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
[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
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
[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 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
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 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
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
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
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
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
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:
http://mail.python.org/mailman/opt
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
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
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
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
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
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
Thomas Heller wrote:
>>> return Py_BuildValue("s",
>>> ver.dwMajorVersion,
>>> ver.dwMinorVersion,
>>> ver.dwBuildNumber,
>>> ver.dwPlatformId,
>>> ver.szCSDVersion);
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
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:
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
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
23 matches
Mail list logo
