Changing line() and text() to not generate 3d objects

[Jason Grout]

What do people think of changing line() and text() to only give 2d
graphics. Currently, the behavior for line() seems to be something
like, passing in a list of coordinates:

1. if the list has 3-dimensional coordinates, make a 3d line
2. if the list has more than 3-dimensional coordinates, silently strip
off the first two and make a 2d line
3. if the list has 2-dimensional coordinates,

Since there is not feature-parity between the 2d and 3d backends, the
current setup also means that options become valid or invalid depending
on how line() interprets its coordinates. That sounds like a very bad
thing.

There is a patch up at #3853 which makes line() and text() only do 2d
stuff, leaving line3d and text3d for the 3d things. I've also fixed
some other places that assumed the current behavior (which broke some
doctests; hooray for doctests). Are there any comments about making
this change?

Thanks,

Jason

[mhampton]

I would prefer that commands like point, line, and text work in 2D and
3D, but I don't have very strong feelings about it.

-M. Hampton

[Robert Bradshaw]

I would much rather not have to use two distinct methods, point could
simply dispatch to point2d or point3d depending on the size of the
coordinate vector, passing *args and **kwds along. Silently stripping off
the "extra" coordinates is IMHO bad though...

Even better, it would be good for the parameters for 2d and 3d
lines/text/etc to be made more uniform.

- Robert

[Jason Merrill]

On Aug 21, 6:54 pm, Robert Bradshaw <rober...@math.washington.edu>
wrote:

> On Thu, 21 Aug 2008, Jason Grout wrote:
>
> > What do people think of changing line() and text() to only give 2d
> > graphics.  Currently, the behavior for line() seems to be something
> > like, passing in a list of coordinates:
>
> > 1. if the list has 3-dimensional coordinates, make a 3d line
> > 2. if the list has more than 3-dimensional coordinates, silently strip
> > off the first two and make a 2d line
> > 3. if the list has 2-dimensional coordinates,
>
> > Since there is not feature-parity between the 2d and 3d backends, the
> > current setup also means that options become valid or invalid depending
> > on how line() interprets its coordinates.  That sounds like a very bad
> > thing.
>
> > There is a patch up at #3853 which makes line() and text() only do 2d

> > stuff, leavingline3dand text3d for the 3d things.  I've also fixed

> > some other places that assumed the current behavior (which broke some
> > doctests; hooray for doctests).  Are there any comments about making
> > this change?

-1

I also don't like this change. It seems pretty unambiguous what I
want to do if I pass line() a list with three dimensional
coordinates. I want a 3D line. I don't really understand the
rationale for this change.

1. and 3. above seem like correct behavior. 2. should throw an error,
until there is a 4D plotting backed ;-). Is there more specific data
on the problem with options not being the same between 2D and 3D?
Could the options be fixed to be the same? Or to fail in a sensible
way?

JM

[Mike Hansen]

> -1
>
> I also don't like this change. It seems pretty unambiguous what I
> want to do if I pass line() a list with three dimensional
> coordinates. I want a 3D line. I don't really understand the
> rationale for this change.
>
> 1. and 3. above seem like correct behavior. 2. should throw an error,
> until there is a 4D plotting backed ;-). Is there more specific data
> on the problem with options not being the same between 2D and 3D?
> Could the options be fixed to be the same? Or to fail in a sensible
> way?

The patch at #3853 will dispatch to line3d if line2d (same for point)
fails. This is the same behavior as was there before. It needs to be
reviewed.

--Mike