Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #70366 > unrolled thread

Why Python 3?

Back to article view | Back to comp.lang.python

Contents

  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

Page 1 of 4  [1] 2 3 4  Next page →

#70366 — Why Python 3?

Hello Everyone,

So I've been working with Python for a while and I'm starting to take
on more and more serious projects with it. I've been reading a lot
about Python 2 vs Python 3 and the community kind of seems split on
which should be used.

Some say 'Python 3 is the future, use it for everything now' and other
say 'Python 3 is the future but you can't do everything in it now so
use Python 2'.

What is the general feel of /this/ community? I'm about to start a
large scale Python project. Should it be done in 2 or 3? What are the
benefits, aside from the 'it's the future' argument?

Thanks,
Anthony

[toc] | [next] | [standalone]

#70371

Anthony Papillion <papillion@gmail.com> writes:
> Some say 'Python 3 is the future, use it for everything now' and other
> say 'Python 3 is the future but you can't do everything in it now so
> use Python 2'.

Python 3 is generally better than Python 2, except for a few packages
that haven't been ported.

That said, I don't know anyone who actually uses Python 3.  I don't
think it's a matter of wanting to use some problematic package, or
having particular technical concerns.  It's just that the improvement
from 2 to 3 is rather small, and 2 works perfectly well and people are
used to it, so they keep using it.  There are nice tools that
help port your codebase from 2 to 3 with fairly little effort.
But, you can also keep your codebase on 2 with zero effort.
So people choose zero over fairly little.

If you're starting a new project and you get to choose between 2 and 3,
other things equal I'd say use 3.  I've kept using 2 basically because
it's the path of least resistance.  I'm somewhat following the 3
situation and of course I'd use 3 if I were doing something that
benefited from it, but so far it hasn't been an issue.

Eventually the main Linux distros will include 3 instead of 2 by
default, and we'll probably see more migration then.  Right now I type
"python" and get 2, so I use it.

[toc] | [prev] | [next] | [standalone]

#70372

On Sat, Apr 19, 2014 at 4:40 PM, Paul Rubin <no.email@nospam.invalid> wrote:
> If you're starting a new project and you get to choose between 2 and 3,
> other things equal I'd say use 3.  I've kept using 2 basically because
> it's the path of least resistance.  I'm somewhat following the 3
> situation and of course I'd use 3 if I were doing something that
> benefited from it, but so far it hasn't been an issue.
>
> Eventually the main Linux distros will include 3 instead of 2 by
> default, and we'll probably see more migration then.  Right now I type
> "python" and get 2, so I use it.

Several of the main distros are already including Python 3 by default
(eg Ubuntu), but when you type "python", you still get Python 2, for
reasons of compatibility. (See PEP 394.) As long as you set your
shebang to say python3, it'll work just fine.

I strongly recommend going for Python 3 unless something actually
stops you from doing so. If you absolutely must use Python 2, try to
aim for a minimum of 2.6 or 2.7, and start your program with this
line:

from __future__ import print_function, unicode_literals, division

That'll make Python 2.6/2.7 behave like Python 3.x in three ways:
firstly, "print" will be a function instead of a statement (and it's
more powerful than the statement form, as well as being more
flexible); secondly, quoted strings will be Unicode strings, not byte
strings (that'll help you to start thinking about what's bytes and
what's text, which is an important distinction in Python 3); and
thirdly, though less important than the others, the division of two
integers will result in a floating point, not an integer. I personally
think the last one was a mistake on Python 3's part (why bless float
specifically? what if you're working with integers and
decimal.Decimals?), but if you're going to move to Python 3, you may
as well have your code start working that way, so you get used to
typing // to divide integers and get an integer (floor division).

But if you possibly can, aim for Python 3. Every new version adds
features, and new versions within the 3.x line break very little
(generally only what would have been working with a bug anyway, like
narrow Unicode builds of 3.2 becoming universal on 3.3). If you aim
for 3.2 today, and tomorrow try to run your code on 3.4, chances are
it'll work. The main thing is, know what's a text string and what's a
string of bytes; that's critical in 3.x, but not in 2.x. Force
yourself to think about that, and your code will be more reliable -
regardless of even what language you write it in.

