"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."
"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