On Wednesday, May 28, 2003, at 02:23 PM, Phillip J. Eby wrote:
> Please don't number a pre-PEP; I believe PEP 1 recomends using 'XXX'
> until a PEP number has been assigned by the PEP editors.
>
Ack. Oops. I've sent it off to peps@python.org with the XXX, but
posted
here with the 999.
> A number of things aren't clear from your PEP. For example, how would
> syntax errors in assertions be handled? How is backward compatibility
> with existing docstrings that may use 'inv:' or 'pre:' to specify
> conditions informally?
Um. No thought given to that. My first guess is: syntax errors printed
to standard error, optionally silently ignored, no safety checks
installed
either way. Run-time errors trapped and re-raised as some kind of
ContractViolation::
def read_stuff(input)
"""pre: input.readline"""
would be valid, and the AttributeError would be wrapped inside a
PreconditionViolationError if the ``input`` parameter isn't some
type of input stream.
> Are you proposing that this be part of Python's core syntax? If so,
> then why do it as docstrings? Are you proposing instead that your
> implementation be part of the standard library? If so, then where is
> the documentation for how a developer enables the behavior?
Proposing that some implementation, hopefully mine, be put in the
standard library. I *really* don't think contracts should be part of
the
core syntax: contracts belong in the documentation, and changing all the
doc tools to parse code looking for contract assertions is harder than
building one or two docstring implementations.
self.note(): where *is* the documentation on how to enable the
behavior.
> Also, I didn't find the motivation section convincing. Your answer to
> "Why not have several different implementations, or let programmers
> implement their own assertions?" isn't actually a justification. If
> Alice uses some package to wrap her methods with checks, I can weaken
> the preconditions in a subclass, by simply overriding the methods. If
> I can't do that, then it is a weakness of the DBC package Alice used,
> or of Alice's package, not a weakness of Python.
Consider when Alice's preconditions work, but Bob's do not. Code that
thinks it's calling Alice's code *must not* break when calling Bob's.
Weakening pre-conditions means that Alice's pre-conditions must be
tested as well: and Bob's code is run even if his pre-conditions fail.
The converse is also true: code that understands Bob's pre-conditions
must not fail even if Alice's pre-conditions fail. This is tough to
do with asserts, or with incompatible contract packages.
I haven't made that clear in the PEP or the samples, and it needs to
be clear, because it is the /only/ reason why contracts need to be in
the language/standard runtime.
Excellent points, thanks for taking an interest.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4