blhsing
blhsing
> > I'm not sure those qualify as "efficient". > > You're right. Definitely not space, maybe they're not too inefficient time wise? The proposed workaround requires *O(n)* complexity in...
> Change `LOAD_NAME` so it can deal with a mapping `globals()`. > * The performance will be impacted > * No backwards compatibility issue and we can remove the restriction...
> Basically, there's a giant hole here - it's about `LOAD_NAME`, `STORE_NAME` vs `LOAD_GLOBAL`, `STORE_GLOBAL`. They have different assumptions about the global dict. While I totally agree with you on...
> Allowing an arbitrary mapping for `PyDict_*` APIs is an even more backwards incompatible change. I don't believe that would be accepted. Also even for this specific scenario, this change...
> I thought you are changing `PyDict_*` APIs. It seems like you are changing the calls to those APIs, then that's a much smaller issue. Ah I see. Yeah my...
> I don't see a good reason why the globals must be a dictionary in some places, but not in others that appear very similar. > > If we are...
I've updated the PR to allow a mapping to be the `__dict__` attribute of any object. Can you help review the PR, @markshannon? Thanks!
> > 2024-09-08T16:49:27.5943515Z checking whether year with century should be normalized for strftime... **yes** > > 2024-09-08T16:49:27.6286869Z checking whether C99-specific strftime specifiers are supported... **yes** > > > 2024-09-08T16:51:33.7240722Z checking...
> > Ahh how could I have not noticed the second configure in the logs! > > Well, isn't it trivial to spot it among 11985 lines 😄? Actually, I...
FWIW in my answer to this StackOverflow question of [Is it possible to get the inferred type information using mypy programmatically?](https://stackoverflow.com/questions/54469653/is-it-possible-to-get-the-inferred-type-information-using-mypy-programmatically), I've worked around the issue of subclassing mypy classes...