Abstraction in Python?

[OptymizeSoham]

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 this
 

Code: [Select]

class AbstractGraph:
   def method1(self):
      raise NotImplementedError
   ...
 
class AbstractAdvanced:
   def method2(self):
      raise NotImplementedError
   ... I then have an implementation of a graph:
 

Code: [Select]

class Graph(AbstractGraph):
   def method1(self):
      * actual code * Now my question is: can I do something like this?
 

Code: [Select]

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.

[janoc]

See:

https://pythongeeks.org/inheritance-in-python/

Also for abstract classes (interfaces from C# or Java):

https://docs.python.org/3/library/abc.html

[ve7xen]

First and most tangential of all, the

Code: [Select]

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.

Now my question is: can I do something like this?

I 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.

[wizard69]

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.

[bson]

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: [Select]

class AbstractGraph(object):
   def __init__(self):
      pass

   def method1(self):
      raise NotImplementedError
   ...
 
class AbstractAdvanced(object):
   def __init__(self):
      pass

   def method2(self):
      raise NotImplementedError
   ...


Code: [Select]

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 implementing interception where 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.

[RoGeorge]

From the 'Clear Code' channel:

Understanding classes and object-oriented programming [Python Tutorial]
https://youtu.be/_vr5faCXFo8

Understanding decorators [Python tutorial]
https://youtu.be/nVdF7QT-Ggg

7 simple tips for python beginners
https://youtu.be/ESTf0ut14N0

[ledtester]

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-useful

You 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.

[janoc]

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.

Sorry but abstract classes have nothing to do with duck typing (or typing in general). They are an architectural concept, allowing to define common interfaces. And that applies regardless of whether or not the language is duck typed or statically typed.

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-useful

Please 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.

You can also use decorators to modify a class definition:

https://pencilprogrammer.com/decorate-python-class/

That'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.

[/quote]