Live data from Hacker News

Python 3 in 2016

hynek.me

111–120 of 194 posts

Re: Python 3 in 2016

#111

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…

Python is still king for really boring and maintainable scripts. I mean boring in the best way. Every Python script o read is clean and elegant. It's easy to follow and well organized. Python 3 doesn't seem to make it any better at this. In fact all Python3 does is annoy me. I never know when I need it or not, it never seems to be clear either. The fact that it's packaged as a separate entity (i.e. /user/local/bin/python3) is even weirder.

Mastering Python-foo is still on my todo list, though. As a Ruby user, I've noticed that Python scripts are much more straight forward and maintable. I still write my scripts in Ruby though because nobody seems to mind. This is perhaps because I try my best write good comments. In general, Ruby is better as Perl replacement than a Python substitute. In fact, one of my coworkers who is an oldschool perl scripters was sold on Ruby over Perl just by reviewing one of my scripts. I think the issue is people don't think of Ruby outside of Rails, where it's basically a readable purely object oriented Perl.

As an aside, I think there is a bigger overall problem of using scripting languages for application development. I wouldn't use Python, Ruby, or Perl for anything that was more than, say, 500 lines. I almost cried when I tried to read the code for homebrew. Not that it's bad code (it's quite good actually), it's just way too much duck typing for me. I could never keep all that type information in my head. I prefer to pass that cognitive load to the compiler.

Re: Python 3 in 2016

#112
post #62
post #38

Earlier quoted context omitted.

> 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. Really? Why even change the major version then, when there are no breaking changes? Given that many Python programmers seem to be traumatized by the last major version switch, why even bother? Or is this just for setting up Python 5 can have breaking changes i…

> Really? Why even change the major version then, when there are no breaking changes? Python releases don't follow semver. If Linus can bump the kernel to 4.0 because he felt like it so can Python.

> If Linus can bump the kernel to 4.0 because he felt like it so can Python.

"Can" is not "should": I mean, Python can go from 3.x to Python 2020, go with year numbers for a while, then have Python XP, then go Python 7, Python 8, Python 8.1, and then skip to Python 10. But there's no good reason to do that.

Re: Python 3 in 2016

#113

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.

Working in Windows, my biggest issue was "the 64 bit situation", but that has been greatly solved by Microsoft's MSVS for Python (lovely move by Redmond) and the Python Wheels. Now it has truly become `pip install something` or `pip install [wheel file]` for more complex stuff.

That and Cristoph Gohlke[0]'s repository of pre-compiled modules. That guy saved me more than once. Should I ever meet him, I'll sure buy him a beer!

[0] http://www.lfd.uci.edu/~gohlke/pythonlibs/

Re: Python 3 in 2016

#114

The problem is not Python 3, the problem is keeping both languages in my head at the same time. I'm tired of caring whether "print" is supposed to be a function or not, I just want to print something.

Why not just always use print() as a function? That's only a single mental change, and works in both 2 and 3.

Re: Python 3 in 2016

#115

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.

at least on OS X installing numpy and scipy is very easy - pip installs prebuilt wheels by default, no need to compile anything

Re: Python 3 in 2016

#116
On the web framework side of things, who is using aiohttp (web) and something like API-Hour? Seems like the performance is really great. Python 3 asyncio.

It's hard to find people blogging about it, not sure why? It seems like a great combination.

http://blog.gmludo.eu/2015/02/macro-benchmark-with-django-fl...

Re: Python 3 in 2016

#117

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…

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…

  > What language has decorators, generators, comprehensions, modules, but isn't Python?
Clojure, Haskell. :-)

Re: Python 3 in 2016

#118

In practice: inheriting from "object" every time is not a big deal, but losing the possibility to use Pypy or Kivy is huge.

This is my problem as well. I love using Kivy instead of tkinter, and Pypy.

Re: Python 3 in 2016

#119
post #24

Earlier quoted context omitted.

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.

> Adding a freaking JIT to CPython is a ridiculous suggestion that will never happen for a whole load of reasons. That's a bold statement. Can you elaborate on what those reasons are?

It's not a bold statement, it's one made time and time again by the cPython developers. In short:

1. The Python language itself doesn't lend itself to being JIT compiled - it's too dynamic.

2. cPython is the reference implementation. It's source should be as simple as possible.

3. Only a subset of Python programs would benefit, and the rest would be slower/more memory hungry

and finally,

4. If you want/need a JIT then use PyPy, in all it's glory with all its upsides and downsides.

PyPy is a big project with a lot of very very very smart people working on it. They've done an excellent job at JITting Python (and creating an impressive interpreter framework) but even they couldn't make a JIT that is anywhere near suitable for inclusion in cPython. A bunch of cPython hackers on python-dev have no chance.

tldr: Want a JIT? Use PyPy.

Re: Python 3 in 2016

#120
post #74

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…

> I struggle to find a compelling reason to use Python at all My issue is I always see Python as the Second Best choice for what I am doing. There is always a better tool for the job. The one thing going for Python is that it is such a generalist BUT when doing work I prefer the Right Tool for the Job approach. I seriously can't think of a job that Python does best.

[deleted]
Post reply on HN