Message361031
| Author |
serhiy.storchaka |
| Recipients |
ezio.melotti, serhiy.storchaka, vstinner |
| Date |
2020-01-30.10:13:54 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1580379235.33.0.906343370847.issue39500@roundup.psfhosted.org> |
| In-reply-to |
|
| Content |
Since the behavior was changed, I think we need a versionchanged directive.
This function was added in 3.0. Prior to 3.3 it was always successful (if you pass an unicode object, that is required for most of PyUnicode API). Py_FatalError was added in 3.3, because not all unicode object are now valid. But I am not sure that it could be triggered in real code without using some broken extensions.
It may be safer to return 0 instead of returning -1 or crashing if PyUnicode_READY() fails. If return -1 and set an exception, it can lead to an unexpected behavior if the calling code expects only 0/1, and maybe even to crash in debug build due to set an exception and returning value. |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2020-01-30 10:13:55 | serhiy.storchaka | set | recipients:
+ serhiy.storchaka, vstinner, ezio.melotti |
| 2020-01-30 10:13:55 | serhiy.storchaka | set | messageid: <1580379235.33.0.906343370847.issue39500@roundup.psfhosted.org> |
| 2020-01-30 10:13:55 | serhiy.storchaka | link | issue39500 messages |
| 2020-01-30 10:13:54 | serhiy.storchaka | create | |
|