Will Python 3.x ever become the actual standard?

[Peter Cacioppi]

I said

"Even Bill F*ng Gates was reluctant to break back compatibility,"

Reluctant to do so with his own stuff. Obviously he "embraced and extended" other peoples work. Don't get me started, Gates is Bizarro Guido. Good work with vaccines though.

 

[Ethan Furman]

Moreover, you get a lot of the good stuff with 2.7.

And the "good stuff" in 2.7 makes it easier to take that last step to 3.x when the time comes to do so.

 

[Steven D'Aprano]

I said

"Even Bill F*ng Gates was reluctant to break back compatibility,"

Don't be fooled though, Python is *extremely* reluctant to break
backwards compatibility too. That's why Python has the "__future__"
directive, and why some warts have ended up enshrined in the language.

For example, although string exceptions were recognised as a bad idea for
many years, there was a long deprecation process to get rid of them. It
took at least 11 years to remove them completely:

http://python-history.blogspot.com.au/2009/03/how-exceptions-came-to-be-classes.html

Nick Coglan describes some of the completing pressures on a language like
Python:

http://www.boredomandlaziness.org/2011/04/musings-on-culture-of-python-dev.html


Because of the tension between users demanding Python change more
quickly, and those demanding it changes more slowly, you can't satisfy
everyone. You probably can't even satisfy anyone.

 

[Chris Angelico]

Moreover, you get a lot of the good stuff with 2.7. Along with more library support. So the smart decision is to code your project 2.7, even though the best thing for Pythonistan would be for us all to voluntarily migrate to 3.x.

I won't flame you, but I will disagree with you

You may get "a lot of" the good stuff with 2.7, but there are plenty
of things you won't get - and the gap will widen with every Python
release. As of 3.3, you're missing out on, among other things:

* PEP 393 strings - high performance and perfect Unicode handling
* 'yield from'
* Major improvements to 'import'
* High performance 'decimal'

When 3.4 comes out, add to the list:

* enumerations
* asyncio
* Argument Clinic (introspection)

When 3.5 comes out, your 2.7 program will additionally be unable to use:

* Who knows?
* But it'll be exciting.

If you insist on not moving to 3.x, I strongly recommend some future
imports - unicode_literals, division, print_function - to make your
2.7 program behave more like a 3.x one. That'll ease the pain of
transition, though you'll still probably run into problems with
unicode vs bytes in places where your code used to be oblivious...
which means your code will become guaranteed-correct when you move to
3.x, where the 2.7 version was merely accidentally-correct.

ChrisA

 

[Peter Cacioppi]

Chris The Angel said :
"I won't flame you, but I will disagree with you "

good, that's why I'm here


" but there are plenty of things you won't get - and the gap will widen with very Python release."

Yes I skimmed that laundry list before deciding. I still think I made the right decision.

I'll port it someday. I'll own the iPhone 5s (or whatever the latest one is) someday. I'm not an early adopter kind of person.

I'd like to think my project (which looks like it is getting funding, hooray!) will advance the glory of Pythonistan simply by doing cool stuff with 2.7. I'll port it someday (unless it flops, which won't happen, because I won't let it).

Good discussion though, thanks!

 

[Chris Angelico]

I'd like to think my project (which looks like it is getting funding, hooray!) will advance the glory of Pythonistan simply by doing cool stuff with 2.7. I'll port it someday (unless it flops, which won't happen, because I won't let it).

Which is why I mentioned those helpful __future__ directives, so you
can code now and be better able to port in five years when you feel
that it's important enough to do so. It's a good system.

ChrisA

 

[Mark Lawrence]

Because it's trivially easy under Unix? Three commands:

./configure
make
make install

will generally do the job. Unless it doesn't work, in which case it's a
world of pain. But that's no different from Windows, except that somebody
else has already worked through the pain for you.

Precisely my point. I suspect being a Python core dev must do wonders
for the moral fibre. Your pristine, fully reviewed patch improves
performance by 10,000% and works wonderfully except on buildbot xyz and
has to be reverted. How do they do it?

 

[Antoine Pitrou]

I am starting to have doubts as to whether Python 3.x will ever be

actually adopted by the Python community at

large as their standard.

We're planning to start the switch on 25th December 2013, 14h UTC.
It should be finished at most 48 hours later. You should expect some
intermittent problems during the first few hours, but at the end
all uses of Twisted will be replaced with Tornado and asyncio (and
camelCase methods will have ceased to be).

By the way, if you want to join us, one week later we'll also switch
the Internet to IPv6 (except Germany).

Regards

Antoine.

 

[Chris Angelico]

Precisely my point. I suspect being a Python core dev must do wonders for
the moral fibre. Your pristine, fully reviewed patch improves performance
by 10,000% and works wonderfully except on buildbot xyz and has to be
reverted. How do they do it?

It's called Diplomacy, and it's a class skill for bards, clerics,
druids, monks, paladins, rogues, and core developers.

ChrisA

 

[Chris Angelico]

actually adopted by the Python community at

We're planning to start the switch on 25th December 2013, 14h UTC.
It should be finished at most 48 hours later. You should expect some
intermittent problems during the first few hours, but at the end
all uses of Twisted will be replaced with Tornado and asyncio (and
camelCase methods will have ceased to be).

By the way, if you want to join us, one week later we'll also switch
the Internet to IPv6 (except Germany).

Excellent! It's about time. IPv4 depletion happened some time ago.

What's your schedule for the replacement of Windows XP (with either a
later Windows or with Linux, open to either option)?

ChrisA

 

[Mark Lawrence]

actually adopted by the Python community at

We're planning to start the switch on 25th December 2013, 14h UTC.
It should be finished at most 48 hours later. You should expect some
intermittent problems during the first few hours, but at the end
all uses of Twisted will be replaced with Tornado and asyncio (and
camelCase methods will have ceased to be).

By the way, if you want to join us, one week later we'll also switch
the Internet to IPv6 (except Germany).

Regards

Antoine.

You forgot to mention that the whole world is switching to driving on
the left hand side of the road at the same time.

 

[Peter Cacioppi]

Angelico said:
"Which is why I mentioned those helpful __future__ directives,"

OK, thanks, I'll study the __future__.

I will port to 3.x in less than 60 months, or my name isn't Cacioppi. (So, in the worst case, I might have to backport a change to my name).

 

[Damien Wyart]

I am starting to have doubts as to whether Python 3.x will ever be

actually adopted by the Python community at large as their standard.
Years have passed, and a LARGE number of Python programmers has not
even bothered learning version 3.x. Why am I bothered by this? Because
of lot of good libraries are still only for version 2.x, and there is
no sign of their being updated for v3.x. I get the impression as if
3.x, despite being better and more advanced than 2.x from the
technical point of view, is a bit of a letdown in terms of adoption.

Some Linux distributions will certainly switch to Python 3 by default,
sooner or later. Fedora has decided to do so for their 22 release:
http://lwn.net/Articles/571528/

 

[ishish]

Am 24.10.2013 14:29, schrieb Damien Wyart:

Some Linux distributions will certainly switch to Python 3 by
default,
sooner or later. Fedora has decided to do so for their 22 release:
http://lwn.net/Articles/571528/

Saucy Salamander (Ubuntu 13.10, released oct 17th) comes with Python
3.3.

 

[Ned Batchelder]

Some Linux distributions will certainly switch to Python 3 by default,
sooner or later. Fedora has decided to do so for their 22 release:
http://lwn.net/Articles/571528/

I'm not sure what "by default" means, I hope it isn't that "python" runs
Python 3.x. That causes massive confusion on Arch, and will make it
very difficult to support a mixed environment.

--Ned.

 

[Terry Reedy]

I'm not sure what "by default" means, I hope it isn't that "python" runs
Python 3.x. That causes massive confusion on Arch, and will make it
very difficult to support a mixed environment.

It means that 3.x is always present (with 2.x an option) and Fedora's
Python code works with the always-present version.

The actual proposal (FEP? ;-):
https://fedoraproject.org/wiki/Changes/Python_3_as_Default
'''
The main goal is switching to Python 3 as a default, in which state:

DNF is the default package manager instead of Yum, which only works
with Python 2
Python 3 is the only Python implementation in the minimal buildroot
Python 3 is the only Python implementation on the LiveCD
Anaconda and all of its dependencies run on Python 3
cloud-init and all of its dependencies run on Python 3
'''
....
"Upstream recommends that /usr/bin/python point to Python 2 runtime for
the time being, so if we go with that, there shouldn't be any serious
compatibility impact: "

 

[Colin J. Williams]

On 23/10/2013 12:57, (e-mail address removed) wrote:
Years have passed, and a LARGE number of Python programmers has not
even bothered learning version 3.x.

The changes aren't large enough to worry a Python programmer so
effectively there's nothing to learn, other than how to run 2to3.

...there is no sign of their being updated for v3.x.

Could have fooled me. The number is growing all the time. The biggest
problem is likely (IMHO) to be the sheer size of the code base and
limitations on manpower.

I get the impression as if 3.x, despite being better and more advanced
than 2.x from the technical point of view, is a bit of a letdown in
terms of adoption.

I agree with this technical aspect, other than the disastrous flexible
string representation, which has been repeatedly shot to pieces by, er,
one idiot As for adaption we'll get there so please don't do a
Captain Mainwearing[1] and panic. People should also be pursuaded by
watching this from Brett Cannon

Just my 2 pence worth.

[1] From the extremely popular BBC TV series "Dad's Army" of the late
60s and 70s.

It would be good if more of the packages were available, for Python 3.3,
in binary for the Windows user.

I am currently wrestling with Pandas, lxml etc.

Can I assume you're aware of the industrious Christopher Gohlke?

http://www.lfd.uci.edu/~gohlke/pythonlibs/

TJG

Tim,

Many thanks. I have installed lxml. help(lxml) looks good.

I'll keep this link for future use.

It would be good if, after some verification process for each package,
it could be included in PyPi.

Colin W.

PS A problem in building lxml from source is that the build expects
?Cygwin? and I have Mingw32 installed.

 

[Dennis Lee Bieber]

Sorry, there's problems with all version of both Windows and Linux so
we're reverting with immediate effect to VMS.

Wisdom and Intelligence in one...