Konstantin Zemlyak added the comment:
Terry J. Reedy wrote:
> Is this still relevant or should it be closed?
Should be closed.
> On Win10, I created a short script юникод.py using Save As from IDLE.
>
> py -2 юникод.py produces
> C:\Programs\Python27\python.exe: can't
New submission from Konstantin Zemlyak:
When installing python 3.3 under windows and checking "Compile .py files to
byte code after installation" Lib/venv/scripts/nt/pydoc.py gets precompiled as
well. This causes venv module to abort with "Error: 'utf-8' codec c
Konstantin Zemlyak added the comment:
If option to precompile python files is checked in installer, pydoc.py gets
compiled into binary files Lib\venv\scripts\nt\__pycache__\pydoc.cpython33.pyc
and Lib\venv\scripts\nt\__pycache__\pydoc.cpython33.pyo
Konstantin Zemlyak added the comment:
Also current title is a bit wrong, since decoding error happens in runtime each
time venv is invoked, while the source of the problem happens while
byte-compiling stdlib at install time once.
--
___
Python
Konstantin Zemlyak added the comment:
Not at all. I have installed Python into "C:\Program Files (x86)\Python33".
Also made a copy into "D:\Python33" and got the same results.
The problem is in file contents (pyc/pyo files are binary, utf-8 fails to
decode the
Changes by Konstantin Zemlyak :
--
title: Decoding error at install time when byte-compiling venv scripts ->
Decoding error due to byte-compiling venv scripts at install time
___
Python tracker
<http://bugs.python.org/issu
New submission from Konstantin Zemlyak:
Python 3.4.0 (v3.4.0:04f714765c13, Mar 16 2014, 19:25:23) [MSC v.1600 64 bit
(AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> bytearray([256])
Traceback (most rec
Konstantin Zemlyak added the comment:
To clarify few things:
- Yes, I know that 256 doesn't fit into byte. I was checking how
bytes/bytearray are handling overflow.
- I know that range() is a half-open interval.
Yet this error message still gave me a "wtf" moment because I di
New submission from Konstantin Zemlyak:
Running `py.exe юникод.py` in cmd window fails:
E:\>set PYLAUNCH_DEBUG=1
E:\>py юникод.py
launcher build: 32bit
launcher executable: Console
File 'C:\Users\Zart\AppData\Local\py.ini' non-existent
Using global configuration file 'C:\W
Changes by Konstantin Zemlyak :
Removed file:
http://bugs.python.org/file33247/pylauncher-fix-launcing-unicode-filenames.patch
___
Python tracker
<http://bugs.python.org/issue20
Konstantin Zemlyak added the comment:
Sorry, fixed whitespaces in the patch.
--
Added file:
http://bugs.python.org/file33248/pylauncher-fix-launcing-unicode-filenames.patch
___
Python tracker
<http://bugs.python.org/issue20
Konstantin Zemlyak added the comment:
I don't care much about debug output though it probably should be fixed.
The point is that changing text mode of stdout has a weird side effect of
fixing command-line arguments when invoking interactively from cm
Konstantin Zemlyak added the comment:
There is something weird with my proposed fix. Right after submitting a bug
with patch I've updated pythons on my system - 2.7.5 to 2.7.6, 3.3.2 to 3.3.3,
and installed 3.4.0b1 - both 32- and 64-bit. Then my fixed py.exe stopped
working.
Then I
Konstantin Zemlyak added the comment:
Some more fun stuff with command-line (I'm cutting output to few essential
lines for easier reading):
e:\cpython\PCbuild\py.exe юникод.py
...
Called with command line: .py
run_child: about to run '"C:\Program Files (x86)\Python33\pyt
Konstantin Zemlyak added the comment:
Win2003 x64, VS2008, vanilla python 2.7rc1 amd64 from python.org.
Building python packages with C extensions works fine. Tested on simplejson,
jinja2 (with enabled speedups) and PIL.
--
nosy: +zart
___
Python
Konstantin Zemlyak added the comment:
64-bit Windows, 64-bit cmd.exe, 64-bit python, not patched::
D:\>"c:\Program Files\Python27\python.exe"
Python 2.7rc1 (r27rc1:81787, Jun 6 2010, 20:03:36) [MSC v.1500 64 bit
(AMD64)]
on win32
Type "
Konstantin Zemlyak added the comment:
Tried msvc9compiler-py27.patch. find_vcvarsall() still works with the same
result, while distutils.msvc9compiler.VS_BASE has been changed.
::
>>> distutils.msvc9compiler.find_vcvarsall(9.0)
u'c:\\Program Files (x86)\\Mi
Konstantin Zemlyak added the comment:
> Using the remote shell, those VS2008 env vars are not set and
> so the build fails.
Seems it doesn't load user profile.
> The output is:
>
> VS2008 product dir: None - Software\Microsoft\VisualStudio\9.0
> VS2008 product dir: No
Konstantin Zemlyak added the comment:
Environment variables have always been process-wide. It doesn't deserve any
special mention in threads documentation.
--
nosy: +zart
___
Python tracker
<http://bugs.python.org/i
19 matches
Mail list logo
