> Mark will you give more details about this proposal? How would the flag > work, what would it modify? > > The idea is inspired in part by the Chrome release cycle, which has a > presentation here: > > https://docs.google.com/present/view?id=dg63dpc6_4d7vkk6ch&pli=1 > > Some quotes: > Features should be engineered so that they can be disabled easily (1 patch) > and > Would large feature development still be possible? > > "Yes, engineers would have to work behind flags, however they can work for as > many releases as they need to and can remove the flag when they are done." > > The current numpy codebase isn't designed for this kind of workflow, but I > think we can productively emulate the idea for a big feature like NA support. > > One way to do this flag would be to have a "numpy.experimental" namespace > which is not imported by default. To enable the NA-mask feature, you could do: > > >>> import numpy.experimental.maskna > > This would trigger an ExperimentalWarning to message that an experimental > feature has been enabled, and would add any NA-specific symbols to the numpy > namespace (NA, NAType, etc). Without this import, any operation which would > create an NA or NA-masked array raises an ExperimentalError instead of > succeeding. After this import, things would behave as they do now.
How would this flag work at the C-API level? -Travis
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
