Mailman 3 June 1999 - Python-Dev

Re: [Python-Dev] ActiveState & fork & Perl
by Tim Peters 14 Jul '99

14 Jul '99

Moving back in time ... [GordonM] > Perhaps Christian's stackless Python would enable green threads... [Guido] > This has been suggested before... While this seems possible at first, > all blocking I/O calls would have to be redone to pass control to the > thread scheduler, before this would be useful -- a huge task! I didn't understand this. If I/O calls are left alone, and a green thread hit one, the whole program just sits there waiting for the call to complete, right? But if the same thing happens using "real threads" today, the same thing happens today anyway <wink>. That is, if a thread doesn't release the global lock before a blocking call today, the whole program just sits there etc. Or do you have some other kind of problem in mind here? unconvincedly y'rs - tim

11 42

ob_refcnt access
by Vladimir Marangozov 01 Jul '99

01 Jul '99

How about introducing internal macros for explicit ob_refcnt accesses in the core? Actually, there are a number of places where one can see "op->ob_refcnt" logic, which could be replaced with _Py_GETREF(op), _Py_SETREF(op, n) thus decoupling completely the low level refcount management defined in object.h: #define _Py_GETREF(op) (((PyObject *)op)->ob_refcnt) #define _Py_SETREF(op, n) (((PyObject *)op)->ob_refcnt = (n)) Comments? I've contributed myself to the mess in intobject.c & floatobject.c, so I thought that such macros would make the code cleaner. Here's the current state of affairs: python/dist/src>find . -name "*.[c]" -exec grep ob_refcnt {} \; -print (void *) v, ((PyObject *) v)->ob_refcnt)) ./Modules/_tkinter.c if (self->arg->ob_refcnt > 1) { \ if (ob->ob_refcnt < 2 || self->fast) if (args->ob_refcnt > 1) { ./Modules/cPickle.c if (--inst->ob_refcnt > 0) { ./Objects/classobject.c if (result->ob_refcnt == 1) ./Objects/fileobject.c if (PyFloat_Check(p) && p->ob_refcnt != 0) if (!PyFloat_Check(p) || p->ob_refcnt == 0) { if (PyFloat_Check(p) && p->ob_refcnt != 0) { p, p->ob_refcnt, buf); ./Objects/floatobject.c if (PyInt_Check(p) && p->ob_refcnt != 0) if (!PyInt_Check(p) || p->ob_refcnt == 0) { if (PyInt_Check(p) && p->ob_refcnt != 0) p, p->ob_refcnt, p->ob_ival); ./Objects/intobject.c assert(v->ob_refcnt == 1); /* Since v will be used as accumulator! */ ./Objects/longobject.c if (op->ob_refcnt <= 0) op->ob_refcnt, (long)op); op->ob_refcnt = 1; if (op->ob_refcnt < 0) fprintf(fp, "[%d] ", op->ob_refcnt); ./Objects/object.c if (!PyString_Check(v) || v->ob_refcnt != 1) { if (key->ob_refcnt == 2 && key == value) { ./Objects/stringobject.c if (!PyTuple_Check(op) || op->ob_refcnt != 1) { if (v == NULL || !PyTuple_Check(v) || v->ob_refcnt != 1) { ./Objects/tupleobject.c if (PyList_Check(seq) && seq->ob_refcnt == 1) { if (args->ob_refcnt > 1) { ./Python/bltinmodule.c if (value->ob_refcnt != 1) ./Python/import.c return PyInt_FromLong((long) arg->ob_refcnt); ./Python/sysmodule.c -- Vladimir MARANGOZOV | Vladimir.Marangozov(a)inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252

6 11

Is Python Free Software, free software, Open Source, open source, etc?
by Mark Hammond 30 Jun '99

30 Jun '99

This probably isnt the correct list, but I really dont want to start a philosophical discussion - hopefully people here are both "in the know" and able to resist a huge thread :-) Especially given the recent slashdot flamefest between RMS and ESR, I thought it worth getting correct. I just read a statement early in our book - "Python is an Open Source tool, ...". Is this "near enough"? Should I avoid this term in preference for something more generic (ie, even simply dropping the caps?) - but the OS(tm) idea seems doomed anyway... Just-hoping-to-avoid-flame-mail-from-rabid-devotees-of-either-religion :-) Mark.

5 5

Merge the string_methods tag?
by Mark Hammond 28 Jun '99

28 Jun '99

