Hi. Thanks for posting this. Here are my high level thoughts. - I'm not opposed to the idea, and it's always good to write design decisions down, but we should make sure it doesn't become bureaucratic, as David mentioned.
- 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. And of course, every GSoC project starts with a GSoC proposal that outlines what will be done in the project. - I would look at how other similar projects do this, especially projects in the scientific ecosystem. NumPy, matplotlib, and scikit-learn are some examples I know of. I would expect matplotlib and scikit-learn to be more similar to SymPy, since they are also large projects with distinct parts, where most contributors are only familiar with some specific submodules, but there's also a "core" that affects the entire library. 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 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. - My biggest concern is this: it is often impossible to really know what will work unless we try to implement it. 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 have a few gripes with the Python PEP process which I think we should try to avoid. - First, SEPs should not be treated as end-user documentation. There are too many instances where Python links to a PEP instead of real documentation. It always feels inappropriate, because PEPs spend a lot of time talking about things that are irrelevant to an end-user, like motivations for a feature, alternate proposals that were not implemented, and so on. - Python PEPs often give the impression of a cabal, or separation between the "core contributors" and "users", which I want to avoid for SymPy. For example, you may be familiar with the politics that occured with PEP 572 (assignment expressions) or more recently, PEP 622 (pattern matching). - Lastly, it really annoys me when people refer to Python PEPs by number only. This serves to reinforce the "cabal" feeling, because core developers tend to work with the PEPs a lot and know them by number, but everyone else won't. Unless the PEP is PEP 8, I think people should always either include a title with the PEP or a URL to the PEP when referring to it. - The SEP abbreviation is probably already used by some other projects. How about SymPEP? Aaron Meurer On Sun, Aug 2, 2020 at 2:32 PM Oscar Benjamin <oscar.j.benja...@gmail.com> wrote: > > On Sun, 2 Aug 2020 at 18:49, Gagandeep Singh (B17CS021) > <singh...@iitj.ac.in> wrote: > > > > I read the original post and I think the idea of introducing SEPs seems to > > be really useful. Since, I am quite involved with `stats` module and was > > thinking to add some new features to it to make it more powerful and useful > > to the people working in the area of statistics. I wanted to know whether > > it will be possible to propose new features via SEP or more precisely, can > > SEPs initially have requirements and expectations, and then later on after > > community discussion, SEPs can be changed and more details can be added. > > I think that a SEP would be most useful where it represents a > non-incremental change as incremental changes are well handled by the > existing issue/PR workflow. So if the proposal is to add a feature > without substantially altering the existing structure then that's not > the kind of situation I'm thinking of although we could use SEPs for > that if that's what people want to do. > > On the other hand I think a SEP would be useful if the proposal is > something like "The stats module needs to be reworked with a new > structure/API because the existing structure can not be extended in a > backward compatible way to handle random variables with finite but > symbolically sized sample spaces" then that's the kind of situation I > was thinking of. Making deep incompatible changes needs careful > consideration and needs to have a motivation/explanation that we can > point to for downstream libraries and users. > > To me it would also seem useful if the stats module had a document > (perhaps a SEP) that clarified what the intended scope of the module > is in its entirety. For example: what features would the module have > at the point that it was considered complete and what needs to be done > to get there? Personally I would find a document like that useful > because right now the intended scope of the stats module is unclear to > me. > > > 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 sympy+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/CAHVvXxSezSA%3Doiu9PWHNSX-7rAM_2Tdsg2yBDFvUKW9R9RENrw%40mail.gmail.com. -- 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 sympy+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6%2BAGz2M2iVn%2B%3DG1n5QRRAguPZyQO9Mez0xwZ6iXur9dhA%40mail.gmail.com.
