Re: [Python-Dev] A wart which should have been repaired in 3.0?

>> See for what I think is a function >> with more predictable behavior given that we are discussing paths and >> not just strings. Martin> See above: the function works for lists as well. But as you yourself pointed out, Python lacks a reliable

Re: [Python-Dev] A wart which should have been repaired in 3.0?

> Martin> I don't think any change is necessary. os.path.commonprefix > Martin> works just fine on path components: > ... > > Ummm... > > >>> os.path.commonprefix(["/export/home", "/etc/passwd"]) > '/e' This calls it with strings, not with path components. As I said, it works

Re: [Python-Dev] A wart which should have been repaired in 3.0?

> "skip" == skip writes: Martin> I don't think any change is necessary. os.path.commonprefix Martin> works just fine on path components: skip> Ummm... >>> os.path.commonprefix(["/export/home", "/etc/passwd"]) '/e' skip> I suppose that's correct given the defined be

Re: [Python-Dev] A wart which should have been repaired in 3.0?

Martin> I don't think any change is necessary. os.path.commonprefix Martin> works just fine on path components: ... Ummm... >>> os.path.commonprefix(["/export/home", "/etc/passwd"]) '/e' I suppose that's correct given the defined behavior of the function, but it certainly do

Re: [Python-Dev] Call PyType_Ready on builtin types during interpreter startup?

On Sun, Dec 28, 2008 at 5:09 AM, Nick Coghlan wrote: > Nick Coghlan wrote: >> Nick Coghlan wrote: >>> Is there a specific reason for not fully initialising the builtin types? >>> Or should we be calling PyType_Ready on each of them from _PyBuiltin_Init? >> >> I need to correct this slightly: some

Re: [Python-Dev] A wart which should have been repaired in 3.0?

> I'm all for breaking backwards compatibility when it allows some genuine > improvements that would otherwise be impossible, but in this particular > case a little API bloat seems like the least of the available evils :) I don't think any change is necessary. os.path.commonprefix works just fine

[Python-Dev] Use -M option on buildbots?

Hi all, Could we use the -M option (with a suitable value depending on the amount of physical RAM) for regression tests on the buildbots? It would help avoid the kind of situation described in http://bugs.python.org/issue3700 cheers Antoine. ___ Pyth

Re: [Python-Dev] Call PyType_Ready on builtin types during interpreter startup?

Nick Coghlan wrote: Nick Coghlan wrote: Rather than playing whack-a-mole with this, does anyone have any ideas on how to systematically find types which are defined in the core, but are missing an explicit PyType_Ready call? (I guess one way would be to remove all the implicit calls in a local b

Re: [Python-Dev] Call PyType_Ready on builtin types during interpreter startup?

Nick Coghlan wrote: > Rather than playing whack-a-mole with this, does anyone have any ideas > on how to systematically find types which are defined in the core, but > are missing an explicit PyType_Ready call? (I guess one way would be to > remove all the implicit calls in a local build and see wh

Re: [Python-Dev] Call PyType_Ready on builtin types during interpreter startup?

Nick Coghlan wrote: > Nick Coghlan wrote: >> Is there a specific reason for not fully initialising the builtin types? >> Or should we be calling PyType_Ready on each of them from _PyBuiltin_Init? > > I need to correct this slightly: some builtin types *are* initialised > properly by _Py_ReadyTypes

Re: [Python-Dev] Hello everyone + little question around Cpython/stackless

Hello, > I'm currently studying all I can find on stackless python, PYPY and the > concepts they've brought to Python, and so far I wonder : since > stackless python claims to be 100% compatible with CPython's extensions, > faster, and brings lots of fun stuffs (tasklets, coroutines and no C

Re: [Python-Dev] A wart which should have been repaired in 3.0?

Antoine Pitrou wrote: > Le dimanche 28 décembre 2008 à 16:26 +1000, Nick Coghlan a écrit : >> If we're going to end up with two functions anyway, why mess with the >> one which is already there and in use for real programs? > > Well, agreed. > I was just hoping we could get away with "fixing" the

Re: [Python-Dev] A wart which should have been repaired in 3.0?

Le dimanche 28 décembre 2008 à 16:26 +1000, Nick Coghlan a écrit : > If we're going to end up with two functions anyway, why mess with the > one which is already there and in use for real programs? Well, agreed. I was just hoping we could get away with "fixing" the existing function and voilà :)