Re: Result objects for scipy.sparse.csgraph

--===============1877628347867965939==
Content-Type: multipart/alternative; boundary="000000000000b9b714061354a79a"

--000000000000b9b714061354a79a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Mar 7, 2024 at 4:39=E2=80=AFAM <[email protected]> wrote:

> Hi all,
>
> I'd like to raise the idea of updating the ``scipy.sparse.csgraph`` API t=
o
> use result objects rather than a mutable return signature. This was raise=
d
> by Jake from [scipy-20187](https://github.com/scipy/scipy/pull/20187) and
> I think he has the right idea. Specifically I agree with:
>
> "These mutating signatures tend to be quite nasty especially as it doesn'=
t
> save on computation. Elsewhere in SciPy we often use results objects"
>
> Should there be some effort to rework the csgraph API to utilise a result
> object?
>

I don't think so. While we have learned that it is typically not good API
design with `return_xxx` keywords that control how many return values a
function has, the problems that such keywords create really aren't large
enough to justify breaking changes to an otherwise well-designed API.
Moreover, result objects don't quite solve the problems with static typing
or being friendly to JIT compilers - that remains unchanged.

Result objects in `optimize`, `integrate` and `stats` are useful to collect
many return values, and they can also help with making functions extensible
(adding extra/optional return values). But those aren't problems that the
csgraph functions have.

Cheers,
Ralf

--000000000000b9b714061354a79a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Thu, Mar 7, 2024 at 4:39=E2=80=AFA=
M &lt;<a href=3D"mailto:[email protected]">[email protected]</a>&gt; =
wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all,<b=
r>
<br>
I&#39;d like to raise the idea of updating the ``scipy.sparse.csgraph`` API=
 to use result objects rather than a mutable return signature. This was rai=
sed by Jake from [scipy-20187](<a href=3D"https://github.com/scipy/scipy/pu=
ll/20187" rel=3D"noreferrer" target=3D"_blank">https://github.com/scipy/sci=
py/pull/20187</a>) and I think he has the right idea. Specifically I agree =
with:<br>
<br>
&quot;These mutating signatures tend to be quite nasty especially as it doe=
sn&#39;t save on computation. Elsewhere in SciPy we often use results objec=
ts&quot;<br>
<br>
Should there be some effort to rework the csgraph API to utilise a result o=
bject?<br></blockquote><div><br></div><div>I don&#39;t think so. While we h=
ave learned that it is typically not good API design with `return_xxx` keyw=
ords that control how many return values a function has, the problems that =
such keywords create really aren&#39;t large enough to justify breaking cha=
nges to an otherwise well-designed API. Moreover, result objects don&#39;t =
quite solve the problems with static typing or being friendly to JIT compil=
ers - that remains unchanged.</div><div><br></div><div>Result objects in `o=
ptimize`, `integrate` and `stats` are useful to collect many return values,=
 and they can also help with making functions extensible (adding extra/opti=
onal return values). But those aren&#39;t problems that the csgraph functio=
ns have.</div><div><br></div><div>Cheers,<br></div><div>Ralf</div><div><br>=
</div></div></div>

--000000000000b9b714061354a79a--

--===============1877628347867965939==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
SciPy-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/scipy-dev.python.org/
Member address: [email protected]

--===============1877628347867965939==--