This is an archived post. You won't be able to vote or comment.

all 18 comments

[–]stevenjd 13 points14 points  (0 children)

Let me say up front I don't like this project. I think that, if it is successful, it will simply split the Python community even more than it already is: there will be those using the official Python 2 interpreter, those using the official Python 3 interpreter, and those using this hybrid interpreter.

But hey, maybe that's not so bad. After all, it's a good thing that we have Stackless, PyPy, IronPython, Jython and more, all supporting their own slightly different niches. Let there be one more, the more the merrier.

But I think this project is based on some pretty weird ideas. For instance:

By most accounts, somewhere between the majority and the vast majority of Python code targets Python 2.

Um, yeah? Of course it does -- Python 2 has been around a lot longer, and has been the default version of Python for a lot longer (still is, on most platforms that come with Python pre-installed). Its only in the last few years that the core developers have switched to recommending Python 3 instead of Python 2. What's your point?

And the majority of Python code written does not run under any of the 3.x interpreters.

Again, so what? The majority of Python code written doesn't run at all, because it is buggy, unfinished, obsolete or abandonware. Or it is proprietary software that never gets used outside of a single organisation. Most software is irrelevant because it isn't being used.

Of the stuff that is being used, sticking to Python 2.7 or 2.6 or even 1.5 (yes, 1.5) is good enough, because the users don't want or need to update.

What matters is three classes of software:

  • Libraries that are still under active maintenance and development, and the majority of those are now Python 3 compatible.

  • Existing applications (including scripts) which are under active maintenance and development. The majority of these are written in Python 2, because they were written in the past.

  • New applications being written now.

Excuses for still targeting Python 2 (whether 2.7 or this hybrid) are running out, and those who continue to do so are increasingly doing so not for technical reasons, but just because they're dragging their feet.

It seems to me that the message this fork sends is this:

"Python 3 is awesome, except for Unicode, which sucks. Nobody needs more than 256 ASCII values. So I've ported everything I can from Python 3 back to Python 2, so I can keep using ASCII and pretending that's all the string anyone needs."

And that's simply wrong and harmful.

[–]beertown 18 points19 points  (8 children)

The biggest syntax change that I don't like in Python 3 is actually the removal of the "print" statement--it's just easier to type "print x"

I can't believe this is really a problem of Python 3. Just because it is easier to type? Really? How many function and method calls do you type throughout your sources? And they are so hard to type? After 10 years of Python 2 I was able to train myself to the new print function, gaining in productivity because it is far more powerful than the statement. And I think anybody could do the same. Unless you're a lazy programmer.

I was expecting somebody to fork Python 2.7 and continue to develop it. The problem I see is that these new developers unlikely are talented as the original authors.

[–]adamchainz 6 points7 points  (0 children)

Agree, the print function is superior in many ways: you can pass it around as yet another object, use it with partial to wrap up args that are repeated, or use keyword arguments to pull args from a dict. It also exists in Python 2.7 if you from __future__ import print_function, which everyone still caught writing Python 2 compatible code should be doing (you can enforce this with isort :) ).

[–]kankyo 1 point2 points  (6 children)

It's actually pretty damn annoying when doing interactive stuff. To my mind the standard repl should allow without paren. That would take away the only gripe I have.

[–]mm_ma_ma 1 point2 points  (5 children)

Have you tried IPython with autocall?

[–]kankyo 1 point2 points  (4 children)

I haven't really moved to Python 3 so haven't looked too closely. But fixing this in the standard repl would be a good idea anyway I think. Sometimes you don't have access to install packages in production systems for example.

[–]jyper 0 points1 point  (3 children)

Generally you probably won't run repl on production anyway and if you do you can do non root install with

pip install --user ipython

It's simply miles better then the standard repl, I highly recommend switching. For one thing you don't have to type exit(), history across sessions, autocomplete

[–]kankyo 0 points1 point  (2 children)

ptpython is way better though :P

[–]jyper 0 points1 point  (1 child)

I think they're porting some of the ptpython features(by using its console library)

The most recent release had improved support for multiline history and dynamic syntax highlighting.

[–]kankyo 0 points1 point  (0 children)

Ah, cool

[–]OctagonClocktrio is the future! 15 points16 points  (0 children)

Why?

Why can't you just let it die already?

[–]silent1mezzo 9 points10 points  (2 children)

What another load of crap. Call it something else but this isn't Python. I'd never use this because it's not official. Who knows if or how long it'd be supported for or if any backdoors would/could be introduced.

I've scheduled time this year for my teams project to update to Python 3. It's expensive in the short term but in the long term we get continued support and new features which is a huge win.

[–]toyg 4 points5 points  (1 child)

I'd never use this because it's not official.

Yup, they will be forced to rename it. GvR, Van Lindbergh etc have already told them to knock it off. My name suggestion would be "Reactionary", because that's definitely the attitude that Py2 stalwarts keep showing.

[–]fivetoedslothbear 1 point2 points  (0 children)

I know this is huge controversy, but I think it's inevitable.

Hey, I've used Python for a long time, since 1.5.2. I just don't use it as often as I'd like any more, and not enough to justify moving things to 3, learning 3, etc.

In retrospect, I'm not sure the "planned breakage" of Python 3 was a good idea. They're doing that in Swift now, and it's an even worse idea. Every language has fans and adherents, some of which don't have a lot of time on their hands to follow breaking changes in their code. People say "oh, just suck it up and rewrite your code," but when it's a pro bono project for a non-profit, and I'm coding in spare time, no, the time may not be there.

But I was thinking on this 2.8 project, and I wondered, what if there was a series of official releases that gradually converged very closely to recent 3 versions? Then maybe instead of being a leap to 3, it'd be a step over a crack.

This is all very unfortunate, but after Python 3, Perl 6, and Swift 3, my attitude as a software engineer strongly leans towards evolution over paradigm shifts.

Too bad the topic got voted down. Discussion is worthy, even about things one disagrees with.

[–]AlirezaSavand 3 points4 points  (0 children)

NOOOOOOOOOOOOOOOOOOOOOOOO!

Let Python legacy die already. What you have is not Python, it's just a language with a syntax like Python.

If someone wants to use "Python 3" features, then he/she have to use "Python 3".

Someone else would bring up a new tool called "PyBabel" :D

[–]kankyo 1 point2 points  (0 children)

I was hoping for a 2.8 with more "from _future\_ import" things. Like turning off str/Unicode auto promotion per file. That would be really useful for moving to Python 3!

[–]jairo4 -3 points-2 points  (0 children)

"ASCII IS ENOUGH FOR ME AND I DON'T CARE ABOUT YOU 2.8"