classification
Title: open(): remove 'U' mode, deprecated since Python 3.3
Type: Stage: resolved
Components: Library (Lib) Versions: Python 3.9
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: Anthony Sottile, abartlet, miss-islington, pitrou, serhiy.storchaka, vstinner
Priority: normal Keywords: patch

Created on 2019-06-18 15:48 by vstinner, last changed 2020-03-04 17:50 by vstinner. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 14204 closed vstinner, 2019-06-18 16:06
PR 16959 merged vstinner, 2019-10-27 15:49
PR 16972 merged vstinner, 2019-10-28 22:09
PR 16982 merged miss-islington, 2019-10-29 09:33
PR 18767 merged vstinner, 2020-03-03 15:20
Messages (19)
msg345991 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-06-18 15:48
The builtin open() function accepts 'U' in the file mode, but it emits a DeprecationWarning since Python 3.4, change made in bpo-15204:

commit 6787a3806ee6a85a6f21ede70c10e15a6df267c4
Author: Serhiy Storchaka <storchaka@gmail.com>
Date:   Sat Nov 23 22:12:06 2013 +0200

    Issue #15204: Deprecated the 'U' mode in file-like objects.

$ cat x.py 
f = open(__file__, 'U')
line = f.readline()
print(type(line))
f.close()

$ python3.7 x.py 
x.py:1: DeprecationWarning: 'U' mode is deprecated
  f = open(__file__, 'U')
<class 'str'>

The 'U' mode is documented as deprecated since Python 3.3

The flag is basically only there for backward compatibility with Python 2. Python 3.9.0 final release is currently scheduled at 2020-06-08: 6 months after Python 2 end-of-life (2020-01-01).

Currently, the 'U' mode is documented as it will be removed from Python 4.0. But I dislike having a bunch of backward incompatible changes in Python 4.0. I would prefer Python 4.0 to be simply the version after Python 3.X.

Deprecation warnings are now displayed in the __main__ module by default, thanks to the PEP 565 -- Show DeprecationWarning in __main__.
https://www.python.org/dev/peps/pep-0565/

More and more projects run their test suite using -Werror and so have to fix deprecation warnings.
msg345995 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-06-18 16:07
I prefer to push backward incompatible changes at the beginning of a dev cycle (Python 3.9), so we have room to revert it later if it causes too much trouble.
msg346219 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-06-21 14:01
I reported the issue to docutils. In fact, docutils FileInput class was already fixed to prevent the deprecation warning, but there was no release yet:
https://sourceforge.net/p/docutils/bugs/363/
msg348007 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-07-16 08:59
docutils is already fixed in the development version. I requested a release:
https://sourceforge.net/p/docutils/bugs/364/
msg355479 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-10-27 16:17
I cited this change in the PEP 608 "Coordinated Python release".
msg355543 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-10-28 14:40
New changeset e471e72977c83664f13d041c78549140c86c92de by Victor Stinner in branch 'master':
bpo-37330: open() no longer accept 'U' in file mode (GH-16959)
https://github.com/python/cpython/commit/e471e72977c83664f13d041c78549140c86c92de
msg355544 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-10-28 14:40
Thanks for the review Serhiy ;-)
msg355573 - (view) Author: Anthony Sottile (Anthony Sottile) * Date: 2019-10-28 17:28
should we backport a documentation change for this? (the deprecatedremoved says 4.0 currently)
msg355633 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-10-29 09:32
New changeset 1d2862a323ae1387e306942253b1e487018e2b7f by Victor Stinner in branch '3.8':
bpo-37330: open(): "U" mode is removed in Python 3.9 (GH-16972)
https://github.com/python/cpython/commit/1d2862a323ae1387e306942253b1e487018e2b7f
msg355635 - (view) Author: miss-islington (miss-islington) Date: 2019-10-29 09:38
New changeset 4cb08b6c0ae6989d169dd48c2b24087941f6d0b0 by Miss Skeleton (bot) in branch '3.7':
bpo-37330: open(): "U" mode is removed in Python 3.9 (GH-16972)
https://github.com/python/cpython/commit/4cb08b6c0ae6989d169dd48c2b24087941f6d0b0
msg355636 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-10-29 09:40
> should we backport a documentation change for this? (the deprecatedremoved says 4.0 currently)

