> > > Overall it isn't bad...it's a little weird to have a method that depends > > > on sys._getframe(1) (or as the say in Tcl-land "upvar"). It may set a > > > bad precedent... > > > > No, the real implementation will be in C. C functions always have > > access to locals and globals. > > I didn't mean it will be a bad precedent because of the implemention. I > mean that methods do not usually peak into their caller's variables, > even from C. What other methods do that? Dunno about methods, but locals(), globals(), vars() and dir() do this or something like it. > I'm still "+0" despite being somewhat uncomfortable with that > aspect. I think little would be lost if sub() always required a dict (or perhaps keyword args, although that feels like a YAGNI now). I think that the key thing here is to set the precedent of using $ and the specific syntax proposed, not necessarily to have this as a built-in string methong. Note: posixpath.expandvars() doesn't have $$, which is essential, and leaves unknown variables alone, which we (mostly) agree is not the right thing to do. --Guido van Rossum (home page: http://www.python.org/~guido/)
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