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

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

So, what's the real story on Python 2 vs Python 3?

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

Contents

  So, what's the real story on Python 2 vs Python 3? Travis McGee <nobody@nowhere.com> - 2013-12-27 00:04 -0500
    Re: So, what's the real story on Python 2 vs Python 3? Roy Smith <roy@panix.com> - 2013-12-27 00:07 -0500
      Re: So, what's the real story on Python 2 vs Python 3? Chris Angelico <rosuav@gmail.com> - 2013-12-27 16:14 +1100
    Re: So, what's the real story on Python 2 vs Python 3? Andrew Berg <robotsondrugs@gmail.com> - 2013-12-26 23:20 -0600
      Re: So, what's the real story on Python 2 vs Python 3? Grant Edwards <invalid@invalid.invalid> - 2014-01-02 16:34 +0000
    Re: So, what's the real story on Python 2 vs Python 3? Dan Stromberg <drsalists@gmail.com> - 2013-12-26 21:29 -0800
    Re: So, what's the real story on Python 2 vs Python 3? Rustom Mody <rustompmody@gmail.com> - 2013-12-27 11:13 +0530
    Re: So, what's the real story on Python 2 vs Python 3? Chris Angelico <rosuav@gmail.com> - 2013-12-27 17:00 +1100
    Re: So, what's the real story on Python 2 vs Python 3? Dan Stromberg <drsalists@gmail.com> - 2013-12-26 22:23 -0800
    Re: So, what's the real story on Python 2 vs Python 3? Rustom Mody <rustompmody@gmail.com> - 2013-12-27 16:21 +0530
    Re: So, what's the real story on Python 2 vs Python 3? Chris Angelico <rosuav@gmail.com> - 2013-12-27 22:06 +1100
      Re: So, what's the real story on Python 2 vs Python 3? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-27 22:34 +1100
        Re: So, what's the real story on Python 2 vs Python 3? Chris Angelico <rosuav@gmail.com> - 2013-12-27 22:46 +1100
    Re: So, what's the real story on Python 2 vs Python 3? Ned Batchelder <ned@nedbatchelder.com> - 2013-12-27 07:13 -0500
    Re: So, what's the real story on Python 2 vs Python 3? Grant Edwards <invalid@invalid.invalid> - 2014-01-02 16:28 +0000

#62771 — So, what's the real story on Python 2 vs Python 3?

The Python.org site says that the future is Python 3, yet whenever I try 
something new in Python, such as Tkinter which I am learning now, 
everything seems to default to Python 2. By this I mean that, whenever I 
find that I need to install another package, it shows up as Python 2 
unless I explicitly specify Python 3.

What's the deal? If I want to make a distributable software package, 
should it be 2 or 3? Enquiring minds want to know.

[toc] | [next] | [standalone]

#62773

In article <XT7vu.64127$Qi4.25759@fx11.iad>,
 Travis McGee <nobody@nowhere.com> wrote:

> The Python.org site says that the future is Python 3, yet whenever I try 
> something new in Python, such as Tkinter which I am learning now, 
> everything seems to default to Python 2. By this I mean that, whenever I 
> find that I need to install another package, it shows up as Python 2 
> unless I explicitly specify Python 3.
> 
> What's the deal? If I want to make a distributable software package, 
> should it be 2 or 3? Enquiring minds want to know.

The future is indeed Python 3.  The problem with the future is that it's 
not here yet.

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

#62774

On Fri, Dec 27, 2013 at 4:07 PM, Roy Smith <roy@panix.com> wrote:
> In article <XT7vu.64127$Qi4.25759@fx11.iad>,
>  Travis McGee <nobody@nowhere.com> wrote:
>
>> The Python.org site says that the future is Python 3, yet whenever I try
>> something new in Python, such as Tkinter which I am learning now,
>> everything seems to default to Python 2. By this I mean that, whenever I
>> find that I need to install another package, it shows up as Python 2
>> unless I explicitly specify Python 3.
>>
>> What's the deal? If I want to make a distributable software package,
>> should it be 2 or 3? Enquiring minds want to know.
>
> The future is indeed Python 3.  The problem with the future is that it's
> not here yet.

Or to be more precise, is not exclusively here yet. The past is Python
2; the future is Python 3. The present is both Pythons, running in
parallel; if you're lucky, that's 2.7 and the latest 3.x, though not
everyone has that luxury.

For new code, aim for Python 3 unless you have a good reason to go for
Python 2. Most Linux distributions come with Python 2 under the name
"python", and Python 3 under the name "python3"; stick with that and
you'll be fairly safe. Or, if you can depend on your users having a
recent Py3 installed, you can use the launcher packaged with 3.3 and
later, which can intelligently figure out versioning.

ChrisA

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

#62777

