Suzumizaki added the comment:
Thanks, but Those cannot resolve this issue.
This is install time problem. In other words, whatever the default encoding is,
even some users change it, `distutils.util.byte_compile` must always succeed.
There's no relation between using non-ASCII path an
Suzumizaki added the comment:
... and please check "batch.diff" (Oops, that's typo of 'patch'). I just added
"encoding" parameter to calling open() function, and added the temp file to
'utf-8' code declaration. This bug could happen where the defa
Suzumizaki added the comment:
Terribly Sorry! I forgot to write this is only Windows Issue! Thanks!
--
components: +Unicode, Windows
nosy: +ezio.melotti, paul.moore, steve.dower, tim.golden, vstinner, zach.ware
___
Python tracker
<ht
Suzumizaki added the comment:
Here's test code.
Note: I marked just Python 3.8 and 3.7 I tested, but maybe all versions.
--
Added file: https://bugs.python.org/file48473/my_test_case.py
___
Python tracker
<https://bugs.python.org/is
New submission from Suzumizaki :
`distutils.util.byte_compile` fails _indirect_ byte compiling when the
full-path of the .py file contains non-ASCII characters.
Because there is the project (cx_Freeze) which directly uses
`distutils.util.byte_compile`, the problem would happen while installing
Changes by Suzumizaki :
--
nosy: +Suzumizaki
___
Python tracker
<http://bugs.python.org/issue24307>
___
___
Python-bugs-list mailing list
Unsubscribe:
Suzumizaki added the comment:
Thank you Nick about msg210209.
I would like to try making PEP, but the work looks somewhat difficult. It may
take the time.
BTW, C/C++ Standards only allow the encoding of source code as platform
dependent. They don't define "the standard encoding
Suzumizaki added the comment:
Thank you Victor about msg210125, I read the discussion on ML, May 2011.
Inside the articles, the previous discussion on tracker is found:
"On Windows, don't encode filenames in the import machinery"
http://bugs.python.org/issue11619
Here is my
Suzumizaki added the comment:
Both Visual Studio 2012 and 2013 CANNOT install on Windows Vista. That's OK for
you even Vista alive until April 2017?
--
___
Python tracker
<http://bugs.python.org/is
Suzumizaki added the comment:
Thank you Nick, I understand the behavior of this issue should be written on
PEP.
By the way, Can I continue the discussion here? or is there elsewhere suitable
place for the PEP?
--
___
Python tracker
<h
Suzumizaki added the comment:
Thanks for taking into account this issue for PEP 451.
Honestly to say, I can't imagine why or/and how this issue(or my patches)
causes any problems especially compatibility issues. If someone can point them,
I will try to resolve.
Note that I extend onl
Suzumizaki added the comment:
Thank you for reply, STINNER.
> You encode it to UTF-8 and use "\xHH\xHH\xHH..." syntax to keep ASCII
> encoding for the C file? The NAME may also be mentionned in docstrings,
> C comments, type names, etc.
The main purpose of this issue is
Suzumizaki added the comment:
Thank you for reply.
The hack msg209998 is interesting, but how to name submodule with non latin
like languages, especially keeping native reable? X(
The reason I don't use like "name.encode('unicode-escape').replace(b'\\',
b&#x
Changes by Suzumizaki :
Added file: http://bugs.python.org/file33868/sample_importing_non_ascii_pyd.zip
___
Python tracker
<http://bugs.python.org/issue20485>
___
___
Changes by Suzumizaki :
Added file:
http://bugs.python.org/file33867/20140202_patch_for_python3.3_4.patch
___
Python tracker
<http://bugs.python.org/issue20
New submission from Suzumizaki:
Currently, the name of .pyd modules is limited within 7 bit US-ASCII.
I want to do "import X" to import X.pyd, where X contains Unicode characters.
I tried to make the patch and my work seems to be done successfully.
I will post the patch with this
Suzumizaki added the comment:
There is possibility that the installation of setuptools fails with
any Windows machine because of this bug. I want change the priority of this
issue higher...
I failed the installation of setuptools with Python 2.7.6 on my machine,
Windows 8.1 Pro Japanese
Suzumizaki added the comment:
Thanks for reply.
I tried Python 3.1 Beta, and the testcode goes fine.
(and my current work also.)
I checked with Windows XP, I told before.
My problem seems resolved, and here is answers only to make sure.
>(What is the value of sys.maxunicode there tho
New submission from Suzumizaki :
When the path of the package has non-ascii characters, importing such
packages always fails except the first time (in other words, always
fails when compiled .pyc file exists).
The problem exists even the names of such modules only consist of
us-ascii
Changes by Suzumizaki :
--
nosy: +Suzumizaki
___
Python tracker
<http://bugs.python.org/issue5924>
___
___
Python-bugs-list mailing list
Unsubscribe:
20 matches
Mail list logo
