HI version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
56% Positive
Analyzed from 5726 words in the discussion.
Trending Topics
#python#language#languages#code#true#weird#things#https#still#programming
Discussion (138 Comments)Read Original on HackerNews
I challenge you to find Python behaviors as weird and off-putting as anything here: https://wtfjs.com/
Python has weird file imports (no relative ones either), broken package management, historical differences between asyncio and blocking that still cause issues, threading/GIL caveats that trip up even experienced users, indentation for scope (esp weird given it was designed for REPL), weirdly no anonymous functions, 2 vs 3 (mostly gone by now), the __init__ and __init__.py stuff, namedtuple vs dict vs object, `global`, and a whole mess with type-linting if you're going there. You have to deal with all those things every time.
Here's one little Python footgun that everyone hits and is also annoying after:
For example, why would you expect `Boolean("false")` to equal `false`? It's a string, and bears no relation to the Boolean type. [0]
[0] https://wtfjs.com/wtfs/2014-10-07-true-equals-false
What makes this weirder than other languages detecting if they’re an import or an invoked file?
Sure, it's not a language to write a web browser or game engine in. And it is slow. But it has some very strong niches outside of ML/Data science. Personally, I love it. To each their own.
uv + PEP723 make this even better.
The only thing good I can say about Python nowadays is that it's easy to get started for the first five minutes, and then you'll have to deal with all of its weirdness: significant whitespace, truthiness, duck typing, GIL, distribution/packaging, etc, etc.
I was a big fan of Julia as the potential replacement for Python for science for such a long time and I had evangelized it a lot previously, but recently I've been more and more convinced that JIT/multiple dispatch was only good if you already know how to program well to begin with, which for a lot of academics who are not working in computer science, they write quite horrific code. I think it may be better off to skip Python altogether and write your code in a statically typed language to begin with.
In my experience the difficulty is understanding what exactly is important when teaching someone something new. And it largely depends on the goals. What you’d teach some biology undergrad is going to be very different from what you teach a bunch of robotics team high schoolers (and no you’re not teaching them the best language for controls and embedded).
Embedded firmware, probably C/C++/Rust. Not the answer you want to hear, but these are the languages for bare metal applications. Of course, if you are just using an Arduino/Pi, just use their SDK for their hardware on whichever language they support.
Those two fields are just not very friendly towards beginners in general.
It depends. If you're a teen I'm mentoring, you're probably starting with some Scratch to drive Lego robots around. Then on to Python to drive the same robots around but now with more fun!. Probably because you absolutely couldn't stand the standard line follower solution of jittering back and forth and you sniffed out the existence of better control loops you cannot realize in Scratch. If you're on the FIRST Robotics team you're probably doing Java or Python, mainly because that's just what we've geared up for (and this is really the core theme for me at least: at introductory levels, what really matters most is whatever is most readily accessible to you and whatever kit you already have).
If you're doing your own stuff and you're a newbie with absolutely no opinions on where you started or what you were trying to do, you'd probably start poking around with an Arduino or similar, so you could write MicroPython (it's Python but you squint your eyes a bit!) or C. There's so many great kits for beginners.
In the context of my comment: what I meant is that you wouldn't decide, "the professionals do it in C++, C, or Rust, so we'll start with one of those." I'm going to give you a recorder (Python) before I hand you bagpipes (C++).
In the past, the usual answer to people who need a programming language but did not want to learn programming was to give them a domain specific language that focused on solving the specific problem they wanted to solve.
> I think it may be better off to skip Python altogether and write your code in a statically typed language to begin with
Having a good REPL is a huge advantage for beginners (and expert users too), but I'm not aware of any (popular) statically-typed languages with a good REPL.
Despite Python's many faults, it's easy to install (especially on Windows), it has a large standard library, there are third-party packages available for essentially everything, it comes with a user-friendly REPL out-of-the-box, and it gives comprehensible error messages. I'm not really aware of any other (popular) languages with all these attributes.
scala's repl is decent. It has its annoyances, but so does python's (white space sensitivity + repl + terminal emulators stuck in the late mid century don't mix).
Nice to see it get attention this time.
I’ve of course certainly heard of, seen, and used `assert`, but more often than not, outside of pytest, I see its use way more in potential footgun scenarios—I doubt that many people know that assertions can be silenced, and that they’d probably be better off raising exceptions in many cases where they’re using `assert`.
I would not be surprised in the least if that pattern existed in the wild. In fact, it's quite common to see this in C/C++ codebases too: people will use assert() to check a security-relevant property, and then disable those checks in their release builds "because it can't happen".
Assigning to __debug__ wouldn't do anything to the compiler as it never actually reads the variable, so assignment would just cause weirdness from other use
True = 1
False = 0
then later these got added to the language. In Python 2 you could still reassign and swap them so that 'if False' was actually true!
True, False = False, True
Python 3 you could no longer reassign them.
Common language design boners:
- Not building in strings. That's now in the past. Everybody has strings. (Well, C...)
- Not building in multidimensional arrays of the numeric types. Everything that number-crunches needs them, and having multiple definitions is Not Fun and may lead to expensive re-copying between different libraries. This is an enormous blind spot in language design. It's one of the reasons FORTRAN, which has good multidimensional numeric arrays, is still often used for number-crunching.
- Not standardizing the small vectors (vec2, vec3, vec4) and their matrix friends. Graphics code depends on these, and it's really annoying if there are multiple slightly incompatible implementations. Especially since GPUs have hardware for those types, and you want CPU and GPU to use the same representations.
- Not having arrays of bits. Pascal had PACKED ARRAY[0..N] of BOOLEAN but that was lost in later languages. It's useful to have that as a language construct, because most modern CPUs have good hardware for dealing with bit strings, and you'd like the compiler to use it.
Most useful languages acquire these features, but, when they come in late, there are multiple similar implementations, and libraries made incompatible by depending on different implementations.
(Amusingly, when Second Life switched from Linden Scripting Language to Luau, they initially had True, TRUE, and true all in use, as different types with different semantics. I was able to persuade the devs to unify the boolean types.)
Several times now†, people make a language where the way a for-each loop (for each Goose in Geese ...) works is that there's a single variable Goose and each time around the loop we change which value is referred to by the Goose variable. This seems intuitively like a reasonable way to do this. But it's wrong and eventually your programmers will get nasty surprises. What you actually should deliver is an implementation where each time around the loop there's a new variable named Goose, that variable goes away at the end of that iteration and will be replaced by the next one, with the same exact name.
† At least Go and C#, I think there are others
I'd consider LSL to have been foundational in my ultimate interest/career in software engineering. The strict typing, very usable compile/runtime errors, and good documentation/examples made it so easy to pick up as a teen. Not to mention as long as you didn't edit/save a script again it would always run the same regardless of updates.
I'm not sure exactly which features are responsible (I'm inclined to blame templates), but C++'s std::vector<bool> is a rough edge. For those unfamiliar, the standard specifies this vector template in a way that's not compatible with other vectors.
It kind of started with vectors as the very first feature (I was sick & tired of libraries reinventing their own `Point`/`VectorN` in incompatible ways).
Definitely agree on multidimensional arrays. I feel like efficient arrays in general are underrated in high-level language design.
The thing you want is what Rust delivers in the box, &str a string slice reference type, in Rust's case the "string" is UTF-8 encoded text. On the bare metal the way to represent this type is as a "fat pointer" typically a pair of registers, one with the address of the first byte of the string and the other with a length.
C should have fat pointers, they were proposed, for IIRC C89 but the proposal was rejected. That's pretty sad, the fat pointer is expensive to the point of maybe feeling extravagant on a PDP-11, but by 1989 that's long gone.
More ridiculously C++ didn't get this type (which it eventually called std::string_view and provides in its standard library not as a built-in) until 2017, years after Rust 1.0 shipped. In the meanwhile C++ just did not have a sensible way to do this, strings are hard apparently.
The string buffer feature, allowing you to actually make strings is less important, as you say it will need an allocator and so on very bare metal you might not have this - but the string slice reference doesn't need an allocator.
I think it's worth delivering the basic "it's a growable array type, duh" implemenation of the string buffer type, which is what Rust's String type is, but C++ chooses to ship an oddly specific small-string optimized version as std::string right from the offset.
Ruby has such a nice holistic consistency to it. With a few exceptions, it feels like it was conceived of by one person with a core idea in mind. Python feels like a mess.
This is just my personal opinion with no data to back it up, but I suspect that Python "won" because it has excellent Windows support, while Ruby doesn't. Even a decade ago, Python's website offered an official native Windows installer [0], while Ruby's website [1] still points you to a third-party installer, which doesn't even have native support since it uses MSYS2 [2].
Most non-developers use Windows, so if you're choosing the first language to teach a large group of people, good Windows support is fairly important. Python being the "default" introductory language gave it a huge number of users, then I suspect that everything flowed down from there.
[0]: https://web.archive.org/web/20160824235759/https://www.pytho...
[1]: https://www.ruby-lang.org/en/downloads/
[2]: https://rubyinstaller.org/
SWIG[0] makes working with C libraries trivial for over a dozen programming languages; Perl, Python, and Ruby included.
0 - https://www.swig.org/
That said, I find it the nicest, cleanest option of the three. I still wouldn't use it for large and complex projects. I really like it for stuff where one might otherwise use shellscript. It's way way better than shellscript... except if it's all about files and running external commands.
This is exactly what I remember being said about C (which I agree with) and often given as a reason why higher level languages like Python or Java have so many protections against things C/C++ allowed (memory management being the biggest one of course). Very funny, and I assume not coincidental, to read this about Python in the modern programming landscape.
Have you tried using `uv`'s newer tools? They help a lot e.g. with linting speed, lock management, package dependency separation, correct python version mgmt and no need to fudge with venv.
In an age where people are still standing by C over memory-safe systems programming languages, I feel quite comfortable depending Python for the great many things that Python is good at.
For little utilities, it’s faster than a lot of alternatives - just start the interpreter, no compilation needed.
It’s all relative, but if you view it as replacing bash scripts for renaming files or running other tools, it’s 100x better.
The fact that Python has become the language of choice for machine learning and data science is not a language issue.
If you've ever read through FORTRAN code from a mathematics department or MATLAB/C/C++ from (non-software) engineering disciplines, then you probably understand why productionizing a jupyter notebook is definitely not the worst of all possible worlds.
https://packaging.python.org/en/latest/specifications/inline...
And it's weird how you import files. They're dot-separated packages that resemble file structure but not exactly. NodeJS has a self-explanatory require("./foo.js") or "../foo.js". The newer JS `import` syntax is annoyingly different from `require` but not terrible.
We open sourced the implementation https://github.com/janushendersonassetallocation/loman
My CLI tools publish from Github to PyPI so that I can run tools with just `uvx sql-agent-cli` or `uvx dlna-here. Nothing for me to handle downloading (directly myself), no environment to manually setup, portable (Linux, Windows, Mac, ARM, x86). Easy for agents to run from a skill.md file without any other prereq than uv.
Really useful library ecosystem to leverage. No more shell scripts, or TS/JS/PHP backend services. I've even used Python on devices I've built around Raspberry Pi Zero 2 boards.
You didn't use Perl before? https://xkcd.com/353/
At least it’s Python/Jupyter and not R, SAS, or MATLAB.
> I often work with data scientists and have to productionize their jupyter notebooks
I'm not a huge Python fan, despite working with it fulltime, but this feels like mixing correlation and causation. Data scientists would not be writing good, optimized code in any language.
> and it’s way too easy to do the wrong thing
is there another programming language where you believe a data scientist is going to have an easier time writing correct code than Python? Do you think C or Rust or JavaScript or C# make it harder to do the wrong thing?
[0]: https://peps.python.org/pep-0790/#schedule
[1]: https://peps.python.org/pep-0781/#backwards-compatibility
Took me down some rabbit holes, but interesting to see the chatter about the fix here:
https://github.com/python/cpython/issues/80233
Initially you could reassign True,False but that was verboten with the switch to python 3! The walrus operator was the one simply an oversight.
https://python-history.blogspot.com/2013/11/story-of-none-tr...
Explanation from Guido himself
Could this be so that the interpreter don't inadvertently manipulate them or pass them to a function? param=None and param="" can be very different.
https://github.com/nucypher/constantSorrow/blob/master/tests...
Now it feels like a weird PHP itself that is slow, brittle, and dangerous to write code at scale in.
The loose typing, potluck standard library, and horrible package manager (insofar as the community does not know how to package code) all feel so dated.
I still really enjoy using python though. It's not really a fair comparison because I hadn't used PHP and Perl for as long but I just don't hit some mystifying issue every single session like I did with those languages when I'm using python. I honestly have never even read about that __debug__ constant. It's fun to hear about it but it's just not something that's comes up much.
The Python community has spent the last 15 years refusing to improve in any meaningful way, or to learn anything from their peers. As someone who used to choose only jobs that would let me work with Python, I’ve gone through every phase of grief, and now just try to forget that it exists.
But to describe the Python community as "spen[ding] the last 15 years refusing to improve in any meaningful way" is just laughably wrong. I can't give details as I haven't been doing much Python work, but even so I know of multiple changes, such as the typing system, or packaging improvements, which have significantly improved the language AFAICT. If there's a reason why you would not consider those to be "improv[ing] in any meaningful way", please enlighten me.
I'm with Conal Elliot when he said on Type Theory for All that it is sooo much harder to understand a program in Python.
But to _learn_ programming, I really, really don't see how using Haskell would be simpler than Python. Perhaps if you have a specific background (e.g., math), but else python is almost pseudo code already. You'll really have to convince me that a more abstract language is better...
Python: errors based on incorrect indentation (many beginners don’t use nice IDEs), or don’t understand the meaning of the hints) and scope (don’t forget your “global” if you’re hacking in PyGame) are challenges.
I have used all three languages; and you clearly have no idea of the notion of usability of a language. So many things contradict this, let me list them off the top of my head
- Getting a running toolchain working: Prexisting (most OSes bundle a Python interpreter) or a package install away for Python. Scheme / Racket is some odd mix of custom IDEs with Dr. in the name, or someone's 20 page essay on how SLIME is the best thing ever. Haskell gets into odd stuff with ghci, cabal, and stack, and all of them are extremely slow.
- Tutorials: Python has a ton of them, they all get you printing to stdout and calculating things in about 10 minutes. Scheme / Racket typically spends multiple chapters navel-gazing about lists, cons, and such. Haskell is actually better in terms of the Hello World stuff, but ghci v/s ghc bites you again; and no one has a clear idea of which one to use.
- Advanced concepts: Python has mainstream but halfhearted OOP; and things like decorators and metaprogramming. Quickly intelligible if you learned something else like Java or C++. Or if you learned shell scripts you can get quite a bit done with just imperative. Racket/Scheme: 3 chapters in and you're still trying to figure out tail recursion. Haskell: Instead of just doing fun things with take and foldl you're being hit with trivia about typeclasses.
You’re replying to a post making assertions about beginners.
That doesn’t usually mean people with 4 years programming experience picking up a new language.
Racket: criticizing for having a beginner-friendly IDE doesn’t make a lot of sense. There’s always Magic Racket for VSCode for the others.
I guess you’re not starting people with “How to Design Programs” because that’s pictures and animations for ages.
Haskell: that was funny but an absurd criticism ghc vs ghci?? Nobody has that problem. The other stuff - valid but lead with it instead of trolling.
Can’t take credit for the quote, read it somewhere.
The whole language changed when they kicked what’s-his-name out, and it’s a tool I almost never reach for anymore, whereas 15 years ago it was my Swiss Army knife.
for all the hate js used to get, py is at least a few magnitudes worse.
my opinion ofc. don’t get mad xD
There's a lot of annoying issues with Python, but compared to the billions of dollars and thousands of man hours that has been spent trying to fix Javascript and how horrible it still is, it's a perfectly cromulent language.
Did you encounter JS first?