| 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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now (except for a wimpy hash function) it's as good as it's going to
get for true mutables. Calls to change_hook occur for all changes,
sometime after the change-enducing action and before the next
attribute access. See testChangeHookMutableProperty for an example of
the expected behavior.
If you're doing some mutable-modification (e.g. t.x.append(5)) and you
want to `flush' the changes into a change_hook call, just assign t.x
to a dummy variable. e.g.
t.x.append(5)
dummy = t.x
If you _really_ need post-modification change_hook calls without such
a flush, you're on your own. Would you get the property-owning class
to poll for changes?
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 ;).
|
|
|
libbe/bug has been moved over to the new system.
comment and bugdir still to go.
|
