Testing

Continuous Delivery For Complex Systems Using Zuul with Monty Taylor - Episode 172

Summary

Continuous integration systems are important for ensuring that you don’t release broken software. Some projects can benefit from simple, standardized platforms, but as you grow or factor in additional projects the complexity of checking your deployments grows. Zuul is a deployment automation and gating system that was built to power the complexities of OpenStack so it will grow and scale with you. In this episode Monty Taylor explains how he helped start Zuul, how it is designed for scale, and how you can start using it for your continuous delivery systems. He also discusses how Zuul has evolved and the directions it will take in the future.

Preface

  • Hello and welcome to Podcast.__init__, the podcast about Python and the people who make it great.
  • When you’re ready to launch your next app you’ll need somewhere to deploy it, so check out Linode. With private networking, shared block storage, node balancers, and a 200Gbit network, all controlled by a brand new API you’ve got everything you need to scale up. Go to podcastinit.com/linode to get a $20 credit and launch a new server in under a minute.
  • Visit the site to subscribe to the show, sign up for the newsletter, and read the show notes. And if you have any questions, comments, or suggestions I would love to hear them. You can reach me on Twitter at @Podcast__init__ or email [email protected])
  • To help other people find the show please leave a review on iTunes, or Google Play Music, tell your friends and co-workers, and share it on social media.
  • Join the community in the new Zulip chat workspace at podcastinit.com/chat
  • Your host as usual is Tobias Macey and today I’m interviewing Monty Taylor about Zuul, a platform that drives continuous integration, delivery, and deployment systems with a focus on project gating and interrelated projects.

Interview

  • Introductions
  • How did you get introduced to Python?
  • Can you start by explaining what Zuul is and how the project got started?
  • How do you view Zuul in the broader landscape of CI/CD systems (e.g. GoCD, Jenkins, Travis, etc.)?
  • What is the workflow for someone who is defining a pipeline in Zuul?
    • How are the pipelines tested and promoted?
    • One of the problems that are often encountered in CI/CD systems is the difficulty of testing changes locally. What kind of support is available in Zuul for that?
  • Can you describe the project architecture?
    • What aspects of the architecture enable it to scale to large projects and teams?
  • How difficult would it be to swap the Ansible integration for another orchestration tool?
  • What would be involved in adding support for additional version control systems?
  • What are your plans for the future of the project?

Keep In Touch

Picks

Links

The intro and outro music is from Requiem for a Fish The Freak Fandango Orchestra / CC BY-SA

Michael Foord On Testing, Mock, TDD, And The Python Community - Episode 171

Summary

Michael Foord has been working on building and testing software in Python for over a decade. One of his most notable and widely used contributions to the community is the Mock library, which has been incorporated into the standard library. In this episode he explains how he got involved in the community, why testing has been such a strong focus throughout his career, the uses and hazards of mocked objects, and how he is transitioning to freelancing full time.

Preface

  • Hello and welcome to Podcast.__init__, the podcast about Python and the people who make it great.
  • When you’re ready to launch your next app you’ll need somewhere to deploy it, so check out Linode. With private networking, shared block storage, node balancers, and a 200Gbit network, all controlled by a brand new API you’ve got everything you need to scale up. Go to podcastinit.com/linode to get a $20 credit and launch a new server in under a minute.
  • Visit the site to subscribe to the show, sign up for the newsletter, and read the show notes. And if you have any questions, comments, or suggestions I would love to hear them. You can reach me on Twitter at @Podcast__init__ or email [email protected])
  • To help other people find the show please leave a review on iTunes, or Google Play Music, tell your friends and co-workers, and share it on social media.
  • Join the community in the new Zulip chat workspace at podcastinit.com/chat
  • Your host as usual is Tobias Macey and today I’m interviewing Michael Foord mockingly, about his career in Python

