[Python-ideas] new format spec for iterable types

[Andrew Barnert]

On Sep 9, 2015, at 16:24, random832 at fastmail.us wrote:
> 
>> On Wed, Sep 9, 2015, at 18:39, Andrew Barnert via Python-ideas wrote:
>> I believe he posted a more detailed version of the idea on one of the
>> other spinoff threads from the f-string thread, but I don't have a link.
>> But there are lots of possibilities, and if you want to start
>> bikeshedding, it doesn't matter that much what his original color was.
>> For example, here's a complete proposal:
>> 
>>    class MyJoiner:
>>        def __init__(self, value):
>>            self.value = value
>>        def __format__(self, spec):
>>            return spec.join(map(str, self.value))
>>    string.register_converter('join', MyJoiner)
> 
> Er, I wanted it to be something more like
> 
> def __format__(self, spec):
>   sep, fmt = # 'somehow' break up spec into two parts

I covered later in the same message how this simple version could be extended to a smarter version that does that, or even more, without requiring any further changes to str.format. I just wanted to show the simplest version first, and then show that designing for that doesn't lose any flexibility.

> And I wasn't the one who actually proposed user-registered converters;
> I'm not sure who did.

Well, that does make it a bit harder to search for... But anyway, I think the idea is obvious enough once someone's mentioned it that it only matters if everyone decides we should do it, when we want to figure out who to give the credit to.

> At one point in the f-string thread I suggested
> using a _different_ special !word for stuff like a string that can be
> inserted into HTML without quoting. I'm also not 100% sure how good an
> idea it is (since it means either using global state or moving
> formatting to a class instead of str).

I don't see why global state is more of a problem here than for any other global registry (sys.modules, pickle/copy, ABCs,  registries, etc.). In fact, it seems less likely that, e.g., a multithreaded app container would run into problems with this than with most of those other things, not more likely. And the same ideas for solving those problems (subinterpreters, better IPC so multithreaded app containers aren't necessary, easier switchable contexts, whatever) seem like they'd solve this one just as easily.

And meanwhile, the alternative seems to be having something similar, but not exposing it publicly, and just baking in a handful of hardcoded converters for join, html, re-escape, etc., and I don't see why str should know about all of those things, or why extending that set when we realize that we forgot about shlex should require a patch to str and a new Python version.

> The Joiner class wouldn't have to exist as a builtin, it could be
> private to the format function.

If it's custom-registerable, it can be on PyPI, or in the middle of your app, although of course there could be some converters, maybe including your Joiner, somewhere in the stdlib, or even private to format, as well.