Mailman 3 July 2009 - Python-Dev

PEP 376 - from PyPM's point of view
by Sridhar Ratnakumar July 16, 2009

July 16, 2009

Here are my comments regarding PEP 376 with respect to PyPM (the Python package manager being developd at ActiveState) Multiple versions: I understand that the PEP does not support installation (thus uninstallation) of multiple versions of the same package. Should this be explicitly mentioned in the PEP -- as `get_distribution` API accepts only `name` argument, and not a `version` argument? > get_distribution(name) -> Distribution or None. >Scans all elements in sys.path and looks for all directories ending > with .egg-info. Returns a Distribution corresponding to the .egg-info > directory that contains a PKG-INFO that matches name for the name > metadata. >Notice that there should be at most one result. The first result > founded is returned. If the directory is not found, returns None. Some packages have package names with mixed case. Example: ConfigObj .. as registered in setup.py. However, other packages such as turbogears specifies "configobj" (lowercase) in their install_requires. Is `get_distribution(name)` supposed to handle mixed cases? Will it match both 'ConfigObj' and 'configobj'? > get_installed_files(local=False) -> iterator of (path, md5, size) Will this also return the directories /created/ during the installation? For example, will it also contain the entry "docutils" .. along with "docutils/__init__.py"? If not, how is the installer (pip, pypm, etc..) supposed to know which directories to remove (docutils/) and which directories not to remove (site-packages/, bin/, etc..)? > The new version of PEP 345 (XXX work in progress) extends the Metadata > standard and fullfills the requirements described in PEP 262, like the > REQUIRES section. Can you tell more about this? I see that PEP 262 allows both distributions names ('docutils') and modules/packages ('roman.py') in the 'Requires:' section. Is this how the new PEP is going to adhere to? Or, is it going to adhere to PEP 345's way of allowing *only* modules/packages? In practice, I noticed that packages usually specify distribution names in their 'Requires:' file (or install_requires.txt in the case of setuptools). Hence, PyPM *assumes* the install requirements to be distribution name. But then .. most distributions have the same name as their primary module/package. Ok, so PEP 345 also specifies the 'Provides:' header. Does easy_install/pip make use 'Provides:' at all when resolving dependencies? For example, does 'pip install sphinx' go look for all distributions that 'provides' the 'docutils' provision.. or does it simply get the distribution named 'docutils'? -srid

11 20

Re: [Python-Dev] [Distutils] PEP 376 - from PyPM's point of view
by P.J. Eby July 15, 2009

July 15, 2009

At 04:59 PM 7/15/2009 +0100, Paul Moore wrote: >- Virtualenv isn't a workaround (I don't know virtualenv, I'll take >your word for it) It's not one for system package maintainers because it would effectively be managing multiple instances of 'python'. Really not a suitable solution. >- I do not believe that it's clear that sanctioning the setuptools >workaround as the "right" approach by building it into the Python >core/stdlib is the right thing to do. I still don't understand how we're doing that.

4 3

Add an ExecutionLoader abc to importlib or to runpy?
by Brett Cannon July 15, 2009

July 15, 2009

I implemented get_filename() as specified in PEP 302 for importlib's source and bytecode loaders and I was starting to create the ABC for importlib.abc, but then I realized that perhaps the loader should live in runpy instead of importlib. Putting the new ABC in importlib keeps all PEP 302 ABCs in a single spot. But this addition to the PEP 302 protocols is very specific to runpy and is not directly required to make imports work (the implementation was just a reshuffling of pre-existing code from one method to another). I am tempted to leave the ABC out of importlib and stop at implementing get_filename() for importlib.abc.PyLoader and PyPycLoader. Any opinions? -Brett

4 6

Mercurial: tag generation incorrect
by "Martin v. Löwis" July 15, 2009

July 15, 2009

According to http://hg.python.org/cpython/tags?revcount=50 the tag r301 belongs to revision be32850b093f. However, this is really r69557, which was not tagged. be32850b093f is listed as having a child revision, 52b0a279fec6, and ISTM that *this* should be the revision that got tagged. Regards, Martin

2 2

Re: [Python-Dev] [Distutils] PEP 376 - from PyPM's point of view
by P.J. Eby July 15, 2009

July 15, 2009

At 06:40 PM 7/15/2009 +0100, Paul Moore wrote: >And of course, someone has to do the clean-up. It seems to me that the >fact that people are more inclined to reinvent the code than to try to >understand the existing codebase and pick out the relevant bits, says >something important about how easy it would be to maintain the >existing code within the Python core... That's normal for any code that contains "legacy" issues, which is why people always prefer rewriting code they don't understand: it's more fun to write than to read. However, as Joel Spolsky has well explained, rewriting such code inevitably means that you must re-learn the lessons that were learned by the original author. It seems like a waste, but then, I suppose those lessons must be relearned *some* way. I just think it'd be better if, having re-learned most of the lessons by trying to rewrite, one could then go back and learn the rest from the code. ;-) That having been said, it's obviously a dead parrot... one which I will now cease attempting to revive.

1 0

Re: [Python-Dev] [Distutils] PEP 376 - from PyPM's point of view
by P.J. Eby July 15, 2009

July 15, 2009

At 07:07 PM 7/15/2009 +0200, Tarek Ziadé wrote: > Part of the rejection of setuptools is because of that and > because you don't > bless anyone to maintain the project code base, or do releases, >neither to communicate clearly > on what's its roadmap. Jim Fulton and Ian Bicking have been officially blessed for *years*, and I've posted plenty about what's on its roadmap. >I really don't understand why you keep on pushing setuptools *code* pkg_resources is not setuptools; its stability and revision history are very different, as it addresses different problems.

