Mimic BigInteger members on Int32 #1399
Conversation
BCSharp
force-pushed
the
int32_bigintapi
branch
from
faedd2e to
d4a9009
Compare
Tests/test_int.py
Outdated
| self.assertSetEqual(set(dir(int)) - set(dir(Int32)), {'GetByteCount', 'TryWriteBytes'}) | ||
|
|
||
| # these two assertions fail on IronPython compiled for .NET Standard | ||
| # if not iptest.is_netstandard: # no such check possible |
There was a problem hiding this comment.
We could add an is_netstandard = clr.TargetFramework.startswith(".NETStandard")
| public static bool TryWriteBytes(int self, Span<byte> destination, out int bytesWritten, bool isUnsigned = false, bool isBigEndian = false) | ||
| => new BigInteger(self).TryWriteBytes(destination, out bytesWritten, isUnsigned, isBigEndian); | ||
|
|
||
| #elif NETSTANDARD |
There was a problem hiding this comment.
These feel a bit icky since depending on what runtime is using the .NET Standard assemblies you will get different methods. For example, if the .NET Standard assemblies are used with .NET Framework you'll might get extra methods on Int32 based int which won't appear when backed by BigInteger.
Anyway, I don't have a good solution to propose right now so this is probably fine.
There was a problem hiding this comment.
Indeed, but I too have no better ideas. However I am not too concerned about this case: from the perspective of the Python type system consistency it is totally acceptable for some instances to have some additional attributes that other instances or their type don't have.
On the other hand, it is not OK if a type has attributes which are missing on (some) instances (without any explicit deletion, that is). Unfortunately, this is now the case on Mono. After spending an hour or so trying to fix it, I decided to simply fix the tests on Mono and will submit an issue report once this PR is merged. Maybe it will be picked up at some point in the future (or Mono becomes obsolete by .NET vNext). My enthusiasm to work around Mono quirks is quite limited, and in any case, this particular issue is not on the top of the list.
There was a problem hiding this comment.
I decided to simply fix the tests on Mono and will submit an issue report once this PR is merged.
Fine by me. Mono is less relevant these days with .NET having good cross-platform support.
| public static bool TryWriteBytes(int self, Span<byte> destination, out int bytesWritten, bool isUnsigned = false, bool isBigEndian = false) | ||
| => new BigInteger(self).TryWriteBytes(destination, out bytesWritten, isUnsigned, isBigEndian); | ||
|
|
||
| #elif NETSTANDARD |
There was a problem hiding this comment.
I decided to simply fix the tests on Mono and will submit an issue report once this PR is merged.
Fine by me. Mono is less relevant these days with .NET having good cross-platform support.
Follow-up on #1329 (issue #52).
Instances of
Int32behave as if being instances of an anonymous subtype ofint. Therefore, for the sake of type system consistency, any attributes ofintshould be also present on instances of bothintandInt32. This was already the case for regular Python attributes, but not for Python-hidden attributes. This PR sets it straight. Arguably, there is little chance that the static attributes are going to be accessed through an instance rather than the type, but here they are to avoid surprises. Who knows, maybe some code-generating use case assumes that it is possible, as it should be.Ideally I would like to see those Python-hidden properties and method only on
Int32instances and not pollute the namespace of theInt32type. However, the existing resolver mechanism does not support such distinction and I am not convinced it is worth extra complexity implementing an additional mechanism just for that.