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.
Whoups, I meant "from inside a *code* block" :p
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 :)
But that's the "self function" thread you noted, I missed that one...
thanks for pointing it ^^
Well, to me there was like a ternary semantic for arguments :
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.
*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
^^ I'm maybe the only one, but I've always found the quickest way to
a language/library was to read the doc.
Heh heh heh, he thinks beginners read manuals :-)
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
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,
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
But imo, it'd be worth having a simple and "consensual way" of
obtaining dynamic evaluation of default arguments, without the "if
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 = *):
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 ?
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
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