При этом, что поразительно: что штатная версия, что ad-hoc патч, что заплатка в PR защищают только и исключительно .name и .value. Установить в рантайме произвольное свойство члена перечисления (даже такое, которое заявлено как часть типа этого перечисления, то есть, устанавливается при инициализации членов перечисления) — не проблема.
То, о чём вы говорите применимо абсолютно к любому объекту, объявленному в питоне, в том числе и к енумам в вашей реализации. Это просто факт и неотъемлемая часть языка, и я не вижу в этом особой проблемы. У нас есть средства, которые позволяют ограничить непреднамеренное изменение свойств, и как мне кажется этого достаточно.
Есть лишь возможность защититься от непредполагаемых свойств с помощью __slots__, но это невозможно, если миксин-класс имеет ненулевой __itemsize__ (как, например, int).
Это как раз не решает проблему переопределения существующих атрибутов. Да и добавление новых тоже, кстати. Как я сказал выше — всё можно «пропатчить и заапдейтить» :)
Еще хотел бы прояснить отдельно момент: зачем в тестах производительности оценивается dir()?
Я начал заниматься этим патчем задолго до того, как увидел Вашу реализацию и тогда тестировал разницу с реализацией discordpy.enum, которая обещала иметь такое же api, как встроенный enum. Так что изначально оно там больше для демонстрации разного набора атрибутов.
В любом случае, спасибо за проделанную работу.
Приятно слышать, спасибо и вам что смотивировали её закончить :)
(и, надеюсь, разошлют бекпорт-мерджи в 3.6 и 3.7)
Было бы здорово. Можете написать об этом в issue или PR.
Посмотрите enum.EnumMeta.__getattr__. Это то самое место, избежав использования которого мы ускорили доступ к члену перечисления в три раза.
Я знаю, за счёт чего вы достигли такую скорость. Только вопрос был про заглавные атрибуты, и я не вижу связи между удалением __getattr__ и необходимостью писать всё с большой буквы.
Только, если можно, сразу в виде PR сюда и ссылкой в это обсуждение. Спасибо.
(код отличается от PR, т. к. решил выкинуть вещи, связанные с поддержкой Python <3.6 и DynamicClassAttribute. Наверное всё же приведу к одному виду с PR, как будет время)
TOTAL TIME:
PatchedEnum : 6.602916 seconds in total, 0.274735 average (Fastest)
BuiltinEnum : 13.805300 seconds in total, 0.548496 average, slower than PatchedEnum by x 1.996453 (in average)
QratorEnum : 29.979191 seconds in total, 0.336723 average, slower than PatchedEnum by x 1.225629 (in average)
...
Общее время в целых 29.979191 секунд получилось из-за очень медленного dir(QratorEnum), так что сморите лучше на средние показатели скорости.
Посмотрел код, посравнивал со встроенным енумом — имхо, очень сырая имплементация получилась.
Колоссальные отличия в апи от встроенного енума и полное отсутсвие обратной совместимости, ничем немотивированная необходимость использования заглавных имён, отсутствие поддержки наследование от других типов, например, IntEnum.
Пропатчив стандартный Enum можно получить сопоставимые результаты по скорости, сохранив при этом полную совместимость с существующим кодом (выложу как-нибудь такой патч).
Исходя из вышесказанного, я совершенно не понимаю зачем нужна штука, описанная в посте.
Upd. коммент написал до обсуждения с iroln, только сейчас прошел модерацию. Вижу что вроде как добавилась поддержка миксинов, но остальные вопросы остались.
То, о чём вы говорите применимо абсолютно к любому объекту, объявленному в питоне, в том числе и к енумам в вашей реализации. Это просто факт и неотъемлемая часть языка, и я не вижу в этом особой проблемы. У нас есть средства, которые позволяют ограничить непреднамеренное изменение свойств, и как мне кажется этого достаточно.
Это как раз не решает проблему переопределения существующих атрибутов. Да и добавление новых тоже, кстати. Как я сказал выше — всё можно «пропатчить и заапдейтить» :)
Я начал заниматься этим патчем задолго до того, как увидел Вашу реализацию и тогда тестировал разницу с реализацией
discordpy.enum, которая обещала иметь такое же api, как встроенный enum. Так что изначально оно там больше для демонстрации разного набора атрибутов.Приятно слышать, спасибо и вам что смотивировали её закончить :)
Я знаю, за счёт чего вы достигли такую скорость. Только вопрос был про заглавные атрибуты, и я не вижу связи между удалением
__getattr__и необходимостью писать всё с большой буквы.Хотите PR? Он есть у меня :)
bpo-39102: Increase Enum performance up to 10x times (3x average) #17669 (https://github.com/python/cpython/pull/17669)
Попробовать патч на python можно установив этот пакет: https://github.com/MrMrRobat/fastenum
(код отличается от PR, т. к. решил выкинуть вещи, связанные с поддержкой Python <3.6 и DynamicClassAttribute. Наверное всё же приведу к одному виду с PR, как будет время)
Вот результаты бенчмарка моего патча: (https://github.com/MrMrRobat/fastenum/tree/master/benchmark):
Общее время в целых 29.979191 секунд получилось из-за очень медленного dir(QratorEnum), так что сморите лучше на средние показатели скорости.
Посмотрел код, посравнивал со встроенным енумом — имхо, очень сырая имплементация получилась.
Колоссальные отличия в апи от встроенного енума и полное отсутсвие обратной совместимости, ничем немотивированная необходимость использования заглавных имён, отсутствие поддержки наследование от других типов, например, IntEnum.
Пропатчив стандартный Enum можно получить сопоставимые результаты по скорости, сохранив при этом полную совместимость с существующим кодом (выложу как-нибудь такой патч).
Исходя из вышесказанного, я совершенно не понимаю зачем нужна штука, описанная в посте.
Upd. коммент написал до обсуждения с iroln, только сейчас прошел модерацию. Вижу что вроде как добавилась поддержка миксинов, но остальные вопросы остались.