Mailman 3 January 2000 - Python-Dev

Changing existing class instances
by A.M. Kuchling Feb. 9, 2000

Feb. 9, 2000

Currently, when you replace a class definition with an updated version, it's really difficult to change existing class instances; you'd have to essentially sweep every Python object and check if it's an instance, starting at roots such as __main__ and sys.modules. This makes developing code in a long-running process difficult, Zope being the best example of this. When you modify a class definition used by Zope code, you can't update existing instances floating around in memory. Over dinner, … [View More]a friend and I were discussing this, and we thought it probably isn't difficult to add an extra level of indirection to allow fixing this. The only other option we could think of is either the complete scan of all objects, or inserting a forwarding pointer into PyClassObjects that points to the replacing class if !NULL, and then chase pointers when accessing PyInstanceObject->in_class. A quick hack to implement the extra indirection took about half an hour. It does these things: * Defines a PyClassHandle type: struct _PyClassHandle { PyClassHandle *next; /* ptr to next PyClassHandle in linked list */ PyClassObject *klass; /* The class object */ } ; * The in_class attribute of PyInstanceObject becomes a PyClassHandle* instead of a PyClassObject*, and all code such as inst->in_class becomes inst->in_class->klass. * As a quick hack to allow changing the class object referenced by a handle, I added a .forward( <newclassobject> ) method to class objects. This basically does self.handle->klass = <newclassobject>. The end result is that obj.__class__.forward(newclass) changes obj to be an instance of newclass, and all other instances of obj.__class__ also mutate to become newclass instances. Making this purely automatic seems hard; you'd have to catch things like 'import ftplib; ftplib.FTP = myclass', which would require automatically calling ftplib.FTP.forward( myclass ) to make all existing FTP instances mutate. Would it be worthwhile to export some hook for doing this in 1.6? The cost is adding an extra pointer deref to all access to PyInstanceObject->in_class. (This could probably also be added to ExtensionClass, and probably doesn't need to be added to core Python to help out Zope. Just a thought...) -- A.M. Kuchling http://starship.python.net/crew/amk/ Here the skull of a consumptive child becomes part of a great machine for calculating the motions of the stars. Here, a yellow bird frets within the ribcage of an unjust man. -- Welcome to Orqwith, in DOOM PATROL #22 [View Less]

12 39

Python 1.6 timing
by Guido van Rossum Feb. 4, 2000

Feb. 4, 2000

Andrew let me repost this mail of his to this list. It's worth a discussion here (if not in a larger forum). My responses are at the bottom. ------- Forwarded Message Date: Wed, 19 Jan 2000 20:17:55 -0500 From: "A.M. Kuchling" <amk1(a)erols.com> To: guido(a)python.org Subject: Python 1.6 timing I thought a bit more about the release schedule for 1.6, and like the idea of delaying it less and less. Another bad effect of delaying it is that not having Unicode in the core … [View More]handicaps developing XML tools; we can continue working with wstrop, or integrate MAL's code into the XML-SIG's CVS tree, but it might mean abandoning the XML processing field to Perl & Tcl because the tools can't be made fully standard compliant in time. Options I can think of: 1) Delegating some control to a pumpkin holder [...]. 2) Releasing the Unicode+sre modules as separate add-ons to 1.5. (But would that impose annoying backward-compatibility constraints when they get integrated into 1.6?) 3) Add Unicode, sre, Distutils, plus other minor things and call it 1.5.5, meaning it's not as big a revision as a 1.6 release, but it's bigger than just another patchlevel of bugfixes. I don't remember what other features were planned for 1.6; was there anything major, if static typing is left for 2.0? - -- A.M. Kuchling http://starship.python.net/crew/amk/ Life's too short for chess. -- H.J. Byron ------- End of Forwarded Message There are several other things I can think of now that were planned for 1.6: revamped import, rich comparisons, revised coercions, parallel for loop (for i in L; j in M: ...), extended slicing for all sequences. I've also been thinking about making classes be types (not as huge a change as you think, if you don't allow subclassing built-in types), and adding a built-in array type suitable for use by NumPy. I've also received a conservative GC patch that seems to be fairly easy to apply and has some of Tim Peters' blessing. For 1.5.5 (what happened to 1.5.3 and 1.5.4?), we can have a more conservative agenda, as suggested by Andrew: Unicode and distutils are probably the most important things to integrate. (The import utilities are not ready for prime time in my opinion; there are too many issues.) Anybody care to be the pumpkin? That would cut the discussion short; otherwise the problem remains that I can't spend too much time on the next release unless I get funded for it; what little money I've received for CP4E I had better spend on getting some CP4E-related results ASAP, because the next installment of this funding is very much at stake... --Guido van Rossum (home page: http://www.python.org/~guido/) Life's better without braces. -- Bruce Eckel [View Less]

20 70

Adding C ternary select (a?b:c) to Python?
by Guido van Rossum Feb. 3, 2000

Feb. 3, 2000

Dear developers, Eric Raymond has sent me the following patch, which adds conditional expressions to Python. I'd like to hear opinions on whether this is a good thing to add to Python, and whether this is the right syntax. I am a bit skeptical about whether this is sufficiently Pythonic, but on the other hand there have always been requests for such a feature, and the existing solutions are ugly: a and b or c only works when you know for sure that b will never be false, and (a and [b] … [View More]or [c])[0] is dead ugly... --Guido van Rossum (home page: http://www.python.org/~guido/) Subject: Ternary select -- here it is. From: "Eric S. Raymond" <esr(a)thyrsus.com> To: Guido Van Rossum <guido(a)CNRI.Reston.Va.US> Date: Sat, 29 Jan 2000 17:40:31 -0500 X-Eric-Conspiracy: There is no conspiracy Dang, Guido, this was *fun*! This patch extends the Python interpreter to support the C ternary operator, and documents the extension in the Reference Manual. The implementation is dead simple and robust: it's adapted from the existing code for if statements, and adds or changes less than 70 lines of code all told. Diffs between last version checked in and current workfile(s): --- Grammar/Grammar 2000/01/28 17:10:18 1.1 +++ Grammar/Grammar 2000/01/29 22:14:05 @@ -61,7 +61,8 @@ except_clause: 'except' [test [',' test]] suite: simple_stmt | NEWLINE INDENT stmt+ DEDENT -test: and_test ('or' and_test)* | lambdef +test: bool_test ['?' bool_test ':' bool_test] +bool_test: and_test ('or' and_test)* | lambdef and_test: not_test ('and' not_test)* not_test: 'not' not_test | comparison comparison: expr (comp_op expr)* --- Include/token.h 2000/01/28 17:38:55 1.1 +++ Include/token.h 2000/01/29 01:27:00 @@ -74,10 +74,11 @@ #define LEFTSHIFT 34 #define RIGHTSHIFT 35 #define DOUBLESTAR 36 +#define QUERY 37 /* Don't forget to update the table _PyParser_TokenNames in tokenizer.c! */ -#define OP 37 -#define ERRORTOKEN 38 -#define N_TOKENS 39 +#define OP 38 +#define ERRORTOKEN 39 +#define N_TOKENS 34 /* Special definitions for cooperation with parser */ --- Modules/parsermodule.c 2000/01/28 18:03:27 1.1 +++ Modules/parsermodule.c 2000/01/29 22:13:45 @@ -945,6 +945,7 @@ #define validate_star(ch) validate_terminal(ch, STAR, "*") #define validate_vbar(ch) validate_terminal(ch, VBAR, "|") #define validate_doublestar(ch) validate_terminal(ch, DOUBLESTAR, "**") +#define validate_query(ch) validate_terminal(ch, QUERY, "?") #define validate_dot(ch) validate_terminal(ch, DOT, ".") #define validate_name(ch, str) validate_terminal(ch, NAME, str) @@ -963,7 +964,8 @@ VALIDATER(exec_stmt); VALIDATER(compound_stmt); VALIDATER(while); VALIDATER(for); VALIDATER(try); VALIDATER(except_clause); -VALIDATER(test); VALIDATER(and_test); +VALIDATER(test); +VALIDATER(bool_test); VALIDATER(and_test); VALIDATER(not_test); VALIDATER(comparison); VALIDATER(comp_op); VALIDATER(expr); VALIDATER(xor_expr); VALIDATER(and_expr); @@ -1829,12 +1831,34 @@ } /* validate_except_clause() */ +/* bool_test ( | bool_test ? bool_test ) + * + */ static int validate_test(tree) node *tree; { + if (!validate_ntype(tree, test)) + return 0; + else if (NCH(tree) == 1) + return(validate_bool_test(CHILD(tree, 0))); + else if (validate_numnodes(tree, 5, "expr")) + { + return validate_bool_test(CHILD(tree, 0)) + && validate_query(CHILD(tree, 1)) + && validate_bool_test(CHILD(tree, 2)) + && validate_colon(CHILD(tree, 3)) + && validate_bool_test(CHILD(tree, 4)); + } +} /* validate_test() */ + + +static int +validate_bool_test(tree) + node *tree; +{ int nch = NCH(tree); - int res = validate_ntype(tree, test) && is_odd(nch); + int res = validate_ntype(tree, bool_test) && is_odd(nch); if (res && (TYPE(CHILD(tree, 0)) == lambdef)) res = ((nch == 1) @@ -1848,7 +1872,7 @@ } return (res); -} /* validate_test() */ +} /* validate_bool_test() */ static int --- Parser/tokenizer.c 2000/01/28 17:37:48 1.1 +++ Parser/tokenizer.c 2000/01/29 01:27:26 @@ -99,6 +99,7 @@ "LEFTSHIFT", "RIGHTSHIFT", "DOUBLESTAR", + "QUERY", /* This table must match the #defines in token.h! */ "OP", "<ERRORTOKEN>", @@ -384,6 +385,7 @@ case '}': return RBRACE; case '^': return CIRCUMFLEX; case '~': return TILDE; + case '?': return QUERY; default: return OP; } } --- Python/compile.c 2000/01/28 23:17:19 1.1 +++ Python/compile.c 2000/01/29 22:19:29 @@ -1698,11 +1698,11 @@ } static void -com_test(c, n) +com_bool_test(c, n) struct compiling *c; node *n; { - REQ(n, test); /* and_test ('or' and_test)* | lambdef */ + REQ(n, bool_test); /* and_test ('or' and_test)* | lambdef */ if (NCH(n) == 1 && TYPE(CHILD(n, 0)) == lambdef) { PyObject *v; int i; @@ -1738,6 +1738,32 @@ } static void +com_test(c, n) + struct compiling *c; + node *n; +{ + int op; + REQ(n, test); + com_bool_test(c, CHILD(n, 0)); + + /* is there a following ternary operator? */ + /* XXX optimize the compilation when the guard is a constant */ + if (NCH(n) == 5) + { + int anchor1 = 0, anchor2 = 0; + com_addfwref(c, JUMP_IF_FALSE, &anchor2); + com_addbyte(c, POP_TOP); + com_pop(c, 1); + com_node(c, CHILD(n, 2)); + com_addfwref(c, JUMP_FORWARD, &anchor1); + com_backpatch(c, anchor2); + com_addbyte(c, POP_TOP); + com_node(c, CHILD(n, 4)); + com_backpatch(c, anchor1); + } +} + +static void com_list(c, n, toplevel) struct compiling *c; node *n; @@ -2931,6 +2957,9 @@ break; case test: com_test(c, n); + break; + case bool_test: + com_bool_test(c, n); break; case and_test: com_and_test(c, n); --- Doc/ref/ref5.tex 2000/01/29 21:28:13 1.1 +++ Doc/ref/ref5.tex 2000/01/29 22:00:02 @@ -764,7 +764,7 @@ \section{Boolean operations\label{Booleans}} \indexii{Boolean}{operation} -Boolean operations have the lowest priority of all Python operations: +Boolean operations have the lowest priority of all Python binary operations: \begin{verbatim} expression: or_test | lambda_form @@ -832,6 +832,24 @@ def make_incrementor(increment): return lambda x, n=increment: x+n \end{verbatim} + +\section{Select\label{select}} +\index{select} + +The select operator is a ternary operator with lower priority than +boolean operations (and thus lower priority than all other binary and +unary operators). + +\begin{verbatim} +select_expr: xor_expr | xor_expr "?" xor_expr ":" xor_expr +\end{verbatim} + +If its first operand is nonempty, the value of a select operation is +its second operand; otherwise the value is the third operand. + +(The semantics and precedence level of select are intended to be +unsurprising to programmers familiar with \C's ternary select +operator.) \section{Expression lists\label{exprlists}} \indexii{expression}{list} End of diffs. -- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a> You know why there's a Second Amendment? In case the government fails to follow the first one. -- Rush Limbaugh, in a moment of unaccustomed profundity 17 Aug 1993 [View Less]

20 46

Ann: Stackless Python 1.02
by Christian Tismer Jan. 31, 2000

Jan. 31, 2000

Stackless Python is a Python without C stack usage. It allows for all kinds of non-local control flow. For info see http://www.tismer.com/research/stackless/ Update for Stackless Python V. 1.02: - passes all standard tests - should work with Zope now (try...finally was incorrect) - has a smart object destructor for really deeply nested stuff The "5 percent speedup" is no longer there currently, since the smart object destructor needs to be optimized into the objects. It is not done in this … [View More]

1 0

Riskless deletion of nested structures
by Christian Tismer Jan. 31, 2000

Jan. 31, 2000

Howdy, Please review! While implementing Stackless Python, a new problem arose: Nested structures like frame chains and tracebacks can now easily grow somuch that they cause a stack overflow on deallocation. To protect lists, tuples, frames, dicts and tracebacks against this, I wrote a stackless deallocator. At the moment, everything is done in trashcan.c . This gives a slight performance loss of 5% for pystone, most probably due to the double indirection and non-local code reference. It is … [View More]

1 0

Eight suggestions for Python books
by gvwilson＠nevex.com Jan. 30, 2000

Jan. 30, 2000

I realize this is a bit off-topic, but based on discussions with various publishers over the last couple of years, and on conversations at the conference last week, I wrote up some notes on books that I think would help Python succeed, and posted them to comp.lang.python under the heading "Eight suggestions for Python books". Some of the books are specificially about Python, while others try to use Python to fill holes in the curriculum, and thereby get Python into colleges through the side … [View More]

1 0

Multiple dicts for string interpolation?
by Skip Montanaro Jan. 29, 2000

Jan. 29, 2000

Every once in awhile I want to perform string interpolation using more than one dictionary. One way is to build a dictionary that's a union of multiple dictionaries: dict = {} dict.update(d1) dict.update(d2) ... s = format % dict Another way is the MultiDict approach that Digital Creations (used to?) use in their DocumentTemplate module (I can't remember the exact usage any more): dict = MultiDict() dict.append(d1) dict.append(d2) ... s = format % … [View More]

6 11

To-do for Distutils 0.2 (and beyond)
by Greg Ward Jan. 28, 2000

Jan. 28, 2000

Hi all -- [oops: I *said* that I was cc'ing this to python-dev when I posted it to distutils-sig, but I just plain forgot to. So here it is again, still presumed relevant to python-dev'ers because it directly affects the planned Python 1.6 feature set. Please reply either to me directly or to distutils-sig, because that's where the implementation will be done.] recent developments in the planned release schedule for Python 1.6 (Guido doesn't want to wait for everything planned, but get … [View More]something out the door in the next couple of months) are lighting a fire under me to get a seriously usable version of Distutils ready *really* soon now. This will be Distutils 0.2; I anticipate that 0.2.x will be included in Python 1.6, where x is the number of attempts it takes me to get something reasonably bug-free out the door. Those if you who were at the Python Conference this past week will have seen bits and pieces of my "laundry list" of desired features that should be added to the Distutils at some point in the future. Given the shortened schedule, it looks like it's necessary to do some pruning and concentrate on the essentials to get something in Python 1.6. So, here is my current laundry list, sorted into a couple of categories: essential for 0.2 (Python 1.6) ----------------- * fix the "dist" command (two-phase manifest, better feedback) (steal ideas and hopefully code from Gordon Macmillan's installer) * fix the "install" command (have the right interface and do the right thing for installating to non-standard or personal directories) * fix some bad nomenclature in the command classes (most likely 'options' -> 'user_options', 'set_default_options()' -> 'initialize_options()', and 'set_final_options()' -> ??? (maybe 'finalize_options()'?)) * build C libraries (for PIL, and other similar distributions) * documentation (two small manuals that should become standard Python manuals: "Installing Python Modules" and "Developing and Distributing Python Modules") * add a bdist command; should at least be able to generate dumb archives of built distributions (eg. a tarball that you unpack from /usr/local, or maybe /usr/local/lib/python1.5/site-packages) desirable for 0.2 ----------------- * "what's installed" database * dependency checking ("is version 1.3 of foo installed?") * don't automatically clobber an existing installation -- confirm, or require a "force" option, or something * command to install C headers (assuming more extensions than NumPy need to do this) put off to 0.3 (Python 1.7?) ---------------------------- * JPython support (most importantly, know where to install .py modules when run from JPython and be able to build Java extensions for JPython) * build static Python binary (for shared-library-challenged OSs) * SWIG support (mainly, know how to run it before building the C extension it generates) * PyFort support (ditto) * Mac support * allow overlapping multi-architecture installations (Michel Sanner's pet peeve and Guido's nightmare ;-) (this would *not* be the default; it would have to be explicitly chosen by brave/cheap/foolhardy installers) * support for archive sites (Parnassus) to pull out meta-info Anyone feel strongly about moving any of these items around, or discarding any entirely, or adding anything? Please let me know by email; I'll summarize to the list. Thanks -- Greg [View Less]

