A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from http://mail.python.org/pipermail/python-dev/2015-February/138471.html below:

[Python-Dev] Request for Pronouncement: PEP 441

[Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application SupportPaul Moore p.f.moore at gmail.com
Mon Feb 23 22:38:25 CET 2015
On 23 February 2015 at 21:02, Brett Cannon <brett at python.org> wrote:
>> The real problem with overwriting is if there's a failure during the
>> overwrite you lose the original file. My original API had overwrite as
>> the default, but I think the risk makes that a bad idea.
>
>
> Couldn't you catch the exception, write the original file back out, and then
> re-raise the exception?

But you don't *have* the original file. You read the source archive
entry-by-entry, not all at once.

Apart from the implementation difficulty, this is getting too complex,
and I think it's better to just give the user the tools to add
whatever robustness or exception handling they want on top.

Paul
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4