Nicholas F. Fabry schrieb: > Thank you for the prompt response and suggestion! I am writing up a > proposal presently. There are, however, two broad category of changes > - the 'easy' changes, which could be accomplished with little > additional effort, and the 'hard' changes, which would require > significant reworking of the datetime class (or a wrapper around it). > I was going to break my proposal up into two parts, the easy part and > the hard part. Does that sound like a good idea? Or should I unify > the two? The prime purpose of all the changes, easy and hard, is to > make timezone handling accurate and clear, reduce and make clearer the > (application programmer) code required to use them, and give more > informaton to the programmer about errors, not silently assume > something and pass them.
Yes, it sounds like a good idea. The low hanging fruits (aka easy tasks) could be implemented for 2.6 and 3.0. The more complex tasks may have to wait for 2.7 and 3.1 Apropos time zones. A while ago I proposed the inclusion of pytz. But Stuart argued that the tz database may change monthly so I retracted my proposal. But Stuart has proposed some improvements for datetime's tz class. I suggest you contact him. > Please clarify how long a novel is? The problem with the modules are > not bugs, they are problems with real world use scenarios that result > in inescabably ugly code without improvements to the module - so the > explanations involve code samples and use cases... so they may be > 'long'. Could you suggest a maximum number of (70 char) lines, or an > example of an overly long proposal? Some people tend to start their postings like: In the year 2008 after the birth of Christ I, the son of Jone, son of James ... Do you get my point? :] I suggest you start with a short introduction of yourself and your proposal. Short paragraphs and short sentences are easier to read than long. You'll do fine ;) Christian -- http://mail.python.org/mailman/listinfo/python-list
