"sins" (aka, acknowledged language problems)

[Alex Martelli]

John Skaller writes:

> Secondly, the reader has to find the class,
> and try to understand it, and remember its name.
> I think people remember patterns (idioms) better 
> than names.
> 
I guess that's the crux of our disagreement -- a
mixed philosophical and ergonomical issue.  As I
see things (and I know I'm not the only one, since
Gamma et al, Coplien, Martin, have all made this
point in print in the past), a good part of the idea
behind the "design pattern" movement of recent
years is just about this -- NAMING patterns, because,
when a name is attached to a pattern, [some] people
have a MUCH easier time remembering the pattern
and the various "forces" issues attached to it.

I suspect it may have to do with some people's
brains' preference for "verbal" modes of reasoning,
versus others' leaning for "pattern-recognition" modes.
I _know_ I'm an exceedingly verbal person myself,
and I _suspect_ people with verbal orientation may
tend to be over-represented among the authors of
books and articles, for clear self-selection reasons:-).

>  
> > (Despite which, I'd still like to see this wrapper
> > idea [a] either shot to pieces because of some
> > subtle problem I can't see, or [b] made more
> > available as a 'standard' idiom, perhaps in an
> > example or tutorial).
> 
> 	Yeah -- even if it works, you get an uneasy 
> feeling that it make the code a bit harder to read?
> 
But that's just because I'm a newbie in this Python
language -- you should see me operate in realms
I'm more confident about!-)  [Despite my verbal
prowess, I've been unable to help others find strong
enough superlatives of "arrogant" to describe my
attitude when experience backs me up:-)].

Seriously, now -- I _know_ that wrapping a pattern
up in a "keyword" *would* make it harder to read
*unless* the "keyword" itself was familiar to the
reader.  E.g., I used singletons before Gamma et
al. published their landmark work (as did many,
many others, of course -- that's why it IS a common
design pattern, after all!-) but I didn't "name" them
as such -- partly, because that was not my name
for this "idiom" (as I then called it), of course.

But as soon as they published, and the book was
such an instant success, I started using their
design pattern names with abandon (with a biblio
reference in a comment, when I remembered:-).

I don't need C++ to provide me with an _actual_
keyword for it, mind you.  Indeed, I think C++
would be a WORSE language if it had a keyword
such as "singleton", despite the fact that, e.g.,
placing in my header files a construct such as:

	"singleton MyClass;"

might be marginally more readable than using:

	inline MyClass& get_MyClass() {
		static MyClass singleton;
		return singleton;
	}

or other, more long-winded forms.  When
boilerplate is just a few lines, not needing much
repetition, such as here, I don't really mind it
as much as I'd mind an extra few (or MANY:-)
keywords in the language (I guess I would not
be using C++ if I was _really_ allergic to
even modest amounts of boilerplate, hm?-)

But for this to be effective, it does need to be
widely known.  "condition and iftrue or iffalse"
is perceived by many as an unreadable way
to express a ternary operation, although IMHO
it has it all over C's "condition?iftrue:iffalse",
for the sole reason that the latter has had much
exposure (any C programmer has NEEDED to
learn about it), while the former has not -- if
such idioms were more widely promoted in
widespread Python literature, their actual
"readability" would improve... without needing
to change anything in the idiom itself nor in the
Python interpreter.


> 	Python's scopes are NOT simple.
> The idea that 'exactly two scopes' is simpler
> that 'stack of scopes' is a misconception,
> and it doesn't even work in Python: 
> there are at least two places where it fails:
> (a) the __builtins__ hack, to make builtin
> 
OK, _three_ namespaces.  "Nobody expects...".

> functions available, and (b) in except clauses,
> to make the exception available.
> 
*blink* isn't that what sys.exc_info() is for...?

I particularly appreciated Java's abandonment
of classical rules for nested lexical scopes -- the
idea that an identifier in an inner scope hides the
existing outer one silently.  Java makes it an
error to have such a 'hiding', and although the
idea was totally novel to me when I tried Java out,
I think it substantially reduced mistakes without any
real cost in expressiveness.

On meeting Python's simplified approach to scoping
(although you tell me that the "simplicity" is really a
misconception), it seemed to me that this would have
similar but even stronger advantages.


> > What are the drawbacks of supplying the needed
> > wrappers, rather than adding new syntax...?
> 
> 	For a start, efficiency. And, as above,
> readability.
> 
If the wrappers are standardized, readability is no
problem.  And efficiency need not be, either; why
cannot you parse and optimize:

	for key,value in kv_enum(sequence):

just as easily as

	ifor key,value in sequence:

???

As long as the kv_enum (or other name for it) is
a built-in, this would seem just as easy.  And it
does not break older programs using "ifor" as a
variable name, etc (having context-dependent
keyword status, the way PL/I tried to do, has, I
hope, been decisively proved to be a BAD idea,
unless you're the kind of person that *likes*

IF IF = THEN THEN THEN = ELSE ELSE ELSE = IF

and other such endearing PL/I constructs:-).

>  
> > > But 'break'
> > > in python isn't labelled, and there is no goto,
> > > so you end up having to use exceptions ... Uggghhhh.
> > 
> > Labeled breaks might well be a good idea, I guess.
> 
> 	I'm not sure. I also have no candidate syntax
> for defining the labels. Labelled breaks give me
> an uneasy feeling.
> 
I've used them with much happiness in both Rexx and
Java in the past, and I've never seen anything bad
happen, that could be in any way related to them (I'll
tactfully omit mentioning I also used them in Perl, of
course:-).

>  
> > > Of course, most functional languages provide coherent
> > > and very concise ways of doing this kind of thing.
> > > So it is fairly well known WHAT is required, just not
> > > what syntax to use in a 'pythonic' version. :-)
> > 
> > What about the "for x in y" syntax -- that seems neat
> > to me, as long as we can supply the y appropriately:-).
> 
> 	Quite a lot of the time, you CAN provide the y:
> using functional programming with map and reduce etc.
> 
Yep -- and O-O wrappings work for it, too.

> This works well in functional programming languages,
> but it doesn't work nearly as well in python
> What I mean  is, the 'y' becomes so cluttered the reader
> isn't sure what is happening.
> 
Why would it be less cluttered in a functional PL?


> 	for example, to loop thru two lists I can write:
> 
> 	for x,y in zip(l1, l2): ..
> 
> which is something like:
> 
> 	for x,y in map(None, l1, l2):
> 
> although I can never figure map(None, ..) out.
> 
So maybe "zip" should be promoted to official status
as a synonym of "map(None.".  I'm not a _total_
minimalist, you know:-) -- maybe it could have better
optimized semantics specially for use in for loops
(just return one element at a time at __getitem__,
rather than actually building the list in memory --
yep, I _am_ a lazy-evaluation fanatic:-).


> But somehow, this is wrapping the structure TOO much.
> Guido noted something like
> 
> 	for x in l1; for y in l2:
> 
> at the last conference, which is a bit ugly,
> but it _exhibits_ the intended structure better
> than functional wrapping: here I can see a
> pattern, rather than remember a name.
> 
To me, this suggests nested loops -- noticing the
subtle difference of a ";" rather than ":" after I1
seems just like the kind of visual challenge I can
perfectly well do without.


Alex