[issue13260] distutils and cross-compiling the extensions
New submission from Alexander Myodov : I was recently trying to cross-compile several extensions (host: Linux, target: Win32) using mingw-gcc, and noticed that there is quite a little amount of changes needed to distutils code to at least make proper win32-compabible modules. Some of them require pretty noticeable functionality changes to distutils (like, adding a new option) thus they are unlikely a target for 2.7 anymore (though with some luck, any person who wants to follow my way and do cross-compilation, may just subclass the existing code). But some others are obvious bugs, and their fixes may still be useful for users stuck at 2.7. 1. (This is dubious but still is related to the problem, and was required to build some of the modules). "--include-dirs" and "--library-dirs" options to build_ext command support multiple paths separated by os.pathsep. For some reason (which I may be unaware of) "--libraries" option doesn't. A tiny fix just adds this support. 2. (more obvious issue) get_msvcr() function in distutils/cygwincompiler.py tries to guess the C runtime library which the target extension should link to. To do that, it tests the Python where the setup.py is *running* for what library it was linked to. But when the compilation target is Win32 but the compilation host is Linux, the hosts's Python won't contain such information. In this case, this function will return None. The result then gets assigned to self.dll_libraries (in an instance of CygwinCCompiler or Mingw32CCompiler), and gets used in a context which implies it is always an iterable (libraries.extend(self.dll_libraries)). These changes, together with altering or subclassing Mingw32CCompiler to use a different compiler name (like, "i586-mingw32msvc-gcc" instead of "gcc"), make it possible to cross-compile a number of extensions which were non-compileable before. -- assignee: tarek components: Distutils files: distutils.patch keywords: patch messages: 146340 nosy: amyodov, eric.araujo, tarek priority: normal severity: normal status: open title: distutils and cross-compiling the extensions versions: Python 2.7 Added file: http://bugs.python.org/file23514/distutils.patch ___ Python tracker <http://bugs.python.org/issue13260> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13268] assert
New submission from Alexander Myodov : The extended version of assert statement has a strange violation of documented behaviour. According to the http://docs.python.org/reference/simple_stmts.html#the-assert-statement, "assert expression1, expression2" should be equivalent to "if __debug__: if not expression1: raise AssertionError(expression2)". Nevertheless, it is not so for the following scenario: class A(object): def __str__(self): return "str" def __unicode__(self): return "unicode" def __repr__(self): return "repr" expression1 = False expression2 = (A(),) That is, when expression2 is a single-item tuple, assert statement prints the str-evaluation of the item itself, rather than of the tuple. This occurs in 2.x branch only, seems fixed in 3.x, and it would be great to have it backported for consistency. -- messages: 146434 nosy: amyodov priority: normal severity: normal status: open title: assert type: behavior versions: Python 2.6, Python 2.7 ___ Python tracker <http://bugs.python.org/issue13268> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13268] assert statement violates the documentation
Changes by Alexander Myodov : -- title: assert -> assert statement violates the documentation ___ Python tracker <http://bugs.python.org/issue13268> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9099] multiprocessing/win32: WindowsError: [Error 0] Success on Pipe()
Alexander Myodov added the comment: Sorry for being a little bit slow to respond... No I was not able to come up with a testcase that could generate this problem in a reproducible way on any Windows box I had. This problem sometimes occured on various OS versions, being probably a Windows oof configuration problem rather than the problem of the Python code itself. Nevertheless, changing it as I described above didn't cause any adverse side effects, at least for me. -- ___ Python tracker <http://bugs.python.org/issue9099> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8472] itertools.filterfalse() function missing
New submission from Alexander Myodov : The documentation (eg at http://docs.python.org/release/2.6.5/library/functions.html#filter) tells that there should be an itertools.filterfalse() function complementary to builtin filter() function, that returns the list of elements (instead of the iterator over them, as ifilterfalse() does), for which the condition is failed. This function is absent from Python 2.x branch (though obviously is present in 3.x, as all the i* functions are renamed to their non-i* counterparts). -- messages: 103733 nosy: honeyman severity: normal status: open title: itertools.filterfalse() function missing versions: Python 2.5, Python 2.6, Python 2.7 ___ Python tracker <http://bugs.python.org/issue8472> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8472] itertools.filterfalse() function missing
Changes by Alexander Myodov : -- type: -> behavior ___ Python tracker <http://bugs.python.org/issue8472> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8472] itertools.filterfalse() function missing
Alexander Myodov added the comment: In this case, I'd suggest to rephrase it to "See :func:`itertools.ifilterfalse` for the complementary function that returns the iterator over the elements of *iterable* for which *function* returns false.", or even remove this line at all (because, ifilterfalse() is a complement to ifilter() rather than to filter()). But please don't leave this as it is now, as this is still confusing and misleading (filter returns a list, but ifilter and ifilterfalse return an iterator!). -- status: closed -> open ___ Python tracker <http://bugs.python.org/issue8472> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6601] Fractions do not support other Fractions as numerators or denominators
New submission from Alexander Myodov : Occurs in 2.6, doesn't occur in 3.1. Example: Python 2.6.2+ (release26-maint, Jun 23 2009, 07:08:39) [GCC 4.3.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from fractions import Fraction >>> Fraction(Fraction(3,5), Fraction(1,2)) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.6/fractions.py", line 99, in __new__ numerator = operator.index(numerator) TypeError: 'Fraction' object cannot be interpreted as an index Compare: Python 3.1 (r31:73572, Jul 23 2009, 23:41:26) [GCC 4.3.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from fractions import Fraction >>> Fraction(Fraction(3,5), Fraction(1,2)) Fraction(6, 5) -- messages: 91088 nosy: honeyman severity: normal status: open title: Fractions do not support other Fractions as numerators or denominators type: behavior versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue6601> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6696] Profile objects should be documented
New submission from Alexander Myodov : Seems like a minor documentation issue in 2.x became more significant one in 3.x. In Python 2.6 (and lower), the documentation on Profile objects discussed them as a part of hotshot module, while omitting the fact that any profiler module, either of profile/cProfile/hotshot, supports them (though in fact, hotshot Profile objects have an api a bit different from profile/cProfile Profile objects). Note http:// docs.python.org/2.6/library/hotshot.html#profile-objects - there is no separate documentation of non-hotshot Profile objects, though they are largely similar. This is a minor issue which could probably be fixed in 2.7 as a separate problem - otherwise it is pretty unclear from the documentation, what methods do cProfile Profile objects support (eg, they support enable()/disable() and runcall() methods, which is pretty useful for profiling, but impossible to find in documentation). In Python 3.1, looks like everything related to hotshot was removed from the documents, including the documentation on Profile objects - which should not have been. This means, that now the documentation on profilers does not cover any Profile classes at all - see http:// docs.python.org/3.1/library/profile.html . For example, the official documentation doesn't say any way to profile a function passing arguments to it and receiving its result - while profile/cProfile Profile objects still do support runcall() method. -- assignee: georg.brandl components: Documentation messages: 91522 nosy: georg.brandl, honeyman severity: normal status: open title: Profile objects should be documented versions: Python 3.1 ___ Python tracker <http://bugs.python.org/issue6696> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9099] multiprocessing/win32:
New submission from Alexander Myodov : I am using Python 2.6.5/win32, and working with multiprocessing module, doing that with Python interpreter embedded using Cython (if that may be related to the problem). While creating a subprocess and a Pipe to communicate with it, I've got the following traceback (particulaly on the line "parent_conn, child_conn = Pipe()"): Traceback (most recent call last): File "test_fork.py", line 24, in init test_fork (test_fork.c:810) vasia.main() File "Z:\multiprocessing_cython_w32\vasia.py", line 15, in main parent_conn, child_conn = Pipe() File "Z:\python-win32\2.6.5\Lib\multiprocessing\__init__.py", line 106, in Pipe return Pipe(duplex) File "Z:\python-win32\2.6.5\Lib\multiprocessing\connection.py", line 202, in Pipe h2, win32.PIPE_READMODE_MESSAGE, None, None WindowsError: [Error 0] Success Lines 202-204 in multiprocessing/connection.py contain the following: win32.SetNamedPipeHandleState( h2, win32.PIPE_READMODE_MESSAGE, None, None ) It seems to me that for some reason SetNamedPipeHandleState might be returning 0 even while it didn't fail actually; a quick check confirmed that it could be fixed by changing the above lines to the following: try: win32.SetNamedPipeHandleState( h2, win32.PIPE_READMODE_MESSAGE, None, None ) except WindowsError, e: (win32) if e.args[0] != 0: # 0 is error code for SUCCESS raise -- components: Extension Modules, Windows messages: 108824 nosy: honeyman priority: normal severity: normal status: open title: multiprocessing/win32: type: behavior versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue9099> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9099] multiprocessing/win32: WindowsError: [Error 0] Success on Pipe()
Alexander Myodov added the comment: Sorry for formatting above, a copypaste issue. The lines 202-204: win32.SetNamedPipeHandleState( h2, win32.PIPE_READMODE_MESSAGE, None, None ) The change that fixes the problem (at least for me): try: win32.SetNamedPipeHandleState( h2, win32.PIPE_READMODE_MESSAGE, None, None ) except WindowsError, e: if e.args[0] != 0: # 0 is error code for SUCCESS raise -- title: multiprocessing/win32: -> multiprocessing/win32: WindowsError: [Error 0] Success on Pipe() ___ Python tracker <http://bugs.python.org/issue9099> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9122] Problems with multiprocessing, Python embedding and Windows
New submission from Alexander Myodov :
Hello,
I am using Python 2.6.5 and Cython (to embed the Python interpreter) to create
a simple launcher.exe launcher which then imports and uses the remaining logic
from the other modules, conveniently stored in a single modules.zip file (i.e.
importing from inside zip file). Such setup causes some issues when it comes to
the multiprocessing.
First of all, the __main__ module is built as a binary (via Cython->mingw), but
the stuff like freeze is not used. In multiprocessing/forking.py, when it comes
to determination of the primary path, there is a WINEXE variable which affects
the further processing. In its assignment, getattr(sys, 'frozen', False)
obviously results in False, causing the WINEXE variable be False too (though in
my case it is obviously wrong, the stuff like imp.is_builtin("__main__") shows
that the main module is indeed builtin). This is the first problem which
probably could be solved by adding an additional check for something like
imp.is_builtin("__main__") to WINEXE assignment.
Further, as the WINEXE is wrongly False, it causes the "if not WINEXE:" branch
to be processed, and adds the 'main_path' to the data, containing the name of
the .exe file.
On the forked side, d['main_path'] is received and parsed, and the name of the
.exe file is split out of its extension, and such name is attempted to be
imported, using imp.find_module/imp.load_module. The import fails, as there is
indeed no such files wildly lying around in the installation; on the other
hand, to get a quick fix of the problem, I thought of adding the appropriate
launcher.py(.pyo/.pyc) files into the modules.zip, so that they still could be
externally imported by the "launcher" name, even though it is already builtin
under the __main__ name; but the second problem is that the
imp.find_module/imp.load_module functions do not find the module inside the zip
files, like the import statement does.
--
components: Extension Modules, Windows
messages: 108953
nosy: honeyman
priority: normal
severity: normal
status: open
title: Problems with multiprocessing, Python embedding and Windows
versions: Python 2.6
___
Python tracker
<http://bugs.python.org/issue9122>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
