Is this unpythonic?

[Frank Millman]

"Johannes Bauer" <dfnsonfsduifb at gmx.de> wrote in message 
news:min9t3$e56$1 at 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