On 15 November 2016 at 02:59, Matthias welp <boekew...@gmail.com> wrote:
> Mikhail, what Paul probably means here is that python 'operators' are actually
> 'syntactic sugar' for functions (it is not recommended to call
> these functions directly, but it is possible):
More specifically, the meaning of the syntax a = a + b does not depend
on the types of the operators - it always means
a = a.__add__(b)
(with some added complexity for __radd__). So you can't make it do
something different "for integers" because at this stage of
interpretation, Python hasn't looked at the types of the objects in
the expression.
Hence my example, which uses lists to show an "obvious" case where a =
a + b and a += b differ. It's harder to show a convincing example when
a has an immutable type like int, because the fundamental difference
between the 2 constructs is how they treat mutable values.
If you're proposing a = a + b to introspect at runtime the type of a,
and produce different bytecode depending on the answer, you're
proposing a fundamental change to the runtime semantics of Python
(such that the resulting language is arguably not even Python any
more). That's not to say it can't be done, just that it's not in scope
for "ideas about new features for Python" in any practical sense.
Paul
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
