[issue23316] Incorrect evaluation order of function arguments with *args

Irit Katriel added the comment: See also issue33492. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue23316] Incorrect evaluation order of function arguments with *args

Terry J. Reedy added the comment: I was pointing out what to me is a second related contradiction in the doc, between one sentence and the next. -- ___ Python tracker ___

[issue23316] Incorrect evaluation order of function arguments with *args

Guido van Rossum added the comment: I'm currently not very interested in philosophizing about why we allow one syntax but not the other. -- ___ Python tracker ___

[issue23316] Incorrect evaluation order of function arguments with *args

Terry J. Reedy added the comment: (The nosy list change was an accident of my local copy not being complete refreshed before posting.) If (b=b, *c) were evaluated in order, then the byte code for b=b and any subsequent keyword arguments would have to be put aside, such as in a separate

[issue23316] Incorrect evaluation order of function arguments with *args

Guido van Rossum added the comment: Looks like Terry accidentally removed Serhiy. Adding him back. -- nosy: +Guido.van.Rossum, serhiy.storchaka ___ Python tracker ___

[issue23316] Incorrect evaluation order of function arguments with *args

Irit Katriel added the comment: It should be possible to make the compiler emit code that evaluates the arg values left to right in all cases. -- ___ Python tracker ___

[issue23316] Incorrect evaluation order of function arguments with *args

Change by Terry J. Reedy : -- nosy: -serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue23316] Incorrect evaluation order of function arguments with *args

Change by Serhiy Storchaka : -- versions: +Python 3.11 -Python 3.4, Python 3.5 ___ Python tracker ___ ___ Python-bugs-list mailing

[issue23316] Incorrect evaluation order of function arguments with *args

Serhiy Storchaka added the comment: Would not be be better in long term to get rid of irregularities? It would make the grammar simpler and the documentation clearer. The only use case of such syntax in wrappers, but they always can be rewritten in other style, with natural order of

[issue23316] Incorrect evaluation order of function arguments with *args

Neil Girdhar added the comment: FYI: https://github.com/PyCQA/pylint/issues/4586 -- ___ Python tracker ___ ___ Python-bugs-list

[issue23316] Incorrect evaluation order of function arguments with *args

Guido van Rossum added the comment: Well, it seems we're stuck -- we can't make the grammar more restrictive (at least, I don't think we should, since it is a backwards incompatibility), so we'll have to live with the exception. Since it is now clear what the rule is, we can update the

[issue23316] Incorrect evaluation order of function arguments with *args

Serhiy Storchaka added the comment: See also thread "Order of positional and keyword arguments" on the Python-Dev mailing list (https://mail.python.org/archives/list/python-...@python.org/thread/I6AUYV6DVEMP7XVYVDWC62N6PK6FHX3H/). -- nosy: +serhiy.storchaka

[issue23316] Incorrect evaluation order of function arguments with *args

b) normal For whatever reason, the byte code is more complicated without function arguments. e(a, b=b, *g, **k) 1 0 LOAD_NAME0 (e) 2 LOAD_NAME1 (a) 4 BUILD_LIST 1 6 LOAD_NAME2 (g)

[issue23316] Incorrect evaluation order of function arguments with *args

Guido van Rossum added the comment: > "The one exception is in function calls with *expression after a keyword > argument: f(x=expr2, *expr1)." So the question before us is whether to add this phrase to the docs, or to tweak the compiler to fix it. It is certainly convenient to update the

[issue23316] Incorrect evaluation order of function arguments with *args

Terry J. Reedy added the comment: The particular example of left-to-right function evaluation in https://docs.python.org/3/reference/expressions.html#evaluation-order is "expr1(expr2, expr3, *expr4, **expr5)". Joshua's claim, without evidence, that "'f(*a(), b=b())' will evaluate b() before

[issue23316] Incorrect evaluation order of function arguments with *args

Irit Katriel added the comment: I don't think this is true anymore: >>> def a(): ... print('a') ... return (1,2) ... >>> def b(): ... print('b') ... return (3,4) ... >>> def f(*args, b=None): ... print('f') ... >>> f(*a(), b=b()) a b f >>> -- nosy: +iritkatriel

[issue43227] Backslashes in function arguments in f-string expressions

Change by Eric V. Smith : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker ___ ___

[issue43227] Backslashes in function arguments in f-string expressions

Eric V. Smith added the comment: Yes, they're prohibited anywhere inside of the braces {}. This might be relaxed in the future, but through 3.9 it's still enforced. -- ___ Python tracker

[issue43227] Backslashes in function arguments in f-string expressions

Change by Karthikeyan Singaravelan : -- nosy: +eric.smith ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43227] Backslashes in function arguments in f-string expressions

