On 2018-04-02 11:40, MRAB wrote:
OTOH, it's not like it's causing a problem.
Well, not a big one, but there are arguments for keeping a language as simple as
possible.
Also every time an idea comes up for a string prefix, the combinatorial issue
comes up again. If we could factor out an
On 2018-04-02 10:53, Michel Desmoulin wrote:
Le 02/04/2018 à 07:09, Mike Miller a écrit :
On 2018-04-01 05:36, Steven D'Aprano wrote:
You are right that many of the prefixes can be handled by the same code:
rfd rfD rFd rFD rdf rdF rDf rDF
Rfd RfD RFd RFD Rdf RdF RDf RDF
frd
On 2 April 2018 at 23:06, Steven D'Aprano wrote:
> On Mon, Apr 02, 2018 at 12:08:47PM +, Steve Barnes wrote:
>
>> This would reflect that, typically, a specific developer tends to want
>> either all or no multi-line text strings dedented.
>
> I don't know how you come to
On Mon, Apr 02, 2018 at 12:08:47PM +, Steve Barnes wrote:
> This would reflect that, typically, a specific developer tends to want
> either all or no multi-line text strings dedented.
I don't know how you come to that conclusion.
I certainly would not want "All or Nothing" when it comes to
On 01/04/2018 02:48, Steven D'Aprano wrote:
> On Sun, Apr 01, 2018 at 02:20:16AM +0100, Rob Cliffe via Python-ideas wrote:
>
>>> New unordered 'd' and 'D' prefixes, for 'dedent', applied to multiline
>>> strings only, would multiply the number of alternatives by about 5 and
>>> would require
Le 02/04/2018 à 07:09, Mike Miller a écrit :
>
> On 2018-04-01 05:36, Steven D'Aprano wrote:
>> You are right that many of the prefixes can be handled by the same code:
>>
>> rfd rfD rFd rFD rdf rdF rDf rDF
>> Rfd RfD RFd RFD Rdf RdF RDf RDF
>> frd frD fRd fRD fdr fdR fDr fDR
>>
On 2018-04-01 05:36, Steven D'Aprano wrote:
You are right that many of the prefixes can be handled by the same code:
rfd rfD rFd rFD rdf rdF rDf rDF
Rfd RfD RFd RFD Rdf RdF RDf RDF
frd frD fRd fRD fdr fdR fDr fDR
Frd FrD FRd FRD Fdr FdR FDr FDR
drf drF dRf dRF dfr dfR
On 2018-04-01 20:10, Terry Reedy wrote:
On 4/1/2018 8:36 AM, Steven D'Aprano wrote:
On Sun, Apr 01, 2018 at 08:08:41AM -0400, Richard Damon wrote:
One comment about the 'combinatorial explosion' is that it sort of assumes
that each individual combination case needs to be handled with distinct
On 4/1/18 4:31 PM, Brendan Barnwell wrote:
> On 2018-04-01 05:36, Steven D'Aprano wrote:
>> On Sun, Apr 01, 2018 at 08:08:41AM -0400, Richard Damon wrote:
>>
>>> One comment about the 'combitorial explosion' is that it sort of
>>> assumes
>>> that each individual combination case needs to be
On 2018-04-01 05:36, Steven D'Aprano wrote:
On Sun, Apr 01, 2018 at 08:08:41AM -0400, Richard Damon wrote:
One comment about the 'combitorial explosion' is that it sort of assumes
that each individual combination case needs to be handled with distinct
code.
No -- as I said in an earlier
On Mon, Apr 2, 2018 at 5:25 AM, Marius Räsener wrote:
> Actually I‘d rather like to see Python develop backwards and remove string
> literals and not getting even more ... so maybe just `r` and `b`?
Yeah, that's not gonna happen :)
ChrisA
On 4/1/18 8:36 AM, Steven D'Aprano wrote:
> On Sun, Apr 01, 2018 at 08:08:41AM -0400, Richard Damon wrote:
>
>> One comment about the 'combitorial explosion' is that it sort of assumes
>> that each individual combination case needs to be handled with distinct
>> code.
> No -- as I said in an
Hey again,
Thx all for the active discussion.
Since I‘m the OP and though want to make clear that I didn‘t had a `d`
string literal in mind.
So the Idea was to support this just as default, with any more effords to
support it I don‘t see a real advantage or that I‘d think it is ‚solved‘.
So
On 4/1/2018 8:36 AM, Steven D'Aprano wrote:
On Sun, Apr 01, 2018 at 08:08:41AM -0400, Richard Damon wrote:
One comment about the 'combinatorial explosion' is that it sort of assumes
that each individual combination case needs to be handled with distinct
code.
No -- as I said in an earlier
On 4/1/2018 8:55 AM, Chris Angelico wrote:
On Sun, Apr 1, 2018 at 10:36 PM, Steven D'Aprano wrote:
And that *mental complexity* is (in my opinion) the biggest issue with
adding a new d-prefix, and why I would rather make it a method.
Another big advantage of a method is
On Sun, Apr 1, 2018 at 10:36 PM, Steven D'Aprano wrote:
> And that *mental complexity* is (in my opinion) the biggest issue with
> adding a new d-prefix, and why I would rather make it a method.
>
> Another big advantage of a method is that we can apply it to
> non-literals
On Sun, Apr 01, 2018 at 08:08:41AM -0400, Richard Damon wrote:
> One comment about the 'combitorial explosion' is that it sort of assumes
> that each individual combination case needs to be handled with distinct
> code.
No -- as I said in an earlier post, Terry and I (and Eric) are talking
Hi,
On 03/31/2018 09:47 PM, Terry Reedy wrote:
> With no padding, I would not argue with someone who prefers
> textwrap.dedent, but dedent cannot add the leading space.
Couldn't one use use the 'indent' method on the 'textwrap' module for
that purpose?
Thanks,
--francis
On 4/1/18 5:11 AM, Eric V. Smith wrote:
> On 3/31/2018 9:48 PM, Steven D'Aprano wrote:
>> On Sun, Apr 01, 2018 at 02:20:16AM +0100, Rob Cliffe via Python-ideas
>> wrote:
>>
New unordered 'd' and 'D' prefixes, for 'dedent', applied to multiline
strings only, would multiply the number of
A "d" prefix to do textwrap.dedent is something I wished for a long time.
It's like the "f" one: we already can do it, be hell is it convenient to
have a shortcut.
This is especially if, like me, you take a lot of care in the error
messages you give to the user. I write a LOT of them, very long,
On 1 April 2018 at 19:24, Chris Angelico wrote:
> Since the entire point of the Py3 u"..." prefix is compatibility with
> Py2, the semantics have to be retained. There's no point supporting
> ur"..." in Py3 if it's not going to produce the same result as in Py2.
Right, "ur"
On Sun, Apr 1, 2018 at 7:11 PM, Eric V. Smith wrote:
> Interestingly, in 2.7 'ur' is a valid prefix, but not in 3.6. I don't recall
> if that was deliberate or not. And 'ru' isn't valid in either version.
I believe it was. The 'ur' string literal in Py2 was a bizarre hybrid
On 3/31/2018 9:48 PM, Steven D'Aprano wrote:
On Sun, Apr 01, 2018 at 02:20:16AM +0100, Rob Cliffe via Python-ideas wrote:
New unordered 'd' and 'D' prefixes, for 'dedent', applied to multiline
strings only, would multiply the number of alternatives by about 5 and
would require another rewrite
On Sun, Apr 01, 2018 at 07:39:31AM +, Marius Räsener wrote:
> Ok I see this is nothing for any 3.x release.
[...]
> So, if at all, maybe something for Python 4 :)
No, that's the wrong conclusion to draw.
There are four options:
(1) Change the behaviour of triple-quoted strings, immediately
Ok I see this is nothing for any 3.x release.
I imagine this now either ‚clean‘ for users with compatibility break or
just leave things as they are.
So, if at all, maybe something for Python 4 :)
Coincidence I watched yesterday Armin Ronachers talk related to seeing
compatibility as the holy cow
On Sun, Apr 01, 2018 at 02:20:16AM +0100, Rob Cliffe via Python-ideas wrote:
> >New unordered 'd' and 'D' prefixes, for 'dedent', applied to multiline
> >strings only, would multiply the number of alternatives by about 5 and
> >would require another rewrite of all code (Python or not) that
In 3.6, we introduced a new prefix, 'f', so there was no back
compatibility issue. There was, however, a combinatorial explosion
issue, as 'F' was also added (a mistake, I now think), and no order
requirement (possibly another mistake). Hence
stringprefix ::= "r" | "u" | "R" | "U"
On Sat, Mar 31, 2018 at 04:50:03PM +0200, Marius Räsener wrote:
[...]
> What I have in mind is probably best described with an Example:
>
> print("""
> I am a
> multiline
> String.
> """)
>
> the closing quote defines the "margin indentation" - so in this example all
> lines
On 3/31/2018 2:14 PM, Marius Räsener wrote:
Oh, ok... yeah didn‘t think of that.
Except I guess I‘d assume that so far multiline strings are either with
textwrap or ‚don‘t care‘? Maybe?
For docstrings, I don't care, as a docstring consumer like help() can
reformat the docstring with indents
On 3/31/2018 10:50 AM, Marius Räsener wrote:
What I have in mind is probably best described with an Example:
print("""
I am a
multiline
String.
""")
the closing quote defines the "margin indentation" - so in this example
all lines would get reduces by their leading 4
Oh, ok... yeah didn‘t think of that.
Except I guess I‘d assume that so far multiline strings are either with
textwrap or ‚don‘t care‘? Maybe?
But sure, with that in mind it gets more tricky
Todd schrieb am Sa. 31. März 2018 um 19:49:
> It would radically change the meaning
It would radically change the meaning of every existing multi-line string.
That is an enormous backwards-compatibility break. It might work as a
__future__ import, though.
On Sat, Mar 31, 2018, 13:03 Marius Räsener wrote:
> Hey David,
>
> hm, that's actually a nice way to
Hey David,
hm, that's actually a nice way to solve this too I guess, besides the
additional import and "string literal".
but as I answered to robert before (did it wrong with who to answer,
correct it just now so the mailing-list has the answer, too) was, that I
don't have a string literal in
Hey Robert
Not really, I don‘t think another string literal would be nice.
Also, to correct your example, it would have to look something like:
print(d“““
I am
a Line
“““)
The Idea is to use the closing quotes to detect the indentation length so
to speak...
2018-03-31 17:48
I can currently write:
from textwrap import dedent as d
print(d("""
I am
A Line
"""))
It doesn't feel like these hypothetical d-strings are with new syntax.
On Sat, Mar 31, 2018, 11:49 AM Robert Vanden Eynde
wrote:
> So yes, currently you just do :
>
> import
I have to admit, regardless of how practical this is, it would surely get
rid of a ton of textwrap.dedent calls all over the place...
On March 31, 2018 9:50:43 AM Marius Räsener wrote:
Hey List,
this is my very first approach to suggest a Python improvement I'd think
Hey List,
this is my very first approach to suggest a Python improvement I'd think
worth discussing.
At some point, maybe with Dart 2.0 or a little earlier, Dart is now
supporting multiline strings with "proper" identation (tried, but I can't
find the according docs at the moment. probably due
37 matches
Mail list logo