Re: Indented multi-line strings

[Chris Angelico]

On Mon, Jun 4, 2018 at 11:54 PM, Dan Strohl  wrote:
>> >
>> No-one is saying a method is *worse* than a standalone function - they are
>> just saying it's *not sufficiently better* to justify creating a string 
>> method that
>> replicates an existing stdlib function.
>>
>
> What about performance?  I would expect a string method to perform better 
> than a stdlib function.  (no?)  Especially if it's something that could be 
> used commonly it seems like having that function be of higher performance 
> would be a benefit?
>
> At least for me, when I do use this, it's often in places like logging where 
> it could well be called a lot.
>

Considering that a method on a string literal is a plausible candidate
for constant folding, it most definitely could perform better; it
could perform as well as the string literal itself does.

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

RE: Indented multi-line strings

[Dan Strohl via Python-list]

> > 
> No-one is saying a method is *worse* than a standalone function - they are
> just saying it's *not sufficiently better* to justify creating a string 
> method that
> replicates an existing stdlib function.
> 

What about performance?  I would expect a string method to perform better than 
a stdlib function.  (no?)  Especially if it's something that could be used 
commonly it seems like having that function be of higher performance would be a 
benefit?

At least for me, when I do use this, it's often in places like logging where it 
could well be called a lot.

Dan

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

Re: Indented multi-line strings

[Dan Stromberg]

On Sat, Jun 2, 2018 at 11:43 AM, Chris Angelico  wrote:

> >> 1) Messy code because people unindent inside their source code,
> >> creating wonky indentation (which Python usually avoids)
> >>
> >> 2) Forcing readers to look up the third-party module you're using
> >> before they can understand your code
> >>
> >> 3) Forcing readers to look up your ad-hoc function before
> >> understanding your code.
> >>
> >> All of these make it harder to understand your code, specifically
> >> BECAUSE the language doesn't have the requisite feature. Well-written
> >> language features are good, not bad, for readability.
> >>
> > A well designed language has a small core, and large libraries.
> >
> > Please don't make Python into a big language.
> >
> > Almost anytime you can do something in a library instead of in the core
> > language, it's better to do it in a library.
> >
> > Looking things up in a library isn't onerous.
>
> How small is small, though? And how is a method worse than a library
> function? People keep asserting this about the language needing to be
> smaller, but never backing it up.

It should be small enough to facilitate multiple, compatible
implementations.

It should be small enough that you don't have to learn a lot to start
writing programs.

It should be small enough that you don't have to learn 10 languages to read
someone else's code.

It should not be perl, where anything that seemed a little helpful was
dumped in.

Was Python 1.0 better than Python 3.7 due to having fewer features?

No, generators pretty much rock.  And comprehensions are OK, despite the
obvious duplication with map and filter.  And I like true booleans too.

But there's a reason why so many other implementations of Python are still
stuck on 2.x.  The pace of change in Python, the core language, has just
been too fast.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Indented multi-line strings

[Chris Angelico]

On Sun, Jun 3, 2018 at 2:52 AM, Dan Stromberg  wrote:
>
> On Fri, Jun 1, 2018 at 2:57 PM, Chris Angelico  wrote:
>>
>> If you dislike adding features to a language on the basis that it
>> makes the language harder to learn, remember that you instead force
>> one of three even worse options:
>>
>> 1) Messy code because people unindent inside their source code,
>> creating wonky indentation (which Python usually avoids)
>>
>> 2) Forcing readers to look up the third-party module you're using
>> before they can understand your code
>>
>> 3) Forcing readers to look up your ad-hoc function before
>> understanding your code.
>>
>> All of these make it harder to understand your code, specifically
>> BECAUSE the language doesn't have the requisite feature. Well-written
>> language features are good, not bad, for readability.
>>
> A well designed language has a small core, and large libraries.
>
> Please don't make Python into a big language.
>
> Almost anytime you can do something in a library instead of in the core
> language, it's better to do it in a library.
>
> Looking things up in a library isn't onerous.
>

How small is small, though? And how is a method worse than a library
function? People keep asserting this about the language needing to be
smaller, but never backing it up.

Was Python 1.0 better than Python 3.7 due to having fewer features?

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

Re: Indented multi-line strings

[Dan Stromberg]

On Fri, Jun 1, 2018 at 2:57 PM, Chris Angelico  wrote:

> If you dislike adding features to a language on the basis that it
> makes the language harder to learn, remember that you instead force
> one of three even worse options:
>
> 1) Messy code because people unindent inside their source code,
> creating wonky indentation (which Python usually avoids)
>
> 2) Forcing readers to look up the third-party module you're using
> before they can understand your code
>
> 3) Forcing readers to look up your ad-hoc function before
> understanding your code.
>
> All of these make it harder to understand your code, specifically
> BECAUSE the language doesn't have the requisite feature. Well-written
> language features are good, not bad, for readability.
>
> A well designed language has a small core, and large libraries.

Please don't make Python into a big language.

Almost anytime you can do something in a library instead of in the core
language, it's better to do it in a library.

Looking things up in a library isn't onerous.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Indented multi-line strings

[Paul Moore]

On 1 June 2018 at 22:57, Chris Angelico  wrote:

> How will a method be worse than a standalone function? Please explain
> this.

Because the standalone function already exists (in the textwrap
module). There's nothing wrong with adding string methods, but where
they don't add anything that can't be done already within the core
language and stdlib, then they have to get past the hurdle of "status
quo wins".

> A method is a lot easier to discover than a stdlib module
> function,

If you're using Google or the python docs, I'm not sure it is easier,
and I'm certain it's not a *lot* easier. If you're using the REPL,
then yes, finding a string method is easier than hunting out a random
function that takes a string argument.

> which is in turn IMMENSELY more discoverable than anything
> on pypi.

True. But discoverability of anything gets a lot better when it's more
widely used, so if this is a common need, I'd hope that
discoverability of any approach would improve over time.

> If you dislike adding features to a language on the basis that it
> makes the language harder to learn, remember that you instead force
> one of three even worse options:
>
> 1) Messy code because people unindent inside their source code,
> creating wonky indentation (which Python usually avoids)
>
> 2) Forcing readers to look up the third-party module you're using
> before they can understand your code
>
> 3) Forcing readers to look up your ad-hoc function before
> understanding your code.
>
> All of these make it harder to understand your code, specifically
> BECAUSE the language doesn't have the requisite feature. Well-written
> language features are good, not bad, for readability.

You missed the option that's actually the case:

0) Expecting readers to look up a stdlib module in order to understand
your code.

And you aren't comparing like with like, if this were a string method
users would have to look up that method, just as much as they would
have to look up a stdlib function. But honestly, if someone needs to
look up the definition a function or method called "dedent", then
either there is something more than normally complex going on, or they
are not a native English speaker and this is the least of their
worries, or something similar.

No-one is saying a method is *worse* than a standalone function - they
are just saying it's *not sufficiently better* to justify creating a
string method that replicates an existing stdlib function.

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

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

[Peter J. Holzer]

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 do have an
> >> attachment, i.e., a signature.asc file.
> >
> > No this is isn't an attachment. It's a signature. Your MUA probably
> > displays everything it can't handle as an "attachment".
> 
> Which, I might point out, is a decent way to handle unknown parts. The
> user is shown that there's an extra part, and can view it as an
> external file.

Which makes very little sense with a signature. By itself it is useless,
it is only useful together with the content part.

I consider this very poor UI design. There are only a handful multipart
types defined in MIME, each with clear semantics. For multipart/signed,
there are basically 2 things you can do if you don't support the
signature algorithm: Ignore the signature completely, or display an
indication that this part is signed but you can't verify the signature
(the latter might also offer a way to pass the entire multipart/signed
to an external program). But offering to view/save the signature alone
is useless and only confuses the user.

(This is especially baffling for programs which already support
multipart/signed, but not the specific signature type. What was the
developer thinking?)

hp

-- 
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson 


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Chris Angelico]

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.
>
> No this is isn't an attachment. It's a signature. Your MUA probably
> displays everything it can't handle as an "attachment".

Which, I might point out, is a decent way to handle unknown parts. The
user is shown that there's an extra part, and can view it as an
external file.

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

Re: Indented multi-line strings

[Chris Angelico]

On Sat, Jun 2, 2018 at 7:00 AM, Peter Pearson  wrote:
> On Fri, 1 Jun 2018 15:57:58 +0100, Paul Moore  wrote:
>> On 1 June 2018 at 15:36, Dan Strohl via Python-list
>> wrote:
>>> So... how does one go about suggesting changes to the built in types?
> [snip]
>>
>> Why does this need to be a string method? Why can't it be a standalone
>> function?
>
> Yes, please, let's content ourselves with a standalone function.
>
> Adding features to a language imposes costs in several ways, including
> hindering newcomers and making code version-dependent.  To full-time
> Python developers, these costs appear small, because they are amortized
> over a lot of Python activity; but they are encumbrances to the spread
> and casual use of the language.  It seems as if the destiny of every
> language is to be adorned by its enthusiasts with so many arcane and
> specialized optimizations -- every one an obvious improvement -- that
> the world's interest drifts to something newer and cleaner.

How will a method be worse than a standalone function? Please explain
this. A method is a lot easier to discover than a stdlib module
function, which is in turn IMMENSELY more discoverable than anything
on pypi.

If you dislike adding features to a language on the basis that it
makes the language harder to learn, remember that you instead force
one of three even worse options:

1) Messy code because people unindent inside their source code,
creating wonky indentation (which Python usually avoids)

2) Forcing readers to look up the third-party module you're using
before they can understand your code

3) Forcing readers to look up your ad-hoc function before
understanding your code.

All of these make it harder to understand your code, specifically
BECAUSE the language doesn't have the requisite feature. Well-written
language features are good, not bad, for readability.

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

Re: Indented multi-line strings

[Peter Pearson]

On Fri, 1 Jun 2018 15:57:58 +0100, Paul Moore  wrote:
> On 1 June 2018 at 15:36, Dan Strohl via Python-list
> wrote:
>> So... how does one go about suggesting changes to the built in types?
[snip]
>
> Why does this need to be a string method? Why can't it be a standalone
> function?

Yes, please, let's content ourselves with a standalone function.

Adding features to a language imposes costs in several ways, including
hindering newcomers and making code version-dependent.  To full-time
Python developers, these costs appear small, because they are amortized
over a lot of Python activity; but they are encumbrances to the spread
and casual use of the language.  It seems as if the destiny of every
language is to be adorned by its enthusiasts with so many arcane and
specialized optimizations -- every one an obvious improvement -- that
the world's interest drifts to something newer and cleaner.
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Peter J. Holzer]

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 probably
displays everything it can't handle as an "attachment".
> 
> I'm just curious; why and how do those particular attachments get through?
> And should they get through, I guess? E.G., what if I attach a malicious
> file labeled as .asc?

The mailinglist software can probably distinguish between
multipart/signed and multipart/mixed.

hp

-- 
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson 


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Indented multi-line strings

[Chris Angelico]

On Sat, Jun 2, 2018 at 2:10 AM, Paul Moore  wrote:
> On 1 June 2018 at 16:36, Chris Angelico  wrote:
>> On Sat, Jun 2, 2018 at 12:57 AM, Paul Moore  wrote:
>
>>> Why does this need to be a string method? Why can't it be a standalone
>>> function? Maybe you should publish an implementation on PyPI, collect
>>> some data on how popular it is, and then if it's widely used, propose
>>> it for inclusion in the stdlib at that point? By making it a string
>>> method, you're also restricting its use to users of recent versions of
>>> Python, whereas a PyPI implementation would work for everyone.
>>
>> The biggest reason to make it a string method is to give the
>> possibility of optimization. Python cannot optimize int(1.2) down to
>> the constant 1 because you might have shadowed int; but a method on a
>> string literal cannot be shadowed, and could potentially be
>> constant-folded. Include that in the initial post to preempt this
>> recommendation.
>
> So the optimisation should probably be an explicit part of the
> proposal. Without the optimisation, factors like "won't be usable in
> code that wants to support older Python", "why not just make it a
> standalone function", etc. will probably result in the proposal not
> getting accepted.

