Thread by @HeyChelseaTroy

@freakboy3742 So, I feel like an ass explaining this to a Django maintainer. This guy's gotta know 3x as much as I do—including why it's controversial.

The REPLIES, however, are getting kinda sarcastic and mean and poorly informed. So I'm'a explain, in good faith, why it's controversial. 1/

@freakboy3742 Before I begin, who the hell am I: I write Python that powers article recs on Firefox and NASA LandSat satellite data-to-image processing. I teach Python to CS grad students by having them replicate features of pytest, pandas, and memcached.

The reasons it's controversial:

2/

@freakboy3742 1. The first thing to understand about any language/framework is that computers are entirely manmade, and so therefore CS doesn't have "natural laws" like physics does.

CS's "laws of physics" are the perspectives of the humans who wrote whatever the thing is we're writing in. 3/

@freakboy3742 The PARTICULAR perspective of the Python programming language, and the one that the language sold itself on in versions 2 and early 3, was that of a SMALL keyword library. This made the language, in theory, easier to learn than others. More here:

@freakboy3742 No decision like that is universally "good/bad"—it's the communication of a perspective.

In line with this perspective, the Python maintainers have several times rejected the idea of adding a case statement. The reasoning: if...elif does that. We don't need a bigger language. 5/

@freakboy3742 So this is not just about a case statement or no case statement. This decision calls into question the driving perspective of the language team.

It's the open source equivalent of a court repealing a past decision after ruling on stare decisis for like three decades.

6/

@freakboy3742 To that's thing 1.

Thing 2 is, as repliers have pointed out, this isn't "just" a case statement. It rebinds a name (reallocates an existing variable) without clearly communicating that it's doing that.

So, I'll be frank here. I have seen a lot of code bugs in my career.

7/

@freakboy3742 The really bad, insidious ones are never, like, syntactic sugar screwups. The compiler catches those.

The BAD ones are situations where variable allocation isn't working the way the developer thinks it is. Those bugs can hide for Y E A R S.

This is why I teach... /8

@freakboy3742 ...precedence, associativity, and scope in the very first lesson in my Python class. In my experience, misinterpreting these three things causes more developer tears than anything else.

More on insidious bugs: 9/

chelseatroy.com/2019/12/30/pos…

@freakboy3742 So that's thing 2.

Now I wanna do thing 3: why this language feature would be useful to somebody who writes Django (and perhaps even why the maintainers themselves wanted it in there) versus why a lot of the Python community is upset about it.

Context time!

10/

@freakboy3742 Apropos of thing 2, a lot of arguments like this one in programming come from a misunderstanding of scope.

In particular, everybody thinks that programming advice that works for them specifically has global scope for all of programmers and it super doesn't

11/

@freakboy3742 Take this common Programmer Advice example: "Use composition, not inheritance."

For and-user app writers, sure. But Android, iOS, Rails, and Django have you inherit from their classes all over the place. And if they didn't, believe you me, they'd be a bigger pain to use.

12/

@freakboy3742 Same deal with performance. "Worry about legibility before performance."

For end-user app writers, sure. But the reason end-user app writers can do that is that language designers made the BASE LANGUAGE fast enough for that. By prioritizing performance.

13/

@freakboy3742 So, if you're writing a framework (like Django) or a programming language (like Python), your design priorities are different than if you're writing a Django app for an employer, for example.

To language and framework designers, a case statement is super helpful because... 14/

@freakboy3742 1. It's usually performant AF
2. It's a concise structure useful for metaprogramming
3. Probably this assignment magic is helpful in framework-and-PL-writing contexts.

But it adds little (and takes away assignment explicitness) for end-user app devs, which is 98% of Pythonistas

@freakboy3742 Do I think this is going to push Pythonistas away from the language? I mean, nah. There's other stuff like this in the language. Most app devs just don't use it.

But the breaking stare decisis thing does make me wonder where the language is headed. That's a big deal. 16/

@freakboy3742 Anyway I'm done talking. Here's more on detecting assumed context if you're interested.

chelseatroy.com/2020/11/07/wha…