aboutsummaryrefslogtreecommitdiffstats
path: root/libbe/settings_object.py
Commit message (Collapse)AuthorAgeFilesLines
* 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 ;).