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

Why Python keeps growing, explained

github.blog

Post reply on HN
Print view View original

261–270 of 459 posts

Re: Why Python keeps growing, explained

#261

Post by ale42 »

sva_ wrote: post #97
joenot443 wrote: post #74

Earlier quoted context omitted.

Damn! Is the rule of thumb really a 10x performance hit between Python/C++? I don’t doubt you’re correct, I’m just thinking of all the unnecessary cycles I put my poor CPU through.

It really depends on what you're doing, but I don't think it is generally accurate. What slows Python down is generally the "everything is an object" attitude of the interpreter. I.e. you call a function, the interpreter has to first create an object of the thing you're calling. In C++, due to zero-cost abstractions, this usually just boils down to a CALL instruction preceded by a bunch of PUSH instructions in assemb…

Other than this, dynamic typing is a big culprit. I can't find back the article with the numbers, but its performance overhead is enormous.

Re: Why Python keeps growing, explained

#262

Post by marcosdumay »

ngrilly wrote: post #57

It's interesting that people keep claiming that indentation-based blocks makes Python easier to learn and read. I've been teaching programming to students in banking, finance and insurance for a few years, using Python, and my experience with them is the opposite. They have been struggling with that a lot. They didn't pay too much attention to white spaces and tabs, probably because they are "invisible", and couldn't…

IMO, the thing about beginners and relevant white space is that it forces them to learn how to indent their code, not that it makes it any easier to learn the language.

Re: Why Python keeps growing, explained

#263

Post by zeku »

osigurdson wrote: post #242
airtag wrote: post #174

Earlier quoted context omitted.

Totally depends on the business you're in. If you're dealing in areas with short time limits then Python is great, because you can't sell a ticket for a ship that has sailed. And I've seen "the right way" which, again, depending on the business may result in a well designed product that is not what's actually needed (because people are really bad at defining what they want) What's brilliant with Python compared to ot…

It is hard to believe that Python is objectively that much more productive than other languages. I know Python moderately well (with much more real world experience in C#). I like Python very much but I don't think it is significantly more productive than C#.

Python is out of this world more productive in the Science space and Data space.

The only thing that can compete with it for productivity in the science space is R.

Re: Why Python keeps growing, explained

#264

Post by cozzyd »

photochemsyn wrote: post #202

They don't mention that Python makes it really easy to interoperate with other languages via the subprocess module. So you can run Javascript web code via node, wait for it to finish, then move on to something else. Or you can launch a C++ process that's can do real parallelism and wait for the results, avoiding many issues with the Python GIL. Also, Python makes it easy to work in different programming paradigms, it…

What languages make it difficult to spawn other processes?

Re: Why Python keeps growing, explained

#265

Post by kajaktum »

t43562 wrote: post #73
kajaktum wrote: post #42

Why haven't Python replaced Make? Its cross-platform and can do pretty much any horrible monstrosities that people do in make and cmake.

Meson is a build system written in python: https://mesonbuild.com/index.html Getting python bootstrapped is less easy than getting make bootstrapped, plus python isn't a GNU tool so I don't see them adding a dependency on it to all their packages. GNU Make is really far more sophisticated than people give it credit for and it's not that easy to replace it.

I was thinking of using python as a script (duh).

> GNU Make is really far more sophisticated than people give it credit for and it's not that easy to replace it.

Since its turing complete, it should be able to do everything make can. For example, to compile a C project involves something like:

1. grab all the C files inside `src/`. 2. join the filenames with whitespace delimiter 3. execute `gcc `

It can also be used to figure out the OS, where to find dependencies and what order compilation should happen or whatever.

But why doesn't this happen?

Re: Why Python keeps growing, explained

#266

Post by OJFord »

wussboy wrote: post #233
leetrout wrote: post #227

Tangent: Something interesting (and frustrating) ... I went to the LinkedIn assessments to take the Python assessment and over half the questions were specifically about Numpy, it's API and matrix math. Which for me and what I generally do has nothing to do with "Python" and I was quite surprised to find that in the questions.

In my search for a senior Python developer I have encountered dozens and dozens of resumes whose Python experience consists almost exclusively of Numpy and data entry. Not at all the skill set I’m looking for.

Are you calling the job 'senior python developer'? I haven't used any other language (as the primary one anyway) professionally (and I'm open to that remaining the case) but I probably wouldn't even open such a job description.

Re: Why Python keeps growing, explained

#267

Post by albrewer »

wussboy wrote: post #233
leetrout wrote: post #227

Tangent: Something interesting (and frustrating) ... I went to the LinkedIn assessments to take the Python assessment and over half the questions were specifically about Numpy, it's API and matrix math. Which for me and what I generally do has nothing to do with "Python" and I was quite surprised to find that in the questions.

In my search for a senior Python developer I have encountered dozens and dozens of resumes whose Python experience consists almost exclusively of Numpy and data entry. Not at all the skill set I’m looking for.

As a pretty experienced python dev who has never worked professionally with Django / Flask or Numpy, I have a hard time finding job postings without those seemingly hard requirements.

Re: Why Python keeps growing, explained

#268

Post by drewcoo »

Lyngbakr wrote: post #190
raincole wrote: post #115

Earlier quoted context omitted.

> This week our Director ordered a total rewrite of two years of work in Python WTF? Unless your system is originally written in a proprietary language that literally no one outside your company knows, I'll say it's a good sign that you need to change team (or change job). Don't work under a director like that.

Agreed. Coincidentally, I resigned the day before this was announced.

Sorry if it sounds too cynical, but that's probably the intended effect of a rewrite from what the team knows into Python: staffing changes. A bunch of the (expensive) old guard will leave and they can be replaced with cheap grads, who all know Python.

Better luck with the next one!

Re: Why Python keeps growing, explained

#270

Post by dkarl »

Yoric wrote: post #214
pletnes wrote: post #11

Python keeps growing in number of users because it’s easy to get started, has libraries to load basically any data, and to perform any task. It’s frequently the second best language but it’s the second best language for anything. By the time a python programmer has «graduated» to learning a second language, exponential growth has created a bunch of new python programmers, most of which don’t consider themselves progr…

I fully agree with the description. What worries me, though, is that the features that make Python quite good at prototyping make it rather bad at auditing for safety and security. And we live in a world in which production code is prototyping code, which means that Python code that should have remained a quick experiment – and more often than not, written by people who are not that good at Python or don't care about…

I sometimes think about what Python would be like if it were written today, with the hindsight of the last thirty years.

Immutability would be the default, but mutability would be allowed, marked in some concise way so that it was easy to calculate things using imperative-style loops. Pervasive use of immutable instances would make it impossible for libraries to rely on mutating objects a la SQLAlchemy.

The language would be statically type-checked, with optional type annotations and magic support for duck typing (magic because I don't know how that would work.) The type system would prioritize helpful, legible feedback, and it would not support powerful type-level programming, to keep the ecosystem accessible to beginners.

It would still have a REPL, but not everything allowed in the REPL would be allowed when running code from a file.

There would be a strong module system that deterred libraries from relying on global state.

Support for at least one fairly accessible concurrency paradigm would be built in.

I suspect that the error system would be exception-based, so that beginners and busy people could write happy path code without being nagged to handle error values and without worrying that errors could be invisibly suppressed, but there might be another way.

Post reply on HN