[Python-ideas] CapPython's use of unbound methods

[spir]

Le Sun, 22 Mar 2009 15:31:15 -0700,
Guido van Rossum <guido at python.org> s'exprima ainsi:

> > To some extent the verifier's check of only accessing private
> > attributes through self is just checking a coding style that I already
> > follow when writing Python code (except sometimes for writing test
> > cases).  
> 
> You might wish this to be true, but for most Python programmers, it
> isn't. Introspection is a commonly-used part of the language (probably
> more so than in Java). So is the use of attribute names starting with
> a single underscore outside the class tree, e.g. by "friend"
> functions.

Just a side note.
In a language that does not hold a notion of private attribute as core feature, "morphologic" (name forming) convention is a great help. I have long thought a more formal way of introducing public interface -- if only a simple declarative line at top of class def -- would be better, but I recently changed my mind. I think now the privacy vs "publicity" opposition is rather relative, vague, changing.
Let's take the case of any toolset/library code with several classes communicating with each other. In most cases, some attributes will be both hidden to client code but exposed to other objects of the toolset. So there are already 3 levels of privacy. If we now introduce tools of the toolset and pure client interface classes we add two levels...
Privacy is relative, so to say conventional; in addition to relative levels, there are also qualitative differences in privacy. Some languages (esp. Java) invent hardcoded languages features in a hopeless trial to formalize all of these distinctions.
The python way of just saying "let this alone, unless you really know what you intend to do" is probably better to cope with such unclear and variable notions.

Denis
------
la vita e estrany