On Tue, Oct 26, 2021 at 5:50 AM Erik Demaine <edema...@mit.edu> wrote:
> But you're definitely right that it's easier to give permissions later than
> take them away, and there are two natural left-to-right orders...
>
> Speaking of implementation as Guido just raised, maybe going with what makes
> the most sense in the implementation would be fitting here? I'm guessing it's
> left-to-right overall (among all arguments), which is also the
> simpler-to-explain rule. I would actually find it pretty weird for references
> to arguments to the right to make sense even if they could...
>
> Actually, if we use the left-to-right overall order, this is the more
> conservative choice. If code worked with that order, and we later decided
> that the two-pass default assignment is better, it would be
> backward-compatible (except that some previously failing code would no longer
> fail).
Maybe I'm overthinking the parallels with existing idioms. There is no
current idiom which can be described as having a perfect correlation,
so maybe it's best to just describe all of them as very rough
approximations, and think solely about the behaviour of a function in
a post-PEP-671 world. Let's try this.
* Function parameters *
A function receives some number of parameters as defined by its
signature. When a function is called, parameters get assigned their
values in the order that they are listed; either they are assigned an
argument as given by the caller, or the default given in the
signature. For example:
def parrot(voltage, state='a stiff', action=>rand_verb(),
type='Norwegian Blue'):
print("This parrot wouldn't", action)
...
parrot('a million', 'bereft of life')
This behaves as if you wrote:
def parrot():
voltage = 'a million'
state = 'bereft of life'
action = rand_verb()
type = 'Norwegian Blue'
print("This parrot wouldn't", action)
...
***
We can continue to bikeshed the precise syntax, but I think the
semantics of pure left-to-right make very good sense.
Will have to get an implementation together before being sure, though.
> On Tue, 26 Oct 2021, Chris Angelico wrote:
>
> >> Personally, I'd expect to use late-bound defaults almost all or all the
> >> time;
> >> [...]
> >
> > Interesting. In many cases, the choice will be irrelevant, and
> > early-bound is more efficient. There aren't many situations where
> > early-bind semantics are going to be essential, but there will be huge
> > numbers where late-bind semantics will be unnecessary.
>
> Indeed; you could even view those cases as optimizations, and convert
> late-bound immutable constants into early-bound defaults. (This optimization
> would only be completely equivalent if we stick to a global left-to-right
> ordering, though.)
Yeah. And that's another good reason to keep the two default syntaxes
as similar as possible - no big keyword adornment like "deferred" - so
that code isn't unnecessarily ugly for using more early-bound
defaults.
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/2S74ISUMJ3L42EP2GQSKZKNH6UC5GONE/
Code of Conduct: http://python.org/psf/codeofconduct/
