Чем «is» отличается от «==» при использовании string?

по меркам PHP в питоне вообще нет граблей

белые люди используют in и hasattr

не учи плохому

Если тебя в детстве покусали кресты, то это еще не значит, что твою уродливую травму теперь надо пихать и в нормальные языки.

Если тебе прям горит - реализуй через метакласс и аннотации, но не надо выдавать это скрытное присваивание с синтаксисом от keyword argument за сколь-либо разумную идею.

Есть решение лучше в плане выразительности и совместимости?

hasattr в целом же делает вот буквально что спрашивали, только проверяет конкретный класс ошибки и оставляет код более читаемым, не загрязняя его постоянной ловлей ошибок в тексте функции.

hasattr(object, name)

The arguments are an object and a string. The result is True if the string is the name of one of the object’s attributes, False if not. (This is implemented by calling getattr(object, name) and seeing whether it raises an AttributeError or not.)

Да, разумеется, если задаче не собственно проверить наличие атрибута, то могут быть более эффективные пути решения, типа трёхаргументного getattr (или соответственно get для словаря).

Я бы не отказался от добавки. Например, какой-нибудь кракозабр в аргументах конструктора, чтобы эти аргументы сразу становились полями объекта:

Один момент, __init__ это не конструктор, это инициализатор уже созданного в __new__ объекта. Иначе откуда бы взялся self первым аргументом?

https://docs.quantifiedcode.com/python-anti-patterns/readability/asking_for_p...

Вот о чём я и говорю: я не видел всего кода.

Для исправления поведения если ошибка произошла при попытке получить атрибут - надо использовать except. Но, во-первых, в любом случае желательно иметь в except класс ожидаемой ошибки, а во-вторых, если исправление сводится к подстановке альтернативного значения - стоит использовать get/getattr.

Если же цель собственно состоит в проверке атрибута - то hasattr это как минимум не переписывание от руки кода, уже входящего в стандартную поставку.

Вопрос же ставился

для проверки атрибута или ключа

А не «для обработки ситуации отсутствия ключа».

Для исправления поведения если ошибка произошла при попытке получить атрибут - надо использовать except
если исправление сводится к подстановке альтернативного значения - стоит использовать get/getattr.
Если же цель собственно состоит в проверке атрибута - то hasattr

спору нет, ты со всех сторон прав

кстати, не могу понять, верна ли еще строка https://github.com/python/cpython/blob/f5e7b1999f46e592d42dfab51563ea5411946f...

раньше была: https://hg.python.org/cpython/file/77d24f51effc/Python/bltinmodule.c#l1051

Вопрос же ставился

для проверки атрибута или ключа

А не «для обработки ситуации отсутствия ключа».

и, заметь, не «для проверки наличия/отсутствия ключа». а это, как ты уже признал, единственный случай, когда стоит использовать hasattr. я и прибежал ругаться потому, что это не он.

кстати, не могу понять, верна ли еще строка https://github.com/python/cpython/blob/f5e7b1999f46e592d42dfab51563ea5411946f...

Ну в целом похоже верна с некоторым уточнением: она использует уже функцию на уровне C, которая содержит оптимизации для частных случаев https://github.com/python/cpython/blob/d852142cd728f45372ba6137bd87e29ba7b5b4...

В итоге has_attr возвращает False когда при поиске атрибута возникает AttributeError ИЛИ возникает ситуация, когда должна была бы возникнуть AttributeError (типа методы __getattr__ не прописаны, а в словаре нужного нет). То есть делается минимальная экономия на то, чтобы породить и загасить ошибку в очевидных случаях.

Это ещё один аргумент использовать системные функции, а не свои костыли, да: системные функции могут работать быстрее за счёт доступа к более низким уровням. В то же время да, это быстродействие должно быть принесено в пользу выразительности (если вы ищете высокой производительности микроптимизациями - Python не совсем тот язык, что вам нужен).

if (!PyErr_ExceptionMatches(PyExc_AttributeError)) {

а, вот оно где. спасибо.

если вы ищете высокой производительности микроптимизациями - Python не совсем тот язык, что вам нужен

если ускорять логику, то может еще и соглашусь. а вот для числодробилок Python в связке с Cython, numba, numexpr или всяким opencl уже почти полная годнота.