* Thu Jan 11 2018 email@example.com
* update copyirght year
- update to version 0.5.0:
* Dropped support for Python 2.6 and 3.3.
* Update to keep up with "pandas" API changes
* More consistent handling of degenerate linear constraints in
* Fix a crash in "DesignMatrix.__repr__" when "shape == 0"
* Sat Nov 14 2015 firstname.lastname@example.org
- update to version 0.4.1:
* On Python 2, accept "unicode" strings containing only ASCII
characters as valid formula descriptions in the high-level formula
API (:func:`dmatrix` and friends). This is intended as a
convenience for people using Python 2 with "from __future__
import unicode_literals". (See :ref:`py2-versus-py3`.)
* Accept "long" as a valid integer type in the new
:class:`DesignInfo` classes. In particular this fixes errors that
arise on 64-bit Windows builds (where "ndarray.shape" contains
"long" objects), like "ValueError: For numerical factors,
num_columns must be an int."
* Fix deprecation warnings encountered with numpy 1.10
* Wed Jul 22 2015 email@example.com
- Update to version 0.4.0
+ Incompatible changes:
* :class:`EvalFactor` and :meth:`ModelDesc.from_formula` no longer
take an ``eval_env`` argument.
* The :func:`design_matrix_builders` function and the
:meth:`factor_protocol.memorize_passes_needed` method now require an
``eval_env`` as an additional argument.
* The :class:`DesignInfo` constructor's arguments have totally
changed. In addition to the changes needed to support the new
features below, we no longer support "shim" DesignInfo objects that
have non-trivial term specifications. This was only included in the
first place to provide a compatibility hook for competing formula
libraries; four years later, no such libraries have shown up. If one
does, we can re-add it, but I'm not going to bother maintaining it
in the mean time...
* Dropped support for Python 3.2.
+ Other changes:
* Patsy now supports Pandas's new (version 0.15 or later) categorical
* Formulas (or more precisely, :class:`EvalFactor` objects) now only
keep a reference to the variables required from their environment
instead of the whole environment where the formula was
defined. (Thanks to Christian Hudon.)
* :class:`DesignInfo` has new attributes
:attr:`DesignInfo.factor_infos` and :attr:`DesignInfo.term_codings`
which provide detailed metadata about how each factor and term is
* As a result of the above changes, the split between
:class:`DesignInfo` and :class:`DesignMatrixBuilder` is no longer
necessary; :class:`DesignMatrixBuiler` has been eliminated. So for
example, :func:`design_matrix_builders` now returns a list of
:class:`DesignInfo` objects, and you can now pass
:class:`DesignInfo` objects directly to any function for building
design matrices. For compatibility, :class:`DesignInfo` continues to
provide ``.builder`` and ``.design_info`` attributes, so that old
code should continue to work; however, these attributes are
* Ensured that attempting to pickle most Patsy objects raises an
error. This has never been supported, and the interesting cases
failed in any case, but now we're taking a more systematic
approach. (Soon we will add real, supported pickling support.)
* Fixed a bug when running under ``python -OO``.
- update to version 0.3.0:
* New stateful transforms for computing natural and cylic cubic
splines with constraints, and tensor spline bases with
constraints. (Thanks to @broessli and GDF Suez for contributing
* Dropped support for Python 2.5 and earlier.
* Switched to using a single source tree for both Python 2 and
* Added a fast-path to skip NA detection for inputs with boolean
dtypes (thanks to Matt Davis for patch).
* Incompatible change: Sometimes when building a design matrix for a
formula that does not depend on the data in any way, like "1 ~ 1",
we have no way to determine how many rows the resulting matrix
should have. In previous versions of patsy, when this occurred we
simply returned a matrix with 1 row. In 0.3.0+, we instead refuse
to guess, and raise an error.
Note that because of the next change listed, this situation occurs less frequently in 0.3.0 than in previous versions.
* If the data argument to :func:`build_design_matrices` (or derived
functions like :func:`dmatrix`, :func:`dmatrices`) is a
:class:`pandas.DataFrame`, then we now check its number of rows
and index, and insist that the output design matrices match. This
also means that if data is a DataFrame, then the error described
in the first bullet above cannot occur -- we will simply return a
column of 1s that is the same size as the input dataframe.
* Worked around some more limitations in py2exe/py2app and friends.
* update copyright year
* changed README to README.rst