Live Chat

We'll need to share your messages (and your email address if you're logged in) with our live chat provider, Drift. Here's their privacy policy.

If you don't want to do this, you can email us instead at

Blog - Page 5

Anvil News - July
24th of July 2018

It was great meeting everyone at EuroPython! Next up: PyCon UK in Cardiff. Join us there, where we’ll be showing everyone how to build full-stack web apps with nothing but Python!

Meanwhile, here’s what’s new this month:

1. Single Sign-On with Microsoft

Does your organisation use Office 365? Now your users can log into your apps with their Microsoft accounts! Microsoft login (or, to give it its official name, Azure Active Directory) is available for all our Business plan customers.

Click here to read more.

2. Building Email-Driven Apps with Anvil

We’ve already made it easy to build web-based apps. Now it’s just as easy to send and receive email from your code, with our new Email Service.

Check out the code samples, or watch our demo video to see me build an email-receiving app in just a couple of minutes.

3. New Documentation Search

We’ve made it easier than ever to search the Anvil documentation. Next time you’re in the Anvil editor, check out the search box in the toolbar. You can search our tutorials, reference documentation, and selected posts from the Community Forum.

(Speaking of the Community Forum, we’d love to hear your feedback. Come join us there!)

4. Other updates

As always, we’re improving Anvil all the time. Here are a few highlights:

  • Validating user input just got a lot easier, with our new form validation library. Check it out!

  • We’ve introduced a new domain for your apps: Now, by default, your apps are available at <something> (Don’t worry, the old <something> links still work!)

  • We had an idea for improving the saving mechanism, so if you’re on a flaky internet connection saving should feel instant.

Happy building!


Building Email-Driven Apps
18th of July 2018

Sending and responding to email in code

Email is the most popular messaging platform on Earth. We use email to arrange events, to exchange files, and to notify each other when something happens.

You should be able to email your applications too. But to receive email, you need to set up a server somewhere, run an SMTP daemon, and somehow connect that to your code.

We’re here to fix that. Today, we’re delighted to show you the easiest way to build email-driven apps. All you need to do is write a Python function. For example, here’s all the code you need to receive emails and store them in a database:
def incoming_email(msg):
  msg.reply(text="Thank you for your message.")

Sending is just as simple:
  subject="New message",
  text="This is awesome",
  html="This is <b>awesome</b>"

Despite its simplicity, it’s also fully featured - you can handle attachments, recipients, and even use DKIM to check that a message is genuine before trusting what it says.


You can scroll down for a cookbook of common examples, or watch as I build a full disposable-email-address service, and publish it on the web, in four minutes:

Example Snippets Watch video

Video example: Disposable Email

App Source Code
Note: We skim past the UI building pretty fast in that video.
If you want to see how it's done, check out our other tutorials for a slower explanation.

Sample Email Code

Here are a few things you might want to do with email. You can follow along from these code snippets, or view them all in the Anvil editor:

Open Example Code

1. Receiving email and saving it in a database
def incoming_email(msg):

2. Replying to an email you’ve received
def incoming_email(msg):
  msg.reply(text="Thank you for your message.")

3. Sending email

def send_a_message(txt):
    cc=["Someone Else <>"],
    subject="Hello World",
    text="Hi there!"

4. Handling attachments

All attachments are Anvil Media objects. This means you can upload them from web browsers, store them in databases, make them downloadable, and more.

def send_by_email(file):
    subject="New upload",

Incoming attachments are just as straightforward. Here’s how to save all attachments in a database:
def incoming_email(msg):
  for f in msg.attachments:

5. Authenticating senders

Email has historically been easy to spoof. Helpfully, many providers now support DKIM, which lets you verify that the email actually came from the domain it says it did.

The dkim property of the message contains details about all that message’s valid DKIM signatures, and a shortcut to check whether it’s signed by the address in msg.envelope.from_address:
def incoming_email(msg):
  if msg.envelope.from_address == ''
      and msg.dkim.valid_from_sender:
    msg.reply(text="You're the real deal!")

There’s a shorthand, if you only want to accept DKIM-authenticated messages (and reject all others):
def incoming_email(msg):
  if msg.envelope.from_address == '':
    msg.reply(text="You're the real deal!")

6. Rejecting (“bouncing”) messages
def incoming_email(msg):
Try it yourself

Start writing email-driven apps for free with Anvil:

Try it now

You can also read more about the Email service in the Anvil reference docs.

Anvil News - May
9th of May 2018

It’s been another monster month for us.

It was great meeting everyone at PyCon, and the crowds around our table were awesome! Check out my 5-minute talk from the conference: Making the Web More Pythonic

As always, we’re improving Anvil all the time. Here are a few things you might have missed:

1. Beautiful apps: New Material Design theme

We’ve published a new Material Design theme! We’ve given our components a facelift and added swappable colour schemes, so it’s now even easier to build beautiful apps.

(Don’t worry, the old theme is still there - it’s now called “Classic”.)

2. Simple objects in Data Tables

If you want to store richer data, you can now add “Simple Object” columns to your Data Tables. These can store strings, numbers, lists, or dicts - that’s any JSON object. And you can search inside them with a powerful query system.

Find out more on our blog:

3. Looking after the details

Here are some things we’ve done this month to make Anvil even more pleasing to use:

  • Easier code navigation - you can hold down the Ctrl key and click on a function or variable to jump to its definition.

  • The new FlowPanel lets you lay out components side-to-side. It’s great for grouping buttons, links or labels right next to each other.

  • We’ve made it easier to drag and drop Link components, so it’s clearer whether you’re dropping something next to a Link or inside it. (I love this when I’m building sidebars for navigation!)

  • More options for displaying images in Image components: Shrink to fit, zoom to fill, or display your image at its original size no matter how big your page is.

  • Want your components closer together, or further apart? Now you can control the spacing in a ColumnPanel with the column_spacing property.

  • We’ve made the Toolbox easier to navigate by highlighting the most commonly used components.

  • Fixed-width layouts are easier now too, with the XYPanel. Most of the time, you won’t be needing a fixed-width layout, but when you do, it’s right there.

Happy building!


Making the Web More Pythonic
15th of May, 2018

The Web is not Pythonic. Can we improve that?

The Web is traditionally a pain to program. It's also seriously un-Pythonic.

At PyCon 2018, I asked: Can we make Web programming easier, by making it more Python-shaped?

Scroll down for transcript
Anvil logo
For more information about Anvil, check out

The Web, I assert, is seriously un-Pythonic. It's also famously a pain to program for. Are these two things related? Could we make the Web a nicer place to program, by making it more Pythonic?

Well, to start with, what do I mean by "the web is un-Pythonic"?

Think about a typical web app. You're going to have to turn your data into a bunch of different shapes along the way:

  1. Your data exists as rows in a database, accessed via SQL.
  2. You then transform it into model objects on the server, with methods and attributes to interact with them.
  3. Now, you have to represent these objects as JSON, and provide a whole bunch of REST endpoints for getting or manipulating them.
  4. On the client, you then transform these HTTP requests into Javascript objects, which have methods of their own.
  5. And then you have to transform these client objects into HTML DOM...
  6. ...and style that to produce pixels on a screen.


At each of these boundaries, a bunch of boring and repetitive translation work happens. And that is an invitation to exactly the wrong sort of magic.

Let's take an entirely unfair pot-shot at SQLAlchemy, which is a library that manages the transformation of an SQL database into Python objects (and back). It's actually really good at it. You can even write neat query expressions like this: filter(Book.value<20).

Of course, the process of turning that Python expression into SQL is black magic. It involves metaclasses, and overloading standard Python operators to do something completely different to what they normally do.

And that's cool, if you do it once. But if you have this amount of magic at every boundary in this stack, you're setting yourself up for a bad time.

