Python grammar..

[Alex Martelli]

"D-Man" <dsh8290 at rit.edu> wrote in message
news:mailman.992488760.27134.python-list at python.org...
    ...
> | > Yes, but if I were designing a language today, I think I would
> | > request you to be EXPLICIT about "ignoring the return value" --
> | > explicit is better than implicit.  It IS an occasional cause of
> | > errors in Python (particularly with newbies) that an expression
> | > statement's value is silently and implicitly ignored...
    ...
> | So you would prefer that functions whose return value is ignored must be
> | called with a keyword ... such as in VB
> |
> | call aFunction()
>
> or
>
>     (void) aFunction() ;
>
> | Personally, I absolutely hate this.
>
> Not any better ;-).

I'm talking about a hypothetical language design issue, of course.

Let's assume that expression-statements are part of it -- any
expression is a syntacticaly valid statement.  Now, the issue
becomes: what to do with the VALUE, if any, of that expression.

Python silently throws it away, as do C and C++.  I do not
particularly like that, for all that I'm used to it after
almost 20 years of C'ing.  A Python *interactive session*
print the value's repr AND saves it to __builtin__._ -- now
THAT is good, and you can also tweak it with sys.displayhook,
which is even better.  But the stark split between the
behaviour of interactive sessions and running a script
is confusing indeed to newbies.

One (IMHO) sensible alternative might be to generalize the
use of sys.displayhook (perhaps by some other name:-).  The
language specs might be: expression statements are allowed;
when an expression statement returns a value != None, then
sys.whateverhook is called with that value as its only
argument.  The issue now becomes just one of having the
whateverhook you want.  One with a body of 'pass' would
make most old hands happy, one like the one the interactive
interpreter uses now might make sense for debugging, etc.

If you DON'T want the whateverhook to be called for a given
expression statement that might return a not-None result,
just turn the expression statement into something else, e.g
    _=myfunkyfun()
or, for keyword-lovers, we might make 'pass' accept an
optional argument:-)...:
    pass myfunkyfun()

The point of this design decision would be that, IF myfunkyfun()
returns something, there's supposed to be a POINT to that
value... the DECISION to ignore the value anyway should be
just that, a *DECISION* -- and explicitly expressed in the
code (by assigning the value to a sink-variable like _, or
whatever:-).  Oh well, it IS all hypothetical anyway!-)


Alex