Re: [Numpy-discussion] Officially drop Python 3.6 from NumPy 1.20 (was: NumPy 1.20.x branch in two weeks)

[Jarrod Millman]

e financial removal slightly more gentle).
> > > > > I am not sure if PyPy already has stable support for 3.7 yet?
> > > > > Although
> > > > > PyPy is maybe not a big priority.
> > > > >
> > > > > We don't have to support 3.6 and I don't care if we do. Until
> > > > > this
> > > > > discussion my assumption was we would probably drop it.
> > > > >
> > > > > But, current master is tested against 3.6, so the main work
> > > > > seems
> > > > > release related. If Chuck thinks that is no hassle I don't mind
> > > > > if
> > > > > NumPy is a bit more conservative than NEP 29.
> > > > >
> > > > > Or is there a danger of setting a precedent where projects are
> > > > > wrongly
> > > > > expected to keep support just because NumPy still has it, so
> > > > > that NumPy
> > > > > not being conservative actually helps everyone?
> > > > >
> > > > > - Sebastian
> > > > >
> > > > >
> > > > > > Thanks all,
> > > > > >
> > > > > > Juan.
> > > > > >
> > > > > > On Mon, 2 Nov 2020, at 2:01 AM, Ralf Gommers wrote:
> > > > > > > On Mon, Nov 2, 2020 at 7:47 AM Stephan Hoyer <
> > > > > > > sho...@gmail.com>
> > > > > > > wrote:
> > > > > > > > On Sun, Nov 1, 2020 at 7:47 PM Stefan van der Walt <
> > > > > > > > stef...@berkeley.edu> wrote:
> > > > > > > > > On Sun, Nov 1, 2020, at 18:54, Jarrod Millman wrote:
> > > > > > > > > > I also misunderstood the purpose of the NEP.  I
> > > > > > > > > > assumed it
> > > > > > > > > > was
> > > > > > > > > > intended to encourage projects to drop old versions
> > > > > > > > > > of
> > > > > > > > > > Python.
> > > > > > >
> > > > > > > It was. It is. I think the NEP is very clear on that.
> > > > > > > Honestly we
> > > > > > > should just follow the NEP and drop 3.6 now for both NumPy
> > > > > > > and
> > > > > > > SciPy, I just am tired of arguing for it - which the NEP
> > > > > > > should
> > > > > > > have prevented being necessary, and I don't want to do
> > > > > > > again right
> > > > > > > now, so this will probably be my last email on this thread.
> > > > > > >
> > > > > > >
> > > > > > > > > Other
> > > > > > > > > > people have viewed the NEP similarly:
> > > > > > > > > > https://github.com/networkx/networkx/issues/4027
> > > > > > > > >
> > > > > > > > > Of all the packages, it makes sense for NumPy to behave
> > > > > > > > > most
> > > > > > > > > conservatively with depreciations. The NEP suggests
> > > > > > > > > allowable
> > > > > > > > > support periods, but as far as I recall does not
> > > > > > > > > enforce
> > > > > > > > > minimal support.
> > > > > > >
> > > > > > > It doesn't *enforce* it, but the recommendation is very
> > > > > > > clear. It
> > > > > > > would be good to follow it.
> > > > > > >
> > > > > > > > > Stephan Hoyer had a good recommendation on how we can
> > > > > > > > > clarify
> > > > > > > > > the NEP to be easier to intuit. Stephan, shall we make
> > > > > > > > > an
> > > > > > > > > ammendment to the NEP with your idea?
> > > > > > > >
> > > > > > > > For reference, here was my proposed revision:
> > > > > > > > https://github.com/numpy/numpy/pull/14086#issuecomment-649287648
> > > > > > > > Specifically, rather than saying "the latest release of
> > > > > > > > NumPy
> > > > > > > > supports all versions of Python released in the 42 mo

Re: [Numpy-discussion] NumPy 1.20.x branch in two weeks

[Jarrod Millman]

I also misunderstood the purpose of the NEP.  I assumed it was
intended to encourage projects to drop old versions of Python.  Other
people have viewed the NEP similarly:
https://github.com/networkx/networkx/issues/4027

If the intention of the NEP is to specify that projects not drop old
version of Python too early, I don't think it is obvious from the NEP.
It would be helpful if you added a simple motivation statement near
the top of the document.  Something like:

## Motivation and Scope

The purpose of the NEP is to ensure projects in the scientific Python
ecosystem don't drop support for old version of Python and NumPy too
soon.

