Hacker News Reader

Comment by comex | Hacker News Reader

The syntax strikes me as somewhat strange. It requires writing out enum values (and thus avoiding duplicates or, for a cleaner look, just keeping them sorted), necessitating unnecessary effort when new values are added in the middle, and misleadingly implies that the enum values are merely class-level integer constants. I would have preferred a more explicit API that used a list of strings for the enumerators.

View on HN

As an optional implementation that'd be nice, but this syntax I assume is meant to solve two problems:

1. Making the integral values of an enum clear and unchanged by re-ordering the names. If the integral values matter to you (because you serialize enums that way), then I would want them to be explicit.

2. The integer values of these enums aren't exclusive. Two enums can reference the same value.

That said, I agree a short hand for people who don't care seems reasonable, where the integers could be auto-assigned by definition order, or just all set to 0.

I completely agree, this disgusts me:

>>> Animal = Enum('Animal', 'ant bee cat dog') >>> Animal.ant <Animal.ant: 1>

That being said, I welcome enums - I made classes to basically represent an enum a bunch of times.

The second parameter can also be a list/tuple of strings. e.g.:

>>> Animal = Enum('Animal', ('lion', 'tiger', 'liger', 'tigon'))

What disgusts you about it, in particular?

The fact that it allows whitespace-seperated words. It's just wrong.

It's weird, unnecessary, it just shouldn't be there.

Personally, I would've preferred:

>>> Enum('Example', 'foo', 'bar', 'baz')

(ie. Enum(name, *values))

That syntax is a bit unusual, but it has the clear advantage of being far less verbose. Consider this:

* The functional API is mostly for short code snippets and experiments in the shell. For real programs, the standard class syntax is preferred and recommended. * namedtuple already uses the same functional API allowing space-separated members, and it's a popular tool in the stdlib. Yes, the first time you run into it it feels a bit odd, but then you get used to it and it's not a big deal.

Looks exactly like namedtuple, why do we need this?

The only similarity is the signature; semantics are completely unrelated.

I guess I'm looking for a usecase that namedtuple (or set...) doesn't support. Here's one example:

http://pythonpath.wordpress.com/2012/01/26/python-enum-with-...

in that example the values of the enumerated constants are simply integer values, they do not have their own type. so there is nothing stopping you comparing values from two unrelated enumerations, and getting a nonsensical True or False result, instead of a TypeError.

I suppose that's true and theoretically useful. I don't find myself coding nonsense very often, but python has not been a language that gives much support (or is appropriate) to use cases that can't tolerate any.

I now see some good uses for Enum, but (with a skeptical eye to additions) I believe that the reasons to keep the language/libs small are equally important.

Strange that the auto-assigned values start at one.

Not that strange, actually. Reserving zero allows using it as an 'undefined' enumeration value that plays well with basic Boolean tests, e.g. 'if not animal: ...' and such.

Now all I want in Python is a real switch statement...

If this was a strongly-typed language I wouldn't want enums to be nullable, but maybe people would use that in Python.

Incidentally, this makes me wonder if one could implement something similar for flags (powers of two values, overloading | and &). Though sets of enums might be sufficient.

Python is a strongly-typed language.

Perhaps you're thinking of static versus dynamic typing?

The only languages I'd consider strongly typed are static typed.

Python functions are always 'a -> 'b (any to any), the weakest possible type for a function. Same for variables (as opposed to values), they are all 'a; same for list membership or attribute membership. There is no place in the language with room for a nullable / nonnullable distinction.

A statically-typed language is one in which (1) names and values both are typed, and the only legal binding of a value to a name is when the type of the value is compatible with the type of the name; (2) all expressions have types, and only values or names of the appropriate type may be used or returned. Often but not always, some form of source-code processing prior to execution will evaluate all types in the program and determine whether these conditions are met.

A dynamically-typed language is one in which only values have types, and there are no restrictions by type on what values may be bound to particular names. Expressions may or may not have defined types, and may or may not check these types (some dynamically-typed languages do allow statements to be made about the types of functions, for example; some use these in a "static-y" way, while others treat them more as hints for runtime optimization).

Strong and weak typing are far less precisely defined. The most broadly-used criterion I've personally seen is that in a strongly-typed language, attempting to perform an operation with values whose types are incompatible with the operation will fail immediately, and will not try to implicitly coerce the values to acceptable types for the operation.

Python is generally considered strongly typed, and dynamically typed. There is no consensus that these two labels are incompatible, just as there is no consensus that weak and static typing are incompatible (C is often described as being both statically and weakly typed, for example, due to C's casting and conversion facilities).

In a dynamic language it's the values that are typed (at runtime), not variables, functions, etc. I think your interpretation of weak vs. strong is already covered by static vs. dynamic, whereas the other interpretation of weak typing is about silent coercion of types such as in Javascript and PHP where for example an integer can be concatenated to a string, or in C where a string can be interpreted as an integer with a cast.

You might consider that, but frankly, you'd be wrong. Python is unambiguously strongly (and dynamically) typed.

Python accepts:

     1 + True == False + 2

It should have to be:

     1 + int(True) == int(False) + 2

Python accepts this because bool is a subclass of int, and True and False have defined integer values (1 and 0 respectively).

Which means there's no coercion or conversion going on here. For what you think it "should" be, Python would have to break Liskov substitution for subclasses of int.

It shouldn't be a subclass of int. http://arxiv.org/abs/math/9205211

You're free to argue that. But the fact that it is, and behaves correctly as a subclass of int, does not make Python be weakly typed. In fact, rather the opposite.

Then it gets fixed, and everyone screams because it's not backward compatible (Python 3).

It should have just been part of Python 3.

Yep, but they didn't aim to or succeed in 'fixing everything' in python3, just the most pressing items.

Here's to Python 4!

The syntax is easy for us who have been using ghetto enums:

  class Colors:
      red, green, blue = range(3)

Adding new values in the middle is exactly why it needs to be explicit. If you're pickling them, for example, or otherwise recording them, you certainly care about the values. Auto-assignment is often convenient, but it certainly must never be the only way to do it.

Similar to this?

http://www.python.org/dev/peps/pep-0435/#functional-api

Having to throw in a " ".join(...) isn't that bad.

No need for join().

> It can be a whitespace-separated string of names, a sequence of names, a sequence of 2-tuples with key/value pairs, or a mapping (e.g. dictionary) of names to values.

Even better. The many levels of skimming on display.

Would love to see functionality here similar to the iota keyword in Go.

Reply on news.ycombinator.com