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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4