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

91–100 of 172 posts

Re: Making Python 3 more attractive

#91

Post by baq »

bufordsharkley wrote: post #69
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…

Cleaning up Exception chaining, and removing unnecessary boilerplate from super() were two more nice improvements I personally really enjoy.

exceptions are actually the most important thing for me in practice, even though almost no one ever mentions that. guess only my code ever throws exceptions. /s

Re: Making Python 3 more attractive

#92

Post by wora »

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,…

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 support. For people who work deeply in i18n support, UTF-8 encoding is the only practical solution. Python 3 string should use UTF-8 much like Go. Just for reference, Google stores almost all data as protobuf, which only support UTF-8. That proves the story.

Re: Making Python 3 more attractive

#93

Post by coldtea »

raverbashing wrote: post #87
plesner wrote: post #71

Earlier quoted context omitted.

To what end though? It's a small thing sure but it's busywork. Why am I being asked to do busywork?

Yeah, I don't like the busywork that Pep8 makes me do it, and it's a lot, and some of it is stupid, but it has to be done You certainly don't have to do it if you don't want Python 3 and 2to3 makes it a lot easier

>Yeah, I don't like the busywork that Pep8 makes me do it, and it's a lot, and some of it is stupid, but it has to be done

Actually no, it hasn't. PEP8 is just a formatting standard, your code will work with your own standard too.

Re: Making Python 3 more attractive

#94

Post by coldtea »

mrweasel wrote: post #84

Honestly I thought that we where done with 2 vs. 3. Every new project we start is Python 3 and I don't hear anyone in the office preferring Python 2. Dealing with Scandinavian languages having the Python 3 Unicode support is the killer feature in Python 3, it just make everything so much easier. In terms of performance it's fine and library support is no longer an issue (for us at least), everything we use just works…

Yeah, perhaps your experience in your office is not generally representative?

In PIP, Python 3 has like 5% uptake...

Re: Making Python 3 more attractive

#95

Post by the_mitsuhiko »

jeffbr13 wrote: post #46
rdtsc wrote: post #4

> The Unicode support that comes with Python 3 is "kind of like eating your vegetables", he said. It is good for you, but it doesn't really excite developers Saddly I agree with that. There needs to be either a big stick (Python 2 being really bad, but it is actually pretty good) or a large carrot ("Oh look 3x performance improvement!"). Something like a carrot was presented during Pycon and that was gradual types (o…

> There needs to be either a big stick (Python 2 being really bad, but it is actually pretty good) Doing any non-ASCII string-processing in Python 2 with any regularity is a more than regular-enough beating for me.

> Doing any non-ASCII string-processing in Python 2 with any regularity is a more than regular-enough beating for me.

Can you elaborate on this? Unicode processing is the same on 2.x and 3.x for the most part. There are some differences in interpreter internals, how string literals are represented and the internal representation was changed (and obviously the literal defaults and bytestrings were removed), but other than that the unicode support is more or less equivalent.

Re: Making Python 3 more attractive

#96

Post by coldtea »

sanxiyn wrote: post #77
mahouse wrote: post #31

Just make it faster and everybody will move. No need for fancy new stuff... I'm eager.

"Just make it faster and everybody will move" is demonstrably false. See PyPy.

PyPy is another implementation. Might as well be another planet. Extensions break or are slower. Different toolkits. DB Drivers not working, etc.

Re: Making Python 3 more attractive

#97

Post by TsukasaUjiie »

"For another, conventional wisdom holds that reference counting and "pure garbage collection" (his term for mark and sweep) are roughly equivalent performance-wise, but the performance impact wouldn't be known until after the change was made, which might make it a hard sell."

AFAIK there exists RC GC's which are performance equivalent to MarkSweep, but these aren't super common out of academia? What is the state of GC performance in python currently?

Re: Making Python 3 more attractive

#98

Post by sago »

kaoD wrote: post #90
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…

Disclaimer: I used both Python and Node.js at job, and use Node.js regularly for side projects. I think the difference is that Node embraces the single-threadedness as part of its architecture. I don't use Python that much now so I'm not sure if it's changed, but I found it clumsier by default. I know there's Twisted and other nice evented/multiprocess libraries that make Python closer to Node, but it surprises me th…

GIL is a bogeyman, particularly from folks who've never deployed large python codebases, so I was fully expecting downvotes. Unpopular opinions attract them. Though it would be more gratifying to see downvotes along with people's use cases for when GIL was a genuine issue for them.

I agree that Node has its single-threadedness baked in, and Python doesn't clearly have one way to do it. Still, I think that multithreaded programming isn't very scalable in the long-run. Learning Erlang and figuring out that message passing buys you much more headroom was important to me. I like that you can do simple things in Python simply, but it is important to have some understanding of why different languages solve the problem in different ways, and what approach is best for a problem domain. My sense is that Node's default approach is actually very good for a large range of situations, a larger range than multithreading, anyway. But that could be because my use-cases are often either UI or CPU bound.

In your example, is your domain primarily internet servers (what I assume is Node's sweet spot for commercial deployment).

Re: Making Python 3 more attractive

#99

Post by Latty »

k_bx wrote: post #64
bufordsharkley wrote: post #52

Earlier quoted context omitted.

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.

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