1 0

Re: [Python-Dev] [Distutils] PEP 376 - from PyPM's point of view
by P.J. Eby July 15, 2009

July 15, 2009

At 11:10 AM 7/15/2009 +0100, Paul Moore wrote: >I propose that before the current prototype is turned into a final >(spec and) implementation, the PEP 302 extensions are extracted and >documented as an independent protocol, purely part of PEP 376. (This >*helps* implementers, as they can write support for, for example, >eggs, without needing to modify the existing egg importer). Btw, this is why setuptools chose to implement these things as adapters or generic functions in pkg_resources (and in the vestigial bits that were added to python 2.5's pkgutil). So as you can see, trying to solve these particular problems tends to lead to reinventing setuptools or at least portions thereof. ;-) >But the >problem is that too many people dislike setuptools as it stands for it >to gain support. My understanding is that the current set of PEPs were >intended to be a stripped down, more generally acceptable subset of >setuptools. Let's keep them that way (and omit the complexities of >multi-version support). Even without multi-version support, the parts of PEP 376 that aren't about uninstallation are still reinventing chunks of pkg_resources. Had pkg_resources been in the stdlib a couple years back (note that bugs and changes in it are still quite rare), the PEP 376 bits for pkgutil could have been focused strictly on uninstallation, and just reused pkg_resources API for finding distributions, reading metadata, getting version info, etc. etc. All that stuff is extremely stable code, very widely used for a very long time. If politics is the only thing keeping it from being used, then that's a pretty sad statement about the community, given that pkg_resources is not to blame for 99% of what people complain about in relation to setuptools. All pkg_resources does is find stuff (on request) and maybe add it to sys.path (on request), pull out data and metadata from distributions (on request), or set up namespace packages (on request). So if politics demands that it be rejected by association with "setuptools", then just search-and-replace the API, PEP 8-ify it, call it something different, and lie to everyone about where it came from. I won't tell if you won't. ;-)

3 2

Re: [Python-Dev] [Distutils] PEP 376 - from PyPM's point of view
by P.J. Eby July 15, 2009

July 15, 2009

At 04:14 PM 7/15/2009 +0100, Paul Moore wrote: >Look - I really, really don't mind if people use setuptools. Honest. >But I do mind if core python gets changed to support little bits of >what setuptools does, adding complexity to deal with issues that >setuptools handles, but without making it possible to avoid using >setuptools. I don't see how that's being proposed. Nothing in PEP 376 requires setuptools or any portion thereof, AFAICT.

1 0

Re: [Python-Dev] 2.6 object.__init__ & deling __new__
by P.J. Eby July 15, 2009

July 15, 2009

At 04:11 PM 7/14/2009 -0500, Benjamin Peterson wrote: >4. When __init__() is overridden, and the subclass __init__() >calls object.__init__(), the latter should complain about >excess arguments; ditto for __new__(). Actually, this rule is a PITA, because there's no good way to get rid of the warnings when you're trying to write MRO-agnostic mixins. In other words, it negates many of the gains that were obtained by having new-style MROs, since you can no-longer write pass-through constructors that leave their arguments untouched. Instead, every class must know ahead of time whether it will be the "last" class before 'object' -- thereby making it impossible to slip other mixins into the chain below them. In effect, 2.6 forces you to have a common known base class *other* than 'object' in order to write co-operative classes. :-(

2 2

64-bit values in XML RPC: OverflowError: int exceeds XML-RPC limits
by Peter Hanecak July 15, 2009

July 15, 2009

Hello, when I'm trying to use 64-bit integer values with SimpleXMLRPCServer, I'm getting "OverflowError: int exceeds XML-RPC limits" error each time I use an integer with value greater or equal to 2^31. I googled this: http://bugs.python.org/issue2985 So, my question is: In which Python release has been this fix distributed? Thank you in advance for information. Btw, I've made some dummy scripts to demonstrate the issue: - server.py: from SimpleXMLRPCServer import SimpleXMLRPCServer def dummy(number): return number server = SimpleXMLRPCServer(("localhost", 8000)) server.register_function(dummy, 'dummy') server.serve_forever() - client.py import xmlrpclib proxy = xmlrpclib.ServerProxy("http://localhost:8000/") print proxy.dummy(0x7FFFFFFF) print proxy.dummy(0x80000000) The output from client is: localhost.localdomain - - [15/Jul/2009 15:24:12] "POST / HTTP/1.0" 200 - 2147483647 Traceback (most recent call last): File "./client.py", line 7, in <module> print proxy.dummy(0x80000000) File "/usr/lib64/python2.6/xmlrpclib.py", line 1199, in __call__ return self.__send(self.__name, args) File "/usr/lib64/python2.6/xmlrpclib.py", line 1483, in __request allow_none=self.__allow_none) File "/usr/lib64/python2.6/xmlrpclib.py", line 1132, in dumps data = m.dumps(params) File "/usr/lib64/python2.6/xmlrpclib.py", line 677, in dumps dump(v, write) File "/usr/lib64/python2.6/xmlrpclib.py", line 699, in __dump f(self, value, write) File "/usr/lib64/python2.6/xmlrpclib.py", line 710, in dump_int raise OverflowError, "int exceeds XML-RPC limits" OverflowError: int exceeds XML-RPC limits Have a nice day. Peter p.s.: I'm not subscribed to the list, se please keep me in CC when replying. Thank you. -- Peter Hanecak ePC Developer | Alcatel-Lucent Apollo BC II - B block | Prievozska 4/A 11 | Bratislava | Slovak Republic email: peter.hanecak(a)alcatel-lucent.com phone: +421 (0)2 49264 857

5 5