Comment by rdtsc | Hacker News Reader

Comment by rdtsc | Hacker News Reader

Parent Full thread

> Not much has changed in python 3? What rubbish. You just have to look at the thousands of commits, and change lists.

Sorry, I'll have to disagree with your disagreement. Thousands of commits doesn't mean it is worth breaking backwards compatibility. Unicode support? Yeah it is nice. But it worked fine for me before. Print is a function. Again, pretty nice, not nice enough to break backwards compatibility.

> Python 3.4 has generic functions to do single dispatch matching on type.

Ok. Never really needed that in Python. So again not worth breaking backwards compatibility.

> There is the new asyncio library for really elegant async,

That is a bad idea. Promises and futures are not a very good concurrency construct. Light threads, processes and message passing are better. Twisted has been around for ages, and even though it is used here and there it hasn't exactly taken the world by storm yet. So I certainly don't see it as a positive, rather it is a negative. I would rather they adopted greenlet and supported gevent better or integrated PyPy's STM

> We have CFFI for simpler FFI.

Ok, I just used CFFI in Python 2 last week, worked great.

> Lambdas are kept simple for readability, as functions are preferred.

Heavy lambda usage is not that good of a practice in Python. And Python 2 has lambdas as well. It use them sparingly.

> I'm just going to stop here..

Oh no, please don't stop, because you haven't convinced many people Python 3 is better.

> You can statically type check python now (see pysonar2, pylint, and pycharm for example)

You know what has better static type checking? Go. I am sitting down looking at static type checking and fixing code for backward compatibility, I will also be evaluating other languages and platforms.

Python 3 is not bad. But is is not that much better than Python 2. Sorry. A lot of that is not Python 3's fault as much as a testament to how good Python 2 already was.

I think Python 3 should have offered a lot more than unicode and print as a function. A list of possible improvements:

  * A JIT compiler

  * An STM module
  
  * Better concurrency (removed GIL)

  * Maybe integrated requests or flask or some other modern web tools and libraries

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.

1. https://wiki.python.org/moin/GlobalInterpreterLock

> "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.

> 1. https://wiki.python.org/moin/GlobalInterpreterLock

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.

whats a good and performant mysql library for python 3 to use? or did you use postgres for all those projects?

I used postgres for all the projects I'm afraid, but the Mysql team provide a db-api compatible library here: http://dev.mysql.com/downloads/connector/python/ that supports Python 3

How about oursql (https://pythonhosted.org/oursql/)?

I agree. Python 3 fixes a lot of warts (range() defaults to xrange(), input() is the default) and does make the language overall more elegant (arbitrary head and tail unpacking with splat) but unfortunately it's not really worth a full switch. At least not for me.

A lot of the goodies from 3.3 were back ported into python 2.7, to ease portability. Python 3.4 makes it more backwards compatible still (whilst staying elegant). However, now there are also some new features that are not getting back ported.

Using argument annotations for type checking is quite useful in IDEs and for statically checking your code.

Asyncio, and yield from have been in the design phase for many years by Guido and the community. This is seriously well thought out concurrency done by people with lots of experience. It's the 4th generation async framework for python.

The better unittest framework saves me time, and helps me with error handling.

pip installed everywhere is a serious productivity improvement.

Function dispatch based on type (ie, pattern matching like some functional languages) is something I've missed for years. It was originally planned for py3k, and I think is the main missing piece from the original design docs.

Importlib is much improved, so you can do some really interesting things with importing code. If you're working on IDEs, or other apps like games this is pretty cool stuff.

Little things like the enum module make APIs that tiny bit cleaner and more intuitive to use.

Speaking of nicer APIs, the Documentation got a lot of fixups too in Python 3.4.

Want to track down memory leaks? Python 3.4 has a whole new set of memory debugging primitives to make this much easier.

There were also a lot of security improvements for 3.4 that have not been backported.

Reply on news.ycombinator.com