uio – 输入/输出流¶
该模块实现相应CPython模块的子集，如下所示。更多信息，请参见
|CPython文档| python:io.
该模块包含其他类型的流(类文件)对象和辅助函数。
层次结构¶
与CPython区别
正如在本部分中所述，流基类的概念层次结构在MicroPython中简化。
（摘要）基流类作为所有具体类行为的基础，在CPython中保持较少的二排序（两两排序法）。在MicroPython中，基流类被简化并隐藏以提高效率和节省资源。
CPython中一个重要的二分法是无缓冲对缓冲流。在MicroPython 中，所有流目前都未缓冲。这是因为所有现代操作系统， 甚至许多实时操作系统和文件系统驱动程序都已在侧面执行了缓冲。添加另一缓冲层会产生相反效果（称为“缓冲过满”的问题）， 且需占用宝贵的内存。注意：在某些情况下，缓冲可能有用，因此我们会在后面介绍一些可供选择的缓冲支持。
但是在CPython中，另一个重要二分法是与“缓冲性”联系在一起的，即流是否会引发短读/短写。短读即当用户从流中请求10个字节时， 但是所得少于该数量，短写与之相似。在CPython中，未缓冲流会自动进行短操作，而缓冲是对其的保证。非短读/写是一个重要特性， 由此我们得以开发更简洁高效的程序—非常适合MicroPython的程序。因此，尽管MicroPython不支持缓冲流，但仍适合非短操作流。 是否有短操作取决于每个特定类的需求，但是出于上述原因，强烈建议开发人员支持非短操作的行为。例如： MicroPython套接字就确保避免短 读/写。实际上，此时在核心中并无短操作流类的示例，一例是特定于端口的类，在这种情况下需由硬件特性来控制需求。
非短操作行为在非阻塞流情况会很棘手，阻塞对非阻塞的行为为CPython的另一种二分法，并受MicroPython完全支持。 非阻塞流不会等待数据到达或写入—而会读取/写入任何可能的数据或标记数据的缺乏（或写入数据的能力）。显而易见， 这与“非短操作”的方法相矛盾。的确，在CPython中，非阻塞缓冲流的情况非常复杂。在某些地方，这种结合是被禁止的； 在某些地方，未给出明定义或没有文档说明；在某些情况下。会引发较为复杂的异常。在MicroPython中，情况就简单多了： 非阻塞流对高效的异步操作至关重要，因此这一特性在“非短期操作”中占优先地位。所以，阻塞流会在任何情况下都尽可能避免短读/短写 （短读仅在到达文件末尾或发产生误差时出现（但是误差不会返回短数据，而会引发异常）），非阻塞流会产生短数据以避免阻碍操作。
最后一种二分法是二进制vs文本流。MicroPython支持这两种形式，但是在CPython中，文本流本质上就是缓冲的，它们并不在MicroPython中。（实际上，这就是我们引入缓冲支持的情况之一。）
注意：为提高效率，MicroPython不提供与以上层次结构相对应的抽象基类，并且不可能实现纯Python中的流类或将之归入子类。
函数¶
-
uio.open(name, mode='r', **kwargs)¶ 打开一个文件。内置的
open()函数是该函数的别名。所有端口（提供对文件系统的访问）都需支持模式参数，但是对于其他参数的支持因端口不同而不同。