Mailman 3 July 2009 - Python-Dev

PEP 376
by Tarek Ziadé July 4, 2009

July 4, 2009

Hello, If no one objects, I'd like to push PEP 376 in the "accepted" status and go ahead with its implementation, with continuous feedback at Distutils-SIG as we did to build it. The next PEPs that are being discussed at Distutils-SIG are : - the new version of PEP 345 for the inclusion of fields like "installed_requires" (dependencies) - PEP 386, that talks about distribution version numbers (because it's needed to describe dependencies) While they are still under heavy discussion, I have … [View More]

15 52

3.1 buildbots
by "Martin v. Löwis" July 4, 2009

July 4, 2009

I have now turned the 3.0 buildbots off, and created new builders for 3.1. Regards, Martin

1 0

Re: [Python-Dev] PEP 376
by P.J. Eby July 4, 2009

July 4, 2009

At 02:54 PM 7/3/2009 +0100, Paul Moore wrote: >Eggs are fundamentally a PEP 302 zip file format. There are some >extra bits of metadata for setuptools/easy_install in there (as I >understand things) but essentially they are zip files. When you say >"decoupling the egg format", I assume you mean "decoupling the egg >metadata" - which is fine, but to properly decouple, you need API >level access to the metadata. PEP 376 offers read-only access, but >as you rightly point … [View More]

3 2

PEP 376
by Tarek Ziadé July 4, 2009

July 4, 2009

Hello, We have polished out PEP 376 and its code prototype at Distutils-SIG. It seems to fullfill now all the requirements, so I am mailing it here again, for a new round of feedback, if needed. - the pep : http://svn.python.org/projects/peps/trunk/pep-0376.txt - the code prototype : http://bitbucket.org/tarek/pep376/src/tip/pkgutil.py Notice that if the PEP is accepted at this point, I will : - focus on making the code work as fast as possible, for directories browsing - work on the … [View More]

8 16

Summary of Python tracker Issues
by Python tracker July 3, 2009

July 3, 2009

ACTIVITY SUMMARY (06/26/09 - 07/03/09) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 2231 open (+26) / 16000 closed (+38) / 18231 total (+64) Open issues with patches: 890 Average duration of open issues: 661 days. Median duration of open issues: 413 days. Open Issues Breakdown open 2203 (+26) pending 28 ( +0) Issues Created Or Reopened (65) … [View More]

1 0

pthread sem PyThread_acquire_lock
by Florian Mayer July 3, 2009

July 3, 2009

Hello. As this is my first post I will try to introduce myself as requested in the welcome email. If you aren't interested in my person, just continue reading at the next paragraph. I'm a student from Vienna/Austria. I attend what would match high school in the United States. I have been writing Python for about 3 years now and have just began to dig into the implementation of CPython. Now to my real question. I have noticed that PyThread_acquire_lock swallows all signals with pthread … [View More]

6 8

I am back
by Brett Cannon July 3, 2009

July 3, 2009

Assuming Mailman flipped the right bits to start delivering mail to me again, my Python sabbatical is now over. Anything happen while I was gone that I should be aware of that is not covered in a PEP? -Brett

7 8

Exception for setting attributes of built-in type
by Seo Sanghyeon July 3, 2009

July 3, 2009

Exception for setting attributes of built-in type differs between CPython and IronPython. This is not purely theoretical, as zope.interface tries to set Implements declaration as __implemented__ attribute of built-in type object, and excepts TypeError. Python 2.6.1 >>> object.flag = True TypeError: can't set attributes of built-in/extension type 'object' IronPython 2.6 >>> object.flag = True AttributeError: 'object' object has no attribute 'flag' I was surprised that … [View More]

8 12

[Fwd: [issue6397] Implementing Solaris "poll" in the "select" module]
by Jesus Cea July 3, 2009

July 3, 2009

-- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea(a)jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz

4 4

Re: [Python-Dev] PEP 376
by P.J. Eby July 3, 2009

July 3, 2009

At 09:06 PM 7/2/2009 +0100, Paul Moore wrote: >Maybe the answer is that distutils reject *all* uses of absolute paths >on Windows. The PEP can then say whatever you want as far as I'm >concerned, as it doesn't affect me. If the existing bugs don't get >fixed, though, I'd say that the RECORD file should be explicitly >disallowed from containing absolute paths on Windows (for safety >reasons if nothing else). In non bdist cases (e.g. setup.py with manual options, but also … [View More]

1 0

"re" module and Python 1.6 (GPL incompatible) license?
by Anderson Lizardo July 3, 2009

July 3, 2009

Hi, I noticed that some files of the "re" module still have the (GPL incompatible) 1.6 license notice. Is that on purpose or unintentionally forgotten? If that is on purpose, does that mean that some GPL Python code cannot use the "re" module? For reference, here are the links to these files (from trunk): http://svn.python.org/view/python/trunk/Lib/re.py?view=markup http://svn.python.org/view/python/trunk/Modules/_sre.c?view=markup Additionally, the files below do not have a complete … [View More]

2 1

Bytes, Strings, Encoding
by Eric Pruitt July 2, 2009

July 2, 2009

Hello, I am working on the subprocess.Popen module for Python 2.7 and am now moving my changes over to Python 3.1 however I am having trouble with the whole byte situation and I can't quite seem to understand how to go back and forth between bytes and strings. I am also looking for the Python 3k equivalent for the Python 2.X built-in buffer class. One version of the file with my modifications can be found here < http://code.google.com/p/subprocdev/source/browse/subprocess.py?spec=svn5b5…&… [View More]

3 2

Re: [Python-Dev] PEP 376
by P.J. Eby July 2, 2009

July 2, 2009

At 04:29 PM 7/1/2009 +0200, Tarek Ziadé wrote: >- Phase 1 : introduction of the egg-info file in distutils > >Philipp introduced the creation of a file named xxx.egg-info file in 2006 >(see http://bugs.python.org/issue1459476) alongside >distutils-installed package, that contains >the metadata of the distribution. > >- Phase 2: two new formats in the setuptools project > >Then he created two new formats in the setuptools project: This is backwards. The .egg-… [View More]info file was added to distutils and setuptools *after* support for the other formats. In other words, it was a third format added to allow other software (such as setuptools and friends) to detect the presence of packages installed via the distutils, and thereby prevent other tools from installing duplicates. (.egg-info directories and .egg files/directories already existed.) >This means that all the third-party tools out there already conform to >that standard, and that packages installed >in other formats will not benefit from the new APIs. which means that >people that want to work with distributions installed as .egg >directories will have to use setuptools APIs. >Which makes sense. Yes and no. Not providing uninstall support is reasonable, but the PEP also has features to query packages in general. (There's also no technical reason why comparable manifest and uninstall support can't be provided for .egg files and directoriees, since they already have an implicit manifest: their contents. However, since I'm not currently possessed of the time to provide a patch myself, I'm not going to lobby for this as a feature.) > > If you want, you can then add a cross-reference note, saying something > > like "The setuptools structure, as proposed in the EggFormats > > documentation for that package [ref], is a subset of this standard. In > > order to conform to this PEP, setuptools will have to be amended to > > only install .egg-info directories in the format defined by this PEP". > >I'll work that way. (Technically, it's an extension of a subset of EggFormats, since it adds RECORD and INSTALLER.) > > > > "However, it will impact the setuptools and pip projects, but given > > the fact that..." > > > > Confusing. Will these tools need to change (I believe so) or not? If > > they will need to change, that hardly counts as "no deep consequences" > > - there's the whole backward compatibility issue for them to handle. > >I'll add this in a backward compatibility section, as suggested >earlier by someone. They don't need to change, unless they're going to support being uninstalled by the tool (in which case they'll need to add RECORD and INSTALLER). [View Less]

2 1

Re: [Python-Dev] PEP 376
by P.J. Eby July 1, 2009

July 1, 2009

At 07:57 PM 6/29/2009 +0200, Tarek Ziadé wrote: >Hello, > >If no one objects, I'd like to push PEP 376 in the "accepted" status >and go ahead with its implementation, >with continuous feedback at Distutils-SIG as we did to build it. I do have a question about the current draft... Do zipped distributions use EGG-INFO or a project-version.egg-info? This isn't spelled out in the PEP, although I get the general idea that the EGG-INFO format isn't supported, and thus the PEP and … [View More]

3 5

Re: [Python-Dev] PEP 376
by P.J. Eby July 1, 2009

July 1, 2009

At 01:34 AM 7/1/2009 +0200, Tarek Ziadé wrote: >On Wed, Jul 1, 2009 at 12:47 AM, Steven D'Aprano<steve(a)pearwood.info> wrote: > > I don't see how this proposal will help in the second case. If you > > install distribution Spam, containing file spam.py, and then install > > distribution Ham, which requires spam.py, what is to prevent you from > > removing Spam and breaking Ham? > > > > If you don't propose a solution for the dependency problem, you … [View More]

2 1