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 t
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.
> a
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:
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 unrela
Thomas Heller wrote:
>>> return Py_BuildValue("s",
>>> ver.dwMajorVersion,
>>> ver.dwMinorVersion,
>>> ver.dwBuildNumber,
>>> ver.dwPlatformId,
>>> ver.szCSDVersion);
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 "", line 1, in ?ValueError: inval
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 thi
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 Pyth
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 rema
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, b
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
I just completed the repository import;
write access to the projects repository is back.
Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/opt
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 s
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 mec
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 sourc
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 diff
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 de
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 O
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/libpthre
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 P
[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
Tim Peters wrote:
> #ifdef __VMS
> extern char* vms__StdioReadline(FILE *sys_stdin, FILE *sys_stdout,
> char *prompt);
> #endif
>
> may be (it's apparently not checked in, and Google couldn't find it
> either). Does anyone still work on the VMS port? If not, screw it
> ;-)
I would have no conce
23 matches
Mail list logo
