On 21 September 2012 14:38, Benjamin Root <ben.r...@ou.edu> wrote:
> On Fri, Sep 21, 2012 at 6:43 AM, Damon McDougall <
> damon.mcdoug...@gmail.com> wrote:
>
>> On Fri, Sep 21, 2012 at 8:27 AM, Ian Thomas <ianthoma...@gmail.com>
>> wrote:
>> > On 20 September 2012 22:30, Damon McDougall <damon.mcdoug...@gmail.com>
>> > wrote:
>>
> 3. Create a new args_2d tuple exactly equal to *args but with 'z'
>> removed. Then rely on the 2d code with:
>> Triangulation.get_from_args_and_kwargs(args_2d, **kwargs). Since this
>> option would be common to all 3d functions relying on the 2d heavy
>> lifting, it could be wrapped up into a convenience function.
>>
>> In my opinion, option 3. is preferable. Option 3. will also produce
>> commits with the highest signal-to-noise ratio.
>>
>>
> I agree with option 3. It fits in nicely with the paradigms of the
> existing codebase (my recent contributions excluded...)
>
I am happy with option 3 too, but I don't think you need to do as much as
this. The existing 2d triplot/tripcolor/tricontour call
Triangulation.get_from_args_and_kwargs, which removes the various
args/kwargs needed for the triangulation and leaves the remainder for the
calling function to process. For example lib/matplotlib/tri/tricontour.py
lines 86 to 88:
tri, args, kwargs = \
Triangulation.get_from_args_and_kwargs(*args, **kwargs)
z = np.asarray(args[0])
Can't you just do the same here, or am I missing something?
> A wider issue, and something I should have mentioned when you first
>> > implemented plot_trisurf, is that I don't like the function name. It
>> seems
>> > unnecessary to have the plot_ at the front as most of the other
>> plot-related
>> > functions manage without it. My unease extends to plot_surface and
>> > plot_wireframe as well. I guess we can't just change such names now
>> that
>> > they are being used, but eventually I would like to see better naming
>> within
>> > mplot3d.
>> >
>>
>>
>> Agreed. Not sure how best to solve this. Furthermore, I think it
>> should be implemented in a pull request separate to the one migrating
>> these 3d methods to custom triangulations.
>>
>>
> I wouldn't be against going down a deprecation path for renaming these
> functions, but for what gains? The names have been there since before I
> took up this toolkit, and ultimately, these functions aren't typed so often
> that brevity would gain one much. Definitely any new functions should not
> take up that naming, but I see no real compelling reason to change the
> existing names.
>
The gain is that of more consistent naming of the mplot3d api functions.
The argument that we should keep names because they have been around for a
long time is not a strong one if the names are poor choices in the first
place. But I am not particularly concerned as I think that mplot3d has
some bigger problems to solve than this e.g. correct rendering of nested
polygons, z-order rendering, so maybe I should keep quiet about such
details!
Ian
------------------------------------------------------------------------------
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
