Detecting __future__ features

[Steven D'Aprano]

How would one tell at runtime if a particular feature has been enabled by
the "from __future__ import thing" statement?

For example, I can do this:

if 1/2 == 0:
print "classic division in use"
else:
print "true division in use"
I could even do this:

from keyword import keyword
if keyword("with"):
print "with statement enabled"
else:
print "with statement not enabled"

(I don't especially care whether the feature in question has been enabled
via an explicit call to import, or because it has become the default.)

Is there any general mechanism?
--
Steven.

[Lawrence Oluyede]

Steven D'Aprano <st***@REMOVE.THIS.cybersource.com.auwrote:

Is there any general mechanism?

I'd just use the expected future feature and if the result is not what I
expect (or Python raises any kind of exception, like using a keyword not
present) I'd think I'm in the past :-)

--
Lawrence, oluyede.org - neropercaso.it
"It is difficult to get a man to understand
something when his salary depends on not
understanding it" - Upton Sinclair

[Neil Cerutti]

On 2007-07-30, Steven D'Aprano
<st***@REMOVE.THIS.cybersource.com.auwrote:

How would one tell at runtime if a particular feature has been
enabled by the "from __future__ import thing" statement?

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.

--
Neil Cerutti
Will the highways on the Internet become more few? --George W. Bush

[=?iso-8859-1?B?QW5kcuk=?=]

On Jul 30, 9:39 am, Neil Cerutti <[e-mail]:

On 2007-07-30, Steven D'Aprano

<[e-mail]:

How would one tell at runtime if a particular feature has been
enabled by the "from __future__ import thing" statement?

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).

André

--
Neil Cerutti
Will the highways on the Internet become more few? --George W. Bush

[Antti Rasinen]

On 2007-07-30, at 15:29, Steven D'Aprano wrote:

How would one tell at runtime if a particular feature has been
enabled by
the "from __future__ import thing" statement?

(I don't especially care whether the feature in question has been
enabled
via an explicit call to import, or because it has become the default.)

Is there any general mechanism?

You probably have to care about imports vs. language defaults. But
it's not very difficult.

For imports you can use __future__ to help you. If your namespace
contains a feature you want to check for and it is identical to the
same feature in __future__, then the code has used from __future__
import feature. You could probably try something like this:

import __feature__
feature = "division"
if globals().get(feature, None) == __future__.__dict__[feature]:
print "Bingo!"

You can probably figure out how to use sys.version_info to check
whether the current Python version is higher than the one specified
in a feature line:

import __future__
import sys
if sys.version_info >= __future__.division.mandatory:
print "Bingo! Two in a row!"

Check the __future__ docstrings for more information.

--
[ ar*@iki.fi <*Antti Rasinen ]

This drone-vessel speaks with the voice and authority of the Ur-Quan.

[Neil Cerutti]

On 2007-07-30, André <an***********@gmail.comwrote:

On Jul 30, 9:39 am, Neil Cerutti <[e-mail]:

>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?

--
Neil Cerutti
8 new choir robes are currently needed, due to the addition of several new
members and to the deterioration of some of the older ones. --Church Bulletin
Blooper

[Carsten Haese]

On Mon, 2007-07-30 at 12:53 +0000, André wrote:

On Jul 30, 9:39 am, Neil Cerutti <[e-mail]:

On 2007-07-30, Steven D'Aprano

<[e-mail]:

How would one tell at runtime if a particular feature has been
enabled by the "from __future__ import thing" statement?

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.

Incorrect. It must be done at the beginning of the *file*.

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.

Incorrect. You can use a __future__ import in a module as long as you do
it at the beginning of the modul file.

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).

No. __future__ directives are scoped to the module. Observe:
$ cat f1.py
def f1():
print 1/2

f1()
import f2
f2.f2()

$ cat f2.py
from __future__ import division

def f2():
print 1/2

$ python f1.py
0
0.5

As you can see, f1 uses past semantics, f2 uses future semantics. Just
use whatever __future__ directives you need for your module at the
beginning of your module, and everything will just work.

HTH,

--
Carsten Haese
http://informixdb.sourceforge.net

[Diez B. Roggisch]

Neil Cerutti wrote:

On 2007-07-30, André <an***********@gmail.comwrote:

>On Jul 30, 9:39 am, Neil Cerutti <[e-mail]:

>>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

[Neil Cerutti]

On 2007-07-30, Diez B. Roggisch <de***@nospam.web.dewrote:

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 was considering the following specific quote:

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."

If that were true, I think it would indeed be lame. Of course, it
isn't true, right?

--
Neil Cerutti

[Carsten Haese]

On Mon, 2007-07-30 at 14:10 +0000, Neil Cerutti wrote:

On 2007-07-30, Diez B. Roggisch <de***@nospam.web.dewrote:

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 was considering the following specific quote:

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."

If that were true, I think it would indeed be lame. Of course, it
isn't true, right?

Correct, the statement you're referring to is not true. See my earlier
reply on this thread for details.

--
Carsten Haese
http://informixdb.sourceforge.net

[=?iso-8859-1?B?QW5kcuk=?=]

On Jul 30, 11:10 am, Neil Cerutti <[e-mail]:

On 2007-07-30, Diez B. Roggisch <[e-mail]:

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 was considering the following specific quote:

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."

If that were true, I think it would indeed be lame. Of course, it
isn't true, right?

Yes, it was my mistake; I replied too quicly from a faulty memory
bank...

(extract foot from mouth ... inhale deeply to resupply oxygen to the
brain ...)
André

--
Neil Cerutti

[Steve Holden]

Lawrence Oluyede wrote:

Steven D'Aprano <st***@REMOVE.THIS.cybersource.com.auwrote:

>Is there any general mechanism?

I'd just use the expected future feature and if the result is not what I
expect (or Python raises any kind of exception, like using a keyword not
present) I'd think I'm in the past :-)

Of course if the use of the feature creates a syntax error in the
__main__ module (as it might currently for a use of the "with" keyword
in 2.5, for example) then there is no way to catch the exception and you
are therefore SOL, no?

sholden@bigboy ~/Projects/Python
$ cat test11.py
with open("myfile.txt") as f:
print l for l in f
sholden@bigboy ~/Projects/Python
$ python test11.py
test11.py:1: Warning: 'with' will become a reserved keyword in Python 2.6
File "test11.py", line 1
with open("myfile.txt") as f:
^
SyntaxError: invalid syntax
regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
--------------- Asciimercial ------------------
Get on the web: Blog, lens and tag the Internet
Many services currently offer free registration
----------- Thank You for Reading -------------