[Python-ideas] Custom string prefixes
Haoyi Li
haoyi.sg at gmail.com
Mon May 27 17:51:40 CEST 2013
With macros <https://github.com/lihaoyi/macropy#string-interpolation>, 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130527/1a4dba3d/attachment.html>
More information about the Python-ideas
mailing list