Live data from Hacker News

Python 3 in 2016

hynek.me

91–100 of 194 posts

Re: Python 3 in 2016

#91
Unless it is explicitly necessary to use python 2 (like legacy stuff, that hasn't been upgraded yet), I've been using python 3 solely for almost 2 years, and there is no turning back. I have no reason to stick with the old version.

The last piece that needs to change, to complete the transition, is the majority of OS makers to bundle python3 by default.

Re: Python 3 in 2016

#92
post #40

Earlier quoted context omitted.

I would recommend to even use pyenv ( https://github.com/yyuu/pyenv ) that will allow you to install any Python version in your home directory (i.e. not fucking up your system installation). If you maintain many FOSS libs like I do, together with tox it's priceless.

Homebrew installs software into /usr/local last time I checked so unless you are doing something really strange like manually overwriting system files, you'll be hard pressed to fuck up the whole system. Personally I'd install homebrew into /opt/homebrew.

The real advantage of pyenv is being able to install all interpreters in all versions. If you're developing libraries, you're going to need that.

Re: Python 3 in 2016

#93
post #89

Earlier quoted context omitted.

> or Go. If you like Go, try Nim - it's like Go but without all the dogma. I wrote a blog post about my little Nim project: https://klibert.pl/output/slock_in_nim.html > Why should I choose Python 3 for my new projects? You shouldn't unless it fits all the constraints of your new project. Choosing a language is not, for the most part, a technical decision: sure there are language features and implementation features…

In Nim, isn't it the case that concurrency is thread based? Something I really like about Go is that goroutines are cheap green threads, not full OS threads. This lets me spawn as many goroutines as I like without worrying about exhausting a thread pool.

There is some support for coroutines with async/await (http://nim-lang.org/docs/asyncdispatch.html), but I don't know how mature or functional it is, never tested it. As mentioned, for anything involving concurrency I'd rather use Erlang or Elixir; but it may be a good idea to see how well Nim does in this area.

Re: Python 3 in 2016

#94

I'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…

For anything involving data analysis and scientific computing Python really shines - though I'm often surprised the extent to which web-oriented programmers are unaware of this, I read things like "you can write better web services in Go, therefore Python is obsolete". Python in science is kinda like the One Ring the Binds them - it is the glue that holds together the HPC code at CERN, ESA, NASA, and more, it crunche…

Yeah, I don't know

While Numpy/Scipy is great with a capital G, it seems the underlying infrastructure is flaky.

I'm talking about the messy process of building and installing it. And it seems everything is held with duct-tape

Also it seems that "inside Scipy' it is a different world, and that to really "talk to the outside world" there seems to be a data-translation step needed.

Re: Python 3 in 2016

#95
post #77
post #63

Earlier quoted context omitted.

But you have to build those with its dependencies. And the best thing Go came up with is vendorizing.

And good luck keeping everything updated. (Does go statically link the libc, too? If so, you should be rebuilding all your go applications right now, after the glibc issues reported on Tuesday…)

You can link a Go program completely statically, but it's not the default.

Re: Python 3 in 2016

#96

Earlier quoted context omitted.

For anything involving data analysis and scientific computing Python really shines - though I'm often surprised the extent to which web-oriented programmers are unaware of this, I read things like "you can write better web services in Go, therefore Python is obsolete". Python in science is kinda like the One Ring the Binds them - it is the glue that holds together the HPC code at CERN, ESA, NASA, and more, it crunche…

Yeah, I don't know While Numpy/Scipy is great with a capital G, it seems the underlying infrastructure is flaky. I'm talking about the messy process of building and installing it. And it seems everything is held with duct-tape Also it seems that "inside Scipy' it is a different world, and that to really "talk to the outside world" there seems to be a data-translation step needed.

> "I'm talking about the messy process of building and installing it."

If you're using Python for scientific computing, you can use the Anaconda distribution of Python, it makes it painless to work with those packages.

https://www.continuum.io

> "Also it seems that "inside Scipy' it is a different world, and that to really "talk to the outside world" there seems to be a data-translation step needed."

Python has excellent ORMs, I'm not sure what you're getting at.

Re: Python 3 in 2016

#97
post #14

Since everyone gives anecdotal proofs that Python 3 is just fine, I'll give mine as well. I've migrated to Python3 a rather big project (for the unicode handling) and although it was not quite easy, it'just fine now. I'm active in Qt, web, json, sql domains and I've never needed a library that is Python 2 only. Thus from my own point of view, the Python 3 ecosystem is just complete now. Super.

>Thus from my own point of view, the Python 3 ecosystem is just complete now.

We're mostly seeing the same thing, but there is a few libraries where we maintain forks, because the original author didn't test Python 3 support, but just claimed that it would work. However all but one of these libraries are by commercial companies an solely for integrating their service. For the third one the original author seems to have evaporated (I believe one of my colleague are planning a fork with some of the other users of the library).

Re: Python 3 in 2016

#98

I'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…

For anything involving data analysis and scientific computing Python really shines - though I'm often surprised the extent to which web-oriented programmers are unaware of this, I read things like "you can write better web services in Go, therefore Python is obsolete". Python in science is kinda like the One Ring the Binds them - it is the glue that holds together the HPC code at CERN, ESA, NASA, and more, it crunche…

Two days ago I took a proof-of-concept project written in Python, using the GMPY2 library (Gnu Multiple Precision library), and ported it to C.

My C code was very complicated in order to be fast. Lots of pointer swapping, bit-shifting, etc.

The code was about 4% faster in C, which was more lines of code, much harder to read (and write), compiled with every imaginable flag that could offer a speedup. Switching operating systems, this code was about 8% faster in C on Linux than Python in Windows 10. C in Linux would take about 9.5 days to complete, Python in Windows 10 would be about 10.5 days.

In addition, Python has the "pickle" module so that I can easily make the algorithm save state to pause and restore it any time I want. What's more, I can probably use mmap to share memory easily without making copies and switch to multiprocessing for an even greater speedup (my first attempt using Pool was a little slower despite using 3 cores, but that's the slowest way to multithread).

Re: Python 3 in 2016

#100
post #48

Earlier quoted context omitted.

pypy still has the GIL.

Hopefully not for long: http://doc.pypy.org/en/latest/stm.html

STM isn't magic. Transactions can and will silently fail and you lose your parallelism. You need additional tools to identify and debug failed transactions and you'll need to learn how to structure your code to avoid failed transactions.

This might turn out to be quite difficult for non-trivial Python applications.

STM is exciting but I think it's important to keep in mind that it's an experiment that while promising might still fail in practice.

Post reply on HN