91–100 of 169 posts
Compared to wtfjs, I'd say this is pretty tame. The only one I actually encountered myself is `def some_func(default_arg=[]):` one, but it was indeed a very "WTF" moment.
The only one that has really bitten me was implicit string concatenation when forgetting a comma in a list literal.
Earlier quoted context omitted.
> But Python has never been about performance I have been burnt by this. As much as I like python's "expressiveness" so to speak, it is too slow for my needs; the ML community gravitated towards that because it is simple to implement and test large models because C++/C/Cuda are doing the lifting. However, in my flavour/field of ML, python is often the bottleneck because the sampling/simulations are glued with it and…
You might take a look at Julia with PyCall and RCall, if you haven't already. I find it solves a lot of headaches I have with Python while allowing me to leverage the ecosystem.
Earlier quoted context omitted.
I think you forgot the link to your collection?
There are some that you can find in [0], but they are often de-contextualized (and sometimes aren't really Python's problem, because there was a trade off that had to be made, and the LOL is just frustration as a result of the bad ergonomics that it creates), those and some others will eventually go in an longer post when I finally get that set up. To give one concrete example of an LOL PYTHON consider the @property…
The Python/NumPy gotcha that has caused me the most pain by far is def foo(x, y): return x+y where the intention is for x and y to be NumPy arrays, but the caller accidentally passes lists (or vice versa). This is especially common because a lot of NumPy functions are agnostic as to whether they operate on arrays or other iterables.
Sometimes you end up with a stray value of a wrong type somewhere in a complicated data structure. It gets propagated down the line since most parts don't care if it's one type or the other. This makes it possible for the value to propagate far away from the original mistake that caused it to be of the wrong type in the first place. Finally when some code chokes up on it, it can be completely unrelated to the code that needs fixing.
Since it's hard to debug the original cause this is often fixed by just adding the type conversion at the place that choked up. But this is just kicking the can down the street, since the remaining type inconsistency will soon pop up a problem somewhere else.
I feel like WTFs caused by doing something deeply weird hardly counts against the language. Yes doing the walrus operator inside brackets works. Yes of course it's going to be doing weird things. Is this really surprising to anyone? It's not what that operator is for . Yes comparing strings with "is" works sometimes . It's not checking equality and it isn't supposed to. In another implementation using "is" might work…
> I've been seeing a growing anti-python sentiment lately Not speaking for the quality of the article, but on that sentiment: maybe it's just that the pro-python sentiment is eroding. I'm glad it's becoming kind of ok to criticise that language, after years of it being untouchable (at its core, not the 2 -> 3 migration). At least that's my sentiment as someone who really doesn't like it (but I'm a professional, I sti…
Earlier quoted context omitted.
> I've been seeing a growing anti-python sentiment lately Not speaking for the quality of the article, but on that sentiment: maybe it's just that the pro-python sentiment is eroding. I'm glad it's becoming kind of ok to criticise that language, after years of it being untouchable (at its core, not the 2 -> 3 migration). At least that's my sentiment as someone who really doesn't like it (but I'm a professional, I sti…
I've observed the weird phenomenon that any valid criticism of Python is treated as either some kind of personal attack or because you're a mad static typing ideologue.
As if wishing for any performance that’s an improvement on bottom-of-the-barrel is some kind of wild, unreasonable ask for which the solution is “write it in a language full of pitfalls, sharp edges and an even worse packaging and developer experience than the current one? Seriously?
Earlier quoted context omitted.
The confusion there is caused by english not disambiguating between equality and being-the-exact-same-thing-ness. I'll grant that "is" is a bit of a footgun for new users, but it's not a WTF in the sense that the language is doing something weird. Rule of thumb is use == for everything except True/False/None. Once you get going with python you'll learn the meaning of is eventually, and you'll still barely ever need t…
Why that exception?
Small integers, as they are kept around, probably are as well (5 is (2+3) works).
I think what gets dropped during the conversation is, that we've been living with Java doing it this way (is being == and == being .equals) for decades and nobody really complains.
I feel like WTFs caused by doing something deeply weird hardly counts against the language. Yes doing the walrus operator inside brackets works. Yes of course it's going to be doing weird things. Is this really surprising to anyone? It's not what that operator is for . Yes comparing strings with "is" works sometimes . It's not checking equality and it isn't supposed to. In another implementation using "is" might work…
> I've been seeing a growing anti-python sentiment lately The same happened to Ruby and Rails. Once the last "in" thing no longer gets attention and new "in" things are the talk of the blogosphere, "yesterday's" things start to get dissed. I think it's to gain points for recognizing the new thing. To attract people following "old" thing to the "new" thing and provide social validation or increased mindshare for one's…
Earlier quoted context omitted.
You might take a look at Julia with PyCall and RCall, if you haven't already. I find it solves a lot of headaches I have with Python while allowing me to leverage the ecosystem.
Yes, I am currently learning Julia. My issue with it is that the documentation is rather sparse or lacking, but I am getting the hang of it. On the positive side, it appears that the jitter works quite well and fast arrays as first class citizens make me happy.
Python should just remove the `is` operator. If you really need to compare object identities, which is already a rare scenario to begin with, you can explicitly compare the object IDs. Checking if something is or is not True/False/None can just be treating the thing as True-ish or False-ish. Making the language bigger is not nearly as impressive as making it smaller!
I find checking for "is None" very useful, but that is also the only time I use 'is'. I try to avoid checking for True-ish and False-ish whenever possible, preferring to be more explicit.