On 2013.12.26 23:04, Travis McGee wrote:
> The Python.org site says that the future is Python 3, yet whenever I try 
> something new in Python, such as Tkinter which I am learning now, 
> everything seems to default to Python 2. By this I mean that, whenever I 
> find that I need to install another package, it shows up as Python 2 
> unless I explicitly specify Python 3.
> 
> What's the deal? If I want to make a distributable software package, 
> should it be 2 or 3? Enquiring minds want to know.
> 
Oh boy, another 2 vs. 3 thread!

Always use 3 unless you absolutely have to use 2. Python 3 is not a shiny new thing. It is *five* years old at this point and is soon to
have its *fifth* significant release. Python 2.6 is EOL, and there will not be a 2.8.
However, people have stayed with Python 2 for various reasons, and unfortunately, many of those people haven't even made an effort to
migrate until the last year or so.
Most of the major third-party libraries these days are either 3.x compatible or have 3.x-compatible replacements, though.

-- 
CPython 3.3.3 | Windows NT 6.2.9200 / FreeBSD 10.0

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

#62979

On 2013-12-27, Andrew Berg <robotsondrugs@gmail.com> wrote:
> On 2013.12.26 23:04, Travis McGee wrote:
>> The Python.org site says that the future is Python 3, yet whenever I try 
>> something new in Python, such as Tkinter which I am learning now, 
>> everything seems to default to Python 2. By this I mean that, whenever I 
>> find that I need to install another package, it shows up as Python 2 
>> unless I explicitly specify Python 3.
>> 
>> What's the deal? If I want to make a distributable software package, 
>> should it be 2 or 3? Enquiring minds want to know.
>
> Oh boy, another 2 vs. 3 thread!
>
> Always use 3 unless you absolutely have to use 2. Python 3 is not a
> shiny new thing. It is *five* years old at this point

<Insert crotchety-old-guy story about how something five years old
most certainly is still a "shiney new thing" here>

While Python 3 may not be shiney and new, the Python 3 support in some
third-party packages and libraries is still shiney and new at best,
and missing at worst.  The situation is improving steadily, and while
I do try to write new code work with both 2.7 and 3.x, I still use 2.7
for my day-to-day work.

-- 
Grant Edwards               grant.b.edwards        Yow! Of course, you
                                  at               UNDERSTAND about the PLAIDS
                              gmail.com            in the SPIN CYCLE --

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

#62778

On Thu, Dec 26, 2013 at 9:04 PM, Travis McGee <nobody@nowhere.com> wrote:
> What's the deal? If I want to make a distributable software package, should
> it be 2 or 3? Enquiring minds want to know.

3.x alone isn't a bad option, but it doesn't really have to be an
either-or decision.  That is, even pretty substantial code bases can
run on both, without any 2to3 or 3to2.

Personally, I'd think very carefully before committing to a dependency
that's still 2.x-only today.

EG, when I was looking for a 3.x version of pygtk, it turned out that
pygtk was being replaced by something called "gobject", which runs on
both 2.x and 3.x.  I happily made my pygtk scripts use gobject, and
now they're portable between 2.x and 3.x - there was even a script
provided that made most of the changes for me.

Here's a link to a presentation I did at my local Python User Group
about writing code to run on both 2.x and 3.x:
http://stromberg.dnsalias.org/~dstromberg/Intro-to-Python/

HTH

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

#62780

On Fri, Dec 27, 2013 at 10:50 AM, Andrew Berg <robotsondrugs@gmail.com> wrote:
> On 2013.12.26 23:04, Travis McGee wrote:
>> The Python.org site says that the future is Python 3, yet whenever I try
>> something new in Python, such as Tkinter which I am learning now,
>> everything seems to default to Python 2. By this I mean that, whenever I
>> find that I need to install another package, it shows up as Python 2
>> unless I explicitly specify Python 3.
>>
>> What's the deal? If I want to make a distributable software package,
>> should it be 2 or 3? Enquiring minds want to know.
>>
> Oh boy, another 2 vs. 3 thread!

I believe that this is separable into at least two questions:

1. Whats the deal about 2 and 3, as in where on the
past-present-future do these sit

2. How to write software that is 2+3 compatible

As for 1 its the much heat little light kind of discussion. I'll leave
others to warm themselves and the planet

As for 2 maybe we need a wiki page. (Or do we have one already?)
Heres my largely ignoramus attempt at starting that:

1. print: Use print with (). Dont use funny 2 syntax
2. Always write strings with a u" prefix
3. Always use new style classes
4. Always use relative imports with explicit relative (ie use .)

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

#62781

On Fri, Dec 27, 2013 at 4:43 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> 1. print: Use print with (). Dont use funny 2 syntax
> 2. Always write strings with a u" prefix
> 3. Always use new style classes
> 4. Always use relative imports with explicit relative (ie use .)

