view release on metacpan or  search on metacpan

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

it left off <wink>.
    m100-basic-reminded-me-a-lot-of-python-except-that-it-sucked-ly y'rs
      -- Tim Peters remembering the Model 100, 10 Jan 1999

    "Heh -- all it really broke so far was my resistance to installing Tk. I
suppose wizardry is inevitable after one installs something, though <wink>."
    "Spoken like a truly obsessive-compulsive wizard! It-takes-one-to-know
-one..."
      -- Tim Peters and Guido van Rossum, 6 Jan 1999

Note, however, that architectural forms are completely declarative and can be
implemented in a highly optimized fashion. The sorts of extensions that
Microsoft has proposed for XSL (<xsl:eval>...</>) would completely destroy
those features. Architectural mapping would, in general, be as reliable and
high performance as ordinary software -- (not at all).
      -- Paul Prescod, 6 Jan 1999

Darned confusing, unless you have that magic ingredient *coffee*, of which I
can pay you Tuesday for a couple pounds of extra-special grind today.
      -- John Mitchell, 11 Jan 1999

That's so obvious that someone has already got a patent on it.
      -- Guido van Rossum, 12 Jan 1999

I have to stop now. I've already told you more than I know.
      -- Wolf Logan, 14 Jan 1999

I really don't have any incisive insights about the economic mechanisms or
viability of free software and open source, but I do have a strong, clear sense
that such things make it possible for me to do my job, as a programmer and a
facilitator of/participant in online communities, better and more easily than I
otherwise could do.
      -- Ken Manheimer, 24 Jan 1999

    Every standard applies to a certain problem domain and a certain level. A
standard can work perfectly and save the world economy billions of dollars and
there will still be software and hardware compatibility problems. In fact,
solving one level of compatibility just gives rise to the next level of
incompatibility. For example, connecting computers together through standard
protocols gives rise to the problem of byte endianness issues. Solving byte
endianness gives rise to the problem of character sets. Solving character sets
gives rise to the problem of end-of-line and end-of-file conventions. Solving
that gets us to the problem of interpreting the low-level syntax (thus XML).
Then we need to interpet that syntax in terms of objects and properties (thus
RDF, WDDX, etc.). And so forth.
    We could judge a standard's success by its ability to reveal another level
of standardization that is necessary.
      -- Paul Prescod, 24 Jan 1999

I just want to go on the record as being completely opposed to computer
languages. Let them have their own language and soon they'll be off in the
corner plotting with each other!
      -- Steven D. Majewski, 25 Jan 1999

Constraints often boost creativity.
      -- Jim Hugunin, 11 Feb 1999

Programming is no different - it's only by going outside what you know, and
looking from another direction (working, if you like, your brain, so that it
can be more powerful :-) that you can improve further.
      -- Andrew Cooke, 12 Feb 1999

any-technology-indistinguishable-from-magic-is-too-mysterious- to- trust-ly
y'rs
      -- Tim Peters, 16 Feb 1999

    "I don't think we've thought of this, and it's actually a good idea."
    "I'd better go patent it!"
      -- Uche Ogbuji and Paul Prescod, 16 Feb 1999

Contrary to advertising, no parsing system is "easy to learn", in or out of the
Python world -- parsing is a hard problem. Most are easy enough to use after
practice, though. Ironically, the trickiest system of all to master (regexps)
is also the feeblest and the most widely used.
      -- Tim Peters, 17 Feb 1999

So Python's only cross-platform choices were to mimic the C/POSIX API or invent
its own new x-platform API; only one of those is realistic (as Java proves
every day <wink>).
      -- Tim Peters, 21 Feb 1999

Yes: the code in ntpath.split is too clever to have any hope of working
correctly <wink>.
      -- Tim Peters, 19 Mar 1999

Thanks. The sooner I get discouraged and quit, the more time I'll save overall.
      -- 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."

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

      -- Simon Callan and Gareth McCaughan, 04 Nov 2001, after someone
         quoted the limerick "There was a young man from Wooloomooloo /
         Whose limericks always finished on line two."

Sometimes I feel like I'm reinventing Zope, but at least it's a Zope I
understand.
      -- Quinn Dunkan, 05 Nov 2001 on the quixote-users list

Homological algebra beckons -- brain relief in this context!
      -- Michael Hudson, 07 Nov 2001, in a discussion of Stackless Python

If you're talking "useful", I'm not your bot.
      -- Tim Peters, 08 Nov 2001

    "How do you do a range of floats?"
    "Bring flowers, and buy them all nice dinners. Try not to be *too* obvious
that you're out to do them, though."
      -- Thomas Wouters and Tim Peters, 09 Nov 2001

