[Python-ideas] Dart like multi line strings identation

[Marius Räsener]

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 <tjreedy at 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 at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180401/8bc02697/attachment.html>