4 ms·

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

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

> 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 :-).