Ive been running the string_methods tag (term?) under CVS for quite some time now, and it seems to work perfectly. I admit that I havent stressed the string methods much, but I feel confident that Barry's patches havent broken existing string code. Also, I find using that tag with CVS a bit of a pain. A few updates have been checked into the main branch, and you tend to miss these (its a pity CVS can't be told "only these files are affected by this tag, so the rest should follow the main branch." I know I can do that personally, but that means I personally need to know all files possibly affected by the branch.) Anyway, I digress... I propose that these extensions be merged into the main branch. The main advantage is that we force more people to bash on it, rather than allowing them to make that choice <wink>. If the Unicode type is also considered highly experimental, we can make a new tag for that change, but that is really quite independant of the string methods. Mark.

6 10

Paul Prescod: add Expat to 1.6
by Andrew M. Kuchling 28 Jun '99

28 Jun '99

Paul Prescod sent the following note to the XML-SIG mailing list. Thoughts? --amk

4 4

RE: [Python-Dev] ob_refcnt access
by Sam Rushing 28 Jun '99

28 Jun '99

Mark Hammond writes: > I tried, and look what happened :-) Seriously, some if this stuff > would be way cool. > > Bit I also understand completely the silence on this issue. When > the thread started, there was much discussion about exactly what > the hell these continuation/coroutine thingies even were. However, > there were precious few real-world examples where they could be > used. A few acedemic, theoretical places, but the only real > contender I have seen brought up was Medusa. There were certainly > no clear examples of "as soon as we have this, I could change abc > to take advantage, and this would give us the very cool xyz" Part of the problem is that we didn't have the feature to play with. Many of the possibilities are showing up now that it's here... The basic advantage to coroutines is they allow you to turn any event-driven/state-machine problem into one that is managed with 'normal' control state; i.e., for loops, while loops, nested procedure calls, etc... Here are a few possible real-world uses: ================================================== Parsing. I remember a discussion from a few years back about the distinction between 'push' and 'pull' model parsers. Coroutines let you have it both ways; you can write a parser in the most natural way (pull), but use it as a 'push'; i.e. for a web browser. ================================================== "http sessions". A single 'thread' of control that is re-entered whenever a hit from a particular user ('session') comes in to the web server: [Apologies to those that have already seen this cheezy example] def ecommerce (session): session.login() # sends a login form, waits for it to return basket = [] while 1: item = session.shop_for_item() if item: basket.append (item) else: break if basket: session.get_shipping_info() session.get_payment_info() session.transact() 'session.shop_for_item()' will resume the main coroutine, which will resume this coroutine only when a new hit comes in from that session/user, and 'return' this hit to the while loop. I have a little web server that uses this idea to play blackjack: http://www.nightmare.com:7777/ http://www.nightmare.com/stuff/blackjack_httpd.py [though I'm a little fuzzy on the rules]. Rather than building a state machine that keeps track of where the user has been, and what they're doing, you can keep all the state in local variables (like 'basket' above) - in other words, it's a much more natural style of programming. ================================================== One of the areas I'm most excited about is GUI coding. All GUI's are event driven. All GUI code is therefore written in a really twisted, state-machine fashion; interactions are very complex. OO helps a bit, but doesn't change the basic difficulty - past a certain point interesting things become too complex to try... Mr. Fuchs' paper ("Escaping the event loop: an alternative control structure for multi-threaded GUIs") does a much better job of describing this than I can: http://cs.nyu.edu/phd_students/fuchs/ http://cs.nyu.edu/phd_students/fuchs/gui.ps ================================================== Tim's example of 'dumping' a computation in the middle and storing it on disk (or sending it over a network), is not a fantasy... I have a 'stackless' Scheme system that does this right now. ================================================== Ok, final example. Isn't there an interface in Python to call a certain function after every so many vm insns? Using coroutines you could hook into this and provide non-preemptive 'threads' for those platforms that don't have them. [And the whole thing would be written in Python, not in C!] ================================================== > So, if anyone else if feeling at all like me about this issue, they > are feeling all warm and fuzzy knowing that a few smart people are > giving us the facility to do something we hope we never, ever have > to do. :-) "When the only tool you have is a hammer, everything looks like a nail". I saw the guys over in the Scheme shop cutting wood with a power saw; now I feel like a schmuck with my hand saw. You are right to be frightened by the strangeness of the underlying machinery; hopefully a simple and easy-to-understand interface can be built for the C level as well as Python. I think Christian's 'frame dispatcher' is fairly clear, and not *that* much of a departure from the current VM; it's amazing to me how little work really had to be done! -Sam

2 1

Re: ob_refcnt access (fwd)
by Vladimir Marangozov 25 Jun '99

25 Jun '99

FYI, my second message on this issue didn't reach the list because of a stupid error of mine, so Guido and I exchanged two mails in private. His response to the msg below was that he thinks that tweaking the refcount scheme at this level wouldn't contribute much and that he doesn't intend to change anything on this until 2.0 which will be rewritten from scratch. Besides, if I want to satisfy my curiosity in hacking the refcounts I can do it with a small patch because I've already located the places where the ob_refcnt slot is accessed directly. ----- Forwarded message -----

2 1

Re: ob_refcnt access
by Vladimir Marangozov 24 Jun '99

24 Jun '99

marangoz wrote: > > > How about introducing internal macros for explicit ob_refcnt accesses > in the core? Actually, there are a number of places where one can see > "op->ob_refcnt" logic, which could be replaced with _Py_GETREF(op), > _Py_SETREF(op, n) thus decoupling completely the low level refcount > management defined in object.h: > > #define _Py_GETREF(op) (((PyObject *)op)->ob_refcnt) > #define _Py_SETREF(op, n) (((PyObject *)op)->ob_refcnt = (n)) > > Comments? Of course, the above should be (PyObject *)(op)->ob_refcnt. Also, I forgot to mention that if this detail doesn't hurt code aesthetics, one (I) could experiment more easily all sort of weird things with refcounting... I formulated the same wish for malloc & friends some time ago, that is, use everywhere in the core PyMem_MALLOC, PyMem_FREE etc, which would be defined for now as malloc, free, but nobody seems to be very excited about a smooth transition to other kinds of malloc. Hence, I reiterate this wish, 'cause switching to macros means preparing the code for the future, even if in the future it remains intact ;-). Defining these basic interfaces is clearly Guido's job :-) as he points out in his summary of the last Open Source summit, but nevertheless, I'm raising the issue to let him see what other people think about this and allow him to make decisions easier :-) -- Vladimir MARANGOZOV | Vladimir.Marangozov(a)inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252

1 0

Re: ob_refcnt access
by None 24 Jun '99

24 Jun '99

marangoz wrote: > > > How about introducing internal macros for explicit ob_refcnt accesses > in the core? Actually, there are a number of places where one can see > "op->ob_refcnt" logic, which could be replaced with _Py_GETREF(op), > _Py_SETREF(op, n) thus decoupling completely the low level refcount > management defined in object.h: > > #define _Py_GETREF(op) (((PyObject *)op)->ob_refcnt) > #define _Py_SETREF(op, n) (((PyObject *)op)->ob_refcnt = (n)) > > Comments? Of course, the above should be (PyObject *)(op)->ob_refcnt. Also, I forgot to mention that if this detail doesn't hurt code aesthetics, one (I) could experiment more easily all sort of weird things with refcounting... I formulated the same wish for malloc & friends some time ago, that is, use everywhere in the core PyMem_MALLOC, PyMem_FREE etc, which would be defined for now as malloc, free, but nobody seems to be very excited about a smooth transition to other kinds of malloc. Hence, I reiterate this wish, 'cause switching to macros means preparing the code for the future, even if in the future it remains intact ;-). Defining these basic interfaces is clearly Guido's job :-) as he points out in his summary of the last Open Source summit, but nevertheless, I'm raising the issue to let him see what other people think about this and allow him to make decisions easier :-) -- Vladimir MARANGOZOV | Vladimir.Marangozov(a)inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 ----- End of forwarded message ----- -- Vladimir MARANGOZOV | Vladimir.Marangozov(a)inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252

1 0

Re: ob_refcnt access
by None 24 Jun '99

24 Jun '99

marangoz wrote: > > > How about introducing internal macros for explicit ob_refcnt accesses > in the core? Actually, there are a number of places where one can see > "op->ob_refcnt" logic, which could be replaced with _Py_GETREF(op), > _Py_SETREF(op, n) thus decoupling completely the low level refcount > management defined in object.h: > > #define _Py_GETREF(op) (((PyObject *)op)->ob_refcnt) > #define _Py_SETREF(op, n) (((PyObject *)op)->ob_refcnt = (n)) > > Comments? Of course, the above should be (PyObject *)(op)->ob_refcnt. Also, I forgot to mention that if this detail doesn't hurt code aesthetics, one (I) could experiment more easily all sort of weird things with refcounting... I formulated the same wish for malloc & friends some time ago, that is, use everywhere in the core PyMem_MALLOC, PyMem_FREE etc, which would be defined for now as malloc, free, but nobody seems to be very excited about a smooth transition to other kinds of malloc. Hence, I reiterate this wish, 'cause switching to macros means preparing the code for the future, even if in the future it remains intact ;-). Defining these basic interfaces is clearly Guido's job :-) as he points out in his summary of the last Open Source summit, but nevertheless, I'm raising the issue to let him see what other people think about this and allow him to make decisions easier :-) -- Vladimir MARANGOZOV | Vladimir.Marangozov(a)inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 ----- End of forwarded message ----- -- Vladimir MARANGOZOV | Vladimir.Marangozov(a)inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252

1 0

Re: ob_refcnt access
by None 24 Jun '99

24 Jun '99

marangoz wrote: > > > How about introducing internal macros for explicit ob_refcnt accesses > in the core? Actually, there are a number of places where one can see > "op->ob_refcnt" logic, which could be replaced with _Py_GETREF(op), > _Py_SETREF(op, n) thus decoupling completely the low level refcount > management defined in object.h: > > #define _Py_GETREF(op) (((PyObject *)op)->ob_refcnt) > #define _Py_SETREF(op, n) (((PyObject *)op)->ob_refcnt = (n)) > > Comments? Of course, the above should be (PyObject *)(op)->ob_refcnt. Also, I forgot to mention that if this detail doesn't hurt code aesthetics, one (I) could experiment more easily all sort of weird things with refcounting... I formulated the same wish for malloc & friends some time ago, that is, use everywhere in the core PyMem_MALLOC, PyMem_FREE etc, which would be defined for now as malloc, free, but nobody seems to be very excited about a smooth transition to other kinds of malloc. Hence, I reiterate this wish, 'cause switching to macros means preparing the code for the future, even if in the future it remains intact ;-). Defining these basic interfaces is clearly Guido's job :-) as he points out in his summary of the last Open Source summit, but nevertheless, I'm raising the issue to let him see what other people think about this and allow him to make decisions easier :-) -- Vladimir MARANGOZOV | Vladimir.Marangozov(a)inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 ----- End of forwarded message ----- -- Vladimir MARANGOZOV | Vladimir.Marangozov(a)inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252

1 0

automatic wildcard expansion on Win32
by David Ascher 21 Jun '99

21 Jun '99

