[SciPy-Dev] GSoC proposal draft: Add type hints on scipy.special

[Joshua Wilson]

> I couldn't understand why that is a problem for the development phase, since I could work on my fork and change the numpy dependency to point directly at numpy's master, rather than to an already released version, would that be acceptable?

This is generally undesirable-developing software in isolation against
unreleased versions has a number of risks; e.g.

- The released version ends up being different
- It's harder to get feeback (so you risk building the wrong
thing)-commit early and often is the right approach
- It leads to one giant PR at the end-those are _really hard_ to
review, and usually everyone involved ends up frustrated (e.g. it
could take me months to find the time to review something large)

For a newer contributor who isn't as steeped in the overall direction
of scipy.special I'd be particularly worried.

> I don't understand how I should declare that my stubs are referencing the functions instantiated on the .pyf, is there such a thing as a .pyfi ?

You would want to generate stubs for the extension module that f2py
will generate. If we take special/specfun.pyf as an example you'd end
up with:

specfun.pyf <- input
specfunmodule.c <- generated extension module; when compiled gives a
module importable as "specfun"
specfun.pyi <- now we want to generate these stubs from the pyf


On Sat, Apr 3, 2021 at 11:33 AM Gabriel Simonetto
<gabrielfranksimonetto at gmail.com> wrote:
>
> Hey Joshua, thanks for the answer!
>
> I was looking into your points and I would like to ask for your opinion on them:
>
> 1) For the Numpy versions, I couldn't understand why that is a problem for the development phase, since I could work on my fork and change the numpy dependency to point directly at numpy's master, rather than to an already released version, would that be acceptable?
>
> 2) I was looking for how that would work and found the _generate_pyx.py responsible for generating some automated stubs related to C code, but haven't gotten very far with the f2py file. My problem with it is that since the fortran functions aren't exposed, I don't understand how I should declare that my stubs are referencing the functions instantiated on the .pyf, is there such a thing as a .pyfi ?
>
> I am sorry if my question implies a lack of understanding of both typing and the f2py mechanisms, I am fairly new to these topics. It's a shame I couldn't find your branch to better explore my shortcomings! Is there a chance you know where it is?
>
> So... I will try my best to enrich my proposal, but chances are that I won't be able to make it so much better than it already is, given my lack of experience, and that understanding type interactions would be something that I would need to pick upon before the coding period starts.
>
> I need to be honest about the fact that I don't already have the expertise to do the job, and I would like to know if it's expected to pick things up as the project happens, or if for this job in particular it wouldn't be possible to learn so much stuff on so little time (or something like that)
>
> Looking forward to any inputs, I appreciate the advice very much!
>
>
>
> Em qui., 1 de abr. de 2021 às 00:15, Joshua Wilson <josh.craig.wilson at gmail.com> escreveu:
>>
>> Hey Gabriel,
>>
>> One thing to consider is that a large chunk of special is ufuncs, and
>> better ufunc typing is going to need PRs like
>>
>> https://github.com/numpy/numpy/pull/18417
>>
>> which aren't yet in a released version of NumPy. So you'll want to
>> make sure the timing works out there.
>>
>> You mention .pyf files in the doc, they are an interesting case
>> because ideally we'd be able to auto-generate stubs for them. I even
>> have a languishing branch somewhere that has a start on doing that...
>> there are a few complications because the objects exported by the pyf
>> extension module are actually instances of one class, so you'd need to
>> either fudge the typing a bit or use Generic a lot.
>>
>> I'd recommend thinking through how to handle the above complications
>> and discussing that in the doc.
>>
>> - Josh (also the person142 mentioned in the doc)
>>
>> On Wed, Mar 31, 2021 at 5:42 PM Gabriel Simonetto
>> <gabrielfranksimonetto at gmail.com> wrote:
>> >
>> > Hi everyone!
>> >
>> > I finished making a rough draft of what I would like to do for this year's gsoc, could someone give me some tips on how to improve it?
>> >
>> > In particular I would like to know if this is a good module for the project or if it would be better allocated elsewhere, and how could I make my timeline a bit sharper.
>> >
>> > Here is the link for adding comments: https://docs.google.com/document/d/1d3NkbQC9rBcoKkuOmsx95wYDO_OMA5m1PBSu_oiwQVw/edit?usp=sharing
>> >
>> > Thanks!
>> > Gabriel Simonetto
>> > _______________________________________________
>> > SciPy-Dev mailing list
>> > SciPy-Dev at python.org
>> > https://mail.python.org/mailman/listinfo/scipy-dev
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev