Gabu!! ☁️ ΘΔ

for some reason. its impossible to get anything relevant because all the answers i can find are for people who have Literally The Dumbest Problem and not my problem. anyway

hey so i'm adding pylint to an old project at work and its complaining about names like

C0103: Variable name "SomeCoolClass" doesn't conform to snake_case naming style (invalid-name)

obviously i can either rename the variable or add a comment disabling that error but i would like to conceptually fix it if possible... the thing is that this variable is not a variable but its a class definition returned by a method at runtime (inside another method), ex

def what():
    SomeCoolClass = give_me_the_class()
    a_thing = SomeCoolClass.create_a_thing()

now in this particular case i can put the give_me_the_class line at the top level and it doesn't complain but there's also places where that's not possible because it might not be registered at import time. anyway it's about a conceptual problem here: assume that the class getter can't be generated at import time, it's like dynamically generated by the method.

i also think it would be even worse to rename that class name to a snake case variable name because then it would look more like a class instance rather than a class definition to the passing eye and could easily cause mistakes.

is there really no solution except to disable that warning on that line? i've even tried things like adding type annotations to make it clear that its a class type, but i think pylint doesn't look at those?

#python #pylint #python question #code question

You must log in to comment.

in reply to @gabu's post:

tin roof @tinruufu10/16/2023, 12:56 PM

i might be rationalising here, but i actually like when linters do this, and i can explain why. a camel-case class name is dependable and constant; you'll be able to import it and use it in isinstance() checks elsewhere. a class returned by a function is not the same; it's ephemeral to the namespace you're working in, and so using a different naming convention makes sense to me

this comes up a lot in django apps when dealing with, for instance, forms generated from models. i like the visible distinction between explicitly-defined classes and classes created by functions

to make it clear it's a class and not an instance while adopting this style, you could start getting big into type annotations and write, like, some_cool_class: type[BaseCoolClass] = give_me_the_class(), perhaps?

(sorry for being the 'your question is wrong' person. one horrible workaround would be to define a subclass in whatever scope you're in, but that's not what you're actually looking for: class SomeCoolClass(give_me_the_class()): pass)

Gabu!! ☁️ ΘΔ @gabu10/16/2023, 2:14 PM

no that's good, i'm looking for the "i'm looking in the wrong place" answers! also the reason why i'd rather fix the mistake in the right way rather than disable the warning

you make a good point! it does make it easy to see the difference between an imported class and a generated class

i'm not really ready to go big into type annotations but it'd be a good step in the future. big reason i'm refactoring everything and adding code formatters and linters and more unit testing and stuff in the first place is to make everything clearer, less fault prone, more consistently styled, etc. it'd make it a lot easier to step into the project and harder to make mistakes

three space indent @nago-10/16/2023, 2:35 PM

You can create an allowed list of pylint variable names, too, and just special case each one in a conf file without cluttering your .py file.

Or, you can try and disable the warning file-wide with a single comment, and just refactor until the damage is minimized.

Or, it's possible that if you instruct pylint that it is allowed to import the library that is generating class names, it may become smart enough to start applying class naming rules to the results of those calls.

Gabu!! ☁️ ΘΔ @gabu10/16/2023, 8:08 PM

ive been doing the former for some autogenerated not-quite-enums where pylint gives a no-member warning, but it doesnt scale that nicely and is easy to forget (and clutters the config which in my case case is the pyproject.toml)

disabling the warning means incorrect variable names in the rest of the file arent caught either... and sadly we have some devs that forget and randomly use camelCase in python which is part of the reason im adding a linter ^^;

instructing pylint was wat i was hoping for but it doesnt seem possible :( at he very least i noticed in the middle of making my original post that when doing this at the top level of the file pylint doesnt complain about it so that was 90% of the issue solved

three space indent @nago-10/16/2023, 8:10 PM

Have you tried importing the packages that provide the give_me_the_class() functions using extension-pkg-allow-list?

Pinned Tags