Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
So clearly the ree expectation is that they compare equal (if the values are). On Apr 13, 2013 11:24 AM, "Scott Dial" wrote: > On 4/12/2013 10:51 PM, Steven D'Aprano wrote: > > And two examples from asm-generic/errno.h: > > > > #define EWOULDBLOCK EAGAIN /* Operation would block */ > > #define EDEADLOCK EDEADLK > > > > That's actually even better of an example than you may have realized > because historically EWOULDBLOCK != EAGAIN[1]. So, there very well may > need to exist such code as: > > if : > _EAGAIN = > _EWOULDBLOCK = > else: > _EAGAIN = _EWOULDBLOCK = > > class Errno(Enum): > EAGAIN = _EAGAIN > EWOULDBLOCK = _EWOULDBLOCK > > I don't think it's all that uncommon that enum values that represent > states of a system get merged or renamed over time, and this one is a > great example of that. > > [1] > > http://www.gnu.org/savannah-checkouts/gnu/libc/manual/html_node/Error-Codes.html#index-EAGAIN-97 > > -- > Scott Dial > sc...@scottdial.com > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Announcement] New mailing list for code quality tools including Flake8, Pyflakes and Pep8
Ian Cordasco writes: > Are you concerned about the evolution of various code checkers? > Do you have questions or suggestions? > > Subscribe here: > http://mail.python.org/mailman/listinfo/code-quality Now available via Gmane also http://dir.gmane.org/gmane.comp.python.code-quality>. Thanks guys! -- \ “I have never imputed to Nature a purpose or a goal, or | `\anything that could be understood as anthropomorphic.” —Albert | _o__)Einstein, unsent letter, 1955 | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
On 4/12/2013 10:51 PM, Steven D'Aprano wrote: > And two examples from asm-generic/errno.h: > > #define EWOULDBLOCK EAGAIN /* Operation would block */ > #define EDEADLOCK EDEADLK > That's actually even better of an example than you may have realized because historically EWOULDBLOCK != EAGAIN[1]. So, there very well may need to exist such code as: if : _EAGAIN = _EWOULDBLOCK = else: _EAGAIN = _EWOULDBLOCK = class Errno(Enum): EAGAIN = _EAGAIN EWOULDBLOCK = _EWOULDBLOCK I don't think it's all that uncommon that enum values that represent states of a system get merged or renamed over time, and this one is a great example of that. [1] http://www.gnu.org/savannah-checkouts/gnu/libc/manual/html_node/Error-Codes.html#index-EAGAIN-97 -- Scott Dial sc...@scottdial.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deciding against the CLA (was: Introducing Electronic Contributor Agreements)
On Sat, Apr 13, 2013 at 6:30 AM, Ben Finney wrote: > "Stephen J. Turnbull" writes: > >> Mark Lawrence writes: >> >> > People already use the bug tracker as an excuse not to contribute, >> > wouldn't this requirement make the situation worse? >> >> A failure to sign the CLA is already a decision not to contribute to >> the distribution > > As someone who cannot in good faith sign the CLA, that characterisation > is far from accurate: I would very much like to contribute to the Python > distribution, and so have not decided as you describe. > > Rather, I leave the matter of contribution undecided, while advocating > (when opportunity arises) against the CLA. > > The decision that the current terms are unacceptable does not entail a > decision not to contribute. Stephen said that it's a choice not to contribute and not that one wouldn't _like_ to contribute if the CLA wasn't there. Those are both distinctive choices to make. A desire to help is independent of whether you are willing to take the necessary step of signing the CLA in order to change that desire into an actual act of contributing (which is obviously fine; if you have moral issues with the CLA no one will hold it against you, we just can't legally risk accepting code without it). -Brett > > (aside: good sigmonster, have a treat.) > > -- > \ Lucifer: “Just sign the Contract, sir, and the Piano is yours.” | > `\ Ray: “Sheesh! This is long! Mind if I sign it now and read it | > _o__)later?” —http://www.achewood.com/ | > Ben Finney > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/brett%40python.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
[Eli] >> It is applicable, in the sense that os.O_CREAT etc can be IntEnum values. >> Their bitset operation results will be simple integers. It's not planned to >> add a special enum for this - this was ruled against during the Pycon >> discussions. On Sat, Apr 13, 2013 at 7:30 AM, Serhiy Storchaka wrote: > But IntEnum is useless in such cases because a resulting mask will be an > integer an will lost its convenient printable representation. There is > almost no benefit of IntEnum before int constant. If you really wanted that you could define an int subclass that does better and use that -- IntEnum is just one example of how you can override the value type of Enum. (And yes, I am now +1 on documenting this mechanism.) -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
On 13.04.13 03:13, Glenn Linderman wrote: On 4/12/2013 3:59 PM, Guido van Rossum wrote: class Insect(Enum): wasp = 1 bee = 1 ant = 2 We'd have Insect.wasp == Insect.bee < Insect.ant but Insect.wasp is not Insect.bee. can't define two names in the same enum to have the same value, per the PEP. For current flufl.enum implementations this requires values to be hashable. An alternative implementation can use comparability (which already required for repr() and iteration). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
On 13.04.13 15:43, Eli Bendersky wrote:
On Sat, Apr 13, 2013 at 1:31 AM, Serhiy Storchaka wrote:
On 12.04.13 15:55, Eli Bendersky wrote:
There is some ambiguity in the term "enumeration values". On the one hand,
it's the singleton instances of the enumeration class (Colors.red,
Colors.gree, Colors.blue), and on the other hand it is their values (1, 2,
3).
I agree, but not sure how to resolve it. I hope it's clear enough from the
context.
May be use "enumeration items" or "enumeration members" if instances of
the enumeration class have in mind? And left "enumeration names" and
"enumeration values" for sets of corresponding attributes (.name and
.value) of instances.
But if the value *is* important, enumerations can have arbitrary values.
Should enumeration values be hashable?
At least they should be comparable ("Iteration is defined as the sorted
order of the item values").
See long discussion previously in this thread.
I think this requirements (hashability and comparability (for repr() and
iteration)) should be mentioned explicitly.
The Python standard library has many places where named integer constants
used as bitmasks (i.e. os.O_CREAT | os.O_WRONLY | os.O_TRUNC, select.POLLIN
| select.POLLPRI, re.IGNORECASE | re.ASCII). The proposed PEP is not
applicable to these cases. Whether it is planned expansion of Enum or
additional EnumSet class to aid in these cases?
It is applicable, in the sense that os.O_CREAT etc can be IntEnum values.
Their bitset operation results will be simple integers. It's not planned to
add a special enum for this - this was ruled against during the Pycon
discussions.
But IntEnum is useless in such cases because a resulting mask will be an
integer an will lost its convenient printable representation. There is
almost no benefit of IntEnum before int constant.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (2.7): Issue #16447: Fix potential segfault when setting __name__ on a class.
On Sat, Apr 13, 2013 at 7:25 AM, Eli Bendersky wrote:
> Test case?
>
>
Ugh, sorry. I missed it. Ignore my previous email please.
Eli
>
> On Sat, Apr 13, 2013 at 7:19 AM, mark.dickinson <
> python-check...@python.org> wrote:
>
>> http://hg.python.org/cpython/rev/d5e5017309b1
>> changeset: 83283:d5e5017309b1
>> branch: 2.7
>> user:Mark Dickinson
>> date:Sat Apr 13 15:19:05 2013 +0100
>> summary:
>> Issue #16447: Fix potential segfault when setting __name__ on a class.
>>
>> files:
>> Lib/test/test_descr.py | 14 ++
>> Misc/NEWS | 3 +++
>> Objects/typeobject.c | 6 +-
>> 3 files changed, 22 insertions(+), 1 deletions(-)
>>
>>
>> diff --git a/Lib/test/test_descr.py b/Lib/test/test_descr.py
>> --- a/Lib/test/test_descr.py
>> +++ b/Lib/test/test_descr.py
>> @@ -4136,6 +4136,20 @@
>> C.__name__ = 'D.E'
>> self.assertEqual((C.__module__, C.__name__), (mod, 'D.E'))
>>
>> +def test_evil_type_name(self):
>> +# A badly placed Py_DECREF in type_set_name led to arbitrary code
>> +# execution while the type structure was not in a sane state,
>> and a
>> +# possible segmentation fault as a result. See bug #16447.
>> +class Nasty(str):
>> +def __del__(self):
>> +C.__name__ = "other"
>> +
>> +class C(object):
>> +pass
>> +
>> +C.__name__ = Nasty("abc")
>> +C.__name__ = "normal"
>> +
>> def test_subclass_right_op(self):
>> # Testing correct dispatch of subclass overloading __r__...
>>
>> diff --git a/Misc/NEWS b/Misc/NEWS
>> --- a/Misc/NEWS
>> +++ b/Misc/NEWS
>> @@ -17,6 +17,9 @@
>> Core and Builtins
>> -
>>
>> +- Issue #16447: Fixed potential segmentation fault when setting __name__
>> on a
>> + class.
>> +
>> - Issue #17610: Don't rely on non-standard behavior of the C qsort()
>> function.
>>
>> Library
>> diff --git a/Objects/typeobject.c b/Objects/typeobject.c
>> --- a/Objects/typeobject.c
>> +++ b/Objects/typeobject.c
>> @@ -225,6 +225,7 @@
>> type_set_name(PyTypeObject *type, PyObject *value, void *context)
>> {
>> PyHeapTypeObject* et;
>> +PyObject *tmp;
>>
>> if (!(type->tp_flags & Py_TPFLAGS_HEAPTYPE)) {
>> PyErr_Format(PyExc_TypeError,
>> @@ -253,10 +254,13 @@
>>
>> Py_INCREF(value);
>>
>> -Py_DECREF(et->ht_name);
>> +/* Wait until et is a sane state before Py_DECREF'ing the old
>> et->ht_name
>> + value. (Bug #16447.) */
>> +tmp = et->ht_name;
>> et->ht_name = value;
>>
>> type->tp_name = PyString_AS_STRING(value);
>> +Py_DECREF(tmp);
>>
>> return 0;
>> }
>>
>> --
>> Repository URL: http://hg.python.org/cpython
>>
>> ___
>> Python-checkins mailing list
>> python-check...@python.org
>> http://mail.python.org/mailman/listinfo/python-checkins
>>
>>
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (2.7): Issue #16447: Fix potential segfault when setting __name__ on a class.
Test case?
On Sat, Apr 13, 2013 at 7:19 AM, mark.dickinson
wrote:
> http://hg.python.org/cpython/rev/d5e5017309b1
> changeset: 83283:d5e5017309b1
> branch: 2.7
> user:Mark Dickinson
> date:Sat Apr 13 15:19:05 2013 +0100
> summary:
> Issue #16447: Fix potential segfault when setting __name__ on a class.
>
> files:
> Lib/test/test_descr.py | 14 ++
> Misc/NEWS | 3 +++
> Objects/typeobject.c | 6 +-
> 3 files changed, 22 insertions(+), 1 deletions(-)
>
>
> diff --git a/Lib/test/test_descr.py b/Lib/test/test_descr.py
> --- a/Lib/test/test_descr.py
> +++ b/Lib/test/test_descr.py
> @@ -4136,6 +4136,20 @@
> C.__name__ = 'D.E'
> self.assertEqual((C.__module__, C.__name__), (mod, 'D.E'))
>
> +def test_evil_type_name(self):
> +# A badly placed Py_DECREF in type_set_name led to arbitrary code
> +# execution while the type structure was not in a sane state, and
> a
> +# possible segmentation fault as a result. See bug #16447.
> +class Nasty(str):
> +def __del__(self):
> +C.__name__ = "other"
> +
> +class C(object):
> +pass
> +
> +C.__name__ = Nasty("abc")
> +C.__name__ = "normal"
> +
> def test_subclass_right_op(self):
> # Testing correct dispatch of subclass overloading __r__...
>
> diff --git a/Misc/NEWS b/Misc/NEWS
> --- a/Misc/NEWS
> +++ b/Misc/NEWS
> @@ -17,6 +17,9 @@
> Core and Builtins
> -
>
> +- Issue #16447: Fixed potential segmentation fault when setting __name__
> on a
> + class.
> +
> - Issue #17610: Don't rely on non-standard behavior of the C qsort()
> function.
>
> Library
> diff --git a/Objects/typeobject.c b/Objects/typeobject.c
> --- a/Objects/typeobject.c
> +++ b/Objects/typeobject.c
> @@ -225,6 +225,7 @@
> type_set_name(PyTypeObject *type, PyObject *value, void *context)
> {
> PyHeapTypeObject* et;
> +PyObject *tmp;
>
> if (!(type->tp_flags & Py_TPFLAGS_HEAPTYPE)) {
> PyErr_Format(PyExc_TypeError,
> @@ -253,10 +254,13 @@
>
> Py_INCREF(value);
>
> -Py_DECREF(et->ht_name);
> +/* Wait until et is a sane state before Py_DECREF'ing the old
> et->ht_name
> + value. (Bug #16447.) */
> +tmp = et->ht_name;
> et->ht_name = value;
>
> type->tp_name = PyString_AS_STRING(value);
> +Py_DECREF(tmp);
>
> return 0;
> }
>
> --
> Repository URL: http://hg.python.org/cpython
>
> ___
> Python-checkins mailing list
> python-check...@python.org
> http://mail.python.org/mailman/listinfo/python-checkins
>
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (2.7): Issue #16447: Fix potential segfault when setting __name__ on a class.
2013/4/13 Eli Bendersky :
> Test case?
I see one.
>
>
> On Sat, Apr 13, 2013 at 7:19 AM, mark.dickinson
> wrote:
>>
>> http://hg.python.org/cpython/rev/d5e5017309b1
>> changeset: 83283:d5e5017309b1
>> branch: 2.7
>> user:Mark Dickinson
>> date:Sat Apr 13 15:19:05 2013 +0100
>> summary:
>> Issue #16447: Fix potential segfault when setting __name__ on a class.
>>
>> files:
>> Lib/test/test_descr.py | 14 ++
>> Misc/NEWS | 3 +++
>> Objects/typeobject.c | 6 +-
>> 3 files changed, 22 insertions(+), 1 deletions(-)
>>
>>
>> diff --git a/Lib/test/test_descr.py b/Lib/test/test_descr.py
>> --- a/Lib/test/test_descr.py
>> +++ b/Lib/test/test_descr.py
>> @@ -4136,6 +4136,20 @@
>> C.__name__ = 'D.E'
>> self.assertEqual((C.__module__, C.__name__), (mod, 'D.E'))
>>
>> +def test_evil_type_name(self):
>> +# A badly placed Py_DECREF in type_set_name led to arbitrary code
>> +# execution while the type structure was not in a sane state, and
>> a
>> +# possible segmentation fault as a result. See bug #16447.
>> +class Nasty(str):
>> +def __del__(self):
>> +C.__name__ = "other"
>> +
>> +class C(object):
>> +pass
>> +
>> +C.__name__ = Nasty("abc")
>> +C.__name__ = "normal"
>> +
>> def test_subclass_right_op(self):
>> # Testing correct dispatch of subclass overloading __r__...
>>
>> diff --git a/Misc/NEWS b/Misc/NEWS
>> --- a/Misc/NEWS
>> +++ b/Misc/NEWS
>> @@ -17,6 +17,9 @@
>> Core and Builtins
>> -
>>
>> +- Issue #16447: Fixed potential segmentation fault when setting __name__
>> on a
>> + class.
>> +
>> - Issue #17610: Don't rely on non-standard behavior of the C qsort()
>> function.
>>
>> Library
>> diff --git a/Objects/typeobject.c b/Objects/typeobject.c
>> --- a/Objects/typeobject.c
>> +++ b/Objects/typeobject.c
>> @@ -225,6 +225,7 @@
>> type_set_name(PyTypeObject *type, PyObject *value, void *context)
>> {
>> PyHeapTypeObject* et;
>> +PyObject *tmp;
>>
>> if (!(type->tp_flags & Py_TPFLAGS_HEAPTYPE)) {
>> PyErr_Format(PyExc_TypeError,
>> @@ -253,10 +254,13 @@
>>
>> Py_INCREF(value);
>>
>> -Py_DECREF(et->ht_name);
>> +/* Wait until et is a sane state before Py_DECREF'ing the old
>> et->ht_name
>> + value. (Bug #16447.) */
>> +tmp = et->ht_name;
>> et->ht_name = value;
>>
>> type->tp_name = PyString_AS_STRING(value);
>> +Py_DECREF(tmp);
>>
>> return 0;
>> }
>>
>> --
>> Repository URL: http://hg.python.org/cpython
>>
>> ___
>> Python-checkins mailing list
>> python-check...@python.org
>> http://mail.python.org/mailman/listinfo/python-checkins
>>
>
>
> ___
> Python-checkins mailing list
> python-check...@python.org
> http://mail.python.org/mailman/listinfo/python-checkins
>
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
On Sat, Apr 13, 2013 at 6:43 AM, Lennart Regebro wrote: > OK, so I finally got tie to read the PEP. I like it, I really have > missed Enums, this is awesome. > > That's all folks! > > //Lennart > More of these kinds of comments ;-) Thanks, Lennart. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
OK, so I finally got tie to read the PEP. I like it, I really have missed Enums, this is awesome. That's all folks! //Lennart ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
On Sat, Apr 13, 2013 at 1:31 AM, Serhiy Storchaka wrote:
> On 12.04.13 15:55, Eli Bendersky wrote:
>
>> The enumeration value names are available through the class members::
>>
>> >>> for member in Colors.__members__:
>> ... print(member)
>> red
>> green
>> blue
>>
>
> This is unnecessary because enumerations are iterable. Colors.__members__
> is equal to [v.name for v in Colors] and the latter looks more
> preferable, because it does not use the magic method.
>
>
Right. Fixed (removed this part because it's redundant), thanks.
>
> The str and repr of the enumeration class also provides useful
>> information::
>>
>> >>> print(Colors)
>>
>> >>> print(repr(Colors))
>>
>>
>
> Does the enumeration's repr() use str() or repr() for the enumeration
> values? And same question for the enumeration's str().
>
>
str
>
> To programmatically access enumeration values, use ``getattr``::
>>
>> >>> getattr(Colors, 'red')
>>
>>
>
> How to get the enumeration value by its value?
>
>
I've updated the PEP since then. It also shows how to use __getitem__
syntax to access by value.
>
> Ordered comparisons between enumeration values are *not* supported. Enums
>> are
>> not integers (but see `IntEnum`_ below)::
>>
>
> It's unexpected if values of the enumeration values have the natural
> order. And values of the enumeration values *should be* comparable
> ("Iteration is defined as the sorted order of the item values").
>
> Enumeration values
>> --
>>
>
> There is some ambiguity in the term "enumeration values". On the one hand,
> it's the singleton instances of the enumeration class (Colors.red,
> Colors.gree, Colors.blue), and on the other hand it is their values (1, 2,
> 3).
>
>
I agree, but not sure how to resolve it. I hope it's clear enough from the
context.
>
> But if the value *is* important, enumerations can have arbitrary values.
>>
>
> Should enumeration values be hashable?
>
> At least they should be comparable ("Iteration is defined as the sorted
> order of the item values").
>
>
See long discussion previously in this thread.
>
> ``IntEnum`` values behave like integers in other ways you'd expect::
>>
>> >>> int(Shape.circle)
>> 1
>> >>> ['a', 'b', 'c'][Shape.circle]
>> 'b'
>> >>> [i for i in range(Shape.square)]
>> [0, 1]
>>
>
> What is ``isinstance(Shape.circle, int)``? Does PyLong_Check() return true
> for ``IntEnum`` values?
>
>
Yes. IntEnumValue (the value class underlying IntEnum) subclasses int.
>
> Enumerations created with the class syntax can also be pickled and
>> unpickled::
>>
>
> This does not apply to marshalling, I suppose? Perhaps this is worth to
> mention explicitly. There may be some errors of incompatibility.
No special provision has been made for marshalling.
The ``Enum`` class is callable, providing the following convenience API::
>
> >>> Animals = Enum('Animals', 'ant bee cat dog')
> >>> Animals
>
> >>> Animals.ant
>
> >>> Animals.ant.value
> 1
>
> The semantics of this API resemble ``namedtuple``. The first argument of
> the call to ``Enum`` is the name of the enumeration. The second argument
> is
> a source of enumeration value names. It can be a whitespace-separated
> string
> of names, a sequence of names or a sequence of 2-tuples with key/value
> pairs.
>
Why the enumeration starts from 1? It is not consistent with namedtuple, in
> which indices are zero-based, and I believe that in most practical cases
> the enumeration integer values are zero-based.
I don't know if there was a special reason for this. Perhaps backwards
compatibility with existing flufl.enum APIs. Barry may know more about this.
> Use-cases in the standard library
> =
>
The Python standard library has many places where named integer constants
> used as bitmasks (i.e. os.O_CREAT | os.O_WRONLY | os.O_TRUNC, select.POLLIN
> | select.POLLPRI, re.IGNORECASE | re.ASCII). The proposed PEP is not
> applicable to these cases. Whether it is planned expansion of Enum or
> additional EnumSet class to aid in these cases?
It is applicable, in the sense that os.O_CREAT etc can be IntEnum values.
Their bitset operation results will be simple integers. It's not planned to
add a special enum for this - this was ruled against during the Pycon
discussions.
Eli
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Deciding against the CLA (was: Introducing Electronic Contributor Agreements)
"Stephen J. Turnbull" writes: > Mark Lawrence writes: > > > People already use the bug tracker as an excuse not to contribute, > > wouldn't this requirement make the situation worse? > > A failure to sign the CLA is already a decision not to contribute to > the distribution As someone who cannot in good faith sign the CLA, that characterisation is far from accurate: I would very much like to contribute to the Python distribution, and so have not decided as you describe. Rather, I leave the matter of contribution undecided, while advocating (when opportunity arises) against the CLA. The decision that the current terms are unacceptable does not entail a decision not to contribute. (aside: good sigmonster, have a treat.) -- \ Lucifer: “Just sign the Contract, sir, and the Piano is yours.” | `\ Ray: “Sheesh! This is long! Mind if I sign it now and read it | _o__)later?” —http://www.achewood.com/ | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
On 12.04.13 15:55, Eli Bendersky wrote:
The enumeration value names are available through the class members::
>>> for member in Colors.__members__:
... print(member)
red
green
blue
This is unnecessary because enumerations are iterable.
Colors.__members__ is equal to [v.name for v in Colors] and the latter
looks more preferable, because it does not use the magic method.
The str and repr of the enumeration class also provides useful information::
>>> print(Colors)
>>> print(repr(Colors))
Does the enumeration's repr() use str() or repr() for the enumeration
values? And same question for the enumeration's str().
To programmatically access enumeration values, use ``getattr``::
>>> getattr(Colors, 'red')
How to get the enumeration value by its value?
Ordered comparisons between enumeration values are *not* supported. Enums
are
not integers (but see `IntEnum`_ below)::
It's unexpected if values of the enumeration values have the natural
order. And values of the enumeration values *should be* comparable
("Iteration is defined as the sorted order of the item values").
Enumeration values
--
There is some ambiguity in the term "enumeration values". On the one
hand, it's the singleton instances of the enumeration class (Colors.red,
Colors.gree, Colors.blue), and on the other hand it is their values (1,
2, 3).
But if the value *is* important, enumerations can have arbitrary values.
Should enumeration values be hashable?
At least they should be comparable ("Iteration is defined as the sorted
order of the item values").
``IntEnum`` values behave like integers in other ways you'd expect::
>>> int(Shape.circle)
1
>>> ['a', 'b', 'c'][Shape.circle]
'b'
>>> [i for i in range(Shape.square)]
[0, 1]
What is ``isinstance(Shape.circle, int)``? Does PyLong_Check() return
true for ``IntEnum`` values?
Enumerations created with the class syntax can also be pickled and
unpickled::
This does not apply to marshalling, I suppose? Perhaps this is worth to
mention explicitly. There may be some errors of incompatibility.
The ``Enum`` class is callable, providing the following convenience API::
>>> Animals = Enum('Animals', 'ant bee cat dog')
>>> Animals
>>> Animals.ant
>>> Animals.ant.value
1
The semantics of this API resemble ``namedtuple``. The first argument of
the call to ``Enum`` is the name of the enumeration. The second argument is
a source of enumeration value names. It can be a whitespace-separated
string
of names, a sequence of names or a sequence of 2-tuples with key/value
pairs.
Why the enumeration starts from 1? It is not consistent with namedtuple,
in which indices are zero-based, and I believe that in most practical
cases the enumeration integer values are zero-based.
Use-cases in the standard library
=
The Python standard library has many places where named integer
constants used as bitmasks (i.e. os.O_CREAT | os.O_WRONLY | os.O_TRUNC,
select.POLLIN | select.POLLPRI, re.IGNORECASE | re.ASCII). The proposed
PEP is not applicable to these cases. Whether it is planned expansion of
Enum or additional EnumSet class to aid in these cases?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
