| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
| #ifdef Py_DEBUG | ||
| Py_UNREACHABLE(); |
There was a problem hiding this comment.
The #ifdef looks like a typo.
Sorry, something went wrong.
There was a problem hiding this comment.
It's there to make sure we abort on debug builds, but we have a fallback for non-debug builds.
Sorry, something went wrong.
There was a problem hiding this comment.
I'd prefer an explicit Py_FatalError() then. I think I can see this usage only in crossinterp.c (here, L1673, L1700).
Sorry, something went wrong.
There was a problem hiding this comment.
My intention is to not crash under normal usage, which is what Py_FatalError() would do.
Sorry, something went wrong.
There was a problem hiding this comment.
ah, Py_FatalError() instead of Py_UNREACHABLE()? I'm okay with that. It really should be unreachable through.
Sorry, something went wrong.
There was a problem hiding this comment.
That's fair. I'll switch it to explicitly Py_FatalError().
Sorry, something went wrong.
There was a problem hiding this comment.
done
Sorry, something went wrong.
There was a problem hiding this comment.
Thanks. This is off-topic, but would one of the coming PRs address #133107 (comment)?
Sorry, something went wrong.
There was a problem hiding this comment.
Yeah, I'll be addressing that.
Sorry, something went wrong.
There was a problem hiding this comment.
fixed
Sorry, something went wrong.
| EXCEPTION, | ||
| OBJECT, |
There was a problem hiding this comment.
nit: indent. Also, cls is undefined at L726, 732:
assert not hasattr(mod, func.__name__), (cls, getattr(mod, func.__name__))
Sorry, something went wrong.
There was a problem hiding this comment.
fixed
Sorry, something went wrong.
| # Currently the "extra" attrs are not preserved | ||
| # (via __reduce__). | ||
| self.assertIs(type(exc1), type(exc2)) | ||
| #self.assert_exc_equal(grouped1, grouped2) |
There was a problem hiding this comment.
Is this still intentionally commented out? The assertion passed for me.
Sorry, something went wrong.
There was a problem hiding this comment.
fixed
Sorry, something went wrong.
| def assert_equal_or_equalish(self, obj, expected): | ||
| cls = type(expected) | ||
| if cls.__eq__ is not object.__eq__: | ||
| # assert cls not in (types.MethodType, types.BuiltinMethodType, types.MethodWrapperType), cls |
There was a problem hiding this comment.
Ditto. See also:
L757:
# self.assert_roundtrip_equal(defs.TOP_FUNCTIONS)
L844, 997, 1463:
# UnicodeError: (None, msg, None, None, None),
Sorry, something went wrong.
There was a problem hiding this comment.
fixed
Sorry, something went wrong.
| Py_FatalError("unsupported xidata fallback option"); | ||
| #endif | ||
| _PyErr_SetString(tstate, PyExc_SystemError, | ||
| "unsuppocted xidata fallback option"); |
There was a problem hiding this comment.
nit: unsuppo"c"ted
Sorry, something went wrong.
There was a problem hiding this comment.
fixed
Sorry, something went wrong.
| } | ||
|
|
||
| int | ||
| _PyObject_GetXIDataWithFallback(PyThreadState *tstate, |
There was a problem hiding this comment.
Could we replace the long name with _PyObject_GetXIData? I feel the existing _PyObject_GetXIData could be longer (e.g. _PyObject_GetXIDataNoFallback), as it is unpopular at all in newer PRs.
UPDATE: No, _PyObject_GetXIData should remain as-is.
Sorry, something went wrong.
There was a problem hiding this comment.
I'm not sure whether the fallback parameter is needed. Does this function support the following?
UPDATE: Yes, they are necessary.
Sorry, something went wrong.
There was a problem hiding this comment.
I take back the questions in this topic. Sorry for the noise.
(I currently interpret getdata.fallback as getdata.(with)fallback that can pass an option to tuple's items, and WithFallback as _PyFunction_GetXIData and _PyPickle_GetXIData.)
Sorry, something went wrong.
There was a problem hiding this comment.
Good point about the function name. I'll take a look.
As to the fallback parameter, it does not determine which function is called. The _PyXIData_getdata_t functions will be called for any of the fallback values. It's just a matter of if the fallback parameter is propagated to the getdata func.
Sorry, something went wrong.
There was a problem hiding this comment.
I've changed the name as suggested. Thanks for that!
Sorry, something went wrong.
| typedef struct { | ||
| xidatafunc basic; | ||
| xidatafbfunc fallback; | ||
| } _PyXIData_getdata_t; |
There was a problem hiding this comment.
Does the layout imply that it would accept two functions in the future? If exclusive, is there any reason why it cannot be a void pointer (or xidatafunc) with a flag? (The C compilers could verify xidatafbfunc at REGISTER_FALLBACK().)
E: No change request from me as long as there are only two options.
Sorry, something went wrong.
There was a problem hiding this comment.
Yeah, I tried both and went with this because I don't expect other options. This is internal API so I wasn't going to worry about it too much for now. That said, maybe it would be better to take the void * approach now. I'll think about it.
Sorry, something went wrong.
There was a problem hiding this comment.
I'm inclined to leave it the way it is, since I anticipate only those two options will be needed and it's nice to keep the signature explicit (instead of void *).
Sorry, something went wrong.
| typedef int (*xidatafunc)(PyThreadState *tstate, PyObject *, _PyXIData_t *); | ||
| typedef int xidata_fallback_t; | ||
| #define _PyXIDATA_XIDATA_ONLY (0) | ||
| #define _PyXIDATA_FULL_FALLBACK (1) |
There was a problem hiding this comment.
Maybe flags like 0b111?
Sorry, something went wrong.
There was a problem hiding this comment.
I added these with the idea that there is conceptual room for other options and the actual values aren't so important. However, they don't need to be unioned, so I'm not sure there's much value in using another literal form.
Sorry, something went wrong.
|
Thanks @ericsnowcurrently for the PR 🌮🎉.. I'm working now to backport this PR to: 3.14. |
Sorry, something went wrong.
|
GH-134418 is a backport of this pull request to the 3.14 branch. |
Sorry, something went wrong.
…-133482) It now supports a "full" fallback to _PyFunction_GetXIData() and then `_PyPickle_GetXIData()`. There's also room for other fallback modes if that later makes sense.
…-133482) It now supports a "full" fallback to _PyFunction_GetXIData() and then `_PyPickle_GetXIData()`. There's also room for other fallback modes if that later makes sense.
…-133482) It now supports a "full" fallback to _PyFunction_GetXIData() and then `_PyPickle_GetXIData()`. There's also room for other fallback modes if that later makes sense.
…-133482) It now supports a "full" fallback to _PyFunction_GetXIData() and then `_PyPickle_GetXIData()`. There's also room for other fallback modes if that later makes sense.
| Back | FazBrowse Home | New Git URL |
Uh oh!
There was an error while loading. Please reload this page.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.