[issue27445] Charset instance not passed to set_payload()
Claude Paroz added the comment: Thanks for pushing the patch! -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27445> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27445] Charset instance not passed to set_payload()
Changes by Claude Paroz <cla...@2xlibre.net>: -- keywords: +patch Added file: http://bugs.python.org/file43614/issue27445.diff ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27445> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27445] Charset instance not passed to set_payload()
New submission from Claude Paroz: In issue #16324, I contributed an improvement so as MIMEText __init__ accept Charset instances, not only encoding strings. The use case is from Django where we customize the Charset.body_encoding before passing it to the MIMEText initialization. Unfortunately, what I didn't notice when Berker adapted my patch is that the Charset is casted to its string representation for the whole method, while I initially intended to let the unchanged Charset passed to self.set_payload. And the test I suggested was not smart enough to detect that. -- components: email messages: 269740 nosy: barry, claudep, r.david.murray priority: normal severity: normal status: open title: Charset instance not passed to set_payload() versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27445> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16679] Wrong URL path decoding
Claude Paroz added the comment: Thanks for the explanations (and history). I realize that changing the behaviour is probably not an option. As an example in a framework, we are currently discussing how we will cope with this in Django: https://code.djangoproject.com/ticket/19468 On the Python side, it might be worth adding an admonition about PATH_INFO and non-ascii URLs on the wsgiref docs. -- assignee: - docs@python components: +Documentation -Library (Lib) nosy: +docs@python ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16679 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16679] Wrong URL path decoding
New submission from Claude Paroz: In wsgiref/simple_server.py (WSGIRequestHandler.get_environ), Python 3 is currently populating the env['PATH_INFO'] variable by decoding the URL path, assuming it was encoded with 'iso-8859-1', which appears to be wrong, according to RFC 3986/3987. For example, if you request the path /سلام in any modern browser, PATH_INFO will contain /سÙاÙ. 'iso-8859-1' should be replaced by 'utf-8' for decoding. Note that this was introduced as part of the fix for http://bugs.python.org/issue10155 -- components: Library (Lib) messages: 177449 nosy: claudep priority: normal severity: normal status: open title: Wrong URL path decoding type: behavior versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16679 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16679] Wrong URL path decoding
Claude Paroz added the comment: Attached are my proposed changes. Also, I just came across http://bugs.python.org/issue3300, which finally led Python urllib.parse.quote to default to UTF-8 encoding, after a lengthy discussion. -- keywords: +patch Added file: http://bugs.python.org/file28308/issue16679-1.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16679 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16679] Wrong URL path decoding
Claude Paroz added the comment: I may understand your reasoning when you cannot make any assumptions about the encoding of a series of bytes. I think that the case of PATH_INFO is different, because it should comply with standards, and then you *can* make the assumption that the original path is 'utf-8'-encoded. So either leave the string undecoded, or decode it to what the standards say. It would put un unneccessary burden on WSGI apps to always require to encode-redecode this string. Wouldn't it be possible to amend PEP ? Hopefully we can get some other opinions about this issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16679 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16324] MIMEText __init__ does not support Charset instance
Changes by Claude Paroz cla...@2xlibre.net: -- keywords: +patch Added file: http://bugs.python.org/file27726/issue16324-1.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16324 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16324] MIMEText __init__ does not support Charset instance
New submission from Claude Paroz:
When initializing a MIMEText instance, it might be desirable to set the
_charset parameter to a real Charset instance, not only a charset identifier
(for example to pass a Charset with customized body_encoding). Unfortunately,
this is failing:
File .../django/core/mail/message.py, line 128, in __init__
MIMEText.__init__(self, text, subtype, charset)
File /usr/lib/python3.2/email/mime/text.py, line 29, in __init__
**{'charset': _charset})
File /usr/lib/python3.2/email/mime/base.py, line 25, in __init__
self.add_header('Content-Type', ctype, **_params)
File /usr/lib/python3.2/email/message.py, line 475, in add_header
parts.append(_formatparam(k.replace('_', '-'), v))
File /usr/lib/python3.2/email/message.py, line 67, in _formatparam
if value is not None and len(value) 0:
TypeError: object of type 'Charset' has no len()
It is possible to later call set_charset, but the payload is already encoded
(and 'Content-Transfer-Encoding' is set).
Did I miss anything?
--
components: email
messages: 173764
nosy: barry, claudep, r.david.murray
priority: normal
severity: normal
status: open
title: MIMEText __init__ does not support Charset instance
type: behavior
versions: Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16324
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16324] MIMEText __init__ does not support Charset instance
Claude Paroz added the comment:
It's fine for me to consider it as an enhancement. The fix might be as simple
as replacing **{'charset': _charset} by **{'charset': str(_charset)} in
MIMEText __init__.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16324
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
