Boolean options submitted to API in Python style

[reefdog]

Hi there @anthonydb, this is @reefdog, a developer with DocumentCloud. We're really excited that you've written this impressive library for interacting with our API, and want to be of any help we can.

We noticed that when users of pneumatic set boolean options (like force_ocr), it hits our server with Python-style boolean values (True or False). Unfortunately, Rails doesn't coerce these into their respective boolean values; they both get treated as strings. You'll need to make sure you're sending all booleans as true or false (lowercase) in order to trigger expected behavior from our API.

You can actually find this and more helpful information on our API documentation page, which, thanks to our stellar employees and contributors is even available in Spanish if you're logged in and have your workspace set to Spanish.

Cheers, Anthony!

[anthonydb]

Hi, @reefdog! You may not know this, but I'm a big fan of DocumentCloud, which is why I created this package. I am actually fairly goosebumped (is that a verb?) that one of its developers is checking out my code! Do you all do autographs?

Anyhoo, your point about Python and its capitalized True and False booleans causing dismay at the HQ of DocumentCloud's API is well-taken, and I hereby declare that no matter how many Pulitzer Prizes someone has they will no longer be able to send one of those suckers your way.

You'll see from 743b78e that I've removed force_ocr and secure from the payload dictionary (they were there by default) and now only pass them in if a user explicitly provides a True boolean in the uploader. If they do, I turn into a Ruby-friendly true and send it your way.

I've also clarified usage in the docs.

Hope this solves any further issues and hope you have a nice day!

[reefdog]

Anthony, haha, we're actually a very approachable bunch, unless you want to talk prog rock. Then blood can get spilled. But for all other topics, feel free to reach out any time! Thanks for fixing this, our exception logs are in better shape for it, and I know the entire team is thankful for that.

Keep on keepin on, and if you ever need help interacting with the API, I'd recommend shooting an email to [email protected], who keeps our docs ship-shape and has a great handle on things. Cheers!

[tommeagher]

I've been thinking about this issue a bit, because it struck me as odd why requests doesn't automatically convert the payload to a JSON boolean object, false, and instead sends it as a string of a Python boolean object, False. You shouldn't have to convert your booleans to strings to get it to work.

Would the post request to the API accept these params as "data" rather than "args"? Looking in the requests docs, it appears that you could use the json parameter on upload_dict['payload'] to handle the conversion for you, which params doesn't do. (or you could use the data parameter and use json.dumps to convert the dict.

You could do something like this to avoid the extra lines of conversions to strings :

        r = requests.post(self.base_uri + 'upload.json',
                          json=upload_dict['payload'],
                          files=files,
                          headers=self.headers)
        upload_response = r.json() #this method returns the json-encoded content of the response, which in this case is what I think you want.

Not 100% certain this would work, but thought I'd mention it just in case.

[anthonydb]

@tommeagher You make a good point; re-opening for more investigation. Thank you!

[reefdog]

I applaud @tommeagher for side-stepping Tony's and my game of pretend and actually tackling the issue at hand. 👏

[tommeagher]

Oh, do you two know each other?

[reefdog]

We've crossed paths once or twice.