Le 06/10/2023 à 17:54, Felipe Oliveira Carvalho a écrit :
Hello,
Since existing C Data Interface integrations sometimes don't parse beyond
the first `l` (or `L`) I'm going to start a new [VOTE] thread with Dewey's
suggestion:
Regardless of which format string we choose for ListView, a bug s
Hello,
Since existing C Data Interface integrations sometimes don't parse beyond
the first `l` (or `L`) I'm going to start a new [VOTE] thread with Dewey's
suggestion:
+vl and +vL
If anyone objects to that and has a different suggestion, reply here so I
don't have to spam the list with too many
I won't belabour the point any more, but the difference in layout
between a list and a list view is consequential enough to deserve its
own top-level character in my opinion. My vote would be +1 for +vl and
+vL.
On Thu, Oct 5, 2023 at 6:40 PM Felipe Oliveira Carvalho
wrote:
>
> > Union format str
> Union format strings share enough properties that having them in the
> same switch case doesn't result in additional complexity...lists and
> list views are completely different types (for the purposes of parsing
> the format string).
Dense and sparse union differ a bit more than list and list-v
I don't think the parsing will be a problem even in C. It's not like you
have to backtrack anyway.
+1 from me on Felipe's proposal.
Regards
Antoine.
Le 05/10/2023 à 20:33, Felipe Oliveira Carvalho a écrit :
This mailing list thread is going to be the discussion.
The union types also use
+vl and +vL sound good to me!
On Thu, Oct 5, 2023 at 5:06 PM Ben Harkins wrote:
>
> Not sure how consequential it'd be in practice, but my first thought is
> that "+vl" and "+vL" (or "+v"/"+V") would require fewer logic changes and
> extra checks for parsers. Plus, establishing a v-prefixed conve
Not sure how consequential it'd be in practice, but my first thought is
that "+vl" and "+vL" (or "+v"/"+V") would require fewer logic changes and
extra checks for parsers. Plus, establishing a v-prefixed convention for
views would avoid those downsides for plain binary types when BinaryView
and Utf
Makes sense.
The only obstacle to +v is: what do we choose for string views and binary
views? They are not nested, so the + prefix of list-view (as it’s nested)
would differentiate them, but is that OK?
—
Felipe
On Thu, 5 Oct 2023 at 16:33 Dewey Dunnington
wrote:
> Union format strings share e
Union format strings share enough properties that having them in the
same switch case doesn't result in additional complexity...lists and
list views are completely different types (for the purposes of parsing
the format string). Is there any reason *not* to use +v and +V? The
switch statements used
This mailing list thread is going to be the discussion.
The union types also use two characters, so I didn’t think it would be a
problem.
—
Felipe
On Thu, 5 Oct 2023 at 15:26 Dewey Dunnington
wrote:
> I'm sorry for missing earlier discussion on this or a PR into the
> format where this discuss
I'm sorry for missing earlier discussion on this or a PR into the
format where this discussion may have occurred...is there a reason
that +lv and +Lv were chosen over a single-character version (i.e.,
maybe +v and +V)? A single-character version is (slightly) easier to
parse in C.
On Thu, Oct 5, 2
Hello,
I'm writing to propose "+lv" and "+Lv" as format strings for list-view and
large list-view arrays passing through the Arrow C data interface [1].
The vote will be open for at least 72 hours.
[ ] +1 - I'm in favor of this new C Data Format string
[ ] +0
[ ] -1 - I'm against adding this new
12 matches
Mail list logo
