Re: Indented multi-line strings

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

RE: Indented multi-line strings

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

Re: Indented multi-line strings

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

Re: Indented multi-line strings

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

Re: Indented multi-line strings

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

Re: Indented multi-line strings

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

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: Indented multi-line strings

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

Re: Indented multi-line strings

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,

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: Indented multi-line strings

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,

Re: Indented multi-line strings

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

Re: Indented multi-line strings

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

RE: Indented multi-line strings

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

Re: Indented multi-line strings

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 >

RE: Indented multi-line strings

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

Re: Indented multi-line strings

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

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

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

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

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

Re: Indented multi-line strings

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"

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: Indented multi-line strings

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

Re: Indented multi-line strings

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

Re: Indented multi-line strings

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

Re: Indented multi-line strings

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

Re: Indented multi-line strings

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

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

Indented multi-line strings

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

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

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