aboutsummaryrefslogtreecommitdiffstats
path: root/libbe/settings_object.py
Commit message (Collapse)AuthorAgeFilesLines
* Added default to settings_object.versioned_property's change_hook_property.W. Trevor King2009-07-271-8/+3
| | | | | | | | | | Now change_hook properties handle defaults, which allows them to avoid an initial None -> default save hook trigger. Removed the now-redundant read-only mode business in becommands/diff.py.
* Fixed extra change-hook save in testChangeHookMutableProperty.W. Trevor King2009-07-211-10/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The actual fix was @@ -339,7 +355,10 @@ fset = funcs.get("fset") name = funcs.get("name", "<unknown>") def _fget(self, new_value=None, from_fset=False): # only used if mutable == True - value = fget(self) + if from_fset == True: + value = new_value # compare new value with cached + else: + value = fget(self) # compare current value with cached if _cmp_cached_mutable_property(self, "change hook property", name, value) != 0: # there has been a change, cache new value old_value = _get_cached_mutable_property(self, "change hook property", name) The reason for the double-save was: >>> print t.settings["List-type"]==EMPTY True (the cached value here is EMPTY) >>> t.list_type = [] (old fget compares cached EMPTY to current EMPTY, no change, so no cache. fset notices change and saves EMPTY->[]) >>> t.list_type.append(5) (now fget notices the change EMPTY->[], caches [], and calls extra save) The new way: >>> print t.settings["List-type"]==EMPTY True (the cached value here is EMPTY) >>> t.list_type = [] (fget compares cached EMPTY to new [] and saves EMPTY->[]) >>> t.list_type.append(5) (fget sees no change ([]->[]), which is correct) In addition to the fix and the related corrections to testChangeHookMutableProperty, I added details about mutables to all relevant docstrings and stripped trailing whitespace from both files.
* Updated GPLv2 to current GPLv2.W. Trevor King2009-07-141-10/+11
| | | | | | | | | | | | | | | | | | | | | | | | Fixes Ben's bug 00f26f04-9202-4288-8744-b29abc2342d6. I also tweaked update_copyright.sh to make possible future copyright-blurb revision easier. The new algorithm is greedier, overwriting _all_ consecutive comments after a '^# Copyright' line, so do # Copyright # GPL ... GPL ... GPL # Your comment here... not # Copyright # GPL ... GPL ... GPL # # Your comment here... Without the blank line, your comment would get overwritten by the next run of update_copyright.sh. Note that catmutt is ignored by update_copyright.sh because Moritz Barsnick has only licensed his grepm code under the GPLv2 (not GPLv>=2). See the initial catmutt commit for details.
* Updating "be set --help" and "be status --help".W. Trevor King2009-07-111-3/+3
| | | | | | | | | I don't really like the "defaults to None" for the settings that have funky initialization procedures (most of them :p), but I'm not sure how to handle that cleanly yet. Perhaps be set --current I also need to find a method of adding complicated settings like the nested lists for severities, etc from the "be set" commandline.
* Fixed versioned_property(default=None, generator=None) defaults.W. Trevor King2009-07-111-10/+10
| | | | | | Now the behavior conforms to the docstring: If both default and generator are None, then the property will be a defaulting property which defaults to None.
* Updated copyright blurbs and AUTHORS and included script for future updatesW. Trevor King2009-07-011-1/+1
|
* tag --remove now returns bug.settings["extra_strings"] to EMPTY.W. Trevor King2009-06-251-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | extra_strings returns to a defaulting property from a cached/generator property, with the help of the new, mutable defaults. Lots of deepcopies avoid mutable default uncertainty too ;). And copy.deepcopy([]) should be pretty cheap. tag --remove had previously left settings["extra_strings"] as [], which polluted the bug's values file. Now the improved defaulting_property notices a return to the default [], and sets the internally stored value to EMPTY. I struggled with creating a more intuitive way to notice changes to extra_strings than the tmp = bug.extra_strings <work on tmp> bug.extra_strings = tmp but didn't have any luck. The problem seems to be that if you only hand out copies of your default, you don't have any pointers to what you handed out to check for changes. On the other hand, if you hand out your original default, any external changes will _change_ your original default. I suppose you could only hand out copies, but keep a list of all copies handed out, but that sounds like a disaster. Reassigning is easy enough.
* Added test case for mutables to libbe/settings_object.W. Trevor King2009-06-231-4/+59
| | | | | | | | | | | | | This continues the line of changes started in libbe/properties with the last two commits. Also straightened up stranch double-default in libbe.settings_object.versioned_property and moved the fn_checked before checked, which shouldn't matter because I never use both at once, and can't think of a case where you'd want to. I've also added some docstrings to the settings_object unit tests, since apparently docstrings get printed during the test if they exist, and they look nicer than the name of the unittest itself. More like ./configure output ;).
* Added Bug.extra_strings to support add-on functionality, e.g. `be tag`.W. Trevor King2009-06-231-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Versioned properties whose data is a mutable type are tricky, since the simple comparisons we'd been using in libbe.properties.change_hook_property don't work for mutables. For now, we avoid that problem by assuming a change happened whenever a mutable property is set. change_hook_property is a bit untidy at the moment while I work out how to deal with mutables. As an example of using Bug.extra_strings to patch on some useful functionality, I've written becommands/tag.py. I'd suggest future add-ons (e.g. becommands/depend.py?) use the "<LABEL>:<value>" string format to keep it easy to sort out which strings belong to which add-ons. tag.py is still missing command line tag-removal and tag-searching for `be list'. Perhaps something like be list --extra-strings TAG:<your-tag>,TAG:<another-tag>,DEPEND:<bug-id> would be good, although it would requre escaping commas from the tags, or refusing to allow commas in the tags... libbe.properties.ValueCheckError also got a minor update so the printed error message makes sense when raised with allowed being an iterable (i.e. check_property) or a function (e.g. fn_checked_property). All of this digging around turned up a really buggy libbe.bugdir.MultipleBugMatches. Obviously I had never actually called it before :p. Should be fixed now. libbe.comment._set_comment_body has also been normalized to match the suggested change_hook interface: change_hook(self, old, new). Although, I'm not sure why it hadn't been causing obvious problems before, so maybe I'm misunderstanding something about that.
* Merged Thomas Habets 2009-01-07 XML output for "be show".W. Trevor King2009-06-191-8/+94
| | | | | | | | | | | | I rewrote a few of his routines, e.g. generalizing Comment.string_thread to run a caller-specified method avoided the need for some duplicate code in Comment.xml_thread. There was also a reasonable reorganization of libbe.settings_object.versioned_property because the <in_reply_to> field of the Comment.xml output was giving me `-1' (= old settings_object.EMPTY) instead of None, even after I had set comm.in_reply_to to None. The rewritten versioned_property avoids the ambiguity of UNPRIMED vs EMPTY, and avoids the stupididy of my using EMPTY=-1 ;).
* Added decorator-style properties to bugdir. Created settings_object module.W. Trevor King2008-12-021-0/+267
settings_object.SavedSettingsObject encapsulates some of the common settings functionality in the BE BugDir, Bug, and Comment classes. It's a bit awkward due to the nature of scoping in python subclasses, but it's better than reproducing this code in each of the above classes. Now I need to move Bug and Comment over to *this* system ;).