[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults -- choice of -> vs @
One similarity that I don't think has been mentioned yet: - decorator syntax says, "run me later, after this function is built" - late-bound argument syntax says, "run me later, just before each function call" Because both mean "run me later" we can leverage the @ symbol to aid understanding; also, because "run me later" can completely change the workings of a function (mutable defaults, anyone?), it deserves more attention than being buried in the middle of the expression where it is easy to miss (which is why I originally proposed the ? -- it stood out better). -- ~Ethan~ ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/VUKFDNJBHSM7GJLKRDJHGQ7WKZZDLB2F/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults -- choice of -> vs @
On Thu, Nov 4, 2021 at 2:29 AM Ethan Furman wrote: > > One similarity that I don't think has been mentioned yet: > > - decorator syntax says, "run me later, after this function is built" > > - late-bound argument syntax says, "run me later, just before each function > call" Hmm, I more think of decorator syntax as "modify this function". It runs at the same time that the def statement does, although the effects may be felt at call time (including a lot of simple ones like lru_cache). > Because both mean "run me later" we can leverage the @ symbol to aid > understanding; also, because "run me later" can > completely change the workings of a function (mutable defaults, anyone?), it > deserves more attention than being buried > in the middle of the expression where it is easy to miss (which is why I > originally proposed the ? -- it stood out better). One of the reasons I want to keep the latebound vs earlybound indication at the equals sign is the presence of annotations. I want to associate the lateboundness of the default with the default itself; consider: def func(spam: list = []) -> str: ... Which part of that becomes late bound? The [], not the name "list", not the name "spam". So if you want to make use of the at sign, it would end up looking like matrix multiplication: def func(spam: list @= []) -> str: ... def func(spam: list =@ []) -> str: ... rather than feeling like decorating the variable. Is that still valuable enough to prefer it? ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/ROHV24OWFTJTD3IWEBKQY6ZA24GOTHO3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults -- choice of -> vs @
On 11/3/21 9:07 AM, Chris Angelico wrote: > On Thu, Nov 4, 2021 at 2:29 AM Ethan Furman wrote: >> One similarity that I don't think has been mentioned yet: >> >> - decorator syntax says, "run me later, after this function is built" >> >> - late-bound argument syntax says, "run me later, just before each function call" > > Hmm, I more think of decorator syntax as "modify this function". It > runs at the same time that the def statement does, although the > effects may be felt at call time (including a lot of simple ones like > lru_cache). Well, if "at the same time" you mean "after the function is defined even though the decorator appears first", then sure. ;-) >> Because both mean "run me later" we can leverage the @ symbol to aid understanding; also, >> because "run me later" can completely change the workings of a function (mutable defaults, >> anyone?), it deserves more attention than being buried in the middle of the expression where >> it is easy to miss (which is why I originally proposed the ? -- it stood out better). > > One of the reasons I want to keep the latebound vs earlybound > indication at the equals sign is the presence of annotations. I want > to associate the lateboundness of the default with the default itself; I think that level of specificity is unnecessary, and counter-productive. When discussing a particular late-bound default, how are you (usually) going to reference it? By name: "the 'spam' parameter is late-bound" -- so decorate the variable name. > So if you want to make use of the at sign, it would end up looking like matrix multiplication: > > def func(spam: list @= []) -> str: ... > def func(spam: list =@ []) -> str: ... > > rather than feeling like decorating the variable. Which is horrible. Put the @ at the front: - its relation to decorators, and delayed evaluation, is much more clear - it stands out better to the reader -- ~Ethan~ ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/PG37EY2GKTQ2HZKOG6XLUTTNSJW7XFE5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults -- choice of -> vs @
On Thu, Nov 04, 2021 at 03:07:22AM +1100, Chris Angelico wrote: > def func(spam: list = []) -> str: ... > > Which part of that becomes late bound? The name "spam" of course. Without the parameter, nothing gets bound at all. > The [], not the name "list", not the name "spam". The type annotation is irrelevant. Its an annotation. There's no sense that the earliness/lateness of the binding comes into it at all. The parameter spam is declared to be a list even if the function is never called and nothing gets bound to it at all. And the [] is merely the expression that is bound to the parameter. I say "merely", but of course the expression is important in the sense that if you want the default value to be an empty list, it won't do to use "Hello world" as the expression. Obviously. But the parameter is, in a sense, more important than the default value, because the default value is only a default. If you pass an argument to the function, the default doesn't get used. So if you talk about the function (either in code, the function's body, or in actual prose), you will say something like: if condition: spam.append(eggs) "if this condition is true, append eggs to spam" rather than "...to the empty list" because it might not be the empty list. We talk about the parameter. The parameter is late bound. Not the empty list. Which empty list? My program might generate millions of them. The only one that matters here is spam. It is *spam* which is late bound. Late binding or early binding is a property of the identifier, not of the value that gets bound to it. Putting the late-bound modifier on the assignment buries it in the middle of what might be a fairly complicated (or hideously complicated!) signature with a type annotations and an expression for the default value: parameter:Optional[Literal[X]|List[T]]=>(alpha if value > 2 else beta)*gamma ... I'm sure that we can make it unambiguous to the compiler, but we may not make it stand out sufficiently to the human reader. It should be front and centre, like the `*` in the `*args` and `**kwargs` syntax. I personally feel that the @ symbol works as a prefix modifier on the parameter. But if you hate the @ symbol, I think that other prefix modifiers may also work: $parameter=expression # perhaps a little too like Sparameter !parameter=expression # "bang" parameter :-) ^parameter=expression >parameter=expression # unary greater than :-) ~parameter=expression Perl calls these symbols that modify an identifier "sigils". Other languages have them too: https://en.wikipedia.org/wiki/Sigil_(computer_programming) I guess this is not really a "true" sigil, because the modifier doesn't follow the parameter name outside of the function header (likewise for the `*args` and `**kwargs` syntax). But the analogy is close: the signal instructs the compiler that this identifier needs to be treated differently by using late-binding instead of early for the default, just as the `*` and `**` sigils instruct the compiler that they are to collect extra positional and keyword arguments. -- Steve ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/P46SWHU5UTDGXIS6IK74JAFX4N3BQIBP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults -- choice of -> vs @
On Wed, Nov 03, 2021 at 10:25:02AM -0700, Ethan Furman wrote: > Which is horrible. Put the @ at the front: > > - its relation to decorators, and delayed evaluation, is much more clear > - it stands out better to the reader I agree. (Well, I would, wouldn't I? :-) But if people really, really hate the idea of the @ symbol as a prefix modifier/sigil, I think that there are some alternatives which also look good. (See my previous post.) !parameter=expression # bang parameter >parameter=expression ^parameter=expression ~parameter=expression (but not $parameter, thank you). I suppose that we could even add yet another overloaded meaning on the asterix: # with no default, * keeps the old meaning of collecting # extra positional values *parameter # with a default, * triggers late-binding *parameter=expression I should hate that, I know I should... but I kinda don't. -- Steve ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/XWLV2BK6NYUJI4XPL3FO7EA2BAIUWB76/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults -- choice of -> vs @
On Thu, Nov 4, 2021 at 4:25 AM Ethan Furman wrote: > > On 11/3/21 9:07 AM, Chris Angelico wrote: > > On Thu, Nov 4, 2021 at 2:29 AM Ethan Furman wrote: > > >> One similarity that I don't think has been mentioned yet: > >> > >> - decorator syntax says, "run me later, after this function is built" > >> > >> - late-bound argument syntax says, "run me later, just before each > function call" > > > > Hmm, I more think of decorator syntax as "modify this function". It > > runs at the same time that the def statement does, although the > > effects may be felt at call time (including a lot of simple ones like > > lru_cache). > > Well, if "at the same time" you mean "after the function is defined even > though the decorator appears first", then sure. > ;-) Yes, I do mean that that's the same time. There are three very different points in the life of a function: 1) Compilation (converting source code to byte code) 2) Definition 3) Invocation Decorators happen at definition time. Yes, the decorator is called after the function is otherwise defined, but that's very little difference (the only way it would be visible is an early-bound default, which would be evaluated prior to decorators being applied - all the rest of the work happens at compilation time). In contrast, late-bound defaults happen at invocation, which is completely separate. > >> Because both mean "run me later" we can leverage the @ symbol to aid > understanding; also, > >> because "run me later" can completely change the workings of a function > (mutable defaults, > >> anyone?), it deserves more attention than being buried in the middle of > the expression where > >> it is easy to miss (which is why I originally proposed the ? -- it stood > out better). > > > > One of the reasons I want to keep the latebound vs earlybound > > indication at the equals sign is the presence of annotations. I want > > to associate the lateboundness of the default with the default itself; > > I think that level of specificity is unnecessary, and counter-productive. > When discussing a particular late-bound > default, how are you (usually) going to reference it? By name: "the 'spam' > parameter is late-bound" -- so decorate the > variable name. You use the name because you can't refer to it other than by name, and that's fine. But it's the *default* that is different. Not the parameter. If you provide a value when you call the function, it doesn't make any difference whether there's an early default, a late default, or no default at all; the name is bound identically regardless. > > So if you want to make use of the at sign, it would end up looking like > matrix multiplication: > > > > def func(spam: list @= []) -> str: ... > > def func(spam: list =@ []) -> str: ... > > > > rather than feeling like decorating the variable. > > Which is horrible. Put the @ at the front: > > - its relation to decorators, and delayed evaluation, is much more clear > - it stands out better to the reader > I agree that both of those are horrible. That's why I'm not advocating either :) ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/EJUKF5PMRUUPJBEDJ6W77PP4AGEBVWLY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults -- choice of -> vs @
On Thu, Nov 4, 2021 at 4:30 AM Steven D'Aprano wrote: > > On Thu, Nov 04, 2021 at 03:07:22AM +1100, Chris Angelico wrote: > > > def func(spam: list = []) -> str: ... > > > > Which part of that becomes late bound? > > The name "spam" of course. Without the parameter, nothing gets bound at > all. True, but the parameter will be bound at the same time (minor implementation details aside) whether there's an early default, a late default, or no default, and (orthogonally) whether a value was provided by the caller. There's nothing early or late there. > > The [], not the name "list", not the name "spam". > > The type annotation is irrelevant. Its an annotation. There's no sense > that the earliness/lateness of the binding comes into it at all. The > parameter spam is declared to be a list even if the function is never > called and nothing gets bound to it at all. Correct, the annotation is irrelevant - but it is between the name and the default. That's why I'm using annotated examples here: to emphasize that separation (which will happen in many codebases), and to highlight the distinction between annotating the name and annotating the expression. > And the [] is merely the expression that is bound to the parameter. > > I say "merely", but of course the expression is important in the sense > that if you want the default value to be an empty list, it won't do to > use "Hello world" as the expression. Obviously. Uhh, but that's exactly the bit that's evaluated at a different time. So it's not "merely" the expression; it is the exact thing that we're changing the behaviour of. > But the parameter is, in a sense, more important than the default value, > because the default value is only a default. If you pass an argument to > the function, the default doesn't get used. So if you talk about the > function (either in code, the function's body, or in actual prose), you > will say something like: > > if condition: > spam.append(eggs) > > "if this condition is true, append eggs to spam" rather than "...to the > empty list" because it might not be the empty list. We talk about the > parameter. The parameter is late bound. Not the empty list. Of course! The parameter is FAR more important than the default, and that's why it comes first. But it's not the parameter that changes. > Late binding or early binding is a property of the identifier, not of > the value that gets bound to it. I disagree :) The identifier is bound in exactly the same way. > I'm sure that we can make it unambiguous to the compiler, but we may not > make it stand out sufficiently to the human reader. It should be front > and centre, like the `*` in the `*args` and `**kwargs` syntax. But *a and **kw are actually different parameter types. They change the meaning of the parameter itself, and therefore annotate that. > I personally feel that the @ symbol works as a prefix modifier on the > parameter. But if you hate the @ symbol, I think that other prefix > modifiers may also work: > > $parameter=expression # perhaps a little too like Sparameter > !parameter=expression # "bang" parameter :-) > ^parameter=expression > >parameter=expression # unary greater than :-) > ~parameter=expression The at sign doesn't particularly bother me, the prefix does. So I'm not really a fan of any of these alternatives. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/KY57ADWX5ISYUDO7N2GHRFV5ERTR2RWP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults -- choice of -> vs @
On Thu, Nov 4, 2021 at 4:38 AM Steven D'Aprano wrote: > > On Wed, Nov 03, 2021 at 10:25:02AM -0700, Ethan Furman wrote: > > > Which is horrible. Put the @ at the front: > > > > - its relation to decorators, and delayed evaluation, is much more clear > > - it stands out better to the reader > > I agree. (Well, I would, wouldn't I? :-) > > But if people really, really hate the idea of the @ symbol as a prefix > modifier/sigil, I think that there are some alternatives which also look > good. (See my previous post.) > > !parameter=expression # bang parameter > >parameter=expression > ^parameter=expression > ~parameter=expression > > (but not $parameter, thank you). > > I suppose that we could even add yet another overloaded meaning on the > asterix: > > # with no default, * keeps the old meaning of collecting > # extra positional values > > *parameter > > # with a default, * triggers late-binding > > *parameter=expression > > I should hate that, I know I should... but I kinda don't. > I'll save you the trouble: I hate that :) As I said in the other post, *param changes the meaning of param itself. If there's any meaning to *param=expr, it should be something like "provide one or more args, but if you provide zero, use this instead". Which seems pretty weird. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/NT5UCVQAFWJXGRHPZXHHCPSIRCCR7RBX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults -- choice of -> vs @
On Thu, Nov 04, 2021 at 04:36:27AM +1100, Chris Angelico wrote: > You use the name because you can't refer to it other than by name, and > that's fine. But it's the *default* that is different. Not the > parameter. Wait, are you saying that the list display here: parameter=[] is different from the list display here? parameter=>[] Well obviously they are distinct *objects*, but we consider that the semantics of the [] is the same here: a = [] b = [] even though a and b get distinct objects. So we should ignore the fact that they give distinct objects. What if we use a singleton as our default? parameter=None parameter=>None Now there's only a single object involved. There is no question at all that the token `None` refers to exactly the same thing in both cases. We cannot possibly say that "it's the *default* that is different" in this case, that one of the Nones is different from the other. But one parameter is still early bound and the other is still late-bound. It's not the binding itself that is different (the implementations are the same: we have a slot with a pointer to an object), and it's not the None defaults that are different, because there is only one None. It must be the parameter that is different. > I agree that both of those are horrible. That's why I'm not advocating either > :) I've lost track of what your preferred syntax is. It is this? # move parameter name into the expression parameter=>expression -- Steve ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/EAT5Y3TZXRJQBODVQWZ3WF3JT5X456CH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults -- choice of -> vs @
On Thu, Nov 4, 2021 at 4:56 AM Steven D'Aprano wrote: > > On Thu, Nov 04, 2021 at 04:36:27AM +1100, Chris Angelico wrote: > > > You use the name because you can't refer to it other than by name, and > > that's fine. But it's the *default* that is different. Not the > > parameter. > > Wait, are you saying that the list display here: > > parameter=[] > > is different from the list display here? > > parameter=>[] > > Well obviously they are distinct *objects*, but we consider > that the semantics of the [] is the same here: > > a = [] > b = [] > > even though a and b get distinct objects. So we should ignore the fact > that they give distinct objects. Here's a closer parallel. a = [] for _ in range(10): b = [] ... code that uses a and b Are the names a and b different? Are the lists different? Is the assignment different? What, exactly, is different? In a sense, nothing is. > What if we use a singleton as our default? > > parameter=None > parameter=>None > > Now there's only a single object involved. There is no question at all > that the token `None` refers to exactly the same thing in both cases. We > cannot possibly say that "it's the *default* that is different" in this > case, that one of the Nones is different from the other. > > But one parameter is still early bound and the other is still > late-bound. The parameters are bound at the same time. One of the defaults is evaluated at function definition time, the other at function invocation time. It's the evaluation of None that is different. > It's not the binding itself that is different (the implementations are > the same: we have a slot with a pointer to an object), and it's not the > None defaults that are different, because there is only one None. It > must be the parameter that is different. Well, you have two evaluations that produce the same result, but that's because None is a singleton. I mean, you could write it like this and get the same result too: parameter=(None,)[0] I'm sure nobody would try to claim that that's the same expression as just None :) Different expressions can easily yield the same object. But the evaluation is what's different - not because the expression is different, but because the timing is. > > I agree that both of those are horrible. That's why I'm not advocating > > either :) > > I've lost track of what your preferred syntax is. It is this? > > # move parameter name into the expression > parameter=>expression > Yeah, but only a weak preference. I'm sticking to it for consistency, but only until something better comes along. However, I don't consider adorning the name to be better. :) ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/67VS5NY3G5W6G6WV2KHTDWKVYTVHQ524/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults -- choice of -> vs @
On 11/3/21 10:35 AM, Steven D'Aprano wrote: > I suppose that we could even add yet another overloaded meaning on the > asterix: > > # with no default, * keeps the old meaning of collecting > # extra positional values > > *parameter > > # with a default, * triggers late-binding > > *parameter=expression > > I should hate that, I know I should... but I kinda don't. Don't worry, I do. ;-) -- ~Ethan~ ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/C675R5WABWBHT3O7GZH7HR4736SKY7HO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults -- choice of -> vs @
There’s some conflict about whether it’s the name or the expression that’s different, and thus should be adorned. But it’s neither: it’s the “=“ that’s different— so that’s what should be a different symbol. As for “=>” — I like it now, but if that same symbol is adopted for lambda, it would be horrible. -CHB On Wed, Nov 3, 2021 at 11:16 AM Ethan Furman wrote: > On 11/3/21 10:35 AM, Steven D'Aprano wrote: > > > I suppose that we could even add yet another overloaded meaning on the > > asterix: > > > > # with no default, * keeps the old meaning of collecting > > # extra positional values > > > > *parameter > > > > # with a default, * triggers late-binding > > > > *parameter=expression > > > > I should hate that, I know I should... but I kinda don't. > > Don't worry, I do. ;-) > > -- > ~Ethan~ > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/C675R5WABWBHT3O7GZH7HR4736SKY7HO/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/5LAHNG6AO5FLGVD5UV3RKGFA7J2TFZFD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults -- choice of -> vs @
On 2021-11-03 18:14, Ethan Furman wrote: On 11/3/21 10:35 AM, Steven D'Aprano wrote: > I suppose that we could even add yet another overloaded meaning on the > asterix: > > # with no default, * keeps the old meaning of collecting > # extra positional values > > *parameter > > # with a default, * triggers late-binding > > *parameter=expression > > I should hate that, I know I should... but I kinda don't. Don't worry, I do. ;-) How about: parameter=*expression so, for example: parameter=*[] indicates that you get a new list for each default, so multiple lists, not a single shared list? ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/7L4DYTUTQYP4A6OIHN45IKVZOTXUBZPM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults -- choice of -> vs @
On Wed, Nov 3, 2021, 2:40 PM MRAB wrote: > On 2021-11-03 18:14, Ethan Furman wrote: > > On 11/3/21 10:35 AM, Steven D'Aprano wrote: > > > > > I suppose that we could even add yet another overloaded meaning on > the > > > asterix: > > > > > > # with no default, * keeps the old meaning of collecting > > > # extra positional values > > > > > > *parameter > > > > > > # with a default, * triggers late-binding > > > > > > *parameter=expression > > > > > > I should hate that, I know I should... but I kinda don't. > > > > Don't worry, I do. ;-) > > > How about: > > parameter=*expression > > so, for example: > > parameter=*[] > > indicates that you get a new list for each default, so multiple lists, > not a single shared list? > I'm sure I could get used to it, but that looks to me like you're unpacking an empty list and assigning the resulting tuple. It's weird. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/5IQURP77KMIZOCNU7PDNFOKAHGJCZ7LP/ Code of Conduct: http://python.org/psf/codeofconduct/
