
Why I'm Making Python 2.8 - cpeterso
https://www.naftaliharris.com/blog/why-making-python-2.8/
======
lloeki
> _And the majority of Python code written does not run under any of the 3.x
> interpreters. This makes it harder for its users to be productive._

What a load of bollocks. For new projects this only matters if libraries
aren't ported, which they are for the most part. For old projects, either
you're in a situation where you can spend time porting your code to Python 3,
or you don't; but as TFA mentioned pep-404, the writing has been officially on
the wall ever since 2011 so at that point you have to admit you did choose to
incur tech debt and do nothing about it, so the claimed loss of productivity
is on you.

> _Unlike 2.7 code, Python 2.8 wouldn 't be able to guarantee exact 3.x
> compatibility, since there are some python scripts that will run under both
> Python 2.7 and Python 3.x but produce different output, and Python 2.8
> chooses the 2.7 behavior in these cases._

What a terrible, terrible situation. Now you'll have "python" code that will
neither run on 2.7 nor run compliantly on 3.x. As for the latter, please
explain how that will alleviate anything on the following point, since
behaviour at runtime will be subtly different:

> _adding these remaining Python 3 features would greatly simplify running
> code targeting Python 3, and allow people to use Python 2.8 to run a mix of
> Python 2 and 3 code._

I don't know what recourse the PSF has but maybe they should even go all in
and defend the "Python" name so as to prevent confusion and stop a potential
community fracture. Just call it anything else but "Python 2.8" is not Python.

~~~
susan_hall
I currently work for a client who has decided to shift away from PHP and
towards Python. They had a monolithic PHP app with perhaps 250,000 lines of
code. Now we are developing a series of Python apps in the microservices
style. We've decided to develop everything as Python 2.7. We are not looking
at Python 3.x. There are a few reasons. Some libraries that we want are in
Python 2.7. And Amazon only supports 2.7. And we are not wild about Python
3.x's attempt to imitate a classical object oriented style.

We would look very closely at a Python 2.8, if it existed.

~~~
vosper
If I was your client I'd be pissed that you decided to rewrite my code into a
legacy version of Python. Make no mistake: Python 3 is the future of Python.
There will be no version 2.8 and there is no going back to 2.7.

Also, I don't know what you mean by "Amazon only supports 2.7" because boto
(the main client for Python) has supported Python 3 for 2 years now. Perhaps
you mean Lambda?

~~~
hayd
+1. Also it's easy to write code that supports both, so if you really need
python 2 support right now (surely AWS Lambda python 3 is coming soon, you can
already use it unofficially) that's a much better option than being entrenched
in python 2 (mainly the string handling is the issue for buggy code that'll
run in 2 but not 3).

------
yladiz
As others have said, maybe this project fixes some actual problems and
backports some features from 3, but this isn't "Python". Beyond the fact that
Python is a trademark of the Python Software Foundation, Python is more than
the language, it's the community and the tools (as with every programming
language). So while there are some vocal people that really dislike Python 3
(either in part or wholly), my understanding is that with the planned phase
out of Python 2 and Python 2 only receiving bug fixes at this point, much of
the industry is transitioning to Python 3 (either currently doing so or
planning to) and so it seems relatively fruitless to attempt to build upon
Python 2. I personally think the effort put into this would be much better
spent making tooling around Python 2 to 3 transformations.

I also think it's pretty irresponsible of the author to call this Python 2.8,
because it may cause confusion to developers unfamiliar with the history and
come from a tutorial that is still in Python 2 (it does show up on the first
page of Google for me). It's also especially irresponsible and hubristic to
attempt to make a language that is seemingly compatible with both Python 2 and
3, because 1) I trust that if it was possible Guido and the other developers
would have made it, and 2) it can cause significant confusion when code
doesn't work when it hits an edge case, and then the whole tooling around it
can't be guaranteed to work. The last thing I'd want in my programming
language is unaccounted for ambiguity.

~~~
dismantlethesun
I don't know about that. It forked a Python compiler, and is fully
interoperable with 100% of Python 2 code, and much of Python 3 code. It's even
compatible with Python C extensions.

Why isn't it a valid Python compiler?

To me, the whole morass about trying to end-of-life Python 2 is a bit silly.
People have gotten emotional about the situation.

On one side, people like Zed Shaw are calling the Python maintainers 'evil'
and claiming conspiracy.

On the other side, people are calling companies using Python 2, 'lazy' and
claim they're a threat to the ecosystem.

Yet elsewhere, C is still being written in all of its various year-specific
formats, and people end up using 'old' versions simply because they join pre-
existing projects or need to totally interface with something that's written
in an 'old' version.

Python is an extablished language, it's likely that 10 years from now there
will still be Python 2 codebases going strong.

~~~
yladiz
There are some fair points, but unlike C or other languages that have "old"
versions, most of the newer versions are compatible with this old code (as in,
if you have some C89 code, you can compile it in the newest C compiler. Same
with Fortran). This isn't the case with Python 3 (there are breaking changes),
and I think it's fair that the Python core developers who, besides Guido,
probably work on this for free decide that it's time to end the older, non-
compatible version and give ample time for developers to move their codebases,
adding bug fixes and security fixes in the mean time until EOL is reached.

My biggest gripe with this project besides calling this Python is that it's
seemingly ambiguous with its code compatibility. I don't mind ambiguity in
programming languages, but generally the ambiguous cases are explicitly
defined with cases to explain them, and I don't see anything of that nature
here, only something that vaguely says that if there's something that works in
both the Python 2.7 way will be the default. Without defining those it's hard
to know what could happen in an edge case and this could introduce specific
bugs that don't present themselves immediately but introduce data weirdness
because the cases where something may be ambiguous wasn't defined.

In any case, I think that if a company has a really big, maintained code base
in Python 2, it's their fault for supporting an older, in-2020-unsupported
version of a programming language and the money/developer time spent
supporting the codebase could be spent transitioning it to Python 3. I can
understand a little more with an open source project because time is more
precious and generally that time is donated, but even then most bigger
projects (Numpy, Scipy, Django) have moved to Python 2/3 compatibility so
unless the project is gargantuan there's no real excuse besides the project is
not maintained.

~~~
true_religion
They transitioned with a lot of community support and did sooner the course of
years. It wasn't easy to support 2/3 out of the box. For a normal company,
staying on 2 is like keeping technical debt and we all know how companies
loathe to allow weeks for major refactoring when the gains aren't immediately
visible. My company switched to using puppy and eschewing c extensions before
we supported python 3.

