Michael Lamparski

Unclear what Config::build() returns

4

The output of this function is confusing and undocumented. Based on the code samples in ~~README.md~~ `lib.rs`, it would appear to be the directory where libs were installed. However, printing...

mapping a zipped iterator to produce tuples

5

I have a function which looks vaguely like this: ```rust struct Rect { real: f64, imag: f64 } struct KetRef KetRef

How to handle resume types with lifetimes

3

Just something I've run into and have been thinking about. I'm not precisely sure how much it would impact the API (probably too much!), and what the advantages and disadvantages...

Arrays with ndim != 1

4

Is there any particular reason why is the current implementation restricted to 1-dimensional arrays? In particular, right now I want to use this crate to read a `bsr_matrix` saved by...

Support one rust type serializing as many dtypes

12

#### This is now ready for review! I have chosen to finally submit a PR now that `cargo test --all` succeeds, and the behavior of all of the existing examples...

This is a small thing I need for some of the unit tests I'm adding to #15. In order to be backwards compatible, `OutFile` becomes a type alias for a...

```rust use npy::NpyData; use npy::Serializable; #[derive(npy_derive::Serializable)] #[derive(Debug, PartialEq)] struct Array23 { field: [[i32; 3]; 2], } fn main() { println!("{}", ::dtype().descr()); } ``` ``` [('field', '

The name `open` is confusing and suggests that the file must already exist (or that any existing data is somehow retained). `create` is consistent with `std::fs::File::create`.

`DType::from_descr` is public, but `Value` is not exposed at any public path (nor are any public functions that can construct one).

Supporting 1 rust type <-> many npy types

1

There are many datatypes which can appear in NPY files which currently cannot be supported by the design of the `Serialize` trait. To name a few: * Anything that's big-endian....