I'm +1 on deprecating the __getitem__ stuff.  I think at this point it mostly creates confusion.<br><br>I also think it might be a good idea to phase out instantiation of sphere, disk, etc object in the manner discuss in point 3 and push toward using the (size, unit) tuple method.  This method is consistent with how the time_series analogs of those objects are created and I think that consistency is valuable.<br>
<br>Britton<br><br><div class="gmail_quote">On Sun, Feb 19, 2012 at 11:49 AM, Matthew Turk <span dir="ltr"><<a href="mailto:matthewturk@gmail.com">matthewturk@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Kacper,<br>
<br>
This is a gigantic weak spot in yt: handling of units, which generally<br>
does *work*, is done behind some relatively old and unnecessary code.<br>
When I started writing it, I learned about operator overloading, and<br>
so I tossed all the parameters, units, and time_units into a single<br>
call to __getitem__.  I've disliked this for quite some time, as it<br>
conflates all types of conversion between things, as well as<br>
conflating conversion with parameters.<br>
<br>
Adding a length and mass unit system would be a bandaid to this system<br>
... I'm inclined to say it's probably okay to do, but I would rather<br>
we go through a more in-depth improvement.<br>
<br>
1) Deprecate *immediately* __getitem__ on a parameter file.  This<br>
means adding a DeprecationWarning, in whcih we say that in version 3.0<br>
this functionality will go away.<br>
2) Replace all usages of pf[whatever] in the code with calls to<br>
explicitly the parameters dict or something else.<br>
3) Find all places where the idiom something/pf[unit] is used, and<br>
either replace them with fix_length on it or find some other way<br>
around it.  (Did you know that spheres, cylinders, etc can all have<br>
tuples of value, unit passed in?)<br>
4) Set up our base of unit conversions, which are applied when IO is conducted.<br>
5) Use conversions between those units rather than relying on the<br>
parameter file.<br>
<br>
For #5, we could either use a system like Amusecode.org uses (where<br>
they apply sidecar unit values to wrapped ndarrays; the main amuse<br>
architect is on this list, so perhaps he could say a bit more) or I<br>
noticed that Casey's blog indicated he released Dimensionful, a<br>
library for light tracking and converting units, which would also work<br>
quite nicely for this.<br>
<br>
Either way, I want to get rid of the current system and plan something<br>
out; first step is letting people know that we're deprecating<br>
pf[something].  [+-][01]?  But, for now, adding on what you suggest is<br>
fine, Kacper.  :)<br>
<br>
Thoughts?<br>
<br>
-Matt<br>
<div><div class="h5"><br>
On Sat, Feb 18, 2012 at 10:02 AM, Kacper Kowalik<br>
<<a href="mailto:xarthisius.kk@gmail.com">xarthisius.kk@gmail.com</a>> wrote:<br>
> Hi,<br>
> I've been hit by a part of the code<br>
> (plot_modifications:get_smallest_appropriate_unit) that assumed my data<br>
> knows what a Mpc, or even Rsun is. While it's trivial to workaround by<br>
> using try/except, that made wonder why time_units get a special<br>
> treatment in StaticOutput? Would it be beneficial to introduce<br>
> corresponding {lenght,mass}_units?<br>
> Cheers,<br>
> Kacper<br>
><br>
><br>
><br>
</div></div>> _______________________________________________<br>
> yt-dev mailing list<br>
> <a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
> <a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
><br>
_______________________________________________<br>
yt-dev mailing list<br>
<a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
</blockquote></div><br>