[issue44019] operator.call/operator.__call__

2021-10-21 Thread Dong-hee Na


Change by Dong-hee Na :


--
pull_requests: +27418
pull_request: https://github.com/python/cpython/pull/29142

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44019] operator.call/operator.__call__

2021-10-21 Thread Dong-hee Na


Dong-hee Na  added the comment:


New changeset 37fad7d3b7154c44b9902a2ab0db8641f1a0284b by Dong-hee Na in branch 
'main':
bpo-44019: Add test_all_exported_names for operator module (GH-29124)
https://github.com/python/cpython/commit/37fad7d3b7154c44b9902a2ab0db8641f1a0284b


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44019] operator.call/operator.__call__

2021-10-21 Thread Dong-hee Na


Dong-hee Na  added the comment:

> test___all__ was not supposed to fail with the missing "call" in 
> operator.__all__?

AFAIK, it doesn't check.

I add the test for the operator module.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44019] operator.call/operator.__call__

2021-10-21 Thread Dong-hee Na


Change by Dong-hee Na :


--
pull_requests: +27401
pull_request: https://github.com/python/cpython/pull/29124

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44019] operator.call/operator.__call__

2021-10-21 Thread STINNER Victor


STINNER Victor  added the comment:

test___all__ was not supposed to fail with the missing "call" in 
operator.__all__?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44019] operator.call/operator.__call__

2021-10-21 Thread Dong-hee Na


Dong-hee Na  added the comment:


New changeset a53456e587c2e935e7e77170d57960e8c80d8a4d by Kreus Amredes in 
branch 'main':
bpo-44019: Add operator.call() to __all__ for the operator module (GH-29110)
https://github.com/python/cpython/commit/a53456e587c2e935e7e77170d57960e8c80d8a4d


--
nosy: +corona10

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44019] operator.call/operator.__call__

2021-10-21 Thread Antony Lee


Change by Antony Lee :


--
nosy:  -Antony.Lee

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44019] operator.call/operator.__call__

2021-10-21 Thread Kreusada


Change by Kreusada :


--
nosy: +Kreusada
nosy_count: 7.0 -> 8.0
pull_requests: +27394
pull_request: https://github.com/python/cpython/pull/29110

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44019] operator.call/operator.__call__

2021-09-24 Thread Mark Dickinson


Mark Dickinson  added the comment:


New changeset bfe26bbad787c124f0ce144cff1b513ef9d2dc9c by Terry Jan Reedy in 
branch 'main':
bpo-44019: Add missing comma to operator.call doc (GH-28551)
https://github.com/python/cpython/commit/bfe26bbad787c124f0ce144cff1b513ef9d2dc9c


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44019] operator.call/operator.__call__

2021-09-24 Thread Terry J. Reedy


Change by Terry J. Reedy :


--
nosy: +terry.reedy
nosy_count: 6.0 -> 7.0
pull_requests: +26934
pull_request: https://github.com/python/cpython/pull/28551

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44019] operator.call/operator.__call__

2021-09-24 Thread Mark Dickinson


Mark Dickinson  added the comment:

Thanks for the contribution!

--
stage: patch review -> resolved
status: open -> closed
type:  -> enhancement

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44019] operator.call/operator.__call__

2021-09-24 Thread Mark Dickinson


Mark Dickinson  added the comment:


New changeset 6587fc60d447603fb8c631d81d9bb379f53c39ab by Antony Lee in branch 
'main':
bpo-44019: Implement operator.call(). (GH-27888)
https://github.com/python/cpython/commit/6587fc60d447603fb8c631d81d9bb379f53c39ab


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44019] operator.call/operator.__call__

2021-09-01 Thread Antony Lee


Antony Lee  added the comment:

Python2's apply has different semantics: it takes non-unpacked arguments, i.e.

def apply(f, args, kwargs={}): return f(*args, **kwargs)

rather than

def call(f, *args, **kwargs): return f(*args, **kwargs)

I agree that both functions can be written in two (or one) line, but the same 
can be said of most functions in the operator module (def add(x, y): return x + 
y); from the module's doc ("efficient functions corresponding to the intrinsic 
operators"), I would argue that the criteria for inclusion are efficiency 
(operator.call is indeed fast, see the linked PR) and intrinsicness (I don't 
know if there's a hard definition, but function calling certainly seems 
intrinsic).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44019] operator.call/operator.__call__

2021-08-31 Thread STINNER Victor


STINNER Victor  added the comment:

> `call(f, *args, **kwargs) == f(*args, **kwargs)`

