mutable default parameter problem [Prothon]

[Troy Melhase]

On Tuesday 15 June 2004 10:52 pm, Mark Hahn wrote:
> Troy Melhase wrote:
> > Here's an idea:  if it ain't broke, don't fix it.
> >
> > Seriously, you see a "wart" and a "problem".  I see a pleasant
> > side-effect of the documented semantics.  True, new folks are
> > surprised by the behavior, but once it's understood, it becomes more
> > powerful.
>
> All four of the Python gotcha's, wart's and regrets lists I have found
> included this problem.  It is not only a newbie's problem as I showed in my
> posting.

You're right, it's not a newbie problem.  It's a problem for everyone who 
hasn't bothered to read the documentation.

> > How do you intend to account for code like this:
> >
> > def F(a, b, cache={}):
> >     try:
> >         return cache[(a,b)]
> >     except (IndexError, ):
> >         value = cache[(a,b)] = do_some_long_calc(a,b)
> >         return value
> >
> > Or even this:
> >
> > shared_cache = {}
> >
> > def F(a, b, cache=shared_cache):
> >     ...
>
> The first example is very unreadable and uncool in general.  Your second
> example will work just fine with our fix.

Uncool?  Do you mean "uncool" as in "forking a language and distracting a 
bunch of folks because I don't like its otherwise hard-earned design 
decisions" or "uncool" as in "I don't know how to otherwise express my 
thoughts and therefore will assign to them some magnificently subjective 
expression"? 

> I disagree strongly.  I would never be caught coding something like that
> and I love Python dearly.

Then you are limiting yourself to a subset of something wonderful.  

(And by the way, one definition of love means to accept what we perceive as 
deficiencies.  So maybe you don't love Python as dearly as you love the idea 
of Python.)

> > Python is a tool, and you decrease the utility of that tool when you
> > limit it's idioms.
>
> So far you have only shown me an idiom that many say should not be used.
> Show me one that everyone agrees is useful.

If you're goal is universal acceptance, you should stop now.

> > And see 67 instances just in the standard library.  Multiply that by
> > a factor of 1000, 10000 or more to reflect code in the field, and you
> > might start to understand the significance of changing the language
> > definition.
>
> That count is not accurate.  Fixing this will not break every use of [] as
> a default formal param.  Using [] in __init__ for example would break
> nothing. I can think of many other cases where it is legal to use [].  The
> only case I can think of that would break would be the idiom we disagree on
> above.  If I am wrong, then show me other cases.

Oh, but it will.  You'll have to read and comprehend every function definition 
that uses mutable default arguments to start to prove otherwise.

> If I also might make a general argument for the fix then let me continue.
> Doing a late evaluation of the default expression makes the language more
> dynamic, which fits the overall goal of making Prothon more dynamic.  Using
> prototypes instead of classes, dynamic var scoping, this fix, and many
> other Prothon changes from Python all work towards that goal.
>
> Dynamic var scoping fixed another Python gotcha which doesn't break
> anything.  Here are the two versions of code showing the problem and the
> fix:

[snip]

Maybe you should take a step back and look at what you're doing.  From my 
perspective, you're adding a whole lot of additional rules to the language, 
and a completely different way of doing things.  That's fine, and more power 
to you, but if you're bent on changing so much, you should stop looking to  
c.l.p to validate your ideas.

(Of course, I don't speak for the Python community or c.l.p, but I am 
horrified nonetheless with what you're doing.  Please forgive me if I've been 
disagreeable while disagreeing.)

-- 
Troy Melhase, troy at gci.net
--
It is terrible to contemplete how few politicians are hanged. - G. K. 
Chesterton