Bug#918206: Pandas
On Wed, 27 Feb 2019, Andreas Tille wrote:
> Dear Rebecca,
> On Wed, Feb 27, 2019 at 07:25:26AM +, Rebecca N. Palmer wrote:
> > On 27/02/2019 07:00, Andreas Tille wrote:
> > > Dear Rebecca,
> > > I do not think that there is any
> > > need for a separate branch. Just stick to the debian branch.
> > It's needed because the debian branch contains the attempt at packaging 0.24
> > described earlier in this thread, which it's now too late for.
> You are right. Considering the branching jungle (Yaroslav, could you possibly
for someone jungle is a sweet sweet home! ;)
$> git br -a | grep salsa | grep -e bf- -e enh- -e cythoned | while
read b; do git push salsa :${b//*salsa\//}; done
To salsa.debian.org:science-team/pandas.git
- [deleted] __tent/debian-cythoned-quilt
To salsa.debian.org:science-team/pandas.git
- [deleted] bf-cython
To salsa.debian.org:science-team/pandas.git
- [deleted] bf-i386
To salsa.debian.org:science-team/pandas.git
- [deleted] bf-native-endianness
To salsa.debian.org:science-team/pandas.git
- [deleted] bf-skips
To salsa.debian.org:science-team/pandas.git
- [deleted] bf-unser
To salsa.debian.org:science-team/pandas.git
- [deleted] bf-versions-etc
To salsa.debian.org:science-team/pandas.git
- [deleted] enh-tests-compat-pytables-2.1
and will try to not forget to not push them again ;)
$> git br -a | grep salsa # -- with my annotations
remotes/salsa/master -- some upstream's point of master -- could
also be removed if you like
remotes/salsa/releases -- linear progression of upstream releases
remotes/salsa/debian -- sits on top of releases and carries
packaging
remotes/salsa/debian-experimental -- the one for uploads to
experimental
better now?
> cleanup branches that are not used any more?) I'd prefer if you would move the
> 0.24 packaging to some separate branch (debian-experimental is covered but may
> be debian-0.24 or something like this?) and keep branch debian for what we are
> really releasing.
well "releasing" is a loaded term. I guess you are talking about uploading to
unstable so it manages to get into buster. Since "debian" branch already got
its 0.24, what about starting debian-buster branch off debian/0.23.3-1 ?
otherwise -- I am ok to hard-reset and force push debian to the debian/0.23.3-1
state -- everyone should just beware of it, and then progress
debian-experimental to current state of debian (v0.24.1-972-g1cfbd07c7)
your call
> Thanks again for your work on this
yeap, Thank you Rebecca!
--
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
Bug#918206: Pandas
Dear Rebecca, On Wed, Feb 27, 2019 at 07:25:26AM +, Rebecca N. Palmer wrote: > On 27/02/2019 07:00, Andreas Tille wrote: > > Dear Rebecca, > > I do not think that there is any > > need for a separate branch. Just stick to the debian branch. > > It's needed because the debian branch contains the attempt at packaging 0.24 > described earlier in this thread, which it's now too late for. You are right. Considering the branching jungle (Yaroslav, could you possibly cleanup branches that are not used any more?) I'd prefer if you would move the 0.24 packaging to some separate branch (debian-experimental is covered but may be debian-0.24 or something like this?) and keep branch debian for what we are really releasing. Thanks again for your work on this Andreas. -- http://fam-tille.de
Bug#918206: Pandas new version (not?)
This builds (including build-time tests; haven't tried the autopkgtest). Description: Fix np.array @ DataFrame matrix multiplication Author: jbrockmendel Origin: upstream https://github.com/pandas-dev/pandas/commit/ad2a14f4bec8a004b2972c12f12ed3e4ce37ff52 Bug-Debian: https://bugs.debian.org/918206 Forwarded: not-needed --- a/pandas/core/generic.py +++ b/pandas/core/generic.py @@ -1602,6 +1602,7 @@ class NDFrame(PandasObject, SelectionMix # -- # Array Interface +__array_priority__ = 1000 def __array__(self, dtype=None): return com._values_from_object(self) --- a/pandas/tests/frame/test_analytics.py +++ b/pandas/tests/frame/test_analytics.py @@ -2283,8 +2283,11 @@ class TestDataFrameAnalytics(TestData): # np.array @ DataFrame result = operator.matmul(a.values, b) +assert isinstance(result, DataFrame) +assert result.columns.equals(b.columns) +assert result.index.equals(pd.Index(range(3))) expected = np.dot(a.values, b.values) -tm.assert_almost_equal(result, expected) +tm.assert_almost_equal(result.values, expected) # nested list @ DataFrame (__rmatmul__) result = operator.matmul(a.values.tolist(), b)
Bug#918206: Pandas new version (not?)
Given the soft freeze, the new upstream version is probably no longer an
option for buster.
Just setting __array_priority__ fails, but with a message that suggests
also including the test_analytics part of that upstream commit would
work; I haven't yet had time to try this.
left = one two
0 -1.365296 1.088132
1 -1.668353 3.025582
2 0.343140 -0.260306
right = array([[-1.36529629, 1.08813166],
[-1.66835336, 3.02558216],
[ 0.34314 , -0.26030576]])
cls =
def _check_isinstance(left, right, cls):
"""
Helper method for our assert_* methods that ensures that
the two objects being compared have the right type before
proceeding with the comparison.
Parameters
--
left : The first object being compared.
right : The second object being compared.
cls : The class type to check against.
Raises
--
AssertionError : Either `left` or `right` is not an instance of
`cls`.
"""
err_msg = "{name} Expected type {exp_type}, found {act_type}
instead"
cls_name = cls.__name__
if not isinstance(left, cls):
raise AssertionError(err_msg.format(name=cls_name,
exp_type=cls,
act_type=type(left)))
if not isinstance(right, cls):
raise AssertionError(err_msg.format(name=cls_name,
exp_type=cls,
> act_type=type(right)))
E AssertionError: DataFrame Expected type 'pandas.core.frame.DataFrame'>, found instead
../debian/tmp/usr/lib/python3/dist-packages/pandas/util/testing.py:296:
AssertionError
Bug#918206: Pandas new version
Control: tags -1 fixed-upstream patch The test failure is that np.array @ pd.DataFrame (matrix product) tries to keep both the DataFrame's indices, which fails because the new matrix is a different shape. This appears to be fixed in 0.24.1 from PyPI, but as previously noted, this is a new major version and hence risks breaking rdeps. The relevant change appears to be setting __array_priority__: https://github.com/brute4s99/pandas/commit/a01fa791eafe704ea85e2acc956ad9077e8e7542#diff-03b380f521c43cf003207b0711bac67f but I haven't actually tried applying only that to 0.23.
Processed: Re: Bug#918206: pandas: autopkgtest fails with python-numpy (1:1.16.0~rc1-3)
Processing control commands: > severity -1 serious Bug #918206 [src:pandas] pandas: autopkgtest fails with python-numpy (1:1.16.0~rc1-3) Severity set to 'serious' from 'normal' > tags -1 + ftbfs Bug #918206 [src:pandas] pandas: autopkgtest fails with python-numpy (1:1.16.0~rc1-3) Added tag(s) ftbfs. -- 918206: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918206 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
