Ah, the age old pragmatism vs. purism. While it sounds like you have a healthy amount of skepticism, I think this is actually one of the few instances where it's OK to use a global variable. The core of your problem is you need to share data (state) between two routes. A global variable is the simplest way of doing this if all you're doing is appending the number 4 each time.
Here's some things to consider:
- Security: You mentioned security. Will any sensitive information be stored in global_list? If so, you should consider putting safegards in place (authentication and authorization) to make sure only the right people see the appropriate information. Also, if you store user input to the variable, be very careful how you use the data (SQL injection).
- Persistence: Will state need to be maintained across webserver restarts? If everything is in a Python variable, it will be lost when you shut down the process. You may want to persist the data to a filesystem or database.
- Resources: Are you going to be storing lots of information in this global variable? If so, the process may run out of memory, because the global variable is never garbage collected. The solution here is to store the data somewhere and generate aggregate data to use in the app instead (or do pagination).
- Shared-state side effects: Anytime you share data, you have to be conscious of side effects caused by altering this data. If two routes are reading/writing from the same variable, one route could do something that breaks the other route.
More on resources:
For instance, if you store 1KB every time the / route is loaded and get 1M visitors a month, you'd be up to 1GB of memory just for global_list in around 1 month. 1KB is a lot of data, and you probably don't need all of this information to do your calculation in /test. Instead, you could aggregate the data by using global_list as a running total for the full set of data stored elsewhere (a database or filesystem).
If you're doing more than simply presenting a count of records in /test, and you need whole (or partial) records, then you can do pagination. Let's say you're presenting a list of the records in global_list. In this case, /test could simply return the first 10 records by default, but allow the user to see more pages by providing a page parameter. So if the user wants to see records 31-40, they could request /test?page=4