It may be relevant at this point to mention that the padding bytes do *not*
get copied - so you get a blob with possibly quite a lot of uninitialized
data. If anything, that seems a recipe for unexpected results. Are there
non-contrived examples where you would *want* this uninitialized blob?
Hello all,
padding bytes can be relevant (for example hidden data). Why not add a new
argument that the user can use to remove padding bytes?
On Fri, Apr 12, 2019, 20:01 Stefan van der Walt
wrote:
> On Fri, 12 Apr 2019 12:13:18 -0400, Allan Haldane wrote:
> > I would be much more in favor of
On Fri, 12 Apr 2019 12:13:18 -0400, Allan Haldane wrote:
> I would be much more in favor of `copy` eliminating padding in the
> dtype, if dtypes with different paddings were considered equivalent.
> But they are not.
This, and the simplicity arguments, are fair points. Option (1) seems
like the
I would be much more in favor of `copy` eliminating padding in the
dtype, if dtypes with different paddings were considered equivalent.
But they are not.
Numpy has always treated dtypes with different padding bytes as
not-equal, and prints them very differently:
>>> a = np.array([1],
I recently put some thought on the issue because a user was complaining
about PyTables unadvertendly removing the padding while doing a copy.
Incidentally, h5py also do respect padding while doing copies, so I took
this seriously and released a new PyTables version mainly for fixing this.
You can
