[issue22525] ast.literal_eval() doesn't do what the documentation says

New submission from Behdad Esfahbod: The documentation says: Safely evaluate an expression node or a string containing a Python expression. The string or node provided may only consist of the following Python literal structures: strings, bytes, numbers, tuples, lists, dicts, sets, booleans

[issue22525] ast.literal_eval() doesn't do what the documentation says

Behdad Esfahbod added the comment: I think it should be made much more clear that this is not a blanket safe eval() replacement. Re complex literals, note that Python 2.7.x only implemented the binary plus operator if the second argument was complex. This seems to have been relaxed

[issue22525] ast.literal_eval() doesn't do what the documentation says

Behdad Esfahbod added the comment: Thanks. In your proposed text: + Safely evaluate an expression node or a string containing a Python literal or container display. I suggest changing it to ...containing a single Python literal or... Ie, adding single

[issue10733] plistlib rejects strings containing control characters

Behdad Esfahbod added the comment: Replacing all control characters by entities before trying to parse the Plist XML would likely be the best way forward. That wouldn't work. Control characters are disallowed in XML's character set, so they are invalid even if input as entities

[issue24040] plistlib assumes dict_type is descendent of dict

New submission from Behdad Esfahbod: Please replace instances of type({}) in plistlib.py with self._dict_type. -- components: Library (Lib) messages: 241875 nosy: Behdad.Esfahbod priority: normal severity: normal status: open title: plistlib assumes dict_type is descendent of dict

[issue11101] plistlib has no graceful way of handing None values

Behdad Esfahbod added the comment: plistlib's internal implementation already supports sort_keys and skipkeys, those just are not wired to load() and loads(). -- nosy: +Behdad.Esfahbod ___ Python tracker rep...@bugs.python.org http://bugs.python.org

[issue24041] Implement Mac East Asian encodings properly

New submission from Behdad Esfahbod: encodings.aliases has this in it's tail, even master today [0] # temporary mac CJK aliases, will be replaced by proper codecs in 3.1 'x_mac_japanese' : 'shift_jis', 'x_mac_korean': 'euc_kr', 'x_mac_simp_chinese' : 'gb2312

[issue24041] Implement Mac East Asian encodings properly

Behdad Esfahbod added the comment: Also, I'm not sure about the 'x_' prefix. It's not kept for the other mac encodings. There's a useful table here: https://github.com/behdad/fonttools/issues/236 -- ___ Python tracker rep...@bugs.python.org http

[issue24043] Implement mac_romanian and mac_croatian encodings

New submission from Behdad Esfahbod: They are used in OpenType fonts, but not implemented by Python at this time. Here's are the Unicode mappings for them: http://unicode.org/Public/MAPPINGS/VENDORS/APPLE/ROMANIAN.TXT http://unicode.org/Public/MAPPINGS/VENDORS/APPLE/CROATIAN.TXT Thanks

[issue24040] plistlib assumes dict_type is descendent of dict

Behdad Esfahbod added the comment: I don't have a valid use-case in mind. I was reading the code and noticed this discrepancy. (4) replace the isinstance(self.stack[-1], type({})) with not isinstance(self.stack[-1], type([])). -- ___ Python

[issue24040] plistlib assumes dict_type is descendent of dict

Behdad Esfahbod added the comment: The items on the stack are created in two ways: [], and self._dict_type(). Currently the code assumes that self._dict_type() returns an object that passes isinstance(..., type({})). I suggested the following two ways to improve this check: - Replace

[issue24041] Implement Mac East Asian encodings properly

Behdad Esfahbod added the comment: Thanks Marc-Andre. If the x_ was indeed added for that reason, it's quite a coincidence, because the MIME name of these encodings also starts with x-mac-..., so I assumed that's where the x_ comes from. The mappings are available at the Unicode website

[issue24041] Implement Mac East Asian encodings properly

Behdad Esfahbod added the comment: They are a rather minor change on top of the existing Asian encodings. So implementing them in Python might be easier. I have a half-done version of those. I can try finishing and post it back here

[issue24043] Implement mac_romanian and mac_croatian encodings

Behdad Esfahbod added the comment: Very valid question. Let me ask and get back to you. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24043

[issue24043] Implement mac_romanian and mac_croatian encodings

Behdad Esfahbod added the comment: Huh. So they are implemented, even though they are not in aliases.py. Sorry about the noise! Please add them to aliases.py. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24043

[issue24043] Implement mac_romanian and mac_croatian encodings

Behdad Esfahbod added the comment: Similar encodings have an alias that removes the underscore: https://github.com/python/cpython/blob/master/Lib/encodings/aliases.py#L435 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org