Steve Holden wrote: [was Python-list digest, Vol 1 #10572 - 14 msgs]

[Steve Holden]

"James J. Besemer" <jb at cascade-sys.com> wrote at almost interminable length
...

[disclaimer: this time I really will not be following up, unless I can do so
in less than twenty words...]
>
> "James J. Besemer" wrote:
>
> > Steve Holden wrote:
> >
> >> Well, on this particular group I feel you *are* in the minority.
> >
> > As I acknowledged up front.
> >
> >> 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.
> >
> > Some of the better "professional programmers" that I have had the
> > pleasure to work with or employ had formal training in chemistry,
> > physics or math rather than "computer science".  Some of the worst
> > programmers had CS degrees from big name schools and couldn't design
> > their way out of a paper bag.  I think the scientists tend to come to
> > the subject of programming with more maturity, discipline and focus
> > than some with formal [sic.] training in CS.
> >
Perhaps because they see programming as a means to an end and not just an
end in itself.

> > I think some people have a natural aptitude for programming and some
> > people do not.  It has nothing to do with educational background.  The
> > ones with the aptitude excel and the ones without tend to average or
> > sub average work.  I also know that basic programming tasks may be
> > completed by children, so the basic skills are not at all hard to
> > master.
> >
> > I also have had experience coaching newbies in Python and other new
> > languages and also I have spent time teaching programming to middle
> > school kids.  At one point in my life, I worked supporting a bunch of
> > EE researchers who were not programmers, so I think I actually relate
> > to this community better than it may appear on the surface.
> >
> > I guess my main point, which I don't want to get lost is that we DON'T
> > have to dumb down the language in order to help beginning users.
> >
Well, the "future division" discussiosn seemed to see most resistance to the
change from long-term programmers, though really it's probably no big deal.
And you must know (or not) that Guido has interests in "Computer Programming
for Everybody"?

> >> 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.
> >
> > I apologize for any offense I may have given.  I'm new here and I'm
> > the type of person that tends towards direct talk.  I see in this
> > social setting it distracts from my message rather than (as I am used
> > to) lending clarity.  Please forgive me for coming on too strong.
> >
That's OK. I'm from Yorkshire myself, and I've had to consciously reduce my
directness level somewhat since I moved to the USA. It's probably not your
fault you got up my nose ;-)

> > I certainly make no presumption that Python is "my" language.  If I
> > were king, there is a very short list of relatively minor things I'd
> > change immediately, adding a ternary operator being one of them.  And
> > if a topic I care about comes up on the list (I did not start the
> > thread) I feel I have every right to chime in with my opinion, humble
> > or otherwise.
> >
Right, right.

> > More importantly, I don't think we have to make a choice to optimize
> > only for "pros" or only for newbies.  Seems to me already Python is a
> > large and in places a complicated language.  To it's credit, it's way
> > easier to learn and use than Perl, which is the closest practical
> > alternative around today.  There are and always will continue to be
> > advanced topics that will take newbies time to absorb (possibly
> > forever).  Given the overall complexity of the system, seems to me
> > that little items such as a ternary operator are way down in the
> > noise.
> >
> > Does anybody honestly think the addition of a ternary operator would
> > be more confusing to newcomers than the business with lexical scope
> > changing behavior over time?  Iterators?  Generators?  List
> > comprehensions? Unifying types and classes?  Sockets, Select, Polling
> > Objects, multi-threading and synchronization of concurrent
> > programming?
> >
> > No.  Arguing that comparatively trivial extensions such as ternary
> > choice will hurt beginners is pure rhetoric, simply superstitious
> > behavior.  The conclusion is foregone and you use this specious
> > argument to rationalize your prejudice.
> >
Well, like some of the features you mention above, a ternary operator could
easily be ignored. But in that case why have it in the language. I simply
tried to assert my own opinion (as someone whe's been programming a long
time and doesn't much like C) that an if: then: else: combination is
clearer.

There are reasons (mentioned in the FAW) why Python is not an
expression-based language such as Icon, and the philosophy of ternary ? is
kind of against that.

Ultimately we are probably simply debating our own prejudices, though, and I
have no objection to you preferring yours ...

> > For the most part, beginners are focused on getting their own programs
> > to work.  Like with Lexical scope, they can simply ignore the issue
> > for the most part until they gain sufficient experience with the
> > language (along with larger applications).  If they run into questions
> > about constructs they do not understand, then they can look things up
> > in the doc.  But seriously, is your typical newbie going to have more
> > trouble understanding a simple inline choice operator or some code
> > that relies on some subtle aspect of dynamic scoping?
> >
> > Seriously, would something like
> >
> >     x = ( if a>b : a else: b )    # trivial example, would be more
> > complex in real life
> >
> > truly be all that much more confusing for your average newibe than
> >
> >     y = [ func( i ) for i in collection ]    # trivial example, would
> > be more complex in real life
> >
> > Wouldn't the second, existing construct actually be MORE confusing?
> >
> > Ha!  I bet your mythical newbie would be LESS confused by the proposed
> > ternary operator than by the recommended substitute:
> >
> >     x = ( a > b and [ a ] or [ b ])[ 0 ]
> >
> > It'll confuse almost everybody.
> >
> > We already added an "inline FOR", what could possibly be so bad about
> > an "inline IF"?
> >
Well, apart from the if's in list comprehensions such as [x for x in
range(5) if x % 2], I presume you mean. Note that the list comprehension
doesn't include any colons, however. Patching up the syntax might not be a
simple matter, but I haven't seen any suggestions I like.

> > Finally, many the sophisticated concepts mentioned earlier I expect
> > were dreamed up by people with specialized training in software.  Not
> > to put anyone down but people with specialized training and experience
> > in the field of programming and programming languages often are better
> > able to articulate new features like this and figure out how best to
> > fit them into the language.  Just a factual statement, no offense
> > intended to anyone trained in different fields.
> >
> >> > 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.
> >
> > That's not at all what I said.
> >
> > Rather, (a) the average user is smart enough to NOT be confused, and
> > (b) there likely is something to be learned from people with a lot of
> > technical experience and expertise in the matter.
> >
> > You refer to all the scientists who use Python.  I'm sure they've all
> > taken calculus, linear algebra and undoubtedly mastered lots more
> > complicated subjects.  I find it impossible to believe that this
> > august group could not in time come to master the syntax and semantics
> > of such a simple, useful and not all that unfamiliar of a construct.
> > If I was one of these mythical users, I'd be insulted that you presume
> > I'm so stupid.
> >
> > I sense that this is a religious issue, so both parties will resort to
> > elaborate arguments, well out of scope of the actual issue.  All
> > bullshit aside, do you really and sincerely in your heart believe that
> > this feature alone would "bloat" the language, actually harm the user
> > community and materially detract from Python's growing "following?"
> >
Not really. I believe this discussion has appeared so many times before that
we can reliably predict it's not going to happen. Just trying to save you
some time ...

> >> > 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?
> >
> > Yes.  Here, I'm attempting to employ C's :? operator within Python.
> > I'm sorry, previous posts seemed to assume that people generally knew
> > what it meant, so I apologize for relying on that evidently
> > presumptuous presumption.
> >
> >> I completely fail to see how this is preferable to the instantly
> >> comprehensible
> >>
> >>     def abs(n):
> >>         if n > 0:
> >>             return n
> >>         else:
> >>             return -n
> >
> > In this case you are right there is little advantage.  But I find
> > cases frequently arise where the decision appears nested in a larger
> > expression (other than the entire body of a function) in which return
> > would not be a legal or meaningful alternative.  [For a change of
> > pace, and a test of your intellectual honesty, you give an example and
> > I'll translate it to existing Python.]
> >
Not sure I like the flavor of that last sentence, but we'll overlook it for
now.

> > In any language, you always can get by with additional declarations
> > (functions and/or auxiliary variables).  To some, this improves the
> > readability of the program.  To others, like myself, it obfuscates the
> > meaning.  In any case, creating additional steps creates extra,
> > unnecessary work for the computer and there are cases in inner loops
> > where such differences in performance may be significant.  Since the
> > extra program steps furthermore are unnecessary, it's doubly
> > irritating to have to spell it out.  I.M.H.O.
> >
So, you tend towards the functional. Nothing wrong with that, but you should
be aware that Guido's on record as regretting allowing the modest functional
constructs the language already has, and presumably leaves them in to avoid
the anathema of code breakage.

> > And to say there's already some other way to do it in Python is doubly
> > disingenuous.  You can say that about just about half the features in
> > the language -- Generators, Iterators and List Comprehensions.  Toss
> > 'em out, no need.  Easily done another way.  Hell, by that rationale
> > we can get rid of FOR and IF, as there's way to express everything
> > they can do in terms of WHILE.
> >
By that rationale, we can do all our programming on a simulated Turing
machine, which can compute all computable functions. We are, after all,
arguing about what we see as "best" for the language. Our opinions differ.

> >> 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?
> >
> > Thanks for picking this tiniest of nits from my fur.
> >
Tee, hee. Sorry, that was indeed a cheap shot. But, at the same time, you
should consider it - style is  important in communication about a languge,
and there is a recommended style. I hope you aren't suggesting that
stylistic recommendations should be ignored?
.
> > I actually am familiar with the style guide and even how it's changed
> > over time.  IIRC, it used to be 8 column tabs were god's inviolate
> > creation (which I still tend to favor), with 4 ok if you did penance.
> > Now 4 is standard and god's own are the also ran.  Who knows?
> > Someday, spaces like I use them might become standard.  (Yeah, right
> > ;o)
> >
> > For the record, while I whole heatedly agree with most of the things
> > in the style guide, including many of Guido's personal prejudices, I
> > do happen to disagree on a few points.  And, similarly, after over 25
> > years of writing software for a living there is no point in trying to
> > convince me there's a better way.  Besides, "A Foolish Consistency is
> > the Hobgoblin of Little Minds" and "sometimes the style guide just
> > doesn't apply."  Right?  Seems to me, little example snippets in an
> > email is last place where the rules need to be strictly enforced
> > (unless you're one of those Hobgoblins).
> >
While I don't consider myself a hobgoblin it's probably for others to say.

> > Philosophically, I feel the clarity of written code is of paramount
> > importance (aside from actually working as intended).  I adhere to
> > Cornell CS Professor David Gries' advice to liberally use white space
> > to improve the clarity of your code.  In one effective presentation he
> > admonished his audience of professional programmers to "open up your
> > code and and let it breathe."  He accompanied his advice with a very
> > dramatic slight of hand with transparencies on the overhead projector
> > where a compact snipped of sample code opens up with white space and
> > indentation throughout.  It's always stuck with me and I have found
> > that the extra spaces inside parentheses and square brackets do
> > noticeably improve comprehension of existing code.  It's more work to
> > put them there but to me it's worth it.  Quite simply it more clearly
> > delineates the inside from the outside.  In ten years when all y'all's
> > vision starts to fade, you may finally appreciate the wisdom of this
> > advice.
> >
This is the same David Gries whose book on compiler technology used ASCII
art for the diagrams? I cursed him in my twenties (I went to college late),
but not because the book was flawed in any other way. Those diagrams stank,
so I suppose he has learned better since.

Again, you are free to adopt the style that suits you. I prefer, in my
written communications, to use a commonly-accepted style which (by and
large, hobgoblins excepted) will find most acceptance in the broad Python
community. It's a courtesy to my readers.

> > Things I particularly agree with in the style guide are (a) the
> > importance of consistency varies depending on scope; (b) you generally
> > need to apply some common sense; and (c) if you're working on someone
> > else's code you should respect the style already present (unless
> > you're willing to redo the whole thing properly).
> >
> >> > 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.
> >
> > The FAQ admits the very "flaw" and "ugly"ness (FAQ's term) with the
> > alternatives.  I didn't need to look because I already was well
> > acquainted with the issue.  Even the sample function they give as an
> > alternative is not a complete equivalent.  The very fact that this
> > topic is a Frequently Asked Question and one with such a lame answer I
> > think emphasizes that it's a true WART on the language.
> >
> >> 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.
> >
> > If you are referring to the confusion between "=" and "==" -- that
> > problem is completely unrelated to the ternary construct and
> > absolutely would not apply to Python extended only with a ternary
> > operator.  Rather it is a problem with C's concept that assignment is
> > an operator that may appear in any expression rather than a
> > statement.  So long as assignment remains a statement, then there is
> > no problem with omitted "=" that I am aware of.  Python could diagnose
> >
> >     a = if a = b : 0 else: 1        # syntax error!
> >
> > as an error just the same as
> >
> >     a = ( b = c )     # syntax error!
> >
> > is today.
> >
But once the ternary was in ...

> > Then too, I'm crazy enough to count assignment operators as another
> > one of Python's few serious omissions.  I wish to hell I could simply
> > write:
> >
> >     while data = socket.recv( 1024 ):
> >         process( data )
> >
Aha! So you are a closet "Python should be C" adherent? You should (since
you are thoroughly familiar with the above FAQ entry) know from FAQ 6.30
this is a definite no-no. Indeed, once you allow assignment operators you
bring in as allowable the very case you say above that Python would be able
to detect easily. The FAQ unambiguously states """The reason for not
allowing assignment in Python expressions is a common, hard-to-find bug in
those other languages, caused by this construct:
    if (x = 0) {
        ...error handling...
    }
    else {
        ...code that only works for nonzero x...
    }

"""

> > The recent addition of file iterators helps some but that's only one
> > case.  Are we going to add iterators to sockets?  If so, should it
> > default to recvline() or some other operation?
> >
There can be only one?

> > While it is true that assignment operators do cause some confusion, it
> > nevertheless again is a simple concept, readily mastered by even
> > novice programmers.  It's not brain surgery.  I've taught non
> > programmers how to program in C and they tend to pick up on these
> > several idioms right away.  Arrays, arrays vs. pointers and
> > multi-dimensional arrays seemed to be the bigger language problem,
> > followed quickly by tools and libraries particular to a particular lab
> > environment.
> >
This just ain't gonna happen, and these discussions can therefore be
considered a waste of bandwidth. I have used expression-based languages
myself. I thought Icon was much preferable to C, taking the whole thing to
further extremes and including generators.

> > Furthermore, to the extent there is risk, there are express remedies.
> > I worked for a while with a dialect of AWK.  AWK, like C, treated
> > assignment as an operator.  To protect people from the '=' vs. '=='
> > confusion, the AWK compiler adopted a convention that it would issue a
> > warning for any top level assignments that appeared within an
> > expression.  To suppress the warning, an additional level of
> > parentheses was required.  This actually worked out quite well,
> > stylistically, as the extra parentheses gave the reader a clear,
> > visible hint that something unusual was going on.  It's a good
> > convention which I retain even in C/C++, where it means nothing to the
> > compiler but aids humans reading the code later on.
> >
So a crappy language with warnings is better than a clean one without them?

> >> > (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 ..."].
> >
> > Yes, thanks.
> >
> >> 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".
> >
> > Of course, that's not what I meant.  I'm saying that the and/or idiom
> > likely will confuse more people (INCLUDING experts) than an explicit
> > ternary operator that's a documented standard part of the language.
> > Don't you agree?
> >
Well, given that I suggest the existing if: then: else: is to be preferred,
yes, I agree. But the FAQ entry specifically points out it's for those who
would wish a ternary ? on the language.

> >> > To me clarity of expression is the most important quality of a
> >> well
> >> > written program.
> >
> >> To me, clarity of expression is the most important quality of a well
> >> written
> >> program.
> >
> > I find it very encouraging that if you go high enough up the tree,
> > there is some common ground; in fact we are absolutely agreed.
> >
> > Even if we disagree about the details and outcomes we both have the
> > same objective in mind, which is a big head start.
> >
Who are you calling a big head?

> >> 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.
> >
> > "Reeducated" raises for me the specter of the Khmer Rouge.  Violent
> > revolution and anarchy.  Kill all the professionals and "reeducate"
> > anybody who resists.  I'm sure that's not what you meant.
> >
Well, actually it was. But in a gently ironic sense, rather than an "I'ma
get my gun" sense. I realise not everyone agrees with me all the time.

> > Too, I am fairly confident this feeling will not go away.  The several
> > gratuitous departures from C are a daily annoyance with each new
> > Python module I write.
> >
> >> I disagree. The biggest issue is the bloat this will introduce into
> >> the
> >> language, and programs written in it, without the least advantage.
> >> YAGNI.
> >
> > I think it's unreasonable to refer to this tiny, easily understood
> > feature as 'bloat', especially given the scope of Python now and the
> > myriad other features that already spilled over the dam.
> >
> >> Blerch. This is supposed to be easy to understand? In which
> >> universe. I
> >> submit it's completely unpythonic.
> >
> > Just an alternative.  I thought using the ":" to separate the question
> > from the answers made a kind of sense.  But I'll have to defer to your
> > expertise on what is or is not "Pythonic".
> >
No you won't, that's a game *anyone* can play. As you pointed out (and I
agree), it's not my language either.

> >> Well, there were problems with Algol 60's conditional expressions,
> >
> > Oh?  Something other than the dangling else ambiguity (which does not
> > apply in this case)?
> >
no, nothing else.

> >> but I
> >> agree that *in a free-form language* they are useful and fairly
> >> natural.
> >
> > Wow, so you don't simply hate them altogether.
> >
Not at all.

> >> 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.
> >
> > Fascinating.  I'm not sure I'm getting this but it sounds like this is
> > a fundamental point that makes a ternary operator good or bad.
> >
Not really. Ternary good or bad isn't the issue (for me). The issue is
ternary in or out. The situation now is it's out. I am suggesting it will
stay out, is all.

> > I learned yesterday that Guido says Python is an Algol derivative.
> > Isn't that "free form"?
> >
> > Please define "free-form language", with emphasis on why Python is not
> > one.  Then please explain how free-formed-ness has any bearing either
> > way on allowing a proposed construct, which you otherwise admit may be
> > "useful and fairly natural."
> >
> > I am truly eager to learn, master.
> >
Snide. I simply meant that when indentation is used to indicate block
structure it becomes more difficult to detrmine an appropriate layout for
expressions of this nature. You yourself have referred to simple one0line
constructs, but suggest it would be more natural to spread a ternary over
three lines. I simply suggeested that given that preference if: then: else:
isn't much worse.

> >> This isn't the first time this topic has been dragged out of
> >> retirement, and
> >> I don't suppose it will be the last.
> >
> > I expect it'll be a continual nuisance unless/until Python adopts the
> > changes.  The majority of SW development done on Unix and on PCs is by
> > C/C++ programmers and a large fraction of college grads come
> > pre-programmed to know one or both languages.  To that huge body of
> > prospective users, the several gross and unnecessary inconsistencies
> > with C appear to be glaring errors.  I know a lot of people with that
> > background who reject Python out of hand (in favor of, Bletch, Perl)
> > simply because of those perceived inconsistencies.  Sad and unfair but
> > true.
> >
Well, should we also introduce a COMPUTE statement so the COBOL programmers
will feel at home?

> > I accept I'm probably pissing in the wind on all this but I think it's
> > an important consideration when trying to attract a substantial
> > "following".
> >
The worst thing Python's developers could do is "try to attract a
substantial following", and I think it's to Guido's credit that he expects
the excellence of the language to dictate its eventual popularity rather
than trying to advertise it.

> >> 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.
> >
> > Well, you thought I was being uncivil when I did not intend to be and
> > then your broke Miss Manners' first rule that rudeness (perceived or
> > otherwise) does not justify rudeness in turn.  No problem.  I have no
> > problem with criticisms about my ideas, or just about anything else
> > short of personal insults.
> >
I have no problem with this either, and indeed chose to apologise rather
than rewrite when I got to the end of the post.

> > I have nothing but an abundance of goodwill for Python and it's users
> > base.  That's why I'm here.  Any suggestions I may make are sincerely
> > well intentioned, whether it may seem that way or not.
> >
> >> I shall not be contributing more to this thread.
> >
> > Ah, the old, chicken shit, take some pot shots and run away.....
> >
> > Worse: you wait until NOW to tell me!   You shoulda put this
> > disclaimer at the top of your note -- woulda saved me a lotta time.
> > ;o)
> >
So you saw the disclaimer at the top of this one, then? I hate that you made
a liar out of me, but since you had the foresight to email your reply as
well as posting it I felt this was the appropriate forum for the response.

> > But then too, in retrospect, I suppose you could do nothing but agree
> > with everything I say in this reply, so I suppose there's really
> > nothing more for you to add.   ;o)
> >
> > Seriously, I'm interested to hear your further views on the matter.
> >
No, you aren't. Do you want the $5 argument or the $10 argument?

regards
 Steve
--

home: http://www.holdenweb.com/
Python Web Programming:
http://pydish.holdenweb.com/pwp/