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 of source
Nick Coghlan added the comment:
import-...@python.org would be the appropriate list for this one.
However, we can't do anything about it until Python 3.5 next year at the
earliest, and I'm already planning to write a follow-up to
http://www.python.org/dev/peps/pep-0451/ that adapts the
STINNER Victor added the comment:
we *should* do, but there will be some research involved in figuring out how
good the current support for UCN C identifiers is in at least gcc, clang and
Visual Studio 2013
Python 3.4 uses Visual Studio 2010. I'm not sure that you can build an
extension
Nick Coghlan added the comment:
Oh, you're right - I temporarily forgot that the C runtime compatibility was
compiler version specific on Windows. So such an approach *would* require
updating the CPython compiler on Windows to at least VS2013 for 3.5. Still,
we're likely to want to do that
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 rep...@bugs.python.org
http://bugs.python.org/issue20485
Nick Coghlan added the comment:
Updating the C extension loading API to take advantage of PEP 451 is on the
to do list for 3.5, so I'll see if we can do something about this as well.
However, as Victor noted, it will depend on whether or not we can figure
out a compiler independent cross
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 only the
Nick Coghlan added the comment:
As Victor noted, inventing our own encoding scheme just for this use case
isn't desirable, although it's certainly a good fallback option that will
ensure the feature remains feasible even if trying to handle the Unicode
issues at the C compiler level proves too
STINNER Victor added the comment:
Oh, the topic was already discussed some years ago. Start:
https://mail.python.org/pipermail/python-dev/2011-May/111279.html
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20485
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
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 issue, and next
Changes by Suzumizaki suzumiz...@free.japandesign.ne.jp:
Added file:
http://bugs.python.org/file33867/20140202_patch_for_python3.3_4.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20485
Changes by Suzumizaki suzumiz...@free.japandesign.ne.jp:
Added file: http://bugs.python.org/file33868/sample_importing_non_ascii_pyd.zip
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20485
___
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +brett.cannon, eric.snow, haypo, ncoghlan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20485
___
Serhiy Storchaka added the comment:
I think that if you need a module with non-ASCII name, you can wrap it in
Python module.
=== späm.py ===
from _spam import *
from _spam import __all__, __doc__
=== späm.py ===
--
nosy: +serhiy.storchaka
___
Amaury Forgeot d'Arc added the comment:
I'd use a much simpler encoding.
Maybe something like
name.encode('unicode-escape').replace(b'\\', b'_')
As you said, simplicity is important for tools which generate code!
--
nosy: +amaury.forgeotdarc
___
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'_') is the length limits of the
STINNER Victor added the comment:
The PyInit_NAME symbol is not the only place where NAME is used. The NAME is
also present in the PyModuleDef structure. It looks lie Python expects UTF-8
here. You encode it to UTF-8 and use \xHH\xHH\xHH... syntax to keep ASCII
encoding for the C file? The
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 I want use Cython like
Serhiy Storchaka added the comment:
The hack msg209998 is interesting, but how to name submodule with non latin
like languages, especially keeping native reable? X(
It is left to your discretion. You can use idna, punycode, utf-7, szm62 or
romaji.
--
20 matches
Mail list logo
