[Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as
Stephen J. Turnbull
stephen at xemacs.org
Wed Feb 27 06:49:11 CET 2013
Greg Ewing writes:
> Stephen J. Turnbull wrote:
> > Worse for me, most of the applications I have, I'd like the enumerator
> > identifiers to be both string-valued and int-valued: the int used to
> > index into Python sequences, and the string used in formatting SQL.
> Is the string value required the same as the name used in
> Python code? If so, this requirement would be met by having
> __index__ return the int value and __str__ return the
> unqualified name.
Ah, that's right (and Ethan already mentioned using __index__). Yes,
I think that should work for me. Very cool!
... If I had a use for it. But I'm mostly trying to understand
Ethan's use case; I can't recall having a case where I would be
hard-coding an index by name. In my typical use, I might have several
data set with columns CITY, INCOME, NUMBER_OF_CARS, ... and need to
compute various correlations based on user-specified models. Then my
list of indicies for internal use is just
[column_index[name] for name in user_provided_name_list]
and the inverse (for formatting output) is
[column_name[index] for index in internal_indicies] .
The column_index and column_name dicts are computed when reading the
data set (typically from column headers in a CSV file).
Then I said to myself, "instead of using 'internal_indicies', let me
hard-code enum constants for indicies -- what would that look like?"
and that's where my requirement came from.
If I am guessing Ethan's use case correctly, the computations are very
specific to the columns involved (eg, he can't use a generic function
like "correlation" for arbitrary pairs of columns). Then he does
these idiosyncratic computations for various data sets.
Are such applications common? Evidently, they're bread and butter for
Ethan, but anybody else?
More information about the Python-Dev