
The lack of a case against Python 3 - ingve
http://blog.lerner.co.il/case-python-3/
======
lorenzfx
> But again, the population that will be affected is the 10% who deal with
> Unicode.

I doubt that only 10% of people are dealing with unicode. Rough estimate 10%
of the world speak English as a first language and almost all other languages
are written with (at least some) non-ascii characters.

In my experience (I'm from the 90% part of the world), people new to
programming and python stumble really early into some (to them) hard to debug
(UnicodeDecodeError: ... can't decode byte) errors in python 2. Then it's time
to explain the whole strings are not bytes, unicode, encoding and so on thing.
In python 3 that's also needed, perhaps even earlier, but bugs are much easier
to fix and programs fail on the first run, not when you finally enter some
non-ascii characters.

In my mind, python 3 clearly is superior to python 2, and would be even if
nothing but the unicode support changed.

~~~
JimDabell
> Rough estimate 10% of the world speak English as a first language

ASCII isn't even good enough for that 10% – British people need £, which isn't
in ASCII – not to mention things like em dashes, en dashes, and curly
quotation marks that word processors tend to add.

~~~
guan
Kids these days also use emoji.

~~~
yummyfajitas
Also unicode.

[http://unicode.org/emoji/charts/full-emoji-
list.html](http://unicode.org/emoji/charts/full-emoji-list.html)

------
gnud
This idea that some developers don't need to deal with unicode, really needs
to die.

If you're creating a web app and don't support unicode input, you're doing it
wrong. You probably can't accurately store the names of your customers, for
starters.

~~~
reuven
OP here. I teach Python to Fortune 100 companies, more or less every day.

You're totally right that people who deal with outside-world data need
Unicode. Anything that deals with users _MUST_ deal with Unicode.

But a huge proportion of the people I work with -- in Israel, China, and
Europe -- couldn't care less about Unicode. That's because they're processing
logfiles, dealing with test automation and system administration. For them,
Unicode is important a very small proportion of the time.

So I stand by my assertion that a small proportion of developers need to worry
about Unicode. But I also agree with you that Unicode is absolutely crucial in
the modern world, and that a language lacking good Unicode support isn't going
to get very far.

~~~
orf
> That's because they're processing logfiles, dealing with test automation and
> system administration ... So I stand by my assertion that a small proportion
> of developers need to worry about Unicode.

You come to this conclusion based on your dealings with a small subset of
developers within a small subset of companies?

I think many other developers in the fortune 500 companies outside of the
subset you deal with would laugh at that conclusion, then go back to
developing apps that deal with people/locales all over the world.

~~~
falcolas
This also describes my entire team. And the team before that. There are at
least as many developers out there who don't write user facing code as those
who do.

When I do run across Unicode, it's just a matter of passing it through, which
is usually pretty easy to do.

------
elnygren
People still stuck in python2 and arguing that python2 is better than python3
is weird.

I get it, more features does not mean better and newer does not mean better
but seriously, just do the jump to python3. It's not that much work and the
language is much nicer to work with.

I've built a library with python2/3 support and do most of my work in python3.
Maybe my web dev background biases me somehow, but I can't remember the last
time I had problems with a major library not supporting python3.

To me this seems more like tradition/age/generation -related. Those who
started back in python1/2 are the ones with problems moving to python3, while
young people who started with python 3.x are already running 3.5/3.6.

ps. like the author said, there will always be large corporations stuck in
very old techs - that doesn't mean the rest of the world too has to use Cobol
or MUMPS.

~~~
geocar
> but seriously, just do the jump to python3.

Or jump to another language.

Here's my problem: I don't program unless I get paid, and I simply cannot sell
this crazy idea: "hey, you know all that software you paid me to write? how
about you pay me again so you can have it in python3?"

It seems like if I want my programs to run for more than ten years I shouldn't
be using Python.

~~~
oblio
IMO that's the wrong approach. The correct one would be: "Hey, you know all
the software you want to pay me to write? It will be in Python 3 now".

~~~
guitarbill
I consider Python 3 a huge benefit for a similar reason: I can avoid or charge
$$$ for people still using 2.6 (e.g. on ancient RHEL). There's always
somebody. 2.6 is pretty sucky, not to mention unsupported by the PSF.

If you support 2.7, some "clever" manager or client will say that 2.6 support
surely isn't so unreasonable. It is. 2.7 is legacy only now IMO.

~~~
lima
I'm happily using and deploying Python 3.6 on CentOS 6 using pyenv. You don't
have to use the system Python unless there's a policy requiring you to do so.

~~~
guitarbill
I agree, and EPEL works fine on RHEL, too. But it wouldn't be _enterprise_
without some BS rules. Hence why compatibility "issues" are such a blessing
for detecting enterprise BS early on.

~~~
lima
You can get a more recent Python from Software Collections, too:

[https://www.softwarecollections.org/en/scls/?search=python](https://www.softwarecollections.org/en/scls/?search=python)

Up to Python 3.5 and 3.6 will probably follow shortly after release.

This is blessed and QA'd by Red Hat themselves, so it's as good as it gets.

"My distro only has Python 2" has to be one of the worst excuses not to use
Python 3 :-)

Obvious exception are systems tools (did you know that Ansible modules have to
compatible with Python 2.4 since that's what CentOS 5 uses?). But those are
the absolute minority.

------
cesarb
The biggest problem with Unicode in Python2 was not the
UnicodeDecodeError/UnicodeEncodeError, it was the _latent_
UnicodeDecodeError/UnicodeEncodeError. As in, you had some code which works
perfectly fine, both in your machine and in production, until someone
somewhere types a word with a ç character and your code blows up with one of
those two exceptions.

With Python3, the same code will blow up early, even if there was no non-ASCII
character for that string in your test set, and will get fixed before going
into production.

~~~
fb03
That was the main reason I migrated: processing everything internally in
Unicode and then encoding/decoding as needed for the outside world creates a
well defined 'place-where-unicode-shit-might-bork' border in your project that
allows you to not only detect unicode errors earlier, as you stated, but also
keep tabs on this 'border'.... eventually you don't even have unicodeerrors in
your codebase anymore, because in 3.x this pattern emerges in your head and
imho it's a really good thing, it is making your think properly how your code
interacts with other entities.

~~~
dom0
FTR I can't remember ever seeing a UnicodeError in Python 3 that was caused by
an ill-formed program. I only saw it when someone put binary shit somewhere
were only text should be (eg. that flat text file with the page title should
contain text, not an .exe)

Also the distinction between binary and text is the _only_ sane way to handle
it. Everything else is simply ill-formed.

------
lucasnemeth
I find surreal how much people underestimate how big is the population that
deals with those unicodeerrors. It's SO MANY FUCKING LANGUAGES AND SO MANY
PEOPLE. The majority of the world population writes using non-ASCII
characters!

It's a HUGE problem in Python 2. Python 3 was needed. If you don't think the
Unicode change was needed and you actually work with texts in any form, you
should also stop developing "for web scale" before fixing this. Because you're
actually focusing on a small percentage of the world population on your
software.

For me Zed's argument sounds like "This is America, speak English". Specially
with his quotes around "international".

~~~
softwarelimits
Üክጎርöዕቿ የዪöጌረቿጠነ ልዪቿ öሀቿዪዪäፕቿዕ.

~~~
memracom
Unicode problems are overrated

------
belvoran
Yea, use Python2, don't use Unicode, but please add information to a
registration form like: _" due to our programmers' limitations please don't
enter your first name or last name as your write it, use only ASCII
characters, otherwise our servers may blow up"_.

PS) This is what I had to work on last year. Happy US programmers who know
nothing except English. And suddenly the software blew up, just because a
client wanted to enter his name.

------
tronje
There's also this article [0], which sort of tears Zed's article apart bit by
bit. It's honestly a fun read because of the aggressive tone (which I find
deserved), and it's also informative.

edit: there was a HN discussion about it as well. [1]

[0] [https://eev.ee/blog/2016/11/23/a-rebuttal-for-
python-3/](https://eev.ee/blog/2016/11/23/a-rebuttal-for-python-3/)

[1]
[https://news.ycombinator.com/item?id=13027481](https://news.ycombinator.com/item?id=13027481)

------
Sir_Cmpwn
I don't have a problem with Python 3's unicode support, and I don't really
understand why people do. I think it works fine, you just want to think of b''
as byte arrays instead of strings. If you're ever carrying a bytes around and
passing it into string handling functions, you're Doing It Wrong. Honestly, I
can't find anything wrong with Python 3's Unicode support. It's great.

~~~
minus7
Exactly. Its clear distinction between (unicode) strings and (binary) data is
Python 3's biggest plus, imho. No more randomly popping up errors because
something is trying to handle the binary data in your str as string; instead
you'll get a nice type error. I don't understand how people do _not_ find that
terribly annoying with Python 2. (seriously, tell me)

~~~
dom0
Gut feeling: there is a large intersection between the "Python 3 Unicode
sucks" and "Every operating system ought to handle only bytes and never think
of encoding, and file names and paths are just bytes". I have words for the
latter attitude, but they're not HN-compatible.

------
SeanDav
I have nothing against Python 3, but right now Python 2.7 is more than good
enough for all my current requirements, and is used by every client I work
with that uses Python.

At some point that might start applying to Python 3, in which case I will use
Python 3. In the meantime I stay out of religious programming wars and use the
best tool for the job. For me, right now, that is Python 2.7.

~~~
BerislavLopac
> Python 2.7 is more than good enough for all my current requirements

> use the best tool for the job. For me, right now, that is Python 2.7.

Sorry, but these two statements seem at odd with each other. I absolutely
agree with the first principle, and I agree that in many cases 2.7 is more
than good enough; however, in nearly all cases I have encountered (and I have,
a lot!) Python 3 is notably better, which means that it is not "the best tool
for the job".

~~~
freehunter
Everyone has different needs. For your needs (for most people's needs), Py3 is
better. For his needs, Py2.7 is better. It's not hard to understand.

If everything he encounters, for example, is in 2.7, then that's probably the
best tool for the job. If I'm commuting to work in the morning, I want a nice
sedan with an automatic transmission and fuel injection because it's nice and
modern and easy to use. If I'm in rural Africa though, I probably want a truck
with a manual transmission and a carburetor. Sure it's outdated, but if I need
a mechanic to work on it or parts that will fit it, every other car on the
road there is just as outdated as mine.

~~~
BerislavLopac
> If everything he encounters, for example, is in 2.7, then that's probably
> the best tool for the job.

I disagree. Your example describes two completely different solutions to
different scenarios; but Python 3 is not a different solution, it's a subset.
It has everything that 2.7 has, only improved -- which means that for each
case that Py 2.7 can handle, Py 3 can handle it just as easily, or better.

My comment was simply about the phrase "the best tool for the job" \-- Python
2.7 is in many cases good enough, and there is no point in switching an
existing codebase if it means much more work than it brings benefits. However,
when starting something new, with the goal of using "the best tool for the
job", Python 3 is -- in my experience at least -- the clear winner.

------
burnbabyburn
serious question: why I see really almost no complains in other languages when
they introduce breaking changes? is the migration handled differently or the
communities are less vocal?

~~~
ubernostrum
Serious answer (seriously): because Python 3 didn't break enough stuff.

For all the complaints, Python 3 was _incredibly conservative_ about making
changes that would completely break existing code. String handling was
basically _the_ big shift, and if you were writing good code to begin with
wasn't super hard for most problem domains to adjust to. Clearing up some
cruft in the way the standard library was organized wasn't hard to deal with
either. And there wasn't a lot of new syntax in 3.0/3.1 and quite a bit of it
was backported into 2.6/2.7 to make the transition easier.

And then there was a bit of a moratorium on language changes in 3.x to give
people time to catch up from their 2.x codebases.

The result of which is a lot of people who didn't think Python 3 was a big
enough deal to be worth putting in the effort to migrate, when the 3.x series
started releasing. And now many of them are finally noticing all the cool
stuff that's in 3.x now (3.6 is about to release), and noticing that their
favorite tools and libraries have switched from "we support 2 and 3" to "we're
dropping support for 2", and realizing they didn't take advantage of all the
time they had to port stuff, and are angry and feeling left out and trying to
find complaints to level at Python 3 in the hope that enough people will agree
and just magically end it, port all the new features back to Python 2, and let
them keep going as-is.

~~~
guitarbill
> Serious answer (seriously): because Python 3 didn't break enough stuff.

I could also be because there was another choice (which is what you also
said). Ruby 1.8 -> 1.9 was annoying, but you weren't going to keep using 1.8
given e.g. the speed improvements of 1.9. (Also, who adds breaking changes in
minor version numbers?)

There's a great talk about changing the culture around Python3 at Facebook[0],
I highly recommend it. Technically, it isn't so hard. Culturally, it can be
pretty hard. Calling Python2 "Legacy Python" helped at my $work. My boss
agreed that continuing 2.x development wasn't a good investment for the
future, given the minor technical challanges involved with moving over a few
years.

[0]
[https://www.youtube.com/watch?v=nRtp9NgtXiA](https://www.youtube.com/watch?v=nRtp9NgtXiA)

------
forgottenacc57
The main reason that Python Unicode is hard is because of the disastrously
confusingly named "encode" and "decode". It's a constant question which
direction you are going - encoding or decoding, huh, what?

Python 3 Unicode would be MUCH easier if encoding/decoding was more intuitive,
memorable and obvious.

Still an unfixed problem. Not even an acknowledged problem.

~~~
icebraining
How would you design the API?

~~~
baq
I'd copy directly from Rust.

~~~
icebraining
Say I get a file and the name of the encoding it's in (like an XML file with a
declaration), how I decode it in Rust?

------
fb03
I was a die-hard 2.x Pythonista, and as Python 3 started to reach 3.[4/5]
releases, in my view it started to get really good in terms of new (and
actually useful, not just bloated) features. I for instance love the way you
can properly type everything, and that equates to proper interfacing,
expectancy between object interactions and also (ofc!), better and smarter
IDEs.

Also, at the 3.5 release, most "big" libraries and frameworks were already
supporting Py3.x in a stable manner, so more and more the point about being at
2.x "because I have this huge library support" got fragile in my head, and I
knew what that meant: "Someday, I will actually have to migrate!"

I started getting worried that the 2.x ways were too entrenched in me and that
I'd never be able to migrate, that my Python (2.x) skills would become
something as forgotten as my former self (childhood) Turbo Pascal antics and
etc. Nonsense!

Here's what happened: I was asked to work on the backend of a new website that
was aiming for a fully "portable" (desktop, mobile, and whatever comes next)
experience. They wanted me to write an API for it, and I started studying what
framework I could use that was simple enough for an API (flask!) and for sane
backend storage definition (sqlalchemy!)

\- Flask on 3.x -> The more I searched about flask on 3.x, the more I found
how it was really stable and production-ready. Also, using 3.x would be really
nice on the whole Unicode thing, as I would not be able to make the same
string/bytestring mixing assumptions I used to do so carelessly in 2.x (until
something blew up...) I would actually have to enforce and handle proper
Unicode throughout the api.

\- SQLAlchemy on 3.x -> Really, the same. Production-ready, used throughout.

These two convinced me to try to get the initial API study on 3.x, and oh boy,
besides stumbling here and there with some changed syntax (mostly, simple
print()'s during early stages), migrating to 3.x went real smooth!

As I advanced in my 3.x studies, I started to see benefits in typing
everything properly, specially between layers/borders, and it meant less
typing and more intelligent autocomplete for my pycharm.

Seriously, If you find yourself struggling or anxious about migrating to 3.x,
just find yourself a new project and start doing it on 3.x in the most non-
pretentious manner. You'll find yourself just as 'at home' as you felt in 2.x,
but you'll still feel something changed for the better...you won't feel
strange more than 3 days I promise you :DD

------
TeeWEE
I HATE python 2

    
    
        "hello how are you {}'.format(name)
    

UnicodeDecodeError ARRRRGGGGH

~~~
jwilk
SyntaxError: EOL while scanning string literal

------
gravypod
My biggest issue is that Python 3, from an outsiders perspective, does not
look at all like it's about unicode. Python 3 could very well have been done
in a way that just fixed the back end implementation of python 2 (implement a
string as an extension of a list) and then most things would have probably
worked fine. Just handle all the unicode stuff in the back end and treat them
the same exact way as Python 2 treated strings.

That's not what happened and instead we had a huge change to one of the
fundamental data structures of any programming language and a lot of changes
that pretty much no one wanted.

Packages were moved, things were renamed, etc. These are not changes that
should be made. Make a fix, don't make me rewrite my code because someone else
said "Eh, I like this name better". It's useless to do so and helps no one.
There are now swaths of community-written documentation that are useless
because every package name in the post has changed for seemingly no reason.

The issue is simple: it could have been handled so much better.

------
softwarelimits
I would like to understand: what was the key mistake in the transistion to
Python 3 that generated this huge divide and this ultra-annoying situation for
the people that still have to use Python today?

What can be learned from that Python desaster to avoid such a catastrophy with
some other programming language?

I really would like to read some analysis about what went wrong.

Thank you very much for your attention!

~~~
dagw
Personally I think one big mistake was that it took literally years between
python 3.0 coming out and numpy and django having a release that supported
python 3. I remember python 3 coming out, being interested, looking at it for
just long enough to realize that numpy wasn't supported and then not looking
at it any more. Then I kind of lost interest in the intervening years and just
kept working with python 2 which ended up getting back ports of many python 3
features.

I think that if the teams had somehow managed to coordinate a more or less
simultaneous release then much of that early momentum wouldn't have been lost.

------
sambe
The big thing is not so much the changes that you need to make for Python 3,
but supporting both from the same code base. Combined with the fact that this
is often very necessary and will continue to be necessary for quite a while
(LTS distros on Python 2.6 or 2.7), people think "why not just use the
minimum?". If you have good support from things like six and good testing then
it's possible, but it certainly adds a development tax.

Python 3 has been adding more features (especially concurrency-related) that
don't seem to be getting back-ports, or at least the libraries that support
them in Python 2 lack the ergonomics of nice syntax sugar. Eventually there'll
be a tipping point of all major LTS releases on 3.x and enough carrots in
Python 3 that none of the little things will matter any more.

------
drej
Since we keep having these discussions every now and then, here's a link to
one of them from a few weeks ago:

[https://news.ycombinator.com/item?id=12930082](https://news.ycombinator.com/item?id=12930082)

------
brudgers
To me, the essay misses Shaw's point. One way to divide out the invested
positions of the Python community and see his position for what it is, is to
look back at when Shaw similarly pissed off the Ruby community (as distinct
from the time he pissed off the Ruby-on-Rails community).

This essay is among the most memorable pieces I have read on Hacker News:
[https://web.archive.org/web/20120821234313/http://learncodet...](https://web.archive.org/web/20120821234313/http://learncodethehardway.org/blog/AUG_19_2012.html)

~~~
minitech
What do you think his point is, then?

~~~
brudgers
Having read Shaw's recent essay [0]:

1\. Because the target audience of _Learn Python the Hardway_ is very new
beginners and the pedagogy is _programmed learning_ [1][2], Python 3 is a poor
choice for the target audience of _Learn Python the Hard Way_.

2\. Shaw is more concerned with the welfare of the book's intended audience
than adherence to the dictates of Python's leading figures.

3\. More subtly, that sales figures indicate a disconnect between the dictates
of Python's leading figures and the interests of his students.

From my outside position, it seems Shaw has a legitimate stake in his decision
and people like this essay's author have a stake that boils down to creating
drama.

[0]: [https://zedshaw.com/2016/11/24/the-end-of-coder-
influence/](https://zedshaw.com/2016/11/24/the-end-of-coder-influence/)

[1]:
[https://en.wikipedia.org/wiki/Programmed_learning](https://en.wikipedia.org/wiki/Programmed_learning)

[2]: [http://hanselminutes.com/407/learning-code-the-hard-way-
with...](http://hanselminutes.com/407/learning-code-the-hard-way-with-zed-
shaw)

~~~
minitech
A noble goal, but his Python 3 post is still nonsense [0].

[0]: [https://eev.ee/blog/2016/11/23/a-rebuttal-for-
python-3/](https://eev.ee/blog/2016/11/23/a-rebuttal-for-python-3/)

------
ralmidani
I've built two (soon to be commercialized) web apps in Django over roughly a
year. I don't bother to ensure Python 2 compatibility. I refuse to litter my
code with unneeded imports and make my code my code uglier/harder to
understand.

Maybe I have the luxury of not targeting enterprises with legacy codebases. I
genuinely feel sorry for people who have to go out of their way to solve
compatilibility problems rather than work on more interesting problems.

Edit: typo

------
heisenbit
For new projects Python 3 has to compete not against Python 2 but also against
other scripting languages, especially NodeJs.

~~~
jjawssd
No problem tho [https://magic.io/blog/asyncpg-1m-rows-from-postgres-to-
pytho...](https://magic.io/blog/asyncpg-1m-rows-from-postgres-to-python/)

------
alexchamberlain
I'm unconvinced by the argument that big shops won't migrate by 2020. There is
a statistic (which may be false and unproven, but I think is roughly correct)
that says all code gets rewritten every 3 years. ie if you make Python 3
available to new code now, then by 2020, your code will be rewritten in Python
3 by natural attrition. That being said, its of course not that simple.
However, the investment now in making core libraries compatible and deployed
for both languages is likely to be much cheaper than a mass switch when Python
2 gives up the ghost.

~~~
reuven
One of the companies where I teach just (in 2016) upgraded one of their core
systems to Python 2.7. That's after years in which it was written in Python
2.4. Yes, 2.4, the same version my great-grandparents ran back in the Old
Country.

So yes, things are rewritten. And things are upgraded. But at a glacier's
pace.

2020 is coming soon -- in about three years. There's no way that companies
will upgrade some of these systems to Python 3 during that time. Some things,
sure -- but there's a _lot_ of legacy code out there, and I don't see them
spending the time and money to upgrade something that already works.

~~~
scrollaway
Python 2.4 was, until fairly recently, still supported in a RHEL LTS.

Enterprise being stuck with old versions isn't new. But it's a radically
different world.

------
runjake
> But again, the population that will be affected is the 10% who deal with
> Unicode.

I bet a lot more than 10% of the user base uses emoji. And even more will.

------
kozak
As I said in another Python 3 HN thread, developers from cultures whose
languages can be fully satisfied with the Latin-1 charset (which is the
absolute majority of the developed world) just don't get how important and
essential it is to have a proper (pervasive and implicit) implementation of
Unicode at the language level.

~~~
bildung
_> (which is the absolute majority of the developed world)_

I'm a German writing web apps using Django, and I constantly got
UnicodeDecodeErrors when mingling with older browsers, uploads from Windows
users, copy-pasted content from word processors etc.

The problem isn't (only) whether Latin-1 has all the characters, it's what
encoding gets thrown at your software.

Python 3 was a blessing for handling user-provided input.

------
edblarney
If you can't handle Unicode fairly well, you can't make an app that is
international ... the world is a big place.

I run into unicode issues on almost every project.

------
vuanotinn
I can make a case against 3: it's even slower than 2.

~~~
pja
Yeah, but if you’re programming in Python then speed isn’t exactly high on
your language feature priority list is it?

~~~
dom0
Performance and choice of language has in most cases no correlation at all.

