Suggestion for a "data" object syntax

[Mikhail V]

On Tue, May 8, 2018 at 6:20 PM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> 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").
>
> 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;
>

Sorry this all does not seem to even refer to my proposal.

I don't propose to remove spaces, but I propose Tab-separated
elements. 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.

Also I don't know what kind of human thinks that this:
 a + b
 is two elements "a" and "+ b"
What is "+ b"? And who writes "- b" with a space in unary minus?
I don't. Nobody does. Is it allowed? yes. no problem.

(It would be great if you group the issues
related to usability separetely from technical problems
with parser. That will help to understand you comments.)


>> 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.

Yes my idea, but not sure what is you concern right now.
IIRC back then, you were the *only one* who commented something about
Tab and parsing, and made some mysterious example with eval("\t") which
I still don't know what it should explain exactly.
You say "everyone?" ... Hmm, now I am starting to suspect - maybe
each your post really represents a result of a quick meeting
regarding each raised proposal?
That would explain the usage of plural "us".

>>> There's also the problem that your syntax requires the *invisible*
>>> difference between tabs and spaces to be treated as syntactically
>>> meaningful.

There is "invisible" difference in indentations tabs vs spaces - so what?
I don't want spaces or tabs visible - there is toggle "show tabs" and "toggle
show space" for that and many more usability features, as I already said.
Look, I work with layouts - there are: Indents, Tabs, spaces, En
space, Em space,
thin space, non-breaking space, "indent to here" control characters.
All those are useful parts of inner syntax - all are "invisible".
What point are you making after all?

Those are basically universal features. And thousands of Python people
already use tabs to align columns so you have to accept it - it is
part of many source code and tabulation formatting is a good and
useful feature, although not all editors cope good with that.


>>
>> 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.

Using outdated tools or being PEBCAK are not and will not be justification for
language syntax improvements. Using an editor from 85 - everyone else
should bother?
As said there is already tons of code with which you may be unsatisfied
when you paste it into REPL, but nearly nobody uses REPL for work.

>
> [...]
>> 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.

No, i haven't. It takes much less time to type that than bracketed
version. Though I am amused that you've noticed the misaligned
element but can't notice how bad the bracketed version look.
Ok, Steve, as said, I hear you - you like the ugly one, I'll pick the cute
one ;-)


> 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;

Your bullet list feels incomplete, can add also:

 - no other languages use such syntax

 - this is not current Python syntax after all. Syntax error, Ta-da!



> - 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?
Or do you like command-line editors so much?

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

I think it's time to reveal what exactly you mean here.
In the above example there is nothing ambigious.
At least not for someone who is Ok with basic editing
skills.


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

Why it can't? did you read the original e-mail? Also it is not
the primary aim of the suggested syntax, but I work this out too.

Somehow it feels you have collected all posible related and
not directly related concerns together here.