[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 types of whitespace characters, such as spaces and line breaks. I'd like to add the other characters to the documentation. -- assignee: docs@python components: Documentation messages: 389961 nosy: docs@python, jugmac00 priority: normal pull_requests: 23879 severity: normal status: open title: difflib: mention other "problematic" characters in documentation versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue43689> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 time anyway! Also, thanks to Tim for explaining the meaning of the question mark in detail. When I read the documentation, I also had to pause a moment to understand the sentence. But I agree with Tim, it is hard to explain it better without getting much more verbose. My initial reason to read (and then to update) the documentation was an output of pytest, which left me puzzled. E AssertionError: assert 'ROOT: No tox...ith_no_t0/p\n' == 'ROOT: No tox..._with_no_t0/p' E Skipping 136 identical leading characters in diff, use -v to show E - ith_no_t0/p E + ith_no_t0/p E ?+ Here is the screenshot and some discussion: https://twitter.com/jugmac00/status/1377317886419738624 Using a similar snippet as Tim, here is a minimal example: for L in d.compare(["abcdefghijkl"], ["abcdefghijkl\n"]): print(L) - abcdefghijkl + abcdefghijkl ? + Usually, the output is pretty obvious most of the time, so I never actually noticed the question mark - except when whitespace characters are involved. I was then told that pytest uses difflib, and I was kindly pointed to the Python documentation. As only the tab character was listed, I thought it would be a good idea to add the other whitespace characters as well. After Tim's explanation, I see, that tabs could be especially confusing, while all whitespace characters are on a normal level of confusing :-), especially at the end of the diff. I certainly won't forget what I learned, but maybe my proposal helps one fellow Python user or another. -- ___ Python tracker <https://bugs.python.org/issue43689> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue43354> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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://github.com/python/cpython/pull/21859 / bpo-40204 The `:noindex:` workaround was introduced to silence doc build errors which came with a new Sphinx version. Without the workaround, you get errors like... P.S.: I uploaded a screenshot of the documentation section showing the heading before optionxform has a permalink, optionsxform does not. Warning, treated as error: /home/jugmac00/Projects/cpython/Doc/library/configparser.rst:1170:duplicate object description of configparser.ConfigParser.optionxform, other instance in library/configparser, use :noindex: for one of them Makefile:49: recipe for target 'build' failed make: *** [build] Error 2 Looks like a possible fix to this problem would involve a major restructuring of the configparser documentation, to avoid the "duplicated object description". Maybe there is a simpler solution? -- assignee: docs@python components: Documentation files: Screenshot from 2021-05-05 08-46-05.png messages: 392977 nosy: docs@python, jugmac00 priority: normal severity: normal status: open title: ConfigParser: cannot link to ConfigParser.optionxform(option) Added file: https://bugs.python.org/file50014/Screenshot from 2021-05-05 08-46-05.png ___ Python tracker <https://bugs.python.org/issue44044> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/3/library/configparser.html#configparser.ConfigParser.optionxform The webster dictionary only accepts "lowercase" as a valid English word: https://www.merriam-webster.com/dictionary/lowercase Before I wanted to create a pull request for this one, I also grepped the complete source code with the following result: lower-case24 lowercase207 upper-case 9 uppercase201 I'd like to create a pull request which canonicalizes the writing to a consistent "lowercase" resp. "uppercase". Is there any core dev out there willing to review / merge this kind of PR? -- messages: 392978 nosy: jugmac00 priority: normal severity: normal status: open title: canonicalize "upper-case" -> "uppercase"; "lower-case" -> "lowercase" ___ Python tracker <https://bugs.python.org/issue44045> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 I marked in the screenshot, and it is not possible to do so, because of the `:noxindex:` directive. -- ___ Python tracker <https://bugs.python.org/issue44044> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 documentation, to avoid the "duplicated object > description". -- ___ Python tracker <https://bugs.python.org/issue44044> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/lowercase So, to wrap up: - you could use lowercase and uppercase as a noun, as an adjective and as a verb - you can use lower case and upper case only as a noun - you can use lower-case and upper-case only as an adjective If that is true - I am no native English speaker, and Éric does not like to convert them all to single words, it gets a bit tougher. Some - to me - obvious wrong usages would be: "All IMAP4rev1 commands are supported by methods of the same name (in lower-case)." => in lower case or in lowercase "All POP3 commands are represented by methods of the same name, in lower-case; most return the response text sent by the server." => in lower case or in lowercase "Wrapper around a file that converts output to upper-case." => to upper case or to uppercase "Return a new UUID, in the format that MSI typically requires (i.e. in curly braces, and with all hexdigits in upper-case)." => in upper case or in uppercase "Hostnames are compared lower case." => lower-case or lowercase Éric, are you ok with my suggested changes or do you want me to close the issue? -- ___ Python tracker <https://bugs.python.org/issue44045> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue44045> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 docs on 3.10 -- assignee: docs@python components: Documentation files: Screenshot from 2021-05-09 10-04-17.png messages: 393308 nosy: docs@python, jugmac00 priority: normal severity: normal status: open title: py.svg not found on search result page versions: Python 3.11 Added file: https://bugs.python.org/file50027/Screenshot from 2021-05-09 10-04-17.png ___ Python tracker <https://bugs.python.org/issue44086> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 -> closed ___ Python tracker <https://bugs.python.org/issue44086> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue41963> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/specifications/core-metadata/#author ) do not enforce this behavior, so I'd like to change the wording from `must` to `should`. This can be reproduced by creating a setup.py, providing `author`, but not `author_email`, and then calling `python setup.py check` or `python -m pep517.build .`. This issue was discussed at: https://discuss.python.org/t/which-fields-are-required-for-a-setup-py-especially-is-author-required/2705 and https://github.com/pypa/pep517/issues/73 Background: I ported a 16 year old package to Python 3, and tried to upload it to PyPi. I know the author name, but not his email address. Also, I think he does not like to get bothered with emails for a project he abandoned 16 years ago. P.S.: I am working on a PR for this and update this issue accordingly. -- components: Distutils messages: 357490 nosy: dstufft, eric.araujo, jugmac00 priority: normal severity: normal status: open title: Clarify wording for warning message when checking a package type: enhancement ___ Python tracker <https://bugs.python.org/issue38914> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue38914> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 packaging (e.g myself) by doing something with the probably wrong word "must". Changing the checks is another way to fix this issue, but it is beyond my scope to say one is better or the other. -- ___ Python tracker <https://bugs.python.org/issue38914> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue38914> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 characters.
For complex expressions this is way too small.
Example ( https://github.com/jedie/python-creole/issues/31 ):
current output
/home/jugmac00/Projects/bliss_deployment/work/_/home/jugmac00/.batou-shared-eggs/python_creole-1.3.2-py3.7.egg/creole/parser/creol2html_parser.py:48
/home/jugmac00/Projects/bliss_deployment/work/_/home/jugmac00/.batou-shared-eggs/python_creole-1.3.2-py3.7.egg/creole/parser/creol2html_parser.py:48:
DeprecationWarning: Flags not at the start of the expression '(?P\n
' (truncated)
re.VERBOSE | re.UNICODE
output with patched sre_parse.py
creole/parser/creol2html_parser.py:51
/home/jugmac00/Projects/python-creole/creole/parser/creol2html_parser.py:51:
DeprecationWarning: Flags not at the start of the expression '\n\\|
\\s*\n(\n(?P [=][^|]+ ) |\n
(?P ( (?P\n\\[\\[\n(?P.+?)
\\s*\n([|] \\s* (?P.+?) \\s*)?\n]]\n
)|\n(?P\n<< \\s* (?P\\w+)
\\s* (?P.*?) \\s* >>\n
(?P(.|\\n)*?)\n<>\n)\n|(?P\n<<(?P \\w+)
(?P.*?) \\s* /*>>\n)|(?i)(?P\n{{\n
(?P.+?) \\s*\n(\\| \\s* (?P.+?)
\\s*)?\n}}\n)|(?P {{{ (?P.*?)
}}} ) | [^|])+ )\n) \\s*\n'
cell_re = re.compile(x, re.VERBOSE | re.UNICODE)
(Line number differs because there was a change in the source between these two
test runs).
I would like to create a pr and remove the limitation to 20 characters
completely, but wanted to get feedback before I do so.
The deprecation warning was created by Tim Graham - maybe he could elaborate
why it was cut at 20 chars at first?
https://github.com/python/cpython/commit/abf275af5804c5f76fbe10c5cb1dd3d2e4b04c5b
--
components: Regular Expressions
messages: 360306
nosy: ezio.melotti, jugmac00, mrabarnett
priority: normal
severity: normal
status: open
title: DeprecationWarning for `flag not at the start of expression` is cutoff
too early
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue39394>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 refers only to the line where compile gets called. The warning points to following line ( https://github.com/jedie/python-creole/blob/4e74f29daaf5026a3d4d6dae9f2e74f5f3655439/creole/parser/creol2html_parser.py#L49-L50 ): cell_re = re.compile(SpecialRules.cell, re.VERBOSE | re.UNICODE) And SpecialRules.cell is a quite a big class ( https://github.com/jedie/python-creole/blob/4e74f29daaf5026a3d4d6dae9f2e74f5f3655439/creole/parser/creol2html_rules.py#L16-L97 ) defining lots of partial expressions. Even if spotting this line ( https://github.com/jedie/python-creole/blob/4e74f29daaf5026a3d4d6dae9f2e74f5f3655439/creole/parser/creol2html_rules.py#L54 ) at the first glance it looks like it starts with the flag and should be correct (but is not as it turned out later). > Is not source file path, line number, and starting 20 characters not enough > to identify the affected regular expression? It definitely was not enough for me (new to this code base as I only tried to report deprecation warnings in my application), and when you have a look at the comment ( https://github.com/jedie/python-creole/issues/31#issuecomment-575983117 ) it even was not enough for the author/maintainer of this package. Do you expect any downside of printing the complete warning? -- ___ Python tracker <https://bugs.python.org/issue39394> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/library/xmlrpc.client.html#xmlrpc.client.Fault.faultCode This leads to a `TypeMismatch` error on the client's side. The documentation for `faultCode` is pretty much unchanged since 2007, when `xmlrpc.client.rst` was first created (at least at that place) by Georg Brandl. The docs are most probably older, but I do not know where they were managed before. I had a look at the cpython source code, and at least the tests all use ints for `faultCode` (both of them :-) ) eg https://github.com/python/cpython/blob/255f53bdb54a64b93035374ca4484ba0cc1b41e1/Lib/test/test_xmlrpc.py#L166 Having a look at the XMLRPC spec at http://xmlrpc.com/spec.md it is clearly shown that `faultCode` has to be an int. Typeshed recently added type hints for xmlrpc lib, and they used string for `faultCode` - but I guess this is just an aftereffect from the faulty documentation. https://github.com/python/typeshed/pull/3834 I suggest to both update cpython's documentation and to create a PR for typeshed in order to fix the type issue. If any core dev agrees on this, I'd like to prepare the pull requests. Thanks for taking your time to look into this! -- assignee: docs@python components: Documentation messages: 387866 nosy: docs@python, jugmac00 priority: normal severity: normal status: open title: xmlrpc.client: Fault.faultCode erroneously documented to be a string, should be int versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue43354> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue43354> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue43354> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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, as it is neither documented at https://docs.python.org/3/library/configparser.html nor in the docstrings (read and _read) which I read at first. The stripping of comments is only documented with inline comments https://github.com/jugmac00/cpython/blob/610a60c601fb4380eee30e15be1cd4dcbdaeec4c/Lib/configparser.py#L1019 and https://github.com/jugmac00/cpython/blob/610a60c601fb4380eee30e15be1cd4dcbdaeec4c/Lib/configparser.py#L1031 Once I found these comments, I was surprised once again, as in my code the inline comments were not stripped. After some more pdb-ing and reading the source of ConfigParser, I noticed that - while comments have a default value, inline comments do not - and that is why when you read a config file, some comments get removed and others not. I'd like to work on a pull request to document this behaviour, both in the official documentation and in the docstrings of the read and the _read methods. -- messages: 378146 nosy: jugmac00 priority: normal severity: normal status: open title: ConfigParser: stripping of comments should be documented ___ Python tracker <https://bugs.python.org/issue41963> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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://bugs.python.org/issue41963> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 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, it is best to seek help at their issue tracker. For numpy this would be https://github.com/numpy/numpy/issues Actually, there is already an issue on their tracker about support for Python 3.9 https://github.com/numpy/numpy/issues/17482 I suggest to close this issue here. -- nosy: +jugmac00 ___ Python tracker <https://bugs.python.org/issue41978> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 get ignored and to the write method(s) that on writing, the possible previous existing comments get removed. Are there any thoughts on this or should I go forward and create a pull request? -- ___ Python tracker <https://bugs.python.org/issue41963> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue41963> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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, it is best to seek help at their issue tracker. For lxml this would be https://launchpad.net/lxml Actually, there is already an issue on their tracker about support for Python 3.9 https://bugs.launchpad.net/lxml/+bug/1892261 I suggest to close this issue here. -- nosy: +jugmac00 ___ Python tracker <https://bugs.python.org/issue41992> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 of maintenance for the maintainers. Some off-topic comments... cgi.FieldStorage has quite some unresolved issues, partially open for many years, although there are also some pull requests, waiting for review. While cgi.FieldStorage is certainly a niche thing, it is used by Zope, by Plone, by webob... The latter even has a 250 line compat module to accomodate for current bugs ( https://github.com/Pylons/webob/blob/5c062aef9397b27915c5cc2ed2f202bff7494eca/src/webob/compat.py ). If you, Javier, are also a fan of cgi.FieldStorage want to improve the situation with cgi.FieldStorage, maybe you could help reviewing the open issues and the open pull requests for cpython? -- nosy: +jugmac00 ___ Python tracker <https://bugs.python.org/issue42004> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 a cpython maintainer. -- ___ Python tracker <https://bugs.python.org/issue42004> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 at the documentation of the imaginary python implementation, where only dicts are compared, the reader (me) could think you can compare it to classes. https://docs.python.org/3/library/types.html?highlight=simplenamespace#types.SimpleNamespace ``` >>> from types import SimpleNamespace >>> simple_ns = SimpleNamespace(a=1, b="two") >>> class NS: pass >>> class_ns = NS() >>> class_ns.a = 1 >>> class_ns.b = "two" >>> simple_ns == class_ns >>> False ``` Actually, the C implementation compares the types, too. https://github.com/python/cpython/blob/bc777047833256bc6b10b2c7b46cce9e9e6f956c/Objects/namespaceobject.c#L163-L171 While the documentation says the Python impl is "roughly equivalent", I's still suggest to update the documentation. If there is some agreement, I'd create a pull request. -- messages: 380882 nosy: jugmac00 priority: normal severity: normal status: open title: SimpleNamespace: update documentation regarding comparison ___ Python tracker <https://bugs.python.org/issue42344> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue38914> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ___ Python tracker <https://bugs.python.org/issue42344> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
