Question Protected by gnat
    Tweeted twitter.com/StackSoftEng/status/901380731523538944
4 added 7 characters in body; edited tags
source | link

I'm fully aware that pylint and other static analysis tools are not all-knowing, and sometimes their advice must be disobeyed. (This applies for various classes of messages, not just conventions.)


If I have classes like

class related_methods():

    def a_method(self):
        self.stack.function(self.my_var)

class more_methods():

    def b_method(self):
        self.otherfunc()

class implement_methods(related_methods, more_methods):

    def __init__(self):
        self.stack  = some()
        self.my_var = other()

    def otherfunc(self):
        self.a_method()

Obviously, that's contrived. Here's a better example, if you like.

I believe this style is called using "mixins".

Like other tools, pylint rates this code at -21.67 / 10, primarily because it thinks more_methods and related_methods don't have self or attributes otherfunc, stack, annd my_var because without running the code, it apparently can't see related_methods and more_methods are mixed-in to implement_methods.

Compilers and static analysis tools can't always solve the Halting Problem, but I feel this is certainly a case in which looking at what's inherited by implement_methods would show this is perfectly valid, and that would be a very easy thing to do.

Why do static analysis tools reject this valid (I think) OOP pattern?

Either:

  1. They don't even try to check inheritance or

  2. mixins are discouraged in idiomatic, readable Python


#1 is obviously incorrect because if I ask pylint to tell me about a class of mine that inherits unittest.TestCase that uses self.assertEqual, (something defined only in unittest.TestCase), it does not complain.

Are mixins unpythonic or discouraged?

I'm fully aware that pylint and other static analysis tools are not all-knowing, and sometimes their advice must be disobeyed. (This applies for various classes of messages, not just conventions.)


If I have classes like

class related_methods():

    def a_method(self):
        self.stack.function(self.my_var)

class more_methods():

    def b_method(self):
        self.otherfunc()

class implement_methods(related_methods, more_methods):

    def __init__(self):
        self.stack  = some()
        self.my_var = other()

    def otherfunc(self):
        self.a_method()

Obviously, contrived. Here's a better example, if you like.

I believe this style is called using "mixins".

Like other tools, pylint rates this code at -21.67 / 10, primarily because it thinks more_methods and related_methods don't have self or attributes otherfunc, stack, annd my_var because without running the code, it apparently can't see related_methods and more_methods are mixed-in to implement_methods.

Compilers and static analysis tools can't always solve the Halting Problem, but I feel this is certainly a case in which looking at what's inherited by implement_methods would show this is perfectly valid, and that would be a very easy thing to do.

Why do static analysis tools reject this valid (I think) OOP pattern?

Either:

  1. They don't even try to check inheritance or

  2. mixins are discouraged in idiomatic, readable Python


#1 is obviously incorrect because if I ask pylint to tell me about a class of mine that inherits unittest.TestCase that uses self.assertEqual, (something defined only in unittest.TestCase), it does not complain.

Are mixins unpythonic or discouraged?

I'm fully aware that pylint and other static analysis tools are not all-knowing, and sometimes their advice must be disobeyed. (This applies for various classes of messages, not just conventions.)


If I have classes like

class related_methods():

    def a_method(self):
        self.stack.function(self.my_var)

class more_methods():

    def b_method(self):
        self.otherfunc()

class implement_methods(related_methods, more_methods):

    def __init__(self):
        self.stack  = some()
        self.my_var = other()

    def otherfunc(self):
        self.a_method()

Obviously, that's contrived. Here's a better example, if you like.

I believe this style is called using "mixins".

Like other tools, pylint rates this code at -21.67 / 10, primarily because it thinks more_methods and related_methods don't have self or attributes otherfunc, stack, annd my_var because without running the code, it apparently can't see related_methods and more_methods are mixed-in to implement_methods.

Compilers and static analysis tools can't always solve the Halting Problem, but I feel this is certainly a case in which looking at what's inherited by implement_methods would show this is perfectly valid, and that would be a very easy thing to do.

Why do static analysis tools reject this valid (I think) OOP pattern?

Either:

  1. They don't even try to check inheritance or

  2. mixins are discouraged in idiomatic, readable Python


#1 is obviously incorrect because if I ask pylint to tell me about a class of mine that inherits unittest.TestCase that uses self.assertEqual, (something defined only in unittest.TestCase), it does not complain.

