- Introduction - I propose to rewrite the Python library's mailbox module to support mailbox modification. I would extend the module's API (e.g., mailboxes would sport dictionary-like mapping) and enhance certain existing functionality (e.g., message objects would maintain mailbox-format-specific attributes). Full backward compatibility would be maintained. Python already offers robust support for mail transfer (via smtplib, imaplib, and poplib) and representation (via email). With the proposed enhancements, Python would offer similarly extensive support for local mail storage, filling a noticeable[1-11] void in the library's mail-handling capabilities---by offering complete support for more mailbox formats than most MUAs. [1] http://groups-beta.google.com/group/comp.lang.python/msg/28dc1cd5680dafa8 [2] http://groups-beta.google.com/group/comp.lang.python/msg/47c9669bf9e260f0 [3] http://groups-beta.google.com/group/comp.lang.python/msg/7e7a6ad03201dc8c [4] http://groups-beta.google.com/group/comp.lang.python/msg/98445a97f838f185 [5] http://groups-beta.google.com/group/comp.lang.python/msg/b33808d19bd55d43 [6] http://groups-beta.google.com/group/comp.lang.python/msg/7050ff54d5ccfb98 [7] http://groups-beta.google.com/group/comp.lang.python/msg/2fd0a01736bbb31f [8] http://groups-beta.google.com/group/comp.lang.python/msg/172abac4d6c455d1 [9] http://groups-beta.google.com/group/comp.lang.python/msg/9f99a0213ec36037 [10] http://groups-beta.google.com/group/comp.lang.python/msg/2532bc5de270f837 [11] http://groups-beta.google.com/group/comp.lang.python/msg/a730ceba1624b341 - Design - (I have posted online[1] some skeleton code with empty class and method declarations to show some details of my proposed module design, two heavily-commented examples of code using the API, a diagram of the proposed class hierarchies, and a copy of this proposal.) Two class hierarchies would be defined, a Mailbox hierarchy and a Message hierarchy. The Message hierarchy would be rooted at email.Message. In both hierarchies, subclasses would implement format-specific operations. Mailbox objects would behave as dictionaries. Message objects would have the normal behavior of email.Messages, along with format-specific behaviors. A Mailbox's keys would be small, opaque objects meaningful to the Mailbox instance that issued them. Its values would be Message objects. Each time a message was requested, a new Message instance would be created. The Message would have no special relationship to the Mailbox that created it. Messages would only provide behaviors that were independent of the particular mailbox from which they were derived (although presumably not of the format of that mailbox). For example, MaildirMessage would provide get_flags() but not get_uniq(), and MboxMessage would provide get_from() but not get_byte_offset(). Messages could be instantiated without arguments, just as email.Messages can. They could also be initialized based on existing Messages. Any format-specific information in the existing Message would be converted to the new Message's format if the new Message could represent it. For example, a MaildirMessage constructed from an MboxMessage containing a "Status: O" header would have its own "S" flag set and the "Status: O" header omitted (unless requested otherwise). [1] http://gkj.freeshell.org/summer_of_code - Testing and Documentation - As I proceeded to implement the module, I would also write a suite of test cases sufficient to thoroughly ensure that it behaves as it should---that all of the methods of each class perform their tasks correctly in typical and corner cases and that they fail (as appropriate) according to their documentation. The module would be sufficiently straightforward that these tests could easily provide complete (or very, very nearly complete) code coverage and test a great many common execution paths. In addition to ensuring that the module complies with published or conventional standards for the various mailbox formats, I would carefully verify that it conformed to the expectations of the usual MUAs for each format (for example, that Rmail and the mailbox module treated Babyl mailboxes in the same way). I would also write comprehensive documentation of the module in the standard LaTeX format for Python documentation. I expect the effort and care I put into this to be on the same order of magnitude as that involved in developing the module itself. - Implementation Considerations - See: http://gkj.freeshell.org/summer_of_code/implementation_considerations.txt - About Me - I'm a first-year computer science major at the University of Maryland, College Park, where (much to my surprise, and somewhat to my chagrin) I had the highest overall grade of all 150-odd people in each of my two introductory classes. In the past I've been moderately active on Debian mailing lists[1], I've submitted or helped with various bug reports (one[2], of which I'm particularly proud, had left the packaged maintainer "at a complete loss"), and overall I'm a great fan of free software and the Stallman-, Torvalds-, Raymond-esque community. Although I've never actually written a significant amount of code for a FOSS project, I've been on the verge of buckling down and doing so a number of times (particularly for ratpoison[3], vim, Debian, and Python), and the Summer of Code program has greatly re-kindled my interest. Although I am only a first-year student, I am confident that I can provide a polished and robust implementation of the module. I've been programming on my own for about six years now, and I've lurked on FOSS developer's mailing lists, read relevant books[4], inspected the source of well-written programs, and contemplated at length the style and generality of my own small programs enough to be competently familiar with what constitutes good software development. [1] http://www.google.com/search?q=site:lists.debian.org+gkj%40gregorykjohnson.com [2] http://bugs.debian.org/202130 [3] http://www.nongnu.org/ratpoison/ [4] Among them: The Practice of Programming (Kernighan & Pike), Code Complete (McConnell), The Art of UNIX Programming (Raymond), C Interfaces and Implementations (Hanson) - Conclusion - If my application is approved, I will begin development promptly. I will also promptly post to python-dev a brief description of the changes I have in mind, to see if anyone has any comments and to try to get prima facie support for incorporating the changes into the library. (I hope it will be sufficiently easy to get this support, given that the changes will be backward-compatible improvements to an existing module and remain clearly within the module's current problem scope.) I will also, later, solicit feedback from potential user's via python-list. Throughout the development process, I will keep my mentor thoroughly informed of my progress. If some of the proposed changes were deemed undesirable by Guido or others, I would be more than happy to accomodate such decisions. Within reason, I would also be willing to undertake additional related changes to the module if any were deemed appropriate. I will of course be willing to license my code to the PSF as customary. If you require any clarifications or additional information to evaluate my application, I will attempt to promptly provide it. I look forward to embarking on this project, and I eagerly await a decision.