attributes of Python classes

[beliavsky]

I have started using classes with Python and have a question
about their use.

In Python, 'attributes are all "public" and "virtual" in C++
terms; they're all accessible everywhere and all looked up
dynamically at runtime' (Quoting "Learning Python", 2nd. ed.,
p367). It seems to me that two good conventions are to

(1) initialize all attributes in the __init__ function
(2) avoid creating new attributes elsewhere that are not initialized in
__init__

I have not followed these conventions so far, and sometimes
it is difficult for me to tell what attributes an instance of
a class has. Are these conventions good?

[Erik Max Francis]

be*******@aol.c om wrote:

I have started using classes with Python and have a question
about their use.

In Python, 'attributes are all "public" and "virtual" in C++
terms; they're all accessible everywhere and all looked up
dynamically at runtime' (Quoting "Learning Python", 2nd. ed.,
p367). It seems to me that two good conventions are to

(1) initialize all attributes in the __init__ function
(2) avoid creating new attributes elsewhere that are not initialized
in
__init__

I have not followed these conventions so far, and sometimes
it is difficult for me to tell what attributes an instance of
a class has. Are these conventions good?

Yes, I think so, provided a key feature of the class in question isn't
that it's inherently dynamic (in which case it's inherently infeasible
to do this) -- an example might be a class that you'd like to mimic the
interface of a module, so it effectively acts like a dictionary but it
allows attribute access to access the dictionary as well.

I certainly follow them as best as is possible in my own code; I can
only think of once instance in an old project where I don't do that, and
it's marked as ugly in the code.

--
__ Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
/ \ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
\__/ Everyone wants to look good at his own funeral.
-- Louis Wu

[Roy Smith]

In article <40************ ***@alcyone.com >,
Erik Max Francis <ma*@alcyone.co m> wrote:

be*******@aol.c om wrote:

I have started using classes with Python and have a question
about their use.

In Python, 'attributes are all "public" and "virtual" in C++
terms; they're all accessible everywhere and all looked up
dynamically at runtime' (Quoting "Learning Python", 2nd. ed.,
p367). It seems to me that two good conventions are to

(1) initialize all attributes in the __init__ function
(2) avoid creating new attributes elsewhere that are not initialized
in
__init__

I have not followed these conventions so far, and sometimes
it is difficult for me to tell what attributes an instance of
a class has. Are these conventions good?

Yes, I think so, provided a key feature of the class in question isn't
that it's inherently dynamic (in which case it's inherently infeasible
to do this) -- an example might be a class that you'd like to mimic the
interface of a module, so it effectively acts like a dictionary but it
allows attribute access to access the dictionary as well.

I certainly follow them as best as is possible in my own code; I can
only think of once instance in an old project where I don't do that, and
it's marked as ugly in the code.

I agree that initializing all attributes in __init__ is a good idea.
Even if you initialize them to None and overwrite them in some other
method before ever accessing the value, it's still a nice way to help
soem future reader understand your class better. If it's a good idea to
have self-documenting code, I guess it's an even better idea to have
executable comments :-)

[Mike C. Fletcher]

be*******@aol.c om wrote:

I have started using classes with Python and have a question
about their use.

In Python, 'attributes are all "public" and "virtual" in C++
terms; they're all accessible everywhere and all looked up
dynamically at runtime' (Quoting "Learning Python", 2nd. ed.,
p367). It seems to me that two good conventions are to

(1) initialize all attributes in the __init__ function
(2) avoid creating new attributes elsewhere that are not initialized in
__init__

I have not followed these conventions so far, and sometimes
it is difficult for me to tell what attributes an instance of
a class has. Are these conventions good?

I actually go a very different way. Use properties/descriptors for
everything, with the properties declared directly in the class
definition something like so:

class SessionImporter ( sessiondata.Ses sionData ):
"""Holder for importing data with an interactive session

Primary purpose of this class is to provide a way to safely
store partially-constructed records which may reference either
database-resident records, or other partially-constructed
records.
"""
sourceText = common.StringPr operty(
"sourceText ", """Source of the data being imported""",
defaultValue = "",
)
newObjectID = common.IntegerP roperty(
"newObjectI D", """Sequence for the newObjectID of newly created
objects""",
defaultValue = 0,
)
newObjects = common.Dictiona ryProperty(
"newObjects ", """New objects, indexed by newObjectID""",
)
rootObjects = common.ListProp erty(
"rootObject s", """IDs for each root-object to be stored""",
)

and then use generic __init__ and the like that can take any set of
specified properties. This way each attribute is fully documented, can
have intelligently calculated defaults, can be initialised anywhere,
etceteras, but there's not the huge collections of boilerplate
initialisation, copying, etceteras code that's needed with bare
attributes. The fact that it also allows for type-checking and
coercian, and generic code for working with properties, is a nice
side-effect :)

There's still the possibility of having properties without values, but
if that's undesired, just declare each with the default of None or "" or
whatever you like *for that particular property*.

Have fun,
Mike

_______________ _______________ _________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://members.rogers.com/mcfletch/

[Yermat]

Roy Smith a écrit :

In article <40************ ***@alcyone.com >,
Erik Max Francis <ma*@alcyone.co m> wrote:

be*******@aol .com wrote:

I have started using classes with Python and have a question
about their use.

In Python, 'attributes are all "public" and "virtual" in C++
terms; they're all accessible everywhere and all looked up
dynamicall y at runtime' (Quoting "Learning Python", 2nd. ed.,
p367). It seems to me that two good conventions are to

(1) initialize all attributes in the __init__ function
(2) avoid creating new attributes elsewhere that are not initialized
in
__init__

I have not followed these conventions so far, and sometimes
it is difficult for me to tell what attributes an instance of
a class has. Are these conventions good?

Yes, I think so, provided a key feature of the class in question isn't
that it's inherently dynamic (in which case it's inherently infeasible
to do this) -- an example might be a class that you'd like to mimic the
interface of a module, so it effectively acts like a dictionary but it
allows attribute access to access the dictionary as well.

I certainly follow them as best as is possible in my own code; I can
only think of once instance in an old project where I don't do that, and
it's marked as ugly in the code.

I agree that initializing all attributes in __init__ is a good idea.
Even if you initialize them to None and overwrite them in some other
method before ever accessing the value, it's still a nice way to help
soem future reader understand your class better. If it's a good idea to
have self-documenting code, I guess it's an even better idea to have
executable comments :-)

I agree BUT there is 2 cases were I don't follow this rules :

1) I have a project that creates a lot of objects by reading a file. The
time is twice as needed if I initialize first the attribute and then set
them from the values given by the file...

2) When using an algorithm that need to decorate the object, it's easier
to just add attribute to the object rather than create a dictionnary or
something like that.

But for te sake of documentation, your rules sound good to me. For the
first problem, I don't know how to solve it nicely.

The second is not a problem because, the algorithm know what he's doing.

Yermat

[Terry Reedy]

I agree that initializing all attributes in __init__ is a good idea.
Even if you initialize them to None and overwrite them in some other
method before ever accessing the value, it's still a nice way to help
soem future reader understand your class better. If it's a good idea to have self-documenting code, I guess it's an even better idea to have
executable comments :-)

An alternative is to give attributes a default value of None as class
attributes. This avoid time and space overhead of doing same on per
instance basis. Instances only need instance-specific value when there is
one.

class C:
a = None # what a is
b = None # what b is

Terry J. Reedy

[Yermat]

Terry Reedy a écrit :

I agree that initializing all attributes in __init__ is a good idea.
Even if you initialize them to None and overwrite them in some other
method before ever accessing the value, it's still a nice way to help
soem future reader understand your class better. If it's a good idea
to
have self-documenting code, I guess it's an even better idea to have
executable comments :-)

An alternative is to give attributes a default value of None as class
attributes. This avoid time and space overhead of doing same on per
instance basis. Instances only need instance-specific value when there is
one.

class C:
a = None # what a is
b = None # what b is

Terry J. Reedy

Ya right but then the documentation will not be very clear. I was
thinking of two version of my class. Let say A that does not initialize
its variable because it will be done later by the file reader. And B
that inherit A and initialize instance variables.

In the documentation it will be easier to understand which one to use.

Just ideas...
Yermat