2 1

Re: [Python-Dev] Multiple dicts for string interpolation?
by Jack Jansen Jan. 26, 2000

Jan. 26, 2000

> the part you didn't like about that? If so, how about changing the > constructor to > > def __init__(self, *dicts): > ... > > instead so you could use it as a one-liner > > format % MultiDict(d1, d2, ...) > > ? That's exactly the same as the tuple idea, except there's a nice > descriptive word in the middle of it <wink>. I've always wonderer why dict+dict isn't supported (or possibly dict|dict, if the key-collision semantics … [View More]

2 1

Re: [Python-Dev] Python 1.6 timing (fwd)
by gvwilson＠nevex.com Jan. 22, 2000

Jan. 22, 2000

Guido> There are several other things I can think of now that were Guido> planned for 1.6: revamped import, rich comparisons, revised Guido> coercions, parallel for loop (for i in L; j in M: ...), Guido> extended slicing for all sequences. I've also been thinking Guido> about making classes be types (not as huge a change as you Guido> think, if you don't allow subclassing built-in types), and Guido> adding a built-in array type suitable for use by NumPy. I've Guido> … [View More]

5 8

Conference Schedules
by David Ascher Jan. 21, 2000

Jan. 21, 2000

Given the rush of interesting discussions and progress which occurs in the two weeks before Python conferences, I propose that we have a bi-weekly conference. We'll just have to remember to cancel them at the last minute except a couple of times a year. --david ascher

