Set/Get attribute syntatic sugar

[=?koi8-r?b?+sHV0iA=?= =?koi8-r?b?+8nC2tXIz9c=?=]

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]

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:
.... def __setattr__(self, e, v):
.... print 'setting %s to %s' % (e, v)
.... self.__dict__[e] = v
....
-Peter

 

[Robert Kern]

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:
... def __setattr__(self, e, v):
... print 'setting %s to %s' % (e, v)
... self.__dict__[e] = v
...

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

--
Robert Kern
(e-mail address removed)

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

 

[Michael Hoffman]

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.

 

[Guest]

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

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.

... def __setattr__(self, e, v):
... print 'setting %s to %s' % (e, v)
... self.__dict__[e] = v
...
-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]

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

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.

 

[Peter Hansen]

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]

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.

 

[szport]

Yes, I mean this thing.

 

[szport]

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