Re: Suggestion for a "data" object syntax

[Mikhail V]

On Sat, May 12, 2018 at 5:38 PM, Ian Kelly  wrote:
> On Fri, May 11, 2018 at 5:26 PM, Mikhail V  wrote:
>> On Fri, May 11, 2018 at 9:12 AM, Ian Kelly  wrote:
>>> On Thu, May 10, 2018 at 6:34 PM, Mikhail V  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?

>> So what is false?
>
> Your absurd assertion that the only way to safely email Python code is
> as a binary file.

Why you say so? You have agreed yourself with the assertion.
Also I did not say "safe" but meant that I cannot receive the exact file
in the body of e-mail in case of tabs.


> no support for _fancy features_ like viewing tabs and spaces

:\
is syntax highlighting fancy feature?


>> 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 you find e.g. this ok:
→1 →→ 2 →→ 3 →→ 4

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

Maybe you can come up with some example in current syntax?
I have browsed some projects with a lot of resource definitions.
sometimes it has 3-4 levels of nesting, and I have hard time
understanding the structure - so maybe it is possible to simplify
those according to this syntax.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Suggestion for a "data" object syntax

[Ian Kelly]

On Fri, May 11, 2018 at 5:26 PM, Mikhail V  wrote:
> On Fri, May 11, 2018 at 9:12 AM, Ian Kelly  wrote:
>> On Thu, May 10, 2018 at 6:34 PM, Mikhail V  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.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Suggestion for a "data" object syntax

[Mikhail V]

On Sat, May 12, 2018 at 7:54 AM, Steven D'Aprano
 wrote:
> On Sat, 12 May 2018 02:26:05 +0300, Mikhail V wrote:
>
>> it is just  not a trivial task to find an optimal solution to this
>
> We already have an optimal solution to this.

Yes. current syntax will not go anyway so proposal
addresses cases where it is appropriate and
clearly better.

>
> * It works with any editor, including simple ones.

Ok

> * It is safe for transmit over email, or on web forums,
>   so long as you avoid tabs and use spaces.

I don't use spaces so I'm out of luck already.

> * It is readable by humans without them needing to distinguish
>   between two different kinds of invisible space.

I'm using tabs from childhood and don't find it a problem.

> * It can be easily parsed by hand or by machine.

Parsed by hand?

> * It works with a multitude of text processing tools whether
>   or not they can cope with tabs.

Ok. But this is bullet #1, see above, you repeat it

>
> * It is resistant to many sorts of typos.

Here I think you oversimplify - In fact current syntax
introduces typing problems in many cases:
as a user with very high proficiency in typing and
good sight, I have some trouble inputting nested bracketed
arrays  and spend some time trying to match
corresponding suites. Plus the comma noise here,
so your statement is too one-sided and overestimated.

As said, I remember this and similar issues were raised on 'ideas'
so don't pretend it does not exist.

>
> * It allows great flexibility in the presentation, you aren't
>   forced to lay things out in one specific 2D format.

Only words - but nothing concrete

> * It uses the same consistent rules for the rest of the language,
>   without adding special cases and complexity.

I'll grant you for "special cases", but the rest is quite contradictive.
As said, Python uses indented blocks - not bracketed
blocks as in C.
Python does not make semicolons mandatory.
All this is a great improvement, but it seems you
don't see the parallel here.


> * It is a tried-and-true solution that has been used (with minor
>   modifications) for dozens, possibly hundreds, of programming
>   languages, natural language lists and data formats.

> "natural language lists and data formats"

OTOH all _real_ data list, tables, matrices do not include redundant commas,
unless it is really needed.
Any book, lectures, etc. presents them without commas so its
second nature to any human to see it without commas
and its just better so.



M
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Suggestion for a "data" object syntax