Done. Thanks for the reminder.
msg362362 - (view) Author: Andrew Bartlett (abartlet) Date: 2020-02-20 22:54
This breaks Samba's build:

https://bugzilla.samba.org/show_bug.cgi?id=14266

While we are of course able to patch new versions of Samba, this will make it harder to bisect back though Samba history.  It would be really great if this kind of change could be reverted or at least deferred so Samba can rely on a stable language platform for it's build system.
msg363194 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2020-03-02 17:45
> While we are of course able to patch new versions of Samba, this will make it harder to bisect back though Samba history.

I don't understand the bisect part. Would you mind to elaborate? What do you want to bisect?

>  It would be really great if this kind of change could be reverted or at least deferred so Samba can rely on a stable language platform for it's build system.

The "U" mode was deprecated since September 2012 (Python 3.3): you had 8 years to handle the DeprecationWarning. 8 years before actually removing a deprecated feature sounds like a stable language platform to me.

I'm not sure of the benefit of deferring the change. Does it mean that Sambda would not be updated?

Well, your comment fits exactly into bpo-39674 scope, except that revert the "U" mode is not scheduled yet.
msg363211 - (view) Author: Andrew Bartlett (abartlet) Date: 2020-03-02 21:37
Thanks for the reply.

To clarify, it is best to understand where Samba thinks of itself in terms of Python.  We use python, but we don't really think of ourselves as a python project, and while we have some developers with a depth of experience in the language, most of us just use it as a tool to get things done, in particular to build Samba.

Samba has a build system built in Python, called Waf.  Samba uses waf to build the project (particularly the C parts), and our build of the C binaries is portable back to Python 2.6.  

Often in Samba we find bugs.  This might come as a shock! ;-).  Many of those bugs are regressions, and so it is useful to build old versions, sometimes 7 year old versions, to confirm if/when the behaviour regressed.  We are able to do this, with only one patch to address a perl behaviour change, even on a modern Ubuntu 18.04 system, all the way back to 2013.  

I terms of 'but this has been deprecated for years', Samba has only had releases been able to even use Python3 in the build system for a year (first committed to master in July 2018).

Nobody in Samba was aware of any DeprecationWarning and for better or worse we only knew about the issue once our builds failed in Fedora.  We are incredibly grateful that Fedora tried a rebuild with the alpha version of Python 3.9 as otherwise we would find out only after this was well baked into a release.

Thankfully we don't need universal newlines, but no matter if we need them, old versions of Samba will fail to build without a fix-up patch.

More importantly, I think it is unlikely that Samba is the only software to have used this feature, intentionally or otherwise, or to be in this position.  

While not as critical here, for context as to why we support Python 2.6 to build, it should be noted that retaining this compatibility was a critical part of being able to get consensus to otherwise move to Python 3.4.
msg363247 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2020-03-03 09:15
> Thankfully we don't need universal newlines, but no matter if we need them, old versions of Samba will fail to build without a fix-up patch.

io.open() is available since Python 2.6 and handles different kinds of newlines transparently. Example:

$ python2
Python 2.7.17 (default, Oct 20 2019, 00:00:00) 
>>> f=open("test", "wb"); f.write("a\rb\rc\r"); f.close()
>>> import io; f=io.open("test"); lines=list(f); f.close(); lines
[u'a\n', u'b\n', u'c\n']

Do you suggest to change the documentation to suggest to open io.open() for applications which still care about Python 2?
https://docs.python.org/dev/whatsnew/3.9.html#changes-in-the-python-api

Note: Python 2 is no longer supported upstream, I strongly advice you to upgrade to Python 3.
msg363320 - (view) Author: Andrew Bartlett (abartlet) Date: 2020-03-04 02:01
I think we are speaking past each other. 

