[issue36392] IPv4Interface Object has no attributte prefixlen
Václav Šmilauer added the comment: This one works: addr.network.prefixlen. It took me a while to find out; I find the documentation somewhat confusing in this point. -- nosy: +eudoxos ___ Python tracker <https://bugs.python.org/issue36392> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18654] modernize mingw&cygwin compiler classes
Václav Šmilauer added the comment: Ping? Roumen has been updaing the patch for one year and no reaction. Is there something which can be done? -- nosy: +eudoxos ___ Python tracker <http://bugs.python.org/issue18654> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18397] Python with MinGW
Václav Šmilauer added the comment: @David & others: mingw build is covered in detail under issue17605 by Roumen Petrov. -- nosy: +eudoxos ___ Python tracker <http://bugs.python.org/issue18397> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16633] os.environ updates only one copy of env vars under Windows (GetEnvironmentVariable vs. getenv)
Václav Šmilauer added the comment: I checked on Windows 7 64bit with python 2.7 (sorry, not python 3.3 installed here) with the script attached. Each line sets a variable using the method in the very left column, then it attempts to read it back using all methods. os.environ win32 os.?etenv msvcrt msvcr? os.environ OK OK OK -- -- win32 -- OK -- -- -- os.?etenv -- OK -- -- -- msvcrt -- OK -- OK -- msvcr? -- OK -- -- -- Methods which can read back what they also set are os.environ, win32api, msvcrt. OTOH, msvcr? (which is ctypes.util.find_msvcr(), in my case msvcr90.dll) does not read its own values, just like os.getenv/os.putenv. It *seems* that reading with win32 API is very reliable (that is not a good news for writing cross-platform extension modules), though, but perhaps it just asks the CRT if it does not find the variable defined (my testing did not go that far). @Andrew: you're probably right, though it does not explain, why msvcr90.dll does not read back the values I set in there - that is the CRT python27.dll itself links to -- -- Added file: http://bugs.python.org/file28243/tryenv2.py ___ Python tracker <http://bugs.python.org/issue16633> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16633] os.environ updates only one copy of env vars under Windows (GetEnvironmentVariable vs. getenv)
New submission from Václav Šmilauer:
On windows, environment variables exist in two copies: one is manipulated using
win32 API (GetEnvironmentVariable, SetEnvironmentVariable), and another one is
maintained by the C runtime (getenv, _putenv). This is explained in more depth
in [1].
os.environ manipulates win32 environment variables, but *not* those seen by the
CRT. This means that if I set an environment variable using os.environ and
later read it, in the same process, using getenv in an extension module, it
will not give the expected result. Child processes *do* see those vars in CRT,
since it is copied over from the win32 version at process startup.
Setting env vars has legitimate uses, since it is one of the few ways to
influence initialization of extension modules: for instance, setting
OMP_NUM_THREADS sets number of threads for OpenMP runtime (which cannot be
changed once the module using it is loaded).
It would be ideal to keep both CRT and win32 env vars in sync transparently. If
that is not realistically achievable, this gotcha should be documented as a
warning in the os.environ documentation.
A workaround to this problem to set variables in both win32 and CRT using
something like
import ctypes, ctypes.util, os.environ
ctypes.cdll[ctypes.util.find_msvcrt()]._putenv("%s=%s"%(name,value))
os.environ[name]=value
[1]
http://msmvps.com/blogs/senthil/archive/2009/10/13/when-what-you-set-is-not-what-you-get-setenvironmentvariable-and-getenv.aspx
--
assignee: docs@python
components: Documentation
messages: 177081
nosy: docs@python, eudoxos
priority: normal
severity: normal
status: open
title: os.environ updates only one copy of env vars under Windows
(GetEnvironmentVariable vs. getenv)
type: behavior
versions: Python 2.7, Python 3.3
___
Python tracker
<http://bugs.python.org/issue16633>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16472] Distutils+mingw links agains msvcr90, while python27.dll is linked agains msvcrt
Václav Šmilauer added the comment: I was having a compiled module consistently crash at import time when linking against msvcr90, and being imported fine when linked against msvcrt. I will try to investigate further with mingw folks. -- ___ Python tracker <http://bugs.python.org/issue16472> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16472] Distutils+mingw links agains msvcr90, while python27.dll is linked agains msvcrt
Václav Šmilauer added the comment: I am sorry for the initial confusion. python27.dll is really linked against MSVCR90. Its path, though, is c:\windows\winsxs\amd64_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4940_none_08e4299fa83d7e3c\MSVCR90.DLL, and perhaps is a different one found at runtime? Dependency walker also reveals, that python27.dll links against SHELL32, which itself links to MSVCRT. PS I am using the offical build of 2.7.3 on Windows7 64bit. -- ___ Python tracker <http://bugs.python.org/issue16472> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16472] Distutils+mingw links agains msvcr90, while python27.dll is linked agains msvcrt
New submission from Václav Šmilauer:
Compiling an extension with --compiler=mingw32 with official python 2.7.3
distribution on Windows (64bit) leads to unusable result - crash on module load
("invalid access to memory").
The reasons is that Lib/distutils/cygwincompiler.py#l62 links the resulting
.pyd file against msvcr90.dll (version is determined by version of MSVC used to
build python itself), while python27.dll is linked against msvcrt.dll (shows
the Dependency Walker).
Based on my own experience (above) and MSDN docs
http://msdn.microsoft.com/en-us/library/abx4dbyh.aspx,
http://msdn.microsoft.com/en-us/library/ms235460.aspx), loading 2 different
runtimes is asking for trouble.
I raised this topic on distutils-sig, hoping for an explanation. Judging by the
reaction, it is quite possibly historical relict which is no longer needed.
This is also hinted at by comments at the beginning of
Lib/distutils/cygwincompiler.py
"if you use a msvc compiled python version (1.5.2)"
"mingw gcc 3.2/ld 2.13 works"
I am aware of distutils being frozen for new features (unless you want to call
bugfix a new feature).
--
assignee: eric.araujo
components: Distutils
messages: 175569
nosy: eric.araujo, eudoxos, tarek
priority: normal
severity: normal
status: open
title: Distutils+mingw links agains msvcr90, while python27.dll is linked
agains msvcrt
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue16472>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11566] hypot define in pyconfig.h clashes with g++'s cmath
Václav Šmilauer added the comment: Martin, I know it is not a proper fix. OTOH, Python is not the only project which "recommends" its header be included as first. I don't know if it is an issue for Python 3.x; will try to test that. This bug, though, is clearly reported about Python 2.7, which IS in bug-fix mode. -- ___ Python tracker <http://bugs.python.org/issue11566> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16421] importlib.machinery.ExtensionFileLoader cannot load several modules from the same shared object
Václav Šmilauer added the comment: Good, will let editors do that next time. I was following http://docs.python.org/devguide/patch.html#preparation which says "Sixth, if you are not already in the Misc/ACKS file then add your name." For NEWS, I was reading http://docs.python.org/devguide/committing.html#news-entries, but it is true it talks about commits, not about patches. -- ___ Python tracker <http://bugs.python.org/issue16421> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16421] importlib.machinery.ExtensionFileLoader cannot load several modules from the same shared object
Václav Šmilauer added the comment: Attaching patch based on Andrew's review, agains latest hg (80291:859ef54bdce). For the MSVC files, I copied what was there for _testcapimodule in PC/VS9.0 and PCbuild, and created two new UUIDs: one for _testimportmultiple itself (36D0C52C-DF4E-45D0-8BC7-E294C3ABC781; used in .sln, .vcproj and .vcxproj files), and one for _testimportmultiple.vcxproj.filters (1ec38ad9-1abf-4b80-8628-ac43ccba324b; used only once). Please check that I did that correctly. (I am wondering how can one maintain such a build system.) I also added myself to Misc/ACKS (and sent contributor agreement by mail), added the entry to Misc/NEWS. -- components: +Extension Modules -Interpreter Core type: enhancement -> behavior versions: +Python 3.5 -Python 3.4 Added file: http://bugs.python.org/file27918/many-modules-in-one-so_3.diff ___ Python tracker <http://bugs.python.org/issue16421> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16421] importlib.machinery.ExtensionFileLoader cannot load several modules from the same shared object
Václav Šmilauer added the comment: I added the test, with a module Modules/_testimportmultiple.c. The test uses the (undocumented) imp module, but all othet tests in Lib/test/test_imp.py do the same, so I assume it is OK? -- Added file: http://bugs.python.org/file27911/many-modules-in-one-so_2.diff ___ Python tracker <http://bugs.python.org/issue16421> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16194] imp.load_dynamic imports wrong module when called several times on a multi-module .so
Václav Šmilauer added the comment: issue16421 was opened for py3k. Just for the sport of writing, I fixed that in python 2.7 (tip) as well, though other seemed to defend the view it was not a bug, hence not fixable in 2.7. -- keywords: +patch versions: -Python 3.2, Python 3.3 Added file: http://bugs.python.org/file27910/py2_many-modules-in-one-so_1.diff ___ Python tracker <http://bugs.python.org/issue16194> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16421] importlib.machinery.ExtensionFileLoader cannot load several modules from the same shared object
Václav Šmilauer added the comment: @Andrew: I was using symlinks to achieve this, until I found recently that some exotic systems (read: windows) have still troubles there, like not letting non-admins create symlinks. -- type: enhancement -> behavior versions: +Python 3.5 -Python 3.4 ___ Python tracker <http://bugs.python.org/issue16421> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16421] importlib.machinery.ExtensionFileLoader cannot load several modules from the same shared object
Changes by Václav Šmilauer : -- components: +Interpreter Core -Extension Modules versions: +Python 3.4 -Python 3.5 ___ Python tracker <http://bugs.python.org/issue16421> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16421] importlib.machinery.ExtensionFileLoader cannot load several modules from the same shared object
Václav Šmilauer added the comment: Storing several modules in one .so file offloads some issues which have to be dealt with manually (like one module needing symbols from other module, or even cross-dependencies) to the linker. In any case, unless forbidden and signalled, it should be supported. I set version to 3.4 and component to "Interpreter core", as you suggested, it is probably more appropriate. How do I write test which requires a custom module to be compiled? -- ___ Python tracker <http://bugs.python.org/issue16421> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16421] importlib.machinery.ExtensionFileLoader cannot load several modules from the same shared object
New submission from Václav Šmilauer: This issue was split off issue16194 (I am not copying the whole discussion here). It was suggested a new issue is opened for Python3, where a proper fix can be done. Python internally caches dynamically loaded modules, but the cache is based on the filename only. If one file contains several modules, only the first of them is imported and initialized properly. This interface was previously exposed via imp.load_dynamic, the same codepath is used by importlib.machinery.ExtensionFileLoader now. A solution is to cache by the (filename, modulename) tuple, which avoids any ambiguity. I am attaching a simple patch for that, agains current hg tip (80272:ec00f8570c55), and tested with the scripot attached to issue16194. I have not modified the test suite, I am not sure whether testing compiled modules is actually supported (did not see any compiled files in there), I will be glad for help. -- components: Extension Modules files: many-modules-in-one-so_1.diff keywords: patch messages: 174967 nosy: Arfrever, amaury.forgeotdarc, brett.cannon, docs@python, eudoxos, ncoghlan, r.david.murray priority: normal severity: normal status: open title: importlib.machinery.ExtensionFileLoader cannot load several modules from the same shared object type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file27909/many-modules-in-one-so_1.diff ___ Python tracker <http://bugs.python.org/issue16421> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11566] hypot define in pyconfig.h clashes with g++'s cmath
Václav Šmilauer added the comment: Just for the record: a workaround (mentioned at http://boost.2283326.n4.nabble.com/Boost-Python-Compile-Error-s-GCC-via-MinGW-w64-td3165793.html#a3166760) is to always include before . -- ___ Python tracker <http://bugs.python.org/issue11566> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11566] hypot define in pyconfig.h clashes with g++'s cmath
Václav Šmilauer added the comment: I would like to second Ralf here. I am having the same issue with mingw's gcc 4.7 and -std=c++11. -- nosy: +eudoxos ___ Python tracker <http://bugs.python.org/issue11566> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16194] imp.load_dynamic imports wrong module when called several times on a multi-module .so
Václav Šmilauer added the comment: Yes, that's what I suggested at the end of msg172656 - including modulename in the key. Brett, would it be OK if I make patch against 3.3 (or head, if you prefer) to key by (modulename,filename) for compiled modules? I had a look at importlib.machinery.ExtensionFileLoader and it will suffer from the same issue. Should I open a separate bug for the post-3.3 patch, and keep this as documentation bug for 2.7? -- ___ Python tracker <http://bugs.python.org/issue16194> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16194] imp.load_dynamic imports wrong module when called several times on a multi-module .so
Václav Šmilauer added the comment: I did not notice it was not documented in python 3.3 anymore -- my fault, sorry. In case there is no functional replacement for it, I will try to raise it on the ML. I am currently writing some code in 2.7 which relies on it (I don't see another way of packing multiple compiled modules into one file without using symlinks, which won't work under windows; it saves me lots of trouble with cross-module symbol dependencies and such, avoids RTLD_GLOBAL, rpath and such nasty stuff), and don't want to throw it away with future migration to 3k. -- ___ Python tracker <http://bugs.python.org/issue16194> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16194] imp.load_dynamic imports wrong module when called several times on a multi-module .so
Václav Šmilauer added the comment:
I found the cause of the behavior (perhaps it is common knowledge, but I am new
to python source); imp.load_dynamic calls the following functions
Python/import.c: imp_load_dynamic
(http://hg.python.org/cpython/file/ad51ed93377c/Python/import.c#l1777)
Python/importdl.c: _PyImport_LoadDynamicModule
(http://hg.python.org/cpython/file/ad51ed93377c/Python/importdl.c#l23)
Python/import.c: _PyImport_FindExtensionObject
(http://hg.python.org/cpython/file/ad51ed93377c/Python/import.c#l525)
where the last one uses the extensions object
(http://hg.python.org/cpython/file/ad51ed93377c/Python/import.c#l32), which is
explained at http://hg.python.org/cpython/file/ad51ed93377c/Python/import.c#l449
Magic for extension modules (built-in as well as dynamically
loaded). To prevent initializing an extension module more than
once, we keep a static dictionary 'extensions' keyed by module name
(for built-in modules) or by filename (for dynamically loaded
modules), containing these modules. A copy of the module's
dictionary is stored by calling _PyImport_FixupExtensionObject()
immediately after the module initialization function succeeds. A
copy can be retrieved from there by calling
_PyImport_FindExtensionObject().
The fact that extensions are keyed by file name explains why opening the .so
through symlink does not return the old extension object:
# foo.so
# bar.so -> foo.so (works for both symlinks and hardlinks)
imp.load_dynamic("foo","foo.so")
imp.load_dynamic("bar","bar.so") # will return the bar module
I will investigate whether marking the module as capable of multiple
initialization could be a workaround for the issue -- since the quoted comment
further says
(http://hg.python.org/cpython/file/ad51ed93377c/Python/import.c#l459):
Modules which do support multiple initialization set their m_size
field to a non-negative number (indicating the size of the
module-specific state). They are still recorded in the extensions
dictionary, to avoid loading shared libraries twice.
To fix the issue, I suggest that the *extensions* dict is keyed by
(filename,modulename) tuple for dynamically loaded modules. This would avoid
any ambiguity. Grepping through the code shows that the *extensions* object is
only accessed from Python/import.c, therefore regressions should be unlikely.
What do you think?
--
___
Python tracker
<http://bugs.python.org/issue16194>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16194] imp.load_dynamic imports wrong module when called several times on a multi-module .so
Václav Šmilauer added the comment: While I understand that this behavior went unnoticed for ages and can be seen therefore as unimportant, designating this as documentation bug is quite absurd; perhaps the following wording would be appropriate: .. note:: If this function is called multiple times on the same file (in terms of inode; symlink pointing to same file is fine), it will return the module which was first imported via `load_dynamic` instead of the requested module, without reporting any error. The previous call to `load_dynamic` may not be in the same part of the code, but it must happen within the same interpreter instance. -- components: +Library (Lib) -Documentation nosy: +ncoghlan ___ Python tracker <http://bugs.python.org/issue16194> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16194] imp.load_dynamic imports wrong module when called several times on a multi-module .so
Václav Šmilauer added the comment:
No, it is an old bug, since the behavior does something else than documented
(http://docs.python.org/library/imp.html#imp.load_dynamic) and reasonably
expected -- imp.load_dynamic("baz","foo.so") imports the "foo" module under
some circumstances.
--
type: enhancement -> behavior
versions: +Python 2.7 -Python 3.4
___
Python tracker
<http://bugs.python.org/issue16194>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16194] imp.load_dynamic imports wrong module when called several times on a multi-module .so
Václav Šmilauer added the comment: I tried with python 2.4.5 and 2.5.2 in chroot (using ubuntu hardy, which packaged both of them) and the result is exactly the same for both. I doubt I am able to install anything older in a sensible manner. -- status: pending -> open ___ Python tracker <http://bugs.python.org/issue16194> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16194] imp.load_dynamic imports wrong module when called several times on a multi-module .so
New submission from Václav Šmilauer:
I have several compiled modules linked into one .so file and import them using
imp.load_dynamic.
Only the first module imported with load_dynamic is imported properly, all
subsequent calls of load_dynamic on the same file ignore the first argument
(name) and return the first module again. The init function is also called only
for the first module imported by load_dynamic.
The bug is reproducible for python 2.7.3 and 3.2.2. Test case is attached.
Here inline simplified source for 2.7:
foo.c:
#include
#include
PyMODINIT_FUNC initfoo(){
(void) Py_InitModule("foo",NULL);
printf("initfoo()\n");
}
PyMODINIT_FUNC initbar(void){
(void) Py_InitModule("bar",NULL);
printf("initbar()\n");
}
PyMODINIT_FUNC initbaz(void){
(void) Py_InitModule("baz",NULL);
printf("initbaz()\n");
}
test.py:
import sys,imp
# import foo using the normal machinery
sys.path.append('.')
import foo
# this is OK
print imp.load_dynamic('bar','foo.so')
# this imports *bar* again, but should import baz
print imp.load_dynamic('baz','foo.so')
# this imports *bar* again, although the module is not defined at all
print imp.load_dynamic('nonsense','foo.so')
Compiled with
gcc -shared -fPIC foo.c -o foo.so `pkg-config python --cflags --libs`
I get when running "python test.py" output:
initfoo()
initbar()
The module 'bar' is imported 3 times, although the 2nd import should import
*baz* and the third import should fail ("nonsense" module does not exist).
--
components: Library (Lib)
files: load_dynamic-test.zip
messages: 172632
nosy: eudoxos
priority: normal
severity: normal
status: open
title: imp.load_dynamic imports wrong module when called several times on a
multi-module .so
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file27527/load_dynamic-test.zip
___
Python tracker
<http://bugs.python.org/issue16194>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3754] cross-compilation support for python build
Václav Šmilauer added the comment: Being a newcomer to this issue, I would like to ask for a brief summary about which parts of the patch are checked in for 3.3.0 and which are still to be applied. Roumen mentions #15483, #15484, #15268 and the ac_cv_thread in the previous post as mandatory and #15298 and #14598 as optional; can I add those as dependencies of this issue? python-py3k-20120607-CROSS.patch does not apply to 3.3.0 cleanly, but looking quickly at .rej files suggests that rejected hunks are those which were already merged for 3.3.0 final. Can someone confirm that? -- nosy: +eudoxos ___ Python tracker <http://bugs.python.org/issue3754> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
