Prev: imports again
Next: python as pen and paper substitute
From: Steven D'Aprano on 8 Apr 2010 03:07
On Wed, 07 Apr 2010 20:14:23 -0700, Raymond Hettinger wrote:

> [Raymond Hettinger]
>> > If the two collections have unequal sizes, then both ways immediately
>> > return unequal.
>
> [Steven D'Aprano]
>> Perhaps I'm misinterpreting what you are saying, but I can't confirm
>> that behaviour, at least not for subclasses of list:
>
> For doubters, see list_richcompare() in
> http://svn.python.org/view/python/trunk/Objects/listobject.c?
revision=78522&view=markup

So what happens in my example with a subclass that (falsely) reports a
different length even when the lists are the same?

I can guess that perhaps Py_SIZE does not call the subclass __len__
method, and therefore is not fooled by it lying. Is that the case?


--
Steven
From: Terry Reedy on 8 Apr 2010 06:26
On 4/8/2010 3:07 AM, Steven D'Aprano wrote:
> On Wed, 07 Apr 2010 20:14:23 -0700, Raymond Hettinger wrote:
>
>> [Raymond Hettinger]
>>>> If the two collections have unequal sizes, then both ways immediately
>>>> return unequal.
>>
>> [Steven D'Aprano]
>>> Perhaps I'm misinterpreting what you are saying, but I can't confirm
>>> that behaviour, at least not for subclasses of list:
>>
>> For doubters, see list_richcompare() in
>> http://svn.python.org/view/python/trunk/Objects/listobject.c?
> revision=78522&view=markup
>
> So what happens in my example with a subclass that (falsely) reports a
> different length even when the lists are the same?
>
> I can guess that perhaps Py_SIZE does not call the subclass __len__
> method, and therefore is not fooled by it lying. Is that the case?

Adding a print call within __len__ should determine that.



From: Raymond Hettinger on 8 Apr 2010 11:16
[Steven D'Aprano]
> So what happens in my example with a subclass that (falsely) reports a
> different length even when the lists are the same?
>
> I can guess that perhaps Py_SIZE does not call the subclass __len__
> method, and therefore is not fooled by it lying. Is that the case?

Yes. Py_SIZE() gets the actual size of the underlying list.

The methods for most builtin containers typically access the
underlying structure directly. That makes them fast and allows
them to maintain their internal invariants.


Raymond

From: Gabriel Genellina on 8 Apr 2010 19:35
En Thu, 08 Apr 2010 04:07:53 -0300, Steven D'Aprano
<steven(a)remove.this.cybersource.com.au> escribi�:
> On Wed, 07 Apr 2010 20:14:23 -0700, Raymond Hettinger wrote:
>> [Raymond Hettinger]

>>> > If the two collections have unequal sizes, then both ways immediately
>>> > return unequal.
>>
>> [Steven D'Aprano]
>>> Perhaps I'm misinterpreting what you are saying, but I can't confirm
>>> that behaviour, at least not for subclasses of list:
>>
>> For doubters, see list_richcompare() in
>> http://svn.python.org/view/python/trunk/Objects/listobject.c?
> revision=78522&view=markup
>
> So what happens in my example with a subclass that (falsely) reports a
> different length even when the lists are the same?
>
> I can guess that perhaps Py_SIZE does not call the subclass __len__
> method, and therefore is not fooled by it lying. Is that the case?

Yes. Py_SIZE is a generic macro, it returns the ob_size field from the
object structure. No method is called at all.

Another example: the print statement bypasses the sys.stdout.write()
method and calls directly fwrite() at the C level when it determines that
sys.stdout is a `file` instance. Even if it's a subclass of file, so
overriding write() in Python code does not work.

The CPython source contains lots of shortcuts like that. Perhaps the
checks should be stricter in some cases, but I imagine it's not so easy to
fix: lots of code was written in the pre-2.2 era, assuming that internal
types were not subclassable.

--
Gabriel Genellina

From: Patrick Maupin on 8 Apr 2010 20:02
On Apr 8, 6:35 pm, "Gabriel Genellina" <gagsl-...(a)yahoo.com.ar> wrote:

> The CPython source contains lots of shortcuts like that. Perhaps the  
> checks should be stricter in some cases, but I imagine it's not so easy to  
> fix: lots of code was written in the pre-2.2 era, assuming that internal  
> types were not subclassable.

I don't know if it's a good "fix" anyway. If you subclass an internal
type, you can certainly supply your own rich comparison methods, which
would (IMO) put the CPU computation burden where it belongs if you
decide to do something goofy like subclass a list and then override
__len__.

Regards,
Pat
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: imports again
Next: python as pen and paper substitute