[SciPy-Dev] adding more window functions to scipy.signal

[Ralf Gommers]

On Sun, Jan 8, 2017 at 12:07 AM, Yuri D'Elia <wavexx at thregr.org> wrote:

> On Fri, Jan 06 2017, Ralf Gommers wrote:
> > Sorry, copy-paste error - should be https://github.com/scipy/
> scipy/pull/6895
> >
> >     but isn't get_window
> >     basically reinventing the concept of the python namespace? Maybe
> >     declare scipy.signal.windows (which already exists!) to be the public
> >     namespace where you find your windows?
> >
> >     Not really. For example, from gh-6895, this (which uses get_window):
> >
> > signal.firwin(80, 0.5, window=('kaiser', 8))
> >
> > is equivalent to:
> >
> > signal.firwin(80, 0.5, window=functools.partial(signal.kaiser, beta=8))
> >
> > Despite the arguments in gh-6895, I'm quite sure that most users prefer
> not to
> > have to know about functools.partial.
> >
> > Agreed that get_window is a bit ugly though ...
>
> [thanks for mentioning this thread in PR#6012]
>
> As I also wrote in the planck PR, I'd move all window functions to the
> windows namespace as well. This is much cleaner. Providing aliases for
> backward-compatibility is trivial. Name clashes go away. I think the
> benefits are pretty clear.
>

Sounds like adding signal.windows to the public API is the consensus -
let's go with that. I'll have a look at preparing a PR for that. Then we
can add all the new windows in the open PRs just there.

Cheers,
Ralf



> We can rewrite get_window so that it simply uses ft.partial anyway, with
> the added exception that, for strings as first arguments, we resolve the
> function in the signal.windows namespace to keep the code concise.
>
> I don't think that knowing 'partial' is bad per se, but using it
> directly in this case would get pretty verbose very often. For
> experimentation, I did like the window=tuple "hack".
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20170111/5e7278b2/attachment.html>