2009-11-23 3 views
7

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

  • Как выглядит внешний вид приложения Python?

    В настоящее время у меня есть:

     
    setup.py 
    application_name/ 
        __main__.py 
        __init__.py 
        views/ 
        controllers/ 
        model/ 
        resources/ <- images, videos, ... 
    
  • Как один запустить приложение?

    У меня бегуна скрипт со следующим содержанием

    #!/usr/bin/env python -m "application_name" 
    

    Если один даже использовать __main__.py для этой цели? Требуется ли скрипт бегуна?

  • Как следует импортировать части приложения? (Python 2,6)

    Например, в application_name/__main__.py

    from . import controllers.MainWindow 
    

Как вы макет вашего приложения?

+1

Дубликат: http://stackoverflow.com/questions/171785/how-do-you-organize-python-modules, http://stackoverflow.com/questions/ 527919/how-to-correct-organiz-a-package-module-dependency-tree, http://stackoverflow.com/questions/501945/how-to-modularize-a-python-application –

ответ

5

Есть несколько частей к этому вопросу, поэтому я постараюсь ответить на них, в свою очереди:

1: Его действительно до вас, есть не негибкие правила, кроме тех, для установления того, что каталог следует рассматривать как package и так далее. Некоторые структуры предписывают структуру каталогов, используя скрипт для создания лесов (немного похоже на Rails в мире Ruby), но это просто удобство или соглашение данной структуры. Организуйте свой код и модули, чтобы они имели смысл логически, как и на любом другом языке.

2: То, что у вас есть, абсолютно прекрасное. В качестве альтернативы вы можете использовать installed script, если вы используете distutils, console_script как часть установки .egg, или, в крайнем случае, просто вызовите скрипт main.py (или что бы вы там назвали) напрямую. Например, console_script довольно распространен и используется такими инструментами, как, например, платформа тестирования nose.

3: Для этой конкретной темы есть PEP. В моем опыте, хотя вы действительно должны предпочесть абсолютный импорт в относительные. Для того, чтобы заставить это поведение, которое вы можете сделать:

from __future__ import absolute_import 
+0

Что относительно явного относительного импорта? 'от. импортировать подпакет'? Меня немного беспокоит, что абсолютный импорт прерывается, когда я перемещаю некоторые пакеты или переименовываю их. –

+0

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

+0

gs: Python довольно предписывает во многих местах, например PEP8, который определяет правильный стиль использования! (Программисты C НИЧЕГО это ...) PEP, с которым я связан, пытается прояснить ситуацию с импортом, но в том, что касается макета проекта, который трудно законодательно закрепить. В рамках данной структуры да, но в остальном она открыта для обсуждения. Лучше всего прочитать много кода и посмотреть, что вам нравится. – jkp

Смежные вопросы