> from the database. If you want to compare you either have to use
> __class__ which I would say is a code smell, or you have
> to provide the Enum class.

I'm having a hard time seeing why the latter is problematic, I must
admit (certainly no more so than the "Alice in Wonderland" side effects
previously described).

> [...] An example of how this will be used in practice is:
>
> � � {% if object.state == object.state.completed %}
> � � � some html
> � � {% endif %}

The names used slightly obscure the weirdness of it, but what you're
really saying there is:

� � if my_state == my_state.another_state

... which feels more like a code smell to me than

� � �{% if object.state == State.completed %}
� � � �some html
� � �{% endif %}

That's quite intelligible, and doesn't require anyone to know that an
Enum member's siblings can, in your proposal, be accessed directly via
dot notation (an unintuitive state of affairs, to me at least).

Right. The OP is just concerned that (because these are Django templates) he will have to pass in the 'State' class as a separate template parameter for this to work. But to me that's a problem with Django, and not something for which the Enum type should bend over backwards to cover up for. Given that it's a Djano weakness, IMO the __class__ solution is reasonable enough, although in theory it would allow having object.state be something of the wrong class that happens to have a 'completed' attribute -- that would be a bug of a different color, though. :-)
">

(original) (raw)

On Mon, Sep 23, 2013 at 8:17 AM, Zero Piraeus <z@etiol.net> wrote:

On Mon, Sep 23, 2013 at 09:45:46AM -0400, Chris Lambacher wrote:

> [...] The exact use case is in Django templates where a value comes

> from the database. If you want to compare you either have to use
\> \_\_class\_\_ which I would say is a code smell, or you have
\> to provide the Enum class.

I'm having a hard time seeing why the latter is problematic, I must
admit (certainly no more so than the "Alice in Wonderland" side effects
previously described).

\> \[...\] An example of how this will be used in practice is:
>
\> � � {% if object.state == object.state.completed %}
\> � � � some html
\> � � {% endif %}

The names used slightly obscure the weirdness of it, but what you're
really saying there is:

� � if my\_state == my\_state.another\_state

... which feels more like a code smell to me than

� � �{% if object.state == State.completed %}
� � � �some html
� � �{% endif %}

That's quite intelligible, and doesn't require anyone to know that an
Enum member's siblings can, in your proposal, be accessed directly via
dot notation (an unintuitive state of affairs, to me at least).

Right. The OP is just concerned that (because these are Django templates) he will have to pass in the 'State' class as a separate template parameter for this to work. But to me that's a problem with Django, and not something for which the Enum type should bend over backwards to cover up for. Given that it's a Djano weakness, IMO the \_\_class\_\_ solution is reasonable enough, although in theory it would allow having object.state be something of the wrong class that happens to have a 'completed' attribute -- that would be a bug of a different color, though. :-)
�
--
--Guido van Rossum (python.org/\~guido)