[Numpy-discussion] adopting Python Style Guide for classes

[Timothy Hochberg]

On 10/2/07, Christopher Barker <Chris.Barker at noaa.gov> 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
>
> Chris.Barker at noaa.gov
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>



-- 
.  __
.   |-\
.
.  tim.hochberg at ieee.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20071002/0d6ab426/attachment.html>