A RetroSearch Logo

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

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2000-January/001853.html below:

[Python-Dev] Changing existing class instances

[Python-Dev] Changing existing class instancesBarry A. Warsaw bwarsaw@cnri.reston.va.us (Barry A. Warsaw)
Fri, 21 Jan 2000 09:38:52 -0500 (EST)
>>>>> "TP" == Tim Peters <tim_one@email.msn.com> writes:

    TP> Under the explicit new.update scheme, such a service needn't
    TP> bother clients with communicating the full name of the
    TP> original module; heck, in a *truly* long-running app, over
    TP> time the source tree will change, and classes and functions
    TP> will migrate across modules.  That will be a problem for the
    TP> explicit scheme too (how does it know *which* "class Misc" to
    TP> update) -- but at least it's an explicit problem then, and not
    TP> a "mysterous failure" of hidden magic.

I completely agree.  I think in general, such long running apps are
rare, and in those cases you probably want to be explicit about when
and how the updates occur anyway.  The one place where automatic
updates would be convenient would be at the interactive prompt, so it
might be nice to add a module that could be imported by PYTHONSTARTUP,
and play hook games to enable automatic updates.

-Barry




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