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`
> 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
>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
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'?
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
>- 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.
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
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.
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.
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.
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.
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. ;-)
>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
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. ;-)
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
I don't see how that's being proposed. Nothing in PEP 376 requires
setuptools or any portion thereof, AFAICT.
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. :-(
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:
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:
from SimpleXMLRPCServer import SimpleXMLRPCServer
server = SimpleXMLRPCServer(("localhost", 8000))
proxy = xmlrpclib.ServerProxy("http://localhost:8000/")
The output from client is:
localhost.localdomain - - [15/Jul/2009 15:24:12] "POST / HTTP/1.0" 200 -
Traceback (most recent call last):
File "./client.py", line 7, in <module>
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
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
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.
p.s.: I'm not subscribed to the list, se please keep me in CC when
replying. Thank you.
ePC Developer | Alcatel-Lucent
Apollo BC II - B block | Prievozska 4/A 11 | Bratislava | Slovak Republic
phone: +421 (0)2 49264 857