On 8/26/19 4:03 PM, 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. > > There are quite a few situations where this can be used: > - Fraction literals: `frac'123/4567'` > - Decimals: `dec'5.34'` > - Date/time constants: `t'2019-08-26'` > - SQL expressions: `sql'SELECT * FROM tbl WHERE a=?'.bind(a=...)` > - Regular expressions: `rx'[a-zA-Z]+'` > - Version strings: `v'1.13.0a'` > - etc. > > This proposal has been already discussed before, in 2013: > https://mail.python.org/archives/list/python-ideas@python.org/thread/M3OLUURUGORLUEGOJHFWEAQQXDMDYXLA/ > > The opinions were divided whether this is a useful addition. The opponents > mainly argued that as this only "saves a couple of keystrokes", there is no > need to overcomplicate the language. It seems to me that now, 6 years later, > that argument can be dismissed by the fact that we had, in fact, added new > prefix "f" to the language. Note how the "format strings" would fall squarely > within this framework if they were not added by now. > > 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? > > The prefixes would also help when writing functions that accept different > types > of their argument. For example: > > collection.select("abc") # find items with name 'abc' > collection.select(rx"[abc]+") # find items that match regular expression > > I'm not discussing possible implementation of this feature just yet, we can > get to > that point later when there is a general understanding that this is worth > considering.
I have seen a lot of discussion on this but haven't seen a few points that I thought of brought up. One solution to all these would be to have these be done as suffixes, Python currently has a number of existing prefixes to strings that are valid, and it might catch some people when they want to use a combination that is currently a valid prefix. (It has been brought up that this converts an invalid prefix from an immediately diagnosable syntax error to a run time error.) This also means that it becomes very hard to decide to add a new prefix as that would now have a defined meaning. A second issue is that currently some of the prefixes (like r) change how the string literal is parsed. These means that the existing prefixes are just a slightly special case of the general rules, but need to be treated very differently, or perhaps somehow the prefix needs to indicate what standard prefix to use to parse the string. Some of your examples could benefit by sometimes being able to use r' and sometimes not, so being able to say both r'string're or 'string're could be useful. -- Richard Damon _______________________________________________ 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/VXIDEEE3225UIKWJOROCJVIESXBJIS2O/ Code of Conduct: http://python.org/psf/codeofconduct/
