matplotlib-devel Mailing List for matplotlib

Thanks for looking at this. From the unittest that you checked in, it 
appears you've succeeded in getting dates and datetimes to work, modulo 
the apparent datetime precision buglet you mention below.
My understanding with repr() is that, in general, it should attempt to 
support lossless copying of data with the eval() function. It does 
appear that dateutils does this -- repr() produces a string that looks 
like what you'd use to call the constructor. (Numpy scalars don't follow 
this idiom, and it's doubtful they could change without breaking a lot 
of code.) I also agree that for a CSV file, something like the str() on 
date and datetime objects makes most sense. This is all just to say that 
the date and datetime stuff looks good to my eye, but you're using that 
stuff a lot more than me. Finally, from your example, it does look like 
there's a bug somewhere in the datetime code. Since I don't use them, I 
leave that to you...
Finally, as far as the checkrows -- I must admit that I wasn't even 
aware of its existence until you asked the question. (That's the problem 
with writing code that just works - no one notices it!) Now that you've 
posed the question, I suppose I'm in favor a default of 0 (which 
actually means infinity). I suppose no one in their right mind is going 
to use CSV files to store gigabytes of data, so parsing the whole thing 
for consistency seems like a worthwhile expenditure of cycles. (And if 
they're thinking about it, maybe the slowness with dissuade them, or at 
least cause them to read the docstrings! :)
John Hunter wrote:
> On Dec 16, 2007 5:26 PM, Andrew Straw <str...@as...> wrote:
>
> 
>> As a followup to the work on floats, I fixed rec2csv to deal with funky
>> strings (strings with commas and quotes). I've checked this is as r4749,
>> but I thought I'd announce here in case someone (John, in particular)
>> was depending on some peculiar aspect of the old implementation. If
>> there is something you depend on, can you update the unittests in
>> unit/mlab_unit.py to check for the behavior you need?
>> 
>
> OK, I found one problem with repr. When adding support for date vs
> datetime to the csv2rec roundtrip, and adding this to the unit test, I
> notice that repr is probably not what we want for datetime; str makes
> more sense here:
>
> In [1]: import datetime
>
> In [2]: d = datetime.date.today()
>
> In [3]: repr(d)
> Out[3]: 'datetime.date(2007, 12, 16)'
>
> In [4]: str(d)
> Out[4]: '2007-12-16'
>
> The latter is more natural in the CSV file, and the repr version is
> not supported by dateutil, at least not the one we are shipping:
>
> In [5]: import dateutil.parser
>
> In [6]: dateutil.parser.parse(repr(d))
> ---------------------------------------------------------------------------
> ValueError Traceback (most recent call last)
>
> /Users/jdhunter/python/svn/matplotlib/examples/<ipython console> in <module>()
>
> ...snip the rest of the traceback...
>
> In [7]: dateutil.parser.parse(str(d))
> Out[7]: datetime.datetime(2007, 12, 16, 0, 0)
>
>
> So I changed FormatObject to use str, pending further discussion. At
> least for my common use cases, the only obj types I have in my record
> arrays are dates and datetimes, and I find this to be a pretty
> compelling use case since it is the type least likely to be supported
> by other persistence methods (tostring and pickle both fail or do not
> behave as expected with datetimes in the recarray).
>
> But there is an oddity in the parsing of milliseconds which is causing
> the updated unit test to fail; the code below illustrates the problem:
>
> In [3]: import dateutil.parser
>
> In [4]: import datetime
>
> In [5]: s = '2007-12-18 22:29:34.924122'
>
> In [6]: dateutil.parser.parse(s)
> Out[6]: datetime.datetime(2007, 12, 18, 22, 29, 34, 924121)
>
> Thoughts?
>
> JDH
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services
> for just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

Darren Dale wrote:
> On Thursday 13 December 2007 2:22:13 pm Robert Kern wrote:
>> John Hunter wrote:
>>> Do we need namespace packages in toolkits? I recently added gtktools
>>> and exceltools to toolkits, and got a very hard to debug error:
>>>
>>> In [1]: import matplotlib
>>>
>>> In [2]: matplotlib.__file__
>>> Out[2]:
>>> '/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/__init__.py
>>> c'
>>>
>>> In [3]: matplotlib.rcParams['axes.axisbelow']
>>> Out[3]: False
>>>
>>> In [4]: import matplotlib.toolkits.gtktools
>>>
>>> In [5]: matplotlib.__file__
>>> Out[5]:
>>> '/opt/app/g++lib6/python-2.4/lib/python2.4/site-packages/matplotlib/__ini
>>> t__.pyc'
>>>
>>> In [6]: matplotlib.rcParams['axes.axisbelow']
>>> ------------------------------------------------------------
>>> Traceback (most recent call last):
>>> File "<ipython console>", line 1, in ?
>>> KeyError: 'axes.axisbelow'
>>>
>>> Notice that the matplotlib module which was previously imported got
>>> changed by the import of the toolkit which declared itself a namespace
>>> package. Now this may be the result of mpl not using namespace
>>> packages correctly (eg matplotlib/__init__.py should be empty save for
>>> the namespace package or something like that)
>> Probably. In setuptools 0.7, they can have stuff in them, but all of them
>> must be identical.
> 
> How would one learn about this new feature? According to setuptools.txt from 
> the 0.7 svn checkout, the namespace package's __init__.py must still be empty 
> save the namespace declaration.
It's a logical consequence of how namespace packages are loaded in 0.7 as has
been explained on the mailing list whenever the subject of namespace packages in
0.7 is brought up. It's still not recommended, but it can be made to work. The
remaining objection in the documentation is about installing the package using
--single-version-externally-managed for distro packagers. Using --svem, the
__init__.py files are not installed. Since a distro package would have a
mynamespace-common package (or something similar) that *just* provides this
__init__.py file for all of the mynamespace.foo packages, it can provide the
single copy of the meaningful code.
But it's still not a good idea.
>> If you are using an unmodified matplotlib/__init__.py in 
>> the main matplotlib package, then the "if 0:" is preventing the declaration
>> of the namespace package, and that may be contributing.
>>
>> Also, neither matplotlib nor matplotlib.toolkits is named as a
>> namespace_package in matplotlib's setup.py, and both have to be. Similarly,
>> basemap (for example) only lists matplotlib.toolkits but not matplotlib.
> 
> If I understand correctly, even after fixing these two problems, namespace 
> packages would not work since matplotlib/__init__.py contains lots of 
> meaningful code. Based on the remarks at 
> http://mail.python.org/pipermail/distutils-sig/2007-October/008346.html and 
> the setuptools svn commit log, it looks like development on version 0.7 is 
> not a priority and a release in the next year is unlikely. So is it fair to 
> say that for the foreseeable future, matplotlib is not compatible with 
> namespace packages unless we cleaned out __init__.py? 
Yes. Phillip explained this in February and suggested a way around the issue:
 http://www.mail-archive.com/dis...@py.../msg02908.html
-- 
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
 -- Umberto Eco