[Steven D'Aprano]

On Sat, 12 May 2018 02:26:05 +0300, Mikhail V wrote:

> it is just  not a trivial task to find an optimal solution to this

We already have an optimal solution to this.


* It works with any editor, including simple ones.

* It is safe for transmit over email, or on web forums, 
  so long as you avoid tabs and use spaces.

* It is readable by humans without them needing to distinguish
  between two different kinds of invisible space.

* It can be easily parsed by hand or by machine.

* It works with a multitude of text processing tools whether
  or not they can cope with tabs.

* It is resistant to many sorts of typos.

* It allows great flexibility in the presentation, you aren't
  forced to lay things out in one specific 2D format.

* It uses the same consistent rules for the rest of the language,
  without adding special cases and complexity.

* It is a tried-and-true solution that has been used (with minor
  modifications) for dozens, possibly hundreds, of programming
  languages, natural language lists and data formats.



-- 
Steve

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Suggestion for a "data" object syntax

[Mikhail V]

On Fri, May 11, 2018 at 9:39 AM, Ian Kelly  wrote:
> On Mon, May 7, 2018 at 9:45 PM, Mikhail V  wrote:

>> *Example 1. Multi-line strings*
>>
>> data === S :
>> this is multi-line string
>> escape chars: same as in strings (\\, \\n, \\t ...) ,
>> but "no need to 'escape' quotes"
>
> My reaction #1: why 'S'? Python strings have a name: it's 'str'.
> ...
> My reaction #2: what's the point of this construct? Python already has
> multi-line strings that can be used as expressions, not as statements
> only.

#1. I think passing multiline data structures as arguments
is not especially beautiful. Necessary? I don't know.
#2. What is the point? If introduce the new syntax _at all_,
- the cost of adding some additional common types is less -
IOW worth investigating some options?
About string type id - I agree it may be suboptimal with "S", since
it is not like tuples. But well, there must be something.

In this case:

s = """\
multi line string multi multi line string
multi line string multi line string"""

vs:

s === S:
multi line string multi multi line string
multi line string multi line string

Nothing revolutional, just a bit cleaner and with
an indent (which is not necesserily always a good thing
but IMO a bit more presentable).
The problem though, this will require editors to
modify their lexers for highlighting - this is a problem :/


> My reaction #3: Not a fan of adding an '===' operator. We already have
> '=' and '=='. Javascript is another language that uses '===' to mean
> something completely different from this proposal (it's another
> equality operator) and it's a mess there. Come up with something else.
>

"===" is just the least disturbing one I've come up with while
experimenting. I thought it should start with "=" at least.
E.g.
data =%  T :
data =\\  T :
(\\  now is syntaxError: unexpected character after line continuation)

I dont know - frankly I think its too early to start the game of
perfect operator choice.


>> Benefits are easy to see: say I want a tuple of strings:
>>
>> data === T :
>> "foo bar"
>> "hello world"
>> "to be continued..."
>>
>> VS current:
>>
>> data = (
>> "foo bar" ,
>> "hello world" ,
>> "to be continued..." ,
>> )
>>
>> Main problem with the latter are commas, it is not easy
>> to type
>
> In what bizarro world are commas harder to type than tabs? At least if
> I type a comma I know I'll get a comma. If I type a tab then it
> depends on my editor settings what I'll actually get.

Well, in the above case you don't have to type tabs or commas.
As for what character is easier to type : commas or tabs :
I find that Tab key is maybe a bit harder when using together
 with upper number row keys - OTOH when using keypad -
it feels easier. On average I think its comparable.
Also if you type commas, usually you want to type
space after a comma, or  a Tab  ;-)
So Tab maybe will win this race.


>> and, whats more important - hard to notice missing commas.
>
> But it's totally easy to notice missing tabs, right? Not.

**Those are two different things** - commas must be there -
and the issue persists, you want it or not.

I still have feeling that you try to imply that commas have
some role apart from Disambiguation of closely positioned
tokens - that's what they are from reader's POV.
In other words, if inter-token spacing is solid - commas are nothing
but redundant noise.
Do you understand this or not?

Also there was a topic about string lists on 'Ideas' recently -
so thats not only me who notices it.

Issues with input of tabs is more of psychology &
experience I'd say. I haven't problems with that.
Normally I input 2 tabs to make it form a solid whitespace- it
gives me optimal look. And I don't bother too much with
perfect alignment usually.


>> *Example 3. Two-dimensional tuple.*
>>
>> data === T/T :
>
> What about T/S? S/T? S/S? Are these allowed?

Not really. The idea is: to identify common cases
and data structures and try to find an optimal
set of ID's to represent them. But the slash
indicates that it's 2D case - so this one
is sort of explicit sign of higher dimension.

>
> Also, why is there a division operator here?

"slash"


>
>> 123"hello"
>> abc + de f
>>
>> is a synonym for:
>>
>> data = (
>> (1, 2, 3, "hello") ,
>> (a, b, c + d, e, f ) )
>
> If this is supposed to be a tabular format then why is the second row
> allowed to have a different number of elements than the first row?