Interview

  • Introductions
  • How did you get introduced to Python?
  • One of the main threads in your career appears to be software testing. What aspects of testing do you find so interesting and how did you first get exposed to that aspect of building software?
    • How has the language and ecosystem support for testing evolved over the course of your career?
    • What are some of the areas that you find it to still be lacking?
  • Mock is one of your projects that has been widely adopted and ultimately incorporated into the standard library. What was your reason for starting it in the first place?
    • Mocking can be a controversial topic. What are your current thoughts on how and when to use mocks, stubs, and fixtures?
  • How do you view the state of the art for testing in Python as it compares to other languages that you have worked in?
  • You were fairly early in the move to supporting Python 2 and 3 in a single project with Mock. How has that overall experience changed in the intervening years since Python 2.4 and 3.2?
  • What are some of the notable evolutions in Python and the software industry that you have experienced over your career?
  • You recently transitioned to acting as a software trainer and consultant full time. Where are you focusing your energy currently and what are your grand plans for the future?

Keep In Touch

Picks

Links

The intro and outro music is from Requiem for a Fish The Freak Fandango Orchestra / CC BY-SA

Great Expectations For Your Data Pipelines with Abe Gong and James Campbell - Episode 161

Summary

Testing is a critical activity in all software projects, but one that is often neglected in data pipelines. The complexities introduced by the inherent statefulness of the problem domain and the interdependencies between systems contribute to make pipeline testing difficult to manage. To make this endeavor more manageable Abe Gong and James Campbell have created Great Expectations. In this episode they discuss how you can use the project to create tests in the exploratory phase of building a pipeline and leverage those to monitor your systems in production. They also discussed how Great Expectations works, the difficulties associated with pipeline testing and managing associated technical debt, and their future plans for the project.

Preface

  • Hello and welcome to Podcast.__init__, the podcast about Python and the people who make it great.
  • When you’re ready to launch your next app you’ll need somewhere to deploy it, so check out Linode. With private networking, shared block storage, node balancers, and a 200Gbit network, all controlled by a brand new API you’ve got everything you need to scale up. Go to podcastinit.com/linode to get a $20 credit and launch a new server in under a minute.
  • Finding a bug in production is never a fun experience, especially when your users find it first. Airbrake error monitoring ensures that you will always be the first to know so you can deploy a fix before anyone is impacted. With open source agents for Python 2 and 3 it’s easy to get started, and the automatic aggregations, contextual information, and deployment tracking ensure that you don’t waste time pinpointing what went wrong. Go to podcastinit.com/airbrake today to sign up and get your first 30 days free, and 50% off 3 months of the Startup plan.
  • To get worry-free releases download GoCD, the open source continous delivery server built by Thoughworks. You can use their pipeline modeling and value stream map to build, control and monitor every step from commit to deployment in one place. And with their new Kubernetes integration it’s even easier to deploy and scale your build agents. Go to podcastinit.com/gocd to learn more about their professional support services and enterprise add-ons.
  • Visit the site to subscribe to the show, sign up for the newsletter, and read the show notes. And if you have any questions, comments, or suggestions I would love to hear them. You can reach me on Twitter at @Podcast__init__ or email [email protected]
  • Your host as usual is Tobias Macey and today I’m interviewing James Campbell and Abe Gong about Great Expectations, a tool for testing the data in your analytics pipelines

Interview

  • Introduction
  • How did you first get introduced to Python?
  • What is Great Expectations and what was your motivation for starting it?
  • What are some of the complexities associated with testing analytics pipelines?
    • What types of tests can be executed to ensure data integrity and accuracy?
  • What are some examples of the potential impact of pipeline debt?
  • What is Great Expectations and how does it simplify the process of building and executing pipeline tests?
  • What are some examples of the types of tests that can be built with Great Expectations?
  • For someone getting started with Great Expectations what does the workflow look like?
  • What was your reason for using Python for building it?
    • How does the choice of language benefit or hinder the contexts in which Great Expectations can be used?
  • What are some cases where Great Expectations would not be usable or useful?
  • What have been some of the most challenging aspects of building and using Great Expectations?
  • What are your hopes for Great Expectations going forward?

Contact Info

