You mean an IDE should display foo=foo as foo= even though that’s not valid Python right now? Strong disagree. Editors should display the code as written, not invent new display-only pseudo-languages that make it hard to edit text.
5 Likes
If you think this is a simple decision to make, you clearly haven’t maintained a project that has chosen to use black.
- It’s quite likely the choice to use black wasn’t yours - at best, you may have been persuaded to agree “because not having endless debates like the one about whether to use black is the point”.
- There isn’t realistically any other choice than black for an auto-formatter. Ruff is a possibility now, but AFAIK it basically implements the same rules as black[1]. Other formatters are pretty niche.
And I reiterate - the change from foo=foo to foo= is not simply a reformatting. It changes the sematics in a way that affects the AST, and changes how coupled the names of local variables and function parameters are. I think the proposed change to black is misguided, and at the very least should be controlled by an option so that users can choose whether to allow it independently of the formatting changes black makes.
Yes, this comment is all about black, and unrelated to the PEP. But it does affect how people think about the PEP, and frankly I think that black’s plans hurt the chance of getting community consensus in favour of the PEP. So we’re all being affected one way or another by the disproportionate impact that black’s choices have on the Python ecosystem. I find that ironic, for a tool that’s intended to reduce the amount of time spent on discussions about syntax…
Although my hope is that ruff will either not implement this rule, or make it optional, so there will be a meaningful choice available ↩︎
15 Likes
I agree, and this is one reason that I will not use black. I see this as a significant semantic decision, not purely a display matter. Therefore, if black makes what I consider a “wrong” decision (and by that I really mean “makes a decision different from what I would have made”), it is correct for me to not use it.
You can NEVER eliminate these discussions, only move them. It’s no different from any other kind of centralization. Do you prefer 110V power or 220V? Tough, that decision’s been made at a higher level. But that means that the people MAKING those decisions are making them for vast numbers of people, and will therefore have more to discuss.
3 Likes
I think this is an ok analogy, but it doesn’t show what you’re trying to show.
Imagine that right now Python only supports spaces as indentation.
Then someone introduces a PEP to allow for tabs also.
Then Black comes and says they will enforce using tabs, after this PEP is accepted.
I think there would be a lot of push-back against that PEP.
Do people moan that Python permits tabs AND spaces as indentation
Yes, I think some people do.
we welcome the flexibility
No, WE don’t welcome the flexibility. Maybe YOU welcome the flexibility.
…except this analogy is weaker than that, because the indentation wouldn’t change the AST, which means there’s more reason to push-back against this PEP than there is against that hypothetical PEP in the analogy.
11 Likes
Okay. Well, then the analogy doesn’t work for you, because you actually would prefer less flexibility. Find some other equivalent where people (particularly YOU) want the flexibility.
Note that some Java IDEs routinely do display the code differently than it’s actually written. But, yes, I agree it’s slightly annoying.
I’m aware of IDEs adding text (e.g. to show parameter names, which I can understand being helpful for some people, though I personally turn it off as the user experience is jarring), but removing text as suggested here? Is there any precedent for that? Aside from hiding entire lines in e.g. method bodies with a disclosure arrow to show it again?
There are vim plugins that replace >= with ≥, and lambda with λ. This is (I guess) similar. Personally, I find thos plugins terrible to work with, but some people like them…
2 Likes
I can imagine replacing text like that — the replacement is very unlikely to occur in real code so you’d know what was happening — but it’s still not quite at the level of just deleting code. How would you even know it was elided, and not just that you’d forgotten to finish writing the line of code? Would it vanish as soon as you typed it?
Completely off-topic, but that feature is great for markup IMO (makes latex nicer to work with). But I wouldn’t want to use such features with “regular” languages.
As was one of my points in the post above, this critique applies just as well to the proposed feature.
And please do note that the exact text your replying to is this:
this really seems like a feature that would be better implemented at the visual presentation layer of code
I did not really suggest an exact solution, rather that the problem can be solved at the presentation layer. How it would be solved is off topic, but would of course be a matter of designing something appropriate, user friendly and readable.
Hardly. With the new feature, if I see foo=, I know what the code will do when I run it. If a UI elides the final foo of foo=foo, I do not know what the code will do when I see it. They are completely different scenarios.
However, it seems as if this has been relegated to “I don’t know how it would work, the UI will solve this hard problem for us”, so I don’t see any value in continuing to discuss. Agreed that perhaps this is a thing a UI might manage to accomplish, but I have never yet seen a good instance of it; nor are IDEs the only or most important place code is viewed (e.g. diffs in git, PRs in github)
But both are subject to ambiguity when posing the question “[…] not just that you’d forgotten to finish writing the line of code?”.
That is true of a lot of code. Did I finish writing this function or just forget the last line? Did I finish adding all the arguments, or just get half way through? Did I add all the things I meant to add, or did I miss the last one? However, it’s not normally an ambiguity added in by the IDE. It also doesn’t wag the dog of language design.
2 Likes
I’ve had different problems with black, and occasionally had to disable it.
When at work we change the base distribution, and we get a new python and a new black, the new black is very likely to change things all over the place that the old black was fine with.
This makes it impossible to backport patches to the older releases, because they won’t apply.
1 Like
@moderators: suggesting to either a) split out the subthread about Black into a separate topic, or b) close this thread (AFAICS, there is no new information, only repetition of arguments and opinions)
8 Likes
Hi Joshua
The Steering Council recently discussed PEP 736 - Shorthand syntax for keyword arguments at invocation.
The SC understands the desire for a simple way to handle redundant keyword passing and how this can simplify some use cases. This PEP proposes to solve this problem with shorthand syntax, and we’re very impressed with the well-researched proposal. Although we considered that this feature could make some users’ lives easier and improve productivity, we have decided to reject the PEP.
The SC identified the following concerns:
First, the SC believes that the cost versus benefit of the new syntax does not have a high enough payoff to justify the added complexities and maintenance required from the wider Python ecosystem to support the new syntax and grammar changes. We favor readability over writability, as we know that code is typically read far more frequently than it is written. There is arguably an added cognitive lookup to “fill in the blanks” and ensure that the missing variable after the equal sign is indeed the intended behavior or a mistaken omission. Generally, modern IDEs have given us excellent tools for auto-completion and the overhead of typing (or tab-completing) a variable name seems to win out in cognitive efficiency. This would be an incredibly interesting study to prove which is actually true.
Second, we have some concerns about complicating the grammar around function arguments, since this is a particularly complex part of the language that already involves plenty of different features and is saturated with grammar paths that involve several tokens with complex ordering requirements. We also have concerns about the maintainable aspect of adding new complexity to the grammar in this particular area. This different point focuses more on the maintainability of the code and any future bug fixes and performance improvements rather than the user-visible aspects. We believe the proposal doesn’t meet the bar given these combined costs in complexity.
Third, even though it seems similar to the f-string debugging specifier, the use case is different enough that we don’t believe it can be used to draw parallels between the two and we also feel it can confuse some users.
Lastly, considering the above reasons, the SC is not convinced that this feature is the best that Python can provide. While we recognize that solutions like this can improve some use cases, they need to be properly balanced with everything else. As we have mentioned in previous occasions grammar changes are subjected to higher scrutiny levels given how far they reach.
Again, thank you for your efforts.
26 Likes