Считается ли Pythonic иметь несколько классов, определенных в одном файле?

Работая с python впервые, я обнаружил, что в итоге я пишу несколько классов в одном файле, в отличие от других языков, таких как Java, которые используют один файл на класс.

Обычно эти классы состоят из 1 абстрактного базового класса с 1-2 конкретными реализациями, использование которых незначительно отличается. Я разместил один такой файл ниже:

class Logger(object):

    def __init__(self, path, fileName):
        self.logFile = open(path + '/' + filename, 'w+')
        self.logFile.seek(0, 2)

    def log(self, stringtoLog):
        self.logFile.write(stringToLog)

    def __del__(self):
        self.logFile.close()

class TestLogger(Logger):   

    def __init__(self, serialNumber):
        Logger.__init__('/tests/ModuleName', serialNumber):

    def readStatusLine(self):
        self.logFile.seek(0,0)
        statusLine = self.logFile.readLine()
        self.logFile.seek(0,2)
        return StatusLine

    def modifyStatusLine(self, newStatusLine):
        self.logFile.seek(0,0)
        self.logFile.write(newStatusLine)
        self.logFile.seek(0,2)

class GenericLogger(Logger):

    def __init__(self, fileName):
        Logger.__init__('/tests/GPIO', fileName):

    def logGPIOError(self, errorCode):
        self.logFile.write(str(errorCode))

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

Вопрос: это стандарт для python или для любого языка? Какие проблемы могут возникнуть при использовании этой реализации, если таковые имеются?

РЕДАКТИРОВАТЬ: Я на самом деле не ищу руководство по этому конкретному файлу, но в более общем смысле. Что делать, если занятия заканчиваются 3-5 умеренно сложными методами? Есть ли смысл разделять их тогда? Где отсечка, чтобы сказать, что вы должны разбить файл?

Все хорошо. Это хорошо в C ++, для справки.

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

Некоторые практические правила:

1. Размер

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

2. Разделение проблем

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

   Таким образом, иногда может быть разумным считать, что связь подклассов с их зависимостями перевешивает их связь с интерфейсом (или, наоборот, проблема реализации интерфейса слабее, чем проблема внутренней реализации).

   В качестве конкретного примера возьмем общий интерфейс базы данных. Конкретные реализации, использующие БД в памяти, СУБД SQL и веб-запрос соответственно, могут не иметь ничего общего, кроме интерфейса, и принуждать всех, кто хочет, чтобы облегченная версия в памяти также импортировала библиотеку SQL, было противно.

3. Инкапсуляция

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

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

Мои обычные справочные документы, чтобы знать, что такое pythonic.

Простое лучше, чем сложное.

Квартира лучше, чем вложенная.

Из дзен питона

Почти без исключения имена классов используют соглашение CapWords.

Имена пакетов и модулей Модули должны иметь короткие, строчные имена. [...] Имена модулей сопоставляются с именами файлов

Из пп 8

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

То, что у вас есть сейчас, прекрасно. Пойдите и просмотрите стандартную библиотеку - в одном файле есть множество модулей с несколькими связанными классами. В какой-то момент все становится больше, и вы в конечном итоге захотите начать использовать модули с несколькими файлами, но нет никаких реальных правил относительно того, когда. Вещи просто разделяются, когда один файл начинает чувствовать себя «слишком большим».

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

Короче - черт возьми, да.

Более того, наличие нескольких классов в одном файле иногда очень удобно. Некоторые пакеты ( six, bottle) явно поставляются в одном файле, чтобы их можно было легко интегрировать в любой сторонний модуль без установки pip (иногда желательно). Но убедитесь, что ваш код организован хорошо. Интенсивно используйте комментарии кода и разделительные блоки, чтобы сделать его более читабельным.