A few comments regarding what I think justifies some sort of standard to be part of Python (understanding that there are various ways that it could be done, so I'm not commenting on the specifics here directly). I don't there is any harm in making the standard numpy-centric. In fact, I think the selling point is that this standard means that any extension can expose repetitive data to those that want to manipulate it *in Python* in a simple and standard way. While its possible that ultimately there are those that will pass these sorts of things from one extension into another, I don't see that as a common use for a while. What it does mean is that if you want a simple Python-only way of seeing and modifying such data, all you need to do is install numpy. You don't have write a C extension. If the extension writers use the descriptive field names, they can make the array they expose somewhat self-documenting so that turning it into an array and doing a little introspection may tell you all you need to know about the data. Rather than try to sell this as some neutral interface, I would make the numpy-dependence explicit (not that it excludes extension-to- extension direct use). It may be that the developers of various extensions are not the ones most interested in this capability (after all, they've build it to do what they want), but I wouldn't be surprised if many of the users of the extension would like it so they can do things the extension doesn't allow them. So one approach is to see what the respective user communities think about such capabilities. If they find out what this can do for them, they may pressure the developers for such support. People in the numpy community can also volunteer to implement the standard (but with this approach, it's a bit of a chicken and egg thing as someone has mentioned. You can't do it if it isn't in Python yet.) I do agree that the most persuasive approach would be to have at least some of the 3rd party extensions support this explicitly on the python-dev list. Perry