468,511 Members | 1,641 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,511 developers. It's quick & easy.

Setting an attribute without calling __setattr__()

OK, I'm sure the answer is staring me right in the face--whether that answer
be "you can't do that" or "here's the really easy way--but I am stuck. I'm
writing an object to proxy both lists (subscriptable iterables, really) and
dicts.

My init lookslike this:

def __init__(self, obj=None):
if type(obj).__name__ in 'list|tuple|set|frozenset':
self.me = []
for v in obj:
self.me.append(ObjectProxy(v))
elif type(obj) == dict:
self.me = {}
for k,v in obj.items():
self.me[k] = ObjectProxy(v)

and I have a __setattr__ defined like so:

def __setattr__(self, name, value):
self.me[name] = ObjectProxy(value)

You can probably see the problem.

While doing an init, self.me = {} or self.me = [] calls __setattr__, which
then ends up in an infinite loop, and even it it succeeded

self.me['me'] = {}

is not what I wanted in the first place.

Is there a way to define self.me without it firing __setattr__?

If not, it's not a huge deal, as having this class read-only for now won't
be a problem, but I was just trying to make it read/write.

Thanks!

j

Jun 27 '08 #1
12 1057
Joshua Kugler <jk*****@bigfoot.comwrites:
self.me = []
self.me = {}
Use "object.__setattr__(self, 'me') = []" and likewise for {}.
Jun 27 '08 #2
On Apr 26, 7:01 am, Joshua Kugler <jkug...@bigfoot.comwrote:
OK, I'm sure the answer is staring me right in the face--whether that answer
be "you can't do that" or "here's the really easy way--but I am stuck. I'm
writing an object to proxy both lists (subscriptable iterables, really) and
dicts.

My init lookslike this:

def __init__(self, obj=None):
if type(obj).__name__ in 'list|tuple|set|frozenset':
self.me = []
for v in obj:
self.me.append(ObjectProxy(v))
elif type(obj) == dict:
self.me = {}
for k,v in obj.items():
self.me[k] = ObjectProxy(v)

and I have a __setattr__ defined like so:

def __setattr__(self, name, value):
self.me[name] = ObjectProxy(value)

You can probably see the problem.

While doing an init, self.me = {} or self.me = [] calls __setattr__, which
then ends up in an infinite loop, and even it it succeeded

self.me['me'] = {}

is not what I wanted in the first place.

Is there a way to define self.me without it firing __setattr__?
Consider reading the *second* paragraph about __setattr__ in section
3.4.2 of the Python Reference Manual.
Jun 27 '08 #3
Hrvoje Niksic <hn*****@xemacs.orgwrites:
Joshua Kugler <jk*****@bigfoot.comwrites:
> self.me = []
self.me = {}

Use "object.__setattr__(self, 'me') = []" and likewise for {}.
Oops, that should of course be "object.__setattr__(self, 'me', [])".
Jun 27 '08 #4
John Machin wrote:
>Is there a way to define self.me without it firing __setattr__?
Consider reading the *second* paragraph about __setattr__ in section
3.4.2 of the Python Reference Manual.
Like I said in my original post, it was probably staring me right in the
face. I had read through a bit of the documentation on special methods,
but for some reason I missed that part.

Thanks to all for your responses!

j

Jun 27 '08 #5
On Apr 25, 5:01 pm, Joshua Kugler <jkug...@bigfoot.comwrote:
My init lookslike this:

def __init__(self, obj=None):
if type(obj).__name__ in 'list|tuple|set|frozenset':
self.me = []
for v in obj:
self.me.append(ObjectProxy(v))
elif type(obj) == dict:
self.me = {}
for k,v in obj.items():
self.me[k] = ObjectProxy(v)
As an aside, unrelated to your question, Python encourages "duck
typing" instead of exact type matching. Unless you have a good reason
to restrict obj to one of the 5 types you hardcoded (a rather rare
need), it is more flexible to write it as:

def __init__(self, obj=None):
if hasattr(obj, 'items'):
# assume obj is a mapping type instance
self.me = dict((k,ObjectProxy(v)) for k,v in obj.items())
else:
try: # check if obj is an iterable instance
self.me = map(ObjectProxy, obj)
except TypeError:
# handle other cases here
# self.me = ...
A downside of this flexibility is that it may be more liberal than it
should. For instance, if obj just happens to have an 'items()' method
but it's not really a mapping type, the assumption is violated. Python
3 deals with such potential ambiguities by introducing Abstract Base
Classes (ABCs) [1] that allow a class to make explicit its semantics.
So in Py3K the hasattr() test above would rather be written as
"isinstance(obj, Mapping)", where Mapping is the ABC that represents
(read-only) mappings.

