prose will stop being maintained soon, and I'll focus completely on eloy.
Why?
prose introduces too much unnecessary abstractions, which makes it hard to learn, hard to develop, and hard to maintain.
Consider the example of trimming an image:
# with prose
trimmed_image = blocks.Trim(50)(image)
# with just Python...
trimmed_ndarray = ndarray[50:-50, 50:-50]
Even in this trivial case, prose introduces unnecessary abstraction that obscures what’s actually happening. To me, this is not only redundant but also counterproductive — it leads users to treat prose as a black box, which is the opposite of why I developed it. Excessive abstraction also impacts maintainability and testing.
For instance, what if a user wants to trim 50 pixels from the left, 20 from the right, and 10 from the top? Should this require a PR to add another keyword argument to the Trim block along with new tests and a version release?
Difference with eloy
By adhering to a more functional programming paradigm, eloy is far more testable, maintainable, and intuitive than prose (see by yourself by exploring the documentation). Importantly, using it doesn’t necessarily lead to longer scripts.
You might wonder why prose was designed this way in the first place then. The answer is simple: I’m a better Python developer now than I was back then. Using eloy instead of prose helps spread that improvement by fostering autonomy with essential dependencies in Astronomy (most of which users are already familiar with!).
Please reach out!
If one of your project is dependent on prose and you want to make the transition I'd be happy to help, just open an issue!
prose will stop being maintained soon, and I'll focus completely on eloy.
Why?
prose introduces too much unnecessary abstractions, which makes it hard to learn, hard to develop, and hard to maintain.
Consider the example of trimming an image:
Even in this trivial case, prose introduces unnecessary abstraction that obscures what’s actually happening. To me, this is not only redundant but also counterproductive — it leads users to treat prose as a black box, which is the opposite of why I developed it. Excessive abstraction also impacts maintainability and testing.
For instance, what if a user wants to trim 50 pixels from the left, 20 from the right, and 10 from the top? Should this require a PR to add another keyword argument to the
Trimblock along with new tests and a version release?Difference with eloy
By adhering to a more functional programming paradigm, eloy is far more testable, maintainable, and intuitive than prose (see by yourself by exploring the documentation). Importantly, using it doesn’t necessarily lead to longer scripts.
You might wonder why prose was designed this way in the first place then. The answer is simple: I’m a better Python developer now than I was back then. Using eloy instead of prose helps spread that improvement by fostering autonomy with essential dependencies in Astronomy (most of which users are already familiar with!).
Please reach out!
If one of your project is dependent on prose and you want to make the transition I'd be happy to help, just open an issue!