matplotlib-devel Mailing List for matplotlib (Page 2)

On 3/21/07, Eric Firing <ef...@ha...> wrote:
> Properties would be OK for 2.3; I was thinking we might want to use
> them. When a getter and setter already exist, all it takes is the one
> extra line of code, plus a suitable (unused) name for the property. I
> decided not to pursue traits (if at all) until we can use the Enthought
> package as-is. But I think that properties could be converted to traits
> very easily if we wanted to do that in the future, so starting with
> properties would not be wasted effort. This is getting a bit off-topic,
> though.
Minor note: if you are going to use properties, make sure all classes
using them are new-style (inherit from object). With old-style
classes, properties fail in silent and mysterious ways that may lead
to much head-scratching.
As far as I can see, it is not currently the case in lines.py (where
Line2D inherits from Artist, which is an old-style class).
agg.py, which makes extensive use of property(), has it properly
wrapped in the following:
import types
try:
 _object = types.ObjectType
 _newclass = 1
except AttributeError:
 class _object : pass
 _newclass = 0
del types
and then all calls to property() are of the form:
 if _newclass:x = property(_agg.point_type_x_get, _agg.point_type_x_set)
Currently the only two files I see using property() are agg.py and
lines.py; once artist.py is fixed to be new-style, things should be
fine.
And yes, properties are actually OK even with 2.2, so there's no
reason to avoid them (and they do provide a nicer, claner user API).
Decorators are 2.4-only though.
Cheers,
f

> 
> And I've gotten the units.py module down to a digestable 105 lines of
> code!
You must have done more work after writing your message--now wc reports 
only 87 lines!
Thanks for all the explanations (I am gradually coming around...) and 
additional work.
Minor points from a quick look at axes.py: a line in spy() got 
regressed, so I restored it (svn rev 3114); and **kwargs got added to 
the signatures of set_xlim and set_ylim, but they are not being 
used--all valid kwargs are explicit. I left this alone because maybe 
you are planning to pass kwargs through later.
> 
> See if you find the new interface less onerous. There is still work
> to do if we want to support this kind of thing -- one of the hard
> parts is to modify the various plotting functions to try and get the
> original data into the primitive objects, which the current approach
> is building around.
Looks promising. I see the problem, as in the example you pointed out 
with plotting multiple columns, but I don't have any suggestions yet.
> 
> I've also gotten rid of all the decorators and properties. The code
> is not python2.3 compatible.
Properties would be OK for 2.3; I was thinking we might want to use 
them. When a getter and setter already exist, all it takes is the one 
extra line of code, plus a suitable (unused) name for the property. I 
decided not to pursue traits (if at all) until we can use the Enthought 
package as-is. But I think that properties could be converted to traits 
very easily if we wanted to do that in the future, so starting with 
properties would not be wasted effort. This is getting a bit off-topic, 
though.
Aha! Now I see that lines.py still has a few properties but they are 
private.
Eric

On 3/20/07, Norbert Nemec <Nor...@gm...> wrote:
> I agree, though, that the units package itself should not be part of
> matplotlib. But this is exactly
> how I understand the idea by John Hunter: describe an interface to allow
> the use of any third-party
> unit package.
That's exactly right -- we are not providing a units package and have
no intention of providing one. What this implementation is providing
is an interface that one can use with any units package, either a
publicly released one or a home grown one. Whether the interface is
robust enough to handle real world package remains to be seen with
further use and testing -- this is a first cut at it.
The basic_units package in examples/units was developed for
prototyping and testing, and was not meant to be the foundation of a
real units package. matplotlib.units.UnitConverter describes the
basic interface a unit converter class must expose.
> Of course, the whole thing only makes sense is there is a units package
> that is fit for production use.
Well, one can still use it to support home grown units, even if they
aren't production ready. And as the example date_converter.py shows,
the same framework works well for plotting custom types even if unit
conversion is not needed.
I think your suggestion of supporting default axis labels is also a
good one -- the current implementation supports tick labeling an
formatting and axis labeling is a natural target for unit handling
also.
JDH

On 3/20/07, Eric Firing <ef...@ha...> wrote:
> You accidentally whacked out the new Axes.matshow, so I put it back.
Oops, sorry.
> I also noticed a few decorators--gasp!--in axes.py. I presume you will
> want them replaced by old-style syntax to preserve 2.3 compatibility,
> but I will leave that to you. (After about the 10th or so time of
> reading a bit about decorators, I think I understand them enough for
> simple use cases; apart from that ugly and utterly unpythonic @ symbol,
> maybe they are not as bad as I thought.)
>
> The curmudgeon in me has to wonder whether the snazzy unit support is
> really a good thing; this is partly a question of where the boundary of
> a plotting library should be. The simpler view (classic mpl) is that
> the role of mpl is to do a good job plotting numbers and labeling
> things, and the role of the user or application programmer is to supply
> the numbers and labels. I am not sure that enough is gained by enabling
> unit conversion and automatic axis labeling inside a plot command to
> compensate for the added complexity. My hesitation probably reflects
> the facts (1) that I don't see any *compelling* use cases in the sort
> of work I do, (2) I am not familiar with whatever use cases motivated
> this, (3) I haven't thought about it much yet, and (4) I may be a bit
> unimaginative.
>
> I will try to take a closer look, both at the changes and at the
> questions you raise in your message, tomorrow.
I too have been concerned by the complexity of this implementation --
I think it is trying to support too many paradigms, for example,
sequences of hetergeneous units. I have dramatically simplified the
code, and moved almost everything out of Axes. I have also made
"units" an rc param so that if units is not enabled, there is a dummy
do nothing units manager so you'll only pay for a few extra do nothing
function calls. Take a look at the code again when you get a minute,
I think you'll be more satisfied at the reduced complexity.
I've also cleaned up the examples to hopefully make clearer the
potential use cases. Eg, for radian plotting
 from basic_units import radians, degrees
 from pylab import figure, show, nx
 x = nx.arange(0, 15, 0.01) * radians
 fig = figure()
 ax = fig.add_subplot(211)
 ax.plot(x, nx.cos(x), xunits=radians)
 ax.set_xlabel('radians')
 ax = fig.add_subplot(212)
 ax.plot(x, nx.cos(x), xunits=degrees)
 ax.set_xlabel('degrees')
 show()
and see attached screenshot. One of the things this implementation
buys you is the units writer can provide a mapping from types to
locators and formatters -- notice in the attached screenshot how you
get the fancy tick locating and formatting. This enables a matplotlib
application developer to alter the default ticking and formatting
outside of the code base.
Here is another use case, working with native datetimes -- note that
we get to use native dates in plot and set_xlim
 import date_support # set up the date converters
 import datetime
 from pylab import figure, show, nx
 xmin = datetime.date(2007,1,1)
 xmax = datetime.date.today()
 xdates = [xmin]
 while 1:
 thisdate = xdates[-1] + datetime.timedelta(days=1)
 xdates.append(thisdate)
 if thisdate>=xmax: break
 fig = figure()
 fig.subplots_adjust(bottom=0.2)
 ax = fig.add_subplot(111)
 ax.plot(xdates, nx.mlab.rand(len(xdates)), 'o')
 ax.set_xlim(datetime.date(2007,2,1), datetime.date(2007,3,1))
 for label in ax.get_xticklabels():
 label.set_rotation(30)
 label.set_ha('right')
 show()
Some of the features were inspired by some real use cases that the JPL
has encountered in developing their monty application for ground
tracking of orbiting spacecraft. The basic problem is this. Imagine
you are a large C++ shop with a lot of legacy code and a python
interface, and you've decided to jettison your internal plotting
library for matplotlib. Your users work at a enhanced python shell
and have all of the legacy functionality and objects and want to so
something like
>>> plot(o)
where o is one of these legacy objects. They may not know a lot of
matplotlib, but can do plot. Asking them to learn about tickers and
formatters and conversion to arrays etc may be a non-starter for many
of these users. You could wrap all of the bits of matplotlib that you
need and do the conversion under the hood for your users, but then you
will always be trying to keep up with the mpl changes. You can't
really change the objects to suit mpl because too much legacy code
depends on them. What the proposed changes allow the developer to do
is write a converter class and register their types with a unit
manager and mpl will do the conversions in the right place. In the
current implementation (heavily revised) this happens when the Axes
adds the artist to itself, which provides a finite number of points of
entry.
Here is what the converter code in date_support in the units example
directory (used in the demo above). Note that this pretty much
replaces all of the current plot_date functionality, but happens
outside mpl and doesn't require the user to think about date2num
 import matplotlib
 matplotlib.rcParams['units'] = True
 import matplotlib.units as units
 import matplotlib.dates as dates
 import matplotlib.ticker as ticker
 import basic_units
 import datetime
 class DateConverter(units.ConversionInterface):
 def tickers(x, unit=None):
 'return major and minor tick locators and formatters'
 majloc = dates.AutoDateLocator()
 minloc = ticker.NullLocator()
 majfmt = dates.AutoDateFormatter(majloc)
 minfmt = ticker.NullFormatter()
 return majloc, minloc, majfmt, minfmt
 tickers = staticmethod(tickers)
 def convert_to_value(value, unit):
 return dates.date2num(value)
 convert_to_value = staticmethod(convert_to_value)
 units.manager.converters[datetime.date] = DateConverter()
And I've gotten the units.py module down to a digestable 105 lines of
code!
I haven't finished porting all of the artists yet, eg there is work
left to do in collections and text, but lines, patches and regular
polygon collections are working, and there are more examples.
See if you find the new interface less onerous. There is still work
to do if we want to support this kind of thing -- one of the hard
parts is to modify the various plotting functions to try and get the
original data into the primitive objects, which the current approach
is building around.
I've also gotten rid of all the decorators and properties. The code
is not python2.3 compatible.
JDH

FYI The unit system John is working on will be a huge improvement for 
the way we use MPL. Our users do a ton of plotting that involves 
unitized numbers vs time. We have our own unit class and time class 
and right now users have to convert the unitized numbers into floats 
in the correct units and convert the times to the correct MPL format 
in the correct reference frame. Being able to seamlessly pass these 
objects to MPL is going to make all of our plotting scripts much 
simpler to use, easier to understand, and much safer (by eliminating 
different unit/time frame problems).
It's not a big deal to convert values when the plot is first created 
- where it makes the biggest difference is when you want to 
manipulate the plot after it's created (xlim for example). Being 
able to pass unitized numbers to the various manipulation methods is 
what makes everything much easier to use (especially when dates are 
being plotted).
Ted
At 02:15 PM 3/20/2007, Norbert Nemec wrote:
>Actually, I like the idea of unit support quite a bit and could well
>imagine that it makes sense
>to support it explicitely in matplotlib.
>
>I am using physical units very frequently in my computations. Lacking a
>robust units package,
>I simply define the units as numerical constants without checks but at
>least with comfortable
>conversion. If there were a good units package, support in matplotlib
>would mean that the axis
>labels could automatically be completed with appropriate units without
>need for explicit conversion.
>
>I agree, though, that the units package itself should not be part of
>matplotlib. But this is exactly
>how I understand the idea by John Hunter: describe an interface to allow
>the use of any third-party
>unit package.
>
>Of course, the whole thing only makes sense is there is a units package
>that is fit for production use.
>
>
>
>Darren Dale wrote:
> >
> > My first impression is similar to Eric's. I don't know if there 
> is a robust
> > units package for python, but I imagine it should be a part of 
> scipy. I think
> > it would be better to get an array and if you wanted to plot it 
> in different
> > units, you call a method on the array at plot time. Maybe I dont 
> understand
> > all the intended uses.
> >
> > Darren
> >
> >
>
>
>-------------------------------------------------------------------------
>Take Surveys. Earn Cash. Influence the Future of IT
>Join SourceForge.net's Techsay panel and you'll get the chance to share your
>opinions on IT & business topics through brief surveys-and earn cash
>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>_______________________________________________
>Matplotlib-devel mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Actually, I like the idea of unit support quite a bit and could well 
imagine that it makes sense
to support it explicitely in matplotlib.
I am using physical units very frequently in my computations. Lacking a 
robust units package,
I simply define the units as numerical constants without checks but at 
least with comfortable
conversion. If there were a good units package, support in matplotlib 
would mean that the axis
labels could automatically be completed with appropriate units without 
need for explicit conversion.
I agree, though, that the units package itself should not be part of 
matplotlib. But this is exactly
how I understand the idea by John Hunter: describe an interface to allow 
the use of any third-party
unit package.
Of course, the whole thing only makes sense is there is a units package 
that is fit for production use.
Darren Dale wrote:
>
> My first impression is similar to Eric's. I don't know if there is a robust 
> units package for python, but I imagine it should be a part of scipy. I think 
> it would be better to get an array and if you wanted to plot it in different 
> units, you call a method on the array at plot time. Maybe I dont understand 
> all the intended uses.
>
> Darren
>
> 

On Tuesday 20 March 2007 3:50:07 am Eric Firing wrote:
> John Hunter wrote:
> > If you are using mpl svn, please read this as it describes
> > some fairly major changes.
> >
> > Mike Lusignan has been working on adding units support, and as a
> > consequence, partial support for working with arbitrary types in mpl.
> > The support is not complete yet, but it is basically working and
> > compatible with the rest of mpl, so I thought now would be a good time
> > to integrate it into the svn HEAD (he's been working in a branch)
> > and get some more eyeballs on it.
>
> John,
>
> You accidentally whacked out the new Axes.matshow, so I put it back.
>
> I also noticed a few decorators--gasp!--in axes.py. I presume you will
> want them replaced by old-style syntax to preserve 2.3 compatibility,
> but I will leave that to you. (After about the 10th or so time of
> reading a bit about decorators, I think I understand them enough for
> simple use cases; apart from that ugly and utterly unpythonic @ symbol,
> maybe they are not as bad as I thought.)
>
> The curmudgeon in me has to wonder whether the snazzy unit support is
> really a good thing; this is partly a question of where the boundary of
> a plotting library should be. The simpler view (classic mpl) is that
> the role of mpl is to do a good job plotting numbers and labeling
> things, and the role of the user or application programmer is to supply
> the numbers and labels. I am not sure that enough is gained by enabling
> unit conversion and automatic axis labeling inside a plot command to
> compensate for the added complexity. My hesitation probably reflects
> the facts (1) that I don't see any *compelling* use cases in the sort
> of work I do, (2) I am not familiar with whatever use cases motivated
> this, (3) I haven't thought about it much yet, and (4) I may be a bit
> unimaginative.
My first impression is similar to Eric's. I don't know if there is a robust 
units package for python, but I imagine it should be a part of scipy. I think 
it would be better to get an array and if you wanted to plot it in different 
units, you call a method on the array at plot time. Maybe I dont understand 
all the intended uses.
Darren
-- 
Darren S. Dale, Ph.D.
dd...@co...

John Hunter wrote:
> If you are using mpl svn, please read this as it describes
> some fairly major changes.
> 
> Mike Lusignan has been working on adding units support, and as a
> consequence, partial support for working with arbitrary types in mpl.
> The support is not complete yet, but it is basically working and
> compatible with the rest of mpl, so I thought now would be a good time
> to integrate it into the svn HEAD (he's been working in a branch)
> and get some more eyeballs on it.
John,
You accidentally whacked out the new Axes.matshow, so I put it back.
I also noticed a few decorators--gasp!--in axes.py. I presume you will 
want them replaced by old-style syntax to preserve 2.3 compatibility, 
but I will leave that to you. (After about the 10th or so time of 
reading a bit about decorators, I think I understand them enough for 
simple use cases; apart from that ugly and utterly unpythonic @ symbol, 
maybe they are not as bad as I thought.)
The curmudgeon in me has to wonder whether the snazzy unit support is 
really a good thing; this is partly a question of where the boundary of 
a plotting library should be. The simpler view (classic mpl) is that 
the role of mpl is to do a good job plotting numbers and labeling 
things, and the role of the user or application programmer is to supply 
the numbers and labels. I am not sure that enough is gained by enabling 
unit conversion and automatic axis labeling inside a plot command to 
compensate for the added complexity. My hesitation probably reflects 
the facts (1) that I don't see any *compelling* use cases in the sort 
of work I do, (2) I am not familiar with whatever use cases motivated 
this, (3) I haven't thought about it much yet, and (4) I may be a bit 
unimaginative.
I will try to take a closer look, both at the changes and at the 
questions you raise in your message, tomorrow.
Eric

If you are using mpl svn, please read this as it describes
some fairly major changes.
Mike Lusignan has been working on adding units support, and as a
consequence, partial support for working with arbitrary types in mpl.
The support is not complete yet, but it is basically working and
compatible with the rest of mpl, so I thought now would be a good time
to integrate it into the svn HEAD (he's been working in a branch)
and get some more eyeballs on it.
The code base is a little complicated and daunting at first, but we
are working to try and simplify it and refactor it so the main
functionality is minimally invasive into the rest of the code base.
Right now it is somewhat distributed among units, figure, axes,
artist, lines, patched, etc, but will be consolidated in the upcoming
week(s). Not all of the plotting functions support units, but the
examples show some with scatter and plot.
The documentation is in matplotlib.units. We do not assume any
particular units package, we only require that package to provide
a certain interface. Alternatively, one can use a units type that doesn't
have the required interface as long as you register some adaptors with
the figure. More on this later. Mike also provided a mockup units package
in the examples/units dir called basic_unit.py to test and demo the support.
I ran into a little problem today in trying to reconcile Eric's work
supporting multicolumn y data with the unit support for arbitrary
types. The basic tension is in _process_plot_var_args._xy_from_xy and
friends which simplfies the array column logic by forcing all inputs
to have a array.shape==2 using some conversion functions. The problem
is this strips out the units tagging Mike is relying on (in the
current implementation he needs _xorig in Line2D to be the original
data type). This is a fairly important question that
requires some thought: do we want mpl objects to store original data
objects as long as they know how to convert themselves under the hood
to something useful when requested (eg Text now supports any object
that supports '%s'%o. I think if we could support this generally,
that is the ideal, because it let's users use mpl with custom objects,
possibly from 3rd party closed src vendors, as long as the objects
expose the right interface. It's also useful for picking, where you
might want to store your custom objects and arrays in mpl and query
them later. If we lose access to the orginal data when constructing
our objects, we lose this ability. That said, we are fairly far from
achieving this goal globally.
I did a quick-and-dirty hack in process_plot_var_args for the time
being to get something everyone can chew on, which is to use the
existing approach if the data are indeed multicolumn, but use the
original x and y data otherwise. We'll come up with something more
general and elegant shortly.
backend_driver is passing in my local repository, and the units
examples are passing as well, and I thought this is sufficient
progress that it merits getting the merge done now and getting more
testers on this. I expect there will be some breakage
and performance hits, and we can fix these as they arise.
The new examples are in examples/units -- a couple of screenshot
of the example below is attached.
Thanks Mike!
JDH
import matplotlib
matplotlib.rcParams['numerix'] = 'numpy'
import basic_units as bu
import numpy as N
from pylab import figure, show
from matplotlib.cbook import iterable
cm = bu.BasicUnit('cm', 'centimeters')
inch = bu.BasicUnit('inch', 'inches')
inch.add_conversion_factor(cm, 2.54)
cm.add_conversion_factor(inch, 1/2.54)
lengths_cm = cm*N.arange(0, 10, 0.5)
# iterator test
print 'Testing iterators...'
for length in lengths_cm:
 print length
print 'Iterable() = ' + `iterable(lengths_cm)`
print 'cm', lengths_cm
print 'toinch', lengths_cm.convert_to(inch)
print 'toval', lengths_cm.convert_to(inch).get_value()
fig = figure()
ax1 = fig.add_subplot(2,2,1)
ax1.plot(lengths_cm, 2.0*lengths_cm, xunits=cm, yunits=cm)
ax1.set_xlabel('in centimeters')
ax1.set_ylabel('in centimeters')
ax2 = fig.add_subplot(2,2,2)
ax2.plot(lengths_cm, lengths_cm, xunits=cm, yunits=inch)
ax2.set_xlabel('in centimeters')
ax2.set_ylabel('in inches')
ax3 = fig.add_subplot(2,2,3)
ax3.plot(lengths_cm, 2.0*lengths_cm, xunits=inch, yunits=cm)
ax3.set_xlabel('in inches')
ax3.set_ylabel('in centimeters')
ax4 = fig.add_subplot(2,2,4)
ax4.plot(lengths_cm, 2.0*lengths_cm, xunits=inch, yunits=inch)
ax4.set_xlabel('in inches')
ax4.set_ylabel('in inches')
fig.savefig('simple_conversion_plot.png')
show()

Ted Drain <ted...@pu...> writes:
> I'm trying to build matplotlib and basemap on a solaris box using the 
> latest SVN. My python, qt, tk, etc are all installed in a build 
> directory ($TOOLS). Under linux, the build goes fine and everything 
> works great. However, under solaris, both matplotlib and basemap 
> have link errors that say they can't find the python shared library 
> which is at $TOOLS/lib. Under linux, this shows up in the link line 
> as -L$TOOLS/lib but is missing on solaris.
>
> I'm trying to figure out how I can add -L$TOOLS/lib to the link 
> line. For matplotlib, I was able to just hand copy the error message 
> to the command line, add -L$TOOLS/lib, and rerun 'python setup.py 
> build' to get it to work. This doesn't work for basemap though as it 
> seems to generate some intermediate files that are needed.
how about 
 # LD_LIBRARY_PATH=$TOOLS/lib:LD_LIBRARY_PATH LD_RUN_PATH=$TOOLS/lib:LD_LIBRARY_PATH python setup.py build
Regards
Berthold
-- 

I'm trying to build matplotlib and basemap on a solaris box using the 
latest SVN. My python, qt, tk, etc are all installed in a build 
directory ($TOOLS). Under linux, the build goes fine and everything 
works great. However, under solaris, both matplotlib and basemap 
have link errors that say they can't find the python shared library 
which is at $TOOLS/lib. Under linux, this shows up in the link line 
as -L$TOOLS/lib but is missing on solaris.
I'm trying to figure out how I can add -L$TOOLS/lib to the link 
line. For matplotlib, I was able to just hand copy the error message 
to the command line, add -L$TOOLS/lib, and rerun 'python setup.py 
build' to get it to work. This doesn't work for basemap though as it 
seems to generate some intermediate files that are needed.
I edited setup.py to do this:
import sys
basedir[sys.platform] = [ os.environ['TOOLS' ] ]
which seems to have worked on linux but doesn't seem to work on 
solaris. I google'ed to try and figure out how to add a link option 
using distutils and found something that said to do this:
python setup.py build build_ext -n -L$TOOLS/lib
but that doesn't build all the necessary components so my 
installation ends up not working.
Does anyone know an easy way to add this link dir to the distutils build?
Thanks,
Ted
Ted Drain Jet Propulsion Laboratory ted...@jp... 

I made some commits to svn last night to support clipping to arbitrary
paths last night -- they work is still in development, but some of the
compile *agg backends may be out of whack since the compile
dependencies aren't always respected.
If you see something funny with svn, try a clean recompile.
JDH

"Edin Salkovic"
<edi...@pu...> writes:
> Hi Berthold,
>
> Try running some of the examples:
> http://matplotlib.sourceforge.net/matplotlib_examples_0.90.0.zip
>
> This is mpl's test suite.
Testting should possibly done with the "-tt" or at least the "-t"
command line switch to identify inconsistent use of tabs and spaces in
indentations. My library tests run with the "-tt" switch and fail in
some matplotlib modules.
Kind regards
Berthold H=F6llmann
--=20
Germanischer Lloyd AG
CAE Development
Vorsetzen 35
20459 Hamburg
Phone: +49(0)40 36149-7374
Fax: +49(0)40 36149-7320
e-mail: ber...@gl...
Internet: http://www.gl-group.com
This e-mail and any attachment thereto may contain confidential =
information and/or information protected by intellectual property rights =
for the exclusive attention of the intended addressees named above. Any =
access of third parties to this e-mail is unauthorised. Any use of this =
e-mail by unintended recipients such as total or partial copying, =
distribution, disclosure etc. is prohibited and may be unlawful. When =
addressed to our clients the content of this e-mail is subject to the =
General Terms and Conditions of GL's Group of Companies applicable at =
the date of this e-mail.=20
If you have received this e-mail in error, please notify the sender =
either by telephone or by e-mail and delete the material from any =
computer.
GL's Group of Companies does not warrant and/or guarantee that this =
message at the moment of receipt is authentic, correct and its =
communication free of errors, interruption etc.=20
Germanischer Lloyd AG, 31393 AG HH, Hamburg, Vorstand: Dr. Hermann J. =
Klein, Rainer Sch=F6ndube, Vorsitzender des Aufsichtsrats: Dr. Wolfgang =
Peiner

John Hunter wrote:
> On 3/17/07, Eric Firing <ef...@ha...> wrote:
>> In response to the feature request:
>>
>> Does anyone see any disadvantage to making Text.__init__ and
>> Text.set_text() either try to call the __str__ method, or use the str()
>> builtin, if passed an argument that is not a string? Maybe there is no
>> need to even check--just automatically use str(arg)? Offhand, this
>> looks to me like it would provide a gain in convenience and
>> intuitiveness with no pain.
> 
> My concern is that we don't break unicode support , so if you come up
> with a solution that supports calling str but doesn't break unicode,
> it's fine by me
> 
> 
> In [2]: x = unicode('D351円velopp351円s et fabriqu351円s', 'latin-1')
> 
> In [3]: x
> Out[3]: u'D\xe9velopp\xe9s et fabriqu\xe9s'
Looks like the simplest thing is
arg = '%s' % (arg,)
I'll give that a try.
Eric
> 
> In [4]: str(x)
> ---------------------------------------------------------------------------
> exceptions.UnicodeEncodeError Traceback (most
> recent call last)
> 
> /Users/jdhunter/<ipython console>
> 
> UnicodeEncodeError: 'ascii' codec can't encode character '\ue9' in
> position 1: ordinal not in range(128)

On 3/17/07, Eric Firing <ef...@ha...> wrote:
> In response to the feature request:
>
> Does anyone see any disadvantage to making Text.__init__ and
> Text.set_text() either try to call the __str__ method, or use the str()
> builtin, if passed an argument that is not a string? Maybe there is no
> need to even check--just automatically use str(arg)? Offhand, this
> looks to me like it would provide a gain in convenience and
> intuitiveness with no pain.
My concern is that we don't break unicode support , so if you come up
with a solution that supports calling str but doesn't break unicode,
it's fine by me
In [2]: x = unicode('D351円velopp351円s et fabriqu351円s', 'latin-1')
In [3]: x
Out[3]: u'D\xe9velopp\xe9s et fabriqu\xe9s'
In [4]: str(x)
---------------------------------------------------------------------------
exceptions.UnicodeEncodeError Traceback (most
recent call last)
/Users/jdhunter/<ipython console>
UnicodeEncodeError: 'ascii' codec can't encode character '\ue9' in
position 1: ordinal not in range(128)

In response to the feature request:
Does anyone see any disadvantage to making Text.__init__ and 
Text.set_text() either try to call the __str__ method, or use the str() 
builtin, if passed an argument that is not a string? Maybe there is no 
need to even check--just automatically use str(arg)? Offhand, this 
looks to me like it would provide a gain in convenience and 
intuitiveness with no pain.
Eric

SGkgQmVydGhvbGQsCgpUcnkgcnVubmluZyBzb21lIG9mIHRoZSBleGFtcGxlczoKaHR0cDovL21h
dHBsb3RsaWIuc291cmNlZm9yZ2UubmV0L21hdHBsb3RsaWJfZXhhbXBsZXNfMC45MC4wLnppcAoK
VGhpcyBpcyBtcGwncyB0ZXN0IHN1aXRlLgoKQ2hlZXJzLApFZGluCgpPbiAzLzE2LzA3LCBCZXJ0
aG9sZCBIw7ZsbG1hbm4gPGJob2VsQGRlc3BhbW1lZC5jb20+IHdyb3RlOgo+IEtlbiBNY0l2b3Ig
PG1jaXZvckBpaXQuZWR1PiB3cml0ZXM6Cj4KPiA+IE9uIE1hciAxNiwgMjAwNywgYXQgOToyOCBB
TSwgQmVydGhvbGQgSMO2bGxtYW5uIHdyb3RlOgo+ID4+Cj4gPj4gSSBuZWVkIGEgcHl0aG9uIGNv
bXBpbGUgd2l0aCBWQzYuICBUaGlzIHB5dGhvbiBhbHNvIG5lZWRzIGEKPiA+PiBtYXRwbG90bGli
Lgo+ID4KPiA+IENocmlzIEJhcmtlciBhbmQgSSB3b3JrZWQgb24gdGhpcyBhIHdoaWxlIGFnbywg
YW5kIEkgYmVsaWV2ZSB3ZQo+ID4gZGVjaWRlZCBpdCB3YXMgaW1wb3NzaWJsZSBkdWUgdG8gYnVn
cy9saW1pdGF0aW9ucyBpbiB0aGUgVkMrKyA2Cj4gPiBjb21waWxlci4KPgo+IElzIHRoZXJlIGFu
eSB0ZXN0c3VpdGUgZm9yIG1hdHBsb3RsaWIuIEkgZGVjaWRlZCB0byBpbnN0YWxsIHRoZQo+IGRv
d25sb2FkYWJsZSBtYXRwbG90bGliIGVnZyAocHJlc3VtYWJseSBjb21waWxlZCB1c2luZyBWQzcp
IGludG8gbXkKPiBWQzYgcHl0aG9uIGFuZCB0aGUgZmlyc3Qgc2FtcGxlcyBmcm9tIHRoZSBtYXRw
bG90bGliIHR1dG9yaWFsIHBhZ2UKPiB3aGljaCBzZWVtIHRvIHdvcmsuIEkgd291bGQgbGlrZSB0
byBkbyBzb21lIG1vcmUgdGhvcm91Z2hseSB0ZXN0aW5nLgo+IElzIHRoZXJlIGFueXRoaW5nIHJl
Y29tbWVuZGVkPwo+Cj4gUmVnYXJkcwo+IEJlcnRob2xkCj4gLS0KPgo+Cj4gLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLQo+IFRha2UgU3VydmV5cy4gRWFybiBDYXNoLiBJbmZsdWVuY2UgdGhlIEZ1dHVyZSBvZiBJ
VAo+IEpvaW4gU291cmNlRm9yZ2UubmV0J3MgVGVjaHNheSBwYW5lbCBhbmQgeW91J2xsIGdldCB0
aGUgY2hhbmNlIHRvIHNoYXJlIHlvdXIKPiBvcGluaW9ucyBvbiBJVCAmIGJ1c2luZXNzIHRvcGlj
cyB0aHJvdWdoIGJyaWVmIHN1cnZleXMtYW5kIGVhcm4gY2FzaAo+IGh0dHA6Ly93d3cudGVjaHNh
eS5jb20vZGVmYXVsdC5waHA/cGFnZT1qb2luLnBocCZwPXNvdXJjZWZvcmdlJkNJRD1ERVZERVYK
PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IE1hdHBs
b3RsaWItZGV2ZWwgbWFpbGluZyBsaXN0Cj4gTWF0cGxvdGxpYi1kZXZlbEBsaXN0cy5zb3VyY2Vm
b3JnZS5uZXQKPiBodHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9t
YXRwbG90bGliLWRldmVsCj4K

On Mar 16, 2007, at 4:24 PM, Berthold H=F6llmann wrote:
>
> Applying the following patch current matplotlib SVN compiles against
> wxPython 2.8.1.1. The resulting module seems to work.
That test is present in setupext.pu because I don't intend to support =20=
the C++ WXAgg accelerator module with wxPython 2.8 and later.
Ken=

Applying the following patch current matplotlib SVN compiles against
wxPython 2.8.1.1. The resulting module seems to work.
Kind regads
Berthold
svn diff setup.py
Index: setup.py
===================================================================
--- setup.py (Revision 3084)
+++ setup.py (Arbeitskopie)
@@ -261,7 +261,7 @@
 print 'WXAgg\'s accelerator requires wxPython'
 BUILD_WXAGG = 0
 else:
- if getattr(wx, '__version__', '0.0')[0:3] < '2.8':
+ if getattr(wx, '__version__', '0.0')[0:3] <= '2.8':
 BUILD_AGG = 1
 build_wxagg(ext_modules, packages, NUMERIX,
 not (isinstance(BUILD_WXAGG, str) # don't abort if BUILD_WXAGG
-- 

Ken McIvor <mc...@ii...> writes:
> On Mar 16, 2007, at 9:28 AM, Berthold H=C3=B6llmann wrote:
>>
>> I need a python compile with VC6. This python also needs a
>> matplotlib.
>
> Chris Barker and I worked on this a while ago, and I believe we=20=20
> decided it was impossible due to bugs/limitations in the VC++ 6=20=20
> compiler.
Is there any testsuite for matplotlib. I decided to install the
downloadable matplotlib egg (presumably compiled using VC7) into my
VC6 python and the first samples from the matplotlib tutorial page
which seem to work. I would like to do some more thoroughly testing.
Is there anything recommended?
Regards
Berthold
--=20

On Mar 16, 2007, at 9:28 AM, Berthold H=F6llmann wrote:
>
> I need a python compile with VC6. This python also needs a
> matplotlib.
Chris Barker and I worked on this a while ago, and I believe we =20
decided it was impossible due to bugs/limitations in the VC++ 6 =20
compiler.
Ken=

I need a python compile with VC6. This python also needs a
matplotlib. Now trying to compile matplotlib with my python version I
get some errors that are easy to overcome, but I'm stuck with an error
in the agg library part:
C:\PROGRA~1\MICROS~4\VC98\bin\cl.exe /c /nologo /Ox /MD /W3 /GX /DNDEBUG =
-Iw:\hoel\work\Python-2.4.4\dist\lib\site-packages\numpy\core\include =
-IW:\hoel\work\libs\include -I. -Isrc -Iswig -Iagg23/include -I. =
-IW:\hoel\work\libs\include -I. =
-Iw:\hoel\work\Python-2.4.4\dist\lib\site-packages\numpy\core\include\fre=
etype2 -IW:\hoel\work\libs\include\freetype2 -I.\freetype2 =
-Isrc\freetype2 -Iswig\freetype2 -Iagg23/include\freetype2 -I.\freetype2 =
-IW:\hoel\work\libs\include\freetype2 -I.\freetype2 =
-Iw:\hoel\work\Python-2.4.4\dist\include =
-Iw:\hoel\work\Python-2.4.4\dist\PC /Tpsrc/_ns_backend_agg.cpp =
/Fobuild\temp.win32-2.4\Release\src/_ns_backend_agg.obj -DSCIPY=3D1 =
_ns_backend_agg.cpp
src/_ns_backend_agg.cpp(74) : warning C4800: 'long' : forcing value to =
bool 'true' or 'false' (performance warning)
src/_ns_backend_agg.cpp(376) : error C2893: Failed to specialize =
function template 'void __thiscall RendererAgg::_fill_and_stroke(VS =
&,const class GCAgg &,const
 struct std::pair<bool,struct agg::rgba> &,bool)'
 With the following template arguments:
 'class agg::path_storage'
src/_ns_backend_agg.cpp(423) : error C2893: Failed to specialize =
function template 'void __thiscall RendererAgg::_fill_and_stroke(VS =
&,const class GCAgg &,const struct std::pair<bool,struct agg::rgba> =
&,bool)'
 With the following template arguments:
 'class agg::path_storage'
src/_ns_backend_agg.cpp(476) : error C2893: Failed to specialize =
function template 'void __thiscall RendererAgg::_fill_and_stroke(VS =
&,const class GCAgg &,const struct std::pair<bool,struct agg::rgba> =
&,bool)'
 With the following template arguments:
 'class agg::path_storage'
src/_ns_backend_agg.cpp(1887) : error C2893: Failed to specialize =
function template 'void __thiscall RendererAgg::_fill_and_stroke(VS =
&,const class GCAgg &,const struct std::pair<bool,struct agg::rgba> =
&,bool)'
 With the following template arguments:
 'class agg::path_storage'
error: Command "C:\PROGRA~1\MICROS~4\VC98\bin\cl.exe /c /nologo /Ox /MD =
/W3 /GX /DNDEBUG =
-Iw:\hoel\work\Python-2.4.4\dist\lib\site-packages\numpy\core\include =
-IW:\hoel\work\libs\include -I. -Isrc -Iswig -Iagg23/include -I. =
-IW:\hoel\work\libs\include -I. =
-Iw:\hoel\work\Python-2.4.4\dist\lib\site-packages\numpy\core\include\fre=
etype2 -IW:\hoel\work\libs\include\freetype2 -I.\freetype2 =
-Isrc\freetype2 -Iswig\freetype2 -Iagg23/include\freetype2 -I.\freetype2 =
-IW:\hoel\work\libs\include\freetype2 -I.\freetype2 =
-Iw:\hoel\work\Python-2.4.4\dist\include =
-Iw:\hoel\work\Python-2.4.4\dist\PC /Tpsrc/_ns_backend_agg.cpp =
/Fobuild\temp.win32-2.4 \Release\src/_ns_backend_agg.obj -DSCIPY=3D1" =
failed with exit status 2
Is there any tip how to fix this for VC6?=20
Thanks
Kind regards
Berthold H=F6llmann
--=20
Germanischer Lloyd AG
CAE Development
Vorsetzen 35
20459 Hamburg
Phone: +49(0)40 36149-7374
Fax: +49(0)40 36149-7320
e-mail: ber...@gl...
Internet: http://www.gl-group.com
This e-mail and any attachment thereto may contain confidential =
information and/or information protected by intellectual property rights =
for the exclusive attention of the intended addressees named above. Any =
access of third parties to this e-mail is unauthorised. Any use of this =
e-mail by unintended recipients such as total or partial copying, =
distribution, disclosure etc. is prohibited and may be unlawful. When =
addressed to our clients the content of this e-mail is subject to the =
General Terms and Conditions of GL's Group of Companies applicable at =
the date of this e-mail.=20
If you have received this e-mail in error, please notify the sender =
either by telephone or by e-mail and delete the material from any =
computer.
GL's Group of Companies does not warrant and/or guarantee that this =
message at the moment of receipt is authentic, correct and its =
communication free of errors, interruption etc.=20
Germanischer Lloyd AG, 31393 AG HH, Hamburg, Vorstand: Dr. Hermann J. =
Klein, Rainer Sch=F6ndube, Vorsitzender des Aufsichtsrats: Dr. Wolfgang =
Peiner

Hi All:
I've had a lot of requests lately for a basemap binary installer for 
windows. Unfortunately, I don't have access to Windows at home or at 
work (it's an all mac/linux shop here). I'd really appreciate it if 
someone who uses windows and can compile matplotlib from source could 
help me out. Just check out basemap from svn, run 'python setupegg.py 
bdist_egg', and tell me where to pick up the resulting binary egg. Thanks!
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

I get this error
Traceback (most recent call last):
 File "simpletest.py", line 22, in <module>
 savefig('simpletest.pdf')
 File "/Users/jsw/lib/python/matplotlib/pylab.py", line 796, in savefig
 return fig.savefig(*args, **kwargs)
 File "/Users/jsw/lib/python/matplotlib/figure.py", line 727, in savefig
 self.canvas.print_figure(*args, **kwargs)
 File "/Users/jsw/lib/python/matplotlib/backends/backend_gtkagg.py", 
line 114, in print_figure
 orientation, **kwargs)
 File "/Users/jsw/lib/python/matplotlib/backends/backend_agg.py", line 
493, in print_figure
 orientation, **kwargs)
 File "/Users/jsw/lib/python/matplotlib/backends/backend_pdf.py", line 
1334, in print_figure
 file.close()
 File "/Users/jsw/lib/python/matplotlib/backends/backend_pdf.py", line 
399, in close
 self.writeFonts()
 File "/Users/jsw/lib/python/matplotlib/backends/backend_pdf.py", line 
454, in writeFonts
 fontdictObject = self.embedTTF(filename)
 File "/Users/jsw/lib/python/matplotlib/backends/backend_pdf.py", line 
506, in embedTTF
 widths = [ get_char_width(charcode) for charcode in range(firstchar, 
lastchar+1) ]
 File "/Users/jsw/lib/python/matplotlib/backends/backend_pdf.py", line 
503, in get_char_width
 unicode = cp1252.decoding_map[charcode] or 0
AttributeError: 'module' object has no attribute 'decoding_map'
when running the basemap example simpletest.py (or any other basemap 
example), and then saving to a pdf file using savefig.
I'm using the latest svn.
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

SSB3b3VsZCBqdXN0IHN1Z2dlc3QgdXNpbmcgb3BlbigpIGluc3RlYWQgb2YgZmlsZSgpLCBidXQg
dGhpcyBpcyBhCmdlbmVyYWwgUHl0aG9uIHRpcCA6KQoKRXZlcnl0aGluZyBlbHNlIHNlZW1zIE9L
LgoKQmVzdCwKRWRpbgoKT24gMy8xMy8wNywgSm91bmkgSy4gU2VwcMOkbmVuIDxqa3NAaWtpLmZp
PiB3cm90ZToKPiBbTW92aW5nIHRvIHRoZSBkZXZlbCBsaXN0Ll0KPgo+IEhlcmUncyBhIHBhdGNo
IGZvciBmb250X21hbmFnZXIucHkgdG8gY2xvc2Ugb3BlbmVkIGZpbGVzLiBDb3VsZAo+IHNvbWVi
b2R5IHJldmlldyB0aGUgcGF0Y2g/IEFzIEkgbWVudGlvbmVkIGVhcmxpZXIsIEkgZG9uJ3QgdW5k
ZXJzdGFuZAo+IHdoeSBjUGlja2xlL3BpY2tsZSBpcyBub3QgaW1wb3J0ZWQgYXQgdGhlIHRvcCBs
ZXZlbCwgc28gSSdtIGhlc2l0YW50Cj4gdG8gY2hlY2sgdGhpcyBpbiB3aXRob3V0IHJldmlldy4K
Pgo+Cj4KPiBKb3VuaSBLLiBTZXBww6RuZW4gPGprc0Bpa2kuZmk+IHdyaXRlczoKPgo+ID4gSSBm
aXhlZCBhbm90aGVyIGZpbGVoYW5kbGUgbGVhayBpbiB0aGUgcGRmIGJhY2tlbmQsIHNvIGhlcmUn
cyBhIG1vcmUKPiA+IGNvbXBsZXRlIHBhdGNoLiBUaGVyZSBhcmUgYWxzbyBzZXZlcmFsIGNhc2Vz
IG9mIGZpbGUoLi4uKSBiZWluZyBwYXNzZWQKPiA+IHRvIHBpY2tsZS5kdW1wIG9yIHBpY2tsZS5s
b2FkIGluIGZvbnRfbWFuYWdlci5weS4gSSB3YXMgZ29pbmcgdG8gdGFrZQo+ID4gY2FyZSBvZiB0
aGVzZSBieSB3cml0aW5nIHNvbWUgdXRpbGl0eSBmdW5jdGlvbnMsIGJ1dCBJIHN0YXJ0ZWQKPiA+
IHdvbmRlcmluZyB3aHkgdGhlIGltcG9ydCBvZiBjUGlja2xlIG9yIHBpY2tsZSBpcyBkb25lIG9u
bHkgd2l0aGluCj4gPiBtZXRob2RzIG9mIEZvbnRNYW5hZ2VyIGFuZCBub3QgYXQgdGhlIHRvcCBs
ZXZlbC4gQXJlIHRoZXJlIHNvbWUKPiA+IHBsYXRmb3JtcyB3aGVyZSBuZWl0aGVyIGlzIGF2YWls
YWJsZSwgb3Igd2hhdCBpcyB0aGUgcmF0aW9uYWxlPwo+Cj4gLS0KPiBKb3VuaSBLLiBTZXBww6Ru
ZW4KPiBodHRwOi8vd3d3LmlraS5maS9qa3MKPgo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiBUYWtlIFN1
cnZleXMuIEVhcm4gQ2FzaC4gSW5mbHVlbmNlIHRoZSBGdXR1cmUgb2YgSVQKPiBKb2luIFNvdXJj
ZUZvcmdlLm5ldCdzIFRlY2hzYXkgcGFuZWwgYW5kIHlvdSdsbCBnZXQgdGhlIGNoYW5jZSB0byBz
aGFyZSB5b3VyCj4gb3BpbmlvbnMgb24gSVQgJiBidXNpbmVzcyB0b3BpY3MgdGhyb3VnaCBicmll
ZiBzdXJ2ZXlzLWFuZCBlYXJuIGNhc2gKPiBodHRwOi8vd3d3LnRlY2hzYXkuY29tL2RlZmF1bHQu
cGhwP3BhZ2U9am9pbi5waHAmcD1zb3VyY2Vmb3JnZSZDSUQ9REVWREVWCj4gX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBNYXRwbG90bGliLWRldmVsIG1h
aWxpbmcgbGlzdAo+IE1hdHBsb3RsaWItZGV2ZWxAbGlzdHMuc291cmNlZm9yZ2UubmV0Cj4gaHR0
cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vbWF0cGxvdGxpYi1kZXZl
bAo+Cj4KPgo=