Ridiculous. Python 2 has many many warts and the right thing to do was to fix them. Why the heck is print a statement? Why do we have urllib and urllib2? Why are generators not that useful?
>> That is a bad idea. Promises and futures are not a very good concurrency construct. Light threads, processes and message passing are better.
Not so much in Python I'm afraid. The new asyncio module is worth the switch by itself I find, while Twisted is pretty good it can be very verbose and suffers from a number of issues.
You say that it's not worth breaking backwards compatibility for genuine warts in the language and seem to think it's only worth progressing the language if its by implementing huge changes like adding a JIT or removing the GIL (why you would think of bundling requests or flask with Python is beyond me). Python 3 may not have those big blockbuster features but its a nicer language with fewer warts (from __future__ import division? please).
I gave Python 3.4 a try while porting a Twisted application to asyncio and I was very surprised. After using it in a couple of Django projects I have yet to come across any packaging issues, and I use the awesome 'six' library so my code runs on 2 and 3 without modification.
> Why the heck is print a statement? Why do we have urllib and urllib2? Why are generators not that useful?
So what if it is. Why not just make prnt a function. Or println or something.
Have urllib and urllib2. Make urllib2 or just put requests in the stdlib.
Still don't see what was worth breaking backward compatibility over.
> You say that it's not worth breaking backwards compatibility for genuine warts in the language and seem
I say it is not worth doing it at the time they did. It just came too late. People how didn't pick python over other frameworks probably weren't put off by the print statement.
This should have happened 5-10 years ago not now. Not it was time for better performance, packaging, web frameworks, better concurrency constructs.
> ts by implementing huge changes like adding a JIT or removing the GIL (why you would think of bundling requests or flask with Python is beyond me).
Removing the GIL shouldn't break sane code. With GIL you still have race conditions and have to guard against them. You just can't run CPU bound code in parallel. That would be nice to fix.
And if it is beyond you read up on how JPython works because it doesn't have a GIL.
> why you would think of bundling requests or flask with Python is beyond me)
How does bundling a library like that break code?
> I gave Python 3.4 a try while porting a Twisted application to asyncio and I was very surprised.
I switched to using gevent from Twisted and saw speed improvement and code reduction by about 30-50%.
> So what if it is. Why not just make prnt a function. Or println or something.
Make another function to print output while also having a print statement? "There should be one-- and preferably only one --obvious way to do it". Same with urllib. Lets just be clear, they didn't release Python 3 because urllib and urllib2 were not combined, so no by itself it's not worth breaking backwards compatibility for (and hence why there were 2 urllib modules). But combined with a bunch of other issues, some of which necessitate breaking backwards compatibility, why not combine them?
> I say it is not worth doing it at the time they did. It just came too late. People how didn't pick python over other frameworks probably weren't put off by the print statement.
Fair enough, but better late than never right? You can't maintain backwards compatibility forever especially with syntax changes. That's why it was put into a major release and the 2.x branch continued to develop. Porting the code isn't hard (there are even automated tools to do it, like gos gofmt command), and I think every major web framework supports py3 now.
> How does bundling a library like that break code?
The best things about python packages is they can be updated independently of the standard library that ships with Python. Why would you want to add flask or requests to the standard library? Is executing one shell command too hard? Including popular packages just because they are popular at the time is not a good thing to do.
> And if it is beyond you read up on how JPython works because it doesn't have a GIL.
You mean Jython? That's a silly comparison. CPython is the reference implementation for Python. A JIT compiler could be added to it, sure, but actually think about it for a second: writing a JIT compiler for Python is a huge undertaking. PyPy has one, but it's not 100% compatible (no eval and others for example, which is sometimes used) and for some workloads slows down execution. Not to mention PyPy is a very advanced project and it has taken years and years of development by people specialized in writing JIT compilers (remember Psyco for Python 2.5?) to get PyPy to where it is now, expecting the Python developers to whip up a usable JIT compiler in a jiffy is not exactly realistic. Adding one would add huge complexity to the reference implementation of Python, the same goes for the GIL. Read here[1] for reasons why the GIL will never be removed and use the awesomely simple multiprocessing library to spread work over multiple cores, that's why it was made.
> "There should be one-- and preferably only one --obvious way to do it".
That or split the community and spend thousands and thousands of man hours, coding, planning, talking about, arguing on HN over a print statement vs function. I'll take a 2nd function over it any day.
> The best things about python packages is they can be updated independently of the standard library that ships with Python.
That is a separate issue. I was just responding to you saying how adding flask or some web framework or client would break code. And I think we can agree that adding a module won't break existing code if it is not using, wouldn't you agree? Now ok, maybe adding something like that is a bad idea as you said, as it will become ossified and kind of stuck (including bugs and warts). Ok, sorry that was a bad example. I was just trying to think if big enough thing that _would_ have justified switching to a new version.
> You mean Jython? That's a silly comparison.
Sorry Jython. Why is it silly? If the effort put into PyPy combined with effort put into Python 3 transition (including time wasted arguing about it, porting, designing shaming websites "check out these unported Python 2 projects") were put into it removing the GIL it would have probably worked.
> Not to mention PyPy is a very advanced project and it has taken years and years of development by people specialized in writing JIT compilers (remember Psyco for Python 2.5?) to get PyPy to where it is now
Yes, I know I was using Psyco back in the day and every time I was using (and I did measure and it did improve the speed quite a bit) I was think why the heck is this not in the base distro?
Remember, I didn't say this hypothetical "better" Python 3 had to have yet another JIT separate from Psyco, Jython, PyPy, Unladen Swallow (LLVM). It could have been any one of those. And that would have been a worthy enough carrot to get people more excited. The port would have taken less time, with less drama.
I know it is hard but I didn't say any of those would be easy. It is in fact kind of hard to beat Python 2 (or rather to offer something a lot more compelling to justify switching to it).
By implication here, not switching to 3 would have been a valid step as far as I see.
>> That is a bad idea. Promises and futures are not a very good concurrency construct. Light threads, processes and message passing are better.
Not so much in Python I'm afraid. The new asyncio module is worth the switch by itself I find, while Twisted is pretty good it can be very verbose and suffers from a number of issues.
You say that it's not worth breaking backwards compatibility for genuine warts in the language and seem to think it's only worth progressing the language if its by implementing huge changes like adding a JIT or removing the GIL (why you would think of bundling requests or flask with Python is beyond me). Python 3 may not have those big blockbuster features but its a nicer language with fewer warts (from __future__ import division? please).
I gave Python 3.4 a try while porting a Twisted application to asyncio and I was very surprised. After using it in a couple of Django projects I have yet to come across any packaging issues, and I use the awesome 'six' library so my code runs on 2 and 3 without modification.