I forgot that there's also Ray:
https://github.com/ray-project/ray
Ray uses Apache Arrow (and Plasma) under the hood. It seems Plasma was
originally developed by Ray team.
Don't know how they solve the GC problem. Maybe they disable it.
___
Maybe get-type-hints can be refactored to make writing such a function
simpler. IIRC the part that takes a single annotation and evaluates it is a
private function.
On Tue, Aug 4, 2020 at 12:57 David Mertz wrote:
> This definitely feels to me like though if an oddball case that "write
> your
This definitely feels to me like though if an oddball case that "write your
own function" seems like the best solution. I accept the OP needs it, but I
have trouble imagining that many others would.
On Tue, Aug 4, 2020, 7:42 AM Dominik Vilsmeier
wrote:
> In one of my projects I'm reusing
When one needs a custom property, the easy, readable, and that already
works way to create then
is just to create an instance of the their class and assign the instance to
the desired
class attribute. All the class have to do is to have the methods that
identify it as a descriptor: "__get__" and
On Tue, Aug 4, 2020 at 8:17 AM Ricky Teachey wrote:
> The following comment is from the thread about adding kwd arg support to
> the square bracket operator (eg, `Vec = Dict[i=float, j=float]`).
>
> On Tue, Aug 4, 2020, 2:57 AM Greg Ewing
> wrote:
>
> On 4/08/20 1:16 pm, Steven D'Aprano wrote:
Thank you all for your posts. I'm busy now and for the next few days, so
have little time to respond. Here's some comments and suggestions.
I hope that Andras, Caleb, Stefano, Neil, Joao Bueno, Todd and Stephan will
take a special interest in this post. In the previous thread, these people
saw
The following comment is from the thread about adding kwd arg support to
the square bracket operator (eg, `Vec = Dict[i=float, j=float]`).
On Tue, Aug 4, 2020, 2:57 AM Greg Ewing wrote:
On 4/08/20 1:16 pm, Steven D'Aprano wrote:
> Why would we want to even consider a new approach to handling
The primary issue I was trying to find a way to reliably and clearly avoid
conflicts between the index labels and the positional argument names. So
if you have:
__getitem__(self, index, **kwargs)
You can't have an index label named "index", because it conflicts with the
"index" positional
In one of my projects I'm reusing class-level type annotations to identify
relevant attributes for serialization, e.g. similar to the following:
attrs = {name: getattr(obj, name) for name in get_type_hints(type(obj))}
This is convenient because it merges the type annotations from the
On Tue, Aug 4, 2020 at 6:09 PM wrote:
>
> Hi all,
>
> Seems like this topic was previously raised, but what if we add possibility
> to decorate non function properties in class:
>
> ```python
> class Neuron:
> @linear_activation
> activation
> ```
What would that decoration do, exactly?
Hi all,
Seems like this topic was previously raised, but what if we add possibility to
decorate non function properties in class:
```python
class Neuron:
@linear_activation
activation
```
___
Python-ideas mailing list --
On 4/08/20 1:16 pm, Steven D'Aprano wrote:
Why would we want to even consider a new approach to handling keyword
arguments which applies only to three dunder methods, `__getitem__`,
`__setitem__` and `__delitem__`, instead of handling keyword arguments
in the same way that every other method
On 4/08/20 6:35 pm, Greg Ewing wrote:
Has anyone suggested attaching the keyword args as attributes
on the slice object?
Realised after sending that this idea is rubbish, because
there can be more than one slice object.
--
Greg
___
Python-ideas
On 4/08/20 9:20 am, Todd wrote:
Another approach could be too simply pass the labelled indices in a dict
as a third/fourth positional argument.
Has anyone suggested attaching the keyword args as attributes
on the slice object?
This would avoid changing the signature of __getitem__, and
14 matches
Mail list logo
