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

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

Python 3.x adoption

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

Contents

  Python 3.x adoption Staszek <noreply@eisenbits.com> - 2014-01-14 20:33 +0100
    Re: Python 3.x adoption Skip Montanaro <skip@pobox.com> - 2014-01-14 13:38 -0600
      Re: Python 3.x adoption beliavsky@aol.com - 2014-01-17 14:16 -0800
        Re: Python 3.x adoption Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-01-17 22:51 +0000
        Re: Python 3.x adoption Terry Reedy <tjreedy@udel.edu> - 2014-01-17 18:03 -0500
          Re: Python 3.x adoption beliavsky@aol.com - 2014-01-18 05:27 -0800
            Re: Python 3.x adoption Travis Griggs <travisgriggs@gmail.com> - 2014-01-21 11:04 -0800
            Re: Python 3.x adoption Chris Kaynor <ckaynor@zindagigames.com> - 2014-01-21 11:15 -0800
            Re: Python 3.x adoption Chris Angelico <rosuav@gmail.com> - 2014-01-22 06:25 +1100
        Re: Python 3.x adoption MRAB <python@mrabarnett.plus.com> - 2014-01-17 23:12 +0000
        Re: Python 3.x adoption Chris Angelico <rosuav@gmail.com> - 2014-01-18 10:17 +1100
        Re: Python 3.x adoption Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-01-17 20:01 -0500
        Re: Python 3.x adoption Ben Finney <ben+python@benfinney.id.au> - 2014-01-18 12:18 +1100
        Re: Python 3.x adoption Ben Finney <ben+python@benfinney.id.au> - 2014-01-18 12:27 +1100
    Re: Python 3.x adoption Chris Angelico <rosuav@gmail.com> - 2014-01-15 06:44 +1100
    Re: Python 3.x adoption Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-01-15 02:55 +0000
      Re: Python 3.x adoption MRAB <python@mrabarnett.plus.com> - 2014-01-15 03:30 +0000
    Re: Python 3.x adoption Travis Griggs <travisgriggs@gmail.com> - 2014-01-15 07:43 -0800
      Re: Python 3.x adoption Piet van Oostrum <piet@vanoostrum.org> - 2014-01-16 13:57 +0100
    Re: Python 3.x adoption Chris Angelico <rosuav@gmail.com> - 2014-01-16 03:14 +1100
    Re: Python 3.x adoption Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-01-15 16:46 +0000
    Re: Python 3.x adoption Chris Angelico <rosuav@gmail.com> - 2014-01-16 04:08 +1100
    Re: Python 3.x adoption Christopher Welborn <cjwelborn@live.com> - 2014-01-15 11:37 -0600
    Re: Python 3.x adoption Grant Edwards <invalid@invalid.invalid> - 2014-01-17 15:27 +0000
      Re: Python 3.x adoption Tim Chase <python.list@tim.thechases.com> - 2014-01-17 10:15 -0600
        Re: Python 3.x adoption Grant Edwards <invalid@invalid.invalid> - 2014-01-17 20:02 +0000
          Re: Python 3.x adoption Roy Smith <roy@panix.com> - 2014-01-17 21:49 -0500
      Re: Python 3.x adoption Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-01-17 16:21 +0000
      Re: Python 3.x adoption Terry Reedy <tjreedy@udel.edu> - 2014-01-17 17:10 -0500

Page 1 of 2  [1] 2  Next page →

#63928 — Python 3.x adoption

Hi

What's the problem with Python 3.x? It was first released in 2008, but
web hosting companies still seem to offer Python 2.x rather.

For example, Google App Engine only offers Python 2.7.

What's wrong?...

-- 
http://people.eisenbits.com/~stf/
http://www.eisenbits.com/

OpenPGP: 80FC 1824 2EA4 9223 A986  DB4E 934E FEA0 F492 A63B

[toc] | [next] | [standalone]

#63931

> What's the problem with Python 3.x? It was first released in 2008, but
> web hosting companies still seem to offer Python 2.x rather.
>
> For example, Google App Engine only offers Python 2.7.
>
> What's wrong?...

What makes you think anything's wrong? Major changes to any
established piece of software takes a fairly long while to infiltrate.
Lots of COBOL and Fortran 77 still running out there. I imagine there
are still more than a few DOS and Windows 3.1 boxes as well. Why
should adoption of Python 3.x be any different?

Skip

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

#64200

On Tuesday, January 14, 2014 2:38:29 PM UTC-5, Skip Montanaro wrote:
> > What's the problem with Python 3.x? It was first released in 2008, but
> 
> > web hosting companies still seem to offer Python 2.x rather.
> 
> >
> 
> > For example, Google App Engine only offers Python 2.7.
> 
> >
> 
> > What's wrong?...
> 
> 
> 
> What makes you think anything's wrong? Major changes to any
> 
> established piece of software takes a fairly long while to infiltrate.
> 
> Lots of COBOL and Fortran 77 still running out there.

I don't think the Fortran analogy is valid.

The Fortran standards after F77 are almost complete supersets of F77, and Fortran compiler vendors handle even the deleted parts of F77, knowing their customer base. Therefore you do not need to rewrite old Fortran code to use it with Fortran 95 or 2003 compilers, and you can easily mix old-style and modern Fortran. Later Fortran standards did not invalidate basic syntax such as print statements, as Python 3 did. Python 2 and 3 are incompatible in ways that do not apply to Fortran standards pre- and post- F77.

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

#64201

On 17/01/2014 22:16, beliavsky@aol.com wrote:
> On Tuesday, January 14, 2014 2:38:29 PM UTC-5, Skip Montanaro wrote:
>>> What's the problem with Python 3.x? It was first released in 2008, but
>>
>>> web hosting companies still seem to offer Python 2.x rather.
>>
>>>
>>
>>> For example, Google App Engine only offers Python 2.7.
>>
>>>
>>
>>> What's wrong?...
>>
>>
>>
>> What makes you think anything's wrong? Major changes to any
>>
>> established piece of software takes a fairly long while to infiltrate.
>>
>> Lots of COBOL and Fortran 77 still running out there.
>
> I don't think the Fortran analogy is valid.
>
> Later Fortran standards did not invalidate basic syntax such as print statements, as Python 3 did. Python 2 and 3 are incompatible in ways that do not apply to Fortran standards pre- and post- F77.
>

A good choice to make, the capability to use "from __future__ import 
print_function", or whatever the actual thing is, has been available for 
years.  2to3 has been available for years, six was released at the end 
of June 2010 and there's now future, see http://python-future.org/
Admittedly there's a problem with the porting of code which mixes bytes 
and strings, but that's being addressed right now via PEPs 460, 461 and 
possibly others.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

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

#64202

On 1/17/2014 5:16 PM, beliavsky@aol.com wrote:

> I don't think the Fortran analogy is valid.

The appropriate analogy for the changes between Python 2.x and 3.x, 
which started about 1 and 2 decades after the original Python, are the 
changes between Fortran IV/66 and Fortran 77, also about 1 and 2 decades 
after the original Fortran. The latter two have a comparable number of 
differences. "In this revision of the standard [F77], a number of 
features were removed or altered in a manner that might invalidate 
previously standard-conforming programs.
   https://en.wikipedia.org/wiki/Fortran
Not mentioned in the wiki article is the change in calling convention 
from call by value to call by reference (or maybe the opposite). I 
remember a program crashing because of this when I tried it with F77.

Overall, there was more churn in Fortran up to F77 than there was in 
Python up to 3.0.

> The Fortran standards after F77 are almost complete supersets of F77, and Fortran compiler vendors handle even the deleted parts of F77, knowing their customer base. Therefore you do not need to rewrite old Fortran code to use it with Fortran 95 or 2003 compilers, and you can easily mix old-style and modern Fortran. Later Fortran standards did not invalidate basic syntax such as print statements, as Python 3 did. Python 2 and 3 are incompatible in ways that do not apply to Fortran standards pre- and post- F77.

Since 3.0, we have added new syntax ('yield from', u'' for instance) but 
I do not believe we have deleted or changed any syntax (I might have 
forgotten something minor) and I do not know of any proposal to do so 
(except to re-delete u'', which should only be used as a temporary 
crutch for 2&3 code).

 > Python 2 and 3 are incompatible in ways that do not apply to Fortran 
 > standards pre- and post- F77.

