Suggestion for a "data" object syntax

[Mikhail V]

On Fri, May 11, 2018 at 9:12 AM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
> On Thu, May 10, 2018 at 6:34 PM, Mikhail V <mikhailwas at gmail.com> wrote:
>> On Wed, May 9, 2018 at 6:25 AM, Steven D'Aprano
>> <steve+comp.lang.python at pearwood.info> wrote:
>>> On Tue, 08 May 2018 23:16:23 +0300, Mikhail V wrote:
>>>
>>
>>>> but I propose Tab-separated elements.
>
> Then these are not ordinary expressions, are they? They're a different
> type of expression and will require a modified parser. This adds
> complexity.

Definitely such syntax will require modifed parser.


>> "GvR have invented amazing new syntax that cannot be preserved
>> by sending it by e-mail"!
>> (not me)
>>
>> Do you understand that basically any python code sent by e-mail converts tabs to
>> spaces, thus the only way to receive it - is to send binary file?
>
> Um, no, this is false. We send Python code by email all the time.
> 1) Tabs as indentation: Python permits the use of both tabs and spaces

This means if I paste some code _inside_ an existing  block,
I get a Syntax error:
"TabError: inconsistent use of tabs and spaces in indentation"

> 3) Tabs that appear in strings: This one I'll grant you.

This too.

So what is false? Yes with my syntax it will just become
more prone to environments which replace tabs with
spaces. Mostly this happens in e-mails and web forms.
Why they do it I don't have an idea.

Anyway keeping this in mind, I'd prefer not to adapt
the syntax to such things. It would be fair that the software
solutions should address those, as it should not happen.


> In any case, the use of tabs is entirely optional. For the most part,
> programs can be safely emailed whether they contain tabs or not, the

In real situation just send as attachment, with or without such
syntax, it will be
more polite and safe if you wish the person to run the program.
For some talks in email its not *far* worse than now.


>> Yes, I have told already that there are _some_ cases when
>>  tabulation formatting can cause visual confusion.
>> *But why do you blame me*?
>> It just the issues with editor's incompleteness.
>
> That's great, but if I'm editing a file on an embedded system over a
> serial port and the only editor I have available is nano, I should be
> able to use it. You can't just assume that everybody has a fully
> featured editor (and knows how to use it -- what was that point you
> made just above about beginners?)

Wait, wait, wait - we are adult people - what problem causes nano?
I don't have nano so maybe you can tell what happens in nano if you
load for example a text file this:

→a + b →→ a + b →→a + b  →→a + b
→1 →→ 2 →→ 3 →→ 4
→width:→→→→→→100% →→!important;

In the above example one arrow → is one tab char.
What exact problem do you experience?
(note, I don't ask to align the columns, I just ask what
real problems you have with that?)
TBH I cant say for tools other than normal editor.
Just hope it will not become my problem to test
all legacy stuff out there.


>> For instance, there is real demand on adding new control characters
>> to syntax, so as IDE developers can utilize those for making
>> better user experience. If you apply same one-sided principles here
>> then you behave good to one group of people, but just ignorant
>> to other group of people who want better new experience.
>
> Please link the approved PEP that is going to add syntactically
> meaningful control characters.

Sorry, i was writing too fast - not control characters, but characters in
general. That was kind of general parallel to the current situation.
I'll try to ask better: for instance, if propose to use some unicode character
operator - so I can use the editor feature.
In theory - many people may potentially benefit but some people
have issues with it in some software.
And the issues may vary in nature - e.g. Steven can't bind a keyboard
shortcut to type it.
OTOH it may be something really bad - a software failure or general
problem. So the question is what would be more _serious/general_ problem.


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

> Needing to fiddle with editor settings in order to determine how the
> code in front of me that somebody else wrote is organized doesn't
> sound to me like a good feature. That sounds to me like poor
> readability.
>

Sorry, not sure what you mean. Do you propose _visible_ character
instead of e.g. tab? But then you need to hide it to be able
to read normally.


>>
>>     "So the idea is to _hide brackets for_ first two levels of
>>     nesting of course."
>
> In other words, this syntax is really not appropriate for more than
> two levels of nesting due to the mental gymnastics required to keep
> track of how the current level of nesting should be expressed.

No. How you come up to this conclusion?
it is just  not a trivial task to find an optimal solution to this -
on the one hand it must be feasible to parse, on the other hand
presentable to the reader. Initial  idea is just use current
Python syntax for further nesting:

image === T/T:
    (127,127,127)        (127,127,127)        (127,127,127)
    (127,127,127)        (127,127,127)        (127,127,127)
    (127,127,127)        (127,127,127)        (127,127,127)
    (127,127,127)        (127,127,127)        (127,127,127)

vs:

image = (
    ((127,127,127), (127,127,127), (127,127,127),),
    ((127,127,127), (127,127,127), (127,127,127),),
    ((127,127,127), (127,127,127), (127,127,127),),
    ((127,127,127), (127,127,127), (127,127,127),),
    )


Seriously I find it quite an improvement both for
readability and type-ability.
I see you keep denying it for some unknown reason,
but well, its up to your conscience.


M