Mailman 3 July 2017 - docs

[issue30974] Update os.samefile docstring to match documentation
by R. David Murray 20 Jul '17

20 Jul '17

R. David Murray added the comment: I would take "actual file" as meaning the file the symlink points to, so I'd say the documentation matches the implementation according to your description of the two. The current docs actually say "refer to the same file or directory", and mention os.stat explicitly, so again I'd say the docs and implementation match. It sounds like what you want is to open a feature request for a samefile equivalent that does not follow symlinks. lsamefile? We could use this issue for making the docstring match the docs, though. I think the sentence in the docs is short enough to just get copied into the docstring. ---------- assignee: -> docs@python components: +Documentation nosy: +docs@python, r.david.murray title: os.samefile / shutil._samefile: following symlinks -> Update os.samefile docstring to match documentation versions: +Python 3.6, Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue30974> _______________________________________

1 0

I found a typo on page https://docs.python.org/3/library/turtle.html
by 靳阳 19 Jul '17

19 Jul '17

Dear all, I found a typo on page https://docs.python.org/3/library/turtle.html It should be yinyang instead of yingyang The typo appears in section " 24.1.7. turtledemo — Demo scripts " To prove it is a typo, I run two commands as shown in the following picture. The first one throws one error, (The first command is python3 -m turtledemo.yingyang ) the second one works well. (The second command is python3 -m turtledemo.yinyang ) Best regards, from 靳阳

1 0

[issue11230] "Full unicode import system" not in 3.2
by John 19 Jul '17

19 Jul '17

New submission from John <jh45dev(a)gmail.com>: A few months ago I read that in 3.2 it will be possible to import modules that are located on paths containing any unicode character. (more precisely, with chars not in the local code page) After an hour or two trying to get this to work in 3.2rc3, I went looking for clues, and found these 2 messages in which Victor Stinner says this feature is delayed until Python 3.3: http://bugs.python.org/issue3080#msg126514 http://bugs.python.org/issue10828#msg125787 Could you please make it clear in documentation and web pages, that this feature is not working yet. The Python 3.2 download page includes this: "countless fixes regarding bytes/string issues; among them full support for a bytes environment (filenames, environment variables)" and I guessed this must cover importing from any unicode path, as there was no mention that such importing had been abandoned for this version. -- jh ---------- assignee: docs@python components: Documentation messages: 128711 nosy: docs@python, jh45 priority: normal severity: normal status: open title: "Full unicode import system" not in 3.2 versions: Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue11230> _______________________________________

7 11

[issue18558] Iterable glossary entry needs clarification
by Terry J. Reedy 17 Jul '17

17 Jul '17

Terry J. Reedy added the comment: The problem with the Iterable ABC is that 'iterable' and 'iterator' are *dynamically* defined, with a possibly infinite time required to possibly destructively check either definition. In general, an algorithmic *static* check can only guess whether an object is iterable, though humans analyzing enough code can potentially get it right. Therefore, using isinstance(ob, Iterable) is not 100% reliable, and in my opinion *should not be used* as the definition of lower-case 'iterable'. Definition: Object ob is iterable if 'iter(ob)' returns an iterator. For the reasons given above, iter may return a non-iterator, but it will if ob implements either the old or new iterator protocol. If ob has .__iter__, iter returns ob.__iter__(). If ob has .__getitem__, iter returns iterator(ob), where iterator is a hidden internal class that embodies the old iterator protocol by defining a .__next__ method that calls .__getitem__. In both cases, iter does the best it can by assuming that the methods are correctly written as per one of the two protocols. Loose definition: Object 'it' is iterable if it can be looped over. Python definition: Object 'it' is iterable if repeated 'next(it)' calls either return an object or raise StopIteration. This means that try: while True: next(it) except StopIteration: pass runs, possibly forever, without raising. As Raymond noted, an iterator can be created multiple ways: IteratorClass(), iter(ob), iter(func, sentinal), generator_func(). --- Iterable versus iter with respect to classes with __getitem__: Iter was added in 2.2. Built-in iterables were only gradually converted from old to new protocol, by adding a new .__iter__. So even ignoring user classes, iter *had* to respect .__getitem__. Even today, though only a small fraction of classes with .__getitem__ are iterable, people do not generally call iter() on random objects. Iterable (added 2.6) is documented as the "ABC for classes that provide the __iter__() method." In other words, isinstance(ob, Iterable) replaces hasattr(ob, '__iter__'). Except that the former is more than that. The magic word 'register' does not appear in the collections.ABC doc, and I think that this is the omission to be remedied. "ABC for classes that provide the __iter__() method, or that provide a __getitem__ method that implements the old iterator protocol and register themselves as Iterable." An example could be given using a patched version of IsIterable. If one adds two lines of code from collections.abc import Iterable ... Iterable.register(IsIterable) then isinstance(IsIterable(3), Iterable) is True, except that this is a lie in the other direction. Traceback (most recent call last): File "F:\Python\mypy\tem.py", line 17, in <module> for i in it2: File "F:\Python\mypy\tem.py", line 7, in __getitem__ return self.data[key] TypeError: 'int' object is not subscriptable Either IsIterable.__init__ must check that data itself has .__getitem__ or IsIterable.__next__ must capture exceptions and raise IndexError instead. def __getitem__(self, key): try: return self.data[key] except Exception: raise IndexError ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue18558> _______________________________________

1 0

Python 3.6.2 download links broken
by Bogdan Popescu 17 Jul '17

17 Jul '17

Hi, The links for the HTML docs download at https://docs.python.org/3/download.html <https://docs.python.org/3/download.html> end up in a 404. Regards, Bogdan

1 0

Can't download 3.6.2 docs -- all links go 404!
by Dave C. 17 Jul '17

17 Jul '17

Please let me know when this is rectified. Thanks

1 0

[issue18558] Iterable glossary entry needs clarification
by R. David Murray 17 Jul '17

17 Jul '17

R. David Murray added the comment: "things with __getitem__ are clearly iterable" This is false. IMO it should be fixed in the glossary. It should say "or __getitem__ method implementing sequence semantics". That plus the addition to the Iterable docs will close this issue. ---------- versions: +Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue18558> _______________________________________

1 0

[issue18558] Iterable glossary entry needs clarification
by Vedran Čačić 17 Jul '17

17 Jul '17

Vedran Čačić added the comment: Yes, the mapping/sequence distinction was (at least declaratively) the reason the ABCs were introduced, but that isn't an obstacle here: whether a mapping or a sequence, it _is_ iterable, right? --- In case anybody is interested, here's how I came to this problem: at a programming competition, I set a problem where contestants had to write some function, and I declared that "the function must work for arbitrary iterable (with some properties that currently don't matter)". Then a big discussion ensued, with a big group of people thinking that classes with __getitem__ but no __iter__ don't quality (giving collections.abc.Iterable as an argument), and another big group of people thinking they do (giving EAFP as an argument: "look, I tried iterating, and succeeded"). Of course, it's an incredibly technical detail, but I don't like such gray areas. To me, things with __getitem__ are clearly iterable - the glossary says so:-). Iterable's instancecheck is simply buggy ("incomplete", if you want). There might be valid reasons for keeping it buggy, but they should be documented. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue18558> _______________________________________

1 0

[issue18558] Iterable glossary entry needs clarification
by Raymond Hettinger 17 Jul '17

17 Jul '17

Raymond Hettinger added the comment: > Or at least, if we cannot do that because of backward > compatibility:-(, to explicitly document that Iterable ABC > _does not_ fully encompass what we mean by "being iterable". That would be a reasonable amendment to collections.abc.Iterable docs. I don't think it is either desirable or possible for collections.abc.Iterable to recognize iterables with __getitem__. We cannot know it advance whether __getitem__ is a mapping or a sequence. IIRC, that particular problem was the motivation for creating the ABCs. Without a user registering a class as Iterable or without inheriting from Iterable, there is really no way to know. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue18558> _______________________________________

1 0

[issue18558] Iterable glossary entry needs clarification
by Vedran Čačić 17 Jul '17

17 Jul '17

Vedran Čačić added the comment: Raymond, I think you didn't understand the issue. Glossary already _has_ the ammendment you mention (at least for the __getitem__ - I'm not sure any of other examples you mention are counterexamples to that interpretation: callable_iterators and generators _do_ have an __iter__ attribute, and they are correctly detected as instances of collections.abc.Iterable). I wanted to push in the _opposite_ direction, to fully bless __getitem__ as a way to declare iterability, so it could be recognized by Iterable's instancecheck. Because it seems to me that whoever wrote that instancecheck, didn't have the _intention_ to exclude __getitem__ iteration. Or at least, if we cannot do that because of backward compatibility:-(, to explicitly document that Iterable ABC _does not_ fully encompass what we mean by "being iterable". ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue18558> _______________________________________

1 0