[issue4753] Faster opcode dispatch on gcc

Paolo 'Blaisorblade' Giarrusso added the comment: @pitrou: Argh, reference counting hinders even that? 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 interpre

[issue4864] test_msvc9compiler fails on VC6

Changes by Hirokazu Yamamoto : Added file: http://bugs.python.org/file12629/test_msvc9compiler.patch ___ Python tracker ___ ___ Python-bugs-lis

[issue4864] test_msvc9compiler fails on VC6

Changes by Hirokazu Yamamoto : Removed file: http://bugs.python.org/file12628/test_msvc9compiler.patch ___ Python tracker ___ ___ Python-bugs-l

[issue4864] test_msvc9compiler fails on VC6

New submission from Hirokazu Yamamoto : Currently, test_msvc9compiler fails on VC6 with following message. // Traceback (most recent call last): File "test_distutils.py", line 17, in test_main() File "test_distutils.py", line 13, in test_main

[issue4863] deprecate/delete distutils.mwerkscompiler...

New submission from Skip Montanaro : 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

[issue3823] ssl.wrap_socket() is incompatible with servers that drop privileges, due to keyfile requirement

Changes by Giampaolo Rodola' : -- nosy: +giampaolo.rodola ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:/

[issue4862] utf-16 BOM is not skipped after seek(0)

New submission from Amaury Forgeot d'Arc : 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())) read

[issue4858] Deprecation of MD5

Marc-Andre Lemburg added the comment: On 2009-01-06 23:10, Lukas Lueg wrote: > Lukas Lueg 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

[issue4858] Deprecation of MD5

Raymond Hettinger 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 v

[issue4858] Deprecation of MD5

Lukas Lueg 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 t

[issue4861] fix problems with ctypes.util.find_library

New submission from Matthias Klose : 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

[issue4858] Deprecation of MD5

Marc-Andre Lemburg added the comment: On 2009-01-06 22:42, Lukas Lueg wrote: > Lukas Lueg 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

[issue4860] js_output wrong for cookies with " characters

New submission from Noufal : 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; Versi

[issue4293] Thread Safe Py_AddPendingCall

Kristján Valur Jónsson 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

[issue4858] Deprecation of MD5

Lukas Lueg 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 un

[issue4026] fcntl extension fails to build on AIX 6.1

Jeremy Olexa 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 ___

[issue1708] improvements for linecache

umaxx 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 answ

[issue816929] term.h present but cannot be compiled

Amaury Forgeot d'Arc 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 trac

[issue4859] pwd, spwd, grp functions vulnerable to denial of service

Changes by David Watson : Added file: http://bugs.python.org/file12623/latin1.diff ___ Python tracker ___ ___ Python-bugs-list mailing list Uns

[issue4859] pwd, spwd, grp functions vulnerable to denial of service

Changes by David Watson : Added file: http://bugs.python.org/file12622/minor.diff ___ Python tracker ___ ___ Python-bugs-list mailing list Unsu

[issue4859] pwd, spwd, grp functions vulnerable to denial of service

New submission from David Watson : 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 enc

[issue4858] Deprecation of MD5

Gregory P. Smith 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 __

[issue1708] improvements for linecache

Antoine Pitrou 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 traceback

[issue4858] Deprecation of MD5

Raymond Hettinger 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

[issue4858] Deprecation of MD5

Marc-Andre Lemburg 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 a

[issue4858] Deprecation of MD5

New submission from Lukas Lueg : 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 ter

[issue4751] Patch for better thread support in hashlib

Lukas Lueg added the comment: PyThread_allocate_lock can fail without interference. object->lock will stay NULL and the GIL is simply not released. ___ Python tracker ___

[issue4751] Patch for better thread support in hashlib

Changes by Lukas Lueg : Removed file: http://bugs.python.org/file12587/hashlibopenssl_small_lock-4.diff ___ Python tracker ___ ___ Python-bugs-

[issue1180193] broken pyc files

Antoine Pitrou 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 __

[issue3976] pprint._safe_repr is not general enough in one instance

Alexander Belopolsky 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

[issue4794] garbage collector blocks and takes worst-case linear time wrt number of objects

darrenr 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

[issue4751] Patch for better thread support in hashlib

