On Wed, May 16, 2018 at 10:26 AM, Carl Smith <carl.in...@gmail.com> wrote:
> 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. > > Not if you need to make changes in the same tens of thousands of lines file. > 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. > No it isn't. It was added in Python 2.3 and only became a keyword in Python 3. Prior to that lots of other packages defined their own "True" (or "true" or "TRUE", etc), which is why it wasn't made a keyword for such a long time. But this is just an example of the sort of problem that can come up with your approach. The overall issue is that python has no way of knowing if the keyword is being used for legitimate backwards-compatibility purposes or someone intentionally overrode after it was made a keyword because they somehow thought it was a good idea. That is why being explicit about overriding the keyword is so important. > 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/ > >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
