On Mon, 30 Jul 2007 15:48:00 +0200, "Diez B. Roggisch" <deets@nospam.web.de> wrote:
>Neil Cerutti wrote:
>
>> On 2007-07-30, André <andre.roberge> wrote:
>>> On Jul 30, 9:39 am, Neil Cerutti <horp...@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?
>

I think you misunderstood the behavior which was being called lame. The
earlier poster was suggesting that only the first Python code to run any
where in a process could perform future imports. This is, of course, not
true. It's only restricted to the first Python code to run in a particular
file.

Jean-Paul