On Aug 26, 2019, at 16:03, stpa...@gmail.com 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 -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/C7R3CLKBWT4LICX33HCSIT7ETHTQUVDM/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to