Set/Get attribute syntatic sugar

[Заур Шибзухов]

There is a syntactic sugar for item access in
dictionaries and sequences:

o[e] = v <-> o.__setitem__(e, v)
o[e] <-> o.__getitem__(e)

where e is an expression.

There is no similar way for set/get attribute for objects.
If e is a given name, then

o.e = v <-> o.__setattr__(e, v)
o.e <-> o.__getattr__(e)

Anybody thought about this issue?

We could write something like this:

o.[e] = v
o.[e]

or

o.(e) = v
o.(e)

in this case.

For example:

setattr(self, method_name, getattr(self.metadata,
method_name)) -->
self.(method_name) = self.metadata.(method_name)

setattr(command_obj, neg_opt[option], not
strtobool(value)) -->
command_obj.(neg_opt[option]) = not strtobool(value)

setattr(self, '%s_open' % type,
lambda r, proxy=url, type=type,
meth=self.proxy_open:
meth(r, proxy, type)) -->
self.('%s_open' % type) =
lambda r, proxy=url, type=type,
meth=self.proxy_open: meth(r, proxy, type)

[Peter Hansen]

Заур Шибзухов wrote:
> There is a syntactic sugar for item access in
> dictionaries and sequences:
>
> o[e] = v <-> o.__setitem__(e, v)
> o[e] <-> o.__getitem__(e)
>
> where e is an expression.
>
> There is no similar way for set/get attribute for objects.
> If e is a given name, then
>
> o.e = v <-> o.__setattr__(e, v)
> o.e <-> o.__getattr__(e)
>
> Anybody thought about this issue?

Perhaps not, but now that you've pointed it out they've taken the time
machine back and fixed the problem before it arose:

>>> class C:
... def __setattr__(self, e, v):
... print 'setting %s to %s' % (e, v)
... self.__dict__[e] = v
...
>>> o = C()
>>> v = 'mystring'
>>> o.e = v
setting e to mystring
>>> o.e
'mystring'
>>>

-Peter

[Robert Kern]

I think he means something like this:
e = 'i_am_an_attribute'
o.(e) = 10
o.i_am_an_attribute == 10

--
Robert Kern
rk...@ucsd.edu

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

[Michael Hoffman]

Robert Kern wrote:
>> Заур Шибзухов wrote:
>>
>>> There is a syntactic sugar for item access in
>>> dictionaries and sequences:
>>>
>>> o[e] = v <-> o.__setitem__(e, v)
>>> o[e] <-> o.__getitem__(e)
>>>
>>> where e is an expression.
>>>
>>> There is no similar way for set/get attribute for objects.
>>> If e is a given name, then o.e = v <-> o.__setattr__(e, v)
>>> o.e <-> o.__getattr__(e)
>>>
>>> Anybody thought about this issue?
>

> I think he means something like this:
> e = 'i_am_an_attribute'
> o.(e) = 10
> o.i_am_an_attribute == 10

I always use the getattr() and setattr() built-ins which could be
considered syntactic sugar when compared to the alternatives above.

But that's all the syntactic sugar you need--any more will give you
cancer of the semicolon.
--
Michael Hoffman

[Gary Wilson Jr]

Заур Шибзухов wrote:
> There is a syntactic sugar for item access in
> dictionaries and sequences:
>
> o[e] = v <-> o.__setitem__(e, v)
> o[e] <-> o.__getitem__(e)
>
> where e is an expression.
>
> There is no similar way for set/get attribute for objects.
> If e is a given name, then
>
> o.e = v <-> o.__setattr__(e, v)
> o.e <-> o.__getattr__(e)
>
> Anybody thought about this issue?

How about inheriting the dict class, something like this...

>>> class C(dict):
... pass
...
>>> e = 'myAttribute'
>>> v = 'syntactic sugar'
>>> o = C()
>>> o[e] = v
>>> o[e]
'syntactic sugar'

[Elmo Mäntynen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Peter Hansen wrote:
> Заур Шибзухов wrote:
>
>> There is a syntactic sugar for item access in
>> dictionaries and sequences:
>>
>> o[e] = v <-> o.__setitem__(e, v)
>> o[e] <-> o.__getitem__(e)
>>
>> where e is an expression.
>>
>> There is no similar way for set/get attribute for objects.
>> If e is a given name, then o.e = v <-> o.__setattr__(e, v)
>> o.e <-> o.__getattr__(e)
>>
>> Anybody thought about this issue?
>
>
> Perhaps not, but now that you've pointed it out they've taken the time
> machine back and fixed the problem before it arose:

Maybe funny, but a bit too cocky for my taste. Robert kern is propably
right about what he really meant so don't be too hasty in the future,
right?). Looking at his code example I got the picture that he's of the
kind that could come up with something useful. So either he's
right(which I think is the case), or it's just the kind of silly mistake
all of us sometimes make. I sure think some one should look in to this
suggestion.

>>>> class C:
> ... def __setattr__(self, e, v):
> ... print 'setting %s to %s' % (e, v)
> ... self.__dict__[e] = v
> ...
>>>> o = C()
>>>> v = 'mystring'
>>>> o.e = v
> setting e to mystring
>>>> o.e
> 'mystring'
>>>>
>
> -Peter

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCweYyctNFyQJObrsRAhGtAJwJXlhQ9i1PIQKj1fus6GIq7mfDVgCeJBRw
vq6yJrozRTUSTu+p8akVbVw=
=k4EW
-----END PGP SIGNATURE-----

[Terry Hancock]

On Tuesday 28 June 2005 07:07 pm, Elmo Mäntynen wrote:
> Peter Hansen wrote:
> > Заур Шибзухов wrote:
> >> There is a syntactic sugar for item access in
> >> dictionaries and sequences:
> >> o[e] = v <-> o.__setitem__(e, v)
> >> o[e] <-> o.__getitem__(e)
> >>
> >> where e is an expression.
> >>
> >> There is no similar way for set/get attribute for objects.
> >> If e is a given name, then o.e = v <-> o.__setattr__(e, v)
> >> o.e <-> o.__getattr__(e)
> >>
> >> Anybody thought about this issue?

I'm pretty sure it's been discussed. Javascript unifies the concepts of
dictionary access and object attribute access into the single concept
of "associational array" (there are some limitations to the Javascript
version, so they aren't really equivalent, but for simple cases they
often are).

In Javascript, the expression

a['b']

means the same thing as

a.b

> > Perhaps not, but now that you've pointed it out they've taken the time
> > machine back and fixed the problem before it arose:
>
> Maybe funny, but a bit too cocky for my taste. Robert kern is propably
> right about what he really meant so don't be too hasty in the future,
> right?). Looking at his code example I got the picture that he's of the
> kind that could come up with something useful. So either he's
> right(which I think is the case), or it's just the kind of silly mistake
> all of us sometimes make. I sure think some one should look in to this
> suggestion.

Could be, but I think the absence of "sugar" in this situation is
at least semi-intentional. We already have dictionary access for
when this type of situation is needed. And if you really want an
object that permits either type of access --- that is, for which
dictionary access and attribute access are the same --- it is not
difficult to create one.

OTOH, if it were automatic, it would tend to erase any distinction
between the two concepts. Stylistically, dictionaries are the "right"
thing to use when the elements are going to be very fluid, whereas
objects are expected to have more or less fixed attribute and method
interfaces. Making "access to attribute by string name" more
difficult than "access to dictionary value by string key" is one way
to encourage the distinction.

And, really, when you do need it, __getattr__ / __setattr__ aren't
really *that* difficult to use.

--
Terry Hancock ( hancock at anansispaceworks.com )
Anansi Spaceworks http://www.anansispaceworks.com

[Peter Hansen]

Elmo Mäntynen wrote:
>
> Peter Hansen wrote:
>>Заур Шибзухов wrote:
>>>Anybody thought about this issue?
>>
>>Perhaps not, but now that you've pointed it out they've taken the time
>>machine back and fixed the problem before it arose:
>
> Maybe funny, but a bit too cocky for my taste. Robert kern is propably
> right about what he really meant so don't be too hasty in the future,
> right?).

Elmo, it's probably neither cocky nor funny, but before you pass
judgment you should Google this group for "time machine" and read
awhile. (I was merely attempting to parrot a traditional response that
is given around here when someone asks for something which is already
present in the language.)

And whether I misinterpreted the (ambiguous) question or not, my
response provides the required information to put together a solution to
the OP's question. It would just require one extra level of
indirection, so to speak, to do what Robert suggests he might have wanted.

(Uncocky enough for you this time?)

-Peter

[Michael Hoffman]

Peter Hansen wrote:

> Elmo Mäntynen wrote:
>
>> Maybe funny, but a bit too cocky for my taste. Robert kern is propably
>> right about what he really meant so don't be too hasty in the future,
>> right?).
>
> Elmo, it's probably neither cocky nor funny, but before you pass
> judgment you should Google this group for "time machine" and read
> awhile. (I was merely attempting to parrot a traditional response that
> is given around here when someone asks for something which is already
> present in the language.)
>
> And whether I misinterpreted the (ambiguous) question or not, my
> response provides the required information to put together a solution to
> the OP's question. It would just require one extra level of
> indirection, so to speak, to do what Robert suggests he might have wanted.

I didn't understand the original question either until Robert Kern
guessed what the OP was talking about.
--
Michael Hoffman

[szp...@fromru.com]

Yes, I mean this thing.

[szp...@fromru.com]

> e = 'i_am_an_attribute'
> o.(e) = 10
> o.i_am_an_attribute == 10

Yes I mean this thing: to write

o.(e) = 10

or

o.[e] = 10