There's already an existing function, albeit not the most
discoverable. But people avoid it because it's a run-time cost, and
deleting the leading spaces in the source code eliminates that
run-time cost.

> OK, so unless the argument is "provide a string method, that's
> guaranteed to be constant folded"[1] I suspect that it's pretty
> unlikely that a proposal to add a string method that simply replicated
> the textwrap functions would get very far.
>
> [1] There's two possibilities here, of course. First, provide an
> implementation for CPython that includes the constant folding, or
> second, make constant folding a language guarantee that other
> implementations also have to implement. I doubt the second option is
> going to be practical, though.

I wouldn't make it an actual guarantee. As long as CPython has the
optimization, people will start using it; if Jython or MicroPython or
Brython does a run-time method call, so be it. It's still likely to be
faster than importing a module, but most importantly, people's code
will look better this way than manually unindented.

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

Re: Indented multi-line strings

[Paul Moore]

On 1 June 2018 at 16:36, Chris Angelico  wrote:
> On Sat, Jun 2, 2018 at 12:57 AM, Paul Moore  wrote:

>> Why does this need to be a string method? Why can't it be a standalone
>> function? Maybe you should publish an implementation on PyPI, collect
>> some data on how popular it is, and then if it's widely used, propose
>> it for inclusion in the stdlib at that point? By making it a string
>> method, you're also restricting its use to users of recent versions of
>> Python, whereas a PyPI implementation would work for everyone.
>
> The biggest reason to make it a string method is to give the
> possibility of optimization. Python cannot optimize int(1.2) down to
> the constant 1 because you might have shadowed int; but a method on a
> string literal cannot be shadowed, and could potentially be
> constant-folded. Include that in the initial post to preempt this
> recommendation.

So the optimisation should probably be an explicit part of the
proposal. Without the optimisation, factors like "won't be usable in
code that wants to support older Python", "why not just make it a
standalone function", etc. will probably result in the proposal not
getting accepted.

On 1 June 2018 at 16:20, Dan Strohl  wrote:
>
> Good point, so, basically, there already is a function for this built in 
> textwrap.dedent() and textwrap.indent(), I would think (hope) that that would 
> answer that question.

OK, so unless the argument is "provide a string method, that's
guaranteed to be constant folded"[1] I suspect that it's pretty
unlikely that a proposal to add a string method that simply replicated
the textwrap functions would get very far.

But regardless, there's no point in me trying to second guess what
might come up on python-ideas, you should just post there and see what
reception you get.

Paul

[1] There's two possibilities here, of course. First, provide an
implementation for CPython that includes the constant folding, or
second, make constant folding a language guarantee that other
implementations also have to implement. I doubt the second option is
going to be practical, though.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Indented multi-line strings

[Chris Angelico]

On Sat, Jun 2, 2018 at 12:57 AM, Paul Moore  wrote:
> On 1 June 2018 at 15:36, Dan Strohl via Python-list
>  wrote:
>> So... how does one go about suggesting changes to the built in types?  I 
>> could take a whack at the code for it, but my C skills are no where near 
>> what should probably be needed for something this close to the core of the 
>> language.  I'm not sure if adding a couple of methods is a PEP type of thing.
>
> It would probably have to go via python-ideas, but if it gets the OK
> there I doubt it would need a PEP.

Yeah, take it to -ideas but don't worry about a PEP.

> There are a few key questions I'd expect to see come up.
>
> Why does this need to be a string method? Why can't it be a standalone
> function? Maybe you should publish an implementation on PyPI, collect
> some data on how popular it is, and then if it's widely used, propose
> it for inclusion in the stdlib at that point? By making it a string
> method, you're also restricting its use to users of recent versions of
> Python, whereas a PyPI implementation would work for everyone.

The biggest reason to make it a string method is to give the
possibility of optimization. Python cannot optimize int(1.2) down to
the constant 1 because you might have shadowed int; but a method on a
string literal cannot be shadowed, and could potentially be
constant-folded. Include that in the initial post to preempt this
recommendation.

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

RE: Indented multi-line strings

[Dan Strohl via Python-list]

> 
> It would probably have to go via python-ideas, but if it gets the OK there I
> doubt it would need a PEP.
> 

Cool, thanks!

> There are a few key questions I'd expect to see come up.
> 
> Why does this need to be a string method? Why can't it be a standalone
> function? Maybe you should publish an implementation on PyPI, collect some
> data on how popular it is, and then if it's widely used, propose it for 
> inclusion
> in the stdlib at that point? By making it a string method, you're also 
> restricting
> its use to users of recent versions of Python, whereas a PyPI implementation
> would work for everyone.

Good point, so, basically, there already is a function for this built in 
textwrap.dedent() and textwrap.indent(), I would think (hope) that that would 
answer that question.



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

Re: Indented multi-line strings

[Paul Moore]

On 1 June 2018 at 15:36, Dan Strohl via Python-list
 wrote:
> So... how does one go about suggesting changes to the built in types?  I 
> could take a whack at the code for it, but my C skills are no where near what 
> should probably be needed for something this close to the core of the 
> language.  I'm not sure if adding a couple of methods is a PEP type of thing.

It would probably have to go via python-ideas, but if it gets the OK
there I doubt it would need a PEP.

There are a few key questions I'd expect to see come up.

Why does this need to be a string method? Why can't it be a standalone
function? Maybe you should publish an implementation on PyPI, collect
some data on how popular it is, and then if it's widely used, propose
it for inclusion in the stdlib at that point? By making it a string
method, you're also restricting its use to users of recent versions of
Python, whereas a PyPI implementation would work for everyone.

None of these are showstoppers - many proposals have got past them -
but it's worth having at least thought through your answers to them,
so you can present the idea in the best light.

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

RE: Indented multi-line strings

[Dan Strohl via Python-list]

> 
> I would prefer to remove the padding, like this:
> 
> Test = """
> |Hello, this is a
> | Multiline indented
> |String
> """.outdent(padding='|')
> 
> Or write it like this?
> 
> Test = """|Hello, this is a
>   | Multiline indented
>   |String
>   """.outdent(padding='|')
> 
> Hmm, the sign of Zorro! :-)
> 
> I'm starting to like outdent(), but that may be my TIMTOWTDIism speaking.
> 

I can see both outdent(padding="|") and outdent(size=4) being useful in various 
cases.  If this ends up being the recommendation, I would also suggest adding 
str.indent(), it evens out the methods and most of the time I use the textwrap 
functions it is either indent or outdent, so this would clean up those pieces.

So... how does one go about suggesting changes to the built in types?  I could 
take a whack at the code for it, but my C skills are no where near what should 
probably be needed for something this close to the core of the language.  I'm 
not sure if adding a couple of methods is a PEP type of thing.

Dan Strohl


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

Re: Indented multi-line strings

[Gregory Ewing]

Here's my take on what an indented multi-line string
syntax should look like.

string foo:
|  This is a multi-line indented string declaration.
|  Note that it's a statement, not an expression. In
|  this example, each line of the final string starts
|  with two spaces.

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

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

[Paul]

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
> 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 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? E.G., what if I attach a malicious
>> file labeled as .asc?
>>
>> [Peter, I am not suggesting anything about you!  ;). ]
>>
>> Paul C.
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>>
>
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Abdur-Rahmaan Janhangeer]

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 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? E.G., what if I attach a malicious
> file labeled as .asc?
>
> [Peter, I am not suggesting anything about you!  ;). ]
>
> Paul C.
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Paul]

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? E.G., what if I attach a malicious
file labeled as .asc?

[Peter, I am not suggesting anything about you!  ;). ]

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

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

[Chris Angelico]

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 spaces to remove from the beginning of
>> each line in the string.  Non space characters will not be
>> removed.  IF this is None, the number of characters in the first
>> line of the string will be used.
>
> The default should be the minimum number of leading spaces on non-empty
> lines, I think. This is compatible with PEP 257. And in fact it allows
> all lines to start with whitespace if the string ends with a newline
> (which is a weird dependency, but probably not much of a restriction in
> practice).

Exactly. The default will be the most commonly used option when
working with string literals; explicitly setting it is there if you
need it, but won't be the normal way you do things.

Either way, if attached to a string literal, with either no parameter
or a literal integer, this would be a valid candidate for constant
folding. (There's no way to monkeypatch or shadow anything.) At that
point, we would have all the benefits of a new string literal type,
with no syntactic changes, just the creation of the method.

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

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

[Peter J. Holzer]

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 noticed it before.

hp

-- 
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson 


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Indented multi-line strings

[Peter J. Holzer]

On 2018-05-31 16:44:10 +0100, MRAB wrote:
> I was also thinking that it could take the indentation from the first line,
> but that if you wanted the first line to have a larger indent than the
> remaining lines, you could replace the first space that you want to keep
> with a non-whitespace character and then pass that character to the method.
> 
> For example:
> 
> Test = """\
>  _   Hello, this is a
>   Multiline indented
>  String
>  """.outdent(padding='_')
> 
> Outdent so that the first line is flush to the margin:
> 
> _   Hello, this is a
>  Multiline indented
> String
> 
> The padding argument tells it to replace the initial '_':
> 
> Hello, this is a
>  Multiline indented
> String

I would prefer to remove the padding, like this:

Test = """
|Hello, this is a
| Multiline indented
|String
""".outdent(padding='|')

Or write it like this?

Test = """|Hello, this is a
  | Multiline indented
  |String
  """.outdent(padding='|')

Hmm, the sign of Zorro! :-)

I'm starting to like outdent(), but that may be my TIMTOWTDIism
speaking.

hp

-- 
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson 


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Peter J. Holzer]

[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
> > '''
> 
> I get the point, but it feels like it would be a pain to use, and it
> "Feels" different from the other python indenting, which is something
> that I would want to stay away from changing.

Yes, it's the wrong way around. The indentation should be determined by
the start quote. That's why I initially wrote that the quotes must
line up vertically.

Unfortunately you can't write 

a_multi_line_string = 
i'''
Py-
   thon
 '''

although you can write 

a_multi_line_string = \
i'''
Py-
   thon
 '''

which is visually not much worse.

> > > In any case, Chris made a good point that I agree with. This doesn't
> > > really need to be syntax at all, but could just be implemented as a
> > > new string method.
> > 
> > Depending on the details, not quite. A method wouldn't get the horizontal
> > position of the leading quote. It could infer the position of the trailing 
> > quote,
> > though.
> > 
> 
> What about if we used Chris's approach, but added a parameter to the
> method to handle the indent? 
> 
> For example, 
> 
> Test = """
> Hello, this is a
>  Multiline indented
> String
> """.outdent(4)

Eek! No, I don't think that's a good idea. It means that the programmer
has to count spaces and has to remember to adjust the parameter if the
indentation changes (e.g. because the block is wrapped in a loop or
factored out to a function).


> The outdent method could look like:
> 
> string.outdent(size=None)
> """
> :param size : The number of spaces to remove from the beginning of
> each line in the string.  Non space characters will not be
> removed.  IF this is None, the number of characters in the first
> line of the string will be used.

The default should be the minimum number of leading spaces on non-empty
lines, I think. This is compatible with PEP 257. And in fact it allows
all lines to start with whitespace if the string ends with a newline
(which is a weird dependency, but probably not much of a restriction in
practice).


> If this is an iterable, the numbers returned from each iteration
> will be used for their respective lines.  If there are more lines
> than iterations, the last iteration will be used for subsequent
> lines.

This looks like overkill to me. What would be the use case?

> This solves the problem in a very pythonic way,

Everybody has their own definition of "pythonic", I guess.

hp

-- 
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson 


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Chris Angelico]

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 pain to use, and it "Feels" 
> different from the other python indenting, which is something that I would 
> want to stay away from changing.
>
>> > In any case, Chris made a good point that I agree with. This doesn't
>> > really need to be syntax at all, but could just be implemented as a
>> > new string method.
>>
>> Depending on the details, not quite. A method wouldn't get the horizontal
>> position of the leading quote. It could infer the position of the trailing 
>> quote,
>> though.
>>
>
> What about if we used Chris's approach, but added a parameter to the method 
> to handle the indent?
>
> For example,
>
> Test = """
> Hello, this is a
>  Multiline indented
> String
> """.outdent(4)
>
>
> The outdent method could look like:
>
> string.outdent(size=None)
> """
> :param size : The number of spaces to remove from the beginning of each 
> line in the string.  Non space characters will not be removed.  IF this is 
> None, the number of characters in the first line of the string will be used.  
> If this is an iterable, the numbers returned from each iteration will be used 
> for their respective lines.  If there are more lines than iterations, the 
> last iteration will be used for subsequent lines.
>
> This solves the problem in a very pythonic way, while allowing the 
> flexibility to handle different needs.
>

Sure! Though I'd drop the iterable option - YAGNI. Keep the basic API
simple. Just an integer or None, where None's is defined in terms of
the string itself.

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

Re: Indented multi-line strings

[Terry Reedy]

On 5/31/2018 10: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 pain to use, and it "Feels" 
different from the other python indenting, which is something that I would want to stay 
away from changing.


In any case, Chris made a good point that I agree with. This doesn't
really need to be syntax at all, but could just be implemented as a
new string method.


Depending on the details, not quite. A method wouldn't get the horizontal
position of the leading quote. It could infer the position of the trailing 
quote,
though.



What about if we used Chris's approach, but added a parameter to the method to 
handle the indent?

For example,

Test = """
 Hello, this is a
  Multiline indented
 String
 """.outdent(4)


The outdent method could look like:

string.outdent(size=None)
 """
 :param size : The number of spaces to remove from the beginning of each 
line in the string.  Non space characters will not be removed.  IF this is 
None, the number of characters in the first line of the string will be used.  
If this is an iterable, the numbers returned from each iteration will be used 
for their respective lines.  If there are more lines than iterations, the last 
iteration will be used for subsequent lines.

This solves the problem in a very pythonic way, while allowing the flexibility 
to handle different needs.


string = (
" Hello, this is a concatenated   \n"
"   multiline variably indented   \n"
"string with variable trailing blanks.\n"
"It works now and always has! ")

--
Terry Jan Reedy

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

Re: Indented multi-line strings

[MRAB]

On 2018-05-31 15:39, 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 pain to use, and it "Feels" 
different from the other python indenting, which is something that I would want to stay 
away from changing.


> In any case, Chris made a good point that I agree with. This doesn't
> really need to be syntax at all, but could just be implemented as a
> new string method.

Depending on the details, not quite. A method wouldn't get the horizontal
position of the leading quote. It could infer the position of the trailing 
quote,
though.



What about if we used Chris's approach, but added a parameter to the method to 
handle the indent?

For example,

Test = """
 Hello, this is a
  Multiline indented
 String
 """.outdent(4)


The outdent method could look like:

string.outdent(size=None)
 """
 :param size : The number of spaces to remove from the beginning of each 
line in the string.  Non space characters will not be removed.  IF this is 
None, the number of characters in the first line of the string will be used.  
If this is an iterable, the numbers returned from each iteration will be used 
for their respective lines.  If there are more lines than iterations, the last 
iteration will be used for subsequent lines.

This solves the problem in a very pythonic way, while allowing the flexibility 
to handle different needs.


That string starts with a blank line, after the initial quotes.

I was also thinking that it could take the indentation from the first 
line, but that if you wanted the first line to have a larger indent than 
the remaining lines, you could replace the first space that you want to 
keep with a non-whitespace character and then pass that character to the 
method.


For example:

Test = """\
 _   Hello, this is a
  Multiline indented
 String
 """.outdent(padding='_')

Outdent so that the first line is flush to the margin:

_   Hello, this is a
 Multiline indented
String

The padding argument tells it to replace the initial '_':

Hello, this is a
 Multiline indented
String
--
https://mail.python.org/mailman/listinfo/python-list

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

[Dan Strohl via Python-list]

> 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, which is something that I would want 
to stay away from changing.

> > In any case, Chris made a good point that I agree with. This doesn't
> > really need to be syntax at all, but could just be implemented as a
> > new string method.
> 
> Depending on the details, not quite. A method wouldn't get the horizontal
> position of the leading quote. It could infer the position of the trailing 
> quote,
> though.
> 

What about if we used Chris's approach, but added a parameter to the method to 
handle the indent? 

For example, 

Test = """
Hello, this is a
 Multiline indented
String
""".outdent(4)


The outdent method could look like:

string.outdent(size=None)
"""
:param size : The number of spaces to remove from the beginning of each 
line in the string.  Non space characters will not be removed.  IF this is 
None, the number of characters in the first line of the string will be used.  
If this is an iterable, the numbers returned from each iteration will be used 
for their respective lines.  If there are more lines than iterations, the last 
iteration will be used for subsequent lines.

This solves the problem in a very pythonic way, while allowing the flexibility 
to handle different needs.

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

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

[Peter J. Holzer]

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 prefix character instead of making
> >> quad-quote meaningful? Apart from being hard to visually distinguish
> >> from triple-quote, this would break existing triple-quote strings that
> >> happen to start with the quote character, e.g What?' she asked.'''
> >
> > No confusion here, since in my proposal there is always a newline after
> > the leading delimiter, since otherwise the first line wouldn't line up
> > with the rest. So the parser would notice that this is a triple-quote
> > and not a quad-quote as soon as it sees the "W".
> 
> Then how about a triple-quote string that starts with a quote
> character followed by a newline?

Collateral damage. Seriously, if you write something like this

s = 
A quoted
multline
string


instead of this

s = """'
A quoted
multline
string
'"""

outside of an obfuscation contest, you get what you deserve.

> >> b = i'''
> >> Here is a multi-line string
> >> with indentation, which is
> >> determined from the second
> >> line.'''
> >
> > Visually, that letter doesn't look like a part of the quote, so I would
> > like to pull the contents of the string over to align with the quote:
> >
> > b = i'''
> >  Here is a multi-line string
> >  with indentation, which is
> >  determined from the second
> >  line.'''
> >
> > But that creates an ambiguity: Is the whole string now indented one
> > space or not? Where is the left edge?
> 
> I don't follow. In the first case you have a multi-line string where
> every line is indented four spaces, so four spaces are to be removed
> from every line. In the second case you have a multi-line string where
> every line is indented by five spaces, so five spaces are to be
> removed from every line.

Nope. Remember that I want to be able to have *all* lines start with
white space.

So I can't simply strip all the common whitespace.

This is the reason why I want the quote (leading or trailing, preferably
both) to indicate where the left edge of the string is.

For a quad quote this is IMHO unambiguous:

b = 
   Py-
  thon


The first line starts with 3 spaces, the second one with 2.

But the prefix makes is visually ambiguous: Is the left edge where the
prefix is or where the first quote character is.

This is of course not a problem if the *trailing* quote determines the
indentation:

a_multi_line_string = i'''
   Py-
  thon
'''


> What about the second string would make the algorithm think that four
> spaces are to be removed from every line, leaving one?

Because you have to skip 4 spaces to get below the "i" which starts the
quote.

> Why not remove three, leaving two? Or remove one, leaving
> four? And why is the first string safe from this?

Not sure what you mean by "first string". The way you wrote has either
no leading whitespace (if the "i" signals the left edge) or is a syntax
error (if the first "'" signals the left edge, because then
non-whitespace characters would have to be discarded).

> In any case, Chris made a good point that I agree with. This doesn't
> really need to be syntax at all, but could just be implemented as a
> new string method.

Depending on the details, not quite. A method wouldn't get the
horizontal position of the leading quote. It could infer the position of
the trailing quote, though.

So, yes, it would be possible. And the optimizer might call the method
at compile time instead of runtime. There is still the visual noise,
though.

This is a bit of a pet peeve of mine: It is common to indent code in all
languages invented in the 40 years or so (and even older languages like
Fortran have adopted that convention). But *none*[1] of them has syntax
to let the programmer write multiline strings that are  properly aligned
with the rest of the code. Not even Python, where indentation is part of
the syntax.

[1] I exaggerate. SPL is the one exception I know. And there are
probably a few other similarly obscure languages.

-- 
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson 


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Ian Kelly]

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?
>>
>> https://www.python.org/dev/peps/pep-0257/#handling-docstring-indentation
>
> These rules are nice for a specific application, but I think they are
> too ad-hoc and not general enough for a language feature which should be
> able to represent arbitrary strings.
>
> In particular:
>
> | will strip a uniform amount of indentation from the second and further
> | lines of the docstring, equal to the minimum indentation of all
> | non-blank lines after the first line
>
> What if I want all lines to start with some white space?
>
> |  Any indentation in the first line of the docstring (i.e., up to the
> |  first newline) is insignificant and removed.
>
> What if I want the string to start with white space?
>
> |  Blank lines should be removed from the beginning and end of the
> |  docstring.
>
> What if I want leading or trailing blank lines?

