On Thu, 9 Dec 2021 at 11:51, Chris Angelico <ros...@gmail.com> wrote:
>
> Are = and := confusing? They are also very similar, and they have some
> subtle distinctions. Is it a problem for two different operators to
> look similar when they do very similar things?
Maybe. I don't use assignment expressions - I don't really have any
good uses for them. And no project I maintain is able to use them yet
as we support older Python versions. So I'm honestly not sure. I'd be
more concerned about confusing := and ==, as both can appear in the
same expression. But again I don't know.
And I don't know *for certain* about =>. It's a concern, not a
showstopper. No-one has yet (as far as I can recall) shown real-life
cases, such as a PR against an existing project that changes code to
use the new syntax. There's no requirement on a PEP to do that much
work up front, so I'm not demanding that you do. But I'll remain
concerned about confusability until I see some "real world" evidence
like that. And like with assignment expressions, the PEP might still
get accepted even though I'm concerned.
> Argument defaults look like assignment because it makes sense for them
> to look like assignment. That's not an accident.
I didn't say it was. But there comes a point when too many things all
look like X because they are similar to X, and we run out of easily
distinguishable variations. Are we at that point yet? I don't know.
Might we be? In my opinion, yes we might. And the PEP should document
*your* view on the question, which can be "I think it's fine, but
everyone disagrees with me", or "the majority of people on the list
think it's OK", or "there were concerns expressed but they were all
theoretical and I believe the benefits of this proposal outweigh the
theoretical risk". Or whatever. It's your PEP, not mine. Your view is
what should be in there.
> If this is accepted, it will become a standard idiom to see "=>[]" or
> "=>{}" or whatever, and seeing "=[]" will continue to look wrong. I
> think you're underestimating people's ability to understand code.
I think you're (at a minimum) overestimating *my* ability to spot
mistakes like this. I'm certain that I've missed similar things in
reviews in the past. Maybe I'm not typical. Maybe you're thinking more
of people writing their own code, and less about maintainers reviewing
externally submitted code. Or maybe projects will define standards and
good practices that prohibit over-use of late-bound defaults, or
prefer None sentinels where possible, or just impose a general "keep
it simple" rule and use that to minimise the risk of confusion.
And maybe people will end up cargo culting "you use => for mutable
values like [] or {}, and = for everything else" and not actually
understanding when values get bound at all. And people do the right
thing by accident, so everything is fine (sort of).
> But maybe we ARE using the term "confusing" in different ways. Maybe
> I'm trying to respond to completely the wrong thing. If the concern is
> that the new syntax is "confusing" but I'm interpreting that word
> wrongly, please clarify.
I think your responses above are addressing what I mean by
"confusing". But your responses are essentially that you don't agree
with me. That's fine, and I'm not demanding that we have to agree
here. But to be a fair reflection of the discussion, the PEP should
note this concern and be clear that there was disagreement with your
position. That is literally all I am asking here.
If the PEP ends up containing a section with a list of concerns people
have, and your statement that you don't agree with them, that's 100%
fine. Maybe it makes the PEP less persuasive. I don't have a problem
with that - after all, I'm the one arguing that the status quo is
fine. You're the one arguing that the change is worth making, so
presumably you believe the section in the PEP that describes the
benefits of this change outweighs this.
> > > I'm not sure what concerns need to be addressed, because I don't
> > > understand the concerns.
> >
> > Fair, but you can state them, surely? Even if you're just copying what
> > people say into the PEP, and noting that these are open issues that
> > the PEP author cannot address without further explanation of the
> > issue, that's better than having nothing (and having the same
> > objections raised over and over again). At the moment the PEP doesn't
> > even *have* an "open issues" section.
>
> No, I can't, because every time I try to pin down actual issues, they
> slip away. I can't nail jelly to the PEP.
Rob Cliffe did an excellent summary. Just copy and paste that. If you
really don't understand any of the points in spite of his summary and
everyone's comments, just note in the PEP that this was the objection
and it's not been addressed because you didn't understand what the
problem was. And move on.
> > > EVERYONE is arguing against the proposal.
> >
> > So your response to my concern that opinion is divided on the PEP, is
> > to say that actually, no-one likes it? I get that you're frustrated,
> > but that doesn't seem useful.
>
> The problem is that even people who claim to be in support of it are
> arguing against it. That's what makes it incredibly hard to figure out
> what concerns are still open.
OK. I don't claim to be in support of the PEP, but I'm only mildly
against it (I prefer the status quo). I'll be satisfied if Rob's list
of people's concerns is noted in the PEP. You can say these haven't
been addressed because you couldn't get a clear understanding of what
the precise issue was. I'm fine with that. Or you can say that the
concern is noted, but you don't plan on changing the PEP because you
don't believe the issue is significant enough. Or whatever, as long as
the issue is noted and there's a response. Do that and I'll have
nothing further to say. I'll still prefer the status quo, but you
don't have to persuade me, you just have to persuade the SC, and as
long as the points I've made are noted for the SC's consideration,
that's all I ask.
> Exactly. And this particular issue is fixing an issue that people
> point to as a gotcha - "be careful of mutable default arguments" or
> even "mutable values don't work in argument defaults" (which I see all
> too often). With a good response of "they behave that way if you write
> =>[] instead of =[]", it still looks and feels like an argument
> default, but it has the slightly different behaviour that people
> expect, and all is well.
And people don't all agree. So what? Present your case, represent the
objections fairly, and that's good enough.
As someone said (Jonathan Goble, I think) if we were designing Python
now, we'd quite likely have picked late bound defaults as the only
behaviour. Early binding has some unfortunate warts. But we didn't,
and we're not talking about changing that decision. So the question is
whether the existing warts are better or worse than any warts a new
solution would have (multiple types of binding behaviour, confusable
syntax, etc - you know the drill, you've heard it way too many times
now).
You think the fix is better than the status quo. Some people here
don't (you yourself said "everyone", I think you were being
pessimistic, but I think "at least half" is probably fair). Pass the
facts to the SC and let them decide. Or drop the idea, if you feel
it's not going to succeed.
Paul
_______________________________________________
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/2AUP5JJKY4G6LNCIUWKXW2BJ7ZNQAR23/
Code of Conduct: http://python.org/psf/codeofconduct/
