Open davidhewitt opened 2 weeks ago
Makes sense to me!
for me PyString make sense cause it's allocate.
for me PyString make sense cause it's allocate.
I do like this argument tbh; and if we chose to leave PyString
as-is and just update PyLong
-> PyInt
, this argument would be a somewhat reasonable justification (alongside the benefit of avoiding churn).
I also think PyString
is fine as is. PyStr
can also make the impression that is would somehow be coupled to Rust's &str
, which it is not really. Renaming PyLong
to PyInt
sounds reasonable to me, given that long
is neither a thing in Rust or Python, and PyInt
makes is clearer what it refers to.
It sounds like the conclusion here is PyString
will stay as-is (we can deprecate the PyUnicode
alias, I think, though).
On the other hand, we have broad agreement that PyLong
-> PyInt
is desirable.
Just need someone to find a moment implement, in that case 👍
Hi @davidhewitt I would love to do changes for PyLong -> PyInt.
I'm still a beginner in rust & open-source. So, this issue would be a good starting point for me
Please feel free to go for it! I suggest starting with a PR and we can review and help iterate that way.
We currently have
PyString
to represent Pythonstr
, andPyLong
to represent Pythonint
.While
PyString
is reasonably clear,PyLong
is primarily a historical accident based on the fact that Python 2's integers were split betweenint
andlong
types, and so the Python C API is based onPyLongObject
etc.Interestingly, we do currently expose
PyInt
aspyo3::types::PyInt
as an import alias.Similar history applies to
PyString
; we currently have aPyUnicode
type alias kicking around which is again a throwback to Python 2'sstr
andunicode
split (they became approximatelybytes
andstr
respectively in Python 3).I would propose the following:
PyString
toPyStr
, and leavePyString
andPyUnicode
as deprecated type aliases for a couple versions.PyLong
toPyInt
, and leavePyLong
as a deprecated type alias for a couple versions.The only counter-arguments I can see:
PyString
->PyStr
is not worth the churn. I could accept this if people hold this strongly, though I also think such a migration is a straightforward find-and-replace and improves alignment with the Python naming.PyLong
->PyInt
is unappealing because we build uponPyLong_
C APIs. After some consideration I find this a non-argument;PyInt
is a much clearer name in my opinion, and I don't think we would ever considerPyUnicode
as better thanPyStr
orPyString
. So by extension I see no reason to prefer C-API consistency ofPyLong
overPyInt
.Subject to agreement from maintainers that we want to make this change, I think this is a relatively easy change to implement, so tentatively marking as "Good First Issue".