Martin v. Löwis mar...@v.loewis.de 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
___
Martin v. Löwis mar...@v.loewis.de 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
Ezio Melotti ezio.melo...@gmail.com 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
Antoine Pitrou pit...@free.fr 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).
Stefan Behnel sco...@users.sourceforge.net 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
Antoine Pitrou pit...@free.fr 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
New submission from Kent Johnson k...@kentsjohnson.com:
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).
Stefan Krah stefan-use...@bytereef.org 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
Martin v. Löwis mar...@v.loewis.de 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
New submission from JT Johnson svedgeb...@gmail.com:
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
Amaury Forgeot d'Arc amaur...@gmail.com 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]-
Antoine Pitrou pit...@free.fr 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
tholzer thol...@wetafx.co.nz added the comment:
This is not quite correct:
The following 2 lines fail as expected (unbuffered):
pre
python -u -c 'import sys; print sys.stdout, x' 1- ; echo $?
python -u -c 'import sys; print sys.stderr, x' 2- ; echo $?
/pre
whereas in the following example,
Stefan Krah stefan-use...@bytereef.org 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
Martin v. Löwis mar...@v.loewis.de added the comment:
Thanks for the tests, and the patch. Committed as r78202, r78203, r78204, and
r78205.
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
Martin v. Löwis mar...@v.loewis.de added the comment:
Closing this as unreproducible.
--
resolution: - works for me
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6375
Martin v. Löwis mar...@v.loewis.de 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 rep...@bugs.python.org
Stefan Krah stefan-use...@bytereef.org 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 rep...@bugs.python.org
http://bugs.python.org/issue4639
New submission from Willem de Bruijn wdebr...@dds.nl:
(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
JT Johnson svedgeb...@gmail.com 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
JT Johnson svedgeb...@gmail.com 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
Nikolaus Rath nikol...@rath.org 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
Changes by Nikolaus Rath nikol...@rath.org:
--
title: Python hangs after last thread has exited - Interpreter does not
terminate if daemonized while running multithreaded
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7931
Éric Araujo mer...@netwok.org 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
Éric Araujo mer...@netwok.org 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
Ezio Melotti ezio.melo...@gmail.com 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
Christoph Gohlke cgoh...@uci.edu 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
27 matches
Mail list logo
