On Wed, Aug 31, 2022, 12:24 AM Wes Turner wrote:
> +0.1
>
>
>
>
> On Tue, Aug 30, 2022, 11:15 PM Charles Machalow
> wrote:
>
>
>
>> ```
>> and for the simple test, added this to the partial definition:
>>
>> ```
>> @property
>> def __name__(self):
>> return
+0.1
On Tue, Aug 30, 2022, 11:15 PM Charles Machalow wrote:
> ```
> and for the simple test, added this to the partial definition:
>
> ```
> @property
> def __name__(self):
> return f"partial({self.func.__name__})"
> ```
> Of course it probably wouldn't be too bad to add in
I'd likely propose doing both as properties so that we don't need to hold
onto either of them... I was trying this out when I hit:
```
C:\Users\csm10495\Desktop\cpython\Scripts>ipython
Could not import runpy module
Traceback (most recent call last):
File "", line 1172, in _find_and_load
File
Actually, there is a good motive IMO for a partial function to have
__name__ and __qualname__: the code one is passing a partial function
might expect these attributes to be presented in the callable it get.
It is just a matter of unifying the interface for callables that are often
used as
Would a property or a copy be faster for existing and possible use cases?
In practice, how frequently will __qual/name__ be called on partials?
- Copying __qual/name__ would definitely be a performance regression
- There are probably as many use cases for partials as other methods of
functional
We may be able to do __name__/__qualname__ as a property to make it
evaluate when called as opposed to computed once on creation. That way we
just work with .func upon call so no need for extra references, etc.
As for documentation generation tools, it may be different at first, though
I believe
Is there a non-performance regressive way to proxy attr access to
func.__name__ of the partial function (or method; Callable)?
Would this affect documentation generation tools like e.g. sphinx-spidoc,
which IIRC use __name__ and probably now __qualname__ for generating
argspecs in RST for HTML
