Mailman 3 March 2006 - Python-Dev

Re: [Python-Dev] [Python-checkins] r43033 - in python/trunk/Lib: distutils/sysconfig.py encodings/__init__.py
by Thomas Wouters 15 Mar '06

15 Mar '06

On 3/15/06, guido.van.rossum <python-checkins(a)python.org> wrote: > > > Use relative imports in a few places where I noticed the need. > (Ideally, all packages in Python 2.5 will use the relative import > syntax for all their relative import needs.) You should be aware that using relative imports (or absolute imports) in the standard library may cause custom __import__'s that don't take the optional fifth argument to break, whereas using 'old-style' imports does not. I don't know how common custom __import__ hooks are, and adding the optional fifth argument is backwardly compatible, but I would personally not add absolute or relative imports to the oft-used parts of the stdlib until after 2.5. On the other hand, code using sys.path_hooks (like zipimport) don't need any tweaking, as the absolute/relative choice is made before they are queried, so I don't know howmuch impact this has, all in all. -- Thomas Wouters <thomas(a)python.org> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

4 4

Re: [Python-Dev] [Python-checkins] r43033 - in python/trunk/Lib: distutils/sysconfig.py encodings/__init__.py
by Phillip J. Eby 15 Mar '06

15 Mar '06

At 01:34 PM 3/15/2006 -0800, Guido van Rossum wrote: >Because Thomas designed it this way. :-) > >I believe his design makes sense though: "import foo" translates to >__import__(foo, ...). > >There's a separate setting, only known to the compiler, that says >whether "from __future__ import absolute_import" is in effect (there's >no way to slip a flag into globals to convey this setting, since code >is compiled independently from globals, and there are ways to pass >flags to the compiler without explicitly doing the future import). > >So the compiler emits different code when the future syntax is in >effect, and that opcode must pass its knowledge to __import__. This is >done trough the 5th argument, which also tells us how many leading >dots there were. Without the future import, the 5th argument is >omitted (as long as there aren't any leading dots). Ah, so it's *relative* imports that require a 5th argument. I was thinking it was there to support absolute imports. I was thinking that relative imports could be implemented by popping bits off of __name__ to get an absolute location. It seems to me that backward compatibility would be greatly enhanced by having the interpreter convert everything but "legacy" imports into absolute imports, as this would then work with the existing __import__ code in the field, even when new relative/absolute code was doing the importing. Otherwise, this forces __import__ hooks to be rewritten. (I personally avoid writing __import__ hooks if at all possible, but there are certainly some out there.) The mechanism I have in mind would be to just have an IMPORT_EXACT opcode that takes a relative or absolute name. This opcode would process relative names relative to the __name__ in globals to produce an exact module name, and leave absolute names alone. It would then invoke __import__ using the builtins or sys module dictionary as the "globals" argument *instead of the current globals*, so that __import__ will not do any legacy-style fallback. When absolute imports are in effect, or when an explicit relative import is used, it would be compiled such that IMPORT_NAME is replaced by IMPORT_EXACT. This mechanism doesn't require any change to the __import__() signature, and so remains backward compatible with any existing import hook that doesn't do weird things to the globals dictionary of the module that invoked it. On the other hand, perhaps it would be better to fail loudly by breaking on the 5th argument, than to fail silently for really weird __import__ hooks. That is, if it breaks, it will force people to make sure their __import__ code is safe for use with absolute imports. So, the existing approach might well be better than what I had in mind.

2 1

Re: [Python-Dev] [Python-checkins] r43028 - python/trunk/Modules/_ctypes/cfield.c
by Tim Peters 15 Mar '06

15 Mar '06

>> Author: thomas.heller >> Date: Tue Mar 14 21:39:27 2006 >> New Revision: 43028 >> >> Modified: >> python/trunk/Modules/_ctypes/cfield.c >> Log: >> Cast an Py_ssize_t to int, to avoid a compiler warning. >> >> Modified: python/trunk/Modules/_ctypes/cfield.c >> ============================================================================== >> --- python/trunk/Modules/_ctypes/cfield.c (original) >> +++ python/trunk/Modules/_ctypes/cfield.c Tue Mar 14 21:39:27 2006 >> @@ -251,10 +251,10 @@ >> >> if (bits) >> result = PyString_FromFormat("<Field type=%s, ofs=%d:%d, bits=%d>", >> - name, self->offset, size, bits); >> + name, (int)self->offset, size, bits); >> else >> result = PyString_FromFormat("<Field type=%s, ofs=%d, size=%d>", >> - name, self->offset, size); >> + name, (int)self->offset, size); >> return result; >> } [Neal Norwitz] > This isn't exactly correct. On a 64-bit system, the value will be > cast into a 32-bit integer. This is true for both Win64 and Unix. If > you change the cast to a long and use %ld (lowercase ell), that will > work correctly on Unix, but not Win64. To always display the correct > value on all platforms, you need an #ifdef MS_WIN64. For Windows, you > use %Id (that's a capital letter eye) and reference the value without > a cast. For Unix, you use %ld (lowercase ell), and cast the value to > a (long) to avoid a warning. I'm copying this to python-dev because it's important people understand this :-): all of the above is kinda true but irrelevant. Martin already checked in a patch so that PyString_FromFormat() understands the C99 "z" qualifier on _all_ platforms. So the correct way to repair this one wasn't to add a cast, and much less to add an #ifdef, it was to change ofs=%d to ofs=%zd in the format. I'm going to check that change in now, but don't make me do it again :-)

2 1

Re: [Python-Dev] [Python-checkins] r43033 - in python/trunk/Lib: distutils/sysconfig.py encodings/__init__.py
by Phillip J. Eby 15 Mar '06

15 Mar '06

At 10:33 AM 3/15/2006 -0800, Guido van Rossum wrote: >Well, absolute imports without the future statement will not use the >5th argument, so they won't break, right? That's what MAL also says. >Someone please fix this. Why is a 5th argument needed to do absolute imports? Shouldn't it suffice to supply a globals argument with no __path__ and an undotted __name__? ISTM that passing in the builtins dictionary as the globals argument ought to do the trick.

2 1

Deprecated modules going away in 2.5
by Neal Norwitz 15 Mar '06

15 Mar '06

Unless I hear shouts *soon*, the following modules will be removed in 2.5: reconvert.py regex # regexmodule.c regex_syntax.py regsub.py lib-old/* # these are the modules under lib-old Para.py codehack.py fmt.py ni.py statcache.py whatsound.py addpack.py dircmp.py grep.py packmail.py tb.py whrandom.py cmp.py dump.py lockfile.py poly.py tzparse.py zmod.py cmpcache.py find.py newdir.py rand.py util.py In addition, I will swap sre and re. This will make help(re) work properly. Let me know if you disagree with any of these changes. n

2 1

PEP 338 implemented in SVN
by Nick Coghlan 15 Mar '06

15 Mar '06

Following Guido's acceptance of the PEP in SVN, PEP 338 has now been checked in for 2.5. (PEP's 0, 338 and 356 have been updated to reflect this). Cheers, Nick. P.S. Has the change to the new look site broken the automatic update of pydotorg after PEP checkins? (PEP 356 looks fairly different from the latest SVN version) -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org

2 1

About "Coverity Study Ranks LAMP Code Quality"
by fermigier 15 Mar '06

15 Mar '06

http://www.internetnews.com/dev-news/article.php/3589361 "Perl had a defect density of only 0.186. In comparison Python had a defect density of 0.372 and PHP was actually above both the baseline and LAMP averages at 0.474." This is of course a PR stunt. But I'm wondering if the actual "bugs" list was transmitted to Python developers, and verified / acted upon. Because according to http://www.washingtontechnology.com/news/1_1/daily_news/28134-1.html : "The maintainers of the source codes can register with Coverity to see the full results. (End users cannot see the bug lists themselves; they will be able to see how buggy a particular program may be.)" Regards, S.

