Home Original page

UserLinux chooses Python as "interpretive language" of choice

Steve Lamb grey at despair.dmiyu.org
Sat Dec 20 16:19:55 EST 2003 
On 2003-12-20, John Roth <newsgroups at jhrothjr.com> wrote:
> It doesn't matter. As you can see by my reply to Bengt,
> the crux of the issue is that, in Ruby, the function call
> syntax is *optional.* There is no way to make it optional
> in Python, and it is not clear whether it should be.

    It is quite clear.  I, and others, have shown why several times.

> What I'm missing, however, is any *thoughtful*
> discussion of the issues involved. Your [perjoritive
> adverb deleted] response makes it clear that you
> didn't think of the issues, you just reacted.

    No, I didn't react and I have thought.  Want to know my thinking?  5+
years of programming Perl professionally and being damned tired of trying to
debug not only other people's code but even *my own code* which I wrote before
I restricted myself to using as few implicit calls as I could get away with.
I've gone on to argue against main implicit calls in various different
languages in several different venues (here, Debian lists, in the workplace,
in private discussions, etc) and provided examples why the ambiguity sets up
the programmer, the program and the maintainer for problems down the road.

    Now just because you weren't around to see all of this or be in on any of
it doesn't mean it didn't happen.  Furthermore it also does not mean that
every time some neophyte comes in throwing languages wishes which have been
discussed at great length several times before that we have to engage in the
same weeks long discussion AGAIN just for his sole benefit!  No, we give
concise examples on why that position is the way it is.  

    That's what you got.  You chose to ignore it.  Instead of engaging in the
valid points present you ignored them and flamed me.  Bravo, way to get your
point across.  So until you can address these points I strongly suggest you
not reply because the chances of you making any serious headway without
addressing them is on you.  Great thought HAS been put into them.  So far no
thought has apparently been put in your position.

1: Calling a function or method without parameters occurs far, far less than
calling a function or method with parameters.  This constitutes a special
case.

2: Making the calling syntax optional creates ambiguity because one does not
know if we're making an assignment to the function/method object or an
assignment to the results of the function/method.

3: Making the calling syntax optional creates ambiguity for the maintainer
since it muddles the visual difference between variables and function/method
names.

4: Making the calling syntax optional dictates that to maintain functionality
additional syntax need be created to address the case where one wants to
assign to a function/method ojbect and not to the return of said object.

5: In doing all of the above we have now introduced multiple ways to do the
same thing on 2 different occasions.

    The onus is on you to explain, given these statements that we Python
programmers tend to like to adhere to...

Explicit is better than implicit.
Simple is better than complex.
Special cases aren't special enough to break the rules.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.

    ...why the behavior is desireable when it is implicit, complex guess on a
special case that introduces an additional way to do something which combined
means the language is harder to read and maintian all so you can save two
whole shifted keystrokes.

-- 
         Steve C. Lamb         | I'm your priest, I'm your shrink, I'm your
       PGP Key: 8B6E99C5       | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------
More information about the Python-list mailing list