[Python-Dev] PEP 318 bake-off?

[Jewett, Jim J]

Brad Clements:
> 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
choice.

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 
to you.

> 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__.

-jJ