Tetsuya Morimoto added the comment:
I can reproduce it on Mac OS X.
I made a patch which checks the "func_name" attribute of function before it
refers. It works for me. However, I wonder if a function has both
"func.im_self" and "func.func_name"? Tell me the
Changes by Tetsuya Morimoto :
Removed file: http://bugs.python.org/file24801/distutils2_pypi_wrapper.patch
___
Python tracker
<http://bugs.python.org/issue14002>
___
___
New submission from Tetsuya Morimoto:
This patch adds Japanese legacy encodings as below.
https://bitbucket.org/t2y/cpython/branches/compare/japanese-legacy-encoding..default
* eucjp_ms (euc-jp compatible with cp932)
* iso2022_jp_ms (yet another iso-2022-jp compatible with cp932, similar to
Tetsuya Morimoto added the comment:
On Mon, Dec 15, 2014 at 1:04 AM, R. David Murray wrote:
> In emails these are labeled as, say, iso-2022-jp-ms?
No. These are labeled just 'iso-2022-jp' and we (japanese) choose
proper charset encoding to decode the encoded text. You can see
sev
Tetsuya Morimoto added the comment:
>> These character encodings are legacy, but are still used.
>
> Do you have an idea of how many users still have documents stored or
> exchanged using these encodings?
Hmm, I guess iso-2022-jp codec is still default charset of MUA (Mail
Tetsuya Morimoto added the comment:
> By error prone, it mean that it's easy to introduce a bug or a regression,
> since the code is complex and almost nobody maintains it.
Indeed. Actually, I encountered some faults when I migrated original
patch. The character encoding is a kind o
Tetsuya Morimoto added the comment:
> Another traditional issue with Japanese codecs is that people have different
> opinions on what the encoding should do. It may be that when we release the
> codec, somebody comes up and says that the codec is incorrect, and it should
>
