Live data from Hacker News

Why Python keeps growing, explained

github.blog

401–410 of 459 posts

Re: Why Python keeps growing, explained

#401

Earlier quoted context omitted.

It's really funny that one of the subheadings under "Why is Python so popular?" is "It has high corporate demand."

That's a perfectly relevant thing, no?

It reads as a little bit of a tautology. "People are using it because people use it". I get that from a hireability standpoint it's a real thing to consider, but the statement doesn't say anything about whether or not Python is actually a good language to use

Re: Why Python keeps growing, explained

#402

I have been a heavy Python user now about 15 years, but for me now I'm increasingly reaching for modern JavaScript and particularly TypeScript to do the things I would have traditionally done with Python. ES modules, fat arrow expressions, and all the other nice new syntax and library features have made the language so more pleasant to use. In many ways the ergonomics of TypeScript in particular are far superior to P…

Same. I analyzed a little why I find JS (I don't like TS) easier to deal with for some tasks: - Particular support for web frontends or backends, both very broad categories. - JS concurrency is easier to deal with. Focused entirely on promises with the nice async/await syntax on top, unlike Python which slapped on too many different ways to do this. - By far easier package management and imports. Python's is so annoy…

Python 3 vs 2 drama is from 5 years ago. It's just python 3 now.

Re: Why Python keeps growing, explained

#403

Earlier quoted context omitted.

I still use perl for some of that stuff, or even awk, but those are barely reusable or readable.

This is a letter to the general community: please stop writing these scripts in perl and bash one liners. That one off script you thought would only be used once or twice at this nonprofit has been in continuous use for 12 years and every year a biologist or journalist runs your script having no idea how it actually works. Eventually the script breaks after 8 years and some poor college student interns there and has…

I think your complaint isn't really about perl and bash. It's about knowing your audience.

When writing code that will be used by a particular sort of user base, the code should be written in whatever way best suits that user base. If your users are academics, researchers, journalists, etc. -- yes, avoid anything with complex or obscure semantics like perl or bash.

But if your code is going to be used by programmers or people who are already comfortable with perl/bash/whatever, those tools may be just the ticket.

Re: Why Python keeps growing, explained

#404

The comparison with Java is always a funny one. Consider this: import sys def main( args: list[str], ) -> int: sys.stdout.write(“hi\n”) return 0 sys.exit(main()) Apart from the call to write instead of print everything else there is a standard Python pattern for writing testable, type-safe arg-parsing code! It’s just that you don’t have to write testable, type-safe code if you don’t want to.

> Apart from the call to write instead of print everything else there is a standard Python pattern for writing testable, type-safe arg-parsing code!

Its…not, actually. A more typical, and testable, example of python would be:

  import sys

  def main(args: list[str]) -> None:
    sys.stdout.write("hi\n")

  if __name__ == "__main__":
    main(sys.argv)
Your version:

* Isn’t testable because it runs the sys.exit() call unconditionally on import, so there is no way to import the module and call main() from test code.

* Fails with an error, because main has a required argument that it isn’t supplied in the unconditional main() call inside the sys.exit() call.

* Isn’t following a typical python idiom by returning a value from a function and have it be unconditionally 0; if the only options are a fixed return and a exception somewhere, the convention is to return None (which doesn’t require an explicit return.)

* Since a normal exit is the default response of ending the main program, sys.exit() is unnecessary here; “Exit with 0 if main() returns successfully, and with an abnormal exit on exceptions in main” is achieved by just calling main() and having nothing after it in the main program.

Re: Why Python keeps growing, explained

#405

Earlier quoted context omitted.

That's a perfectly relevant thing, no?

It reads as a little bit of a tautology. "People are using it because people use it". I get that from a hireability standpoint it's a real thing to consider, but the statement doesn't say anything about whether or not Python is actually a good language to use

Another counterpoint to this. Rust is a popular language (debatable claim, of course) but it's not high in corporate demand.

Re: Why Python keeps growing, explained

#406
post #333
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…

Code is still completely unreadable with explicit block markers, if it is without appropriate indentation and newlines. That's like trying to read minified javascript. And python forces you to have these, to some extent.

I used to think the same, but go fmt totally changed my mind on this. Most languages now have a code formatted that is integrated in all popular text editors and IDEs.

Re: Why Python keeps growing, explained

#407
post #270
post #214

Earlier quoted context omitted.

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…

Aren't you kinda describing OCaml?

Re: Why Python keeps growing, explained

#408
post #369

Earlier quoted context omitted.

This is a letter to the general community: please stop writing these scripts in perl and bash one liners. That one off script you thought would only be used once or twice at this nonprofit has been in continuous use for 12 years and every year a biologist or journalist runs your script having no idea how it actually works. Eventually the script breaks after 8 years and some poor college student interns there and has…

one line spaghetti ... I remain unsympathetic.

He has a valid point, though. I've seen (and written!) one-liners that were so complex that nobody, even devs, can deal with them without decoding them first.

They aren't technically "spaghetti", but they are technically impenetrable.

I argue that one-liners like that aren't good for anybody, dev or otherwise.

Re: Why Python keeps growing, explained

#409

Earlier quoted context omitted.

Same. I analyzed a little why I find JS (I don't like TS) easier to deal with for some tasks: - Particular support for web frontends or backends, both very broad categories. - JS concurrency is easier to deal with. Focused entirely on promises with the nice async/await syntax on top, unlike Python which slapped on too many different ways to do this. - By far easier package management and imports. Python's is so annoy…

Python 3 vs 2 drama is from 5 years ago. It's just python 3 now.

"Python 2 is unsupported by the Python Foundation since 2020-01-01" according to Debian docs. Ubuntu defaulted to Py2 until around then. So I'd say that's when the drama ended, then again it's probably not the last I've seen of Py2.

Re: Why Python keeps growing, explained

#410
post #257
post #214

Earlier quoted context omitted.

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…

> the features that make Python quite good at prototyping make it rather bad at auditing for safety and security What's an example that makes it bad? Is it a case of the wrong tool for the job? For example I understand that garbage collection languages shouldn't be used with real time systems like flight controllers.

There are many examples, but let's speak for instance of the fact that Python has privacy by convention and not by semantics.

This is very useful when you're writing unit tests or when you want to monkey-patch a behavior and don't have time for the refactoring that this would deserve.

On the other hand, this means that a module or class, no matter how well tested and documented and annotated with types, could be entirely broken because another piece of code is monkey-patching that class, possibly from another library.

Is it the case? Probably not. But how can you be sure?

Another (related) example: PyTorch. Extremely useful library, as we have all witnessed for a few years. But that model you just downloaded (dynamically?) from Hugging Face (or anywhere else) can actually run arbitrary code, possibly monkey-patching your classes (see above).

Is it the case? Probably not. But how can you be sure?

Cue in supply chain attacks.

That's what I mean by auditing for safety and security. With Python, you can get quite quickly to the result you're aiming for, or something close. But it's really, really, really hard to be sure that your code is actually safe and secure.

And while I believe that Python is an excellent tool for many tasks, I am also something of an expert in safety, with some experience in security, and I consider that Python is a risky foundation to develop any safety- or security-critical application or service.

Post reply on HN