[issue29241] sys._enablelegacywindowsfsencoding() don't apply to os.fsencode and os.fsdecode

2017-01-19 Thread JGoutin
JGoutin added the comment: A little encoding cache benchmark. Current Code: = import sys def _fscodec(): encoding = sys.getfilesystemencoding() errors = sys.getfilesystemencodeerrors() def fsencode(filename): filename = fspath(filename) # Does type-checking

[issue29241] sys._enablelegacywindowsfsencoding() don't apply to os.fsencode and os.fsdecode

2017-01-13 Thread JGoutin
JGoutin added the comment: Yes, I reported this encoding issue to some of them. But, there is still some problems : - Some libraries are not updated frequently (Or not still maintained), and still use fsencode. - Tests and CI don't see this problem if they don't have a test case for filename

[issue29241] sys._enablelegacywindowsfsencoding() don't apply to os.fsencode and os.fsdecode

2017-01-13 Thread JGoutin
JGoutin added the comment: Personally, I call "sys._enablelegacywindowsfsencoding()" for only one reason : Temporary fixing issues with some third party libraries which use C code for files I/O (With filename as "mbcs" encoded bytes internally). Theses libraries generally c

[issue29241] sys._enablelegacywindowsfsencoding() don't apply to os.fsencode and os.fsdecode

2017-01-11 Thread JGoutin
JGoutin added the comment: import sys # Force the use of legacy encoding like versions of Python prior to 3.6. sys._enablelegacywindowsfsencoding() # Show actual file system encoding encoding = sys.getfilesystemencoding() print('File system encoding:', encoding) # os.fsencode(filename) VS

[issue29241] sys._enablelegacywindowsfsencoding() don't apply to os.fsencode and os.fsdecode

2017-01-11 Thread JGoutin
New submission from JGoutin: The doc say that calling "sys._enablelegacywindowsfsencoding()" is equivalent to use "PYTHONLEGACYWINDOWSFSENCODING" environment variable. In fact, this no apply to "os.fsencode" and "os.fsdecode". Example with Python 3.6

[issue25646] Distutils and Windows SDK 7.1

2015-11-23 Thread JGoutin
JGoutin added the comment: OK, I'll look that. -- resolution: -> out of date status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python

[issue25646] Distutils and Windows SDK 7.1

2015-11-20 Thread JGoutin
JGoutin added the comment: Better compatibility for Architectures names conversion between Vcvarsall.bat and SetEnv.Cmd for cross compilation. This seem to work good on classic compilation, but I still have difficulties with cross-compilation. -- title: Distutils and Windows SDK 7.0

[issue25646] Distutils and Windows SDK 7.0 / Windows SDK 7.1 / Visual C++ Build Tools 2015

2015-11-20 Thread JGoutin
JGoutin added the comment: I updated the file. I did some new tests with cross compilation and I see that the "libpath" environment variable may be missing in some case. Fortunately, this one is not used in the following of the code. So I set it as optional result for "

[issue25646] Distutils and Windows SDK 7.0 / Windows SDK 7.1 / Visual C++ Build Tools 2015

2015-11-19 Thread JGoutin
JGoutin added the comment: Hello, I modified "msvc9compiler.py" with following changes : - Add automatic compatibility with standalone VC++ compilers from Windows SDK 7.1. (Not for 6.1/7.0, because that finally don't work as good as it seem on first view and there is al

[issue25646] Distutils and Windows SDK 7.0 / Windows SDK 7.1 / Visual C++ Build Tools 2015

2015-11-17 Thread JGoutin
JGoutin added the comment: For SDK 7.1, with "DISTUTILS_USE_SDK=1" (And "MSSdk=1"), I still have the problem. The error is on "include", "lib", "libpath", "path" environment variables which are not set by "vcvarsall.bat&quo

[issue25646] Distutils and Windows SDK 7.0 / Windows SDK 7.1 / Visual C++ Build Tools 2015

2015-11-17 Thread JGoutin
New submission from JGoutin: Hello, This issue is related to Visual C++ standalone distributions (Without any Visual Studio version installed). Distutils don't properly detect theses compilers. It try to work with "vcvarsall.bat" but this file : - is missing with Visual C++ Build