Mailman 3 September 2000 - Python-Dev

Re: [Python-checkins] CVS: python/nondist/peps pep-0042.txt,1.19,1.20
by Thomas Wouters Sept. 23, 2000

Sept. 23, 2000

On Fri, Sep 22, 2000 at 09:40:47PM -0700, Fred L. Drake wrote: > Modified Files: > pep-0042.txt > Log Message: > > Added request for a portable time.strptime() implementation. As Tim noted, there already was a request for a separate implementation of strptime(), though slightly differently worded. I've merged them. -- Thomas Wouters <thomas(a)xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

1 0

Sunday code freeze
by Jeremy Hylton Sept. 22, 2000

Sept. 22, 2000

We will need about a day to prepare the 2.0b2 release. Thus, all changes need to be committed by the end of the day on Sunday. A code freeze will be in effect starting then. Please try to resolve any patches or bugs assigned to you before the code freeze. Jeremy

1 0

Versioning for Python packages
by M.-A. Lemburg Sept. 21, 2000

Sept. 21, 2000

[Moved to python-dev from xml-sig] Guido van Rossum wrote: > > > Perhaps a good start would be using lib/python-2.0.0 as installation > > target rather than just lib/python2. I'm sure this was discussed > > before, but given the problems we had with this during the 1.5 > > cycle (with 1.5.2 providing not only patches, but also new > > features), I think a more fine-grained approach should be > > considered for future versions. > > We're using lib/… [View More]python2.0, and we plan not to make major releases with > a 3rd level version number increment! SO I think that's not necessary. Ah, that's good news :-) > > About package versioning: how would the version be specified > > in imports ? > > > > from mx.DateTime(1.4.0) import now > > from mx(1.0.0).DateTime import now > > from mx(1.0.0).DateTime(1.4.0) import now > > > > The directory layout would then look something like this: > > > > mx/ > > 1.0.0/ > > DateTime/ > > 1.4.0/ > > > > Package __path__ hooks could be used to implement the > > lookup... or of course some new importer. > > > > But what happens if there is no (old) version mx-1.0.0 installed ? > > Should Python then default to mx-1.3.0 which is installed or > > raise an ImportError ? > > > > This sounds like trouble... ;-) > > You've got it. Please move this to python-dev. It's good PEP > material! Done. > > > > We will have a similar problem with Unicode and the stdlib > > > > during the Python 2.0 cycle: people will want to use Unicode > > > > together with the stdlib, yet many modules in the stdlib > > > > don't support Unicode. To remedy this, users will have to > > > > patch the stdlib modules and put them somewhere so that they > > > > can override the original 2.0 ones. > > > > > > They can use $PYTHONPATH. > > > > True, but why not help them a little by letting site > > installations override the stdlib ? After all, distutils > > standard target is site-packages. > > Overrides of the stdlib are dangerous in general and should not be > encouraged. > > > > > BTW, with distutils coming on strong I don't really see a > > > > need for any hacks: instead distutils should be given some > > > > smart logic to do the right thing, ie. it should support > > > > installing subpackages of a package. If that's not desired, > > > > then I'd opt for overriding the whole package (without any > > > > hacks to import the overridden one). > > > > > > That's another possibility. But then distutils will have to become > > > aware of package versions again. > > > > This shouldn't be hard to add to the distutils processing: > > before starting an installation of a package, the package > > pre-install hook could check which versions are installed > > and then decide whether to raise an exception or continue. > > Here's another half-baked idea about versions: perhaps packages could > have a __version__.py file? Hmm, I usually put a __version__ attribute right into the __init__.py file of the package -- why another file ? I think we should come up with a convention on these meta-attributes. They are useful for normal modules as well, e.g. __version__, __copyright__, __author__, etc. Looks like its PEP-time again ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ [View Less]

1 0

Disabling Unicode readbuffer interface
by Martin v. Loewis Sept. 21, 2000

Sept. 21, 2000

