Peter Otten wrote:
> Mattias Brändström wrote:
>
>> On Feb 15, 5:56 pm, Peter Otten <[EMAIL PROTECTED]> wrote:
>>> You can clear the cache with
>>>
>>> filecmp._cache = {}
>>>
>>> as a glance into the filecmp module would have shown.
>> You are right, a quick glance would have enlighten me. Next time I
>> will RTFS first. :-)
>>
>>> If you don't want to use the cache at all (untested):
>>>
>>> class NoCache:
>>> def __setitem__(self, key, value):
>>> pass
>>> def get(self, key):
>>> return None
>>> filecmp._cache = NoCache()
>>>
>> Just one small tought/question. How likely am I to run into trouble
>> because of this? I mean, by setting _cache to another value I'm
>> mucking about in filecmp's implementation details. Is this generally
>> considered OK when dealing with Python's standard library?
>
> I think it's a feature that Python lends itself to monkey-patching, but
> still there are a few things to consider:
>
> - Every hack increases the likelihood that your app will break in the next
> version of Python.
> - You take some responsibility for the "patched" code. It's no longer the
> tried and tested module as provided by the core developers.
> - The module may be used elsewhere in the standard library or third-party
> packages, and failures (or in the above example: performance degradation)
> may ensue.
>
> For a script and a relatively obscure module like 'filecmp' monkey-patching
> is probably OK, but for a larger app or a module like 'os' that is heavily
> used throughout the standard lib I would play it safe and reimplement.
>
It would probably be a good idea to add a clear_cache() function to the
module API for 2.6 to avoid such issues.
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
Blog of Note: http://holdenweb.blogspot.com
See you at PyCon? http://us.pycon.org/TX2007
--
http://mail.python.org/mailman/listinfo/python-list
