back
3 comments
I really like it's OO, it's regular and explicit. _ conventions are flexible for rapid development yet interfaces can still be hardened if required. You can do all sorts of stuff with decorators and Meta classes that you might do in macros in other languages but these are much more readable and predictable. The package system is simple and effective.
> Then again, if I wanted OOP, I'd use C#.

Which is not just reductionist, but downright silly. C# is not a very good OO language, in the same way Java isn't.

When I want OOP, I play with Smalltalk. Or Self.

> When I want OOP, I play with Smalltalk. Or Self.

I'm reasonably sure there was an implicit "and be productive" in there. Smalltalk and Self are neat, but they don't do well on the get shit done test.

(Yes, I know it is possible to get shit done in those. Compare the difficulty of getting-shit-done in them to an environment like Java or C#, and an unbiased source is going to have to admit they fail pretty hard if only because of stuff like Maven or, to a lesser extent, NuGet.)

> I'm reasonably sure there was an implicit "and be productive" in there.

Right, let's move the goalposts and reduce the target, was there also the implicit assumption that the language should have a C-style syntax, be statically typed, run on a JITted runtime and be maintained by a big company?

...or we can assume that the guy isn't an idiot and has selected C# as an object-oriented language for getting shit done. The only one who said "play" was you, and it makes sense because there's not really a lot of getting-shit-done using Smalltalk on modern systems. But he didn't say "play", he said "use", and a reasonable person might think that he said "use" because he has shit to get done.

If hopping up and down and yelling about your pet likes when they don't really fit the topic is your bag, more power to you, but...

> ...or we can assume that the guy isn't an idiot

No, I think we can exclude that one with no issue at all.

What's right with smalltalk and self that's wrong with c# and java? This is a serious question asked out of a desire to learn the answer.
Lower syntactic and semantic overhead, pretty much all of the language semantics are built from two properties/behaviors (and hooks into the interpreter): blocks and sending messages.

Sending messages are method calls, the difference is mostly contextual. Blocks are first-class functions with closures and nonlocal returns. That part's important when you're trying to implement e.g. loops (otherwise you have to add flags or throw exceptions, as in Javascript).

In Smalltalk, iteration is a message and a block:

    aCollection do: [item|
        "process item"
    ]
but that's not exactly rare these days. On the other hand, a conditional is a message and two blocks:

    aBoolean ifTrue: [ "code if true" ] ifFalse: [ "code if false" ]
A repeat loop is a message to a block on a block:

    [ "dynamic condition" ] whileTrue: [ "repeat while true" ]
and so's a try/finally:

    [ "a piece of code which may blow up" ] ensure: [
        "error recovery code" ]
or a try/catch:

    [ "a piece of code which may blow up]
        on: SomeError
        do: [ :sig| "error handling" ]
What this means is that there are very few special cases in the language, and the user of the language has the same power of expression as the designer of the language (much as in Lisps or Forths), the only limit is the hooks into the runtime but that's about it.

Also, message cascading is a minor but way cool (and pretty much unique) feature of Smalltalk, it lets you have your cake (return interesting values from methods) and eat it too (chain calls):

    someObject
        aMessage
      ; anOtherMessage
      ; yetAnOther
      ; andOneMore
will send all 4 messages to the same `someObject` no matter what the previous message returns.

That tells you what the language's priorities are.

How do you find OOP in python awkward? Out of curiosity.
Another response from a different source. Having to include self as a method argument means that those are not methods, but static functions. This really means there isn't precisely methods at all and the whole OOP part of python appears hacked together. That part seriously turned me off when I encountered it.

If there is a valid reason for this, it would go a long way in explaining away one of the major reasons I dislike python.

Edit: Appears to be a bug and I cannot respond to your post 'masklinn'. Can you rework the example to include the result as 42 being an instance variable instead? Thanks.

> Another response from a different source. Having to include self as a method argument means that those are not methods, but static functions.

This declaration makes no sense.

> This really means there isn't precisely methods at all

Of course there is:

    >>> class Foo(object):
    ...     def bar(self): return 42
    ... 
    >>> type(Foo().bar)
    <type 'instancemethod'>
    >>> m = Foo().bar
    >>> m()
    42
> If there is a valid reason for this, it would go a long way in explaining away one of the major reasons I dislike python.

I don't know (and don't really care) if you'll consider it "a valid reason", but here's GvR's reasoning: http://neopythonic.blogspot.be/2008/10/why-explicit-self-has...

Functions don't magically become methods just because the language hid the "self" or "this" parameter. You're focusing on irrelevant details.
It's not that the language is hiding self/this so much as what manually passing those as variables represent. What you are saying is that you never need to call a method like this?

> instance.method(instance)

You only have to list self in the declaration, you don't have to pass the instance to itself.

Borrowing masklinn's example:

  >>> class Foo(object):
  ...   def __init__(self):
  ...     self.n = 42
  ...   def bar(self):
  ...     return self.n
  ... 
  >>> f = Foo()
  >>> f.bar()
  42
Although you can also (and that can be rather neat when e.g. mapping or filtering) use the method as a function, if you get it from the class:

    f = Foo()
    Foo.bar(f)
note that it will typecheck the first argument to ensure it's an instance of `Foo`, it's not a function, it's an unbound method:

    >>> class Bar(object): pass
    ... 
    >>> b = Bar()
    >>> b.n = 66
    >>> Foo.bar(b)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: unbound method bar() must be called with Foo instance as first argument (got Bar instance instead)
If you want to do that use the @staticmethod decorator.
> "... python appears hacked together ..."

I had to extract that as a concise summation of my subjective view of the language as a whole. (Note: hacked != bad.)

The code to call super is awkward. Instead of saying super(MyClass, self).foo(), I would rather just say super.foo().

Having to specify self or cls as the first argument of an instance or class method. This one is weird when you are learning Python because you don't pass in the first variable but it gets magically inserted for you.

Creating a class method using a method decorator. Using a decorator to do something like this seems like a hack to me.

Not having a clean way to specify what all the instance variables are outside of the constructor. People with a java background are used to putting instance variable declarations as the first thing inside a class definition. In Python, these will be static variables. This seems weird and inconsistent with the how method declarations work (methods only become class methods when a decorator is used).

BTW, I like Python.

> The code to call super is awkward. Instead of saying super(MyClass, self).foo(), I would rather just say super.foo().

That's been changed in Python 3. Although it brings other issues.

> Creating a class method using a method decorator. Using a decorator to do something like this seems like a hack to me.

Why? Even more so, why is a decorator more of a hack than adding a new keyword (java) or special-casing method declaration (ruby) itself? Note that you can also create class methods without decorators if you wish to, by using a metaclass (I believe the method won't be accessible from the instance though)

> This seems weird and inconsistent with the how method declarations work.

It's actually very coherent: every binding created in the class scope is collected and set on the class object, as if passed as the third argument to `type`. That's it. Some objects (functions) are processed a bit more, but they still end up in the same place.

> methods only become class methods when a decorator is used

That's because the decorator is basically a flag to tell the attribute-resolution process to handle this method differently from the normal method-resolution process.

Class methods needing decorators really bugs me too. The problem goes back to explicit self. The explicit self, as currently implemented, carries no information: yes, you get to pick "self" as the instance name, but everyone picks "self" for that and There's One Way To Do It in Python anyway. If you could declare a class method like this:

    class Foo(object):
      def class_method(Foo):
        pass
then suddenly explicit self gains a meaning (Hey! Instance method!) and class method declaration doesn't go through a completely unrelated mechanism.

>> methods only become class methods when a decorator is used

> That's because the decorator is basically a flag to tell the attribute-resolution process to handle this method differently from the normal method-resolution process.

Do you see how that's just special-casing method declaration in a similar way to Ruby's mechanism, just relying on the programmer to drive the mechanism himself? To a not-so-casual observer it looks like Guido wasn't willing or able to change enough semantics to make a syntactic fix work for class method declaration, despite there being an obvious space in the syntax for it to fit in, so lent on a convenient implementation detail - a hack - to get the same effect with more work for the programmer.

Of course, it's equally possible that he believes that class methods are a code smell and should be explicitly made ugly, which I could have a certain sympathy for, but to me the current situation just looks really inelegant.

> yes, you get to pick "self" as the instance name, but everyone picks "self" for that

No, actually, there have been situations in the past where using `self` was not the best choice, and I didn't. Using `self` is extremely confusing when defining methods on metaclasses for instance (self turns out to be a class object)

> If you could declare a class method like this:

You completely change the semantics of defining methods and potentially break explicit code.

> Do you see how that's just special-casing method declaration in a similar way to Ruby's mechanism, just relying on the programmer to drive the mechanism himself?

The programmer is always the driver, the difference is that decorators allow doing this without adding a pointless syntactic special case.

> No, actually, there have been situations in the past where using `self` was not the best choice, and I didn't. Using `self` is extremely confusing when defining methods on metaclasses for instance (self turns out to be a class object)

Here's somewhere that Python could have made things easier for you. What's wrong with `self` being a class object? It's something Ruby gets right, in my opinion.

> You completely change the semantics of defining methods and potentially break explicit code.

Yep. In a good way. Guido had a chance to fix this at Python 3, and didn't. Do you seriously not see the benefits of the code I posted?

> The programmer is always the driver, the difference is that decorators allow doing this without adding a pointless syntactic special case.

Yes, the programmer's always the driver, but my point is that in Python the programmer has more driving to do than necessary. The reason this is confusing and inelegant is precisely because it's not a pointless case. Decorators allow doing it, but they're absolutely not the best way, its a (ab)use of a conceptually unrelated mechanic.

I always found it weird that they use len([1,2,3]) rather than [1,2,3].len

(no, I don't want to call [0,1,3].__len__() . Why would I want to add all of those underscores.)

^ this ^ never understood why certain methods (or are they functions?) are not called on the objects. This is one of the reasons I love Ruby, everything is clearly an object.
> ^ this ^ never understood why certain methods (or are they functions?) are not called on the objects.

Because they don't depend on a given class, they're protocols. There's no "master class" in which to put them, so they go in some sort of bastardized CLOS-like generic method instead.

With duck typing, that shouldn't matter. Lots of methods in the Python standard library take "file-like objects" that have read() methods and no common superclass, and that works fine without read being a top-level function.
There's no need for a super class to have a len() method. I don't get your reasoning here, Python is not a statically typed language.
reasoning by BDFL here: http://stackoverflow.com/a/237312/1188079
Similarly weirdly, the string join method really confuses me:

    ''.join([1, 2, 3])
That actually makes sense. Because the joining is something that a string knows how to do. Why should arbitrary lists know about string manipulation?

By the way, your example has an error, since you can't join a list of numbers. You can only join lists of strings. I.e.

    ' '.join("Hello", "World")
It seems strange at first but now it feels pretty natural. The alternatives might be to have a new global function (like len) or to have every possible iterator type have join (which sounds complicated).
In python 1.X it was a function under the string module. This is maintained in 2.x but goes away in 3.x.

string.join(['1','2','3'], ' ') == ' '.join(['1','2','3'])

It is rather arbitrary yeah, but I don't mind it. Len kind of makes sense as a function.
Not the one you replied to, but one thing that hits me as awkward is the default static behavior of variables.

something like

  class Foo:
    bar = 1
means that bar is now a static class member (static in Java's sense). It needs to be assigned to "1" explicitly in __init__ as far as I understand. That's just unintuitive and leads to lots of boilerplate, just so that you don't need specifiers like 'static'. Sometimes the fear of verbosity gets in the way of intuitiveness.
> Not the one you replied to, but one thing that hits me as awkward is the default static behavior of variables.

There's no default anything, what you wrote sets "bar = 1" on the class itself, nothing more an nothing less, just as if you'd written:

    Foo = type("Foo", (object,), {'bar': 1})
(in fact that's pretty much what the class statement is sugar for)

If you want to set it on the instance, set it on the instance.

Python's class context is a namespace like every other, you can do any computation you wish in there, and at the end the ``class`` statements collects all bindings of the namespace and sets them on the class.

Well in my case foo = Foo(); print foo.bar will print 1, so it does 'kinda' work as a default value. And that's ok, I just remembered there to be some case where it didn't behave the way I expected it to (e.g. instance member assignment overriding the content of another instance), but I wasn't able to reproduce it right now.
> Well in my case foo = Foo(); print foo.bar will print 1

Of course it will, Python's attribute-resolution (as do most languages) tries the instance, then the class, then the superclass, then... why wouldn't it work?

> I just remembered there to be some case where it didn't behave the way I expected it to (e.g. instance member assignment overriding the content of another instance)

Only two way I see for that to happen:

1. Re-setting the member on the class itself, not the instance

2. Or having the member be mutable and mutating it, since it's set on the class it's shared by all instances.

Right, of course it was the mutable use of an internal data structure.

  class Foo:
	bar = [1]

  foo1 = Foo()
  foo2 = Foo()
  foo2.bar.append(2)
  print foo1.bar
  print foo2.bar
prints [1, 2] [1, 2]

And that's the reason why I don't like that the standard way I define common instance members is an init function. Are there any decorators I could use to do that outside of any class function?

> It needs to be assigned to "1" explicitly in __init__ as far as I understand.

I don't think so. You do have to assign anything to it if you want to use it as a 'static' (actually 'class' attribute). You can access bar from Foo, as in Foo.bar or from an instance of Foo as in foo=Foo(); foo.bar.

What probably is confusing to you is if you assign a value bar in an instance then that gets assigned to the instance not the class. That is if you do foo.bar=100 then now foo instance has an object attribute called bar=100 that overrides Foo.bar=1. But Foo.bar still stays at 1.

You're right, I was mixing something up. You need mutable data structures to show the behaviour I mean, see my other comment in this tree.
EDIT: You do have to assign = You don't have to assign
All those self statements.
What's even worse IMO is the lack of a proper built-in 'super'. The self parameters at least serve the purpose of deciding whether a function is a class function or object function.

So yeah, I agree, python's OOP is kind of awkward. I love the ease of composition though, something I use extensively even in other languages since I know python.

> The self parameters at least serve the purpose of deciding whether a function is a class function or object function.

No, it does not.

It doesn't do that for the interpreter / compiler. But it's a common enough idiom that the human reader can rely on it.
To elaborate on masklinn's answer, you need to add the @classmethod decorator to get a class method instead of an instance method.