[issue43979] Simplify urllib.parse_qsl
Christoph Zwerschke added the comment: I don't mind if you reopen your PR. But thanks for asking. -- ___ Python tracker <https://bugs.python.org/issue43979> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43979] Simplify urllib.parse_qsl
Christoph Zwerschke added the comment: I saw you submitted a PR already which looks good to me. -- ___ Python tracker <https://bugs.python.org/issue43979> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43979] Simplify urllib.parse_qsl
New submission from Christoph Zwerschke : Just noticed the following code in urrlib.parse_qsl: pairs = [s1 for s1 in qs.split(separator)] for name_value in pairs: ... see https://github.com/python/cpython/blob/088a15c49d99ecb4c3bef93f8f40dd513c6cae3b/Lib/urllib/parse.py#L755 This looks like an unnecessary list comprehension to me, probably a relic of earlier code that used a nested list comprehension for splitting with two different separators. Can't we just do this instead now, which is faster and shorter? for name_value qs.split(separator): I can provide a PR if wanted. -- components: Library (Lib) messages: 392345 nosy: cito priority: normal severity: normal status: open title: Simplify urllib.parse_qsl type: performance 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/issue43979> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27777] cgi.FieldStorage can't parse simple body with Content-Length and no Content-Disposition
Christoph Zwerschke added the comment: Just created a test case for this problem after a pentest provoked this error on one of my web apps. Then I found this bug report which already has a similar test case attached. The problem is that read_binary() as the name says reads binary data, but then writes it to a file which may or may not be binary, depending on whether self._binary_file is set, which depends on whether a filename was set via the content-disposition header. Jakub's patch looks good and works for me. Please merge this! -- ___ Python tracker <https://bugs.python.org/issue2> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1375011] http.cookies, Cookie.py: Improper handling of duplicate cookies
Christoph Zwerschke added the comment: This patch should really be included. As carl already mentioned, the relevant spec is RFC 6265, see section 5.4.2: "The user agent SHOULD sort the cookie-list in the following order: Cookies with longer paths are listed before cookies with shorter paths. Among cookies that have equal-length path fields, cookies with earlier creation-times are listed before cookies with later creation-times." Currently, if the cookies are loaded with cookies.load(env['HTTP_COOKIE']) as most web frameworks do, then the cookies will be populated with the least specific or oldest values if there are duplicates. This is really bad. -- nosy: +cito ___ Python tracker <https://bugs.python.org/issue1375011> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18319] gettext() cannot find translations with plural forms
Change by Christoph Zwerschke : -- nosy: +cito ___ Python tracker <https://bugs.python.org/issue18319> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35228] Index search in CHM help crashes viewer
Christoph Zwerschke added the comment: Had the same problem for years and wondered why nobody else complained. Still reproducable with Win 10 Pro 2004, Python 3.8, cp1252 locale. Deleting hh.dat did not solve the problem for me. -- nosy: +cito ___ Python tracker <https://bugs.python.org/issue35228> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38531] argparse action "extend" not documented as new
New submission from Christoph Zwerschke : A new action "extend" has been added to argparse in https://github.com/python/cpython/commit/aa32a7e1116f7aaaef9fec453db910e90ab7b101 The documentation should specify that this is new in Python 3.8 addition. I wondered why it didn't work in Python 3.7. -- assignee: docs@python components: Documentation messages: 354966 nosy: cito, docs@python priority: normal severity: normal status: open title: argparse action "extend" not documented as new type: enhancement versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue38531> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27777] cgi.FieldStorage can't parse simple body with Content-Length and no Content-Disposition
Christoph Zwerschke added the comment: This also happens when sending POST requests with JSON payload from a browser with XMLHttpRequest to a Python 3.7 backend using FieldStorage. It seems XMLHttpRequest adds the content length automatically. -- ___ Python tracker <https://bugs.python.org/issue2> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27777] cgi.FieldStorage can't parse simple body with Content-Length and no Content-Disposition
Change by Christoph Zwerschke : -- nosy: +cito ___ Python tracker <https://bugs.python.org/issue2> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37110] Clarify hashability of custom class instances
Christoph Zwerschke added the comment: My point was that it's not immediately obvious what "by default" means and that hashability is not only affected by the __hash__ method but also by __eq__. But I agree, you can argue that "by default" already includes not adding any special methods like __eq__ and the glossary should not become too verbose. (I remember these words from Donald Knuth in one of his books: "In the interest of conciseness, you need to indulge in simplifications that are really little lies; these should be overlooked.") -- ___ Python tracker <https://bugs.python.org/issue37110> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37110] Clarify hashability of custom class instances
New submission from Christoph Zwerschke : The Python documentation says about hashability in the glossary (https://docs.python.org/3/glossary.html#term-hashable): "Objects which are instances of user-defined classes are hashable by default." This is not quite true. Objects of a user-defined class with an __eq__ method are not hashable. Maybe it would be better to make this more explicit: "Objects which are instances of user_defined classes without custom __eq__ and __hash__ methods are hashable by default." -- assignee: docs@python components: Documentation messages: 344042 nosy: cito, docs@python priority: normal severity: normal status: open title: Clarify hashability of custom class instances type: enhancement versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue37110> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34730] aclose() doesn't stop raise StopAsyncIteration / GeneratorExit to __anext__()
Change by Christoph Zwerschke : -- nosy: +cito ___ Python tracker <https://bugs.python.org/issue34730> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31140] Insufficient error message with incorrect formated string literal
Christoph Zwerschke <c...@online.de> added the comment:
I can confirm that the problem still exists in Python 3.6.4 and 3.7.0a4.
Here is another way to demonstrate it:
Create the following file test.py:
# test
hello = f"{world)}"
Note that there is a syntax error in the f-string in line 2 which has a closing
parentheses, but no opening one.
Import this from Python 3.6.4 or 3.7.0a4:
>>> import test
Traceback (most recent call last):
File "", line 1, in
File "", line 1
(world))
^
SyntaxError: unexpected EOF while parsing
The problem here is that the error message does not contain the name of the
erroneous file (test.py), points to a wrong line (line 1 instead of line 2),
and also shows parentheses instead of braces around the word "world", which are
not there in the original code. This can make it hard to locate such errors.
Note that when there are other kinds of errors in the f-string, or other kinds
of "unexpected EOF" in the imported file, the errorenous file is usually
reported correctly in the error message. Only certain kinds of syntax errors in
f-strings seem to be problematic.
--
nosy: +cito
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31140>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1697943] msgfmt cannot cope with BOM
Christoph Zwerschke added the comment: > Corresponding GNU gettext issue [1] was closed as "Not a Bug". Though I think the rationale given there pointing to RFC3629 section 6 is wrong, since that section explicitly refers to Internet protocols, but PO files are not an Internet protocol. Anyway, if silently ignoring BOMs is considered a bad idea, then at least there should be a more helpful error message. Because the BOM is invisible, users - who may not even be aware that something like a BOM exist or that their editor saves files with BOM - may be frustrated about the current error message because they don't see any invalid character when they open the PO file in their editor. A more explicit error message like "PO files should not be saved with a byte order mark" might point users in the right direction. After all, these tools are supposed to be used directly by human beings on the command line. Who said that command line tools must not be user friendly? -- status: pending -> open versions: +Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue1697943> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15207] mimetypes.read_windows_registry() uses the wrong regkey, creates wrong mappings
Christoph Zwerschke added the comment: After this patch, some of the values in mimetypes.types_map now appear as unicode instead of str in Python 2.7.7 under Windows. For compatibility and consistency reasons, I think this should be fixed so that all values are returned as str again under Python 2.7. See https://groups.google.com/forum/#!topic/pylons-devel/bq8XiKlGgv0 for a real world issue which I think is caused by this bugfix. -- nosy: +cito ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15207 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17326] Windows build docs still referring to VS 2008 in 3.3
New submission from Christoph Zwerschke: The first paragraph in PCbuild/readme.txt of Python 3.3 still talks about Visual C++ 2008 Express and Visual Studio 2008. It says that VS 2008 is required at the very least (which may be still true, I'm not sure), but then it also says the official Python releases are built with this [i.e. the 2008] version of VS, while it seems they have been built with VS 2010 in reality (as the title is also indicating). -- assignee: docs@python components: Documentation messages: 183259 nosy: cito, docs@python priority: normal severity: normal status: open title: Windows build docs still referring to VS 2008 in 3.3 type: enhancement versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17326 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7402] reduce() is an anti-example in Idioms and Anti-Idioms
Christoph Zwerschke c...@online.de added the comment: My point was that the passage starts with there are also many useful built-in functions people seem not to be aware of for some reasons and then it looks like the author himself was not aware of sum() for some reason because he gives calculating a sum with reduce() as a classical example. It's very hard to come up with good examples for reduce() and I think in newer Python versions it has been demoted from builtin to functools, so it's not a good example for a useful built-in fuction anyway. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7402 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7402] reduce() is an anti-example in Idioms and Anti-Idioms
New submission from Christoph Zwerschke c...@online.de: In the section Using the batteries of the Idioms and Anti-Idioms in Python document (http://docs.python.org/dev/howto/doanddont.html#using-the-batteries), the reduce statement is used for summing up numbers as an example. I think this is rather an anti-example, because Python already has a sum function built-in, i.e. reduce(operator.add, nums)/len(nums) can be written much simpler as sum(nums)/len(nums). -- assignee: georg.brandl components: Documentation messages: 95762 nosy: cito, georg.brandl severity: normal status: open title: reduce() is an anti-example in Idioms and Anti-Idioms versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7402 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2504] Add gettext.pgettext() and variants support
Changes by Christoph Zwerschke c...@online.de: -- nosy: +cito ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2504 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6777] Python 2.6 tutorial still recommends using Exception.message attribute
New submission from Christoph Zwerschke c...@online.de: The Python 2.6.2 tutorial says at the end of secton 8.3 (http://docs.python.org/tutorial/errors.html#handling-exceptions): But use of .args is discouraged. Instead, the preferred use is to pass a single argument to an exception (which can be a tuple if multiple arguments are needed) and have it bound to the message attribute. It seems this is not true any more, the idea has been retracted so that it's now the other way around again: .args can still be used, but .message is deprecated (see http://www.python.org/dev/peps/pep- 0352/#retracted-ideas). The examples classes in section 8.5 of the Tutorial, using the .message attribute should be also adapted because they raise a DeprecationWarning in Python 2.6.2. -- assignee: georg.brandl components: Documentation messages: 91937 nosy: cito, georg.brandl severity: normal status: open title: Python 2.6 tutorial still recommends using Exception.message attribute versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6777 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6423] The cgi docs should advertize using in instead of has_key
New submission from Christoph Zwerschke c...@online.de: The cgi.Fieldstorage class supports the __contains__ method since Py 2.2, but the documentation of Py 2.6 still only mentions the old fashioned has_key method. See patch. -- assignee: georg.brandl components: Documentation files: cgi.patch keywords: patch messages: 90158 nosy: cito, georg.brandl severity: normal status: open title: The cgi docs should advertize using in instead of has_key versions: Python 2.6 Added file: http://bugs.python.org/file14456/cgi.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6423 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4799] handling inf/nan in '%f'
Christoph Zwerschke c...@online.de added the comment: This is a related problem on Windows: '%g' % 1e400 - '1.#INF' '%.f' % 1e400 -- '1' -- nosy: +cito ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4799 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4713] Installing sgmlop can crash xmlrpclib
New submission from Christoph Zwerschke c...@online.de: If you install sgmlop (downloadable from http://effbot.org/downloads/#sgmlop) under Python 2.x, then this can break xmlrpclib. You can reproduce this problem as follows (I have tested with Py 2.4, 2.5 and 2.6): data = ?xml version=1.0 encoding=UTF-8? methodCallmethodNamef/methodNameparams paramvaluek#228;se/value/param /params/methodCall import xmlrpclib assert xmlrpclib.FastParser is None print xmlrpclib.SgmlopParser and 'with' or 'without', 'sgmlop' assert xmlrpclib.loads(data) == ((u'k\xe4se',), 'f') If sgmlop is installed, this gives a UnicodeDecodeError, otherwise everything works well. This happens because xmlrpclib prefers using sgmlop over lib.parsers.expat, but fails to handle numeric character entities properly with this parser. Find attached a patch that fixes this problem. I also wonder whether lib.parsers.expat shouldn't be preferred over sgmlop, since the latter is somewhat outdated, and installing external libraries should not cause crashes or wrong behavior of standard lib modules (see also Issue1772916 for a similar problem). -- components: Library (Lib) messages: 78156 nosy: cito severity: normal status: open title: Installing sgmlop can crash xmlrpclib type: crash versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4713 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4713] Installing sgmlop can crash xmlrpclib
Changes by Christoph Zwerschke c...@online.de: -- keywords: +patch Added file: http://bugs.python.org/file12418/xmlrpclib.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4713 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1697943] msgfmt cannot cope with BOM
Christoph Zwerschke [EMAIL PROTECTED] added the comment: Small improvement of the patch: Instead of hardcoding the BOM as '\xef\xbb\xbf', we should use codecs.BOM_UTF8. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1697943 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3354] sort(reverse=None) prints misleading error message
New submission from Christoph Zwerschke [EMAIL PROTECTED]: When you sort a list with list.sort() or sorted(list), and set the reverse parameter to None, then you get the following misleading error message: TypeError: an integer is required I would expect a more proper error message for the reverse parameter, such as reverse must be a boolean, and maybe reverse=None also accepted as default value, i.e. False. -- components: Interpreter Core messages: 69651 nosy: cito severity: normal status: open title: sort(reverse=None) prints misleading error message type: behavior versions: Python 2.4, Python 2.5, Python 2.6 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3354 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3354] sort(reverse=None) prints misleading error message
Christoph Zwerschke [EMAIL PROTECTED] added the comment: The problem is not only that the error message TypeError: an integer is required has integer instead of boolean, but it does not mention the attribute name reverse, i.e. it does not even say *where* the integer is required. I firmly believe error messages should not only be technically correct, but also precise, meaningful and helpful for the user. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3354 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3354] Improve error reporting for the argument parsing API
Christoph Zwerschke [EMAIL PROTECTED] added the comment: Agree. Seems to be a more general weakness of the argument parsing of builtin functions and methods, that calls for a general solution instead of a local patch. Luckily there are not so many cases where the errors are misleading, since the builtin functions have very few and mostly positioned parameters, so the problem is not as bad as it seems. There may be only very few cases, like the example above, where the errors are really too unspecific or misleading. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3354 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2481] locale.strxfrm does not work with Unicode strings
New submission from Christoph Zwerschke [EMAIL PROTECTED]: While locale.strcoll seems to work with Unicode strings, locale.strxfrm gives a UnicodeError. Example: ### try: locale.setlocale(locale.LC_ALL, 'de') except locale.Error: # Windoof locale.setlocale(locale.LC_ALL, 'german') s = ['Ägypten', 'Zypern'] print sorted(s, cmp=locale.strcoll) # works print sorted(s, key=locale.strxfrm) # works s = [u'Ägypten', u'Zypern'] print sorted(s, cmp=locale.strcoll) # works print sorted(s, key=locale.strxfrm) # UnicodeError ### Therefore, it is not possible to sort lists of Unicode strings effectively. If possible, this should be fixed. If not possible, this problem should at least be mentioned in the documentation. Currently, the docs do not indicate that strcoll and strxfrm behave differently concerning Unicode. -- components: Unicode messages: 64484 nosy: cito severity: normal status: open title: locale.strxfrm does not work with Unicode strings type: behavior versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2481 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2217] Problem with if clause in generator expression on class level
Christoph Zwerschke added the comment: Thanks, this now makes sense to me. You're right, it's rather an ugly wart than a bug. But I think the Python reference needs to be improved to make this clear enough. How about the following proposed addtions (in square brackets) to section 5.2.5 (http://docs.python.org/ref/genexpr.html): Variables used in the generator expression are evaluated lazily [in the scope of the generator function] when the next() method is called for [the] generator object (in the same fashion as normal generators). However, the leftmost for clause is immediately evaluated [in the current scope] so that [an] error produced by it can be seen before any other possible error in the code that handles the generator expression. Subsequent for [and if] clauses cannot be evaluated immediately since they may depend on the previous for loop. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2217 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
