36 ms·

Ahh dunders, and the lack of proper privacy mechanisms... It is generally considered bad practice to call dunders, with the idea being that those are more priv

by z9znz 4y ago

Ahh dunders, and the lack of proper privacy mechanisms... It is generally considered bad practice to call dunders, with the idea being that those are more private or more internal methods which you should not directly depend on (unless you're willing to accept more breaking changes). Instead, you depend on other more intentionally public methods which themselves may call dunders or do other things. I think the issue the parent was really focusing on was the fact that many methods are instance methods, but there are some global functions. Python suffers from being sort of OO, sort of procedural, and even less but also sort of functional. It's a bit like a flying camper van. It's a weird plane with tricky controls, poor fuel economy, cramping sleeping areas, and a bump ride on roads. But boy does it have a lot of mods and attachments, so you can do just about anything with it using only a pair of plyers and a flathead screwdriver. Thus, it attracts beginner mechanics and enthusiasts who build monstrosities that experienced mechanics have nightmares about but which pointy haired bosses don't understand and think the feature set is great.

bb88 4y ago
Humans might care whether or not you called __len__() vs len(), but that's their problem. Guido and the python community didn't enforce this in python, because I think they liked freedom over opinion of what should be done. It seems like your inability to understand why a lot of people like python seems more like a professional inability (liability?) to adapt and change with the flow.
- fragmede 4y ago
  behind closed doors managers call that inability a career limiting move
- z9znz 4y ago
  len() is not the same as __len__. The built in len() function does type checking and produces a useful exception/message if you provide an argument for which len() is inappropriate. Instead, if you do someobj.__len__ and that object does not implement __len__, then you'll get an exception complaining that he object has no __len__. Likewise, for example, abs() and __abs__() raise different exceptions if used on something for which abs() makes no sense. Like len(), the built in failure exceptions are somewhat more useful than the dunder exceptions. But even the type related exceptions of the built in functions are inconsistent -- unnecessarily so. abs("hello") => TypeError: bad operand type for abs(): 'str' len(5) => TypeError: object of type 'int' has no len() At least the exception types are uniform: TypeError. But the exception messages should be identical rather than two very different statements which say the same thing: function f is not appropriate for argument type t. You may call all this inconsistency freedom, but it's just lack of structure and general sloppiness. Or to be kinder, it's just more organic. Inconsistency and organic evolution are not hallmarks of good tools for building reliable systems. Finally, I do not lack the inability to understand why a lot of people like Python. I just posit that most people who like Python only like it because they don't (yet) know better. http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html . Python is Blub in this essay. If you don't know better, Python is a marvelous language. Although I would argue that some of the oddities and awkwardness of Python misshape peoples' thought processes in a way that can be difficult to unlearn (and which I believe even make these conversations like we are having in this topic extra challenging).
  - bb88 4y ago
    People choose tech based upon the business needs. I don't like Java, still don't. But I don't tell people they were making a huge mistake and they needed to be "schooled" into using C++, e.g. There's usually some business reason to use a particular technology -- one that you may not like. Back to python. There is no type checking in len() or abs(). The best argument I can make is through code. You, yourself, can make your own len() method. This will behave exactly like len(). Let's call it len2(): def len2(obj): try: return obj.__len__() except AttributeError: raise TypeError(f"object of type '{type(obj)}' has no len()") There's no type checking, because there's no need. All that object needs is for __len__() to exist. Further we can add abs() and len() to an object like this: class X: def __len__(self): return 2 def __abs__(self): return 1 assert len(X()) == 2 assert len2(X()) == 2 assert abs(X()) == 1 Fortunately you can fix the issues with error uniformity by creating your own functions if you choose the method above. I won't judge you -- because there might be a reason you may want that. > I just posit that most people who like Python only like it because they don't (yet) know better. I don't know about that. I came from a background of C/C++/Ada/Java/68k Assembly/Perl/Shell Script/Awk/etc. I switched to python about a decade ago. The python community has some of the smartest people I've ever met. To me the smart people seem to have gravitated towards python.

by z9znz 4y ago

bb88 4y ago

Humans might care whether or not you called __len__() vs len(), but that's their problem. Guido and the python community didn't enforce this in python, because I think they liked freedom over opinion of what should be done. It seems like your inability to understand why a lot of people like python seems more like a professional inability (liability?) to adapt and change with the flow.

fragmede 4y ago
behind closed doors managers call that inability a career limiting move
z9znz 4y ago
len() is not the same as __len__. The built in len() function does type checking and produces a useful exception/message if you provide an argument for which len() is inappropriate. Instead, if you do someobj.__len__ and that object does not implement __len__, then you'll get an exception complaining that he object has no __len__. Likewise, for example, abs() and __abs__() raise different exceptions if used on something for which abs() makes no sense. Like len(), the built in failure exceptions are somewhat more useful than the dunder exceptions. But even the type related exceptions of the built in functions are inconsistent -- unnecessarily so. abs("hello") => TypeError: bad operand type for abs(): 'str' len(5) => TypeError: object of type 'int' has no len() At least the exception types are uniform: TypeError. But the exception messages should be identical rather than two very different statements which say the same thing: function f is not appropriate for argument type t. You may call all this inconsistency freedom, but it's just lack of structure and general sloppiness. Or to be kinder, it's just more organic. Inconsistency and organic evolution are not hallmarks of good tools for building reliable systems. Finally, I do not lack the inability to understand why a lot of people like Python. I just posit that most people who like Python only like it because they don't (yet) know better. http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html . Python is Blub in this essay. If you don't know better, Python is a marvelous language. Although I would argue that some of the oddities and awkwardness of Python misshape peoples' thought processes in a way that can be difficult to unlearn (and which I believe even make these conversations like we are having in this topic extra challenging).
- bb88 4y ago
  People choose tech based upon the business needs. I don't like Java, still don't. But I don't tell people they were making a huge mistake and they needed to be "schooled" into using C++, e.g. There's usually some business reason to use a particular technology -- one that you may not like. Back to python. There is no type checking in len() or abs(). The best argument I can make is through code. You, yourself, can make your own len() method. This will behave exactly like len(). Let's call it len2(): def len2(obj): try: return obj.__len__() except AttributeError: raise TypeError(f"object of type '{type(obj)}' has no len()") There's no type checking, because there's no need. All that object needs is for __len__() to exist. Further we can add abs() and len() to an object like this: class X: def __len__(self): return 2 def __abs__(self): return 1 assert len(X()) == 2 assert len2(X()) == 2 assert abs(X()) == 1 Fortunately you can fix the issues with error uniformity by creating your own functions if you choose the method above. I won't judge you -- because there might be a reason you may want that. > I just posit that most people who like Python only like it because they don't (yet) know better. I don't know about that. I came from a background of C/C++/Ada/Java/68k Assembly/Perl/Shell Script/Awk/etc. I switched to python about a decade ago. The python community has some of the smartest people I've ever met. To me the smart people seem to have gravitated towards python.