Abstraction in Python? - Page 1
Forum section: electronics / projects

author: OptymizeSoham
author_rank: Newbie
timestamp: June 23, 2022, 12:25:03 pm
content: I'm trying to pick up Python for a project, and I'm a bit confused about how to use abstraction and classes. (I'm not a very experienced programmer, so apologies for the basic level of this question.) I come from a Java/Ocaml background, and what I've been trying to do is as follows: I have abstract classes for a graph and a graph advanced (a graph with some more fancy methods), that looks something like thisCode:class AbstractGraph:def method1(self):raise NotImplementedError...class AbstractAdvanced:def method2(self):raise NotImplementedError...I then have an implementation of a graph:Code:class Graph(AbstractGraph):def method1(self):* actual code *Now my question is: can I do something like this?Code:class Advanced(AbstractAdvanced, AbstractGraph):def method2(self):*actual code, using the methods from AbstractGraph*In other words, how can I define the methods of Advanced abstractly in terms of the methods of AbstractGraph, and then somehow pass Graph into a constructor to get an instance of Advanced that uses Advanced's definitions with Graph's implementation?In terms of Ocaml, I'm trying to treat AbstractAdvanced and AbstractGraph as module types, but I've played around a little with python and I'm not sure how to get this to work.

author: janoc
author_rank: Super Contributor
timestamp: June 23, 2022, 12:45:51 pm
content: See:https://pythongeeks.org/inheritance-in-python/Also for abstract classes (interfaces from C# or Java):https://docs.python.org/3/library/abc.html

author: ve7xen
author_rank: Super Contributor
timestamp: June 23, 2022, 09:04:52 pm
content: First and most tangential of all, theCode:abc(abstract base class) module is the Pythonic way to define abstract classes, though I don't believe it changes anything with respect to the question.QuoteI don't think so, since there is no inheritance between Advanced and Graph, no implementation of AbstractGraph's methods will exist on Advanced. If Advanced inherited from Graph instead, that would work fine, since there would be an implementation of AbstractGraph's methods in the tree. Otherwise, Advanced itself needs to implement AbstractGraph.I don't know quite what you're trying to do here, but in many cases composition (ie. Advanced holds an instance of AbstractGraph as a property, instead of is one itself) is a more sensible pattern than multiple inheritance, and it sounds like that might be the case here.It also might be worth reminding that Python is a dynamically typed language where 'duck typing' is the idiomatic way to handle 'interfaces' in many / most cases. So unless you are actually intending to inherit implementations, the inheritance might actually be holding you back here. 'Interfaces' are *required* in strongly typed languages, because otherwise there would be no binding for the method signature to call, but this is not something you need to deal with in Python where the methods are bound to the instance, not the type of the reference to it a la Java.

author: wizard69
author_rank: Super Contributor
timestamp: June 24, 2022, 04:44:21 am
content: While this doesn't directly answer your question, there are already many Python plotting libs or packages. One example is MatPlotLib but there are others and and even high level interfaces to MatPlotLib. I mention these because the source is available for most of these libs and as such there is much to learn based on the differing approaches of others.

author: bson
author_rank: Unknown
timestamp: June 24, 2022, 07:08:37 am
content: Yes, but you'll want constructors and a bit more scaffolding. Technically the ctor's aren't needed, but if you always add them you don't have to remember which classes have them and which don't, and accidentally omit calling them. (Python doesn't do this automatically and there is no default ctor.) Any arguments (beyond self) to __init__ are constructor arguments.Code:class AbstractGraph(object):def __init__(self):passdef method1(self):raise NotImplementedError...class AbstractAdvanced(object):def __init__(self):passdef method2(self):raise NotImplementedError...Code:class Graph(AbstractGraph):def __init__(self):super(Graph, self).__init__()def method1(self):* actual code *The __init__() method is the constructor.You could also, in a different context where it made sense, make Graph.method1() call super(self).method1() and so implement itself using the super class's. This is useful for implementinginterceptionwhere you class might for example trace all calls to another class, implement performance metrics, or an observer pattern (for setters/getters). Or, you just simply extend the existing functionality.

author: RoGeorge
author_rank: Super Contributor
timestamp: June 24, 2022, 07:26:57 am
content: From the 'Clear Code' channel:Understanding classes and object-oriented programming [Python Tutorial]https://youtu.be/_vr5faCXFo8Understanding decorators [Python tutorial]https://youtu.be/nVdF7QT-Ggg7 simple tips for python beginnershttps://youtu.be/ESTf0ut14N0

author: ledtester
author_rank: Super Contributor
timestamp: June 24, 2022, 09:02:39 am
content: Because python is duck-typed there is no need to define Abstract* classes. An object is what it is based simply on what methods it implements.One way of creating a class with a certain set of methods is the "mix-in" technique:https://stackoverflow.com/questions/533631/what-is-a-mixin-and-why-is-it-usefulYou can also use decorators to modify a class definition:https://pencilprogrammer.com/decorate-python-class/Also consider whether your methods can just be free-standing functions. For instance, counting the connected components in a graph can be implemented if you have access to the basic structure of the graph (list of all nodes and the edges for a given node).Tell us more about what methods are in the AbstractGraph and AbstractAdvanced classes and we might be able to give you more specific ideas.

author: janoc
author_rank: Super Contributor
timestamp: June 24, 2022, 08:18:54 pm
content: Quote from: ledtester on June 24, 2022, 09:02:39 amSorry but abstract classes have nothing to do with duck typing (or typing in general). They are anarchitecturalconcept, allowing to define common interfaces. And that applies regardless of whether or not the language is duck typed or statically typed.Quote from: ledtester on June 24, 2022, 09:02:39 amPlease don't. Mixins are a terrible concept that is pretty much discouraged by modern software architecture. They directly lead to creation of "dogcats" and "flying submarines that run on rails", because it is so easy to combine unrelated functionality.The same applies to a lesser degree to inheritance, especially multiple inheritance.Use object composition instead, not mixins.Quote from: ledtester on June 24, 2022, 09:02:39 amThat's not relevant for what the OP is asking/doing. One can also monkeypatch the class or define custom metaclass to modify the class definition but that's not indented for what the OP is trying to do.