Preliminary points: 1) It's unreasonable to always ask reviewers to implement their ideas. For instance, sometimes they may find a problem but not be sufficiently expert to implement it; that doesn't mean there isn't a problem. Of course, then other reviewers may decide the critique is too trivial/far afield/etc.
2) It's unreasonable to expect authors to always implement reviewer ideas or critiques. The same reason applies, though others exist. Of course, then the ticket may (probably will) not be merged. 1-2) Both of the above are also subject to time constraints by author and reviewer, and I think that very few posts in this thread have really recognized that. The reality is that sometimes good things just don't happen (not just in OSS, by the way) because people have to make choices about what to work on, or whether to work on (say) Sage at all. 1-2) Both of the above have happened zillions of times in Sage. Just take a look at Trac. 3) Sometimes there will be philosophical differences about structure/implementation, ones which are not about bugs per se, but informed speculation. There need to be ways to resolve those, but we have to recognize that some decisions will not be a full consensus. And we have to recognize that those are not necessarily related to 1-2). I don't know whether any or all of these 1-3) apply to #10963, though it looks likely. But the philosophy of Sage has *typically* (not universally, not throughout all time) been to give new functionality a chance once technical problems have been worked out, even if not everything is implemented etc. This thread seems like the canonical place to do it, but let's keep in mind the goal is to see whether, *given* that #10963 has no issues of that kind (which doesn't yet appear to be the case, see #15792 and related discussion), whether it should be given a chance. 4) I'm not sure how documentation fits into this. We usually just say "needs doc and doctests" but perhaps in some cases additional documentation is not just desirable (it always is) but actually necessary for things to be merged. That was the case for the git change, for example. I have no idea whether that is really the case here, since I don't use this functionality. This did seem to be part of the motivation behind Volker's original remark, that the un-Pythonic syntax would cause confusion/bad infinite regress/various other things you can read about in this thread; I could imagine very very explicit doc that was "required reading" somehow dealing with this kind of potentially legitimate objection to a ticket's being merged. And no, I'm not suggesting that any old new syntax is okay; the question is whether this one is different enough to make it inappropriate for Sage. Main point: Raise your hand if you've never seen something implemented in Sage you thought should have been structured/named/organized differently. I don't think even the BDFL can say that! We may just end up having slightly suboptimal syntax if other syntax is not implemented in a reasonable period of time - that certainly isn't the first time in Sage, nor in other math software. The key is whether the change/syntax/concept/whatever is technically sound *enough* and expands the capabilities of Sage enough - keep the mission statement in mind. And in the end, a decision will have to be made, or the decision not to have this functionality will have been made by default. Perhaps that's the correct decision, but let's be careful about how often we use that decision. Good luck resolving this, everyone ;-) -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
