[Python-ideas] Syntax idea for 2D lists\arrays

Terry Reedy tjreedy at udel.edu
Wed Mar 14 21:10:05 EDT 2018


On 3/14/2018 8:32 PM, Mikhail V wrote:
> Once there was a discussion about alternative list and arrays
> creation and assignment syntaxes. I think this is one of things with room for
> ideas and has frequent usage.
> I've had some ideas for syntax long ago, and now I remembered it because of
> the recent topic "Descouraging the implicit string concatenation".
> 
> Idea is a concept for 2D arrays/lists syntax, which should simplify
> some editing boilerplate while working with arrays and improve
> readability for bigger arrays.
> 
> Lets start with a simple list example :
> 
> L ===
>      1   5   9   155
>      53  44  44  34
> 
> returns a 2d list:
> [[1, 5, 9, 155], [53, 44, 44, 34]]

I would rather type this, with or without a return.  Literal arrays are 
not this common.  When the entries are constant, a tuple of tuples is 
much more efficient as it is built at compile time

 >>> dis.dis("((1,2),(3,4))")
   1           0 LOAD_CONST               0 (((1, 2), (3, 4)))
               2 RETURN_VALUE
 >>> dis.dis("[[1,2],[3,4]]")
   1           0 LOAD_CONST               0 (1)
               2 LOAD_CONST               1 (2)
               4 BUILD_LIST               2
               6 LOAD_CONST               2 (3)
               8 LOAD_CONST               3 (4)
              10 BUILD_LIST               2
              12 BUILD_LIST               2
              14 RETURN_VALUE

> 
> Syntax rules here:
> - "===" indicates parsing start (may be some other decorator)
> - data block *always* starts on the new line and parsing always
>     like in a "def:" block (by indentation, till next negative indent)
> - new line is a next element
> - white space separated inner elements (tabs, spaces)
> 
> Line continuation as usual:
> L ===
>      2  1  5 \
>      3  4  6
> returns:
> [[2, 1, 5, 3, 4, 5]]
> 
> 
> SPECIAL CASE: 1d list could be explicitly marked with e.g. *:
> 
> L ===*
>      2  1  5  3  4  6
> returns :
> [2, 1, 5, 3, 4, 5]
> 
> Also in 1d case one might omit the line continuation \:
> 
> L ===*
>      "msg1"
>      "msg2"
>      "error"
> 
> returns:
> ["msg1", "msg2", "error"]

No, this would return "msg1msg2error"

> IMO the latter looks nice and very useful for pretty-formatting
> of string lists.
> 
> ----
> 
> *Examples for working with 3D arrays:*
> 
> import numpy as np
> A = np.zeros((2,3,2))
> 
> A[0,0] ===
>      8  8
> A[1] ===
>      0    0
>      155  1
>      1    1
> 
> returns:
> [[[   8.    8.]
>    [   0.    0.]
>    [   0.    0.]]
>   [[   0.    0.]
>    [ 155.    1.]
>    [   1.    1.]]]
> 
> Compared to same operation in current syntax:
> 
> A[0, 0] = [8, 8]
> A[1] = [
>      [0,   0],
>      [155, 1],
>      [1,   1] ]
> 
> (which is ugly, though can be a bit more compact in simplest case)
> 
> I think these examples show the general idea already.
> 
> Pros:
> - clean readable look
> - copy-pasting tables from e.g. excel with little to no re-typing
> - no more editing annoyance with trailing commas/brackets
> 
> Cons:
> - less compact for trivail cases (newline always added)
> 
> -----
> 
> Problems that I see with this syntax:
> *Comma-separated vs space separated*.
> 
> Space separated IMO better readable in general,
> though single space can be too dense with some proportional
> fonts. In this case two or more spaces could be better.
> 
> Also consider expressions inside arrays, e.g.:
> SS ===*
>      11 + 3  5  6
> SS ===*
>      11 + 3,  5,  6
> 
> I would not say comma really improves things here, but
> opinions may vary.
> Still, all in all, I am on the side of space-separated.
> Also numpy uses space-separated with print() method by default.
> 
> ------
> 
> How do you like such syntax? Maybe someone can come up
> with counter-examples where such syntax will lead to ugly look?
> 
> 
> 
> Mikhail
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
> 


-- 
Terry Jan Reedy



More information about the Python-ideas mailing list