Pythonに明示的なアクセス修飾子がないのはなぜですか：

「明示的が暗黙的よりも優れている」場合、Pythonには明示的アクセス修飾子がないのはなぜですか：Public、Protected、Privateなど？

プログラマーはヒントを通して何をすべきかを知っておくべきだという考えを知っています-「ブルートフォース」を使用する必要はありません。しかし、IMOの「カプセル化」または「情報隠蔽」は単に人を締め出すためだけではなく、組織と構造の問題です。物理層システムのように、開発レイヤーは明確に区切られたスコープと境界を自己定義する必要があります。

Pythonでアクセス制限が明示されているのではなく、それ以外の場合は完璧に近いと思われる言語について、なぜアクセス制限が暗黙的に含まれているのかについて、誰かがここで助けてくれますか？

編集：これまでに3つの提案された答えを見てきましたが、私の質問には2つの部分があることに気付きました。

1. たとえば、キーワードがないのはなぜですか

   private def myFunc(): 
       dostuff....

   IMOの代わりに、typeいアンダースコアを入力します。しかし、それは重要なポイントではありません。

2. さらに重要なことには：

   これらのアクセス修飾子が「推奨事項」またはヒントのみであり、強制されないのはなぜですか。後で変更するのは難しいでしょうか？「保護された」を「パブリック」に変更するのは非常に簡単です-複雑な継承チェーンがあり、それが難しくなると、デザインが貧弱になります-書きやすい言語機能に依存するのではなく、デザインを洗練する必要があります不十分な構造のコード。

   アクセス修飾子が適用されると、コードは自動的に区分化されます。特定のセグメントが範囲外であることを知っているので、必要な場合と必要な場合を除き、それらを処理する必要はありません。そして、あなたのデザインが良くなく、物事をさまざまな範囲に出し入れしていることに気付いた場合、言語はあなたの行為をきれいにするのに役立ちます。

Pythonが大好きなのと同じように、この2番目の点は深刻な欠陥であると感じています。そして、これに対する良い答えをまだ見ていません。

「明示的は暗黙的よりも優れている」は、Pythonの設計哲学における格言の1つにすぎません。「単純なものは複雑なものよりも優れています」もあります。また、PythonのZenには含まれていませんが、「ここにいる大人は全員同意しています」というのは別です。

ここで、2番目のルールがおそらく最も重要です。クラスを設計するとき、それがどのように使用されるかについていくつかの考えがあります。しかし、考えられるすべての用途を予測することはできません。それは可能私のコードのいくつかの将来の使用は、私がプライベートであると考えてきた変数へのアクセスを必要とすることになります。将来のプログラマー（または将来の私）がそれらを必要とする場合、なぜこれらにアクセスするのを難しくする必要があるのですか？最善の方法は、警告でマークすることです。Joonasが指摘しているように、単一のアンダースコアプレフィックスが標準であり、それらは内部であり、変更される可能性があります。しかし、アクセスを完全に禁止する必要はないようです。

アクセス修飾子が欠落している主な理由はシンプルであることを疑います

あなたが言うように、それは人々を締め出すことではなく、組織についてのものではないので、「プライベート」の主なポイントは、APIのユーザーにメッセージを送信することです「これに依存するコードを書かないでください」。

「慣例により、_xまたは__xをクラスの外部で使用すべきではありません」と言うのは簡単ですが、Pythonの動的オブジェクトモデルでは、表記法を考え出すことすら難しいでしょう。

class ActiveRow(object):
    def __init__(self, **kwargs):
        for name, value in kwargs.items():
            setattr(self, name, value)

アクセシビリティに注意する方法

これはトレードオフだったと思います。厳密にそれと一緒に暮らすことができない場合は、ルビをお勧めします。ルビは抽象化と動的性のレベルは似ていますが、アクセスの変更を可能にするオブジェクトモデルがあります。

Pythonの規則では、保護/プライベートメンバーにアンダースコアプレフィックスを使用します。

続くこの大会、1を除いて、アクセス修飾子として効果的に同じである）あなたが会員から直接表示されます名前、それは国民のかどうか、および2）あなたがすることができますあなたは本当に（これは正当可能にしたい場合は、「カプセル化」を破りますテストなど;他のいくつかの言語では、リフレクション==より多くのコードを使用する必要があります）。

最終的には好みの問題ですが、特別なキーワードなしで同じことを（もう少し柔軟に）できる場合、言語は小さくなり、コードはより簡潔になります。これは一般に良いことです。