Import the builtin json first.

`simplejson` segfaults for me ([details](https://github.com/simplejson/simplejson/issues/114)) and it looks like it's not maintained. It should only be used as a last resort.


This is a very deliberate import situation. requests does not support a version of Python that lacks the standard library version. simplejson is imported first specifically because there are people who would rather it be used than the standard library's json module. As such I'm strongly -1 on including this change, but I'd still like to hear @Lukasa's thoughts.


@sigmavirus24 Which people would rather use simplejson? For what reason?


@ionelmc it was an oft-requested feature. simplejson supposedly has better performance. As for "which people" my job is not to catalogue all users of requests relying on _X_ feature. The people using this are likely easy to find in the issue history of requests. Searching "simplejson" should probably get you 98% of the way there.


It was merged via https://github.com/kennethreitz/requests/pull/710 - doesn't have any performance tests. IMO not using unmaintained libraries is reason enough to revert that change..


> IMO not using unmaintained libraries is reason enough to revert that change..

You keep calling simplejson unmaintained. Looking at the issue you linked, your issue received a nearly immediate response. Granted the author hasn't responded since the last time, but it's a very specific problem on a very specific version of python that they don't have immediate access to. I wouldn't call that unmaintained. If it were unmaintained, you would never have received a response whatsoever.


Also, even if we do want to accept this, we can't do it before 3.0.0 because it's a breaking API change (people are expecting this to use simplejson in certain cases and removing it is breaking those expectations).


So I looked into the bug on simplejson and I can't reproduce it. Also, I forgot to mention earlier that this change is functionally equivalent to only ever importing the standard library's `json` module (for interested parties).

I'd still like input from @Lukasa although I'm not rather convinced that this isn't a bug requests needs to be concerned about.


@sigmavirus24 Seems your simplejson tests were incomplete, see https://github.com/simplejson/simplejson/issues/114 for details.

Victor Stinner [seemed to be able to reproduce the issue](https://gist.github.com/ionelmc/811bbf8ceed66ca83a2a). But alas, cpython devs aren't interested in fixing simplejson. Neither am I.


My position here is that the short-term fix is simple: if simplejson is segfaulting, don't use it.

In the longer term, I don't really understand why we're bothering. If people really want to use simplejson they can, it's not that hard to monkeypatch. So for 3.0.0 I'd like to remove the conditional import.


Regardless, we certainly shouldn't merge this, because there's no point having the fallback: if we're going to import the stdlib we should just only import the stdlib. That import will _never_ fail.


Python 2.5 is not supported right? (`json` was added in 2.6)


Correct.

> On 27 Mar 2015, at 11:04, Ionel Cristian Mărieș notifications@github.com wrote:
> 
> Python 2.5 is not supported right?
> 
> —
> Reply to this email directly or view it on GitHub.


`json` and `simplejson` are the same library. In Python 2.6, where it is called `json`, it was not shipped with the speed-boosting c extensions enabled. So, in Python 2.6, it could be considered best practice to use `simplejson` if it is available. 

This is no longer the case with Python 2.7, however. Oh well. It's still a nice design consideration, in my opinion. 


@kennethreitz they are in fact slightly different, the builtin json receiving serveral bugfixes simplejson didn't.


There shouldn't be any bugfixes in json that are not also in simplejson, if you know of any and you report them I can make sure they get applied.