On Sun, May 10, 2009 11:51PM, Nick Coghlan wrote:
However lots of developers rely on CPython ref counting as well, no
matter how many times they're told not to do that if they want to
support alternative interpreters.
Cheers,
Nick.
From socket.py:
# Wrapper around platform socket objects.
Benjamin Peterson wrote:
A while ago, Guido declared that all special method lookups on
new-style classes bypass __getattr__ and __getattribute__. This almost
completely consistent now, and I've been working on patching up a few
incorrect cases. I've know hit __enter__ and __exit__. The
Nick Coghlan wrote:
Benjamin Peterson wrote:
A while ago, Guido declared that all special method lookups on
new-style classes bypass __getattr__ and __getattribute__. This almost
completely consistent now, and I've been working on patching up a few
incorrect cases. I've know hit __enter__
Michael Foord wrote:
Nick Coghlan wrote:
Benjamin Peterson wrote:
A while ago, Guido declared that all special method lookups on
new-style classes bypass __getattr__ and __getattribute__. This almost
completely consistent now, and I've been working on patching up a few
incorrect cases. I've
Benjamin Peterson wrote:
__reduce__
__setstate__
__reversed__
__length_hint__
__sizeof__
No, it's easier to just use _PyObject_LookupSpecial there.
Does that mean that the above 5 'work correctly' (or can easily be made
to do so)? Leaving just __entry__ and __exit__ as problems?
2009/5/9 Terry Reedy tjre...@udel.edu:
Benjamin Peterson wrote:
__reduce__
__setstate__
__reversed__
__length_hint__
__sizeof__
No, it's easier to just use _PyObject_LookupSpecial there.
Does that mean that the above 5 'work correctly' (or can easily be made to
do so)? Leaving just
Benjamin Peterson schrieb:
A while ago, Guido declared that all special method lookups on
new-style classes bypass __getattr__ and __getattribute__. This almost
completely consistent now, and I've been working on patching up a few
incorrect cases. I've know hit __enter__ and __exit__. The
Are we solving an actual problem by changing the
behaviour here, or is it just a case of foolish
consistency?
Seems to me that trying to pin down exactly what
constitutes a special method is a fool's errand,
especially if you want it to include __enter__ and
__exit__ but not __reduce__, etc.
--
2009/5/9 Greg Ewing greg.ew...@canterbury.ac.nz:
Are we solving an actual problem by changing the
behaviour here, or is it just a case of foolish
consistency?
No implementation detail is obscure enough.
For example, Maciek Fijalkowski of PyPy told me that he cares about
this because someone
A while ago, Guido declared that all special method lookups on
new-style classes bypass __getattr__ and __getattribute__. This almost
completely consistent now, and I've been working on patching up a few
incorrect cases. I've know hit __enter__ and __exit__. The compiler
generates LOAD_ATTR
Benjamin Peterson wrote:
A while ago, Guido declared that all special method lookups on
new-style classes bypass __getattr__ and __getattribute__. This almost
completely consistent now, and I've been working on patching up a few
incorrect cases. I've know hit __enter__ and __exit__. The compiler
2009/5/8 Terry Reedy tjre...@udel.edu:
2. I am puzzled why those two methods should be extra special, but don't
know enough to say more.
They're not supposed to be special, which is the reason for this
message. :) Currently the interpreter will call __getattr__ when
looking them up. This is not
On Fri, May 8, 2009 at 1:09 PM, Benjamin Peterson benja...@python.orgwrote:
I've know hit __enter__ and __exit__. The compiler
generates LOAD_ATTR instructions for these, so it uses the normal
lookup. The only way I can see to fix this is add a new opcode which
uses _PyObject_LookupSpecial,
2009/5/8 Daniel Stutzbach dan...@stutzbachenterprises.com:
On Fri, May 8, 2009 at 1:09 PM, Benjamin Peterson benja...@python.org
wrote:
I've know hit __enter__ and __exit__. The compiler
generates LOAD_ATTR instructions for these, so it uses the normal
lookup. The only way I can see to fix
2009/5/8 Daniel Stutzbach dan...@stutzbachenterprises.com:
On Fri, May 8, 2009 at 6:14 PM, Benjamin Peterson benja...@python.org
wrote:
Normally special methods use slots of the PyTypeObject struct.
typeobject.c looks up all those methods on Python classes correctly.
In the case of __enter__
Benjamin Peterson wrote:
2009/5/8 Terry Reedy tjre...@udel.edu:
2. I am puzzled why those two methods should be extra special, but don't
know enough to say more.
They're not supposed to be special, which is the reason for this
message. :) Currently the interpreter will call __getattr__ when
Benjamin Peterson wrote:
2009/5/8 Daniel Stutzbach dan...@stutzbachenterprises.com:
On Fri, May 8, 2009 at 6:14 PM, Benjamin Peterson benja...@python.org
wrote:
Normally special methods use slots of the PyTypeObject struct.
typeobject.c looks up all those methods on Python classes correctly.
2009/5/8 Terry Reedy tjre...@udel.edu:
Benjamin Peterson wrote:
2009/5/8 Daniel Stutzbach dan...@stutzbachenterprises.com:
On Fri, May 8, 2009 at 6:14 PM, Benjamin Peterson benja...@python.org
wrote:
Normally special methods use slots of the PyTypeObject struct.
typeobject.c looks up all
18 matches
Mail list logo
