@udono wrote:

pexels-photo-760971.jpeg1280x753 366 KB

This month was mainly focused on fixing bugs.
But also it is the month where we finally closed the Google Groups in favor of this forum (users can post in there language thanks to translator plugin). We still manage two mailing lists for announces and commits. The former ones are archived.

Contents:

• Changes for users
• Changes for developers

Changes For The User

Some bugs related to the update of chart of account have been fixed. You may need to re-run the wizard to ensure your chart is in sync with the template.

The form view for the invoices and shipments on the sale and purchase form has been removed. Often the user tried to validate or post them from this view which is not always working due to some constraints from the clients design. Indeed the proper way is to open them using the relate feature which provide access to the complete workflow. The list views on the sale and purchase are just there to provide a quick summary.

After 2,5 years, the support for the series 4.0 ended as planned. If you are still using this series or any older, it is highly advise to upgrade to a supported series (the best choice to day is the LTS 5.0).

The “PieceDate” column of the FEC export has been changed for the move date. Before we used the post date but indeed the move date is closer to the definition.

With the removal in series 5.0 of the default accounts on journal, the journal cash report was broken. It was fixed by basing it on the moves of cash journal between receivable/payable and others accounts.

Now, all the tables are correctly responsive in the web client even when they are hidden behind a tab.

Changes For The Developer

An important security issue has been fixed on all supported versions. It allowed an authenticated user to guess value of fields for which he does not have read access.

In order to simplify and to enforce good practice, ModelStorage.read requires to always list the requested fields. Before if no list was provided, it returned the values of all the readable fields.

The documentation on proteus, the scripting library, is now available on proteus — tryton-proteus latest documentation

The cache is now correctly cleaned even when an exception occurs during a test case.

Posts: 1

Participants: 1

Read full topic

What happens when 100% test code coverage just isn't enough.
In this episode, we talk with Mahmoud Hashemi about glom, a very cool project in itself, but a project that needs more coverage than 100%.
This problem affects lots of projects that use higher level programming constructs, like domain specific languages (DSLs), sub languages mini languages, compilers, and db query languages.

Also covered:

• awesome Python applications
• versioning: 0-ver vs calver vs semver

Special Guest: Mahmoud Hashemi.

Sponsored By:

• DigitalOcean: Get started with a free $100 credit toward your first project on DigitalOcean and experience everything the platform has to offer, such as: cloud firewalls, real-time monitoring and alerts, global datacenters, object storage, and the best support anywhere. Claim your credit today at: do.co/testandcode

Support Test and Code - A Podcast about Software Testing, Software Development, and Python

Links:

• Announcing glom— Restructured Data for Python
• Domain-specific language - Wikipedia
• awesome-python-applications— Free software that works great, and also happens to be open-source Python.
• Meld— a visual diff and merge tool targeted at developers.
• ZeroVer: 0-based Versioning
• SemVer: Semantic Versioning
• CalVer: Calendar Versioning
• episode 27: unit, integration, and system testing - Mahmoud Hashemi

The next version of Mu will be 1.1. This post describes how we’re going to get there and what to expect on the way.

The first thing you should know is that 1.1 will have new features including new modes, new capabilities and new ways to configure Mu. Some of the new modes have been kindly written by new contributors. The new capabilities and ways to configure Mu are based upon valuable feedback from folks in the community. Thank you to everyone who has contributed so far.

The second thing you should know is that 1.1 will have many bug fixes. Since Mu 1.0 was released a huge number of people have started to use it and, inevitably, found and reported bugs. Thank you for all the valuable feedback, please keep it coming! We hope to address as many of the problems as possible.

The final thing you should know about is the release schedule for Mu 1.1. Very soon, a version 1.1.0.alpha.1 will be released: this will contain some of the new features and updates and will definitely contain bugs. It will be followed with a number of further alpha releases as new features are created and/or contributed to this version of Mu. When we’re happy we have all the features we want, we’ll release a version 1.1.0.beta.1. The focus of the various beta releases will be to test and fix any bugs we may encounter. However, the beta releases will be “feature complete” and represent a good preview of what version 1.1 will look like. Once there are no more known bugs, or those bugs that remain are “edge cases” that can be documented, we’ll release the final 1.1.0 version which will be available for official download. The old 1.0.* version of Mu will still be on the website, but no longer officially supported.

Such work will touch all aspects of the Mu project: the editor, the associated projects for generating resources for the editor, the documentation and the website too. It will also mean the translations will need to be checked and updated to deal with any UI changes.

Some of you may be contributors waiting for us to merge your work or respond to your suggestions. We promise we will always be respectful and supportive of your efforts. However, we may not accept all contributions. This reminds me of my work as a musician: when auditioning players for a band or orchestra you meet a huge number of talented musicians, but there may only be the need for one flute player. Any number of the musicians who auditioned could have easily played the flute part, but the person who was offered the job was the one who it was felt fitted in with the rest of the orchestra. Likewise, if we don’t merge your contribution, it’s likely that it’s because it either doesn’t quite fit with our vision for Mu, or the capabilities it provides are met in some other preferred way. We will, of course, explain our decisions via discussion on the relevant pull requests. Nevertheless, please don’t be disheartened if we decline your contribution – it’s certainly not a critique of your efforts (which we value hugely).

This is a LOT of work, and we ask you to be patient as we volunteer our time to make the next version of Mu. However, we’re a free software project developed in the open and so we would love to hear your input as work progresses. Wouldn’t it be cool to be able to say, “you see that feature? I suggested that”.

Together, we can collaborate to make Mu a better editor for beginner programmers and those who support them.

A while ago, we've seen how to write a simple filtering syntax tree with Python. The idea was to provide a small abstract syntax tree with an easy to write data structure that would be able to filter a value. Filtering meaning that once evaluated, our AST would return either True or False based on the passed value.

With that, we were able to write small rules like Filter({"eq": 3})(4) that would return False since, well, 4 is not equal to 3.

In this new post, I propose we enhance our filtering ability to support multiple values. The idea is to be able to write something like this:

>>> f = Filter(
  {"and": [
    {"eq": ("foo", 3)},
    {"gt": ("bar", 4)},
   ]
  },
)
>>> f(foo=3, bar=5)
True
>>> f(foo=4, bar=5)
False

The biggest change here is that the binary operators (eq, gt, le, etc.) now support getting two values, and not only one, and that we can pass multiple values to our filter by using keyword arguments.

How should we implement that? Well, we can keep the same data structure we built previously. However, this time we're gonna do the following change:

• The left value of the binary operator will be a string that will be used as the key to access the keyword arguments passed to our Filter.__call__ values.
• The right value of the binary operator will be kept as it is (like before).

We therefore need to change our Filter.build_evaluator to accommodate this as follow:

