[Numpy-discussion] adopting Python Style Guide for classes
David M. Cooke
cookedm at physics.mcmaster.ca
Tue Oct 2 05:22:16 EDT 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 at physics.mcmaster.ca
More information about the NumPy-Discussion
mailing list