[issue40359] email.parse part.get_filename() fails to unwrap long attachment file names
Matthew Davis added the comment: Ah woops, I mistyped the relevant ticket. It's issue 36401 https://bugs.python.org/issue36041 -- ___ Python tracker <https://bugs.python.org/issue40359> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40359] email.parse part.get_filename() fails to unwrap long attachment file names
New submission from Matthew Davis :
# Summary
When parsing emails with long attachment file names, part.get_filename() often
returns \n or \r\n.
It should strip those characters out.
# Steps to reproduce
I have attached a minimal working example.
The relevant part of the raw email is:
--_004_D6CEDE1EBD6645898F5643C0C6878005examplecom_
Content-Type: text/plain;
name="an attachment with a very very very long super long file name
which has
many words and just keeps on going and going.txt"
# Expected output:
attachments = ["an attachment with a very very very long super long file name
which has many words and just keeps on going and going.txt"]
Maybe I'm reading the email RFC spec wrong. My interpretation is that the
parser should do something like:
raw = raw.replace('\r\n ', ' ').replace('\n ', ' ')
# Actual output
attachments = ["an attachment with a very very very long super long file name
which\n has many words and just keeps on going and going.txt"]
Note that I have seen other examples where the output includes \r\n not just \n
# Impact
I'm trying to write an email bot which saves attachments to a database, and
also forwards on the emails.
My both thinks that the filename includes a line break. This inevitably causes
failures in my subsequent code.
# Relevant links:
The RFC for email spec is here:
https://tools.ietf.org/html/rfc2822.html#section-2.2.3
This Stack Overflow answer seems relevant:
https://stackoverflow.com/questions/3050298/parsing-email-with-python/3050374#3050374
Issue 3601 may be relevant, but doesn't seem exactly the same. It seems to be
the reverse, *constructing* emails with long headers. My issue is *parsing*
emails with long headers.
--
components: email
files: mwe.py
messages: 366963
nosy: barry, matt-davis, r.david.murray
priority: normal
severity: normal
status: open
title: email.parse part.get_filename() fails to unwrap long attachment file
names
versions: Python 3.6
Added file: https://bugs.python.org/file49083/mwe.py
___
Python tracker
<https://bugs.python.org/issue40359>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40359] email.parse part.get_filename() fails to unwrap long attachment file names
Matthew Davis added the comment: 36041 -- ___ Python tracker <https://bugs.python.org/issue40359> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40359] email.parse part.get_filename() fails to unwrap long attachment file names (legacy API)
Matthew Davis added the comment: Ah, yes that workaround works. Thanks! So what's the exact status of this policy? It's called the default policy, but it's not used by default? If I download the latest version of python, will this be parsed correctly without explicitly setting the policy? i.e. Is this still something that should be changed in the code? (Yes, I already use message_from_bytes in my real application. I just used message_from_string in the MWE, because I could only attach one file in this web page, so I embedded the email body as a string in the script.) -- ___ Python tracker <https://bugs.python.org/issue40359> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41788] enhancement: add assertDuration context manager to unittest module
New submission from Matthew Davis : # Summary I propose an additional unit test type for the unittest module. TestCase.assertDuration(min=None, max=None), which is a context manager, similar to assertRaises. It runs the code inside it, and then fails the test if the duration of the code inside was not between min and max. # Use case I want to check that when I call a certain function in my application, it doesn't take far more time than I expect, or far less time. e.g. if I'm trying to do things concurrently, I want to test that they are indeed concurrent, by measuring whether the duration equals the sum of all processes' duration, or the max. # MWE ``` import unittest from time import sleep, time from multiprocessing import Pool def slow(x): sleep(x) # blocking sleep for 0, 1, 2, 3 seconds, concurrently def together(): with Pool(4) as p: p.map(slow, range(4)) class TestConcurrent(unittest.TestCase): # this is how you do it today def test_today(self): start = time() together() end = time() duration = end - start self.assertGreaterEqual(duration, 2) # max should be 3 seconds, plus some overhead # if together() called slow() in series, # total duration would be 0 + 1 + 2 + 3 = 6 > 4 self.assertLessEqual(duration, 4) # this is how I want to do it def test_simpler(self): with self.assertDuration(min=2, max=4): together() ``` # Solution I just need to add a new context manager next to this one: https://github.com/python/cpython/blob/6b34d7b51e33fcb21b8827d927474ce9ed1f605c/Lib/unittest/case.py#L207 -- components: Library (Lib) messages: 376923 nosy: matt-davis priority: normal severity: normal status: open title: enhancement: add assertDuration context manager to unittest module ___ Python tracker <https://bugs.python.org/issue41788> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29056] logging.Formatter doesn't respect more than one formatException()
Matthew Davis added the comment: The documentation says "you will have to clear the cached value" What does that mean? How do I clear the cached value? Is there a flush function somewhere? Do I `del` the attribute? Set the attribute to None? The documentation as it stands today does not provide enough detail about this workaround. -- nosy: +matt-davis ___ Python tracker <https://bugs.python.org/issue29056> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42369] Reading ZipFile not thread-safe
Matthew Davis added the comment: In addition to fixing any unexpected behavior, can we update the documentation [1] to state what the expected behavior is in terms of thread safety? [1] https://docs.python.org/3/library/zipfile.html -- nosy: +mdavis-xyz ___ Python tracker <https://bugs.python.org/issue42369> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
