PEP0238 lament
Arthur...@rsmi.com
discussions of Pep238 (or case sensitivty) allow
be to present my credentials.
None, to speak of.
Except that I've been through the program. Guido's
program. His language. His environment. His
tutorials.
I think with some success.
Participate little on python-list, because much of
what goes on is over my head.
But on the question of learning programming with
Python - as I mention, been through the program.
Here the issues are under my nose, not
over my head.
I particpate actively on the edu-sig list, because
I understand my success could be other's success.
Am a big supporter of Guido's CP4E ideals.
Yet despite the gratitude I try to keep in mind,
I clash consistently with Guido on CP4E - sometimes
in unpleasant ways.
Can only hope he appreciates at some level that I
bring some passion to the table on some common
goals.
Because that clash now spills over to the Python list.
Since I have convinced myself that not only do I
object to the rationale and evidence gathering behind
the integer division change - I am going to step up
and be arrogant enough to say that I am against it
as a design feature, in light of the only aspect of Python
design about which I would dare to speak - CP4E goals.
3 / 4 = 0
3.0 / 4 = .75
Something important is going on here. I have a decent
understanding of what that is. Enough to get me by in
the real world.
I came to It - having already understood that I would
only get so far if I expected it all to come to me.
That reckoning has been put off an hour ot two for the
Python 2.2 learner, with a measurable cost.
Pity for the Python2.2 learner.
Quite well realize that I am not saying anything that
hasn't been said before on the issue.
But disappointed to never have heard the counter
argument from Guido - what put the issue over the
top for him?
If I was told that experinced programmers might
appreciate this change for any possible reason -
I'd be quiet as a mouse.
Since I remain convinced that the single most important
factor for Python's acceptance as an educational language is
the growth of its acceptance as a professional language.
It will be interesting to see where Guido chooses to draw
the line on the thought process that lead him to his integer
division conclusion.
Which is the real issue - the integer division thing, stand-alone,
not likely to be a deal breaker for anyone.
Like to believe that there is more real world thinking
than Guido chooses to share publicly.
Alternatively, I'm baffled as hell.
ART
Guido van Rossum
constantly. I don't know why it is, but ever post of his feels like a
flame or flamebait to me. I always feel that he attacks me as a
person rather than attacking my arguments (usually because he claims
that I haven't given any arguments). Try as I may, this makes it very
hard, almost impossible for me to respond in a meaningful manner to
Arthur's posts. I wonder what I've done to tick him off. I also
wonder how come he is so good at ticking me off.
The reason for wanting / to return a float (or at least a type that
can represent close approximations of numbers like 0.75) has been
discussed many times before. The summary of the argument in the PEP
may not be complete, but I disagree with Arthur's assessment that
integer division is not a problem -- the VPython folks have ample
experience that it is.
Because all Arthur does is tick me off, I'll leave it at this -- maybe
someone else can explain it all to him.
--Guido van Rossum (home page: http://www.python.org/~guido/)
Rainy
>
> If I was told that experinced programmers might
> appreciate this change for any possible reason -
> I'd be quiet as a mouse.
I don't think they will..
>
> Since I remain convinced that the single most important
> factor for Python's acceptance as an educational language is
> the growth of its acceptance as a professional language.
First of all, it's really ugly. It's the ugliest thing in python for a newbie,
imho. Yes, 1/2 is 0. You have to type 1.0/2 to get 0.5. No, there is no good
reason for that, just memorize it. Ugh.
If it was just a matter of that, it wouldn't be enough for a change (non-
backwards-compatible one). But, the problem is that people will have strange
bugs because of this and spend hours upon hours trying to figure out what's
wrong. Python may be around during next 10-20 years and userbase may grow
a thousandfold, and having this ugliness on board for all this time is a
big problem.
It's arguable whether the problem is serious enough to break old code, but it's
obvious (to me, anyway) that there *is* a rather big problem here.
--
Cymbaline: intelligent learning mp3 player - python, linux, console.
get it at: http://silmarill.org/cymbaline
Guido van Rossum
>
> http://python.sourceforge.net/peps/pep-0238.html
>
> It looks like it hasn't been updated since March. I see no support for the
> argument that the current integer division semantics are confusing, only a
> claim that the current semantics are a problem. Perhaps there's a more
> recent version of the PEP available that hasn't been released to the
> website.
Skip,
I've asked Moshe today to update the rationale based on the discussion
in c.l.py. He said he would. So just be patient.
Skip Montanaro
Guido> The reason for wanting / to return a float (or at least a type
Guido> that can represent close approximations of numbers like 0.75) has
Guido> been discussed many times before. The summary of the argument in
Guido> the PEP may not be complete, but I disagree with Arthur's
Guido> assessment that integer division is not a problem -- the VPython
Guido> folks have ample experience that it is.
Guido,
I just reread the PEP at
http://python.sourceforge.net/peps/pep-0238.html
It looks like it hasn't been updated since March. I see no support for the
argument that the current integer division semantics are confusing, only a
claim that the current semantics are a problem. Perhaps there's a more
recent version of the PEP available that hasn't been released to the
website.
--
Skip Montanaro (sk...@pobox.com)
http://www.mojam.com/
http://www.musi-cal.com/
Moshe Zadka
> Guido,
>
> I just reread the PEP at
>
> http://python.sourceforge.net/peps/pep-0238.html
>
> It looks like it hasn't been updated since March. I see no support for the
> argument that the current integer division semantics are confusing, only a
> claim that the current semantics are a problem. Perhaps there's a more
> recent version of the PEP available that hasn't been released to the
> website.
Not really. I'm working on the PEP, and hopefully there will be a
new version tommorow with some more meat.
--
gpg --keyserver keyserver.pgp.com --recv-keys 46D01BD6 54C4E1FE
Secure (inaccessible): 4BD1 7705 EEC0 260A 7F21 4817 C7FC A636 46D0 1BD6
Insecure (accessible): C5A5 A8FA CA39 AB03 10B8 F116 1713 1BCF 54C4 E1FE
Tim Peters
> ...
> If I was told that experinced programmers might
> appreciate this change for any possible reason -
> I'd be quiet as a mouse.
Not all experienced programmers agree. At the last Python Conference, I
moderated a 40-some person group discussion on conceivable changes to
Python's numeric model, not advocating but keeping the participants from
killing each other <wink>. The meaning of integer division wasn't the
focus, but naturally came up. By show of hands, about 3/4ths of the
participants agreed that 3/4 should not return 0, but rather *something* x
such that x*4 had a better chance of being confused with 3 than with 0.
There was no consensus on exactly what 3/4 should return -- rational or HW
float or decimal float were the most popular alternatives.
It shouldn't be so hard to understand why. The current integer division
loses information silently and without a trace. Combined with that Python
is not a statically typed language, there's simply no telling what e.g.
def velocity(distance, time):
return distance / time
will compute by inspection. This isn't about esoteric user overloading of
"/", it's about ordinary arithmetic on builtin numeric types, and many
experienced Python programmers have testified over the years to being burned
in practice by stuff exactly that simple.
I expect that either way is easy enough to *teach*, but I don't accept ease
of teaching as a primary goal: I'm much keener on semantics that, once
*learned*, are hard to forget or to stumble over. Even if such semantics
are 100x harder to teach at first, fine by me: you spend the rest of your
life living with the consequences. I wish the definition of continuity were
easier to teach too, but that doesn't mean I'll settle for an easier
definition that doesn't actually work <wink>.
some-mice-are-surprised-when-thet-divide-up-the-cheese-and-
cheese-mass-mysteriously-disappears-ly y'rs - tim
Moshe Zadka
On Sun, 22 Jul 2001 14:22:21 -0400, "Tim Peters" <tim...@home.com> wrote:
> I wish the definition of continuity were
> easier to teach too, but that doesn't mean I'll settle for an easier
> definition that doesn't actually work <wink>.
Here is one that is easier to teach, if you just reverse the order
of teaching calculus and first-order logic and basic set theory.
A function is continuous at c if, when embedding the world of Reals
into a saturated model (or, say, 2^{Beth_omega} saturated, if you
don't want to get into subtle assumptions), for every infinitesimal x,
f(c+x)-f(c) is an infintesimal.
Of course, you might think that teaching about saturation is hard --
well, it might be ;-)
i-always-blamed-cauchy-and-weirstrass-for-tormenting-the-world-
with-epsilons-and-deltas-ly y'rs, Z.
David Eppstein
"Tim Peters" <tim...@home.com> wrote:
> By show of hands, about 3/4ths of the
> participants agreed that 3/4 should not return 0, but rather *something* x
> such that x*4 had a better chance of being confused with 3 than with 0.
Well then, float is a very bad choice for what to return, or then how do
we explain when 3/4 * 4 = 3 (exactly) but 3/10 * 10 != 10?
I would be a lot happier with integer / integer = rational (as in
Mathematica's programming lang), but float is just ugly. It is turning
exact values (integers) into approximate ones (float) when I didn't tell it
to. It's almost as bad as if integer subtraction always truncated to 16
bit values -- a lot of the time that would give sort of reasonable answers
but it's a gratuitous approximation where you didn't expect one.
--
David Eppstein UC Irvine Dept. of Information & Computer Science
epps...@ics.uci.edu http://www.ics.uci.edu/~eppstein/
David Eppstein
David Eppstein <epps...@ics.uci.edu> wrote:
> Well then, float is a very bad choice for what to return, or then how do
> we explain when 3/4 * 4 = 3 (exactly) but 3/10 * 10 != 10?
Uh, of course I meant 3/10 * 10 != 3...
James Logajan
> By show of hands, about 3/4ths of the
> participants agreed that 3/4 should not return 0, but rather *something* x
> such that x*4 had a better chance of being confused with 3 than with 0.
> There was no consensus on exactly what 3/4 should return -- rational or HW
> float or decimal float were the most popular alternatives.
This has probably already been brought up, but perhaps the problem lies not
with the "/" operator, but one step earlier in distinguishing the meaning
of:
x = 3
and
x = 3.
That is subtle difference that can cause quite different results later on.
Or, one may try to teach that when ALL arguments of an operator are in one
"set", such as the set of integers, then one must expect a result that is an
element from THAT set, not another set, such as the set of real numbers or
from the set of complex numbers. Set theory seems to be taught fairly early
on in math, I think.
It has been my observation that people can often quickly grasp and make use
of the common underlying general principles behind things after having seen
only a few examples, provided there is a CONSISTENT underlying principle. A
handful of general rules may be easier to teach than a collection of special
cases. So can and should Python adopt an underlying principle along the
lines where one can grasp the following pattern:
integer = integer operator integer
real = integer operator real
real = real operator integer
real = real operator real
complex = integer operator complex
...
I prefer a handful of general rules, and operators that obey them.
Erik Max Francis
> I would be a lot happier with integer / integer = rational (as in
> Mathematica's programming lang), but float is just ugly. It is
> turning
> exact values (integers) into approximate ones (float) when I didn't
> tell it
> to. It's almost as bad as if integer subtraction always truncated to
> 16
> bit values -- a lot of the time that would give sort of reasonable
> answers
> but it's a gratuitous approximation where you didn't expect one.
I agree. It's turning an otherwise fairly strongly (but dynamically)
typed language on its head. If I want type-changing operations, I'll do
them explicitly.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
/ \ Wretches hang that jurymen may dine.
\__/ Alexander Pope
Esperanto reference / http://mirror/alcyone/max/lang/esperanto/
An Esperanto reference for English speakers.
Tim Peters
> I wish the definition of continuity were easier to teach too, but that
> doesn't mean I'll settle for an easier definition that doesn't actually
> work <wink>.
[Moshe Zadka]
> Here is one that is easier to teach, if you just reverse the order
> of teaching calculus and first-order logic and basic set theory.
>
> A function is continuous at c if, when embedding the world of Reals
> into a saturated model (or, say, 2^{Beth_omega} saturated, if you
> don't want to get into subtle assumptions), for every infinitesimal x,
> f(c+x)-f(c) is an infintesimal.
>
> Of course, you might think that teaching about saturation is hard --
> well, it might be ;-)
Na, they always leave *some* of the foundations in intro calculus courses
fuzzy. H. Jerome Keisler wrote a very good intro calculus text based on
non-standard analysis, unfortunately now out of print. See
http://www.math.wisc.edu/~keisler/books.html
for publication details. He didn't try to explain the intricacies of model
theory, he just spelled out "the rules" for working with infinitesimals and
got on with it. Huge steaming masses of epsilon-delta proofs were
conspicuous by absence, so he was able to get to "the interesting stuff" a
lot quicker that way. A good feel for the flavor of the approach can be
gotten by skipping to the end ("Part IV: Turning Calculus into Algebra") of
http://online.sfsu.edu/~brian271/nsa.pdf
and reading "~=" as "infinitely close to".
> i-always-blamed-cauchy-and-weirstrass-for-tormenting-the-world-
> with-epsilons-and-deltas-ly y'rs, Z.
i-personally-blame-guido-for-letting-it-stand<wink>-ly y'rs - tim
Justin Sheehy
> 1/2 is 0. You have to type 1.0/2 to get 0.5. No, there is no good
> reason for that, just memorize it. Ugh.
Of course there is a good reason for it.
It may not be a reason that you personally think is "good enough", but
that does not make it a random, arbitrary aspect of the language.
You don't have to memorize that 1/2 is zero. You just have to learn
the general rule here, that division of two integers produces an integer.
Whether or not you like this feature, presenting it as you have is
incorrect and unfair.
-Justin
Martijn Faassen
> [Arthur...@rsmi.com]
>> ...
>> If I was told that experinced programmers might
>> appreciate this change for any possible reason -
>> I'd be quiet as a mouse.
> Not all experienced programmers agree. At the last Python Conference, I
> moderated a 40-some person group discussion on conceivable changes to
> Python's numeric model, not advocating but keeping the participants from
> killing each other <wink>. The meaning of integer division wasn't the
> focus, but naturally came up. By show of hands, about 3/4ths of the
> participants agreed that 3/4 should not return 0, but rather *something* x
> such that x*4 had a better chance of being confused with 3 than with 0.
> There was no consensus on exactly what 3/4 should return -- rational or HW
> float or decimal float were the most popular alternatives.
> It shouldn't be so hard to understand why.
[snip Tim's reasons]
The audience was entirely self-selected; they were people with an interest
in numeric models. Did Guido ask for a show of hands in the big session
afterwards? I don't recall; I kind of suspect the outcome would've been
different.
> The current integer division
> loses information silently and without a trace. Combined with that Python
> is not a statically typed language, there's simply no telling what e.g.
> def velocity(distance, time):
> return distance / time
> will compute by inspection.
There's no telling what:
def add_stuff(a, b):
return a + b
will compute by inspection either, though. Are we complaining about that?
(yeah, I know the inverse operation is rather hard to define for
string addition :)
[snip]
Of course I claim no expertise in this matter whatsoever. :)
For working with pixels in GUIs and such, integer division can be a useful
thing, though.
Regards,
Martijn
--
History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?
Cliff Crawford
|
| The meaning of integer division wasn't the
| focus, but naturally came up. By show of hands, about 3/4ths of the
| participants agreed that 3/4 should not return 0, but rather *something*
In other words, nobody raised their hand, since 3/4 == 0. Well, that
settles it, then -- nobody wants this change <0.75 wink>.
--
Cliff Crawford http://www.sowrong.org/
A sign should be posted over every campus toilet:
"This flush comes to you by courtesy of capitalism."
-- Camille Paglia
Moshe Zadka
> I agree. It's turning an otherwise fairly strongly (but dynamically)
> typed language on its head. If I want type-changing operations, I'll do
> them explicitly.
Be sure to tell math.cos that...it has been "silently" turning integers
into floats for years.
> Esperanto reference / http://mirror/alcyone/max/lang/esperanto/
Err.....problem with the URL? I don't think there's a host called "mirror".
A pity, sounded interesting.
Tim Peters
> Well then, float is a very bad choice for what to return, or then how
> was intended here]
Using decimal floats, 3/10*10 does equal 3, but a generation raised on
BCD-ish hand calculators wouldn't even blink an eye if 1/3*3 returned
0.999999999999.
> I would be a lot happier with integer / integer = rational (as in
> Mathematica's programming lang),
That view has its fans too; see PEPs 239 and 240; also mounds of prior
discussion on the python-numerics list:
http://sourceforge.net/mail/?group_id=5470
You're probably new enough to this to have missed that Guido had lots of
experience with rationals in the ABC language and didn't like it there.
Speed and memory consumption were unpredictable for non-experts, and could
vary wildly (factors of 1000s) for a fixed algorithm, depending on the
inputs. Rationals aren't a cure-all, and the instant you throw a sqrt or
transcendental into the mix you're back to some form of fp anyway.
> but float is just ugly. It is turning exact values (integers) into
> approximate ones (float) when I didn't tell it to.
If the language defines "/" as returning a float, then you told it to. You
*almost* may as well complain that math.sqrt(2) turns an exact value into an
approximate one; but, e.g., when I use Macsyma, it doesn't lose information
there either. Python isn't going to do symbolic computation by default, so
the question isn't whether to compromise, but where.
> It's almost as bad as if integer subtraction always truncated to 16
> bit values -- a lot of the time that would give sort of reasonable
> answers but it's a gratuitous approximation where you didn't expect
> one.
You don't expect an approximation in that context because Python promises
not to make one in that context. If you expect things a language doesn't
promise, that's not really the language's fault <wink>.
Tim Peters
> This has probably already been brought up, but perhaps the problem lies
> not with the "/" operator, but one step earlier in distinguishing the
> meaning of:
>
> x = 3
> and
> x = 3.
>
> That is subtle difference that can cause quite different results later
> on.
Why is that? It's because unlike any other builtin arithmetic operation,
"/" today can cause *catastrophic* loss of information silently, and in
ordinary cases. If code sticks to + - * and **, it usually doesn't matter
much in the end whether someone says
x = 3
or
x = 3.
at the start. But toss in one "/", and radically different results are
common.
> Or, one may try to teach that when ALL arguments of an operator are in
> one "set", such as the set of integers, then one must expect a result
> that is an element from THAT set, not another set, such as the set of
> real numbers or from the set of complex numbers. Set theory seems to
> be taught fairly early on in math, I think.
I think you're missing that the proponents are arguing on pragmatic grounds:
this has mostly to do with that x/y surprises people in real life. It's not
that there aren't clear rules, or that the rules can't be taught, or that
people are too stupid to understand the rules. Guido hears all the
complaints, and he's become convinced that this is a genuine and serious
flaw in the language: the current rules are *unusable* for too many people
too often. If you're not one of them, congratulations <wink>. I'm not
either -- I never get burned by this. But I see plenty of people who are,
and they're neither stupid nor careless; it's a common blind spot, so it
doesn't really matter that it's not one I (or you) suffer.
> ...
> I prefer a handful of general rules, and operators that obey them.
Of course, but computer numerics is a massive exercise in picking the
general rules you want to preserve at the expense of others, and trading all
that off against pragmatics too. Not losing information silently is also a
Very Good General Rule, and even 745 binary fp arithmetic is better at
meeting that one than current "/".
Bengt Richter
>[Arthur...@rsmi.com]
>> ...
>> If I was told that experinced programmers might
>> appreciate this change for any possible reason -
>> I'd be quiet as a mouse.
>
I'd call myself experienced, though not yet with Python (though
I fancy my other experience gives me a leg up on most Python newbies).
I am generally so adaptable it's almost a problem, so I'll
have no big problem with '//' after I accept that this is Rome,
and I should do as the Romans do. It's certainly not going
to put me off Python ;-)
>Not all experienced programmers agree. At the last Python Conference, I
>moderated a 40-some person group discussion on conceivable changes to
>Python's numeric model, not advocating but keeping the participants from
>killing each other <wink>. The meaning of integer division wasn't the
>focus, but naturally came up. By show of hands, about 3/4ths of the
>participants agreed that 3/4 should not return 0, but rather *something* x
>such that x*4 had a better chance of being confused with 3 than with 0.
>There was no consensus on exactly what 3/4 should return -- rational or HW
>float or decimal float were the most popular alternatives.
>
>It shouldn't be so hard to understand why. The current integer division
>loses information silently and without a trace. Combined with that Python
The thing is, current floating point operations also (sometimes, not always,
just as with integer ops) lose "information silently and without a trace."
Just less noticeably, for the most part, if you sanitize output.
Which leads me to wondering if exactness would be a more approachable
concept for CP4E than details of numeric representation alternatives.
For many 'float' is about as relevant to their desired computing experience
as 'hypoid' is to their commuting experience. Why not keep both hidden under
the hood (without welding it shut, of course) ?
>is not a statically typed language, there's simply no telling what e.g.
>
>def velocity(distance, time):
> return distance / time
>
>will compute by inspection. This isn't about esoteric user overloading of
>"/", it's about ordinary arithmetic on builtin numeric types, and many
>experienced Python programmers have testified over the years to being burned
>in practice by stuff exactly that simple.
>
I believe you. BTW, is there an efficient type assertion that doesn't go away with
optimization, that one could use to refuse wrong-type arguments?
>I expect that either way is easy enough to *teach*, but I don't accept ease
>of teaching as a primary goal: I'm much keener on semantics that, once
Glad to hear that. <rant>Worst IMHO is when teachers teach what is actually wrong
to children or the otherwise innocently ignorant, with the rationale that
the real truth is too complicated, and even letting on that there is a real
truth will just be confusing. That not letting on part is the real evil.
Of course, many teachers are themselves the product of this methodology,
and pass it on unawares.</rant>
I wonder what K-12 teachers will say about Python float ;-/
Maybe there should be guidelines for teaching what is not understood,
so that bright kids don't get cynical too fast.
>*learned*, are hard to forget or to stumble over. Even if such semantics
>are 100x harder to teach at first, fine by me: you spend the rest of your
>life living with the consequences. I wish the definition of continuity were
>easier to teach too, but that doesn't mean I'll settle for an easier
>definition that doesn't actually work <wink>.
>
You teach that? How many are you, anyway? ;-)
Grant Edwards
>First of all, it's really ugly. It's the ugliest thing in python for a newbie,
>imho. Yes, 1/2 is 0. You have to type 1.0/2 to get 0.5. No, there is no good
>reason for that, just memorize it. Ugh.
There _is_ a good reason. 1 and 2 are integers. How many 2s
can you fit into a 1?
None.
Zero.
--
Grant Edwards grante Yow! Can you MAIL a BEAN
at CAKE?
visi.com
Grant Edwards
>It shouldn't be so hard to understand why. The current integer division
>loses information silently and without a trace.
No, it doesn't. Integer division is integer division. The
correct answer for the value of 3/4 is 0. If you wanted the
remainder, you should ask for it. If you want to divide
floating point numbers, you should _use_ floating point numbers.
Perhaps my mind was warped by using nothing but integer
arithmatic in my software for many years because floating point
was simply too slow and too expensive.
--
Grant Edwards grante Yow! Are we THERE yet? My
at MIND is a SUBMARINE!!
visi.com
Tim Peters
> ...
> The audience was entirely self-selected;
Unlike, say, the participants in this discussion? Hmm. You set a rather
high standard here, Martijn <wink>.
? they were people with an interest in numeric models.
Or uninterested in Stackless (its "competition" in that time slot). I
suppose the next time we want advice about Unicode, we should just ask
Americans.
> Did Guido ask for a show of hands in the big session afterwards?
No, not on this issue.
> I don't recall; I kind of suspect the outcome would've been different.
I actually think 1/2==0 bothers "the general" population more than those
with a keen interest in numerics. Indeed, nobody with a keen interest in
numerics has bugged Guido about this except Moshe, that I know of; the most
visible repeated pressures have come from educators using Python as a means
to some other end.
>> The current integer division loses information silently and without a
>> trace combined with that Python is not a statically typed language,
>> there's simply no telling what e.g.
>>
>> def velocity(distance, time):
>> return distance / time
>>
>> will compute by inspection.
> There's no telling what:
>
> def add_stuff(a, b):
> return a + b
>
> will compute by inspection either, though.
You chopped all my following text, saying that the velocity() example wasn't
about user-defined overloadings but about ordinary arithmetic on the builtin
numeric types. A user trying e.g. velocity(3, 2) is simply going to be
surprised -- as countless newbies have testified on c.l.py over the years.
> ...
> For working with pixels in GUIs and such, integer division can be a
> useful thing, though.
It can be useful for many things; that's not at issue, and nobody has ever
proposed taking away the ability to get an integer result; the issue is how
to spell that.
David Eppstein
"Tim Peters" <tim...@home.com> wrote:
> A user trying e.g. velocity(3, 2) is simply going to be
> surprised -- as countless newbies have testified on c.l.py over the years.
My intuition is that the users who will be surprised that 1/2 = 0 are the
same ones who would be bitten by roundoff-error bugs if 1/2 = 0.5.
Result: buggier code since the errors are less obvious.
If you have a routine "velocity" in which it doesn't make sense to do
integer truncation, and it doesn't coerce its args to float by adding 0.0,
that's also a bug.
James Logajan
> Guido hears all the
> complaints, and he's become convinced that this is a genuine and serious
> flaw in the language: the current rules are *unusable* for too many people
> too often. If you're not one of them, congratulations <wink>. I'm not
> either -- I never get burned by this. But I see plenty of people who are,
> and they're neither stupid nor careless; it's a common blind spot, so it
> doesn't really matter that it's not one I (or you) suffer.
Well, having learned one set of expectations, I can say that I WILL suffer
some pain if this is changed. And it isn't a case of an expectation carried
over from another language!
Speaking of patterns, it unfortunately appears that Guido has a strong
tendency to take the existing user base for granted, since he continues to
keep the door open to code-breaking changes. There is only so much insult
("well, what you were doing was bad style anyway," or "you shouldn't have
written code that depends on integer division(!)") and injury (the more
Python you've written, the more likely something you wrote wont work with
the latest version and will need to spend hours reviewing,
just-in-case-anyway) before one decides that it just isn't worth the pain.
I do not want to continue to write more Python and expose myself to further
risk of having it either become dependent on an un-maintained and minority
release (e.g. "sorry, you should have upgraded to 3.1 years ago; who writes
stuff on 2.1 these days anyway?") or having a growing body of code to
constantly shepherd along to insure it runs on the next release.
That is the pragmatics from my point of view. And it doesn't give a damn
what real or perceived "flaw" in the language is being addressed.
Jan Dries
> No, it doesn't. Integer division is integer division. The
> correct answer for the value of 3/4 is 0. If you wanted the
> remainder, you should ask for it. If you want to divide
> floating point numbers, you should _use_ floating point numbers.
>
> Perhaps my mind was warped by using nothing but integer
> arithmatic in my software for many years because floating point
> was simply too slow and too expensive.
Upon reading this and other threads on the subject I wondered why
apparently a number of people find 3/4 giving 0 odd, while I don't
remember ever having and certainly don't ever make a mistake against it.
But now I realise why. I too for many years used nothing but integers
because fp was, indeed, simply too slow. I even remember calculating
bezier curves for vector font outlines using only +, >> and << on ints,
because even integer multiplication was too slow.
Jan
Robin Becker
<mos...@zadka.site.co.il> writes
>On Sun, 22 Jul 2001 13:24:22 -0700, Erik Max Francis <m...@alcyone.com> wrote:
>
>> I agree. It's turning an otherwise fairly strongly (but dynamically)
>> typed language on its head. If I want type-changing operations, I'll do
>> them explicitly.
>
>Be sure to tell math.cos that...it has been "silently" turning integers
>into floats for years.
coercions and the like are a separate issue. the cos of 1.0 , 1/1 and 1
are all the same so it makes some sense to allow a conversion.
The 1/2 == 0 case is just as good if not better than the 1/2 == 0.5
case, it's probably slightly worse than the rational result case, but we
have many languages which treat integer division like python currently
so I would argue that it has some extra merit.
We hear many criticisms of basic on this list, but Dartmouth basic was
originally a teaching language. When I taught basic, C didn't exist and
Fortran, Algol and the like were considered too hard for non-programmer
university students.
The leadership seems to want to python become more available to a lower
grade of student than first year undergraduates.
I think that is wrong, but I use python in a professional capacity. I
think languages succeed or fail because they work for programmers.
Division in computers is always discrete (unless we ever manage to get
quantum things working).
--
Robin Becker
Erik Max Francis
> Be sure to tell math.cos that...it has been "silently" turning
> integers
> into floats for years.
Sure, but that's something different. The domain of math.cos (and so
on) is floats, not ints, so if you pass it an int you very sensibly get
coercion to an float, because that's what you must have really meant.
That's quite different from the current case, where we're talking about
an operation that will return different types depending on the inputs.
I don't see any good reason to change the current behavior; / means
division over the types that are passed in. If you pass in floats, you
want float division. If you pass in ints, you want integer division.
> Err.....problem with the URL?.
Sorry, lazily pasted something into my .sig database. It was meant to
be:
http://www.alcyone.com/max/lang/esperanto/
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
/ \ When the solution is simple, God is answering.
\__/ Albert Einstein
REALpolitik / http://www.realpolitik.com/
Get your own customized newsfeed online in realtime ... for free!
Tim Peters
> The current integer division loses information silently and without
> a trace.
[Grant Edwards]
> No, it doesn't.
Of course it does, but note that I'm using "information" in its technical
sense. Current int division is a many-to-one mapping, so necessarily loses
information. Loss of information is often a good thing (like, losing most
of the repetitions of these old arguments would be a good thing <0.5 wink>),
but silent loss by default is generally bad design.
> Integer division is integer division. The correct answer for the
> value of 3/4 is 0.
If Guido has his druthers, the correct answer for 3//4 will be 0. It's not
the *operation* but the *spelling* he's seeking to change.
> If you wanted the remainder, you should ask for it. If you want to
> divide floating point numbers, you should _use_ floating point numbers.
Whether 1/2 would return a float is still open.
> Perhaps my mind was warped by using nothing but integer arithmatic
> in my software for many years because floating point was simply too
> slow and too expensive.
Or maybe you needed integer semantics -- I can't guess. Doesn't much matter
to the current debate. If you bought a hand calculator that truncated
division results to integers, would you be happy with that? That's what
informs the expectations of the generations after us.
Tim Peters
> My intuition is that the users who will be surprised that 1/2 = 0 are
> the same ones who would be bitten by roundoff-error bugs if 1/2 = 0.5.
Anyone using floats will get bitten eventually; ditto anyone using
rationals, for that matter. This is a "lesser of evils" thing more than a
"good vs evil" thing.
> Result: buggier code since the errors are less obvious.
Perhaps; I don't know of evidence one way or the other, and don't put much
stock in "head arguments" predicting programmer behavior. I've never heard
that, e.g., Pascal programs were especially prone to numerical bugs (a
language in with 1/2 does return 0.5; and I did work on a vector Pascal
compiler for Cray Research, so it's not that I've heard nothing at all about
Pascal in numeric contexts). I haven't heard knocks against Algol 60 on
this count either, which for several years was the de facto standard for
publishing numeric algorithms (and in which int/int also returned a real; it
had a different operator for int division).
> If you have a routine "velocity" in which it doesn't make sense to do
> integer truncation, and it doesn't coerce its args to float by
> adding 0.0, that's also a bug.
According to who? Routines are often *used* in ways authors didn't
anticipate, and a dynamic language (like Python) encourages that. The
current rules for "/" work against it.
Tim Peters
> ...
> Speaking of patterns, it unfortunately appears that Guido has a
> strong tendency to take the existing user base for granted, since he
> continues to keep the door open to code-breaking changes.
I'd say it's more the case that people project their particular concerns on
to the entire Python user base, and somehow mistake disagreement for being
ignored. As I said before, Guido hears *all* the complaints, and, believe
it or not, the Python user base is composed of people, and people don't
agree. It's Guido's job to make the best sense he can out of conflicting
desires (including but not limited to his own).
> There is only so much insult ("well, what you were doing was bad style
> anyway," or "you shouldn't have written code that depends on integer
> division(!)") and injury (the more Python you've written, the more
> likely something you wrote wont work with the latest version and will
> need to spend hours reviewing,just-in-case-anyway) before one decides
> that it just isn't worth the pain.
Of course. Do you seriously think Guido is unaware of that? OTOH, do you
seriously think 100% backward compatibility is an absolute criterion, immune
from competition with other claims?
> I do not want to continue to write more Python and expose myself
> to further risk of having it either become dependent on an un-maintained
> and minority release (e.g. "sorry, you should have upgraded to 3.1 years
> ago; who writes stuff on 2.1 these days anyway?") or having a growing
> body of code to constantly shepherd along to insure it runs on the next
> release.
Your choice, but my guess is that Guido has done an excellent job of
maintaining backward compatibility so far (he burned me by changing
str(long) to stop producing a trailing "L", and I must have spent nearly 20
minutes recovering from that -- BFD).
> That is the pragmatics from my point of view. And it doesn't give a
> damn what real or perceived "flaw" in the language is being addressed.
OK, I'll save this msg for the next time you ask for a change <0.9 wink>
Erik Max Francis
> The leadership seems to want to python become more available to a
> lower
> grade of student than first year undergraduates.
>
> I think that is wrong, but I use python in a professional capacity. I
> think languages succeed or fail because they work for programmers.
> Division in computers is always discrete (unless we ever manage to get
> quantum things working).
I couldn't agree more. Certainly there's no reason for a language to be
deliberately opaque, but the goal of the language (except a language
primarily intended for education) should be for programmers to get their
job done.
A good beginning programming language is one that has a simple syntax
and straightforward rules to follow. Python already qualifies in that
capacity very well; I don't see any reasons to "dumb down" Python any
further in order to try to make Python easier for "non-programmers"
(non-programmers won't be programming anyway! :-) to use in areas where
the benefit to non-programmers will be questionable in the first place.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
Grant Edwards
>[Tim]
>> The current integer division loses information silently and without
>> a trace.
>
>[Grant Edwards]
>> No, it doesn't.
>
>Of course it does, but note that I'm using "information" in its technical
>sense. Current int division is a many-to-one mapping, so necessarily loses
>information.
Right, but the same is true for float division. Therefore, the
fact that integer division loses information isn't a valid
reason to prefer floating point division for the "/" operator
when it is used on two integers.
int + int => int
int * int => int
int - int => int
int & int => int
int | int => int
[so far, so good]
int / int => int
or
int / int => float
Which of the two is the least astonishing? In my mind, the
"int" result is the least astonishing, but like I said, I'm
quite used to using integer arithmetic, and if I want floats,
I use floats.
>Whether 1/2 would return a float is still open.
Right. IMO, having operators coerce their operands like that
is too much like the "magic" that goes on in Perl. I suppose
it's only a bit worse that 1/2.0 coercing the "1" to a float,
but I'm not too kean on _that_ either. ;) Quite a few hours of
debugging time could have been saved over the past 30 years if
1/2.0 wasn't legal in C.
I'd be pretty happy if mixing a float and an int threw an
exception. When I run lint on C programs, I usually want it to
complain about that sort of thing. I don't generally like types
changing "automagically" behind the scenes.
>Or maybe you needed integer semantics -- I can't guess. Doesn't
>much matter to the current debate. If you bought a hand
>calculator that truncated division results to integers, would
>you be happy with that?
Mine does. If it didn't I'd toss it in the trash. Of course
the operands are always integers, so it's not that surprising.
There's a way to get it to do floating point, but I don't do
that very often.
>That's what informs the expectations of the generations after
>us.
Kids these days...
--
Grant Edwards grante Yow! I'm in direct contact
at with many advanced fun
visi.com CONCEPTS.
Steve Williams
> [snip]
>
> > i-always-blamed-cauchy-and-weirstrass-for-tormenting-the-world-
> > with-epsilons-and-deltas-ly y'rs, Z.
>
> i-personally-blame-guido-for-letting-it-stand<wink>-ly y'rs - tim
Yes, yes. Let's stop nattering about wedging division into the ring of
integers (1/2 is undefined, not 0, right?) and get on with adding the
hyperreals to Python.
John W. Baxter
> > I agree. It's turning an otherwise fairly strongly (but dynamically)
> > typed language on its head. If I want type-changing operations, I'll do
> > them explicitly.
>
> Be sure to tell math.cos that...it has been "silently" turning integers
> into floats for years.
Not really the same thing, because within the range of int (on most
machines so far), no information is lost (always assuming we mean
double when we say float, which we seem to).
Also unlikely, in that the argument is in radians, and 1 radian (or 1.0
radian) isn't a particularly interesting value (at least for the things
I do..."broad on the starboard quarter" would be my more typical
approximation, although it's perhaps a half point off).
By the way, in .../lib/module-math.html (I keep my own copy on my end
of my 56K frame connection), it is not stated whether the input to
sin() (and the others where it applies) is degrees or radians. An
experiment is necessary, or a reference to my rapidly waning C
knowledge or a visit to the C standard (which I'd rather not do, for
reasons of marginal sanity).
>>> math.sin(1)
0.8414709848078965
is a conclusive experiment...which I had to run before making the "also
unlikely" claim.
--John
John W. Baxter
<tim...@home.com> wrote:
> Not all experienced programmers agree. At the last Python Conference, I
> moderated a 40-some person group discussion on conceivable changes to
> Python's numeric model, not advocating but keeping the participants from
> killing each other <wink>. The meaning of integer division wasn't the
> focus, but naturally came up. By show of hands, about 3/4ths of the
> participants agreed that 3/4 should not return 0, but rather *something* x
> such that x*4 had a better chance of being confused with 3 than with 0.
> There was no consensus on exactly what 3/4 should return -- rational or HW
> float or decimal float were the most popular alternatives.
I see a fairly strong argument there for starting out with a language
in which int / int --> float (or rational) and int // int --> int (or
int div int --> int).
I don't see it as a strong enough argument to overcome the fact that
the careful programmer will have to inspect every / in all the code,
before installing 2.3 or whatever version this happens in, to see
whether (a) it IS division, as opposed to the / in
'<a href="6/7.html">' (that's contrived...but possible) and if so
whether it has to be respelt as // (or div).
Some of them will; some won't: some of both outcomes indicate latent
errors in the code, so the inspection isn't completely wasted after
all.
And it may not be her code...she could be 3 or 4 people removed from
the creator, who is gone. [Another good thing about finding the latent
errors.]
It's true--as stated elsewhere--that Guido hears all the complaints.
It's also true that until recently there was no reason for Guido to
hear "Guido, thank you for defining int / int to be integer division,
because integer division is natural for my problem space." So he's
been getting a biased sample. Probably a fairly representative one
even so.
--John
Andy Salnikov
"Robin Becker" <ro...@jessikat.fsnet.co.uk> wrote in message
news:vyIKbWAP...@jessikat.fsnet.co.uk...
>
> I think that is wrong, but I use python in a professional capacity. I
> think languages succeed or fail because they work for programmers.
Yeah, completely agree. Personaly, if this change happens, it will be a big
revolt from Python for me. Not only for aesthetic reasons, simply because I
cannot rely on the language which dares to change the meaning of existing
operators. What do you think will be next? Change assignment to work like a
copy, because there are many people confused with the reference semantic? I
almost hear how manager staff saying: "Do you talk about that sh**ty snake
language which changes its rules every year? Don't even think about it in
our project!"
Guys, if you really need something returning floats for division, make it
new operator, I guess everyone could be made happy with 1/2 == 0 and 1//2 ==
0.5.
Cheers,
Andy.
Rainer Deyke
news:mailman.995848124...@python.org...
> [David Eppstein]
> > My intuition is that the users who will be surprised that 1/2 = 0 are
> > the same ones who would be bitten by roundoff-error bugs if 1/2 = 0.5.
>
> Anyone using floats will get bitten eventually; ditto anyone using
> rationals, for that matter. This is a "lesser of evils" thing more than a
> "good vs evil" thing.
"Good" would be a language without built-in support for non-integer numbers,
and therefore no source of confusion. Those who really need them could use
an extension module.
--
Rainer Deyke (ro...@rainerdeyke.com)
Shareware computer games - http://rainerdeyke.com
"In ihren Reihen zu stehen heisst unter Feinden zu kaempfen" - Abigor
Donn Cave
...
| By the way, in .../lib/module-math.html (I keep my own copy on my end
| of my 56K frame connection), it is not stated whether the input to
| sin() (and the others where it applies) is degrees or radians. An
| experiment is necessary, or a reference to my rapidly waning C
| knowledge or a visit to the C standard (which I'd rather not do, for
| reasons of marginal sanity).
|
| >>> math.sin(1)
| 0.8414709848078965
|
| is a conclusive experiment...which I had to run before making the "also
| unlikely" claim.
Right! and I don't think it's what the common folk expect either.
Someone should write up a PEP to change these functions to take
degrees (not on my account, but it would seem to be a potential
stumbling block for the uninitiated, wouldn't it?)
Donn Cave, do...@drizzle.com
Terry Reedy
issue,
Actually, it did seem to be an issue when a couple of people seemed to
suggest that some of us were mentally unbalanced in thinking that
integer quotients are the right and useful result for int/int.
>and nobody has ever proposed taking away the ability to get an
integer result;
> the issue is how to spell that.
And that issue was *not* spelled out in the PEP.
Actually, as I mention in my article today 'A use for integer
quotients', I thought that one version of the proposal *was* to take
away the current spelling without providing any replacement. That is
what I argued most strenously against.
I know that one version of the proposal was to provide an
*unacceptible* (to me) replacement -- div(i,j). Guido appeared to
maybe even favor it until I pointed out that an infix replacement
would make fixing current code *much* easier.
This gets to the issue of what is a proper PEP. Simply saying 'I
don't like the current situation; lets replace it with something' is
not, in my opinion. The only thing definite that I remember from
reading PEP 238 was to change the result of int/int to float. Then
maybe add div() [awful], div [possible], // [best in my opinion],
something else [???], or, at least by implication, nothing
[horrendous]. It is hard compare something definite (the current
situation, whatever it is) to a nebulosity, especially when the range
of alternatives floating around the nebula range from horrendous to
maybe ok.
If 238 had been written originally something like the following (which
it now is), I would have argued *much* less.
Situation: Python '/' currently overloads and confounds two arithmetic
operations: whole-number result division and fractional result
division. This confuses some people.
Proposal: Make '/' consistently mean fractional division and introduce
a new operator '//' for truncated-result division.
Acknowledgement: This semantic replacement is a bit different from
most any previous change to Python. Extra care will be needed to make
the transition as smooth as possible.
(Just noticed: http://python.sourceforge.net/peps/pep-0238.html
now proposes a *2 year* int/int warning period starting with 2.3. It
still needs a stipulation that someone write an intdiv checker to help
automate replacements.)
Terry J. Reedy
Donn Cave
...
| Of course, but computer numerics is a massive exercise in picking the
| general rules you want to preserve at the expense of others, and trading all
| that off against pragmatics too. Not losing information silently is also a
| Very Good General Rule, and even 745 binary fp arithmetic is better at
| meeting that one than current "/".
So would it make sense to also change the >> and << operators to
rotate shift? I mean, I sure wouldn't find that more useful, but
it does conserve information that the current shifts lose.
Donn Cave, do...@drizzle.com
Terry Reedy
make it
> new operator, I guess everyone could be made happy with 1/2 == 0 and
1//2 ==
> 0.5.
I can sympathize with the people who have suggested this alternative,
but it strikes me as making things worse in a way. The current
situation is this: '/' mixes two types of division -- fractional
result and integer result. This is fine with me, but I can understand
some having a problem.
Moshe's current proposal cleanly separates the two types: '/' will be
fractional result and '//' will be integer result (including
floor(float/float)). So 8/3 = 8.0/3.0 = 2.33333, while 8//3 = 2 and
8.0//3.0 = 3.0, which is the same to within type, just as 3+8 ==
(withing type) 3.0+8.0. (I am not sure about complex//complex since I
an not sure if floor(complex) is defined -- floor(x) + floor(y)*j?)
This is arguably what Python should have started with.
Adding '//' as a pure fractional division operator while '/' remains a
mixed division operator strikes me an unaesthetic and more confusing
than the current situation. Why the two half redundant operators?
newcomers might rightly wonder.
Terry J. Reedy
Moshe Zadka
> My intuition is that the users who will be surprised that 1/2 = 0 are the
> same ones who would be bitten by roundoff-error bugs if 1/2 = 0.5.
> Result: buggier code since the errors are less obvious.
The thing is, making 1/2=0.5 won't make the problem *worse*. Because
after two days of being baffled by 1/2=0, these newbies will eventually
figure out the solution float(1)/2. So, I'm just getting to show them
the buggy roundoff-error code *faster*, instead of making them suffer
for it. You want to fix *that* problem, you have to give easy to access
rationals.
> If you have a routine "velocity" in which it doesn't make sense to do
> integer truncation, and it doesn't coerce its args to float by adding 0.0,
> that's also a bug.
velocity(1+2j, 3)
--
gpg --keyserver keyserver.pgp.com --recv-keys 46D01BD6 54C4E1FE
Secure (inaccessible): 4BD1 7705 EEC0 260A 7F21 4817 C7FC A636 46D0 1BD6
Insecure (accessible): C5A5 A8FA CA39 AB03 10B8 F116 1713 1BCF 54C4 E1FE
Tim Peters
> Not all experienced programmers agree. At the last Python Conference, I
> the participants agreed that 3/4 should not return 0, but rather
> *something* x such that x*4 had a better chance of being confused
> with 3 than with 0.
[John W. Baxter]
> I see a fairly strong argument there for starting out with a language
> in which int / int --> float (or rational) and int // int --> int (or
> int div int --> int).
I don't consider a vote an argument. At best, since it was a visible show
of hands, it let everyone know who wasn't worthy to live due to voting the
wrong way <wink>.
> I don't see it as a strong enough argument
It's not an argument at all -- it was in response to Arther asking whether
experienced programmers would favor such a change (and, yes, some would).
> to overcome the fact that the careful programmer will have to inspect
> every / in all the code, before installing 2.3 or whatever version
> this happens in, to see whether (a) it IS division, as opposed to
> the / in '<a href="6/7.html">' (that's contrived...but possible)
Guido suggested building a tool on top of the tokenize module; it reliably
distinguishes "/" as an operator from all other occurrences of "/"; no false
leads.
> and if so whether it has to be respelt as // (or div).
I probably use integer division more than most, and that job looks trivial
to me -- but then I *understand* my algorithms, and "it's obvious" in each
case which I intended. If this happens, the transitional release should
also produce runtime warnings pinpointing lines where "/" is applied to
integer arguments, so if you've got good unit tests nothing will be missed.
> Some of them will; some won't: some of both outcomes indicate latent
> errors in the code, so the inspection isn't completely wasted after
> all.
>
> And it may not be her code...she could be 3 or 4 people removed from
> the creator, who is gone. [Another good thing about finding the latent
> errors.]
>
> It's true--as stated elsewhere--that Guido hears all the complaints.
> It's also true that until recently there was no reason for Guido to
> hear "Guido, thank you for defining int / int to be integer division,
> because integer division is natural for my problem space." So he's
> been getting a biased sample. Probably a fairly representative one
> even so.
Don't forget that this has been debated repeatedly over the course of
several years. Most people drop out of these things after the fifth time
<0.5 wink>.
what-i-can't-tolerate-is-making-division-case-sensitive-ly y'rs - tim
Moshe Zadka
> That's quite different from the current case, where we're talking about
> an operation that will return different types depending on the inputs.
> I don't see any good reason to change the current behavior; / means
> division over the types that are passed in.
It does? I fail to see why people assume that operations *have* to return
the type of their operands. In this case, succumbing to this rule means
that we violate much more important, IMHO, rules, like
>>> a==b
1
>>> c==d
1
>>> a/c == b/d
0
(the part before that is:
Python 2.1 (#1, Apr 27 2001, 01:24:08)
[GCC 2.95.3 20010219 (prerelease)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> a,b,c,d=1,1.,2,2.
Of course)
> If you pass in ints, you want integer division.
I do?
> Sorry, lazily pasted something into my .sig database. It was meant to
> be:
>
> http://www.alcyone.com/max/lang/esperanto/
Thanks!
Craig Markwardt
"Tim Peters" <tim...@home.com> writes:
> [John W. Baxter]
> > I see a fairly strong argument there for starting out with a language
> > in which int / int --> float (or rational) and int // int --> int (or
> > int div int --> int).
>
> I don't consider a vote an argument. At best, since it was a visible show
> of hands, it let everyone know who wasn't worthy to live due to voting the
> wrong way <wink>.
I'll decloak here for a moment. I'm an IDL user, as in Interactive
Data Language by RSI, but I mostly admire Python from afar, and read
the newsgroup. I can relate the community experience of the upgrade
between IDL version 4 and version 5.
In the new version, IDL gained an *optional* language change. IDL 5
allows users to subscript arrays with either the square brackets [] or
the round parentheses (). IDL 4 only allowed the round parentheses.
As a result of this, people began coding both styles. However, the
new style was not backwards compatible, so there was some
fragmentation. Some major standard libraries were, and are still,
maintained in two forms.
Overall, from introduction to acceptance, the change took about 2-3
years. This change was thankfully optional. I am very grateful that
I can still pull up useful IDL archive code from ten or more years
ago, written by someone long gone, and usually have it run
successfully.
Thus, I am dismayed to hear about a Python language change that will
*not* be optional, and which will break the function of existing code.
Doing so will eventually place people in the unenviable quandry of
either upgrading their Python interpreter, or tossing out a tried and
tested library module.
Other language enhancements, like nested scopes, add features at the
expense of resolving language ambiguities. The proposed integer
division change is an outright language change, and impacts a core
functionality: arithmetic. Quite frankly, I am baffled.
Craig
--
--------------------------------------------------------------------------
Craig B. Markwardt, Ph.D. EMAIL: crai...@cow.physics.wisc.edu
Astrophysics, IDL, whatever else
--------------------------------------------------------------------------
Tim Peters
> Of course, but computer numerics is a massive exercise in picking the
> general rules you want to preserve at the expense of others,
> and trading all that off against pragmatics too. Not losing information
> silently is also a Very Good General Rule, and even 745 binary fp
> arithmetic is better at meeting that one than current "/".
>
[Donn Cave]
> So would it make sense to also change the >> and << operators to
> rotate shift? I mean, I sure wouldn't find that more useful, but
> it does conserve information that the current shifts lose.
First explain what bitstring operations have to do with computer numerics.
You may as well as complain that, e.g., "del a[i]" loses information too.
Well, of course it does -- that's its purpose. Same thing with >>. << does
not lose info on longs, and it is indeed a source of bugs that it may lose
info on ints (the result is platform-dependent in Python).
Greg Ewing
>
> If I was told that experinced programmers might
> appreciate this change for any possible reason -
> I'd be quiet as a mouse.
I'm an experienced programmer, and I appreciate the
change on the grounds that different operations on
the same data should be spelled differently.
You may lapse into silence now. :-)
--
Greg Ewing, Computer Science Dept, University of Canterbury,
Christchurch, New Zealand
To get my email address, please visit my web page:
http://www.cosc.canterbury.ac.nz/~greg
Stephen Horne
wrote:
>discussed many times before. The summary of the argument in the PEP
>may not be complete, but I disagree with Arthur's assessment that
>integer division is not a problem -- the VPython folks have ample
>experience that it is.
The PEP says virtually nothing. It simply claims that 1/2 giving 0
creates a hump in the learning curve. The only questions answered are
the ones about not creating a div keyword or function - which I don't
believe anyone is contesting.
The bit about coercing to floats rarely if ever happens - if you are
dealing with float values then that is most likely what the variables
you are using hold. If you need a float literal, all it needs is to be
written as a float - simple, clear and it works.
I doubt that anyone ever got through school without learning about
integer division and remainders - most children learn that before they
learn long division, let alone fractions and decimals, so all they
should need is a reminder.
People only experience their first day of something new *once*.
Really, this cannot be considered a problem. A five minute explanation
- if that - says all that needs to be said. Hell - even my mum
understands integer division, and she regularly confuses the size of
her machines RAM and hard disk!
Integer division is claimed to be a major stumbling block in user
testing - what does that mean exactly? Has formal user testing been
done? Just how confused were people? Were these the same people who
tried to put full stops and the end of their 'scentences'? Do you
simply count the frequency that a question is asked, or do you make an
allowance for how easily it is sorted out? Have you done *any* user
testing with the alternate implementation?
As for a few professional programmers occasionally making mistakes -
surely that means the vast majority get it right most of the time,
which suggests the current version is correct. There is a good chance
that those from Pascal and Modula 2 backgrounds who've rarely if ever
used other languages might be temporarily confused, and might get
things wrong a while after from force of habit. But what about all
those from C, C++, Java, Ada, BASIC - and don't forget, Visual BASIC
has been the most popular professional programming language for
several years - not to mention the VBScript and JavaScript used by all
those web developers, and even VBA in Microsoft Excel.
Pascal is a half dead language. It is currently achieving significant
success only as Delphi - a non-standard, single-vendor implementation
that - despite being a commercial product - has to be given away free
on magazine CD ROMs in order to keep people using it. Is that what we
want to emulate?
Surely the professional programmers who expect 1/2==0.5 are a
minority.
Look at all the algorithms that *require* integer division to give an
integer result - anyone who has so much as binary searched an ordered
list or tuple is going to have *BIG* problems.
>Because all Arthur does is tick me off, I'll leave it at this -- maybe
>someone else can explain it all to him.
I have no idea about Arthur, but the PEP explains virtually nothing
about the reasons and the idea that it will actually be done scares
the hell out of me. After the time I spent convincing my employer to
let me use Python internally, you now want me to throw away all the
productivity gains and more trying to sort out the results of this
change - *and* you want me to explain it to my boss! Maybe a slightly
better reason is needed than 'newbies are often a bit confused for
five minutes or so'.
I don't remember ever contributing to threads on this topic before - I
just kind of assumed the idea was laughable on those occasions when
I've seen it, and I expect I usually missed it because I only
occasionally follow the group. I'll bet there are a lot of people like
me who never really believed this would happen, and are going to go
ballistic if it does.
If we can't rely on a fundamental operator to work the same from one
release to the next, then Python is going to be reduced to a joke. It
is going to be causing surprise bugs for years to come as people
upgrade there old 1.5.2 installations - many times, the programmer
will have since left the company and there won't be anyone there to
fix it. Just think of the impact that will have on Pythons reputation.
If there really needs to be a division operator that returns floats
with all-integer arguments, *that* is the new functionality and *that*
should be the new operator. The idea of a division operator that
returns an integer when given float arguments is just plain daft, so
the existing division operator works fine for integers whatever
viewpoint anyone takes.
If this is about people in the pro-PEP0238 camp not wanting to have to
use // for their precious operator - why the hell should it be forced
on the anti-PEP0238 camp?
Stephen Horne
>First of all, it's really ugly. It's the ugliest thing in python for a newbie,
>imho. Yes, 1/2 is 0. You have to type 1.0/2 to get 0.5. No, there is no good
>reason for that, just memorize it. Ugh.
No reason!
Every five-year-old knows that 5 divided by 2 is 2 remainder 1. What
is the problem?
Integer division *is* important. Confusing integers and floats is a
sign of sloppy thinking, and a clue that far more bugs are going to
result.
Furthermore, Python is unlikely to *ever* be the only computer
language, and most Python users use other languages as well - that is
the nature of scripting languages. Surely we should comply with
conventions used in the languages we know are unlikely to die - those
which are already popular multi-vendor languages, and those which have
such powerful single-vendor backing that they are unlikely to
disappear. That means the likes of C, C++, Java and Visual BASIC. And
what about the languages web developers are used to, such as VBScript
and JavaScript.
Stephen Horne
<saln...@inp.nsk.su> wrote:
>
>"Robin Becker" <ro...@jessikat.fsnet.co.uk> wrote in message
>news:vyIKbWAP...@jessikat.fsnet.co.uk...
>>
>> I think that is wrong, but I use python in a professional capacity. I
>> think languages succeed or fail because they work for programmers.
>
>Yeah, completely agree. Personaly, if this change happens, it will be a big
>revolt from Python for me. Not only for aesthetic reasons, simply because I
>cannot rely on the language which dares to change the meaning of existing
>operators. What do you think will be next? Change assignment to work like a
>copy, because there are many people confused with the reference semantic? I
EXACTLY.
I do, in fact, occasionally get confused by the reference behaviour in
Python - expecting copies and getting references and visa versa,
especially when I havn't used it for a while. I'm used to being
explicit about when I'm dealing with references, and occasionally
having something behave as a reference when I didn't tell it to can be
a surprise. But I wouldn't propose changing this in a million years -
too much code would break.
There is only one other way I'd accept this change quietly. Support
some kind of version declaration in source files - a bit like 'from
__future__ import', but not implying the new behaviour will be
standard in the next version up.
How about...
from __standards__ import v22_base, sloppy_thinking_division
It should not prevent the use of new constructs, but new semantics for
old syntax should only occur if requested.
It would still leave a bad taste, but at least it doesn't mean
spending months debugging code that currently works.
>Guys, if you really need something returning floats for division, make it
>new operator, I guess everyone could be made happy with 1/2 == 0 and 1//2 ==
>0.5.
Absolutely. I could *ignore* that ;-)
In fact, document '//' as the alternative for the traditional division
sign '÷'. If it really is for the benefit of newbie non-programmers to
delay the integer division lesson until it can really bite them -
maybe when they first learn binary searches and can't figure out why
theirs never terminates, for instance - then they are probably just as
shocked not to have a ÷ symbol anyway.
Stephen Horne
<mos...@zadka.site.co.il> wrote:
>On Sun, 22 Jul 2001 13:24:22 -0700, Erik Max Francis <m...@alcyone.com> wrote:
>
>> I agree. It's turning an otherwise fairly strongly (but dynamically)
>> typed language on its head. If I want type-changing operations, I'll do
>> them explicitly.
>
>Be sure to tell math.cos that...it has been "silently" turning integers
>into floats for years.
Implicit typecasting is not the issue. Even C and C++ support implicit
typecasting - that does not mean the integer operations give float
results, which is a completely separate issue.
Erik Max Francis
> It does? I fail to see why people assume that operations *have* to
> return
> the type of their operands.
It's not a requirement, but integer division is very frequently used.
An operation that's closed on the types of its arguments is always easy
to understand, consistent with many other programming languages that do
such integer division, and is already the way things work.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
/ \ There is nothing stronger in the world than gentleness.
\__/ Han Suyin
Erik Max Francis' bookmarks / http://www.alcyone.com/max/links/
A highly categorized list of Web links.
Stephen Horne
wrote:
Of course - and the chaos that would cause for people working with
engineering or mathematical notations where radians are natural
irrespective of the language or even the use of a computer should of
course be completely ignore ;-)
Stephen Horne
>Grant Edwards wrote:
>> No, it doesn't. Integer division is integer division. The
>> correct answer for the value of 3/4 is 0. If you wanted the
>> remainder, you should ask for it. If you want to divide
>> floating point numbers, you should _use_ floating point numbers.
>>
>> Perhaps my mind was warped by using nothing but integer
>> arithmatic in my software for many years because floating point
>> was simply too slow and too expensive.
>
>Upon reading this and other threads on the subject I wondered why
>apparently a number of people find 3/4 giving 0 odd, while I don't
>remember ever having and certainly don't ever make a mistake against it.
>But now I realise why. I too for many years used nothing but integers
>because fp was, indeed, simply too slow. I even remember calculating
>bezier curves for vector font outlines using only +, >> and << on ints,
>because even integer multiplication was too slow.
Surely it goes deeper than that?
Children learn to count integers very young, and they learn integer
division almost as soon as they start school. They learn about
remainders almost as soon. Fractions, decimals and scientific notation
don't come until much later. The confused expectation about getting
floats as a result instead of integers simply shows that a lot of
children forget the core principles on which their knowledge is based.
Tim Peters
- New math module radians() and degrees() functions.
Somebody quick add grads before Python becomes obsolete <wink>.
Tim Peters
> ...
> And what about the languages web developers are used to, such as
> VBScript and JavaScript.
Good thing you stopped before mentioning Perl (yes, 1/2 is 0.5 there) -- I'm
afraid the "mimic other languages" approach requires picking languages very
carefully if you want the illusion of consistency. By the way, 1/2 is also
0.5 in standard JavaScript:
http://www.el-mundo.es/internet/ecmascript.html
11.5.2 Applying the / operator
The / operator performs division, producing the quotient of
its operands. The left operand is the dividend and the right
operand is the divisor. ECMAScript does not perform integer
division. The operands and result of all division operations
are double-precision floating-point numbers. The result of
division is determined by the specification of IEEE 754
arithmetic:
yadda yadda yadda
produce-enough-frantic-arguments-at-random-and-some-are-likely-
to-backfire<wink>-ly y'rs - tim
Paul Boddie
> "Robin Becker" <ro...@jessikat.fsnet.co.uk> wrote in message
> news:vyIKbWAP...@jessikat.fsnet.co.uk...
> >
> > I think that is wrong, but I use python in a professional capacity. I
> > think languages succeed or fail because they work for programmers.
>
> Yeah, completely agree. Personaly, if this change happens, it will be a big
> revolt from Python for me. Not only for aesthetic reasons, simply because I
> cannot rely on the language which dares to change the meaning of existing
> operators. What do you think will be next? Change assignment to work like a
> copy, because there are many people confused with the reference semantic?
Indeed. I think there's a significantly underestimated danger of
widespread code breakage in making such a fundamental change to the
language. While it may be disappointing to learn, or even consider,
that numerous working programs today may somehow depend on the
semantics of the / operator as it stands, we must still respect that
this situation exists.
Of course, it is also possible that some programs out there are
actually flawed because integer division is taking place where the
author intended that "floating point division" should occur, and where
arguments to the / operator were not anticipated to be, but can be,
integer. However, it is not up to the language architects to fix
people's programs for them - those programs were written according to
well-defined rules, and it is the obligation of the language
architects to maintain those rules.
> I almost hear how manager staff saying: "Do you talk about that sh**ty snake
> language which changes its rules every year? Don't even think about it in
> our project!"
I can see people seriously suggesting a "pythonfork" project if the
debate gets any more intense. :-O
> Guys, if you really need something returning floats for division, make it
> new operator, I guess everyone could be made happy with 1/2 == 0 and 1//2 ==
> 0.5.
The most sensible suggestion yet! I was reading the previous messages
in this thread waiting for someone to suggest this, and it's about
time someone did! There's a lot of weight behind adding a new
operator, yet most people seem to advocate adding the // operator and
then *changing* the / operator... which is madness!
If beginners want an operator which behaves as they expect, they
certainly aren't going to have any preconceptions about what it's
going to look like - they are beginners, after all. Therefore, why
even bother suggesting changing the / operator? Just introduce // and
be done with it! Nothing gets broken, the beginners get their new
operator, and those wanting the C++ comment syntax in Python will just
have to be disappointed. ;-)
Paul
Steve Horne
>I can see people seriously suggesting a "pythonfork" project if the
>debate gets any more intense. :-O
I've had idle thoughts for some time about a language that would allow
you to define - within the language itself - the syntax and semantics
for sublanguages. Only the lexical rules would be fixed, though there
would need to be several built-in sublanguages - grammar and
translation definition, simple compile-time imperative and simple
run-time imperative being the obvious ones. The thought was originally
provoked by wanting to support many different paradigms efficiently
and concisely in the same language - if anyone comes up with a new
paradigm, they just create a library that defines a suitable grammar
and translation and, hey presto, anyone can use it without changing
languages, and without discarding code written for other paradigms.
It suddenly seems so much more like a practical idea.
>> Guys, if you really need something returning floats for division, make it
>> new operator, I guess everyone could be made happy with 1/2 == 0 and 1//2 ==
>> 0.5.
>
>The most sensible suggestion yet! I was reading the previous messages
>in this thread waiting for someone to suggest this, and it's about
>time someone did! There's a lot of weight behind adding a new
>operator, yet most people seem to advocate adding the // operator and
>then *changing* the / operator... which is madness!
Agreed - I already made the same suggestion in the 'Future division
patch available (PEP 238) thread.
>If beginners want an operator which behaves as they expect, they
>certainly aren't going to have any preconceptions about what it's
>going to look like - they are beginners, after all. Therefore, why
>even bother suggesting changing the / operator? Just introduce // and
>be done with it! Nothing gets broken, the beginners get their new
>operator, and those wanting the C++ comment syntax in Python will just
>have to be disappointed. ;-)
I'll live ;-)
--
Steve Horne
Home : st...@lurking.demon.co.uk
Work : s...@ttsoftware.co.uk
Martijn Faassen
> [Martijn Faassen]
>> ...
>> The audience was entirely self-selected;
> Unlike, say, the participants in this discussion? Hmm. You set a rather
> high standard here, Martijn <wink>.
This discussion is entirely self selected too. What I'm pointing out is that
your 3/4 number is fairly meaningless in this discussion.
> ? they were people with an interest in numeric models.
> Or uninterested in Stackless (its "competition" in that time slot). I
> suppose the next time we want advice about Unicode, we should just ask
> Americans.
No, next time you want to point out why Unicode should be removed from the
language, you should mention that in a session with mostly Americans *about*
removing Unicode from the language (because it confuses newbies) that
3/4th of the people present wanted it removed.
>> Did Guido ask for a show of hands in the big session afterwards?
> No, not on this issue.
>> I don't recall; I kind of suspect the outcome would've been different.
> I actually think 1/2==0 bothers "the general" population more than those
> with a keen interest in numerics. Indeed, nobody with a keen interest in
> numerics has bugged Guido about this except Moshe, that I know of; the most
> visible repeated pressures have come from educators using Python as a means
> to some other end.
It bothers this member of the "general population" more that the semantics
of '/' will be changed rather radically at this point in the development of a
language. I don't see / as an educationally difficult concept compared to,
say, "all names in Python are references. Assignment is name rebinding, not
copying".
I wouldn't be arguing about this if we were designing a new language.
>>> The current integer division loses information silently and without a
>>> trace combined with that Python is not a statically typed language,
>>> there's simply no telling what e.g.
>>>
>>> def velocity(distance, time):
>>> return distance / time
>>>
>>> will compute by inspection.
>> There's no telling what:
>>
>> def add_stuff(a, b):
>> return a + b
>>
>> will compute by inspection either, though.
> You chopped all my following text, saying that the velocity() example wasn't
> about user-defined overloadings but about ordinary arithmetic on the builtin
> numeric types. A user trying e.g. velocity(3, 2) is simply going to be
> surprised -- as countless newbies have testified on c.l.py over the years.
I'm talking about string concatenation versus addition; no user-defined
overloading. "+" involves information loss when you use string concatenation;
the converse "-" operator isn't even defined for string concatenation.
"+" does two different things depending on what you pass in (strings or
numbers). "*" does so too. They both can be said to lose information.
Of course here we'd make the counter argument that "+" and "*" are entirely
different operations when we apply them to strings. But we can make a similar
argument for "/" (integers versus floats). That by itself is pretty common
in OO languages.
Anyway, this only to point out that "/" is not *that* specially weird.
My main argument has nothing to do with it, but everything about not wanting
to break a rather large amount of existing code. This isn't the makefile
scenario, either.
>> ...
>> For working with pixels in GUIs and such, integer division can be a
>> useful thing, though.
> It can be useful for many things; that's not at issue, and nobody has ever
> proposed taking away the ability to get an integer result; the issue is how
> to spell that.
The issue is also on whether you want to break all the existing integer division
code by changing the spelling, or not. You aren't designing a language in
a void here and this is a rather fundamental change to the core semantics.
Regards,
Martijn
--
History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?
Martijn Faassen
> On Sun, 22 Jul 2001 16:27:32 -0700, David Eppstein <epps...@ics.uci.edu> wrote:
>> My intuition is that the users who will be surprised that 1/2 = 0 are the
>> same ones who would be bitten by roundoff-error bugs if 1/2 = 0.5.
>> Result: buggier code since the errors are less obvious.
> The thing is, making 1/2=0.5 won't make the problem *worse*. Because
> after two days of being baffled by 1/2=0, these newbies will eventually
> figure out the solution float(1)/2. So, I'm just getting to show them
> the buggy roundoff-error code *faster*, instead of making them suffer
> for it. You want to fix *that* problem, you have to give easy to access
> rationals.
Will you introduce a special 'rational division' operator for that?
Or change the semantics of '/' again? :)
Guido van Rossum
> >and nobody has ever proposed taking away the ability to get an
> >integer result; the issue is how to spell that.
>
> And that issue was *not* spelled out in the PEP.
Funny, I just checked rev. 1.1 of PEP 238, and it contains the same
language about adding // as before. Maybe you never saw the PEP, but
assumed the worse based on the discussion?
> Actually, as I mention in my article today 'A use for integer
> quotients', I thought that one version of the proposal *was* to take
> away the current spelling without providing any replacement. That is
> what I argued most strenously against.
This was never considered.
> I know that one version of the proposal was to provide an
> *unacceptible* (to me) replacement -- div(i,j). Guido appeared to
> maybe even favor it until I pointed out that an infix replacement
> would make fixing current code *much* easier.
I originally favored //, but in an earlier round of discussions this
was opposed by folks based on its use for Java and C++ comments, so
for a while I considered alternatives. Not any more.
> This gets to the issue of what is a proper PEP. Simply saying 'I
> don't like the current situation; lets replace it with something' is
> not, in my opinion. The only thing definite that I remember from
> reading PEP 238 was to change the result of int/int to float. Then
> maybe add div() [awful], div [possible], // [best in my opinion],
> something else [???], or, at least by implication, nothing
> [horrendous].
You must misremember it.
> It is hard compare something definite (the current
> situation, whatever it is) to a nebulosity, especially when the range
> of alternatives floating around the nebula range from horrendous to
> maybe ok.
I find that most arguments against also appear to come from a nebula.
> If 238 had been written originally something like the following (which
> it now is), I would have argued *much* less.
Shall I rub it in? :-) Your bad reading skills (or bad memory) cost
you a great deal of stress. :-)
> Situation: Python '/' currently overloads and confounds two arithmetic
> operations: whole-number result division and fractional result
> division. This confuses some people.
> Proposal: Make '/' consistently mean fractional division and introduce
> a new operator '//' for truncated-result division.
> Acknowledgement: This semantic replacement is a bit different from
> most any previous change to Python. Extra care will be needed to make
> the transition as smooth as possible.
This is exactly what the PEP said all the time.
> (Just noticed: http://python.sourceforge.net/peps/pep-0238.html
> now proposes a *2 year* int/int warning period starting with 2.3. It
> still needs a stipulation that someone write an intdiv checker to help
> automate replacements.)
Hm??? I don't see that on the URL you give. Maybe you live in an
alternate universe where PEP 238 has a different contents than in mine?
--Guido van Rossum (home page: http://www.python.org/~guido/)
Steve Horne
wrote:
>case which I intended. If this happens, the transitional release should
>also produce runtime warnings pinpointing lines where "/" is applied to
>integer arguments, so if you've got good unit tests nothing will be missed.
Assuming that people realise they need to retest all those scripts
they've be using trouble-free for years.
I think you underestimate the number of people who will some day
figure that 1.5.2 is a bit old, install the latest version, and have
hell break lose over night when half their scripts stop working.
>Don't forget that this has been debated repeatedly over the course of
>several years. Most people drop out of these things after the fifth time
><0.5 wink>.
There's no point arguing these things if you don't believe anyone
would ever really do it. Now it looks like, after spending some time
advocating Python and talking people into letting me use it, suddenly
I'm going to look a right arse. I'll either have to warn everyone not
to upgrade because "the new version has serious compatability issues
with a basic arithmetic issue - nothing you wouldn't expect from *any*
language honestly - please stop laughing at me", or just hope like
hell that the problems aren't serious enough to get me the sack.
I couldn't find every copy of my scripts that's in use if I wanted to
- and besides, how am I going to justify having to suddenly take time
out to "fix the serious compatability issues with a basic arithmetic
operator in that language I kept insisting was so great".
Python advocates are going to end up looking pathetic. How long do you
think they'll carry on advocating Python?
Steve Horne
wrote:
>Your choice, but my guess is that Guido has done an excellent job of
>maintaining backward compatibility so far (he burned me by changing
>str(long) to stop producing a trailing "L", and I must have spent nearly 20
>minutes recovering from that -- BFD).
Of course - so far. In 2.2, the biggest issue is the new 'yield'
keyword, for instance - easy to fix, and not a problem for me because
I have a naming convention where identifiers always contain at least
one uppercase letter.
Changing the behaviour of a fundamental arithmetic operator is going
to ruin this record quite effectively, I think.
Integers are much more used in scripting code than floats - subscripts
and loop indices being the main culprits. Integer division happens
quite a bit. All that code is just going to suddenly stop working. How
nice.
Roy Smith
> Good thing you stopped before mentioning Perl (yes, 1/2 is 0.5 there)
Well, heck, in perl, "1"/2 is 0.5 as well. I'm sure there are lots of
people new to programming who gets confused when they discover that numbers
and strings are different too. Perhaps we should add auto-conversion of
strings to numbers to python as well? :-)
The thing that scares me most about this idea is that it breaks existing
code. And, the idea that there will be conversion tools, and auto-warnings
generated, don't impress me. You still need to touch all the old code.
What about code that you've shipped to customers already? Are we going to
demand that they not upgrade their python installation, or that they
maintain a new version for their own work and an old version to keep our
stuff going?
While, I happen to like the way integer division works, I could be
convinced that auto-promotion from int to float might be a good thing, if
that's the way the language had been defined in the first place. Too late
to go back now, however.
Robin Becker
Rossum <gu...@python.org> writes
....excuses etc elided
the pep no matter how written is still about breaking one of the
traditional arithmetic properties that has been carried into many
computer languages.
I am of the if it ain't broke don't fix it school. As others point out
explicit is better than implicit. int op int --> int is pretty easy to
remember as is the fact that mixed arithmetic promotes the lower
arithmetic operands.
The leadership is wrong on this and not for good reasons.
--
Robin Becker
Steve Horne
wrote:
>[]Stephen Horne]
>> ...
>> And what about the languages web developers are used to, such as
>> VBScript and JavaScript.
>
>Good thing you stopped before mentioning Perl (yes, 1/2 is 0.5 there) -- I'm
>afraid the "mimic other languages" approach requires picking languages very
>carefully if you want the illusion of consistency. By the way, 1/2 is also
>0.5 in standard JavaScript:
My mistake. However, the overwhelming majority of code is written to a
pattern where 1/2=0 - the simple fact Visual BASIC does it almost sets
the standard itself - and C, C++ and Java are hardly obscure.
I think you'll find it's the picking of languages where 1/2 = 0.5 that
has to be done carefully - I can think of Pacal, Modula 2, LISP and -
taking into account your correction - Perl and JavaScript. The last to
are enough to prove that your *opinion* is valid, those are not in use
to anywhere near the same extent as languages like C, C++, Java and
BASIC.
>produce-enough-frantic-arguments-at-random-and-some-are-likely-
> to-backfire<wink>-ly y'rs - tim
This argument still holds well enough on its own to prove that
changing the division operator is *not* an *undeniably* good thing -
it is at best a matter of opinion. *THAT* is all I need to prove - and
I have done so with several different arguments.
Furthermore it is not a random argument - it is a genuine concern with
no less validity than those in favor of 1/2 being 0.5.
Had Python started out differently, I'd still disagree but I wouldn't
be making a big issue. But this is a code-breaker of the worse kind -
it will create bugs in trusted programs that have been relied upon for
years without problem, which the programmers have forgotten about (if
the programmers are even still in the company) - and many of the bugs
may not even be obvious when they occur. And it will happen a *lot* -
division is *not* some obscure rarely-used feature, it is a basic
arithmetic operation.
The reward for advocating Python is apparently that you get to look a
complete idiot in front of your boss when everything you've written
goes pear shaped - *just* the kind of thankyou all the Python
advocates have been looking for, I don't think.
Steve Horne
<gr...@cosc.canterbury.ac.nz> wrote:
>Arthur...@rsmi.com wrote:
>>
>> If I was told that experinced programmers might
>> appreciate this change for any possible reason -
>> I'd be quiet as a mouse.
>
>I'm an experienced programmer, and I appreciate the
>change on the grounds that different operations on
>the same data should be spelled differently.
It's not a different operation on the same data. It's the same
operation on a different datatype. Floating point division simply
extends integer division to some extend past the point - quite
appropriate when dealing with floats, but extending a principle is not
the same as defining a fundamentally different operation.
You might as well claim floating point addition is different from
integer addition - that also requires a different algorithm and gives
a different result.
But that is only a small part of the problem. The real problem is
compatability.
You disagree? - then may the bugs of a thousand divisions infest your
code forever ;-)
Steve Horne
wrote:
>[Tim]
>> Of course, but computer numerics is a massive exercise in picking the
>> general rules you want to preserve at the expense of others,
>> and trading all that off against pragmatics too. Not losing information
>> silently is also a Very Good General Rule, and even 745 binary fp
>> arithmetic is better at meeting that one than current "/".
>>
>
>[Donn Cave]
>> So would it make sense to also change the >> and << operators to
>> rotate shift? I mean, I sure wouldn't find that more useful, but
>> it does conserve information that the current shifts lose.
>
>First explain what bitstring operations have to do with computer numerics.
Donn didn't claim any such relationship - Tim said that not losing
information is a very good *GENERAL* rule and Donn followed that logic
through quite effectively.
>You may as well as complain that, e.g., "del a[i]" loses information too.
>Well, of course it does -- that's its purpose. Same thing with >>. << does
The same applies to integer division - it is an inherently many-to-one
information-losing operation unless you include the remainder as part
of the result.
Chris Gonnerman
From: "Greg Ewing" <gr...@cosc.canterbury.ac.nz>
> Arthur...@rsmi.com wrote:
> >
> > If I was told that experinced programmers might
> > appreciate this change for any possible reason -
> > I'd be quiet as a mouse.
>
> I'm an experienced programmer, and I appreciate the
> change on the grounds that different operations on
> the same data should be spelled differently.
>
> You may lapse into silence now. :-)
Well, I'm an experienced programmer also, and I don't
appreciate the change. Ultimately that's the entire
reason... code written for 1.5.2 still works great in
2.1, and will work fine in 2.2 and apparently 2.3, but
will then fail in 2.4.
Suppose that I follow all this, dutifully finding and
fixing all the warnings in my modules as we move from
version to version; this is the plan, after all.
Now, here I am some years later and I look for a module
to do something or other, and on the Vaults I find one;
but the module (which may be huge) was written for 1.5.2.
I have to debug someone else's code (a big job even in
Python), find another source (if there is one) or write
the functionality myself.
If we don't screw with the integer division, I'm probably
in good shape. If we do, bang.
Changes that are mostly backwards compatible are cool,
but when something as fundamental as division of integers
changes, it gets pretty ugly.
Arthur Siegel
>>copy, because there are many people >>confused with the reference
semantic?
>EXACTLY.
To the extent anybody is interested in the first hand
experience of a novice programmer - rather than the
second hand report (made privately to the appropriate
authorities) of non-programmers - you happen to be
right near the mark of where some real issues lie.
To the extent anybody cares - and there is no particular
reason anybody should - the anger in my posts that Guido
interprets as directed toward him, is real anger. But not
meant to be directed at him.
Except to the extent that I feel he unwittingly collaborates
in the breakdown of community dynamics. Aloofness from
the community should count against, not for, one's cause -
whatever it happens to be.
PEP0238 is conclusionary as to the experience of novices.
Certainly its conclusions were not out of the experience of
its advocates. How were conclusions drawn before
the question was asked?
Why aren't the folks who drew and reported those conclusions
here to defend them, to the extent they are called into
question. Under the circumstances of considerable
controversy, at least.
Let the evidence stand up to at least a little scrutiny before
decisions are made based on it.
Why isn't some anger to be expected - or why doesn't the
leadership at least recognized how the dynamics here
are primed beautifully for an angry debate?
ART
Chris Gonnerman
From: "Roy Smith" <r...@panix.com>
> Well, heck, in perl, "1"/2 is 0.5 as well. I'm sure there are lots of
> people new to programming who gets confused when they discover that
numbers
> and strings are different too. Perhaps we should add auto-conversion of
> strings to numbers to python as well? :-)
If that were the rule in the first place (pre-1.5.2 at least) we wouldn't
cry about it (much).
> The thing that scares me most about this idea is that it breaks existing
> code. And, the idea that there will be conversion tools, and
auto-warnings
> generated, don't impress me. You still need to touch all the old code.
YES. This is my headache too. All the pro-PEP0238 people out there assume
that we will track version upgrades... but I upgraded several systems
directly
from 1.5.2 to 2.1. There's nothing to stop me from doing that with 2.4, and
then I'll be in a world of hurt.
> What about code that you've shipped to customers already? Are we going to
> demand that they not upgrade their python installation, or that they
> maintain a new version for their own work and an old version to keep our
> stuff going?
Ouch.
> While, I happen to like the way integer division works, I could be
> convinced that auto-promotion from int to float might be a good thing, if
> that's the way the language had been defined in the first place. Too late
> to go back now, however.
Much too late.
Consistent rules which are not *wrong* but only *different* should NOT be
changed this late in the game. I really don't think it takes that long to
teach a newbie about integer division; is saving 5 minutes times the number
of newbies out there really worth the man-hours of fixing the bugs and the
serious loss of face when we screw with a fundamental rule?
Steve Horne
wrote:
>Moshe Zadka <mos...@zadka.site.co.il> wrote:
>> On Sun, 22 Jul 2001 16:27:32 -0700, David Eppstein <epps...@ics.uci.edu> wrote:
>>> My intuition is that the users who will be surprised that 1/2 = 0 are the
>>> same ones who would be bitten by roundoff-error bugs if 1/2 = 0.5.
>>> Result: buggier code since the errors are less obvious.
>
>> The thing is, making 1/2=0.5 won't make the problem *worse*. Because
>> after two days of being baffled by 1/2=0, these newbies will eventually
>> figure out the solution float(1)/2. So, I'm just getting to show them
>> the buggy roundoff-error code *faster*, instead of making them suffer
>> for it. You want to fix *that* problem, you have to give easy to access
>> rationals.
>
>Will you introduce a special 'rational division' operator for that?
>Or change the semantics of '/' again? :)
There would certainly be three meanings of division - create a
rational from integers, do integer division *and* do float division.
Unless rationals were made into an independent type, some kind of
change would be necessary to support this.
If we just keep the same old division operator, the obvious thing
would be to define a rational type for which literals could only be
defined using integers or decimal notation, but supporting some
compile-time calculation. For instance...
Source Value in Bytecode
------ -----------------
3R 3/1
1.5R 15/10
1R/3 1/3
Simple predictable behaviour, and no-one gets rationals unless they
want them.
Symbolic calculations could be handled just as easily as a new type...
5S / 3
k * symbolicmath.exp (q)
In fact, doesn't Python now support overloaded operators for classes -
if so, all but the literals could be handled by a library right now if
someone writes it ;-)
Heres a thought - how about a set of declarations along the lines
of...
from __pragmas__ import numeric_literals_default_integer
from __pragmas__ import numeric_literals_default_longinteger
from __pragmas__ import numeric_literals_default_float
That way, anyone who is worried about accidental use of integers can
simply request their numberic literals default to floats and add a
suffix that specifies integer when they need an integer.
Steve Horne
wrote:
>Tim Peters <tim...@home.com> wrote:
>> [Martijn Faassen]
>>> ...
>>> The audience was entirely self-selected;
>
>> Unlike, say, the participants in this discussion? Hmm. You set a rather
>> high standard here, Martijn <wink>.
>
>This discussion is entirely self selected too. What I'm pointing out is that
>your 3/4 number is fairly meaningless in this discussion.
Anyway, we don't need to prove the Anti-PEP0238 opinion representative
- we only need prove the Pro-PEP0238 vote is not. In the absence of
good solid reasons for change, stability should be the rule. All the
reasons given for change are clearly a matter of opinion.
Steve Horne
wrote:
>I find that most arguments against also appear to come from a nebula.
They don't need to be any better than that - the anti-PEP0238 opinion
does not represent a serious code-breaking change, whereas the
pro-PEP0238 position does. All we need is to prove we have a valid
opinion - code-breaks, especially on this scale and relating to
fundamental arithmetic operations, should not be done on the basis of
a clearly debatable matter of opinion.
pi...@cs.uu.nl
DE> In article <eppstein-03540D...@news.service.uci.edu>,
DE> David Eppstein <epps...@ics.uci.edu> wrote:
>> Well then, float is a very bad choice for what to return, or then how do
>> we explain when 3/4 * 4 = 3 (exactly) but 3/10 * 10 != 10?
DE> Uh, of course I meant 3/10 * 10 != 3...
You have to explain it the same way as you explain that 3*0.1 != 0.3.
--
Piet van Oostrum <pi...@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP]
Private email: P.van....@hccnet.nl
Duncan Grisby
Guido van Rossum <gu...@python.org> wrote:
>The reason for wanting / to return a float (or at least a type that
>can represent close approximations of numbers like 0.75) has been
>discussed many times before. The summary of the argument in the PEP
>may not be complete, but I disagree with Arthur's assessment that
>integer division is not a problem -- the VPython folks have ample
>experience that it is.
Many people have mentioned the backwards compatibility issue. For me,
the main issue is related to that, but much more devastating. I
maintain libraries which have to work on a range of Python versions.
At the moment, I can have a single set of source files which work on
all versions. The various recent language changes don't affect that.
With this division change, I will either have to maintain two parallel
versions of the source, or make use of ugly and inefficient code which
works with both old and new versions of Python.
The reality is that the whole world will not switch Python versions
overnight, so everyone who maintains a library will have to face this
issue.
Cheers,
Duncan.
--
-- Duncan Grisby \ Research Engineer --
-- AT&T Laboratories Cambridge --
-- http://www.uk.research.att.com/~dpg1 --
Grant Edwards
>Situation: Python '/' currently overloads and confounds two arithmetic
>operations: whole-number result division and fractional result
>division. This confuses some people.
That's life. The foo[] overloads different operations also:
indexing into a sequence, looking up an element in a
dictionary.
What about the other overloaded math operators like "+", "-",
"*"?
Should "/" behave differently from the others?
Personally, I don't think so.
--
Grant Edwards grante Yow! I know things about
at TROY DONAHUE that can't
visi.com even be PRINTED!!
Grant Edwards
>On Sun, 22 Jul 2001 17:40:10 GMT, si...@optonline.net (Rainy) wrote:
>
>>First of all, it's really ugly. It's the ugliest thing in python for a newbie,
>>imho. Yes, 1/2 is 0. You have to type 1.0/2 to get 0.5. No, there is no good
>>reason for that, just memorize it. Ugh.
>
>No reason!
>
>Every five-year-old knows that 5 divided by 2 is 2 remainder 1. What
>is the problem?
>
>Integer division *is* important. Confusing integers and floats is a
>sign of sloppy thinking, and a clue that far more bugs are going to
>result.
Right. If you want redesign the language to prevent programmers
from creating bugs due to using the wrong numeric data types,
then you're only hope is to eliminate all but one of the
numeric types, and that numeric data type better do what
everybody expects all the time.
Can't be done.
--
Grant Edwards grante Yow! I always have fun
at because I'm out of my
visi.com mind!!!
Grant Edwards
>The reality is that the whole world will not switch Python versions
>overnight, so everyone who maintains a library will have to face this
>issue.
I maintain a couple small applications that have to support
1.5.2 and up. There must be plenty of people in the same spot.
--
Grant Edwards grante Yow! My polyvinyl cowboy
at wallet was made in Hong
visi.com Kong by Montgomery Clift!
Michael Abbott
news:mailman.995894318...@python.org:
>
> To the extent anybody cares - and there is no particular
> reason anybody should - the anger in my posts that Guido
> interprets as directed toward him, is real anger. But not
> meant to be directed at him.
>
> Except to the extent that I feel he unwittingly collaborates
> in the breakdown of community dynamics. Aloofness from
> the community should count against, not for, one's cause -
> whatever it happens to be.
Actually, I'm quite suprised at just how rude Guido is in his replies.
Just for the record, I think that PEP0238 is an extremely stupid idea, and
that the last thing Python needs is a deluge of half baked and incompatible
changes.
Marcin 'Qrczak' Kowalczyk
> It's not a different operation on the same data. It's the same
> operation on a different datatype.
No, it's different operation on the same data, as long as we agree that
"same data" means "Python's '==' holds".
3.0 == 3
2.0 == 2
3.0/2.0 != 3/2
> You might as well claim floating point addition is different from
> integer addition - that also requires a different algorithm and gives
> a different result.
They give the same result, except a very small rounding error
sometimes, and except where the integer addition doesn't give any
result because it overflows. If x and y are integers, then
float(x+y) == float(x)+float(y), with disclaimers above.
--
__("< Marcin Kowalczyk * qrc...@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
mch...@destiny.com
> I remain convinced that the single most important
> factor for Python's acceptance as an educational language is
> the growth of its acceptance as a professional language.
I have opinions on integer division, case sensitivity, and
probably on other issues where CP4E advocates seem to come
into conflict with some "professional programmers". But I
think I'll just keep quiet about my own opinions (which may
NOT be what you think) and let you think a minute on Arthur's
words.
-- Michael Chermside
mch...@destiny.com
> [...]
> Because all Arthur does is tick me off, I'll leave it at this --
> maybe someone else can explain it all to him.
Well, I'll see what I can do. In the language there are (at least)
two distinct things we might want to do when "dividing" A and B:
(1) split A up into B parts
(2) find how many B's fit in an A
A good example of (1) is float division, and the cannonical example
of (2) is "int division", aka "div". These are DIFFERENT THINGS.
For instance, if you are implementing a sort algorithm, you may
well want (2) in a place where (1) will never do! On the other
hand, if your program is performing CAD drawings, then (1) is
probably the meaning you need. Note that (2) often makes most sense
with integers (especially since it always gives out an integer),
while (1) may make sense with floats, rationals, fixed-position
decimals, as well as various other numerical types.
So I'm hoping that everyone reading this can agree, BOTH (1) and
(2) are USEFUL things, and a good language should allow BOTH. If
not, then please stop reading: there's no way I can convince you.
Given that you want both (1) and (2), there is just one problem:
the syntax "A / B" is the ideal syntax for BOTH of these purposes.
It's ideal for (1) because the mathematical operation of division
is traditionally represented with a "/", and it's ideal for (2)
because C and other languages have historically used "/" between
integers for (2). In my opinion (and those of quite a few others),
this is pretty lopsided: (1) is probably used more often, so it
should get priority, PLUS just imitating C isn't very convincing
since other languages (eg: Pascal) use other syntax, PLUS the use
of division in mathematics is far more widespread and well-known
than the use of "/" in C, PLUS the people who intend to use (2)
will probably be able to remember to use a different symbol. So
if you believe these arguments, then the next time you go out
and invent a new language, you'll use "/" to mean (1), not (2).
But Python is not a new language, and in existing versions of
Python, "/" has meant (2) if both arguments were integers. To
change this now is VERY bad, because it will break lots of
existing code. It probably won't be hard for existing programmers
to adapt, but having to repair all those old scripts is a VERY
BAD THING.
So Guido is trying to balance two things: the desire to use "/"
to mean (1) in all cases, regardless of the type of its arguments,
and the desire to keep Python stable, without breaking lots of
existing code. The issue is important because we often see
newbie bugs based on this issue, and because if the change is
EVER going to happen, it HAS to be soon... the longer he waits,
the more old scripts there are which will have to be broken.
In the end, after hearing all of the arguments (and if you haven't
spoken up yet I STILL suspect someone else has made your argument
for you before in a previous usenet thread), Guido has apparently
decided that the design improvement is worth breaking old scripts.
Obviously, that means that tools and techniques (warnings, type
inferring source checkers, etc) need to be provided which will
help in that transition... but it'll still be painful. Guido is
well aware of that, and I'm sure he approaches this with
reluctance. But remember, there's a GOOD side too! After the
trasnsition is over, the language will be (in one small way) even
better than before.
-- Michael Chermside
mch...@destiny.com
Skip Montanaro
Tim> Why is that? It's because unlike any other builtin arithmetic
Tim> operation, "/" today can cause *catastrophic* loss of information
Tim> silently, and in ordinary cases.
Catastrophic is in the eye of the beholder. I would find it just as
catastrophic if this
x = len(somelist)/3
resulted in a floating point answer. With integer division I haven't lost
anything, because if I want the remainder I can just execute
y = len(somelist)%3
If I want to insure a floating point result I can just use the builtin
float.
I suspect that most people resistant to this change share the following two
traits:
* a large body of code to maintain
* most arithmetic they do in Python is non-scientific - implied by few
imports of the math module in their code
I took a quick peek at my code. Out of 360 Python source files, the math
module is imported just six times. Two of those imports are in versions of
Digital Creations' DocumentTemplate module, which I didn't write, just
forked for private use, one was in a trivial test script, and one was a
spurious import (it was imported but not actually used). That leaves two
files written by me that use math. I only found calls to the float builtin
in 16 files. I suspect that most people who are advocates of the change
proposed in PEP 238 either are numerical folks or don't have much code that
will break. Numerical folks probably import math about as frequently as sys
and sprinkle their code liberally with calls to float().
S
Skip Montanaro
Tim> Indeed, nobody with a keen interest in numerics has bugged Guido
Tim> about this except Moshe, that I know of; the most visible repeated
Tim> pressures have come from educators using Python as a means to some
Tim> other end.
I'm not a denizen of the edu-sig list, but Guido has mentioned the Alice
folks (I think they are the ancestors of the VPython folks) before as a
significant influence on his ideas about this subject. Perhaps you would
class them as educators and not numeric people, but I would throw them in
the numeric camp.
Skip
Tim Hochberg
"Tim Peters" <tim...@home.com> wrote in message
[SNIP]
> Indeed, nobody with a keen interest in
> numerics has bugged Guido about this except Moshe, that I know of; the
most
> visible repeated pressures have come from educators using Python as a
means
> to some other end.
[SNIP]
Hey, I'm one of those people with a keen interest in numerics who hasn't
bugged Guido about this yet. Let me rectify the situation. First off a
disclaimer, I don't claim to be a hard core numerical analysist of any
sort -- I'm an engineer of sorts and I know just enough numerical analysis
to get myself into trouble. I do use python almost entirely for numerical
work and have been using it since way back in version 0.9.2 or so.
Let me stray from the topic for a paragraph here: I'm astounded to discover
the number of people pining for integer division that truncates towards
zero. That sort of integer division is horriible. When programming in C, I
always had to simulate Python's behaviour in order to get code that might
take both positive and negative integral values to work correctly. Python
gets this exactly right.
Back to the topic, more or less: I've been astounded by way the arguments
against this has played out. I expected the opposition to say more or less,
"It's a small problem at worst, and it will break 10 zillion lines of code,
and will be a huge pain to upgrade, so it's just not worth it". Instead, the
talk of code breakage has been suprisingly small and there seems to be a
fair number of people claiming that the current mixed behaviour is a _good_
thing. I couldn't disagree more. C-style division in a dynamically typed
language is an accident waiting to happen. And does this mean that code
breakage won't be as large and/or painful as I thought it might be? It also
seems that a lot of the people most vociferously opposed to the PEP have
very little idea what's actually in it. In particuluar, there seems to be
many out there who seem horrifed at the prospect of integer division going
away even though this was never proposed.
Anyway, not being an educator, I'm not particularly concerned with whether
integer division is easy or hard to learn. I like the proposal because there
just isn't a good way currently to spell
divide-these-two -numbers-using-normal-division. The fact that oponents of
this proposal keep suggesting methods for doing this that are wrong only
reveals that this is more difficult than generally supposed.
Consider the completely unsafe function:
def simple_func(x, y):
return y / x**2
It has been suggested as recently as this morning, I believe, that this be
rewritten:
def simple_func(x, y):
return y / float(x)**2
This is simple, clear and ... wrong, as Konrad Hinsen pointed out several
days ago. At least it's wrong if complex numbers are ever a possibility. One
could instead write it using complex(x), but one generally does not want to
convert to a complex number unless the inputs are complex, so that solution
is unsatisfactory. A more correct solution suggested by Konrad is:
def simple_func(x, y):
return y / (x+0.0)**2
This is correct, but can hardly be called simple or clear. Also, in the
context of Numeric Python, where x and/or y may be an array, the above code
may be inefficient in time and extremely inefficient in space. It's possible
of course to work around this, but it becomes even less simple and clear.
Time to stop before I get too inflamatory,
-tim
Erik Max Francis
> Good thing you stopped before mentioning Perl (yes, 1/2 is 0.5 there)
> -- I'm
> afraid the "mimic other languages" approach requires picking languages
> very
> carefully if you want the illusion of consistency.
Only fairly strongly-typed languages are relevant here. Perl doesn't
have a concept of types at this level, so 1 and 1.0 and even "1" are all
the same thing.
> By the way, 1/2 is also
> 0.5 in standard JavaScript:
I wouldn't think how JavaScript does things would be a valid defense in
any case.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
/ \ I wonder if this grief will ever let me go
\__/ Sade
blackgirl international / http://www.blackgirl.org/
The Internet resource for black women.
Jim Abrams
<916olt0p3kciv0evm...@4ax.com>:
>Had Python started out differently, I'd still disagree but I wouldn't
>be making a big issue. But this is a code-breaker of the worse kind -
>it will create bugs in trusted programs that have been relied upon for
>years without problem, which the programmers have forgotten about (if
>the programmers are even still in the company) - and many of the bugs
>may not even be obvious when they occur. And it will happen a *lot* -
>division is *not* some obscure rarely-used feature, it is a basic
>arithmetic operation.
>
>The reward for advocating Python is apparently that you get to look a
>complete idiot in front of your boss when everything you've written
>goes pear shaped - *just* the kind of thankyou all the Python
>advocates have been looking for, I don't think.
Because every camel has its straw, I need to agree here. I, and most
of my python buddies, fight with bloodstained teeth and nails to get
python in our projects and developments. I can't see winning too many
arguments when my opposition can pull out 'the division operator' to
shoot me down. I can't see budgeting time and people to making sure
the division operator works after an upgrade. I'd be laughed into data
entry ;).
Options such as // for the new semantics, keeping / as integer div
seem quite reasonable. Or even allowing / to be used with the new
semantics given some "from __something__ import something" seems very
acceptable. And not just as a stepping stone to future versions, as a
permanent change to how the interpreter works.
Reading the points people make keeps reminding me of a joke.
A Mathematician, an Engineer and a Physicist are hunting in the woods.
The come upon a trophy buck. The Physicist shoots and the shot is 5
feet too low. He mumbles about improper air resistance and drag.
The engineer then fires and the shot is 5 feet too high. He mumbles
about overcompensating for environmental variables.
The mathematician looks left at the Physicist, right at the Engineer
and exclaims, "You got him!"
Jim
Steve Horne
<michael....@ntlworld.com> wrote:
>"Arthur Siegel" <a...@ix.netcom.com> wrote in
>news:mailman.995894318...@python.org:
>
>>
>> To the extent anybody cares - and there is no particular
>> reason anybody should - the anger in my posts that Guido
>> interprets as directed toward him, is real anger. But not
>> meant to be directed at him.
>>
>> Except to the extent that I feel he unwittingly collaborates
>> in the breakdown of community dynamics. Aloofness from
>> the community should count against, not for, one's cause -
>> whatever it happens to be.
>
>Actually, I'm quite suprised at just how rude Guido is in his replies.
Here I do disagree, though I was rather annoyed once when I
*complemented* Python by saying that, although I was initially
sceptical about list comprehensions, I actually found them very useful
- and rather than accepting the complement he twisted that single case
into a character judgement where I was supposed to be *always* be
excessively judgemental about things and blatantly about to burst a
blood vessel.
For those who have been reading my current posts, until a couple of
days ago I have *never*, IIRC, posted any serious criticism of Python.
I've commented occasionally on alternate views, but never said Python
was flawed. I have, in fact, often spoken in defence of the Python way
- though admittedly I don't often follow the group at all.
Anyway, in general Guido handles the benevolent-dictator role
extremely well - it has to be extremely frustrating in the position he
is in, and I'm surprised he has been generally as polite as he has.
I hope he sees my current posts as they are intended - I see PEP0238
as being something worthy of extreme scepticism if not outright
terror. But I only care at all because Python *is* a good and
worthwhile thing, and as a result I have been a very vocal advocate in
my company.
Fortunately, I only have to worry about internal things - some people
have to worry what happens on customers sites and - presumably, with
todays free software attitudes - on the sites of customers of
customers that they've never even had contact with.
However, the day when the support staff have to say "sorry, I know we
could do that last week, but nothing works any more and it'll take a
few months before this thing reaches the head of the debugging queue"
to a customer - or worse, they don't realise it doesn't work any more
and tell the customer a completely erroneous result - is NOT a day I'm
looking forward to.
Erik Max Francis
> Because every camel has its straw, I need to agree here. I, and most
> of my python buddies, fight with bloodstained teeth and nails to get
> python in our projects and developments. I can't see winning too many
> arguments when my opposition can pull out 'the division operator' to
> shoot me down. I can't see budgeting time and people to making sure
> the division operator works after an upgrade. I'd be laughed into data
> entry ;).
Indeed. If this is implemented, it will be a black eye for Python. Any
anti-Python advocate will be able to point at this and say, "Look,
that's why you shouldn't switch to Python. The semantics of the builtin
operators changes from release to release." Problem is, they will be
absolutely right.
Skip Montanaro
Terry> now proposes a *2 year* int/int warning period starting with 2.3.
Terry> It still needs a stipulation that someone write an intdiv checker
Terry> to help automate replacements.)
Here's a quick div finder (got some off-by-one errors trying to track
NEWLINE tokens, hence the self.line hack).
Skip
import tokenize
import sys
class TokenSorter:
def __init__(self, f):
self.tokens = {}
self.filename = f
self.line = ""
self.linenumber = 0
self.lastprinted = 0
def tokeneater(self, typ, val, (sr, sc), (er, ec), line):
if self.line != line:
self.linenumber += 1
self.line = line
if (tokenize.tok_name[typ] == "OP" and
val == "/" and
self.lastprinted != self.linenumber):
print "%s(%d): %s" % (self.filename, self.linenumber,
line.rstrip())
self.lastprinted = self.linenumber
def main():
for fn in sys.argv[1:]:
try:
f = open(fn)
except IOError:
pass
else:
ts = TokenSorter(fn)
try:
tokenize.tokenize(f.readline, ts.tokeneater)
except tokenize.TokenError:
pass
if __name__ == "__main__":
main()
Ben Wolfson
wrote:
>Integers are much more used in scripting code than floats - subscripts
>and loop indices being the main culprits. Integer division happens
>quite a bit. All that code is just going to suddenly stop working. How
>nice.
If integer division is more common than float division, why not let '/'
retain its current meaning and use '//' for "yes, I want a float result"?
int / int -> int
float / int, int / float, float / float -> whatever these currently mean
with "//" in Guido's patch
int // int -> float, rational, or whatever
--
Barnabas T. Rumjuggler
No man can run so fast that he can escape his own past's projectile vomit.
Roy Smith
> Tim> operation, "/" today can cause *catastrophic* loss of information
> Tim> silently, and in ordinary cases.
Surely assignment causes catastrophic loss of information, no? If I
say "x = 4", havn't I lost the old value of x? Multiplication by zero
causes catastrophic loss of information too. Should we redefine how
those operations work too?
Terry Reedy
eps/
"Guido van Rossum" <gu...@python.org> wrote in message
news:cp3d7ng...@cj20424-a.reston1.va.home.com...
> "Terry Reedy" <tjr...@home.com> writes:
>
> > >and nobody has ever proposed taking away the ability to get an
> > >integer result; the issue is how to spell that.
> >
> > And that issue was *not* spelled out in the PEP.
>
> Funny, I just checked rev. 1.1 of PEP 238, and it contains the same
> language about adding // as before. Maybe you never saw the PEP,
but
> assumed the worse based on the discussion?
I just discovered how to access older versions of PEPs and checked
1.3, which I at least partly read and you are right. My view and
memory of the PEP was distorted by anti-int-div float-div-religion
being pushed as fact by the PEP author and some other proponents, who
continue to this day. Some current examples nearly identical to
several previous attempts:
* "Many other languages do division correctly - Scheme, Perl and Tcl,
for instance." My claim: this is a religious statement. Obvious
implication of such statements: Python currently does division
wrongly. Subtler implication in at least some statements of this
sort: it is not intelligent to advocate that Python continue doing
division wrongly.
* "Integer division is a lousy tool in this particular example.."
[converting bytes to Kbytes]. Combined with the previous line, this
response denies the possibility of using (bytes + k/2)/k to round (or
that the original poster would have known how to do so) and claims
that int(float(bytes)/float(k)+.5) is factually better. I disagree.
* "Nobody said [int division] wasn't of any use, people just claim it
is *less* useful, and so should not be the most easily accessible."
(from Moshe himself, last night). Since in any situation the most
useful form of division is the one that most easily gives the correct
answer, the premise is incorrect. So why do proponents even now keep
repeating an incorrect and unnecessary claim to justify the change?
Since the difference between '/' and '//' is too trivial to hardly
discuss, I tend to interprete the 'conclusion' to be an attempt, even
now, to justify something that really would be less accessible and
more obnoxious than '//', like div(i,j) or divmod(i,j)[0]. When
proponents of the change keep trying to justify making int div less
accessible, is it any wonder that people think that that is what they
really intend?
[snip]
> > If 238 had been written originally something like the following
(which
> > it now is), I would have argued *much* less.
>
> Shall I rub it in? :-) ...:-)
Since I just recently accepted the long-term desirability of the
change, you're treading on thin ice. But since you added two smileys
to make sure I saw at least one, I'll take this as good-natured
ribbing.
> > Situation: Python '/' currently overloads and confounds two
arithmetic
> > operations: whole-number result division and fractional result
> > division. This confuses some people.
> > Proposal: Make '/' consistently mean fractional division and
introduce
> > a new operator '//' for truncated-result division.
> > Acknowledgement: This semantic replacement is a bit different from
> > most any previous change to Python. Extra care will be needed to
make
> > the transition as smooth as possible.
> This is exactly what the PEP said all the time.
NO, NO, NO! Contrary to what I said above, it still does not. Moshe
writes,
"Rationale
The behavior of integer division is a major stumbling block ..."
This prejudiced view, which too many people have unnecessarily bundled
with the proposed change itself, is quite different from the
division-neutral rationale you quoted above, which locates the
'problem' in the conflict *between* the two meanings. To repeat:
'''
Situation: Python '/' currently overloads and confounds two arithmetic
operations: whole-number result division and fractional result
division. This confuses some people.
'''
which I would today follow with:
'''
Contention: Even though there will be many transition problems, it
will be in the long term interest of some current and many future
Python programmers to better separate the two meanings of 'division'.
'''
Proponents have pointed out that if someone writes a function like
def speed(distance, time): return distance/time
without checking inputs for conformance with preconditions and if
function users violate the preconditions (by feeding in two ints in
this case), the function will generally return a subtlely wrong
answer. Okay, but the same is just as true of
def minmaxpart(n,k): return (n+k-1)/k
The problem is the close overlap of the two meanings, not either in
itself.
I strongly recommend that the PEP Rationale (and Abstract) be
rewritten in a neutral manner starting with something like "The
conflict and confusion between the two closely related meanings of
number division is a stumbling block in the writing of correct Python
programs." In suggesting that a straightforward, if troublesome,
separation of meanings be divorced from attempts to assign blame to
one of the two meanings, I am attempting to help make the proposal
more palatable to those, like me, who do not and will not accept the
religious-philosophical views behind that assignment of blame.
> > (Just noticed: http://python.sourceforge.net/peps/pep-0238.html
> > now proposes a *2 year* int/int warning period starting with 2.3.
It
> > still needs a stipulation that someone write an intdiv checker to
help
> > automate replacements.)
>
> Hm??? I don't see that on the URL you give. Maybe you live in an
> alternate universe where PEP 238 has a different contents than in
mine?
Your sarcasism is improving, but look again:
'''
PEP: 238
Title: Non-integer Division
Version: $Revision: 1.6 $
...
Changing the Semantics of the / Operator
...
The warning will be off by default in the 2.2 release, and on by
default for in the next Python release, and will stay in effect
for 24 months.
'''
Shall *I* rub it in? ;-) In *my* universe, 24 months is (24/12 =) 2
years ;-)
> --Guido van Rossum (home page: http://www.python.org/~guido/)
Terry J. Reedy
Tim Peters
> ...
> The fact that oponents of this proposal keep suggesting methods for
> doing this that are wrong only reveals that this is more difficult
> than generally supposed.
>
>
> A more correct solution suggested by Konrad is:
>
> def simple_func(x, y):
> return y / (x+0.0)**2
>
> This is correct, but can hardly be called simple or clear.
In this specific case "x + 0.0" is correct, but in general it isn't: on
boxes with 754 arithmetic (virtually everything), x+0. has a different sign
bit than x when x is -0.0, and the default rounding mode is in effect. In
this specific case that doesn't matter because the result is immediately
squared, but in general you can't know that it doesn't matter. Safest is
x*1.0
which works in all cases -- maybe. There's still hardware out there that
flushes denormal results to 0, and on such boxes both x+0. and x*1.0 can
return 0 when x is not 0. Python inherits such behaviors from the platform.
So "this is more difficult than generally supposed" applies even to people
who know quite a bit about this stuff.
correctness-is-a-severe-requirement-ly y'rs - tim
Tim Peters
> I wouldn't think how JavaScript does things would be a valid defense in
> any case.
Neither would I, but in the context snipped away I was replying to someone
who seemed to think that it was, but misunderstood what JS actually does.
Even bad arguments should be accurate <wink>.
or-ignored-ly y'rs - tim
Marcin 'Qrczak' Kowalczyk
> "+" does two different things depending on what you pass in (strings or
> numbers). "*" does so too. They both can be said to lose information.
The difference between '+' and '/' is that ints aren't implicitly
converted to strings, so one wouldn't use an int instead of a string
expecting '+' to do the conversion and concatenation. But ints *are*
implicitly converted to floats when needed in about all contexts except
'/', so it would be reasonable to expect them to be converted in the
'/' case too.
In languages where ints are implicitly converted to strings, addition
and concatenation are typically different operators. Like in Perl:
'+' and '.'.
Python does treat ints and floats as different parts of the same
concept by letting them compare equal and convert as needed. So real
division and integer division should be distinguished by the operator.
To help with migration there can be old_div(x,y) function. That way
old / can be unconditionally replaced with old_div for a quick fix,
and it can be made nicer by saying explicitly which division is meant
when somebody has time to do it properly.
I still favor 'x div y' and 'x mod y', with '/' on ints giving
rationals, and with mixed rationals with floats giving floats.
Literals like 1.2 would continue to mean floats, so each type has
nicely spelled constants:
7 - int (unified with long in the future)
7/3 - rational
7.2 - float
Each time a float is expected, a rational would give the same answer
(perhaps in a different type or accuracy). Each time a rational
is expected, an integer would give the same answer (perhaps in
a different type).
'"%.02f" % a_rational' is a good way to output currency amounts.
'rational(a_string)' is a good way to input them.
Donn Cave
...
| I can see people seriously suggesting a "pythonfork" project if the
| debate gets any more intense. :-O
Has already happened, names proposed etc. I see you don't have time
to read all the threads, speaks well of you I might add.
Discussion seems a little futile at this point. People on both sides
are clearly dug in and there's nothing left to say. I don't think it's
time to start talking seriously about a fork project, but it looks like
a sure bet at some point. Though I think with the current size of the
Python base, we're talking about integer division - Python / 2 -> 0.
But that may only mean gradual extinction of Python in some of its
current roles, like for software that gets distributed sans interpreter.
If GvR & Co. actually get somewhere with the new Python and its target
audience, and Python3000 survives, it may still be attractive for
applications like prototyping.
I think the "tubes vs. transistors" lag in contemporary computing is the
difficulty of writing software in general in C/C++. Storage model leads
to buffer overflows, segmentation faults etc., laborious implementation
requirements make it too hard to fix a design after it's first coded.
Software for alternative platforms tends to not exist. Python could be
the revolution. But that's no safer bet than the CP4E gamble, and maybe
the latter is better for Python anyway. I'd like to see a language that
can make fast, self-contained compiled applications for the major platforms
and also interpret the same application on a new or obscure platform.
Donn Cave, do...@u.washington.edu