Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python 3 in 2016

hynek.me

Post reply on HN
Print view View original

131–140 of 194 posts

Re: Python 3 in 2016

#131

Post by kweks »

zanny wrote: post #127
monkmartinez wrote: post #85

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…

I've written a production app in Python 3 + QT4 (PySide as opposed to PyQT) - I've bundled with cxfreed, and it's great.

Fully cross-platform.. easy to distribute. Quite nice all around.

Re: Python 3 in 2016

#132

Post by abecedarius »

stdbrouw wrote: post #43
retrogradeorbit wrote: post #23

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…

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

That's a good reason, but note that it used to be the reason you picked Perl.

Re: Python 3 in 2016

#133

Post by orf »

plesner wrote: post #125
orf wrote: post #119

Earlier quoted context omitted.

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…

1. By people you mean "Google", and with a whole lot of money and a room full of some of the smartest people they could find. V8 is a whole department working full time, not a open source community-led effort. JS is also a different beast in a whole lot of ways. No, I am definitely saying "we can't make a JIT for Python that doesn't significantly impact single threaded scripts, retains significant backwards compatibility and doesn't massively complicate the cPython code". Obviously someone can make one, PyPy did, and it would be insane to ignore all of the HUGE problems they encountered (and overcame) while writing a JIT for Python. What makes you think cPython could do better?

2. It would make the reference implementation insanely more complex, to the point where it is no longer a reference implementation but a JIT implementation of Python. That's not cPython's role. For whos benefit is the requirement of a JIT? My apps run fine without them, and I don't need the memory bloat or startup cost associated with a JIT. If the community really wants another JIT they could fork cPython, find a room full of JIT experts and re-do all of the work PyPy has done, with all of the tradeoffs and problems they encountered. Nice idea.

3. "so small and short-running that neither slowdown or extra memory is usually an issue." - this is exactly the situation where a JIT adds a lot of overhead and becomes an issue.

4. So you want the best of both worlds, with no clear idea as to what magical person can make this happen (or even how) and you won't be happy until you can have your cake and eat it?

Re: Python 3 in 2016

#134

Post by gh02t »

raverbashing wrote: post #94
mangecoeur wrote: post #79

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.

The complexity of building NumPy or SciPy is pretty much par for the course in HPC. Most of the libraries it is based on are battle-hardened and ridiculously well tested to a degree not seen in many places, but they date from a different era, including libraries where originally "building" it involved a hole puncher and a bucket of coffee. Getting all those libraries to play nicely together at all is a genuine miracle.

Most any significant scientific package I've ever had to build (which is quite a few) had a complex build system that felt like it was built on top of shaky glass pillars. It's just the nature of what's involved and it's a fundamentally hard problem; it's difficult to replace those libraries because the extreme amount of verification/validation and optimization that have gone into something like LAPACK makes it economically undesirable.

I'd say also that this is part of the appeal of NumPy and SciPy, which is they glue together a huge number of tools that are otherwise disjoint. You don't have to worry (most of the time) about matrix ordering, calling conventions, those mysterious "workspace" variables in LAPACK etc.

Re: Python 3 in 2016

#135

Post by goldbrick »

coldtea wrote: post #44
andrewstuart wrote: post #33

Earlier quoted context omitted.

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.

You can still use the "-Sync" versions of functions in the standard lib.

Re: Python 3 in 2016

#136

Post by jorge-fundido »

I don't understand the python2 vs python3 fuss. Maybe I'm not doing anything interesting enough, but I find it fairly easy to write code that runs in python >= 2.7 and python >= 3.3. If I was working in a python2-only code base, I would just baby-step it towards python3 compatibility. It doesn't have to be a complicated, disruptive task.

Re: Python 3 in 2016

#137

Post by btreecat »

abecedarius wrote: post #132
stdbrouw wrote: post #43

Earlier quoted context omitted.

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

That's a good reason, but note that it used to be the reason you picked Perl.

Still a valid reason for people to chose Perl.

Not advocating for Perl, just on behalf of Perl lovers like my office mate

Re: Python 3 in 2016

#138

Post by JupiterMoon »

abecedarius wrote: post #132
stdbrouw wrote: post #43

Earlier quoted context omitted.

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

That's a good reason, but note that it used to be the reason you picked Perl.

The difference is that most people can read most other peoples' python code. Perl didn't tend to have that quality.

EDIT Added another "most" to make it clear that not everyone can write readable python.

Re: Python 3 in 2016

#139

Post by platz »

abecedarius wrote: post #132
stdbrouw wrote: post #43

Earlier quoted context omitted.

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

That's a good reason, but note that it used to be the reason you picked Perl.

Although larger network effects might make it harder to turn the ship, this time around.

Re: Python 3 in 2016

#140

Post by platz »

dragonwriter wrote: post #110
andrewstuart wrote: post #33

Earlier quoted context omitted.

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…

> I never thought I'd say it, but I'm loving programming the new ES2105 version of JavaScript. Well, yeah, I'm sure ES2105 is cool, but most of us don't have the choice of using languages from the next century.

You mean yavascript?
Post reply on HN