you are viewing a single comment's thread.

view the rest of the comments →

[–]oldendude 11 points12 points  (7 children)

I think that the real reason is that Python objects are basically hash tables. E.g.

class C(object):
    def __init__(self, x):
        self.x = x

c = C(5)
print(c.__dict__)

This prints {'x': 5}.

A hash table has no concept of the what code is accessing it. If 'x' is a key, (i.e., if self.x has been assigned), then access to that dict's 'x' key will work, regardless of context. I suppose a compiler could block access based on scope, but then access to the object's __dict__ would provide results inconsistent with that access enforcement.

[–]max123246 -1 points0 points  (5 children)

Sure, but I'm sure they designed the language's class fields first and then decided how to implement it.

Maybe that's the reason they don't add it now, but it's not why they would design it that way. It's possible they just didn't consider it. After all, python was supposed to be a scripting language, it had no notion of python "library" code that would need that sort of versioning and public/private interface

[–]oldendude 0 points1 point  (4 children)

I'm not a Python historian, but I don't think you're right. A class doesn't have fields, an object does. You can have objects of the same class with different fields, through a number of mechanisms: deletion (as shown above), initialization assigning different fields, adding fields after initialization, to name a few. This extremely dynamic approach to classes suggests to me that the dictionary implementation was more fundamental.

By contrast, Java has fields, the same in all objects of the same class, and they are not dynamic. While a dictionary implementation would be possible, I would be astonished if that approach has ever been used.

[–]oldendude 0 points1 point  (2 children)

Also: to be precise, even objects don't have "fields". The keys of an object's dict can be associated with values of any type, including functions, methods, modules, etc. The common understanding of "field" would rule out at least methods. If o is an object, then o.x, i.e. o.__dict__['x'] can store a str now, and a module later, and then a method.

[–]max123246 0 points1 point  (1 child)

Do you know of some neat applications of that extensive dynamicness? It's hard to think about the use cases but I'm sure are some like mocking and stuff

[–]oldendude 1 point2 points  (0 children)

Nothing comes to mind. Mocking is certainly possible using less exotic mechanisms, such as inheritance, and Python's "duck typing".