[Python-Dev] PEP 318 bake-off? (original) (raw)

Jewett, Jim J jim.jewett at eds.com
Fri Apr 2 11:44:17 EST 2004

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

More information about the Python-Dev mailing list