Decode byte pattern into string using proper encoding

[nicolasbock]

The IMAP response is str and a re.match() needs to use a str type pattern. Depending on the encoding supported by the IMAP response, the literal patterns need to be decoded using the correct (supported) encoding.

[nicolasbock]

@nicolas33 I might be totally off here, but if I understand str vs. bytes correctly then the literal patterns need to be decoded before the regular expression is compiled. Like I said, I might be totally off here :sweat_smile:

[nicolas33]

We bundle the python2 version only of imaplib2. There have been work on imaplib2 for python3 at https://github.com/imaplib2/imaplib2. However, this version was declared untested and beta by the author (Piers). Sadly, the full imaplib2 project died soon after.

I wonder if a new repository for offlineimap-py3 with imaplib2.py3 would make sense for people wanting to contribute on this. Of course, this would need a maintainer.

[nicolasbock]

You don't think the current version could be slowly lifted to support Python 3?

[nicolas33]

I think that deep changes in offlineimap would need a maintainer, either way.

[nicolasbock]

What kind of requirements would you have for a maintainer? And what kind of time involvement do you think it would take to maintain such changes?

[nicolas33]

I don't have requirements. Maintaining open source projects is mainly about perseverance and traction.

I'm open to relay the links to all the new forks of offlineimap claiming development in this area. I'm fine to insert a new section on top of our README and relay the news to the mailing list, twitter, etc.

There are many ways to get python3 support from the most code conservative way to a new start from scratch. I can't define the required time because this depends on this strategy and a lot of other factors like the amount/complexity of contributions, the internal project workflow, the project policies, the level of offered support, etc.

[nicolas33]

Also, the required time depends on technical skills like python programming and all the tooling (git, travis, rst/sphinx, shell scripting, etc).

[nicolasbock]

Let me make sure I understand your position by rephrasing what I think you wrote:

You prefer to not merge any Python 3 work in this repository, and to do this kind of work in a fork.

If you are open to including this change in this repository though, I could help you maintain this change and changes like it.

[nicolas33]

You prefer to not merge any Python 3 work in this repository, and to do this kind of work in a fork.

Exactly this. At least, as long as we have enough users expecting offlineimap-py2 to be maintained.

I'd rather have python3 support in a fork to not have issues because of the python3 migration. The reason of this policy is that the required changes are very deep. I'd like to avoid issues for the py2 users while doing this work.

Also, getting rid of python2 while migrating to python3 is a very BIG plus. All the past attempts to support both py2 and py3 failed.

[nicolas33]

Forgot to say that I won't contribute to the migration, though.

[nicolasbock]

Ok thanks! I'll close this then.