def build_evaluator(self, tree):
    try:
        operator, nodes = list(tree.items())[0]
    except Exception:
        raise InvalidQuery("Unable to parse tree %s" % tree)
    try:
        op = self.multiple_operators[operator]
    except KeyError:
        try:
            op = self.binary_operators[operator]
        except KeyError:
            raise InvalidQuery("Unknown operator %s" % operator)
        assert len(nodes) == 2 # binary operators take 2 values
        def _op(values):
            return op(values[nodes[0]], nodes[1])
        return _op
    # Iterate over every item in the list of the value linked
    # to the logical operator, and compile it down to its own
    # evaluator.
    elements = [self.build_evaluator(node) for node in nodes]
    return lambda values: op((e(values) for e in elements))

The algorithm is pretty much the same, the tree being browsed recursively.

First, the operator and its arguments (nodes) are extracted.

Then, if the operator takes multiple arguments (such as and and or operators), each node is recursively evaluated and a function is returned evaluating those nodes.
If the operator is a binary operator (such as eq, lt, etc.), it checks that the passed argument list length is 2. Then, it returns a function that will apply the operator (e.g., operator.eq) to values[nodes[0]] and nodes[1]: the former access the arguments (values) passed to the filter's __call__ function while the latter is directly the passed argument.

The full class looks like this:

import operator


class InvalidQuery(Exception):
    pass


class Filter(object):
    binary_operators = {
        u"=": operator.eq,
        u"==": operator.eq,
        u"eq": operator.eq,

        u"<": operator.lt,
        u"lt": operator.lt,

        u">": operator.gt,
        u"gt": operator.gt,

        u"<=": operator.le,
        u"≤": operator.le,
        u"le": operator.le,

        u">=": operator.ge,
        u"≥": operator.ge,
        u"ge": operator.ge,

        u"!=": operator.ne,
        u"≠": operator.ne,
        u"ne": operator.ne,
    }

    multiple_operators = {
        u"or": any,
        u"∨": any,
        u"and": all,
        u"∧": all,
    }

    def __init__(self, tree):
        self._eval = self.build_evaluator(tree)

    def __call__(self, **kwargs):
        return self._eval(kwargs)

    def build_evaluator(self, tree):
        try:
            operator, nodes = list(tree.items())[0]
        except Exception:
            raise InvalidQuery("Unable to parse tree %s" % tree)
        try:
            op = self.multiple_operators[operator]
        except KeyError:
            try:
                op = self.binary_operators[operator]
            except KeyError:
                raise InvalidQuery("Unknown operator %s" % operator)
            assert len(nodes) == 2 # binary operators take 2 values
            def _op(values):
                return op(values[nodes[0]], nodes[1])
            return _op
        # Iterate over every item in the list of the value linked
        # to the logical operator, and compile it down to its own
        # evaluator.
        elements = [self.build_evaluator(node) for node in nodes]
        return lambda values: op((e(values) for e in elements))

We can check that it works by building some filters:

x = Filter({"eq": ("foo", 1)})
assert not x(foo=1, bar=1)

x = Filter({"eq": ("foo", "bar")})
assert not x(foo=1, bar=1)

x = Filter({"or": (
    {"eq": ("foo", "bar")},
    {"eq": ("bar", 1)},
)})
assert x(foo=1, bar=1)

Supporting multiple values is handy as it allows to pass complete dictionaries to the filter, rather than just one value. That enables users to filter more complex objects.

Sub-dictionary support

It's also possible to support deeper data structure, like a dictionary of dictionary. By replacing values[nodes[0]] by self._resolve_name(values, node[0]) with a _resolve_name method like this one, the filter is able to traverse dictionaries:

ATTR_SEPARATOR = "."

def _resolve_name(self, values, name):
    try:
        for subname in name.split(self.ATTR_SEPARATOR):
            values = values[subname]
        return values
    except KeyError:
        raise InvalidQuery("Unknown attribute %s" % name)

It then works like that:

x = Filter({"eq": ("baz.sub", 23)})
assert x(foo=1, bar=1, baz={"sub": 23})

x = Filter({"eq": ("baz.sub", 23)})
assert not x(foo=1, bar=1, baz={"sub": 3})

By using the syntax key.subkey.subsubkey the filter is able to access item inside dictionaries on more complex data structure.

That basic filter engine can evolve quite easily in something powerful, as you can add new operators or new way to access/manipulate the passed data structure.

If you have other ideas on nifty features that could be added, feel free to add a comment below!

Welcome back to the part 2 of the python application project, if you miss the first part of the project then you can read it here. In this chapter we are going to print out the file name which we have selected earlier with the help of the custom made thread instance instead of print out that filename directly inside the selectFile method just like in the previous chapter.

First lets create a custom made thread class from the main Thread class then process the selected filename under it’s run method.

import threading

class Remove(threading.Thread):

   def __init__(self, massage):

      threading.Thread.__init__(self)
      self.massage = massage

   def run(self):
      print(self.massage)
      print('program terminate!')
      return

Now in the main file the program will create a new instance of the Remove thread class whenever the user has clicked on the button and selected a file from the folder.

This is the modify version of the main file.

from tkinter import *
from tkinter import filedialog
from Remove import Remove

win = Tk() # 1 Create instance
win.title("Multitas") # 2 Add a title
win.resizable(0, 0) # 3 Disable resizing the GUI

# 4 Create a label
aLabel = Label(win, text="Remove duplicate file")
aLabel.grid(column=0, row=0) # 5 Position the label

# 6 Create a selectFile function to be used by button
def selectFile():

    filename = filedialog.askopenfilename(initialdir="/", title="Select file")
    remove = Remove(filename) # 7 create and start new thread to print the filename from the selected file
    remove.start() 

# 8 Adding a Button
action = Button(win, text="Search File", command=selectFile)
action.grid(column=0, row=1) # 9 Position the button

win.mainloop()  # 10 start GUI

The reason we need to create a thread when we search and remove the duplicate files later on in our project is because the search program will freeze up whenever we search for a very large folder which contains lots of files inside it, therefore creating a separate stand alone thread to process those files is a must.

Alright, with that we are now ready to move to the next step of our project, which is to create a search engine which will help us to remove the duplicate files on our folder.

Shipping a web application usually involves having your code up and running on single or multiple servers. In this model, you end up setting up processes for monitoring, provisioning, and scaling your servers up or down. Although this seems to work well, having all the logistics around a web application handled in an automated manner reduces a lot of manual overhead. Enter Serverless.

With Serverless Architecture, you don’t manage servers. Instead, you only need to ship the code or the executable package to the platform that executes it. It’s not really serverless. The servers do exist, but the developer doesn’t need to worry about them.

AWS introduced Lambda Services, a platform that enables developers to simply have their code executed in a particular runtime environment. To make the platform easy to use, many communities have come up with some really good frameworks around it in order to make the serverless apps a working solution.

