Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #89494
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Newsgroups | comp.lang.python |
| Subject | Re: Not possible to hide local variables |
| Date | 2015-04-28 12:20 +0300 |
| Organization | A noiseless patient Spider |
| Message-ID | <87pp6oip7x.fsf@elektro.pacujo.net> (permalink) |
| References | <874mo0zoz2.fsf@Equus.decebal.nl> <553f46d2$0$11124$c3e8da3@news.astraweb.com> |
Steven D'Aprano <steve+comp.lang.python@pearwood.info>:
> The convention is, if the caller messes with your private attributes
> or variables, and their code breaks, they have nobody to blame but
> themselves, and we are allowed to laugh at them. We're consenting
> adults here.
I would take it further: as a rule, user code should not think of
modifying the contents of an object unless it is clearly documented as a
supported operation. IOW, you should consider all attributes private, or
at least read-only.
BTW, the principle is actually enforced for some objects:
>>> "hello".join = lambda *x: "world"
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'str' object attribute 'join' is read-only
>>> "hello".joinn = lambda *x: "world"
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'str' object has no attribute 'joinn'
>>> "hello".__setattr__ = lambda *x: None
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'str' object attribute '__setattr__' is read-only
A tougher issue is with encapsulation. A derived class might
accidentally step on the toes of the base class by redefining an
attribute:
========================================================================
class Base:
def __init__(self):
self._secret = 17
def divulge_secret(self):
return self._secret
class Derived(Base):
def __init__(self):
self._secret = 1
print(Derived().divulge_secret())
========================================================================
which outputs 1.
Marko
Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Not possible to hide local variables Cecil Westerhof <Cecil@decebal.nl> - 2015-04-28 09:33 +0200
Re: Not possible to hide local variables Ethan Furman <ethan@stoneleaf.us> - 2015-04-28 00:56 -0700
Re: Not possible to hide local variables Cecil Westerhof <Cecil@decebal.nl> - 2015-04-29 08:16 +0200
Re: Not possible to hide local variables Michael Torrie <torriem@gmail.com> - 2015-04-29 21:10 -0600
Re: Not possible to hide local variables Chris Angelico <rosuav@gmail.com> - 2015-04-28 18:06 +1000
Re: Not possible to hide local variables Cecil Westerhof <Cecil@decebal.nl> - 2015-04-29 08:25 +0200
Re: Not possible to hide local variables Chris Angelico <rosuav@gmail.com> - 2015-04-29 17:36 +1000
Re: Not possible to hide local variables Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-04-28 18:37 +1000
Re: Not possible to hide local variables Chris Angelico <rosuav@gmail.com> - 2015-04-28 18:44 +1000
Re: Not possible to hide local variables Marko Rauhamaa <marko@pacujo.net> - 2015-04-28 12:20 +0300
Re: Not possible to hide local variables Cecil Westerhof <Cecil@decebal.nl> - 2015-04-29 08:32 +0200
Re: Not possible to hide local variables Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-04-30 14:05 +1000
Re: Not possible to hide local variables Marko Rauhamaa <marko@pacujo.net> - 2015-04-30 08:10 +0300
Re: Not possible to hide local variables Chris Angelico <rosuav@gmail.com> - 2015-04-30 16:01 +1000
Re: Not possible to hide local variables Cecil Westerhof <Cecil@decebal.nl> - 2015-04-29 08:14 +0200
Re: Not possible to hide local variables Grant Edwards <invalid@invalid.invalid> - 2015-04-29 14:16 +0000
Re: Not possible to hide local variables Dave Angel <davea@davea.name> - 2015-04-29 22:31 -0400
Re: Not possible to hide local variables Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-04-30 08:53 -0400
Re: Not possible to hide local variables Cecil Westerhof <Cecil@decebal.nl> - 2015-04-30 16:50 +0200
csiph-web