Re: [Matplotlib-users] Undocumented transform API change between 1.1 and 1.2?
On Tue, Dec 18, 2012 at 2:05 PM, Darren Dale dsdal...@gmail.com wrote: On Mon, Dec 10, 2012 at 3:45 AM, Phil Elson pelson@gmail.com wrote: Thanks for bringing this up, it is certainly valuable to highlight this on the mailinglist. As you say, the change is hard to spot and, I agree, makes library code supporting v1.1.1 and v1.2 harder than one would like. Typically, anything which is going to break core APIs (even slightly) should be documented under the API Changes page here http://matplotlib.org/api/api_changes.html#changes-in-1-2-x I suggest that an API change should have triggered a major version bump to mpl-2.0.0. It seems a well-established expectation for a major.minor.bugfix versioning scheme that bugfix releases will not introduce new features, and minor releases will not introduce API changes. Darren Agreed. I think what happened here was short-sightedness (somewhat on my part since I was involved in that PR). I didn't realize this sort of situation when I reviewed it. This originally looked more like an enhancement that a more fundamental change. My apologies. Ben Root -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Undocumented transform API change between 1.1 and 1.2?
Is there anything we could do to give this important information a little more visibility on the webpage? The webpage still indicates that 1.2.0 is a development version. Oops. That's been updated. Perhaps we could update it to say: 1.2.0 The most current stable release. Click here to see what's new since 1.1.1 And have Click here link to the page Phil mentioned. Thoughts? I think I'm fine with this, but I'll hold off a bit on making this change in case there are better ideas raised. Cheers, Mike -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Undocumented transform API change between 1.1 and 1.2?
On Mon, Dec 10, 2012 at 3:45 AM, Phil Elson pelson@gmail.com wrote: Thanks for bringing this up, it is certainly valuable to highlight this on the mailinglist. As you say, the change is hard to spot and, I agree, makes library code supporting v1.1.1 and v1.2 harder than one would like. Typically, anything which is going to break core APIs (even slightly) should be documented under the API Changes page here http://matplotlib.org/api/api_changes.html#changes-in-1-2-x I suggest that an API change should have triggered a major version bump to mpl-2.0.0. It seems a well-established expectation for a major.minor.bugfix versioning scheme that bugfix releases will not introduce new features, and minor releases will not introduce API changes. Darren -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Undocumented transform API change between 1.1 and 1.2?
On Mon, Dec 10, 2012 at 6:27 PM, Joe Kington joferking...@gmail.com wrote: On Mon, Dec 10, 2012 at 2:45 AM, Phil Elson pelson@gmail.com wrote: Hi Joe, Thanks for bringing this up, it is certainly valuable to highlight this on the mailinglist. As you say, the change is hard to spot and, I agree, makes library code supporting v1.1.1 and v1.2 harder than one would like. Typically, anything which is going to break core APIs (even slightly) should be documented under the API Changes page here http://matplotlib.org/api/api_changes.html#changes-in-1-2-x . Thanks! I wasn't aware of that page! (and it does a very nice job of documenting the changes!) You will find there were quite a few changes made relating to transforms which I think is entirely my doing, so at least we know who the guilty party is :-) Thanks for spotting the example failure - I split these changes over many separate pull requests and did scan the gallery for any noticeable changes, but this one must have slipped the net. If you're still having problems with using the newer transform API, please shout and I'd be happy to have a look for you. Will do, thanks for the offer! All the best, Phil On 9 December 2012 22:10, Joe Kington joferking...@gmail.com wrote: Hi folks, At some point transforms.Transform was slightly refactored. (Particularly, this commit: https://github.com/matplotlib/matplotlib/commit/8bbe2e55f29b28ba558504b27596b8e36a087c1c ) This changed what methods need to be overridden when subclassing Transform. All in all, it seems like a very sensible change, but it led to some very hard-to-find bugs in some of my code that subclasses transforms.Transform. I thought I would mention it on the mailing list for anyone else that uses custom projections. Forgive me if it was mentioned earlier and I just didn't notice. With versions 1.1.x and older, one had to directly implement a transform method when subclassing transforms.Transform, otherwise a NotImplemented error would be raised. With versions 1.2.x and newer, the preferred way appears to be to implement things in a separate transform_affine or transform_non_affine method and not explicitly implement a transform method. If you implement the non-affine portion directly in the transform method without overriding transform_non_affine, it leads to strange drawing bugs with v1.2 that did not occur with older versions. (For example, this broke one of the examples in the gallery between 1.1. and 1.2: http://matplotlib.org/1.1.1/examples/api/custom_projection_example.html http://matplotlib.org/1.2.0/examples/api/custom_projection_example.html . I just submitted a pull request to update the example, by the way.) On the other hand, for compatibility with versions 1.1 and older, you have to explicitly implement the transform method as well, otherwise you'll get the NotImplemented error. Therefore, now one needs to explicitly implement _both_ the transform_non_affine and transform methods of a custom non-affine transform for compatibility with 1.1 and older as well as 1.2 and newer. Similarly, one needs to implement _both_ the transform_path_non_affine and the transform_path methods for compatibility with newer and older versions of matplotlib. Arguably, it should have always been done this way, but based on examples/api/custom_projection_example.py, I (and I suspect many other people as well) implemented the transform directly as the transform method when subclassing Transform, instead of separately in a transform_affine or transform_non_affine method. Is this a large enough change to warrant a mention in the changelog? (On the other hand, the mailing list probably gets a lot more eyes on it than the changelog...) Thanks! -Joe -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users Is there anything we could do to give this important information a little more visibility on the webpage? The webpage still indicates that 1.2.0 is a development version. Perhaps we could update it to say: 1.2.0 The most current stable release. Click here to see what's new since 1.1.1 And have Click here link to the page Phil mentioned. Thoughts? -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 -- LogMeIn
Re: [Matplotlib-users] Undocumented transform API change between 1.1 and 1.2?
On Mon, Dec 10, 2012 at 2:45 AM, Phil Elson pelson@gmail.com wrote: Hi Joe, Thanks for bringing this up, it is certainly valuable to highlight this on the mailinglist. As you say, the change is hard to spot and, I agree, makes library code supporting v1.1.1 and v1.2 harder than one would like. Typically, anything which is going to break core APIs (even slightly) should be documented under the API Changes page here http://matplotlib.org/api/api_changes.html#changes-in-1-2-x . Thanks! I wasn't aware of that page! (and it does a very nice job of documenting the changes!) You will find there were quite a few changes made relating to transforms which I think is entirely my doing, so at least we know who the guilty party is :-) Thanks for spotting the example failure - I split these changes over many separate pull requests and did scan the gallery for any noticeable changes, but this one must have slipped the net. If you're still having problems with using the newer transform API, please shout and I'd be happy to have a look for you. Will do, thanks for the offer! All the best, Phil On 9 December 2012 22:10, Joe Kington joferking...@gmail.com wrote: Hi folks, At some point transforms.Transform was slightly refactored. (Particularly, this commit: https://github.com/matplotlib/matplotlib/commit/8bbe2e55f29b28ba558504b27596b8e36a087c1c) This changed what methods need to be overridden when subclassing Transform. All in all, it seems like a very sensible change, but it led to some very hard-to-find bugs in some of my code that subclasses transforms.Transform. I thought I would mention it on the mailing list for anyone else that uses custom projections. Forgive me if it was mentioned earlier and I just didn't notice. With versions 1.1.x and older, one had to directly implement a transformmethod when subclassingtransforms.Transform, otherwise a NotImplemented error would be raised. With versions 1.2.x and newer, the preferred way appears to be to implement things in a separate transform_affine or transform_non_affinemethod and not explicitly implement a transform method. If you implement the non-affine portion directly in the transform method without overriding transform_non_affine, it leads to strange drawing bugs with v1.2 that did not occur with older versions. (For example, this broke one of the examples in the gallery between 1.1. and 1.2: http://matplotlib.org/1.1.1/examples/api/custom_projection_example.html http://matplotlib.org/1.2.0/examples/api/custom_projection_example.html. I just submitted a pull request to update the example, by the way.) On the other hand, for compatibility with versions 1.1 and older, you have to explicitly implement the transform method as well, otherwise you'll get the NotImplemented error. Therefore, now one needs to explicitly implement *_both_* the transform_non_affine and transform methods of a custom non-affine transform for compatibility with 1.1 and older as well as 1.2 and newer. Similarly, one needs to implement* _both_ *the transform_path_non_affineand the transform_path methods for compatibility with newer and older versions of matplotlib. Arguably, it should have always been done this way, but based onexamples/api/custom_projection_example.py, I (and I suspect many other people as well) implemented the transform directly as the transform method when subclassing Transform, instead of separately in a transform_affine or transform_non_affine method. Is this a large enough change to warrant a mention in the changelog? (On the other hand, the mailing list probably gets a lot more eyes on it than the changelog...) Thanks! -Joe -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
