Mailman 3 May 2004 - Python-Dev

Fwd: OSCON discount for core contributors
by Kevin Altis 10 May '04

10 May '04

OSCON will be held at the Portland Marriott Downtown in Portland, Oregon, July 26-30, 2004. Gina Blaber at O'Reilly is offering a special 20% discount for 20 core Python developers. Anyone on python-dev qualifies, so we'll handle this as first-come, first-served. Note that if you have attended OSCON in the past you are already qualified for a 20% alumni discount in addition to the 20% early bird discount, so you don't need to use this special developer discount. If you qualify for the academic discounts, then those are better discount deals, and again you don't need to use this developer discount code. Regardless of which discount you use, if you plan to attend OSCON, you'll definitely save on registration by registering before June 18, 2004 for an additional 20% early bird discount. Registration: http://conferences.oreillynet.com/pub/w/29/register.html OSCON site: http://conferences.oreillynet.com/os2004/ Python 12 track at OSCON: http://conferences.oreillynet.com/pub/w/29/track_python.html http://conferences.oreillynet.com/pub/w/29/tutorial_python.html Hope to see you in Portland in July, ka --- Kevin Altis altis(a)semi-retired.com http://altis.pycs.net/ Python 12 co-chair Begin forwarded message: > From: "Gina Blaber" <gina(a)oreilly.com> > Cc: gina(a)oreilly.com, lholder(a)oreilly.com > Subject: OSCON discount for core contributors > > Hi Kevin, > > O'Reilly would like to help the core contributors of important open > source software projects to attend OSCON. Therefore, I'd like to > offer a discount of 15% off the registration price to 20 core > contributors to Python. This discount can be combined with the 20% > Early Bird pricing, which ends June 18, 2004. > > The registration discount code for the 20 core contributors to use is > os04py. I've cc'ed Linda Holder on this message; Linda can answer > any registration questions you may have. > > Thanks, and I look forward to seeing you at OSCON! > > -Gina Blaber >

1 0

RE: [Python-Dev] Is core dump always a bug? Advice requested
by Robert Brewer 10 May '04

10 May '04

Terry Reedy wrote: > > The following was posted in the last 25 hours on c.l.p: > > "Xaver Hinterhuber" <xaver_hinterhuber(a)web.de> wrote in message > news:c7o6al$i1j$1@online.de... > > codeObject = new.code( > > 0, # argcount > > 0, # nlocals > > 0, # stacksize > > 0, # flags > > codeString, # code > > (), # consts > > (), # names > > (), # varnames > > 'content', # filename > > 'content', # name > > 3, # first line number > > codeString # lnotab > > ) > > f = new.function(codeObject, dict, 'f') > > f() > > > > Everything runs fine, until the function is called with f(). > > When python tries to execute f(), the core dump happens. > > I don't have any clue why python core dumps. > > The codeString is nothing complex, its a one-liner. > > ... but, as too typical of new posters, not posted ;-) > > My question: I understand that core dumping by the Python > interpreter is > normally considered a bug -- one that should be reported on SF -- and > fixed. But does that principle apply to this sort of use (or probably > abuse) of the new module. In other words, does the 'no core > dump' contract > include a 'byte code compiled by the interpreter' proviso. > Or is ceval > intended to be robust against random strings masquerading as > valid byte > code (which would seem require an InvalidByteCode exception). > Or in still > other words, is there a bug that I should encourage reporting > of, or is > 'don't do that' the extent of a proper response? There are other problems; once I passed a unicode string in co_names--it took me quite a while to track down THAT mistake. :) Perhaps some more rigorous assertions, returning ValueErrors? If not in C, then in the 'new' module, since that seems to be the vector of disaster for Xaver, above. Perhaps this would also be an argument for keeping the 'new' module around longer, as a 'safer' Pythonic wrapper over bare code/function construction. Robert Brewer MIS Amor Ministries fumanchu(a)amor.org

1 0

Generator expression used in test suite?
by Nick Coghlan 10 May '04

10 May '04

I just finished setting up a Mandrake 9.2 box for Python development, and got a doctest failure in test_deque (after running ./configure, make, make test). It looks like one of the examples (roundrobin) is using a generator expression to populate the deque. Since this will work once generator expressions hit CVS, is there any point in raising a bug report for it? Regards, Nick. -- Nick Coghlan | Brisbane, Australia Email: ncoghlan(a)email.com | Mobile: +61 409 573 268

2 2

SF Bug 933068 - Unexpected result from super() call
by Nick Coghlan 10 May '04

10 May '04

This bug report can probably be closed (the reported error is the result of supplying 'self' an an argument to the already bound method returned from the super call). The relevant docs for super looked fairly clear to me, too, so I don't think it is a documentation bug, either. Regards, Nick. -- Nick Coghlan | Brisbane, Australia Email: ncoghlan(a)email.com | Mobile: +61 409 573 268

1 0

PEP 328: import...as with relative import
by Greg Ewing 09 May '04

09 May '04

There's been some discussion on c.l.py about whether the new relative import system should allow things like import ..abc as def It seems the PEP currently disallows this, but nobody seems to be able to adequately explain why. Is there any technical reason it couldn't be done? Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg(a)cosc.canterbury.ac.nz +--------------------------------------+

5 7

RE: [Python-Dev] python-dev Summary for 2004-04-01 through 2004-04-30[rough draft]
by Robert Brewer 09 May '04

09 May '04

Brett C wrote Yet Another Great Summary: > Subject: [Python-Dev] python-dev Summary for 2004-04-01 > through 2004-04-30[rough draft] > > I would like to get this out Wednesday night, so please send in your > corrections by then. Thanks. >8 > -------------------- > stdlib: Python or C? > -------------------- > The question of whether stdlib modules should be coded in Python or C > came up again. Armin Rigo posted some numbers comparing > performance of > heapq using the Python version both in a stock Python > interpreter and in > Psyco_ and then the C version. Armin's quick timings showed that the > Python version of heapq was actually after than the C version > when used in Psyco. I think you mean "faster than" instead of "after than". >8 > ----------------------------------------- > Moving forward with generator expressions > ----------------------------------------- >8 > > What people did was the whole thing about late bindings period. I don't understand this sentence. HTH, Robert Brewer MIS Amor Ministries fumanchu(a)amor.org

1 0

python-dev Summary for 2004-04-01 through 2004-04-30 [rough draft]
by Brett C. 09 May '04

09 May '04

By not getting into any details on method decorators and relative imports I was actually able to finish this summary. =) I would like to get this out Wednesday night, so please send in your corrections by then. Thanks. ------------------------------- ===================== Summary Announcements ===================== Well, as you may have noticed, I wasn't able to keep up the pace of releasing the summaries twice in a month. Joys of school. Hopefully over the summer I will be able to semi-monthly releases since I will only be working and not have homework hanging over my head 24/7. To give everyone a a heads-up, a release candidate for Python 2.3.4 is going to be released May 13/14 (depending where you are on the globe). If you have time, please download it and run the regression test suite (instructions can be found in the module documentation for the 'test' package) and report any issues you have. ========= Summaries ========= -------------------------------------------------------- Method decorators and the discussion that will never end -------------------------------------------------------- Method decorators and `PEP 318`_ were discussed ad nausea this past month. Read the PEP for the updated details. .. _PEP 318: http://www.python.org/peps/pep-0318.html Contributing threads: - `PEP 318 -- a couple use cases <http://mail.python.org/pipermail/python-dev/2004-April/043902.html>`__ - `PEP 318: Decorators last before colon/bakeoff <http://mail.python.org/pipermail/python-dev/2004-April/043911.html>`__ - `PEP 318 bake-off? <http://mail.python.org/pipermail/python-dev/2004-April/043952.html>`__ - `PEP 318: Is decorators the right term for these things? <http://mail.python.org/pipermail/python-dev/2004-April/043973.html>`__ - `Re: PEP 318: Let's propose some useful built-in decorators <http://mail.python.org/pipermail/python-dev/2004-April/043975.html>`__ - `Help with PEP 318 <http://mail.python.org/pipermail/python-dev/2004-April/044011.html>`__ - `PEP 318: Properties <http://mail.python.org/pipermail/python-dev/2004-April/044012.html>`__ - `PEP 318: More examples of decorator use <http://mail.python.org/pipermail/python-dev/2004-April/044132.html>`__ - `PEP 318: How I would implement decorators <http://mail.python.org/pipermail/python-dev/2004-April/044133.html>`__ - `PEP 318 - check for consensus <http://mail.python.org/pipermail/python-dev/2004-April/044251.html>`__ ------------------------------------------------------------ Relative imports: the *other* discussion that will never end ------------------------------------------------------------ `PEP 328`_, which covers relative imports, has been updated to cover its lengthy discussion. It seems the PEP is pretty much finalized. .. _PEP 328: http://www.python.org/peps/pep-0328.html Contributing threads: - `Re: PEP 328 -- relative and multi-line import <http://mail.python.org/pipermail/python-dev/2004-April/043978.html>`__ - ` Some comments on PEP 328 (absolute/relative imports) <http://mail.python.org/pipermail/python-dev/2004-April/043998.html>`__ - `PEP 328: __path__ <http://mail.python.org/pipermail/python-dev/2004-April/044017.html>`__ - `from ...sys import path <http://mail.python.org/pipermail/python-dev/2004-April/044024.html>`__ -------------------- stdlib: Python or C? -------------------- The question of whether stdlib modules should be coded in Python or C came up again. Armin Rigo posted some numbers comparing performance of heapq using the Python version both in a stock Python interpreter and in Psyco_ and then the C version. Armin's quick timings showed that the Python version of heapq was actually after than the C version when used in Psyco. If it is possible to get the Python version to go faster, should it and future modules be coded in Python? The usual arguments over maintenance and readability were brought up. In the end the Python version of heapq was put back into the library with the C version renamed to _heapq. Contributing threads: - `Python is faster than C <http://mail.python.org/pipermail/python-dev/2004-April/044054.html>`__ ----------------------------------- Getting an Interest Group on Artima ----------------------------------- Bill Venners of Artima_ asked if there was anyone who wanted to act as a moderator for an interest group for Python on the site. If you are interested, read the email for details. .. _Artima: http://www.artima.com/ Contributing threads: - `Python Interest Group <http://mail.python.org/pipermail/python-dev/2004-April/044131.html>`__ ------------------------------- Informative reprs for iterators ------------------------------- Raymond Hettinger suggested having the repr of iterators for built-in types list the first three objects returned by the iterator. That way you would actually know what was in the iterator. It was suggested only for iterators where the length of the iterator was known and extracting the first three objects from the iterator to display them would be cheap. In the end, though, it was not added for built-in types. Some itertools iterators, though, did get more informative reprs. Contributing threads: - `More imformative iterator representations <http://mail.python.org/pipermail/python-dev/2004-April/044136.html>`__ - `Proposed iterator representations <http://mail.python.org/pipermail/python-dev/2004-April/044166.html>`__ ------------------------------ Turning globals into constants ------------------------------ Raymond Hettinger came up with some code that could take a code object and make all globals constants, thus speeding up access. It was proposed for the stdlib in `PEP 329`_, but was rejected in the end for being too "hackish". It did bring up the idea of trying to come up with a way to flag built-ins that might be masked. If the compiler knew what built-ins were not going to be masked a direct lookup in the built-in namespace would be all that was needed to access a built-in. As it stands now, though, since an external module could inject a shadowing function into the global namespace of a module (such as having module bar having the code ``import foo; foo.len = lambda x: 42`` to shadow 'len' in the module foo), Python has to check the global namespace first, and then the built-in namespace for all non-local name accesses. That is costly and it could possibly be avoided since the common case is to not shadow a built-in. Guido suggested having programmers have to specify when a built-in could be shadowed. This could be compared to the 'volatile' keyword in C; the programmer has to specify when the compiler should not try to optimize access. This seemed like the best way to go since forcing the programmer to flag when a built-in will *not* be shadowed would be more work for the common case. Obviously this would all break backwards-compatibility and thus would either require a __future__ statement initially or would be like true division and always be a __future__ import until Python 3.0 . But it was all just being thrown around with no concrete ideas on implementation and such. .. _PEP 329: http://www.python.org/peps/pep-0329.html Contributing threads: - `Candidate Function Decorator <http://mail.python.org/pipermail/python-dev/2004-April/044204.html>`__ - `PEP 329: Treating Builtins as Constants... <http://mail.python.org/pipermail/python-dev/2004-April/044396.html>`__ - `peps 329, 266, 267 <http://mail.python.org/pipermail/python-dev/2004-April/044492.html>`__ ----------------------------- Decimal "stuff" was discussed ----------------------------- Two big topics came up about the Decimal package. The first one was over whether there should be an exponent limit. The discussion went back and forth, but in the end it was decided that having a limit is good since it will prevent undetected overflow and underflow. The second topic was about adding extra methods. This was shot down since the point of the Decimal module is to follow the standard as put forth at http://www2.hursley.ibm.com/decimal/decarith.html . After the module has been in the library and seen some wide usage then possible additions beyond the standard could be made. exponent limit repr (passable to eval if possible) sticking to spec initially Contributing threads: - `Decimal data type issues <http://mail.python.org/pipermail/python-dev/2004-April/044208.html>`__ - `Decimal conversion to string <http://mail.python.org/pipermail/python-dev/2004-April/044269.html>`__ - `Decimal - context manipulation <http://mail.python.org/pipermail/python-dev/2004-April/044485.html>`__ ------------------------------------------------- Magic hashing numbers segues into JIT compilation ------------------------------------------------- Raymond Hettinger suggested using a different number for hashing since it could be expressed in shifts and additions. But Tim Peters said it was a bad idea to futz with the number since the current one had proven its usefulness for so long. Since part of the justification for changing to another number was the number of cycles it would take to do the calculations, the discussion shifted to JIT compilation. Clarification for JIT compared to specialized compilation (former does single compiled version of a function while the latter does multiple versions based on the argument types) came up along with wondering how some of the optimizations used in the Self_ language could be applied to Python. .. _Self: http://research.sun.com/self/language.html Contributing threads: - `String hash function multiplier <http://mail.python.org/pipermail/python-dev/2004-April/044235.html>`__ - `Optimization targets - refcount <http://mail.python.org/pipermail/python-dev/2004-April/044304.html>`__ ---------------------------------- Modules that need some documentin' ---------------------------------- Yours truly compiled a list of modules that need documentation that can be found both in the email starting this thread (although I made one mistake on that list of including the imp module) or at http://www.python.org/cgi-bin/moinmoin/ModulesThatNeedDocs where Michael Chermside was nice enough to put it on up on the wiki. Writing docs for modules is not that hard and is a great way to help out. See http://www.python.org/dev/doc/devel/doc/doc.html on how to do documentation using LaTeX. And if that scares you, even just writing the docs in reST_ is helpful since someone else can volunteer to convert it to LaTeX. Contributing threads: - `Possible modules that could use docs <http://mail.python.org/pipermail/python-dev/2004-April/044392.html>`__ -------------------------------------- A change in the name of the CVS server -------------------------------------- SourceForge_ started forcing people to use cvs.sf.net:/cvsroot/python as the location of the CVS server as compared to the previously supported (but not "official") path of cvs.python.sf.net:/cvsroot/python . Barry Warsaw posted a Python script by Greg Ward that would traverse a CVS checkout and change the name of the CVS server. That script can be found at http://mail.python.org/pipermail/python-dev/2004-April/044593.html . Contributing threads: - `SSH problems getting into SourceForge's CVS? <http://mail.python.org/pipermail/python-dev/2004-April/044592.html>`__ --------------------------- A ConfigParser replacement? --------------------------- Dan Gass presented his `config.py`_ to python-dev to see if there was any interest in adding it. While he was given the standard response that no new modules will be accepted for inclusion in the stdlib until it has seen widespread acceptance and use by the community, Barry Warsaw suggested a possible ConfigParser replacement shootout ala the `getopt-sig`_ and how it was decided that optparse (aka Optik_) should be the suggested command-line parser used. This won't happen for 2.4, but if people are interested enough this could be done for 2.5 if someone decides to spear-head this. People also immediately pointed out ZConfig_ (by our very own Fred Drake) as another possibility. .. _config.py: http://config-py.sf.net/ .. _getopt-sig: http://mail.python.org/mailman/listinfo/getopt-sig .. _Optik: http://optik.sourceforge.net/ .. _ZConfig: http://www.zope.org/Members/fdrake/zconfig/ Contributing threads: - `Proposal: A more powerful alternative to ConfigParser <http://mail.python.org/pipermail/python-dev/2004-April/044520.html>`__ - `Proposal: A more powerful alternativeto... <http://mail.python.org/pipermail/python-dev/2004-April/044529.html>`__ ----------------------------------------- Moving forward with generator expressions ----------------------------------------- Guido said he wanted to get generator expressions into CVS. While this is good and all, it still doesn't address the whole argument over whether early or late binding for variables in the genexps should be used (in case you have not been following, early binding would have a genexp save the state of the variables used in the genexp at creation time while late binding will use the state of the variables at the time of each execution of the genexp). Since Guido prefers the late binding for simplicity, he suggested using it for 2.4a1 and a2. If it was found that late binding was bad then for 2.4b1 early binding could be used. No one had issues with that idea. What people did was the whole thing about late bindings period. Basically the issue boils down to whether late binding is too much of a surprise for the cases where they can have issues. But Greg Ewing pointed out that the use case that genexps were being created for were for arguments to functions; a use case where the genexp is used immediately and whose possible abuse of variables would not be an issue. It was realized that genexps are not exactly the same as listcomps and thus not a direct replacement. Genexps are meant for places where memory is going to be an issue; if a listcomp would do just a good of a job, then just go ahead and use a listcomp. Contributing threads: - `PEP 289 - Generator Expressions - Let's Move Forward <http://mail.python.org/pipermail/python-dev/2004-April/044555.html>`__ --------------------------------------------------- How should gettext return strings from an .mo file? --------------------------------------------------- Gustavo Niemeyer noticed that if you called 'gettext.gettext' it would return the exact bytes stored in the .mo file. Apparently `GNU gettext`_ translates the bytes according to the current locale instead of just passing them through untouched. Gustavo wanted to make Python match the GNU implementation. Barry Warsaw and Martin v. Loewis disagreed, though. Since Python's way of doing it has been that way for so long, they didn't want to break backwards-compatibility. It was also stated that code should use 'gettext.ugettext' anyway. In the end it was agreed upon that if Gustavo wanted this functionality he should add another function to 'gettext' (such as 'lgettext') that did what he wanted. .. _GNU gettext: http://www.gnu.org/software/gettext/gettext.html Contributing threads: - `Small issues in gettext support <http://mail.python.org/pipermail/python-dev/2004-April/044569.html>`__ ----------------------------------------------- And how long have you been hacking on the core? ----------------------------------------------- Anthony Baxter, fearless release manager, decided to run the Misc/ACKS file through ``cvs annotate`` which prints out who edited every line and when it was edited and then he sorted it. This was to see when people were added to the ACKS file and thus find our roughly how long people have been hacking on the Python core. The file wasn't started until January 26, 1994 so a lot of the "old-timers" don't have exact dates (of which Anthony is one of them). Yours truly was added on July 19, 2002. Contributing threads: - `today's pointless, yet slightly terrifying, factoid(s) <http://mail.python.org/pipermail/python-dev/2004-April/044574.html>`__

