Re: [Python-Dev] special method lookup: how much do we care?

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? ___

Re: [Python-Dev] special method lookup: how much do we care?

2009/5/8 Terry Reedy : > Benjamin Peterson wrote: >> >> 2009/5/8 Daniel Stutzbach : >>> >>> On Fri, May 8, 2009 at 6:14 PM, Benjamin Peterson >>> wrote: Normally special methods use slots of the PyTypeObject struct. typeobject.c looks up all those methods on Python classes correctly

Re: [Python-Dev] special method lookup: how much do we care?

Benjamin Peterson wrote: 2009/5/8 Daniel Stutzbach : On Fri, May 8, 2009 at 6:14 PM, Benjamin Peterson 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__ and __exit__, the compiler

Re: [Python-Dev] special method lookup: how much do we care?

Benjamin Peterson wrote: 2009/5/8 Terry Reedy : 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. T

Re: [Python-Dev] special method lookup: how much do we care?

2009/5/8 Daniel Stutzbach : > On Fri, May 8, 2009 at 6:14 PM, Benjamin Peterson > 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__ and __exit__, the compiler generates byt

Re: [Python-Dev] special method lookup: how much do we care?

On Fri, May 8, 2009 at 6:14 PM, Benjamin Peterson 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__ and __exit__, the compiler generates bytecode > to look them up, and that byte

Re: [Python-Dev] special method lookup: how much do we care?

2009/5/8 Daniel Stutzbach : > On Fri, May 8, 2009 at 1:09 PM, Benjamin Peterson > 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 this is add a new opcode which >> uses _Py

Re: [Python-Dev] special method lookup: how much do we care?

On Fri, May 8, 2009 at 1:09 PM, Benjamin Peterson 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 this is add a new opcode which > uses _PyObject_LookupSpecial, but I don't think

Re: [Python-Dev] special method lookup: how much do we care?

2009/5/8 Terry Reedy : > 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 the way it sho

Re: [Python-Dev] special method lookup: how much do we care?

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

Re: [Python-Dev] Proposed: drop unnecessary "context" pointer from PyGetSetDef

Casey Duncan wrote: I think this is an important feature, which allows you to define generic, reusable getter and setter functions and pass static metadata to them at runtime. Admittedly I have never needed the full pointer, my typical usage is to pass in an offset. I think this should only

[Python-Dev] special method lookup: how much do we care?

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 instruc

Re: [Python-Dev] Proposed: drop unnecessary "context" pointer from PyGetSetDef

On May 4, 2009, at 3:10 AM, Larry Hastings wrote: I should have brought this up to python-dev before--sorry for being so slow. It's already in the tracker for a couple of days: http://bugs.python.org/issue5880 The idea: PyGetSetDef has this "void *closure" field that acts like a conte

Re: [Python-Dev] Easy way to detect filesystem case-sensitivity?

On Fri, May 08, 2009 at 09:52:40AM -0700, Brett Cannon wrote: > Thanks for the help to everyone. I ended up simply taking __file__, making > it all uppercase (or lowercase if it is already uppercase) and then doing > os.path.exists() on the modified name. Seems to work. What if __file__ is on a

Re: [Python-Dev] Easy way to detect filesystem case-sensitivity?

Brett Cannon wrote: On Thu, May 7, 2009 at 18:56, John Arbash Meinel mailto:john.arbash.mei...@gmail.com>> wrote: Andrew Bennetts wrote: > Antoine Pitrou wrote: >> Robert Kern gmail.com > writes: >>> Since one may have more than one filesystem side-by-si

Re: [Python-Dev] Easy way to detect filesystem case-sensitivity?

On Thu, May 7, 2009 at 18:56, John Arbash Meinel < john.arbash.mei...@gmail.com> wrote: > Andrew Bennetts wrote: > > Antoine Pitrou wrote: > >> Robert Kern gmail.com> writes: > >>> Since one may have more than one filesystem side-by-side, this can't be > just > >> be > >>> a system-wide boolean s

[Python-Dev] Summary of Python tracker Issues

ACTIVITY SUMMARY (05/01/09 - 05/08/09) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 2188 open (+45) / 15604 closed (+30) / 17792 total (+75) Open issues with patches: 848 Average

[Python-Dev] feature request 5804

Hello there. I have sumitted the following patch: Add an 'offset' argument to zlib.decompress http://bugs.python.org/issue5804 I'd be interested on getting some more feedback on it. Kristján ___ Python-Dev mailing list Python-Dev@python.org http://mai

Re: [Python-Dev] PEP 383 update: utf8b is now the error handler

Stephen J. Turnbull wrote: > Walter Dörwald writes: > > > "surrogatepass" (for the "don't complain about lone half surrogates" > > handler) and "surrogatereplace" sound OK to me. However the other > > "...replace" handlers are destructive (i.e. when such a "...replace" > > handler is used for

Re: [Python-Dev] py3k build broken

On Fri, May 8, 2009 at 7:23 AM, Tarek Ziadé wrote: > I have fixed configure by runing autoconf, everything should be fine now > > Sorry for the inconvenience. I am the one responsible for this - I did not realize that the generated configure/Makefile were also in the trunk, and my patch did not