Hacker News Reader

Comment by ak217 | Hacker News Reader

> another year has gone by without considerable progress towards adoption of Python 3

What planet does the author live on?

If you mean "adoption of Python 3" in the sense of new Python programmers choosing 3 over 2, then yes, there has been progress towards learning Python 3. It's pushed in all of the online "beginning Python" guides I've looked at as well. From everything I've read about it, learning 3 is the way to go, since if you learn 3 you can always code in 2 if necessary. When the time comes that you'll need to know 3, you'll already know it.

If you mean adoption by businesses and entities using it in their infrastructure, then no, the author is correct: We're not seeing much progress there.

The real world.

That's the same real world where I routinely type "mkvirtualenv …", install a bunch of things and don't notice that I've been using Python 3 until the first time I toss a print statement in for debugging?

Which virtualenv's, regrettably, depend on OS-level packages. so when you go to deploy your app to production, you find you installed some system dependency long ago and promptly forgot about it. The real world is messy.

I'm not arguing there aren't upgrading pains, but --no-site-packages has be on by default in virtualenv for over three years (https://virtualenv.pypa.io/en/latest/changes.html#id31). There are certainly issues when it comes to compatibility between the languages, but I'm not sure that's one of them any more.

I've actually done this for years in the real-world. Yes, you can make mistakes. No, it's not a particularly hard problem to avoid and, as jonafato noted, --no-site-packages has been the default for awhile and I had it enabled by default for many years before then.

If this is a frequent challenge, it sounds like there's some technical debt to pay down elsewhere in your testing/deployment practice because it really doesn't need to be that hard.

I could be doing something wrong; I'm open to the possibility. And yet...

`psycopg2` is a pip package that won't install without system dependencies. Yes, I use Ansible and the system dependencies are managed. But, out of the box, on a clean system, `pip install psycopg2` doesn't just work.

The approach I use is to have the non-python dependencies managed externally – i.e. use APT/YUM for the postgres, mysql, redis, memcache etc. C libraries since those are very stable on a normal distribution – so a simple `pip install` will work as a non-privileged user inside a virtualenv.

Reply on news.ycombinator.com