🌐 Mailman 3 August 2004 - Python-list - python.org

Re: Quixote vs. Preppy
by A.M. Kuchling Aug. 6, 2004

Aug. 6, 2004

On Thu, 5 Aug 2004 10:55:19 -0600, Bruce Eckel <BruceEckel(a)MailBlocks.com> wrote: > programmer"), but someone also suggested Preppy from Reportlabs: > http://www.reportlab.org/preppy.html Preppy looks like a templating library, not an arbitrary web framework, so the direct comparison is to Quixote's PTL. It should be straightforward to use Preppy templates from a Quixote handler function, something like: import preppy def _q_index (request): d = {'name':'amk', ...} m = preppy.getModule('template') return m.run(d) (The Quixote Wiki at http://www.quixote.ca/qx/ also includes examples showing Quixote with other templating libraries such as SimpleTAL. The tips on http://www.quixote.ca/qx/TemplatingWithZpt are probably relevant.) --amk

3 2

Re: Confused about pep 318
by Edward K. Ream Aug. 6, 2004

Aug. 6, 2004

> Sorry, but if discussions on python-dev are not considered "public", what is? The reason that discussions on py-dev were not valid a public discussion of '@' is that there was no public announcement that pep 318 pertained to '@'. It's that simple. It's sorta like holding a public meeting supposedly to discuss sewers and voting to give all the county commissioners 100% raises instead :-) The public wasn't informed of the true nature of the meeting, so the open meeting law was violated. To repeat: given that pep 318 is grossly misleading, I contend that no proper discussion of it has ever taken place. Sorry, but if you actively mislead the public, then the public _does_ have a right to complain. The web is a huge place. Expecting people to track it without proper notice of what is being discussed is patently unfair. Edward -------------------------------------------------------------------- Edward K. Ream email: edreamleo(a)charter.net Leo: Literate Editor with Outlines Leo: http://webpages.charter.net/edreamleo/front.html --------------------------------------------------------------------

2 1

Re: Confused about pep 318
by Edward K. Ream Aug. 6, 2004

Aug. 6, 2004

> > There had previously been no public discussions about it. > Nonsense. I could not disagree more. Pretending that discussions on py-dev and SourceForge count as truly public discussions of pep 318 is most unwise. pep 318 does not discuss '@' at all. People like me, with a strong interest in how Python uses '@', would not naturally have known about the proposed new syntax until the stuff hit the fan. Indeed, pep 318 is grossly misleading; reading it one gets the distinct impression that the design is far from complete. It is my strong opinion that _no_ public discussion of this new code has taken place, and none _can_ take place until we see what it is exactly that is being proposed. This is an issue of basic fairness and openness. I have complained loudly to the [B]DFL. We shall see... Edward -------------------------------------------------------------------- Edward K. Ream email: edreamleo(a)charter.net Leo: Literate Editor with Outlines Leo: http://webpages.charter.net/edreamleo/front.html --------------------------------------------------------------------

5 4

Re: Confused about pep 318
by Ville Vainio Aug. 6, 2004

Aug. 6, 2004

>>>>> "Anthony" == Anthony Baxter <anthonybaxter(a)gmail.com> writes: Anthony> On Thu, 05 Aug 2004 13:29:29 -0400, Peter Hansen <peter(a)engcorp.com> wrote: >> I'll make another donation to PSF if the final decorator syntax >> does not Perlishly use arbitrary punctuation as the @ syntax >> does. Anthony> FFS. What exactly is "Perlish" about @? It's an unused Anthony> symbol. That's all. It's hardly arbitrary - Java, for Anthony> instance, already uses @ for the same thing. The problem with @ as I see it (FWIW, of course) is that the new syntax wastes @ for a minor feature. I wouldn't mind @[decorator], which would allow reserving stuff like @private (compiler / type inferrer / macro / whatever) for future extension of the language. And "def decorator func(args):" is even worse. Most interesting applications of decorators involve decorators with arguments... -- Ville Vainio http://tinyurl.com/2prnb

2 1

Decorator keyword
by steven.bethard＠gmail.com Aug. 6, 2004

Aug. 6, 2004

