On Thu, 2008-11-13 at 09:38 -0800, Matimus wrote:
> On Nov 13, 9:16 am, Joe Strout <[EMAIL PROTECTED]> wrote:
> > One thing I miss as I move from REALbasic to Python is the ability to
> > have static storage within a method -- i.e. storage that is persistent
> > between calls, but not visible outside the method. I frequently use
> > this for such things as caching, or for keeping track of how many
> > objects a factory function has created, and so on.
> >
> > Today it occurred to me to use a mutable object as the default value
> > of a parameter. A simple example:
> >
> > def spam(_count=[0]):
> > _count[0] += 1
> > return "spam " * _count[0]
> >
> > >>> spam()
> > 'spam '
> > >>> spam()
> > 'spam spam '
> >
>
> Don't Do this, it is confusing and there are definitely (many) better
> facilities in python for handling saved state.
>
>
> > Ooh, for a change I had another thought BEFORE hitting Send rather
> > than after. Here's another trick:
> >
> > def spam2():
> > if not hasattr(spam2,'count'):spam2.count=0
> > spam2.count += 1
> > return "spam2 " * spam2.count
>
>
> This is definitely preferred over the first. However the preferred
> method is just to use a class. Preserving state is what classes are
> for.
>
Preserving state is what *objects* are for. Even the builtins have
state to be preserved (list.__len__, func.func_code, for example).
Classes are for creating custom objects.
> >>> class Spam(object):
> ... def __init__(self):
> ... self._count = 0
> ... def spam(self):
> ... self._count += 1
> ... return " ".join("spam" for _ in xrange(self._count))
> ...
Oh of course. This is a much cleaner way to return the response than
the one I used. (FYI, I used: `return ("spam " * self._count).rstrip()`
and I didn't like the rstrip even when I was doing it. Dunno why I
didn't think of it.)
> >>> class Spam(object):
> ... def __init__(self):
> ... self._count = 0
> ...
> ... def spam(self):
> ... self._count += 1
> ... return " ".join("spam" for _ in xrange(self._count))
> ...
> ... __call__ = spam
> ...
Interesting. I hadn't thought of making __call__ a synonym for an
existing method. I think I like that, but I'm not quite sure. There's
something that nags at me about having two ways to do the same thing,
but I like giving the method a more descriptive name than __call__.
Cheers,
Cliff
--
http://mail.python.org/mailman/listinfo/python-list
