Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #63395 > unrolled thread

Re: the Gravity of Python 2

Started byChris Angelico <rosuav@gmail.com>
First post2014-01-07 13:00 +1100
Last post2014-01-07 13:00 +1100
Articles 1 — 1 participant

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: the Gravity of Python 2 Chris Angelico <rosuav@gmail.com> - 2014-01-07 13:00 +1100

#63395 — Re: the Gravity of Python 2

FromChris Angelico <rosuav@gmail.com>
Date2014-01-07 13:00 +1100
SubjectRe: the Gravity of Python 2
Message-ID<mailman.5106.1389060068.18130.python-list@python.org>
On Tue, Jan 7, 2014 at 12:55 PM, Devin Jeanpierre
<jeanpierreda@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.

ChrisA

[toc] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web