Re: [matplotlib-devel] Custom plot_trisurf triangulations

[Ian T. <ian...@gm...>]

On 21 September 2012 14:38, Benjamin Root <ben...@ou...> wrote:

> On Fri, Sep 21, 2012 at 6:43 AM, Damon McDougall <
> dam...@gm...> wrote:
>
>> On Fri, Sep 21, 2012 at 8:27 AM, Ian Thomas <ian...@gm...>
>> wrote:
>> > On 20 September 2012 22:30, Damon McDougall <dam...@gm...>
>> > 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