Чому в Python немає явних модифікаторів доступу:

Якщо "явний кращий за неявний", чому в Python немає явних модифікаторів доступу: Public, Protected, Private тощо?

Я знаю, що ідея полягає в тому, що програміст повинен знати, що робити через підказку - не потрібно використовувати «грубу силу». Але "Інкапсуляція" або "приховування інформації" ІМО - це не лише для того, щоб уникнути людей, це питання організації та структури: ваші шари розвитку повинні мати чітко визначені сфери та межі, як і фізичні системи.

Чи може хтось, будь ласка, допомогти мені тут, чітко пояснивши, чому обмеження доступу мають на увазі, а не явні в Python, мові, яка в іншому випадку здається близькою до ідеальної?

Редагувати: Поки я бачив 3 запропонованих відповіді, і зрозумів, що на моє запитання є 2 частини:

1. Чому, наприклад, немає ключових слів

   private def myFunc(): 
       dostuff....
   

   замість IMO підкреслюють потворні та важкі підкреслення. Але це не важливий момент.

2. Що ще більш важливо:

   Чому ці модифікатори доступу є лише «рекомендаціями» або підказками, а не застосовуються. Це буде важко змінити пізніше? Дуже просто змінити "захищений" на "публічний" - і якщо у вас є складний ланцюжок успадкування, який ускладнює, ви маєте поганий дизайн - ваш дизайн повинен бути вдосконалений, а не покладатися на мовну особливість, яка дозволяє легко писати погано структурований код.

   Коли застосовуються модифікатори доступу, ваш код автоматично розподіляється - ви знаєте, що певні сегменти виходять за межі сфери, тому вам не доведеться з ними боротися, за винятком випадків, коли це потрібно. І якщо ваш дизайн не є корисним, і ви виявляєте, що постійно переміщуєте речі в різні сфери, мова може допомогти вам очистити свій вчинок.

Наскільки я люблю Python, я вважаю цей другий момент серйозним недоліком. І я ще не бачив гарної відповіді на це.

"Явне краще, ніж неявне" - лише одна із сентенцій філософії дизайну Python. "Просте - краще, ніж складне". І хоча це не в дзен Питона, "Всі ми згодні на дорослих тут" - це інша.

Це друге правило, мабуть, найважливіше тут. Коли я проектую клас, я маю деяке уявлення про те, як його використовуватимуть. Але я не можу передбачити всіх можливих застосувань. Це може бути , деякі використовують майбутнє мого коду потрібен доступ до змінних я думав , як приватні. Чому я повинен зробити це важким - або навіть неможливим - отримати доступ до них, якщо майбутній програміст (або навіть майбутній я) потребує їх? Найкраще зробити це позначити їх попередженням - як зазначає Йоонас, єдиний префікс підкреслення є стандартним - про те, що вони є внутрішніми і можуть змінюватися; але заборона доступу взагалі видається непотрібною.

Я б підозрював, що основною причиною відсутності модифікаторів доступу є простота

Як ви говорите, справа не в тому, щоб утримувати людей, а не про організацію, тому головним моментом "приватного" є те, що він надсилає повідомлення користувачам вашої програми "будь ласка, не пишіть код, який залежить від цього".

Тривіально сказати: "за умовами, _x або __x не слід використовувати поза класом", але в динамічній об'єктній моделі python важко навіть придумати нотацію.

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

як відзначити доступність?

Я здогадуюсь, це була торгівля. Якщо ви категорично не можете з цим жити, я б запропонував рубін, який має аналогічний рівень абстракції та динамічності, але має об'єктну модель, яка дозволяє змінювати доступ.

Конвенція Python полягає у використанні приставки підкреслення для захищених / приватних членів.

Ця угода, якщо за ним слід, фактично такий же , як модифікатори доступу, за винятком 1) ви будете бачити безпосередньо від учасника імені , будь то державні чи ні, і 2) ви можете зламати «інкапсуляція» , якщо ви дійсно хочете (це може бути виправдано напр. тестування; в деяких інших мовах вам доведеться використовувати віддзеркалення == більше коду).

Зрештою, це питання смаку, але якщо ви можете зробити те ж саме (з трохи більшою гнучкістю) без спеціальних ключових слів, мова буде меншою, а код буде більш лаконічним, що, як правило, добре.