undefined | Better HN

0 pointserokar6y ago0 comments

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 in the standard library. OO feels more integrated in e.g. Ruby.

About some of the design decisions in Guido's own words: http://python-history.blogspot.com/2009/02/adding-support-fo...

0 comments

uranusjr6y 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.

gowld6y 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.

keypusher6y 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.

biggestdecision6y 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.

2 more replies

Doxin6y ago

The thing is that that doesn't really match the calling syntax, it matches the syntactic sugar for the calling syntax. Whenever you do

    thing_instance.foo(bar, baz)

you're secretly calling

    Thing.foo(thing_instance, bar, baz)

Which succinctly explains where the self argument comes from.

duahncjak6y ago

Wow, this is a lot more intuitive. gowld for BDFL!

sweeneyrod6y ago

The first two of those are explicit design decisions: "explicit is better than implicit" and "we're all consenting adults" respectively.

smacktoward6y 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.

ForHackernews6y 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.

gowld6y ago

Sadly the linters went for `self`.

erokarOP6y 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.

ForHackernews6y 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.

mixmastamyk6y 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.

progval6y 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.

tomp6y ago

> "Explicit is better than implicit"

Too bad Python breaks this "commandment" pretty much whenever it wants to.

progval6y 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

rectangletangle6y ago

"Practicality beats purity"

gpderetta6y ago

FWIW, I wish 'this' were explicit in C++.

viraptor6y 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.

takeda6y 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.

j / k navigate · click thread line to collapse

0 comments

uranusjr6y ago

gowld6y 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.

keypusher6y 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()

  someInstance.self.foo()

for cases when you aren't referencing the function from within the class, which would be even more confusing.

biggestdecision6y 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.

2 more replies

Doxin6y ago

The thing is that that doesn't really match the calling syntax, it matches the syntactic sugar for the calling syntax. Whenever you do

    thing_instance.foo(bar, baz)

you're secretly calling

    Thing.foo(thing_instance, bar, baz)

Which succinctly explains where the self argument comes from.

duahncjak6y ago

Wow, this is a lot more intuitive. gowld for BDFL!

sweeneyrod6y ago

The first two of those are explicit design decisions: "explicit is better than implicit" and "we're all consenting adults" respectively.

smacktoward6y 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.

ForHackernews6y 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.

gowld6y ago

Sadly the linters went for `self`.

erokarOP6y ago

Most things in a language are explicit design decisions. Doesn't automatically make them good decisions.

ForHackernews6y ago

Python has warts, but IMHO it's weird to identify valid design choices, with pros and cons on each side, as "warts".

mixmastamyk6y 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.

progval6y 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.

tomp6y ago

> "Explicit is better than implicit"

Too bad Python breaks this "commandment" pretty much whenever it wants to.

progval6y 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

rectangletangle6y ago

"Practicality beats purity"

gpderetta6y ago

FWIW, I wish 'this' were explicit in C++.

viraptor6y 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.

takeda6y ago

first is a design decision, felt weird at first but after time I kind of like it, there's less magic behavior happening.

j / k navigate · click thread line to collapse