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

[James J. Besemer]

"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.
>
> 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.
>
>> 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.
>
> 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.
>
> 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.
>
> 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"?
>
> 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?"
>
>> > 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.]
>
> 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.
>
> 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 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.
>
> 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).
>
> 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.
>
> 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.
>
> 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 )
>
> 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?
>
> 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.
>
> 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.
>
>> > (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?
>
>> > 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.
>
>> 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.
>
> 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".
>
>> 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)?
>
>> but I
>> agree that *in a free-form language* they are useful and fairly
>> natural.
>
> Wow, so you don't simply hate them altogether.
>
>> 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.
>
> 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.
>
>> 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.
>
> 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".
>
>> 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 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)
>
> 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.
>
> Regards
>
> --jb
>
> --
> James J. Besemer  503-280-0838 voice
> http://cascade-sys.com  503-280-0375 fax
> mailto:jb at cascade-sys.com
>

--
James J. Besemer  503-280-0838 voice
http://cascade-sys.com  503-280-0375 fax
mailto:jb at cascade-sys.com