[issue15798] subprocess.Popen() fails if 0, 1 or 2 descriptor is closed

Ross Lagerwall added the comment: It's caused by the following check in _posixsubprocess.c: if (close_fds && errpipe_write < 3) { /* precondition */ PyErr_SetString(PyExc_ValueError, "errpipe_write must be >= 3"); return NULL; } which was written by Gregory P. Smith in 2

[issue15804] Feature request, implicit "except : pass"

Changes by Ezio Melotti : -- stage: -> committed/rejected ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http

[issue15806] Add context manager for the "try: ... except: pass" pattern

Changes by Chris Jerdonek : -- nosy: +cjerdonek ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyt

[issue15806] Add context manager for the "try: ... except: pass" pattern

Nick Coghlan added the comment: I'd just write it with @contextmanager. Making it easier to cleanly factor out exception handling is one of the main reasons that exists. @contextmanager def ignored(*exceptions): """Context manager to ignore particular exceptions""" try: yiel

[issue15806] Add context manager for the "try: ... except: pass" pattern

Raymond Hettinger added the comment: Yes, something along those lines would be *much* better: class Ignore: ''' Context manager to ignore particular exceptions''' def __init__(self, *ignored_exceptions): self.ignored_exceptions = ignored_exceptions def __enter__(self):

[issue15806] Add context manager for the "try: ... except: pass" pattern

Alex Gaynor added the comment: Why not just: issubclass(exctype, self.exception_types)? -- ___ Python tracker ___ ___ Python-bugs-list

[issue15806] Add context manager for the "try: ... except: pass" pattern

Raymond Hettinger added the comment: Hmm, the __exit__ method was doing exact matches by exception type, so KeyError wouldn't match LookupError or Exception. There are probably a number of ways to fix this, but it may be easiest to use the builtin exception catching mechanisms: class Ignore:

[issue15805] Add stdout redirection tool to contextlib

Nick Coghlan added the comment: Sure, but by targeting a specific use case you can make it really trivial to use. -- ___ Python tracker ___ _

[issue15806] Add context manager for the "try: ... except: pass" pattern

Changes by Alex Gaynor : -- nosy: +alex ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/

[issue15805] Add stdout redirection tool to contextlib

Alex Gaynor added the comment: Sounds like a special case of a small part of mock. Not sure that this observation is significant though. -- nosy: +alex ___ Python tracker ___ __

[issue15806] Add context manager for the "try: ... except: pass" pattern

New submission from Raymond Hettinger: It is a somewhat common pattern to write: try: do_something() except SomeException: pass To search examples in the standard library (or any other code base) use: $ egrep -C2 "except( [A-Za-z]+)?:" *py | grep -C2 "pass" In the Pyt

[issue15805] Add stdout redirection tool to contextlib

Nick Coghlan added the comment: We actually use a variant of this idea in the test suite (http://docs.python.org/dev/library/test#test.support.captured_stdout) It would be pretty easy to combine the two concepts by defaulting the redirection to a new StringIO instance if no other destination i

[issue15805] Add stdout redirection tool to contextlib

Changes by Raymond Hettinger : -- assignee: -> ncoghlan nosy: +ncoghlan priority: normal -> low ___ Python tracker ___ ___ Python-bug

[issue15805] Add stdout redirection tool to contextlib

New submission from Raymond Hettinger: The technique of temporarily redirecting stdout could be encapsulated in a context manager. print('This goes to stdout') with RedirectStdout(sys.stderr): print('This goes to stderr') print('So does this') print('This goes to stdout') The print f

[issue15751] Support subinterpreters in the GIL state API

Nick Coghlan added the comment: Currently, both PyGILState_Ensure and PyGILState_Release just call PyFatal_Error if anything goes wrong. With the *Ex versions, it would be possible to replace those fatal errors with more conventional error handling. For Ensure, the likely error is failing to c

[issue15751] Support subinterpreters in the GIL state API

Graham Dumpleton added the comment: So you are saying that as user of this I am meant to call it as: PyGILState_INFO info; PyGILState_EnsureEx(interp, &info); ... PyGILState_ReleaseEx(&info); What is the potential error code from PyGILState_EnsureEx() considering that right now for PyGILState

[issue15751] Support subinterpreters in the GIL state API

Nick Coghlan added the comment: No, those wouldn't change at all. However, after thinking about it further, I'm leaning back towards the option of an EnsureEx/ReleaseEx pair that allows the previous interpreter to be reported and restored along with the GIL state. I'd also like to make the sta

[issue15804] Feature request, implicit "except : pass"

Benjamin Peterson added the comment: Please submit your idea to the python-ideas list. -- nosy: +benjamin.peterson resolution: -> wont fix status: open -> closed ___ Python tracker

[issue15751] Support subinterpreters in the GIL state API

Graham Dumpleton added the comment: Nick. Valid point. I guess I hadn't been thinking about case of one thread calling out of one interpreter and then into another, as I don't do it in mod_wsgi and even I regard doing that as partly evil. Does that mean this switch interpreter call somehow ge

[issue15751] Support subinterpreters in the GIL state API

Nick Coghlan added the comment: The reason I'm proposing going back to the original SwitchInterpreter idea is because the EnsureEx idea doesn't nest cleanly - if your thread is already associated with "interpreter A", you can't readily call into "interpeter B", because the API provides no way

[issue15804] Feature request, implicit "except : pass"

Jesús Cea Avión added the comment: No way this is going to be in 2.7. -- nosy: +jcea versions: -Python 2.7 ___ Python tracker ___ ___

[issue15804] Feature request, implicit "except : pass"

Raymond Hettinger added the comment: FWIW, this is already easy to do with decorators: >>> class Pass: def __init__(self, exc): self.exc = exc def __enter__(self): return self def __exit__(self, exctype, excinst, exctb): ret

[issue15804] Feature request, implicit "except : pass"

New submission from gd2shoe: I'm constantly finding myself writing itty-bitty try blocks like such: process stuff try : someSubProcess.kill() except : pass process stuff I realize this isn't a rigorous use of except, but it's good enough for a vast majority of what I need it for. Still, it ad

[issue15783] decimal.localcontext(None) fails when using the C accelerator module

Nick Coghlan added the comment: I agree it's an acceptable risk for 3.3.0. Most third party decimal operations simply won't accept an explicit context argument at all - avoiding the need to pass the current context around explicitly is the whole point of it being stored in the thread locals.

[issue15803] Incorrect docstring on ConfigParser.items()

New submission from Nathan Trapuzzano: The docstring on ConfigParser.items() is self-evidently bass ackwards. Fix is in attached patch. -- components: Library (Lib) files: cpython.patch keywords: patch messages: 169324 nosy: nbtrap priority: normal severity: normal status: open title: I

[issue15802] Illegal test for mailbox

Changes by Jesús Cea Avión : -- nosy: +jcea ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue15800] Closing of sys.std* files in gzip test.

Changes by Jesús Cea Avión : -- nosy: +jcea ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue14649] doctest.DocTestSuite error misleading when module has no docstrings

Chris Jerdonek added the comment: I updated the patch to fix the test_zipimport_support tests. All tests now pass. The only changes were to Lib/test/test_zipimport_support.py. I'll make a note about test_pyclbr and test_zipimport_support when I create the issue to move the supporting doctest

[issue15785] curses.get_wch() returns keypad codes incorrectly

Roundup Robot added the comment: New changeset c58789634d22 by Victor Stinner in branch 'default': Issue #15785: Modify window.get_wch() API of the curses module: return a http://hg.python.org/cpython/rev/c58789634d22 -- ___ Python tracker

[issue15785] curses.get_wch() returns keypad codes incorrectly

STINNER Victor added the comment: bitdancer proposes (on IRC) a better doc for get_wch(): "Get a wide character. Return a character for most keys, or an integer for function keys, keypad keys, and other special keys." We may also replace "and so on" by "and other special keys" in getkey() def

[issue15801] Weird string interpolation behaviour

Erik Allik added the comment: Respectable reaction time. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: htt

[issue15785] curses.get_wch() returns keypad codes incorrectly

STINNER Victor added the comment: @simpkins: can you please try my patch? -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue15785] curses.get_wch() returns keypad codes incorrectly

STINNER Victor added the comment: bitdancer tested the patch version 3 for me and it fails: unget_wch(KEY_UP) inserts the character U+0103 (259, à) instead of KEY_UP in get_wch() buffer. unget_wch() cannot be used to insert key codes, only classic keys like letters. So I removed the patch vers

[issue15785] curses.get_wch() returns keypad codes incorrectly

Changes by STINNER Victor : Removed file: http://bugs.python.org/file27039/curses_get_wch-3.patch ___ Python tracker ___ ___ Python-bugs-list

[issue14649] doctest.DocTestSuite error misleading when module has no docstrings

Chris Jerdonek added the comment: > With your patch 5 applied, test_zipimport_support fails. You're right. It looks like test_zipimport_support is tightly coupled to test_doctest. For example-- http://hg.python.org/cpython/file/786d9516663e/Lib/test/test_zipimport_support.py#l94 My apologie

[issue15785] curses.get_wch() returns keypad codes incorrectly

Changes by STINNER Victor : Added file: http://bugs.python.org/file27038/curses_get_wch-2.patch ___ Python tracker ___ ___ Python-bugs-list ma

[issue15785] curses.get_wch() returns keypad codes incorrectly

STINNER Victor added the comment: > Perhaps you should simply remove the new function, and re-add it in 3.4 when > you've thought it out a bit more. Python 3 forces somehow to use Unicode, and the Unicode support of the curses module in Python 3.2 is incomplete or broken (see . Many issues hav

[issue14649] doctest.DocTestSuite error misleading when module has no docstrings

R. David Murray added the comment: With your patch 5 applied, test_zipimport_support fails. I took a quick look at this and it looks like it is because we've added a dependency on an external data file to the test for DocTestSuite. Note that with patch 4 applied, test_pyclbr fails...I found t

[issue15785] curses.get_wch() returns keypad codes incorrectly

STINNER Victor added the comment: New patch with a test for this specific issue. (It's not easy to me to write a patch because my version of libncurses doesn't work with integers bigger than 128...) -- Added file: http://bugs.python.org/file27039/curses_get_wch-3.patch ___

[issue15785] curses.get_wch() returns keypad codes incorrectly

Changes by STINNER Victor : Removed file: http://bugs.python.org/file27038/curses_get_wch-2.patch ___ Python tracker ___ ___ Python-bugs-list

[issue15785] curses.get_wch() returns keypad codes incorrectly

STINNER Victor added the comment: window.get_wch() has been added by the issue #6755, and curses.unget_wch() by #12567. Copy the nosy of the issue #6755. -- nosy: +Nicholas.Cole, akuchling, cben, gpolo, inigoserna, jcea, phep, python-dev, r.david.murray, schodet, zeha

[issue15785] curses.get_wch() returns keypad codes incorrectly

Antoine Pitrou added the comment: Perhaps you should simply remove the new function, and re-add it in 3.4 when you've thought it out a bit more. -- nosy: +pitrou ___ Python tracker

[issue15785] curses.get_wch() returns keypad codes incorrectly

Changes by STINNER Victor : Removed file: http://bugs.python.org/file27007/curses_get_wch.patch ___ Python tracker ___ ___ Python-bugs-list ma

[issue15785] curses.get_wch() returns keypad codes incorrectly

