Suggestion for a "data" object syntax

[Ian Kelly]

On Fri, May 11, 2018 at 5:26 PM, Mikhail V <mikhailwas at gmail.com> wrote:
> 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:
>>> 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"

You can't generally paste code into other contexts and expect it to
just work without any editing, for more reasons than the tabs / spaces
issue. This doesn't have to do with emailing code.

>> 3) Tabs that appear in strings: This one I'll grant you.
>
> This too.
>
> So what is false?

Your absurd assertion that the only way to safely email Python code is
as a binary file.

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

Note that this mailing list does not permit the use of attachments.
Pastebin is fine, but for small snippets it's much simpler just to
include them inline.

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

I have no specific problems. It was just an example of a simple editor
without support for fancy features like viewing tabs and spaces, in an
environment where a more feature-rich editor may not be available.

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

Why would I need to hide the separator character in order to be able
to read the data?

>>>     "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),),
>     )

And if you have more than three levels of nesting, and you don't
conveniently just have a bunch of 3-tuples that line up perfectly with
one another?

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

I'm not sure what my conscience has to do with it.