Re: [Python-Dev] PEP 376 - from PyPM's point of view

2009/7/15 Sridhar Ratnakumar : > On Wed, 15 Jul 2009 02:01:24 -0700, Tarek Ziadé > wrote: > 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 "docut

[Python-Dev] PEP 376 - from pythonpkgmgr point of view

On Wed, 15 Jul 2009 13:47:35 -0400, Chris McDonough wrote: > I've been trying to follow this discussion now for weeks. The signal to > noise ratio is pretty low. I'm -1 on that.. As a relative newcomer to python packaging I'm finding all these discussions very informative. :-) > I'd love to hav

Re: [Python-Dev] [Distutils] PEP 376 - from PyPM's point of view

2009/7/15 Chris McDonough : > I've been trying to follow this discussion now for weeks. The signal to > noise ratio is pretty low. I agree :-( > I'd love to have an stdlib solution for distribution packaging and > installation.  But I think we might as well pack it up and go home if the > folks w

Re: [Python-Dev] Add an ExecutionLoader abc to importlib or to runpy?

Brett Cannon wrote: > On Wed, Jul 15, 2009 at 06:51, Nick Coghlan > wrote: > However, the fact that importlib doesn't implement the comparatively > recent get_filename() optional extension documented in PEP 302 came up > in one of the PEP 376 threads within t

Re: [Python-Dev] Mercurial: tag generation incorrect

Hagen Fürstenau wrote: >> be32850b093f is listed >> as having a child revision, 52b0a279fec6, and ISTM that *this* >> should be the revision that got tagged. > > I think the tag is correct. Note that the concept of tagging is > different in Mercurial, where a tag can only refer to a revision > pre

Re: [Python-Dev] Add an ExecutionLoader abc to importlib or to runpy?

On Wed, Jul 15, 2009 at 06:51, Nick Coghlan wrote: > Antoine Pitrou wrote: > > I am not sure when this discussion started. Are you replying to a 3 > month-old > > message of yours? :) > > That depends on how you define the beginning of the discussion... > Especially since I was offlist three mon

Re: [Python-Dev] [Distutils] PEP 376 - from PyPM's point of view

I've been trying to follow this discussion now for weeks. The signal to noise ratio is pretty low. I'd love to have an stdlib solution for distribution packaging and installation. But I think we might as well pack it up and go home if the folks whom are contributing to the discussion "recreat

Re: [Python-Dev] [Distutils] PEP 376 - from PyPM's point of view

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

Re: [Python-Dev] [Distutils] PEP 376 - from PyPM's point of view

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 official

Re: [Python-Dev] [Distutils] PEP 376 - from PyPM's point of view

On Wed, 15 Jul 2009 08:22:03 -0700, David Cournapeau wrote: if docutils 0.5 is installed, Foo is broken, unless docutils 0.4 is shipped with it. As was stated by Debian packagers on the distutils ML, the problem is that docutils 0.5 breaks packages which work with docutils 0.4 in the first p

Re: [Python-Dev] PEP 376 - from PyPM's point of view

Tarek Ziadé wrote: In any case I don't see any use case to have a "site-packages" remaining in Python itself. I have and am using it. Where else would you have me put library packages meant to be accessible by any Python program? Terry Jan Reedy ___

Re: [Python-Dev] [Distutils] PEP 376 - from PyPM's point of view

2009/7/15 P.J. Eby : > 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* im

Re: [Python-Dev] PEP 376 - from PyPM's point of view

On Wed, 15 Jul 2009 02:01:24 -0700, Tarek Ziadé wrote: 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"? I

Re: [Python-Dev] [Distutils] PEP 376 - from PyPM's point of view

2009/7/15 P.J. Eby : [...] > 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.  ;-) While setuptools did addre

Re: [Python-Dev] [Distutils] PEP 376 - from PyPM's point of view

On Wed, 15 Jul 2009 at 16:14, Paul Moore wrote: Bluntly, as Python stands, import and sys.path do not offer any core support for multiple versions. Custom solutions can be built on top of that - that's what setuptools does. But they are precisely that - custom solutions, and should be supported a

Re: [Python-Dev] [Distutils] PEP 376 - from PyPM's point of view

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

