"Why should I switch to 3.x?" You haven't provided a reason to switch.
I don't know if it was your intent, but your question assumes that Python 3.x is the "default", and that there is some sort of obligation to use it instead of 2.x. That's a premise that a lot of people do not share.
As an example, they may not view 3.x as an "upgrade", but as a different language. So you might as well ask anyone doing work in one language "What reason is there for you to still use language X? Why not use language Y?"
As long as some team is willing to support Python 2.7 (and possibly backport non-breaking features), 2.7 will live on, and there is no reason it should go away. The only strong reason for many to switch to 3.x is "I have a library I need to use that is supported only in 3.x". Or "I need to hire developers, and I can't find people who know 2.x, but I can find those who know 3.x"
Languages are tools. As long as the tool is more than adequate for the task, the burden is on others to justify a change in tool.
Writing new code in Python 2 is completely nuts and just makes everyone's life harder (including your own).
Just to put a stake in the ground, when did FreeCAD start? When did 3.0 come out, along with the announced end-of-life date for 2.7?
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.
I hate it because Python2 is a flaming garbage heap, and 2.7 is what happens when you piss on a flaming garbage heap to put it out, whereas Python 3 is actually a nice language to work in, but until OS distributions get their act together on the Python front, some stuff is going to continue sucking.
I worked in Python 2 daily for about a year and a half (doing side stuff in 3), and switched over to Python 3 a few months ago. It's just not that big of a deal. Maybe it's because I'm pretty shielded from the madness of strings vs. bytes (or just import from future).
Not all of us have hobby-sized projects on the go.
I'd really like to understand this from a technology transition management standpoint.
If you'll allow a strained analogy, the 2.7 to 3.x transition appears in retrospect like an exercise in herding cats, because the transition was done using cat-herding style incentives. What should have been done differently to make the transition into greyhounds chasing a rabbit? What should the rabbit have been?
Any technology that lives long enough eventually has to transition its customer base. I'm trying to learn to identify rabbits.
Slightly tangential but system ruby is stuck at 2.0.0p648 (which is well into unsupported) and perl v5.18.2 (which I don't know the status support of but is old enough to wonder).
They might as well rip them out and make them an optional package like CLI dev tools for possible backwards compatibility needs (easily installable either with something like xcode-select --install or the java/javac stubs).
I don't really see the benefit of a Python 3.6 to 2.7 transpiler/compiler though. More realistically I would require that all new code be both 2 and 3 compatible, for when the eventual migration will happen. This isn't necessarily and easy task either, but then you're only depended on the Python project, not some random transpiler that might not see further development.
- 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]
It already works this way.
Python 3.6.1 (v3.6.1:69c0db5, Mar 21 2017, 17:54:52) [MSC v.1900 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> add = lambda a, b: a + b
>>> add(1, 2)
3
You can produce a list from any iterable by passing it to `list()`. You cannot take a materialized list and make it lazy though.
> I prefer dict.keys/values/items to return sets/lists rather than iterables, unless I call dict.iter[keys/values/items]
Why? Sets are mutable. What happens when you mutate dict.values? It doesn't make sense.
l = lambda (a, b): a + b
l((1, 2))
With regard to the second point, I also would have liked a more "gradual" step there, I find myself (especially in REPL environments) often doing `list(map(sth, sth))`. A `mapi`, `filteri` or something like this would probably not be zenny enough.
Both don't pose very strong points for python 2 > 3.
uh, `lambda a,b: a + b` works in 3.6...
> I prefer ... to return lists rather than iterable:
Why? I'm just curious. Iterables are much more flexible than lists, unless you need random access... at which point list(...) works pretty well.
I wonder why isn't "lambda (a, b): a+b" allowed?
That works perfectly well in Python 3, you're thinking about `lambda (a, b)` aka `def foo((a, b))` aka tuple-parameter unpacking.
> - I prefer map/reduce/filter to return lists rather than iterable
1. why? 2. just wrap them in a list() call?
> - I prefer dict.keys/values/items to return sets/lists rather than iterables, unless I call dict.iter[keys/values/items]
You are aware that Python3's keyviews and itemsviews are sets but P2's are just lists right?
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.
That's nonsensical since it solves a completely unrelated problem.
2to3 was conceived of as a one-shot migration tool for Python 2 codebases. Not as a way to build cross-version Python, and not as something to use repeatedly (which it why it is relatively simplistic and fallible), just as a way to take an existing codebase and handle the first 90% of migrating to Python 3, leaving you with the second 90%.
2to3 was _conceived_ of as migration tool, as if evolutionary lineages just all stopped, changed their genome and restarted. Except it only refactored some easy stuff and let the rest fall on the floor.
Six has had way more impact than 2to3. It was only because core Python said running a single 2/3 codebase was UnPythonic that people didn't embrace it sooner. Running a single codebases across both 2 and 3 is now the defacto technique.
Writing in 3 and "compiling down" to 2 gets people writing 3 which is the point, even if they can't run CPython3.
If I were writing a library that needed both 2 and 3 compatibility, I would prefer to write Python 3 code and then run 3to2 on it, rather than going the other way. My own solution is to fork the library, provide only bug fixes for the 2.x version and do all new development in Python 3 only. Porting has taken some effort but not as much as I feared. In retrospect, I'm happy to have invested the time.
I suspect this may be easier to achieve with JS than other languages because its prototypical nature makes it easy to compose dependencies. However, there is certainly a lot that other communities can learn from the JS community's solutions to this problem.
In theory more than practice. For example if you use array destructuring (`[x, y] = something`) and Babel cannot verify that `something` is always an array it inserts a 664 character function that handles generators and other things. That adds performance and size overhead (grep for _slicedToArray in your compiled js files), when all you really want is `x = something[0]...`
https://babeljs.io/repl/#?babili=false&evaluate=true&lineWra...
The only reason the Python 2/3 issue exists is because of just enough breaking backwards compatibility in a way that a lot of people didn't agree with in the community. This isn't a thing in Ruby.
So the goal should be to have codebases in Python 3.
> python3 should be the input and not the output
How would this accomplish that goal? All the codebases would be in Python 2 then. I bet that removing barriers to run Python 2 code would cause it to stay around longer.
So rustc is a transpiler when using the emscripten backend but not when using the native backend? How does that even make sense?
Compilers are computer programs that translate a program written in one language into a program written in another language.
Example of a compiler in action.
$ cat hello.c
#include <stdio.h>
int main(void)
{
printf("hello world\n");
return 42;
}
$ cc -O3 -S hello.c -o -
.section __TEXT,__text,regular,pure_instructions
.macosx_version_min 10, 12
.globl _main
.align 4, 0x90
_main: ## @main
.cfi_startproc
## BB#0:
pushq %rbp
Ltmp0:
.cfi_def_cfa_offset 16
Ltmp1:
.cfi_offset %rbp, -16
movq %rsp, %rbp
Ltmp2:
.cfi_def_cfa_register %rbp
leaq L_str(%rip), %rdi
callq _puts
movl $42, %eax
popq %rbp
retq
.cfi_endproc
.section __TEXT,__cstring,cstring_literals
L_str: ## @str
.asciz "hello world"
.subsections_via_symbolsA writeup on how you handled mapping bytes, bytearrays, unicode, etc, to 2.7 constructs would be interesting.
In code that supports both 2 and 3, I end up with ugly stuff testing sys.hexversion to deal with 3rd party libraries, like pyserial, that expect str in v2, bytearrays in v3.
As I mentioned elsewhere, I created "ppython" to handle these two porting problems. The source code is on github: https://github.com/nascheme/ppython . If someone needs a Windows binary, I could build it if you ask politely. ;-) For my project, it has been a useful tool to speed up porting.
Porting code is not trivial and there is huge amount of Python 2 out there. I wish more effort had been spent building tools to help porting of code. Even simple things like disallowing the 'u' prefix on strings in Python 3 was a big mistake. Mostly those things have been corrected but it is still going to take a very long time to move the majority of the community to Python 3. There will be Python 2 running for the next 50 years easily, I'm sure, maybe 100 years. At least Python is open source and you will not be stranded like VB developers where when MS drastically changed Visual Basic.
if sys.version_info >= (3,):
... # Python 3.X code
if str is bytes:
... # Python 2.X codeI never was able to find anyone talking about that goal with mypy, but it looks like this tool may be a solution.
Does it mean I can only use f''-strings if the target version is 3.5? Why such a limitation?
That's my guess, anyway.
Python 2 is near end if life anyway.