[Python-ideas] Dart like multi line strings identation

Brendan Barnwell brenbarn at brenbarn.net
Sun Apr 1 16:31:30 EDT 2018


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 post, Terry and I (and Eric) are talking
> about the explosion in number of prefixes, not the complexity of the
> code.
>
> 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 dFr dFR
>      Drf DrF DRf DRF Dfr DfR DFr DFR
>      # why did we support all these combinations? who uses them?
>
> presumably will all handled by the same "raw dedent f-string" code. But
> the parser still has to handle all those cases, and so does the person
> reading the code.
>
> 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.

	That doesn't seem a very reasonable argument to me.  That is like 
saying that a person reading code has to mentally slog through the 
cognitive burden of understanding "all the combinations" of "a + b + c", 
"a + b - c", "a * b + c", "a - b * c", etc.  We don't.  We know what the 
operators mean and we build up our understanding of expressions by 
combining them.  Similarly, these string prefixes can mostly be thought 
of as indepedent flags.  You don't parse each combination separately; 
you learn what each flag means and then build up your understanding of a 
prefix by combining your understanding of the flags.  (This is also 
glossing over the fact that many of the combinations you list differ 
only in case, which to my mind adds no extra cognitive load whatsoever.)

-- 
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is no 
path, and leave a trail."
    --author unknown


More information about the Python-ideas mailing list