nxutils

All,

I have not touched the code for several months, so it has taken me up until just now to realize that nxutils has been removed from the build.

I there any real reason for this? Particularly when you consider that there are still functions present that use it and now they just fail.

In particular I am referring to ‘mlab.inside_poly’. In my case I was using ‘nxutils.points_inside_poly’ directly, but the end result is the same.

Thanks,

–James Evans

All,

      I have not touched the code for several

months, so it has taken me up until just now to realize that
nxutils has been removed from the build.

      I there any real reason for this?

Particularly when you consider that there are still functions
present that use it and now they just fail.

      In particular I am referring to

‘mlab.inside_poly’. In my case I was using
‘nxutils.points_inside_poly’ directly, but the end result is
the same.

Thanks,

–James Evans

Most of what was in nxutils has been superseded by things in Numpy, and
it makes more sense for it to be over there.

In the case of points_inside_poly, you can use the Path object in
path.py and the "contains_point" method.

Mike

Mike,

This, however, brings us back to the plea by Volker Blum:

http://www.mail-archive.com/matplotlib-users@lists.sourceforge.net/msg22669.html

There is a real tension between the need to clean things up and simplify them, and users' desire for minimal loss of backwards compatibility. Personally, my instincts are in the "clean it up" camp, but a good balance has to be found.

nxutils was definitely a vestige of an earlier era; but I don't think it went through any official, publicized, deprecation process, did it? Maybe it didn't need to; I don't know. Perhaps we need to formulate and write down a deprecation policy.

Eric

···

On 11/17/2011 10:19 AM, Michael Droettboom wrote:

On 11/17/2011 12:03 PM, James Evans wrote:

All,

I have not touched the code for several months, so it has taken me up
until just now to realize that nxutils has been removed from the build.

I there any real reason for this? Particularly when you consider that
there are still functions present that use it and now they just fail.

In particular I am referring to ‘mlab.inside_poly’. In my case I was
using ‘nxutils.points_inside_poly’ directly, but the end result is the
same.

Thanks,

--James Evans

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Huh? Nxutils removed? Then how am I still using points_inside_poly? And, if I remember right, Path uses that to calculate contains().

Ben Root

···

On Thursday, November 17, 2011, Eric Firing <efiring@…229…> wrote:

On 11/17/2011 10:19 AM, Michael Droettboom wrote:

Most of what was in nxutils has been superseded by things in Numpy, and
it makes more sense for it to be over there.

In the case of points_inside_poly, you can use the Path object in
path.py and the “contains_point” method.

Mike

Mike,

This, however, brings us back to the plea by Volker Blum:

http://www.mail-archive.com/matplotlib-users@lists.sourceforge.net/msg22669.html

There is a real tension between the need to clean things up and simplify
them, and users’ desire for minimal loss of backwards compatibility.
Personally, my instincts are in the “clean it up” camp, but a good
balance has to be found.

nxutils was definitely a vestige of an earlier era; but I don’t think it
went through any official, publicized, deprecation process, did it?
Maybe it didn’t need to; I don’t know. Perhaps we need to formulate and
write down a deprecation policy.

Eric

On 11/17/2011 12:03 PM, James Evans wrote:

All,

I have not touched the code for several months, so it has taken me up
until just now to realize that nxutils has been removed from the build.

I there any real reason for this? Particularly when you consider that
there are still functions present that use it and now they just fail.

In particular I am referring to ‘mlab.inside_poly’. In my case I was
using ‘nxutils.points_inside_poly’ directly, but the end result is the
same.

Thanks,

–James Evans


All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d


Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d


Matplotlib-devel mailing list
Matplotlib-devel@…266…ts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d


Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

nxutils has been removed from master because it is completely
redundant to the Path functionality that has been in matplotlib
since 0.98. In the process of porting to Python 3, I felt it was
important to reduce code duplication, because every additional line
requires additional testing.

That said, there seems to be a lot of push back on this.  We can

reinstate it, but I would suggest raising DeprecationWarnings for
one release and then removing it entirely in the next.

Mike
···

http://p.sf.net/sfu/splunk-novd2dMatplotlib-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Perhaps another alternative is to just include a small compatibility
module that would call the new functionality under the hood.

Mike
···

http://p.sf.net/sfu/splunk-novd2dMatplotlib-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/matplotlib-develhttp://p.sf.net/sfu/splunk-novd2dMatplotlib-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/matplotlib-devel

I was just shocked to find the source code still present, just not compiled during the build step and at least one completely broken function call still referencing the un-built module and no apparent reason for removal.

I have updated mlab.inside_poly to use Path instead and will submit it later today.

–James

···

From: Michael Droettboom [mailto:mdroe@…31…]
Sent: Friday, November 18, 2011 6:23 AM
To: matplotlib-devel@lists.sourceforge.net
Subject: Re: [matplotlib-devel] nxutils

Perhaps another alternative is to just include a small compatibility module that would call the new functionality under the hood.

Mike

On 11/18/2011 09:07 AM, Michael Droettboom wrote:

nxutils has been removed from master because it is completely redundant to the Path functionality that has been in matplotlib since 0.98. In the process of porting to Python 3, I felt it was important to reduce code duplication, because every additional line requires additional testing.

That said, there seems to be a lot of push back on this. We can reinstate it, but I would suggest raising DeprecationWarnings for one release and then removing it entirely in the next.

Mike

On 11/18/2011 12:21 AM, Benjamin Root wrote:

Huh? Nxutils removed? Then how am I still using points_inside_poly? And, if I remember right, Path uses that to calculate contains().

Ben Root

On Thursday, November 17, 2011, Eric Firing <efiring@…229…> wrote:

On 11/17/2011 10:19 AM, Michael Droettboom wrote:

Most of what was in nxutils has been superseded by things in Numpy, and
it makes more sense for it to be over there.

In the case of points_inside_poly, you can use the Path object in
path.py and the “contains_point” method.

Mike

Mike,

This, however, brings us back to the plea by Volker Blum:

http://www.mail-archive.com/matplotlib-users@…1034…s.sourceforge.net/msg22669.html

There is a real tension between the need to clean things up and simplify
them, and users’ desire for minimal loss of backwards compatibility.
Personally, my instincts are in the “clean it up” camp, but a good
balance has to be found.

nxutils was definitely a vestige of an earlier era; but I don’t think it
went through any official, publicized, deprecation process, did it?
Maybe it didn’t need to; I don’t know. Perhaps we need to formulate and
write down a deprecation policy.

Eric

On 11/17/2011 12:03 PM, James Evans wrote:

All,

I have not touched the code for several months, so it has taken me up
until just now to realize that nxutils has been removed from the build.

I there any real reason for this? Particularly when you consider that
there are still functions present that use it and now they just fail.

In particular I am referring to ‘mlab.inside_poly’. In my case I was
using ‘nxutils.points_inside_poly’ directly, but the end result is the
same.

Thanks,

–James Evans


All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d


Matplotlib-devel mailing list
Matplotlib-devel@…717…rge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d


Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d


Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

------------------------------------------------------------------------------

All the data continuously generated in your IT infrastructure

contains a definitive record of customers, application performance,

security threats, fraudulent activity, and more. Splunk takes this

data and makes sense of it. IT sense. And common sense.

http://p.sf.net/sfu/splunk-novd2d

_______________________________________________

Matplotlib-devel mailing list

Matplotlib-devel@...1035...orge.net

https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

------------------------------------------------------------------------------

All the data continuously generated in your IT infrastructure

contains a definitive record of customers, application performance,

security threats, fraudulent activity, and more. Splunk takes this

data and makes sense of it. IT sense. And common sense.

http://p.sf.net/sfu/splunk-novd2d

_______________________________________________

Matplotlib-devel mailing list

Matplotlib-devel@...953...ge.net

https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

I
was just shocked to find the source code still present, just
not compiled during the build step and at least one
completely broken function call still referencing the
un-built module and no apparent reason for removal.

        I

have updated mlab.inside_poly to use Path instead and will
submit it later today.

–James

···

From:
Michael Droettboom [mailto:mdroe@…31…]
Sent: Friday, November 18, 2011 6:23 AM
To: matplotlib-devel@lists.sourceforge.net
Subject: Re: [matplotlib-devel] nxutils

        Perhaps another alternative is to just

include a small compatibility module that would call the new
functionality under the hood.

        Mike

        On 11/18/2011 09:07 AM, Michael Droettboom wrote:

        nxutils has been removed from master

because it is completely redundant to the Path functionality
that has been in matplotlib since 0.98. In the process of
porting to Python 3, I felt it was important to reduce code
duplication, because every additional line requires
additional testing.

        That said, there seems to be a lot of push back on this.  We

can reinstate it, but I would suggest raising
DeprecationWarnings for one release and then removing it
entirely in the next.

        Mike

        On 11/18/2011 12:21 AM, Benjamin Root wrote:

        Huh? Nxutils removed? Then how am I still

using points_inside_poly? And, if I remember right, Path
uses that to calculate contains().

        Ben Root

        On Thursday, November 17, 2011, Eric Firing <efiring@...229...            >

wrote:
> On 11/17/2011 10:19 AM, Michael Droettboom wrote:
>> Most of what was in nxutils has been superseded by
things in Numpy, and
>> it makes more sense for it to be over there.
>>
>> In the case of points_inside_poly, you can use the
Path object in
>> path.py and the “contains_point” method.
>>
>> Mike
>
> Mike,
>
> This, however, brings us back to the plea by Volker
Blum:
>
> http://www.mail-archive.com/matplotlib-users@lists.sourceforge.net/msg22669.html
>
> There is a real tension between the need to clean
things up and simplify
> them, and users’ desire for minimal loss of backwards
compatibility.
> Personally, my instincts are in the “clean it up” camp,
but a good
> balance has to be found.
>
> nxutils was definitely a vestige of an earlier era; but
I don’t think it
> went through any official, publicized, deprecation
process, did it?
> Maybe it didn’t need to; I don’t know. Perhaps we need
to formulate and
> write down a deprecation policy.
>
> Eric
>
>>
>> On 11/17/2011 12:03 PM, James Evans wrote:
>>>
>>> All,
>>>
>>> I have not touched the code for several months,
so it has taken me up
>>> until just now to realize that nxutils has been
removed from the build.
>>>
>>> I there any real reason for this? Particularly
when you consider that
>>> there are still functions present that use it
and now they just fail.
>>>
>>> In particular I am referring to
‘mlab.inside_poly’. In my case I was
>>> using ‘nxutils.points_inside_poly’ directly,
but the end result is the
>>> same.
>>>
>>> Thanks,
>>>
>>> --James Evans
>>>
>>>
>>>
>>>

        >>> All the data continuously generated in your IT

infrastructure
>>> contains a definitive record of customers,
application performance,
>>> security threats, fraudulent activity, and
more. Splunk takes this
>>> data and makes sense of it. IT sense. And
common sense.
>>> http://p.sf.net/sfu/splunk-novd2d
>>>
>>>
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Matplotlib-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>>
>>

        >> All the data continuously generated in your IT

infrastructure
>> contains a definitive record of customers,
application performance,
>> security threats, fraudulent activity, and more.
Splunk takes this
>> data and makes sense of it. IT sense. And common
sense.
>> http://p.sf.net/sfu/splunk-novd2d
>>
>>
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Matplotlib-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
>

        > All the data continuously generated in your IT

infrastructure
> contains a definitive record of customers, application
performance,
> security threats, fraudulent activity, and more. Splunk
takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

------------------------------------------------------------------------------

All the data continuously generated in your IT infrastructure

contains a definitive record of customers, application performance,

security threats, fraudulent activity, and more. Splunk takes this

data and makes sense of it. IT sense. And common sense.

http://p.sf.net/sfu/splunk-novd2d

_______________________________________________

Matplotlib-devel mailing list

Matplotlib-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

------------------------------------------------------------------------------

All the data continuously generated in your IT infrastructure

contains a definitive record of customers, application performance,

security threats, fraudulent activity, and more. Splunk takes this

data and makes sense of it. IT sense. And common sense.

http://p.sf.net/sfu/splunk-novd2d

_______________________________________________

Matplotlib-devel mailing list

Matplotlib-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/matplotlib-devel