Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #63402
| References | (2 earlier) <CABicbJ+k9Yim879QaDtty_dNvpZMgKA8W-zX6Xcsc5BQcnaCaQ@mail.gmail.com> <CAPTjJmozt8XcWrW2xAX7oeHDQHcDDWkoY7kMK0YXdYU+z+cOfQ@mail.gmail.com> <CABicbJ+YMRLHqQQ3nFLeqqxnvqRLRioZc9X3pZUMfZWzgEbMSw@mail.gmail.com> <CAPTjJmojtgi=fjMrZ2dW-dXpoAMWrwww-yp4BTvUtL8iNdAbBQ@mail.gmail.com> <CABicbJ+dG4Adgeb0RKydXWJrwYNC=HHdsWhd+X=YZ37jm+1t8w@mail.gmail.com> |
|---|---|
| Date | 2014-01-07 13:28 +1100 |
| Subject | Re: the Gravity of Python 2 |
| From | Chris Angelico <rosuav@gmail.com> |
| Newsgroups | comp.lang.python |
| Message-ID | <mailman.5111.1389061729.18130.python-list@python.org> (permalink) |
On Tue, Jan 7, 2014 at 1:15 PM, Devin Jeanpierre <jeanpierreda@gmail.com> wrote:
> 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.
Currently, there are __add__ methods (and __radd__ but let's focus on
__add__) on a bunch of objects, which determine what happens when you
use the + operator.
class Foo(str):
def __add__(self, other):
if isinstance(other, unicode): return self + other.encode("cp500")
return str.__add__(self, other)
What happens if you have the __future__ directive disabling
autoencoding on (a) the module in which this class is defined, (b) the
one in which the it was instantiated, (c) the one that actually uses
the +?
This is why I think it's getting magical. Far better to do this sort
of change on a per-application basis - maybe with a warning parameter
that you can enable when running your test suite, as has been
suggested (and in many cases implemented) for other 2-vs-3 problems.
ChrisA
Back to comp.lang.python | Previous | Next | Find similar | Unroll thread
Re: the Gravity of Python 2 Chris Angelico <rosuav@gmail.com> - 2014-01-07 13:28 +1100
csiph-web