Thank you to make my question clear.
Actually, I misunderstood property values and its validation.
On 12/11/18 5:12 PM, Daniel Shahaf wrote:
> Generic APIs that work on any property should return bytes. More
> specific APIs that work on properties that have further restrictions
> (svn:needs-lock, svn:date), or even a structured value (svn:externals,
> svn:mergeinfo), may use appropriately more specific data types.
I see. Then I'll try to fix those API wrappers returns propety values
to return as bytes in py3. I think precise restriction check for
properties is not the matter of wrappers, so I don't touch it.
> In general, if an API has an input of type bytes and needs to return
> str, I would have it throw an exception if the conversion fails, so the
> caller is forced to deal with the failure mode explicitly. It'd be fine
> to use surrogateescape or return bytes *if the caller has explicitly
> requested that*, but the default postcondition should be as simple as
> possible: "This function either returns str or raises an exception".
I'm sorry, I meant "Those APIs" as not generic APIs, but "those APIs
return propety values", and I don't want to hide exception if there
are ways not to do so, too. (I've searched the way to add keywords
arguments with default values like charset, errors, or return_type
with make relation to argment for props, but I couldn't)
However, I also think if C API returns value successfuly and the wrapper
fails to return its value "unexpectedly", the wrapper is incomplete.
My interest is "what should care as bytes object and what should
care as str object Python 3 API wrapper". Current typemaps seems
almost all char *, svn_string_t * are mapped to str object in py3.
Thanks,
--
Yasuhito FUTATSUKI
Received on 2018-12-11 11:23:23 CET