[issue15783] decimal.localcontext(None) fails when using the C accelerator module
Nick Coghlan added the comment: Note that it's only the 3.2 interactive help that specifies ctx=None, and it's almost certainly lifting that directly from the Python implementation. The C implementation is definitely in compliance with the prose docs, which give the signature as localcontext([c]) and say If no context is specified, a copy of the current context is used without indicating whether passing in None explicitly is supposed to count as not specifying a context. However, the specific problem that prompted this report is that you used to be able to write code like: def my_decimal_func(arg1, arg2, context=None): with decimal.localcontext(context): # perform decimal operations on arg1 and arg2 but with the C implementation, such code will break. You have to instead write something less idiomatic like: def my_decimal_func(arg1, arg2, *context): with decimal.localcontext(*context): # perform decimal operations on arg1 and arg2 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 omitting the context argument entirely. We can either handle this as a documentation issue (recommending the *args based idiom above as an alternative to passing an explicit None), or else change the C implementation to accept context=None as equivalent to omitting the context argument entirely. I'm inclined towards the latter, simply due to the backwards compatibility breach: explicitly calling localcontext(None) would indeed be silly, but calling localcontext(context), where context comes from a parameter with a default value of None, is perfectly normal Python code. Idiomatic code that worked correctly in the previous Python version is a reasonably strong argument in favour of retaining the feature. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15783 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9694] argparse required arguments displayed under optional arguments
Changes by Martin Burger m...@rtin-burger.net: -- nosy: +mburger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9694 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14880] csv.reader and .writer use wrong kwargs notation in 2.7 docs
Hynek Schlawack added the comment: What does bother you? Both sigs look like in py3 if I'm looking correctly. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14880 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15775] Add StopParser() to expat
Nemeskey Dávid added the comment: OK, then this issue has a bug part, too: it is not mentioned in the documentation that exceptions from the handler methods propagate through the Parse() method. I guess the parser can be then stopped in this way too, but it is a dirty method as opposed to calling StopParser(). To answer your question, there are several situations where StopParser() could come in handy. For instance, the XML file might contain records (such as the output of a search engine), from which we only need the first n. Another example would be that reading through the file we realize halfway that e.g. it does not contain the information we need, contains wrong information, etc. so we want to skip the rest of it. Since the file might be huge and since XML parsing can in now way be considered fast, being able to stop the parsing in a clear way would spare the superfluous and possible lengthy computation. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15775 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15789] mention shell-like parts of the std lib in the subprocess docs
Chris Rebert added the comment: Revised patch in response to comments. -- Added file: http://bugs.python.org/file27029/subprocess.rst.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15789 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15794] test_importlib: test_locks failure
Stefan Krah added the comment: The patch works fine here (as expected). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15794 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11176] give more meaningful argument names in argparse documentation
David Lam added the comment: here's a patch that covers all but one of the foo/bar/baz examples it also has fixes for the sample code near the beginning from the review Ezio did the one example I didn't do was the Arguments containing - part. I guess it felt like changing the names in that example would distract from what it was trying to illustrate there Anyways, I tried to proofread it so hopefully it reads okay, enjoy enjoy ^^ -- Added file: http://bugs.python.org/file27030/issue11176.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11176 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1185124] pydoc doesn't find all module doc strings
Changes by Mike Hoy mho...@gmail.com: -- nosy: +mikehoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1185124 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11964] Undocumented change to indent param of json.dump in 3.2
Roundup Robot added the comment: New changeset 5bff555168ab by Petri Lehtinen in branch '3.2': #11964: Document a change in v3.2 to the json indent parameter http://hg.python.org/cpython/rev/5bff555168ab New changeset 0fb511659ef4 by Petri Lehtinen in branch 'default': #11964: Document a change in v3.2 to the json indent parameter http://hg.python.org/cpython/rev/0fb511659ef4 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11964 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11964] Undocumented change to indent param of json.dump in 3.2
Petri Lehtinen added the comment: Fixed, thanks. -- resolution: - fixed stage: commit review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11964 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14880] csv.reader and .writer use wrong kwargs notation in 2.7 docs
Petri Lehtinen added the comment: Well, I wasn't sure about [optional] params before **kwargs. But if that's ok, then I think the patch is good. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14880 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15797] bdist_msi does not pass -install/remove flags to install_script
New submission from B Maqueira: When building an msi package using the --install-script=xx.py, the script xx.py is called on msi package install/removal as expected. However the cmd line flags -install/-remove are not passed to the script making it hard to write step specific code. I experienced this under python 2.7.3 (winXP / distutils 2.7.3, setuptools 0.6c11). I attach a patch for bdist_msi.py for your consideration. Kind regards, Braudel -- assignee: eric.araujo components: Distutils files: patch.diff keywords: patch messages: 169262 nosy: braudel, eric.araujo, tarek priority: normal severity: normal status: open title: bdist_msi does not pass -install/remove flags to install_script type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file27031/patch.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15797 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9668] strings in json.dump in '' instead of
Petri Lehtinen added the comment: No activity in 2 years, closing. -- nosy: +petri.lehtinen status: pending - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9668 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 surrogates invalid, not UTF-8 by itself. -- nosy: +petri.lehtinen ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11489 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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))
return NULL;
Therefore going to commit.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14880
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15783] decimal.localcontext(None) fails when using the C accelerator module
Stefan Krah added the comment: Nick Coghlan rep...@bugs.python.org 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 omitting the context argument entirely. I agree, but for me the issue is: What is the standard API? If you look at the Context methods in decimal.py, you see this pattern: def add(self, a, b): ... r = a.__add__(b, context=self) So I think it's reasonably safe to say that all Decimal methods only take a context=None argument because it happens to be a convenient way of implementing the Context methods. With that reasoning, most of the list in msg169144 would be eliminated already. I sort of regret that the Decimal methods of the C version take a context argument at all, but the arguments are documented. Now to localcontext(ctx=None). Yes, code might exist that does the following: def f(a, b, context=None): with localcontext(context): return a / b It is, however, a strange function: If I explicitly pass a context to a function, I'd expect that it is also used for recording any status that accumulates in the function (or that the function actually *can* accumulate status at all). If I'm only interested in the precision, I'd write: def f(a, b, prec=None): with localcontext() as c: c.prec = 9 if prec is None else prec return Decimal(a) / b [This is along the lines of Raymond's original suggestion in #15136.] But there are other examples of unexpected behavior, such as Decimal.to_eng_string(context) taking a context purely to determine the value of context.capitals, i.e. no status flags can possibly be set. Here I'd also prefer: to_eng_string(capitals=1) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15783 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 tracker rep...@bugs.python.org http://bugs.python.org/issue14880 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 rep...@bugs.python.org http://bugs.python.org/issue14880 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 tracker rep...@bugs.python.org http://bugs.python.org/issue13405 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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]'
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13769
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 unicode versions: -Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14042 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 is a keycode.) I tried to mimic the getkey() function, but I like your idea. In many cases you don't have to check explicitly the type. Example: if key == q: quit(), or if key == curses.KEY_UP: move(1). It works also if the key is used as a key of a dictionary: key = callback. And yes, keyname() can be used to mimic manually getkey() behaviour. It does not solve unget_wch() issue, but I propose to drop the unget_wch()+get_wch() test on non-ASCII keys because it looks like a bug in the curses library. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15785 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 rep...@bugs.python.org http://bugs.python.org/issue13769 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13769] json.dump(ensure_ascii=False) return str instead of unicode
Changes by Petri Lehtinen pe...@digip.org: -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13769 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ignores the declared encoding) (The reason for not using full compilation is that you would then have to either *run* the compiled code or else compile to the AST and interrogate that, which is technically implementation dependent) 2. For 3.3+, synopsis should be using importlib to get the source code rather than assuming filesystem imports. That's probably better handled in a separate issue, though. -- assignee: ping - nosy: +ncoghlan versions: +Python 3.3 -Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1185124 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 do the parsing inside source_synopsis remains valid. There's no good reason to continue duplicating a subset of that text processing logic within pydoc. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1185124 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 string, line 14, in module File /usr/lib/python3.2/subprocess.py, line 745, in __init__ restore_signals, start_new_session) File /usr/lib/python3.2/subprocess.py, line 1197, in _execute_child restore_signals, start_new_session, preexec_fn) ValueError: errpipe_write must be = 3 -- messages: 169276 nosy: sarum9in priority: normal severity: normal status: open title: subprocess.Popen() fails if 0, 1 or 2 descriptor is closed versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15798 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 rep...@bugs.python.org http://bugs.python.org/issue15798 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 embedding application (and the degenerate case would be to assume the thread hasn't been seen, and as such should get the default interpreter) If that isn't too wide of the mark, I agree it sounds workable and worthwhile. -- nosy: +mhammond ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15751 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 rep...@bugs.python.org http://bugs.python.org/issue14783 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 looked at that code. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15751 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 rep...@bugs.python.org http://bugs.python.org/issue15775 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 breaks if you use the flags - if they were 100% backwards compatible, Microsoft wouldn't have made them separate options. - distutils is essentially frozen, any change to it requires considerable negotiation. - for Python 2.7 to 3.3, making such a change would be a new feature (to pass the Windows 8 certification), which cannot be added to a bug fix release. So if you insist that this is a distutils bug, I'll re-close the issue as won't fix. Instead, I suggest to find a way to solve this within py2exe's setup.py, e.g. by monkey-patching distutils.msvccompiler.MSVCCompiler with a subclass of msvc9compiler.MSVCCompiler. -- resolution: invalid - wont fix ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15762 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 form (as surrogate pairs) and do not directly represent characters. When encoding in UTF-8 from UTF-16 data, it is necessary to first decode the UTF-16 data to obtain character numbers, which are then encoded in UTF-8 as described above. -- nosy: +storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11489 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 subsequent calls to PyGILState_Ensure from *that thread* should get the explicitly associated interpreter, rather than the main interpreter. Then, the lookup sequence for interpreter=NULL would be: 1. Check the active TLS key, if set, use that thread state 2. If not set, look up the main interpreter's TLS key. If set, also set that on the active TLS key and use that thread state. 3. If still not set, create a new thread state on the main interpreter, set it for both the active TLS and the main interpreter's TLS key and use that thread state A similar approach almost works when requesting a specific interpreter, but where that goes wrong is when the active TLS key is *already set*. You can't just overwrite it, because that will cause problems for subsequent PyGIL_Release calls. You could just make it an error, but I think Graham's original idea makes it possible to do better than that. Specifically, a PyGILState_SwitchInterpreter API could focus solely on the manipulation of the active thread state TLS key entry. The sequence of commands in mod_wsgi would then look like: old_interp = PyGILState_SwitchInterpreter(target_interp); old_gil = PyGILState_Ensure(); /* Call into Python using target_interp */ PyGILState_Release(old_gil); PyGILState_SwitchInterpreter(old_interp); /* May not be needed in the mod_wsgi case, since it knows it is making the outermost call into the PyGILState_* APIs */ All of the other elements of Antoine's proposal (i.e. the per-interpreter TLS key entries) would still be needed, it's just that the API for associating a thread with an interpreter would remain separated from that of associating the thread with a particular thread state. The big advantage of doing it this way is that it will nest properly, whereas PyGILState_EnsureEx would need a more complicated API to correctly report both the old interpreter state and the old GIL state within that interpreter. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15751 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13266] Add inspect.unwrap(f) to easily unravel __wrapped__ chains
Changes by Éric Araujo mer...@netwok.org: -- versions: +Python 3.4 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13266 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 rep...@bugs.python.org http://bugs.python.org/issue15775 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15797] bdist_msi does not pass -install/remove flags to install_script
Changes by B Maqueira brau...@ferrarihaines.com: Added file: http://bugs.python.org/file27033/patch1.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15797 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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_interp); /* May not be needed in the mod_wsgi case, since it knows it is making the outermost call into the PyGILState_* APIs */ Why wouldn't it be simply written: old_gil = PyGILState_EnsureEx(target_interp); /* Call into Python using target_interp */ PyGILState_Release(old_gil); -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15751 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 available, falls back to MAKEFLAGS, and then tries to match -s. The only downside is that you won't get a quiet build, if you don't have getopt, and pass MAKEFLAGS options as a combined option (e.g. -fs). -- keywords: +patch Added file: http://bugs.python.org/file27034/makeflags.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15591 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13592] repr(regex) doesn't include actual regex
Changes by Ezio Melotti ezio.melo...@gmail.com: -- stage: needs patch - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13592 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 MAKEFLAGS in the sharedmods target. http://hg.python.org/cpython/rev/763d188a96bb New changeset 3a3fd48a6ef7 by Matthias Klose in branch 'default': - Issue #15591: Fix parsing MAKEFLAGS in the sharedmods target. http://hg.python.org/cpython/rev/3a3fd48a6ef7 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15591 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 rep...@bugs.python.org http://bugs.python.org/issue15591 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15794 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15794] test_importlib: test_locks failure
Changes by Antoine Pitrou pit...@free.fr: -- resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15794 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15591] when building the extensions, stdout is lost when stdout is redirected
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15591 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14468] Update cloning guidelines in devguide
Changes by Mike Hoy mho...@gmail.com: -- nosy: +mikehoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14468 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 tracker rep...@bugs.python.org http://bugs.python.org/issue15784 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 this. So we have a tie here: Mark thinks it can wait, Nick thinks it's better to do something. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15783 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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
status2 = HTTP/1.1 200
status3 = HTTP/1.1 200
status1.split(None, 2)
['HTTP/1.1', '200', 'OK']
status2.split(None, 2)
['HTTP/1.1', '200']
status3.split(None, 2)
['HTTP/1.1', '200']
According to the production rules of HTTP/1.1 bis only status1 and status2 are
valid.
status-line = HTTP-version SP status-code SP reason-phrase CRLF
— http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-20#section-3.1.2
with reason-phrase = *( HTAB / SP / VCHAR / obs-text ) aka 0 or more
characters.
I'm also not sure what are the expected ValueError with additional parsing
rules which seems even more bogus.
First modification should be
status1.split(' ', 2)
['HTTP/1.1', '200', 'OK']
status2.split(' ', 2)
['HTTP/1.1', '200', '']
Which would be correct for the first two, with an empty reason-phrase
The third one is still no good.
status3.split(' ', 2)
['HTTP/1.1', '200']
An additional check could be done with
len(status.split(' ', 2)) == 3
Will return False in the third case.
Do you want me to create a patch and a test for it?
--
messages: 169293
nosy: karlcow
priority: normal
severity: normal
status: open
title: httplib client and statusline
type: enhancement
versions: Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15799
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 tracker rep...@bugs.python.org http://bugs.python.org/issue15799 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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* None or of type/interface XXX.) So colour me -0 on changing cdecimal to allow the 'None' argument. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15783 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 condition now always true and standard files are closed after use. Here is a patch that fixes this error. -- components: Library (Lib) files: gzip_main_close.patch keywords: patch messages: 169296 nosy: pitrou, storchaka priority: low severity: normal status: open title: Closing of sys.std* files in gzip test. type: resource usage versions: Python 3.2, Python 3.3 Added file: http://bugs.python.org/file27035/gzip_main_close.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15800 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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#l318 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15799 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 rep...@bugs.python.org http://bugs.python.org/issue15799 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 idea. -- nosy: +orsenthil, pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15799 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 tuple with exactly the number of items specified by the format string, or a single mapping object (for example, a dictionary). Tested and confirmed on 2.5, 2.6, 2.7 (both old and new style classes) and 3.2. -- messages: 169300 nosy: eallik priority: normal severity: normal status: open title: Weird string interpolation behaviour type: behavior versions: Python 2.6, Python 2.7, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15801 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 rep...@bugs.python.org http://bugs.python.org/issue15801 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15801 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15801] Weird string interpolation behaviour
R. David Murray added the comment: Didn't get an error in 2.7, either, with Message(). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15801 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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: +Mike.Graham ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15801 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 are right and choose or not to ignore and having to avoid to patch the libraries or rewrite modules when you create code which needs to be strict for specifically validating responses and requests. :) ps: I haven't checked yet if the server counter part of httplib was strict in the production rule. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15799 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 rep...@bugs.python.org http://bugs.python.org/issue15591 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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, storchaka priority: normal severity: normal status: open title: Illegal test for mailbox type: behavior versions: Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file27036/test_mailbox_create_tmp.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15802 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15802] Illegal test for mailbox
Changes by Serhiy Storchaka storch...@gmail.com: Added file: http://bugs.python.org/file27037/test_mailbox_create_tmp-2.7.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15802 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 rep...@bugs.python.org http://bugs.python.org/issue15802 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15802] Illegal test for mailbox
Changes by A.M. Kuchling li...@amk.ca: -- nosy: -akuchling ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15802 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 (closes #15801) http://hg.python.org/cpython/rev/4d431e719646 New changeset 263d09ce3e9e by Benjamin Peterson in branch 'default': merge 3.2 (#15801) http://hg.python.org/cpython/rev/263d09ce3e9e -- nosy: +python-dev resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15801 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 that simplified API to work against a sub interpreter. Nick, I previously said: In the case of the latter, if a Python thread is created in a specific sub interpreter, it should automatically designate for that thread that that is its interpreter context, so if it calls out and does the Release/Ensure dance, that it goes back into the same sub interpreter. So yes to your: 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 subsequent calls to PyGILState_Ensure from *that thread* should get the explicitly associated interpreter, rather than the main interpreter. My example was more to do with a thread created in Python then calling out and back in, but same deal as foreign thread calling in, out and back in. Antoine, yes, can possibly can be simplified to that. The original idea of a switch interpreter function was suggested on basis that PyGILState_Ensure would not be modified or extended version of function created. Rolling an implicit switch interpreter into PyGILState_EnsureEx when argument is different to the current may serve same purpose. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15751 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 libncurses 5.7. This version is old and has known bugs. So the unget_wch issue is maybe unrelated. -- Added file: http://bugs.python.org/file27038/curses_get_wch-2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15785 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15785] curses.get_wch() returns keypad codes incorrectly
Changes by STINNER Victor victor.stin...@gmail.com: Removed file: http://bugs.python.org/file27007/curses_get_wch.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15785 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 rep...@bugs.python.org http://bugs.python.org/issue15785 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15785 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15785] curses.get_wch() returns keypad codes incorrectly
Changes by STINNER Victor victor.stin...@gmail.com: Removed file: http://bugs.python.org/file27038/curses_get_wch-2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15785 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15785 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 that out by accident. Not sure why test_zipimport_support didn't fail with that one. But regardless we'll have to deal with pyclbr if/when we isolate the doctest test files. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14649 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 have been fixed in Python 3.3. It would be a regression to remove get_wch(), it's an important function to use the curses module with Python 3. Changes between Python 3.2 and 3.3: http://docs.python.org/dev/whatsnew/3.3.html#curses -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15785 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15785] curses.get_wch() returns keypad codes incorrectly
Changes by STINNER Victor victor.stin...@gmail.com: Added file: http://bugs.python.org/file27038/curses_get_wch-2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15785 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 apologies for not running the full test suite before uploading those patches. I'll take a closer look. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14649 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15785] curses.get_wch() returns keypad codes incorrectly
Changes by STINNER Victor victor.stin...@gmail.com: Removed file: http://bugs.python.org/file27039/curses_get_wch-3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15785 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 version 3 and restored patch version 2 which only changes the get_wch() API and adapts the existing unit test. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15785 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15785] curses.get_wch() returns keypad codes incorrectly
STINNER Victor added the comment: @simpkins: can you please try my patch? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15785 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15801] Weird string interpolation behaviour
Erik Allik added the comment: Respectable reaction time. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15801 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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() definition. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15785 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 rep...@bugs.python.org http://bugs.python.org/issue15785 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 files into a subdirectory. Thanks again for the catch, David. -- Added file: http://bugs.python.org/file27040/issue-14649-6.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14649 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15800] Closing of sys.std* files in gzip test.
Changes by Jesús Cea Avión j...@jcea.es: -- nosy: +jcea ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15800 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15802] Illegal test for mailbox
Changes by Jesús Cea Avión j...@jcea.es: -- nosy: +jcea ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15802 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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: Incorrect docstring on ConfigParser.items() type: enhancement versions: Python 3.2, Python 3.3 Added file: http://bugs.python.org/file27041/cpython.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15803 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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. However, I still think it would be better if consistency with the Python API could be restored for 3.3.1. If that's done via a more general this value means the arg is actually missing C API that can be made public in 3.4, so much the better. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15783 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 adds excess verbiage and makes code slightly harder to read. All I need except to do most of the time is suppress exceptions. I think the language could be enhanced by making the except clause implicit. the above would become: process stuff try : someSubProcess.kill() process stuff The intent remains clear. The code is cleaner and easier to read. This does not happen often in rigorous code, but grep does find 3 counts in standard modules and 9 counts in numpy. I'm certain most prototype code (like mine) would greatly benefit. (My current 300 line project uses 4 so far.) -- components: Interpreter Core messages: 169326 nosy: gd2shoe priority: normal severity: normal status: open title: Feature request, implicit except : pass type: enhancement versions: Python 2.7, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15804 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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): return exctype == self.exc with Pass(IndexError): 'hello'[10] -- nosy: +rhettinger priority: normal - low ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15804 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 rep...@bugs.python.org http://bugs.python.org/issue15804 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 to correctly restore the associated interpreter back to interpreter A when you're done. EnsureEx works fine if extension modules are not aware of multiple interpreters: /* Embedding application (GIL always unlocked) */ gilstate = PyGILState_EnsureEx(interp_A); /* Python code and extension code happens */ /* Callback needs to reach back into Python */ cb_gilstate = PyGILState_Ensure(); /* Callback runs */ PyGILState_Release(cb_gilstate); /* Python code and extension code unwinds */ PyGILState_Release(gilstate); However, it *doesn't* work (at least, not easily) if the extension itself wants to call back into an interpreter other than the one already associated with the current thread: /* Embedding application (GIL always unlocked) */ gilstate = PyGILState_EnsureEx(interp_A); /* Python code and extension code happens */ /* Callback needs to reach back into a specific interpreter */ cb_gilstate = PyGILState_EnsureEx(interp_B); /* Callback runs */ PyGILState_Release(cb_gilstate); /* Python code and extension code unwinds */ PyGILState_Release(gilstate); Does that second call to EnsureEx fail? If it succeeds, how does the client know which interpreter to use for the PyGILState_Release call? It could be made to work if PyGILState_STATE was changed from an enum to a struct that included in interpreter state pointer, or if EnsureEx returned a different type and was paired up with a new ReleaseEx pointer. However, that's starting to get very messy compared to a separate SwitchInterpreter call: /* Embedding application (GIL always unlocked) */ old_interp = PyGILState_SwitchInterpreter(interp_A); /* autoTLSkey now refers to a thread state for interpreter A */ gilstate = PyGILState_Ensure(); /* Python code and extension code happens */ /* Callback needs to reach back into Python */ pre_cb_interp = PyGILState_SwitchInterpreter(interp_B); /* autoTLSkey now refers to a thread state for interpreter B */ cb_gilstate = PyGILState_Ensure(); /* Callback runs */ PyGILState_Release(cb_gilstate); PyGILState_SwitchInterpreter(pre_cb_interp); /* autoTLSkey again refers to a thread state for interpreter A */ /* Python code and extension code unwinds */ PyGILState_Release(gilstate); PyGILState_SwitchInterpreter(old_interp); And yes, I'm pondering ways that this could be used to implement Rust-style channels for communication between interpreters without needing to copy data, by using this API to create proxy interfaces for accessing an object owned by another subinterpreter. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15751 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 gets used in the Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15751 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 rep...@bugs.python.org http://bugs.python.org/issue15804 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 state an opaque structure that isn't exposed in the
limited API. Something along the lines of:
typedef struct _gilinfo {
PyGILState_STATE lock_state;
PyInterpreter *active;
} PyGILState_INFO;
int /* Allow returning an error code */
PyGILState_EnsureEx(PyInterpreterState *target,
PyGILState_INFO*prev);
void
PyGILState_ReleaseEx(PyGILState_INFO *prev);
This allows various issues related to implicitly creating thread states to be
handled the same way they are now, where PyThreadState_New will create a
persistent thread state, while PyGILState_EnsureEx will either use a
preexisting thread state for the requested interpreter (if it exists), or
implicitly create one. Implicitly created thread states would be destroyed by
the corresponding call to ReleaseEx.
To make this work, I believe all that should be needed is for:
1. PyInterpreterState updated to include a per-interpreter TLS key
2. _PyGILState_NoteThreadState would update both the autoTLSkey entry and the
per-interpreter key entry
3. PyGILState_EnsureEx added to support switching the autoTLSkey entry to point
to a different thread state (creating it if needed)
4. PyGILState_Ensure updated to map to PyGILState_EnsureEx(NULL) and to extract
the lock state from the info structure
5. PyGILState_Release updated to populate the info structure with the active
interpreter and the passed in previous GIL state before calling
PyGILState_ReleaseEx
5. PyThreadState_Delete and PyThreadState_DeleteCurrent updated to also clobber
the per-interpreter TLS key entry
PyThreadState_New already calls _PyGILState_NoteThreadState implicitly, so
Python created threads (and embedded threads with an explicitly created thread
state) should do the right thing automatically.
Making the INFO struct an opaque token also means it can be expanded to cover
any future needs that arise.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15751
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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_Ensure() it is a value passed back into PyGILState_Release(). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15751 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 create the thread state. For Release, the likely error is calling it with the system in the wrong state. I think the current API reflects a difference between an extension mindset and an embedding mindset. If those calls go wrong in an extension context, killing the entire application is likely the only thing you can reasonably do. In an embedded context, though, the embedding application likely has other options (such as reinitialising the entire Python interpreter). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15751 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 function already supports redirection but it much be done for every
single call to print(). The context manager let's the redirection apply to a
batch of statements.
The context manager is also useful with existing tools that don't currently
provide output redirection hooks:
from collections import namedtuple
with open('model.py', 'w') as module:
with RedirectStdout(module):
namedtuple('Person', ['name', 'age', 'email'], verbose=True)
import dis
with open('disassembly.txt', 'w') as f:
with RedirectStdout(f):
dis.dis(myfunc)
A possible implementation is:
class RedirectStdout:
''' Create a context manager for redirecting sys.stdout
to another file.
'''
def __init__(self, new_target):
self.new_target = new_target
def __enter__(self):
self.old_target = sys.stdout
sys.stdout = self.new_target
return self
def __exit__(self, exctype, excinst, exctb):
sys.stdout = self.old_target
--
components: Library (Lib)
messages: 169335
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Add stdout redirection tool to contextlib
type: enhancement
versions: Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15805
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
