[Numpy-discussion] Removing `np.f2py.compile`

[Rohit Goswami]

Hello.
As part of the spring cleanup for NumPy 2.0 I'm soliciting opinions on the 
removal of the numpy.f2py.compile() function (documented here 
(https://link.getmailspring.com/link/937e4c5c-47d5-40d9-89bb-8fc04b19d...@getmailspring.com/0?redirect=https%3A%2F%2Fnumpy.org%2Fdoc%2Fstable%2Ff2py%2Fusage.html%23python-module-numpy-f2py&recipient=bnVtcHktZGlzY3Vzc2lvbkBweXRob24ub3Jn)).
 The associated issue is gh-25122 
(https://link.getmailspring.com/link/937e4c5c-47d5-40d9-89bb-8fc04b19d...@getmailspring.com/1?redirect=https%3A%2F%2Fgithub.com%2Fnumpy%2Fnumpy%2Fissues%2F25122&recipient=bnVtcHktZGlzY3Vzc2lvbkBweXRob24ub3Jn).
 Here are the main points against it:
Hasn't been updated (beyond compatibility) in 18 years

Is a (not great) wrapper around subprocess.run

Leaks memory (noted in this test case 
(https://link.getmailspring.com/link/937e4c5c-47d5-40d9-89bb-8fc04b19d...@getmailspring.com/2?redirect=https%3A%2F%2Fgithub.com%2Fnumpy%2Fnumpy%2Fblob%2F9340fcaeda5aa783a76ab356a58f52b9f76debe3%2Fnumpy%2Ff2py%2Ftests%2Ftest_compile_function.py%23L26&recipient=bnVtcHktZGlzY3Vzc2lvbkBweXRob24ub3Jn))

As for why now..
After the meson transition, the -c workflow is mostly to generate a skeleton
Many of the older -c flags are not coming back (since parsing build arguments 
and forwarding them to meson is basically resurrecting distutils )

It still generates a .so file in the working directory which is weird at best
.. and likely to be very broken very often in practice

The expectation that -c based builds work exactly the same post meson is not 
correct, and removing this function would also make downstream users come check 
the new documentation 
(https://link.getmailspring.com/link/937e4c5c-47d5-40d9-89bb-8fc04b19d...@getmailspring.com/3?redirect=https%3A%2F%2Fnumpy.org%2Fdevdocs%2Ff2py%2Fusage.html%23building-a-module&recipient=bnVtcHktZGlzY3Vzc2lvbkBweXRob24ub3Jn)

Projects should generate their own subprocess.run wrappers for the post meson 
f2py , so they can set the environment variables to interact with meson or 
provide native files...

All said, it also seems to be mostly 
(https://link.getmailspring.com/link/937e4c5c-47d5-40d9-89bb-8fc04b19d...@getmailspring.com/4?redirect=https%3A%2F%2Fgithub.com%2Fsearch%3Fq%3Df2py.compile%26type%3Dcode&recipient=bnVtcHktZGlzY3Vzc2lvbkBweXRob24ub3Jn)
 (but not completely) unused. Happy to hear thoughts against / for this, though 
the default assumption is going to be remove it :)
--- Rohit
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com

[Numpy-discussion] Re: Policy on AI-generated code

[Rohit Goswami]

> Personally, I wouldn't (as a maintainer)...

Especially since I know that many potential contributors may not have 
English as their first language so stunted language / odd patterns are 
not **always** an AI indicator, sometimes its just inexperience.


-- Rohit

On 7/4/24 3:03 PM, Daniele Nicolodi wrote:

On 04/07/24 12:49, Matthew Brett wrote:

Hi,

Sorry to top-post!  But - I wanted to bring the discussion back to
licensing.  I have great sympathy for the ecological and code-quality
concerns, but licensing is a separate question, and, it seems to me,
an urgent question.


The licensing issue is complex and it is very likely that it will not 
get a definitive answer until a lawsuit centered around this issue is 
litigated in court. There are several lawsuits involving similar 
issues ongoing, but any resolution is likely to take several years.


Providing other, much more pragmatic and easier to gauge, reasons to 
reject AI generated contributions, I was trying to sidestep the 
licensing issue completely.


If there are other reasons why auto-generated contributions should be 
rejected, there is no need to solve the much harder problem of 
licensing: we don't want them regardless of the licensing issue.


Cheers,
Dan

___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: rgosw...@quansight.com___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com

[Numpy-discussion] Re: Policy on AI-generated code

[Rohit Goswami]

Doesn't the project adopting wording of this kind "pass the buck" onto 
the maintainers? At the end of the day, failure to enforce our stated 
policy will be not only the responsibility of the authors but also the 
reviewers / maintainers on whole. In effect (and just speaking 
personally) wording like this would make it less likely for me as a 
maintainer to review PRs with questionable content (potentially avoiding 
new contributors who are human but not very aware of their tools / are 
junior / new contributors), because I don't want to be implicated in 
attesting to the validity of possibly copyright infringing code. I am of 
course not against the exact wording or the spirit, and the details are 
probably best hammered out on a PR if we decide it makes sense to try to 
catch AI generated / assisted work (though I'm not sure we should)..


Perhaps not very related, but at my Uni we recently decided it took too 
much effort for us to try to make sure no one was using AI tools than to 
simply *grade*, and I think the same spirit applies here as well.


--- Rohit

On 7/4/24 3:18 PM, Daniele Nicolodi wrote:

On 04/07/24 13:29, Matthew Brett wrote:

I agree it is hard to enforce, but it seems to me it would be a
reasonable defensive move to say - for now - that authors will need to
take full responsibility for copyright, and that, as of now,
AI-generated code cannot meet that standard, so we require authors to
turn off AI-generation when writing code for Numpy.


I like this position.

I wish it for be common sense for contributors to an open source 
codebase that they need to own the copyright on their contributions, 
but I don't think it can be assumed. Adding something to these lines 
to the project policy has also the potential to educate the 
contributions about the pitfalls of using AI to autocomplete their 
contributions.


Cheers,
Dan
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: rgosw...@quansight.com___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com

[Numpy-discussion] Re: spam on the mailing lists

[Rohit Goswami]

Although it is true that discourse is easier for newcomers in a lot of ways, it 
is far worse for governance and consensus. The mailing list, by having 
essentially sequential topics sent out to all subscribers is easier to keep 
track of than a large number of forum topics.
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com

[Numpy-discussion] Re: spam on the mailing lists

[Rohit Goswami]

To add to that, while it is redundant to maintain both a mailing list and a 
discourse, the latter requires significantly more moderation and policy (eg. 
What happens if users delete posts / accounts).

It is a non trivial amount of work which I think should not be underestimated. 
A lot of other communities I'm part of have made the shift, but it has been 
undertaken to grow users, not to facilitate mailing list activities.

1. Nix discourse moderation team rfc - -> https://github.com/NixOS/rfcs/pull/102
2. Fortran Lang discourse moderation and coc - - > 
https://fortran-lang.discourse.group/t/welcome-to-discourse/7

There are many others but in particular, even if we go for a discourse we 
should still keep the mailing list for low volume, wide reach activity. At 
which point we're back to the original problem of spam.

---
Rohit
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com

[Numpy-discussion] Re: spam on the mailing lists

[Rohit Goswami]

I guess then the approach overall would evolve to something like using the 
mailing list to announce discourse posts which need input. Though I would 
assume that the web interface essentially makes the mailing list almost like 
discourse, even for new users.

The real issue IMO is still the moderation efforts and additional governance 
needed for maintaining discourse.
---
Rohit
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com

[Numpy-discussion] Re: spam on the mailing lists

[Rohit Goswami]

I’m firmly against GH discussions because of the upvoting mechanism. We don’t 
need to be Reddit or SO. .NET had a bad experience with the discussions as well 
[1].

[1] https://github.com/dotnet/aspnetcore/issues/29935

— Rohit

On 1 Oct 2021, at 15:04, Andras Deak wrote:

> On Fri, Oct 1, 2021 at 4:27 PM Ilhan Polat  wrote:
>
>> The reason why I mentioned GH discussions is that literally everybody who
>> is engaged with the code, is familiar with the format, included in the
>> codebase product and has replies in built unlike the Discourse (opinion is
>> mine) useless flat discussion design where replies are all over the place
>> just like the mailing list in case you are not using a tree view supporting
>> client. Hence topic hijacking is one of the main usability difficulties of
>> emails.
>>
>> The goal here is to have a coherent engagement with everyone not just
>> within a small circle, such that there is indeed a discussion happening
>> rather than a few people chiming in. It would be a nice analytics exercise
>> to have how many active users using these lists. I'd say 20-25 max for
>> contribs and team members which is really not much. I know some people are
>> still using IRC and mailing lists but I wouldn't argue that these are the
>> modern media to have proper engaging discussions. "Who said to whom" is the
>> bread and butter of such discussions. And I do think that discourse is
>> exactly the same thing with mailing lists with a slightly better UI while
>> virtually everyone else in the world is doing replies.
>>
>
> (There are probably a lot of users like myself who follow the mailing list
> discussions but rarely feel the need to speak up themselves. Not that this
> says much either way in the discussion, just pointing it out).
>
> I'm not intimately familiar with github discussions (I've only used it a
> few times), but as far as I can tell it only has answers (or "comments")
> and comments (or "replies") on answers, i.e. 2 levels of replies rather
> than a flat single level of replies. If this is indeed the case then I'm
> not sure it's that much better than a flat system, since when things really
> get hairy then 2 levels are probably also insufficient to ensure "who said
> to whom". The "clear replies" argument would hold stronger (in my
> peanut-gallery opinion) for a medium that supports full reply trees like
> many comment sections do on various websites.
>
> András
>
>
>> I would be willing to help with the objections raised since I have been
>> using GH discussions for quite a while now and there are many tools
>> available for administration of the discussions. For example,
>>
>>
>> https://github.blog/changelog/2021-09-14-notification-emails-for-discussions/
>>
>> is a recent feature. I don't work for GitHub obviously and have nothing to
>> do with them but the reasons I'm willing to hear about.
>>
>>
>>
>>
>>
>>
>> On Fri, Oct 1, 2021 at 3:07 PM Matthew Brett 
>> wrote:
>>
>>> Hi,
>>>
>>> On Fri, Oct 1, 2021 at 1:57 PM Rohit Goswami 
>>> wrote:
>>>>
>>>> I guess then the approach overall would evolve to something like using
>>> the mailing list to announce discourse posts which need input. Though I
>>> would assume that the web interface essentially makes the mailing list
>>> almost like discourse, even for new users.
>>>>
>>>> The real issue IMO is still the moderation efforts and additional
>>> governance needed for maintaining discourse.
>>>
>>> Yes - that was what I meant.   I do see that mailing lists are harder
>>> to moderate, in that once the email has gone out, it is difficult to
>>> revoke.  So is the argument just that you *can* moderate on Discourse,
>>> therefore you need to think about it more?  Do we have any reason to
>>> think that more moderation will in fact be needed?  We've needed very
>>> little so far on the mailing list, as far as I can see.
>>>
>>> Chers,
>>>
>>> Matthew
>>> ___
>>> NumPy-Discussion mailing list -- numpy-discussion@python.org
>>> To unsubscribe send an email to numpy-discussion-le...@python.org
>>> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
>>> Member address: ilhanpo...@gmail.com
>>>
>> ___
>> NumPy-Discussion mailing list -- numpy-discussion@python.org
>> To unsubscrib

[Numpy-discussion] Re: Documentation Team meeting - Monday October 11

[Rohit Goswami]

It works if the entire link is copied into the browser.
—
Rohit
On 11 Oct 2021, at 19:07, Rumanu Bhardwaj wrote:

> I'm not able to join without the meeting password ;-;
>
> On Mon, 11 Oct, 2021, 4:46 am Melissa Mendonça,  wrote:
>
>> Hi all!
>>
>> Our next Documentation Team meeting will be on *Monday, October 11* at ***4PM
>> UTC***.
>>
>> All are welcome - you don't need to already be a contributor to join. If
>> you have questions or are curious about what we're doing, we'll be happy to
>> meet you!
>>
>> If you wish to join on Zoom, use this link:
>>
>> https://zoom.us/j/96219574921?pwd=VTRNeGwwOUlrYVNYSENpVVBRRjlkZz09#success
>>
>> Here's the permanent hackmd document with the meeting notes (still being
>> updated in the next few days!):
>>
>> https://hackmd.io/oB_boakvRqKR-_2jRV-Qjg
>> 
>>
>> Hope to see you around!
>>
>> ** You can click this link to get the correct time at your timezone:
>> https://www.timeanddate.com/worldclock/fixedtime.html?msg=NumPy+Documentation+Team+Meeting&iso=20211011T16&p1=1440&ah=1
>>
>> *** You can add the NumPy community calendar to your google calendar by
>> clicking this link: https://calendar.google.com/calendar
>> /r?cid=YmVya2VsZXkuZWR1X2lla2dwaWdtMjMyamJobGRzZmIyYzJqODFjQGdyb3VwLmNhbGVuZGFyLmdvb2dsZS5jb20
>>
>> - Melissa
>> ___
>> NumPy-Discussion mailing list -- numpy-discussion@python.org
>> To unsubscribe send an email to numpy-discussion-le...@python.org
>> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
>> Member address: rumanubhard...@gmail.com
>>

> ___
> NumPy-Discussion mailing list -- numpy-discussion@python.org
> To unsubscribe send an email to numpy-discussion-le...@python.org
> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> Member address: rgosw...@quansight.com
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com

[Numpy-discussion] Re: Speeding up __array_function__ by moving to C (interest in pushing that forward?)

[Rohit Goswami]

This seems fun. I should have some time for a few weeks after the 20th (Uni 
vacation) if no one else takes it up by then.
—
Rohit

On 8 Dec 2021, at 15:55, Sebastian Berg wrote:

> Hi all,
>
> is anyone interested in digging into speeding up __array_function__?  I
> distracted myself briefly looking into moving (more) of it to C and got
> up with this:
>
> https://github.com/numpy/numpy/compare/main...seberg:faster-array-function
>
> The effect seems to be an up to 40% speed improvement for very
> lightweight functions.  (There may be more room for improvement but I
> am not sure how much and it should not be as easy.)
>
>
> I had never really tried this before, because on older Python versions
> it was just slower/harder to jump between C and Python.  That was due
> to the lack of "vectorcall", now it is all there, although for PyPy it
> might still need fixups.
>
> The main point is moving the object that we replace our functions with
> (the entry point) to C [1].  This works, but it was a one-evening quick
> try, so it needs a lot of polishing:
>
> * Fixing `like=` for Python defined functions:  They are broken, I have
>   one possible approach, but it is just an "idea stage".
>   (should not be hard, but needs a some thought)
> * Make sure the C entry-point looks and feel right, such as printing
>   (I am not sure what is left to do here, maybe we can find prior art?)
> * Enable pickling (should be very easy)
> * Ensure PyPy compatibility if necessary
> * Change all warning `stacklevel=` to one lower (in wrapped functions).
>   (simple, but a lot of churn)
> * General code cleanup
>
> Thought I would put it out there.  It might be a cool and worthwhile
> project for someone interested in decreasing overheads and familiar
> with the Python C-API.
>
> Cheers,
>
> Sebastian
>
>
> [1] This also avoids the need for packing `args` and `kwargs` into a
> tuple/dict, which is faster, even if we have to pack it again for
> `__array_function__` (we can avoid it for the NumPy version though).
> I had wondered if we could evolve `__array_function__` to accept
> `*args, **kwargs`.  I expect this is only useful if
> `__array_function__` was defined in C though.
> ___
> NumPy-Discussion mailing list -- numpy-discussion@python.org
> To unsubscribe send an email to numpy-discussion-le...@python.org
> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> Member address: rgosw...@quansight.com

signature.asc
Description: OpenPGP digital signature
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com

[Numpy-discussion] Re: Numpy array

[Rohit Goswami]

Agreed, however, the[ NumPy learn section of the official 
documentation](https://numpy.org/learn/) is probably a better place to 
point to (though your article is justifiably also linked from there).


---
Rohit

On 27 Jan 2022, at 16:15, Lev Maximov wrote:


Hi,

I believe this question fits Stack Overflow better.

Here're SO guidelines on how to create a minimal reproducible example:
https://stackoverflow.com/help/minimal-reproducible-example

If you're new to NumPy I'd recommend this visual guide:
https://betterprogramming.pub/numpy-illustrated-the-visual-guide-to-numpy-3b1d4976de1d

Best regards,
Lev

On Thu, Jan 27, 2022 at 8:19 PM  wrote:


Hi, i am new to numpy. This is first time i am using numpy.

https://github.com/mspieg/dynamical-systems/blob/master/Bifurcations.ipynb

This code i found to create bifurcation graph. There is section of 
code

which i am not able to understand

vr[stable], vx[stable]

vr and vx is array of 150 elements.
unstable and stable array also has 150 elements

But vr[stable], vx[stable] becomes 75 elements in the array. Which i 
am

not able to umderstand how 150 elements in array drops to 75
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: lev.maxi...@gmail.com




___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: rgosw...@quansight.com___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com

[Numpy-discussion] Re: Dropping the pdf documentation.

[Rohit Goswami]

Being very hard to read should not be reason enough to stop generating 
them. In places with little to no internet connectivity often the PDF 
documentation is invaluable.


I personally use the PDF documentation both on my phone and e-reader 
when I travel simply because it is more accessible and has better search 
capabilities.


It is true that SciPy has removed them, but that doesn't necessarily 
mean we need to follow suit. Especially relevant (IMO) is that large 
parts of the NumPy documentation still make sense when read sequentially 
(going back to when it was at some point partially kanged from Travis' 
book).


I'd be happy to spend time (and plan to) working on fixing concrete 
issues other than straw-man and subjective arguments.


Personally I'd like to see the NumPy documentation have PDFs in a 
fashion where each page / chapter can be downloaded individually.


-- Rohit

P.S.: If we have CI timeout issues, for the PDF docs we could also have 
a dedicated repo and only build for releases.


P.P.S: FWIW the Python docs are also still distributed in PDF form.

On 22 May 2022, at 21:41, Stephan Hoyer wrote:


+1 let’s drop the PDF docs. They are already very hard to read.

On Sun, May 22, 2022 at 1:06 PM Charles R Harris 


wrote:


Hi All,

This is a proposal to drop the generation of pdf documentation and 
only
generate the html version. This is a one way change due to the 
difficulty

maintaining/fixing the pdf versions. See minimal discussion here
 
.


Chuck
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: sho...@gmail.com




___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: rgosw...@quansight.com___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com

[Numpy-discussion] Re: Dropping the pdf documentation.

[Rohit Goswami]

The HTML docs can also be downloaded for offline use.


HTML documentation isn't easy to navigate on anything other than a 
laptop / tablet. It also makes it confusing when there isn't an internet 
connection because of the external links. Also it is hard (subjectively) 
to read in order.


Also more subjective points:
- A PDF can be annotated
- A PDF can be bookmarked
- A PDF has a separate reading app / device from browsing
- A PDF can be printed out (yes sometimes this might still be useful)


Perhaps someone has access to analytics from 
[numpy.org](http://numpy.org) that can tell us how often the PDF docs 
are viewed?


It would be interesting to see the comparison between the downloads of 
the offline HTML documentation and the PDF documentation.


I don't think it's worth the trouble of the separate rendering 
pipeline for a relatively niche use-case.


We might end up going that way, but it would be a shame IMO. Though 
splitting it out might be useful. Python documentation is packaged into 
chapters which are self contained and reasonably readable. We should 
strive for the same.


As we move increasingly towards different kinds of content 
(blogs/notebooks/tutorials), I think we should try to keep all users in 
mind and PDF generation is hardly on its way out in any language / 
library.


--- Rohit

On 22 May 2022, at 23:28, Stephan Hoyer wrote:


On Sun, May 22, 2022 at 3:52 PM Rohit Goswami 
wrote:

Being very hard to read should not be reason enough to stop 
generating

them. In places with little to no internet connectivity often the PDF
documentation is invaluable.


The HTML docs can also be downloaded for offline use.

Perhaps someone has access to analytics from numpy.org that can tell 
us how
often the PDF docs are viewed? I believe PDFs could be more convenient 
for
some use-cases, but I don't think it's worth the trouble of the 
separate

rendering pipeline for a relatively niche use-case.



___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: rgosw...@quansight.com___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com

[Numpy-discussion] Re: Dropping the pdf documentation.

[Rohit Goswami]

I am unaware of the state of the SciPy documentation at the time it was 
dropped. However, many of these arguments do not seem to apply to the 
NumPy documentation hosted at https://numpy.org/doc/.


The typography is \\subsubpar (as a TeX person should say) and just an 
eyesore, this actually matters a lot more than you would assume and 
unreadable in mobile without constant zooming because of nonresponsive 
format


This is a valid concern, but there are third-party tools to deal with 
reflow (both at the mobile level and by preprocessing like with 
k2pdfopt: https://www.willus.com/k2pdfopt/)


Almost all links are broken and left as double backticks since it is 
not originally designed for PDF navigation


There are no broken links in our User Guide, and even external links 
(e.g. `PyObject` links to the Python documentation) work. Internal links 
to different parts of the PDF also work.


I have not read our Reference Guide cover to cover in a while (other 
than the NumPy-C API chapter) but I do not remember any backticks 
anywhere. Please correct me if this is incorrect.


Code copy/pasting is broken (due to how the TeX package for listings 
setup) regardless of the PDF viewer


This isn't the case for Firefox's PDF viewer and others I have tried 
(Adobe, Zathura). Though on Linux most pdf copy-pastes can be a little 
difficult.


It is mostly empty space hence bloats the page number because it comes 
from the HTML format and not the other way around as say, TeX4ht 
workflow would follow.


Untrue, our typography and layout might not be perfect but we do not 
have a lot of empty space.


It is an absolute waste of resources on CI/CD since it fires up per 
Pull Request (maybe we can argue to reduce it to per main-branch-merge 
but doesn't change the fact that it is just wasteful and burdensome)


We have a reasonable 30 minute timeout for the `pdf` build and we have 
discussed running this less frequently.



Like Ralf mentioned the infrastructure for a TeX run is unacceptable 
for today's standards (but it is the LaTeX maintainers to blame for it 
and I know some of them, they know this very well and trying hard to 
reduce it)


Also can be mitigated, we can shift to `tectonic` or simply use a custom 
`texlive` install to have less packages (for the size issue).


It is a very unstable workflow and errors out depending on the planets 
alignment because, again, it is coming from an awkward Markdown source 
which is not designed for. Becomes very annoying for maintainers to 
see it fail for otherwise a perfectly valid code.


We don't have markdown sources?

I understand that perhaps SciPy's documentation was in far worse shape 
than NumPy, but we shouldn't paint with a broad brush.


-- Rohit

On 23 May 2022, at 8:41, Ilhan Polat wrote:

As the person initiated the PDF drop in SciPy, I'd give my reasoning 
for

why it bugged me in the first place

- The typography is \subsubpar (as a TeX person should say) and just 
an

eyesore, this actually matters a lot more than you would assume and
unreadable in mobile without constant zooming because of nonresponsive
format
- Almost all links are broken and left as double backticks since it is 
not

originally designed for PDF navigation
- Code copy/pasting is broken (due to how the TeX package for listings
setup) regardless of the PDF viewer
- It is mostly empty space hence bloats the page number because it 
comes
from the HTML format and not the other way around as say, TeX4ht 
workflow

would follow.
- It is an absolute waste of resources on CI/CD since it fires up per 
Pull

Request (maybe we can argue to reduce it to per main-branch-merge but
doesn't change the fact that it is just wasteful and burdensome)
- Like Ralf mentioned the infrastructure for a TeX run is unacceptable 
for
today's standards (but it is the LaTeX maintainers to blame for it and 
I
know some of them, they know this very well and trying hard to reduce 
it)
- It is a very unstable workflow and errors out depending on the 
planets

alignment because, again, it is coming from an awkward Markdown source
which is not designed for. Becomes very annoying for maintainers to 
see it

fail for otherwise a perfectly valid code.

The API reference PDF (7.2 mb) is also difficult to find compared to 
the
front page version which is the User guide (3.x mb). So probably there 
is
no demand for it anyways because it didn't cause too much noise as far 
as I

know.







On Mon, May 23, 2022 at 8:34 AM Ralf Gommers  
wrote:





On Mon, May 23, 2022 at 6:51 AM Matti Picus  
wrote:




On 23/5/22 01:51, Rohit Goswami wrote:


Being very hard to read should not be reason enough to stop 
generating
them. In places with little to no internet connectivity often the 
PDF

documentation is invaluable.

I personally use the PDF documentation both on my phone and 
e-reader

when I travel simply because it is more accessible and has better
search capabili

[Numpy-discussion] Re: Dropping the pdf documentation.

[Rohit Goswami]

The contents are nonresponsive. No tool can fix a native 
responsiveness issues.  I am familiar with those tools. The questions 
is why work so hard when you have the HTML already?


I'm afraid I don't understand this argument. It is true that PDFs are 
not responsive without software assistance, but HTML documents when 
printed (e.g. CTRL+P) do not have any way of generating the Appendix / 
outlinks to related sections etc. Yet we still have HTML documentation. 
IMO this simply means they are not mutually exclusive.


This is demonstrably true, the document margins are against quite a 
few technical document typography rules (mostly how page setup and 
typeface choices are done). It is as it is because the documentation 
is also following an indentation format very much like Python code 
which uses whitespace too generously. The document itself is quite an 
eyesore if you care about those things.np.einsum is a prime example 
how it shouldn't render in a PDF document. All choices are coming from 
the indentation of markdown. Because it uses none of the advantages of 
a PDF. That is typography and font layout. It cannot use it because 
the source is not providing context. Because it is coming from a 
function signature. This is also related to Markdown comment below.


About this, the full page layout on the HTML pages has exactly the same 
amount of whitespace. It can be argued that for a full width layout 
there is exactly the same whitespace and indentation.


Additionally, even trying to print out say, `np.einsum` will first have 
3 pages of the sidebar when using a naive CTRL+P approach.


The argument that the typography is poor goes beyond the documentation 
format.


In fact, even the "responsiveness" is rather overrated at the moment. 
With a mobile device again the first few screenfulls are simply the 
sidebar with routines and other things. After which there's still 
whitespace, and things are still just as indented as in the PDF. Only 
now I also don't have a global TOC which is easy to see.


The assertion that there is parity between serving ~2000 pages of 
documentation as HTML and ZIP files as opposed to a PDF seems to be 
flawed from the get go.


If you want to have a proper doc effort, that is a whole another story 
and I would love to have that but this doc generated PDF is not worth 
of any nonnegligable value.


I should add that NumPy does indeed have a dedicated docs team and 
consolidated effort. As mentioned earlier we meet regularly about these 
issues and it would be nice if the meetings are not unequivocally 
sidestepped by the mailing list. We also apply for funding (GSoD / 
NumFocus SDG) for our docs.


I understand there are frustrations with the PDF, but I am still not 
convinced at this point that the HTML versions are even at par with the 
PDF experience.


It is nice that I have the time and ability to generate my documentation 
locally for my niche needs should I so wish it. It is less nice that we 
assume that it must be niche and everyone would have the same energy 
because HTML is theoretically more responsive, even though our docs are 
not.


-- Rohit


On 23 May 2022, at 11:08, Ilhan Polat wrote:

On Mon, May 23, 2022 at 11:12 AM Rohit Goswami 


wrote:

I am unaware of the state of the SciPy documentation at the time it 
was
dropped. However, many of these arguments do not seem to apply to the 
NumPy

documentation hosted at https://numpy.org/doc/.

They were almost identical, same machinery (like most things). Well 
this is

subjective but the typography is unfit for any code based format.

The typography is \\subsubpar (as a TeX person should say) and just 
an

eyesore, this actually matters a lot more than you would assume and
unreadable in mobile without constant zooming because of 
nonresponsive

format

This is a valid concern, but there are third-party tools to deal with
reflow (both at the mobile level and by preprocessing like with 
k2pdfopt:

https://www.willus.com/k2pdfopt/)

The contents are nonresponsive. No tool can fix a native 
responsiveness
issues.  I am familiar with those tools. The questions is why work so 
hard

when you have the HTML already?

There are no broken links in our User Guide, and even external links 
(e.g.

PyObject links to the Python documentation) work. Internal links to
different parts of the PDF also work.

I have not read our Reference Guide cover to cover in a while (other 
than
the NumPy-C API chapter) but I do not remember any backticks 
anywhere.

Please correct me if this is incorrect.

OK this one was on me. I've updated the reader and now things went 
back to

normal. Sorry for the noise.


This isn't the case for Firefox's PDF viewer and others I have tried
(Adobe, Zathura). Though on Linux most pdf copy-pastes can be a 
little

difficult.

 All mentioned viewers fail to retain the format of the code and copy 
as
text. You should paste it to somewhere to get the prob

[Numpy-discussion] Re: Dropping the pdf documentation.

[Rohit Goswami]

The argument is about why one should use PDF on a mobile device. I am 
not even going to bother with the argument. The world moved on. See 
any app on your device.


Lets agree to not talk about the world here a bit, user profiles vary. I 
have three browser apps true, but also a bunch of PDF readers.


But in any case, lets talk about the UX a bit.

We are assuming that instead of downloading one document and using that 
when there is no internet:

- Go to pg. 50 on numpy-ref.pdf

We would instead be:
- Explaining how to unzip things on a mobile (default file managers are 
not guaranteed to come with zip support)
- Explaining how to use offline HTML (or even better, have them find the 
file of interest and open that with the local path)
- Tell someone to either use the search or navigate the rather baroque 
mobile interface to find something


Because the average user in a low network area is clearly going to be 
aware of all this.


Mostly because we don't believe PDFs are viable. Also, the Reference 
Manual is exactly what I'd expect from a technical manual. The argument 
is on the other side, that trying to actually read or use the HTML 
document as a replacement for the Reference Manual is rather unlikely.


Again, the intents differ, perhaps for something like SciPy, a 
user-focused library, a reference manual enumerating API design and 
decisions doesn't make much sense. NumPy has a lot of design 
documentation which is kanged from an actual book...



Again, you are comparing doc formats.


Nope, it is the information content and ease of access, see usage 
pattern above for an offline developer.


It is not overrated. You are basically saying UX people are just doing 
bloated fancy work. This is not how things are designed.


This is not what I meant at all, I have a deep love for frontend work, I 
was merely pointing out that at this point in time I don't think our 
"responsive" HTML is any better than our "broken" PDFs. I think we'd be 
hard pressed to find anyone saying the current HTML documentation 
follows best responsive practices (the sidebar should be minimized, I 
shouldn't have to scroll for tens of seconds to get to text I was 
looking for, the list goes on)


That's why we are proposing to remove it. Otherwise it wouldn't be 
discussed here and removed in SciPy.


Removed in SciPy really needs to stop being part of this discussion. 
Unless we want to merge the projects back together; we don't *have* to 
evolve in lock-step. Hence the discussion.


If there is a demand for it we don't see it anywhere. Glad that we are 
aggressively agreeing.


Why do we expect people to request a document we already provide? This 
is the first time we have this on the mailing list, so we should simply 
defer the discussion. We can add analytics to the `/doc` page and check 
back in a few releases. IMO the argument about "load" is a bit 
fallacious, we don't actually seem to be generating or serving PDFs per 
commit (but I might be wrong).


Also, definitely not agreeing at all yet :)

Also HTML responsiveness need no proof. Just look at the page source 
on your browser and change the size of your window. The docs are 
responsive though not perfect (it collapses to the wrong frame in the 
smallest size for example but fixable) but definitely much more 
readable.


Here are some steps to reproduce the mobile experience. They rely on 
either using an actual mobile device or "web inspector" or "developer 
tools":


- Switch to a standard format, and watch the sidebar take up most of the 
real-estate

- Try using the zip as discussed above

Additionally, I really don't intend to bash on the HTML, of course we 
could add more breakpoints, and special casing until it looks / behaves 
better.


Until we do so, the removal of the PDFs seem awkward.

As for CI load and metrics, we don't have hard numbers for a lot of 
these things and it feels strange to discuss what we feel is 
"responsible use".


--- Rohit

P.S. By happy coincidence, I see we have an upcoming documentation 
meeting in around 3 hours. As always, everyone is welcome to come 
discuss here: https://hackmd.io/oB_boakvRqKR-_2jRV-Qjg


On 23 May 2022, at 12:42, Ilhan Polat wrote:


On Mon, May 23, 2022 at 2:00 PM Rohit Goswami 
wrote:

The contents are nonresponsive. No tool can fix a native 
responsiveness
issues.  I am familiar with those tools. The questions is why work so 
hard

when you have the HTML already?

I'm afraid I don't understand this argument. It is true that PDFs are 
not
responsive without software assistance, but HTML documents when 
printed
(e.g. CTRL+P) do not have any way of generating the Appendix / 
outlinks to
related sections etc. Yet we still have HTML documentation. IMO this 
simply

means they are not mutually exclusive.

The argument is about why one should use PDF on a mobile device.

[Numpy-discussion] GSoC Student Announcement 2022

[Rohit Goswami]

NumPy as a sub-organization under the Python Software Foundation organization 
will be mentoring a summer student this year funded by the Google Summer of 
Code program. Ralf facilitated the application process and I will be the 
primary mentor this year (with Gagandeep for support). Please look forward to 
work done by our mentee, Namami Shankar who will be working on F2PY and in 
particular our front-end.

His proposal entitled "Restructuring the F2PY frontend and replacing the build 
system" can be found here: 

https://summerofcode.withgoogle.com/media/user/a7128bebaf4c/proposal/bMbhENWPCCwdVFL3.pdf
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com

[Numpy-discussion] Re: Congratulation to our newest maintainer Mukulika Pahari

[Rohit Goswami]

Wonderful news! Very well deserved. Congratulations and welcome, Mukulika!
--- Rohit
On Jan 27 2023, at 1:20 pm, Charles R Harris  wrote:
>
>
> On Fri, Jan 27, 2023 at 3:23 AM Matti Picus  (mailto:matti.pi...@gmail.com)> wrote:
> > The NumPy steering council recently granted maintainer rights to
> > Mukulika Pahari (https://github.com/Mukulikaa/)
> >
> >
> > Mukulika was recently elected to co-lead the numpy documentation team,
> > and has been active in reviewing documentation issues and PRs. Welcome
> > and thanks for all you do.
> > Matti
>
>
> This is a great addition. Welcome Mukulika.
>
> Chuck
> ___
> NumPy-Discussion mailing list -- numpy-discussion@python.org
> To unsubscribe send an email to numpy-discussion-le...@python.org
> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> Member address: rgosw...@quansight.com

___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com

[Numpy-discussion] GSoC Participation

[Rohit Goswami]

Last year we took with SciPy under the PSF with Ralf taking care of admin 
duties. We had a great contributor (Namami [1]) and I think solid progress was 
made for F2PY. SciPy is currently considering applying again this year [1], 
with Hameer stepping up to take the administrative burden if there is enough 
interest. I think even though GSoC (and Google in general) has been a little 
weird about the program requirements, its still good PR and is a good vehicle 
for onboarding contributors. I would be willing to mentor a student towards 
finishing up the F2PY derived type support [2] which mostly needs examples and 
finding rough edges in the design. It would be great to have it through for 
NumPy 2.0

Other project ideas would be much appreciated as well.

[1] https://namamishanker.github.io/posts/gsoc-closing-remarks/
[2] 
https://mail.python.org/archives/list/scipy-...@python.org/thread/A4KU7WVR77HAIJFUDTTJYOVY535NT7Y2/
[3] https://github.com/HaoZeke/f2py_derived_nep
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com

[Numpy-discussion] Re: dropping support for Gitpod and our Docker image builds

[Rohit Goswami]

I'm in favor of dropping Gitpod, IMO during sprints as well, it yielded less 
utility than expected initially, and breaks far too often (as summarized 
above). It would also be good to be free from docker rot given their recent 
changes.
--- Rohit

On Mar 20 2023, at 9:09 pm, Ralf Gommers  wrote:
> Hi all,
>
> We received a notification from Docker that there Free Team organization no 
> longer exists, and that we have until April 14 to upgrade to a paid tier. We 
> only use Docker to support Gitpod. Gitpod builds have been broken in main for 
> quite a while (see 
> https://github.com/numpy/numpy/actions/workflows/gitpod.yml 
> (https://link.getmailspring.com/link/26a16109-f730-429d-b189-c4597c5af...@getmailspring.com/0?redirect=https%3A%2F%2Fgithub.com%2Fnumpy%2Fnumpy%2Factions%2Fworkflows%2Fgitpod.yml&recipient=bnVtcHktZGlzY3Vzc2lvbkBweXRob24ub3Jn)).
>  Since it's a cron job that doesn't show up on PRs, but I get the 
> notifications.
>
> Overall, Gitpod has been useful during some sprints, but it has proven to be 
> too much maintenance effort. Maintaining a Docker team, CI jobs for building 
> 2 Docker images, and a nontrivial amount of code and docs is no longer a good 
> tradeoff.
>
> Here is what we have related to Gitpod:
> https://github.com/numpy/numpy/tree/main/tools/gitpod 
> (https://link.getmailspring.com/link/26a16109-f730-429d-b189-c4597c5af...@getmailspring.com/1?redirect=https%3A%2F%2Fgithub.com%2Fnumpy%2Fnumpy%2Ftree%2Fmain%2Ftools%2Fgitpod&recipient=bnVtcHktZGlzY3Vzc2lvbkBweXRob24ub3Jn)
> https://github.com/numpy/numpy/blob/main/.github/workflows/docker.yml 
> (https://link.getmailspring.com/link/26a16109-f730-429d-b189-c4597c5af...@getmailspring.com/2?redirect=https%3A%2F%2Fgithub.com%2Fnumpy%2Fnumpy%2Fblob%2Fmain%2F.github%2Fworkflows%2Fdocker.yml&recipient=bnVtcHktZGlzY3Vzc2lvbkBweXRob24ub3Jn)
> https://github.com/numpy/numpy/blob/main/.github/workflows/gitpod.yml 
> (https://link.getmailspring.com/link/26a16109-f730-429d-b189-c4597c5af...@getmailspring.com/3?redirect=https%3A%2F%2Fgithub.com%2Fnumpy%2Fnumpy%2Fblob%2Fmain%2F.github%2Fworkflows%2Fgitpod.yml&recipient=bnVtcHktZGlzY3Vzc2lvbkBweXRob24ub3Jn)
> https://github.com/numpy/numpy/blob/main/doc/source/dev/development_gitpod.rst
>  
> (https://link.getmailspring.com/link/26a16109-f730-429d-b189-c4597c5af...@getmailspring.com/4?redirect=https%3A%2F%2Fgithub.com%2Fnumpy%2Fnumpy%2Fblob%2Fmain%2Fdoc%2Fsource%2Fdev%2Fdevelopment_gitpod.rst&recipient=bnVtcHktZGlzY3Vzc2lvbkBweXRob24ub3Jn)
> https://hub.docker.com/u/numpy 
> (https://link.getmailspring.com/link/26a16109-f730-429d-b189-c4597c5af...@getmailspring.com/5?redirect=https%3A%2F%2Fhub.docker.com%2Fu%2Fnumpy&recipient=bnVtcHktZGlzY3Vzc2lvbkBweXRob24ub3Jn)
>
> We have a reasonable alternative, which is GitHub Codespaces. All it 
> currently requires is ~lines of simple to understand code 
> (https://github.com/numpy/numpy/tree/main/.devcontainer 
> (https://link.getmailspring.com/link/26a16109-f730-429d-b189-c4597c5af...@getmailspring.com/6?redirect=https%3A%2F%2Fgithub.com%2Fnumpy%2Fnumpy%2Ftree%2Fmain%2F.devcontainer&recipient=bnVtcHktZGlzY3Vzc2lvbkBweXRob24ub3Jn))
>  and no CI jobs. We have one tracking issue for feedback in case you try it 
> and find gaps: https://github.com/numpy/numpy/issues/23134 
> (https://link.getmailspring.com/link/26a16109-f730-429d-b189-c4597c5af...@getmailspring.com/7?redirect=https%3A%2F%2Fgithub.com%2Fnumpy%2Fnumpy%2Fissues%2F23134&recipient=bnVtcHktZGlzY3Vzc2lvbkBweXRob24ub3Jn).
>  It doesn't pre-build NumPy locally, but that's only 1-2 minutes of wait time 
> and is something a new contributor anyway has to learn about. The dev 
> environment is reproducible, so this isn't much of a hurdle. We need 
> replacement docs for that, but
 they can be much simpler I'd say. It's basically "go to 
https://github.com/codespaces/ 
(https://link.getmailspring.com/link/26a16109-f730-429d-b189-c4597c5af...@getmailspring.com/8?redirect=https%3A%2F%2Fgithub.com%2Fcodespaces%2F&recipient=bnVtcHktZGlzY3Vzc2lvbkBweXRob24ub3Jn),
 hit the green button, and select the numpy repo, then it'll drop you into a 
VSCode IDE with a ready to go dev env".
>
> So my proposal is to drop all the Docker Hub and Gitpod related code and 
> docs. I have already discussed this with Tania Allard, who did most of the 
> heavy lifting on the initial creation of the Gitpod machinery (for SciPy, 
> which was then synced to NumPy).
>
> Thoughts?
>
> Cheers,
> Ralf
>
> ___
> NumPy-Discussion mailing list -- numpy-discussion@python.org
> To unsubscribe send an email to numpy-discussion-le...@python.org
> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> Member address: rgosw...@quansight.com

___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.o

[Numpy-discussion] Re: update / revision suggest around f2py

[Rohit Goswami]

Please open an issue with the outputs. They should be working correctly. Newer 
Fortran standard support is an ongoing process. 

From: nbehrnd--- via NumPy-Discussion 
Sent: Thursday, 13 April 2023 21:29
To: numpy-discussion@python.org
Cc: nbeh...@yahoo.com
Subject: [Numpy-discussion] update / revision suggest around f2py

Dear maintainers of the documentation, 

Python numpy includes f2py to access functionality (and performance) of Fortran 
modules, which 

https://numpy.org/doc/stable/f2py/f2py.getting-started.html#the-smart-way 

aims to present.  However, I was not able to successfully replicate fully 
either one of the three approaches (the quick way, the smart way, the quick and 
smart way) in an instance of Linux Debian 12/bookworm with gcc and gfortran 
(12.2.0), Python (3.11.2), and f2py (1.24.2) as provided from the repositories 
of Debian's branch testing. 

I would like to suggest an update and a revision of the page in question. 

For one, the snippets of Fortran adhere the (fixed format) standard of 
FORTRAN77, which became "old" with the major revision of Fortran90 (by 
1991/1992) and the introduction of the free format.  With current standard 
Fortran2018 (and Fortran2023 anticipated for July this year) an update of them 
would be very welcome - one still can state (as by now) that multiple standards 
of Fortran are supported. For two and in addition to this, it would be nice if 
the instructions given could be cross checked if they still provide the 
functionality claimed.  If helpful, I can send the captured terminal 
input/output as ASCII text to one of you maintainers in a direct message, too. 

Regards 
___ 
NumPy-Discussion mailing list -- numpy-discussion@python.org 
To unsubscribe send an email to numpy-discussion-le...@python.org 
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ 
Member address: rgosw...@quansight.com 
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com

[Numpy-discussion] Re: Google Season of Docs 2023 participation announcement

[Rohit Goswami]

This is fantastic news!! Congratulations Mars (and Mukulika and Ross and 
everyone else involved with the proposal), definitely well deserved.
--- Rohit

On Apr 28 2023, at 6:51 am, Benny Ifeanyi Iheagwara  
wrote:
> That's awesome news Mars (@marsBarLee) You definitely earned it. Keep up the 
> good work!
>
>
> On Mon, 24 Apr 2023 at 12:43, Mukulika Pahari  (mailto:mukulikapah...@gmail.com)> wrote:
> > Hi all,
> >
> > I am pleased to announce that NumPy has been selected as a participant for 
> > the Google Season of Docs program. This year, the grant will support Mars 
> > (@MarsBarLee) as our technical writer on the "NumPy Contributor Journey 
> > Comics" project. She has been instrumental in improving the NumPy 
> > documentation experience through design and conceived the idea for this 
> > project here- https://github.com/numpy/numpy.org/pull/600. She will share 
> > her detailed implementation plan with us soon.
> > The project proposal can be read here- 
> > https://github.com/numpy/numpy/wiki/Google-Season-of-Docs-2023:-Project-Proposal.
> >  And the full list of selected participants can be seen at 
> > https://developers.google.com/season-of-docs/docs/participants.
> > Also, we are always happy to welcome other documentation contributions on a 
> > volunteer basis. Please check out our community page 
> > (https://numpy.org/community/) if you wish to get involved.
> > Best wishes,
> > Mukulika
> > ___
> > NumPy-Discussion mailing list -- numpy-discussion@python.org 
> > (mailto:numpy-discussion@python.org)
> > To unsubscribe send an email to numpy-discussion-le...@python.org 
> > (mailto:numpy-discussion-le...@python.org)
> > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> > Member address: iheifea...@gmail.com (mailto:iheifea...@gmail.com)
>
>
>
> ___
> NumPy-Discussion mailing list -- numpy-discussion@python.org
> To unsubscribe send an email to numpy-discussion-le...@python.org
> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> Member address: rgosw...@quansight.com

___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com

[Numpy-discussion] Re: Numpy with eigen c++ binding

[Rohit Goswami]

FWIW xtensor is supposed to be more of a drop in C++ replacement.. 

--- Rohit

From: Matthieu Brucher 
Sent: Sunday, 11 June 2023 08:27
To: Discussion of Numerical Python
Subject: [Numpy-discussion] Re: Numpy with eigen c++ binding

What would be the point? You would need to add support in Eigen for most of 
what makes Numpy Numpy. Eigen is really about 2D, Tensors are not even close to 
be something working properly (not even talking about the dynamic number of 
dimensions that breaks), and I'm not talking about broadcasting rules.

Matthieu

Le dim. 11 juin 2023 à 08:38, Lev Maximov  a écrit :
>
> It looks as though pybind11 can serve as a bridge between NumPy and Eigen:
> https://pybind11.readthedocs.io/en/stable/advanced/cast/eigen.html
>
>
> On Sun, Jun 11, 2023 at 2:39 AM Matti Picus  wrote:
>>
>> On 6/6/23 06:46, darshan patel wrote:
>>
>> > it seems like numpy is moving toward c++ implementation, so is there any 
>> > plan to have eigen c++ library also inline with numpy to get better 
>> > performance?
>> > is there any ongoing work happening around this?
>>
>> NumPy does not currently use eigen and I am not aware of any plans to do so.
>>
>> Matti
>>
>> ___
>> NumPy-Discussion mailing list -- numpy-discussion@python.org
>> To unsubscribe send an email to numpy-discussion-le...@python.org
>> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
>> Member address: lev.maxi...@gmail.com
>
> ___
> NumPy-Discussion mailing list -- numpy-discussion@python.org
> To unsubscribe send an email to numpy-discussion-le...@python.org
> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> Member address: matthieu.bruc...@gmail.com



--
Quantitative researcher, Ph.D.
Blog: http://blog.audio-tk.com/
LinkedIn: http://www.linkedin.com/in/matthieubrucher___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com

[Numpy-discussion] Re: How to get numpy.distutils.fcompiler to find my absoft compiler

[Rohit Goswami]

More of a workaround, since it seems like the wrappers and binding files are 
generated could you try the `meson` build following this page in the 
documentation?

https://numpy.org/devdocs/f2py/buildtools/meson.html

`distutils` support is patchy at best, but if the meson build doesn't work the 
bindings might be incorrect, please open an issue in that case. 

--- Rohit


From: Samuel H Dupree Jr 
Sent: Saturday, 29 July 2023 09:33
To: Discussion of Numerical Python
Subject: [Numpy-discussion] How to get numpy.distutils.fcompiler to find my 
absoft compiler

Hello everyone,

I'm trying to wrap some Fortran77 subroutines from the Math77 library using 
f2py3. f2py3 responds with a message:
>>
>>  File 
>> "/Users/user/opt/anaconda3/lib/python3.9/site-packages/numpy/distutils/fcompiler/__init__.py",
>>  line 426, in get_version
>>     raise CompilerNotFound()
>> numpy.distutils.fcompiler.CompilerNotFound

I'm running Python ver. 3.9.17 under the Anaconda distribution (anaconda 
Command line client (version 1.12.0)) on a Mac Pro (2019) under 
Mac OS X Ventura ver. 13.4.1. The Fortran compiler is Absoft Pro Fortran ver. 
22.0.

The set of subroutines to be wrapped were concatenated into a single file named 
divapy.f. The command used to wrap the routines was
>>
>> --fcompiler=absoft --f77exec=/Applications/Absoft22.0/bin/f77 -c -m diva 
>> divapy.f

I've attached a file containing the complete set of messages output by f2py3 
using the command above.

Any suggestions as to how to fix this problem?

Sam Dupree.
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com

[Numpy-discussion] Re: Endorsing SPECs 1, 6, 7, and 8

[Rohit Goswami]

I second Matti's comments about the validity of endorsing things we don't 
implement. 
Also, personally I really dislike the keys to castle spec, because I'm 
generally against having yearly check in reviews and such. 
--- Rohit 



From: Sebastian Berg 
Sent: Monday, October 7, 2024 02:23
To: Discussion of Numerical Python
Subject: [Numpy-discussion] Endorsing SPECs 1, 6, 7, and 8

Hi all, 

TL;DR: NumPy should endorse some or all of the new SPECs if we like 
them.  If you don't or do like them, please discuss, otherwise I 
suspect we will propose and endorsing them soon and do it if a few core 
maintainers agree. 

--- 


The Scientific Python project has the SPEC process to write up helpful 
tips/patterns [1] with the idea that projects "endorse" them to 
indicate that we think following the SPEC is a good idea. 

One example probably known best is SPEC 0, which is NEP 27 (the 
suggested minimum supported versions for dependencies, e.g. 
Python/library versions). 

There has been a lot of work recently to write some new SPECs, and the 
following ones are up for endorsement by NumPy: 

* 1 -- Lazy Loading of Submodules and Functions 
  https://scientific-python.org/specs/spec-0001 
* 6 -- Keys to the Castle 
  https://scientific-python.org/specs/spec-0006/ 
* 7 -- Seeding Pseudo-Random Number Generation 
  https://scientific-python.org/specs/spec-0007/ 
* 8 -- Securing the Release Process 
  https://scientific-python.org/specs/spec-0008/ 

Endorsing them means we think they are good guidance for projects, not 
necessarily strictly following them [2]. 

Without input, I suspect we may endorse them soon (if a few maintainers 
give a thumbs up).  But of course it would be great to discuss and 
maybe improve the SPECs in the progress! 

SPEC 7 is important, because it describes how we would like other 
libraries to use the new random number generation API in the future 
(but actually doesn't apply directly). 

Cheers, 

Sebastian 



[1] The SPECs are not necessarily fixed.  If you think they are missing 
a note/solution, we can modify them. 

[2] With it's flat namespace, I am not sure e.g. lazy-loading is of 
much use to NumPy (just like we have longer compatibility than SPEC 0). 

___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: rgosw...@quansight.com
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com