Quoting Joe Strout <joe@strout.net >:
On Nov 13, 2008, at 10:19 AM, Chris Mellon wrote:
Argh. I've been back in the Python community for about a month, and
I've been continually amazed at how every single "how do I do X" or
"what do you think of this method of doing X" question is answered by
people on high horses claiming "you shouldn't do X".
I know very well about state and objects. I'll be happy to whip out
my software engineering credentials and measure them against yours if
that's how you like to play.
Static storage is a way of preserving state. Objects are a way of
encapsulating state and behavior. Use an object.
encapsulating state and behavior. Use an object.
I've been continually amazed at how every single "how do I do X" or
"what do you think of this method of doing X" question is answered by
people on high horses claiming "you shouldn't do X".
I know very well about state and objects. I'll be happy to whip out
my software engineering credentials and measure them against yours if
that's how you like to play.
languages have ditched the "concept" of a static variable on a method (how do
you parse that sentence, btw?) in favour of using encapsulation. Of the top of
my head, there is Java, C# and Python, and I think even PHP and Perl. They call
them "private variables", including the
name-mangled-publicly-accessible-__python's variables.
I only know one family of languages that support it: C/C++ (LISP, maybe? I don't
remember - my list is very sketchy), but here comes into play the fact that your
credentials are bigger. But that may be the reason why you refuse to follow yet
another model.
Python doesn't have the concept of 'static variables', as in "a variable that
remembers its value between function calls". Instance attributes (or class
atributes, or metaclass attributes - your choice, depending on the problem)
exist for that.
So, if you want to simulate your C++ static variables in python, you ha ve a few
choices (more than in other languages, btw):
* Global variable. Ouch. We really don't want you going there :D
* Instance variable. Maybe a __private instance variable, to avoid polluting
your descendant's namespaces.
* Class/Metaclass variables (if you need them - that's rare).
* Closures
* Default arguments (too fragile for my taste)
* Instance variables _of the function object_.
For the last three: (untested code follows)
* With closures:
===
def myfunc():
pseudo_static_l ist = []
def real_function(a rgs):
pseudo_static_l ist.append(args )
print pseudo_static_l ist
return real_function
myfunc = myfunc()
===
[or, until python removes the apply function]
===
@apply
def myfunc():
# same definition as before
return real_function
===
Caveat: you cannot assign, as in python 2.5 at least, to the closure variable -
doing so would create a local variable instead.
* With default argument:
===
def myfunc(normal_a rgs, _hidden_arg=[]):
_hidden_arg.app end(normal_args )
print _hidden arg
===
(You can't shouldn't to _hidden_arg either, and you risk someone invokingthe
function with that argument)
* With function's instance members:
===
def myfunc(args):
myfunc.counter= 1 # well, you should use some logic to see if it's not
# initialized
myfunc.counter+ =1
print myfunc.counter
===
Instance attributes beats them all, though.
I understand very well when data should
be stored as instance data, and when it should be instead tucked away
as static data within a method.
be stored as instance data, and when it should be instead tucked away
as static data within a method.
instance variables made a lot more sense to me that 'static' variables.
If you don't understand that, or are
happy without having the choice, and have no answer to the question I
was asking, then that's fine.
happy without having the choice, and have no answer to the question I
was asking, then that's fine.
palatable to you.
--
Luis Zarrabeitia
Facultad de Matemática y Computación, UH
