Re: [Python-Dev] [Python-checkins] r88867 - in tracker/instances/python-dev: extensions/pydevutils.py html/file.item.html html/issue.item.html html/msg.item.html
On Sat, Jul 23, 2011 at 8:34 AM, ezio.melotti wrote: > Author: ezio.melotti > Date: Sat Jul 23 00:34:53 2011 > New Revision: 88867 > > Log: > #267: remove the remove button from the issue page, move it to the msg/file > page, and add a button to add back removed messages/files. Thank you! (I accidentally deleted one of RDM's comments just the other day) Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Merge - Issue #12592: Make Python build on OpenBSD 5 (and future major
Am 22.07.2011 23:51, schrieb charles-francois.natali: > http://hg.python.org/cpython/rev/63de97ae832e > changeset: 71462:63de97ae832e > parent: 71459:d3f0f72c31f8 > user:Charles-François Natali > date:Fri Jul 22 23:52:02 2011 +0200 > summary: > Merge - Issue #12592: Make Python build on OpenBSD 5 (and future major > releases). > > files: > Misc/NEWS|2 + > configure| 597 ++ > configure.in |4 +- > 3 files changed, 291 insertions(+), 312 deletions(-) Note that this commit wasn't actually a merge -- you'll have to use the "hg merge" command for that. Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r88867 - in tracker/instances/python-dev: extensions/pydevutils.py html/file.item.html html/issue.item.html html/msg.item.html
On 23/07/2011 9.55, Nick Coghlan wrote: On Sat, Jul 23, 2011 at 8:34 AM, ezio.melotti wrote: Author: ezio.melotti Date: Sat Jul 23 00:34:53 2011 New Revision: 88867 Log: #267: remove the remove button from the issue page, move it to the msg/file page, and add a button to add back removed messages/files. Thank you! (I accidentally deleted one of RDM's comments just the other day) You are welcome! (That was actually one of the reasons that made me look at that issue again) Now restoring messages and files that got deleted should be trivial, and deleting them accidentally (almost) impossible. Messages and files can be deleted/restored from their pages. Links to these pages can be found in the history of the issue. For messages and files that are still linked to the issue, the "(view)" and "edit" links can also be used. Best Regards, Ezio Melotti Cheers, Nick. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Merge - Issue #12592: Make Python build on OpenBSD 5 (and future major
> Note that this commit wasn't actually a merge -- you'll have to use the > "hg merge" command for that. You're right. I guess that's what happens when I try to work past my usual bedtime ;-) By the way, I'm still getting errors upon push, and it looks like when I push a patch, this doesn't trigger any build on the buildbots. It used to work, any idea what's going on? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3.2.1 encoding surprise
Glenn Linderman g.nevcal.com> writes: I aim to update the launcher downloads Real Soon Now. > What (free?) toolset is needed for building the launcher? I don't > even have a C compiler installed on this computer yet. > The tools I use for building the launcher are: Windows SDK (for the 64-bit compilers), Visual Studio Express C++ (2008 Edition), WiX for the installers, and Python. All are free as in beer, and some are also free as in speech. Regards, Vinay Sajip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Merge - Issue #12592: Make Python build on OpenBSD 5 (and future major
On Sat, 23 Jul 2011 11:46:05 +0200 Charles-François Natali wrote: > > Note that this commit wasn't actually a merge -- you'll have to use the > > "hg merge" command for that. > > You're right. > I guess that's what happens when I try to work past my usual bedtime ;-) > > By the way, I'm still getting errors upon push, and it looks like when > I push a patch, this doesn't trigger any build on the buildbots. It > used to work, any idea what's going on? What is the error? Is a traceback printed? Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Merge - Issue #12592: Make Python build on OpenBSD 5 (and future major
(See http://mail.python.org/pipermail/python-dev/2011-July/112309.html for the original mail): """ $ hg push pushing to ssh://[email protected]/cpython searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 1 changesets with 2 changes to 2 files remote: change(s) NOT sent, something went wrong: remote: [Failure instance: Traceback from remote host -- Traceback unavailable remote: ] remote: sent email to roundup at report at bugs.python.org remote: notified python-checkins at python.org of incoming changeset ca077f2672e3 """ No traceback. Last time I did a push (yesterday), there was a slight difference, the lines reporting the failure were prefixed by "buildbot:" (IIRC). And indeed, none of my pushes triggers a build on the buildbots (and I'm sure it worked a couple weeks ago). Thanks, cf ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Merge - Issue #12592: Make Python build on OpenBSD 5 (and future major
On Sat, 23 Jul 2011 16:10:38 +0200 Charles-François Natali wrote: > > No traceback. > Last time I did a push (yesterday), there was a slight difference, the > lines reporting the failure were prefixed by "buildbot:" (IIRC). And > indeed, none of my pushes triggers a build on the buildbots (and I'm > sure it worked a couple weeks ago). Ok, it should be fixed now. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Merge - Issue #12592: Make Python build on OpenBSD 5 (and future major
> Ok, it should be fixed now. > Indeed. Thanks! cf ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] tuple[int] optimization
tuple[int] is 30% slower than list[int].
Please let me explain the problem.
(1, 2, 3)[1] has compiled as BINARY_SUBSCR operation.
ceval.c has optimization for list:
case BINARY_SUBSCR:
w = POP();
v = TOP();
if (PyList_CheckExact(v) && PyInt_CheckExact(w)) {
/* INLINE: list[int] */
Py_ssize_t i = PyInt_AsSsize_t(w);
if (i < 0)
i += PyList_GET_SIZE(v);
if (i >= 0 && i < PyList_GET_SIZE(v)) {
x = PyList_GET_ITEM(v, i);
Py_INCREF(x);
}
else
goto slow_get;
}
else
slow_get:
x = PyObject_GetItem(v, w);
Py_DECREF(v);
Py_DECREF(w);
SET_TOP(x);
if (x != NULL) continue;
break;
For tuple code follows slow way via tp_as_mapping slot and calls
tuplesubscript from Objects/tupleobject.c
Looks like tuple is goot applicant to be optimized as list does.
tuples is used in python programs very often and getting element from
tuple by index as common operation as list[int].
Is there reasons to prevent special case for tuples in BINARY_SUBSCR?
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] tuple[int] optimization
On Sun, 2011-07-24 at 01:20 +0300, Andrew Svetlov wrote:
> tuple[int] is 30% slower than list[int].
> Please let me explain the problem.
>
> (1, 2, 3)[1] has compiled as BINARY_SUBSCR operation.
> ceval.c has optimization for list:
>
> case BINARY_SUBSCR:
> w = POP();
> v = TOP();
> if (PyList_CheckExact(v) && PyInt_CheckExact(w)) {
> /* INLINE: list[int] */
> Py_ssize_t i = PyInt_AsSsize_t(w);
> if (i < 0)
> i += PyList_GET_SIZE(v);
> if (i >= 0 && i < PyList_GET_SIZE(v)) {
> x = PyList_GET_ITEM(v, i);
> Py_INCREF(x);
> }
> else
> goto slow_get;
> }
> else
> slow_get:
> x = PyObject_GetItem(v, w);
> Py_DECREF(v);
> Py_DECREF(w);
> SET_TOP(x);
> if (x != NULL) continue;
> break;
>
> For tuple code follows slow way via tp_as_mapping slot and calls
> tuplesubscript from Objects/tupleobject.c
>
> Looks like tuple is goot applicant to be optimized as list does.
> tuples is used in python programs very often and getting element from
> tuple by index as common operation as list[int].
>
> Is there reasons to prevent special case for tuples in BINARY_SUBSCR?
In latest trunk this optimisation seems to have gone away, the code is
now:
TARGET(BINARY_SUBSCR)
w = POP();
v = TOP();
x = PyObject_GetItem(v, w);
Py_DECREF(v);
Py_DECREF(w);
SET_TOP(x);
if (x != NULL) DISPATCH();
break;
The implementation of PyObject_GetItem doesn't appear to have changed
though. Maybe this optimisation was no longer worth it in practice?
Ryan
--
Ryan Kelly
http://www.rfk.id.au | This message is digitally signed. Please visit
[email protected]| http://www.rfk.id.au/ramblings/gpg/ for details
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] tuple[int] optimization
On Sun, 24 Jul 2011 09:13:07 +1000 Ryan Kelly wrote: > > In latest trunk this optimisation seems to have gone away, the code is > now: > > TARGET(BINARY_SUBSCR) > w = POP(); > v = TOP(); > x = PyObject_GetItem(v, w); > Py_DECREF(v); > Py_DECREF(w); > SET_TOP(x); > if (x != NULL) DISPATCH(); > break; > > The implementation of PyObject_GetItem doesn't appear to have changed > though. Maybe this optimisation was no longer worth it in practice? The optimization was probably removed because PyInt objects don't exist anymore. There's a related but more ambitious patch at http://bugs.python.org/issue10044. In practice however, such micro-optimizations usually have little or no effect. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] tuple[int] optimization
You right. Sorry, I missed changes in ceval.c for py3k.
Please note, simple test like:
from timeit import timeit
print('list', timeit("l[0]", "l = [1]"))
print('tuple', timeit("l[0]", "l = (1,)"))
Has results:
andrew@ocean ~/p/cpython> python2.7 z.py
('list', 0.03479599952697754)
('tuple', 0.046610116958618164)
andrew@ocean ~/p/cpython> python3.2 z.py
list 0.04870104789733887
tuple 0.04825997352600098
For python2.7 list[int] microoptimization saves 25-30%, while 3.2 (and
trunk) very close to "unoptimized" 2.7 version.
On Sun, Jul 24, 2011 at 2:27 AM, Antoine Pitrou wrote:
> On Sun, 24 Jul 2011 09:13:07 +1000
> Ryan Kelly wrote:
>>
>> In latest trunk this optimisation seems to have gone away, the code is
>> now:
>>
>> TARGET(BINARY_SUBSCR)
>> w = POP();
>> v = TOP();
>> x = PyObject_GetItem(v, w);
>> Py_DECREF(v);
>> Py_DECREF(w);
>> SET_TOP(x);
>> if (x != NULL) DISPATCH();
>> break;
>>
>> The implementation of PyObject_GetItem doesn't appear to have changed
>> though. Maybe this optimisation was no longer worth it in practice?
>
> The optimization was probably removed because PyInt objects don't exist
> anymore. There's a related but more ambitious patch at
> http://bugs.python.org/issue10044.
>
> In practice however, such micro-optimizations usually have little or no
> effect.
>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/andrew.svetlov%40gmail.com
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] tuple[int] optimization
Le dimanche 24 juillet 2011 à 03:15 +0300, Andrew Svetlov a écrit :
> You right. Sorry, I missed changes in ceval.c for py3k.
> Please note, simple test like:
>
> from timeit import timeit
>
> print('list', timeit("l[0]", "l = [1]"))
> print('tuple', timeit("l[0]", "l = (1,)"))
>
> Has results:
>
> andrew@ocean ~/p/cpython> python2.7 z.py
> ('list', 0.03479599952697754)
> ('tuple', 0.046610116958618164)
>
> andrew@ocean ~/p/cpython> python3.2 z.py
> list 0.04870104789733887
> tuple 0.04825997352600098
>
> For python2.7 list[int] microoptimization saves 25-30%, while 3.2 (and
> trunk) very close to "unoptimized" 2.7 version.
My point is that on non-trivial benchmarks, the savings are almost zero.
If you look at the (much more complex) patch I linked to, the savings
are at most 10% on a couple of select benchmarks, other benchmarks
showing almost no difference.
Regards
Antoine.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] tuple[int] optimization
I undrestand your point. Thank you for explanation.
On Sun, Jul 24, 2011 at 3:18 AM, Antoine Pitrou wrote:
> Le dimanche 24 juillet 2011 à 03:15 +0300, Andrew Svetlov a écrit :
>> You right. Sorry, I missed changes in ceval.c for py3k.
>> Please note, simple test like:
>>
>> from timeit import timeit
>>
>> print('list', timeit("l[0]", "l = [1]"))
>> print('tuple', timeit("l[0]", "l = (1,)"))
>>
>> Has results:
>>
>> andrew@ocean ~/p/cpython> python2.7 z.py
>> ('list', 0.03479599952697754)
>> ('tuple', 0.046610116958618164)
>>
>> andrew@ocean ~/p/cpython> python3.2 z.py
>> list 0.04870104789733887
>> tuple 0.04825997352600098
>>
>> For python2.7 list[int] microoptimization saves 25-30%, while 3.2 (and
>> trunk) very close to "unoptimized" 2.7 version.
>
> My point is that on non-trivial benchmarks, the savings are almost zero.
> If you look at the (much more complex) patch I linked to, the savings
> are at most 10% on a couple of select benchmarks, other benchmarks
> showing almost no difference.
>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/andrew.svetlov%40gmail.com
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] tuple[int] optimization
On Jul 23, 2011, at 5:18 PM, Antoine Pitrou wrote: > > My point is that on non-trivial benchmarks, the savings are almost zero. That could be said of any optimization in Python. Typical Python scripts exercise many features at time, so any one optimization by itself if almost useless. Collectively however, we've gotten nice speed-ups on real programs. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [PEPs] Rebooting PEP 394 (aka Support the /usr/bin/python2 symlink upstream)
I put up a tracker issue at http://bugs.python.org/issue12627 There are patches for 2.7 as well as tip, but they only fix the Makefiles; no changes are done to documentation. Also, Ned, it appears that Python 2.7 doesn't install the Idle or PyDoc binaries (grep the 2.7 Makefile to see what I mean), so I didn't make any changes related to idle2 or pydoc2. -Kerrick Staley On Wed, Jul 20, 2011 at 3:28 AM, Nick Coghlan wrote: > > On Wed, Jul 20, 2011 at 4:53 PM, Kerrick Staley > wrote: > > Nick, can you please apply the patch (will be sent in the following > > email) to the PEP SVN as soon as we get the hard-link issue is figured > > out? Alternatively, could you provide me write access to just the > > pep-0394.txt file so I can update it myself? Thanks. > > Done: http://www.python.org/dev/peps/pep-0394/ > > Main thing needed now is a tracker issue to reference (ideally with a > first cut at a patch) and python-dev's collective blessing to take it > out of Draft status. > > Cheers, > Nick. > > -- > Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Convention on functions that shadow existing stdlib functions
Some background: I'm working (on and off) on issue 11015 - documenting the public functions in test.support Some of the functions in test.support (for example unlink, rmtree) simply shadow existing & popular stdlib functions, with the aim of swallowing the exceptions these may throw. This is confusing, IMHO. For example, grepping 'unlink' on Lib/test/test_*.py files doesn't say much about which unlink is being used. A couple of options to handle this are: 1. Remove these functions altogether, trying to use existing constructs (such as the ignore_errors parameter in rmtree). 2. Adapt a naming convention for such functions, for instance rmtree_silent and unlink_silent (or a similar convention, if one exists) Opinions? Eli ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] is sys.modules not meant to be replaced?
The documentation[1] doesn't say, but the implementation of the imp module makes me wonder if sys.modules was not meant to be replaceable. No doubt this has to do with its tie to the interpreter's modules dict. I ran into this doing "sys.modules = sys.modules.copy()" to protect the actual sys.modules dict during some import related test cases. If the modules I imported were extension modules it broke. So, is sys.modules not meant to be open to re-binding? -eric p.s. I tried opening a tracker ticket on this, but it wouldn't go through. I'll try again later. [1] http://docs.python.org/library/sys.html#sys.modules ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] is sys.modules not meant to be replaced?
2011/7/23 Eric Snow : > The documentation[1] doesn't say, but the implementation of the imp > module makes me wonder if sys.modules was not meant to be replaceable. > No doubt this has to do with its tie to the interpreter's modules > dict. I ran into this doing "sys.modules = sys.modules.copy()" to > protect the actual sys.modules dict during some import related test > cases. If the modules I imported were extension modules it broke. > > So, is sys.modules not meant to be open to re-binding? Not any more or less than other global mutable objects. You can expect other code to be holding on to old references. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] is sys.modules not meant to be replaced?
On Sat, Jul 23, 2011 at 10:55 PM, Benjamin Peterson wrote: > 2011/7/23 Eric Snow : >> The documentation[1] doesn't say, but the implementation of the imp >> module makes me wonder if sys.modules was not meant to be replaceable. >> No doubt this has to do with its tie to the interpreter's modules >> dict. I ran into this doing "sys.modules = sys.modules.copy()" to >> protect the actual sys.modules dict during some import related test >> cases. If the modules I imported were extension modules it broke. >> >> So, is sys.modules not meant to be open to re-binding? > > Not any more or less than other global mutable objects. You can expect > other code to be holding on to old references. But, isn't sys.modules a little different because other modules (at least the imp module) don't use it. From what I understand the interpreter object's modules dict (to which sys.modules is initially bound) is used directly instead. So rebinding sys.modules causes a disconnect. That's why I am wondering if sys.modules is not meant to be rebound. Are there other objects in the interpreter state that are exposed in sys that would have the same problem? -eric > > > -- > Regards, > Benjamin > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] is sys.modules not meant to be replaced?
2011/7/24 Eric Snow : > On Sat, Jul 23, 2011 at 10:55 PM, Benjamin Peterson > wrote: >> 2011/7/23 Eric Snow : >>> The documentation[1] doesn't say, but the implementation of the imp >>> module makes me wonder if sys.modules was not meant to be replaceable. >>> No doubt this has to do with its tie to the interpreter's modules >>> dict. I ran into this doing "sys.modules = sys.modules.copy()" to >>> protect the actual sys.modules dict during some import related test >>> cases. If the modules I imported were extension modules it broke. >>> >>> So, is sys.modules not meant to be open to re-binding? >> >> Not any more or less than other global mutable objects. You can expect >> other code to be holding on to old references. > > But, isn't sys.modules a little different because other modules (at > least the imp module) don't use it. From what I understand the > interpreter object's modules dict (to which sys.modules is initially > bound) is used directly instead. So rebinding sys.modules causes a > disconnect. That's why I am wondering if sys.modules is not meant to > be rebound. Sure. I'm not sure what point you're trying to make, though. > > Are there other objects in the interpreter state that are exposed in > sys that would have the same problem? Is it problematic? -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3.2.1 encoding surprise
On 7/23/2011 5:34 AM, Vinay Sajip wrote: Glenn Linderman g.nevcal.com> writes: I aim to update the launcher downloads Real Soon Now. Has fixed my problem with not having a local py.ini file, and now is picking up python=3 from the py.ini coresident to the py.exe. Thanks, Mark & Vinay. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] is sys.modules not meant to be replaced?
On Sun, Jul 24, 2011 at 3:05 PM, Eric Snow wrote: > Are there other objects in the interpreter state that are exposed in > sys that would have the same problem? Rebinding (rather than mutating) any global state in any module is always dubious due to the potential for direct references to the previous value. (This is a large part of the reason why imp.reload() often doesn't work in practice) sys.modules, sys.path, sys.argv, sys.stdout, et al are all subject to that caveat. For mutable state, the onus is typically on the developer performing the substitution to decide whether or not those consequences are acceptable (usually, they're not, hence you get idioms like "sys.path[:] = saved_copy" to revert sys.path to a saved value). For immutable state (such as sys.stdout), where modification in place isn't possible, the obligation often goes the other way, with developers deliberately avoiding cached references in order to correctly react to runtime changes. sys.modules is by far the worst case though, since dropping modules out of that cache is only safe for modules that correctly support imp.reload(). This is not the case for any module that mutates other global state (or is otherwise referenced from other modules), nor does it work properly for extension modules. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
