Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <CAPTjJmoWOpEtAnDEWfyZamsCkHG4gDbJ3_KreMfTiyDo9UpECA@mail.gmail.com>
References: <laf00q$10k$1@ger.gmane.org> <CAPTjJmqzc2AQJ6TrBtCFnT+NBp8uYWMxMhtGNpLr+NGyhoxO-g@mail.gmail.com> <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> <CAPTjJmoWOpEtAnDEWfyZamsCkHG4gDbJ3_KreMfTiyDo9UpECA@mail.gmail.com>
From: Devin Jeanpierre <jeanpierreda@gmail.com>
Date: Mon, 6 Jan 2014 19:12:05 -0800
Subject: Re: the Gravity of Python 2
To: Chris Angelico <rosuav@gmail.com>
Content-Type: text/plain; charset=UTF-8
Cc: "python-list@python.org" <python-list@python.org>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.5116.1389064367.18130.python-list@python.org>
Lines: 37
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:63407

On Mon, Jan 6, 2014 at 6:28 PM, Chris Angelico <rosuav@gmail.com> wrote:
> 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 +?

In both methods I described, all uses of instances of the class are
changed, but only in case A. That's a really good point, I hadn't
considered that the second case could be converted into the first.

> This is why I think it's getting magical.

Yes, it's magical, but to be fair that's stack inspection as it always is.

I am OK with a little ugliness if it makes actual work easier.

> 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.

Doing a flag like that that enables a backwards incompatible change
does in fact address that issue you were worried about originally, so
that's something. And feature-by-feature moves are, like the OP said,
still lower cost than a wholesale move.

In the end a gradual transition can still be done with the polyglot
approach, but I'm not happy that there's no way to enforce/test a
polyglot conversion until it is complete. Any kind of granularity
would have helped. :(

-- Devin