Hey Andrew, On Sun, Jan 13, 2013 at 6:45 PM, Andrew Myers wrote:

Hi Folks,

I was wondering if there are any objections (particularly from Nathan) to adding an optional **kwargs argument to SlicePlot and ProjectionPlot, so that we can pass in field parameters like this:

pw = SlicePlot(pf, 2, 'GravitationalForceMag', center=c, width=(1e4, 'au'), particle_data=pd)

instead of the (very slighty) more clunky:

slice = pf.h.slice(2, c[2], ['GravitationalForceMag'], particle_data=pd) pw = slice.to_pw('GravitationalForceMag', center=c, width=(1e4, 'au'))

I think it would be nice to able to use the same syntax to generate slices and projections whether or not a derived field requires extra field parameters.

This would be nice. However, sine in 3.0 kwargs have been replaced with an explicit: field_parameters = {'particle_data': pd} type call in the constructor, I would prefer we go with the same thing here. In general I'm less into adding complexity to the APIs for things like this, but for this use case I think it's manifestly better to allow it. So I'd say yes, with the caveat that we should be doing: pw = SlicePlot(pf, 2, 'GravitationalForceMag', center=c, width=(1e4, 'au'), field_parameters=dict(particle_data=pd)) and then passing the field_parameters as kwargs to the data object creation. This way when 3.0 is the main use case, we only have to change from passing kwargs to the data object construction to passing the field_parameters dict itself. Would that be okay? -Matt

Thanks, Andrew

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

Hi Matt and Nathan, Thanks for your responses. I'm fine with an explicit field_parameters instead of **kwargs - in fact, now that you both mention it, I agree that it's better to do it that way. I'll submit a pull request shortly for you to look at. Thanks, Andrew On Sun, Jan 13, 2013 at 4:04 PM, Nathan Goldbaum wrote:

Hi Andrew,

Rather than adding **kwargs to the signature of __init__ for PWViewMPL, I think it would be better to add a field_parameters keyword argument. This would be a dict that would be iterated over to set field parameters. This is actually exactly how **kwargs is handled in the AMRData base class but I think mandating that the dict is referred to as field_parameters internally is a bit clearer with the added benefit that the API is concrete and doesn't rely on a somewhat advanced python concept. I'm not a big fan of how the data containers currently handle the kwargs dict and am -1 on exposing **kwargs in a user-facing function.

That being said, I haven't thought about this issue as deeply as others on the project have, and there may be very good reasons for using **kwargs in this context.

Cheers,

Nathan

...

Hi Folks,

I was wondering if there are any objections (particularly from Nathan) to adding an optional **kwargs argument to SlicePlot and ProjectionPlot, so that we can pass in field parameters like this:

pw = SlicePlot(pf, 2, 'GravitationalForceMag', center=c, width=(1e4, 'au'), particle_data=pd)

instead of the (very slighty) more clunky:

slice = pf.h.slice(2, c[2], ['GravitationalForceMag'], particle_data=pd) pw = slice.to_pw('**GravitationalForceMag', center=c, width=(1e4, 'au'))

I think it would be nice to able to use the same syntax to generate slices and projections whether or not a derived field requires extra field parameters.

Thanks, Andrew

______________________________**_________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/**listinfo.cgi/yt-dev-spacepope.**orghttp://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.**orghttp://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org