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/ |[EMAIL PROTECTED] _______________________________________________ Numpy-discussion mailing list [email protected] http://projects.scipy.org/mailman/listinfo/numpy-discussion
