[Yt-dev] announcing yt 2.0-alpha

j s oishi jsoishi at gmail.com
Mon Aug 30 12:41:15 PDT 2010


Hi all,

After a few days of hard work, Britton, Matt, and I are pleased to
announce that a major reorganization of yt is complete. This is the
biggest part of what will become yt-2.0, and encompasses nearly all of
the codebase. We have pushed it to the tip of the yt branch in the
hg repository today. PLEASE NOTE you MUST reclone (not hg pull!) your
mercurial repository from hg.enzotools.org! Just move your old
repository out of the way and do

hg clone http://hg.enzotools.org/yt

Finally, please note that as of today SVN is read only. You can still
use the SVN repository for now, but it will no longer acquire any new
changes.

We have done a good amount of testing, but there are sure to be places
where things break. Please report anything you find to the issue
tracker
(http://yt.enzotools.org/newticket) as soon as you can.

The changes have almost all been organizational, except for the
addition of a new QuadTree method for projections, which Matt pushed
to the yt branch ahead of this. Furthermore, unless you do something
**other** than

from yt.mods import *

*everything* should be exactly the same for all of your scripts. We
would really appreciate it if you could file a ticket
(http://yt.enzotools.org/newticket) if you find anything that imports
only from yt.mods doesn't work.

The biggest change is that the old module Snow Crash-derived module
names (lagos, raven, fido, enki) have been removed, and  the code has
been divided up into new set of modules, with descriptive names:

drwxr-xr-x   21 joishi   joishi        714 Aug 27 11:49 analysis_modules
drwxr-xr-x   31 joishi   joishi       1.0k Aug 28 08:45 data_objects
drwxr-xr-x   15 joishi   joishi        510 Aug 26 16:57 frontends
drwxr-xr-x    9 joishi   joishi        306 Aug 28 08:45 gui
drwxr-xr-x   46 joishi   joishi       1.5k Aug 28 08:45 utilities
drwxr-xr-x   38 joishi   joishi       1.3k Aug 28 16:09 visualization

The second biggest change, and perhaps the more important one
(especially to yt developers) is the redesign of how we access
component pieces within and outside of yt. Previously, within yt,
importing modules from one part of the code to another was
accomplished by things like

from lagos import *

in the __init__.py file of another module. This has two negative
effects: first, it pollutes the namespaces with many unnecessary
classes and functions (greatly raising the possibility of a
collision), and second, it creates circular imports which can slow
down import times for yt. In order to solve these two problems, we
emptied out __init__.py of everything except a docstring in every
module and replaced them with api.py files. Each module has a api.py
file containing a list of imports of each class or function wihthin
that module imported individually to the API. For example, here is the
visualization api.py:

from color_maps import \
   add_cmap

from plot_collection import \
   PlotCollection, \
   PlotCollectionInteractive, \
   concatenate_pdfs, \
   get_multi_plot

from fixed_resolution import \
   FixedResolutionBuffer, \
   ObliqueFixedResolutionBuffer

from image_writer import \
   multi_image_composite, \
   write_bitmap, \
   write_image, \
   map_to_colors, \
   splat_points

from plot_modifications import \
   PlotCallback, \
   callback_registry

In order to use a function from the yt/visualization package, you
would add the following import lines to your script:

from yt.mods import * # this hasn't changed
from yt.visualization.api import PlotCollection

pf = load("AwesomeTown0132")
pc = PlotCollection(pf)

The third major change was to move extensions to analysis_modules.
This will likely affect many people in a purely cosmetic way; for
example, the halo finder is now imported by adding the following line
to your script:

from yt.analysis_modules.halo_finding.api import HaloFinder

a bit wordier, but much cleaner. If you are developing yt, please note
that the api.py file is for EXTERNAL scripts only. Anything INTERNAL
to yt must directly import any class or function necessary by directly
referencing the file it resides in, e.g.: from .fixed_resolution
import FixedResolutionBuffer.

Finally, Volume Rendering has been relocated to the new visualization
module. It should otherwise be unchanged (except the api.py change, of
course).

Full notes on all these changes can be found on the wiki:

http://yt.enzotools.org/wiki/yt-2.0

We hope this will lead to a much cleaner, more hackable, more
understandable yt. yt-2.0 will also include a new, simpler plotting
interface. Please feel free to contact Britton, Matt, or me if you
have any questions or any problems with the new yt.

Thanks!

Jeff
Matt
Britton



More information about the yt-dev mailing list