[issue30681] email.utils.parsedate_to_datetime() should return None when date cannot be parsed
Change by Georges : -- nosy: +sim0n nosy_count: 4.0 -> 5.0 pull_requests: +21176 pull_request: https://github.com/python/cpython/pull/22090 ___ Python tracker <https://bugs.python.org/issue30681> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30681] email.utils.parsedate_to_datetime() should return None when date cannot be parsed
Georges added the comment: As I think it is still important to have this fixed and considering the original PR was closed, I have created a new PR based on the original one while implementing the requested changes. https://github.com/python/cpython/pull/22090 -- versions: +Python 3.10, Python 3.9 ___ Python tracker <https://bugs.python.org/issue30681> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30681] email.utils.parsedate_to_datetime() should return None when date cannot be parsed
Georges added the comment: @barry Thank you for your input on the PR. >From what I understood this PR was nearly ready and only missing a small >addition to the documentation which I added. So it took me a bit to go through >it all :-). I actually don't see how *parsedate_to_datetime* would ever return None. It is *_parsedate_tz* which returns None on bogus input, in which case *parsedate_to_datetime* raises a TypeError. This is also covered in the tests, so those should be fine. In order to continue I suggest to fix the documentation on *parsedate_to_datetime*, remove the mention of it returning None and replacing it with it possibly returning TypeError in case of an invalid date input. Does that make sense ? Regarding the backporting, as a user of this I must admit that it would be much appreciated if this could be backported :-). -- ___ Python tracker <https://bugs.python.org/issue30681> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11316] RFC822 header parsing API inconsistencies between httplib.HTTPMessage and email.message.Message
New submission from Georges Martin : Both httplib.HTTPMessage and email.message.Message classes[1] implements methods for RFC822 headers parsing. Unfortunately, they have different implementations and they do not provide the same level of functionality. One example that is bugging me is that: * httplib.HTTPMessage is missing the get_filename method present in email.message.Message, that allows you to easily retrieve the filename from a 'Content-disposition: attachment; filename="fghi.xyz"' header; * httplib.HTTPMessage has getparam, getplist and parseplist methods but AFAIK, they are not and cannot be used outside of the 'content-type' header parsing; * email.message.Message has a generic get_param method to parse any RFC822 header with parameters, such as 'content-disposition' or 'content-type'. The workaround I'm using is to decorate an httplib.HTTPMessage with the missing methods from email.message.Message: def monkeypatch_http_message(obj): """ Decorate an httplib.HTTPMessage instance's class with the RFC822 header parameters parsing methods from email.message.Message. (thanks to ncoghlan) """ import httplib assert isinstance(obj, httplib.HTTPMessage) cls = obj.__class__ from email import utils from email.message import ( _parseparam, _unquotevalue, Message ) funcnames = ( '_get_params_preserve', 'get_params', 'get_param', 'get_filename' ) for funcname in funcnames: cls.__dict__[funcname] = Message.__dict__[funcname] So I can do: import mechanize from some.module import monkeypatch_http_message browser = mechanize.Browser() # in that form, browser.retrieve returns a temporary filename # and an httplib.HTTPMessage instance (tmp_filename, headers) = browser.retrieve(someurl) # monkeypatch the httplib.HTTPMessage instance monkeypatch_http_message(headers) # yeah... my original filename, finally filename = headers.get_filename() -- components: Library (Lib) messages: 129348 nosy: jrjsmrtn priority: normal severity: normal status: open title: RFC822 header parsing API inconsistencies between httplib.HTTPMessage and email.message.Message type: behavior versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue11316> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11316] RFC822 header parsing API inconsistencies between httplib.HTTPMessage and email.message.Message
Georges Martin added the comment: Hello, David. According to issue4773, httplib.HTTPMessage in Python 3.x is using email.message.Message underneath, so my issue is only with 2.6 (I've not checked 2.7). Georges -- ___ Python tracker <http://bugs.python.org/issue11316> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11316] RFC822 header parsing API inconsistencies between httplib.HTTPMessage and email.message.Message
Georges Martin added the comment: No problem. I thought important that the issue and a workaround were documented somehow... :-) -- ___ Python tracker <http://bugs.python.org/issue11316> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14455] plistlib unable to read json and binary plist files
Changes by Georges Martin : -- nosy: +jrjsmrtn ___ Python tracker <http://bugs.python.org/issue14455> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24875] pyvenv doesn´t install PIP inside a new venv with --system-site-package
Georges Racinet added the comment: Hi, I have the same symptoms and noticed by accident that you can somewhat workaround it by running pyvenv twice: pyvenv /path/to/env && pyvenv --system-site-packages /path/to/env The first provides pip, the second does not destroy it. At least this works on my Debian 8 installation -- nosy: +gracinet ___ Python tracker <http://bugs.python.org/issue24875> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