By the end of this tutorial, you’ll be able to:

• Discuss the benefits of a serverless architecture
• Explore Chalice, a Python serverless framework
• Build a full blown serverless app for a real world use case
• Deploy to Amazon Web Services (AWS) Lambda
• Compare Pure and Lambda functions

Getting Started With AWS Chalice

Chalice, a Python Serverless Microframework developed by AWS, enables you to quickly spin up and deploy a working serverless app that scales up and down on its own as required using AWS Lambda.

Why Chalice?

For Python developers accustomed to the Flask web framework, Chalice should be a breeze in terms of building and shipping your first app. Highly inspired by Flask, Chalice keeps it pretty minimalist in terms of defining what the service should be like and finally making an executable package of the same.

Enough theory! Let’s start with a basic hello-world app and kick-start our serverless journey.

Project Setup

Before diving into Chalice, you’ll set up a working environment on your local machine, which will set you up for the rest of the tutorial.

First, create and activate a virtual environment and install Chalice:

$ python3.6 -m venv env
$source env/bin/activate
(env)$ pip install chalice

Follow our comprehensive guide on the Pipenv packaging tool.

Now that you have Chalice installed on your virtual environment, let’s use the Chalice CLI to generate some boilerplate code:

(env)$ chalice new-project

Enter the name of the project when prompted and hit return. A new directory is created with that name:

<project-name>/
|
├── .chalice/
│   └── config.json
|
├── .gitignore
├── app.py
└── requirements.txt

See how minimalist the Chalice codebase is. A .chalice directory, app.py, and requirements.txt is all that it requires to have a serverless app up and running. Let’s quickly run the app on our local machine.

Chalice CLI consists of really great utility functions allowing you to perform a number of operations from running locally to deploying in a Lambda environment.

Build and Run Locally

You can simulate the app by running it locally using the local utility of Chalice:

(env)$ chalice localServing on 127.0.0.1:8000

By default, Chalice runs on port 8000. We can now check the index route by making a curl request to http://localhost:8000/:

$ curl -X GET http://localhost:8000/
{"hello": "world"}

Now if we look at app.py, we can appreciate the simplicity with which Chalice allows you to build a serverless service. All the complex stuff is handled by the decorators:

fromchaliceimportChaliceapp=Chalice(app_name='serverless-sms-service')@app.route('/')defindex():return{'hello':'world'}

Now, let’s move on to deploying our app on the AWS Lambda.

Deploy on AWS Lambda

Chalice makes deploying your serverless app completely effortless. Using the deploy utility, you can simply instruct Chalice to deploy and create a Lambda function that can be accessible via a REST API.

Before we begin deployment, we need to make sure we have our AWS credentials in place, usually located at ~/.aws/config. The contents of the file look as follows:

[default]aws_access_key_id=<your-access-key-id>aws_secret_access_key=<your-secret-access-key>region=<your-region>

With AWS credentials in place, let’s begin our deployment process with just a single command:

(env)$ chalice deploy
Creating deployment package.Updating policy for IAM role: hello-world-devCreating lambda function: hello-world-devCreating Rest APIResources deployed:  - Lambda ARN: arn:aws:lambda:ap-south-1:679337104153:function:hello-world-dev  - Rest API URL: https://fqcdyzvytc.execute-api.ap-south-1.amazonaws.com/api/

Wow! Yes, it is really this easy to get your serverless app up and running. To verify simply make a curl request on the generated Rest API URL:

$ curl -X GET https://fqcdyzvytc.execute-api.ap-south-1.amazonaws.com/api/
{"hello": "world"}

Typically, this is all that you need to get your serverless app up and running. You can also go to your AWS console and see the Lambda function created under the Lambda service section. Each Lambda service has a unique REST API endpoint that can be consumed in any web application.

Next, you will begin building your Serverless SMS Sender service using Twilio as an SMS service provider.

Building a Serverless SMS Sender Service

With a basic hello-world app deployed, let’s move on to building a more real-world application that can be used along with everyday web apps. In this section, you’ll build a completely serverless SMS-sending app that can be plugged into any system and work as expected as long as the input parameters are correct.

In order to send SMS, we will be using Twilio, a developer-friendly SMS service. Before we begin using Twilio, we need to take care of a few prerequisites:

• Create an account and acquire ACCOUNT_SID and AUTH_TOKEN.
• Get a mobile phone number, which is available for free at Twilio for minor testing stuff.
• Install the twilio package in our virtual environment using pip install twilio.

With all the above prerequisites checked, you can start building your SMS service client using Twilio’s Python library. Let’s begin by cloning the repository and creating a new feature branch:

$ git clone <project-url>
$cd<project-dir>
$ git checkout tags/1.0 -b twilio-support

Now make the following changes to app.py to evolve it from a simple hello-world app to enable support for Twilio service too.

First, let’s include all the import statements:

fromosimportenvironasenv# 3rd party importsfromchaliceimportChalice,Responsefromtwilio.restimportClientfromtwilio.base.exceptionsimportTwilioRestException# Twilio ConfigACCOUNT_SID=env.get('ACCOUNT_SID')AUTH_TOKEN=env.get('AUTH_TOKEN')FROM_NUMBER=env.get('FROM_NUMBER')TO_NUMBER=env.get('TO_NUMBER')

Next, you’ll encapsulate the Twilio API and use it to send SMS:

app=Chalice(app_name='sms-shooter')# Create a Twilio client using account_sid and auth tokentw_client=Client(ACCOUNT_SID,AUTH_TOKEN)@app.route('/service/sms/send',methods=['POST'])defsend_sms():request_body=app.current_request.json_bodyifrequest_body:try:msg=tw_client.messages.create(from_=FROM_NUMBER,body=request_body['msg'],to=TO_NUMBER)ifmsg.sid:returnResponse(status_code=201,headers={'Content-Type':'application/json'},body={'status':'success','data':msg.sid,'message':'SMS successfully sent'})else:returnResponse(status_code=200,headers={'Content-Type':'application/json'},body={'status':'failure','message':'Please try again!!!'})exceptTwilioRestExceptionasexc:returnResponse(status_code=400,headers={'Content-Type':'application/json'},body={'status':'failure','message':exc.msg})

In the above snippet, you simply create a Twilio client object using ACCOUNT_SID and AUTH_TOKEN and use it to send messages under the send_sms view. send_sms is a bare bones function that uses the Twilio client’s API to send the SMS to the specified destination. Before proceeding further, let’s give it a try and run it on our local machine.

Build and Run Locally

Now you can run your app on your machine using the local utility and verify that everything is working fine:

(env)$ chalice local

Now make a curl POST request to http://localhost:8000/service/sms/send with a specific payload and test the app locally:

$ curl -H "Content-Type: application/json" -X POST -d '{"msg": "hey mate!!!"}' http://localhost:8000/service/sms/send

The above request responds as follows:

{"status":"success","data":"SM60f11033de4f4e39b1c193025bcd5cd8","message":"SMS successfully sent"}

The response indicates that the message was successfully sent. Now, let’s move on to deploying the app on AWS Lambda.

Deploy on AWS Lambda

As suggested in the previous deployment section, you just need to issue the following command:

(env)$ chalice deploy
Creating deployment package.Updating policy for IAM role: sms-shooter-devCreating lambda function: sms-shooter-devCreating Rest APIResources deployed:  - Lambda ARN: arn:aws:lambda:ap-south-1:679337104153:function:sms-shooter-dev  - Rest API URL: https://qtvndnjdyc.execute-api.ap-south-1.amazonaws.com/api/

twilio==6.18.1

Once all the package dependencies are sorted, you need to make sure all the environment variables are also shipped along and set correctly during the Lambda runtime. To do so, you have to add all the environment variables in .chalice/config.json in the following manner:

{"version":"2.0","app_name":"sms-shooter","stages":{"dev":{"api_gateway_stage":"api","environment_variables":{"ACCOUNT_SID":"<your-account-sid>","AUTH_TOKEN":"<your-auth-token>","FROM_NUMBER":"<source-number>","TO_NUMBER":"<destination-number>"}}}}

Now we’re good to deploy:

Creating deployment package.Updating policy for IAM role: sms-shooter-devUpdating lambda function: sms-shooter-devUpdating rest APIResources deployed:  - Lambda ARN: arn:aws:lambda:ap-south-1:679337104153:function:sms-shooter-dev  - Rest API URL: https://fqcdyzvytc.execute-api.ap-south-1.amazonaws.com/api/

Do a sanity check by making a curl request to the generated API endpoint:

$ curl -H "Content-Type: application/json" -X POST -d '{"msg": "hey mate!!!"}' https://fqcdyzvytc.execute-api.ap-south-1.amazonaws.com/api/service/sms/send

The above request responds as expected:

{"status":"success","data":"SM60f11033de4f4e39b1c193025bcd5cd8","message":"SMS successfully sent"}

Now, you have a completely serverless SMS sending service up and running. With the front end of this service being a REST API, it can be used in other applications as a plug-and-play feature that is scalable, secure, and reliable.

Refactoring

Finally, we will refactor our SMS app to not contain all the business logic in app.py completely. Instead, we will follow the Chalice prescribed best practices and abstract the business logic under the chalicelib/ directory.

Let’s begin by creating a new branch:

$ git checkout tags/2.0 -b sms-app-refactor

First, create a new directory in the root directory of the project named chalicelib/ and create a new file named sms.py:

(env)$ mkdir chalicelib
(env)$ touch chalicelib/sms.py

Update the above created chalicelib/sms.py with the SMS sending logic by abstracting things from app.py:

fromosimportenvironasenvfromtwilio.restimportClient# Twilio ConfigACCOUNT_SID=env.get('ACCOUNT_SID')AUTH_TOKEN=env.get('AUTH_TOKEN')FROM_NUMBER=env.get('FROM_NUMBER')TO_NUMBER=env.get('TO_NUMBER')# Create a twilio client using account_sid and auth tokentw_client=Client(ACCOUNT_SID,AUTH_TOKEN)defsend(payload_params=None):""" send sms to the specified number """msg=tw_client.messages.create(from_=FROM_NUMBER,body=payload_params['msg'],to=TO_NUMBER)ifmsg.sid:returnmsg

The above snippet only accepts the input params and responds as required. Now to make this work, we need to make changes to app.py as well:

# Core importsfromchaliceimportChalice,Responsefromtwilio.base.exceptionsimportTwilioRestException# App level importsfromchalicelibimportsmsapp=Chalice(app_name='sms-shooter')@app.route('/')defindex():return{'hello':'world'}@app.route('/service/sms/send',methods=['POST'])defsend_sms():request_body=app.current_request.json_bodyifrequest_body:try:resp=sms.send(request_body)ifresp:returnResponse(status_code=201,headers={'Content-Type':'application/json'},body={'status':'success','data':resp.sid,'message':'SMS successfully sent'})else:returnResponse(status_code=200,headers={'Content-Type':'application/json'},body={'status':'failure','message':'Please try again!!!'})exceptTwilioRestExceptionasexc:returnResponse(status_code=400,headers={'Content-Type':'application/json'},body={'status':'failure','message':exc.msg})

In the above snippet, all the SMS sending logic is invoked from the chalicelib.sms module, making the view layer a lot cleaner in terms of readability. This abstraction lets you add much more complex business logic and customize the functionality as required.

Sanity Check

After refactoring our code, let’s ensure it is running as expected.

Build and Run Locally

Run the app once again using the local utility:

(env)$ chalice local

Make a curl request and verify. Once that’s done, move on to deployment.

Deploy on AWS Lambda

Once you are sure everything is working as expected, you can now finally deploy your app:

(env)$ chalice deploy

As usual, the command executes successfully and you can verify the endpoint.

Conclusion

You now know how to do the following:

• Build a serverless application using AWS Chalice in accordance with best practices
• Deploy your working app on the Lambda runtime environment

Lambda services under the hood are analogous to pure functions, which have a certain behavior on a set of input/output. Developing precise Lambda services allows for better testing, readability, and atomicity. Since Chalice is a minimalist framework, you can just focus on the business logic, and the rest is taken care of, from deployment to IAM policy generation. This is all with just a single command deployment!

Moreover, Lambda services are mostly focused on heavy CPU bound processing and scale in a self-governed manner, as per the number of requests in a unit of time. Using serverless architecture allows your codebase to be more like SOA (Service Oriented Architecture). Using AWS’s other products in their ecosystem that plug in well with Lambda functions is even more powerful.

[ Improve Your Python With 🐍 Python Tricks 💌 – Get a short & sweet Python Trick delivered to your inbox every couple of days. >> Click here to learn more and see examples ]

Today we've issued the 2.1.4 and 1.11.17 bugfix releases.

The release package and checksums are available from our downloads page, as well as from the Python Package Index. The PGP key ID used for this release is Carlton Gibson: E17DF5C82B4F9D00.

Introduction

In the previous article, we looked at how Python's Matplotlib library can be used for data visualization. In this article we will look at Seaborn which is another extremely useful library for data visualization in Python. The Seaborn library is built on top of Matplotlib and offers many advanced data visualization capabilities.

Though, the Seaborn library can be used to draw a variety of charts such as matrix plots, grid plots, regression plots etc., in this article we will see how the Seaborn library can be used to draw distributional and categorial plots. In the next part of the article, we will see how to draw regression plots, matrix plots, and grid plots.