ChrisA

[toc] | [prev] | [next] | [standalone]

#70384

Chris Angelico <rosuav@gmail.com> wrote:

> I strongly recommend going for Python 3 unless something actually
> stops you from doing so.

One of the problems is you don't know in advance if something is going 
to stop you.  By committing to P3 now, you are eliminating from possible 
future use, all of those third-party modules which only support P2.  And 
you don't know which of those you'll need until you sometime in the 
future.

It's rare to find a modern, actively maintained module which doesn't 
either support P3 already, or at least has that on its roadmap, but 
there's a lot of old stuff out there which is still very useful.

> If you absolutely must use Python 2, try to
> aim for a minimum of 2.6 or 2.7

That I absolutely agree with.  Unless I had some specific legacy use 
case I needed to continue to support, I wouldn't waste any time worrying 
about 2.5 support, and we're quickly reaching the point where the same 
can be said about 2.6.

> and start your program with this line:
> 
> from __future__ import print_function, unicode_literals, division

That seems reasonable, but be prepared for possible unicode issues.  
There is code out there in third party modules which makes 
unicode-unfriendly assumptions about strings.  For example:

https://github.com/brandon-rhodes/pyephem/issues/35

I'm not saying don't use unicode_literals (we do), just we aware that 
you might have to explicitly cast things to str() once in a while.

[toc] | [prev] | [next] | [standalone]

#70385

On Sat, Apr 19, 2014 at 11:26 PM, Roy Smith <roy@panix.com> wrote:
> Chris Angelico <rosuav@gmail.com> wrote:
>
>> I strongly recommend going for Python 3 unless something actually
>> stops you from doing so.
>
> One of the problems is you don't know in advance if something is going
> to stop you.  By committing to P3 now, you are eliminating from possible
> future use, all of those third-party modules which only support P2.  And
> you don't know which of those you'll need until you sometime in the
> future.

Conversely, committing to Py2 now eliminates from possible future use
all modules which support only Py3. Is there strong evidence that one
of those groups is larger than the other?

>> If you absolutely must use Python 2, try to
>> aim for a minimum of 2.6 or 2.7
>
> That I absolutely agree with.  Unless I had some specific legacy use
> case I needed to continue to support, I wouldn't waste any time worrying
> about 2.5 support, and we're quickly reaching the point where the same
> can be said about 2.6.

Red Hat? :) Though that's likely to be the last bastion of ancient
Python out there, soon. Debian Squeeze (oldstable) ships with 2.6, so
if you aim for 2.6+, you should catch all the distros that derive from
Debian (the current Debian stable, Wheezy, ships with 2.7). But Red
Hat will be supporting older Pythons for a good while.

>> and start your program with this line:
>>
>> from __future__ import print_function, unicode_literals, division
>
> That seems reasonable, but be prepared for possible unicode issues.
> There is code out there in third party modules which makes
> unicode-unfriendly assumptions about strings.

Right. It's not the magic line that fixes everything; if it were,
Python 3 wouldn't be a big deal at all. Go Py3 if you can, but if you
can't, at least make your double-quoted strings Unicode strings, and
then you have a chance to find problems.

ChrisA

[toc] | [prev] | [next] | [standalone]

#70395

----- Original Message -----

> From: Chris Angelico <rosuav@gmail.com>
> To: 
> Cc: "python-list@python.org" <python-list@python.org>
> Sent: Saturday, April 19, 2014 3:42 PM
> Subject: Re: Why Python 3?

<snip>

> Right. It's not the magic line that fixes everything; if it were,
> Python 3 wouldn't be a big deal at all. Go Py3 if you can, but if you
> can't, at least make your double-quoted strings Unicode strings, and
> then you have a chance to find problems.

Totally agree. It's not that hard at all. I consider it true craftmanship that Guido had the guts break backward compatibility and clean up some mistakes. Compare this with CRAN R, where so much illogical S-plus stuff is present (word count for "historical anomaly": 1000+ ;-). 

Am I the only one who always thinks of Rogers' Diffusion of Innovations curve with these Python2/3 debates? http://en.wikipedia.org/wiki/File:Diffusion_of_ideas.svg. source: http://en.wikipedia.org/wiki/Diffusion_of_innovations

