5 ms·

A lot of Mercurial's issues would have been resolved much easier if they'd used the common tools for maintaining polyglot 2/3 code instead of trying to invent e

A lot of Mercurial's issues would have been resolved much easier if they'd used the common tools for maintaining polyglot 2/3 code instead of trying to invent everything themselves. Futurize and Pasturize in particular provide essentially all of the features that this post laments missing. https://python-future.org/ https://python-future.org/

lacker 7y ago
The author does touch on that. When Mercurial accepts a 3rd party package, downstream packagers like Debian get all hot and bothered and end up making questionable patches to our source code. Some environments just can't use dependencies like this. IMO Python 3 was too much of a breaking change, and in particular, the ability to transition from 2 to 3 should have been better in Python itself.
- j88439h84 7y ago
  Six, for example, is designed to be a single file -- specifically to ease copying it directly into the code base. But the idea that Mercurial couldn't use dependencies because of fear for what Debian might do...I find it so hard to believe that's the best choice. Vendor if you must, but do not reinvent the wheel.
  - masklinn 7y ago
    Having done so, six really is not necessary for a transition. We went with forking werkzeug's minimalist compat file because six was waaay overkill, and that made it easier to progressively rip it out later. python-future is invaluable for the fixers (which are way better than 2to3's), the runtime stuff you can easily do without.
untitaker_ 7y ago
Those tools were not popular at the time for sure. I remember that Python-Future only got traction sometime after Flask has been ported to Python 3.
- j88439h84 7y ago
  FWIW, Flask supported Python 3 in 0.10.1, released 2013-06-14 and Mercurial started porting in 2015.
deleted 7y ago
[deleted]
morelisp 7y ago
The first versions of Flask that supported Python 3 absolutely tanked performance. Some memory k/v store esque APIs we had that spent a good chunk of their time processing headers / query params to know what keys to look up got something like 8x slower. I remember ripping all the logic out of one endpoint and finding out it was >1ms minimum round trip, something like 85% of the time spent switching pure ASCII back and forth in six. It's a shame, because I absolutely love Flask, but we couldn't tolerate that so new APIs ended up in other languages. I can't imagine what it would do to Mercurial's performance to have picked the wrong migration library early on.

lacker 7y ago

The author does touch on that. When Mercurial accepts a 3rd party package, downstream packagers like Debian get all hot and bothered and end up making questionable patches to our source code. Some environments just can't use dependencies like this. IMO Python 3 was too much of a breaking change, and in particular, the ability to transition from 2 to 3 should have been better in Python itself.

j88439h84 7y ago
Six, for example, is designed to be a single file -- specifically to ease copying it directly into the code base. But the idea that Mercurial couldn't use dependencies because of fear for what Debian might do...I find it so hard to believe that's the best choice. Vendor if you must, but do not reinvent the wheel.
- masklinn 7y ago
  Having done so, six really is not necessary for a transition. We went with forking werkzeug's minimalist compat file because six was waaay overkill, and that made it easier to progressively rip it out later. python-future is invaluable for the fixers (which are way better than 2to3's), the runtime stuff you can easily do without.

untitaker_ 7y ago

Those tools were not popular at the time for sure. I remember that Python-Future only got traction sometime after Flask has been ported to Python 3.

j88439h84 7y ago
FWIW, Flask supported Python 3 in 0.10.1, released 2013-06-14 and Mercurial started porting in 2015.

deleted 7y ago

[deleted]

morelisp 7y ago

The first versions of Flask that supported Python 3 absolutely tanked performance. Some memory k/v store esque APIs we had that spent a good chunk of their time processing headers / query params to know what keys to look up got something like 8x slower. I remember ripping all the logic out of one endpoint and finding out it was >1ms minimum round trip, something like 85% of the time spent switching pure ASCII back and forth in six. It's a shame, because I absolutely love Flask, but we couldn't tolerate that so new APIs ended up in other languages. I can't imagine what it would do to Mercurial's performance to have picked the wrong migration library early on.