[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Obsolescence Python 3.5 support plan

From: EricZolf
Subject: Re: Obsolescence Python 3.5 support plan
Date: Sun, 7 Jun 2020 09:20:41 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0


On 06/06/2020 14:07, Frank Crawford wrote:
> On Thu, 2020-06-04 at 09:44 -0400, Derek Atkins wrote:
>> So long as there isn't a client-server wire-format incompatiblity
>> with
>> older 2.x versions, I don't care!  (I want to ensure we never make
>> that
>> same mistake again of a wire incompatibility due to a change in
>> underlying tooling).

Just to be clear: we will break interfaces also in the future but we
will do our best (but also not more) to break them across 3 versions
instead of only 2, giving you one middle version to do your migration.

Telling you anything else would be a promise to obsolete rdiff-backup.

> And the only way to do that is to move to your own protocol over the
> wire instead of using something that is tied to low-level python primitives.

I slightly disagree with this statement: with a concept of client/server
protocol version mapped to a pickle protocol version [1] we could
probably avoid the issue.

Actually, while writing this e-mail, I checked the code and noticed that
it's enforcing pickle version 1 so the issue isn't the pickle protocol,
the issue is solely the bytes vs. str vs. unicode change between python
2 and 3. There is not much we could have done about it IMHO.

> Saying that, doubt that pickles will cause issues in the near future,
> and so it is more likely to break due to change in function names
> within rdiff-backup.

We could enforce protocol 5 to infuriate our users but we won't do this
;-) Seriously, we should move to protocol 3 or 4 (known since Python 3.4
so no issue with incompatibility), it should improve speed and resilience.

KR, Eric

reply via email to

[Prev in Thread] Current Thread [Next in Thread]