On Sun, Nov 1, 2020 at 6:44 PM Jarrod Millman  wrote:
>
> NetworkX is currently planning to support 3.6 for our coming 2.6
> release (dec 2020) and 3.0 release (early 2021).  We had originally
> thought about following NEP 29.  But I assumed it had been abandoned,
> since neither NumPy nor SciPy dropped Python 3.6 on Jun 23, 2020.
>
> NetworkX is likely to continue supporting whatever versions of Python
> both NumPy and SciPy support regardless of what NEP 29 says.  I
> wouldn't be surprised if other projects do the same thing.
>
> Jarrod
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] NumPy 1.20.x branch in two weeks

[Jarrod Millman]

NetworkX is currently planning to support 3.6 for our coming 2.6
release (dec 2020) and 3.0 release (early 2021).  We had originally
thought about following NEP 29.  But I assumed it had been abandoned,
since neither NumPy nor SciPy dropped Python 3.6 on Jun 23, 2020.

NetworkX is likely to continue supporting whatever versions of Python
both NumPy and SciPy support regardless of what NEP 29 says.  I
wouldn't be surprised if other projects do the same thing.

Jarrod
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Cleaning up Python 2.7 code.

[Jarrod Millman]

Sounds good!
Jarrod

On Thu, Jan 2, 2020 at 4:53 PM Charles R Harris
 wrote:
>
>
>
> On Thu, Jan 2, 2020 at 5:20 PM Jarrod Millman  wrote:
>>
>> Hi Chuck,
>>
>> I just finished doing that for NetworkX and would be happy to start a
>> PR for NumPy tomorrow (assuming there are no objections).
>>
>> Best regards,
>> Jarrod
>
>
> Hi Jarrod,
>
> There are four current PRs making a start on the task, they need review and 
> coordination. If you could help with that it would be a good start. They are 
> tagged with `Py3K`. There are also several related issues with that tag. I 
> think we can also remove Python <= 3.4 stuff, removing 3.5 can probably wait 
> until NumPy 1.20. See https://github.com/numpy/numpy/labels/27%20-%20Py3K for 
> the list of tagged PRs/issues.
>
> 
>
> Chuck
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Cleaning up Python 2.7 code.

[Jarrod Millman]

Hi Chuck,

I just finished doing that for NetworkX and would be happy to start a
PR for NumPy tomorrow (assuming there are no objections).

Best regards,
Jarrod


On Thu, Jan 2, 2020 at 3:53 PM Charles R Harris
 wrote:
>
> Hi All,
>
> Just want to propose cleaning up the Python 2.7 compatibility code for NumPy 
> 1.19. Any objections?
>
> Chuck
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] NetworkX 2.3rc3 released (Python 3 only)

[Jarrod Millman]

I am happy to announce the third **release candidate** for NetworkX
2.3!  NetworkX is a Python package for the creation, manipulation, and
study of the structure, dynamics, and functions of complex networks.

This release supports Python 3.5-3.7 (i.e., this is our first **Python
3 only** release).  Please try out the pre-release and let us know
about any problems you find.  If no major issues arise, we will
release 2.3 final next week.

Please see the draft of the 2.3 release announcement:
  https://networkx.github.io/documentation/latest/release/release_dev.html

Since this is a pre-release, pip won't automatically install it.  So
  $ pip install networkx
still installs networkx-2.2.  But
  $ pip install --pre networkx
will install networkx-2.3rc3.  If you already have networkx installed
then you need to do
  $ pip install --pre --upgrade networkx

For more information, please visit our `website
`_ and our `gallery of examples
`_.
Please send comments and questions to the `networkx-discuss mailing
list `_.

Best regards,
Jarrod
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Adoption of a Code of Conduct

[Jarrod Millman]

+1

Jarrod

On Tue, Aug 14, 2018 at 9:30 PM, Ralf Gommers  wrote:
>
>
> On Fri, Aug 3, 2018 at 1:02 PM, Charles R Harris 
> wrote:
>>
>>
>>
>> On Fri, Aug 3, 2018 at 1:45 PM, Peter Creasey
>>  wrote:
>>>
>>> +1 for keeping the same CoC as Scipy, making a new thing just seems a
>>> bigger surface area to maintain. Personally I already assumed Scipy's
>>> "honour[ing] diversity in..." did not imply any protection of
>>> behaviours that violate the CoC *itself*, but if you wanted to be
>>> really explicit you could add "to the extent that these do not
>>> conflict with this code of conduct." to that line.
>>
>>
>> I prefer that to the proposed modification, short and sweet.
>
>
> This edit to the SciPy CoC has now been merged.
>
> It looks to me like we're good to go here and take over the SciPy CoC.
>
> Cheers,
> Ralf
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Dropping Python 3.4 support for NumPy 1.16

[Jarrod Millman]

+1

On Wed, Jun 13, 2018 at 2:27 PM, Charles R Harris
 wrote:
> Hi All,
>
> I think NumPy 1.16 would be a good time to drop Python 3.4 support. We will
> want to do that anyway once we drop 2.7 so that we will only be using recent
> Windows compilers, and with Python 3.7 due at the end of the month I think
> supporting 3.5-7 for 1.16 should be sufficient.
>
> Thoughts?
>
> Chuck
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] A roadmap for NumPy - longer term planning

[Jarrod Millman]

I like the idea of a random/controversial ideas section.

On Fri, Jun 1, 2018 at 12:11 PM, Ralf Gommers  wrote:
>
>
> On Fri, Jun 1, 2018 at 9:57 AM, Stefan van der Walt 
> wrote:
>>
>> Hi Ralf,
>>
>> On Thu, 31 May 2018 21:57:06 -0700, Ralf Gommers wrote:
>> > - "internal refactorings": MaskedArray yes, but the other ones no.
>> > numpy.distutils and f2py are very hard to test, a big refactor pretty
>> > much
>> > guarantees breakage. there's also not much need for refactoring, because
>> > those things are not coupled to the numpy.core internals.
>> > numpy.financial
>> > is simply uninteresting - we wish it wasn't there but it is, so now it
>> > simply stays where it is.
>>
>> I want to clarify that in the current notes we put down ideas that
>> prompted active discussion, even if they weren't necessarily feasible.
>> I feel it is important to keep the conversation open to run its course
>> until we have a good understanding of the various issues at hand.
>>
>> You may find that, in person, people are more willing to admit to their
>> support for some "heretical" ideas than they are here on the list.
>
>
> Thanks Stefan, good points. I totally agree that anything can be discussed.
>
>>
>>
>> E.g., you say that the financial functions "now simply stay", but that
>> promises a future of a NumPy that never shrinks, while there is
>> certainly some support for allowing NumPy to contract so that we can
>> release maintenance burden and allow development of other core areas
>> that have been neglected for a long time.
>>
>> You will *always* have small, vocal proponents of any specific piece of
>> functionality; that doesn't necessarily mean that such functionality
>> contributes to the health of a project as a whole.
>>
>> So, I gently urge us carefully reconsider the narrative that nothing can
>> change/be removed, and evaluate each suggestion carefully, not weighing
>> only the very evident negatives but also the longer term positives.
>
>
> I don't think there's such a narrative - e.g. the removal of np.matrix that
> we've planned and getting rid of MaskedArray at some point once we have a
> better new masked array implementation are *major* removals. We do plan
> those things because they have major benefits. Imho "major benefits" is a
> bar that needs to be passed before listing features as up for removal on a
> roadmap (even a draft one).
>
> It would be helpful maybe to find a form for the roadmap where the
> essentials of such discussions (key pros/cons) can be captured. Or at least
> split it in good/desirable/planned items and "wild ideas".
>
> Re `financial`, there isn't much of a pro as far as I can tell - there's
> almost zero maintenance cost now, and it doesn't hinder any of the proposed
> new features. Plus it's a discussion we've had a couple of times before.
>
> I know that the current roadmap doc is only draft, but it still says "NumPy
> Roadmap" and it's the best thing we have now, so I'd prefer to not have
> things there (or have them in a separate random/controversial ideas section)
> that are unlikely to happen or for which it's unclear if they're good ideas.
>
> Cheers,
> Ralf
>
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Python 3 compatible examples

[Jarrod Millman]

+1

On Fri, Jun 1, 2018 at 1:43 PM, Juan Nunez-Iglesias  wrote:
>
> On Sat, Jun 2, 2018, at 6:22 AM, Pauli Virtanen wrote:
>> For Scipy, we converted the examples in the documentation to Python 3,
>> and have essentially ignored Python 2 compatibility. So far, I remember
>> no complaints about it.
>
> I vote for what Pauli said.
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] NumPy sprint May 24-25 at BIDS

[Jarrod Millman]

Hi Chuck,

