On Mon, 3 Aug 2020 at 21:15, Aaron Meurer <[email protected]> wrote: > > - We have already done some degree of high-level planning in the past. > It just hasn't been organized. For example, you can see there are some > documents on the wiki that go over design ideas for various things. > Some of them are implemented and some not.
I took a look through the wiki and there are many different pages but I don't see any that looks like a well specified design that has been reviewed and agreed on. Since you mentioned the new assumptions (below) I see that the new assumptions are one of the more discussed topics having three separate pages: https://github.com/sympy/sympy/wiki/_pages https://github.com/sympy/sympy/wiki/Assumptions https://github.com/sympy/sympy/wiki/Assumptions-Handlers https://github.com/sympy/sympy/wiki/Assumptions-history Mostly though the pages on the wiki look like collections of first-draft notes each written by a single author, reviewed by no one and then never updated again. Those can be useful in many situations but they're really not the kind of thing I'm thinking about. > And of course, every GSoC > project starts with a GSoC proposal that outlines what will be done in > the project. There are also lots of GSOC proposals on the wiki but those are also different. A GSOC proposal is used to select a student who is then supervised by the mentor(s) who will then drive the high-level design. When evaluating proposals I treat them as a demonstration that the student understands roughly what they are volunteering to do (under instruction) rather than as a specification of what will actually be done. > - I would look at how other similar projects do this, especially > projects in the scientific ecosystem. NumPy, matplotlib, and > scikit-learn > ... > We should also talk with members of those > communities to see how they feel about the processes and what works > and what doesn't. I'll give that a go. > I think Python PEPs aren't a great model to mimic > directly. The Python community of developers is much larger, the > community of users is *much* larger, and they also care much more > about not breaking compatibility and being conservative about adding > new features than we do. I think we *should* be more conservative about adding features. For the most part, time would be better spent improving the existing features and documentation. We should also be more conservative about breaking compatibility. The community of users for sympy is growing all of the time as is the number of downstream libraries. PyPI now records on the order of a million downloads per month for sympy: https://pypistats.org/packages/sympy I'm sure the vast majority of that is CI but that shows how many projects now have sympy as a dependency. Of course it's easier to be more conservative about breaking compatibility if you are also more conservative about adding features in the first place. > - My biggest concern is this: it is often impossible to really know > what will work unless we try to implement it. We would have to be prepared to discuss or allow changes as needed on an ongoing basis until implementation is complete. I still think it's good to start with a proper specification and consider that in full with its rationale before implementing anything beyond proof of concept. Problems will always emerge during implementation but better design can help to avoid fundamental problems. > I think the assumptions > are a great example of this. The idea of what the "new assumptions" > should look like has changed several times over the years, because > every time it has become clear that the current idea isn't tenable. > This has led to a rather unfortunate state of things where we have two > concurrent systems. But I don't really see how we could have come up > with a "new assumptions" idea that would actually work without first > trying out what we did and seeing why it didn't work. I wasn't around so I won't comment on discussion or design that took place in the past. What I will say is that at this stage we really do need something like a SymPEP to plan out what to do with assumptions *going forwards*. There needs to be a discussion and decisions need to be made and the result should be distilled and written down for all to see. The implications for developers and users need to be spelled out somewhere and there needs to be an implementation plan so that contributors can get on with that work. Last year there was a GSOC student working on making the new assumptions faster which is a straight-forward improvement that we can all understand without needing to think about complicated design questions. This year we have 6 GSOC students and none of them is working on assumptions even though it is high priority. I think that's quite simply because no one knows what a project on the new assumptions would do at this stage. (Design not agreed, no implementation plan) > - I have a few gripes with the Python PEP process which I think we > should try to avoid. All agreed. > - The SEP abbreviation is probably already used by some other > projects. How about SymPEP? Yes, I like the pronunciation of that. Oscar -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAHVvXxR7v%2BTmt91wsxX5AehXmEfLAL7Hu%2BUuqf92bdfJv2zvfA%40mail.gmail.com.
