[Cython] PyUnicode_Tailmatch

[Josh Ayers]

Cython devs,

In the function __Pyx_PyUnicode_Tailmatch, the return type of
PyUnicode_Tailmatch is assumed to be in int.  See line 543 of
Cython/Utility/StringTools.c.  

PyUnicode_Tailmatch actually returns a Py_ssize_t.  See:
https://docs.python.org/3/c-api/unicode.html#c.PyUnicode_Tailmatch.

For reference, there was previously an error in the Python documentation
of this function.  The documentation mistakenly said it returned an int.
 This was fixed via Python issue 22580:
https://bugs.python.org/issue22580.

Thanks,
Josh Ayers
___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel

Re: [Cython] PyUnicode_Tailmatch

[Robert Bradshaw]

Fixed (though I'm inclined to agree with the assessment that this
choice of return type was a bug in the first place).

https://github.com/cython/cython/commit/0a5890216d29d7bce941c9ab5cb0cb818eed643d

On Tue, Jul 7, 2015 at 8:11 AM, Josh Ayers  wrote:
> Cython devs,
>
> In the function __Pyx_PyUnicode_Tailmatch, the return type of
> PyUnicode_Tailmatch is assumed to be in int.  See line 543 of
> Cython/Utility/StringTools.c.
>
> PyUnicode_Tailmatch actually returns a Py_ssize_t.  See:
> https://docs.python.org/3/c-api/unicode.html#c.PyUnicode_Tailmatch.
>
> For reference, there was previously an error in the Python documentation
> of this function.  The documentation mistakenly said it returned an int.
>  This was fixed via Python issue 22580:
> https://bugs.python.org/issue22580.
>
> Thanks,
> Josh Ayers
> ___
> cython-devel mailing list
> cython-devel@python.org
> https://mail.python.org/mailman/listinfo/cython-devel
___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel

Re: [Cython] PyUnicode_Tailmatch

[Stefan Behnel]

Robert Bradshaw schrieb am 07.07.2015 um 19:05:
> On Tue, Jul 7, 2015 at 8:11 AM, Josh Ayers wrote:
>> In the function __Pyx_PyUnicode_Tailmatch, the return type of
>> PyUnicode_Tailmatch is assumed to be in int.  See line 543 of
>> Cython/Utility/StringTools.c.
>>
>> PyUnicode_Tailmatch actually returns a Py_ssize_t.  See:
>> https://docs.python.org/3/c-api/unicode.html#c.PyUnicode_Tailmatch.
>>
>> For reference, there was previously an error in the Python documentation
>> of this function.  The documentation mistakenly said it returned an int.
>>  This was fixed via Python issue 22580:
>> https://bugs.python.org/issue22580.
>
> Fixed (though I'm inclined to agree with the assessment that this
> choice of return type was a bug in the first place).
> 
> https://github.com/cython/cython/commit/0a5890216d29d7bce941c9ab5cb0cb818eed643d

That's not a complete fix, though, because it would also be necessary to
widen the types wherever these functions are called. I therefore prefer an
explicit and local downcast to "int" over letting this API quirk spread.

https://github.com/cython/cython/commit/9962ade0f048dac953b974ff9dddf087ed2b8fab

Stefan

___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel

Re: [Cython] PyUnicode_Tailmatch

[Robert Bradshaw]

On Tue, Jul 7, 2015 at 12:07 PM, Stefan Behnel  wrote:
> Robert Bradshaw schrieb am 07.07.2015 um 19:05:
>> On Tue, Jul 7, 2015 at 8:11 AM, Josh Ayers wrote:
>>> In the function __Pyx_PyUnicode_Tailmatch, the return type of
>>> PyUnicode_Tailmatch is assumed to be in int.  See line 543 of
>>> Cython/Utility/StringTools.c.
>>>
>>> PyUnicode_Tailmatch actually returns a Py_ssize_t.  See:
>>> https://docs.python.org/3/c-api/unicode.html#c.PyUnicode_Tailmatch.
>>>
>>> For reference, there was previously an error in the Python documentation
>>> of this function.  The documentation mistakenly said it returned an int.
>>>  This was fixed via Python issue 22580:
>>> https://bugs.python.org/issue22580.
>>
>> Fixed (though I'm inclined to agree with the assessment that this
>> choice of return type was a bug in the first place).
>>
>> https://github.com/cython/cython/commit/0a5890216d29d7bce941c9ab5cb0cb818eed643d
>
> That's not a complete fix, though, because it would also be necessary to
> widen the types wherever these functions are called. I therefore prefer an
> explicit and local downcast to "int" over letting this API quirk spread.
>
> https://github.com/cython/cython/commit/9962ade0f048dac953b974ff9dddf087ed2b8fab

I did look at the callsites--they were all conversion to a boolean or
the implementation of an explicit call to PyUnicode_Tailmatch in user
code.

- Robert
___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel

Re: [Cython] Multidimensional indexing of C++ objects

[Ian Henriksen]

On Sat, Jul 4, 2015 at 12:43 AM Stefan Behnel  wrote:

> Hi Ian!
>
> Ian Henriksen schrieb am 04.07.2015 um 00:43:
> > I'm a GSOC student working to make a Cython API for DyND. DyND
> >  is a relatively new n-dimensional
> > array library in C++ that is based on NumPy. A full set of Python
> bindings
> > (created using Cython) are provided as a separate package. The goal of my
> > project is to make it so that DyND arrays can be used easily within
> Cython
> > so that an n-dimensional array object can be used without any of the
> > corresponding Python overhead.
> >
> > Currently, there isn't a good way to assign to multidimensional slices
> > within Cython. Since the indexing operator in C++ is limited to a single
> > argument, we use the call operator to represent multidimensional
> indexing,
> > and then use a proxy class to perform assignment to a slice.
> > Currently, in C++, assigning to a slice along the second axis of a DyND
> > array looks like this:
> >
> > a(irange(), 1).vals() = 0;
> >
> > Unfortunately, in Cython, only the index operator can be used for
> > assignment, so following the C++ syntax isn't currently possible. Does
> > anyone know of a good way to address this?
>
> Just an idea, don't know how feasible this is, but we could allow inline
> special methods in C++ class declarations that implement Python protocols.
> Example:
>
> cdef extern from ...:
> cppclass Array2D:
>int operator[] except +
>int getItemAt(ssize_t x, ssize_t y) except +
>
>cdef inline __getitem__(self, Py_ssize_t x, Py_ssize_t y):
>return self.getItemAt(x, y)
>
> def test():
> cdef Array2D a
> return a[1, 2]
>
> Cython could then translate an item access on an Array2D instance into the
> corresponding special "method" call.
>
> Drawbacks:
>
> 1) The example above would conflict with the C++ [] operator, so it would
> be ambiguous which one is being used in Cython code. Not sure if there's a
> use case for making both available to Cython code, but that would be
> difficult to achieve if the need arises.
>
> 2) It doesn't solve the general problem of assigning to C++ expressions,
> especially because it does not extend the syntax allowed by Cython which
> would still limit what you can do in these fake special methods.
>
> Regarding your proposals, I'd be happy if we could avoid adding syntax
> support for assigning to function calls. And I agree that the cname
> assignment hack is really just a big hack. It shouldn't be relied on.
>
> Stefan
>
> ___
> cython-devel mailing list
> cython-devel@python.org
> https://mail.python.org/mailman/listinfo/cython-devel


Yes, both this idea and the modified version that redefines operator[] are
similar to the idea I had about respecting the cname entries for
operator[]. This method would certainly expose a more flexible API for
modules that want to do this. It may work in my case, but I worry that
getting this into Cython would further complicate the (already lengthy)
indexing logic. I'm still uneasy about exporting an API that is
fundamentally different from the existing Python and C++ APIs, but making a
way to use Python's syntax could help with that. Is there a good way to
make a method like this accept Python-like indexing syntax? It would be
confusing to put a code definition like this inside an extern block too.
Could this syntax be adapted to work outside the extern block while still
showing its connection to the original cppclass?

Thanks for looking at it!
-Ian
___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel