I like the => syntax and would use it probably 80% of the time for mutable defaults.
I don't think it causes cognitive load.
I especially disagree with the argument that it looks like arbitrary symbols and adds more 'line noise' than a keyword. My eye picks it up as a distinct arrow rather than a random assembly of punctuation. Maybe it's not as hard as people claim to visually parse strings of punctuation that make little pictures ¯\_(ツ)_/¯
I also disagree that it makes Python harder to teach or learn. You *have to* teach students about early binding anyway. That's the hard part. Explaining how parameter binding works so that they can avoid the pit traps is the hard part. Then you either show them a verbose and clumsy work around of checking for a sentinel or you show them a cute little arrow.
I think people are missing the overall point of doing in the function header what belongs in the function header so that it doesn't spill into the body.
My favorite alternative is ?= if people think => and -> are getting overly loaded. What I really don't like is @param= because it puts the emphasis on the parameter name rather than the act of binding. Not only does it make it look like @param is a special kind of variable, it also mimics the *args and **kwargs syntax which makes them seem related.
On Wed, Dec 1, 2021, 8:36 PM Chris Angelico firstname.lastname@example.org wrote:
On Thu, Dec 2, 2021 at 1:30 PM Steven D'Aprano email@example.com wrote:
On Wed, Dec 01, 2021 at 12:26:33PM +0000, Matt del Valle wrote:
If anything I think the symmetry between the proposed '=>' syntax and the arrow syntax for lambdas in other languages (potentially even in python in the future) reduces the cognitive burden significantly, given the there is an equivalent symmetry with their semantics (in both cases the code is
evaluated later when something is called).
It may be that behind the scenes the default expression is stored as a callable function which the interpreter calls. (I believe that list comprehensions do something similar.) But that's an implementation detail that can change: it might just as well store the source code as a string, and pass it to eval().
In my reference implementation, there is no object that stores it; it's simply part of the function. A good parallel is the if/else expression:
x = float("inf") if z == 0 else y/z
Is there an object that represents the if/else expression (or the deferred "y/z" part)? No, although it could be implemented that way if you chose:
x = iff(z == 0, lambda: y/z, lambda: float("inf"))
But just because you CAN use a function to simulate this behaviour, that doesn't mean that it's inherently a function.
So I agree with Steve that the parallel is quite weak. That said, though, I still like the arrow notation, not because of any parallel with a lambda function, but because of the parallel with assignment.
(And hey. You're allowed to think of things in any way you like. I'm not forcing you to interpret everything using the same justifications I do.)
Or use some other mechanism that I'm not clever enough to think of, so I shall just call "deepest black magic".
Remind me some time to use some slightly shallower black magic.
There is no *neccessity* for the late-bound default to be a hidden function, and it is certainly not part of the semantics of late-bound defaults. Just the implementation.
If you disagree, and still think that the symmetry is powerful enough to use the same syntax for both lambdas and default arguments, well, how about if we *literally* do that?
def function(spam=expression, # regular default lambda eggs: expression, # late-bound default )
Heh, perhaps the symmetry is not that strong after all :-)
That..... is hilariously confusing. I like it. Just not EVER in the language :)
ChrisA _______________________________________________ Python-ideas mailing list -- firstname.lastname@example.org To unsubscribe send an email to email@example.com https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://firstname.lastname@example.org/message/AQWFM7... Code of Conduct: http://python.org/psf/codeofconduct/