[Numpy-discussion] adopting Python Style Guide for classes

David M. Cooke cookedm@physics.mcmaster...
Tue Oct 2 04:22:16 CDT 2007


On Tue, Oct 02, 2007 at 09:12:43AM +0200, Pearu Peterson wrote:
> 
> 
> Jarrod Millman wrote:
> > Hello,
> > 
> ..
> > Please let me know if you have any major objections to adopting the
> > Python class naming convention.
> 
> I don't object.

Me either.

> > 2.  Any one adding a new class to NumPy would use CapWords.
> > 3.  When we release NumPy 1.1, we will convert all (or almost all)
> > class names to CapWords.  There is no reason to worry about the exact
> > details of this conversion at this time.  I just would like to get a
> > sense whether, in general, this seems like a good direction to move
> > in.  If so, then after we get steps 1 and 2 completed we can start
> > discussing how to handle step 3.
> 
> After fixing the class names in tests then how many classes use
> camelcase style in numpy/distutils? How many of them are implementation
> specific and how many of them are exposed to users? I think having this
> statistics would be essential to make any decisions. Eg would we
> need to introduce warnings for the few following releases of numpy/scipy
> when camelcase class is used by user code, or not?

In numpy/distutils, there's the classes in command/* modules (but note
that distutils uses the same lower_case convention, so I'd say keep
them), cpu_info (none of which are user accessible; I'm working in there
now), and system_info (which are documented as user accessible). Poking
through the rest, it looks like only the system_info classes are ones
that we would expect users to subclass. We could document the lower_case
names as deprecated, and alias them to CamlCase versions.

-- 
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke                      http://arbutus.physics.mcmaster.ca/dmc/
|cookedm@physics.mcmaster.ca


More information about the Numpy-discussion mailing list