Brett Cannon wrote:
- expat
Not sure whether you mean the Expat parser proper here, or the pyexpat
module: both are externally maintained, also; pyexpat is part of PyXML.
OTOH, people can just consider PyXML to be part of Python, and I
synchronize the Python sources with the PyXML sources from
On 4/9/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Brett Cannon wrote:
- expat
Not sure whether you mean the Expat parser proper here, or the pyexpat
module: both are externally maintained,
I was thinking the parser, but if pyexpat is externally maintained,
then both of them.
also;
Tim Peters wrote:
Anyone: is it a bug or a feature that a socket.connect() call
that times out may raise either socket.timeout or socket.error?
Trent's box raises socket.error. On my box, when I set a timeout
value small enough so that it _does_ time out, socket.timeout is
raised:
That
I will need to turn off subversion write access for an hour or so
today, from about 18:00 GMT to 19:00 GMT. During that time, I will
load the stackless svn dumpfile into the repository. I don't expect
problems, but if there are any, I want to be able to revert to a
backup, without losing any
Thomas Heller wrote:
return Py_BuildValue(s,
ver.dwMajorVersion,
ver.dwMinorVersion,
ver.dwBuildNumber,
ver.dwPlatformId,
ver.szCSDVersion);
The crash
Someone on IRC (who refuses to report bugs on sourceforge, so I guess he wants to remain anonymous) came with this very amusing bug: int(), when raising ValueError, doesn't quote (or repr(), rather) its arguments:
int()Traceback (most recent call last): File stdin, line 1, in ?ValueError: invalid
On 4/8/06, Brett Cannon [EMAIL PROTECTED] wrote:
Anyway, here is a list of the packages that I think have outside
maintenance (or at least have been at some point). Anyone who has
info on them that I need, please let me know the details. Also, if I
missed any, obviously speak up:
I think
At 02:47 PM 4/8/2006 -0700, Brett Cannon wrote:
Do people think we need to document the version that has
been imported into Python and when that was done as well?
Definitely. Better yet, in 2.5 I'd like to have the version information
embedded in a PKG-INFO file that gets installed with
Go ahead and fix it. This was probably never changed since 1990 or
so... Do expect some code brakage where people rely on the old
behavior. :-(
--Guido
On 4/9/06, Thomas Wouters [EMAIL PROTECTED] wrote:
Someone on IRC (who refuses to report bugs on sourceforge, so I guess he
wants to remain
Recently I downloaded Python 2.5a1 and I have started playing with it. In
doing so,
I have been looking at the Demo directory in the distribution, to check if
demos
of the new features have been added there. So, I rediscovered brownian.py,
in Demo/tkinter/guido. I just love this little program,
Phillip J. Eby wrote:
It would be good if we could have separate setup.py files for external
libraries, not only because of the ability to get PKG-INFO installed, but
also because then OS vendors that split those externals out into separate
system packages wouldn't need to jump through as
I just completed the repository import;
write access to the projects repository is back.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
At 07:56 PM 4/9/2006 +0200, Martin v. Löwis wrote:
Phillip J. Eby wrote:
It would be good if we could have separate setup.py files for external
libraries, not only because of the ability to get PKG-INFO installed, but
also because then OS vendors that split those externals out into separate
Phillip J. Eby wrote:
I was hoping that we had reached a point where setup.py could simply
become the One Obvious Way to do it, in which case the One Obvious Way
to bundle formerly-external libraries would be to bundle their setup
scripts.
Well, setup.py cannot (yet?) replace the other
Guido van Rossum wrote:
Go ahead and fix it. This was probably never changed since 1990 or
so... Do expect some code brakage where people rely on the old
behavior. :-(
--Guido
On 4/9/06, Thomas Wouters [EMAIL PROTECTED] wrote:
Someone on IRC (who refuses to report bugs on sourceforge, so
On Sun, Apr 09, 2006 at 02:48:47PM -0400, Phillip J. Eby wrote:
At 07:56 PM 4/9/2006 +0200, Martin v. Löwis wrote:
[...]
-1. These aren't external libraries; they are part of Python.
They *were* external libraries. Also, many OS vendors nonetheless split
the standard library into different
On Monday 10 April 2006 04:48, Phillip J. Eby wrote:
They *were* external libraries. Also, many OS vendors nonetheless
split the standard library into different system packages, e.g.
Debian's longstanding tradition of excising the distutils into a
separate python-dev package.
Ubuntu (a
At 09:35 AM 4/10/2006 +1000, Andrew Bennetts wrote:
On Sun, Apr 09, 2006 at 02:48:47PM -0400, Phillip J. Eby wrote:
At 07:56 PM 4/9/2006 +0200, Martin v. Löwis wrote:
[...]
-1. These aren't external libraries; they are part of Python.
They *were* external libraries. Also, many OS vendors
On Linux, In HEAD 2.5, but only with the non-debug version, I get a
segfault when I do this:
'''
... '''
It seems to occur for any triple-quoted string crossing a line
boundary. A bit of the stack trace:
#0 0x40030087 in pthread_mutex_lock () from /lib/i686/libpthread.so.0
#1 0x4207ad18 in
[Guido]
On Linux, In HEAD 2.5, but only with the non-debug version, I get a
segfault when I do this:
'''
... '''
It seems to occur for any triple-quoted string crossing a line
boundary. A bit of the stack trace:
#0 0x40030087 in pthread_mutex_lock () from /lib/i686/libpthread.so.0
#1
On 4/9/06, Tim Peters [EMAIL PROTECTED] wrote:
[Guido]
On Linux, In HEAD 2.5, but only with the non-debug version, I get a
segfault when I do this:
'''
... '''
It rings a bell here only in that the front end had lots of
allocate-versus-free mismatches between the PyObject_ and
[Neal Norwitz]
http://python.org/sf/1467512 fixes the problem for me on linux. It
converts all the PyMem_* APIs to PyObject_* APIs. Assigned to Guido
until he changes that. :-)
Thanks! I didn't take that route, instead not changing anything I
didn't take the time to understand first. For
22 matches
Mail list logo
