On Wed, May 6, 2020 at 3:25 AM Steven D'Aprano <st...@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
_______________________________________________
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/FOCSHKCYPEQPVBY2WIE4MHW7QNM5JFEZ/
Code of Conduct: http://python.org/psf/codeofconduct/
