-
-
Notifications
You must be signed in to change notification settings - Fork 30.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement RFC 6855 (IMAP Support for UTF-8) in imaplib. #65999
Comments
I made a patch implementing the following changes to the IMAP4 class:
Does this look like a good idea to you? (I'll make a patch including docs when we agree on the API.) |
The patch contains changes to code and tests have been added so can we have a formal review please. |
Here is an updated patch based on Milan's work, including docs. I've tweaked the API slightly: no dedicated method for doing the enable (instead it is inlined in authenticate), I added 'enable' to the exposed API (with a doc caveat about not using it for UTF8=ACCEPT), added None as a valid value for enable_UTF8 with the meaning "enable if possible" (True is now "must enable"), and exposed a utf8_enabled attribute so the program can easily tell what mode to use when specifying enable_UTF8=None. Someday, None should become the default. "None" is not the best choice for value, especially when it is not the default, so perhaps someone could suggest better values for that keyword. It would be great if Milan or Maciej could give me a review (or anyone else who feels like it). I want to get this in before the beta deadline. |
David I did the review and there's one thing that worries me the most, actually two:
|
Well, the problem with that is that we then have to parse the capability to see if it is utf8 that is being enabled. I don't like that as an API, it feels fragile. Since capabilities cannot later be disabled, there's no functional reason to keep it separate. However, it would solve the problem of values to use in the init flag, and would remove the caveat that you shouldn't use UTF8=ENABLE in an explicit enable call, so perhaps it is best after all. Do you have any interest in updating the patch? I won't be able to get back to it until this weekend. |
Yes, I can update that (that IMAP testing bug - http://bugs.python.org/issue22137, is taking me longer than I expected it ;)). |
An explicit call to enable with an argument string that contains 'UTF8=ACCEPT'. I did not go far enough through the BNF to determine if enable can be passed more than one capability at a time, but I suspect it can. In which case we should factor out the capability parsing such that we can reuse it for parsing the enable argument. |
David, I've changed according to your suggestion, appreciate review. |
New changeset 195343b5e64f by R David Murray in branch 'default': |
Thanks, Maciek (and Milan). I tweaked your patch slightly (mostly doc changes...I moved the discussion of the utf8 RFC into the enable method only, and added back the docs for utf8_enabled). I made some review comments about the changes other than that doc reorg that I made before commit, just FYI. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: