-
-
Notifications
You must be signed in to change notification settings - Fork 30.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deprecate the 'U' open mode #59409
Comments
Since Python 2.3 many open functions supports "Universal line mode" (PEP-278). Since 3.0 (and 2.6) PEP-3116 suggests better alternative -- io.TextWrapper. Now support for the 'U' mode in the different open functions is heterogeneous. Some functions simply ignore the 'U' mode (but accept it), others perceive it as a synonym for text-mode, others just pass it on lower lever, other attempt to implement it, but the implementation is obtained imperfect and contradictory (as in ZipExtFile). The documentation for built-in open does not advise the use of the 'U' mode. The 'U' mode support cumbersome. I propose to deprecate the 'U' mode. If someone wanted to work with the universal line support, he'll surely need to work with encodings too, and io.TextWrapper provides is better choise. The deprecation plan for the 'U' mode of open functions might be as follow: 3.3. Deprecating the 'U' mode in docs for all opens (building open, io.open, codecs.open, gzip.open, ZipFile.open, etc). Add suggestion about io.TextWrapper. As the first stage involves only the changes to the documentation, I hope deprecation can starts in 3.3. |
Starting to deprecate "U" in the 3.3 docs sounds reasonable to me. |
Unless there are places where it is actually broken, I don't think there is a good reason to have step 3.5, though. Just add the deprecation warning and remove it in 4.0. |
Well. In any case, the 'U' mode in most cases has no effect, and the Here are the patches for the first (documentation) and the second stage |
+1 for the general idea of deprecating and eventually removing the "U" But I agree with David, that it doesn't make sense to have separate steps |
The only people affected by deprecating "U" are the people who are currently using it for some reason -- presumably they are expecting that it does something useful for their code. Ideally, this proposed deprecation should be mentioned on python-dev so that those folks will have an opportunity to respond. |
|
Chris, you did a great job on improving the documentation (including about universal newlines). Can you help with this issue? For the first stage should be clearly shown that "U" mode is not only should not be used in new code, but must be removed from the old code. Stage 1 patch updated to resolve conflicts with Chris changes. |
Thanks, Serhiy. :) Sure, I should be able to help with the documentation portion of this issue if the community is in agreement. Would the deprecation need to be moved up to 3.4 though now? |
Yes, I think so. |
Here is an updated patch. I think we can combine 1 and 2 stages (change the documentation and add warnings). |
http://bugs.python.org/review/15204/diff/9032/Tools/iobench/iobench.py Line 10 in New: But io module is never used. |
Could anyone please review the patch? |
Updated patch addresses Victor's comments. |
Updated patch addresses Ezio's comments. |
New changeset 70bd6f7e013b by Serhiy Storchaka in branch 'default': |
Thanks Victor and Ezio for the reviews. |
New changeset 694e2708b4a8 by Serhiy Storchaka in branch 'default': |
New changeset 2d5544afb510 by R David Murray in branch 'default': |
open() documentation is probably broken a little now. Here is what one can see at the end of open() description: The 'U' mode." Reader may assume open() function is what will be removed. Which is frightening :) |
Please open new issue for this. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: