Neil Cerutti wrote: > On 2007-07-30, André <[EMAIL PROTECTED]> wrote: >> On Jul 30, 9:39 am, Neil Cerutti <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list