Mailman 3 June 2002 - Python-Dev

SF sending content-free emails
by Guido van Rossum 05 Jun '02

05 Jun '02

You may have noticed that the SF tracker is sending email that doesn't contain any content, when an item is updated. I've filed a bug report with SF. http://sourceforge.net/tracker/index.php?func=detail&aid=565001&group_id=1&… Gordon, how's the roundup project coming along? :-) --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

'compile' error message
by Thomas Heller 05 Jun '02

05 Jun '02

Consider: Python 2.3a0 (#29, Jun 5 2002, 13:09:10) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> compile("1+*3", "myfile.py", "exec") Traceback (most recent call last): File "<stdin>", line 1, in ? File "<string>", line 1 1+*3 ^ SyntaxError: invalid syntax >>> Shouldn't it print "myfile.py" instead of "<string>"? Thomas

4 4

xrange identity crisis
by Oren Tirosh 05 Jun '02

05 Jun '02

It seems that the xrange object in the current CVS can't make up its mind whether it's an iterator or an iterable: >>> iterables = ["", (), [], {}, file('/dev/null'), xrange(10)] >>> iterators = [iter(x) for x in iterables] >>> for x in iterables + iterators: ... print hasattr(x, 'next'), x is iter(x), type(x) ... False False <type 'str'> False False <type 'tuple'> False False <type 'list'> False False <type 'dict'> False False <type 'file'> True False <type 'xrange'> True True <type 'iterator'> True True <type 'iterator'> True True <type 'listiterator'> True True <type 'dictionary-iterator'> True True <type 'xreadlines.xreadlines'> True False <type 'xrange'> Generally, iterables don't have a next() method and return a new object each time they are iter()ed. Iterators do have a next() method and return themselves on iter(). xrange is a strange hybrid. In Python 2.2.0/1 xrange behaved just like the other iterables: >>> iterables = ["", (), [], {}, file('/dev/null'), xrange(10)] >>> iterators = [iter(x) for x in iterables] >>> for x in iterables + iterators: ... print hasattr(x, 'next'), x is iter(x), type(x) ... 0 0 <type 'str'> 0 0 <type 'tuple'> 0 0 <type 'list'> 0 0 <type 'dict'> 0 0 <type 'file'> 0 0 <type 'xrange'> 1 1 <type 'iterator'> 1 1 <type 'iterator'> 1 1 <type 'iterator'> 1 1 <type 'dictionary-iterator'> 1 1 <type 'xreadlines.xreadlines'> 1 1 <type 'iterator'> What's the rationale behind this change? Oren

6 16

Changes to PEP 8 & 42
by Neal Norwitz 04 Jun '02

04 Jun '02

I've also got a change to PEP 8 (for basestring). Is the wording ok? Should I check it in or should Barry/Guido? Also, it seems that PEP 42 is a bit out of date. I think the stat/statvfs changes may be done (at least started), the std library uses 4 space indents, math.radians/degrees were added. Probably others too. Neal -- Index: pep-0008.txt =================================================================== RCS file: /cvsroot/python/python/nondist/peps/pep-0008.txt,v retrieving revision 1.13 diff -C1 -r1.13 pep-0008.txt *** pep-0008.txt 29 May 2002 16:07:27 -0000 1.13 --- pep-0008.txt 3 Jun 2002 20:25:54 -0000 *************** *** 542,548 **** When checking if an object is a string, keep in mind that it ! might be a unicode string too! In Python 2.2, the types module ! has the StringTypes type defined for that purpose, e.g.: ! from types import StringTypes: ! if isinstance(strorunicodeobj, StringTypes): --- 542,547 ---- When checking if an object is a string, keep in mind that it ! might be a unicode string too! In Python 2.3, str and unicode ! have a common base class, basestring, so you can do: ! if isinstance(strorunicodeobj, basestring):

3 2

Python 2.3 release schedule
by Guido van Rossum 04 Jun '02

04 Jun '02

The Python 2.3 release schedule as laid out in PEP 283 is unrealistic. It has May 22 (yesterday) as the release date for 2.3a1, and then promises successive releases at approximately 4-week intervals. I think we're nowhere near doing the first alpha release. PythonLabs has been consumed by high priority Zope projects. There's a little less pressure now, and we can go back to thinking about Python releases, but we've lost a lot of time. We haven't even appointed a release manager! (Or the appointment was never recorded in the PEP.) In the discussion about release stability, it was brought up that the release schedule should be driven by feature completeness, not by the calendar. I basically agree, although I believe that when it takes the responsible party for a particular feature forever to implement it, it's better to move the feature to future release than to hold up the release forever. So let's discuss features for 2.3. PEP 283 mentions these: > PEP 266 Optimizing Global Variable/Attribute Access Montanaro > PEP 267 Optimized Access to Module Namespaces Hylton > PEP 280 Optimizing access to globals van Rossum (These are basically three friendly competing proposals.) Jeremy has made a little progress with a new compiler, but it's going slow and the compiler is only the first step. Maybe we'll be able to refactor the compiler in this release. I'm tempted to say we won't hold our breath for this one. > PEP 269 Pgen Module for Python Riehl I haven't heard from Jon Riehl, so I consider dropping this idea. > PEP 273 Import Modules from Zip Archives Ahlstrom I think this is close -- maybe it's already checked in and I don't know about it! > PEP 282 A Logging System Mick Vinay Sajip has been making steady progress on an implementation, and despite a recent near-flamewar (which I haven't followed) I expect that his code will be incorporated in the near future. That's it as far as what PEP 283 mentions (there's also a bunch of things already implemented, like bool, PyMalloc, universal newlines). Here are some ideas of my own for things I expect to see in 2.3a1: - Provide alternatives for common uses of the types module; essentially Skip's proto-PEP. - Extended slice notation for all built-in sequences. Wasn't Raymond Hettinger working on this? - Fix the buffer object??? http://mail.python.org/pipermail/python-dev/2002-May/023896.html - Lazily tracking tuples? Neil, how's that coming? http://mail.python.org/pipermail/python-dev/2002-May/023926.html - Timeoutsocket. Work in progress. http://mail.python.org/pipermail/python-dev/2002-May/024077.html - Making None a keyword. Can't be done right away, but a warning would be a first step. http://mail.python.org/pipermail/python-dev/2002-April/023600.html - Stage 2 of the int/long integration (PEP 237). This mostly means warning about situations where hex, oct or shift of an int returns a different value than for the same value as a long. (I think the PEP misses this step, but it's necessary -- we can't just change the semantics silently without warning first.) - I think Andrew Kuchling has a bunch of distutils features planned; how's that coming? - PEP 286??? (MvL: Enhanced argument tuples.) I haven't had the time to review this thoroughly. It seems a deep optimization hack (also makes better correctness guarantees though). - A standard datetime type. An implementation effort is under way: http://www.zope.org/Members/fdrake/DateTimeWiki/FrontPage Effbot and MAL have a proposal for a basic interface that all datetime types should implement, but there are some problems with UTC. A decision needs to be made. Anything else? --Guido van Rossum (home page: http://www.python.org/~guido/)

10 22

Draft Guide for code migration and modernation
by Raymond Hettinger 04 Jun '02

04 Jun '02

Here is my cut at the migration and modernization guide. Comments are welcome. Walter and Neal, would you like to add the somewhat more involved steps for eliminating the types and strings modules. Raymond Hettinger ----------------------------------------------- Code Modernization and Migration Guide Pattern: if d.has_key(k): --> if k in d: Idea: For testing dictionary membership, use the 'in' keyword instead of the 'has_key()' method. Version: 2.2 or greater Benefits: The result is shorter and more readable. The style becomes consistent with tests for membership in lists. The result is slightly faster because has_key requires an attribute search. Locating: grep has_key Contra-indications: 1. if dictlike.has_key(k) ## objects like shelve do not define __contains__() Pattern: for k in d.keys() --> for k in d for k in d.items() --> for k in d.iteritems() for k in d.values() --> for k in d.itervalues() Idea: Use the new iter methods for looping over dictionaries Version: 2.2 or greater Benefits: The iter methods are faster because the do not have to create a new list object with a complete copy of all of the keys, values, or items. Selecting only keys, items, or values as needed saves the time for creating unused object references and, in the case of items, saves a second hash look-up of the key. Contra-indications: 1. def getids(): return d.keys() ## do not change the return type 2. for k in dictlike.keys() ## objects like shelve do not define itermethods 3. k = d.keys(); j = k[:] ## iterators do not support slicing, sorting or other operations 4. for k in d.keys(): del[k] ## dict iterators prohibit modifying the dictionary Pattern: if v == None --> if v is None: Idea: Since there is only one None object, it can be tested with identity. Version: Any Benefits: Identity tests are slightly faster than equality tests. Also, some object types may overload comparison to be much slower (or even break). Locating: grep '== None' or grep '!= None' Pattern: os.stat("foo")[stat.ST_MTIME] --> os.stat("foo").st_mtime os.stat("foo")[stat.ST_MTIME] --> os.path.getmtime("foo") Idea: Replace stat contants or indices with new stat methods Version: 2.2 or greater Benefits: The methods are not order dependent and do not require an import of the stat module Locating: grep os.stat Pattern: import whrandom --> import random Idea: Replace deprecated module Version: 2.1 or greater Benefits: All random methods collected in one place Locating: grep whrandom

7 13

Adding Optik to the standard library
by Greg Ward 04 Jun '02

04 Jun '02

I think it's time to declare the work of the getopt-sig finished: several competing proposals were put forward, but Optik appears to be the only really complete, documented, field-tested (by someone other than its author) library. Not everyone on the getopt-sig will agree, but I think that's the broad consensus. Take this with a grain of salt, though -- I'm biased. ;-) Anyways, I think further consensus is needed on how precisely to add Optik to the standard library. The only constraint I've heard from Guido is to give it a less-cutesy name, which is fine by me. First, background: Optik consists of three modules: optik.option, optik.option_parser, and optik.errors, but that detail is hidden from users -- Optik applications normally just do this: from optik import OptionParser although there are a handful of other names that are occasionally useful to import from the 'optik' package: Option, SUPPRESS_HELP, OptionValueError, etc. Optik's __init__.py file is here: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/optik/optik/lib/_… It's only about 1100 lines, including docs and comments and blanks, so they could easily be merged into one module if people think that's preferable. So the main issues are 1) where those names should be imported from (interface), and 2) how the standard library should be rearranged to make this interface unobtrusive and efficient (implementation). I'm going to toss out ideas at random until I get bored. Please provide feedback and/or extra ideas on getopt-sig(a)python.org. IDEA #1: interface: from getopt import OptionParser # and the other Optik names implementation: * turn the getopt module into a package * put the current getopt.py into, say, getopt/classic_getopt.py * make getopt/__init__.py import everything from classic_getopt.py and Optik's three modules, so that either interface is there for the asking pros: * dead simple cons: * applications using just the classic getopt interface suddenly find themselves importing lots more code than they used to IDEA #2: interface: from getopt.option_parser import OptionParser, ... implementation: * as before, getopt.py becomes getopt/classic_getopt.py * getopt/__init__.py consists solely of "from classic_getopt import *" * Optik's three modules are copied into getopt, with the right imports added to getopt/option_parser.py so that applications don't have to worry about where Optik's other names come from pros: * only slightly more burden on apps now using classic getopt cons: * interface is a tad clunkier IDEA #3: interface: from getopt.option_parser import OptionParser, SUPPRESS_HELP, ... from getopt.option import Option from getopt.errors import OptionValueError implementation: * classic getopt handled the same as #2 * just dump Optik's three modules into getopt/ and be done with it pros: * dead simple cons: * clunky interface -- imports expose a lot of implementation detail IDEA #4: interface: same as #1 implementation: * same as #1, except use some funky import-time magic to ensure that the Optik code is only imported if someone actually needs it. Barry Warsaw provided a patch to do this: http://sourceforge.net/tracker/index.php?func=detail&aid=544175&group_id=38… pros: * more efficient for apps using classic getopt cons: * more complicated; apparently Guido expressed distaste for the import-time magic. I'm a little leery of it myself, although I have not carefully read the code. Preferences? Other ideas? Surely the right solution is out there somewhere, just beyond my reach... Greg -- Greg Ward - Unix geek gward(a)python.net http://starship.python.net/~gward/ "Passionate hatred can give meaning and purpose to an empty life." -- Eric Hoffer

12 36

RE: [Python-checkins] python/dist/src/Objects object.c,2.175,2.176
by Tim Peters 04 Jun '02

04 Jun '02

[Guido] > Modified Files: > object.c > Log Message: > Implement the intention of SF patch 472523 (but coded differently). > > In the past, an object's tp_compare could return any value. In 2.2 > the docs were tightened to require it to return -1, 0 or 1; and -1 for > an error. > > We now issue a warning if the value is not in this range. > ... > > I haven't decided yet whether to backport this to 2.2.x. The patch > applies fine. But is it fair to start warning in 2.2.2 about code > that worked flawlessly in 2.2.1? If 2.2.x is the Python-in-a-Tie line, I say "no way". People wearing ties don't care whether a thing is right or wrong, so long as "it works" they simply don't want to hear about it at all. Converting old extensions to avoid new warnings is a 2.3 task for them.

3 4

subclass a module?
by barry＠zope.com 04 Jun '02

04 Jun '02

Am I freaking out, did I missing something, or was the `root' in my root beer float tonight something other than sarsaparilla? -------------------- snip snip -------------------- Python 2.2.1 (#1, May 31 2002, 18:34:35) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import string >>> class allmodcons(string): pass ... >>> string <module 'string' from '/usr/local/lib/python2.2/string.pyc'> >>> allmodcons <module '?' (built-in)> -------------------- snip snip -------------------- Can I now subclass from modules? And if so, what good does that do me? -------------------- snip snip -------------------- >>> dir(allmodcons) [] >>> allmodcons.whitespace Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: 'module' object has no attribute 'whitespace' >>> string.whitespace '\t\n\x0b\x0c\r \xa0' >>> -------------------- snip snip -------------------- stickin'-to-herbal-tea-and-dr.-pepper-ly y'rs, -Barry

4 5

zap _Py prefix?
by Skip Montanaro 04 Jun '02

04 Jun '02

The issue of Michael's static PyTimeout_Err symbol reminded me about a question I had about _Py-prefixed symbols. I realize they are all "internal", but I also recall Tim saying a couple of times that the ANSI C standard reserves all symbols which begin with underscores for use by compiler writers. Should the _Py-prefixed symbols be renamed, for example, from _PyUnicode_IsDecimalDigit to Py__Unicode_IsDecimalDigit ? If so, we would then declare that all external symbols which begin with "Py__" were part of the private API. We would of course add macro definitions during the deprecation period: #define _PyUnicode_IsDecimalDigit Py__Unicode_IsDecimalDigit (It would also be nice to #warn when the macros are used. Is that possible with the C preprocessor?) Skip

6 6

Python-Dev June 2002