1 0

Source of the FAQ?
by Matthias Klose 09 May '04

09 May '04

Is the source text for the FAQ's available in some form, that could be included in a packaged form for distribution? Thanks, Matthias

2 1

RE: [Python-Dev] Re: New Subscriber
by Batista, Facundo 07 May '04

07 May '04

[Tim Peters] #- doesn't mean we all object to it <wink>. My advice is to #- read a bit first #- about how Python development gets done: #- #- http://www.python.org/dev/ David, I repost these Tim statements because as a new Python developer I found something amusing. If you follow the rules, you'll have a lot of valuable humans that donate their time to help you to help everybody. With follow the rules I mean to get used to how things get done here (for example: learn how to write a PEP, that is a wonderful tool). Welcome! . Facundo

1 0

what level of backward compatibility? how
by Jewett, Jim J 07 May '04

07 May '04

urlparse.py uses lists of strings to indicate which protocols have which properties. For instance: uses_relative = ['ftp', 'http', 'gopher', 'nntp', 'imap', 'wais', 'file', 'https', 'shttp', 'mms', 'prospero', 'rtsp', 'rtspu', ''] Logically, these are sets, rather than lists. CVS change 143 changed the lists to sets. Unfortunately, it breaks client code that did urlparse.uses_relative.append('my_protocol') which was as close to a documented API as existed. (1) Is this an OK breakage with the 2.4 switch? (2) If not, should this change be backed out, or replaced with some set subclass that takes a few of the list methods? -jJ

5 5