[morelisp]

> Do you learn and use all of any language you use?

Generally, yes for Python (definitely for 2, async shook up 3 a bit), C (barring a few genuinely legacy things like trigraphs), Go, Lua, and I think probably at least 2-3 times a year for anything in Java 12 and earlier.

C++ is the only language I use regularly that I am certain I don't even know of, let alone know or use, all the features of.

[pansa2]

> Do you learn and use all of any language you use? yes for Python

Have you really used all of these Python features (from https://twitter.com/raymondh/status/1280988785841278976)?

__class_getitem__, __init_subclass__, __prepare__, __qualname__, __slots__, __spec__, __annotations__

__subclasshook__, __abstractmethods__, __text_signature__, __index__, __loader__, __mro__

I've been writing Python for years, but I've never even heard of half of them.

[HelloNurse]

Because they are extension points that all have sensible defaults (in most cases, "nothing to see here") but are readily available when one needs to write something magical, not because there's unnecessary complexity in the language.

All Python-like languages have the same or similar mechanisms (for example, a method resolution order whenever there is multiple inheritance) and they are usually not explicit and not customizable.

[sseagull]

But the common argument against C++ is that you need to know a large portion of the language because someone somewhere might be using it, and you may have to read and understand their code. So even things that are optional in python should count against python, just like they do in C++.

[masklinn]

The difference is that C++ features very much interact with one another in subtle and detrimental ways, so if you are using feature A and a codebase you leverage uses feature B, the interaction of the two can genuinely cause issues. For Python, the extension points are generally hooks into very explicit operations (and some of the symbols you list aren't even extension points).

Hell, the very defaults of C++ will interact badly with other features and proceed to shoot you in the foot, as Chrome somewhat recently reminded us (https://chromium-review.googlesource.com/c/chromium/src/+/16...).

You need an 8x6 matrix just to know what the compiler will or won't generate (https://i.stack.imgur.com/b2VBV.png) and then you need to know exactly what the defaults will do and whether that breaks your object entirely and you need to override those defaults.

[sseagull]

Oh I completely agree. I am mostly just annoyed at the slanted comparisons, saying that something like Python is ”simple” on some absolute scale.

I teach Python to scientific programmers. There are a lot of little details and corners that aren’t as obvious to experienced developers. Just like any language.

[masklinn]

Nobody in the thread said that Python is simple though, only that it's nowhere near the complexity of C++.

[morelisp]

There is a big difference between "optional because I don't need do to the thing in 99% of projects" and "optional because I can use one of three alternate features with subtle incompatibilities to do the thing."

[morelisp]

The only one I had not heard of before is a relatively recent addition, __class_getitem__. To Python's credit, I immediately (and correctly) guessed what it did from the name. I have used over half of them - if you have even written anything that needs to show docstring/typing information or a plugin loader you already cover nearly of them. I've used __index__, __slots__, and __mro__ more times than I can remember. The ones I haven't used are mostly because they are Python 3.4+.

But, critically, you won't find anything other than __slots__ and __index__ (and maybe __subclasshook__ if the code you're working on was from someone who drank the ABC koolaid back in the day) in "normal code" - they're there for people who want to hook into language internals, the kind of thing you'd usually find #pragma'd in C++.

With C++, on the other hand, you run into this kind of complexity just trying to solve "ordinary" problems. And it bears repeating, the "safe subset" between projects is different. It's not the only language with this problem (Common Lisp suffers greatly from it), but it's the one that offers the least in return and breaks the hardest when you get it wrong.

[atribecalledqst]

> C++ is the only language I use regularly that I am certain I don't even know of, let alone know or use, all the features of.

I'm still holding out some hope that Stroustrop releases a new edition of "The C++ Programming Language" with the features from C++14 onward.