As stated above, I disagree with respect to pre-F77 and F77. Did you 
actually program in both, as I did?

-- 
Terry Jan Reedy

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

#64231

On Friday, January 17, 2014 6:03:45 PM UTC-5, Terry Reedy wrote:
> On 1/17/2014 5:16 PM, beliavsky@aol.com wrote:
 
>  > Python 2 and 3 are incompatible in ways that do not apply to Fortran 
> 
>  > standards pre- and post- F77.
> 
> 
> 
> As stated above, I disagree with respect to pre-F77 and F77. Did you 
> 
> actually program in both, as I did?
> 
> 
> 
> -- 
> 
> Terry Jan Reedy

I should have written "F77 and post F77". I have programmed in Fortran 77, 90, and 95.

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

#64441

Looks like the 2/3 topic has lain fallow for a couple of days, gotta keep it burning…

I’m  a relatively recent python convert, but been coding and talking to others about coding for many moons on this big blue orb. I think the industrial side of this debate has been talked up quite a bit. We have tools, we have the wall of shame/superpowers for libraries and projects.

I think the desires of the core of people moving python forward are pretty clear to those of us that plug in. Move to 3. Period. We can debate, hate it, go on all day, but they’ve been pretty steady.

I’ve had a bunch of interns around me lately though, wanting to get into python, and this is where I find the momentum really breaks down. If newcomers go to take an online course in python, they might try MIT’s Open Courseware (who doesn’t want to learn from the illustrious MIT after all?). They’ll be taught Python 2, not 3. Or they might try Code Academy. Again, they’ll be taught 2, not 3. If the newbie googles “python reference”… top link will be python 2.

So in my mind, the wall of superpowers/shame is no longer well aligned with where the real battlefront of adoption is at. The legacy of the internet caches and education sites are. Personally, I have no idea why an education site would favor a version that sooner or later they’re going to have to try and explain how super() works.

The other area, I think, that puts a dent in perceived adoption is in alternate interpreters. Back in the day, everyone was making some branch of python (e.g. IronPython, Jython, Cython, PyPy, Stackless, etc). All of them did python 2. Very few are doing python 3. Some have been abandoned (as is the nature of research endeavors like these were), but there doesn’t seem to be the broad swath of people still building alternate python expressions, especially in python 3. Being a fan of JIT, I have big hopes for PyPy, I can’t figure out why they aren’t pitching their “cutting edge” interpreter, for the “cutting edge” version of python. There should be a wall of superpowers/shame for interpreters.

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

#64443

[Multipart message — attachments visible in raw view] — view raw

On Tue, Jan 21, 2014 at 11:04 AM, Travis Griggs <travisgriggs@gmail.com>wrote:

> Being a fan of JIT, I have big hopes for PyPy, I can’t figure out why they
> aren’t pitching their “cutting edge” interpreter, for the “cutting edge”
> version of python. There should be a wall of superpowers/shame for
> interpreters.


A very quick look at the PyPy website shows they are working on a 3.x
compatible version:
http://doc.pypy.org/en/latest/release-pypy3-2.1.0-beta1.html. Its just
still in beta.

Chris

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

#64447

On Wed, Jan 22, 2014 at 6:04 AM, Travis Griggs <travisgriggs@gmail.com> wrote:
> I’ve had a bunch of interns around me lately though, wanting to get into python, and this is where I find the momentum really breaks down. If newcomers go to take an online course in python, they might try MIT’s Open Courseware (who doesn’t want to learn from the illustrious MIT after all?). They’ll be taught Python 2, not 3.
>

Courses are inherently laggy. I don't know how long it takes to write
a course, get it approved, and then advertise it so you get some
students, but I suspect it's a good while. I'd say that it's only
since 3.3 (some would argue 3.2, others 3.4) that Py3 has been the
clear winner in the new-application debate; give it a few more years
before courses start teaching Py3. Of course, anyone who comes to a
rapid communication venue like python-list can learn the state of the
art (in the original sense), but if you want a degree in Comp Sci and
you have to take X courses to get it, chances are you'll learn Py2
along the way.

ChrisA

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

#64203

