Hey again, Thx all for the active discussion.
Since I‘m the OP and though want to make clear that I didn‘t had a `d` string literal in mind. 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‘. 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. 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`? Anyways, I think I‘ve made my Point clear. Terry Reedy <tjre...@udel.edu> schrieb am So. 1. Apr. 2018 um 21:12: > 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 > > _______________________________________________ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
