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

141–150 of 172 posts

Re: Making Python 3 more attractive

#141

Post by abusque »

bryanlarsen wrote: post #21
abusque wrote: post #15

I find it somewhat unfortunate that a LWN subscriber link is being abused like that. I don't think such a link should be shared on a widely accessible platform like Hacker News. I find LWN articles to always be of great quality, and the subscription cost is definitely worth it if you can afford it. Also, "subscriber-only" content becomes publicly available after only a week. There is consequently no reason to share a…

Jonathon Corbet, the editor, encourages occasional subscriber links posted to Hacker News: https://news.ycombinator.com/item?id=5688938

I wasn't aware of his stance on this specific matter. I guess I was needlessly worried, then.

Re: Making Python 3 more attractive

#142

Post by qznc »

rburhum wrote: post #134
qznc wrote: post #76

Earlier quoted context omitted.

A practical perspective depends very much on your specific use case. Server programming? Scripting? Scientific computing? Games? Tooling?

I am honestly curious if there is a good argument for any of the examples you mentioned.

Scripting and Tooling becomes more robust wrt Unicode. You write a short script which works on some ASCII data. Later that ASCII suddenly becomes utf8. With Python 2 you could easily run into weird issues, when there is a unicode object instead of the expected str. With Python 3 decode is more explicit and robust.

Scripting and Tooling are the major uses of Python for me, so I like Python 3.

Re: Making Python 3 more attractive

#143

Post by mrsteveman1 »

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?

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

Re: Making Python 3 more attractive

#144

Post by beagle3 »

kibwen wrote: post #119
beagle3 wrote: post #27

Earlier quoted context omitted.

Have you tried Nim[rod]? Seems to be pythonesque in almost every way, except speed, in which it is goesque.

Aside from having whitespace-sensitive syntax, Nim isn't Python-esque at all. Nim very much encourages TIMTOWTDI over Python's there-should-be-preferably-one-way-to-do-it. Nim also has extremely flexible syntax where Python is rigid. See Nim's pervasive use of metaprogramming via macros, or its inclusion of user-defined symbolic operators (as per Haskell and Scala), or the fact that it considers `foo` and `Foo` and `…

I agree that idiomatic Nim (if there is such a thing) is very different than idiomatic Python.

What I meant (and did not express clearly) is that you can write mostly pythonesque code in Nim, and it will perform as well as Go. You don't have to modify the syntax, use macros, define symbolic operators, operational transforms, etc any more than you have to use metaclasses in Python.

At it's core, if you write "typed python" code in Nim, it will work, be readable, and perform well.

Re: Making Python 3 more attractive

#145

Post by vessenes »

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…

I like PyPy, it's great work. But, it doesn't always work. Our last project that used python seriously used tornado and occasionaly numpy. Getting it all glued together was lots and lots of frustration, confusion about versions, and so on. PyPy just isn't mainline python. Which is really what the 2 vs 3 debate is about, in the end. If you have a 'batteries included' language, making breaking changes could take a long time.

Re: Making Python 3 more attractive

#146

Post by vessenes »

beagle3 wrote: post #27
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…

Have you tried Nim[rod]? Seems to be pythonesque in almost every way, except speed, in which it is goesque.

I haven't, but I have tracked Nim since announcement. It might be a great language, but I don't think it will ever be appropriate for my use case, which is reasonably performant mid-size codebases that junior/journeyman developers can be productive in almost immediately.

If you read the "Why Nim" posts, they are highly salient points for a 'journeyman' or better developer that wishes to be highly productive on a small project; I read the list of 'better than Go' stuff with that hat on, and it's very appealing.

But, there's too much rope to hang oneself in Nim for my use case. Getting a language stripped down just enough that team productivity over years is maximized is a very, very hard thing to do. I think the go folks have the best take on it right now, and it's run by courteous and responsive grownups who do what they say they'll do. That's a total win in my book.

Add in go fmt, a very good (not without warts) module import system, reasonable testing and a multi processor programming model that's easy to reason about, and it is a very, very good solution for my needs.

Re: Making Python 3 more attractive

#147

Post by [deleted] »

beagle3 wrote: post #27
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…

Have you tried Nim[rod]? Seems to be pythonesque in almost every way, except speed, in which it is goesque.

[deleted]

Re: Making Python 3 more attractive

#148

Post by keyneus »

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 still don't think it's an especially good language, and type checking with it will never be as useful as with a language where it's built in and required), but it's not as pressing of a concern.

I think type checking turns Python into a bearable language.

Re: Making Python 3 more attractive

#149

Post by wiz21z »

I've ported a 100KLOC project. Took me a week or so to do it. But it took me months to iron out the last bugs. Had no problem with libraries (so I just had to support the language)

Fact is 2to3 is nice but it doesn't give you any guarantee about its code coverage. So you go almost just as fast working by hand.

But the lack of guarantees, that makes working in production very dangerous.

Tried to support 2 and 3 at the same time, but that's just too exhausting and error prone (one has to check in both python2 and python3)

Projects with 100% test coverage don't exist, spare time project have even less test coverage.

For me unicode was the driver to change. And it paid off. And I think that's the only P3 feature that actually improves expressivity (now I can clearly express unicode strings). The yield stuf, etc. is fine but nothing /that/ impressive.

For performance, forget PyPy, a 5x/7x improvements is not enough : you still can't write high perf code with that. If PyPy was 50x faster than CPython, that would be something.

So basically, after a lot of efforts I'd say write Python3 code because it helps Python or because you use unicode. Any other reason seems a bit weak to me. And that's sad, I've bet on Python 4 years ago and it didn't evolve much (it surely became very stable, which is not funny but damn useful!).

I guess the point of the 2-3 war is precisely that : 2 and 3 are different but not different enough... So people have hard time to make a choice.

Re: Making Python 3 more attractive

#150

Post by mixmastamyk »

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 don't mind print being a function so much, but rather the required parens. If they could somehow be optional, I'd bet 90% of the problems associated with the break would dissolve.
Post reply on HN