Add offset or translation function to Interval

[exoriente]

Hi Alexandre,

I love this library. It comes close to almost everything I would expect from a standard library for handling intervals. There's one feature I'm missing that I would love to see added or add myself, and that's a built-in way to add a value to all bounds of an interval (whether atomic or union).

I realize this can be done with .apply() (in fact, it's even one of the examples in the readme), but in the project where I would love to use portion it would be such a common occurrence it becomes really tempting to build in support for it, instead of handling it with lambda functions or an external wrapper for .apply.

In the planning software I'm working on we use timedelta intervals, tasks to be planned relative to some event time. Adding the event time to the timedelta interval would yield an interval of datetimes that represents the planned task. It seems to me that these and other use cases could be common enough to warrant a convenient function, like.offset(value) or .translate(value), that would be a shortcut for .apply(lambda x: (x.left, x.lower + value, x.upper + value, x.right)).

What do you think? Would you be open for a pull-request for it?

Best regards, Maarten

[AlexandreDecan]

Hello Marteen,

First of all, thank you for those kind words about 'portion'. It's always nice to see this kind of feedback and to see that the library is useful to others ;-)

Concerning the .offset method, I understand its interest and the proposed use-case. However, portion aims to remain as generic as possible, and proposing such a method finally applies only to objects supporting the + operator, which is not necessarily the case for all objects. Even if I realize that the main use-cases of portion are typically for objects implementing + (e.g., integers, floats, dates, etc.), I'm reluctant to implement .offset directly in Interval because of this "not-that-generic" thing, and also because it is finally easy enough, as you said, to implement a wrapper over .apply to offer the same service.

Ideally, what would be really practical and useful would be to be able to "add" methods on the fly on portion objects, a bit like the "extension class" proposed in Kotlin. This would allow users of the library to easily add new "services" in the form of methods (as opposed to what can already be done via functions). However, binding new methods on a class is not very "pythonic" and there is no specific reason to support this "out-of-the-box" in portion (since that's something a user can easily do in his own code, by e.g., doing Interval.func = custom_func if he doesn't care about bound methods, or about the scope of this ;-))

[exoriente]

Clear. I completely understand your preference to keep the library as generic as possible. Thanks for taking the time to look at the suggestion. I'll probably will be using portion either way.

(In the mean time I already wrote a PR for .offset. But that was fun to do even if it won't be used!)

[AlexandreDecan]

I'm glad you won't give up with portion because of this :-D

On a more serious note, I am sorry I had to answer in the negative. It is always difficult to refuse a good contribution for "philosophical" reasons.

[exoriente]

Well if you're right, you're right. And the philosophical reasons are often the best to keep something pure and generic. I was immediately convinced!

…

On Mon, Jan 18, 2021 at 11:20 AM Alexandre Decan ***@***.***> wrote: I'm glad you won't give up with portion because of this :-D On a more serious note, I am sorry I had to answer in the negative. It is always difficult to refuse a good contribution for "philosophical" reasons. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#52 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOG443GTNJ7NCCWDYQRBDXDS2QDNJANCNFSM4WFQXZUQ> .