A post by Guido van Rossum removed for violating Python community guidelines

[flagged]

>I don't know if you're bring purposefully obtuse, I hope not, but obviously I meant "master" came from slavery before audio, and audio took that terminology because it was already a popular word.

I don't know if you're bring purposefully delusional, I hope not, but obviously I meant "master" came from master piece before audio, and audio took that terminology because it was already a popular word. Because of, you know, mastering something?

>Yes audio mastering came before git, and slavery came before both. I don't even know why someone would even bother to argue otherwise.

Luckily "master" in this context has absolutely nothing to do with slavery, so your comment is an immaterial non sequitur.

The use of "master" in git has no historical or etymological ties to slavery whatsoever as outlined above. QED.

[flagged]

> One might not reasonably infer this because that's the most insane thing I've ever read. Do you just assume everyone else is this insane? They're really not.

Again, a higher standard of discourse is expected here. But I infer this because it is the only way that any sense could possibly be made of the argument.

If we claim anything other than "this terminology somehow justifies or advocates for racial supremacy", then it is immediately clear that nothing the author says about the terminology actually counts against using the terminology.

But the author insists that it is problematic to use the terminology. Therefore that must be the argument.

> But whenever I open up GIMP, I can't help but think about some sexual things.

This is your fault, bluntly.

> inaction CAN BE political.

This is a different claim from what you initially presented.

> Was this act of inaction political? Yes, yes it was. So yes, inaction can be political.

The police officers in your example were demonstrating action, not inaction. They made a conscious choice to ignore a legal duty. That is clearly different from failing to rename something in your code because an activist says you should. Nothing ordinarily obligates me to accept pull requests.

> I'm not asserting that, it seems you're having hallucinations.

Again, a higher standard of discourse is expected here. But I asked a question.

> And, it was known and understood because of... wait for it... slavery. The only reason it's in our lexicon is because of slavery.

First off, no, that is simply untrue: https://www.etymonline.com/word/master . The word is attested in other uses going back to at least the 12th century.

Second, I already addressed the possibility that you were not making such an assertion. In this case your argument also fails. You cede that the term is not used for a political reason, even if it were inseparable from a particular connotation (which isn't the case anyway). Simply having an effect is not the same thing as doing something for the reason of creating that effect.

> I understand it's very easy to win arguments against insane people but you'll have to try harder.

Again, a higher standard of discourse is expected here.

>Dictionary merging and update operators contradict the "one way to do it" with weird and confusing syntax that's completely redundant to methods that already exist.

I find the unpacking syntax elegant. There are yet more unrealized possible generalizations of it that I can think of.

> Type hints are a sore spot for me.... Python resisted match/case syntax for decades, but when it finally arrived, it did so in a way that’s anything but standard

Many people expect match/case to be "a switch statement" but it really is not designed for this purpose. I agree that it's an awkward fit and I don't use it. Similarly, I only use type annotations for documentation purposes.

> Dicts are ordered now, but is OrderedDict deprecated? No, because it's just slightly different in weird and mostly unimportant ways.

Large amounts of existing code are dependent on those ways, because the code was written to use that design. The ordering of dicts since 3.6 is an accidental consequence of an unrelated space optimization. In my view, the team erred by deciding in 3.7 to guarantee that ordering. I have concretely identified a further space optimization which is prevented as a result.

> Python in 2005, when everyone depended on the standard library, was a safer place than npm is today.

The flip side of dependency risk is security risk from lack of maintenance. For example, the standard library `json` module is a frozen-in-time old version of `simplejson` (it even remembers a useless version number). That project is still actively maintained (https://github.com/simplejson/simplejson) but none of those improvements - even if they fix security - will make it into Python except by parallel work by the core dev team. (Or accepting a patch; but that also requires either the maintainer or a third party to notice that a recent `simplejson` change is a security fix, figure out how to backport it to the much older version, and make a PR.)

There are other ways to solve the problem. For example, an organization similar to PyPA could publish a set of "core" libraries, versioned independently from Python but explicitly tested as part of the CPython release process. (That would also allow for fixing the problem that the standard library isn't namespaced - which is at the root of the problem whereby beginners e.g. put their toy lottery project in `random.py` and get an error from a circular import, or - I swear I'm not making this up - having a `token.py` in the current working directory breaks the interactive REPL help - see https://stackoverflow.com/a/75068706).

So, yes, it would be nice to see lockfiles that "depend only on a specific version of the Python Standard Library". Right now, that dependency goes undeclared, and the maintenance work is distributed among people who are also busy with developing the actual language.