Are mixins unpythonic or discouraged?

3 replaced http://programmers.stackexchange.com/ with https://softwareengineering.stackexchange.com/
source | link

I'm fully aware that pylint and other static analysis tools are not all-knowing, and sometimes their advice must be disobeyed. (This applies for various classes of messages, not just conventions.)


If I have classes like

class related_methods():

    def a_method(self):
        self.stack.function(self.my_var)

class more_methods():

    def b_method(self):
        self.otherfunc()

class implement_methods(related_methods, more_methods):

    def __init__(self):
        self.stack  = some()
        self.my_var = other()

    def otherfunc(self):
        self.a_method()

Obviously, contrived. Here's a better example, if you like.

I believe this style is called using "mixins".

Like other tools, pylint rates this code at -21.67 / 10, primarily because it thinks more_methods and related_methods don't have self or attributes otherfunc, stack, annd my_var because without running the code, it apparently can't see related_methods and more_methods are mixed-in to implement_methods.

Compilers and static analysis tools can't always solve the Halting ProblemCompilers and static analysis tools can't always solve the Halting Problem, but I feel this is certainly a case in which looking at what's inherited by implement_methods would show this is perfectly valid, and that would be a very easy thing to do.

Why do static analysis tools reject this valid (I think) OOP pattern?

Either:

  1. They don't even try to check inheritance or

  2. mixins are discouraged in idiomatic, readable Python


#1 is obviously incorrect because if I ask pylint to tell me about a class of mine that inherits unittest.TestCase that uses self.assertEqual, (something defined only in unittest.TestCase), it does not complain.

Are mixins unpythonic or discouraged?

I'm fully aware that pylint and other static analysis tools are not all-knowing, and sometimes their advice must be disobeyed. (This applies for various classes of messages, not just conventions.)


If I have classes like

class related_methods():

    def a_method(self):
        self.stack.function(self.my_var)

class more_methods():

    def b_method(self):
        self.otherfunc()

class implement_methods(related_methods, more_methods):

    def __init__(self):
        self.stack  = some()
        self.my_var = other()

    def otherfunc(self):
        self.a_method()

Obviously, contrived. Here's a better example, if you like.

I believe this style is called using "mixins".

Like other tools, pylint rates this code at -21.67 / 10, primarily because it thinks more_methods and related_methods don't have self or attributes otherfunc, stack, annd my_var because without running the code, it apparently can't see related_methods and more_methods are mixed-in to implement_methods.

Compilers and static analysis tools can't always solve the Halting Problem, but I feel this is certainly a case in which looking at what's inherited by implement_methods would show this is perfectly valid, and that would be a very easy thing to do.

Why do static analysis tools reject this valid (I think) OOP pattern?

Either:

  1. They don't even try to check inheritance or

  2. mixins are discouraged in idiomatic, readable Python


#1 is obviously incorrect because if I ask pylint to tell me about a class of mine that inherits unittest.TestCase that uses self.assertEqual, (something defined only in unittest.TestCase), it does not complain.

Are mixins unpythonic or discouraged?

I'm fully aware that pylint and other static analysis tools are not all-knowing, and sometimes their advice must be disobeyed. (This applies for various classes of messages, not just conventions.)


If I have classes like

class related_methods():

    def a_method(self):
        self.stack.function(self.my_var)

class more_methods():

    def b_method(self):
        self.otherfunc()

class implement_methods(related_methods, more_methods):

    def __init__(self):
        self.stack  = some()
        self.my_var = other()

    def otherfunc(self):
        self.a_method()

Obviously, contrived. Here's a better example, if you like.

I believe this style is called using "mixins".

Like other tools, pylint rates this code at -21.67 / 10, primarily because it thinks more_methods and related_methods don't have self or attributes otherfunc, stack, annd my_var because without running the code, it apparently can't see related_methods and more_methods are mixed-in to implement_methods.

Compilers and static analysis tools can't always solve the Halting Problem, but I feel this is certainly a case in which looking at what's inherited by implement_methods would show this is perfectly valid, and that would be a very easy thing to do.

Why do static analysis tools reject this valid (I think) OOP pattern?

Either:

  1. They don't even try to check inheritance or

  2. mixins are discouraged in idiomatic, readable Python


#1 is obviously incorrect because if I ask pylint to tell me about a class of mine that inherits unittest.TestCase that uses self.assertEqual, (something defined only in unittest.TestCase), it does not complain.

