Suggestion for a "data" object syntax

[Steven D'Aprano]

On Tue, 08 May 2018 15:52:12 +0300, Mikhail V wrote:

>> Last time you brought up this idea, you were told that it is ambiguous.
>> Using whitespace alone, it is impossible to distinguish between
>>
>>     a + b
>>
>> and
>>
>>     a + b
>>
>>
>> Can you see the difference? Of course not. That's the whole point. It
>> is ambiguous. The first is a single item consisting of a plus b, and
>> the second is two items consisting of a, following by unary plus b.
> 
> Can you be more precise what issue are you addressing?

Was I not clear enough the first time?

When you write "a + b" it is impossible for either the human reader or 
the interpreter to tell whether that is meant to be two items separated 
by white space ("a" and "+b") or a single item ("a+b").

The same applies to "a - b".

There is no acceptable work-around or fix for this.

* It is not acceptable to prohibit whitespace between unary operators
  and their operand;

* or to require spaces rather than tabs between binary operators
  and their operands;

* or to make a subtle semantic difference between tabs and spaces
  of this sort.

Unix "make" files require tabs rather than spaces, and it is a constant 
source of bugs and frustration.


> Last time and
> this time I told it uses TAB character to separate elements.

That's not my recollection. As I remember it, it was *your* idea to use 
tab characters, and everyone told you that was not an acceptable work-
around.

Who told you to use tab characters? It would not have been any of the 
core developers. Many of them would rather ban tabs than require them.


>> There's also the problem that your syntax requires the *invisible*
>> difference between tabs and spaces to be treated as syntactically
>> meaningful.
> 
> What editor do you use? My editor can toggle tabs highlighting as
> arrows, and I suppose almost any editor has good support for
> highlighting of characters by search, etc. For NPP there are even
> plugins like Regex helper.

Using a particular editor is not and will not be a mandatory requirement 
for Python.


[...]
> So you would prefer this:
> 
> L = (
>     (a, 1),
>     (b, 2),
>     (c, 3),
>     (foobar, 4))
> 
> over this:
> 
> L === T/T:
>     a    1
>     b    2
>     c    3
>     foobar    4
> 
> Right?

I am amused that you have obviously gone to a lot of trouble to carefully 
line up the columns, and yet they aren't even aligned -- "foobar" extends 
into the second column, pushing the "4" out to the right.

There is no doubt that the first is HUGELY better:

- it uses the standard = assignment operator, not a 
  special "===" operator;

- there's no cryptic and mysterious "T/T" code which looks like
  you are dividing T by T;

- the first one allows you to write it as a single line:

    L = ((a, 1), (b, 2), (c, 3), (foobar, 4))

  instead of wasting vertical space;

- the first one is unambiguous while the second is ambiguous;

- the first one can include nested data structures, while 
  the second cannot.

There is only one advantage to the second format. It gives bad 
programmers a justification to waste time while pretending to be working, 
as they carefully align their columns, then realign them each time the 
data changes.


> Your issues with tabs aside, I think it is impossible to ignore
> the the readability improvement.

An interesting philosophical conundrum... is it possible to ignore 
something which isn't there?

If there is no elephant in the room, and nobody mentions it, are they 
ignoring it?



-- 
Steve