Fair points. I still dislike reinventing the wheel here. Note that
even as I proposed reusing the single existing indentation-removal
scheme in the language, I misremembered a few things about how it
works.

>> Also, how about using a string prefix character instead of making
>> quad-quote meaningful? Apart from being hard to visually distinguish
>> from triple-quote, this would break existing triple-quote strings that
>> happen to start with the quote character, e.g What?' she asked.'''
>
> No confusion here, since in my proposal there is always a newline after
> the leading delimiter, since otherwise the first line wouldn't line up
> with the rest. So the parser would notice that this is a triple-quote
> and not a quad-quote as soon as it sees the "W".

Then how about a triple-quote string that starts with a quote
character followed by a newline?

>> b = i'''
>> Here is a multi-line string
>> with indentation, which is
>> determined from the second
>> line.'''
>
> Visually, that letter doesn't look like a part of the quote, so I would
> like to pull the contents of the string over to align with the quote:
>
> b = i'''
>  Here is a multi-line string
>  with indentation, which is
>  determined from the second
>  line.'''
>
> But that creates an ambiguity: Is the whole string now indented one
> space or not? Where is the left edge?

I don't follow. In the first case you have a multi-line string where
every line is indented four spaces, so four spaces are to be removed
from every line. In the second case you have a multi-line string where
every line is indented by five spaces, so five spaces are to be
removed from every line. What about the second string would make the
algorithm think that four spaces are to be removed from every line,
leaving one? Why not remove three, leaving two? Or remove one, leaving
four? And why is the first string safe from this?

In any case, Chris made a good point that I agree with. This doesn't
really need to be syntax at all, but could just be implemented as a
new string method.
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Peter J. Holzer]

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
> >
> > x = 'Here is a multi-line string\nwith\n  indentation.'
> >
> > Rules:
> >
> >  * The leading and trailing  must be aligned vertically.
> 
> Ick, why?

To create an unambiguous left edge.

> What's wrong with letting the trailing delimiter be at the
> end of a line, or the beginning with no indentation?

If "no indentation" means "its indentation defines the left edge", so
that 

