Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #70397
| References | (1 earlier) <7x8ur1esa5.fsf@ruckus.brouhaha.com> <CAPTjJmqAeuFnOmW890ykPkk4L7JpgYFtFpd6uk1xAXtt2MgBMw@mail.gmail.com> <CALwzidmk9ogErqsF9ghM4_Bi=+n2qwCTpqJ48exOgg+L-2Gd_Q@mail.gmail.com> <CAPTjJmqcr+ZhtRRxGtOVX6ppLd=1RyQ2yU9X=fFy4zH8oLrHyA@mail.gmail.com> <CALwzid=HrxL7kCwM5LOKEgwQT+YzrCH0xV57LXEjqU6jtsti=g@mail.gmail.com> |
|---|---|
| Date | 2014-04-20 06:31 +1000 |
| Subject | Re: Why Python 3? |
| From | Chris Angelico <rosuav@gmail.com> |
| Newsgroups | comp.lang.python |
| Message-ID | <mailman.9370.1397939472.18130.python-list@python.org> (permalink) |
On Sun, Apr 20, 2014 at 5:58 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> Considering that Fraction and Decimal did not exist yet, what type do
> you think the PEP 238 implementers should have chosen for the result
> of dividing two ints? If float is not acceptable, and int is not
> acceptable (which was the whole point of the PEP), then the only
> alternative I can see would have been to raise a TypeError and force
> the user to upcast explicitly. In that case, dividing arbitrary ints
> using floating-point math would not be possible for those ints that
> are outside the range of floats; you would get OverflowError on the
> upcast operation, regardless of whether the result of division would
> be within the range of a float.
>
>> Yes, I can see that it's nice for simple interactive use.
>
> More importantly, it's useful for implementers of generic mathematical
> routines. If you're passed arbitrary inputs, you don't have to check
> the types of the values you were given and then branch if both of the
> values you were about to divide happened to be ints just because the
> division operator arbitrarily does something different on ints.
Or you just cast one of them to float. That way you're sure you're
working with floats.
The main trouble is that float is not a perfect superset of int. If it
were, then it really would be upcasting, same as turning a float into
a complex is; there's no downside, other than performance.
If I'd been in charge, I would have simply let int/int continue to
return an int, as that's the one thing that is guaranteed not to
behave differently on different input values. Python 3 fixed Unicode
handling by ensuring that mixing text and bytes would cause problems
straight away, rather than waiting until you get a character with a
codepoint higher than U+00FF; 3.3 went further and made sure you
wouldn't get problems by going past U+FFFF even on Windows. I think we
all agree (well, all bar the trolls) that that was a good thing. So
why do we have this sort of thing go weird?
def always_true(x):
assert type(x) is int
return x*10/2 == x*5
In Python 2, I believe that will indeed be always true, for any
integer x. (Yeah, there's a naughty type check in there. I'm talking
about integers, mmkay?) In Python 3, it might not be.
>>> always_true(2**53)
True
>>> always_true(2**53+1)
False
(32-bit Windows, because I'm on the laptop. Other Pythons, other CPUs,
etc, may have different points where that happens, but the same will
happen.)
So either you keep a very close eye on everything to make sure you
don't have floats infecting your calculations, or you ignore the
problem and then start seeing odd stuff happen with specific numbers.
I'd rather have to explicitly request floating-point division; that
way, you get issues a lot sooner and more simply. "Why is 34/10 equal
to 3?" is a lot easier to explain than "Why does my program not work
when I give it numbers with lots of data encoded in them, when it
works fine with sequential numbers from zero?". (Imagine if you work
with invoice numbers, for instance, and your code is fine; but if you
encode the date into the first eight digits, then put the store number
in the next three, register number in the next three, and then the
last three are sequential. Should work the same, right?)
Anyway, way too late to change now. That ship sailed in 2.2 or thereabouts.
ChrisA
Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Why Python 3? Anthony Papillion <papillion@gmail.com> - 2014-04-18 22:28 -0500
Re: Why Python 3? Paul Rubin <no.email@nospam.invalid> - 2014-04-18 23:40 -0700
Re: Why Python 3? Chris Angelico <rosuav@gmail.com> - 2014-04-19 17:34 +1000
Re: Why Python 3? Roy Smith <roy@panix.com> - 2014-04-19 09:26 -0400
Re: Why Python 3? Chris Angelico <rosuav@gmail.com> - 2014-04-19 23:42 +1000
Re: Why Python 3? Albert-Jan Roskam <fomcl@yahoo.com> - 2014-04-19 10:57 -0700
Re: Why Python 3? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-04-20 10:07 +0000
Re: Why Python 3? Ian Kelly <ian.g.kelly@gmail.com> - 2014-04-19 03:25 -0600
Re: Why Python 3? Marko Rauhamaa <marko@pacujo.net> - 2014-04-19 12:59 +0300
Re: Why Python 3? Chris Angelico <rosuav@gmail.com> - 2014-04-19 19:37 +1000
Integer and float division [was Re: Why Python 3?] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-04-20 11:02 +0000
Re: Integer and float division [was Re: Why Python 3?] Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2014-04-20 15:38 +0300
Re: Integer and float division [was Re: Why Python 3?] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-04-20 15:09 +0000
Re: Integer and float division [was Re: Why Python 3?] Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-04-21 11:44 +1200
Re: Why Python 3? Terry Reedy <tjreedy@udel.edu> - 2014-04-19 13:23 -0400
Re: Why Python 3? Paul Rubin <no.email@nospam.invalid> - 2014-04-19 20:25 -0700
Re: Why Python 3? Ben Finney <ben+python@benfinney.id.au> - 2014-04-20 19:15 +1000
Re: Why Python 3? Walter Hurry <walterhurry@lavabit.com> - 2014-04-20 23:50 +0000
Re: Why Python 3? Chris Angelico <rosuav@gmail.com> - 2014-04-21 10:00 +1000
Re: Why Python 3? HoneyMonster <nobody@someplace.invalid> - 2014-04-21 04:08 +0000
Re: Why Python 3? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-04-21 01:11 +0100
Re: Why Python 3? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-04-19 18:31 +0100
Re: Why Python 3? Chris Angelico <rosuav@gmail.com> - 2014-04-20 03:53 +1000
Re: Why Python 3? Ian Kelly <ian.g.kelly@gmail.com> - 2014-04-19 13:58 -0600
Re: Why Python 3? Chris Angelico <rosuav@gmail.com> - 2014-04-20 06:31 +1000
Re: Why Python 3? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-04-20 13:06 +1200
Re: Why Python 3? Chris Angelico <rosuav@gmail.com> - 2014-04-20 11:28 +1000
Re: Why Python 3? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-04-21 10:52 +1200
Re: Why Python 3? Chris Angelico <rosuav@gmail.com> - 2014-04-21 09:24 +1000
Re: Why Python 3? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-04-21 03:43 +0000
Re: Why Python 3? Chris Angelico <rosuav@gmail.com> - 2014-04-21 14:43 +1000
Re: Why Python 3? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-04-22 09:58 +1200
Re: Why Python 3? Chris Angelico <rosuav@gmail.com> - 2014-04-21 14:48 +1000
Re: Why Python 3? wxjmfauth@gmail.com - 2014-04-21 02:42 -0700
Re: Why Python 3? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-04-22 10:28 +1200
Re: Why Python 3? Chris Angelico <rosuav@gmail.com> - 2014-04-22 08:43 +1000
Re: Why Python 3? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-04-22 18:03 +1200
Re: Why Python 3? Terry Reedy <tjreedy@udel.edu> - 2014-04-20 00:17 -0400
Re: Why Python 3? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-04-21 11:13 +1200
Re: Why Python 3? Terry Reedy <tjreedy@udel.edu> - 2014-04-20 20:09 -0400
Re: Why Python 3? Ian Kelly <ian.g.kelly@gmail.com> - 2014-04-19 14:38 -0600
Re: Why Python 3? Chris Angelico <rosuav@gmail.com> - 2014-04-20 06:53 +1000
Re: Why Python 3? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-04-20 13:35 +1200
Re: Why Python 3? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-04-20 09:59 +0000
Unicode in Python Rustom Mody <rustompmody@gmail.com> - 2014-04-21 20:57 -0700
Re: Unicode in Python Terry Reedy <tjreedy@udel.edu> - 2014-04-22 01:44 -0400
Re: Unicode in Python Rustom Mody <rustompmody@gmail.com> - 2014-04-21 23:18 -0700
Re: Unicode in Python Chris Angelico <rosuav@gmail.com> - 2014-04-22 16:32 +1000
Re: Unicode in Python Steven D'Aprano <steve@pearwood.info> - 2014-04-22 06:11 +0000
Re: Unicode in Python Rustom Mody <rustompmody@gmail.com> - 2014-04-21 23:30 -0700
Re: Unicode in Python Chris Angelico <rosuav@gmail.com> - 2014-04-22 16:44 +1000
Re: Unicode in Python wxjmfauth@gmail.com - 2014-04-22 02:07 -0700
Re: Unicode in Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-04-22 12:21 +0000
Re: Unicode in Python wxjmfauth@gmail.com - 2014-04-22 08:28 -0700
Re: Unicode in Python Ian Kelly <ian.g.kelly@gmail.com> - 2014-04-22 00:31 -0600
Re: Unicode in Python Rustom Mody <rustompmody@gmail.com> - 2014-04-22 02:23 -0700
Re: Unicode in Python Rustom Mody <rustompmody@gmail.com> - 2014-04-22 11:09 -0700
Re: Why Python 3? Ian Kelly <ian.g.kelly@gmail.com> - 2014-04-20 10:22 -0600
Re: Why Python 3? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-04-21 11:56 +1200
Re: Why Python 3? Ian Kelly <ian.g.kelly@gmail.com> - 2014-04-20 18:29 -0600
Re: Why Python 3? MRAB <python@mrabarnett.plus.com> - 2014-04-20 17:41 +0100
Re: Why Python 3? Chris Angelico <rosuav@gmail.com> - 2014-04-21 02:46 +1000
Re: Why Python 3? Roy Smith <roy@panix.com> - 2014-04-20 14:40 -0700
Re: Why Python 3? Terry Reedy <tjreedy@udel.edu> - 2014-04-20 17:58 -0400
Re: Why Python 3? Richard Damon <Richard@Damon-Family.org> - 2014-04-20 18:02 -0400
Re: Why Python 3? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-04-21 12:22 +1200
Re: Why Python 3? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-04-21 02:13 +0000
Re: Why Python 3? Steve Hayes <hayesstw@telkomsa.net> - 2014-04-19 13:53 +0200
Re: Why Python 3? Chris Angelico <rosuav@gmail.com> - 2014-04-19 22:46 +1000
Re: Why Python 3? Rustom Mody <rustompmody@gmail.com> - 2014-04-19 08:59 -0700
Re: Why Python 3? Rick Johnson <rantingrickjohnson@gmail.com> - 2014-04-19 07:41 -0700
Re: Why Python 3? Thomas Lehmann <thomas.lehmann.private@googlemail.com> - 2014-05-06 09:28 -0700
csiph-web