A python-help poster finally convinced me that there was a way to enable automatic wildcard expansion on win32. This is done by linking in "setargv.obj" along with all of the other MS libs. Quick testing shows that it works. Is this a feature we want to add? I can see both sides of that coin. --david PS: I saw a RISKS digest posting last week which had a horror story about wildcard expansion on some flavor of Windows. The person had two files with long filenames: verylongfile1.txt and verylongfile2.txt But Win32 stored them in 8.3 format, so they were stored as verylo~2.txt and verylo~1.txt (Yes, the 1 and 2 were swapped!). So when he did del *1.txt he removed the wrong file. Neat, eh? (This is actually relevant -- it's possible that setargv.obj and glob.glob could give different answers). --david

4 6

Relative package imports
by M.-A. Lemburg 21 Jun '99

21 Jun '99

Although David has already copy-posted a message regarding this issue to the list, I would like to restate the problem to get a discussion going (and then maybe take it to c.l.p for general flaming ;). The problem we have run into on starship is that some well-known packages have introduced naming conflicts leading to the unfortunate situation that they can't be all installed on the same default path: 1. Zope has a module named DateTime which also is the base name of the package mxDateTime. 2. Both Zope and PIL have a top-level module named ImageFile.py (different ones of course). Now the problem is how to resolve these issues. One possibility is turning Zope and PIL into proper packages altogether. To ease this transition, one would need a way to specify relative intra-package imports and a way to tell pickle where to look for modules/packages. The next problem we'd probably run into sooner or later is that there are quite a few useful top-level modules with generic names that will conflict with package names and other modules with the same name. I guess we'd need at least three things to overcome this situation once and for all ;-): 1. Provide a way to do relative imports, e.g. a single dot could be interpreted as "parent package": modA.py modD.py [A] modA.py modB.py [B] modC.py modD.py In modC.py: from modD import * (works as usual: import A.B.modD) from .modA import * (imports A.modA) from ..modA import * (import the top-level modA) 2. Establish a general vendor based naming scheme much like the one used in the Java world: from org.python.core import time,os,string from org.zope.core import * from com.lemburg import DateTime from com.pythonware import PIL 3. Add a way to prevent double imports of the same file. This is the mayor gripe I have with pickle currently, because intra- package imports often lead to package modules being imported twice leading to many strange problems (e.g. splitting class hierarchies, problems with isinstance() and issubclass(), etc.), e.g. from org.python.core import UserDict u = UserDict.UserDict() import UserDict v = UserDict.UserDict() Now u and v will point to two different classes: >>> u.__class__ <class org.python.core.UserDict.UserDict at 80d3b48> >>> v.__class__ <class UserDict.UserDict at 80aed18> 4. Add some kind of redirection or lookup hook to pickle et al. so that imports done during unpickling can be redirected to the correct (possibly renamed) package. -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 196 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

3 5

stackable ints [stupid idea (ignore) :v]
by Aaron Watters 19 Jun '99

19 Jun '99

While we're talking about stacks... I've always considered it a major shame that Python ints and floats and chars and stuff have anything to do with dynamic allocation, and I always suspected it might be a major speed performance boost if there was some way they could be manipulated without the need for dynamic memory management. One conceivable alternative approach would change the basic manipulation of objects so that instead of representing objects via pyobject pointers everywhere represent them using two "slots" in a structure for each object, one of which is a type descriptor pointer and the other being a (void *) which could contain the data directly for small objects such as ints, floats, chars. In this case, for example, integer addition would never require any memory management, as it shouldn't, I think, in a perfect world. IE instead of C-stack or static: Heap: (pyobject *) ------------> (refcount, typedescr, data ...) in general you get (typedescr repr* ----------------------> (refcount, data, ...) ) or for small objects like ints and floats and chars simply (typedescr, value) with no dereferencing or memory management required. My feeling is that common things like arithmetic and indexing lists of integers and stuff could be much faster under this approach since it reduces memory management overhead and fragmentation, dereferencing, etc... One bad thing, of course, is that this might be a drastic assault on the way existing code works... Unless I'm just not being creative enough with my thinking. Is this a good idea? If so, is there any way to add it to the interpreter without breaking extension modules and everything else? If Python 2.0 will break stuff anyway, would this be an good change to the internals? Curious... -- Aaron Watters ps: I suppose another gotcha is "when do you do increfs/decrefs?" because they no longer make sense for ints in this case... maybe add a flag to the type descriptor "increfable" and assume that the typedescriptors are always in the CPU cache (?). This would slow down increfs by a couple cycles... Would it be worth it? Only the benchmark knows... Another fix would be to put the refcount in the static side with no speed penalty (typedescr repr* ----------------------> data refcount ) but would that be wasteful of space?

4 9

Flat Python in Linux Weekly
by Christian Tismer 18 Jun '99

18 Jun '99

Howdy, Who would have thought this... Linux Weekly took notice. http://lwn.net/bigpage.phtml derangedly yours - 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

2 1

org.python.org
by David Ascher 17 Jun '99

17 Jun '99

Not all that revolutionary, but an interesting migration path. FWIW, I think the underlying issue is a real one. We're starting to have more and more conflicts, even among package names. (Of course the symlink solution doesn't work on Win32, but that's a detail =). --david ---------- Forwarded message ---------- Date: Thu, 17 Jun 1999 13:44:33 -0400 (EDT) From: Andy Dustman <adustman(a)comstar.net> To: Gordon McMillan <gmcm(a)hypernet.com> Cc: M.-A. Lemburg <mal(a)lemburg.com>, Crew List <crew(a)server.python.net> Subject: Re: [Crew] Wizards' Resolution to Zope/PIL/mxDateTime conflict? On Thu, 17 Jun 1999, Gordon McMillan wrote: > M.A.L. wrote: > > > Or maybe we should start the com.domain.mypackage thing ASAP. > > I know many are against this proposal (makes Python look Feudal? > Reminds people of the J language?), but I think it's the only thing > that makes sense. It does mean you have to do some ugly things to get > Pickle working properly. Actually, it can be done very easily. I just tried this, in fact: cd /usr/lib/python1.5 mkdir -p org/python (cd org/python; ln -s ../.. core) touch __init__.py org/__init__.py org/python/__init__.py >>> from org.python.core import rfc822 >>> import profile So this seems to make things nice and backwards compatible. My only concern was having __init__.py in /usr/lib/python1.5, but this doesn't seem to break anything. Of course, if you are using some trendy new atrocity like Windoze, this might not work. -- andy dustman | programmer/analyst | comstar communications corporation telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d _______________________________________________ Crew maillist - Crew(a)starship.python.net http://starship.python.net/mailman/listinfo/crew

2 1

RE: [Python-Dev] stackable ints [stupid idea (ignore) :v]
by Aaron Watters 17 Jun '99

17 Jun '99

> no-positive-suggestions-just-grousing-ly y'rs - tim On the contrary. I think this is definitively a bad idea. Retracted. A double negative is a positive. -- Aaron Watters === "Criticism serves the same purpose as pain. It's not pleasant but it suggests that something is wrong." -- Churchill (paraphrased from memory)

1 0

mmap
by David Ascher 16 Jun '99

16 Jun '99

Another topic: what are the chances of adding the mmap module to the core distribution? It's restricted to a smallish set of platforms (modern Unices and Win32, I think), but it's quite small, and would be a nice thing to have available in the core, IMHO. (btw, the buffer object needs more documentation) --david

7 14

String methods... finally
by Barry A. Warsaw 16 Jun '99

16 Jun '99

I've finally checked my string methods changes into the source tree, albeit on a CVS branch (see below). These changes are outgrowths of discussions we've had on the string-sig, with I think Greg Stein giving lots of very useful early feedback. I'll call these changes controversial (hence the branch) because Guido hasn't had much opportunity to play with them. Now that he -- and you -- can check them out, I'm sure I'll get lots more feedback! First, to check them out you need to switch to the string_methods CVS branch. On Un*x: cvs update -r string_methods You might want to do this in a separate tree because this will sticky tag your tree to this branch. If so, try cvs checkout -r string_methods python Here's a brief summary of the changes (as best I can restore the state -- its been a while since I actually made all these changes ;) Strings now have as methods most of the functions that were previously only in the string module. If you've played with JPython, you've already had this feature for a while. So you can do: Python 1.5.2+ (#1, Jun 10 1999, 18:22:14) [GCC 2.8.1] on sunos5 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> s = 'Hello There Devheads' >>> s.lower() 'hello there devheads' >>> s.upper() 'HELLO THERE DEVHEADS' >>> s.split() ['Hello', 'There', 'Devheads'] >>> 'hello'.upper() 'HELLO' that sort of thing. Some of the string module functions don't make sense as string methods, like join, and others never had a C implementation so weren't added, like center. Two new methods startswith and endswith act like their Java cousins. The string module has been rewritten to be completely (I hope) backwards compatible. No code should break, though they could be slower. Guido and I decided that was acceptable. What else? Some cleaning up of the internals based on Greg's suggestions. A couple of new C API additions. Builtin int(), long(), and float() have grown a few new features. I believe they are essentially interchangable with string.atoi(), string.atol(), and string.float() now. After you guys get to toast me (in either sense of the word) for a while and these changes settle down, I'll make a wider announcement. Enjoy, -Barry

11 80

Re: [Python-Dev] Re: [Python-Dev] Re: [Python-Dev] String methods... finally
by Jack Jansen 15 Jun '99

15 Jun '99

> The same should happen as for L"foo" + " " + L"bar". This is probably the most reasonable solution. Unfortunately it breaks Marks truly novel suggestion that 0.join(1, 2) becomes 102, but I guess we'll have to live with that:-) -- 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

RE: [Python-Dev] String methods... finally
by Ken Manheimer 14 Jun '99

14 Jun '99

> [Skip Montanaro] > > I see the following functions in string.py that could > > reasonably be methodized: > > > > ljust, rjust, center, expandtabs, capwords > > > > Also zfill. > > > > [Barry A. Warsaw] > > What do you think, are these important enough to add? I think expandtabs is worthwhile. Though i wouldn't say i use it frequently, when i do use it i'm thankful it's there - it's something i'm really glad to have precooked, since i'm generally not looking for the distraction when i do happen to need it... Ken klm(a)digicool.com

1 0

RE: [Python-Dev] stackable ints [stupid idea (ignore) :v]
by Aaron Watters 12 Jun '99

12 Jun '99

From: "Tim Peters" <tim_one(a)email.msn.com> >Jumping in to opine that mixing tag/type bits with native pointers is a >Really Bad Idea. Put the bits on the low end and word-addressed machines >are screwed. Put the bits on the high end and you've made severe >assumptions about how the platform parcels out address space. In any case >you're stuck with ugly macros everywhere. Agreed. Never ever mess with pointers. This mistake has been made over and over again by each new generation of computer hardware and software and it's still a mistake. I thought it would be good to be able to do the following loop with Numeric arrays for x in array1: array2[x] = array3[x] + array4[x] without any memory management being involved. Right now, I think the for loop has to continually dynamically allocate each new x and intermediate sum (and immediate deallocate them) and that makes the loop piteously slow. The idea replacing pyobject *'s with a struct [typedescr *, data *] was a space/time tradeoff to speed up operations like the above by eliminating any need for mallocs or other memory management.. I really can't say whether it'd be worth it or not without some sort of real testing. Just a thought. -- Aaron Watters

4 3

More flexible namespaces.
by Mark Hammond 12 Jun '99

12 Jun '99

Here is a bit of an idea that I first came up with some years ago. Guido's response at the time was "sounds reasonable as long as we dont slow the normal case down". To cut a long story short, I would like eval and exec to be capable of working with arbitrary mapping objects rather than only dictionaries. The general idea is that I can provide a class with mapping semantics, and pass this to exec/eval. This would give us 2 seriously cool features (that I want <wink>), should anyone decide to write code that enables them: * Case insensitive namespaces. This would be very cool for COM, and as far as I know would please the Alice people. May open up more embedding opportunities that are lost if people feel strongly about this issue. * Dynamic name lookups. At the moment, dynamic attribute lookups are simple, but dynamic name lookups are hard. If I execute code "print foo", foo _must_ pre-exist in the namespace. There is no reasonable way I can some up with so that I can fetch "foo" as it is requested (raising the NameError if necessary). This would also be very cool for some of the COM work - particularly Active Scripting. Of course, these would not be enabled by standard Python, but would allow people to create flexible execution environments that suit their purpose. Any comments on this? Is it a dumb idea? Anyone have a feel for how deep these changes would cut? Its not something I want to happen soon, but it does seem a reasonable mechanism that can provide very flexible solutions... Mark.

11 37

join()
by Guido van Rossum 12 Jun '99

12 Jun '99

Given the heat in this discussion, I'm not sure if I endorse *any* of the proposals so far any more... How would Java do this? A static function in the String class, probably. The Python equivalent is... A function in the string module. So maybe string.join() it remains. --Guido van Rossum (home page: http://www.python.org/~guido/)

6 6

Re: [Python-Dev] Aside: apply syntax
by Jack Jansen 11 Jun '99

11 Jun '99

> > > > class SubFoo(Foo): > > def __init__(self, *args, **kw): > > Foo(self, *args, **kw) > > ... Guido: > I like the idea, but it would mean a major reworking of the grammar > and the parser. Can I persuade you to keep this on ice until 2.0? What exactly would the semantics be? While I hate the apply() loops you have to jump through nowadays to get this behaviour I don't funny understand how this would work in general (as opposed to in this case). For instance, would Foo(self, 12, *args, **kw) be allowed? And Foo(self, *args, x=12, **kw) ? -- 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

2 1

Aside: apply syntax
by David Ascher 11 Jun '99

11 Jun '99

I've seen repeatedly on c.l.p a suggestion to modify the syntax & the core to allow * and ** in function calls, so that: class SubFoo(Foo): def __init__(self, *args, **kw): apply(Foo, (self, ) + args, kw) ... could be written class SubFoo(Foo): def __init__(self, *args, **kw): Foo(self, *args, **kw) ... I really like this notion, but before I poke around trying to see if it's doable, I'd like to get feedback on whether y'all think it's a good idea or not. And if someone else wants to do it, feel free -- I am of course swamped, and I won't get to it until after rich comparisons. FWIW, apply() is one of my least favorite builtins, aesthetically speaking. --david

2 3

Stackless Preview (was: Memory leak under Idle?)
by Christian Tismer 10 Jun '99

10 Jun '99

Tim Peters wrote: [see the main list on idle leaks] > if-pystone-works-ship-it-ly y'rs - tim Well, on request of uncle Timmy, I do it. Although it's very early. A preview of stackless Python can be found under ftp://ftp.pns.cc/pub/stackless_990606.zip Current status: The main interpreter is completely stackless. Just for fun, I've set max recursion depth to 30000, so just try it. PyStone does of course run. My measures were about 3-5 percent slower than with standard Python. I think this is quite fair. As a side effect, the exec_statement now behaves better than before, since exec <anything> without globals and locals should update the current environment, which worked only for exec "string". Most of the Run_<thing> functions are stackless as well. Almost all cases could be treated tail recursively. I have just begun to work on the builtins, and there is a very bloody, new-born stackless map, which seems to behave quite well. (It is just an hour old, so don't blame me if I didn't get al refcounts right). This is a first special case, since I *had* to build a tiny interpreter from the old map code. Still quite hacky, but not so bad. It creates its own frame and bails out whenever it needs to call the interpreter. If not, it stays in the loop. Since this one is so fresh, the old map is still there, and the new one has the name "map_nr". As a little bonus, map_nr now also shows up in a traceback. I've set the line no to the iteration count. Beware, this is just a proof of concept and will most probably change. Further plans: I will make the other builtins stackless as well (reduce, filter), also the simple tail-recursive ones which I didn't do now due to lack of time. I think I will *not* think of stackless imports. After loking into this for a while, I think this is rather hairy, and also not necessary. On extensions: There will be a coroutine extension in a few days. This is now nearly a no-brainer, since I did the stackless Python with exactly that in mind. This is the real fruit where I'm after, so please let me pick it :) Documentation: Besides the few new comments, there is nothing yet. Diff files: Sorry, there are no diffs but just the modified files. I had no time to do them now. All files stem from the official Python 1.5.2 release. You might wonder about the version: In order to support extension modules which rely on some special new features of frames, I decided to name this Python "1.5.42", since I believe it will be useful at least "four two" people. :-) I consider this an Alpha 1 version. fearing the feedback :-) ciao - 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

8 17

Re: [Python-Dev] Splitting up the PVM
by Jack Jansen 10 Jun '99

10 Jun '99

> Here's what I think we should do first (I've mentioned this before but > nobody cheered me on :-). Go, Guido, GO!!!! What I'd like in the split you propose is to see which of the items would be implementable in Python, and try to do the split in such a way that such a Python implementation isn't ruled out. Am I correct in guessing that after factoring out the components you mention the only things that aren't in a "replaceable component" are the builtin objects, and a little runtime glue (malloc and such)? -- 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

2 1

Re: [Python-Dev] licensing
by Sam Rushing 08 Jun '99

08 Jun '99

Guido van Rossum writes: > Greg Stein writes: > > For example, can I take the async modules and build a commercial > > product on them? Yes, my intent was that they go under the normal Python 'do what thou wilt' license. If I goofed in any way, please let me know! > As far as I know, yes. Sam Rushing promised me this when he gave > them to me for inclusion. (I've had a complaint that they aren't > the latest -- can someone confirm this?) Guilty as charged. I've been tweaking them a bit lately, for performance, but anyone can grab the very latest versions out of the medusa CVS repository: CVSROOT=:pserver:medusa@seattle.nightmare.com:/usr/local/cvsroot (the password is 'medusa') Or download one of the snapshots. BTW, those particular files have always had the Python copyright/license. -Sam

4 3

Re: [Python-Dev] ActiveState & fork & Perl
by Jack Jansen 08 Jun '99

08 Jun '99

> One possibility might be NSPR, the Netscape Portable Runtime, > which provides platform-independent threads and I/O on Mac, Win32, and > Unix. Perhaps a thread implementation could be written that sat on > top of NSPR, in addition to the existing pthreads implementation. > See http://www.mozilla.org/docs/refList/refNSPR/. NSPR looks rather promising! Does anyone has any experiences with it? What I'd also be interested in is experiences in how it interacts with the "real" I/O system, i.e. can you mix and match NSPR calls with normal os calls, or will that break things? The latter is important for Python, because there are lots of external libraries, and while some are user-built (image libraries, gdbm, etc) and could conceivably be converted to use NSPR others are not... -- 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

2 1

ActiveState & fork & Perl
by David Ascher 08 Jun '99

08 Jun '99

In case you haven't heard about it, ActiveState has recently signed a contract with Microsoft to do some work on Perl on win32. One interesting aspect of this for Python is the specific work being performed. From the FAQ on this joint effort, one gets, under "What is the scope of the work that is being done?": fork() This implementation of fork() will clone the running interpreter and create a new interpreter with its own thread, but running in the same process space. The goal is to achieve functional equivalence to fork() on UNIX systems without suffering the performance hit of the process creation overhead on Win32 platforms. Emulating fork() within a single process needs the ability to run multiple interpreters concurrently in separate threads. Perl version 5.005 has experimental support for this in the form of the PERL_OBJECT build option, but it has some shortcomings. PERL_OBJECT needs a C++ compiler, and currently only works on Windows. ActiveState will be working to provide support for revamped support for the PERL_OBJECT functionality that will run on every platform that Perl will build on, and will no longer require C++ to work. This means that other operating systems that lack fork() but have support for threads (such as VMS and MacOS) will benefit from this aspect of the work. Any guesses as to whether we could hijack this work if/when it is released as Open Source? --david

13 46

licensing
by Greg Stein 08 Jun '99

08 Jun '99

Speaking of licensing issues... I seem to have read somewhere that the two Medusa files are under a separate license. Although, reading the files now, it seems they are not. The issue that I'm really raising is that Python should ship with a single license that covers everything. Otherwise, it will become very complicated for somebody to figure out which pieces fall under what restrictions. Is there anything in the distribution that is different than the normal license? For example, can I take the async modules and build a commercial product on them? Cheers, -g -- Greg Stein, http://www.lyra.org/

3 2

Re: [Python-Dev] ActiveState & fork & Perl
by Fredrik Lundh 07 Jun '99

07 Jun '99

I wrote: > > Not a Mac programmer, but I recall that when Steve Jobs came back, > > they published a schedule that said threads would be available a > > couple releases down the road. Schedules only move one way, so I'd > > guess ActiveState is premature. > > http://www.computerworld.com/home/print.nsf/all/990531AAFA which was just my way of saying that "did he perhaps refer to OS X ?". or are they adding real threads to good old MacOS too? </F>

4 3