Mailman 3 August 2003 - Python-Dev

Re-introduce caching for _strptime.py for 2.3.1?
by Brett C. 05 Aug '03

05 Aug '03

Bug #780807 is a complaint that strptime is now 1,200 times slower than a C library version the user used to have. Now slowdown is going to happen since Python string code can't compete with C string code, let alone _strptime has to figure out the locale info it needs while a C version has direct access. And I am sure people who now have strptime on their platform are not going to complain about performance. =) But 1,200 times is a little high. The new version I checked into HEAD is supposedly only 3 times slower than the equivalant C version according to the bug report submitter. This is mainly because of caching. My question is whether I should backport any of this. The new version of _strptime is thread-safe and has caching (2.3 is already thread-safe thanks to the loss of caching for that version). If I were to re-introduce caching (which was in 2.3 until a day before 2.3.0c2) I would need to also tweak other code to keep it thread-safe. In other words I would have to do more work than just throw back in the caching code with the addition of a thread lock. Is this considered a bugfix? The only reason I question whether it is since it is not a pure "bugfix" is because I know at least Raymond thought the code should have gone back in before 2.3.0 final went out. Had I not been so panicked about fixing that one bug the caching code would still be in there and I would be patching 2.3.1 to make it thread-safe instead of sending out this email. -Brett

3 3

IDLE NEWS and Version
by kbk＠shore.net 05 Aug '03

05 Aug '03

IDLE has historically maintained its own NEWS file, and it is now accessible from IDLE's Help/About menu. Maintaining this file has the advantage that all the IDLE NEWS is kept in one place and is easily parsable for display. Do we want to continue this tradition or merge IDLE NEWS into Python NEWS on a go-forward basis? Second, do we want to continue the IDLE versioning (currently 1.0) or just drop it now that IDLE is no longer distributed separately? -- KBK

2 1

RE: Python-Dev Digest, Vol 1, Issue 3435
by Sanket Patel 05 Aug '03

05 Aug '03

