[issue4707] round() shows undocumented behaviour
Changes by Raymond Hettinger rhettin...@users.sourceforge.net: -- assignee: rhettinger - ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4707 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4714] print opcode stats at the end of pybench runs
Marc-Andre Lemburg m...@egenix.com added the comment: On 2008-12-21 22:37, Antoine Pitrou wrote: New submission from Antoine Pitrou pit...@free.fr: This patch prints opcode statistics at the end of a pybench run if DYNAMIC_EXECUTION_PROFILE has been enabled when compiling the interpreter. Is it ok? Is it better to add it to the Benchmark class? I don't think it's worth doing this for low-level and highly artificial benchmarks like the ones run by pybench. Opcode statistics are much better taken in real life applications, e.g. let Django, Zope, etc. run for a day or two and then look at the opcode statistics. If at all, then opcode statistics should be an optional feature enabled by a command line switch. I'd then create new methods bench.start_opcode_stats(), bench.stop_opcode_stats() and bench.get_opcode_stats(). Also note that this line will result in wrong results: +if opstats: +opstats = [new - old +for new, old in zip(sys.getdxp(), opstats)] It should be: start_opstats = sys.getdxp() ... stop_opstats = sys.getdxp() opstats = [new_value - old_value for new_value, old_value in zip(stop_opstats, start_opstats] ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4714 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4714] print opcode stats at the end of pybench runs
Antoine Pitrou pit...@free.fr added the comment: I don't think it's worth doing this for low-level and highly artificial benchmarks like the ones run by pybench. Well, it can help to know which opcodes are executed when running a particular bunch of sub-tests :) If at all, then opcode statistics should be an optional feature enabled by a command line switch. I'd then create new methods bench.start_opcode_stats(), bench.stop_opcode_stats() and bench.get_opcode_stats(). Also note that this line will result in wrong results: +if opstats: +opstats = [new - old +for new, old in zip(sys.getdxp(), opstats)] You are right, my assumption was simply that the error would be in the noise. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4714 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4716] Python 3.0 halts on shutdown when settrace is set
New submission from Fabio Zadrozny fab...@users.sourceforge.net:
In Python 3.0, the interpreter will not shutdown properly after setting
a tracing function and something goes into stdout.
The code attached shows the problem in action: just execute it and
notice how the interpreter will be kept running after the code has been
executed.
There are some more things that need to be considered:
- If the print('here') is not called, it will shutdown
- If BOTH the print('here') and the sys.settrace(None) is not called, it
will NOT shutdown
Note: I've marked the bug as crash because it's halting, but maybe there
could be a better alternative for it...
--
components: Interpreter Core
files: tracing_test.py
messages: 78169
nosy: fabioz
severity: normal
status: open
title: Python 3.0 halts on shutdown when settrace is set
type: crash
versions: Python 3.0
Added file: http://bugs.python.org/file12422/tracing_test.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4716
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4717] execfile conversion is not correct
New submission from Fabio Zadrozny fab...@users.sourceforge.net: In 2to3, execfile(file, globals, locals) is translated to exec(open(file).read(), globals, locals) But that's not correct, as the actual file from the executed code gets wrong with that. The correct thing would be: exec(compile(open(file).read(), file, 'exec'), globals, locals) So that the name of the file remains correct in the module that's being run. -- components: 2to3 (2.x to 3.0 conversion tool) messages: 78170 nosy: fabioz severity: normal status: open title: execfile conversion is not correct versions: Python 3.0 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4717 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4718] wsgiref package totally broken
New submission from Dmitry Vasiliev d...@hlabs.spb.ru: It seems the wsgiref package was copied from Python 2.* without any modifications. There are already 3 issues about that but they only describe a part of the problem so I decided to start a new one. The issues was: http://bugs.python.org/issue3348 http://bugs.python.org/issue3795 http://bugs.python.org/issue4522 The attached patch fix the problem with the following changes: - Fixed headers handling in wsgiref/simple_server.py; - Fixed encoding problems. Now WSGI applications must return iterable with bytes but start_response() allow status and headers as bytes and as strings. wsgi.input file-like now use BytesIO instead of StringIO; - Fixed tests; - Updated documentation examples; -- components: Library (Lib) files: wsgiref.patch keywords: patch messages: 78171 nosy: hdima severity: normal status: open title: wsgiref package totally broken type: crash versions: Python 3.0 Added file: http://bugs.python.org/file12423/wsgiref.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4718 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4718] wsgiref package totally broken
Antoine Pitrou pit...@free.fr added the comment: Phillip, do you have time to take a look at it? We really *must* fix wsgiref in py3k... -- nosy: +pitrou, pje priority: - critical ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4718 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4719] sys.exc_clear() not flagged in any way
New submission from Fabio Zadrozny fab...@users.sourceforge.net: sys.exc_clear() does not seem to exist in Python 3.0 anymore, so, a way to deal with it should be provided (maybe put a #TODO comment and point to somewhere explaining what happened?). -- components: 2to3 (2.x to 3.0 conversion tool) messages: 78173 nosy: fabioz severity: normal status: open title: sys.exc_clear() not flagged in any way versions: Python 3.0 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4719 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4716] Python 3.0 halts on shutdown when settrace is set
Antoine Pitrou pit...@free.fr added the comment: I haven't investigated, but in py3k print() has currently bits written in Python, which means it will get (recursively) traced when called from the trace function. It can of course have all kinds of funny implications! -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4716 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4719] sys.exc_clear() not flagged in any way
Antoine Pitrou pit...@free.fr added the comment: There should be no need for sys.exc_clear() anymore. What are you trying to achieve? -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4719 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4719] sys.exc_clear() not flagged in any way
Antoine Pitrou pit...@free.fr added the comment: In any case, probably a documentation issue :)) -- assignee: - georg.brandl components: +Documentation -2to3 (2.x to 3.0 conversion tool) nosy: +georg.brandl priority: - normal type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4719 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4719] sys.exc_clear() not flagged in any way
Fabio Zadrozny fab...@users.sourceforge.net added the comment: When created it was already marked as a 2to3 issue (in the components), so, for clarity, yes: it's a 2to3 issue (what should the user do with that when porting... I think that the 2to3 should do something regarding that... maybe just changing it for a 'pass'?). Also, the docs say it was removed, but they don't leave clear that it's not needed because no info is stored anymore (because that was needed just to clear the frame that was kept alive when an exception was raised -- so, note that I'm assuming that issue was fixed and it's not needed anymore, but the docs don't make that clear) ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4719 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4720] Extension function optional argument specification | causes RuntimeError
New submission from Pearu Peterson pe...@users.sourceforge.net:
Calling the following extension function
static PyObject *
baz(PyObject *self, PyObject *args, PyObject *keywds)
{
static char *kwlist[] = {NULL};
if (!PyArg_ParseTupleAndKeywords(args,keywds,|:bar.baz, kwlist))
return NULL;
return Py_BuildValue();
}
raises
RuntimeError: more argument specifiers than keyword list entries
(remaining format:'|:bar.baz')
in Python 2.6 but it used to work with earlier versions of Python.
This bug breaks all f2py generated extension modules when using Python 2.6.
--
components: Extension Modules
files: barmodule.c
messages: 78179
nosy: pearu
severity: normal
status: open
title: Extension function optional argument specification | causes RuntimeError
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file12424/barmodule.c
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4720
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4719] sys.exc_clear() not flagged in any way
Antoine Pitrou pit...@free.fr added the comment: Le lundi 22 décembre 2008 à 12:48 +, Fabio Zadrozny a écrit : Fabio Zadrozny fab...@users.sourceforge.net added the comment: When created it was already marked as a 2to3 issue Oops, sorry. (because that was needed just to clear the frame that was kept alive when an exception was raised To clear the frame and the exception object itself, yes. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4719 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4719] sys.exc_clear() not flagged in any way
Benjamin Peterson musiccomposit...@gmail.com added the comment: Actually, I think this should just get a Py3k warning in 2.6 and 2.7. 2to3 doesn't deal with anything else that has been removed. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4719 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4719] sys.exc_clear() not flagged in any way
Fabio Zadrozny fab...@users.sourceforge.net added the comment: 2to3 doesn't deal with anything else that has been removed. That seems a bit odd for me... isn't it the perfect place for that? (it doesn't even need to change the code for a pass, but it could give the user some warning about it at that specific line -- maybe with a pointer to a place explaining why it was removed). I think that if 2to3 flags it, it can make the porting cycle faster than having to run the code (and expecting a huge code-coverage) to get those -- especially as sys.exc_clear is mostly used in cases where you are expecting some exception... and I believe not everyone gives as much emphasis for exception cases as they'd for the cases in the 'regular flow' ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4719 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4704] Update pybench for python 3.0
Mark Dickinson dicki...@gmail.com added the comment: Thanks for the responses! I don't think should go into 3.0.1 - they are a new feature and not a bug fix. But if these changes don't go into 3.0.1, and the removal of cmp does, that means that pybench won't run on 3.0.1. It seems to me that we could make a strong case for this being a bugfix... ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4704 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4704] Update pybench for python 3.0
Marc-Andre Lemburg m...@egenix.com added the comment: On 2008-12-22 15:07, Mark Dickinson wrote: Mark Dickinson dicki...@gmail.com added the comment: Thanks for the responses! I don't think should go into 3.0.1 - they are a new feature and not a bug fix. But if these changes don't go into 3.0.1, and the removal of cmp does, that means that pybench won't run on 3.0.1. It seems to me that we could make a strong case for this being a bugfix... ... or a good case for not removing cmp() from 3.0.1 :-) I have a feeling that people are mixing up the reasons for removal of the __cmp__ slot and the utility of the cmp() builtin. Those two should be treated as separate issues, IMHO. Anyway, like I said: the release manager should decide. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4704 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1289118] timedelta multiply and divide by floating point
STINNER Victor victor.stin...@haypocalc.com added the comment: I like this idea, it's the opposite of the issue #2706. -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1289118 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4291] Allow Division of datetime.timedelta Objects
STINNER Victor victor.stin...@haypocalc.com added the comment: See related issues: #1289118 and #2706. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4291 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706039] Added clearerr() to clear EOF state
Scott Dial sc...@scottdial.com added the comment: I believe the original patch is overreaching. I believe the changes to fileobject.c should've been much simpler, just as the title describes (adding clearerr() just before performing reads on the FILE handles). I've attached a much simpler patch that I believe corrects the issue, but I don't have an OS X platform to try it on. -- nosy: +scottdial Added file: http://bugs.python.org/file12425/fileobject.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1706039 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4718] wsgiref package totally broken
Antoine Pitrou pit...@free.fr added the comment: FYI, instead of trying to do exhaustive type checking in _check_type(), you can just rely on duck typing and catch the TypeError: str(ba, utf-8) 'a' str(bytearray(ba), utf-8) 'a' str(memoryview(ba), utf-8) 'a' str(1, utf-8) Traceback (most recent call last): File stdin, line 1, in module TypeError: coercing to str: need string or buffer, int found ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4718 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4721] pythonw.exe crash in GU application(PythonWX)
New submission from George g...@mail.gr: I have Python 2.6.1 in Windows Vista. It happened in Python 2.6 and I hoped it would be fixed. I don't know what happenes in other versions. When I open a file containing a python program(.py/.pyw and even one compiled with py2exe) made by using the PythonWX GUI programming libraries it crashes immediately after the mouse hovers over the window created by the program(spesifically in the area inside it). It happenes both when the program is a .py file and a .pyw file or one compiled with py2exe. I get a message that the program stopped working. Shouldn'nt I get a message about wrong code? It doesn't crash in the Python Shell, but it has happened ,too, a few times. Do I do something wrong? Is there something I should know? The programs I use are not made by me(I can't yet make mine), but they are examples downloaded or copy-pasted. Here is one: import wx app = wx.PySimpleApp() frame = wx.Frame(None,-1,Hello World) frame.Show(True) app.MainLoop() Please tell me what is wrong or what I should do. -- files: simple editor.pyw messages: 78189 nosy: george severity: normal status: open title: pythonw.exe crash in GU application(PythonWX) type: crash versions: Python 2.6 Added file: http://bugs.python.org/file12426/simple editor.pyw ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4721 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4721] pythonw.exe crash in GUI application(PythonWX)
Changes by George g...@mail.gr: -- title: pythonw.exe crash in GU application(PythonWX) - pythonw.exe crash in GUI application(PythonWX) ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4721 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4722] _winreg.QueryValue fault while reading mangled registry values
New submission from Alex malicious.wiz...@gmail.com: == What steps will reproduce the problem? 1. Create registry key (let's assume it's located in HKEY_CURRENT_USER\TestKey); 2. Walk to it in regedit; 3. Right-click on (Default) and select Modify binary data; 4. Leave everything blank and press OK; 5. Go to Python and execute this: import _winreg _winreg.QueryValue(_winreg.HKEY_CURRENT_USER, 'TestKey') Traceback (most recent call last): File stdin, line 1, in module SystemError: ..\Objects\stringobject.c:4271: bad argument to internal function == What is the expected output? What do you see instead? I expect either returning '' or some ValueError indicating that source string is malformed. == What version of the product are you using? On what operating system? 1. Windows XP Professional SP2 English; 2. Tested on Python 2.5.2; 3. Tested on Python 2.6.1; 4. Tested on Stackless Python 2.5.2. == Please provide any additional information below. And yes, I know that this function is lame and everybody using it also is lame, but it's not really a reason to include buggy functions, right? -- components: Library (Lib), Windows messages: 78190 nosy: malicious.wizard severity: normal status: open title: _winreg.QueryValue fault while reading mangled registry values type: behavior versions: Python 2.5, Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4722 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4721] pythonw.exe crash in GUI application(PythonWX)
Martin v. Löwis mar...@v.loewis.de added the comment: Please understand that the bug tracker is not a place to obtain help, but a place to provide help. You can help by analysing the source of the crash in a debugger, such as the one of Visual Studio. In any case, it seems that the crash is specific to wxPython, which is not part of the Python 2.6 distribution. Please report it to the authors of wxPython. Closing this report as 3rd-party. -- nosy: +loewis resolution: - invalid status: open - closed versions: +3rd party -Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4721 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4718] wsgiref package totally broken
Phillip J. Eby p...@telecommunity.com added the comment: If you want to change to using bytes, you're going to have to take it to the Web-SIG and hash out a revision to PEP 333, which at the moment requires the use of strings, period. This has nothing to do with the desirability of bytes vs. strings; I am sure that if Python had bytes from day 1, bytes would've been the way to go with it. But simply changing the reference library is not the way to change the spec. In the meantime, as far as I'm aware, there are two other patches pending to address these issues, but I'm not in a position to assess their readiness/correctness since I have yet to even download Py3K. In principle, I approve their approaches, so if someone else can handle the code review, those fixes could in principle be put in without changing the PEP. But to put *this* patch in, the PEP would have to be changed. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4718 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4718] wsgiref package totally broken
Antoine Pitrou pit...@free.fr added the comment: If you want to change to using bytes, you're going to have to take it to the Web-SIG and hash out a revision to PEP 333, which at the moment requires the use of strings, period. What was called str in 2.x has become the bytes object in py3k. What was called unicode in 2.x has become str in py3k. (roughly) Given the meaning of the term string and its possible acceptions have dramatically changed between 2.x and py3k, how does this patch violate the PEP more than any other? Actually, the PEP says: HTTP does not directly support Unicode, and neither does this interface. All encoding/decoding must be handled by the application; all strings passed to or from the server must be standard Python *byte strings*, not Unicode objects. [emphasis mine] So, not accepting bytes in py3k is clearly a violation of the PEP! ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4718 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4718] wsgiref package totally broken
Dmitry Vasiliev d...@hlabs.spb.ru added the comment: Antoine Pitrou wrote: FYI, instead of trying to do exhaustive type checking in _check_type(), you can just rely on duck typing and catch the TypeError: Good point! I'll update the patch soon. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4718 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4718] wsgiref package totally broken
Changes by Antoine Pitrou pit...@free.fr: -- priority: critical - release blocker stage: - patch review versions: +Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4718 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3795] wsgiref.simple_server fails to run demo_app
Changes by Antoine Pitrou pit...@free.fr: -- superseder: - wsgiref package totally broken ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3795 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3348] Cannot start wsgiref simple server in Py3k
Antoine Pitrou pit...@free.fr added the comment: There's a proper patch in #4718, marking this one in duplicate. -- resolution: - duplicate status: open - closed superseder: - wsgiref package totally broken ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3348 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4718] wsgiref package totally broken
Dmitry Vasiliev d...@hlabs.spb.ru added the comment: Antoine Pitrou wrote: If you want to change to using bytes, you're going to have to take it to the Web-SIG and hash out a revision to PEP 333, which at the moment requires the use of strings, period. What was called str in 2.x has become the bytes object in py3k. What was called unicode in 2.x has become str in py3k. (roughly) Agreed, moreover it's time for Python 3.0.1 and we need to decide - apply a patch or just remove wsgiref completely for now. Keep wsgiref just as nonworking piece of code is the worse solution which can made questionable all WSGI effort. Given that old str has been replaced by bytes in Python 3 I think the patch is a correct implementation of the PEP from the Python 3's point of view. To avoid confusion note about the meaning of the term *string* can be added to the PEP later. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4718 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4723] os.path.basename error on directory names with numbers
New submission from Klemens Häckel clic...@linuxmail.org: I am using python for some backup tasks, and recently i found a problem whe i have certain directory names. Probably the problem is only in windows, however i would like You to know. I verified the same behaviour in (WindowsXP, spanish, SP3) using Python 2.5.2 and also in 2.6.1 (installers from Python.org). In my case i have directory names, beginning with year/month numbers. Aparrently python is confusing something, so os.path.basename is not working: dd = 'C:\downloads\hacking\0812logcompress' os.path.basename(dd) 'hacking\x00812logcompress' dd = 'C:\downloads\hacking\logcompress' os.path.basename(dd) 'logcompress' -- components: Windows messages: 78197 nosy: kle_py severity: normal status: open title: os.path.basename error on directory names with numbers type: behavior versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4723 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4723] os.path.basename error on directory names with numbers
Tim Golden m...@timgolden.me.uk added the comment: You need to use raw strings or to use forward-slashes in your pathnames: rc:\downloads\hacking\0812logcompress or c:/downloads/hacking/0812logcompress The sequence \0 has a special meaning in strings, introducing an octal escape, I think. -- nosy: +tim.golden ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4723 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4724] setting f_exc_traceback aborts in debug builds
New submission from Benjamin Peterson musiccomposit...@gmail.com: $ ./python.exe Python 2.7a0 (trunk:67899, Dec 22 2008, 11:17:09) [GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin Type help, copyright, credits or license for more information. import sys [36275 refs] sys._getframe(0).f_exc_traceback = 23 Python/ceval.c:2720: failed assertion `tstate-frame-f_exc_traceback == NULL' Abort trap -- components: Interpreter Core messages: 78199 nosy: benjamin.peterson priority: high severity: normal status: open title: setting f_exc_traceback aborts in debug builds versions: Python 2.6, Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4724 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4723] os.path.basename error on directory names with numbers
Martin v. Löwis mar...@v.loewis.de added the comment: Tim is right; \0 is an octal escape (for the byte with the ordinal value 0). -- nosy: +loewis resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4723 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4719] sys.exc_clear() not flagged in any way
Benjamin Peterson musiccomposit...@gmail.com added the comment: In fact, there is already a Py3k warning for sys.exc_clear(). I'm still not convinced that 2to3 should play a role. What should it do? Simply remove the call? I'm apprehensive about trying to guess the intention of the user. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4719 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4719] sys.exc_clear() not flagged in any way
Antoine Pitrou pit...@free.fr added the comment: If this is already handled by the -3 flag then I agree it's not a bug. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4719 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4719] sys.exc_clear() not flagged in any way
Changes by Benjamin Peterson musiccomposit...@gmail.com: -- resolution: - wont fix status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4719 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4725] reporting file locations in egg (and other package) files
New submission from rocky bernstein ro...@gnu.org: When listing a traceback or showing stack frames or implementing a debugger (or a tool which wants to track the exact location of the source code), how is one supposed to detect a file located inside an egg or some other archive mechanism? There are a number of issues, I think. First, I think some sort of consistent naming convention would be helpful. Here's an example of the current situation. I have a file called tracer.py inside egg /usr/lib/python2.5/site-packages/tracer-0.1.0-py2.5.egg/tracer.py and I get an exception inside of that. The traceback shows this: File build/bdist.linux-i686/egg/tracer.py, line 216, in size The file information comes from frame.f_code.co_filename and its relation to a file is a bit nebulous since there is no file either in the filesystem with that path suffix nor a file in an with that name. (It's possible there was a file with that suffix at one time during the build of the egg.) So possibly this is a bug. Via the __loader__ key in the tracer module's __dict__ hash (a zipimporter object) there is a _files hash which has a key tracer.py with value /usr/lib/python2.5/site-packages/tracer-0.1.0-py2.5.egg/tracer.py. This seems to correspond to a file tracer.py in zip file: /usr/lib/python2.5/site-packages/tracer-0.1.0-py2.5.egg Glomming the two parts together as one entity or one name is a bit weird and means that things that work on files will have do some parsing to figure out that this there is a member inside an archive (and egg here). PEP 302 has lots of interesting things in it such as a way to get the file source text, but it doesn't specify uniform file *names* of either the surrounding package/archive or the member inside that. So possibly this is an omission or something that should be added. Finally looking at linecache.py, the function update_cache() has a routine to do some sort of filename resolution consulting loaders using the API of PEP 302. Possibly the name resolution part (without reading file data) might be made callable by itself so that it returns a package/archive name and a package/archive member name. -- messages: 78203 nosy: rocky severity: normal status: open title: reporting file locations in egg (and other package) files type: behavior versions: Python 2.5, Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4725 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1524639] Fix Tkinter Tcl-commands memory-leaks
Guilherme Polo ggp...@gmail.com added the comment: I hope you are not too bored for me commenting on this again. So, I have re-though about this issue today and decided to solve it differently (and will include a patch here this time, don't worry about mentions to external repo this time). To solve the problem I replaced the tk.call method in the Tk so it can remove registered commands in the call in case it fails. The other problems reported in this issue are also solved by it, and others that weren't reported are too: Misc.selection_handle (just to name one, but there are others) could leave a undesired item in _tclCommands too. Another advantage of this solution is that extensions benefit from it, and they do not need to change their code (except if they are using a collection of internal functions, which they shouldn't, affected by this patch). Added file: http://bugs.python.org/file12427/keep_tclcommands_correct.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1524639 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1187] pipe fd handling issues in subprocess.py on POSIX
pw p...@padd.com added the comment: Stumbled on this bug a different way in 2.5.2. My code worked in 2.5, which included change 51793, but fails in 2.5.1 and beyond due to the reimplementation in 53294. Dustin's patch, applied by hand to 2.5.2, fixes things for me. -- nosy: +pw versions: +Python 2.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1187 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4726] doctest gets line numbers wrong due to quotes in comments
New submission from guyer gu...@nist.gov: My text editor places a comment block at the top of each source file with a block of information about the author, the project, license, etc. One (rather pointless) line of this block looks like # FILE: somefile.py The re in `_find_lineno()` misinterprets this line as the beginning of the docstring. I believe the attached patch maintains the spirit of the re, while avoiding this false positive. -- components: Tests files: doctest_find_lineno.diff keywords: patch messages: 78206 nosy: guyer severity: normal status: open title: doctest gets line numbers wrong due to quotes in comments versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7 Added file: http://bugs.python.org/file12428/doctest_find_lineno.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4726 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4718] wsgiref package totally broken
Dmitry Vasiliev d...@hlabs.spb.ru added the comment: New version of the patch: - Now only Unicode strings are allowed as status and headers because allowing bytes leads to big changes in wsgiref.validate and wsgiref.handlers; -- versions: -Python 3.1 Added file: http://bugs.python.org/file12429/wsgiref2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4718 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1524639] Fix Tkinter Tcl-commands memory-leaks
Changes by Guilherme Polo ggp...@gmail.com: Removed file: http://bugs.python.org/file12427/keep_tclcommands_correct.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1524639 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1524639] Fix Tkinter Tcl-commands memory-leaks
Changes by Guilherme Polo ggp...@gmail.com: Added file: http://bugs.python.org/file12430/keep_tclcommands_correct.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1524639 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4717] execfile conversion is not correct
Benjamin Peterson musiccomposit...@gmail.com added the comment: Fixed in r67900. -- nosy: +benjamin.peterson resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4717 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4720] Extension function optional argument specification | causes RuntimeError
Benjamin Peterson musiccomposit...@gmail.com added the comment: Thanks for the report! Fixed in r67905. -- nosy: +benjamin.peterson resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4720 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4169] library/turtle.rst does not format properly in PDF mode
Winfried Plappert winfried.plapp...@gmx.de added the comment: When looking at the PDF documentation for Python 2.6.1, the issue4169 is gone away. What has changed? I think we can close 4169 now. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4169 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4169] library/turtle.rst does not format properly in PDF mode
Changes by Benjamin Peterson musiccomposit...@gmail.com: -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4169 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4162] library.pdf - Section 17.6.4 Examples - Multiprocessing - Formatting got lost
Changes by Benjamin Peterson musiccomposit...@gmail.com: -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4162 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4162] library.pdf - Section 17.6.4 Examples - Multiprocessing - Formatting got lost
Winfried Plappert winfried.plapp...@gmx.de added the comment: Changes to Sphinx fixed issue4162 for Python version 2.6.1. This issue can be closed. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4162 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4173] PDF documentation: long verbatim lines are cut off at right hand side
Winfried Plappert winfried.plapp...@gmx.de added the comment: see also issue4160. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4173 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4160] library.pdf - Section 12.13.2 Connection Objects - example cut off at the right hand side
Winfried Plappert winfried.plapp...@gmx.de added the comment: see also issue4173, might be the same root cause. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4160 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4718] wsgiref package totally broken
Phillip J. Eby p...@telecommunity.com added the comment: At 03:37 PM 12/22/2008 +, Antoine Pitrou wrote: So, not accepting bytes in py3k is clearly a violation of the PEP! On the contrary. Please read the two paragraphs *after* the one you quoted. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4718 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4718] wsgiref package totally broken
Phillip J. Eby p...@telecommunity.com added the comment: To be quite clear: this change requires discussion on the Web-SIG and an appropriate revision of the PEP. Ideally, the patch should include the necessary PEP revision. The Web-SIG discussion regarding a switch to bytes should also take into consideration the effects of running 2to3 on existing WSGI applications and/or servers. Will their code be converted to use bytes, or Unicode? The previous choice to use Unicode was based on source compatibility across Python implementations, so this shouldn't be thrown out on the basis of simple expediency. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4718 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3959] Add Google's ipaddr.py to the stdlib
Benjamin Peterson musiccomposit...@gmail.com added the comment: Now that 2.6 and 3.0 are out of the way, how should we move forward? Will a PEP be required? ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4723] os.path.basename error on directory names with numbers
Klemens Häckel clic...@linuxmail.org added the comment: Of course my example was not that trivial, since i do sort of directory-walking, and i get the value passed over. And in Windows it is with backslash! Ok, i will check my code, wherever i use os.path.basename and change it to process as raw string. Thank You ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4723 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3959] Add Google's ipaddr.py to the stdlib
Martin v. Löwis mar...@v.loewis.de added the comment: Now that 2.6 and 3.0 are out of the way, how should we move forward? I think some committer needs to take charge and work with the authors on merging the code. If pmoody wants commit access, that should be set up, and he should add it himself in a commit-after-review manner (with an actual patch, including documentation and tests). If he doesn't want to do the integration, some committer needs to volunteer - I personally won't (lack of time). In any case, we would need a copyright form signed, unless Guido can confirm that the code is covered by some agreement between Google and the PSF. Will a PEP be required? I doubt that; a quick announcement to python-dev might be sufficient (in general, a PEP should only be done if dissent is likely). It seems that Victor didn't actually disagree to integrating this package; we should somehow encourage IPy users to review the code and comment on the (possibly lack of) functionality. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4723] os.path.basename error on directory names with numbers
Martin v. Löwis mar...@v.loewis.de added the comment: Of course my example was not that trivial, since i do sort of directory-walking, and i get the value passed over. And in Windows it is with backslash! Not necessarily. Windows supports forward slashes as path separators just as well. Ok, i will check my code, wherever i use os.path.basename and change it to process as raw string. You can consider avoiding the path separator by using os.path.join all the time. There might still be places where you need to provide absolute file names as literals in your source code, but those should be few. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4723 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4725] reporting file locations in egg (and other package) files
Martin v. Löwis mar...@v.loewis.de added the comment: If this message is about multiple issues (as the second paragraph suggests), they should be reported separately. As it stands, this is too much text for me to consider, and it might be too much for other readers as well. When you split it up, please consider whether the things are bugs or wishes, and whether they apply to Python proper, or some other library (e.g. setuptools - eggs are not part of Python). -- nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4725 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4725] reporting file locations in egg (and other package) files
rocky bernstein ro...@gnu.org added the comment: Martin v. Löwis mar...@v.loewis.de added the comment: If this message is about multiple issues (as the second paragraph suggests), they should be reported separately. As it stands, this is too much text for me to consider, and it might be too much for other readers as well. Fair enough. So let's start with I guess the most important thing. PEP 302 describes an importer protocol. Given that, I don't understand how I can reliably get full (package) information about where the source code resides from a stack frame or code object. For code that comes from packages like eggs (but not necessarily restricted to eggs as there may be other packaging mechanisms), the information would contain the package file (e.g. /usr/lib/python2.5/site-packages/tracer-0.1.0-py2.5.egg), a member inside that (e.g. tracer.py), and possibly loader/packaging information (e.g. zipimporter). For a specific mechanism like zipimporter, no doubt one can hack something based on how the package mechanism is currently implemented. But given there is an API for import hooks that package mechanisms currently adhere to, shouldn't there also be some sort of API for untangling what has gone on? A use case here is in a stack trace or a debugger where an error occured. For example does this come from an egg? And if so, which one? Perhaps I have missed something in PEP 302, or perhaps this is defined elsewhere. Please elucidate. When you split it up, please consider whether the things are bugs or wishes, and whether they apply to Python proper, or some other library (e.g. setuptools - eggs are not part of Python). Ok. I'll probably add one more bug report for now see where things go. Based on the outcome of these queries, I'll possibly add more. The problem I have with splitting things up too soon is that I'm not sure where the problem lies. As stated above, I think the crux is that given that there are now package mechanisms that bundle source code into a file, the notion of a file location should be adjusted to include the package and/or importer. If it turns out that there already is this notion, then it could be that certain implementations aren't aware of it and/or don't adhere to it. -- nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4725 ___ ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4725 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4727] pickle/copyreg doesn't support keyword only arguments in __new__
New submission from Erick Tryzelaar idade...@users.sourceforge.net: According to both of these bugs: http://bugs.python.org/issue1398 http://bugs.python.org/issue4331 pickle can't pickle functools.partial objects. It looks the underlying reason is that objects that pickle can't handle objects with __new__ and keyword only arguments. To support this, would this require a new pickle protocol and a __getnewfullargs__ that returns a tuple and dict? -- components: Library (Lib) messages: 78222 nosy: erickt severity: normal status: open title: pickle/copyreg doesn't support keyword only arguments in __new__ type: feature request versions: Python 2.7, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4727 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1025540] urllib2 http auth
Senthil orsent...@gmail.com added the comment: This issue makes a request to implement, plain-text inurl password authentication like https://user:passw...@host:port/ for HTTP Basic Authentication. for urllib2. As per rfc3986, this is strongly discouraged and is deprecated. See the section: 3.2.1. User Information Use of the format user:password in the userinfo field is deprecated. Applications should not render as clear text any data after the first colon (:) character found within a userinfo subcomponent unless the data after the colon is the empty string (indicating no password). Applications may choose to ignore or reject such data when it is received as part of a reference and should reject the storage of such data in unencrypted form. The passing of authentication information in clear text has proven to be a security risk in almost every case where it has been used. Also, this was reported on 2004-09-10! We do not have any other similar requests inline. AFAIK, current urllib2 will authenticate and fetch the documents with HTTP Basic authentication when password is passed along in the url like the case specifies. I do not what was the case in 2004. My conclusion for this request is to Close it as either Invalid or Wont Fix. -- nosy: +orsenthil ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1025540 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4728] Endianness and universal builds problems
New submission from Cournapeau David da...@ar.media.kyoto-u.ac.jp:
I had some problems with python and universal builds related to the
WORDS_BIGENDIAN macro. Because universal builds are built in one pass
(one configure), the AC_C_ENDIAN cannot be used reliably. Example:
int main()
{
#ifdef WORDS_BIGENDIAN
printf(Big endian macro defined\n);
#else
printf(No big endian macro defined\n);
#endif
return 0;
}
If I build this against python 2.5, it prints no big endian macro (I
have an intel CPU), as expected. But with python 2.6.0 (official binary
from python.org), I get Big endian macro defined.
--
messages: 78224
nosy: cdavid
severity: normal
status: open
title: Endianness and universal builds problems
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4728
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4729] Documentation under 'pass' statement talks about exception very early.
New submission from Senthil orsent...@gmail.com: This is a new change in the documentation. Tutorial - More Control Flow Tools - pass Statements There is a new section which says: However, as pass is silently ignored, a better choice may be to raise a NotImplementedError exception: While what the section says is correct, but its placement in the documentation is inappropriate. The tutorial has not yet introduced the reader to function and Exceptions, and this portion has squeezed its way in between. I feel, this needs to be rearranged. Georg, what is your thought? -- assignee: georg.brandl components: Documentation messages: 78225 nosy: georg.brandl, orsenthil severity: normal status: open title: Documentation under 'pass' statement talks about exception very early. type: behavior versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4729 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4660] multiprocessing.JoinableQueue task_done() issue
Brian br...@merrells.org added the comment: Here are a few stabs at how this might be addressed. 1) As originally suggested. Allow task_done() to block waiting to acquire _unfinished_tasks. This will allow the put() process to resume, release() _unfinished_tasks at which point task_done() will unblock. No harm, no foul but you do lose some error checking (and maybe some performance?) 2) One can't protect JoinableQueue.put() by simply acquiring _cond before calling Queue.put(). Fixed size queues will block if the queue is full, causing deadlock when task_done() can't acquire _cond. The most obvious solution would seem to be reimplementing JoinableQueue.put() (not simply calling Queue.put()) and then inserting self._unfinished_tasks.release() into a protected portion. Perhaps: def put(self, obj, block=True, timeout=None): assert not self._closed if not self._sem.acquire(block, timeout): raise Full self._notempty.acquire() self._cond.acquire() try: if self._thread is None: self._start_thread() self._buffer.append(obj) self._unfinished_tasks.release() self._notempty.notify() finally: self._cond.release() self._notempty.release() We may be able to get away with not acquiring _cond as _notempty would provide some protection. However its relationship to get() isn't entirely clear to me so I am not sure if this would be sufficient. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4660 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
