Well, my motivation to quibble over the *exact definition of "crash"* has
certainly gone :-(

(To be fair it wasn't strong in the first place. I've read your edits but
they just don't seem... substantive enough to care about? I guess you
probably have some stronger problems you were hoping to sneak up on this
way or something? I don't really know. But it is true that you haven't
convinced me that anything in this PR is worth my time.)

On Thu, Apr 10, 2014 at 10:09 PM, Robert Bradshaw
<notifications@github.com>wrote:

> In doc/neps/return-of-revenge-of-matmul-pep.rst:
>
> > @@ -165,11 +167,13 @@ For ``numpy.matrix`` objects, ``*`` performs matrix multiplication,
> >  and elementwise multiplication requires function syntax.  Writing code
> >  using ``numpy.ndarray`` works fine.  Writing code using
> >  ``numpy.matrix`` also works fine.  But trouble begins as soon as we
> > -try to integrate these two pieces of code together.  Code that expects
> > -an ``ndarray`` and gets a ``matrix``, or vice-versa, may crash or
> > +try to integrate these two pieces of code together.  ``numpy.matrix``
> > +subclasses ``numpy.ndarray`` so code that expects an ``ndarray``
> > +and gets a ``matrix``, or vice-versa, may crash or worse
>
> Personally, I have read a lot of accepted PEPs to understand the reasoning
> behind them, but if your motivation to justify it now that it has gotten in
> is gone, so be it.
> … <#1454d7916a90b217_>
> On Thu, Apr 10, 2014 at 12:33 PM, njsmith <notifications@github.com>
> wrote: In doc/neps/return-of-revenge-of-matmul-pep.rst: > @@ -165,11
> +167,13 @@ For ``numpy.matrix`` objects, ``*`` performs matrix
> multiplication, > and elementwise multiplication requires function syntax.
> Writing code > using ``numpy.ndarray`` works fine. Writing code using >
> ``numpy.matrix`` also works fine. But trouble begins as soon as we > -try
> to integrate these two pieces of code together. Code that expects > -an
> ``ndarray`` and gets a ``matrix``, or vice-versa, may crash or > +try to
> integrate these two pieces of code together. ``numpy.matrix`` > +subclasses
> ``numpy.ndarray`` so code that expects an ``ndarray`` > +and gets a
> ``matrix``, or vice-versa, may crash or worse Hey Robert, The PEP's
> accepted and @ is implemented in Python mainline. It's probably not worth
> spending our time at this point trying to figure out the exact best
> phrasing for describing exactly why np.matrix is problematic in different
> situations. -n — Reply to this email directly or view it on GitHub<
> https://github.com/njsmith/numpy/pull/1/files#r11502907> .
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/njsmith/numpy/pull/1/files#r11506641>
> .
>



-- 
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org