[issue15318] IDLE - sys.stdin is writeable

Martin v. Löwis added the comment: I propose the attached patch to block write() calls. -- keywords: +patch Added file: http://bugs.python.org/file26350/blockwrite.diff ___ Python tracker _

[issue15318] IDLE - sys.stdin is writeable

Martin v. Löwis added the comment: Revised -- Added file: http://bugs.python.org/file26351/blockwrite.diff ___ Python tracker ___ ___

[issue15320] thread-safety issue in regrtest.main()

Amaury Forgeot d'Arc added the comment: There is indeed a race condition here. Fortunately unit tests take much more time than the generator loop. Is it enough to turn the generator into a fixed list? Or is the "late binding" behavior of args_tuple important? (For example, if the main thread

[issue3405] Add support for the new data option supported by event generate (Tk 8.5)

Mark Summerfield added the comment: According to the Tcl/Tk docs the 'data' field is a string (i.e., for any user data) and the 'detail' field contains some internal data (so shouldn't be messed with); see http://www.tcl.tk/man/tcl8.5/TkCmd/event.htm#M16 Anyway, I hope you add a data field fo

[issue15324] --match does not work for regrtest

New submission from Chris Jerdonek : The long form of the -m/--match option does not work with regrtest because it does not accept an argument. For example (observe the lack of an error in the second invocation)-- $ ./python.exe -m test -m option -m requires argument Use --help for usage $ .

[issue15319] IDLE - sys.stdin, sys.stdout, etc are broken

Serhiy Storchaka added the comment: > title: IDLE - input() is broken. -> IDLE - sys.stdin is broken. Well, now, with the modified header, I'm not going to open a separate issue. Here is a patch that fixes almost all IDLE sys.std* issues. -- title: IDLE - readline, isatty, and input br

[issue15319] IDLE - sys.stdin, sys.stdout, etc are broken

Martin v. Löwis added the comment: Serhiy: this issue is closed, so your patch won't be considered. -- ___ Python tracker ___ ___ Pyt

[issue15319] IDLE - readline, isatty, and input broken

Serhiy Storchaka added the comment: Sorry, I missed the morning's discussion. -- title: IDLE - sys.stdin, sys.stdout, etc are broken -> IDLE - readline, isatty, and input broken ___ Python tracker ___

[issue15323] Provide target name in output message when Mock.assert_called_once_with fails

Michael Foord added the comment: Looks good, thanks. -- assignee: -> michael.foord nosy: +michael.foord ___ Python tracker ___ ___ P

[issue15318] IDLE - sys.stdin is writeable

Serhiy Storchaka added the comment: sys.std* streams have many other issues. >>> sys.stdin.readable() Traceback (most recent call last): File "", line 1, in sys.stdin.readable() AttributeError: readable >>> sys.stdout.writable() Traceback (most recent call last): File "", line 1, in

[issue15318] IDLE - sys.stdin is writeable

Serhiy Storchaka added the comment: Added getvar method to PyShell.console. -- Added file: http://bugs.python.org/file26354/idle_stdstreams-3.patch ___ Python tracker ___diff -r

[issue15318] IDLE - sys.stdin is writeable

Martin v. Löwis added the comment: Serhiy: can you please explicitly list what issues your patch fixes? I can think of many *more* issues that your patch doesn't fix, e.g. sys.stdin.read(sys) and sys.stdout.read(). I'm quite opposed to monkey-patching, so I won't commit any patch that involve

[issue15325] --fromfile does not work for regrtest

New submission from Chris Jerdonek : The long form of the -f/--fromfile option does not work. It does not read its required argument. For example (observe that the second invocation raises no error)-- $ ./python.exe -m test -f option -f requires argument Use --help for usage $ ./python.exe -

[issue15324] --match does not work for regrtest

Chris Jerdonek added the comment: Note that issue 15302 will fix this. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Un

[issue15318] IDLE - sys.stdin is writeable

Martin v. Löwis added the comment: As an additional note: the change to monkey-patching breaks the test isinstance(sys.stdout, io.TextIOBase) which currently succeeds. -- ___ Python tracker

[issue15326] --random does not work for regrtest

New submission from Chris Jerdonek : The long form of the -r/--random option does not work: $ ./python.exe -m test --random No handler for option --random. Please report this as a bug at http://bugs.python.org. Note that issue 15302 will fix this. -- components: Tests keywords: easy

[issue15302] Use argparse instead of getopt in test.regrtest

Chris Jerdonek added the comment: Attached is a first version of a complete patch. Note that I found three bugs in the current argument parsing code in the course of working on this patch: issue 15324, issue 15325, and issue 15326 (because of various typos in the getopt configuration). All o

[issue15327] Argparse: main arguments and subparser arguments indistinguishable

New submission from Ingo Fischer : I have an argument called '--verbose' in the main parser. Then I add a subparser called 'command', to which I add an argument with the same name '--verbose' (See attached script). When I process these args, I cannot decide afterwards if the user called 'mysc

[issue15318] IDLE - sys.stdin is writeable

Serhiy Storchaka added the comment: > Serhiy: can you please explicitly list what issues your patch fixes? issue12967. And sys.std* in IDLE lacks other common sys.std* methods and attributes. > I can think of many *more* issues that your patch doesn't fix, e.g. > sys.stdin.read(sys) and sys.s

[issue15320] thread-safety issue in regrtest.main()

Chris Jerdonek added the comment: I don't think the late binding is necessary. But it looks like late binding could be preserved simply by constructing args_tuple inside the worker thread instead of in the generator. Really, only "test" needs to be yielded. Nothing else varies in the loop. I

[issue15318] IDLE - sys.stdin is writeable

Serhiy Storchaka added the comment: > As an additional note: the change to monkey-patching breaks the test > > isinstance(sys.stdout, io.TextIOBase) > > which currently succeeds. Agree, this is a regression. However isinstance(sys.stdout, io.TextIOBase) is False now in no-subprocess mode. Th

[issue1346874] httplib simply ignores CONTINUE

André Cruz added the comment: Attached is an updated patch against 2.7.3. It solves a bug in the tests and implements Carl's suggestion. The new tests pass and it updates the documentation as well. As for inclusion in 2.7, as this is in fact solving a bug, I would vote for it. Right now, if

[issue15320] thread-safety issue in regrtest.main()

Amaury Forgeot d'Arc added the comment: I was about to say "yes, listiter.__next__ is atomic" (it should, really), but that's not true (Hint: there is a Py_DECREF in the code...). The script below crashes with: Fatal Python error: Objects/listobject.c:2774 object at 0x7f66b7a6c600 has neg

[issue3405] Add support for the new data option supported by event generate (Tk 8.5)

O.C. added the comment: I don't agree with this comment. 1) The 'detail' field also contains a string, one of the following: "NotifyAncestor", "NotifyNonlinearVirtual",... 2) When an event is received, the 'detail' and 'user_data' fields are de facto mixed up. Indeed, the "%d" field contains

[issue15302] Use argparse instead of getopt in test.regrtest

Changes by Brett Cannon : -- stage: needs patch -> patch review ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue8823] urllib2 does not catch httplib.BadStatusLine

Greg Roodt added the comment: By the way, the issue can be recreated by running the following: netcat -l -p -e "echo HTTP/1.1 1000 OK" & python -c "import urllib2; urllib2.urlopen('http://localhost:')" This happens on 2.6, 2.7 and 3 by the looks of it. -- ___

[issue15328] datetime.strptime slow

New submission from Lars Nordin : The datetime.strptime works well enough for me it is just slow. I recently added a comparison to a log parsing script to skip log lines earlier than a set date. After doing so my script ran much slower. I am processing 4,784,212 log lines in 1,746 files. Using

[issue15328] datetime.strptime slow

Lars Nordin added the comment: Running the script without any timestamp comparison (and parsing more log lines), gives these performance numbers: log lines: 7,173,101 time output: real1m9.892s user0m53.563s sys 0m1.592s -- ___ Python t

[issue15328] datetime.strptime slow

R. David Murray added the comment: Thanks for the report. However, do you have a patch to propose? Otherwise I'm not sure there is a reason to keep this issue open...one can always say various things are slow; that by itself is not a bug. Performance enhancement patches are welcome, though

[issue15318] IDLE - sys.stdin is writeable

Serhiy Storchaka added the comment: issue9290 also has relation to this. -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue15318] IDLE - sys.stdin is writeable

Serhiy Storchaka added the comment: issue7163 is another PseudoFile-related issue. -- ___ Python tracker ___ ___ Python-bugs-list mai

[issue7897] Support parametrized tests in unittest

Changes by florian-rathgeber : -- nosy: +florian-rathgeber ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:

[issue12600] Add example of using load_tests to parameterise Test Cases

Changes by florian-rathgeber : -- nosy: +florian-rathgeber ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http

[issue15322] sysconfig.get_config_var('srcdir') returns unexpected value

Changes by Antoine Pitrou : -- nosy: +eric.araujo, tarek ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:/

[issue15300] test directory doubly-nested running tests with -j/--multiprocess

Antoine Pitrou added the comment: Thanks, Chris. I haven't tested the patch but it looks fine. -- ___ Python tracker ___ ___ Python-b

[issue15322] sysconfig.get_config_var('srcdir') returns unexpected value

Éric Araujo added the comment: Looks like a duplicate; I can’t search right now (try sysconfig + build). -- ___ Python tracker ___ __

[issue7163] IDLE suppresses sys.stdout.write() return value

Changes by Serhiy Storchaka : -- nosy: +storchaka ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue15320] thread-safety issue in regrtest.main()

Antoine Pitrou added the comment: Amaury's patch looks obviously fine. As for the original issue: yes, I thought I saw a traceback once due to that. Using list.pop() (or deque.pop()) instead would probably be good enough. -- stage: -> patch review versions: +Python 2.7, Python 3.2 _

[issue15320] thread-safety issue in regrtest.main()

Changes by Florent Xicluna : -- nosy: +flox ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue14797] Deprecate imp.find_module()/load_module()

Changes by Florent Xicluna : -- nosy: +flox ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue5815] locale.getdefaultlocale() missing corner case

rg3 added the comment: I don't know if the behavior is considered a bug or just undocumented, but under Python 2.7.3 it's still the same. locale.getpreferredencoding() does return UTF-8, but the second element in the tuple locale.getdefaultlocale() is "utf_8_valencia", which is not a valid en

[issue15300] test directory doubly-nested running tests with -j/--multiprocess

Roundup Robot added the comment: New changeset 724a6e0e35f0 by Antoine Pitrou in branch '3.2': Issue #15300: Ensure the temporary test working directories are in the same parent folder when running tests in multiprocess mode from a Python build. http://hg.python.org/cpython/rev/724a6e0e35f0 Ne

[issue15300] test directory doubly-nested running tests with -j/--multiprocess

Antoine Pitrou added the comment: Committed now. -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed versions: +Python 3.2 ___ Python tracker _

[issue5815] locale.getdefaultlocale() missing corner case

Serhiy Storchaka added the comment: The patch is not work for "ca_ES@valencia" locale. And there are issues for such locales: "ks_in@devanagari", "ks...@devanagari.utf-8", "sd", "sd...@devanagari.utf-8" ("ks_in@devanagari" in locale_alias maps to "ks...@devanagari.utf-8" and "sd" to "sd...@d

[issue15322] sysconfig.get_config_var('srcdir') returns unexpected value

Chris Jerdonek added the comment: I searched a little before. There is issue 12141, "sysconfig.get_config_vars('srcdir') fails in specific cases," but that issue is closed. In the comments there, Antoine seems to be describing the bug I describe here, but I'm not sure an issue was filed: h

[issue15318] IDLE - sys.stdin is writeable

Martin v. Löwis added the comment: "implements textio badly" is *not* a well-defined issue. First it is a personal judgement: some think it's really bad, some think it's quite ok. More importantly, such issue has no clear success criterion: how do we know we are done - can we hope to EVER cl

[issue15320] thread-safety issue in regrtest.main()

Chris Jerdonek added the comment: Attaching a patch for the original issue using deque. -- Added file: http://bugs.python.org/file26359/issue-15320-1.patch ___ Python tracker __

[issue15318] IDLE - sys.stdin is writeable

Serhiy Storchaka added the comment: > In any case,*this* issue is about sys.stdin being writable. I already got confused with all these closing/reopening/renaming of issues and floating code. Should I open my own issue even if it duplicates and supersedes some other? > Any objection to checkin

[issue15320] thread-safety issue in regrtest.main()

Antoine Pitrou added the comment: Hmm, actually the patch is not ok, because of the -F option which uses an infinite iterator. -- ___ Python tracker ___ ___

[issue13866] {urllib, urllib.parse}.urlencode should not use quote_plus

jin added the comment: I just ran into exactly the same problem and was quite disappointed to see that urlencode does not provide an option to use percent encoding. My use case: I'm preparing some metadata on the server side that is stored as an url encoded string, the processing is done in p

[issue15318] IDLE - sys.stdin is writeable

Changes by Martin v. Löwis : Added file: http://bugs.python.org/file26360/blockfile-3.diff ___ Python tracker ___ ___ Python-bugs-list mailing

[issue15318] IDLE - sys.stdin is writeable

Changes by Martin v. Löwis : Removed file: http://bugs.python.org/file26360/blockfile-3.diff ___ Python tracker ___ ___ Python-bugs-list maili

[issue15318] IDLE - sys.stdin is writeable

Changes by Martin v. Löwis : Added file: http://bugs.python.org/file26361/blockfile-3.diff ___ Python tracker ___ ___ Python-bugs-list mailing

[issue15318] IDLE - sys.stdin is writeable

Martin v. Löwis added the comment: > I already got confused with all these closing/reopening/renaming of > issues and floating code. Should I open my own issue even if it > duplicates and supersedes some other? I personally think it would be best if these issues where closed *first*, and only t

[issue15329] clarify which deque methods are thread-safe

New submission from Chris Jerdonek : I think it would help to clarify which collections.deque methods are thread-safe: http://docs.python.org/dev/library/collections.html?highlight=deque#collections.deque Currently, the documentation says that "Deques support thread-safe, memory efficient app

[issue15330] allow deque to act as a thread-safe circular buffer

New submission from Chris Jerdonek : It seems like it would be useful if collections.deque had a thread-safe method that could rotate(1) and return the rotated value. This would let deque to act as a thread-safe circular buffer (e.g. if serving jobs to multiple threads in a loop, like `python

[issue15318] IDLE - sys.stdin is writeable

Roger Serwy added the comment: I tested blockfile-3.diff against the latest code in the repository. sys.stdin.write returns the wrong error message when passed a non-string. Presently it returns io.UnsupportedOperation instead of TypeError: must be str, not ... The attached blockfile-4.diff

[issue15320] thread-safety issue in regrtest.main()

Chris Jerdonek added the comment: Good catch. Here is a patch that takes --forever mode into account. I wrote this patch with the assumption that it shouldn't hurt if multiple threads call deque.extend() at the same time. -- Added file: http://bugs.python.org/file26363/issue-15320-2.

[issue15330] allow deque to act as a thread-safe circular buffer

Changes by Raymond Hettinger : -- assignee: -> rhettinger priority: normal -> low versions: +Python 3.4 ___ Python tracker ___ ___ Py

[issue15330] allow deque to act as a thread-safe circular buffer

Raymond Hettinger added the comment: By thread-safe you mean that the operation should be atomic? -- ___ Python tracker ___ ___ Pytho

[issue15329] clarify which deque methods are thread-safe

Changes by Raymond Hettinger : -- assignee: docs@python -> rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubsc

[issue15330] allow deque to act as a thread-safe circular buffer

Chris Jerdonek added the comment: Yes, atomic. I was under the impression that the existing deque.rotate() is atomic, in which case deque.rotate(1) almost provides what I'm suggesting (lacking only the return value). -- ___ Python tracker

[issue15330] allow deque to act as a thread-safe circular buffer

Raymond Hettinger added the comment: We make almost no guarantees about atomicity. If something in CPython happens to be atomic, it is not guaranteed to hold in other implementations. The recommendation is to use locks anywhere you need a critical section of code. FWIW, the term thread-saf

[issue15330] allow deque to act as a thread-safe circular buffer

Chris Jerdonek added the comment: Thanks for the info. A couple questions: what does "won't break" mean -- that it won't throw an exception of a type that it wouldn't normally throw in a single-threaded environment? And does this mean that not even deque.pop() is atomic? -- __

[issue15329] clarify which deque methods are thread-safe

Chris Jerdonek added the comment: I think some of the information in the issue 15330 comments would be very helpful to add as well (what thread-safe means in Python, distinction between thread-safe and atomic, and which deque methods are thread-safe and/or atomic). If some of that information