Python 3 changed nothing

* print is function

* string is unicode by default

Should have been clean and easy migration path

    # python 2
    from __future__ import print_function
    print(u"foo")
    u"" # was u""
    b"" # was  ""

But u"" was not supported in Python 3 until PEP 414 (python 3.3) [1]. That's four years [2]:

    Python 3.0.0 Dec.   3, 2008
    Python 3.3.0 Sept. 29, 2012

Ruby string switched from codebytes to codepoints with encoding in 1.9. Ruby 2.0 switched default literal encoding to UTF-8 [3], timeline [4]:

    Ruby 1.8.7          2008-05-31
    Ruby 1.9.1          2009-01-30 # first 1.9
    Ruby 1.9.2          2010-08-18 # people already switched to 1.9
    Ruby 2.0.0          2013-02-24 # first 2.0
    Ruby 1.8.7-p352     2013-06-27 # last 1.8

Switch to Ruby 2.0 was even simpler than 1.9.

How specifically Wayland harms you? I've opened GTK+ tutorial [5], compiled code, works both on X.Org and Wayland. How it is not clean migration path?

And no, it is not XWayland which is additional migration path, I've removed it for this test:

    $ xterm
    xterm: Xt error: Can't open display: :1

[1] https://www.python.org/dev/peps/pep-0414/

[2] https://www.python.org/downloads/

[3] https://medium.com/rubycademy/the-evolution-of-ruby-strings-...

[4] https://www.ruby-lang.org/en/downloads/releases/

[5] https://developer.gnome.org/gtk3/stable/gtk-getting-started....

> Python 3 changed nothing.

Sorry, have you tried to maintain a C extension for both 2/3? Or a unicode heavy application?

This is a silly statement, there's a reason that major packages took a decade to migrate. There are thousands of little details that are incompatible.

From user perspective. Gains.

Nothing required big 2/3 change. Ruby and Go done it right — a series of small changes. Python 2.* had it right. The attitude of language developers was clearly stated in PEP 414 and 2to3 approach — no backward compatibility. That is nonsense, every python program had backward compatibility several minor versions deep.

Select one issue and work on it. Unicode:

    # python prev
    u"" # or from __future__ import unicode_literals
    b""

vs

    # python next
    u""
    b"" # or from __past__ import binary_literals

Facts speak for itself, change was to big for users to overcome it, price was too high. I've lived through Ruby string changes, not a big deal.

Wayland transition is nothing like Python 2/3. It is big but mostly invisible, XWayland runs X11 applications, toolkits hide implementation details, no X.Org deprecation.

Just like you said, for majority of people, migration from python 2 to 3 is mostly painless. Some code don't even have to be rewritten and might work on python 3 without any modification. However, some applications requires major migration because their core functionality depends on some feature in python 2 that now changed python 3, and they won't do major refactoring effort until the benefit of migrating to python 3 outweighs staying on python 2. They were essentially waiting until the ecosystem migrated to python 3, but as they're also part of the ecosystem (and often the essential part in their niche), this created a chicken and egg problem that needs a decade to be resolved.

The situation with wayland migration seem to be somewhat similar with the python 3 migration. Many gui apps that uses gui toolkit probably don't need major modification, or no modification at all. But some apps that requires platform-specific access are heavily affected and might require some major refactor, and they probably won't do it until the benefit of migrating to wayland outweigh staying on xorg.

Also, unlike python 3 migration where most of the community agree that the move is justifiable will have to happen eventually, in the case of wayland migration, the community opinion seem to be split which certainly harm wayland migration progress.

I've built Python 3.2 just to show the problem introduced by language designer

    $ python3.2
    Python 3.2.6 (default, Oct 26 2020, 15:29:09) 
    [GCC 10.2.0] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> u"foo"
      File "<stdin>", line 1
        u"foo"
             ^
    SyntaxError: invalid syntax

This is hostile behavior. It took four years to solve (python 3.3), still supported:

    $ python3
    Python 3.8.6 (default, Sep 30 2020, 04:00:38) 
    [GCC 10.2.0] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>> u"foo"
    'foo'

Python got better in supporting old versions over the years. Take a look at Django, it got Python 3 support in February 26, 2013 [1].

> Django 1.5 introduces support for Python 3 - specifically, Python 3.2 and above.

Notice version gap — no support for 3.0, 3.1. It was quite common.

> python 3 migration where most of the community agree that the move is justifiable

If people believed breaking change was justified they would move to 3.0, it did not happen.

I've seen both Python and Ruby community, Ruby made two breaking changes (1.9 and 2.0) while Python got its PEP 414. There was a huge split among developers.

---

Essentially you are describing how switch happened while I'm describing which lessons should have been learned. It is sad if Python community learned nothing.

> the community opinion seem to be split which certainly harm wayland migration progress.

Developers done great job, you can't run 2.7 code in 3.*, you can run X11 applications in XWayland. Is there a split in developers community? All I see is FUD among users.

[1] https://docs.djangoproject.com/en/3.1/releases/1.5/#python-3...

Doesn’t wayland run x11 server as well?

Yes, removed for test

    $ sudo pacman -Rs xorg-server-xwayland

Otherwise X11 applications work fine. GTK+ supports Wayland since 2015

https://wiki.gnome.org/Initiatives/Wayland/GTK%2B

worth noting that in the python 2 to 3 story, a migration path was mostly provided along with tools that tried to automatically refactor your code, the latest 2.x release was supported for nearly a decade, and there have been directions on how to temporarily write code to work on both python2 and python3.

Python 3 is only unusual in its failure. Perl6 Apocalypses [1] is wonderful. Python 3000 is pointless [2].

I've been Python developer at that time, the writing was on the wall. They have not provided migration path. PEP 414 "Complaint: This PEP may harm adoption of Python 3.2" [3], this is insane. Community voted with feet — they've stayed with Python 2 until clean migration path arrived. I've switched to Ruby and been happy since.

Ruby 1.8.7 was supported for five years.

You had to write Python 2 code and run 2to3, you had to live in the past or abandon it.

[1] https://raku.org/archive/doc/apocalypse.html

[2] https://en.wikipedia.org/wiki/History_of_Python#Features

[3] https://www.python.org/dev/peps/pep-0414/