Почему слияния системных классов Python с пользовательскими классами менее желательны, чем подключение механизма импорта?

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

Я прочитал некоторые из ресурсов, а именно ответ @Omnifarious по этому вопросу python-importing-from-builtin-library-when-module-with-same- имя-существует

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

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

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

Вот фрагмент кода, где интерпозиция должна перехватывать сообщение сокета перед его отправкой:

class vector_clock:

  def __init__(self):
   """
   Initiate the clock with the object
   """
   self.clock = [0,0]

  def sendMessage(self):
   """
   Send Message to the server
   """
   self.msg = "This is the test message to that will be interposed on"
   self.vector_clock.increment(0) # We are clock position 0

   # Some extraneous formatting details removed for brevity….
   # connectAndSend needs interpositioning to include the vector clock

   self.client.connectAndSend(totalMsg);
   self.client.s.close()

Ответы

Ответ 1

Из моего понимания вашего сообщения вы хотите изменить существующую библиотеку сокетов, чтобы внедрить в нее свои собственные функции.

Да, это вполне выполнимо, и, возможно, это даже самое простое решение вашей проблемы, но вы должны учитывать все последствия того, что вы делаете.

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

Из этого вы должны рассмотреть вопрос: ваше изменение на 100% обратно совместимо. Если вы не можете гарантировать, что вы знаете каждый случай использования сокета какой-либо библиотекой, используемой вашим процессом (подсказка: вы не можете), то вам нужно убедиться, что она полностью сохраняет всю существующую функциональность или где-то в дороге какая-то основная библиотека собирается загадочно сломаться, и вы не поймете, почему и нет способа ее отладить. Примером чего-то 100% назад совместимого (или как можно ближе к нему) является инъекция декоратора, который сохраняет информацию о времени в один из ваших собственных модулей.

Если вы полностью это понимаете и по-прежнему считаете, что ваше решение хорошее, тогда я говорю "пойдите для этого". Однако рассмотрели ли вы какие-либо альтернативы?

Если вам просто нужно ввести эту функциональность для определенного набора библиотек, которые вы используете, я бы предложил сделать что-то вроде исправления: https://docs.python.org/3/library/unittest.mock.html#unittest.mock.patch

Вы можете подклассифицировать любую базовую библиотеку, которую хотите изменить, а затем исправить библиотеку, чтобы использовать свой класс. На этом ядре, что делает патч, он изменяет глобальные привязки, используемые в целевом модуле, для использования другого класса/модуля, чем тот, который он первоначально использовал.

PS. Я не думаю, что ваша ситуация является ситуацией, которая требует подключения механизма импорта.