Re: [Python-3000] Draft PEP: Module Initialization and finalization

2006-04-12 Thread Tim Peters
[Greg Ewing] > It's been suggested before that the explicit clearing > of a module at interpreter shutdown should be replaced > with just letting cyclic GC do its thing. Is there any > reason why that wouldn't work? It might lead to less of > the unintuitive behaviour that sometimes occurs because

Re: [Python-3000] symbols?

2006-04-12 Thread Greg Ewing
Michael Chermside wrote: > I must > be unusually lucky in this regard, because I meet lots of people who > are very concerned about the fact that it *is* possible to change > these values. Occasionally I wonder whether it would be useful to have some form of const declaration in the language, not

Re: [Python-3000] Draft PEP: Module Initialization and finalization

2006-04-12 Thread Greg Ewing
Thomas Wouters wrote: > > On 4/12/06, *"Martin v. Löwis"* <[EMAIL PROTECTED] > > wrote: > > This raises the question whether modules should be able to > participate in cyclic GC... > > Don't they already? They have a traverse proc, just not a clear proc. It's

Re: [Python-3000] Adaptation vs. Generic Functions

2006-04-12 Thread Guido van Rossum
On 4/12/06, Tim Hochberg <[EMAIL PROTECTED]> wrote: > What would happen if 'a+b' was just syntactic sugar for > 'operator.add(a,b)', where operator.add was a generic > function, instead of the current magic dance involving > __add__ and __radd__. Funny, exactly the same thought

Re: [Python-3000] Interfaces for views and extended collections

2006-04-12 Thread Brett Cannon
On 4/11/06, Ian Bicking <[EMAIL PROTECTED]> wrote: > So Guido asked for more concrete discussion of things like views. A > richer set of collections also fits in here, as for instance dict.keys() > would be a view with a collection interface not exactly like other > collections. I wrote up some n

Re: [Python-3000] Adaptation vs. Generic Functions

2006-04-12 Thread Tim Hochberg
Here's a little thought experiment: What would happen if 'a+b' was just syntactic sugar for 'operator.add(a,b)', where operator.add was a generic function, instead of the current magic dance involving __add__ and __radd__. Neglecting the fact that it would break all Python co

Re: [Python-3000] Adaptation vs. Generic Functions

2006-04-12 Thread Tim Hochberg
This is just a little update on my rewrite of pprint. I've continued to clean up and optimize this. If anyone wants to look at it, I've updated the code here: http://members.cox.net/~tim.hochberg/pprint2.py [The changes are probably not signifigant enough to justify another posting of t

Re: [Python-3000] symbols?

2006-04-12 Thread Adam DePrince
On Tue, 2006-04-11 at 12:11 +1200, Greg Ewing wrote: > Kendall Clark wrote: > > > One thing I'd really like to see in Python 3000 is support for first- > > class symbols, with literal syntax. > > Actually I think enumerations would be more useful than > symbols. There's no essential difference b

Re: [Python-3000] Draft PEP: Module Initialization and finalization

2006-04-12 Thread Thomas Wouters
On 4/12/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: Thomas Wouters wrote:> Actually, no, reload() has to remove the module from sys.modules and> load it anew.That's not what reload currently does for Python modules. The moduleobject stays the same (so that anybody who imported it will also see

Re: [Python-3000] Draft PEP: Module Initialization and finalization

2006-04-12 Thread Martin v. Löwis
Thomas Wouters wrote: > Actually, no, reload() has to remove the module from sys.modules and > load it anew. That's not what reload currently does for Python modules. The module object stays the same (so that anybody who imported it will also see the reload's effect). > The reason for this is tha

Re: [Python-3000] symbols?

2006-04-12 Thread Michael Chermside
Kendall Clark writes: > The other choice, of course, is for the library or API to define some > variables bound to strings and then use them like constants, except > that they can get redefined: > > @pylons.rest.restrict(GET, HEAD) > ... > > A symbol has the advantage that it can't be assig

Re: [Python-3000] Draft PEP: Module Initialization and finalization

2006-04-12 Thread Thomas Wouters
On 4/12/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: Thomas Wouters wrote:> In fact... perhaps module functions should then get the module object as> the first argument (currently unused but always defined)?That wouldn't work: the first argument currently *is* used, atleast if you pass a non-NU

Re: [Python-3000] Draft PEP: Module Initialization and finalization

2006-04-12 Thread Thomas Wouters
On 4/12/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: Tim Peters quoted Guido:> - when reload() is used on an extensionThis is trickier: I guess reload should invoke the finalize function,discard the memory for the state, and then invoke the initialize function again, which will allocate a new s

Re: [Python-3000] Draft PEP: Module Initialization and finalization

2006-04-12 Thread Martin v. Löwis
Tim Peters wrote: > PythonLabs never found the bandwidth for this, as we all spent the > next year trying to teach Barry how to use Unicode. I don't even > remember what the thread above was about, but it would be great if the > PEP contained enough relevant words that I could finally clean that >