is Python fully object oriented ?

[Alex Martelli]

"Ben Hutchison" <benh at intelligenesis.net> wrote in message
news:mailman.979279694.10695.python-list at python.org...
    [snip]
> > About a year
> > ago, I discovered Python and have since then written thousands of lines
> > of Python code, yet have not once experienced the typing of "self." to
> > be overhead,
>
> Im sure you grow used to it, but Im not convinced its preferable. My
general
> preference, shared by many programmers I suggest, is that extraneous code
be
> minimized.

Right, but scope clarification isn't "extraneous" -- it's as simple as this.

> That also seems to be a theme in pythons design, I notice. Its perfectly
> legal to explictly use "this" everywhere in C++/Java if you like it that
way, you
> just arent forced to.

And by 'not being forced to', the scope of a non-explicitly-scope-clarified
symbol can become very mysterious (particularly in C++).  Are you _sure_,
when you see an undecorated symbol in code you're maintaining or porting,
that the interpretation of subtle and refined scoping rules is perfectly
aligned between...:
    a. the original coder,
    b. intervening maintainers,
    c. yourself,
    d. future maintainers,
    e. the original compiler,
    f. the current compiler,
    g. future compilers,
    h. the ISO Standard...?

What with 'Koenig lookup' and the distinction in templates between
dependent and nondependent symbols, it DOES get subtle indeed -- most
particularly because the rules shifted somewhat (subtly, of course:-),
around standardization time, to facilitate precompilation of templates
(portions thereof, at least).  In fact, this makes lookup of such
undecorated symbols one critical issue to watch out for when porting,
if any compiler or coder is involved whose 'standard compliance' you
cannot entirely vouchsafe for.  Out of 100 very good C++ coders I know,
there is NONE I'd be 100% certain will get all such lookup issues right,
considering occasional coding performed in low-caffeine situations --
and that does include myself, Brainbench MVP for C++, 'reference guru'
for all C++ language/compiler issues for my employers, and with over
a decade of C++ experience.

It's inevitable that a language as rich and complex as C++ will have
obscure, dusty corners just waiting to trap the unwary, of course. But
it's one thing to worry about, say, "pointers to members in templates
where a virtual base, and overloads, may or may not be present" --
*that* kind of obscurity can normally be finessed by sticking to a
'safe' (ha!) subset of the language (a good idea, given the bugs that
DO about in popular compilers, related to such 'corners').  But, when
something as bread and butter as "what does `foo' refer to here" gets
involved, now THAT becomes a really sticky situation.  You'll never
get C++ users to agree to never code just 'foo' but always, more
explicitly, this->foo, AClass::foo, ::foo, etc (and if you did you'd
have problems, since namespace-transparence is SO important in many
C++ usage contexts!).

Java isn't _quite_ as thorny, by a long shot (no namespaces existing
across classes, no multiple inheritance of implementation, it's an
error if a local variable's name 'shadows' an outer-nested homonym --
a combination of many such limitations and restrictions does help in
clarifying things wrt C++ name-lookup rules!).

But Python's choice (historically inspired, I believe, by Modula-3)
is even simpler and more straightforward (it will get slightly less
so when nested-scopes are added, as it seems they'll be, but only
marginally so, we can hope).


> > > * Is Pythons leading underscore mechanism more of a convention?
> >
> > > * It is strong enough to build security mechanisms on?
> >
> > Even the C++ support for public/protected/private access is not strong
> > enough to enforce security. <snip>
>
> In other words, no. However, Java's is. private members really are very
private, and
> this gives the programmer design options not available perhaps in Python.
IMO, cases
> where you simply cant do something, by any technique, in a language, are
ones to
> watch out for. Possibly python could benefit from a strong private
modifier.

Not really, because Python relies on a completely different approach
to "build security mechanisms on" -- see Chapter 16, "Restricted
Execution", in the online Python Library Reference.  Java's approach
to security is hardly a shining beacon for the world, IMHO -- it's
still to be proven that the security mechanisms it built on top of
its "very private members" are yet solid, despite mucho patching
and reworking since their very first release.

I forget the origin of the quote, but -- "there are two approaches
to [coding]: make it so complex there are no obvious flaws, or,
make it so simple there are obviously no flaws".  When security
is involved, you definitely want the SECOND approach (the slant
of the quote, of course, is clearly that you just about always
should prefer the second, but security issues make that choice
particularly apt:-).

Re "cases where you simply can't do something, by any technique,
in a language": what about binary (no library mods allowed) reuse
of library code using "really very private" variables, in Java,
when it turns out the library's design isn't _quite_ perfect and
its author has omitted to provide an accessor for a little piece
of state you desperately need to know...?  Of course, we all know
library designers ARE always-right, perfect, superhuman beings,
so the issue is merely theoretical, but, if these are indeed the
"cases ... to watch out for", this one would seem interesting.

Anyway, security definitely is NOT something you "can't do by
any technique" in Python.  The language itself, here as in so
many other places, provides very simple, usable infrastructure;
you design or adopt modules using and wrapping that for the
specific purposes of your application, depending on the exact
nature of the 'untrusted code' you're dealing with.


> Except security. And in some domains, where you have someone elses
untrusted code
> executing, that really does matter. Python can prevent accidental access
to private
> fields but not a deliberate attempt. When people consider building very
large
> systems from python, they surely will encounter this barrier. It may
prevent pythons
> use where it would otherwise be appropriate.

People _have_ built very large systems in Python, but security
can be an issue even in pretty-small ones -- any time you get
code snippets from the net, from an interactive user, from a
database that might have been tampered with.  And you *can*
deal securely with such untrusted code -- not claiming it's
EASY (I know of NO language that makes security truly easy:
you are hypothetically dealing with a would-be invader who must
be presumed to be at least as smart as you, remember:-), but,
it IS as DOABLE as in any other language I know.


Alex