Nicholas F. Fabry
nick.fabry at coredump.us
Wed Mar 19 22:40:39 CET 2008
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
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
> 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,
More information about the Python-list