这是一个设计的和品位的问题，而不是一个技术问题。

就拿你举的这个例子来说，我们看到这里有一层封装，但是因为封装的内容太过于简单，所以让你疑惑是否有这个必要。要回答这个问题，我们要想想为什么会有封装？不管是函数也好，类也好，我们定义它们可能是因为以下原因：

• 它们提供了逻辑上的某个功能，便于我们理解

• 这段逻辑是会被经常调用到的，为了避免重复（DRY原则），我们把它抽象出来

这个例子是符合上面这两条的：flask 需要一个创建 application context 的功能，并且是在多处会用到它。

➜ flask grep "\.request_context" -rin . ./app.py:1918: with app.request_context(environ): ./app.py:1925: ctx = app.request_context(environ) ./app.py:1948: return self.request_context(builder.get_environ()) ./app.py:1977: ctx = self.request_context(environ)

另外一个好处是，RequestContext算是比较内部的一个类，大多数情况下用户不会（也不应该）直接使用它。而为了让用户可以创建这个类的对象，作者封装了Flask.request_context()方法，算是最小接口原则（尽量提供最小的接口给用户）。

封装还有一个好处，只要接口固定，内部实现是可以随便更改的。你的版本里初始化是ctx = _RequestContext(self, environ)，在我安装的版本里（Flask==0.12）这行代码是ctx = RequestContext(self, environ)。虽然这里只是一个类名的简单变化，但是通过它我们可以明白，如果我们对RequestContext的实现或者初始化发生了变化，所有的调用方是不用改动的；不然的话，所有的调用方都要跟着修改。

当然这里封装的内容只有一句，这些好处不是那么明显，甚至显得我有点牵强附会。但是我猜测，这是作者思考过的结果，因为RequestContext是 Flask 中比较重要的类，以后对它进行修改的可能性很大（增加一些属性、改变初始化的参数等），把它封装一层，可以轻松应对未来可能的变化。毕竟，软件工程一个重要的事情就是应对变化。

这就是面向对象的成员变量是否对外可见的问题了，这里操作的是类的成员变量的成员变量，不适合直接获取。
可以参考一下property，你觉得property的优势在哪里？
明显的就是当你所需要的属性不是直接获得而是通过计算获得的话只需要修改属性的获取方法就可以了。