t;test\ test\ test" path = f"{my_str.replace(r'\ ', ' ')}" gives my_str = "test\ test\ test" path = f"{my_str.replace(r'\ ', ' ')}" SyntaxError: f-string expression part cannot include a backslash -- messages: 386978 nosy: nabelekt priority: normal severit

[issue42921] Inferred Optional type of wrapper function arguments

`get_type_hints` not taking `wraps` in account at all), because inferred `Optional` is a kind deprecated feature (https://github.com/python/typing/issues/275). -- messages: 385005 nosy: joperez priority: normal severity: normal status: open title: Inferred Optional type of wrapper function

Is there a Python profiler that preserves function arguments?

I'm profiling a Python function `foo()` that takes a single argument, but that argument makes a huge difference in what the function actually does. Currently I'm using `cProfile`, which records every call to `foo()` as if it was the same, preventing me from figuring out what's going on. Is there

[issue34792] Tutorial doesn''t discuss / and * function arguments

Pablo Galindo Salgado added the comment: I don't think we should backport the changes or modify the file for the 3.7 branch, so I close the issue. Feel free to reopen if you still think it makes sense :) -- resolution: -> fixed stage: -> resolved status: open -> closed

[issue34792] Tutorial doesn''t discuss / and * function arguments

Karthikeyan Singaravelan added the comment: With PEP 570 implementation docs were expanded : https://github.com/python/cpython/commit/b76302ddd0896cb39ce69909349b53db6e7776e2#diff-d764089fca21fdc70d55804714b1cba5 -- nosy: +pablogsal ___ Python

Re: Get Count of function arguments passed in

Sayth Renshaw schreef op 11/09/2019 om 12:11: I want to allow as many lists as needed to be passed into a function. But how can I determine how many lists have been passed in? I expected this to return 3 but it only returned 1. matrix1 = [[1, -2], [-3, 4],] matrix2 = [[2, -1], [0, -1]] matrix3

Re: Get Count of function arguments passed in

> I expected this to return 3 but it only returned 1. > > matrix1 = [[1, -2], [-3, 4],] > matrix2 = [[2, -1], [0, -1]] > matrix3 = [[2, -1], [0, -1]] > > def add(*matrix): > print(len(locals())) > > print(add(matrix1, matrix2)) In this case, locals will be a dictionary with exactly one key.

Re: Get Count of function arguments passed in

Le 11/09/2019 à 12:11, Sayth Renshaw a écrit : Hi I want to allow as many lists as needed to be passed into a function. But how can I determine how many lists have been passed in? I expected this to return 3 but it only returned 1. matrix1 = [[1, -2], [-3, 4],] matrix2 = [[2, -1], [0, -1]]

Re: Get Count of function arguments passed in

On Wednesday, 11 September 2019 20:25:32 UTC+10, Sayth Renshaw wrote: > On Wednesday, 11 September 2019 20:11:21 UTC+10, Sayth Renshaw wrote: > > Hi > > > > I want to allow as many lists as needed to be passed into a function. > > But how can I determine how many lists have been passed in? > >

Re: Get Count of function arguments passed in

On Wednesday, 11 September 2019 20:11:21 UTC+10, Sayth Renshaw wrote: > Hi > > I want to allow as many lists as needed to be passed into a function. > But how can I determine how many lists have been passed in? > > I expected this to return 3 but it only returned 1. > > matrix1 = [[1, -2],

Get Count of function arguments passed in

Hi I want to allow as many lists as needed to be passed into a function. But how can I determine how many lists have been passed in? I expected this to return 3 but it only returned 1. matrix1 = [[1, -2], [-3, 4],] matrix2 = [[2, -1], [0, -1]] matrix3 = [[2, -1], [0, -1]] # print(add(matrix1,

[issue35138] timeit documentation should have example with function arguments

STINNER Victor added the comment: Thanks Anders Hovmöller! Example added to Python 3.7 and 3.8 documentation :-) -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue35138] timeit documentation should have example with function arguments

miss-islington added the comment: New changeset 7f485ea4fc17c5afb38cd0478ff15326fb5a47fc by Miss Islington (bot) in branch '3.7': bpo-35138: Added an example for timeit.timeit with callable arguments (GH-9787) https://github.com/python/cpython/commit/7f485ea4fc17c5afb38cd0478ff15326fb5a47fc

[issue35138] timeit documentation should have example with function arguments

STINNER Victor added the comment: New changeset 8da5ebe11e0cb6599af682b22f7c2b2b7b9debd8 by Victor Stinner (Anders Hovmöller) in branch 'master': bpo-35138: Added an example for timeit.timeit with callable arguments (GH-9787)

[issue35138] timeit documentation should have example with function arguments

Change by miss-islington : -- pull_requests: +13205 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35138] timeit documentation should have example with function arguments

Change by davidak : -- keywords: +patch pull_requests: +9598 stage: needs patch -> patch review ___ Python tracker ___ ___

[issue35138] timeit documentation should have example with function arguments

Karthikeyan Singaravelan added the comment: There is an open PR that adds a similar example. Is it the same as the one you are proposing and I think you can add a review comment to add it with the same PR if it's different? PR : https://github.com/python/cpython/pull/9787 Thanks

[issue35138] timeit documentation should have example with function arguments

Change by Serhiy Storchaka : -- keywords: +easy stage: -> needs patch type: -> enhancement versions: +Python 3.8 ___ Python tracker ___

[issue35138] timeit documentation should have example with function arguments

@python priority: normal severity: normal status: open title: timeit documentation should have example with function arguments versions: Python 3.6, Python 3.7 ___ Python tracker <https://bugs.python.org/issue35

[issue34792] Tutorial doesn''t discuss / and * function arguments

Change by Ezio Melotti : -- nosy: +ezio.melotti ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34792] Tutorial doesn''t discuss / and * function arguments

Karthikeyan Singaravelan added the comment: There is a related issue to document / in signatures though : https://bugs.python.org/issue21314 -- nosy: +xtreak ___ Python tracker

[issue34792] Tutorial doesn''t discuss / and * function arguments

: normal status: open title: Tutorial doesn''t discuss / and * function arguments type: enhancement versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue34

[issue33774] Document that @lru_cache caches based on exactly how the function arguments are specified

Change by Raymond Hettinger : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue33774] Document that @lru_cache caches based on exactly how the function arguments are specified

Change by miss-islington : -- pull_requests: +8728 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33774] Document that @lru_cache caches based on exactly how the function arguments are specified

Change by Raymond Hettinger : -- keywords: +patch pull_requests: +8727 stage: needs patch -> patch review ___ Python tracker ___

[issue33774] Document that @lru_cache caches based on exactly how the function arguments are specified

Srinivas Reddy T added the comment: Hi Raymond, I find your statement hard to understand.I agree with Solstag, it is always helpful to have an example. +1 for solstag wording. -- nosy: +thatiparthy ___ Python tracker

[issue33774] Document that @lru_cache caches based on exactly how the function arguments are specified

Al-Scandar Solstag added the comment: Speaking frankly, I might not have grasped what might happen by reading your line. I think having at least a minimal example is crucial. Perhaps: "Distinct argument patterns, such as `f(1)` and `f(first_arg=1)`, may not cache for each other even if the

[issue33774] Document that @lru_cache caches based on exactly how the function arguments are specified

Raymond Hettinger added the comment: I propose this, "Distinct argument patterns may be considered to be distinct calls with distinct results even if the underlying function sees them as equivalent calls." -- ___ Python tracker

[issue33774] Document that @lru_cache caches based on exactly how the function arguments are specified

Al-Scandar Solstag added the comment: Hi Raymond, I think I understand what you mean, and would suggest something along the lines of: """ Note that lru_cache only guarantees cache matches on the exact way function arguments are specified, so the following ways of callin

[issue33774] Document that @lru_cache caches based on exactly how the function arguments are specified

Raymond Hettinger added the comment: Sure, I can add a line mentioning that distinct argument patterns may be considered as distinct cache entries even though they otherwise seem to be equivalent calls. That will just be a general statement though. The specific details are implementation

[issue33774] Document that @lru_cache caches based on exactly how the function arguments are specified

R. David Murray added the comment: Agreed that this should be documented. -- nosy: +r.david.murray, rhettinger stage: -> needs patch title: Improve doc of @lru_cache to avoid misuse and confusion -> Document that @lru_cache caches based on exactly how the function arg

[issue33588] Unicode function arguments aren't preserved

Steven D'Aprano added the comment: This does seem to be a normalisation issue: py> unicodedata.normalize('NFKC', 'ϵαγϕ') == ''.join(func.__code__.co_varnames) True so I'm closing this as not a bug. Mike, thank you for copying and pasting the relevant text into the

[issue33588] Unicode function arguments aren't preserved

Mat Leonard added the comment: Ah great, then I just need to do something like unicodedata.normalize('NFKC', 'Ω'). Thanks! On Sun, May 20, 2018 at 2:59 PM Eric V. Smith wrote: > > Eric V. Smith added the comment: > > I think

[issue33588] Unicode function arguments aren't preserved

Eric V. Smith added the comment: I think you're seeing identifier normalization. See this SO question for a description of the issue: https://stackoverflow.com/questions/34097193/identifier-normalization-why-is-the-micro-sign-converted-into-the-greek-letter --

[issue33588] Unicode function arguments aren't preserved

New submission from Mat Leonard <leonard@gmail.com>: Unicode symbols used as function arguments aren't preserved in the variable names available from .__code__.co_varnames. Example shown below. def func(ϵ, α, γ, ϕ): pass varnames = func.__code__.co_varnames print(varnames) pr

[issue23316] Incorrect evaluation order of function arguments with *args

Terry J. Reedy added the comment: I expect left to right as documented (and designed by Guido). His OK or clarification would be to intentionally do differently. -- nosy: +terry.reedy ___ Python tracker rep...@bugs.python.org

[issue23316] Incorrect evaluation order of function arguments with *args

Neil Girdhar added the comment: After thinking about this a bit more, my suggestion is not to fix it. Instead, I suggest that PEP 8 be modified to suggest that all positional arguments and iterable argument unpackings precede keyword arguments and keyword argument unpackings. Then, a tool

[issue23316] Incorrect evaluation order of function arguments with *args

Neil Girdhar added the comment: (I also suggest that the evaluation order within a function argument list to be defined to be positional and iterable before keyword, otherwise left-to-right —  rather than strictly left-to-right). -- ___ Python

[issue23316] Incorrect evaluation order of function arguments with *args

SilentGhost added the comment: It seems, if I read https://docs.python.org/3/reference/expressions.html#calls correctly that the evaluation order of the function arguments is not defined in general, as it depends on your use of keyword argument and exact function signature. Naturally, f

[issue23316] Incorrect evaluation order of function arguments with *args

R. David Murray added the comment: The resolution of issue 16967 argues that this should probably be considered a bug. It certainly goes against normal Python expectations. I think it should also be considered to be of low priority, though. -- nosy: +r.david.murray priority: normal

[issue23316] Incorrect evaluation order of function arguments with *args

Core messages: 234672 nosy: Joshua.Landau priority: normal severity: normal status: open title: Incorrect evaluation order of function arguments with *args type: behavior versions: Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http

[issue23316] Incorrect evaluation order of function arguments with *args

Neil Girdhar added the comment: actually, we accept alternation, so maybe a bit to say whether we start with a list or a dict followed by a length of the alternating sequence? -- ___ Python tracker rep...@bugs.python.org

[issue23316] Incorrect evaluation order of function arguments with *args

R. David Murray added the comment: Neil: I presume you are speaking of your in-progress PEP patch, and not the current python code? If so, please keep the discussion of handling this in the context of the PEP to the PEP issue. This issue should be for resolving the bug in the current code

[issue23316] Incorrect evaluation order of function arguments with *args

Neil Girdhar added the comment: Yes, sorry David. I got linked here from the other issue. In any case, in the current code, the longest alternating sequence possible is 4. So one way to solve this is to change the CALL_FUNCTION parameters to be lists and dicts only and then process the

[issue23316] Incorrect evaluation order of function arguments with *args

Neil Girdhar added the comment: another option is to add a LIST_EXTEND(stack_difference) opcode that would allow us to take the late iterable and extend a list at some arbitrary stack position. I had to add something like that for dicts for the other issue, so it would follow that pattern.

[issue23316] Incorrect evaluation order of function arguments with *args

Neil Girdhar added the comment: I assume this is the problem: dis.dis('f(*a(), b=b())') 1 0 LOAD_NAME0 (f) 3 LOAD_NAME1 (a) 6 CALL_FUNCTION0 (0 positional, 0 keyword pair) 9 LOAD_CONST

Meaning of * in the function arguments list

Hi Consider the following to_bytes method from integer class: int.to_bytes(length, byteorder, *, signed=False) What doest the '*' in the arguments list means ? -- https://mail.python.org/mailman/listinfo/python-list

Re: Meaning of * in the function arguments list

ast wrote: Consider the following to_bytes method from integer class: int.to_bytes(length, byteorder, *, signed=False) What doest the '*' in the arguments list means ? A bare * indicates that the arguments that follow it are keyword-only: def f(a, b=2, *, c=3): ... print(a = {}, b =

Re: Meaning of * in the function arguments list

Peter Otten __pete...@web.de a écrit dans le message de news:mailman.15291.1414574006.18130.python-l...@python.org... A bare * indicates that the arguments that follow it are keyword-only: ok, thx -- https://mail.python.org/mailman/listinfo/python-list

Re: Meaning of * in the function arguments list

On 10/29/2014 4:56 AM, ast wrote: Consider the following to_bytes method from integer class: int.to_bytes(length, byteorder, *, signed=False) What doest the '*' in the arguments list means ? If you go to the online doc index page for Symbols, https://docs.python.org/3/genindex-Symbols.html

[issue11271] concurrent.futures.ProcessPoolExecutor.map() doesn't batch function arguments by chunks

Roundup Robot added the comment: New changeset f87c2c4f03da by Antoine Pitrou in branch 'default': Issue #11271: concurrent.futures.Executor.map() now takes a *chunksize* https://hg.python.org/cpython/rev/f87c2c4f03da -- nosy: +python-dev ___ Python

[issue11271] concurrent.futures.ProcessPoolExecutor.map() doesn't batch function arguments by chunks

Antoine Pitrou added the comment: Sorry for the delay. I simplified the patch a tiny bit (yield from wasn't needed, it was sufficient to result the itertools.chain.from_iterable() result), and committed it. Thank you! -- resolution: - fixed stage: patch review - resolved status: open

[issue11271] concurrent.futures.ProcessPoolExecutor.map() doesn't batch function arguments by chunks

Dan O'Reilly added the comment: Hey, my first committed patch :) Thanks for helping to push this through, Antoine! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11271 ___

[issue11271] concurrent.futures.ProcessPoolExecutor.map() doesn't batch function arguments by chunks

Dan O'Reilly added the comment: A couple of small updates based on comments from Charles-François Natali: * Use itertools.chain.from_iterable to yield from the result chunks instead of a for loop. * Add more tests with varying chunksizes. -- Added file:

[issue11271] concurrent.futures.ProcessPoolExecutor.map() doesn't batch function arguments by chunks

Changes by Antoine Pitrou pit...@free.fr: -- nosy: +neologix stage: - patch review versions: +Python 3.5 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11271 ___

[issue11271] concurrent.futures.ProcessPoolExecutor.map() doesn't batch function arguments by chunks

Antoine Pitrou added the comment: Thanks for the update! This looks basically good, I'll wait a bit to see if other people have comments, otherwise I'll commit. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11271

[issue11271] concurrent.futures.ProcessPoolExecutor.map() doesn't batch function arguments by chunks

Dan O'Reilly added the comment: Here's an updated patch that adds documentation and Antoine's requested code changes. -- Added file: http://bugs.python.org/file36306/map_chunksize_with_docs.patch ___ Python tracker rep...@bugs.python.org

[issue11271] concurrent.futures.ProcessPoolExecutor.map() doesn't batch function arguments by chunks

Changes by Josh Rosenberg shadowranger+pyt...@gmail.com: -- nosy: +josh.rosenberg ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11271 ___ ___

[issue11271] concurrent.futures.ProcessPoolExecutor.map() doesn't batch function arguments by chunks

Dan O'Reilly added the comment: I've attached an updated patch based on your review comments; there's now a unit test with a non-default chunksize, the chunking algorithm is more readable, and the same code path is used no matter what chunksize is provided. I've also updated the test script

[issue11271] concurrent.futures.ProcessPoolExecutor.map() doesn't batch function arguments by chunks

Changes by Dan O'Reilly oreil...@gmail.com: Removed file: http://bugs.python.org/file36065/test_mult.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11271 ___

[issue11271] concurrent.futures.ProcessPoolExecutor.map() doesn't batch function arguments by chunks

Changes by Dan O'Reilly oreil...@gmail.com: Added file: http://bugs.python.org/file36185/test_mult.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11271 ___

[issue11271] concurrent.futures.ProcessPoolExecutor.map() doesn't batch function arguments by chunks

Antoine Pitrou added the comment: Thank you for the patch. I've posted some review comments. Two further remarks: - this makes the ProcessPool API slightly different from the ThreadPool one. I wonder if this is acceptable or not. Thoughts? - the patch would need unit tests for the additional

[issue11271] concurrent.futures.ProcessPoolExecutor.map() doesn't batch function arguments by chunks

Dan O'Reilly added the comment: re: Diverging ThreadPoolExecutor and ProcessPoolExecutor APIs. I thought about this as well. It would of course be possible to make ThreadPoolExecutor's API match, but it would serve no useful purpose that I can think of. I guess we could make the

[issue11271] concurrent.futures.ProcessPoolExecutor.map() doesn't batch function arguments by chunks

Antoine Pitrou added the comment: Thank you for posting this, I'm reopening the issue. -- nosy: +sbt resolution: out of date - status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11271

[issue11271] concurrent.futures.ProcessPoolExecutor.map() doesn't batch function arguments by chunks

Changes by Dan O'Reilly oreil...@gmail.com: Removed file: http://bugs.python.org/file36059/map_chunksize.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11271 ___

[issue11271] concurrent.futures.ProcessPoolExecutor.map() doesn't batch function arguments by chunks

Changes by Dan O'Reilly oreil...@gmail.com: Added file: http://bugs.python.org/file36064/map_chunksize.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11271 ___

[issue11271] concurrent.futures.ProcessPoolExecutor.map() doesn't batch function arguments by chunks

Changes by Dan O'Reilly oreil...@gmail.com: Removed file: http://bugs.python.org/file36058/test_mult.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11271 ___

[issue11271] concurrent.futures.ProcessPoolExecutor.map() doesn't batch function arguments by chunks

Changes by Dan O'Reilly oreil...@gmail.com: Added file: http://bugs.python.org/file36065/test_mult.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11271 ___

[issue11271] concurrent.futures.ProcessPoolExecutor.map() doesn't batch function arguments by chunks

Changes by Dan O'Reilly oreil...@gmail.com: Removed file: http://bugs.python.org/file36064/map_chunksize.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11271 ___

[issue11271] concurrent.futures.ProcessPoolExecutor.map() doesn't batch function arguments by chunks

Changes by Dan O'Reilly oreil...@gmail.com: Added file: http://bugs.python.org/file36067/map_chunksize.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11271 ___

[issue11271] concurrent.futures.ProcessPoolExecutor.map() doesn't batch function arguments by chunks

Dan O'Reilly added the comment: I've added new versions of the patch/demonstration that ensures we actually submit all the futures before trying to yield from the returned iterator. Previously we were just returning a generator object when map was called, without actually submitting any

[issue11271] concurrent.futures.ProcessPoolExecutor.map() doesn't batch function arguments by chunks

Dan O'Reilly added the comment: I'm seeing an even larger difference between multiprocessing.Pool and ProcessPoolExecutor on my machine, with Python 3.4: Starting multiproc...done in 2.160644769668579 s. Starting futures...done in 67.953957319259644 s. Starting futures fixed...done in

[issue11271] concurrent.futures.ProcessPoolExecutor.map() doesn't batch function arguments by chunks

Dan O'Reilly added the comment: Here's a patch that adds the new map implementation from the benchmark script to concurrent.futures.process. -- keywords: +patch Added file: http://bugs.python.org/file36059/map_chunksize.patch ___ Python tracker

ALL function arguments in a common dictionary

Hi everybody, what is the recommended way of stuffing *all* function arguments (not just the ones passed by **kwargs) into a common dictionary? The following sort of works when used as the first block in a function: try: kwargs.update(locals()) except NameError: kwargs = locals().copy

Re: ALL function arguments in a common dictionary

]) ... return out_dict ... func(1,2, gah=123) {'a': 1, 'c': 3, 'b': 2, 'gah': 123} On Wed, Apr 24, 2013 at 2:36 PM, Wolfgang Maier wolfgang.ma...@biologie.uni-freiburg.de wrote: Hi everybody, what is the recommended way of stuffing *all* function arguments (not just the ones passed

[issue11271] concurrent.futures.ProcessPoolExecutor.map() doesn't batch function arguments by chunks

Changes by Brian Quinlan br...@sweetapp.com: -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11271 ___ ___ Python-bugs-list

[issue14918] Incorrect TypeError message for wrong function arguments

Changes by Jesús Cea Avión j...@jcea.es: -- nosy: +jcea ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14918 ___ ___ Python-bugs-list mailing list

[issue14918] Incorrect TypeError message for wrong function arguments

Éric Araujo mer...@netwok.org added the comment: I think this was fixed in 3.3, and maybe backported. Could you test with the latest releases? -- nosy: +benjamin.peterson, eric.araujo title: Incorrect explanation of TypeError exception - Incorrect TypeError message for wrong function

[issue14918] Incorrect TypeError message for wrong function arguments

R. David Murray rdmur...@bitdance.com added the comment: It is fixed. It was not backported. -- nosy: +r.david.murray resolution: - duplicate stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org

[issue11271] concurrent.futures.ProcessPoolExecutor.map() doesn't batch function arguments by chunks

Brian Quinlan br...@sweetapp.com added the comment: I'm closing this since tbrink didn't respond to pitrou's comments. -- resolution: - out of date ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11271

[issue11271] concurrent.futures.ProcessPoolExecutor.map() doesn't batch function arguments by chunks

: concurrent.futures.ProcessPoolExecutor.map() slower than multiprocessing.Pool.map() for fast function argument - concurrent.futures.ProcessPoolExecutor.map() doesn't batch function arguments by chunks versions: +Python 3.3 -Python 3.2 ___ Python tracker rep

  1   2   >