[Python-ideas] Custom string prefixes

Göktuğ Kayaalp goktug.kayaalp at gmail.com
Mon May 27 19:18:15 CEST 2013


> In order to achieve this ideal, and assuming you'd be keeping backward
> compatibility (!), you'd have to explain how to support both of these strings:
>
>     "Hello\n"
>     r"Hello\n"

A possible solution is:

    - In parse time, any string literal is a /raw string/, regardless of
      what prefix it has or if it even has a prefix.

    - The /raw string/ is then passed to user-land in this raw state,
      and then, if no prefix is applied, it is parsed as a standard
      string, otherwise the requested prefix is applied.

    - In case of a user-land raw string (e.g. r"yo"), the prefix
      function can be the identity function (e.g. f(x) = x).

This is possibly not the most ideal solution, but it is a solution.

Greetings,

        Göktuğ.

Ned Batchelder <ned at nedbatchelder.com> writes:

> On 5/27/2013 11:51 AM, Haoyi Li wrote:
>
>     If-if-if all that works out, you would be able to completely remove the
>     ("b" | "B" | "br" | "Br" | "bR" | "BR" | "rb" | "rB" | "Rb" | "RB" | "r" |
>     "u" | "R" | "U") from the grammar specification! Not add more to it,
>     remove it! Shifting the specification of all the different string prefixes
>     into a user-land library. I'd say that's a pretty creative way of getting
>     rid of that nasty blob of grammar =D.
>     
>     
>
> In order to achieve this ideal, and assuming you'd be keeping backward
> compatibility (!), you'd have to explain how to support both of these strings:
>
>     "Hello\n"
>     r"Hello\n"
>
> Implicit in your idea is that the plain literal creates a string of some kind,
> and but the r-prefixed string would apply some user-land function to the
> string.  But there is no function you can apply to string literals to make
> them be raw.  The r prefix suppresses interpretation that happens in
> un-prefixed strings.  By the time a user-land function got hold of the string,
> the interpretation has already been done, information has already been lost.
>
> --Ned.

-- 
Göktuğ Kayaalp <goktug.kayaalp at gmail.com>


More information about the Python-ideas mailing list