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.

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

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

> instance.method(instance)

Borrowing masklinn's example:

  >>> class Foo(object):
  ...   def __init__(self):
  ...     self.n = 42
  ...   def bar(self):
  ...     return self.n
  ... 
  >>> f = Foo()
  >>> f.bar()
  42

    f = Foo()
    Foo.bar(f)

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

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

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.

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 Foo(object):
      def class_method(Foo):
        pass

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

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.

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.

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

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.

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

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")

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

something like

  class Foo:
    bar = 1

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})

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.

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.

  class Foo:
	bar = [1]

  foo1 = Foo()
  foo2 = Foo()
  foo2.bar.append(2)
  print foo1.bar
  print foo2.bar

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?

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.

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.

No, it does not.

I can't imagine going through this every second of my day for as long you do did. And in comparison those few hours when I can't breathe and I'm waiting for my medicine to work feel like a blessing in the sense that it could very much worse like what you experienced. Wow.

Side note: Why are the post that are giving apple the benefit of the doubt of this being a mistake getting downvoted? Really guys?

I stumbled across this incredible article reading Jeff Atwood's now-apparently-controversial post on that subject I'm avoiding like the plague.

Back to the point, it basically summarizes what I tell all of my friends who gain an interest and want to learn fast. I've been learning for over a decade out of interest now since I was 12 and I will never refer to myself as anything other than marginally competent. I akin programming to math in the sense that the ceiling is not really there because there is always more to learn and thats what the majority of your (programming) life is spent doing.

The simple fact that it's syntax light will always be the #1 reason it's a great introduction. Worry about the syntactical hangups once you have the core concepts of programming down.

I never understood those CS courses that have you diving in blind with C++

C++ made more sense to me than all the CS programs that were switching to Java for their intro to CS courses when I was coming up a decade ago.

C/C++ may have overhead that's confusing to a beginner out of the gate, but Java just amplifies that.

Started learning python on my own around age 19 and everything just skyroketed from there. I'm much more comfortable using( saying that lightly ) C++ these days but I can't imagine ever recommending it to even an enemy as their first language.

An aquaintenance on a board somewhere put it best, " C++ is like a hurricane. Gorgeous but incredibly destructive". Personally I think it all looks hideous but I get the point now.

Today, I'd agree that Python -- and possibly Ruby -- is a better first language, but when this was happening they weren't particularly mature. You just didn't have the kind of mature, syntactically-clean, object-oriented languages available that you do now. Even so, I never understood why you'd choose Java with all its excess syntax to teach a beginner.

As someone who’s well versed in C++, and who had to tutor CS students in it, I certainly wouldn’t recommend anyone use C++ unless they already know it and can use it effectively.