Rajeev S writes:

Hi Abhilash,

Please don't top-post. It's very helpful to readers to keep the "subthreads" about particular issues separate, while at the same time bundling them together for ease of mail-handling.

I did not quite get the user role part.A command line utility runs on the server on which a software instance runs, just like a MySQL command line utility.You will need physical access to the system or atleast the shell.I believe you cannot expect every moderator of the list to have that kind of access. From my point of view, the tool will be used by the list owner or the server admin, just like the MySQL shell,which can be used only if you have access to system shell.However, User/Role management can be imposed by including a login for the shell,if necessary.Again,that's not possible for the command tools.

Why not? The CLI tools will have access to the user database, so in theory you could authenticate. In *practice*, this may be outside of the scope of your project because there's no provision for authentication in the current RESTful interface; you end up restricting to connections from localhost.

But by the same token, past projects have decided to connect to Postorius rather than Mailman itself precisely because Postorious *does* maintain roles and credentials for users. Again, probably beyond the scope of your project, but for precisely this reason it has been proposed a few times that the authn/authz part of Postorius be broken out into a separate module.

And Yes.Users will be a part of this. I prefer to build the other two first.Many methods that can come under User class is better suited under the other two.For eg, for adding a moderator to the list, you can do, *list --addmoderator user_id , *which should be under the List class*. *But the same from user point of view, would be a complicated and less intuitive command, *user **user_id **--addmoderator **--list list_id *. So, after the list and domain functions are built, It will be more clear what the user class must do.

I agree with your logic here.

But I find the text very difficult to read. There should be at least one space after a sentence-ending period ("Yes.Users" looks like a class attribute!) And I have no idea what the semantics of "*" is intended to be.

About optparse, I actually meant argparse,sorry about that :). And thanks for the style guide tip.

Despite the current thread on python-dev<wink target="Barry"/>, I strongly recommend the pep8.py tool (available on PyPI as well as upstream: https://github.com/jcrocholl/pep8/). pyflakes, pylint, and pychecker are also good tools, but their orientation is a bit different, and you may or may not find them useful (and in particular you may find after a while that you *never* get warnings from them).