Yasuhito FUTATSUKI wrote on Mon, Dec 17, 2018 at 05:50:03 +0900:
> On 12/17/18 2:08 AM, Troy Curtis Jr wrote:
> > On Sun, Dec 16, 2018 at 11:28 AM Daniel Shahaf <d.s_at_daniel.shahaf.name>
> > wrote:
> >
> > > Troy Curtis Jr wrote on Sun, 16 Dec 2018 09:59 -0500:
> > > > But there was one item I wanted to talk about related to the patch. I
> > > > agree that "svn_stringbuf_t" => "bytes" and "svn_string_t" => "str" is the
> > > > right general path,
Would svn_stringbuf_t map better to bytearray? Sorry, that didn't occur
to me yesterday.
> > > Are you sure about this? Property values can be binary data (so not
> > > representable as 'str') but are usually represented by «svn_string_t *»;
> > > for example, svn_repos_parse_fns3_t::set_node_property().
> > >
> >
> > Ah yes, I suppose this also has bearing on the discussion in the other
> > thread relating
> > to returning property values. With that in mind, perhaps your suggestion
> > of effectively
> > defaulting to always being Bytes for char * , svn_string_t, and
> > svn_stringbuf_t unless there
> > is a specific circumstance not to makes the most sense as the general
> > principle.
>
> To treat all those values as bytes in wrapper makes the wrapper is lower
> level, keeping raw access like device drivers. On the other hand,
> to make contexts, to make semantic differences in wrapper makes it more
> higher level. So I think those are not the general principle but just a
> policy of the wrapper design.
In general, you're right. The swig bindings are not Pythonic; to use
them requires using C idioms while writing Python. There's certainly
room for higher-level abstractions — I think the javahl and
python-ctypes bindings are examples — but the trade-off is that they
can't be autogenerated like the swig bindings can.
However, all that aside, I think this general discussion doesn't apply
here. The value of the svn_string_t* parameter of svn_repos_parse_fns3_t::set_node_property()
may be *unrepresentable* as a py3 str object. It isn't a question of
C-like idiom versus a Pythonic idiom; the bytes class can can represent
all possible values, the str class cannot.
Consider «svn propset -F /bin/sh foo iota». How would you represent
that value as str?
> I, as a consumer of the Python bindings, prefer the latter if it is
> clear that what are bytes and what are str, however I also agree with
> former if the distinction is too complex for both of consumers and
> developers.
Cheers,
Daniel
Received on 2018-12-17 10:35:26 CET