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