Простота и элегантность - это философские концепции, установленные для Python, когда основатель Python Гвидо Ван Россум (Дядя Черепаха) открыл горные ворота. Теперь разработка Pyton явно отклонилась от этого принципа: независимо от того, что полезно или нет, все другие домохозяйства имеют доход; независимо от того, подходит он или нет, если он может заполнить витрину, получить все это. Эта ситуация похожа на беспомощность, которую выразил Уэс МакКинни, отец Pandas, когда он столкнулся с быстрым распространением Pandas: «Pandas отклоняется от простоты и легкости использования, на которые я изначально ожидал, становясь все более и более раздутыми и неконтролируемыми».
Когда-то мне очень нравился Python. Сегодня эта любовь сохранилась, но она более спокойная и рациональная. За более чем десять лет компании, от неизвестности до популярности, Python наконец занял видное место в рейтинге программного обеспечения. В шторме расширения, охватившем индустрию программного обеспечения, в непрерывном обновлении версий Python я ясно увидел опасное изменение: Python меняется от простоты к раздуванию, от практичности к китчу.
Я долго терпел это, и сегодня я должен пожаловаться на новые языковые особенности Python. Ниже приведены десять основных слотов, вызывающих опасное вращение Python, без определенного порядка.
1. Статическая проверка типа Китч
Начиная с Py3.5 до последней версии Py3.9, я чувствую, что команда проекта языка Python занимается одним делом: проверкой статического типа. Чтобы добиться проверки типов, они запустили модуль набора текста и определили множество правил приложения. Соответственно, появился ряд инструментов проверки статического типа, таких как Mypy, Pylint или Pyflakes, и PyCharm также может хорошо интегрировать эти инструменты. В этой связи я просто хочу сказать: Python - это динамический язык, верно? Так как это динамический язык, то вы проверяете пряжу? Даже если проверка пройдет успешно, можно ли запустить его как скомпилированный язык? Все просто иллюзия, пожалуйста, не используйте концепции других языков, чтобы навредить простому Python. Python стремится решить проблему самым простым и удобным способом, а не создавать проблемы, а затем решать их. Сильный толчок Python к проверке статических типов заключается в том, чтобы обслуживать эти интегрированные среды разработки (IDE), одновременно удовлетворяя чувство выполненного долга и тщеславие программистов, которые не знают, что делать.
2. Объявление типа избыточной переменной
Что чувствует программист Python с 5-летним опытом работы, когда он читает следующий код?
>>> name: str
>>> age: int = 18
>>> gilrfriends: list = ['奥黛丽·赫本', '卡米拉·贝勒', '安吉丽娜·朱莉']
Я думаю, он скажет: "Боже, что это?" Это Python? Да, это действительно Python. Похоже, что тип переменной указан, но даже если строка используется для присвоения значения переменной, указанной как тип списка, как показано ниже, во время выполнения не будет выдано ни одного приглашения или предупреждения.
>>> gilrfriends: list = '奥黛丽·赫本, 卡米拉·贝勒, 安吉丽娜·朱莉' # 打着右转灯左转
>>> gilrfriends
'奥黛丽·赫本, 卡米拉·贝勒, 安吉丽娜·朱莉'
Видите ли, поверните налево с правым светофором, и движение по-прежнему нормальное. Какой толк от таких лишних операций? Оказалось, что это было сделано для того, чтобы IED или инструмент проверки типов знали тип переменной. Изначально инструменты предназначались для программистов, но теперь это хорошо, вы должны сначала обслужить инструменты. Отрицательные оценки!
3. Безвкусные аннотации к функциям и типам параметров
Я искал способ ограничить тип параметров функции, чтобы избежать непредвиденных ситуаций, когда программа работает. Ограниченный механизмом Python, в большинстве случаев я могу использовать утверждения только для ограничения типов параметров внутри функции, и в то же время как можно больше для подробного описания типов и значений параметров в документе , как и код ниже.
def sphere(center, radius, color, slices=90):
"""绘制球体
center - 球心坐标，长度为3的元组或列表
radius - 半径，浮点型
color - 顶点颜色，字符串
slices - 球面分片数（数值越大越精细），整型
"""
assert isinstance(center, (tuple, list)) and len(center)==3, '期望参数center是长度为3的元组或列表'
print('Hello')
return True
Теперь, если вы последуете подходу, предложенному руководящим комитетом Python, приведенный выше код должен быть написан следующим образом.
from typing import Union
def sphere(center:Union[tuple,list], radius:float, color:str, slices:int=90) -> bool:
"""绘制球体
center - 球心坐标，长度为3的元组或列表
radius - 半径，浮点型
color - 顶点颜色，字符串
slices - 球面分片数（数值越大越精细），整型
"""
print('Hello')
return True
Вроде все идеально, но результат достойный сожаления. Аннотации типа этой функции и параметра - это просто аннотация, она бесполезна: независимо от того, какой тип параметра вы вводите, если число равно 3 или 4, его можно выполнить. Единственный эффект - снижение читабельности кода. Четыре исходных параметра можно увидеть с первого взгляда, но теперь для идентификации требуется 20 секунд. Не будет ни проверки типа (если не используется инструмент проверки типа), ни проверки длины. Если вам нужны эти функции, вы должны полагаться на себя.
4. Оператор неограниченного распространения
Любой язык программирования постоянно обновляется и расширяется, и Python не исключение. Честно говоря, некоторые грамматические расширения Python все еще очень тонкие и необходимые, например, оператор моржа (: =), представленный в Py3.8, который является типичным примером. До введения оператора моржа, если вы хотите использовать # для заполнения строки длиной менее 16 бит 16 битами (если она больше или равна 16 битам, она будет выводиться как есть), обычно пишется следующим образом.
>>> s = 'Hello Wold'
>>> s + '#'*(16-len(s)) if len(s) < 16 else s
'Hello Wold######'
Этот код дважды вычисляет длину строки s. Очевидно, что это неэффективный код. Но использование временной переменной для хранения длины строки s недостаточно элегантно. Морж-оператор был создан для решения подобных задач.
>>> s = 'Hello Wold'
>>> s + '#'*(16-c) if (c:=len(s)) < 16 else s
'Hello Wold######'
К сожалению, не все расширения так красивы, как оператор моржа, и даже большая часть из них не показывает достаточной необходимости и незаменимости, а только вносит еще большую путаницу в программистов. Например, новые операторы слияния (|) и обновления (| =) словаря в Py3.9 принадлежат этому столбцу.
>>> a = {'x':1, 'y':2}
>>> b = {'y':3, 'z':4}
>>> a | b # 返回一个新的字典
{'x': 1, 'y': 3, 'z': 4}
>>> a |= b # 将b合并到a中
>>> a
{'x': 1, 'y': 3, 'z': 4}
Люди, которые серьезно подозревают, что команда Python забыла, что в словаре также есть метод update (), который может реализовать функции этих двух новых операторов.
>>> a = {'x':1, 'y':2}
>>> b = {'y':3, 'z':4}
>>> a.update(b)
>>> a
{'x': 1, 'y': 3, 'z': 4}
Некоторые люди могут сказать, что даже если оператор обновления словаря (| =) и update () полностью перекрываются, оператор слияния словарей (|) возвращает новый словарь, а update () изменяет исходный словарь. Тем, кто придерживается такого взгляда, могу лишь тихо напомнить, что у Python есть решение для этого.
>>> {**a, **b}
{'x': 1, 'y': 3, 'z': 4}
5. Метод строки символов 濎 俎 代庖
Большое количество встроенных функций или методов может принести больше удобства программистам, но они также могут раздуть систему, увеличить сложность ввода и сделать кривую обучения крутой. Как уравновесить эту шкалу - вопрос личного мнения. На мой взгляд, постоянное добавление функций и методов не только нарушает первоначальный замысел Python, разрушает стабильность API, но также заставляет программистов терять выбор и веселье. Например, Py3.9 добавил removeprefix () и removeuffix () для объекта str, которые используются для удаления префикса и суффикса строки соответственно.
>>> s = '[主播]上港获得前场任意球(1:1)'
>>> s.removeprefix('[主播]')
'上港获得前场任意球(1:1)'
>>> s.removesuffix('(1:1)')
'[主播]上港获得前场任意球'
Существует много похожих требований к приложениям.Если они будут добавлены в библиотеку методов объекта str, объект str станет очень большим. Очевидно, что написание таких функций должно быть оставлено на усмотрение программиста.Команде проекта языка Python нужно уделять внимание только основным и основным методам. Фактически, реализация этих двух методов - это всего лишь одна строка кода.
>>> s = '[主播]上港获得前场任意球(1:1)'
>>> s if s.find('[主播]') < 0 else s[len('[主播]'):]
'上港获得前场任意球(1:1)'
>>> s if (n:=s.rfind('(1:1)')) < 0 else s[:n]
'[主播]上港获得前场任意球'
6. Нелепый строковый префикс.
В эпоху Py2 наиболее распространенным строковым префиксом является u. В эпоху Py3 префикс u исчез, а b стал наиболее распространенным строковым префиксом. Будь то Py2 или Py3, нативный строковый префикс r является привычным клиентом в глазах программистов Python. Начиная с Py3.6, внезапно появился новый строковый префикс.
>>> score = '1:1'
>>> f'当前比分{score}'
'当前比分1:1'
Предыдущий префикс был просто логотипом, но теперь префикс f стал оператором, и кажется, что чудесный мир рациональности мгновенно рухнул! Однако это только начало, и в версии Py3.8 произошло еще хуже, они фактически добавили поддержку знака равенства (=) к префиксу f.
>>> 语文=95
>>> 数学=100
>>> f'{语文=}，{数学=}'
'语文=95，数学=100'
MyGod, где код, это волшебная руна! Честно говоря, при форматировании строк, кроме% в стиле C, я даже не использовал функцию format (), но теперь мне, возможно, придется столкнуться с кодом, написанным моими коллегами, который содержит расширенный префикс f. Печально меня, я могу только улыбаться.
7. Нелогический порядок словаря
Когда был выпущен Py3.6, люди повсюду рекламировали, что словарь в порядке. Сначала я подумал, что это не более чем любопытная цель СМИ, вскользь говоря, привлечь внимание. Логически словарь - это неупорядоченный набор данных, который полагается только на извлечение ключа. Если словарь упорядочен, это не словарь. Неожиданно Py3.7 официально объявил о новой функции «Dictionary Keep Insertion Order». К счастью, чиновник сказал, что «словарь поддерживает порядок вставки», а не «словарь в порядке», и, наконец, зарезервировал последние трусики для логики.
Когда я говорю, что словарь неупорядочен, я не имею в виду, что словарь действительно неупорядочен, когда он реализован на физическом объекте, но что его порядок не четко определен для пользователей и не может использоваться в качестве функции данных. Возможно, Py3.7 использует новый механизм для более эффективного хранения и извлечения данных словаря, но программиста это не беспокоит. Стабильность словарного порядка, вызванная новым механизмом, не может быть атрибутом словаря, которому мы можем доверять и использовать.
8. Квалификаторы параметров функций во избежание хаоса.
Что касается определения функций и передачи параметров, я боюсь, что нет языка более гибкого, чем Python. В то же время удобство, позиционные параметры, параметры по умолчанию, параметры переменных, параметры ключевых слов и другие типы параметров и порядок использования также принесли программистам много путаницы. Однако Py3.8 твердо убежден, что использование параметров функции недостаточно хаотично, и его необходимо стимулировать снова, чтобы достичь цели перехода от хаоса к лечению. Итак, на сцене появился квалификатор параметра функции - чтобы усилить эффект, Python официально выбрал косую черту (/) в качестве проявления этого квалификатора.
Попробуем вместе прочитать следующий код.
>>> def func(a, b, /, c, d, *, e, f):
print('OK')
>>> func(1,2,3,4,e=5,f=6)
OK
>>> func(1,2,3,d=4,e=5,f=6)
OK
Здесь a и b - позиционные параметры, e и f - параметры ключевого слова, а c и d могут быть позиционными параметрами или параметрами ключевого слова. Хорошо, так много о квалификаторах параметров функций, они вам все равно не нужны - если только вы не используете функции Python для полной имитации функций, написанных в коде C.
9. Общие функции без элегантности
Когда дело доходит до дженериков, программисты на Python обычно используют два выражения: одно удивляется: «Есть ли в Python универсальные типы?»; Другое ухмыляется: «Является ли Python типом?» И не обсуждает, является ли Python «типом», «как» динамический язык, разве общий тип не является врожденным? Может быть, команда Python так не думает, или они думают, что программисты Python так не думают. Чтобы занять первое место в рейтинге языков программирования, начиная с Py3.4, команда Python настроила общий декоратор функций для Python. К сожалению, этот механизм слишком надуман, а код, написанный с его помощью, уродлив, и, по оценкам, мало кто будет его использовать.
>>> from functools import singledispatch
>>> @singledispatch
def say_hello(x):
print('抱歉，我不认识你')
>>> @say_hello.register(int)
def _(x):
print('你好，整数')
>>> @say_hello.register(str)
def _(x):
print('你好，字符串')
>>> say_hello(5)
你好，整数
>>> say_hello('abc')
你好，字符串
>>> say_hello([1,2,3])
抱歉，我不认识你
Приведенная выше куча кодов просто определяет функцию say_hello (), которая может реагировать по-разному в зависимости от типа входного параметра. Если вы не используете универсальные декораторы, реализация будет проще и удобнее для чтения.
>>> def say_hello(x):
if isinstance(x, int):
print('你好，整数')
elif isinstance(x, str):
print('你好，字符串')
else:
print('抱歉，我不认识你')
>>> say_hello(5)
你好，整数
>>> say_hello('abc')
你好，字符串
>>> say_hello([1,2,3])
抱歉，我不认识你
10. Пощечины до и после
Когда я впервые прочитал «typing.List» и «typing.Dict» на короткое время, мне показалось, что я читаю код Java или C ++. Почему не знакомый список и диктант? Просто для подсказок типа, чтобы интегрированный инструмент разработки понимал код, я придумал более сложные концепции, чем списки и словари. Конечным результатом является то, что среда IDE может читать код, а программист - нет.
К счастью, Py3.9 улучшил подсказки типов и обеспечивает общую поддержку подсказок типов для встроенных и стандартных библиотечных типов коллекций. Это решает проблему, связанную с тем, что в коде Python всегда будет два списка (list и typing.List) ) типа смущения, это можно рассматривать как средство правовой защиты.
Я по-прежнему хочу порекомендовать группу обучения Python, которую я создал сам : 721195303 , все они изучают Python. Если вы хотите изучить или изучаете Python, вы можете присоединиться. вовремя (только для разработки программного обеспечения на Python), включая копию последних расширенных материалов по Python и обучение с нуля, составленное мной в 2021 году. Добро пожаловать, друзья, которые продвинуты и заинтересованы в Python, присоединяйтесь!
Рори написал так много, я надеюсь, что это не разочарует программистов на Python. Фактически, как бы я или мы ни жаловались, Python по-прежнему остается отличным языком программирования. Взгляды в этой статье - это всего лишь мои личные взгляды как фундаменталиста, с небольшим количеством насмешек. Вы можете высказать свое мнение, не обращайте внимания на мое лицо. Я буду притворяться невидимым без объяснений и споров. Пожалуйста, обойди.