Javascript-Style Objects in Python
gist.github.com
gist.github.com
There's also the lack of inheritance, the lack of class specific methods, isinstance and issubclass checking, the different type, no possible way to define a custom iteration method, no way to use it as a decorator or a context manager, no static methods, and probably a dozen other things I haven't thought about.
- For the dot syntax, all you have to do is define the __call__ method. You could do that by creating an object that encapsulates the dictionary, defines a __call__ method, and repasses the method calls to the underlying dictionary.
- For inheritance, just create another constructor function that calls the parent constructor, adds the desired methods, and returns the new function. In JavaScript, it's called parasithic inheritance.
- For the iteration method, you just have to define the __iter__ method.
- For the isinstance and issubclass method, maybe you could create new conventions (and thus reinvent the wheel)
- About static method... should we be using them anyway?
Those are just some thoughts. This alternative way of creating objects is probably useless, nevertheless fun.
That's what a Python object is... The underlying dictionary is called __dict__.
- Inheritance: start with an empty dictionary and pass it to an "init" function. Inheritance is then just calling another "init" inside it. Allows for "multiple inheritance".
- "isinstance" and "issubclass" are mostly useful for primitive types, i.e. distinguishing between a number and a string. Also, duck typing.
- Custom iteration/use as decorator/context manager: true, it's not possible. We could amend the language to check for dictionary keys or simply use the "a.b -> a['b']" syntax sugar like javascript. Perhaps a pre-processor? Pyscript?
- Static methods: that's a loss. Fortunately we have modules, so you could just make them simple functions. If this were Java we would have problems.
- We don't have encapsulation, but again pure Python doesn't either (name mangling notwithstanding).
I don't know what you mean by "class specific methods", "the different type".
- isinstance/issubclass: Duck typing is good, but the ability to check if you really need to is really good to have.
When I was talking about class specific methods, I was talking about __str__, __repr__, __cmp__, __hash__, etc.
By different type I meant that this will read as a dict and not a class if you check the type.
Sure, you could reimplement a lot of these things if you made a subclass of dict, implemented a __call__ method, yadda yadda, but at that point you're basically recreating what type() already does.
I didn't realize all beginning Python programmers knew what they could do with closures.
My point is, why have a class syntax at all? It's such a mess, "self" isn't even implicit. You don't even need to declare class methods inside the class. You just have to make sure you pass self to the class method.
This seems very loosely wrapped around what I did. Except class syntax is native. Why? I just really don't care for how sloppy the python class syntax is.
/rant
At some point you trade an api for being explicit. Why isn't memory management explicit in python? I just don't agree with the (seemingly arbitrary) choice of making self explicit. It really does not feel like the "Python" way.
http://neopythonic.blogspot.com/2008/10/why-explicit-self-ha...
There's really nothing new or interesting about it. Except maybe for beginners. Which is fine. Nothing wrong with being a beginner. It's just not what I expect to see on the frontpage of HackerNews.
That's almost like someone saying: look wow, 2+2 and 2*2 and 2^2 all return the same result! Sure, amusing when you realize it for the first time, but hardly interesting for anyone but a first grader.
It's just not pythonic.
> There should be one-- and preferably only one --obvious way to do it.
Not to mention that the object['field'] syntax is rather annoying.
If you like Javascript that much.. then write in Javascript. Just my 2c. :-)
Edit: Forgot to capitalize.
>>> def Cat(name):
def hello():
print "I'm "+name
hello.__dict__ = {
'hello': hello,
}
return hello
>>> c = Cat('snuffels')
>>> c.hello()
I'm snuffelsMy question remains, why use Python objects vs these style objects? Sure you can say this doesn't have "support" for class-related functionality natively. But just like in Javascript, most of these can be implemented anyway.
Support inheritance by passing in the parent Function/Class and copying the attributes/values. Check the type by storing type name or check the function name via reflective programming.
My point is, I can see most of the functionality of Python classes replicated without the Python class syntax. So... why is there native class syntax when I can replicate most of the functionality with just functions.
At least from a devil's advocate perspective, why should I use classes? Is memory management better? That is the only topic I can imagine mattering if there is a library for creating objects from just functions per the example.
Another answer is that you are, in fact, using classes, you're just not using the 'class' identifier and syntax (assuming you're library was fleshed out to include all the missing features that your toy example is missing). Why doesn't Python offer three different class implementations and syntax? Why did you use a dictionary in your example, instead of implementing your own key-value object with hashing functions? Why are you using Python at all, instead of writing directly machine code?
What exactly do you think a class can do that you can't replicate in this pattern? Inheritance? Pass the parent function in. Typeof? Store a type value or get the function name reflectively.
class JSLikeObject(dict):
__getattr__ = dict.__getitem__
__setattr__ = dict.__setitem__