New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Python and C implementations of io are out of sync #54067
Comments
RawIOBase is defined as having the readinto() method but it doesn't. It should at least have a failing one (raising io.UnsupportedOperation like the BufferedIOBase.{read,readinto} methods do). This is, of course, mainly for auto-documenting purposes (with help() and friends). |
+1 for a failing one. (Does the base implementation not raise?) Is it even possible to implement a real one without buffering? |
The base implementation doesn't exist :)
FileIO does. It's the same as read(), except that you read into an existing buffer rather than allocating a new bytes object. |
Attached is a script to find all of the mismatches between the C and Python implementations. There are several. Below is the output: RawIOBase C is missing: ['readinto', 'write'] Since the Python version was the original reference implementation, adding the attributes missing from the C side seems to be a straightforward decision (and it should simply match whatever the Python version does). It looks like a number of new attributes have creeped into the C side, which will require more thoughtful decision making. We should probably double-check that each of these is documented, while we're at it. |
FWIW, I just opened bpo-9859: Add tests to verify API match of modules with 2 implementations. |
2010/9/15 Daniel Stutzbach <report@bugs.python.org>:
These attributes exist; they're just not properties. |
Yes, I see. They're added to the instance in the constructor, so they don't exist as attributes of the class. Also in that category: BlockingIOError python is missing: ['characters_written'] That leaves: RawIOBase C is missing: ['readinto', 'write'] The Python version of StringIO throws an AttributeException on the .name attribute. It's a property inherited from the TextIOWrapper. Effectively, TextIOWrapper provides the .name attribute if the object that it's wrapping provides the .name attribute. This behavior is undocumented. Is that reasonable behavior? Or should TextIOWrapper define .name always and return some suitable value if the wrapped object doesn't define .name? (e.g., None) In any case, it needs documentation. |
2010/9/15 Daniel Stutzbach <report@bugs.python.org>:
I'm not sure if this pickling stuff matters as long as they both pickle.
Yes, all the code expects an AttributeError on name is it's not |
On Wed, Sep 15, 2010 at 10:51 AM, Benjamin Peterson
I'm not sure either. Do other Python implementations try to maintain a
Actually, FileIO sets the name attribute to the file descriptor if it isn't 1 |
Roundup does not play well with Gmail when Gmail is in Rich Format mode ;-) That example should have read: >>> f = io.FileIO(1)
>>> f.name
1 |
2010/9/15 Daniel Stutzbach <report@bugs.python.org>:
>
> Daniel Stutzbach <daniel@stutzbachenterprises.com> added the comment:
>
> Roundup does not play well with Gmail when Gmail is in Rich Format mode ;-)
>
> That example should have read:
>
>>>> f = io.FileIO(1)
>>>> f.name
> 1 Hmm, none the less other code expects it. |
Does that imply that there's some code that will break on FileIO objects that are created using a file descriptor instead of a filename? If so, where? |
2010/9/15 Daniel Stutzbach <report@bugs.python.org>:
No, just that all code that access name expects an AttributeError, |
Is there anything left to do on this or can it be closed as fixed? |
A test has been added as part of bpo-9859, it is marked with @unittest.skip as the API surface does not yet match. |
There were originally three methods present in RawIOBase that were not present in PyRawIOBase_Type:
I've created a patch that adds the first two to PyRawIOBase_Type. The python class readinto and write methods raise UnsupportedOperation, so the c methods return a PyExc_NotImplementedError. The next major question I have is whether we need to implement a __weakref__ method or this should be ignored in the test. |
Can anyone provide feedback on this patch? |
I think ignoring weakref is wrong: it means the two implementations are different. |
__weakref__ is just an implementation detail of how heap types expose weak references (actually, I'm not sure why it's exposed at all). Laura, thank you for contributing. Your patch looks good to me. |
New changeset 962b42d67b9e by Antoine Pitrou in branch 'default': |
I've pushed this to the default branch. Thanks! |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: