Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making Python 3 more attractive

lwn.net

Post reply on HN
Print view View original

151–160 of 172 posts

Re: Making Python 3 more attractive

#151

Post by berntb »

keyneus wrote: post #148
mangecoeur wrote: post #115

I think the obsession with the GIL is sort of missing the point - people on python2 live with the GIL and don't really miss it, I don't think that's really the killer feature to drive python3 adoption. Especially considering its almost impossible to do without breaking something (most likely C extensions) and when you see the wailing and gnashing of teeth that came from python3 forcing people to fix their text encodi…

Anecdotal data to agree with type annotations: We have a fairly large Python codebase here. I've been wanting to move away from Python for a whole host of reasons, a top one being that it's dynamically typed. However, when mypy was released, that was enough of a reason to port from Python2 to Python3. Now we have a mostly-annotated codebase, and I'm a lot happier. We'll probably move away from Python eventually (I st…

THAT is how you get downvoted around Python people...

Edit: I'm hellbanned already, so... :-)

Re: Making Python 3 more attractive

#152

Post by DrJosiah »

mrsteveman1 wrote: post #143
unfamiliar wrote: post #122

Earlier quoted context omitted.

Doesn't 2to3 handle all of these problems?

2to3 will write you a patch so you can port the code to py3 if that's what you want, but if you then also want to maintain py2 compatibility you've got more work to do. I can't speak to the wisdom of making map and zip builtins, but that's what they are in py3, and the six module will make using them that way automatically backward and forward compatible: from six import map, zip

Map and zip were builtins in 2.x as well, just not the itertools.imap/itertools.izip variants.

Re: Making Python 3 more attractive

#153

Post by eeZi »

reidrac wrote: post #72
eeZi wrote: post #23

Reasons I am excited about Python 3: * "yield from" * Unicode support (I'm German and the clear distinction between bytes and unicode really makes my life easier) * function annotations (PyCharm interprets them and uses them for static type checking) * cleaned up stdlib (not only names, but also features) * asyncio Library support is very good nowadays, pretty much all of the important libraries are either ported to…

So far I've focused on making new projects both Python 2 and 3 compatible, but "new stuff" in Python 3 is not always available when: - Laptop running Ubuntu Trusty: Python 3.4 - Production servers with Debian Wheezy: Python 3.2 - Laptop running Fedora 20: 3.3.2 You don't usually install Python in Linux using upstream, you install the version provided by your distribution and unfortunately Python 3 has differences bet…

Debian Jessie and Fedora 21 both ship Python 3.4, so that problem is going away.

In the meantime, it's always possible to install a self-contained Python 3.4 interpreter and a virtualenv. It's pretty straight-forward, actually. The only thing you'll miss is distribution-provided binary packages (like lxml), but pip/setuptools compiles them for you.

Re: Making Python 3 more attractive

#154

Post by aidos »

sago wrote: post #89

GIL seems to me to be only a niche problem in reality. But it is a bit of a storm in a powerpoint (i.e. people see it on a list of features of python and panic. Even though, as the article says, Javascript has much more constrained single-threadedness). I've been deploying python for almost 20 years, and I haven't had a single performance issue that was caused by GIL and couldn't easily be worked around. In my experi…

I agree, it's not a problem in most spaces.

I'm one of those not so lucky souls that could benefit from having the GIL removed. I do a load of concurrent read only access from multiple threads of execution on a large object in memory. At the moment I'm forced to fork using multiprocessing. It works, but it sucks to have the overhead.

Though, as you say, it's really a non-issue for most workloads.

Re: Making Python 3 more attractive

#155

Post by eiopa »

masklinn wrote: post #113
eiopa wrote: post #67

Earlier quoted context omitted.

I want Python 2.8. This is Python 2.7, but is based on PyPy (so it's waaay faster), and has requests + gevent + lxml built-in, and adds some small niceties from 3.x (yield from, a, b* = foo()).

Feel free to implement that in Pypy right now?

Haven't hacked on PyPy before. Would be interesting to do someday :)

Re: Making Python 3 more attractive

#156

Post by BuckRogers »

IanCal wrote: post #105
BuckRogers wrote: post #62

Earlier quoted context omitted.

I'm a library consumer not a maintainer, but with info like this- https://twitter.com/mitsuhiko/status/586294700430254080 If you look at the date on the calender, the fact this is still being discussed with virtually no progress like it's still 2008 when 3.0 got released tells me that this is over. As an end user, I say drop 3.x support in your libraries. The gig is up. If 3 ever takes over, do a 1 time wholesale por…

> I say drop 3.x support in your libraries. The gig is up. If 3 ever takes over People dropping 3.x support until 3.x becomes the most used version basically guarantees that it won't take over. Is this a code equivalent to the bystander effect?

I don't think so. 3 will take over eventually if they don't give up on it. But the issue is that the onus of the labor involved is on those enthusiastic for Python3, and the core dev team.

Few to no one in userspace asked for this problem. For me, it's not a problem. I suspect a lot of people will eventually see it my way. Instead of learning/porting from 2 to 3, they'll stick with 2 and pickup something else like Go. I believe adding Go to my toolbelt was a much better use of my time. While there's other, maybe better, choices than Go, my argument is that it's so easy to learn that it's just about as difficult as the transition/porting of existing projects that Python3 would've been.

I personally gain little to nothing by spending any time on Python3. No amount of features, moving distros to 3 by default, or anything else can convince me. All job prospects 2, and all the libraries support 2. No one cares if my resume has Python3 on it, but adding Golang alongside Python2 opened up a lot of opportunities. If a Python(2) user wanted to spend time on Rust, that would also be a great use of time.

For each person I see demanding Python3 support, I want to see that person spending hours, weeks, months, porting everything they can find to 3 and then maintaining it. Because the rest of us don't care.

For me, Python3 has 1 main feature. It enables you to beg library maintainers to port to 3.

Re: Making Python 3 more attractive

#157

Post by netheril96 »

kylebgorman wrote: post #32

This post seems to conflate language and implementation. IMO, Python 3 the language has tons of improvements and no regressions. The grief on the internet about Python 3 makes me seriously wonder how many people who don't like Python 3 have actually tried it yet. (There are legitimate critiques of Python 3, but they're few on the ground and none are presented here.) The suggestions in this post are mostly changes to…

The idea that language and its implementation can be separated is only theoretical. In practice, the adoption of a certain language is highly influenced by its implementation (and ecosystem).

The language improvements are nice. I know this because I started with Python 3 then switched to Python 2 and missed some of the goodies now and then. But the language improvements are not enough to overcome the breakage of backwards compatibility. Only a vastly improved implementation (that is not backported to Python 2.7) will.

Re: Making Python 3 more attractive

#158

Post by netheril96 »

unfamiliar wrote: post #122
netheril96 wrote: post #102

Earlier quoted context omitted.

`print` statement is not a big deal for me. But one thing that especially annoys me is the functions in the module `itertools`. In Python 2, I use `itertools.izip` or `itertools.imap` a lot, because I'd like to avoid creating a large list only to iterate over once. When I tried migrating to Python 3, I found out that these functions are gone, and I was supposed to use plain `zip` and `map` instead. I was furious. How…

Doesn't 2to3 handle all of these problems?

It is not the difficulty of handling these situations. It is the lack of regard for Python users like me. Again, as I have said, I feel punished for milking the most from the language, whereas those who code carelessly are rewarded with performance improvement and no pains in transition. Why should I switch to a language that punishes me for good behavior?

It is the same as the `u` prefix. Those who actually cared to get Unicode right got punished when Python 3.0 came out because now none of their code compiled, whereas those who just assume everything is ASCII went on without problems.

Re: Making Python 3 more attractive

#159

Post by pc2g4d »

federico3 wrote: post #124
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,…

>I'm using the worst of both worlds To me this is the main pain point and I'm surprised that people are not talking about this. 2to3 and 3to2 are too kludgy and writing native py2-and-py3 compatible code is quite painful and requires a number of workarounds (e.g. unicode/str/bytes type, different methods on dictionaries...)

Does the `six` library not help with this?
Post reply on HN