software-store-developers team mailing list archive

[Olivier Tilloy <olivier@xxxxxxxxxx>]

Hey Matt,

Matthew McGowan a écrit :
> Hi folks,
> 
> I have just pushed a branch 'enums-style-idea' and thought i should
> explain myself.
> 
> The main reason i did it was to make our enums imports go from something
> akin to this (as seen in appdetailsview_gtk.py):
> from softwarecenter.enums import (PKG_STATE_INSTALLING_PURCHASED,
>                                   PKG_STATE_INSTALLED,
>                                   PKG_STATE_PURCHASED_BUT_REPO_MUST_BE_ENABLED,
>                                   PKG_STATE_NEEDS_PURCHASE,
>                                   PKG_STATE_NEEDS_SOURCE,
>                                   PKG_STATE_UNINSTALLED,
>                                   PKG_STATE_REINSTALLABLE,
>                                   PKG_STATE_UPGRADABLE,
>                                   PKG_STATE_INSTALLING,
>                                   PKG_STATE_UPGRADING,
>                                   PKG_STATE_REMOVING,
>                                   PKG_STATE_NOT_FOUND,
>                                   PKG_STATE_UNKNOWN,
>                                   APP_ACTION_APPLY,
>                                   PKG_STATE_ERROR,
>                                   SOFTWARE_CENTER_PKGNAME,
>                                   MISSING_APP_ICON,
>                                   )
>  
> to this:
> from softwarecenter.enums import AppActions, PkgStates, Icons, SOFTWARE_CENTER_PKGNAME
> 
> Usage of enums within code would look something like this:
> if state == PkgStates.INSTALLED:

That looks good to me, more object-oriented and less C-style-ish.

> Besides the import clarity it makes browsing enums.py easier when using
> a python class-browser and i think going forward it makes the enums
> style similar to both qml, pyside (Qt.LeftButton for example) and also
> the gi enums style.
> 
> The downside is we obviously lose a some granularity as far as importing
> specific enums but i doubt this is a major.

I’d bet it’s actually more of a hassle in the general case than a win,
since one usually needs to import all or at least several constants in a
given group.

> Enums that dont really fit into a logical group i have left separate,
> i.e. SOFTWARE_CENTER_PKGNAME remains an 'ungrouped' enum.  There are a
> few other examples.

That looks good too.

> So is this a good idea or not?

I like the idea, it’d make the code more elegant. I had a look at the
implementation too, and I realized that I would have done it in a
different way (not necessarily better, just different).
I would naturally have changed the enums.py for an enum folder
containing submodules for each group of constants. Ungrouped constants
would go in the module’s __init__.py.
I don’t know how the two implementations compare in terms of
elegance/performance/potential issues/etc… I just thought I’d mention my
first idea for discussion, but as far as I’m concerned your
implementation looks fine to me, if it works go for it!

Cheers,

Olivier