DEV Community: Diego Berolatti

Python Tips # 1

Diego Berolatti — Mon, 19 Aug 2019 20:07:31 +0000

These tips are entirely based on the Python official tutorial guide.

Using else in for statements:

You can use the else clause at the end of a for loop if you want to trigger an action as soon as the loop finishes. It will not be triggered by break:

  for num in range(2, 10):
    for x in range(2, n):
      if n % x == 0:
        print(n, 'equals', x, '*', n//x)
            break
      else:
        # loop fell through without finding a factor
        print(n, 'is a prime number')

Source

Using simple copy vs shallow copy vs deep copy:
- Simple copy or = will only create a reference of the object:

  old_list = [[1, 1, 1], [2, 2, 2], [3, 3, 3]]
  new_list = old_list
  new_list[2][2] = 9

  print('old_list:', old_list)
  print('id of old_list:', id(old_list))

  print('new_list:', new_list)
  print('id of new_list:', id(new_list))

  Old List: [[1, 1, 1], [2, 2, 2], [3, 3, 9]]
  ID of Old List: 140673303268168

  New List: [[1, 1, 1], [2, 2, 2], [3, 3, 9]]
  ID of New List: 140673303268168

Shallow copy or object[:]will create a new object but will reference the nested objects:

import copy

old_list = [[1, 1, 1], [2, 2, 2], [3, 3, 3]]
new_list = old_list[:] # or copy.copy(old_list)
old_list[1][1] = 'AA'

print('old_list:', old_list)
print('id of old_list:', id(old_list))

print('new_list:', new_list)
print('id of new_list:', id(new_list))

```
old_list: [[1, 1, 1], [2, 'AA', 2], [3, 3, 3]]
id of old_list: 140673303268168

new_list: [[1, 1, 1], [2, 'AA', 2], [3, 3, 3]]
id of new_list: 140673303268169
```

Finally, a deep copy will create a new object and will create new objects for the content as well:

import copy

old_list = [[1, 1, 1], [2, 2, 2], [3, 3, 3]]
new_list = copy.deepcopy(old_list)
old_list[1][1] = 'AA'

print('old_list:', old_list)
print('id of old_list:', id(old_list))

print('new_list:', new_list)
print('id of new_list:', id(new_list))

```
old_list: [[1, 1, 1], [2, 'AA', 2], [3, 3, 3]]
id of old_list: 140673303268168

new_list: [[1, 1, 1], [2, 2, 2], [3, 3, 3]]
id of new_list: 140673303268169
```

[Source](https://www.programiz.com/python-programming/shallow-deep-copy)

Default values in functions are evaluated only once:

def f(a, L=[]):
    L.append(a)
    return L

print(f(1))
print(f(2))
print(f(3))

[1]
[1, 2]
[1, 2, 3]

If you don’t want the default to be shared between subsequent calls, you can write the function like this instead:

def f(a, L=None):
    if L is None:
        L = []
    L.append(a)
    return L

Source

Use deque to implement double-ended queues:

"Deques are a generalization of stacks and queues (the name is pronounced “deck” and is short for “double-ended queue”). Deques support thread-safe, memory efficient appends and pops from either side of the deque with approximately the same O(1) performance in either direction".

  from collections import deque
  d = deque('ghi')
  d.append('j')
  d.appendleft('f')
  j = d.pop()
  f = d.popleft()
  for elem in d:
    print(elem.upper())

Source

The "Shared-Account" issue

Diego Berolatti — Sun, 18 Aug 2019 23:18:23 +0000

I need to write about this issue. It involves in some way:

GraphQL (Apollo)
NodeJS
Cache
HTTP headers

Situation

I was working on this project a couple of months ago. I was developing the backend for a new website. It was the second time using Apollo as part of the backend tools (using GraphQL instead of REST allowed to separate more efficiently the frontend and back-end responsibilities and I love that). Everything was working fine until one day I found out something strange was happening with the service.

For some reason, the data from one specific user started to appear to all users in the service. I called it the "shared-account" issue since it made the server think that it was always the same user accessing the data.

By the way, something I didn't mention before is that the way the user authenticates to the service was with an external REST service. The client needed to send a key that was used internally in the GraphQL backend service to validate the user.

Task

The task was very simple. Find this embarrassing issue and solve it.

Action

First, I made sure the issue was not part of my imagination and I replicated it a couple of times until it was undeniable.

Then, I tried to isolate the behavior in a way I can replicate it every time I want. This is very important because it allows me to find the suspects.

So I started, by analyzing the interaction with the front end (sometimes the issue is the way the service is called), then only analyzing the backend behavior with an external client and finally adding logs to the specific pieces that were acting weird.

Changing the authentication header key in the client didn't change anything.

Restarting the server didn't fix the issue but only change the shared-account to the first user that used the service.

And then: I found the issue!

Apollo was saving in the cache of the server the authentication of a previous user. I didn't know why was saving it and why that user in particular. I wanted to understand how the cache worked in apollo so then I googled: "RESTDataSource apollo remove cache"

(RESTDataSource is the name of the apollo class that is in charge of the cache )

The first link sent me to this apollo issue from last year:

Disable cache in ApolloServer when using RESTDataSource #1562

sharathm89 posted on Aug 22, 2018

I am using RESTDataSource to fetch data from REST api's but data is being cached.

How to disable cache since data keeps changing in thequery resolver.

Below is the node.js code.

   const app = express();
    
    const server = new ApolloServer({
      schema: schema,
      context: ({ req }) => ({
        token: req.headers.authorization,
      }),
      dataSources: () => apiDataSources,
    });
    
    server.applyMiddleware({ app });
    
    app.listen({ port: 4000 }, () => {
      console.log("Server is at http://localhost:4000/graphql");
    });

View on GitHub

At least 4 kinds of solutions were suggested there:

Two ways of forcing the class to disable caching
=> Didn't want to do that so I didn't try them.
Other to check the response headers of the authentication service.
=> Apollo RESTDataSource uses the HTTP response "cache" headers to
store the response in the cache, but in my case, the header response
was "no-cache"
Others to change the TTL header to 60 seconds or 0 seconds or -1 second.
=> By default, Apollo uses 24 hours to store data in the cache, you can change this by sending the TTL down to 60 seconds. Some people suggested to use 0 seconds or even -1 second but this is not reliable.

None of this worked for me.

And lastly, one user mentioned that the context ( the object that contains the RESTDataSource) in apollo is instantiated per request.

That was it!

  const dataSources = {
      usersDatasource: new UsersDatasource(),
      spreadsheetDatasource: new SpreadsheetDatasource(database, logger),
  };

  ...
  introspection: false,
  playground: false,
  dataSources,
  },
  ...

I fixed it like this:

  ...
  introspection: false,
  playground: false,
  dataSources: () => {
    return {
      usersDatasource: new UsersDatasource(),
      spreadsheetDatasource: new SpreadsheetDatasource(database, logger),
    };
  },
  ...

Results

I learned a lot solving this issue and I hope you learned something too.

Diego