8 ms·

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

by Doxin 6y ago

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 all the time or none of the time. Don't use "is" to compare strings. it's not what that's for. Yes chaining mismatching operations does weird things. Be clearer in how you write your code. It's no surprise that writing confusing code results in confusing results. I've been seeing a growing anti-python sentiment lately, and most of it seems to be based on these sorts of odd perceived language defects. Python is by no means perfect, but none of the code on this page is something anyone would actually write in production code on purpose. I suppose it's a sign of python getting more popular.

evil-olive 6y ago
> I've been seeing a growing anti-python sentiment lately Despite the name, I don't think this is anti-python, in the same way classics like [0] are anti-PHP. The project README mentions this a bit: > While some of the examples you see below may not be WTFs in the truest sense, but they'll reveal some of the interesting parts of Python that you might be unaware of. I find it a nice way to learn the internals of a programming language, and I believe that you'll find it interesting too! 0: https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
- Doxin 6y ago
  Fair enough I suppose, but I'm still seeing posts like the OP getting linked all over the place by people trying to disparage python as a language. Of course once you get more deeply into a language it's probably a really good thing to get to know all the weird edge cases. One of my favorite past-times is writing intentionally terrible code just to exercise some of those edge cases. For instance this hello world code uses quite some oddball language features: https://gist.github.com/SuperDoxin/fde4fdad237e85a90c8764cdf88eadf5 https://gist.github.com/SuperDoxin/fde4fdad237e85a90c8764cdf...
  - foolfoolz 6y ago
    this is the same defense against the php and javascript posts: if you know the entire language really well none of these are actually problems
    - Doxin 6y ago
      If you'll read more carefully you'll find that that's not what I said. I said none of these are problems you'll run into. Even as a newcomer. Once you're getting better at the language it's nice to know these edge cases because they teach you details about the language you'd otherwise miss out on.
scott_w 6y ago
I agree, it’s the same thing when “WTF JS??” articles always include behaviour that’s part of the floating point spec in their list. I can’t think of any popular language that doesn’t have weird quirks. That said, the content of the post is useful. Knowing about this behaviour, even when it’s demonstrated by using language features incorrectly, is important. I’ve seen enough code that misuses “is” on strings to know there’s a need for information like this to be collated and accessible.
- Doxin 6y ago
  This information is definitely useful, though it probably shouldn't be presented in such a newb-friendly way. It might very well dissuade people from using python based on nonsensical reasons.
serial_dev 6y ago
I agree with most of your points, because in most cases, people try something very weird, and they are surprised that the result is something even weirder (or they just didn't think through the example logically). Except the string comparison with "is". It's confusing, because there are no errors, and when I try them in the Python REPL, it "works". The code is logical, I tested the example and it works... ...except when it doesn't, but if I'm just a naive beginner, I'll need to learn the hard way that it doesn't always work For this reason, I'd be okay with saying that "it" for strings is a WTF of the language.
- Doxin 6y ago
  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 to use it.
  - GoblinSlayer 6y ago
    Why that exception?
    - maweki 6y ago
      None, True, False are singletons and are never constructed again after initilization of the interpreter (and have been keywords in python2). That's why "is" is always safe. 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.
      - deleted 6y ago
        [deleted]
      - 6y ago
andi999 6y ago
Serious question: how do you know how the language is intended to be used?(or what the one right way is). Last time I checked, I couldn't find a document about this.
- Doxin 6y ago
  Most likely by interacting with other python developers once you run into trouble doing things in odd ways. Same as for any other language. Main difference is that the python community has a rather strong reaction to how pythonic your code is. You'll notice soon enough after working with python that for most python developers "it works" isn't good enough reason for anything. It has to work and fit how you're supposed to write python. Some of it is encoded in style guides like pep8, but most of it is pretty hard to codify like that.
echelon 6y ago
> 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 choices. Or maybe people are tired of pain points with the old way (even if just perceived or tangentially related), and they need to lash out at something.
- cutler 6y ago
  To be fair to Ruby I think it has a lot less WTFs than Python. The design of Ruby is a lot cleaner.
sorokod 6y ago
Can you imagine same "yes - ..." comments made about some new, straight out of the oven language? Most people would not touch it with a ten foot pole.
- Doxin 6y ago
  And it'd be unfair to that new language too. Basically all of the WTFs in the OP are things you don't run into, unless you're writing deeply deeply weird code, at which point it's hardly the languages fault that it does weird things.
  - sorokod 6y ago
    Not a python dev, but what is deeply weird about the examples in "Strings can be tricky..." section?
    - olau 6y ago
      Both "id()" and its companion "is" are almost never used in practice - I don't think the tutorial mentions them. At least when it comes to id(), you'd have to find that in the reference where it will explain how it works. If you're familiar with C, id() returns the memory address of the thing given to it, and "x is y" is like "id(x) == id(y)". So "x" is "x" is asking whether the Python runtime happened to put the two strings in the same place in memory, not whether the two strings are equal. ("is" is commonly used for one thing - testing against None. So you might write "a is None". I think that's just because someone once got bitten by a badly overloaded == operator. Just like some people will write === in all their Javascript, in case an incorrect type sneaks in.)
