Q: attribute access and comparisons of two different objects

[Chris...]

Two simple questions regarding future of Python:

1) Is there already a "fix" to avoid writing to an attribute that
isn't defined yet? I remember this being an often discussed problem,
but didn't see any changes. The only way I can think of is overriding
__setattr__, but this is huge overhead. While I like the idea of
being able to add new attributes on the fly, in great projects I'd
like to restrict some classes not to do so.

2) This is driving me nuts: I do not want to compare apples and peas.
I can say that they are not equal, but I cannot say that one is great
than the other (speaking not of greater taste ;-). Just ran into a
problem caused by comparing a string with a number ("1" > 10) -- I
simply forgot to convert the string to an integer. Since I cannot add
"1" + 10 which makes sense, I do not want to compare them. Any
development regarding this? Any """from __future__ import"""?

- Chris

 

[Larry Bates]

1) In Python 2.3 there is a new __slots__ methodology that
does what you want with class attributes. One must wonder
how everyone got by without it for so many years. I'm not
sure I understand the "overhead" issue. Some code must be
executed to determine if an attribute exists or not, why
shouldn't it be up to the programmer to write it by
overriding __setattr__ method?

2) Why don't these programming languages do what I mean
instead of what I tell them to do? ;-)

HTH,
Larry Bates
Syscon, Inc.

 

[Aloysio Figueiredo]

Two simple questions regarding future of Python:

1) Is there already a "fix" to avoid writing to an attribute that
isn't defined yet? I remember this being an often discussed problem,
but didn't see any changes. The only way I can think of is overriding
__setattr__, but this is huge overhead. While I like the idea of
being able to add new attributes on the fly, in great projects I'd
like to restrict some classes not to do so.

I have a "fix" in mind, but I would like the community to comment
because I don't know if it's good practice. What about using the __slots__
attribute to prevent creation of new attributes on the fly?
... __slots__ = ['attr1', 'attr2']
... Traceback (most recent call last):

__slots__ is documented in
http://www.python.org/doc/current/ref/slots.html

Aloysio

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAzwSm3Z98a+m7958RAjI+AJ9hZD4OuFho18EV83K6WWzqC69JpQCfakgp
c7WN8GxsQ8Ka+CRW2AtrsCY=
=7xiF
-----END PGP SIGNATURE-----

 

[Aahz]

1) Is there already a "fix" to avoid writing to an attribute that
isn't defined yet? I remember this being an often discussed problem,
but didn't see any changes. The only way I can think of is overriding
__setattr__, but this is huge overhead. While I like the idea of
being able to add new attributes on the fly, in great projects I'd
like to restrict some classes not to do so.

Don't use __slots__. Why do you think __setattr__ is a huge overhead?

2) This is driving me nuts: I do not want to compare apples and peas.
I can say that they are not equal, but I cannot say that one is great
than the other (speaking not of greater taste ;-). Just ran into a
problem caused by comparing a string with a number ("1" > 10) -- I
simply forgot to convert the string to an integer. Since I cannot add
"1" + 10 which makes sense, I do not want to compare them. Any
development regarding this? Any """from __future__ import"""?

You'll have to wait for Python 3.0 for the core to fully support this;
meanwhile, you can only force this with your own classes.

 

[Michele Simionato]

1) In Python 2.3 there is a new __slots__ methodology that
does what you want with class attributes. One must wonder
how everyone got by without it for so many years. I'm not
sure I understand the "overhead" issue. Some code must be
executed to determine if an attribute exists or not, why
shouldn't it be up to the programmer to write it by
overriding __setattr__ method?

__slots__ should never be used to restrict attribute access;
they are just a memory saving optimization; you are better off
not using it if you can. See this recipe:

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/252158

Yes, overriding __setattr__ has a performance overhaud, so
just do not freeze your attributes! That's the Pythonic solution.

Michele Simionato

 

[Jean Brouwers]

Permit me to comment on this. Restricted atrtibute access may not be a
feature of __slots__, but combined with the memory savings and run time
improvement, it is another, secondary benefit of __slots__.

Overriding __setattr__ provides restricted access but at a significant
run time cost compared to __slots__ and without the other benefits of
__slots__. My posting from May 15 shows some figures without
overloading __setattr__. (Google "group:comp.lang.python.* __slots__ vs
__dict__").

Based on other postings in this group there seems to be a legitimate
need for limiting class extensility without incurring a signficant
performance penalty. For production Python applications the choice
between using __slots__ and overriding __setattr__ is obviously in
favor of the former.

/Jean Brouwers
ProphICy Semiconductor, Inc.

 

[Chris...]

Don't use __slots__. Why do you think __setattr__ is a huge overhead?

Ok, I won't use __slots__. I was trying it anway and found out that
it doesn't satisfy my needs. I do not like the idea of implementing
__setattr__ either. For each class I have to write my own __setattr__
which has to look up a class attribute like __attributes__ = ['attr1',
'attr2']. But I have to write it for each new class, right?

- Chris