About a month ago I wrote (but did not publish) a proposal that combined
#pragmas and method attributes. The reason I combined them is that in a
lot of cases method "attributes" are supposed to be available in the
parse tree, before the program begins to run. Here is my rough draft.
----
We've been discussing method attributes for a long time and I think that
it might be worth hashing out in more detail, especially for type
declaration experimentation. I'm proposing a generalization of the
"decl" keyword that hasbeen kicked around in the types-sig. Other
applications include Spark grammar strings, XML pattern-trigger strings,
multiple language doc-strings, IDE "hints", optimization hints,
associated multimedia (down with glass ttys!), IDL definitions, thread
locking declarations, method visibility declarations, ...
Of course some subset of attributes might migrate into Python's "core
language". Decl gives us a place to experiment and get them right before
we do that migration.
Declarations would always be associated with functions, classes or
modules. They would be simple string-keyed values in a dictionary
attached to the function, class or module called __decls__.
The syntax would be
decl {<key> :"value", <key> :"value" }
Key would be a Python name. Value would be any Python string. In the
case of a type declaration it might be:
decl {type:"def(myint: int) returns bar",
french_doc:"Bonjour",
english_doc: "Hello"}
def func( myint ):
return bar()
No string interpolation or other runtime-ish evaluation is done by the
compiler on those strings. Neither the keys nor the values are evaluated
as Python expressions. We could have a feature that would allow values
to be dictionary-ish strings themselves:
decl {type:"def(myint: int) returns bar",
doc : "Bonjour",
languages:{
french: "Hello"}
}
That would presumably be rare (if we allow it at all). Again, there
would be no evaluation or interpolation. The left hand must be a name.
The right must be a
Code which depended on the declaration can do whatever it wants...if it
has some idea of "execution context" and it wants to (e.g.) do
interpolation with things that have percent signs, nobody would stop it.
A decl that applies to a function or class immediately precedes the
funtion or class. A decl that applies to a module precedes all other
statements other than the docstring (which can be before or after).
--
Paul Prescod - ISOGEN Consulting Engineer speaking for himself
"I and my companions suffer from a disease of the heart that can only
be cured with gold", Hernan Cortes
#pragmas and method attributes. The reason I combined them is that in a
lot of cases method "attributes" are supposed to be available in the
parse tree, before the program begins to run. Here is my rough draft.
----
We've been discussing method attributes for a long time and I think that
it might be worth hashing out in more detail, especially for type
declaration experimentation. I'm proposing a generalization of the
"decl" keyword that hasbeen kicked around in the types-sig. Other
applications include Spark grammar strings, XML pattern-trigger strings,
multiple language doc-strings, IDE "hints", optimization hints,
associated multimedia (down with glass ttys!), IDL definitions, thread
locking declarations, method visibility declarations, ...
Of course some subset of attributes might migrate into Python's "core
language". Decl gives us a place to experiment and get them right before
we do that migration.
Declarations would always be associated with functions, classes or
modules. They would be simple string-keyed values in a dictionary
attached to the function, class or module called __decls__.
The syntax would be
decl {<key> :"value", <key> :"value" }
Key would be a Python name. Value would be any Python string. In the
case of a type declaration it might be:
decl {type:"def(myint: int) returns bar",
french_doc:"Bonjour",
english_doc: "Hello"}
def func( myint ):
return bar()
No string interpolation or other runtime-ish evaluation is done by the
compiler on those strings. Neither the keys nor the values are evaluated
as Python expressions. We could have a feature that would allow values
to be dictionary-ish strings themselves:
decl {type:"def(myint: int) returns bar",
doc : "Bonjour",
languages:{
french: "Hello"}
}
That would presumably be rare (if we allow it at all). Again, there
would be no evaluation or interpolation. The left hand must be a name.
The right must be a
Code which depended on the declaration can do whatever it wants...if it
has some idea of "execution context" and it wants to (e.g.) do
interpolation with things that have percent signs, nobody would stop it.
A decl that applies to a function or class immediately precedes the
funtion or class. A decl that applies to a module precedes all other
statements other than the docstring (which can be before or after).
--
Paul Prescod - ISOGEN Consulting Engineer speaking for himself
"I and my companions suffer from a disease of the heart that can only
be cured with gold", Hernan Cortes