[Barry A. Warsaw] > FP> However, there are other contexts where the concept of a > FP> compound dictionary of all globals and locals would be useful. > FP> Maybe we could have some allvars() similar to globals() and > FP> locals(), and use `... % allvars()' instead of `.sub()'? So > FP> this would serve both string interpolation and other avenues. > Or maybe just make vars() do something more useful when no arguments > are given? I surely had the thought, but changing the meaning of an existing library function is most probably out of question. > In any event, allvars() or a-different-vars() is out of scope for this > PEP. We'd use it if it was there, but I think it needs its own PEP, > which someone else will have to champion. I do not see myself championing a PEP yet, I'm not sure the Python community is soft enough for my thin skin (not so thin maybe, but I really had my share of over-long discussions in other projects, I want some rest in these days). On the other hand, the allvars() suggestion is right on the point in my opinion. It is not a stand-alone suggestion, its goal was to stress out that `.sub()' is too far from the `%' operator, it looks like a random addition. The available formatting paradigms of Python, I mean, those which are standard, should look a bit more unified, just to preserve overall elegance. If we want Python to stay elegant (which is the source of comfort and pleasure, these being the main goals of using Python after all), we have to seek elegance in each Python move. To the risk of looking frenetic and heretic, I guess that `$' would become more acceptable in view of the preceding paragraph, if we were introducing an `$' operator for driving `$' substitutions, the same as the `%' operator currently drives `%' substitutions. I'm not asserting that this is the direction to take, but I'm presenting this as an example of a direction that would be a bit less shocking, and which through some unification, could somewhat salvage the messy aspect of having two formatting characters. Saying that PEP 292 rejects an idea because this idea would require another PEP to be debated and accepted beforehand, and than rushing the acceptance of PEP 292 as it stands, is probably missing the point of the discussion. Each time such an argumentation is made, we loose vision and favour the blossom of various Python features in random directions, which is not good in the long term for Python self-consistency and elegance. -- François Pinard http://www.iro.umontreal.ca/~pinard
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