<div><div dir="auto">Hey again,</div><div dir="auto"><br></div><div dir="auto">Thx all for the active discussion. </div><div dir="auto"><br></div><div dir="auto">Since I‘m the OP and though want to make clear that I didn‘t had a `d` string literal in mind. </div><div dir="auto"><br></div><div dir="auto">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‘.</div><div dir="auto"><br></div><div dir="auto">So I‘m aware that probably there won‘t be a majority to have this considering a breaking change - still I want to emphasize that I wouldn‘t want yet another string literal. I think this would be really bad. </div><div dir="auto"><br></div><div dir="auto">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`?</div><div dir="auto"><br></div><div dir="auto">Anyways, I think I‘ve made my Point clear. </div><div dir="auto"><br></div><div dir="auto"><br></div><div class="gmail_quote"><div>Terry Reedy <<a href="mailto:tjreedy@udel.edu">tjreedy@udel.edu</a>> schrieb am So. 1. Apr. 2018 um 21:12:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 4/1/2018 8:36 AM, Steven D'Aprano wrote:<br>
> On Sun, Apr 01, 2018 at 08:08:41AM -0400, Richard Damon wrote:<br>
><br>
>> One comment about the 'combinatorial explosion' is that it sort of assumes<br>
>> that each individual combination case needs to be handled with distinct<br>
>> code.<br>
<br>
> No -- as I said in an earlier post, Terry and I (and Eric) are talking<br>
> about the explosion in number of prefixes, not the complexity of the<br>
> code.<br>
><br>
> You are right that many of the prefixes can be handled by the same code:<br>
><br>
> rfd rfD rFd rFD rdf rdF rDf rDF<br>
> Rfd RfD RFd RFD Rdf RdF RDf RDF<br>
> frd frD fRd fRD fdr fdR fDr fDR<br>
> Frd FrD FRd FRD Fdr FdR FDr FDR<br>
> drf drF dRf dRF dfr dfR dFr dFR<br>
> Drf DrF DRf DRF Dfr DfR DFr DFR<br>
> # why did we support all these combinations? who uses them?<br>
><br>
> presumably will all handled by the same "raw dedent f-string" code. But<br>
> the parser still has to handle all those cases, and so does the person<br>
> reading the code.<br>
<br>
IDLE's colorizer does its parsing with a giant regex. The new prefix<br>
combinations would nearly double the number of alternatives in the<br>
regex. I am sure that this would mean more nodes in the compiled<br>
finite-state machine. Even though the non-re code of the colorizer<br>
would not change, I am pretty sure that this would mean that coloring<br>
takes longer. Since the colorizer is called with each keystroke*, and<br>
since other events can be handled between keystrokes#, colorizing time<br>
*could* become an issue, especially on older or slower machines than<br>
mine. Noticeable delays between keystroke and character appearance on<br>
screen are a real drag.<br>
<br>
* Type 'i', 'i' appears 'normal'; type 'n', 'in' is colored 'keyword';<br>
type 't', 'int' is colored 'builtin'; type 'o', 'into' becomes 'normal'<br>
again.<br>
<br>
# One can edit while a program is running in a separate process and<br>
outputting to the shell window.<br>
<br>
--<br>
Terry Jan Reedy<br>
<br>
_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/codeofconduct/</a><br>
</blockquote></div></div>