Interest in refactoring dup_time.py

Yes, we are interested! Duplicity was written back in 2002 and 1.5.2 Python was extant then. That's why some of the code is somewhat out-of-date. We would appreciate all the help we can get. Thanks!

PS - In the testing module there are a fair number of date/time tests. Those will need to be updated and pass as well.

I've got a few more questions. If the mailing list isn't the right place for them, let me know.

First off, I want to say that I have high respect of code that is time proven and works, even if it's not written in the latest greatest language :)

That being said, I still think that I'd be able to make some careful contributions.

My first question:
Would it be acceptable to raise the minimum required python version to 2?

Second question:
My impression is that the dup_time module is mainly used for parsing file names into an internal time representation and vice versa. Therefore, no matter what changes I make here, I'll have to be very careful not to break backwards compatibility in parsing the file names.

I'd probably start working by writing tests for all the file name formats that need to be covered and then ask here on the list for confirmation that the tests are exhaustive.
Afterwards, I can start work on refactoring the module by making use of datetime and pytz.

Does that sound reasonable?

Never mind, I just realized that the minimum required Python version has already been raised to 2.7

On 11/11/2017 14:53, Konstantin Schubert wrote:
> Question #660463 on Duplicity changed:
> https://answers.launchpad.net/duplicity/+question/660463
>
> Konstantin Schubert gave more information on the question:
>
> I've got a few more questions. If the mailing list isn't the right place for them, let me know.
>
> First off, I want to say that I have high respect of code that is time
> proven and works, even if it's not written in the latest greatest
> language :)
>
> That being said, I still think that I'd be able to make some careful
> contributions.
>
> My first question:
> Would it be acceptable to raise the minimum required python version to 2?
>
> Second question:
> My impression is that the dup_time module is mainly used for parsing file names into an internal time representation and vice versa. Therefore, no matter what changes I make here, I'll have to be very careful not to break backwards compatibility in parsing the file names.
>
> I'd probably start working by writing tests for all the file name formats that need to be covered and then ask here on the list for confirmation that the tests are exhaustive.
> Afterwards, I can start work on refactoring the module by making use of datetime and pytz.
>
> Does that sound reasonable?
>

Konstantin,

it does. i am wondering tough why you want to rewrite a perfectly functioning part of duplicity when there are bugs and feature request en masse on launchpad already. just a tought.

..ede/duply.net

Hi @edso, I guess that's a valid question.

I would not re-write it if I did not believe that I will be able to significantly update and simplify the code.

Simpler code will allow others to better address bugs and feature requests.

Dear Konstantin,

Many thanks for your intended contribution to the project. As Kenneth says, this would be greatly appreciated.

I think refactoring is extremely important and something I spend a bit of time on. There are quite a few areas where the code can be dramatically improved, which helps newcomers and makes it easier for those more familiar to make changes without breaking a bunch of things. I also think that refactoring an existing module with extensive test cases is a good way to get up to speed with the codebase.

http://bazaar.launchpad.net/~duplicity-team/duplicity/0.8-series/view/head:/README-REPO
Describes checking out the code and starting.

http://bazaar.launchpad.net/~duplicity-team/duplicity/0.8-series/view/head:/README-TESTING
Describes how to test your code. For what you are doing you should not need the docker containers and the tox method makes sense. Please run all tests on your branch (testing/run-tests) before proposing a merge, to ensure that all tests pass.

When you come to commit, please commit to lp:duplicity, which is the 0.8-series (for new code/features).

I will propose this as the answer to close this ticket off, but please do ask any questions on the duplicity mailing list:
https://lists.nongnu.org/mailman/listinfo/duplicity-talk