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 <sebast...@sipsolutions.net> 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