On 2014-01-17 23:03, Terry Reedy wrote:
[snip]
> Since 3.0, we have added new syntax ('yield from', u'' for instance) but
> I do not believe we have deleted or changed any syntax (I might have
> forgotten something minor) and I do not know of any proposal to do so
> (except to re-delete u'', which should only be used as a temporary
> crutch for 2&3 code).
>
There was the removal of backticks.

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

#64204

On Sat, Jan 18, 2014 at 10:12 AM, MRAB <python@mrabarnett.plus.com> wrote:
> On 2014-01-17 23:03, Terry Reedy wrote:
> [snip]
>
>> Since 3.0, we have added new syntax ('yield from', u'' for instance) but
>> I do not believe we have deleted or changed any syntax (I might have
>> forgotten something minor) and I do not know of any proposal to do so
>> (except to re-delete u'', which should only be used as a temporary
>> crutch for 2&3 code).
>>
> There was the removal of backticks.

Wasn't that removed _in_, not _since_, 3.0?

ChrisA

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

#64208

On Fri, 17 Jan 2014 18:03:45 -0500, Terry Reedy <tjreedy@udel.edu>
declaimed the following:


>Not mentioned in the wiki article is the change in calling convention 
>from call by value to call by reference (or maybe the opposite). I 
>remember a program crashing because of this when I tried it with F77.
>
	Maybe because there was NO change in calling convention. FORTRAN was
call by reference in all versions I've worked with. DEC did add special
"functions" to force a parameter to be passed as "value", "reference", or
"descriptor" -- mostly to interface with other languages (descriptor is
what was used for character strings -- basically a structure containing the
length of the string/buffer, and the address of said buffer).

	However, one may have encountered an implementation that did some
checking for duplicated parameter addresses -- or may have behaved
internally as a value/return system, wherein the by-reference parameters
were copied to local/stack storage, manipulated, and only written back to
the reference address on exit. That would result in differences:

	a = 1
	call xyz(a, b, a)

	subroutine xyz(x, y, z)

	x = x + 1
	z = z * 2

...
	In a true by-reference system, "a" would turn into 2 for the first
assignment, but then turn into 4 after the second.

	In value/return, the second assignment still sees "1" and results in
"2", and thereby "a" becomes "2", not "4"...

	I'd still consider a value/return scheme to be a misbehaving FORTRAN.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#64209

Terry Reedy <tjreedy@udel.edu> writes:

> Since 3.0, we have added new syntax ('yield from', u'' for instance)
> but I do not believe we have deleted or changed any syntax (I might
> have forgotten something minor)

I'm aware of the removal of ‘`foo`’ (use ‘repr(foo)’ instead), and
removal of ‘except ExcClass, exc_instance’ (use ‘except ExcClass as
exc_instance’ instead).

-- 
 \      “For my birthday I got a humidifier and a de-humidifier. I put |
  `\  them in the same room and let them fight it out.” —Steven Wright |
_o__)                                                                  |
Ben Finney

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

#64210

Ben Finney <ben+python@benfinney.id.au> writes:

> Terry Reedy <tjreedy@udel.edu> writes:
>
> > Since 3.0, we have added new syntax ('yield from', u'' for instance)
> > but I do not believe we have deleted or changed any syntax (I might
> > have forgotten something minor)
>
> I'm aware of the removal of ‘`foo`’ (use ‘repr(foo)’ instead), and
> removal of ‘except ExcClass, exc_instance’ (use ‘except ExcClass as
> exc_instance’ instead).

Ah, you meant “deleted or changed any Python 3 syntax”. No, I'm not
aware of any such changes.

-- 
 \             “I have never imputed to Nature a purpose or a goal, or |
  `\    anything that could be understood as anthropomorphic.” —Albert |
_o__)                                    Einstein, unsent letter, 1955 |
Ben Finney

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

#63932

On Wed, Jan 15, 2014 at 6:33 AM, Staszek <noreply@eisenbits.com> wrote:
> What's the problem with Python 3.x? It was first released in 2008, but
> web hosting companies still seem to offer Python 2.x rather.
>
> For example, Google App Engine only offers Python 2.7.
>
> What's wrong?...

There's nothing wrong with Python 3, but as Skip says, it takes time
for people to migrate.