Picks

Links

The intro and outro music is from The Hug by The Freak Fandango Orchestra / CC BY-SA

Synthetic Data Generation Using Mimesis with Nikita Sobolev - Episode 155

Summary

Most applications require data to operate on in order to function, but sometimes that data is hard to come by, so why not just make it up? Mimesis is a library for randomly generating data of different types, such as names, addresses, and credit card numbers, so that you can use it for testing, anonymizing real data, or for placeholders. This week Nikita Sobolev discusses how the project got started, the challenges that it has posed, and how you can use it in your applications.

Preface

  • Hello and welcome to Podcast.__init__, the podcast about Python and the people who make it great.
  • When you’re ready to launch your next app you’ll need somewhere to deploy it, so check out Linode. With private networking, shared block storage, node balancers, and a 40Gbit network, all controlled by a brand new API you’ve got everything you need to scale up. Go to podcastinit.com/linode to get a $20 credit and launch a new server in under a minute.
  • To get worry-free releases download GoCD, the open source continous delivery server built by Thoughworks. You can use their pipeline modeling and value stream map to build, control and monitor every step from commit to deployment in one place. Go to podcastinit.com/gocd to learn more about their professional support services and enterprise add-ons.
  • Visit the site to subscribe to the show, sign up for the newsletter, and read the show notes. And if you have any questions, comments, or suggestions I would love to hear them. You can reach me on Twitter at @Podcast__init__ or email [email protected])
  • Your host as usual is Tobias Macey and today I’m interviewing Nikita Sobolev about Mimesis, a library for quickly generating synthetic data

Interview

  • Introductions
  • How did you get introduced to Python?
  • What is mimesis and how does it compare to other projects such as faker and factory_boy?
    • What was the motivation for creating it?
  • One of the features that is advertised is the speed of Mimesis. What techniques are used to ensure that the data is generated quickly?
  • What are the built in mechanisms for generating data?
    • What options do users have for customizing the types of data that can get generated?
  • What are some of the most complicated providers to write and maintain?
  • What are some of the use cases outside of unit or integration tests where Mimesis could be beneficial?
    • How would you use Mimesis to anonymize data from a production environment to be used for testing?
  • What are the most challenging aspects of maintaining the Mimesis project?
  • What are some of the plans that you have for the future of Mimesis?

Keep In Touch

Picks

Links

The intro and outro music is from Requiem for a Fish The Freak Fandango Orchestra / CC BY-SA

MonkeyType with Carl Meyer and Matt Page - Episode 146

Summary

One of the draws of Python is how dynamic and flexible the language can be. Sometimes, that flexibility can be problematic if the format of variables at various parts of your program is unclear or the descriptions are inaccurate. The growing middle ground is to use type annotations as a way of providing some verification of the format of data as it flows through your application and enforcing gradual typing. To make it simpler to get started with type hinting, Carl Meyer and Matt Page, along with other engineers at Instagram, created MonkeyType to analyze your code as it runs and generate the type annotations. In this episode they explain how that process works, how it has helped them reduce bugs in their code, and how you can start using it today.

