On Jan 17, 11:28 pm, Steven D'Aprano <st...@remove-this- cybersource.com.au> wrote: > On Sat, 17 Jan 2009 20:49:38 +0100, Bruno Desthuilliers wrote: > > Russ P. a écrit : > >> On Jan 15, 12:21 pm, Bruno Desthuilliers > >> <bdesth.quelquech...@free.quelquepart.fr> wrote: > > >>> Once again, the important point is that there's a *clear* distinction > >>> between interface and implementation, and that you *shouldn't* mess > >>> with implementation. > > >> If you "*shouldn't* mess with the implementation", then what is wrong > >> with enforcing that "shouldn't" in the language itself? > > Russ: There are SHOULD NOTs and there are MUST NOTs. snip > >>> class Parrot: > > ... _private = 'spam' > ...>>> p = Parrot() > >>> p._private = 'ham' # allowed by default > >>> from protection import lock > >>> lock(p)._private > >>> p._private = 'spam' > > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > ProtectionError: attribute is read-only from outside of class Parrot > > Would that be so bad? I don't think so.
Sorry, I didn't see the last part originally. I don't think 'outside of class Parrot' is well-defined in Python. Does '_private' have to be a member of 'Parrot', an instance of 'Parrot', or the calling instance of 'Parrot', before entering the calling scope, or at the time the call is made? Since many of these can change on the fly, there's more than one consistent interpretation to the syntax. -- http://mail.python.org/mailman/listinfo/python-list