Downloading the Seaborn Library

The seaborn library can be downloaded in a couple of ways. If you are using pip installer for Python libraries, you can execute the following command to download the library:

pip install seaborn  

Alternatively, if you are using the Anaconda distribution of Python, you can use execute the following command to download the seaborn library:

conda install seaborn  

The Dataset

The dataset that we are going to use to draw our plots will be the Titanic dataset, which is downloaded by default with the Seaborn library. All you have to do is use the load_dataset function and pass it the name of the dataset.

Let's see what the Titanic dataset looks like. Execute the following script:

import pandas as pd  
import numpy as np

import matplotlib.pyplot as plt  
import seaborn as sns

dataset = sns.load_dataset('titanic')

dataset.head()  

The script above loads the Titanic dataset and displays the first five rows of the dataset using the head function. The output looks like this:

The dataset contains 891 rows and 15 columns and contains information about the passengers who boarded the unfortunate Titanic ship. The original task is to predict whether or not the passenger survived depending upon different features such as their age, ticket, cabin they boarded, the class of the ticket, etc. We will use the Seaborn library to see if we can find any patterns in the data.

Distributional Plots

Distributional plots, as the name suggests are type of plots that show the statistical distribution of data. In this section we will see some of the most commonly used distribution plots in Seaborn.

The Dist Plot

The distplot() shows the histogram distribution of data for a single column. The column name is passed as a parameter to the distplot() function. Let's see how the price of the ticket for each passenger is distributed. Execute the following script:

sns.distplot(dataset['fare'])  

Output:

You can see that most of the tickets have been solved between 0-50 dollars. The line that you see represents the kernel density estimation. You can remove this line by passing False as the parameter for the kde attribute as shown below:

sns.distplot(dataset['fare'], kde=False)  

Output:

Now you can see there is no line for the kernel density estimation on the plot.

You can also pass the value for the bins parameter in order to see more or less details in the graph. Take a look at he following script:

sns.distplot(dataset['fare'], kde=False, bins=10)  

Here we set the number of bins to 10. In the output, you will see data distributed in 10 bins as shown below:

Output:

You can clearly see that for more than 700 passengers, the ticket price is between 0 and 50.

The Joint Plot

The jointplot()is used to display the mutual distribution of each column. You need to pass three parameters to jointplot. The first parameter is the column name for which you want to display the distribution of data on x-axis. The second parameter is the column name for which you want to display the distribution of data on y-axis. Finally, the third parameter is the name of the data frame.

Let's plot a joint plot of age and fare columns to see if we can find any relationship between the two.

sns.jointplot(x='age', y='fare', data=dataset)  

Output:

From the output, you can see that a joint plot has three parts. A distribution plot at the top for the column on the x-axis, a distribution plot on the right for the column on the y-axis and a scatter plot in between that shows the mutual distribution of data for both the columns. You can see that there is no correlation observed between prices and the fares.

You can change the type of the joint plot by passing a value for the kind parameter. For instance, if instead of scatter plot, you want to display the distribution of data in the form of a hexagonal plot, you can pass the value hex for the kind parameter. Look at the following script:

sns.jointplot(x='age', y='fare', data=dataset, kind='hex')  

Output:

In the hexagonal plot, the hexagon with most number of points gets darker color. So if you look at the above plot, you can see that most of the passengers are between age 20 and 30 and most of them paid between 10-50 for the tickets.

The Pair Plot

The paitplot() is a type of distribution plot that basically plots a joint plot for all the possible combination of numeric and Boolean columns in your dataset. You only need to pass the name of your dataset as the parameter to the pairplot() function as shown below:

sns.pairplot(dataset)  

A snapshot of the portion of the output is shown below:

Note: Before executing the script above, remove all null values from the dataset using the following command:

dataset = dataset.dropna()  

From the output of the pair plot you can see the joint plots for all the numeric and Boolean columns in the Titanic dataset.

To add information from the categorical column to the pair plot, you can pass the name of the categorical column to the hue parameter. For instance, if we want to plot the gender information on the pair plot, we can execute the following script:

sns.pairplot(dataset, hue='sex')  

Output:

In the output you can see the information about the males in orange and the information about the female in blue (as shown in the legend). From the joint plot on the top left, you can clearly see that among the surviving passengers, the majority were female.

The Rug Plot

The rugplot() is used to draw small bars along x-axis for each point in the dataset. To plot a rug plot, you need to pass the name of the column. Let's plot a rug plot for fare.

sns.rugplot(dataset['fare'])  

Output:

From the output, you can see that as was the case with the distplot(), most of the instances for the fares have values between 0 and 100.

These are some of the most commonly used distribution plots offered by the Python's Seaborn Library. Let's see some of categorical plots in the Seaborn library.

Categorical Plots

Categorical plots, as the name suggests are normally used to plot categorical data. The categorical plots plot the values in the categorical column against another categorical column or a numeric column. Let's see some of the most commonly used categorical data.

The Bar Plot

The barplot() is used to display the mean value for each value in a categorical column, against a numeric column. The first parameter is the categorical column, the second parameter is the numeric column while the third parameter is the dataset. For instance, if you want to know the mean value of the age of the male and female passengers, you can use the bar plot as follows.

sns.barplot(x='sex', y='age', data=dataset)  

Output:

From the output, you can clearly see that the average age of male passengers is just less than 40 while the average age of female passengers is around 33.

In addition to finding the average, the bar plot can also be used to calculate other aggregate values for each category. To do so, you need to pass the aggregate function to the estimator. For instance, you can calculate the standard deviation for the age of each gender as follows:

import numpy as np

import matplotlib.pyplot as plt  
import seaborn as sns

sns.barplot(x='sex', y='age', data=dataset, estimator=np.std)  

Notice, in the above script we use the std aggregate function from the numpy library to calculate the standard deviation for the ages of male and female passengers. The output looks like this:

The Count Plot

The count plot is similar to the bar plot, however it displays the count of the categories in a specific column. For instance, if we want to count the number of males and women passenger we can do so using count plot as follows:

sns.countplot(x='sex', data=dataset)  

The output shows the count as follows:

Output:

The Box Plot

The box plot is used to display the distribution of the categorical data in the form of quartiles. The center of the box shows the median value. The value from the lower whisker to the bottom of the box shows the first quartile. From the bottom of the box to the middle of the box lies the second quartile. From the middle of the box to the top of the box lies the third quartile and finally from the top of the box to the top whisker lies the last quartile.

You can study more about quartiles and box plots at this link.

Now let's plot a box plot that displays the distribution for the age with respect to each gender. You need to pass the categorical column as the first parameter (which is sex in our case) and the numeric column (age in our case) as the second parameter. Finally, the dataset is passed as the third parameter, take a look at the following script:

sns.boxplot(x='sex', y='age', data=dataset)  

Output:

Let's try to understand the box plot for female. The first quartile starts at around 5 and ends at 22 which means that 25% of the passengers are aged between 5 and 25. The second quartile starts at around 23 and ends at around 32 which means that 25% of the passengers are aged between 23 and 32. Similarly, the third quartile starts and ends between 34 and 42, hence 25% passengers are aged within this range and finally the fourth or last quartile starts at 43 and ends around 65.

If there are any outliers or the passengers that do not belong to any of the quartiles, they are called outliers and are represented by dots on the box plot.

You can make your box plots more fancy by adding another layer of distribution. For instance, if you want to see the box plots of forage of passengers of both genders, along with the information about whether or not they survived, you can pass the survived as value to the hue parameter as shown below:

sns.boxplot(x='sex', y='age', data=dataset, hue="survived")  

Output:

Now in addition to the information about the age of each gender, you can also see the distribution of the passengers who survived. For instance, you can see that among the male passengers, on average more younger people survived as compared to the older ones. Similarly, you can see that the variation among the age of female passengers who did not survive is much greater than the age of the surviving female passengers.

The Violin Plot

The violin plot is similar to the box plot, however, the violin plot allows us to display all the components that actually correspond to the data point. The violinplot() function is used to plot the violin plot. Like the box plot, the first parameter is the categorical column, the second parameter is the numeric column while the third parameter is the dataset.

Let's plot a violin plot that displays the distribution for the age with respect to each gender.

sns.violinplot(x='sex', y='age', data=dataset)  

Output:

You can see from the figure above that violin plots provide much more information about the data as compared to the box plot. Instead of plotting the quartile, the violin plot allows us to see all the components that actually correspond to the data. The area where the violin plot is thicker has a higher number of instances for the age. For instance, from the violin plot for males, it is clearly evident that the number of passengers with age between 20 and 40 is higher than all the rest of the age brackets.

Like box plots, you can also add another categorical variable to the violin plot using the hue parameter as shown below:

sns.violinplot(x='sex', y='age', data=dataset, hue='survived')  

Now you can see a lot of information on the violin plot. For instance, if you look at the bottom of the violin plot for the males who survived (left-orange), you can see that it is thicker than the bottom of the violin plot for the males who didn't survive (left-blue). This means that the number of young male passengers who survived is greater than the number of young male passengers who did not survive. The violin plots convey a lot of information, however, on the downside, it takes a bit of time and effort to understand the violin plots.

Instead of plotting two different graphs for the passengers who survived and those who did not, you can have one violin plot divided into two halves, where one half represents surviving while the other half represents the non-surviving passengers. To do so, you need to pass True as value for the split parameter of the violinplot() function. Let's see how we can do this:

sns.violinplot(x='sex', y='age', data=dataset, hue='survived', split=True)  

The output looks like this:

Now you can clearly see the comparison between the age of the passengers who survived and who did not for both males and females.

Both violin and box plots can be extremely useful. However, as a rule of thumb if you are presenting your data to a non-technical audience, box plots should be preferred since they are easy to comprehend. On the other hand, if you are presenting your results to the research community it is more convenient to use violin plot to save space and to convey more information in less time.

The Strip Plot

The strip plot draws a scatter plot where one of the variables is categorical. We have seen scatter plots in the joint plot and the pair plot sections where we had two numeric variables. The strip plot is different in a way that one of the variables is categorical in this case, and for each category in the categorical variable, you will see scatter plot with respect to the numeric column.

The stripplot() function is used to plot the violin plot. Like the box plot, the first parameter is the categorical column, the second parameter is the numeric column while the third parameter is the dataset. Look at the following script:

sns.stripplot(x='sex', y='age', data=dataset)  

Output:

You can see the scattered plots of age for both males and females. The data points look like strips. It is difficult to comprehend the distribution of data in this form. To better comprehend the data, pass True for the jitter parameter which adds some random noise to the data. Look at the following script:

sns.stripplot(x='sex', y='age', data=dataset, jitter=True)  

Output:

Now you have a better view for the distribution of age across the genders.

Like violin and box plots, you can add an additional categorical column to strip plot using hue parameter as shown below:

sns.stripplot(x='sex', y='age', data=dataset, jitter=True, hue='survived')  

Again you can see there are more points for the males who survived near the bottom of the plot compared to those who did not survive.

Like violin plots, we can also split the strip plots. Execute the following script:

sns.stripplot(x='sex', y='age', data=dataset, jitter=True, hue='survived', split=True)  

Output:

Now you can clearly see the difference in the distribution for the age of both male and female passengers who survived and those who did not survive.

The Swarm Plot

The swarm plot is a combination of the strip and the violin plots. In the swarm plots, the points are adjusted in such a way that they don't overlap. Let's plot a swarm plot for the distribution of age against gender. The swarmplot() function is used to plot the violin plot. Like the box plot, the first parameter is the categorical column, the second parameter is the numeric column while the third parameter is the dataset. Look at the following script:

sns.swarmplot(x='sex', y='age', data=dataset)  

You can clearly see that the above plot contains scattered data points like the strip plot and the data points are not overlapping. Rather they are arranged to give a view similar to that of a violin plot.

Let's add another categorical column to the swarm plot using the hue parameter.

sns.swarmplot(x='sex', y='age', data=dataset, hue='survived')  

Output:

From the output, it is evident that the ratio of surviving males is less than the ratio of surviving females. Since for the male plot, there are more blue points and less orange points. On the other hand, for females, there are more orange points (surviving) than the blue points (not surviving). Another observation is that amongst males of age less than 10, more passengers survived as compared to those who didn't.

We can also split swarm plots as we did in the case of strip and box plots. Execute the following script to do so:

sns.swarmplot(x='sex', y='age', data=dataset, hue='survived', split=True)  

Output:

Now you can clearly see that more women survived, as compared to men.

Combining Swarm and Violin Plots

Swarm plots are not recommended if you have a huge dataset since they do not scale well because they have to plot each data point. If you really like swarm plots, a better way is to combine two plots. For instance, to combine a violin plot with swarm plot, you need to execute the following script:

sns.violinplot(x='sex', y='age', data=dataset)  
sns.swarmplot(x='sex', y='age', data=dataset, color='black')  

Output:

Conclusion

Seaborn is an advanced data visualization library built on top of Matplotlib library. In this article, we looked at how we can draw distributional and categorical plots using Seaborn library. This is Part 1 of the series of article on Seaborn. In the next article, we will see how we play around with grid functionalities in Seaborn and how we can draw Matrix and Regression plots in Seaborn.

By James A. Bednar This post is the second in a three-part series on the current state of Python data visualization and the trends that emerged from SciPy 2018. In my previous post, I provided an overview of the myriad Python data visualization tools currently available, how they relate to each other, and their many …
Read more →

The post Python Data Visualization 2018: Moving Toward Convergence appeared first on Anaconda.

Django Templates are used to create HTML interfaces that get rendered with a Django view.

A TemplateView is a generic class-based view that helps developers create a view for a specific template without re-inventing the wheel.

TemplateView is the simplest one of many generic views provided by Django.

You can create a view for an example index.html template by simply sub-classing TemplateView and providing the template name via a template_name variable.

TemplateView is more convenient when you need to create views that display static HTML pages without context or forms that respond to GET requests.

TemplateView is simply a sub-class of the View class with some repetitive and boilerplate code that renders a Django template and sends it to the client.

Django View Example

Before looking at how to use TemplateView, let's first look at how we can create a Django view from scratch.

Let's pretend we need to create a home view. This is the required code that you need to write in the views.py file of your application

fromdjango.shortcutsimportrenderfromdjango.views.generic.baseimportViewclassHome(View):defget(self,request,*args,**kwargs):returnrender(request,"index.html")

If our app is named myapp, you need to create a templates/myapp inside myapp and then add an index.html template inside of it. The path of the index.html file should be myapp/templates/myapp/index.html.

So what does View do for us? It simply provides the get method which needs to contain any code that will be called when a GET request is sent to the associated URL.

You don't have to check for the GET request, just provide your code inside the get method.

As you can see in this example, we used extra code to render and return the index.html template using an HttpResponse.

Django TemplateView Example

Here comes the role of TemplateView. Instead of extending View, override the get method and then process the template and return an HttpResponse object using a render function. Simpy extend TemplateView.

This is the previous example rewritten to use TemplateView:

fromdjango.views.generic.baseimportTemplateViewclassHome(TemplateView):template_name='index.html'

Next, put your index.html template in the corresponding folder and you are good to go!

You don't need to override the get method and provide an implementation using render or another method. It's already done for you in TemplateView.

If you look at the implementation of TemplateView, you'll find an implementation of the get that uses the template in the template_name variable and renders it.

Since this is a common pattern, it's easily isolated and defined in its own class which can be re-used by Django developers without re-inventing the wheel.

The only requirement is that you have to use the template_name variable for specifying the template since this is the only way TemplateView can use to recognize the template you want to render.

Django Template Context with View

If you don't want your template to be completely static, you need to use Template Context.

Let's see how you can provide context to your template using a View class. This is the previous example with a simple context object that we'll be passed to the template to make it more dynamic.

fromdjango.shortcutsimportrenderfromdjango.views.generic.baseimportViewclassHome(View):defget(self,request,*args,**kwargs):context={'message':'Hello Django!'}returnrender(request,"index.html",context=context)

You simply create a context object (You can name it whatever you want) and you pass it as the second parameter of the render method.

Django Template Context with TemplateView

Let's now see the previous example with TemplateView:

fromdjango.views.generic.baseimportTemplateViewclassHome(TemplateView):template_name='index.html'defget_context_data(self,*args,**kwargs):context=super(Home.self).get_context_data(*args,**kwargs)context['message']='Hello World!'returncontext

If using TemplateView, you need to use the get_context_data method to provide any context data variables to your template.