[toc] | [prev] | [next] | [standalone]

#70410

On Sat, 19 Apr 2014 09:26:53 -0400, Roy Smith wrote:

> One of the problems is you don't know in advance if something is going
> to stop you.  By committing to P3 now, you are eliminating from possible
> future use, all of those third-party modules which only support P2.  And
> you don't know which of those you'll need until you sometime in the
> future.

I believe this is more of an issue in theory than in practice. My on-line 
web portal app could potentially use any of a thousand different Python 
2.x only libraries, but in practice I'm probably only going to use half a 
dozen libraries, or fewer, and know very early in the design phase what I 
need (web templating software, yes, library to control radio telescopes, 
probably not). And I'm likely to eliminate from contention most libraries 
that seem unsupported or abandoned, and if they only support Python 2 
five years since the introduction of Python 3, they better have a good 
reason for it.


-- 
Steven D'Aprano
http://import-that.dreamwidth.org/

[toc] | [prev] | [next] | [standalone]

#70373

On Sat, Apr 19, 2014 at 1:34 AM, Chris Angelico <rosuav@gmail.com> wrote:
> That'll make Python 2.6/2.7 behave like Python 3.x in three ways:
> firstly, "print" will be a function instead of a statement (and it's
> more powerful than the statement form, as well as being more
> flexible); secondly, quoted strings will be Unicode strings, not byte
> strings (that'll help you to start thinking about what's bytes and
> what's text, which is an important distinction in Python 3); and
> thirdly, though less important than the others, the division of two
> integers will result in a floating point, not an integer. I personally
> think the last one was a mistake on Python 3's part (why bless float
> specifically? what if you're working with integers and
> decimal.Decimals?), but if you're going to move to Python 3, you may
> as well have your code start working that way, so you get used to
> typing // to divide integers and get an integer (floor division).

If you're working with decimals, then the result is a decimal.  If one
side is an integer and the other is a decimal, then the result is
still a decimal.  Similarly if one of the operands is a fraction, then
the result is a fraction.  The change from / denoting "classic
division" to "true division" really only affects the case where both
operands are integers, so far as I'm aware.  If you want to divide two
integers and get a decimal result, then convert one or both of them to
decimals first; you would have needed to do the same with classic
division.

We also gained a consistent and explicit way to differentiate between
the two different styles of division that classic division
represented, as opposed to picking at run-time based on type.

As for "why float" specifically, the division __future__ import has
been around since 2.2, longer than either decimals or fractions.

[toc] | [prev] | [next] | [standalone]

#70375

Ian Kelly <ian.g.kelly@gmail.com>:

> On Sat, Apr 19, 2014 at 1:34 AM, Chris Angelico <rosuav@gmail.com> wrote:
>> if you're going to move to Python 3, you may as well have your code
>> start working that way, so you get used to typing // to divide
>> integers and get an integer (floor division).
>
> [...]
>
> We also gained a consistent and explicit way to differentiate between
> the two different styles of division that classic division
> represented, as opposed to picking at run-time based on type.

Very often when integer division is needed, so is the remainder. Then,
it is good to remember the builtin divmod() function:

   https://docs.python.org/3.4/library/functions.html#divmod

In fact, divmod() goes a long way toward removing the need for // and %
in Python code.


Marko

[toc] | [prev] | [next] | [standalone]

#70374

On Sat, Apr 19, 2014 at 7:25 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> The change from / denoting "classic
> division" to "true division" really only affects the case where both
> operands are integers, so far as I'm aware.  If you want to divide two
> integers and get a decimal result, then convert one or both of them to
> decimals first; you would have needed to do the same with classic
> division.

If float were a perfect superset of int, and the only logical superset
when you want non-integers, then it'd be fine. But if you're mixing
int and Decimal, you have to explicitly convert, whereas if you're
mixing int and float, you don't. Why is it required to be explicit
with Decimal but not float? Of all the possible alternate types, why
float? Only because...

> As for "why float" specifically, the division __future__ import has
> been around since 2.2, longer than either decimals or fractions.

