Pre-RFC: Function parameter defaults

jplatte:

Well, this thread is about function parameter defaults, not named parameters. I posted it independently (a) because an RFC with both would be way too big IMO, and (b) because I think this makes sense as a feature on its own.

I don't think they're considerable in isolation, really. (And they're both mentioned in the OP.)

Function parameter defaults, at least assuming that more than one is allowed, to me inherently want named parameters to avoid the foo(1, None, None, None, None, None, 30) problem and be able to write foo(1, blah = 30) (or whatever) instead.

(Or, alternatively, they end up wanting overloading to be able to make different sets of possible arguments, but that has different -- worse IMHO -- problems.)

jplatte:

The text above has a Motivation section, so I don't understand this criticism.

Specifically to me the Rationale & Alternatives section is the most important, because it's about why things work this way and why it's better than other possibilities.

The extant motivation section is basically just "I want function parameter defaults". It could similarly be the motivation section for "I want overloaded functions" -- where they're both just named new instead of having a default for the second parameter -- with almost zero changes.