Mailman 3 May 2013 - Pandas-dev

mailing list
by Phillip Cloud June 1, 2013

June 1, 2013

hey guys, is it possible we could move this list to google groups?

3 4

docs
by Jeff Reback May 31, 2013

May 31, 2013

docs regenerated today but must have been a failure somewhere as io.rst and api.rst still reflecting the old version (while everything else seems ok) weird Still need bs4 / html5lib on the build machine! thanks Jeff

2 3

change/wes can you turn the docs builder on? hasn't updated since may 11..thanks
by Jeff Reback May 25, 2013

May 25, 2013

2 3

Re: [Pandas-dev] 0.11.1
by Wes McKinney May 24, 2013

May 24, 2013

On Tue, May 21, 2013 at 3:18 AM, Jeff Reback <jeffreback(a)gmail.com> wrote: > oh I agree they should be core methods > (and have to_json,read_json) > > just think all io should be put in pandas.io > (as we r moving that way already there for: csv,hdf,excel,html...) > > just easier to manage > > and then put the accessor methods in core.generic (for to_) and have the read_ from the top level API > > avoids code bloat in the core/frame and friends > > actually would deprecate from_csv constructors as well - I think pd.read_csv pretty dominant now > > > On May 21, 2013, at 3:32 AM, Wes McKinney <wesmckinn(a)gmail.com> wrote: > >> On Mon, May 20, 2013 at 1:25 PM, Jeff Reback <jreback(a)yahoo.com> wrote: >>> sounds good >>> should these method be in >>> pandas.io.json >>> >>> to avoid bloating the core methods? >>> >>> >>> On May 20, 2013, at 2:51 PM, Wes McKinney <wesmckinn(a)gmail.com> wrote: >>> >>>> On Mon, May 20, 2013 at 4:57 AM, Jeff Reback <jeffreback(a)gmail.com> wrote: >>>>> very little left in the issues space >>>>> >>>>> y-p? >>>>> https://github.com/pydata/pandas/issues/3573 >>>>> >>>>> a PR I think should be included >>>>> https://github.com/pydata/pandas/pull/3649 >>>>> >>>>> I think y-p has a couple as well >>>>> >>>>> a couple of issues for wesm: >>>>> https://github.com/pydata/pandas/issues/3501 >>>>> https://github.com/pydata/pandas/issues/3453 >>>>> >>>>> a to_csv issue about quoting >>>>> https://github.com/pydata/pandas/issues/3503 >>>>> >>>>> maybe...chang? >>>>> https://github.com/pydata/pandas/issues/3634 >>>>> >>>>> _______________________________________________ >>>>> Pandas-dev mailing list >>>>> Pandas-dev(a)python.org >>>>> http://mail.python.org/mailman/listinfo/pandas-dev >>>> >>>> Cool-- just moved these to 0.11.1 milestone. What do you think about >>>> merging the JSON-back-from-the-dead code, right after 0.11.1? >> >> I feel that JSON is an important enough serialization format (along >> with CSV/TSV, definitely) to be core methods. What do you think? >> _______________________________________________ >> Pandas-dev mailing list >> Pandas-dev(a)python.org >> http://mail.python.org/mailman/listinfo/pandas-dev Agreed, deprecate from_* methods and simply have pandas.read_json and DataFrame.to_json, etc. - Wes

1 0

0.11.1
by Jeff Reback May 21, 2013

May 21, 2013

very little left in the issues space y-p? https://github.com/pydata/pandas/issues/3573 a PR I think should be included https://github.com/pydata/pandas/pull/3649 I think y-p has a couple as well a couple of issues for wesm: https://github.com/pydata/pandas/issues/3501 https://github.com/pydata/pandas/issues/3453 a to_csv issue about quoting https://github.com/pydata/pandas/issues/3503 maybe...chang? https://github.com/pydata/pandas/issues/3634

3 3

datetimes
by Jeff Reback May 13, 2013

May 13, 2013

Currently we allow ONLY datetime64[ns] as an internal representation (and analgously timedelta64[ns] for timedeltas). There are several issues where things like this are done: a) Series([np.datetime(2013,1,1),np.datetime(2013,1,2)],dtype='M8[ms]') b) Series([datetime(2013,1,1),datetime(2013,1,2)],dtype='M8[D]') in a) the np.datetimes are by default [us], so we need to do a conversion to M8[ns], ok, can do that to keep the internal rep, but what about the dtype specified? is this effectively an astype, but then is this conceptually just a display thing, e.g. the user wants to view the data as [ms], rather than [ns] several options to think about: 1) ignore completely the passed dtype and do some conversions on np.datetime64 (which we already do) to guarantee a M8[ns] internally (we do this now, but bork on a passed dtype that is not M8[ns] when the data is M8) 2) keep the passed dtype (or the inferred dtype) internally, effectively making datetimes a suite of M8[ms,D,s,ns......] 3) keep data a M8[ns] internally and provide an asfreq which works kind of like the PeriodIndex method, which can provide a DateTimeIndex I guess of the requested frequency? but then I keep thinking, is there any actual difference between 20130101 15:00:01.12345 in [ms], or [ns] (right now no) Any thoughts....I know I am ramblings a bit, but confused over what is even necessary here... Jeff

2 2