Let's do what json.dump does. If width is a string, it's used as the indent, otherwise it's the number of spaces to use as the indent. Makes it a bit weird to call it width, but I don't want to deal with a deprecation cycle just to rename it.

Implemented it as requested in #1167 (comment). The reuse of 'width' does'nt look like the finest solution to me, but it fit's my needs.

Why not to introduce an indent_with kwarg indent_char kwarg that would default to single space, to decouple the level of indentation from indentation type?

The original function has an attribute width that can only contain a length. My first suggestion for this was 08db4a3 which was introducing a additional param called indent_char, which can of course also contain something like " ". The width attribute was still conaining only a length there, and the indention type was decoupled.
I changed this due to #1167 (comment), but @davidism thought also of renaming the param to indent, but discarded this because of legacy reasons. Since this params are optional, theoretically you can have both a param indent that contains the whole indention, and a param width that contains the length with a param indent_char, that contains a single indention sequence. But I think that will cause people to discuss about deprecating some of them.
To rename the length parameter width to indent_with and to introduce a new width parameter with the indention type, will be one of the worst of possible all options.

To rename the length parameter width to indent_with and to introduce a new width parameter with the indention type, will be one of the worst of possible all options.

Sorry, I indeed wrote a nonsense. What I meant was to accompany width a kwarg indent_string or indent_char that would default to space. Arguments indent, width and indent_char are not orthogonal, so I also wouldn't support an interface that uses all three in one macro.

Let's do what json.dump does.