So you can want to reintroduce the Python 2 apply() function which was removed 
in Python 3.

You can reimplement it in 2 lines, no?

def call(func, *args, **kwargs):
  return func(*args, **kwargs)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44019] operator.call/operator.__call__

2021-08-30 Thread Antony Lee


Antony Lee  added the comment:

> I'm not convinced that operator.caller() would be useful to me.

To be clear, as noted above, I have realized that the semantics I initially 
proposed (now known as "caller") are not particularly useful; the semantics I 
am proposing (and implementing in the linked PR) are `call(f, *args, **kwargs) 
== f(*args, **kwargs)`.

> I don't see how operator.caller() implements an existing "intrinsic operators 
> of Python".

Agreed; on the other hand function calling is much more intrinsic(?!)

> Can't you use functools.partial() for that?

How do you propose to do that?  Perhaps I am missing an easy solution...

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44019] operator.call/operator.__call__

2021-08-30 Thread STINNER Victor


STINNER Victor  added the comment:

> An actual use case I had for such an operator was collecting a bunch of 
> callables in a list and wanting to dispatch them to 
> concurrent.futures.Executor.map, i.e. something like 
> `executor.map(operator.call, funcs)` (to get the parallelized version of 
> `[func() for func in funcs]`).

Can't you use functools.partial() for that?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44019] operator.call/operator.__call__

2021-08-30 Thread STINNER Victor


STINNER Victor  added the comment:

Python 2.7 had apply(func, args, kwargs) which called func(*args, **kwargs).
https://docs.python.org/2.7/library/functions.html#apply

There is also functools.partial(func, *args, **kwargs)(*args2, **kwargs2) which 
calls func(*args, *args2, **kwargs, **kwargs2).
https://docs.python.org/dev/library/functools.html#functools.partial

operator.methodcaller(name, /, *args, **kwargs)(obj) calls getattr(obj, 
name)(*args, **kwargs).
https://docs.python.org/dev/library/operator.html#operator.methodcaller

I'm not convinced that operator.caller() would be useful to me. Why do you 
consider that it belongs to the stdlib? It is a common pattern? Did you see in 
this pattern in the current stdlib?

Can't you easily implement such helper function in a few lines of Python?

operator documentation says: "The operator module exports a set of efficient 
functions corresponding to the intrinsic operators of Python". I don't see how 
operator.caller() implements an existing "intrinsic operators of Python".

methodcaller() can be implemented in 4 lines of Python, as shown in its 
documentation:
---
def methodcaller(name, /, *args, **kwargs):
def caller(obj):
return getattr(obj, name)(*args, **kwargs)
return caller
---

--
nosy: +brett.cannon, rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44019] operator.call/operator.__call__

2021-08-23 Thread Mark Dickinson


Mark Dickinson  added the comment:

This seems like a reasonable addition to me. Victor: any thoughts?

--
nosy: +mark.dickinson, vstinner

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44019] operator.call/operator.__call__

2021-08-22 Thread Antony Lee


Change by Antony Lee :


--
keywords: +patch
pull_requests: +26342
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/27888

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44019] operator.call/operator.__call__

2021-08-03 Thread Antony Lee


Antony Lee  added the comment:

Actually, upon further thought, the semantics I suggested above should go into 
`operator.caller` (cf. `operator.methodcaller`), and 
`operator.call`/`operator.__call__` should instead be defined as 
`operator.call(f, *args, **kwargs) == f(*args, **kwargs)`, so that the general 
rule `operator.opname(a, b) == a.__opname__(b)` (modulo dunder lookup rules) 
remains applicable.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44019] operator.call/operator.__call__

2021-05-04 Thread Shatabarto Bhattacharya


Change by Shatabarto Bhattacharya :


--
nosy: +hrik2001

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44019] operator.call/operator.__call__

2021-05-03 Thread Antony Lee


New submission from Antony Lee :

Adding a call/__call__ function to the operator module (where 
`operator.call(*args, **kwargs)(func) == func(*args, **kwargs)`, similarly to 
operator.methodcaller) seems consistent with the design with the rest of the 
operator module.

An actual use case I had for such an operator was collecting a bunch of 
callables in a list and wanting to dispatch them to 
concurrent.futures.Executor.map, i.e. something like 
`executor.map(operator.call, funcs)` (to get the parallelized version of 
`[func() for func in funcs]`).

--
components: Library (Lib)
messages: 392809
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: operator.call/operator.__call__
versions: Python 3.11

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com