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

161–170 of 172 posts

Re: Making Python 3 more attractive

#161

Post by kylebgorman »

netheril96 wrote: post #157
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 back…

Python is notable among its peers in that it has a well-defined spec that is not just a list of bugs in the reference interpreter. It is thus important to note that some of the non-reference interpreters do already have the properties requested in TFA, but for whatever reason they haven't supplanted the reference implementation. (I suspect that the ability to drop down into C/C++, link against preexisting libs, or use tools like Cython and taking advantage of the compiler's optimizer, is actually more important than, say, the average PyPy speed boost. Certainly it is for me.)

Re: Making Python 3 more attractive

#162

Post by palmstroem »

zem wrote: post #101
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…

what's wrong with qt as a modern ui toolkit? python seems to be one the best supported languages as far as qt bindings go.

Have you ever tried to deploy a native looking Python3 qt app on both Mac and Windows? I am not aware of anyone who lived to tell the tale. If you can do without a native look (menus, dock icons, app packaging), i.e. you just want to have some academic lab tool, then qt is good enough, IMHO. But no comparison with native UI development on Win or Mac.

Re: Making Python 3 more attractive

#163

Post by palmstroem »

cookiecaper wrote: post #137
reidrac wrote: post #72

Earlier quoted context omitted.

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…

Python is actually much better than almost all equivalent languages in this. Consider that custom package managers like rvm/bundler, nvm/npm, etc., are considered must-haves for any kind of serious development on Ruby or Node, whereas use of virtualenv is still kind of seen as a "bonus" feature. The fact that Python is good enough to allow that demonstrates its robustness . Stop using Python 2. All of the justificati…

After we migrated to Python 3, we came to regret the decision with considerable regularity. We mostly use MacOS, and working with OpenGL and scientific libraries has been painful. We never found that a library we needed was not available for 2.7, but lots of stuff has not been ported to 3.3. The syntactic advantages of 3 have been too minor to warrant the troubles we earned. Your mileage may vary, if you have different applications, of course.

Re: Making Python 3 more attractive

#164

Post by zem »

palmstroem wrote: post #162
zem wrote: post #101

Earlier quoted context omitted.

what's wrong with qt as a modern ui toolkit? python seems to be one the best supported languages as far as qt bindings go.

Have you ever tried to deploy a native looking Python3 qt app on both Mac and Windows? I am not aware of anyone who lived to tell the tale. If you can do without a native look (menus, dock icons, app packaging), i.e. you just want to have some academic lab tool, then qt is good enough, IMHO. But no comparison with native UI development on Win or Mac.

no, linux only. i'll admit that i wasn't taking native look into account, but then again, no default gui toolkit would be likely to have a native l&f anyway - you'd want to use the platform-native bindings for each platform separately, if that was a strong concern.

Re: Making Python 3 more attractive

#165

Post by wora »

1wd wrote: post #110
wora wrote: post #92

Earlier quoted context omitted.

Migration is a critical issue for python 3 adoption. I think python 3 should have done something similar to Protocol Buffers v3 (proto3) by introducing syntax = "python3" statement and let runtime support both v2 and v3. This allows people migrate one file at a time. In any large scale production environment, this is pretty much the only practical way for migration. Another critical mistake python 3 made was unicode…

A runtime that can support both v2 and v3 files is a nice idea and has been proposed before, but is virtually impossible because of the unicode changes. I don't understand where you see the mistake in Python 3 with unicode. What encoding Python internally uses to store strings doesn't really matter. What's important is that it is always known what encoding is used. This was unclear in Python 2 and Python 3 fixed this…

Nowadays, most of text data are stored in UTF-8 format. If the language uses UTF-8 as native string format, it is much easier for text processing, which is why Go chose it. There are a lot of subtle technical details you will only realize after working with many text processing components.

Re: Making Python 3 more attractive

#166

Post by ngrilly »

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…

To which languages could you possibly move, as a replacement for Python?

Re: Making Python 3 more attractive

#167

Post by ngrilly »

wora wrote: post #165
1wd wrote: post #110

Earlier quoted context omitted.

A runtime that can support both v2 and v3 files is a nice idea and has been proposed before, but is virtually impossible because of the unicode changes. I don't understand where you see the mistake in Python 3 with unicode. What encoding Python internally uses to store strings doesn't really matter. What's important is that it is always known what encoding is used. This was unclear in Python 2 and Python 3 fixed this…

Nowadays, most of text data are stored in UTF-8 format. If the language uses UTF-8 as native string format, it is much easier for text processing, which is why Go chose it. There are a lot of subtle technical details you will only realize after working with many text processing components.

Can't agree more.

Re: Making Python 3 more attractive

#168

Post by [deleted] »

eeZi wrote: post #153
reidrac wrote: post #72

Earlier quoted context omitted.

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.

[deleted]

Re: Making Python 3 more attractive

#169

Post by eeZi »

eeZi wrote: post #153
reidrac wrote: post #72

Earlier quoted context omitted.

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.

Refer to this comment for an alternative way to install Python 3.4 without compiling it yourself: https://news.ycombinator.com/item?id=9389742

Re: Making Python 3 more attractive

#170

Post by k_bx »

Latty wrote: post #99
k_bx wrote: post #64

Earlier quoted context omitted.

Yeah, this was a very unwise thing to make, at least this could be postponed for later.

What? And make another language breaking version down the line? Better to rip off the plaster in one fell swoop.

It's better to make multiple breakages one by one than not doing them at all. On a plus side, maybe at some point you'd realize this print statement isn't that important anyway to make thousands of edits all over the world.
Post reply on HN