4 ms·

"The only visible difference is that you cannot simply access the members using the dot syntax (cat.sayHi)." There's also the lack of inheritance, the lack of

"The only visible difference is that you cannot simply access the members using the dot syntax (cat.sayHi)." 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.

lfowles 12y ago
But other than that, what have the romans ever done for us?
thalesmello 12y ago
Most of this issues could be walked around: - 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.
- icebraining 12y ago
  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. That's what a Python object is... The underlying dictionary is called __dict__.
- AnkhMorporkian 12y ago
  Static methods are fantastic. I use them all the time for deserialization. Adding a .from_json() static method to create a new instance makes way more sense to me than putting one outside the class.
BoppreH 12y ago
Don't hold me on this, just bouncing a few possible solutions: - 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".
- AnkhMorporkian 12y ago
  - Inheritance: You could, but I really don't see the point of this in the first place. - 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.

lfowles 12y ago

But other than that, what have the romans ever done for us?

thalesmello 12y ago

Most of this issues could be walked around: - 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.

icebraining 12y ago
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. That's what a Python object is... The underlying dictionary is called __dict__.
AnkhMorporkian 12y ago
Static methods are fantastic. I use them all the time for deserialization. Adding a .from_json() static method to create a new instance makes way more sense to me than putting one outside the class.

BoppreH 12y ago

Don't hold me on this, just bouncing a few possible solutions: - 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".

AnkhMorporkian 12y ago
- Inheritance: You could, but I really don't see the point of this in the first place. - 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.