Re: "Data blocks" syntax specification draft

[Rick Johnson]

From: Rick Johnson 

On Sunday, May 20, 2018 at 5:29:11 PM UTC-5, Mikhail V wrote:

> What against PDF?

I'm not a big fan of PDF either. Adobe Reader is one the most bloated POS
software i have ever had the misfortune of hosting on my computers, and i
absolutely refuse to host that crapware any longer. And while there are smaller
 more sane PDF viewers and editors, i find the whole experience of PDF to be
annoying.

I would suggest sticking with HTML or raw text. Every computer worth its salt
has a web browser, but not every computer needs (yet another) special purpose
document format (PUKE!). And I refuse to participate in the propagation of the
PDF file format.

> Anyway, I have reloaded files with most recent corrections in various
formats:
>
> PDF
> https://github.com/Mikhail22/Documents/blob/master/data-blocks-v01.pdf
>
> TXT
> https://github.com/Mikhail22/Documents/blob/master/data-blocks-v01.txt
>
> HTML(direct preview link)
> http://htmlpreview.github.io/?https://raw.githubusercontent.com/Mikhail22/Doc
uments/master/data-blocks-v01.html

Thanks for providing the last two "sane" formats.

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[Abdur-Rahmaan Janhangeer]

From: Abdur-Rahmaan Janhangeer 

the tab separated idea is used in :

e.g. see last section of files

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ


>
>

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[Abdur-Rahmaan Janhangeer]

the tab separated idea is used in :

e.g. see last section of files

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ


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

Re: "Data blocks" syntax specification draft

[Steven D'Aprano]

On Tue, 22 May 2018 08:01:05 +0200, Christian Gollwitzer wrote:

>>> If a block of static data is large enough to start to be ugly, a
>>> common approach is to load the data from some other file, in a
>>> language which is designed around structured data.
[...]

> Thing is, you can do it already now in the script, without modifying the
> Python interpreter, by parsing a triple-quoted string. See the examples
> right here: http://pyyaml.org/wiki/PyYAMLDocumentation


Indeed. But that requires the data be parsed at runtime, and requires 
either that you use only literals, or that you use some form of string 
interpolation.

Imagine if the only way to write a list in Python was:

make_list("[1, 2, 3, %d, 5]" % n)

instead of [1, 2, 3, n, 5]. That would be annoying and inefficient. 
Parsing triple-quoted strings is a second-class solution. While I don't 
think much of Mikhail's proposed solution (except as a good example of 
how *not* to design programming syntax) the motivation is interesting: 
can we come up with a good syntax for table-based data?

Many years ago, people got frustrated with having to define dicts like 
this:

d = {'key': value, 'a': 1, 'b': 2, ...}

and now the dict constructor allows keywords:

d = dict(key=value, a=1, b=2, ...)

which covers the very common case of keys being strings and values being 
either identifiers or numeric literals, but cases where keys and values 
are both strings, and unlike dict displays {...} the compiler can't build 
the dict at compile-time. No compile-time optimization for us!

And I know I spend a lot of unproductive time editing tables of string 
constants, making sure all the strings are quoted, etc. I would hope 
there is a better way.

There are a very small number of languages with first-class literal 
syntax for (e.g.) XML:

Kawa
https://www.gnu.org/software/kawa/XML-literals.html

Racket
http://docs.racket-lang.org/xml/

VB.Net 
https://docs.microsoft.com/en-us/dotnet/visual-basic/programming-guide/
language-features/xml/xml-literals-overview

and possibly a few others. But it seems to be a niche feature.

There's also table-driven programming:

http://wiki.c2.com/?TableOrientedProgramming

an old, proven, but undervalued technique. Probably undervalued because 
it is *too simple for non-programmers to understand*.

https://blogs.msdn.microsoft.com/ericlippert/2004/02/24/table-driven-
programming/

I can't find any languages which have native data types for building 
tables. Have I missed any? Given how ubiquitous and useful tables of 
strings or numbers are, why aren't there simple ways to build such tables 
without parsing a string at runtime?

So there's a great big hole in programming languages here.



-- 
Steve

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

RE: "Data blocks" syntax specification draft

[Schachner, Joseph]

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 <ros...@gmail.com> 
Sent: Wednesday, May 23, 2018 9:56 AM
To: Python <python-list@python.org>
Subject: Re: "Data blocks" syntax specification draft

On Wed, May 23, 2018 at 11:11 PM, Steven D'Aprano 
<steve+comp.lang.pyt...@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

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

Re: "Data blocks" syntax specification draft

[bartc]

On 23/05/2018 14:56, Chris Angelico wrote:


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

Tuple of three: 1, 2, 3 or 1, 2, 3,

Not requiring any bracketing is poor IMO.

If you wanted the tuple to co-exist with any other thing in an 
expression, rather than being the only thing the expression comprises, 
then you will run into problems. Try adding two tuples:


  1, 2, 3 + 4, 5, 6

This in fact gives you 1,2,7,5,6 rather than 5,7,9. (I don't know if 
tuples can actually be added like this, but the point is clear.)


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

Re: "Data blocks" syntax specification draft

[bartc]

On 23/05/2018 14:11, Steven D'Aprano wrote:

On Wed, 23 May 2018 11:10:33 +0100, bartc wrote:

(x,)  Tuple of one item


Incorrect. Yet again, you have failed to do enough testing. No special
form is required. Only a comma:

py> x = 1,
py> type(x)


It isn't enough to test examples which confirm a hypothesis. You need to
test examples which also refute it, and see if your hypothesis survives
the challenge.


I use this trailing comma scheme in my own own languages too. The reason 
is simple, it is to distinguish between these two:


  (x) Ordinary bracketed expression
  (x) A list (in my case) of one item.

That is not needed for one less item: (), or one more: (x,y). Like 
Python, that trailing comma is not needed for [x] (I don't have a {...} 
constructor).


In both languages, it's just a hack to get around a syntax clash in the 
language.


I don't say however, that the comma is the defining feature of a list.

Comma is used to separate items of /any/ kind of list, and that trailing 
comma is used when there is an ambiguity or a conflict.


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

Re: "Data blocks" syntax specification draft

[Chris Angelico]

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

RE: "Data blocks" syntax specification draft

[Dan Strohl via Python-list]

First of all, I suggest splitting this into a separate proposal (new thread) 
that way you will avoid confusion for people who are still considering the 
older proposal, and for the (probably many) people who have stopped reding the 
old thread due to some of the more heated conversations in there.

> 
> Though hard-coded knock-out is also very useful, e.g. for this:
> 
> data = /// s4
> First line indented more (8 spaces)
> second - less (4 spaces)
> rest code
> 
> So this will preserve formatting.
> 

True, but in everything, there is a balance between flexibility and complexity. 
 Nothing else in python (that I can think of) forces people to use 4 spaces, 
that's merely a style thing.  If I want to use 2 spaces, I can, I've seen 
modules that use 3 spaces for indenting and it works fine.  So, the flexibility 
of adding the ability to further indent the first line seems to me to be 
outweighed by the added complexity of this being "different".

> 
> >> data = /// "???"
> >> ??? abc foo bar
> >> ???
> >>
> >> - defines indent character by string: crazy idea but why not.
> >>
> >
> > Nope, don't like this one... It's far enough from Python normal that
> > it seems unlikely to not get through, and (personally at least), I struggle 
> > to
> see the benefit.
> 
> Heh, that was merely joke - but OTOH one could use it for hard-coded indent
> sequences:
> 

Yeah, I get it (now  ), I would caution against making jokes in the 
middle of an already controversial thread.  When they are missed, they tend to 
be used against your suggestion.


> data = /// ""
> First line indented more (8 spaces)
> second - less (4 spaces)
> rest code
> 
> A bit sloppy look, but it generalizes some uses. But granted - I don't see 
> much
> real applications besides than space and tab indented block anyway - so it's
> under question.
> 
> 
> >> Language  parameter, e.g.:
> >> data = /// t1."yaml"
> >>
> >> -this can be reserved for future usage by code analysis tools or
> >> dynamic syntax highlighting.
> >>
> >
> > I can see where this might be interesting, but again, I just don't see
> > the need,
> 
> I think you're right  - if need a directive for some analysis tool then one 
> can
> make for example a consideration to precede the whole statement with a
> directive, say in a comment:
> 
> # lang "yaml"
> data = /// t
> first line
> last line
> rest
> 
> 

Again, you're complicating the thought without really providing enough benefit 
to it to justify the complication.   Something to keep in mind when you look at 
most languages, the simpler the language primitives the better, added 
flexibility can (and should) be added later in modules and functions.  But 
primitives should have as few caveats as possible, they should work pretty much 
anywhere with very little needed documentation.  To me, the idea of an indented 
TQS idea (data-string, data block, whatever) Is interesting.  Extra features 
are fine, but when they start making it "more complex" to use, then you should 
back off.

> 
> 
> Also I am thinking about this - there might be one useful 'hack".
> One could even allow single-line usage, e.g.; (with a semicolon)
> 
> data = /// s2:  first line
> 
> - so this would start parsing just after colon :
> "pretending it is block.
> This may be not so fat-fingered-proof and 'inconsistent', but in the end of 
> the
> day, might be a win actually.
> 
> 

If you are thinking about this road, what about instead making another reserved 
word and approaching it like class or def, for example;

datablock data:
first line
second line

Then you can also add functions without "breaking" python approaches like:

datablock data(foo, bar, blah):
First line
Second line

(*having thrown this out, I don’t know the parser/compiler well enough to know 
if this would cause more problems or not).