deleted 6y ago
[deleted]
tarsinge 6y ago
> 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 still use it when it's a best tool for the job, it's just a pain). I'm sure just saying that is still suspicious, and saying that I prefer JS (modern) to Python will still get me more than raised eyebrows for at least a few more years.
- donaldihunter 6y ago
  > JS (modern) LOL. JS is what, 25 years old, versus Python at 30.
  - adevx 6y ago
    I think the reference is to modern JS as in ES6 or TypeScript
  - coldtea 6y ago
    LOL, it's about "modern JS", not JS being new.
- dragonwriter 6y ago
  > I'm glad it's becoming kind of ok to criticise that language, after years of it being untouchable I've only been following Python for a little over 20 years of it's ~30 year life, but I don't remember it ever being “untouchable”, or even just “untouched” by criticism.
  - earthboundkid 6y ago
    Up until mid-2000s, no one had heard of Python. Then there was maybe ten years of “Whitespace? No!” But from say 2012 on there was a big movement of data science and education into Python and its general reputation was quite good. Edit: the XKCD antigravity comic was December 2007, so pretty early on all things considered. PG’s Python Paradox was 2004.
singularity2001 6y ago
>> none of the code on this page is something anyone would actually write in production code on purpose. I mostly agree, but there is one example where I thought it is important to know and remember: for x in range(7): def some_func(): return x Here x binds to the (outside) symbol x, not the value of x at creation time of the inner function.
- pansa2 6y ago
  Yes - in many languages x is a new variable on each iteration of the loop. Python re-uses the same variable each time, because the loop does not have its own scope.
- iovrthoughtthis 6y ago
  I’ve seen a number of experienced python programmers bitten by this. They expect a new scope but don’t get one.
- edflsafoiewq 6y ago
  That's how I expect it to behave. But anyway, the alternative (x in a new lexical environment each time the loop body is entered) only makes sense in a language where variables are scoped to a lexical block, not in Python where variables are scoped to the whole function.
pjc50 6y ago
Critiquing X, or even warning people about surprises in X, is not "anti-X". Have people picked up this weird idea from fandom culture or something? This article is not saying that people should not use python. It's not criticizing the maintainers for making stupid decisions, as far as I can see. It's just saying "if you do this, you'll get a surprising result", and in the process teaching people more about how it actually works. One of the most informative books I read early in my career was "C traps and pitfalls". I've written a lot of C in the subsequent 20 years or so. It has some particularly nasty traps. Acknowledging that does not make me anti-C. Pointing out that a saw is sharp does not make you anti-saw.
- jcelerier 6y ago
  > I've written a lot of C in the subsequent 20 years or so. It has some particularly nasty traps. Acknowledging that does not make me anti-C. depends on your cultural background I guess. Some people see literally everything that is not 100% risk-free as inherently bad.
  - pjc50 6y ago
    Well, possibly, but if you genuinely think that then you can never achieve anything other than complaining on message boards and hodling US treasury bonds. Everything has risks and it's a question of enumerating them and deciding how and whether to manage them.
    - jcelerier 6y ago
      > if you genuinely think that then you can never achieve anything other than complaining on message boards and hodling US treasury bonds. I mean... yes. That's, like, most people.
  - coldtea 6y ago
    It doesn't have to be 100% for that to be right. If we can achieve a N% risk-free Python (without sacrificing other useful features), and we only have a M% risk-free Python (where M < N, or even M << N), then what we have is inherently bad.
conistonwater 6y ago
> 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? Yes, it is in fact extremely surprising that an expression does something different based on surrounding context. It would be as if expr had one meaning but it you called f(expr) it had another. Saying that you're using it unexpectedly doesn't really address the issue of language design. It reminds me of Matlab's idea (a long time ago) that f(i) is either a function call or an array access at index i, but you will not know for sure until you've evaluated f, so expressions like f(i)(j) end up being just weird. There is a certain amount of logic that you are fully justified in expecting from a language. > It's not what that operator is for. If your idea is that an operator is free to do whatever, once it's outside its predicted situation, then I can see how that's technically correct based on the language spec, but it just seems like a very weird way to just a language design. I think if you think that some of those examples have no legitimate uses at all you'd then have no problem saying that they should be syntax errors but are accepted anyway, that it's just a bug in the parser, that it accepts too much. I also do not see how this is anti-python, I think you are being unfair to the author.
- Doxin 6y ago
  > It is in fact extremely surprising that an expression does something different based on surrounding context It isn't doing anything different though. Compare: >>> a:=1 1 >>> (1, 2) (1, 2) >>> (a:=1, 2) (1, 2) The thing that's confusing people here isn't even the walrus operator, it's tuple syntax. > If your idea is that an operator is free to do whatever, once it's outside its predicted situation No it's not. But clearly an operator can never do an operation it isn't defined to do. is and == are different operators and they do different things. > I think if you think that some of those examples have no legitimate uses at all They do have legitimate uses, but purposefully obfuscating the context around what the code is doing is hardly the fault of the language. > I also do not see how this is anti-python, I think you are being unfair to the author. Yeah on further thought it really isn't anti-python, but articles like the OP do tend to get linked in anti-language posts, which is probably what got me a bit annoyed about the article. No fault of the author.
arc-in-space 6y ago
Only two kinds of languages.
michaelcampbell 6y ago
> I've been seeing a growing anti-python sentiment lately, and most of it seems to be based on these sorts of odd perceived language defects. I've seen the same, but to me it feels like the downslope of the hype-train that was brought on by the ML crowd. Early on there was python doing python things, and the (IMO overly smug) community was happy with that. Then the AI/ML hype train fired up and for historical #reasons python became the language of choice, and this introduced a LOT more people to the language, and it became their lingua franca. Now, those people are having to write honest to god applications and are finding that python is Hard To Scale, both technically and code-management-y. IMO. Reasonable people disagree.
- pydry 6y ago
  "Hard to scale" isn't really a coherent argument against any mainstream programming language. It's kind of like saying that AMD processors or Microsoft Word are hard to scale - it's not entirely meaningless as a criticism but it's close to it. Python is not a language for writing ultraperformant multi threaded code but, of course, that's not what it used for or was ever intended to do and is an entirely separate issue to scalability. Reasonable people disagree about well defined, important matters.
  - Thiez 6y ago
    > "Hard to scale" isn't really a coherent argument against any mainstream programming language. It is odd that you would say that, because it is a very common complaint about languages with dynamic typing. As the program grows larger static typechecking becomes more and more helpful.
    - pydry 6y ago
      That is one of the many interpretations of "not scalable" I suppose... Regardless, python has tools to do that. Instagram and Dropbox in particular have written quite a lot about their internal usage and built and open sourced additional tooling (e.g. MonkeyType - that lets your code type annotate itself).
TomSwirly 6y ago
My theory is you didn't read past the couple of pages. There is some very interesting material in there that was news to me and I've been doing Python fairly intensively for the last fifteen years. Edge cases are really interesting. It's important to know them, and it's no comment on the language.
wynck 6y ago
I don't understand these comments suggesting this article is anti-python. I won't say it is the opposite. But the repo is literally stating the goal is to "Exploring and understanding Python through surprising snippets.". And I totally agree that analysing and trying to understand what is actually going on, when the language is behaving in a slightly unexpected way, is a great way to learn. So see this as a resource for people who want to learn, not for people with an “anti-python sentiment” (whatever that even means).
stjohnswarts 6y ago
I think most of this is covered by the python rule of thumb "explicit is better than implicit". I have a particularly stubborn cohort who loves nothing better than doing what I call "cargo trains" of combining list comprehensions and "." into sometime 7 or 8+ connected items in one liners. It is ridiculous. I have actually set calendar reminders to go ask him what these trains do after a couple of months between when he wrote the code and $TODAY. It never fails that he'll "get back with me". About an hour later I'll get an explanation via email :) . It never teaches him anything though.

by Doxin 6y ago

evil-olive 6y ago

> I've been seeing a growing anti-python sentiment lately Despite the name, I don't think this is anti-python, in the same way classics like [0] are anti-PHP. The project README mentions this a bit: > While some of the examples you see below may not be WTFs in the truest sense, but they'll reveal some of the interesting parts of Python that you might be unaware of. I find it a nice way to learn the internals of a programming language, and I believe that you'll find it interesting too! 0: https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

Doxin 6y ago
Fair enough I suppose, but I'm still seeing posts like the OP getting linked all over the place by people trying to disparage python as a language. Of course once you get more deeply into a language it's probably a really good thing to get to know all the weird edge cases. One of my favorite past-times is writing intentionally terrible code just to exercise some of those edge cases. For instance this hello world code uses quite some oddball language features: https://gist.github.com/SuperDoxin/fde4fdad237e85a90c8764cdf88eadf5 https://gist.github.com/SuperDoxin/fde4fdad237e85a90c8764cdf...
- foolfoolz 6y ago
  this is the same defense against the php and javascript posts: if you know the entire language really well none of these are actually problems
  - Doxin 6y ago
    If you'll read more carefully you'll find that that's not what I said. I said none of these are problems you'll run into. Even as a newcomer. Once you're getting better at the language it's nice to know these edge cases because they teach you details about the language you'd otherwise miss out on.

scott_w 6y ago

I agree, it’s the same thing when “WTF JS??” articles always include behaviour that’s part of the floating point spec in their list. I can’t think of any popular language that doesn’t have weird quirks. That said, the content of the post is useful. Knowing about this behaviour, even when it’s demonstrated by using language features incorrectly, is important. I’ve seen enough code that misuses “is” on strings to know there’s a need for information like this to be collated and accessible.

Doxin 6y ago
This information is definitely useful, though it probably shouldn't be presented in such a newb-friendly way. It might very well dissuade people from using python based on nonsensical reasons.

serial_dev 6y ago

I agree with most of your points, because in most cases, people try something very weird, and they are surprised that the result is something even weirder (or they just didn't think through the example logically). Except the string comparison with "is". It's confusing, because there are no errors, and when I try them in the Python REPL, it "works". The code is logical, I tested the example and it works... ...except when it doesn't, but if I'm just a naive beginner, I'll need to learn the hard way that it doesn't always work For this reason, I'd be okay with saying that "it" for strings is a WTF of the language.

Doxin 6y ago
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 to use it.
- GoblinSlayer 6y ago
  Why that exception?
  - maweki 6y ago
    None, True, False are singletons and are never constructed again after initilization of the interpreter (and have been keywords in python2). That's why "is" is always safe. 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.
    - deleted 6y ago
      [deleted]
    - 6y ago

andi999 6y ago

Serious question: how do you know how the language is intended to be used?(or what the one right way is). Last time I checked, I couldn't find a document about this.

Doxin 6y ago
Most likely by interacting with other python developers once you run into trouble doing things in odd ways. Same as for any other language. Main difference is that the python community has a rather strong reaction to how pythonic your code is. You'll notice soon enough after working with python that for most python developers "it works" isn't good enough reason for anything. It has to work and fit how you're supposed to write python. Some of it is encoded in style guides like pep8, but most of it is pretty hard to codify like that.

echelon 6y ago

> 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 choices. Or maybe people are tired of pain points with the old way (even if just perceived or tangentially related), and they need to lash out at something.

cutler 6y ago
To be fair to Ruby I think it has a lot less WTFs than Python. The design of Ruby is a lot cleaner.

sorokod 6y ago

Can you imagine same "yes - ..." comments made about some new, straight out of the oven language? Most people would not touch it with a ten foot pole.

Doxin 6y ago
And it'd be unfair to that new language too. Basically all of the WTFs in the OP are things you don't run into, unless you're writing deeply deeply weird code, at which point it's hardly the languages fault that it does weird things.
- sorokod 6y ago
  Not a python dev, but what is deeply weird about the examples in "Strings can be tricky..." section?
  - olau 6y ago
    Both "id()" and its companion "is" are almost never used in practice - I don't think the tutorial mentions them. At least when it comes to id(), you'd have to find that in the reference where it will explain how it works. If you're familiar with C, id() returns the memory address of the thing given to it, and "x is y" is like "id(x) == id(y)". So "x" is "x" is asking whether the Python runtime happened to put the two strings in the same place in memory, not whether the two strings are equal. ("is" is commonly used for one thing - testing against None. So you might write "a is None". I think that's just because someone once got bitten by a badly overloaded == operator. Just like some people will write === in all their Javascript, in case an incorrect type sneaks in.)

