Thanks for the reply Todd. If `True` was redefined somewhere else, it would still be `True` for you. You could do `from oldlib import True as true` and have `true` equal ` np.bool_(1)`. You could reference `oldlib.True` or do `oldlib.function(True=x)` to interact with the name in the old library.
None of this would actually apply to `True`, as it's a reserved word in all versions. The proposal only applies to new keywords that are used as names in other libraries. Again, thanks for taking the time. -- Carl Smith carl.in...@gmail.com On 16 May 2018 at 14:46, Todd <toddr...@gmail.com> wrote: > On Tue, May 15, 2018, 23:03 Carl Smith <carl.in...@gmail.com> wrote: > >> >> >>> On Tue, May 15, 2018 at 8:41 PM, Steven D'Aprano <st...@pearwood.info> >>> wrote: >>> >>>> Inspired by Alex Brault's post: >>>> >>>> https://mail.python.org/pipermail/python-ideas/2018-May/050750.html >>>> >>>> I'd like to suggest we copy C#'s idea of verbatim identifiers, but >>>> using >>>> a backslash rather than @ sign: >>>> >>>> \name >>>> >>>> would allow "name" to be used as an identifier, even if it clashes with >>>> a keyword. >>> >>> >> I strongly disagree, but can't seem to get anyone >> to bite. >> >> We want to be able to introduce a keyword that was formally a name, still >> allow >> it to be used as a name, still allow code that uses it as a keyword to >> interoperate >> >> with code that uses it as a name >> , without changing the language >> or implementation >> too much. >> >> Ideally, Python would still not allow the keyword to be used as a name >> and a >> keyword in the same file?? >> >> The lexer could class the tokens as *keynames*, and the parser could use >> the >> context of the first instance of each keyname to determine if it's a name >> or >> keyword for the rest of that file. Projects that used the word as a name >> would >> only be prevented from also using it as a keyword in the same file. >> >> It's really then a question of whether users could elegantly and naturally >> reference a name in another module without introducing the name to the >> current module's namespace. >> >> We only reference external names (as syntactic names) in import >> statements, >> as properties after the dot operator, and as keyword arguments. >> >> If code that used the word as a keyword was still allowed to use the word >> as >> a name after the dot operator and as a keyword argument *in an >> invocation*, >> it would only change the language in a subtle way. >> >> If we could reference keynames in import statements, but not import the >> name, >> so basically allow `from keyname import keyname as name`, but not allow >> `import keyname`, we could still easily import things that used the >> keyname >> as a name. This wouldn't change the language too dramatically either. >> >> Maybe I'm just being dumb, but it seems like three subtle changes to the >> language would allow for everything we want to have, with only minor >> limitations >> on the rare occasion that you want to use the new keyword with a library >> that is >> also using the same keyword as a name. >> >> I promise not to push this idea again, but would really appreciate >> someone taking >> a couple of minutes to explain why it's not worth responding to. I'm not >> offended, >> but would like to know what I'm doing wrong. >> >> Thanks. >> > > > I think your idea would work okay if everyone followed good programming > practices. But when you have files that are tens of thousands of ugly code > written by dozens of non-programmers over a dozen years it sounds like a > recipe for a nightmare. > > For example someone you never met that left your group ten years ago could > have made "True" be "np.bool_(1)" on a whim that makes your code break > later in very hard-to-debug ways. > > To put it simply, I think it encourages people to take convenient > shortcuts with implications they don't understand. > >> > _______________________________________________ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
