On 2021-10-30 20:44, Chris Angelico wrote:
The default of every argument should be a first-class value. That's
how things are now, and I think that's a very useful invariant to have.
If we want to break it we need a lot more justification than "I don't
like typing if x is None".
How important is this? Yes, it's the status quo, but if we evaluate
every proposal by how closely it retains the status quo, nothing would
ever be changed. Let's look at type checking for a moment, and compare
a few similar functions:
<snip>
As I've said before, the problem is that the benefit of this feature is
too small to justify this large change to the status quo.
You use similarly mysterious "expressions" all the time. They can't be
treated as first-class values, but they can be used in the contexts
they are in. This is exactly the same. You've probably even used
expressions that are only evaluated conditionally:
recip = 1 / x if x else 0
Is the "1 / x" a first-class value here? No - and that's why if/else
is a compiler construct rather than a function.
No, but that example illustrates why: the expression there is not a
first-class value, but that's fine because it also has no independent
status. The expression as a whole is evaluated and the expression as a
whole has a value and that is what you work with. You don't get to
somehow stash away just the 1/x part and use it later, but without
evaluating it yet. That is not even close to the situation envisioned
in the proposal under discussion, because in the proposal this
mysterious expression (the argument default), although not a first-class
value, is going to be stored and used independently, yet without
evaluating it and without "reifying" it into a function or other such object
It's obvious that there are tons of things that aren't first-class
values in Python (and in any language). The plus sign isn't a first
class value, the sequence of characters `a = "this".cou` in source code
isn't a first class value. But these usages aren't the same as what's
in the proposal under discussion here. I'm not sure if you actually
disagree with this or if you're just being disingenuous with your examples.
Anyway, I appreciate your engaging with me in this discussion,
especially since I'm just some random guy whose opinion is not of major
importance. :-) But I think we're both kind of just repeating
ourselves at this point. I acknowledge that your proposal is
essentially clear and is aimed at serving a genuine use case, but I
still see it as involving too much of a departure from existing
conventions, too much hairiness in the details, and too little real
benefit, to justify the change.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
_______________________________________________
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/HTEYZGXHMPGAPVPAL6VOOF3EF32PIVCG/
Code of Conduct: http://python.org/psf/codeofconduct/
