Of course, in Python 8 this naming convention will indeed be enforced. https://mail.python.org/pipermail/python-dev/2016-March/143603.html Op 1 mrt. 2017 15:16 schreef "Alexandre Brault" <abrault@mapgears.com>:

Long story short, it's because there can be good reasons to ignore PEP8 naming conventions. Linting tools can be taught to skip over an intentional PEP8 violation. A grammar rule can't

Alex

On 2017-03-01 09:04 AM, Mathieu BEAL wrote:

I was wondering why the PEP coding style (https://www.python.org/dev/ peps/pep-0008/) is not natively included in python grammar ?

For instance, both, *function definition* and *class definition*, are using the same “NAME” token. ((see, https://docs.python.org/3/ reference/grammar.html).

classdef: 'class' NAME ['(' [arglist] ')'] ':' suite

funcdef: 'def' NAME parameters ['->' test] ':' suite

Then, we are using libraries like pyflake, flake8, pylint, to check the coding style.

It seems useful to natively make distinction between NAME of classdef and NAME of funcdef, with something like:

classdef: 'class' NAME_CLASS ['(' [arglist] ')'] ':' suite

funcdef: 'def' NAME_FUNC parameters ['->' test] ':' suite

NAME_CLASS:

· Class name should normally use the CapWord convention;

NAME_FUNC:

· Function name should be lowercase, with words separated by underscore as necessary to improve readability,

· mixedCase is allowed;

STYLE_CAP_WORDS = r’([A-Z]{1}[a-z]+(_[A-Z]{1}[a-z]+)*)’

STYLE_UNDERSCORE_LOW_WORDS = r’([a-z]+(_[a-z]+)*)’

STYLE_MIXED_CASE = r’([a-z]{1,}([A-Z]{1}[a-z]+)*’)

NAME_FUNC = STYLE_LOW_WORDS

| STYLE_UNDERSCORE_LOW_WORDS

| STYLE_MIXED_CASE

NAME_CLASS = STYLE_CAP_WORDS

| NAME_FUNC # naming convention for functions may be used in cases where the interface is documented and used primarily as a callable (pep8 source).

I didn't find any information about this point in a previous post or elsewhere. Is there any reason for such a choice ? or is it a dark old discussion we never talk about ?

Mathieu

-------------

import re

# Testing the first part of the class def, only.

style_cap_words = r'^class ([A-Z]{1}[a-z]+(_?[A-Z]{1}[a-z]+)*)$'

compiled_style_cap_words = re.compile(style_cap_words)

status_samples = {True:['class Hello',

'class Hel_Lo', # ok if Hel and Lo are 2 words

'class HelLo', # same.

],

False:['class HellO',

'class _He',

'class HEllo',

'class HE',

'class H',

'class h',

'class Hell_oo',

'class Hell_',

'class _hell',

'class H_E_L_L_O',

'class _H']}

def is_matched(sample, pattern=compiled_style_cap_words):

matched = pattern.match(sample)

return matched is not None

for status, samples in status_samples.items():

for sample in samples:

is_correct = status == is_matched(sample)

assert is_correct, '%s is not correct, required %s' % (sample, status)

_______________________________________________ Python-ideas mailing listPython-ideas@python.orghttps://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/

On Thu, Mar 2, 2017 at 11:04 AM, Barry Warsaw <barry@python.org> wrote:

On Mar 01, 2017, at 03:04 PM, Mathieu BEAL wrote:

...

I was wondering why the PEP coding style ( https://www.python.org/dev/peps/pep-0008/) is not natively included in python grammar ?

Well, the simple answer is that the grammar predates PEP 8 (or any PEP) by many years.

Also, the grammar has a much stricter backward compatibility guarantee than any style guide ever can (or should). After some discussion about this and related topics on python-list, I posted this collection: http://rosuav.blogspot.com/2016/04/falsehoods-programmers-believe-about.html ChrisA

Of course, in Python 8 this naming convention will indeed be enforced. https://mail.python.org/pipermail/python-dev/2016-March/143603.html Op 1 mrt. 2017 15:16 schreef "Alexandre Brault" <abrault@mapgears.com>:

Long story short, it's because there can be good reasons to ignore PEP8 naming conventions. Linting tools can be taught to skip over an intentional PEP8 violation. A grammar rule can't

Alex

On 2017-03-01 09:04 AM, Mathieu BEAL wrote:

I was wondering why the PEP coding style (https://www.python.org/dev/ peps/pep-0008/) is not natively included in python grammar ?

For instance, both, *function definition* and *class definition*, are using the same “NAME” token. ((see, https://docs.python.org/3/ reference/grammar.html).

classdef: 'class' NAME ['(' [arglist] ')'] ':' suite

funcdef: 'def' NAME parameters ['->' test] ':' suite

Then, we are using libraries like pyflake, flake8, pylint, to check the coding style.

It seems useful to natively make distinction between NAME of classdef and NAME of funcdef, with something like:

classdef: 'class' NAME_CLASS ['(' [arglist] ')'] ':' suite

funcdef: 'def' NAME_FUNC parameters ['->' test] ':' suite

NAME_CLASS:

· Class name should normally use the CapWord convention;

NAME_FUNC:

· Function name should be lowercase, with words separated by underscore as necessary to improve readability,

· mixedCase is allowed;

STYLE_CAP_WORDS = r’([A-Z]{1}[a-z]+(_[A-Z]{1}[a-z]+)*)’

STYLE_UNDERSCORE_LOW_WORDS = r’([a-z]+(_[a-z]+)*)’

STYLE_MIXED_CASE = r’([a-z]{1,}([A-Z]{1}[a-z]+)*’)

NAME_FUNC = STYLE_LOW_WORDS

| STYLE_UNDERSCORE_LOW_WORDS

| STYLE_MIXED_CASE

NAME_CLASS = STYLE_CAP_WORDS

| NAME_FUNC # naming convention for functions may be used in cases where the interface is documented and used primarily as a callable (pep8 source).

I didn't find any information about this point in a previous post or elsewhere. Is there any reason for such a choice ? or is it a dark old discussion we never talk about ?

Mathieu

-------------

import re

# Testing the first part of the class def, only.

style_cap_words = r'^class ([A-Z]{1}[a-z]+(_?[A-Z]{1}[a-z]+)*)$'

compiled_style_cap_words = re.compile(style_cap_words)

status_samples = {True:['class Hello',

'class Hel_Lo', # ok if Hel and Lo are 2 words

'class HelLo', # same.

],

False:['class HellO',

'class _He',

'class HEllo',

'class HE',

'class H',

'class h',

'class Hell_oo',

'class Hell_',

'class _hell',

'class H_E_L_L_O',

'class _H']}

def is_matched(sample, pattern=compiled_style_cap_words):

matched = pattern.match(sample)

return matched is not None

for status, samples in status_samples.items():

for sample in samples:

is_correct = status == is_matched(sample)

assert is_correct, '%s is not correct, required %s' % (sample, status)

_______________________________________________ Python-ideas mailing listPython-ideas@python.orghttps://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/

On Thu, Mar 2, 2017 at 11:04 AM, Barry Warsaw <barry@python.org> wrote:

On Mar 01, 2017, at 03:04 PM, Mathieu BEAL wrote:

...

I was wondering why the PEP coding style ( https://www.python.org/dev/peps/pep-0008/) is not natively included in python grammar ?

Well, the simple answer is that the grammar predates PEP 8 (or any PEP) by many years.

Also, the grammar has a much stricter backward compatibility guarantee than any style guide ever can (or should). After some discussion about this and related topics on python-list, I posted this collection: http://rosuav.blogspot.com/2016/04/falsehoods-programmers-believe-about.html ChrisA