On Sun, 2 Aug 2020 at 04:58, Jason Moore <[email protected]> wrote:
>
> I agree with this. SEPs would be a net positive. They seem to work well with
> other projects.
>
> Question: How do we know what changes require SEPs and what don't?
I would say that for now at least it shouldn't be a requirement to
produce a SEP except where there are significant backwards
compatibility issues for users or downstream projects.
An example of a backwards compatibility change would be the import
changes introduced in sympy 1.6 should that probably have been
discussed in a SEP:
https://github.com/sympy/sympy/issues/18245
Those changes are still incomplete so a SEP for removal of the
deprecated imports would still be reasonable. A SEP would be a better
place than a github issue/PR to document the purpose of the changes
and what affected users should do in response to them.
> Is the idea that if informal proposals are brought up in our current
> communication mechanisms that someone would say "this should probably be a
> SEP" and then it's the proposer's burden to create the SEP to move forward?
I would look at this the other way round. As a contributor you can
write a SEP to get your idea fleshed out and accepted/rejected before
implementing the idea. Then you would know that the idea is accepted
and you and others would be able to work on the implementation with a
good shared understanding of the objectives and agreed specification.
I would be much happier when reviewing a PR that partially implements
a SEP than I am about merging a half-complete idea that isn't fully
specified anywhere.
I don't think anyone should be required to write a SEP but as a
contributor wanting to make larger changes you might want to write one
if e.g.
- You are not sure that your idea is something that will be accepted.
- There is a deadlock between contributors over proposed changes on github
- You want to get an agreed specification that can be implemented
afterwards partially or entirely by other contributors.
- The work is a longer term project that is too much for a single pull
request and you want to make the overall goal clear to others who
would review/merge the pull requests.
- You think that there is a need for all contributors to standardise
on something that isn't trivial to explain.
An example of a PR that might benefit from a SEP is:
https://github.com/sympy/sympy/pull/19479
That adds an Equation class which can be used intuitively in
arithmetic and function calls and so on. That's something that a lot
of users want and there is a very long-standing issue for it on
github. It's also something that can be easily understood by many
contributors and the wider community. Finally the discussion there has
a potential deadlock over the user of simplify. A SEP discussion can
resolve that deadlock as well as ensure that the design choices have
wide agreement. In this example there has already been a lot of
discussion on many issues and pull requests and on this mailing list.
The SEP would help to get broad agreement on the design.
Another example of a PR that could benefit from a SEP is this:
https://github.com/sympy/sympy/pull/19750
The proposal is to introduce a new function framework. I think that is
needed but there are many different ways to do it and there hasn't
really been any wider discussion around how it should work. The actual
changes would take a long time to implement since the implication is
that all function classes in sympy (exp, sin, ...) would be migrated
to the new framework. That's too big for one PR though so instead the
new framework will be introduced and then the classes incrementally
migrated over. I personally would object to merging that PR as a
half-implementation of an idea until it is clear to me what the
broader plan is and that it can actually replace the existing function
framework. In this case there has been hardly any discussion and now a
huge amount of work seems to have gone into implementing a design that
hasn't really been agreed by anyone. It would be better to have a SEP
discussion first before implementing something like this.
> What prevents every suggested change being pushed towards a SEP?
I do understand your concern here. It seems that the way things have
gone with core Python even trivial things end up having PEPs now:
https://www.python.org/dev/peps/pep-0485/
Part of the reason that happens I think is because in core Python many
changes/ideas are discussed excessively. The PEP process becomes a way
of structuring that conversation and also often serves the purpose of
resolving otherwise unending debates.
Right now there is fairly minimal discussion around any changes in
sympy (typically 2-3 people are involved in discussing even major
changes). Part of why I want to have SEPs for sympy is to give a space
to have wider discussion that otherwise just doesn't happen anywhere.
If the burden of writing/discussing SEPs becomes too great then that
we can rethink the idea.
I think that the biggest question is this: by what mechanism can a SEP
be considered "rejected"? Rejecting ideas is one of the most important
roles of these processes. SymPy's current collaboration model is based
on "consensus" which doesn't allow for an idea to be rejected if it
still has a single proponent (e.g. the author).
--
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/CAHVvXxSubwhsdvcMSyfZ82ORXHqPD7Or4We%3DwRDPqUKRRO7BJg%40mail.gmail.com.