Are mixins unpythonic or discouraged?

2 added 10 characters in body
source | link

I'm fully aware that pylint and other static analysis tools are not all-knowing, and sometimes their advice must be disobeyed. (This applies for various classes of messages, not just conventions.)


If I have classes like

class related_methods():

    def a_method(self):
        self.stack.function(self.my_var)

class more_methods():

    def b_method(self):
        self.otherfunc()

class implement_methods(related_methods, more_methods):

    def __init__(self):
        self.stack  = some()
        self.my_var = other()

    def otherfunc(self):
        self.a_method()

Obviously, contrived. Here's a better example, if you like.

I believe this style is called using "mixins".

Like other tools, pylint rates this code at -21.67 / 10, primarily because it thinks more_methods and related_methods don't have self or attributes otherfunc, stack, annd my_var because without running the code, it apparently can't see related_methods and more_methods are mixed-in to implement_methods.

Compilers and static analysis tools can't always solve the Halting Problem, but I feel this is certainly a case in which looking at what's inherited by implement_methods would show this is perfectly valid, and that would be a very easy thing to do.

Why do static analysis tools reject this valid (I think) OOP pattern?

Either:

  1. They don't even try to check inheritance or

  2. mixins are discouraged in idiomatic, readable Python


#1 is obviously incorrect because if I ask pylint to tell me about a class of mine that inherits unittest.TestCase using that uses self.assertEqual, something(something defined only in unittest.TestCase), it does not complain.

Are mixins unpythonic or discouraged?

I'm fully aware that pylint and other static analysis tools are not all-knowing, and sometimes their advice must be disobeyed. (This applies for various classes of messages, not just conventions.)


If I have classes like

class related_methods():

    def a_method(self):
        self.stack.function(self.my_var)

class more_methods():

    def b_method(self):
        self.otherfunc()

class implement_methods(related_methods, more_methods):

    def __init__(self):
        self.stack  = some()
        self.my_var = other()

    def otherfunc(self):
        self.a_method()

Obviously, contrived. Here's a better example, if you like.

I believe this style is called using "mixins".

Like other tools, pylint rates this code at -21.67 / 10, primarily because it thinks more_methods and related_methods don't have self or attributes otherfunc, stack, annd my_var because without running the code, it apparently can't see related_methods and more_methods are mixed-in to implement_methods.

Compilers and static analysis tools can't always solve the Halting Problem, but I feel this is certainly a case in which looking at what's inherited by implement_methods would show this is perfectly valid, and that would be a very easy thing to do.

Why do static analysis tools reject this valid (I think) OOP pattern?

Either:

  1. They don't even try to check inheritance or

  2. mixins are discouraged in idiomatic, readable Python


#1 is obviously incorrect because if I ask pylint to tell me about a class of mine that inherits unittest.TestCase using self.assertEqual, something defined in unittest.TestCase, it does not complain.

Are mixins unpythonic or discouraged?

I'm fully aware that pylint and other static analysis tools are not all-knowing, and sometimes their advice must be disobeyed. (This applies for various classes of messages, not just conventions.)


If I have classes like

class related_methods():

    def a_method(self):
        self.stack.function(self.my_var)

class more_methods():

    def b_method(self):
        self.otherfunc()

class implement_methods(related_methods, more_methods):

    def __init__(self):
        self.stack  = some()
        self.my_var = other()

    def otherfunc(self):
        self.a_method()

Obviously, contrived. Here's a better example, if you like.

I believe this style is called using "mixins".

Like other tools, pylint rates this code at -21.67 / 10, primarily because it thinks more_methods and related_methods don't have self or attributes otherfunc, stack, annd my_var because without running the code, it apparently can't see related_methods and more_methods are mixed-in to implement_methods.

Compilers and static analysis tools can't always solve the Halting Problem, but I feel this is certainly a case in which looking at what's inherited by implement_methods would show this is perfectly valid, and that would be a very easy thing to do.

Why do static analysis tools reject this valid (I think) OOP pattern?

Either:

  1. They don't even try to check inheritance or

  2. mixins are discouraged in idiomatic, readable Python


#1 is obviously incorrect because if I ask pylint to tell me about a class of mine that inherits unittest.TestCase that uses self.assertEqual, (something defined only in unittest.TestCase), it does not complain.

Are mixins unpythonic or discouraged?

1
source | link