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

Brad Clements bkc at murkworks.com
Thu Apr 1 14:28:28 EST 2004

On 1 Apr 2004 at 11:08, 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?

I'm concerned that the funcattrs(a="xyz" .. ) sample tossed around here will be rather ugly for specifying DBC strings.

DBC will also need class invariants, so a funcattrs work-alike at the class level will be needed.

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.

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. For example, a traceback handler might be able to use DBC info to suggest the call level that may have caused the problem.

To do "on demand loading", I suggested giving .pyc files a "resource section" that could hold this meta information. Normal imports would not load the resource section, but resource information could be loaded later using another mechanism.

I thought that putting meta data into a different file was more complicated, and that using -OO to "strip out" annotation was too heavy handed. The standard library might benefit from the addition of method attribute type information. However I think it would be better to not load this information at runtime unless needed.

The same could be said for docstrings. If docstrings were "packed" in a resource section of the .pyc file, they might be loaded "on-demand", thereby saving some memory overhead.

-- Brad Clements, bkc at murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax http://www.wecanstopspam.org/ AOL-IM: BKClements

More information about the Python-Dev mailing list