> On 30 Jun 2017, at 03:14, Soni L. <fakedme...@gmail.com> wrote:
>
> This isn't a *major* backwards incompatibility. Unlike with unicode/strings,
> a dumb static analysis program can trivially replace + with the concatenation
> operator, whatever that may be. Technically, nothing forces us to remove +
> from strings and such and the itertools stuff - we could just make them
> deprecated in python 4, and remove them in python 5.
No it can’t, not unless you’re defining concatenation as identical to numeric
addition (which I saw in your original post you are not).
For example:
def mymethod(a, b):
return a + b
What should the static analysis program do here? Naturally, it’s unclear. The
only way to be even remotely sure in the current Python world where type
hinting is optional and gradual is to do what PyPy does, which is to run the
entire program and JIT it, and even then PyPy puts in guards to confirm that it
doesn’t get caught out if and when an assumption is wrong.
So yes, I’d say this is at least as bad as the unicode/bytes divide in terms of
static analysis: unless you make type hinting mandatory for any function
including the symbol “+”, there is no automatic transformation that can be made
here.
Cory_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
