Just make it faster and everybody will move. No need for fancy new stuff... I'm eager.
I agree. Introduce a JIT in CPython and optimize the hell out of it like Javascript does.
Making Python 3 more attractive
81–90 of 172 posts
Re: Making Python 3 more attractive
#82I would like to learn Python to use it for web apps - what version would you recommend now to begin with?
If you're starting now, there's really no reason not to begin with version 3.
Re: Making Python 3 more attractive
#83> 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…
I strongly disagree, in regards to Unicode. Unicode in Python 3 alone makes it worth switching from Python 2.
Re: Making Python 3 more attractive
#84Honestly 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.
Re: Making Python 3 more attractive
#85> 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 appro…
FYI, greenlet already includes stack switching code, so it would make more sense to use that. https://github.com/python-greenlet/greenlet/tree/master/plat...
Ah, neat. Looks like they have even more backends than me. I've never even heard of S390 before. Okay, nevermind then. Thanks for the link.
That's the downside of these libraries, there's as many libraries as there are people wanting to do this. I've been hoping for a standard to emerge, even if it's not mine. This looks a bit too tied into Python to be general purpose, though.
Re: Making Python 3 more attractive
#86Earlier quoted context omitted.
Exactly this Why is changing 'print stuff' to 'print (stuff)' such a big deal? I think 2To3 solves a lot of print cases https://docs.python.org/2/library/2to3.html
The print function is clearly a better, more precise way to handle it, to be sure... But the print statement was one prominent, attractive way that Python was essentially pseudocode-- its removal seems an improvement from a pedantic sense, but one that seems to run contrary to convenience and (perhaps) the expectations of a beginner.
I disagree about this being worse for beginners - if we're teaching a new programmer about functions, surely a basic print function is a great introduction? Whereas before it was a one-off special case.
Re: Making Python 3 more attractive
#87Earlier quoted context omitted.
Exactly this Why is changing 'print stuff' to 'print (stuff)' such a big deal? I think 2To3 solves a lot of print cases https://docs.python.org/2/library/2to3.html
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
Re: Making Python 3 more attractive
#88> 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 appro…
libco seems pretty interesting. Do you alswo have some code to show which uses it? Just to get an idea of what you use it for typically. Have you used it with Python alreday?
The code that uses it is pretty complex (go up two folders in my gitlab link for that), so here's a minimal example of the full API:
cothread_t a, b; //cothread_t is a typedef to void*
int main() {
a = co_active(); //get a handle to the main thread
b = co_create(entrypoint, stacksize_in_bytes);
printf("a");
co_switch(b);
printf("c");
co_delete(b); //no need to delete a
}
void entrypoint() {
printf("b");
co_switch(a);
}
//output: "abc"
Re: Making Python 3 more attractive
#89GIL 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 experience, building big multithreaded applications with shared memory access isn't great design anyway. I prefer systems that share as little as possible, and can therefore scale beyond a single machine when needed.
So I think the focus on the GIL is a false quest. It isn't a bad compromise to a thorny implementation issue (it allows certain performance optimisations, without forcing you to worry about re-entrancy and atomicity when writing simple code). Removing the GIL will be a big thing for pundits, I think, but won't make much of a difference to big python deployments. It certainly isn't the killer app for Py3 adoption.
Re: Making Python 3 more attractive
#90GIL 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 that a batteries-included language with a GIL has to be, as you say, worked around. I don't work around single-threadedness in Node, I work towards it! And the platform encourages me to do so.
EDIT: I'm not sure why you seem to have been downvoted (man, I hate HN sometimes). Here's an upvote to counter it.