changes to collections, etc.

Where breakage will occur is any place in user code that

    > expects the collection segments or vertices to be lists of
    > tuples and tries to append to the list, for example. I
    > don't know of any way to make the move towards use of arrays
    > without this problem cropping up; I hope it is considered
    > tolerable.

If I'm understanding you correctly: Users who create the collection
themselves with the list of xy tuples approach can still modify their
lists, eg with append, and not have breakage (I actually use this
feature). But users who are getting collections back from code like
contour will get the non-modifiable array version.

John Hunter wrote:

"Eric" == Eric Firing <efiring@...229...> writes:

    > Where breakage will occur is any place in user code that
    > expects the collection segments or vertices to be lists of
    > tuples and tries to append to the list, for example. I
    > don't know of any way to make the move towards use of arrays
    > without this problem cropping up; I hope it is considered
    > tolerable.

If I'm understanding you correctly: Users who create the collection
themselves with the list of xy tuples approach can still modify their
lists, eg with append, and not have breakage (I actually use this
feature). But users who are getting collections back from code like
contour will get the non-modifiable array version.

John,

Yes, that is the way it is supposed to work. The collection stores and uses whichever form it is given. This can work because the XY array is very similar to the [(x,y), (x,y)...] form; both are single objects, and they behave the same when one says, "for xy in XY:", or if one calls the array constructor with either as an argument.

Eric