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

41–50 of 113 posts

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

#41

Post by rhaps0dy »

filmor wrote: post #28
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]

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…

PEP 3113 -- Removal of Tuple Parameter Unpacking http://legacy.python.org/dev/peps/pep-3113/

These seem like OK reasons, but I find myself continuously needing the destructuring idiom in lambdas, while these introspection and documentation concerns are just not there for me.

However tuple-parameters being an exception to rules (such as args and kwargs not being usable with them) is more compelling. And allowing destructuring only in lambdas would be weird, because they wouldn't be normal function objects any more.

Unless the destructuring was only syntactic sugar for the translation in the PEP? But that's again inconsistent.

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

#42

Post by Marat_Dukhan »

recursive wrote: post #33
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] 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…

Yes, sets are mutable, but if I call dict.keys, I expect to get a copy of keys.

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

#43

Post by Marat_Dukhan »

filmor wrote: post #28
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]

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…

Yes, lack of implicit tuple unpacking in lambda is what forces me to write `lambda a_b`.

Python 2.7 has imap and ifilter in itertools. Python 3 could have imported them into global namespace to simplify usage without breaking map/filter functions.

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

#44

Post by dbcurtis »

run4yourlives2 wrote: post #22
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?

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 style incentives. What should have been done differently to make the transition into greyhounds chasing a rabbit? What should the rabbit have been?

Any technology that lives long enough eventually has to transition its customer base. I'm trying to learn to identify rabbits.

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

#45

Post by xrange »

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?

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.

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

#46

Post by leejoramo »

antman wrote: post #7
nas wrote: post #3

Interesting but I wonder when you would need a tool like that. I have something related, a fork of Python 3.6 that adds a bunch of backwards compatible behaviour so 2.7 code runs more easily, https://github.com/nascheme/ppython .

Link broken

https://github.com/nascheme/ppython

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

#47

Post by nas »

benhoyt wrote: post #21
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.

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 mentioned elsewhere, I created "ppython" to handle these two porting problems. The source code is on github: https://github.com/nascheme/ppython . If someone needs a Windows binary, I could build it if you ask politely. ;-) For my project, it has been a useful tool to speed up porting.

Porting code is not trivial and there is huge amount of Python 2 out there. I wish more effort had been spent building tools to help porting of code. Even simple things like disallowing the 'u' prefix on strings in Python 3 was a big mistake. Mostly those things have been corrected but it is still going to take a very long time to move the majority of the community to Python 3. There will be Python 2 running for the next 50 years easily, I'm sure, maybe 100 years. At least Python is open source and you will not be stranded like VB developers where when MS drastically changed Visual Basic.

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

#48

Post by nas »

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…

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 compatibility, I would prefer to write Python 3 code and then run 3to2 on it, rather than going the other way. My own solution is to fork the library, provide only bug fixes for the 2.x version and do all new development in Python 3 only. Porting has taken some effort but not as much as I feared. In retrospect, I'm happy to have invested the time.

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

#49

Post by chc »

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…

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

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

#50

Post by CJefferson »

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.
Post reply on HN