I just tried to disable the getreadbufferproc on Unicode objects. Most of the test suite continues to work. test_unicode fails, which is caused by "s#" not working anymore when in readbuffer_encode when testing the unicode_internal encoding. That could be fixed (*). More concerning, sre fails when matching a unicode string. sre uses the getreadbufferproc to get to the internal representation. If it has sizeof(Py_UNICODE) times as many bytes as it is long, we got a unicode buffer (?!?). I'm … [View More]

4 5

Unobfuscated Perl Code Contest
by David Ascher Sept. 21, 2000

Sept. 21, 2000

ObPython at the end... ---da Unobfuscated Perl Code Contest September 16, 19100 The Perl Gazette has announced the winners in the First Annual _Un_obfuscated Perl Code Contest. First place went to Edwin Fuller, who submitted this unobfuscated program: #!/usr/bin/perl print "Hello world!\n"; "This was definitely a challenging contest," said an ecstatic Edwin Fuller. "I've never written a Perl program before that didn't have hundreds of qw( $ @ % & * | ? / \ ! # ~ ) symbols. I really … [View More]had to summon all of my programming skills to produce an unobfuscated program." The judges in the contest learned that many programmers don't understand the meaning of 'unobfuscated perl'. For instance, one participant sent in this 'Hello world!' program: #!/usr/bin/perl $x='unob'; open OUT, ">$x.c"; print OUT <<HERE_DOC; #include <stdio.h> int main(void) { FILE *f=fopen("$x.sh", "w"); fprintf(f,"echo Hello world!\\n"); fclose(f); system("chmod +x $x.sh"); system("./$x.sh"); return 0; } HERE_DOC close OUT; system("gcc $x.c -o $x && ./$x"); "As an experienced Perl monger," said one of the judges, "I can instantly tell that this program spits out C source code that spits out a shell script to print 'Hello world!'. But this code certainly does not qualify as unobfuscated Perl -- I mean, most of it isn't even written in Perl!" He added, "Out of all of the entries, only two were actually unobfuscated perl. Everything else looked like line noise -- or worse." The second place winner, Mrs. Sea Pearl, submitted the following code: #!/usr/bin/perl use strict; # Do nothing, successfully exit(0); "I think everybody missed the entire point of this contest," ranted one judge. "Participants were supposed to produce code that could actually be understood by somebody other than a ten-year Perl veteran. Instead, we get an implementation of a Java Virtual Machine. And a version of the Linux kernel ported to Win32 Perl. Sheesh!" In response to the news, a rogue group of Perl hackers have presented a plan to add a "use really_goddamn_strict" pragma to the language that would enforce readability and unobfuscation. With this pragma in force, the Perl compiler might say: Warning: Program contains zero comments. You've probably never seen or used one before; they begin with a # symbol. Please start using them or else a representative from the nearest Perl Mongers group will come to your house and beat you over the head with a cluestick. Warning: Program uses a cute trick at line 125 that might make sense in C. But this isn't C! Warning: Code at line 412 indicates that programmer is an idiot. Please correct error between chair and monitor. Warning: While There's More Than One Way To Do It, your method at line 523 is particularly stupid. Please try again. Warning: Write-only code detected between lines 612 and 734. While this code is perfectly legal, you won't have any clue what it does in two weeks. I recommend you start over. Warning: Code at line 1,024 is indistinguishable from line noise or the output of /dev/random Warning: Have you ever properly indented a piece of code in your entire life? Evidently not. Warning: I think you can come up with a more descriptive variable name than "foo" at line 1,523. Warning: Programmer attempting to re-invent the wheel at line 2,231. There's a function that does the exact same thing on CPAN -- and it actually works. Warning: Perl tries to make the easy jobs easy without making the hard jobs impossible -- but your code at line 5,123 is trying to make an easy job impossible. Error: Programmer failed to include required string "All hail Larry Wall" within program. Execution aborted due to compilation errors. Of course, convincing programmers to actually use that pragma is another matter. "If somebody actually wanted to write readable code, why would they use Perl? Let 'em use Python!" exclaimed one Usenet regular. "So this pragma is a waste of electrons, just like use strict and the -w command line parameter." [View Less]

