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

Show HN: Python-to-Python compiler for some 3.6 features in older versions

github.com

Post reply on HN
Print view View original

61–70 of 113 posts

Re: Show HN: Python-to-Python compiler for some 3.6 features in older versions

#61

Post by xrange »

jerryszczerry wrote: post #56
carapace wrote: post #52

Earlier quoted context omitted.

Because it's going to be stable for the next N years. Python 2 is like FORTRAN. It might not be sexy anymore but it's not going anywhere.

> Python 2 is like FORTRAN. It might not be sexy anymore but it's not going anywhere. Except Fortran is, and is going to be, further developed. (So, if a new useful programming concept appears, or a major design mistake is discovered, it always can be patched.) Python 2 is going to be abandoned in 2020. Python 3 will supersede it.

>Python 2 is going to be abandoned in 2020.

But Python 2 is Free Software, so as long as people like it, they can keep improving it:

https://github.com/naftaliharris/tauthon

Re: Show HN: Python-to-Python compiler for some 3.6 features in older versions

#62

Post by tetraodonpuffer »

dbcurtis wrote: post #17

Serious question: Why would anyone still be doing anything with Python 2.7 except porting the last remnants of their code base to 3.X?

if you have a large py2 codebase in a shipping product, can you make an ROI argument that porting to py3 makes sense given the staff months required to do so?

Re: Show HN: Python-to-Python compiler for some 3.6 features in older versions

#63

Post by travisjungroth »

cthalupa wrote: post #59
dbcurtis wrote: post #17

Serious question: Why would anyone still be doing anything with Python 2.7 except porting the last remnants of their code base to 3.X?

Distributing a tool to OS distributions that do not have Python3.x (e.g. RedHat/CentOS 7) where the requirements include 'Not installing any additional packages' I hate it because Python2 is a flaming garbage heap, and 2.7 is what happens when you piss on a flaming garbage heap to put it out, whereas Python 3 is actually a nice language to work in, but until OS distributions get their act together on the Python front…

2 and 3 have like a 90% overlap. How can you call one a flaming garbage heap and the other a nice language?

I worked in Python 2 daily for about a year and a half (doing side stuff in 3), and switched over to Python 3 a few months ago. It's just not that big of a deal. Maybe it's because I'm pretty shielded from the madness of strings vs. bytes (or just import from future).

Re: Show HN: Python-to-Python compiler for some 3.6 features in older versions

#64

Post by xrange »

dbcurtis wrote: post #60
xrange wrote: post #45

Earlier quoted context omitted.

Thank you for signing up to help in the porting effort for FreeCAD and Pyspread to Python 3. Free software projects depend on volunteer contributors like you.

So I've been following FreeCAD since it started. Even tried to get my head around the code base at one point, but the hacking guide was mostly nonexistent in those days, so I moved on to projects that did not skip that very important step. Just to put a stake in the ground, when did FreeCAD start? When did 3.0 come out, along with the announced end-of-life date for 2.7?

Wikipedia says that the first release of FreeCAD was in 2002:

https://en.wikipedia.org/wiki/FreeCAD

...Python 3.0 was released in 2008:

https://www.python.org/download/releases/3.0/

...It looks like the port of FreeCAD to Python 3 stared in 2015:

https://forum.freecadweb.org/viewtopic.php?f=10&t=12534

Re: Show HN: Python-to-Python compiler for some 3.6 features in older versions

#65

Post by orf »

travisjungroth wrote: post #63
cthalupa wrote: post #59

Earlier quoted context omitted.

Distributing a tool to OS distributions that do not have Python3.x (e.g. RedHat/CentOS 7) where the requirements include 'Not installing any additional packages' I hate it because Python2 is a flaming garbage heap, and 2.7 is what happens when you piss on a flaming garbage heap to put it out, whereas Python 3 is actually a nice language to work in, but until OS distributions get their act together on the Python front…

2 and 3 have like a 90% overlap. How can you call one a flaming garbage heap and the other a nice language? I worked in Python 2 daily for about a year and a half (doing side stuff in 3), and switched over to Python 3 a few months ago. It's just not that big of a deal. Maybe it's because I'm pretty shielded from the madness of strings vs. bytes (or just import from future).

> How can you call one a flaming garbage heap and the other a nice language?

The lack of UnicodeDecodeErrors.

Just because there is a 90% overlap doesn't mean one can't be a pile of trash (i think that's a bit harsh though). The improvements under the hood are huge (unicode, no 'new-style' classes, speed improvements etc) as well as syntactic sugar means that as time goes on Python 2 looks worse and worse.

Re: Show HN: Python-to-Python compiler for some 3.6 features in older versions

#66

Post by ben-schaaf »

Marat_Dukhan wrote: post #40
recursive wrote: post #33

Earlier quoted context omitted.

> I like lambda a, b: a + b syntax better than lambda a_b: a_b[0] + a_b[1] It already works this way. Python 3.6.1 (v3.6.1:69c0db5, Mar 21 2017, 17:54:52) [MSC v.1900 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> add = lambda a, b: a + b >>> add(1, 2) 3 > I prefer map/reduce/filter to return lists rather than iterable You can produce a list from any iterable by pa…

lambda a, b: a + b kind of works, but you can't call it with tuple argument (which you could in Python 2.7). This hurts when e.g. you have a list of pairs and try to map when via lambda, e.g.: map(lambda a, b: a+b, [(1, 2), (3, 4)]). Even worse, this won't fail right away in Python 3 (thanks, lazy evaluation in map), but will raise when you try to use the result of map

That doesn't work in the python 2.7 that I'm running, just like python 3 it complains that I don't have enough arguments.

Re: Show HN: Python-to-Python compiler for some 3.6 features in older versions

#67

Post by cthalupa »

travisjungroth wrote: post #63
cthalupa wrote: post #59

Earlier quoted context omitted.

Distributing a tool to OS distributions that do not have Python3.x (e.g. RedHat/CentOS 7) where the requirements include 'Not installing any additional packages' I hate it because Python2 is a flaming garbage heap, and 2.7 is what happens when you piss on a flaming garbage heap to put it out, whereas Python 3 is actually a nice language to work in, but until OS distributions get their act together on the Python front…

2 and 3 have like a 90% overlap. How can you call one a flaming garbage heap and the other a nice language? I worked in Python 2 daily for about a year and a half (doing side stuff in 3), and switched over to Python 3 a few months ago. It's just not that big of a deal. Maybe it's because I'm pretty shielded from the madness of strings vs. bytes (or just import from future).

>How can you call one a flaming garbage heap and the other a nice language?

----------

try:

    import queue as queue
except ImportError:

    import Queue as queue
----------

They couldn't even consistently name portions of the standard library. Python 2 has a few random things where the first letter is capitalized while 99% of everything else isn't.

There's all sorts of things like this, where poor design decisions cause you to sit there with question marks appearing over your head. That 10% takes Python from being a joy to work with to being incredibly frustrating. I would be happy if I could just work exclusively in 3, but making sure things are backwards compatible to 2.7 is a frequent source of driving me up the wall.

>Maybe it's because I'm pretty shielded from the madness of strings vs. bytes (or just import from future).

If you lose this shielding it will help you understand my vitriolic response as well.

Re: Show HN: Python-to-Python compiler for some 3.6 features in older versions

#68

Post by lloeki »

CJefferson wrote: post #50
dbcurtis wrote: post #17

Serious question: Why would anyone still be doing anything with Python 2.7 except porting the last remnants of their code base to 3.X?

Mac still doesn't come with python 3 out of the box, so if i want to distribute a script to people without requiring them to install anything else, python 2 is my only option.

I don't get why Apple doesn't include python 3.x since they can easily slot it as they do for 2.6 and 2.7, and there was no licence change that I know of (in contrast with e.g bash 3.x vs 4.x) to justify that.

Slightly tangential but system ruby is stuck at 2.0.0p648 (which is well into unsupported) and perl v5.18.2 (which I don't know the status support of but is old enough to wonder).

They might as well rip them out and make them an optional package like CLI dev tools for possible backwards compatibility needs (easily installable either with something like xcode-select --install or the java/javac stubs).

Re: Show HN: Python-to-Python compiler for some 3.6 features in older versions

#69

Post by Marat_Dukhan »

ben-schaaf wrote: post #66
Marat_Dukhan wrote: post #40

Earlier quoted context omitted.

lambda a, b: a + b kind of works, but you can't call it with tuple argument (which you could in Python 2.7). This hurts when e.g. you have a list of pairs and try to map when via lambda, e.g.: map(lambda a, b: a+b, [(1, 2), (3, 4)]). Even worse, this won't fail right away in Python 3 (thanks, lazy evaluation in map), but will raise when you try to use the result of map

That doesn't work in the python 2.7 that I'm running, just like python 3 it complains that I don't have enough arguments.

Right, needs brackets: lambda (a, b)

Re: Show HN: Python-to-Python compiler for some 3.6 features in older versions

#70

Post by BeetleB »

dbcurtis wrote: post #17

Serious question: Why would anyone still be doing anything with Python 2.7 except porting the last remnants of their code base to 3.X?

The standard answer to any question like this is:

"Why should I switch to 3.x?" You haven't provided a reason to switch.

I don't know if it was your intent, but your question assumes that Python 3.x is the "default", and that there is some sort of obligation to use it instead of 2.x. That's a premise that a lot of people do not share.

As an example, they may not view 3.x as an "upgrade", but as a different language. So you might as well ask anyone doing work in one language "What reason is there for you to still use language X? Why not use language Y?"

As long as some team is willing to support Python 2.7 (and possibly backport non-breaking features), 2.7 will live on, and there is no reason it should go away. The only strong reason for many to switch to 3.x is "I have a library I need to use that is supported only in 3.x". Or "I need to hire developers, and I can't find people who know 2.x, but I can find those who know 3.x"

Languages are tools. As long as the tool is more than adequate for the task, the burden is on others to justify a change in tool.

Post reply on HN