But of course, that's exactly what we do:

  • We have ORMs to translate databases into objects;
  • We have REST frameworks to help us represent objects as JSON;
  • We have JS frameworks (like Angular's resources) to help us turn patterns of HTTP requests into Javascript objects;
  • We have templating engines to represent JS objects as HTML DOM;
  • And we have CSS frameworks to help us display this DOM as the right pixels.

And they're all extremely leaky abstractions! To be a reasonably advanced user of any of these frameworks, you need to understand everything they do, on both sides of the transformation.

Aside: This is a leading cause of the "Framework of the Week" anti-pattern. You have a tool which is inherently unsatisfactory, because it's spanning one or more of these transitions and suffers from all these impedance mismatches. And just in order to use this tool, you need to know more or less everything you need to build one yourself. This presents an irresistible temptation. But of course the new one still isn't quite right...and around and around we go.

So, how does this situation stack up against The Zen of Python?

"There should be one obvious way to do it"?

Hoo, boy. Look at all these frameworks!

"Explicit is better than implicit"?

Transforming data implicitly is these frameworks' job.

"If you can't explain the implementation, it's a bad idea"?

Again, look at the sheer amount of magic in every level of this stack!

So, what might something more Pythonic look like?

At Anvil, we start by putting Python everywhere — even in the browser. (We use the Skulpt Python-to-Javascript compiler; check out my previous talk about it.)

OK, so if we're in Python, and making an HTTP request to a Python server, what happens?

Well, we make a function call into the requests library, and then some time later it emerges as a function call to a Flask endpoint.

Wait a second. If a function call was all we wanted, why not explicitly turn the whole thing into function calls?

So that's what we do. Have a function on the server, decorate it with @anvil.server.callable, and call it from the client with a function call.

Now we can pass arguments (even keyword arguments), and return values from the function. We don't have to marshal everything into an HTTP request any more — it's just a Python function call.

(The data still passes over HTTP, of course. Actually, we use an encrypted WebSocket.)

OK, so the next question is, "What sorts of data should you be able to pass into, or return out of, these functions?"

Well, strings, numbers, dicts, and lists are easy. That's just JSON. But we want to avoid translations, so we want to pass proper objects from the server to the client.

Unfortunately, this is a web server, serving lots of clients, so it has to be stateless: the server just can't afford to keep these objects in RAM.

So we support passing a special sort of object: a stateless server object.

What's in a stateless object? Well, it has an immutable ID, some method names, and some permissions. That's all. (So there's nothing else the server has to remember.)

We can call methods on this object from the client: it's just a server function call, like we saw on the last slide. We make sure the client can't call methods on arbitrary objects by signing the ID and permissions, and requiring that signature to call a method on an object. So the client can only call methods on an object that has been returned from a server function.

An excellent use case for this is...database rows! The object's ID is the unique ID of that row in the database; the methods are things like update() and delete(). And by implementing __getitem__() and __setitem__(), we can even use square-bracket lookup to get and set column values.

If we put this together, we can:

  • Make a simple function call to the server,
  • Look up a database row,
  • Return that row to the client as a Python object,
  • ...and use the values from that row in client code.

We've skipped a whole bunch of these translation steps! We've got one object, passed all the way from the database to client code.

And that's a little contribution to making the Web more Pythonic.

For more about Anvil, check out

Thank you very much.

Simple Object Storage
3rd of May 2018

New: Store richer data in Data Tables

Do you find yourself wanting to store more than just strings, numbers and dates in your tables? Perhaps you have complex records with dynamic fields, or perhaps you want to store lists of data without making a whole new table.

Today, we’re introducing a new type of column: the Simple Object. It can store lists, dicts, numbers, strings and (of course) None. (If you’re familiar with JSON, you’ll know this is another way of saying “any JSON value”.)

Add a Simple Object column to your table like this:

Creating a Simple Object column

Now you can store structured data in a single row of your table:

    name = "Kermit the Frog",
    contact_details = {
      'phone': [
        {'type': 'work',
         'number': '555-555-5555'},
        {'type': 'home',
         'number': '555-123-4567'}

Querying them is just as simple. If you supply an object to the Data Tables search() or get() method, you’ll match every value that contains those values, dictionary keys or list items. Here’s an example:

  def get_person_for_number(phone_number):
    # We have a phone call for this number. Who is it?

    return app_tables.people.get(
        contact_details = {'phone': [{'number': phone_number}]}

You can read more about Simple Object columns in the Data Tables reference docs.

Learn More

Get the best out of Anvil with our free email course.