Mailman 3 June 1999 - Python-Dev

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 09 Jun '99

09 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