fixed conflict in sql.py

Author: duozhang

.gitattributes

@@ -0,0 +1,15 @@
+* text=auto
+# enforce text on certain files
+*.py text
+*.pyx text
+*.pyd text
+*.c text
+*.h text
+*.html text
+*.csv text
+*.json text
+*.pickle binary
+*.h5 binary
+*.dta binary
+*.xls binary
+*.xlsx binary

.gitignore

@@ -13,6 +13,7 @@ MANIFEST
 *.so
 *.pyd
 *.h5
+*.dta
 pandas/version.py
 doc/source/generated
 doc/source/_static
@@ -33,3 +34,4 @@ pandas/io/*.json
 .idea/libraries/sass_stdlib.xml
 
 .idea/pandas.iml
+.build_cache_dir

.travis.yml

@@ -2,31 +2,21 @@ 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" UPLOAD=true
 
 matrix:
   include:
     - python: 2.7
-      env: VBENCH=true
+      env: NOSE_ARGS="slow and not network"  LOCALE_OVERRIDE="zh_CN.GB18030" FULL_DEPS=true UPLOAD=false
     - 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 UPLOAD=true
     - python: 3.2
-      env: FULL_DEPS=true
+      env: NOSE_ARGS="not slow" FULL_DEPS=true UPLOAD=true
+    - python: 3.3
+      env: NOSE_ARGS="not slow" UPLOAD=true
 
 # allow importing from site-packages,
 # so apt-get python-x works for system pythons
@@ -37,11 +27,13 @@ virtualenv:
 before_install:
   - echo "Waldo1"
   - echo $VIRTUAL_ENV
+  - df
   - date
-  - export PIP_ARGS=-q # comment this this to debug travis install issues
-  - export APT_ARGS=-qq # comment this to debug travis install issues
+  # - export PIP_ARGS=-q # comment this this to debug travis install issues
+  # - export APT_ARGS=-qq # comment this to debug travis install issues
   # - set -x # enable this to see bash commands
-  - source ci/before_install.sh # we need to source this to bring in the env
+  - export ZIP_FLAGS=-q # comment this to debug travis install issues
+  - ci/before_install.sh
   - python -V
 
 install:

CONTRIBUTING.md

@@ -1,5 +1,4 @@
-Guidelines
----
+###Guidelines
 
 All contributions, bug reports, bug fixes, documentation improvments,
 enhancements and ideas are welcome.
@@ -12,34 +11,70 @@ 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__`).
+  - Please include a short, self-contained python snippet reproducing the problem.
+  You can have the code formatted nicely by using [GitHub Flavored Markdown](http://github.github.com/github-flavored-markdown/) :
+
+    ```
+    ```python
+
+    print("I ♥ pandas!")
+
+    ``'
+    ```
+
+  - Specify the pandas (and numpy) version used. (you can check `pandas.__version__`).
   - Explain what the expected behavior was, and what you saw instead.
+  - If the issue seems to involve some of pandas' dependencies such as matplotlib
+    or PyTables, you should include (the relavent parts of) the output of
+    [ci/print_versions.py](https://github.com/pydata/pandas/blob/master/ci/print_versions.py)
 
 - 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.
+    See the "Getting Travis-CI going" below.
   - 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.   
+    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.
+  - docstrings follow the [numpydoc](https://github.com/numpy/numpy/blob/master/doc/HOWTO_DOCUMENT.rst.txt) format.
   - **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. Use a "ENH: ", "TST:", "BUG:", "DOC:", etc' prefix in
-    your commit title. Check the output of "git log" for examples.
-  - 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.
+    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.
+  - Use "raise AssertionError" rather then plain `assert` in library code (using assert is fine
+    for test code). python -o strips assertions. better safe then sorry.
+  - When writing tests, don't use "new" assertion methods added to the unittest module
+    in 2.7 since pandas currently supports 2.6. The most common pitfall is:
+
+    with self.assertRaises(ValueError):
+         foo
+
+    which fails on python 2.6, use `self.assertRaises(TheException,func,args)` instead.
+
+  - doc/source/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.
@@ -52,8 +87,58 @@ your contribution or address the issue you're having.
     - 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.
+    - Generally its a BAD idea to PEP8 on documentation.
 
     Having said that, if you still feel a PEP8 storm is in order, go for it.
 
+### Notes on plotting functions convention
+
+https://groups.google.com/forum/#!topic/pystatsmodels/biNlCvJPNNY/discussion
+
+###Getting Travis-CI going
+
+Instructions for getting Travis-CI installed are available [here](http://about.travis-ci.org/docs/user/getting-started/). For those users who are new to travis-ci and continuous-integration in particular,
+Here's a few high-level notes:
+- Travis-CI is a free service (with premium account available), that integrates
+well with Github.
+- Enabling Travis-CI on your github fork of a project will cause any *new* commit
+pushed to the repo to trigger a full build+test on Travis-CI's servers.
+- All the configuration for travis's builds is already specified by .travis.yml in the repo,
+That means all you have to do is enable Travis-CI once, and then just push commits
+and you'll get full testing across py2/3 with pandas's considerable test-suite.
+- Enabling travis-CI will attach the test results (red/green) to the Pull-Request
+page for any PR you submit. For example:
+
+    https://github.com/pydata/pandas/pull/2532,
+
+See the Green "Good to merge!" banner? that's it.
+
+This is especially important for new contributors, as memebers of the pandas dev team
+like to know the test suite passes before considering it for merging.
+Even regular contributors who test religiously on their local box (using tox
+for example) often rely on a PR+travis=green to make double sure everything
+works ok on another system, as occasionally, it doesn't.
+
+####Steps to enable Travis-CI
+
+- go to https://travis-ci.org/
+- "Sign in with Github", on top panel.
+- \[your username\]/Account, on top-panel.
+- 'sync now' to refresh the list of repos on your GH account.
+- flip the switch on the repos you want Travis-CI enabled for,
+"pandas" obviously.
+- Then, pushing a *new* commit to a certain branch on that repo
+will trigger a build/test for that branch, for example the branch
+might be "master" or "PR1234_fix_all_the_things", if that's the
+name of your PR branch.
+
+You can see the build history and current builds for your fork
+on: https://travis-ci.org/(your_GH_username)/pandas.
+
+For example, the builds for the main pandas repo can be seen at:
+https://travis-ci.org/pydata/pandas.
+
+####More developer docs
+
 Please see [Developers](http://pandas.pydata.org/developers.html) page on
 the project website for more details.

LICENSES/OTHER

@@ -29,4 +29,52 @@ SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
 INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
 CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
 ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
-POSSIBILITY OF SUCH DAMAGE.
+POSSIBILITY OF SUCH DAMAGE.
+
+google-api-python-client license
+--------------------------------
+
+Copyright (C) 2012 Google Inc.
+All rights reserved.
+
+Licensed under the Apache License, Version 2.0 (the "License");
+you may not use this file except in compliance with the License.
+You may obtain a copy of the License at
+
+     http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+
+Pyperclip v1.3 license
+----------------------
+
+Copyright (c) 2010, Albert Sweigart
+All rights reserved.
+
+BSD-style license:
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions are met:
+    * Redistributions of source code must retain the above copyright
+      notice, this list of conditions and the following disclaimer.
+    * Redistributions in binary form must reproduce the above copyright
+      notice, this list of conditions and the following disclaimer in the
+      documentation and/or other materials provided with the distribution.
+    * Neither the name of the pyperclip nor the
+      names of its contributors may be used to endorse or promote products
+      derived from this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY Albert Sweigart "AS IS" AND ANY
+EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+DISCLAIMED. IN NO EVENT SHALL Albert Sweigart BE LIABLE FOR ANY
+DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

LICENSES/ULTRAJSON_LICENSE

@@ -0,0 +1,34 @@
+Copyright (c) 2011-2013, ESN Social Software AB and Jonas Tarnstrom
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions are met:
+    * Redistributions of source code must retain the above copyright
+      notice, this list of conditions and the following disclaimer.
+    * Redistributions in binary form must reproduce the above copyright
+      notice, this list of conditions and the following disclaimer in the
+      documentation and/or other materials provided with the distribution.
+    * Neither the name of the ESN Social Software AB nor the
+      names of its contributors may be used to endorse or promote products
+      derived from this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
+ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+DISCLAIMED. IN NO EVENT SHALL ESN SOCIAL SOFTWARE AB OR JONAS TARNSTROM BE LIABLE
+FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+
+Portions of code from MODP_ASCII - Ascii transformations (upper/lower, etc)
+http://code.google.com/p/stringencoders/
+Copyright (c) 2007  Nick Galbreath -- nickg [at] modp [dot] com. All rights reserved.
+
+Numeric decoder derived from from TCL library
+http://www.opensource.apple.com/source/tcl/tcl-14/tcl/license.terms
+ * Copyright (c) 1988-1993 The Regents of the University of California.
+ * Copyright (c) 1994 Sun Microsystems, Inc.

MANIFEST.in

@@ -1,6 +1,6 @@
 include MANIFEST.in
 include LICENSE
-include RELEASE.rst
+include RELEASE.md
 include README.rst
 include TODO.rst
 include setup.py

Makefile

@@ -1,11 +1,27 @@
-clean:
+.PHONY : clean develop build clean clean_pyc tseries doc
+
+clean: clean_pyc
 	-rm -rf build dist
+	-find . -name '*.so' -exec rm {} \;
+
+clean_pyc:
+	-find . -name '*.pyc' -or -name '*.pyo' -exec rm {} \;
 
 tseries: pandas/lib.pyx pandas/tslib.pyx pandas/hashtable.pyx
 	python setup.py build_ext --inplace
 
 sparse: pandas/src/sparse.pyx
-	-python setup.py build_ext --inplace
+	python setup.py build_ext --inplace
+
+build: clean_pyc
+	python setup.py build_ext --inplace
+
+develop: build
+	-python setup.py develop
 
-test: sparse
-	-python pandas/tests/test_libsparse.py
+doc:
+	-rm -rf doc/build
+	-rm -rf doc/source/generated
+	cd doc; \
+	python make.py clean; \
+	python make.py html