Any comments? My draft of a new PEP.

[Bengt Richter]

On Sat, 18 Aug 2001 16:35:45 GMT, Courageous <jkraska1 at san.rr.com> wrote:

>
>>Could you add 'protocol' to the reserved keyword list?
>
>directive                I like this, as compilers need pragmas sometimes
>foreign                   What's this for?
>interface                I like this, too, but wonder what the argument is in
>                                 favor of _needing_ it
>static                      Would rather gouge my eyes out. We already have
>                                class- and module- level attributes. The only possible
>                                use for it is method- and function- level statics which are
>                                bad programming practice and "not very OO," imo.
>yield                      Misfortunate word for its evocation of thread semantics;
>                                Would have rather had "produce" or "result" or some such.
>protocol                What's this for?
>abstract                How is this necessary if we have interface?
>
>Personally I would like to add:
>
>declare, strict
>
>Perhaps I should write a PEP. :-)
>

It occurred to me that it might be good to be able to factor out
some kinds of information into a/some separate file/s.

For example, if you wanted to use 'strict' to indicate that a function
is not going to use some dynamic features of Python, there's several
ways to do it. One would be to introduce strict as a keyword modifying
'def foo x,y:'. Another might be to put 'strict foo foo_source_file_path'
in a project file and have the interpreter cache such info when it
starts up. This leaves the source clean. Or, for per-file meta info, you
could have foo.py and foo.met. If you did that, you could factor out
big additional docstrings, and help info, etc. also.

If you wanted a general purpose way of referring to a chunk of source
code in foo.py, there could be a span block that would do nothing
except identify its suite by a supplied name, e.g.,

span calcy: y = c0 + c1*x + c2*x**2 + c3*x**3

In another file you could then refer to it to indicate e.g. that
everything in calcy scope could be assumed floating point, and
globals could be assumed to have constant values, as in a config
file with a command per line, e.g., (for illustration only)
   meta calcy foo.py: const globals; all float

But 'span' would be transparent if there was no external info telling
the interpreter about calcy in that file. And it would always be
safe to eliminate the meta-data file, with possible speed/space sacrifice.
E.g., you could upgrade the interpreter and drop the file if the new version
didn't handle the previous kind of meta data. Plus you could have platform
dependent meta-data.

This is not fully thought out, but I wanted to (re?)introduce the concept of factoring
out non-semantic meta-info whose presence doesn't change the intended correct result
of the program, but may offer opportunities for optimization, extra validation,
etc. 'span' is inspired by the html tag. (Maybe another very similar word would
be more apt for Python? ;-) It's just a way to give a name to things that don't
already have one.

_______________________
Separate topic...

On a similar note, I've thought it might be nice to be able to have an unobtrusive
tagging convention in python comments to serve like anchors and links in html.
The idea is to make it easy to write CGI that presents code from source
and links back and forth with supporting html and/or other documentation.

All this would require is an easy to use convention, so in your source
you could write
   foo(x, y) # tricky! -- see ##foodoc#
or such, and maybe
   def foo(x, y):    ##:foodef#
as a target.

This would also be a way to signal intent to provide docs ;-)
  
##foodoc# would be easy to translate to
   <a href='foodoc.html'>##foodoc#</a>
and ##:foodef# to
   <a name='foodef'></a>
A link inside source to the latter would need a '#' in front, so maybe, e.g.,
   -- see code at ###foodef#
could become
   <a href='#foodef'>###foodef#</a>
in the CGI-served page. Links in html docs to code would use something like
    <a href='http://python.org/cgi-bin/src2html/foo.py#foodef'>See def in foo.py source!</a>
or relative versions of same, depending on how the whole context is entered.

The CGI would be pretty simple to do, I think.
Does anything like this already exist for Python?