[Python-ideas] proto-PEP: Fixing Non-constant Default Arguments

[Ron Adam]

Josiah Carlson wrote:
> Chris Rebert <cvrebert at gmail.com> wrote:
>> Collin Winter wrote:
>>> On 1/28/07, Chris Rebert <cvrebert at gmail.com> wrote:
>>> Syntax changes are a huge stick to wield against such a small problem.
>>> I realize the boilerplate is annoying, but Tomer has pointed out a
>>> number of decorator-based solutions [1] that could easily be adapted
>>> to any unusual needs you have.
>> One of his decorators assumes that the default value merely needs to be 
>> copied across calls. However, as the PEP says, there are cases where 
>> this isn't sufficient or just doesn't work. His second decorator 
>> involves using lambdas (ick!),
> [snip]
> 
> Using the features of a language to attempt to compensate for that same
> language's (argued) shortcomings are a valid _and encouraged_ approach. 
> Your poo-pooing of Python conditionals, decorators, and lambdas to solve
> this particular problem, to me, seems like you want a *particular
> solution*.
> 
> I don't see a problem with the current default argument semantics.  Why? 
> Because in the case where I would want to receive a mutable parameter,
> like in the case below that wouldn't work with Python's standard
> semantics...
> 
>     def append_10(lst=[]):
>         lst.append(10)
>         return lst
> 
> I would presumably change it to...
> 
>     def append_10(lst=None):
>         if lst is None: lst = []
>         lst.append(10)
>         return lst

Strings sometimes work nice.  Then you have a hint as to what should go there.

      def append_10(lst='[]'):
          if lst == '[]': lst = []
          lst.append(10)
          return lst


> Or some variant thereof.  Now, here's the thing; if I want a mutable
> argument, then None is a nonsensical value to pass, generally, as it is
> not mutable.  So I don't buy the whole "but then None would no longer be a
> valid argument to pass" bull that was offered as a reason why the above
> isn't a reasonable translation (I can't remember who offered it).
> 
> I'm also not convinced by either of the 3 pages that talk about Python
> "gotchas".  You get bitten by it, you learn it, understand it, and move
> on.  If they can't figure it out, I'm not sure I want them writing
> Python software anyways; I certainly wouldn't want them to work on any
> of the Python software I work on and use.
> 
> 
>  - Josiah

I agree,  What seems like a gotcha is some situations can be a feature in others.

At the most, documenting things like this should be more visible.  Like maybe
adding a [Gotcha! Mutable arguments...] info box's in the documents.  I like
those little info box's in manuals, especially if they are written with a bit of
humor.

Cheers,

Ron