Re: [Python-Dev] Slow down...
On Wed, 9 May 2018 14:25:06 +1000 Steven D'Aprano wrote: > On Mon, May 07, 2018 at 10:23:32PM +0200, Antoine Pitrou wrote: > > On Mon, 07 May 2018 19:19:28 + > > Ryan Gonzalez wrote: > > > 10 years feels like a simultaneously long and arbitrary limit. IMO a > > > policy > > > of "try to avoid major language features for a while" would work better. > > > > I would remove "for a while". "Try to avoid major language features" > > sounds good. > > It sounds good, until you ask about "What if we had that policy from > the beginning?" > > Let's see what sort of language features we would miss out on if we > avoided language features because there was an existing alternative: [...] "Try to avoid" would make it more of a general guideline than a hard rule, IMHO. I proposed the idea in another thread that Python had reached "peak syntax" and maybe it was time to consider the core language essentially mature. Of course, we don't know what the future will bring and perhaps some fundamentally new programming idiom will appear in the next years that deserve implementing in Python. 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] Slow down...
On Wed, May 09, 2018 at 01:35:53PM +0200, Antoine Pitrou wrote: > > > I would remove "for a while". "Try to avoid major language features" > > > sounds good. > > > > It sounds good, until you ask about "What if we had that policy from > > the beginning?" [...] > "Try to avoid" would make it more of a general guideline than a hard > rule, IMHO. Fair enough. But it really depends on how hard we try: too hard, or not hard enough? *wink* -- 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] Slow down...
09.05.18 14:35, Antoine Pitrou пише: I proposed the idea in another thread that Python had reached "peak syntax" and maybe it was time to consider the core language essentially mature. Of course, we don't know what the future will bring and perhaps some fundamentally new programming idiom will appear in the next years that deserve implementing in Python. "If you want to add a new syntax feature, first remove two old syntax features." ___ 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] Slow down...
On Mon, May 7, 2018 at 10:21 AM, Glenn Linderman wrote: > On 5/7/2018 7:59 AM, Eric Snow wrote: > > On Sun, May 6, 2018 at 8:25 PM, Nick Coghlan wrote: > > I'm inclined to agree that a Python 3.8 PEP in the spirit of the PEP 3003 > language moratorium could be a very good idea. > > Note that the PEP specifically applies to "syntax, semantics, and > built-ins". Here's the full abstract [1]: > > This PEP proposes a temporary moratorium (suspension) of all changes to > the > Python language syntax, semantics, and built-ins for a period of > at least two > years from the release of Python 3.1. In particular, the moratorium > would > include Python 3.2 (to be released 18-24 months after 3.1) but allow > Python > 3.3 (assuming it is not released prematurely) to once again include > language > changes. > > This suspension of features is designed to allow non-CPython > implementations > to "catch up" to the core implementation of the language, help ease > adoption > of Python 3.x, and provide a more stable base for the community. > > -eric > > Here's my "lightning" response to a "lightning talk" about a moratorium: > > So if other implementations didn't catch up during the last moratorium, > either the moratorium then was lifted too soon, or the other implementations > don't really want to catch up, or the thought that they should catch up was > deemed less important than making forward progress with the language. Have > any of those opinions changed? Speaking as the maintainer of IronPython during the last moratorium: while catching up was certainly desirable, there simply wasn't enough person-power to do it any reasonable amount of time (I'm not sure any implementation besides PyPy even has yield-from, let alone async). Between fixing issues in 2.x branches, trying to implement 3.x features, and dealing with underlying platform churn I don't think even two years was ever realistic. Plus, every feature has to be considered with how it works in Python and the other platform (like, what sort of fun .NET interop can we do with type annotations?). Another moratorium would probably have the same (lack of) effect. Better, IMO, to just raise the bar on expensive features and let them catch up naturally. - Jeff ___ 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] [Python-checkins] bpo-33038: Fix gzip.GzipFile for file objects with a non-string name attribute. (GH-6095)
From: Serhiy Storchaka To: [email protected] Sent: Wednesday, 9 May 2018, 10:14 Subject: [Python-checkins] bpo-33038: Fix gzip.GzipFile for file objects with a non-string name attribute. (GH-6095) https://github.com/python/cpython/commit/afe5f633e49e0e873d42088ae56819609c803ba0 commit: afe5f633e49e0e873d42088ae56819609c803ba0 branch: 2.7 author: Bo Bayles committer: Serhiy Storchaka date: 2018-05-09T13:14:40+03:00 summary: bpo-33038: Fix gzip.GzipFile for file objects with a non-string name attribute. (GH-6095) files: A Misc/NEWS.d/next/Library/2018-03-10-20-14-36.bpo-33038.yA6CP5.rst M Lib/gzip.py M Lib/test/test_gzip.py M Misc/ACKS diff --git a/Lib/gzip.py b/Lib/gzip.py index 07c6db493b0b..76ace394f482 100644 --- a/Lib/gzip.py +++ b/Lib/gzip.py @@ -95,9 +95,8 @@ def __init__(self, filename=None, mode=None, if filename is None: # Issue #13781: os.fdopen() creates a fileobj with a bogus name # attribute. Avoid saving this in the gzip header's filename field. - if hasattr(fileobj, 'name') and fileobj.name != '': - filename = fileobj.name - else: + filename = getattr(fileobj, 'name', '') + if not isinstance(filename, basestring) or filename == '': filename = '' if mode is None: if hasattr(fileobj, 'mode'): mode = fileobj.mode diff --git a/Lib/test/test_gzip.py b/Lib/test/test_gzip.py index 902d93fe043f..cdb1af5c3d13 100644 --- a/Lib/test/test_gzip.py +++ b/Lib/test/test_gzip.py @@ -6,6 +6,7 @@ import os import io import struct +import tempfile gzip = test_support.import_module('gzip') data1 = """ int length=DEFAULTALLOC, err = Z_OK; @@ -331,6 +332,12 @@ def test_fileobj_from_fdopen(self): with gzip.GzipFile(fileobj=f, mode="w") as g: self.assertEqual(g.name, "") + def test_fileobj_from_io_open(self): + fd = os.open(self.filename, os.O_WRONLY | os.O_CREAT) + with io.open(fd, "wb") as f: + with gzip.GzipFile(fileobj=f, mode="w") as g: + self.assertEqual(g.name, "") + def test_fileobj_mode(self): gzip.GzipFile(self.filename, "wb").close() with open(self.filename, "r+b") as f: @@ -359,6 +366,14 @@ def test_read_with_extra(self): with gzip.GzipFile(fileobj=io.BytesIO(gzdata)) as f: self.assertEqual(f.read(), b'Test') + def test_fileobj_without_name(self): + # Issue #33038: GzipFile should not assume that file objects that have + # a .name attribute use a non-None value. + with tempfile.SpooledTemporaryFile() as f: + with gzip.GzipFile(fileobj=f, mode='wb') as archive: + archive.write(b'data') + self.assertEqual(archive.name, '') + def test_main(verbose=None): test_support.run_unittest(TestGzip) diff --git a/Misc/ACKS b/Misc/ACKS index 580b0c5bf76d..458f31e6a6b7 100644 --- a/Misc/ACKS +++ b/Misc/ACKS @@ -94,6 +94,7 @@ Michael R Bax Anthony Baxter Mike Bayer Samuel L. Bayer +Bo Bayles Donald Beaudry David Beazley Carlo Beccarini diff --git a/Misc/NEWS.d/next/Library/2018-03-10-20-14-36.bpo-33038.yA6CP5.rst b/Misc/NEWS.d/next/Library/2018-03-10-20-14-36.bpo-33038.yA6CP5.rst new file mode 100644 index ..22d394b85ab7 --- /dev/null +++ b/Misc/NEWS.d/next/Library/2018-03-10-20-14-36.bpo-33038.yA6CP5.rst @@ -0,0 +1,2 @@ +gzip.GzipFile no longer produces an AttributeError exception when used with +a file object with a non-string name attribute. Patch by Bo Bayles. ___ Python-checkins mailing list [email protected] https://mail.python.org/mailman/listinfo/python-checkins ___ 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
