the Gravity of Python 2

[Devin Jeanpierre]

On Mon, Jan 6, 2014 at 6:00 PM, Chris Angelico <rosuav at gmail.com> wrote:
> On Tue, Jan 7, 2014 at 12:55 PM, Devin Jeanpierre
> <jeanpierreda at gmail.com> wrote:
>> What if we decide there is no single source of responsibility, and it
>> can't be limited exactly to a module, and make a __future__ feature
>> the best we can regardless? We can still exact some benefit from a
>> "sloppy" __future__ feature: we can still move code piecemeal.
>
> I worry that it's starting to get into the realm of magic, though.
> Maybe dict.keys() isn't the best example (you can easily make your
> code 2+3 compat by just calling list() on it immediately, which is
> effectively "from __past__ import absence_of_views"), but the issue is
> the same with string autoencodings. It's really hard to define that
> the + operator will do magic differently based on a future directive,
> and changing the object ("this string will not autoencode") means
> you're not tweaking things per-module, and behaviour will change
> and/or break based on where some object was created, rather than the
> settings on the module with the code in it.

Well, what's "magic"? There are two ideas that I know roughly how to
implement, and that maybe would make the world better.

Behaviour that changes or breaks based on what module some object was
created in sounds pretty bad, but I don't think it's so bad that it's
not a tolerable solution. The error messages can be made obvious, and
it would still allow a gradual migration. Allowing the exception to be
toned down to a warning might help with the gradual move without
breaking code unpredictably. It's bad, but if there were no better
alternative, I would be OK with it. (i.e. I think it's better than
nothing.)

The other alternative is having + (etc.) do something different
depending on what module it's in. It's not hard to do: add a condition
to all places where Python automatically converts, and check the call
stack to see what module you're in. I mostly retract my worries about
performance, I for some reason was thinking you'd do it on all
operations, but it only has to be checked if the string is about to be
automatically encoded or decoded, (and that's already slow). It still
has the effect that your API is different and you raise exceptions
when you didn't before, which usually affects your callers more than
it affects you, but I feel like it propagates outside of the module
more "nicely".

It's "magic" in that looking at the call stack is "magic", but that's
the kind of magic that you can even do without touching the
interpreter, using functions from sys. I don't think the definition of
when exactly automatic encoding/decoding occurs is magical. It's
already a part of Python behaviour, changing it isn't outrageous.

-- Devin