Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork32.1k
gh-134151 Fix TypeError in email.utils.decode_params() when sorting RFC 2231 continuations on Python 3#134687
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
base:main
Are you sure you want to change the base?
Uh oh!
There was an error while loading.Please reload this page.
Conversation
…ntinuations on Python 3 and add corresponding test case
| ) | ||
| filename = msg.get_filename() | ||
| self.assertEqual(filename, 'foo bar.txtignored') | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
In the new API this case is treated as two separate occurrences of the parameter 'filename', and I chose to ignore the one that didn't have a section number if there was already a section 0. I suspect that was because it seemed like the more complex attribute was more likely to be accurate, but I don't really remember. If you are doing it the way you are to replicate 2.7 behavior, then it is fine as is. Otherwise replicating the new API logic would probably be better (treat None as 0 if there is no 0, ignore it if there is already a 0). Unless you have an RFC or standard practice (what do other email clients do?) reason for a different behavior, in which case I could consider changing the new API logic.
Also, the error messages are clearer if you do assertEqual(expected, actual) (the diff is clearer).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Resolved, I believe that aligning the new API behaviour makes sense. I have updated my logic and added more test cases for two different scenarios. Thanks!
…d update tests for continuation sorting
Uh oh!
There was an error while loading.Please reload this page.
TypeError: '<' not supported between instances of 'NoneType' and 'int'raised during call toemail.message_from_file#134151