Exception for setting attributes of built-in type

[Seo Sanghyeon-3]

Exception for setting attributes of built-in type differs between
CPython and IronPython. This is not purely theoretical, as
zope.interface tries to set Implements declaration as __implemented__
attribute of built-in type object, and excepts TypeError.

Python 2.6.1
>>> object.flag = True
TypeError: can't set attributes of built-in/extension type 'object'

IronPython 2.6
>>> object.flag = True
AttributeError: 'object' object has no attribute 'flag'

I was surprised that CPython raises TypeError. Library Reference seems
to mention it here:

exception AttributeError
Raised when an attribute reference or assignment fails. (When an
object does not support attribute references or attribute assignments
at all, TypeError is raised.)
http://docs.python.org/library/exceptions.html

What does it mean that "an object does not support attribute
references or attribute assignments at all"?

--
Seo Sanghyeon
_______________________________________________
Users mailing list
Users@...
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

[Guido van Rossum]

On Sun, Jun 14, 2009 at 3:42 PM, MRAB<python@...> wrote:

> Seo Sanghyeon wrote:
>>
>> Exception for setting attributes of built-in type differs between
>> CPython and IronPython. This is not purely theoretical, as
>> zope.interface tries to set Implements declaration as __implemented__
>> attribute of built-in type object, and excepts TypeError.
>>
>> Python 2.6.1
>>>>>
>>>>> object.flag = True
>>
>> TypeError: can't set attributes of built-in/extension type 'object'
>>
>> IronPython 2.6
>>>>>
>>>>> object.flag = True
>>
>> AttributeError: 'object' object has no attribute 'flag'
>>
>> I was surprised that CPython raises TypeError. Library Reference seems
>> to mention it here:
>>
>> exception AttributeError
>> Raised when an attribute reference or assignment fails. (When an
>> object does not support attribute references or attribute assignments
>> at all, TypeError is raised.)
>> http://docs.python.org/library/exceptions.html
>>
>> What does it mean that "an object does not support attribute
>> references or attribute assignments at all"?
>>
> Here's my guess:
>
> Some objects have a fixed (and possibly empty) set of attributes.
> Attempting to add a new attribute or get a non-existent attribute raises
> an AttributeError.
>
> Other objects, such as types (are there any that aren't types?), don't
> have attributes at all. Attempting to add or get an attribute raises a
> TypeError.

This particular error comes (grep tells me :-) from type_setattro() in
Objects/typeobject.c. It makes a specific check whether the type
object whose attribute you want to set is a "built-in type" (this is
done by checking the HEAPTYPE flag, which is never set for built-in
types and always for user-defined types). For built-in types it
disallows setting attributes. This is a pure policy issue: it prevents
different 3rd party modules to make incompatible modifications of
built-in types.

In general, CPython isn't always consistent in raising AttributeError
and TypeError when it comes to such policy issues: there are various
places that raise TypeError in typeobject.c (and probably elsewhere)
that simply forbid setting a specific attribute (another example is
__name__).

Given how poorly Python exceptions are specified in general, I don't
want to hold IronPython to this standard (nor CPython :-). The reason
this breaks zope.interfaces in IronPython is probably just that
zope.interfaces was primarily written/tested against CPython.

Going back to the phrase quoted from the reference manual, it's
probably referring to the possibility that a type's tp_getattro slot
is NULL; but even so it's wrong: PyObject_GetAttr() raises
AttributeError in this case.

Uselessly y'rs,

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
Users mailing list
Users@...
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

[Guido van Rossum]

On Sun, Jun 14, 2009 at 4:19 PM, Guido van Rossum<guido@...> wrote:
> In general, CPython isn't always consistent in raising AttributeError
> and TypeError when it comes to such policy issues: there are various
> places that raise TypeError in typeobject.c (and probably elsewhere)
> that simply forbid setting a specific attribute (another example is
> __name__).

I should add that this policy is also forced somewhat by the existence
of the "multiple interpreters in one address space" feature, which is
used e.g. by mod_python. This feature attempts to provide isolation
between interpreters to the point that each one can have a completely
different set of modules loaded and can be working on a totally
different application. The implementation of CPython shares built-in
types between multiple interpreters (and it wouldn't be easy to change
this); if you were able to modify a built-in type from one
interpreter, all other interpreters would see that same modification.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
Users mailing list
Users@...
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

[Dino Viehland]

Guido wrote:
> I should add that this policy is also forced somewhat by the existence
> of the "multiple interpreters in one address space" feature, which is
> used e.g. by mod_python. This feature attempts to provide isolation
> between interpreters to the point that each one can have a completely
> different set of modules loaded and can be working on a totally
> different application. The implementation of CPython shares built-in
> types between multiple interpreters (and it wouldn't be easy to change
> this); if you were able to modify a built-in type from one
> interpreter, all other interpreters would see that same modification.

IronPython is in the exact same boat here - we share built-in types
Across multiple Python engines as well.


_______________________________________________
Users mailing list
Users@...
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

[Michael Foord-5]

Dino Viehland wrote:

> Guido wrote:
>  
>> I should add that this policy is also forced somewhat by the existence
>> of the "multiple interpreters in one address space" feature, which is
>> used e.g. by mod_python. This feature attempts to provide isolation
>> between interpreters to the point that each one can have a completely
>> different set of modules loaded and can be working on a totally
>> different application. The implementation of CPython shares built-in
>> types between multiple interpreters (and it wouldn't be easy to change
>> this); if you were able to modify a built-in type from one
>> interpreter, all other interpreters would see that same modification.
>>    
>
> IronPython is in the exact same boat here - we share built-in types
> Across multiple Python engines as well.
>
>
>  

And indeed it is needed - if you are working with multiple interpreters
(engines in IronPython) you don't want isinstance(something, dict) to
fail because it is a dictionary from a different interpreter...

Michael

> _______________________________________________
> Python-Dev mailing list
> Python-Dev@...
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
>  


--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog


_______________________________________________
Users mailing list
Users@...
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

[Guido van Rossum]

On Mon, Jun 15, 2009 at 9:10 AM, Michael Foord<fuzzyman@...> wrote:

> Dino Viehland wrote:
>> Guido wrote:
>>> I should add that this policy is also forced somewhat by the existence
>>> of the "multiple interpreters in one address space" feature, which is
>>> used e.g. by mod_python. This feature attempts to provide isolation
>>> between interpreters to the point that each one can have a completely
>>> different set of modules loaded and can be working on a totally
>>> different application. The implementation of CPython shares built-in
>>> types between multiple interpreters (and it wouldn't be easy to change
>>> this); if you were able to modify a built-in type from one
>>> interpreter, all other interpreters would see that same modification.

>> IronPython is in the exact same boat here - we share built-in types
>> Across multiple Python engines as well.

> And indeed it is needed - if you are working with multiple interpreters
> (engines in IronPython) you don't want isinstance(something, dict) to fail
> because it is a dictionary from a different interpreter...

Ah, but that suggests you have sharing between different interpreters.
If you're doing that, perhaps you shouldn't be using multiple
interpreters, but instead multiple threads?

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
Users mailing list
Users@...
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

[Michael Foord-5]

Guido van Rossum wrote:

> On Mon, Jun 15, 2009 at 9:10 AM, Michael Foord<fuzzyman@...> wrote:
>  
>> Dino Viehland wrote:
>>    
>>> Guido wrote:
>>>      
>>>> I should add that this policy is also forced somewhat by the existence
>>>> of the "multiple interpreters in one address space" feature, which is
>>>> used e.g. by mod_python. This feature attempts to provide isolation
>>>> between interpreters to the point that each one can have a completely
>>>> different set of modules loaded and can be working on a totally
>>>> different application. The implementation of CPython shares built-in
>>>> types between multiple interpreters (and it wouldn't be easy to change
>>>> this); if you were able to modify a built-in type from one
>>>> interpreter, all other interpreters would see that same modification.
>>>>        
>
>  
>>> IronPython is in the exact same boat here - we share built-in types
>>> Across multiple Python engines as well.
>>>      
>
>  
>> And indeed it is needed - if you are working with multiple interpreters
>> (engines in IronPython) you don't want isinstance(something, dict) to fail
>> because it is a dictionary from a different interpreter...
>>    
>
> Ah, but that suggests you have sharing between different interpreters.
> If you're doing that, perhaps you shouldn't be using multiple
> interpreters, but instead multiple threads?
>
>  

Well, in our use case we use multiple engines to provide an isolated
execution context for every document (the Resolver One spreadsheet
written in IronPython). Each of these has their own calculation thread
as well - but the engine per document structure is nice and clean and
means each document can have its own set of modules loaded without
affecting the other documents (although they share a core set of modules).

Once we move these engines into their own app domains we can completely
isolate each document and apply separate security permissions to each
one. That might mean each document effectively paying the
not-insubstantial startup time hit and we haven't begun to look at how
to mitigate that.

Michael

--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog


_______________________________________________
Users mailing list
Users@...
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

[Dino Viehland]

Seo wrote:

> Exception for setting attributes of built-in type differs between
> CPython and IronPython. This is not purely theoretical, as
> zope.interface tries to set Implements declaration as __implemented__
> attribute of built-in type object, and excepts TypeError.
>
> Python 2.6.1
> >>> object.flag = True
> TypeError: can't set attributes of built-in/extension type 'object'
>
> IronPython 2.6
> >>> object.flag = True
> AttributeError: 'object' object has no attribute 'flag'
>
> I was surprised that CPython raises TypeError. Library Reference seems
> to mention it here:
>
> exception AttributeError
> Raised when an attribute reference or assignment fails. (When an
> object does not support attribute references or attribute assignments
> at all, TypeError is raised.)
> http://docs.python.org/library/exceptions.html
>
> What does it mean that "an object does not support attribute
> references or attribute assignments at all"?

Even though Guido said we didn't have to match it I've updated IronPython
so that we'll throw the same exception now.  The change will be in
tomorrow's source push to CodePlex.  We've matched specific exceptions
in the past and this one is at least documented :)
_______________________________________________
Users mailing list
Users@...
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com