Menu
▾
▴
imaplib2-devel — imaplib2 development list
You can subscribe to this list here.
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(20) |
Jun
(38) |
Jul
(8) |
Aug
(9) |
Sep
(5) |
Oct
(8) |
Nov
|
Dec
(10) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2012 |
Jan
(19) |
Feb
(9) |
Mar
|
Apr
(8) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(5) |
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(4) |
Oct
(4) |
Nov
|
Dec
(3) |
| 2016 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(15) |
Jul
(5) |
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
From: Nicolas S. <nic...@la...> - 2018-10-30 10:16:39
|
Hi Piers, It appears from https://sourceforge.net/projects/imaplib2/ that the official project is officially maintained at https://github.com/imaplib2/imaplib2 However, nobody looks active there. Is there anyone maintaining this project? Thanks, -- Nicolas Sebrecht |
|
From: Piers L. <pi...@ja...> - 2017-11-15 02:25:02
|
To all whom it may concern: I've agreed with the maintainers of the imaplib2 fork at https://github.com/imaplib2/imaplib2 that further development will be coordinated there. The sourceforge site will remain for archival purposes. Piers Lauder |
|
From: Piers L. <pi...@ja...> - 2017-11-13 09:58:14
|
Hi Tobias, I'm happy for you to take over the publication to PyPi. I've left a comment to that effect on the issue forum @ https://github.com/bcoe/imaplib2/issues/26 Piers |
|
From: Tobias G. <jun...@ya...> - 2017-11-13 08:13:49
|
Hi, I'm using imaplib2 in a project, but the PyPi package is hardly maintained and has gotten out of date. Could you please publish the package yourself? If you do not have time, I'd love to help out. I've contacted the maintainers of the PyPi package already if they want to hand the package over, but, unsurprisingly, they don't just want to give it to some stranger. -> https://github.com/bcoe/imaplib2/issues/26 -- Tobias |
|
From: Piers L. <pi...@ja...> - 2017-04-08 23:02:31
|
no, i hadn't seen those. thanks, I'll check them out. On 8 April 2017 7:11:25 PM AEST, Chris Coleman <ch...@es...> wrote: >Piers, > >OK. Thank you. By the way, when you patched imaplib2 to support UTF-8 >( >RFC6855 ), have you had a look at RFC6532 Internationalized Email >Headers, or this UTF-8 RFC6855 patch for the imaplib standard library? > >https://bugs.python.org/review/21800 > > >On 4/7/17 10:37 PM, Piers Lauder wrote: >> On Fri, 7 Apr 2017 21:37:22 -0400, Chris Coleman wrote: >> > >> > Piers, >> > >> > A UTF-8 internationalized headers protocol issue has been >reported, as >> > happening during the communications between imaplib2 and the >Germany >> > localized Microsoft Exchange Server. Maybe you could take a >look. >> > Imaplib2 is returning back to the application, the >internationalized >> > versions of the header names, at a place when this probably >shouldn't be >> > happening. Maybe Imaplib2 should retain these headers for >possible >> > later use. >> > https://github.com/OfflineIMAP/offlineimap/issues/449 >> >> I'm going to have to defer to the people on the frontline, as I have >no >> easy way to debug UTF-8 IMAP problems here. I would welcome bug fixes >> once sorted out of course! >> >> Piers >> > >------------------------------------------------------------------------------ >Check out the vibrant tech community on one of the world's most >engaging tech sites, Slashdot.org! http://sdm.link/slashdot >_______________________________________________ >Imaplib2-devel mailing list >Ima...@li... >https://lists.sourceforge.net/lists/listinfo/imaplib2-devel |
|
From: Chris C. <ch...@es...> - 2017-04-08 09:11:37
|
Piers, OK. Thank you. By the way, when you patched imaplib2 to support UTF-8 ( RFC6855 ), have you had a look at RFC6532 Internationalized Email Headers, or this UTF-8 RFC6855 patch for the imaplib standard library? https://bugs.python.org/review/21800 On 4/7/17 10:37 PM, Piers Lauder wrote: > On Fri, 7 Apr 2017 21:37:22 -0400, Chris Coleman wrote: > > > > Piers, > > > > A UTF-8 internationalized headers protocol issue has been reported, as > > happening during the communications between imaplib2 and the Germany > > localized Microsoft Exchange Server. Maybe you could take a look. > > Imaplib2 is returning back to the application, the internationalized > > versions of the header names, at a place when this probably shouldn't be > > happening. Maybe Imaplib2 should retain these headers for possible > > later use. > > https://github.com/OfflineIMAP/offlineimap/issues/449 > > I'm going to have to defer to the people on the frontline, as I have no > easy way to debug UTF-8 IMAP problems here. I would welcome bug fixes > once sorted out of course! > > Piers > |
|
From: Chris C. <ch...@es...> - 2017-04-08 02:23:12
|
Piers, A UTF-8 internationalized headers protocol issue has been reported, as happening during the communications between imaplib2 and the Germany localized Microsoft Exchange Server. Maybe you could take a look. Imaplib2 is returning back to the application, the internationalized versions of the header names, at a place when this probably shouldn't be happening. Maybe Imaplib2 should retain these headers for possible later use. https://github.com/OfflineIMAP/offlineimap/issues/449 On 7/5/2016 12:28 AM, Piers Lauder wrote: > Hi Chris, > > On looking deeper into the new code, I'm not sure it is fully debugged(!) > > There are places where I would have thought they ought to be doing UTF-8 > matches on the data received from the server, but the code hasn't been > changed. > > So I'm inclined to wait a bit to see if further changes are made down > the track. > > I will however add the changes as I think they *ought* to be done to my > Python3 version of imaplib2 ("imaplib2.py3" on sourceforge) and see if > anyone can test it for me. > > Piers > > > By the way, someone else just sent me a really neat implementation of imaplib with IDLE using AIO - see this:- > https://github.com/bamthomas/aioimaplib > > It's a work in progress, but seems really good code. > > > -- --- Chris Coleman Espace LLC 860-576-9526 |
|
From: Piers L. <pi...@ja...> - 2017-03-01 02:08:10
|
Definately a typo - thanks for finding it!
__all__ is an instruction to the interpreter on what names are to be imported by the "from <mod> import *" statement, so probably noone has tried to use either of those two routines directly, from imaplib3 at least.
On Tue, 28 Feb 2017 19:58:58 +0000, Boylan, Ross wrote:
>
> Hi everyone. Thanks for your work on this library.
>
> imaplib2.py3 near the top has
> __all__ = ("IMAP4", "IMAP4_SSL", "IMAP4_stream",
> "Internaldate2Time", "ParseFlags", "Time2Internaldate"
> "Mon2num", "MonthNames", "InternalDate")
> Shouldn't there be a comma at the end of the 2nd line, after "Time2Internaldate"?
>
> I noticed it when I did a diff vs the version 2 code, which has the comma.
> Code obtained via git yesterday.
>
> Does this mean no one has actually used the code? I suppose python just concatenates strings to get Time2InternaldateMon2num. Confirmed after renaming code to im3.py and importing:
> >>> im3.__all__
> ('IMAP4', 'IMAP4_SSL', 'IMAP4_stream', 'Internaldate2Time', 'ParseFlags', 'Time2InternaldateMon2num', 'MonthNames', 'InternalDate')
>
>
>
> Ross Boylan
|
|
From: Boylan, R. <Ros...@uc...> - 2017-02-28 19:59:13
|
Hi everyone. Thanks for your work on this library.
imaplib2.py3 near the top has
__all__ = ("IMAP4", "IMAP4_SSL", "IMAP4_stream",
"Internaldate2Time", "ParseFlags", "Time2Internaldate"
"Mon2num", "MonthNames", "InternalDate")
Shouldn't there be a comma at the end of the 2nd line, after "Time2Internaldate"?
I noticed it when I did a diff vs the version 2 code, which has the comma.
Code obtained via git yesterday.
Does this mean no one has actually used the code? I suppose python just concatenates strings to get Time2InternaldateMon2num. Confirmed after renaming code to im3.py and importing:
>>> im3.__all__
('IMAP4', 'IMAP4_SSL', 'IMAP4_stream', 'Internaldate2Time', 'ParseFlags', 'Time2InternaldateMon2num', 'MonthNames', 'InternalDate')
Ross Boylan
|
|
From: Piers L. <pi...@ja...> - 2016-08-03 04:23:36
|
Ok, if you can test this out enough to satisfy your conditions, that would be great and I'll incorporate the changes. It would be good to get an idea of a better default timeout time as well, as the number I used was pretty much a guess, and networks are faster now. On Tue, 2 Aug 2016 16:42:25 -0400, Chris Coleman wrote: > > > > On 8/2/2016 2:35 PM, Nicolas Sebrecht wrote: > > On Mon, Aug 01, 2016 at 10:20:22PM +1000, Piers Lauder wrote: > >> Hi, > >> > >> Seems a reasonable supposition to me. > >> > >> Have you tried testing it by setting a timeout using the optional timeout argument to IMAP4()? (The default is no timeout.) > > No, I didn't because I don't think a "global" timeout is good enough. > > I'll try to check the timeout is working well. > > > > Good point Nicolas, one fixed global timeout is isn't good enough. > The short timeout, for task which require no data processing, maybe > 10-15 seconds. > The long timeout, for the commands which require the server to access > the disk, to return mail data, to read/write disk, to search for a > message by a key, to move mail between folder, should be probably 30-60 > seconds. Depending, how many other applications are sharing the same > server, and whether the server is running on SSD, or HD. > These timeouts must be defaults built into the imaplib2 classes, and > enforced by the imaplib2 depending on what imaplib2 is asking for from > the remote imap4 server. > It should be possible for the applications which use the imap2lib > library, to override the defaults by passing new values in to the > constructor, or in a setter method. > > -- > Chris Coleman > Espace LLC > 860-576-9526 > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Imaplib2-devel mailing list > Ima...@li... > https://lists.sourceforge.net/lists/listinfo/imaplib2-devel |
|
From: Chris C. <ch...@es...> - 2016-08-02 20:42:46
|
On 8/2/2016 2:35 PM, Nicolas Sebrecht wrote: > On Mon, Aug 01, 2016 at 10:20:22PM +1000, Piers Lauder wrote: >> Hi, >> >> Seems a reasonable supposition to me. >> >> Have you tried testing it by setting a timeout using the optional timeout argument to IMAP4()? (The default is no timeout.) > No, I didn't because I don't think a "global" timeout is good enough. > I'll try to check the timeout is working well. > Good point Nicolas, one fixed global timeout is isn't good enough. The short timeout, for task which require no data processing, maybe 10-15 seconds. The long timeout, for the commands which require the server to access the disk, to return mail data, to read/write disk, to search for a message by a key, to move mail between folder, should be probably 30-60 seconds. Depending, how many other applications are sharing the same server, and whether the server is running on SSD, or HD. These timeouts must be defaults built into the imaplib2 classes, and enforced by the imaplib2 depending on what imaplib2 is asking for from the remote imap4 server. It should be possible for the applications which use the imap2lib library, to override the defaults by passing new values in to the constructor, or in a setter method. -- Chris Coleman Espace LLC 860-576-9526 |
|
From: Nicolas S. <nic...@la...> - 2016-08-02 19:00:25
|
On Mon, Aug 01, 2016 at 10:20:22PM +1000, Piers Lauder wrote: > Hi, > > Seems a reasonable supposition to me. > > Have you tried testing it by setting a timeout using the optional timeout argument to IMAP4()? (The default is no timeout.) No, I didn't because I don't think a "global" timeout is good enough. I'll try to check the timeout is working well. -- Nicolas Sebrecht |
|
From: Piers L. <pi...@ja...> - 2016-08-01 12:20:36
|
Hi, Seems a reasonable supposition to me. Have you tried testing it by setting a timeout using the optional timeout argument to IMAP4()? (The default is no timeout.) Piers Lauder On Thu, 28 Jul 2016 23:42:33 -0400, Chris Coleman wrote: > > I totally agree with your idea of making timeouts shorter Nicolas. > > There are many requests to the server, such as the example you give, the > imap server should return with the welcome message without needing to > process any data, essentially it's static text. For this, it would seem > reasonable to have the imaplib2 client timeout in 5-10 seconds max. > > For other requests involving actual mail data, the timeout should be longer. > > > > On 7/28/2016 11:21 PM, Nicolas Sebrecht wrote: > > Hi Piers, > > > > I've done debug sessions to understand why offlineimap can hang. It > > appears one of our thread might hang waiting for imaplib2 which never > > returns a value. > > > > This happens when I reach the (undocumented) maximum number of > > connections to my IMAP server. I guess they limit connections based on > > the public IP or similar. It looks like IMAP servers "handle" this case > > in quite different ways. > > > > I believe that Gmail drops a previously existing connection. > > > > imap.laposte.net will hold the connection without ever returning a > > welcome message. This sucks hard but I wonder other servers have similar > > behaviour. > > > > Hence, imaplib2 is blocked at line 396 in __init__: > > > > self.welcome = self._request_push(name='welcome', tag='continuation').get_response(...) > > > > I wonder if imaplib2 should not assume a response within the global > > threading.TIMEOUT_MAX range which is "very" long (considered infinite). > > I know that socket.setdefaulttimeout() can handle this, too. We > > currently allow the users to configure a value for this. However, both > > are expected large enough to avoid reaching the timeout while it should > > not. > > > > IOW, I think some very special cases at decisive steps might use a short > > timeout while waiting for a response. The above line 396 falls into this > > case. We know that the time required for a welcome message is definetly > > shorter than for downloading/fetching a mail. So, we might like to add a > > "max_timeout" argument to get_response() at line 191. By using short > > timeouts when applicable, we would avoid hangs or long waits. > > > > > > Also, I wonder that waiting for the welcome message might not be the > > only one case. Some IMAP servers might behave in a similar way for other > > limits: e.g. at authentication time to limit connections in a > > per-account basis. > > > > Thoughts? > > > > -- > Chris Coleman > Espace LLC > 860-576-9526 > > > ------------------------------------------------------------------------------ > _______________________________________________ > Imaplib2-devel mailing list > Ima...@li... > https://lists.sourceforge.net/lists/listinfo/imaplib2-devel |
|
From: Chris C. <ch...@es...> - 2016-07-29 03:42:43
|
I totally agree with your idea of making timeouts shorter Nicolas. There are many requests to the server, such as the example you give, the imap server should return with the welcome message without needing to process any data, essentially it's static text. For this, it would seem reasonable to have the imaplib2 client timeout in 5-10 seconds max. For other requests involving actual mail data, the timeout should be longer. On 7/28/2016 11:21 PM, Nicolas Sebrecht wrote: > Hi Piers, > > I've done debug sessions to understand why offlineimap can hang. It > appears one of our thread might hang waiting for imaplib2 which never > returns a value. > > This happens when I reach the (undocumented) maximum number of > connections to my IMAP server. I guess they limit connections based on > the public IP or similar. It looks like IMAP servers "handle" this case > in quite different ways. > > I believe that Gmail drops a previously existing connection. > > imap.laposte.net will hold the connection without ever returning a > welcome message. This sucks hard but I wonder other servers have similar > behaviour. > > Hence, imaplib2 is blocked at line 396 in __init__: > > self.welcome = self._request_push(name='welcome', tag='continuation').get_response(...) > > I wonder if imaplib2 should not assume a response within the global > threading.TIMEOUT_MAX range which is "very" long (considered infinite). > I know that socket.setdefaulttimeout() can handle this, too. We > currently allow the users to configure a value for this. However, both > are expected large enough to avoid reaching the timeout while it should > not. > > IOW, I think some very special cases at decisive steps might use a short > timeout while waiting for a response. The above line 396 falls into this > case. We know that the time required for a welcome message is definetly > shorter than for downloading/fetching a mail. So, we might like to add a > "max_timeout" argument to get_response() at line 191. By using short > timeouts when applicable, we would avoid hangs or long waits. > > > Also, I wonder that waiting for the welcome message might not be the > only one case. Some IMAP servers might behave in a similar way for other > limits: e.g. at authentication time to limit connections in a > per-account basis. > > Thoughts? > -- Chris Coleman Espace LLC 860-576-9526 |
|
From: Nicolas S. <nic...@la...> - 2016-07-29 03:21:50
|
Hi Piers, I've done debug sessions to understand why offlineimap can hang. It appears one of our thread might hang waiting for imaplib2 which never returns a value. This happens when I reach the (undocumented) maximum number of connections to my IMAP server. I guess they limit connections based on the public IP or similar. It looks like IMAP servers "handle" this case in quite different ways. I believe that Gmail drops a previously existing connection. imap.laposte.net will hold the connection without ever returning a welcome message. This sucks hard but I wonder other servers have similar behaviour. Hence, imaplib2 is blocked at line 396 in __init__: self.welcome = self._request_push(name='welcome', tag='continuation').get_response(...) I wonder if imaplib2 should not assume a response within the global threading.TIMEOUT_MAX range which is "very" long (considered infinite). I know that socket.setdefaulttimeout() can handle this, too. We currently allow the users to configure a value for this. However, both are expected large enough to avoid reaching the timeout while it should not. IOW, I think some very special cases at decisive steps might use a short timeout while waiting for a response. The above line 396 falls into this case. We know that the time required for a welcome message is definetly shorter than for downloading/fetching a mail. So, we might like to add a "max_timeout" argument to get_response() at line 191. By using short timeouts when applicable, we would avoid hangs or long waits. Also, I wonder that waiting for the welcome message might not be the only one case. Some IMAP servers might behave in a similar way for other limits: e.g. at authentication time to limit connections in a per-account basis. Thoughts? -- Nicolas Sebrecht |
|
From: Piers L. <pi...@ja...> - 2016-07-05 04:29:01
|
Hi Chris,
On looking deeper into the new code, I'm not sure it is fully debugged(!)
There are places where I would have thought they ought to be doing UTF-8
matches on the data received from the server, but the code hasn't been
changed.
So I'm inclined to wait a bit to see if further changes are made down
the track.
I will however add the changes as I think they *ought* to be done to my
Python3 version of imaplib2 ("imaplib2.py3" on sourceforge) and see if
anyone can test it for me.
Piers
By the way, someone else just sent me a really neat implementation of imaplib with IDLE using AIO - see this:-
https://github.com/bamthomas/aioimaplib
It's a work in progress, but seems really good code.
|
|
From: Piers L. <pi...@ja...> - 2016-07-05 03:36:50
|
On Mon, 4 Jul 2016 13:08:39 -0400, Chris Coleman wrote: > > Hello Piers, and imaplib2-devel, > > Thanks for imaplib2! > > imaplib in python 3.5.2 has implemented support for RFC-6855, which > supports UTF-8 encoding in mailbox names, usernames, passwords, email > address, and message headers, with the new "enable" method, which looks > for CAPABILITY UTF8=ACCEPT or UTF8=ONLY and replies "ENABLE UTF8=ACCEPT" > to the server. > > https://docs.python.org/3/library/imaplib.html > https://tools.ietf.org/html/rfc6855.html > > Would it be possible request a backport the rfc6855 UTF8 support from > imaplib in python 3.5.2, to imaplib2. This would allow offlineimap, and > other applications which use imaplib2, to communicate with modern imap > servers which are now upgraded and supporting everything UTF8 encoded. > > -Chris Just had a look - seems pretty straight forward - will do. Will let you know... Piers |
|
From: Chris C. <ch...@es...> - 2016-07-04 17:27:03
|
Hello Piers, and imaplib2-devel, Thanks for imaplib2! imaplib in python 3.5.2 has implemented support for RFC-6855, which supports UTF-8 encoding in mailbox names, usernames, passwords, email address, and message headers, with the new "enable" method, which looks for CAPABILITY UTF8=ACCEPT or UTF8=ONLY and replies "ENABLE UTF8=ACCEPT" to the server. https://docs.python.org/3/library/imaplib.html https://tools.ietf.org/html/rfc6855.html Would it be possible request a backport the rfc6855 UTF8 support from imaplib in python 3.5.2, to imaplib2. This would allow offlineimap, and other applications which use imaplib2, to communicate with modern imap servers which are now upgraded and supporting everything UTF8 encoded. -Chris |
|
From: Łukasz Ż. <do...@ou...> - 2016-06-11 07:16:54
|
On Saturday, 11 June 2016 14:03:59 CEST, Piers Lauder wrote: > Thanks for the fix! No problem, next time you can use git am to apply email directly, and then you can use git commit --amend to change the commit message while giving a person a full credit for the patch :) Cheers |
|
From: Piers L. <pi...@ja...> - 2016-06-11 04:04:12
|
On Sat, 11 Jun 2016 00:45:25 +0200, ??ukasz ??arnowiecki wrote: > > Python 3 does not allow to implicitly convert convert bytes objects > to str which causes exception being thrown. > > By initializing oup variable as binary string we no longer rely on > implicit conversion which does not work in Python 3 > > Signed-off-by: Åukasz Å»arnowiecki <do...@ou...> > --- > > The issue was discover when using offlineimap with Python 3 and > outlook.com. > > imaplib2.py | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/imaplib2.py b/imaplib2.py > index 6974639..1cf2303 100755 > --- a/imaplib2.py > +++ b/imaplib2.py > @@ -2294,7 +2294,7 @@ class _Authenticator(object): > # so when it gets to the end of the 8-bit input > # there's no partial 6-bit output. > # > - oup = '' > + oup = b'' > while inp: > if len(inp) > 48: > t = inp[:48] > -- > 2.8.3 Thanks for the fix! |
|
From: Łukasz Ż. <do...@ou...> - 2016-06-10 22:45:35
|
Python 3 does not allow to implicitly convert convert bytes objects to str which causes exception being thrown. By initializing oup variable as binary string we no longer rely on implicit conversion which does not work in Python 3 Signed-off-by: Łukasz Żarnowiecki <do...@ou...> --- The issue was discover when using offlineimap with Python 3 and outlook.com. imaplib2.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/imaplib2.py b/imaplib2.py index 6974639..1cf2303 100755 --- a/imaplib2.py +++ b/imaplib2.py @@ -2294,7 +2294,7 @@ class _Authenticator(object): # so when it gets to the end of the 8-bit input # there's no partial 6-bit output. # - oup = '' + oup = b'' while inp: if len(inp) > 48: t = inp[:48] -- 2.8.3 |
|
From: Nicolas S. <nic...@la...> - 2016-06-08 15:48:20
|
tls1_1 and tls1_2 might be available with python 2, too. Remove the comment about py3 which make things confusing. Signed-off-by: Nicolas Sebrecht <nic...@la...> --- The following changes since commit b4c1c9f5fe1ebf48d0e23e3e78814ead64580875: Add "InternalDate" to __all__ (2016-06-06 12:18:35 +1000) are available in the git repository at: https://github.com/nicolas33/imaplib2.git ns/ssl-comment for you to fetch changes up to 29d0018b01ac09d5575dc78d87907d985949e454: remove wrong comment about py3 (2016-06-08 17:38:02 +0200) imaplib2.py | 2 +- imaplib2.py3 | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/imaplib2.py b/imaplib2.py index 6974639..538659b 100755 --- a/imaplib2.py +++ b/imaplib2.py @@ -485,7 +485,7 @@ class IMAP4(object): import ssl TLS_MAP = {} - if hasattr(ssl, "PROTOCOL_TLSv1_2"): # py3 + if hasattr(ssl, "PROTOCOL_TLSv1_2"): TLS_MAP[TLS_SECURE] = { "tls1_2": ssl.PROTOCOL_TLSv1_2, "tls1_1": ssl.PROTOCOL_TLSv1_1, diff --git a/imaplib2.py3 b/imaplib2.py3 index 6b49d23..8dbeb13 100755 --- a/imaplib2.py3 +++ b/imaplib2.py3 @@ -433,7 +433,7 @@ class IMAP4(object): import ssl TLS_MAP = {} - if hasattr(ssl, "PROTOCOL_TLSv1_2"): # py3 + if hasattr(ssl, "PROTOCOL_TLSv1_2"): TLS_MAP[TLS_SECURE] = { "tls1_2": ssl.PROTOCOL_TLSv1_2, "tls1_1": ssl.PROTOCOL_TLSv1_1, -- 2.7.4 |
|
From: Piers L. <pi...@ja...> - 2016-06-06 02:20:53
|
On Mon, 6 Jun 2016 02:40:45 +0200, Nicolas Sebrecht wrote: > > On Mon, Jun 06, 2016 at 10:01:12AM +1000, Piers Lauder wrote: > > > oops - sorry, didn't notice: "Mon2num", "MonthNames". > > > > Happy to add them. > > Thank you much. There is "InternalDate", too. > > -- > Nicolas Sebrecht oh, right. done. |
|
From: Nicolas S. <nic...@la...> - 2016-06-06 00:40:55
|
On Mon, Jun 06, 2016 at 10:01:12AM +1000, Piers Lauder wrote: > oops - sorry, didn't notice: "Mon2num", "MonthNames". > > Happy to add them. Thank you much. There is "InternalDate", too. -- Nicolas Sebrecht |
|
From: Piers L. <pi...@ja...> - 2016-06-06 00:01:25
|
On Mon, 6 Jun 2016 01:44:18 +0200, Nicolas Sebrecht wrote: > > On Mon, Jun 06, 2016 at 09:30:36AM +1000, Piers Lauder wrote: > > > In general, I think it a bad idea for a public module to export names > > that will trump names in the importing module. Eg in this case these > > names will overwrite the local values for __version__ etc. > > > > If you want to do this, make it explicit by having the importing > > module do "from imaplib2 import __version__..." etc. Tedious I know, > > but I don't want other unsuspecting users of "import *" to be bitten > > by it. > > Makes sense for version, release and revision. What about the other > literals I've added? > > -- > Nicolas Sebrecht oops - sorry, didn't notice: "Mon2num", "MonthNames". Happy to add them. Piers |
2 messages has been excluded from this view by a project administrator.
