osdir.com

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

"Data blocks" syntax specification draft


I understand that the /// data representation is meant to emphasize data structure (and de-emphasize existing Python syntax for that purpose).  It's already been discussed that Python can export to pickle format, JSON, csv, XML and possibly others I can't think of right now.  So having a data representation format is not a foreign concept.

All I want to say is that I don't really feel that there is a need for another data representation.  Also, even if we leave out parentheses, "/// a,b,c" is 9 characters, whereas "(a,b,c)" is 7 characters. And "a,b,c" is only 5 characters.  I think I would actually prefer the usual Python syntax, because to me it is clear (I already know Python) and typing fewer characters to achieve the same result appeals to me.

Perhaps I just don't value the benefit of this data representation technique, or perhaps there really is a benefit that I didn't get. If so forgive me.  But I do think that a good exposition of the benefit obtained by using this data representation will need to be made, or you may find that there are many other people like me.

--- Joseph S.



-----Original Message-----
From: Chris Angelico <rosuav at gmail.com> 
Sent: Wednesday, May 23, 2018 9:56 AM
To: Python <python-list at python.org>
Subject: Re: "Data blocks" syntax specification draft

On Wed, May 23, 2018 at 11:11 PM, Steven D'Aprano <steve+comp.lang.python at pearwood.info> wrote:
> On Wed, 23 May 2018 11:10:33 +0100, bartc wrote:
>> 0 items within the list:
>>
>> ()    Empty tuple
>> []    Empty list
>> {}    Empty dict
>
> Aye ... as we've acknowledged numerous times now, the empty tuple *is* 
> a genuine special case, one which *does* rely on an empty pair of 
> round brackets.

We actually have THREE special cases and only two types that follow the general case. Here's the general case:

List of three: [1, 2, 3] or [1, 2, 3,]
List of two: [1, 2] or [1, 2,]
List of one: [1] or [1,]
List of zero: []

Dict of three: {1:1, 2:2, 3:3} or {1:1, 2:2, 3:3,} Dict of two: {1:1, 2:2} or {1:1, 2:2,} Dict of one: {1:1} or {1:1,} Dict of zero: {}

Perfect! Now let's try that with other types.

Tuple of three: 1, 2, 3 or 1, 2, 3,
Tuple of two: 1, 2 or 1, 2,
Tuple of one: 1, # no other way to do it Tuple of zero: ()

Set of three: {1, 2, 3} or {1, 2, 3,}
Set of two: {1, 2} or {1, 2,}
Set of one: {1} or {1,}
Set of zero: set()

The empty set and empty tuple are special, as is the single-element tuple (you can't omit the comma). So, yes, there are definitely special cases in the grammar, and they come about because practicality beats purity. If we wanted perfectly clean grammar with no special cases, we'd probably have to use two-character bracketings, to ensure that everything is uniquely spellable, and there'd be no omitting them from tuples - so it really WOULD be the bracketing characters that define a tuple. But what would we gain? Very little. A few less special cases, maybe, in return for needing to write more verbose syntax for every literal/display type.

ChrisA