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
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
