[tutufan]

Of those, only the async I/O stuff seems compelling. But compelling it is, at least as used in Curio. It feels like this is still shaking out, with the standard library and Trio (?) alternatives, but it looks really cool.

[asdfgadsfgasfdg]

If you work with international users full unicode support is very compelling.

[loeg]

Why do your users care about symbols internal to your code?

[eyelidlessness]

They don't, they care about `str` being unicode and developers not having to do additional work to support unicode strings.

[flavio81]

Strings can be unicode in Python2, you start a unicode string with u".

Python2​ has full unicode support. While Python3 supports only unicode strings.

[eyelidlessness]

I was thinking through my response to this, and realized that I would just be repeating what I already said.

Is there any reason to require extra work to support unicode strings?

[asdfgadsfgasfdg]

I've come into large python2 projects which had been started with non-unicode strings (because the initial developers didn't think about it). At some point a user with non-English characters invariably signs up and then shortly complains. It has been significant work to (1) convert everything that should be converted to unicode (2) re-train the developers to use the unicode syntax.

[loeg]

Python 3 has, more or less, just renamed unicode() to str() and str() to bytes(). unicode() support was already complete in Python 2. The rename is not a user-facing feature.

[eyelidlessness]

String literals are unicode by default, which they were not before.

[JupiterMoon]

True. It is a nice thing for scientific code though. Often in a field α etc etc have a known meaning by convention and being able to write them as α rather than alpha can really make longer formulas more readable.

[soperj]

if you do open source development, your users are your testers and your future developers.