Warning alert:We're building our new website - with more examples, tips and docs! Some sections though might still be incomplete or under review. When browsing, keep an eye for progress notes and ways to get updated on particular topics.

Developing with Python

Initializing the Client

Import and create a new instance of Mishmash:

from mishmash import Mishmash
mishmash = Mishmash()

Be sure to check that the lib can find the config in your operating environment.

The mishmash variable now holds the 'mishmash of all data' for the given application. Everything stored in mishmash io is now accessible through that variable.

What is a mishmash of data?

A 'mishmash' is a special type of object that represents all or parts of the application data. It is, usually, a container, a collection, a list (a collection that has order) or a set (a collection where operators like 'union', 'intersection', etc can be applied).

A mishmash can also represent a single Number, bool, string or other type of value.

We call it a 'mishmash' because it just 'holds' data structures of arbitrary complexity, such as objects, lists, etc. For example, as part of a video streaming service, a mishmash can simultaneously contain user profiles, lists of their videos, posts, comments and so on. In other words - they 'hold' all the input that is needed for a particular application code to operate on.

It's the responsibility of this application code to properly interpret each element and its meaning for the application, other objects in its context, and so on. With this in mind, mishmashes give the developer an easy way, with little coding required - to describe an input and apply complex logic on it.

What a mishmash is not

A 'mishmash' is not a table, has no rows, no columns, no cells. It has no specific data format, schema or structure on its own.

It is simply a persistent store of application variables.

Using mishmashes

A mishmash can be 'built' from literals, variables, code and other mishmashes. It can be assigned values and data; it can be deleted, updated, added to and deleted from. Code can be applied to mishmashes too.

Mishmash objects are basically descriptors of data and not the actual data. Operations (accessing, indexing, 'union', etc) applied on a mishmash usually return another mishmash (another descriptor), and do not transfer data. This is called 'building a mishmash' - building the descriptor for data that will be needed by some application code later.

Fetching data or results actually happens only when specifically requested (usually by the interpreter), for example when a value is needed for a local computation, or an iteration over the mishmash is requested in local code. These are often referred to as 'terminal operations' - building stops and transferring of data begins. There is more about terminal operations (and local versus remote code) below.

Mutating the data (for example - storing new data, deleting existing data, etc) is done through assignments, additions, etc., to a mishmash that has been previously built.

Building a mishmash

All mishmashes are built from existing mishmashes or from the 'mishmash of all data' (shown at the beginning of this section). As any building operation on a mishmash always returns a new mishmash, you can build one in several steps, iteratively or directly.

Three major rules apply to all building operations on a given mishmash:

  1. Naming (or indexing) makes a narrower, more specific mishmash, e.g. when 'naming' videos on the user mishmash, like in user.videos, the returned mishmash is more specific as it now 'holds' the videos objects only. Similarly, the mishmash user.videos[3] is even more specific.
  2. Enumerating (or listing) produces a broader mishmash; for example user['video', 'music'] will return a mishmash of all music and videos. Enumerating is usually done by the commas (',') in your code.
  3. Applying code, by specifying a lambda, or a function or method, performs the action specified in the code on the mishmash that it is applied to. And it does that remotely on the mishmash io cluster (see below for more about 'local code' and 'remote code').

These three rules can be mixed, combined and nested many times:

my_mishmash[today, {'age': age_range[18:], 'department': 'software development'}][check_for_birthdays](throw_party)

Important: All three operations are done either as function call arguments - my_mishmash(<operations>) - or as item access (a bracket notation) - my_mishmash[<operations>]. Naming can also be done by accessing a local attribute (a dot notation) on a mishmash - my_mishmash.videos.

Naming and indexing

Accessing an attribute of an object by its name (or identifier) returns one of the specific values contained in that object, just as accessing the element of a list located at a given index returns that one value among all others in the list. In the same way, 'naming' or 'indexing' a mishmash returns a mishmash that is describing a more specific subset of the initial data.

In Python, this is done by using:

  • dot notation, like

  • single int, float, bool, None, etc or other simple type

  • date, datetime and similar;

  • str or unicode

  • bytes, bytearray, memoryview

Or by using types that naturally contain names:

  • namedtuple

  • mapping objects, like dict

    {'age': 42, 'department': 'software development'}
    dict('age': 42, 'department': 'software development')
  • function call arguments with names


And some of the sequence types that are often used as list indexes:

  • range
  • slice

Finally, objects of other complex classes:

  • another mishmash
  • user-defined classes (see below how these are treated)
  • Python code - 'Callables' - lambdas, functions, methods, generators, etc. (see below)


A 'broader' mishmash, one that combines many 'deeper' mishmashes together into a whole, is created by enumerating multiple items, or in other words - by supplying sequences or collections with no specific naming, mapping or other association between items.

The simplest ways to create broader mishmashes in Python are:

  • multiple function call arguments

    my_mishmash('age', 'software development', my_other_mishmash)
  • list or tuple

    my_mishmash[('software development', 'quality assurance')]
  • set

    my_mishmash({'software_development', 'quality assurance'})
  • other, user-defined iterable classes (see below how user-defined classes are handled)

Note: Callable code - like generators for example - are not considered as 'enumerating' parameters, they're handled as code, transferred to the cluster and optimized. This is because executable code can be doing much more than just enumerating. For this reason, it's considered on its own. (See below)

Adding code

More ways to build a mishmash

Set operators

Mutating a mishmash

Computing with a mishmash

Computing locally

Computing remotely


Custom classes

Serializing a mishmash for storage or transfer

© 2024, Mishmash I O UK Ltd. or its affiliates. All rights reserved. | Privacy Policy | Cookies