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/issue24
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/issue24
Behdad Esfahbod added the comment:
Very valid question. Let me ask and get back to you.
--
___
Python tracker
<http://bugs.python.org/issue24043>
___
___
Pytho
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
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 Unico
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
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([])).
--
___
P
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
T
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
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_
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
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 i
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/is
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, addi
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 r
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, lis
16 matches
Mail list logo
