I think naming an interface with an I prefix is perfectly acceptable.

e.g.:

• IFoo
• IPublishable

A few years back I used Zope Interfaces. I noticed most codebases used this convention. Our team did too.

We preferred IFoo vs. FooInterface or IFooInterface

If you're using Python 2.6 or higher, you can use the Abstract Base Class module from the standard library if you want to enforce abstractness. Here's an example:

from abc import ABCMeta, abstractmethod

class SomeAbstractClass(object):
    __metaclass__ = ABCMeta

    @abstractmethod
    def this_method_must_be_overridden(self):
        return "But it can have an implementation (callable via super)."

class ConcreteSubclass(SomeAbstractClass):
    def this_method_must_be_overridden(self):
        s = super(ConcreteSubclass, self).this_method_must_be_overridden()
        return s.replace("can", "does").replace(" (callable via super)", "")

Output:

>>> a = SomeAbstractClass()
Traceback (most recent call last):
  File "<pyshell#13>", line 1, in <module>
    a = SomeAbstractClass()
TypeError: Can't instantiate abstract class SomeAbstractClass with abstract
methods this_method_must_be_overridden
>>> c = ConcreteSubclass()
>>> c.this_method_must_be_overridden()
'But it does have an implementation.'

"I'm wondering if there is a widely accepted convention for naming base classed in OOP"

Short answer: no, there is not.

If you want to read something directly out of the name of a class, you need to consult the programming guidelines of your team or organization. There are only very few widely accepted naming conventions, and even those don't apply to "OOP in general", but usually to a specific language ecosystem.

For example, in C#, I would usually expect a type name starting with a single I to be an interface (though not every team names gives interfaces always an I prefix; it is a convention suggested by Microsoft). For a class ending with the word Exception I would expect it to be a derivation of System.Exception. And (as mentioned in a comment by @Blake, thanks), attribute classes in C# usually end with the suffix Attribute. In Python, the PEP 8 style guide suggests to let exception classes (which represent errors) end with the name Error.

Specifically for C#, I guess that list is complete. I cannot remember to have seen a naming style "broadly accepted" across teams and organizations, where part of a class name induces a clear semantics.

I think the property decorator approach is the cleanest. Just silence pylint:

@abstractmethod
@property
def CONST_CLASS_ATTR(self) -> str:  # pylint: disable=invalid-name
    return "base"

This will only silence the warning for this specific method and its overrides.

According to Bloch's Effective Java (Item 18) the Abstract prefix is a convention used in a special case.

You can combine the virtues of interfaces and abstract classes by providing an abstract skeletal implementation class to go with each nontrivial interface that you export. ... By convention, skeletal implementations are called AbstractInterface, where Interface is the name of the interface they implement.

But Bloch also points out that the name SkeletalInterface would have made sense, but concludes that

the Abstract convention is now firmly established.

As other answers have pointed out, in general there is no reason to apply this naming convention to all abstract classes.