On 10/2/07, Christopher Barker <[EMAIL PROTECTED]> wrote: > > Jarrod Millman wrote: > > I am hoping that most of you agree with the general principle of > > bringing NumPy and SciPy into compliance with the standard naming > > conventions. > > +1 > > > 3. When we release NumPy 1.1, we will convert all (or almost all) > > class names to CapWords. > > What's the backwards-compatible plan? > > - keep the old names as aliases? > - raise deprecation warnings? > > What about factory functions that kind of look like they might be > classes -- numpy.array() comes to mind. Though maybe using CamelCase for > the real classes will help folks understand the difference.
I'm not a big fan of this kind of distinction distinction between factory functions and "real" classes based on the concrete types of the objects.. In some cases whether an object is a class or a factory function is simply an implementation detail. The real distinction, as I see it, is whether the object in question is meant to be subclassed. Thus an object is conceptually a class if it can be called to create an instance and it can be usefully subclassed. A factory function, on the other hand is only meant to be called to get an instance, regardless whether it is implemented as a class or a function. Of course, in the case of ndarray/array the distinction is clear since array cannot be subclassed, so the minor rant above doesn't apply. What is a "class" in this case -- with new-style classes, there is no > distinction between types and classes, so I guess they are all classes, > which means lots of things like: > > numpy.float32 > > etc. etc. etc. are classes. should they be CamelCase too? Core Python makes an additional distinction between types built into the core (float, int, etc...) which are all lower case and library classes, which generally use CapWords. So I guess there are two questions, IMO: 1. Can float32 and friends be usefull subclassed? I suspect the answer is no. And in my head at least, these are conceptually mostly marker objects that can also be used as coercion functions, not classes. FWIW. 2. Are these enough like builtin types to leave them alone in any case? One approach would be CapWords the superclasses of these that are subclassable, but leave the leaf types alone. For example, looking at float32 and its bases : - numpy.generic -> numpy.Generic - numpy.number -> numpy.Number - numpy.inexact -> numpy.Inexact - numpy.floating -> numpy.Floating - numpy.float32 stays the same This is probably a lot less painful in terms of backwards compatibility. My $0.02. NOTE: > for i in dir(numpy): > if type(getattr(numpy, i)) == type(numpy.ndarray): print i > > Yields 86 type objects. > > -Chris > > > > -- > Christopher Barker, Ph.D. > Oceanographer > > Emergency Response Division > NOAA/NOS/OR&R (206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > [EMAIL PROTECTED] > _______________________________________________ > Numpy-discussion mailing list > Numpy-discussion@scipy.org > http://projects.scipy.org/mailman/listinfo/numpy-discussion > -- . __ . |-\ . . [EMAIL PROTECTED]
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion