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
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.
In Python 3.7 that part is now:
stringprefix = r"(?i:\br|u|f|fr|rf|b|br|rb)?"
(which looks slightly wrong to me!).
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
