[Python-ideas] Default arguments in Python - the return
chambon.pascal at wanadoo.fr
Sat May 9 12:56:20 CEST 2009
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 :
def func(self, x, newcache=cache):
print "Current cache state :",y
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.
More information about the Python-ideas