Let me add that one can do this: class Dummy(object): def __getitem__(self,key): return getattr(self,key) def __setitem__(self,key,value): return setattr(self,key,value) def __getattr__(self,key): return self.__dict__.get(key,None) d=Dummy() d.something = 5 print d.something print d.somethingelse which is more or less efficient and accomplished 4. Not as fast as a dict anyway. On Jan 30, 2012, at 12:49 PM, Massimo Di Pierro wrote:
Trying to make sure I understand where we disagree and perhaps explain my problem better. For me this has very little to do with dictionaries.
STEP 1) Today we can do this:
class Dummy(object): pass
d = Dummy() d.something = 5 print d.something
Is anybody calling this un-pythonic?
STEP 2) We can now overload the [] to make the dynamic attributes accessible in an alternative syntax:
class Dummy(object): def __getitem__(self,key): return getattr(self,key) def __setitem__(self,key,value): return setattr(self,key,value) d = Dummy() d.something = 5 d['something'] = 5 print d.something print d['something']
STEP 3) Is anybody calling this un-pythonic?
We can add redefine __getattr__ so that it never raises an exception:
STEP 4) class Dummy(object): def __getitem__(self,key): return getattr(self,key) def __setitem__(self,key,value): return setattr(self,key,value) def __getattr__(self,key): return object.__getattr__(self,key) if hasattr(self,key) else Dummy()
Is this un-pythonic?
I do not think so but I do have a problem with it:
class Dummy(object): def __getitem__(self,key): return getattr(self,key) def __setitem__(self,key,value): return setattr(self,key,value) def __getattr__(self,key): print 'wtf' return object.__getattr__(self,key) if hasattr(self,key) else None
d=Dummy() print d.somethingelse wtf ... 334 wtf times with python2.7, 999 times with python2.5... wtf None
whatever this does internally, it makes some programs slower then I would like them to be. Why is it calling itself 334 times?
STEP 5) We can add methods to make this object behave like a dictionary by redefining d.keys() in terms of d.__dict__.keys() etc.
STEP 6) we can re-factor it a bit so that actually class Dummy is derived from dict.
Is this the part that people do not like?
I would be happy if Python provided an efficient way to do something like STEP 4 without the problem I mentioned. Perhaps there is one and I ignore it. I do not necessarily require STEP5 and STEP6.
Use case:
settings = Dummy() settings.parameter1 = 'a' settings.parameter2 = 'b' etc.
if not settings.parameter1: do something ...
Massimo
On Jan 30, 2012, at 11:28 AM, Eric Snow wrote:
On Mon, Jan 30, 2012 at 10:14 AM, Arnaud Delobelle
wrote: On Jan 30, 2012 4:23 PM, "Massimo Di Pierro"
wrote: I do not think the issue is whether the people who use that semantic understand it or not. I can assure you they do and they know when it is appropriate to use it or not. The issue is whether there is any value is making it faster by including it in python or not. Because of the increasing popularity of JS I think new users are starting to expect something like it out of the box.
But this design decision in JavaScript is at the heart of many problems (e.g. simply looping over keys is a pain). That it is widely used doesn't make it desirable. My experience with JavaScript is that we should keep this 'feature' out of Python. If people want it they can implement it very easily but encouraging them would be wrong.
+1