Какие бывают расширяемые архитектуры приложения на Python (ООП)?

Question

[Mike Evstropov]

К чему я шел, вот каталог:

- - cgi-bin
- - | - - a.py
- - | - - a
- - | - - | - - __init__.py
- - | - - | - - b.py
- - | - - | - - b
- - | - - | - - | - - __init__.py
- - | - - | - - | - - c.py
- - | - - | - - | - - c
. . .

Мне было бы удобно получать доступ к доступ к дочерним классам по аналогу вызова свойства.
То есть, класс «a» в файле «a.py» -

class a:
	prop = 5

и в другом пакете под именем «a», в файле «b.py» класс «b»

class b (a):
	prop = 7

после импорта, удобно было бы обращаться к классу и его свойству так:

a.prop
a.b.prop
# 5
# 7

Расширяемо? Да.
Но, так как импорт в первую очередь ищет пакет, у меня не получается загрузить модуль «b».
Если есть что-то более удобное и расширяемое, прошу привести пример.
А если мой вариант имеет правильное направление, то как его сделать рабочим?
Спасибо!

Comments

[sim3x]

используй tree для показа дерева директорий

[Mike Evstropov]

на винде в cmd он не показывает файлы, только папки почему-то...

Answer 1

[Владимир]

просто плачу ! перл :)

Comments

[Mike Evstropov]

Информативно...

Answer 2

[angru]

чепуха какая-то.

import a

что будет импортировано, модуль а или пакет а? как интерпретатор узнает что вы от него хотите?

Comments

[Mike Evstropov]

Вы не догадались, что это и был один из вопросов? "у меня не получается загрузить модуль, так как импорт в первую очередь ищет пакет" Что именно вам непонятно?

[angru]

Mike Evstropov: я как-то на фразе "расширяемо? да" получил слишком много эмоций и сразу написал ответ. у вас получается родительский класс должен знать о дочерних, это мягко говоря странно. вложенность задом наперед выходит: a(b(c)), а обычно c(b(a))

[angru]

как вариант можно делать каркас с базовыми классами в пакете lib/core/common/что-то_другое, а дочерние классы располагать на уровень выше, может в отдельных пакетах, и импортировать из ядра базовые классы