File python-patsy.changes of Package python-patsy

Sun May  8 07:03:49 UTC 2016 -

- specfile:
  * updated source url to

Sat Nov 14 21:08:57 UTC 2015 -

- 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 12:04:39 UTC 2015 -

- 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
    this code.)
  * Dropped support for Python 2.5 and earlier.
  * Switched to using a single source tree for both Python 2 and
    Python 3.
  * 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.
- specfile:
  * update copyright year
  * changed README to README.rst
Tue Oct 22 14:02:31 UTC 2013 -

- Initial version (0.2.1)