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/issue36
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 rep...@bugs.python.org
http://bugs.python.org/issue18654
Václav Šmilauer added the comment:
@David others: mingw build is covered in detail under issue17605 by Roumen
Petrov.
--
nosy: +eudoxos
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18397
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
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
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
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
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
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
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
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
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
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
Changes by Václav Šmilauer e...@doxos.eu:
--
components: +Interpreter Core -Extension Modules
versions: +Python 3.4 -Python 3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16421
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
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
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
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 cmath before Python.h.
--
___
Python
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 rep...@bugs.python.org
http://bugs.python.org/issue11566
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
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
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
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
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
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
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
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
27 matches
Mail list logo