STINNER Victor added the comment: Updated patch: - change HASHLIB_GIL_MINSIZE to 2048 bytes - update hashlib documentation: add a note about the 2048 GIL limit - write a small test just for more sure that the GIL cases are tested (GIL released during object creation or on update) Added file

[issue4751] Patch for better thread support in hashlib

Gregory P. Smith 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 ___

[issue1180193] broken pyc files

Changes by Antoine Pitrou : -- resolution: -> accepted versions: +Python 2.7, Python 3.1 -Python 2.6 ___ Python tracker ___ ___ Pyt

[issue4751] Patch for better thread support in hashlib

Antoine Pitrou 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? _

[issue2121] complex constructor doesn't accept string with nan and inf

Raymond Hettinger 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

[issue2121] complex constructor doesn't accept string with nan and inf

Raymond Hettinger added the comment: David, at this point, I recommend dropping this one. It has become a time waster. Possibly, there is a refactoring of the code that makes parsing a bit simpler or shares some common code but it is not worth destabilizing the battle-tested code and risking t

[issue4850] Change type and add _Py_ prefix to COUNT_ALLOCS variables

Alexander Belopolsky added the comment: On Tue, Jan 6, 2009 at 10:53 AM, Marc-Andre Lemburg 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 i

[issue4293] Thread Safe Py_AddPendingCall

Antoine Pitrou added the comment: Sorry, forget what I said about the GIL, it looks fine. Perhaps some comments should be added to clarify that matter, however. ___ Python tracker ___ ___

[issue4293] Thread Safe Py_AddPendingCall

Antoine Pitrou 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 imagin

[issue2121] complex constructor doesn't accept string with nan and inf

Cournapeau David 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

[issue4850] Change type and add _Py_ prefix to COUNT_ALLOCS variables

Marc-Andre Lemburg added the comment: On 2009-01-06 15:57, Alexander Belopolsky wrote: > Alexander Belopolsky added the comment: > > On Tue, Jan 6, 2009 at 7:28 AM, Martin v. Löwis > wrote: > .. >> It is not easier, but more difficult. It now requires a change, >> whereas leaving things as-i

[issue2121] complex constructor doesn't accept string with nan and inf

Mark Dickinson added the comment: As Christian says, it's about not increasing code complexity without a good reason. For me, it's also about mental complexity: the set of valid inputs to the complex constructor should be small, and should be easy to understand and to describe. The additio

[issue4850] Change type and add _Py_ prefix to COUNT_ALLOCS variables

Alexander Belopolsky added the comment: On Tue, Jan 6, 2009 at 7:28 AM, Martin v. Löwis 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 th

[issue4753] Faster opcode dispatch on gcc

Antoine Pitrou 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 (

[issue4850] Change type and add _Py_ prefix to COUNT_ALLOCS variables

Marc-Andre Lemburg added the comment: On 2009-01-06 14:22, Martin v. Löwis wrote: > Martin v. Löwis 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. Righ

[issue3826] Problem with SocketIO for closing the socket

Changes by STINNER Victor : -- priority: critical -> release blocker title: BaseHTTPRequestHandler depends on GC to close connections -> Problem with SocketIO for closing the socket ___ Python tracker _

[issue4857] syntax: no unpacking in augassign

STINNER Victor added the comment: Oh yes! I didn't see "(" target_list ")" | "[" target_list "]", sorry. ___ Python tracker ___ ___ Python-bugs

[issue4857] syntax: no unpacking in augassign

jura added the comment: Yes, but target ::= identifier | "(" target_list ")" | ... so (x,y) seems to be a valid target. ___ Python tracker ___

[issue4850] Change type and add _Py_ prefix to COUNT_ALLOCS variables

Martin v. Löwis 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 ___

[issue4857] syntax: no unpacking in augassign

STINNER Victor added the comment: Extract of the grammar: target ::= identifier | ... target_list ::= target ("," target)* [","] assignment_stmt ::= (target_list "=")+ ... augmented_assignment_stmt ::= target augop ... augop ::= "+=" | ... So ther

[issue2121] complex constructor doesn't accept string with nan and inf

Cournapeau David added the comment: > I disagree. *Why* do you think it should work? It fails for many other > types: I don't understand the rationale: why not making something work better if possible ? Also, I don't understand the comparison with Decimal or Fraction; there is a big differenc

[issue4857] syntax: no unpacking in augassign

New submission from jura : 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, canno

[issue4293] Thread Safe Py_AddPendingCall

Kristján Valur Jónsson 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 _

[issue4850] Change type and add _Py_ prefix to COUNT_ALLOCS variables

Marc-Andre Lemburg added the comment: On 2009-01-06 13:28, Martin v. Löwis wrote: > Martin v. Löwis 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 diffi

[issue4850] Change type and add _Py_ prefix to COUNT_ALLOCS variables

Martin v. Löwis 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 sym

[issue4856] Remove checks for win NT

Ulrich Eckhardt 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/f

[issue2121] complex constructor doesn't accept string with nan and inf

Mark Dickinson added the comment: Christian, any comments? Is it okay to close this as a 'won't fix'? ___ Python tracker ___ ___ Python-bugs-l

[issue2121] complex constructor doesn't accept string with nan and inf

Mark Dickinson 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(..)) roun

