[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, and None. This can be used for safely evaluating strings containing Python expressions from untrusted sources without the need to parse the values oneself. """ This makes me to believe that this is a useful replacement for eval() that is safe. However, it fails to make it clear that it parses **one literal**, NOT an expression. Ie. it can't handle "2*2". Weirdly enough, at least with my Python 3.2.3, it does handle "2+2" with no problem. This seriously limits the usefulness of this function. Is there really no equivalent that parses simple expressions of literals? -- messages: 227941 nosy: Behdad.Esfahbod priority: normal severity: normal status: open title: ast.literal_eval() doesn't do what the documentation says ___ Python tracker <http://bugs.python.org/issue22525> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 in Python 3. Regarding DoS attack with a safe eval(), I understand the concern, but that's still a huge improvement over security risks of eval(). -- ___ Python tracker <http://bugs.python.org/issue22525> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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". -- ___ Python tracker <http://bugs.python.org/issue22525> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 <http://bugs.python.org/issue11101> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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. Unfortunately this causes a lot of trouble for clients [0], because it means that XML cannot represent the full Unicode repertoire. I'm curious about alternates. Perhaps the expat module can be extended to allow recovering from this if the client chooses to... [0] eg. https://github.com/behdad/fonttools/issues/249 -- nosy: +Behdad.Esfahbod ___ Python tracker <http://bugs.python.org/issue10733> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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
versions: Python 3.4
___
Python tracker
<http://bugs.python.org/issue24040>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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', 'x_mac_trad_chinese' : 'big5', A full implementation is appreciated. [0] https://github.com/python/cpython/blob/master/Lib/encodings/aliases.py#L539 -- components: Library (Lib) messages: 241876 nosy: Behdad.Esfahbod priority: normal severity: normal status: open title: Implement Mac East Asian encodings properly ___ Python tracker <http://bugs.python.org/issue24041> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 <http://bugs.python.org/issue24041> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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. -- components: Library (Lib) messages: 241879 nosy: Behdad.Esfahbod priority: normal severity: normal status: open title: Implement mac_romanian and mac_croatian encodings versions: Python 3.6 ___ Python tracker <http://bugs.python.org/issue24043> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 tracker
<http://bugs.python.org/issue24040>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 with: isinstance(..., self._dict_type)
- Replace with: not isinstance(..., type([]))
Feel free to close. I reported because I saw room for improvement. I don't
/need/ the change myself.
Thanks.
--
___
Python tracker
<http://bugs.python.org/issue24040>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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: http://unicode.org/Public/MAPPINGS/VENDORS/APPLE/JAPANESE.TXT http://unicode.org/Public/MAPPINGS/VENDORS/APPLE/CHINTRAD.TXT http://unicode.org/Public/MAPPINGS/VENDORS/APPLE/KOREAN.TXT http://unicode.org/Public/MAPPINGS/VENDORS/APPLE/CHINSIMP.TXT As for actual use, they are part of the OpenType standard. So by user request, I had to implement them last week in the FontTools Python library. This is useful for people when dealing with old and legacy fonts, specially in the process of converting them to Unicode-compatible fonts. -- ___ Python tracker <http://bugs.python.org/issue24041> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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. -- ___ Python tracker <http://bugs.python.org/issue24041> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 <http://bugs.python.org/issue24043> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 <http://bugs.python.org/issue24043> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 <http://bugs.python.org/issue24043> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
