(original) (raw)
On 19 November 2011 23:11, Vinay Sajip <vinay_sajip@yahoo.co.uk> wrote:
The Python compiler can do strange things with assignment to \_\_class\_\_ in the presence of super. This issue has now been fixed, but it may be what is biting you:
��� http://bugs.python.org/issue12370
If this \*is\* the problem, then see the workaround suggested in the issue. (alias super to \_super in the module scope and use the old style super calling convention.)
Michael
�
Michael Foord <fuzzyman <at> voidspace.org.uk> writes:Michael, thanks for the quick response. Okay, I'll dig in a bit further: the
> 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\_\_
> <class 'int'>
>
> There must be something else going on here.
>
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\_\_
<type 'bool'>
>>> fake\_bool.\_\_dict\_\_
{'\_setupfunc': <function <lambda> at 0xca9ed8>, '\_wrapped': True}
>>> SimpleLazyObject.\_\_dict\_\_
dict\_proxy({
� �'\_\_module\_\_': 'django.utils.functional',
� �'\_\_nonzero\_\_': <function inner at 0xca9de8>,
� �'\_\_deepcopy\_\_': <function \_\_deepcopy\_\_ at 0xca9c08>,
� �'\_\_str\_\_': <function inner at 0xca9b18>,
� �'\_setup': <function \_setup at 0xca9aa0>,
� �'\_\_class\_\_': <property object at 0xca5730>,
� �'\_\_hash\_\_': <function inner at 0xca9d70>,
� �'\_\_unicode\_\_': <function inner at 0xca9b90>,
� �'\_\_bool\_\_': <function inner at 0xca9de8>,
� �'\_\_eq\_\_': <function inner at 0xca9cf8>,
� �'\_\_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\_\_': <function \_\_init\_\_ at 0xca9a28>
})
\--------------------------------------------------------------------------
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\_\_
<class 'django.utils.functional.SimpleLazyObject'>
>>> fake\_bool.\_\_dict\_\_
{
� �'\_setupfunc': <function <lambda> at 0x1c36ea8>,
� �'\_wrapped': <object object at 0x1d88b70>
}
>>> SimpleLazyObject.\_\_dict\_\_
dict\_proxy({
� �'\_\_module\_\_': 'django.utils.functional',
� �'\_\_nonzero\_\_': <function inner at 0x1f56490>,
� �'\_\_deepcopy\_\_': <function \_\_deepcopy\_\_ at 0x1f562f8>,
� �'\_\_str\_\_': <function inner at 0x1f561e8>,
� �'\_setup': <function \_setup at 0x1f56160>,
� �'\_\_hash\_\_': <function inner at 0x1f56408>,
� �'\_\_unicode\_\_': <function inner at 0x1f56270>,
� �'\_\_bool\_\_': <function inner at 0x1f56490>,
� �'\_\_eq\_\_': <function inner at 0x1f56380>,
� �'\_\_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\_\_': <function \_\_init\_\_ at 0x1f560d8>
})
\--------------------------------------------------------------------------
In Python 3, there's no \_\_class\_\_ property as there is in Python 2,
the fake\_bool's type isn't bool, and the callable to set up the wrapped
object never gets called (which is why \_wrapped is not set to True, but to
an anonymous object - this is set in SimpleLazyObject.\_\_init\_\_).
The Python compiler can do strange things with assignment to \_\_class\_\_ in the presence of super. This issue has now been fixed, but it may be what is biting you:
��� http://bugs.python.org/issue12370
If this \*is\* the problem, then see the workaround suggested in the issue. (alias super to \_super in the module scope and use the old style super calling convention.)
Michael
�
Puzzling!
Regards,
Vinay Sajip
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
--
http://www.voidspace.org.uk/
May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html