[Python-ideas] Default arguments in Python - the return

[Pascal Chambon]

Thanks everyone for the feedback and the links (I was obviously too 
confident in Google's first pages, to miss such things >_<)

Terry Reedy a écrit :
>> And no one seemed to enjoy the possibilities of getting "potentially 
>> static variables" this way.
>
> You did not search hard enough.
>
Well, for sure some people here and there used that semantic to have, 
for example, a "default cache" handling the requests for which a 
specific cache isn't provided.
But that behavior can as easily be obtained with a much more explicit 
way, which furthermore lets you access your default cache easily from 
inside the function code, even when a specific cache is provided :

class a:
    cache=[1,2,3]
    def func(self, x, newcache=cache):
        print "Current cache state :",y
        y.append(x)
        print "The static, default cache is ", cache

So I don't see the default argument trick as a "neat feature", rather as 
a way of doing simple things obscure.

>> Static variables are imo a rather bad idea, 
>
> So you want to take them away from everyone else.  I think *that* is a 
> rather bad idea ;-).  No one is forcing you to use them.
>

I don't want to annihilate all traces of static variables :p ;
I just find them ugly, because they create stateful functions whose 
state is hidden in them (like some do with free variables, too), and 
that's imo not a "robust code best practice".

But what kills me with current default arguments is that those aren't 
even real static variables : they're "potentially static variables", and 
as far as I've seen, you have no easy way to check whether, for 
instance, the argument value that you've gotten is the default, static 
one, or a new one provided by the caller (of course, you can store the 
default value somewhere else for reference, but it's lamely redundant).
If people want static variables in python, for example to avoid OO 
programming and still have stateful functions, we can add an explicit 
"static" keyword or its equivalent. But using the ambiguous value given 
via a default-valued argument is not pretty, imo.
Unless we have a way to access, from inside a code block, the function 
object in which this code block belongs.

Does it exist ? Do we have any way, from inside a call block, to browse 
the default arguments that this code block might receive ?


>
>> I guess this will mean some overhead during function call,
>
> I absolutely guarantee that this will.  Functions calls are expensive. 
> Adding a function call for each default arg (and many functions have 
> more than one) multiplies the calling overhead.
>
> > so this might become another issue.
>
> Is and always has been.
>

Well, if, like it was proposed in previous threads, the expression is 
only reevaluated in particular circumstances (i.e, if the user asks it 
with a special syntax), it won't take more time than the usual "if myarg 
is None : myarg = []" ;
but I agree that alternate syntaxes have led to infinite and complex 
discussions, and that the simpler solution I provided is likely to be 
too CPU intensive, more than I expected...
>
>> /to get what we want (and if None was also a possible value ? 
>
> __none = object()
> def(par = __none):
>   if par == __none: ...
>
> as had been posted each time this question has been asked.
Well, I didn't turn my rhetorical question properly it seems ^^.
I wholly agree that you can always use another object as a placeholder, 
but I don't quite like the idea of creating new instances just to 
signify "that's not a valid value that you can use, create one brand new"

On the other hand, would anyone support my alternative wish, of having a 
builtin "NotGiven", similar to "NotImplemented", and dedicated to this 
somehow usual taks of "placeholder" ?
There would be two major pros for this, imo :
    - giving programmers a handy object for all unvanted "mutable 
default argument" situations, without having to think "is None a value I 
might want to get ?"
    - *Important* : by appearing in the beginning of the doc near True 
and False, this keyword would be much more visible to beginners than the 
deep pages on "default argument handling" ; thus, they'd have much more 
chances to cross warnings on this Gotcha, than they currently have (and 
seeing "NotGiven" in tutorials would force them to wonder why it's so, 
it's imo much more explicit than seeing "None" values instead)

So, since reevaluation of arguments actually *is* a no-go, and 
forbidding mutable arguments is obviously a no-go too, would you people 
support this integrating of "NotGiven" (or any other name) in the 
builtins ? It'd sound to me like a good practice.

Regards,
Pascal