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...@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
