473,372 Members | 1,277 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,372 software developers and data experts.

Detecting __future__ features

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.

Jul 30 '07 #1
11 1167
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
Jul 30 '07 #2
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
Jul 30 '07 #3
On Jul 30, 9:39 am, Neil Cerutti <horp...@yahoo.comwrote:
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.
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

Jul 30 '07 #4

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.

Jul 30 '07 #5
On 2007-07-30, André <an***********@gmail.comwrote:
On Jul 30, 9:39 am, Neil Cerutti <horp...@yahoo.comwrote:
>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
Jul 30 '07 #6
On Mon, 2007-07-30 at 12:53 +0000, André wrote:
On Jul 30, 9:39 am, Neil Cerutti <horp...@yahoo.comwrote:
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.

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
Jul 30 '07 #7
Neil Cerutti wrote:
On 2007-07-30, André <an***********@gmail.comwrote:
>On Jul 30, 9:39 am, Neil Cerutti <horp...@yahoo.comwrote:
>>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

Jul 30 '07 #8
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
Jul 30 '07 #9
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
Jul 30 '07 #10
On Jul 30, 11:10 am, Neil Cerutti <horp...@yahoo.comwrote:
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?
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

Jul 30 '07 #11
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 +1 571 484 6266 +1 800 494 3119
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 -------------

Jul 30 '07 #12

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

3
by: Logan | last post by:
Is there a list with all 'from __future__ import ...' statements (which lists all the statements, in which version of Python the feature was introduced and in which version of Python it will become...
10
by: Frances Del Rio | last post by:
pls, why is this not working? <SCRIPT language=JavaScript type="text/javascript"> var br = '<SCRIPT language=Javascript' br += 'src="js_pop.js" type="text/javascript">' br += '</SCRIPT>' var...
13
by: ima | last post by:
I've been studying a great book on css and now that I've put together a few pages using it, I'm finding out that my book needed one more very important chapter. Introducing css in the real world. ...
3
by: mdsteele | last post by:
My understanding of the __future__ statement is that you may say something like: from __future__ import foo, bar to enable more than one feature. However, this does not seem to be working...
2
by: mithrond | last post by:
i can't use "from __future__ import ..." statement import two statesments in the same time. for the simple code: from __future__ import with_statement, division with file('url.txt','r') as f:...
7
by: Ron Adam | last post by:
from __future__ import absolute_import Is there a way to check if this is working? I get the same results with or without it. Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) on win 32 ...
1
by: Malcolm Greene | last post by:
Is there any consensus on what "from __future__ import" options developers should be using in their Python 2.5.2 applications? Is there a consolidated list of "from __future__ import" options to...
0
by: Tim Golden | last post by:
Malcolm Greene wrote: Well, that bit's easy: import __future__ print __future__.all_feature_names TJG
15
by: RobG | last post by:
When using createEvent, an eventType parameter must be provided as an argument. This can be one of those specified in DOM 2 or 3 Events, or it might be a proprietary eventType. My problem is...
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
by: ryjfgjl | last post by:
In our work, we often need to import Excel data into databases (such as MySQL, SQL Server, Oracle) for data analysis and processing. Usually, we use database tools like Navicat or the Excel import...
0
by: taylorcarr | last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
0
by: Charles Arthur | last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
0
by: aa123db | last post by:
Variable and constants Use var or let for variables and const fror constants. Var foo ='bar'; Let foo ='bar';const baz ='bar'; Functions function $name$ ($parameters$) { } ...
0
by: ryjfgjl | last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
0
by: ryjfgjl | last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
0
BarryA
by: BarryA | last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
1
by: Sonnysonu | last post by:
This is the data of csv file 1 2 3 1 2 3 1 2 3 1 2 3 2 3 2 3 3 the lengths should be different i have to store the data by column-wise with in the specific length. suppose the i have to...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.