Requests: Почему по умолчанию используется simplejson?

Спасибо за этот отчет! Пожалуйста, смотрите вопрос № 2516, когда это обсуждалось в последний раз.

Итак, чтобы внести ясность, я сейчас, как и тогда, был готов полностью удалить simplejson как вариант, но @kennethreitz хотел, чтобы он был там. знак равно

Я не говорю, что его нужно удалить... но, возможно, есть лучший способ контролировать импорт. Библиотеки могут конфликтовать друг с другом. Может ли быть способ указать библиотеку json для запросов?

Исторически у меня сложилось впечатление, что только что скомпилированный модуль simplejson имеет лучшие характеристики производительности, чем модуль json , встроенный в Python 2.6.

Я считаю, что «ускорение» не было включено в модуле json до версии 2.7.

Здесь вспоминаю по памяти, так что могу быть не прав.

Управление импортом _чрезвычайно_ чревато, потому что оно основано на задержке импорта до более позднего времени выполнения. Я очень не хочу этого делать, потому что это приводит к появлению ошибок в странных местах и, как правило, делает жизнь странно сложной. Если мы собираемся сохранить это, мы должны сохранить это, если мы собираемся удалить это, мы должны удалить это.

Последние три комментария здесь хорошо излагают нашу позицию https://github.com/kennethreitz/requests/pull/2516#issuecomment -89005463

Итак, что бы вы предложили делать, когда две библиотеки конфликтуют друг с другом? Monkey исправляет библиотеку запросов, чтобы контролировать, какой импорт json используется?

Конфликт друг с другом? Я не понимаю. Если simplejson не работает должным образом в вашей системе, вы, вероятно, узнаете, почему, или удалите его.

Я не против удаления, если это действительно проблема для некоторых пользователей, так как я не думаю, что это повлияет на кого-либо каким-либо измеримым образом, но в настоящее время это один из тех приятных последних штрихов, которые превращают использование запросов в удовольствие — крайний уровень задумчивость.

Пять лет назад люди гораздо больше заботились о скорости своих библиотек сериализации кодирования/декодирования, чем сегодня. Это была лучшая практика. Я тоже не думаю, что это вредно.

Следует также отметить, что сегодня версия 2.6 используется гораздо реже, чем пять лет назад.

@digitaldavenyc единственный приемлемый способ управления этим потоком импорта - поддержка переменной среды, например REQUESTS_NO_SIMPLEJSON . Этого не произойдет.

Да, я приведу свой реальный сценарий... Одна библиотека использует запросы и после некоторого поиска обнаружила, что по разным причинам она переопределяет декодирование json. Он отлично работает с запросами при использовании стандартной библиотеки Python json, но другая библиотека Python решила импортировать simplejson и сломала декодирование в запросах. Вы могли бы сказать, что реальной проблемой было переопределение, но я думаю, что отсутствие контроля над тем, какие запросы библиотеки json используют, является проблемой.

Следует также отметить, что наша поддержка json очень проста и никоим образом не нужна для использования библиотеки — вы можете легко json.loads(response.content) (хотя мы делаем немного больше с кодировками, я думаю).

Действительно ли у simplejson есть прирост производительности по сравнению с собственным json в более новых версиях Python 3.3+?

Понятия не имею, сомневаюсь. Я специально сказал Python 2.6.

Или json.loads(response.text) . Да, приятно использовать удобный метод, но запросы имеют множество удобных методов, которые люди обходят в определенных случаях, и это отличный пример одного случая (где у вас есть другое требование к simplejson, которое должно работать точно так же, как модуль json стандартной библиотеки ).

Однако вопросы о производительности simplejson не относятся к запросам.

Я собирался сказать, что, возможно, нет причин что-либо менять в запросах, но если нет причин, связанных с производительностью, для использования simplejson, то зачем больше включать его в запросы?

Вы читали какие-либо комментарии, которые я оставил ранее?

Причины, связанные с производительностью == Python 2.6.x.

@kennethreitz Точно. Вы только что упомянули, что мало кто больше использует Python 2.6. По-прежнему приятно иметь функцию, которую стоит включить?

Может быть, а может и нет. Именно это постулировали мои утверждения выше.

В частности https://github.com/kennethreitz/requests/issues/3052#issuecomment -197025994

Я согласен с вами, что поддержка simple-json была отличной 3-4 года назад, она показала тот уровень продуманности, который делает запросы отличной библиотекой. Но я не вижу ценности включения простого json в будущие выпуски. Если только приложения, использующие Python 2.6, могут получить какие-либо преимущества от использования simple-json, кажется бессмысленным включать что-то еще, поскольку это самая низкая версия Python, которая в настоящее время поддерживается запросами.

Я просто пользователь запросов, но вы, ребята, поддерживаете библиотеку, и вам решать.

Я согласен. Несколько вариантов здесь:

