Hi,
I've stumbled across an old application from 2007 which uses the old
matplotlib.transforms API, namely matplotlib.transforms.Value() which
obviously disappeared in a great transforms overhaul.
I tried to figure out what has become of these classes and functions
browsing the changelog and SVN, without success - there doesn't seem to
be a successor to these classes.
As I would love to tweak that particular application to make it
work again: could someone enlighten me what has become of
matplotlib.transforms.Value() and how to replace the functionality?
Thanks a ton!
Florian
There is a guide about porting from the old transforms to the new transforms here:
http://matplotlib.sourceforge.net/api/api_changes.html#notes-about-the-transforms-refactoring
Mike
···
On 06/24/2010 01:53 PM, Florian Berger wrote:
Hi,
I've stumbled across an old application from 2007 which uses the old
matplotlib.transforms API, namely matplotlib.transforms.Value() which
obviously disappeared in a great transforms overhaul.
I tried to figure out what has become of these classes and functions
browsing the changelog and SVN, without success - there doesn't seem to
be a successor to these classes.
As I would love to tweak that particular application to make it
work again: could someone enlighten me what has become of
matplotlib.transforms.Value() and how to replace the functionality?
Thanks a ton!
Florian
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options
--
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA
It's possible I'm missing something, but I don't see
matplotlib.transforms.Value() or anything remotely resembling it
mentioned there. I have no idea what the original method did, so I'm
not sure if this an omission or if I'm just dense.
Ryan
···
On Thu, Jun 24, 2010 at 1:11 PM, Michael Droettboom <mdroe@...86...> wrote:
There is a guide about porting from the old transforms to the new
transforms here:
http://matplotlib.sourceforge.net/api/api_changes.html#notes-about-the-transforms-refactoring
--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Hi,
Ryan May <rmay31@...287...>:
> There is a guide about porting from the old transforms to the new
> transforms here:
>
> http://matplotlib.sourceforge.net/api/api_changes.html#notes-about-the-transforms-refactoring
It's possible I'm missing something, but I don't see
matplotlib.transforms.Value() or anything remotely resembling it
mentioned there.
Same with me. 
Michael, I've checked the very document and just like
Ryan I couldn't find any hint of what had become of that functionality.
Here is a diff of transforms.py before and after the refactoring:
On the left side you see that Value() has been featured quite
distinctively. After the refactoring there doesn't seem to be anything
left of it. To a newbie like me this is striking, as it seems to be a
major change in the API. I thus hoped it probably could have been moved
to another module or something like this.
Still glad about any enlightenments.
Best,
Florian
···
Michael Droettboom <mdroe@...86...> wrote:
Hi,
Ryan May<rmay31@...287...>:
There is a guide about porting from the old transforms to the new
transforms here:
http://matplotlib.sourceforge.net/api/api_changes.html#notes-about-the-transforms-refactoring
It's possible I'm missing something, but I don't see
matplotlib.transforms.Value() or anything remotely resembling it
mentioned there.
Same with me. Michael, I've checked the very document and just like
Ryan I couldn't find any hint of what had become of that functionality.
Here is a diff of transforms.py before and after the refactoring:
matplotlib download | SourceForge.net
On the left side you see that Value() has been featured quite
distinctively. After the refactoring there doesn't seem to be anything
left of it. To a newbie like me this is striking, as it seems to be a
major change in the API. I thus hoped it probably could have been moved
to another module or something like this.
It was *such* a major change that Value and its ilk were completely replaced, not moved aside. Value was a lazy value. The original transforms system was based on lazy evaluation of expressions, for the sake of efficiency. (The new transforms system achieves the same sort of efficiency but in a more general and extensible framework.)
To port code, you really have to look not for replacements for things like Value, but for how the structure changed so that they are not needed. Essentially, you have to look at one level higher than the Value level--look at what you were trying to do with the code, not at how you implemented it via Value. Unless you were using Value et al for your own purposes, rather than in Bbox etc, looking at this higher level should take you straight to the translations in the table that Mike made to help guide the transition.
Eric
···
On 06/24/2010 11:07 AM, Florian Berger wrote:
Michael Droettboom<mdroe@...86...> wrote:
Still glad about any enlightenments.
Best,
Florian
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options
Hi,
Eric Firing <efiring@...202...>:
It was *such* a major change that Value and its ilk were completely
replaced, not moved aside.
Thanks, I feared as much.
look at what you were trying to do with the code, not at how you
implemented it via Value.
Well the thing is that *I* did not try anything, as it is third party
code. So I fear I have to figure out why the original author found
Value() so appealing. *sigh*
Unless you were using Value et al for your own purposes [...]
I think that is what he did. :-/
Anyway, thanks for the clarification!
Best,
Florian
Hi,
Eric Firing<efiring@...202...>:
It was *such* a major change that Value and its ilk were completely
replaced, not moved aside.
Thanks, I feared as much.
look at what you were trying to do with the code, not at how you
implemented it via Value.
Well the thing is that *I* did not try anything, as it is third party
code. So I fear I have to figure out why the original author found
Value() so appealing. *sigh*
Unless you were using Value et al for your own purposes [...]
I think that is what he did. :-/
At least for those applications, you might be able to go back to an earlier mpl version, pull out the c++ code and the wrappers for Value, BinOp, etc., and turn them into an independent extension. That might be worthwhile if you have a *lot* of third-party code that is using those things extensively in ways not tied to mpl. I suspect it would not be very difficult. It's a long time since I looked at that code, though.
Eric
···
On 06/24/2010 11:57 AM, Florian Berger wrote:
Anyway, thanks for the clarification!
Best,
Florian