On 8/15/06, Paul Prescod <[EMAIL PROTECTED]> wrote: > On 8/15/06, Collin Winter <[EMAIL PROTECTED]> wrote: > > How is > > this significantly better than my dict-based approach, which uses > > standardised dict keys to indicate the kind of metadata? > > The dict-based approach introduces an extra namespace to manage. What if two > different groups start fighting over the keyword "type" or "doc" or "lock"?
How do you foresee this arising? Do you think users will start wanting to apply several different typechecking systems to the same function? The idea behind these standard keys is to a) keep them limited in number, and b) keep them limited in scope. At the moment, I can only foresee two of these: "type" and "doc". My justification for "type" is that users won't be using multiple type systems on the same parameter (and if they are, that their own problem); for "doc" is that a docstring is just a Python string, and there's really only own way to look at that within the scope of documentation strings. Beyond these applications, the annotation consumers are on their own. Consumers that operate in the same domain may well coordinate their keys, and popular keys might make it into the list of standard keys (like the process for getting a module into the stdlib). I hope to have a second draft of the pre-PEP within a few days that includes this idea. Collin Winter _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
