Change Details

Before officially releasing 2.0 all code (especially the library) should be PEP-8 compliant and non-compliant code should be marked deprecated. But I also think that this shouldn't be rushed as this gives us a chance to change the method headers for example and improve them without the need to deprecate parts of the new PEP-8 method header.

Before officially releasing 2.0 all code (especially the library) should be PEP-8 compliant and non-compliant code should be marked deprecated. But I also think that this shouldn't be rushed as this gives us a chance to change the method headers for example and improve them without the need to deprecate parts of the new PEP-8 method header. So my suggestion would be the following (prior to release pywikibot 2.0): * If the method is changed but can be easily done, it shouldn't be changed to a PEP-8 compliant name * If it is very complex (e.g. parameters are removed or repurposed) it should be changed to a PEP-8 compliant name * More or less immediately before the release we change all names to PEP-8 compliant names and deprecate the old names (this doesn't apply to already changed methods obviously). This shouldn't be done minutes prior to the release obviously but with one of the last steps. It shouldn't be rushed but thought out so that the names are flexible enough that they don't need to be deprecated. Non PEP-8 compliant names are a very easy way to get away with failures in the API, because the PEP-8 compliant names can be easily added without concern about backwards compatibility, because the old name can translate to the new name. This also means that we should be careful with premature renaming. For example `APISite.hasExtension` was already changed to `APISite.has_extension` but there has been suggestions to make `has_extension` more like `hasExtension` and so any advantage would be lost and our final `has_extension` needs to be compatible with the current `has_extension`.

Before officially releasing 2.0 all code (especially the library) should be PEP-8 compliant and non-compliant code should be marked deprecated. But I also think that this shouldn't be rushed as this gives us a chance to change the method headers for example and improve them without the need to deprecate parts of the new PEP-8 method header. So my suggestion would be the following (prior to release pywikibot 2.0): * If the method is changed but can be easily done, it shouldn't be changed to a PEP-8 compliant name * If it is very complex (e.g. parameters are removed or repurposed) it should be changed to a PEP-8 compliant name * More or less immediately before the release we change all names to PEP-8 compliant names and deprecate the old names (this doesn't apply to already changed methods obviously). This shouldn't be done minutes prior to the release obviously but with one of the last steps. It shouldn't be rushed but thought out so that the names are flexible enough that they don't need to be deprecated. Non PEP-8 compliant names are a very easy way to get away with failures in the API, because the PEP-8 compliant names can be easily added without concern about backwards compatibility, because the old name can translate to the new name. This also means that we should be careful with premature renaming. For example `APISite.hasExtension` was already changed to `APISite.has_extension` but there has been suggestions to make `has_extension` more like `hasExtension` and so any advantage would be lost and our final `has_extension` needs to be compatible with the current `has_extension`.