why not ?

>
> What about named fields? Is there a proposal for extending this syntax
> to allow construction of dicts or namedtuples?

Maybe - though there already exist Python built-in methods to convert
e.g. tuples to dicts and lists.


>
>> The rule here is: TAB character is inner elements' separator, and the
>> new line is outer elements' separator. Line continuation
>> character is  \  (to help with long lines).
>
> So brackets and commas are 

Re: Suggestion for a "data" object syntax

[Mikhail V]

On Fri, May 11, 2018 at 9:12 AM, Ian Kelly  wrote:
> On Thu, May 10, 2018 at 6:34 PM, Mikhail V  wrote:
>> On Wed, May 9, 2018 at 6:25 AM, Steven D'Aprano
>>  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

Re: Suggestion for a "data" object syntax

[Chris Angelico]

On Fri, May 11, 2018 at 4:39 PM, Ian Kelly  wrote:
> On Mon, May 7, 2018 at 9:45 PM, Mikhail V  wrote:
>> Benefits are easy to see: say I want a tuple of strings:
>>
>> data === T :
>> "foo bar"
>> "hello world"
>> "to be continued..."
>>
>> VS current:
>>
>> data = (
>> "foo bar" ,
>> "hello world" ,
>> "to be continued..." ,
>> )
>>
>> Main problem with the latter are commas, it is not easy
>> to type
>
> In what bizarro world are commas harder to type than tabs? At least if
> I type a comma I know I'll get a comma. If I type a tab then it
> depends on my editor settings what I'll actually get.

In Mikhail's defense, this is a reasonably elegant solution to the
age-old problem of "I forgot a comma, now two of my entries got joined
implicitly". It automatically makes multiple entries, and if you WANT
joined entries, you would have to request that explicitly with the +
operator or a line continuation backslash. Oh wait, these things
aren't actual expressions, so you probably can't do either of those
things... hmm.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Suggestion for a "data" object syntax

[Ian Kelly]

On Mon, May 7, 2018 at 9:45 PM, Mikhail V  wrote:
> Here is an idea for 'data object' a syntax.
> For me it is interesting, how would users find such syntax.
> I personally find that this should be attractive from users
> perspective.
> Main aim is more readable presenting of typical data chunks
> and some typical data types (tuples/lists) directly in code.
> Further this should significantly simplify typing.
>
> *Example 1. Multi-line strings*
>
> Here is a 3 lines multi-line string, it will be automatically 'dedented'
> by the parser by one level of indent:
>
> data === S :
> this is multi-line string
> escape chars: same as in strings (\\, \\n, \\t ...) ,
> but "no need to 'escape' quotes"

My reaction #1: why 'S'? Python strings have a name: it's 'str'. They
don't need an additional, even more opaque name on top of that. If I
could go back in time and change the name of the type from 'str' to
'string', I would.

My reaction #2: what's the point of this construct? Python already has
multi-line strings that can be used as expressions, not as statements
only. Why do we need this syntax also? This is also not really
homomorphic with the proposed tuple syntax since that uses
tab-separated fields whereas this is just freeform text.

My reaction #3: Not a fan of adding an '===' operator. We already have
'=' and '=='. Javascript is another language that uses '===' to mean
something completely different from this proposal (it's another
equality operator) and it's a mess there. Come up with something else.

My reaction #4: Come to think of it, in keeping with other assigment
operators like '+=' and '*=' and '//=', if 'a === b' must exist then
it should mean 'a = a == b'. :-)

> *Example 2. Tuples*
>
> Tuple is a data block with normal Python elements.
>
> data === T :
> 123"hello"
> abc + d
>
> Here the separators of elements are : tab character,
> new line (and maybe some white-space character like em-space?)
> The above construct will be direct synonym for:
>
> data = (1, 2, 3, "hello", a, b, c + d)
>
> Benefits are easy to see: say I want a tuple of strings:
>
> data === T :
> "foo bar"
> "hello world"
> "to be continued..."
>
> VS current:
>
> data = (
> "foo bar" ,
> "hello world" ,
> "to be continued..." ,
> )
>
> Main problem with the latter are commas, it is not easy
> to type

In what bizarro world are commas harder to type than tabs? At least if
I type a comma I know I'll get a comma. If I type a tab then it
depends on my editor settings what I'll actually get.

> and, whats more important - hard to notice missing commas.

But it's totally easy to notice missing tabs, right? Not.

> And brackets of course does not make it nicer either.
>
> The above are typical cases where I see clear win, and
> IMO they are quite common constructs.
>
> More complicated examples :
>
>
> *Example 3. Two-dimensional tuple.*
>
> data === T/T :

What about T/S? S/T? S/S? Are these allowed? How would they work? I
hope you see my point from above about how these syntaxes are not
really homomorphic.

Also, why is there a division operator here?

> 123"hello"
> ab c + de f
>
> is a synonym for:
>
> data = (
> (1, 2, 3, "hello") ,
> (a, b, c + d, e, f ) )

If this is supposed to be a tabular format then why is the second row
allowed to have a different number of elements than the first row?

What about named fields? Is there a proposal for extending this syntax
to allow construction of dicts or namedtuples?

> The rule here is: TAB character is inner elements' separator, and the
> new line is outer elements' separator. Line continuation
> character is  \  (to help with long lines).

So brackets and commas are too ugly, but line continuation characters
are just fine?

> *The benefits is just as in above examples :
> readability and 'typeability' boost.*

Sorry, I don't see it. For presentation of data this may be fine, but
for code inside a program I'm much more interested in the organization
of the data than the data itself. Commas and brackets make the
organization clear. Tabs obscure it.

> *Main rules: *
> - the definition is allowed  only as a statement (no passing as argument)

Point for the existing syntax, which can be used as an expression.

> - (imo) data starts always as a new line after the header
> - implicit string concatenation disallowed

So this would be a syntax error?

foo === T:
"one" "two" "three"

That seems reasonable, but what about this?

foo === T/T:
"this is a very " \
"long string " \
"needing to be " \
"broken up over " \
"several lines"

> So the question is, how do you like such syntax

I see a lot of disadvantages and not many real advantages.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Suggestion for a "data" object syntax

[Ian Kelly]

On Thu, May 10, 2018 at 6:34 PM, Mikhail V  wrote:
> On Wed, May 9, 2018 at 6:25 AM, Steven D'Aprano
>  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 these are not ordinary expressions, are they? They're a different
type of expression and will require a modified parser. This adds
complexity.

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

Um, no, this is false. We send Python code by email all the time.

There are essentially three cases of tabs that can occur in Python:

1) Tabs as indentation: Python permits the use of both tabs and spaces
as indentation, but it requires consistency; if one line is indented
with a tab and three spaces, then the next line in the same block must
also use a tab and three spaces. Therefore, if the tabs are converted
to spaces, they will be converted to the same number of spaces
throughout the block. Indents and dedents remain intact, indentation
is therefore not ruined, and the meaning of the program is not
changed.

2) Tabs as other whitespace: Other tabs in the program, such as in
expressions, don't matter at all. They can safely be replaced with
spaces, and the meaning of the program is not changed.

3) Tabs that appear in strings: This one I'll grant you. A replaced
tab inside a string may alter the meaning of the program. However,
note two things: tabs are rarely used in strings, and when they do
appear it's usual to write them as \t rather than with an actual tab
character.

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
exception being tabs in strings which are better written as \t. In the
case of your proposed syntax however, the tabs are *required*, and it
is not possible to email a program containing such a construct at all.
Contrary to your assertion, this is *far* different from the status
quo.

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

When you're designing a language syntax, you need to account for *all*
the cases, not just the ones that you personally would use.

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

I don't know, I find that much less painful than:

L === T:
a + b   c   d

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

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

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

Why not? The existing Python syntax is fine for this.

> 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 

Re: Suggestion for a "data" object syntax

[Mikhail V]

On Wed, May 9, 2018 at 6:25 AM, Steven D'Aprano
 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
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: 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

-- 

Re: Suggestion for a "data" object syntax

[Mikhail V]