Changing diapers reminded Guido that he wanted to allow for some measure of
multiple inheritance from a mix of new- and classic-style classes.
      -- Tim Peters in a checkin message, 14 Nov 2001

My late father-in-law, Ray Pigozzi, was an extremely talented architect (he was
made a fellow of the AIA in the late 70's or early 80's), and although he was
by all accounts an excellent mentor to younger architects in the firm he
cofounded, he also had the well- deserved reputation of being quite laconic
(this I know from personal experience ;-). Early in his career, he received an
award from some masonry organization for his use of brick in building OWP (now
OWP&P) had designed. This necessitated the usual awards ceremony with dinner
and speeches. The recipients who preceeded Ray to the podium all spoke at
length about their work. Ray's entire acceptance speech was, "The building
speaks for itself."
      -- Skip Montanaro, 4 Jan 2002

The Lisp community is like a ghost town, with the occasional banshee howl
echoing darkly around the chamber in lament of what might have been.
      -- Courageous, 19 Jan 2002

I'll lend you _Calendrical Calculations_. Even *skimming* the chapters on some
of the world's other calendrical delights makes our date gimmicks blind via the
intensity of their clarity.
      -- Tim Peters, 05 Mar 2002

The joy of coding Python should be in seeing short, concise, readable classes
that express a lot of action in a small amount of clear code -- not in reams of
trivial code that bores the reader to death.
      -- GvR, 20 Mar 2002

A bot may injure a human being, or, preferably, through inaction, allow a human
being to come to harm, although laughing about either in the hearing of humans
is MACNAM-017B3^H.
      -- Tim Peters, 26 Mar 2002

"It works in Scheme" doesn't give me the warm fuzzy feeling that it's been
tried in real life.
      -- GvR, 02 Oct 2002

Most recipes are short enough for the attention span of the average Python
programmer.
      -- GvR, in the introduction to the _Python Cookbook_

We read Knuth so you don't have to.
      -- Tim Peters, _Python Cookbook_

Here's another technique that is faster and more obvious but that is often
avoided by those who mistakenly believe that writing two lines of code where
one might do is somehow sinful.
      -- Tim Peters, _Python Cookbook_

A fruitful approach to problem solving is known as "divide and conquer", or
making problems easier by splitting their different aspects apart. Making
problems harder by joining several aspects together must be an example of an
approach known as "unite and suffer!"
      -- Alex Martelli, _Python Cookbook_

compromise-is-the-art-of-spreading-misery-ly y'rs
      -- Tim Peters, 11 Dec 2002

As for Grail, it was certainly a "hot product" in the Python community in 1995
because of the restricted execution environment which I evaluated for a project
involving mobile software agents. How priorities and trends have changed since
then! Who would have thought that Microsoft Outlook would be the premier
platform for mobile code?
      -- Paul Boddie, 16 Jan 2004

    I mean, if I think about my open-source contributions, nobody wants to see
talks with these titles:
    * The Zope API Reference: Ouch
    * A Random Handful Of Bugs I've Fixed In Other Peoples' Code
    * An Old Crufty Project I Inherited That Has Zero Relevance To You
    * The Joy of Preemptive Abandonware: Release Late, If Ever (or, Software
Design as a Nihilistic Abstract Art Form) (or, Sourceforge as a Medium for
Cryptic Time Capsules)
      -- Paul Winkler, 14 Mar 2005

Syntax should not look like grit on my monitor.
      -- Anthony Baxter, 02 Jun 2005

Can this not be resolved by carefully adjusting the order of finalization? If
code can be bootstrapped it can be strootbapped.
      -- Kristján Jónsson, 30 Jun 2006

Python resembles Lisp like an octopus eye resembles a mammalian eye: they have
lots in common because they're both pretty good solutions to similar problems.
Deciding whether it's Python or Lisp that has the retina fitted back-to-front
is left as an exercise for the reader.
      -- Gareth McCaughan, 11 Jul 2006

As Neal said, we are not perfect; bugs happen. If we all gave up on a piece of
software after two bugs we would not be able to turn our computers.
      -- Brett Cannon, 13 Jul 2006

... I've come to believe that some people have the personality traits that let
them tolerate redoing the same work over and over again for no reason other
than management "furniture rearranging", whereas others start to resent having
their (working) life repeatedly flashed before their eyes, but in slightly
different colours, over a longer period of time.
      -- Paul Boddie, 29 Aug 2006

    I am the very model of a modern major database,
     For gigabytes of information gathered out in userspace.
     For banking applications to a website crackers will deface,
     You access me from console or spiffy user interface.
    My multi-threaded architecture offers you concurrency,
     And loads of RAM for caching things reduces query latency.
     The data is correctly typed, a fact that I will guarantee,
     Each datum has a data type, it's specified explicitly.
      -- Tim Chase, 12 Sep 2006