Hi all, Some of this was hashed out before on the YTEP-0019 discussion, but I am going through and re-implementing some of that now and I wanted to bring it back to the group. What we had come up with was: * import yt => gets most of the items used in yt in the main namespace * import yt.mods => treats yt more like an application, gets everything but *also* does "startup tasks" Now, the big benefit to making it like this is that you can do: import yt and get everything. The *downside* is that we will no longer be able to do: import yt.something.something_else and *avoid* importing all of yt. I've experimented with the import times and came up with this. All times were computed by running 10 cycles, dividing total time by 10. * 2.6 (current @ bookmark) => 0.45s per import * 3.0, "development" => 0.47s per import * My YTEP-0019 bookmark => 0.97s per import * Import numpy and matplotlib => 0.22s per import * Importing numpy, matplotlib, *and* sympy => 0.78s per import So I think we're doing okay on import times, although I must confess when I initial ran it and saw how slow importing the unitrefactor branch was I was a bit worried. But most of that is sucked up into numpy, matplotlib and sympy. I guess it's not so bad. Here's my PR: https://bitbucket.org/yt_analysis/yt/pull-request/729/ytep-0019/diff (bookmark: ytep0019, which I will delete later.) -Matt
What are the key things that `yt.mods` will do that `yt` will not under
this model? As a new user I did find the yt.mods thing a little strange. :p
Stuart
On 18 March 2014 14:20, Matthew Turk
Hi all,
Some of this was hashed out before on the YTEP-0019 discussion, but I am going through and re-implementing some of that now and I wanted to bring it back to the group.
What we had come up with was:
* import yt => gets most of the items used in yt in the main namespace * import yt.mods => treats yt more like an application, gets everything but *also* does "startup tasks"
Now, the big benefit to making it like this is that you can do:
import yt
and get everything. The *downside* is that we will no longer be able to do:
import yt.something.something_else
and *avoid* importing all of yt. I've experimented with the import times and came up with this. All times were computed by running 10 cycles, dividing total time by 10.
* 2.6 (current @ bookmark) => 0.45s per import * 3.0, "development" => 0.47s per import * My YTEP-0019 bookmark => 0.97s per import * Import numpy and matplotlib => 0.22s per import * Importing numpy, matplotlib, *and* sympy => 0.78s per import
So I think we're doing okay on import times, although I must confess when I initial ran it and saw how slow importing the unitrefactor branch was I was a bit worried. But most of that is sucked up into numpy, matplotlib and sympy. I guess it's not so bad.
Here's my PR:
https://bitbucket.org/yt_analysis/yt/pull-request/729/ytep-0019/diff
(bookmark: ytep0019, which I will delete later.)
-Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
On Tue, Mar 18, 2014 at 12:29 PM, Stuart Mumford
What are the key things that `yt.mods` will do that `yt` will not under this model? As a new user I did find the yt.mods thing a little strange. :p
Yeah, it was designed to avoid lots of sub-imports and to keep it possible to import individual bits by themselves. (i.e., importing without getting matplotlib, which will no longer be possible.) "mods" will treat yt more like an application, which means things like startup_tasks will be run and it will look at command line arguments. -Matt
Stuart
On 18 March 2014 14:20, Matthew Turk
wrote: Hi all,
Some of this was hashed out before on the YTEP-0019 discussion, but I am going through and re-implementing some of that now and I wanted to bring it back to the group.
What we had come up with was:
* import yt => gets most of the items used in yt in the main namespace * import yt.mods => treats yt more like an application, gets everything but *also* does "startup tasks"
Now, the big benefit to making it like this is that you can do:
import yt
and get everything. The *downside* is that we will no longer be able to do:
import yt.something.something_else
and *avoid* importing all of yt. I've experimented with the import times and came up with this. All times were computed by running 10 cycles, dividing total time by 10.
* 2.6 (current @ bookmark) => 0.45s per import * 3.0, "development" => 0.47s per import * My YTEP-0019 bookmark => 0.97s per import * Import numpy and matplotlib => 0.22s per import * Importing numpy, matplotlib, *and* sympy => 0.78s per import
So I think we're doing okay on import times, although I must confess when I initial ran it and saw how slow importing the unitrefactor branch was I was a bit worried. But most of that is sucked up into numpy, matplotlib and sympy. I guess it's not so bad.
Here's my PR:
https://bitbucket.org/yt_analysis/yt/pull-request/729/ytep-0019/diff
(bookmark: ytep0019, which I will delete later.)
-Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
YTEP-0019 has landed in the experimental bookmark!
https://bitbucket.org/yt_analysis/yt/pull-request/729/ytep-0019/diff
-Matt
On Tue, Mar 18, 2014 at 9:30 AM, Matthew Turk
On Tue, Mar 18, 2014 at 12:29 PM, Stuart Mumford
wrote: What are the key things that `yt.mods` will do that `yt` will not under this model? As a new user I did find the yt.mods thing a little strange. :p
Yeah, it was designed to avoid lots of sub-imports and to keep it possible to import individual bits by themselves. (i.e., importing without getting matplotlib, which will no longer be possible.) "mods" will treat yt more like an application, which means things like startup_tasks will be run and it will look at command line arguments.
-Matt
Stuart
On 18 March 2014 14:20, Matthew Turk
wrote: Hi all,
Some of this was hashed out before on the YTEP-0019 discussion, but I am going through and re-implementing some of that now and I wanted to bring it back to the group.
What we had come up with was:
* import yt => gets most of the items used in yt in the main namespace * import yt.mods => treats yt more like an application, gets everything but *also* does "startup tasks"
Now, the big benefit to making it like this is that you can do:
import yt
and get everything. The *downside* is that we will no longer be able to do:
import yt.something.something_else
and *avoid* importing all of yt. I've experimented with the import times and came up with this. All times were computed by running 10 cycles, dividing total time by 10.
* 2.6 (current @ bookmark) => 0.45s per import * 3.0, "development" => 0.47s per import * My YTEP-0019 bookmark => 0.97s per import * Import numpy and matplotlib => 0.22s per import * Importing numpy, matplotlib, *and* sympy => 0.78s per import
So I think we're doing okay on import times, although I must confess when I initial ran it and saw how slow importing the unitrefactor branch was I was a bit worried. But most of that is sucked up into numpy, matplotlib and sympy. I guess it's not so bad.
Here's my PR:
https://bitbucket.org/yt_analysis/yt/pull-request/729/ytep-0019/diff
(bookmark: ytep0019, which I will delete later.)
-Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
participants (2)
-
Matthew Turk
-
Stuart Mumford