On 10/31/2015 8:48 PM, Nick Coghlan wrote: > Given that "f" is standing for a runtime transformation (unlike the > purely declarative "b" and "r"), it makes sense to me to mentally > translate it as > "magic_format_call_that_needs_compiler_assistance(<normal string > literal>)", so requiring the "f" to be first isn't arbitrary, it's > slotting in where the function name would be for a call to a builtin. > > I'd also like to leave the door open to i-strings in the future, so my > answer to Eric's "What would the docs say?" question is that string > prefixes can contain imperative runtime flags (which appear first, are > mutually exclusive, are always lowercase, and cause a runtime > transformation by changing the actual code generated at compile time) > and declarative compile time flags (which can appear in any order > after the imperative flag, may be in upper or lower case, I think either order for b|u versus r is ok, even though a nuisance to specify in a grammer that assumes order significance. But given that Python is case-sensitive, I think the exception here was a mistake that need not be copied. > and only > cause a compile time transformation in the stored constant without > changing the code to load that constant at runtime) It makes sense to me that f should be kept logically distinct from the other two. > Currently the only imperative prefix we have is "f", while "b", "u", > and "r" are available as declarative prefixes. "i" has been proposed > as a second imperative prefix, but is currently deferred until 3.7 at > the earliest (after we have a release worth's of experience with "f"). -- Terry Jan Reedy
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4