view release on metacpan or  search on metacpan

t/data/python_quotes.txt  view on Meta::CPAN

      -- Frank Sergeant, 28 Mar 1999

But it's a general way to debug: tell someone what right things your program is
doing. Chances are that you will see the wrong thing(s) before the other person
has said anything... I just stick a picture of a face on my monitor and talk to
it to find bugs.
      -- Richard van de Stadt, 9 Apr 1999

Might just be nostalgia, but I think I would give an arm or two to get that
(not necessarily my own, though).
      -- Fredrik Lundh, 13 May 1999

    1. Beautiful is better than ugly.
    2. Explicit is better than implicit.
    3. Simple is better than complex.
    4. Complex is better than complicated.
    5. Flat is better than nested.
    6. Sparse is better than dense.
    7. Readability counts.
    8. Special cases aren't special enough to break the rules.
    9. Although practicality beats purity.
    10. Errors should never pass silently.
    11. Unless explicitly silenced.
    12. In the face of ambiguity, refuse the temptation to guess.
    13. There should be one -- and preferably only one -- obvious way to do it.
    14. Although that way may not be obvious at first unless you're Dutch.
    15. Now is better than never.
    16. Although never is often better than *right* now.
    17. If the implementation is hard to explain, it's a bad idea.
    18. If the implementation is easy to explain, it may be a good idea.
    19. Namespaces are one honking great idea -- let's do more of those!
      -- Tim Peters' 19 Pythonic Theses, 4 Jun 1999

    "However, I've heard that after about 10K items in a dict, it starts having
problems."
    "11,523 to be exact. After that, dicts drink to excess and show up for work
late the morning after. We don't like to talk about it, though."
      -- Aahz Maruch and Tim Peters, 8 Jun 1999

Stackless Python 0.2, a plug-in replacement for the Python core that does not
use the C stack, has been announced by Christian Tismer as the best way to
prove that it was possible without a major rewrite to the core. Neel
Krishnaswami commented to Christian, "This is very neat, and you are completely
deranged".
      -- From Linux Weekly News, 17 Jul 1999

... we need more people like him, who are willing to explore without being
driven to argue with people about it.
      -- William Tanksley on Chuck Moore, inventor of Forth, 2 Jul 1999

Sorry for the term, I picked it up from Jim Fulton back when it was an
about-to-be-added feature for Principia/Aqueduct. As with so many Fultonisms,
it's vivid and tends to stick in one's (non-pluggable) brain.
      -- Paul Everitt on the term "pluggable brains", 5 Jul 1999

I picture a lump of inanimate flesh (a result from a relational database query)
being infused with the spark of life (object behavior, aka class).
      -- Jim Fulton on the term "pluggable brains", 5 Jul 1999

This is good. It means that while Ionesco is dead, his spirit lives on.
      -- Gordon McMillan on how Windows attaches meaning to 3-character
         file extensions, 30 Jul 1999

(On the statement print "42 monkeys"+"1 snake") BTW, both Perl and Python get
this wrong. Perl gives 43 and Python gives "42 monkeys1 snake", when the answer
is clearly "41 monkeys and 1 fat snake".
      -- Jim Fulton, 10 Aug 1999

I expect that what you really object to is the absence of control structures
other than goto, and the LT/GE/etc spelling of comparison operators. That was
common enough in its day, and even by the time Pascal came around the keypunch
I used still didn't have a semicolon key. It looks ugly in retrospect only
because it is <wink>.
      -- Tim Peters on SNOBOL4, 17 Aug 1999

Theory and reality rarely are kissing cousins.
      -- Christopher Petrilli, 1 Sep 1999

Features generally don't exist in isolation, and you have to look at all the
consequences, not just the one that attracts you at first sight.
      -- Tim Peters, 3 Sep 1999

The danger in this line of thinking is not realizing that the computational
effort involved in big NP complete problems is *so* huge that even in optimized
micro-code, the algorithm might take a million years to run. Tweezers or shovel
-- it makes little difference when you are trying to move a universe...
      -- Sean McGrath, 4 Sep 1999

On a scale of one to ten I'd give it a tim.
      -- William Tanksley, 13 Sep 1999

Statistical analysis shows that the junk looks like human text, which clearly
shows that it is actually used in some yet unknown way. (docstrings?)
      -- Fredrik Lundh, writing about junk DNA, 5 Oct 1999

If I engineer code that I expect to be in use for N years, I make damn sure
that every internal limit is at least 10x larger than the largest I can
conceive of a user making reasonable use of at the end of those N years. The
invariable result is that the N years pass, and fewer than half of the users
have bumped into the limit <0.5 wink>.
      -- Tim Peters, 11 Nov 1999

I don't think the bytecodehacks, while sufficiently dark and useless to be a
tim-ism, qualify me in any way for a Pythonic Wizard Hat...
      -- Michael Hudson, 16 Nov 1999

The bottom tier is what a certain class of wanker would call "business
objects"...
      -- Greg Ward, 9 Dec 1999

Since I've done fewer than my normal quota of futile things this week, I
thought I'd post to remind people that ...
      -- Phil Austin, 9 Dec 1999

There are useful diagrams in UML, (eg, the state and transition diagrams).
Unfortunately, the one most tools use to generate code (and draw from reverse
engineering) has everything to do with language structure, and nothing to do
with what actually happens at runtime. To put it bluntly: people spend most of
their time designing the wrong thing. Worse, they get it wrong, but it's carved
in stone now; so the final system is either needlessly complex and marginally
functional, or bears no resemblance to the "design".