Most Pythonic way to declare an abstract class property : <p>Assume you're writing an abstract class and one or more of its non-abstract class methods require the concrete class to have a specific class attribute; e.g., if instances of each concrete class can be constructed by matching against a different regular expression, you might want to give your ABC the following:</p>

<pre><code>@classmethod
def parse(cls, s):
    m = re.fullmatch(cls.PATTERN, s)
    if not m:
        raise ValueError(s)
    return cls(**m.groupdict())
</code></pre>

<p>(Maybe this could be better implemented with a custom metaclass, but try to ignore that for the sake of the example.)</p>

<p>Now, because overriding of abstract methods &amp; properties is checked at instance creation time, not subclass creation time, trying to use <code>abc.abstractmethod</code> to ensure concrete classes have <code>PATTERN</code> attributes won't work — but surely there should be <em>something</em> there to tell anyone looking at your code "I didn't forget to define <code>PATTERN</code> on the ABC; the concrete classes are supposed to define their own."  The question is: Which <em>something</em> is the most Pythonic?</p>

<ol>
<li><p><strong>Pile of decorators</strong></p>

<pre><code>@property
@abc.abstractmethod
def PATTERN(self):
    pass
</code></pre>

<p>(Assume Python 3.4 or higher, by the way.)  This can be very misleading to readers, as it implies that <code>PATTERN</code> should be an instance property instead of a class attribute.</p></li>
<li><p><strong>Tower of decorators</strong></p>

<pre><code>@property
@classmethod
@abc.abstractmethod
def PATTERN(cls):
    pass
</code></pre>

<p>This can be very confusing to readers, as <code>@property</code> and <code>@classmethod</code> normally can't be combined; they only work together here (for a given value of "work") because the method is ignored once it's overridden.</p></li>
<li><p><strong>Dummy value</strong></p>

<pre><code>PATTERN = ''
</code></pre>

<p>If a concrete class fails to define its own <code>PATTERN</code>, <code>parse</code> will only accept empty input.  This option isn't widely applicable, as not all use cases will have an appropriate dummy value.</p></li>
<li><p><strong>Error-inducing dummy value</strong></p>

<pre><code>PATTERN = None
</code></pre>

<p>If a concrete class fails to define its own <code>PATTERN</code>, <code>parse</code> will raise an error, and the programmer gets what they deserve.</p></li>
<li><p><strong>Do nothing.</strong>  Basically a more hardcore variant of #4.  There can be a note in the ABC's docstring somewhere, but the ABC itself shouldn't have anything in the way of a <code>PATTERN</code> attribute.</p></li>
<li><p>Other???</p></li>
</ol>
