You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Given a folder name that could be considered a number, ImapClient will mangle that folder name in the case of leading zeroes.
For example: if I create a folder 012345, and execute a list_folders, ImapClient will return 12345.
The cause can be traced down to the atom function in response_parser.py. That function will check if a token in the response is a digit, and then cast the token to an int. When the int is later cast back to a str (in _proc_folder_list in imapclient.py), the leading zero has already been removed.
I'd be happy to provide a pull request for this bug, but since the atom function is a general-purpose function, I'm not sure what the best course of action is. Changing that behavior will likely have side effects on other parts of the code that do expect ints being returned.
The text was updated successfully, but these errors were encountered:
Ouch, good catch! I bet you could also see incorrect behaviour if a folder was called NIL :)
I think the right approach is to have a specialised function for handling folder list responses which doesn't use atom and just assumes everything is strings. It could still use TokenSource to generate tokens.
Does that sound reasonable? Are you prepared to have a go at the change?
Hi all,
Given a folder name that could be considered a number, ImapClient will mangle that folder name in the case of leading zeroes.
For example: if I create a folder
012345
, and execute alist_folders
, ImapClient will return12345
.The cause can be traced down to the
atom
function inresponse_parser.py
. That function will check if a token in the response is a digit, and then cast the token to anint
. When theint
is later cast back to astr
(in_proc_folder_list
inimapclient.py
), the leading zero has already been removed.I'd be happy to provide a pull request for this bug, but since the
atom
function is a general-purpose function, I'm not sure what the best course of action is. Changing that behavior will likely have side effects on other parts of the code that do expectint
s being returned.The text was updated successfully, but these errors were encountered: