Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #15033 > unrolled thread

__dict__ attribute for built-in types

Back to article view | Back to comp.lang.python

Contents

  __dict__ attribute for built-in types candide <candide@free.invalid> - 2011-10-27 12:08 +0200
    Re: __dict__ attribute for built-in types Arnaud Delobelle <arnodel@gmail.com> - 2011-10-27 11:36 +0100
    Re: __dict__ attribute for built-in types Duncan Booth <duncan.booth@invalid.invalid> - 2011-10-27 11:03 +0000
      Re: __dict__ attribute for built-in types Chris Angelico <rosuav@gmail.com> - 2011-10-28 00:25 +1100
        Re: __dict__ attribute for built-in types Duncan Booth <duncan.booth@invalid.invalid> - 2011-10-27 14:36 +0000
          Re: __dict__ attribute for built-in types Chris Angelico <rosuav@gmail.com> - 2011-10-28 09:39 +1100
      Re: __dict__ attribute for built-in types candide <candide@free.invalid> - 2011-10-27 16:01 +0200
        Re: __dict__ attribute for built-in types Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-10-27 22:19 +0000
          Re: __dict__ attribute for built-in types candide <candide@free.invalid> - 2011-10-28 00:52 +0200
            Re: __dict__ attribute for built-in types Terry Reedy <tjreedy@udel.edu> - 2011-10-27 22:44 -0400
            Re: __dict__ attribute for built-in types alex23 <wuwei23@gmail.com> - 2011-10-27 19:48 -0700
            Re: __dict__ attribute for built-in types Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-10-28 08:01 +0000
              Re: __dict__ attribute for built-in types candide <candide@free.invalid> - 2011-10-28 12:03 +0200
              Re: __dict__ attribute for built-in types Christian Heimes <lists@cheimes.de> - 2011-10-28 13:51 +0200
            Re: __dict__ attribute for built-in types Peter Pearson <ppearson@nowhere.invalid> - 2011-10-28 15:52 +0000
        Re: __dict__ attribute for built-in types Hrvoje Niksic <hniksic@xemacs.org> - 2011-10-28 00:57 +0200
          Re: __dict__ attribute for built-in types candide <candide@free.invalid> - 2011-10-28 01:36 +0200
            Re: __dict__ attribute for built-in types MRAB <python@mrabarnett.plus.com> - 2011-10-28 01:02 +0100
              Re: __dict__ attribute for built-in types candide <candide@free.invalid> - 2011-10-28 04:46 +0200
                Re: __dict__ attribute for built-in types Patrick Maupin <pmaupin@gmail.com> - 2011-10-27 20:02 -0700
                  Re: __dict__ attribute for built-in types candide <candide@free.invalid> - 2011-10-28 12:04 +0200
            Re: __dict__ attribute for built-in types Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-10-28 06:21 +0000
            Re: __dict__ attribute for built-in types Hrvoje Niksic <hniksic@xemacs.org> - 2011-10-28 11:08 +0200
              Re: __dict__ attribute for built-in types candide <candide@free.invalid> - 2011-10-28 12:23 +0200
    Re: __dict__ attribute for built-in types Nobody <nobody@nowhere.com> - 2011-10-28 06:49 +0100

Page 1 of 2  [1] 2  Next page →

#15033 — __dict__ attribute for built-in types

I realize that built-in types objects don't provide a __dict__ attribute 
and thereby i can't set an attribute to a such object, for instance


 >>> a=[42,421]
 >>> a.foo="bar"
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
AttributeError: 'list' object has no attribute 'foo'
 >>> a.__dict__
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
AttributeError: 'list' object has no attribute '__dict__'
 >>>


So, i was wondering :

-- why this behaviour ?
-- where the official documentation refers to this point ?

[toc] | [next] | [standalone]

#15037

On 27 October 2011 11:08, candide <candide@free.invalid> wrote:
> I realize that built-in types objects don't provide a __dict__ attribute and
> thereby i can't set an attribute to a such object, for instance
>
>
>>>> a=[42,421]
>>>> a.foo="bar"
> Traceback (most recent call last):
>  File "<stdin>", line 1, in <module>
> AttributeError: 'list' object has no attribute 'foo'
>>>> a.__dict__
> Traceback (most recent call last):
>  File "<stdin>", line 1, in <module>
> AttributeError: 'list' object has no attribute '__dict__'
>>>>

Some built in types have a __dict__:

>>> def foo(): pass
...
>>> foo.__dict__
{}
>>> import random
>>> len(random.__dict__)
57

>
> So, i was wondering :
>
> -- why this behaviour ?

Performance reasons I guess.

> -- where the official documentation refers to this point ?

I don't know this one :)

-- 
Arnaud

[toc] | [prev] | [next] | [standalone]

#15039

candide <candide@free.invalid> wrote:

> I realize that built-in types objects don't provide a __dict__ 
attribute 
> and thereby i can't set an attribute to a such object, for instance
> 
> 
> >>> a=[42,421]
> >>> a.foo="bar"
> Traceback (most recent call last):
>    File "<stdin>", line 1, in <module>
> AttributeError: 'list' object has no attribute 'foo'
> >>> a.__dict__
> Traceback (most recent call last):
>    File "<stdin>", line 1, in <module>
> AttributeError: 'list' object has no attribute '__dict__'
> >>>
> 
> 
> So, i was wondering :
> 
> -- why this behaviour ?

Types without a __dict__ use less memory. Also, if you couldn't have a 
type that didn't have a `__dict__` then any `dict` would also need its 
own `__dict__` which would either result in infinite memory use or 
recursive dictionaries.

It isn't just built-in types, you can choose for any type you define 
whether or not to have a '__dict__' attribute

>>> class Fixed(object):
	__slots__ = ('foo', 'bar')
	readonly = 42

	
>>> f = Fixed()
>>> f.foo, f.bar = 1, 2
>>> f.foo, f.bar, f.readonly
(1, 2, 42)
>>> f.readonly = 24
Traceback (most recent call last):
  File "<pyshell#31>", line 1, in <module>
    f.readonly = 24
AttributeError: 'Fixed' object attribute 'readonly' is read-only
>>> f.baz = 'whatever'
Traceback (most recent call last):
  File "<pyshell#32>", line 1, in <module>
    f.baz = 'whatever'
AttributeError: 'Fixed' object has no attribute 'baz'

> -- where the official documentation refers to this point ?
> 
See http://docs.python.org/reference/datamodel.html for the docs about 
__slots__

There is also the API documentation which describes at a low level how 
to control whether or not instances have a dict:
 http://docs.python.org/c-api/typeobj.html#tp_dictoffset

I'm not sure though where you find a higher level statement of which 
builtin types have a __dict__.

-- 
Duncan Booth http://kupuguy.blogspot.com

[toc] | [prev] | [next] | [standalone]

#15041

On Thu, Oct 27, 2011 at 10:03 PM, Duncan Booth
<duncan.booth@invalid.invalid> wrote:
> Types without a __dict__ use less memory. Also, if you couldn't have a
> type that didn't have a `__dict__` then any `dict` would also need its
> own `__dict__` which would either result in infinite memory use or
> recursive dictionaries.
>

Easy, just self-reference.
a = {}
a.__dict__ is a  --> True

Yeah, it's recursion, but no different from types:

>>> type(type) is type
True

If you want this behavior, you can do it easily enough.

>>> class dictdict(dict):
	def __init__(self):
		self.__dict__=self

>>> a=dictdict()
>>> a.__dict__ is a
True

However, the more compelling argument is that a __slots__ object can
be WAY more efficient.

ChrisA

[toc] | [prev] | [next] | [standalone]

#15047

Chris Angelico <rosuav@gmail.com> wrote:

> On Thu, Oct 27, 2011 at 10:03 PM, Duncan Booth
><duncan.booth@invalid.invalid> wrote:
>> Types without a __dict__ use less memory. Also, if you couldn't have a
>> type that didn't have a `__dict__` then any `dict` would also need its
>> own `__dict__` which would either result in infinite memory use or
>> recursive dictionaries.
>>
> 
> Easy, just self-reference.
> a = {}
> a.__dict__ is a  --> True
> 
> Yeah, it's recursion, but no different from types:
> 

Try thinking that one through. Imagine you could set up a dictionary the 
way you describe:

>>> class DictWithDict(dict):
	def __init__(self, *args, **kw):
		dict.__init__(self, *args, **kw)
		self.__dict__ = self

		
>>> d = DictWithDict()
>>> d.keys()
dict_keys([])
>>> d = DictWithDict({'a': 42})
>>> d.keys()
dict_keys(['a'])
>>> d['keys'] = lambda: 'oops'
>>> d.keys()
'oops'
>>> 

A dict with itself as its own __dict__ becomes like a javascript object 
where subscripting and attribute access are mostly interchangeable.


-- 
Duncan Booth http://kupuguy.blogspot.com

[toc] | [prev] | [next] | [standalone]

#15064

On Fri, Oct 28, 2011 at 1:36 AM, Duncan Booth
<duncan.booth@invalid.invalid> wrote:
> Try thinking that one through. Imagine you could set up a dictionary the
> way you describe
>
> A dict with itself as its own __dict__ becomes like a javascript object
> where subscripting and attribute access are mostly interchangeable.

Yeah; I never said it was a good thing, just that it's possible.
"Everything is permissible" - but not everything is beneficial.
"Everything is permissible" - but not everything is constructive. (1
Corinthians 10:23, NIV translation.)

ChrisA

[toc] | [prev] | [next] | [standalone]

#15043

Le 27/10/2011 13:03, Duncan Booth a écrit :

>
>> -- where the official documentation refers to this point ?
>>
> See http://docs.python.org/reference/datamodel.html for the docs about
> __slots__
>
> There is also the API documentation which describes at a low level how
> to control whether or not instances have a dict:
>   http://docs.python.org/c-api/typeobj.html#tp_dictoffset
>
> I'm not sure though where you find a higher level statement of which
> builtin types have a __dict__.
>


OK, thanks for the information abouts the slots. Nevertheless, this 
cannot answer completely my question. Some builtin types like string, 
lists, integer, float, dictionaries, etc have the property that 
instances of those types don't provide a __dict__ attribute. I can't 
imagine the documentation lets pass silently this point.

But beside this, how to recognise classes whose object doesn't have a 
__dict__ attribute ?

[toc] | [prev] | [next] | [standalone]

#15062

On Thu, 27 Oct 2011 16:01:25 +0200, candide wrote:

> OK, thanks for the information abouts the slots. Nevertheless, this
> cannot answer completely my question. Some builtin types like string,
> lists, integer, float, dictionaries, etc have the property that
> instances of those types don't provide a __dict__ attribute. I can't
> imagine the documentation lets pass silently this point.

What, you think it goes against the laws of physics that nobody thought 
to mention it in the docs? <wink>

> But beside this, how to recognise classes whose object doesn't have a
> __dict__ attribute ?

The same way as you would test for any other attribute.

>>> hasattr(42, '__dict__')
False


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#15065

Le 28/10/2011 00:19, Steven D'Aprano a écrit :
>
> What, you think it goes against the laws of physics that nobody thought
> to mention it in the docs?<wink>


No but I'm expecting from Python documentation to mention the laws of 
Python ...


>
>> But beside this, how to recognise classes whose object doesn't have a
>> __dict__ attribute ?
>
> The same way as you would test for any other attribute.
>
>>>> hasattr(42, '__dict__')
> False
>
>


OK but I'm talking about classes, not instances  : 42 has no __dict__ 
attribute but, may be, 43 _has_ such attribute, who knows in advance ? ;)

Let'have a try :

 >>> hasattr(43, '__dict__')
False
 >>>


so we have proved by induction that no integer instance has a 
dictionnary attribute ;)

[toc] | [prev] | [next] | [standalone]

#15075

On 10/27/2011 6:52 PM, candide wrote:

> No but I'm expecting from Python documentation to mention the laws of
> Python ...

The details of CPython builtin classes are not laws of Python. It *is* a 
'law of Python' that classes can use 'slots = ' to restrict the 
attributes of instances. By implication, builtin classes in any 
implementation do not have to allow attribute assignment. I do not 
believe it would be a violation if some implementation did so.

None of this is to say that we could not say something on the subject at 
the beginning of the 'built-in types' chapter of the lib manual.

> OK but I'm talking about classes, not instances :

Yes you are. The class determines whether its instances have assignable 
new attributes.

 > 42 has no __dict__ > attribute but,
 > may be, 43 _has_ such attribute, who knows in advance ? ;)

True, in a sense, but if the class allowed a user to execute
"42.__dict__ = {}" then you could safely assume that "43.xxx = z" should 
work also.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#15077

On Oct 28, 8:52 am, candide <cand...@free.invalid> wrote:
> No but I'm expecting from Python documentation to mention the laws of
> Python ...

It's not a "law", it's an _implementation detail_. The docs don't tend
to mention every such decision made because that's what the source is
for.

> But beside this, how to recognise classes whose object doesn't have a
> __dict__ attribute ?

The better question is: why do you need to be able to?

> Is it possible in the CPython implementation to write something like this :
> "foo".bar = 42
> without raising an attribute error ?

Why are you trying to modify an immutible object?

If you really want to assign attributes to string objects, subclass
str.

[toc] | [prev] | [next] | [standalone]

#15094

On Fri, 28 Oct 2011 00:52:40 +0200, candide wrote:

> Le 28/10/2011 00:19, Steven D'Aprano a écrit :
>>
>> What, you think it goes against the laws of physics that nobody thought
>> to mention it in the docs?<wink>
> 
> 
> No but I'm expecting from Python documentation to mention the laws of
> Python ...

You seem to have missed my point. You said "I can't imagine" that the 
Python docs fail to mention that built-ins don't allow the addition of 
new attributes. I can, easily. The people writing the documentation are 
only human, and if they failed to mention it, oh well, perhaps they 
didn't think of it. This is hardly a surprise. Wanting to add arbitrary 
attributes to built-ins is not exactly an everyday occurrence.


>>> But beside this, how to recognise classes whose object doesn't have a
>>> __dict__ attribute ?
>>
>> The same way as you would test for any other attribute.
>>
>>>>> hasattr(42, '__dict__')
>> False
> 
> OK but I'm talking about classes, not instances  : 42 has no __dict__
> attribute but, may be, 43 _has_ such attribute, who knows in advance ?
> ;)

True, it is theoretically possible that (say) only odd numbers get a 
__dict__, or primes, or the smallest multiple of seventeen larger than 
the natural logarithm of a googol (10**100). But it's a safe bet that 
nothing so arbitrary will happen.

Dunder attributes ("Double UNDERscore") like __dict__ are reserved for 
use by Python, and __dict__ has known semantics. You can safely assume 
that either *all* instances of a type will have a __dict__, or *no* 
instances will have one. If some class violates that, oh well, your code 
can't be expected to support every badly-designed stupid class in the 
world.

Also, keep in mind the difference between a *class* __dict__ and an 
*instance* __dict__. 

>>> hasattr(int, '__dict__')  # Does the int class/type have a __dict__?
True
>>> hasattr(42, '__dict__')  # Does the int instance have a __dict__?
False



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#15099

Le 28/10/2011 10:01, Steven D'Aprano a écrit :

> didn't think of it. This is hardly a surprise. Wanting to add arbitrary
> attributes to built-ins is not exactly an everyday occurrence.
>



Depends. Experimented programmers don't even think of it. But less 
advanced programmers can consider of it. It's is not uncommun to use a 
Python class like a C  structure, for instance :

class C:pass

C.member1=foo
C.member2=bar


Why not with a built-in type instead of a custom class?




> the natural logarithm of a googol (10**100). But it's a safe bet that
> nothing so arbitrary will happen.

betting when programming ?  How curious! ;)


> Also, keep in mind the difference between a *class* __dict__ and an
> *instance* __dict__.
>

You mean this distinction

 >>> hasattr('', '__dict__')
False
 >>> hasattr(''.__class__, '__dict__')
True
 >>>


?

[toc] | [prev] | [next] | [standalone]

#15103

Am 28.10.2011 10:01, schrieb Steven D'Aprano:
>>>> hasattr(int, '__dict__')  # Does the int class/type have a __dict__?
> True
>>>> hasattr(42, '__dict__')  # Does the int instance have a __dict__?
> False

Also __dict__ doesn't have to be an instance of __dict__. Builtin types
usually have a dictproxy instane as their __dict__.

>>> type(int.__dict__)
<type 'dictproxy'>
>>> int.__dict__["egg"] = "spam"
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'dictproxy' object does not support item assignment

[toc] | [prev] | [next] | [standalone]

#15105

On Fri, 28 Oct 2011 00:52:40 +0200, candide <candide@free.invalid> wrote:
[snip]
>>>>> hasattr(42, '__dict__')
>> False
[snip]
>
> Let'have a try :
>
> >>> hasattr(43, '__dict__')
> False
> >>>
>
> so we have proved by induction that no integer instance has a 
> dictionnary attribute ;)

You left out an important step in this proof by induction.  Observe:

>>> n = 0
>>> hasattr(n, "__dict__")
False
>>> if hasattr(n, "__dict__") is False:
...   hasattr(n+1, "__dict__") is False
... 
True

There, now it's proven by induction.

-- 
To email me, substitute nowhere->spamcop, invalid->net.

[toc] | [prev] | [next] | [standalone]

#15066

candide <candide@free.invalid> writes:

> But beside this, how to recognise classes whose object doesn't have a
> __dict__ attribute ?

str, list and others aren't classes, they are types.  While all
(new-style) classes are types, not all types are classes.  It's
instances of classes (types created by executing the "class" statement
or its equivalent) that automatically get a __dict__, unless __slots__
was used at class definition time to suppress it.  Built-in and
extension types can choose whether to implement __dict__.

(Mechanics of defining built-in and extension types are of course
implementation-specific.  CPython allows adding __dict__ to any
extension type by setting the tp_dictoffset member of the type
definition struct to the appropriate offset into the instance struct.)

[toc] | [prev] | [next] | [standalone]

#15069

Le 28/10/2011 00:57, Hrvoje Niksic a écrit :

> was used at class definition time to suppress it.  Built-in and
> extension types can choose whether to implement __dict__.
>

Is it possible in the CPython implementation to write something like this :

"foo".bar = 42

without raising an attribute error ?

[toc] | [prev] | [next] | [standalone]

#15070

On 28/10/2011 00:36, candide wrote:
> Le 28/10/2011 00:57, Hrvoje Niksic a écrit :
>
>> was used at class definition time to suppress it. Built-in and
>> extension types can choose whether to implement __dict__.
>>
>
> Is it possible in the CPython implementation to write something like this :
>
> "foo".bar = 42
>
> without raising an attribute error ?

No, built-in classes written in C have certain limitations, but why
would you want to do that anyway?

[toc] | [prev] | [next] | [standalone]

#15076

Le 28/10/2011 02:02, MRAB a écrit :

>
> No, built-in classes written in C have certain limitations, but why
> would you want to do that anyway?




Mainly for learning purpose and Python better understanding.

Actually, I have a class of mine for drawing graphs with the Graphviz 
software. The nodes of the graph to be represented was supposed to have 
2 attributes, say title and shortName. Now, I want to plot a graph whose 
nodes are pure string. So to fit the class interface, I was trying to 
add title and shortName attribute to every string node.

[toc] | [prev] | [next] | [standalone]

#15078

On Oct 27, 9:46 pm, candide <cand...@free.invalid> wrote:
> Le 28/10/2011 02:02, MRAB a crit :
>
>
>
> > No, built-in classes written in C have certain limitations, but why
> > would you want to do that anyway?
>
> Mainly for learning purpose and Python better understanding.
>
> Actually, I have a class of mine for drawing graphs with the Graphviz
> software. The nodes of the graph to be represented was supposed to have
> 2 attributes, say title and shortName. Now, I want to plot a graph whose
> nodes are pure string. So to fit the class interface, I was trying to
> add title and shortName attribute to every string node.

You can easily do that by subclassing a string:

class AnnotatedStr(str):
    pass

x = AnnotatedStr('Node1')
x.title = 'Title for node 1'

etc.

The fact that you subclass it (unless your subclass uses __slots__)
will give it a dict.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web