Wed, 05 Apr 2017 21:32:32 +0900 templatekw: rename 'args' to 'mapping' in showlist()
Yuya Nishihara <yuya@tcha.org> [Wed, 05 Apr 2017 21:32:32 +0900] rev 32035
templatekw: rename 'args' to 'mapping' in showlist() The name 'args' provides no information. Call it 'mapping' as in templater.py.
Wed, 05 Apr 2017 21:27:44 +0900 templatekw: eliminate unnecessary temporary variable 'names' from _showlist()
Yuya Nishihara <yuya@tcha.org> [Wed, 05 Apr 2017 21:27:44 +0900] rev 32034
templatekw: eliminate unnecessary temporary variable 'names' from _showlist() Replace 'names' with the optional argument 'plural'.
Mon, 17 Apr 2017 20:22:00 +0200 color: update the help with the new default
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 17 Apr 2017 20:22:00 +0200] rev 32033
color: update the help with the new default The default is now "auto" we update the help to match reality.
Wed, 12 Apr 2017 16:48:13 +0200 upgrade: register all format variants in a list
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 12 Apr 2017 16:48:13 +0200] rev 32032
upgrade: register all format variants in a list Now that all known format variants exists outside of the function, we can gather them in a lists. This build a single entry point other code can use (current target: extensions). The repository upgrade code is updated to simply use entries from this list. As a side effect this will also allow extensions to register their own format variants, to do this "properly" we should introduce a "registrar" for this category of object. However I prefer to keep this series simple, and that will be adventure for future time.
Wed, 12 Apr 2017 16:34:05 +0200 upgrade: move descriptions and selection logic in individual classes
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 12 Apr 2017 16:34:05 +0200] rev 32031
upgrade: move descriptions and selection logic in individual classes Our goal here is to get top level definition for all the format variants. Having them defined outside of the function enabled other users of that logic. They are two keys components of a format variant: 1) the name and various descriptions of its effect, 2) the code that checks if the repo is using this variant and if the config enables it. That second items make us pick a class-based approach, since different variants requires different code (even if in practice, many can reuse the same logic). Each variants define its own class that is then used like a singleton. The class-based approach also clarify the definitions part a bit since each are simple assignment in an indented block. The 'fromdefault' and 'fromconfig' are respectively replaced by a class attribute and a method to be called at the one place where "fromconfig" matters. Overall, they are many viable approach for this, but this is the one I picked.
Mon, 10 Apr 2017 23:34:43 +0200 upgrade: introduce a 'formatvariant' class
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 10 Apr 2017 23:34:43 +0200] rev 32030
upgrade: introduce a 'formatvariant' class The 'deficiency' type has multiple specificities. We create a dedicated class to host them. More logic will be added incrementally in future changesets.
Mon, 17 Apr 2017 13:07:31 +0200 upgrade: implement '__hash__' on 'improvement' class
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 17 Apr 2017 13:07:31 +0200] rev 32029
upgrade: implement '__hash__' on 'improvement' class The pythonomicon request its implementation.
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -7 +7 +10 +30 +100 +300 +1000 +3000 +10000 tip