[issue4660] multiprocessing.JoinableQueue task_done() issue

Brian 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

[issue4729] Documentation under 'pass' statement talks about exception very early.

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

[issue4728] Endianness and universal builds problems

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

[issue1025540] urllib2 http auth

Senthil 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 Inform

[issue4727] pickle/copyreg doesn't support keyword only arguments in __new__

New submission from Erick Tryzelaar : 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

[issue4725] reporting file locations in egg (and other package) files

rocky bernstein added the comment: > > Martin v. Löwis 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 reader

[issue4725] reporting file locations in egg (and other package) files

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

[issue4723] os.path.basename error on directory names with numbers

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

[issue3959] Add Google's ipaddr.py to the stdlib

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

[issue4723] os.path.basename error on directory names with numbers

Klemens Häckel 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 _

[issue3959] Add Google's ipaddr.py to the stdlib

Benjamin Peterson 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 ___ __

[issue4718] wsgiref package totally broken

Phillip J. Eby 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 e

[issue4718] wsgiref package totally broken

Phillip J. Eby 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

[issue4160] library.pdf - Section 12.13.2 Connection Objects - example cut off at the right hand side

Winfried Plappert added the comment: see also issue4173, might be the same root cause. ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue4173] PDF documentation: long verbatim lines are cut off at right hand side

Winfried Plappert added the comment: see also issue4160. ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyt

[issue4162] library.pdf - Section 17.6.4 Examples - Multiprocessing - Formatting got lost

Winfried Plappert added the comment: Changes to Sphinx fixed issue4162 for Python version 2.6.1. This issue can be closed. ___ Python tracker ___ _

[issue4162] library.pdf - Section 17.6.4 Examples - Multiprocessing - Formatting got lost

Changes by Benjamin Peterson : -- resolution: -> fixed status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue4169] library/turtle.rst does not format properly in PDF mode

Changes by Benjamin Peterson : -- resolution: -> fixed status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue4169] library/turtle.rst does not format properly in PDF mode

Winfried Plappert 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 _

[issue4720] Extension function optional argument specification | causes RuntimeError

Benjamin Peterson added the comment: Thanks for the report! Fixed in r67905. -- nosy: +benjamin.peterson resolution: -> fixed status: open -> closed ___ Python tracker ___ _

[issue4717] execfile conversion is not correct

Benjamin Peterson added the comment: Fixed in r67900. -- nosy: +benjamin.peterson resolution: -> fixed status: open -> closed ___ Python tracker ___

[issue1524639] Fix Tkinter Tcl-commands memory-leaks

Changes by Guilherme Polo : Added file: http://bugs.python.org/file12430/keep_tclcommands_correct.diff ___ Python tracker ___ ___ Python-bug

[issue1524639] Fix Tkinter Tcl-commands memory-leaks

Changes by Guilherme Polo : Removed file: http://bugs.python.org/file12427/keep_tclcommands_correct.diff ___ Python tracker ___ ___ Python-b

[issue4718] wsgiref package totally broken

Dmitry Vasiliev 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/wsgiref

[issue4726] doctest gets line numbers wrong due to quotes in comments

New submission from guyer : 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 l

[issue1187] pipe fd handling issues in subprocess.py on POSIX

pw 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.

[issue1524639] Fix Tkinter Tcl-commands memory-leaks

Guilherme Polo 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

[issue4725] reporting file locations in egg (and other package) files

New submission from rocky bernstein : 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 numbe

[issue4719] sys.exc_clear() not flagged in any way

Changes by Benjamin Peterson : -- resolution: -> wont fix status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing l

[issue4719] sys.exc_clear() not flagged in any way

Antoine Pitrou added the comment: If this is already handled by the -3 flag then I agree it's not a bug. ___ Python tracker ___ ___ Python-bugs

[issue4719] sys.exc_clear() not flagged in any way

Benjamin Peterson 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. _

[issue4723] os.path.basename error on directory names with numbers

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

[issue4724] setting f_exc_traceback aborts in debug builds

New submission from Benjamin Peterson : $ ./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_tracebac

[issue4723] os.path.basename error on directory names with numbers

Tim Golden added the comment: You need to use raw strings or to use forward-slashes in your pathnames: r"c:\downloads\hacking\0812logcompress" or "c:/downloads/hacking/0812logcompress" The sequence \0 has a special meaning in strings, introducing an octal escape, I think. -- nosy: +

[issue4723] os.path.basename error on directory names with numbers

New submission from Klemens Häckel : 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

[issue4718] wsgiref package totally broken

Dmitry Vasiliev 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

[issue3348] Cannot start wsgiref simple server in Py3k

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

[issue3795] wsgiref.simple_server fails to run demo_app

Changes by Antoine Pitrou : -- superseder: -> wsgiref package totally broken ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue4718] wsgiref package totally broken

Changes by Antoine Pitrou : -- priority: critical -> release blocker stage: -> patch review versions: +Python 3.1 ___ Python tracker ___ _

[issue4718] wsgiref package totally broken

Dmitry Vasiliev 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

[issue4718] wsgiref package totally broken

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

[issue4718] wsgiref package totally broken

Phillip J. Eby 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 i

[issue4721] pythonw.exe crash in GUI application(PythonWX)

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

[issue4722] _winreg.QueryValue fault while reading mangled registry values

New submission from Alex : == 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 Pytho

[issue4721] pythonw.exe crash in GUI application(PythonWX)

Changes by George : -- title: pythonw.exe crash in GU application(PythonWX) -> pythonw.exe crash in GUI application(PythonWX) ___ Python tracker ___ _

[issue4721] pythonw.exe crash in GU application(PythonWX)

New submission from George : 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 GU

[issue4718] wsgiref package totally broken

Antoine Pitrou 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(b"a", "utf-8") 'a' >>> str(bytearray(b"a"), "utf-8") 'a' >>> str(memoryview(b"a"), "utf-8") 'a' >>> str(1, "utf-8") Traceba

[issue1706039] Added clearerr() to clear EOF state

Scott Dial 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 corr

[issue4291] Allow Division of datetime.timedelta Objects

STINNER Victor added the comment: See related issues: #1289118 and #2706. ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue1289118] timedelta multiply and divide by floating point

STINNER Victor added the comment: I like this idea, it's the opposite of the issue #2706. -- nosy: +haypo ___ Python tracker ___ __

[issue4704] Update pybench for python 3.0

Marc-Andre Lemburg added the comment: On 2008-12-22 15:07, Mark Dickinson wrote: > Mark Dickinson 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 remo

[issue4704] Update pybench for python 3.0

Mark Dickinson 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

[issue4719] sys.exc_clear() not flagged in any way

Fabio Zadrozny 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 -- mayb

[issue4719] sys.exc_clear() not flagged in any way

Benjamin Peterson 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 _

[issue4719] sys.exc_clear() not flagged in any way

Antoine Pitrou added the comment: Le lundi 22 décembre 2008 à 12:48 +, Fabio Zadrozny a écrit : > Fabio Zadrozny 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 excepti

[issue4720] Extension function optional argument specification | causes RuntimeError

New submission from Pearu Peterson : 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(

[issue4719] sys.exc_clear() not flagged in any way

Fabio Zadrozny 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'?).

[issue4719] sys.exc_clear() not flagged in any way

Georg Brandl added the comment: exc_clear() is not in the 3.0 docs, and the whatsnew contains a note. Maybe a 2to3 issue? -- assignee: georg.brandl -> benjamin.peterson components: +2to3 (2.x to 3.0 conversion tool) -Documentation nosy: +benjamin.peterson _

[issue4719] sys.exc_clear() not flagged in any way

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

[issue4719] sys.exc_clear() not flagged in any way

Antoine Pitrou added the comment: There should be no need for sys.exc_clear() anymore. What are you trying to achieve? -- nosy: +pitrou ___ Python tracker ___ ___

[issue4716] Python 3.0 halts on shutdown when settrace is set

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

[issue4719] sys.exc_clear() not flagged in any way

New submission from Fabio Zadrozny : 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 n

[issue4718] wsgiref package totally broken

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

[issue4718] wsgiref package totally broken

New submission from Dmitry Vasiliev : 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://bug

[issue4717] execfile conversion is not correct

New submission from Fabio Zadrozny : 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, 'e

[issue4716] Python 3.0 halts on shutdown when settrace is set

New submission from Fabio Zadrozny : 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 be

[issue4714] print opcode stats at the end of pybench runs

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

[issue4714] print opcode stats at the end of pybench runs

Marc-Andre Lemburg added the comment: On 2008-12-21 22:37, Antoine Pitrou wrote: > New submission from Antoine Pitrou : > > 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

[issue4707] round() shows undocumented behaviour

Changes by Raymond Hettinger : -- assignee: rhettinger -> ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http: