On Mon, Apr 11, 2016 at 7:36 PM, Volker Braun <vbraun.n...@gmail.com> wrote: > On Monday, April 11, 2016 at 3:00:12 PM UTC+2, Erik Bray wrote: >> >> It's no doubt very time consuming to check every merged pull request > > > Thats a great idea and scales really well when the project merges 5 branches > a day. It will also ensure that there are always enough volunteers to serve > as release manager.
Sorry, I can't tell if this was meant to be sincere or not. Because I'm being quite sincere. Sage isn't the biggest project in the world--it can be managed. The problem currently is that it's on an all-volunteer basis, and that's hard. And I respect that. But I don't think having an increasingly unmanageable project is going to attract *more* volunteers. Another reason to look for places to trim the fat, so to speak. >> Sage, unfortunately, hasn't made many pacts in this regard > > Sage does have a very clear way of making symbols available on the > commandline, namely via accompanying all.py files. We can either use that to > define our public api (which it de facto already is when you use Sage > interactively), or go through every module and sprinkle around underscores. > Only one of these two is realistic. Why only one? One thing that too many people in this discussion seem to assume is that this has to be all or nothing. You wrote "every module", but why not "some modules", or "the most abused modules"? Or, "on a case-by-case basis when evidence of misuse turns up in bug reports"? Because an incremental approach is better than doing nothing at all. An all.py file is fine too though and certainly helps as a starting point. We could say "don't use anything that's not listed there". But certainly when it comes to class methods, perhaps more than anything else, consistent use of underscores is a must. Module names, and functions within modules are sometimes a little looser, and better handled through __all__ or some equivalent thereof. > Equally important, we need > a mechanism for consumers of the api to avoid fragile dependencies on > private structures. This could be via unit testing, a linter, or an import > meta hook. Not exactly sure what you would use an import hook for in this case, but it sounds like overkill. It sounds instead like a slight cultural shift is needed--that people writing code for sage need to understand what they're writing Python, and should follow the standard best-practices for Python. They should understand what is and isn't for private use, and that they can't rely on private interfaces. Unit testing + linter rules for all code sounds like a good idea though! Best, Erik -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
