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

71–80 of 113 posts

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

#71

Post by amyjess »

cthalupa wrote: post #67
travisjungroth wrote: post #63

Earlier quoted context omitted.

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 yo…

Yet Python 3 still has logging.getLogger()

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

#72

Post by chc »

dbcurtis wrote: post #57
chc wrote: post #49

Earlier quoted context omitted.

Asking this question without disqualifying the answer "No breaking changes whatsoever" usually just generates a bunch of different ways of phrasing that.

No, I don't buy that. IBM successfully transitioned a huge customer base from 709/7090 36-bit words to System 360 32 bit words. The transition from 32 to 64 bit addresses was rocky for a lot of architectures. DEC Alpha, Intel Itanium. But are you still running a 32 bit OS? K&R C no longer compiles. Not that the C to C++14 transition is what I would call an example of greatness, but it is somewhere along the success s…

Yes, I agree with you. That's why I said you should disqualify that answer. It's by far the most common answer, but it's also obviously not the right answer.

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

#73

Post by masklinn »

nas wrote: post #48
masklinn wrote: post #5

Earlier quoted context omitted.

> Imho this is a much better solution than 2to3. That's nonsensical since it solves a completely unrelated problem. 2to3 was conceived of as a one-shot migration tool for Python 2 codebases. Not as a way to build cross-version Python, and not as something to use repeatedly (which it why it is relatively simplistic and fallible), just as a way to take an existing codebase and handle the first 90% of migrating to Pytho…

I don't think it is nonsensical. There was a tool 3to2 that took Python 3 code and produced Python 2 code. You had to write in a subset of Python 3 but the idea was sound, I think. Python 3 is more strict in ways than 2 and so downgrading the code was easier (e.g. no implicity str/unicode coercions). It looks like 3to2 is not maintained but I liked the idea. If I were writing a library that needed both 2 and 3 compat…

> I don't think it is nonsensical.

It is completely nonsensical in the context it is made in, the purpose of TFA has nothing to do with the purpose of 2to3, it makes no sense to "rank" them.

> There was a tool 3to2 that took Python 3 code and produced Python 2 code. You had to write in a subset of Python 3 but the idea was sound, I think. Python 3 is more strict in ways than 2 and so downgrading the code was easier (e.g. no implicity str/unicode coercions). It looks like 3to2 is not maintained but I liked the idea.

That still has nothing to do with 2to3, whose intended purpose once again is as a helper for a one-shot conversion of an existing Python 2 project to Python 3.

> If I were writing a library that needed both 2 and 3 compatibility, I would prefer to write Python 3 code and then run 3to2 on it, rather than going the other way.

And guess what? If you're starting from a Python 2 project you can use 2to3 to convert it to Python3 then use some other converter to provide P2 releases.

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

#74

Post by jwilk »

tyingq wrote: post #16

Great idea. A writeup on how you handled mapping bytes, bytearrays, unicode, etc, to 2.7 constructs would be interesting. In code that supports both 2 and 3, I end up with ugly stuff testing sys.hexversion to deal with 3rd party libraries, like pyserial, that expect str in v2, bytearrays in v3.

sys.version_info gives you a tuple, which is way more convenient for comparisons than sys.hexversion:

    if sys.version_info >= (3,):
        ...  # Python 3.X code
Or you could check whether str is bytes:

    if str is bytes:
        ...  # Python 2.X code

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

#75

Post by run4yourlives2 »

dbcurtis wrote: post #44
run4yourlives2 wrote: post #22

Earlier quoted context omitted.

Serious Answer: Because some of us have some rather large perfectly working systems written in 2.7 and using lots of different libraries that moving to 3 is a major project requiring a good amount of time and effort. Not all of us have hobby-sized projects on the go.

OK, but this has been a very long transition. There has been lots of time to evolve to 3.x. Has the primary barrier been the slow transition of library dependancies? I'd really like to understand this from a technology transition management standpoint. If you'll allow a strained analogy, the 2.7 to 3.x transition appears in retrospect like an exercise in herding cats, because the transition was done using cat-herding…

It's been a long transition, yes. So long, that 4-5 years ago, developing a new application in 3.X was a non starter. Hence, 2.7.

Now, you have 2.7 apps that are very mature, stable and reliant on lots of little things. Okay, big job.

Now let's throw another wrinkle into this. You can pay good money to develop your next feature, or to port your system to 3.x. One adds real value to your customers and improves your bottom line. One lets you say you are on 3.x and gets nods of approval from random programmers.

What do you think a business is going to do? Exactly.

When will we eventually port? Sometime shortly after 3.x becomes the overall standard. THIS is actually what we are seeing right now, which is great, but that hasn't been the case up until the last year or so.

>Any technology that lives long enough eventually has to transition its customer base.

While true, this costs money, time, and effort. So you better be damn well sure there is a good ROI that is something more than "This code that nobody but programmers see is more elegant and properly structured".

There's a reason banks are still using COBOL after all...

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

#76

Post by recursive »

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

As far as I can tell, you're complaining about one character. This works.

    >>> add = lambda a, b: a + b
    >>> t = (1, 2)
    >>> add(*t)
    3
Is that extra asterisk the problem? Again, if you want a materialized list, pass it to `list()`. Projection failures will raise then.

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

#77

Post by kec »

jerryszczerry wrote: post #58
Grue3 wrote: post #37

Earlier quoted context omitted.

"Why don't you just rewrite it in X?" Because Python 3.X is not backwards compatible and we have millions of lines of production code in Python 2.X.

> Because Python 3.X is not backwards compatible and we have millions of lines of production code in Python 2.X. I believe the common subset of Python 2 and 3 was created to ease that transition.

That common subset doesn't include string handling.

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

#78

Post by flohofwoe »

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?

In my case: MacOS has python 2.7 pre-installed, and python3's lack of backward compatibility is mildly annoying while giving very little actual improvements in return.

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

#79

Post by mikebenfield »

BeetleB wrote: post #70
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.…

The Python project itself is dropping support for Python 2 by 2020. Lots of major libraries have pledged to stop supporting Python 2 by 2020 or even before.

Writing new code in Python 2 is completely nuts and just makes everyone's life harder (including your own).

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

#80

Post by sametmax »

wbond wrote: post #12

Ever since mypy started gaining attention, I’ve been looking for a way to write using Python 3 annotations and strip the annotations for release so that the code can run on Python 2. I never was able to find anyone talking about that goal with mypy, but it looks like this tool may be a solution.

Use the comment syntax for type annotations. They are compatible with both versions.
Post reply on HN