Guido van Rossum wrote: > So, what's next? In Python 2.4a3 (to be released this Thursday), > everything remains as currently in CVS. For 2.4b1, I will consider a > change of @ to some other single character, even though I think that @ > has the advantage of being the same character used by a similar > feature in Java. It's been argued that it's not quite the same, since > @ in Java is used for attributes that don't change semantics. But > Python's dynamic nature makes that its syntactic elements never mean > quite the same thing as similar constructs in other languages, and > there is definitely significant overlap. One issue with the '@' character choice is that in the context of Jython things can get rather confusing and I mean beyond the fact that the need of an "annotation" to get a static method will seem rather bizarre to Java people. It somewhat put the burden on Jython to try to do the obvious thing: Consider this java annotation definition (concretely these get compiled to interfaces): public @interface Author { String value() default ""; } Now this potential Jython code: import Author classs A: # not inheriting from a Java class # this also the exact legal java syntax for this @Author("batman") def method(self): pass in the past and at the moment interfaces are not callable, but here we would like to produce a nice error or warning, we are not inheriting from a java class so there is no way to attach the annotation. But in this case: import java import Author classs A(java.lang.Runnable): @Author("batman") def run(self): # this one pass here we potentially could attach the annotation to the exposed method. My point is basically that '@' will likely generate more user questions (which are time consuming) and expectations than a different character choice in Jython context. Samuele
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4