Re: [sage-devel] Re: Sage as a Python Library
When I played around with imports a while back I came away with the impression that almost all of sage is imported rather early on in sage.all. Without flattening out the import dependencies you won't make importing modules much faster IMHO. On Friday, April 4, 2014 3:23:31 PM UTC+1, R. Andrew Ohana wrote: > > I think that a lot of our circular import issues stem from the > (unofficial) convention of using the `from foo import bar` syntax over the > `import foo` syntax > I would argue the opposite, when you just import modules then you get away with many more circular imports. That in itself is not a good thing. And [1] just provides a way to enable non-pythonic code. Whereas explictly importing classes forces you to at least think about an order of imports. Seldomly used imports should move from the module scope to the method that uses them; this isn't unlike the "import foo" solution except that it is more explicit. And would be encouraged by any module-scope import restrictions that I propose. > I often wish the reverse convention was chosen for namespace reasons (and > readability reasons). Just looking at the absolute imports within the sage > library we have [2] > > - thereof lines of the form "from sage.foo import bar" 19,581 - thereof > lines of the form "import sage.foo (as baz)" 1,650 > > [1] > http://stackoverflow.com/questions/3955790/python-circular-imports-once-again-aka-whats-wrong-with-this-design > [2] http://trac.sagemath.org/15985 > > -- > Andrew > -- 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.
Re: [sage-devel] Re: Sage as a Python Library
On Fri, Apr 4, 2014 at 3:27 AM, Volker Braun wrote: > On Friday, April 4, 2014 1:55:40 AM UTC+1, R. Andrew Ohana wrote: >> >> I'm a bit confused at what you are saying. I agree that the act of >> cleaning up the imports is essentially impossible right now due to the >> combinatorial explosion, but unless I'm missing something, we could track >> the modules that can be imported (without causing circular import issues) >> and have a regression requirements to insure that this list doesn't shrink. >> > > What I'm trying to say is: You can trivially make every module importable > by first importing everything else (well everything before that module in > sage.all). That is presumably not what you want ;) So there should also be > a mechanism to restrict the available modules, e.g. via a custom importer > while said module is loading. > Ah ok, I understand now. I'm not necessarily convinced this is the right way to go -- I think the cost of making a developer jump through hoops to get some functionality from a module foo from bar, just because bar is not allowed to import foo, outweighs the benefit. I think that a lot of our circular import issues stem from the (unofficial) convention of using the `from foo import bar` syntax over the `import foo` syntax (for anyone not really familiar with this, see [1] for a good explanation). I often wish the reverse convention was chosen for namespace reasons (and readability reasons). Just looking at the absolute imports within the sage library we have [2] - thereof lines of the form "from sage.foo import bar" 19,581 - thereof lines of the form "import sage.foo (as baz)" 1,650 [1] http://stackoverflow.com/questions/3955790/python-circular-imports-once-again-aka-whats-wrong-with-this-design [2] http://trac.sagemath.org/15985 -- Andrew -- 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.
Re: [sage-devel] Re: Sage as a Python Library
On Friday, April 4, 2014 1:55:40 AM UTC+1, R. Andrew Ohana wrote: > > I'm a bit confused at what you are saying. I agree that the act of > cleaning up the imports is essentially impossible right now due to the > combinatorial explosion, but unless I'm missing something, we could track > the modules that can be imported (without causing circular import issues) > and have a regression requirements to insure that this list doesn't shrink. > What I'm trying to say is: You can trivially make every module importable by first importing everything else (well everything before that module in sage.all). That is presumably not what you want ;) So there should also be a mechanism to restrict the available modules, e.g. via a custom importer while said module is loading. > -- 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.
Re: [sage-devel] Re: Sage as a Python Library
On Thu, Apr 3, 2014 at 3:49 PM, Volker Braun wrote: > > Simplifying the import process would definitely be nice. We should have > some mechanism enforce a somewhat linear order, e.g. by introducing > barriers where you are only allowed to (module-level) import stuff that > finished importing before the previous barrier. Perhaps ideally a linear > order where you can only import from the previously imported modules, one > can always dream > > One general problem with the "Python library" goal are cyclic imports. > There are a lot of places where you have to import modules in the right > order. Once you do away with a single sage.all entry point then it'll be > tricky to get Sage running at all. And the combinatorial explosion prevents > us from any meaningful test coverage. > > I'm a bit confused at what you are saying. I agree that the act of cleaning up the imports is essentially impossible right now due to the combinatorial explosion, but unless I'm missing something, we could track the modules that can be imported (without causing circular import issues) and have a regression requirements to insure that this list doesn't shrink. I also vaguely recall Robert creating a graph of the module dependencies some years ago -- if that code is still around (with potentially a little updating), it would at least give us a good idea of what components of sage are currently approachable in regards to this issue. -- Andrew -- 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.
[sage-devel] Re: Sage as a Python Library
Simplifying the import process would definitely be nice. We should have some mechanism enforce a somewhat linear order, e.g. by introducing barriers where you are only allowed to (module-level) import stuff that finished importing before the previous barrier. Perhaps ideally a linear order where you can only import from the previously imported modules, one can always dream One general problem with the "Python library" goal are cyclic imports. There are a lot of places where you have to import modules in the right order. Once you do away with a single sage.all entry point then it'll be tricky to get Sage running at all. And the combinatorial explosion prevents us from any meaningful test coverage. > -- 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.