No, thanks. When I move away from Python 2, I’ll go to Nim or Rust, not Python 3.
The reason is that I might as well get some real carrots along with the trouble: efficient use of resources (both CPU and RAM), proper static typing with sane type inference, generics, metaprogramming, modern parallelism mechanisms, etc.
Good Unicode is not enough. It never was.
Do you realize that migrating code base to Nim ou Rust from python 2 is several order of magnitude more painful than to python 3 ?
Moreover both of them will far from having an ecosystem comparable to python ecosystem at the 2020
Of course all that depend on your use cases.
That’s interesting. I had been programming in Java for most of my life, and I moved to Python a couple of years ago. I really love it, the syntax, list comprehensions, the tooling.
However, I’m Spanish and have to deal with Unicode constantly. It’s crazy. I was fed up of doing .encode('utf8') and .decode('utf8'), tried to move to Python 3 (which is honestly not a big deal) but many libraries don’t support it, if even for some print statements.
Since I’m in love with list comprehensions, map, apply, and high order functions, I’m exploring Elixir. It suits me perfectly as it’s massively concurrent, fault-tolerant and distributed, perfect for my use cases. The tools are awesome, mix and Phoenix are both very young but modern and fast. Unfortunately, there aren’t many libraries available, and you can’t just look for answers in Stack Overflow, you have to actually RTFM and sometimes even the implementation in the sources.
Where am I going with this small rant? Well, as you were saying, when you start exploring other stuff and invest your time (I’ve spent a couple weeks studying Elixir) you want to leapfrog, not just some incremental improvement.
I felt that Java -> Python was a leapfrog. Python -> Elixir also looks like it. Python2 -> Python3… not that so. Still has the PIL, async is nice but not as cool as Task.Supervisor, and regarding Unicode, well, it’s already 2016, right?
Python3 is what Python2 should have been. It doesn’t feel as modern as new stuff like Elixir, Rust or Nim. And unfortunately it lacks a lot of libraries which are available for Python2.
If I’m going to write library code myself, I see no point in using Python3. I’ll just use something else which will be more useful in the future.
PS: Writing a language is a titanic task and all developers have my absolute respect. The bottom line is that brain power and sweat should be preceded by thorough planning and roadmapping, or it feels like a bit of a waste
Do you have any requirements or are you free to use any language you want? .NET friendly languages are Unicode aware, so I was going to recommend F#.
I’m free to chose language, but would like to move away from the “enterprisey” world (Java, .NET, etc)
Easy massive parallelism is a requirement since we are building chat bots. Elixir is just perfect for the job. Pity that there aren’t good NLP libraries yet.
Still has the PIL
Did you mean the GIL (Global Interpreter Lock) instead of PIL?
If Python 2 worked for your use-case I can’t imagine wanting to move to a language that doesn’t have the luxury of GC. Having to reason about object lifetimes is a major pain in the ass and most of the time you Just. Don’t. Care. I have to ask: have you ever used Rust for something non-trivial?
(I think Rust is a great language and I am using it to implement the runtime system for a research PL I am developing. But unless one of my explicit requirements was “no GC” (like it is here), I wouldn’t use Rust. YMMV)
I had the feeling until I had logic that was hard to implement in the ownership model.
Also I kind of miss an ML syntax for Rust :-)
have you ever used Rust for something non-trivial?
Not Rust, but I did use Nim and I actually plugged in gccgo'c garbage collector in it (along with the rest of the Go runtime, so I can have goroutines and channels) - https://github.com/stefantalpalaru/golib-nim
Metaprogramming already exists in Python, and Python 3’s asyncio can definetly be called a “modern parallelism mechanism”. If static typing and efficient use of resources are most important to you, I don’t understand why you chose Python for your project to begin with. But maybe you don’t know yourself and just follow a trend without having made a proper cost/benefit analysis.
Metaprogramming already exists in Python
Are you confusing metaprogramming with metaclasses?
Python 3’s asyncio can definetly be called a “modern parallelism mechanism”
I’m pretty sure that’s just a concurrency mechanism.
No. I really don’t see how Python’s metaprogramming capabilities are inferior to Rust’s.
Then I don’t understand what you want.
If you want to understand, start by reading the Wikipedia page on metaprogramming I just linked. After you become familiar with this new concept, look for articles/presentations on the differences between concurrency and parallelism.
[Comment removed by author]
Metaprogramming that only works at import time and targets an AST that is guaranteed to change at the next release? Works as a proof of concept, but not as something you’d actually propose with a straight face.
Rust’s syntax extension API is not available in stable releases, changes almost every nightly and metaprogramming in general works only at compile time.
Yes, Rust has macros, but those are less powerful than just executing arbitrary code at import time.
We are already switching for new projects and even migrated one older to Python3 recently. Good unicode is enough.
Not much new in this post, but I agree that it’s scary that Python 2.7 will only be supported for three more years.
The main reasons I think it’s worth moving to Python 3 are:
Brett Cannon wrote a good pitch here as well.
Check out the official guide which includes a link to the 2to3 tool.
I wasn’t previously aware of tracemalloc. Thanks for the link!
In my experience the hardest part about python 2/3 is for library developers in maintaining a code base compatible with the both of them.
Migrating user code requires some effort but is rather straightforward in most cases, maybe with the exception of encoding handling, where python3 is more restrictive
On the other hand most code where porting is hard due to encoding stuff is either (1) complex in itself or (2) was probably somewhat buggy in python 2.
We are now in a situation where most libs are compatible and with python 3.4 porting got even easier, thus if we don’t start migrating on 3.4+, we risk a split of the python community.
But well they shouldn’t! This strange idea is exactly what keeps Python 2 around for all these years. For some reason library maintainers decided to take that burden upon themselves instead of developing new code for Python 3 only and create an incentive to switch for their users.
Well, python 3.0 and 3.2 were not exactly as production ready as 2.7…