[issue2897] include structmember.h in Python.h
Martin v. Löwis mar...@v.loewis.de added the comment: I agree with Alexander; the header shouldn't be included into Python.h as-is. I would propose to eliminate it eventually, with the following steps: 1. move PyMemberDef and the function declarations into object.h 2. (simultaneously) introduce properly-prefixed macros in object.h 3. deprecate structmember.h 4. remove it ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2897 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3872] Python 2.6rc2: Tix ComboBox error
Dominique Wahli dwa...@gmail.com added the comment: What happened ??? I'm pretty sure the fix was committed in 2.6.0 and, as saying by Amaury in comments, the test script running fine. In 2.6.1 test is broken. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3872 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4850] Change type and add _Py_ prefix to COUNT_ALLOCS variables
Martin v. Löwis mar...@v.loewis.de added the comment: Making it static is fine. I don't recall what kind of customization I did when I introduced it. I'm skeptical about the entire issue, though. Why is it that these variables should be prefixed? I disagree that all names need to be prefixed: those only present in certain debug builds need not. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4805] Make python code compilable with a C++ compiler
Marc-Andre Lemburg m...@egenix.com added the comment: On 2009-01-05 22:06, Alexander Belopolsky wrote: Alexander Belopolsky belopol...@users.sourceforge.net added the comment: Given that you can build Python as library on Unix and as DLL on Windows, there doesn't appear to be any need to actually be able to build Python itself using a C++ compiler. Simply using the header files and linking against those libraries should do the trick in most cases. So what is your position on the proposed patch? Is it worthwhile to track down the remaining symbols that may be affected by removal of extern C from .c files? What is your opinion on the original patch (c++-patch.diff) which restores C++ compilability but does not touch these declarations? I think using C++ as a lint variant from time to time is a good exercise to catch some corner issues as I hope this patch demonstrates. I don't think this should be a requirement on every submission, but once an effort is made to restore C++ compilability, such changes should be applied unless there are valid concerns against them. I agree with using C++ compatibility as additional means of checking for correctness of the code. The type casts you have added in the patch should definitely make it into the trunk. Making sure that all exported private symbols get a _Py prefix and a declaration in the header files that adds a comment explaining their private nature is also a good idea. I'm not sure about removing the extern C declarations altogether. We'd need further testing with non-G++ compilers to see whether we still need them or not. With the above fixes, I doubt that we still need them nowadays. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4805 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4850] Change type and add _Py_ prefix to COUNT_ALLOCS variables
Marc-Andre Lemburg m...@egenix.com added the comment: On 2009-01-06 11:28, Martin v. Löwis wrote: Martin v. Löwis mar...@v.loewis.de added the comment: Making it static is fine. I don't recall what kind of customization I did when I introduced it. I'm skeptical about the entire issue, though. Why is it that these variables should be prefixed? I disagree that all names need to be prefixed: those only present in certain debug builds need not. For completeness and to make things easier for all developers, all exported symbols should be prefixed with _Py or Py - regardless of how their export is enabled. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4856] Remove checks for win NT
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: +1 -- nosy: +amaury.forgeotdarc ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4856 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2121] complex constructor doesn't accept string with nan and inf
Mark Dickinson dicki...@gmail.com added the comment:
[Mark]
inputs with a special real or imaginary component. On balance, I'd
support making complex('nan + nan*j') do the right thing.
Having thought about this a bit more, I take this back. Some reasons are
given below.
[David]
- complex(repr(..)) roundtrip should work, whatever the value of complex
is
I disagree. *Why* do you think it should work? It fails for many other
types:
def roundtrip(x): return type(x)(repr(x))
...
roundtrip(abc)
'abc'
roundtrip([1,2,3])
['[', '1', ',', ' ', '2', ',', ' ', '3', ']']
roundtrip((1,))
('(', '1', ',', ')')
roundtrip(Fraction(1, 2))
Traceback (most recent call last):
File stdin, line 1, in module
File stdin, line 1, in roundtrip
File /Users/dickinsm/python_source/trunk/Lib/fractions.py, line 73, in
__new__
raise ValueError('Invalid literal for Fraction: %r' % input)
ValueError: Invalid literal for Fraction: 'Fraction(1, 2)'
roundtrip(Decimal(1))
Traceback (most recent call last):
File stdin, line 1, in module
File stdin, line 1, in roundtrip
File /Users/dickinsm/python_source/trunk/Lib/decimal.py, line 545, in
__new__
Invalid literal for Decimal: %r % value)
File /Users/dickinsm/python_source/trunk/Lib/decimal.py, line 3721, in
_raise_error
raise error(explanation)
decimal.InvalidOperation: Invalid literal for Decimal: Decimal('1')
In general, type(repr(x)) == x only works for simple types (ints, floats),
not compound types like lists, strings, tuples, ... I think it's
reasonable to regard complex as such a compound type.
There *is* a general Python guideline that eval(repr(x)) == x should work
where possible. Note that this fails even for floats:
eval(repr(float('nan')))
Traceback (most recent call last):
File stdin, line 1, in module
File string, line 1, in module
NameError: name 'nan' is not defined
The *real* problem here is that repr(complex) is a mess when it comes to
niceties like signed zeros, infinities and nans:
complex(-0., 0.) # throws away sign of 0 on real part
0j
eval(repr(complex(2., -0.))) # throws away sign on imag. part
(2+0j)
nan = float('nan')
complex(0, nan)
nan*j
nan*j # can't even eval this...
Traceback (most recent call last):
File stdin, line 1, in module
NameError: name 'j' is not defined
nan*1j # not much better: real part should be 0, not nan
(nan+nan*j)
inf = float('inf')
inf*1j # ouch: nan in real part!
(nan+inf*j)
I think the *right* solution is to define repr of a complex number
z to be:
complex(%r, %r) % (z.real, z.imag)
but that's not possible before the mythical, compatibility-breaking,
Python 4.0. And even then your desired complex(repr(z)) roundtripping
wouldn't work, though eval(repr(z)) would.
While we're daydreaming, another possibility is to follow C99's lead, and
introduce a type of 'imaginary' numbers, and make 1j be an imaginary
literal rather than a complex literal. That solves some of the above
eval(repr(.)) problems. Again, I don't see how this could happen before
4.0, and I'm not even sure that it's desirable.
In the circumstances, repr does the best it can, which is to output a
whole expression which more-or-less describes the given complex number,
and will usually eval back to the right thing. I think it's not the
business of the complex() constructor to parse such expressions.
To summarize: it's a mess. I'd recommend that you and/or numpy don't use
repr for roundtrip-capable conversions to string. Instead, output the
real and imaginary parts separately, and use float-from-string and the
complex-from-pair-of-floats constructors to reconstruct.
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2121
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2121] complex constructor doesn't accept string with nan and inf
Mark Dickinson dicki...@gmail.com added the comment: Christian, any comments? Is it okay to close this as a 'won't fix'? ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2121 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4856] Remove checks for win NT
Ulrich Eckhardt eckha...@satorlaser.com added the comment: This patch removes all calls to win32's GetVersion() where they are used to detect NT. In posixmodule.c it was used by a wrapper function that cached the result, which then also became obsolete. -- keywords: +patch Added file: http://bugs.python.org/file12618/python-2.7-win9x-wchar-checks.0.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4856 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4850] Change type and add _Py_ prefix to COUNT_ALLOCS variables
Martin v. Löwis mar...@v.loewis.de added the comment: For completeness I don't think completeness is a useful thing to have here. and to make things easier for all developers, It is not easier, but more difficult. It now requires a change, whereas leaving things as-is requires no change. all exported symbols should be prefixed with _Py or Py - regardless of how their export is enabled. Ah - but they aren't exported symbols. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4850] Change type and add _Py_ prefix to COUNT_ALLOCS variables
Marc-Andre Lemburg m...@egenix.com added the comment: On 2009-01-06 13:28, Martin v. Löwis wrote: Martin v. Löwis mar...@v.loewis.de added the comment: For completeness I don't think completeness is a useful thing to have here. and to make things easier for all developers, It is not easier, but more difficult. It now requires a change, whereas leaving things as-is requires no change. Sure it does: consistent rules always make things easier, since they avoid doubt. all exported symbols should be prefixed with _Py or Py - regardless of how their export is enabled. Ah - but they aren't exported symbols. I'm only referring to exported symbols. Static globals, of course, don't need such a prefix. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4293] Thread Safe Py_AddPendingCall
Kristján Valur Jónsson krist...@ccpgames.com added the comment: Ok, I have addressed the issues raised about testcapi. A new file has been submitted. Added file: http://bugs.python.org/file12619/testcapi.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4293 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4857] syntax: no unpacking in augassign
New submission from jura jur...@narod.ru: the following code produces syntax error: (x, y) += 1 While this is documented in http://docs.python.org/3.0/reference/simple_stmts.html#augmented-assignment-statements (An augmented assignment evaluates the target (which, unlike normal аssignment statements, cannot be an unpacking)...), the syntax specification doesn't reflect this: http://docs.python.org/3.0/reference/simple_stmts.html#grammar-token-augmented_assignment_stmt http://docs.python.org/3.0/reference/grammar.html -- assignee: georg.brandl components: Documentation messages: 79256 nosy: georg.brandl, jura05 severity: normal status: open title: syntax: no unpacking in augassign versions: Python 3.0 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4857 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4857] syntax: no unpacking in augassign
STINNER Victor victor.stin...@haypocalc.com added the comment: Extract of the grammar: target ::= identifier | ... target_list ::= target (, target)* [,] assignment_stmt ::= (target_list =)+ ... augmented_assignment_stmt ::= target augop ... augop ::= += | ... So there is only one possible target for ... += ... and multiple targets for ... = ... -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4857 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4850] Change type and add _Py_ prefix to COUNT_ALLOCS variables
Martin v. Löwis mar...@v.loewis.de added the comment: I'm only referring to exported symbols. Static globals, of course, don't need such a prefix. Ok, the symbols in question are not exported from pythonxy.dll. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4857] syntax: no unpacking in augassign
jura jur...@narod.ru added the comment: Yes, but target ::= identifier | ( target_list ) | ... so (x,y) seems to be a valid target. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4857 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4857] syntax: no unpacking in augassign
STINNER Victor victor.stin...@haypocalc.com added the comment: Oh yes! I didn't see ( target_list ) | [ target_list ], sorry. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4857 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4753] Faster opcode dispatch on gcc
Antoine Pitrou pit...@free.fr added the comment: FWIW, I have made a quick attempt at removing the f-f_lasti assignment in the few places where it could be removed, but it didn't make a difference on my machine. The problem being that there are very few places where it is legitimate to remove the assignment (even a call to Py_DECREF can invoke arbitrary external code through destructors, so even a very simple opcode such as POP_TOP needs the f-f_lasti assignment). Another approach would be to create agregate opcodes, e.g. BINARY_ADD_FAST would combine LOAD_FAST and BINARY_ADD. That's orthogonal to the current issue though. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4753 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4850] Change type and add _Py_ prefix to COUNT_ALLOCS variables
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: On Tue, Jan 6, 2009 at 7:28 AM, Martin v. Löwis rep...@bugs.python.org wrote: .. It is not easier, but more difficult. It now requires a change, whereas leaving things as-is requires no change. I actually agree with Martin on this one. I would not touch this if not for the Py_ssize_t vs. int issue. I am only +0 on renaming: if type change and format spec changes go in, renaming is cost free. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2121] complex constructor doesn't accept string with nan and inf
Cournapeau David da...@ar.media.kyoto-u.ac.jp added the comment:
@ Mark
Concerning float('inf') * 1j: you're right, my rambling did not make any
sense, sorry.
I agree that adding complexity may be a good reason to warrant an
arbitrary feature; actually, I did not manage to handle nan/inf at first
because of the complexity :) But as I mentioned in a previous comment, I
think my patch simplifies the parsing as well. I suggested to split the
patch in to: one whithout any new feature (no handling of nan/inf), and
then anoter handling nan/inf on the top of it. Would that be acceptable ?
Also, how should I proceed to share implementation between floatobject.c
and complexobject.c ? Would creating a new file for the common code be
acceptable ?
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2121
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4293] Thread Safe Py_AddPendingCall
Antoine Pitrou pit...@free.fr added the comment: Ok, the test patch is fine! Now looking at the main patch, some comments: - you removed volatile from pendingfirst and pendinglast, is it really safe? - what if pending_lock is not initialized when Py_AddPendingCall is called? I know it's unlikely, but imagine someone calling that function just after the interpreter has been initialized - the documentation should mention that the GIL must not be held when Py_AddPendingCall is called, otherwise there can be a deadlock (is it a change from previous versions by the way?) - you should check the return value of PyThread_allocate_lock() for NULL - is your implementation reentrant? that is, registering a callback from a callback. There is no need for it to be, but if it aims to be, then it should perhaps be documented and tested :) ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4293 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4850] Change type and add _Py_ prefix to COUNT_ALLOCS variables
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: On Tue, Jan 6, 2009 at 10:53 AM, Marc-Andre Lemburg rep...@bugs.python.org wrote: .. I don't follow you: those symbols are not meant for public use anyway, so we can easily change them without any costs. The same goes for any of the private, but still exported symbols in the API, ie. all _Py* APIs. This is the same that I said: renaming is cost free if it is done together with the type change. Martin was right that there is cost associated with any change. The benefit of completeness for a specialized build would not justify even having this discussion IMO. On the other hand since the type change needs to be done in order to make the code correct on a 64 bit platform and compile without warnings with gcc, a patch is needed anyways. Since we are already paying the cost of change, renaming is free. There is no disagreement between you and me here. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2121] complex constructor doesn't accept string with nan and inf
Raymond Hettinger rhettin...@users.sourceforge.net added the comment: Mark, I'm somewhat uncomfortable with your proposal also. It changes what the parser will accept and the potential benefits are almost nil. Also, putting NaNs and Infs in complex numbers is probably not something that should be pursued. I see no utility in pairs like (NaN, 3.0) or (-2.0, Inf). The whole request is use case challenged. AFAICT, the current implementation suffice for real cases and there is no compelling need to rearrange and redesign this code. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2121 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4751] Patch for better thread support in hashlib
Antoine Pitrou pit...@free.fr added the comment: The patch looks fine to me, apart from one point: the return value of PyThread_allocate_lock() should be checked for NULL, and the error either propagated or cleared. (I'd also suggest lowering HASHLIB_GIL_MINSIZE to 2048 or 4196) Gregory, what's your take? ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4751 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4751] Patch for better thread support in hashlib
Gregory P. Smith g...@krypto.org added the comment: hashlibopenssl_small_lock-4.diff looks good to me. I also agree that HASHLIB_GIL_MINSIZE should be lowered to 2048. Commit it, and please backport it to trunk before closing this bug. -- nosy: -gps versions: +Python 2.7, Python 3.1 -Python 3.0 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4751 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4794] garbage collector blocks and takes worst-case linear time wrt number of objects
darrenr python-roun...@dranalli.com added the comment: Regardless of the type of algorithm used by the garbage collector that currently exists in Python, its worst-case performance is undesirable. I have some interest in implementing a garbage collector for Python with improved performance characteristics but don't really have the time for it. Hopefully someone does. In any case thanks for hearing me out. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4794 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3976] pprint._safe_repr is not general enough in one instance
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
The proposed patch appears to give up sorting by key,value altogether if
there are a few incomparable items. It would be better to group items by
type and sort within each group. For example,
pprint({1:1,2:2,A():3,A():4}) should print int:int items in order.
--
nosy: +belopolsky
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3976
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1180193] broken pyc files
Antoine Pitrou pit...@free.fr added the comment: Committed to trunk and py3k, and backported to 2.6 and 3.0. Thanks! -- resolution: accepted - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1180193 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4751] Patch for better thread support in hashlib
Changes by Lukas Lueg knabberknusperh...@yahoo.de: Removed file: http://bugs.python.org/file12587/hashlibopenssl_small_lock-4.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4751 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4751] Patch for better thread support in hashlib
Lukas Lueg knabberknusperh...@yahoo.de added the comment: PyThread_allocate_lock can fail without interference. object-lock will stay NULL and the GIL is simply not released. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4751 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4858] Deprecation of MD5
New submission from Lukas Lueg knabberknusperh...@yahoo.de: MD5 is one of the most popular cryptographic hash-functions around, mainly for it's good performance and availability throughout applications and libraries. The MD5 algorithm is currently implemented in python as part of the hashlib-module and (in more general terms) as part of SSL in the ssl-module. However, concerns about the security of MD5 have risen during the last few years. In 2007 a practical attack to create collisions in the compression-function has been released and on 12/31/2008 US-CERT issued a note to warn about the general insecurity of MD5 (http://www.kb.cert.org/vuls/id/836068). I propose and strongly suggest to start deprecate direct support for MD5 during this year and completly remove support for it afterwards. * MD5 is a cryptographic hash function, it's reason for being is security. By means of current hardware and attack vectors it's a matter of hours to create collisions and fool MD5 hashes. The reason for being has come to an end. * Python runs an uncountable number of exposed user interfaces on the web. Usually the programmers rely on the security of the backing libraries. Python can't provide this with MD5. * The functionality of MD5 can be easily replaced by using other hashes that are supported by python (e.g. SHA1). They supply compareable performance but are not binary-compatible (yay). * Programmers use MD5 in python without the need for it's cryptographic attributes (e.g. creating unique indexes). Keeping MD5 for this use however devaluates overall security of python for the good of few. I'd like to start a discussion about this. Please keep in mind that - although MD5 is currently still very popular and python's support for it is justifed by demand - it's existence will come to an end soon. We should now act and give people time to update their implementations. In a rough cut: - Patch haslib to throw a DeprecationWarning, starting during the first half of 2009. - Update documentation not to use MD5 for security reasons - Remove MD5 from python in 2010. - Keep accordance to PEP 4 Goodbye MD5 and thanks for all the fish. -- components: Extension Modules messages: 79281 nosy: ebfe severity: normal status: open title: Deprecation of MD5 versions: Python 2.7, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4858 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4858] Deprecation of MD5
Marc-Andre Lemburg m...@egenix.com added the comment: On 2009-01-06 21:06, Lukas Lueg wrote: MD5 is one of the most popular cryptographic hash-functions around, mainly for it's good performance and availability throughout applications and libraries. The MD5 algorithm is currently implemented in python as part of the hashlib-module and (in more general terms) as part of SSL in the ssl-module. However, concerns about the security of MD5 have risen during the last few years. In 2007 a practical attack to create collisions in the compression-function has been released and on 12/31/2008 US-CERT issued a note to warn about the general insecurity of MD5 (http://www.kb.cert.org/vuls/id/836068). I propose and strongly suggest to start deprecate direct support for MD5 during this year and completly remove support for it afterwards. A strong -1 on that idea. MD5 is in wide-spread use as hash function. It can no longer be considered a cryptographic hash function, but still serves its purpose as fast, easy to use general purpose hash function well. Removing it from Python would cripple Python for no apparent reason. -- nosy: +lemburg ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4858 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4858] Deprecation of MD5
Raymond Hettinger rhettin...@users.sourceforge.net added the comment: Because MD5 is used widely, Python needs to support it, if only to be able to verify MD5 signatures when offered. -- nosy: +rhettinger resolution: - rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4858 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1708] improvements for linecache
Antoine Pitrou pit...@free.fr added the comment: Looking at the patch, the recorded seek points will probably be wrong if some newlines were translated (e.g. '\r\n' - '\n') when reading the file. I'm also not sure not what the use case for very big files is. linecache is primarily used for printing tracebacks, the API isn't really general-purpose. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1708 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4858] Deprecation of MD5
Gregory P. Smith g...@krypto.org added the comment: The hashlib docs already mention the problems with md5 et al via a bright red: Warning Some algorithms have known hash collision weaknesses, see the FAQ at the end. thanks for closing this. not gonna happen. -- nosy: +gregory.p.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4858 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4859] pwd, spwd, grp functions vulnerable to denial of service
New submission from David Watson bai...@users.sourceforge.net: The pwd (and spwd and grp) modules deal with data from /etc/passwd (and/or other sources) that can be supplied by users on the system. Specifically, users can often change the data in their GECOS fields without the OS requiring that it conform to a specific encoding, and given some automated account signup system, it's conceivable that arbitrary data could even be placed in the username field. This causes a problem since the functions in these modules try to decode the data into str objects, and if a user has placed data in /etc/passwd, say, that does not conform to the relevant encoding, the function will raise UnicodeDecodeError and thus prevent the program from learning the relevant mapping between username and UID, etc. (or crash the program if it wasn't expecting this). For a system program written in Python, this can amount to a denial of service attack, especially if the program uses the get*all() functions. Currently, the pwd module tries to decode the string fields using the Unicode-escape codec, i.e. like a Python string literal, and this can fail when given an invalid backslash escape. You can see this by running chfn(1), entering something like \ux in one of the fields, and then calling pwd.getpwnam(yourname) or pwd.getpwall(). Perhaps the use of this codec is a mistake, given that spwd and grp decode the string fields as UTF-8, but chfn could also be used to enter non-UTF-8 data in the GECOS field. You can see similar failures in the grp and spwd modules after adding a user with a non-UTF-8 name (do something like useradd $'\xff' in bash). A debug build of Python also reports a reference counting error in grp (count goes to -1) when its functions fail on non-UTF-8 data; what I think is going on is that in mkgrent(), PyStructSequence_SET_ITEM steals the reference to w, meaning the second Py_DECREF(w) shouldn't be there. Also, getpwall() and getgrall() leave file descriptors open when they fail, since they don't call end*ent() in this case. The attached minor.diff fixes both of these problems, I think. I've also written a patch (bytes.diff, attached) that would add new functions pwd.getpwnamb(), etc. (analogous to os.getcwdb()) to return bytes objects for the text fields, thus avoiding these problems - what do you think? The patch also makes pwd's original string functions use UTF-8 like the other modules. Alternatively or in addition, a quick fix for the GECOS problem might be for the pwd module to decode the text fields as Latin-1, since in the absence of backslash escapes this is what the Unicode-escape encoding is equivalent to. This would at least block any DoS attempts using the GECOS field (or attempts to add extra commas with \x2c, etc.) without changing the behaviour much. The attached latin1.diff does this. -- components: Extension Modules files: bytes.diff keywords: patch messages: 79286 nosy: baikie severity: normal status: open title: pwd, spwd, grp functions vulnerable to denial of service type: security versions: Python 3.0, Python 3.1 Added file: http://bugs.python.org/file12621/bytes.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4859 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4859] pwd, spwd, grp functions vulnerable to denial of service
Changes by David Watson bai...@users.sourceforge.net: Added file: http://bugs.python.org/file12622/minor.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4859 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4859] pwd, spwd, grp functions vulnerable to denial of service
Changes by David Watson bai...@users.sourceforge.net: Added file: http://bugs.python.org/file12623/latin1.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4859 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue816929] term.h present but cannot be compiled
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: This was corrected a long time ago in r37372 -- nosy: +amaury.forgeotdarc resolution: - out of date status: open - closed superseder: - configure not able to find ncurses/curses in Solaris ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue816929 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1708] improvements for linecache
umaxx um...@oleco.net added the comment: Looking at the patch, the recorded seek points will probably be wrong if some newlines were translated (e.g. '\r\n' - '\n') when reading the file. ack, this could be a problem. I'm also not sure not what the use case for very big files is. this is easy to answer: i used it for example for parsing (still growing) big log files from mail servers. parsing the whole file first time, and than later: starting from line xyz+1 (xyz was the last line recorded after first time parsing) *without* parsing the whole file again. especially very useful for growing log files 1GB just try to get linenumber 1234567 from a 2,3GB log file with the current linecache implementation :) the main idea behind the patch is to cache the seek points to save a lot of time on big files. linecache is primarily used for printing tracebacks, the API isn't really general-purpose. i know :) ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1708 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4026] fcntl extension fails to build on AIX 6.1
Jeremy Olexa darks...@gentoo.org added the comment: This also happens with Python 2.5.2 (not the latest 2.5 series, I know) on AIX 6.1. -- nosy: +darkside ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4026 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4858] Deprecation of MD5
Lukas Lueg knabberknusperh...@yahoo.de added the comment: As I already said to Raymond: At least we should update the documentation. The FAQ currently linked is from 2005. The CERT-Advisory from provides a clean and simple language: In 2008, researchers demonstrated the practical vulnerability [...] We are currently unaware of a practical solution to this problem. *Do not use the MD5 algorithm*. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4858 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4293] Thread Safe Py_AddPendingCall
Kristján Valur Jónsson krist...@ccpgames.com added the comment: 1) volatile is not required when access is guarded by locks. 2) pendingcalls_to_do is initialized to 1, so the very first thing that the interpreter does (after executing one bytecode, I init _PyTicker to 0 now) is to initialize this lock. Creating a lock really must be done by one well known startup thread only. There is a lot of functions in the python API that don't work until after python initialization (without that being explicitly documented), Py_AddPendingCall() is one of them. Btw, there is no generic init function for the ceval.c module. And PyEval_InitThreads isn't really suitable since we must have the lock, even if we haven't initialized the threads, to guard us against reentrancy during signal delivery. For extra safety, I have added a NULL test in Py_AddPendingCall(). 3)Py_AddPendingCall() can be called with our without the GIL. 4)I've added a check in Py_MakePendingCalls(). In PyEval_ReInitThreads there is no way to do anything sensible in the case of error. 5)Yes it is reentrant. The pending_lock is only held for a short while while we pop a callback off the queue. However, because even during that short while a signal can be delivered which causes Py_AddPendingCall() to be called, the latter function fails if it doesn't acquire the lock in a reasonable amount of time. This would cause a signal to be lost, and not a deadlock. This hasn't changed from the old implementation. I have also added a flag to make sure that we don't execute pending calls recursively, (async notifications is so much better) and explained it better in the docs. Added file: http://bugs.python.org/file12624/pendingalls.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4293 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4860] js_output wrong for cookies with characters
New submission from Noufal nou...@nibrahim.net.in:
If a cookie is created with a character in the content, the js_output
which is emitted is bad javascript. eg.
import Cookie
c=Cookie.Cookie('Customer=WILE_E_COYOTE; Version=1; Path=/acme')
print c
Set-Cookie: Customer=WILE_E_COYOTE; Path=/acme; Version=1
print c.js_output()
script type=text/javascript
!-- begin hiding
document.cookie = Customer=WILE_E_COYOTE; Path=/acme; Version=1;
// end hiding --
/script
Also, the test_cookie tests (test_load) explicitly checks for this
(wrong) output.
I have attached a patch that seems to fix this or at the very least
produces the same Cookie settings whether the cookie is set using the
header or using javascript (I've verified this on firefox on Linux).
--
components: Library (Lib), Tests
files: cookie.patch
keywords: patch
messages: 79292
nosy: noufal
severity: normal
status: open
title: js_output wrong for cookies with characters
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file12625/cookie.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4860
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4858] Deprecation of MD5
Marc-Andre Lemburg m...@egenix.com added the comment: On 2009-01-06 22:42, Lukas Lueg wrote: Lukas Lueg knabberknusperh...@yahoo.de added the comment: As I already said to Raymond: At least we should update the documentation. The FAQ currently linked is from 2005. The CERT-Advisory from provides a clean and simple language: In 2008, researchers demonstrated the practical vulnerability [...] We are currently unaware of a practical solution to this problem. *Do not use the MD5 algorithm*. That's a correct statement for cryptographic work based on MD5. However, it's not true with respect to using MD5 as fast general purpose hash algorithm in non-crypto applications, so I think the warning on http://docs.python.org/library/hashlib.html is sufficient. Note that the various SHA implementations are also starting to get some heat lately, so it's only a question of time until these get excluded from the set of cryptographic hash functions: http://en.wikipedia.org/wiki/SHA1 http://en.wikipedia.org/wiki/Cryptographic_hash_function also see: http://en.wikipedia.org/wiki/Hash_function Hash functions are related to (and often confused with) checksums, check digits, fingerprints, randomizing functions, error correcting codes, and cryptographic hash functions. Although these concepts overlap to some extent, each has its own uses and requirements. It might be a good idea to remove the word secure from the hashlib documentation, since security of these algorithms is always limited to a certain period of time. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4858 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4861] fix problems with ctypes.util.find_library
New submission from Matthias Klose d...@debian.org: there are some problems with ctypes.util.find_library(), which I would like to see fixed on active branches. - find_library is not robust, if either objdump or gcc are not installed. fixed by raising an exception if the tools are not found. Is OSError the correct type for this exception? - ldconfig -p already prints the shared object name. afaics there is no need to call objdump again. - the regexp to scan the ldconfig -p output is wrong for architectures where libraries of more than one abi type are installed, e.g. having ix86 libs on a x86_64 system. Having only the library installed which doesn't match the python executable lets find_library find the wrong library. Note that the patch is only correct under the assumption that the python executable is unstalled for the main abi. patch attached, ok to check in? -- assignee: theller components: ctypes files: ctypes-findlib.diff keywords: patch, patch messages: 79294 nosy: doko, theller severity: normal status: open title: fix problems with ctypes.util.find_library versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1 Added file: http://bugs.python.org/file12626/ctypes-findlib.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4861 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4858] Deprecation of MD5
Lukas Lueg knabberknusperh...@yahoo.de added the comment: It might be a good idea to remove the word secure from the hashlib documentation, since security of these algorithms is always limited to a certain period of time. I'm sorry, was that a boy attempted humor ? [Misuse quote from DH3: Check] Anyway, in fact that might be a good idea: Reflect that the hashlib module includes hash functions for the sake of compatibility and interoperability and not everlasting security. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4858 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4858] Deprecation of MD5
Raymond Hettinger rhettin...@users.sourceforge.net added the comment: Secure hash or cryptographic hash is the correct term and I think we should leave that in, if only to make the original intent clear and to make them easier to search for. I propose adding a sentence to the first paragraph noting that the level of security varies by algorithm and that over time some of the algorithms are being found to have possible cryptographic weaknesses or exploits. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4858 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4858] Deprecation of MD5
Marc-Andre Lemburg m...@egenix.com added the comment: On 2009-01-06 23:10, Lukas Lueg wrote: Lukas Lueg knabberknusperh...@yahoo.de added the comment: It might be a good idea to remove the word secure from the hashlib documentation, since security of these algorithms is always limited to a certain period of time. I'm sorry, was that a boy attempted humor ? [Misuse quote from DH3: Check] No, it's the reality of life and one of the reasons why digitally signed data needs to be resigned every few years in order to keep the data secured and the legal status of the signature intact. Note that SHA-0 and -1 were broken in 2005: http://www.schneier.com/blog/archives/2005/08/new_cryptanalyt.html In Germany, the BSI which corresponds to the NSA in the US, publishes a list of algorithms each year that are deemed safe, including their expiration year: http://www.bundesnetzagentur.de/enid/Veroeffentlichungen/Algorithmen_sw.html (in German) They regard SHA-1 as expired by the end of this year. For SHA-2 functions they give 2015 as expiry date. The NSA has similar guidelines: http://csrc.nist.gov/groups/ST/hash/statement.html They currently suggest using SHA-2 functions for crypto applications, but are also running a new contest for SHA-3: http://csrc.nist.gov/groups/ST/hash/sha-3/Round1/submissions_rnd1.html Anyway, in fact that might be a good idea: Reflect that the hashlib module includes hash functions for the sake of compatibility and interoperability and not everlasting security. BTW: Not sure what Deer Hunter 3 has to do with all this ;-) http://www.planetdeerhunter.com/dh3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4858 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4862] utf-16 BOM is not skipped after seek(0)
New submission from Amaury Forgeot d'Arc amaur...@gmail.com:
First write a utf-16 file with its signature:
f1 = open('utf16.txt', 'w', encoding='utf-16')
f1.write('0123456789')
f1.close()
Then read it twice:
f2 = open('utf16.txt', 'r', encoding='utf-16')
print('read1', ascii(f2.read()))
read1 '0123456789'
f2.seek(0)
0
print('read2', ascii(f2.read()))
read2 '\ufeff0123456789'
The second read returns the BOM!
This is because the zero in seek(0) is a cookie which contains both the
position
and the decoder state. Unfortunately, state=0 means 'endianness has been
determined:
native order'.
maybe a suggestion: handle seek(0) as a special value which calls
decoder.reset().
The patch implement this idea.
--
files: io_utf16.patch
keywords: patch
messages: 79299
nosy: amaury.forgeotdarc
priority: critical
severity: normal
status: open
title: utf-16 BOM is not skipped after seek(0)
versions: Python 3.0
Added file: http://bugs.python.org/file12627/io_utf16.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4862
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3823] ssl.wrap_socket() is incompatible with servers that drop privileges, due to keyfile requirement
Changes by Giampaolo Rodola' billiej...@users.sourceforge.net: -- nosy: +giampaolo.rodola ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3823 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4863] deprecate/delete distutils.mwerkscompiler...
New submission from Skip Montanaro s...@pobox.com: I was just poking around the distutils documentation and came across the distutils.mwerkscompiler module. Surely that can't be useful anymore, can it? The doc reads, in its entirety: Contains MWerksCompiler, an implementation of the abstract CCompiler class for MetroWerks CodeWarrior on the pre-Mac OS X Macintosh. Needs work to support CW on Windows or Mac OS X. So the only place it used to work was on pre-Mac OS X, which Python doesn't support any longer and will need work for Windows or Mac OS X which presumably nobody has done. This module should be deprecated in 3.1 and removed in 3.2. Skip -- messages: 79300 nosy: skip.montanaro severity: normal status: open title: deprecate/delete distutils.mwerkscompiler... ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4863 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4864] test_msvc9compiler fails on VC6
New submission from Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp: Currently, test_msvc9compiler fails on VC6 with following message. // Traceback (most recent call last): File test_distutils.py, line 17, in module test_main() File test_distutils.py, line 13, in test_main test.test_support.run_unittest(distutils.tests.test_suite()) File e:\python-dev\trunk\lib\test\test_support.py, line 710, in run_unittest _run_suite(suite) File e:\python-dev\trunk\lib\test\test_support.py, line 693, in _run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File e:\python-dev\trunk\lib\distutils\tests\test_msvc9compiler.py, line 16, in test_no_compiler from distutils.msvc9compiler import query_vcvarsall File e:\python-dev\trunk\lib\distutils\msvc9compiler.py, line 281, in modul e raise DistutilsPlatformError(VC %0.1f is not supported by this module % VE RSION) DistutilsPlatformError: VC 6.0 is not supported by this module // I think attached patch will fix this. Is this fix appropriate? Thank you. -- components: Tests files: test_msvc9compiler.patch keywords: easy, needs review, patch messages: 79301 nosy: ocean-city severity: normal status: open title: test_msvc9compiler fails on VC6 versions: Python 2.7 Added file: http://bugs.python.org/file12628/test_msvc9compiler.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4864 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4864] test_msvc9compiler fails on VC6
Changes by Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp: Removed file: http://bugs.python.org/file12628/test_msvc9compiler.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4864 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4864] test_msvc9compiler fails on VC6
Changes by Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp: Added file: http://bugs.python.org/file12629/test_msvc9compiler.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4864 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4753] Faster opcode dispatch on gcc
Paolo 'Blaisorblade' Giarrusso p.giarru...@gmail.com added the comment: @pitrou: ranting mode Argh, reference counting hinders even that? /ranting mode I just discovered another problem caused by refcounting. Various techniques allow to create binary code from the interpreter binary, by just pasting together the code for the common interpreters cases and producing calls to the other. But, guess what, on most platforms (except plain x86, but including x86_64 and maybe x86 for the shared library case) this does not work if the copied code includes function calls (on x86_64 that's due to RIP-relative addressing, and on similar issues on other platforms). So, Python could not even benefit from that! That's a real pity... I'll have to try with subroutine threading, to see if that's faster than indirect threading on current platforms or if it is still slower. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4753 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
