| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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 ;).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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 ;).
|
|
|
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 ;).
|
