Re: "Data blocks" syntax specification draft

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

Re: "Data blocks" syntax specification draft

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

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: Attachments? Re: Indented multi-line strings (was: "Data blocks" syntax specification draft)

On 2018-06-02 07:59:07 +1000, Chris Angelico wrote: > On Sat, Jun 2, 2018 at 7:03 AM, Peter J. Holzer wrote: > > On 2018-05-31 14:42:39 -0700, Paul wrote: > >> I have heard that attachments to messages are not allowed on this list, > >> which makes sense. However I notice that messages from Peter

Re: Attachments? Re: Indented multi-line strings (was: "Data blocks" syntax specification draft)

On Sat, Jun 2, 2018 at 7:03 AM, Peter J. Holzer wrote: > On 2018-05-31 14:42:39 -0700, Paul wrote: >> I have heard that attachments to messages are not allowed on this list, >> which makes sense. However I notice that messages from Peter do have an >> attachment, i.e., a signature.asc file. > >

Re: Attachments? Re: Indented multi-line strings (was: "Data blocks" syntax specification draft)

On 2018-05-31 14:42:39 -0700, Paul wrote: > I have heard that attachments to messages are not allowed on this list, > which makes sense. However I notice that messages from Peter do have an > attachment, i.e., a signature.asc file. No this is isn't an attachment. It's a signature. Your MUA

Re: Attachments? Re: Indented multi-line strings (was: "Data blocks" syntax specification draft)

I gave it a different subject line. On Fri, Jun 1, 2018 at 2:45 AM, Abdur-Rahmaan Janhangeer < arj.pyt...@gmail.com> wrote: > as this sig file is a common occurance, attaching the topic to the data > blocks thread is not really necessary > > Abdur-Rahmaan Janhangeer >

Re: Attachments? Re: Indented multi-line strings (was: "Data blocks" syntax specification draft)

as this sig file is a common occurance, attaching the topic to the data blocks thread is not really necessary Abdur-Rahmaan Janhangeer https://github.com/Abdur-rahmaanJ On Fri, 1 Jun 2018, 01:49 Paul, wrote: > I have heard that attachments to messages are not allowed on this list, > which

Attachments? Re: Indented multi-line strings (was: "Data blocks" syntax specification draft)

I have heard that attachments to messages are not allowed on this list, which makes sense. However I notice that messages from Peter do have an attachment, i.e., a signature.asc file. I'm just curious; why and how do those particular attachments get through? And should they get through, I guess?

Re: Indented multi-line strings (was: "Data blocks" syntax specification draft)