Preface

  • Hello and welcome to Podcast.__init__, the podcast about Python and the people who make it great.
  • I would like to thank everyone who supports us on Patreon. Your contributions help to make the show sustainable.
  • When you’re ready to launch your next project you’ll need somewhere to deploy it. Check out Linode at podastinit.com/linode and get a $20 credit to try out their fast and reliable Linux virtual servers for running your awesome app. And now you can deliver your work to your users even faster with the newly upgraded 200 GBit network in all of their datacenters.
  • If you’re tired of cobbling together your deployment pipeline then it’s time to try out GoCD, the open source continuous delivery platform built by the people at ThoughtWorks who wrote the book about it. With GoCD you get complete visibility into the life-cycle of your software from one location. To download it now go to podcatinit.com/gocd. Professional support and enterprise plugins are available for added piece of mind.
  • Visit the site to subscribe to the show, sign up for the newsletter, and read the show notes. And if you have any questions, comments, or suggestions I would love to hear them. You can reach me on Twitter at @Podcast__init__ or email [email protected])
  • To help other people find the show please leave a review on iTunes, or Google Play Music, tell your friends and co-workers, and share it on social media.
  • A few announcements before we start the show:
    • There’s still time to get your tickets for PyCon Colombia, happening February 9th and 10th. Go to pycon.co to learn more and register.
    • There is also still time to register for the O’Reilly Software Architecture Conference in New York Feb 25-28. Use the link podcastinit.com/sacon-new-york to register and save 20%
    • If you work with data or want to learn more about how the projects you have heard about on the show get used in the real world then join me at the Open Data Science Conference in Boston from May 1st through the 4th. It has become one of the largest events for data scientists, data engineers, and data driven businesses to get together and learn how to be more effective. To save 60% off your tickets go to podcastinit.com/odsc-east-2018 and register.
  • Your host as usual is Tobias Macey and today I’m interviewing Carl Meyer and Matt Page about MonkeyType, a system to collect type information at runtime for your Python 3 code

Interview

  • Introductions
  • How did you get introduced to Python?
  • What is MonkeyType and how did the project get started?
  • How much overhead does the MonkeyType tracing add to the running system, and what techniques have you used to minimize the impact on production systems?
  • Given that the type information is collected from call traces at runtime, and some functions may accept multiple different types for the same arguments (e.g. add), do you have any logic that will allow for combining that information into a higher-order type that gets set as the annotation?
  • How does MonkeyType function internally and how has the implementation evolved over the time that you have been working on it?
  • Once the type annotations are present in your code base, what other tooling are you using to take advantage of that information?
  • It seems as though using MonkeyType to trace your running production systems could be a way to inadvertantly identify dead sections of code that aren’t being executed. Have you investigated ways to use the collected type information perform that analysis?
  • What have been some of the most challenging aspects of building, using, and maintaining MonkeyType?
  • What have been some of the most interesting or noteworthy things that you have learned in the process of working on and with MonkeyType?
  • What have you found to be the most useful and most problematic aspects of the typing capabilities provided in recent versions of Python?
  • For someone who wants to start using MonkeyType today, what is involved in getting it set up and using it in a new or existing codebase?
  • What features or improvements do you have planned for future releases of MonkeyType?

Keep In Touch

Picks

Links

The intro and outro music is from Requiem for a Fish The Freak Fandango Orchestra / CC BY-SA

Golem: End-To-End Test Automation Framework with Luciano Renzi - Episode 137

Summary

The importance of testing your software is widely talked about and well understood. What is not as often discussed is the different types of testing, and how end-to-end tests can benefit your team to ensure proper functioning of your application when it gets released to production. This week Luciano Renzi shares the work that he has done on Golem, a framework for building and executing an automation suite to exercise the entire system from the perspective of the user. He discusses his reasons for creating the project, how he things about testing, and where he plans on taking Golem in the future. Give it a listen and then take it for a test drive.

Preface

  • Hello and welcome to Podcast.__init__, the podcast about Python and the people who make it great.
  • I would like to thank everyone who supports us on Patreon. Your contributions help to make the show sustainable.
  • When you’re ready to launch your next project you’ll need somewhere to deploy it. Check out Linode at podastinit.com/linode and get a $20 credit to try out their fast and reliable Linux virtual servers for running your awesome app. And now you can deliver your work to your users even faster with the newly upgraded 200 GBit network in all of their datacenters.
  • If you’re tired of cobbling together your deployment pipeline then it’s time to try out GoCD, the open source continuous delivery platform built by the people at ThoughtWorks who wrote the book about it. With GoCD you get complete visibility into the life-cycle of your software from one location. To download it now go to podcatinit.com/gocd. Professional support and enterprise plugins are available for added piece of mind.
  • Visit the site to subscribe to the show, sign up for the newsletter, and read the show notes. And if you have any questions, comments, or suggestions I would love to hear them. You can reach me on Twitter at @Podcast__init__ or email [email protected])
  • To help other people find the show please leave a review on iTunes, or Google Play Music, tell your friends and co-workers, and share it on social media.
  • Your host as usual is Tobias Macey and today I’m interviewing Luciano Renzi about Golem, a framework and automation tool for end-to-end testing in Python

Interview

  • Introductions
  • How did you get introduced to Python?
  • What is golem and what motivated you to create it?
    • What was your inspiration for the name?
  • Why did you choose to use Python for Golem and if you were to start over today would you make the same choice?
  • For someone who is unfamiliar with the concept, can you describe what end-to-end testing is and the reasons for making it part of their development process?
  • What is the main goal of Golem
  • What does the internal architecture and implementation of Golem look like and how has that evolved from when you first started the project?
  • How does Golem compare to other Python libraries for automated browser testing and what was lacking in the existing solutions when you created it?
  • What are the differences between golem and robot framework?
  • What about projects written in other languages such as protractor?
  • One of the intriguing features of Golem is the web interface for constructing tests. What are the benefits of codeless automation & record-playback functionality?
  • What are some of the most challenging aspects of building and maintaining Golem?
  • It seems that every browser automation library is ultimately a wrapper around Selenium. Why is a wrapper necessary and why haven’t any strong alternatives been created?
  • What are the advantages of making Golem a framework for test automation, rather than a library?
  • What are some of the most interesting or unexpected uses for Golem that you have seen?
  • What do you have planned for the future of Golem?
  • What is the current state of end to end automation and how do you see it evolving in the future?
  • How do you think machine learning and AI will be used in test automation?

Keep In Touch

Picks

Links

The intro and outro music is from Requiem for a Fish The Freak Fandango Orchestra / CC BY-SA

Coverage.py with Ned Batchelder - Episode 121

Summary

We write tests to make sure that our code is correct, but how do you make sure the tests are correct? This week Ned Batchelder explains how coverage.py fills that need, how he became the maintainer, and how it works under the hood.

Preface

  • Hello and welcome to Podcast.__init__, the podcast about Python and the people who make it great.
  • I would like to thank everyone who supports us on Patreon. Your contributions help to make the show sustainable.
  • When you’re ready to launch your next project you’ll need somewhere to deploy it. Check out Linode at www.podastinit.com/linode and get a $20 credit to try out their fast and reliable Linux virtual servers for running your awesome app.
  • Visit the site to subscribe to the show, sign up for the newsletter, read the show notes, and get in touch.
  • To help other people find the show please leave a review on iTunes, or Google Play Music, tell your friends and co-workers, and share it on social media.
  • Your host as usual is Tobias Macey and today I’m interviewing Ned Batchelder about coverage.py, the ubiquitous tool for measuring your test coverage.

Interview

  • Introductions
  • How did you get introduced to Python?
  • What is coverage.py and how did you get involved with the project?
  • The coverage project has become the de facto standard for measuring test coverage in Python. Why do you think that is?
  • What is the utility of measuring test coverage?
  • What are the downsides to measuring test coverage?
  • One of the notable capabilities that was introduced recently was the plugin for measuring coverage of Django templates. Why is that an important capability and how did you manage to make that work?
  • How does coverage conduct its measurements and how has that algorithm evolved since you first started work on it?
  • What are the most challenging aspects of building and maintaining coverage.py?
  • While I was looking at the bug tracker I was struck by the vast array of contexts in which coverage is used. Do you find it overwhelming trying to support so many operating systems and Python implementations?
  • What might be added to coverage in the future?

Keep In Touch

Picks

Links

The intro and outro music is from Requiem for a Fish The Freak Fandango Orchestra / CC BY-SA

Automat State Machines with Glyph Lefkowitz - Episode 116

Summary

The venerable ‘if’ statement is a cornerstone of program flow and busines logic, but sometimes it can grow unwieldy and lead to unmaintainable software. One alternative that can result in cleaner and easier to understand code is a state machine. This week Glyph explains how Automat was created and how it has been used to upgrade portions of the Twisted project.

