
On 17/08/2020 3:08 pm, Henk-Jaap Wagenaar wrote:
Thanks for having a look! The example now looks like (looking at int case only, same applies to UID):
case int(): if value < 0: try: self._fp.write(struct.pack('>Bq', 0x13, value)) except struct.error: raise OverflowError(value) from None elif value < 1 << 8: self._fp.write(struct.pack('>BB', 0x10, value)) ... elif value < 1 << 64: self._fp.write(b'\x14' + value.to_bytes(16, 'big', signed=True)) else: raise OverflowError(value)
I was more thinking it would read/look something like:
case int() if value < 0: try: self._fp.write(struct.pack('>Bq', 0x13, value)) except struct.error: raise OverflowError(value) from None case int() if value < 1 << 8: self._fp.write(struct.pack('>BB', 0x10, value)) ... case int() if value < 1 << 64: self._fp.write(b'\x14' + value.to_bytes(16, 'big', signed=True)) case int(): raise OverflowError(value)
Which I think works as expected under the current PEP622?
That would work, but would be slower for the reference implementation due to the repeated `isinstance(value, int)` checks. I think the repeated `int()` cases do not help readability. Which form do you think is more readable?
On Mon, 17 Aug 2020 at 14:16, Mark Shannon <mark@hotpy.org <mailto:mark@hotpy.org>> wrote:
On 17/08/2020 1:13 pm, Henk-Jaap Wagenaar wrote: > On Mon, 17 Aug 2020 at 11:30, Mark Shannon <mark@hotpy.org <mailto:mark@hotpy.org> > <mailto:mark@hotpy.org <mailto:mark@hotpy.org>>> wrote: > > > I would also bring you attention to my rigorous analysis of the > possible > application to PEP 622 the entirety of CPython. > If I have made any mistakes there, I'd be happy to correct them. > > > You say "I've elided a lot of complex logic int cases, as it is not > relevant." in the plistlib._BinaryPlistWriter._write_object example, > this seems to be a prime example where guards could be used to > simplify/unnest the logic? Even if you disagree, I think it is highly > relevant and worth commenting on, one way or another!
Thanks for the feedback.
I've expanded the code in the `int` and `UID` cases, and made it clearer why the remaining code has been elided.
Cheers, Mark.