[Python-3000] Adaptation and type declarations

[Ron Adam]

Guido van Rossum wrote:
> On 4/11/06, Jim Jewett <jimjjewett at gmail.com> wrote:
>> You had said there was some question of what kind of objects the type
>> markers should be.  I couldn't (and still can't) see any good reason
>> for them to be anything but a way to ensure [to some level] that the
>> argument is [in some way] appropriate.
> 
> You just can't avoid using a double negative can't you? :-)
> 
> I'd like to stretch the definition further, so that *any* argument
> metadata can be placed in that syntactic position, as long as a
> decorator is used that can interpret the metadata, and as long as the
> metadata can be expressed as a single expression. (If the expression
> gets too long we can always lift it out and move it to a preceding
> position in the file, as the expression is evaluated at the same time
> the function definition and the default values are -- I probably
> forgot to make that explicit.)
> 
> Just like decorators have no defined semantics (beyond "the decorator
> gets called this way and what it returns gets assigned to that
> variable") but have found a few well-defined conventions for their
> most common usage (call wrappers and registration), I expect that
> we'll develop a convention for how to express various useful metadata
> soon enough -- but I don't want the language to enforce that. The
> syntactic position is much too precious to assign it a single specific
> meaning.
> 
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)

I almost posted this suggestion yesterday but didn't because I wasn't 
sure it fit the context.  But maybe it does.

There is a possibility of parsing selected meta data items from doc 
strings.  Doc strings already are a type of meta data that gets set to 
an attribute, so this would be extending that precedence.

If the __signature__ is parsed from the first line, it puts it right 
below the function definition.

     def pattern_search(seq, pattern, start=0):
         """ fn(str, str, int) -> (str, int)

             Get a sub-string and index using a pattern.
         """
         <block>

This doesn't have as strong a relationship as adding syntax in the 
definition.  Having the syntax in the definition seems (to me) like it 
should always be enforced.  While having it in the doc string seems more 
like suggested use, and it may, or may not be enforced.  I also like 
that it is self documenting.

If the signature doesn't get recognized and parsed correctly, then an 
exception would probably occur as soon as something tries to use 
__signature__, so it should be reasonably easy to debug.

Depending on how freely the signature line is parsed it could fit a 
pattern or be anything that someone finds to be useful.

Other meta data such as __version__, __author__, and/or __date__ could 
also be parsed from doc strings.  Currently those are used very 
inconsistently in the standard library.

Cheers,
    Ron