[Python-ideas] Re: else without except
2023-08-01 21:46 UTC+02:00, Ronald Oussoren via Python-ideas : > > >> On 1 Aug 2023, at 19:59, Mitch wrote: >> >> Is this a relevant argument (either way) here? > > Adding features to the language always has a cost in that it slightly > complicates the language and makes it harder to teach. Because of that the > bar for adding features is high. > > Showing how a new feature would improve realistic code patterns helps to > defend to proposal. > > Ronald To me it's a simplification of the language and its teaching because it removes an exception (pun not intended). A 'try' might be followed by some blocks: - except with an exception - bare except - else - finally They are all optional. And if present, they must appear in that order. They are optional, except for the 'else', which must follow either an 'except' with an exception, or a bare 'except'. I think this could be made simpler by allowing 'else' without any 'except'. Celelibi ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/ZNZN6ZVGOH3DVW2M7IJC3P7XEPZFK76Z/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: else without except
On Tue, 8 Aug 2023 at 00:09, Celelibi wrote:
> Actually, now that I think about it, I guess a 'try' block without an
> 'except' and just a 'finally' would probably be a good candidate for a
> context manager. (Which I'm a big fan of. ^^)
Yeah, context managers are often a good way of writing a try/finally.
Certainly not *always*, but they can be very elegant.
> Here's what I think could be a not so far fetched example: writing a
> structured file through a serializing class. Conceptually the code
> could look like this:
>
> myfile = MySerializer("foo.bin")
> try:
> # Write data with myfile.write()
> else:
> # Write footer with myfile.write()
> finally:
> myfile.close()
>
> You might want to keep it as a 'try' statement instead of a 'with'
> because in the future you might want to handle some the exceptions
> generated by MySerializer but not those generated by the OS. (Although
> I agree, you can have a 'try' in a 'with'.)
Not sure how the generalization would go here, but in order to make
"try-else" useful, it has to be highly likely that the "else" block be
capable of raising the same exception that would be caught in the
hypothetical "except" (and, importantly, that you not want this). I'm
having trouble imagining what sort of exception would be like this,
since a partly-written file is almost certainly not going to parse a
useful footer.
Maybe it's like a PKZIP file where the footer is actually measured
from the end of the file?? Not a common technique by any means,
although given Zip's ubiquity, maybe it deserves more consideration.
Still, that would probably want to be coded as two entirely separate
blocks, since - as per your comment - the "write out the central
directory" part would have to happen when there's a serialization (or
in this case, perhaps compression) problem, but NOT when there's other
types of problem, or Ctrl-C, or anything like that.
> And in the real world, that code might look something like this.
> It write two blocks of data, each preceeded by the data length and
> followed by a checksum. And the footer is the checksum of the whole
> data.
>
> assert len(data) <= 256
> myfile = MySerializer("foo.bin")
> try:
> myfile.write(128)
> myfile.write(data[:128])
> myfile.write(crc32(data[:128]))
> myfile.write(len(data) - 128)
> myfile.write(data[128:])
> myfile.write(crc32(data[128:]))
> myfile.write(crc32(data))
> finally:
> myfile.close()
>
> I don't know about you, but I don't think it's obvious which 'write'
> should be put in an 'else' block when an 'except' gets added. Even if
> we added comments to identify the data blocks and footers, it's not
> obvious that the exceptions that could be raised by writing the footer
> shouldn't be captured by the future 'except'.
Yeah, if there's a problem in any of these blocks, I have no idea what
should get written. If the line "myfile.write(data[128:])", fails...
do you write out its CRC? Do you write out the global CRC? You've
already successfully written the length here, so I'd say the file is
irreparably broken at that point, and all you can do is report that
serialization failed.
This is why real-world examples are so important. Inventing examples
invariably leads to this sort of thing. You've had a marvellous
attempt at it, and...
> This example is not perfect, but here it is.
... exactly.
ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/OVVK6I6A7JAOOOSWYAPL5HZFMGRNYJOK/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: else without except
2023-08-01 18:14 UTC+02:00, Chris Angelico :
> On Wed, 2 Aug 2023 at 02:02, Celelibi wrote:
>> If later on an "except" is added, the developper doing the
>> modification should be reminded to move the call to
>> no_error_occurred() into an "else". With real-world non-trivial code,
>> it might not be so simple to see.
>>
>
> Can you give us an example of real-world non-trivial code that would
> benefit from this?
I guess Daniel Walker (OP) would be the best to answer that since he's
the one who came up with this need. I've rarely used 'else' with a
'try'.
Actually, now that I think about it, I guess a 'try' block without an
'except' and just a 'finally' would probably be a good candidate for a
context manager. (Which I'm a big fan of. ^^)
Here's what I think could be a not so far fetched example: writing a
structured file through a serializing class. Conceptually the code
could look like this:
myfile = MySerializer("foo.bin")
try:
# Write data with myfile.write()
else:
# Write footer with myfile.write()
finally:
myfile.close()
You might want to keep it as a 'try' statement instead of a 'with'
because in the future you might want to handle some the exceptions
generated by MySerializer but not those generated by the OS. (Although
I agree, you can have a 'try' in a 'with'.)
And in the real world, that code might look something like this.
It write two blocks of data, each preceeded by the data length and
followed by a checksum. And the footer is the checksum of the whole
data.
assert len(data) <= 256
myfile = MySerializer("foo.bin")
try:
myfile.write(128)
myfile.write(data[:128])
myfile.write(crc32(data[:128]))
myfile.write(len(data) - 128)
myfile.write(data[128:])
myfile.write(crc32(data[128:]))
myfile.write(crc32(data))
finally:
myfile.close()
I don't know about you, but I don't think it's obvious which 'write'
should be put in an 'else' block when an 'except' gets added. Even if
we added comments to identify the data blocks and footers, it's not
obvious that the exceptions that could be raised by writing the footer
shouldn't be captured by the future 'except'.
This example is not perfect, but here it is.
Celelibi
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/JQLJ4W3WPRJ7B6SV4ZRX64XVWNKTMP6G/
Code of Conduct: http://python.org/psf/codeofconduct/