Stop spaming our server. Please remove all the email addresses containing @kelseus.com domain from your mailing list. Sanket Patel Network Engineer Kelseus Ltd DDI: +44 (0)1223 471235 Fax: +44 (0)1223 471220 http://www.kelseus.com -----Original Message----- From: python-dev-request(a)python.org [mailto:python-dev-request@python.org] Sent: Tuesday, August 05, 2003 5:01 PM To: python-dev(a)python.org Subject: Python-Dev Digest, Vol 1, Issue 3435 Send Python-Dev mailing list submissions to python-dev(a)python.org To subscribe or unsubscribe via the World Wide Web, visit http://mail.python.org/mailman/listinfo/python-dev or, via email, send a message with subject or body 'help' to python-dev-request(a)python.org You can reach the person managing the list at python-dev-owner(a)python.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Python-Dev digest..." Today's Topics: 1. Re: python-dev Summary for 2003-07-01 through 2003-07-31 [draft] (Michal Wallace) 2. Re: python-dev Summary for 2003-07-01 through 2003-07-31 [draft] (Brett C.) 3. New place for python-mode bug reports and patches (Skip Montanaro) 4. RE: Re: Re: pirate (python+parrot) (logistix) 5. Re: Re: pirate (python+parrot) (Michael Hudson) 6. Re: Python 2.3 maintenance branch is now open (Jack Jansen) 7. RE: python-dev Summary for 2003-07-01 through 2003-07-31 [draft] (Michael Chermside) 8. Re: Python 2.3 maintenance branch is now open (Michael Hudson) 9. Re: Python 2.3 maintenance branch is now open (Barry Warsaw) 10. IDLE NEWS and Version (Kurt B. Kaiser) ---------------------------------------------------------------------- Message: 1 Date: Mon, 4 Aug 2003 23:20:43 -0400 (EDT) From: Michal Wallace <michal(a)sabren.com> Subject: Re: [Python-Dev] python-dev Summary for 2003-07-01 through 2003-07-31 [draft] To: brett(a)python.org Cc: python-dev(a)python.org Message-ID: <Pine.LNX.4.44.0308042315540.31222-100000(a)hydrogen.sabren.com> Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 4 Aug 2003, Brett C. wrote: > Another offer sprung up this month from Michal Wallace to host our > CVS at http://www.versionhost.com/ with the hitch that the server > would be pserver only which would thus most likely only work for > anonymous checkouts Not at all! That's the whole point. :) And if you like using ssh, there's always stunnel, or: http://www.sabren.net/code/cvssh/ Sincerely, Michal J Wallace Sabren Enterprises, Inc. ------------------------------------- contact: michal(a)sabren.com hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ -------------------------------------- ------------------------------ Message: 2 Date: Mon, 04 Aug 2003 20:25:08 -0700 From: "Brett C." <bac(a)OCF.Berkeley.EDU> Subject: Re: [Python-Dev] python-dev Summary for 2003-07-01 through 2003-07-31 [draft] To: Michal Wallace <michal(a)sabren.com> Cc: brett(a)python.org, python-dev(a)python.org Message-ID: <3F2F2394.4070807(a)ocf.berkeley.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Michal Wallace wrote: > On Mon, 4 Aug 2003, Brett C. wrote: > > >>Another offer sprung up this month from Michal Wallace to host our >>CVS at http://www.versionhost.com/ with the hitch that the server >>would be pserver only which would thus most likely only work for >>anonymous checkouts > > > Not at all! That's the whole point. :) > > And if you like using ssh, there's always stunnel, or: > http://www.sabren.net/code/cvssh/ > Glad to hear that! I know I would not be the only one who would strongly object to moving the CVS over to anything that didn't have some form of SSH protection (and allowed for SSH keys since I know I am too damn lazy to type my password in constantly =) . -Brett ------------------------------ Message: 3 Date: Mon, 4 Aug 2003 22:49:02 -0500 From: Skip Montanaro <skip(a)pobox.com> Subject: [Python-Dev] New place for python-mode bug reports and patches To: python-list(a)python.org, python-dev(a)python.org, python-mode(a)python.org Message-ID: <16175.10542.302239.792809(a)montanaro.dyndns.org> Content-Type: text/plain; charset=us-ascii As many of you are already aware, Barry Warsaw recently created a new project on SourceForge to house the python-mode.el code which makes Emacs and XEmacs so delightful to edit Python code. I just completed migrating all open bugs and patches which mention python-mode from the python project to the new python-mode project. In the future, please submit all bugs and patches at http://sourceforge.net/projects/python-mode/ All new bugs and patches regarding python-mode should be submitted to the new project. There's also a mailing list, python-mode(a)python.org, to which you can subscribe in the usual Pythonic fashion: http://mail.python.org/mailman/listinfo/python-mode Skip ------------------------------ Message: 4 Date: Tue, 5 Aug 2003 02:58:32 -0400 From: "logistix" <logistix(a)cathoderaymission.net> Subject: RE: [Python-Dev] Re: Re: pirate (python+parrot) To: "'A.M. Kuchling'" <amk(a)amk.ca>, <python-dev(a)python.org> Message-ID: <000001c35b1e$fc938a60$20bba8c0@XP> Content-Type: text/plain; charset="us-ascii" [guido(a)python.net] > wrote: > > Sure, but bytecode evolves slowly enough to be useful for Dan; given > > that the only parse tree format we have is *intricately* linked with > > the Python parser and (at least part of) its runtime, > [AMK] > It is? Both translators are using the compiler package, not > the parser > module; can it be said to be intricately linked with the runtime? > Admittedly it uses the parser module underneath, but the AST > representation > itself is pretty generic, isn't it? > As Michal touched on earlier, I wrote a hand-coded pure-python parser that plugs into the compiler package. It takes about 1.5-2x as long to compile vs using the native parser module. The resultant tuples can also be shoved back into genuine parse trees via parser.sequence2ast(). So yeah, it's not that big of a deal to generate AST trees without the runtime (until some crazy function attribute syntax gets added to python, that is) http://www.cathoderaymission.net/~logistix/python/pparser.py -Grant ------------------------------ Message: 5 Date: Tue, 05 Aug 2003 11:22:09 +0100 From: Michael Hudson <mwh(a)python.net> Subject: Re: [Python-Dev] Re: pirate (python+parrot) To: python-dev(a)python.org Message-ID: <2mllu8qu9a.fsf(a)starship.python.net> Content-Type: text/plain; charset=us-ascii Guido van Rossum <guido(a)python.net> writes: > Interesting indeed. The focus on bytecode is understandable: let > someone else write a parser, so Parrot won't have to. But from > skimming his log, Dan seems to take the bytecode too seriously; > it's really only meant to be a quick way for the parser to output > something. In particular, bytecode hacks were never a goal. Really? You surprise me <wink>. Cheers, mwh -- 3. Syntactic sugar causes cancer of the semicolon. -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html ------------------------------ Message: 6 Date: Tue, 5 Aug 2003 12:47:47 +0200 From: Jack Jansen <Jack.Jansen(a)cwi.nl> Subject: Re: [Python-Dev] Python 2.3 maintenance branch is now open To: Barry Warsaw <barry(a)python.org> Cc: LIST Python Developers <python-dev(a)python.org> Message-ID: <4053FFDF-C732-11D7-BB10-0030655234CE(a)cwi.nl> Content-Type: text/plain; charset=US-ASCII; format=flowed On Tuesday, Aug 5, 2003, at 00:58 Europe/Amsterdam, Barry Warsaw wrote: > Jack turned over the release23-branch branch to me so I was able to > create the Python 2.3 maintenance branch. Here's what I did: > > - checked out release23-fork > - cvs tag -b release23-maint > - cvs up -rrelease23-maint > - cvs up -j release23-branch > - cvs commit Barrt, how about porting things back to the trunk? Is that my responsibility for the stuff I changed between 2.3 and 2.3-mac? -- Jack Jansen, <Jack.Jansen(a)cwi.nl>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ------------------------------ Message: 7 Date: Tue, 5 Aug 2003 04:30:28 -0700 From: Michael Chermside <mcherm(a)mcherm.com> Subject: [Python-Dev] RE: python-dev Summary for 2003-07-01 through 2003-07-31 [draft] To: python-dev(a)python.org Message-ID: <1060083028.3f2f95543a9a2(a)mcherm.com> Content-Type: text/plain; charset=ISO-8859-1 Brett writes: > I would appreciate not just correctional feedback but just overall > feedback as well for this summary. I have changed the format once again > as well as the general philosophy behind the Summaries Brett, you're doing great as usual. Saving enough time to survive grad school may have been your primary motivation, but I actually think that this revised format is better than your exhaustive one. IMHO people who wanted to know every detail that went on would just subscribe to python-dev, and people who wanted historical accuracy would just consult the list archives. Your summaries made these tasks easier, but could never be as exhaustive as just reading the list. However, the "more journalistic" approach is really nice because it helps to separate out the relevent from the insignifigant. It is a very useful filtering of the information, providing something you CAN'T get by reading the list. Of course, it's *your* idea of what's important and what's not, but at this point I'd say you're as qualified as any to make that call, and more qualified than almost all. Keep up the great work! -- Michael Chermside ------------------------------ Message: 8 Date: Tue, 05 Aug 2003 12:31:08 +0100 From: Michael Hudson <mwh(a)python.net> Subject: Re: [Python-Dev] Python 2.3 maintenance branch is now open To: python-dev(a)python.org Message-ID: <2m8yq8qr2b.fsf(a)starship.python.net> Content-Type: text/plain; charset=us-ascii Barry Warsaw <barry(a)python.org> writes: > Jack turned over the release23-branch branch to me so I was able to > create the Python 2.3 maintenance branch. Here's what I did: > > - checked out release23-fork > - cvs tag -b release23-maint > - cvs up -rrelease23-maint > - cvs up -j release23-branch > - cvs commit > > IOW, I basically branched release23-maint off of the release23-fork tag > on the trunk, then I merged all the changes in the release23-branch to > the release23-maint. Here's a recipe I use for branches that others might find useful: $ cd ~/src/python/dist/ $ cvs co -d src-23x -r release23-maint python/dist/src (This creates -- eventually -- a src-23x directory alongside the src directory which contains the trunk) Then hack CVS/Entries to contain a line D/src-23x//// Now running cvs up in python/dist/ will update both the trunk and the release23-maint code (and in my case release22-maint, too). Cheers, mwh -- Just point your web browser at http://www.python.org/search/ and look for "program", "doesn't", "work", or "my". Whenever you find someone else whose program didn't work, don't do what they did. Repeat as needed. -- Tim Peters, on python-help, 16 Jun 1998 ------------------------------ Message: 9 Date: 05 Aug 2003 08:44:58 -0400 From: Barry Warsaw <barry(a)python.org> Subject: Re: [Python-Dev] Python 2.3 maintenance branch is now open To: Jack Jansen <Jack.Jansen(a)cwi.nl> Cc: LIST Python Developers <python-dev(a)python.org> Message-ID: <1060087498.8108.2.camel@anthem> Content-Type: text/plain On Tue, 2003-08-05 at 06:47, Jack Jansen wrote: > Barrt, > how about porting things back to the trunk? Is that my responsibility > for the stuff I changed between 2.3 and 2.3-mac? I wasn't planning on porting things back to the trunk, so it would be great if you could do it. -Barry ------------------------------ Message: 10 Date: Tue, 05 Aug 2003 11:54:50 -0400 From: kbk(a)shore.net (Kurt B. Kaiser) Subject: [Python-Dev] IDLE NEWS and Version To: python-dev(a)python.org Message-ID: <m3znionlpx.fsf(a)float.attbi.com> Content-Type: text/plain; charset=us-ascii IDLE has historically maintained its own NEWS file, and it is now accessible from IDLE's Help/About menu. Maintaining this file has the advantage that all the IDLE NEWS is kept in one place and is easily parsable for display. Do we want to continue this tradition or merge IDLE NEWS into Python NEWS on a go-forward basis? Second, do we want to continue the IDLE versioning (currently 1.0) or just drop it now that IDLE is no longer distributed separately? -- KBK ------------------------------ _______________________________________________ Python-Dev mailing list Python-Dev(a)python.org http://mail.python.org/mailman/listinfo/python-dev End of Python-Dev Digest, Vol 1, Issue 3435 *******************************************

1 0

pirate (python+parrot)
by Michal Wallace 05 Aug '03

05 Aug '03

Hey all, Earlier this week, I picked up amk's old crack at generating parrot bytecode, and have got it working again with imcc, the new(er) high(er)-level parrot assembler. Between imcc and the python compiler package, it's actually moving pretty rapidly. Currently, it supports: - print - lists, strings, ints (but no methods on them) - assignment and multi-assignment ( x,y=1,2 ) - while, for, if/elif/else, break, continue - math operations (+, -, *, /, %) - boolean logic (and, or, not) - comparison operators - function calls - lambda You can browse the code here: http://pirate.versionhost.com/viewcvs.cgi/pirate/ (See the README file for more info) To run it, you'll need python and also to check out and build parrot from cvs: http://dev.perl.org/cvs/ I'm just posting here to see if anyone's interested in helping out. There's a to-do list and help wanted section in the README, but one thing I could *really* use some help with is figuring out how to get the core C types working as PMCs. A PMC is supposedly very similar to a PyObject, so I'm wondering if it's possible to bridge the two without doing a lot of extra work. I just don't know enough C to judge. Anyway, cheers. :) Sincerely, Michal J Wallace Sabren Enterprises, Inc. ------------------------------------- contact: michal(a)sabren.com hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ --------------------------------------