I don't think a bike is necessary.  It is less than a mile from the
Shattuck hotel to BIDS and takes about 10-15 minutes to walk.  It is
also more or less completely flat and most of the walk is on campus.
There are tons of restaurants and stores immediately around the
Shattuck hotel, so the farthest you probably need to travel is from
the hotel to BIDS and back.

Best regards,
Jarrod

On Sun, May 13, 2018 at 10:59 AM, Charles R Harris
 wrote:
>
>
> On Sat, May 12, 2018 at 4:27 PM, Jarrod Millman 
> wrote:
>>
>> Hi Chuck,
>>
>> A few more bits of advice from a local ...
>>
>> Oakland airport is smaller and closer, so I try to use it when I can.
>> But SFO probably has more options and isn't too far away.
>>
>> I prefer Hotel Shattuck Plaza to Hotel Durant.  Shattuck is close to
>> BART.  So you can get on the BART at either SFO or OAK and get off at
>> the Downtown Berkeley station and then walk a short block to your
>> hotel.  Also, Durant is closer to the frat houses, so it can get noisy
>> at certain times (although, classes should be out so that shouldn't be
>> a problem now).
>>
>> Some people prefer to use Airbnb.  If you go that route, I would try
>> to get something near (or on) Euclid Ave. between Hearst and Marin.
>> There is a bus line that runs up and down Euclid every 30 minutes.  It
>> is a pretty and very quiet area (as soon as you get a couple blocks
>> away from campus).  It takes about 30 minutes to walk from the corner
>> of Euclid and Marin to BIDS.  It is all downhill to campus.  (I live
>> near Euclid & Marin and often walk even though I have a bus pass.)
>> Once you get to Euclid and Hearst (i.e., the Northgate to campus), it
>> is a short walk (continuing in the same direction) to BIDS.
>>
>> I am not sure about the hours of the sprint, but I suspect they will
>> be 9ish to 5ish.
>>
>> I hope to see you and others soon!
>
>
> OK, I've reserved at the Shattuck Plaza. There is a bike rental around the
> corner, would you recommend renting a bike ($35/day)?
>
> Chuck
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] NumPy sprint May 24-25 at BIDS

[Jarrod Millman]

Hi Chuck,

A few more bits of advice from a local ...

Oakland airport is smaller and closer, so I try to use it when I can.
But SFO probably has more options and isn't too far away.

I prefer Hotel Shattuck Plaza to Hotel Durant.  Shattuck is close to
BART.  So you can get on the BART at either SFO or OAK and get off at
the Downtown Berkeley station and then walk a short block to your
hotel.  Also, Durant is closer to the frat houses, so it can get noisy
at certain times (although, classes should be out so that shouldn't be
a problem now).

Some people prefer to use Airbnb.  If you go that route, I would try
to get something near (or on) Euclid Ave. between Hearst and Marin.
There is a bus line that runs up and down Euclid every 30 minutes.  It
is a pretty and very quiet area (as soon as you get a couple blocks
away from campus).  It takes about 30 minutes to walk from the corner
of Euclid and Marin to BIDS.  It is all downhill to campus.  (I live
near Euclid & Marin and often walk even though I have a bus pass.)
Once you get to Euclid and Hearst (i.e., the Northgate to campus), it
is a short walk (continuing in the same direction) to BIDS.

I am not sure about the hours of the sprint, but I suspect they will
be 9ish to 5ish.

I hope to see you and others soon!

Best regards,
Jarrod

On Sat, May 12, 2018 at 2:14 PM, Matti Picus  wrote:
> On 10/05/18 04:44, Charles R Harris wrote:
>>
>> On Wed, May 9, 2018 at 2:33 PM, Matti Picus > > wrote:
>>
>> A reminder - we will take advantage of a few NumPy developers
>> being at Berkeley to hold a two day sprint May 24-25
>> https://scisprints.github.io/#may-numpy-developer-sprint
>> 
>> > >.
>> We invite any core contributors who would like to attend and can
>> help if needed with travel and accomodations.
>>
>> Stefan and Matti
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@python.org 
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>> 
>>
>>
>> Hi Matti,
>>
>> I need to know some details:
>>
>>  1. Where is the meeting
>>  2. When is the meeting
>>  3. Where are good places to stay
>>  4. Is there a recommended airport
>>
>> I expect the university has a page somewhere with useful information for
>> visitors, a link would be helpful. I've been to SV several times, but the
>> last time I was in Berkeley was in 1969 :)
>>
>> Chuck
>>
>>
> We will meet at the BIDS inside the Berkeley campus, more info on travel,
> location and accommodation is here
> https://bids.berkeley.edu/about/directions-and-travel
>
>
> Matti
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] NEP process PR

