Suggestion for a "data" object syntax

[Steven D'Aprano]

On Tue, 08 May 2018 23:16:23 +0300, Mikhail V wrote:

> I don't propose to remove spaces, 

And that is why the syntax will be ambiguous. So long as whitespace is 
*allowed* but not *required* around operators, there will be ambiguity 
between a - b and a - b with no way to tell whether they are intended as 
two items or one.


> but I propose Tab-separated elements.

We already have tab-separated elements in Python. It is allowed to use 
tabs between any whitespace separated tokens.

The only restriction is that in Python 3 you must use *consistent* spaces 
or tabs but not a mix of both for indents.


> If I allow commas as well, this will become not so simple, probably.
> Also I don't propose syntax for e-mail code exchange, but rather syntax
> for *work* an this can potentially help a lot of people in everyday
> work.

/head-desk

You: "I have invented amazing new syntax that cannot be exchanged by 
email. Here, let me email some examples to you."

Do you understand that you have already emailed samples of this proposed 
code?


> Also I don't know what kind of human thinks that this:
>  a + b
>  is two elements "a" and "+ b"
> What is "+ b"? 

It is unary plus followed by b.

If you don't know Python's existing syntax, how can you possibly expect 
to invent new syntax?


> And who writes "- b" with a space in unary minus? I don't. Nobody does.

Oh well, if you don't, then clearly nobody in the world, and no code 
generators, could possibly do it. Because Mikhail says so.


> Is it allowed? yes. no problem.

Since it is allowed, it is a HUGE problem for your syntax, since your 
syntax cannot distinguish between the two cases.


[...]
> There is "invisible" difference in indentations tabs vs spaces - so
> what? 

That means that people will look at a piece of code and not know whether 
they are seeing spaces or tabs, since they are both invisible.


> I don't want spaces or tabs visible - there is toggle "show tabs"
> and "toggle show space" for that

/head-desk

You: "This syntax doesn't need tabs and spaces to be visible. Just use 
the Show Tabs and Show Spaces commands on your editor to make them 
visible."


> Those are basically universal features. And thousands of Python people
> already use tabs to align columns so you have to accept it

Current syntax allows people to use tabs to align columns, and it remains 
unambiguous no matter how wacky people align their data, because of the 
commas. Even if they think they are writing Fortran with fixed column 
widths, it is still unambiguous to both the human reader and the parser:

data = [        +       a       ,       -        b      ,
                -       foo     ,       +        bar    ,       ]

even if they separate operators from their operands with tabs. Paste that 
into your Python interpreter, and it has an unambiguous meaning.

The same does not apply to your syntax. Take out the commas, and it is 
impossible to tell what the code means or how many columns it has.


>> Using a particular editor is not and will not be a mandatory
>> requirement for Python.
> 
> Using outdated tools or being PEBCAK are not and will not be
> justification for language syntax improvements.

It is not your choice of what editors people are permitted to use in 
order to read and write Python.


[...]
>> - 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;
> 
> Wasting space you say? You economize paper for printing out?

No. I arrange code in the best way I see fit, depending on the code. 
Sometimes that means I put things on a single line, so as to fit more 
lines into a single screen, sometimes it means I spread things out over 
multiple lines in order to get maximum benefit from two dimensional 
layout. It all depends on the code I am writing and I use whatever is 
best for the situation.


>> - the first one is unambiguous while the second is ambiguous;
> 
> I think it's time to reveal what exactly you mean here.

For the fourth time, it means that the current syntax is unambiguous and 
only ever has a single meaning. Your suggestion is ambiguous, it cannot 
be parsed into a single meaning, and you have to guess what the code 
possibly means.

A single expression like either of these:

	a	+	b

	a	+b

under your syntax have TWO legal meanings, and there is no way to tell 
which is required except to guess.

I do not know how to make it more clear.


>> - the first one can include nested data structures, while
>>   the second cannot.
> 
> Why it can't? did you read the original e-mail?

Of course I did. You said:

    "To present nesting of elements of higher than 2 levels, 
    normal Python syntax can be used for deeper nesting"

and 

    "So the idea is to cover only first two levels of 
    nesting of course."

With bracket syntax, I can cover unlimited levels of nesting. Yours 
cannot.




-- 
Steve