1 0

Re: [Python-checkins] CVS: python/dist/src/Lib/xml/sax __init__.py,1.6,1.7
by Jeremy Hylton Sept. 21, 2000

Sept. 21, 2000

Lars, I just fixed the last set of checkins you made to the xml package. You left the system in a state where test_minidom failed. When part of the regression test fails, it causes severe problems for all other developers. They have no way to know if the change they've just made to the tuple object (for example) causes the failure or not. Thus, it is essential that the CVS repository never be in a state where the regression tests fail. You're kind of new around here, so I'll let you off … [View More]

1 0

forwarded message from noreply@sourceforge.net
by bwarsaw＠beopen.com Sept. 20, 2000

Sept. 20, 2000

For those of you who may not have received this message, please be aware that SourceForge will have scheduled downtime this Friday night until Saturday morning. -Barry

3 2

FW: [humorix] Unobfuscated Perl Code Contest
by Mark Hammond Sept. 20, 2000

Sept. 20, 2000

And now for something completely different ;-) -- Unobfuscated Perl Code Contest September 16, 19100 The Perl Gazette has announced the winners in the First Annual _Un_obfuscated Perl Code Contest. First place went to Edwin Fuller, who submitted this unobfuscated program: #!/usr/bin/perl print "Hello world!\n"; "This was definitely a challenging contest," said an ecstatic Edwin Fuller. "I've never written a Perl program before that didn't have hundreds of qw( $ @ % & * | ? / \ ! # ~ ) … [View More]symbols. I really had to summon all of my programming skills to produce an unobfuscated program." The judges in the contest learned that many programmers don't understand the meaning of 'unobfuscated perl'. For instance, one participant sent in this 'Hello world!' program: #!/usr/bin/perl $x='unob'; open OUT, ">$x.c"; print OUT <<HERE_DOC; #include <stdio.h> int main(void) { FILE *f=fopen("$x.sh", "w"); fprintf(f,"echo Hello world!\\n"); fclose(f); system("chmod +x $x.sh"); system("./$x.sh"); return 0; } HERE_DOC close OUT; system("gcc $x.c -o $x && ./$x"); "As an experienced Perl monger," said one of the judges, "I can instantly tell that this program spits out C source code that spits out a shell script to print 'Hello world!'. But this code certainly does not qualify as unobfuscated Perl -- I mean, most of it isn't even written in Perl!" He added, "Out of all of the entries, only two were actually unobfuscated perl. Everything else looked like line noise -- or worse." The second place winner, Mrs. Sea Pearl, submitted the following code: #!/usr/bin/perl use strict; # Do nothing, successfully exit(0); "I think everybody missed the entire point of this contest," ranted one judge. "Participants were supposed to produce code that could actually be understood by somebody other than a ten-year Perl veteran. Instead, we get an implementation of a Java Virtual Machine. And a version of the Linux kernel ported to Win32 Perl. Sheesh!" In response to the news, a rogue group of Perl hackers have presented a plan to add a "use really_goddamn_strict" pragma to the language that would enforce readability and unobfuscation. With this pragma in force, the Perl compiler might say: Warning: Program contains zero comments. You've probably never seen or used one before; they begin with a # symbol. Please start using them or else a representative from the nearest Perl Mongers group will come to your house and beat you over the head with a cluestick. Warning: Program uses a cute trick at line 125 that might make sense in C. But this isn't C! Warning: Code at line 412 indicates that programmer is an idiot. Please correct error between chair and monitor. Warning: While There's More Than One Way To Do It, your method at line 523 is particularly stupid. Please try again. Warning: Write-only code detected between lines 612 and 734. While this code is perfectly legal, you won't have any clue what it does in two weeks. I recommend you start over. Warning: Code at line 1,024 is indistinguishable from line noise or the output of /dev/random Warning: Have you ever properly indented a piece of code in your entire life? Evidently not. Warning: I think you can come up with a more descriptive variable name than "foo" at line 1,523. Warning: Programmer attempting to re-invent the wheel at line 2,231. There's a function that does the exact same thing on CPAN -- and it actually works. Warning: Perl tries to make the easy jobs easy without making the hard jobs impossible -- but your code at line 5,123 is trying to make an easy job impossible. Error: Programmer failed to include required string "All hail Larry Wall" within program. Execution aborted due to compilation errors. Of course, convincing programmers to actually use that pragma is another matter. "If somebody actually wanted to write readable code, why would they use Perl? Let 'em use Python!" exclaimed one Usenet regular. "So this pragma is a waste of electrons, just like use strict and the -w command line parameter." - Humorix: Linux and Open Source(nontm) on a lighter note Archive: http://humbolt.nl.linux.org/lists/ Web site: http://www.i-want-a-website.com/about-linux/ ----- End forwarded message ----- [View Less]

