Re: [PATCH]On branch swig-py3: accept both of bytes/str for inputchar * args
On 1/14/19 6:30 PM, Yasuhito FUTATSUKI wrote:
On 1/14/19 3:10 PM, Yasuhito FUTATSUKI wrote:
In article
troycurti...@gmail.com writes:
On Thu, Jan 10, 2019 at 9:50 AM Yasuhito FUTATSUKI
PyBytes: Sequence of byte values, e.g. "raw data"
In Py2: str
In Py3: bytes
PyStr: Character data
In Py2: Unicode
In Py3: str
Unfortunately, PyStr in py3c compatibility layer API is the intersection
of PyString in Python 2, and PyUnicode in Python 3, so we must explicitly
use PyUnicode_* for handling Unicode in py2.
Aha, both of those are partially correct and partially wrong.
PyStr_Check:
In Py2: PyString_Check, accept string and its subtype object.
(not accept unicode object)
In Py3: PyUnicode_Check, accept string and its subtype object.
PyStr_UTF8:
In Py2: PyString_AsString, accept both of bytes(str) and unicode.
In Py3: PyUnicode_AsUTF8, accept str(Unicode object).
and, PyUnicode_Check() is also provided for py2.
So, we can use code fragment like:
...
if (PyBytes_Check(input))
{
retval = PyBytes_AsString(input);
}
else if (PyUnicode_Check(input))
{
retval = (char *)PyStr_AsUTF8(input);
}
else
...
--
Yasuhito FUTATSUKI
[ANNOUNCE] Apache Roadshow Chicago, Call for Presentations
Hello Devs! You're receiving this email because you are subscribed to one or more Apache developer email lists. I’m writing to let you know about an exciting event coming to the Chicago area: The Apache Roadshow Chicago. It will be held May 13th and 14th at three bars in the Logan Square neighborhood (Revolution Brewing, The Native, and the Radler). There will be six tracks: - Apache in Adtech: Tell us how Apache works in your advertising stack - Apache in Fintech: Tell us how Apache works in your finance/insurance business - Apache in Startups: Tell us how you’re using Apache in your startup - Diversity in Apache: How do we increase and encourage diversity in Apache and tech fields overall? - Made in Chicago: Apache related things made by people in Chicago that don’t fall into other buckets - Project Shark Tank: Do you want more developers or users for your Apache project? Come here and pitch it! This is an exciting chance to learn about how Apache Projects are in use in production around Chicago, how business users make the decision to use Apache projects, to learn about exciting new projects that want help from developers like you, and how/why to increase diversity in tech and IT. If you have any use cases of Apache products in Adtech, Fintech, or Startups; if you represent a minority working in tech and have perspectives to share, if you live in the Chicagoland area and want to highlight some work you’ve done on an Apache project, or if you want to get other people excited to come work on your project, then please submit a CFP before the deadline on February 15th! Tickets to the Apache Roadshow Chicago are $100; speakers will get a complimentary ticket. We’re looking forward to reading your submissions and seeing you there on May 13-14! Sincerely, Trevor Grant https://www.apachecon.com/chiroadshow19/cfp.html https://www.apachecon.com/chiroadshow19/register.html
Re: Blame callback: remove start/end parameters
On 15.01.2019 10:49, Bert Huijben wrote: > Not sure if that would be as helpful as the old code and/or can be done > with a compatibility wrapper. The problem is that the output arguments are > available only, long after the blame reporting is done, while with the > current implementation intermediate callbacks can be used more efficiently. > > Perhaps if we document that the output arguments are set before the first > invocation of the callback, but that would be an API-first. Good point. And also we may not be able to guarantee that in general. It doesn't really hurt for the callback to get redundant parameters. It does hurt the API user if they have to play tricks to make sure they update the callback's context (baton) before the callback is invoked. So, on balance ... this is not an improvement. -- Brane > On Tue, Jan 15, 2019 at 1:30 AM Johan Corveleyn wrote: > >> On Mon, Jan 14, 2019 at 4:13 PM Julian Foad wrote: >>> Julian Foad wrote: The svn_client_blame_receiver4_t parameters "start_revnum" and "end_revnum" do not really belong here because they are not per-line data. They are the "resolved" versions of the input revnums to svn_client_blame6(). I introduced them in r955895, applying a patch by Johan. I propose to move them to svn_client_blame6() output parameters. >> Ooh, my very first patch :-). I had no clue what I was doing back >> then, and I still don't most of the time :-). Thanks for improving >> things ... >> >> -- >> Johan >>
Re: Blame callback: remove start/end parameters
Not sure if that would be as helpful as the old code and/or can be done with a compatibility wrapper. The problem is that the output arguments are available only, long after the blame reporting is done, while with the current implementation intermediate callbacks can be used more efficiently. Perhaps if we document that the output arguments are set before the first invocation of the callback, but that would be an API-first. Bert On Tue, Jan 15, 2019 at 1:30 AM Johan Corveleyn wrote: > On Mon, Jan 14, 2019 at 4:13 PM Julian Foad wrote: > > > > Julian Foad wrote: > > > The svn_client_blame_receiver4_t parameters "start_revnum" and > > > "end_revnum" do not really belong here because they are not per-line > > > data. They are the "resolved" versions of the input revnums to > > > svn_client_blame6(). I introduced them in r955895, applying a patch by > > > Johan. I propose to move them to svn_client_blame6() output parameters. > > Ooh, my very first patch :-). I had no clue what I was doing back > then, and I still don't most of the time :-). Thanks for improving > things ... > > -- > Johan >
