[Python-ideas] list of reserved identifiers in program?

[Daniel Fetchinson]

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
_______________________________________________
Python-ideas mailing list
Python...@python.org
http://mail.python.org/mailman/listinfo/python-ideas

[Christian Heimes]

Am 26.10.2012 11:22, schrieb Daniel Fetchinson:
> 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?

Something like
http://hg.python.org/cpython/file/405932ddca9c/Lib/keyword.py ? :)

Christian

[Daniel Fetchinson]

>> 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?
>
> Something like
> http://hg.python.org/cpython/file/405932ddca9c/Lib/keyword.py ? :)

Exactly! Thanks a lot, I did not know about it before!

Cheers,
Daniel


--
Psss, psss, put it down! - http://www.cafepress.com/putitdown

[Rob Cliffe]

On 26/10/2012 10:22, Daniel Fetchinson wrote:
> 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
>
>

>>> import keyword
>>> keyword.kwlist
['and', 'as', 'assert', 'break', 'class', 'continue', 'def', 'del',
'elif', 'else', 'except', 'exec', 'finally', 'for', 'from', 'global',
'if', 'import', 'in', 'is', 'lambda', 'not', 'or', 'pass', 'print',
'raise', 'return', 'try', 'while', 'with', 'yield']
>>>
Rob Cliffe

[Steven D'Aprano]

On 26/10/12 20:22, Daniel Fetchinson wrote:
> 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.

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

[Mark Hackett]

On Friday 26 Oct 2012, Steven D'Aprano wrote:
> On 26/10/12 20:22, Daniel Fetchinson wrote:
> > 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.
>
> 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".
>

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).

[Jasper St. Pierre]

On Fri, Oct 26, 2012 at 5:58 AM, Mark Hackett
<mark.h...@metoffice.gov.uk> wrote:
> On Friday 26 Oct 2012, Steven D'Aprano wrote:
>> On 26/10/12 20:22, Daniel Fetchinson wrote:
>> > 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.
>>
>> 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".
>>
>
> 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).

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.

> _______________________________________________
> Python-ideas mailing list
> Python...@python.org
> http://mail.python.org/mailman/listinfo/python-ideas

--
Jasper