Donald Stufft writes: > For instance there are things on PyPI named after websites, like > github, twitter, Facebook, etc. These things are not written by the > companies behind those websites and are merely written to interface > with those websites. Should we assume that those companies all > endorse every single one of those projects simply because they > chose a descriptive name for their project?
OK, "endorse" is an inappropriate word to describe the problem inherent in naming a script "pep8.py" when the maintainers of PEP 8 say it doesn't implement the PEP. (Aside: In fact, in the cases you cite, you *may* assume implicit approval (or that the company in question has not yet discovered and complained about the usage), if not active endorsement. That is the implication of a "trade name", and I suspect many of the names you mention are registered trademarks as well.) However, be that as it may, your examples are irrelevant to the "spirit" of Nick's issue: PEP 8 is a standard, not a corporate reputation. Even if there is no implicit "endorsement", the maintainer of the program is using the name of the document, while he and others are arguing that it's up to him to decide about conforming to it. That is unfair to those users who do not care about the *content* of the standard, but only about the interoperability implied by a certification of conformance to the standard. And if you think "interoperability" is a strong word to apply to a style guide like PEP 8, maybe so -- but RFC 2119 is also just a style guide, and I would hope that you would not argue that misuse of terms defined in that document has no interoperability consequences. > > I agree 100% with Nick: in a program named "pep8", the examples > > in PEP 8 should *all* pass in the sense of not being labelled > > errors. Of course if the PEP changes that doesn't mean you > > should withdraw or rename the program, or even that you are > > required to address the issue within any time span. But you > > should consider it a bug. > > Or required to address it at all if you don’t wish to. In the case of a explicit decision to WONTFIX just because you don't want to, it becomes a deliberately sustained false-y, and renaming is the appropriate action. There is a huge namespace of strings starting with "py". Although some of the more attractive ones are already taken (pylint, pychecker, pyflakes), I'm sure there's plenty of room for creative naming left if 100% conformance to the standard is a non-goal for the maintainer of the script. > Since the issue is still open I assume that means that the author > hasn’t decided what the correct remediation is yet. In the case of a program intended to check conformance to a standard, it's not a matter for the script maintainer's decision. It's obvious what the specification of the correct remediation is. (The author may of course choose the implementation. Or, having tried implementation he may decide to acknowledge the bug but WONTFIX it as too difficult, but too difficult is obviously not true here.) It's always possible that the document is buggy (as suggested by Janzert the 2- or 3- space indentation may have been a typo), but again, that's for the authors of the standard, not of the script, to decide. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
