[Python-Dev] Pre-PEP: Allow Empty Subscript List Without Parentheses

[Nick Coghlan]

Greg Ewing wrote:
> Ka-Ping Yee wrote:
> 
>> I think the whole discussion about the concept and meaning of
>> zero-dimensional arrays is mostly irrelevant to the original
>> issue.  The original issue is a *syntax* question: should
>> x[()] be written as x[]?
> 
> But, at least as presented in the PEP, it's a
> syntax that was motivated by a perceived need
> for dealing with 0D arrays. So it seems relevant
> to ask whether 0D arrays are really needed or not.
> 
> Does anyone have any other use case for this
> syntax?

I believe the NumPy link Robert posted does a pretty good job of thrashing out 
the use cases (or lack thereof).

I also thought a bit more about the places where the comma separator is used 
as part of the syntax, and realised that there is no consistent behaviour used 
when the expression is omitted entirely.

In return and yield, omitting the expression is equivalent to using 'None'

In print, omitting the expression is equivalent to using the empty string.

In raise, omitting the expression has no real equivalent short of:
   exctype, excval, exctb = sys.exc_info()
   raise exctype, excval, exctb

In an except clause, omitting the expression means the clause handles all 
exceptions.

In a function definition, omitting the expression means the function accepts 
no arguments.

In a function call, omitting the expression is equivalent to writing *().

Most other places (assignment statements, for loops, etc) omitting the 
expression that may contain a comma separator is simply not permitted.

The closest parallel would be with return/yield, as those actually create real 
tuples the same way subscripts do, and allow the expression to be omitted 
entirely.

By that parallel, however, an implicit subscript (if adopted) should be None 
rather than ().

Adapting the table from the pre-PEP to describe return statements (and yield 
expressions):

     return i, j, k  <-->  return (i, j, k)
     return i, j     <-->  return (i, j)
     return i,       <-->  return (i, )
     return i        <-->  return (i)
                           return ()    # (No implicit equivalent)
     return          <-->  return None

With the status quo, however, subscripts are simply equivalent to the RHS of 
an assignment statement in *requiring* that the expression be non-empty:

     x = i, j, k  <-->  x = (i, j, k)
     x = i, j     <-->  x = (i, j)
     x = i,       <-->  x = (i, )
     x = i        <-->  x = (i)
                        x = ()     # (No implicit equivalent)
                        x = None   # (No implicit equivalent)

The PEP doesn't make a sufficiently compelling case for introducing 
yet-another-variant on the implicit behaviour invoked when a particular 
subexpression is missing from a construct.

I guess I could have gone with my initial instinct of -1 and saved myself some 
mental exercise ;)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org