a_very_long_variable_name = 
A string.
  

is equivalent to "  A string.", I could live with that. The downside is
that the parser has to scan to the end of the string before it knows how
much whitespace to strip from each line. OTOH it makes consistent
indentation with tabs easier:

a_very_long_variable_name = 
»···»···»···»···  A string.
»···»···»···»···

Are the quad-quotes aligned? It depends on how wide a tab is. (I used
»··· to visualize a tab)

If "no indentation literally means no indentation, like this:

a = foo()
b = 
  A string.

c = bar()

then the reason for not allowing this is that it subverts the reason for
proposing this feature (to have multiline strings which nicely align
with the indentation of the code and don't stick out to the left like a
sore thumb). 

Similarily, if "no indentation" means "no additional indentation
relative to the surrounding code", then reason is that in a multiline
statement, the continuation lines should be indented more than the first
line (seep PEP 8).

The trailing delimiter could be at the end of the line to signify that
there is no newline at the end of the string:

s = 
  A string.
t = 
  A string.


would then be equivalent to 

s = '  A string.'
t = '  A string.\n'

Then the indentation of the first delimiter alone determines how much
white space is stripped. I think this looks untidy, though, and my rule
4 is more symmetrical.


> >  * The contents of the string must be indented at least as far as the
> >delimiters (and with consistent tabs/spaces).
> >This leading white space is ignored.
> >  * All the leading white space beyond this 'left edge' is preserved.
> >  * The newlines after the leading  and before the trailing  are
> >ignored, all the others preserved. (I thought about preserving the
> >trailing newline, but it is easier to add one than remove one.)
> 
> 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

These rules are nice for a specific application, but I think they are
too ad-hoc and not general enough for a language feature which should be
able to represent arbitrary strings.

In particular:

| will strip a uniform amount of indentation from the second and further
| lines of the docstring, equal to the minimum indentation of all
| non-blank lines after the first line

What if I want all lines to start with some white space? 

|  Any indentation in the first line of the docstring (i.e., up to the
|  first newline) is insignificant and removed.

What if I want the string to start with white space?

|  Blank lines should be removed from the beginning and end of the
|  docstring.

What if I want leading or trailing blank lines?


> Also, how about using a string prefix character instead of making
> quad-quote meaningful? Apart from being hard to visually distinguish
> from triple-quote, this would break existing triple-quote strings that
> happen to start with the quote character, e.g What?' she asked.'''

No confusion here, since in my proposal there is always a newline after
the leading delimiter, since otherwise the first line wouldn't line up
with the rest. So the parser would notice that this is a triple-quote
and not a quad-quote as soon as it sees the "W". 

A prefix might still be a good idea, but .. see below.


> I don't know if 'i' would be the right prefix character for this, but
> it's unused and is short for 'indented':

'i' is fine by me.

> b = i'''
> Here is a multi-line string
> with indentation, which is
> determined from the second
> line.'''

Visually, that letter doesn't look like a part of the quote, so I would
like to pull the contents of the string over to align with the quote:

b = i'''
 Here is a multi-line string
 with indentation, which is
 determined from the second
 line.'''

But that creates an ambiguity: Is the whole string now indented one
space or not? Where is the left edge?

hp

-- 
   _  | Peter J. Holzer| we build much big

Re: Indented multi-line strings

[Mikhail V]

On Wed, May 23, 2018 at 11:56 PM, Bob van der Poel  wrote:
> On Wed, May 23, 2018 at 1:45 PM, MRAB  wrote:
>
>> If you want additional indentation, then provide a string literal:
>>
>> def func():
>> foobar
>> data = >> '':
>>   first line
>>   last line
>> foobar
>>
>> for 'first line\nlast line\n' or:
>>
>> def func():
>> foobar
>> data = >> '\t':
>>   first line
>>   last line
>> foobar
>>
>> for '\tfirst line\n\tlast line\n'.
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>>
>
> I think this is getting way too complex to fix a problem which doesn't
> exist.

@Bob
It is not clear at all about which issue are you writing the comment.
Also not clear to whom is it addressed (me or MRAB).

Please - can you be specific and respectful.

And a general note - It is hard to support the conversation when the
amount of rational content becomes low.
May be it surprises you but I _read_ the comments and try to
understand them.



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

Re: Indented multi-line strings

[Mikhail V]

On Wed, May 23, 2018 at 11:45 PM, MRAB  wrote:

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

> Instead of the "s2", etc:
>
> def func():
> foobar
> data = >> :
>   first line
>   last line
> foobar
>
> Leading indentation to the level of the first line would be stripped.
>
> If you want additional indentation, then provide a string literal:
>
> def func():
> foobar
> data = >> '':
>   first line
>   last line
> foobar

Such approach has its benefits.
and ">>" looks nice.

So the benefit here is that you make it more
compact - no parameters needed.
But as you see, it just cannot parse the text in
case of positive indent.
Or otherwise I need to edit the text and then, if say I want
to paste it back elsewhere - edit again. This small nuance can
get in the way.
Also semantically - I find it a bit of implication - it's something
automatic.


> As the last line also ends with '\n', the result should be 'first line\nlast
> line\n'.

Sorry, I can't see how this would be beneficial?
This would mean every string will have trailing \n.
Even if it is one word.
Maybe it could help in some cases, for example
if you write a code generator and then append to
a file consequently.
But in general I disagree with this approach.

Also it is counter-intuitive - for example if I open a
text editor and type "a", save it and then read it with
python script - then I get only "a" but not "a\n".

But maybe I am missing something.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Indented multi-line strings

[Bob van der Poel]

On Wed, May 23, 2018 at 1:45 PM, MRAB  wrote:

> On 2018-05-23 19:36, Mikhail V wrote:
>
>> On Wed, May 23, 2018 at 8:08 PM, Mikhail V  wrote:
>>
>>> On Wed, May 23, 2018 at 4:19 PM, Dan Strohl  wrote:
>>>
>>
>> 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"
>>>
>>
>> oops, I meant it to be:
>> data = "first line\nlast line"
>>
>> sorry for possible confusion
>>
>>
>>> (assuming of course no trailing spaces were
>>> in original lines)
>>>
>>
>> Instead of the "s2", etc:
>
> def func():
> foobar
> data = >> :
>   first line
>   last line
> foobar
>
> Leading indentation to the level of the first line would be stripped.
>
> As the last line also ends with '\n', the result should be 'first
> line\nlast line\n'.
>
> If you want additional indentation, then provide a string literal:
>
> def func():
> foobar
> data = >> '':
>   first line
>   last line
> foobar
>
> for 'first line\nlast line\n' or:
>
> def func():
> foobar
> data = >> '\t':
>   first line
>   last line
> foobar
>
> for '\tfirst line\n\tlast line\n'.
> --
> https://mail.python.org/mailman/listinfo/python-list
>

I think this is getting way too complex to fix a problem which doesn't
exist.

-- 

 Listen to my FREE CD at http://www.mellowood.ca/music/cedars 
Bob van der Poel ** Wynndel, British Columbia, CANADA **
EMAIL: b...@mellowood.ca
WWW:   http://www.mellowood.ca
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Indented multi-line strings

[MRAB]

On 2018-05-23 19:36, Mikhail V wrote:

On Wed, May 23, 2018 at 8:08 PM, Mikhail V  wrote:

On Wed, May 23, 2018 at 4:19 PM, Dan Strohl  wrote:



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"


oops, I meant it to be:
data = "first line\nlast line"

sorry for possible confusion



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



Instead of the "s2", etc:

def func():
foobar
data = >> :
  first line
  last line
foobar

Leading indentation to the level of the first line would be stripped.

As the last line also ends with '\n', the result should be 'first 
line\nlast line\n'.


If you want additional indentation, then provide a string literal:

def func():
foobar
data = >> '':
  first line
  last line
foobar

for 'first line\nlast line\n' or:

def func():
foobar
data = >> '\t':
  first line
  last line
foobar

for '\tfirst line\n\tlast line\n'.
--
https://mail.python.org/mailman/listinfo/python-list

Re: Indented multi-line strings

[Mikhail V]

On Wed, May 23, 2018 at 8:08 PM, Mikhail V  wrote:
> On Wed, May 23, 2018 at 4:19 PM, Dan Strohl  wrote:

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

oops, I meant it to be:
data = "first line\nlast line"

sorry for possible confusion

>
> (assuming of course no trailing spaces were
> in original lines)
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Chris Angelico]

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 second
> line.'''

Since this doesn't change the way the string is parsed, it doesn't
actually NEED to be a prefix letter. I'd like to see this instead:

b = '''
Here is a multi-line string
with indentation, which is
determined from the second
line.'''.dedent()

Implemented as a string method, it would be completely syntactically
forwards and backwards compatible, and could be easily documented
(s.dedent() <=> textwrap.dedent(s)). And methods on literals are open
to being optimized, as there's no way to mess with imports or
anything.

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

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

[Dan Strohl via Python-list]

> 
> 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 standards. One could then see 
this as an extension of the doc-strings.

> Also, how about using a string prefix character instead of making quad-quote
> meaningful? Apart from being hard to visually distinguish from triple-quote,
> this would break existing triple-quote strings that happen to start with the
> quote character, e.g What?' she asked.'''
> 
> I don't know if 'i' would be the right prefix character for this, but it's 
> unused
> and is short for 'indented':
> 

Or go with a different character (or set of characters) altogether... like $, 
\, ~, ^, < ? (good catch on it  catching on hello' I am not in this''', I 
forgot about that behavior)

I'm not against a prefix character, just throwing out alternatives. (though, to 
me, the 'i' indicated int)


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

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

[Ian Kelly]

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  indentation.'
>
> Rules:
>
>  * The leading and trailing  must be aligned vertically.

Ick, why? What's wrong with letting the trailing delimiter be at the
end of a line, or the beginning with no indentation?

>  * The contents of the string must be indented at least as far as the
>delimiters (and with consistent tabs/spaces).
>This leading white space is ignored.
>  * All the leading white space beyond this 'left edge' is preserved.
>  * The newlines after the leading  and before the trailing  are
>ignored, all the others preserved. (I thought about preserving the
>trailing newline, but it is easier to add one than remove one.)

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

Also, how about using a string prefix character instead of making
quad-quote meaningful? Apart from being hard to visually distinguish
from triple-quote, this would break existing triple-quote strings that
happen to start with the quote character, e.g What?' she asked.'''

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 second
line.'''
-- 
https://mail.python.org/mailman/listinfo/python-list

Indented multi-line strings

[Mikhail V]

On Wed, May 23, 2018 at 4:19 PM, Dan Strohl  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
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Dan Strohl via Python-list]

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

Looks right to me, I don't know if the quad quote overloads the ' and " 
character too much, but I'm not against it.


> Rules:
> 
>  * The leading and trailing  must be aligned vertically.
>  * The contents of the string must be indented at least as far as the
>delimiters (and with consistent tabs/spaces).
>This leading white space is ignored.
>  * All the leading white space beyond this 'left edge' is preserved.
>  * The newlines after the leading  and before the trailing  are
>ignored, all the others preserved. (I thought about preserving the
>trailing newline, but it is easier to add one than remove one.)
> 
> hp
> 
> 


These sound good to me.


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

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

[Peter J. Holzer]

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

Agreed.


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

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

Rules:

 * The leading and trailing  must be aligned vertically.
 * The contents of the string must be indented at least as far as the
   delimiters (and with consistent tabs/spaces).
   This leading white space is ignored.
 * All the leading white space beyond this 'left edge' is preserved.
 * The newlines after the leading  and before the trailing  are
   ignored, all the others preserved. (I thought about preserving the
   trailing newline, but it is easier to add one than remove one.)

hp


-- 
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson 


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list