[Jarrod Millman]

Hi all,

I've started working on the proposal discussed in this thread:
  https://mail.python.org/pipermail/numpy-discussion/2017-December/077481.html
here:
  https://github.com/numpy/numpy/pull/10213

You can see how I modified PEP 1 here:
  
https://github.com/numpy/numpy/pull/10213/commits/eaf788940dee7d0f1c7922fac70a87144de89656

I used numbers (i.e., ``nep-.rst``) in the file names, since it
seems more standard and numbers are easier to refer to in discussions.
I don't have a strong preference, so I am happy to change it.  If
using numbers seems reasonable, I will number the existing NEPs.
Moreover, if the preamble seems reasonable, I will go through the
existing NEPs and make sure they all have compliant headers.  For now,
I think auto-generating the index is unnecessary.  Once we are happy
with the purpose and template NEPs as well as automatically publish to
GH pages, we can always go back and write a little script to
autogenerate the index using the preamble information.

Finally, I started preparing to host the NEPs online at:
  http://numpy.github.io/neps
If that seems reasonable, I will need someone to create a neps repo.

We also need to decide whether to move ``numpy/doc/neps`` to the
master branch of the new neps repo or whether to leave it where it is.
I don't have a strong opinion either way.  However, if no one else
minds leaving it where it is, not moving it is slightly less work.
Either way, the work is trivial.  Regardless of where the source
resides, we can host the generated web page in the same location
(i.e., http://numpy.github.io/neps).

It is probably also worth having
  https://docs.scipy.org/doc/numpy/neps/
redirect to
  http://numpy.github.io/neps

Best regards,
Jarrod
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] NEP process update

[Jarrod Millman]

I was planning on looking at/working on the main doc generating system
and the main webpage (for numpy and scipy) soon (over the winter
break), but I didn't want to get too many things in the discussion
right now.  My immediate interest is getting agreement on the first
two items:

- A purpose and process NEP based on PEP 1 and a few other projects.
- A draft NEP template.

I am ambivalent about whether we need a separate repo.  My immediate
plan is start drafting text as a PR to numpy/doc/neps on Thursday
(assuming no major objections arise before then).  That way we can
discuss the NEP purpose/process and template docs, while I look into
the build system.  I was imaging doing something similar to what I did
for for networkx this summer:
  https://networkx.github.io/
The latest docs are autogenerated whenever a PR is merged into master:
  https://networkx.github.io/documentation/latest/

I will look into the scipy system as well and make sure we don't have
an explosion of systems.

Jarrod

On Tue, Dec 5, 2017 at 5:32 PM, Ralf Gommers  wrote:
>
>
> On Wed, Dec 6, 2017 at 1:49 PM, Nathaniel Smith  wrote:
>>
>> On Tue, Dec 5, 2017 at 4:12 PM, Ralf Gommers 
>> wrote:
>> > On Wed, Dec 6, 2017 at 12:31 PM, Jarrod Millman 
>> > wrote:
>> >> Assuming that sounds good, my tentative next steps are:
>> >>
>> >> - I'll draft a purpose and process NEP based on PEP 1 and a few other
>> >> projects.
>> >> - I'll also create a draft NEP template.
>> >
>> >
>> > sounds good
>> >
>> >> - I'll move the NEPs into their own repo (something like numpy/neps),
>> >
>> > This doesn't sound ideal to me - NEPs are important pieces of
>> > documentation,
>> > so I'd rather keep them included in the main docs.
>> >
>> >>   and set up an automated system (RTD or Github pages) to
>> >>   render and publish them with some useful index.
>> >
>> >
>> > If you could copy over the scipy method to rebuild the docs on each
>> > merge
>> > into master, that would achieve the same purpose. Compare
>> > https://docs.scipy.org/doc/numpy-dev/reference/ (outdated) vs
>> > https://docs.scipy.org/doc/scipy-dev/reference/ (redirects to
>> > http://scipy.github.io/devdocs/, always up-to-date).
>>
>> Yeah, we were debating back and forth on this -- I can see arguments
>> either way. The reasons we were leaning towards splitting them out
>> are:
>>
>> - it would be great to make our regular docs auto-generated, but we
>> didn't necessarily want to block this on that
>
>
> This is easy, it's just copying a trick from SciPy. (and that's work that
> anyway needs doing at some point, sooner rather than later)
>
>> - part of the idea is to auto-generate the NEP index out of the
>> metadata inside each NEP file, which is going to involve writing some
>> code and integrating it into the NEP build. This seems easier if we
>> don't have to integrate it into the overall doc build process too,
>> which already has a lot of custom code.
>
>
> This is easy too, if you have your script to auto-generate an index file,
> it's just calling that file from within `doc/Makefile`.
>
>> - NEPs are really part of the development process, not an output for
>> end-users -- they're certainly useful to have available as a
>> reference, but if we're asking end-users to look at them on a regular
>> basis then I think we've messed up and should improve our actual
>> documentation :-)
>> - NEPs have a different natural life-cycle than numpy itself. Right
>> now, if I google "numpy neps", the first hit is the 1.13 version of
>> the NEPs, and the third hit is someone else's copy of the 1.9 version
>> of the NEPs. What you actually want in every case is the latest
>> development version of the NEPs, and the idea of "numpy 1.13 NEPs"
>> doesn't even make sense, because NEPs are not describing a specific
>> numpy release.
>
>
> The last two points are good arguments, I agree that they shouldn't serve as
> documentation. A separate repo has downsides though (discoverability etc.),
> we also keep our dev docs within the numpy repo and you can make exactly the
> same argument about those as about NEPs. So I'd still suggest keeping them
> where they are. Or otherwise move all development related docs.
>
> It's probably less effort even to keep them where they are rather than
> creating a separate repo, setting up RTD for it, and linking to that from
> our main docs.
>
> Ralf
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] NEP process update

