Merge tag 'v0.11.0rc1' into debian

Version 0.11 RC 1

* tag 'v0.11.0rc1': (647 commits)
  RLS: version 0.11 release candidate 1
  TST: py3 compat on test_pickle.py
  TST: properly raise the quoted exception when trying to unpickle on py2
  BUG: fix raw path to github raw data file
  DOC add missing arguments to to_datetime docstring
  PERF: series construction perf enhancements, use a fast path based on dtype
  PERF/CLN: infer Period in infer_dtype, later index inference is faster
  TST: run benchmark for repr wide frame with/without interactive mode
  PERF: fixed int64 indexing perf issue when conversion to int64
  DOC: fix typo
  WIP: finish on pandas-dev#2856
  DOC: add docstring
  BLD: travis make nose test selection clear via env_var
  BUG: segfault when set_index with MultiIndex. close pandas-dev#3308
  BUG: ensure index casting works even in Int64Index
  ENH: added py3 pickles, revsied to include SparseSeries/SparseDataFrame/Index/MultiIndex
  BUG: reading py2 pickles in py3 ok now
  BLD: fix setup.py to load correctly data files
  ENH: added legacy pickel generation/testing suppport
  CLN: moved all data for tests to /data sub-dir of the tests
  ...

Author: yarikoptic

.gitignore

@@ -29,3 +29,8 @@ pandas/io/*.dat
 pandas/io/*.json
 *.log
 .noseids
+
+.idea/libraries/sass_stdlib.xml
+
+.idea/pandas.iml
+.build_cache_dir

.travis.yml

@@ -2,31 +2,20 @@ language: python
 
 python:
   - 2.6
-  - 2.7
-#  - 3.1 # travis EOL
-  - 3.2
   - 3.3
 
 env:
   global:
-    - # need at least this so travis page will show env column
+    - NOSE_ARGS="not slow" # need at least this so travis page will show env column
 
 matrix:
   include:
     - python: 2.7
-      env: VBENCH=true
+      env: NOSE_ARGS="not network"  LOCALE_OVERRIDE="zh_CN.GB18030"
     - python: 2.7
-      env: LOCALE_OVERRIDE="zh_CN.GB18030"  # simplified chinese
-    - python: 2.7
-      env: FULL_DEPS=true
-    - python: 3.2
-      env: FULL_DEPS=true
-
-  allow_failures:
-    - python: 2.7
-      env: VBENCH=true
+      env: NOSE_ARGS="not slow" FULL_DEPS=true
     - python: 3.2
-      env: FULL_DEPS=true
+      env: NOSE_ARGS="not slow" FULL_DEPS=true
 
 # allow importing from site-packages,
 # so apt-get python-x works for system pythons

CONTRIBUTING.md

@@ -1 +1,70 @@
-Please see [Developers](http://pandas.pydata.org/developers.html) page on the project website.
+Guidelines
+---
+
+All contributions, bug reports, bug fixes, documentation improvments,
+enhancements and ideas are welcome.
+
+The Github "issues" tab contains some issues labels "Good as first PR", these are
+tasks which do not require deep knowledge of the package. Look those up if you're
+looking for a quick way to help out.
+
+Please try and follow these guidelines, as this makes it easier for us to accept
+your contribution or address the issue you're having.
+
+- When submitting a bug report:
+  - Please include a short, self-contained python snippet.
+  - Specify the pandas version used. (you can check `pandas.__version__`).
+  - Explain what the expected behavior was, and what you saw instead.
+
+- When submitting a Pull Request
+  - **Make sure the test suite passes**., and that means on python3 as well.
+    You can use "test_fast.sh", or tox locally and/or enable Travis-CI on your fork.
+  - We suggest you enable Travis-CI on your fork, to make it easier for the team
+     to see that the PR does indeed pass all the tests.
+  - Back-compatiblitiy **really** matters. Pandas already has a large user-base and
+    a lot of existing user code. Don't break old code if you can avoid it
+    Explain the need if there is one in the PR.
+    Changes to method signatures should be made in a way which doesn't break existing
+    code, for example you should beware of changes to ordering and naming of keyword
+    arguments. Add deprecation warnings when needed.
+  - Performance matters. You can use the included "test_perf.sh"
+    script to make sure your PR does not introduce any performance regressions
+    in the library.
+  - **Don't** merge upstream into a branch you're going to submit as a PR,
+    This can create all sorts of problems. Use "git rebase" instead. This ensures
+    no merge conflicts occur when you're code is merged by the core team.
+  - An informal commit message format is in effect for the project, please try
+    and adhere to it. View "git log" for examples. Here are some common prefixes
+    along with general guidelines for when to use them:
+      - ENH: Enhancement, new functionality
+      - BUG: Bug fix
+      - DOC: Additions/updates to documentation
+      - TST: Additions/updates to tests
+      - BLD: Updates to the build process/scripts
+      - PERF: Performance improvement
+      - CLN: Code cleanup
+  - Commit messages should have subject line <80 chars, followed by one blank line,
+    and finally a commit message body if there's a need for one.
+  - Please reference the GH issue number in your commit message using GH1234
+    or #1234, either style is fine.
+  - RELEASE.rst and doc/source/vx.y.z.txt contain an on-going changelog for each
+    release as it is worked on. Add entries to these files as needed in
+    a separate commit in your PR, documenting the fix, enhancement or (unavoidable)
+    breaking change.
+  - For extra brownie points, use "git rebase -i" to squash and reorder
+    commits in your PR so that the history makes the most sense. Use your own
+    judgment to decide what history needs to be preserved.
+  - On the subject of [PEP8](http://www.python.org/dev/peps/pep-0008/): yes.
+  - On the subject of massive PEP8 fix PRs touching everything, please consider the following:
+    - They create merge conflicts for people working in their own fork.
+    - They makes git blame less effective.
+    - Different tools / people achieve PEP8 in different styles. This can create
+      "style wars" and churn that produces little real benefit.
+    - If your code changes are intermixed with style fixes, they are harder to review
+      before merging. Keep style fixes in separate commits.
+    - it's fine to clean-up a little around an area you just worked on.
+
+    Having said that, if you still feel a PEP8 storm is in order, go for it.
+
+Please see [Developers](http://pandas.pydata.org/developers.html) page on
+the project website for more details.

README.rst

@@ -2,6 +2,9 @@
 pandas: powerful Python data analysis toolkit
 =============================================
 
+.. image:: https://travis-ci.org/pydata/pandas.png
+        :target: https://travis-ci.org/pydata/pandas
+
 What is it
 ==========
 
@@ -67,6 +70,12 @@ Dependencies
   * `pytz <http://pytz.sourceforge.net/>`__
      * Needed for time zone support with ``date_range``
 
+Highly Recommended Dependencies
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+  * `numexpr <http://code.google.com/p/numexpr/>`__: to accelerate some expression evaluation operations
+       also required by `PyTables`
+  * `bottleneck <http://berkeleyanalytics.com/bottleneck>`__: to accelerate certain numerical operations
+
 Optional dependencies
 ~~~~~~~~~~~~~~~~~~~~~
 
@@ -85,10 +94,25 @@ Optional dependencies
 Installation from sources
 =========================
 
-In the ``pandas`` directory (same one where you found this file), execute::
+To install pandas from source you need ``cython`` in addition to the normal dependencies above,
+which can be installed from pypi::
+
+    pip install cython
+
+In the ``pandas`` directory (same one where you found this file after cloning the git repo), execute::
 
     python setup.py install
 
+or for installing in `development mode <http://www.pip-installer.org/en/latest/usage.html>`__::
+
+    python setup.py develop
+
+Alternatively, you can use `pip` if you want all the dependencies pulled in automatically
+(the optional ``-e`` option is for installing it in
+`development mode <http://www.pip-installer.org/en/latest/usage.html>`__)::
+
+    pip install -e .
+
 On Windows, you will need to install MinGW and execute::
 
     python setup.py build --compiler=mingw32