... it already existed. There's no particular reason to up-cast to
float, specifically, and it can cause problems with large integers -
either by losing accuracy, or by outright overflowing.

Suppose you take an integer, multiply it by 10, and divide it by 5. In
theory, that's the same as multiplying by 2, right? Mathematically it
is. In C it might not be, because the multiplication might overflow;
but Python, like a number of other modern languages, has an integer
type that won't overflow. In Python 2, doing the obvious thing works:

x * 10 / 5 == x * 2

In Python 3, you have to say "Oh but I want my integer division to
result in an integer":

x * 10 // 5 == x * 2

Yes, I can see that it's nice for simple interactive use. You type
"1/2" and you get back 0.5. But doesn't it just exchange one set of
problems ("dividing integers by integers rounds") for another set
("floating point arithmetic isn't real number arithmetic")?

Anyway. While I think it was a mistake to bless float in that way, I'm
aware that it isn't going to change. Which is why, for anyone who's
looking at starting a project fresh, I recommend "from __future__
import division", as it'll make the port to Py3 that much easier.

ChrisA

[toc] | [prev] | [next] | [standalone]

#70411 — Integer and float division [was Re: Why Python 3?]

On Sat, 19 Apr 2014 19:37:31 +1000, Chris Angelico wrote:

> On Sat, Apr 19, 2014 at 7:25 PM, Ian Kelly <ian.g.kelly@gmail.com>
> wrote:
>> The change from / denoting "classic
>> division" to "true division" really only affects the case where both
>> operands are integers, so far as I'm aware.  If you want to divide two
>> integers and get a decimal result, then convert one or both of them to
>> decimals first; you would have needed to do the same with classic
>> division.
> 
> If float were a perfect superset of int, and the only logical superset
> when you want non-integers, then it'd be fine. But if you're mixing int
> and Decimal, you have to explicitly convert, 

I don't think so. Operations on mixed int/Decimal arguments return 
Decimal. There's no conversion needed except to get the original Decimal 
number in the first place. (Decimal is not a built-in and there's no 
literal syntax for them.)

py> from decimal import Decimal as D
py> x, y = 1, D(2)
py> x/y
Decimal('0.5')
py> x//y
Decimal('0')


> whereas if you're mixing
> int and float, you don't. Why is it required to be explicit with Decimal
> but not float? Of all the possible alternate types, why float? Only
> because...

Because float is built-in and Decimal is not. Because Decimal wasn't 
introduced until Python 2.4 while the change to the division operator was 
first begun back in Python 2.2.

http://python.org/dev/peps/pep-0238/

Guido writes about why his decision to emulate C's division operator was 
a mistake:

http://python-history.blogspot.com.au/2009/03/problem-with-integer-division.html


>> As for "why float" specifically, the division __future__ import has
>> been around since 2.2, longer than either decimals or fractions.
> 
> ... it already existed. There's no particular reason to up-cast to
> float, specifically, and it can cause problems with large integers -
> either by losing accuracy, or by outright overflowing.

If you reject C integer division, you have to do *something* with 1/2. 
Ideally you'll get a number numerically equal to one half. It can't be a 
Decimal, or a Fraction, because back in 2001 there were no Decimal or 
Fraction types, and even now in 2014 they aren't built-ins.

(Besides, both of those choices have other disadvantages. Fractions are 
potentially slow and painful, with excessive accuracy. See Guido's 
comments in his blog post above. And Decimal uses base 10 floating point, 
which is less suitable for serious numeric work than base 2 floats.)


> Suppose you take an integer, multiply it by 10, and divide it by 5. In
> theory, that's the same as multiplying by 2, right? 

That's a bit of a contrived example. But go on.


> Mathematically it
> is. In C it might not be, because the multiplication might overflow; but
> Python, like a number of other modern languages, has an integer type
> that won't overflow. 

Only since, um, version 2.2 I think. I don't have 2.1 easily available, 
but here's 1.5:


[steve@ando ~]$ python1.5
Python 1.5.2 (#1, Aug 27 2012, 09:09:18)  [GCC 4.1.2 20080704 (Red Hat 
4.1.2-52)] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> 2**31*10
Traceback (innermost last):
  File "<stdin>", line 1, in ?
