[issue37195] test_utime fails on MacOS Mojave (Kernel Version 18.6.0:)
Felipe Rodrigues added the comment: Hi all! I'm seeing the same error that @pablogsal saw here, but I'm on Linux Mint 20.1 x86_64 (Kernel 5.4.0-77): ./python -m test test_os -R : -v == CPython 3.11.0a0 (heads/pr_26964:d375c08c75, Jul 3 2021, 07:47:01) [GCC 9.3.0] == Linux-5.4.0-77-generic-x86_64-with-glibc2.31 little-endian == cwd: /home/fbidu/collab/cpython/build/test_python_276759æ == CPU count: 8 == encodings: locale=UTF-8, FS=utf-8 0:00:00 load avg: 0.71 Run tests sequentially 0:00:00 load avg: 0.71 [1/1] test_os (...) == FAIL: test_utime (test.test_os.UtimeTests) -- Traceback (most recent call last): File "/home/fbidu/collab/cpython/Lib/test/test_os.py", line 797, in test_utime self._test_utime(set_time) File "/home/fbidu/collab/cpython/Lib/test/test_os.py", line 785, in _test_utime self.assertAlmostEqual(st.st_atime, atime_ns * 1e-9, delta=1e-6) AssertionError: 1.0 != 1.002003 within 1e-06 delta (0.0020029977 difference) == FAIL: test_utime_by_indexed (test.test_os.UtimeTests) -- Traceback (most recent call last): File "/home/fbidu/collab/cpython/Lib/test/test_os.py", line 815, in test_utime_by_indexed self._test_utime(set_time) File "/home/fbidu/collab/cpython/Lib/test/test_os.py", line 785, in _test_utime self.assertAlmostEqual(st.st_atime, atime_ns * 1e-9, delta=1e-6) AssertionError: 1.0 != 1.002003 within 1e-06 delta (0.0020029977 difference) == FAIL: test_utime_by_times (test.test_os.UtimeTests) -- Traceback (most recent call last): File "/home/fbidu/collab/cpython/Lib/test/test_os.py", line 824, in test_utime_by_times self._test_utime(set_time) File "/home/fbidu/collab/cpython/Lib/test/test_os.py", line 785, in _test_utime self.assertAlmostEqual(st.st_atime, atime_ns * 1e-9, delta=1e-6) AssertionError: 1.0 != 1.002003 within 1e-06 delta (0.0020029977 difference) == FAIL: test_utime_dir_fd (test.test_os.UtimeTests) -- Traceback (most recent call last): File "/home/fbidu/collab/cpython/Lib/test/test_os.py", line 857, in test_utime_dir_fd self._test_utime(set_time) File "/home/fbidu/collab/cpython/Lib/test/test_os.py", line 785, in _test_utime self.assertAlmostEqual(st.st_atime, atime_ns * 1e-9, delta=1e-6) AssertionError: 1.0 != 1.002003 within 1e-06 delta (0.0020029977 difference) == FAIL: test_utime_directory (test.test_os.UtimeTests) -- Traceback (most recent call last): File "/home/fbidu/collab/cpython/Lib/test/test_os.py", line 863, in test_utime_directory self._test_utime(set_time, filename=self.dirname) File "/home/fbidu/collab/cpython/Lib/test/test_os.py", line 785, in _test_utime self.assertAlmostEqual(st.st_atime, atime_ns * 1e-9, delta=1e-6) AssertionError: 1.0 != 1.002003 within 1e-06 delta (0.0020029977 difference) == FAIL: test_utime_fd (test.test_os.UtimeTests) -- Traceback (most recent call last): File "/home/fbidu/collab/cpython/Lib/test/test_os.py", line 844, in test_utime_fd self._test_utime(set_time) File "/home/fbidu/collab/cpython/Lib/test/test_os.py", line 785, in _test_utime self.assertAlmostEqual(st.st_atime, atime_ns * 1e-9, delta=1e-6) AssertionError: 1.0 != 1.002003 within 1e-06 delta (0.0020029977 difference) == FAIL: test_utime_nofollow_symlinks (test.test_os.UtimeTests) -- Traceback (most recent call last): File "/home/fbidu/collab/cpython/Lib/test/test_os.py", line 834, in test_utime_nofollow_symlinks self._test_utime(set_time) File "/home/fbidu/collab/cpython/Lib/test/test_os.py", line 785, in _test_utime self.assertAlmostEqual(st.st_atime, atime_ns * 1e-9, delta=1e-6) AssertionError: 1.0 != 1.002003 within 1e-06 delta (0.0020029977 difference) -- Ran 314 tests in 1.172s FAILED (failures=7, skipped=46) Additional info based on what a
[issue44539] Imghdr JPG Quantized
Change by Felipe Rodrigues : -- nosy: +fbidu ___ Python tracker <https://bugs.python.org/issue44539> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4476] compileall fails if current dir has a "types" package
Change by Felipe Rodrigues : -- nosy: +fbidu nosy_count: 5.0 -> 6.0 pull_requests: +26023 pull_request: https://github.com/python/cpython/pull/27509 ___ Python tracker <https://bugs.python.org/issue4476> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44766] [easy doc] Remove redundant info in README.valgrind
Change by Felipe Rodrigues : -- keywords: +patch nosy: +fbidu nosy_count: 2.0 -> 3.0 pull_requests: +26026 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27509 ___ Python tracker <https://bugs.python.org/issue44766> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4476] compileall fails if current dir has a "types" package
Felipe Rodrigues added the comment: sorry about the noise, everyone. Missed an '6' in the end of the issue name -- ___ Python tracker <https://bugs.python.org/issue4476> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4476] compileall fails if current dir has a "types" package
Change by Felipe Rodrigues : -- pull_requests: -26023 ___ Python tracker <https://bugs.python.org/issue4476> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40042] Enum Flag: psuedo-members have None for name attribute
New submission from Felipe Rodrigues : Hi, Can you elaborate on this? Thanks! -- nosy: +fbidu ___ Python tracker <https://bugs.python.org/issue40042> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41220] add optional make_key argument to lru_cache
Felipe Rodrigues added the comment: Hello all, I love discussions about caching! While I do see the point of Itayazolay's proposal, I think that it should be on the _caller_ to solve the caching issue, and not on the _callee_ to provide a way to make it happen. That is, I think that if one wants to use a cache, they should make sure their arguments are hashable and not that we should modify called functions to provide workarounds for those. -- nosy: +fbidu ___ Python tracker <https://bugs.python.org/issue41220> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41220] add optional make_key argument to lru_cache
Felipe Rodrigues added the comment: Correction: (...) on the _caller_ to solve the hashing* issue (...) -- ___ Python tracker <https://bugs.python.org/issue41220> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37943] mimetypes.guess_extension() doesn’t get JPG right
Felipe Rodrigues added the comment:
@_savage, on the commit @xtreak referred, there's a note that "image/jpg" and
some other non-standard mimetypes are only supported if `strict=False`[1]
So, this:
>>> mimetypes.guess_extension("image/jpg")
Gives no return. But this works:
>>> mimetypes.guess_extension("image/jpg", strict=False)
'.jpg'
-
I guess we could improve the current documentation [2]. It currently specifies
correctly the `strict` behavior:
> The optional strict argument is a flag specifying whether the list of known
> MIME types is limited to
> only the official types registered with IANA. When strict is True (the
> default), only the IANA types
> are supported; when strict is False, some additional non-standard but
> commonly used MIME types are
> also recognized.
But I think it would be nice to have a table specifying what are those
"non-standard but commonly used MIME types". Personally, I'd have a hard time
guessing on a regular day of my life which of 'image/jpeg' and 'image/jpg' is
standard or not. We could even add a nice note pointing out that the
`common_types` property [3] is a list of those supported non-standard type .
Given the fact that the `strict` flag is used by different methods with the
same behavior, maybe we could add a note on the top of the doc explaining the
general meaning of that flag.
[1]:
https://github.com/python/cpython/commit/2a99fd911ebeecedbb250a05667cd46eca4735b9#diff-fc65388a9cdf41980b2c31de5de67758R547
[2]: https://docs.python.org/3.10/library/mimetypes.html#mimetypes.guess_type
[3]: https://docs.python.org/3.10/library/mimetypes.html#mimetypes.common_types
--
nosy: +fbidu
___
Python tracker
<https://bugs.python.org/issue37943>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42060] Usage of assert in http/client.py
New submission from Felipe Rodrigues : Hi all! I was testing some static analysis tool and decided to use the HTTP module as testing ground. While running `bandit` at the client module, it detected 3 instances of using `assert` inside the code. Twice in the HTTPResponse class and once in the HTTPConnection class. Now, I know that this will only cause any trouble when running python with the optimize settings turned on and if someone is that concerned about optimization, they probably won't be using the stdlib's HTTP implementation, but I think it would be fitting to fix this corner case. I've written a PR that fixes this but I'm not sure if the raised exceptions and messages are ok -- components: Library (Lib) messages: 378810 nosy: fbidu priority: normal severity: normal status: open title: Usage of assert in http/client.py versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue42060> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42060] Usage of assert in http/client.py
Change by Felipe Rodrigues : -- keywords: +patch pull_requests: +21700 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22737 ___ Python tracker <https://bugs.python.org/issue42060> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42062] Usage of HTTPResponse.url
New submission from Felipe Rodrigues :
Hello all,
While testing some static analysis tools on HTTP/client.py, Pylint pointed
me to HTTPResponse.geturl() method with a "no-member" error for the `url`
attribute. I tried invoking the `geturl` method and reading the
`HTTPResponse.url` attribute using a sample code from the official docs:
```
import http.client
conn = http.client.HTTPSConnection("www.python.org")
conn.request("GET", "/")
r1 = conn.getresponse()
print(r1.status, r1.reason)
r1.geturl()
r1.url
```
```
import http.client
conn = http.client.HTTPSConnection("www.python.org")
conn.request("GET", "/")
r1 = conn.getresponse()
data1 = r1.read()
conn.request("GET", "/")
r1 = conn.getresponse()
while chunk := r1.read(200):
print(repr(chunk))
r1.geturl()
r1.url
```
Both of those examples will raise an `AttributeError: 'HTTPResponse' object has
no attribute 'url'`.
I tried searching through this module's history from when this line originally
appeared,
https://github.com/python/cpython/commit/6c5e28c383bf587f80d01e52f887801be200200d
but
I wasn't able to find this attribute being set internally by the class, even
though there is an `url` attribute at __init__.
So, I wonder if this attribute was intended to be set externally as in `r1.url
= 'something'`
or if it is just a bug
--
components: Library (Lib)
messages: 378814
nosy: fbidu
priority: normal
severity: normal
status: open
title: Usage of HTTPResponse.url
___
Python tracker
<https://bugs.python.org/issue42062>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42062] Usage of HTTPResponse.url
Change by Felipe Rodrigues : -- keywords: +patch pull_requests: +21701 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22738 ___ Python tracker <https://bugs.python.org/issue42062> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13464] HTTPResponse is missing an implementation of readinto
Change by Felipe Rodrigues : -- nosy: +fbidu nosy_count: 5.0 -> 6.0 pull_requests: +21847 pull_request: https://github.com/python/cpython/pull/22737 ___ Python tracker <https://bugs.python.org/issue13464> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21032] Socket leak if HTTPConnection.getresponse() fails
Change by Felipe Rodrigues : -- nosy: +fbidu nosy_count: 3.0 -> 4.0 pull_requests: +21848 pull_request: https://github.com/python/cpython/pull/22737 ___ Python tracker <https://bugs.python.org/issue21032> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34728] deprecate *loop* argument for asyncio.sleep
Change by Felipe Rodrigues : -- nosy: +fbidu ___ Python tracker <https://bugs.python.org/issue34728> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34576] [EASY doc] http.server, SimpleHTTPServer: warn users on security
Felipe Rodrigues added the comment: Well, even if we do fix some security issues in SimpleHTTPServer, it doesn't change the fact that it shouldn't really be used for sensitive applications. I like how Django docs handles a similar issue regarding their development server (https://docs.djangoproject.com/en/2.1/ref/django-admin/#runserver) > DO NOT USE THIS SERVER IN A PRODUCTION SETTING. It has not gone through > security audits or performance tests. (And that’s how it’s gonna stay. We’re > in the business of making Web frameworks, not Web servers, so improving this > server to be able to handle a production environment is outside the scope of > Django.) I think that the same philosophy applies to SimpleHTTPServer. If the warning should be add to the docs, I'll be glad to issue an PR fixing it! -- nosy: +fbidu ___ Python tracker <https://bugs.python.org/issue34576> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34832] "Short circuiting" in base64's b64decode, decode, decodebytes
Felipe Rodrigues added the comment: I am not sure if simply ignoring the non-valid character is the best way to go. Feels like silencing errors. b64decode does accept the 'validate' flag - defaulted to False - that will halt the execution and throw an error. What might be a good idea is to implement an 'errors' argument that accepts 'ignore' as a value, like we do for bytes.decode (https://docs.python.org/3/library/stdtypes.html#bytes.decode) -- nosy: +fbidu ___ Python tracker <https://bugs.python.org/issue34832> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34832] "Short circuiting" in base64's b64decode, decode, decodebytes
Felipe Rodrigues added the comment: Actually, I'm not even sure if it makes sense to decode the 'first valid substring'... IMHO, we should warn the user -- ___ Python tracker <https://bugs.python.org/issue34832> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34832] "Short circuiting" in base64's b64decode, decode, decodebytes
Felipe Rodrigues added the comment:
For reference in future discussions, Python's base64 module implements RFC 3548
(https://tools.ietf.org/html/rfc3548) whose section 2.3
(https://tools.ietf.org/html/rfc3548#section-2.3) discusses about
"Interpretation of non-alphabet characters in encoded data".
The section's content is:
Base encodings use a specific, reduced, alphabet to encode binary
data. Non alphabet characters could exist within base encoded data,
caused by data corruption or by design. Non alphabet characters may
be exploited as a "covert channel", where non-protocol data can be
sent for nefarious purposes. Non alphabet characters might also be
sent in order to exploit implementation errors leading to, e.g.,
buffer overflow attacks.
Implementations MUST reject the encoding if it contains characters
outside the base alphabet when interpreting base encoded data, unless
the specification referring to this document explicitly states
otherwise. Such specifications may, as MIME does, instead state that
characters outside the base encoding alphabet should simply be
ignored when interpreting data ("be liberal in what you accept").
Note that this means that any CRLF constitute "non alphabet
characters" and are ignored. Furthermore, such specifications may
consider the pad character, "=", as not part of the base alphabet
until the end of the string. If more than the allowed number of pad
characters are found at the end of the string, e.g., a base 64 string
terminated with "===", the excess pad characters could be ignored.
In my opinion, the RFC is rather permissive about strange characters in the
encoded data. The RFC refers to the MIME specification that ignores the data
and hints the possibility of rejecting the pad symbol '=' unless it is found in
the end of the string.
I think that our best option if we would like to address this issue is to add
an 'errors' argument whose default value will keep the current behavior for
backwards compatibility but will accept more options in order to both ignore
the strange characters and carry on with the processing - like bytes.decode's
errors=ignore flag - and to raise an error in such situations, like
bytes.decode's errors=strict.
--
___
Python tracker
<https://bugs.python.org/issue34832>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34576] [EASY doc] http.server, SimpleHTTPServer: warn users on security
Change by Felipe Rodrigues : -- keywords: +patch pull_requests: +9103 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue34576> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26005] Denial of Service in SimpleHTTPServer and BaseHTTPServer
Change by Felipe Rodrigues : -- pull_requests: +9104 ___ Python tracker <https://bugs.python.org/issue26005> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25416] Add encoding aliases from the (HTML5) Encoding Standard
Change by Felipe Rodrigues : -- keywords: +patch pull_requests: +9549 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue25416> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18624] Add alias for iso-8859-8-i which is the same as iso-8859-8
Change by Felipe Rodrigues : -- pull_requests: +9550 ___ Python tracker <https://bugs.python.org/issue18624> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19376] document that strptime() does not support the Feb 29 if the format does not contain the year
Felipe Rodrigues added the comment: What about adding some more information in the exception message in addition to the docs? I mean, if we're raising an issue because someone inserted Feb 29, we add a note about leap year in the exception message -- nosy: +fbidu ___ Python tracker <https://bugs.python.org/issue19376> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25416] Add encoding aliases from the (HTML5) Encoding Standard
Felipe Rodrigues added the comment: Ezio, I have issued a simple PR that adds just the two aliases cited in the issue's initial message. I would like to implement tests but as I wrote in the PR's message, I'm not really sure how to proceed with that. bpo-18624 is really related to this issue and in there is a reference to a test_codecs.py file that I did not find. If you could give me a few pointer on how to proceed, I'll be glad to improve my PR, add tests and even add all the other aliases that are missing. -- ___ Python tracker <https://bugs.python.org/issue25416> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
