It's quite possible that someone will come up with a good enough automatic 2->3 converter which alleviate the situation.
2to3 (comes bundled with Python) will do some of the work for you.
Python 3 in 2016
41–50 of 194 posts
Re: Python 3 in 2016
#42I've done a lot of Python for many years and its all been Python 2. Python 3 seems to be a decent improvement, and if I was working on a Python 3 project, that would be fine. But when it comes to new projects, I struggle to find a compelling reason to use Python at all, when there are so many amazing languages now to choose from. With a new project you could choose Scala, Haskell, Clojure, Erlang (or Elixir) or Go. A…
Noob question: What's so difficult about deploying/distributing python?
ATM it takes work to create a deployable artifact.
We package virtualenvs using fpm, others use Docker. But Go just spits out a single binary you can scp anywhere (the build process OTOH is more painful IMHO).
That’s why I’m highly curious about https://us.pycon.org/2016/schedule/presentation/2122/ .
Re: Python 3 in 2016
#43I've done a lot of Python for many years and its all been Python 2. Python 3 seems to be a decent improvement, and if I was working on a Python 3 project, that would be fine. But when it comes to new projects, I struggle to find a compelling reason to use Python at all, when there are so many amazing languages now to choose from. With a new project you could choose Scala, Haskell, Clojure, Erlang (or Elixir) or Go. A…
Pick Python for the sheer amount of libraries that's available. Not just for web stuff, where Node.js and Ruby do fine, but also for scientific work, for statistics, for embedded work (Raspberry Pi or MicroPython), for systems administration, for command-line tools, for really just about anything you can imagine. And you can do all of those things while not having to switch contexts between different syntaxes and different standard libraries for basic things like regular expressions or HTTP requests.
Picking the best tool for the job often gets in the way of actually getting things done. Python is the true swiss army knife of today's programming languages.
Re: Python 3 in 2016
#44I've done a lot of Python for many years and its all been Python 2. Python 3 seems to be a decent improvement, and if I was working on a Python 3 project, that would be fine. But when it comes to new projects, I struggle to find a compelling reason to use Python at all, when there are so many amazing languages now to choose from. With a new project you could choose Scala, Haskell, Clojure, Erlang (or Elixir) or Go. A…
I never thought I'd say it, but I'm loving programming the new ES2105 version of JavaScript. It really has a great deal in common with Python now. Clearly many programming languages are converging as they implement common good ideas from other programming languages. That's going to mean that whilst Python might have distinguished itself in the past for being streets ahead, in the future it's likely that many language…
The "all async" model of Node kills it for practical programming compared to Python...
And the worst thing is, Node/v8's JIT would kill Python in performance for a;; the kind of things people write Python scripts for, even if it run all synchronous.
It would be nice if callbacks/promises/async-await were only optional and for network/web things, not for everything.
Re: Python 3 in 2016
#45I've done a lot of Python for many years and its all been Python 2. Python 3 seems to be a decent improvement, and if I was working on a Python 3 project, that would be fine. But when it comes to new projects, I struggle to find a compelling reason to use Python at all, when there are so many amazing languages now to choose from. With a new project you could choose Scala, Haskell, Clojure, Erlang (or Elixir) or Go. A…
If you are building an application which does a lot of machine learning and statistics, I don't see a better language than Python. It has so many libraries to use for it. Note, I love R, but I can't imagine building an application with it.
Re: Python 3 in 2016
#46Since it's basically all anecdotal, I'll say my gazing-into-the-crystal-ball educated-guess feeling that Python 4 will make the entirety of Python about as popular as Perl is today if: it doesn't get rid of GIL and at the same time implement a JIT compiler, and at the same time remain 100% .py source-code compatible with Python 3. The developers have dug themselves into this mess with frivolous differences ("print" a…
Comments like this are so misguided and yet so common on HN. Adding a freaking JIT to CPython is a ridiculous suggestion that will never happen for a whole load of reasons. Getting rid of the GIL is more noble, but seems impossible to do without breaking compatibility. Python 4 will just be the next release after Python 3.9.
Getting rid of the GIL is more noble, but seems impossible to do without breaking compatibility.
The problem isn't just breaking compatibility, it's performance. There have been a number of experiments with removing the GIL going back (I think) to python 1.4. However every attempt has led to significant performance degradation in some part of the language.
Re: Python 3 in 2016
#47Earlier quoted context omitted.
I often dabble in other languages but in the end always return to python (3). What it offers for me truly is the batteries included and easy, memorable and predictable syntax. (Probably due to experience). Sure, Go is easier to deploy, Erlang and by extension Elixir are easier to scale. But python does align very well with my personal though process. I don't think parallel and I don't have race conditions in my mind.…
>Sure, Go is easier to deploy Go's lack of a package manager making deployment more painful is the thing that made me come back to python.
Go is staticly linked, you don't need to deploy packages, just the binary.
Re: Python 3 in 2016
#48Since it's basically all anecdotal, I'll say my gazing-into-the-crystal-ball educated-guess feeling that Python 4 will make the entirety of Python about as popular as Perl is today if: it doesn't get rid of GIL and at the same time implement a JIT compiler, and at the same time remain 100% .py source-code compatible with Python 3. The developers have dug themselves into this mess with frivolous differences ("print" a…
> "it doesn't get rid of GIL and at the same time implement a JIT compiler, and at the same time remain 100% .py source-code compatible with Python 3." Guido could do that if he decided that Python 4 would be based on PyPy (AFAIK, many people thought Python 3 would be based on PyPy too). Compatibility isn't 100% but if it was the main platform I'm sure it'd improve even faster.
pypy still has the GIL.
Re: Python 3 in 2016
#49We are using Python LDAP library[1] at work, but it is not available for Python 3 yet. Is there an alternative? 1 https://pypi.python.org/pypi/python-ldap/
ldap3 is not API-compatible with python-ldap, but it's pure-Python (it doesn't need the OpenLDAP libraries installed) and you might find its API is a bit nicer to use:
Re: Python 3 in 2016
#50Since it's basically all anecdotal, I'll say my gazing-into-the-crystal-ball educated-guess feeling that Python 4 will make the entirety of Python about as popular as Perl is today if: it doesn't get rid of GIL and at the same time implement a JIT compiler, and at the same time remain 100% .py source-code compatible with Python 3. The developers have dug themselves into this mess with frivolous differences ("print" a…
> "it doesn't get rid of GIL and at the same time implement a JIT compiler, and at the same time remain 100% .py source-code compatible with Python 3." Guido could do that if he decided that Python 4 would be based on PyPy (AFAIK, many people thought Python 3 would be based on PyPy too). Compatibility isn't 100% but if it was the main platform I'm sure it'd improve even faster.
There is also pyston, which is a 'competing' LLVM backed JIT that Dropbox is working on. Guido also happens to be working at Dropbox, but I don't know if he's directly involved with pyston or not.
AFAIK, many people thought Python 3 would be based on PyPy too
Don't think so. Some people hoped that Python 3 might be based on Unladen Swallow, which was a different Python JIT that Guido was working on while at Google, but that project never really got off the ground and Google seemed to lose interest in it.