Even easier:

1. from __future__ import print_function
2. from __future__ import unicode_literals
(3 and 4 as per your above)

For anything 2.6 or newer, those two will give Py3 behaviour, at least
in those two ways. Saves you having to put the explicit u prefix on
everything.

ChrisA

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

#62783

On Thu, Dec 26, 2013 at 9:43 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> On Fri, Dec 27, 2013 at 10:50 AM, Andrew Berg <robotsondrugs@gmail.com> wrote:

> As for 2 maybe we need a wiki page. (Or do we have one already?)
> Heres my largely ignoramus attempt at starting that:
>
> 1. print: Use print with (). Dont use funny 2 syntax.
In fact, use parens with a single argument that may be a relatively
complex string % or .format expression.  Otherwise 2.x will think it's
being passed a tuple and display accordingly.

> 2. Always write strings with a u" prefix
3.0, 3.1 and 3.2 don't understand this, but 3.3 does.

In a project I wanted to run on 2.5, 2.6, 2.7, 3.0, 3.1, 3.2 and 3.3,
I dedicated a python module to most of my string constants, and
converted as needed using a pair of helper functions.  If Jython had
been available with 2.7 compatibility at the time, I would've ignored
2.5 and 2.6; now Jython has a 2.7 beta which is good enough for at
least some of my purposes.

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

#62787

On Fri, Dec 27, 2013 at 11:53 AM, Dan Stromberg wrote:
> On Thu, Dec 26, 2013 at 9:43 PM, Rustom Mody  wrote:
>> 2. Always write strings with a u" prefix
> 3.0, 3.1 and 3.2 don't understand this, but 3.3 does.

Ok
I was writing this under the assumption that 2 is really entrenched
whereas 3.n is dispensable when 3.n+1 comes out
At least on my debian box 3.2 recently got obsoleted and removed when
3.3 came out.

>
> In a project I wanted to run on 2.5, 2.6, 2.7, 3.0, 3.1, 3.2 and 3.3,

Obviously my assumption may not always be 'assumable' eg sometime ago
there was someone who wanted to port his old working python app to 3.
2to3 was not working because he was using string exceptions (His code
was 1.something!!)


-- 

http://blog.languager.org

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

#62788

On Fri, Dec 27, 2013 at 9:51 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> On Fri, Dec 27, 2013 at 11:53 AM, Dan Stromberg wrote:
>> On Thu, Dec 26, 2013 at 9:43 PM, Rustom Mody  wrote:
>>> 2. Always write strings with a u" prefix
>> 3.0, 3.1 and 3.2 don't understand this, but 3.3 does.
>
> Ok
> I was writing this under the assumption that 2 is really entrenched
> whereas 3.n is dispensable when 3.n+1 comes out
> At least on my debian box 3.2 recently got obsoleted and removed when
> 3.3 came out.

That's true except for the "comes out" part. Just because python.org
has released a newer 3.x Python doesn't mean everyone has it; Debian
Wheezy (the current stable) ships with 3.2, and Debian Squeeze (the
current oldstable, still supported and will be until some time 2014
probably) ships 3.1. So for scripts that need to be deployed onto one
of the most popular Linux distributions, supporting only 3.3 is pretty
much out of the question. And Red Hat, generally, is supported for
even longer. I don't know what Python versions are going to still be
around for the next ten years, but the easiest way to check would
probably be to see what RHEL support dates and Python versions are.

However, I do broadly agree. For controlled environments, you should
be able to slide from 3.1 to 3.2 to 3.3 to 3.4 on whatever schedule
you choose, and happily drop support for the older versions. But in
less controlled environments, that's a bit harder.

Probably within the next 5 years, it'll become reasonably plausible to
support nothing older than 2.6, and then all those 3.x compatibility
__future__s will be all you need. Well, most of what you need. There
are still fundamental issues with functions not taking Unicode
strings, but that's going to be a problem whatever you do. But life'll
be a lot easier.

ChrisA

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

#62789

Chris Angelico wrote:

> However, I do broadly agree. For controlled environments, you should
> be able to slide from 3.1 to 3.2 to 3.3 to 3.4 on whatever schedule
> you choose, and happily drop support for the older versions. But in
> less controlled environments, that's a bit harder.
> 
> Probably within the next 5 years, it'll become reasonably plausible to
> support nothing older than 2.6, 

It's already reasonable to support nothing older than 2.6, or 2.7 for that
matter.

The *first* question you have to ask is, which third-party libraries do I
rely on? Those libraries will set the minimum system requirement. Beyond
that, you have total freedom to support as many or as few versions as you
like. Ask yourself:

- Which operating systems do I intend to support?

If the answer is "Windows only", you pretty much can pick whichever version
of Python you like, since all versions of Python are equally difficult (or
easy) to install on Windows. Likewise for Mac.

