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
On Tue, Jul 14, 2009 at 2:12 AM, Sridhar
Ratnakumarsridh...@activestate.com 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
2009/7/15 Tarek Ziadé ziade.ta...@gmail.com:
On Tue, Jul 14, 2009 at 2:12 AM, Sridhar
Ratnakumarsridh...@activestate.com 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
Paul Moore wrote:
2009/7/15 Tarek Ziadé ziade.ta...@gmail.com:
On Tue, Jul 14, 2009 at 2:12 AM, Sridhar
Ratnakumarsridh...@activestate.com wrote:
Here are my comments regarding PEP 376 with respect to PyPM (the Python
package manager being developd at ActiveState)
Multiple versions:
Brett Cannon brett at 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
2009/7/15 Brett Cannon br...@python.org:
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
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 why
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
On Wed, Jul 15, 2009 at 12:10 PM, Paul Moorep.f.mo...@gmail.com 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
On Wed, Jul 15, 2009 at 12:17 PM, Michael
Foordfuzzy...@voidspace.org.uk 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
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
2009/7/15 Peter Hanecak peter.hane...@alcatel-lucent.sk:
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
On Wed, 15 Jul 2009 at 09:29, Benjamin Peterson wrote:
2009/7/15 Peter Hanecak peter.hane...@alcatel-lucent.sk:
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
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
On Wed, Jul 15, 2009 at 4:42 PM, Peter
Hanecakpeter.hane...@alcatel-lucent.sk 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
On Wed, Jul 15, 2009 at 16:42, Peter
Hanecakpeter.hane...@alcatel-lucent.sk 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
2009/7/15 Tarek Ziadé ziade.ta...@gmail.com:
On Wed, Jul 15, 2009 at 12:17 PM, Michael
Foordfuzzy...@voidspace.org.uk 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
2009/7/15 Nick Coghlan ncogh...@gmail.com:
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
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
On Wed, Jul 15, 2009 at 5:14 PM, Paul Moorep.f.mo...@gmail.com wrote:
2009/7/15 Tarek Ziadé ziade.ta...@gmail.com:
On Wed, Jul 15, 2009 at 12:17 PM, Michael
Foordfuzzy...@voidspace.org.uk wrote:
Disclaimer: I've only read the short version, so if some of this is
covered in the longer
On Wed, Jul 15, 2009 at 11:00 PM, Tarek Ziadéziade.ta...@gmail.com wrote:
On Wed, Jul 15, 2009 at 12:10 PM, Paul Moorep.f.mo...@gmail.com 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
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__.
2009/7/15 David Cournapeau courn...@gmail.com:
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
On Wed, Jul 15, 2009 at 5:16 PM, Joachim Königh...@online.de 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
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
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
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?
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
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
2009/7/15 P.J. Eby p...@telecommunity.com:
[...]
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
On Wed, 15 Jul 2009 02:01:24 -0700, Tarek Ziadé ziade.ta...@gmail.com
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
2009/7/15 P.J. Eby p...@telecommunity.com:
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
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
On Wed, 15 Jul 2009 08:22:03 -0700, David Cournapeau courn...@gmail.com
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
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
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
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
On Wed, Jul 15, 2009 at 06:51, Nick Coghlan ncogh...@gmail.com 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
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
previous to
Brett Cannon wrote:
On Wed, Jul 15, 2009 at 06:51, Nick Coghlan ncogh...@gmail.com
mailto:ncogh...@gmail.com 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
2009/7/15 Chris McDonough chr...@plope.com:
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
On Wed, 15 Jul 2009 13:47:35 -0400, Chris McDonough chr...@plope.com
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. :-)
2009/7/15 Sridhar Ratnakumar sridh...@activestate.com:
On Wed, 15 Jul 2009 02:01:24 -0700, Tarek Ziadé ziade.ta...@gmail.com
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
43 matches
Mail list logo