A more difficult problem is that even if a class derives from some
ABC, you may not always want to treat its instances as such. The
typical gotcha is that strings are iterable, but in many (most?)
applications they are to be treated as atomic values, not as sequences
of characters. So in the example above if obj is a string, self.me
will be a list of ObjectProxy instances, one per character; probably
not what you intend. Of course we can check for "isinstance(obj,str)"
but then we're back at explicit type checking. There is no general way
to express something lke "atomic value that also happens to be
iterable (but pretend it's not)" because it's inherently domain-
dependent.

George

[1] http://www.python.org/dev/peps/pep-3119/
Jun 27 '08 #6
Joshua Kugler <jk*****@bigfoot.comwrites:

[...]
self.me = []
for v in obj:
self.me.append(ObjectProxy(v))
Note that is could be spelt:

self.me = map(ObjectProxy, v)

--
Arnaud
Jun 27 '08 #7


Hrvoje Niksic wrote:
Hrvoje Niksic <hn*****@xemacs.orgwrites:
Joshua Kugler <jk*****@bigfoot.comwrites:
self.me = []
self.me = {}
Use "object.__setattr__(self, 'me') = []" and likewise for {}.

Oops, that should of course be "object.__setattr__(self, 'me', [])".
Jun 27 '08 #8
Consider reading the *second* paragraph about __setattr__ in section
3.4.2 of the Python Reference Manual.
if you are simply going to answer rtfm - might as well kept it to
yourself.
Jun 27 '08 #9
In article <m2************@googlemail.com>,
Arnaud Delobelle <ar*****@googlemail.comwrote:
>Joshua Kugler <jk*****@bigfoot.comwrites:
>>
self.me = []
for v in obj:
self.me.append(ObjectProxy(v))

Note that is could be spelt:

self.me = map(ObjectProxy, v)
It could also be spelt:

self.me = [ObjectProxy(v) for v in obj]

which is my preferred spelling....
--
Aahz (aa**@pythoncraft.com) <* http://www.pythoncraft.com/

Why is this newsgroup different from all other newsgroups?
Jun 27 '08 #10
On Sat, 26 Apr 2008 08:28:38 -0700, animalMutha wrote:
>Consider reading the *second* paragraph about __setattr__ in section
3.4.2 of the Python Reference Manual.

if you are simply going to answer rtfm - might as well kept it to
yourself.
Yes, but if you are telling where exactly to find the wanted information
in the documentation, like John did, you are teaching the OP how to fish.
Which is a good thing. Much more helpful than your remark anyway. You
might as well have kept it to yourself. :-þ

Ciao,
Marc 'BlackJack' Rintsch
Jun 27 '08 #11
aa**@pythoncraft.com (Aahz) writes:
In article <m2************@googlemail.com>,
Arnaud Delobelle <ar*****@googlemail.comwrote:
>>Joshua Kugler <jk*****@bigfoot.comwrites:
>>>
self.me = []
for v in obj:
self.me.append(ObjectProxy(v))

Note that is could be spelt:

self.me = map(ObjectProxy, v)
^-- I meant obj!
>
It could also be spelt:

self.me = [ObjectProxy(v) for v in obj]

which is my preferred spelling....
I was waiting patiently for this reply... And your preferred spelling
is py3k-proof as well, of course.

I don't write map(lambda x: x+1, L) or map(itemgetter('x'), L) but I
like to use it when the first argument is a named function,
e.g. map(str, list_of_ints).

--
Arnaud
Jun 27 '08 #12
animalMutha wrote:
>Consider reading the *second* paragraph about __setattr__ in section
3.4.2 of the Python Reference Manual.

if you are simply going to answer rtfm - might as well kept it to
yourself.
For what it's worth, I (the original poster) am glad he answered that way.
It showed me the section and paragraph I had overlooked when reading
through the docs the first time.

j

Jun 27 '08 #13

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

4 posts views Thread by Maarten van Reeuwijk | last post: by
1 post views Thread by Thomas Heller | last post: by
3 posts views Thread by Christian Dieterich | last post: by
9 posts views Thread by | last post: by
5 posts views Thread by Joel Andres Granados | last post: by
reply views Thread by Terry Reedy | last post: by
8 posts views Thread by Ken Starks | last post: by
2 posts views Thread by Jan Schilleman | last post: by
reply views Thread by NPC403 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.