[Numpy-discussion] ENH: Proposal to add atleast_nd function

[Ralf Gommers]

On Wed, Feb 17, 2021 at 9:26 PM Oscar Benjamin <oscar.j.benjamin at gmail.com>
wrote:

> On Wed, 17 Feb 2021 at 10:36, Ralf Gommers <ralf.gommers at gmail.com> wrote:
> >
> > On Wed, Feb 17, 2021 at 12:26 AM Stefan van der Walt <
> stefanv at berkeley.edu> wrote:
> >>
> >> Ralf has been working towards this idea, but having a well-organised
> namespace of utility functions outside of the core NumPy API would be
> helpful in allowing expansion and experimentation, without making the
> current situation worse (where we effectively have to support things
> forever).  As an example, take Cartesian product [0] and array combinations
> [1], which have been requested several times on StackOverflow, but there's
> nowhere to put them.
> >
> > This is a good point. If we could put it in `numpy.lib` without it
> bleeding into the main namespace, saying yes here would be easier. Maybe we
> can give it a conditional yes based on that namespace reorganization?
>
> As an aside is this numpy.lib idea explained anywhere?
>

It isn't, but it's relatively straightforward and can be done without
thinking about the issues around our other namespaces. Basically:
- today `numpy.lib` is a public but fairly useless namespace, because its
contents get star-imported to the main namespace; only subsubmodules like
`numpy.lib.stride_tricks` are separate
- we want to stop this star-importing, which required some tedious work of
fixing up how we handle __all__ dicts in addition to making exports explicit
- then, we would like to use `numpy.lib` as a namespace for utilities and
assorted functionality that people seem to want, but does not meet the bar
for the main namespace and doesn't fit in our other decent namespace (fft,
linalg, random, polynomial, f2py, distutils).
- TBD if there should be subsubmodules under `numpy.lib` or not
- it should be explicitly documented that this is a "lower bar namespace"
and that we discourage other array/tensor libraries from copying its API

We had a good discussion about this in the community meeting yesterday.
Sebastian volunteered to sort out the star-import issue.


> I've been thinking about something possibly similar for sympy which
> also has a bloated top-level namespace (and has no other place for
> public API to go).
>

A larger plan for cleaning up main namespace bloat, as well as dealing with
our unmaintained namespaces (numpy.dual, numpy.emath, etc.) is still needed.

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/numpy-discussion/attachments/20210218/f3b4bb55/attachment.html>