BLD: fix build warnings

[jbrockmendel]

xref #25995, #17936

AFAICT these warnings are caused by cython casting len(some_ndarray) to int or Py_ssize_t but casting len(some_memoryview) to size_t. Easiest fix is to declare the affected len variables as size_t since we know they'll never be negative.

[codecov]

Codecov Report

Merging #26757 into master will decrease coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master   #26757      +/-   ##
==========================================
- Coverage   91.71%    91.7%   -0.01%     
==========================================
  Files         178      178              
  Lines       50740    50740              
==========================================
- Hits        46538    46533       -5     
- Misses       4202     4207       +5

Flag	Coverage Δ
#multiple	90.3% <ø> (ø)	⬆️
#single	41.21% <ø> (-0.11%)	⬇️

Impacted Files	Coverage Δ
pandas/io/gbq.py	78.94% <0%> (-10.53%)	⬇️
pandas/core/frame.py	96.88% <0%> (-0.12%)	⬇️
pandas/util/testing.py	90.84% <0%> (-0.11%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0f3e8e8...8ac7bb9. Read the comment docs.

[codecov]

Codecov Report

Merging #26757 into master will increase coverage by 1.4%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           master   #26757     +/-   ##
=========================================
+ Coverage   90.35%   91.76%   +1.4%     
=========================================
  Files         178      178             
  Lines       50753    50753             
=========================================
+ Hits        45859    46571    +712     
+ Misses       4894     4182    -712

Flag	Coverage Δ
#multiple	90.35% <ø> (ø)	⬆️
#single	41.04% <ø> (?)

Impacted Files	Coverage Δ
pandas/core/arrays/categorical.py	95.92% <0%> (+0.12%)	⬆️
pandas/core/indexes/datetimes.py	96.37% <0%> (+0.16%)	⬆️
pandas/io/formats/printing.py	85.56% <0%> (+1.06%)	⬆️
pandas/io/clipboard/clipboards.py	34.78% <0%> (+2.89%)	⬆️
pandas/core/computation/expr.py	97.8% <0%> (+3.02%)	⬆️
pandas/core/computation/common.py	89.47% <0%> (+5.26%)	⬆️
pandas/io/pytables.py	90.29% <0%> (+26.47%)	⬆️
pandas/core/computation/pytables.py	90.24% <0%> (+27.74%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 646ff0b...5228964. Read the comment docs.

[WillAyd]

Hmm understood that these would never be negative but since Py_ssize_t is what Python would use for indexing that still seems like the more natural data type to use. Is there not a way to silence these warnings while still using that type for indexers?

[jbrockmendel]

@scoder any thoughts on whether this is worthwhile and if not, how to silence the warnings?

[scoder]

size_t, or, more generally, unsigned integer types in C, have their advantages and disadvantages. Special use cases like bit manipulation aside, it's nice that they explicitly state that their value cannot be lower than zero. On the downside, they mix badly with C's default (signed) integer behaviour and signed arithmetic in general, and fail to support Python's negative indexing.

I think Py_ssize_t is the most obvious return type for len(), and memory views shouldn't diverge from this. This is something we can change in Cython 3.0. If you have an opinion, please discuss it at
cython/cython#2992

As for a work-around for now, it's probably best to explicitly cast the return values to Py_ssize_t, at least where it's not used in an unsigned context anyway.

[jreback]

we are consistently using Py_ssize_t, adding in size_t is confusing.

[jbrockmendel]

Updated to use Py_ssize_t consistently

[jreback]

import comment, otherwise lgtm. ping on green.

[jreback]

lgtm. merge on green (and close the issues above if this & others cover)

[jbrockmendel]

and close the issues above if this & others cover

There's still a bunch in interval.pyx that I'm not sure are purely cosmetic (cc @jschendel)

[jreback]

thanks @jbrockmendel