2 ms·
I’ve personally never understood the appeal of Python’s syntax or other language details. The inconsistency over postfix method calls versus builtin or root lev
by skywhopper 7y ago
I’ve personally never understood the appeal of Python’s syntax or other language details. The inconsistency over postfix method calls versus builtin or root level functions (like ‘len’) has always been totally inscrutable to me. The weird and unexpected rules about how to interact with multiple kinds of strings (what?). The special self param you are forced to add to method specs so that they don’t match how they are called. And the whitespace rules always struck me as heretical and in practice they just make me feel constantly confused about where to put what. For a long time I thought it was just a matter of working through the learning curve. But I’ve never felt comfortable with it.
All that said, lots of people I deeply respect love the language and I think it ultimately just comes down to some different wiring in our brains about what intuitively makes sense or doesn’t.
- joshuamorton 7y ago> The inconsistency over postfix method calls versus builtin or root level functions (like ‘len’) Interesting, what inconsistency? My understanding is that the main interfaces the language provides (Sized, Iterable, Container, etc.) are defined in terms of dunder methods that are used by top level functions (len, iter, sorted/reversed). Granted, the python-of-1995 decision that objects like dict or list shouldn't have chainable methods is weird compared to modern ergonomics (like streams), but that decision predates a lot of those practices by decades. > The special self param you are forced to add to method specs so that they don’t match how they are called. Is this more, or less magical than a `this` param that is magically accessible in method bodies and references something, though it's not always clear what, especially in the case of nested classes/scopes (Java/JS)? > The weird and unexpected rules about how to interact with multiple kinds of strings (what?) Huh? Do you mean unicode/bytes? This isn't really hard. Just use unicode everywhere unless you're dealing with something that is conceptually either a bitstring you're going to do bit-twiddly things to, or an opaque blob of bytes.
- gugagore 7y agoE.g. "".upper() vs len("")
- joshuamorton 7y agoLen works on any Sized. Upper only works on strings. There are lots of Sized, there's only one string.
- divs1210 7y agoI believe that was a reply to your question: > Interesting, what inconsistency?
- joshuamorton 7y agoAnd my point is that there isn't an obvious inconsistency there. Sized is an interface, exposed via a function. String is a type, which has methods. Now yes, you can make an argument that everything is an interface ("upper-able"). But bleh, and this avoided problems like "is it .length or .length() or .size or .size()" as happened in some other languages.
- lkrubner 7y agoThis appears to be 2 different languages: "".upper() vs len("") The first appears to be an object oriented language such as Ruby or Javascript. The second appears to be some language with plenty of static or built-in functions, such as PHP or C. This is clearly inconsistent under any definition of inconsistent.
- joshuamorton 7y agoSo which would you prefer: upper([1,2]) (so `upper` is a static builtin) or being unclear on whether its "".len or "".length or "".size or "".size() Like I said, there is consistency: interfaces are given top level things (builtin functions, operators, language features/keywords), while object methods don't. To give a recent anecdote, Rust's `x.await`, which is more "consistent", but everyone is complaining because in most languages async interfaces are exposed via something like `await x` instead of an attribute/method-y thing.