"Data blocks" syntax specification draft

[Dan Strohl]

On 5/19/18 10:58 PM, Mikhail V wrote:
>> I have made up a printable PDF with the current version of the syntax 
>> suggestion.
>>
>> https://github.com/Mikhail22/Documents/blob/master/data-blocks-v01.pdf
>>
>> After some of your comments I've made some further re-considerations, 
>> e.g. element separation should be now much simpler.
>> A lot of examples with comparison included.
>>
>>
>> Comments, suggestions are welcome.
>>
>
>Mikhail, you have a completely different esthetic for syntax than the rest of the Python world.  Your proposal seems to have almost nothing in common with existing Python syntax.  Your approach to >whitespace is different. You've ignored existing words (tuple, str) in favor of new shorthands (t, s).  You use semicolon and asterisk for something new. Parentheses enclosing strings!?
>
>This is never going to be adopted as Python syntax. It's too different.
>
>That's fine: make a new file format.  Write a library that can read and write this format.  Propose it to people, and get them using it.  We have xml, ini, json, yaml, and toml.  Now we can also have data >blocks.

Mikhail,

I'm afraid I would have to agree with Ned,   in looking at it, this did not seem to be any less complex than existing python structures, nor was it significantly less typing (in many cases) after you put the /// in there.

Also there were several places where it's not deterministic enough around data types... how would it handle a tuple like:

test=(0x991, 0x01, 'Hello', 123e334562.9, 1, '1', "This is a single string (including this)",  custom_object)

I get the idea of trying to remove some of those extra punctuation marks, but they exist for a reason, and removing them just leads to a more complex world of "sometimes you use them and sometimes you don’t".

For the dictionary type, with odd elements being keys and even being values, that can get really hard to visually parse if you have a long block in a row... for example:

///d abc def ghi jkl mno pqr stu vwx yz1 ab2 cd4

Would break, but... where?  Which parts are supposed to be keys v. values?

You mentioned ease of import of data in your summary, I haven't seen any data files that use a format like this, so I don’t offhand see that value, but if it is, as Ned mentioned, then doing a translator object for it makes sense.  Approach this like a new data format (like XML, JSON, etc) Then also, if it ends up taking off, you are better placed to come back and say "see, everyone's using this format, Python should handle it by default".

Finally, you mentioned several "main problems".  Those I totally agree with, but I don’t think you realize how complex they are.  The parser would have nightmares trying to parse some of these structures into tokens without having a totally different parser engine just for that, and there are lots of corner cases that would break this approach and would need a different approach, requiring a long list of caveats, and at least personally, I just don't see the value there.  The few places where it seems like it would be a benefit are pretty small, and the places where it makes things more complex seem common.

Dan Strohl