[Python-Dev] Is explicit registration of Iterators needed?
A number of builtin iterator classes (but not all builtin iterator classes) are registered with the Iterator ABC in Lib/_collections_abc.py. But isinstance(it, Iterable) check works without explicit registration, because Iterable has __subclasshook__ that checks iterator methods. Is there a need in explicit registrations? Or their can be safely removed? ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Is explicit registration of Iterators needed?
On Fri, Oct 7, 2016 at 6:36 AM, Serhiy Storchaka wrote: > A number of builtin iterator classes (but not all builtin iterator classes) > are registered with the Iterator ABC in Lib/_collections_abc.py. But > isinstance(it, Iterable) check works without explicit registration, because > Iterable has __subclasshook__ that checks iterator methods. Is there a need > in explicit registrations? Or their can be safely removed? The preferred apprach is actually inheritance; registration comes next; the __subclasshook__ is a final compromise to the tradition of duck typing. I think the registrations should stay. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Is explicit registration of Iterators needed?
On 07.10.16 17:37, Guido van Rossum wrote: On Fri, Oct 7, 2016 at 6:36 AM, Serhiy Storchaka wrote: A number of builtin iterator classes (but not all builtin iterator classes) are registered with the Iterator ABC in Lib/_collections_abc.py. But isinstance(it, Iterable) check works without explicit registration, because Iterable has __subclasshook__ that checks iterator methods. Is there a need in explicit registrations? Or their can be safely removed? The preferred apprach is actually inheritance; registration comes next; the __subclasshook__ is a final compromise to the tradition of duck typing. I think the registrations should stay. Should we register missed builtin iterators? For example longrange_iterator. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Is explicit registration of Iterators needed?
On Fri, Oct 7, 2016 at 7:47 AM, Serhiy Storchaka wrote: > On 07.10.16 17:37, Guido van Rossum wrote: >> >> On Fri, Oct 7, 2016 at 6:36 AM, Serhiy Storchaka >> wrote: >>> >>> A number of builtin iterator classes (but not all builtin iterator >>> classes) >>> are registered with the Iterator ABC in Lib/_collections_abc.py. But >>> isinstance(it, Iterable) check works without explicit registration, >>> because >>> Iterable has __subclasshook__ that checks iterator methods. Is there a >>> need >>> in explicit registrations? Or their can be safely removed? >> >> >> The preferred apprach is actually inheritance; registration comes >> next; the __subclasshook__ is a final compromise to the tradition of >> duck typing. I think the registrations should stay. > > > Should we register missed builtin iterators? For example longrange_iterator. I don't feel strongly about this either way. Let sleeping dogs lie, etc. (Is this related to issue 26906?) -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2016-09-30 - 2016-10-07) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open5517 ( -2) closed 34624 (+69) total 40141 (+67) Open issues with patches: 2383 Issues opened (33) == #6280: calendar.timegm() belongs in time module, next to time.gmtime( http://bugs.python.org/issue6280 reopened by belopolsky #28315: incorrect "in ?" output in 'divide' example at "Defining Clean http://bugs.python.org/issue28315 reopened by terry.reedy #28320: Hostname validation is False by default in imaplib http://bugs.python.org/issue28320 opened by maciej.szulik #28326: multiprocessing.Process depends on sys.stdout being open http://bugs.python.org/issue28326 opened by Valentin.Lorentz #28327: statistics.geometric_mean gives incorrect results for mixed in http://bugs.python.org/issue28327 opened by mark.dickinson #28328: statistics.geometric_mean has no tests. Defer to 3.7? http://bugs.python.org/issue28328 opened by mark.dickinson #28330: Use simpler and faster sched.Event definition http://bugs.python.org/issue28330 opened by Satoru Logic #28331: "CPython implementation detail:" is removed when contents is t http://bugs.python.org/issue28331 opened by inada.naoki #28333: input() with Unicode prompt produces mojibake on Windows http://bugs.python.org/issue28333 opened by Drekin #28334: netrc does not work if $HOME is not set http://bugs.python.org/issue28334 opened by Dimitri Merejkowsky #28339: "TypeError: Parameterized generics cannot be used with class o http://bugs.python.org/issue28339 opened by Arfrever #28340: TextIOWrapper.tell extremely slow http://bugs.python.org/issue28340 opened by rmalouf #28343: Bad encoding alias cp936 -> gbk: euro sign http://bugs.python.org/issue28343 opened by Artoria2e5 #28344: Python 3.5.2 installer hangs when run in session 0 http://bugs.python.org/issue28344 opened by spooja #28351: statistics.geometric_mean can enter infinite loop for Decimal http://bugs.python.org/issue28351 opened by mark.dickinson #28352: winfo_pathname(..) | window id "xyz" doesn't exist in this app http://bugs.python.org/issue28352 opened by Tyler Sweeden #28353: os.fwalk() unhandled exception when error occurs accessing sym http://bugs.python.org/issue28353 opened by Samson Lee #28355: wsgiref simple_server PATH_INFO treats slashes and %2F the sam http://bugs.python.org/issue28355 opened by tdammers #28356: Windows: os.rename different in python 2.7.12 and python 3.5.2 http://bugs.python.org/issue28356 opened by stephan #28364: Windows - Popen (subprocess.py) does not call _handle.Close() http://bugs.python.org/issue28364 opened by Mateusz Klatt #28367: Add more standard baud rate constants to "termios" http://bugs.python.org/issue28367 opened by Andrey Smirnov #28373: input() prints to original stdout even if sys.stdout is wrappe http://bugs.python.org/issue28373 opened by wiggin15 #28374: SyntaxError: invalid token in python2.7/test/test_grammar.py http://bugs.python.org/issue28374 opened by welker #28375: cgi.py spam in Apache server logs http://bugs.python.org/issue28375 opened by srittau #28376: rangeiter_new fails when creating a range of step 0 http://bugs.python.org/issue28376 opened by Oren Milman #28377: struct.unpack of Bool http://bugs.python.org/issue28377 opened by Weihong Guan #28378: urllib2 does not handle cookies with `,` http://bugs.python.org/issue28378 opened by Grzegorz Sikorski #28379: PyUnicode_CopyCharacters could lead to undefined behaviour http://bugs.python.org/issue28379 opened by xiang.zhang #28381: Add a "starcaller" function http://bugs.python.org/issue28381 opened by josh.r #28382: Possible deadlock after many multiprocessing.Process are launc http://bugs.python.org/issue28382 opened by Hadhoke #28383: __hash__ documentation recommends naive XOR to combine but thi http://bugs.python.org/issue28383 opened by Kevin.Norris #28384: hmac cannot be used with shake algorithms http://bugs.python.org/issue28384 opened by minrk #28385: Bytes objects should reject all formatting codes with an error http://bugs.python.org/issue28385 opened by mmarkk Most recent 15 issues with no replies (15) == #28384: hmac cannot be used with shake algorithms http://bugs.python.org/issue28384 #28383: __hash__ documentation recommends naive XOR to combine but thi http://bugs.python.org/issue28383 #28382: Possible deadlock after many multiprocessing.Process are launc http://bugs.python.org/issue28382 #28375: cgi.py spam in Apache server logs http://bugs.python.org/issue28375 #28367: Add more standard baud rate constants to "termios" http://bugs.python.org/issue28367 #28355: wsgiref simple_server PATH_INFO treats slashes and %2F the sam http://bugs.python.org/issue28355 #28351: statistics.geometric_mean can enter infini
Re: [Python-Dev] Is explicit registration of Iterators needed?
On 7 October 2016 at 17:08, Guido van Rossum wrote: > On Fri, Oct 7, 2016 at 7:47 AM, Serhiy Storchaka > wrote: > > On 07.10.16 17:37, Guido van Rossum wrote: > >> > >> On Fri, Oct 7, 2016 at 6:36 AM, Serhiy Storchaka > >> wrote: > >>> > >>> A number of builtin iterator classes (but not all builtin iterator > >>> classes) > >>> are registered with the Iterator ABC in Lib/_collections_abc.py. But > >>> isinstance(it, Iterable) check works without explicit registration, > >>> because > >>> Iterable has __subclasshook__ that checks iterator methods. Is there a > >>> need > >>> in explicit registrations? Or their can be safely removed? > >> > >> > >> The preferred apprach is actually inheritance; registration comes > >> next; the __subclasshook__ is a final compromise to the tradition of > >> duck typing. I think the registrations should stay. > I have a question about the registration of builtins. Currently, typing.py contains this line: ByteString.register(type(memoryview(b''))) But there are two test lines in test_collections.py self.assertNotIsInstance(memoryview(b""), ByteString) self.assertFalse(issubclass(memoryview, ByteString)) This looks like a contradiction. Which one is right? Should these tests be removed or the registration in typing.py? -- Ivan ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
