Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

You should avoid making technical decisions based on emotional impulses.

Technically Python 3 is superior, IMO, to Python 2.7 and barring any setbacks such as unported libraries (which are becoming increasingly scarce) I wouldn't start a new project in Python 2.7.

The reason libraries have been taking so long is because so many people are resistant to change that they hadn't begun making any serious efforts to port to Python 3 until 2011 by my estimation.

Python 2 is so ass-backwards and broken that I find it painful to use on large code bases. It conflates strings and byte streams, has pathetic Unicode support, and its libraries are rife with bit-rotting code. For the batteries to continue being useful they need to be updated once in a while. Have you seen urllib? It's atrocious by today's standards! Python needed an update and I think that the core team made the right choices.

The challenge has been porting and the core team knew that. They made some poor decisions in hind-sight such as 2to3 and dropping u"", but otherwise the porting story is not as painful as it seems. Cherrypy did it ages ago and Django is finally getting around to it. SQLAlchemy supports Python 3. There are fewer reasons not to switch than ever before and yet articles like this still come up to this day.

Python is only going to fall by the way-side if the developers of the language decide to stop using it. The language hasn't gotten worse by any stretch of the imagination. It needs more contributors to make it better. If you like it so much, port your libraries, contribute to python core, and stop complaining! It's been like five years people!



Sorry in advance that this is so negative, but it reflects my honest feelings, as well as some experience.

The big problem with Python was always predicting what any given piece of code would actually do. Considering the lack of static typing, pervasive use of exceptions for non-exceptional cases, and subtle behavior changes in the core language from version to version, you basically never knew what you were going to get. On the plus side, all the Python libraries I ever used were open source and the code was easy to access. On the minus side, I needed to access that code on a daily or even hourly basis. Getting something working on my own machine wasn't too hard. Getting something working on anyone else's computer was a challenge.

It seems that most Python developers now use virtualenv. This is a handy little tool that creates a small runtime environment for your Python program. Basically, it allows you to explicitly set the version of every library that you use.

I always viewed virtualenv as a sign of Python's failure. Having stable APIs is damn near impossible in Python, so let's just give up and use old versions for everything. Put the whole mess in an airtight chamber, and hope you never need to do anything with it in the future. With an attitude like this, it's no surprise that the adoption of Python 3 has been pushed off into the indefinite future.

Issues like the global interpreter lock (GIL) and lack of real GC for data structures with cycles just reinforce the impression of a better /bin/sh, not a serious language. Sadly, in some ways, Bourne shell is still the better language, because it got backwards compatibility right, has a bigger install base, and better startup time. It's also significantly less verbose for simple tasks. And really, if your task isn't simple-- you shouldn't be using a language that doesn't even properly support threads.

tl;dr: Overall, I think my interest in Python has come to an end. It's over, sorry.


One nitpick:

> lack of real GC for data structures with cycles

This has not been true since (AFAIK) Python 2.0, which was released 12 years ago.


> > lack of real GC for data structures with cycles > This has not been true since (AFAIK) Python 2.0, > which was released 12 years ago.

Sorta.

It seems that CPython still can't garbage collect objects in cycles if those objects have a __del__ method.

See http://www.electricmonk.nl/log/2008/07/07/python-destructor-...

Or see gc.garbage, from http://docs.python.org/release/2.7.3/library/gc.html




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: