|
|
|
|
|
by ecma
3384 days ago
|
|
Having been involved in several large scale (10s KLOC) source ports from Python 2 to 2/3 compat, I can say that IME it is trivial to make a mistake when handling these kind of changes. The complexity and regression risk is entirely dependent on the complexity of the codebase and I wouldn't be surprised if that factored fairly heavily into the Mercurial package teams' thought processes. The case for spending valuable people time on the harder problems in their codebase seems like a valid choice if the scale is large. TBH I wish I'd known about this a year ago... It's also worth noting that the end goal may also not align with valid intermediate goals. I often found myself fretting about where to pivot to using a byte literal prefix, where to accept an unprefixed literal (to get pre-3.5 % formatting since the codebase used that in some places) and where I explicitly needed a unicode literal prefix (and dealing with the headache of what to do if we cared about 3.2 - the brief wasn't specific enough at first). Just $0.02, I think everyone's experience, expectations and desire for purity will be different for porting efforts. It's worth noting that my porting work was supported by a large number of anally retentive unit and regression tests which made the effort much more frustrating but a heck of a lot more obvious when we messed it up! |
|