[issue43698] Use syntactically correct examples on abc package page
New submission from Vladimir Ryabtsev : There are code snippets on the package's page (https://docs.python.org/3.10/library/abc.html) like this: class C(ABC): @classmethod @abstractmethod def my_abstract_classmethod(cls, ...): ... Here, the author probably wanted to demonstrate that the method may have _any other arguments_ in addition to `cls`, but it makes the code not compilable: def my_abstract_classmethod(cls, ...): ^ SyntaxError: invalid syntax Additionally it uses the same Ellipsis as in the method's body (that is supposed to indicate a stub), which is confusing. I think that all code samples must be syntactically correct, so that if a reader copypastes them into their code editor they would work right away. I suggest to remove ellipsis in the argument lists everywhere on the page and replace them with one of the following: - sample parameters such as `a, b, c` or `my_arg1, my_arg2`, - `*args, **kwargs`, - nothing. -- assignee: docs@python components: Documentation messages: 390004 nosy: Vladimir Ryabtsev, docs@python priority: normal severity: normal status: open title: Use syntactically correct examples on abc package page type: compile error versions: Python 3.10, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue43698> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42179] Clarify chaining exceptions in tutorial/errors.rst
Vladimir Ryabtsev added the comment: The issue won't be fixed, but other useful changes applied. -- resolution: -> wont fix stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue42179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38413] Remove or change "Multithreading" section
Change by Vladimir Ryabtsev : -- stage: patch review -> resolved status: open -> closed versions: +Python 3.10 -Python 3.7 ___ Python tracker <https://bugs.python.org/issue38413> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38413] Remove or change "Multithreading" section
Change by Vladimir Ryabtsev : -- pull_requests: +22974 pull_request: https://github.com/python/cpython/pull/24145 ___ Python tracker <https://bugs.python.org/issue38413> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42179] Clarify chaining exceptions in tutorial/errors.rst
Vladimir Ryabtsev added the comment: All right, you won. I hope beginner users will be happy :) I removed my proposal paragraph about __cause__ and __context__ and kept only changes about exception type (https://bugs.python.org/issue42179#msg380435). -- ___ Python tracker <https://bugs.python.org/issue42179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42179] Clarify chaining exceptions in tutorial/errors.rst
Vladimir Ryabtsev added the comment: Also, the choice of the exception type in the example looks not very apt: you raise "IOError" but the traceback message says "OSError" (which is due to strange design decision "IOError = OSError"). For the tutorial, I would choose an exception that does not disguise as another exception. -- ___ Python tracker <https://bugs.python.org/issue42179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42179] Clarify chaining exceptions in tutorial/errors.rst
Vladimir Ryabtsev added the comment: We have automatic chaining, so you don't need to use "from X" unless you want to have some control on the traceback message. Even without knowing of this syntax (and without using "from exc"), a user will get a traceback message similar to what is shown in the example. What is the purpose of the entire section then? As I see it, the purpose might be providing some details about how exactly chaining works, so a user: a) could make an informed decision whether they need "from X" or not, b) would know how to retrieve the linked exception programmatically. I generally feel that we don't want to deprive a user from special attributes, in Python they are everywhere, you cannot even construct a class instance without __init__(). -- ___ Python tracker <https://bugs.python.org/issue42179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42179] Clarify chaining exceptions in tutorial/errors.rst
Vladimir Ryabtsev added the comment: > I can not find confusion caused by this tutorial section Inada, have you read the very first message in this ticket? It explains why this wording may cause confusion (and it did in me), and describes the problem part. A link for your convenience: https://docs.python.org/3/tutorial/errors.html#exception-chaining > Describing the default behavior and "from None" is enough for new users Strange that you think that "from None" is more useful for beginners than these special attributes. Without understanding of __cause__ and __context__, stack traceback message looks like magic. Say you want to handle an exception and retrieve its cause (context) in runtime (this is what exception chaining for) – this section makes no clues about how to do that. -- ___ Python tracker <https://bugs.python.org/issue42179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42179] Clarify chaining exceptions in tutorial/errors.rst
Vladimir Ryabtsev added the comment: 1. Such understanding of a tutorial is debatable. Tutorial is just a material for learning written with some system in mind, which is more interesting to read than dry reference material. A tutorial, generally dpeaking, may be both for beginners and for professionals. 2. The question about exception chaining is popular on Stackoverflow in people who came to Python with Java or C# background (see “python inner exception”). 3. Whatever material is given, it should not cause confusion, but now it does. Since this section has been added recently, it is better to fix it rather than remove entirely, aren’t you agree? -- ___ Python tracker <https://bugs.python.org/issue42179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42179] Clarify chaining exceptions in tutorial/errors.rst
Change by Vladimir Ryabtsev : -- keywords: +patch pull_requests: +22072 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23160 ___ Python tracker <https://bugs.python.org/issue42179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38413] Remove or change "Multithreading" section
Change by Vladimir Ryabtsev : -- pull_requests: +22071 pull_request: https://github.com/python/cpython/pull/23159 ___ Python tracker <https://bugs.python.org/issue38413> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42179] Clarify chaining exceptions in tutorial/errors.rst
New submission from Vladimir Ryabtsev : A new section has been added to the page as a result of https://bugs.python.org/issue37826. The change: https://github.com/python/cpython/commit/dcfe111eb5602333135b8776996332a8dcf59392 The wording it uses (in the beginning of section 8.5), defines chaining as setting __cause__ attribute in an exception, and later states that "Exception chaining happens automatically when an exception is raised inside an exception handler or finally section". This may lead the reader to a wrong idea that re-raising an exception without "from" in "except" and "finally" automatically sets __cause__. In reality it sets only __context__ attribute, which is similar concept to __cause__, but work a bit differently, as explained in library/exceptions.rst. I suggest to mention that difference and provide a link to the main article. -- assignee: docs@python components: Documentation messages: 379823 nosy: Vladimir Ryabtsev, docs@python priority: normal severity: normal status: open title: Clarify chaining exceptions in tutorial/errors.rst versions: Python 3.10, Python 3.9 ___ Python tracker <https://bugs.python.org/issue42179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38413] Remove or change "Multithreading" section
Vladimir Ryabtsev added the comment: Also the footnote requires some minor corrections (formatting and style). I suggest the following wording: To get loadable extension support, your Python must be compiled with ``-–enable-loadable-sqlite-extensions`` option in ``PYTHON_CONFIGURE_OPTS``. I believe otherwise it is basically not clear what is said here. -- ___ Python tracker <https://bugs.python.org/issue38413> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38413] Remove or change "Multithreading" section
Vladimir Ryabtsev added the comment: May by I was wrong above and it uses system's Sqlite... But anyway it does not cancel the fact that this section contradicts to another one. -- ___ Python tracker <https://bugs.python.org/issue38413> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38413] Remove or change "Multithreading" section
Vladimir Ryabtsev added the comment: I see no point in researching the version of sqlite, since Python does not allow user to specify it, you just use the compiled version that comes with Python distribution. 10 years now to the commit that introduced that piece of text: https://github.com/python/cpython/commit/c34d76cdc3212615f9a3c2c4b1c542592372b5f8 Let's just remove it, what it says is simply not true. -- ___ Python tracker <https://bugs.python.org/issue38413> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38413] Remove or change "Multithreading" section
New submission from Vladimir Ryabtsev : This is regarding the page https://docs.python.org/3.7/library/sqlite3.html. I believe this section on the very bottom of the page has been kept here for pretty long time, during that both SQLite and the sqlite3 module evolved and improved. Now the content contradicts to the description of function "connect()" in the part describing "check_same_thread" parameter. The function description says that using connections from multiple threads is allowed with serialization handled by the user (and it is true), while the bottom "Mutithreading" section says sharing connections is not allowed. I think we can remove "Mutithreading" section entirely unless there is something important to add to what already mentioned. -- assignee: docs@python components: Documentation messages: 354227 nosy: Vladimir Ryabtsev, docs@python priority: normal severity: normal status: open title: Remove or change "Multithreading" section versions: Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue38413> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
