[ python-Bugs-1723338 ] Crash in ctypes callproc function with unicode string arg
Bugs item #1723338, was opened at 2007-05-22 10:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1723338&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Colin Laplace (claplace) Assigned to: Nobody/Anonymous (nobody) Summary: Crash in ctypes callproc function with unicode string arg Initial Comment: I've recently came to a bug using ctypes. I was using ctypes to call a syscall and and passing it a string argument, which was in fact in unicode. This resulted in a python crash in the callproc function. You can easily reproduce the crash by launching the attached python file (or at this link: https://core.fluendo.com/elisa/trac/browser/branches/rewrite-1/elisa/extern/inotify.py ) tested with python 2.5 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1723338&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-832159 ] C++ extensions using SWIG and MinGW
Bugs item #832159, was opened at 2003-10-29 04:27 Message generated for change (Comment added) made by dobesv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832159&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: Python 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Allen Chan (alydar) Assigned to: Nobody/Anonymous (nobody) Summary: C++ extensions using SWIG and MinGW Initial Comment: Using the following three files: -- begin files - /* hello.cpp */ #includevoid hello() { printf("hello world\n"); } -- /* hello.i */ %module hello extern void hello(); -- # setup.py import distutils from distutils.core import setup, Extension setup(name = "Hello World", version = "1.0", ext_modules = [Extension("_hello", ["hello.i","hello.cpp"])]) -- end files --- executing the command: "python setup.py build_ext -cmingw32 --swig-cpp -f" creates the following output: -- begin output -- running build_ext building '_hello' extension swigging hello.i to hello_wrap.cpp ... [ snipped ] ... cc -mno-cygwin -shared -s build\temp.win32-2.3 \Release\hello_wrap.o build\temp.w in32-2.3\Release\hello.o build\temp.win32-2.3 \Release\_hello.def -LC:\p\Python23 \libs -LC:\p\Python23\PCBuild -lpython23 -o build\lib.win32-2.3\_hello.pyd error: command 'cc' failed: No such file or directory -- end output -- It appears that unixccompiler.py defaults compiler_cxx to use "cc" and then uses it for the linking, and cygwinccompiler.py does not override the compiler_cxx entry. If the self.set_executable() call in the __init__*( function of the Mingw32Compiler class also sets compiler_cxx to use "g++", then the extension build will work. -- Comment By: Dobes V (dobesv) Date: 2007-05-22 17:18 Message: Logged In: YES user_id=400635 Originator: NO Here's a workaround I used to fix the linker: # Force g++ for linking import distutils.sysconfig old_customize_compiler = distutils.sysconfig.customize_compiler def customize_compiler(compiler): old_customize_compiler(compiler) if compiler.compiler_type == 'mingw': compiler.set_executables(linker_so='g++ -mno-cygwin -shared') distutils.sysconfig.customize_compiler = customize_compiler You could also override the compiler, too. -- Comment By: Kef X-Schecter (furrykef) Date: 2004-08-20 17:26 Message: Logged In: YES user_id=536129 ARGH! This bug is still in Python 2.3.4 and should have been fixed A LONG TIME AGO! What am I supposed to do, have my users fix their distutils by hand? Sorry to be so gripy, but jeez. It tells you how to freaking fix it... -- Comment By: David S. Rushby (woodsplitter) Date: 2004-02-11 23:18 Message: Logged In: YES user_id=414645 I also encountered this bug while trying to build a C++ extension with no SWIG involved. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832159&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1028697 ] Problem linking on windows using mingw32 and C++
Bugs item #1028697, was opened at 2004-09-15 17:28 Message generated for change (Comment added) made by dobesv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1028697&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: Python 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Steve Menard (devilwolf) Assigned to: Nobody/Anonymous (nobody) Summary: Problem linking on windows using mingw32 and C++ Initial Comment: When create a python extension in C++ and using ming32 to compile it, distutil will try to use 'cc' as the linker. The problem is that the CCompiler.link() method will substitude the linker it has found in linker_exe or linker_so with the first part of compiler_cxx. (lines 175-176) So adding the following line to Mingw32Compiler, near line 296 compiler_cxx='g++ -mno-cygwin -O -Wall', Fixes it for me. Quickly looking at the CygwinCompiler indicates it would suffer from he same problem. -- Comment By: Dobes V (dobesv) Date: 2007-05-22 19:30 Message: Logged In: YES user_id=400635 Originator: NO This is a duplicate of 832159. See the comments in that one for a workaround that doesn't require patching your distutils sources. Note that for cygwin, you can set some environment variables to change the compiler/linker. This doesn't work in mingw32 due to a bug in distutils. -- Comment By: Steve Menard (devilwolf) Date: 2004-09-18 17:54 Message: Logged In: YES user_id=423569 Indeed it does seem identical to http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=877165 thanks. -- Comment By: David S. Rushby (woodsplitter) Date: 2004-09-17 16:15 Message: Logged In: YES user_id=414645 Is this a duplicate of the following two bug reports? http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=877165 http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=832159 The first of those two was closed with a notice that the patch is in CVS; the second is still open. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1028697&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1721890 ] IDLE hangs in popup method completion
Bugs item #1721890, was opened at 2007-05-19 13:23 Message generated for change (Settings changed) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721890&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.5 Status: Open Resolution: None >Priority: 6 Private: No Submitted By: Andy Harrington (andyharrington) >Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE hangs in popup method completion Initial Comment: import os os. After entering the above code in a new idle editor window, the popup method completion window appears. If I navigate with the down-arrow key, the list starts scrolling fine all the way down to spawnv, which I can select, but if I try to use down-arrow once more and scroll the list (to what would be startfile if I could reach it), idle hangs. Pure pagedown works all the way to in the popup to write, but then it I use up-arrow idle hangs when I try to scroll up beyond startfile to what would be spawnv. I am running Windows XP, service pack 2. On May 5 I installed and am running python-2.5.1.msi. I started idle form idle.bat while in the idlelib directory. I also ran \Python25\Lib\idlelib\idle.pyw from other directories with the same result. I have no such problem with modules os.path or string. I did not think of a module to try which has a list of methods as long as os. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721890&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1721083 ] Add File - Reload
Feature Requests item #1721083, was opened at 2007-05-17 22:15 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1721083&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Raymond Hettinger (rhettinger) Assigned to: Kurt B. Kaiser (kbk) Summary: Add File - Reload Initial Comment: When using CVS or SVN, it is common to revert or merge a file that is open in the editor. It would be great to have a reload/refresh option on the menu to bring in the changed file. Without that option, the only approach is to close without saving, fire-up the editor again, and reload the file manually. -- >Comment By: Kurt B. Kaiser (kbk) Date: 2007-05-22 19:18 Message: Logged In: YES user_id=149084 Originator: NO But isn't this an example of a bell/whistle which is outside IDLE's design policies? It would add a menu item which would be rather rarely used, especially by beginners, it seems to me. Why not just close the edit window (not IDLE) and re-open using the Files / Recent Files feature? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1721083&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1723875 ] inspect.formatargspec last argument ignored
Bugs item #1723875, was opened at 2007-05-23 00:46
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1723875&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Patrick Dobbs (patrickcd)
Assigned to: Nobody/Anonymous (nobody)
Summary: inspect.formatargspec last argument ignored
Initial Comment:
from: [EMAIL PROTECTED]
The last argument of inspect.formatargspect() is a function to control the way
the entire returned string is formatted:
...join=joinseq):
joinseq being a function at line 757 in inspect.py
However, this argument is ignored and joinseq is not called.
The line in question is inspect.py 794 it was:
return '(' + string.join(specs, ', ') + ')'
The function seems to work as advertised if this line is replaced by:
return join(specs)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1723875&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1721372 ] emphasize iteration volatility for set
Bugs item #1721372, was opened at 2007-05-18 10:10 Message generated for change (Comment added) made by aisaac0 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721372&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Closed Resolution: Rejected Priority: 5 Private: No Submitted By: Alan (aisaac0) Assigned to: Nobody/Anonymous (nobody) Summary: emphasize iteration volatility for set Initial Comment: For http://docs.python.org/lib/types-set.html>, append the following new sentence to the 2nd paragraph. Iteration over a set returns elements in an indeterminate order, which generally depends on factors outside the scope of the containing program. *Justification:* users should not be expected to understand without being told that iteration order depends on factors outside the scope of the containing program. (Additionally, unlike the documentation for dictionaries, the documentation for sets fails to give a serious warning not to rely on iteration order.) -- >Comment By: Alan (aisaac0) Date: 2007-05-22 22:01 Message: Logged In: YES user_id=1025672 Originator: YES Martin's preceding comment asks: "How else could you interpret 'unordered collection' but as 'having arbitrary order'?" This question seems to me to read into the docs much that is not there. There are so many possibilities ... Keep in mind that I proposed a docs patch believing that the docs should communicate to users that a particular iteration on a set may produce a different order of elements on *sequential* runs of an *unchanged* source. Martin been claiming that the docs do communicate this (although he has been somewhat vague about the target audience). Here is a simple description of a class whose instances are plausibly considered an "unordered collection" that would not have that "volatility" property. (The question here should not whether this is a silly class but whether Martin is actually drawing a valid inference from the existing docs rather than just reading his experience into them.) Call the class ``Silly``. Initialize a Silly instance with an empty list and a deterministically seeded instance of random.Random. A Silly instance has an ``add`` method that computes the length of its list N and picks an insertion point for the new item using randrange(N+1). (If you want a Silly instance to behave more like a set, we can insert an element only if it's not in the list.) Iteration on this object is to be iteration on its list, but no indexing or slicing is to be provided. A ``Silly`` instance is plausibly an 'unordered collection' that is iterable but does NOT have the "volatility" property under discussion. -- Comment By: Martin v. Löwis (loewis) Date: 2007-05-22 00:22 Message: Logged In: YES user_id=21627 Originator: NO aisaac0: The first sentence of types-set says "A set object is an unordered collection of immutable values." How else could you interpret "unordered collection" but as "having arbitrary order"? -- Comment By: Alan (aisaac0) Date: 2007-05-21 22:27 Message: Logged In: YES user_id=1025672 Originator: YES Note that on c.l.python, Raymond Hettinger justifies this rejection as follows: "the docs are sufficient when they say that set ordering is arbitrary" Where exactly do the docs say this? I do not see it. I am looking here: http://docs.python.org/lib/types-set.html> I also take this as a concession that the docs *should* say something like this, which is about half of the language I proposed (unless there is some reason why 'arbitrary' is superior to 'indeterminate'). Btw, I did provide the source code to several people before Peter. This was clear in the thread on c.l.python. I do not think they would appreciate being called "not experienced". -- Comment By: Martin v. Löwis (loewis) Date: 2007-05-19 16:29 Message: Logged In: YES user_id=21627 Originator: NO aisaac0, thanks for elaborating. Your remark now convinces me that it was the right thing to reject this change. Ite seems that you suggest that experienced users a) are aware that some objects compare and hash by their id(), and b) that the id() is the address in memory, and c) that the id() will influence the order in which objects are iterated, and d) fail to see that the id() may differ across runs Such users are *not* experienced. There are many more reasons why the id of an object may vary across runs. E.g. Linux 2.6 deliberately randomizes memory management, so that identical processes get their objects allocated at different addres
[ python-Bugs-1723338 ] Crash in ctypes callproc function with unicode string arg
Bugs item #1723338, was opened at 2007-05-22 03:43 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1723338&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Colin Laplace (claplace) >Assigned to: Thomas Heller (theller) Summary: Crash in ctypes callproc function with unicode string arg Initial Comment: I've recently came to a bug using ctypes. I was using ctypes to call a syscall and and passing it a string argument, which was in fact in unicode. This resulted in a python crash in the callproc function. You can easily reproduce the crash by launching the attached python file (or at this link: https://core.fluendo.com/elisa/trac/browser/branches/rewrite-1/elisa/extern/inotify.py ) tested with python 2.5 -- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-05-22 21:06 Message: Logged In: YES user_id=33168 Originator: NO Thomas, could you take a look? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1723338&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
