On Sat, Jan 31, 2009 at 9:08 AM, <thmpsn....@gmail.com> wrote:
So what, though?
If you're a application developer, writing your own code: just don't do it.
You've now achieved enforced encapsulation! Why does the language
need to check that?
If you're the user of a library and you need access to a private member
of that library: again, just don't do it! Write a patch and maintain a
private fork to expose the member function, and submit it to the developer
and hope it gets included so you don't have to maintain the private fork.
For those people who need access to that internal Right Now and don't
want to wait for the developer to expose it, because its important to them
why should the language forbid it? Sure, its an ugly hack. But so what?
They're doing it, at the risk of future breakage if anything changes in
that undocumented internal detail, because they need to. There are
situations where maintaining a private fork to expose something in a
library is a far greater burden and not worth it.
If you're the writer of a library, why do you even care if the people who
use it access an undocumented internal? If anything breaks its not
your problem.
If you're in some corporate environment which has a 'no fiddling with
the privates of another teams modules' -- why do you need the language
to enforce that restriction? If your employees aren't following the coding
standards of your own organization, that's a problem. Surely it'd come up
very quickly with even the most cursory of reviews, after all "obj._variable"
is really obviously not "self._variable" and so pretty obviously accessing
someone elses private state.
If you're in an open source environment and are worried about quality
of code from lots of contributors who aren't being paid: again, reviews
should be happening /anyways/.
In the end, why bother? If you believe in absolute encapsulation its
extremely easy for you to get it in Python, today... don't touch someone
elses privates.
Sure, the design is flawed. Doesn't change the fact that you need to access
that internal state. "Providing a getter" is not necessarily simple: what if
its someone elses code? At the very least you have to maintain a private
fork then /or/ wait until they get around to fixing the design. Sometimes that's
no big deal. Sometimes it is.
I find marking my constants as SOME_CONSTANT instead of some_constant
to be more then sufficient usually. In the case where I do want to let someone
read a piece of data and not write it, I find a getter accessing a private member
variable without a corresponding setter perfectly fine.
If the users of the code choose to dig inside my class and fiddle with that
private member -- woe on them! I wash my hands of any trouble they
have.
--Stephen
On Jan 30, 12:15 am, Chris Rebert <c...@rebertia.com> wrote:How do you know? (I know I'm not.)
> - Python supports encapsulation. Prefixing an attribute/method with an
> underscore indicates that other programmers should treat it as
> 'private'. However, unlike B&D languages, Python itself does nothing
> to enforce this privacy, leaving it instead to the good judgement of
> the programmer, under the philosophy that "We're all consenting adults
> here".
Seriously, though, the lack of private members does allow for ugly
hacks in user code, and you know there are always ugly hackers.
So what, though?
If you're a application developer, writing your own code: just don't do it.
You've now achieved enforced encapsulation! Why does the language
need to check that?
If you're the user of a library and you need access to a private member
of that library: again, just don't do it! Write a patch and maintain a
private fork to expose the member function, and submit it to the developer
and hope it gets included so you don't have to maintain the private fork.
For those people who need access to that internal Right Now and don't
want to wait for the developer to expose it, because its important to them
why should the language forbid it? Sure, its an ugly hack. But so what?
They're doing it, at the risk of future breakage if anything changes in
that undocumented internal detail, because they need to. There are
situations where maintaining a private fork to expose something in a
library is a far greater burden and not worth it.
If you're the writer of a library, why do you even care if the people who
use it access an undocumented internal? If anything breaks its not
your problem.
If you're in some corporate environment which has a 'no fiddling with
the privates of another teams modules' -- why do you need the language
to enforce that restriction? If your employees aren't following the coding
standards of your own organization, that's a problem. Surely it'd come up
very quickly with even the most cursory of reviews, after all "obj._variable"
is really obviously not "self._variable" and so pretty obviously accessing
someone elses private state.
If you're in an open source environment and are worried about quality
of code from lots of contributors who aren't being paid: again, reviews
should be happening /anyways/.
In the end, why bother? If you believe in absolute encapsulation its
extremely easy for you to get it in Python, today... don't touch someone
elses privates.
If it ends up being necessary, the class's design is flawed. (Though
> This allows people to meddle with internals, at their own risk,
> if it ends up being absolutely necessary.
in this case, the flaw is easily solved by simply providing a getter.)
Sure, the design is flawed. Doesn't change the fact that you need to access
that internal state. "Providing a getter" is not necessarily simple: what if
its someone elses code? At the very least you have to maintain a private
fork then /or/ wait until they get around to fixing the design. Sometimes that's
no big deal. Sometimes it is.
In the absence of private/protected, Python should at least provide
something similar to C++'s 'const' or Java's 'final'. (Similar, not
equivalent, because then the object itself wouldn't be able to
manipulate its own members!)
I find marking my constants as SOME_CONSTANT instead of some_constant
to be more then sufficient usually. In the case where I do want to let someone
read a piece of data and not write it, I find a getter accessing a private member
variable without a corresponding setter perfectly fine.
If the users of the code choose to dig inside my class and fiddle with that
private member -- woe on them! I wash my hands of any trouble they
have.
--Stephen
signature.asc
Description: OpenPGP digital signature
-- http://mail.python.org/mailman/listinfo/python-list
