Making Python 3 more attractive • Hacker News Board

Re: Making Python 3 more attractive

#51

Post by tdicola » Wed, Apr 15, 2015, 7:13 AM UTC

1wd wrote: post #44

plesner wrote: post #41

Making python 3 more attractive is not the solution, it's part of the problem. I can't use just python 3 because python 2 is still widely used. I can write code that works on both but now I'm using the worst of both worlds, and even worse I now have to test on both. And that'll last until python 2 goes away completely which, - when has a language ever gone away quickly? These aren't fun problems. Improving python 3,…

There has actually been a lot of focus on making migration less painful, including restoring some removed features, e.g. Python 3.3 has added back the unicode literals. This is limited to things that are actually painful to migrate though not trivial non-issues like the print statement.

It's not really migration though, it's supporting both python 2 and 3. If you write modules that people depend on you're in a really, really painful spot with the 2 and 3 transition. You can have two completely separate code bases and deal with all the duplication and problems that come with it, or you can try to write code that works with both python 2 and 3 and deal with the huge amount of warts and pain that come with it. Both are painful so it's easy to see why a lot of people just don't even bother trying to support both and ignore 3.

Re: Making Python 3 more attractive

#52

Post by bufordsharkley » Wed, Apr 15, 2015, 7:16 AM UTC

plesner wrote: post #41

Making python 3 more attractive is not the solution, it's part of the problem. I can't use just python 3 because python 2 is still widely used. I can write code that works on both but now I'm using the worst of both worlds, and even worse I now have to test on both. And that'll last until python 2 goes away completely which, - when has a language ever gone away quickly? These aren't fun problems. Improving python 3,…

Removing the print statement is, to me, an extremely frustrating breaking change to make.

If nothing else, I feel that backward compatibility should be given toward's a language's canonical "hello world" example.

Re: Making Python 3 more attractive

#53

Post by guipsp » Wed, Apr 15, 2015, 7:19 AM UTC

plesner wrote: post #41

Making python 3 more attractive is not the solution, it's part of the problem. I can't use just python 3 because python 2 is still widely used. I can write code that works on both but now I'm using the worst of both worlds, and even worse I now have to test on both. And that'll last until python 2 goes away completely which, - when has a language ever gone away quickly? These aren't fun problems. Improving python 3,…

from __future__ import print_function on python2 solves the print function incompat.

Re: Making Python 3 more attractive

#54

Post by stock_toaster » Wed, Apr 15, 2015, 7:19 AM UTC

hurin wrote: post #47

vessenes wrote: post #5

Python developers would almost all upgrade in a single minute for 30%+ better performance. It's interesting that performance wasn't a topic at this rump session as reported; I moved over to Go about a year ago, and while I miss Python's expressivity at least once a week, I'm just not willing to slow down all my programs by 5x. On the other hand, if Python could double in speed, I'd likely try to rework it into our wo…

>Python developers would almost all upgrade in a single minute for 30%+ better performance. But strangely they don't - PyPy has hardly gained traction (albeit the python2->python3 switch didn't help) and looking at the benchmarks that's more like 5-7x performance. I suspect that most often, in places where performance matters enough in a way that would warranted refactoring a code-base from cpython to PyPy, they alre…

pypy is great (we use it at work for a few services), but it has slow startup/jit warm up, and uses crazy lots of ram. Once it warms up though, it is pretty darn fast (for python).

Re: Making Python 3 more attractive

#55

Post by sanxiyn » Wed, Apr 15, 2015, 7:23 AM UTC

MichaelMoser123 wrote: post #37

iandanforth wrote: post #14

Nothing in that article matters to me and I use Python every single day. I guess if you know too much about a thing it's easy to lose sight of what "normal" users care about. So here's my list: 1. Speed 2. Language warts (e.g. del, __init__, import *, while: else:) 3. Lack of a modern UI toolkit 4. No native support in Android, iOS, or Browsers worth mentioning. Right now Python is the perfect prototyping, glue, and…

regarding the speed issue: i looked at python 2.7 - here the interpreter is creating a dictionary for each function frame, now local variables are looked up by name of variable in this dictionary ! (globals have their separate namespace dictionary) (i made a tracing tool that traces a python program and prints out all accessed variables - it actually makes use of this by-name-lookup-feature http://mosermichael.github…

Variable access already works by index, not by name. Normally, LOAD_FAST and STORE_FAST are used.

Re: Making Python 3 more attractive

#56

Post by bemused » Wed, Apr 15, 2015, 7:24 AM UTC

saurik wrote: post #25

ghshephard wrote: post #13

Earlier quoted context omitted.

Mercurial is a canary - if they see so much pain involved in moving from Py2 to Py3, and little reward, then that's representative of the overall ecosystem. Having people on older versions of the interpreter is a problem, because it divides the community in half when it comes to knowledge, skillset, capability, etc.. It also confuses outsiders who are looking at the situation, and don't understand which version they…

More of that effort needs to go into compromises back to Python 2.x as opposed to figuring out how to beat people into going up to Python 3.x; it should not have taken until Python 3.3, for example, for the u'' syntax to return. They need to sprinkle a few well-placed "this is a way to get compatibility with Python 2 and 3 at the same time, without crazy tools, at least as an interim state". When I shifted from Ruby…

my experience with python3 unicode has been just the other way round - there are some minor troubles with python3 in regard to unicode too, but when doing anything user facing (starting with i18n/l10n) I'd take python3 without thinking twice. its 2015 and bugs like the unicode usernames problem in GTA V lately are just embarrassing for developers

I'm not saying you can't do this with python2 but you have to pay attention to unicode all the time. this gets worse A LOT when trying to serve python 2 and 3 from the same codebase, something I wouldn't recommend at all if you want to do eg. application development. of course this is a bit frustrating if you learned to properly do unicode in python2 the hard way, but for new developers not having to worry about unicode issues really is a blessing

Re: Making Python 3 more attractive

#57

Post by raverbashing » Wed, Apr 15, 2015, 7:24 AM UTC

guipsp wrote: post #53

plesner wrote: post #41

Making python 3 more attractive is not the solution, it's part of the problem. I can't use just python 3 because python 2 is still widely used. I can write code that works on both but now I'm using the worst of both worlds, and even worse I now have to test on both. And that'll last until python 2 goes away completely which, - when has a language ever gone away quickly? These aren't fun problems. Improving python 3,…

from __future__ import print_function on python2 solves the print function incompat.

Exactly this

Why is changing 'print stuff' to 'print (stuff)' such a big deal?

I think 2To3 solves a lot of print cases https://docs.python.org/2/library/2to3.html

Re: Making Python 3 more attractive

#58

Post by 1wd » Wed, Apr 15, 2015, 7:27 AM UTC

tdicola wrote: post #51

1wd wrote: post #44

Earlier quoted context omitted.

There has actually been a lot of focus on making migration less painful, including restoring some removed features, e.g. Python 3.3 has added back the unicode literals. This is limited to things that are actually painful to migrate though not trivial non-issues like the print statement.

It's not really migration though, it's supporting both python 2 and 3. If you write modules that people depend on you're in a really, really painful spot with the 2 and 3 transition. You can have two completely separate code bases and deal with all the duplication and problems that come with it, or you can try to write code that works with both python 2 and 3 and deal with the huge amount of warts and pain that come…

I agree migrating is painful, and supporting both even more so. But not because of print. Migrating print statement usages and even making them work on python 2 and 3 is trivial, even fully automated and statically verifiable.

Compare that to unicode changes, where you need to manually inspect and potentially deeply analyze every single string literal.

Why waste resources making the trivial easier just to please people that will not migrate anyway?

Re: Making Python 3 more attractive

#59

Post by heinrich5991 » Wed, Apr 15, 2015, 7:28 AM UTC

vacri wrote: post #19

iandanforth wrote: post #14

Nothing in that article matters to me and I use Python every single day. I guess if you know too much about a thing it's easy to lose sight of what "normal" users care about. So here's my list: 1. Speed 2. Language warts (e.g. del, __init__, import *, while: else:) 3. Lack of a modern UI toolkit 4. No native support in Android, iOS, or Browsers worth mentioning. Right now Python is the perfect prototyping, glue, and…

I always found it weird that python functions quite happily tell you that you're missing a colon, but can't 'just run' without it. Excluding one-liner syntax, why does Python actually need a colon to define a function, given it's goal of being free of unnecessary syntactic elements? I'm only an intermediate pythonista, but I'd be interested to know if there was a particular point to the colon.

A few "unnecessary" syntactic elements help find errors at "compile time". In Javascript for example, automatic semicolon insertion can lead to very subtle errors.

Re: Making Python 3 more attractive

#60

Post by bufordsharkley » Wed, Apr 15, 2015, 7:28 AM UTC

raverbashing wrote: post #57

guipsp wrote: post #53

Earlier quoted context omitted.

from __future__ import print_function on python2 solves the print function incompat.

Exactly this Why is changing 'print stuff' to 'print (stuff)' such a big deal? I think 2To3 solves a lot of print cases https://docs.python.org/2/library/2to3.html

The print function is clearly a better, more precise way to handle it, to be sure...

But the print statement was one prominent, attractive way that Python was essentially pseudocode-- its removal seems an improvement from a pedantic sense, but one that seems to run contrary to convenience and (perhaps) the expectations of a beginner.