爲什麼要從WSGI環境中複製一個dictonairy？

在下面example from wsgi.org是cur_named複製：爲什麼要從WSGI環境中複製一個dictonairy？

def __call__(self, environ, start_response): 
    script_name = environ.get('SCRIPT_NAME', '') 
    path_info = environ.get('PATH_INFO', '') 
    for regex, application in self.patterns: 
     match = regex.match(path_info) 
     if not match: 
      continue 
     extra_path_info = path_info[match.end():] 
     if extra_path_info and not extra_path_info.startswith('/'): 
      # Not a very good match 
      continue 
     pos_args = match.groups() 
     named_args = match.groupdict() 
     cur_pos, cur_named = environ.get('wsgiorg.routing_args', ((), {})) 
     new_pos = list(cur_pos) + list(pos_args) 
     new_named = cur_named.copy() # Why copy()? 
     new_named.update(named_args) 
     environ['wsgiorg.routing_args'] = (new_pos, new_named) 
     environ['SCRIPT_NAME'] = script_name + path_info[:match.end()] 
     environ['PATH_INFO'] = extra_path_info 
     return application(environ, start_response) 
    return self.not_found(environ, start_response)

爲什麼不直接調用ur_named.update(named_args)？

來源

2010-09-06 deamon

你知道嗎cur_named字典從哪裏來？只是成像類似如下：

SOME_CONFIG = { 
    'some_key': ((..., ...), {...}), 
    ... 
} 

environ['wsgiorg.routing_args'] = SOME_CONFIG['some_key']

現在，當你更新就地new_named你實際上是更新內部SOME_CONFIG內的字典，這將帶給你的數據到其他請求。除非您確定不需要，否則安全的方法是複製字典。

來源

2010-09-06 16:34:33

好的，但'routing_args'是每個請求和一個無法想象的情況下，就地修改將是至關重要的。即使有另一箇中間件修改這個字典，複製字典也沒有意義，因爲最終只有一個帶有routing_args的字典可以傳遞給應用程序。 – deamon 2010-09-06 22:13:24

我的示例中的SOME_CONFIG不是爲每個請求創建的。像FastCGI這樣的環境在流程生命週期中處理多個請求。由於第一個請求間接修改了這個變量，所以你會得到後續請求的修改數據。 – 2010-09-07 05:44:48

爲什麼要從WSGI環境中複製一個dictonairy？

回答

相關問題