Блог

Я создаю библиотеку для работы с очень специфическими структурированными данными, и я создаю свою инфраструктуру поверх Pandas. В настоящее время я пишу кучу разных контейнеров данных для разных вариантов использования, таких как CTMatrix для данных о времени в стране x и т.д. для размещения методов, подходящих для всех структурированных данных CountryxTime.

В настоящее время я обсуждаю между

Вариант 1: наследование объекта

 class CTMatrix(pd.DataFrame):
    methods etc. here
  

или вариант 2: использование объекта

 class CTMatrix(object):
    _data = pd.DataFrame

    then use getter, setter methods to control access to _data etc. 
  

С точки зрения разработки программного обеспечения, есть ли здесь очевидный выбор?

Мои мысли до сих пор:

Вариант 1:

1. Можно использовать методы фрейма данных непосредственно в классе CTMatrix (например CTmatrix.sort() ) без необходимости поддерживать их с помощью методов в инкапсулированном _data объекте в варианте # 2
2. Обновления и новые методы в Pandas наследуются, за исключением методов, которые могут быть перезаписаны методами локального класса

НО

1. Сложности с некоторыми методами, такими как __init__() и необходимость передавать атрибуты в суперкласс super(MyDF, self).__init__(*args, **kw)

Вариант 2:

1. Больше контроля над классом и его поведением
2. Возможно, более устойчивый к обновлениям в Pandas?

Но

1. Необходимость использования getter() или не скрытого атрибута для использования объекта как фрейма данных, такого как ( CTMatrix.data.sort() )

Есть ли какие-либо дополнительные недостатки для использования подхода в варианте # 1?

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

На GitHub есть несколько открытых вопросов по этому поводу, например:

• https://github.com/pydata/pandas/issues/60

• https://github.com/pydata/pandas/issues/2485

В более общем плане, это вопрос композиции против наследования. Я бы особенно опасался преимущества # 2. Сейчас это может показаться замечательным, но если вы не будете внимательно следить за обновлениями Pandas (а это быстро меняющаяся цель), вы можете легко столкнуться с неожиданными последствиями, и ваш код в конечном итоге будет переплетен с Pandas.

Из-за похожих проблем и ответа Матти Джона я написал _pandas_wrapper класс для своего проекта, потому что я также хотел наследовать от фрейма данных pandas.

https://github.com/mcocdawc/chemcoord/blob/bdfc186f54926ef356d0b4830959c51bb92d5583/src/chemcoord/_generic_classes/_pandas_wrapper.py

Единственная цель этого класса — создать аналогичный фрейм данных pandas, от которого безопасно наследовать.

Если ваш проект имеет лицензию LGPL, вы можете использовать его повторно без проблем.