New submission from era :
Several of the examples in the email module documentation modify the preamble.
This is not good practice. The email MIME preamble is really only useful for
communicating information about MIME itself, not for general human-readable
content like 'Our family reunion
era added the comment:
I don't think this is a bug. My impression is that encoded words should be
decodable in isolation.
--
nosy: +era
___
Python tracker
<https://bugs.python.org/issue35
era added the comment:
https://bugs.python.org/issue34460 now requests the addition of "cp-850" and
"windows-784" as charset aliases in the email.charset module.
--
___
Python tracker
<https://bug
New submission from era :
The email.charset module should contain common informal character-set
identifiers even if they are not formally specified in a IANA RFC.
>From a quick grep of a pile of recent email, I find the following:
46 "cp-850"
6 "windows-874&quo
New submission from era :
https://github.com/python/cpython/blob/3.7/Lib/email/contentmanager.py#L64
currently contains the following code:
def get_text_content(msg, errors='replace'):
content = msg.get_payload(decode=True)
charset = msg.get_param('charset', 'ASCII
era added the comment:
Closing the entire enhancement request just because one detail is off seems
insane.
Anyway, until the day in the distant future when Python can support encoding
names in common circulation, http://stackoverflow.com/a/1064191/874188 offers a
crude workaround.
import
era added the comment:
#28577 requests a similar special case for /32
--
nosy: +era
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
era added the comment:
Quick googling did not turn up anything like a credible authoritative reference
for this, but in actual practice, I have seen /32 used to designate a single
individual IP address in CIDR notation quite a lot.
I can see roughly three options:
1. Status quo. Silently
era added the comment:
@xiang.zhang thanks for the quick reply.
I find this behavior surprising. If I process a list of addresses, like
ips = (
'10.9.8.7/32'
'10.11.12.8/28'
)
for test in ['10.9.8.7', '10.11.12.10']:
if test in [str(y) for x in ips for y
era added the comment:
(Meh, silly typo, of course the expected output is ['10.9.8.7'], sorry about
that!)
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
New submission from era:
I would expect the following code to return ['10.9.8.8'] but it returns an
empty list.
yosemite-osx$ python3
Python 3.5.1 (default, Dec 26 2015, 18:08:53)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)] on darwin
Type "help",
era added the comment:
The double quotes around the "human readable" part of the email address are not
allowed. Python is handling this correctly.
--
nosy: +era
___
Python tracker <rep...@bugs.python.org>
<http://bugs.py
era added the comment:
The call to .setpassword() doesn't seem to make any difference. I was hoping
it would offer a workaround, but it didn't.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24430
New submission from era:
The attached archive from the Windows version of the 7z file manager (7zFM
version 9.20) cannot be decrypted into memory. The first file succeeds, but
the second one fails.
The following small program is able to unzip other encrypted zip archives
(tried one created
Changes by era era+pyt...@iki.fi:
--
components: +Library (Lib)
title: ZipFile.read() cannot decrypt multiple members from Windows 7zfm -
ZipFile.read() cannot decrypt multiple members from Windows 7zFM
type: - behavior
___
Python tracker rep
Changes by era era+pyt...@iki.fi:
--
nosy: +era
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17254
___
___
Python-bugs-list mailing list
New submission from era:
I created a simple script to map character codes in the 8bit range to Unicode
for simple lookup:
https://github.com/tripleee/8bit
In the generated output, on Python 2.6.6 (but corroborated on Python 2.7.6),
almost all character codes come up as undefined in CP874
era added the comment:
My apologies -- I already attemptd to close this as a mistake on my part, but
apparently, that failed too. )-: Sorry.
--
resolution: - not a bug
status: open - closed
___
Python tracker rep...@bugs.python.org
http
era added the comment:
For those who cannot update just yet, see also the workaround at
http://stackoverflow.com/a/21996397/874188
--
nosy: +era
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1757072
era added the comment:
At least the following existing domain names are rejected by the current
implementation, apparently because they are not IDNA2003-compatible.
XNNNC9BXA1KSA.COM
XN--14-CUD4D3A.COM
XN--YGB4AR5HPA.COM
XN---14-00E9E9A.COM
XN--MGB2DAM4BK.COM
XN--6-ZHCPPA1B7A.COM
XN--3
20 matches
Mail list logo
