Indented multi-line strings

[Mikhail V]

On Wed, May 23, 2018 at 4:19 PM, Dan Strohl <D.Strohl at f5.com> wrote:
> 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".

I think we might have a misunderstanding here.
I admit I have tendency to use false terms sometimes -
in this case I did not mean "hard-coded", but rather with
parameter which is taken by the parser.

Namely the proposal is to use 'de-dention' parameter in
such form:

data = /// sN         # and
data = /// tN

Where N - is the amount of characters, spaces (s) or
tabs (t).
This should cover most use cases.
It implies of course that the user should know himself
what he is doing.

More concrete example:

def func():
    foobar
    data = /// s2
      first line
      last line
    foobar

will store same data as:
data = "first linelast line"

(assuming of course no trailing spaces were
in original lines)

So obviously the minimal amount in a parameter is 1,
otherwise it will not work at all.

That's actually it. I am inclining to opinion that no
further parameters are necessary, but of course
there might be few other common use case.
IOW it would be not correct to totally disregard
considering some additional options.



>> # lang "yaml"
>> data = /// t
>>     first line
>>     last line
>> rest
>
> Again, you're complicating the thought without really
> [...] primitives should have as few caveats as possible.
> [...] Extra features are fine, but when they start making
> it "more complex" to use, then you should back off.>

I 100% agree with you. In this case it is better to concentrate
on the most 'low-level' behaviour.


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

Well it looks ok, but traditionally it is forbidden to introduce
any new keywords, unless it is absolutely necessary.


M