Open danielballan opened 9 years ago
And if we dropped 2 support it would have no dependencies!
I am :+1: and would willing to be a co-owner.
Yes to both! Not sure what I bring to this except a shared enthusiasm for this pattern. Started wondering ~5 years ago why this wasn't in the standard library.
Nathan
On Jul 12, 2015, at 2:09 PM, Dan Allan notifications@github.com<mailto:notifications@github.com> wrote:
@nkeimhttps://github.com/nkeim @caspervdwhttps://github.com/caspervdw @tacaswellhttps://github.com/tacaswell:
I'm at SciPy 2015 working next to @stefanvhttps://github.com/stefanv. He would like me to refactor scikit-image's ImageCollection to behave like pims objects, backed by SliceableIterable. After some discussion with @JDWarnerhttps://github.com/JDWarner, we concluded that the best way to start is to make a very light standalone package that both pims and scikit-image can depend upon, in the pattern of cyclerhttps://github.com/matplotlib/cycler, historyhttps://github.com/Nikea/history, and other simple utilities. This seems better than copying code and maintaining it in two places.
To be clear, I think pims has a good niche as a user-facing package, and this is not necessarily a step toward pushing pims wholly into scikit-image. It spreads the pims-like interface as a common pattern in the scipy stack.
While this would technically add a new dependency to pims, it wouldn't be a user-facing one: the user would not normally import it, and there will be never installation issues because sliceable_iterable depends only on core Python and six.
Questions:
— Reply to this email directly or view it on GitHubhttps://github.com/soft-matter/pims/issues/162.
Seems to me as a good direction! I am also willing to monitor the new repo.
What about the name, is sliceable_iterable
the definite one? I always found it a bit long and difficult to read.
LazyList
On Jul 13, 2015, at 12:55 AM, Casper van der Wel notifications@github.com<mailto:notifications@github.com> wrote:
Seems to me as a good direction! I am also willing to monitor the new repo.
What about the name, is sliceable_iterable the definite one? I always found it a bit long and difficult to read.
Reply to this email directly or view it on GitHubhttps://github.com/soft-matter/pims/issues/162#issuecomment-120841833.
Reslicable
Sliceable + Iterator --> Slicerator
I like Slicerator. OK with everyone else?
P.S. LazyList is nice and simple, but in a way it's problematic because we don't support the list interface (e.g., .extend
) like this package of the same name does.
Ha! I was starting to like Slicerator better anyway.
On Jul 14, 2015, at 8:12 AM, Dan Allan notifications@github.com<mailto:notifications@github.com> wrote:
I like Slicerator. OK with everyone else?
P.S. LazyList is nice and simple, but in a way it's problematic because we don't support the list interface (e.g., .extend) like this package of the same namehttps://github.com/ryanhaining/lazylist does.
Reply to this email directly or view it on GitHubhttps://github.com/soft-matter/pims/issues/162#issuecomment-121276913.
:+1: for Slicerator!
Slicerator gets my vote! As I was the one to ask for multiple owners, I'd be happy to share that responsibility. On Jul 14, 2015 1:59 PM, "Casper van der Wel" notifications@github.com wrote:
[image: :+1:] for Slicerator!
— Reply to this email directly or view it on GitHub https://github.com/soft-matter/pims/issues/162#issuecomment-121342638.
Thanks for pushing this forward!
Slicerator is live! See https://github.com/soft-matter/slicerator. It's on PyPI, and a conda package is on soft-matter's binstar channel.
There's a decent README but it could do with more examples. I tagged 0.9.x; I aim to tag 1.0 right before we merge a refactored ImageCollection
into scikit-image. This leaves us some room to rethink things until then.
@nkeim @caspervdw @tacaswell:
I'm at SciPy 2015 working next to @stefanv. He would like me to refactor scikit-image's
ImageCollection
to behave like pims objects, backed bySliceableIterable
. After some discussion with @JDWarner, we concluded that the best way to start is to make a very light standalone package that both pims and scikit-image can depend upon, in the pattern of cycler, history, and other simple utilities. This seems better than copying code and maintaining it in two places.To be clear, I think pims has a good niche as a user-facing package, and this is not necessarily a step toward pushing pims wholly into scikit-image. It spreads the pims-like interface as a common pattern in the scipy stack.
While this would technically add a new dependency to pims, it wouldn't be a user-facing one: the user would not normally import it, and there will be never installation issues because
sliceable_iterable
depends only on core Python andsix
.Questions:
sliceable_iterable
repo? It is important to scikit-image that there be a couple people with permissions to the repo and PyPI.