[Python-Dev] Exact date of Python 2 EOL?
Hi, I looked at the "Status of Python branches" to check if it was up to date. It's the case, thanks :-) But it recalled me that no exact date was decided for the official end of line of the the Python 2 branch (2.7 EOL). https://docs.python.org/devguide/#status-of-python-branches says January 1st, 2020 https://pythonclock.org/ picked April 12th, 2020 (Pycon US) "Python 2.7 will not be maintained past 2020. No official date has been given, so this clock counts down until April 12th, 2020, which will be roughly the time of the 2020 PyCon. I am hereby suggesting we make PyCon 2020 the official end-of-life date, and we throw a massive party to celebrate all that Python 2 has done for us. (If this sounds interesting to you, email [email protected])." Can we pick an official date? By the way, maybe we can also start to list vendors (Linux vendors?) who plan to offer commercial extended support? For example, you can expect longer support than 2020 from RHEL: https://access.redhat.com/support/policy/updates/errata Ubuntu 12.04 reached its end of life after 5 years, but it seems like Canonical also starts to offer extended support to customers: http://www.omgubuntu.co.uk/2017/03/ubuntu-12-04-esm-support You can expect longer Python 2 support indirectely ;-) Victor ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 3.5 unittest does not support namespace packages for discovering
Hello. I have following layout: \---tests | test_module.py | __init__.py When I launch "python.exe" -m unittest discover -t . -s tests" it works perfectly. But when I remove " __init__.py" it says Start directory is not importable: "tests'" ``loader.py``: if start_dir != top_level_dir: is_not_importable = not os.path.isfile(os.path.join(start_dir, '__init__.py')) I believe ``__init__.py`` does not play any role since Python 3.3, am I right? If so, it seems to be a bug. Should I create an issue? Ilya. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3.5 unittest does not support namespace packages for discovering
There is already http://bugs.python.org/issue29642 On Thu, Mar 23, 2017 at 11:04 PM, Ilya Kazakevich wrote: > Hello. > I have following layout: > > \---tests > | test_module.py > | __init__.py > > > When I launch "python.exe" -m unittest discover -t . -s tests" it works > perfectly. > But when I remove " __init__.py" it says > > Start directory is not importable: "tests'" > > ``loader.py``: > if start_dir != top_level_dir: > is_not_importable = not os.path.isfile(os.path.join(start_dir, > '__init__.py')) > > > I believe ``__init__.py`` does not play any role since Python 3.3, am I > right? > If so, it seems to be a bug. Should I create an issue? > > Ilya. > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/songofacandy%40gmail.com > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3.5 unittest does not support namespace packages for discovering
And this issue is relating to it too: http://bugs.python.org/issue29716 In short, "namespace package" is for make it possible to `pip install foo_bar foo_baz`, when foo_bar provides `foo.bar` and foo_baz provides `foo.baz` package. (foo is namespace package). If unittests searches normal directly, it may walk deep into very large tree containing millions of directories. I don't like it. On Fri, Mar 24, 2017 at 12:53 AM, INADA Naoki wrote: > There is already http://bugs.python.org/issue29642 > > On Thu, Mar 23, 2017 at 11:04 PM, Ilya Kazakevich > wrote: >> Hello. >> I have following layout: >> >> \---tests >> | test_module.py >> | __init__.py >> >> >> When I launch "python.exe" -m unittest discover -t . -s tests" it works >> perfectly. >> But when I remove " __init__.py" it says >> >> Start directory is not importable: "tests'" >> >> ``loader.py``: >> if start_dir != top_level_dir: >> is_not_importable = not os.path.isfile(os.path.join(start_dir, >> '__init__.py')) >> >> >> I believe ``__init__.py`` does not play any role since Python 3.3, am I >> right? >> If so, it seems to be a bug. Should I create an issue? >> >> Ilya. >> >> ___ >> Python-Dev mailing list >> [email protected] >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> https://mail.python.org/mailman/options/python-dev/songofacandy%40gmail.com >> ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exact date of Python 2 EOL?
By the way, maybe we can also start to list vendors (Linux vendors?) who plan to offer commercial extended ... Delurking ever so briefly... Might be worthwhile to list published vendor EOL dates no matter if they are before or after the 2020 EOL date. Different Linux distros have different focuses. This could very well be a useful gauge for potential users. Skip ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exact date of Python 2 EOL?
On Mar 23, 2017, at 09:41 AM, Victor Stinner wrote: >Can we pick an official date? Benjamin should pick the date and update PEP 373. >Ubuntu 12.04 reached its end of life after 5 years, but it seems like >Canonical also starts to offer extended support to customers: >http://www.omgubuntu.co.uk/2017/03/ubuntu-12-04-esm-support Ubuntu 14.04 and 16.04 both have Python 2.7 so those will be supported until 2019 and 2021 respectively. I'm still hoping to relegate 2.7 to universe for 18.04 LTS. I don't think we'll be able to drop it entirely (nor should we). If it stays in main, it will get official support until 2023. https://www.ubuntu.com/info/release-end-of-life Cheers, -Barry ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exact date of Python 2 EOL?
On Thu, Mar 23, 2017 at 12:19 PM, Barry Warsaw wrote: > On Mar 23, 2017, at 09:41 AM, Victor Stinner wrote: > >>Can we pick an official date? > > Benjamin should pick the date and update PEP 373. Not to start a bikeshed (calendarshed?), but how about 8 February 2020, or 2/8 as some in the US would write it? ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exact date of Python 2 EOL?
On 23Mar2017 0937, Brian Curtin wrote: On Thu, Mar 23, 2017 at 12:19 PM, Barry Warsaw wrote: On Mar 23, 2017, at 09:41 AM, Victor Stinner wrote: Can we pick an official date? Benjamin should pick the date and update PEP 373. Not to start a bikeshed (calendarshed?), but how about 8 February 2020, or 2/8 as some in the US would write it? Whatever date is it will have to have a release on it. There's no point in taking fixes after the final release, and I'd suggest that given it is the last one that we'll want a longer RC period with RM approval required for any changes after that. (I predict a slight chance of a last minute rush to get contribution made - possibly it's worth locking things down from the second-to-last release?) All of which to say, there are more important concerns than choosing a cute date :) I've got no doubt that Benjamin will come up with a plan that leads to a stable and reliable release. Cheers, Steve ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exact date of Python 2 EOL?
On Mar 23, 2017, at 04:41, Victor Stinner wrote: > By the way, maybe we can also start to list vendors (Linux vendors?) > who plan to offer commercial extended support? IMO, we should definitely not list 2.7 vendor and their plans on a python.org web page. One, it would be a maintenance headache for the web site / devguide. Two, it puts us and the PSF in the position of curating such a list and deciding who get to be on it and in what order and with keeping up with vendors' changing plans etc etc. Third, most likely they are already using a particular vendor so they are not likely to change just because of Python 2 support. And, fourth and most important, we don't really want to be encouraging people to stay on 2.7 anyway! If it is important enough for them, they can do their research and find out directly from the vendors. -- Ned Deily [email protected] -- [] ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exact date of Python 2 EOL?
On 3/23/2017 4:41 AM, Victor Stinner wrote: Hi, I looked at the "Status of Python branches" to check if it was up to date. It's the case, thanks :-) But it recalled me that no exact date was decided for the official end of line of the the Python 2 branch (2.7 EOL). > https://docs.python.org/devguide/#status-of-python-branches > says January 1st, 2020 Can we pick an official date? The devguide list is effectively the official list. No one should plan on getting anything from pydev after 1/1/20. As far as ''we' are concerned, 2.7 EOL will be when the final 2.7.n release is made. If Benjamin continues twice-a-year releases, n could be 20 in mid 2020, about 10 years after 2.7.0 in 2010-7-3. Or perhaps he will push a possible 2.7.19 'Dec 2019' release to 2020-01-01. Especially if the rate of commits decreases, he might lengthen the interval, thereby reducing the final ''n'. In the meanwhile, I think we should let him continue planning one release ahead. https://www.python.org/dev/peps/pep-0373/ Planned future release dates: 2.7.14 in mid 2017 -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3.5 unittest does not support namespace packages for discovering
On 24 March 2017 at 04:59, INADA Naoki wrote: > And this issue is relating to it too: http://bugs.python.org/issue29716 > > In short, "namespace package" is for make it possible to `pip install > foo_bar foo_baz`, > when foo_bar provides `foo.bar` and foo_baz provides `foo.baz` > package. (foo is namespace package). > > If unittests searches normal directly, it may walk deep into very > large tree containing > millions of directories. I don't like it. That is a risk, OTOH I think the failure to do what folk expect is a bigger risk. -Rob ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exact date of Python 2 EOL?
On 2017-03-23 16:37, Brian Curtin wrote: On Thu, Mar 23, 2017 at 12:19 PM, Barry Warsaw wrote: On Mar 23, 2017, at 09:41 AM, Victor Stinner wrote: Can we pick an official date? Benjamin should pick the date and update PEP 373. Not to start a bikeshed (calendarshed?), but how about 8 February 2020, or 2/8 as some in the US would write it? If you see 2/8, is that 2 August or February 8? We could avoid ambiguity if day_of_month == month or day_of_month > 12. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3.5 unittest does not support namespace packages for discovering
On 3/23/17 3:14 PM, Robert Collins wrote: > On 24 March 2017 at 04:59, INADA Naoki wrote: >> And this issue is relating to it too: http://bugs.python.org/issue29716 >> >> In short, "namespace package" is for make it possible to `pip install >> foo_bar foo_baz`, >> when foo_bar provides `foo.bar` and foo_baz provides `foo.baz` >> package. (foo is namespace package). >> >> If unittests searches normal directly, it may walk deep into very >> large tree containing >> millions of directories. I don't like it. > That is a risk, OTOH I think the failure to do what folk expect is a > bigger risk. The issue here is, what do folks expect? PEP 420 is pretty clear on its purpose. The first sentence of the abstract: > Namespace packages are a mechanism for splitting a single Python package across multiple directories on disk. And the first sentence of the specification: > Regular packages will continue to have an __init__.py and will reside in a single directory. PEP 420 is not meant to make all __init__.py files optional. It has a specific purpose. These proposed changes are not in support of that purpose. We should not bend over backwards to support getting rid of __init__.py files just because people don't like empty __init__.py files. That's not what PEP 420 is for. --Ned. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exact date of Python 2 EOL?
On Thu, 23 Mar 2017 09:41:11 +0100 Victor Stinner wrote: > Hi, > > I looked at the "Status of Python branches" to check if it was up to > date. It's the case, thanks :-) But it recalled me that no exact date > was decided for the official end of line of the the Python 2 branch > (2.7 EOL). > > https://docs.python.org/devguide/#status-of-python-branches > says January 1st, 2020 > > https://pythonclock.org/ picked April 12th, 2020 (Pycon US) I suggest we pick April 1st, 2020, so as to extra confuse users who are still on Python 2 ;-) Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3.5 unittest does not support namespace packages for discovering
On 23 March 2017 at 20:41, Ned Batchelder wrote: >>> If unittests searches normal directly, it may walk deep into very >>> large tree containing >>> millions of directories. I don't like it. > >> That is a risk, OTOH I think the failure to do what folk expect is a >> bigger risk. > > The issue here is, what do folks expect? PEP 420 is pretty clear on its > purpose. The unittest docs say (https://docs.python.org/3.6/library/unittest.html#test-discovery) """ Unittest supports simple test discovery. In order to be compatible with test discovery, all of the test files must be modules or packages (including namespace packages) importable from the top-level directory of the project (this means that their filenames must be valid identifiers). """ Personally, that to me pretty clearly implies that namespace packages *should* work. They are explicitly mentioned, after all. I agree that the implication that any random directory will get scanned is unexpected - after all *I* know which directories I intended to be namespace packages, it's just the computer that doesn't. Either way, someone is likely to get surprised. But I'd argue that if we retain the current __init__.py check, we need to amend the docs - and that's then a change in the documented behaviour. I do think it's a relatively minor point either way, and practicality may well imply that we're better avoiding the risk of discovery being impractical in projects with large directories full of resource files or similar. But on the expectation side of things, I'd consider the current behaviour as unexpected. Paul ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exact date of Python 2 EOL?
On Mar 23, 2017, at 08:02 PM, MRAB wrote: >If you see 2/8, is that 2 August or February 8? I think that's 0.25 which doesn't look like a date to me . ISO 8601 dates please: 2020-02-08 is unambiguous. -Barry ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exact date of Python 2 EOL?
On 23 March 2017 at 19:47, Barry Warsaw wrote: > On Mar 23, 2017, at 08:02 PM, MRAB wrote: > >>If you see 2/8, is that 2 August or February 8? > > I think that's 0.25 which doesn't look like a date to me . ISO 8601 > dates please: 2020-02-08 is unambiguous. In Python 2, 2/8 is just 0. > > -Barry > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/jsbueno%40python.org.br ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exact date of Python 2 EOL?
Le 23 mars 2017 19:56, "Terry Reedy" a écrit : > https://docs.python.org/devguide/#status-of-python-branches > says January 1st, 2020 Can we pick an official date? > The devguide list is effectively the official list. No one should plan on getting anything from pydev after 1/1/20. Oh sorry, I forgot to mention that *I* wrote this table. I chose this date just to fill quickly the table. But I now would like a precise date to prevent future confusion. Victor ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exact date of Python 2 EOL?
: On Thu, 2017-03-23 at 21:08 -0300, Joao S. O. Bueno wrote: > In Python 2, 2/8 is just 0. 27/7 is 3 in Python 2, and between 3.8 and 3.9 in Python 3 (which is probably about where 3.x will be). -[]z. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exact date of Python 2 EOL?
On 24 March 2017 at 02:19, Barry Warsaw wrote: > On Mar 23, 2017, at 09:41 AM, Victor Stinner wrote: > > >Can we pick an official date? > > Benjamin should pick the date and update PEP 373. > +1. The other detail to be clarified is that we know 2020-MM (whatever MM ends up being) will be the last upstream 2.7.x binary release (so the security-updates-for-bundled-OpenSSL problem will go away), but we haven't decided yet how other security updates after that point will be handled. If It's just RHEL/CentOS (and maybe Software Collections) keeping the branch alive past the upstream end-of-community-support date it's not a big deal, but if there are other redistributors or folks running self-supported binaries still monitoring it for security updates, then it may make sense to continue putting any required security patches in a common location, even if we stop doing any new upstream releases. > I'm still hoping to relegate 2.7 to universe for 18.04 LTS. I don't think > we'll be able to drop it entirely (nor should we). If it stays in main, it > will get official support until 2023. > > https://www.ubuntu.com/info/release-end-of-life > As far as I'm aware, Samba is the main remaining challenge for Fedora Server on that front, but at least all of the libraries it depends on have received the necessary updates to make them Python 2/3 compatible: http://fedora.portingdb.xyz/pkg/samba/ Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exact date of Python 2 EOL?
On 24 March 2017 at 02:59, Ned Deily wrote: > On Mar 23, 2017, at 04:41, Victor Stinner > wrote: > > By the way, maybe we can also start to list vendors (Linux vendors?) > > who plan to offer commercial extended support? > > IMO, we should definitely not list 2.7 vendor and their plans on a > python.org web page. One, it would be a maintenance headache for the web > site / devguide. Two, it puts us and the PSF in the position of curating > such a list and deciding who get to be on it and in what order and with > keeping up with vendors' changing plans etc etc. Third, most likely they > are already using a particular vendor so they are not likely to change just > because of Python 2 support. And, fourth and most important, we don't > really want to be encouraging people to stay on 2.7 anyway! If it is > important enough for them, they can do their research and find out directly > from the vendors. > Agreed, although I'd be open to maintaining such a list in my Python 3 Q&A at http://python-notes.curiousefficiency.org/en/latest/python3/questions_and_answers.html That's explicitly caveated as being both from my personal perspective and only intermittently updated. It also already mentions the 2024 date, since that comes from RHEL 7's 2014 release date and 10 year support cycle. All the other commercial support end dates we know for certain at this point finish before 2020, with Canonical being a "maybe" on 2023 (depending on what happens in Ubuntu 18.04). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