Most cheap web hosts don't offer Python _at all_, but those that do
have the choice of which version(s) to provide. It may be possible to
call up either a 2.x or a 3.x by looking for "python" or "python3" -
give it a try.

ChrisA

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

#63958

On Tue, 14 Jan 2014 20:33:50 +0100, Staszek wrote:

> Hi
> 
> What's the problem with Python 3.x? 

Nothing.

> It was first released in 2008, 

That was only five years ago.

I know that to young kids today who change their iPhone every six months, 
five years sounds like a lot, but in the world of mature software, five 
years is a blink of the eye. People still use Fortran code that is 30 
years old. I know of at least one person supporting a Python 1.5 system, 
which is about 15 years old. RedHat is still providing commercial support 
for Python 2.3, and their Python 2.7 commercial support won't end until 
2023 or 2024.


> but web hosting companies still seem to offer Python 2.x rather.
> 
> For example, Google App Engine only offers Python 2.7.
> 
> What's wrong?...

Hosting companies are conservative. Just look at how many still offer old 
versions of PHP. These guys offer PHP 5.2 to 5.5:

http://www.a2hosting.com/php-hosting

WordPress will run on PHP 4.1!

So it is no surprise that Python hosting companies still mostly provide 
2.7.



-- 
Steven

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

#63960

On 2014-01-15 02:55, Steven D'Aprano wrote:
> On Tue, 14 Jan 2014 20:33:50 +0100, Staszek wrote:
>
>> Hi
>>
>> What's the problem with Python 3.x?
>
> Nothing.
>
>> It was first released in 2008,
>
> That was only five years ago.
>
> I know that to young kids today who change their iPhone every six months,
> five years sounds like a lot, but in the world of mature software, five
> years is a blink of the eye. People still use Fortran code that is 30
> years old. I know of at least one person supporting a Python 1.5 system,
> which is about 15 years old. RedHat is still providing commercial support
> for Python 2.3, and their Python 2.7 commercial support won't end until
> 2023 or 2024.
>
>
>> but web hosting companies still seem to offer Python 2.x rather.
>>
>> For example, Google App Engine only offers Python 2.7.
>>
>> What's wrong?...
>
> Hosting companies are conservative. Just look at how many still offer old
> versions of PHP. These guys offer PHP 5.2 to 5.5:
>
> http://www.a2hosting.com/php-hosting
>
> WordPress will run on PHP 4.1!
>
> So it is no surprise that Python hosting companies still mostly provide
> 2.7.
>
Not to mention Windows XP, which is only now being dropped by Microsoft.

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

#63993

Here we go again…

On Jan 14, 2014, at 11:33 AM, Staszek <noreply@eisenbits.com> wrote:

> Hi
> 
> What's the problem with Python 3.x? It was first released in 2008, but
> web hosting companies still seem to offer Python 2.x rather.
> 
> For example, Google App Engine only offers Python 2.7.
> 
> What's wrong?...

Maybe what it means is that Python3 is just fine, but Google App Engine isn’t seeing a lot of development/improvement lately, that it’s just in maintenance mode. Imagine that, Google not finishing/maintaining something.

I wish amongst the periodic maelstroms of Python2 vs Python3 handwringing, people would look at the new project starts. When I work with someone’s old library that they’ve moved on from, I use python2 if I have to, but anytime I can, I use python3.

Personally, I wish they’d start python4, sure would take the heat out of the 3 vs 2 debates. And maybe there’d be a program called twentyfour as a result.

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

#64078

Travis Griggs <travisgriggs@gmail.com> writes:

> Personally, I wish they’d start python4, sure would take the heat out of
> the 3 vs 2 debates. And maybe there’d be a program called twentyfour as
> a result.

twelve would be sufficient, I would think.
-- 
Piet van Oostrum <piet@vanoostrum.org>
WWW: http://pietvanoostrum.com/
PGP key: [8DAE142BE17999C4]

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

#63994

On Thu, Jan 16, 2014 at 2:43 AM, Travis Griggs <travisgriggs@gmail.com> wrote:
> Personally, I wish they’d start python4, sure would take the heat out of the 3 vs 2 debates. And maybe there’d be a program called twentyfour as a result.

Learn All Current Versions of Python in Twenty-Four Hours?

ChrisA

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web