Same here.

Haven't had a single Unicode bug in production since we switched to Python 3. Also, chained exceptions (extremely valuable in walled-off production environment).

Type annotations actually work and have prevented a number of bugs.

The asyncio syntax is really nice with Tornado (don't use aiohtto, use Tornado! it's much more mature)

Python 3 doesn't remove unicode issues, although granted you probably run into fewer issues when defaulting to unicode over a bytestring.

Python 3 doesn't remove all unicode issues, it's not magic. But the pain is 95% gone compared with Python 2. I write Python for a living, and my life has been a lot better since we switched.

Because unicode is default and the byte-type is single-byte adressable (rather than 1 character in <encoding>) it makes it more straightforward. It's not perfect, but it helps a lot.

It doesn't? I've ran into UnicodeDecodeError exceptions literally every time I've had to deal with external input in Python 2. It was a nightmare, and it made me hate Python.

With Python 3, that simply has never happened to me. Never.

I don't know why. I don't know what the change, what the secret sauce was. And what's even better: I don't have to care. Python now simply works for me.

So yes, Python did remove Unicode issues.

I'm slightly moving backwards. Previously I just make Python 3 scripts with 0% retrocompatibility because I thought that Python 3 was going to happen soon and it was futile to try to resist. Now that my programs and scripts are getting used more frequently at work and outside of work I'm making more Python 2-3 compatible code because often people just try to use python myscript.py (that might just call any interpreter), or they use myscript.py in an development environment that only uses Python 2.

It's a bit sad to not be able to use some things that I really love about Python 3 but it makes me happier to see other people enjoying my work, so I'm going to bear with it for now.

The only time we're writing new Python 2.7 code is when we're working with Twisted (and they are vigorously migrating to Python 3). All other new code is Python 3.5 based and we're not looking back at all.

Using asyncio has been a delight for a lot of the small, quick web services we need to write (though not a replacement for Twisted). Looking forward to seeing the asyncio infrastructure grow.

Same at my place, 2.x is banned for all purposes.

Ansible only works with 2.x, so that is perhaps the only exception I would make... (if you are an ansible shop).

But ansible scripts tend to be like 5 lines, so it is not the same as the scale you would write a webapp or something in Python3...

For Ansible, it's important to differentiate between the master and client side code.

Client side code has to run on everything starting with CentOS 6, so they have to stick with Python 2 for a long time.

For the Ansible master (which runs on the management machine), Python 3 porting work is already underway.

We're a Python shop but all of our Ansible work is just YAML. Ansible is a program more than a library so it's almost irrelevant what version of Python they use. Now, of course it's highly annoying to have to bootstrap python2 on Ubuntu Xenial but that's really not relevant to what version of Python a group uses for regular development.

We use Python 3.5 and are VERY happy about it.

Came here to say this. I've default to Python 3 for all new projects (our new stuff is primarily on Ubuntu 16.04 anyway), but we use AWS Lambda a lot and it's still stuck at 2.7 for now.

They're also only Node 4.3.2. It seems that they need quite a while to test new versions, or they have little man power and are constrained to keep working with what they know it worked.