Re: [SciPy-dev] adopting Python Style Guide for classes
Perry Greenfield <perry <at> stsci.edu>
2007-10-03 15:43:04 GMT
To follow on to my previous posting on this topic given Robert's
response.
As I said previously, I was never strongly committed to one approach
or the other. But since the v1 release has been made, I think more
care needs to be given to consideration of proposals like this before
actually charging off to make the changes.
1) Even though Robert is speaking for Travis, I think given Travis's
role in numpy, it is important for Travis to speak directly to this
when he gets the chance.
2) API changes should only be made in major releases, not minor
releases (IMHO).
3) Greater time should be provided to accommodate the transition. For
example, there should not be deprecation warnings in the first
version that this API appears in. The first release of this should
not lead to nuisance messages for those that have other software that
depends on this. (A tool that allows conditional messages would be
good, but the default should be no message). The next release, sure.
As a result, it means that the old API can't be removed until at
least two releases after that.
4) More information should be provided as to what actually will
change in the public interface. I suspect that it isn't obvious to
many what will change. From the mailing list discussions there
doesn't even seem to be consensus on the factory functions or type
objects (more on these later). Many of the remaining objects are
probably used internally (essentially private) and will affect few
outside of the numpy developers. Since users typically deal mostly
with factory functions, and other functions, they may not deal with
classes much (outside of types). So listing the public classes so
affected will help people understand what changes typical users will
see, and what changes advanced users will see. While this is
annoying, I think someone needs to write up an explicit list of those
public classes that will be changed (and those that won't) so we all
know what we will face. It may be a very small list and thus
alleviate concern about the process. It may show some surprises that
people hadn't thought about. Not doing this before making the changes
seems very unwise.
5) In my humble opinion, we would be nuts--absolutely nuts--to change
either the type classes or the factory functions. This would be
foolish consistency at it's worst. We *just* went through the
exercise of changing Int32 to int32 and so forth and we would have to
change back again? This cannot be seriously considered.
Perry Greenfield
On Oct 2, 2007, at 1:24 PM, Jarrod Millman wrote:
> Hello,
>
> For those of you not on the Numpy developer's list, we have been
> talking about adopting the Python class naming convention to conform
> with Guido's style guide as closely as possible:
> http://www.python.org/dev/peps/pep-0008/
> According to Guido, class names should use the CapWords convention.
> Most Python projects (eg, ETS, matploltlib) adhere to the Python
> naming conventions and it is confusing that NumPy and SciPy don't.
>
> Currently, both NumPy and SciPy use either lower_underscore_separated
> or CapWords for class names.
>
> NumPy
> ======
> $ grep -r '^class [A-Z]' --include "*.py" * | wc -l
> 1014
> $ grep -r '^class' --include "*.py" * | grep -v 'class [A-Z]' | wc -l
> 207
>
> SciPy
> =====
> $ grep -r '^class [A-Z]' --include "*.py" * | wc -l
> 587
> $ grep -r '^class' --include "*.py" * | grep -v 'class [A-Z]' | wc -l
> 565
>
> So far, there is Universal support for the basic idea of conforming to
> the Python Style Guide. Since it should effect the user API, we have
> already updated the TestCase classes. First, we checked in a change
> to allow TestCase classes to be prefixed with
> either 'test' or 'Test':
> http://projects.scipy.org/scipy/numpy/changeset/4144
> Then, we updated both SciPy and NumPy to use CapWords for TestCase
> classes:
> http://projects.scipy.org/scipy/numpy/changeset/4151
> http://projects.scipy.org/scipy/scipy/changeset/3388
> In order to run the SciPy tests on the trunk you will need to install
> NumPy from svn revision 4144 or greater. Before SciPy 0.7.0 is
> released, we will release NumPy 1.0.4.
>
> Also, if you are adding a new class to NumPy or SciPy, please use
> CapWords. Now we need to decide what to do about the remaining
> lower_underscore_separated class names. Obviously, it is important
> that we are careful to not break a lot of code just to bring our class
> names up to standards.
>
> Cheers,
>
> --
> Jarrod Millman
> Computational Infrastructure for Research Labs
> 10 Giannini Hall, UC Berkeley
> phone: 510.643.4014
> http://cirl.berkeley.edu/
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev <at> scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
Mind you, I wasn't one of those that felt that strongly about it, but
do realize that the people that are voting here are not your typical
users. So before this is considered a "universal" opinion, I'd like
to see some of those that made the decision the other way bless it
(and some rationale for the switch that addresses the original
decision).
Eric, Travis, what say you?
Perry
RSS Feed