Allow unknown numerical types for indent parameter

[kini]

This was causing failures in software which passes objects which are
neither of type str, int, or long, but rather a custom numerical class,
as the value of the indent parameter. Since this custom numerical class
understands multiplication by strings, it should be accepted by
simplejson's encoder and treated as a numerical argument.

... is what it says in the commit message. Of course, I make no such bold claim about what "should" happen, but am just submitting this pull request to see if you agree :) This is in some sense a regression because everything worked fine before string arguments for the indent parameter became supported, and the docstring suggests that backwards compatibility was aimed for.

[kini]

WTF? Sorry, that code doesn't even run. Lemme fix that...

[kini]

OK, should be fixed now. Sorry about the noise...

[etrepum]

How about you also write a test for this so that there are no future regressions, and I'll go ahead and take that.

[kini]

Great! Do you want a test that tests the situation I described, or just one which shows the regression? For example, instead of an actual numeric type, I could test that an object of the following type is accepted, which is a more minimal test case and easier to write, but I guess somehow less meaningful:

class Foo(object):
    def __mul__(self, other):
        return ''

[etrepum]

I'd prefer to have something as close as possible to your use case, since the intent was always really just to support integers. Note that float and Decimal do not implement string multiplication, so we're not even going for generic number support.

[kini]

Hmm. Well, my actual use case is quite convoluted and involves a huge amount of code that is not even entirely written in Python - you can see the relevant segment here if you're interested - so I won't try to simplify my actual use case. I'll make something along the same general lines, though.

[etrepum]

I guess the real question is - why are you using this to specify the number of spaces to indent a JSON document?

[kini]

We have a Python-based user console in which integer literals are hooked in the parser and turned into our custom integer-like objects so that they can interact better with the array of mathematical objects we provide. This means that if, for example, you type json.dumps(foo, indent=4) into the console, it is internally parsed as json.dumps(foo, indent=Integer(4)). So generally we try to make our custom objects do anything that standard Python ints can do. It's not that we particularly want to use our objects with simplejson, it's just that users may happen to do so when using our software.

I only happened to catch this because exactly such a line happened to appear in our test suite, and fails with the latest simplejson whereas it does not fail with the json module shipped with Python 2.7.2, making this technically a regression, IMO. Of course, you may consider this scenario not worth changing simplejson's code for, in which case we will need to modify our test suite, but it could still bite users who type in similar code in our console, and I think it's more elegant to patch simplejson in this way than to write code special-casing simplejson calls in our parser hooks...

[etrepum]

That sounds like a reasonable use case. It's worth a small change in the code, I just want to make sure that once it's fixed it will stay fixed for you.

[kini]

Great, I'm glad you think so. Here's a commit with a test and some documentation.

[kini]

Thanks!