Hacker News new | past | comments | ask | show | jobs | submit login

Yeah, for the longest time everyone kept using library support as an excuse for sticking with 2. But at this point I think it's the exception that a decent Python library doesn't support 3, rather than the rule.

The only one that comes to mind for me is fabric, to be honest.

> But at this point I think it's the exception that a decent Python library doesn't support 3, rather than the rule.

Right now 187 of the top 200 packages on Pypi support Python 3. https://python3wos.appspot.com/

Infrastructure changes to PyPI made it hard to work out what the top packages are. http://py3readiness.org/ is another effort, which currently lists 345/360 packages as Python 3 compatible.

And of the 13 not migrated, 9 are Mozilla packages, so they're probably just waiting to write them all in Rust...

Those are internal tools at best so it won't matter that much for migration.

That list is of the top packages. If internal Mozilla tools are downloaded enough to become top 200, then either Mozilla is larger than I thought or Python is smaller than I thought.

Download counts -- which usually power "most popular" charts -- are extremely misleading, because usually every run of an automated CI system triggers a download.

Arguably that works better as an indicator, as you can see which packages are being actively developed with. But that's beside the point.

Are you suggesting that Mozilla's CI system runs so often as to artificially inflate the download numbers of their internal only packages to the top 200 Python packages? Because if so, then my point still stands. Either Mozilla is a lot bigger than I thought or the Python community is a lot smaller than I thought.

I also am of the belief that if any team would think to cache their dependencies, it would be the team behind a modern browser.

Keeping in mind it's been a few years (my last day at Mozilla was in mid-2015), and I was in the web dev org, not the browser...

The sheer number of platforms, variants, etc. of the browser and the number of test runs that need to happen are mind-blowing. So it's entirely within the realm of believability for me that the mozbase packages (which provide a lot of the foundation for all of that automated infrastructure) could hit the most-downloaded list. It's not that Mozilla is necessarily that much bigger than other big-name tech companies, it's just that Mozilla open-sources everything by default and puts most stuff on PyPI.

As an aside, though, I think people do tend to underestimate the scaling stuff Mozilla deals with. Once I got to give a conference lightning talk pointing out we could probably claim the highest-traffic Django deployment in the world, for example (the version check done by Firefox on startup, if you're curious, is or at least was a Django-backed service). Though I'm pretty sure Instagram has taken that title now; back in 2013 when we talked about that we "only" served on the order of a billion requests/day :)

Even things like MDN -- which is what I worked on in my time there -- presented interesting challenges. Building a wiki with the kinds of features technical writers need, that's still responsive and fast to build and render the pages post-edit and capable of handling the traffic of a top-300-ish (Alexa currently puts MDN at #107 worldwide) site, isn't entirely simple to do.

Why are internal tools showing up in the top 200 PyPI package list?

I've wondered that too. Are they automatically downloaded by a Firefox build script, perhaps?

I have always been interested in that cycle. We use 2 because NumPy supports it still. NumPy supports it because we use it. If a major library had dropped support earlier on, I am curious what would have happened.

I bet the same dynamic happened with Linux distributions including Python 2 as the default as well. Double whammy.

> The only one that comes to mind for me is fabric

Speaking of Fabric, does anyone know of any Python 3 projects similar to it? I've been using Fabric3 since the switch but it's not a 1:1 port. I'd consider dropping it in favor of something better if it exists.

The Fabric dev(s) seem to be developing a v2 branch with Python 3 support: https://github.com/fabric/fabric/tree/v2

But I'm not sure how far along it is yet.

Twisted port is a work in progress.

Ah, forgot about twisted. The new asyncio stuff probably changes a lot for how something like that could be implemented.

It's not just libraries that I use when developing.

Searching for code snippets and copy/pasting stackoverflow answers can easily take more time out of my days than library documentation. But it's so much slower when I have to rewrite something I found for python 3.

Yes, but during the long migration, it was no mere excuse.

Almost every time I tried to use a library, it was 2.7 only.

That situation has only changed recently, and with it people have moved on to 3. (Which sort of underscores that the library support was the main issue).

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