On Fri, Jun 1, 2018 at 7:05 AM, Peter J. Holzer wrote: > [Strange: I didn't get this mail through the list, only directly] > > On 2018-05-31 14:39:17 +, Dan Strohl wrote: >> The outdent method could look like: >> >> string.outdent(size=None) >> """ >> :param size : The number of

Re: Indented multi-line strings (was: "Data blocks" syntax specification draft)

On 2018-05-31 23:05:35 +0200, Peter J. Holzer wrote: > [Strange: I didn't get this mail through the list, only directly] Found it. For some reason "Avoid duplicate copies of messages" was enabled. I normally always disable this when I subscribe to a mailinglist and I'm surprised that I haven't

Re: Indented multi-line strings (was: "Data blocks" syntax specification draft)

[Strange: I didn't get this mail through the list, only directly] On 2018-05-31 14:39:17 +, Dan Strohl wrote: > > This is of course not a problem if the *trailing* quote determines the > > indentation: > > > > a_multi_line_string = i''' > >Py- > > thon > >

Re: Indented multi-line strings (was: "Data blocks" syntax specification draft)

On Fri, Jun 1, 2018 at 12:39 AM, Dan Strohl via Python-list wrote: >> This is of course not a problem if the *trailing* quote determines the >> indentation: >> >> a_multi_line_string = i''' >>Py- >> thon >> ''' > > I get the point, but it feels like it would be a

RE: Indented multi-line strings (was: "Data blocks" syntax specification draft)

> This is of course not a problem if the *trailing* quote determines the > indentation: > > a_multi_line_string = i''' >Py- > thon > ''' I get the point, but it feels like it would be a pain to use, and it "Feels" different from the other python indenting,

Re: Indented multi-line strings (was: "Data blocks" syntax specification draft)

On 2018-05-29 07:57:18 -0600, Ian Kelly wrote: > On Tue, May 29, 2018 at 3:19 AM, Peter J. Holzer wrote: > > On 2018-05-23 11:08:48 -0600, Ian Kelly wrote: > >> [...] > > What if I want all lines to start with some white space? [...] > > Fair points. [...] > >> Also, how about using a string

Re: Indented multi-line strings (was: "Data blocks" syntax specification draft)

On Tue, May 29, 2018 at 3:19 AM, Peter J. Holzer wrote: > On 2018-05-23 11:08:48 -0600, Ian Kelly wrote: >> >> How about we instead just use the rules from PEP 257 so that there >> aren't two different sets of multi-line string indentation rules to >> have to remember? >> >>

Re: Indented multi-line strings (was: "Data blocks" syntax specification draft)

On 2018-05-23 11:08:48 -0600, Ian Kelly wrote: > On Wed, May 23, 2018 at 10:25 AM, Peter J. Holzer wrote: > > How about this? > > > > x = > > Here is a multi-line string > > with > > indentation. > > > > > > This would be equivalent to > > > >

Re: "Data blocks" syntax specification draft

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

RE: "Data blocks" syntax specification draft

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

Re: Indented multi-line strings (was: "Data blocks" syntax specification draft)

On Thu, May 24, 2018 at 3:08 AM, Ian Kelly wrote: > I don't know if 'i' would be the right prefix character for this, but > it's unused and is short for 'indented': > > b = i''' > Here is a multi-line string > with indentation, which is > determined from the

RE: Indented multi-line strings (was: "Data blocks" syntax specification draft)

> > How about we instead just use the rules from PEP 257 so that there aren't two > different sets of multi-line string indentation rules to have to remember? > > https://www.python.org/dev/peps/pep-0257/#handling-docstring-indentation > I like that, better to be closer to the existing

Re: Indented multi-line strings (was: "Data blocks" syntax specification draft)

On Wed, May 23, 2018 at 10:25 AM, Peter J. Holzer wrote: > How about this? > > x = > Here is a multi-line string > with > indentation. > > > This would be equivalent to > > x = 'Here is a multi-line string\nwith\n

Re: "Data blocks" syntax specification draft

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

RE: Indented multi-line strings (was: "Data blocks" syntax specification draft)

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

Re: "Data blocks" syntax specification draft

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

Indented multi-line strings (was: "Data blocks" syntax specification draft)

On 2018-05-22 23:25:36 +, Dan Strohl via Python-list wrote: > > 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

Re: "Data blocks" syntax specification draft

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

RE: "Data blocks" syntax specification draft

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

Re: "Data blocks" syntax specification draft

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

Re: "Data blocks" syntax specification draft

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

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

Re: "Data blocks" syntax specification draft

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)

Re: "Data blocks" syntax specification draft

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

Re: "Data blocks" syntax specification draft

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

Re: "Data blocks" syntax specification draft

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

Re: "Data blocks" syntax specification draft

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 =

Re: "Data blocks" syntax specification draft

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,

Re: "Data blocks" syntax specification draft

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

Re: "Data blocks" syntax specification draft

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

Re: "Data blocks" syntax specification draft

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

Re: "Data blocks" syntax specification draft

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

Re: "Data blocks" syntax specification draft

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

Re: "Data blocks" syntax specification draft

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

Re: "Data blocks" syntax specification draft

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

Re: "Data blocks" syntax specification draft

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

RE: "Data blocks" syntax specification draft

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

Re: "Data blocks" syntax specification draft

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

Re: "Data blocks" syntax specification draft

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

Re: "Data blocks" syntax specification draft

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

Re: "Data blocks" syntax specification draft

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

Re: "Data blocks" syntax specification draft

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:

Re: "Data blocks" syntax specification draft

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 =

Re: "Data blocks" syntax specification draft

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 =

Re: "Data blocks" syntax specification draft

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

Re: "Data blocks" syntax specification draft

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

Re: "Data blocks" syntax specification draft

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

Re: "Data blocks" syntax specification draft

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

Re: "Data blocks" syntax specification draft

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

Re: "Data blocks" syntax specification draft

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

Re: "Data blocks" syntax specification draft

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

Re: "Data blocks" syntax specification draft

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.

Re: "Data blocks" syntax specification draft

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

Re: "Data blocks" syntax specification draft

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

RE: "Data blocks" syntax specification draft

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

Re: "Data blocks" syntax specification draft

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

Re: "Data blocks" syntax specification draft

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

Re: "Data blocks" syntax specification draft

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

Re: "Data blocks" syntax specification draft

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

Re: "Data blocks" syntax specification draft

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

Re: "Data blocks" syntax specification draft

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

Re: "Data blocks" syntax specification draft

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

Re: "Data blocks" syntax specification draft

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

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

Re: "Data blocks" syntax specification draft

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

Re: "Data blocks" syntax specification draft

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

Re: "Data blocks" syntax specification draft

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

Re: "Data blocks" syntax specification draft

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

Re: "Data blocks" syntax specification draft

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

"Data blocks" syntax specification draft

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

Re: "Data blocks" syntax specification draft

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 >

"Data blocks" syntax specification draft

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