How do you find OOP in python awkward? Out of curiosity.
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.