Yes, Python 2 is no longer being changed, which is awesome as we need for fear breakage of the older builds that use that for the build system.

The issue isn't the particular language feature, or that there is no way to further adapt code, but that a valid build script that operates correctly on Python 3.8 will no longer, without warning to us, operate on Python 2.9 or at best 2.10. 

Thankfully the only Samba versions with support for Python3 are still in maintenance, so course I've back-ported patches to the tip of each release branch to work around this change.  But again, that doesn't help when I need to build an arbitrary git revision in the future. 

(That warnings were available, if we knew were to look, is an entirely moot point at this stage).
msg363321 - (view) Author: Andrew Bartlett (abartlet) Date: 2020-03-04 02:02
...Python 2.9 or at best 2.10. 

Of course I mean Python 3.9 or at best 3.10. 

Sorry for the confusion.
msg363344 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2020-03-04 13:08
Le mer. 4 mars 2020 à 03:01, Andrew Bartlett <report@bugs.python.org> a écrit :
> (...) but that a valid build script that operates correctly on Python 3.8 will no longer, without warning to us, (...)

Displaying warnings by default or not is an old debate.

I added the "Python Development Mode" (-X dev) to help the situation:

https://docs.python.org/dev/library/devmode.html#devmode

I just added a very explicit "You should check for DeprecationWarning in your code" section in What's New In Python 3.9:

https://docs.python.org/dev/whatsnew/3.9.html#you-should-check-for-deprecationwarning-in-your-code

Moreover, DeprecationWarning are now (Python 3.7) displayed *by default* in the __main__ module:
https://www.python.org/dev/peps/pep-0565/
msg363366 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2020-03-04 17:50
New changeset 942f7a2dea2e95a0fa848329565c0d0288d92e47 by Victor Stinner in branch 'master':
bpo-39674: Revert "bpo-37330: open() no longer accept 'U' in file mode (GH-16959)" (GH-18767)
https://github.com/python/cpython/commit/942f7a2dea2e95a0fa848329565c0d0288d92e47
History
Date User Action Args
2020-03-04 17:50:25vstinnersetmessages: + msg363366
2020-03-04 13:08:41vstinnersetmessages: + msg363344
2020-03-04 02:02:19abartletsetmessages: + msg363321
2020-03-04 02:01:25abartletsetmessages: + msg363320
2020-03-03 15:20:46vstinnersetpull_requests: + pull_request18125
2020-03-03 09:15:47vstinnersetmessages: + msg363247
2020-03-02 21:37:22abartletsetmessages: + msg363211
2020-03-02 17:45:02vstinnersetmessages: + msg363194
2020-02-20 22:54:33abartletsetnosy: + abartlet
messages: + msg362362
2019-10-29 09:40:22vstinnersetmessages: + msg355636
2019-10-29 09:38:41miss-islingtonsetnosy: + miss-islington
messages: + msg355635
2019-10-29 09:33:08miss-islingtonsetpull_requests: + pull_request16508
2019-10-29 09:32:51vstinnersetmessages: + msg355633
2019-10-28 22:09:45vstinnersetpull_requests: + pull_request16499
2019-10-28 17:28:33Anthony Sottilesetnosy: + Anthony Sottile
messages: + msg355573
2019-10-28 14:40:57vstinnersetstatus: open -> closed
resolution: fixed
messages: + msg355544

stage: patch review -> resolved
2019-10-28 14:40:21vstinnersetmessages: + msg355543
2019-10-27 16:17:16vstinnersetmessages: + msg355479
2019-10-27 15:49:30vstinnersetpull_requests: + pull_request16487
2019-07-16 08:59:25vstinnersetmessages: + msg348007
2019-06-21 14:01:07vstinnersetmessages: + msg346219
2019-06-18 16:07:56vstinnersetmessages: + msg345995
2019-06-18 16:07:08vstinnersetnosy: + pitrou
2019-06-18 16:06:58vstinnersetkeywords: + patch
stage: patch review
pull_requests: + pull_request14042
2019-06-18 15:48:25vstinnercreate