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 2 of 2 — ← Prev page 1 [2]

#15100

Le 28/10/2011 05:02, Patrick Maupin a écrit :

> You can easily do that by subclassing a string:
>
> class AnnotatedStr(str):
>      pass
>
> x = AnnotatedStr('Node1')
> x.title = 'Title for node 1'
>


Less or more what I did. But requires to transport the string graph 
structure to the AnnotatedStr one.

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

#15089

On Fri, 28 Oct 2011 01:36:41 +0200, 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, because built-in strings don't have a __dict__ and so you cannot add 
new attributes that didn't already exist.

But you can subclass str and do whatever you like.

class Str(str):
    pass

Str("foo").bar = 42



-- 
Steven

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

#15097

candide <candide@free.invalid> writes:

> 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, and for good reason.  Strings are immutable, so that you needn't
care which particular instance of "foo" you're looking at, they're all
equivalent.  The interpreter uses that fact to cache instances of short
strings such as Python identifiers, so that most places that look at a
string like "foo" are in fact dealing with the same instance.  If one
could change an attribute of a particular instance of "foo", it would no
longer be allowed for the interpreter to transparently cache them.  The
same goes for integers and other immutable built-in objects.

If you really need to attach state to strings, subclass them as Steven
explained.  All code that accepts strings (including all built-ins) will
work just fine, transparent caching will not happen, and attributes are
writable.

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

#15101

Le 28/10/2011 11:08, Hrvoje Niksic a écrit :

> longer be allowed for the interpreter to transparently cache them.  The
> same goes for integers and other immutable built-in objects.


On the other hand, immutability and optimization don't explain the whole 
thing because you can't do something like [].bar = 42.



>
> If you really need to attach state to strings, subclass them as Steven
> explained.  All code that accepts strings (including all built-ins) will
> work just fine, transparent caching will not happen, and attributes are
> writable.

OK, thanks, I'll consider it seriously. Actually I have a directed graph 
whose nodes are given as string but it's oversimplistic to identify node 
and string (for nodes requiring specific methods).

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

#15088

On Thu, 27 Oct 2011 12:08:45 +0200, candide 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

Note that possession or absence of a __dict__ attribute doesn't
necessarily mean that you can or can't set attributes, as the class can
override __setattr__().

Ultimately, there is no guaranteed mechanism to determine in advance
whether or not an attempt to set an attribute will succeed.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web