list of reserved identifiers in program?
Hi folks, Would it be a good idea to have a built-in list of strings containing the reserved identifiers of python such as 'assert', 'import', etc? The reason I think this would be useful is that whenever I write a class with user defined methods I always have to exclude the reserved keywords. So for instance myinstance.mymethod( ) is okay but myinstance.assert( ) is not. In these cases I use the convention myinstance._assert( ), etc. In order to test for these cases I hard code the keywords in a list and test from there. I take the list of keywords from http://docs.python.org/reference/lexical_analysis.html#keywords But what if these change in the future? So if I would have a built-in list containing all the keywords of the given interpreter version in question my life would be that much easier. What do you think? Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown
Am 26.10.2012 11:22, schrieb Daniel Fetchinson:
Something like http://hg.python.org/cpython/file/405932ddca9c/Lib/keyword.py ? :) Christian
Exactly! Thanks a lot, I did not know about it before! Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown
On 26/10/12 20:22, Daniel Fetchinson wrote:
The usual convention is that leading underscores are private, and trailing underscores are used to avoid name clashes with reserved words. So myinstance.assert_ rather than myinstance._assert, which would be considered "private, do not use". -- Steven
On Friday 26 Oct 2012, Steven D'Aprano wrote:
One story I heard about development was a site that had included as an early C++ header had #define private public If users REALLY want to use a function you though was private, they will. Convention works just as well without having people go to extreme lengths to avoid it (where their use case makes it beneficial).
On Fri, Oct 26, 2012 at 5:58 AM, Mark Hackett <mark.hackett@metoffice.gov.uk> wrote:
I use it more as a guarantee. Any API that you mark as private can and will break in the future, and is not covered by any stability promise. If they really need to do some awfulness that my library can help out with, sure, they can hack up the private API, but they're on their own.
-- Jasper
Am 26.10.2012 11:22, schrieb Daniel Fetchinson:
Something like http://hg.python.org/cpython/file/405932ddca9c/Lib/keyword.py ? :) Christian
Exactly! Thanks a lot, I did not know about it before! Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown
On 26/10/12 20:22, Daniel Fetchinson wrote:
The usual convention is that leading underscores are private, and trailing underscores are used to avoid name clashes with reserved words. So myinstance.assert_ rather than myinstance._assert, which would be considered "private, do not use". -- Steven
On Friday 26 Oct 2012, Steven D'Aprano wrote:
One story I heard about development was a site that had included as an early C++ header had #define private public If users REALLY want to use a function you though was private, they will. Convention works just as well without having people go to extreme lengths to avoid it (where their use case makes it beneficial).
On Fri, Oct 26, 2012 at 5:58 AM, Mark Hackett <mark.hackett@metoffice.gov.uk> wrote:
I use it more as a guarantee. Any API that you mark as private can and will break in the future, and is not covered by any stability promise. If they really need to do some awfulness that my library can help out with, sure, they can hack up the private API, but they're on their own.
-- Jasper
participants (6)
-
Christian Heimes -
Daniel Fetchinson -
Jasper St. Pierre -
Mark Hackett -
Rob Cliffe -
Steven D'Aprano