Kotlin Limitations vs Python

social-media-failThis page will serve as repository of limitations found when attempting to move kotlin code to python code. Some limitations are a natural consequence of moving to static types, others are effectively inherited from Java.

The list here is based on placing those I find most significant at the top, and the further down the list the less significant.

base class parameter pass through


Kotlin, like python, allows for optional parameters, a feature not found in Java.  A consequence of this feature is that libraries with heavily used classes can over time evolve to have a large number of optional parameters in the most heavily used methods.  A larger number of parameters should only occur in code in a language that has optional parameters, as without the parameters being optional, every extra parameter  would introduce overhead on every call.  These methods with a large number of parameters are often frequently used methods, and the goal is that well chosen defaults will mean that most of these optional parameters are only provided in exceptional cases.  While a typical instance of the class may require only 2 or 3 parameters, while there may be as many as 20 to chose from.

To find examples, I simply thought: “what are the most widely used python packages I can think of?”.  The first three that occurred to me to check were sqlalchemy,  attr, and Django, and for each of these I looked for the most basic usage cases I could find. The first examples I found are:

  • sqlalchemy:   Table Class  20 optional parameters (see ‘parameters’)
  • attr: atrr.s() function – 9 optional parameters (see attr.s function)
  • Django: Field class – 22 optional parameters (see __init__)

While such a large number of parameters should not normally occur in Java due to lack of optional parameters, I think these example establish that the pattern is common in well regarded python packages.

The Problem.

Consider the Django Fieldclass . This class serves as a base class for several other classes, such as  TextField, TimeField, BinaryField etc.  To code examples like these cleanly, some type of language mechanism is needed which effectively achieves:  “include all fields from the base class constructor (or other method from the base class) as also parameters to this class unless specifically declared in this class“.

Python uses the *args,**kwargs system, which for several reasons is not an appropriate solution for kotlin, but is at least a solution.  There are some more elegant solutions possible for kotlin, and perhaps one will be added at a later time.

In Python the code for defining the BinaryField Class is as follows (not exact code for simplicity):

class BinaryField(Field):

    def __init__(self, *args, **kwargs):
        kwargs['editable'] = False
        super().__init__(*args, **kwargs)
        // other init code goes here

while in kotlin (slightly changed for name conventions and simplicity) the code becomes:

class BinaryField(
        verboseName:String?=null, name:String?=null, primaryKey:Boolean=false,
        maxLength:Int?=null, unique:Boolean=false, blank:Boolean=false,
        nulled:Boolean=false, dbIndex:Boolean=false, rel:String?=null,
        default:Any?=null, //editable:Boolean=true, - force 'false' for editable
        uniqueForYear:Int?=null, choices:String?=null, helpText:String="",
        dbColumn:Int?=null, dbTablespace:Int?=null, autoCreated:Boolean=false,
        validators:List<Any>?=null, errorMessages:String?=null
 ):Field(verboseName=verboseName, name=name, primaryKey=primaryKey,
        maxLength=maxLength, unique=unique, blank=blank, nulled=nulled,
        dbIndex=dbIndex, rel=rel, default=default, editable=false,
        serialize=serialize, uniqueForYear=uniqueForYear, choices=choices,
        helpText=helpText, dbColumn=dbColumn,
        dbTablespace=dbTablespace, autoCreated=autoCreated,
        validators=validators, errorMessages=errorMessages) {
  // class code here

Clearly, the call to the base constructor will be much shorter if not using named parameters, which is a choice, but in a list this long I would use named parameters.

The code (or almost identical code) will be repeated TextField, TimeField and the over 12 other fields that inherit from Field. Any update to the parameter list for the base Field class is tedious to say the least.

This is a case where kotlin requires boilerplate that is not required in python. What is needed is some way to say “accept all parameters to the base default constructor not specifically named in the base call, and pass these parameters through“. Given this problem will not occur in Java libraries which have no default parameters, it may be some time before kotlin designers consider this, if ever.  In the mean time, messy.

Constructor Calls

(to be added: by Nov 13)

Intricate, preset order, class data initialisation

Kotlin has what can appear a rather strange way of implementing the overriding of properties when extending classes.  The result is that when extending classes, the behaviour of initcode can be unexpected.  The way to avoid this is to use lazy properties in place of initialising during init.

open class Base{
    val simple = 3
    open val open = 3
    open val openGet = 3
    open val getter get()= 3
    open val getOpen get()= 3
    open val getDelg by GetDelg(3)
    init {
        println("base simple $simple open $open openG $openGet "+
                "getOpen $getOpen getter $getter "+
                " getDelg $getDelg")
    //open fun add(a:Int,b:Int) = a + b

class SubClass:Base(){
    override val open = 4
    override val openGet get()= 4
    override val getter get() = 4
    override val getOpen = 4
    //override val getDelg by GetDelg(4)  //uncomment for null pointer
    init {
        println("sub simple $simple open $open openG $openGet "+
                "getOpen $getOpen getter $getter "+
                " getDelg $getDelg")

class GetDelg(val value:Int){
    operator fun getValue(thisRef: Any?, property: KProperty<*>): Int {
        return value

The print from instancing a SubClass object is:

base simple 3 open 0 openG 4 getOpen 0 getter 4 getDelg 3
sub simple 3 open 4 openG 4 getOpen 4 getter 4 getDelg 3


Open is 0 in the base class init because the code to set the value has not yet been run, but not it is not 3 as you would expect.

openG, a value overridden by a get() method, perhaps unexpected returns the override value in both init() methods

getOpen, a get() method in the base overridden by a simple initialisation, behaves as a simple initialised value overridden by a new initialise, which is to be unitialised in the base init() method

getter() , a get() method overidden by another get() method returns the override value as does openG

getDelg() actually generates a null pointer exception if called during  the base init() method, as the overridden value has not been calculated

Note: part of this behaviour is base on the fact that overridden properties are actually new distinct properties, so the do not inherit values from base class property which is still accessible via super.<name>.  This means, counterintuitively, that open in the base init() method, returns 0while super.open in the subclass init()will return 3

I will update with more on the use of lazy to avoid this issue, but the main point is to think carefully before initialising values in a base class that are open.

*args, **kwargs (to be added)

A specific use of *args and **kwargs has already been covered in base class parameter pass through.

Outside of that specific use, kotlin does have effective equivalents to most use cases, but may depend on the reflections library, which is not available on all platforms at this time.

vararg parameters capture the equivalent to a *args list, and allows for using the list for calling in a manner very similar to python.

callBy provide most of the functionality of **kwargs when used for calling functions, but some code is needed to map parameter names to KParameters.  A link to such code may be added to this page is someone asks 🙂

For cases where it is desired to capture parameters in map for, using a map actually makes better sense in every case I have found, but I will update this further if I find a case where this is not true.


Kotlin beyond Android: A risk?

Support for a language is dependant on the popularity of that language.  The only possible risk in choosing kotlin is the project becoming an orphan as kotlin never gains sufficient traction in the relevant space.  Choosing any language on the assumption that popularity will increase is a gamble,  so understanding the popularity of kotlin now and are the prospects for future popularity is essential in understanding the risk of future kotlin support.

Depending on the language popularity indicator you reference, kotlin is either climbing the rankings or already very near to top.  Kotlin on Android is widely tipped to overtake Java as the number 1 language, and choosing the number 1 language cannot really be considered a risk.  Could choosing Kotlin for development other than Android still be considered a risk, given the positive signs for kotlin uptake?

Continue reading “Kotlin beyond Android: A risk?”

When will your project ‘grow up’ and require typesafe code?

originalThere is common belief that after an initial very agile development period,  “grown up projects should switch to a static typed language”.  This also raises the question, “are type-safe languages less suitable for early stage development?”  This page considers the evidence for these beliefs, plus considers if there is a benefit to starting dynamic and switching to static, what is the crossover point?

TL;DR? As usual, read the headings and choose only read beyond the heading when you choose.  But in summary, modern statically typed language, and specifically kotlin, are bringing forward the point where adoption is logical, to the point it can now be argued that any project that justifies its own repository, would benefit from starting out as a kotlin project. Continue reading “When will your project ‘grow up’ and require typesafe code?”

Classes, Objects and Instances

Topics for this page:


Python, Kotlin or Java, which best supports Object Oriented Programming (OOP)?


Simula 67 (in 1967) was probably the first Object Oriented Language.  It was a great language, but wow was it slow!  And slow even on the massive mainframe computers it lived on.

The origin of C++ was to add the power of Object Oriented Programming to the very efficient language C, while still delivering real performance. In first reference book on C++ was released in 1985 (tired of waiting for everyone to have access to the internet?) at a time when micro-computers were popular, but far slower than even old mainframe computers.  The result was a language with great control over how objects were created, but in reality necessarily severely compromised by the features to deliver performance.

Java began life as Oak in 1991, but was only used by the original team until 1995 and then had a very short gestation to reaching 1.0 in 1996.  Java delivered greater ease of Object Oriented Programming than C++, and with good performance even with the added layer of a virtual machine.  While the language is hardly truly Object Oriented throughout,  it struck winning formulae with a balance of Object Oriented and performance.

Python had origins also in 1991, but did not really get public exposure until python 2.0 in the year 2000, and did not get full object orientation until ‘new style classes’ were introduced at the end of 2001. Computing power had moved a long way between 1996 and 2001 (consider the 150Mhz 1995 Pentium pro vs the 1.3Ghz 2000 Pentium 4),  and python was targeting easy of programming over ultimate performance anyway.  As you can guess as a result python was able to be Object Oriented throughout instead of just having an outer veneer of being Object Oriented.  But yes, still slower than Java.

Of course for Kotlin, designed in 2011 and having version 1.0 released in 2016, having Object Oriented structure throughout and adding features for functional programming as well was not even really a challenge. But slower than Java? Sometimes, but a 2016 technology compiler that ran run in a 2016 computer with gigabytes of memory available (windows 3.1, the common version at the time of Java release, required 1MB of Ram!) can optimise and produce almost the same code.  Oh yes, the compiler is slower than a Java compiler can be, but is it a problem?

OOP Myths.

But Java has created some OOP myths with almost a generation of programmers learning OOP on Java.

“This program cannot be True OOP, where are the getters and setters!”

That encapsulation requires getters and setters is actually true.  That you have to write your own getters and setters just to access and store data is not true.  Both python and kotlin automatically provide getters and setters without the programmer noticing unless the program requires non-standard behaviour from the getters and setters. Java requires the program writes their own getters and setters in order to allow breaking the rules of OO for performance reasons.

True OOP requires and functions and data to be inside a class so every thing is an object!

True OOP does have everything as an object.  Functions, all data types, everything.  For performance reasons Java broke this rule.  Understandable, but breaking the rules of OOP does not make the language more OO.  Functions should be ‘first class functions’ and in java they were not, for performance reasons.  Putting the non-OOP functions inside an object at least gave them an Object Wrapper, and the same applies for Java primitive data types.  Modern OO languages do not need to wrap functions or data in a class because functions and data are always already objects.

defining classes: constructors and init

python vs kotlin Syntax

# syntax is:
class <Name>(<base classes>):
    def __init__(self, <parameter list>):
        # put init code here
#now example 1
class Fred:
    def __init__(self, var1, var2):
       self.var1 = var1
       self.var2 = var3
       self.container = []
#and example 2
class Fred(BaseClass):
    def __init__(self, var1, var2):
       self.var1 = var1
       self.var2 = var3
       self.container = []
           # rest of init here

Hopefully the above python code is self explanatory. Example 2 adds a base class.  I do not deal with multiple inheritance at this time, and will devote a specific page at some future time as for python it gets complex, and for kotlin it requires additional concepts.  Now here is the kotlin ‘imitate python’ equivalent to example 1.

//syntax is:
<optional modifier> class <name>(<default constructor params>): <base>
// example 1a:bad version- to be python like - not best kotlin
class Fred{
    val var1: Int
    val var2: String
    val container: MutableList<Int>

    constructor(var1: Int, var2:String){
        this.var1 = var1
        this.var2 = var2
        this.container = mutableListOf<Int>()
// example 1b: still bad version- to be python like again- not best kotlin
//  move 'constructor' to class definition, now contructor body is 'init'
class Fred constructor(var1: Int, var2:String){
    val var1: Int
    val var2: String
    val container: MutableList<Int>

        this.var1 = var1
        this.var2 = var2
        this.container = mutableListOf<Int>()

// example 1c:better - 'constructor' keyword omitted and defines variables
// in the primary constructor
class Fred(val var1: Int, val var2: String){
    val container: MutableList<Int>

        container = mutableListOf<Int>()

First the ‘not the best kotlin way’ examples. Is constructor or init the best equivalent python __init__? The first example keeps the class definition more similar to python, and uses a constructor to perform the role of the python __init__. In kotlin, a class can have multiple different constructors to enable constructing an object from different types. So there could be another constructor accepting String in place of Int for the parameters.

But where the python code simply assigns to self.var1 without first declaring var1, in kotlin all variables must be declared, so example aside from the declarations of the three instance variables (var1, var2 and container) and constructor in place of __init__, 1a above looks almost directly like the python version. However, in this form, there is more code than the python version.

Version 1b above moves the constructor(var1: Int, var2:String to the class declaration. Doing this makes this the default constructor for the class, but the body of the constructor method cannot be on this line declaring the class so the body of the constructor is now called init, and the class declaration reads: class Fred constructor(var1: Int, var2:String).
init is the special reserved word to identify the block of code which is the body of the default constructor.

So example 1b is very similar to example 1a, but introduces the concept of a default constructor and the init block.

Example 1c introduces some improvement. A common pattern is that values to the constructor (__init__) as saved as instance variables. Simply adding var or val in the constructor means the parameter is the declaration, plus this result in the constructor automatically saving the values passed in. So we lose 4 lines of code as unnecessary (two declarations, plus 2 assignments). We can also omit the word ‘constructor’ for the primary constructor except for some rare special cases. So now the code is almost as brief as the python code. But there are still optimisations to come.

// example 1d:best
class Fred(val var1: Int, val var2: String){
    val container = mutableListOf<Int>()
// example 2
class Fred(val var1: Int, val var2: String):BaseClass(Var1){
    val container = mutableListOf<Int>()

So for example 1d, the code is now more concise than python, despite the declaration of variables. Yes, container does now look like a python class variable, but this is how instance variables are in kotlin. So the code is brief with types, and perhaps more so than the code without types. This is because the remaining code in the kotlin constructor prior to this step, initialisation of container, can happen at the declaration of container. So no Normally, all code needed in a constructor is setting initial values, so normally no init block is needed as initial values at the definition, either automatically in the case of default constructor parameters, or at the definition in the main block of other instance variables.

Example 2 covers a class with a base class, just for completeness, to have the syntax covered.

instance vs class variables

Consider the following python code:

class Person:
    age = 21

    def __init__(self, name):
       self.name = name
       self.otherName = ""
       self.fullName = name

name, otherName and fullname are instances variable or properties, which means for each Person there is a new copy of each variable. Without a person object, there is no name, otherName or fullName. But age is a class variable, so it exists exactly once, even if there are no Person instances, and regardless of how many person instances.

>>> p1= Person("Fred")
>>> p2= Person("Tom")
>>> p1.age  # access class variable just like instance variable
>> p2.age  # same value both times
>>> Person.age = 22 # change value in class
>>> p1.age # and p1.age automatically has the new value
>>> p2.age # and so does p2.age
>>> p2.age = 19 # set p2.age creates an instance variable
>>> p1.age # p1 is still using the class so unchanged
>>> p2.age # but p2.age shows the instance, which hides the class variable
>>> del p2.age // now delete the instance variable
>>> p2.age  // but the class is still there

The above code plays with how instance variables in python can have the same name as class variables, but hide the class variable.

Now to kotlin. As we saw in class definition, instance variables in kotlin are defined in the way closer to how class variables are defined in python.

Code which appears in the class definition and defines and sets the value of a variable, is actually run every time an object of the class is instanced. This is very useful, because it makes the most common case the one that is simpler, while with python the simpler code is the class variable, and they are less common.

With kotlin there is no automatic class object at run time, with information on class methods and properties held internal to the compiler. To have an object at run time to hold information for the class information for runtime including class variables, kotlin classes have a ‘companion object’. So the reverse of python, kotlin instance variables are declaring at the class level, and class variables are declared inside a container, the companion object container.

The kotlin companion object is the parallel of the class object in python. Any methods or variables in the companion object will be class based and exist once per class, regardless of whether there are zero or more instances of that class.

Most access to class based data will happen from inside the class, but if you do wish to access class based data from outside the class, you do need a ‘getter’ and/or a setter, which are not normally needed in kotlin, but this is an unusual case, and for completeness it is covered here.

class Person(val name:String) {  // instance variable declared in constructor

    var otherName = "" // an instance variable not from a parameter
    var fullName = name //instance variable manually set from parameter

    companion object {
       var age = 21  // class variable age

    var staticAge get()= age   // instance property as getter and
        set(value){age = value}   // setter for age - see properties

The staticAge is needed for the example, but most often access to get or set a class variable like age will happen from within the class, so no staticAge would be needed.

p1 = Person("Fred")
p2 = Person("Tom")
p1.staticAge  // access class variable like instance only within class
p2.staticAge  // use instance with getter from outside class
Person.age = 22 // change value in class
p1.staticAge // and p1.age automatically has the new value
p2.staticAge // and so does p2.age
// cannot create instance value at runtime
// no workable equivalent to python class and instance with same name

The main point is that while defining a variable in the class scope in python creates a class variable, in kotlin creating at this scope creates normal instance variables (or properties).  Class variables (also know as static class variables) in kotlin are created within the companion object for the class, which is a single object as a container for the class, rather than each instance of the class.

self vs this

Access to variables of an object from outside the code of class definition (as in the previous example), is the same for python and kotlin. The code p1.name will access the name variable from the object p1.   Code inside the class must work without any actual object name, so another naming system is needed.  The naming for python is self to indicate the current object, and for kotlin this to indicate the current object.  But the python self is needed far more often than the kotlin this, so in python self.name for the object variable or property, and this.name in kotlin, but in kotlin the this. is only needed when there is a parameter or local with the same name, and normally the this. can be omitted.   So a lot less this in kotlin than self in python.

Again, in python the first parameter to each method in a class should be self, this is not included in the parameter list in kotlin.  Again, less this than self.

# consider in method defintion
    def setNames(self, name): # self as first parameter
       self.name = name
       self.otherName = ""
       self.fullName = name # use name as fullname
//method definition in kotlin
   fun setNames(name): // no 'this' in parameter list
       this.name = name // 'this.name' is property, 'name' is parameter
       otherName = "" // only one 'otherName', so do not need 'this.'
       fullName = "" // also only one 'fullName'

properties: getters and setters

Traditionally, java programmers have been taught that encapsulation (a key part of OO) requires building a class so that how things work can be changed without affecting code using the class. To do this ‘getters’ and ‘setters’ are required, to provide for changes to how data inside the class is used. Instead of allowing a variable to be accessed or set from outside the class, a getter method is created to get the value, and a setter method to set the value. The idea is functions already there in place ready for a possible time when getting or setting is to be become more complex.
Modern languages have identified problems with this approach:
almost all getters and setters just get or set the value and do nothing else so they just bloat the program
it is much clearer for the calling code to get the value of a variable or have an assignment statement to set the value – even when what is happening inside the class is more complex

The solution is:
require code only for the complex cases
ensure setting and getting from outside the class looks the same for simple and complex and is most readable.

Consider this python class:

class Person:
    def __init__(self, name):
       self.name = name
       self.otherName = ""
       self.fullName = name

>>> tom = Person("Tom")  #instance object
>>> tom.fullName = "Tom Jones" # set property using object
>>> tom.fullName  # get property
'Tom Jones'

getting and setting is as simple as possible when using the class, but what if we do wish to ‘complicate’ the fullName property changing the value from being simply its own data, to being the result of name together with otherNames?

class Person:

    def __init__(self, name):
       self.name = name
       self.otherName = ""

    def fullName(self):
	    return " ".join([self.name,self.otherName])
    def fullName(self,value):
	    if " " in value:
	        self.name,self.otherName = value.split(" ",1)
	        self.name = value
	        self.otherName = ""
>>> bob = Person("Bob")
>>> bob.otherName = "Jones"
>>> bob.fullName
'Bob Jones'
>>> bob.fullName = "Bobby Smith"
>>> bob.name
>>> bob.fullName
'Bobby Smith'
>>> bob.otherName

Now we have the new implementation, and all code written before the change will still work.

class Person(var name:String) {  // instance variable declared in constructor

    var otherName = "" // an instance variable not from a parameter
    var fullName
        get()= listOf(name,otherName).joinToString(" ")
        set(value) {
            val (first,second) =
                    if(' ' in value) value.split(" " ,limit=2)
                    else listOf(value,"")
            name = first
            otherName = second

The kotlin code for having getters and setters is less changed by adding getters and setters. Simply follow the variable (or value) property declaration with the get and/or set methods.


What is not covered?
Super, which I feel needs no explanation, and
Delegated properties and more complex cases with does need more. I will add a separate page on these but for now see this page, and delegated properties are described here.

Extension functions will also be covered separately.


binaryEnum is an abbreviation for enumerated.  The overall concept is processing information where each value is one of a very limited set of values.  This is a look from the basics to the more advanced in how a dynamic language like python treats enum, through the advanced treatment available in kotlin.

TLDR; Just read the headings until you find sections of interest.

Ascii characters are one of 127 possible characters (although now we use larger character sets), and the original ‘integer’ values were 0,1,2, …. 65,535,  but what about when you have your own finite set of possibilities, like expressing location as ‘at home’, ‘at work’ or simply ‘elsewhere’? Enter, the Enum.


With Digital Data Everything is a number.

In digital computers, every value becomes a number.  Some values, for example a speed, or a length measurement, just are numbers already so to store the value as a number is obvious.  In fact at the simplest level, we have to types of data: integers and floats which are numbers.

Strings: All data can be a string.

But what about all the things that are not normally numbers? Since we use a language based on characters, any value we like can reduced to a string of characters, and as there are established ways of transforming each character into a number for storage in a computer, we could simply store each item as a string of characters.  We call this the string type.  We can store anything, regardless of whether the characters happen to be number or not, so we could even store our numbers as strings.   The string is effectively the common representation we can use for all types of data.  In a sense, all other types are subsets of the possible strings. Integers are subsets where only numeric characters are allowed.  Simplistically, the syntax of float like an integer with the addition of a single “.” character. Both integer and float are just subsets of the valid strings.  In fact you could design a language where string is the only type.

Why not keep everything as a string?

There are advantages not simply treating all data as a string. An integer or float is not just a string restricted to numeric characters, there are also special operations that can only be done with numbers, and special relationships between numbers.  These special subsets has their own rules which only apply to these subsets of possible strings.  For any given length of number, there also less possible alternatives than there are with strings. In the UTF-8 character set,  there are 1,112,064 possible values for each character.  In an integer, there are 10 possibilities for each character.  This allows for far more efficient storage of as an entry within the possible integers, than keeping them as string format which means keeping them as one of the far greater number of possible strings.  The less possible values, the more efficient the storage.  Actually keeping numbers in such a format also simply works with the fact that computers are by nature digital, so they are most efficient with numbers.

So now we have integer, float and string, and again, this would be sufficient, but there are advantages to even more types.

Boolean: The simplest ‘Enum’.

If you are reading this, it can be assumed you understand Boolean, but reviewing the basics is still worthwhile.  Boolean is a type where the values are not characters and not numbers, and therefore fits the classic definition of an Enum type: data with a limited number of possible values that we can ‘enumerate’. For Boolean, there are just two possible values: false and true.

Anything with a fixed number of choices fits the pattern on an enum.  Think of any data you fill out on a form where the answer is one of a fixed set of choices, such as gender: male/female/not-saying, or Title: Mr/Mrs/Dr/Prof/Miss/Ms  or even agreement: strongly-agree/agree/unsure/disagree/strongly-disagree.

Each of the possible choices could be represented as a number, for example:

#  etc.......

The value for title could be kept in an integer.  In fact a language could do the same with Boolean, and simply have false=0 and true=1 would cover most requirements.  So technically, no Enum values are needed at all.  Just as we could not even bother with the constants and just remember that title of Mrs is number 2.  But having enums which specifically declare what the possible values are makes the code intent far clearer, and the code more easily scanner by a language or a reader for errors.


Enums have been added to Python 3.4 as described in PEP 435. It has also been backported to 3.3, 3.2, 3.1, 2.7, 2.6, 2.5, and 2.4 on pypi.

Prior to the introduction of Enum in the language officially, code could use constants for the alternate values as described in background, or made use of a class implement enums.   In fact libraries for Enum were sufficiently widely in use that these were the basis for Enum as added to the python language.

Enum in Python

There is a very simple format for declaring an enum:

>>> from enum import Enum
>>> Title = Enum("Title", "Mr Mrs Dr") # create type for title
>>> from enum import Enum # do import
>>> title= Title(2) #instance using value
>>> title
<Title.Mrs: 2>
>>> title2=Title["Dr"] # instance using name
>>> title2
<Title.Dr: 3>
>>> title.name # the attributes of 'title'
>>> title.value

This example shows creating and using an Enum by specifying the names each alternative within the Enum.  In python, each alternative also has a value, and with this format, values for each alternative are assigned automatically, in a sequence starting with 1, so this case uses the values 1, 2 and 3.

Why start at one and not zero? Because in python the number zero can also be considered false, and the design is for every value by default to be true.

An alternative form allows choosing values as well as names.

>>> class Title(Enum):
Mrs = 2
Dr = 5
>>> title = Title(0)
>>> title
<Title.Mr: 0>
>>> title2 = Title["Dr"]
>>> title2.name
>>> title2.value

Note: this does allow starting at zero if you wish, and there are problems as a result
This alternative form can also work with automatic values:

>> from enum import Enum, auto
>>> class Title(Enum):
Mr = auto()
Mrs = auto() # using all automatic values
Dr = auto()
>> title2 = Title.Dr # same value as Title["Dr"]
>>> title2
<Title.Dr: 3>
>>> class Title(Enum):
Mr = auto()
Mrs = 5 # choose value # can mix auto() with other values
Dr = auto() # value will follow from previous chosen
>>> title2 = Title.Dr
>>> title2
<Title.Dr: 6>

In all these example, the value has been integer, but value can be anything: a float, a string, None, True or False and even a mutable list or a user created class. Auto() still works mixed with any other values, but ignores any non-numeric so

Mr = auto()
Mrs = None # Could be True or even [1,2,3]
Dr = auto()
#  will have values 1, None, 2

This has provided a simple review of enums in python, and illustrated the general concept. See the official python documentation for more details. Note that some cases provided by python are oriented to supporting implementations made before Enum was added to the language.

Enum in Kotlin

enum class Title{
val title = Title.Mrs
println("$title  ${title.ordinal} ${title.name}")

This is almost an exact match for the python ‘auto()’ allocation of values. The differences are about ordinal vs value. Firstly, the name is different (ordinal vs value), and ordinal and starts from the more usual zero, not one, kotlin does not need to avoid the clash with python ‘Boolean safety’.

But the biggest difference is that ordinal is fixed. Like the indexes of an array, it must be the sequence of integers from zero … eg 0,1,2 …. It cannot be of another type, nor any other integers.

However, with kotlin, unlike the value in python, ordinal is not the only attribute beyond the name: you can add whatever extra fields you wish by adding them to the enum class.

enum class Title(val value:Int){

This does not provide an exact equivalent for value in python as there is no inbuilt method to find the Enum from the value as here:

>>> class Title(Enum):
Mrs = 2
Dr = 5
>>> title = Title(0)
>>> title
<Title.Mr: 0>

This does not allow ‘value’ to vary in type between class members either, but that could be done in this manner (although it is difficult to see the use):

enum class Title{
    Mr() {val value = 2},
    Mrs() { val value = "abc" }

Although this can be done, creating value this way results in reflection being needed to access value, so this is not practical. To have different properties, object should have different classes, so enter sealed classes.

Generally, the Kotlin Enum is an effective replacement for the python Enum. Where it gets interesting, is that in kotlin it does not stop there.

Beyond Enum: Sealed Classes

So far our example has been ‘Title‘, and just keeping it breif dictates that the examples have not even attempted to cover all possibilities. While any reasonable list would of course include Ms and Miss, what about Dame, Madam, Duchess, Duke or Sir?  In Italy Engineer is actually a title so we need to add Eng.  Could we ever be sure to cover every title a person might consider as their appropriate title?  One solution is to simply have people tick “other”.  A problem is that simply recording “other” is almost the same as having no data.  While adding a “please specify” may feel better, without actually recording what is specified, this is almost misleading.

Neither a python Enum,  nor a kotlin Enum, can handle the “other” case.  Every value in an enum is effectively mapped to a number.  Why not add a “specify” property?  Because it does not achieve the goal.  If we have four possible values “Mr/Mrs/Dr/Other” these could be mapped to 1,2,3,4 for storage.  Each choice is just one value.  Every time “Other” is recorded it is exacly the same, including any properties of other, so there is only one value “specify”.  To have additional values for specify we need a new entries in our list in the Enum defintition.  Something like “Mr/Mrs/Dr/Other1(“Miss”)/Other2(“Ms”) ….. in other words we still need to state every possible value of all properties at the time the Enum is declared.

Now consider, having a custom type (and a type is really a class) for each possible value.  So we have a Mr class and a Mrs class, and a Dr class and a Other class.   Then we can have the possible values for our enum as the classes.  Our Enum is no longer constrained (in this example) to four(4) specific values for Mr/Mrs/Dr/Other, but instead to 4 specific classes, and each class can have any number of different objects of that class.  While in a standard Enum type, if there are four possible values then variables of that type could be stored as a number between 1 and 4 (or 0 to 3), with a sealed class with four possible types, the reference to object matching one of the four classes is required, not just a number indicating which class is matched.   Despite this significant difference in how things work internally, the code can look very similar. This sample is attempting to look as similar as
possible to the enum example, but needs adjustment before being useful.

sealed class Title {  // no class parameter required
    object mr   // each entry can be an object definition or class definition
    object mrs  // note this sample shows entries with no base class ...
    object dr   // ... which valid syntax but not very useful
    class Other(val text:String)  // introduction of class member of 'enum'

The above example is difficult to use as the alternative values have no common
class so a different variable type is required for each value.

The example below fixes is not just valid syntax, but provides the recommended structure.

sealed class Title(val value:Int) {  // value to match previous enum examples
    object mr: Title(0)   // each object or class based on sealed class
    object mrs: Title(1)  // which gives a common base class
    class Dr: Title(2)   // entries matching the enum patter can be class or object
    // but entries making use of the power of sealed classes must be a class
    class Other(val text:String): Title(5)

In kotlin, object declares a singleton class where there is only ever a single instance of the object.  This means there will only ever be one instance of mr which is referenced everywhere, which is similar to the way Enum is implemented.
Both mr and mrs could also be implemented as classes, but since there is no data at all in objects of these classes, every instance of Dr (or a Mr or Mrs class) would be identical and therefore could be references to the same instance.   But the goal of using sealed classes is to provide for classes which do have data so every instance has the potential to be different.

Another example of sealed classes can be found here, with the code here.  Plus the official kotlin information could also be useful.

If there are questions, add a comment and I will attempt to address them.