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

2008-12-28 Thread Antoine Pitrou 
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à :)



___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2008-12-28 Thread Nick Coghlan 
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 existing function
> and voilà :)

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 :)

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
---
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2008-12-28 Thread Antoine Pitrou 

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 
> stack), how comes it hasn't been merged back, to become the standard 
> 'fast' python implementation ?

I'm not sure Stackless ever claimed to be faster than CPython for standard tasks
(i.e., not coroutine-related). Do you have any pointers to this?

As for coroutines, the greenlets (*) package is said to bring them to the
standard interpreter.

(*) http://codespeak.net/py/dist/greenlet.html

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2008-12-28 Thread Nick Coghlan 
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.
> 
> So the question is actually whether or not the missing builtin types
> should be added to that function.

I'm probably going to fix the specific problem with hashing of range
objects in Py3k just by initialising xrange/range properly in
_Py_ReadyTypes.

However, I wonder how many other builtin types have the same problem -
for example, the enumerate type is also missing a call to PyType_Ready:

Python 3.1a0 (py3k, Dec 14 2008, 21:35:11)
[GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> x = enumerate([])
>>> hash(x)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: unhashable type: 'enumerate'
>>> enumerate.__name__ # implicit call to PyType_Ready
'enumerate'
>>> hash(x)
-1212398692

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 what blows up...
that seems a little drastic though)

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
---
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2008-12-28 Thread Nick Coghlan 
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 what blows up...
> that seems a little drastic though)

The whack-a-mole tactic did pick up a couple more though - the two
"builtin" types that iter() can return (the basic sequence iterator and
the callable with sentinel result iterator).

Perhaps the path of least resistance is to change PyObject_Hash to be
yet another place where PyType_Ready will be called implicitly if it
hasn't been called already?

That approach would get us back to the Python 2.x status quo where
calling PyType_Ready was only absolutely essential if you wanted to
correctly inherit a slot from a type other than object itself.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
---
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2008-12-28 Thread Eric Smith 

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 build and see what blows up...
that seems a little drastic though)


The whack-a-mole tactic did pick up a couple more though - the two
"builtin" types that iter() can return (the basic sequence iterator and
the callable with sentinel result iterator).

Perhaps the path of least resistance is to change PyObject_Hash to be
yet another place where PyType_Ready will be called implicitly if it
hasn't been called already?


I think that's the best thing to do. It would bring PyObject_Hash in 
line with PyObject_Format, for example.


Eric.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2008-12-28 Thread Antoine Pitrou 
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.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2008-12-28 Thread Martin v. Löwis 
> 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 on path components:

py> p = ["/usr/bin/ls", "/usr/bin/ln"]
py> os.path.commonprefix([f.split('/') for f in p])
['', 'usr', 'bin']
py> p.append("/usr/local/bin/ls")
py> os.path.commonprefix([f.split('/') for f in p])
['', 'usr']

Of course, using it that way would require a library function that
reliably splits a path into components; I think one would have to do
abspath on arbitrary inputs.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2008-12-28 Thread Adam Olsen 
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 builtin types *are* initialised
>> properly by _Py_ReadyTypes.
>>
>> So the question is actually whether or not the missing builtin types
>> should be added to that function.
>
> I'm probably going to fix the specific problem with hashing of range
> objects in Py3k just by initialising xrange/range properly in
> _Py_ReadyTypes.
>
> However, I wonder how many other builtin types have the same problem -
> for example, the enumerate type is also missing a call to PyType_Ready:
>
> Python 3.1a0 (py3k, Dec 14 2008, 21:35:11)
> [GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu3)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
 x = enumerate([])
 hash(x)
> Traceback (most recent call last):
>  File "", line 1, in 
> TypeError: unhashable type: 'enumerate'
 enumerate.__name__ # implicit call to PyType_Ready
> 'enumerate'
 hash(x)
> -1212398692
>
> 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 what blows up...
> that seems a little drastic though)

What I did with safethread was replace the implicit calls with
assertions.  That with the test suite should pick everything up.


-- 
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2008-12-28 Thread skip 

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 doesn't seem to be very path-like to me.

Martin> Of course, using it that way would require a library function
Martin> that reliably splits a path into components; I think one would
Martin> have to do abspath on arbitrary inputs.

See  for what I think is a function with
more predictable behavior given that we are discussing paths and not just
strings.

Skip
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2008-12-28 Thread skip 
> "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 behavior of the
skip> function, but it certainly doesn't seem to be very path-like to
skip> me.

I should also point out that most people will not have the foresight to use
it the way Martin demonstrated.  Documentation or not, I'll be a fair
fraction of all usage assumes the return value represents a valid path.

Martin> Of course, using it that way would require a library function
Martin> that reliably splits a path into components; I think one would
Martin> have to do abspath on arbitrary inputs.

Kinda what I think os.path.split ought to do.  Should I tackle that next?
;-)

Skip

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2008-12-28 Thread Martin v. Löwis 
> 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 fine for path components:

py> os.path.commonprefix([f.split('/') for f in ["/export/home",
"/etc/passwd"]])
['']

> See  for what I think is a function with
> more predictable behavior given that we are discussing paths and not just
> strings.

See above: the function works for lists as well.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2008-12-28 Thread skip 

>> 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 split function for
filesystem paths.  The patch implements different versions for Windows and
other platforms because Python supports two separators on that platform.

Skip
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com