PEP 3107 and stronger typing (note: probably a newbie question)

[Paul Boddie]

On 28 Jun, 07:53, a... at mac.com (Alex Martelli) wrote:
> John Nagle <n... at animats.com> wrote:
> > PEP 3107 is static typing without enforcement, which is not a good thing.
>
> Wrong: PEP3107 is a syntax for adding arbitrary metadata annotations (so
> that said annotations don't get squished where they don't belong, such
> as decorators or docstrings, as they used to be in 2.*).

Really, we all know where PEP 3107 came from and where people are
likely to go with it. When you kick the ball up the field to the
striker, what's the most likely thing the striker is going to do? Pass
back to the goalkeeper? (Apart from in an England vs. Republic of
Ireland game, that is.)

>  The PEP itself offers a good example that should be vastly sufficient to destroy the
> "is static typing" notion:
>
> def compile(source: "something compilable",
>                    filename: "where the compilable thing comes from",
>                    mode: "is this a single statement or a suite?"):
>
> how do you get from that example to "PEP 3107 is static typing"?

You just need to put yourself in the position of those advocating
static typing. "Oh, 'something compilable': that's an interface,
'Compilable', which has this and this methods. [Multi-month discussion
ensues on which methods.] And the filename: well, that's a string!"
And so it continues.

>  What an absurd, illogical leap.  Here, it's being used to provide
> "per-argument docstrings" which a pydoc-like system could access as
> compile.func_annotation['source'] and the like, and format as it likes
> best.  Type annotations (not necessarily for checking -- third party
> libraries are free to provide completely different semantics, such as
> adaptation) is another possible use, and Pythonistas' creativity may
> well supply many, many others.

I'll accept that it allows higher precision annotations than what
we've had before, although I think it'd be a strong case of denial if
we didn't admit that the people who've probably had to struggle the
most with metadata in docstrings have been those who have been writing
wrappers and bindings. I remember decorators being proposed as useful
there, but anyway. As for javadoc-style documentation as a compelling
motivation, I've seen too much of this kind of thing to be persuaded:

  /**
   * The compile method.
   * @param source Compilable A Compilable
   * @param filename String A string
   * @param mode Mode A mode
   */
  public void compile(Compilable source, String filename, Mode mode);

With PEP 3107, you either get the same inane commentary inline, but
the code is still readable, or you have lots of prose, breaking up the
signature and making it potentially harder to read. The best
documentation might have some reference element as that proposed, but
the prose is what makes it stand out. And in any case, I await this
kind of thing with the above scheme:

  def compile(source : MyDoc("something compilable", some_arg,
some_other_arg),
              filename : MyOtherDoc("where the compilable thing comes
from", yet_more_stuff),
              mode : MyDocEnum("is this a single statement or a
suite?",
                  EnumValue("it's a statement"), EnumValue("no, it's a
suite!"))):

I guess this could just be me being cynical as usual, though.

Paul