Why does python not have a mechanism for data hiding?

Fuzzyman fuzzyman at gmail.com
Sat May 24 13:02:17 EDT 2008


On May 24, 4:56 pm, vivai... at gmail.com (Ville M. Vainio) wrote:
> Fuzzyman <fuzzy... at gmail.com> writes:
> > The 'we told you not to use that' approach, when applied to paying
> > customers doesn't really work... all they see is that you broke
> > their spreadsheet code by changing your API.
>
> And the customer point of view is quite reasonable - they have a job
> to do, and a limited timeframe; sometimes accessing privates directly
> is much better than waiting for updates from vendor. Bad designs (as
> far as choosing publics goes) happen.


They will use whatever they find, whether it is the best way to
achieve a goal or not. Once they start using it they will expect us to
maintain it - and us telling them it wasn't intended to be used by
them in the first place won't cut it.


>
> Even if their softare breaks on upgrade, you can quite clearly point
> out that they used an internal api - and they will keep on using the
> old version until they solve the problem. Everybody wins.
>

Not if they are waiting for a fix or new feature in the upgrade - and
we can't refactor because they are relying on APIs that we want to
remove.

We very much lose.


> Perhaps a lint-like validation tool would be optimal for this
> problem...

So we can refuse to execute their code if they use private APIs?

Proxying so that we can really hide our internal APIs is a better
solution.

This hasn't happened to us yet (our application has only been in
commercial use since January), but it is one of the reasons that
Microsoft's COM APIs grew so wide and wild, and caused them very real
problems in trying to improve them. We are keen to avoid the same
situation.

Michael Foord
http://www.ironpythoninaction.com/



More information about the Python-list mailing list