Re: [Python-Dev] Python 3, new-style classes and class

21 Nov 2011

      On 20/11/2011 21:41, Guido van Rossum wrote:
...
On Sun, Nov 20, 2011 at 10:44 AM, Michael Foord
  wrote:
...
On 20 Nov 2011, at 16:35, Guido van Rossum wrote:
...
Um, what?! __class__ *already* has a special meaning. Those examples
violate that meaning. No wonder they get garbage results.
The correct way to override isinstance is explained here:
http://www.python.org/dev/peps/pep-3119/#overloading-isinstance-and-issubcla...
.
Proxy classes have been using __class__ as a descriptor for this purpose for years before ABCs were introduced. This worked fine up until Python 3 where the compiler magic broke it when super is used. That is now fixed anyway.
Hm, okay. Though it's disheartening that it took three releases of 3.x
to figure this out. And there was a PEP even!
...
If I understand correctly, ABCs are great for allowing classes of objects to pass isinstance checks (etc) - what proxy, lazy and mock objects need is to be able to allow individual instances to pass different isinstance checks.
Ah, oops. Yes, __instancecheck__ is for the class to override
isinstance(inst, cls); for the *instance* to override apparently
you'll need to mess with __class__.
I guess my request at this point would be to replace '@__class__' with
some other *legal* __identifier__ that doesn't clash with existing use
-- I don't like the arbitrary use of @ here.
The problem with using a valid identifier name is that it leaves open 
the possibility of the same "broken" behaviour (removing from the class 
namespace) for whatever name we pick.

That means we should document the name used - and it's then more likely 
that users will start to rely on this odd (but documented) internal 
implementation detail. This in turn puts a burden on other 
implementations to use the same mechanism, even if this is less than 
ideal for them.

This is why a deliberately invalid identifier was picked.

All the best,

Michael Foord
...
--Guido
...
All the best,
Michael Foord
...
--Guido
On Sat, Nov 19, 2011 at 6:13 PM, Michael Foord
  wrote:
...
On 19 November 2011 23:11, Vinay Sajip  wrote:
...
Michael Foord  writes:
...
That works fine in Python 3 (mock.Mock does it):
>>>  class Foo(object):
...  @property
...  def __class__(self):
...   return int
...
  >>>  a = Foo()
  >>>  isinstance(a, int)
True
  >>>  a.__class__

There must be something else going on here.
Michael, thanks for the quick response. Okay, I'll dig in a bit further:
the
definition in SimpleLazyObject is
__class__ = property(new_method_proxy(operator.attrgetter("__class__")))
so perhaps the problem is something related to the specifics of the
definition.
Here's what I found in initial exploration:
--------------------------------------------------------------------------
Python 2.7.2+ (default, Oct 4 2011, 20:06:09)
[GCC 4.6.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
...
>> from django.utils.functional import SimpleLazyObject
>> fake_bool = SimpleLazyObject(lambda: True)
>> fake_bool.__class__

>> fake_bool.__dict__
{'_setupfunc':, '_wrapped': True}
>> SimpleLazyObject.__dict__
dict_proxy({
    '__module__': 'django.utils.functional',
    '__nonzero__':,
    '__deepcopy__':,
    '__str__':,
    '_setup':,
    '__class__':,
    '__hash__':,
    '__unicode__':,
    '__bool__':,
    '__eq__':,
    '__doc__': '\n A lazy object initialised from any function.\n\n
        Designed for compound objects of unknown type. For builtins or
        objects of\n known type, use django.utils.functional.lazy.\n ',
    '__init__':
})

Python 3.2.2 (default, Sep 5 2011, 21:17:14)
[GCC 4.6.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
...
>> from django.utils.functional import SimpleLazyObject
>> fake_bool = SimpleLazyObject(lambda : True)
>> fake_bool.__class__

>> fake_bool.__dict__
{
    '_setupfunc':,
    '_wrapped':

Re: [Python-Dev] Python 3, new-style classes and __class__

Michael Foord

Re: [Python-Dev] Python 3, new-style classes and class