Beforewe begin working with this dataset, we should make some visualizations to better understand the data. As we saw before, we have many columns in this data, whether the bill length, the flipper length, the island the penguin lives on, or even the species of penguin. I’ve done the first visualization for us already in Altair, a popular visualization library that we will use extensively throughout this book because it is interactive by default and generally pretty:

Figure 2.2: Bill length and bill depth

From this, we can see that the Adelie penguins have a shorter bill length but generally have fairly deep bills. Now, what does it look like if we plot weight by flipper length?

Figure 2.3: Bill length and weight

Now we see that Gentoo penguins seem to be heavier than the other two species, and that bill length and body mass are positively correlated. These findings are not a huge surprise, but getting to these simple...

Aswe talked about just before, there are two solutions to this data upload default situation. We can provide a default file to use until the user interacts with the application, or we can stop the app until a file is uploaded. Let’s start with the first option. The following code uses thest.file_uploader() function from within anif statement. If the user uploads a file, then the app uses that; if they do not, then we default to the file we have used before:

import altairas altimport pandasas pdimport seabornas snsimport streamlitas st st.title("Palmer's Penguins")st.markdown("Use this Streamlit app to make your own scatterplot about penguins!") penguin_file = st.file_uploader("Select Your Local Penguins CSV (default provided)")if penguin_fileisnotNone:    penguins_df = pd.read_csv(penguin_file)else:    penguins_df = pd.read_csv("penguins.csv") selected_x_var = st.selectbox( ...

We broadly have two options forStreamlit development:

• Develop in Streamlit andst.write() as a debugger.
• Explore in Jupyter and then copy to Streamlit.

In the first option, we write our code directly in Streamlit as we’re experimenting and exploring exactly what our application will do. We’ve basically been taking this option already, which works very well if we have less exploration work and more implementation work to do.

Pros:

• What you see is what you get – there is no need to maintain both IPython and Python versions of the same app.
• Better experience for learning how to write production code.

Cons:

• A slower feedback loop (the entire app must run before feedback).
• A potentially unfamiliar development environment.

Another option is to utilize the extremely popular Jupyter data science product to write and test out the Streamlit app’s code before placing it in the necessary script and formatting it correctly. This can be useful for exploring new functions that will live in the Streamlit app, but it has serious downsides.

Pros:

• The lightning-fast feedback loop makes it easier to experiment with very large apps.
• Users may be more familiar with Jupyter.
• The full app does not have to be run to get results, as Jupyter can be run in individual cells.

Cons:

• Jupyter may provide deceptive results if run out of order.
• “Copying” code over from Jupyter is time-consuming.
• Python versioning may be different between Jupyter and Streamlit.

My recommendation here is to develop Streamlit apps inside the environment where they are going to be run (that is, a Python file)....

Streamlit runs our Python file from the top down as a script, so we can perform datamanipulation with powerful libraries such aspandas in the same way that we might in a Jupyter notebook or a regular Python script. As we’ve discussed before, we can do all our regular data manipulation as normal. For our Palmer’s Penguins app, what if we wanted the user to be able to filter out penguins based on their gender? The following code filters our DataFrame usingpandas:

import streamlitas stimport pandasas pdimport altairas altimport seabornas snsst.title("Palmer's Penguins")st.markdown('Use this Streamlit app to make your own scatterplot about penguins!')penguin_file = st.file_uploader('Select Your Local Penguins CSV (default provided)')if penguin_fileisnotNone:    penguins_df = pd.read_csv(penguin_file)else:    penguins_df = pd.read_csv('penguins.csv')selected_x_var =...

As we create more computationally intensive Streamlit apps and begin to use and upload larger datasets, we should start thinking about the runtime of these apps and work to increase our efficiency whenever possible. The easiest way to make a Streamlit app more efficient is through caching, which is storing some results in memory so that the app does not repeat the same work whenever possible.

A good analogy for an app’s cache is a human’s short-term memory, where we keep bits of information close at hand that we think might be useful. When something is in our short-term memory, we don’t have to think very hard to get access to that piece of information. In the same way, when we cache a piece of information in Streamlit, we are making a bet that we’ll use that information often.

The way Streamlit caching works more specifically is by storing the results of a function in our app, and if that function is called with the same...

One of the most frustrating parts of the Streamlit operating model fordevelopers starting out is the combination of two facts:

1. By default, information is not stored across reruns of the app.
2. On user input, Streamlits are rerun top-to-bottom.

These two facts make it difficult to make certain types of apps! This is best shown in an example. Let’s say that we want to make a to-do app that makes it easy for you to add items to your to-do list. Adding user input in Streamlit is really simple, so we can create one quickly in a new file calledsession_state_example.py that looks like the following:

import streamlitas stst.title('My To-Do List Creator')my_todo_list = ["Buy groceries","Learn Streamlit","Learn Python"]st.write('My current To-Do list is:', my_todo_list)new_todo = st.text_input("What do you need to do?")if st.button('Add the new To-Do...

This chapter was full of fundamental building blocks that we will use often throughout the remainder of this book, and that you will use to develop your own Streamlit applications.

In terms of data, we covered how to bring our own DataFrames into Streamlit and how to accept user input in the form of a data file, which brings us past only being able to simulate data. In terms of other skill sets, we learned how to use our cache to make our data apps faster, how to control the flow of our Streamlit apps, and how to debug our Streamlit apps usingst.write(). That’s it for this chapter. Next, we’ll move on to data visualization!

Learn more on Discord

To join the Discord community for this book – where you can share feedback, ask questions to the author, and learn about new releases – follow the QR code below:

https://packt.link/sl