1 0

Stackless Python 1.0 + Continuations 0.6
by Christian Tismer Jan. 20, 2000

Jan. 20, 2000

ANNOUNCING: Stackless Python 1.0 A Python Implementation That Does Not Use The C Stack * plus the real toy * Continuation Module 0.6 Continuations as First Class Objects What is it? A plugin-replacement for core Python. It should run any program which runs under Python 1.5.2 . But it does not need space on the C stack. Why did I write it? Stackless Python was never written before (afaik), since it was said to be … [View More]impossible without major rewrites of core Python. I have proven the controverse: It is easy to write, just hard to think. About 3 times harder was finally the continuation module. The whole project took about 6 man months where 80 percent of the time was thinking and trying. The rest was coding and to become a reference counting champion :-) Recent changes: Version 1.0 has been optimized like hell and is now 3-5 percent faster than Standard Python. Continuation module is in version 0.6, very stable, and it allows to save a program's "future" at any time, in a portable way. Continuations are callable Python objects with a very small footprint. Who needs it? Since the continuations are done, this is no more only useful for C programmers who want to try certain new ideas. Everybody who is interested to develop his own generators, coroutines and tiny threads is invited to check it out. Status of the final 1.0: Pystone works correctly and is 5% faster than standard Python. Version 0.3 was 10 percent slower. Continuations work with PythonWin and Idle. The overall result is now better than expected, and I'm happy to call this *FINAL* (until the next version of course:) Downloadable files can be found at http://www.tismer.com/research/stackless/ Some older documentation: http://www.tismer.com/research/stackless/stackless.htm Some better documentation can be found in my IPC8 paper: http://www.tismer.com/research/stackless/spc_final.zip or be read directly as HTML http://www.tismer.com/research/stackless/spcpaper.htm Source code and a VC++6.0 build for Windows (340K): http://www.tismer.com/research/stackless/spc_win32.zip cheers - chris == Christian Tismer :^) <mailto:tismer@appliedbiometrics.com> Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaiserin-Augusta-Allee 101 : *Starship* http://starship.python.net 10553 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF we're tired of banana software - shipped green, ripens at home <P><A HREF="http://www.tismer.com/research/stackless/stackless.htm"> Stackless Python 1.0</A> - a version of Python 1.5.2 that does not need space on the C stack. (20-Jan-00) [View Less]

1 0

SOAP
by David Ascher Jan. 20, 2000

Jan. 20, 2000

Who if anyone is working on SOAP clients and servers for Python? --david ascher

3 2

''.join in 1.6
by Gerrit Holl Jan. 20, 2000

Jan. 20, 2000

Hello, I have a question/suggestion about ''.join in Python 1.6. Suppose I have this list: l = ["This", "is", "a", "test"] Currently, I would join it this way into a tab-delimeted string: s = string.join(l, '\t') In 1.6, I should do it this way: '\t'.join(s) I think it would be better to have that method on the *list*: s.join('\t') That's more clear, isn't it? regards, Gerrit. -- Please correct any bad English you encounter in my email message! -----BEGIN GEEK CODE BLOCK----- http://… [View More]

4 4

Python Tools/
by M.-A. Lemburg Jan. 19, 2000

Jan. 19, 2000

I was just looking through the Tools dir of the CVS version (looking for a tool which autoexpands tabs in Python source files -- which I didn't find) and found some other useful scripts along the way. To my surprise these executable files did not have a .py extension even though were Python source files. Is this intended ? I find that scripts like "world" provide useful information which would be nice to have in the standard lib -- with .py extension... Other tidbits: I noted that at least … [View More]

3 3

developers day session on compilers
by Jeremy Hylton Jan. 17, 2000

Jan. 17, 2000

I am championing a Developers' Day session on a Python compiler. There is a short Web page describing the goals of the session at http://www.python.org/workshops/2000-01/compiler.html. I'd appreciate feedback on the content and format of the session. If you have ideas for what we should talk about or do, please followup to me or to the list. Jeremy

1 0

"이사"도 하고 "정수기"도 받고... [광고]
by 이사몰(24mall) Jan. 9, 2000

Jan. 9, 2000

Untitled DocumentA:active { COLOR: #000000; FONT-SIZE: 12px; TEXT-DECORATION: none }A:link { COLOR: #000000; FONT-SIZE: 12px; TEXT-DECORATION: none }A:visited { COLOR: #000000; FONT-SIZE: 12px; TEXT-DECORATION: none }A:hover { COLOR: #000000; FONT-SIZE: 12px; TEXT-DECORATION: none }TD { FONT-SIZE: 12px; font-face: 굴림 } 온라인 계약을 하신 고객분들에게 무료제공하는 서비스로 A/S 발생시 이사업체가 책임을 회피할때 동양화재에서 최고 1000만원까지 물품배상을 해 드리는 서비스입니다 이사를 했으니 집들이를 하긴 해야겠는데...시간도 없고 … [View More]

1 0

new imputil.py
by Greg Stein Jan. 5, 2000

Jan. 5, 2000

Happy New Year! I've attached a new imputil.py to this message. It isn't posted on my page yet, as I'd like some feedback before declaring this new version viable. In this imputil, there is an ImportManager class. It gets installed as the import hook, with the presumption that it is the only import hook (technically, it could chain, but I've disabled that for now). I think Python 1.6 should drop the __import__ builtin and move to something like sys.import_hook (to allow examination and change)… [View More]. Another alternative would be sys.get_import_hook() and sys.set_import_hook(). [ I don't think we would want a "set" that returned the old version as the only way to get the current hook function; we want to be able to easily find the ImportManager instance. ] The ImportManager knows how to scan sys.path when it needs to find a top-level module/package (e.g. given a.b.c, the "a" is the top-level; b.c falls "below" that). sys.path can contain strings which specify a filesystem directory, or it can contain Importer instances. The manager also records an ordered list of suffix/importer pairs. The add_suffix() method is used to append new suffixes, but clients can also access the .suffixes attribute for fine-grained manipulation/ordering. There is a new importer called _FilesystemImporter which understands how to look into a directory for Python modules. It borrows/refers to the ImportManager's .suffixes attribute, using that to find modules in a directory. This is also the Importer that gets associated with each filesystem-based module. The importers used for suffix-based importing are derived from SuffixImporter. While a function could be used here, future changes will be easier if we presume class instances. The new imputil works fine (use _test_revamp() to switch to the new import mechanism). Importer subclasses using the old imputil should continue to work, although I am deprecating the 2-tuple return value for get_code(). get_code() should return None or the 3-tuple form now. I think I still have a bit more work to do, to enable something like "import a.b.c" where a.zip is an archive on the path and "b.c" resides in the archive. Note: it *is* possible to do sys.path.append(ZipImporter(filename)) and have "a.b.c" in the Zip file. It would simply be nicer to be able to drop arbitrary .zip files onto the path and use their basename as the top-level name of a package. Anyhow: I haven't looked at this scenario yet to find what the new system is missing (if anything). As always: feedback is more than appreciated! Especially from people using imputil today. Did I break anything? Does the new scheme still feel right to you? etc. Cheers, -g p.s. I'd also like to remove PackageArchiveImporter and PackageArchive. They don't seem to add any real value. I might move DirectoryImporter and PathImporter to an "examples" file, too. -- Greg Stein, http://www.lyra.org/ [View Less]

6 9

Better text processing support in py2k?
by Skip Montanaro Jan. 3, 2000

Jan. 3, 2000

It just occurred to me as I was replying to a request on the main list, that Python's text handling capabilities could be a bit better than they are. This will probably not come as a revelation to many of you, but I finally put it together with the standard argument against beefing things up One fix would be to add regular expressions to the language core and have special syntax for them, as Perl has done. However, I don't like this solution because Python is a general-purpose … [View More]language, and regular expressions are used for the single application domain of text processing. For other application domains, regular expressions may be of no interest, and you might want to remove them to save memory and code size. and the observation that Python does support some builtin objects and syntax that are fairly specific to some much more restricted application domains than text processing. I stole the above quote from Andrew Kuchling's Python Warts page, which I also happened to read earlier today. What AMK says makes perfect sense until you examine some of the other things that are in the language, like the Ellipsis object and complex numbers. If I recall correctly both were added as a result of the NumPy package development. I have nothing against ellipses or complex numbers. They are fine first class objects that should remain in the language. But I have never used either one in my day-to-day work. On the other hand, I read files and manipulate them with regular expressions all the time. I rather suspect that more people use Python for some sort of text processing than any other single application domain. Python should be good at it. While I don't want to turn Python into Perl, I would like to see it do a better job of what most people probably use the language for. Here is a very short list of things I think need attention: 1. When using something like the simple file i/o idiom for line in f.readlines(): dofunstuff(line) the programmer should not have to care how big the file is. It should just work in a reasonably efficient manner without gobbling up all of memory. I realize this may require some change to the syntax of the common idiom. 2. The re module needs to be sped up, if not to catch up with Perl, then to catch up with the deprecated regex module. Depending how far people want to go with things, adding some language syntax to support regular expressions might be in order. I don't see that as compelling as adding complex numbers however. Another possibility, now that Barry Warsaw has opened the floodgates, is to add regular expression methods to strings. 3. I've not yet used it, but I am told the pattern matching in Marc-Andre Lemburg's mxTextTools (http://starship.python.net/crew/lemburg/) is both powerful and efficient (though it certainly appears complex). Perhaps it deserves consideration for incorporation into the core Python distribution. I'm sure other people will come up with other suggestions. Skip Montanaro | http://www.mojam.com/ skip(a)mojam.com | http://www.musi-cal.com/ 847-971-7098 | Python: Programming the way Guido indented... [View Less]

5 10

Software Carpentry: GUI Toolkit?
by gvwilson＠nevex.com Jan. 3, 2000

Jan. 3, 2000

Hi, folks. I'm putting together guidelines for submissions to the Software Carpentry design competition (www.software-carpentry.com), and would like to know what I should recommend as a Python GUI toolkit. As I understand it, the alternatives are: - Tkinter: the "standard" answer, but many people think it's showing its age, and it's an installation and update headaches because of its Tcl dependencies. - some other GUI toolkit: but there's no consensus on which one, and documentation … [View More]

1 0

Re: [Distutils] Questions about distutils strategy
by Guido van Rossum Jan. 2, 2000

Jan. 2, 2000

[Great analysis, Tim!] > 4) The audience is Python end-users "in general", and the product is pure > Python. I think this is the most important one for Distutils to address, > and compilation isn't a part of it. So far, though, what Gordon is doing > seems more appropriate than what Distutils has been up to. I hope his work > gets folded into this. I'm not sure what stuff by which Gordon you're referring to. I am only familiar with his installer, which I thought is win32 … [View More]

14 78