-
-
Notifications
You must be signed in to change notification settings - Fork 32.2k
bpo-35950: Raise OSError in io.BufferedReader.truncate() #13689
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
bpo-35950: Raise OSError in io.BufferedReader.truncate() #13689
Conversation
Please try to read source code more widely, and make new code consistent with existing code. For example: Lines 1619 to 1621 in 4e22157
Same error type and error message is preferred. |
Have you read the issue and documentation?
https://docs.python.org/3/library/io.html#io.IOBase.writable If I understand it correctly, It seems to me that the implementation is in sync with the documentation here. Could you clarify your comment a bit? |
I read, of course. "raise OSError" means "raise an instance of OSError or it's subclass." UnsupportedOperation is subclass of OSError. It is used in similar cases, like write() is called for non writable file. |
Ah, now I understand what you mean. Yes, I'll update the PR. |
Could you please update the PR, @berkerpeksag? |
I'm going to update it this weekend. |
Plistlib currently throws an exception when asked to decode a valid .plist file that was generated by Apple's NSKeyedArchiver. Specifically, this is caused by a byte 0x80 (signifying a UID) not being understood. This fixes the problem by enabling the binary plist reader and writer to read and write plistlib.UID objects.
…-6191) Similarly to how several pathlib file creation functions have an "exists_ok" parameter, we should introduce "missing_ok" that makes removal functions not raise an exception when a file or directory is already absent. IMHO, this should cover Path.unlink and Path.rmdir. Note, Path.resolve() has a "strict" parameter since 3.6 that does the same thing. Naming this of this new parameter tries to be consistent with the "exists_ok" parameter as that is more explicit about what it does (as opposed to "strict"). https://bugs.python.org/issue33123
…nGH-13351) @zooba I just realized that this whitespace fix didn't get pushed. https://bugs.python.org/issue36511
No NEWs is needed since the problem was introduced on master only and never released. https://bugs.python.org/issue35589
We cannot use "unsigned int" for exitcode on Windows, since Py_Main() and _Py_RunMain() always return an "int". Changes: * _PyPathConfig_ComputeSysPath0() now returns -1 if an exception is raised. * pymain_run_python() no longer uses _PyInitError but display the exception and set exitcode to 1 in case of error. * Fix _Py_RunMain(): return an exitcode rather than calling exit() on pymain_run_python() failure. * _Py_ExitInitError() no longer uses ExitProcess() on Windows, use exit() on all platforms. * _Py_ExitInitError() now fails with a fatal error if 'err' is not an error not an exit.
The second attempt. Now deprecate `@coroutine` only, keep `yield from fut` as is. https://bugs.python.org/issue36921
* _PyCoreConfig_Read() doesn't parse nor update argv if parse_argv is 0. * Move path configuration fields in _PyCoreConfig. * Add an unit test for parse_argv=0. * Remove unused "done": label in _Py_RunMain().
* Add a private _Py_InitializeMain() function. * Add again _PyCoreConfig._init_main. * _Py_InitializeFromConfig() now uses _init_main to decide if _Py_InitializeMainInterpreter() should be called. * _PyCoreConfig: rename _frozen to pathconfig_warnings, its value is now the opposite of Py_FrozenFlag. * Add an unit test for _init_main=0 and _Py_InitializeMain().
Add tests for configure_c_stdio and pathconfig_warnings parameters.
precmdline is only needed in _PyCoreConfig_Read(), not in config_read_cmdline(). Reorganize _PyCoreConfig_Read().
Superseded by #18586. |
The truncate() method of io.BufferedReader() should raise OSError
when it is called on a read-only io.BufferedReader() instance.
https://bugs.python.org/issue35950