On 2021-12-08 15:17, Chris Angelico wrote:
>At a minimum, the PEP should state the objections fairly, and note
>that the PEP author disagrees. A PEP isn't a sales pitch, it's a
>summary of the discussions - so it absolutely should mention that
>there's been significant opposition to the proposal, which did not get
>resolved, if that's the reality.
Yes, and "significant opposition" doesn't just mean "I don't like
this". There's nothing to respond to in that.
Well, in a way it does. In another message on this thread you wrote:
I have attempted to explain the syntax. What is confusing?
def f(x=spam): ...
def f(x=>spam): ...
I'm not sure what concerns need to be addressed, because I don't
understand the concerns.
Speaking for myself, I would agree that there is nothing for you to
"address" per se. The problem, though, is that if half the people in
the discussion think it is confusing, then that in itself constitutes a
case that it is confusing and maybe we shouldn't add it. It's possible
this is why this discussion is kind of going in circles, because a lot
of it does come down to a somewhat subjective judgment about what is
"too confusing". But that doesn't mean that the subjective disagreement
about the relative costs and benefits doesn't exist, or that there is
some external source of truth about whether it "really is" confusing.
Your example there is very simple. But for me a lot of it comes down
to this:
def f(a=[], b@={}, c=some_function(a, b), d@=other_function(a, b, c)):
The PEP envisions a world in which you can have a list of arguments
like that, alternating back and forth between early and late binding,
and they can refer to each other in arbitrary ways, and the semantics
will differ from one argument to another (in that, e.g., for c the
arguments a and b will be evaluated in the enclosing scope, whereas for
d they are evaluated in the function scope). And yet none of the
late-bound defaults will exist as objects or be accessible or creatable
in any way apart from in function signatures, so all of this complexity,
insofar as it exists, is necessarily going to be crammed entirely into
function signatures, and also provide no benefit anywhere else.
Now certainly it is possible to write confusing code now, and on some
level any language that allows arbitrary nesting of expressions allows
arbitrarily confusing code. But from my perspective, the point is that
introducing this entire new "way" for things to be confusing just isn't
worth it for the benefit this PEP provides. Of course we can say "well
people could write confusing code like that but they
won't/shouldn't/etc.". But to my mind there is no reason to even give
them the chance. There would need to be a lot more than just "I don't
have to do an if-None check" to justify this new "surface area" of
complexity.
I agree with you that it is unclear how you would "address" this
objection, but that doesn't mean it's not a valid objection. To me it
is sort of an "irreducible" objection, in the sense that I don't
currently see how it could possibly be addressed and therefore I am
against the PEP outright. Maybe someone could come up with some
alternative mechanism for late-bound defaults that I would think was
fine, but as of now it's hard for me to envision what that could
possibly be. From where I stand it is like someone told me they were
going to put a horse into a suitcase; unless it turns out the suitcase
has a false bottom, or someone comes up with a kind of horse or suitcase
I've never seen before, it just fundamentally will not fit.
To touch on the "deferred" issue, I will also say it's quite possible
that someone might come up with a proposal for deferred evaluation and I
would still oppose it because I thought it was too confusing. That's
really neither here nor there. It's not that I oppose this PEP because
I think we can get some great deferred-eval PEP instead; it's just that
the benefit this PEP provides is too small to justify the complexity.
Now, I can add to that that in theory (in theory!) one reason I might
look differently on a deferred-eval proposal is that such a proposal
could provide benefits OUTSIDE of function signatures. Because your
proposal focuses only on function signatures, it can provide no benefit
outside of function signatures, and (in my view) there simply isn't
enough potential benefit available within function signatures to
outweigh the possibility of confusion that I outlined above. The
cost-benefit account of function signatures is overdrawn.
--
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/RW26EHL36LEOVWE32GTNK4GGD7F5HI4R/
Code of Conduct: http://python.org/psf/codeofconduct/
