On Sunday, September 26, 2021 at 1:10:21 PM UTC-7 Nils Bruin wrote: > On Sunday, 26 September 2021 at 10:44:14 UTC-7 Matthias Koeppe wrote: > >> *1. Replace use of "from sage.PAC.KAGE.all import ..." by more specific >> imports* >> > > I'm not sure whether I'm a fan of the "all" packages (for one thing, they > make proper use of "lazy_import" a lot harder, but importing lazy_import > from all will cause exactly the same problem), but does it need to stand in > the way of modularization? Doesn't it just mean that the "all" package > needs to do a little magic to discover what its namespace should contain? > Here I mean with "magic" something that perhaps needs to discover during > runtime what is available within the relevant "namespace" package. >
Such more dynamic approaches are certainly possible. But I think they will create trouble with static type checkers. See discussion in https://trac.sagemath.org/ticket/30647, for example. > One big advantage of "all" packages is that you can hide the internal > module structure of a package with it a little bit, so that the structure > becomes an implementation detail, not a part of the API specification. > This does not describe our current practice or policy. All public names in all Python modules are part of the API; when we move anything around, we use deprecation via lazy_import etc. Also, I think it's pretty clear that the Sage library does not currently use imports from .all in a systematic way. So I don't think anything is lost. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/b8ad1d06-a30b-4ace-8659-793b47e2bdd6n%40googlegroups.com.
