[issue20751] Harmonize descriptor protocol documentation: direct call, super binding with Descriptor Howto docs
Change by Arthur Milchior : -- pull_requests: +28486 pull_request: https://github.com/python/cpython/pull/30271 ___ Python tracker <https://bugs.python.org/issue20751> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46182] `super` and descriptor clarification
Arthur Milchior added the comment: I do regret to have created a single bug, as I now realize that there are two issues that are less related than I first imagined. Is there a way to split a bug in two, so that both discussion can be discussed in different places. Actually, after more search abound "unbound method", I discovered in https://www.python.org/download/releases/3.0/whatsnew/ that this concept was supposed to be gone for good in 3.0 The notion is also used in a few other places in the documentation but as far as I can tell the only "definition" would be in https://docs.python.org/3.11/c-api/method.html#method-objects. While my first suggestion here was clearly wrong, I believe it still indicates a documentation bug. In that if the concept is still in the language, "unbound" should be a link to this concept. If the concept is not in the language anymore, then it should not be used without explanation. "super considered super" does not give a single example of super with a single argument. Which is probably great, because this case is far less super. However, this means that: * there is currently no way for a user that want to discover python to know that there is virtually no more reason to use super with a single argument. * for someone reading a codebase with super called with a single argument, it would be hard to figure out what it does. Actually, I was going to create a PR https://github.com/Arthur-Milchior/cpython/commit/dd453acad2b1f61867717cee4b47f944d37fb213 before seeing your answer, and while less certain, I still believe it has merits -- ___ Python tracker <https://bugs.python.org/issue46182> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20751] Harmonize descriptor protocol documentation: direct call, super binding with Descriptor Howto docs
Arthur Milchior added the comment: "a base class ``B`` following ``A``" shouldn't it be "the base class"? . After all, there is at most one base class following ``A``. Also, I find it unclear what means "``x`` is returned unchanged, since in this context ``x`` is not a value which exists by itself. -- ___ Python tracker <https://bugs.python.org/issue20751> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46182] `super` and descriptor clarification
Arthur Milchior added the comment: "a base class ``B`` following ``A``" shouldn't it be "the base class"? . After all, there is at most one base class following ``A``. Also, I find it unclear what means "``x`` is returned unchanged, since in this context ``x`` is not a value which exists by itself. -- ___ Python tracker <https://bugs.python.org/issue46182> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46182] `super` and descriptor clarification
Arthur Milchior added the comment: I just realized that https://bugs.python.org/issue20751 already tackled some of my issues. While I still believe that some things can be improved, this mean that some of the critiques in my first messages are not entirely up to date. -- versions: -Python 3.11 ___ Python tracker <https://bugs.python.org/issue46182> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20751] Harmonize descriptor protocol documentation: direct call, super binding with Descriptor Howto docs
Arthur Milchior added the comment: Shouldn't those change be ported to 3.10 and maybe even earlier version? They are great, but hard to find if you read the current version manual. I'm just surprised by the term "dotted lookup". The remaining of the documentation mention "attribute access". So I assumed that there was a reason to use "dotted lookup" instead of "attribute access". If there is such a reason, it's not clear right now. Otherwise, if they are equivalent, I'd suggest remaining consistent in the term used. I must note that "dotted lookup" is also used in the howto about descriptor, but it does not explain the difference with "attribute access". One last note, I find it a little bit strange that `a` was supposed to be the value on which the access is done, and suddenly it becomes a part of the value. -- nosy: +Arthur-Milchior ___ Python tracker <https://bugs.python.org/issue20751> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46182] `super` and descriptor clarification
New submission from Arthur Milchior : I find super documentation confusing because it uses multiple variables that are never introduced. Once you understand super, the meaning of those variables gets easier to understand, but still, I believe that it would help the documentation to rephrase some sentences. In https://docs.python.org/3/reference/datamodel.html#invoking-descriptors you can read > If a is an instance of super, then the binding super(B, obj).m() searches > obj.__class__.__mro__ for the base class A immediately following B and then > invokes the descriptor with the call: A.__dict__['m'].__get__(obj, > obj.__class__). It took me many reading to understand that `obj` is supposed to be a new variable; and also why `a` only appear once in the line. I believe it'd be better to explicitly state "We consider the case where a = super(B, obj), with `obj` an instance of B." Also, `super(B, obj).m()` seems to indicate that the method `m` is called. While ` A.__dict__['m'].__get__(obj, obj.__class__)` does not seems to call this method. Hence, I believe that the parentheses should be removed after `m` (and either `m` should be renamed to `x`, or we should state explicitly that we are not considered `a.x` anymore, contrary to the previous cases) In https://docs.python.org/3/library/functions.html#super , you can read > If the second argument is omitted, the super object returned is unbound. If > the second argument is an object, isinstance(obj, type) must be true. If the > second argument is a type, issubclass(type2, type) must be true (this is > useful for classmethods). On first reading, I have no idea what it means that a returned object is unbound. I know what "variable binding" mean, but it really does not seems to apply here. My current understanding, and I would love if someone can confirm it, is that the first sentence means that "contrary to the other cases, the returned value do not have to satisfy any bound". In this case, I believe that it would be far better to put the case with no second argument at the end of the paragraph, ensuring that "is unbound" makes sens to the reader since they already will have seen bounds. Also, it may help clarify to write "is an object `obj`" and "is a type `type2`" so that it get clear what `obj` and `type2` means. Any feedback welcome. -- assignee: docs@python components: Documentation messages: 409201 nosy: Arthur-Milchior, docs@python priority: normal severity: normal status: open title: `super` and descriptor clarification type: enhancement versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46182> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46087] format library documentation error
Arthur Milchior added the comment: ipypthon3 does not print the loop content. python3 does. I only tested with ipython. I beg your pardon. I didn't know about this difference in behavior -- nosy: -eric.smith title: Zip library documentation error -> format library documentation error ___ Python tracker <https://bugs.python.org/issue46087> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46087] Zip library documentation error
Change by Arthur Milchior : -- keywords: +patch pull_requests: +28345 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30126 ___ Python tracker <https://bugs.python.org/issue46087> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46087] Zip library documentation error
New submission from Arthur Milchior :
I don't have permission to assign the issue, but I intend to post the change in
a few minutes as a PR
Copied from Richard Hyde's email to doc mailing list.
One of the examples of string formatting doesn't work. This applies to prior
versions of Python as well.
The last set of the examples headed: 'Nesting arguments and more complex
examples:' starts with the following code:
>>> for align, text in zip('<^>', ['left', 'center', 'right']):
... '{0:{fill}{align}16}'.format(text, fill=align, align=align)
...
This omits print()
The correct code would be:
>>> for align, text in zip('<^>', ['left', 'center', 'right']):
... print('{0:{fill}{align}16}'.format(text, fill=align, align=align))
...
---
I agree with Richard here that there is a problem. Most example don't use
print, but since there is no returned expression, that's the most relevant way
to express the meaning of the example. Adding an expression would just make
things more complex.
Bug introducde in 28fbea412819f90698527c1997ece5aeddf8e9a7 in 2010.
--
assignee: docs@python
components: Documentation
messages: 408624
nosy: Arthur-Milchior, docs@python
priority: normal
severity: normal
status: open
title: Zip library documentation error
type: behavior
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python
3.9
___
Python tracker
<https://bugs.python.org/issue46087>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45922] Many method, function, built-in... are not clickable and should be
Arthur Milchior added the comment: Thanks for the warning about double link. I agree with you. I guess it's another reason why it would be non trivial to automate here. -- ___ Python tracker <https://bugs.python.org/issue45922> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45922] Many method, function, built-in... are not clickable and should be
New submission from Arthur Milchior :
I would like to work on this documentation improvement. Before spending time on
it, I would like to know whether it would be accepted in principle and whether
the way I would intend to improve the documentation would be accepted.
# Problem:
In a lot of part of the documentation, the text refers to a method, function,
built-in, variable, member defined somewhere else in the doc, but does not link
to it (I'll call it "the defined thing" in the remaining of this BPO).
## Example
As an example, in https://docs.python.org/3.10/library/imp.html#imp.reload ,
you'll get link to import from, but no link on __name__. Admittedly, it's
probably not a big deal by itself, and I would not have opened a bug report
only for this one. But I'm convinced that there are sufficiently many missing
links that a PR that would solve add a lot of them would improve the day to day
use of the documentation in a small way for a lot of users.
This example seems interesting to me because it also shows that creating the
links can not be 100% automated (even if most of it can). Indeed, __name__ is a
property of modules, but it is also a property of class, function, method,
descriptor and generator instances. The former is defined in
https://docs.python.org/3.10/library/types.html?highlight=__name__#types.ModuleType.__name__
while the latter is defined in
https://docs.python.org/3.10/library/stdtypes.html?highlight=__name__#definition.__name__
. Hence, a commit dealing with __name__ need to check that the correct
reference is used each time.
I got the idea from a change requested by Terry J Reedy on another of my
documentation PR a few days ago:
https://github.com/python/cpython/pull/29183#pullrequestreview-816414072 and I
believe this should be more systematic.
# How I'll solve this issue
## Ensuring the PR is easy to review
For each defined thing, I'll create a commit that simply add links to this
refered thing. In the example I gave, it will transform ``__name__`` to
:meth:`__name__`. That means that each commit will be very easy to review (even
if it will be boring). Even better, any diff tools can show that there are no
other difference than the one I claim to make.
### One downside
The downside is that it requires that I do not change the place where line
break occurs (otherwise, git default diff tool will show a lot of difference).
this mean that some lines will grow larger than 80 characters. In this case, I
believe that this is a cost worth paying because:
* there are already a lot of lines with more than 80 characters in the
documentation,
* reformating each paragraph will makes the reviewer work extremely hard, for
virtually no benefits
* if required, a last commit can reformat all paragraphs at the end.
## How I'll find missing references
I will NOT find all missing references. I do not believe it is a realistic
goal. My goal here is to improve the documentation, I don't care if it is not
perfect here. What I do is that I search for lines containing matching the
regexp `\`\.{2,}\`\`; they are generally, but not always, code that should be
reference. For each missing reference, I'll use search and replace in the
documentation codebase to replace the code by the link, I'll compile and check
that the link works.
## Future work
I believe ideally a linter should warn if a single word betwen `` and `` could
potentially be a reference. This seems harder work to be honest, I don't know
how I'd start it. And it seems useless while so many missing references are in
the codebase.
# Conclusion
My questions are thus:
* If I were to make such a PR, would it be accepted
* is there any feedback, improvement one would suggest that may improve the
result or save time
--
assignee: docs@python
components: Documentation
messages: 407242
nosy: Arthur-Milchior, docs@python
priority: normal
severity: normal
status: open
title: Many method, function, built-in... are not clickable and should be
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python
3.9
___
Python tracker
<https://bugs.python.org/issue45922>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45920] make doctest fails
Arthur Milchior added the comment: I know understand one thing I missed. I needed to do `make venv` after changing the make file to get 3.10 in virtual environment. The issue being that this would make doc harder to create on ubuntu since 3.10 is not yet easily accessible through apt/snap. Anyway, even when it's done, when 3.10-venv is installed on my machine and I remake venv, and I run doctest, it still fails with: Document: library/statistics Warning, treated as error: ** File "library/statistics.rst", line 150, in default Failed example: fmean(grades, weights) Exception raised: Traceback (most recent call last): File "/usr/lib/python3.10/doctest.py", line 1348, in __run exec(compile(example.source, filename, "single", File "", line 1, in fmean(grades, weights) TypeError: fmean() takes 1 positional argument but 2 were given Which comes from the fact that fmean got a new argument in 3.11 it didn't had in 3.10 So I guess the only way to actually get make doctest to work is if the virtual env uses the version of python in main. Is there anyway to do that? -- ___ Python tracker <https://bugs.python.org/issue45920> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45920] make doctest fails
New submission from Arthur Milchior : On current main, f87ea0350286837e9e96de03f8bfa215176c2928 , ``` cd cpython/Doc make doctest ``` fails. Due to: Document: library/functions --- Warning, treated as error: ** File "library/functions.rst", line ?, in default Failed example: list(zip(range(3), ['fee', 'fi', 'fo', 'fum'], strict=True)) Expected: Traceback (most recent call last): ... ValueError: zip() argument 2 is longer than argument 1 Got: Traceback (most recent call last): File "/usr/lib/python3.8/doctest.py", line 1336, in __run exec(compile(example.source, filename, "single", File "", line 1, in list(zip(range(3), ['fee', 'fi', 'fo', 'fum'], strict=True)) TypeError: zip() takes no keyword arguments This is not surprising since zip didn't take "Strict" kwarg in 3.8. The issue is that 3.10 doc is tested with Python 3.8. If in Makefile I change Python to "Python3.10" I get a new error, but it still mention "/usr/lib/python3.8/doctest.py" so I guess for some reason it was not using 3.10 everywhere. I don't know make enough to have any idea how to correct this one. By the way, is there a tool to auto-format .rst file? Initially, that was what I was trying to figure out, if I could get automatically warning when a new line is more than 80 chars long for example. -- assignee: docs@python components: Documentation messages: 407238 nosy: Arthur-Milchior, docs@python priority: normal severity: normal status: open title: make doctest fails versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue45920> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45646] Star expression in comprehension wrongly indicates to use or_expression after the star
Arthur Milchior added the comment: Thank you very much Dennis. For two reasons. First, because I like a lot what you wrote. I suspect that it would have saved me time and make things less confusing. That's not certain, because at the time I was reading the documentation of or_expr, I may have skipped or forgotten the part about BNF. A solution - that would require a bigger change - is that the various blocks containing rules have a small link back to the text you wrote, so that if a reader reads the rule directly, they can find out the meta information they need to know about rules. I guess that it's technically possible to do it with an extra sphinx rule, but may not be trivial to do, and it's not clear how such a link and text should look like in practice, as it must be noticeable the first time and easy to ignore next time. Thanks also because I'm happy, and slightly relieved, that my concerns are taken seriously. I admit that I feared that I would get as answer something such as: > actually, if you knew BNF, it should be clear that the actual meaning of > or_expr is And the fact that the answer I got tries to actually clarify the documentation for people wanting to learn or review Python without being expert in programming language theory is really great. Do you open a PR with your suggested test or do I update mine? -- ___ Python tracker <https://bugs.python.org/issue45646> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45584] Clarifying truncating in documentation
Arthur Milchior added the comment: Done -- ___ Python tracker <https://bugs.python.org/issue45584> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45584] Clarifying truncating in documentation
Arthur Milchior added the comment: I'm quite fan of your suggestion. Should I push it on the PR? Do you create another PR? I'm not used to BPO, I beg your pardon, only to github -- ___ Python tracker <https://bugs.python.org/issue45584> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45646] Star expression in comprehension wrongly indicates to use or_expression after the star
Change by Arthur Milchior : -- keywords: +patch pull_requests: +27571 stage: -> patch review pull_request: https://github.com/python/cpython/pull/29303 ___ Python tracker <https://bugs.python.org/issue45646> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45646] Star expression in comprehension wrongly indicates to use or_expression after the star
Arthur Milchior added the comment: Message 405188 was supposed to be another bug report. My bad. -- ___ Python tracker <https://bugs.python.org/issue45646> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45646] Star expression in comprehension wrongly indicates to use or_expression after the star
Change by Arthur Milchior : -- title: "expression" is erroneous in the doc -> Star expression in comprehension wrongly indicates to use or_expression after the star ___ Python tracker <https://bugs.python.org/issue45646> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45647] "expression" is erroneous in the doc
New submission from Arthur Milchior : https://docs.python.org/3/reference/expressions.html#grammar-token-python-grammar-expression is wrong This line state: `expression ::= conditional_expression | lambda_expr` and it is a problem because, by the way sphinx understand reference, this mean that any people who use the token `expression` will be linked to this particular line. For example in https://docs.python.org/3/reference/expressions.html#grammar-token-python-grammar-key_datum `key_datum ::= expression ":" expression | "**" or_expr` while clearly a key_datum is not expecting only a conditional expression or a lambda expression. Admittedly, you can derive, from expression: * conditional_expression * or_test * and_test * not_test * comparison * or_expr * xor_expr * and_expr * shift_expr * a_expr * m_expr * u_expr * power * primary * atom in this order, so in practice you can probably derive most of the expressions. However, I doubt that this is what the documentation meant here, and clearly not practical. -- assignee: docs@python components: Documentation messages: 405189 nosy: Arthur-Milchior, docs@python priority: normal severity: normal status: open title: "expression" is erroneous in the doc versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue45647> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45646] "expression" is erroneous in the doc
Arthur Milchior added the comment: https://docs.python.org/3/reference/expressions.html#grammar-token-python-grammar-expression is wrong This line state: `expression ::= conditional_expression | lambda_expr` and it is a problem because, by the way sphinx understand reference, this mean that any people who use the token `expression` will be linked to this particular line. For example in https://docs.python.org/3/reference/expressions.html#grammar-token-python-grammar-key_datum `key_datum ::= expression ":" expression | "**" or_expr` while clearly a key_datum is not expecting only a conditional expression or a lambda expression. Admittedly, you can derive, from expression: * conditional_expression * or_test * and_test * not_test * comparison * or_expr * xor_expr * and_expr * shift_expr * a_expr * m_expr * u_expr * power * primary * atom in this order, so in practice you can probably derive most of the expressions. However, I doubt that this is what the documentation meant here, and clearly not practical. -- title: The documentation wrongly uses or_expr for star expresion in displays -> "expression" is erroneous in the doc ___ Python tracker <https://bugs.python.org/issue45646> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45646] The documentation wrongly uses or_expr for star expresion in displays
New submission from Arthur Milchior : According to the current documentation, I believe there is an error in list_display, set_display and dict_display. According to list display, this is a valid expression [* l1 ^ l2] parsed as list_display: "[" starred_list: starred_item: "*" or_expr: xor_expr: xor_expr: "l1" "^" and_expr: "l2" "]" I add the full derivation from and_expr to l2 at the end of the report, it's not important for this topic. The same issue is present for set. For dictionary it is also present, but instead the error is in key_datum. I have no idea what would be the proper correction. Indeed [*l1+l2] is valid (in 3.9) at least. So it's not like the element after a star is restricted to be an atom. At the very least, I believe it should be clearly indicated that, contrary to what the name indicates, "or_expr" do not mean that we accept any or, nor any expression. It just mean that *some_complex_expression is interpreted as * (some_complex_expression) and that it is valid iff some_complex_expression is valid shift_expr: a_expr: m_expr: power: primary: atom: identifier: "l2" -- assignee: docs@python components: Documentation messages: 405187 nosy: Arthur-Milchior, docs@python priority: normal severity: normal status: open title: The documentation wrongly uses or_expr for star expresion in displays versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue45646> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45640] Production tokens are not clickable
Change by Arthur Milchior : -- keywords: +patch pull_requests: +27525 stage: -> patch review pull_request: https://github.com/python/cpython/pull/29260 ___ Python tracker <https://bugs.python.org/issue45640> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45640] Production tokens are not clickable
New submission from Arthur Milchior : In the current documentation, production tokens are not clickable. For example in https://docs.python.org/3/reference/expressions.html#yield-expressions , you highlight `yield_from` as a token but do not link to it. I suppose that the goal, when using :token:`yeld_from`, was to ensure that the token links to its definition. However, Sphinx require to use :token:`~python-grammar:yeld_from` for the link to appear. I suggest adding ~python-grammar after each token:. -- assignee: docs@python components: Documentation messages: 405147 nosy: Arthur-Milchior, docs@python priority: normal severity: normal status: open title: Production tokens are not clickable versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue45640> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45619] Mentioning structural pattern matching in the list of binding
Change by Arthur Milchior : -- keywords: +patch pull_requests: +27495 stage: -> patch review pull_request: https://github.com/python/cpython/pull/29232 ___ Python tracker <https://bugs.python.org/issue45619> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45619] Mentioning structural pattern matching in the list of binding
New submission from Arthur Milchior : https://docs.python.org/3/reference/executionmodel.html list all of the way a variable may be bound. However, it seems that it was not updated. Indeed, structural pattern matching in 3.10 also allows to bind a variable and is not mentionned. As a related issue, the sentence is far too long and really would need to be broken down. At the very least, the special case "and targets that are identifiers if" is not clear, it is not indicated whether this case extends to the end of the sentence or is just local -- assignee: docs@python components: Documentation messages: 405066 nosy: Arthur-Milchior, docs@python priority: normal severity: normal status: open title: Mentioning structural pattern matching in the list of binding versions: Python 3.10, Python 3.11 ___ Python tracker <https://bugs.python.org/issue45619> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45602] The grammar misses links that are present everywhere else
New submission from Arthur Milchior : The grammar, in https://docs.python.org/3/reference/grammar.html , lacks some utilities that the remaining of the documentation have. While it remains usable, it is hard to navigate. As an example https://www.python.org/dev/peps/pep-0634/ 's "star_named_exrpsession" and "block" links to the general grammar page, and indeed can't link to the specific rules as there are no anchor on them. This would also allow a related improvement: being able to click on a rule R in the right side of a declaration and go to the definition of R. Given the recursive nature of grammar, that would transform a sequence of search into a sequence of click (and even allow to use the browser's "back" to go back to the previous definition, or to open the new definition in a new tab) As far as I can tell, the first action would be to add a new kind of token on Doc/tools/extensions/peg_highlight.py , so that we distinguish the left and the right part of the rule. The left part (the name of the declared rule) would be easy to recognize as it always start on the beginning of the line and end with :. The second action would be that, for each declaration D, the html would contain an anchor "#D". And each time D would appear on the right hand side of a rule, it would be in a link to #D I suspect that adding those links and anchor could be done by overriding the default formatter or highlighter, but I don't understand pygment well enough to know what should be done here -- assignee: docs@python components: Documentation messages: 404946 nosy: Arthur-Milchior, docs@python priority: normal severity: normal status: open title: The grammar misses links that are present everywhere else type: enhancement versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue45602> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45584] Clarifying truncating in documentation
New submission from Arthur Milchior : While floor/ceil 's documentation are very precise, `truncate` was not explained. I actually had to search online to understand the difference between `truncate` and `floor` (admittedly, once I remembered that numbers are signed, and that floating numbers actually uses a bit for negation symbol instead of two complement, it became obvious) I assume that I won't be the only user having this trouble, especially for people whose mother tongue is not English. So I suggest adding a clarification to help make what should be obvious to most actually explicit -- assignee: docs@python components: Documentation messages: 404850 nosy: ArthurMilchior, docs@python priority: normal severity: normal status: open title: Clarifying truncating in documentation type: enhancement versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue45584> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45583] Documentation of int() in datamodel.rst is out of date
New submission from Arthur Milchior : In 3.8, int() default implementation changed, using __index__() if it is available instead of __trunc__(). The file function.rst was updated accordingly, but the redundant information in datamodel.rst contained out of date information I offer a correction in https://github.com/python/cpython/pull/29182 (but ideally it should be added back to 3.8 python documentation) -- assignee: docs@python components: Documentation messages: 404848 nosy: ArthurMilchior, docs@python priority: normal severity: normal status: open title: Documentation of int() in datamodel.rst is out of date versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue45583> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42140] asyncio.wait function creates futures set two times
Justin Arthur added the comment: > So the behaviour you describe will happen anyway. Unless we make your change against the 3.9 branch, in which case the fix will make it into the 3.9.x series of patch releases. -- ___ Python tracker <https://bugs.python.org/issue42140> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42140] asyncio.wait function creates futures set two times
Justin Arthur added the comment: I believe the documentation may be referring to the English set and not a Python set, but I could be wrong. Yury changed the wording from sequence to set in 3.7, but we didn't document a breaking change as far as I know. The purpose of those set constructions was to handle the many things other than a set that can be passed in that may have non-unique values. Early asyncio documentation included examples of passing wait() a list. I wouldn't be surprised if there are other libraries or apps out there for which removing iterator support was an accidentally-breaking change and it may be strange if this is only is broken in 3.9.x, but working both before and after. -- ___ Python tracker <https://bugs.python.org/issue42140> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42140] asyncio.wait function creates futures set two times
Justin Arthur added the comment: Your change makes perfect sense to me. It would be a backport-only change as the 2nd set creation is actually getting removed for the development version (3.10) to finalize the deprecation of wait's coroutine scheduling. -- nosy: +JustinTArthur ___ Python tracker <https://bugs.python.org/issue42140> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38912] test_asyncio altered the execution environment
Justin Arthur added the comment: The "'NoneType' object has no attribute 'close'" error is likely caused by a race against the loop calling the test protocol object's connection_made callback. I was able to reproduce this case occasionally on macOS and it's likely platform-agnostic. Given server/connection cleanup isn't context-managed or finally-driven on the affected tests, raising the NoneType error will skip cleanup and we see additional exceptions from unclosed networking components being garbage collected. Tests using this test protocol pattern were either waiting for the callback already or were waiting on network i/o that happens long after connection establishment with the exception of: - `test_create_server_ssl_verified` - `test_create_unix_server_ssl_verified` PR 22691 ensures those two tests wait for the connect callbacks as well. This may not address the env changed error from recent msg378481, as the initial error is not necessarily disclosed in that log. -- ___ Python tracker <https://bugs.python.org/issue38912> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38912] test_asyncio altered the execution environment
Change by Justin Arthur : -- nosy: +JustinTArthur nosy_count: 5.0 -> 6.0 pull_requests: +21662 pull_request: https://github.com/python/cpython/pull/22691 ___ Python tracker <https://bugs.python.org/issue38912> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33533] Provide an async iterator version of as_completed
Change by Justin Arthur : -- versions: +Python 3.10 -Python 3.8 ___ Python tracker <https://bugs.python.org/issue33533> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33533] Provide an async iterator version of as_completed
Change by Justin Arthur : -- title: Provide an async-generator version of as_completed -> Provide an async iterator version of as_completed ___ Python tracker <https://bugs.python.org/issue33533> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33533] Provide an async-generator version of as_completed
Justin Arthur added the comment: Thanks, Hrvoje. I've updated the patch to match this bug's suggested format and have updated the documentation and What's New. The one quirk that comes with the benefit of getting the same futures back is that we still allow both coroutines and futures to be passed in. Coroutines will not be yielded back in their original form, but instead a new task. -- ___ Python tracker <https://bugs.python.org/issue33533> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38032] lib2to3 doesn't parse Python 3 identifiers containing non-spacing marks
Justin Arthur added the comment: Not sure if there is consensus on how to fix, but fixing #12731 will fix this for most of the cases I've seen complaints about as a side effect. -- ___ Python tracker <https://bugs.python.org/issue38032> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33533] Provide an async-generator version of as_completed
Justin Arthur added the comment: I've added a new PR, PR 22491. This one has as_completed returning an iterator and includes tests for both the old and new style. I see a trivial amount of latency added in extra call stack over Guido's original implementation. Should we decide to deprecate the plain-iterator-of-awaitables form, we can possibly regain that latency in refactoring this as an asynchronous generator. -- ___ Python tracker <https://bugs.python.org/issue33533> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33533] Provide an async-generator version of as_completed
Change by Justin Arthur : -- nosy: +JustinTArthur nosy_count: 5.0 -> 6.0 pull_requests: +21508 pull_request: https://github.com/python/cpython/pull/22491 ___ Python tracker <https://bugs.python.org/issue33533> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40128] IDLE Show completions/ autocomplete pop-up not working
New submission from Arthur : Hi, I am new to python, I am learning it now. In the course the guy is using autocomplete and when he writes "math." he gets an autocomplete menu. on my device for some reason it is not working. I also tried the key combination to force pop-up but nothing happens. I am running macOSx Catalina 10.15.2 and IDLE 3.8.2 P.s. I reinstalled IDLE, nothing changed. -- assignee: terry.reedy components: IDLE messages: 365401 nosy: darthur90, terry.reedy priority: normal severity: normal status: open title: IDLE Show completions/ autocomplete pop-up not working type: behavior versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue40128> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39449] New Assignment operator
New submission from Arthur Fibich : It's just a personal thing, but I kind of miss the following possibility in Python (and likewise every other language I know): Like a += 1 is the same as a = a + 1 I'd love to see a .= b() as an opportunity to express a = a.b() Possible usages are for example linked lists or other structures, where a class's attributes or methods are/return an object of the same type. -- components: Interpreter Core messages: 360659 nosy: Arthur Fibich priority: normal severity: normal status: open title: New Assignment operator type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue39449> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12731] python lib re uses obsolete sense of \w in full violation of UTS#18 RL1.2a
Change by Justin Arthur : -- nosy: +JustinTArthur ___ Python tracker <https://bugs.python.org/issue12731> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38032] lib2to3 doesn't parse Python 3 identifiers containing non-spacing marks
Justin Arthur added the comment: Ned, can you confirm that 2to3 is not intended for cumulative/incremental runs over the same codebase? If it's not intended to be run on previously ported code, this will just need to be fixed on the lib2to3 downstream projects like awpa and Black that are encountering this issue. -- ___ Python tracker <https://bugs.python.org/issue38032> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38032] lib2to3 doesn't parse Python 3 identifiers containing non-spacing marks
New submission from Justin ARthur :
Python 3 code with an identifier that has a non-spacing mark in it does not get
tokenized by lib2to3 and will result in an exception thrown in the parsing
process.
Parsing the attached file (badvar.py), results in `ParseError: bad token:
type=58, value='̇', context=('', (1, 1))`
This happens because the Name pattern regular expression in lib2to3 is `r'\w+'`
and the word character class doesn't contain non-spacing marks (and possible
other [continuation characters allowed in Python 3
identifiers](https://docs.python.org/3/reference/lexical_analysis.html#identifiers)).
(reported by energizer in the Python IRC channel)
--
components: 2to3 (2.x to 3.x conversion tool), Library (Lib)
files: badvar.py
messages: 351153
nosy: JustinTArthur
priority: normal
severity: normal
status: open
title: lib2to3 doesn't parse Python 3 identifiers containing non-spacing marks
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8
Added file: https://bugs.python.org/file48592/badvar.py
___
Python tracker
<https://bugs.python.org/issue38032>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2506] Add mechanism to disable optimizations
Arthur Goldberg added the comment: Appreciate you working on this Serhiy and Victor! -- ___ Python tracker <https://bugs.python.org/issue2506> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36808] Understanding "cannot import name" exception
New submission from Arthur Goldberg : I'm attempting to better understand an ImportError: cannot import name '' error by reading the cpython source. But I cannot find this error in the source. The closest I find is in cpython/Python/ceval.c, lines 5060 & 5068, but they both say: cannot import name %R from %R (*) and my message doesn't include the 'from ...'. I'm using: Python 3.6.5 (default, Sep 14 2018, 14:56:31) [GCC 7.3.0] on linux Thanks, Arthur -- components: Interpreter Core messages: 341478 nosy: ArthurGoldberg priority: normal severity: normal status: open title: Understanding "cannot import name" exception type: behavior versions: Python 3.6 ___ Python tracker <https://bugs.python.org/issue36808> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2506] Add mechanism to disable optimizations
Arthur Goldberg added the comment: This issue is well into the 2nd decade of debate. Who has the power to effect this change? Happy New Year Arthur -- ___ Python tracker <https://bugs.python.org/issue2506> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35259] Py_FinalizeEx unconditionally exists in Py_LIMITED_API
Change by Arthur Neufeld : -- keywords: +patch pull_requests: +9868 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue35259> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35259] Py_FinalizeEx unconditionally exists in Py_LIMITED_API
New submission from Arthur Neufeld : In application compiled with #define Py_LIMITED_API 0x0304 this method was used Py_FinalizeEx() Tested application with: SET PATH=...;C:\Program Files\Python35 APPLICATION.EXE Result: Entry Point Not Found (X) The procedure entry point Py_FinalizeEx could not be located in the dynamic link library C:\PATH\TO\APPLICATION.EXE Expected Result: Application runs Rebuilding, after replacing Py_FinalizeEx(void) with Py_Finalize(void): Application runs when pointing to 3.5 DLLs. Suggested resolution: Declaration should be restricted to ABI 3.6+: #if !defined(Py_LIMITED_API) || Py_LIMITED_API+0 >= 0x0306 PyAPI_FUNC(int) Py_FinalizeEx(void); #endif -- components: Interpreter Core messages: 329959 nosy: AJNeufeld priority: normal severity: normal status: open title: Py_FinalizeEx unconditionally exists in Py_LIMITED_API type: crash versions: Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue35259> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2506] Add mechanism to disable optimizations
Arthur Goldberg added the comment: I'm another user of Ned's coverage tool. Our team at the Mount Sinai School of Medicine is building tools to model the dynamics of biochemistry inside individual cells. Our short term aims are to better understanding microbiology and model microorganisms so they can be engineered to more effectively produce drugs and do other industrial tasks. Long term, we seek to build genetically personalized models of human cells which can be used to improve the medical care of cancer and other illnesses. We're funded by several agencies of the federal government. Our field is called whole-cell modeling. We use Python because it provides a wide array of powerful tools we can reuse to reduce our development time, enables us to rapidly prototype software to test and advance our modeling ideas, and is fun to program. Using git, pip, coverage, GitHub, CircleCI, Docker and other tools we've built a robust development environment that enables multiple people to contribute to advancing our tools for whole-cell modeling. We strongly emphasize software engineering because the data we use is large, incomplete and inconsistent, and our models are complex and difficult to train, verify and validate. We want to have a high level of confidence in our tested code so that if we have trouble with a model we can focus on checking the data and understanding the model design. Coverage testing is an important part of our software engineering. We test both line and branch coverage. While working today on our simulator I found code that should have been fully covered except for a # pragma no cover, but was not fully covered. I reported it to Ned (https://github.com/nedbat/coveragepy/issues/697) who reproduced it in a simpler example and pointed out that this "Add mechanism to disable optimizations" issue contributed to the problem. I realize that approximately 0.0% of Python users work on whole-cell modeling, which diminishes the importance of this use case. But Python is widely used in computational biomedicine, which represents many more users. Case in point -- I've created and teach a course in Biomedical Software Engineering which uses Python and teaches coverage testing to masters, PhD, and MD/PhD students. We'd appreciate your help improving Ned's coverage tool. You can learn more about us at http://www.karrlab.org/ and https://github.com/KarrLab. Regards Arthur -- nosy: +ArthurGoldberg ___ Python tracker <https://bugs.python.org/issue2506> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31025] io.BytesIO: no way to get the length of the underlying buffer without copying data
Arthur Darcet added the comment: BytesIO is heavily optimised to avoid copying bytes when it can. For case (1), if you want to modify the data, then there is no need to actually copy it before overwriting it, because no-one else is using it For case (2), if you want to change something, then you need to copy it first, otherwise the original bytes object would get modified Case (1): % python -m timeit -s "import io; b = io.BytesIO(b'0' * 2 ** 30)" "b.getbuffer()" 100 loops, best of 3: 0.201 usec per loop Case (2): python -m timeit -s "import io; a = b'0' * 2 ** 30; b = io.BytesIO(a)" "b.getbuffer()" 10 loops, best of 3: 54.5 msec per loop -- versions: -Python 3.7 ___ Python tracker <http://bugs.python.org/issue31025> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31025] io.BytesIO: no way to get the length of the underlying buffer without copying data
Arthur Darcet added the comment: it's a tiny bit slow, but that works, thank you. I guess we can close this % python -m timeit -s "import io; b = io.BytesIO(b'0' * 2 ** 30)" "p = b.tell(); b.seek(0, 2); b.tell(); b.seek(p)" 100 loops, best of 3: 0.615 usec per loop % python -m timeit -s "import io; b = io.BytesIO(b'0' * 2 ** 30)" "len(b.getvalue())" 1000 loops, best of 3: 0.174 usec per loop -- stage: -> resolved status: open -> closed ___ Python tracker <http://bugs.python.org/issue31025> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31025] io.BytesIO: no way to get the length of the underlying buffer without copying data
New submission from Arthur Darcet: If I'm not mistaken, a BytesIO buffer can be in three states: (1) `b = BytesIO(b'data')` -> free of any constraints (2) `d = b'data'; b = BytesIO(d)` -> cannot modify the underlying bytes without copying them (3) `b = BytesIO(b'data'); d = b.getbuffer()` -> cannot return a "bytes" representation of the data without copying it (the underlying buffer might change) My use-case is "how to get the length of the data currently in the BytesIO object". And right now, there are two solutions: (a) `len(b.getvalue())` (b) `len(b.getbuffer())` but, solution (a) is copying data if the buffer is in state (3) ; and solution (b) is copying data for state (2). And I don't see any way to distinguish between the three states from Python code. So as far as I understand it, there is no way to get the size of the buffer in Python that would reliably not copy any data Should I open a PR to add a `size()` method on the BytesIO class? (simply returning `PyLong_FromSsize_t(self->string_size)` -- components: IO messages: 299054 nosy: rthr priority: normal severity: normal status: open title: io.BytesIO: no way to get the length of the underlying buffer without copying data type: enhancement versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <http://bugs.python.org/issue31025> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30679] __aexit__ not called when `run_until_complete` is interrupted by SIGINT
Arthur Darcet added the comment: Ok, thank you. I'm guessing the patch I proposed in the PR is not an option, for my curiosity, why is that? -- ___ Python tracker <http://bugs.python.org/issue30679> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30679] __aexit__ not called when `run_until_complete` is interrupted by SIGINT
New submission from Arthur Darcet:
Here is the example code I am running:
```
import asyncio
class it:
async def __aenter__(self):
return self
async def __aexit__(self, *_):
print('EXIT')
async def main():
async with it():
await asyncio.sleep(100)
asyncio.get_event_loop().run_until_complete(main())
```
When this gets interrupted by a SIGINT, I would expect this code to display
`EXIT` before the `KeyboardInterrupt` stacktrace. But instead the `__aexit__`
function is simply not called.
--
components: asyncio
messages: 296106
nosy: rthr, yselivanov
priority: normal
pull_requests: 2264
severity: normal
status: open
title: __aexit__ not called when `run_until_complete` is interrupted by SIGINT
versions: Python 3.5, Python 3.6, Python 3.7
___
Python tracker
<http://bugs.python.org/issue30679>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29406] asyncio SSL contexts leak sockets after calling close with certain Apache servers
Changes by Arthur Darcet : -- nosy: +rthr ___ Python tracker <http://bugs.python.org/issue29406> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27240] 'UnstructuredTokenList' object has no attribute '_fold_as_ew'
Changes by Arthur Gutman : -- nosy: +archibald ___ Python tracker <http://bugs.python.org/issue27240> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30002] Minor change to https://docs.python.org/3.6/extending/building.html
New submission from Arthur Goldberg:
The core example on this page starts:
from distutils.core import setup, Extension
module1 = Extension('demo',
sources = ['demo.c'])
...
I suggest that 'sources = ['demo.c']' be changed to 'sources =
['demomodule.c']', because this would make the example consistent with
https://docs.python.org/3.6/extending/extending.html which says: "Begin by
creating a file spammodule.c. (Historically, if a module is called spam, the C
file containing its implementation is called spammodule.c; ... )"
This minor change may help encourage this standard practice.
Arthur
--
assignee: docs@python
components: Documentation
messages: 291203
nosy: ArthurGoldberg, docs@python
priority: normal
severity: normal
status: open
title: Minor change to https://docs.python.org/3.6/extending/building.html
type: behavior
versions: Python 3.6
___
Python tracker
<http://bugs.python.org/issue30002>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29997] Suggested changes for https://docs.python.org/3.6/extending/extending.html
Arthur Goldberg added the comment: Also, Incorrect number agreement: s/strategy that minimizes this kind of errors/strategy that minimizes this kind of error/ -- ___ Python tracker <http://bugs.python.org/issue29997> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29997] Suggested changes for https://docs.python.org/3.6/extending/extending.html
New submission from Arthur Goldberg:
I've just taught myself how to write C extensions to Python with
https://docs.python.org/3.6/extending/extending.html. I think it's quite good.
Nevertheless, I've some suggested improvements. These all use the vi s///
replacement syntax.
Ambiguous 'it':
s/If the latter header file does not exist on your system, it declares the
functions malloc(), free() and realloc() directly./If the latter header file
does not exist on your system, Python.h declares the functions malloc(), free()
and realloc() directly./
Unclear, as 'The C function' refers to the specific example, whereas 'always
has' implies that this applies to all calls from Python to C:
s/The C function always has two arguments, conventionally/A C function called
by Python always has two arguments, conventionally/
In
PyMODINIT_FUNC
PyInit_spam(void)
{
PyObject *m;
m = PyModule_Create(&spammodule);
if (m == NULL)
return NULL;
SpamError = PyErr_NewException("spam.error", NULL, NULL);
Py_INCREF(SpamError);
PyModule_AddObject(m, "error", SpamError);
return m;
}
remove
m = PyModule_Create(&spammodule);
if (m == NULL)
return NULL;
and replace it with
...
because it won't compile because spammodule has not been described yet on the
page.
Self-contradictory: 'normally always' is an oxymoron.
s/It should normally always be METH_VARARGS or METH_VARARGS | METH_KEYWORDS; a
value of 0 means that an obsolete variant of PyArg_ParseTuple() is used./It
should always be METH_VARARGS or METH_VARARGS | METH_KEYWORDS; however, legacy
code may use 0, which indicates that an obsolete variant of PyArg_ParseTuple()
is being used./
Incomplete: this comment doesn't contain a complete thought
s/module documentation, may be NULL/pointer to a string containing the module's
documentation, or NULL if none is provided/
Provide hyperlink: for user convenience, add a hyperlink to 'Modules/xxmodule.c'
s/included in the Python source distribution as Modules/xxmodule.c/included in
the Python source distribution as Modules/xxmodule.c/
Incomplete: It would be good to lead programmers towards the easiest approach.
s/ If you use dynamic loading,/ If you can use dynamic loading,
the the easiest approach is to use Python's distutils module to build your
module. If you use dynamic loading,/
--
assignee: docs@python
components: Documentation
messages: 291192
nosy: ArthurGoldberg, docs@python
priority: normal
severity: normal
status: open
title: Suggested changes for
https://docs.python.org/3.6/extending/extending.html
type: behavior
versions: Python 3.6
___
Python tracker
<http://bugs.python.org/issue29997>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29280] gdbm & ndbm support missing in Windows
New submission from Arthur Vanwalleghen: When I tried to work with GDBM and Ndbm files I saw that their supporting modules were not found. This can be verified with Pydoc: Pydoc\Python36-32\lib \dbm(package)\Package Contents\gnu|ndbm ErrorDuringImport: problem in dbm.gnu - ModuleNotFoundError: No module named '_gdbm' ErrorDuringImport: problem in dbm.ndbm - ModuleNotFoundError: No module named '_dbm' I first noticed this in 3.5 and waited to see if it was fixed in 3.6. I am running Win8.1. I want to work with files created on Linux/Perl using GDBM or NDBM. I cannot find any perl support for Python's dbm.dumb. I am looking for an out-of-the-box support for simple key/data files. -- components: Windows messages: 285517 nosy: ArtVan, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: gdbm & ndbm support missing in Windows type: behavior versions: Python 3.5, Python 3.6 ___ Python tracker <http://bugs.python.org/issue29280> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27280] Paste fail in ipaddress documentation
New submission from Arthur Carcano: There is a type in the `IPv6Network' constructor doc, fixed in attached patch. -- assignee: docs@python components: Documentation files: patch_doc_ipaddress.patch keywords: patch messages: 267999 nosy: NougatRillettes, docs@python priority: normal severity: normal status: open title: Paste fail in ipaddress documentation type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file43317/patch_doc_ipaddress.patch ___ Python tracker <http://bugs.python.org/issue27280> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24592] global var defined in module not returned by function
New submission from arthur: defined global var, glob.myVar, in separated module imported module containing glob.myVar in function1, func1(): glob.myVar = "" func1Var = func2() in function2, func2(): if (...): glob.myVar+= "abc" func2() # call func2() again - recursive else: return glob.myVar I always find: func1Var is None = True An obvious workaround is func1Var = glob.myVar which is fine -- components: Windows messages: 246460 nosy: arthur, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: global var defined in module not returned by function type: behavior versions: Python 3.6 ___ Python tracker <http://bugs.python.org/issue24592> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6818] remove/delete method for zipfile/tarfile objects
Changes by Arthur Darcet : -- nosy: +Arthur.Darcet ___ Python tracker <http://bugs.python.org/issue6818> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4643] cgitb.html fails if getattr call raises exception
Arthur Petitpierre added the comment: I attached a patch containing both the fix suggested by Allan and a test case. Tested against trunk and python2.7. -- keywords: +patch nosy: +arthur.petitpierre Added file: http://bugs.python.org/file28229/issue4643.patch ___ Python tracker <http://bugs.python.org/issue4643> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1378] fromfd() and dup() for _socket on WIndows
Arthur Kantor added the comment: Hi guys It appears, that this patch was meant to go into both the 2.x and 3.x series, but it never made into 2.x Are there still plans to apply it to 2.7? (apologies if I'm asking this in the wrong forum) -- nosy: +Arthur.Kantor versions: +Python 2.7 -Python 2.6 ___ Python tracker <http://bugs.python.org/issue1378> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