OverflowError: integer pow()


So don't forget the historical context of what you are discussing.



> In Python 2, doing the obvious thing works:
> 
> x * 10 / 5 == x * 2

Ignoring old versions of Python 2.x, correct. But that is a contrived 
example. Mathematically x/5*10 also equals 2*x, but not with C division 
semantics. This is with Python 2.7:


>>> x = 7
>>> x/5*10, x*10/5, x*2
(10, 14, 14)

Let's try it with true (calculator) division:

>>> x/5*10, x*10/5, x*2
(14.0, 14.0, 14)


With a bit of effort, I'm sure you can find values of x where they are 
not all equal, but that's because floats only have a finite precision. In
general, true division is less surprising and causes fewer unexpected
truncation errors.

 
> In Python 3, you have to say "Oh but I want my integer division to
> result in an integer":
> 
> x * 10 // 5 == x * 2

No, // doesn't mean "divide and coerce to an integer", it is 
*truncating* division. The type being truncated may choose to return
an int, but that's not compulsory:


>>> from decimal import Decimal as D
>>> x = D("23.5")
>>> x/4, x//4
(Decimal('5.875'), Decimal('5'))


> Yes, I can see that it's nice for simple interactive use. You type "1/2"
> and you get back 0.5. But doesn't it just exchange one set of problems
> ("dividing integers by integers rounds") 

It doesn't round, it truncates.

[steve@ando ~]$ python2.7 -c "print round(799.0/100)"
8.0
[steve@ando ~]$ python2.7 -c "print 799/100"
7


> for another set ("floating
> point arithmetic isn't real number arithmetic")?

It's not like that avoiding that problem is an option.




-- 
Steven D'Aprano
http://import-that.dreamwidth.org/

[toc] | [prev] | [next] | [standalone]

#70414 — Re: Integer and float division [was Re: Why Python 3?]

Steven D'Aprano writes:

> It doesn't round, it truncates.
> 
> [steve@ando ~]$ python2.7 -c "print round(799.0/100)"
> 8.0
> [steve@ando ~]$ python2.7 -c "print 799/100"
> 7

Seems it floors rather than truncates:

$ python2.7 -c "from math import trunc;print trunc(799./-100)"
-7
$ python2.7 -c "from math import floor;print floor(799./-100)"
-8.0
$ python2.7 -c "print 799/-100"
-8

$ python3.2 -c "print(799//-100)"
-8

[toc] | [prev] | [next] | [standalone]

#70416 — Re: Integer and float division [was Re: Why Python 3?]

On Sun, 20 Apr 2014 15:38:03 +0300, Jussi Piitulainen wrote:

> Steven D'Aprano writes:
> 
>> It doesn't round, it truncates.
>> 
>> [steve@ando ~]$ python2.7 -c "print round(799.0/100)" 8.0
>> [steve@ando ~]$ python2.7 -c "print 799/100" 7
> 
> Seems it floors rather than truncates:
> 
> $ python2.7 -c "from math import trunc;print trunc(799./-100)" -7
> $ python2.7 -c "from math import floor;print floor(799./-100)" -8.0
> $ python2.7 -c "print 799/-100"
> -8
> 
> $ python3.2 -c "print(799//-100)"
> -8


Ah yes, so it does. Sorry for the confusion. This has been reported as a 
bug at least twice, but it is actually working as intended. // floors, 
not truncates towards zero.

http://bugs.python.org/issue19446
http://bugs.python.org/issue19574



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/

[toc] | [prev] | [next] | [standalone]

#70441 — Re: Integer and float division [was Re: Why Python 3?]

> On Sat, 19 Apr 2014 19:37:31 +1000, Chris Angelico wrote:
 >
>>In Python 3, you have to say "Oh but I want my integer division to
>>result in an integer":

I don't see why that's such a big hardship.

There are clear advantages to having an explicit way to
request non-floor division. Whatever way is chosen for
that, some other way has to be chosen to request floor
division.

One could debate whether it would have been better to make
/ mean floor division and invent something else for
non-floor division, but then some people would complain
"Oh, but I have to say I want my float division to return
a float!"

Either way requires people to make some changes in their
habits.

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#70392

On 4/19/2014 2:40 AM, Paul Rubin wrote:

> That said, I don't know anyone who actually uses Python 3.

I have no idea who you know ;-)

