On Tue, Jan 7, 2014 at 2:12 PM, Devin Jeanpierre <jeanpierr...@gmail.com> wrote: > 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. :(
Yeah, feature-by-feature is possible; but it doesn't help with one of the big (and common) complaints, that a library can't migrate without the application migrating. The way I see it, polyglot coding should be considered a superset of 2.7 coding, at which point there should hopefully be some perceived value in boasting "Requires 2.7 *OR 3.3*!", and ideally that value should be greater than the cost of supporting both. There are two ways to achieve that: Increase the perceived value, and decrease the cost. Making 3.3 (or 3.4, or whatever) look better is simply a matter of there being more applications (or potential applications) written for that, and that's going to be largely circular, and it's completely not in the hands of Python development, so the focus has to be on decreasing the cost. Hence the question: What are the breakages between 2.7 and 3.3, and which ones can be solved per-module? If the solution to the breakage has to be done per-application, that's a problem, even if it is feature-by-feature. But stuff that can be changed per-module can entirely eliminate the cost of polyglot code (for that feature), as it'll simply be written in the Py3 way, with one little future directive at the top. ChrisA -- https://mail.python.org/mailman/listinfo/python-list