[issue29259] Add tp_fastcall to PyTypeObject: support FASTCALL calling convention for all callable objects

STINNER Victor added the comment: Oops, I had a local commit for testing purpose. I regenerated the patch: tp_fastcall-4.patch. > Is PR 65 is same to the third patch? Yes, patches are generated from my Git pull request: https://github.com/python/cpython/pull/65 The Git history became a

[issue29259] Add tp_fastcall to PyTypeObject: support FASTCALL calling convention for all callable objects

INADA Naoki added the comment: @haypo, Rietveld didn't accept your patch. (I don't know what format Rietveld accepts...) Is PR 65 is same to the third patch? -- ___ Python tracker

[issue29304] dict: simplify lookup function

INADA Naoki added the comment: I've attached wrong file. This patch is first version I wanted to post. It dedupe all five functions. -- Added file: http://bugs.python.org/file46325/dict-refactor.patch ___ Python tracker

[issue29304] dict: simplify lookup function

Changes by INADA Naoki : Removed file: http://bugs.python.org/file46324/dictlook-refactoring.patch ___ Python tracker ___

[issue29304] dict: simplify lookup function

INADA Naoki added the comment: Raymond, I understand your worries. I won't commit this until I do more precise survey. But why I trying this is not only I find duplicated code. I think benefit of this technique is reduced by historical reason. In Python 2.7, there are only two lookup

[issue28339] "TypeError: Parameterized generics cannot be used with class or instance checks" in test_functools after importing typing module

Changes by Larry Hastings : -- nosy: -larry ___ Python tracker ___ ___ Python-bugs-list

[issue28339] "TypeError: Parameterized generics cannot be used with class or instance checks" in test_functools after importing typing module

Guido van Rossum added the comment: @levkivskyi Do you want to attempt a better fix in tome for 3.6.1? -- ___ Python tracker ___

[issue29246] typing.Union raises RecursionError when comparing Union to other type

Guido van Rossum added the comment: Fixed, see http://bugs.python.org/issue28556#msg281317 New changeset 75c7bc2c1ad8 by Guido van Rossum in branch '3.5': Issue #28556: upstream improvements to docstrings and error messages by Ivan Levkivskyi (#331)

[issue28556] typing.py upgrades

Roundup Robot added the comment: New changeset 1a9e12a852b2 by Guido van Rossum in branch '3.5': Issue #28556: merge 5 more typing changes from upstream (#340, #344, #348, #349, #350) https://hg.python.org/cpython/rev/1a9e12a852b2 New changeset fd889884fe08 by Guido van Rossum in branch '3.6':

[issue29304] dict: simplify lookup function

Raymond Hettinger added the comment: I worry you guys are rapidly sloshing around and churning code that was developed slowly and methodically over many years. A lot of people have looked at an tweaked the dictionary code, but now it seems like there is a rewrite-everything festival. When

[issue28879] smtplib send_message should add Date header if it is missing, per RFC5322

R. David Murray added the comment: I think this constitutes the heuristic I was talking about in that comment, that will get it right 99+% of the time. Strict mode should raise an error, but strict is not the default in the email package. I probably won't have time to do any review for a

[issue29304] dict: simplify lookup function

Xiang Zhang added the comment: Ahh, I got the same idea before. But then I persuaded myself that the first "lookup()" was deliberately extracted from the loop since it's highly possible there is no collision and you can hit the result (empty or not) the first time. -- nosy:

[issue29304] dict: simplify lookup function

New submission from INADA Naoki: All lookdict* functions are implemented like pseudo language: ``` lookup() if not collision: return result while True: perturb_shift() lookup() if not collision: return result ``` This patch changes it as: ``` while True: lookup()

[issue28879] smtplib send_message should add Date header if it is missing, per RFC5322

Eric Lafontaine added the comment: Hi all, I've received an answer from the IETF Pete Resnick. The answer does say however that there is no guaranteed way of getting the right headers if the message doesn't respect the standard; "[...] In this case, if the trace fields were not present,

[issue29259] Add tp_fastcall to PyTypeObject: support FASTCALL calling convention for all callable objects

STINNER Victor added the comment: Ok, I fixed all remaining issues. The new patch version 3 is now waiting for your review ;-) Patch version 3: * Add Py_TPFLAGS_HAVE_FINALIZE and Py_TPFLAGS_HAVE_FASTCALL to Py_TPFLAGS_DEFAULT * Don't read or write tp_fastcall if the type doesn't have the

[issue29296] convert print() to METH_FASTCALL

STINNER Victor added the comment: Serhiy Storchaka: "Please wait until the support of var-positional arguments be added in Argument Clinic. After that print() could be just converted to Argument Clinic." Why can't we start with METH_FASTCALL and convert to AC later? It seems like

[issue29303] asyncio.Lock.acquire() does not always yield

Guido van Rossum added the comment: No, `yield from` (or, in Python 3.5+, `await`) is not meant to bound back to the scheduler. If the target is a coroutine that itself doesn't yield, it is a *feature* that the scheduler is bypassed. If you want to force a trip through the scheduler, use

[issue29303] asyncio.Lock.acquire() does not always yield

anonymous2017 added the comment: I may have mis-characterized the original report. Rephrasing just to make sure it is correctly addressed: First, it is not about fairness. Sorry for the original characterization. I was trying to understand what was happening. Second, the precise issue is

[issue29303] asyncio.Lock.acquire() does not always yield

Guido van Rossum added the comment: Locks are not meant to have predictable behavior like that. They are meant to protect against concurrent access. If you want fairness you have to look elsewhere. -- ___ Python tracker

[issue29303] asyncio.Lock.acquire() does not always yield

New submission from anonymous2017: Details here: http://stackoverflow.com/questions/41708609/unfair-scheduling-bad-lock-optimization-in-asyncio-event-loop Essentially there should be a `yield` before this line otherwise a coroutine that only acquires and releases a lock will never yield to

[issue29302] add contextlib.AsyncExitStack

New submission from Alexander Mohr: ExitStack is a really useful class and would be a great to have an async version. I've gone ahead and created an implementation based on the existing Python 3.5.2 implementation. Let me know what you guys think. I think it would be possible to combine

[issue28879] smtplib send_message should add Date header if it is missing, per RFC5322

Eric Lafontaine added the comment: Hi all, The IETF didn't answer yet :(. I'll await your news regarding this patch ("issue_28879_V4.patch"). I would like to have feedback if I need to change something. Thanks a lot in advance, Eric Lafontaine --

[issue29282] Fused multiply-add: proposal to add math.fma()

Serhiy Storchaka added the comment: LGTM except that needed the versionadded directive and What's New entry. And maybe few additional tests. -- ___ Python tracker

[issue29282] Fused multiply-add: proposal to add math.fma()

Changes by Mark Dickinson : -- stage: -> patch review ___ Python tracker ___ ___

[issue9216] FIPS support for hashlib

Doug Hellmann added the comment: @Antoine - The idea behind introducing some API mechanism is exactly as you say, to let the developer say "this use of this algorithm is not related to security" to tell FIPS systems to not be pedantic. -- ___

[issue9216] FIPS support for hashlib

Doug Hellmann added the comment: @Robert, I thought you were proposing a hashlib.fips module that did not include md5() at all. If it does include the function, and the function does whatever is needed to disable the "die when using MD5" on a FIPS system, then I agree it would work. Your

[issue29282] Fused multiply-add: proposal to add math.fma()

Mark Dickinson added the comment: And here's a patch. -- keywords: +patch Added file: http://bugs.python.org/file46321/math_fma.patch ___ Python tracker

[issue9216] FIPS support for hashlib

Yolanda added the comment: @rbtcollins, so you mean the apps using it, shall be "fips aware" ? That will be the point of your separate module? So... if fips_enabled then use fips.md5 else use normal.md5 -- ___ Python tracker

[issue29301] decimal: Use FASTCALL and/or Argument Clinic

STINNER Victor added the comment: Raymond Hettinger: "This should not go in without Stephan Krah's approval. This code is finely tuned and carefully arrang" Sure, that's why I opened this issue. Serhiy Storchaka: "See msg207652 in issue20177." Oh, I didn't know that Stefan Krah already

[issue9216] FIPS support for hashlib

Antoine Pitrou added the comment: AFAICT from David's patch, there isn't a new argument in all hashlib functions but only in the digest constructors. Someone might want to correct me. -- ___ Python tracker

[issue9216] FIPS support for hashlib

Ian Cordasco added the comment: So I see the argument on both sides of this discussion. Having those optional arguments for all the functions seems like an obvious blocker. If a submodule is a blocker, what if we provide a context-manager to signal this? -- nosy: +icordasc

[issue9216] FIPS support for hashlib

Antoine Pitrou added the comment: The separate module idea is an interesting one, though I wonder if it aligns with users' goals. Perhaps some users simply want to set the OPENSSL_FORCE_FIPS_MODE environment variable and then run existing Python code with it to ensure that code is

[issue9216] FIPS support for hashlib

Robert Collins added the comment: @doug - I don't see how a separate fips module *wouldn't* solve it: - code that uses md5 in security contexts wouldn't be able to call it from the fips module, which is the needed outcome - code that uses md5 and isn't fips compliant would be importing from

[issue29285] Unicode errors occur inside of multi-line comments

John Taylor added the comment: OP here, thanks for replying to this. I used Zach's suggestion of placing an 'r' in front of triple-quotes. This accomplishes my goal. -- ___ Python tracker

[issue29259] Add tp_fastcall to PyTypeObject: support FASTCALL calling convention for all callable objects

INADA Naoki added the comment: > Maybe it's the expensive price of creating a temporary dictionary? Please see the patch on issue29295. PyDict_GetItemString() is bad part, too. It's create str object, calc hash, lookup dict, and dealloc the str object. --

[issue29301] decimal: Use FASTCALL and/or Argument Clinic

Raymond Hettinger added the comment: This should not go in without Stephan Krah's approval. This code is finely tuned and carefully arranged. -- assignee: -> skrah nosy: +rhettinger ___ Python tracker

[issue29296] convert print() to METH_FASTCALL

Serhiy Storchaka added the comment: Please wait until the support of var-positional arguments be added in Argument Clinic. After that print() could be just converted to Argument Clinic. -- ___ Python tracker

[issue29301] decimal: Use FASTCALL and/or Argument Clinic

Serhiy Storchaka added the comment: See msg207652 in issue20177. -- ___ Python tracker ___ ___

[issue29301] decimal: Use FASTCALL and/or Argument Clinic

STINNER Victor added the comment: Oh wait, I'm not sure that attached patch has a significant impact on performances. It seems like the speedup mostly comes from the print patch: http://bugs.python.org/issue29296#msg285668 But well, it is still interesting to use METH_FASTCALL in decimal ;-)

[issue29300] Modify the _struct module to use FASTCALL and Argument Clinic

Serhiy Storchaka added the comment: Why not just convert the struct module to Argument Clinic? -- ___ Python tracker ___

[issue29296] convert print() to METH_FASTCALL

STINNER Victor added the comment: I reviewed print-fastcall.patch: LGTM, but I proposed a minor change. Serhiy Storchaka: "The performance of print() is not critical. It usually involves slow formatting and IO." I also had the same understanding of print(), but I just analyzed performances

[issue29259] Add tp_fastcall to PyTypeObject: support FASTCALL calling convention for all callable objects

STINNER Victor added the comment: I checked the effect of individual patches: * tp_fastcall-2 * print * struct * decimal tp_fastcall-2 + print + struct + decimal: 16.3 ms +- 0.6 ms tp_fastcall-2 + struct + decimal: 21.2 ms +- 0.3 ms tp_fastcall-2 + print: 16.7 ms +- 0.2 ms Oh wow, I didn't

[issue29259] Add tp_fastcall to PyTypeObject: support FASTCALL calling convention for all callable objects

STINNER Victor added the comment: Back on performances: if you combined tp_fastcall-2.patch + 3 minor changes to use METH_FASTCALL, the bm_telco benchmark becomes 22% faster, which is significant for a benchmark: http://bugs.python.org/issue29301#msg285665 "20.9 ms +- 0.5 ms => 16.4 ms +- 0.5

[issue29301] decimal: Use FASTCALL and/or Argument Clinic

Changes by STINNER Victor : -- nosy: +serhiy.storchaka ___ Python tracker ___ ___

[issue29301] decimal: Use FASTCALL and/or Argument Clinic

New submission from STINNER Victor: I'm currently working on the isuse #29259: "Add tp_fastcall to PyTypeObject: support FASTCALL calling convention for all callable objects". I used bm_telco of the performance benchmark suite to check which functions still require to create a temporary tuple

[issue29292] Missing a parameter in PyEval_EvalCodeEx doc

Xiang Zhang added the comment: > "keywords and defaults," however, the kwdefs argument was never added to the > prototype. I don't think this is about the missing "kwdefs". I think "arrays of arguments, keywords and defaults" is a whole part describing "PyObject **args, int argcount,

[issue29300] Modify the _struct module to use FASTCALL and Argument Clinic

New submission from STINNER Victor: Attached patch modify the _struct module to use FASTCALL and Argument Clinic. AC requires a summary line, so I duplicated the first sentence of iter_unpack() docstring: iter_unpack(fmt, buffer, /) Return an iterator yielding tuples unpacked from the

[issue29292] Missing a parameter in PyEval_EvalCodeEx doc

Ammar Askar added the comment: It looks like a basic description of kwdefs was added as part of this commit: https://github.com/python/cpython/commit/7811a5d1c93f2aa0b357444eeb3f1ddc242ac57a "keywords and defaults," however, the kwdefs argument was never added to the prototype. I've attached

[issue29299] Argument Clinic: Fix signature of optional positional-only arguments

Serhiy Storchaka added the comment: Please don't change this part of Argument Clinic without Larry. There were several attempts to solve this problem, I don't like current status, but this is Larry's decision. -- ___ Python tracker

[issue20291] Argument Clinic should understand *args and **kwargs parameters

Serhiy Storchaka added the comment: Thank you for your examples Raymond, but they don't directly related to this issue, implementing support of var-positional and var-keyword parameters. I believe that it is possible to solve it, and the solution is complex, but is not extremal hard. I'm

[issue29299] Argument Clinic: Fix signature of optional positional-only arguments

Serhiy Storchaka added the comment: The problem is that func(mandatory_arg1, mandatory_arg2[, optional_arg3[, optinal_arg4]]) is not compatible with the inspect module. In many case a meaningful default value was added if this is possible. For example the Python default shown in the

[issue29285] Unicode errors occur inside of multi-line comments

Eryk Sun added the comment: > they do not appear in the byte code files It's simple to coonfirm that unassigned string literals get thrown away.: >>> code = compile('"doc"\n"unused"\n"us"+"ed"', '', 'exec') >>> code.co_consts ('doc', 'us', 'ed', None, 'used') >>> dis.dis(code)

[issue29299] Argument Clinic: Fix signature of optional positional-only arguments

STINNER Victor added the comment: This issue is blocking me to convert more functions to Argument Clinic. See for example attached getattr_ac.patch which converts getattr() to AC. Without ac_optional_positional.patch, AC generates the signature: "getattr($module, object, name,

[issue29299] Argument Clinic: Fix signature of optional positional-only arguments

STINNER Victor added the comment: See also issue #20291: "Argument Clinic should understand *args and **kwargs parameters". -- ___ Python tracker ___

[issue29289] Convert OrderedDict methods to Argument Clinic

Serhiy Storchaka added the comment: I have added other comments on Rietveld (mostly about docstrings). -- nosy: +serhiy.storchaka ___ Python tracker ___

[issue20291] Argument Clinic should understand *args and **kwargs parameters

STINNER Victor added the comment: FYI I started to work on a different Argument Clinic enhancement, issue #29299: "Argument Clinic: Fix signature of optional positional-only arguments". -- nosy: +haypo ___ Python tracker

[issue29297] python3 open() does not check argument type before attempting to read() or write()

Serhiy Storchaka added the comment: Builtin open() in Python 3 (and io.open() in Python 2.7) accept unicode strings, byte strings and integers as the first arguments (general path-like objects also are supported in Python 3.6, but it doesn't matter). bool is a subtype of int, and False is

[issue29289] Convert OrderedDict methods to Argument Clinic

STINNER Victor added the comment: For OrderedDict.pop(), I created the issue #29299: "Argument Clinic: Fix signature of optional positional-only arguments". -- ___ Python tracker

[issue29299] Argument Clinic: Fix signature of optional positional-only arguments

STINNER Victor added the comment: List of functions modified when Argument Clinic is run to regenerate .c.h files: builtin_format builtin_getattr builtin_input builtin_sum cmath_log _codecs_ascii_decode _codecs_ascii_encode _codecs_charmap_decode _codecs_charmap_encode _codecs_code_page_encode

[issue29299] Argument Clinic: Fix signature of optional positional-only arguments

New submission from STINNER Victor: When a function has only positional arguments and at least one argument is optional, the expected signature is: func(mandatory_arg1, mandatory_arg2[, optional_arg3[, optinal_arg4]]) For example, the signature of format() is inconsistent with its

[issue29297] python3 open() does not check argument type before attempting to read() or write()

Mo Ali added the comment: Serhiy, I expected a type error or a filenotfound like you received, however mine doesn't return the same. It just hangs. I've attached a picture. Also, I meant this to be for 3.6 not 3.5. >>> test = False >>> with open(test) as f: ... fail = f.read() ...

[issue29297] python3 open() does not check argument type before attempting to read() or write()

Serhiy Storchaka added the comment: The first example raises an error: Traceback (most recent call last): File "", line 1, in FileNotFoundError: [Errno 2] No such file or directory: 'False' Unless you have a file named "False" in the current directory of course. What behavior you expected?

[issue20291] Argument Clinic should understand *args and **kwargs parameters

Raymond Hettinger added the comment: In case it is helpful, here's my list of examples where the AC and existing signature objects are insufficiently expressive: type(obj) type(name, bases, mapping) two different signatures depending on type range(stop) range(start, stop) range(start,

[issue29298] argparse fails with required subparsers, un-named dest, and empty argv

New submission from zachrahan: In python 3.6 (and several versions back), using argparse with required subparsers will cause an unhelpful TypeError if the 'dest' parameter is not explicitly specified, and no arguments are provided. Test case: import argparse parser = argparse.ArgumentParser()

[issue29285] Unicode errors occur inside of multi-line comments

R. David Murray added the comment: @zach: actually, triple quoted strings *are* suggested as a way to do multiline comments, and are often used for that. In particular, note that they do not appear in the byte code files if they are not assigned to anything or appear in the docstring

[issue29297] python3 open() does not check argument type before attempting to read() or write()

New submission from Mo Ali: Python3 open(), read(), or write()doesn't check argument type before action causing a hang. Would like to catch exceptions but not without an exception to return. See below. Python3.6: Python 3.6.0 (default, Dec 24 2016, 08:01:42) [GCC 4.2.1 Compatible Apple LLVM

[issue9216] FIPS support for hashlib

Yolanda added the comment: I agree with Doug. From my understanding, the intention of the patch is to allow the usage of md5 for non-security purposes, without being blocked by FIPS. Right now, md5() calls running on a FIPS enabled kernel, are blocked without discrimination of the usage, that

[issue20291] Argument Clinic should understand *args and **kwargs parameters

Serhiy Storchaka added the comment: I'll try to implement the support of var-positional parameters. -- assignee: larry -> serhiy.storchaka versions: +Python 3.7 -Python 3.4, Python 3.5 ___ Python tracker

[issue16623] argparse help formatter does not honor non-breaking space

Changes by Peter Otten <__pete...@web.de>: -- nosy: +peter.otten ___ Python tracker ___ ___ Python-bugs-list

[issue29290] argparse breaks long lines on NO-BREAK SPACE

Changes by Peter Otten <__pete...@web.de>: -- nosy: +peter.otten ___ Python tracker ___ ___ Python-bugs-list

[issue29287] IDLE needs syntax highlighting for f-strings

Changes by Peter Otten <__pete...@web.de>: -- nosy: +peter.otten ___ Python tracker ___ ___ Python-bugs-list

[issue29280] gdbm & ndbm support missing in Windows

R. David Murray added the comment: This has always been the case (that gdbm and ndbm are not supported on windows). See also issue 3769 for background and dbm and windows, and issue 3783 for something to work on if you want to contribute to making the dbm story on windows better. Googling

[issue9216] FIPS support for hashlib

Doug Hellmann added the comment: @rbcollins, I don't think providing a hashlib.fips module without md5() solves the problem. The idea is to have a way to call md5() in non-secure situations, and to signal to the FIPS system that the call is OK. A separate module would work if it included an

[issue29295] dict: Optimize PyDict_GetItemString()

STINNER Victor added the comment: > Close this issue for now, until profiler shows me PyDict_XString. I like Serhiy's rationale. We should try to avoid PyDict_GetItemString() wheneve possible. If PyDict_GetItemString() becomes a clear bottleneck, we can discuss again optimizing it. But in

[issue29296] convert print() to METH_FASTCALL

STINNER Victor added the comment: Hi, Serhiy Storchaka: "The performance of print() is not critical. It usually involves slow formatting and IO." Oh, please, I want a print() using METH_FASTCALL! Not for the performance, but just to help me in my development! To identify code not using

[issue29294] ctypes.windll.LoadLibrary refuses unicode argument

Changes by Eryk Sun : -- resolution: -> duplicate stage: -> resolved superseder: -> In 2.7.13, _ctypes.LoadLibrary no longer accepts Unicode objects ___ Python tracker

[issue20291] Argument Clinic should understand *args and **kwargs parameters

Changes by INADA Naoki : -- nosy: +inada.naoki ___ Python tracker ___ ___

[issue29296] convert print() to METH_FASTCALL

INADA Naoki added the comment: I see. AC should support this. -- dependencies: +Argument Clinic should understand *args and **kwargs parameters resolution: -> later status: open -> pending ___ Python tracker

[issue29295] dict: Optimize PyDict_GetItemString()

INADA Naoki added the comment: Close this issue for now, until profiler shows me PyDict_XString. -- resolution: -> rejected status: open -> closed ___ Python tracker

[issue29295] dict: Optimize PyDict_GetItemString()

INADA Naoki added the comment: This patch checks passed C string is ascii or not. But I don't want make dict complex too. telco is more faster with issue29296. Most common builtin functions are not METH_KEYWORDS when it merged. -- ___ Python

[issue29296] convert print() to METH_FASTCALL

Serhiy Storchaka added the comment: The performance of print() is not critical. It usually involves slow formatting and IO. _PyArg_ParseStackAndKeywords() is a part of unstable, fast-evolved API. I would beware of using it in common code. -- nosy: +serhiy.storchaka

[issue29295] dict: Optimize PyDict_GetItemString()

Serhiy Storchaka added the comment: It looks to me that PyDict_GetItemString(), PyObject_GetAttrString(), etc are mainly for backward compatibility and for using in performance non-critical code. Performance critical code caches string objects. The only code that heavily used

[issue29296] convert print() to METH_FASTCALL

New submission from INADA Naoki: Median +- std dev: [default] 24.2 ms +- 0.4 ms -> [patched] 19.2 ms +- 0.4 ms: 1.26x faster (-21%) -- files: print-fastcall.patch keywords: patch messages: 285632 nosy: haypo, inada.naoki priority: normal severity: normal status: open title: convert

[issue29295] dict: Optimize PyDict_GetItemString()

New submission from INADA Naoki: PyDict_GetItemString() is heavily used, especially from keyword argument parsing. Current implementation creates temporary string for key object. This patch avoid the temporary key string when passed C string is ASCII. This benchmark is based on a8563ef0eb8a,

[issue29294] ctypes.windll.LoadLibrary refuses unicode argument

Changes by Thomas Heller : -- status: open -> closed ___ Python tracker ___ ___

[issue29294] ctypes.windll.LoadLibrary refuses unicode argument

Thomas Heller added the comment: Yes, seems that it is fixed in the repository. So I have to use 2.7.12 or wait for 2.7.14. Thanks! -- ___ Python tracker

[issue29294] ctypes.windll.LoadLibrary refuses unicode argument

Xiang Zhang added the comment: #29082 fixed it? -- nosy: +xiang.zhang ___ Python tracker ___ ___

[issue29294] ctypes.windll.LoadLibrary refuses unicode argument

New submission from Thomas Heller: ctypes.windll.LoadLibrary refuses unicode argument; this is a regression in Python 2.7.13: Python 2.7.13 (v2.7.13:a06454b1afa1, Dec 17 2016, 20:42:59) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information.

[issue29291] Misleading text in the documentation of re library for non-greedy match

Raymond Hettinger added the comment: I concur with Serhiy and Xiang that the docs are correct as-is. Also IMO, the proposed rewording will cause more confusion than it cures. Since this issue hasn't previously come up in the rather long life span of the re module, it suggests that most

[issue29291] Misleading text in the documentation of re library for non-greedy match

Xiang Zhang added the comment: This doesn't look like a bug in the doc to me. -- nosy: +xiang.zhang ___ Python tracker ___

[issue29293] Missing parameter "n" on multiprocessing.Condition.notify()

Changes by Raymond Hettinger : -- assignee: -> davin nosy: +davin ___ Python tracker ___

[issue29293] Missing parameter "n" on multiprocessing.Condition.notify()

Victor de la Fuente added the comment: Sorry for the typo, I meant: #Replacing the call with condition.notify(n=2): #TypeError: notify() got an unexpected keyword argument 'n' -- ___ Python tracker

[issue29291] Misleading text in the documentation of re library for non-greedy match

Serhiy Storchaka added the comment: The documentation doesn't look incorrect to me. The non-greedy match doesn't fallback to the greedy match, it always matches as few characters as *possible* will be matched. For example a.match(" b e ") matches " b ", not " b e ". -- nosy:

[issue29293] Missing parameter "n" on multiprocessing.Condition.notify()

New submission from Victor de la Fuente: Versions: Darwin MacBook-Pro-de-Victor.local 16.3.0 Darwin Kernel Version 16.3.0: Thu Nov 17 20:23:58 PST 2016; root:xnu-3789.31.2~1/RELEASE_X86_64 x86_64 Python 3.6.0 (v3.6.0:41df79263a11, Dec 22 2016, 17:23:13) [GCC 4.2.1 (Apple Inc. build 5666) (dot

[issue29292] Missing a parameter in PyEval_EvalCodeEx doc

Changes by Xiang Zhang : -- keywords: +easy stage: -> needs patch ___ Python tracker ___

[issue29029] Faster positional arguments parsing in PyArg_ParseTupleAndKeywords

Serhiy Storchaka added the comment: Thank you for your reviews Inada and Victor. Thank you for rebasing the patch Victor. I were going first to try an alternative patch, maybe less efficient, but allowing to share more code. But since the code is changed so fast, it is better to commit the

[issue29029] Faster positional arguments parsing in PyArg_ParseTupleAndKeywords

Roundup Robot added the comment: New changeset a8563ef0eb8a by Serhiy Storchaka in branch 'default': Issue #29029: Speed up processing positional arguments in https://hg.python.org/cpython/rev/a8563ef0eb8a -- ___ Python tracker

[issue29292] Missing a parameter in PyEval_EvalCodeEx doc

New submission from Xiang Zhang: The signature of PyEval_EvalCodeEx now gets a "PyObject *kwdefs" parameter but the doc doesn't mention it. -- assignee: docs@python components: Documentation messages: 285620 nosy: docs@python, xiang.zhang priority: normal severity: normal status: open

[issue29291] Misleading text in the documentation of re library for non-greedy match

New submission from ipolcak: The text about non-greedy match in the documentation for re library is misleading. The docs for py2.7 (https://docs.python.org/2.7/library/re.html) and 3.6 (https://docs.python.org/3.6/library/re.html) says: "The '*', '+', and '?' qualifiers are all greedy; they

[issue28518] execute("begin immediate") throwing OperationalError

Ma Lin added the comment: some comments on Aviv Palivoda's patch. -- ___ Python tracker ___ ___

  1   2   >