Mailman 3 October 2009 - Python-Dev

Re: [Python-Dev] Package install failures in 2.6.3
by P.J. Eby 06 Oct '09

06 Oct '09

At 02:22 PM 10/5/2009 +0200, Tarek Ziadé wrote: >Setuptools development has been discontinued for a year, and does >patches on Distutils code. Some of these patches are sensitive to any change >made on Distutils, wether those changes are internal or not. Setuptools is also not the only thing out there that subclasses distutils commands in general, or the build_ext command in particular. Numpy, Twisted, the mx extensions... there are plenty of things out there that subclass distutils commands, quite in adherence to the rules. (Note too that subclassing != patching, and the ability to subclass and substitute distutils commands is documented.) It's therefore not appropriate to treat the issue as if it were setuptools-specific; it could have broken any other major (or minor) package's subclassing of the build_ext command.

2 1

Help needed for tar archive creation with changed UID/GID
by bheemesh v 06 Oct '09

06 Oct '09

Hello, I am a newbie to this mailing list, i have seen in some mail discussions about a tar archive creation by forcibly setting the UID/GID to a specific user (say root). Te code mentioned goes like this: tar = tarfile.open("foo.tar.gz", "w:gz") for filename in filenames: tarinfo = tar.gettarinfo(filename) if tarinfo.isreg(): fobj = open(filename) else: fobj = None tarinfo.uid = 0 tarinfo.gid = 0 tar.addfile(tarinfo, fobj) tar.close() But this is not really working for me as when i am trying to un-tar or un-compress contents to a new directory and contents still have diff GID & UID in the long listing of directory. Can somebody suggest an alternative or a working case if already changes are done here. Thanks in advance. Best regards, Bheemesh

3 2

summary of transitioning from % to {} formatting
by Steven Bethard 06 Oct '09

06 Oct '09

I thought it might be useful for those who don't have time to read a million posts to have a summary of what's happened in the formatting discussion. The basic problem is that many APIs in the standard library and elsewhere support only %-formatting and not {}-formatting, e.g. logging.Formatter accepts:: logging.Formatter(fmt="%(asctime)s - %(name)s") but not:: logging.Formatter(fmt="{asctime} - {name}") There seems to be mostly agreement that these APIs should at least support both formatting styles, and a sizable group (including Guido) believe that %-formatting should eventually be phased out (e.g. by Python 4). There are a number of competing proposals on how to allow such APIs to start accepting {}-format strings: * Add a parameter which declares the type of format string:: logging.Formatter(fmt="{asctime} - {name}", format=BRACES) The API code would then switch between %-format and {}-format based on the value of that parameter. If %-formatting is to be deprecated, this could be done by first deprecating format=PERCENTS and requiring format=BRACES, and then changing the default to format=BRACES. * Create string subclasses which convert % use to .format calls:: __ = brace_fmt logging.Formatter(fmt=__("{asctime} - {name}")) The API code wouldn't have to change at all at first, as applying % to brace_fmt objects would call .format() instead. If %-formatting is to be deprecated, this could be done by first deprecating plain strings and requiring brace_fmt strings, and then allowing plain strings again but assuming they are {}-format strings. * Teach the API to accept callables as well as strings:: logging.Formatter(fmt="{asctime} - {name}".format) The API code would just call the object with .format() style arguments if a callable was given instead of a string. If %-formatting is to be deprecated, this could be done by first deprecating plain strings and requiring callables, and then allowing plain strings again but assuming they are {}-format strings * Create translators between %-format and {}-format:: assert to_braces("%(asctime)s") == "{asctime}" assert to_percents("{asctime}") == "%(asctime)s" these could then either be used outside of the API:: logging.Formatter(fmt=to_percents("{asctime} - {name}")) or they could be used within the API combined with some sort of heuristic for guessing whether a {}-format string or a %-format string was passed in:: logging.Formatter(fmt="{asctime} - {name}") If %-formatting is to be deprecated, the transition strategy here is trivial. However, no one has yet written translators, and it is not clear what heuristics should be used, e.g. should the method just try %-formatting first and then {}-formatting if it fails? I don't think there is consensus yet on which of these proposals should be the "blessed" one. Steve -- Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus

12 23

Re: [Python-Dev] Package install failures in 2.6.3
by P.J. Eby 05 Oct '09

05 Oct '09

At 11:21 AM 10/5/2009 -0700, Brett Cannon wrote: >I have to admit I find it really disheartening that we are letting >an unmaintained project dictate how we fix a bug. Setuptools was not the only project broken by this change. See: http://bugs.python.org/issue7020#msg93355 Apparently, I'm not the only person who read the get_ext_filename() docstring that way, and subclassed build_ext in a way that broke it. (In this case, it was pywin32.) IMO, the fact that it broke Pywin32 in 2.6.3rc1 should have been considered evidence that the change was not suitable for a bugfix release.

1 0

Re: [Python-Dev] Package install failures in 2.6.3
by P.J. Eby 05 Oct '09

05 Oct '09

At 04:17 PM 10/5/2009 +0200, Tarek Ziadé wrote: >Now I am astonished that we are talking about reverting changes in >Distutils that were done for bugfixes, for a third party package that >does monkey patches on Distutils. Subclassing is not monkeypatching, so if you consider the above to be a general policy, then the developers of at least Numpy and Twisted should consider themselves warned that bugfix releases may break their build processes.

1 0

Python 2.6.3rc1 available
by Barry Warsaw 04 Oct '09

04 Oct '09

The first (and hopefully last) release candidate for Python 2.6.3 is now available via http://www.python.org/download/releases/2.6.3/ Source releases and Windows binaries are currently available, and Mac OS X binaries should be forthcoming. Nearly 100 bugs have been fixed since 2.6.2. Barring any unforeseen problems, we will make the final 2.6.3 release this Friday, October 2nd. Please give this release candidate a spin and let us know if you encounter any show stopping problems. Enjoy, -Barry

4 3

% to .format() converter
by Benjamin Peterson 03 Oct '09

03 Oct '09

Interested in the recent threads about % and str.format(), I wrote a little Python 3 script that converts % format strings to format strings compatible with str.format(). I invite you to try it out. The code is at https://code.launchpad.net/~gutworth/+junk/mod2format (That means you can do "bzr branch lp:~gutworth/+junk/mod2format".) It should basically work except for some obscure cases like "%#.0f". -- Regards, Benjamin

1 0

PEP 3144 review.
by Peter Moody 03 Oct '09

03 Oct '09

Folks, Guido, I believe PEP 3144 is ready for your review. When you get a chance, can you take a look/make a pronouncement? Cheers, /peter

35 266

PEP 3121
by Andrew Svetlov 02 Oct '09

02 Oct '09

What real status of this document? As I figured out py3k trunk uses this ones. Most part of 'battery included' modules don't use this feature, leaving m_traverse, m_clear and m_free NULL pointers. There are only exception: _io. But looks like all underground python machinery is already ported to support PEP. Maybe it's good point to update PEP? "accepted; may not be implemented yet" sounds a bit confusing. Just insert somethere close to top of content: "Implemented by Python itself, but builtin modules should be converted". Next question: are where all 'python standard library' modules looks like "not converted yet" really need to be refactored? Or we can split this huge set to 'looks already good' and 'requires some work'? And just add comment for every PyModuleDef definition like: "Completely satisfy PEP 3121, signed and stamped by Martin von Loewis and GvR".? Last question: PEP refers to "multiple interpreters" feature of python. This feature presented at least in 2.xx branch (don't remember about 1.xx - up to 2003 I used python as scripting language only and not care about C interface). I never saw usage of this one in real use cases. Is there projects (preferable with code sources, of course) what runs multiple interpreter in same process?

2 1

RELEASED Python 2.6.3
by Barry Warsaw 02 Oct '09

02 Oct '09

On behalf of the Python community, I'm happy to announce the availability of Python 2.6.3. This is the latest production-ready version in the Python 2.6 series. Somewhere near 100 bugs have been fixed since Python 2.6.2 was released in April 2009. Please see the NEWS file for all the gory details. http://www.python.org/download/releases/2.6.3/NEWS.txt Source tarballs, Windows installers and the Mac OS X disk image can be downloaded from the Python 2.6.3 page. http://www.python.org/download/releases/2.6.3/ For more information on Python 2.6 in general, please see http://docs.python.org/whatsnew/2.6.html Please report bugs for any Python version in the Python tracker. http://bugs.python.org Enjoy, -Barry Barry Warsaw barry(a)python.org Python 2.6 Release Manager (on behalf of the entire python-dev team)

1 0