Mailman 3 July 2009 - Python-Dev

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 using sems. Looking at the source code it appears that this is intended, but I cannot see the reason for that. It seems the pthread sem implementation is the only one doing so. Can any of you tell me the reason why it swallows signals? I have already prepared a patch that introduces a new _noswallow function if sem are used and uses this in threadmodule.c. But if there isn't any real reason for it to swallow exceptions, I think it would be wisest to change that. Best regards, Florian Mayer

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 2, 2009

July 2, 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 CPython raises TypeError. Library Reference seems to mention it here: exception AttributeError Raised when an attribute reference or assignment fails. (When an object does not support attribute references or attribute assignments at all, TypeError is raised.) http://docs.python.org/library/exceptions.html What does it mean that "an object does not support attribute references or attribute assignments at all"? -- Seo Sanghyeon

8 12

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

July 2, 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 2, 2009

July 2, 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 easy_install, pip, etc.) you can specify where data files and scripts go on Windows, and they don't have to be relative locations. So, absolute paths need to be supported, despite the existence of broken bdist targets on Windows.

1 0

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

July 2, 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 license header, or they just point to one of the files above: http://svn.python.org/view/python/trunk/Lib/sre_compile.py?view=markup http://svn.python.org/view/python/trunk/Lib/sre_constants.py?view=markup http://svn.python.org/view/python/trunk/Lib/sre_parse.py?view=markup http://svn.python.org/view/python/trunk/Modules/sre.h?view=markup http://svn.python.org/view/python/trunk/Modules/sre_constants.h?view=markup PS: if this gets fixed somehow, can the fix be backported to the Python 2.5.x releases? Let me know what needs to be done to get this fixed on next release. Thanks, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil

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…>. Lines 1 - 15 are me attempting to get around certain changes between Python 3.0 and Python 2.7. Further down on line 916, we have the function "send" and "recv" in which I am having the most trouble with bytes and strings. Any help is appreciated. Feel free to comment on my blog http://subdev.blogspot.com/ or reply to the last. Thanks in advance, Eric

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-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).

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 API do not support existing .egg files. This should probably be made clear, if that's the intention.

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 should > > say so. > >This problem is solved as described later in the PEP, with the API >that allows you to get the >list of the distributions that use a given file. (thanks to the RECORD files) > >If Spam and Ham use smap.py, and if you uninstall Spam, this file will >not be removed >because the API will tell you its used in both distributions. That's not the scenario he's talking about. He's talking about the case where Ham has an 'install_requires' of Spam. That is, a runtime dependency, not a shared file. >Good question, I have never created such distribution. >Aren't they read-only files ? setuptools' bdist_egg command has an option to exclude source from an .egg, but it doesn't do anything special with permissions. I don't think any other current install tools support source-free installation.

2 1