1. Оставить все как есть (всегда предпочтительно)
2. Полностью удалить логику simplejson (я думаю, это будет хорошо)
3. Ограничение логики simplejson только до 2.6 (неидеально, но ограничит возможные побочные эффекты)

Мне больше всего нравится 1 , с фразой "если не сломалось, не чини!" менталитет, очень слабо держится. Я знаю, что 2 — это то, что предпочитают @sigmavirus24 и @Lukasa , и если это стоит (минимальных) усилий, я не против, если они за это.

Я думаю, что 3 , вероятно, будет лучшим вариантом, поскольку пользователи Python 2.6 все еще могут использовать simple-json, и на данный момент он все еще поддерживается запросами. Могут ли быть потенциально какие-либо проблемы с этим?

Я не думаю, что кто-то заметит или позаботится. Я вставил это _для_ них, потому что _мне_ было наплевать больше, чем им :)

Если бы сообщество действительно заботилось о скорости, мы бы все время использовали ujson . В наши дни речь идет об удобстве и привязанности к толпе, прежде всего.

Найдено в Интернете:

С simplejson (при использовании модуля ускорения) тип строки зависит от ее значения, т.е. он декодирует строки как тип 'str', если их символы только для ascii, но как 'unicode' в противном случае; как ни странно, он всегда декодирует строки как юникод (как стандартный модуль json), когда ускорение отключено.

Ошибка новичка, хотя довольно распространенная практика pre-python3. Запросы делали это в течение многих лет для Response.content , прежде чем я начал работать над поддержкой Python 3 и был вынужден сделать отдельное свойство Response.text для юникода (гораздо лучший дизайн).

Я подозреваю, что это проблема, с которой вы столкнулись.

Учитывая эту информацию, 2 это будет: полное удаление логики simplejson.

2, вероятно, лучший путь в долгосрочной перспективе.

Что ж, я был признателен, когда вы включили simple-json еще в 2010 году, если вас это утешит :-)

Имеет ли смысл повторно открыть исходный PR https://github.com/kennethreitz/requests/pull/2516 ?

№ 2516 причудливым образом добавил код для возврата к simplejson, который никогда не может быть использован (во всех версиях Python есть модуль json , который успешно импортирует.

Право, это не имеет смысла. Тогда новый пиар?

Ага. знак равно

С # 3056 объединены, я закрываю это.

Я согласен. Несколько вариантов здесь:

1. Оставить все как есть (всегда предпочтительно)
2. Полностью удалить логику simplejson (я думаю, это будет хорошо)
3. Ограничение логики simplejson только до 2.6 (неидеально, но ограничит возможные побочные эффекты)

Мне больше всего нравится 1 , с фразой "если не сломалось, не чини!" менталитет, очень слабо держится. Я знаю, что 2 — это то, что предпочитают @sigmavirus24 и @Lukasa , и если это стоит (минимальных) усилий, я не против, если они за это.

2, вероятно, лучший путь в долгосрочной перспективе.

У меня тоже такая же проблема, но я не могу удалить simplejson с помощью « pip3 uninstall simplejson ». Если это не способ удалить его, скажите, пожалуйста, как его удалить.

simplejson — это тот же модуль, что и «json», только более современный (и потенциально более быстрый)

отправлено из моего Айфона

15 ноября 2019 г. в 13:45 Бхану Пракаш ( [email protected] ) написал:

В
Я согласен. Несколько вариантов здесь:

Оставить все как есть (всегда предпочтительно)
Полностью удалить логику simplejson (я думаю, это будет хорошо)
Ограничение логики simplejson только до 2.6 (неидеально, но ограничит возможные побочные эффекты)
Мне больше всего нравится 1, с фразой "если не сломалось, не чини!" менталитет, очень слабо держится. Я знаю, что 2 — это то, что предпочитают @sigmavirus24 и @Lukasa , и если это стоит (минимальных) усилий, я не против, если они за это.

2, вероятно, лучший путь в долгосрочной перспективе.

У меня тоже такая же проблема, но я не могу удалить simplejson с помощью « pip3 uninstall simplejson ». Если это не способ удалить его, скажите, пожалуйста, как его удалить.

—
Вы получаете это, потому что вы изменили состояние открытия/закрытия.
Ответьте на это письмо напрямую, просмотрите его на GitHub или отмените подписку.

поэтому он используется в первую очередь, если он доступен, поскольку, вероятно, он будет быстрее для пользователя, если он использует колесо или имеет доступные расширения c. десериализация — очень медленная операция в вычислительном отношении, особенно если вы выполняете сотни тысяч запросов. все, что мы можем сделать, чтобы помочь оптимизировать это, мы должны делать.

Удаление этого не будет несовместимо с API, но потребует нового выпуска запросов, который должен содержать только исправления безопасности. Пользователи могут полагаться на эту функциональность, и она не наносит вреда кодовой базе.