[issue46628] Can't install YARL
Paul Koning added the comment: Thanks, I'll pass the word to the yarl and aiohttp team (both have this issue). -- ___ Python tracker <https://bugs.python.org/issue46628> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46628] Can't install YARL
Paul Koning added the comment: The only dependency mentioned by the yarl documentation is multidict and installing that makes no difference. I see I can tell yarl to build a pure-python version to avoid compiling stuff. If I do that it installs. But what I actually wanted to do is install aiohttp, and that step fails with the exact same error message. Given that it works in 3.10 but fails in 3.11a4, it does seem there is something about the new code that is involved here. -- ___ Python tracker <https://bugs.python.org/issue46628> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46628] Can't install YARL
New submission from Paul Koning : Trying to install "aiohttp" with pip I get a compile error installing "yarl". I get the same error when I install just that module. But it installs fine on 3.10. This is on an Apple M1 (ARM64) machine. -- components: macOS files: yarl.log messages: 412453 nosy: ned.deily, pkoning, ronaldoussoren priority: normal severity: normal status: open title: Can't install YARL type: compile error versions: Python 3.11 Added file: https://bugs.python.org/file50602/yarl.log ___ Python tracker <https://bugs.python.org/issue46628> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33470] Changes from GH-1638 (GH-3575, bpo-28411) are not documented in Porting to Python 3.7
Paul Koning added the comment: FYI, I'm the one who created this problem back in 2012. I just submitted a GDB patch for this, using PyImport_AppendInittab to define the built-in module at startup. I'm not sure how I missed this originally; perhaps the documentation was not as clear back then or maybe I just overlooked the information. The patch eliminates the call to _PyImport_FixBuiltins. -- nosy: +pkoning ___ Python tracker <https://bugs.python.org/issue33470> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21750] mock_open data is visible only once for the life of the class
Paul Koning added the comment: Section 26.7.7 of the library manual describes mock_open with the words: A helper function to create a mock to replace the use of open. It works for open called directly or used as a context manager. which implies that it works just like open. Given that it doesn't (not if you do two opens and use both streams concurrently) that difference should be called out as a difference, or limitation. -- ___ Python tracker <http://bugs.python.org/issue21750> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21750] mock_open data is visible only once for the life of the class
Paul Koning added the comment: I suppose. And it certainly is much better than the original behavior. But if this is the approach chosen, it should be clearly called out in the documentation, because the current wording suggests the 1.1.4 behavior, not the one you recommended. -- ___ Python tracker <http://bugs.python.org/issue21750> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21750] mock_open data is visible only once for the life of the class
Paul Koning added the comment: So if I understand right, it seems to me the 3.5/mock 1.1.4 behavior is correct. mock_open(read_data="f") acts like a file that contains f, and m() acts like an open() of that file. So if I call open once, I should read the f, then EOF. If I open twice, then each stream (x and y) is independent, and each sees f then EOF. -- ___ Python tracker <http://bugs.python.org/issue21750> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21750] mock_open data is visible only once for the life of the class
Paul Koning added the comment: Sure, you can use a vfs. That's true for a lot of mock functions; the benefit of mock, including mock_open, is that it provides an easier and better packaged way. The behavior expected is "be like a file". So in that last example, if you open it twice, you've got two views of the same "file" data, independent of each other, and reads of each file will see that data in full. A.read() has no effect on B.read(). I don't think I understand what the latest discussion/issue is all about. -- ___ Python tracker <http://bugs.python.org/issue21750> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21750] mock_open data is visible only once for the life of the class
New submission from Paul Koning: The read_data iterator that supplies bits of read data when asked from unittest.mock.mock_open is a class attribute. The result is that, if you instantiate the class multiple times, that iterator is shared. This isn't documented and it seems counterintuitive. The purpose of mock_open is to act like a file, and read_data is that file's data. A file contains the same data each time you read it. So it would seem better for the data iterator to be an instance attribute, initialized from the mock_open read_data value each time mock_open is called to create a new file instance. -- components: Library (Lib) messages: 220474 nosy: pkoning priority: normal severity: normal status: open title: mock_open data is visible only once for the life of the class type: behavior versions: Python 3.4 ___ Python tracker <http://bugs.python.org/issue21750> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21258] Add __iter__ support for mock_open
Paul Koning added the comment: This is the corresponding patch to the test suite. -- Added file: http://bugs.python.org/file35598/testwith.diff ___ Python tracker <http://bugs.python.org/issue21258> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21258] Add __iter__ support for mock_open
Paul Koning added the comment: I created a fix for this. This also fixes a second issue in mock_open, which is that readline() raises StopIteration at EOF rather than returning empty strings. See attached diff. (Is there a better procedure for submitting fixes?) -- nosy: +pkoning Added file: http://bugs.python.org/file35597/mock.diff ___ Python tracker <http://bugs.python.org/issue21258> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17309] __bytes__ doesn't work in subclass of int
New submission from Paul Koning: The __bytes__ special method has no effect in a subclass of "int" because the bytes() builtin checks for int or int subclass before it gets around to looking for that special method. The attached example shows it. -- components: Interpreter Core files: bytes.py messages: 183155 nosy: pkoning priority: normal severity: normal status: open title: __bytes__ doesn't work in subclass of int type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file29264/bytes.py ___ Python tracker <http://bugs.python.org/issue17309> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