[issue4856] Remove checks for win NT

Amaury Forgeot d'Arc added the comment: +1 -- nosy: +amaury.forgeotdarc ___ Python tracker ___ ___ Python-bugs-list mailing list Unsub

[issue4805] Make python code compilable with a C++ compiler

Marc-Andre Lemburg added the comment: On 2009-01-05 22:06, Alexander Belopolsky wrote: > Alexander Belopolsky 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 usin

[issue4850] Change type and add _Py_ prefix to COUNT_ALLOCS variables

Marc-Andre Lemburg added the comment: On 2009-01-06 11:28, Martin v. Löwis wrote: > Martin v. Löwis 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 >

[issue4850] Change type and add _Py_ prefix to COUNT_ALLOCS variables

Martin v. Löwis 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 i

[issue3872] Python 2.6rc2: Tix ComboBox error

Dominique Wahli 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 _

[issue2897] include structmember.h in Python.h

Martin v. Löwis 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

[issue2772] Add PendingDeprecationWarning for % formatting

Raymond Hettinger added the comment: Am closing this one. It is pointless and counter-productive unless there is a firm decision that % formatting is definitely going away (and migration tools have been developed). Right now, it looks like there is some chance that it might pull through for a

[issue2897] include structmember.h in Python.h

Raymond Hettinger added the comment: Martin, do you want to make the call on this one? -- assignee: -> loewis nosy: +loewis, rhettinger ___ Python tracker ___ __

[issue4293] Thread Safe Py_AddPendingCall

Kristján Valur Jónsson added the comment: Thanks. What do you mean by making the test a method of TestCAPI? I have found no such class. Are you talking about the python part or the c part? Also, atomicity in the callback is not required, as the callback is never interrupted implicitly. In

[issue4855] Popen(..., shell=True, ...) should allow simple access to the command's PID

Georg Brandl added the comment: As Alexander says: a shell command can spawn any number of subprocesses, or none at all (if e.g. only shell builtins are called). -- nosy: +georg.brandl resolution: -> wont fix status: open -> closed ___ Python tracke

[issue3582] thread_nt.c update

Ulrich Eckhardt added the comment: You're right, Kristján, sorry for the noise. Shouldn't make claims before being fully awake ___ Python tracker ___

[issue3582] thread_nt.c update

Kristján Valur Jónsson added the comment: No, the startup function for beginthreadex() must be __stdcall. From the docs: start_address Start address of a routine that begins execution of a new thread. For _beginthread, the calling convention is either __cdecl or __clrcall; for _beginthreade

[issue4856] Remove checks for win NT

New submission from Ulrich Eckhardt : There are several checks like "GetVersion() < 0x8000" that try to determine whether there is support for the WCHAR versions of the win32 API. Since all support for MS Windows 95, 98 and ME has been dropped, all supported systems support those APIs. Als

[issue3582] thread_nt.c update

Ulrich Eckhardt added the comment: I do have an issue with the patch's startup code. The prototype for the thread entry should be "DWORD WINAPI function(PVOID);". The important distinction is the WINAPI part, which resolves to __stdcall but doesn't have to. I know that some CE targets actuall

[issue4855] Popen(..., shell=True, ...) should allow simple access to the command's PID

Alexander Belopolsky added the comment: This really belongs to python-list rather than the tracker. It is not correct that with shell=False Popen reuses the thread of control of the calling process. You seem to be confusing blocking and reusing the thread of control. Popen always creates a