On Mar 19, 2008, at 16:30, Christian Heimes wrote: > Nicholas F. Fabry schrieb: >> This is a query for information as to how to proceed. I am not a >> professional programmer, but I use Python a great deal to help me >> in my main job, which involves designing schedules for a global >> airline. As such, I use datetime (and dateutil) extensively, and >> after much use, I have come to some conclusions about their >> utility, and how to improve them. Some of these changes are quite >> minor and would result in a large increase in utility (low hanging >> fruit), while some changes are major, and would result in less >> obvious benefits - but these changes would increase the 'Python >> Zen' of them. >> So - where should I propose these changes? Here? python-dev? >> Should I write up a full PEP or should I just give a more informal >> outline with code samples? I would volunteer to help maintain/ >> improve datetime, but I don't speak C at all, unfortunately, and >> datetime appears to be in C. > > Please write a detailed but not too long proposal to the Python > ideas mailing list. The proposal should explain how you like to > improve the datetime module. But *please* don't write a novel. > You'll get more attention when the signal to noise ratio is high. A > bullet list of features is easier to read than a long text block. >
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. I have to sign up for that mailing list - I will do so, and submit my ideas there. 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? > I'm a core developer and I may be interested in mentoring your > proposal. I can guide you through the process, review code and > commit it. > Thank you very much for the offer - I greatly appreciate it. I must admit, my motivation is because Python made programming so much fun for me again (my first machine was a Sinclair ZX80, long, long ago), and I want to improve this part of the language so datetime calculations are clean and neat (like the rest of Python) and don't force programmers to manually go through what the library should do for them. > Yes, the datetime module is written in C. But we may move the C code > to _datetime and create a facade module in Python. > That would be excellent for me, because the underlying datetime routines work correctly and quickly; it's the 'topmost' layer that needs to be improved to do the right thing. And, I could then actually write/maintain the Python code in the facade module, rather than request someone else 'do it for me' in C. To summarize my proposal VERY briefly: - Make aware datetime objects display in local time, but calculate/ compare in UTC. - Raise exceptions when an illegal or ambiguous datetime is instantated. Thank you again, Nick > Christian -- http://mail.python.org/mailman/listinfo/python-list
