On Mon, Jan 6, 2014 at 6:00 PM, Chris Angelico <ros...@gmail.com> wrote: > On Tue, Jan 7, 2014 at 12:55 PM, Devin Jeanpierre > <jeanpierr...@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 -- https://mail.python.org/mailman/listinfo/python-list