Mailman 3 March 2000 - Python-Dev

RE: [Patches] selfnanny.py: checking for "self" in every method
by Tim Peters March 5, 2000

March 5, 2000

[Guido van Rossum] > Before we all start writing nannies and checkers, how about a standard > API design first? I will want to call various nannies from a "Check" > command that I plan to add to IDLE. I already did this with tabnanny, > and found that it's barely possible -- it's really written to run like > a script. I like Moshe's suggestion fine, except with an abstract base class named Nanny with a virtual method named check_ast. Nannies should (of course) derive from that. > Since parsing is expensive, we probably want to share the parse tree. What parse tree? Python's parser module produces an AST not nearly "A enough" for reasonably productive nanny writing. GregS & BillT have improved on that, but it's not in the std distrib. Other "problems" include the lack of original source lines in the trees, and lack of column-number info. Note that by the time Python has produced a parse tree, all evidence of the very thing tabnanny is looking for has been removed. That's why she used the tokenize module to begin with. God knows tokenize is too funky to use too when life gets harder (check out checkappend.py's tokeneater state machine for a preliminary taste of that). So the *only* solution is to adopt Christian's Stackless so I can rewrite tokenize as a coroutine like God intended <wink>. Seriously, I don't know of anything that produces a reasonably usable (for nannies) parse tree now, except via modifying a Python grammar for use with John Aycock's SPARK; the latter also comes with very pleasant & powerful tree pattern-matching abilities. But it's probably too slow for everyday "just folks" use. Grabbing the GregS/BillT enhancement is probably the most practical thing we could build on right now (but tabnanny will have to remain a special case). unsure-about-the-state-of-simpleparse-on-mxtexttools-for-this-ly y'rs - tim

4 5

Re: [Patches] selfnanny.py: checking for "self" in every method
by Moshe Zadka March 4, 2000

March 4, 2000

On Sat, 4 Mar 2000, Guido van Rossum wrote: > Before we all start writing nannies and checkers, how about a standard > API design first? I thoroughly agree -- we should have a standard API. I tried to write selfnanny so it could be callable from any API possible (e.g., it can take either a file, a string, an ast or a tuple representation) > I will want to call various nannies from a "Check" > command that I plan to add to IDLE. Very cool: what I imagine is a sort of modular PyLint. > I already did this with tabnanny, > and found that it's barely possible -- it's really written to run like > a script. Mine definitely isn't: it's designed to run both like a script and like a module. One outstanding bug: no docos. To be supplied upon request <0.5 wink>. I just wanted to float it out and see if people think that this particular nanny is worth while. > Since parsing is expensive, we probably want to share the parse tree. Yes. Probably as an AST, and transform to tuples/lists inside the checkers. > Ideas? Here's a strawman API: There's a package called Nanny Every module in that package should have a function called check_ast. It's argument is an AST object, and it's output should be a list of three-tuples: (line-number, error-message, None) or (line-number, error-message, (column-begin, column-end)) (each tuple can be a different form). Problems? (I'm CCing to python-dev. Please follow up to that discussion to python-dev only, as I don't believe it belongs in patches) -- Moshe Zadka <mzadka(a)geocities.com>. http://www.oreilly.com/news/prescod_0300.html

2 1

HTMLgen-style interface to SQL?
by gvwilson＠nevex.com March 4, 2000

March 4, 2000

[short form] I'm looking for an object-oriented toolkit that will do for SQL what Perl's CGI.pm module, or Python's HTMLgen, does for HTML. Pointers, examples, or expressions of interest would be welcome. [long form] Lincoln Stein's CGI.pm module for Perl allows me to build HTML in an object-oriented way, instead of getting caught in the Turing tarpit of string substitution and printf. DOM does the same (in a variety of languages) for XML. Right now, if I want to interact with an SQL database from Perl or Python, I have to embed SQL strings in my programs. I would like to have a DOM-like ability to build and manipulate queries as objects, then call a method that translate the query structure into SQL to send to the database. Alternatively, if there is an XML DTD for SQL (how's that for a chain of TLAs?), and some tool to convert the XML/SQL to pure SQL, so that I could build my query using DOM, that would be cool too. RSVP, Greg Wilson gvwilson(a)nevex.com

1 0

Re: [Python-Dev] Design question: call __del__ for cyclical garbage?
by Jack Jansen March 3, 2000

March 3, 2000

The __init__ rule for calling __del__ has me confused. Is this per-class or per-object? I.e. what will happen in the following case: class Purse: def __init__(self): self.balance = WithdrawCashFromBank(1000) def __del__(self): PutCashBackOnBank(self.balance) self.balance = 0 class LossyPurse(Purse): def __init__(self): Purse.__init__(self) raise 'kaboo! kaboo!' If the new scheme means that the __del__ method of Purse isn't called I think I don't like it. In the current scheme I can always program defensively: def __del__(self): try: b = self.balance self.balance = 0 except AttributeError: pass else: PutCashBackOnBank(b) but in a new scheme with a per-object "__del__ must be called" flag I can't... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

1 0

str vs repr at prompt again (FW: String printing behavior?)
by Tim Peters March 2, 2000

March 2, 2000

Another unsolicited testimonial that countless users are oppressed by auto-repr (as opposed to auto-str) at the interpreter prompt. Just trying to keep a once-hot topic from going stone cold forever <wink>. -----Original Message----- From: python-list-admin(a)python.org [mailto:python-list-admin@python.org] On Behalf Of Ted Drain Sent: Wednesday, March 01, 2000 5:42 PM To: python-list(a)python.org Subject: String printing behavior? Hi all, I've got a question about the string printing behavior. If I define a functions as: >>> def foo(): ... return "line1\nline2" >>> foo() 'line1\013line2' >>> print foo() line1 line2 >>> It seems to me that the default printing behavior for strings should match behavior of the print routine. I realize that some people may want to see embedded control codes, but I would advocate a seperate method for printing raw byte sequences. We are using the python interactive prompt as a pseudo-matlab like user interface and the current printing behavior is very confusing to users. It also means that functions that return text (like help routines) must print the string rather than returning it. Returning the string is much more flexible because it allows the string to be captured easily and redirected. Any thoughts? Ted -- Ted Drain Jet Propulsion Laboratory Ted.Drain(a)jpl.nasa.gov -- http://www.python.org/mailman/listinfo/python-list

2 1

Re: [Python-Dev] Re: A warning switch?
by Jack Jansen March 1, 2000

March 1, 2000

> > What about adding a command-line switch for enabling warnings, as has > > been suggested long ago? The .append() change could then print a > > warning in 1.6alphas (and betas?), but still run, and be turned into > > an error later. > > That's better. I propose that the warnings are normally on, and that > there are flags to turn them off or thrn them into errors. Can we then please have an interface to the "give warning" call (in stead of a simple fprintf)? On the mac (and possibly also in PythonWin) it's probably better to pop up a dialog (possibly with a "don't show again" button) than do a printf which may get lost. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

3 2

DDJ article on Python GC
by gvwilson＠nevex.com March 1, 2000

March 1, 2000

Jon Erickson (editor-in-chief) of "Doctor Dobb's Journal" would like an article on what's involved in adding garbage collection to Python. Please email me if you're interested in tackling it... Thanks, Greg

2 1

Re: [Python-checkins] CVS: python/dist/src Makefile.in,1.82,1.83
by Greg Stein March 1, 2000

March 1, 2000

On Tue, 29 Feb 2000, Fred L. Drake, Jr. wrote: > Guido van Rossum writes: > > You can already extract this from the updated documetation on the > > website (which has a list of obsolete modules). > > > > But you're righ,t it would be good to be open about this. I'll think > > about it. > > Note that the updated documentation isn't yet "published"; there are > no links to it and it hasn't been checked as much as I need it to be > before announcing it. Isn't the documentation better than what has been released? In other words, if you release now, how could you make things worse? If something does turn up during a check, you can always release again... Cheers, -g -- Greg Stein, http://www.lyra.org/

2 1

Unicode Snapshot 2000-03-01
by M.-A. Lemburg March 1, 2000

March 1, 2000

There is a new Unicode implementation snaphot available at the secret URL. It contains quite a few small changes to the internal APIs, doc strings for all methods and some new methods (e.g. .title()) on the Unicode and the string objects. The code page mappings are now integer->integer which should make them more performant. Some of the C codec APIs have changed, so you may need to adapt code that already uses these (Fredrik ?!). Still missing is a MSVC project file... haven't gotten around yet to build one. The code does compile on WinXX though, as Finn Bock told me in private mail. Please try out the new stuff... Most interesting should be the code in Lib/codecs.py as it provides a very high level interface to all those builtin codecs. BTW: I would like to implement a .readline() method using only the .read() method as basis. Does anyone have a good idea on how this could be done without buffering ? (Unicode has a slightly larger choice of line break chars as C; the .splitlines() method will deal with these) Gotta run... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

1 0

Re: Python / Haskell (fwd)
by gvwilson＠nevex.com March 1, 2000

March 1, 2000

[Forwarded to this list with Phil Wadler's permission.] > Greg Wilson wrote: > Hi, Phil. I was talking to a couple of colleagues over the weekend, > one of whom learned Miranda as his second language and never really > recovered :-). I was wondering: if you could add one or two features > of Haskell to Python, what would you choose? And why? Philip Wadler <wadler(a)research.bell-labs.com> wrote: Well, what I most want is typing. But you already know that. Next after typing? Full lexical scoping for closures. I want to write: fun x: fun y: x+y Not: fun x: fun y, x=x: x+y Lexically scoped closures would be a big help for the embedding technique I described [GVW: in a posting to the Software Carpentry discussion list, archived at http://software-carpentry.codesourcery.com/lists/sc-discuss/msg00068.html which discussed how to build a flexible 'make' alternative in Python]. Next after closures? Disjoint sums. E.g., fun area(shape) : switch shape: case Circle(r): return pi*r*r case Rectangle(h,w): return h*w (I'm making up a Python-like syntax.) This is an alternative to the OO approach. With the OO approach, it is hard to add area, unless you modify the Circle and Rectangle class definitions. On the other hand, with disjoint sums it is hard to add a new shape, unless you modify all the existing switch statements for shapes. This is a well-known tradeoff, see e.g., the discussion in my paper with Odersky on Pizza, or the ECOOP 98 paper by Felleisen and Krishnamurthi. [GVW: the Pizza paper is available from: http://cm.bell-labs.com/cm/cs/who/wadler/topics/gj.html The Felleisen and Krishnamurthi paper is at: http://www.cs.rice.edu/CS/PLT/Publications/#tr98-299 ]

2 1