Depending on enum34 from a library

[Ben Finney]

Vasiliy Faronov <vfaronov at gmail.com> writes:

> 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.

As far as I know, ‘enum34’ is intended to provide all the same features
as the latest Python 3 standard library's ‘enum’ library.

> 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?

I think that this is similar to using the ‘unit2’ library, which is
intended to be used in projects to allow Python 2 and Python 3 to run
the same code to import ‘unittest’ and get the features of the latest
Python 3 ‘unittest’.

That is, the existence of ‘enum34’ is intended to allow you to just
depend on that library, import ‘enum’, and your code will work correctly
in Python 2 and Python 3 unchanged.

You are then using a Python 3 feature, just ported to an external
library. The advantage is that when eventually you stop supporting
Python 2, you can drop the external library, and your code keeps on
importing ‘enum’ and works.


Now, you may not trust that will work as seamlessly as described! That's
reasonable, and it is your choice whether the risk is worth it.

Consider the maintainer of the library, consider what they say about how
the library is expected to be used now and in the future, and choose
which risk to take.

-- 
 \        “If one tells the truth, one is sure, sooner or later, to be |
  `\   found out.” —Oscar Wilde, _Phrases and Philosophies for the Use |
_o__)                                              of the Young_, 1894 |
Ben Finney