[Python-ideas] Custom string prefixes

[Göktuğ Kayaalp]

> I disagree that custom string prefixes make code harder to read. Saying s"ham"
> costs minutes of confusion over s("ham") is based purely on unfamiliarity,
> which can be removed over time. Why u"text" rather than make_unicode_string
> ("text") if the latter is more meaningful? 

I concur. And, while we can't know what s("ham") does to the string
"ham" (print it or get the sum of ord(x) for x in "ham" or add to a
database) without context, we can understand that some parsing of the
string is involved when we see s"ham".

> * If hooking into this preprocessing could be made easy (via a simple
>   desugaring, import-hook style, or otherwise). Naively making b"12" call the
>   function "b" is probably a bad idea, since people using variables called "b"
>   all the time. 

I thought of something like

    >>> string.register_prefix ("x", callable)

where callable expects at least one string argument and returns a
string. I don't know how apt would this be practically.

> 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.

Frankly, I never thought of this (simplifying the grammar) :)

Greetings

        Göktuğ.

Haoyi Li <haoyi.sg at gmail.com> writes:

> With macros, you can string interpolation kinda like that:
>
>
>>>> a, b = 1, 2
>>>> s%"%{a} apple and %{b} bananas"
> '1 apple and 2 bananas'
> But enough with the self promotion =D. 
>
>> What do you think
>> 
>> s"ham"
>> 
>> will mean to the reader? I think that it is better to encourage people to
> write meaningful names:
>> 
>> make_sandwich("ham")
>
> I disagree that custom string prefixes make code harder to read. Saying s"ham"
> costs minutes of confusion over s("ham") is based purely on unfamiliarity,
> which can be removed over time. Why u"text" rather than make_unicode_string
> ("text") if the latter is more meaningful? 
>
> This may be entirely mistaken, but 
>
> * If the parsing of string literals could be shifted from the lexer/parser
>   into functions being called at import time to preprocess the interned
>   literals
>   
> * If hooking into this preprocessing could be made easy (via a simple
>   desugaring, import-hook style, or otherwise). Naively making b"12" call the
>   function "b" is probably a bad idea, since people using variables called "b"
>   all the time. 
>
> * If existing prefixes would continue with identical semantics and minimal
>   performance changes (e.g. from a change from lex-time handling to user-land
>   preprocessing)
>
> Then this could be pretty nice.
>
>> I think string prefixes aren't something that we want more of, this is
> already complicated enough:
>> "b" | "B" | "br" | "Br" | "bR" | "BR" | "rb" | "rB" | "Rb" | "RB"
>> "r" | "u" | "R" | "U"
>>
>> We should be more creative on how to get rid of them.
>
> 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.
>
> Now, that's a lot of "if"s, and I have no idea if any of them at all are true,
> but if-if-if they are all true, we could both simplify the lexer/parser, open
> up the prefixes for  extensibility while maintaining the exact semantics for
> existing code.
>
> -Haoyi
>
>
>
>
> On Mon, May 27, 2013 at 10:30 AM, Göktuğ Kayaalp <goktug.kayaalp at gmail.com>
> wrote:
>
>     > ... but ISTM you're talking about something very similar
>     > to the C++11 standard's new feature of user-defined literals ...
>     
>     I did not know this until now, but it looks like a fine idea. I wonder
>     how people would react to the idea of having this in Python. I can also
>     add that this is far better than what I propose.
>     
>     
>     > In fact, I'd recommend you join python-list regardless, if only
>     > because we have awesome fun there :) You sound like you'd be the
>     > perfect sort to join in.
>     
>     
>     I've just started to get into the community, and even though I haven't
>     posted anything to python-list, I'm trying to read every message. Python
>     community is really awesome!
>     
>     Thanks for your input!
>     
>             Göktuğ
>     
>     
>     
>     Chris Angelico <rosuav at gmail.com> writes:
>     
>     > On Mon, May 27, 2013 at 8:41 PM, Göktuğ Kayaalp
>     > <goktug.kayaalp at gmail.com> wrote:
>     >>   - I know that there is a library called `decimal`, which provides
>     >>     facilities for finer floating point arithmetic. A `Decimal`
>     >>     class is used to express these numbers and operations, resulting in
>     >>
>     >>         >>> decimal.Decimal ("1.6e-9") * decimal.Decimal ("1.0e9")
>     >>
>     >>     which is a little bit messy. This can easily be cured by
>     >>
>     >>         >>> from decimal import Decimal as D
>     >>         >>> D ("1.6e-9") * D ("1.0e9")
>     >>
>     >>     but I'd enounce that the following is more concise and readable:
>     >>
>     >>         >>> D"1.6e-9" * D"1.0e9"
>     >>
>     >>     with removed parens.
>     >
>     > Your wording is a little confusing, as you're no longer talking about
>     > a string literal; but ISTM you're talking about something very similar
>     > to the C++11 standard's new feature of user-defined literals:
>     >
>     > http://en.wikipedia.org/wiki/C%2B%2B11#User-defined_literals
>     >
>     > This may be a little too complex for what you're proposing, but it is
>     > along the same lines. I suspect a generic system for allowing Decimal
>     > and other literals would be welcomed here.
>     >
>     >>     Even though `str.format (*, **)` is cool, I think using an
>     >>     'interpolated string' prefix can help clean up stuff a little bit:
>     >>
>     >>        # ...
>     >>        def build ():
>     >>          t0 = _build.CompilationTask ([...], I"{OUTDIR}/{progn}", ...)
>     >>
>     >>        def clean ():
>     >>          shell.sh (I"rm -fr {OUTDIR} *.o .pokedb")
>     >
>     > Please no. It's far too easy to make extremely messy code this way. If
>     > you want it, spell it like this:
>     >
>     > shell.sh ("rm -fr {OUTDIR} *.o .pokedb".format(**globals()))
>     >
>     > (or locals() perhaps) so it's sufficiently obvious that you're just
>     > casually handing all your names to the format function. It's like
>     > avoiding Python 2's input() in favour of explicitly spelling it out as
>     > eval(raw_input()) - put the eval call right there where it can be
>     > seen. The system of interpolations as found in other languages (I'm
>     > most familiar with the PHP one as I have to work with it on a daily
>     > basis) is inevitably a target for more and more complexity and then
>     > edge cases; being explicit is the Python way, so unless there's a
>     > really good reason to make all your global names easily available, I
>     > would be strongly inclined to not.
>     >
>     >> I'm looking forward to your criticisms and advices. I've searched this
>     >> online and asked in the chatroom (#python) and I'm nearly sure that I'm
>     >> not asking for a feature that is already present. Being a beginner, I
>     >> can say that I'm kind of nervous to post here, where really experienced
>     >> people discuss the features of an internationally-adopted language.
>     >
>     > I'd recommend python-list at python.org or comp.lang.python rather than
>     > #python; you get much better responses when there's no requirement for
>     > people to be online simultaneously. But in this case you're right,
>     > there's no feature quite as you describe.
>     >
>     > In fact, I'd recommend you join python-list regardless, if only
>     > because we have awesome fun there :) You sound like you'd be the
>     > perfect sort to join in.
>     >
>     > ChrisA
>     > _______________________________________________
>     > Python-ideas mailing list
>     > Python-ideas at python.org
>     > http://mail.python.org/mailman/listinfo/python-ideas
>     
>     
>     --
>     Göktuğ Kayaalp <goktug.kayaalp at gmail.com>
>     
>     
>     _______________________________________________
>     Python-ideas mailing list
>     Python-ideas at python.org
>     http://mail.python.org/mailman/listinfo/python-ideas
>     
>

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