STINNER Victor added the comment: New patch fixing the issue with a better API: window.get_wch()->int or str depending on the key (int for key codes, str for other keys). Oh, I realized that test_curses does also fail on my laptop without the patch. My laptop is running Fedora 11 which uses li

[issue15751] Support subinterpreters in the GIL state API

Graham Dumpleton added the comment: Sorry, Mark. Is not for associating thread state specified by embedding application. In simple terms it is exactly like existing PyGILState_Ensure() in that caller doesn't have a thread state, whether it has already been created. Only difference is to allow

[issue15801] Weird string interpolation behaviour

Roundup Robot added the comment: New changeset 2801bf875a24 by Benjamin Peterson in branch '2.7': use the stricter PyMapping_Check (closes #15801) http://hg.python.org/cpython/rev/2801bf875a24 New changeset 4d431e719646 by Benjamin Peterson in branch '3.2': use the stricter PyMapping_Check (clos

[issue15802] Illegal test for mailbox

Changes by A.M. Kuchling : -- nosy: -akuchling ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyt

[issue15802] Illegal test for mailbox

R. David Murray added the comment: Looks right to me on a quick scan, but I'm not familiar with that test. -- nosy: +petri.lehtinen ___ Python tracker ___ ___

[issue15802] Illegal test for mailbox

Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file27037/test_mailbox_create_tmp-2.7.patch ___ Python tracker ___ ___ Python

[issue15802] Illegal test for mailbox

New submission from Serhiy Storchaka: Test for mailbox contains meaningless asserts. Here is a patch that corrects testing, if I correctly understand it. -- components: Tests files: test_mailbox_create_tmp.patch keywords: patch messages: 169307 nosy: akuchling, barry, r.david.murray, st

[issue15591] when building the extensions, stdout is lost when stdout is redirected

Benjamin Peterson added the comment: This seems to have broken parallel building of modules. -- nosy: +benjamin.peterson ___ Python tracker ___ __

[issue15799] httplib client and statusline

karl added the comment: Fair enough, it could be a warning when * more than one space in between http version and status code * if there is a missing space after the status code I'm not advocating for being strict only. I'm advocating for giving the tools to developer to assess that things ar

[issue15801] Weird string interpolation behaviour

Mike Graham added the comment: Line 13464 of unicodeobject.c is if (Py_TYPE(args)->tp_as_mapping && !PyTuple_Check(args) && !PyUnicode_Check(args)) Too lazy to check, but don't user-created types have a tp_as_mapping? If so, I think it mistakes Foo() for a dict. -- nosy: +

[issue15801] Weird string interpolation behaviour

R. David Murray added the comment: Didn't get an error in 2.7, either, with Message(). -- ___ Python tracker ___ ___ Python-bugs-list

[issue15801] Weird string interpolation behaviour

R. David Murray added the comment: That doesn't appear to be true in 3.2. I happened to test this on email.message.Message, and it also did not raise an error, but it defines an __str__. I suspect this is some oddball result of the coercion rules. -- nosy: +r.david.murray __

[issue15801] Weird string interpolation behaviour

Alex Gaynor added the comment: Additional detail, if and only if Foo defines an __str__ method, this raises an exception. -- nosy: +alex ___ Python tracker ___ _

[issue15801] Weird string interpolation behaviour

New submission from Erik Allik: >>> class Foo(object): ... pass ... >>> "asdads" % Foo() 'asdads' Doesn't look like it's supposed to be this way. As per the documentation: "If format requires a single argument, values may be a single non-tuple object. [5] Otherwise, values must be a tup

[issue15799] httplib client and statusline

Antoine Pitrou added the comment: I would point out that the goal of the http module is to provide interoperability with real-life servers, rather than be a strict implementation of RFCs. So, starting to raise errors for "HTTP/1.1 200" while "HTTP/1.1 200 " remains ok might not be the best ide

[issue15799] httplib client and statusline

R. David Murray added the comment: Why should it raise an error? The postel principle suggests that we should treat it as equivalent to the second line. -- ___ Python tracker _

[issue15799] httplib client and statusline

karl added the comment: ok. status lines 1 and 2 are valid. the third one is invalid and should trigger a raise BadStatusLine(line) The code at line 318 is bogus as it will parse happily the third line without raising an exception. http://hg.python.org/cpython/file/3.2/Lib/http/client.py#l3

[issue15800] Closing of sys.std* files in gzip test.

New submission from Serhiy Storchaka: When porting gzip module from Python 2 to Python 3, binary files sys.std(in|out) was replaced by sys.std(in|out).buffer in gzip module internal testing code (when gzip used as executable). But in one place the replacement was skipped. As the result the con

[issue15783] decimal.localcontext(None) fails when using the C accelerator module

Mark Dickinson added the comment: I don't really feel that strongly either way, either. I understand Nick's arguments, but can't help feeling that we're letting a doc mistake dictate the API here. (And my inner type-system has an aversion to APIs where arguments are expected to be *either* N

[issue15799] httplib client and statusline

R. David Murray added the comment: Could you explain the error you are seeing in more detail first? You are talk about parsing and fixes here, but I'm not clear on what the actual bug is you are reporting. -- nosy: +r.david.murray ___ Python tracke

[issue15799] httplib client and statusline

New submission from karl: The current parsing of HTTP status line seems strange with regards to its definition in HTTP. http://hg.python.org/cpython/file/3.2/Lib/http/client.py#l307 Currently the code is version, status, reason = line.split(None, 2) >>> status1 = "HTTP/1.1 200 OK" >>> status

[issue15783] decimal.localcontext(None) fails when using the C accelerator module

Stefan Krah added the comment: I don't want to block this, BTW. Personally I'm +-0 on the issue. If more people think this is needed for backwards compatibility, I'll write a patch for localcontext. But I'd rather do that *very* soon. FWIW, none of the cdecimal users has ever complained about t

[issue15784] OSError.__str__() should distinguish between errno and winerror

Roundup Robot added the comment: New changeset 2e587b9bae35 by Richard Oudkerk in branch 'default': Issue #15784: Modify OSError.__str__() to better distinguish between http://hg.python.org/cpython/rev/2e587b9bae35 -- nosy: +python-dev ___ Python trac

[issue14468] Update cloning guidelines in devguide

Changes by Mike Hoy : -- nosy: +mikehoy ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/

[issue15591] when building the extensions, stdout is lost when stdout is redirected

Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue15794] test_importlib: test_locks failure

Changes by Antoine Pitrou : -- resolution: -> fixed stage: -> committed/rejected status: open -> closed ___ Python tracker ___ ___ P

[issue15794] test_importlib: test_locks failure

Roundup Robot added the comment: New changeset 454dceb5fd56 by Antoine Pitrou in branch 'default': Issue #15794: Relax a test case due to the deadlock detection's conservativeness. http://hg.python.org/cpython/rev/454dceb5fd56 -- nosy: +python-dev __

[issue15591] when building the extensions, stdout is lost when stdout is redirected

Matthias Klose added the comment: fixed. -- resolution: -> fixed status: open -> closed versions: -Python 2.6 ___ Python tracker ___ ___

[issue15591] when building the extensions, stdout is lost when stdout is redirected

Roundup Robot added the comment: New changeset 1a1d097b17e2 by Matthias Klose in branch '2.7': - Issue #15591: Fix parsing MAKEFLAGS in the sharedmods target. http://hg.python.org/cpython/rev/1a1d097b17e2 New changeset 763d188a96bb by Matthias Klose in branch '3.2': - Issue #15591: Fix parsing M

[issue13592] repr(regex) doesn't include actual regex

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

[issue15591] when building the extensions, stdout is lost when stdout is redirected

Matthias Klose added the comment: bah, this happens when you do a parallel build. --jobserver-fds is passed in MAKEFLAGS, and the test for sharedmods turns on the quiet mode, because it matches just *s* in MAKEFLAGS :-/ The patch tries to parse MAKEFLAGS using getopt, and if getopt is not ava

[issue15751] Support subinterpreters in the GIL state API

Antoine Pitrou added the comment: Le mardi 28 août 2012 à 14:12 +, Nick Coghlan a écrit : > old_interp = PyGILState_SwitchInterpreter(target_interp); > old_gil = PyGILState_Ensure(); > /* Call into Python using target_interp */ > PyGILState_Release(old_gil); > PyGILState_SwitchInterpreter(old

[issue15797] bdist_msi does not pass -install/remove flags to install_script

Changes by B Maqueira : Added file: http://bugs.python.org/file27033/patch1.diff ___ Python tracker ___ ___ Python-bugs-list mailing list Unsu

[issue15775] Add StopParser() to expat

Nemeskey Dávid added the comment: loewis: I don't think it would be difficult to fix, so theoretically I'd be in. However, I don't really have the time to work on this right now. -- ___ Python tracker

[issue13266] Add inspect.unwrap(f) to easily unravel "__wrapped__" chains

Changes by Éric Araujo : -- versions: +Python 3.4 -Python 3.3 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: h

[issue15751] Support subinterpreters in the GIL state API

Nick Coghlan added the comment: Thinking about it, I believe there still needs to be a concept of an "active thread state" TLS key in order to deal with Graham's original problem. Specifically, if PyGILState_EnsureEx is used to associate the thread with a particular interpreter, then subsequen

[issue11489] json.dumps not parsable by json.loads (on Linux only)

Serhiy Storchaka added the comment: > It's Unicode that considers unpaired surrogates invalid, not UTF-8 by itself. It's UTF-8 too. See RFC 3629: The definition of UTF-8 prohibits encoding character numbers between U+D800 and U+DFFF, which are reserved for use with the UTF-16 encoding

[issue15762] Windows 8 certification

Martin v. Löwis added the comment: The change you proposed cannot be applied to Python 2.7, or any distutils code bases, for a number of reasons: - it's not clear (and probably not the case) that the proposed command line flags are correct for all distutils code. It may well be that some code

[issue15775] Add StopParser() to expat

Martin v. Löwis added the comment: nemeskeyd: would you like to work on a patch (for Python 3.4)? -- nosy: +loewis ___ Python tracker ___

[issue15751] Support subinterpreters in the GIL state API

Mark Hammond added the comment: To clarify, I wrote: > can be associated with a thread-state specified by the > embedding application Where I meant to say: Can be associated with an interpreter state and corresponding thread-state ... Or something like that - it's been a while since I've lo

[issue14783] Update int() docstring from manual

Ezio Melotti added the comment: .. function:: int(n=0) int(s, base=10) should do the trick. +1 on using this instead of int([number | string[, base]]) -- ___ Python tracker __

[issue15751] Support subinterpreters in the GIL state API

Mark Hammond added the comment: The GIL state api was mainly interested in the case of a thread which has (possibly) never been seen before calling into Python. IIUC, the proposal here is so that a thread that *has* been seen before can be associated with a thread-state specified by the embed

[issue15798] subprocess.Popen() fails if 0, 1 or 2 descriptor is closed

Ezio Melotti added the comment: #10806 seems related. -- components: +Library (Lib) nosy: +ezio.melotti, pitrou, rosslagerwall type: -> behavior ___ Python tracker ___ _

[issue15798] subprocess.Popen() fails if 0, 1 or 2 descriptor is closed

New submission from Aleksey Filippov: System info: kernel: 3.4.8-1-ARCH dist: Arch linux python: 3.2.3 subprocess.Popen() fails if python interpreter is started with closed 0, 1 or 2 descriptor. Traceback (most recent call last): File "", line 14, in File "/usr/lib/python3.2/subprocess.py

[issue1185124] pydoc doesn't find all module doc strings

Nick Coghlan added the comment: Oops, I somehow ended up looking at an old revision of pydoc.py The current version *is* using tokenize.open and importlib in synopsis(), so those aspects of my comments are incorrect. However, the point that pydoc should probably be using the tokenize module to

[issue1185124] pydoc doesn't find all module doc strings

Nick Coghlan added the comment: The standard library has moved on quite a bit since this patch was written... 1. source_synopsis() should be using the tokeniser module when reading the docstring. The current implementation is broken in more ways than just those noted here (e.g. it completely i

[issue13769] json.dump(ensure_ascii=False) return str instead of unicode

Changes by Petri Lehtinen : -- nosy: +pitrou ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python

[issue13769] json.dump(ensure_ascii=False) return str instead of unicode

Petri Lehtinen added the comment: Attached a patch for 2.7 that updates docs and docstrings. -- keywords: +needs review, patch stage: needs patch -> patch review Added file: http://bugs.python.org/file27032/issue13769.patch ___ Python tracker

[issue15785] curses.get_wch() returns keypad codes incorrectly

STINNER Victor added the comment: > If the function returned either a single-character unicode string or an integer > keycode, this would also make it possible to completely drop the is_key_code > part of the return value. (Callers could simply check the type of the return > value to see if it i

[issue14042] json.dumps() documentation is slightly incorrect.

Petri Lehtinen added the comment: This is a documentation bug for 2.7. Setting as duplicate of #13769. -- nosy: +petri.lehtinen resolution: -> duplicate stage: needs patch -> committed/rejected status: open -> closed superseder: -> json.dump(ensure_ascii=False) return str instead of un

[issue13769] json.dump(ensure_ascii=False) return str instead of unicode

Petri Lehtinen added the comment: It may also be unicode if the encoding parameter is used even if there are no unicode objects in the input. >>> json.dumps([u'Ş'.encode('iso-8859-9')], encoding='iso-8859-9', >>> ensure_ascii=False) u'["\u015e"]' -- __

[issue13405] Add DTrace probes

Samuel John added the comment: I did your test. Thank you! You are absolutely right, it seems, dtrace does not honor "CPP" or "PATH" or any other flags and bluntly looks in a hard-coded location. It's not up to you to patch that. -- ___ Python trac

[issue14880] csv.reader and .writer use wrong kwargs notation in 2.7 docs

Hynek Schlawack added the comment: Thank you for your contribution Chris! -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker ___

[issue14880] csv.reader and .writer use wrong kwargs notation in 2.7 docs

Roundup Robot added the comment: New changeset dc080e19f7aa by Hynek Schlawack in branch '2.7': #14880: Fix kwargs notation in csv.reader, .writer & .register_dialect http://hg.python.org/cpython/rev/dc080e19f7aa -- nosy: +python-dev ___ Python tracke

[issue15783] decimal.localcontext(None) fails when using the C accelerator module

Stefan Krah added the comment: Nick Coghlan wrote: > Any third party Decimal manipulating function that accepts an > optional context and passes it down to the standard Decimal API > will be confronted with the same problem in 3.3: passing None > as the context no longer means the same thing as

[issue14880] csv.reader and .writer use wrong kwargs notation in 2.7 docs

Hynek Schlawack added the comment: It seems correct like that: static PyObject * csv_register_dialect(PyObject *module, PyObject *args, PyObject *kwargs) { PyObject *name_obj, *dialect_obj = NULL; PyObject *dialect; if (!PyArg_UnpackTuple(args, "", 1, 2, &name_obj, &dialect_obj))

[issue11489] json.dumps not parsable by json.loads (on Linux only)

Petri Lehtinen added the comment: Bear in mind that Douglas Crockford thinks a JSON document is valid even if it contains unpaired surrogates: http://tech.groups.yahoo.com/group/json/message/1603 http://tech.groups.yahoo.com/group/json/message/1583 It's Unicode that considers unpaired

  1   2   >