On Mon, Jul 16, 2007 at 10:31:03PM -0500, John Hunter wrote:
> On 7/16/07, Eric Firing <[EMAIL PROTECTED]> wrote:
> > Are any real, live projects outside of enthought making major use of
> > traits? Or would we be the first?
> I am happy to be the first at this point -- enthought has done a lot
On Mon, Jul 16, 2007 at 08:38:17AM -0500, John Hunter wrote:
> On 7/15/07, Paul Kienzle <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > I don't see an obvious way to remove a line from an axes object.
> >
> > Shall I add remove_child(h) which searches through all the lists
> > of containers and removes
Robert Kern wrote:
[...]
> We've split up the main "enthought" package such that Traits can be installed
> separately as "enthoguht.traits". I think we'd prefer depending on it
> externally
> now that we've spent so much effort to make that feasible.
When do you expect to make a release?
Eric
-
John Hunter wrote:
> On 7/16/07, Eric Firing <[EMAIL PROTECTED]> wrote:
>
>> Are any real, live projects outside of enthought making major use of
>> traits? Or would we be the first?
Yes. Most are in the somewhat formative stages, so you may not think they count
(which is fine).
> I am happy to
On 7/16/07, Eric Firing <[EMAIL PROTECTED]> wrote:
> Are any real, live projects outside of enthought making major use of
> traits? Or would we be the first?
I am happy to be the first at this point -- enthought has done a lot
to support traits. Traits has one of the most impressive pieces of
t
John Hunter wrote:
[...]
> Isn't there a potential problem here? The original validate funcs
> support conversion from a string to a value, but you are proposing
> using them here in a context where users will generally be supplying a
> (possibly bogus) value, but in general not a string. So the
On 7/16/07, Darren Dale <[EMAIL PROTECTED]> wrote:
> John wrote rc_traits.py, before numpy was around, by the looks of it. Traits
> seem more appealing to me than properties, but I was looking for something
> that could be done outside of a chainsaw branch. If we decided on traits, we
> should also
On 7/16/07, Darren Dale <[EMAIL PROTECTED]> wrote:
> John wrote rc_traits.py, before numpy was around, by the looks of it. Traits
> seem more appealing to me than properties, but I was looking for something
> that could be done outside of a chainsaw branch. If we decided on traits, we
> should als
On Monday 16 July 2007 7:22:37 pm you wrote:
> Darren Dale wrote:
> > I've been thinking a bit about rcParams and validation. It looks like
> > values are currently only validated when matplolibrc is read, during the
> > call to rc_params. What if we define a new class (RcParams), derived from
> >
Darren Dale wrote:
> I've been thinking a bit about rcParams and validation. It looks like values
> are currently only validated when matplolibrc is read, during the call to
> rc_params. What if we define a new class (RcParams), derived from dict, which
> has as an attribute, a dict, called vali
On 7/16/07, Darren Dale <[EMAIL PROTECTED]> wrote:
> the validation dict and default properties would be populated during the
> initial call to rc_params(), when the defaultParams dict is interpretted.
> Thereafter, any attempt to set a parameter, either directly using
> rcParams[i]=j or indirectly
I've been thinking a bit about rcParams and validation. It looks like values
are currently only validated when matplolibrc is read, during the call to
rc_params. What if we define a new class (RcParams), derived from dict, which
has as an attribute, a dict, called validate. We could override __s
Darren Dale wrote:
[...]
> Why do we need a single namespace? It seems unadvisable. There is additional
> overhead with namespace lookups: running numpy.arange(10) a million times
> takes 15% longer than arange(10). I would have thought it best to do more
> of "from w import x, y, z"
I have in
On 7/16/07, Darren Dale <[EMAIL PROTECTED]> wrote:
> This seems a little too cute too me, no offense intended to the clever author.
> Why do we need a single namespace? It seems unadvisable. There is additional
> overhead with namespace lookups: running numpy.arange(10) a million times
> takes 15%
John Hunter wrote:
> That or we simply adopt the TeX standard
+1 TeX is widely used and well documented -- why have something almost
the same?
though I still think the real solution is to sue TeX itself to do the
typesetting. not the way we do now, but:
Parsing the DVI and laying out stuff
On Friday 13 July 2007 06:29:59 pm Eric Firing wrote:
> Eric Firing wrote:
> > John Hunter wrote:
> >> On 7/13/07, Ted Drain <[EMAIL PROTECTED]> wrote:
> >>> I think he means that the matplotlib/__init__.py file should be
> >>> changed to that those things are imported.
> >>
> >> but if __init__.py
On 7/16/07, Edin Salkovic <[EMAIL PROTECTED]> wrote:
> You use it like this (notice no backslashes):
> >>> from matplotlib._mathtext_data import tex2uni
> >>> unichr(tex2uni['int'])
> u'\u222b'
> >>> unichr(tex2uni['sum'])
> u'\u2211'
That's a rather good solution, as it avoids duplication, and i
On Monday 16 July 2007 02:32:30 pm John Hunter wrote:
> On 7/16/07, Michael Droettboom <[EMAIL PROTECTED]> wrote:
> > I'm working on some improvements to the mathtext engine on a branch.
> > Feel free to join in if curious, but I expect to break lots of things as
> > I go.
> >
> > https://matplotli
On 7/16/07, Michael Droettboom <[EMAIL PROTECTED]> wrote:
> 1. Deal with nested sub/superscripts, such as $x_i_j$, equivalent to
> $x_{i_j}$
> 2. Make the font change tags (\cal, \tt, \rm etc.) behave more like TeX,
> In general, is the goal with mathtext to become as TeX-compatible as
> possible
On 7/16/07, Michael Droettboom <[EMAIL PROTECTED]> wrote:
> As for Unicode literals in Python source, there is a third option, other
> than u'\xd7' or '×'. Python will let you do u"\N{MULTIPLICATION SIGN}",
> which means you don't have to remember what \xd7 is. For single
> characters like this,
On 7/16/07, Andrew Straw <[EMAIL PROTECTED]> wrote:
> It looks like Edin made setuptools required in svn, which I just
> reverted. Edin -- why? I'm a fan of setuptools, but I don't think we
> should require a prerequisite that isn't necessary. Of course, if the
> developers decide we want to requir
John Hunter wrote:
> On 7/16/07, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>> I'm working on some improvements to the mathtext engine on a branch.
>> Feel free to join in if curious, but I expect to break lots of things as
>> I go.
>>
>> https://matplotlib.svn.sourceforge.net/svnroot/matplotlib
On 7/16/07, Michael Droettboom <[EMAIL PROTECTED]> wrote:
> I'm working on some improvements to the mathtext engine on a branch.
> Feel free to join in if curious, but I expect to break lots of things as
> I go.
>
> https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/mathtext_mgd/
>
Eric Firing wrote:
> While you are at it, perhaps you can figure out how to stop
> unicode_demo from generating an error:
>
> driving unicode_demo.py
> File "_tmp_unicode_demo.py", line 10
> SyntaxError: Non-ASCII character '\xe9' in file _tmp_unicode_demo.py
> on line 10, but no encodi
I'm working on some improvements to the mathtext engine on a branch.
Feel free to join in if curious, but I expect to break lots of things as
I go.
https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/mathtext_mgd/
I've collected a bunch of math expressions from the source tree f
It looks like Edin made setuptools required in svn, which I just
reverted. Edin -- why? I'm a fan of setuptools, but I don't think we
should require a prerequisite that isn't necessary. Of course, if the
developers decide we want to require setuptools, I'm happy to support
the change, but it should
Darren Dale wrote:
[...]
> What about rendering unicode, but keeping the mpl sources ascii only?
This sounds like the thing to do for now.
While you are at it, perhaps you can figure out how to stop unicode_demo
from generating an error:
driving unicode_demo.py
File "_tmp_unicode_de
John Hunter wrote:
> On 7/16/07, Eric Firing <[EMAIL PROTECTED]> wrote:
>
>> I use a good old-fashioned editor called zed, written by an Italian
>> named Sandro Serrafini who seems to have left no trace for several
>> years. I have modified it slightly, and I do minimal maintenance to
>> keep it
On Monday 16 July 2007 01:25:18 pm Eric Firing wrote:
> Michael Droettboom wrote:
> > Darren Dale wrote:
> >> If not, should we use
> >> u'\xd7' or '×' in the actual sources (the latter requiring the file's
> >> encoding to be declared at the beginning of the file, like: # -*-
> >> coding: utf-8 -*
On 7/16/07, Eric Firing <[EMAIL PROTECTED]> wrote:
> I use a good old-fashioned editor called zed, written by an Italian
> named Sandro Serrafini who seems to have left no trace for several
> years. I have modified it slightly, and I do minimal maintenance to
> keep it compiling with new OS relea
Michael Droettboom wrote:
> Darren Dale wrote:
>> If not, should we use
>> u'\xd7' or '×' in the actual sources (the latter requiring the file's
>> encoding to be declared at the beginning of the file, like: # -*- coding:
>> utf-8 -*-)?
> In an ideal world, I would prefer the latter, but we woul
Darren Dale wrote:
> If not, should we use
> u'\xd7' or '×' in the actual sources (the latter requiring the file's
> encoding to be declared at the beginning of the file, like: # -*- coding:
> utf-8 -*-)?
In an ideal world, I would prefer the latter, but we would want to
verify that all the mat
I am cleaning up some of the code in ticker.ScalarFormatter, specifically some
of the text formatting for dealing with scientific notation.
We provide an option to format labels in sci. notation without using mathtext
or usetex, in which case I would like to use the unicode multiplication sign,
On 7/15/07, Paul Kienzle <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I don't see an obvious way to remove a line from an axes object.
>
> Shall I add remove_child(h) which searches through all the lists
> of containers and removes the one that I don't want?
That's one way to do it, but you might consider
As a stopgap measure until someone with more knowledge of these changes
replies, the following worked for me. In setup.py, uncomment the old
distutils import, and comment the new setuptools import:
#from distutils.core import Extension, setup
from setuptools import setup
to
from distutils.cor
This morning I am having trouble installing from the svn repository. My home
machine does not have setuptools installed, and the standard python setup.py
install fails because it wants to import setuptools.
If I install setuptools, I am able to install, but not run pylab:
In [1]: from pylab imp
36 matches
Mail list logo
