6 ms·

The nuisance of having to add self as parameter to every class method, no way of enforcing private methods and the mix between methods on objects and functions

• viraptor 7y ago
  You know that double underscore is basically making a method private, right? You can work around it to access the method anyway, but you can do that as well with Ruby.
• sweeneyrod 7y ago
  The first two of those are explicit design decisions: "explicit is better than implicit" and "we're all consenting adults" respectively.
  • erokar 7y ago
    Most things in a language are explicit design decisions. Doesn't automatically make them good decisions. Actually Python is one of my favorite programming languages, probably the language with the closest mapping to how I naturally think about a problem. I really like it. But I'm also willing to admit it has some warts, as does any language.
    • ForHackernews 7y ago
      Python has warts, but IMHO it's weird to identify valid design choices, with pros and cons on each side, as "warts". If I were listing Python warts, I'd point to things like single-element tuples (1,), the `datetime` support (timezone-naive datetimes are an ambiguous disaster), or the cpython Global Interpreter Lock.
      • mixmastamyk 7y ago
        Yep, complaining about self is kinda silly when there are real things to complain about. My editor supports snippets so moderate python boilerplate is not a problem.
  • smacktoward 7y ago
    There's a fine line between "explicit is good because it means how things behave is obvious" and "explicit is bad because it means typing the same boilerplate over and over again." Not saying Python fell on the wrong side of that line, just that it's an easy line to end up on the wrong side of.
    • ForHackernews 7y ago
      You're free to use `_` (or whatever) instead of `self`, if you find `self` to be much repetitive boilerplate. It's only a convention.
      • gowld 7y ago
        Sadly the linters went for `self`.
• uranusjr 7y ago
  I’ve seen a lot of people taking issue with the self argument. Am I crazy to actually love it as a feature? I pulled out a lot of my hairs when I first started OOP (Java) trying to gork `this`, and I remember myself thinking “why didn’t everybody just do this” when I saw how Python declare methods. And I still think that’s a good idea now. So much easier to keep my sanity than using JavaScript’s bind.
  • gowld 7y ago
    What's weird is that it's half baked def foo(self): instead of a more logical: def self.foo(): to match the calling syntax.
    • duahncjak 7y ago
      Wow, this is a lot more intuitive. gowld for BDFL!
    • keypusher 7y ago
      I don't think you understand what is actually going on under the hood here, at all. Methods are member functions of a class, and must be invoked on an object. someInstance.foo() When invoking a method from within the class, you still need a reference to the object the method will be invoked on. In python, the reference is passed implicitly as the first argument, and usually called self. That has nothing to do with the method name or signature itself, and calling the method self.foo() would result in calling it like someInstance.self.foo() for cases when you aren't referencing the function from within the class, which would be even more confusing.
      • biggestdecision 7y ago
        The syntax of a language is an abstraction over what is actually going on under the hood. There's no reason python couldn't have designed their OOP abstraction more elegantly.
        • joshuamorton 7y ago
• gpderetta 7y ago
  FWIW, I wish 'this' were explicit in C++.
• takeda 7y ago
  first is a design decision, felt weird at first but after time I kind of like it, there's less magic behavior happening. The second is not true, if you add methods with double underscore (also design decision) they do behave like private. The real method name will be randomly generated so you won't get conflicts, and you can still access it for debugging purposes.
• progval 7y ago
  > The nuisance of having to add self as parameter to every class method This was done intentionnaly, because "Explicit is better than implicit". It also has some uses, eg. if you want to do this: class Foo: def inject_bar(self): def new_bar(self2): pass # you can refer to both 'self' and 'self2 here other_object.bar = new_bar It's rare, but it has its uses.
  • tomp 7y ago
    > "Explicit is better than implicit" Too bad Python breaks this "commandment" pretty much whenever it wants to.
    • progval 7y ago
      Yeah, The Zen of Python has commandments to justify pretty much anything. eg. "Simple is better than complex." or "Readability counts." when you want something to be implicit
    • rectangletangle 7y ago
      "Practicality beats purity"