4 ms·

I will get excited when it actually works out to be faster than interpreters with the GIL. I'm a bit disappointed that Python seems to have no interest in stan

I will get excited when it actually works out to be faster than interpreters with the GIL. I'm a bit disappointed that Python seems to have no interest in standardizing a lightweight-thread (greenlet, coroutine) interface that isn't an awful mess. yield is powerful but coroutine implementations with it are baroque and opaque. Java-style threading has a million gotchas and the interface is just a dog. I want to be able to teach people with a week of experience to write concurrent programs. (What about writing turtle programs with multiple turtles running at the same time?) If Python doesn't do it, then I want someone else to eat their lunch.

jmtulloss 14y ago
Stackless works fine for this kind of thing.
Tobu 14y ago
Which of the existing coroutine implementations have you tried, and what did you dislike about it?
- jlgreco 14y ago
  In my humble opinion, the greatest problem with all of them is that there are so many. Most of them are rather fine I think, but it can just be a serious pain in the ass getting your head around all of them.
  - Tobu 14y ago
    I've only needed one (Twisted, which is actually slightly outside the space occupied by gevent et al). You can't stop people from building more, but feel free to bet on a popular project if you don't want to deal with choice.
    - jlgreco 14y ago
      In a world where I only work with my own code, that works. Unfortunately that is not my reality.
- slurgfest 14y ago
  The issue isn't that all the third-party implementations are no good, several are good. It's that there is no Pythonic one which is also standard and blessed, which would help with interoperability as well as providing one obvious way to do it. I'd rather Python moved in the direction of go than Java
viraptor 14y ago
Most likely it never will be faster than just GIL. It may be very close to the same performance, but nothing is likely to beat a "one lock every N thousands of instructions" approach when you have a single thread. If it's within 5% though, I'll be happy - especially if the backend is possible to switch. It seems that it's possible now - so if you know you're running only in a single thread you could just choose the cut-down version.

jmtulloss 14y ago

Stackless works fine for this kind of thing.

Tobu 14y ago

Which of the existing coroutine implementations have you tried, and what did you dislike about it?

jlgreco 14y ago
In my humble opinion, the greatest problem with all of them is that there are so many. Most of them are rather fine I think, but it can just be a serious pain in the ass getting your head around all of them.
- Tobu 14y ago
  I've only needed one (Twisted, which is actually slightly outside the space occupied by gevent et al). You can't stop people from building more, but feel free to bet on a popular project if you don't want to deal with choice.
  - jlgreco 14y ago
    In a world where I only work with my own code, that works. Unfortunately that is not my reality.
slurgfest 14y ago
The issue isn't that all the third-party implementations are no good, several are good. It's that there is no Pythonic one which is also standard and blessed, which would help with interoperability as well as providing one obvious way to do it. I'd rather Python moved in the direction of go than Java

viraptor 14y ago

Most likely it never will be faster than just GIL. It may be very close to the same performance, but nothing is likely to beat a "one lock every N thousands of instructions" approach when you have a single thread. If it's within 5% though, I'll be happy - especially if the backend is possible to switch. It seems that it's possible now - so if you know you're running only in a single thread you could just choose the cut-down version.