[PATCH 01/15] Raise exceptions as defined in PEP 3109
nicolas.s-dev at laposte.net
Fri May 13 13:03:32 BST 2016
On Fri, May 13, 2016 at 08:35:41AM +0200, Łukasz Żarnowiecki wrote:
> You are right, it is not compatible with Python2. I was not careful
> enough this time. We have three possibilities here:
> * Use reraise from six module.
>  https://pythonhosted.org/six/#six.reraise
> * Write wrapper around raise.
> I tried this one and I was successful, it is quite tricky, cause the
> syntax from Python2 is not compatible with Python3, so a little
> hackery is necessary. I was thinking about putting it into
I'm fine with both above alternatives. I tend to think that our own
wrapper of raise will be somewhat a rewrite of six.reraise(). The other
good point about six is all the other features already supported by this
lib that we might use later.
The bad news is about the license. I'm not sure we can bundle and use
this lib without adding a new clause in the current GPL licence. This
would be sad because this would mean contacting all the contributors
requesting them to agree with the new clause. This was previously done
by Sebastian for adding the OpenSSL clause and this is a real work.
There are currently 109 contributors in `git shortlog -ns`.
I'm cc'ing both Ilias and Sebatian because the issue raised about the
OpenSSL was done by Debian. They might have hints for us and the AS-IS
licence might be compatible with the GPL. I don't know.
> * Abandon Python2, most popular distributions ships with Python3
> installed, but RHEL 6 not, but it is still supported.
> What do you think?
I'm not sure we can safely abandon Python 2. I'm not concerned by Python
2 compatibility myself but I wonder some users will complain. I would
not decide to abandon Python 2 without polling our users first. IOW,
this means communicating about that on twitter, this mailing list, the
blog, create an issue and see if we have complaints in a reasonable
amount of time.
Also, I wonder some users might be tempted to support a fork for Python
2. This would mean maintaining yet another software and I'm definetly
not going to do this job myself. We could invite a maintainer to the
team for this purpose, though.
To be clear, I'm not opposed to a migration to Python 3 only. I'd even
say that time has come. Still, we can't decide to do this without
carefully requesting the users and see if the complaints are marginal
More information about the OfflineIMAP-project