Being honest, I'm not sure that even these would be enough to get it added 
without a stronger case, but the further you stray from the python norms, the 
less likely it is to even get consideration.  
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[Steven D'Aprano]

On Wed, 23 May 2018 11:10:33 +0100, bartc wrote:

[...]
>> You haven't done enough testing. All you have done is found that "round
>> brackets give a tuple, other brackets don't". But you need to test what
>> happens if you take away the brackets to be sure that it is the round
>> brackets which create the tuple:
>> 
>>  a = 10, 20, 30  # take away the ()
>> 
>> You still get a tuple. Taking away the [] and {} also give tuples.
> 
> If ... is a comma-separated sequence of (2 or more) expressions, then:
> 
>   Enclosed with: It yields:
> 
>   {...} brackets Set (or dict with key:value items)
>   [...] brackets List
>   (...) brackets Tuple
>...  (no) bracketsTuple

Indeed.

> Each ... contains commas. But it is what surrounds ..., or that doesn't
> surround ..., that determines what the construction yields. The commas
> are not specific to tuples.

Nobody said that they were. You are arguing against a strawman. The 
brackets are not part of tuple syntax. They are sometimes needed for 
grouping, when some other grammatical construct would otherwise take 
precedence. That is all.


>> What happens if you add extra brackets?
>> 
>>  a = ((10, 20, 30))  # tuple
>>  b = ([10, 20, 30])  # list
>>  c = ({10, 20, 30})  # set
> 
> 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.



> 1 item within the list
> 
> (x)   Yields x

Exactly! There is no comma, therefore, there is no tuple.

> [x]   List of one item
> {x}   Set of one item

Neither of these require commas, since you don't need a separator to 
separate a single item. The square brackets *do* specify that the item is 
a list; the curly brackets *do* specify a dict or set. The round brackets 
DO NOT specify a tuple (except in the empty tuple case).

No comma, no tuple, no matter how emphatically you insert round brackets 
around the item.


> Because () is used for normal bracketing of expression terms, it
> requires this special form to denote a tuple:
> 
> (x,)  Tuple of one item

Incorrect. Yet again, you have failed to do enough testing. No special 
form is required. Only a comma:

py> x = 1,
py> type(x)


It isn't enough to test examples which confirm a hypothesis. You need to 
test examples which also refute it, and see if your hypothesis survives 
the challenge.

Certainly commas are used as separators. They're used as separators in 
many different contexts: import statements, function calls, function 
declarations, class declarations, except statements, list displays, etc. 
We don't dispute that or deny it.

But in the context of "tuple displays" (the official terminology for 
tuple so-called "literal" syntax), the brackets are not part of the tuple 
display. It is the commas that tell the interpreter that the result is a 
tuple:

https://docs.python.org/3/reference/expressions.html#expression-lists

Because commas are used as separators in so many places, there is often a 
clash between one part of the grammar that uses commas and their use in 
tuples, requiring us to disambiguate the syntax with brackets.

https://docs.python.org/3/reference/expressions.html#parenthesized-forms


> which can ALSO be used to form one element lists, sets and dicts.

But *unlike* one-element lists, sets and dicts, where the comma is 
optional, it is *required* for tuples.


[...]
> Suppose you were parsing Python source, had just processed a term of an
> expression, and the next token was a comma. What came before the term
> may have been (, {, [ or nothing. What comes next, would you call:
[...]

I don't even understand what point you think you are making here. But it 
really doesn't matter. Ultimately, the grammar and documentation trumps 
any hypotheses we might have about what the language is doing, and they 
are absolutely clear about what is going on:


https://docs.python.org/3/reference/expressions.html#expression-lists
https://docs.python.org/3/reference/expressions.html#parenthesized-forms


-- 
Steve

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

Re: "Data blocks" syntax specification draft

[Steven D'Aprano]

On Wed, 23 May 2018 03:02:48 -0600, Ian Kelly wrote:

> Maybe you are the one who is being overly pedantic.

I resemble that remark!



-- 
Steve

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

Re: "Data blocks" syntax specification draft

[bartc]

On 23/05/2018 07:03, Chris Angelico wrote:

On Wed, May 23, 2018 at 3:32 PM, Christian Gollwitzer  wrote:



I'd think that the definitive answer is in the grammar, because that is what
is used to build the Python parser:

 https://docs.python.org/3/reference/grammar.html

Actually, I'm a bit surprised that tuple, list etc. does not appear there as
a non-terminal. It is a bit hard to find, and it seems that "atom:" is the
starting point for parsing tuples, lists etc.



The grammar's a bit hard to read for this sort of thing, as the only
hint of semantic meaning is in the labels at the beginning. For
example, there's a "dictorsetmaker" entry that grammatically could be
a dict comp or a set comp; distinguishing them is the job of other
parts of the code.


Looking at all the instances of "','" (and there are plenty), none of 
them are tied to anything to do with tuples. Actually 'tuple' doesn't 
appear at all.


'dict' does, presumably because a dict-constructor is different 
syntactically in requiring key:value pairs.


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

Re: "Data blocks" syntax specification draft

[bartc]

On 23/05/2018 07:47, Steven D'Aprano wrote:

On Tue, 22 May 2018 18:51:30 +0100, bartc wrote:


On 22/05/2018 15:25, Chris Angelico wrote:

[...]

The tuple has nothing to do with the parentheses, except for the
special case of the empty tuple. It's the comma.


No? Take these:

   a = (10,20,30)
   a = [10,20,30]
   a = {10,20,30}

If you print type(a) after each, only one of them is a tuple - the one
with the round brackets.


You haven't done enough testing. All you have done is found that "round
brackets give a tuple, other brackets don't". But you need to test what
happens if you take away the brackets to be sure that it is the round
brackets which create the tuple:

 a = 10, 20, 30  # take away the ()

You still get a tuple. Taking away the [] and {} also give tuples.


If ... is a comma-separated sequence of (2 or more) expressions, then:

 Enclosed with: It yields:

 {...} brackets Set (or dict with key:value items)
 [...] brackets List
 (...) brackets Tuple
  ...  (no) bracketsTuple

Each ... contains commas. But it is what surrounds ..., or that doesn't 
surround ..., that determines what the construction yields. The commas 
are not specific to tuples.



What happens if you add extra brackets?

 a = ((10, 20, 30))  # tuple
 b = ([10, 20, 30])  # list
 c = ({10, 20, 30})  # set


0 items within the list:

()Empty tuple
[]Empty list
{}Empty dict

1 item within the list

(x)   Yields x
[x]   List of one item
{x}   Set of one item

Because () is used for normal bracketing of expression terms, it 
requires this special form to denote a tuple:


(x,)  Tuple of one item

which can ALSO be used to form one element lists, sets and dicts.


What if we take away the commas but leave the brackets? If "brackets make
tuples", then the commas ought to be optional.

 a = (10 20 30)  # SyntaxError


This will be a syntax error with [] and {} as well. I never said the 
commas were optional, only that the resulting type depends on bracketing 
(see above)



The comma is just generally used to separate expressions, it's not
specific to tuples.


Nobody said it was specific to tuples. That would be an absurd thing to
say. What was said is that the comma is what makes tuples, not the
brackets.


Suppose you were parsing Python source, had just processed a term of an 
expression, and the next token was a comma. What came before the term 
may have been (, {, [ or nothing. What comes next, would you call:


  readtuplesequence()

or:

  readexprsequence()

or:

  readexprsequence(type_of_sequence) # ie. tuple, list etc

(assume recursive descent parser). Since they have to accomplish the 
same thing (read series of comma-separated terms), what would be the 
advantage in having a separate routine just for tuples?



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

Re: "Data blocks" syntax specification draft

[Abdur-Rahmaan Janhangeer]

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ

Comments, suggestions are welcome.
>

nice effort

well as far as i've seen, it is more suited as a data standard than a
direct python integration

why?

same as why do we write .json files, xml files, csv files apart as,
in-source you want to emphasize logic, not data

if it works well and is adopted by nice projects etc, then it might make
it's way into py's support by that way

the only downside to a tab-based standard is readability unless you assure
more or less constant word length. same reasons the guys in here explained
to me why we should not align equal signs. if readability is not an issue,
then xml might be your friend

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

Re: "Data blocks" syntax specification draft

[Ian Kelly]

On Wed, May 23, 2018 at 12:49 AM, Steven D'Aprano
 wrote:
> On Tue, 22 May 2018 09:43:55 -0600, Ian Kelly wrote:
>
>> In other words, the rule is not really as simple as "commas make
>> tuples". I stand by what I wrote.
>
> Being pedantic is great, but if you're going to be pedantic, it pays to
> be *absolutely correctly* pedantic *wink*
>
> Chris is right to say "commas make tuples", and never implied that making
> tuples is *all* that commas do. That would be an absurd thing for him to
> say. Fortunately he didn't :-)
>
> If your comment had been posed as an addition to Chris' comment ("By the
> by, commas also do this that and the other...") then it would have been
> unobjectionable. But by posing it as a correction ("Although, if the rule
> were really as simple ...") you left yourself wide-open to be criticised
> in turn for failing to be pedantic *enough*.

I don't understand why you read that as a correction and not as an
addition. I never said that Chris was *wrong*. I read my comment as
implying that he was correct, and also that there was more to it.
Maybe you are the one who is being overly pedantic.

> Of course commas can be used elsewhere, just as the use of "if" in if
> statements doesn't prevent us from using that same token in the ternary
> if operator.
>
> In the context of the discussion (namely, the mistaken belief that tuples
> are created by parentheses, which we can often leave out) pointing out
> that commas are *also* used as separators in import statements, lists,
> dicts, function parameter lists etc adds noise but no insight to the
> understanding of tuples.

Then you misunderstood my post. My point was not that commas are also
used for other purposes, but that there are other special cases beyond
the empty tuple where commas alone are insufficient and parentheses
are required to create a tuple.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[Steven D'Aprano]

On Tue, 22 May 2018 09:43:55 -0600, Ian Kelly wrote:

> In other words, the rule is not really as simple as "commas make
> tuples". I stand by what I wrote.

Being pedantic is great, but if you're going to be pedantic, it pays to 
be *absolutely correctly* pedantic *wink*

Chris is right to say "commas make tuples", and never implied that making 
tuples is *all* that commas do. That would be an absurd thing for him to 
say. Fortunately he didn't :-)

If your comment had been posed as an addition to Chris' comment ("By the 
by, commas also do this that and the other...") then it would have been 
unobjectionable. But by posing it as a correction ("Although, if the rule 
were really as simple ...") you left yourself wide-open to be criticised 
in turn for failing to be pedantic *enough*.

Of course commas can be used elsewhere, just as the use of "if" in if 
statements doesn't prevent us from using that same token in the ternary 
if operator.

In the context of the discussion (namely, the mistaken belief that tuples 
are created by parentheses, which we can often leave out) pointing out 
that commas are *also* used as separators in import statements, lists, 
dicts, function parameter lists etc adds noise but no insight to the 
understanding of tuples.


-- 
Steve

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

Re: "Data blocks" syntax specification draft

[Steven D'Aprano]

On Tue, 22 May 2018 18:51:30 +0100, bartc wrote:

> On 22/05/2018 15:25, Chris Angelico wrote:
[...]
>> The tuple has nothing to do with the parentheses, except for the
>> special case of the empty tuple. It's the comma.
> 
> No? Take these:
> 
>   a = (10,20,30)
>   a = [10,20,30]
>   a = {10,20,30}
> 
> If you print type(a) after each, only one of them is a tuple - the one
> with the round brackets.

You haven't done enough testing. All you have done is found that "round 
brackets give a tuple, other brackets don't". But you need to test what 
happens if you take away the brackets to be sure that it is the round 
brackets which create the tuple:

a = 10, 20, 30  # take away the ()

You still get a tuple. Taking away the [] and {} also give tuples.

What happens if you add extra brackets?

a = ((10, 20, 30))  # tuple
b = ([10, 20, 30])  # list
c = ({10, 20, 30})  # set


The round brackets are just used for grouping. In fact, the bytecode 
generated is identical:

py> import dis
py> dis.dis("(99, x)")
  1   0 LOAD_CONST   0 (99)
  3 LOAD_NAME0 (x)
  6 BUILD_TUPLE  2
  9 RETURN_VALUE
py> dis.dis("99, x")
  1   0 LOAD_CONST   0 (99)
  3 LOAD_NAME0 (x)
  6 BUILD_TUPLE  2
  9 RETURN_VALUE

What if we take away the commas but leave the brackets? If "brackets make 
tuples", then the commas ought to be optional.

a = (10 20 30)  # SyntaxError


What if we simple add a single comma to end end, outside of the brackets?

a = (10, 20, 30),  # tuple inside tuple
b = [10, 20, 30],  # list inside tuple
c = {10, 20, 30},  # set inside tuple


Conclusion: it is the comma, not the round brackets, which defines tuples 
(aside from the empty tuple case).



> The 10,20,30 in those other contexts doesn't create a tuple, nor does it
> here:
> 
>f(10,20,30)

That's okay. There's no rule that says commas are ONLY used for tuples, 
just as there is no rule that says "if" is ONLY be used for if 
statements. (It is also used in the ternary if operator, elif, and any 
valid identifier which happens to include the letters "if" in that order).


> It's just that special case I
> highlighted where an unbracketed sequence of expressions yields a tuple.

You have that backwards. An unbracketed sequence of expressions yielding 
a tuple is not the special case, it is the base case. If you want 
something which is not a tuple (a list, a set) you have to use square or 
curly brackets.

The round brackets are only neccessary for tuples to group items in case 
of ambiguity with other grammar rules. (And the empty tuple.)



> The comma is just generally used to separate expressions, it's not
> specific to tuples.

Nobody said it was specific to tuples. That would be an absurd thing to 
say. What was said is that the comma is what makes tuples, not the 
brackets.


-- 
Steve

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

Re: "Data blocks" syntax specification draft

[Ian Kelly]

On Wed, May 23, 2018 at 12:01 AM, Ian Kelly  wrote:
> On Tue, May 22, 2018 at 11:32 PM, Christian Gollwitzer  
> wrote:
>> Am 23.05.18 um 07:22 schrieb Chris Angelico:
>>>
>>> On Wed, May 23, 2018 at 9:51 AM, bartc  wrote:

 Sorry, but I don't think you're right at all. unless the official
 references
 for the language specifically say that commas are primarily for
 constructing
 tuples, and all other uses are exceptions to that rule.
>>>
>>>
>>> "A tuple consists of a number of values separated by commas"
>>>
>>> https://docs.python.org/3/tutorial/datastructures.html#tuples-and-sequences
>>>
>>> "Separating items with commas"
>>> https://docs.python.org/3/library/stdtypes.html#tuple
>>>
>>> "Note that tuples are not formed by the parentheses, but rather by use
>>> of the comma operator."
>>> https://docs.python.org/3/reference/expressions.html#parenthesized-forms
>>>
>>> Enough examples? Commas make tuples, unless context specifies otherwise.
>>
>>
>> I'd think that the definitive answer is in the grammar, because that is what
>> is used to build the Python parser:
>>
>> https://docs.python.org/3/reference/grammar.html
>>
>> Actually, I'm a bit surprised that tuple, list etc. does not appear there as
>> a non-terminal. It is a bit hard to find, and it seems that "atom:" is the
>> starting point for parsing tuples, lists etc.
>
> For enclosed tuples, yes. I believe that tuples without parentheses
> can be produced by either 'exprlist' or 'testlist' (which is why some
> cases permit iterable unpacking and some don't).

Er, that should be "either 'testlist_star_expr' or 'testlist'".
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[Marko Rauhamaa]

Christian Gollwitzer :

> I'd think that the definitive answer is in the grammar, because that is
> what is used to build the Python parser:
>
>   https://docs.python.org/3/reference/grammar.html
>
> Actually, I'm a bit surprised that tuple, list etc. does not appear
> there as a non-terminal. It is a bit hard to find, and it seems that
> "atom:" is the starting point for parsing tuples, lists etc.

testlist and testlist_comp are the interesting entities.

The syntax definition does not help you understand the semantics. For
example, omitting yield_expr and testlist_comp in

   atom: ('(' [yield_expr|testlist_comp] ')' |

evaluates to a tuple and nothing in

   testlist: test (',' test)* [',']

suggests what effect the the presence or absence of the final ',' could
have on the evaluation.


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

Re: "Data blocks" syntax specification draft

[Chris Angelico]

On Wed, May 23, 2018 at 3:32 PM, Christian Gollwitzer  wrote:
> Am 23.05.18 um 07:22 schrieb Chris Angelico:
>>
>> On Wed, May 23, 2018 at 9:51 AM, bartc  wrote:
>>>
>>> Sorry, but I don't think you're right at all. unless the official
>>> references
>>> for the language specifically say that commas are primarily for
>>> constructing
>>> tuples, and all other uses are exceptions to that rule.
>>
>>
>> "A tuple consists of a number of values separated by commas"
>>
>> https://docs.python.org/3/tutorial/datastructures.html#tuples-and-sequences
>>
>> "Separating items with commas"
>> https://docs.python.org/3/library/stdtypes.html#tuple
>>
>> "Note that tuples are not formed by the parentheses, but rather by use
>> of the comma operator."
>> https://docs.python.org/3/reference/expressions.html#parenthesized-forms
>>
>> Enough examples? Commas make tuples, unless context specifies otherwise.
>
>
> I'd think that the definitive answer is in the grammar, because that is what
> is used to build the Python parser:
>
> https://docs.python.org/3/reference/grammar.html
>
> Actually, I'm a bit surprised that tuple, list etc. does not appear there as
> a non-terminal. It is a bit hard to find, and it seems that "atom:" is the
> starting point for parsing tuples, lists etc.
>

The grammar's a bit hard to read for this sort of thing, as the only
hint of semantic meaning is in the labels at the beginning. For
example, there's a "dictorsetmaker" entry that grammatically could be
a dict comp or a set comp; distinguishing them is the job of other
parts of the code.

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

Re: "Data blocks" syntax specification draft

[Ian Kelly]

On Tue, May 22, 2018 at 11:32 PM, Christian Gollwitzer  wrote:
> Am 23.05.18 um 07:22 schrieb Chris Angelico:
>>
>> On Wed, May 23, 2018 at 9:51 AM, bartc  wrote:
>>>
>>> Sorry, but I don't think you're right at all. unless the official
>>> references
>>> for the language specifically say that commas are primarily for
>>> constructing
>>> tuples, and all other uses are exceptions to that rule.
>>
>>
>> "A tuple consists of a number of values separated by commas"
>>
>> https://docs.python.org/3/tutorial/datastructures.html#tuples-and-sequences
>>
>> "Separating items with commas"
>> https://docs.python.org/3/library/stdtypes.html#tuple
>>
>> "Note that tuples are not formed by the parentheses, but rather by use
>> of the comma operator."
>> https://docs.python.org/3/reference/expressions.html#parenthesized-forms
>>
>> Enough examples? Commas make tuples, unless context specifies otherwise.
>
>
> I'd think that the definitive answer is in the grammar, because that is what
> is used to build the Python parser:
>
> https://docs.python.org/3/reference/grammar.html
>
> Actually, I'm a bit surprised that tuple, list etc. does not appear there as
> a non-terminal. It is a bit hard to find, and it seems that "atom:" is the
> starting point for parsing tuples, lists etc.

For enclosed tuples, yes. I believe that tuples without parentheses
can be produced by either 'exprlist' or 'testlist' (which is why some
cases permit iterable unpacking and some don't).
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[Christian Gollwitzer]

Am 23.05.18 um 07:22 schrieb Chris Angelico:

On Wed, May 23, 2018 at 9:51 AM, bartc  wrote:

Sorry, but I don't think you're right at all. unless the official references
for the language specifically say that commas are primarily for constructing
tuples, and all other uses are exceptions to that rule.


"A tuple consists of a number of values separated by commas"
https://docs.python.org/3/tutorial/datastructures.html#tuples-and-sequences

"Separating items with commas"
https://docs.python.org/3/library/stdtypes.html#tuple

"Note that tuples are not formed by the parentheses, but rather by use
of the comma operator."
https://docs.python.org/3/reference/expressions.html#parenthesized-forms

Enough examples? Commas make tuples, unless context specifies otherwise.


I'd think that the definitive answer is in the grammar, because that is 
what is used to build the Python parser:


https://docs.python.org/3/reference/grammar.html

Actually, I'm a bit surprised that tuple, list etc. does not appear 
there as a non-terminal. It is a bit hard to find, and it seems that 
"atom:" is the starting point for parsing tuples, lists etc.


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

Re: "Data blocks" syntax specification draft

[Chris Angelico]

On Wed, May 23, 2018 at 9:51 AM, bartc  wrote:
> On 22/05/2018 16:57, Chris Angelico wrote:
>>
>> On Wed, May 23, 2018 at 1:43 AM, Ian Kelly  wrote:
>
>
>>> In other words, the rule is not really as simple as "commas make
>>> tuples". I stand by what I wrote.
>>
>>
>> Neither of us is wrong here.
>
>
> Sorry, but I don't think you're right at all. unless the official references
> for the language specifically say that commas are primarily for constructing
> tuples, and all other uses are exceptions to that rule.

"A tuple consists of a number of values separated by commas"
https://docs.python.org/3/tutorial/datastructures.html#tuples-and-sequences

"Separating items with commas"
https://docs.python.org/3/library/stdtypes.html#tuple

"Note that tuples are not formed by the parentheses, but rather by use
of the comma operator."
https://docs.python.org/3/reference/expressions.html#parenthesized-forms

Enough examples? Commas make tuples, unless context specifies otherwise.

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

Re: "Data blocks" syntax specification draft

[Mikhail V]

On Wed, May 23, 2018 at 2:25 AM, Dan Strohl  wrote:
>

>>
>> Explanation:
>> [here i'll use same symbol /// for the data entry point, but of course it 
>> can be
>> changed if a better idea comes later. Also for now, just for simplicity - 
>> the rule
>> is that the contents of a block starts always on the new line.
>>
>> So, e.g. this:
>>
>> data = /// s4
>> first line
>> last line
>> the rest python code
>>
>> - will parse the block and knock out leading 4 spaces.
>> i.e. if the first line has 5 leading spaces then 1 space will be left in the 
>> string.
>> Block parsing terminates when the next line does not satisfy the indent
>> sequence (4 spaces in this case).
>
>
> Personally though, I would not hard code it to knock out 4 leading spaces.
> I would have it handle spaces the same was that the existing parser does,

If I understand you correctly, then I think I have this option already
described,
i.e. these:

>> data = /// ts
>>
>> - "any whitespace" (mimic current Python behaviour)
>>
>> data = /// s# or
>> data = /// t
>>
>> - simply count amount of spaces (tabs) from first
>>   line and proceed, otherwise terminate.


Though hard-coded knock-out is also very useful, e.g. for this:

data = /// s4
First line indented more (8 spaces)
second - less (4 spaces)
rest code

So this will preserve formatting.


>> data = /// "???"
>> ??? abc foo bar
>> ???
>>
>> - defines indent character by string: crazy idea but why not.
>>
>
> Nope, don't like this one... It's far enough from Python normal that it seems
> unlikely to not get through, and (personally at least), I struggle to see the 
> benefit.

Heh, that was merely joke - but OTOH one could use it for hard-coded
indent sequences:

data = /// ""
First line indented more (8 spaces)
second - less (4 spaces)
rest code

A bit sloppy look, but it generalizes some uses. But granted - I don't
see much real applications besides than space and tab indented block
anyway - so it's under question.


>> Language  parameter, e.g.:
>> data = /// t1."yaml"
>>
>> -this can be reserved for future usage by code analysis tools or dynamic
>> syntax highlighting.
>>
>
> I can see where this might be interesting, but again, I just don't see the 
> need,

I think you're right  - if need a directive for some analysis tool then one
can make for example a consideration to precede the whole statement
with a directive, say in a comment:

# lang "yaml"
data = /// t
first line
last line
rest




Also I am thinking about this - there might be one useful 'hack".
One could even allow single-line usage, e.g.;
(with a semicolon)

data = /// s2:  first line

- so this would start parsing just after colon :
"pretending it is block.
This may be not so fat-fingered-proof and 'inconsistent',
but in the end of the day, might be a win actually.



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

Re: "Data blocks" syntax specification draft

[Mikhail V]

On Tue, May 22, 2018 at 1:25 PM, bartc  wrote:
> On 22/05/2018 03:49, Mikhail V wrote:
>>
>> On Mon, May 21, 2018 at 3:48 PM, bartc  wrote:
>>
>> # t
>> # t
>>11  22  33
>>
>
> Is this example complete? Presumably it means ((11,22,33),).

Yep.

>
>> You get the point?
>> So basically all nice chars are already occupied.
>
> You mean for introducing tuple, list and dict literals?

No, I've meant the node (or whole data block) entry point chars ///.

So in such an language full of various operators, it is
just hard to find anything that does not clash with some
current meaning yet looks adequate and is ASCII.

A quick note: thanks for your comments, I'll  just note that I've
moved to some more promising related proposal (see last posts in this thread),
so the original one will move to later considerations.
so the nuances will be reconsidered anyway.


> Python already uses
> (, [ and { for those, with the advantage of having a closing ), ] and } to
> make it easier to see where each ends.

Ehm, for inline usage - i.e. everywhere on a line - closing tags are necessity.
My whole idea was about indentation based data - so there it is redundant noise.
You may disagree as well, since I've noticed in some previous thread
that you prefer Fortran-like termination tags. So that's quite personal I think.

As for more objective points: currently many brackets are 'overloaded'
and moreover, they are all almost "homoglyphs" - very similar characters.

For an inline solution I'd prefer it e.g.
for a tuple:

{t  11  22  33}

nested:
{t  11  {t  11  22}  22}

Yes, it IS worse than:
{11  {11  22}  22}

But still one might need _various types_ so brackets only - has
limited potential in this sense.


>>> The ///d dictionary example is ambiguous: can you have more than one
>>> key:value per line or not? If so, it would look like this:
>>>
>>>///d "a" "b" "c" "d" "e" "f"
>>
>>
>> ///d   "a" "b""c" "d""e" "f"
>>
>> Now better? :-)
>
>
> Not really.
> Suppose one got accidentally missed out, and there was some
> spurious name at the end,

Not sure about your case, but it is up to you to format it to make it
more readable - whitespace / newline separation gives enough possibilities to
do so. And for me the lack of commas is of great benefit.
 _Some_ punctuation can be added in some cases (see e.g. "node
stacking section" in original document - dicts may adopt this as well
but I see no necessity at least for this case)


> It's not clear whether:
>
>   ///d a b
> c e
> f x
>
> is allowed ?

allowed, but i'd say merely discouraged for industrial usage. better start
newline at least for multiline contents.

> I think this is an interesting first draft of an idea, but it doesn't seem
> rigorous. And people don't like that triple stroke prefix, or those single
> letter codes (why not just use 'tuple', 'list', 'dict')?
>
> For example, here is a proposal I've just made up for a similar idea, but to
> make such constructors obey similar rules to Python blocks:
>
>  tuple:
>  10
>  20
>  30
>
>  list:
>  list:
>  10
>  tuple: 5,6,7
>  30
>  "forty"
>  "fifty"
>

Cool, I've commented on similar option actually in some post before -
it might be ok
with type codes grayed-out and good coloring, but in black and white it is a bit
"wall of text" - not much emphasis on _structure_. But its ok - good option.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[bartc]

On 22/05/2018 16:57, Chris Angelico wrote:

On Wed, May 23, 2018 at 1:43 AM, Ian Kelly  wrote:



In other words, the rule is not really as simple as "commas make
tuples". I stand by what I wrote.


Neither of us is wrong here.


Sorry, but I don't think you're right at all. unless the official 
references for the language specifically say that commas are primarily 
for constructing tuples, and all other uses are exceptions to that rule.


AFAICS, commas are used just like commas everywhere - used as 
separators. The context tells Python what the resulting sequence is.


 "Commas make tuples" is a useful

oversimplification in the same way that "asterisk means
multiplication" is. The asterisk has other meanings in specific
contexts (eg unpacking), but outside of those contexts, it means
multiplication.


I don't think that's quite right either. Asterisk is just an overloaded 
token but you will what it's for as soon as it's encountered.


Comma seems to be used only as a separator.


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

RE: "Data blocks" syntax specification draft

[Dan Strohl via Python-list]

> -Original Message-
> 
> I think it would be appropriate to propose an alternative to TQS for this
> specific purposes. Namely for making it easier to implement parsers and
> embedded syntaxes.
> 
> So what do I have now with triple quoted strings - a simple example:
> 
> if 1:
> s = """\
> print ("\n") \\
> foo = 5
> """
> 
> So there is a _possibility_ in the sense it is possible to do, so let's say I 
> have a
> lib with a parser, etc. Though now a developer and a user will face quite real
> issues:
> 
> - TQS itself has its specific purpose already in many contents,
>   which may mean for example hard-coded syntax highlighting
> - there a lot of things happening here: e.g. in the above example
>   I use "\n" which I assume a part of string, or \\ - but it is interpreted.
>   Maybe some other things regarding escaping. This particular
>   issue maybe a blocker for making use of TQS in some data cases,
>   Say if the target source text need these very characters.
> 

Yup, I can see this, I do use """ in a number of ways, often to comment out 
large chunks of code. (OK, I probably should not, but I do).

> - indentation is the part of TQS. That is of couse by design
>   so and it's quite logical, though it is hard-coded behaviour and thus
>   does not make the presentation a natural part of blocks containing
>   this string.
> - appearance: imagine you have some small chunks of embedded
>   code parts and you will still have the closing """ everywhere -
>   that would be really hairy.
> 
> 

And yup, that does cause some challenges sometimes.

> 
> Explanation:
> [here i'll use same symbol /// for the data entry point, but of course it can 
> be
> changed if a better idea comes later. Also for now, just for simplicity - the 
> rule
> is that the contents of a block starts always on the new line.
> 
> So, e.g. this:
> 
> data = /// s4
> first line
> last line
> the rest python code
> 
> - will parse the block and knock out leading 4 spaces.
> i.e. if the first line has 5 leading spaces then 1 space will be left in the 
> string.
> Block parsing terminates when the next line does not satisfy the indent
> sequence (4 spaces in this case).
> Another obvious type: tabs:

OK, I CAN see this as a potentially useful suggestion.  There are a number of 
times where I would like to define a large chunk of text, but using tqs and 
having it suddenly move to the left is painful visually.  Right now, I tend to 
either a) do it anyway, b) do it in a separate module and import the variables, 
or c) do it and parse the string to remove the extra spaces.

Personally though, I would not hard code it to knock out 4 leading spaces.   I 
would have it handle spaces the same was that the existing parser does, if 
there are 4 spaces indending the next line, then it removes 4 spaces, if there 
are 6 spaces, it removes 6 spaces, etc... ignoring additional spaces within the 
data-string object.  Once it hits a line that has the same number if indenting 
spaces as the initial token, the data-string object is finished.

> 
> data = /// t1
> first line
> last line
> the rest python code
> 
> Will do the same but with one tabstop character.
> 

Tabs / spaces should be handled as normal (up to the data-string object starts, 
after which, it pulls off the first x tabs or spaces, and leaves anything else) 

> Actually that's it!
> Some further ideas:
> 
> data = /// ts
> - "any whitespace" (mimic current Python behaviour)
> 
> data = /// s# or
> data = /// t
> - simply count amount of spaces (tabs) from first
>   line and proceed, otherwise terminate.
> 
> data = /// "???"
> ??? abc foo bar
> ???
> 
> - defines indent character by string: crazy idea but why not.
> 

Nope, don't like this one... It's far enough from Python normal that it seems 
unlikely to not get through, and (personally at least), I struggle to see the 
benefit.

> Language  parameter, e.g.:
> data = /// t1."yaml"
> 
> -this can be reserved for future usage by code analysis tools or dynamic
> syntax highlighting.
> 

I can see where this might be interesting, but again, I just don't see the 
need, if the spec returns a string, you can use that string in any parser you 
want. If you want to customize how it's handled, then you can always create a 
custom object for it.

> That's just a rough specification.
> 
> What should it give as result:
> 

To me, this seems like a simply additional specification for a TQS, with the 
only enhancement being that it's an indented TQS basically, so the return is a 
string.

> 1. No clash with current TQS rules - less worries
>   about reserved characters.
> 
> 2. Built-in indentation parsing parameter makes it more or
>   less natural continuation of Python blocks and is char-precise,
>   which is very important here.
> 
> 3. Independent of the indent of containing block!
> 
> 4. Parameter descriptor can be developed in such manner
>that it allows more customisation and 

Re: "Data blocks" syntax specification draft

[Mikhail V]

On Tue, May 22, 2018 at 9:01 AM, Christian Gollwitzer  wrote:
> Am 22.05.18 um 04:17 schrieb Mikhail V:
>>> YAML comes to mind
>>
>>
>> Actually plugging a data syntax in existing language is not a new idea.
>> Though I don't know real success stories.
>>
>
> Thing is, you can do it already now in the script, without modifying the
> Python interpreter, by parsing a triple-quoted string. See the examples
> right here: http://pyyaml.org/wiki/PyYAMLDocumentation
>


Yes. That is exactly what I wanted to discuss actually.
So the feature, which makes it possible in this case  is
triple quote string (TQS).

I think it would be appropriate to propose an alternative
to TQS for this specific purposes. Namely for making it
easier to implement parsers and embedded syntaxes.

So what do I have now with triple quoted strings -
a simple example:

if 1:
s = """\
print ("\n") \\
foo = 5
"""

So there is a _possibility_ in the sense it is possible to do, so
let's say I have a lib with a parser, etc. Though now a developer
and a user will face quite real issues:

- TQS itself has its specific purpose already in many contents,
  which may mean for example hard-coded syntax highlighting
- there a lot of things happening here: e.g. in the above example
  I use "\n" which I assume a part of string, or \\ - but it is interpreted.
  Maybe some other things regarding escaping. This particular
  issue maybe a blocker for making use of TQS in some data cases,
  Say if the target source text need these very characters.

- indentation is the part of TQS. That is of couse by design
  so and it's quite logical, though it is hard-coded behaviour and thus
  does not make the presentation a natural part of blocks containing
  this string.
- appearance: imagine you have some small chunks of embedded
  code parts and you will still have the closing """ everywhere -
  that would be really hairy.


The alternative proposal therefore comes down to a "data block" syntax,
without much assumption about the contents of the block.

This should be simpler to implement, because it should not need a lot
of parsing rules - only some basic options. At the same time it enables
the 'embedding' of user-defined blocks/syntax more naturally
looking than TQS.

My thoughts on possible solution.
-

Problem one: make it look natural inside python source.
Current Python behaviour: very simply speaking, first leading white space
on a line is taken and compared with the one from the next line.
Its Okay for statements, but not okay for raw text data -
because probably I want custom leading whitespaces:

string =
 abc
   abc

(So the TQS takes it simple - grabs it from the line beginning)

So the idea:
- add such a block  to syntax
- *force explicit parameter for the indent charaters.*

Explanation:
[here i'll use same symbol /// for the data entry point, but of course it can
be changed if a better idea comes later. Also for now, just for simplicity -
the rule is that the contents of a block starts always on the new line.

So, e.g. this:

data = /// s4
first line
last line
the rest python code

- will parse the block and knock out leading 4 spaces.
i.e. if the first line has 5 leading spaces then 1 space will be left
in the string. Block parsing terminates when the next line does not
satisfy the indent sequence (4 spaces in this case).
Another obvious type: tabs:

data = /// t1
first line
last line
the rest python code

Will do the same but with one tabstop character.

Actually that's it!
Some further ideas:

data = /// ts
- "any whitespace" (mimic current Python behaviour)

data = /// s# or
data = /// t
- simply count amount of spaces (tabs) from first
  line and proceed, otherwise terminate.

data = /// "???"
??? abc foo bar
???

- defines indent character by string: crazy idea but why not.

Language  parameter, e.g.:
data = /// t1."yaml"

-this can be reserved for future usage by code analysis tools
or dynamic syntax highlighting.

That's just a rough specification.

What should it give as result:

1. No clash with current TQS rules - less worries
  about reserved characters.

2. Built-in indentation parsing parameter makes it more or
  less natural continuation of Python blocks and is char-precise,
  which is very important here.

3. Independent of the indent of containing block!

4. Parameter descriptor can be developed in such manner
   that it allows more customisation and additions in the future.


Does seem to be more generalized problem-solving here.

One problem, as usual - tabs may be implicitly converted
to spaces by some software. That obviously could brake
something, but so is with any tabs, and its not related to
Python problem.


Is there something I miss here?
What caveats can be with such approach?



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

Re: "Data blocks" syntax specification draft

[Chris Angelico]

On Wed, May 23, 2018 at 3:51 AM, bartc  wrote:
> On 22/05/2018 15:25, Chris Angelico wrote:
>>
>> On Tue, May 22, 2018 at 8:25 PM, bartc  wrote:
>>>
>>> Note that Python tuples don't always need a start symbol:
>>>
>>> a = 10,20,30
>>>
>>> assigns a tuple to a.
>>
>>
>> The tuple has nothing to do with the parentheses, except for the
>> special case of the empty tuple. It's the comma.
>
>
> No? Take these:
>
>  a = (10,20,30)
>  a = [10,20,30]
>  a = {10,20,30}
>
> If you print type(a) after each, only one of them is a tuple - the one with
> the round brackets.

And this isn't a tuple either:

import os, sys, math

If you've actually read the other emails in this thread, you'll see
that this has already been said.

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

Re: "Data blocks" syntax specification draft

[bartc]

On 22/05/2018 15:25, Chris Angelico wrote:

On Tue, May 22, 2018 at 8:25 PM, bartc  wrote:

Note that Python tuples don't always need a start symbol:

a = 10,20,30

assigns a tuple to a.


The tuple has nothing to do with the parentheses, except for the
special case of the empty tuple. It's the comma.


No? Take these:

 a = (10,20,30)
 a = [10,20,30]
 a = {10,20,30}

If you print type(a) after each, only one of them is a tuple - the one 
with the round brackets.


The 10,20,30 in those other contexts doesn't create a tuple, nor does it 
here:


  f(10,20,30)

Or here:

  def g(a,b,c):

Or here in Python 2:

  print 10,20,30

and no doubt in a few other cases. It's just that special case I 
highlighted where an unbracketed sequence of expressions yields a tuple.


The comma is just generally used to separate expressions, it's not 
specific to tuples.


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

Re: "Data blocks" syntax specification draft

[Chris Angelico]

On Wed, May 23, 2018 at 1:43 AM, Ian Kelly  wrote:
> On Tue, May 22, 2018 at 9:34 AM, Chris Angelico  wrote:
>> On Wed, May 23, 2018 at 1:22 AM, Ian Kelly  wrote:
>>> On Tue, May 22, 2018 at 8:25 AM, Chris Angelico  wrote:
 On Tue, May 22, 2018 at 8:25 PM, bartc  wrote:
> Note that Python tuples don't always need a start symbol:
>
>a = 10,20,30
>
> assigns a tuple to a.

 The tuple has nothing to do with the parentheses, except for the
 special case of the empty tuple. It's the comma.
>>>
>>> Although, if the rule were really as simple as "commas make tuples",
>>> then this would be a list containing a tuple: [1, 2, 3].
>>
>> In an arbitrary expression, a comma between two expressions creates a
>> tuple. In other contexts, the comma has other meanings, which take
>> precedence:
>>
>> * Separating a function's arguments (both at definition and call)
>> * Enumerating import targets and global/nonlocal names
>> * Separating an assertion from its message
>> * Listing multiple context managers
>> * And probably some that I've forgotten.
>>
>> In those contexts, you can override the normal interpretation and
>> force the tuple by using parentheses, preventing it from being parsed
>> as something else, and making it instead a single expression:
>>
>> print((1, 2)) # prints a tuple
>> print(1, 2) # prints two items
>>
>> The comma is what makes the tuple, though, not the parentheses. The
>> parentheses merely prevent this from being something else.
>
> In other words, the rule is not really as simple as "commas make
> tuples". I stand by what I wrote.

Neither of us is wrong here. "Commas make tuples" is a useful
oversimplification in the same way that "asterisk means
multiplication" is. The asterisk has other meanings in specific
contexts (eg unpacking), but outside of those contexts, it means
multiplication.

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

Re: "Data blocks" syntax specification draft

[Ian Kelly]

On Tue, May 22, 2018 at 9:34 AM, Chris Angelico  wrote:
> On Wed, May 23, 2018 at 1:22 AM, Ian Kelly  wrote:
>> On Tue, May 22, 2018 at 8:25 AM, Chris Angelico  wrote:
>>> On Tue, May 22, 2018 at 8:25 PM, bartc  wrote:
 Note that Python tuples don't always need a start symbol:

a = 10,20,30

 assigns a tuple to a.
>>>
>>> The tuple has nothing to do with the parentheses, except for the
>>> special case of the empty tuple. It's the comma.
>>
>> Although, if the rule were really as simple as "commas make tuples",
>> then this would be a list containing a tuple: [1, 2, 3].
>
> In an arbitrary expression, a comma between two expressions creates a
> tuple. In other contexts, the comma has other meanings, which take
> precedence:
>
> * Separating a function's arguments (both at definition and call)
> * Enumerating import targets and global/nonlocal names
> * Separating an assertion from its message
> * Listing multiple context managers
> * And probably some that I've forgotten.
>
> In those contexts, you can override the normal interpretation and
> force the tuple by using parentheses, preventing it from being parsed
> as something else, and making it instead a single expression:
>
> print((1, 2)) # prints a tuple
> print(1, 2) # prints two items
>
> The comma is what makes the tuple, though, not the parentheses. The
> parentheses merely prevent this from being something else.

In other words, the rule is not really as simple as "commas make
tuples". I stand by what I wrote.

>> Curiously, parentheses are also sometimes required for iterable
>> unpacking. For example:
>>
>> py> 1, 2, *range(3,5)
>> (1, 2, 3, 4)
>> py> d = {}
>> py> d[1, 2] = 42
>> py> d[1, 2, *range(3,5)] = 43
>>   File "", line 1
>> d[1, 2, *range(3,5)] = 43
>> ^
>> SyntaxError: invalid syntax
>
> I'm not sure what you mean about the parentheses here. AIUI iterable
> unpacking simply isn't supported inside subscripting. If that's an
> actual problem anywhere, I'm sure it could be added :)

Of course it's supported:

py> d = {}
py> d[(1, 2, *range(3, 5))] = 43
py> d
{(1, 2, 3, 4): 43}

Works just fine. But take out the parentheses and you get the SyntaxError.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[Chris Angelico]

On Wed, May 23, 2018 at 1:22 AM, Ian Kelly  wrote:
> On Tue, May 22, 2018 at 8:25 AM, Chris Angelico  wrote:
>> On Tue, May 22, 2018 at 8:25 PM, bartc  wrote:
>>> Note that Python tuples don't always need a start symbol:
>>>
>>>a = 10,20,30
>>>
>>> assigns a tuple to a.
>>
>> The tuple has nothing to do with the parentheses, except for the
>> special case of the empty tuple. It's the comma.
>
> Although, if the rule were really as simple as "commas make tuples",
> then this would be a list containing a tuple: [1, 2, 3].

In an arbitrary expression, a comma between two expressions creates a
tuple. In other contexts, the comma has other meanings, which take
precedence:

* Separating a function's arguments (both at definition and call)
* Enumerating import targets and global/nonlocal names
* Separating an assertion from its message
* Listing multiple context managers
* And probably some that I've forgotten.

In those contexts, you can override the normal interpretation and
force the tuple by using parentheses, preventing it from being parsed
as something else, and making it instead a single expression:

print((1, 2)) # prints a tuple
print(1, 2) # prints two items

The comma is what makes the tuple, though, not the parentheses. The
parentheses merely prevent this from being something else.

> Curiously, parentheses are also sometimes required for iterable
> unpacking. For example:
>
> py> 1, 2, *range(3,5)
> (1, 2, 3, 4)
> py> d = {}
> py> d[1, 2] = 42
> py> d[1, 2, *range(3,5)] = 43
>   File "", line 1
> d[1, 2, *range(3,5)] = 43
> ^
> SyntaxError: invalid syntax

I'm not sure what you mean about the parentheses here. AIUI iterable
unpacking simply isn't supported inside subscripting. If that's an
actual problem anywhere, I'm sure it could be added :)

> py> def foo():
> ...   return 1, 2
> ...
> py> foo()
> (1, 2)
>
> py> def foo():
> ...   return 1, 2, *range(3, 5)
>   File "", line 2
> return 1, 2, *range(3, 5)
>  ^
> SyntaxError: invalid syntax

That's a slightly curious case, since it's definitely being parsed the
same way. PEP 448 gives precedence for adding this sort of thing, if
anyone feels like digging into it. You may find that there's some
ambiguity somewhere in the unparenthesized version.

> py> def foo():
> ...   yield 1, 2
> ...
> py> list(foo())
> [(1, 2)]
> py> def foo():
> ...   yield 1, 2, *range(3, 5)
>   File "", line 2
> yield 1, 2, *range(3, 5)
> ^
> SyntaxError: invalid syntax

That's the exact same thing as the 'return' example, so it'll behave
the same way.

> py> for x in 1, 2: print(x)
> ...
> 1
> 2
> py> for x in 1, 2, *range(3, 5): print(x)
>   File "", line 1
> for x in 1, 2, *range(3, 5): print(x)
>^
> SyntaxError: invalid syntax

In fact, I think probably all four of your examples would behave the
same way. So if you want to push for the change, go for it :)

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

Re: "Data blocks" syntax specification draft

[Ian Kelly]

On Tue, May 22, 2018 at 9:22 AM, Ian Kelly  wrote:
> On Tue, May 22, 2018 at 8:25 AM, Chris Angelico  wrote:
>> On Tue, May 22, 2018 at 8:25 PM, bartc  wrote:
>>> Note that Python tuples don't always need a start symbol:
>>>
>>>a = 10,20,30
>>>
>>> assigns a tuple to a.
>>
>> The tuple has nothing to do with the parentheses, except for the
>> special case of the empty tuple. It's the comma.
>
> Although, if the rule were really as simple as "commas make tuples",
> then this would be a list containing a tuple: [1, 2, 3].
>
> Curiously, parentheses are also sometimes required for iterable
> unpacking. For example:

[SNIP]

> py> def foo():
> ...   yield 1, 2
> ...
> py> list(foo())
> [(1, 2)]
> py> def foo():
> ...   yield 1, 2, *range(3, 5)
>   File "", line 2
> yield 1, 2, *range(3, 5)
> ^
> SyntaxError: invalid syntax

Here's another case where parentheses are always required:

py> def foo():
...   yield from 1, 2
  File "", line 2
yield from 1, 2
^
SyntaxError: invalid syntax

This one might be explained by noting that "yield from" is actually an
expression and so it could be confusing as to whether this should be
equivalent to "yield from (1, 2)" or "(yield from 1), 2". But "yield"
has the same issue and does allow an unparenthesized tuple.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[Ian Kelly]

On Tue, May 22, 2018 at 8:25 AM, Chris Angelico  wrote:
> On Tue, May 22, 2018 at 8:25 PM, bartc  wrote:
>> Note that Python tuples don't always need a start symbol:
>>
>>a = 10,20,30
>>
>> assigns a tuple to a.
>
> The tuple has nothing to do with the parentheses, except for the
> special case of the empty tuple. It's the comma.

Although, if the rule were really as simple as "commas make tuples",
then this would be a list containing a tuple: [1, 2, 3].

Curiously, parentheses are also sometimes required for iterable
unpacking. For example:

py> 1, 2, *range(3,5)
(1, 2, 3, 4)
py> d = {}
py> d[1, 2] = 42
py> d[1, 2, *range(3,5)] = 43
  File "", line 1
d[1, 2, *range(3,5)] = 43
^
SyntaxError: invalid syntax

py> def foo():
...   return 1, 2
...
py> foo()
(1, 2)

py> def foo():
...   return 1, 2, *range(3, 5)
  File "", line 2
return 1, 2, *range(3, 5)
 ^
SyntaxError: invalid syntax

py> def foo():
...   yield 1, 2
...
py> list(foo())
[(1, 2)]
py> def foo():
...   yield 1, 2, *range(3, 5)
  File "", line 2
yield 1, 2, *range(3, 5)
^
SyntaxError: invalid syntax

py> for x in 1, 2: print(x)
...
1
2
py> for x in 1, 2, *range(3, 5): print(x)
  File "", line 1
for x in 1, 2, *range(3, 5): print(x)
   ^
SyntaxError: invalid syntax
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[Chris Angelico]

On Tue, May 22, 2018 at 8:25 PM, bartc  wrote:
> Note that Python tuples don't always need a start symbol:
>
>a = 10,20,30
>
> assigns a tuple to a.

The tuple has nothing to do with the parentheses, except for the
special case of the empty tuple. It's the comma.

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

Re: "Data blocks" syntax specification draft

[bartc]

On 22/05/2018 03:49, Mikhail V wrote:

On Mon, May 21, 2018 at 3:48 PM, bartc  wrote:



But I have to say it looks pretty terrible, and I can't see that it buys
much over normal syntax.




# t
# t
   11  22  33



Is this example complete? Presumably it means ((11,22,33),).


You get the point?
So basically all nice chars are already occupied.


You mean for introducing tuple, list and dict literals? Python already 
uses (, [ and { for those, with the advantage of having a closing ), ] 
and } to make it easier to see where each ends.


The only advantage of your proposal is that it resembles Python block 
syntax a little more, but I don't know if it follows the same rules of 
indentation and for inlining content.



Proposing Unicode symbols -- that will probably will be
dead on arrival (just remembering some of such past proposals).
Leaving out symbols could be an option as well.
Still the structure needs a syntactical entry point.


Note that Python tuples don't always need a start symbol:

   a = 10,20,30

assigns a tuple to a.


E.g.

data = ///
t
t
   11  22  33

Hmm. not bad. But I must think about parsing as well.


Have you tried writing a parser for this? It can be stand-alone, not a 
full parser for Python code. That could help reveal any problems.


But think about when t could be the name of a variable, and you want to 
construct the tuple (t,t,t):


 ///t t t t

That already looks a little odd. And when the /// is omitted:

 t t t t

Is that one tuple of (t,t,t), or a tuple of (t,(t))?


Also, is ///t ///t ///t a b c allowed, or does it have to be split 
across lines? If it is allowed, then it's not clear to which tuple b and 
c belong to, or even a, if an empty tuple is allowed.


I think this syntax is ambiguous; you need a more rigorous 
specification. (How will it parse ///.3 4 5 for example?)



So I can change types of all child nodes with one keystroke.


Suppose you only wanted to change the top one?





The ///d dictionary example is ambiguous: can you have more than one
key:value per line or not? If so, it would look like this:

   ///d "a" "b" "c" "d" "e" "f"


///d   "a" "b""c" "d""e" "f"

Now better? :-)


Not really. Suppose one got accidentally missed out, and there was some 
spurious name at the end, so that you had this (dispensing with quotes, 
these are variables):


   ///d a b c e f x

The pairing is a:b, c:e, f:x rather the a:b, c:d, e:f that was intended 
with the x being an error. Use of : and , add useful redundancy. It's 
not clear whether:


  ///d a b
c e
f x

is allowed (I don't know what the terminating conditions are), but in a 
very long dict literal, it's easy to get confused.



I think this is an interesting first draft of an idea, but it doesn't 
seem rigorous. And people don't like that triple stroke prefix, or those 
single letter codes (why not just use 'tuple', 'list', 'dict')?


For example, here is a proposal I've just made up for a similar idea, 
but to make such constructors obey similar rules to Python blocks:


 tuple:
 10
 20
 30

 list:
 list:
 10
 tuple: 5,6,7
 30
 "forty"
 "fifty"

So, the keyword prefixes are followed by ":"; entities can follow on the 
same line, but using "," rather than ";", and the end of a sequence is 
just like the end of a 'suite'.


But even here there is ambiguity: the '5,6,7' forms a tuple of its own 
in normal syntax, so these could be a tuple of one tuple of 3, rather 
than a tuple of 3. (I may need ";" here rather than ,")


--
bartc

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

Re: "Data blocks" syntax specification draft

[Christian Gollwitzer]

Am 22.05.18 um 04:17 schrieb Mikhail V:

On Mon, May 21, 2018 at 1:41 PM, Chris Lindsay via Python-list
 wrote:


If a block of static data is large enough to start to be ugly, a common
approach is to load the data from some other file, in a language which is
designed around structured data.



Maybe it is common in industrial applications but not in smaller production,
and according to my observation not common at all in all occasional scripts.


YAML comes to mind


Actually plugging a data syntax in existing language is not a new idea.
Though I don't know real success stories.



Thing is, you can do it already now in the script, without modifying the 
Python interpreter, by parsing a triple-quoted string. See the examples 
right here: http://pyyaml.org/wiki/PyYAMLDocumentation


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

Re: "Data blocks" syntax specification draft

[Joe Pfeiffer]

Mikhail V  writes:

> On Mon, May 21, 2018 at 1:41 PM, Chris Lindsay via Python-list
>  wrote:
>
>> If a block of static data is large enough to start to be ugly, a common
>> approach is to load the data from some other file, in a language which is
>> designed around structured data.
>
>
> Maybe it is common in industrial applications but not in smaller production,
> and according to my observation not common at all in all occasional scripts.

It is absolutely standard in all applications that have a configuration
file.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[Mikhail V]

On Mon, May 21, 2018 at 3:48 PM, bartc  wrote:

>
> This is intended to be used inside actual Python programs?
>
> In that case code is normally displayed in fixed pitch, as it would normally
> be viewed in a code editor, even if part of a document.
>
> But I have to say it looks pretty terrible, and I can't see that it buys
> much over normal syntax.

Ha, here we go. Last time I have used fixed pitch font for work -
maybe 4 years ago.
(and IMO fixed pitch font plus specifically Python - I find quite a blasphemy)

So, you re right, of course in one sense: "///" looks terrible with
a fixed pitch font! That's so true, but also it is true that this ///
I well maybe change for something less font-sensitive.
And in all fonts other than fixed pitch it looks cute enough.

Simply speaking, if it was not for Python, I might propose something
like:

# t
   # t
  11  22  33

You get the point?
So basically all nice chars are already occupied.
Proposing Unicode symbols -- that will probably will be
dead on arrival (just remembering some of such past proposals).
Leaving out symbols could be an option as well.
Still the structure needs a syntactical entry point.
E.g.

data = ///
t
   t
  11  22  33

Hmm. not bad. But I must think about parsing as well.


> It's not clear what ///. is for, or why it's necessary (presumably you have
> to use ///. /// instead of /// ///).

"///."  is meant to inherit the previous (parent) type:

/// t
   /// .
  /// .

is same as

/// t
   /// t
  /// t

So I can change types of all child nodes with one keystroke.


>
> The ///d dictionary example is ambiguous: can you have more than one
> key:value per line or not? If so, it would look like this:
>
>   ///d "a" "b" "c" "d" "e" "f"

///d   "a" "b""c" "d""e" "f"

Now better? :-)

Or compare these two:

{"a": "b", "c": "d", "e": "f"}

///d   "a" "b""c" "d""e" "f"

I'd say, the second one is much better.


> Or do you also allow: date = ///  with data following on the next line?

Yes, all this should be legal:

data = /// t
   11 22 33

data =\
/// t
   11 22 33

data = /// t  11 22 33


But this probly not good:

data = /// t  11 22 33  /// t  44  55

Because it will not be clear for the reader how further suite termination
happens.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[Ben Finney]

Ned Batchelder  writes:

> You've proposed it and asked for feedback, but you seem to be
> completely ignoring the feedback people are giving you.

Another problem with the proposal: The motivation to introduce such a
large change is not compelling. What is the problem this proposal aims
to solve? Why solve it with such a large amount of fundamental change,
when (as discussed in this thread) there are apparently many existing
solutions that work well?

If there's a problem that existing solutions are not addressing well,
the proposal needs to do the work of explicitly stating the problem and
its constraints, demonstrating an understanding of those existing
solutions and how they are inadequate to the explicitly described
problem.

-- 
 \ “If you can do no good, at least do no harm.” —_Slapstick_, |
  `\ Kurt Vonnegut |
_o__)  |
Ben Finney

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

Re: "Data blocks" syntax specification draft

[Ned Batchelder]

On 5/21/18 9:42 PM, Mikhail V wrote:

On Mon, May 21, 2018 at 2:14 PM, Ned Batchelder  wrote:

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.

In what sense? I don't propose to add braces to Python or anything like that.



In the sense that no one likes it.  I don't mean to be blunt, but it 
doesn't look or act like Python, and it replaces existing structures 
with things that are completely different.


You've proposed it and asked for feedback, but you seem to be completely 
ignoring the feedback people are giving you.


It's not going to be added to Python. Write it as a third-party library.

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

Re: "Data blocks" syntax specification draft

[Mikhail V]

On Mon, May 21, 2018 at 1:41 PM, Chris Lindsay via Python-list
 wrote:

> If a block of static data is large enough to start to be ugly, a common
> approach is to load the data from some other file, in a language which is
> designed around structured data.


Maybe it is common in industrial applications but not in smaller production,
and according to my observation not common at all in all occasional scripts.

>YAML comes to mind

Actually plugging a data syntax in existing language is not a new idea.
Though I don't know real success stories.

> What use-case do you foresee for your proposed new format, that isn't
> already (better) accomplished by using a separate structured
> data/serialisation language?

Well everything described in the doc is quite common. So simply put,
for all data beyond trivial inline [1,2,3].

If your idea is to use external data for all scenarios - then there are
many questions - which toolchains, file organisation, distribution etc.
One common approach is an TSV/ CSV editor plus a quick dirty
self-defined parser.
One criteria for a syntax - how simple to edit it in normal text editor
and how other existing data editors can do it.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[Mikhail V]

On Mon, May 21, 2018 at 2:14 PM, Ned Batchelder  wrote:
> 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.

In what sense? I don't propose to add braces to Python or anything like that.

> Your proposal seems to have almost nothing in common
> with existing Python syntax.

Well, if  speak of adding any embedded data syntax at all - how do you think:
should the embedded syntax copy everything? Even if it will look worse
in the end?
Frankly, I don't think so.
If you ask me:  may it be totally different syntax than Python?
I'd say - no, but it should be something compromising.

What other criteria is there?
Main benefits i see in Python syntax: indentation-based,
no termination tokens, new-line statement separation. Overall tendency
to prioritize readability
(e.g. over parse-ability). All these points i try to oblige.
Actually if think deeper of it - these points are not even something "Pythonic"
but merely just common sense and some basic readability principles.

> Your approach to whitespace is different.
> You've ignored existing words (tuple, str) in favor of new shorthands (t,s).

Yes. Turns out these two things should work better for presentation,
so nothing much unexpectable and nothing personal against existing words ;-).
Type abbreviations deserve more explanation in the doc though.
Simply put - if I write whole words - then type names _will dominate over data_.
E.g.:

/// tuple
   /// tuple
  foo  bar

and even so:

tuple:
   tuple:
  foo  bar

Might it be that the latter is more 'Pythonic'? Maybe yes. But how it
will look on average structure - should be compared.
Again: with proper highlighting this _might_ be an option, but without
highlighting -
sorry, would be just too hard to eyeball the nodes.

Regarding further smaller details - semicolons, asterisks - those are
subject for
further observations and may change.


> Parentheses enclosing strings!?

:-) Ok, here I agree -   the whole 'string type' part - that would be
just too much to
slip through. This would cause inconsistence and add confusion when
placed together with
normal token presentation structs. Although e.g. in a separate file
with a string-only data
it could make the difference.
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: "Data blocks" syntax specification draft

[Dan Strohl via Python-list]

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


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

Re: "Data blocks" syntax specification draft

[Marko Rauhamaa]

Mikhail V :
> How do you do that?! You're truly unsurpassed master of polemics. How
> you turn everything upside down so easily?

If someone's behavior annoys you too much, just put them in your kill
file.

(And no, you don't have to declare it publically.)


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

Re: "Data blocks" syntax specification draft

[Chris Angelico]

On Tue, May 22, 2018 at 4:08 AM, Mikhail V  wrote:
>>> Ok. How is about images? this proposal will require a lot of images
>>> - otherwise people who read it are forced to copy-paste snippets
>>> into their code editors to understand how it may look in reality.
>>
>> If you're proposing syntax for Python, it's ultimately going to have
>> to be text.
>
> All of files that I provided are TEXT. Well maybe PDF is a bit "less text
> than TXT" but still its just text pieces.

Funny, I'm pretty sure I heard you say that your proposal would
require a lot of images. Or are images somehow just a bit less text
than text too?

I'm not interested in a proposal that is hard to read, for a syntax
that is utterly unpythonic, to achieve something that is better done
with a data file format. Bye!

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

Re: "Data blocks" syntax specification draft

[Mikhail V]

On Mon, May 21, 2018 at 7:05 AM, Chris Angelico  wrote:
>>> Forcing us to download a PDF and then read it? Well, it's your
>>> decision. My decision is that I cannot be bothered going to THAT much
>>> effort to figure out what you're saying.
>>
>> THAT much effort to click two times instead of one - and get a
>> formatted document instead of plain bw text. o-kaay..
>
> Two clicks? No, that isn't how it happened for me. I clicked on it and
> then I couldn't see the content.

Sorry I don't know - seems that everyone can see it.

> What second click am I supposed to do
> that shows me the page?

No, no second click is needed. But if you want to download a file -
there is a button "download file". So in a pair of clicks you get
a file on your PC and you can use your favorite viewer to view
PDF, which is IMO more convenient than in a browser.

>> Ok. How is about images? this proposal will require a lot of images
>> - otherwise people who read it are forced to copy-paste snippets
>> into their code editors to understand how it may look in reality.
>
> If you're proposing syntax for Python, it's ultimately going to have
> to be text.

All of files that I provided are TEXT. Well maybe PDF is a bit "less text
than TXT" but still its just text pieces.

> You cannot say "and every text editor has to render it
> like this". If you can't demonstrate it using plain text, you have a
> major problem on your hands.

How do you do that?!  You're truly unsurpassed master of polemics.
How you turn everything upside down so easily? - that is _me_ who tells
to make _various_ samples so as to be able to see difference by
various fonts. And it is _you_ who say "everybody look at black and
white sample with a font out of 80' ".
WTF means "If you can't demonstrate it using plain text"?
There is nothing more simple than demonstrate it in plain text.
But it is not enough to judge the syntax since there is
_huge_ difference of fonts, and presence of highlighting makes huge
difference especially for expressions with keywords.

>>> I'm not going to read your proposal if you force me to go to heaps of
>>> effort for it.
>>
>> heaps! oh come on, youre making up again.
>
> No, I'm not making it up. Just because the PDF works perfectly for
> you, you assume that it'll work perfectly for everyone.

Look, PDF is one of the most widely used document exchange formats.
And you know it. I personally  don't need the PDF either - creating it
just adds me
work. And I am not debating anything about it, just made it for convenience
since someone maybe prefer it.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[bartc]

On 20/05/2018 03:58, 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.


This is intended to be used inside actual Python programs?

In that case code is normally displayed in fixed pitch, as it would 
normally be viewed in a code editor, even if part of a document.


But I have to say it looks pretty terrible, and I can't see that it buys 
much over normal syntax.


The use of the funny /// symbol, and reserving identifiers t, L and d 
when following ///, is also a little naff.


(Note that lines starting // are interpreted as comment lines in C and 
C++ languages, and may be used by others too. Those used to see those as 
comments may get confused.)


It's not clear what ///. is for, or why it's necessary (presumably you 
have to use ///. /// instead of /// ///).


The ///d dictionary example is ambiguous: can you have more than one 
key:value per line or not? If so, it would look like this:


  ///d "a "b "c" "d" "e" "f"

so that the pairing is not clear.

You also seem to have more need of the "\" line continuation character 
in your syntax, because Python can do this:


   data = {

but you need:

   date = \
   ///

Or do you also allow: date = ///  with data following on the next line?


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

Re: "Data blocks" syntax specification draft

[bartc]

On 21/05/2018 05:05, Chris Angelico wrote:

On Mon, May 21, 2018 at 2:00 PM, Mikhail V  wrote:



heaps! oh come on, youre making up again.


No, I'm not making it up. Just because the PDF works perfectly for
you, you assume that it'll work perfectly for everyone. That is not
the case, and that isn't my problem - it's your problem.


Perhaps the problem could well be at your end.

I don't remember having much trouble viewing PDFs, it's just a bit of a 
pain to do so (and I prefer to read them properly downloaded via the 
Adobe reader so that I can scroll in page mode, some extra steps).


I've just viewed a PDF on an old, low-spec Linux machine and it seemed 
fine, so it's not a Windows thing. (Can't access the OP's link for 
reasons unconnected with PDF.)


PDF seems to be universally used for all sorts of things (I used to have 
to print boarding passes via PDF; I doubt airlines wanted to alienate 
Linux users).


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

Re: "Data blocks" syntax specification draft

[Ned Batchelder]

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.


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

Re: "Data blocks" syntax specification draft

[Chris Lindsay via Python-list]

So this is a syntax for defining large blocks of static data in-line with
code.

If a block of static data is large enough to start to be ugly, a common
approach is to load the data from some other file, in a language which is
designed around structured data. YAML comes to mind - it has minimal
punctuation, and whitespace as syntax, with little in the way of syntax
ambiguity since it isn't already a scripting language.

What use-case do you foresee for your proposed new format, that isn't
already (better) accomplished by using a separate structured
data/serialisation language?

On 21 May 2018 at 10:21, Steven D'Aprano <
steve+comp.lang.pyt...@pearwood.info> wrote:

> On Mon, 21 May 2018 01:28:51 +0300, Mikhail V wrote:
>
> > Source examples on
> > Github will force a crappy font and replace tabs.
>
>
> Is that supposed to convince us that using mandatory TABs is a good idea?
>
>
> --
> Steve
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>



-- 
Chris
Open Cosmos

Any opinions given above are my own.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[Steven D'Aprano]

On Mon, 21 May 2018 01:28:51 +0300, Mikhail V wrote:

> Source examples on
> Github will force a crappy font and replace tabs.


Is that supposed to convince us that using mandatory TABs is a good idea?


-- 
Steve

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

Re: "Data blocks" syntax specification draft

[m]

W dniu 21.05.2018 o 06:00, Mikhail V pisze:
>> As Ian says, reStructuredText is the only supported format [1] for
>> PEPs, so you may as well just start using it straight away. GitHub
>> automatically renders it if you use a ".rst" extension on your file,
>> so the rendered form would be visible on the web.
> Ok. How is about images? this proposal will require a lot of images
> - otherwise people who read it are forced to copy-paste snippets
> into their code editors to understand how it may look in reality.
> 

I would say, that if proposition of your syntax requires images, then
it's bad syntax.

And re PDF - i opened that pdf with one click - hopefully I have
configured my thunderbird to that. And what do I see? Completely
unreadable code, because you used bizzare, non monospaced,  font to code
examples.

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

Re: "Data blocks" syntax specification draft

[Mikhail V]

On Mon, May 21, 2018 at 5:20 AM, Chris Angelico  wrote:
> On Mon, May 21, 2018 at 8:28 AM, Mikhail V  wrote:
>>> >
>>> > Comments, suggestions are welcome.
>>> >
>>>
>>> One comment.
>>>
>>> I'm not interested in downloading a PDF. Can you rework your document
>>> to be in a more textual format like Markdown or reStructuredText?
>>> Since you're hosting on GitHub anyway, the rendering can be done
>>> automatically.
>>>
>>> ChrisA
>>
>>
>> What against PDF?
>> Anyway, I have reloaded files with most recent corrections in various 
>> formats:
>
> The very best way to put your proposal is right here in the body of
> the email, as plain Unicode (and primarily ASCII) text, no images, no
> external links, no side dependencies.

Well that's the easiest way for me, but - if the document changes constantly
then it is more convenient to have a web link for a document.

> The second best way is to have a simple link that anyone can click on
> to read your proposal. It's an external dependency, but you're
> depending on a web browser and a basic internet connection, and
> nothing more.
>
> Forcing us to download a PDF and then read it? Well, it's your
> decision. My decision is that I cannot be bothered going to THAT much
> effort to figure out what you're saying.

THAT much effort to click two times instead of one - and get a
formatted document instead of plain bw text. o-kaay..

> The PDF link you give is not viewable on the web

Dunno, works for me - I click it and see immediately my PDF in
the browser. But I (and many people) prefer to download anyway.
Also I provided a link to HTML - also works per click and looks even
better than PDF.

> As Ian says, reStructuredText is the only supported format [1] for
> PEPs, so you may as well just start using it straight away. GitHub
> automatically renders it if you use a ".rst" extension on your file,
> so the rendered form would be visible on the web.

Ok. How is about images? this proposal will require a lot of images
- otherwise people who read it are forced to copy-paste snippets
into their code editors to understand how it may look in reality.

> I'm not going to read your proposal if you force me to go to heaps of
> effort for it.

heaps! oh come on, youre making up again.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[Chris Angelico]

On Mon, May 21, 2018 at 2:00 PM, Mikhail V  wrote:
>> The second best way is to have a simple link that anyone can click on
>> to read your proposal. It's an external dependency, but you're
>> depending on a web browser and a basic internet connection, and
>> nothing more.
>>
>> Forcing us to download a PDF and then read it? Well, it's your
>> decision. My decision is that I cannot be bothered going to THAT much
>> effort to figure out what you're saying.
>
> THAT much effort to click two times instead of one - and get a
> formatted document instead of plain bw text. o-kaay..

Two clicks? No, that isn't how it happened for me. I clicked on it and
then I couldn't see the content. What second click am I supposed to do
that shows me the page?

>> As Ian says, reStructuredText is the only supported format [1] for
>> PEPs, so you may as well just start using it straight away. GitHub
>> automatically renders it if you use a ".rst" extension on your file,
>> so the rendered form would be visible on the web.
>
> Ok. How is about images? this proposal will require a lot of images
> - otherwise people who read it are forced to copy-paste snippets
> into their code editors to understand how it may look in reality.

If you're proposing syntax for Python, it's ultimately going to have
to be text. You cannot say "and every text editor has to render it
like this". If you can't demonstrate it using plain text, you have a
major problem on your hands.

>> I'm not going to read your proposal if you force me to go to heaps of
>> effort for it.
>
> heaps! oh come on, youre making up again.

No, I'm not making it up. Just because the PDF works perfectly for
you, you assume that it'll work perfectly for everyone. That is not
the case, and that isn't my problem - it's your problem.

Suppose someone posted a Microsoft Word document, claiming that
Internet Explorer will display it perfectly. Would you accept that,
and say that we should all switch to IE? Would you moan that it's so
easy, and we're just complainers for not wanting to play your games?
Or would we just drop the thread and ignore you thereafter?

I'm not going to debate this with you. If you want people to read your
content, you need to make it accessible; it's much easier for me to
just assume that a proposal that requires a PDF and a bunch of images
simply isn't worth reading.

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

Re: "Data blocks" syntax specification draft

[Mikhail V]

On Mon, May 21, 2018 at 3:02 AM, Ian Kelly  wrote:
> On Sun, May 20, 2018 at 4:28 PM, Mikhail V  wrote:
>> "Markdown" is too vague - there dozens of markdown styles and
>> also they include subsets of HTML. It is just plain text with tags
>
> The whole point of Markdown is that it's readable as plain text
> precisely because it *doesn't* use obvious tags like HTML.
>
>> it cannot represent syntax in civilized form (unless I embed images
>> for every source example - but then it is too inconvenient for editing).
>
> Why would you need images to represent syntax? What's wrong with code blocks?

Code blocks where? In what software/webkit it is supposed to be
rendered?
How do you imagine a serious proposal with such syntax comparisons
without ability to make more or less precise presentation in various
fonts?
To speak about significant syntax change seriously you need many samples
in at least 2-3 modern quality fonts. Modulo a pair of reasonable color schemes.
Modern editors (and users) are far beyond type-writer fonts.

>> I suggest you just view HTML or PDF - it looks better and if you need
>> source - just download TXT - it has tabs preserved at least.
>
> You know, if you're serious about this proposal, then eventually you
> will have to write a PEP for it. And that PEP has a required style and
> format. And that format is reStructuredText.

Making reStructuredText is not a problem, but as said - it is not
serious to speak of syntax without good samples. IOW besides a
Markdown PEP such proposal requires a lot of supplementary material.
The best method is to create images of code snippets in addition to
text. Main advantage of images that it will be independent of browser/OS
but it requires some extra job.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[Chris Angelico]

On Mon, May 21, 2018 at 8:28 AM, Mikhail V  wrote:
>> >
>> > Comments, suggestions are welcome.
>> >
>>
>> One comment.
>>
>> I'm not interested in downloading a PDF. Can you rework your document
>> to be in a more textual format like Markdown or reStructuredText?
>> Since you're hosting on GitHub anyway, the rendering can be done
>> automatically.
>>
>> ChrisA
>
>
> What against PDF?
> Anyway, I have reloaded files with most recent corrections in various formats:

The very best way to put your proposal is right here in the body of
the email, as plain Unicode (and primarily ASCII) text, no images, no
external links, no side dependencies.

The second best way is to have a simple link that anyone can click on
to read your proposal. It's an external dependency, but you're
depending on a web browser and a basic internet connection, and
nothing more.

Forcing us to download a PDF and then read it? Well, it's your
decision. My decision is that I cannot be bothered going to THAT much
effort to figure out what you're saying. The PDF link you give is not
viewable on the web, and the text file looks like source code for your
PDF, but isn't very readable either.

As Ian says, reStructuredText is the only supported format [1] for
PEPs, so you may as well just start using it straight away. GitHub
automatically renders it if you use a ".rst" extension on your file,
so the rendered form would be visible on the web. Consider:

https://github.com/python/peps/blob/master/pep-0562.rst

I'm not going to read your proposal if you force me to go to heaps of
effort for it. The onus is on YOU to gather support, not on everyone
else to refute it, so it's up to you to publish it accessibly.

ChrisA

[1] Technically plain text is also supported, but not for new PEPs.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[Ian Kelly]

On Sun, May 20, 2018 at 4:28 PM, Mikhail V  wrote:
> "Markdown" is too vague - there dozens of markdown styles and
> also they include subsets of HTML. It is just plain text with tags

The whole point of Markdown is that it's readable as plain text
precisely because it *doesn't* use obvious tags like HTML.

> it cannot represent syntax in civilized form (unless I embed images
> for every source example - but then it is too inconvenient for editing).

Why would you need images to represent syntax? What's wrong with code blocks?

> Source examples on Github will force a crappy font and replace tabs.

Has it occurred to you that this will also be a problem for anybody
else trying to create examples using this syntax on Github?

> I suggest you just view HTML or PDF - it looks better and if you need
> source - just download TXT - it has tabs preserved at least.

You know, if you're serious about this proposal, then eventually you
will have to write a PEP for it. And that PEP has a required style and
format. And that format is reStructuredText.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[Chris Angelico]

On Sun, May 20, 2018 at 12: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.
>

One comment.

I'm not interested in downloading a PDF. Can you rework your document
to be in a more textual format like Markdown or reStructuredText?
Since you're hosting on GitHub anyway, the rendering can be done
automatically.

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