[MERGE] Content filtering (EOL part 2 of 3)
John Arbash Meinel
john at arbash-meinel.com
Wed Jul 9 12:49:49 BST 2008
-----BEGIN PGP SIGNED MESSAGE-----
Martin Pool wrote:
> On Wed, Jul 9, 2008 at 11:49 AM, Ian Clatworthy
> <ian.clatworthy at internode.on.net> wrote:
>>> I think going to a callable is better because there may be some filters
>>> that can be parameterized in arbitrary different ways not just by a small
>>> set of values.
>> You're probably right but I was treating this as YAGNI. I hope there's
>> enough abstraction in the API for this to be supported via refactoring later.
> I can't help noticing that two paragraphs earlier you used an object
> rather than a dict to allow future evolution. :-)
Speaking of which, if you are using an object-per-file you should at least be
using __slots__ to make them a little more lightweight.
I would hope that there is some amount of filtering to prevent it from having
a full object() overhead for every node for simple operations, but I worry
that it will not be.
For example, iter_changes() is fast because it works *very* hard to do the
minimum amount of work necessary to ignore the bulk of the files. It doesn't
decode utf8 => unicode, it doesn't create objects (everything is still tuples
and lists at this point), etc.
I'm not completely sure where the content filtering slots into all of this...
> I do think it'd be worth changing this now, because it's at the pivot
> point where filters are registered, and a dict is easy to map to a
> I'll read the rest later...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the bazaar