[issue7751] urllib.urlopen("///C|/foo/bar/spam.foo") IOError: [Errno 22]

Christoph Gohlke 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-in-windows.aspx http://www.

[issue7930] pydoc.stripid doesn't strip ID in py25, py26, py31

Ezio Melotti added the comment: Here's a patch with a minimal unittest. -- keywords: +easy, needs review, patch stage: test needed -> patch review versions: -Python 2.5 Added file: http://bugs.python.org/file16229/issue7930.patch ___ Python tracker

[issue7751] urllib.urlopen("///C|/foo/bar/spam.foo") IOError: [Errno 22]

Éric Araujo added the comment: Hello I’m no expert on Python bugs, but I believe a test for the fixed behavior would improve your patch. Maybe a link to some documentation in a comment (or in an entry in Misc/NEWS) too. Regards -- nosy: +merwok _

[issue7846] Fnmatch cache is never cleared during usage

Éric Araujo added the comment: Hello The feature seems useful to me and the patch straightforward. I wonder why you used a global name for the max length (“_MAXCACHE”) instead of inlining the value where it is used. Does it feel more constanty? ;) I fear that the leading underscore won’t dis

[issue7931] Interpreter does not terminate if daemonized while running multithreaded

Changes by Nikolaus Rath : -- title: Python hangs after last thread has exited -> Interpreter does not terminate if daemonized while running multithreaded ___ Python tracker ___

[issue7931] Python hangs after last thread has exited

Nikolaus Rath added the comment: Here is a short testcase that reproduces the problem. If you run the script it daemonizes correctly, but then the daemon does not terminate but hangs forever. The crucial part seems to be to daemonize the program while there is more than one thread running.

[issue7936] sys.argv contains only scriptname

JT Johnson added the comment: Sorry for a double-comment, but I thought of posting this after I already submitted the last one and I found no edit button. Here's some output: "Microsoft Windows [Version 6.0.6001] Copyright (c) 2006 Microsoft Corporation. All rights reserved. C:\Users\JT>asso

[issue7936] sys.argv contains only scriptname

JT Johnson added the comment: Actually, I was playing around with it and I found that using the "python" command before it does work. Now, when I type what you said to do, it shows that there is no association, even though i can run a program without the python command. This is quite strange..

[issue7938] makesetup interprets macros -DA=B as a Make variable definition

New submission from Willem de Bruijn : (this is very low priority: an issue in a nonstandard build) I am porting Python 2.6.4 to a system with only partial Posix support that requires static linking for all modules. To enable sqlite, I added the line _sqlite3 _sqlite/cache.c _sqlite/connectio

[issue4639] Build failure on OpenBSD 4.4-current regarding lstat()

Stefan Krah added the comment: This is fixed in trunk by the configure.in patch. I've tested trunk on 4.4 and 4.7. -- nosy: +skrah ___ Python tracker ___

[issue4639] Build failure on OpenBSD 4.4-current regarding lstat()

Martin v. Löwis added the comment: Can you please try the Python trunk (or release26-maint branch) and report whether the problem still occurs? -- nosy: +loewis ___ Python tracker _

[issue6375] compile failure in Modules/python.c

Martin v. Löwis added the comment: Closing this as unreproducible. -- resolution: -> works for me status: open -> closed ___ Python tracker ___ _

[issue7903] Configure script incorrect for reasonably recent OpenBSD

Martin v. Löwis added the comment: Thanks for the tests, and the patch. Committed as r78202, r78203, r78204, and r78205. -- resolution: -> fixed status: open -> closed ___ Python tracker _

[issue7903] Configure script incorrect for reasonably recent OpenBSD

Stefan Krah added the comment: On OpenBSD the ncurses.h header has been broken for quite some time, see e.g. http://bugs.python.org/issue1244610. The problem is that when _XOPEN_SOURCE_EXTENDED is defined, wchar_t is defined twice. I can confirm that it is still broken on 4.6, but it appears tha

[issue7932] print statement delayed IOError when stdout has been closed

