<div dir="ltr">Hi,<br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 24, 2018 at 4:10 PM, Nicholas Sauter <span dir="ltr">&lt;<a href="mailto:nksauter@lbl.gov" target="_blank">nksauter@lbl.gov</a>&gt;</span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>It was always the intention to support flex arrays in the absence of Numpy.  If there is some refactoring to be done, this principle should be preserved:  that Numpy is an optional rather than required dependency.</div></div></blockquote><div><br></div><div> Good to know - some of this code seems a little crusty (and I&#39;ve found a couple of bugs just trying to verify that it still works correctly).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Not sure about the wording in your second sentence.  At the time we developed flex, branching was not a code development mechanism we used.  Furthermore, not sure why you say Numpy is &quot;exclusively&quot; used in the flex constructors?  Certainly there are numerous flex constructors that do not involve Numpy?</div></div></blockquote><div><br></div><div>I meant a code branch e.g. &quot;if&quot;, or a preprocessor &quot;#ifdef&quot; in this case.</div><div><br></div><div>I think I&#39;ve gotten confused by some of the indirection in the class definitions - the top level only adds the numpy constructor, and then everything else is put in several levels down - and in some of my tests it looked like the numpy routine was mistakenly doing all of the construction (which ended in much the same results).</div><div><br></div><div>Nick</div><div> </div></div></div></div>