using "private" parameters as static storage?

[Luis Zarrabeitia]

Quoting Joe Strout <joe at strout.net>:

> On Nov 13, 2008, at 10:19 AM, Chris Mellon wrote:
> 
> > Static storage is a way of preserving state. Objects are a way of
> > encapsulating state and behavior. Use an object.
> 
> 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.  

I'm sure your credentials are bigger than mine. But he is right. A lot of
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_list = []
    def real_function(args):
         pseudo_static_list.append(args)
         print pseudo_static_list
    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_args, _hidden_arg=[]):
    _hidden_arg.append(normal_args)
    print _hidden arg
===
(You can't shouldn't to _hidden_arg either, and you risk someone invoking the
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.

OT: Please enlighthen me. I didn't grew with C, and even when I saw C++,
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.  

I believe he had an answer... You didn't like it, though. I hope mine was more
palatable to you.

-- 
Luis Zarrabeitia
Facultad de Matemática y Computación, UH
http://profesores.matcom.uh.cu/~kyrie