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 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.
Another big advantage of a method is that we can apply it to non-literals too.
The number of code paths increases too, but not anywhere as fast:
# existing - regular ("cooked") triple-quoted string; - raw string; - f-string - raw f-string
# proposed additions - dedent string - raw dedent string - dedent f-string - raw dedent f-string
so roughly doubling the number of cases. I doubt that will double the code complexity, but it will complicate it somewhat.
Apart from parsing, the actual complexity to the code will probably be similar whether it is a method or a prefix. After all, whichever we do, we still need built-in dedent code.
I think you miss my point that we shouldn't be parsing by each combination of prefixes (even collapsing equivalent ones), and instead by each prefix adjusting the rules for parse, which a single parsing routine uses. Mentally, you should be doing the same. I think that the grammar trying to exhaustively list the prefixes is awkward, and would be better served by a simpler production that allows for an arbitrary combination of the prefixes combined with a rule properly limiting the combinations of letters allowed, something like: one one of a give letter (case insensitive), at most one of b, u, and f, at most one of r and u (for python 3), then followed like currently with a description of what each letter does. This removes the combitorial explosion that is already starting with the addition of f. -- Richard Damon