Support for "none python" parameters used in the put_object method

[niklasae]

There are parameters available in the Facebook API that can not be represented by python arguments, for instance "fb:explicitly_shared" (https://developers.facebook.com/docs/opengraph/guides/explicit-sharing/). Therefore there is a need to make the put_object method more flexible. I suggest doing so by allowing a post_args dictionary as a method argument. Since there might be conflicts between the post_args dictionary and the kwargs, I've implemented it in such a way that the kwarg always will take precedence.

[niklasae]

Anyone had a look at this yet?

[martey]

I don't have any significant objections to the content of this pull request, and I am glad that you took pains to make it backwards-compatible.

However, I wonder whether Facebook's increasing use of colons in their API methods means that it makes sense to just replace all methods that use kwargs with dictionaries. This would break compatibility in a major way, but would make the code simpler and more future-proof.

[niklasae]

That is true and would make sense. The only thing is that I haven't seen it
being used anywhere else, but I'm far from an expert. Does anyone else know
of any other places facebook is using none "dictionary compatible"
arguments?

On 8 January 2014 17:43, Martey Dodoo [email protected] wrote:

I don't have any significant objections to the content of this pull
request, and I am glad that you took pains to make it backwards-compatible.

However, I wonder whether Facebook's increasing use of colons in their API
methods means that it makes sense to just replace all methods that use
kwargs with dictionaries. This would break compatibility in a major way,
but would make the code simpler and more future-proof.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/108#issuecomment-31851858
.

[martey]

I think there at least one other place, but it is possible that I am misremembering.

[niklasae]

Made any decision regarding this yet? I think it would be great if it was merged, since it doesn't break backwards compatibility and fixes the issue I'm having... 😃

[martey]

I have added this to the 1.0.0 milestone, so I plan on dealing with this before the next release. I have not have a chance to look into whether this commit will be merged directly, or whether larger changes need to be made, though.

[niklasae]

Great stuff, let me know if there is anything I can do.

[AlJohri]

+1 on this PR