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

101–110 of 113 posts

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

#101

Post by carapace »

jerryszczerry wrote: post #99
pekk wrote: post #96

Earlier quoted context omitted.

FORTRAN 77 is just as likely to be abandoned in 2020 as well. And?

How many uses can you find for Fortran 77 besides legacy systems?

Well now you're getting onto my personal reason why I don't adopt Python 3. Python 2 will remain just as useful as it's been. Python 3 will not significantly extend that usefulness.

So I don't think there's much to be gained.

The 3 syntax and new features are not massively better than the sweet spot hit by 2, they're not even incrementally better. They're just massively more complicated.

So the cost/benefit ratio of Python 2 to 3 just isn't there. People are changing up because it's "the done thing" not because they really gain anything.

I was surprised as hell when I realized I wouldn't use Python 3, but it is a rational and considered opinion.

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

#102

Post by sitkack »

masklinn wrote: post #5
sly010 wrote: post #2

Imho this is a much better solution than 2to3. If python3 adoption is the goal, python3 should be the input and not the output.

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

You are not being charitable.

2to3 was _conceived_ of as migration tool, as if evolutionary lineages just all stopped, changed their genome and restarted. Except it only refactored some easy stuff and let the rest fall on the floor.

Six has had way more impact than 2to3. It was only because core Python said running a single 2/3 codebase was UnPythonic that people didn't embrace it sooner. Running a single codebases across both 2 and 3 is now the defacto technique.

Writing in 3 and "compiling down" to 2 gets people writing 3 which is the point, even if they can't run CPython3.

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

#103

Post by sitkack »

nas wrote: post #47
benhoyt wrote: post #21

Earlier quoted context omitted.

I've scanned the source code and it doesn't look like it handles the bytes/unicode thing. Which, while the project is cool, will mean it won't work for a ton of Python 3 code.

The implicit coercion between bytes and unicode was one of the biggest hurtles I ran into when porting a relatively large (30k+ lines) code base from Python 2 to 3. Also challenging was the change in comparisons (None no longer smaller than all types, TypeError when trying to order disjoint types). While this looks like an interesting hack, I can't see anyone seriously using it to backport code to Python 2.7. As I me…

You probably fixed lots of bugs in the process. How long did it take?

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

#105

Post by c8g »

spott wrote: post #32
Marat_Dukhan wrote: post #25

Earlier 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]

> I like lambda a, b: a + b syntax better than lambda a_b: a_b[0] + a_b[1] uh, `lambda a,b: a + b` works in 3.6... > I prefer ... to return lists rather than iterable: Why? I'm just curious. Iterables are much more flexible than lists, unless you need random access... at which point list(...) works pretty well.

he mean `map(lambda (a, b): a+b, [(1, 2), (3, 4)])`

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

#106

Post by masklinn »

sitkack wrote: post #102
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…

You are not being charitable. 2to3 was _conceived_ of as migration tool, as if evolutionary lineages just all stopped, changed their genome and restarted. Except it only refactored some easy stuff and let the rest fall on the floor. Six has had way more impact than 2to3. It was only because core Python said running a single 2/3 codebase was UnPythonic that people didn't embrace it sooner. Running a single codebases a…

> You are not being charitable.

There's nothing to be charitable about, GP's comment is rather clear and stands for itself.

> 2to3 was _conceived_ of as migration tool

And it still is one, so far as I know, which is actually part of the issues with it.

> Except it only refactored some easy stuff and let the rest fall on the floor.

I'm rather well aware of that, which you'd have noted if you'd actually read my comment.

> Six has had way more impact than 2to3. […] Running a single codebases across both 2 and 3 is now the defacto technique.

Sure, but again that has nothing whatsoever to do with the inanity of ranking 2to3 and backwards.

> Writing in 3 and "compiling down" to 2 gets people writing 3 which is the point, even if they can't run CPython3.

You do realise that's complementary to 2to3 right? A big issue of 2to3 is that once you've converted your P2 codebase to pure-3 (not a common subset of 2 and 3) you either have to maintain two different branches making packaging and backporting difficult or you just leave your P2 users out in the cold.

Once again, the purpose of 2to3 is not to regularly run 2to3 to generate a Python3 release from a Python2 source.

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

#107

Post by masklinn »

pekk wrote: post #97
kec wrote: post #77

Earlier quoted context omitted.

That common subset doesn't include string handling.

You can absolutely do string handling in a common subset of Python 2 and Python 3. It won't work for legacy string handling code if you relied on implicit coercion, but then the same apps are unlikely to support unicode either.

> It won't work for legacy string handling code if you relied on implicit coercion

That's far from the only pitfall. For instance some of the P2 stdlib relies on implicit coercion to bytestrings whereas the Python 3 version has been properly converted to unicode (I discovered that when I tried to disable implicit coercion in one of the codebases I work with for cleanup/migration purposes).

So cross-platform string handling is not just a matter of properly splitting bytestrings and textstrings, but also finding out where "native strings" need to remain.

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

#108

Post by masklinn »

Marat_Dukhan wrote: post #25
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?

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]

> - I like lambda a, b: a + b syntax better than lambda a_b: a_b[0] + a_b[1]

That works perfectly well in Python 3, you're thinking about `lambda (a, b)` aka `def foo((a, b))` aka tuple-parameter unpacking.

> - I prefer map/reduce/filter to return lists rather than iterable

1. why? 2. just wrap them in a list() call?

> - I prefer dict.keys/values/items to return sets/lists rather than iterables, unless I call dict.iter[keys/values/items]

You are aware that Python3's keyviews and itemsviews are sets but P2's are just lists right?

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

#109

Post by masklinn »

pekk wrote: post #95
sametmax wrote: post #81

Please don't. The transpiler route ended very badly for JS. Let's not open this pandora box for Python.

We've already had tools like 2to3, but they weren't all that popular, and this won't be either. Most things are ported to Python 3 now and most new projects just use Python 3. Never fear.

2to3 is not a tool with which you generate releases with, it's a one-shot porting aid.

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

#110

Post by masklinn »

cwyers wrote: post #54
sigjuice wrote: post #8

I am not a Python developer, but thanks for not using the unnecessary term "transpiler".

I never understood the insistence in this. A transpiler is "a compiler that targets a high-level language." It's a term that adds information above and beyond compiler. All transpilers are compilers, not all compilers are transpilers.

> A transpiler is "a compiler that targets a high-level language."

So rustc is a transpiler when using the emscripten backend but not when using the native backend? How does that even make sense?

Post reply on HN