467,075 Members | 993 Online
Bytes | Developer Community
Ask Question

Home New Posts Topics Members FAQ

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

Q: attribute access and comparisons of two different objects

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
Jul 18 '05 #1
  • viewed: 1256
Share:
6 Replies
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.

"Chris..." <ch************@web.de> wrote in message
news:24**************************@posting.google.c om...
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

Jul 18 '05 #2
In article <24**************************@posting.google.com >,
Chris... <ch************@web.de> wrote:

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.
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"as long as we like the same operating system, things are cool." --piranha
Jul 18 '05 #3
* Chris... <ch************@web.de> [15-06-2004 10:52]:
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?
class foo(object): ... __slots__ = ['attr1', 'attr2']
... a = foo()
a.attr1 = 2
a.attr2 = 3
a.attr3 = 4 Traceback (most recent call last):
File "<stdin>", line 1, in ?
AttributeError: 'foo' object has no attribute 'attr3'


__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+AJ9hZD4OuFho18EV83K6WW zqC69JpQCfakgp
c7WN8GxsQ8Ka+CRW2AtrsCY=
=7xiF
-----END PGP SIGNATURE-----

Jul 18 '05 #4
"Larry Bates" <lb****@swamisoft.com> wrote in message news:<V4********************@comcast.com>...
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/Coo.../Recipe/252158

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

Michele Simionato
Jul 18 '05 #5

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.
In article <95**************************@posting.google.com >, Michele
Simionato <mi***************@poste.it> wrote:
"Larry Bates" <lb****@swamisoft.com> wrote in message
news:<V4********************@comcast.com>...
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/Coo.../Recipe/252158

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

Michele Simionato

Jul 18 '05 #6
aa**@pythoncraft.com (Aahz) wrote in message news:<ca**********@panix3.panix.com>...
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?


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
Jul 18 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

11 posts views Thread by Dietrich Epp | last post: by
9 posts views Thread by | last post: by
11 posts views Thread by Rosco | last post: by
1 post views Thread by Quimbly | last post: by
18 posts views Thread by Gabriel Rossetti | last post: by
8 posts views Thread by chamalulu | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.