On Mon, Aug 04, 2014 at 09:14:46PM -0300, David Bremner wrote: > W. Trevor King writes: > > * Commands are no longer split into "most common", "other useful", > > and "less common" sets. If we need something like this, I'd > > prefer workflow examples highlighting common commands in the > > module docstring (available with 'nmbug --help'). > > I don't feel strongly about this, but I remember implementing it by > request in the first version. OTOH, I think you shortened up the > main help string when you split it.
I didn't intentionally remove any information. I think it's just shorter because command-specific details are now in the command-specific docstring/help. > We may want to think about a seperate man page as a follow project. Works for me, but I think it would look a lot like the wiki page [1]. > One thing I did notice is that there is no hint to call nmbug > {command} --help in the main docstring. I'll add that in v4. > > +#!/usr/bin/env python > > +# Copyright (c) 2011 David Bremner > > +# License: same as notmuch > > You should add your self, update the date, and probably explicitly > state the license, as in Carl's patch for nmbug-status. Will do in v4. > > +__version__ = '0.2' > > Do we need/want a version distinct from that of notmuch? nmbug is very loosely bound to the notmuch core. To me it feels like a separate project that happens to share the same version control repository. I'm happy to synchronize versions, but then we have to remember to bump the nmbug version for each notmuch release. > > +def _hex_quote(string, safe='+@=:,'): > > I'm not sure I really understand what makes a function/variable > "private" and hence prefixed with _ in your translation. The public interface is what I thought was reasonably stable for folks who want to call nmbug as a Python library. It's basically the command-line functionality, with a few other helpers that seemed important enough to be worth preserving. If we keep a separate nmbug version, I'd cut major releases for anything that broke compatibility on a public function. I don't need to use nmbug as a library myself, so this might all be over-engineered ;). > > + status, tree, stderr = _git( > > as a non-native speaker of python, I find this a bit hard to read. > How about adding some parens to make the multiple return more clear, > so > > (status, tree, stderr) = _git( That's legal, but I rarely see the parenthesized version in the wild. For examples showing the unparenthesized version, see [2,3]. Parentheses are optional for Python tuples [4], so you'd only want them if ‘=’ had a higher precedence than ‘,’. That's my argument for the unparenthesized version, but feel free to overrule me ;). > I did notice that merging was noticably noisier than I remembered. > > > + output = _collections.defaultdict( > > + lambda : _collections.defaultdict( # {tag: status_string} > > + lambda : ' ')) # default local status > > The initial comment is confusing (to me) because it looks like code. > The two layers of defaultdict are a bit confusing too; it would help > to mention the key of the outer dictionary. In v4, I'll use a leading comment for the whole structure, instead of interleaving the comments. I'll also mention explicitly that the outer layer is keyed by message id. > I guess it makes sense to go for a relatively straight translation > as a first step; I did wonder about whether using the python > bindings to notmuch would speed things up. Any ideas about how to > even figure out where the bottlenecks are? You could profile the Python script [5]. With my usual workflow, the existing implementation isn't generating too many subprocesses. Loading the database is probably slow though, so I'd expect reasonable gains everywhere we call notmuch more than once. I expect checkout out working directories to also be slow, for the few command that do that on behalf of Git. Cheers, Trevor [1]: http://notmuchmail.org/nmbug/ [2]: https://docs.python.org/3.4/tutorial/introduction.html#first-steps-towards-programming [3]: http://legacy.python.org/dev/peps/pep-3132/ [4]: https://docs.python.org/3.4/reference/expressions.html#parenthesized-forms [5]: https://docs.python.org/3.4/library/profile.html -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
signature.asc
Description: OpenPGP digital signature
_______________________________________________ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch