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 | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
