[Python-ideas] Dart like multi line strings identation

[Terry Reedy]

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

IDLE's colorizer does its parsing with a giant regex.  The new prefix 
combinations would nearly double the number of alternatives in the 
regex.  I am sure that this would mean more nodes in the compiled 
finite-state machine.  Even though the non-re code of the colorizer 
would not change, I am pretty sure that this would mean that coloring 
takes longer.  Since the colorizer is called with each keystroke*, and 
since other events can be handled between keystrokes#,  colorizing time 
*could* become an issue, especially on older or slower machines than 
mine.  Noticeable delays between keystroke and character appearance on 
screen are a real drag.

* Type 'i', 'i' appears 'normal'; type 'n', 'in' is colored 'keyword'; 
type 't', 'int' is colored 'builtin'; type 'o', 'into' becomes 'normal' 
again.

# One can edit while a program is running in a separate process and 
outputting to the shell window.

-- 
Terry Jan Reedy