[Python-3000] Open Issues for string.format PEP

[Ian Bicking]

Talin wrote:
> Here's a condensed list of the open issues that have been raised by people
> so far:
> 
> (Well, edited somewhat - I'm including 'major' issues, not minor nits -- we
> can discuss those once the major issues are settled.)
> 
> 1) Whether to drop the optional parts of the proposal:
>    -- support for field expressions (was: locals() support)
>    -- support for direct access to current scope (was: locals() support)

It seems reasonable to implement this as a format() function right now, 
and maybe test it out on a couple modules.  Doing so with or without 
special locals() support isn't too hard, and then it will be possible to 
see what change it makes in actual code.

The benefit of locals() (and maybe expression) support is going to be 
when surrounding code can be easily removed -- the actual string 
substitution isn't going to look much better.  The actual benefit is 
hard to judge without representative chunks of code.

> 3) Role and usage of custom formatters:
> 
>    "string".fformat( formatter, ... )
> 
> vs.
> 
>    MyFormat( "string" ).format( ... )

MyFormat("string").format(...) doesn't seem right as a convention.  I 
would assume my_formatter("string", ...), where my_formatter was built 
through subclassing (but doesn't really need to look like a class or 
instance).  I guess I don't see the need for string.Template-style 
invocation, even if it uses string.Template-style subclassing.

> 4) Should there be a way to pass in a dict argument without flattening it via
> **args?

I think it might not be ambiguous in practice if the first argument 
could be a dictionary.  Because you get:

   "{foo}".format(a_dict)

Since 'foo' isn't an integer and *no* keyword arguments were passed, you 
assume a_dict is a dictionary.  Already "{0}" is going to look for 
positional arguments even if there is a dictionary with a '0' key, and I 
think that's just a reasonable limitation.  Then there's the case:

   "{0} is {result}".format(a_dict)

Is this an error?  I'm not sure; it doesn't really need to be, it'd just 
evaluate to "{'result': 5} is 5" or something.  Potentially this would 
be a problem, though:

   "{0} is {result}".format(value, **vars)

When vars was {}... statically it would be clear that you intended 
{result} to come from vars, but at runtime you couldn't detect that. 
But I can't really imagine where that would happen, especially if 
there's no support for KeyError.

> 5) Should the implementation attempt to detect unused arguments?

Of course, just unused positional arguments would be detected.  Putting 
the dict as the first argument might cause a problem here.


-- 
Ian Bicking  |  ianb at colorstudy.com  |  http://blog.ianbicking.org