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…
Making Python 3 more attractive
21–30 of 172 posts
Re: Making Python 3 more attractive
#22I 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…
"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* "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
#24Nothing 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.
Re: Making Python 3 more attractive
#25I 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…
Re: Making Python 3 more attractive
#26I 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
#27Python 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…
Re: Making Python 3 more attractive
#28If 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.
Re: Making Python 3 more attractive
#29Re: Making Python 3 more attractive
#30Nothing 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.