static variables?

Brian McErlean b_mcerlean at yahoo.com
Fri Nov 22 06:12:26 EST 2002


Erik Max Francis <max at alcyone.com> wrote in message news:<3DDD556B.3936A6AE at alcyone.com>...
>
> Nitpicking aside, it is easy to turn the simply suggestion I gave into a
> well-defined and easily implementable approach.  You can even do it with
> relatively little change:  As now, stow off a unique instance of each
> default argument as Python already does.  When it comes time to use one
> (i.e., the function is called and one of those arguments is not
> supplied), make a copy (via copy.copy, or copy.deepcopy if you prefer)
> of the default argument and use _that_ instead of the original unique
> object.  Voila, problem solved.

I think this could present problems that are just as bad.  This will
work OK for simple types like lists, but what about instances,
classes, or extension types, some of which currently can't be copied,
many for good reasons (eg Locks).  Just because people can get
confused by the current behaviour doesn't mean they wouldn't by a
different one.

A better way might be to compile the expression and store off the
bytecode, to be executed each function invocation if nothing is bound
to the parameter - sort of an extra, optional, first line to the
function.  This way you're binding to the same object if an existing
object is specified by name (Assuming the globals weren't tampered
with between calls), but still constructing new objects if [], or
MyClass() is in the parameters.  It could still be possible to confuse
people (especially if they're used to/expect the current way), so
perhaps this would still just exchange one set of problems for
another.

> Am I suggesting this be done?  No.  Would it help newbies get over that
> hump that everyone new to Python seems to bump into at least once? 
> Maybe; I don't know.  Is it worth doing now?  No, because the current
> behavior is so well-entrenched, good or bad.

Yeah,  I don't think its possible to change now.  I think maybe the
above way might have been better, though it would cost in performance.
 Easy to say this with 20-20 hindsight of course.



More information about the Python-list mailing list