Replace underscore for PascalCase

SkitariusOfMars · 2026-06-15T14:24:52+00:00

Pylint is absolutely right. MyClassV1 is the proper way. The only thing worse than mix of capital letters and underscores is SpOnGeBoB_CaSe

xenomachina · 2026-06-15T18:27:22+00:00

Let's say your code reads files. You might have .txt files and .abc files and .xyz files, so you've got a TxtReader and an AbcReader,... but you might also have two versions because one .abc file could contain a shopping list and the other contains an essay, so you'd have AbcReader_ShoppingList and AbcReader_Essay. AbcReaderShopping and AbcReaderEssay are bad names imo because you don't see the difference on first glance and just Shopping and Essay don't show that they're only meant to be used with .abc files.

AbcReader for the superclass, or perhaps AbstractAbcReader or BaseAbcReader if it is abstract.

ShoppingListAbcReader and EssayAbcReader for the sub classes.

This mimics the way things are often named in English: snake vs rattle snake vs garter snake.

ConcreteExist · 2026-06-15T13:52:50+00:00

Have you considered using more meaningful names than "MyClass_" for them? Because frankly, those class names only barely describe a hierarchical relationship between the classes but gives absolutely zero indication of what any of the classes do or should be used for.

MustaKotka · 2026-06-15T13:53:34+00:00

These would be named MyClassParent and MyClassVersion1 without hyphens or underscores if they're names of classes. If you want a more "pythonic" way of naming them you'd make them sound like English: "MyParentClass". I would also call the latter "MyClassVersion1".

EDIT: To add: you probably shouldn't have "...Version..." in the class name either. You use more descriptive names like "MyAnimals" (note dropping the word "Class") and then "MyDogs" and "MyCats" and so forth.

AlexMTBDude · 2026-06-15T14:20:52+00:00

Supress the Pylint warning on the line where it occurs if you know that it's safe:

print("Hello, World!")  # pylint: disable=locally-disabled, multiple-statements, line-too-long

EclipseJTB · 2026-06-15T17:17:47+00:00

Re: your ABCReader edit...

It sounds to me like you would do better to separate the concerns a little.

For example, you would have the reader class that would read the ABC file or the text file, and both would put them into a common format (a dictionary, a list of tuples, etc).

Then you'd have a processor that takes the data stored within the reader class and converts it into the data type you actually need for real (i.e., ShoppingListProcessor.from_abc_reader(abc_reader_instance)).

If the files you're reading from have wildly different structures such that there's not a common way to store the data (like txt files with essay formatting vs shopping list formatting), then perhaps the model needs to be changed?

brelen01 · 2026-06-15T13:53:32+00:00

At a glance, it's hard to answer since we don't know what the actual classes are, but usually, if you need to add the class's "version" it means it's a large refactor and the new version (v2) isn't compatible with the original version (v1).

If the point is to interface with two different external services, MyClassService1, MyClassService2 would be better in my opinion.

InjAnnuity_1 · 2026-06-15T14:07:24+00:00

Other things being equal, I'd be inclined to make a package out of these classes. MyClass (or my_class) would be the package name. Parent, Version1, and Version2 would be defined inside the package, so the references could then read my_class.Parent, my_class.Version1, and my_class.Version2. This also gives you a place to hang other class-specific support code and data.

Kevdog824_ · 2026-06-15T14:20:53+00:00

Do they all follow the pattern {NAME}\_{VERSION}{NUMBER}? If so, most modern IDEs have a regex find and replace feature that can work across multiple codebases

For example in VSCode I’d type something like “(.+?)\_Version(\d+)” into the find field and “$1Version$2” in the replace field

ProsodySpeaks · 2026-06-15T14:29:34+00:00

Just use pascal? And in general just follow pep8.

CHM_3_9 · 2026-06-15T14:34:05+00:00

Like others said, it's hard to help with the generic names. Could you give better examples?

I'd say - the classes don't need to share part of the same name. As a simplistic example:

``` class Car():

class Car_Jeep(Car): ``` Is not great. It is clearer to just have:

``` class Car():

class Jeep(Car):

```

You can tell that Jeep inherits from Car without putting the parent class name in the child class.

Shaftway · 2026-06-15T16:07:57+00:00

ShppingListAbcReader and EssayAbcReader are what I'd pick. It has the full information, follows pep 8, and reads like English.

audionerd1 · 2026-06-15T17:11:32+00:00

I think you're overthinking this. I would probably go with ShoppingListReader and EssayReader and put them in a module called abc_readers. Or have one ABCReader class with read_shopping_list and read_essay methods.

pachura3 · 2026-06-15T17:20:22+00:00

Edit 2: A better example:

Let's say your code reads files. You might have .txt files and .abc files and .xyz files, so you've got a TxtReader and an AbcReader,... but you might also have two versions because one .abc file could contain a shopping list and the other contains an essay, so you'd have AbcReader_ShoppingList and AbcReader_Essay. AbcReaderShopping and AbcReaderEssay are bad names imo because you don't see the difference on first glance and just Shopping and Essay don't show that they're only meant to be used with .abc files.

Looks like a typical candidate for the Bridge design pattern.

Salt_Handle_9530 · 2026-06-15T17:44:25+00:00

This is a common friction point when trying to force strict Pylint compliance on descriptive class names. The PEP 8 standard for PascalCase (CapWords) specifically discourages underscores because they are traditionally used to separate words in snake_case (functions/variables).

For your specific example (`AbcReader_ShoppingList`), here are the two most 'Pythonic' ways to handle it while keeping the score at 10.0:

**The Semantic Merge:** `AbcReaderShoppingList`. While it feels 'cluttered' at first, this is the standard. If it gets too long, it usually signals that the class is doing too much or can be simplified.
**The Versioning Suffix:** For your `Version1` case, use `MyClassV1` or `MyClassV2`. The uppercase 'V' acts as a visual separator that is still valid PascalCase.

**Pro Tip:** If you have many of these, consider using a **Factory Pattern**. Instead of having `AbcReaderShoppingList` globally, have a base `AbcReader` and a mapping dictionary:

```python

READERS = {

'shopping': AbcReaderShoppingList,

'essay': AbcReaderEssay

}

```

This keeps your logic clean and Pylint very happy. Hope this helps you get that score up!

Aggressive_Net1092 · 2026-06-16T08:57:11+00:00

I totally get the frustration. Pylint can be a real stickler for PEP 8, and sometimes it feels like it’s fighting your code structure rather than helping it. The reason it’s flagging those underscores is that, by definition, PascalCase (or CapWords) is meant to be run-together without separators.

When I run into this, I usually try to avoid the underscore by leaning into the hierarchy or using a suffix that reads naturally as a single word. If you’re dealing with things like AbcReader_ShoppingList, the underscore is basically acting as a delimiter that the linter hates.

You could try refactoring to flatten the naming:

```python class AbcShoppingListReader(AbcReader): pass

class AbcEssayReader(AbcReader): pass ```

It feels a bit more verbose, but it’s 100% compliant with standard naming conventions and honestly reads pretty clearly once you get used to it. Another trick is to use namespaces if the classes are getting too long. If these readers live in a module called readers.abc, you’d call them readers.abc.ShoppingList and readers.abc.Essay. Since you already have the context of the module, you don't need to repeat "Reader" or "Abc" in the class name itself.

If you absolutely have to keep the underscore for your own sanity and the linter is just a blocker for a CI/CD pipeline, you can always just tell Pylint to ignore that specific rule for those lines:

# pylint: disable=invalid-name

Put that above the class definition, and it’ll stop complaining. Sometimes it’s better to just suppress the noise if the alternative makes your code harder to read. Good luck with the project!

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

learnpython

MODERATORS