-Dwarn, long->double overflow (was RE: [Python-checkins] CVS: python/dist/src/Misc NEWS,1.219,1.220)
[Guido]
+ + A new command line option, -D<arg>, is added to control run-time + warnings for the use of classic division. ... + Using -Dwarn issues a run-time warning about all uses of classic + division for int, long, float and complex arguments.
I'm unclear on why we warn about classic division when a float or complex is involved: C:\Code\python\PCbuild>python -Dwarn Python 2.2a2+ (#22, Aug 31 2001, 14:36:57) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information.
2./3. __main__:1: DeprecationWarning: classic float division 0.66666666666666663
Given that this is going to return the same result even in Python 3.0, what is it warning me about? That is, as an end user, I'm being warned about behavior I can't do anything about, and behavior that Python isn't going to change anyway. Different issue: I would like to add OverflowError when coercion of long to float yields a senseless result. PEP 238 mentions this as a possibility, and
from __future__ import division x = 1L << 3000 x/(2*x) -1.#IND
really sucks. For that matter,
float(1L << 3000) 1.#INF
has always sucked; future division just makes it suck harder <wink>. Any objections to raising OverflowError here? Note this is a bit painful for a bogus reason: PyFloat_AsDouble returns a double, and nothing in the codebase now checks it for a -1.0 error return (despite that it can already produce one). So half the effort would be repairing code currently ignoring the possibility of error. Third issue: I don't see a *good* reason for the future-division x/(2*x) above not to return 0.5. long_true_divide could be made smart enough to do that (more generally, to return a good float approximation whenever the true result is representable as a float).
[Guido]
+ + A new command line option, -D<arg>, is added to control run-time + warnings for the use of classic division. ... + Using -Dwarn issues a run-time warning about all uses of classic + division for int, long, float and complex arguments.
I'm unclear on why we warn about classic division when a float or complex is involved:
C:\Code\python\PCbuild>python -Dwarn Python 2.2a2+ (#22, Aug 31 2001, 14:36:57) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information.
2./3. __main__:1: DeprecationWarning: classic float division 0.66666666666666663
Given that this is going to return the same result even in Python 3.0, what is it warning me about? That is, as an end user, I'm being warned about behavior I can't do anything about, and behavior that Python isn't going to change anyway.
Sorry, I should have explained the intention. This warning is intended for perusal by a tool (yet to create) that reads the warnings and can automatically fix your code by inserting the proper future division statements and/or replace / by //. The tool parses the source looking for / operators. For each / it sees if it has corresponding warnings, and if so, if the warnings are consistent (only int/long or only float/complex), it does the right thing. If all / operators in a module have at least one warning, it assumes that it has full coverage, and it adds a future division statement to the module. If there are some / operators for which it doesn't have any warnings, it asks the user to create a better test case. For this, it needs to know about float and complex divisions as well.
Different issue: I would like to add OverflowError when coercion of long to float yields a senseless result. PEP 238 mentions this as a possibility, and
from __future__ import division x = 1L << 3000 x/(2*x) -1.#IND
really sucks. For that matter,
float(1L << 3000) 1.#INF
has always sucked; future division just makes it suck harder <wink>.
Any objections to raising OverflowError here?
Sounds OK to me.
Note this is a bit painful for a bogus reason: PyFloat_AsDouble returns a double, and nothing in the codebase now checks it for a -1.0 error return (despite that it can already produce one). So half the effort would be repairing code currently ignoring the possibility of error.
Third issue: I don't see a *good* reason for the future-division
x/(2*x)
above not to return 0.5. long_true_divide could be made smart enough to do that (more generally, to return a good float approximation whenever the true result is representable as a float).
Sure, but I also don't see a good reason to make this a priority. It's a "don't care" corner of the language to me. --Guido van Rossum (home page: http://www.python.org/~guido/)
[Tim]
I'm unclear on why we warn about classic division when a float or complex is involved:
[Guido]
... This warning is intended for perusal by a tool (yet to create) that reads the warnings and can automatically fix your code by inserting the proper future division statements and/or replace / by //.
Got it now. Thanks! Cool idea, BTW.
I would like to add OverflowError when coercion of long to float yields a senseless result.
Sounds OK to me.
Anyone else object?
Third issue: I don't see a *good* reason for the future-division
x/(2*x)
above not to return 0.5 [when x is a large long].
Sure, but I also don't see a good reason to make this a priority. It's a "don't care" corner of the language to me.
Then I'll leave it alone, but I can't understand this view (it's not like we can claim we're victims of the platform C or libm here -- nonsense results in such cases are on our heads, and an implementation that settles for total loss of information when 53 good bits are obviously possible is at best careless).
+ + A new command line option, -D<arg>, is added ...
I don't know if it is worth considering, but jython already uses the -D option to set registry properties on the command line. -Dprop=v : Set the property `prop' to value `v' Jython would have to come up with a command line option different from -D to control division behavior. regards, finn
+ + A new command line option, -D<arg>, is added ...
I don't know if it is worth considering, but jython already uses the -D option to set registry properties on the command line.
-Dprop=v : Set the property `prop' to value `v'
Jython would have to come up with a command line option different from -D to control division behavior.
Darn. I wished you'd said something earlier -- I put this in PEP 237 weeks ago. Does Jython generally try to follow Python's command line options? Would it make sense to define a Jython property for the division behavior? Then I could change the syntax to -Ddivision=old, -Ddivision=warn, -Ddivision=new. That's a bit long, but acceptable. Otherwise, the only mnemonic I can think of would be -/old, -/warn, -/new. But that may be confusing for some users who are expecting options to be letters. I guess we could use -q for quotient. --Guido van Rossum (home page: http://www.python.org/~guido/)
+ + A new command line option, -D<arg>, is added ...
I don't know if it is worth considering, but jython already uses the -D option to set registry properties on the command line.
-Dprop=v : Set the property `prop' to value `v'
Jython would have to come up with a command line option different from -D to control division behavior.
[GvR]
Darn. I wished you'd said something earlier -- I put this in PEP 237 weeks ago.
So many peps and so little time. Following the discussion of peps like this is a bit of a strain when I really don't care what division return. I'll try to be more proactive about new pep revisions in the future.
Does Jython generally try to follow Python's command line options?
We try to. -i, -S, -W, -v and -c are the same. A very recently added -E options have a different semantic but that is a bug. In addition we have the options -D, -jar, --help and --version.
Would it make sense to define a Jython property for the division behavior?
That would work.
Then I could change the syntax to -Ddivision=old, -Ddivision=warn, -Ddivision=new. That's a bit long, but acceptable.
Our normal property names are a lot longer: -Dpython.security.respectJavaAccessibility=false -Dpython.options.showJavaExceptions=true because there are situations where the jython properties must live in the same namespace as the properties for java, corba etc. As a practical solution, -Ddivision=warn world work fine. regards, finn
On Sat, Sep 01, 2001 at 10:10:10PM -0400, Guido van Rossum wrote:
... Would it make sense to define a Jython property for the division behavior? Then I could change the syntax to -Ddivision=old, -Ddivision=warn, -Ddivision=new. That's a bit long, but acceptable.
This would be similar to compilers which use -Dsym[=value]. Apache has a similar -Dsym[=value] option. Note that a general -Dkey=value option would be quite nice. They could all end in sys.startoptions or somesuch. After the -D switches are processed, the startup code can look in the dictionary for "division" to determine what to do. sys.startoptions would be a generalized way to pass parameters into subsystems which otherwise have no control of the command line. (Apache 2.0 uses this to pass params to the modules which handle request processing) By using sys.startoptions, it would also be portable to systems which don't usually use a command line (Windows, Mac, GUIs, etc); they could potentially get those options from the registry or whatever. Cheers, -g -- Greg Stein, http://www.lyra.org/
On Sun, Sep 02, 2001 at 10:22:54AM -0700, Greg Stein wrote:
sys.startoptions would be a generalized way to pass parameters into subsystems which otherwise have no control of the command line. (Apache 2.0 uses this to pass params to the modules which handle request processing) By using sys.startoptions, it would also be portable to systems which don't usually use a command line (Windows, Mac, GUIs, etc); they could potentially get those options from the registry or whatever.
I'm not sure this is really that useful. In my experience, by far the most common way to execute python is as a script handler, where the -D mechanism is close to useless (if you want to pass such fairly static options into the script, you might as well hardcode them several lines lower.) Contrary to Apache, Python itself isn't often started directly. As for scripts themselves, they all do their own optionparsing anyway (or should.) Back-from-vacation-and-*almost*--caught-up-with-email-ly y'rs, -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
[Greg Stein]
Note that a general -Dkey=value option would be quite nice. They could all end in sys.startoptions or somesuch.
Jython calls it sys.registry: Jython 2.1b1 on java1.4.0-beta (JIT: null) Type "copyright", "credits" or "license" for more information.
import sys sys.registry {python.path=d:\python\Python211\Lib}
After the -D switches are processed, the startup code can look in the dictionary for "division" to determine what to do.
sys.startoptions would be a generalized way to pass parameters into subsystems which otherwise have no control of the command line. (Apache 2.0 uses this to pass params to the modules which handle request processing) By using sys.startoptions, it would also be portable to systems which don't usually use a command line (Windows, Mac, GUIs, etc); they could potentially get those options from the registry or whatever.
Jython reads such options from the files "${sys.prefix}/registry" and "${HOME}/.jython" in addition to the -D options on the command line. regards, finn
Would it make sense to define a Jython property for the division behavior? Then I could change the syntax to -Ddivision=old, -Ddivision=warn, -Ddivision=new. That's a bit long, but acceptable.
This would be similar to compilers which use -Dsym[=value]. Apache has a similar -Dsym[=value] option.
Note that a general -Dkey=value option would be quite nice. They could all end in sys.startoptions or somesuch. After the -D switches are processed, the startup code can look in the dictionary for "division" to determine what to do.
sys.startoptions would be a generalized way to pass parameters into subsystems which otherwise have no control of the command line. (Apache 2.0 uses this to pass params to the modules which handle request processing) By using sys.startoptions, it would also be portable to systems which don't usually use a command line (Windows, Mac, GUIs, etc); they could potentially get those options from the registry or whatever.
Yes, would be nice - but I have no time for that if I want to make a release this week (or later). I think I'll go for something stupid and simple now, like just using -q to turn on division warnings, and nothing else (the -Dnew option is not very useful I think). --Guido van Rossum (home page: http://www.python.org/~guido/)
On Sun, Sep 02, 2001 at 05:28:13PM -0400, Guido van Rossum wrote:
I think I'll go for something stupid and simple now, like just using -q to turn on division warnings, and nothing else (the -Dnew option is not very useful I think).
I'm fine with a single option, but I'd like to note two things: we already have a command line option to turn on specific warnings, do we really need another ? And -q, to me, *screams* 'quiet', exactly the wrong thing... How about -Q instead, if we really need a separate option for it ? -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
I think I'll go for something stupid and simple now, like just using -q to turn on division warnings, and nothing else (the -Dnew option is not very useful I think).
I'm fine with a single option, but I'd like to note two things: we already have a command line option to turn on specific warnings, do we really need another ?
Yes, for efficiency reasons. A call to PyErr_Warn(), even if it doesn't print anything, is very expensive (compared to a division): it calls out to the warnings.py module which goes through a list of filters etc., etc.
And -q, to me, *screams* 'quiet', exactly the wrong thing... How about -Q instead, if we really need a separate option for it ?
OK. --Guido van Rossum (home page: http://www.python.org/~guido/)
guido wrote:
Yes, for efficiency reasons. A call to PyErr_Warn(), even if it doesn't print anything, is very expensive (compared to a division): it calls out to the warnings.py module which goes through a list of filters etc., etc.
you could always special-case "-Wdefault:classic float division" (it's not exactly an option everyone will use all the time, is it?) </F>
On Sun, Sep 02, 2001 at 09:52:42PM -0400, Guido van Rossum wrote:
I'm fine with a single option, but I'd like to note two things: we already have a command line option to turn on specific warnings, do we really need another ?
Yes, for efficiency reasons. A call to PyErr_Warn(), even if it doesn't print anything, is very expensive (compared to a division): it calls out to the warnings.py module which goes through a list of filters etc., etc.
Well, sure, but that says naught about not using the same *option*, just about not using the same framework :) It shouldn't be too hard to specialcase, say, -Wdiv. (or '-Wodiv' or '-Wtdiv', or whichever.) -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
Well, sure, but that says naught about not using the same *option*, just about not using the same framework :) It shouldn't be too hard to specialcase, say, -Wdiv. (or '-Wodiv' or '-Wtdiv', or whichever.)
Cute, but worries me a bit because normally -W options aren't syntax-checked at all by the command line processing code -- only by the warnings module (because the syntax is too complex). And this means that you don't get a warning about a bogus option at all if no warnings are ever issued. This would mean that a misspelling of -Wdiv would cause mysterious silence. Command line options aren't in such short demand that I can't pick a new letter. --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (6)
-
bckfnn＠worldonline.dk -
Fredrik Lundh -
Greg Stein -
Guido van Rossum -
Thomas Wouters -
Tim Peters