Keith Kraus

> @kkraus14 what is not clear to me, is your objection mainly based on the lack of non-cpu device support, or more in general? Assume for a moment that the...

I'm +1 in supporting them

I think we'd want to use the C Device Data Interface as opposed to the C Data Interface in order to support non-CPU memory as well?

I think we should just wait until there's a Python protocol for the C Device Data Interface then instead of plumbing in the C Data Interface. That gives a single...

I haven't been in the discussions lately but drive by commenting since I have some strong opinions about this and was one of the main people voicing concerns about the...

> I'm actually not quite sure how to interpret this bit. Why would these guarantees be needed (if `__arrow_array__` is used by both consumer and producer, it seems like this...

The spec mentions that the format string is used for datetime specification and that it uses the Arrow C Data Interface format string specification, so I'd argue this is well...

I would vote to remove this. This is redundant to `describe_null` on the column level with much more rigid capabilities.

In the case of something like pandas or other dataframe library that doesn't use the Arrow memory layout under the hood, they'd presumably materialize arrow on the `__dataframe__` call and...

Do we expect / want to encourage developers using dataframe libraries to explicitly call `__dataframe__` themselves as opposed to using `libraryx.from_dataframe(...)`? It feels a bit funky to me currently that...