Python-list digest, Vol 1 #10572 - 14 msgs

[Steve Holden]

"James J. Besemer" <jb at cascade-sys.com> descended from the mountain to
confess...
> [...]
> I am probably in the minority here in that I have little patience for
people
> who are "confused" by or have difficulty with advanced language features.
> If you purport to be a professional programmer then you should know the
> base language cold.

Well, on this particular group I feel you *are* in the minority. Many c.l.py
readers are *not* "professional programmers", but chemists, mathematicians,
biophysicists, and a host of others for whom programming is a means to an
end. Many others are, like me, professional programmers who attempt to
increase Python's popularity by assisting those less familiar with
programming concepts.

Furthermore, you express exactly the kind of attitude that gets
"professional programmers" a bad name. Let's remember our social skills here
;-). Remember, Python is *not* just for professional programmers, so you
shouldn't write as though it were "your" language.

In summary: "professional" as a self-description leads people to expect
certain standards of behavior. Your income mightr derive from programming,
but that's only a *part* of being professional.

> So I am not swayed by arguments that :? confuses people.

So, if one is confused, one should leave the job of programming to the
professionals? That will help the programmer shortage.

> But I think part of the problem
> with inline choice is that people who use it do not properly
> parenthesize and indent it to properly highlight what's going on.
> I always split the test and the two alternatives on separate lines,
> with each of the latter two starting with the special operators.
>
>     def abs( n ):
>         return (( n > 0 )
>                       ? ( n  )
>                       : ( -n ))
>
I take it you're using some sort of "desirable" extension syntax here? I
completely fail to see how this is preferable to the instantly
comprehensible

    def abs(n):
        if n > 0:
            return n
        else:
            return -n

(except that this wouldn't confuse anyone). Although I'm told there's a
special place reserved in Hell for those who practice such abuse, it is of
course legal syntactically to rewrite this as

    def abs(n):
        if n>0: return n
        else: return -n

By the way, please note that there *is* a style guide for Python, which you
will, find at

    http://www.python.org/peps/pep-0008.html

It unequivocally states that spaces should not be used after opening
parentheses or before closing ones. So, while we're talking about "proper"
usages, let's get them *all* right, shall we?

> You'd never write if/then/else without proper indentation
>  (not even possible in Python ;o).  Same rules should apply
>  to complex expressions.
>
> Python's and/or semantics, although they may be employed
> to provide similar functionality, are more general, unrelated
> and in most cases an inappropriate substitute.
>
> Thus although you can use and/or as a partial substitute, there are
problems with the hack:

Indeed. An experienced (professional?) programmer would, of course, consult
the FAQ. See

    http://www.python.org/cgi-bin/faqw.py?query=ternary&req=search

for further discussion on this topic.
>
> Most importantly (a) the and/or idiom strays from the desired abstraction
and thus obscures the intent of the developer.
>
I agree with this. But don't try to suggest that there aren't problems with
the ternary construct in C, most notably the omission of an "=" in the test,
turning a test into an assignment.

> (b) Since and/or lacks clarity it arguably is more likely to
> people than inline choice.  And whereas :? confuses beginners,
> and/or (since it's an idiom rather than a language construct)
> is more likely to confuse more advanced users.

[I presume that should have been "...likely to confuse people ..."].
Frankly, I don't think a language that "confuses beginners" is likely to
develop a huge following, since everyione is a beginner at the start. I
think confusion of *any* kind is to be avoided, and Python does as well as
most languages in this respect. I particularly dislike your implication that
if anyone is to be confused it should be the beginners and not the
"professional programmers".
>
> (c) Worst of all, the idiom doesn't even work in all cases, thus admitting
the possibility of subtle, unintentional, seemingly intermittent errors,
e.g.:
>
>      x = ( len( s ) > 0
>                      and s[0]
>                      or -1 )     # FAILS!!  when s[0] == 0
>
Sorry, this is abuse. Also see the FAQ reference above.

> To me clarity of expression is the most important quality of a well
> written program.  Binary conditional evaluation ala ?: is indispensable.
>  It's eminently reasonable for programmers to feel a "need" for such
> an addition to Python.
>
To me, clarity of expression is the most important quality of a well written
program. Binary conditional evaluation ala ? is completely unnecessary. It's
eminently reasonable for programmers to feel a need for such an addition to
Python, but once they have been reeducated the feelings will go away.

> Biggest issue the syntax.

I disagree. The biggest issue is the bloat this will introduce into the
language, and programs written in it, without the least advantage. YAGNI.

> With ":" used the way it is in Python, C's :? syntax probably is not an
easy fit.  One possibility might be to reverse the two symbols:
>
>     x = ( len( s ) > 0
>             : s[ 0 ]
>             ? -1 )
>
> Having ":" separate the test expression from the two alternatives seems
sorta natural.
>
Blerch. This is supposed to be easy to understand? In which universe. I
submit it's completely unpythonic.

> Another alternative would be to borrow from Algol68 and (IIRC) Algol60.
They allowed if/then/else to be embedded within an expression.  Generalizing
if:/else: to return a value also seems somewhat natural, so perhaps that
could work.
>
>     x = ( if len(s) > 0:   s[ 0 ]
>                        else:    -1 )
>
> Since it's all within an expression, indentation doesn't matter.
>
> Just a thought....
>
Well, there were problems with Algol 60's conditional expressions, but I
agree that *in a free-form language* they are useful and fairly natural.
Python, of course, is not a free-form language, and so inline conditionals
of any kind are a far less natural fit with the rest of the language.

This isn't the first time this topic has been dragged out of retirement, and
I don't suppose it will be the last. It's probably obvious that your post
got up my nose -- I'm not normally so crotchety, so I guess I should
apologise for the cranky nature of my reply. I shall not be contributing
more to this thread.

maybe-i-should-have-another-cup-of-coffee-ly y'rs  - steve
--

home: http://www.holdenweb.com/    book: http://pydish.holdenweb.com/pwp/