Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python 2.8?

lwn.net

Post reply on HN
Print view View original

31–40 of 74 posts

Re: Python 2.8?

#31

Post by [deleted] »

scrollaway wrote: post #10
frunzales wrote: post #4

The amount of trolling in that thread is incredible. I don't understand why an average Joe needs to contradict Guido on trademark matters.

Because some people are hateful by nature and see Guido as Satan incarnate for "hating Python 2". And no, I'm not exaggerating, you just need to look at the comments: https://github.com/naftaliharris/placeholder/issues/47#issue... I read through that thread the other day and it breaks my heart to know that there are people who think like that. Honestly. On various occasions I've reasoned (and not reasoned) with the m…

[deleted]

Re: Python 2.8?

#32

Post by daveguy »

didibus wrote: post #14
daveguy wrote: post #7

I'm glad Guido considers this a toy. Anyone interested in helping out the github repo is here: https://github.com/naftaliharris/placeholder

He's right though. Backporting features will be hard, and it looks like the wrong move. If you wanted to fork just fork, and evolve python 2.7 on its own. Why try to create an inferior python 3? I could see security fix releases be useful. Giving people more time to transition is going to benefit some projects. But in terms of feature, it does sound toyish. Appart from that, it actually doesn't look like there's any…

> Why try to create an inferior python 3?

I think the point is -- it will not be an inferior python 3.

It will be a python 2 with the best non-code-breaking parts of python 3. Sane byte handling + bug fixes - breaking changes.

That will make it a superior python 3.

Re: Python 2.8?

#33

Post by rcthompson »

daveguy wrote: post #32
didibus wrote: post #14

Earlier quoted context omitted.

He's right though. Backporting features will be hard, and it looks like the wrong move. If you wanted to fork just fork, and evolve python 2.7 on its own. Why try to create an inferior python 3? I could see security fix releases be useful. Giving people more time to transition is going to benefit some projects. But in terms of feature, it does sound toyish. Appart from that, it actually doesn't look like there's any…

> Why try to create an inferior python 3? I think the point is -- it will not be an inferior python 3. It will be a python 2 with the best non-code-breaking parts of python 3. Sane byte handling + bug fixes - breaking changes. That will make it a superior python 3.

How do you get sane byte handling without breaking backward compatibility? I thought that was the original reason for breaking compatibility in Py3k.

Re: Python 2.8?

#34

Post by daveguy »

rcthompson wrote: post #33
daveguy wrote: post #32

Earlier quoted context omitted.

> Why try to create an inferior python 3? I think the point is -- it will not be an inferior python 3. It will be a python 2 with the best non-code-breaking parts of python 3. Sane byte handling + bug fixes - breaking changes. That will make it a superior python 3.

How do you get sane byte handling without breaking backward compatibility? I thought that was the original reason for breaking compatibility in Py3k.

Sane is py2. Default is bytes not some Unicode string. If you want Unicode use u"". If you want what is usually needed in algorithms (aka bytes) use "".

Re: Python 2.8?

#35

Post by frik »

copx wrote: post #8
douche wrote: post #3

The 2.X => 3.X transition really appears to have been bungled here, which is a shame. I really liked Python before I got deeply into the .Net world, but it has become less than enticing with this fragmentation. Meanwhile other languages seem to have taken up the vanguard position, which leaves Python in kind of an awkward position, between the new hotness and the tried-and-true enterprisey ecosystems

>The 2.X => 3.X transition really appears to have been bungled here, which is a shame. Obviously, the question is what went wrong. Personally I think the dev team gave users too much time to switch. The Python devs should have only given users one or two years to upgrade. Making it clear that all support for Python 2 would end after that period. Another mistake was that when originally released Python 3 did not offer…

Exactly.

For language devs. It's always good to learn from mistakes from the past. PHP 6 failed, then PHP stayed with 5.x and moved directly from v5 to v7 - that worked out fine.

The Python 2 to 3 is an important lesson as well. Ruby (afaik 1 to 2), dotNet 1 to 2 and 4 to dotNetCore 1, Swift 1 to 2 to 3, ... are several more cases that were rocky for developers.

Re: Python 2.8?

#36

Post by mfukar »

daveguy wrote: post #34
rcthompson wrote: post #33

Earlier quoted context omitted.

How do you get sane byte handling without breaking backward compatibility? I thought that was the original reason for breaking compatibility in Py3k.

Sane is py2. Default is bytes not some Unicode string. If you want Unicode use u"". If you want what is usually needed in algorithms (aka bytes ) use "".

> what is usually needed in algorithms

Depends what you're working with, obviously.

Re: Python 2.8?

#37

Post by naftaliharris »

didibus wrote: post #14
daveguy wrote: post #7

I'm glad Guido considers this a toy. Anyone interested in helping out the github repo is here: https://github.com/naftaliharris/placeholder

He's right though. Backporting features will be hard, and it looks like the wrong move. If you wanted to fork just fork, and evolve python 2.7 on its own. Why try to create an inferior python 3? I could see security fix releases be useful. Giving people more time to transition is going to benefit some projects. But in terms of feature, it does sound toyish. Appart from that, it actually doesn't look like there's any…

(I'm the primary author of this interpreter).

> Backporting features will be hard

It's actually pretty straightforward: I just find the relevant changes in the Python 3 history, and apply them to Python 2. Usually a handful of things have changed between 2 and 3, so I typically can't just pipe the diff to "git apply -3", but frankly backporting features is more tedious than difficult. If you're interested, for example, here's my recent implementation of the "nonlocal" keyword; you can see the commit messages reference the Python 3 commits: https://github.com/naftaliharris/placeholder/pull/60

> Why try to create an inferior python 3?

The ultimate goal is to build an interpreter that can run both Python 2 and 3 code. Unfortunately, there is some code that runs and has different behavior under Python 2 and Python 3 (e.g., 'print("a", "b")' ), so anyone who wants to write an interpreter that can run both kinds of code will need to decide what to do there. I decided to defer to Python 2 behavior in those cases, since most of my code is in Python 2 and I don't want to change it. :-)

Re: Python 2.8?

#38

Post by placebo »

Back when python 3 was introduced and after learning of breaking backward compatibility my first thought was, "good luck with that"...

Wanting to create something better is not surprising. What was surprising (to me at least) is not seeing that people don't like change unless they see a really dramatic benefit to what they already have, and clearly see that the advantages to making that change far outweigh the discomfort of the process.

Most people have a really hard time changing from something they know, even if it's less than perfect. Actually, even if it sucks. Ask any marketer, salesman, social worker or psychologist and you will see this is not limited to programming languages, and beyond the psychology, change has an economic price that needs to be justified.

So, years later, the only thing I'm surprised at is that Python 3 actually caught on to the extent it did. I don't know whether to attribute this more to the quality of the language or the energy that went into promoting migration to it, but its current adoption rate to me is a mark of success when one tries to compare it with other attempts to reeducate a well established market.

Re: Python 2.8?

#39

Post by ram_rar »

ubernostrum wrote: post #29
ram_rar wrote: post #13

I am afraid that, the python community has messed up 2.x => 3.X transition. Until 3.3, there seemed no incentive to port your codebase to Python 3.X. With golang getting a lot of traction and compiler tools like grumpy (python -> Go), I would rather invest time to transition into golang as apposed to transition to 3.X.

I am afraid that, the python community has messed up 2.x => 3.X transition. Until 3.3, there seemed no incentive to port your codebase to Python 3.X. Just to bring up a small counterpoint: I don't think anyone really expected the early 3.x releases to be used in production. They were, as I recall, intended primarily as proof-of-concept releases to let people start looking at what porting would involve, and to get fee…

> I don't think anyone really expected the early 3.x releases to be used in production.

I see this as a huge red flag. Its ok, to break/experiment things until you reach 1.0. After that, the core development team must factor in the consequences of breaking backwards compatibility.

Re: Python 2.8?

#40

Post by ram_rar »

Cyph0n wrote: post #18
ram_rar wrote: post #13

I am afraid that, the python community has messed up 2.x => 3.X transition. Until 3.3, there seemed no incentive to port your codebase to Python 3.X. With golang getting a lot of traction and compiler tools like grumpy (python -> Go), I would rather invest time to transition into golang as apposed to transition to 3.X.

Transitioning from Python to Go isn't as easy as you make it out to be. Good luck finding solid alternatives to the likes of Numpy, scikit-learn, Pandas, SQLAlchemy, BeautifulSoup, Flask etc. Oh, and not to mention the community surrounding these and other popular Python libraries.

Numpy / scipy and scikit-learn are the only things that are holding me back. Apart from that, I think its just a matter of time golang will have similar libraries in its ecosystem. Afaik, for regular CRUD apps golang can pretty much replace whole of python with better performance (in terms of concurrency).
Post reply on HN