Preface

  • Hello and welcome to Podcast.__init__, the podcast about Python and the people who make it great.
  • I would like to thank everyone who supports us on Patreon. Your contributions help to make the show sustainable.
  • When you’re ready to launch your next project you’ll need somewhere to deploy it. Check out Linode at www.podastinit.com/linode and get a $20 credit to try out their fast and reliable Linux virtual servers for running your awesome app.
  • Visit the site to subscribe to the show, sign up for the newsletter, read the show notes, and get in touch.
  • To help other people find the show please leave a review on iTunes, or Google Play Music, tell your friends and co-workers, and share it on social media.
  • Your host as usual is Tobias Macey and today I’m interviewing Glyph about Automat, a library that provides self-service finite-state machines for the programmer on the go.

Interview

  • Introductions
  • How did you get introduced to Python?
  • What is a state machine and when might you want to use one?
  • There are a number of libraries available on PyPI that facilitate the creation of state machines. Why did you feel the need to build a new option and how does it differ from what was already available?
  • Why do you think developers fall into the trap of complicated conditional structures rather than reaching for a state machine?
  • For someone who wants to integrate Automat into their project how would they go about that and what are some of the gotchas that they should keep in mind?
  • What do the internals of Automat look like and how did you approach the overall design of the project?
  • What are some of the more difficult aspects of designing and implementing state machines properly?
  • What are some of the technical hurdles that you have been faced with in the process of building a library for implementing state machines?
  • What do you have planned for the future of Automat?
  • What are some of the most interesting use cases of Automat that you have seen?

Keep In Touch

Picks

Links

The intro and outro music is from Requiem for a Fish The Freak Fandango Orchestra / CC BY-SA

Test Engineering with Cris Medina - Episode 68

Summary

We all know that testing is an important part of software and systems development. The problem is that as our systems and applications grow, the amount of testing necessary increases at an exponential rate. Cris Medina joins us this week to talk about some of the problems and approaches associated with testing these complex systems and some of the ways that Python can help.

Brief Introduction

  • Hello and welcome to Podcast.__init__, the podcast about Python and the people who make it great.
  • I would like to thank everyone who has donated to the show. Your contributions help us make the show sustainable. For details on how to support the show you can visit our site at pythonpodcast.com
  • Linode is sponsoring us this week. Check them out at linode.com/podcastinit and get a $20 credit to try out their fast and reliable Linux virtual servers for your next project
  • We are also sponsored by Sentry this week. Stop hoping your users will report bugs. Sentry’s real-time tracking gives you insight into production deployments and information to reproduce and fix crashes. Check them out at getsentry.com
  • Hired has also returned as a sponsor this week. If you’re looking for a job as a developer or designer then Hired will bring the opportunities to you. Sign up at hired.com/podcastinit to double your signing bonus.
  • The O’Reilly Velocity conference is coming to New York this September and we have a free ticket to give away. If you would like the chance to win it then just sign up for our newsletter at pythonpodcast.com
  • To help other people find the show you can leave a review on iTunes, and tell your friends and co-workers
  • Join our community! Visit discourse.pythonpodcast.com for your opportunity to find out about upcoming guests, suggest questions, and propose show ideas.
  • Your hosts as usual are Tobias Macey and Chris Patti
  • Today we’re interviewing Cris Medina about test engineering for large and complex systems.

Interview with Cris Medina

  • Introductions
  • How did you get introduced to Python? – Chris
  • To get us started can you share your definition of test engineering and how it differs from the types of testing that your average developer is used to? – Tobias
  • What are some common industries or situations where this kind of test engineering becomes necessary? – Tobias
  • How and where does Python fit into the kind of testing that becomes necessary when dealing with these complex systems? – Tobias
  • How do you determine which areas of a system to test and how can Python help in that discovery process? – Tobias
  • What are some of your favorite tools and libraries for this kind of work? – Tobias
  • What are some of the areas where the existing Python tooling falls short? – Tobias
  • Given the breadth of concerns that are encompassed with testing the various components of these large systems, what are some ways that a test engineer can get a high-level view of the overall state? – Tobias
    • How can that information be distilled for presentation to other areas of the business? – Tobias
    • Could that information be used to provide a compelling business case for the resources required to test properly? – Chris
  • Given the low-level nature of this kind of work I imagine that proper visibility of the work being done can be difficult. How do you make sure that management can properly see and appreciate your efforts? – Tobias

Keep In Touch

Picks

Links

The intro and outro music is from Requiem for a Fish The Freak Fandango Orchestra / CC BY-SA

Mypy with David Fisher and Greg Price - Episode 65

Summary

As Python developers we are fond of the dynamic nature of the language. Sometimes, though, it can get a bit too dynamic and that’s where having some type information would come in handy. Mypy is a project that aims to add that missing level of detail to function and variable definitions so that you don’t have to go hunting 5 levels deep in the stack to understand what shape that data structure is supposed to be. This week we spoke with David Fisher and Greg Price about their work on Mypy and its use within Dropbox and the broader community. They explained how it got started, how it works under the covers, and why you should consider adding it to your projects.

Brief Introduction

  • Hello and welcome to Podcast.__init__, the podcast about Python and the people who make it great.
  • I would like to thank everyone who has donated to the show. Your contributions help us make the show sustainable. For details on how to support the show you can visit our site at pythonpodcast.com
  • Linode is sponsoring us this week. Check them out at linode.com/podcastinit and get a $20 credit to try out their fast and reliable Linux virtual servers for your next project
  • We are also sponsored by Sentry this week. Stop hoping your users will report bugs. Sentry’s real-time tracking gives you insight into production deployments and information to reproduce and fix crashes. Check them out at getsentry.com
  • Visit our site to subscribe to our show, sign up for our newsletter, read the show notes, and get in touch.
  • To help other people find the show you can leave a review on iTunes, or Google Play Music, and tell your friends and co-workers
  • Join our community! Visit discourse.pythonpodcast.com for your opportunity to find out about upcoming guests, suggest questions, and propose show ideas.
  • Your hosts as usual are Tobias Macey and Chris Patti
  • Today we’re interviewing David Fisher and Greg Price about Mypy, a library for adding optional static types to your Python code.

es

Interview with David Fisher and Greg Price

  • Introductions
  • How did you get introduced to Python? – Chris
  • Can you explain a bit about what Mypy is and its origin story? – Tobias
  • What are the benefits of using Mypy for both new and existing projects? – Tobias
  • How does the Mypy compilation step work? – Tobias
  • What are the biggest technical challenges in implementing Mypy? – Chris
  • Are there any limitations imposed by the syntax of Python that prevented you from implementing any features or syntax that you would have liked to include in Mypy? – Tobias
  • In Guido’s keynote from this year’s PyCon he mentioned some tentative plans for adding variable type declarations to the Python syntax in one of the next major releases. How much of that idea was inspired by Mypy? – Tobias
  • Type theory is a large and complex problem domain. Can you explain where Mypy falls in this space? – Tobias
  • Which language(s) had the biggest influence on the particular syntax and semantics used in Mypy? – Tobias
  • What kinds of type definitions and guarantees can be encoded using Mypy? – Tobias
  • Can you talk a bit about user defined types as implemented in Mypy? – Chris
  • How has the inclusion of the typing module in the Python standard libary influenced the evolution of Mypy? – Tobias
  • Did the inclusion of multiple inheritance add any implementation complexity to Mypy? – Chris
  • Do you know of any formal studies that have been performed to research the ergonomics or efficiency gains of static or gradual type systems? – Tobias
  • What does the future roadmap for Mypy look like? – Tobias

Keep In Touch

$ pip3 install mypy-lang

Bug reports, feature requests, questions welcome on issue tracker: github.com/python/mypy

Picks

Links

The intro and outro music is from Requiem for a Fish The Freak Fandango Orchestra / CC BY-SA