On Wed, Nov 8, 2017 at 8:16 AM, Ian Kelly <ian.g.ke...@gmail.com> wrote: > All of these are things that a linter should probably catch and warn > about. If you had said that the break syntax suggestion was a good > idea but probably better suited as a linter warning than as a > SyntaxError integrated into the parser, then I would likely agree with > you. That's not what you said, though. You said the suggestion was > "ridiculous".
Someone did mention linters at one point, and if I didn't explicitly agree, I certainly didn't disagree. Let me make my position clearer: The suggestion that these should be hard errors in the parser is ridiculous because it is not the parser's job to catch all bugs. Python is not intended to be that sort of language. It is the job of a linter to detect probable errors. >> Not one of these is syntactically invalid. Why should "else without >> break" be trapped by the parser? Your other examples mostly have good >> parser-level reasons for being errors > > No, they don't. All four of them could just as easily also be accepted > by the parser and only flagged as linter warnings. If everyone in the world agreed that a tab was equal to eight spaces, then I would agree that the tab/space discrepancy could be considered a linter warning. But there's no such agreement, which means that having the language declare some equivalency is extremely dangerous. Py2 had several language features and misfeatures that are that dangerous (having the simple name "input()" do evaluation is a trap that MANY people have fallen into), and it's correct to fix that. If Python had, from the start, treated tabs and spaces as different forms of indentation, there would be no reason to change that now. Whether True and False are keywords or builtins is a matter of debate, but there are definite advantages to them being locked down, and the only real disadvantage that I see is the question of consistency (eg "Ellipsis" is not a keyword, so you can still assign to that). Having star imports be bypassed when looking for nonlocals is going to be extremely confusing if you DO import a name from the other module. There's no right answer to the nonlocal lookup question, so the best thing to do is to not permit it. There's fundamentally no way for this to be both legal and sane in all situations, so it can't be left up to the linter. Mixing 'async def' and 'yield from' is, AIUI, more of a NotImplementedError than a SyntaxError; the wording of the PEP basically says that it's low priority, not that it's a bad thing. So that one is never going to be flagged by a linter - once it's made possible, it'll be the normal and expected behaviour, so there's no reason to flag it (except perhaps as "beware that this is not backward compatible with Python <3.8"). So, no, this is not the same. ChrisA -- https://mail.python.org/mailman/listinfo/python-list