If the answer includes Linux or Unix, then the next question to ask is:

- Shall I support only the OS-provided version(s) of Python?

If so, then you need to work out which version(s) of Python are common to
all the OSes you intend to support. E.g. there are currently supported
versions of Centos and RHEL that provide Python 2.4. If you intend to
support those versions of Centos and RHEL, then you need to support Python
2.4. If you are prepared to drop support for such systems, then you can
drop support for 2.4 and move on to 2.5 or 2.6. It depends on how much
extra effort you wish to go to in order to support what percentage of your
users. Personally, I find it very annoying when vendors expect you to
upgrade perfectly adequate, still supported systems, and so I try to target
2.4+ when I can. (Also, I am still running a Centos system with 2.4, so I'm
scratching my own itch.)

On the other hand, I once tried to target Python 2.3+. That decision lasted
about two days. The amount of functionality missing from 2.3 compared to
2.4 makes it too painful.

Alternatively, if you don't care about the OS-provided Python (perhaps
you're providing your own, or you expect your users to install from
source), then I think it is acceptable to target 2.7 and 3.3 or better
(e.g. drop support for 3.1 and 3.2). 3.0 is not supported at all -- it was
a buggy release and was quickly dropped for 3.1. If you're not constrained
by "yum python3" or "apt-get python3", then 3.3 is probably the version you
should aim for.


-- 
Steven

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

#62791

On Fri, Dec 27, 2013 at 10:34 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Alternatively, if you don't care about the OS-provided Python (perhaps
> you're providing your own, or you expect your users to install from
> source), then I think it is acceptable to target 2.7 and 3.3 or better
> (e.g. drop support for 3.1 and 3.2). 3.0 is not supported at all -- it was
> a buggy release and was quickly dropped for 3.1. If you're not constrained
> by "yum python3" or "apt-get python3", then 3.3 is probably the version you
> should aim for.

That's about the size of it. I'm quite happy to work with a 3.4 alpha,
but when it comes to installation instructions, "get this and compile
it" is a lot less helpful than "install python3 via your OS package
manager" (especially since compiling Python from source also means
getting the development versions of whatever modules you need -
apt-getting a bunch of -dev packages, or whatever - and if you don't
get them, some modules mightn't work even though core Python does).
Hence I'd like to stick to OS-provided versions *where reasonable* -
I'm not going to warp my code around Python 2.4 unless there's a large
slab of users on that, but I will restrict myself to Pike 7.8.700
because it's worth the effort.

ChrisA

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

#62794

On 12/27/13 12:04 AM, Travis McGee wrote:
> The Python.org site says that the future is Python 3, yet whenever I try
> something new in Python, such as Tkinter which I am learning now,
> everything seems to default to Python 2. By this I mean that, whenever I
> find that I need to install another package, it shows up as Python 2
> unless I explicitly specify Python 3.
>
> What's the deal? If I want to make a distributable software package,
> should it be 2 or 3? Enquiring minds want to know.

Choosing between 2 and 3 should be done the same way any version 
decision is made: examine all of your dependencies (libraries, help 
online, skilled helpers available, hosting options, books, etc), then 
choose the highest version that supports them.  Some people still find 
that the answer is 2, but many are finding that it is now 3.  There's a 
lot of FUD about Python 3, don't listen to it.

Certainly don't be thrown by the "default" of 2.  It doesn't matter what 
most people do, or how your operating system is configured, what matters 
is whether you have what you need.

Note that on sensible operating systems, "python" will continue to mean 
Python 2, and "python3" will mean Python 3.  This will help perpetuate 
the notion that Python 3 is the outlier, but it's the only way to keep 
software working properly.  Don't let it color your perceptions.

If you are going to support both 2 and 3, in addition to the other good 
suggestions in this thread, the six module on PyPI can help with the 
differences.

-- 
Ned Batchelder, http://nedbatchelder.com

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

#62978

On 2013-12-27, Travis McGee <nobody@nowhere.com> wrote:

> The Python.org site says that the future is Python 3, yet whenever I
> try something new in Python, such as Tkinter which I am learning now,
> everything seems to default to Python 2. By this I mean that,
> whenever I find that I need to install another package, it shows up
> as Python 2 unless I explicitly specify Python 3.

That's a function of whatever you're using to "install another package".

I can tell you how to configure Gentoo Linux so that portage/emerge 
always installs Python packages for Python 3, Python 2, or both.

> What's the deal? If I want to make a distributable software package, 
> should it be 2 or 3?

Both. :)

-- 
Grant Edwards               grant.b.edwards        Yow! This ASEXUAL PIG
                                  at               really BOILS my BLOOD
                              gmail.com            ... He's so ... so
                                                   ... URGENT!!

[toc] | [prev] | [standalone]

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

csiph-web