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

[Pascal Chambon]

Well well well,

lots of interesting points have flowed there, I won't have any chance of 
reacting to each one ^^

> >And no one seemed to enjoy the possibilities of getting "potentially 
> static variables" this way.
 >You did not search hard enough.

Would anyone mind pointing me to people that have made a sweet use of 
mutable default arguments ?
At the moment I've only run into "memoization" thingies, which looked 
rather awkward to me : either the "memo" has to be used from elsewhere 
in the program, and having to access it by browsing the "func_defaults" 
looks not at all "KISS", or it's really some private data from the 
function, and having it exposed in its interface is rather error-prone.


> [...]
>   
>> Does it exist ? Do we have any way, from inside a call block, to
>> browse the default arguments that this code block might receive ?
>>     
> [...]
>
> dir(func_object) is your friend :)
>
>   
Whoups, I meant "from inside a *code* block" :p
But that's the "self function" thread you noted, I missed that one... 
thanks for pointing it ^^


>> 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 already is such a beast: None is designed to be used as a 
> placeholder for Not Given, Nothing, No Result, etc. 
>
> If None is not suitable, NotImplemented is also a perfectly good 
> built-in singleton object which can be used as a sentinel. It's already 
> used as a sentinel for a number of built-in functions and operators. 
> There's no reason you can't use it as well.
>
>   
Well, to me there was like a ternary semantic for arguments :
*None -> make without this argument / don't use this feature
*"NotGiven" -> create the parameter yourself
*"Some value" -> use this value as a parameter
But after reflexion, it's quite rare that the three meanings have to be 
used in the same place, so I guess it's ok like it is...

Even though, still, I'd not be against new, more explicit builtins. 
"None" has too many meanings to be "self documenting", and I feel 
"NotImplemented" doesn't really fit where we mean "notGiven"
That's the same thing for exceptions : I've seen people forced to make 
ugly workarounds because they got "ValueError" where they would have 
loved to get "EmptyIterableError" or other precise exceptions.
But maybe I'm worrying on details there :p

> Heh heh heh, he thinks beginners read manuals :-)
>
>   
 ^^ I'm maybe the only one, but I've always found the quickest way to 
learn a language/library was to read the doc.
Wanna learn python ? Read the language reference, then the library 
reference. Wanna know what's the object model of PHP5 versus PHP4 ? Read 
the 50 pages chapter on that matter. Wanna play with Qt ? Read the class 
libraries first. :p
Good docs get read like novels, and it's fun to cross most of the 
gotchas and implementation limitations without having to be biten by 
them first. People might have the feeling that they gain time by jumping 
to the practice, I've rather the feeling that they lose hell a lot of 
it, that way.



Back to the "mutable default arguments" thingy :
I think I perfectly see the points in favor of having them as attributes 
of the function method, as it's the case currently.
It does make sense in many ways, even if less sense than "class 
attributes", for sure (the object model of python is rock solid to me, 
whereas default arguments are on a thin border that few languages had 
the courage to explore - most of them forbidding non-litteral constants).

But imo, it'd be worth having a simple and "consensual way" of obtaining 
dynamic evaluation of default arguments, without the "if arg==none:" 
pattern.
The decorators that people have submitted have sweet uses, but they 
either deepcopy arguments, use dynamic evaluation of code strings, or 
force to lamba-wrap all arguments ; so they're not equivalent to what 
newbies would most of the time expect - a reevaluation of the python 
code they entered after '='.

So the best, imo, would really be a keyword or some other form that 
reproduces with an easy syntax the "lambda-wrapping" we had.

If adding keywords is too violent, what would you people think of some 
notation similar to what we already have in the "function arguments 
world ", i.e stars ?

def func(a, c = *[]):
    pass

Having 1, 2 or 3 stars in the "default argument" expression, wouldn't it 
be OK ? I guess they have no meaning there at the moment, so we could 
give them one : "keep that code as a lamda functio nand evaluate it at 
each function call".
Couldn't we ?
The risk would be confusion with the other "*" and "**", but in this 
case we might put 3 stars (yeah, that's much but...).

Any comment on this ?

Regards,
Pascal

PS : Has anyone read Dale Carneghie's books here ? That guy is a genius 
of social interactions, and I guess that if 1/3 of posters/mailers had 
read him, there would never be any flame anymore on forums and mailing 
lists.
Contrarily to what his titles might look like, he doesn't promote 
hypocrisy or cowardness ; he simply points lots of attitudes (often 
unconscious) that ruin discussions without helping in any way the matter 
go forward.
I'm myself used to letting scornful or aggressives sentences pass by ; 
but others don't like them, and I fully understand why.
So could't we smoothen edges, in order to keep the discusion as it's 
supposed to be - a harmless sharing of pros and cons arguments, which 
endangers no one's life - instead of having it randomly turned into a 
confrontation of egos, pushing each other down as in an attempt not to 
drown ?
http://en.wikipedia.org/wiki/How_to_Win_Friends_and_Influence_People



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20090511/4c454eca/attachment.html>