On Sat, Oct 23, 2021 at 08:29:54PM -0700, Brendan Barnwell wrote:
> For me the biggest problem with this idea is that it only handles a
> subset of cases, namely those that can be expressed as an expression
> inlined into the function definition.
True. But that's equally true for default values under early binding.
Would you say that existing syntax for default values is problematic
because it only covers the 90% of cases where the default value can be
computed from an expression?
If push comes to shove, we can always write a helper function.
> This subset is too small, because
> we'll still have to write code in the function body for cases where the
> default depends on more complex logic. But it is also too large,
> because it will encourage people to cram complex expressions into the
> function definition.
Just like they do now?
I think people can write bad code regardless of the features available,
but I don't think that adding late binding will particularly make that
tendency worse. Most uses of late binding will be pretty simple:
- mutable literals like [] and {};
- length of another argument (like the bisect example);
- references to an attribute of self;
- call out to another function.
I don't think that there is good reason to believe that adding late
binding will cause a large increase in the amount of overly complex
default values.
As you say, they are limited to a single expression, so the really
complex blocks will have to stay inside the body of the function where
they belong. And we have thirty years of default values, and no sign
that people abuse them by writing lots of horrific defaults:
def func(arg=sum(min(seq) for seq in [[LOOKUP[key]]+list(elements)
for key, elements in zip(map(Mapper(spam, eggs), keys),
iterable_of_sets) if condition(key)] if len(seq) > 5)):
...
People just don't do that sort of thing in anywhere near enough numbers
to worry about them doing it just because we have late binding.
And if they do?
"People will write crappy code" is a social problem, not a technology
problem, which is best solved socially, using code reviews, linters, a
quick application of the Clue Bat to the offending coder's head, etc.
> I would prefer to see this situation handled as part of a
> larger-scale
> change of adding some kind of "inline lambda" which executes directly in
> the calling scope.
That would be what I called a "thunk" in two posts now, stealing the
term from Algol.
It would be nice if one of the core devs who understand the deep
internals of the interpreter could comment on whether that sort of
delayed evaluation of an expression is even plausible for Python.
If it is, then I agree: we should focus on a general thunk mechanism,
which would then give us late binding defaults for free, plus many more
interesting use-cases.
(Somewhere in my hard drive I have a draft proto-PEP regarding this.)
But if it is not plausible, then a more limited mechanism for late bound
defaults will, I think, be a useful feature that improves the experience
of writing functions.
We already document functions like this:
def bisect(a, x, lo=0, hi=len(a))
It would be an improvement if we could write them like that too.
--
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/REVRTYICAKVOZRV2X5PPOY2U5XUY5RQG/
Code of Conduct: http://python.org/psf/codeofconduct/
