В Питоне появится стандартный тип Enum

В новости, на главную!

Гуд, это полезное дело.

Здорово что уж говорить.

Этого до сих пор не было?!

И без этого обходились. Вроде просто переменную объявляли.

from enum import Enum

ilold

Обойтись можно много без чего...

Хорошо хоть не

from if import If

Ну а, собственно, нужен ли он там? Это при компиляции есть разница между enum и просто переменной.

Читабельность.

Enum - не просто пространство имён для констант, см. тут.

Ну объявляем

red = 1
blue = 2

func(red)
func(blue)

Чем не читабельно?

Ну это специфично для сабжевого питоновского enum. А тут возмущаются, что его там не было, хотя во многих других языках (C, например) он есть. Ну вот я и задаю вопрос, какие преимущества у c-шного enum перед тем, как обходятся без enum в Python, учитывая отличия языка Python от C (динамическая типизация, интерпретация вместо компиляции)?

Преимущества сабжевого енума перед портянкой переменных: свой неймспейс, уход от семантики чисел (Color.red + Color.blue будет не 3, а type error).

Python-Version: 3.4

нда, чую совсем скоро обилие подобных ништяков сподвигнут меня уйти с 2.7

Не понял, зачем? Есть же словарь?

Словарь - изменяемый.

там еще до сих пор нет Switch

Вот switch в python не нужен, нужен match.

можно закастомить http://svn.colorstudy.com/home/ianb/recipes/patmatch.py (а вообще Гвидо долго еще наверно не запилит вменяемый pattern matching)

А в C нет begin и end и writeln() :)

Минорная новость. Я уже десяток enum навелосипедил для разных нужд...

Отличная новостЬ! Хотя можно было и без этого обходиться.

зачем enum когда есть списки, коллекции или на худой конец массивы?

Читать документ лень. Там просто стандартный модуль одобрили или есть что-то, что требует поддержки от интерпретатора? Или есть реализация модулем для старых версий + специальные оптимизации для рантайма?

фигня какая-то, лучше бы из будущего C++ Concepts срисовали.

Было бы хорошо. Недавно ознакомился с вариантом в erlang'e, очень понравилось. Ещё бы в coffeescript добавили.

Это издевательство, а не pattern matching.

Ну наконец-то

И без него было отлично. Не хватает pattern matching и средств вроде dialyzer

Хорошо хоть не
from if import If

from import import from

import re?

Есть же словарь?

Словарь - изменяемый.

Есть кортежи.

А вот этого там до сих пор нету:
http://stackoverflow.com/questions/10032788/partial-regex-matching-in-python-3-2
А в java есть:
http://stackoverflow.com/questions/2526756/can-java-util-regex-pattern-do-par...

Это совсем не то.

Еще итерация поддерживается:

Enumerations support iteration, in definition order:

>>> class Shake(Enum):
...   vanilla = 7
...   chocolate = 4
...   cookies = 9
...   mint = 3
...
>>> for shake in Shake:
...   print(shake)
...
Shake.vanilla
Shake.chocolate
Shake.cookies
Shake.mint

Есть кортежи.

К элементам кортежа не обратиться по имени, только по индексу.

К элементам кортежа не обратиться по имени, только по индексу.

Ну и что? Это влияет на что нибудь, кроме красоты кода?

ехал import через....

Это влияет на что нибудь, кроме красоты кода?

Ну, привет! Я бы понял ещё, если бы вы сказали это про словари, мол, пишите [«name»] и не меняйте значения. Но индексы вместо имён - просто взять и впустить в код magic numbers. Дальше будет совет писать спагетти-код?

Или вы предложите на каждый индекс определить константу? Которых в python нет. И которые можно прикрутить сбоку каким-нибудь подобным методом и... Эй, минутку! :)))

И что?

В js тоже ещё нет.

Но индексы вместо имён - просто взять и впустить в код magic numbers

Ага. А потом сиди и разбирайся что такое, например, const[36].

А зачем оно в скриптовом языке нужно? Еще скажите, что ощутимо влияет на скорость работы.

Тред не читал, но считаю своим долгом сказать «В этом вашем питоне что, даже Enum небыло?»

Это просто революция в области ЯП

это уже ушло от темы но вообще-то для этого есть 2 варианта

from collections import namedtuple

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

например

class rec:
    pass

a = rec()
a.pole1 = 100
a.pole2 = 200

у меня сейчас класс не пустой - есть несколько методов для упрощения создания, присваивания и т.д. в частности, вышенаписанное можно написать как a = rec(pole1=100, pole2=200).

Этот метод хорош для динамической типизации (ибо не надо заранее определять что будет содержать «структура», а также объекты являются mutable в отличие от тупля) но плох тем, что каждый такой объект занимает больше места, чем тупль (т.к. словарь за собой тащит), поэтому если надо хранить большой массив элементов то лучше использовать вариант namedtuple - там на каждый экземпляр памяти надо столько же сколько и на простой тупль.

Но вообще везде где мне бы пришлось запоминать номера позиций в тупле вместо имени поля, использую этот метод. Например, если вдруг функция возвращает более одного параметра - проще использовать «rec».

Тред не читал, но считаю своим долгом сказать «В этом вашем питоне что, даже Enum небыло?»

Ты не поверишь, там пока даже скобок (braces) нет! Если тольоко не сделать

from __future__ import braces

Ну, я, собственно, на это и намекал. Что ещё чуть-чуть и Enum будет «изобретён» средствами языка. Только с чуть менее удобной инициализацией.