use better mechanism for enums in gs_utils.py

use better mechanism for enums in gs_utils.py

This will allow more flexible subclassing of the GSUtils class: subclasses will automatically inherit the various constants.

That more flexible subclassing will allow us to easily wrap common's gs_utils.py with an extended version within the buildbot repo, as discussed in https://codereview.chromium.org/405653004/diff/20001/slave/skia_slave_scripts/build_step.py#newcode60

R=borenet@google.com

Committed: https://skia.googlesource.com/common/+/2e2cd80

[epoger, 2014-07-21 16:32:31]

Eric, PTAL.

Patchset 1 just split the unittests out into their own file; I suggest you focus
on the diffs between patchsets 1 and 2, which are the meat of this change.

url_utils.py only shows up because I disabled execute permissions on that file
(we never run that file directly)

[borenet, 2014-07-21 17:35:25]

LGTM with question

https://codereview.chromium.org/405083005/diff/20001/py/utils/gs_utils.py
File py/utils/gs_utils.py (right):

https://codereview.chromium.org/405083005/diff/20001/py/utils/gs_utils.py#new...
py/utils/gs_utils.py:75: Empty = None
Should these be in all-caps, since they're constants (even though they aren't
module-level constants)?

[epoger, 2014-07-21 18:03:20]

https://codereview.chromium.org/405083005/diff/20001/py/utils/gs_utils.py
File py/utils/gs_utils.py (right):

https://codereview.chromium.org/405083005/diff/20001/py/utils/gs_utils.py#new...
py/utils/gs_utils.py:75: Empty = None
On 2014/07/21 17:35:25, borenet wrote:
> Should these be in all-caps, since they're constants (even though they aren't
> module-level constants)?

SURE_WHY_NOT

[epoger, 2014-07-21 18:03:46]

Committed patchset #3 manually as r2e2cd80 (presubmit successful).