You re-define the get_context_data method and provide an implementation which simply gets a context dict object from the parent class (in this example it's TemplateView) then augments it by passing the message data.

You can then use interpolation curly braces in your index.html template to display your context variable

<p>{{message}}</p>

Using TemplateView with URLs with as_view

After defining the sub-class of TemplateView you need to map it with an URL in the urls.py file of your project. In order to do that, you need to call the as_view method of TemplateView which returns a callable object that can be passed as the second parameter for the path method that associates URLs to views. For example:

fromdjango.urlsimportpathfrommyappimportviewsurlpatterns=[# [...]path('',views.Home.as_view())]

Using TemplateView in urls.py

For even simpler cases, you can use TemplateView directly in your URL. This provides you with a quicker way to render a template:

fromdjango.views.generic.baseimportTemplateViewfromdjango.urlsimportpathurlpatterns=[# [...]path('',TemplateView.as_view(template_name='index.html'))]

In the as_view method of TemplateView, you can pass the template name as a keyword argument.

Conclusion

The Django generic TemplateView view class enables developers to quickly create views that display simple templates without reinventing the wheel.

You simpy need to subclass TemplateView and provide a template name in the template_name variable. This template should obviously exist in your templates folder.

In this article we are going to edit a few game’s classes that we have created earlier, our main objective here is to detach the enemy missiles from the enemy missile manager, which means instead of putting all the enemy missiles under a single missile list inside the enemy missile manager as we have done previously, we are going to create a separate missile list and a separate missile pool...

Source

Related posts:

Create a win scene and the level manager class for pygame projectCreate a next level scene for pygame projectCreate a pool object for player missileThe modify version of the Pygame Missile Manager ClassPygame Music player demoGame progress — creating game state engineGroup all the sprites together with PygameHow to use the mouse input in PygameDrawing an Ellipse with PygameJourney into PyGame — The beginning

Let’s say you are running a conference, and let’s say your Call for Proposals is open, and is saving people’s talk ideas into a spreadsheet.

I am in this situation. Reviewing those proposals is a pain, because there are large paragraphs of text, and spreadsheets are a terrible way to read them. I did the typical software engineer thing: I spent an hour writing a tool to make reading them easier.

The result is csv_review.py. It’s a terminal program that reads a CSV file (the exported proposals). It displays a row at a time on the screen, wrapping text as needed. It has commands for moving around the rows. It collects comments into a second CSV file. That’s it.

There are probably already better ways to do this. Everyone knows that to get answers from the internet, you don’t ask questions, instead you present wrong answers. More people will correct you than will help you. So this tool is my wrong answer to how to review CFP proposals. Correct me!

In this article we will continue with our windows application development using tkinter, in the previous article we have created a button which when we click on it we can select a file from a folder and the program will print the name of that file on the pycharm command console. In this article we will write the program to do this.

1) Select a folder.
2) Print all the name of the files (with file extension) within that folder on the label part of our UI.

First we will edit the main file of the program so it will open up a folder instead of a file.

from tkinter import *
from tkinter import filedialog
from Remove import Remove

win = Tk() # 1 Create instance
win.title("Multitas") # 2 Add a title
win.resizable(0, 0) # 3 Disable resizing the GUI
win.configure(background='black') # 4 change background color

# 5 Create a label
aLabel = Label(win, text="Remove duplicate file", anchor="center")
aLabel.grid(column=0, row=1)
aLabel.configure(foreground="white")
aLabel.configure(background="black")

# 6 Create a selectFile function to be used by button
def selectFile():

    #filename = filedialog.askopenfilename(initialdir="/", title="Select file")
    folder = filedialog.askdirectory() # 7 open a folder then create and start a new thread to print those filenames from the selected folder
    remove = Remove(folder, aLabel) 
    remove.start()

# 8 Adding a Button
action = Button(win, text="Open Folder", command=selectFile)
action.grid(column=0, row=0) # 9 Position the button
action.configure(background='brown')
action.configure(foreground='white')

win.mainloop()  # 10 start GUI

As you can see, we have passed in the name of that folder which we have selected when we create a new Remove thread instance in the selectFile method, besides that we have also passed the label object into the Remove thread instance so we can modify it’s content later on.

Here is the modify version of the Remove thread class.

import threading
import os

class Remove(threading.Thread):

   def __init__(self, massage, aLabel):

      threading.Thread.__init__(self)
      self.massage = massage
      self.label = aLabel

   def run(self):

      text_filename = ''
      filepaths = os.listdir(self.massage)
      for filepath in filepaths:
         text_filename += filepath + '\n'
      self.label.config(text=text_filename)
      return

The program is very simple, get each file name from that selected directory, concatenates them and finally prints them on the label object.

Our main objective here is to create a program which will remove the duplicate files in another folder, we have already known the method to open a single file, and in this article we have learned the method to open a folder, in the next chapter we will continue to add in more methods for this particular program.

Flatpak is a system for building, distributing, and running sandboxed desktop applications on Linux. It uses BubbleWrap in the low level to do the actual sandboxing. In simple terms, you can think Flatpak as a as a very simple and easy way to use desktop applications in containers (sandboxing). Yes, containers, and, yes, it is for desktop applications in Linux. I was looking forward to use hexchat-otr in Fedora, but, it is not packaged in Fedora. That is what made me setup an AppVM for the same using flatpak.

I have installed the flatpak package in my Fedora 29 TemplateVM. I am going to use that to install Hexchat in an AppVM named irc.

Setting up the Flatpak and Hexchat

The first task is to add flathub as a remote for flatpak. This is a store where upstream developers package their application and publish.

flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

And then, I installed the Hexchat from the store. I also installed the version of the OTR plugin required.

$ flatpak install flathub io.github.Hexchat
<output snipped>

$ flatpak install flathub io.github.Hexchat.Plugin.OTR//18.08
Installing in system:
io.github.Hexchat.Plugin.OTR/x86_64/18.08 flathub 6aa12f19cc05
Is this ok [y/n]: y
Installing: io.github.Hexchat.Plugin.OTR/x86_64/18.08 from flathub
[####################] 10 metadata, 7 content objects fetched; 268 KiB transferr
Now at 6aa12f19cc05.

Making sure that the data is retained after reboot

All of the related files are now available under /var/lib/flatpak. But, as this is an AppVM, this will get destroyed when I will reboot. So, I had to make sure that I can keep those between reboots. We can use the Qubes bind-dirs for this in the TemplateVMs, but, as this is particular for this VM, I just chose to use simple shell commands in the /rw/config/rc.local file (make sure that the file is executable).

But, first, I moved the flatpak directory under /home.

sudo mv /var/lib/flatpak /home/

Then, I added the following 3 lines in the /rw/config/rc.local file.

# For flatpak
rm -rf /var/lib/flatpak
ln -s /rw/home/flatpak /var/lib/flatpak

This will make sure that the flatpak command will find the right files even after reboot.

Running the application is now as easy as the following command.

flatpak run io.github.Hexchat

Feel free to try out other applications published in Flathub, for example, Slack or the Mark Text

In this post I'd like to discuss the concepts of type erasure and reification in programming languages. I don't intend to dive very deeply into the specific rules of any particular language; rather, the post is going to present several simple examples in multiple languages, hoping to provide enough intuition and background for a more serious study, if necessary. As you'll see, the actual concepts are very simple and familiar. Deeper details of specific languages pertain more to the idiosyncrasies of those languages' semantics and implementations.

Important note: in C++ there is a programming pattern called type erasure, which is quite distinct from what I'm trying to describe here [1]. I'll be using C++ examples here, but that's to demonstrate how the original concepts apply in C++. The programming pattern will be covered in a separate post.

typedefstructFrob_t{intx;inty;intarr[10];}Frob;intextract(Frob*frob){returnfrob->y*frob->arr[7];}

0:   8b 47 04                mov    0x4(%rdi),%eax
3:   0f af 47 24             imul   0x24(%rdi),%eax
7:   c3                      retq

intextract_cast(void*p){Frob*frob=p;returnfrob->y*frob->arr[7];}

SomeOtherStructss;extract_cast(&ss);// oops

classMain{publicstaticvoidmain(String[]args){Stringstrings[]={"a","b"};Objectobjects[]=strings;objects[0]=5;}}

Exception in thread "main" java.lang.ArrayStoreException: java.lang.Integer
    at Main.main(Main.java:5)

structBase{virtualvoidbasefunc(){printf("basefunc\n");}};structDerived:publicBase{voidderivedfunc(){printf("derived\n");}};voidcall_derived(Base*b){Derived*d=dynamic_cast<Derived*>(b);if(d!=nullptr){d->derivedfunc();}else{printf("cast failed\n");}}

intmain(){Derivedd;call_derived(&d);Baseb;call_derived(&b);}

importjava.util.List;importjava.util.ArrayList;classMain{publicstaticvoidmain(String[]args){List<String>list=newArrayList<String>();list.add("Hi");Stringx=list.get(0);System.out.println(x);}}

importjava.util.List;importjava.util.ArrayList;classMain{publicstaticvoidmain(String[]args){Listlist=newArrayList();list.add("Hi");Stringx=(String)list.get(0);System.out.println(x);}}

classFoo:defbar(self):passf=Foo()f.joe()# <--- calling non-existent method

What are Mini-Sprints?

• Gathering best practices for teaching specific populations, tools, classroom styles, etc.
• Drafting open educational content and resources (such as workbooks, exercises, teaching materials) for classroom use
• Documenting active learning activities across age groups
• Inventory and cataloging of Open Educational Resources online

• Alignment of the task with the education mission and appropriate scope for what can be accomplished in a mini-sprint context.  We are broadly open to all topics, but projects designed to benefit non-profit missions and open access materials will be given highest priority.
• Description of the skills and interests needed from participants.  Remember that you’re going to have a room full of professional educators, plan on making use of that!
• Clearly stated activities that should be completed within the sprint along with expected deliverables.
• How do you expect this project to grow and be sustained over the next year? Imagine submitting a talk about this project for the 2020 Python Education Summit, what would you like to say about it?

• Have you implemented a program that you've been dying to talk about?
• Have you tried something that failed but learned some great lessons that you can share?
• Have you been successful implementing a particular program?

How to submit a talk or mini-sprint