tholzer added the comment: This is not quite correct: The following 2 lines fail as expected (unbuffered): python -u -c 'import sys; print >> sys.stdout, "x"' 1>&- ; echo $? python -u -c 'import sys; print >> sys.stderr, "x"' 2>&- ; echo $? whereas in the following example, the first comman

[issue7173] Cython compiler run crashes CPython 3.1.1 and 3.2

Antoine Pitrou added the comment: > Is it normal that even after the call to next(), the generator frame > contains a reference to the RuntimeError? As long as it's executing the generator it's quite normal. The generator must be able to restore the caller's RuntimeError when interrupted by a

[issue7173] Cython compiler run crashes CPython 3.1.1 and 3.2

Amaury Forgeot d'Arc added the comment: Is it normal that even after the call to next(), the generator frame contains a reference to the RuntimeError? Long explanation: - When the function exits, there is a cycle [parent frame]-> ['it' variable]-> [generator frame]-> [RuntimeError]-> [parent

[issue7936] sys.argv contains only scriptname

New submission from JT Johnson : I am running Python 2.6.4 on Windows Vista and when I try to get any command line arguments via sys.argv, it only contains sys.argv[0], but nothing else. Even if I supply several parameters. The only third-parts modules I am using are Pygame, but even before Py

[issue7903] Configure script incorrect for reasonably recent OpenBSD

Martin v. Löwis added the comment: Stefan, what ncurses problem are you referring to? I quite object to working around OpenBSD limitations, and would rather hope that OpenBSD fixes their POSIX support at some point. -- ___ Python tracker

[issue7903] Configure script incorrect for reasonably recent OpenBSD

Stefan Krah added the comment: In my testing of issue 3920 I missed that the original approach also fixed the ncurses.h problem, so it should be preferred over bsd3.diff. I attach a patch that reverts the recent commit and extends the xopen_source=no up to version 4.9. I've tested it on 4.4 and

[issue7935] Cross-reference ast.literal_eval() from eval() docs

New submission from Kent Johnson : eval() is a known security hole. Since Python 2.6 ast.literal_eval() provides a better alternative in many cases. literal_eval() is not as well known as eval() and not easy to find even if you know it exists (but don't remember the name). eval() comes up over

[issue7173] Cython compiler run crashes CPython 3.1.1 and 3.2

Antoine Pitrou added the comment: > I tried several times to debug it myself, but I don't understand the > exception cleanup macros in ceval.c (UNWIND_EXCEPTION_HANDLER and > friends, new in Py3). If someone can get me set up to debug them, I > can give it another shot. I assume there are a coup

[issue7173] Cython compiler run crashes CPython 3.1.1 and 3.2

Stefan Behnel added the comment: I tried several times to debug it myself, but I don't understand the exception cleanup macros in ceval.c (UNWIND_EXCEPTION_HANDLER and friends, new in Py3). If someone can get me set up to debug them, I can give it another shot. I assume there are a couple of

[issue1652] subprocess should have an option to restore SIGPIPE to default action

Antoine Pitrou added the comment: I think restore_sigpipe=True would be a reasonable default. As RDM says, adding an unit test would be better, but it may be difficult to do so (we probably can't spawn Python itself since it will change the default SIGPIPE handler at startup). Looking at the p

[issue7930] pydoc.stripid doesn't strip ID in py25, py26, py31

Ezio Melotti added the comment: This is the stripid implementation: _re_stripid = re.compile(r' at 0x[0-9a-f]{6,16}(>+)$', re.IGNORECASE) def stripid(text): """Remove the hexadecimal id from a Python object representation.""" # The behaviour of %p is implementation-dependent in terms of

[issue7903] Configure script incorrect for reasonably recent OpenBSD

Martin v. Löwis added the comment: This issue is now superseded by issue 3920. It would be good if somebody could confirm that the approach taken for 4.4 continues to work in more recent releases. -- nosy: +loewis ___ Python tracker

[issue3920] OpenBSD 4.4 still doesn't support _XOPEN_SOURCE

Martin v. Löwis added the comment: I have now committed bsd3.diff as r78194, r78195, r78196, and r78197 -- resolution: -> accepted status: open -> closed versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.5, Python 3.0 ___ Python tracker