4 ms·

> 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/

by pansa2 6y ago

> 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 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 6y ago
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 6y ago
  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 6y ago
    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/+/1650298 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 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 6y ago
      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 6y ago
        Nobody in the thread said that Python is simple though, only that it's nowhere near the complexity of C++.
  - morelisp 6y ago
    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 6y ago
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.

by pansa2 6y ago

HelloNurse 6y ago

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 6y ago
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 6y ago
  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/+/1650298 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 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 6y ago
    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 6y ago
      Nobody in the thread said that Python is simple though, only that it's nowhere near the complexity of C++.
- morelisp 6y ago
  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 6y ago

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.