3 ms·

well, in theory you're right, but it isn't like the transition from python 2 to 3 requires a complete rewrite. it was fairly easy to write (mostly) compatible c

well, in theory you're right, but it isn't like the transition from python 2 to 3 requires a complete rewrite. it was fairly easy to write (mostly) compatible code, via __future__, u"", and maybe six. it's a bit unrealistic to think that if someone hasn't put the effort in to do that, they'll expend the effort on porting it to a different language, unless it also makes sense for other reasons

loeg 7y ago
Depends how good your test coverage is, I guess. The legacy Py2 codebase I have the most familiarity with is probably more than 50% C extensions with zero tests, and migrating those to Python 3 correctly is non-trivial. If you've now got to write a bunch of tests, you might as well test a reimplementation in a language with a history of more API stability.
- guitarbill 7y ago
  i hear you, but at that point, it isn't really a Python codebase. i think that qualifies as a good reason to migrate away from Python, since if you've ended up with that many C extensions, Python probably wasn't the best fit to begin with. bitching about unicode, the print function, etc, i'm less sympathetic. the only thing that's weird to me is if you have C extensions, it's super easy writing tests for those in Python. getting coverage is possible via gcov/lcov. retrofitting tests is hard and painful in any language, period. but so is a rewrite. pick your poison.
  - loeg 7y ago
    > i hear you, but at that point, it isn't really a Python codebase. I don't think that's really true. Yes, our overall product is a mixed language codebase, with most of the core functionality in C. But quite a lot of the business logic lives in Python. The C modules are all just manually implemented wrappers of C libraries (as opposed to, say, rewrites to speed up slower Python hot paths). By sheer quantity, it's something like 110k lines of manual C wrappers and 2.0 million lines of Python2. So from a numbers perspective, it seems like the Python part is very much a Python codebase. (Though the whole product is about 19 million lines of C, 3 million lines of C++, and negligible percentages of other languages beyond Python2.) > if you've ended up with that many C extensions, Python probably wasn't the best fit to begin with. Not sure I'd agree with that, either :-). Although I guess it depends on how you define "begin." The initial manual wrappers were written in the early 2000s. At the time, Python (like, version 2.3?) made a lot of sense for CLI / business logic / initial web interface backend, interacting with the core libraries via the wrappers. It's not like any of the contemporaneous languages the original authors (now long gone) could have picked would have fit better or held up better over time. C++98 isn't the C++1y we have today and simply isn't a replacement for Python; other scripting languages were demonstrably worse (Perl, Tcl, ...). I don't know why those folks chose to manually implement wrappers (maybe it predated SWIG), but it's what we're working with now. > the only thing that's weird to me is if you have C extensions, it's super easy writing tests for those in Python. Same as anything else, really. If your code is pure algebraic functions, unit testing is trivial; if it has lots of system-level side effects or isn't decomposed into testable units, it's difficult to retrofit. > retrofitting tests is hard and painful in any language, period. but so is a rewrite. pick your poison. You're not wrong :-).

loeg 7y ago

Depends how good your test coverage is, I guess. The legacy Py2 codebase I have the most familiarity with is probably more than 50% C extensions with zero tests, and migrating those to Python 3 correctly is non-trivial. If you've now got to write a bunch of tests, you might as well test a reimplementation in a language with a history of more API stability.

guitarbill 7y ago
i hear you, but at that point, it isn't really a Python codebase. i think that qualifies as a good reason to migrate away from Python, since if you've ended up with that many C extensions, Python probably wasn't the best fit to begin with. bitching about unicode, the print function, etc, i'm less sympathetic. the only thing that's weird to me is if you have C extensions, it's super easy writing tests for those in Python. getting coverage is possible via gcov/lcov. retrofitting tests is hard and painful in any language, period. but so is a rewrite. pick your poison.
- loeg 7y ago
  > i hear you, but at that point, it isn't really a Python codebase. I don't think that's really true. Yes, our overall product is a mixed language codebase, with most of the core functionality in C. But quite a lot of the business logic lives in Python. The C modules are all just manually implemented wrappers of C libraries (as opposed to, say, rewrites to speed up slower Python hot paths). By sheer quantity, it's something like 110k lines of manual C wrappers and 2.0 million lines of Python2. So from a numbers perspective, it seems like the Python part is very much a Python codebase. (Though the whole product is about 19 million lines of C, 3 million lines of C++, and negligible percentages of other languages beyond Python2.) > if you've ended up with that many C extensions, Python probably wasn't the best fit to begin with. Not sure I'd agree with that, either :-). Although I guess it depends on how you define "begin." The initial manual wrappers were written in the early 2000s. At the time, Python (like, version 2.3?) made a lot of sense for CLI / business logic / initial web interface backend, interacting with the core libraries via the wrappers. It's not like any of the contemporaneous languages the original authors (now long gone) could have picked would have fit better or held up better over time. C++98 isn't the C++1y we have today and simply isn't a replacement for Python; other scripting languages were demonstrably worse (Perl, Tcl, ...). I don't know why those folks chose to manually implement wrappers (maybe it predated SWIG), but it's what we're working with now. > the only thing that's weird to me is if you have C extensions, it's super easy writing tests for those in Python. Same as anything else, really. If your code is pure algebraic functions, unit testing is trivial; if it has lots of system-level side effects or isn't decomposed into testable units, it's difficult to retrofit. > retrofitting tests is hard and painful in any language, period. but so is a rewrite. pick your poison. You're not wrong :-).