Summary
DataSynthesizer/datatypes/DateTimeAttribute.py calls Series.astype(..., copy=False),
which is deprecated in pandas 3.0:
| File |
Line |
DataSynthesizer/datatypes/DateTimeAttribute.py |
78 return encoded.astype(int, copy=False) |
encoded is a pandas Series (self.data.map(...) / self.timestamps.map(...) +
concat(...)). Verified on pandas 3.0.5:
>>> s.astype(int, copy=False)
Pandas4Warning: The copy keyword is deprecated and will be removed in a
future version. Copy-on-Write is active in pandas since 3.0 which utilizes
a lazy copy mechanism that defers copies until necessary. Use .copy() to
make an eager copy if necessary.
Pandas4Warning is a DeprecationWarning subclass, so it is invisible
by default and does not fail CI — but it fires on every
encode_values_into_bin_idx() call under pandas ≥3.0, and the keyword
will be removed in a future version.
Suggested fix: version-guarded branch
Guard the call on the pandas version — keep copy=False on pandas <3.0
(where it is still meaningful: it avoids an extra copy when the dtype is
unchanged) and drop it on ≥3.0, following the pattern used in
NVIDIA/cuml#8142:
if PANDAS_VERSION < Version("3.0"):
return encoded.astype(int, copy=False)
else:
return encoded.astype(int)
with PANDAS_VERSION = Version(pd.__version__) at module level
(packaging is already a transitive dependency of pandas).
This is behaviour-preserving on every pandas version: the copy
keyword never affects the result of astype, only whether an extra
copy is made, and the branch keeps that behaviour exactly as it was on
each side of the boundary. Verified with runtime checks on pandas 2.3.3
and 3.0.5 (Series → fillna → branch):
- pandas 2.3.3 takes the
copy=False branch, results identical.
- pandas 3.0.5 takes the plain branch: no
Pandas4Warning is emitted,
results identical (the copy keyword is a documented no-op under
Copy-on-Write).
Installation does not bound pandas
setup.py declares pandas>=1.0.5 with no upper bound, so a fresh
pip install DataSynthesizer on current PyPI resolves pandas 3.x and the
warning fires whenever encode_values_into_bin_idx is used.
Specifications
- DataSynthesizer version: 0.1.13
- Python version: n/a (library code)
- Operating System: n/a
Description
See Summary and Suggested fix above.
What I Did
Install with a current pandas 3.x resolution and call encode_values_into_bin_idx on a datetime attribute:
Pandas4Warning: The copy keyword is deprecated and will be removed in a future version.
Summary
DataSynthesizer/datatypes/DateTimeAttribute.pycallsSeries.astype(..., copy=False),which is deprecated in pandas 3.0:
DataSynthesizer/datatypes/DateTimeAttribute.pyreturn encoded.astype(int, copy=False)encodedis a pandasSeries(self.data.map(...)/self.timestamps.map(...)+concat(...)). Verified on pandas 3.0.5:Pandas4Warningis aDeprecationWarningsubclass, so it is invisibleby default and does not fail CI — but it fires on every
encode_values_into_bin_idx()call under pandas ≥3.0, and the keywordwill be removed in a future version.
Suggested fix: version-guarded branch
Guard the call on the pandas version — keep
copy=Falseon pandas <3.0(where it is still meaningful: it avoids an extra copy when the dtype is
unchanged) and drop it on ≥3.0, following the pattern used in
NVIDIA/cuml#8142:
with
PANDAS_VERSION = Version(pd.__version__)at module level(
packagingis already a transitive dependency of pandas).This is behaviour-preserving on every pandas version: the
copykeyword never affects the result of
astype, only whether an extracopy is made, and the branch keeps that behaviour exactly as it was on
each side of the boundary. Verified with runtime checks on pandas 2.3.3
and 3.0.5 (Series →
fillna→ branch):copy=Falsebranch, results identical.Pandas4Warningis emitted,results identical (the
copykeyword is a documented no-op underCopy-on-Write).
Installation does not bound pandas
setup.pydeclarespandas>=1.0.5with no upper bound, so a freshpip install DataSynthesizeron current PyPI resolves pandas 3.x and thewarning fires whenever
encode_values_into_bin_idxis used.Specifications
Description
See Summary and Suggested fix above.
What I Did
Install with a current pandas 3.x resolution and call
encode_values_into_bin_idxon a datetime attribute: