Suggestion for a "data" object syntax

[Mikhail V]

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.
>
> We already have tab-separated elements in Python. It is allowed to use
> tabs between any whitespace separated tokens.

Yes, exactly. So in the proposed syntactic construct, it is *not*
allowed to insert tabs between _any_ tokens.
Namely if you will insert tabs _inside_ equations,
like:
a      + b

Then it will not work (it will parse 2 elements) .

So -  the simple answer, which follows directly from the
proposal: no, you don't insert tabs inside equations in this construct.
In simple words, if you want to do it nevertheless - this proposal is
not for you.

*But I am glad that at least you have managed to formulate your concern
finally,  thanks.*


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

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

Maybe you should've made more influence on that in the past and now we
all would have to use spaces only to format the code.
Also maybe include C-brackets so as not to worry when e-mail clients
add extra spaces in front of lines?


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

Wow! Uncle Steven knows Python operators.
My question was: why would you have "+ b" in
the first place in your code? So you treat the worst-case scenario
as a normal case - interesting approach  indeed!

By the way, since you are into unrealistic worst-case scenarios:
Imagine you start with Python learning, how you'd like such constructs:

L = [a     +     b, c, d]
L = [a     +     b, (c, d)]

For a starter, reading this will be quite painful.

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.
Simple feature like "set the minimal tab size" would have solved
this issue by 100%. Maybe it even exists in some editors,
I would not be surprised at least.

 I hope you are not seriously thinking that there is good syntax
 that gives retro-tools, wacky people, not wacky people,
 pros, etc. same opportunities.

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.

Seriously, your sarcasm is pretty one-sided.
You should try to think a bit wider.


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

Yep!  Just toggle them if you want to find out. That's a good feature!

And you know, **head-desk'ing too often (and without reason) may
be not good to you.**
We need healthy Steven.


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

Yeah, but most people do not want to sit with technologies from 80's,
especially when many new possibilities are already available.
And that's why the scene of editors is changing so fast,
there is a lot that makes it easier to work.


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

Ok, that was a typo, it must be:

    "So the idea is to _hide brackets for_ first two levels of
    nesting of course."

Thanks for noticing. So it can, but that's not an easy one to
implement.



M