deleted 6y ago

[deleted]

tarsinge 6y ago

> 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 still use it when it's a best tool for the job, it's just a pain). I'm sure just saying that is still suspicious, and saying that I prefer JS (modern) to Python will still get me more than raised eyebrows for at least a few more years.

donaldihunter 6y ago
> JS (modern) LOL. JS is what, 25 years old, versus Python at 30.
- adevx 6y ago
  I think the reference is to modern JS as in ES6 or TypeScript
- coldtea 6y ago
  LOL, it's about "modern JS", not JS being new.
dragonwriter 6y ago
> I'm glad it's becoming kind of ok to criticise that language, after years of it being untouchable I've only been following Python for a little over 20 years of it's ~30 year life, but I don't remember it ever being “untouchable”, or even just “untouched” by criticism.
- earthboundkid 6y ago
  Up until mid-2000s, no one had heard of Python. Then there was maybe ten years of “Whitespace? No!” But from say 2012 on there was a big movement of data science and education into Python and its general reputation was quite good. Edit: the XKCD antigravity comic was December 2007, so pretty early on all things considered. PG’s Python Paradox was 2004.

singularity2001 6y ago

>> none of the code on this page is something anyone would actually write in production code on purpose. I mostly agree, but there is one example where I thought it is important to know and remember: for x in range(7): def some_func(): return x Here x binds to the (outside) symbol x, not the value of x at creation time of the inner function.

pansa2 6y ago
Yes - in many languages x is a new variable on each iteration of the loop. Python re-uses the same variable each time, because the loop does not have its own scope.
iovrthoughtthis 6y ago
I’ve seen a number of experienced python programmers bitten by this. They expect a new scope but don’t get one.
edflsafoiewq 6y ago
That's how I expect it to behave. But anyway, the alternative (x in a new lexical environment each time the loop body is entered) only makes sense in a language where variables are scoped to a lexical block, not in Python where variables are scoped to the whole function.

pjc50 6y ago

Critiquing X, or even warning people about surprises in X, is not "anti-X". Have people picked up this weird idea from fandom culture or something? This article is not saying that people should not use python. It's not criticizing the maintainers for making stupid decisions, as far as I can see. It's just saying "if you do this, you'll get a surprising result", and in the process teaching people more about how it actually works. One of the most informative books I read early in my career was "C traps and pitfalls". I've written a lot of C in the subsequent 20 years or so. It has some particularly nasty traps. Acknowledging that does not make me anti-C. Pointing out that a saw is sharp does not make you anti-saw.

jcelerier 6y ago
> I've written a lot of C in the subsequent 20 years or so. It has some particularly nasty traps. Acknowledging that does not make me anti-C. depends on your cultural background I guess. Some people see literally everything that is not 100% risk-free as inherently bad.
- pjc50 6y ago
  Well, possibly, but if you genuinely think that then you can never achieve anything other than complaining on message boards and hodling US treasury bonds. Everything has risks and it's a question of enumerating them and deciding how and whether to manage them.
  - jcelerier 6y ago
    > if you genuinely think that then you can never achieve anything other than complaining on message boards and hodling US treasury bonds. I mean... yes. That's, like, most people.
- coldtea 6y ago
  It doesn't have to be 100% for that to be right. If we can achieve a N% risk-free Python (without sacrificing other useful features), and we only have a M% risk-free Python (where M < N, or even M << N), then what we have is inherently bad.

conistonwater 6y ago

