Please don't. The transpiler route ended very badly for JS. Let's not open this pandora box for Python.
Show HN: Python-to-Python compiler for some 3.6 features in older versions
81–90 of 113 posts
Re: Show HN: Python-to-Python compiler for some 3.6 features in older versions
#82Earlier quoted context omitted.
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).
>Writing new code in Python 2 is completely nuts and just makes everyone's life harder (including your own).
And when it makes someone's life harder, they will change. If it's too late for them and affects them, they will have themselves to blame.
This, really, is the only reason for people to change to Python3. Yet people keep evangelizing all its great features, etc as if the existence of a much better language suddenly obligates everyone to switch to it.
It's fine to point out potential repercussions of not switching now. But moralizing it is counterproductive.
Re: Show HN: Python-to-Python compiler for some 3.6 features in older versions
#83Great 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
That is why I used sys.hexversion. Since there are 3 paths, has real bytes, fake str bytes, and no bytes.
Re: Show HN: Python-to-Python compiler for some 3.6 features in older versions
#84Ever 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.
I didn’t like the idea of moving the annotations out-of-band with the parameter names. Aesthetically you also loose syntax highlighting.
Re: Show HN: Python-to-Python compiler for some 3.6 features in older versions
#85Earlier quoted context omitted.
Because Python 2.7 is, IMO, a better language than Python 3+, e.g.: - I like lambda a, b: a + b syntax better than lambda a_b: a_b[0] + a_b[1] - I prefer map/reduce/filter to return lists rather than iterable - I prefer dict.keys/values/items to return sets/lists rather than iterables, unless I call dict.iter[keys/values/items]
Your first point is incorrect, lambda works with the first syntax for both python 2 and 3. What /has/ changed, however, is the implicit destructuring: l = lambda (a, b): a + b l((1, 2)) I suspect there are very good reasons not to allow something like this. With regard to the second point, I also would have liked a more "gradual" step there, I find myself (especially in REPL environments) often doing `list(map(sth, s…
>I find myself (especially in REPL environments) often doing `list(map(sth, sth))`.
This. I wonder if you could have a switch to make ipython print out the list instead of the iterator object at the REPL.
Re: Show HN: Python-to-Python compiler for some 3.6 features in older versions
#86Serious question: Why would anyone still be doing anything with Python 2.7 except porting the last remnants of their code base to 3.X?
I'm working on something right now in 2.7, a personal project. One of the 3rd party tools has a note about 3 with just enough of a "mostly" that I just don't want to encounter the speed bump or road block or whatever it's going to be. And also, the code isn't really the major part of the project.
Re: Show HN: Python-to-Python compiler for some 3.6 features in older versions
#87Quick! Someone inform Zed Shaw!
Re: Show HN: Python-to-Python compiler for some 3.6 features in older versions
#88Earlier quoted context omitted.
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 ou…
Total guess, not a Mac guy, only know Apple by reputation: maybe they aren't interested in spending any resources for anyone to have modern tools that aren't Apple tools. "Y'all do what you want. If it doesn't come from us, you're on your own."
Re: Show HN: Python-to-Python compiler for some 3.6 features in older versions
#89Earlier quoted context omitted.
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
That is why I used sys.hexversion. Since there are 3 paths, has real bytes, fake str bytes, and no bytes.
bytes exists since Python 2.6. Do you really need to support anything older?
Re: Show HN: Python-to-Python compiler for some 3.6 features in older versions
#90Earlier quoted context omitted.
Because Python 2.7 is, IMO, a better language than Python 3+, e.g.: - I like lambda a, b: a + b syntax better than lambda a_b: a_b[0] + a_b[1] - I prefer map/reduce/filter to return lists rather than iterable - I prefer dict.keys/values/items to return sets/lists rather than iterables, unless I call dict.iter[keys/values/items]
Iterables are so much better on memory though. I wonder why isn't "lambda (a, b): a+b" allowed?
It was removed for reasons outlined in this PEP: http://legacy.python.org/dev/peps/pep-3113/