Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
#!/usr/bin/env python
|
|
|
|
|
|
|
|
"""Threaded IMAP4 client.
|
|
|
|
|
2011-08-15 11:55:41 +02:00
|
|
|
Based on RFC 3501 and original imaplib module.
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
Public classes: IMAP4
|
|
|
|
IMAP4_SSL
|
|
|
|
IMAP4_stream
|
|
|
|
|
|
|
|
Public functions: Internaldate2Time
|
|
|
|
ParseFlags
|
|
|
|
Time2Internaldate
|
|
|
|
"""
|
|
|
|
|
|
|
|
|
|
|
|
__all__ = ("IMAP4", "IMAP4_SSL", "IMAP4_stream",
|
|
|
|
"Internaldate2Time", "ParseFlags", "Time2Internaldate")
|
|
|
|
|
2016-06-03 12:06:10 +02:00
|
|
|
__version__ = "2.53"
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
__release__ = "2"
|
2016-06-03 12:06:10 +02:00
|
|
|
__revision__ = "53"
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
__credits__ = """
|
|
|
|
Authentication code contributed by Donn Cave <donn@u.washington.edu> June 1998.
|
|
|
|
String method conversion by ESR, February 2001.
|
|
|
|
GET/SETACL contributed by Anthony Baxter <anthony@interlink.com.au> April 2001.
|
|
|
|
IMAP4_SSL contributed by Tino Lange <Tino.Lange@isg.de> March 2002.
|
|
|
|
GET/SETQUOTA contributed by Andreas Zeidler <az@kreativkombinat.de> June 2002.
|
|
|
|
PROXYAUTH contributed by Rick Holbert <holbert.13@osu.edu> November 2002.
|
|
|
|
IDLE via threads suggested by Philippe Normand <phil@respyre.org> January 2005.
|
|
|
|
GET/SETANNOTATION contributed by Tomas Lindroos <skitta@abo.fi> June 2005.
|
|
|
|
COMPRESS/DEFLATE contributed by Bron Gondwana <brong@brong.net> May 2009.
|
|
|
|
STARTTLS from Jython's imaplib by Alan Kennedy.
|
|
|
|
ID contributed by Dave Baggett <dave@baggett.org> November 2009.
|
|
|
|
Improved untagged responses handling suggested by Dave Baggett <dave@baggett.org> November 2009.
|
|
|
|
Improved thread naming, and 0 read detection contributed by Grant Edwards <grant.b.edwards@gmail.com> June 2010.
|
|
|
|
Improved timeout handling contributed by Ivan Vovnenko <ivovnenko@gmail.com> October 2010.
|
2011-04-11 17:24:44 +02:00
|
|
|
Timeout handling further improved by Ethan Glasser-Camp <glasse@cs.rpi.edu> December 2010.
|
2011-06-09 15:26:14 +02:00
|
|
|
Time2Internaldate() patch to match RFC2060 specification of English month names from bugs.python.org/issue11024 March 2011.
|
|
|
|
starttls() bug fixed with the help of Sebastian Spaeth <sebastian@sspaeth.de> April 2011.
|
2011-08-15 11:55:41 +02:00
|
|
|
Threads now set the "daemon" flag (suggested by offlineimap-project) April 2011.
|
2013-07-07 23:18:59 +02:00
|
|
|
Single quoting introduced with the help of Vladimir Marek <vladimir.marek@oracle.com> August 2011.
|
2013-09-02 07:08:50 +02:00
|
|
|
Support for specifying SSL version by Ryan Kavanagh <rak@debian.org> July 2013.
|
|
|
|
Fix for gmail "read 0" error provided by Jim Greenleaf <james.a.greenleaf@gmail.com> August 2013.
|
2014-10-10 14:23:07 +02:00
|
|
|
Fix for offlineimap "indexerror: string index out of range" bug provided by Eygene Ryabinkin <rea@codelabs.ru> August 2013.
|
2015-03-18 21:54:36 +01:00
|
|
|
Fix for missing idle_lock in _handler() provided by Franklin Brook <franklin@brook.se> August 2014.
|
|
|
|
Conversion to Python3 provided by F. Malina <fmalina@gmail.com> February 2015.
|
2015-03-25 13:39:13 +01:00
|
|
|
Fix for READ-ONLY error from multiple EXAMINE/SELECT calls by Pierre-Louis Bonicoli <pierre-louis.bonicoli@gmx.fr> March 2015.
|
2015-09-14 14:56:17 +02:00
|
|
|
Fix for null strings appended to untagged responses by Pierre-Louis Bonicoli <pierre-louis.bonicoli@gmx.fr> March 2015.
|
|
|
|
Fix for correct byte encoding for _CRAM_MD5_AUTH taken from python3.5 imaplib.py June 2015.
|
|
|
|
Fix for correct Python 3 exception handling by Tobias Brink <tobias.brink@gmail.com> August 2015.
|
2015-09-30 13:29:59 +02:00
|
|
|
Fix to allow interruptible IDLE command by Tim Peoples <dromedary512@users.sf.net> September 2015.
|
2015-11-05 09:07:31 +01:00
|
|
|
Add support for TLS levels by Ben Boeckel <mathstuf@gmail.com> September 2015.
|
2015-12-28 01:17:42 +01:00
|
|
|
Fix for shutown exception by Sebastien Gross <seb@chezwam.org> November 2015."""
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
__author__ = "Piers Lauder <piers@janeelix.com>"
|
2011-06-09 15:26:14 +02:00
|
|
|
__URL__ = "http://imaplib2.sourceforge.net"
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
__license__ = "Python License"
|
|
|
|
|
2015-03-18 21:54:36 +01:00
|
|
|
import binascii, errno, os, random, re, select, socket, sys, time, threading, zlib
|
|
|
|
|
2015-09-14 14:56:17 +02:00
|
|
|
if bytes != str:
|
|
|
|
# Python 3, but NB assumes strings in all I/O
|
|
|
|
# for backwards compatibility with python 2 usage.
|
|
|
|
import queue
|
2015-03-18 21:54:36 +01:00
|
|
|
string_types = str
|
2015-09-14 14:56:17 +02:00
|
|
|
else:
|
|
|
|
import Queue as queue
|
2015-03-18 21:54:36 +01:00
|
|
|
string_types = basestring
|
2015-10-15 04:15:37 +02:00
|
|
|
threading.TIMEOUT_MAX = 9223372036854.0
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
select_module = select
|
|
|
|
|
|
|
|
# Globals
|
|
|
|
|
|
|
|
CRLF = '\r\n'
|
|
|
|
Debug = None # Backward compatibility
|
|
|
|
IMAP4_PORT = 143
|
|
|
|
IMAP4_SSL_PORT = 993
|
|
|
|
|
|
|
|
IDLE_TIMEOUT_RESPONSE = '* IDLE TIMEOUT\r\n'
|
|
|
|
IDLE_TIMEOUT = 60*29 # Don't stay in IDLE state longer
|
|
|
|
READ_POLL_TIMEOUT = 30 # Without this timeout interrupted network connections can hang reader
|
2011-08-15 11:55:41 +02:00
|
|
|
READ_SIZE = 32768 # Consume all available in socket
|
2011-06-09 15:26:14 +02:00
|
|
|
|
|
|
|
DFLT_DEBUG_BUF_LVL = 3 # Level above which the logging output goes directly to stderr
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
2015-10-13 14:37:43 +02:00
|
|
|
TLS_SECURE = "tls_secure" # Recognised TLS levels
|
2015-09-30 13:29:59 +02:00
|
|
|
TLS_NO_SSL = "tls_no_ssl"
|
|
|
|
TLS_COMPAT = "tls_compat"
|
|
|
|
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
AllowedVersions = ('IMAP4REV1', 'IMAP4') # Most recent first
|
|
|
|
|
|
|
|
# Commands
|
|
|
|
|
|
|
|
CMD_VAL_STATES = 0
|
|
|
|
CMD_VAL_ASYNC = 1
|
|
|
|
NONAUTH, AUTH, SELECTED, LOGOUT = 'NONAUTH', 'AUTH', 'SELECTED', 'LOGOUT'
|
|
|
|
|
|
|
|
Commands = {
|
|
|
|
# name valid states asynchronous
|
|
|
|
'APPEND': ((AUTH, SELECTED), False),
|
|
|
|
'AUTHENTICATE': ((NONAUTH,), False),
|
|
|
|
'CAPABILITY': ((NONAUTH, AUTH, SELECTED), True),
|
|
|
|
'CHECK': ((SELECTED,), True),
|
|
|
|
'CLOSE': ((SELECTED,), False),
|
|
|
|
'COMPRESS': ((AUTH,), False),
|
|
|
|
'COPY': ((SELECTED,), True),
|
|
|
|
'CREATE': ((AUTH, SELECTED), True),
|
|
|
|
'DELETE': ((AUTH, SELECTED), True),
|
|
|
|
'DELETEACL': ((AUTH, SELECTED), True),
|
|
|
|
'EXAMINE': ((AUTH, SELECTED), False),
|
|
|
|
'EXPUNGE': ((SELECTED,), True),
|
|
|
|
'FETCH': ((SELECTED,), True),
|
|
|
|
'GETACL': ((AUTH, SELECTED), True),
|
|
|
|
'GETANNOTATION':((AUTH, SELECTED), True),
|
|
|
|
'GETQUOTA': ((AUTH, SELECTED), True),
|
|
|
|
'GETQUOTAROOT': ((AUTH, SELECTED), True),
|
2011-08-15 11:55:41 +02:00
|
|
|
'ID': ((NONAUTH, AUTH, LOGOUT, SELECTED), True),
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
'IDLE': ((SELECTED,), False),
|
|
|
|
'LIST': ((AUTH, SELECTED), True),
|
|
|
|
'LOGIN': ((NONAUTH,), False),
|
|
|
|
'LOGOUT': ((NONAUTH, AUTH, LOGOUT, SELECTED), False),
|
|
|
|
'LSUB': ((AUTH, SELECTED), True),
|
|
|
|
'MYRIGHTS': ((AUTH, SELECTED), True),
|
|
|
|
'NAMESPACE': ((AUTH, SELECTED), True),
|
|
|
|
'NOOP': ((NONAUTH, AUTH, SELECTED), True),
|
|
|
|
'PARTIAL': ((SELECTED,), True),
|
|
|
|
'PROXYAUTH': ((AUTH,), False),
|
|
|
|
'RENAME': ((AUTH, SELECTED), True),
|
|
|
|
'SEARCH': ((SELECTED,), True),
|
|
|
|
'SELECT': ((AUTH, SELECTED), False),
|
|
|
|
'SETACL': ((AUTH, SELECTED), False),
|
|
|
|
'SETANNOTATION':((AUTH, SELECTED), True),
|
|
|
|
'SETQUOTA': ((AUTH, SELECTED), False),
|
|
|
|
'SORT': ((SELECTED,), True),
|
|
|
|
'STARTTLS': ((NONAUTH,), False),
|
|
|
|
'STATUS': ((AUTH, SELECTED), True),
|
|
|
|
'STORE': ((SELECTED,), True),
|
|
|
|
'SUBSCRIBE': ((AUTH, SELECTED), False),
|
|
|
|
'THREAD': ((SELECTED,), True),
|
|
|
|
'UID': ((SELECTED,), True),
|
|
|
|
'UNSUBSCRIBE': ((AUTH, SELECTED), False),
|
|
|
|
}
|
|
|
|
|
|
|
|
UID_direct = ('SEARCH', 'SORT', 'THREAD')
|
|
|
|
|
|
|
|
|
|
|
|
def Int2AP(num):
|
|
|
|
|
|
|
|
"""string = Int2AP(num)
|
|
|
|
Return 'num' converted to a string using characters from the set 'A'..'P'
|
|
|
|
"""
|
|
|
|
|
|
|
|
val, a2p = [], 'ABCDEFGHIJKLMNOP'
|
|
|
|
num = int(abs(num))
|
|
|
|
while num:
|
|
|
|
num, mod = divmod(num, 16)
|
|
|
|
val.insert(0, a2p[mod])
|
|
|
|
return ''.join(val)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
class Request(object):
|
|
|
|
|
|
|
|
"""Private class to represent a request awaiting response."""
|
|
|
|
|
2011-08-15 11:55:41 +02:00
|
|
|
def __init__(self, parent, name=None, callback=None, cb_arg=None, cb_self=False):
|
2011-06-09 15:26:14 +02:00
|
|
|
self.parent = parent
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
self.name = name
|
2011-08-15 11:55:41 +02:00
|
|
|
self.callback = callback # Function called to process result
|
|
|
|
if not cb_self:
|
|
|
|
self.callback_arg = cb_arg # Optional arg passed to "callback"
|
|
|
|
else:
|
|
|
|
self.callback_arg = (self, cb_arg) # Self reference required in callback arg
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
self.tag = '%s%s' % (parent.tagpre, parent.tagnum)
|
|
|
|
parent.tagnum += 1
|
|
|
|
|
|
|
|
self.ready = threading.Event()
|
|
|
|
self.response = None
|
|
|
|
self.aborted = None
|
|
|
|
self.data = None
|
|
|
|
|
|
|
|
|
2015-01-18 22:13:17 +01:00
|
|
|
def abort(self, typ, val):
|
2015-03-18 21:54:36 +01:00
|
|
|
self.aborted = (typ, val)
|
|
|
|
self.deliver(None)
|
2015-01-18 22:13:17 +01:00
|
|
|
|
|
|
|
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
def get_response(self, exc_fmt=None):
|
|
|
|
self.callback = None
|
2011-06-09 15:26:14 +02:00
|
|
|
if __debug__: self.parent._log(3, '%s:%s.ready.wait' % (self.name, self.tag))
|
2015-10-15 04:15:37 +02:00
|
|
|
self.ready.wait(threading.TIMEOUT_MAX)
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
if self.aborted is not None:
|
2015-03-18 21:54:36 +01:00
|
|
|
typ, val = self.aborted
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
if exc_fmt is None:
|
|
|
|
exc_fmt = '%s - %%s' % typ
|
2015-03-18 21:54:36 +01:00
|
|
|
raise typ(exc_fmt % str(val))
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
return self.response
|
|
|
|
|
|
|
|
|
|
|
|
def deliver(self, response):
|
|
|
|
if self.callback is not None:
|
|
|
|
self.callback((response, self.callback_arg, self.aborted))
|
|
|
|
return
|
|
|
|
|
|
|
|
self.response = response
|
|
|
|
self.ready.set()
|
2011-06-09 15:26:14 +02:00
|
|
|
if __debug__: self.parent._log(3, '%s:%s.ready.set' % (self.name, self.tag))
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
class IMAP4(object):
|
|
|
|
|
|
|
|
"""Threaded IMAP4 client class.
|
|
|
|
|
|
|
|
Instantiate with:
|
2011-06-09 15:26:14 +02:00
|
|
|
IMAP4(host=None, port=None, debug=None, debug_file=None, identifier=None, timeout=None, debug_buf_lvl=None)
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
2011-06-09 15:26:14 +02:00
|
|
|
host - host's name (default: localhost);
|
|
|
|
port - port number (default: standard IMAP4 port);
|
|
|
|
debug - debug level (default: 0 - no debug);
|
|
|
|
debug_file - debug stream (default: sys.stderr);
|
|
|
|
identifier - thread identifier prefix (default: host);
|
|
|
|
timeout - timeout in seconds when expecting a command response (default: no timeout),
|
|
|
|
debug_buf_lvl - debug level at which buffering is turned off.
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
All IMAP4rev1 commands are supported by methods of the same name.
|
|
|
|
|
|
|
|
Each command returns a tuple: (type, [data, ...]) where 'type'
|
|
|
|
is usually 'OK' or 'NO', and 'data' is either the text from the
|
|
|
|
tagged response, or untagged results from command. Each 'data' is
|
|
|
|
either a string, or a tuple. If a tuple, then the first part is the
|
|
|
|
header of the response, and the second part contains the data (ie:
|
|
|
|
'literal' value).
|
|
|
|
|
|
|
|
Errors raise the exception class <instance>.error("<reason>").
|
|
|
|
IMAP4 server errors raise <instance>.abort("<reason>"), which is
|
|
|
|
a sub-class of 'error'. Mailbox status changes from READ-WRITE to
|
|
|
|
READ-ONLY raise the exception class <instance>.readonly("<reason>"),
|
|
|
|
which is a sub-class of 'abort'.
|
|
|
|
|
|
|
|
"error" exceptions imply a program error.
|
|
|
|
"abort" exceptions imply the connection should be reset, and
|
|
|
|
the command re-tried.
|
|
|
|
"readonly" exceptions imply the command should be re-tried.
|
|
|
|
|
|
|
|
All commands take two optional named arguments:
|
|
|
|
'callback' and 'cb_arg'
|
|
|
|
If 'callback' is provided then the command is asynchronous, so after
|
|
|
|
the command is queued for transmission, the call returns immediately
|
|
|
|
with the tuple (None, None).
|
|
|
|
The result will be posted by invoking "callback" with one arg, a tuple:
|
|
|
|
callback((result, cb_arg, None))
|
|
|
|
or, if there was a problem:
|
|
|
|
callback((None, cb_arg, (exception class, reason)))
|
|
|
|
|
|
|
|
Otherwise the command is synchronous (waits for result). But note
|
|
|
|
that state-changing commands will both block until previous commands
|
|
|
|
have completed, and block subsequent commands until they have finished.
|
|
|
|
|
|
|
|
All (non-callback) arguments to commands are converted to strings,
|
|
|
|
except for AUTHENTICATE, and the last argument to APPEND which is
|
|
|
|
passed as an IMAP4 literal. If necessary (the string contains any
|
2011-08-15 11:55:41 +02:00
|
|
|
non-printing characters or white-space and isn't enclosed with
|
|
|
|
either parentheses or double or single quotes) each string is
|
|
|
|
quoted. However, the 'password' argument to the LOGIN command is
|
|
|
|
always quoted. If you want to avoid having an argument string
|
|
|
|
quoted (eg: the 'flags' argument to STORE) then enclose the string
|
|
|
|
in parentheses (eg: "(\Deleted)"). If you are using "sequence sets"
|
|
|
|
containing the wildcard character '*', then enclose the argument
|
|
|
|
in single quotes: the quotes will be removed and the resulting
|
|
|
|
string passed unquoted. Note also that you can pass in an argument
|
2015-03-18 21:54:36 +01:00
|
|
|
with a type that doesn't evaluate to 'string_types' (eg: 'bytearray')
|
2011-08-15 11:55:41 +02:00
|
|
|
and it will be converted to a string without quoting.
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
There is one instance variable, 'state', that is useful for tracking
|
|
|
|
whether the client needs to login to the server. If it has the
|
|
|
|
value "AUTH" after instantiating the class, then the connection
|
|
|
|
is pre-authenticated (otherwise it will be "NONAUTH"). Selecting a
|
|
|
|
mailbox changes the state to be "SELECTED", closing a mailbox changes
|
|
|
|
back to "AUTH", and once the client has logged out, the state changes
|
|
|
|
to "LOGOUT" and no further commands may be issued.
|
|
|
|
|
|
|
|
Note: to use this module, you must read the RFCs pertaining to the
|
|
|
|
IMAP4 protocol, as the semantics of the arguments to each IMAP4
|
|
|
|
command are left to the invoker, not to mention the results. Also,
|
|
|
|
most IMAP servers implement a sub-set of the commands available here.
|
|
|
|
|
|
|
|
Note also that you must call logout() to shut down threads before
|
|
|
|
discarding an instance.
|
|
|
|
"""
|
|
|
|
|
|
|
|
class error(Exception): pass # Logical errors - debug required
|
|
|
|
class abort(error): pass # Service errors - close and retry
|
|
|
|
class readonly(abort): pass # Mailbox status changed to READ-ONLY
|
|
|
|
|
|
|
|
|
|
|
|
continuation_cre = re.compile(r'\+( (?P<data>.*))?')
|
|
|
|
literal_cre = re.compile(r'.*{(?P<size>\d+)}$')
|
|
|
|
mapCRLF_cre = re.compile(r'\r\n|\r|\n')
|
|
|
|
# Need to quote "atom-specials" :-
|
|
|
|
# "(" / ")" / "{" / SP / 0x00 - 0x1f / 0x7f / "%" / "*" / DQUOTE / "\" / "]"
|
|
|
|
# so match not the inverse set
|
|
|
|
mustquote_cre = re.compile(r"[^!#$&'+,./0-9:;<=>?@A-Z\[^_`a-z|}~-]")
|
|
|
|
response_code_cre = re.compile(r'\[(?P<type>[A-Z-]+)( (?P<data>[^\]]*))?\]')
|
2011-08-15 11:55:41 +02:00
|
|
|
# sequence_set_cre = re.compile(r"^[0-9]+(:([0-9]+|\*))?(,[0-9]+(:([0-9]+|\*))?)*$")
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
untagged_response_cre = re.compile(r'\* (?P<type>[A-Z-]+)( (?P<data>.*))?')
|
|
|
|
untagged_status_cre = re.compile(r'\* (?P<data>\d+) (?P<type>[A-Z-]+)( (?P<data2>.*))?')
|
|
|
|
|
|
|
|
|
2011-06-09 15:26:14 +02:00
|
|
|
def __init__(self, host=None, port=None, debug=None, debug_file=None, identifier=None, timeout=None, debug_buf_lvl=None):
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
self.state = NONAUTH # IMAP4 protocol state
|
|
|
|
self.literal = None # A literal argument to a command
|
|
|
|
self.tagged_commands = {} # Tagged commands awaiting response
|
|
|
|
self.untagged_responses = [] # [[typ: [data, ...]], ...]
|
|
|
|
self.mailbox = None # Current mailbox selected
|
|
|
|
self.is_readonly = False # READ-ONLY desired state
|
|
|
|
self.idle_rqb = None # Server IDLE Request - see _IdleCont
|
|
|
|
self.idle_timeout = None # Must prod server occasionally
|
|
|
|
|
2013-08-27 16:56:43 +02:00
|
|
|
self._expecting_data = False # Expecting message data
|
|
|
|
self._expecting_data_len = 0 # How many characters we expect
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
self._accumulated_data = [] # Message data accumulated so far
|
|
|
|
self._literal_expected = None # Message data descriptor
|
|
|
|
|
|
|
|
self.compressor = None # COMPRESS/DEFLATE if not None
|
|
|
|
self.decompressor = None
|
2015-10-15 04:15:37 +02:00
|
|
|
self._tls_established = False
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
# Create unique tag for this session,
|
|
|
|
# and compile tagged response matcher.
|
|
|
|
|
|
|
|
self.tagnum = 0
|
|
|
|
self.tagpre = Int2AP(random.randint(4096, 65535))
|
|
|
|
self.tagre = re.compile(r'(?P<tag>'
|
|
|
|
+ self.tagpre
|
|
|
|
+ r'\d+) (?P<type>[A-Z]+) (?P<data>.*)')
|
|
|
|
|
2011-06-09 15:26:14 +02:00
|
|
|
if __debug__: self._init_debug(debug, debug_file, debug_buf_lvl)
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
self.resp_timeout = timeout # Timeout waiting for command response
|
|
|
|
|
|
|
|
if timeout is not None and timeout < READ_POLL_TIMEOUT:
|
|
|
|
self.read_poll_timeout = timeout
|
|
|
|
else:
|
|
|
|
self.read_poll_timeout = READ_POLL_TIMEOUT
|
2011-06-09 15:26:14 +02:00
|
|
|
self.read_size = READ_SIZE
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
# Open socket to server.
|
|
|
|
|
|
|
|
self.open(host, port)
|
|
|
|
|
|
|
|
if __debug__:
|
|
|
|
if debug:
|
|
|
|
self._mesg('connected to %s on port %s' % (self.host, self.port))
|
|
|
|
|
|
|
|
# Threading
|
|
|
|
|
|
|
|
if identifier is not None:
|
|
|
|
self.identifier = identifier
|
|
|
|
else:
|
|
|
|
self.identifier = self.host
|
|
|
|
if self.identifier:
|
|
|
|
self.identifier += ' '
|
|
|
|
|
2011-06-09 15:26:14 +02:00
|
|
|
self.Terminate = self.TerminateReader = False
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
self.state_change_free = threading.Event()
|
|
|
|
self.state_change_pending = threading.Lock()
|
|
|
|
self.commands_lock = threading.Lock()
|
2011-06-09 15:26:14 +02:00
|
|
|
self.idle_lock = threading.Lock()
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
2015-03-18 21:54:36 +01:00
|
|
|
self.ouq = queue.Queue(10)
|
|
|
|
self.inq = queue.Queue()
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
self.wrth = threading.Thread(target=self._writer)
|
2011-06-09 15:26:14 +02:00
|
|
|
self.wrth.setDaemon(True)
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
self.wrth.start()
|
|
|
|
self.rdth = threading.Thread(target=self._reader)
|
2011-06-09 15:26:14 +02:00
|
|
|
self.rdth.setDaemon(True)
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
self.rdth.start()
|
|
|
|
self.inth = threading.Thread(target=self._handler)
|
2011-06-09 15:26:14 +02:00
|
|
|
self.inth.setDaemon(True)
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
self.inth.start()
|
|
|
|
|
|
|
|
# Get server welcome message,
|
|
|
|
# request and store CAPABILITY response.
|
|
|
|
|
|
|
|
try:
|
2015-10-15 04:15:37 +02:00
|
|
|
self.welcome = self._request_push(name='welcome', tag='continuation').get_response('IMAP4 protocol error: %s')[1]
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
if self._get_untagged_response('PREAUTH'):
|
|
|
|
self.state = AUTH
|
|
|
|
if __debug__: self._log(1, 'state => AUTH')
|
|
|
|
elif self._get_untagged_response('OK'):
|
|
|
|
if __debug__: self._log(1, 'state => NONAUTH')
|
|
|
|
else:
|
2014-10-10 14:13:16 +02:00
|
|
|
raise self.error('unrecognised server welcome message: %s' % repr(self.welcome))
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
typ, dat = self.capability()
|
|
|
|
if dat == [None]:
|
|
|
|
raise self.error('no CAPABILITY response from server')
|
|
|
|
self.capabilities = tuple(dat[-1].upper().split())
|
|
|
|
if __debug__: self._log(1, 'CAPABILITY: %r' % (self.capabilities,))
|
|
|
|
|
|
|
|
for version in AllowedVersions:
|
|
|
|
if not version in self.capabilities:
|
|
|
|
continue
|
|
|
|
self.PROTOCOL_VERSION = version
|
|
|
|
break
|
|
|
|
else:
|
|
|
|
raise self.error('server not IMAP4 compliant')
|
|
|
|
except:
|
|
|
|
self._close_threads()
|
|
|
|
raise
|
|
|
|
|
|
|
|
|
|
|
|
def __getattr__(self, attr):
|
|
|
|
# Allow UPPERCASE variants of IMAP4 command methods.
|
|
|
|
if attr in Commands:
|
|
|
|
return getattr(self, attr.lower())
|
|
|
|
raise AttributeError("Unknown IMAP4 command: '%s'" % attr)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# Overridable methods
|
|
|
|
|
|
|
|
|
|
|
|
def open(self, host=None, port=None):
|
|
|
|
"""open(host=None, port=None)
|
|
|
|
Setup connection to remote server on "host:port"
|
|
|
|
(default: localhost:standard IMAP4 port).
|
|
|
|
This connection will be used by the routines:
|
|
|
|
read, send, shutdown, socket."""
|
|
|
|
|
2011-06-09 15:26:14 +02:00
|
|
|
self.host = self._choose_nonull_or_dflt('', host)
|
|
|
|
self.port = self._choose_nonull_or_dflt(IMAP4_PORT, port)
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
self.sock = self.open_socket()
|
|
|
|
self.read_fd = self.sock.fileno()
|
|
|
|
|
|
|
|
|
|
|
|
def open_socket(self):
|
|
|
|
"""open_socket()
|
|
|
|
Open socket choosing first address family available."""
|
|
|
|
|
|
|
|
msg = (-1, 'could not open socket')
|
|
|
|
for res in socket.getaddrinfo(self.host, self.port, socket.AF_UNSPEC, socket.SOCK_STREAM):
|
|
|
|
af, socktype, proto, canonname, sa = res
|
|
|
|
try:
|
|
|
|
s = socket.socket(af, socktype, proto)
|
2015-09-14 14:56:17 +02:00
|
|
|
except socket.error as m:
|
|
|
|
msg = m
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
continue
|
|
|
|
try:
|
2011-04-11 17:24:44 +02:00
|
|
|
for i in (0, 1):
|
|
|
|
try:
|
|
|
|
s.connect(sa)
|
|
|
|
break
|
2015-09-14 14:56:17 +02:00
|
|
|
except socket.error as m:
|
|
|
|
msg = m
|
2011-04-11 17:24:44 +02:00
|
|
|
if len(msg.args) < 2 or msg.args[0] != errno.EINTR:
|
|
|
|
raise
|
|
|
|
else:
|
|
|
|
raise socket.error(msg)
|
2015-09-14 14:56:17 +02:00
|
|
|
except socket.error as m:
|
|
|
|
msg = m
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
s.close()
|
|
|
|
continue
|
|
|
|
break
|
|
|
|
else:
|
|
|
|
raise socket.error(msg)
|
|
|
|
|
|
|
|
return s
|
|
|
|
|
|
|
|
|
2011-08-15 11:55:41 +02:00
|
|
|
def ssl_wrap_socket(self):
|
|
|
|
|
|
|
|
try:
|
|
|
|
import ssl
|
2015-09-30 13:29:59 +02:00
|
|
|
|
|
|
|
TLS_MAP = {}
|
2015-10-13 14:37:43 +02:00
|
|
|
if hasattr(ssl, "PROTOCOL_TLSv1_2"): # py3
|
2015-09-30 13:29:59 +02:00
|
|
|
TLS_MAP[TLS_SECURE] = {
|
|
|
|
"tls1_2": ssl.PROTOCOL_TLSv1_2,
|
|
|
|
"tls1_1": ssl.PROTOCOL_TLSv1_1,
|
|
|
|
}
|
|
|
|
else:
|
|
|
|
TLS_MAP[TLS_SECURE] = {}
|
|
|
|
TLS_MAP[TLS_NO_SSL] = TLS_MAP[TLS_SECURE].copy()
|
|
|
|
TLS_MAP[TLS_NO_SSL].update({
|
|
|
|
"tls1": ssl.PROTOCOL_TLSv1,
|
|
|
|
})
|
|
|
|
TLS_MAP[TLS_COMPAT] = TLS_MAP[TLS_NO_SSL].copy()
|
|
|
|
TLS_MAP[TLS_COMPAT].update({
|
|
|
|
"ssl23": ssl.PROTOCOL_SSLv23,
|
|
|
|
None: ssl.PROTOCOL_SSLv23,
|
|
|
|
})
|
2015-10-13 14:37:43 +02:00
|
|
|
if hasattr(ssl, "PROTOCOL_SSLv3"): # Might not be available.
|
|
|
|
TLS_MAP[TLS_COMPAT].update({
|
|
|
|
"ssl3": ssl.PROTOCOL_SSLv3
|
|
|
|
})
|
2015-09-30 13:29:59 +02:00
|
|
|
|
2011-08-15 11:55:41 +02:00
|
|
|
if self.ca_certs is not None:
|
|
|
|
cert_reqs = ssl.CERT_REQUIRED
|
|
|
|
else:
|
|
|
|
cert_reqs = ssl.CERT_NONE
|
2013-07-07 23:18:59 +02:00
|
|
|
|
2015-09-30 13:29:59 +02:00
|
|
|
if self.tls_level not in TLS_MAP:
|
|
|
|
raise RuntimeError("unknown tls_level: %s" % self.tls_level)
|
|
|
|
|
|
|
|
if self.ssl_version not in TLS_MAP[self.tls_level]:
|
|
|
|
raise socket.sslerror("Invalid SSL version '%s' requested for tls_version '%s'" % (self.ssl_version, self.tls_level))
|
|
|
|
|
|
|
|
ssl_version = TLS_MAP[self.tls_level][self.ssl_version]
|
2013-07-07 23:18:59 +02:00
|
|
|
|
|
|
|
self.sock = ssl.wrap_socket(self.sock, self.keyfile, self.certfile, ca_certs=self.ca_certs, cert_reqs=cert_reqs, ssl_version=ssl_version)
|
2011-08-15 11:55:41 +02:00
|
|
|
ssl_exc = ssl.SSLError
|
2012-04-19 13:18:44 +02:00
|
|
|
self.read_fd = self.sock.fileno()
|
2011-08-15 11:55:41 +02:00
|
|
|
except ImportError:
|
2012-04-19 13:18:44 +02:00
|
|
|
# No ssl module, and socket.ssl has no fileno(), and does not allow certificate verification
|
2015-10-15 04:15:37 +02:00
|
|
|
raise socket.sslerror("imaplib SSL mode does not work without ssl module")
|
2011-08-15 11:55:41 +02:00
|
|
|
|
|
|
|
if self.cert_verify_cb is not None:
|
|
|
|
cert_err = self.cert_verify_cb(self.sock.getpeercert(), self.host)
|
|
|
|
if cert_err:
|
|
|
|
raise ssl_exc(cert_err)
|
|
|
|
|
2015-10-15 04:15:37 +02:00
|
|
|
# Allow sending of keep-alive messages - seems to prevent some servers
|
|
|
|
# from closing SSL, leading to deadlocks.
|
|
|
|
self.sock.setsockopt(socket.SOL_SOCKET, socket.SO_KEEPALIVE, 1)
|
|
|
|
|
2011-08-15 11:55:41 +02:00
|
|
|
|
|
|
|
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
def start_compressing(self):
|
|
|
|
"""start_compressing()
|
|
|
|
Enable deflate compression on the socket (RFC 4978)."""
|
|
|
|
|
|
|
|
# rfc 1951 - pure DEFLATE, so use -15 for both windows
|
|
|
|
self.decompressor = zlib.decompressobj(-15)
|
|
|
|
self.compressor = zlib.compressobj(zlib.Z_DEFAULT_COMPRESSION, zlib.DEFLATED, -15)
|
|
|
|
|
|
|
|
|
|
|
|
def read(self, size):
|
|
|
|
"""data = read(size)
|
|
|
|
Read at most 'size' bytes from remote."""
|
|
|
|
|
|
|
|
if self.decompressor is None:
|
|
|
|
return self.sock.recv(size)
|
|
|
|
|
|
|
|
if self.decompressor.unconsumed_tail:
|
|
|
|
data = self.decompressor.unconsumed_tail
|
|
|
|
else:
|
2012-04-19 13:18:44 +02:00
|
|
|
data = self.sock.recv(READ_SIZE)
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
return self.decompressor.decompress(data, size)
|
|
|
|
|
|
|
|
|
|
|
|
def send(self, data):
|
|
|
|
"""send(data)
|
|
|
|
Send 'data' to remote."""
|
|
|
|
|
|
|
|
if self.compressor is not None:
|
|
|
|
data = self.compressor.compress(data)
|
|
|
|
data += self.compressor.flush(zlib.Z_SYNC_FLUSH)
|
|
|
|
|
2015-03-18 21:54:36 +01:00
|
|
|
if bytes != str:
|
2015-10-15 04:15:37 +02:00
|
|
|
data = bytes(data, 'ASCII')
|
2015-09-14 14:56:17 +02:00
|
|
|
|
|
|
|
self.sock.sendall(data)
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
def shutdown(self):
|
|
|
|
"""shutdown()
|
|
|
|
Close I/O established in "open"."""
|
|
|
|
|
2015-10-15 04:15:37 +02:00
|
|
|
try:
|
|
|
|
self.sock.shutdown(socket.SHUT_RDWR)
|
2015-11-05 09:07:31 +01:00
|
|
|
except Exception as e:
|
2015-10-15 04:15:37 +02:00
|
|
|
# The server might already have closed the connection
|
|
|
|
if e.errno != errno.ENOTCONN:
|
|
|
|
raise
|
|
|
|
finally:
|
|
|
|
self.sock.close()
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
def socket(self):
|
|
|
|
"""socket = socket()
|
|
|
|
Return socket instance used to connect to IMAP4 server."""
|
|
|
|
|
|
|
|
return self.sock
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# Utility methods
|
|
|
|
|
|
|
|
|
|
|
|
def enable_compression(self):
|
|
|
|
"""enable_compression()
|
|
|
|
Ask the server to start compressing the connection.
|
|
|
|
Should be called from user of this class after instantiation, as in:
|
|
|
|
if 'COMPRESS=DEFLATE' in imapobj.capabilities:
|
|
|
|
imapobj.enable_compression()"""
|
|
|
|
|
|
|
|
try:
|
|
|
|
typ, dat = self._simple_command('COMPRESS', 'DEFLATE')
|
|
|
|
if typ == 'OK':
|
|
|
|
self.start_compressing()
|
|
|
|
if __debug__: self._log(1, 'Enabled COMPRESS=DEFLATE')
|
|
|
|
finally:
|
2011-06-09 15:26:14 +02:00
|
|
|
self._release_state_change()
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
def pop_untagged_responses(self):
|
|
|
|
""" for typ,data in pop_untagged_responses(): pass
|
|
|
|
Generator for any remaining untagged responses.
|
|
|
|
Returns and removes untagged responses in order of reception.
|
|
|
|
Use at your own risk!"""
|
|
|
|
|
|
|
|
while self.untagged_responses:
|
|
|
|
self.commands_lock.acquire()
|
|
|
|
try:
|
|
|
|
yield self.untagged_responses.pop(0)
|
|
|
|
finally:
|
|
|
|
self.commands_lock.release()
|
|
|
|
|
|
|
|
|
|
|
|
def recent(self, **kw):
|
|
|
|
"""(typ, [data]) = recent()
|
|
|
|
Return 'RECENT' responses if any exist,
|
|
|
|
else prompt server for an update using the 'NOOP' command.
|
|
|
|
'data' is None if no new messages,
|
|
|
|
else list of RECENT responses, most recent last."""
|
|
|
|
|
|
|
|
name = 'RECENT'
|
2011-06-09 15:26:14 +02:00
|
|
|
typ, dat = self._untagged_response(None, [None], name)
|
|
|
|
if dat != [None]:
|
|
|
|
return self._deliver_dat(typ, dat, kw)
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
kw['untagged_response'] = name
|
|
|
|
return self.noop(**kw) # Prod server for response
|
|
|
|
|
|
|
|
|
|
|
|
def response(self, code, **kw):
|
|
|
|
"""(code, [data]) = response(code)
|
|
|
|
Return data for response 'code' if received, or None.
|
|
|
|
Old value for response 'code' is cleared."""
|
|
|
|
|
|
|
|
typ, dat = self._untagged_response(code, [None], code.upper())
|
|
|
|
return self._deliver_dat(typ, dat, kw)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# IMAP4 commands
|
|
|
|
|
|
|
|
|
|
|
|
def append(self, mailbox, flags, date_time, message, **kw):
|
|
|
|
"""(typ, [data]) = append(mailbox, flags, date_time, message)
|
|
|
|
Append message to named mailbox.
|
|
|
|
All args except `message' can be None."""
|
|
|
|
|
|
|
|
name = 'APPEND'
|
|
|
|
if not mailbox:
|
|
|
|
mailbox = 'INBOX'
|
|
|
|
if flags:
|
|
|
|
if (flags[0],flags[-1]) != ('(',')'):
|
|
|
|
flags = '(%s)' % flags
|
|
|
|
else:
|
|
|
|
flags = None
|
|
|
|
if date_time:
|
|
|
|
date_time = Time2Internaldate(date_time)
|
|
|
|
else:
|
|
|
|
date_time = None
|
|
|
|
self.literal = self.mapCRLF_cre.sub(CRLF, message)
|
|
|
|
try:
|
|
|
|
return self._simple_command(name, mailbox, flags, date_time, **kw)
|
|
|
|
finally:
|
2011-06-09 15:26:14 +02:00
|
|
|
self._release_state_change()
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
def authenticate(self, mechanism, authobject, **kw):
|
|
|
|
"""(typ, [data]) = authenticate(mechanism, authobject)
|
|
|
|
Authenticate command - requires response processing.
|
|
|
|
|
|
|
|
'mechanism' specifies which authentication mechanism is to
|
|
|
|
be used - it must appear in <instance>.capabilities in the
|
|
|
|
form AUTH=<mechanism>.
|
|
|
|
|
|
|
|
'authobject' must be a callable object:
|
|
|
|
|
|
|
|
data = authobject(response)
|
|
|
|
|
|
|
|
It will be called to process server continuation responses.
|
|
|
|
It should return data that will be encoded and sent to server.
|
|
|
|
It should return None if the client abort response '*' should
|
|
|
|
be sent instead."""
|
|
|
|
|
|
|
|
self.literal = _Authenticator(authobject).process
|
|
|
|
try:
|
|
|
|
typ, dat = self._simple_command('AUTHENTICATE', mechanism.upper())
|
|
|
|
if typ != 'OK':
|
|
|
|
self._deliver_exc(self.error, dat[-1], kw)
|
|
|
|
self.state = AUTH
|
|
|
|
if __debug__: self._log(1, 'state => AUTH')
|
|
|
|
finally:
|
2011-06-09 15:26:14 +02:00
|
|
|
self._release_state_change()
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
return self._deliver_dat(typ, dat, kw)
|
|
|
|
|
|
|
|
|
|
|
|
def capability(self, **kw):
|
|
|
|
"""(typ, [data]) = capability()
|
|
|
|
Fetch capabilities list from server."""
|
|
|
|
|
|
|
|
name = 'CAPABILITY'
|
|
|
|
kw['untagged_response'] = name
|
|
|
|
return self._simple_command(name, **kw)
|
|
|
|
|
|
|
|
|
|
|
|
def check(self, **kw):
|
|
|
|
"""(typ, [data]) = check()
|
|
|
|
Checkpoint mailbox on server."""
|
|
|
|
|
|
|
|
return self._simple_command('CHECK', **kw)
|
|
|
|
|
|
|
|
|
|
|
|
def close(self, **kw):
|
|
|
|
"""(typ, [data]) = close()
|
|
|
|
Close currently selected mailbox.
|
|
|
|
|
|
|
|
Deleted messages are removed from writable mailbox.
|
|
|
|
This is the recommended command before 'LOGOUT'."""
|
|
|
|
|
|
|
|
if self.state != 'SELECTED':
|
|
|
|
raise self.error('No mailbox selected.')
|
|
|
|
try:
|
|
|
|
typ, dat = self._simple_command('CLOSE')
|
|
|
|
finally:
|
|
|
|
self.state = AUTH
|
|
|
|
if __debug__: self._log(1, 'state => AUTH')
|
2011-06-09 15:26:14 +02:00
|
|
|
self._release_state_change()
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
return self._deliver_dat(typ, dat, kw)
|
|
|
|
|
|
|
|
|
|
|
|
def copy(self, message_set, new_mailbox, **kw):
|
|
|
|
"""(typ, [data]) = copy(message_set, new_mailbox)
|
|
|
|
Copy 'message_set' messages onto end of 'new_mailbox'."""
|
|
|
|
|
|
|
|
return self._simple_command('COPY', message_set, new_mailbox, **kw)
|
|
|
|
|
|
|
|
|
|
|
|
def create(self, mailbox, **kw):
|
|
|
|
"""(typ, [data]) = create(mailbox)
|
|
|
|
Create new mailbox."""
|
|
|
|
|
|
|
|
return self._simple_command('CREATE', mailbox, **kw)
|
|
|
|
|
|
|
|
|
|
|
|
def delete(self, mailbox, **kw):
|
|
|
|
"""(typ, [data]) = delete(mailbox)
|
|
|
|
Delete old mailbox."""
|
|
|
|
|
|
|
|
return self._simple_command('DELETE', mailbox, **kw)
|
|
|
|
|
|
|
|
|
|
|
|
def deleteacl(self, mailbox, who, **kw):
|
|
|
|
"""(typ, [data]) = deleteacl(mailbox, who)
|
|
|
|
Delete the ACLs (remove any rights) set for who on mailbox."""
|
|
|
|
|
|
|
|
return self._simple_command('DELETEACL', mailbox, who, **kw)
|
|
|
|
|
|
|
|
|
|
|
|
def examine(self, mailbox='INBOX', **kw):
|
2011-08-15 11:55:41 +02:00
|
|
|
"""(typ, [data]) = examine(mailbox='INBOX')
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
Select a mailbox for READ-ONLY access. (Flushes all untagged responses.)
|
|
|
|
'data' is count of messages in mailbox ('EXISTS' response).
|
|
|
|
Mandated responses are ('FLAGS', 'EXISTS', 'RECENT', 'UIDVALIDITY'), so
|
|
|
|
other responses should be obtained via "response('FLAGS')" etc."""
|
|
|
|
|
|
|
|
return self.select(mailbox=mailbox, readonly=True, **kw)
|
|
|
|
|
|
|
|
|
|
|
|
def expunge(self, **kw):
|
|
|
|
"""(typ, [data]) = expunge()
|
|
|
|
Permanently remove deleted items from selected mailbox.
|
|
|
|
Generates 'EXPUNGE' response for each deleted message.
|
|
|
|
'data' is list of 'EXPUNGE'd message numbers in order received."""
|
|
|
|
|
|
|
|
name = 'EXPUNGE'
|
|
|
|
kw['untagged_response'] = name
|
|
|
|
return self._simple_command(name, **kw)
|
|
|
|
|
|
|
|
|
|
|
|
def fetch(self, message_set, message_parts, **kw):
|
|
|
|
"""(typ, [data, ...]) = fetch(message_set, message_parts)
|
|
|
|
Fetch (parts of) messages.
|
|
|
|
'message_parts' should be a string of selected parts
|
|
|
|
enclosed in parentheses, eg: "(UID BODY[TEXT])".
|
|
|
|
'data' are tuples of message part envelope and data,
|
|
|
|
followed by a string containing the trailer."""
|
|
|
|
|
|
|
|
name = 'FETCH'
|
|
|
|
kw['untagged_response'] = name
|
|
|
|
return self._simple_command(name, message_set, message_parts, **kw)
|
|
|
|
|
|
|
|
|
|
|
|
def getacl(self, mailbox, **kw):
|
|
|
|
"""(typ, [data]) = getacl(mailbox)
|
|
|
|
Get the ACLs for a mailbox."""
|
|
|
|
|
|
|
|
kw['untagged_response'] = 'ACL'
|
|
|
|
return self._simple_command('GETACL', mailbox, **kw)
|
|
|
|
|
|
|
|
|
|
|
|
def getannotation(self, mailbox, entry, attribute, **kw):
|
|
|
|
"""(typ, [data]) = getannotation(mailbox, entry, attribute)
|
|
|
|
Retrieve ANNOTATIONs."""
|
|
|
|
|
|
|
|
kw['untagged_response'] = 'ANNOTATION'
|
|
|
|
return self._simple_command('GETANNOTATION', mailbox, entry, attribute, **kw)
|
|
|
|
|
|
|
|
|
|
|
|
def getquota(self, root, **kw):
|
|
|
|
"""(typ, [data]) = getquota(root)
|
|
|
|
Get the quota root's resource usage and limits.
|
|
|
|
(Part of the IMAP4 QUOTA extension defined in rfc2087.)"""
|
|
|
|
|
|
|
|
kw['untagged_response'] = 'QUOTA'
|
|
|
|
return self._simple_command('GETQUOTA', root, **kw)
|
|
|
|
|
|
|
|
|
|
|
|
def getquotaroot(self, mailbox, **kw):
|
|
|
|
# Hmmm, this is non-std! Left for backwards-compatibility, sigh.
|
|
|
|
# NB: usage should have been defined as:
|
|
|
|
# (typ, [QUOTAROOT responses...]) = getquotaroot(mailbox)
|
|
|
|
# (typ, [QUOTA responses...]) = response('QUOTA')
|
|
|
|
"""(typ, [[QUOTAROOT responses...], [QUOTA responses...]]) = getquotaroot(mailbox)
|
|
|
|
Get the list of quota roots for the named mailbox."""
|
|
|
|
|
|
|
|
typ, dat = self._simple_command('GETQUOTAROOT', mailbox)
|
|
|
|
typ, quota = self._untagged_response(typ, dat, 'QUOTA')
|
|
|
|
typ, quotaroot = self._untagged_response(typ, dat, 'QUOTAROOT')
|
|
|
|
return self._deliver_dat(typ, [quotaroot, quota], kw)
|
|
|
|
|
|
|
|
|
|
|
|
def id(self, *kv_pairs, **kw):
|
|
|
|
"""(typ, [data]) = <instance>.id(kv_pairs)
|
2011-08-15 11:55:41 +02:00
|
|
|
'kv_pairs' is a possibly empty list of keys and values.
|
|
|
|
'data' is a list of ID key value pairs or NIL.
|
|
|
|
NB: a single argument is assumed to be correctly formatted and is passed through unchanged
|
|
|
|
(for backward compatibility with earlier version).
|
|
|
|
Exchange information for problem analysis and determination.
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
The ID extension is defined in RFC 2971. """
|
|
|
|
|
|
|
|
name = 'ID'
|
|
|
|
kw['untagged_response'] = name
|
2011-08-15 11:55:41 +02:00
|
|
|
|
|
|
|
if not kv_pairs:
|
|
|
|
data = 'NIL'
|
|
|
|
elif len(kv_pairs) == 1:
|
|
|
|
data = kv_pairs[0] # Assume invoker passing correctly formatted string (back-compat)
|
|
|
|
else:
|
|
|
|
data = '(%s)' % ' '.join([(arg and self._quote(arg) or 'NIL') for arg in kv_pairs])
|
2015-03-18 21:54:36 +01:00
|
|
|
|
|
|
|
return self._simple_command(name, data, **kw)
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
def idle(self, timeout=None, **kw):
|
|
|
|
""""(typ, [data]) = idle(timeout=None)
|
|
|
|
Put server into IDLE mode until server notifies some change,
|
|
|
|
or 'timeout' (secs) occurs (default: 29 minutes),
|
|
|
|
or another IMAP4 command is scheduled."""
|
|
|
|
|
|
|
|
name = 'IDLE'
|
|
|
|
self.literal = _IdleCont(self, timeout).process
|
|
|
|
try:
|
|
|
|
return self._simple_command(name, **kw)
|
|
|
|
finally:
|
2011-06-09 15:26:14 +02:00
|
|
|
self._release_state_change()
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
def list(self, directory='""', pattern='*', **kw):
|
|
|
|
"""(typ, [data]) = list(directory='""', pattern='*')
|
|
|
|
List mailbox names in directory matching pattern.
|
|
|
|
'data' is list of LIST responses.
|
|
|
|
|
|
|
|
NB: for 'pattern':
|
|
|
|
% matches all except separator ( so LIST "" "%" returns names at root)
|
|
|
|
* matches all (so LIST "" "*" returns whole directory tree from root)"""
|
|
|
|
|
|
|
|
name = 'LIST'
|
|
|
|
kw['untagged_response'] = name
|
|
|
|
return self._simple_command(name, directory, pattern, **kw)
|
|
|
|
|
|
|
|
|
|
|
|
def login(self, user, password, **kw):
|
|
|
|
"""(typ, [data]) = login(user, password)
|
|
|
|
Identify client using plaintext password.
|
|
|
|
NB: 'password' will be quoted."""
|
|
|
|
|
|
|
|
try:
|
|
|
|
typ, dat = self._simple_command('LOGIN', user, self._quote(password))
|
|
|
|
if typ != 'OK':
|
|
|
|
self._deliver_exc(self.error, dat[-1], kw)
|
|
|
|
self.state = AUTH
|
|
|
|
if __debug__: self._log(1, 'state => AUTH')
|
|
|
|
finally:
|
2011-06-09 15:26:14 +02:00
|
|
|
self._release_state_change()
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
return self._deliver_dat(typ, dat, kw)
|
|
|
|
|
|
|
|
|
|
|
|
def login_cram_md5(self, user, password, **kw):
|
|
|
|
"""(typ, [data]) = login_cram_md5(user, password)
|
|
|
|
Force use of CRAM-MD5 authentication."""
|
|
|
|
|
|
|
|
self.user, self.password = user, password
|
|
|
|
return self.authenticate('CRAM-MD5', self._CRAM_MD5_AUTH, **kw)
|
|
|
|
|
|
|
|
|
|
|
|
def _CRAM_MD5_AUTH(self, challenge):
|
|
|
|
"""Authobject to use with CRAM-MD5 authentication."""
|
|
|
|
import hmac
|
2015-10-15 04:15:37 +02:00
|
|
|
pwd = (self.password.encode('ASCII') if isinstance(self.password, str)
|
2015-09-14 14:56:17 +02:00
|
|
|
else self.password)
|
|
|
|
return self.user + " " + hmac.HMAC(pwd, challenge, 'md5').hexdigest()
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
def logout(self, **kw):
|
|
|
|
"""(typ, [data]) = logout()
|
|
|
|
Shutdown connection to server.
|
|
|
|
Returns server 'BYE' response.
|
|
|
|
NB: You must call this to shut down threads before discarding an instance."""
|
|
|
|
|
|
|
|
self.state = LOGOUT
|
|
|
|
if __debug__: self._log(1, 'state => LOGOUT')
|
|
|
|
|
|
|
|
try:
|
2011-06-09 15:26:14 +02:00
|
|
|
try:
|
|
|
|
typ, dat = self._simple_command('LOGOUT')
|
|
|
|
except:
|
|
|
|
typ, dat = 'NO', ['%s: %s' % sys.exc_info()[:2]]
|
|
|
|
if __debug__: self._log(1, dat)
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
2011-06-09 15:26:14 +02:00
|
|
|
self._close_threads()
|
|
|
|
finally:
|
|
|
|
self._release_state_change()
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
if __debug__: self._log(1, 'connection closed')
|
|
|
|
|
|
|
|
bye = self._get_untagged_response('BYE', leave=True)
|
|
|
|
if bye:
|
|
|
|
typ, dat = 'BYE', bye
|
|
|
|
return self._deliver_dat(typ, dat, kw)
|
|
|
|
|
|
|
|
|
|
|
|
def lsub(self, directory='""', pattern='*', **kw):
|
|
|
|
"""(typ, [data, ...]) = lsub(directory='""', pattern='*')
|
|
|
|
List 'subscribed' mailbox names in directory matching pattern.
|
|
|
|
'data' are tuples of message part envelope and data."""
|
|
|
|
|
|
|
|
name = 'LSUB'
|
|
|
|
kw['untagged_response'] = name
|
|
|
|
return self._simple_command(name, directory, pattern, **kw)
|
|
|
|
|
|
|
|
|
|
|
|
def myrights(self, mailbox, **kw):
|
|
|
|
"""(typ, [data]) = myrights(mailbox)
|
|
|
|
Show my ACLs for a mailbox (i.e. the rights that I have on mailbox)."""
|
|
|
|
|
|
|
|
name = 'MYRIGHTS'
|
|
|
|
kw['untagged_response'] = name
|
|
|
|
return self._simple_command(name, mailbox, **kw)
|
|
|
|
|
|
|
|
|
|
|
|
def namespace(self, **kw):
|
|
|
|
"""(typ, [data, ...]) = namespace()
|
|
|
|
Returns IMAP namespaces ala rfc2342."""
|
|
|
|
|
|
|
|
name = 'NAMESPACE'
|
|
|
|
kw['untagged_response'] = name
|
|
|
|
return self._simple_command(name, **kw)
|
|
|
|
|
|
|
|
|
|
|
|
def noop(self, **kw):
|
|
|
|
"""(typ, [data]) = noop()
|
|
|
|
Send NOOP command."""
|
|
|
|
|
|
|
|
if __debug__: self._dump_ur(3)
|
|
|
|
return self._simple_command('NOOP', **kw)
|
|
|
|
|
|
|
|
|
|
|
|
def partial(self, message_num, message_part, start, length, **kw):
|
|
|
|
"""(typ, [data, ...]) = partial(message_num, message_part, start, length)
|
|
|
|
Fetch truncated part of a message.
|
|
|
|
'data' is tuple of message part envelope and data.
|
|
|
|
NB: obsolete."""
|
|
|
|
|
|
|
|
name = 'PARTIAL'
|
|
|
|
kw['untagged_response'] = 'FETCH'
|
|
|
|
return self._simple_command(name, message_num, message_part, start, length, **kw)
|
|
|
|
|
|
|
|
|
|
|
|
def proxyauth(self, user, **kw):
|
|
|
|
"""(typ, [data]) = proxyauth(user)
|
|
|
|
Assume authentication as 'user'.
|
|
|
|
(Allows an authorised administrator to proxy into any user's mailbox.)"""
|
|
|
|
|
|
|
|
try:
|
|
|
|
return self._simple_command('PROXYAUTH', user, **kw)
|
|
|
|
finally:
|
2011-06-09 15:26:14 +02:00
|
|
|
self._release_state_change()
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
def rename(self, oldmailbox, newmailbox, **kw):
|
|
|
|
"""(typ, [data]) = rename(oldmailbox, newmailbox)
|
|
|
|
Rename old mailbox name to new."""
|
|
|
|
|
|
|
|
return self._simple_command('RENAME', oldmailbox, newmailbox, **kw)
|
|
|
|
|
|
|
|
|
|
|
|
def search(self, charset, *criteria, **kw):
|
|
|
|
"""(typ, [data]) = search(charset, criterion, ...)
|
|
|
|
Search mailbox for matching messages.
|
|
|
|
'data' is space separated list of matching message numbers."""
|
|
|
|
|
|
|
|
name = 'SEARCH'
|
|
|
|
kw['untagged_response'] = name
|
|
|
|
if charset:
|
|
|
|
return self._simple_command(name, 'CHARSET', charset, *criteria, **kw)
|
|
|
|
return self._simple_command(name, *criteria, **kw)
|
|
|
|
|
|
|
|
|
|
|
|
def select(self, mailbox='INBOX', readonly=False, **kw):
|
|
|
|
"""(typ, [data]) = select(mailbox='INBOX', readonly=False)
|
2015-03-18 21:54:36 +01:00
|
|
|
Select a mailbox. (Flushes all untagged responses.)
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
'data' is count of messages in mailbox ('EXISTS' response).
|
|
|
|
Mandated responses are ('FLAGS', 'EXISTS', 'RECENT', 'UIDVALIDITY'), so
|
|
|
|
other responses should be obtained via "response('FLAGS')" etc."""
|
|
|
|
|
|
|
|
self.mailbox = mailbox
|
|
|
|
|
2015-03-18 21:54:36 +01:00
|
|
|
self.is_readonly = bool(readonly)
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
if readonly:
|
|
|
|
name = 'EXAMINE'
|
|
|
|
else:
|
|
|
|
name = 'SELECT'
|
|
|
|
try:
|
|
|
|
rqb = self._command(name, mailbox)
|
|
|
|
typ, dat = rqb.get_response('command: %s => %%s' % rqb.name)
|
|
|
|
if typ != 'OK':
|
|
|
|
if self.state == SELECTED:
|
|
|
|
self.state = AUTH
|
|
|
|
if __debug__: self._log(1, 'state => AUTH')
|
|
|
|
if typ == 'BAD':
|
|
|
|
self._deliver_exc(self.error, '%s command error: %s %s. Data: %.100s' % (name, typ, dat, mailbox), kw)
|
|
|
|
return self._deliver_dat(typ, dat, kw)
|
|
|
|
self.state = SELECTED
|
|
|
|
if __debug__: self._log(1, 'state => SELECTED')
|
|
|
|
finally:
|
2011-06-09 15:26:14 +02:00
|
|
|
self._release_state_change()
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
if self._get_untagged_response('READ-ONLY', leave=True) and not readonly:
|
|
|
|
if __debug__: self._dump_ur(1)
|
|
|
|
self._deliver_exc(self.readonly, '%s is not writable' % mailbox, kw)
|
|
|
|
typ, dat = self._untagged_response(typ, [None], 'EXISTS')
|
|
|
|
return self._deliver_dat(typ, dat, kw)
|
|
|
|
|
|
|
|
|
|
|
|
def setacl(self, mailbox, who, what, **kw):
|
|
|
|
"""(typ, [data]) = setacl(mailbox, who, what)
|
|
|
|
Set a mailbox acl."""
|
|
|
|
|
|
|
|
try:
|
|
|
|
return self._simple_command('SETACL', mailbox, who, what, **kw)
|
|
|
|
finally:
|
2011-06-09 15:26:14 +02:00
|
|
|
self._release_state_change()
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
def setannotation(self, *args, **kw):
|
|
|
|
"""(typ, [data]) = setannotation(mailbox[, entry, attribute]+)
|
|
|
|
Set ANNOTATIONs."""
|
|
|
|
|
|
|
|
kw['untagged_response'] = 'ANNOTATION'
|
|
|
|
return self._simple_command('SETANNOTATION', *args, **kw)
|
|
|
|
|
|
|
|
|
|
|
|
def setquota(self, root, limits, **kw):
|
|
|
|
"""(typ, [data]) = setquota(root, limits)
|
|
|
|
Set the quota root's resource limits."""
|
|
|
|
|
|
|
|
kw['untagged_response'] = 'QUOTA'
|
|
|
|
try:
|
|
|
|
return self._simple_command('SETQUOTA', root, limits, **kw)
|
|
|
|
finally:
|
2011-06-09 15:26:14 +02:00
|
|
|
self._release_state_change()
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
def sort(self, sort_criteria, charset, *search_criteria, **kw):
|
|
|
|
"""(typ, [data]) = sort(sort_criteria, charset, search_criteria, ...)
|
|
|
|
IMAP4rev1 extension SORT command."""
|
|
|
|
|
|
|
|
name = 'SORT'
|
|
|
|
if (sort_criteria[0],sort_criteria[-1]) != ('(',')'):
|
|
|
|
sort_criteria = '(%s)' % sort_criteria
|
|
|
|
kw['untagged_response'] = name
|
|
|
|
return self._simple_command(name, sort_criteria, charset, *search_criteria, **kw)
|
|
|
|
|
|
|
|
|
2015-09-30 13:29:59 +02:00
|
|
|
def starttls(self, keyfile=None, certfile=None, ca_certs=None, cert_verify_cb=None, ssl_version="ssl23", tls_level=TLS_COMPAT, **kw):
|
|
|
|
"""(typ, [data]) = starttls(keyfile=None, certfile=None, ca_certs=None, cert_verify_cb=None, ssl_version="ssl23", tls_level="tls_compat")
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
Start TLS negotiation as per RFC 2595."""
|
|
|
|
|
|
|
|
name = 'STARTTLS'
|
|
|
|
|
|
|
|
if name not in self.capabilities:
|
|
|
|
raise self.abort('TLS not supported by server')
|
|
|
|
|
2015-10-15 04:15:37 +02:00
|
|
|
if self._tls_established:
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
raise self.abort('TLS session already established')
|
|
|
|
|
2011-06-09 15:26:14 +02:00
|
|
|
# Must now shutdown reader thread after next response, and restart after changing read_fd
|
|
|
|
|
2011-08-15 11:55:41 +02:00
|
|
|
self.read_size = 1 # Don't consume TLS handshake
|
2011-06-09 15:26:14 +02:00
|
|
|
self.TerminateReader = True
|
|
|
|
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
try:
|
|
|
|
typ, dat = self._simple_command(name)
|
|
|
|
finally:
|
2011-06-09 15:26:14 +02:00
|
|
|
self._release_state_change()
|
|
|
|
self.rdth.join()
|
|
|
|
self.TerminateReader = False
|
|
|
|
self.read_size = READ_SIZE
|
|
|
|
|
|
|
|
if typ != 'OK':
|
|
|
|
# Restart reader thread and error
|
|
|
|
self.rdth = threading.Thread(target=self._reader)
|
|
|
|
self.rdth.setDaemon(True)
|
|
|
|
self.rdth.start()
|
|
|
|
raise self.error("Couldn't establish TLS session: %s" % dat)
|
|
|
|
|
2011-08-15 11:55:41 +02:00
|
|
|
self.keyfile = keyfile
|
|
|
|
self.certfile = certfile
|
|
|
|
self.ca_certs = ca_certs
|
|
|
|
self.cert_verify_cb = cert_verify_cb
|
2013-07-07 23:18:59 +02:00
|
|
|
self.ssl_version = ssl_version
|
2015-09-30 13:29:59 +02:00
|
|
|
self.tls_level = tls_level
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
2011-08-15 11:55:41 +02:00
|
|
|
try:
|
|
|
|
self.ssl_wrap_socket()
|
2011-06-09 15:26:14 +02:00
|
|
|
finally:
|
|
|
|
# Restart reader thread
|
|
|
|
self.rdth = threading.Thread(target=self._reader)
|
|
|
|
self.rdth.setDaemon(True)
|
|
|
|
self.rdth.start()
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
2011-06-09 15:26:14 +02:00
|
|
|
typ, dat = self.capability()
|
|
|
|
if dat == [None]:
|
|
|
|
raise self.error('no CAPABILITY response from server')
|
|
|
|
self.capabilities = tuple(dat[-1].upper().split())
|
|
|
|
|
|
|
|
self._tls_established = True
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
typ, dat = self._untagged_response(typ, dat, name)
|
|
|
|
return self._deliver_dat(typ, dat, kw)
|
|
|
|
|
|
|
|
|
|
|
|
def status(self, mailbox, names, **kw):
|
|
|
|
"""(typ, [data]) = status(mailbox, names)
|
|
|
|
Request named status conditions for mailbox."""
|
|
|
|
|
|
|
|
name = 'STATUS'
|
|
|
|
kw['untagged_response'] = name
|
|
|
|
return self._simple_command(name, mailbox, names, **kw)
|
|
|
|
|
|
|
|
|
|
|
|
def store(self, message_set, command, flags, **kw):
|
|
|
|
"""(typ, [data]) = store(message_set, command, flags)
|
|
|
|
Alters flag dispositions for messages in mailbox."""
|
|
|
|
|
|
|
|
if (flags[0],flags[-1]) != ('(',')'):
|
|
|
|
flags = '(%s)' % flags # Avoid quoting the flags
|
|
|
|
kw['untagged_response'] = 'FETCH'
|
|
|
|
return self._simple_command('STORE', message_set, command, flags, **kw)
|
|
|
|
|
|
|
|
|
|
|
|
def subscribe(self, mailbox, **kw):
|
|
|
|
"""(typ, [data]) = subscribe(mailbox)
|
|
|
|
Subscribe to new mailbox."""
|
|
|
|
|
|
|
|
try:
|
|
|
|
return self._simple_command('SUBSCRIBE', mailbox, **kw)
|
|
|
|
finally:
|
2011-06-09 15:26:14 +02:00
|
|
|
self._release_state_change()
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
def thread(self, threading_algorithm, charset, *search_criteria, **kw):
|
|
|
|
"""(type, [data]) = thread(threading_alogrithm, charset, search_criteria, ...)
|
|
|
|
IMAPrev1 extension THREAD command."""
|
|
|
|
|
|
|
|
name = 'THREAD'
|
|
|
|
kw['untagged_response'] = name
|
|
|
|
return self._simple_command(name, threading_algorithm, charset, *search_criteria, **kw)
|
|
|
|
|
|
|
|
|
|
|
|
def uid(self, command, *args, **kw):
|
|
|
|
"""(typ, [data]) = uid(command, arg, ...)
|
|
|
|
Execute "command arg ..." with messages identified by UID,
|
|
|
|
rather than message number.
|
|
|
|
Assumes 'command' is legal in current state.
|
|
|
|
Returns response appropriate to 'command'."""
|
|
|
|
|
|
|
|
command = command.upper()
|
|
|
|
if command in UID_direct:
|
|
|
|
resp = command
|
|
|
|
else:
|
|
|
|
resp = 'FETCH'
|
|
|
|
kw['untagged_response'] = resp
|
|
|
|
return self._simple_command('UID', command, *args, **kw)
|
|
|
|
|
|
|
|
|
|
|
|
def unsubscribe(self, mailbox, **kw):
|
|
|
|
"""(typ, [data]) = unsubscribe(mailbox)
|
|
|
|
Unsubscribe from old mailbox."""
|
|
|
|
|
|
|
|
try:
|
|
|
|
return self._simple_command('UNSUBSCRIBE', mailbox, **kw)
|
|
|
|
finally:
|
2011-06-09 15:26:14 +02:00
|
|
|
self._release_state_change()
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
def xatom(self, name, *args, **kw):
|
|
|
|
"""(typ, [data]) = xatom(name, arg, ...)
|
|
|
|
Allow simple extension commands notified by server in CAPABILITY response.
|
|
|
|
Assumes extension command 'name' is legal in current state.
|
|
|
|
Returns response appropriate to extension command 'name'."""
|
|
|
|
|
|
|
|
name = name.upper()
|
|
|
|
if not name in Commands:
|
|
|
|
Commands[name] = ((self.state,), False)
|
|
|
|
try:
|
|
|
|
return self._simple_command(name, *args, **kw)
|
|
|
|
finally:
|
2011-06-09 15:26:14 +02:00
|
|
|
self._release_state_change()
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# Internal methods
|
|
|
|
|
|
|
|
|
|
|
|
def _append_untagged(self, typ, dat):
|
|
|
|
|
2011-08-15 11:55:41 +02:00
|
|
|
# Append new 'dat' to end of last untagged response if same 'typ',
|
|
|
|
# else append new response.
|
|
|
|
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
if dat is None: dat = ''
|
|
|
|
|
2011-08-15 11:55:41 +02:00
|
|
|
self.commands_lock.acquire()
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
2011-08-15 11:55:41 +02:00
|
|
|
if self.untagged_responses:
|
|
|
|
urn, urd = self.untagged_responses[-1]
|
|
|
|
if urn != typ:
|
|
|
|
urd = None
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
else:
|
2011-08-15 11:55:41 +02:00
|
|
|
urd = None
|
|
|
|
|
|
|
|
if urd is None:
|
|
|
|
urd = []
|
|
|
|
self.untagged_responses.append([typ, urd])
|
|
|
|
|
|
|
|
urd.append(dat)
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
self.commands_lock.release()
|
2011-08-15 11:55:41 +02:00
|
|
|
|
2015-09-14 14:56:17 +02:00
|
|
|
if __debug__: self._log(5, 'untagged_responses[%s] %s += ["%.80s"]' % (typ, len(urd)-1, dat))
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
def _check_bye(self):
|
2011-08-15 11:55:41 +02:00
|
|
|
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
bye = self._get_untagged_response('BYE', leave=True)
|
|
|
|
if bye:
|
2015-10-15 04:15:37 +02:00
|
|
|
if str != bytes:
|
|
|
|
raise self.abort(bye[-1].decode('ASCII', 'replace'))
|
|
|
|
else:
|
|
|
|
raise self.abort(bye[-1])
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
def _checkquote(self, arg):
|
|
|
|
|
|
|
|
# Must quote command args if "atom-specials" present,
|
2011-08-15 11:55:41 +02:00
|
|
|
# and not already quoted. NB: single quotes are removed.
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
2015-03-18 21:54:36 +01:00
|
|
|
if not isinstance(arg, string_types):
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
return arg
|
|
|
|
if len(arg) >= 2 and (arg[0],arg[-1]) in (('(',')'),('"','"')):
|
|
|
|
return arg
|
2011-08-15 11:55:41 +02:00
|
|
|
if len(arg) >= 2 and (arg[0],arg[-1]) in (("'","'"),):
|
|
|
|
return arg[1:-1]
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
if arg and self.mustquote_cre.search(arg) is None:
|
|
|
|
return arg
|
|
|
|
return self._quote(arg)
|
|
|
|
|
|
|
|
|
2011-06-09 15:26:14 +02:00
|
|
|
def _choose_nonull_or_dflt(self, dflt, *args):
|
2015-03-18 21:54:36 +01:00
|
|
|
if isinstance(dflt, string_types):
|
|
|
|
dflttyp = string_types # Allow any string type
|
2012-04-19 13:18:44 +02:00
|
|
|
else:
|
|
|
|
dflttyp = type(dflt)
|
2011-06-09 15:26:14 +02:00
|
|
|
for arg in args:
|
|
|
|
if arg is not None:
|
2011-11-02 10:55:42 +01:00
|
|
|
if isinstance(arg, dflttyp):
|
2011-06-09 15:26:14 +02:00
|
|
|
return arg
|
2011-11-02 10:55:42 +01:00
|
|
|
if __debug__: self._log(0, 'bad arg is %s, expecting %s' % (type(arg), dflttyp))
|
2011-06-09 15:26:14 +02:00
|
|
|
return dflt
|
|
|
|
|
|
|
|
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
def _command(self, name, *args, **kw):
|
|
|
|
|
|
|
|
if Commands[name][CMD_VAL_ASYNC]:
|
|
|
|
cmdtyp = 'async'
|
|
|
|
else:
|
|
|
|
cmdtyp = 'sync'
|
|
|
|
|
|
|
|
if __debug__: self._log(1, '[%s] %s %s' % (cmdtyp, name, args))
|
|
|
|
|
2011-06-09 15:26:14 +02:00
|
|
|
if __debug__: self._log(3, 'state_change_pending.acquire')
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
self.state_change_pending.acquire()
|
|
|
|
|
|
|
|
self._end_idle()
|
|
|
|
|
|
|
|
if cmdtyp == 'async':
|
|
|
|
self.state_change_pending.release()
|
2011-06-09 15:26:14 +02:00
|
|
|
if __debug__: self._log(3, 'state_change_pending.release')
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
else:
|
|
|
|
# Need to wait for all async commands to complete
|
|
|
|
self._check_bye()
|
|
|
|
self.commands_lock.acquire()
|
|
|
|
if self.tagged_commands:
|
|
|
|
self.state_change_free.clear()
|
|
|
|
need_event = True
|
|
|
|
else:
|
|
|
|
need_event = False
|
|
|
|
self.commands_lock.release()
|
|
|
|
if need_event:
|
2011-06-09 15:26:14 +02:00
|
|
|
if __debug__: self._log(3, 'sync command %s waiting for empty commands Q' % name)
|
2015-10-15 04:15:37 +02:00
|
|
|
self.state_change_free.wait(threading.TIMEOUT_MAX)
|
2011-06-09 15:26:14 +02:00
|
|
|
if __debug__: self._log(3, 'sync command %s proceeding' % name)
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
if self.state not in Commands[name][CMD_VAL_STATES]:
|
|
|
|
self.literal = None
|
2015-11-05 09:07:31 +01:00
|
|
|
raise self.error('command %s illegal in state %s, only allowed in states %s'
|
|
|
|
% (name, self.state, ', '.join(Commands[name][CMD_VAL_STATES])))
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
self._check_bye()
|
|
|
|
|
2015-03-18 21:54:36 +01:00
|
|
|
if name in ('EXAMINE', 'SELECT'):
|
2015-03-20 11:02:17 +01:00
|
|
|
self.commands_lock.acquire()
|
2015-03-18 21:54:36 +01:00
|
|
|
self.untagged_responses = [] # Flush all untagged responses
|
2015-03-20 11:02:17 +01:00
|
|
|
self.commands_lock.release()
|
2015-03-18 21:54:36 +01:00
|
|
|
else:
|
|
|
|
for typ in ('OK', 'NO', 'BAD'):
|
|
|
|
while self._get_untagged_response(typ):
|
|
|
|
continue
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
2015-09-14 14:56:17 +02:00
|
|
|
if not self.is_readonly and self._get_untagged_response('READ-ONLY', leave=True):
|
2015-03-18 21:54:36 +01:00
|
|
|
self.literal = None
|
|
|
|
raise self.readonly('mailbox status changed to READ-ONLY')
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
if self.Terminate:
|
|
|
|
raise self.abort('connection closed')
|
|
|
|
|
|
|
|
rqb = self._request_push(name=name, **kw)
|
|
|
|
|
|
|
|
data = '%s %s' % (rqb.tag, name)
|
|
|
|
for arg in args:
|
|
|
|
if arg is None: continue
|
|
|
|
data = '%s %s' % (data, self._checkquote(arg))
|
|
|
|
|
|
|
|
literal = self.literal
|
|
|
|
if literal is not None:
|
|
|
|
self.literal = None
|
2015-03-18 21:54:36 +01:00
|
|
|
if isinstance(literal, string_types):
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
literator = None
|
2015-12-28 01:17:42 +01:00
|
|
|
data = '%s {%s}' % (data, len(literal))
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
else:
|
|
|
|
literator = literal
|
|
|
|
|
|
|
|
if __debug__: self._log(4, 'data=%s' % data)
|
|
|
|
|
|
|
|
rqb.data = '%s%s' % (data, CRLF)
|
|
|
|
|
|
|
|
if literal is None:
|
|
|
|
self.ouq.put(rqb)
|
|
|
|
return rqb
|
|
|
|
|
2013-09-02 07:08:50 +02:00
|
|
|
# Must setup continuation expectancy *before* ouq.put
|
2015-10-15 04:15:37 +02:00
|
|
|
crqb = self._request_push(name=name, tag='continuation')
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
self.ouq.put(rqb)
|
|
|
|
|
|
|
|
while True:
|
|
|
|
# Wait for continuation response
|
|
|
|
|
|
|
|
ok, data = crqb.get_response('command: %s => %%s' % name)
|
2011-06-09 15:26:14 +02:00
|
|
|
if __debug__: self._log(4, 'continuation => %s, %s' % (ok, data))
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
# NO/BAD response?
|
|
|
|
|
|
|
|
if not ok:
|
|
|
|
break
|
|
|
|
|
|
|
|
# Send literal
|
|
|
|
|
|
|
|
if literator is not None:
|
|
|
|
literal = literator(data, rqb)
|
|
|
|
|
|
|
|
if literal is None:
|
|
|
|
break
|
|
|
|
|
|
|
|
if literator is not None:
|
|
|
|
# Need new request for next continuation response
|
2015-10-15 04:15:37 +02:00
|
|
|
crqb = self._request_push(name=name, tag='continuation')
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
if __debug__: self._log(4, 'write literal size %s' % len(literal))
|
|
|
|
crqb.data = '%s%s' % (literal, CRLF)
|
|
|
|
self.ouq.put(crqb)
|
|
|
|
|
|
|
|
if literator is None:
|
|
|
|
break
|
|
|
|
|
|
|
|
return rqb
|
|
|
|
|
|
|
|
|
|
|
|
def _command_complete(self, rqb, kw):
|
|
|
|
|
|
|
|
# Called for non-callback commands
|
|
|
|
|
|
|
|
self._check_bye()
|
2013-09-02 07:08:50 +02:00
|
|
|
typ, dat = rqb.get_response('command: %s => %%s' % rqb.name)
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
if typ == 'BAD':
|
|
|
|
if __debug__: self._print_log()
|
|
|
|
raise self.error('%s command error: %s %s. Data: %.100s' % (rqb.name, typ, dat, rqb.data))
|
|
|
|
if 'untagged_response' in kw:
|
|
|
|
return self._untagged_response(typ, dat, kw['untagged_response'])
|
|
|
|
return typ, dat
|
|
|
|
|
|
|
|
|
2015-03-18 21:54:36 +01:00
|
|
|
def _command_completer(self, cb_arg_list):
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
# Called for callback commands
|
2015-09-14 14:56:17 +02:00
|
|
|
response, cb_arg, error = cb_arg_list
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
rqb, kw = cb_arg
|
|
|
|
rqb.callback = kw['callback']
|
|
|
|
rqb.callback_arg = kw.get('cb_arg')
|
|
|
|
if error is not None:
|
|
|
|
if __debug__: self._print_log()
|
|
|
|
typ, val = error
|
|
|
|
rqb.abort(typ, val)
|
|
|
|
return
|
|
|
|
bye = self._get_untagged_response('BYE', leave=True)
|
|
|
|
if bye:
|
2015-10-15 04:15:37 +02:00
|
|
|
if str != bytes:
|
|
|
|
rqb.abort(self.abort, bye[-1].decode('ASCII', 'replace'))
|
|
|
|
else:
|
|
|
|
rqb.abort(self.abort, bye[-1])
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
return
|
|
|
|
typ, dat = response
|
|
|
|
if typ == 'BAD':
|
|
|
|
if __debug__: self._print_log()
|
|
|
|
rqb.abort(self.error, '%s command error: %s %s. Data: %.100s' % (rqb.name, typ, dat, rqb.data))
|
|
|
|
return
|
2015-09-14 14:56:17 +02:00
|
|
|
if __debug__: self._log(4, '_command_completer(%s, %s, None) = %s' % (response, cb_arg, rqb.tag))
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
if 'untagged_response' in kw:
|
|
|
|
response = self._untagged_response(typ, dat, kw['untagged_response'])
|
|
|
|
rqb.deliver(response)
|
|
|
|
|
|
|
|
|
|
|
|
def _deliver_dat(self, typ, dat, kw):
|
|
|
|
|
|
|
|
if 'callback' in kw:
|
|
|
|
kw['callback'](((typ, dat), kw.get('cb_arg'), None))
|
|
|
|
return typ, dat
|
|
|
|
|
|
|
|
|
|
|
|
def _deliver_exc(self, exc, dat, kw):
|
|
|
|
|
|
|
|
if 'callback' in kw:
|
|
|
|
kw['callback']((None, kw.get('cb_arg'), (exc, dat)))
|
|
|
|
raise exc(dat)
|
|
|
|
|
|
|
|
|
|
|
|
def _end_idle(self):
|
|
|
|
|
2011-06-09 15:26:14 +02:00
|
|
|
self.idle_lock.acquire()
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
irqb = self.idle_rqb
|
|
|
|
if irqb is None:
|
2011-06-09 15:26:14 +02:00
|
|
|
self.idle_lock.release()
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
return
|
|
|
|
self.idle_rqb = None
|
|
|
|
self.idle_timeout = None
|
2011-06-09 15:26:14 +02:00
|
|
|
self.idle_lock.release()
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
irqb.data = 'DONE%s' % CRLF
|
|
|
|
self.ouq.put(irqb)
|
|
|
|
if __debug__: self._log(2, 'server IDLE finished')
|
|
|
|
|
|
|
|
|
|
|
|
def _get_untagged_response(self, name, leave=False):
|
|
|
|
|
|
|
|
self.commands_lock.acquire()
|
|
|
|
|
|
|
|
for i, (typ, dat) in enumerate(self.untagged_responses):
|
|
|
|
if typ == name:
|
|
|
|
if not leave:
|
|
|
|
del self.untagged_responses[i]
|
|
|
|
self.commands_lock.release()
|
2015-09-14 14:56:17 +02:00
|
|
|
if __debug__: self._log(5, '_get_untagged_response(%s) => %.80s' % (name, dat))
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
return dat
|
|
|
|
|
|
|
|
self.commands_lock.release()
|
|
|
|
return None
|
|
|
|
|
|
|
|
|
|
|
|
def _match(self, cre, s):
|
|
|
|
|
|
|
|
# Run compiled regular expression 'cre' match method on 's'.
|
|
|
|
# Save result, return success.
|
|
|
|
|
|
|
|
self.mo = cre.match(s)
|
|
|
|
return self.mo is not None
|
|
|
|
|
|
|
|
|
|
|
|
def _put_response(self, resp):
|
|
|
|
|
2013-08-27 16:56:43 +02:00
|
|
|
if self._expecting_data:
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
rlen = len(resp)
|
2013-08-27 16:56:43 +02:00
|
|
|
dlen = min(self._expecting_data_len, rlen)
|
2015-03-25 13:39:13 +01:00
|
|
|
if __debug__: self._log(5, '_put_response expecting data len %s, got %s' % (self._expecting_data_len, rlen))
|
2013-08-27 16:56:43 +02:00
|
|
|
self._expecting_data_len -= dlen
|
|
|
|
self._expecting_data = (self._expecting_data_len != 0)
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
if rlen <= dlen:
|
|
|
|
self._accumulated_data.append(resp)
|
|
|
|
return
|
|
|
|
self._accumulated_data.append(resp[:dlen])
|
|
|
|
resp = resp[dlen:]
|
|
|
|
|
|
|
|
if self._accumulated_data:
|
|
|
|
typ, dat = self._literal_expected
|
|
|
|
self._append_untagged(typ, (dat, ''.join(self._accumulated_data)))
|
|
|
|
self._accumulated_data = []
|
|
|
|
|
|
|
|
# Protocol mandates all lines terminated by CRLF
|
|
|
|
resp = resp[:-2]
|
2015-03-20 11:02:17 +01:00
|
|
|
if __debug__: self._log(5, '_put_response(%s)' % resp)
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
if 'continuation' in self.tagged_commands:
|
|
|
|
continuation_expected = True
|
|
|
|
else:
|
|
|
|
continuation_expected = False
|
|
|
|
|
|
|
|
if self._literal_expected is not None:
|
|
|
|
dat = resp
|
|
|
|
if self._match(self.literal_cre, dat):
|
|
|
|
self._literal_expected[1] = dat
|
2013-08-27 16:56:43 +02:00
|
|
|
self._expecting_data = True
|
|
|
|
self._expecting_data_len = int(self.mo.group('size'))
|
|
|
|
if __debug__: self._log(4, 'expecting literal size %s' % self._expecting_data_len)
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
return
|
|
|
|
typ = self._literal_expected[0]
|
|
|
|
self._literal_expected = None
|
2015-03-25 13:39:13 +01:00
|
|
|
if dat:
|
|
|
|
self._append_untagged(typ, dat) # Tail
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
if __debug__: self._log(4, 'literal completed')
|
|
|
|
else:
|
|
|
|
# Command completion response?
|
|
|
|
if self._match(self.tagre, resp):
|
|
|
|
tag = self.mo.group('tag')
|
|
|
|
typ = self.mo.group('type')
|
|
|
|
dat = self.mo.group('data')
|
2015-03-20 11:02:17 +01:00
|
|
|
if typ in ('OK', 'NO', 'BAD') and self._match(self.response_code_cre, dat):
|
|
|
|
self._append_untagged(self.mo.group('type'), self.mo.group('data'))
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
if not tag in self.tagged_commands:
|
|
|
|
if __debug__: self._log(1, 'unexpected tagged response: %s' % resp)
|
|
|
|
else:
|
|
|
|
self._request_pop(tag, (typ, [dat]))
|
|
|
|
else:
|
|
|
|
dat2 = None
|
|
|
|
|
|
|
|
# '*' (untagged) responses?
|
|
|
|
|
|
|
|
if not self._match(self.untagged_response_cre, resp):
|
|
|
|
if self._match(self.untagged_status_cre, resp):
|
|
|
|
dat2 = self.mo.group('data2')
|
|
|
|
|
|
|
|
if self.mo is None:
|
|
|
|
# Only other possibility is '+' (continuation) response...
|
|
|
|
|
|
|
|
if self._match(self.continuation_cre, resp):
|
|
|
|
if not continuation_expected:
|
|
|
|
if __debug__: self._log(1, "unexpected continuation response: '%s'" % resp)
|
|
|
|
return
|
|
|
|
self._request_pop('continuation', (True, self.mo.group('data')))
|
|
|
|
return
|
|
|
|
|
|
|
|
if __debug__: self._log(1, "unexpected response: '%s'" % resp)
|
|
|
|
return
|
|
|
|
|
|
|
|
typ = self.mo.group('type')
|
|
|
|
dat = self.mo.group('data')
|
|
|
|
if dat is None: dat = '' # Null untagged response
|
|
|
|
if dat2: dat = dat + ' ' + dat2
|
|
|
|
|
|
|
|
# Is there a literal to come?
|
|
|
|
|
|
|
|
if self._match(self.literal_cre, dat):
|
2013-08-27 16:56:43 +02:00
|
|
|
self._expecting_data = True
|
|
|
|
self._expecting_data_len = int(self.mo.group('size'))
|
|
|
|
if __debug__: self._log(4, 'read literal size %s' % self._expecting_data_len)
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
self._literal_expected = [typ, dat]
|
|
|
|
return
|
|
|
|
|
|
|
|
self._append_untagged(typ, dat)
|
2015-03-20 11:02:17 +01:00
|
|
|
if typ in ('OK', 'NO', 'BAD') and self._match(self.response_code_cre, dat):
|
|
|
|
self._append_untagged(self.mo.group('type'), self.mo.group('data'))
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
2011-06-09 15:26:14 +02:00
|
|
|
if typ != 'OK': # NO, BYE, IDLE
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
self._end_idle()
|
|
|
|
|
|
|
|
# Command waiting for aborted continuation response?
|
|
|
|
|
|
|
|
if continuation_expected:
|
|
|
|
self._request_pop('continuation', (False, resp))
|
|
|
|
|
|
|
|
# Bad news?
|
|
|
|
|
|
|
|
if typ in ('NO', 'BAD', 'BYE'):
|
|
|
|
if typ == 'BYE':
|
|
|
|
self.Terminate = True
|
|
|
|
if __debug__: self._log(1, '%s response: %s' % (typ, dat))
|
|
|
|
|
|
|
|
|
|
|
|
def _quote(self, arg):
|
|
|
|
|
|
|
|
return '"%s"' % arg.replace('\\', '\\\\').replace('"', '\\"')
|
|
|
|
|
|
|
|
|
2011-06-09 15:26:14 +02:00
|
|
|
def _release_state_change(self):
|
|
|
|
|
|
|
|
if self.state_change_pending.locked():
|
|
|
|
self.state_change_pending.release()
|
|
|
|
if __debug__: self._log(3, 'state_change_pending.release')
|
|
|
|
|
|
|
|
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
def _request_pop(self, name, data):
|
|
|
|
|
|
|
|
self.commands_lock.acquire()
|
|
|
|
rqb = self.tagged_commands.pop(name)
|
|
|
|
if not self.tagged_commands:
|
2015-09-14 14:56:17 +02:00
|
|
|
need_event = True
|
|
|
|
else:
|
|
|
|
need_event = False
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
self.commands_lock.release()
|
2015-09-14 14:56:17 +02:00
|
|
|
|
|
|
|
if __debug__: self._log(4, '_request_pop(%s, %s) [%d] = %s' % (name, data, len(self.tagged_commands), rqb.tag))
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
rqb.deliver(data)
|
|
|
|
|
2015-09-14 14:56:17 +02:00
|
|
|
if need_event:
|
|
|
|
if __debug__: self._log(3, 'state_change_free.set')
|
|
|
|
self.state_change_free.set()
|
|
|
|
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
def _request_push(self, tag=None, name=None, **kw):
|
|
|
|
|
|
|
|
self.commands_lock.acquire()
|
|
|
|
rqb = Request(self, name=name, **kw)
|
|
|
|
if tag is None:
|
|
|
|
tag = rqb.tag
|
|
|
|
self.tagged_commands[tag] = rqb
|
|
|
|
self.commands_lock.release()
|
2014-10-10 14:13:16 +02:00
|
|
|
if __debug__: self._log(4, '_request_push(%s, %s, %s) = %s' % (tag, name, repr(kw), rqb.tag))
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
return rqb
|
|
|
|
|
|
|
|
|
|
|
|
def _simple_command(self, name, *args, **kw):
|
|
|
|
|
|
|
|
if 'callback' in kw:
|
2012-04-19 13:18:44 +02:00
|
|
|
# Note: old calling sequence for back-compat with python <2.6
|
|
|
|
self._command(name, callback=self._command_completer, cb_arg=kw, cb_self=True, *args)
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
return (None, None)
|
|
|
|
return self._command_complete(self._command(name, *args), kw)
|
|
|
|
|
|
|
|
|
|
|
|
def _untagged_response(self, typ, dat, name):
|
2011-08-15 11:55:41 +02:00
|
|
|
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
if typ == 'NO':
|
|
|
|
return typ, dat
|
|
|
|
data = self._get_untagged_response(name)
|
|
|
|
if not data:
|
|
|
|
return typ, [None]
|
2011-06-09 15:26:14 +02:00
|
|
|
while True:
|
|
|
|
dat = self._get_untagged_response(name)
|
|
|
|
if not dat:
|
|
|
|
break
|
|
|
|
data += dat
|
2015-09-14 14:56:17 +02:00
|
|
|
if __debug__: self._log(4, '_untagged_response(%s, ?, %s) => %.80s' % (typ, name, data))
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
return typ, data
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# Threads
|
|
|
|
|
|
|
|
|
|
|
|
def _close_threads(self):
|
|
|
|
|
|
|
|
if __debug__: self._log(1, '_close_threads')
|
|
|
|
|
|
|
|
self.ouq.put(None)
|
|
|
|
self.wrth.join()
|
|
|
|
|
|
|
|
if __debug__: self._log(1, 'call shutdown')
|
|
|
|
|
|
|
|
self.shutdown()
|
|
|
|
|
|
|
|
self.rdth.join()
|
|
|
|
self.inth.join()
|
|
|
|
|
|
|
|
|
|
|
|
def _handler(self):
|
|
|
|
|
|
|
|
resp_timeout = self.resp_timeout
|
|
|
|
|
|
|
|
threading.currentThread().setName(self.identifier + 'handler')
|
|
|
|
|
|
|
|
time.sleep(0.1) # Don't start handling before main thread ready
|
|
|
|
|
|
|
|
if __debug__: self._log(1, 'starting')
|
|
|
|
|
2015-03-18 21:54:36 +01:00
|
|
|
typ, val = self.abort, 'connection terminated'
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
while not self.Terminate:
|
2014-10-10 14:23:07 +02:00
|
|
|
|
|
|
|
self.idle_lock.acquire()
|
|
|
|
if self.idle_timeout is not None:
|
|
|
|
timeout = self.idle_timeout - time.time()
|
|
|
|
if timeout <= 0:
|
|
|
|
timeout = 1
|
|
|
|
if __debug__:
|
|
|
|
if self.idle_rqb is not None:
|
|
|
|
self._log(5, 'server IDLING, timeout=%.2f' % timeout)
|
|
|
|
else:
|
|
|
|
timeout = resp_timeout
|
|
|
|
self.idle_lock.release()
|
|
|
|
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
try:
|
|
|
|
line = self.inq.get(True, timeout)
|
2015-03-18 21:54:36 +01:00
|
|
|
except queue.Empty:
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
if self.idle_rqb is None:
|
|
|
|
if resp_timeout is not None and self.tagged_commands:
|
|
|
|
if __debug__: self._log(1, 'response timeout')
|
|
|
|
typ, val = self.abort, 'no response after %s secs' % resp_timeout
|
|
|
|
break
|
|
|
|
continue
|
|
|
|
if self.idle_timeout > time.time():
|
|
|
|
continue
|
|
|
|
if __debug__: self._log(2, 'server IDLE timedout')
|
|
|
|
line = IDLE_TIMEOUT_RESPONSE
|
|
|
|
|
|
|
|
if line is None:
|
|
|
|
if __debug__: self._log(1, 'inq None - terminating')
|
|
|
|
break
|
|
|
|
|
2015-03-18 21:54:36 +01:00
|
|
|
if not isinstance(line, string_types):
|
|
|
|
typ, val = line
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
break
|
|
|
|
|
|
|
|
try:
|
|
|
|
self._put_response(line)
|
|
|
|
except:
|
|
|
|
typ, val = self.error, 'program error: %s - %s' % sys.exc_info()[:2]
|
|
|
|
break
|
|
|
|
|
|
|
|
self.Terminate = True
|
|
|
|
|
2014-10-10 14:13:16 +02:00
|
|
|
if __debug__: self._log(1, 'terminating: %s' % repr(val))
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
while not self.ouq.empty():
|
|
|
|
try:
|
2015-03-18 21:54:36 +01:00
|
|
|
qel = self.ouq.get_nowait()
|
|
|
|
if qel is not None:
|
|
|
|
qel.abort(typ, val)
|
|
|
|
except queue.Empty:
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
break
|
|
|
|
self.ouq.put(None)
|
|
|
|
|
|
|
|
self.commands_lock.acquire()
|
2015-03-18 21:54:36 +01:00
|
|
|
for name in list(self.tagged_commands.keys()):
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
rqb = self.tagged_commands.pop(name)
|
2015-03-18 21:54:36 +01:00
|
|
|
rqb.abort(typ, val)
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
self.state_change_free.set()
|
|
|
|
self.commands_lock.release()
|
2011-06-09 15:26:14 +02:00
|
|
|
if __debug__: self._log(3, 'state_change_free.set')
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
if __debug__: self._log(1, 'finished')
|
|
|
|
|
|
|
|
|
|
|
|
if hasattr(select_module, "poll"):
|
|
|
|
|
|
|
|
def _reader(self):
|
|
|
|
|
|
|
|
threading.currentThread().setName(self.identifier + 'reader')
|
|
|
|
|
|
|
|
if __debug__: self._log(1, 'starting using poll')
|
|
|
|
|
|
|
|
def poll_error(state):
|
|
|
|
PollErrors = {
|
|
|
|
select.POLLERR: 'Error',
|
|
|
|
select.POLLHUP: 'Hang up',
|
|
|
|
select.POLLNVAL: 'Invalid request: descriptor not open',
|
|
|
|
}
|
|
|
|
return ' '.join([PollErrors[s] for s in PollErrors.keys() if (s & state)])
|
|
|
|
|
2015-09-14 14:56:17 +02:00
|
|
|
if bytes != str:
|
|
|
|
line_part = b''
|
|
|
|
else:
|
|
|
|
line_part = ''
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
poll = select.poll()
|
|
|
|
|
|
|
|
poll.register(self.read_fd, select.POLLIN)
|
|
|
|
|
|
|
|
rxzero = 0
|
2011-06-09 15:26:14 +02:00
|
|
|
terminate = False
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
read_poll_timeout = self.read_poll_timeout * 1000 # poll() timeout is in millisecs
|
|
|
|
|
2011-06-09 15:26:14 +02:00
|
|
|
while not (terminate or self.Terminate):
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
if self.state == LOGOUT:
|
2015-09-14 14:56:17 +02:00
|
|
|
timeout = 10
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
else:
|
|
|
|
timeout = read_poll_timeout
|
|
|
|
try:
|
|
|
|
r = poll.poll(timeout)
|
2014-10-10 14:13:16 +02:00
|
|
|
if __debug__: self._log(5, 'poll => %s' % repr(r))
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
if not r:
|
|
|
|
continue # Timeout
|
|
|
|
|
|
|
|
fd,state = r[0]
|
|
|
|
|
|
|
|
if state & select.POLLIN:
|
2011-06-09 15:26:14 +02:00
|
|
|
data = self.read(self.read_size) # Drain ssl buffer if present
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
start = 0
|
|
|
|
dlen = len(data)
|
|
|
|
if __debug__: self._log(5, 'rcvd %s' % dlen)
|
|
|
|
if dlen == 0:
|
|
|
|
rxzero += 1
|
|
|
|
if rxzero > 5:
|
|
|
|
raise IOError("Too many read 0")
|
|
|
|
time.sleep(0.1)
|
2012-04-19 13:18:44 +02:00
|
|
|
continue # Try again
|
|
|
|
rxzero = 0
|
|
|
|
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
while True:
|
2015-03-18 21:54:36 +01:00
|
|
|
if bytes != str:
|
|
|
|
stop = data.find(b'\n', start)
|
|
|
|
if stop < 0:
|
2015-09-14 14:56:17 +02:00
|
|
|
line_part += data[start:]
|
2015-03-18 21:54:36 +01:00
|
|
|
break
|
|
|
|
stop += 1
|
|
|
|
line_part, start, line = \
|
2015-09-14 14:56:17 +02:00
|
|
|
b'', stop, (line_part + data[start:stop]).decode(errors='ignore')
|
2015-03-18 21:54:36 +01:00
|
|
|
else:
|
|
|
|
stop = data.find('\n', start)
|
|
|
|
if stop < 0:
|
|
|
|
line_part += data[start:]
|
|
|
|
break
|
|
|
|
stop += 1
|
|
|
|
line_part, start, line = \
|
|
|
|
'', stop, line_part + data[start:stop]
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
if __debug__: self._log(4, '< %s' % line)
|
|
|
|
self.inq.put(line)
|
2011-06-09 15:26:14 +02:00
|
|
|
if self.TerminateReader:
|
|
|
|
terminate = True
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
if state & ~(select.POLLIN):
|
|
|
|
raise IOError(poll_error(state))
|
|
|
|
except:
|
|
|
|
reason = 'socket error: %s - %s' % sys.exc_info()[:2]
|
|
|
|
if __debug__:
|
|
|
|
if not self.Terminate:
|
|
|
|
self._print_log()
|
|
|
|
if self.debug: self.debug += 4 # Output all
|
|
|
|
self._log(1, reason)
|
2015-03-18 21:54:36 +01:00
|
|
|
self.inq.put((self.abort, reason))
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
break
|
|
|
|
|
|
|
|
poll.unregister(self.read_fd)
|
|
|
|
|
|
|
|
if __debug__: self._log(1, 'finished')
|
|
|
|
|
|
|
|
else:
|
|
|
|
|
|
|
|
# No "poll" - use select()
|
|
|
|
|
|
|
|
def _reader(self):
|
|
|
|
|
|
|
|
threading.currentThread().setName(self.identifier + 'reader')
|
|
|
|
|
|
|
|
if __debug__: self._log(1, 'starting using select')
|
|
|
|
|
2015-09-14 14:56:17 +02:00
|
|
|
if bytes != str:
|
|
|
|
line_part = b''
|
|
|
|
else:
|
|
|
|
line_part = ''
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
rxzero = 0
|
2011-06-09 15:26:14 +02:00
|
|
|
terminate = False
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
2011-06-09 15:26:14 +02:00
|
|
|
while not (terminate or self.Terminate):
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
if self.state == LOGOUT:
|
|
|
|
timeout = 1
|
|
|
|
else:
|
2011-06-09 15:26:14 +02:00
|
|
|
timeout = self.read_poll_timeout
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
try:
|
|
|
|
r,w,e = select.select([self.read_fd], [], [], timeout)
|
|
|
|
if __debug__: self._log(5, 'select => %s, %s, %s' % (r,w,e))
|
|
|
|
if not r: # Timeout
|
|
|
|
continue
|
|
|
|
|
2011-06-09 15:26:14 +02:00
|
|
|
data = self.read(self.read_size) # Drain ssl buffer if present
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
start = 0
|
|
|
|
dlen = len(data)
|
|
|
|
if __debug__: self._log(5, 'rcvd %s' % dlen)
|
|
|
|
if dlen == 0:
|
|
|
|
rxzero += 1
|
|
|
|
if rxzero > 5:
|
|
|
|
raise IOError("Too many read 0")
|
|
|
|
time.sleep(0.1)
|
2012-04-19 13:18:44 +02:00
|
|
|
continue # Try again
|
|
|
|
rxzero = 0
|
|
|
|
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
while True:
|
2015-03-18 21:54:36 +01:00
|
|
|
if bytes != str:
|
|
|
|
stop = data.find(b'\n', start)
|
|
|
|
if stop < 0:
|
2015-09-14 14:56:17 +02:00
|
|
|
line_part += data[start:]
|
2015-03-18 21:54:36 +01:00
|
|
|
break
|
|
|
|
stop += 1
|
|
|
|
line_part, start, line = \
|
2015-09-14 14:56:17 +02:00
|
|
|
b'', stop, (line_part + data[start:stop]).decode(errors='ignore')
|
2015-03-18 21:54:36 +01:00
|
|
|
else:
|
|
|
|
stop = data.find('\n', start)
|
|
|
|
if stop < 0:
|
|
|
|
line_part += data[start:]
|
|
|
|
break
|
|
|
|
stop += 1
|
|
|
|
line_part, start, line = \
|
|
|
|
'', stop, line_part + data[start:stop]
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
if __debug__: self._log(4, '< %s' % line)
|
|
|
|
self.inq.put(line)
|
2011-06-09 15:26:14 +02:00
|
|
|
if self.TerminateReader:
|
|
|
|
terminate = True
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
except:
|
|
|
|
reason = 'socket error: %s - %s' % sys.exc_info()[:2]
|
|
|
|
if __debug__:
|
|
|
|
if not self.Terminate:
|
|
|
|
self._print_log()
|
|
|
|
if self.debug: self.debug += 4 # Output all
|
|
|
|
self._log(1, reason)
|
2015-03-18 21:54:36 +01:00
|
|
|
self.inq.put((self.abort, reason))
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
break
|
|
|
|
|
|
|
|
if __debug__: self._log(1, 'finished')
|
|
|
|
|
|
|
|
|
|
|
|
def _writer(self):
|
|
|
|
|
|
|
|
threading.currentThread().setName(self.identifier + 'writer')
|
|
|
|
|
|
|
|
if __debug__: self._log(1, 'starting')
|
|
|
|
|
|
|
|
reason = 'Terminated'
|
|
|
|
|
|
|
|
while not self.Terminate:
|
|
|
|
rqb = self.ouq.get()
|
|
|
|
if rqb is None:
|
|
|
|
break # Outq flushed
|
|
|
|
|
|
|
|
try:
|
|
|
|
self.send(rqb.data)
|
|
|
|
if __debug__: self._log(4, '> %s' % rqb.data)
|
|
|
|
except:
|
|
|
|
reason = 'socket error: %s - %s' % sys.exc_info()[:2]
|
|
|
|
if __debug__:
|
|
|
|
if not self.Terminate:
|
|
|
|
self._print_log()
|
|
|
|
if self.debug: self.debug += 4 # Output all
|
|
|
|
self._log(1, reason)
|
2015-03-18 21:54:36 +01:00
|
|
|
rqb.abort(self.abort, reason)
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
break
|
|
|
|
|
2015-03-18 21:54:36 +01:00
|
|
|
self.inq.put((self.abort, reason))
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
if __debug__: self._log(1, 'finished')
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# Debugging
|
|
|
|
|
|
|
|
|
|
|
|
if __debug__:
|
|
|
|
|
2011-06-09 15:26:14 +02:00
|
|
|
def _init_debug(self, debug=None, debug_file=None, debug_buf_lvl=None):
|
2013-09-02 07:08:50 +02:00
|
|
|
self.debug_lock = threading.Lock()
|
|
|
|
|
2011-06-09 15:26:14 +02:00
|
|
|
self.debug = self._choose_nonull_or_dflt(0, debug, Debug)
|
|
|
|
self.debug_file = self._choose_nonull_or_dflt(sys.stderr, debug_file)
|
|
|
|
self.debug_buf_lvl = self._choose_nonull_or_dflt(DFLT_DEBUG_BUF_LVL, debug_buf_lvl)
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
self._cmd_log_len = 20
|
|
|
|
self._cmd_log_idx = 0
|
|
|
|
self._cmd_log = {} # Last `_cmd_log_len' interactions
|
|
|
|
if self.debug:
|
|
|
|
self._mesg('imaplib2 version %s' % __version__)
|
2011-06-09 15:26:14 +02:00
|
|
|
self._mesg('imaplib2 debug level %s, buffer level %s' % (self.debug, self.debug_buf_lvl))
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
def _dump_ur(self, lvl):
|
|
|
|
if lvl > self.debug:
|
|
|
|
return
|
|
|
|
|
|
|
|
l = self.untagged_responses
|
|
|
|
if not l:
|
|
|
|
return
|
|
|
|
|
|
|
|
t = '\n\t\t'
|
2015-03-18 21:54:36 +01:00
|
|
|
l = ['%s: "%s"' % (x[0], x[1][0] and '" "'.join(x[1]) or '') for x in l]
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
self.debug_lock.acquire()
|
|
|
|
self._mesg('untagged responses dump:%s%s' % (t, t.join(l)))
|
|
|
|
self.debug_lock.release()
|
|
|
|
|
|
|
|
|
|
|
|
def _log(self, lvl, line):
|
|
|
|
if lvl > self.debug:
|
|
|
|
return
|
|
|
|
|
|
|
|
if line[-2:] == CRLF:
|
|
|
|
line = line[:-2] + '\\r\\n'
|
|
|
|
|
|
|
|
tn = threading.currentThread().getName()
|
|
|
|
|
2011-06-09 15:26:14 +02:00
|
|
|
if lvl <= 1 or self.debug > self.debug_buf_lvl:
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
self.debug_lock.acquire()
|
|
|
|
self._mesg(line, tn)
|
|
|
|
self.debug_lock.release()
|
2011-06-09 15:26:14 +02:00
|
|
|
if lvl != 1:
|
|
|
|
return
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
# Keep log of last `_cmd_log_len' interactions for debugging.
|
|
|
|
self.debug_lock.acquire()
|
|
|
|
self._cmd_log[self._cmd_log_idx] = (line, tn, time.time())
|
|
|
|
self._cmd_log_idx += 1
|
|
|
|
if self._cmd_log_idx >= self._cmd_log_len:
|
|
|
|
self._cmd_log_idx = 0
|
|
|
|
self.debug_lock.release()
|
|
|
|
|
|
|
|
|
|
|
|
def _mesg(self, s, tn=None, secs=None):
|
|
|
|
if secs is None:
|
|
|
|
secs = time.time()
|
|
|
|
if tn is None:
|
|
|
|
tn = threading.currentThread().getName()
|
|
|
|
tm = time.strftime('%M:%S', time.localtime(secs))
|
2011-06-09 15:26:14 +02:00
|
|
|
try:
|
|
|
|
self.debug_file.write(' %s.%02d %s %s\n' % (tm, (secs*100)%100, tn, s))
|
|
|
|
self.debug_file.flush()
|
|
|
|
finally:
|
|
|
|
pass
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
def _print_log(self):
|
|
|
|
self.debug_lock.acquire()
|
|
|
|
i, n = self._cmd_log_idx, self._cmd_log_len
|
|
|
|
if n: self._mesg('last %d log messages:' % n)
|
|
|
|
while n:
|
|
|
|
try:
|
|
|
|
self._mesg(*self._cmd_log[i])
|
|
|
|
except:
|
|
|
|
pass
|
|
|
|
i += 1
|
|
|
|
if i >= self._cmd_log_len:
|
|
|
|
i = 0
|
|
|
|
n -= 1
|
|
|
|
self.debug_lock.release()
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
class IMAP4_SSL(IMAP4):
|
|
|
|
|
|
|
|
"""IMAP4 client class over SSL connection
|
|
|
|
|
|
|
|
Instantiate with:
|
2015-10-15 04:15:37 +02:00
|
|
|
IMAP4_SSL(host=None, port=None, keyfile=None, certfile=None, ca_certs=None, cert_verify_cb=None, ssl_version="ssl23", debug=None, debug_file=None, identifier=None, timeout=None, debug_buf_lvl=None, tls_level="tls_compat")
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
2011-08-15 11:55:41 +02:00
|
|
|
host - host's name (default: localhost);
|
|
|
|
port - port number (default: standard IMAP4 SSL port);
|
|
|
|
keyfile - PEM formatted file that contains your private key (default: None);
|
|
|
|
certfile - PEM formatted certificate chain file (default: None);
|
|
|
|
ca_certs - PEM formatted certificate chain file used to validate server certificates (default: None);
|
|
|
|
cert_verify_cb - function to verify authenticity of server certificates (default: None);
|
2015-09-30 13:29:59 +02:00
|
|
|
ssl_version - SSL version to use (default: "ssl23", choose from: "tls1","ssl3","ssl23");
|
2011-08-15 11:55:41 +02:00
|
|
|
debug - debug level (default: 0 - no debug);
|
|
|
|
debug_file - debug stream (default: sys.stderr);
|
|
|
|
identifier - thread identifier prefix (default: host);
|
|
|
|
timeout - timeout in seconds when expecting a command response.
|
|
|
|
debug_buf_lvl - debug level at which buffering is turned off.
|
2015-09-30 13:29:59 +02:00
|
|
|
tls_level - TLS security level (default: "tls_compat").
|
|
|
|
|
|
|
|
The recognized values for tls_level are:
|
|
|
|
tls_secure: accept only TLS protocols recognized as "secure"
|
|
|
|
tls_no_ssl: disable SSLv2 and SSLv3 support
|
|
|
|
tls_compat: accept all SSL/TLS versions
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
For more documentation see the docstring of the parent class IMAP4.
|
|
|
|
"""
|
|
|
|
|
|
|
|
|
2015-09-30 13:29:59 +02:00
|
|
|
def __init__(self, host=None, port=None, keyfile=None, certfile=None, ca_certs=None, cert_verify_cb=None, ssl_version="ssl23", debug=None, debug_file=None, identifier=None, timeout=None, debug_buf_lvl=None, tls_level=TLS_COMPAT):
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
self.keyfile = keyfile
|
|
|
|
self.certfile = certfile
|
2011-08-15 11:55:41 +02:00
|
|
|
self.ca_certs = ca_certs
|
|
|
|
self.cert_verify_cb = cert_verify_cb
|
2013-07-07 23:18:59 +02:00
|
|
|
self.ssl_version = ssl_version
|
2015-09-30 13:29:59 +02:00
|
|
|
self.tls_level = tls_level
|
2011-06-09 15:26:14 +02:00
|
|
|
IMAP4.__init__(self, host, port, debug, debug_file, identifier, timeout, debug_buf_lvl)
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
def open(self, host=None, port=None):
|
|
|
|
"""open(host=None, port=None)
|
|
|
|
Setup secure connection to remote server on "host:port"
|
|
|
|
(default: localhost:standard IMAP4 SSL port).
|
|
|
|
This connection will be used by the routines:
|
|
|
|
read, send, shutdown, socket, ssl."""
|
|
|
|
|
2011-06-09 15:26:14 +02:00
|
|
|
self.host = self._choose_nonull_or_dflt('', host)
|
|
|
|
self.port = self._choose_nonull_or_dflt(IMAP4_SSL_PORT, port)
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
self.sock = self.open_socket()
|
2011-08-15 11:55:41 +02:00
|
|
|
self.ssl_wrap_socket()
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
def read(self, size):
|
|
|
|
"""data = read(size)
|
|
|
|
Read at most 'size' bytes from remote."""
|
|
|
|
|
|
|
|
if self.decompressor is None:
|
2011-08-15 11:55:41 +02:00
|
|
|
return self.sock.read(size)
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
if self.decompressor.unconsumed_tail:
|
|
|
|
data = self.decompressor.unconsumed_tail
|
|
|
|
else:
|
2012-04-19 13:18:44 +02:00
|
|
|
data = self.sock.read(READ_SIZE)
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
return self.decompressor.decompress(data, size)
|
|
|
|
|
|
|
|
|
|
|
|
def send(self, data):
|
|
|
|
"""send(data)
|
|
|
|
Send 'data' to remote."""
|
|
|
|
|
|
|
|
if self.compressor is not None:
|
|
|
|
data = self.compressor.compress(data)
|
|
|
|
data += self.compressor.flush(zlib.Z_SYNC_FLUSH)
|
|
|
|
|
2015-03-18 21:54:36 +01:00
|
|
|
if bytes != str:
|
2015-09-14 14:56:17 +02:00
|
|
|
data = bytes(data, 'utf8')
|
|
|
|
|
|
|
|
if hasattr(self.sock, "sendall"):
|
|
|
|
self.sock.sendall(data)
|
2011-08-15 11:55:41 +02:00
|
|
|
else:
|
2015-09-14 14:56:17 +02:00
|
|
|
dlen = len(data)
|
|
|
|
while dlen > 0:
|
|
|
|
sent = self.sock.write(data)
|
|
|
|
if sent == dlen:
|
|
|
|
break # avoid copy
|
|
|
|
data = data[sent:]
|
|
|
|
dlen = dlen - sent
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
def ssl(self):
|
|
|
|
"""ssl = ssl()
|
2012-04-19 13:18:44 +02:00
|
|
|
Return ssl instance used to communicate with the IMAP4 server."""
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
2011-08-15 11:55:41 +02:00
|
|
|
return self.sock
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
class IMAP4_stream(IMAP4):
|
|
|
|
|
|
|
|
"""IMAP4 client class over a stream
|
|
|
|
|
|
|
|
Instantiate with:
|
2011-08-15 11:55:41 +02:00
|
|
|
IMAP4_stream(command, debug=None, debug_file=None, identifier=None, timeout=None, debug_buf_lvl=None)
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
2011-08-15 11:55:41 +02:00
|
|
|
command - string that can be passed to subprocess.Popen();
|
|
|
|
debug - debug level (default: 0 - no debug);
|
|
|
|
debug_file - debug stream (default: sys.stderr);
|
|
|
|
identifier - thread identifier prefix (default: host);
|
|
|
|
timeout - timeout in seconds when expecting a command response.
|
|
|
|
debug_buf_lvl - debug level at which buffering is turned off.
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
For more documentation see the docstring of the parent class IMAP4.
|
|
|
|
"""
|
|
|
|
|
|
|
|
|
2011-06-09 15:26:14 +02:00
|
|
|
def __init__(self, command, debug=None, debug_file=None, identifier=None, timeout=None, debug_buf_lvl=None):
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
self.command = command
|
|
|
|
self.host = command
|
|
|
|
self.port = None
|
|
|
|
self.sock = None
|
|
|
|
self.writefile, self.readfile = None, None
|
|
|
|
self.read_fd = None
|
2011-06-09 15:26:14 +02:00
|
|
|
IMAP4.__init__(self, None, None, debug, debug_file, identifier, timeout, debug_buf_lvl)
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
def open(self, host=None, port=None):
|
|
|
|
"""open(host=None, port=None)
|
|
|
|
Setup a stream connection via 'self.command'.
|
|
|
|
This connection will be used by the routines:
|
|
|
|
read, send, shutdown, socket."""
|
|
|
|
|
|
|
|
from subprocess import Popen, PIPE
|
|
|
|
|
2013-09-02 07:08:50 +02:00
|
|
|
if __debug__: self._log(0, 'opening stream from command "%s"' % self.command)
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
self._P = Popen(self.command, shell=True, stdin=PIPE, stdout=PIPE, close_fds=True)
|
|
|
|
self.writefile, self.readfile = self._P.stdin, self._P.stdout
|
|
|
|
self.read_fd = self.readfile.fileno()
|
|
|
|
|
|
|
|
|
|
|
|
def read(self, size):
|
|
|
|
"""Read 'size' bytes from remote."""
|
|
|
|
|
|
|
|
if self.decompressor is None:
|
|
|
|
return os.read(self.read_fd, size)
|
|
|
|
|
|
|
|
if self.decompressor.unconsumed_tail:
|
|
|
|
data = self.decompressor.unconsumed_tail
|
|
|
|
else:
|
2012-04-19 13:18:44 +02:00
|
|
|
data = os.read(self.read_fd, READ_SIZE)
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
return self.decompressor.decompress(data, size)
|
|
|
|
|
|
|
|
|
|
|
|
def send(self, data):
|
|
|
|
"""Send data to remote."""
|
|
|
|
|
|
|
|
if self.compressor is not None:
|
|
|
|
data = self.compressor.compress(data)
|
|
|
|
data += self.compressor.flush(zlib.Z_SYNC_FLUSH)
|
|
|
|
|
2015-03-18 21:54:36 +01:00
|
|
|
if bytes != str:
|
2015-09-14 14:56:17 +02:00
|
|
|
data = bytes(data, 'utf8')
|
|
|
|
|
|
|
|
self.writefile.write(data)
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
self.writefile.flush()
|
|
|
|
|
|
|
|
|
|
|
|
def shutdown(self):
|
|
|
|
"""Close I/O established in "open"."""
|
|
|
|
|
|
|
|
self.readfile.close()
|
|
|
|
self.writefile.close()
|
|
|
|
|
|
|
|
|
|
|
|
class _Authenticator(object):
|
|
|
|
|
|
|
|
"""Private class to provide en/de-coding
|
|
|
|
for base64 authentication conversation."""
|
|
|
|
|
|
|
|
def __init__(self, mechinst):
|
|
|
|
self.mech = mechinst # Callable object to provide/process data
|
|
|
|
|
|
|
|
def process(self, data, rqb):
|
|
|
|
ret = self.mech(self.decode(data))
|
|
|
|
if ret is None:
|
|
|
|
return '*' # Abort conversation
|
|
|
|
return self.encode(ret)
|
|
|
|
|
|
|
|
def encode(self, inp):
|
|
|
|
#
|
|
|
|
# Invoke binascii.b2a_base64 iteratively with
|
|
|
|
# short even length buffers, strip the trailing
|
|
|
|
# line feed from the result and append. "Even"
|
|
|
|
# means a number that factors to both 6 and 8,
|
|
|
|
# so when it gets to the end of the 8-bit input
|
|
|
|
# there's no partial 6-bit output.
|
|
|
|
#
|
|
|
|
oup = ''
|
|
|
|
while inp:
|
|
|
|
if len(inp) > 48:
|
|
|
|
t = inp[:48]
|
|
|
|
inp = inp[48:]
|
|
|
|
else:
|
|
|
|
t = inp
|
|
|
|
inp = ''
|
|
|
|
e = binascii.b2a_base64(t)
|
|
|
|
if e:
|
|
|
|
oup = oup + e[:-1]
|
|
|
|
return oup
|
|
|
|
|
|
|
|
def decode(self, inp):
|
|
|
|
if not inp:
|
|
|
|
return ''
|
|
|
|
return binascii.a2b_base64(inp)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
class _IdleCont(object):
|
|
|
|
|
|
|
|
"""When process is called, server is in IDLE state
|
|
|
|
and will send asynchronous changes."""
|
|
|
|
|
|
|
|
def __init__(self, parent, timeout):
|
|
|
|
self.parent = parent
|
2011-06-09 15:26:14 +02:00
|
|
|
self.timeout = parent._choose_nonull_or_dflt(IDLE_TIMEOUT, timeout)
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
self.parent.idle_timeout = self.timeout + time.time()
|
|
|
|
|
|
|
|
def process(self, data, rqb):
|
2011-06-09 15:26:14 +02:00
|
|
|
self.parent.idle_lock.acquire()
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
self.parent.idle_rqb = rqb
|
|
|
|
self.parent.idle_timeout = self.timeout + time.time()
|
2011-06-09 15:26:14 +02:00
|
|
|
self.parent.idle_lock.release()
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
if __debug__: self.parent._log(2, 'server IDLE started, timeout in %.2f secs' % self.timeout)
|
|
|
|
return None
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-04-11 17:24:44 +02:00
|
|
|
MonthNames = [None, 'Jan', 'Feb', 'Mar', 'Apr', 'May', 'Jun',
|
|
|
|
'Jul', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec']
|
|
|
|
|
2016-06-03 12:06:10 +02:00
|
|
|
Mon2num = dict(list(zip((x for x in MonthNames[1:]), list(range(1, 13)))))
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
InternalDate = re.compile(r'.*INTERNALDATE "'
|
|
|
|
r'(?P<day>[ 0123][0-9])-(?P<mon>[A-Z][a-z][a-z])-(?P<year>[0-9][0-9][0-9][0-9])'
|
|
|
|
r' (?P<hour>[0-9][0-9]):(?P<min>[0-9][0-9]):(?P<sec>[0-9][0-9])'
|
|
|
|
r' (?P<zonen>[-+])(?P<zoneh>[0-9][0-9])(?P<zonem>[0-9][0-9])'
|
|
|
|
r'"')
|
|
|
|
|
|
|
|
|
|
|
|
def Internaldate2Time(resp):
|
|
|
|
|
|
|
|
"""time_tuple = Internaldate2Time(resp)
|
|
|
|
Convert IMAP4 INTERNALDATE to UT."""
|
|
|
|
|
|
|
|
mo = InternalDate.match(resp)
|
|
|
|
if not mo:
|
|
|
|
return None
|
|
|
|
|
|
|
|
mon = Mon2num[mo.group('mon')]
|
|
|
|
zonen = mo.group('zonen')
|
|
|
|
|
|
|
|
day = int(mo.group('day'))
|
|
|
|
year = int(mo.group('year'))
|
|
|
|
hour = int(mo.group('hour'))
|
|
|
|
min = int(mo.group('min'))
|
|
|
|
sec = int(mo.group('sec'))
|
|
|
|
zoneh = int(mo.group('zoneh'))
|
|
|
|
zonem = int(mo.group('zonem'))
|
|
|
|
|
|
|
|
# INTERNALDATE timezone must be subtracted to get UT
|
|
|
|
|
|
|
|
zone = (zoneh*60 + zonem)*60
|
|
|
|
if zonen == '-':
|
|
|
|
zone = -zone
|
|
|
|
|
|
|
|
tt = (year, mon, day, hour, min, sec, -1, -1, -1)
|
|
|
|
|
|
|
|
utc = time.mktime(tt)
|
|
|
|
|
|
|
|
# Following is necessary because the time module has no 'mkgmtime'.
|
|
|
|
# 'mktime' assumes arg in local timezone, so adds timezone/altzone.
|
|
|
|
|
|
|
|
lt = time.localtime(utc)
|
|
|
|
if time.daylight and lt[-1]:
|
|
|
|
zone = zone + time.altzone
|
|
|
|
else:
|
|
|
|
zone = zone + time.timezone
|
|
|
|
|
|
|
|
return time.localtime(utc - zone)
|
|
|
|
|
|
|
|
Internaldate2tuple = Internaldate2Time # (Backward compatible)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
def Time2Internaldate(date_time):
|
|
|
|
|
|
|
|
"""'"DD-Mmm-YYYY HH:MM:SS +HHMM"' = Time2Internaldate(date_time)
|
|
|
|
Convert 'date_time' to IMAP4 INTERNALDATE representation."""
|
|
|
|
|
|
|
|
if isinstance(date_time, (int, float)):
|
|
|
|
tt = time.localtime(date_time)
|
|
|
|
elif isinstance(date_time, (tuple, time.struct_time)):
|
|
|
|
tt = date_time
|
|
|
|
elif isinstance(date_time, str) and (date_time[0],date_time[-1]) == ('"','"'):
|
|
|
|
return date_time # Assume in correct format
|
|
|
|
else:
|
|
|
|
raise ValueError("date_time not of a known type")
|
|
|
|
|
|
|
|
if time.daylight and tt[-1]:
|
|
|
|
zone = -time.altzone
|
|
|
|
else:
|
|
|
|
zone = -time.timezone
|
2011-04-11 17:24:44 +02:00
|
|
|
return ('"%2d-%s-%04d %02d:%02d:%02d %+03d%02d"' %
|
|
|
|
((tt[2], MonthNames[tt[1]], tt[0]) + tt[3:6] +
|
|
|
|
divmod(zone//60, 60)))
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FLAGS_cre = re.compile(r'.*FLAGS \((?P<flags>[^\)]*)\)')
|
|
|
|
|
|
|
|
def ParseFlags(resp):
|
|
|
|
|
|
|
|
"""('flag', ...) = ParseFlags(line)
|
|
|
|
Convert IMAP4 flags response to python tuple."""
|
|
|
|
|
|
|
|
mo = FLAGS_cre.match(resp)
|
|
|
|
if not mo:
|
|
|
|
return ()
|
|
|
|
|
|
|
|
return tuple(mo.group('flags').split())
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
if __name__ == '__main__':
|
|
|
|
|
|
|
|
# To test: invoke either as 'python imaplib2.py [IMAP4_server_hostname]',
|
|
|
|
# or as 'python imaplib2.py -s "rsh IMAP4_server_hostname exec /etc/rimapd"'
|
2015-09-14 14:56:17 +02:00
|
|
|
# or as 'python imaplib2.py -l keyfile[:certfile]|: [IMAP4_SSL_server_hostname]'
|
|
|
|
#
|
|
|
|
# Option "-d <level>" turns on debugging (use "-d 5" for everything)
|
2013-09-02 07:08:50 +02:00
|
|
|
# Option "-i" tests that IDLE is interruptible
|
2015-09-14 14:56:17 +02:00
|
|
|
# Option "-p <port>" allows alternate ports
|
|
|
|
|
|
|
|
if not __debug__:
|
|
|
|
raise ValueError('Please run without -O')
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
import getopt, getpass
|
|
|
|
|
|
|
|
try:
|
2013-09-02 07:08:50 +02:00
|
|
|
optlist, args = getopt.getopt(sys.argv[1:], 'd:il:s:p:')
|
2015-03-18 21:54:36 +01:00
|
|
|
except getopt.error as val:
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
optlist, args = (), ()
|
|
|
|
|
2013-09-02 07:08:50 +02:00
|
|
|
debug, debug_buf_lvl, port, stream_command, keyfile, certfile, idle_intr = (None,)*7
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
for opt,val in optlist:
|
|
|
|
if opt == '-d':
|
|
|
|
debug = int(val)
|
2011-06-09 15:26:14 +02:00
|
|
|
debug_buf_lvl = debug - 1
|
2013-09-02 07:08:50 +02:00
|
|
|
elif opt == '-i':
|
|
|
|
idle_intr = 1
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
elif opt == '-l':
|
|
|
|
try:
|
|
|
|
keyfile,certfile = val.split(':')
|
|
|
|
except ValueError:
|
|
|
|
keyfile,certfile = val,val
|
|
|
|
elif opt == '-p':
|
|
|
|
port = int(val)
|
|
|
|
elif opt == '-s':
|
|
|
|
stream_command = val
|
|
|
|
if not args: args = (stream_command,)
|
|
|
|
|
|
|
|
if not args: args = ('',)
|
|
|
|
if not port: port = (keyfile is not None) and IMAP4_SSL_PORT or IMAP4_PORT
|
|
|
|
|
|
|
|
host = args[0]
|
|
|
|
|
|
|
|
USER = getpass.getuser()
|
|
|
|
|
|
|
|
data = open(os.path.exists("test.data") and "test.data" or __file__).read(1000)
|
|
|
|
test_mesg = 'From: %(user)s@localhost%(lf)sSubject: IMAP4 test%(lf)s%(lf)s%(data)s' \
|
|
|
|
% {'user':USER, 'lf':'\n', 'data':data}
|
2011-11-02 10:55:42 +01:00
|
|
|
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
test_seq1 = [
|
2015-03-18 21:54:36 +01:00
|
|
|
('list', ('""', '""')),
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
('list', ('""', '%')),
|
2015-03-18 21:54:36 +01:00
|
|
|
('create', ('imaplib2_test0',)),
|
|
|
|
('rename', ('imaplib2_test0', 'imaplib2_test1')),
|
|
|
|
('CREATE', ('imaplib2_test2',)),
|
|
|
|
('append', ('imaplib2_test2', None, None, test_mesg)),
|
|
|
|
('list', ('', 'imaplib2_test%')),
|
|
|
|
('select', ('imaplib2_test2',)),
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
('search', (None, 'SUBJECT', 'IMAP4 test')),
|
2011-08-15 11:55:41 +02:00
|
|
|
('fetch', ("'1:*'", '(FLAGS INTERNALDATE RFC822)')),
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
('store', ('1', 'FLAGS', '(\Deleted)')),
|
|
|
|
('namespace', ()),
|
|
|
|
('expunge', ()),
|
|
|
|
('recent', ()),
|
|
|
|
('close', ()),
|
|
|
|
]
|
|
|
|
|
|
|
|
test_seq2 = (
|
|
|
|
('select', ()),
|
2011-11-02 10:55:42 +01:00
|
|
|
('response', ('UIDVALIDITY',)),
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
('response', ('EXISTS',)),
|
|
|
|
('append', (None, None, None, test_mesg)),
|
2015-03-18 21:54:36 +01:00
|
|
|
('examine', ()),
|
|
|
|
('select', ()),
|
2015-03-20 11:02:17 +01:00
|
|
|
('fetch', ("'1:*'", '(FLAGS UID)')),
|
2015-03-18 21:54:36 +01:00
|
|
|
('examine', ()),
|
|
|
|
('select', ()),
|
2015-03-25 13:39:13 +01:00
|
|
|
('uid', ('SEARCH', 'SUBJECT', 'IMAP4 test')),
|
|
|
|
('uid', ('SEARCH', 'ALL')),
|
|
|
|
('uid', ('THREAD', 'references', 'UTF-8', '(SEEN)')),
|
|
|
|
('recent', ()),
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
)
|
|
|
|
|
2011-11-02 10:55:42 +01:00
|
|
|
|
2015-09-14 14:56:17 +02:00
|
|
|
AsyncError, M = None, None
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
2015-03-18 21:54:36 +01:00
|
|
|
def responder(cb_arg_list):
|
2015-09-14 14:56:17 +02:00
|
|
|
response, cb_arg, error = cb_arg_list
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
global AsyncError
|
|
|
|
cmd, args = cb_arg
|
|
|
|
if error is not None:
|
|
|
|
AsyncError = error
|
2011-06-09 15:26:14 +02:00
|
|
|
M._log(0, '[cb] ERROR %s %.100s => %s' % (cmd, args, error))
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
return
|
|
|
|
typ, dat = response
|
2011-06-09 15:26:14 +02:00
|
|
|
M._log(0, '[cb] %s %.100s => %s %.100s' % (cmd, args, typ, dat))
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
if typ == 'NO':
|
|
|
|
AsyncError = (Exception, dat[0])
|
|
|
|
|
|
|
|
def run(cmd, args, cb=True):
|
|
|
|
if AsyncError:
|
2015-03-25 13:39:13 +01:00
|
|
|
M._log(1, 'AsyncError %s' % repr(AsyncError))
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
M.logout()
|
|
|
|
typ, val = AsyncError
|
|
|
|
raise typ(val)
|
2011-06-09 15:26:14 +02:00
|
|
|
if not M.debug: M._log(0, '%s %.100s' % (cmd, args))
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
try:
|
|
|
|
if cb:
|
|
|
|
typ, dat = getattr(M, cmd)(callback=responder, cb_arg=(cmd, args), *args)
|
2011-06-09 15:26:14 +02:00
|
|
|
M._log(1, '%s %.100s => %s %.100s' % (cmd, args, typ, dat))
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
else:
|
|
|
|
typ, dat = getattr(M, cmd)(*args)
|
2011-06-09 15:26:14 +02:00
|
|
|
M._log(1, '%s %.100s => %s %.100s' % (cmd, args, typ, dat))
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
except:
|
2011-06-09 15:26:14 +02:00
|
|
|
M._log(1, '%s - %s' % sys.exc_info()[:2])
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
M.logout()
|
|
|
|
raise
|
|
|
|
if typ == 'NO':
|
2011-06-09 15:26:14 +02:00
|
|
|
M._log(1, 'NO')
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
M.logout()
|
|
|
|
raise Exception(dat[0])
|
|
|
|
return dat
|
|
|
|
|
|
|
|
try:
|
|
|
|
threading.currentThread().setName('main')
|
|
|
|
|
|
|
|
if keyfile is not None:
|
|
|
|
if not keyfile: keyfile = None
|
|
|
|
if not certfile: certfile = None
|
2015-09-30 13:29:59 +02:00
|
|
|
M = IMAP4_SSL(host=host, port=port, keyfile=keyfile, certfile=certfile, ssl_version="tls1", debug=debug, identifier='', timeout=10, debug_buf_lvl=debug_buf_lvl, tls_level="tls_no_ssl")
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
elif stream_command:
|
2011-06-09 15:26:14 +02:00
|
|
|
M = IMAP4_stream(stream_command, debug=debug, identifier='', timeout=10, debug_buf_lvl=debug_buf_lvl)
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
else:
|
2011-06-09 15:26:14 +02:00
|
|
|
M = IMAP4(host=host, port=port, debug=debug, identifier='', timeout=10, debug_buf_lvl=debug_buf_lvl)
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
if M.state != 'AUTH': # Login needed
|
|
|
|
PASSWD = getpass.getpass("IMAP password for %s on %s: " % (USER, host or "localhost"))
|
|
|
|
test_seq1.insert(0, ('login', (USER, PASSWD)))
|
2011-06-09 15:26:14 +02:00
|
|
|
M._log(0, 'PROTOCOL_VERSION = %s' % M.PROTOCOL_VERSION)
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
if 'COMPRESS=DEFLATE' in M.capabilities:
|
|
|
|
M.enable_compression()
|
|
|
|
|
|
|
|
for cmd,args in test_seq1:
|
|
|
|
run(cmd, args)
|
|
|
|
|
2015-03-18 21:54:36 +01:00
|
|
|
for ml in run('list', ('', 'imaplib2_test%'), cb=False):
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
mo = re.match(r'.*"([^"]+)"$', ml)
|
|
|
|
if mo: path = mo.group(1)
|
|
|
|
else: path = ml.split()[-1]
|
|
|
|
run('delete', (path,))
|
|
|
|
|
2011-08-15 11:55:41 +02:00
|
|
|
if 'ID' in M.capabilities:
|
|
|
|
run('id', ())
|
2015-03-18 21:54:36 +01:00
|
|
|
run('id', ("(name imaplib2)",))
|
2011-08-15 11:55:41 +02:00
|
|
|
run('id', ("version", __version__, "os", os.uname()[0]))
|
2013-09-02 07:08:50 +02:00
|
|
|
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
for cmd,args in test_seq2:
|
|
|
|
if (cmd,args) != ('uid', ('SEARCH', 'SUBJECT', 'IMAP4 test')):
|
|
|
|
run(cmd, args)
|
|
|
|
continue
|
|
|
|
|
|
|
|
dat = run(cmd, args, cb=False)
|
|
|
|
uid = dat[-1].split()
|
|
|
|
if not uid: continue
|
|
|
|
run('uid', ('FETCH', uid[-1],
|
|
|
|
'(FLAGS INTERNALDATE RFC822.SIZE RFC822.HEADER RFC822.TEXT)'))
|
|
|
|
run('uid', ('STORE', uid[-1], 'FLAGS', '(\Deleted)'))
|
|
|
|
run('expunge', ())
|
|
|
|
|
|
|
|
if 'IDLE' in M.capabilities:
|
|
|
|
run('idle', (2,), cb=False)
|
2011-11-02 10:55:42 +01:00
|
|
|
run('idle', (99,)) # Asynchronous, to test interruption of 'idle' by 'noop'
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
time.sleep(1)
|
|
|
|
run('noop', (), cb=False)
|
|
|
|
|
2011-11-02 10:55:42 +01:00
|
|
|
run('append', (None, None, None, test_mesg), cb=False)
|
|
|
|
num = run('search', (None, 'ALL'), cb=False)[0].split()[0]
|
|
|
|
dat = run('fetch', (num, '(FLAGS INTERNALDATE RFC822)'), cb=False)
|
2014-10-10 14:13:16 +02:00
|
|
|
M._mesg('fetch %s => %s' % (num, repr(dat)))
|
2011-11-02 10:55:42 +01:00
|
|
|
run('idle', (2,))
|
|
|
|
run('store', (num, '-FLAGS', '(\Seen)'), cb=False),
|
|
|
|
dat = run('fetch', (num, '(FLAGS INTERNALDATE RFC822)'), cb=False)
|
2014-10-10 14:13:16 +02:00
|
|
|
M._mesg('fetch %s => %s' % (num, repr(dat)))
|
2011-11-02 10:55:42 +01:00
|
|
|
run('uid', ('STORE', num, 'FLAGS', '(\Deleted)'))
|
|
|
|
run('expunge', ())
|
2013-09-02 07:08:50 +02:00
|
|
|
if idle_intr:
|
|
|
|
M._mesg('HIT CTRL-C to interrupt IDLE')
|
|
|
|
try:
|
|
|
|
run('idle', (99,), cb=False) # Synchronous, to test interruption of 'idle' by INTR
|
|
|
|
except KeyboardInterrupt:
|
|
|
|
M._mesg('Thanks!')
|
|
|
|
M._mesg('')
|
|
|
|
raise
|
|
|
|
elif idle_intr:
|
|
|
|
M._mesg('chosen server does not report IDLE capability')
|
2011-11-02 10:55:42 +01:00
|
|
|
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
run('logout', (), cb=False)
|
|
|
|
|
|
|
|
if debug:
|
|
|
|
M._mesg('')
|
|
|
|
M._print_log()
|
|
|
|
M._mesg('')
|
|
|
|
M._mesg('unused untagged responses in order, most recent last:')
|
|
|
|
for typ,dat in M.pop_untagged_responses(): M._mesg('\t%s %s' % (typ, dat))
|
|
|
|
|
2015-03-18 21:54:36 +01:00
|
|
|
print('All tests OK.')
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
|
|
|
except:
|
2015-09-14 14:56:17 +02:00
|
|
|
if not idle_intr or M is None or not 'IDLE' in M.capabilities:
|
2015-03-18 21:54:36 +01:00
|
|
|
print('Tests failed.')
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
2013-09-02 07:08:50 +02:00
|
|
|
if not debug:
|
2015-03-18 21:54:36 +01:00
|
|
|
print('''
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
If you would like to see debugging output,
|
|
|
|
try: %s -d5
|
2015-03-18 21:54:36 +01:00
|
|
|
''' % sys.argv[0])
|
Import newest version of imaplib2
This change does not do anything yet with imaplib2, merely makes it
available for future commits.
This file is identical to the one at
http://sydney.edu.au/engineering/it/~piers/python/imaplib2 .
imaplib2, written by the same guy who wrote imaplib, is very different
from imaplib itself. Calling it a modified version from the standard
distribution is misleading. It's more like a complete rewrite. As
such, it's not really possible to summarize what was changed.
The largest thing is that imaplib2 is "threaded". Instead of doing
blocking writes/reads on the socket during/after every command,
imaplib2 forks off threads to read and write to the socket based on
input and output buffers. This opens the door to asynchronous
commands (every command is potentially asynchronous, according to the
docs), and in particular IDLE, which is by definition an asynchronous
command.
The author writes: "imaplib2 can be substituted for imaplib in
existing clients with no changes in the code", but that's pretty
misleading. It might be true for certain simple users of imaplib, but
for us it's completely false. Among other things, how untagged
responses are stored in-memory is different -- instead of a hash
table, it's a list. I'm guessing this is to preserve order of
responses.
I think there are other miscellaneous improvements, like I think
imaplib2 is IPv6 safe out-of-the-box, but I haven't conducted an
extremely thorough examination of the differences :)
Signed-off-by: Ethan Glasser-Camp <ethan@betacantrips.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
2011-03-08 16:05:15 +01:00
|
|
|
|
2013-09-02 07:08:50 +02:00
|
|
|
raise
|