Re: [Numpy-discussion] Python needs goto
Very funny ! đ Le 25 sept. 2015 07:53, "Alexander EberspĂ€cher" a Ă©crit : > On 24.09.2015 21:12, Charles R Harris wrote: > > > I find Cleve Moler's old Fortran version of Brent's zero finding > > algorithm using gotos clearer than the structured versions you can find > > in Numerical Recipes. The operation of the algorithm is easiest to > > describe as a finite state machine. > > I need to look into that piece of Fortran code. I've never (knowingly) > implemented a state-machine myself. However I can say that specifically > Fortran has named loops, which probably helps to avoid many uses of goto. > > > However, the post was for laughs, I didn't expect serious discussion. > > Well, then let me fill in the missing piece - the obligatory XKCD strip: > > https://www.xkcd.com/292/ > > Alex > > > > > > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion > > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] composition of the steering council (was Re: Governance model request)
On Thu, Sep 24, 2015 at 10:45 AM, David Cournapeau wrote: > > On Thu, Sep 24, 2015 at 10:45 AM, Sebastian Berg > wrote: >> [...] >> About using the commit log to seed, I think there are some old term >> contributers (David Cournapeau maybe?), who never stopped doing quite a >> bit but may not have merge commits. However, I think we can start of >> with what we had, then I would hope Chuck and maybe Ralf can fill in the >> blanks. > > > AFAIK, I still have merge commits. I am actually doing a bit of numpy > development ATM, so I would prefer keeping them, but I won't fight it > either. For the record -- Sebastian's "not have merge commits" here I think means that looking at git history shows that you haven't reviewed/merged any other people's pull requests in the time period we've been looking at for the steering council discussion. AFAIK you do still have write permission to the repository on github, and there hasn't been any proposal to change those permissions around. (I'd certainly be in favor of *not* restricting commit permission to just the "steering council". But we can talk about that later once we've figured out what the steering council actually is :-).) -n -- Nathaniel J. Smith -- http://vorpus.org ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] composition of the steering council (was Re: Governance model request)
[Travis: sorry for writing all this referring to you in third person -- I guess it might feel a bit awkward to read! You're certainly part of the intended audience, but then it felt even more awkward trying to write in second person... this is clearly a bug in English.] Hi all, On Wed, Sep 23, 2015 at 2:21 PM, Travis Oliphant wrote: > As the original author of NumPy, I would like to be on the seed council as > long as it is larger than 7 people.That is my proposal.I don't need > to be a permanent member, but I do believe I have enough history that I can > understand issues even if I haven't been working on code directly. > > I think I do bring history and information that provides all of the history > that could be helpful on occasion. In addition, if a matter is important > enough to even be brought to the attention of this council, I would like to > be involved in the discussion about it. Regarding the question of Travis being on the council: My overall feeling on this pretty neutral: I think it won't make much of a difference to NumPy really either way, because the important thing will be Travis's insights, available time to contribute, etc., and these will (I assume) be pretty much the same regardless of whether he's on the council or not. (Any matter so intractable that it actually needs the council's emergency powers will presumably be heralded by an epic multi-month message thread of doom, plus Travis has plenty of friends on the council who know where to find him when historical insight is needed, so I'm not worried about anyone missing out on a chance to be involved.) I'm sure we can make it work either way. But, I want to play devil's advocate for a bit, because there are some connected issues that IMHO we should at least think through if we're going to do this, and I think the easiest way to do that is to try and articulate the case against. So, here's the case against Travis being on the steering council immediately + an alternative option for comparison: - begin devil's advocate - First, just as a procedural matter, it seems clear that putting Travis on the council now will require changing the document in ways that violate Sebastian/Chris's concept of a "no names" rule -- at least in spirit if not in letter. The problem isn't just the initial council seeding; it's that Travis formally stepped down from the project more than 2.5 years ago, was mostly inactive for some time before that, and IIRC has been almost completely unheard-from between then and a few weeks ago. (Of course please correct me if I'm forgetting something, and obviously I'm talking with respect to numpy only -- clearly Travis has been doing tons of great things, but while numpy certainly benefits from e.g. the existence of NumFOCUS, creating NumFOCUS doesn't really feel like what we mean by "project activity" :-).) This means that as currently written, it's pretty unambiguous: he doesn't qualify to be added by the normal nomination process (requires "sustained" activity over the last year), and if he were added anyway (e.g. as part of the seed council) then according to the rules he would then be immediately removed for inactivity (requires being active within the last 1 year, or else within the 2 years plus affirmation that they planned to "return to active participation soon" -- this post hoc analysis requires a bit of squinting to apply at all, but it's pretty hard to reconcile with >2 years inactivity + his "moving on from numpy to blaze" post). To avoid referencing him by name we could add some text about "founding developers" or something as a fig leaf, but judging from Robert's last email it sounds like Travis is the only person in question, so this really would just be a fig leaf. Of course we have the option of modifying the rules to make this work -- I'm not really sure how to do this, but it's our text and I'm sure we can make it do whatever we want somehow. But any kinds of special case modifications for a single person create two problems: 1) Given that whether or not Travis is listed on the steering council probably won't affect the project much or at all, it could easily appear to an outside observer that the purpose of these rules changes was not to benefit NumPy, but only to benefit Travis's ego. Not that there's anything wrong with massaging Travis's ego :-). BUT, it sends a clear message (whether we mean it that way or not): that we think being on the steering council should affect one's ego. And there *is* something very wrong with this *message*. It's crucial that serving on the steering council be understood to be a job, not a privilege -- sort of like being release manager. It's an important and valued job, we're glad people volunteer, but it's an absolutely fundamental rule that council members do *not* get any special treatment outside of specific limited circumstances. If being on the steering council becomes a trophy or judgement of worth, and being left off it become
Re: [Numpy-discussion] composition of the steering council (was Re: Governance model request)
To respond to the devils advocate: Creating this organizational framework is a one time boot-strapping event. You could use wording like "The initial council will include those who have made significant contributions to numpy in the past and want to be on it" or "The initial council will be constructed by invitation by Nathaniel and Chuck". More objective criteria should be used going forward, but in terms of getting things spun up quickly doing things by fiat is probably ok. I am not even sure that the method by which the initial group is formed needs to go into the governing document. I think this addresses most of the concerns, IBM is happy (enough) because this was done as part of a one-time boot strapping operation of standing the rules up and there are no explicit names in the governing documents. It also acknowledges that there is a discontinuity/singularity in the governance of the project which means you get to do singular thing :). Tom On Fri, Sep 25, 2015 at 8:40 AM Nathaniel Smith wrote: > [Travis: sorry for writing all this referring to you in third person > -- I guess it might feel a bit awkward to read! You're certainly part > of the intended audience, but then it felt even more awkward trying to > write in second person... this is clearly a bug in English.] > > Hi all, > > On Wed, Sep 23, 2015 at 2:21 PM, Travis Oliphant > wrote: > > As the original author of NumPy, I would like to be on the seed council > as > > long as it is larger than 7 people.That is my proposal.I don't > need > > to be a permanent member, but I do believe I have enough history that I > can > > understand issues even if I haven't been working on code directly. > > > > I think I do bring history and information that provides all of the > history > > that could be helpful on occasion. In addition, if a matter is > important > > enough to even be brought to the attention of this council, I would like > to > > be involved in the discussion about it. > > Regarding the question of Travis being on the council: > > My overall feeling on this pretty neutral: I think it won't make much > of a difference to NumPy really either way, because the important > thing will be Travis's insights, available time to contribute, etc., > and these will (I assume) be pretty much the same regardless of > whether he's on the council or not. (Any matter so intractable that it > actually needs the council's emergency powers will presumably be > heralded by an epic multi-month message thread of doom, plus Travis > has plenty of friends on the council who know where to find him when > historical insight is needed, so I'm not worried about anyone missing > out on a chance to be involved.) I'm sure we can make it work either > way. > > But, I want to play devil's advocate for a bit, because there are some > connected issues that IMHO we should at least think through if we're > going to do this, and I think the easiest way to do that is to try and > articulate the case against. So, here's the case against Travis being > on the steering council immediately + an alternative option for > comparison: > > - begin devil's advocate - > > First, just as a procedural matter, it seems clear that putting Travis > on the council now will require changing the document in ways that > violate Sebastian/Chris's concept of a "no names" rule -- at least in > spirit if not in letter. The problem isn't just the initial council > seeding; it's that Travis formally stepped down from the project more > than 2.5 years ago, was mostly inactive for some time before that, and > IIRC has been almost completely unheard-from between then and a few > weeks ago. (Of course please correct me if I'm forgetting something, > and obviously I'm talking with respect to numpy only -- clearly Travis > has been doing tons of great things, but while numpy certainly > benefits from e.g. the existence of NumFOCUS, creating NumFOCUS > doesn't really feel like what we mean by "project activity" :-).) > > This means that as currently written, it's pretty unambiguous: he > doesn't qualify to be added by the normal nomination process (requires > "sustained" activity over the last year), and if he were added anyway > (e.g. as part of the seed council) then according to the rules he > would then be immediately removed for inactivity (requires being > active within the last 1 year, or else within the 2 years plus > affirmation that they planned to "return to active participation soon" > -- this post hoc analysis requires a bit of squinting to apply at all, > but it's pretty hard to reconcile with >2 years inactivity + his > "moving on from numpy to blaze" post). To avoid referencing him by > name we could add some text about "founding developers" or something > as a fig leaf, but judging from Robert's last email it sounds like > Travis is the only person in question, so this really would just be a > fig leaf. > > Of course we have the option of modifying the rules to make
Re: [Numpy-discussion] composition of the steering council (was Re: Governance model request)
Hi Nathaniel, Piping in again from the outside: being on council would certainly seem to be a job not a privilege, and I suspect it will be hard enough to find people willing to actually put in work to worry about restricting membership overly. Given this, my suggestion would be to have a general, no-name escape clause to the rules, stating that anybody who does not formally meet the rules is welcome to *volunteer* being on the council, with a suggestion on what s/he might contribute, and the existing council can then decide whether or not that contribution is welcome. My sense would be that any time this happens one will be most happy to accept. All the best, Marten â p.s. Independently of rules, I don't see how Travis would not qualify even from current work, given that he has just committed to actively try to improve/generalize dtype. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] composition of the steering council (was Re: Governance model request)
On Mi, 2015-09-23 at 19:48 -0500, Travis Oliphant wrote: > > > On Wed, Sep 23, 2015 at 6:19 PM, Charles R Harris > wrote: > > > On Wed, Sep 23, 2015 at 3:42 PM, Chris Barker > wrote: > On Wed, Sep 23, 2015 at 2:21 PM, Travis Oliphant > wrote: > > As the original author of NumPy, I would like > to be on the seed council as long as it is > larger than 7 people.That is my proposal. > > > Or the seed council could invite Travis to join as its > first order of business :-) > > > Actually, maybe that's a way to handle it -- declare > that the first order of business for teh seed council > is to expand the council. > > > Perhaps we should specify a yearly meeting to review the past > year and nominate people for commit rights and council > membership. Long term, we might also want to start removing > commit rights, perhaps by adding a team category on github > with restricted rights -- committer emeritus, so to speak. > > > > That's a pretty good idea, actually. > > +1, lets make sure that dynamics of getting new people in and inactive out won't stall too easily. > > > > > > I'd still like some guidelines (suggestions) for > history and at least one major dependent-on-numpy rep. > Travis would certainly meet the history requirement -- > and maybe the other, too. :-) > > It's a simple change to the text --- basically > an explanation that Travis requested to be on > the seed council. > > > I'd rather the final draft of the document didn't name > names, but no biggie. > > > I'm fine with that too --- except you will need to name the initial > seed council. > > > -Travis > > > > > > > > Chuck > > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion > > > > > > -- > > Travis Oliphant > Co-founder and CEO > > > > > > @teoliphant > 512-222-5440 > http://www.continuum.io > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion signature.asc Description: This is a digitally signed message part ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Python needs goto
> On Sep 25, 2015, at 1:53 AM, Alexander EberspÀcher > wrote: > > On 24.09.2015 21:12, Charles R Harris wrote: > >> I find Cleve Moler's old Fortran version of Brent's zero finding >> algorithm using gotos clearer than the structured versions you can find >> in Numerical Recipes. The operation of the algorithm is easiest to >> describe as a finite state machine. > > I need to look into that piece of Fortran code. I've never (knowingly) > implemented a state-machine myself. However I can say that specifically > Fortran has named loops, which probably helps to avoid many uses of goto. > GOTOs really can be useful. COMPUTED GOTOs, on the other hand, are a debugging nightmare, literally!!! Bill >> However, the post was for laughs, I didn't expect serious discussion. > > Well, then let me fill in the missing piece - the obligatory XKCD strip: > > https://www.xkcd.com/292/ > > Alex > > > > > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Python needs goto
goto! and comefrom! Together with exceptions, threads, lambda, super, generators, and coroutines, all we're lacking is call-with-current-continuation for the full list of impenetrable control-flow constructs. Oh, and lisp-style resumable exception handling. (Suggested syntax: drop(exception, value) to return control to where the exception was raised and make the raise statement return value.) On Thu, Sep 24, 2015 at 8:42 PM Charles R Harris wrote: > On Thu, Sep 24, 2015 at 12:13 PM, Yarko Tymciurak > wrote: > >> >> >> I think there are more valid uses - I've read that "goto" basically is >> what a state machine does. >> Have a read of the brief implementation notes for "goto" in golang, for >> example. Goto may not be unreasonable to use, just most people would >> abuse. Sort of like "everyone shouldn't write assembly, but if you >> understand the machine, you can make good things happen". Without >> compiler/interpreter checks, more responsibility rests on the coder to keep >> out of trouble. >> > > I would agree about state machines. When implemented using the standard > control flow constructs they always look a bit artificial. > > That depends what your "standard" control flow constructs are. Has anyone tried implementing a state machine using coroutines? They seem like a rather natural setup: each state is a coroutine that loops, doing the appropriate actions for the state and then handing control over to the coroutine for the next state. Anne ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Python needs goto
Ow! Ow! Ow! I am just a meteorologist that has an obsession with looking up unfamiliar technology terms. I need a Tylenol... Ben Root On Fri, Sep 25, 2015 at 12:27 PM, Anne Archibald wrote: > goto! and comefrom! Together with exceptions, threads, lambda, super, > generators, and coroutines, all we're lacking is > call-with-current-continuation for the full list of impenetrable > control-flow constructs. Oh, and lisp-style resumable exception handling. > (Suggested syntax: drop(exception, value) to return control to where the > exception was raised and make the raise statement return value.) > > On Thu, Sep 24, 2015 at 8:42 PM Charles R Harris < > charlesr.har...@gmail.com> wrote: > >> On Thu, Sep 24, 2015 at 12:13 PM, Yarko Tymciurak >> wrote: >> >>> >>> >>> I think there are more valid uses - I've read that "goto" basically is >>> what a state machine does. >>> Have a read of the brief implementation notes for "goto" in golang, for >>> example. Goto may not be unreasonable to use, just most people would >>> abuse. Sort of like "everyone shouldn't write assembly, but if you >>> understand the machine, you can make good things happen". Without >>> compiler/interpreter checks, more responsibility rests on the coder to keep >>> out of trouble. >>> >> >> I would agree about state machines. When implemented using the standard >> control flow constructs they always look a bit artificial. >> >> > That depends what your "standard" control flow constructs are. Has anyone > tried implementing a state machine using coroutines? They seem like a > rather natural setup: each state is a coroutine that loops, doing the > appropriate actions for the state and then handing control over to the > coroutine for the next state. > > Anne > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion > > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Python needs goto
On Fri, Sep 25, 2015 at 10:27 AM, Anne Archibald wrote: > goto! and comefrom! Together with exceptions, threads, lambda, super, > generators, and coroutines, all we're lacking is > call-with-current-continuation for the full list of impenetrable > control-flow constructs. Oh, and lisp-style resumable exception handling. > (Suggested syntax: drop(exception, value) to return control to where the > exception was raised and make the raise statement return value.) > > On Thu, Sep 24, 2015 at 8:42 PM Charles R Harris < > charlesr.har...@gmail.com> wrote: > >> On Thu, Sep 24, 2015 at 12:13 PM, Yarko Tymciurak >> wrote: >> >>> >>> >>> I think there are more valid uses - I've read that "goto" basically is >>> what a state machine does. >>> Have a read of the brief implementation notes for "goto" in golang, for >>> example. Goto may not be unreasonable to use, just most people would >>> abuse. Sort of like "everyone shouldn't write assembly, but if you >>> understand the machine, you can make good things happen". Without >>> compiler/interpreter checks, more responsibility rests on the coder to keep >>> out of trouble. >>> >> >> I would agree about state machines. When implemented using the standard >> control flow constructs they always look a bit artificial. >> >> > That depends what your "standard" control flow constructs are. Has anyone > tried implementing a state machine using coroutines? They seem like a > rather natural setup: each state is a coroutine that loops, doing the > appropriate actions for the state and then handing control over to the > coroutine for the next state. > > Might well do. TAOCP has an example elevator, passenger simulation that, IIRC, used coroutines. I think I may have even once used a language that had them (Algol 68?). It will be interesting to see what their inclusion in Python 3.5 leads to. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Including .f2py_f2cmap in numpy.distutils?
Hello, I am attempting to set up a numpy.distutils setup.py for a small python program that uses a Fortran module. Currently, the setup is able to compile and install the program seemingly successfully, but the f2py script erroneously maps the data types I am using to float, rather than double. I have the proper mapping set up in a .f2py_f2cmap in the source directory, but it does not seem to be copied to the build directory at compile time, and I cannot figure out how to make it get copied. Is there a simple way to do what I am trying to do? Alternatively, is there a way to specify the mapping in my setup.py scripts? Here's a github repo with the project: https://github.com/ehermes/ased3 Thanks, Eric Hermes ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] "Numpy for Matlab Users" is missing
Does anybody know what happened to the following links on the NumPy homepage (http://www.numpy.org/): - http://wiki.scipy.org/Wiki/NumPy_for_Matlab_Users - http://www.numpy.org/ - http://wiki.scipy.org/Numpy_Functions_by_Category They have not been available for some time now ... ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Python needs goto
On Sep 25, 2015 11:06 AM, "Charles R Harris" wrote: > > > > On Fri, Sep 25, 2015 at 10:27 AM, Anne Archibald wrote: >> >> goto! and comefrom! Together with exceptions, threads, lambda, super, generators, and coroutines, all we're lacking is call-with-current-continuation for the full list of impenetrable control-flow constructs. Oh, and lisp-style resumable exception handling. (Suggested syntax: drop(exception, value) to return control to where the exception was raised and make the raise statement return value.) >> >> On Thu, Sep 24, 2015 at 8:42 PM Charles R Harris < charlesr.har...@gmail.com> wrote: >>> >>> On Thu, Sep 24, 2015 at 12:13 PM, Yarko Tymciurak wrote: I think there are more valid uses - I've read that "goto" basically is what a state machine does. Have a read of the brief implementation notes for "goto" in golang, for example. Goto may not be unreasonable to use, just most people would abuse. Sort of like "everyone shouldn't write assembly, but if you understand the machine, you can make good things happen". Without compiler/interpreter checks, more responsibility rests on the coder to keep out of trouble. >>> >>> >>> I would agree about state machines. When implemented using the standard control flow constructs they always look a bit artificial. >>> >> >> That depends what your "standard" control flow constructs are. Has anyone tried implementing a state machine using coroutines? They seem like a rather natural setup: each state is a coroutine that loops, doing the appropriate actions for the state and then handing control over to the coroutine for the next state. >> > > Might well do. TAOCP has an example elevator, passenger simulation that, IIRC, used coroutines. I think I may have even once used a language that had them (Algol 68?). It will be interesting to see what their inclusion in Python 3.5 leads to. The coroutines in 3.5 are just syntactic sugar around features that were added in *2*.5 (yield expressions and yield from), so no need to wait :-). They fall far short of arbitrary continuations, though. I don't think it's particularly cumbersome to implement a state machine with one function per state and the return value specifying the new state -- there's a little more typing to set up the local variables and such each time, but if you have complex states then this seems like even an advantage over goto (since with goto you may have to set up local state by hand each time, basically reimplementing your own scoping mechanism). Of course if all your states are trivial then this overhead is just annoying. ...I suspect you actually might be able to implement resumable exceptions in cpython as a (very evil) third party module. I'm going to stop thinking about that now before I get too curious and do something I regret. Actually, don't stackless / greenlet give you full continuations? -n ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] "Numpy for Matlab Users" is missing
The wiki is down, presumably as part of this: https://github.com/numpy/numpy/issues/6325 On Sep 25, 2015 1:22 PM, "Thomas Haslwanter" wrote: > Does anybody know what happened to the following links on the NumPy > homepage (http://www.numpy.org/): > > >- http://wiki.scipy.org/Wiki/NumPy_for_Matlab_Users >- http://www.numpy.org/ >- http://wiki.scipy.org/Numpy_Functions_by_Category > > They have not been available for some time now ... > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion > > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Python needs goto
On Fri, Sep 25, 2015 at 3:02 PM, Nathaniel Smith wrote: > > The coroutines in 3.5 are just syntactic sugar around features that were > added in *2*.5 (yield expressions and yield from), so no need to wait :-). > They fall far short of arbitrary continuations, though. > Correction: Python 3.4 gained "yield from". Prior to that, you had a lot of work to properly delegate from one generator to another. But yes, async and await are just syntactic sugar (consistent with other languages) for python 3.4's coroutine functionality. Ryan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Python needs goto
On Fri, Sep 25, 2015 at 2:39 PM, Ryan May wrote: > > On Fri, Sep 25, 2015 at 3:02 PM, Nathaniel Smith wrote: >> >> The coroutines in 3.5 are just syntactic sugar around features that were >> added in *2*.5 (yield expressions and yield from), so no need to wait :-). >> They fall far short of arbitrary continuations, though. > > > Correction: Python 3.4 gained "yield from". Prior to that, you had a lot of > work to properly delegate from one generator to another. Ah, right, thanks for the correction. Not sure how much yield from matters for state machines, but certainly it's great for async IO. -n -- Nathaniel J. Smith -- http://vorpus.org ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] composition of the steering council (was Re: Governance model request)
On Fri, Sep 25, 2015 at 7:25 AM, Marten van Kerkwijk wrote: [...] > > p.s. Independently of rules, I don't see how Travis would not qualify even > from current work, given that he has just committed to actively try to > improve/generalize dtype. Just to clarify what's happening here (at least as I understand it -- hopefully Travis / Continuum folks will be in communication with the community at some point), it sounds like the plan is not so much that Travis will be working on the dtype stuff (he has no time) as that he's hiring other people to work on it: "Travis (Continuum) is working with 3 part-time people (currently Kerry Oliphant, Christian Tismer and Yarko Tymciurak) with additional advisement from Irwin Zaid, Jeff Reback, and Antoine Pitrou. The target of this effort is two Python packages (currently called memtype and gufunc) which could serve as prototypes and/or scaffolding and/or implementations of the same ideas that get into NumPy.They will be working and communicating with the NumPy community. Travis's brother, Kerry Oliphant, is leading the group and tasked with communicating with the broader community about the activities of this team." -- https://bids.hackpad.com/Python-Stack-Refactoring-uU9RVWkMc0J So this seems orthogonal to the steering council discussion -- decisions about steering council membership are 100% about actual work done by actual individuals, without any regard to who is writing checks to whom. (This is a key part of the whole maintaining-independence, keeping-corporate-influence-at-arms-length aspect of the governance plan.) (It also sounds like Continuum's current plan is that instead of improving numpy directly, they will be off building a toy array library to explore the idea of implementing this stuff directly in the core interpreter as builtin types. And in parallel, those of us who are interested in this stuff in numpy will be getting to work on actually implementing new dtype stuff in numpy. And I guess at some point we'll compare notes and see how close our two implementations ended up being in retrospect? Right now I don't understand any path for their work to be useful to numpy, and it sounds like for now the numpy team should just proceed with our existing refactoring plans on the assumption that nothing will come of the Continuum work, and if that's wrong then it will be a pleasant surprise. But Travis is aware of my thoughts here and keen to do it this way anyway, and it's their money and time, so, up to them really...) -n -- Nathaniel J. Smith -- http://vorpus.org ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
