On 28 October 2015 at 20:05, Alexander Walters <tritium-l...@sdamon.com> wrote: > Have you ever used a command line application that --accepted --Boolean > --flags? Have you ever found one that required the flags to be in order? > You remember how much you hated that application for being so arbitrary > about the input?
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, and only cause a compile time transformation in the stored constant without changing the code to load that constant at runtime) 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"). It's only a mild preference, but the main benefit I see is reining in the combinatorial explosion of possible string prefixes before it even has a chance to start getting out of hand. > one of the few undeniably good choices made in python 3. There's no need here for passive aggressive snark directed at the designers providing you with a free programming language. Folks have the entire internet to complain about how much they dislike our work (where we can pick and choose whose feedback we want to listen to), so we don't need to accept it here. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