On Wed, May 9, 2018 at 3:14 AM, Ben Finney  wrote:
> Mikhail V  writes:
>
>> On Wed, May 9, 2018 at 12:33 AM, Chris Angelico  wrote:
>> > On Wed, May 9, 2018 at 7:15 AM, Mikhail V  wrote:
>> >> Just admit it, you try to troll me (or just pretend, I don't know).
>> >
>> > No, I am not trolling you.
>>
>> I don't believe you.
>
> If that's true – if you believe Chris is trolling you – then please do
> not continue the conversation. Since you have already decided Chris is
> trolling you,

Well, the thing is I don't know how exactly the word "trolling" can
be understood by different persons. I use it here in sense of "nitpicking".
Or "fooling around" I don't know actually.
So may be "trolling" has too negative associations to your ears?

As for Chris' attitude in this thread, and my point on this -
well, honestly yes, I believe he uses an opportunity to push
his own game. It has happened before - and now I know already,
so I know that trying to explain and honestly answer his questions ends up
in the same game of Chris - so I suppose he amuses himself
in such a way.
Same scenario happens here - he just completely neglects the whole
proposal straight away with a bold provoking statement.
But then asks "why do you think this a good proposal?"
Which I actually tried to describe in the very proposal.

So honestly I can't understand what game this time he prepared,
and not very much into this kind of things.



>
> This forum has no need of another thread attempting to “win” an argument
> that one side believes is dishonest.
>
> --
>  \   “The best in us does not require the worst in us: Our love of |
>   `\ other human beings does not need to be nurtured by delusion.” |
> _o__) —Sam Harris, at _Beyond Belief 2006_ |
> Ben Finney
>
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Suggestion for a "data" object syntax

[Ben Finney]

Mikhail V  writes:

> On Wed, May 9, 2018 at 12:33 AM, Chris Angelico  wrote:
> > On Wed, May 9, 2018 at 7:15 AM, Mikhail V  wrote:
> >> Just admit it, you try to troll me (or just pretend, I don't know).
> >
> > No, I am not trolling you.
>
> I don't believe you.

If that's true – if you believe Chris is trolling you – then please do
not continue the conversation. Since you have already decided Chris is
trolling you, it follows that you will not respond productively to
anything he says to you. So this thread is already lost.

This forum has no need of another thread attempting to “win” an argument
that one side believes is dishonest.

-- 
 \   “The best in us does not require the worst in us: Our love of |
  `\ other human beings does not need to be nurtured by delusion.” |
_o__) —Sam Harris, at _Beyond Belief 2006_ |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Suggestion for a "data" object syntax

[Mikhail V]

On Wed, May 9, 2018 at 12:33 AM, Chris Angelico  wrote:
> On Wed, May 9, 2018 at 7:15 AM, Mikhail V  wrote:
>> On Tue, May 8, 2018 at 5:25 PM, Chris Angelico  wrote:
>>> On Tue, May 8, 2018 at 10:52 PM, Mikhail V  wrote:
 Right? Your issues with tabs aside, I think it is impossible to ignore the
 the readability improvement. Not even speaking of how
 many commas and bracket you need to type in the first case.
>>>
>>> That's incredibly subjective. Or else straight-up wrong, I'm not sure which.
>>
>> Just admit it, you try to troll me (or just pretend, I don't know).
>
> No, I am not trolling you.

I don't believe you.


> Neither of those examples is program code. You are asking for a
> syntactic change to a *programming language*. Everything you've said
> is fine for a non-code format. Nothing is applicable to a programming
> language.

Everything I said in previous mail was related to your claim that it's
Ok (or even better?) readable
with brackets and commas in a table than without them.
I was not even starting this terminology course.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Suggestion for a "data" object syntax

[Mark Lawrence]

On 08/05/18 22:33, Chris Angelico wrote:

On Wed, May 9, 2018 at 7:15 AM, Mikhail V  wrote:

On Tue, May 8, 2018 at 5:25 PM, Chris Angelico  wrote:

On Tue, May 8, 2018 at 10:52 PM, Mikhail V  wrote:

Right? Your issues with tabs aside, I think it is impossible to ignore the
the readability improvement. Not even speaking of how
many commas and bracket you need to type in the first case.


That's incredibly subjective. Or else straight-up wrong, I'm not sure which.


Just admit it, you try to troll me (or just pretend, I don't know).


No, I am not trolling you.


Have you ever seen tables with commas left in there?


It's called CSV.


I've never seen in my whole life. And you should understand why.

Have you ever seen a website with sparse menu items or 'cloud' tags
with commas attached?
Have you ever heard someone claim that writing a 2d matrix down in a
single line is better that present it as a table?

So what you find _incredibly_ subjective here?


Neither of those examples is program code. You are asking for a
syntactic change to a *programming language*. Everything you've said
is fine for a non-code format. Nothing is applicable to a programming
language.


Why should this be a language feature? Why not just create a data file
and then load it, or use a triple quoted string and write your own
parser? What's the advantage of making this language syntax?


I am not sure what happens if I make another argument -
if it feels so easy for you to deny the obvious improvements (which
also supported by whole worlds' typography experience) then you can
just as easy deny pretty everything. How would we build any conversation
then?


Good question. You're clearly not interested in doing things the
existing (and easy) way, so there's no point debating this.
Fortunately for the rest of us, status quo wins a stalemate.

ChrisA



Please stop feeding the OP, to my knowledge he's never once come up with 
any sensible suggestion for Python.


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Suggestion for a "data" object syntax

[Chris Angelico]

On Wed, May 9, 2018 at 7:15 AM, Mikhail V  wrote:
> On Tue, May 8, 2018 at 5:25 PM, Chris Angelico  wrote:
>> On Tue, May 8, 2018 at 10:52 PM, Mikhail V  wrote:
>>> Right? Your issues with tabs aside, I think it is impossible to ignore the
>>> the readability improvement. Not even speaking of how
>>> many commas and bracket you need to type in the first case.
>>
>> That's incredibly subjective. Or else straight-up wrong, I'm not sure which.
>
> Just admit it, you try to troll me (or just pretend, I don't know).

No, I am not trolling you.

> Have you ever seen tables with commas left in there?

It's called CSV.

> I've never seen in my whole life. And you should understand why.
>
> Have you ever seen a website with sparse menu items or 'cloud' tags
> with commas attached?
> Have you ever heard someone claim that writing a 2d matrix down in a
> single line is better that present it as a table?
>
> So what you find _incredibly_ subjective here?

Neither of those examples is program code. You are asking for a
syntactic change to a *programming language*. Everything you've said
is fine for a non-code format. Nothing is applicable to a programming
language.

>> Why should this be a language feature? Why not just create a data file
>> and then load it, or use a triple quoted string and write your own
>> parser? What's the advantage of making this language syntax?
>
> I am not sure what happens if I make another argument -
> if it feels so easy for you to deny the obvious improvements (which
> also supported by whole worlds' typography experience) then you can
> just as easy deny pretty everything. How would we build any conversation
> then?

Good question. You're clearly not interested in doing things the
existing (and easy) way, so there's no point debating this.
Fortunately for the rest of us, status quo wins a stalemate.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Suggestion for a "data" object syntax

[Mikhail V]

On Tue, May 8, 2018 at 5:25 PM, Chris Angelico  wrote:
> On Tue, May 8, 2018 at 10:52 PM, Mikhail V  wrote:
>> Right? Your issues with tabs aside, I think it is impossible to ignore the
>> the readability improvement. Not even speaking of how
>> many commas and bracket you need to type in the first case.
>
> That's incredibly subjective. Or else straight-up wrong, I'm not sure which.

Just admit it, you try to troll me (or just pretend, I don't know).

Have you ever seen tables with commas left in there?
I've never seen in my whole life. And you should understand why.

Have you ever seen a website with sparse menu items or 'cloud' tags
with commas attached?
Have you ever heard someone claim that writing a 2d matrix down in a
single line is better that present it as a table?

So what you find _incredibly_ subjective here?

I am not telling tabulations work as they should in many code editors, but
there is a lot of work people invest to make better support for them in editors.
Here is another indirect benefit of adding such syntax, as editor developers
will be more motivated to improve the tabulation features.


> Why should this be a language feature? Why not just create a data file
> and then load it, or use a triple quoted string and write your own
> parser? What's the advantage of making this language syntax?

I am not sure what happens if I make another argument -
if it feels so easy for you to deny the obvious improvements (which
also supported by whole worlds' typography experience) then you can
just as easy deny pretty everything. How would we build any conversation
then?




>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Suggestion for a "data" object syntax

[Chris Angelico]

On Wed, May 9, 2018 at 6:16 AM, Mikhail V  wrote:
> Also I don't know what kind of human thinks that this:
>  a + b
>  is two elements "a" and "+ b"
> What is "+ b"?

Unary plus applied to whatever value 'b' is.

> And who writes "- b" with a space in unary minus?
> I don't. Nobody does. Is it allowed? yes. no problem.

You're making a syntax proposal. That means it has to cope with all
the vagaries of syntax, including things that you think "nobody does".

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

There are things that are ambiguous to the Python syntax parser.

If you want to create a completely new syntax that happens to
incorporate some Python expressions, that's not a problem. It isn't a
Python syntax enhancement, it is a completely separate file format,
and you can do what you like with that. You can use tabs to separate
tokens, eval() those tokens to figure out the actual value, and then
build the resulting data structure according to your rules. And it's
100% acceptable to demand a stricter form of Python syntax within your
tokens (eg "no tabs allowed"), because it's your own data file.

And, even better: You can write code to parse this, without needing
approval from the core devs. The code you write doesn't have to wait
until Python 3.8 is released (two years from now); it can run on
existing interpreters. All the advantages are on your side.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Suggestion for a "data" object syntax

[Mikhail V]

On Tue, May 8, 2018 at 6:20 PM, Steven D'Aprano
 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:
>> a1
>> b2
>> c3
>> foobar4
>>
>> 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 

Re: Suggestion for a "data" object syntax

[Steven D'Aprano]

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

The same applies to "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;

* or to make a subtle semantic difference between tabs and spaces
  of this sort.

Unix "make" files require tabs rather than spaces, and it is a constant 
source of bugs and frustration.


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

Who told you to use tab characters? It would not have been any of the 
core developers. Many of them would rather ban tabs than require them.


>> There's also the problem that your syntax requires the *invisible*
>> difference between tabs and spaces to be treated as syntactically
>> meaningful.
> 
> 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.


[...]
> So you would prefer this:
> 
> L = (
> (a, 1),
> (b, 2),
> (c, 3),
> (foobar, 4))
> 
> over this:
> 
> L === T/T:
> a1
> b2
> c3
> foobar4
> 
> 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.

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;

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

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

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

There is only one advantage to the second format. It gives bad 
programmers a justification to waste time while pretending to be working, 
as they carefully align their columns, then realign them each time the 
data changes.


> Your issues with tabs aside, I think it is impossible to ignore
> the the readability improvement.

An interesting philosophical conundrum... is it possible to ignore 
something which isn't there?

If there is no elephant in the room, and nobody mentions it, are they 
ignoring it?



-- 
Steve

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Suggestion for a "data" object syntax

[Liste guru]

Il 08/05/2018 14:52, Mikhail V ha scritto:

 ...

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.


    I like to 'type program.py' and understand what's happening, 
without have to fire up an editor.


   While, in C++, the Microsoft IDE (and some other) mark the class 
members & the parameters so you can easily see what 'counter' is, a lot 
of guide says that you should call it 'm_counter' if it's a member or 
'counter_' if it's a parameter, just in case you don't have your editor 
(or you're colorblind or you don't like to have the parameters printed 
with a light grey ...).



   ...
--
https://mail.python.org/mailman/listinfo/python-list

Re: Suggestion for a "data" object syntax

[Chris Angelico]

On Tue, May 8, 2018 at 10:52 PM, Mikhail V  wrote:
> Right? Your issues with tabs aside, I think it is impossible to ignore the
> the readability improvement. Not even speaking of how
> many commas and bracket you need to type in the first case.

That's incredibly subjective. Or else straight-up wrong, I'm not sure which.

Why should this be a language feature? Why not just create a data file
and then load it, or use a triple quoted string and write your own
parser? What's the advantage of making this language syntax?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Suggestion for a "data" object syntax

[Mikhail V]

On Tue, May 8, 2018 at 10:15 AM, Steven D'Aprano
 wrote:
> On Tue, 08 May 2018 06:45:05 +0300, Mikhail V wrote:
>
>> *Example 3. Two-dimensional tuple.*
>>
>> data === T/T :
>> 123"hello"
>> ab c + de f
>>
>> is a synonym for:
>>
>> data = (
>> (1, 2, 3, "hello") ,
>> (a, b, c + d, e, f ) )
>
> 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?
Last time and this time I told it uses TAB character to
separate elements.


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

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.

The only real issue I know that there may be no option to adjust the
minimal size for a tabulation, so it can become too small
in some rare cases, and there is the highlight function for that.

I never had problems with inputing tables - It seems you are having
an issue or may be it's even some personal pet-pieve.

>
> [...]
>> *The benefits is just as in above examples : readability and
>> 'typeability' boost.*
>
> But your syntax is not more readable, it is less readable and ambiguous.
> It requires us to care about the difference between two kinds of
> invisible whitespace.

Yes it requires you to care about tabulation - which many users already do
to improve readability in their code. As well as any software like
Matlab, Excel, etc presents matrices as tables.
So they are all making it "less readable", lol.
Ok Steven, you like the brackets and commas noise, that's
quite funny. Your opinion is heard, but I would be thankful if you'll
speak for yourself,
and not try to enforce your opinion with these "us", "for us".

Also you seem to start with cherry-picking straight away - trying
to find an issue and wind it up with the whole idea, totally ignoring
obvious benefits for most frequent use cases like multiline
strings,1d tuples/lists  and simple tables.
A very common table case is a 2-column table.

So you would prefer this:

L = (
(a, 1),
(b, 2),
(c, 3),
(foobar, 4))

over this:

L === T/T:
a1
b2
c3
foobar4

Right? Your issues with tabs aside, I think it is impossible to ignore the
the readability improvement. Not even speaking of how
many commas and bracket you need to type in the first case.


M
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Suggestion for a "data" object syntax

[Steven D'Aprano]

On Tue, 08 May 2018 06:45:05 +0300, Mikhail V wrote:

> *Example 3. Two-dimensional tuple.*
> 
> data === T/T :
> 123"hello"
> ab c + de f
> 
> is a synonym for:
> 
> data = (
> (1, 2, 3, "hello") ,
> (a, b, c + d, e, f ) )

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.

The same applies to unary minus.

That problem *alone* kills this idea.

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

[...]
> *The benefits is just as in above examples : readability and
> 'typeability' boost.*

But your syntax is not more readable, it is less readable and ambiguous. 
It requires us to care about the difference between two kinds of 
invisible whitespace.


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

So not only does idea not give us any new benefit, it cannot even do what 
existing syntax can do. It is inferior to what Python already has, 
ambiguous, and hard to read.

-- 
Steve

-- 
https://mail.python.org/mailman/listinfo/python-list

Suggestion for a "data" object syntax

[Mikhail V]

Here is an idea for 'data object' a syntax.
For me it is interesting, how would users find such syntax.
I personally find that this should be attractive from users
perspective.
Main aim is more readable presenting of typical data chunks
and some typical data types (tuples/lists) directly in code.
Further this should significantly simplify typing.

*Example 1. Multi-line strings*

Here is a 3 lines multi-line string, it will be automatically 'dedented'
by the parser by one level of indent:

data === S :
this is multi-line string
escape chars: same as in strings (\\, \\n, \\t ...) ,
but "no need to 'escape' quotes"

(Of course, assuming this feature will be added to the lexers
of your editor, otherwise it may mess up syntax highlighting)

So the proposed statement header is like:

variable === "type" :
...

The "===" token and type id's are of course subject to discussion.
"type" is type of data, which tells the parser to
convert data to specific type of Python object.
The above is type "S", a multi-line string.


*Example 2. Tuples*

Tuple is a data block with normal Python elements.

data === T :
123"hello"
abc + d

Here the separators of elements are : tab character,
new line (and maybe some white-space character like em-space?)
The above construct will be direct synonym for:

data = (1, 2, 3, "hello", a, b, c + d)

Benefits are easy to see: say I want a tuple of strings:

data === T :
"foo bar"
"hello world"
"to be continued..."

VS current:

data = (
"foo bar" ,
"hello world" ,
"to be continued..." ,
)

Main problem with the latter are commas, it is not easy
to type and, whats more important - hard to notice missing commas.
And brackets of course does not make it nicer either.

The above are typical cases where I see clear win, and
IMO they are quite common constructs.

More complicated examples :


*Example 3. Two-dimensional tuple.*

data === T/T :
123"hello"
ab c + de f

is a synonym for:

data = (
(1, 2, 3, "hello") ,
(a, b, c + d, e, f ) )

The rule here is: TAB character is inner elements' separator, and the
new line is outer elements' separator. Line continuation
character is  \  (to help with long lines).

*The benefits is just as in above examples :
readability and 'typeability' boost.*

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

data === T/T :
12(345)
ab c

Or maybe even allow commas:
data === T/T :
12(3, 4, 5)
ab c

VS normal:

data = (
(1, 2, (3, 4, 5) ) ,
(a, b, c ) )

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

Further, common types may be defined, like e.g. L/L (list of lists)
but I don't want to go far into details and want to stop
on common cases to help evaluate the idea in general.


*Main rules: *
- the definition is allowed  only as a statement (no passing as argument)
- (imo) data starts always as a new line after the header
- implicit string concatenation disallowed


So the question is, how do you like such syntax, and
if so, what common examples can be fit in here.
Any ideas, comments are of course welcome.
Suggest some data and I'll try to express it in this syntax.



M
-- 
https://mail.python.org/mailman/listinfo/python-list