[Python-Dev] PEP 318 bake-off?

[Brad Clements]

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