BrandonFors/pandas-github-issues huggingface dataset:
DOC: GH2072 add example and warning on fallback indexing for float indexes.
State: closed

https://github.com/pydata/pandas/issues/2072#issuecomment-9454035


Labels:
name: Docs
name: Indexing
description: Related to indexing on series/frames, not to indexes themselves

Comments:
can you make the doc lines wrap, no more than 80 char width. (I get flagged for this all the time!)

Looks good otherwise

@y-p ?

also, maybe add an example of using the 'float' selection, e.g

say A is your previous indexer column
something like this? 

```
df[(df.A>=1.0) & (df.A<2.0)]
```

`instead use use` - needs fixing.

**very bad idea** is not the best pharsing IMO. explain the problem. explain the caveats, 
recommend a better way.

Also, I can't parse:
`If you do have a float index, an integer label will fallback to`
it seems disjointed.

I haven't followed this issue, so i'm looking at the doc with fresh eyes... ;)

Oh, re 80 char limit on documentation - stop the PEP8 insanity! it's not even code!

Good point @y-p. How about this?

looks good to me (and now you are taking style points from @y-p )....!

Hey- if you don't want pedantry, don't ask for my opinion on docs.

and if you wouldn't mind, pls rebase into 1 commit 

```
git rebase -i <first commit>
```

change the pick to fixup (or squash if you want) for all but the first

then

```
git push <your fork> <this branch name> -f
```

@jreback - done. I wondered how that worked in git - thanks.

this looks great

I'll leave open for a couple of days in case you want to change anything
(I find that I read doc updates and then I edit them the next day)

yep, this is good.

@adamgreenhall 
in http://pandas.pydata.org/pandas-docs/dev/indexing.html#fallback-indexing

I realized that the last part of your example is correct, but not illustrating what _I think_ you want.

`df_new.index` is the _index_ in this case, but you want to illustrate `df_new['index']`

```
In [14]: df_new
Out[14]: 
   index         A         B         C         D
0      1 -1.164567  0.054407  0.619462  1.936210
1      2  0.047871 -1.776328 -0.590250 -0.399167
2      3  0.214890 -0.593469 -1.115490  0.259086
3      4  0.089140 -0.998506  0.514325 -0.719256
```

```
In [15]: df_new[df_new.index==1.0]
Out[15]: 
   index         A         B        C         D
1      2  0.047871 -1.776328 -0.59025 -0.399167

In [16]: df_new[df_new['index']==1.0]
Out[16]: 
   index         A         B         C        D
0      1 -1.164567  0.054407  0.619462  1.93621
```

Same here

```
In [17]: df_new[(df_new['index']>=1.0) & (df_new['index']<2)]
Out[17]: 
   index         A         B         C        D
0      1 -1.164567  0.054407  0.619462  1.93621

```

Doing something like this might make the example more clear (then you can use `df_new.my_float_index`
that's my 2c

```
df_new = df.reset_index().rename(columns = dict(index = 'my_float_index'))
```
ENH: add option display.mpl_style GH3075
State: closed

![style](https://f.cloud.github.com/assets/1820866/285040/05e8f29c-920c-11e2-9ba1-1b7fab69a1a6.png)
#3075


Labels:

Comments:
@huyng, I like your style.

I'm assuming [link](https://gist.github.com/huyng/816622)  is public domain if that's even an issue. is this ok?

@y-p thanks, yes it's still active and in use.

@huyng, ok thanks, hopefully this will be merged and everyone's retinas
will gradually heal after years of mpl's shocking blue default scheme.

Thanks, glad I could contribute in some sense :) . What's the next big push
for Pandas? Would be glad to pitch in in some other ways if you guys need
the help.

On Thu, Mar 21, 2013 at 9:24 AM, y-p notifications@github.com wrote:

> @huyng https://github.com/huyng, ok thanks, hopefully this will be
> merged and everyone's retinas
> will gradually heal after years of mpl's shocking blue default scheme.
> 
> —
> Reply to this email directly or view it on GitHubhttps://github.com/pydata/pandas/pull/3112#issuecomment-15249068
> .

0.11 should be out in the next few weeks. There's always more to do
then devs to do it. 
Send us your PRs, your bug reports, your huddled masses...

f6edd17

@y-p looking at the newly built docs I'm happy to see this one merged for 0.11. This may sound pedantic, but when looking at the box plots section it looks like the old mpl scheme and the new scheme become mixed in an unfavourable way (mpl blue for the box plot lines). Would it make sense to extend this initiative such that all plots in the doc will look consistently? (to make the best impression about the new aesthetic powers of pandas ;-) 

Thanks. fixed the boxplots, the rest will wait for 0.12.

Great, thanks!

On 13.04.2013, at 13:41, y-p notifications@github.com wrote:

> Thanks. fixed the boxplots, the rest will wait for 0.12.
> 
> —
> Reply to this email directly or view it on GitHub.
TST: added ensure_clean file cleanup context manager for file based test
State: closed

avoids leaving temp files around if they are interrupted (during dev),
passes thru exceptions

idiom is:

```
with ensure_clean(path=None) as path:
     .....
```

rather than

```
try:
    ....
finally:
    os.remove(path)
```


Labels:
name: Testing
description: pandas testing functions or related to the test suite

Comments:
@y-p pls have a look when u have a chance

Looks fine. Preferably, PRs that touch many things at once should land 
right at the start of a release cycle not near it's end, to allow time for hidden
issues to manifest in master before being shipped.

delay to 0.12....?

if we do that....need a small fix in test_frame/test_to_csv_dups_cols.....not removing the test file....

no, this is ok to merge I think. better just go for it or you'll have to redo the whole
thing in two weeks due to conlict hell.
BLD: fix time module import conflict
State: closed

See #3097.


Labels:

Comments:
Thanks for investigating this. I think it'd be better to replace the `import *` statement instead, though.

```
from cpython cimport (
        PyTypeObject,
        PyFloat_Check,
        PyObject_RichCompareBool,
        PyString_Check
)
```

seems to do the job.
If you can redo the commit, I'll merge it once travis passes.

So should I change it then `git commit --amend`?

yep. or just add another commit and I'll take care of it.

Cool. Running the test suite on my machine and then I will push.

In it goes. thanks.
Resample docstring default values changed
State: closed

This docstring seems better, since TimeGrouper specifies it [that way](https://github.com/pydata/pandas/blob/master/pandas/tseries/resample.py#L27) too:


Labels:

Comments:
I'd simply remove the default val description from Timegrouper, 
the real behaviour is too much info for a docstring.

Is this OK now or should I change something else in the docstring?

merged.

Great, thanks!
Fix figsize issue when using matplotlib locally
State: closed

This is a pretty minor issue, but I'm seeing the following when passing `figsize=(20,10)` when plotting a Series in the `ipython --pylab` environment:

![Series_figsize](https://f.cloud.github.com/assets/440095/267751/46f8b184-8ebd-11e2-8631-2131ce0421f6.png)

Everything's there - the window is just initialized to the wrong size. Without the `--pylab` flag and manually calling `plt.show()`, the window shows up as the default size (which is incorrect).

The issue appears to be that `plot_series()` will call `plt.gca()` before `figsize=` has been passed to `plt.figure()`. This initializes the window to the default size and it apparently isn't updated when redrawn.

What this patch does is use `plt.get_fignums()` to see if we have any existing figures. If so, we can call `plt.gca()` without automatically creating a figure and window at the default sizes.

The addition of `new_ax.right_axis = new_ax` is to accommodate Series plotted with `secondary_y=True` and thus getting `new_ax` as their `Axes`. It renders fine without it but a few tests expect `right_axis` to exist. This could be handled differently if this is inappropriate.

Finally, there's a test to check that `figsize=` is at least implemented on the figure. I don't know of a way to test this bug in a backend-independent way, so this only checks that we're not regressing to the pre-v0.10.0 state where `figsize=` was silently ignored by `plot_series()`.


Labels:
name: Visualization
description: plotting

Comments:
Thanks!
cython dependency and a pip tip
State: closed

Some advice that would've helped me when I was first trying to get the development version working.


Labels:

Comments:
having a clear README is important, if you fix up the points I mentioned,
I'll merge this.

Is it clearer now?

I didn't write the instructions for Windows (the MiniGW thing) and I don't use Windows so I would rather not change that part.

yes, thank you. I hope the next person will have an easier time diving in.

Great! :)

On Sun, Mar 17, 2013 at 2:54 PM, y-p notifications@github.com wrote:

> yes, thank you. I hope the next person will hvae an easier time diving in.
> 
> —
> Reply to this email directly or view it on GitHubhttps://github.com/pydata/pandas/pull/3067#issuecomment-15023025
> .
Scatter matrix labels fix
State: closed

fix scatter matrix axis labels for odd number of columns

https://github.com/pydata/pandas/issues/2756


Labels:

Comments:
oops - included my last fix in here too. I can fix that if it is a problem - just let me know.

no need, I'll do it. Thanks for pitching in!

A I missing something? the example in #2756 looks unchanged.

I only added a C label the first try. Just took another look - the axis labels should be complete now. Here's an example: http://nbviewer.ipython.org/5189208

Thanks, I rebased and merged. Opted for the traditional tick arrangement.

We could use more help sorting out the plotting part of pandas, there
are a bunch of open issues if you feel like tackling some more stuff.

I opened #3075 yesterday, just need to figure out a way to bake in a color scheme
without messing people's own customizations. The current scheme is inspired by 
1992 CGA screens, we could do better...
Fix some pprint_thing warts
State: closed

**Part 1**
currently:

``` python
In [4]: from pandas.core.common import pprint_thing as pp_t
   ...: pp_t([1,None])
Out[4]: u'[1, ]'
```

after PR:

``` python
In [13]: from pandas.core.common import pprint_thing as pp_t
    ...: pp_t([1,None])
Out[13]: u'[1, None]'
```

and jeff fixed index NaN printing in #3034, at a higher level.

**Part 2**

currently:

``` python
In [1]: pd.Index(['a','b'])
   ...: 
Out[1]: Index([a, b], dtype=object)
```

after PR:

``` python
pd.Index(['a','b'])
Out[3]: Index([u'a', u'b'], dtype=object)
```

so:

``` python
In [7]: from pandas import Index
In [10]: eval(repr(pd.Index([u'a', u'b'], dtype=object)))
Out[10]: Index([u'a', u'b'], dtype=object)
```

Which is what `repr()` should enable, in principle.


Labels:

Comments:
added notes to 0.11.0., but maybe this should wait until 0.12/0.11.1

also, make Timstemp repr executable, like datetime.

@y-p I only found the 1 case where a NaN was actually passed to pprint_thing (in index.py/format, which I fixed)

yep. what bothers you about these changes?

is there a test case where Part 1 actually occurs? 

say there isn't. Why should None be invisible, even in theory?

oh...nothing....they look fine...just curios (I have always though we should ALWAYS convert None anyhow...but that is a separate issue)

I must have written that at the spur of some 4am moment, ["that's no basis for a system of government"](http://www.spunk.org/texts/humour/sp000621.txt).

that's pretty funny!

rebase fail, redone with 4aea3f2
DOC: added cookbook.rst to main docs
State: closed


Labels:
name: Docs

Comments:
@wesm @y-p good addition?

It's a good start, though I suspect the format will ultimately limit this from growing beyond 
a certain point.
Also, you're up against google/stack overflow for discoverability and that's a hard fight.

Possibly a `pandasfu.me` site in the future? a cross between a cheat sheet,
http://repl.it/ and commandlinefu.com.

Suggest putting the word out on the mailing list and opening an eternal issue 
with a "good first PR" tag. **EDIT**: since merging the PR will close this one

Keep knockin'em down, jeff. :thumbsup: 

ahh....but NOT trying to compete against stackoverflow, in fact lifting links to 'interesting' use cases....
sort of supplemental documentation....

Oh sure, it's just a question of what people reach for when they hit a problem.

providing options!

@y-p what do you think of cookbook? (it just updated)

Shaping up very nicely.
BUG:  Formatting of an index that has nan was inconsistent or wrong
State: closed

 Formatting of an index that has `nan` was inconsistent or wrong,
(would fill from last value), closes GH #2850

Also changed in test_format.py/test_index
1) printing of 'nan' rather than the na_rep (NaN) is inconcsistent
     with everywhere else
2) a 'None' in the index is defacto treated as NaN, is this wrong?


Labels:

Comments:
@y-p when you have a chance, can you give this a look-see

updated
cleaner now

:thumbsup: 

Want to fix up pprint_thing or shall I? 

well that's the thing, when is pprint_thing supposed to hit None?

None? I don't follow.

what I meant was

pprint_thing(x)
where x is None

is this ever called? (i know it was called
on an index that had a None in it) - are there any valid
cases where this SHOULD be called with None?

I don't see an issue with pprint_thing like it is

I was thinking of

```
In [73]: pd.core.common.pprint_thing(pd.Series([1,2,nan]))
Out[73]: u'[1.0, 2.0, nan]'
```

But, apperantly the repr/to_string methods take care of that,
so no need.

pprint_thing is mutually recursive with pprint_seq, so pprint_thing(None)
is possible. I made sure None printed as '', so there must have been some case 
I can't for the life of me remember now.

```
In [77]: pd.core.common.pprint_thing([1,2,None])
Out[77]: u'[1, 2, ]'
```

I'm sure it justifies that. at least I hope it does.

ahh yes
that makes sense

the case I found was printing of a None index as ''
which I think should be illegal; prints as NaN now (and does a regular nan in an index)

so are we printing NaN or nan ?
is index different that values?

show me a test case., what is a "None index"?

``` python
In [80]: pd.core.common.pprint_thing(pd.Index([]))
Out[80]: u'[]'
```

I think in normal use where the question of how nans are printed arises,
pprint_thing is not used directly and upper layers ensure proper behaviour.

in general. an index is a sequence like any other as far as pprint is concerned.

I marked the 2 tests I changed in test_index

Should be fine to change pp to print 'None'  as 'None' in general. (at least
I can't remember a reason not to).

Whether None should be interpreted as None or NaN, would
mean adding a mode to pprint_seq and specializing it's invocation
from pprint_thing based on sequence type (ndarrays supporting nans).

Alternatively, since other objects print nans correcty the other stringify method
must be jumping through hoops that the Index class stringify does not.
so could just add that to Index repr()

**edit**: which is what you've done.
Add viewcode extension to allow for links to source in API docs
State: closed

This creates the [source] links in the API documentation sections.  You can read more about this Sphinx extension [here](http://sphinx-doc.org/ext/viewcode.html).  There could be a reason this is NOT already added so let me know.  I find it useful to have this because often times I want to easily jump to the source in the HTML docs.  Of course, I typically just use this to quickly find the file and open it in a real editor.

It might be worth noting this functionality was added in Sphinx 1.0, which was released in July 2010.  I'm not sure what the rules are on backwards compatibility for the documentation build.

I tested this with Sphinx 1.1.3 and it worked without any issues.


Labels:

Comments:
It's also worth noting there is no [source] link for things like `pandas.io.parsers.read_csv` which is sort of built dynamically instead of with a traditional `def`.  Maybe there is a way to improve the `viewcode` extension to handle this or put some additional hooks in the documentation itself?  Not sure what the best approach would be in that case or even what options exist.

This and the fact that almost no user-facing pandas function/method actually does any work other than delegating is one of the reasons I'm not sure about the usefulness of this. That said, it wouldn't hurt anything to have (except the size of the docs, which is probably not a concern). Many refactors ago I got out of the habit of using ?? in ipython to look at the source for pandas because of these same reasons.

I agree with jseabold, moving to 'someday'

No problem.  Maybe this would be more important in the future anyway.  Thanks for the explanation.

Someday PRs make no sense. closing.  Thanks for trying.
Continuing #2057, s/assert/raise AssertionError/g
State: closed

#2057

Though I've never encountered usage of python -O in the wild.


Labels:

Comments:
set to 0.12, to be merged right after 0.11, since it touches all manner of things
and needs testing before inclusion in a release. 

Seems pretty uncontroversial to me. I'd be happy merging?

Up to you. there's no real benefit to users, and it's too many changes to be sure
I haven't missed a semicolon somewhere. I prefer 0.12 - there's already a bunch 
of refactors queued up for right after 0.11, might as well save it for the party.
DOC: ylabels for secondary_y axis
State: closed

modified "Selective Plotting on Secondary Y-axis" example to show how to set ylabels for both left and right y axis


Labels:

Comments:
good, but I don't think it's playing nice with the sphinx machinery
because regenerating the docs doesn't produce the labels. Have a look?

Should be fixed now. The plot below had the same filename. 

much appreciated. merged as dde093e.
Bug: Fixed Issue 2993, Incorrect Timestamp Construction by datetime.date and tz
State: closed

`Timestamp` cannot be constructed correctly by given an `datetime.date` instance and `tz`.
The issued has been solved in this patch and the test case is add in `pandas/tseries/test/test_timezones.py`


Labels:
name: Bug
name: Datetime
description: Datetime data dtype

Comments:
Looks fine to me.

Please setup travis to make sure all the tests are green, and I'll merge this.

``` python
In [15]: d=datetime.datetime(2013, 3, 9)
    ...: print pd.Timestamp(d.date(),tz='US/Pacific')
    ...: print pd.Timestamp(d,tz='US/Pacific')
    ...: 
2013-03-08 16:00:00-08:00
2013-03-09 00:00:00-08:00
``
```

look ok to me 2

The Travis build passed.

Merged. thanks for contributing.
add comparisons operator to the Period object and fixes issue 2781
State: closed

This commit should fix [issue 2781](https://github.com/pydata/pandas/issues/2781). The Period object couldn't be sorted because it didn't have any **le**, **gt**, **lt**, **ge** or **cmp** methods.


Labels:

Comments:
Can you add a test that asserts an exception is raised (`assertRaises`) if two periods with different frequencies are compared?

I did some changes in the `__eq__` method and updated the tests accordingly. I think that comparing a Period object with anything, other than a Period object, should raises a Type error. Correct me if I'm wrong.

Thanks. Note for the future you could have less code duplication by creating a function factory and using the built-in `operator` module

I can redo it with a function factory if you wish. :)

@moisan this mergable?
@wesm ok?

I believe this is mergeable.

Merged. Thank you!
ENH: add display.max_seq_items to limit len of pprinted long sequences
State: closed

There's a circuit-breaker in higher layers of the display code,
but just in case.

``` python
n [2]: pd.options.display.max_seq_items=10

In [3]: pd.core.common.pprint_thing(range(10000))
Out[3]: u'[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, ...]'
```


Labels:

Comments:
Should add this to the release notes somewhere I guess

will do.

pushed.
Enable display of cursor coordinate info in t-series plots
State: closed

See Github Issue [#1670](https://github.com/pydata/pandas/issues/1670).

Apologies for not having squashed my commits together; got rather confused by the process.


Labels:

Comments:
To be perfectly honest, I was hoping to tackle the issue in a slightly more generic way. What I had in mind was something similar to pandas.tseries.converter.PandasAutoDateFormatter so that the format of the timestamp would vary when you zoom in or at least would depend on the frequency of the regular timeseries. For example for a daily timeseries you probably don't want to print the timestamp with a micro-second resolution.

I have to admit I never got around to find a proper solution, although knowing that others have noticed the problem and care about it may help to gather some momentum.

For an ad-hoc solution, it seems like using `fmt_xdata` is better suited e.g. something like:

``` python
ax.fmt_xdata = lambda x: pd.Period(ordinal=int(x), freq=ax.freq)
```

I am actually not sure you get the right timestamp with your method, I get something in 1970 whereas my timeseries start in 2000, unless I missed something. Here is what I did:

``` python
import datetime
import pandas as pd
ts = pd.util.testing.makeTimeSeries(1000)
ax = ts.cumsum().plot()
ax.fmt_xdata = lambda x: datetime.datetime.fromtimestamp(x)
```

I cherry-picked these commits

As identified by @lesteve, the method suggested by @WillFurnass doesn't return the correct timestamp. However, the following solution seems to work:

```
ax.format_coord = lambda t, y : "t = {}    y = {:8f}".format(Period(ordinal=int(t), freq=ax.freq).to_timestamp().to_datetime(), y)
```

in pandas.tseries.plotting.tsplot.

The formatting doesn't automatically scale according to zoom extent (like matplotlib plots automatically do), but I'm not sure how to do this (and personally, find it hinders rather than helps). Instead it just outputs the default format YYYY-MM-DD hh:mm:ss.

Solution inspired from http://stackoverflow.com/questions/13421947/getting-usable-dates-from-axes-get-xlim-in-a-pandas-time-series-plot.