파이썬에 명시 적 액세스 수정자가없는 이유 :

'명시 적 묵시적보다 묵시적'인 경우 파이썬에 명시 적 액세스 수정자가없는 이유는 무엇입니까?

나는 프로그래머가 힌트를 통해 무엇을해야하는지 알아야한다는 것을 알고있다. '브 루트 포스'를 사용할 필요는 없다. 그러나 IMO '캡슐화'또는 '정보 숨기기'는 사람들을 막기위한 것이 아니라 조직과 구조의 문제입니다. 개발 계층에는 물리적 시스템과 마찬가지로 자체 정의되고 명확하게 구분 된 범위와 경계가 있어야합니다.

누군가가 완벽하게 가까운 것처럼 보이는 파이썬에서 명시 적으로 액세스 제한이 암시되지 않는 이유에 대한 확실한 설명으로 나를 도와 줄 수 있습니까?

편집 : 지금까지 3 개의 제안 된 답변을 보았으며 내 질문에 두 부분이 있음을 깨달았습니다.

1. 예를 들어 키워드가없는 이유

   private def myFunc(): 
       dostuff....

   IMO 대신 추악하고 입력하기 어려운 밑줄. 그러나 그것은 중요한 요점이 아닙니다.

2. 더 중요한 것은:

   이러한 액세스 수정자가 왜 '권장 사항'또는 힌트 일 뿐이며 적용되지 않는 이유는 무엇입니까? 나중에 변경하기 어려울까요? '보호 된'을 '공개'로 변경하는 것은 매우 간단합니다. 복잡한 상속 체인을 사용하여 어렵게 만들면 디자인이 나쁩니다. 쉽게 작성할 수있는 언어 기능에 의존하기보다는 디자인을 개선해야합니다. 잘못 구조화 된 코드.

   액세스 수정자가 적용되면 코드가 자동으로 구획화됩니다. 특정 세그먼트가 범위를 벗어 났음을 알고 필요한 경우와 필요한 경우를 제외하고는 처리하지 않아도됩니다. 그리고 디자인이 좋지 않고 끊임없이 다른 범위로 들어오고 나가는 것을 발견하면 언어가 행동을 정리하는 데 도움이 될 수 있습니다.

파이썬을 좋아하는 한이 두 번째 포인트가 심각한 결함이라는 것을 알았습니다. 그리고 나는 이것에 대한 좋은 대답을 아직 보지 못했습니다.

"명시적인 것이 묵시적인 것보다 낫다"는 것은 파이썬 디자인 철학의 최대치 중 하나 일뿐입니다. "복잡한 것보다 단순하다"도 있습니다. 그리고 그것은 파이썬의 선에 있지는 않지만 "우리 모두 여기에 동의하는 성인들"입니다.

이 두 번째 규칙은 아마도 여기서 가장 중요합니다. 수업을 디자인 할 때 수업 사용 방법에 대한 아이디어가 있습니다. 그러나 가능한 모든 용도를 예측할 수는 없습니다. 그것은 수 내 코드의 일부 미래의 사용이 나는 개인으로 간주 한 변수에 대한 액세스를 필요로합니다. 미래의 프로그래머 (또는 미래의 나)가 필요하다면 왜 이것에 액세스하기 어렵거나 불가능하게 만들어야합니까? 가장 좋은 방법은 Joonas가 지적한 것처럼 밑줄 접두어가 표준이며 내부에 있으며 변경 될 수 있다는 경고를 표시하는 것입니다. 그러나 액세스를 금지하는 것은 불필요 해 보입니다.

액세스 수정자가 누락 된 주된 이유는 단순성이라고 생각합니다.

당신이 말했듯이, 사람들을 조직화하는 것이 아니라 조직에 관한 것이기 때문에 '개인'의 주요 요점은 API 사용자에게 '이것에 의존하는 코드를 작성하지 마십시오'라는 메시지를 보내는 것입니다.

'컨벤션에 따라 _x 또는 __x는 클래스 외부에서 사용해서는 안됩니다.'라고 말하는 것은 쉽지 않지만 파이썬의 동적 객체 모델에서는 표기법을 찾기조차 어렵습니다.

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

접근성을 메모하는 방법?

나는 이것이 절충이라고 생각한다. 엄격하게 살 수 없다면 추상화 및 동적 수준은 비슷하지만 액세스 수정이 가능한 객체 모델이있는 루비를 제안합니다.

파이썬 규칙은 보호 / 개인 구성원에 밑줄 접두어를 사용하는 것입니다.

이 규칙은 1) 공개 여부에 상관없이 회원 이름 에서 직접 볼 수 있으며 2) 원한다면 "캡슐화"를 중단 할 수 있다는 점을 제외하고는 액세스 수정 자와 효과적으로 동일 합니다. 예를 들어 테스트; 다른 언어에서는 reflection == 더 많은 코드를 사용해야합니다).

궁극적으로 그것은 맛의 문제이지만, 특별한 키워드없이 동일한 일을 (좀 더 융통성있게) 할 수 있다면 언어가 작아지고 코드가 더 간결해질 것입니다. 이는 일반적으로 좋은 것입니다.