Re: [Python-Dev] pep8 reasoning
On Fri, Apr 25, 2014 at 08:42:02PM -0400, Donald Stufft wrote: > > On Apr 25, 2014, at 7:20 PM, Ethan Furman wrote: > > > On 04/25/2014 03:26 PM, Donald Stufft wrote: > >> > >> pep8.py doesn’t violate PEP8, it just takes a stricter view of it. > > > > If pep8 reports errors on things that PEP 8 says are okay, that's a > > violation. > Not really, any code that passes the pep8.py check is perfectly valid in the > eyes of PEP8, > if a check was implemented to say, require camelCase method names, then that > would > be a violation of a check. Being stricter is not a violation, it’s being > stricter. Suppose that some package claiming to check for PEP 8 compliance decided to flag variable names like "foo" and "bar" as errors. Perhaps it was inspired by Tim Peters: Indeed, when I design my killer language, the identifiers "foo" and "bar" will be reserved words, never used, and not even mentioned in the reference manual. Any program using one will simply dump core without comment. Multitudes will rejoice. -- Tim Peters, 29 Apr 1998 Or perhaps it decides that one should never, ever have more than a single dot in a row, a treat that as an error: obj.method() # okay obj.method().attribute # Law Of Demeter violation This hypothetical checker is stricter than PEP 8, in that it allows nothing that PEP 8 forbids. But it also forbids things which are allowed by PEP 8, which is a false negative error: things which should be allowed (according to PEP 8) are forbidden by the checker. (The other kind of error is a false positive, where things which are forbidden by PEP 8 are wrongly allowed by the checker.) I stress that they're only errors if the checker is running in PEP 8 compatibility mode, where it is supposed to check for PEP 8 compliance. That's the crux of Nick's, and Ethan's, argument: with a name like "PEP8", it is reasonable to expect that by default the checker operates in PEP 8 compatibility mode. I agree with them. -- Steven ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pep8 reasoning
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 [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ConfigParser mangles keys with special chars
On Sat, Apr 26, 2014 at 01:59:27AM -0400, Fred Drake wrote:
> On Sat, Apr 26, 2014 at 1:34 AM, Steven D'Aprano wrote:
> > I think that a line beginning with "#spam" is ambiguous, it isn't clear
> > if it is intended as a comment "spam" or a key starting with #, so by
> > the Zen, configparser should refuse to guess.
>
> Seriously?
Perhaps I could have worded my post more clearly, but yes.
In context, we were talking about a situation where the user creates a
key value pair. Copying from the OP's initial post:
>>> cp = configparser.ConfigParser()
>>> cp.read_dict({'DEFAULT': {';foo': 'bar'}})
>>> cp.write(sys.stdout)
[DEFAULT]
;foo = bar
The intent of the creator of the ConfigParser was for a key ";foo" with
value "bar", and that is the way it is treated while still in memory.
It's only when reading it back from a file does it become treated as a
comment. There's no way to tell whether the line ";foo = bar" *in a
file* came from a key ";foo" with value "bar", or from a genuine comment
that merely happens to look like key=value.
The obvious way to avoid the ambiguity is to disallow keys beginning
with a comment prefix. Then ";foo = bar" cannot represent the key
";foo", because such a key is illegal.
> Perhaps the second paragraph here could be strengthened a little:
> https://docs.python.org/3/library/configparser.html#supported-ini-file-structure
>
> But that seems clear to me. Lines starting with the comment prefix
> are comments.
But the entry in question wasn't a line, it was a key=value pair in a
dict. Here's that line again:
cp.read_dict({'DEFAULT': {';foo': 'bar'}})
or it could have been:
cp['DEFAULT'][';foo'] = 'bar'
Either way, if there's no way to escape comment characters, I think it
is a bug that you can insert illegal keys into the cp object in the
first place.
--
Steven
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Apologies for last post
I accidentally posted a question to here. I am returning to Python after a couple years away and I am trying to brush up my skills and make the switch to Python 3.x. ---Andrew ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ConfigParser mangles keys with special chars
On Sat, Apr 26, 2014 at 7:23 AM, Steven D'Aprano wrote:
> But the entry in question wasn't a line, it was a key=value pair in a
> dict. Here's that line again:
>
> cp.read_dict({'DEFAULT': {';foo': 'bar'}})
>
> or it could have been:
>
> cp['DEFAULT'][';foo'] = 'bar'
>
> Either way, if there's no way to escape comment characters, I think it
> is a bug that you can insert illegal keys into the cp object in the
> first place.
Fair enough.
I'm not trying to argue that it isn't a bug, but that risk of breaking
currently-working applications with data they consider acceptable is
high. Many use configparser for input only, and make no use of the
serialization feature. Those applications can be broken by adding a
constraint on the data that's allowed, regardless of what we think of
their keys.
Chaning this in an application for which it's safe (easier to know at
the application level) is easy enough:
import configparser
import re
class ProtectionistParser(configparser.RawConfigParser):
_rx = re.compile(r"[a-z]([-a-z]*[a-z])?$") # or whatever
makes sense for your app
def optionxform(self, opt):
if self._rx.match(opt) is None:
raise ValueError("don't like this: %r" % opt)
return opt
Maybe the "strict" mode is considered new enough that this isn't as
significant a risk, and it could be allowed when that's enabled; I'm
sure Łukasz will have a carefully considered opinion (and I'll defer
to him in the end).
-Fred
--
Fred L. Drake, Jr.
"A storm broke loose in my mind." --Albert Einstein
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ConfigParser mangles keys with special chars
On Apr 25, 2014, at 11:47 AM, Terry Reedy wrote: >So I wonder whether the thought-to-be-buggy behavior is >actually buggy with respect to *all* the supported styles or just some of them. I can't how being able to write a file that isn't read back with the same meaning could be anything but a bug (or missing feature). Regardless of what ( lack of ) standard it is or isn't conforming to. Also, if it is often used just to read ini files, then those uses wouldn't be effected by more strictness on writing ... But the way, last I checked elmentree had a similar problem -- it would quite happily write invalid XML that it wouldn't read back in... -Chris > > -- > Terry Jan Reedy > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/chris.barker%40noaa.gov ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
