[Python-Dev] PEP 318 bake-off?
Jewett, Jim J
jim.jewett at eds.com
Fri Apr 2 11:44:17 EST 2004
> Guido van Rossum wrote:
>> I think that SPARK syntax and everything else that people have
>> traditionally added to docstring markup that isn't strictly speaking
>> documentation (even some extreme cases of doctest usage) ought to be
>> considered as candidates for attribute-ification.
> Where do method attribute type signatures and DBC fit in?
> As a decorator, or in the docstring?
While it will still be *possible* to abuse the docstring, it
*should* go as a decorator. Not every machine-readable class
invariant is useful documentation to someone who isn't already
debugging that code in particular.
> I'm concerned that the funcattrs(a="xyz" .. ) sample tossed
> around here will be rather ugly for specifying DBC strings.
I agree that it would be better to create a DBC class.
If there is a DBC attribute on a code object, then DBC-aware
tools will look to that object for the DBC conditions. Whether
you express them as strings or predicate functions or ... your
As a specific case, a debugger could use object.__DBC__.__call__
instead of object.__call__. (If you wanted to enforce the
DBC checks at all times, then your decorator could just return
a new object that checks and delegates, rather than an annotated
version of the original.)
> Finally, I don't have a need to access DBC annotations at
> runtime once my module is distributed. I would not want to
> pay the memory cost overhead of loading DBC information or
> attribute type signatures at runtime.
Then define a release-DBC class whose constructor is pass, and
whose decoration is to return the object unchanged (without a
DBC attribute). Use that in your released code. Whether to
strip DBC info entirely or just throw it away on loading is up
> However another person at PyCon poo-poo'd my concern over
> bloating .pyc files and subsequent memory use. As a compromise
> I suggested that "annotation" information could go into the
> .pyc, but be loaded "on demand" at runtime.
Changing the format of .pyc is beyond the scope of PEP318.
If you want a special case for DBC, you can write it. Make
your DBC class save the annotations for example.py to
example.dbc, and retrieve them on demand. You may have to
go through a rewrite/reload step to get them out of the
.pyc without removing them from the .py, but you can do it.
If on-demand is not required, you could probably change the
compiler to ignore any attribute registered as ignorable
during optimization, instead of just __doc__.
More information about the Python-Dev