91–100 of 113 posts
Earlier quoted context omitted.
Because Python 2.7 is, IMO, a better language than Python 3+, e.g.: - I like lambda a, b: a + b syntax better than lambda a_b: a_b[0] + a_b[1] - I prefer map/reduce/filter to return lists rather than iterable - I prefer dict.keys/values/items to return sets/lists rather than iterables, unless I call dict.iter[keys/values/items]
Iterables are so much better on memory though. I wonder why isn't "lambda (a, b): a+b" allowed?
Earlier quoted context omitted.
But isn't that what this is? I was under the impression that a compiler turns source code into machine code whereas a transpiler turns source code into differnet source code?
All compilers turn one form of code into another. Whether that's C to assembly (to machine code), or JavaScript to bytecode to machine code, or Python to Python. Transpiler is just a term referring to a compiler taking one high-level language to another. It's unnecessary because a Coffeescript to JavaScript compiler is a transpiler already; saying "transpiler" there tells you nothing you don't already know.
Earlier quoted context omitted.
That is why I used sys.hexversion. Since there are 3 paths, has real bytes, fake str bytes, and no bytes.
bytes exists since Python 2.6. Do you really need to support anything older?
Quick! Someone inform Zed Shaw!
Please don't. The transpiler route ended very badly for JS. Let's not open this pandora box for Python.
Earlier quoted context omitted.
Because it's going to be stable for the next N years. Python 2 is like FORTRAN. It might not be sexy anymore but it's not going anywhere.
> Python 2 is like FORTRAN. It might not be sexy anymore but it's not going anywhere. Except Fortran is, and is going to be, further developed. (So, if a new useful programming concept appears, or a major design mistake is discovered, it always can be patched.) Python 2 is going to be abandoned in 2020. Python 3 will supersede it.
Earlier quoted context omitted.
> Because Python 3.X is not backwards compatible and we have millions of lines of production code in Python 2.X. I believe the common subset of Python 2 and 3 was created to ease that transition.
That common subset doesn't include string handling.
Earlier quoted context omitted.
Asking this question without disqualifying the answer "No breaking changes whatsoever" usually just generates a bunch of different ways of phrasing that.
No, I don't buy that. IBM successfully transitioned a huge customer base from 709/7090 36-bit words to System 360 32 bit words. The transition from 32 to 64 bit addresses was rocky for a lot of architectures. DEC Alpha, Intel Itanium. But are you still running a 32 bit OS? K&R C no longer compiles. Not that the C to C++14 transition is what I would call an example of greatness, but it is somewhere along the success s…
foo@virt-ubuntu:~/c$ gcc --version
gcc (Ubuntu 6.3.0-12ubuntu2) 6.3.0 20170406
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
foo@virt-ubuntu:~/c$ cat 'k&r.c'
#include
int main(argc, argv)
int argc;
char *argv[];
{
puts("hello, world!");
return 0;
}
foo@virt-ubuntu:~/c$ gcc 'k&r.c'
foo@virt-ubuntu:~/c$ ./a.out
hello, world!Earlier quoted context omitted.
> Python 2 is like FORTRAN. It might not be sexy anymore but it's not going anywhere. Except Fortran is, and is going to be, further developed. (So, if a new useful programming concept appears, or a major design mistake is discovered, it always can be patched.) Python 2 is going to be abandoned in 2020. Python 3 will supersede it.
FORTRAN 77 is just as likely to be abandoned in 2020 as well. And?
Earlier quoted context omitted.
Because it's going to be stable for the next N years. Python 2 is like FORTRAN. It might not be sexy anymore but it's not going anywhere.
> Python 2 is like FORTRAN. It might not be sexy anymore but it's not going anywhere. Except Fortran is, and is going to be, further developed. (So, if a new useful programming concept appears, or a major design mistake is discovered, it always can be patched.) Python 2 is going to be abandoned in 2020. Python 3 will supersede it.
Elsewhere in the thread xrange has mentioned Tauthon. And there are more Python 2 interpreters than just the main C Python.
Pypy may stop supporting 2 syntax officially, but I doubt it. Since it never changes, there's next to no overhead to keeping it available.
And further, if your language isn't changing then maintenance and debugging become much easier. Conceivably the codebase(s) can asymptotically approach 100% correctness.
O_o