Detecting __future__ features

[Diez B. Roggisch]

Neil Cerutti wrote:

> On 2007-07-30, André <andre.roberge at gmail.com> wrote:
>> On Jul 30, 9:39 am, Neil Cerutti <horp... at yahoo.com> wrote:
>>> I don't understand the qualification, "at runtime," you're
>>> making. What's wrong with just importing what you want and
>>> using it? If it's already been enabled, no harm will come from
>>> the import statement.
>>>
>>
>> I'm not the OP, so perhaps I am missing his intent. However, I
>> can see a good reason for asking this question.
>>
>> I seem to recall that the "from __future__ import" statement
>> can only be done at the beginning of a script.  What if you are
>> designing a module meant to be imported, and used by other
>> programs over which you have no control?   You can't use "from
>> __future__ import" in your module.  So, you may have to find a
>> way to figure out what's been done.  (the example given with
>> the division operator is a good one).
> 
> Is "from __future__ import" really that lame?

Well, if you consider it lame, how about you being a 7331 haX0r who tells us
how python is going to handle this then:

def foo():
    yield 1

if random_condition():
   from __future__ import generators

def bar():
    yield 2

The point is that from __future__ can massively alter the behavior of the
parser - accepting keywords that otherwise won't be keywords, as in this
example, and many more.

Making the switch between different parser-implementations on the fly isn't
technically impossible - but really, really, really complicated. But then,
if it's lameness sucks so much, you might wanna take a stab at it?

Diez