4 ms·

I’m not familiar enough with the python transition to say much. I can think of a few things that the PHP developers did that helped make the transition easier:

I’m not familiar enough with the python transition to say much. I can think of a few things that the PHP developers did that helped make the transition easier: - multibyte aware string functions were implemented as a separate (and optional) extension with separately named functions (prefixed with mb) and there was a popular community polyfill from the Symfony project (and is for many new language functions). - Weird sloppy behaviours (like performing array access on a Boolean, or trying to access a property on null, and many more than would silently just turn into null/false) had lengthy deprecation periods and if you had error logging turned on you could clean these up relatively easily even without a big test suite.

acdha 3y ago
> multibyte aware string functions were implemented as a separate (and optional) extension with separately named functions (prefixed with mb) Python had a different take on this with some interesting psychology: you had a new string type which had to explicitly be converted (i.e. concatenating a Unicode string with a byte string causes an exception), which had a stark divide. Projects which had previously handled Unicode correctly converted almost trivially, but the projects which had been sloppy were a morass trying to figure out where Unicode was desirable and where you really needed raw bytes. Almost all of the code I saw where this was a problem didn’t handle Unicode properly but the developers _hated_ the idea of the language forcing them to fix those bugs.
- LexiMax 3y ago
  There were valid reasons to be upset at Python 3's handling of Unicode. - https://lucumr.pocoo.org/2014/5/12/everything-about-unicode/ https://lucumr.pocoo.org/2014/5/12/everything-about-unicode/ - Discussion: https://news.ycombinator.com/item?id=7732572 https://news.ycombinator.com/item?id=7732572 - https://gregoryszorc.com/blog/2020/01/13/mercurial%27s-journey-to-and-reflections-on-python-3/ https://gregoryszorc.com/blog/2020/01/13/mercurial%27s-journ... - Discussion: https://news.ycombinator.com/item?id=22036773 https://news.ycombinator.com/item?id=22036773 Chalking these complaints up to bad development practices is _precisely_ the reason why the Python 3 migration was handled so poorly. If this attitude is repeated for no-GIL Python, it will fail.

acdha 3y ago

> multibyte aware string functions were implemented as a separate (and optional) extension with separately named functions (prefixed with mb) Python had a different take on this with some interesting psychology: you had a new string type which had to explicitly be converted (i.e. concatenating a Unicode string with a byte string causes an exception), which had a stark divide. Projects which had previously handled Unicode correctly converted almost trivially, but the projects which had been sloppy were a morass trying to figure out where Unicode was desirable and where you really needed raw bytes. Almost all of the code I saw where this was a problem didn’t handle Unicode properly but the developers _hated_ the idea of the language forcing them to fix those bugs.

LexiMax 3y ago
There were valid reasons to be upset at Python 3's handling of Unicode. - https://lucumr.pocoo.org/2014/5/12/everything-about-unicode/ https://lucumr.pocoo.org/2014/5/12/everything-about-unicode/ - Discussion: https://news.ycombinator.com/item?id=7732572 https://news.ycombinator.com/item?id=7732572 - https://gregoryszorc.com/blog/2020/01/13/mercurial%27s-journey-to-and-reflections-on-python-3/ https://gregoryszorc.com/blog/2020/01/13/mercurial%27s-journ... - Discussion: https://news.ycombinator.com/item?id=22036773 https://news.ycombinator.com/item?id=22036773 Chalking these complaints up to bad development practices is _precisely_ the reason why the Python 3 migration was handled so poorly. If this attitude is repeated for no-GIL Python, it will fail.