LibreOffice bundles 3.3. So anyone who does Python scripting in 
LibreOffice is using Python 3. Actually, I believe LO uses Python 
internally for some of its scripting. If so, everyone using LO is 
indirectly using 3.3.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#70404

Terry Reedy <tjreedy@udel.edu> writes:
> LibreOffice bundles 3.3. So anyone who does Python scripting in
> LibreOffice is using Python 3. Actually, I believe LO uses Python
> internally for some of its scripting. If so, everyone using LO is
> indirectly using 3.3.

I didn't even know LO supported Python scripting, but I wouldn't count
such indirect use anyway.  I meant I don't know any Python programmers
(at least in person) who use Python 3 for their daily coding.  I think
this is mostly because they (and I) use whatever is in the OS distro,
and that is generally still 2.6 or 2.7.

[toc] | [prev] | [next] | [standalone]

#70407

Paul Rubin <no.email@nospam.invalid> writes:

> [people I know] use whatever is in the OS distro, and that is
> generally still 2.6 or 2.7.

When the OS contains *both* Python 2 and Python 3, does Python 3 count
as “in the OS”?

Or will you only count Python 3 as “in the OS” when Python 2 is not
present at all in the OS?

I think your description isn't accurate. Python 3 is very likely in the
OS also, so you are using some other criterion to decide to use the
legacy Python 2 instead of the current Python 3 also supplied with the OS.

-- 
 \       Moriarty: “Forty thousand million billion dollars? That money |
  `\            must be worth a fortune!” —The Goon Show, _The Sale of |
_o__)                                                       Manhattan_ |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#70442

On Sat, 19 Apr 2014 20:25:32 -0700, Paul Rubin wrote:

> Terry Reedy <tjreedy@udel.edu> writes:
>> LibreOffice bundles 3.3. So anyone who does Python scripting in
>> LibreOffice is using Python 3. Actually, I believe LO uses Python
>> internally for some of its scripting. If so, everyone using LO is
>> indirectly using 3.3.
> 
> I didn't even know LO supported Python scripting, but I wouldn't count
> such indirect use anyway.  I meant I don't know any Python programmers
> (at least in person) who use Python 3 for their daily coding.  I think
> this is mostly because they (and I) use whatever is in the OS distro,
> and that is generally still 2.6 or 2.7.

I would use Python 3 in a flash if only wxPython would support it.

[toc] | [prev] | [next] | [standalone]

#70444

On Mon, Apr 21, 2014 at 9:50 AM, Walter Hurry <walterhurry@lavabit.com> wrote:
> I would use Python 3 in a flash if only wxPython would support it.

There seems to be a "Project Phoenix" (found it at the other end of a
Google search) with that goal. I've no idea what its status is, but
you could help that project along by expressing interest and maybe
helping with their bug tracker, or hosting a buildbot (they seem to
use the same buildbot software that Python uses), or something like
that. If you're really serious about wanting Python 3 support, go the
whole way and actually help to port it!

ChrisA

[toc] | [prev] | [next] | [standalone]

#70451

On Mon, 21 Apr 2014 10:00:01 +1000, Chris Angelico wrote:

> On Mon, Apr 21, 2014 at 9:50 AM, Walter Hurry <walterhurry@lavabit.com>
> wrote:
>> I would use Python 3 in a flash if only wxPython would support it.
> 
> There seems to be a "Project Phoenix" (found it at the other end of a
> Google search) with that goal. I've no idea what its status is, but you
> could help that project along by expressing interest and maybe helping
> with their bug tracker, or hosting a buildbot (they seem to use the same
> buildbot software that Python uses), or something like that. If you're
> really serious about wanting Python 3 support, go the whole way and
> actually help to port it!

Yes, I'm keeping an eye on Fawkes*.
Alas, my skillset is not up to your other suggestions, but thanks.

* http://harrypotter.wikia.com/wiki/Fawkes

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.python

csiph-web