"Johannes Bauer" <dfnsonfsdu...@gmx.de> wrote in message news:min9t3$e56$1...@news.albasani.net... On 10.05.2015 10:58, Frank Millman wrote:
> > It is then a simple extra step to say - > > > > EMPTY_L:IST = () > > > > and if required - > > > > EMPTY_DICT = () > > > > and expand the explanation to show why a tuple is used instead. > > > > So if there was a situation where the overhead of testing for None > > became a > > problem, this solution offers the following - > > > > 1. it solves the 'overhead' problem > > 2. it reads reasonably intuitively in the body of the program > > 3. it is safe > > 4. it should not be difficult to write a suitable self-explanatory > > comment > I do understand what you're trying to do, but it is my gut-feeling that > you're overengineering this and as a side-effect introducing new problems. This has actually gone beyond a practical suggestion, and become more of an academic exercise, so I don't think 'overengineering' comes into it. No-one is recommending that this should be used in real-world code. > With the above declaration as you describe, the code becomes weird: > > foo = EMPTY_LIST > foo.append(123) > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > AttributeError: 'tuple' object has no attribute 'append' > > and > > foo = EMPTY_DICT > foo["bar"] = "moo" > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > TypeError: 'tuple' object does not support item assignment The whole point of this admittedly odd declaration is that no-one should do anything with it at all. It is simply a place-holder to be used in the absence of a real list or dict provided by the caller of the function. The starting premise was that the function would only read from the list/dict, not try to modify it. Frank -- https://mail.python.org/mailman/listinfo/python-list
