[SciPy-dev] adopting Python Style Guide for classes

[Ondrej Certik]

> 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.

I strongly agree with all 1) to 4) above. It's really important not to
break things for the end user at the end and 1) through 4) is the way
to do it. (I don't know much background about 5) to make a judgement).

Ondrej Certik