[Jarrod Millman]

Hi all,

Since we expect to be writing some NEPs in the near future, Nathaniel
and I were looking at how they're organized, and realized that the
process is a bit underspecified and it's a hard to tell the status of
things.

So I'm thinking of putting together some better tools and
documentation, and wanted to get some quick feedback before I
runoff in the wrong direction.

The goal is not to add a ton of new process, but to better document the current
process.  I would also like to add a little additional structure to make it
easier to understand the process for new contributors and to make the status
of NEPS easier to understand.

After reviewing the existing system, looking at how other projects do
this, and discussing this with Nathaniel, I tentatively plan to work
on the following:

1. Standardize the NEP metadata (e.g., whether they're
   draft/accepted/implemented)
2. Write a NEP to explain the purpose and process (think PEP 1)
3. Create a NEP template (think PEP 12)
4. Add metadata to old NEPs
5. Automate updating the NEP website and autogenerating the index
   based on the NEP metadata.

Nathaniel and I have already started discussing some of these items
and would love to get some feedback soon.

Assuming that sounds good, my tentative next steps are:

- I'll draft a purpose and process NEP based on PEP 1 and a few other projects.
- I'll also create a draft NEP template.
- I'll move the NEPs into their own repo (something like numpy/neps),
  and set up an automated system (RTD or Github pages) to
  render and publish them with some useful index.

Does this seem like a reasonable way to start?

Best regards,
Jarrod
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] NetworkX 2.0b1 released

[Jarrod Millman]

Hi All,

I am happy to announce the **beta** release of NetworkX 2.0! NetworkX
is a Python package for the creation, manipulation, and study of the
structure, dynamics, and functions of complex networks.

This release supports Python 2.7 and 3.4-3.6 and contains many new
features.  This release is the result of over two years of work with
over 600 pull requests by 85 contributors.  We have made **major
changes** to the methods in the Multi/Di/Graph classes and before the
2.0 release we need feedback on those changes.  If you have code that
imports networkx, please take some time to check that you are able to
update your code to work with the new release.

Please see the draft of the 2.0 release announcement:
  http://networkx.readthedocs.io/en/latest/news.html#networkx-2-0
In particular, we would like feedback on the migration guide from 1.X to 2.0:
  
http://networkx.readthedocs.io/en/latest/release/migration_guide_from_1.x_to_2.0.html

Since it is a beta release, pip won't automatically install it.  So
  $ pip install networkx
still installs networkx-1.11 still.  But
  $ pip install --pre networkx
will install networkx-2.0b1.  If you already have networkx installed
then you need to do
  $ pip install --pre --upgrade networkx

For more information, please visit our `website
`_ and our `gallery of examples
`_.
Please send comments and questions to the `networkx-discuss mailing
list `_ or create an
issue `here `_.

Best regards,
Jarrod
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion