标题可能说得不是很清楚，还是上代码：
Flask.wsgi_app(self, environ, start_response): ctx = self.request_context(environ)然后可以看到，实际上会调用
def request_context(self, environ): return _RequestContext(self, environ)之后再进入到class _RequestContext(object):的__init__函数中，后面就不再写了。
我的疑惑是，在第一句生成ctx的时候，为何要弄出一个request_context方法来呢？这个方法就只有简单的一个返回语句，那么我直接在开始的时候实例化不就好了：ctx = _RequestContext(self, environ)？
而且像这样的使用方式在flask中其他地方也还有很多，那么这样使用有什么明显的好处吗？ (或者说像我那样写的直接返回的句子有什么明显的坏处吗？)
這是一個設計的和品味的問題，而不是一個技術問題。
就拿你舉的這個例子來說，我們看到這裡有一層封裝，但是因為封裝的內容太過於簡單，所以讓你疑惑是否有這個必要。要回答這個問題，我們要想想為什麼會有封裝？不管是函數也好，類別也好，我們定義它們可能是因為以下原因：
它們提供了邏輯上的某個功能，便於我們理解
這段邏輯是會被經常調用的，為了避免重複（DRY原則），我們把它抽像出來
這個例子就是符合上面這兩條的：flask 需要一個建立 application context 的功能，而且是在多處會用到它。
另一個好處是，
RequestContext算是比较内部的一个类，大多数情况下用户不会（也不应该）直接使用它。而为了让用户可以创建这个类的对象，作者封装了Flask.request_context()方法，算是最小介面原則（盡量提供最小的介面給使用者）。封裝還有一個好處，只要介面固定，內部實作是可以隨便改變的。你的版本裡初始化是
ctx = _RequestContext(self, environ)，在我安装的版本里（Flask==0.12）这行代码是ctx = RequestContext(self, environ)。虽然这里只是一个类名的简单变化，但是通过它我们可以明白，如果我们对RequestContext的實作或是初始化發生了變化，所有的呼叫方是不用改動的；不然的話，所有的呼叫方都要跟著修改。當然這裡封裝的內容只有一句，這些好處不是那麼明顯，甚至顯得我有點牽強附會。但我猜測，這是作者思考過的結果，因為
RequestContext是Flask 中比較重要的類，以後對它進行修改的可能性很大（增加一些屬性、改變初始化的參數等），把它封裝一層，可以輕鬆應對未來可能的變化。畢竟，軟體工程一個重要的事情就是應對變化。這就是物件導向的成員變數是否對外可見的問題了，這裡操作的是類別的成員變數的成員變量，不適合直接取得。
可以參考一下property，你覺得property的優勢在哪裡？
明顯的就是當你所需要的屬性不是直接獲得而是透過計算獲得的話只需要修改屬性的獲取方法就可以了。