> 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? Yes, it is in fact extremely surprising that an expression does something different based on surrounding context. It would be as if expr had one meaning but it you called f(expr) it had another. Saying that you're using it unexpectedly doesn't really address the issue of language design. It reminds me of Matlab's idea (a long time ago) that f(i) is either a function call or an array access at index i, but you will not know for sure until you've evaluated f, so expressions like f(i)(j) end up being just weird. There is a certain amount of logic that you are fully justified in expecting from a language. > It's not what that operator is for. If your idea is that an operator is free to do whatever, once it's outside its predicted situation, then I can see how that's technically correct based on the language spec, but it just seems like a very weird way to just a language design. I think if you think that some of those examples have no legitimate uses at all you'd then have no problem saying that they should be syntax errors but are accepted anyway, that it's just a bug in the parser, that it accepts too much. I also do not see how this is anti-python, I think you are being unfair to the author.

Doxin 6y ago
> It is in fact extremely surprising that an expression does something different based on surrounding context It isn't doing anything different though. Compare: >>> a:=1 1 >>> (1, 2) (1, 2) >>> (a:=1, 2) (1, 2) The thing that's confusing people here isn't even the walrus operator, it's tuple syntax. > If your idea is that an operator is free to do whatever, once it's outside its predicted situation No it's not. But clearly an operator can never do an operation it isn't defined to do. is and == are different operators and they do different things. > I think if you think that some of those examples have no legitimate uses at all They do have legitimate uses, but purposefully obfuscating the context around what the code is doing is hardly the fault of the language. > I also do not see how this is anti-python, I think you are being unfair to the author. Yeah on further thought it really isn't anti-python, but articles like the OP do tend to get linked in anti-language posts, which is probably what got me a bit annoyed about the article. No fault of the author.

arc-in-space 6y ago

Only two kinds of languages.

michaelcampbell 6y ago

> I've been seeing a growing anti-python sentiment lately, and most of it seems to be based on these sorts of odd perceived language defects. I've seen the same, but to me it feels like the downslope of the hype-train that was brought on by the ML crowd. Early on there was python doing python things, and the (IMO overly smug) community was happy with that. Then the AI/ML hype train fired up and for historical #reasons python became the language of choice, and this introduced a LOT more people to the language, and it became their lingua franca. Now, those people are having to write honest to god applications and are finding that python is Hard To Scale, both technically and code-management-y. IMO. Reasonable people disagree.

pydry 6y ago
"Hard to scale" isn't really a coherent argument against any mainstream programming language. It's kind of like saying that AMD processors or Microsoft Word are hard to scale - it's not entirely meaningless as a criticism but it's close to it. Python is not a language for writing ultraperformant multi threaded code but, of course, that's not what it used for or was ever intended to do and is an entirely separate issue to scalability. Reasonable people disagree about well defined, important matters.
- Thiez 6y ago
  > "Hard to scale" isn't really a coherent argument against any mainstream programming language. It is odd that you would say that, because it is a very common complaint about languages with dynamic typing. As the program grows larger static typechecking becomes more and more helpful.
  - pydry 6y ago
    That is one of the many interpretations of "not scalable" I suppose... Regardless, python has tools to do that. Instagram and Dropbox in particular have written quite a lot about their internal usage and built and open sourced additional tooling (e.g. MonkeyType - that lets your code type annotate itself).

TomSwirly 6y ago

My theory is you didn't read past the couple of pages. There is some very interesting material in there that was news to me and I've been doing Python fairly intensively for the last fifteen years. Edge cases are really interesting. It's important to know them, and it's no comment on the language.

wynck 6y ago

I don't understand these comments suggesting this article is anti-python. I won't say it is the opposite. But the repo is literally stating the goal is to "Exploring and understanding Python through surprising snippets.". And I totally agree that analysing and trying to understand what is actually going on, when the language is behaving in a slightly unexpected way, is a great way to learn. So see this as a resource for people who want to learn, not for people with an “anti-python sentiment” (whatever that even means).

stjohnswarts 6y ago

I think most of this is covered by the python rule of thumb "explicit is better than implicit". I have a particularly stubborn cohort who loves nothing better than doing what I call "cargo trains" of combining list comprehensions and "." into sometime 7 or 8+ connected items in one liners. It is ridiculous. I have actually set calendar reminders to go ask him what these trains do after a couple of months between when he wrote the code and $TODAY. It never fails that he'll "get back with me". About an hour later I'll get an explanation via email :) . It never teaches him anything though.