0

Python コードを書いている多くの GUI コントロールを使用するアプリケーションを書いているとします。各コントロールはクラスによって記述されます。これらのクラスをすべて と呼ばれるモジュールに集約したいと考えていますgui。ベテランの C/C++ 開発者として、次のようにクラスの実装をファイルごとに分離するのが最も理にかなっています。

gui/MainWindow.py
gui/Widget1.py
gui/Widget2.py

上記では、MainWindowクラスの仕様はMainWindow.py. ただし、この方法でファイルをレイアウトすると、これらのクラスを取得するための構文は次のようになります。

import gui
w = gui.MainWindow.MainWindow()

これは冗長に思えます。この制限を回避する方法は、次のように編集gui/__init__.pyすることです。

from gui.MainWindow import *
from gui.Widget1 import *
from gui.Widget2 import *

これにより、クラスがguiモジュールの名前空間に取り込まれます。その後、次のようにアクセスできます。

w = gui.MainWindow()

これは通常行われますか? コミュニティで適切と見なされるのに十分なPythonicityがありますか? 私が見ることができる1つの欠点はgui/__init__.py、モジュールに新しいサブモジュールを追加するときに、必ず保持する必要があることguiです。私はそのような手動のステップが好きではありません。

これに対処する方法についての考えや提案は素晴らしいでしょう。

4

2 に答える 2

2

インポートしないでください(競合が発生する可能性がないと確信*している場合を除きます。このルールはパッケージの作成者にとっては曲げられる可能性があります)。

于 2012-04-19T18:34:17.340 に答える
0

おそらく、以前にこれらの PEP とドキュメント サイトに注目したことがあるでしょう。

したがって、これに追加できる唯一のことは、使用しないことimport *です。一例:

>>> from pylab import *
>>> any(False for i in range(5))
True

あなたは自分が何をしているのかを知っていると正当に主張していますが。あなたのパッケージからの潜在的な再利用者のすべてが、import *彼らとあなたのコードの間の最終的な名前空間の障壁を取り壊している間、彼らがシャドーイングしているものを知っていると仮定することはできません. これにより厄介なエラーが発生します。以下も参照してください。

ユーザーが次のように書くとどうなるfrom sound.effects import *でしょうか? 理想的には、これが何らかの形でファイルシステムに送信され、パッケージに存在するサブモジュールを見つけて、それらすべてをインポートすることを期待するでしょう。これには長い時間がかかる可能性があり、サブモジュールをインポートすると、サブモジュールが明示的にインポートされた場合にのみ発生する望ましくない副作用が発生する可能性があります。ドキュメント

と

( import * はオプションではありません;-) PEP328

と

名前空間は素晴らしいアイデアの 1 つです。もっと多くのことをしましょう! PEP20

ただし、これらはガイドライン/推奨事項/個人的な好みにすぎず、これらが当てはまらない特殊なケースが確実に存在します。

于 2012-04-19T19:14:27.147 に答える