Fredrik Lundh wrote: > > so it's no longer an experimental feature, it's a "static variables" > thing? > > umm. I had nearly changed my mind to a "okay, if you insist +1", > but now it's back to -1 again. maybe in Py3K... I think that we get 95% of the benefit without any of the "dangers" (though I don't agree with the arguments against) if we allow the attachment of properties only at compile time and disallow mutation of them at runtime. That will allow Spark, EventDOM, multi-lingual docstrings etc., but disallow static variables. I'm not agreeing that using function properties as static variables is a bad thing...I'm just saying that we might be able to agree on a less powerful mechanism and then revisit the more general one in Py3K. Let's not forget that Py3K is going to be a very hard exercise in trying to combine everyone's ideas "all at once". Experience gained now is golden. We should probably be more amenable to "experimental ideas" now -- secure in the knowledge that they can be killed off in Py3K. If we put ideas we are not 100% comfortable with in Py3K we will be stuck with them forever. -- Paul Prescod - ISOGEN Consulting Engineer speaking for himself "Ivory towers are no longer in order. We need ivory networks. Today, sitting quietly and thinking is the world's greatest generator of wealth and prosperity." - http://www.bespoke.org/viridian/print.asp?t=140
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