Я принял совет мистера Ковентри и представил патч . Однако, учитывая текущее состояние графика выпуска Python, а версия 3.0 уже не за горами, я не ожидаю, что она появится в релизе в ближайшее время. Тем не менее, мы посмотрим, что произойдет!
В то же время мне нравится вариант 5, предложенный г-ном Батчелдером, - пропустить поток gzip через небольшой пользовательский фильтр, который правильно устанавливает поле отметки времени. Это звучит как самый чистый подход. Как он демонстрирует, требуемый код на самом деле довольно мал, хотя его пример для некоторой простоты зависит от предположения (действующего в настоящее время), что реализация модуля gzip
выберет запись метки времени, используя ровно один четырехбайтовый вызов write()
. Тем не менее, я не думаю, что было бы очень сложно придумать полностью общую версию, если это необходимо.
Подход с исправлением обезьян (он же вариант 2) довольно заманчив из-за своей простоты, но дает мне паузу, потому что я пишу библиотеку, которая вызывает gzip
, а не просто отдельную программу, и мне кажется, что кто-то может попробуйте вызвать gzip
из другого потока, прежде чем мой модуль будет готов вернуть свое изменение в глобальное состояние модуля gzip
. Это было бы особенно прискорбно, если бы другой поток пытался вытянуть подобный трюк, исправляющий обезьяну! Я признаю, что эта потенциальная проблема вряд ли возникнет на практике, но представьте, как больно было бы диагностировать такой беспорядок!
Я смутно представляю себе попытку сделать что-то хитрое и сложное и, возможно, не настолько перспективное для будущего, чтобы каким-то образом импортировать приватную копию модуля gzip
и обезьяньего патча , которые , но к этому моменту фильтр кажется более простым и более прямым.