There was a typo in my post and I want to avoid getting into a pedantic tangent about how to properly indent multi-line function signatures, so hopefully this will "nip it in the bud", so to speak. When I wrote: def my_func( param: Annotation[stuff], other_param: MoreAnnotation[things], another_param: SomeType = default_value, yet_another_param: EvenMoreAnnotation = another_default) -> ReturnType: # code goes here ... I meant the parameter list to be at two indentation levels so it's visually distinguishable from the function body at one indentation level. I accidentally put the parameter list at three indentation levels which happen to align with the open parentheses after `def my_func` which is not what I wanted to suggest as good practice because then functions with long names would have their parameter list indented way far over and it would hurt readability. The following is closer to what I intended: *def my_func( param: Annotation[stuff], other_param: MoreAnnotation[things], another_param: SomeType = default_value, yet_another_param: EvenMoreAnnotation = another_default) -> ReturnType: # code goes here ...* On Thursday, December 2, 2021 at 5:56:36 PM UTC-6 abed...@gmail.com wrote:

If the coder's intent is to have an optional parameter default to an empty

...

list, the most EXPLICIT way to encode that intent would be to have the optional parameter default to an empty list. It's categorically LESS EXPLICIT to bind the parameter to None and add boilerplate code to the body of the function to correct that.

I think it's a nearly philosophical distinction but right now there is no such thing as “an optional parameter defaulting to an empty list”. Or rather there is, but it's not what you really want “a different empty list for every call of the function”.

It's not philosophical. It's pretty cut and dry: If you want a parameter to default to an empty list, it's objectively more explicit to make the parameter default to an empty list than to make it default to a sentinel value and assign it to an empty list later. Of course that capability doesn't exist yet, that's what this whole discussion is about.

To me, it's not absurd that “creating a new object and binding the

...

parameter to it” is sufficiently complex that we don't cram it into the function signature. It's fine to just have code in the function body...

It may not be absurd to you, but to me, the function signature is the correct place to put all things related to the function signature, the function body is for business logic. You're argument about "cramming things in the function signature" is more about practical constraints like keeping things on one line which is less important to me than putting things where they belong. You can always expand the signature, which is a practice I wish more people did.

Instead of this:

def my_func(param: Annotation[stuff], other_param: MoreAnnotation[things], another_param: SomeType = default_value, yet_another_param: EvenMoreAnnotation = another_default) -> ReturnType: # code goes here ...

just do this:

def my_func( param: Annotation[stuff], other_param: MoreAnnotation[things], another_param: SomeType = default_value, yet_another_param: EvenMoreAnnotation = another_default) -> ReturnType: # code goes here ...

The repulsion against "cram[ing] [defaults] into the function signature" is more a problem with long function signatures than anything else. You can always use the usual suspects to make it more readable:

instead of this:

def my_func(param: SomeType => long and complicated logic that's hard to read and fits too much in one line) -> ReturnValue: ...

just do this:

def _provide_default() -> SomeType: the same logic as above but more readable and better organized

def my_func(param: SomeType => _provide_default()) -> ReturnValue: ...

especially since there does not seem to be an overwhelming consensus for

...

either the concept or the proposed syntaxes.

The above explanation of why it's objectively more explicit is not subject to the consensus of the python ideas list. It's a refutation of the argument that current familiar work-arounds are somehow more explicit. That somehow binding to a sentinel is actually an explicit way of "telling the function you want it to provide a default value" rather than a work-around that's so familiar that you no longer even question if it's all that explicit in the first place.

(Also maybe not calling what we have been happily (at least for some of

...

us) doing for years "a hack" would be a good way to have a more civil discussion)

Why? It's not a personal attack. The whole point is to prod people into rethinking what they've become inured to.

On Thu, Dec 2, 2021 at 3:11 PM Evpok Padding <evpok....@gmail.com> wrote:

...

On Thu, 2 Dec 2021, 21:48 abed...@gmail.com, <abed...@gmail.com> wrote:

...

Nicholas Cole "There is nothing that this proposal makes possible that is not already possible with more explicit code."

There's nothing any of Python's syntax makes possible that is not already possible with Brainfuck or any other language that's Turing complete. The current hacks used to get around the lack of late-bound optional parameters aren't more explicit. They just require more code. If the coder's intent is to have an optional parameter default to an empty list, the most EXPLICIT way to encode that intent would be to have the optional parameter default to an empty list. It's categorically LESS EXPLICIT to bind the parameter to None and add boilerplate code to the body of the function to correct that.

I think it's a nearly philosophical distinction but right now there is no such thing as “an optional parameter defaulting to an empty list”. Or rather there is, but it's not what you really want “a different empty list for every call of the function”. To me, it's not absurd that “creating a new object and binding the parameter to it” is sufficiently complex that we don't cram it into the function signature. It's fine to just have code in the function body, especially since there does not seem to be an overwhelming consensus for either the concept or the proposed syntaxes.

(Also maybe not calling what we have been happily (at least for some of us) doing for years "a hack" would be a good way to have a more civil discussion)

Best

E