[Mikael Olofsson]
> Naturally. More seriously though, I like
>
> from __future__ import something
>
> as an idiom. It gives us a clear reusable syntax to incorporate new
> features before they are included in the standard distribution. It is
> not obvious to me that the proposed alternative
>
> import __something__
>
> is a way to incorporate something new.
Bingo. That's why I'm pushing for it. Also means we only have to create
one artificial module (__future__.py) for this; and besides the doc value,
it occurs to me we *do* have to create a real module anyway so that masses
of tools don't get confused searching for things that look like modules but
don't actually exist.
> Perhaps Py3k should allow
>
> from __past__ import something
>
> to give us a way to keep some functionality from 2.* that has been
> (will be) changed in Py3k.
Actually, I thought that's something PythonWare could implement as an
extension, to seize the market opportunity created by mean old Guido
breaking all the code he can on a whim <wink>. Except they'll probably have
to extend the syntax a bit, to make that
from __past__ import not something
Maybe we should add
from __future__ import __past__with_not
now to make that easier for them.
> explicit-is-better-than-implicit-ly y'rs
otoh-implicit-manages-to-hide-explicit-suckiness-a-bit-longer-ly
y'rs - tim
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4