On Aug 26, 2019, at 16:03, [email protected] wrote:
>
> In Python strings are allowed to have a number of special prefixes:
>
> b'', r'', u'', f''
> + their combinations.
>
> The proposal is to allow arbitrary (or letter-only) user-defined prefixes as
> well.
> Essentially, a string prefix would serve as a decorator for a string,
> allowing the
> user to impose a special semantics of their choosing.
I don’t think you can fairly discuss this idea without getting at least a
_little_ bit into the implementation details.
How does your code specify a new prefix? How does the tokenizer know which
prefixes are active? What code does the compiler emit for a prefixed string?
The answers to those questions will determine which potential prefixes are
useful.
In particular, you mention that f-strings “would fall squarely within this
framework”, but it’s actually pretty hard to imagine an implementation that
would have actually allowed for f-strings. They essentially need to recursively
call the compiler on the elements inside braces, and then inline the resulting
expressions into the containing scope.
> In addition, I believe that "saving a few keystroked" is a worthy goal if it
> adds
> considerable clarity to the expression. Readability counts. Compare:
>
> v"1.13.0a"
> v("1.13.0a")
>
> To me, the former expression is far easier to read. Parentheses, especially as
> they become deeply nested, are not easy on the eyes. But, even more
> importantly,
> the first expression much better conveys the *intent* of a version string. It
> has
> a feeling of an immutable object. In the second case the string is passed to
> the
> constructor, but the string has no meaning of its own. As such, the second
> expression feels artificial. Consider this: if the feature already existed,
> how *would*
> you prefer to write your code?
Neither. I’d prefer this:
2.3D # decimal.Decimal('2.3')
1/3F # 1/fractions.Fraction('3')
After all, why would I want to put the number in a string when it’s not a
string, but a number? This looks a lot like C’s `2.3f` that gives me 2.3 as a
float rather than a double, and it works like it too, so there’s no surprise.
And C++ already proves that such a thing can be widely usable; it’s been part
of that language for three versions, since 2011.
Also this:
p'C:\'
That can’t be handled by just using a “native
Path” prefix together with the existing raw prefix, because even in raw string
literals you can’t end with a backslash.
And this is another place where talking about implementation matters.
At first glance it might seem like arbitrary-literal affixes would be a lot
more difficult than string-literal-only affixes, but in fact, as soon as you
try to implement it, you realize that you get the exact same set of issues, no
more. See https://github.com/abarnert/userliteralhack for a proof of concept I
wrote back in 2015. (Not that we’d want to actually implement them the way I
did, just demonstrating that it can be done, and doesn’t cause ambiguity.) I’ve
got a couple older PoCs up there as well if you want to play around more,
including one that only allows string literals (so you can see that it’s
actually no easier, and solves no ambiguity problems). I can’t remember if I
did one that does prefixes instead of suffixes, but I don’t _think_ that raises
any new issues, except for the one about interacting with the existing prefixes.
And it might seem like having some affixes get the totally raw token, others
get a cooked string is too complicated, but C++ actually lives with a 3-way
distinction between raw token, cooked string, and fully parsed value. (Why
would you ever want the last one? So your units-and-quantities library can
define a _km suffix so 2_km is a km<int>, 2.3_km is a km<double>, 2.3f_km is a
km<float>, and maybe even 2.3dec_km is a km<Decimal>.) I’m not sure we need
this last distinction, but the first one might be worth copying, so that Path
and other literals can work, but things like version can interact nicely with
plain string literals, and r, and b if that’s appropriate, and most of all f,
by just accepting a cooked string.
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/C7R3CLKBWT4LICX33HCSIT7ETHTQUVDM/
Code of Conduct: http://python.org/psf/codeofconduct/
