[issue36743] Docs: Descript __get__ signature defined differently across the docs
New submission from Jon Dufresne : Here: https://docs.python.org/3/reference/datamodel.html#object.__get__ The __get__ signature is defined as: object.__get__(self, instance, owner) But here: https://docs.python.org/3/howto/descriptor.html#descriptor-protocol It is defined as: descr.__get__(self, obj, type=None) It is not clear to me as a reader if all descriptors should have the owner/type argument default to None or if it should be required. If it should default to None, I think all doc examples should follow this expectation to make it clear to someone implementing a descriptor for the first time. As best I can tell, the owner/type is always passed. So perhaps the =None shouldn't be there. Grepping the CPython code, I see lots of definitions for both required and optional, adding more confusion for me. If there is a definitive answer, I'm happy to follow through by updating the docs. -- assignee: docs@python components: Documentation messages: 341004 nosy: docs@python, jdufresne priority: normal severity: normal status: open title: Docs: Descript __get__ signature defined differently across the docs versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue36743> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28867] NamedTemporaryFile does not generate a ResourceWarning for unclosed files (unlike TemporaryFile)
Changes by Jon Dufresne <jon.dufre...@gmail.com>: -- pull_requests: +2015 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28867> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30296] Remove unnecessary tuples, lists, sets, and dicts from Lib
New submission from Jon Dufresne: Lib has some patterns that could be easily discovered and cleaned up. Doing so will reduce the number of unnecessary temporary lists in memory and unnecessary function calls. It will also take advantage of Python's own rich features in a way that better dog foods the language. For example: * Replace list() with list comprehension * Replace dict() with dict comprehension * Replace set() with set comprehension * Replace builtin func() with func() when supported (e.g. any(), all(), tuple(), min(), & max()) -- components: Library (Lib) messages: 293190 nosy: jdufresne priority: normal pull_requests: 1591 severity: normal status: open title: Remove unnecessary tuples, lists, sets, and dicts from Lib versions: Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30296> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30091] DeprecationWarning: invalid escape sequence: Only appears on first run
Jon Dufresne added the comment: Understood. Thanks for the response. I'll have to keep this in mind as I debug these warnings in the future. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30091> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30091] DeprecationWarning: invalid escape sequence: Only appears on first run
Jon Dufresne added the comment: I see. I think if the goal is for developers to see and fix these DeprecationWarnings, it would help if the warnings were reproducible without taking steps different from normal Python development. TBH, this is the first time I've ever used the -B CLI argument. For an example of where developers saw different sets of warnings which lead to confusion, see https://github.com/dateutil/dateutil/pull/358. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30091> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30091] DeprecationWarning: invalid escape sequence: Only appears on first run
New submission from Jon Dufresne: After upgrading to Python 3.6, I'm working towards cleaning up "DeprecationWarning: invalid escape sequence". I've noticed that the Deprecation warning only appears on the first run. It looks like once the code is compiled to `__pycache__`, the deprecation warning does not show. This makes debugging more difficult as I need clean out `__pycache__` directories for the runs to be reproducible. Example script: foo.py ``` import bar ``` bar.py ``` s = '\.' ``` First run ``` $ python36 -Wall foo.py .../test/bar.py:1: DeprecationWarning: invalid escape sequence \. s = '\.' ``` Second run (no DeprecationWarning) ``` $ python36 -Wall foo.py ``` Third run after cleaning ``` $ rm -rf __pycache__ $ python36 -Wall foo.py .../test/bar.py:1: DeprecationWarning: invalid escape sequence \. s = '\.' ``` I expect the deprecation warning to output on every run. -- components: Interpreter Core messages: 291805 nosy: jdufresne priority: normal severity: normal status: open title: DeprecationWarning: invalid escape sequence: Only appears on first run type: behavior versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30091> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28867] NamedTemporaryFile does not generate a ResourceWarning for unclosed files (unlike TemporaryFile)
Jon Dufresne added the comment: I decided to try a new direction. Instead of modifying _TemporaryFileCloser to handle urllib, I've changed urllib classes to not inherit from _TemporaryFileCloser. The urllib classes are not temporary files as built by tempfile, so I believe this makes more sense. There is a small amount of code copied to the existing class, but I believe this cleans up the inheritance in a way that makes more sense for the given objects and requires fewer workarounds. All feedback on this alternative approach is welcome. Thanks. -- Added file: http://bugs.python.org/file45852/namedtemporaryfile-resourcewarning-4.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28867> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28867] NamedTemporaryFile does not generate a ResourceWarning for unclosed files (unlike TemporaryFile)
Jon Dufresne added the comment: I've taken a new approach to resolve the urllib issues. I believe HTTPError _should not_ warn when __del__ is called as HTTPError wraps an existing resource instead of generating its own. IIUC, in this case, I believe it falls to the responsibility of code generating the resource to properly close and manage the resource (or pass that responsibility along). If I misunderstood, please let me know. All feedback on the patch is welcome, thanks. -- Added file: http://bugs.python.org/file45851/namedtemporaryfile-resourcewarning-3.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28867> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28867] NamedTemporaryFile does not generate a ResourceWarning for unclosed files (unlike TemporaryFile)
Jon Dufresne added the comment: Just for some context, the e.close() is handling this bit of code: https://github.com/python/cpython/blob/d8132c4da7c46587221c5a244224b770d03860b6/Lib/urllib/request.py#L739-L754 When there is no error, http_error_302() will close the passed fp, on error, it will not. The following comment indicates this is intentional: # Don't close the fp until we are sure that we won't use it # with HTTPError. But I agree, this may pose a problem when enforcing deterministic resource handling. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28867> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28867] NamedTemporaryFile does not generate a ResourceWarning for unclosed files (unlike TemporaryFile)
Jon Dufresne added the comment: Thanks for the review. I have updated the patch. Now all warnings during tests handled. Please let me know if there are any other concerns with the changes. -- Added file: http://bugs.python.org/file45789/namedtemporaryfile-resourcewarning-2.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28867> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28867] NamedTemporaryFile does not generate a ResourceWarning for unclosed files (unlike TemporaryFile)
Changes by Jon Dufresne <jon.dufre...@gmail.com>: -- keywords: +patch Added file: http://bugs.python.org/file45783/namedtemporaryfile-resourcewarning.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28867> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28867] NamedTemporaryFile does not generate a ResourceWarning for unclosed files (unlike TemporaryFile)
New submission from Jon Dufresne: When using unittest, I'll frequently enable -Wall to help catch code smells and potential bugs. One feature of this, I'm told when files aren't explicitly closed with an error like: "ResourceWarning: unclosed file <...>". I've noticed this warning is generated for an unclosed tempfile.TemporaryFile (good), but not for an unclosed tempfile.NamedTemporaryFile (possible bug). I've verified this on Python 3.5 and 3.6. Example test: ``` import tempfile import unittest class MyTest(unittest.TestCase): def test_temporary_file(self): tempfile.TemporaryFile() def test_named_temporary_file(self): tempfile.NamedTemporaryFile() ``` Actual output: ``` $ Python-3.6.0b4/python --version Python 3.6.0b4 $ Python-3.6.0b4/python -Wall -m unittest -v test test_named_temporary_file (test.MyTest) ... ok test_temporary_file (test.MyTest) ... /home/jon/test.py:7: ResourceWarning: unclosed file <_io.BufferedRandom name=3> tempfile.TemporaryFile() ok -- Ran 2 tests in 0.004s OK ``` Expected: I expect both tests to generate a ResourceWarning, as neither test explicitly closes the file. -- components: Library (Lib) messages: 282352 nosy: jdufresne priority: normal severity: normal status: open title: NamedTemporaryFile does not generate a ResourceWarning for unclosed files (unlike TemporaryFile) type: behavior versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28867> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22431] Change format of test runner output
Changes by Jon Dufresne <jon.dufre...@gmail.com>: -- nosy: +jdufresne ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22431> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20361] -W command line options and PYTHONWARNINGS environmental variable should not override -b / -bb command line options
Changes by Jon Dufresne <jon.dufre...@gmail.com>: -- nosy: +jdufresne ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue20361> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23277] Cleanup unused and duplicate imports in tests
New submission from Jon Dufresne: Ran variations of the command: $ find . -wholename '*/test/*.py' | xargs flake8 --select=F401,F811 To look for unused or duplicate imports. The attached patch removes them. -- components: Tests files: cleanup-unused-imports.patch keywords: patch messages: 234334 nosy: jdufresne priority: normal severity: normal status: open title: Cleanup unused and duplicate imports in tests versions: Python 3.6 Added file: http://bugs.python.org/file37780/cleanup-unused-imports.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23277 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23250] http.cookies HttpOnly attribute does not use suggested case-style of HTTP standard
New submission from Jon Dufresne: See http://tools.ietf.org/html/rfc6265#section-5.2.6 Relevant section: --- 5.2.6. The HttpOnly Attribute If the attribute-name case-insensitively matches the string HttpOnly, the user agent MUST append an attribute to the cookie-attribute-list with an attribute-name of HttpOnly and an empty attribute-value. ... If the cookie-attribute-list contains an attribute with an attribute-name of HttpOnly, set the cookie's http-only-flag to true. Otherwise, set the cookie's http-only-flag to false. --- http.cookies creates this attribute as `httponly` not `HttpOnly`. It is true, when interpreted by the user agent, this attribute is case insensitive, but it seems odd that Python would go out of its way to purposely use a different case then stated in the standard. When looking at other web technologies, the case used in the standard is most typical. The examples in the standard also use the `HttpOnly` style. (Same applies to the Secure flag.) -- components: Library (Lib) messages: 234132 nosy: jdufresne priority: normal severity: normal status: open title: http.cookies HttpOnly attribute does not use suggested case-style of HTTP standard type: behavior versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23250 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23250] http.cookies HttpOnly attribute does not use suggested case-style of HTTP standard
Changes by Jon Dufresne jon.dufre...@gmail.com: -- keywords: +patch Added file: http://bugs.python.org/file37729/http-only-case.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23250 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7651] Python3: guess text file charset using the BOM
Changes by Jon Dufresne jon.dufre...@gmail.com: -- nosy: +jdufresne ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7651 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23178] csv.reader does not handle BOM
New submission from Jon Dufresne:
The following test script demonstrates that Python's csv library does not
handle a BOM. I would expect the returned row to be equal to expected and to
print 'True' to stdout.
In the wild, it is typical for other CSV writers to add a BOM. MS Excel is
especially picky about the BOM when reading a utf-8 encoded file. So many
writers add a BOM for interopability with MS Excel.
If a python program accepts a CSV file as input (often the case in web apps),
these files will not be handled correctly without preprocessing. In my opinion,
this should just work when reading the file.
---
import codecs
import csv
f = open('foo.csv', 'wb')
f.write(codecs.BOM_UTF8 + b'a,b,c')
f.close()
expected = ['a', 'b', 'c']
f = open('foo.csv')
r = csv.reader(f)
row = next(r)
print(row)
print(row == expected)
---
Output
---
$ ./python ~/test.py
['\ufeffa', 'b', 'c']
False
---
--
components: Library (Lib)
messages: 233549
nosy: jdufresne
priority: normal
severity: normal
status: open
title: csv.reader does not handle BOM
type: behavior
versions: Python 3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23178
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23171] csv.writer.writerow() does not accept generator (must be coerced to list)
New submission from Jon Dufresne:
The csv.writer.writerow() does not accept a generator as input. I find this
counter-intuitive and against the spirit of similar APIs. If the generator is
coerced to a list, everything works as expected. See the following test script
which fails on the line w.writerow(g). In my opinion, this line should work
identically to the line w.writerow(list(g)).
---
import csv
f = open('foo.csv', 'w')
w = csv.writer(f)
g = (i for i in ['a', 'b', 'c'])
w.writerow(list(g))
g = (i for i in ['a', 'b', 'c'])
w.writerow(g)
---
--
components: Library (Lib)
messages: 233470
nosy: jdufresne
priority: normal
severity: normal
status: open
title: csv.writer.writerow() does not accept generator (must be coerced to list)
type: behavior
versions: Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23171
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23171] csv.writer.writerow() does not accept generator (must be coerced to list)
Jon Dufresne added the comment: I have created an initial patch such that writerow() now allows generators. I have also added a unit test to demonstrate the fix. The code now coerces iterators (and generators) to a list, then operates on the result. I would have preferred to simply iterate over the argument, however, there is a special case where the length of the argument is exactly 1. So coercing to a list makes checking the length simpler. All feedback welcome. -- keywords: +patch Added file: http://bugs.python.org/file37609/csv-gen.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23171 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