I mentioned in a previous post that I'd much prefer some sort of keyword as a decorator indication than a character like @ (or the recently suggested |). A promising note on python-dev: http://mail.python.org/pipermail/python-dev/2004-August/047001.html > Perhaps this could be addressed by requiring "from __future__ import > decorators", for one release, just like was done for "yield". I > expect that this would be acceptable to the ObjC folks, too. It > wouldn't be my favorite, but I won't rule it out just because of the > new keyword (and yes, this is a softening of my position on new > keywords). > > --Guido van Rossum (home page: http://www.python.org/~guido/) I was just going to let this go because I thought it had been shut down, but as it seems to have been reopened, I'd love to see something like: with classmethod with returns(int) def func(*args, **kwds): return 1 Or if you don't like so many lines: with [classmethod, returns(int)] def func(*args, **kwds): return 1 Or perhaps, if you like to see the def by itself: def func(*args, **kwds) with [classmethod, returns(int)]: return 1 Really, I'd be much happier with any of these than any of the solely symbol-based versions. Neither [] alone after a function def or '@' before one reads clearly to me as an indicator of decoratorhood. I've always liked that Python tries to be human-readable (e.g. "for x in lst" reads almost like English). If at all possible, I'd like decorators to be the same way. In fact, while I've only used 'with' above (because it was non-'as' keyword suggestion in the wiki), I'd be just as happy (maybe happier) with 'decorate' or 'deco' or something along those lines that would read even easier. Steve

2 1

tkinter idle handler
by John Hunter Aug. 6, 2004

Aug. 6, 2004

Does tkinter have an idle handler analogous to pygtk's gtk.idle_add? Normally I could find this myself on google, but googling for tkinter idle turns up a few false positives <wink>. JDH

1 0

Re: Decorator syntax
by Mark 'Kamikaze' Hughes Aug. 6, 2004

Aug. 6, 2004

C. Barnes <connellybarnes(a)yahoo.com> wrote on Wed, 4 Aug 2004 18:42:48 -0700 (PDT): > I vote for > def f(): [synchronized, classmethod] > (body of function) That syntax looks plausible in toy examples, but is terrible for a more typical invocation, like: class foo: def introduceNewFeature(self, someArgument, anotherArgument): [synchronized, types="o,i,i"] pass # whatever > This is backwards compatible (Python <= 2.3 raise > SyntaxError), That's not what "backwards compatible" means, but @-syntax also raises a syntax error in older versions, which is just what you'd expect. > and looks much nicer than @. I fail to see how that's more attractive than: class foo: @synchronized @types("o,i,i") def introduceNewFeature(self, someArgument, anotherArgument): pass # whatever I'm +1 for the @-syntax. 1) It doesn't cause needless line-wrap. 2) It causes the minimum amount of confusion, because it doesn't overload an existing symbol. [] and {} and () are already pushed to their limits and beyond in Python. Give them a day off for once. 3) A large proportion of Python programmers are also Java programmers, and won't object to the @-syntax. > The only problem is that you can't one-line a > decorated function. You can't do that with > the @ notation either, so it's not a big deal. One-liners are of negative value to a language, anyway, as they encourage bad habits. That way lies Perl and other juvenile entertainments. -- <a href="http://kuoi.asui.uidaho.edu/~kamikaze/"> Mark Hughes </a> "Virtues foster one another; so too, vices. Bad English kills trees, consumes energy, and befouls the Earth. Good English renews it." -The Underground Grammarian, v1n2

2 2

Getting memory usage of Python objects
by Tom Harris Aug. 6, 2004

Aug. 6, 2004

Greetings I have a script that runs for several hours on an XP box. During this time its memory usage grows to absurd amounts. I have checked the code and it's not obvious what is growing. Is there a way that I can access the memory usage of each object so that I could find out which one is too large? Regards TomH <tom.harris(a)opdicom.com>

1 0

RE: how to force a list to be local?
by Robert Brewer Aug. 5, 2004

Aug. 5, 2004

Mark Harrison wrote: > In the following code, t1 does not modify b, while t2 seems to > modify b. What do I need to do in order to make b local in t2 > so that b.remove() does not modify the passed in list? > > def t1(a,b): > b = [] > > def t2(a,b): > b.remove(4) Short answer: make a copy of the list. def t2(a, b): b = b[:] b.remove(4) Robert Brewer MIS Amor Ministries fumanchu(a)amor.org

1 0

how to force a list to be local?
by Mark Harrison Aug. 5, 2004

Aug. 5, 2004

In the following code, t1 does not modify b, while t2 seems to modify b. What do I need to do in order to make b local in t2 so that b.remove() does not modify the passed in list? def t1(a,b): b = [] def t2(a,b): b.remove(4) a=[1,2,3] b=[4,5] t1(a,b) print a,b t2(a,b) print a,b results: [1, 2, 3] [4, 5] [1, 2, 3] [5] Many TIA! Mark -- Mark Harrison Pixar Animation Studios

1 0