[IronPython] __slots__

[Michael Foord]

Dino Viehland wrote:
> The fact that we allow setting to the dictionary when we shouldn't be much to worry about - it is just odd.  In either case we still have a .NET type defined something like:
>
> class NewType : YourBaseTypeHere {
> 	public PythonDictionary __dict__;
> 	public object[] __slots__;
> 	...
> }
>
> And it's just in one case we don't allow anything in __dict__ and in another case we do (the types do look a little different between v2 and v2.6 but not enough to matter).
>
> I could see us backporting just the fix for calculating whether or not slots is allowed but not the restructuring of the new-type maker code.  But I think the justification for that isn't the oddness here but cases where in 2.0.1 slots are valid but we don't allow them (which I'm fairly sure exist as well).  
>
>   

I'm also seeing another oddity with __slots__ - even if __doc__ is in 
the __slots__ list you can't set __doc__ on an instance.

It would be nice to have this in 2.0.2 because as well as the 
performance gains we would prefer users be warned with an AttributeError 
if they set non-existent attributes on our spreadsheet object model 
classes.

Michael

>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-
>> bounces at lists.ironpython.com] On Behalf Of Michael Foord
>> Sent: Monday, March 09, 2009 6:36 AM
>> To: Discussion of IronPython
>> Subject: Re: [IronPython] __slots__
>>
>> Curt Hagenlocher wrote:
>>     
>>> On Mon, Mar 9, 2009 at 5:28 AM, Michael Foord
>>>       
>> <fuzzyman at voidspace.org.uk> wrote:
>>     
>>>> Curt Hagenlocher wrote:
>>>>
>>>>         
>>>>> I believe this is already fixed in the current (ie 2.6ish) source.
>>>>>
>>>>>           
>>>> Any chance for 2.0.2?
>>>>
>>>>         
>>> That's Dino's call.  The fix in 2.6 is actually a massive
>>> restructuring of some code, so the backport would likely have to be
>>> done from scratch against the 2.0 branch.
>>>
>>> Fun fact: it wasn't fixed intentionally, and I only discovered the
>>> problem in 2.0 by noticing that some (buggy) code was now broken with
>>> 2.6...  :)
>>>
>>>       
>> :-)
>>
>> We're trying to see if we can get a performance benefit from using
>> __slots__ and the odd behaviour of 2.0.1. is, well, odd.
>>
>> Michael
>>     
>>> --
>>> Curt Hagenlocher
>>> curt at hagenlocher.org
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.ironpython.com
>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>
>>>       
>> --
>> http://www.ironpythoninaction.com/
>> http://www.voidspace.org.uk/blog
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>     
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>   


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