[Python-Dev] Single- vs. Multi-pass iterability

[Alex Martelli]

On Tuesday 16 July 2002 01:46 am, Barry A. Warsaw wrote:
> >>>>> "AM" == Alex Martelli <aleax@aleax.it> writes:
>     >> what Zope does AFAIK).  Otherwise creating minor variations on
>     >> a class would be quite a pain -- you'd have to repeat all the
>     >> interfaces implemented by the base class; and what if a later
>     >> version of Super implements more interfaces?
>
>     AM> This is actually a difficult point.  If I have to explicitly
>     AM> state all the interfaces of Super that I want to _exclude_,
>     AM> and Super adds some more interfaces tomorrow, then it's quite
>     AM> possible that my class is suddenly broken -- it doesn't
>     AM> guarantee the invariants that says it guarantees, any more --
>     AM> and I don't even know about it.
>
> You'd need a way to explicitly state that you implement /none/ of the
> interfaces of your superclass, and then explicitly add back the ones
> you do implement.

Right -- "i inherit the implementation but none of the interfaces".  You
can express this either by appropriately tagging the "I inherit" part, as
C++ does (private inheritance -- the default, but that's yet _another_
C++ issue... defaults that may or may not be appropriate for typical
use!-), or with a variation of "exclude-interfaces" however you spell that.

Alternatively, "I inherit" could default to "not the interfaces", and, if
needed, one might add a clause "oh, and all the interfaces too, please"
when that is positively desired.  Maybe the default would best be
chosen on the basis of "what is good for them" rather on "what appears
most desirable intuitively", as is currently done for module imports.

Defaulting to "i inherit all" is roughly as convenient as defaulting to
"from amodule import *" would be felt to be by naive users unfamiliar
with the issues of namespace pollution.  You know, "convenience" is
getting to be something of a dirty word:-).  Knuth said "premature
optimization is the root of all evil in programming", and no doubt he
was right for HIS generation -- people who grew up on machines with
a few KB of memory and small fractions of MIPs were warped for life
by the need to squeeze every possible drop of optimization.  We still
have some of that, no doubt.  But current generations of programmers
grew up on machines of overwhelming power -- gradually, the pitfall of
premature optimization becomes less pervasive.  OTOH, the same
programmers grew up on machines overburdened to the gills with a
surfeit of "convenient" features... a new "root of some evil" is
emerging, and it's spelled "convenience".  Perl's surfeit of ad-hoc,
context-dependent, highly-"convenient" surprises just waiting to trip
you at every step should be an object lesson in "convenience".

Simple, clean, orthogonal, predictable, clear, unsurprising, regular.

Now THESE are the buzzwords I long for... "convenient", OTOH, makes
me wary.  Convenience has its place, just as does optimization, and
Python has traditionally done a great job of supplying just enough
optimization and just enough convenience without compromising the
really important buzzwords above listed.  OTOH, the BDFL does say
that he's not very experienced with "components" (interface-based
programming); and few can claim extensive experience with many
different nuances of that (on introspection, I _would_ claim for myself
extensive experience with production use of COM, but a bit lesser with
"bare C++" [a la Lakos, say] and definitely not "extensive" for Java, Haskell 
and others).

Would we REALLY like to have:
	import foo
do the equivalent of today's
	from foo import *
and have to explicitly say
	import foo dont_pollute_my_namespace
to get today's "import foo" behavior?  I'm sure many beginners would love
it -- you have to pound their heads with a mallet to wean them off the
"import *" even today, particularly if they come from languages which
offer the equivalent facility (e.g., C++'s "using namespace" -- back in 
think3, I got hoarse from having to repeat over and over again that making
"using namespace std;" a standard prologue of every source file was NOT
clever -- and I'm talking about able, mature programmers, quite used to
large-scale programming in C++... but namespaces were new, and were
perceived as "inconvenient"...!).  Now, the amount of desirable separation
between components may be lesser than the high separation that is most
desirable between modules / namespaces -- but it IS higher than that most
desirable between "ordinary" objects under inheritance.  I surely don't know
"the solution", but I just as surely do feel there ARE issues here that are
worth pondering about.


Just my two Eurocents (now worth slightly MORE than 2 cents of US$...!-)

Alex