Re: [sage-devel] Re: Sage as a Python Library

2014-04-04 Thread Volker Braun
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

2014-04-04 Thread R. Andrew Ohana
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

2014-04-04 Thread Volker Braun
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

2014-04-03 Thread R. Andrew Ohana
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

2014-04-03 Thread Volker Braun
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.