7 16

Python 2.3 maintenance branch is now open
by Barry Warsaw 05 Aug '03

05 Aug '03

Jack turned over the release23-branch branch to me so I was able to create the Python 2.3 maintenance branch. Here's what I did: - checked out release23-fork - cvs tag -b release23-maint - cvs up -rrelease23-maint - cvs up -j release23-branch - cvs commit IOW, I basically branched release23-maint off of the release23-fork tag on the trunk, then I merged all the changes in the release23-branch to the release23-maint. The release23-maint branch is now open for patches for Python 2.3.1. The release23-branch branch is now closed. Cheers, -Barry

4 5

RE: python-dev Summary for 2003-07-01 through 2003-07-31 [draft]
by Michael Chermside 05 Aug '03

05 Aug '03

Brett writes: > I would appreciate not just correctional feedback but just overall > feedback as well for this summary. I have changed the format once again > as well as the general philosophy behind the Summaries Brett, you're doing great as usual. Saving enough time to survive grad school may have been your primary motivation, but I actually think that this revised format is better than your exhaustive one. IMHO people who wanted to know every detail that went on would just subscribe to python-dev, and people who wanted historical accuracy would just consult the list archives. Your summaries made these tasks easier, but could never be as exhaustive as just reading the list. However, the "more journalistic" approach is really nice because it helps to separate out the relevent from the insignifigant. It is a very useful filtering of the information, providing something you CAN'T get by reading the list. Of course, it's *your* idea of what's important and what's not, but at this point I'd say you're as qualified as any to make that call, and more qualified than almost all. Keep up the great work! -- Michael Chermside

1 0

New place for python-mode bug reports and patches
by Skip Montanaro 04 Aug '03

04 Aug '03

As many of you are already aware, Barry Warsaw recently created a new project on SourceForge to house the python-mode.el code which makes Emacs and XEmacs so delightful to edit Python code. I just completed migrating all open bugs and patches which mention python-mode from the python project to the new python-mode project. In the future, please submit all bugs and patches at http://sourceforge.net/projects/python-mode/ All new bugs and patches regarding python-mode should be submitted to the new project. There's also a mailing list, python-mode(a)python.org, to which you can subscribe in the usual Pythonic fashion: http://mail.python.org/mailman/listinfo/python-mode Skip

1 0

python-dev Summary for 2003-07-01 through 2003-07-31 [draft]
by Brett C. 04 Aug '03

04 Aug '03

Here is the rough draft of the Summary for the month of July (once again I combined two summaries into a single month-long summary since I couldn't get to the earlier summary soon enough to warrant a separate release). As usual you guys have a day or so to send in corrections. I would appreciate not just correctional feedback but just overall feedback as well for this summary. I have changed the format once again as well as the general philosophy behind the Summaries in preparation for when I start grad school and have to cut back on the breadth of the Summaries. You can read the Summary Announcements section to see what and why I have changed. Any feedback is appreciated. ------------- python-dev Summary for 2003-07-01 through 2003-07-31 ++++++++++++++++++++++++++++++++++++++++++++++++++++ This is a summary of traffic on the `python-dev mailing list`_ from July 1, 2003 through July 31, 2003. It is intended to inform the wider Python community of on-going developments on the list and to have some impact or hold interest to the wider Python community. To comment on anything mentioned here, just post to python-list(a)python.org or `comp.lang.python`_ with a subject line mentioning what you are discussing. All python-dev members are interested in seeing ideas discussed by the community, so don't hesitate to take a stance on something. And if all of this really interests you then get involved and join `python-dev`_! This is the twenty-first/twenty-second summary written by Brett Cannon (who is still learning how to count; gave the wrong summary count last month). All summaries are archived at http://www.python.org/dev/summary/ . Please note that this summary is written using reStructuredText_ which can be found at http://docutils.sf.net/rst.html . Any unfamiliar punctuation is probably markup for reST_ (otherwise it is probably regular expression syntax or a typo =); you can safely ignore it, although I suggest learning reST; its simple and is accepted for `PEP markup`_ and gives some perks for the HTML output. Also, because of the wonders of programs that like to reformat text, I cannot guarantee you will be able to run the text version of this summary through Docutils_ as-is unless it is from the original text file. .. _PEP Markup: http://www.python.org/peps/pep-0012.html The in-development version of the documentation for Python can be found at http://www.python.org/dev/doc/devel/ and should be used when looking up any documentation on something mentioned here. Python PEPs (Python Enhancement Proposals) are located at http://www.python.org/peps/ . To view files in the Python CVS online, go to http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/ . .. _python-dev: http://www.python.org/dev/ .. _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev .. _comp.lang.python: http://groups.google.com/groups?q=comp.lang.python .. _Docutils: http://docutils.sf.net/ .. _reST: .. _reStructuredText: http://docutils.sf.net/rst.html .. contents:: .. _last summary: http://www.python.org/dev/summary/2003-06-01_2003-06-30.html ===================== Summary Announcements ===================== It's experimentation time again! In preparation for having to cut down on the breadth of the summary thanks to my return to school I am starting this summary off as the inaugural release of the new format. Pretty much everything is going to change somewhat. First, though, I think I should explain my new viewpoint towards the summaries that I am taking. In order to continue to provide a certain level of quality and coverage while retaining my personal sanity and to not feel like the Summaries are a job instead of something I do for fun and to help others, I am going to start viewing the Summaries more from a journalistic perspective than a historical one. Before I felt more like a historian that was summarizing *everything* that happened on python-dev. Now, though, I am be more like a journalist, covering only the pertinent ideas. This also allows me to inject more of my personality into my writing. But what ramifications does this new perspective cause? Well, it will dictate what I do and do not summarize. I plan on several types of discussions to be covered in the Summaries. One is new features of the language. This is so people can know about them ASAP and thus comment on them. Since practically any feature mentioned here is experimental there is a chance to remove it if a community movement mounts. I will also cover any major thinking on the future of Python. I have always wished there was an easy way to see what pie-in-the-sky ideas python-dev was thinking of in the back of our collective mind; the summaries might as well fill this desire. And of course any random discussion that is large, important, and/or complex will continue to be covered. In terms of formatting and layout, that will also change along with the new viewpoint. I am planning to follow something more along the lines of the Perl's `This Week... <http://dev.perl.org/perl6/list-summaries/>`__; yes, I am taking a cue from Perl but AM Kuchling and Michael Hudson originally used this format as well. This means titles of summary sections will more reflect the topic being summarized rather than the specific thread(s). I will continue to list all of the threads that contributed to the summary, though, for reference purposes. I feel this will be beneficial since I know I have personally looked back into the Summary archives and had a hard time finding something specific since the subject of a thread does not always match the topic of discussion; if I can't find something and I know about what month it happened I can only imagine what everyone else has had to go through to find something! I am removing the Quickies section from the Summaries. This section was nice to have, but it just ate away at my time. This also goes along with the new viewpoint. I am sure not everyone will be happy with this change, that's fine. But if someone out there *truly* hates the direction I am going then they can step forward and take the reigns from me. But as I have stated before, the fine print on me giving up this post is that the person who takes over must be as thorough as I *used* to be; I can do the summaries in a half-assed fashion as well as anyone else. Enough of that topic. One thing I would like to mention is that the `Python Software Foundation`_ can now accept donations through PayPal. Specifics can be found at http://www.python.org/psf/donations.html . It would be great if people could donate since the PSF is more than just a non-profit to hold the Python intellectual property. One of the goals of the group is to get enough money to do something like the Perl Foundation does and sponsor someone to hack on Python for a living for a set amount of time. Right now we are a ways off from having that kind of revenue, but there is no reason why we can't. Heck, if we can just get enough to sponsor one person to do full-time Python hacking for a week it would be beneficial. Or better yet, the PSF could sponsor one of their own members to write a summary of the python-dev mailing list for the betterment of the community. =) .. _PSF: .. _Python Software Foundation: http://www.python.org/psf/ .. _PayPal: http://www.paypal.com/ ========= Summaries ========= -------------------------- Python 2.3 final released! -------------------------- In case for some odd reason you didn't know, Python 2.3 final has gone out the door. The team managed to meet the goal of getting it out by the end of the month so that Apple_ can use a final release instead of a release candidate in OS X 10.3 (a.k.a. Panther). The goal of this release was to continue to improve Python without adding any new keywords. This was met while speeding things up, fixing bugs, adding to the standard library, and adding some new built-ins. To find out what is new or has changed look at the changelog at http://www.python.org/2.3/highlights.html or `What's New in Python 2.3`_. As with all software, there are bound to be bugs. What bugs that are known are listed at http://www.python.org/2.3/bugs.html . If you find bugs not listed there, please report them on the SourceForge bug tracker at http://sourceforge.net/tracker/?group_id=5470&atid=105470 . Running the regression test suite (details on how to do this is covered in the documentation for the 'test' package as found at http://www.python.org/doc/current/lib/module-test.html) is always appreciated. Contributing threads: - `Problem with 2.3b2 tarfile?`__ - `MacPython 2.3b2 binary installer for MacOSX`__ - `Running tests on freebsd5`__ - `Python 2.3 release schedule update`__ - `Vacation and possibly a new bug`__ - `Doc/ tree closes at noon, US/Eastern`__ - `I've tagged the tree`__ - `cygwin errors`__ - `test_strptime; test_logging; test_time failure`__ - `2.3rc1 delayed`__ - `Python 2.3 release candidate 1`__ - `post-release festivities`__ - `New branch for r23c2 work`__ - `Serious CallTip Bug in IDLE`__ - `MacPython-OS9 test failures`__ - `Doc/ tree on trunk closed`__ - `Cutting the 2.3c2 tonight 8pm EDT`__ - `Re: [Python-checkins] python/dist/src/Misc NEWS,1.826,1.827`__ - `RELEASED Python 2.3c2`__ - `2.3rc2 IDLE problems on a Win2000sp3 box`__ - `Draft: 2.3 download page`__ - `Last priority >= 7 bug for Python 2.3`__ - `CVS Freeze`__ - `RELEASED Python 2.3 (final)`__ __ http://mail.python.org/pipermail/python-dev/2003-July/036669.html __ http://mail.python.org/pipermail/python-dev/2003-July/036732.html __ http://mail.python.org/pipermail/python-dev/2003-July/036762.html __ http://mail.python.org/pipermail/python-dev/2003-July/036783.html __ http://mail.python.org/pipermail/python-dev/2003-July/036845.html __ http://mail.python.org/pipermail/python-dev/2003-July/036892.html __ http://mail.python.org/pipermail/python-dev/2003-July/036899.html __ http://mail.python.org/pipermail/python-dev/2003-July/036900.html __ http://mail.python.org/pipermail/python-dev/2003-July/037117.html __ http://mail.python.org/pipermail/python-dev/2003-July/036921.html __ http://mail.python.org/pipermail/python-dev/2003-July/036940.html __ http://mail.python.org/pipermail/python-dev/2003-July/036941.html __ http://mail.python.org/pipermail/python-dev/2003-July/037024.html __ http://mail.python.org/pipermail/python-dev/2003-July/037134.html __ http://mail.python.org/pipermail/python-dev/2003-July/037144.html __ http://mail.python.org/pipermail/python-dev/2003-July/037193.html __ http://mail.python.org/pipermail/python-dev/2003-July/037200.html __ http://mail.python.org/pipermail/python-dev/2003-July/037207.html __ http://mail.python.org/pipermail/python-dev/2003-July/037208.html __ http://mail.python.org/pipermail/python-dev/2003-July/037237.html __ http://mail.python.org/pipermail/python-dev/2003-July/037284.html __ http://mail.python.org/pipermail/python-dev/2003-July/037311.html __ http://mail.python.org/pipermail/python-dev/2003-July/037315.html __ http://mail.python.org/pipermail/python-dev/2003-July/037319.html .. _Apple: http://www.apple.com/ .. _What's New in Python 2.3: http://www.python.org/doc/2.3/whatsnew/ ------------------------------------------- String Exceptions Going Extinct, Eventually ------------------------------------------- It has been brought several times before, but things are now moving along to eventually deprecated string exceptions (e.g., ``raise "this string exception"``). they have now been removed from the tutorial to prevent people new to the language from picking up habits that will eventually be impossible to perform. As for when the impending deprecation will occur only Guido knows. The chances of it coming before Python 3, though, is most likely small. Contributing threads: - `String exceptions in the Tutorial`__ __ http://mail.python.org/pipermail/python-dev/2003-July/036665.html -------------------------------------------------------- Someday, My CVS updates Will Succeed on the First Try... -------------------------------------------------------- We all know that SourceForge_ does not have the snappiest or most reliable CVS_ servers in the world; Python 2.3 final's release was targeted a few days earlier than needed for Apple_ in case SF's CVS went down. Solutions to how to deal with this problem have come up. One specific problem that people are trying to solve is the poor anonymous pserver access. SF has their CVS servers set up so that authorized CVS commands take priority over anonymous ones and thus when there is heavy traffic anonymous CVS basically shuts down. Martin v. Löwis put up a link to a nightly tarball at http://www.dcl.hpi.uni-potsdam.de/home/loewis/python.tgz of the CVS HEAD. perl.org has provided a nightly tarball as well at http://cvs.perl.org/snapshots/python/ for quite some time now. The suggestion of having a read-only version of the CVS tree on python.org was came up, but how to properly do it and who would set it up was not settled. And of course there is always the option of moving CVS off of SF entirely. There is one offer on the table with the caveat that we need to know what kind of bandwidth demands we would have. Another offer sprung up this month from Michal Wallace to host our CVS at http://www.versionhost.com/ with the hitch that the server would be pserver only which would thus most likely only work for anonymous checkouts Contributing threads: - `alternate pserver access for python CVS?`__ - `[fwd] SourceForge status`__ - `Volunteering to help with pserver cvs on python.org`__ __ http://mail.python.org/pipermail/python-dev/2003-July/036699.html __ http://mail.python.org/pipermail/python-dev/2003-July/036708.html __ http://mail.python.org/pipermail/python-dev/2003-July/036860.html .. _SourceForge: http://www.sf.net/ .. _CVS: http://www.cvshome.org/ --------------------- Which License to Use? --------------------- Domenico Andreoli wanted to donate `python-crack`_ to the PSF_ and wondered what steps would be necessary to do so. He was first told that the module would not be included in Python since it is too specific. Secondly, it was suggested he not choose the PSF license. Instead, he was told that he should use the BSD or MIT license (both of which can be found at http://www.opensource.org/licenses/index.php); clean, simple licenses that are not viral like the GPL but are GPL-compatible. This is so that it can be included in any software that uses Python. Contributing threads: - `donating python-crack module`__ __ http://mail.python.org/pipermail/python-dev/2003-July/036712.html .. _python-crack: http://savannah.nongnu.org/projects/python-crack ---------------- Not Quite ANSI C ---------------- Every so often someone runs Python against a C code checker and notices failures that get reported to us. Often, though, we have to tell the person that we already know of the failures and that there is nothing to worry about. This time it was failures under Purify. We have also received reports of failures under Valgrind_ which are spurious. The language isn't even fully ANSI C compliant, but as Tim Peters said, "it's not possible to write a useful and portable memory allocator in 100% standard ANSI C" among other reasons why strict ANSI C conformity is broken. The only major violations in the code are casting a pointer to a unsigned integer type and assuming "that whatever memory protection gimmicks an OS implements are at page granularity" which is a minor sin at best. There is also some cases of accessing memory without proper casting. Contributing threads: - `Invalid memory read in PyObject_Free`__ - `strict aliasing and Python`__ __ http://mail.python.org/pipermail/python-dev/2003-July/036717.html __ http://mail.python.org/pipermail/python-dev/2003-July/036898.html .. _Valgrind: http://developer.kde.org/~sewardj/ --------------------------------------- Shadowing Built-ins is Becoming a No-No --------------------------------------- Before the code was removed, Python 2.3 raised a DeprectionWarning when you overshadowed a built-in in a module from outside the module's actual code. What this means is that doing something like:: import mod mod.reload = 42 would raise the warning. Now doing ``reload = 42`` in the module itself would still be allowed. The idea was (and still is) that the compiler can know when a built-in is shadowed in a module when it compiles the module's code. But allowing someone to overwrite a built-in externally means that the compiler cannot make any assumptions that built-ins will forever reference the actual built-in code. This is unfortunate since if shadowing externally was made illegal the compiler can reference the built-in code directly and skip some steps for a nice speed-up. This is why there was code to warn against this initially. But it didn't work well enough to be left in Python 2.3 so it has been removed. But this restriction will most likely be enforced at some point so it is something to keep in mind. Contributing threads: - `Deprecation warning 'assignment shadows builtin'`__... - `DeprecationWarning: assignment shadows builtin`__ __ http://mail.python.org/pipermail/python-dev/2003-July/036767.html __ http://mail.python.org/pipermail/python-dev/2003-July/036879.html ------------------------ Must...Start...Faster... ------------------------ While Python 2.3 sees up to a 30% speed increase over 2.2, it still starts up slower. Originally it was believed that it was because of the importation of the re module. Marc-André Lemburg applied a patch that tried to minimize its possible importation at startup but it was still slow. Jeremy Hylton pointed out that 2.2.3 imported re so that probably was not the problem. One thing that is different, though, is the automatic inclusion of warnings, codecs, and the ability to do zip imports. These three things pull more modules and all of this leads to a longer startup time. There is also the importation of distutils thanks to the site.py module, but that only occurs if you execute in a build directory. Including zip imports also got attacked for the number of failed checks for files it can incur. But it is believed this is not as bad as all of the extra imports being done now and Just van Rossum said he would try to cut down the unneeded checks in the future. Contributing threads: - `2.3 startup speed?`__ __ http://mail.python.org/pipermail/python-dev/2003-July/036815.html --------------------- The World and Numbers --------------------- People might not be aware of it, but locale.setlocale never changes the LC_NUMERIC locale value. This is so that 'str' and 'float' can return and receive numbers in a consistent way in source code. This causes a problem, though, for people in locales that do not use a period for a decimal point. If you had your locale set to Brazilian and tried to pass the string "3,14" to 'float' it would fail even though that is a legitimate number representation for your locale. The suggestion become to have a locale-agnostic version of 'str' and 'float' in the locale module for people to use when they needed such functionality. It has now reached the stage of a rough draft PEP as found at http://mail.python.org/pipermail/python-dev/2003-July/036996.html . Contributing threads: - `LC_NUMERIC and C libraries`__ - `Be Honest about LC_NUMERIC`__ - `RE: [Spambayes] Question (or possibly a bug report)`__ __ http://mail.python.org/pipermail/python-dev/2003-July/036869.html __ http://mail.python.org/pipermail/python-dev/2003-July/036996.html __ http://mail.python.org/pipermail/python-dev/2003-July/037178.html --------------- Zippin' Nothin' --------------- The built-in 'zip' function in Python 2.3 raises TypeError when given no arguments. This causes problem when you do ``zip(*args)`` and args is empty. So for Python 2.4 'zip' with no arguments will return an empty list. Contributing threads: - `zip() in Py2.4`__ __ http://mail.python.org/pipermail/python-dev/2003-July/037332.html -------------------------------- A Syntax For Function Attributes -------------------------------- An old debate (or at least old in terms of it having popped up multiple times during the tenure of your author) has been ways of enhancing function definitions. Previously it has been over ways to make defining classmethod and its ilk in a cleaner fashion along with properties (past summaries on this can be found at http://www.python.org/dev/summary/2003-01-16_2003-01-31.html#extended-funct… and http://www.python.org/dev/summary/2003-02-01_2003-02-15.html#extended-funct… ). What made the discussion slightly different this time, though, was the focus was on function attributes specifically. One idea was to tweak Michael Hudson's bracket syntax for method annnotations to allow for function attributes; ``def foo() [bar=42]: pass``. Another suggestion was to take the dictionary-like connection even farther; ``def foo() {bar=42}: pass``. There was no clear winner in either case partially because this discussion flared up towards the end of the month. It was also pointed out that using Michael Hudson's method descriptors you could come up with a wrapping function that handled the situation:: def attrs(**kw): def _(func): for k in kw: setattr(func, k, kw[k]) return func return _ def foo() [attrs(bar=42)]: pass Perk of this is it does not lead to any special syntax just for function attributes. One drawback, though, as pointed out by Paul Moore is that this makes the method annotation idea a little to liberal and open to hackish solutions like this that will lead to abuse. This was not a huge worry, though, since almost anything can be abused and this is all already doable now, just without a nice, clean syntax. Contributing threads: - `A syntax for function attributes?`__ __ http://mail.python.org/pipermail/python-dev/2003-July/037338.html

2 2

Document Lib/platform.py ?
by Brett C. 04 Aug '03

04 Aug '03

While skimming the "What's New" doc for 2.3 I noticed the mention of the platform module. After noticing that there were no docs for it, I checked out the module and noticed that the docstrings are pretty good as-is. So, the question becomes whether it is okay for me to write up some LaTeX docs for Fred to correct. The only reason I am asking instead of just writing the thing up is I know once it is documented it is considered "official" and thus require maintenance and support and I don't know if we want to bother with that. Marc-Andre has already given me the green light to write the docs but I wanted python-dev's go-ahead before I proceeded. -Brett

3 4

PyCon DC 2004 Kickoff!
by PyCon Committee 04 Aug '03

04 Aug '03

[Posted to comp.lang.python/python-list, comp.lang.python.announce, zope-announce, pycon-announce, and python-dev.] [Please repost to local Python mailing lists.] Planning for PyCon DC 2004, the Python community conference, is now underway. DC 2004 will be held March 24-26, 2004 in Washington, D.C. It will contain many of the features of this year's successful conference, including a development sprint and a similar cost structure. Registration will be open by October 1. A Call For Proposals will be issued in the next two weeks. Presentations will be required in electronic form for publication on the web. PyCon DC 2003 had a broad range of presentations, from reports on academic and commercial projects to tutorials and case studies, and these will all be included in the Call For Proposals. As long as the presentation is interesting and potentially useful to the Python community, it will be considered for inclusion in the program. There will again be a significant amount of Open Space to allow for informal and spur-of-the-moment presentations for which no formal submission is required. There will also be several Lightning Talk sessions. These informal sessions are opportunities for those who don't want to make a formal presentation. We're looking for volunteers to help run PyCon. If you're interested, subscribe to http://mail.python.org/mailman/listinfo/pycon-organizers Don't miss any PyCon announcements! Subscribe to http://mail.python.org/mailman/listinfo/pycon-announce You can discuss PyCon with other interested people by subscribing to http://mail.python.org/mailman/listinfo/pycon-interest The central resource for PyCon DC 2004 is http://www.python.org/pycon/dc2004/ -- Aahz (aahz(a)pythoncraft.com) <*> http://www.pythoncraft.com/ This is Python. We don't care much about theory, except where it intersects with useful practice. --Aahz

1 0