[issue38914] Clarify wording for warning message when checking a package

New submission from Jürgen Gmach : When creating a package for PyPi, and naming an author, but not an author_email, you get a warning as follows: warning: Check: missing meta-data: if 'author' supplied, 'author_email' must be supplied too The specs ( https://packaging.python.org

[issue38914] Clarify wording for warning message when checking a package

Change by Jürgen Gmach : -- keywords: +patch pull_requests: +16870 stage: -> patch review pull_request: https://github.com/python/cpython/pull/17388 ___ Python tracker <https://bugs.python.org/issu

[issue38914] Clarify wording for warning message when checking a package

Jürgen Gmach added the comment: Thank you for your feedback. Paul Ganssle suggested a updated wording over at https://github.com/pypa/pep517/issues/73 so this is why I created a pr accordingly. The intent of this issue and the pr is to minimize the confusion for a beginner with Python

[issue38914] Clarify wording for warning message when checking a package

Jürgen Gmach added the comment: Thank you, both of you! I especially appreciate the further information about how setuptools and distutils play together. -- ___ Python tracker <https://bugs.python.org/issue38

[issue39394] DeprecationWarning for `flag not at the start of expression` is cutoff too early

New submission from Jürgen Gmach : The usage of flags not at the start of an expression is deprecated. Also see "Deprecate the use of flags not at the start of regular expression" / https://bugs.python.org/issue22493 A deprecation warning is issued, but is cutoff at 20

[issue39394] re: DeprecationWarning for `flag not at the start of expression` is cutoff too early

Jürgen Gmach added the comment: > Why do you want to output the full regular expression? The current output gives no clue about which flag is problematic, nor does it show the complete output (which at least would include the problematic flag), nor does it show the exact line, as it ref

[issue41963] ConfigParser: stripping of comments should be documented

New submission from Jürgen Gmach : While working on `tox-ini-fmt`, a formatter for - you guessed it - `tox.ini` files, I noticed ConfigParser strips comments when reading a config file. ( https://github.com/tox-dev/tox-ini-fmt/issues/34 ) While reasonable, this behaviour is surprising

[issue41963] ConfigParser: stripping of comments should be documented

Jürgen Gmach added the comment: This "while comments have a default value, inline comments do not" should read "while comment prefixes have a default value, inline comment prefixes do not" -- ___ Python tracker <https://bug

[issue38914] Clarify wording for warning message when checking a package

Jürgen Gmach added the comment: This issue can be closed as the related PR was merged. -- ___ Python tracker <https://bugs.python.org/issue38914> ___ ___ Pytho

[issue41978] numpy, scipy packages failed to install via pip - Windows 10 Pro 64 bit

Jürgen Gmach added the comment: While e.g. numpy already shows Python 3.9 support on their GitHub repository ( https://github.com/numpy/numpy/blob/master/setup.py ), there is no Python 3.9 compatible package on PyPI yet ( https://pypi.org/project/numpy/#files ). I guess you have to wait

[issue41963] ConfigParser: stripping of comments should be documented

Jürgen Gmach added the comment: pymotw.com shows a big red warning about comments not being preserved: https://pymotw.com/3/configparser/ -- ___ Python tracker <https://bugs.python.org/issue41

[issue42004] Allow uploading files with SimpleHTTPRequestHandler

Jürgen Gmach added the comment: Disclaimer: I am not cpython maintainer - I just wanted to give a bit of context for using `cgi.FieldStorage`. Personally, I'd rather not include this in the std, but create a small package for PyPI. But that's only me. Wait until you get feedback from

[issue41992] Unable to install lxml using pip in Python 3.9

Jürgen Gmach added the comment: There is no Python 3.9 compatible package on PyPI yet ( https://pypi.org/project/lxml/#files ). I guess you have to wait a bit more until there will be a new release. Also, this is the cpython issue tracker. When you have problems with a specific package

[issue41963] ConfigParser: stripping of comments should be documented

Jürgen Gmach added the comment: The Python wiki mentions that "writing to an INI file will wipe out all comments". https://wiki.python.org/moin/ConfigParserExamples So, when updating the docstrings, it may be a good idea to both add a note at the read methods, that comments g

[issue42004] Allow uploading files with SimpleHTTPRequestHandler

Jürgen Gmach added the comment: There is PEP 594 (draft), which - when accepted - will remove cgi.FieldStorage https://www.python.org/dev/peps/pep-0594/ https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704 This comes from an idea to relief the burden

[issue42344] SimpleNamespace: update documentation regarding comparison

New submission from Jürgen Gmach : When tinkering around with `SimpleNamespace` I tried to figure out the reasons for using it over just the `class NS: pass` alternative. One reason is the comparison, which is not a plain `id` comparison, but an attribute comparison. When looking

[issue38914] Clarify wording for warning message when checking a package

Change by Jürgen Gmach : -- pull_requests: +22160 pull_request: https://github.com/python/cpython/pull/23264 ___ Python tracker <https://bugs.python.org/issue38

[issue42344] SimpleNamespace: update documentation regarding comparison

Jürgen Gmach added the comment: Thanks for your feedback. I created a PR on github. -- keywords: +patch message_count: 2.0 -> 3.0 pull_requests: +22161 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23264 ___

[issue44086] py.svg not found on search result page

Jürgen Gmach added the comment: I was not aware there is a dedicated project for the sphinx theme. I created an issue at https://github.com/python/python-docs-theme/issues/80 Let's close this here. -- stage: -> resolved status: open ->

[issue44086] py.svg not found on search result page

New submission from Jürgen Gmach : repro: - go to docs (Python 3.11) - open dev console in browser - search for e.g ."xml rpc" -> 404 py.svg not found or open dev console and got to this URL directly: https://docs.python.org/3.11/search.html?q=xml+rpc P.S.: No 404 for the

[issue44045] canonicalize "upper-case" -> "uppercase"; "lower-case" -> "lowercase"

Jürgen Gmach added the comment: I did some more research. It looks like US English tends to use `lowercase`, while British English tends to `lower case`, and as an alternative to `lowercase` you can also use `lower-case` when using it as an adjective. See also https://en.wiktionary.org/wiki

[issue41963] ConfigParser: stripping of comments should be documented

Change by Jürgen Gmach : -- keywords: +patch pull_requests: +24814 stage: -> patch review pull_request: https://github.com/python/cpython/pull/26197 ___ Python tracker <https://bugs.python.org/issu

[issue44045] canonicalize "upper-case" -> "uppercase"; "lower-case" -> "lowercase"

Jürgen Gmach added the comment: Thank you for the feedback. I created a PR. -- ___ Python tracker <https://bugs.python.org/issue44045> ___ ___ Python-bugs-list m

[issue44045] canonicalize "upper-case" -> "uppercase"; "lower-case" -> "lowercase"

Change by Jürgen Gmach : -- keywords: +patch pull_requests: +24637 stage: -> patch review pull_request: https://github.com/python/cpython/pull/25985 ___ Python tracker <https://bugs.python.org/issu

[issue43354] xmlrpc.client: Fault.faultCode erroneously documented to be a string, should be int

Jürgen Gmach added the comment: This was merged already. I did not know I have to manually close the issue, but here we go! -- stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/i

[issue44045] canonicalize "upper-case" -> "uppercase"; "lower-case" -> "lowercase"

New submission from Jürgen Gmach : Yesterday, I was bitten by ConfigParser' default behavior to lowercase keys on reading. When I looked in the documentation and the source code, I found that lowercase was sometimes written as "lower-case", e.g. here https://docs.python.org

[issue44044] ConfigParser: cannot link to ConfigParser.optionxform(option)

Jürgen Gmach added the comment: Shreyan Avigyan, thanks for your feedback, but you are linking to the wrong section. And yes I know, there are two sections describing `optionxform`, which is the root cause for this problem in the first place. Anyway, I wanted to reference the section which

[issue44044] ConfigParser: cannot link to ConfigParser.optionxform(option)

New submission from Jürgen Gmach : I wanted to copy a hyperlink to the documentation section for ConfigParser's optionxform method, but in https://docs.python.org/3/library/configparser.html you cannot link to this one section, as the paragraph was marked with `:noindex:` via https

[issue44044] ConfigParser: cannot link to ConfigParser.optionxform(option)

Jürgen Gmach added the comment: > If that's the problem then what about merging the two sections together? That would be one solution, which I suggested in my initial comment: > Looks like a possible fix to this problem would involve a major restructuring > of the configparser docu

[issue43689] difflib: mention other "problematic" characters in documentation

Jürgen Gmach added the comment: First I need to apologize for not providing more info already when I created the issue. Initially, I did not even plan to create an issue, and thought the PR with the context of the current documentation would be sufficient information. Thanks for taking your

[issue43689] difflib: mention other "problematic" characters in documentation

New submission from Jürgen Gmach : In the documentation you can currently read for the "?"-output: "These lines can be confusing if the sequences contain tab characters." >From first hand experience :-), I can assure it is also very confusing for >other type

[issue43354] xmlrpc.client: Fault.faultCode erroneously documented to be a string, should be int

Jürgen Gmach added the comment: The approved typeshed PR: https://github.com/python/typeshed/pull/5083 -- ___ Python tracker <https://bugs.python.org/issue43

[issue43354] xmlrpc.client: Fault.faultCode erroneously documented to be a string, should be int

Change by Jürgen Gmach : -- keywords: +patch pull_requests: +23482 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24707 ___ Python tracker <https://bugs.python.org/issu

[issue43354] xmlrpc.client: Fault.faultCode erroneously documented to be a string, should be int

New submission from Jürgen Gmach : I created a XMLRPC API (via Zope), which gets consumed by a C# application. C#'s XMLRPC lib expects an `int` for the `faultCode` but I currently return a string, as this is the type which is currently documented in the official docs https://docs.python.org/3