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/