5 ms·

This argument fails when you think of Python2 and Python3 as two distinct languages coincidentally having the same brand name

ASalazarMX 7y ago
Then it doesn't fail. They're nearly identical, it's not like one is Java and the other JavaScript.
loeg 7y ago
Totally. If you've got a legacy Python2 codebase, I'd encourage taking a long hard look at porting to a non-Python family language as an alternative. It's not going to be right for everyone, but it's worth keeping in mind.
- guitarbill 7y ago
  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 :-).
PhantomGremlin 7y ago
To the downvoters, you're wrong! Python3 is a distinct language. This is all you need to know: Python3 broke "Hello, World!" It doesn't get any more fundamental than that.
- cwyers 7y ago
  There are nontrivial programs that run on both Python 2 and Python 3.
  - PhantomGremlin 7y ago
    To quote from chapter 1 of K&R C: "The only way to learn a new programming language is by writing programs in it. The first program to write is the same for all languages:" Print the words hello, world The program to do that is literally the very first program shown in the very first chapter of K&R C. 99% of Python programs before Python3 was announced used the print statement. Python3 broke 99% of existing programs. And your rebuttal is there are---now---nontrivial programs that run in both languages? How many of those nontrivial programs existed before python3 was announced? Zero. Zero programs like that existed. This historical revisionism astonishes me. Just because it is now, after the fact possible to write programs that behave the same in both Python2 and Python3 doesn't mean that they are the same language.
    - takeda 7y ago
      Hehe funny that you mentioned K&R, because hello world in original C no longer compiles in current compilers.
      - PhantomGremlin 7y ago
        Works for me. But maybe OpenBSD 6.2 isn't "current" enough for you? $ cat hello.c main() { printf("hello, world\n"); } $ cc hello.c hello.c:1:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int] main() ^ hello.c:3:2: warning: implicitly declaring library function 'printf' with type 'int (const char *, ...)' [-Wimplicit-function-declaration] printf("hello, world\n"); ^ hello.c:3:2: note: include the header <stdio.h> or explicitly provide a declaration for 'printf' 2 warnings generated. $ ./a.out hello, world $ uname -a OpenBSD foo.example.com 6.2 GENERIC.MP#0 amd64 I think this illustrates my point. OpenBSD did what was necessary to keep the vintage 1978 hello.c program working on a recent system. If only Guido and his colleagues did the same.

ASalazarMX 7y ago

Then it doesn't fail. They're nearly identical, it's not like one is Java and the other JavaScript.

loeg 7y ago

Totally. If you've got a legacy Python2 codebase, I'd encourage taking a long hard look at porting to a non-Python family language as an alternative. It's not going to be right for everyone, but it's worth keeping in mind.

guitarbill 7y ago
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 :-).

PhantomGremlin 7y ago

To the downvoters, you're wrong! Python3 is a distinct language. This is all you need to know: Python3 broke "Hello, World!" It doesn't get any more fundamental than that.

cwyers 7y ago
There are nontrivial programs that run on both Python 2 and Python 3.
- PhantomGremlin 7y ago
  To quote from chapter 1 of K&R C: "The only way to learn a new programming language is by writing programs in it. The first program to write is the same for all languages:" Print the words hello, world The program to do that is literally the very first program shown in the very first chapter of K&R C. 99% of Python programs before Python3 was announced used the print statement. Python3 broke 99% of existing programs. And your rebuttal is there are---now---nontrivial programs that run in both languages? How many of those nontrivial programs existed before python3 was announced? Zero. Zero programs like that existed. This historical revisionism astonishes me. Just because it is now, after the fact possible to write programs that behave the same in both Python2 and Python3 doesn't mean that they are the same language.
  - takeda 7y ago
    Hehe funny that you mentioned K&R, because hello world in original C no longer compiles in current compilers.
    - PhantomGremlin 7y ago
      Works for me. But maybe OpenBSD 6.2 isn't "current" enough for you? $ cat hello.c main() { printf("hello, world\n"); } $ cc hello.c hello.c:1:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int] main() ^ hello.c:3:2: warning: implicitly declaring library function 'printf' with type 'int (const char *, ...)' [-Wimplicit-function-declaration] printf("hello, world\n"); ^ hello.c:3:2: note: include the header <stdio.h> or explicitly provide a declaration for 'printf' 2 warnings generated. $ ./a.out hello, world $ uname -a OpenBSD foo.example.com 6.2 GENERIC.MP#0 amd64 I think this illustrates my point. OpenBSD did what was necessary to keep the vintage 1978 hello.c program working on a recent system. If only Guido and his colleagues did the same.