[issue9065] tarfile: default root:root ownership is incorrect.
Changes by Lars Gustäbel l...@gustaebel.de: -- assignee: - lars.gustaebel nosy: +lars.gustaebel ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9065 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9025] Non-uniformity in randrange for large arguments.
STINNER Victor victor.stin...@haypocalc.com added the comment:
Distribution with my algorithm:
...
from collections import Counter
print Counter(_randint(6755399441055744) % 3 for _ in xrange(1))
= Counter({0L: 33342985, 2L: 5781, 1L: 33321234})
Distribution: {0: 0.333429853, 2: 0.57808, 1: 0.33321234}
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9025
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9025] Non-uniformity in randrange for large arguments.
Mark Dickinson dicki...@gmail.com added the comment: A couple of points: (1) In addition to documenting the extent of the repeatability, it would be good to have tests to prevent changes that inadvertently change the sequence of randrange values. (2) For large arguments, cross-platform reproducibility is already a bit fragile. For example, the _randbelow function depends on the system _log function---see the line k = int(1.1 + _log(n-1, 2.0)) Now that we have the bit_length method available, it might be better to use that. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9025 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1685453] email package should work better with unicode
Changes by Shashwat Anand anand.shash...@gmail.com: -- nosy: +l0nwlf ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1685453 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9067] Use macros from pyctype.h
New submission from Stefan Krah stefan-use...@bytereef.org: While investigating issue 9020, I noticed that there are several places where the pyctype.h macros could/should be used. -- messages: 108505 nosy: eric.smith, skrah priority: normal severity: normal status: open title: Use macros from pyctype.h type: feature request ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9067 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9020] 2.7: eval hangs on AIX
Stefan Krah stefan-use...@bytereef.org added the comment: Committed fix in r82191. Thanks Sridhar for tracking this down. New issues emerging from this one: 1) Simplify Py_CHARMASK: issue 9036 2) Use macros from pyctype.h: issue 9067 Additionally, I noticed that the macros is_potential_identifier* from py3k/Parser/tokenizer.c assume a contiguous mapping for A-Z, a-z. Is it ok in Python to assume this (in C it isn't)? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9020 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9068] from . import *
New submission from Haoyu Bai divine...@gmail.com: from . import * is valid syntax in CPython (both 2.6 and py3k) but in the language reference it is not allowed: http://docs.python.org/dev/py3k/reference/simple_stmts.html#the-import-statement -- components: Interpreter Core messages: 108507 nosy: bhy priority: normal severity: normal status: open title: from . import * type: behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9068 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1172711] long long support for array module
Mark Dickinson dicki...@gmail.com added the comment: Seems like a reasonable addition to me. Anyone feel like refreshing the patch so that it applies to py3k? -- nosy: +mark.dickinson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1172711 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1172711] long long support for array module
Mark Dickinson dicki...@gmail.com added the comment: BTW, the PyLong_AsUnsignedLongLong BadInternalCall has long since disappeared. I agree with Armin Rigo that the conversion functions in longobject.c are a mess, though (and also that cleanup is difficult). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1172711 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1172711] long long support for array module
Changes by Senthil Kumaran orsent...@gmail.com: -- versions: +Python 3.2 -Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1172711 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9066] Standard type codes for array.array, same as struct
Mark Dickinson dicki...@gmail.com added the comment: I agree that it might be useful to have some way of specifying fixed-width integers. It's not clear to me that importing specifier prefixes from the struct module is the best way to go about this, though. -- nosy: +mark.dickinson stage: - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9066 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9064] pdb enhancement up/down traversals
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: This is a good idea, but tab characters are disallowed in core python code; please replace them with spaces. Then, please provide an unified diff patch (with diff -u), and name it with the .patch extension, this will make it easier to read. -- nosy: +amaury.forgeotdarc ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9064 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9064] pdb enhancement up/down traversals
Andrew Valencia ajv-611-065-2...@vsta.org added the comment: Here's the patch, hopefully updated as requested. Thanks! -- keywords: +patch Added file: http://bugs.python.org/file17758/pdb_up.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9064 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9036] Simplify Py_CHARMASK
Stefan Krah stefan-use...@bytereef.org added the comment:
Antoine Pitrou rep...@bugs.python.org wrote:
Thus,
((unsigned char)((c) 0xff)) and ((unsigned char)(c)) should produce
the same results.
If it's the case, it's probably optimized away by the compiler anyway.
Yes, the asm output is the same. I was more concerned about readability.
Historically, Py_CHARMASK started as ((c) 0xff), hence the name. In r34974
UCHAR_MAX = 2**CHAR_BIT-1 = 255 was enforced. In r61936 the cast was added.
There is no reason not to do the cast when __CHAR_UNSIGNED__ is
defined (it will be a no-op).
Agreed. It also reduces the opportunity for bugs :)
Ok, let's say we use ((unsigned char)((c) 0xff)) also for __CHAR_UNSIGNED__.
What should the comment say about the intended argument? I've examined all
occurrences in the tree and almost always Py_CHARMASK is used with either
char arguments or int arguments that are directly derived from a char, so
no EOF issues arise.
Exceptions:
===
Index: Objects/unicodeobject.c
===
--- Objects/unicodeobject.c (revision 82192)
+++ Objects/unicodeobject.c (working copy)
@@ -8417,6 +8417,7 @@
else if (c = '0' c = '9') {
prec = c - '0';
while (--fmtcnt = 0) {
+/* XXX: c and *fmt are Py_UNICODE */
c = Py_CHARMASK(*fmt++);
if (c '0' || c '9')
break;
Index: Modules/_json.c
===
--- Modules/_json.c (revision 82192)
+++ Modules/_json.c (working copy)
@@ -603,6 +603,7 @@
}
}
else {
+/* XXX: c is Py_UNICODE */
char c_char = Py_CHARMASK(c);
chunk = PyString_FromStringAndSize(c_char, 1);
if (chunk == NULL) {
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9036
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9036] Simplify Py_CHARMASK
Stefan Krah stefan-use...@bytereef.org added the comment: In r61936 the cast was added. Actually r61987 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9036 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9064] pdb enhancement up/down traversals
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: Two remarks: - when int(arg) fails, an error message should be printed, like with the function do_commmands(). - the for loop seems unnecessary, something like self.curindex -= nup should be enough -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9064 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9009] Improve quality of Python/dtoa.c
Mark Dickinson dicki...@gmail.com added the comment: Another issue to consider, brought to my attention by Rick Regan: Python's dtoa.c code likely misbehaves (i.e., returns incorrectly rounded results) if the FPU rounding mode is anything other than the round-half-to-even default. (This is also true of Gay's original dtoa.c, I suspect.) For example, the quick-return path in strtod does a single floating-point operation on exact arguments, so will end up behaving according to the FPU rounding mode. The long integer-arithmetic-based path will likely return round-half-to-even results, independently of the FPU rounding mode. It's debatable what Python should do if the FPU rounding mode is something other than round-half-to-even. It can either: - try to honour the FPU rounding mode, or - ignore the rounding mode completely, always doing round-half-to-even. I'd prefer the latter behaviour, for various reasons: - it maintains consistency across platforms - it's consistent with many other Python operations, that already do round-half-to-even regardless of FPU rounding mode---examples include float.fromhex and float.hex, true division of integers, the round() function... It seems possible that Python might one day want to be able to control the rounding direction of decimal - binary conversions, but when that day comes I don't think playing with the FPU rounding mode is going to be the best control mechanism. I don't regard this as a terribly serious issue, though: most normal users are unlikely to end up in a situation where the FPU rounding mode has changed unless they've been deliberately and knowingly messing with FPU settings. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9009 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9009] Improve quality of Python/dtoa.c
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: - ignore the rounding mode completely, always doing round-half-to-even. +1 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9009 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5672] Implement a way to change the python process name
Martin Marcher mar...@marcher.name added the comment: Hi, just scanned the messages. As I read it wontfix actually means: Ats some point in the future when the setproctitle project (http://code.google.com/p/py-setproctitle/source/list) has matured it will be reconsidered, correct? Yes sorry for reopening this after quite some time (~6 months), just happened to pop up in my inbox due to the latest nosy list changes... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5672 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9009] Improve quality of Python/dtoa.c
Eric Smith e...@trueblade.com added the comment: Alexander Belopolsky belopol...@users.sourceforge.net added the comment: - ignore the rounding mode completely, always doing round-half-to-even. +1 Agreed. +1 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9009 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5672] Implement a way to change the python process name
Brian Curtin cur...@acm.org added the comment: If it has matured, has shown to be as a best of breed library of it's type, and has gone through the PEP process, it could make it. That takes quite a bit of time and isn't likely to occur within the next few years (3.3 at the earliest assuming the project matures quickly). -- nosy: +brian.curtin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5672 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9036] Simplify Py_CHARMASK
Marc-Andre Lemburg m...@egenix.com added the comment:
Stefan Krah wrote:
Stefan Krah stefan-use...@bytereef.org added the comment:
Antoine Pitrou rep...@bugs.python.org wrote:
Thus,
((unsigned char)((c) 0xff)) and ((unsigned char)(c)) should produce
the same results.
If it's the case, it's probably optimized away by the compiler anyway.
Yes, the asm output is the same. I was more concerned about readability.
Historically, Py_CHARMASK started as ((c) 0xff), hence the name. In r34974
UCHAR_MAX = 2**CHAR_BIT-1 = 255 was enforced. In r61936 the cast was added.
There is no reason not to do the cast when __CHAR_UNSIGNED__ is
defined (it will be a no-op).
Agreed. It also reduces the opportunity for bugs :)
Ok, let's say we use ((unsigned char)((c) 0xff)) also for __CHAR_UNSIGNED__.
What should the comment say about the intended argument? I've examined all
occurrences in the tree and almost always Py_CHARMASK is used with either
char arguments or int arguments that are directly derived from a char, so
no EOF issues arise.
Why not just make the casts in those cases explicit instead of
using Py_CHARMASK ?
Exceptions:
===
Index: Objects/unicodeobject.c
===
--- Objects/unicodeobject.c (revision 82192)
+++ Objects/unicodeobject.c (working copy)
@@ -8417,6 +8417,7 @@
else if (c = '0' c = '9') {
prec = c - '0';
while (--fmtcnt = 0) {
+/* XXX: c and *fmt are Py_UNICODE */
c = Py_CHARMASK(*fmt++);
If both are Py_UNICODE, why do you need the cast at all ?
Note that the above use also appears to be wrong, since if *fmt
is Py_UNICODE, the following if() will also match if the higher
order bytes of the Py_UNICODE value are non-0.
if (c '0' || c '9')
break;
Index: Modules/_json.c
===
--- Modules/_json.c (revision 82192)
+++ Modules/_json.c (working copy)
@@ -603,6 +603,7 @@
}
}
else {
+/* XXX: c is Py_UNICODE */
char c_char = Py_CHARMASK(c);
In this case you should get a compiler warning due to the
different signedness of the arguments.
Same comment as above: the high order bytes of c are lost
in this conversion.
Why can't _json.c use one of the existing Unicode conversion
APIs ?
chunk = PyString_FromStringAndSize(c_char, 1);
if (chunk == NULL) {
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9036
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/mal%40egenix.com
--
nosy: +lemburg
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9036
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9064] pdb enhancement up/down traversals
Andrew Valencia ajv-611-065-2...@vsta.org added the comment: Debugging tools which have bugs are a real pain... thanks for your comments and attention. Here's another try. With all the loop baggage gone the argument handling really called for factoring out. -- Added file: http://bugs.python.org/file17759/pdb_up2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9064 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9064] pdb enhancement up/down traversals
Andrew Valencia ajv-611-065-2...@vsta.org added the comment: My bad (new editor session lost the tab setting). Please consider this one with no tabs instead. -- Added file: http://bugs.python.org/file17760/pdb_up3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9064 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5672] Implement a way to change the python process name
Daniele Varrazzo p...@develer.com added the comment: setproctitle is quite stable, my company uses it in production environment very heavily with python 2.x. Probably its users base is not huge, but that's because it's a relatively specialized tool. Python3 porting is not straightforward because python2 exports the original argv pointer using Py_GetArgcArgv() whereas python3 only exports a decoded version in a wchar_t* array. This may not be a showstopper: probably the original argv can still be found scanning backwards from environ: I want to test it but I haven't had requests for it yet, so it wasn't a top priority. So, while I'd be pleased to have it included in the stdlib, I'm not really convinced it would be useful to such a large audience. Anyway I'm available for any improvement it would make the tool more useful and to anybody eager to push for its inclusion. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5672 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9009] Improve quality of Python/dtoa.c
Stefan Krah stefan-use...@bytereef.org added the comment: +1, if the FPU mask is always restored (as I understand, this is the case now). -- nosy: +skrah ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9009 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8682] _ssl.c uses PyWeakref_GetObject but doesn't incref result
Antoine Pitrou pit...@free.fr added the comment: Here is a patch. Will commit soon if there's no remarks. -- keywords: +patch nosy: +exarkun, giampaolo.rodola, janssen Added file: http://bugs.python.org/file17761/sslweakref.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8682 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9020] 2.7: eval hangs on AIX
Antoine Pitrou pit...@free.fr added the comment: Additionally, I noticed that the macros is_potential_identifier* from py3k/Parser/tokenizer.c assume a contiguous mapping for A-Z, a-z. Is it ok in Python to assume this (in C it isn't)? I don't think we support writing Python source code in an encoding that's not a superset of ASCII, so it should be fine. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9020 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9036] Simplify Py_CHARMASK
Antoine Pitrou pit...@free.fr added the comment:
Ok, let's say we use ((unsigned char)((c) 0xff)) also for
__CHAR_UNSIGNED__.
What should the comment say about the intended argument?
That it's either in [-128; 127] or in [0; 255] ?
Index: Objects/unicodeobject.c
===
--- Objects/unicodeobject.c (revision 82192)
+++ Objects/unicodeobject.c (working copy)
@@ -8417,6 +8417,7 @@
else if (c = '0' c = '9') {
prec = c - '0';
while (--fmtcnt = 0) {
+/* XXX: c and *fmt are Py_UNICODE */
c = Py_CHARMASK(*fmt++);
This is a funny bug:
u%.1\u1032f % (1./3)
u'0.'
Index: Modules/_json.c
===
--- Modules/_json.c (revision 82192)
+++ Modules/_json.c (working copy)
@@ -603,6 +603,7 @@
}
}
else {
+/* XXX: c is Py_UNICODE */
char c_char = Py_CHARMASK(c);
This block can only be entered if c = 0x7f (`has_unicode` is false), so it's
not a problem.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9036
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5672] Implement a way to change the python process name
Marcelo Fernández marcelo.fidel.fernan...@gmail.com added the comment: So, while I'd be pleased to have it included in the stdlib, I'm not really convinced it would be useful to such a large audience. I think different, if python becomes even more successful to be used in desktop apps, this feature will be *very* important, because the reasons I've exposed in this thread. Regards -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5672 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8265] test_float fails on ARM Linux EABI with soft floating point
David Kirkby david.kir...@onetel.net added the comment: I'm seeing this failure on both Solaris 10 (SPARC processor) in 32-bit mode and OpenSolaris 06/2009 (Intel Xeon) in 64-bit mode using Python 2.6.4. So it is not just an ARM Linux issue. See http://trac.sagemath.org/sage_trac/ticket/9297 http://trac.sagemath.org/sage_trac/ticket/9299 Note, Solaris supports both a 32 and 64-bit ABI. Not sure if that is relevant, but I see ABI in the title, so perhaps it might be. Dave -- nosy: +drkirkby ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8265 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8265] test_float fails on ARM Linux EABI with soft floating point
Mark Dickinson dicki...@gmail.com added the comment: David, thanks for the report. This looks like a different issue to me, though. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8265 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
New submission from Mark Dickinson dicki...@gmail.com: Comment from David Kirkby in issue 8265; moved here because it looks like a separate problem. I'm seeing this failure on both Solaris 10 (SPARC processor) in 32-bit mode and OpenSolaris 06/2009 (Intel Xeon) in 64-bit mode using Python 2.6.4. So it is not just an ARM Linux issue. See http://trac.sagemath.org/sage_trac/ticket/9297 http://trac.sagemath.org/sage_trac/ticket/9299 Note, Solaris supports both a 32 and 64-bit ABI. Not sure if that is relevant, but I see ABI in the title, so perhaps it might be. -- assignee: mark.dickinson components: Extension Modules messages: 108532 nosy: drkirkby, mark.dickinson priority: normal severity: normal stage: needs patch status: open title: test_float failure on Solaris type: behavior versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
Mark Dickinson dicki...@gmail.com added the comment:
And the text of the failure (from the first link David provides):
test test_float failed -- Traceback (most recent call last):
File
/export/home/drkirkby/sage-4.4.4.alpha1/spkg/build/python-2.6.4.p9/src/Lib/test/test_float.py,
line 765, in test_roundtrip
self.identical(-x, roundtrip(-x))
File
/export/home/drkirkby/sage-4.4.4.alpha1/spkg/build/python-2.6.4.p9/src/Lib/test/test_float.py,
line 375, in identical
self.fail('%r not identical to %r' % (x, y))
AssertionError: -0.0 not identical to 0.0
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9069
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
Mark Dickinson dicki...@gmail.com added the comment:
David, would it be possible for you to provide the results of:
float.hex(-0.0)
float.fromhex('-0x0.0p+0')
on those platforms, so that we can tell whether it's the float - hex
conversion or the hex - float conversion that's losing the sign of the zero?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9069
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8265] test_float fails on ARM Linux EABI with soft floating point
Mark Dickinson dicki...@gmail.com added the comment: New issue for the Solaris failure opened: issue 9069. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8265 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9070] Timestamps are rounded differently in py3k and trunk
New submission from Alexander Belopolsky belopol...@users.sourceforge.net: In the trunk: datetime.utcfromtimestamp(0.994) datetime.datetime(1970, 1, 1, 0, 0, 1) In py3k: datetime.utcfromtimestamp(0.994) datetime.datetime(1970, 1, 1, 0, 0, 0, 99) See issue1478429 - it appears that rounding up was intentional, but I am adding 2.7 because py3k behavior seems to be more natural. -- assignee: belopolsky components: Extension Modules messages: 108536 nosy: belopolsky, georg.brandl, mark.dickinson, tim_one priority: normal severity: normal stage: unit test needed status: open title: Timestamps are rounded differently in py3k and trunk type: behavior versions: Python 2.7, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9070 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9071] TarFile doesn't support member files with a leading ./
New submission from Free Ekanayaka f...@64studio.com: The tar format allows to have memeber files whose path has a leading ./: $ echo foo $ tar cf bar.tar ./foo $ tar tf bar.tar ./foo However the tarfile module doesn't allow this: from StringIO import StringIO from tarfile import TarInfo, TarFile info = TarInfo(./foo) fd = open(bar.tar, w) tar = TarFile.open(fileobj=fd, mode=w) tar.addfile(info, ) tar.close() then: $ tar tf bar.tar foo So in practice the tarfile module forces the removal of leading ./'s. In particular this is a problem when creating .deb files (dpkg) programmatically as these contains tar files with members with a leading ./. -- components: Library (Lib) messages: 108537 nosy: free.ekanayaka priority: normal severity: normal status: open title: TarFile doesn't support member files with a leading ./ type: behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9071 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
Mark Dickinson dicki...@gmail.com added the comment: David, please could you also tell me whether HAVE_COPYSIGN is defined for those builds of Python? It should be in pyconfig.h in the top level of the build directory, if it is. And (just to double check), at configure time, there should be a line in the output of the configure script that looks like checking for copysign... yes Do you get 'yes' or 'no' there? If I had to guess, I'd say that it's the float - hex conversion that's going wrong (so that (-0.0).hex() produces '0x0.0p+0' instead of '-0x0.0p+0'), and that this is caused by either a buggy system copysign function, or by the system copysign function not being found and Python using a buggy workaround. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9068] from . import *
Brett Cannon br...@python.org added the comment: That's because while it is syntactically allowed, it is semantically disallowed. The grammar rules shown in the docs is a generalization of the actual grammar used to build the parser so that we can take shortcuts with it to simply not have rules that will pass the parser but fail in the compiler. -- assignee: - brett.cannon components: +Documentation -Interpreter Core nosy: +brett.cannon priority: normal - low resolution: - wont fix status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9068 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9071] TarFile doesn't support member files with a leading ./
Gustavo Niemeyer gust...@niemeyer.net added the comment: Please note that even if unpacking such a tar might be semantically equivalent to a version which strips out the ./ prefix, it should be possible to create a tar with valid path names such as these. In the case of debs, for instance, the files inside the tarball may contain expected path names, which means that some (badly done, perhaps) tools could *expect* the file to be exactly that which is created by the standard tools (e.g. ./debian/control), and break down once it's not found. With this in mind, it would indeed be nice to be able to use paths prefixed with ./ in Python's tarfile. -- nosy: +niemeyer ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9071 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9070] Timestamps are rounded differently in py3k and trunk
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: My mistake. I had datetime.py from pypy in the directory from which I ran the trunk python. The problem is also in the latest sandbox version of datetime.py, but this is not yet part of cpython proper. Refiled as pypy bug at http://codespeak.net/issue/pypy-dev/issue548 -- resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9070 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
David Kirkby david.kir...@onetel.net added the comment:
Hi Mark,
Here's the info on the two systems - first the SPARC system, secondly the Intel
Xeon system.
1) SPARC
* Sun Blade 2000, with 2 x UltraSPARC III+ 1200 MHZ processors
* 8 GB RAM
* Solaris 10 update 8 10/09 release (This is the latest release of Solaris 10).
drkir...@swan:~$ cat /etc/release
Solaris 10 10/09 s10s_u8wos_08a SPARC
Copyright 2009 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 16 September 2009
drkir...@swan:~$ uname -a
SunOS swan 5.10 Generic_141444-09 sun4u sparc SUNW,Sun-Blade-1000
Python 2.6.4 (r264:75706, Jun 24 2010, 10:39:29)
[GCC 4.4.4] on sunos5
Type help, copyright, credits or license for more information.
float.hex(-0.0)
'0x0.0p+0'
float.fromhex('-0x0.0p+0')
-0.0
When configure runs, I see:
checking for copysign... yes
In pyconfig.h I have:
/* Define to 1 if you have the `copysign' function. */
#define HAVE_COPYSIGN 1
==
==
2) Intel Xeon system.
* Sun Ultra 27, quad core 3.33 GHz Intel Xeon processor
* 12 GB RAM
* OpenSolaris 06/2009, updated to build 134
* 64-bit installation.
* Note, this is the native operating system on this machine, so VirtualBox is
not used.
drkir...@hawk:~$ cat /etc/release
OpenSolaris Development snv_134 X86
Copyright 2010 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 01 March 2010
drkir...@hawk:~$ uname -a
SunOS hawk 5.11 snv_134 i86pc i386 i86pc
Python 2.6.4 (r264:75706, Jun 24 2010, 17:38:56)
[GCC 4.4.4] on sunos5
Type help, copyright, credits or license for more information.
float.hex(-0.0)
'0x0.0p+0'
float.fromhex('-0x0.0p+0')
-0.0
When configure runs, I see:
checking for copysign... yes
In pyconfig.h I have:
/* Define to 1 if you have the `copysign' function. */
#define HAVE_COPYSIGN 1
If you feel access to the SPARC system could help you debug this (or any of the
other test failures I get), I can get you access to a machine 16-core Sun T5240
which was donated by Sun.
I can't provide such easy access to the Xeon system, though you can install
OpenSolaris as a Virtual machine in VirtualBox quite easily - its a free
download.
Dave
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9069
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
Mark Dickinson dicki...@gmail.com added the comment:
Thanks for the details. So the relevant code (see the float_hex function in
Objects/floatobject.c) looks like this:
if (x == 0.0) {
if(copysign(1.0, x) == -1.0)
return PyString_FromString(-0x0.0p+0);
else
return PyString_FromString(0x0.0p+0);
}
This *should* produce the correct string for -0.0 (because -0.0 compares equal
to 0.0, and then copysign(1.0, x) should be -1.0); I'm reasonably confident
that the C code is correct, since the tests pass on all the other platforms
that get tested regularly.
So a buggy system copysign function looks like a possibility. Another more
likely possibility occurs to me, though: and that's that there's a buggy
compiler optimization going on: the compiler sees that we're in an 'x == 0.0'
branch, and decides that it can substitute '0.0' for 'x' everywhere in the 'if'
block. But this is just guessing.
Do you still get these failures in a debug build of Python (i.e., by passing
--with-pydebug to the configure script)?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9069
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
David Kirkby david.kir...@onetel.net added the comment: Just to clarify something, in case you notice something does not look quite right. The link I provided to the build failure on the SPARC machine http://trac.sagemath.org/sage_trac/ticket/9297 was a Sun Blade 1000. It is *not* the same machine from which I just copied the output, which was a Sun Blade 2000. The two machines are pretty similar though - the motherboards, processors, disks, RAM are interchangeable. In fact,'uname' shows Sun-Blade-1000 in both of them. I think the only real difference between them is that the Blade 2000 looks a bit nicer, and is officially supported with faster CPUs. The link I provided to the failure on the Xeon machine http://trac.sagemath.org/sage_trac/ticket/9299 is the same machine where I just posted the output. If you need an account on a SPARC, it will be a more modern Sun T5240 with 32 GB RAM. Dave -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9072] Unloading modules - memleaks?
New submission from Slava bomb...@gmail.com: I don't know whether this is a bug, but my exhaustive search led me to Python can't really unload modules from every direction, which I find hard to believe, I don't know where else to go with this. The problem: import gc, sys print len(gc.get_objects()) # 4073 # starting with 4073 objects in memory import httplib del sys.modules[httplib] del httplib # httplib should be unloaded # and garbage collected as it is unreachable gc.collect() print len(gc.get_objects()) # 6745 # 6745 objects in memory (2000+ stray objects) This applies to almost any module. Is this a bug or somehow correctable? -- components: None messages: 108545 nosy: yappie priority: normal severity: normal status: open title: Unloading modules - memleaks? type: resource usage versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9072 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
David Kirkby david.kir...@onetel.net added the comment: I'll take a look at this in an hour or two. I'll restrict the testing to the Xeon machine, as it is a zillion times quicker than the old SPARCs. What comes to my mind, is that perhaps 'copysign' is only defined in C99. Solaris header files are pretty strict about what gets defined and not defined depending on the mode of compilation. The compiler option -std=c99 is not being passed yet the man page for copysign on my OpenSolaris laptop (yet another system) says: drkir...@laptop:~$ man copysign Mathematical Library Functions copysign(3M) NAME copysign, copysignf, copysignl - number manipulation func- tion SYNOPSIS c99 [ flag... ] file... -lm [ library... ] #include math.h double copysign(double x, double y); float copysignf(float x, float y); long double copysignl(long double x, long double y); DESCRIPTION These functions produce a value with the magnitude of x and the sign of y. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9073] Tkinter module missing from install on OS X 10.6.4
New submission from Roland Johnson rolandjohn...@acm.org: Tkinter no where to be found in the 3.1 install. No lib-tk folder either. There is a Tkinter folder but this conatains very few modules and none of the standard ones -- messages: 108547 nosy: RolandJ priority: normal severity: normal status: open title: Tkinter module missing from install on OS X 10.6.4 versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9073 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9074] [includes patch] subprocess module closes standard file descriptors when it should not
New submission from Keith Rarick k...@xph.us:
Transcript to reproduce in Python 2.6.5:
import subprocess, sys
subprocess.call(('echo', 'foo'), stderr=sys.stdout)
echo: write: Bad file descriptor
1
Expected behavior:
import subprocess, sys
subprocess.call(('echo', 'foo'), stderr=sys.stdout)
foo
0
This happens because we've asked the child's stderr to be redirected, but not
its stdout. So in _execute_child, errwrite is 1 while c2pwrite is None. So fd 1
(errwrite) correctly gets duped to 2. But then, since errwrite is not None and
it's not in (p2cread, c2pwrite, 2), the child closes fd 1.
The equivalent thing happens if you supply stdout=sys.stderr and the child
attempts to write to its stderr.
I've attached a patch to fix this. It simply adds 2 and 2 to the list of fds
not to close for c2pwrite and errwrite, respectively.
This patch is against the 2.6.5 release.
There is also a workaround, in case anyone else is affected by this bug before
a fix has been released:
import os, subprocess, sys
subprocess.call(('echo', 'foo'), stderr=os.dup(sys.stdout.fileno()))
foo
0
(There could be a similar bug relating to the child's stdin, but I haven't
investigated that.)
--
components: IO
files: fd-close.patch
keywords: patch
messages: 108548
nosy: kr
priority: normal
severity: normal
status: open
title: [includes patch] subprocess module closes standard file descriptors when
it should not
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file17762/fd-close.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9074
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9074] [includes patch] subprocess module closes standard file descriptors when it should not
Keith Rarick k...@xph.us added the comment: There was a typo in my description of the patch. It should read: I've attached a patch to fix this. It simply adds 2 and *1* to the list of fds not to close for c2pwrite and errwrite, respectively. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9074 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
David Kirkby david.kir...@onetel.net added the comment: Using the compiler option -std=c99 allows this test to pass. Perhaps adding the macro AC_PROG_CC_C99 to autoconf to add the right compiler option might be a solution. I know Solaris headers are often quite strict, and will not define something in a header file if the right things are not defined to indicate C99. I would add, there is quite a serious problem on Solaris with _socket failing to build. http://bugs.python.org/issue8852 Unless one uses that workaround, which is not committed to the python source code yet, one can not run any tests of python. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8860] Rounding in timedelta constructor is inconsistent with that in timedelta arithmetics
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: Similar problem affects fromtimestamp() constructors: datetime.fromtimestamp(0.0078125)-datetime.fromtimestamp(0) datetime.timedelta(0, 0, 7813) datetime.utcfromtimestamp(0.0078125)-datetime.utcfromtimestamp(0) datetime.timedelta(0, 0, 7813) both rounded to odd, but 0.0078125*timedelta(seconds=1) datetime.timedelta(0, 0, 7812) is correctly rounded to even. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8860 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
Mark Dickinson dicki...@gmail.com added the comment: Thanks for the update. So I'm confused: when -std=c99 isn't given, where is the build finding the copysign function from? That is, why isn't there a link error when building Python? (I'm attempting to install OpenSolaris in Parallels at the moment, but it may take more time than I have available at the moment...) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7989] Add pure Python implementation of datetime module to CPython
STINNER Victor victor.stin...@haypocalc.com added the comment: Why do you need a pure Python version of datetime: - it's easier to work on a new feature first in Python: there are more people are able to write Python code, than people able to write C code (especially C code using the Python C API) - it helps datetime debuging - it helps other Python implementations (not only PyPy) - it improves the quality of the tests and so of the C version I think that the first point is the most important, but datetime still lack many feature and is far from being perfect. I don't think that the pure Python implementation should be used by default: the current C implementation should stay because it's faster and many people use it. I don't know the best name for the Python version, maybe pydatetime.py (or _pydatetime.py). -- Questions: - @Alexander: did you contacted people from IronPython and Jython? - Is the Python version compatible with the C version about the serialization (pickle)? -- r.david.murray there may be more important stuff to python You cannot force other developer to work on a specific topic since Python is only developed by hackers in their free time. If Alexander would like to work on this, he have to do it :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7989 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8949] PyArg_Parse*(): z should not accept bytes
STINNER Victor victor.stin...@haypocalc.com added the comment: Patch commited to 3.2 (r82200), blocked in 3.1 (r82201). -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8949 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9045] 2.7rc1: 64-bit OSX installer is not built with 64-bit tkinter
Sridhar Ratnakumar sridh...@activestate.com added the comment: We can make this work on OSX 10.6 atleast, using Apple's system Tcl/Tk 8.5. 1. Get a 10.6 build machine with 10.5 SDK 2. Modify setup.py to use openssl 0.9.7 (*not* 0.9.8): search_for_ssl_incs_in=['/Developer/SDKs/MacOSX10.5.sdk/usr/include/'] [...] s/ libraries = ['ssl', 'crypto'] / libraries = ['ssl.0.9.7', 'crypto.0.9.7'] /g 3. Run ./configure with MACOSX_DEPLOYMENT_TARGET=10.5 env variable Catch: 10.5 users will have to install Tcl/Tk manually (eg: ActiveTcl 8.5) and run IDLE with arch -i386 idle2.7 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9045 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8951] PyArg_Parse*(): factorize code of 's' and 'z' formats, and 'u' and 'Z' formats
STINNER Victor victor.stin...@haypocalc.com added the comment: Done in 3.2 (r82202), blocked in 3.1 (r82203) because of #8949 and because I prefer to avoid touching a stable branch. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8951 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5672] Implement a way to change the python process name
Martin v. Löwis mar...@v.loewis.de added the comment: Ats some point in the future when the setproctitle project (http://code.google.com/p/py-setproctitle/source/list) has matured it will be reconsidered, correct? No. It will also be required that it's authors agree to contribute it to Python, agree to stop maintaining the out-of-Python version (eventually), and agree to fill out a contributor form. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5672 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9072] Unloading modules - memleaks?
Martin v. Löwis mar...@v.loewis.de added the comment: This is not a bug. You didn't *nearly* reset Python to the state in which it was before the import: the modules that got imported recursively still hang in sys.modules. Please accept that Python indeed does not support unloading modules for severe, fundamental, insurmountable, technical problems, in 2.x. In 3.x, chances are slightly higher. In principle, unloading could be supported - but no module actually adds the necessary code, and the necessary code in the import machinery isn't implemented in 3.2 and earlier. Supporting unloading will be (and was) a multi-year project. Don't expect any results in the next five years. -- nosy: +loewis resolution: - wont fix status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9072 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5672] Implement a way to change the python process name
Daniele Varrazzo p...@develer.com added the comment: No. It will also be required that it's authors agree to contribute it to Python, agree to stop maintaining the out-of-Python version (eventually), and agree to fill out a contributor form. I would have no problem with these points if the module is considered worthy for stdlib inclusion. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5672 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8682] _ssl.c uses PyWeakref_GetObject but doesn't incref result
Antoine Pitrou pit...@free.fr added the comment: Committed in r82204 (py3k) and r82205 (3.1). -- resolution: - fixed stage: needs patch - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8682 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9075] ssl module sets debug flag on SSL struct
New submission from Antoine Pitrou pit...@free.fr: The ssl module sets a debug flag on the OpenSSL SSL struct at the end of PySSL_SSLdo_handshake(): self-ssl-debug = 1; The OpenSSL header files have this to say about this flag: /* set this flag to 1 and a sleep(1) is put into all SSL_read() * and SSL_write() calls, good for nbio debuging :-) */ int debug; Some uses of it in the OpenSSL source are actually guarded by a macro (#ifdef PKT_DEBUG), but some are not. Bill, do you remember why you put that call? I would find it strongly preferrable to remove that assignment (doing so doesn't seem to break anything in the test suite). -- components: Library (Lib) messages: 108561 nosy: exarkun, giampaolo.rodola, janssen, pitrou priority: high severity: normal status: open title: ssl module sets debug flag on SSL struct type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9075 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8926] getargs.c: release the buffer on error
STINNER Victor victor.stin...@haypocalc.com added the comment: Fixed in r82206 and r82207. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8926 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9075] ssl module sets debug flag on SSL struct
Antoine Pitrou pit...@free.fr added the comment: Actually, looking at the history of the SVN repo, this dates back to 1999 when the first SSL support was incorporated by Guido based on third-party patches, and no trace of a review discussion can be found. The only thing we can do is assume it's useless (and perhaps detrimental to performance) and remove it now. Benjamin, do you think it's safe for 2.7 or should wait for 2.7.1? -- nosy: +benjamin.peterson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9075 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
David Kirkby david.kir...@onetel.net added the comment:
Hi Mark,
Since 'copysign' is in the maths library, I would not expect the link phase to
fail. Solaris does not ship with different maths libraries for C99 (one just
links to libm).
However, I would not be surprised if the behavior was ill defined if the
compiler is not C99. Certainly header files behave differently on Solaris
depending on the mode of the compiler. For example, trying to use the INFINITY
macro when the compiler is not C99 seems to work on Linux, but fails on Solaris
unless you force C99 mode with gcc -std=c99.
The following bit of code gives the same results whether one uses 'gcc' or 'gcc
-std=c99' on OpenSolaris or Linux. However, if one uses 'gcc -ansi' then the
behavior is totally different.
drkir...@hawk:~$ cat cs.c
#include stdio.h
#include math.h
int main(int argc, char **argv) {
double x, y;
/* Set x and y differently if a command line arguement is given.
This will avoid the compiler optimising the values out, as they
will not be known in advance. */
if (argc==1) { /* This will stop compiler optimising 0.0 out x */
x=1.0;
y=0.0;
} else {
x=2.0;
y=-0.0;
}
printf(copysign(%lf,%lf)=%lf\n, x, y, copysign(x, y));
}
drkir...@hawk:~$ gcc -lm cs.c
drkir...@hawk:~$ ./a.out
copysign(1.00,0.00)=1.00
drkir...@hawk:~$ ./a.out z
copysign(2.00,-0.00)=-2.00
drkir...@hawk:~$ gcc -lm -std=c99 cs.c
drkir...@hawk:~$ ./a.out
copysign(1.00,0.00)=1.00
drkir...@hawk:~$ ./a.out z
copysign(2.00,-0.00)=-2.00
Note how -ansi screws it up completely
drkir...@hawk:~$ gcc -lm -ansi cs.c
drkir...@hawk:~$ ./a.out
copysign(1.00,0.00)=0.00
drkir...@hawk:~$ ./a.out z
copysign(2.00,-0.00)=0.00
I also tried it on a Sun SPARC running a recent version of Solaris (2009
release). Again the results are the same.
I then tried it on a Solaris box running the first release of Solaris 10
(03/2005). Then one gets even stranger behavior if one defines -ansi, where the
results are almost right, but with poor rounding errors.
drkir...@redstart:~$ gcc -ansi -lm cs.c
drkir...@redstart:~$ ./a.out
copysign(1.00,0.00)=1.01
drkir...@redstart:~$ ./a.out d
copysign(2.00,-0.00)=-2.02
But in C99 mode, it works fine.
drkir...@redstart:~$ gcc -std=c99 -lm cs.c
drkir...@redstart:~$ ./a.out
copysign(1.00,0.00)=1.00
drkir...@redstart:~$ ./a.out d
copysign(2.00,-0.00)=-2.00
So I draw two conclusions.
1) 'copysign' is in the maths library, so a program which tries to link to
'copysign' will succeed.
2) The behavior of 'copysign' is ill defined unless the compiler is a C99
compiler.
I don't think you should use copysign unless the compiler is C99. Trying to
come up with a test for 'copysign' working is probably an impossible task, as
it undefined. So you could try 99 different values of x and y and they all
work, but its anyone guess what will happen with the 100th set of values.
Dave
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9069
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9076] Remove PyUnicode_AsDecodedObject/Unicode and PyUnicode_AsEncodedObject/Unicode?
New submission from STINNER Victor victor.stin...@haypocalc.com: The following 4 functions are public but not documented and not used in Python3: - PyUnicode_AsDecodedObject(), PyUnicode_AsEncodedObject() - PyUnicode_AsDecodedUnicode(), PyUnicode_AsEncodedUnicode() In Python2, PyUnicode_AsDecodedObject() was used by unicode.decode() method, but Python3 has no more str.decode() method (see the recent discussion on python-dev mailing list about .transform() / .untransform()). In Python2, unicode.encode() uses PyUnicode_AsEncodedObject(), but in Python3 str.encode() uses PyUnicode_AsEncodedString() which ensures that the result type is bytes. PyUnicode_AsDecodedUnicode() and PyUnicode_AsEncodedUnicode() were added by Marc-Andre Lemburg in r63986. These functions may be used for .transform() / .untranform() proposition, but this proposition is not yet accepted and the functions are now unused. If you decide to keep one of these functions, the function have to be documented. -- components: Unicode files: remove_unicode_codec.patch keywords: patch messages: 108565 nosy: haypo, lemburg priority: normal severity: normal status: open title: Remove PyUnicode_AsDecodedObject/Unicode and PyUnicode_AsEncodedObject/Unicode? versions: Python 3.2 Added file: http://bugs.python.org/file17763/remove_unicode_codec.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9076 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9072] Unloading modules - memleaks?
Slava bomb...@gmail.com added the comment: Thank you for taking time to answer my question about unloading modules. I really appreciate it! Slava On Fri, Jun 25, 2010 at 2:43 AM, Martin v. Löwis rep...@bugs.python.orgwrote: Martin v. Löwis mar...@v.loewis.de added the comment: This is not a bug. You didn't *nearly* reset Python to the state in which it was before the import: the modules that got imported recursively still hang in sys.modules. Please accept that Python indeed does not support unloading modules for severe, fundamental, insurmountable, technical problems, in 2.x. In 3.x, chances are slightly higher. In principle, unloading could be supported - but no module actually adds the necessary code, and the necessary code in the import machinery isn't implemented in 3.2 and earlier. Supporting unloading will be (and was) a multi-year project. Don't expect any results in the next five years. -- nosy: +loewis resolution: - wont fix status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9072 ___ -- Added file: http://bugs.python.org/file17764/unnamed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9072 ___Thank you for taking time to answer my question about unloading modules. divI really appreciate it!/divdivbr/divdivSlavabrbrdiv class=gmail_quoteOn Fri, Jun 25, 2010 at 2:43 AM, Martin v. Löwis span dir=ltrlt;a href=mailto:rep...@bugs.python.org;rep...@bugs.python.org/agt;/span wrote:br blockquote class=gmail_quote style=margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;br Martin v. Löwis lt;a href=mailto:mar...@v.loewis.de;mar...@v.loewis.de/agt; added the comment:br br This is not a bug. You didn#39;t *nearly* reset Python to the state in which it was before the import: the modules that got imported recursively still hang in sys.modules.br br Please accept that Python indeed does not support unloading modules for severe, fundamental, insurmountable, technical problems, in 2.x.br br In 3.x, chances are slightly higher. In principle, unloading could be supported - but no module actually adds the necessary code, and the necessary code in the import machinery isn#39;t implemented in 3.2 and earlier.br br Supporting unloading will be (and was) a multi-year project. Don#39;t expect any results in the next five years.br br --br nosy: +loewisbr resolution:  -gt; wont fixbr status: open -gt; closedbr divdiv/divdiv class=h5br ___br Python tracker lt;a href=mailto:rep...@bugs.python.org;rep...@bugs.python.org/agt;br lt;a href=http://bugs.python.org/issue9072; target=_blankhttp://bugs.python.org/issue9072/agt;br ___br /div/div/blockquote/divbr/div ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9077] argparse does not handle arguments correctly after --
New submission from Domen ielect...@gmail.com:
Sample code:
parser = argparse.ArgumentParser()
parser.add_argument('-v', action='store_true')
parser.add_argument('foo')
parser.parse_args(['-v', '--', '--foo'])
Namespace(foo='--foo', v=True)
parser = argparse.ArgumentParser()
parser.add_argument('-v', action='store_true')
parser.parse_args(['--', '-f'])
usage: [-h] [-v]
: error: unrecognized arguments: -- -f
--
components: Library (Lib)
messages: 108567
nosy: iElectric
priority: normal
severity: normal
status: open
title: argparse does not handle arguments correctly after --
type: security
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9077
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9078] Fix C API documentation of unicode
Changes by STINNER Victor victor.stin...@haypocalc.com: -- assignee: d...@python components: Documentation, Unicode files: unicode_doc.patch keywords: patch nosy: d...@python, haypo priority: normal severity: normal status: open title: Fix C API documentation of unicode versions: Python 3.2 Added file: http://bugs.python.org/file17765/unicode_doc.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9078 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9078] Fix C API documentation of unicode
New submission from STINNER Victor victor.stin...@haypocalc.com: Attached patch fixes minor bugs in the C API documentation of unicode. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9078 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8611] Python3 doesn't support locale different than utf8 and an non-ASCII path (POSIX)
STINNER Victor victor.stin...@haypocalc.com added the comment: I think that #8988 is a duplicate of this issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8611 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9075] ssl module sets debug flag on SSL struct
Benjamin Peterson benja...@python.org added the comment: Let it die. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9075 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
David Kirkby david.kir...@onetel.net added the comment: Just to clarify the hostnames and hardware used, in case you look at the results here or the links to the Sage maths bug tracker and are not sure what is what. Note some are Solaris and some are OpenSolaris. Some have SPARC and some have Intel processors. All machines are 64-bit, but note that by default executables are created 32-bit on Solaris and OpenSolaris. * hawk = Sun Ultra 27, 3.33 GHz quad core Xeon, OpenSolaris 06/2009, but updated to the latest build of OpenSolaris. * laptop = Sony laptop, 2.0 GHz Intel CPU core2 duo, OpenSolaris 06/2009. * swan = Sun Blade 2000, 2 x 1200 MHz SPARC processors, Solaris 10 10/2009 release (Latest release of Solaris 10 at the time I'm writing this) * redstart = Sun Blade 1000, 2 x 900 MHz SPARC processors, Solaris 10 03/2005 (First Solaris 10 release) Although I've not shows the results from them, if I do show any others, likely candidates will be * sage = x86 Linux box (Ubunta I think) 24 cores. * t2 = Sun T5240, T2+ SPARC processors, 16 cores 1167 MHz, Solaris 10 05/2009 (A recent, but not the very latest release of Solaris 10) * bsd = OS X box of some sort. * hpbox = HP C3600 running HP-UX 11.11B, PA-RISC processors. * chaffinch = Virtual machine running Solaris 10 10/2009. (Runs as a guest operating system in VirtualBox) Sometimes having access to different hardware can be useful, but it can get confusing if someone sees a lot of different host names! Dave -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8850] Remove w format of PyParse_ParseTuple()
STINNER Victor victor.stin...@haypocalc.com added the comment: Commited to 3.2 (r82208), blocked in 3.1 (r82209). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8850] Remove w format of PyParse_ParseTuple()
Changes by STINNER Victor victor.stin...@haypocalc.com: -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9075] ssl module sets debug flag on SSL struct
Antoine Pitrou pit...@free.fr added the comment: Thanks! Committed in r82210 (trunk), r82211 (py3k), r82212 (2.6), r82213 (3.1). -- resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9075 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6608] asctime does not check its input
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: I've just noticed that time_strftime already has the range checks for tm structure fields. These checks can be separated in a function and shared with asctime. Marking this as easy. See also issue897625. -- keywords: +easy -patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6608 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9079] Make gettimeofday available in datetime module
New submission from Alexander Belopolsky belopol...@users.sourceforge.net: Attached patch moves cross-platform logic of obtaining current time to _time.c which is shared between time and datetime modules. This simplifies both modules and reduces the datetime module dependency on the time module. -- assignee: belopolsky components: Extension Modules files: gettimeofday.diff keywords: needs review, patch messages: 108575 nosy: belopolsky, mark.dickinson priority: normal severity: normal stage: patch review status: open title: Make gettimeofday available in datetime module versions: Python 3.2 Added file: http://bugs.python.org/file17766/gettimeofday.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9079 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8852] _socket fails to build on OpenSolaris x64
David Kirkby david.kir...@onetel.net added the comment: Hi Martin, I appreciate your point. But do you know if anyone has it on their TODO list? If not, is there anything I could do about it? I don't have commit access to the Python source code, but if there is anything else I can do I'd like to. This is a pretty serious bug, as it stops one running the self-tests. Although Python builds and 99% of it works with this bug, an attempt to run the self-tests exits fairly quickly, with no tests performed. So despite there being over 300 tests, note one of them gets run unless one works around this bug. Hence the implication is a lot more than the fact that one can't use _socket. Dave drkir...@hawk:~/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src$ make test running build running build_ext building '_socket' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/./Include -I. -IInclude -I./Include -I/usr/local/include -I/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Include -I/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src -c /export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/socketmodule.c -o build/temp.solaris-2.11-i86pc-2.6/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/socketmodule.o /export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/socketmodule.c: In function 'makesockaddr': /export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/socketmodule.c:1103: error: 'struct ifreq' has no member named 'ifr_ifindex' /export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/socketmodule.c:1104: error: 'SIOCGIFNAME' undeclared (first use in this function) /export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/socketmodule.c:1104: error: (Each undeclared identifier is reported only once /export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/socketmodule.c:1104: error: for each function it appears in.) /export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/socketmodule.c: In function 'getsockaddrarg': /export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/socketmodule.c:1411: error: 'SIOCGIFINDEX' undeclared (first use in this function) /export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/socketmodule.c:1423: error: 'struct ifreq' has no member named 'ifr_ifindex' /export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/socketmodule.c: In function 'init_socket': /export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/socketmodule.c:4589: error: 'PACKET_LOOPBACK' undeclared (first use in this function) /export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/socketmodule.c:4590: error: 'PACKET_FASTROUTE' undeclared (first use in this function) building '_ssl' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/./Include -I. -IInclude -I./Include -I/usr/local/include -I/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Include -I/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src -c /export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/_ssl.c -o build/temp.solaris-2.11-i86pc-2.6/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/_ssl.o gcc -shared build/temp.solaris-2.11-i86pc-2.6/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/_ssl.o -L/usr/local/lib -lssl -lcrypto -o build/lib.solaris-2.11-i86pc-2.6/_ssl.so *** WARNING: renaming _ssl since importing it failed: No module named _socket building '_curses' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/./Include -I. -IInclude -I./Include -I/usr/local/include -I/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Include -I/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src -c /export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/_cursesmodule.c -o build/temp.solaris-2.11-i86pc-2.6/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/_cursesmodule.o /export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/_cursesmodule.c: In function 'PyCursesWindow_ChgAt': /export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/_cursesmodule.c:708: warning: implicit declaration of function 'mvwchgat'
[issue9077] argparse does not handle arguments correctly after --
Changes by Benjamin Peterson benja...@python.org: -- assignee: - bethard nosy: +bethard ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9077 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9077] argparse does not handle arguments correctly after --
Changes by Eric Smith e...@trueblade.com: -- nosy: +eric.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9077 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9079] Make gettimeofday available in datetime module
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: The new patch, issue9079.diff exposes gettimeofday as time.gettimeofday() returning (sec, usec) pair. -- Added file: http://bugs.python.org/file17767/issue9079.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9079 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9079] Make gettimeofday available in datetime module
Changes by Alexander Belopolsky belopol...@users.sourceforge.net: Removed file: http://bugs.python.org/file17766/gettimeofday.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9079 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