------
yoz-y
I make software that people can write plugins for in Python. After months,
years of struggle we finally dropped support for Python 2 because our small
team could not bear the overhead of maintaining two bindings. We work a lot
with researchers in signal processing domain and we have hard time as it is to
get people to use Python 3. Please, do not put obsolete software on life
support.

~~~
coldtea
> _Please, do not put obsolete software on life support._

Regarding adoption, it's 3.0 that's obsolete, and 2.7 that's vibrant. Even for
new code (they conveniently only count totally greenfield projects, but most
new code is written in fact to work with established 2.x codebases under
Python 2, not as a totally greenfield project).

~~~
kstrauser
You keep saying things like this but numbers don't bear that out. Since we
switch to Python 3.5 for new code, I can barely tolerate working in 2.7 now.
It went from feeling "vibrant" to feeling "OMG this is legacy" in about a
week. I would never voluntarily go back.

~~~
coldtea
> _You keep saying things like this but numbers don 't bear that out._

What numbers? All the numbers I've seen -- official numbers from PyPY etc)
tell otherwise.

~~~
RedCrowbar
[https://twitter.com/vlasovskikh/status/801720613312364544](https://twitter.com/vlasovskikh/status/801720613312364544)

~~~
godelski
There is a clear selection bias here, which is revealed in the first response
(unless that was what you're pointing people towards). IDEs are a lot more
common on Windows, which has the best adoption rate. The data from the two
sources in that comment point towards a large majority of users still using
2.7, which agrees with my experience (which is in the scientific community).
The number one reason being that there is no incentive. There is a lot of that
attitude is common, "if it isn't broken, don't fix it". At this point we need
to recognize that python2.7 isn't going to die anytime soon, unless there is a
drastic change.

~~~
RedCrowbar
While the claim of selection bias in JetBrains' survey may be argued, it is
still a valid data source, which is what the gp was asking for.

Also, your anecdotal data is arguably biased as well.

My take is that many sources, including the ones linked to in the tweet's
replies point to solid growth in Python 3 adoption. Python3 might not have
overtaken Python 2 overall, but it's very far from being "dead".

~~~
coldtea
> _While the claim of selection bias in JetBrains ' survey may be argued, it
> is still a valid data source, which is what the gp was asking for._

No, I asked for a representative data source (representative was implied: a
biased data source is as good as no data source at all).

------
toggafgnadx
The worst thing about open source is that people can do stupid stuff with your
software.

If you're going to create this abomination, at least do us all a favour and
DON'T call it Python. Call it Retardython or something. I don't want to
imagine people coming into the official support channels and claiming they are
using "Python 2.8", then other people lecturing them about what that software
really is, etc. Sounds like a horrible waste of time. (Source: I spend many
hours a week helping fellow Python users.)

~~~
harryf
Python is trademarked by the Python Software foundation. IANAL but pretty sure
that means he doesn't get to call it Python 2.8

~~~
ufo
Only if the PSF does something about it...

~~~
bb611
If they don't protect their trademark they open themselves up to what is
essentially loss of the trademark in the US.

They could license it to Python 2.8 for free if they want to, though it seems
unlikely.

------
gigatexal
Python programmers and companies with python code should spend the time and
effort to move to python 3 instead of spending that time and effort to
backport stuff to python 2 because python 2 is deprecated and the future is
python 3. Python 3 I think people and businesses with python 2 code would be
better off moving their code bases to python 3 instead of doing things like
this.

~~~
jzwinck
Companies with Python code are probably better off keeping their working,
tested code than switching to an incompatible interpreter and set of libraries
which among other things will print "b'Hello',b'World'" into their mission
critical CSV files.

Yes, the built in csv module really does that in Python 3.

~~~
ubernostrum
_Yes, the built in csv module really does that in Python 3._

If you pass it bytes, yes, it does. If you pass it strings, no, it doesn't.

If what you pass to the built-in CSV writer is not a string, the CSV writer
will call str() to get a string representation it can write out. The string
representation of a bytes object includes the 'b' prefix.

Meanwhile, you discovered your bug: you were treating bytes as text, which is
likely to blow up on you sooner or later, and thanks to how Python now handles
text, it blew up on you _immediately_ as a way to remind you _not to treat
bytes as text_.

What you probably think you want is for the CSV writer to realize it got a
bytes object and, instead of calling str(), call its decode() method to get
text it can write. But that is once again a dangerous operation, and sort of
the whole point of Python 3's text changes is it won't let you get away with
that stuff anymore.

~~~
CJefferson
I had this problem.

It doesn't "blow up". If it blew up and retired, I would have seen the
problem. The problem, like several python 2/3 incompatibilities, is that
Python 3 merrily did something different, without telling anyone, until
eventually we track down what has changed. I spent quite a while on this very
bug myself, and it, along with others, persuaded me to switch to a different
language (serious I know, but I was just getting annoyed with python's general
loose dynamic nature, in combination with the python 2/3 changes.)

~~~
bb611
It's unreasonable to say "merrily did something different, without telling
anyone" when fixing the string implementation was a significant reason for
creating backwards-incompatible Python3 in the first place.

It's not a bug, it's a fix for an architectural error in Python 2, and it was
quite well announced at the time:
[https://docs.python.org/3.0/whatsnew/3.0.html](https://docs.python.org/3.0/whatsnew/3.0.html)

~~~
int_19h
Fixing the string mess in Py2 was a good thing.

But the fact that the same code now silently does the _always wrong_ thing in
Py3 wrt CSV is clearly a bug.

Actually, the design defect here is calling str() on everything, and assuming
that the output is sensible for CSV. It may be a decent rule of thumb, but it
_clearly_ does not apply to bytes. Given the likelihood that someone might
mistakenly use bytes as a string (for example, because they're porting a
legacy Py2 codebase), this should be a hard error, immediately reported as
such, and not just a silent behavior change.

~~~
ubernostrum
Except if you make an exception for bytes, what about other types that might
get passed into a CSV writer, whose __str__ is something "wrong" for CSV
purposes? Do they also get auto-detected? Do we add a new __csv__() method
just for when outputting to CSV (since it might not be "wrong" for other
output formats)? Or do we ditch str()-ifying altogether, but then add back in
a bunch of special cases for numeric types and other things where str() is
"the right thing"?

Or do we say "CSV outputs strings, whatever is the string representation of
what you passed in is what gets written out", and trust people to figure out
when they're working with something that has a "wrong" string representation
for their use case?

Because remember: the whole underlying cause of this was treating a
dangerously non-string value as a string. Those bytes objects should have been
decoded to strings long before reaching the CSV writer. Python 3 does raise
more and louder exceptions when you pass bytes to things that expect strings,
but the CSV writer isn't a thing that expects strings; it expects things that
have a string representation, and several common use cases get much more
difficult if you change that to force every user to explicitly do throwaway
casts to string in the name of protecting people who keep insisting on writing
dangerous "I'll treat bytes as string until it breaks, and then complain that
the language did the wrong thing, not me" code.

~~~
int_19h
`bytes` is plainly special case for historical reasons here - it's something
that is not a string, but that so many people _assume_ to be a string.

So yeah, I would be fine with making an exception for it (and providing some
kind of option to disable that exception, for that incredibly rare case where
someone really does need b"foo" in their CSV output).

And then in 5 years, flip the default of that switch, and deprecate it. In
another 5, remove it entirely.

Also, note that raising an error in this case is not placating the people who
insist on using bytes as strings. Quite the opposite - it very loudly and
unambiguously tells them that they're wrong, and how exactly they're wrong.

~~~
ubernostrum
The entire problem, though, is people assuming bytes and strings are
interchangeable. Anything which allows that assumption to go unquestioned, or
without program-wrecking consequences, leads right back to where we were. And
the "phase it out" model doesn't work; you proposed a ten-year phase-out, but
in ten years people are just going to say "we never updated our code, we're
not ready, keep it this way another ten years and we'll think about fixing our
code". The only thing that works is actively breaking people's programs when
they try to intermix bytes and strings.

~~~
int_19h
> The only thing that works is actively breaking people's programs when they
> try to intermix bytes and strings.

Um, this is _exactly_ what I proposed above!

"this should be a hard error, immediately reported as such, and not just a
silent behavior change."

What I'm asking for is that csv writer raises an exception if it sees bytes
anywhere by default. The problem is that right now, it doesn't! It just gives
you "incorrect" output, that might go undetected for a long time.

------
mathgenius
People don't seem to be considering the possibility that a stagnant python 2.7
may actually be a reason to like that version of the language. I must admit it
is nice to not have those oh-so-keen python developers messing with my
favorite language.

However, I recently had a gig working in py3. Apart from screwing up every
single print statement for a long time, it was entirely drama-free, and
actually pretty great. There really is a difference between living and dead
languages I think. 2.7 is the latin of python.

~~~
ant6n
why can't print be both a function and a statement...

~~~
kevin_thibedeau
The print statement has a lot of special magic like '>>' and trailing commas
that uglifies the parser.

~~~
ant6n
I don't get this. There's a tiny fraction of Python users who care about the
complexity of the language parser. But many hate the print-tax.

------
naftaliharris
Author here. Imagine my surprise when I got back from a day of sightseeing
(I'm on vacation in Spain) and saw that this had blown up. I had intended to
"release" this project after New Years, after I'd gotten back and a week or
two after 3.6 is released [1], and didn't expect this to get picked up since
the project has been on Github for over a year (although inactive for much of
that time) and since my blog usually doesn't get much traffic.

A lot of people here have strong opinions about the name "Python 2.8". I don't
mind changing it, and intend to do so,
([https://github.com/naftaliharris/python2.8/issues/47](https://github.com/naftaliharris/python2.8/issues/47)).
I picked it initially since when talking with friends about this project it
conveyed pretty darn immediately what the project is and does. I'd be very
keen to hear people's suggestions for alternate names!

For those of you with 2.7 codebases or projects, I'd be extremely interested
in hearing about whether you were able to get this interpreter to run your
code. Personally, the biggest challenges I've had so far are with dependencies
that check for `sys.version_info[:2] == (2, 7)` as opposed to something like
`sys.version_info[0] < 3`. But I'd be very interested in other people's
experiences, particularly with larger codebases.

[1] A minor and somewhat pedantic point: The interpreter I've been working on
includes PEP 515 (underscores in numeric literals), which is new in 3.6. I
didn't think it was right for me to "take credit" for this new feature before
it was even out in Python 3.6. Obviously, the real credit for this feature
existing (in 3.6 or in any interpreter) goes to the CPython core devs, and
especially Georg Brandl.

~~~
eximius
Regardless of the detractors, I think this is brilliant work. All of the
negativity around your project is over politics or subjective opinions based
off of individual experience where they are lucky enough to work in
environments on the bleeding edge.

Keep up the good work, this could help a lot of people!

------
cesarb
Reading a thread from the last time something like that was proposed (although
the only change in that proposal was that 2.8 would, on Windows, use the C
runtime from a more recent MSVC compiler), I found a relevant argument
([https://mail.python.org/pipermail/python-
dev/2013-November/1...](https://mail.python.org/pipermail/python-
dev/2013-November/130485.html)) against this "Python 2.8" idea:

What if more than one person did that? (paraphrasing Raymond Chen's "What if
two programs did this?")

There can be only one official Python 2.8, but since it will never exist (see
PEP 404), there can be many unofficial mutually incompatible "Python" 2.8
implementations. Therefore, calling it "Python 2.8" is a bad idea.

------
dagss
I see many people vigorously defending Py3 but I wonder how many of these have
a paying-the-bills kind of job. Where you would look at the cost of porting a
large project to Py3 and get an answer like half a million USD (easily). Do
you go "of course we do that, that money is easily recouped with the added
programmer productivity of Py3"? No chance.

So the question is do you want to basically light that money on fire, or just
keep your perfectly fine Py2.7 code running and maintained another few years.

More discussions of the monetary value of programming languages please. What
is "correct" or "right" isn't all that interesting to many, for good reasons.

Kudos to this project and hope it can set us on a saner migration path to Py3.
(Should totally change the name though.)

~~~
toyg
You can keep your py2.x code running, absolutely; but you cannot expect other
people _working for free_ to help you pay your bills.

Honestly, the level of self-entitlement through all 2vs3 threads is
staggering.

~~~
dagss
I don't want the CPython core devs to do anything different and are not angry
with them at all. It is their pet and they can do what they want. I fully
agree with what you say in that sense.

But I do mind people saying in these discussions "you should all move to Py3
now or you are stupid/evil".

No. There are legitimate reasons for staying with Py2.7 and embracing it.

So I hope "Python 2.8" gets a cool name, perhaps even some funding from a
company who wants to keep their Py2.7 code alive and invigorated, and the
community part as friends.

Is that self-entitlement in any sense?

All I want is for people who I think have a huge blind spot to stop calling me
ignorant for decisons I make about MY code. I totally don't expect core
CPython devs help me out though.

~~~
toyg
_> I don't want the CPython core devs to do anything different_

It's not just CPython, it's the Python specification of which CPython is the
reference implementation. The specification couldn't move forward in
significant ways without making some of the changes that came with Python 3.

 _> All I want is for people who I think have a huge blind spot to stop
calling me ignorant_

The level of vitriol in 2vs3 threads has been way too high _from the start_ ,
because people always hate change. You are obviously free to do what you want,
you always were. Don't mind the haters, but please don't be one either.

~~~
dagss
Thanks for that, well said.

------
dom0
> I've been working on Python 2.8 (not an official Python release)

It is very dishonest to call it Python 2.8 then.

~~~
labrador
I suggest Monty 2.8

------
eej71
It's too bad the python 3.x fans can't see this as feedback about how
difficult it for users of 2.x to upgrade to the latest and greatest. Many 2.x
folks have sprawling code bases and complex operational needs. The 3.x
advocates seems to consistently ignore that.

Shoot the 2.8 messenger all you want for choosing to call it Python 2.8, but
don't dismiss the issue that drives thoughtful people to get value out of this
strategy.

~~~
fatbird
The python maintainers and the 3.x fans do see this, and know this, and
decided to do it. They knew there would be a cost in community, and decided it
was worth it. They haven't been oblivious, and they've made several large
concessions in 3.4 and 3.5 to increase the ease of migrating. Stop denigrating
them.

------
mathgenius
Christian Tismer tried this a couple of years ago [1].

I guess the intention was a bit different: he wanted to have stackless
features in python. It's not clear to me the reason he decided to back down,
whether because of licensing issues or just because the other python
developers didn't like it.

[1]
[http://www.stackless.com/pipermail/stackless/2014-January/00...](http://www.stackless.com/pipermail/stackless/2014-January/006043.html)

------
silent1mezzo
What another load of crap. Call it something else but this isn't Python. I'd
never use this because it's not official. Who knows if or how long it'd be
supported for or if any backdoors would/could be introduced.

I've scheduled time this year for my teams project to update to Python 3. It's
expensive in the short term but in the long term we get continued support and
new features which is a huge win.

~~~
nilved
Do you trust PyPy? It's not official either.

------
nzjrs
I can't fault a single thing in his justification. This should have been the
approach to modernising python all along.

~~~
Manishearth
This approach could not have worked for modernizing python. The whole point of
the Python 3 thing was to be able to remove warts in the language that could
not have been fixed without breaking backwards compatibility. One core part of
this is unicode support -- Python had a horrible story for international text
before this.

The fact that there are some parts of "modern" Python which could have been
implemented in Python 2.7 backwards-compatibly is irrelevant.

Python 3 is not the language designers worrying about minor subjective issues
in python like the print keyword or the design of iterators and deciding that
they want to change it all. It is the language designers worrying about major
issues like international text, realizing that they regrettably will have to
break backwards compatibility to fix those, and then just taking the
opportunity to revamp things like printing and iteration since they're
breaking backcompat in some pretty major ways anyway.

~~~
patrec
Python 3 fixes no fundamental issues with python 2 and introduced far more
warts than it removed. GIL is still there, crummy runtime is still there and
unicode is now an even greater mess. I really wonder how many people who bang
on about unicode actually have a good grasp of unicode and text processing
because python3's unicode design is obviously terrible. I can now access or
count code points in O(1) (neither of which is in any way useful) at the cost
of tremendously increasing space and time overhead for any basic text
operation on non ascii text and having some bizarre hacks to deal with the
fact that pretending that stdin and stdout and sys.argv are always text.

~~~
wbond
It most certainly fixes support for Unicode on Windows in terms of filesystems
paths, OS function boundaries and the console. Some of these fixes have even
taken until 3.6 to get implemented.

As someone who writes cross-platform code, Python 3 was a breath of fresh air
after fumbling around in the dark with Python 2.

~~~
patrec
I can definitely believe that – but windows has basically lost[1] and a much
worse text model to boot. Like Java and unlike python 3, they at least have
the excellent excuse that this was not obvious at the time. And under unix the
impedance mismatch has definitely increased. Not a good trade.

[1] I wouldn't count them out, but they're definitely on the back foot as bash
inclusion shows.

------
maxander
So when you see a project written in Python 2.8, you'll know that it contains
lots of legacy code under active development by developers who are gung-ho
about fancy language features, but that this team hasn't had the
time/resources/gumption to do a code overhaul anytime in the past _six years_.

And also that you yourself, and any users of your own project, will need to
run it with this guy's own homebrewed version of Python in order to know it
will behave correctly.

Useful?

------
grx
I don't think this is a good idea simply because it reduces the need to
upgrade your library from 2.x to 3. It's a clear cut and a good chance to weed
out unmaintained libraries

~~~
kevincox
Or possibly it makes it easier to have code that works on both. Although that
requires this to catch on enough that 2.7 compatibility isn't required.

~~~
grx
That would mean someone develops a library that uses features of Python 3, but
needs some horrible hacking to port those features to Python 2. Thanks, but no
- please make a cut and decide or split it in two separate packages.

~~~
masklinn
> That would mean someone develops a library that uses features of Python 3,
> but needs some horrible hacking to port those features to Python 2.

The "horrible hacking" already exists bundled into libraries and tools like
Six and Future.

> split it in two seperate packages.

That was tried, and failed every time. Because now you end up with two
diverging and hard to reconcile code bases. A single-source cross-version
library, while not trivial (and not allowing the user of more advanced P3
features) works way better.

~~~
rspeer
> The "horrible hacking" already exists bundled into libraries and tools like
> Six and Future.

Only for the simplest cases. How is Six going to help you write a regex that
matches emoji, for example?

On Python 3 you write a range that includes the emoji you want to match, and
you're done. On Python 2, that regex may or may not compile, depending on what
sys.maxunicode is. If sys.maxunicode is 65535 you have to fall back on a
different complicated regex that has a bunch of cases to find emoji in their
UTF-16 representation. If you want to avoid that system-specific behavior, you
can I guess encode it to UTF-8 bytes and write an _extremely_ complicated
regex that finds emoji in UTF-8.

This is my prime example about how something that's easy on Python 3 can
require horrible hacking on Python 2. A wrapper library doesn't fix that
problem.

Python 2 and 3 have different semantics, and the only way a correct, automated
translation between them would be possible would be to emulate one inside the
other.

------
MaxfordAndSons
Slightly tangential, but: I've noticed an interesting parallel between the 2.7
/ 3.x partisan divide, and the US political partisan divide. In both cases, as
partisan passions have increased without relief, there's both A) an increasing
unwillingness to agree on basic facts about reality essential to the debate,
and B) increasing presumptions of bad faith on the part of their opponents.

Examples of A in this discussion:

\- Disagreements about the degree of library support for 3.x

\- '' the ease/value of porting from 2 to 3

\- '' the rate of industry adoption of 3 for new projects

\- '' the degree to which people are driven away from Python entirely because
of the version situation

Examples of B in this discussion:

\- Claims of paternalism on the part of GVR/ the PSF in pushing 3

\- Claims of unreasonable/emotional attachment to 2 by partisan devs

\- Claims of willful distortion of facts by both sides (see A)

\- Claims that the writing is on the wall for 2, because usage of 3 is
supposedly accelerating

\- Claims that the writing is on the wall for 3, because it's supposedly taken
too long to drive not enough adoption

It seems outrageous to suggest that the differences between 2 and 3 are
anywhere near as significant as the differences between, say political
conservatism and liberalism, and yet the level of partisanship seems nearly
the same. How did it come to be like this?

~~~
nercht12
+1

I like how your comment stands out as being such a rational, non-aggressive
observation in all this. I wish I had the answer for you, but I can't figure
it out either. _shrug_ Maybe some people are using this as an opportunity to
vent the frustrations they've had with using the language (despite it being so
loved, and ranked 3rd in most-used according to IEEE), and since there are two
versions of the language instead of one, they can more readily create an
object doomed for the epitome of their hatred, the sacrificial lamb going to
the slaughter (sounds like something from a bizarre school of thought in
psychology). You'd think it'd just be easier to let people do what works best
for them. I'm sure many expect to take collateral damage from the differences
in versions (imagine being a Python 3 fan and having to start working for a
company that exclusively uses Python 2 or vice versa), but these people also
readily accept working with languages with radically different designs and
welcome in copy-cats (like Clojure is to other LISP-like languages). The
important thing is that the language does what you need it to do. The name on
the download link shouldn't make that much of a difference. The world has
adapted to accepting Python 2 and Python 3 regardless of the bickering.
There's room for "Python 2.8", even if it is poorly-named. I imagine there are
probably dozens of Python 2.8s in existence - they just haven't been noticed
by people here on HN. Besides, in about 3 months, we probably won't be hearing
more about Python 2.8 anyways unless someone else decides to use it.

------
dekhn
Thanks for doing this! I took a look at the arguments underlying the proposed
switch to Python 3 and came to the conclusion that they did not meet the
necessary threshold of effort to switch. Instead, I want to see every feature
in Python 3 backported into 27. I don't think the unicode change can be
accomodated, but 99% of the rest of the new features in 3 can.

------
js8
IMHO, Jython 3 would be more useful than Python 2.8, but it's your project.

We have a project at work and the only reason we need to support 2.7 is
because we want to run under Jython.

Anyway, I would like to hear other people's use cases for Python 2.7.

~~~
kensai
Isn't Jython (generally) dead? The main site seems to be stuck in 2015.

~~~
aargh_aargh
It's not dead, it's just really slow. The 2.7 release has been very long in
the making, released only 18 months ago. There are stabilization releases to
it still coming out. There's a tiny, but dedicated group building it and it
shows. Jython 3 is possible if you're willing to put your money where your
mouth is.

~~~
gsnedders
There's been an imminent 2.7.1 release for a while now, so that will likely
eventually ship.

AIUI, some of those who were paid to work on it previously are now doing so
only in their spare time.

~~~
jimbaker
Yes, that would be true on all counts :) as one of those Jython maintainers.
Jython 2.7.1 is currently bottlenecked on finalizing support on Windows for
pip/setuptools. It should be the last fix.

------
rini17
The discussion is a nice overview how py3k crowd just steamrolls over any
discussion that there are indeed inherent difficulties with forcing lossy
conversion of imperfect outside input.

See example in the fine manual:
[https://docs.python.org/3.7/library/urllib.request.html#exam...](https://docs.python.org/3.7/library/urllib.request.html#examples)

You are only told "we know python.org uses utf-8 so just decode it as utf-8."
No further discussion, no pointers are provided how to correctly fetch an URL
with text content into a string. Even small convenience function that at least
tries to look on Content-Type: header would help here!

I am well aware that "in py2k it just worked" was mostly an illusion. But
honestly, is the situation above an improvement?

------
greyman
Nobody should believe me, but I kind of expected something like this would
happen. People just wants to keep using 2.7, and let the language evolve
slowly over time, as is happening with PHP, for example. So if 2.7 development
was officially stopped, someone will continue with it unofficially.

------
andy_ppp
I think the problem for me is that they did these changes and made a big song
and dance about Python 3. If they had have called Python 3.0 v2.9 instead
everyone would have been clear they had to migrate.

PHP has been successfully deprecating features for decades now and cleaned up
their code base; they have never had a schism in the way Python has so you can
argue all you want about legacy, or people preferring 2.7. The reason this
happend (and is still happening) are human not technical.

~~~
jnbiche
> If they had have called Python 3.0 v2.9 instead everyone would have been
> clear they had to migrate. [...] The reason this happend (and is still
> happening) are human not technical.

You know, as a strong proponent of Python 3.* (it's a significantly better
Python), I started to write a withering critique of your statements here (and
I do strongly disagree about naming it Python v2.9). But then I started
actually looking at the evidence.

For example, when you go to download Python at the python.org website, you're
_still_ presented with a choice between Python 2 and Python 3 side-by-side,
looking for all purposes like equivalent choices (Python 2 should be much less
prominent and toward the bottom and/or the download button should be much
smaller than the Python 3 download button)[0].

And then, when you follow the link for "Wondering which version to use?", you
get a full page worth of hemming and hawing, and cost-benefit analyses and so
on[1]. In fact, they should be saying something like:

    
    
        Always use Python 3 unless you have a strong reason to do otherwise.
        This typically only applies to people who have large legacy code 
        bases and are for some reason unable to upgrade, or else need a special 
        legacy library only available in Python 2 (most libraries are 
        available in Python 3)."
    

So wow, having read the official python.org statements on the Python 2 vs 3
issue, I'm pretty appalled. No wonder some people who are relatively new to
Python are confused or surprised. I'm on Debian or Ubuntu mostly and so
download Python via package manager or PPA, or build from source. So I had no
idea.

It's also been a huge mistake for GVR to have allowed so many new and
attractive features to be backported to Python 2.7. It's taken away a
significant amount of incentive for people to make the move. Python 2.* should
have been bugfixes only for a long, long time now.

That said, if you're in charge of significant amount of Python code for a
company and you've not seen for years that Python 2 is a deadend, you've
either been engaging in wishful thinking or oblivious to what's happening in
the Python community.

0\. [https://python.org/downloads/](https://python.org/downloads/)

1\.
[https://wiki.python.org/moin/Python2orPython3](https://wiki.python.org/moin/Python2orPython3)

~~~
Al-Khwarizmi
_It 's also been a huge mistake for GVR to have allowed so many new and
attractive features to be backported to Python 2.7. It's taken away a
significant amount of incentive for people to make the move._

The idea that Python 2 needs to be sabotaged and the community forbidden from
improving it so that people makes the move, with the people who are stuck to
Python 2 codebases held as hostages, should be an indicator that something was
done very, very wrong...

Personally, I'm neutral as to 2 vs. 3, I use both, but the schism is the main
drawback of Python for me and it often drives me to just use other languages.
Python 3 is great and has very neat improvements, but it should have just been
called a different name so that both branches could evolve freely and compete
on their own merits, rather than on the PSF mandating to use one over the
other.

------
Zane55
> I've been working on Python 2.8 (not an official Python release) because I
> want to give all the people who use Python 2 access to the Python 3 language
> features, which I think are actually pretty cool.

Theres a module called __future__ for exactly this purpose

------
davidmanescu
I hope I don't come across as too obtuse, but it might still make economical
sense for the PSF to backpedal on their decision: even if Python3 is a good
solution for the future, it's caused years of arguments and still hasn't been
adopted by the majority[1].

Ridiculous as it might sound, that implies it would actually take less work to
devise a path for Python2 that's backwards compatible but still has a future,
and invest the time to backport all 3-only code, than it would to proceed with
killing off 2 and porting everything over. It's also nothing more than
everyone whose code is 2-only is being asked to do sometime in the future
(they chose "the wrong competing standard" and have to pay the cost). Either
way someone has to foot the bill for a unified Python but couldn't it just be
that the early adopters of 3 could pay that cost if it saves updating (say)
twice as much legacy code in favour of backporting the 3-only code?

Of course, the future version of Python should be the best form of the
language with the right features, and that's why it was decided to kill off 2,
but if after this many years the initiative hasn't completely succeeded,
there's always the option to reverse course.

Heck, in the time until Python 2 is officially gone, maybe this new fork will
evolve into a better language than 3 and still be backwards-compatible with 2!

For now I'm sticking with 2.7 for as long as I can but will just accept it
when the time comes.

[1]:
[https://mobile.twitter.com/vlasovskikh/status/80172061331236...](https://mobile.twitter.com/vlasovskikh/status/801720613312364544)
for example (I don't _think_ I've made a controversial claim here but could be
wrong)

------
xrisk
Now you're just adding on more technical debt for users of Python 2. Who's
going to maintain your Python 2.8? What happens when there are conflicts
between your Python 2.8 and Python 2.7?

This is just a really bad idea IMO.

------
sandGorgon
this is incredible - give me unicode support in python 2. asyncio ? probably
.. i'll still be happy with gevent. This is a clear path for a python upgrade.

~~~
masklinn
> give me unicode support in python 2

Nope. Can't be done without getting Python 3 either way, because _Python 3 's
text model is not compatible with Python 2's_. That is why the core team
allowed the other breaking changes, because software was going to be broken in
the first place.

~~~
sandGorgon
not entirely true - [http://python-
future.org/unicode_literals.html](http://python-
future.org/unicode_literals.html)

it's not 100% seamless, but its almost there.

~~~
smallnamespace
> Changing to `unicode_literals` will likely introduce regressions on Python 2
> that require an initial investment of time to find and fix. The APIs may be
> changed in subtle ways that are not immediately obvious.

Unless you're willing to put in the time and energy to extensively test, this
is basically a recipe for disaster. You're basically paying at least 80% of
the cost of a full Py2 -> Py3 port (since looking for regressions is a huge
part of that cost), for only a fraction of the benefit.

~~~
dagss
Being able to change things in one part of the code base at the time -- or one
feature/data field at the time, is a HUGE thing. For production systems you
just cannot put the backlog on pause for a month or two while porting. You can
however incrementally fix over the course of some years.

~~~
smallnamespace
That's probably true, but unicode_literals isn't the right tool to make an
incremental port, because it neither obeys good py2 _nor_ py3 text handling
conventions.

It would become a substantial detour and end up being a kit more total work.

Also, porting can be done in parallel to normal dev. You aim your port at a
specific release while you continue fixing bugs. When the port is done, you
port over all the patches. Repeat until port and original version converge.

~~~
dagss
Isn't it as simple as a) do proper string handling in py2 unicode and b) if
you write more u"" in a file than "", flip the switch and write "" and b""
instead?

~~~
smallnamespace
Not quite, because the py2 library is often not compatible with unicode
literals, and also because if you flip the switch in a module it changes the
API of any functions that returned strings. That might break calling code from
other modules.

So then you might have to add code to work around these issues, code that is
needed in neither pure py2 or pure py3 -- hence making it a weird detour.

 _In general, it is more compelling to use `unicode_literals` when back-
porting new or existing Python 3 code to Python 2 /3 than when porting
existing Python 2 code to 2/3_ [1]

[1] [http://python-future.org/unicode_literals.html](http://python-
future.org/unicode_literals.html)

~~~
dagss
Right.. our codebase is already unicode all over the place because otherwise
we could not i18n properly. So we basically have py2 unicode-correct code with
encode/decode in the proper places for interfacing witg stdlib. I didn't
consider people might use str and not unicode for text..

------
hartator
We should make this Python 4.0 and move on. Some high paid google engineers
working the "official" 3.x will be pissed, but that's life. I am sad to see
the schism in Python community.

~~~
rch
A non-trivial number of people seem to want this, but why does it need to be
called Python? Keep the syntax and C extension compatibility, but ditch the
name. One could even work out a means of selectively bringing in ideas from
elsewhere:

\- Concurrency from Erlang
([http://queue.acm.org/detail.cfm?id=1454463](http://queue.acm.org/detail.cfm?id=1454463))

\- String handling from Go
([https://blog.golang.org/strings](https://blog.golang.org/strings))

\- Lightweight data classes ([https://kotlinlang.org/docs/reference/data-
classes.html](https://kotlinlang.org/docs/reference/data-classes.html))

\- Syntactic macros from Nim ([https://hookrace.net/blog/introduction-to-
metaprogramming-in...](https://hookrace.net/blog/introduction-to-
metaprogramming-in-nim/))

\- more from Lua, Julia, Scala, and Haskell (within reason)

There are already plenty of examples of Python modules that implement
significant modifications (e.g. Cython, Rpy2, Dask), so I don't think it would
really feel all that different from typical Python programming.

------
aftbit
Why did Python 3 not ship with

    
    
        from __past__ import bytestring_literals, loose_comparison, integer_division, ...
    

? Being able to upgrade one file at a time to Py3 would have made porting so
much easier! I realize some things could be hard to support file-at-a-time,
but others (like my examples) would obviously not.

I've held off on porting the Py2 code that I'm responsible for because of the
lack of total test coverage. I know that something tricky with unicode, None
comparison, or the list->generator split will cause a failure in a weird,
untested edge case. If I were making a numeric library, that'd be one thing.
However, I mostly write complicated business logic API glue code that is hard
to test without huge amounts of mocks.

Also, this kind of thing gives me nightmares about porting:

    
    
        WSGI therefore defines two kinds of "string":
    
        "Native" strings (which are always implemented using the type named str ) that are used for request/response headers and metadata
        "Bytestrings" (which are implemented using the bytes type in Python 3, and str elsewhere), that are used for the bodies of requests and responses (e.g. POST/PUT input data and HTML page outputs).
    

So according to the spec (!) WSGI headers MUST be `str` in Python 2 & 3, but
that means that the semantic meaning of the types changes. How on earth am I
supposed to write good code for working with headers (let alone mocking and
testing) when I'm required to decode them in Python 2 but not in Python 3?

------
upofadown
I consider the fact that 2.7 isn't getting new features a good thing. After a
point, every new feature takes away something from everything that came
before.

------
thesquib
What about contributing towards a project which enables python2 code to run in
python2? Seems like this would help the move to python3 overall...

Something like this? [http://python-
future.org/translation.html](http://python-future.org/translation.html)

~~~
masklinn
> What about contributing towards a project which enables python2 code to run
> in python2?

Surely that already exists?

------
thewhitetulip
I never knew that despite Python 3 is called the future by PSF and has been
around for a ling time, people still want to stick to Python 2. I mean it
isn't the 2013 that libs aren't ported, most famous ones generally are ported.
Don't know what the problem is.

~~~
bb611
Legacy python 2 code & an unwillingness to refactor it for python 3.

~~~
thewhitetulip
I can understand a project with millions of lines of python2 code, it would be
a headache to port it all to python3

------
StevePerkins
Haha... this is the most Python thread ever.

------
BuckRogers
So it begins.

The arrogance and stubbornness of the CPython dev team is starting to face the
consequences we all knew were coming. If only they'd at least done unicode
right. Gone with assume UTF-8 and kept the indistinction between bytes and
unicode, more of us would be onboard.

------
woah
Why does Python have so many hilariously convoluted trials and tribulations
over decades trying to upgrade their language when the JavaScript community is
able to run smoothly across many different versions and many different
interpreters simultaneously?

------
jchassoul
Just don't call it Python 2.8

~~~
jchassoul
PLEASE don't call it Python 2.8 ...

------
Animats
It's too bad someone didn't do this years ago. We could have avoided much
pain.

------
babo
As a Python 2.7 project why would I trust more to this unofficial version with
a lot of backported code compared to the tried and tested 2.7 to 3 route?

What would happen with my python 2.8 when it needs to be converted to the
official python 3?

------
rch
> there are some python scripts that will run under both Python 2.7 and Python
> 3.x but produce different output

OK, so it may well be terrific, but it should _really_ have a different name.

------
snippet22
You need one of these.
[https://golang.org/cmd/fix/](https://golang.org/cmd/fix/)

------
grillwork
the python community is like a snake eating its own tail

------
supergreg
Just call it Unofficial Python 2.8 instead of Python 2.8

------
luckydata
The existence of this project shows a tremendous lack of judgment on behalf of
the creator and does exactly zero good things for the python community.

------
ianamartin
Just a couple of things I want to point out here.

1\. Calling it Python 2.8 is a really bad idea. If you want to fork Python in
this way, great. I'm sure very few people in the community would have a
problem with it if you called it Brothon or P8thon or Hackthon (could run into
trouble with that one, but who knows?) or IHate3.xThon. You can call it
LifeOfBrython or Snake, depending on how much you care about where the name
came from.

Guido van Rossum is one of the least litigious people you can find in the open
source community. When he wanted people to stop naming packages after PEPs
(pep8, pep257), he didn't try to go to court and figure it out later. He
talked to the maintainers of the packages and explained why he thought it was
problematic [0]. I wouldn't expect a cease and desist showing up anytime soon,
but it's in poor taste, and I hope you reconsider it. Python is not yours just
because you are free to use it and do as you please with it. It's really
stretching the concept of open source for you to unilaterally declare a
collection of hacks to be a point release that's been specifically addressed
and decided against by the community as a whole.

2\. I have so much sympathy for people who must maintain Python 2.x
applications and cannot make the business case for putting the time into
porting it to Python 3. I'm in that situation myself right now, and I have
been for years. I can't find a compelling argument to warrant the time so long
as the 2.7.x branch is getting security updates. When the security updates
stop, the move will finish.

The reality is that those of us who have been working with Python for a long
time now (10+ years) have already figured out reliable workflows to get around
the most lacking aspects of the language in our domains of expertise. Or we
have swapped out subsystems in other languages for cases where we absolutely
cannot find workarounds.

I get it. I'm in that boat. I understand that boat because I live in it.

I can even understand why this project happened. Because hacking things you
love to make them better for you as an individual is the heart and soul of
what makes software development so great.

What I absolutely cannot understand is why anyone (absent certain libraries
needed) would start a new project on a deprecated branch of a language. And I
don't understand why this is such a contentious issue specifically with
Python. I don't hear any of my friends who work with C# or Go getting into
arguments about how the latest version has failed or shouldn't have been
rolled out. As much as Swift 3 has caused problems, I don't hear any of my iOS
developer friends complaining about how that shouldn't have happened and
trying to backport the good stuff into the 2.x branch. I genuinely don't
understand this behavior in the Python community.

 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __
__ __ __ __ __ __ __ __ __ __*

I do, however, suspect that it has something to do with the overall age of the
community.

Using Python has always been a matter of taste and style. I get that. Python
is a language that makes explicit tradeoffs between performance and style. It
is no shock to me that people who learned to love the language in its older
form want it to stay that way. And I say this as someone who is closer to 40
than I am 30: we older folks in the industry need to fight against the
stereotype that we can't or won't learn new tricks. Yes, there's a place for
battle scars and pushing back against every new flavor-of-the-month stack that
rehashes old problems in new ways. But obstinately sticking with stuff simply
because it's what we know does all of us who are getting on in years a huge
disservice.

Getting a good gig as a software engineer in your 20s is not that difficult.
Getting the same gig when you're pushing 40 and the hiring managers are still
in their 20s is a lot harder. If you're making decisions to start new projects
on old versions of _any_ language, please, please, please, do all of us a
favor: make sure that you are doing it for solid reasons and not simply
because it's what you already know and are already comfortable with.

 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __
__ __ __ __ __*

Because this post isn't long enough already, I have a second pet theory about
the reluctant adopters.

Python 3 is a _great_ language. It's not the same as Python 2. It makes
different tradeoffs about styles and choices of expression from what Python 2
does because these things can and should change over time.

I think that the expressive power of Python, the closeness to human language,
and the ease of reading well-formed code have a lot to do with the resistance
to Python 3. There are people (I'm one of them) who get really really picky
about language in general. I think the Oxford comma is a necessity in almost
every case. And I think people who casually omit it are stupid, shallow, non-
thinking, drones who don't care about the history of language and don't care
about precise meaning of words, and therefore don't care about me because they
an't be arsed to toss a comma in a place that greatly clarifies meaning.

I don't actually think all of that, but I'm closer to that than I am to not
caring at all.

And there are many like me. When you're dealing with a programming language
with intent at its heart, people are going to take that in different ways.
When you're dealing with a language that cares about whitespace and eschews
braces and wants to limit brackets and just expose the pure logic of the
program, people really are going to get fired up about print vs. print().

That's expected. And beautiful that so many people care that much. But as much
as I lean towards prescriptivism and that rules are good for a language, even
I have to admit that language evolves. But it usually evolves to be more
inclusive and more expressive, not less. The really bad fights about languages
in general revolve around what to include, not what to exclude. Because
languages are exclusive by default.

A counterpoint to my idea above that we are all just old and lazy, is this:
that we really do genuinely care, and that we care for good reasons. But
something has to give. We cannot refute the evolutionary pressure. Python 3 is
as necessary for modern speakers of programs as a recent edition of a
dictionary is in your preferred language.

Yes, you can get by with something older, and you can even make yourself
understood by most people who speak the language.

But you are limiting your ability to express your intent when you make an
intentional choice to refuse to adopt what the rest of the culture around you
is doing.

Aaaaaaand I'm done. Sorry for how long that was. I didn't intend that. It just
sort of happened. If you read all the way to the end, let me know, and I'll
upvote you.

[0]:
[https://github.com/PyCQA/pycodestyle/issues/466](https://github.com/PyCQA/pycodestyle/issues/466)

------
yahyaheee
Please just spend your time porting things to python 3, this kind of work
could spell the end for python

------
rebootthesystem
Hmmm. OK.

This is a bad idea. My guess is the author will not be able to call this thing
"Python", and for good reason.

Should it exist? Sure. Why not? The nature of FOSS is that anyone can tinker
with it and make it into whatever they dream. Go for it! Just don't call it
Python.

I use both 2.7 and 3.x. No drama. New projects go through a "Do we see any
issues with 3.x?" phase where we try to list libraries we'll need and check
for support. Not that difficult.

I absolutely understand companies/people holding on to 2.7 for dear life.
Converting a non-trivial working code-base would be costly and very difficult
to debug if that code base doesn't have extensive test coverage (probably true
of most). It would also be utterly irresponsible in most business cases.

Most businesses don't have software developers sitting around doing nothing.
Revenue comes from existing products and new features along with bug fixing.
No customer of a software product will pay one dime for a company devoting a
year to port their entire code-base to 3.x. Can you visualize that
announcement?

"We stopped delivering new features and fixing bugs a year ago. Instead we
ported our entire product to Python 3.x. Today, a year later, we give you
exactly what you were using a year ago. Enjoy!"

Yeah. Exactly. The huge sucking sound you'll hear is that of customers leaving
the company throughout an entire year of nothingness. In a dynamic free market
competitors would eat you alive as you stop delivering features and fixes
while they zoom right past you with a better offering to your customers.

That said, sticking to 2.7 for the long haul --say, ten years from now-- will
create the Python equivalent of old COBOL code still running in deep dark
places within financial institutions. It will create codebases nobody wants to
look at or touch. It will create codebases that will be anywhere from hard to
impossible to support as libraries will surely evolve to support the 3.x and,
eventually, 4.x branch.

It is perfectly sensible for a company to, given today's realities, stick to
2.7. This is almost exactly the problem described in "The Innovator's
Dilemma". Good management means focusing on delivering what your current
customers are buying and want to buy. Unless they are clamoring for your
product to use 3.x it could actually be really bad management to make the
switch.

The only way to do it correctly would be to hire a full parallel team of
programmers to port the codebase while mirroring every single new feature and
bug fix implemented as customer's needs are met. At some future point the two
branches would achieve parity in function and reliability. This parity would
allow seamlessly switching to the new codebase without damaging customer
relationships. Of course, this would cost a ton of money for a non-trivial
product and, at the end of the process, the company would probably have to
fire one of the two teams. Pretty messy and costly in more than just financial
terms, isn't it?

I am not advocating either approach. Just saying I understand this from both
engineering and business perspectives. People pushing others to just switch
are doing so from a frame of reference devoid of any understanding of the
realities of business. Most businesses are not about the technology, they are
about what problem you solve for your customer. They don't care about "the
geek stuff" behind the curtains. And rightly so.

Live long and prosper.

------
slmyers
Is the xkcd Appropriate Standards strip appropriate here?

~~~
nercht12
Python xkcd: [https://xkcd.com/353/](https://xkcd.com/353/)

What's even ironic here is that the print command he used is Python 2 instead
of Python agnostic. I wonder which version Randall Munroe would prefer, if
either.

------
Pica_soO
Program languages could be so great if it were not for those pesky users.

------
smegel
This isn't bound to confuse anyone.

~~~
singularity2001
This comment wasn't ironic

------
lordkrandel
Hope you don t succeed

------
holografix
Cuz you have too much free time?

------
mattbillenstein
This is gonna be great.

[https://vazor.com/drop/gif/bill_hader_popcorn.gif](https://vazor.com/drop/gif/bill_hader_popcorn.gif)

~~~
mattbillenstein
I meant -- entertaining great -- people see Python2 vs Python3 as a holy war,
it's just software guys.

