> [Alex] > >>>So it can't be global, as it must stay a keyword for backwards > >>>compatibility at least until 3.0. > > [David] > >>Why? Removing keywords should be much simpler than adding them. I > >>have no idea how hard it is to hack the parser to adjust, but I > >>can't imagine how having 'global' no longer be a keyword as far as > >>its concerned break b/w compatibility. > >> > >>What am I missing? > > [GvR] > > I don't recall the context, but I think the real issue with removing > > 'global' is that there's too much code out there that uses the global > > syntax to remove the global statement before 3.0. > [David] > I would never have suggested that. Just that we can evolve the parser > to retain the old usage > > global a,b,c > > while allowing a new usage > > global.a = value > > by removing 'global' from the list of reserved words and doing "fancy > stuff" in the parser. Note that I very much don't know the details > of the "fancy stuff". Ah. *If* we want to parse both it would be easier to keep global as a keyword and do fancy stuff to recognize the second form... But I think somewhere in the mega-thread about this topic is hidden the conclusion that there are better ways to do this. --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