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?
> >
> 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
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 you
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
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,
>
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 b
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
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
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 m
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, l
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 probabl
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,
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
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 ne
>
> 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 publi
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
> languag
>
> 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
>
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
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-rah
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
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
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
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 not
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 charact
[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
> > ''
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
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"
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"
diff
> 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
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 pr
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
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
> >
> >
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
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
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 charac
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 o
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 shoul
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.'''
Sinc
>
> 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 stand
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
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 t
>
> > 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...
> >
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 b
43 matches
Mail list logo