8 16

Re: [Python-Dev] Using relative imports in std lib packages ([Python-checkins] r43033 - in python/trunk/Lib: distutils/sysconfig.py encodings/__init__.py)
by M.-A. Lemburg 15 Mar '06

15 Mar '06

guido.van.rossum wrote: > Author: guido.van.rossum > Date: Wed Mar 15 05:33:54 2006 > New Revision: 43033 > > Modified: > python/trunk/Lib/distutils/sysconfig.py > python/trunk/Lib/encodings/__init__.py > Log: > Use relative imports in a few places where I noticed the need. > (Ideally, all packages in Python 2.5 will use the relative import > syntax for all their relative import needs.) Instead of adding relative imports to packages in the standard lib, I'd suggest to use absolute imports instead. These are much easier to manage, maintain and read. There's also no "need" for relative imports in std lib packages since these won't be subject to possible relocation. > Modified: python/trunk/Lib/distutils/sysconfig.py > ============================================================================== > --- python/trunk/Lib/distutils/sysconfig.py (original) > +++ python/trunk/Lib/distutils/sysconfig.py Wed Mar 15 05:33:54 2006 > @@ -16,7 +16,7 @@ > import string > import sys > > -from errors import DistutilsPlatformError > +from .errors import DistutilsPlatformError > > # These are needed in a couple of spots, so just compute them once. > PREFIX = os.path.normpath(sys.prefix) > > Modified: python/trunk/Lib/encodings/__init__.py > ============================================================================== > --- python/trunk/Lib/encodings/__init__.py (original) > +++ python/trunk/Lib/encodings/__init__.py Wed Mar 15 05:33:54 2006 > @@ -27,7 +27,8 @@ > > """#" > > -import codecs, types, aliases > +import codecs, types > +from . import aliases > > _cache = {} > _unknown = '--unknown--' > _______________________________________________ > Python-checkins mailing list > Python-checkins(a)python.org > http://mail.python.org/mailman/listinfo/python-checkins -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2006) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

1 0

Re: [Python-Dev] [Python-checkins] Python Regression Test Failures refleak (1)
by Tim Peters 15 Mar '06

15 Mar '06

[Thomas Wouters] > I did the same narrowing-down last week, and submitted a patch to add > cycle-GC support to itertools.tee . It really needs it. I agree. > Come to think of it, now that I remember how to properly do GC, I think > the patch cuts some corners, but it solved the problem. You mean because it didn't supply tp_clear? That's a funny one. Some people take pride in not supplying tp_clear unless it's absolutely necessary. For example, despite that tuples can be in cycles, the tuple type doesn't supply a tp_clear. This is "because" it's possible to prove that any cycle involving tuples must involve a non-tuple gc'ed type too, and that clearing the latter is always sufficient to break the cycles (which is all tp_clear _needs_ to do: we just need that the aggregate of all tp_clear slots that are implemented suffice to break all possible cycles). I never saw a point to that cleverness, though. It makes gc more obscure, and I'm not sure what it buys. Maybe the (typically teensy) bit of code needed to implement a tp_clear slot? That's all the (dubious) benefit I can think of. > Raymond is on it, anyway: > > http://python.org/sf/1444398 You found it, you fix it :-)

2 1

Re: [Python-Dev] [Python-checkins] r43022 - in python/trunk: Modules/xxmodule.c Objects/object.c
by Tim Peters 15 Mar '06

15 Mar '06

[M.-A. Lemburg] >> Why do you add these things to the xx module and not the >> _testcapi module where these things should live ? [Neal Norwitz] > Because I'm an idiot? Ah, so _that's_ why you were made the release coordinator ;-) > Thanks for pointing it out, I moved the code. Or maybe that was why. People who clean up after themselves are certainly welcome to coordinate me!

1 0