Hacker News Reader

Comment by illumen | Hacker News Reader

I doubt the lazy people who haven't moved to python3 will ever do a decent port of python 2. Python3 has been out for over six years now, with warning before that.

I'd much rather bet on the python developers who are shipping software. All major python libraries have been ported to python 3, many of them for years. There's 4799 packages registered on pypi as supporting python 3.

Python is becoming less popular? The author provided no evidence at all. Downloads of python3 from python.org are higher than python 2, and have been for a while now. Job websites show python having more postings than 2 years ago.

Not much has changed in python 3? What rubbish. You just have to look at the thousands of commits, and change lists. Python 3.4 has generic functions to do single dispatch matching on type. You can statically type check python now (see pysonar2, pylint, and pycharm for example). Not only as pypy made a major breakthrough with performant STM based concurrency(no threads), but threading has been improved in python 3 too. There is the new asyncio library for really elegant async, which go along with great generator improvements(yield from). We have CFFI for simpler FFI. Lambdas are kept simple for readability, as functions are preferred.

I'm just going to stop here... many of his statements are just insane. Like this one: "You might as well ask someone to port their entire codebase to Ruby". Um, yeah... porting a codebase to python 3 from python 2 would take more time than porting it to an entire other language. What complete nonsense!

Edit: the post isn't from Microsoft, so fixing it so it isn't misleading. There was a link to a Microsoft person on the top right of the page, which seemed to indicate he was the author. Instead it was just someone promoting the page. Oops/sorry!

View on HN

I'm the author. I've never worked at Microsoft (where did you get that?). I'm a Linux guy.

The "lazy people" you refer to is 98% of the Python community.

Python 3 didn't "gain" static type checking. You can (and I do) run pylint against Python 2 code which is just static analysis, not full type checking. The situation here has not changed between Python 2 and 3.

Python is glue code. You write a small piece of Python to tie together external libraries. Moving a smallish piece of Python code from Python 2 to Python 3 often means porting several 3rd party libraries. If you were to move to Ruby, all you'd need to rewrite is your own code, as there are likely already 3rd party libraries which need no porting.

Do you have examples for these critical 3rd party libraries that haven't yet been ported?

As I noted elsewhere in this thread, the list gets shorter every day:

http://python3wos.appspot.com/

Did you read the article? The long tail is the critical collection of libraries and most of them will never be ported. People write new Python 2 libraries every day, actually--the list is getting longer, not shorter. That said, gevent is an extremely critical library for a lot of production Python 2 code. There doesn't even seem to be a roadmap to port it to Python 3.

gevent is ported to python 3. I guess a proper release would be soon. See here: https://github.com/surfly/gevent/issues/38

If the libraries are used by people, they tend to get ported. Like most of the most popular packages, and 4799 packages listed on pypi.

Any others you depend on? I'm prepared to roll up my sleeves and help.

If you genuinely want to help, I suggest porting launchpadlib to Python3: https://bugs.launchpad.net/launchpadlib/+bug/1060734

This is affecting other parts of Ubuntu, as we don't always install python2 anymore after porting all the default apps to python3. The lack of python3 launchpadlib means apport (the automatic bug reporting tool) doesn't work on some installations.

edit: porting launchpadlib requires first porting lazr.restfulclient, which might be genuinely challenging: https://bugs.launchpad.net/lazr.restfulclient/+bug/1000801

Let's assume a modestly sized Python program uses 8 libraries or so. Assuming 80% of libraries are ported, that means 20% aren't. The likelihood of at least one of your 8 libraries not being ported is 1 - (0.8)^8 = 83%. In other words, most people will find that at least one of their cricitcal libraries is not ported. That is certainly the case for me (Bloomberg Python API, for 2.7, and which, btw, only came out 6 months ago). Inevitably the people using Python come from specific domains, and use at least one domain specific library, so while all the common "usual suspect" libraries are ported, there is usually a very high chance that one critical library is not.

Perhaps the way the entire question should be thought of is: are there actually many properly useful Python 3 libraries that are not available in Python 2?? I bet the above equation would look much better when inverted.

Off the top of my head: Twisted and gevent. It was actually the lack of a Python 3 gevent that lead my to create one crucial piece of software for my startup using NodeJs communicating with the main Python application passing messages via Redis.

Twisted and gevent are available for python 3.

Look, I'm a Python 3 supporter, but you should never foist the Python 3 fork of gevent on anyone.

I'm pretty sure that, the monkey-patched way most people use it, it's a happy accident when gevent even works correctly on Python 2. This happy accident doesn't happen in an unofficial fork.

Available, yes. Working? No.

  File "/usr/lib/python3.2/site-packages/twisted/internet/_sslverify.py", line 1389
    self._cipherString = u':'.join(
                            ^

SyntaxError: invalid syntax

(Twisted 14.0.0, installed with pip)

Numpy, Scipy, NLTK.

These are really HUGE and I can not do my work without them.

And of those, only NLTK isn't compatible with Python 3.

i use NLTK with python 3.4 (and before that, 3.3); NLTK has an alpha release for pyhthon 3; i have not had any problems either installing it or using it.

To clarify: NLTK develop branch is compatible with Python 3.2+ for more than a year. NLTK 3.0a4 (http://www.nltk.org/nltk3-alpha/) is not released as NLTK 3.0 because of some pending API changes, not because of Python 3 compatibility issues.

Ok so why would I risk hitting even one incompatible library or have stuff break because those are dev experimental, untested branches. Why? What does Python 3 offer me except risk of breakage?

If you are running multiple automated eCommerce companies that have their core system written in Python 2 like I do, you'd find that boto/mws and python-excel aren't available for Python 3 (python-excel's porting to Py3 stopped in 2011), which would prevent you from spawning new businesses on Amazon or handling (unfortunately standard) MS Office interchange files quickly.

I actually made the decision to run on Python 2 due to unavailability of these libraries for Python 3 about a year ago (I didn't really care about Python before as I primarily used C++/Java/Asm/GLSL/C#/Haskell in the past) - I was deeply shocked by what Py3 did to its own community and still have that weird feeling that Python is slowly killing itself. I didn't want to write my own Amazon and MS Office wrappers in Python 3 anyway and from all platforms available Py2 seemed to have the least amount of troubles (though I had to write some Py3 code for handling advanced TLS properly).

yup. I think this is the reason so much eCommerce software is Java (& I'm sure there is a bunch of C# but that's not my thing). Java moves like a glacier but damn is it ever stable, and for those who wish to be "cutting edge" there is everything-under-the-sun on the JVM -- Clojure, Scala, Jython, JRuby, slimmer-by-the-minute Java APIs. And the community is just working their lil buns off trying to modernize this stuff while maintaining interop / backwards compatibility.

I think the flack Java gets is for not modernizing fast enough, but I think in a way that makes you stop and smell the roses (the roses being many years' worth of badass JVM features and massive flexibility/reliability in software development).

But Ruby & Python (I am an ex-Ruby guy) take this cutting edge thing wayyy too far & end up with a community of people who can't trust them anymore cuz they all had their damn feet shot off. Sometimes I see the rates for Ruby guys & wonder if they're high cuz its so productive or just cuz its very niche & the stack is shite. On principal, it's hard for me to imagine going back down that road after experiencing the JVM (plus, I'd like to get away from web one day...).

EDIT: Funny thing I just realized actually -- all the Ruby rates I've seen tend to be exactly on par with a lot of FUBAR niche near-extinct Java technologies. The only people I've seen do better than both these camps are down & dirty Linux/Oracle/Java guys. Maybe my view is skewed but I always feel like the rock-solid langs will live on & eventually "modernize" (though lets be real, modernize is kindof a BS term for slim API & lots of MVC tutorials). These other techs are at the mercy of market trends.

Java is simply becoming the next C. For a reason, in my opinion, since the languages share quite a few traits both on the language level and the ecosystem level. Both are fast. Both have a rock solid execution system which sometimes feels backwards compatible to the first punch card made of rock (gcc vs JVM). Both of them have huge communities having significant infrastructural services and other huge code bases developed in them (linux kernel, application servers, databases in both teams). The big improvement of java would be a higher programmer safety.

And to be fair, neither language is the prettiest, shiniest and fanciest for it's time, but they get the darned job done.

you (& bitL as well) make some fair points but I actually (maybe because I'm newer to Java?) have quite a different experience with it. The XML setup seems minimal now (sure it's all there but most stuff is now handled with reasonable default configs & annotations).

Take Jax-Rs is a good example. Once you understand it you're just like "Ohhhhh this is the same way Rails/whatever framework handles json requests but I can add in all this non-linear logic without forcing it to play nicely within a presumptuous design pattern". Adding many data sources & logic flows is easy.

Bottom line is that I feel like Java can never really be the next C because fundamentally its much safer and becoming way more human readable. It toes the line well -- you can code minimal stuff similar to the scripting languages, or you can drop years of work/research into optimization for high-transaction algorithms knowing that the platform won't abandon you.

(By the way, I am personally hoping for Clojure or node.js to take over the front-end of the stack & then just using Java to do any heavy lifting that is left over)

I worked at SUN in the distant past, the backwards compatibility was the mantra #1. Both latest Java and Solaris were expected to run the oldest possible code, and they considered it one of the most important assets.

For many people in eCommerce and banking the arrival of Java was a "manna from heaven", as before they had to deal with the crazy complexity of CORBA and similar technologies. Java simplified this significantly and added at the time modern easy-to-program and fairly safe multi-threading that allowed software like Apache etc. This made Java famous and gave it a "huge karma" amongst developers. Without Java we probably wouldn't have experienced the massive expansion of eCommerce, and now we are lucky to see all the Java's issues - a good problem to have ;-)

Java and JVM as a consequence have their share of problems that arose from initial design decisions such as type erasure (which .NET's CLR avoided) that still deforms all languages based on JVM to this day. Massive boilerplating, J2EE's unreadable XML mess, complex design patterns invented to cope with the limitations of the language are some of the other problems. The compatibility with the old code is still there though.

I've never played with Ruby, I've heard it's still used by many young web companies for their frontends (like SoundCloud) and have heard they had some release that broke most of the compatibility which alienated many of their users. From this and from Python's example I would suggest keeping both the old way and introducing the new ways in parallel so that developers don't have to rewrite/reinvent the wheel when somebody decides to change a part of the language. This served C/C++ pretty well, adding slowly new features and instead of forcing users to use the "current right way", they allowed to live multiple different approaches together. I think that would have served Python well as well - even Py3 feels at places like a hack, similar to Py2.

Indeed, 73% of popular packages in PyPi already support Python 3 http://py3readiness.org

And it's getting better everyday.

wxPython is a big one for me. But it looks more like it's dying altogether rather than not getting ported to 3.

Have you heard of python3-wx3-phoenix?

It is not dying. It just gets better.

I've heard of it, but there has never been an official release. I was looking forward to it for a couple years but I've given up.

I just looked at that list and I see several prominent projects that (according to that list) don't support Python 3: MySQL-python, gevent, Twisted, eventlet, oauth2, thrift, nltk, mechanize, etc. I've used more than a few of these libraries over the years.

I mean, yeah, the list is getting smaller. That's understood. But that doesn't render the problem of depending on only-Python 2 libraries moot.

I think the fundamental insight of the OP is that Python X (the purgatory corresponding to code compatible with both Python 2 and 3) is an absolute pain to write. There's plenty you can do to make Python X easier (like the `six` library or ignoring Python 3.{0,1,2}), but the programmer is still left with the burden of writing code compatible with both versions.

There's just no denying that the Python 3 transition is a huge fucking pain that is costing people tons of time and money. With that in mind, it is absolutely reasonable that people are resisting the change.

Twisted is mostly ported, and you can install via pip and pypi. Some of the more ancient parts remain to be finished however.

gevent is ported, but not in an official release.

There is a mysql alternative module.

mechanize is ported, but not in official branch

nltk alpha3 for python 3 is available

There are python3 thrift ports, but the maintainers are slow.

Yes, I knew most of that. But the fact remains that they aren't complete yet and therefore can't actually be relied on as a dependency.

(N.B. I seem to recall someone telling me that gevent had been ported over a year ago and that all that remained was to just make a release. So count me skeptical until the port is complete.)

And that's just the most popular projects. Imagine what it looks like with the less popular projects? It isn't pretty. This is what the OP was talking about with the "tail" of Python projects.

N.B. I don't personally have this problem with less popular projects. I've always done my best to avoid depending on unmaintained or inactive projects because they tend to rot as time goes on (irrespective of massive changes like Python 2 and 3). But plenty of other people have this problem and it's definitely not an unreasonable problem to have.

There's a large number of significant commercial applications that use Python as their scripting and plug-in language. Non of them that I am aware of are showing any interest in Python 3.

I'd love to have scapy for Python 3. A lot of ports of it have been started but it seems none of them reached a working state.

There was a link to a Microsoft person in the top right of your page. I mistook it for the author link. Edited post to remove that.

You are right that the same tools work for python 2. However, I mentioned tools there which allow python to do type checking, and type inference because they can be done now. See here on how to use them: http://renesd.blogspot.de/2014/05/statically-checking-python...

You're right in that case where you use several libraries that aren't ported. However, there's 4799 packages registered on pypi as supporting python 3, and most of the popular ones are ported. Considering that most libraries are ported, porting small scripts should be easy most of the time. I don't know if you actually ported any code, but it's often trivial.

4799 out of 44198 are python3? just a few more to go.

Not sure if you're just trolling, but the majority of the rest are probably close to being abandonware.

In every Python book I read they were recommending me to use Python 2.7 instead of 3.0. Shouldn't it be the role of educators to promote the latest version out there and work with it, so that by the time the new students get into a working environment they are already on the same page with what is required?

> Python 2.7 instead of 3.0.

Maybe you need to read more up to date books. The latest release is Python 3.4, and even most Linux distros are at least at Python 3.2.

> and even most Linux distros are at least at Python 3.2

Why are you spreading lies? You are hurting your cause (advocating Python 3).

Let's take a look at latest Ubuntu:

   $ cat /etc/issue
   Ubuntu 14.04 LTS \n \l

   $ python --version
   Python 2.7.6

How about the popular server distro CentOS 6?

  $ cat /etc/issue
   CentOS release 6.5 (Final)
   Kernel \r on an \m

   $ python --version
   Python 2.6.6

What exactly are these "most" Linux distros everyone is using that I haven't heard of?

Many distros include both Python 2 and Python 3 support. I think pdonis is saying that distros that support Python 3 are not stuck on 3.0. That is, their Python 3 packages are 3.2 or higher, so comparing 2.7 to 3.0 is unreasonable, since it's not a choice anyone has to make. Which seems to be true. For example, the relatively conservative Debian is currently on Python 3.2, with Python 3.3 in the next version. Ubuntu's python3 is currently 3.4. Fedora appears to be 3.2. Arch has Python 3.4, I think.

So what pdonis was saying is, as far as I can tell, true.

They do. But python3 is not the default python.

Download a python script run it and it will run on Python 2.7.6.

Yes that OP meant to say that because he clarified it later. But I don't see how his original comment of:

> most Linux distros are at least at Python 3.2

implies that. To me that says 3.2+ ships as the default version of Python.

> python3 is not the default python.

The post I was responding to talked about books on Python for students, presumably students studying programming. Python 3 doesn't need to be the default python for students studying programming to use it; it just needs to be available. If the post had been talking about, say, sysadmins, that would be a different story.

I think it's recommended for distros to modify the shebang to /usr/bin/env python3 for script that are supposed to run under python 3, although this does pose a problem for scripts that want to run under both without modification. If the distro ships with python3 and most of the system scripts run under python3 I'd say its the default.Ubuntu for one is planning on not shipping a python2 or /usr/bin/python binary by default(although it will still be in repos) eventually.

I think 3.0 was meant to be 3.x not 3.0 specifically.

You should try to run

    $ python3 --version

...instead.

Will the programs or scripts I download know to to that?

Any script worth it's salt that depends on a newer feature of Python 3 can just check `sys.version_info`. This was a thing one had to consider back when new versions of Python 2.x were coming out, too.

It's not quite that simple. Not all code that runs on Python 2 will be syntax-compatible with Python 3, and vice versa. You can, with some effort, use a subset of the Python syntax that is compatible with both interpreters, but many libraries do not do that, but ship separate Python 2 and Python 3 versions if they support both.

Syntax changes can be an issue for backwards compatibility, but that's not what I was talking about.

It's easy to specify what the minimum version of Python you want to support is. Even if there's syntax which is incompatible with Python 2 in the file, a hashbang that specifies `python3` is pretty clear.

Yes, #!/usr/bin/python3 is clear, but I don't think it addresses the question you were responding to, which was whether the scripts the OP of this subthread was talking about, which he knows will run under Python 2 (because he downloaded them and ran them under Python 2--he mentioned this in another subthread), will know to check for the presence of Python 3 and use it. Any such script will have to check sys.version_info to know which version of Python it is running under (and for at least one version the shebang will be irrelevant anyway since it can only specify python or python3, not both), and it will have to be syntax-compatible with both versions. If the script isn't syntax-compatible with Python 3, then he'll have to go find and download a version that is, if it exists.

> Why are you spreading lies?

Why are you assuming the worst possible intent on my part, instead of asking what I meant?

I meant the distros have Python 3 available, not that they make it the default that /usr/bin/python points to. Ubuntu has had Python 3 available for quite a number of releases; I run 12.04 which has Python 3.2 (and I've had it installed since I installed Ubuntu). According to the release notes[1], Ubuntu 14.04 makes Python 3.4 available, and work is ongoing to make it the default Python for Ubuntu. They also advise porting to Python 3.

It looks like CentOS makes Python 3.2 available, but I can't be sure from their online documentation.

[1] https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes

> most Linux distros are at least at Python 3.2.

I don't know how else to interpret that besides "the base version of python in those latest distros is at least 3.2"

Shipping it as an "alternative" just splits the library world into to. So that is not a distro being "at" a python version.

> It looks like CentOS makes Python 3.2 available,

It does. Do all the python-* libraries work with it. Or do I have to install those separately?

> I don't know how else to interpret that besides "the base version of python in those latest distros is at least 3.2"

Then you could have said that, or asked if there was another way to interpret it, instead of starting with "why are you spreading lies".

> It does. Do all the python- libraries work with it. Or do I have to install those separately?*

If CentOS works like Ubuntu, then there will be python3-* libraries for use with Python 3.

> "why are you spreading lies".

But I also didn't say you are spreading lies maliciously. You can spread them unknowingly via mis-communication.

I could post something like "Large parts of the Linux kernel are written in C++". And it would be spreading lies. But it could be just be me being confused as well or thinking that a C++ compiler will compile C and that C is a largely a subset of C++.

> I also didn't say you are spreading lies maliciously

My objection wasn't that you imputed malice; it was that you went straight to "spreading lies" instead of expressing uncertainty about what I meant. And you were wrong about what I meant.

> You can spread them unknowingly via mis-communication.

Which, since you were wrong about what I meant, is what you did when you said I was "spreading lies".

According to Distrowatch, out of the top twelve (12) distros, all but #8--Arch--use Python2.

The other 11 in order of popularity are #1 Mint, #2 Ubuntu, #3 Debian, #4 Mageia, #5 Fedora, #6 openSUSE, #7 elementary OS, #9 Zorin OS, #10 Puppy Linux, #11 PCLinuxOS, and #12 CentOS.

Most Linux distros use Python 2.

That's not quite a complete picture. Those distros include Python 2 as the default "python" executable, but many include Python 3 as python3, and even more have standard python3 packages that just aren't installed by default.

At work, I am writing tools in Python 2.6.6 specifically because the latest version of RHEL comes with only that, and I cannot get aftermarket versions of tools onto our servers. Is that the fault of Python? No, but I'm sure I'm not the only person working at a stuffy organization with crappy open source policy.

So do I (in some cases even stuck on Python 2.4) [RHEL 5]. But at the same time (re: Python 2.6) I never really thought "oh I really need the latest 3.4 or my project will fail". It doesn't offer dramatic speed improvement, concurrency, some nice built-in web framework or anything.

I would take 3.4 if someone else spent the time testing and validating my code against but I just don't have the time to invest because I just don't see an upside to it at the moment.

Why? Languages are tools used for communications, if there is no one to talk to there is little point in learning a language.

English is a much better universal language than esperanto ever will be for this very reason.

Prior to the release of 3.2 (Feb. 2011, 2.5 years after the initial 3.0), that was clearly reasonable advice. The io subsystem in 3.0 was quite slow, making it uncompetitive with 2.6, and while 3.1 fixed that, there were still too many missing libraries (and similar issues).

I wonder what would have happened if the software that was called 3.0 had been released as "Python 3 Preview Release" or something. I guess the thinking was that would have held people back even more from trying it/porting stuff, but maybe scaling back (end user) expectations for those first couple of versions would have been the better path.

> Shouldn't it be the role of educators to promote the latest version out there

I think the main role of authors of books on programming is to help their readers to become more effective in solving their programming tasks. So they do, if they're wise and honest.

> In every Python book I read they were recommending me to use Python 2.7 instead of 3.0.

Well, for one thing, Python 2.7 is a newer release than Python 3.0 (2.7 was released after 3.1.)

However, while there may have been good reasons to choose 2.7 over 3.0 (or even 3.1), there aren't nearly as many reasons to choose 2.7 over 3.4.

> Python is glue code.

Um, no. Major applications are written in Python. It looks to me like the problem is not Python but your perception of it.

From personal observation I'd say that for every person writing major applications in python you have at least 20 using it for glue code. And having written a major application in python, I'm not really convinced it's a good language for it.

> From personal observation

Which is not a good metric. Have there been any actual surveys or studies of Python programmers to see what the distribution is?

> having written a major application in python, I'm not really convinced it's a good language for it.

Out of curiosity, what was the major application?

>Which is not a good metric. Have there been any actual surveys or studies of Python programmers to see what the distribution is?

So where are your metrics?

http://en.wikipedia.org/wiki/List_of_Python_software

This doesn't show how many programmers work on "glue code" vs. "major applications" (which is why I asked if anyone has data on that), but it certainly shows that there is a lot of Python code out there that is not just "glue code". Bear in mind that it's not just the particular packages listed on that page, since many of them are frameworks; there are also plenty of "major applications" written in those frameworks.

(I am counting major websites using a web framework, major numerical applications using NumPy or SciPy, etc., as "major applications", btw, not "glue code". I suspect on re-reading this subthread that the poster I was originally responding to might differ with me on that point, but application logic is not "glue code" in my view.)

>but it certainly shows that there is a lot of Python code out there that is not just "glue code"

Well, of course, this list would have only NON glue code projects!

Glue code stuff is used internally, in companies etc. It's not (usually) something that you put on GitHub or open source.

> Well, of course, this list would have only NON glue code projects!

And libraries and frameworks that support non glue code projects. Where is the list of libraries that are glued together by all this Python glue code?

> Glue code stuff is used internally, in companies etc. It's not (usually) something that you put on GitHub or open source.

People don't put their Django websites or their internal SciPy models on github either, so I don't think this means much either way.

Nope no metrics, I doubt very much they exist. But if I can pile on a second personal observation, a significant proportion of people programming python aren't python programmers. They'er engineers, artists, scientists, analysts and statisticians whom are using python to do their job. So even if you somehow did manage to survey a statistically significant number of python programmers, you'd still be missing a large swath of the python community.

As to the application, it was a largely in house tool for an engineering and company I used to work for.

> even if you somehow did manage to survey a statistically significant number of python programmers, you'd still be missing a large swath of the python community.

Depends on how the survey is done. If those engineers, artists, scientists, etc. are using Python, they're using Python, and there are ways to survey that. For one thing, you could look for users of the major Python frameworks listed in the Wikipedia article I linked to elsewhere in this subthread, like NumPy or SciPy.

If you want to claim that, for example, a scientist using SciPy isn't a real "python programmer" because he is only writing "glue code", I've already answered that in another subthread. Application logic is not "glue code". The scientist's application logic is in Python, so he's programming in Python, even if his job title doesn't say "Python programmer".

>Python is glue code. You write a small piece of Python to tie together external libraries.

Glue code is only one of the things that Python can be and is used for. Python is used for small, medium and large [2] applications as well.

Do all of the following look like glue code?

Recent marketing brochure from the PSF (Python Software Foundation) - (it's a PDF):

http://brochure.getpython.info/media/releases/psf-python-bro...

Python success stories:

https://www.python.org/about/success/

Google's web front-end (many of their URLs even end in .py)), Dropbox clients (wxPython), YouTube [3], Disqus are some apps / sites written in Python.

[1] See the paragraphs about YouTube near the end of this post (by me, but much before this current thread):

http://jugad2.blogspot.in/2013/03/youtube-dl-yourube-downloa...

[2], [3] The PyCon talk below is by one of the original engineers at YouTube.

https://us.pycon.org/2012/schedule/presentation/128/

The Wikipedia article below says YouTube is one of the largest web sites in the world. A lot of YouTube is written in Python.

http://en.wikipedia.org/wiki/YouTube

Also: Disqus, written partly in Python, mentioned on the High Scalability site:

http://highscalability.com/blog/2014/4/28/how-disqus-went-re...

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

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

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

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

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

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.

This just seems like an ad hominem attack. Just because the author works at Microsoft does not mean that he is speaking for Microsoft or talking on their behalf.

It's not just an ad hominem attack. I counter a number of his claims. The author provides NO evidence for any of the rubbish he's talking about.

There are barely any users of Python 3. New versions of Python 3 are mostly only picked up by other Python 3 users. Python 2 is growing faster in downloads than Python 3 is by PyPI numbers.

That is a problem.

Do you have a link for these numbers?

I tweeted about this a while ago, I don't have the numbers at hand. Unfortunately to get those numbers you need to nudge the pypi maintainer as the data dump is too large to keep in a database without wasting money. As such if I would want to run the report again I would need to import multi gigabytes of logs again which takes time.

I'll take your word for it then ^_^

Currently python 3 packages ported are at about 10.9% according to pypi. This isn't including separate source downloads, so I guess the number would be higher by a few percentage points.

There was a post by Alex Gaynor in January [0] about downloads for python 3 being at 2.4%. But that was before python 3.4 came out, and before some major libraries were finally ported like Twisted. Twisted not being ported was one of the main blockers for python 3 in the last Ubuntu release [1]. Once more distros improve their python 3 support, things will get exponentially better for python 3. Continuous integration servers inflate numbers because they re-download things, and there is the CDN which makes all these numbers highly inaccurate.

Lots of things have been ported since January, like pycurl, pyOpenSSL, bugzilla [2], etc. Because of the big pushes by Debian, Ubuntu, Fedora, Mozilla, and Gnome [3] communities amongst many others. Things have improved greatly in a few months.

Distros, and apps like Sublime Text 3 moving to python 3, along with some of the major missing pieces will help uptake significantly. Almost all packages in Fedora come with python 3 packages now. But the key to increasing python 3 adoption is Apple, and python 3 on OS X. Many of the python packages that come with OS X are now ported to python 3 (Twisted, cups, pyobjc, etc) ... but who knows what they have planned? I guess we'll see June-ish.

[0] http://alexgaynor.net/2014/jan/03/pypi-download-statistics/ [1] https://wiki.ubuntu.com/Python/FoundationsTPythonVersions [2] https://fedorahosted.org/python-bugzilla/ [3] https://wiki.gnome.org/action/show//Initiatives/GnomeGoals/P...

Only a subset of twisted is ported. For example, twisted trial runner is not ported, so you can't run tests using twisted test runner in Python 3.

Yeah. Here's the issue for it "Port twisted.trial.runner to Python 3" twisted.trial https://twistedmatrix.com/trac/ticket/5965

Please make a new extension `py3` and run both on the same VM. I know the str|unicode|buf issue is not easy, but you guys have lots of smart people.

Not possible due to how the interpreter and extension interface is structured.

I have been racking my brain on how to remove all of the externs from the Python 2.7 VM, I think it just needs a big refactor to have a context object like Lua.

Poster mentions msft dropping support for ironpython (there were other languages too - ironruby, for instance) -- where "drop support" was to open source them.

Just last year, msft gave $100k to the ipython project -

http://ipython.org/microsoft-donation-2013.html

It feels like the original commentor has a beef against msft to read company action into what is an individuals blog entry...

If they open source and cease to support, I doubt anyone in the Microsoft ecosystem would pick it up.

Most of the article (on medium) is an unsubstantiated rant. Granted that the move from 2 to 3 has been much slower than what you see for major revisions but it was a _big_ overhaul. In hindsight, maybe the developers could have done something different. But using phrases like "Python 3 is killing Python" & "you might as well port to ruby" is absolutely false & misleading.

It killed it for me. (So not absolutely misleading)

I'm afraid that still won't kill Python.

The OP did not say it would "kill" Python, just that it would cripple it. Personally with bloomberg bringing out a Python2.7 financial module first, no 3.x support, the entire financial world is now also poised to stay on 2.7. That's a classic example: bloomberg only published this Python binding 6 months ago! no Python 3.0 for them.

I was referring to the title : "Python 3 is killing Python"

Anyway, it's a well known fact that 2to3 switch has tremendous inertia. Space, Medical, Finance are few of the applications where often old is gold (tried & trusted). What bloomberg did was logical, no surprise there. That decision adds little value to how Python 3 is impacting the growth of Python.

It is tremendously detrimental when a deprecated technology has all the inertia, because it is a dead end thanks to the Python bosses refusing to move it forward. Every new package for 2.7 (and no this is not old gold - this is a brand new library for access to Bloomberg's massive and uber-valuable database), every new package that invites more people into a dead end, encourages those people to look much wider (beyond Python) when needing to upgrade. Python 3 may be growing in absolute terms, but in relative terms it's a absolute dog compared with its competitors, including Python 2. Python 3 in its current form is doing everybody a huge disservice.

> deprecated technology

Are you calling Python 2 deprecated? Could you provide a reference?

> not old gold - this is a brand new library for access to Bloomberg's massive

You clearly missed the meaning of 'old is gold' here. It's the 2.x Python code I'm referring to.

I see what you mean now on old is gold and yes I agree. Corporations love old proven tech for all the obvious reasons. Not officially deprecated but that's just semantics. The underlying point is that the Python leaders are trying to turn a superhighway into a dead end, and force a long and winding detour for most people onto another highway which is only marginally better. Being forced to take that detour simply encourages the exploration of other alternatives as well. By the way if they really had balls, they would've killed Python 2.7 in 18 months. Not 5 years. Force the choice. Clearly they themselves are not confident enough in 3.

"I doubt the lazy people who haven't moved to python3 will ever do a decent port of python 2."

That is a ridiculous statement. So everything like most of the *nix OS and a dozen other super popular products that require python 2.6 or 2.7 are lazy too?

> I doubt the lazy people who haven't moved to python3 will ever do a decent port of python 2.

These lazy people probably have a day job where they have to do something productive instead of wanking around with "fun" language features.

Not sure how accurate is this source but it shows:

PHP 82.0% ASP.NET 17.5% Java 2.7% ColdFusion0.8% Perl 0.6% Ruby 0.5% Python 0.2% JavaScript 0.1%

http://w3techs.com/technologies/overview/programming_languag...

I really doubt there is more ASP.NET code deployed than Java,i'm pretty they are at least equivalent.

And Coldfusion over Python and Ruby? i dont think so.

Not very accurate. PHP is basically the only language which advertises itself both in file extensions (less and less common as people started using rewrites) and HTTP headers (unless disabled of course).

Reading the methodology behind that survey, I'm very skeptical. Basically, the reason that PHP and ASP score so high is that they're the only ones that explicitly advertise their presence via file extensions.

Reminds me of Ruby, IMHO the version jump from 1.8.7 to 1.9.* killed it. Different scoping rules made porting a non-trivial task, many packages have never been ported to 1.9 and one of the early 1.9.* major releases was extremely buggy...

Nowadays hardly anybody seems to use Ruby for new projects...

I can't tell if this is a poor attempt at sarcasm, but if not:

Do you have evidence to back up the claim that Ruby isn't being used for new projects? Even assuming HN is a skewed environment, I see enough Ruby projects popping up here to make that seem unlikely.

Yes, not sure how much evidence you need. I mean just look at the Tiobe Index:

http://www.tiobe.com/content/paperinfo/tpci/images/history_R...

1.9 was initially released 2007, 1.9.1 was released in 2009... Not sure if you remember it, but one of the early 1.9 releases was reeeeally buggy.

Quite on the contrary. 1.9-compat was very quickly expected of all libs and all important core libs run better on >1.9.

1.9 was the cleanup release after the language became popular and very necessary.

Also, everything before 1.9.2 was considered a preview release.

> Quite on the contrary. 1.9-compat was very quickly expected of all libs and all important core libs run better on >1.9.

That's quite some historical revisionism -- there was quite a while when quite a lot of libraries weren't running on 1.9. It wasn't as bad as with Python, probably because Ruby wasn't popular for as long as Python was, so there weren't as many big libraries that were hard to update. But it was a huge deal.

> 1.9 was the cleanup release after the language became popular and very necessary.

It was necessary for much the same kind of reasons (and, sometimes, the exact same specific reasons) as Python 3 -- particularly, the string encoding problem.

> That's quite some historical revisionism

I concur. The _expectancy_ that libraries should be updated was there pretty quickly. New libraries were generally created with both versions in mind. It was a huge porting effort, especially with 1.9.0 being very buggy, but there was a general sense in the community that you need to port or die.

At least the whole Google Appengine Ruby suite never worked on 1.9. Also JRuby took some time to be 100% 1.9 compatible.

We're at Ruby 2.1.x and every single gem I used in the past six months has been ported to it. I use Ruby only for Rails so I might be seeing a small environment, but it's 96 gems in the project I have in my editor right now. There are still many new projects in Ruby. I probably make half of my income with them.

> We're at Ruby 2.1.x and every single gem I used in the past six months has been ported to it.

Yeah, but 2.x didn't have major breaking changes. The big breaking change from 1.8.x that parallels the Python 2->3 change was 1.9, which has been out for two years longer than Python 3.

Reply on news.ycombinator.com