On 07/24/2016 01:10 PM, Vasiliy Faronov wrote:
I'm building a Python library where I want to use Python 3.4-style
enums. Because I need to support Python 2.7, I'm considering using
enum34 [1]. But I'm not sure how to do this:
If I simply depend on enum34, it will install a module named `enum`
even in Python 3.4+ environments, and that could shadow the stdlib
module. Personally I would be very surprised if installing a library
caused an unrelated stdlib module to be replaced with a third-party
one, even if it's "just" a backport. However, in my environments,
`sys.path` is such that stdlib comes before site-packages -- perhaps
this is normal enough that I can rely on it?
Or I could change my setup.py to include enum34 in `install_requires`
only if running on Python 2.7. But that will make my distribution's
metadata dynamic, which doesn't sound like a good idea [2]. At the
very least, I think it will prevent me from building a universal
wheel.
enum34 is kept up-to-date, as far as I am able, with the current version of
enum in the stdlib. As a happy side-effect if it is found before the stdlib
version Python will still run -- at least for Python 3.4 and 3.5; 3.6 is
adding some new features that I am not planning on adding to enum34.
For my own code I use the 'install_requires' option, plus some code that
checks the Python version to see if enum34 is needed.
Your other option is to use aenum [1], my other package, instead; it does
not risk conflict with enum, but has the same basic behavior (plus lots of
advanced behavior you can opt in to).
--
~Ethan~
[1] https://pypi.python.org/pypi/aenum
--
https://mail.python.org/mailman/listinfo/python-list