Re: [Python-Dev] [Distutils] PEP 376 - from PyPM's point of view

At 05:16 PM 7/15/2009 +0200, Joachim König wrote: f you have m different versions of n packages then you could have n**m different combinations for an application so you need a possiblilty to select one combination from n**m possible ones at application startup time. Is this really worth it? Ob

Re: [Python-Dev] [Distutils] PEP 376 - from PyPM's point of view

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 possib

Re: [Python-Dev] [Distutils] PEP 376 - from PyPM's point of view

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 suppor

Re: [Python-Dev] [Distutils] PEP 376 - from PyPM's point of view

On Wed, Jul 15, 2009 at 5:16 PM, Joachim König wrote: > Tarek Ziadé wrote: >> >> So basically "site-packages" is a distribution location that is >> avoided by everyone because it doesn't >> know how to handle multiple versions. > > I think you overrate the importance of having multiple versions of

Re: [Python-Dev] [Distutils] PEP 376 - from PyPM's point of view

2009/7/15 David Cournapeau : > As was stated by Debian packagers on the distutils ML, the problem is > that docutils 0.5 breaks packages which work with docutils 0.4 in the > first place. > > http://www.mail-archive.com/distutils-...@python.org/msg05775.html > > And current hacks to work around lac

Re: [Python-Dev] 2.6 object.__init__ & deling __new__

At 07:29 PM 7/15/2009 +1200, Greg Ewing wrote: P.J. Eby wrote: In effect, 2.6 forces you to have a common known base class *other* than 'object' in order to write co-operative classes. :-( You have to do that anyway if you want to make cooperative calls to any method *other* that __init__.

Re: [Python-Dev] [Distutils] PEP 376 - from PyPM's point of view

On Wed, Jul 15, 2009 at 11:00 PM, Tarek Ziadé wrote: > On Wed, Jul 15, 2009 at 12:10 PM, Paul Moore wrote: >> >> Disclaimer: I've only read the short version, so if some of this is >> covered in the longer explanation, I apologise now. > > Next time I won't put a short version ;) > > >> >> PEP 376

Re: [Python-Dev] [Distutils] PEP 376 - from PyPM's point of view

On Wed, Jul 15, 2009 at 5:14 PM, Paul Moore wrote: > 2009/7/15 Tarek Ziadé : >> On Wed, Jul 15, 2009 at 12:17 PM, Michael >> Foord wrote: Disclaimer: I've only read the short version, so if some of this is covered in the longer explanation, I apologise now. -1. >>> >>> I ag

Re: [Python-Dev] [Distutils] PEP 376 - from PyPM's point of view

Tarek Ziadé wrote: So basically "site-packages" is a distribution location that is avoided by everyone because it doesn't know how to handle multiple versions. I think you overrate the importance of having multiple versions of a package available for the same python interpreter. If you have m d

Re: [Python-Dev] Add an ExecutionLoader abc to importlib or to runpy?

2009/7/15 Nick Coghlan : > While runpy is the only client in the standard library for the > get_filename() method, the method is still a PEP 302 extension. I > documented the extension in the PEP as loaders are the only things > reliably in a position to provide the filename details that runpy need

Re: [Python-Dev] [Distutils] PEP 376 - from PyPM's point of view

2009/7/15 Tarek Ziadé : > On Wed, Jul 15, 2009 at 12:17 PM, Michael > Foord wrote: >>> Disclaimer: I've only read the short version, so if some of this is >>> covered in the longer explanation, I apologise now. >>> >>> -1. >>> >> >> I agree. People with versioning issues *should* be using virtualen

Re: [Python-Dev] 64-bit values in XML RPC: OverflowError: int exceeds XML-RPC limits

On Wed, Jul 15, 2009 at 16:42, Peter Hanecak wrote: > So my subsequent question is: What can help me solve the "writing" part? The XML-RPC protocol, as specified at [1], doesn't support integers with more than 32 bits (in fact, the i4 alias can be used to make the use of 4 bytes explicit). So, eit

Re: [Python-Dev] 64-bit values in XML RPC: OverflowError: int exceeds XML-RPC limits

On Wed, Jul 15, 2009 at 4:42 PM, Peter Hanecak wrote: > Hello, > > thank you David and Benjamin for quick response. > > So my subsequent question is: What can help me solve the "writing" part? Use strings. Send str(0x7FFF) from the client for example , and get back your number on server side

Re: [Python-Dev] 64-bit values in XML RPC: OverflowError: int exceeds XML-RPC limits

Hello, thank you David and Benjamin for quick response. So my subsequent question is: What can help me solve the "writing" part? Sincerely Peter On 07/15/2009 04:39 PM, R. David Murray wrote: On Wed, 15 Jul 2009 at 09:29, Benjamin Peterson wrote: 2009/7/15 Peter Hanecak : So, my question i

Re: [Python-Dev] 64-bit values in XML RPC: OverflowError: int exceeds XML-RPC limits

On Wed, 15 Jul 2009 at 09:29, Benjamin Peterson wrote: 2009/7/15 Peter Hanecak : So, my question is: In which Python release has been this fix distributed? Python 2.6 and above. But it doesn't solve your problem, since the ticket says it only fixes reading long ints, not writing them. --Dav

Re: [Python-Dev] 64-bit values in XML RPC: OverflowError: int exceeds XML-RPC limits

2009/7/15 Peter Hanecak : > So, my question is: In which Python release has been this fix distributed? Python 2.6 and above. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Uns

[Python-Dev] 64-bit values in XML RPC: OverflowError: int exceeds XML-RPC limits

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 P

Re: [Python-Dev] [Distutils] PEP 376 - from PyPM's point of view

On Wed, Jul 15, 2009 at 12:17 PM, Michael Foord wrote: >> Disclaimer: I've only read the short version, so if some of this is >> covered in the longer explanation, I apologise now. >> >> -1. >> > > I agree. People with versioning issues *should* be using virtualenv. > Let's remove site-packages fr

Re: [Python-Dev] [Distutils] PEP 376 - from PyPM's point of view

On Wed, Jul 15, 2009 at 12:10 PM, Paul Moore wrote: > > Disclaimer: I've only read the short version, so if some of this is > covered in the longer explanation, I apologise now. Next time I won't put a short version ;) > > PEP 376 support has added a requirement for 3 additional methods to > the

Re: [Python-Dev] Add an ExecutionLoader abc to importlib or to runpy?

Antoine Pitrou wrote: > I am not sure when this discussion started. Are you replying to a 3 month-old > message of yours? :) That depends on how you define the beginning of the discussion... However, the fact that importlib doesn't implement the comparatively recent get_filename() optional extens

Re: [Python-Dev] 2.6 object.__init__ & deling __new__

Dino Viehland wrote: > Based upon the behavior I'm seeing it seems to me that the > presence of __new__ / __init__ must be getting cached somewhere > and the deletion isn't updating the cache and that's specifically > what struck me as odd here. Digging through typeobject.c, it isn't clear to me w

Re: [Python-Dev] Add an ExecutionLoader abc to importlib or to runpy?

2009/7/15 Brett Cannon : > 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 i

Re: [Python-Dev] Add an ExecutionLoader abc to importlib or to runpy?

Brett Cannon python.org> writes: > > > 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

Re: [Python-Dev] [Distutils] PEP 376 - from PyPM's point of view

Paul Moore wrote: 2009/7/15 Tarek Ziadé : On Tue, Jul 14, 2009 at 2:12 AM, Sridhar Ratnakumar wrote: 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 ins

Re: [Python-Dev] [Distutils] PEP 376 - from PyPM's point of view

2009/7/15 Tarek Ziadé : > On Tue, Jul 14, 2009 at 2:12 AM, Sridhar > Ratnakumar wrote: >> 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

Re: [Python-Dev] PEP 376 - from PyPM's point of view

On Tue, Jul 14, 2009 at 2:12 AM, Sridhar Ratnakumar wrote: > 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

Re: [Python-Dev] 2.6 object.__init__ & deling __new__

P.J. Eby wrote: In effect, 2.6 forces you to have a common known base class *other* than 'object' in order to write co-operative classes. :-( You have to do that anyway if you want to make cooperative calls to any method *other* that __init__. -- Greg