21–30 of 113 posts
Great idea. A 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.
Serious question: Why would anyone still be doing anything with Python 2.7 except porting the last remnants of their code base to 3.X?
Not all of us have hobby-sized projects on the go.
Does it mean I can only use f''-strings if the target version is 3.5? Why such a limitation?
Serious question: Why would anyone still be doing anything with Python 2.7 except porting the last remnants of their code base to 3.X?
- 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]
I am not a Python developer, but thanks for not using the unnecessary term "transpiler".
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?
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
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_symbolsSerious question: Why would anyone still be doing anything with Python 2.7 except porting the last remnants of their code base to 3.X?
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]
I wonder why isn't "lambda (a, b): a+b" allowed?
Serious question: Why would anyone still be doing anything with Python 2.7 except porting the last remnants of their code base to 3.X?
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]
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.
Earlier quoted context omitted.
Because sometimes the amount of work required to port a 2.7 project to 3.x isn't worth it.
So, then it is a small project that is near end-of-life, and easily replaced?
Serious question: Why would anyone still be doing anything with Python 2.7 except porting the last remnants of their code base to 3.X?
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]