Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #63395 > unrolled thread
| Started by | Chris Angelico <rosuav@gmail.com> |
|---|---|
| First post | 2014-01-07 13:00 +1100 |
| Last post | 2014-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.
Re: the Gravity of Python 2 Chris Angelico <rosuav@gmail.com> - 2014-01-07 13:00 +1100
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-01-07 13:00 +1100 |
| Subject | Re: 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
Back to top | Article view | comp.lang.python
csiph-web