On Wed, May 6, 2020 at 3:25 AM Steven D'Aprano <steve@pearwood.info> wrote:
Personally, I don't think Chris' backwards-compatibility argument is strong. Technically adding a new keyword argument to a function is backwards-incompatible, but we normally exclude that sort of change. Who writes this?
# This behaviour will be changed by the proposed new parameter. zip('', strict=1) # Raise a type error.
So I think the *backwards incompatibility* argument is weak in that regard. But maybe Chris has got a different perspective on this that I haven't thought of.
Adding the flag isn't a problem, but merely adding the flag is useless. (Ditto if a new function is created.) The assumption is that the flag will be used, changing existing code from zip(x, y) to zip_strict(x, y) or zip(x, y, strict=True). Either way, it's not the creation of zip_strict or the addition of the kwonly arg that breaks backward compat, but the change to (say) the ast module, making use of this, that will cause problems.
[Chris]
Should they? I'm not sure how well-supported this actually is. If you hand-craft an AST and then compile it, is it supposed to catch every possible malformation?
I would expect that the ast library should accept anything which could come from legal Python, and nothing that doesn't.
It absolutely should accept anything which could come from legal Python. The question is, to what extent should it attempt to flag invalid forms? For example, if you mess up the lineno fields, attempting to compile that to a code object won't give you a nice exception. It'll most likely just work, and give weird results in tracebacks - but there is no legal code that could have produced that. And what code could produce this?
from ast import * eval(compile(fix_missing_locations(Expression(body=Set(elts=[]))), "-", "eval")) set()
There is no valid code that can create a Set node with an empty element list, yet it's perfectly sensible, and when executed, it produces... an empty set. Exactly like you'd expect. Should it be an error just because there's no Python code that can create it? I'm of the opinion that it's okay for it to accept things that technically can't result from any parse, just as long as there's a reasonable interpretation of them. Which means that both raising and compiling silently are valid results here; it's just a question of whether you consider "ignore the spares" to be a reasonable interpretation of an odd AST, or if you consider "mismatched lengths" to be a fundamental error. ChrisA