Christoph Gohlke added the comment:
Thank you for fixing this issue so fast! Python 3.9.4 works well.
--
___
Python tracker
<https://bugs.python.org/issue43
New submission from Christoph Gohlke :
First reported at https://github.com/numpy/numpy/issues/18720
After upgrading to Python 3.9.3, 32-bit on Windows, importing numpy (installed
via `pip install numpy`) crashes:
```
Microsoft Windows [Version 10.0.19041.906]
C:\Python39-32>python -X
Christoph Gohlke added the comment:
This issue seems specific to C extensions built with pybind11 (using 2.5.0 and
master branch). Building the minimal example at
https://github.com/pybind/python_example and running `python.exe -c"import
python_example"` will cra
Change by Christoph Gohlke :
--
status: closed -> open
___
Python tracker
<https://bugs.python.org/issue41237>
___
___
Python-bugs-list mailing list
Unsubscrib
Christoph Gohlke added the comment:
I tracked this to an import of the numba-0.50.1 package during the numpy tests.
`python -c"import numba'` is enough to reproduce this crash during interpreter
exit. Probably the package needs to be ported to Python 3.9.
--
stage: ->
Change by Christoph Gohlke :
--
type: -> crash
___
Python tracker
<https://bugs.python.org/issue41237>
___
___
Python-bugs-list mailing list
Unsubscrib
New submission from Christoph Gohlke :
When testing extension packages on Python 3.9.0b4 for Windows, I often get
access violations in `python39.dll!meth_dealloc` during interpreter exit. The
crash only happens when heap verification is turned on (`"C:\Program Files
(x86)\Windows Ki
New submission from Christoph Gohlke :
Re https://bugs.python.org/issue9949:
Is it intended that Python-3.8.0b4 now also resolves mapped network drives and
drives created with `subst`?
I would not expect this from the documentation at
https://docs.python.org/3.8/library/os.path.html
Christoph Gohlke added the comment:
`PyRun_String` was exported at least since `python23.dll`.
Python.Net relies on it at
<https://github.com/pythonnet/pythonnet/blob/master/src/runtime/runtime.cs#L858>
--
___
Python tracker
New submission from Christoph Gohlke :
While testing third party packages on Python 3.8.0b1 for Windows, I noticed
that the `PyRun_String` function is no longer exported from `python38.dll`.
Is this intentional? I can't see this mentioned at
<https://docs.python.org/3.8/whatsnew/3.8.h
Christoph Gohlke added the comment:
This is still an issue with Python 3.8.0a4
--
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
versions: +Python 3.8
___
Python tracker
<https://bugs.python.org/issue35
Christoph Gohlke added the comment:
> test_isdigit.c: Can you try to call locale.setlocale(locale.LC_CTYPE, "")
> before running your benchmark on Python 3.7.0?
Yes, that slows down Python 3.7.0a3 to the 3.7.0a4 level.
--
__
Christoph Gohlke added the comment:
I attached a minimal C extension module that can be used to demonstrate the
performance degradation from Python 3.7.0a3 to 3.7.0a4.
Build the extension with `py setup.py build_ext --inplace`, then run the
following code on Python 3.7.0a3 to 3.7.0a4
Change by Christoph Gohlke :
Added file: https://bugs.python.org/file47929/setup.py
___
Python tracker
<https://bugs.python.org/issue35195>
___
___
Python-bugs-list m
Change by Christoph Gohlke :
Added file: https://bugs.python.org/file47928/test_isdigit.c
___
Python tracker
<https://bugs.python.org/issue35195>
___
___
Python-bug
Christoph Gohlke added the comment:
> Can someone please try to write an example which only uses the stdlib?
The simplest is to compare performance of the
`windll.LoadLibrary('API-MS-WIN-CRT-STRING-L1-1-0.DLL')` function on Python
3.7.0a3 and 3.7.0a4, but that will mostly measure Pyt
Change by Christoph Gohlke :
--
type: -> crash
___
Python tracker
<https://bugs.python.org/issue33706>
___
___
Python-bugs-list mailing list
Unsubscrib
New submission from Christoph Gohlke :
When testing Python 3.7.0b5 x64 (and betas before) on Windows 10, I
occasionally get segfaults when passing a program as string on the command
line. The shortest command to reproduce this on my system is `python.exe -c 1`
with heap detection turned
Christoph Gohlke <cgoh...@uci.edu> added the comment:
> Have you confirmed that's a problem?
No, I have not noticed any problems yet with with Python 3.7.0a3 and many
extensions built with VS2017.5.
--
___
Python tracker <rep...@bug
Christoph Gohlke <cgoh...@uci.edu> added the comment:
Since this has not been reverted/changed for 3.6.4 or 3.7.0a3, another
potential issue arises: C extensions that are compiled with Visual Studio 2017
are linked to a newer version of vcruntime140.dll (latest is 14.12.25810,
VS201
Christoph Gohlke <cgoh...@uci.edu> added the comment:
I build most of my binaries after calling the correct vcvarsall.bat so I did
not notice until today, when I was trying to build outside that environment.
Also, I misread your comment (https://bugs.python.org/issue31340#msg301538)
e
Christoph Gohlke <cgoh...@uci.edu> added the comment:
I have Visual Studio 2015 and Visual Studio 2017 Community editions with latest
patches installed.
Building a minimal C extension on Python 3.6.3 with distutils now uses MSVC
14.11.25503. That is unexpected.
When building c
Changes by Christoph Gohlke <cgoh...@uci.edu>:
--
nosy: +cgohlke
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29943>
___
__
Christoph Gohlke added the comment:
The applied patch breaks bdist_wininst installers for 64-bit Python. See
<http://bugs.python.org/issue28680>.
--
nosy: +cgohlke
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Christoph Gohlke added the comment:
The attached patch was tested with Pillow-3.4.2 on Python 3.6.0rc1, 32-bit and
64-bit.
It would be nice to get this fixed in Python 3.5.3 and 3.6.0.
--
components: +Windows
keywords: +patch
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
Added
Christoph Gohlke added the comment:
Pillow-3.4.2.win-amd64-py3.5.exe fails to install due to this. See
<https://github.com/python-pillow/Pillow/issues/2285>.
`MS_WIN64` is never defined at
<https://hg.python.org/cpython/file/v3.5.2/PC/bdist_wininst/install.c#l157>
because bdist_
New submission from Christoph Gohlke:
Trying to build numpy-1.11.2rc1 wheels for Python 3.6.0b1 on Windows 10 with
`python.exe setup.py bdist_wheel`, python36.dll (32 and 64 bit) segfaults in
the `find_maxchar_surrogates` function. Some other packages built OK, e.g.
Cython, pyzmq and Pillow
Christoph Gohlke added the comment:
FWIW, this could be a build issue:
1) `_ssl.OPENSSL_VERSION` for the 2.7.12rc1 amd64 binaries is "OpenSSL 1.0.2d 9
Jul 2015", not OpenSSL 1.0.2g as expected from the changelog at
<https://hg.python.org/cpython/file/v2.7.12rc1/Misc/NEWS#l353>
Changes by Christoph Gohlke <cgoh...@uci.edu>:
--
nosy: +cgohlke
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27305>
___
__
Changes by Christoph Gohlke <cgoh...@uci.edu>:
Added file: http://bugs.python.org/file40402/test_dll_load_failed.py
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
New submission from Christoph Gohlke:
This issue was first mentioned at <http://bugs.python.org/issue24872#msg249591>.
The attached script (test_dll_load_failed.py) builds up to 256 C extension
modules and imports them. On Python 3.4.3 the script passes while on Python
3.5.0rc3 the
Christoph Gohlke added the comment:
Just to confirm: the following script fails with `ImportError: DLL load failed`
on Python 3.5.0rc2. It fails around the 120th extension. The script passes on
Python 3.4.3.
Also, Python 3.5.0rc2 (not Python 3.4.3) requires the `extra_postargs=['/DLL
Christoph Gohlke added the comment:
> Do you know where that time is being spent?
The incremental linker.
> I'd guess it's probably O(N**2) with the number of obj file
Doesn't seem so. For example the pyrxp 2.1 package contains only 23 C files and
takes minutes to link. Most packages c
Christoph Gohlke added the comment:
I have now recompiled hundreds of Python packages and C/C++/Fortran libraries
with the `/MT /GL /LTCG /NODEFAULTLIB:libucrt.lib ucrt.lib` flags. Many
packages test OK, only few crashes.
Some more findings:
The /MT flag forces to also statically link
Christoph Gohlke added the comment:
Two findings regarding the new semi-static linking options:
Distutils now creates libraries (.lib) that may not be readable by subsequent
versions of Visual C++
https://msdn.microsoft.com/en-us/library/0zza0de8.aspx.
Build times and static library sizes
Changes by Christoph Gohlke cgoh...@uci.edu:
--
nosy: +cgohlke
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23606
___
___
Python-bugs-list
Christoph Gohlke added the comment:
The matplotlib extensions compiled with Python 3.5.0rc1 (/MT) are larger than
those compiled with 3.5.0b4 (/MD). The C++ runtime is statically linked. This
seems undesirable for the same reasons the UCRT is not linked statically.
In Introducing
Christoph Gohlke added the comment:
Another /MT only issue: cryptography-1.0 and other libraries depending on
openssl fail to link to static MT openssl-1.0.1p:
cryptlib.obj : error LNK2001: unresolved external symbol __iob_func
This can be fixed manually [1].
[1]
http://openssl.6102.n7
Christoph Gohlke added the comment:
FWIW, I rebuilt static libraries for zlib, jbig, jpeg, openjpeg, tiff, webp,
lcms, and freetype with /MT flag (a tedious task) and was able to build
matplotlib and Pillow using Python 3.5.0rc1. As expected there is no dependency
on the vcruntime DLL.
Even
Christoph Gohlke added the comment:
Matplotlib and my own extensions are using C++ sources but do not depend on
msvcp140.dll, just the ucrt. Am I missing something?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24872
Christoph Gohlke added the comment:
Thanks for going through that tedious process
~140 libraries to go.
I hit the wall last night trying to build Boost DLLs. Boost's build tool b2
does not allow `link=shared runtime-link=static`, hence the `/MT /LTCG
/NODEFAULTLIB:libucrt.lib ucrt.lib` magic
Christoph Gohlke added the comment:
Thank you for looking into this.
I just tried '/NODEFAULTLIB:msvcrt.lib' with Pillow and matplotlib but still
get the linker errors:
tiff.lib(jbig.obj) : error LNK2001: unresolved external symbol __imp_memchr
freetype.lib(ftbase.obj) : error LNK2001
Christoph Gohlke added the comment:
It seems the switch to '/MT' was consciously intended as Python 3.5 itself is
now compiled with '/MT'.
For now I have patched _msvccompiler.py to use '/MD' and continue to link
libraries built with '/MD
Christoph Gohlke added the comment:
This change broke all my builds that link statically against 3rd party
libraries built with the `/MD` flag. `/MD` was used at least since Python 2.3
and is the default for static libraries in Visual Studio 2015. Some of the
broken builds: lxml, pillow
Changes by Christoph Gohlke cgoh...@uci.edu:
--
nosy: +cgohlke
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17213
___
___
Python-bugs-list
Christoph Gohlke added the comment:
Sorry, of course I meant 2**31. Thank you very much for your review!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18909
Christoph Gohlke added the comment:
@haypo: Thanks for fixing this so fast! Your changes work for me on
win-amd64-py2.7 and py3.3.
I am aware of two 3rd party C extensions that use the value of interpaddr():
https://github.com/python-imaging/Pillow/blob/master/_imagingtk.c#L40
https
New submission from Christoph Gohlke:
Using 64 bit CPython 2.6.6, 2.7.5, 3.2.5 or 3.3.2, numpy 1.7.1 and matplotlib
1.3.0 on Windows 8 64 bit, the following script segfaults most of the times:
```
# allocate ~4GB fragmented data
import numpy
a = [numpy.zeros(2**i, 'uint8') for i in range(1
Changes by Christoph Gohlke cgoh...@uci.edu:
Added file:
http://bugs.python.org/file31568/fix_tkapp_interpaddr-win-amd64-py3.3.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18909
Changes by Christoph Gohlke cgoh...@uci.edu:
Added file: http://bugs.python.org/file31566/tkapp_interpaddr_crash_win-amd64.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18909
Changes by Christoph Gohlke cgoh...@uci.edu:
--
keywords: +patch
Added file:
http://bugs.python.org/file31567/fix_tkapp_interpaddr-win-amd64-py2.7.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18909
Changes by Christoph Gohlke cgoh...@uci.edu:
--
nosy: +cgohlke
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17289
___
___
Python-bugs-list
Changes by Christoph Gohlke cgoh...@uci.edu:
--
nosy: +cgohlke
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16296
___
___
Python-bugs-list
Changes by Christoph Gohlke cgoh...@uci.edu:
--
nosy: +cgohlke
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11835
___
___
Python-bugs-list
Changes by Christoph Gohlke cgoh...@uci.edu:
--
nosy: +cgohlke
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1425127
___
___
Python-bugs-list
Changes by Christoph Gohlke cgoh...@uci.edu:
--
versions: +Python 2.7, Python 3.2
Added file: http://bugs.python.org/file21034/msilib2.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7639
Christoph Gohlke cgoh...@uci.edu added the comment:
Actually, PyQt4 was not a good example since it is not build using distutils.
Pywin32 and wxPython extensions are the only ones on my system specifying a
dependency on Common Controls or MFC. No dependencies other than CRT, MFC, and
Common
Christoph Gohlke cgoh...@uci.edu added the comment:
The proposed patch was meant to be backwards compatible. Unconditionally
removing the whole assembly/manifest from extensions could break extensions
that have additional dependencies, such as MFC or Common Controls. PyQt4
extensions
New submission from Christoph Gohlke cgoh...@uci.edu:
Running Tools/Scripts/2to3.py on Python 3.2rc3 or 2.7.1 for Windows on a file
that contains a formfeed character (0x0C, FF) results in a truncated file.
E.g. a file (attached) with the content
print 1
FF
print 2
is incorrectly refactored
Changes by Christoph Gohlke cgoh...@uci.edu:
--
components: +2to3 (2.x to 3.0 conversion tool)
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11250
Changes by Christoph Gohlke cgoh...@uci.edu:
--
nosy: +cgohlke
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4709
___
___
Python-bugs-list mailing
Christoph Gohlke cgoh...@uci.edu added the comment:
Curses binaries for Python 2.5, 2.6, 2.7, 3.1 and 3.2, win32 and win-amd64, are
available at http://www.lfd.uci.edu/~gohlke/pythonlibs/#curses.
--
___
Python tracker rep...@bugs.python.org
http
Changes by Christoph Gohlke cgoh...@uci.edu:
--
nosy: +cgohlke
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11077
___
___
Python-bugs-list
Christoph Gohlke cgoh...@uci.edu added the comment:
Tkinter is not thread safe. You are changing UI elements from a thread that is
not the main thread. Use a Queue as described at
http://effbot.org/zone/tkinter-threads.htm.
--
nosy: +cgohlke
Christoph Gohlke cgoh...@uci.edu added the comment:
Thank you. The new patch works and it also fixes a crash of the
python-2.5.4.amd64 interpreter at startup when ctypes 1.0.2 and pyreadline
1.6.2 are installed.
--
___
Python tracker rep
Christoph Gohlke cgoh...@uci.edu added the comment:
The provided example has two problems: The DLL should be loaded as cdll, not
windll. C_METHOD_TYPE4 uses c_int32 as parameter type while pyFunc4Type in
testPy2.cpp uses LPVOID (64 bit on win-amd64). Even with those corrections the
issue
Christoph Gohlke cgoh...@uci.edu added the comment:
The patch attached to #8275 fixes this issue and possibly also #9266.
Tested with Python 2.7.1 64 bit on Windows 7.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9884
Christoph Gohlke cgoh...@uci.edu added the comment:
This patch fixes issue #9884 and possibly #9266.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8275
Changes by Christoph Gohlke cgoh...@uci.edu:
--
nosy: +cgohlke
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8275
___
___
Python-bugs-list mailing
Changes by Christoph Gohlke cgoh...@uci.edu:
--
nosy: +cgohlke
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10854
___
___
Python-bugs-list
Changes by Christoph Gohlke cgoh...@uci.edu:
--
nosy: +cgohlke
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6792
___
___
Python-bugs-list mailing
Christoph Gohlke cgoh...@uci.edu added the comment:
This seems to be related:
http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/7c913001-227e-439b-bf07-54369ba07994
--
nosy: +cgohlke
___
Python tracker rep...@bugs.python.org
http
Christoph Gohlke cgoh...@uci.edu added the comment:
Creating bdist_msi installers with files such as 'aixc++' (containing '+'),
'.buildinfo' (starting with '.'), and 'py.~1.5.~' (containing '~') currently
also fails, even with the proposed patch.
The revised patch should fix these cases
Christoph Gohlke cgoh...@uci.edu added the comment:
The revised patch for issue7639 now generates better short names for file names
containing spaces, '+', and leading '.'.
http://bugs.python.org/file19334/msilib.diff
Test cases that could be added to MsilibTest.test_makeshort():
TEST
Changes by Christoph Gohlke cgoh...@uci.edu:
--
nosy: +cgohlke
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2889
___
___
Python-bugs-list mailing
Christoph Gohlke cgoh...@uci.edu added the comment:
Any chance to get this fixed in 2.7? On Windows, the bug prevents some popular
applications and packages, such as pymol and matplotlib, to be used when
installed on network shares, as is common practice in computer labs
Christoph Gohlke cgoh...@uci.edu added the comment:
Btw, this bug is also present in Python 3.1, of course when using tkinter
instead of Tkinter.
Here is how to reproduce the bug on your local system: Install python-2.7b2.msi
into C:\Python27. Then open a command prompt with administrator
Christoph Gohlke cgoh...@uci.edu added the comment:
The patch seems to deal with paths that have UNC in them;
and the test seems not to.
The UNCW path is a result of the call to
ctypes.windll.kernel32.GetFinalPathNameByHandleW() in FixTk.py, which
translates \\Server\Share\File paths
Christoph Gohlke cgoh...@uci.edu added the comment:
A slightly different patch is attached to issue7639, which generates short
names more similar to Windows/NTFS:
http://bugs.python.org/file15898/msilib_make_short.diff
Here are some short names created with the msilib_make_short patch, which
Christoph Gohlke cgoh...@uci.edu added the comment:
This issue is also present in Python 2.7b2.
The svn trunk requires a slightly different patch (attached).
--
versions: +Python 2.7
Added file: http://bugs.python.org/file17304/Tkinter-import-UNCW-trunk.patch
Christoph Gohlke cgoh...@uci.edu added the comment:
The bdist_wininst and DLL build issues also exist in Python 2.7b2. A patch
against svn trunk is attached.
The pywin32 v214 package fails as reported earlier when built with Python
2.7b2. It installs and functions when built with this patch
Christoph Gohlke cgoh...@uci.edu added the comment:
I have some doubts about option #4: it is a very specific use case, and then
the whole benefit of issue 4120 is lost
Pythoncom are pywintypes are indeed special cases: Out of the 170 DLL files in
my Python site-packages directory
Christoph Gohlke cgoh...@uci.edu added the comment:
I mentioned the problem with pythoncom.dll and suggested a solution in
issue7833.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4120
Christoph Gohlke cgoh...@uci.edu added the comment:
A testcase is attached.
Information about the file URI scheme can be found at:
http://en.wikipedia.org/wiki/File_URI_scheme
http://tools.ietf.org/html/draft-hoffman-file-uri-03
http://blogs.msdn.com/ie/archive/2006/12/06/file-uris
Christoph Gohlke cgoh...@uci.edu added the comment:
I thought one conclusion of the discussion on issue4120 was that any
executable, which embeds Python and imports MSVCR9 dependent extensions, must
now provide the manifest for the MSVCR9 runtimes, either embedded or as a
separate file. See
New submission from Christoph Gohlke cgoh...@uci.edu:
Wininst-9.0.exe and wininst-9.0-amd64.exe are missing MSVCRT90 dependencies in
the embedded manifest.
While testing installers of pywin32 http://sourceforge.net/projects/pywin32/
version 214 built with Python 2.6.4
Christoph Gohlke cgoh...@uci.edu added the comment:
The last line of my previous post should actually read
python.exe setup.py bdist_wininst
Anyway, here are three files (also attached) that can reproduce the problem:
1) setup.py
from distutils.core import setup, Extension
setup(name
New submission from Christoph Gohlke cgoh...@uci.edu:
On Windows 7, Python 2.6 raises an IOError when opening a valid file URL with
urllib.urlopen(). A patch to the nturl2path.url2pathname function is attached.
It replaces '%7C' by '|' in the url at the top of the url2pathname function
Christoph Gohlke cgoh...@uci.edu added the comment:
I can confirm this issue. It prevents building a IPython msi installer on
Python 2.6 for Windows.
A patch to the Directory.make_short function in msilib\__init__.py is attached.
It falls back to generating prefix~pos filenames when a short
Christoph Gohlke cgoh...@uci.edu added the comment:
My last comment was merely reporting that this patch can break MinGW
based build processes. It did surprise some developers that their
programs embedding matplotlib, which is now build with the MSVC9 patch,
stopped working
Christoph Gohlke cgoh...@uci.edu added the comment:
Apparently the msvc9compiler_stripruntimes_regexp2 patch causes problems
for MinGW users. The following C program is using the Python C API to
import the testpyd extension generated by testpyd.py. When compiled with
MinGW, the program fails
Christoph Gohlke cgoh...@uci.edu added the comment:
There are two levels of testing.
First, on a Windows development system with Visual Studio 2008, Python
2.6.2+, and the msvc9compiler_stripruntimes_regexp2.diff patch applied,
verify that the embedded manifest in distutil generated PYD
Christoph Gohlke cgoh...@uci.edu added the comment:
This patch also removes empty dependentAssembly elements after removing
the VC.CRT assemblyIdentity element.
It seems not enough to just place the Microsoft.VC90.CRT.manifest and VC
runtime DLL files into the Python folder. On a system without
Christoph Gohlke cgoh...@uci.edu added the comment:
The attached patch uses a regular expression.
--
Added file:
http://bugs.python.org/file15072/msvc9compiler_stripruntimes_regexp.diff
___
Python tracker rep...@bugs.python.org
http
Christoph Gohlke cgoh...@uci.edu added the comment:
There are two easy to fix issues with the
msvc9compiler_stripruntimes.diff patch: 1) the dependency for 64-bit
VC90.CRT is not removed and 2) the VC90.CRT dependency is removed also
from executables, which will fail to run. A revised patch
New submission from Christoph Gohlke cgoh...@uci.edu:
On Windows Vista 64-bit, when running Python 2.6.2 (32 or 64 bit) from a
network share, e.g. \\Server\Share\python26\python.exe,
importing Tkinter fails with WindowsError: [Error 3] The system cannot
find the path specified. See session
96 matches
Mail list logo
