Merge lp:~gtg-contributors/gtg/new-date-class into lp:~gtg/gtg/old-trunk
Status: | Merged | ||||
---|---|---|---|---|---|
Approved by: | Izidor Matušov on 2012-02-14 | ||||
Approved revision: | 823 | ||||
Merged at revision: | 1089 | ||||
Proposed branch: | lp:~gtg-contributors/gtg/new-date-class | ||||
Merge into: | lp:~gtg/gtg/old-trunk | ||||
Diff against target: |
959 lines (+300/-282) 10 files modified
GTG/core/filters_bank.py (+6/-6) GTG/core/requester.py (+0/-1) GTG/core/task.py (+17/-20) GTG/gtk/browser/browser.py (+9/-13) GTG/gtk/dbuswrapper.py (+8/-8) GTG/gtk/editor/editor.py (+24/-26) GTG/plugins/evolution_sync/gtgTask.py (+6/-5) GTG/plugins/rtm_sync/gtgTask.py (+6/-5) GTG/tools/dates.py (+216/-190) GTG/tools/taskxml.py (+8/-8) |
||||
To merge this branch: | bzr merge lp:~gtg-contributors/gtg/new-date-class | ||||
Related bugs: |
|
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Paul Natsuo Kishimoto (community) | Approve on 2010-12-17 | ||
Bryce Harrington (community) | code | 2010-06-20 | Approve on 2010-07-14 |
Review via email:
|
Description of the change
This branch almost entirely rewrites the various classes that were contained in GTG/tools/dates.py.
When the GTG UI and backend are separated over DBus, Python objects (including built-in and custom dates) cannot be passed directly. Strings can be used instead. The new Date class in this code is designed to always obey:
Date(str(d)) = d
for any Date instance d, even for special dates ('soon', 'later', etc.). As a result, neither client nor server code need make any distinction between FuzzyDates or RealDates or so on; it can simply construct Date() with the information passed over DBus.
The class also follows some of the semantics from the Python datetime module; for example:
d1 = datetime.
d2 = Date.soon() # get a Date instance representing the special date 'soon'
I have tested the branch in several ways, but some additional experimentation would be appreciated to see if any bugs were introduced.
Luca Invernizzi (invernizzi) wrote : | # |
Paul Natsuo Kishimoto (khaeru) wrote : | # |
I had — pickling is fast, but the output isn't necessarily easy to parse for non-Python code that might be interacting with the DBus API.
Luca Invernizzi (invernizzi) wrote : | # |
FYI, I found out that in current trunk we have that:
string = str(get_
That would let us keep the subclasses about fuzzy dates, which could be useful if we decide to expand our "fuzzyness" support.
Paul Natsuo Kishimoto (khaeru) wrote : | # |
I tried to make Date.parse(...) a replacement for get_canonical_
The difference between Date.parse and Date.__init__ is that parse() checks a lot more possible formats, while __init__() expects simpler input and also recognizes various objects like datetime. __init__() is more for internal use (hopefully also faster, though I haven't checked...)
To handle more formats (e.g. alien ones belonging to various remote backends), I would extend parse() and keep __init__() as-is.
They are about equivalent, but I think it is easier to add more constants like TODAY, SOON, etc. than to subclass Date. This way, any new fuzzy dates will have to behave in a way that is consistent with the existing ones.
Bryce Harrington (bryce) wrote : | # |
Looks good. I like the elimination of difference between RealDate and FuzzyDate.
I can't think of any other fuzzy date terms that would be worth adding, but I'm sure someone will think of one or two, so being able to extend that would be a good thing.
Paul Natsuo Kishimoto (khaeru) wrote : | # |
Anybody in gtg-devs feel like committing this? :)
Paul Natsuo Kishimoto (khaeru) wrote : | # |
Once again, can this be either committed or rejected?
I hate to raise this after you did the work, but have you considered the possibility of using the pickle module? The serialization is done automatically like "pickle. loads(pickle. dumps(datetime. datetime. now())) "
I don't know how fast it is though.