Live data from Hacker News

Making Python 3 more attractive

lwn.net

21–30 of 172 posts

Re: Making Python 3 more attractive

#21
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

Re: Making Python 3 more attractive

#22
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…

https://lwn.net/op/FAQ.lwn#slinks

"Where is it appropriate to post a subscriber link?

Almost anywhere. Private mail, messages to project mailing lists, and blog entries are all appropriate. As long as people do not use subscriber links as a way to defeat our attempts to gain subscribers, we are happy to see them shared."

Re: Making Python 3 more attractive

#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 Python 3 or have an active fork. Even OpenStack is working on Py3 support.

Re: Making Python 3 more attractive

#24
post #19

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.

It doesn't, it just is easier to scan. There isn't a goal of being completely free of syntactic elements, semicolons went because they were excessive and noisey, colons seem, at least to me (comparing with say, coffeescript) to make it less noisey.

Re: Making Python 3 more attractive

#25

I don't think any of the things proposed will really drive conversion from Py2 to Py3. I don't think developers need to be excited about it, it just needs to be plausible. Python 3 has some significant momentum now (these talks seem overly negative about it). Developers are waiting for the signal from the enterprise Linux distributions that Py3 is "truly stable", i.e., they're waiting for it to be made the default Py…

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 1.8 to 1.9, there was nowhere near as much of a flag day of pain, even though they were attempting to solve the same overall problem (Unicode), and even though Ruby 1.8 was actually abysmal at Unicode (unlike Python 2, which contrary to many of the people who like to try to carrot people to Python 3, does not have any issues with Unicode; in fact, if anything, Python 2.x is better than Python 3.0 was, as Python 3 decided to "fix" a bunch of things, like filename encodings, which actually should not be assumed to have an encoding :/).

Re: Making Python 3 more attractive

#26
> Windows has the CreateFiber() API that creates "fibers", which act like threads, but use "cooperative multitasking". For POSIX, using a combination of setjmp(), longjmp(), sigaltstack(), and some signal (e.g. SIGUSR2) will provide coroutine support though it is "pretty awful". While it is "horrible", it does actually work.

I do this, and it works perfectly well. Here's a full implementation demonstrating this approach: https://gitlab.com/higan/higan/blob/master/libco/sjlj.c

It's been successfully used on x86, amd64, ppc32, ppc64, mips, arm and sparc in several projects.

However, it still has a good bit of overhead. But you can implement this concept absolutely trivially on any platform for maximum speed. All you need to do is save the non-volatile registers, swap the stack pointer, restore the non-volatile registers from the swapped-in stack, and return from the function. If you haven't realized, one function can reciprocally save and restore these contexts. Here's an x86 implementation, for example:

    co_swap: ;ecx = new thread, edx = old thread
    mov [edx],esp
    mov esp,[ecx]
    pop eax  ;faster than ret (CPU begins caching new opcodes here)
    mov [edx+4],ebp  ;much faster than push/pop on AMD CPUs
    mov [edx+8],esi
    mov [edx+12],edi
    mov [edx+16],ebx
    mov ebp,[ecx+4]
    mov esi,[ecx+8]
    mov edi,[ecx+12]
    mov ebx,[ecx+16]
    jmp eax
This turns out to be several times faster than abusing setjmp/longjmp.

I turned this into the simplest possible library called libco (public domain or ISC, whichever you prefer.) The entire API is four functions, taking 0-2 arguments each: create, delete, active, switch.

The work's already been done for several processors. Plus there's backends for the setjmp trick, Windows Fibers and even the slow-as-snails makecontext.

If Python does decide to go this route, I'd certainly appreciate if the devs could be directed at libco for consideration. It'd save them a lot of trouble making these, and it'd get us some much-needed notoriety so that we could produce more backends and finally have a definitive cothreading library.

Re: Making Python 3 more attractive

#27
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.

Re: Making Python 3 more attractive

#28

If the Perl6 rewrite is validated by it having a larger user base than Python 3 in 5 years' time, part of me that has died will be reborn. Unlikely, though.

What Perl6 rewrite? Perl6 is a specification. Are you referring to various compilers that have been implemented over the years as rewrites?

Re: Making Python 3 more attractive

#29
I noticed a while back that what really made me want to use python 3 is new features. Several script I use currently has a bunch of try-except that looks for functionality, and then monkey patch some python 3 feature into python 2. This will only get worse until library support allows me to switch.

Re: Making Python 3 more attractive

#30
post #19

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.

It's because there's a rule that every time you are going to start indenting more, there's a colon first. Since whitespace is rather invisible, it's a concession they make to make scoping more clear.
Post reply on HN