Live data from Hacker News

Python 3 in 2016

hynek.me

171–180 of 194 posts

Re: Python 3 in 2016

#171

This is the ultimate HN circlejerk comment >Scala, Haskell, Clojure, Erlang (or Elixir) or Go. And there's also the less popular ones like Haxe and Dart Are you kidding me? Did you just list the languages you see threads on HN about? Scala and Go I could maybe understand if you needed the performance but the rest of the choices are just bad. Especially if you are trying to start a business instead of a functional pro…

Please don't be rude in HN comments.

We detached this subthread from https://news.ycombinator.com/item?id=11124822 and marked it off-topic.

Re: Python 3 in 2016

#172

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…

You did not define what that project would be.

I suppose you should first figure out the domain, then figure out the language support and ecosystem around that domain and then pick one. That is, if you are implementing something practical whose aim is to provide value outside of personal learning.

For example, several constraints still lead to a situation where C++ is a prime choice unless one is mostly interestes in hacking in a new domain and not finishing a project.

Note! I'm not dissing trying out languages for the joy of it!

Personally, I would pick Python for experimenting with syntax transforms, data mining and such. And as a basis for any offline tool that needs to chug bits from one place to another. Also, the numerical use cases listed elsewhere.

Basically, for anything that does not need a GUI.

Re: Python 3 in 2016

#173

It's quite possible that someone will come up with a good enough automatic 2->3 converter which alleviate the situation.

python-modernize[1] tries to automatically make your codebase compatible with both Python 2 and 3, using 2to3 and six[2] underneath. I haven't tried it yet, though. [1] https://github.com/mitsuhiko/python-modernize [2] https://pypi.python.org/pypi/six

Armin handed over development and now Modernize is actively developed at https://github.com/python-modernize/python-modernize

Re: Python 3 in 2016

#174

Earlier quoted context omitted.

python-modernize[1] tries to automatically make your codebase compatible with both Python 2 and 3, using 2to3 and six[2] underneath. I haven't tried it yet, though. [1] https://github.com/mitsuhiko/python-modernize [2] https://pypi.python.org/pypi/six

Armin handed over development and now Modernize is actively developed at https://github.com/python-modernize/python-modernize

Oh, thanks!

Re: Python 3 in 2016

#176

I think this is a nice healthy view to have about Python 2 to 3. Can't wait until python 4!

I seriously doubt 4 will include breaking changes, at least not to the semantics/syntax of the language itself. What python really needs in 4 is better unified package management and distribution support. They have a lot to learn from the Javascript and Ruby evosystems.

There are no plans to break backwards-compatibility in Python 4 like Python 3 did with Python 2. If there is any breaking change it will be something like the C API to remove the GIL or something (otherwise it will be standard stuff like removing deprecated modules and functions).

Re: Python 3 in 2016

#177
post #31

Earlier quoted context omitted.

Noob question: What's so difficult about deploying/distributing python?

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

this +1000

The python users I've encountered fall generally into two camps:

1) The engineer/scientist/researcher/hacker type that has python installed on their snowflake machine, and has a whole bunch of packages installed to make their flavor of snowcones. These users just want python to work, find joy in the syntax, and in general get their work done.

2) the developer that is trying to deploy the same thing to many machines. This is a pain. Often you end up with users from camp 1 trying to do this and you end up with a global python install with batteries and the kitchen sink included that is a dependency for a whole bunch of "server" apps. you update a package (because "my special snowcone needs it") and you break something else that you didn't know to test. This is a nightmare. With pip and venv it is easier to manage this, but I still see that relocatable venv is "experimental" when you read the help. IMHO, the python 3 community needs to make it very, very easy to distribute and deploy my special snowcone maker and all its dependencies to a system without python already installed, and not stomp on anybody elses snowcone maker in the process.

Re: Python 3 in 2016

#178

Earlier quoted context omitted.

I suspect that many Pythoners will install Python3 (with homebrew) or other on OSX (and whatever other platforms still come with just Python2)

Yes but when you want to distribute a program at the end of the day, you don't want to have to bundle python with every release or ask the use to install it, which makes a lot of people choose python 2 since it is ubiquitous.

python 2 is not ubiquitous, it is not installed by default on Windows

Re: Python 3 in 2016

#179
post #78
post #10

Been thinking about learning to code, and a lot of people have recommended Python as a good language to begin with. Taking a look at this, should I be looking elsewhere?

If you decide to learn Python, I'd suggest going through the Learn Python the Hard Way book. It's excellent.

Weirdest downvotes I've ever gotten.

Re: Python 3 in 2016

#180
post #168

Earlier quoted context omitted.

> "So far, based on that page..." From the page... "THIS PAGE IS OLD, THE REST IS ABOUT STMGC-C7 WHEREAS THE CURRENT DEVELOPMENT WORK IS DONE ON STMGC-C8" This page is probably a better starting point for the current PyPy STM work: http://pypy.org/tmdonate2.html

I didn't see anything newer there to suggest they've made a lot of progress since that page, though. Part of the problem is that they're trying to wedge into a really tight window; for all its flaws, the GIL is not all that expensive (relative to how slow Python in general is, anyhow), and trying to do it on PyPy makes their window even smaller. It's a really hard thing to hit, and I'll believe it when I see it. I'm…

> "I'll believe it when I see it".

You may be interested in this...

"Leysin Winter Sprint (20-27th February 2016)"

"STM (Software Transaction Memory), notably: try to come up with benchmarks, and measure them carefully in order to test and improve the conflict reporting tools, and more generally to figure out how practical it is in large projects to avoid conflicts"

http://morepypy.blogspot.co.uk/2016/01/leysin-winter-sprint-...

> "Nor do I recommend that you use it as part of your advocacy."

I'm an advocate for F#, but I'll encourage the progress of any open source language, strong competition is good for the field as a whole. The question isn't 'Why can't Python be fast?' but rather 'How fast can Python be?', the difference is a difference in attitude.

Post reply on HN