3 ms·
Python 3 changed nothing * print is function * string is unicode by default Should have been clean and easy migration path # python 2 from __future_
by sergeykish 6y ago
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/ https://www.python.org/dev/peps/pep-0414/
[2] https://www.python.org/downloads/ https://www.python.org/downloads/
[3] https://medium.com/rubycademy/the-evolution-of-ruby-strings-from-1-8-to-2-5-8b2ed8f39fad https://medium.com/rubycademy/the-evolution-of-ruby-strings-...
[4] https://www.ruby-lang.org/en/downloads/releases/ https://www.ruby-lang.org/en/downloads/releases/
[5] https://developer.gnome.org/gtk3/stable/gtk-getting-started.html https://developer.gnome.org/gtk3/stable/gtk-getting-started....
- vnlab 6y ago> 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.
- sergeykish 6y agoFrom 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.
- neurostimulant 6y agoJust 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.
- sergeykish 6y agoI'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-support https://docs.djangoproject.com/en/3.1/releases/1.5/#python-3...
- AzzieElbab 6y agoDoesn’t wayland run x11 server as well?
- sergeykish 6y agoYes, 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 https://wiki.gnome.org/Initiatives/Wayland/GTK%2B