Live data from Hacker News

Python 3 in 2016

hynek.me

121–130 of 194 posts

Re: Python 3 in 2016

#121
post #19

Since 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…

Python 3 is much more than changing the print() statement (which, actually, is a great thing). It's about unicode by default. It's about removing 100 of duplicates way to do things to have only one. It's about making debug much, much easier, while at the same time allowing you to write better code with less mistakes. It's about removing a lot of boilerplate. It's about introducing new syntaxes allowing things not pos…

> If you see only print, you are missing the point.

The top thing, sometimes the only thing, that makes my scripts written for 2 not work in 3 is the change to print. Adding a print function is fine, I'm all on board with that; removing the statement though seems like pain for no reason. Bringing that up is not missing the point, it's hitting the nail right on the head.

Re: Python 3 in 2016

#122

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…

The difference between python an javascript wasn't in features, it was always about predictability. I can pick out errors and expected behavior in python much more easily then javascript, and unless it breaks compatibility at some point, I suspect it will stay that way.

Re: Python 3 in 2016

#123
post #100

Earlier quoted context omitted.

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…

> "STM isn't magic."

What difference does that make. STM will still enable the removal of the GIL. If an applications is coded that doesn't work with PyPy, that's a separate matter.

Re: Python 3 in 2016

#124
I used to write a lot of personal Python scripts (ie ~/bin). I mainly did this because I seem to always screw up bash scripts and just can't remember all the conditional flags ie ([[-z ]] and error handling with bash for me has always been tricky.

However in the last couple of years I have dropped Python in favor of Groovy in part because I know the JVM and its plethora of libraries so well. Groovy is a highly underrated language. Really my only complaint is the startup time is not nearly as fast as Python but it does seem faster than say Clojure scripts. Also one of the things that I have to say I sort of think Java got right is that it has always been backward compatible (I know this was sort of impossible with Python given its not really a byte code language). That is I really don't have to worry if I write Groovy in a pre Java 5 (ie without generics) where as with Python I wasn't sure if I should write new scripts in 3 or 2.

The other annoying thing albeit far less than Ruby is dependencies with Python. Groovy has a complete bad ass way of just declaring dependencies in a script (@Grab) and they will automatically be downloaded. I have yet to see a scripting language that does this (ie dependency install on demand).

BTW since apparently any time I mention Java-like-tech on any HN post I seem to get downvoted... I really really love Python. This was not to denigrate Python or that Groovy is better than Python.

Re: Python 3 in 2016

#125
post #119

Earlier quoted context omitted.

> 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 the…

By "bold" I'm also referring to your use of the words "freaking" and "ridiculous".

1. This was also said about JS before people just went ahead and wrote JITs for it. Are you sure what they're saying isn't "we can't make a JIT for python" rather than "nobody can make one"? Because that's how it turned out with JS.

2. If given the choice, do you think the community would turn down a JIT to avoid making the reference implementation more complex? To whose benefit is that requirement? I've never heard people complain about other languages that they didn't have an easy-to-read reference implementation.

3. I've not heard this reported as a problem in practice for languages that have a JIT. It's usually toy programs where the JIT overhead is significant and they're so small and short-running that neither slowdown or extra memory is usually an issue.

4. Not everything that runs on cPython runs on PyPy so that's not a choice I'm necessarily able to make.

I'm not saying there aren't reasons to not have a JIT in cPython. But it's a choice not a natural law. And it's not ridiculous to suggest that they could make a different choice if they wanted, as JS eventually did.

Re: Python 3 in 2016

#126

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/py…

Fundamentally, python3 fixes some of the serious WATs in python2 and makes it easier to write high quality and maintainable software. For a pretty quick overview take a look at:

https://migrateup.com/main-difference-python-3/

Perhaps if python3 annoys you more than makes you say, "Hey, this prevents lots of latent bugs I might have easily shipped to production before, cool!", then you need to learn python a bit better and re-evaluate what is annoying about it.

Re: Python 3 in 2016

#127

Earlier quoted context omitted.

https://glyph.twistedmatrix.com/2015/09/software-you-can-use...

This should be the #1 comment/resource on this thread IMO.

I recently started writing a few Qt applications, and was strongly considering PyQt - I mean, why wouldn't I? The syntax is cleaner and I can get more work done faster using Python than C++.

I spent a few days going back and forth - comparing the performance, design time, etc of both - and in the end I'm just using Qt's JS JIT for dynamic list comprehensions and other things C++ is bad at. In the end, the fact that distributing on everything but Linux would have been reduced to having to bundle CPython in was just a deal breaker.

Linux isn't really bad for deployment, though. You can use the SUSE OBS to build packages for all the major platforms besides Arch, and since my main desktop is Arch, I'm building my software with PKGBUILD's from the get-go.

Re: Python 3 in 2016

#128
post #32

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 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.…

Concur with the 'thought process.' I'm a happier person after a day of writing Python than I am after a day of writing Go. Environments take a long time to mature.

Python finally has module packaging down fairly well (Go still drives me crazy even with the latest vending approach--cannot wait for a major build to break because the module creator switched hosting services).

Python is pretty pleasant to debug. The ability to set breakpoints and then poke around and/or modify values saves me hundreds of hours a year.

Building executables can still be a bit problematic (one reason we used Go for a few projects -- they really have this down). However, latest pyInstaller has been working smoothly on Windows and Linux.

Python is quick enough -- and we know how to scale websites with WSGI and stand-alone apps with asyncio (or Twisted). Rarely does the need for that last ounce of speed outweigh the ability to quickly create and modify apps.

Elixir, of all the new languages, intrigues me the most; not just for the language but being built on top of Erlang's OTP platform. They also seem to be doing a decent job on the packaging and distribution front.

Re: Python 3 in 2016

#129
post #127

Earlier quoted context omitted.

This should be the #1 comment/resource on this thread IMO.

I recently started writing a few Qt applications, and was strongly considering PyQt - I mean, why wouldn't I? The syntax is cleaner and I can get more work done faster using Python than C++. I spent a few days going back and forth - comparing the performance, design time, etc of both - and in the end I'm just using Qt's JS JIT for dynamic list comprehensions and other things C++ is bad at. In the end, the fact that d…

Python isn't very big (about 10-20 MB or so). What's the problem with bundling CPython?

Re: Python 3 in 2016

#130

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.

print isn't a function (even though print("hello") works) in Python 2. But you can use __future__ to make it a function.
Post reply on HN