The distutils.LooseVersion constructor currently only calls parse if vstring has a value. Unfortunately, this means that a user passing in vstring="" or vstring=None gets a version object with self.vstring and self.version unset. This wreaks havoc later when the user tries to do anything with their object. I've attached two possible solutions.

The first attempts to fix the issue by raising an exception when an invalid vstring is given. This seems like the most reasonable treatment of this case as there is no reasonable way to fully initialize the object. The second works around the issue, initializing the uninitialized fields with "" in the event of an invalid vstring.

Thanks, will fix it.

The fact that 1) StrictVersion and LooseVersion have None as default argument for vstring in __init__ 2) __init__ does not raise an exception if vstring is not given makes me think that the intended behavior is that the vstring argument is optional.  Making it required would be a behavior change which would run contrary to the distutils code freeze*.  I don’t feel that the workaround (set self.vstring to '') is okay; I’d rather fix the methods that fail when self.vstring is not defined, like __str__, or document the limitations.  What is your use case for these classes, and what methods need fixing?

* There is a lot of code out there that will break if we start to add and remove
  things, so a freeze was decided and we work on distutils2, a new version.
  distutils only gets fixes for real bugs.

The bug was encountered while trying to install a package. As it turns out, a dependency was incorrectly installed, resulting in a null version being passed around which quickly caused a crash in setup.py. While this is definitely not a normal circumstance, the fact that this bug existed made finding the issue substantially more time consuming. If the constructor of the LooseVersion can accept None, then so should its other members.

> The bug was encountered while trying to install a package. As it turns
> out, a dependency was incorrectly installed, resulting in a null
> version being passed around which quickly caused a crash in setup.py.
> While this is definitely not a normal circumstance, the fact that this
> bug existed made finding the issue substantially more time consuming.
I agree.  You don’t happen to have the log available, do you?

> If the constructor of the LooseVersion can accept None, then so should
> its other members.
Sure.  From a quick glance, we need to fix __str__ and _cmp.

Sorry, no log is available.