1 0

[ Bug #110676 ] fd.readlines() hangs (via popen3) (PR#385)
by Martin v. Loewis Sept. 20, 2000

Sept. 20, 2000

I've closed your report at http://sourceforge.net/bugs/?func=detailbug&bug_id=110676&group_id=5470 That is a bug in the application code. The slave tries to write 6000 bytes to stderr, and blocks after writing 4096 (number measured on Linux, more generally, after _PC_PIPE_BUF bytes). The server starts reading on stdin, and blocks also, so you get a deadlock. The proper solution is to use import popen2 r,w,e = popen2.popen3 ( 'python slave.py' ) e.readlines() r.readlines() r.… [View More]

1 0

2.0 Optimization & speed
by Vladimir.Marangozov＠inrialpes.fr Sept. 20, 2000

Sept. 20, 2000

Continuing my impressions on the user's feedback to date: Donn Cave & MAL are at least two voices I've heard about an overall slowdown of the 2.0b1 release compared to 1.5.2. Frankly, I have no idea where this slowdown comes from and I believe that we have only vague guesses about the possible causes: unicode database, more opcodes in ceval, etc. I wonder whether we are in a position to try improving Python's performance with some `wise quickies' in a next beta. But this raises a more … [View More]fundamental question on what is our margin for manoeuvres at this point. This in turn implies that we need some classification of the proposed optimizations to date. Perhaps it would be good to create a dedicated Web page for this, but in the meantime, let's try to build a list/table of the ideas that have been proposed so far. This would be useful anyway, and the list would be filled as time goes. Trying to push this initiative one step further, here's a very rough start on the top of my head: Category 1: Algorithmic Changes These are the most promising, since they don't relate to pure technicalities but imply potential improvements with some evidence. I'd put in this category: - the dynamic dictionary/string specialization by Fred Drake (this is already in). Can this be applied in other areas? If so, where? - the Python-specific mallocs. Actually, I'm pretty sure that a lot of `overhead' is due to the standard mallocs which happen to be expensive for Python in both space and time. Python is very malloc-intensive. The only reason I've postponed my obmalloc patch is that I still haven't provided an interface which allows evaluating it's impact on the mem size consumption. It gives noticeable speedup on all machines, so it accounts as a good candidate w.r.t. performance. - ??? (maybe some parts of MAL's optimizations could go here) Category 2: Technical / Code optimizations This category includes all (more or less) controversial proposals, like - my latest lookdict optimizations (a typical controversial `quickie') - opcode folding & reordering. Actually, I'm unclear on why Guido postponed the reordering idea; it has received positive feedback and all theoretical reasoning and practical experiments showed that this "could" help, although without any guarantees. Nobody reported slowdowns, though. This is typically a change without real dangers. - kill the async / pending calls logic. (Tim, what happened with this proposal?) - compact the unicodedata database, which is expected to reduce the mem footprint, maybe improve startup time, etc. (ongoing) - proposal about optimizing the "file hits" on startup. - others? If there are potential `wise quickies', meybe it's good to refresh them now and experiment a bit more before the final release? -- Vladimir MARANGOZOV | Vladimir.Marangozov(a)inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 [View Less]

8 11