[IronPython] true division?

Martin Maly Martin.Maly at microsoft.com
Fri Sep 22 17:41:54 CEST 2006


Actually, the special-casing of the construct "from __future__ import whatever" is part of Python language definition and is detected by IronPython and CPython alike by parser/compiler in order to change code generation of division operator (for the division case), sometimes the __future__ import will also influence parsing itself (enable 'with' statement etc.)

Apart from this extra detection, the "from __future__ import whatever" statement is handled in the same way as any other occurrence of "from module import whatever", meaning that the statement will still attempt to find module "__future__" on the disk (or in sys.modules) and import 'whatever' from it. This behavior also is the same for both CPython and IronPython. In fact, it is easily demonstrated.

In the following example, I clear sys.path so that CPython fails to find the module __future__.py, but the division behavior will still get changed:

Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> 1/2
0
>>> import sys
>>> sys.path=[]
>>> from __future__ import division
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: No module named __future__
>>> 1/2
0.5
>>>

So the actual difference is that IronPython doesn't ship out of the box with the __future__.py module, otherwise, the behavior of both implementations is identical.

Hope this sheds some light on the "from __future__" behavior.
Martin


-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Gary Stephenson
Sent: Thursday, September 21, 2006 6:03 PM
To: Discussion of IronPython
Subject: Re: [IronPython] true division?

Hi John

> The difference in this case is that IronPython has special-cased the
> "from __future__ import whatever" caper -- there is no module called
> __future__ in IronPython. Note the different error messages below:
>
> | >>> from __future__ import somerubbish
> | Traceback (most recent call last):
> | SyntaxError: future feature is not defined: somerubbish (<stdin>, line
> 1)
> | >>> from sys import somerubbish
> | Traceback (most recent call last):
> |  File , line 0, in <stdin>##13
> | ImportError: Cannot import name somerubbish
> | >>>

Yes, indeed I think it was the "future feature is not defined" message that
convinced me that ipy grokked the whole "form/import __future__ ..." thing,
which is why I didn't consider the CPython lib dependency (along with the
fact that I had not previously comprehended the fact that there is indeed an
actual module somewhere called "__future__" - I'd always thought of it as an
entirely insubstantial time machine type of whatsit).

thanks again,

gary

_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



More information about the Ironpython-users mailing list