If I do from __future__ import division then eval(1/2) gives me 0.5 as
expected. But if I do print input("enter a sum: ") and enter 1/2 as
the sum I get 0 as if I hadn't done the import. I thought input was
supposed to give the same behaviour as an eval on raw input -- why the
difference here? 12 2103
Try 1.0/2 instead of 1/2. Note that when I do eval("1/2") I get 0 not
0.5
-Denis
Le Sun, 11 Jan 2004 23:45:48 +0000, Tim Rowe
<tim@remove_if_not_spam.digitig.co.uk> a écrit : If I do from __future__ import division then eval(1/2) gives me 0.5 as expected. But if I do print input("enter a sum: ") and enter 1/2 as the sum I get 0 as if I hadn't done the import. I thought input was supposed to give the same behaviour as an eval on raw input -- why the difference here?
Denis Sarrazin wrote: Try 1.0/2 instead of 1/2. Note that when I do eval("1/2") I get 0 not 0.5
Please note: "from __future__ import division", see PEP 238 which
changes the behavior of the divisino operator.
My results with Python 2.3.3: from __future__ import division eval('1/2')
0.5 input()
1/2
0 eval(raw_input())
1/2
0.5 -Denis
Le Sun, 11 Jan 2004 23:45:48 +0000, Tim Rowe <tim@remove_if_not_spam.digitig.co.uk> a écrit :
If I do from __future__ import division then eval(1/2) gives me 0.5 as expected. But if I do print input("enter a sum: ") and enter 1/2 as the sum I get 0 as if I hadn't done the import. I thought input was supposed to give the same behaviour as an eval on raw input -- why the difference here?
Tim Rowe <tim@remove_if_not_spam.digitig.co.uk> writes: If I do from __future__ import division then eval(1/2) gives me 0.5 as expected. But if I do print input("enter a sum: ") and enter 1/2 as the sum I get 0 as if I hadn't done the import. I thought input was supposed to give the same behaviour as an eval on raw input -- why the difference here?
The input function is calling eval from the context of the module
where 'input' itself is defined. If you use "from __future__ import
division" in module A and have "print 3/2" in module B, the value of
3/2 in module B shouldn't be affected by the input, since module B
may depend on integer division having the old behavior.
The result is a little bit surprising at first glance though, so it
should probably be documented.
In article <7x************@ruckus.brouhaha.com>, Paul Rubin <http@?.cx>
writes Tim Rowe <tim@remove_if_not_spam.digitig.co.uk> writes: If I do from __future__ import division then eval(1/2) gives me 0.5 as expected. But if I do print input("enter a sum: ") and enter 1/2 as the sum I get 0 as if I hadn't done the import. I thought input was supposed to give the same behaviour as an eval on raw input -- why the difference here?
The input function is calling eval from the context of the module where 'input' itself is defined. If you use "from __future__ import division" in module A and have "print 3/2" in module B, the value of 3/2 in module B shouldn't be affected by the input, since module B may depend on integer division having the old behavior.
The result is a little bit surprising at first glance though, so it should probably be documented.
I get this in pythonwin with 2.3.2
PythonWin 2.3.2 (#49, Oct 2 2003, 20:02:00) [MSC v.1200 32 bit (Intel)]
on win32.
Portions Copyright 1994-2001 Mark Hammond (mh******@skippinet.com.au) -
see 'Help/About PythonWin' for further copyright information. from __future__ import division eval('1/2')
0.5
In python I get
Python 2.3.2 (#49, Oct 2 2003, 20:02:00) [MSC v.1200 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information. from __future__ import division eval('1/2')
0.5
so I guess pythonwin is broken in this respect.
--
Robin Becker
[Tim Rowe] If I do from __future__ import division then eval(1/2) gives me 0.5 as expected. But if I do print input("enter a sum: ") and enter 1/2 as the sum I get 0 as if I hadn't done the import. I thought input was supposed to give the same behaviour as an eval on raw input -- why the difference here?
[Paul Rubin[ The input function is calling eval from the context of the module where 'input' itself is defined. If you use "from __future__ import division" in module A and have "print 3/2" in module B, the value of 3/2 in module B shouldn't be affected by the input, since module B may depend on integer division having the old behavior.
Right!
So, the way to get eval() to respond to the import is to pass along
the current environment: from __future__ import division eval('9/2', globals())
4.5
Raymond Hettinger
Robin Becker <ro***@jessikat.fsnet.co.uk> writes: Python 2.3.2 (#49, Oct 2 2003, 20:02:00) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. from __future__ import division eval('1/2') 0.5 so I guess pythonwin is broken in this respect.
Huh? you get the expected result with both python and pythonwin. Neither
one is broken. The surprising result is from input(), not eval():
$ python
Python 2.2.2 (#1, Feb 24 2003, 19:13:11)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information. from __future__ import division print input('expression: ')
expression: 1/2
0 print eval('1/2')
0.5
That's because input evaluates its string in the context of a
different module which was compiled with old-style division. I don't
know of other functions that use eval like that, and input() should
be deprecated or eliminated anyway, so this isn't a big deal.
Thanks. I'd not realized that we could test out new changes to Python
within existing Python code. Cool.
-D
Le Mon, 12 Jan 2004 02:49:45 -0700, Jason Mobarak <jm**@unm.edu> a
écrit : Please note: "from __future__ import division", see PEP 238 which changes the behavior of the divisino operator. py****@rcn.com (Raymond Hettinger) writes: [Tim Rowe] If I do from __future__ import division then eval(1/2) gives me 0.5 as expected. But if I do print input("enter a sum: ") and enter 1/2 as the sum I get 0 as if I hadn't done the import. I thought input was supposed to give the same behaviour as an eval on raw input -- why the difference here? [Paul Rubin[ The input function is calling eval from the context of the module where 'input' itself is defined. If you use "from __future__ import division" in module A and have "print 3/2" in module B, the value of 3/2 in module B shouldn't be affected by the input, since module B may depend on integer division having the old behavior.
Right!
So, the way to get eval() to respond to the import is to pass along the current environment: from __future__ import division eval('9/2', globals())
4.5
Um, that's not how it works. Off the top of my head I'm not entirely
sure why eval() respects future statements and input() does not, but
it's probably easy enough to fix, if anyone cares (I don't think I
do).
Cheers,
mwh
--
Windows 2000: Smaller cow. Just as much crap. -- Jim's pedigree of
operating systems, asr
In article <7x************@ruckus.brouhaha.com>, Paul Rubin <http@?.cx>
writes Robin Becker <ro***@jessikat.fsnet.co.uk> writes: Python 2.3.2 (#49, Oct 2 2003, 20:02:00) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from __future__ import division >>> eval('1/2') 0.5 >>>
I guess I'm 'broken' :)
--
Robin Becker
Raymond Hettinger <py****@rcn.com> wrote: So, the way to get eval() to respond to the import is to pass along the current environment: from __future__ import division eval('9/2', globals())
4.5
You can also put a future-import in the string, allowing you to run code
with features not known until run-time (and without affecting the host
script). Of course the catch is that import is a statement, not an
expression, so you have to do it with 'exec', eg.:
expr= '9/2'
features= 'division'
scope= {}
exec 'from __future__ import %s\n__assign= (%s)'%(features,expr) in scope
print scope['__assign']
4.5
What you then *can't* do is have a future-import in the host script without
it affecting the script in the exec block.
Python 2.2+ has a much nicer way of doing it involving passing flags to the
'compile' function, which is preferable if you don't need backwards
compatibility.
Anyway, straying from the original point here.
Paul Rubin <http://ph****@NOSPAM.invalid> writes: Peter Hansen <pe***@engcorp.com> writes: Python has no support for macros or aliases, and it would be silly to add some special kludge for input(). The user needs to be able to redefine the function and so forth too. Sure it does:
def input(*args): return eval(raw_input(*args))
For it to be an alias, that definition would have to be injected into the module that input is actually called from, not run in a separate module.
The problem with doing things this way is that it's not easy to get
Python-defined functions into an extension module. Nothing deep.
How the heck does input get at the environment of its caller, anyway? Through the frame object chain?
Yes. The function you are seeking is called
PyEval_MergeCompilerFlags.
I guess the obvious fix is for the future division flag to be part of the environment, so evaling in the caller environment is done according to the flag.
I'm not sure what you mean here. eval() already respects future
division, as does execfile() and compile(). input() just got
overlooked when this stuff got added (back in the 2.1 era for nested
scopes, though the details have changed intermittently over the
intervening vwersions).
Someone has already checked a fix into sourceforge, but I haven't looked at it and don't know if it works that way or some other way.
Wouldn't checking have taken about as much time as writing the above
post? It's a very simple patch...
Cheers,
mwh
--
All obscurity will buy you is time enough to contract venereal
diseases. -- Tim Peters, python-dev
Peter Hansen <pe***@engcorp.com> writes: Michael Hudson wrote: Peter Hansen <pe***@engcorp.com> writes:
Tim Rowe wrote: > > Well, the documentation for "input()" says "Equivalent to > eval(raw_input(/prompt/))". Perhaps it should say "/Usually/ > equivalent...."
I remember reading that too, and just assumed that at this point it was in fact *implemented* that way, as a simple alias. Maybe it should be... http://www.python.org/sf/876178
Ideas on how to write a testcase welcome.
Are there any test cases which verify behaviour both in the presence and absence of certain "from __future__ import" statements?
Yes.
My first thought would have been simply to write two test files, one of which imports from __future__ and the other which does not, and check that in both cases input(x) == eval(raw_input(x)).
Or is the issue how to test when the input comes from stdin? In that case, doesn't faking sys.stdin work as usual?
Oh, probably...
Cheers,
mwh
--
I'll write on my monitor fifty times 'I must not post self-indulgent
wibble nobody is interested in to ucam.chat just because I'm bored
and I can't find the bug I'm supposed to fix'.
-- Steve Kitson, ucam.chat This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Michael Foord |
last post by:
Here's a little oddity with 'print' being a reserved word...
>>> class thing:
pass
>>> something = thing()
>>> something.print = 3
SyntaxError: invalid syntax
>>> print something.__dict__...
|
by: joel |
last post by:
I have a table which I want to update by dividing one field into
another. The update runs with no errors, but the results come out as
only a positive integer number.
The datatype for the result...
|
by: Marcin |
last post by:
How I can make division of two numbers placed in arrays, example:
short int a = {2,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,2};
short int b =...
|
by: seb.haase |
last post by:
Hi,
Is it true that that "Python 3000" is dead ?
Honestly I think that e.g. changing 5/2 to be 2.5 (instead of 2) would
just break to much code :-(
On the otherhand I'm using Python as "Matlab...
|
by: jmdocherty |
last post by:
All,
I've been trying to set up a CSS layout and all seems well in Firefox
but in Safari it just seems to be plain weird! I hope someone can help
tell me whether this is a problem with my code...
|
by: michael.f.ellis |
last post by:
The following script puzzles me. It creates two nested lists that
compare identically. After identical element assignments, the lists
are different. In one case, a single element is replaced. In...
|
by: Mike S |
last post by:
Does anyone know the logic behind why in VB.NET the result of a
floating-point division ('/') is -rounded- on being converted to an
integer type, such as with statements like
Dim x As Integer =...
|
by: kermit |
last post by:
For a long time,, There has been a discussion of trueFor division
versus integer division in Python.
I myslef prefer that / be used for integer division since almost
always, I want the...
|
by: jamesonang |
last post by:
Supposed unsigned int(32 bits) is the largest number that computer can
represent with a single variable.
Now, i have a big integer ( less than 64 bit, but great than 32 bit) .
i represent it by...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
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...
|
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...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
| |