Musi-Cal... Concert Schedules: Folk Music, Country Music, Rock Music & more!

From skip@mojam.com (Skip Montanaro) Wed Apr 21 14:17:32 1999 From: skip@mojam.com (Skip Montanaro) (skip@mojam.com (Skip Montanaro)) Date: Wed, 21 Apr 1999 09:17:32 -0400 Subject: [Python-Dev] ZServer 1.0b1: spurious colon in HTTP response line Message-ID: <199904211317.JAA26167@cm-29-94-14.nycap.rr.com> (Also reported to the bug catcher.) I'm trying to migrate from ZopeHTTPServer to ZServer 1.0b1. I was seeing the ZServer headers turning up in pages generated by the process. When I viewed the page source of the generated HTML I saw: HTTP/1.0: 200 OK Server: Zope/experimental ZServer/1.1b1 Date: Wed, 21 Apr 1999 13:00:38 GMT X-Powered-By: Zope (www.zope.org), Python (www.python.org) Connection: close Content-Type: text/html Content-Length: 7802 Musi-Cal... Concert Schedules: Folk Music, Country Music, Rock Music & more! ... I run ZServer behind an Apache 1.3.3 running mod_proxy. Apparently Apache doesn't recognize the HTTP response when there is a colon following the version number and adds a simple set of headers itself. I guess web browsers either ignore that line or are more lenient in their parsing of the response. The following simple patch corrects the problem: diff -c2 HTTPResponse.py.~1~ HTTPResponse.py *** HTTPResponse.py.~1~ Tue Apr 13 15:21:12 1999 --- HTTPResponse.py Wed Apr 21 09:05:00 1999 *************** *** 146,150 **** # status header must come first. ! append("HTTP/%s: %s" % (self._http_version, status)) if headers.has_key('status'): del headers['status'] --- 146,150 ---- # status header must come first. ! append("HTTP/%s %s" % (self._http_version, status)) if headers.has_key('status'): del headers['status'] *************** Skip Montanaro | Mojam: "Uniting the World of Music" http://www.mojam.com/ skip@mojam.com | Musi-Cal: http://www.musi-cal.com/ 518-372-5583 From da@ski.org Wed Apr 21 19:47:56 1999 From: da@ski.org (David Ascher) Date: Wed, 21 Apr 1999 11:47:56 -0700 (Pacific Daylight Time) Subject: [Python-Dev] Notice of intent: rich comparisons Message-ID: Now that 1.5.2 is finalized, I'll be starting to prepare a patch for the rich comparisons. Guido, how do you envision python-dev working? Do you want to hand out a TODO list for 1.6? --david From guido@CNRI.Reston.VA.US Wed Apr 21 20:04:40 1999 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Wed, 21 Apr 1999 15:04:40 -0400 Subject: [Python-Dev] Notice of intent: rich comparisons In-Reply-To: Your message of "Wed, 21 Apr 1999 11:47:56 PDT." References: Message-ID: <199904211904.PAA14966@eric.cnri.reston.va.us> > Now that 1.5.2 is finalized, I'll be starting to prepare a patch for the > rich comparisons. Cool! > Guido, how do you envision python-dev working? I though we'd just crack Monty Python jokes while pretending to work :-) > Do you want to hand out a TODO list for 1.6? Well, I'm not saying that this is the definitive list, but certainly there are a bunch of things that definitely need to be incorporated. Here's an excerpt of a list that I keep for myself, in no particular order, with brief annotations (I have a meeting in 15 minutes :): Redesign thread/init APIs See the recent discussion in the thread-sig. There should be some kind of micro-init that initializes essential components (including the thread lock!) but doesn't create an interpreter or a threadstate object. There should also be a notion of a default interpreter. Break up into VM, parser, import, mainloop, and other components? The porting efforts to seriously small machines (Win/CE, Pilot, etc.) all seem to need a Python VM that doesn't automatically pull in the parser and interactive main loop. There are other reasons as well to isolate various parts of the functionality (including all numeric data types except ints). This could include: restructuring of the parser so codeop.py can be simplified; making the interactive main loop a script. String methods Barry has his patches ready. Unicode What is the status of /F's latest attempts? Rich comparisons This is Dave's plan. Coercions Marc-Andre Lemburg has some good suggestions here: http://starship.python.net/~lemburg/coercion-0.6.zip Import revamp It should be much easier to add hooks to allow importing from zip files, from a URL, etc., or (different) hooks to allow looking for different extensions (e.g. to automatically generate ILU stubs). This should help the small platforms too, since they often don't have a filesystem, so their imports will have to come from some other place. ANSI C I'm tired of supporting K&R C. All code should be converted to using prototypes. The Py_PROTO macros should go. We can add const-correctness to all code. Too bad for platforms without decent compilers (let them get GCC). Buffer object API extensions Marc-Andre Lemburg has a patch Distutil Should we start integrating some of the results of the distutil SIG? (What's the status? I haven't been paying attention.) Misc Jeremy Hylton's urllib2.py Greg Stein's new httplib.py (or Jeremy's?) Andrew Kuchling's new PCRE release? The IPv6 patches? Gotta run! --Guido van Rossum (home page: http://www.python.org/~guido/) From gward@cnri.reston.va.us Wed Apr 21 20:10:08 1999 From: gward@cnri.reston.va.us (Greg Ward) Date: Wed, 21 Apr 1999 15:10:08 -0400 Subject: [Python-Dev] Notice of intent: rich comparisons In-Reply-To: <199904211904.PAA14966@eric.cnri.reston.va.us>; from Guido van Rossum on Wed, Apr 21, 1999 at 03:04:40PM -0400 References: <199904211904.PAA14966@eric.cnri.reston.va.us> Message-ID: <19990421151008.D6167@cnri.reston.va.us> On 21 April 1999, Guido van Rossum said: > Distutil > > Should we start integrating some of the results of the > distutil SIG? (What's the status? I haven't been paying > attention.) It's in a state that other people can look at the code, but (apparently) not yet good enough for floods of patches to come in. Right now, Distutils has *just* enough marbles to "build" and install itself on Unix systems, and someone has contributed a patch so it works on NT. No support yet for compiling extensions, which of course is the important thing. Greg -- Greg Ward - software developer gward@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913 From da@ski.org Wed Apr 21 20:19:42 1999 From: da@ski.org (David Ascher) Date: Wed, 21 Apr 1999 12:19:42 -0700 (Pacific Daylight Time) Subject: [Python-Dev] Notice of intent: rich comparisons In-Reply-To: <199904211904.PAA14966@eric.cnri.reston.va.us> Message-ID: On Wed, 21 Apr 1999, Guido van Rossum wrote: > > Guido, how do you envision python-dev working? > > I though we'd just crack Monty Python jokes while pretending to work :-) That'd be better than what I've read on the perl5-porters list in the last couple of days (which I'm reading because of the ad hoopla). They seem to spend their time arguing about whether Perl codes are programs or scripts. Viciously, too. =) More seriously, some of the discussions they're having a worth keeping an eye on, just as a form of legal industrial spying. > Import revamp There was an interesting bit from Greg, Jack, and MarkH on this topic recently in the distutil-sig. Maybe one of them can bring the rest of us up to date on the effort. --david From fredrik@pythonware.com Wed Apr 21 21:04:54 1999 From: fredrik@pythonware.com (Fredrik Lundh) Date: Wed, 21 Apr 1999 22:04:54 +0200 Subject: [Python-Dev] Notice of intent: rich comparisons References: <199904211904.PAA14966@eric.cnri.reston.va.us> Message-ID: <092701be8c32$3a4ad9f0$f29b12c2@pythonware.com> Guido wrote: > String methods > > Barry has his patches ready. > > Unicode > > What is the status of /F's latest attempts? most of the code is written and tested; the API still needs some cleaning up. I also have a few patches and other contributions in my inbox that I gotta look into... btw, the unicode module can be compiled for 8-bit characters too. we could merge it with the string module (one place to fix bugs...) > Import revamp > > It should be much easier to add hooks to allow importing > from zip files, from a URL, etc., or (different) hooks to > allow looking for different extensions (e.g. to automatically > generate ILU stubs). This should help the small platforms > too, since they often don't have a filesystem, so their > imports will have to come from some other place. something similar to greg's imputil.py should definitely be in the core... > ANSI C > > I'm tired of supporting K&R C. All code should be converted > to using prototypes. The Py_PROTO macros should go. We can > add const-correctness to all code. Too bad for platforms > without decent compilers (let them get GCC). or ansi2knr.c (available from http://www.cs.wisc.edu/~ghost/). otoh, it only converts function headers, so I'm not sure it's worth the effort... From beazley@cs.uchicago.edu Wed Apr 21 21:06:50 1999 From: beazley@cs.uchicago.edu (David Beazley) Date: Wed, 21 Apr 1999 15:06:50 -0500 (CDT) Subject: [Python-Dev] Notice of intent: rich comparisons References: <199904211904.PAA14966@eric.cnri.reston.va.us> Message-ID: <199904212006.PAA17138@tartarus.cs.uchicago.edu> Guido van Rossum writes: > > ANSI C > > I'm tired of supporting K&R C. All code should be converted > to using prototypes. The Py_PROTO macros should go. We can > add const-correctness to all code. Too bad for platforms > without decent compilers (let them get GCC). > Maybe I'm just lucky, but I've written nothing but ANSI C for the last 8 years and have never had a problem compiling it on any machine. I don't see this as being a huge issue. > > Misc > Depending on how deep I want to dig, I may have some patches to ParseTuple() that would make life easier for some of us extension writing fans. As it is right now, my experimental version of Swig is using it's own version of ParseTuple (for various reasons). Also, out of curiousity, is anyone making heavy use of the CObject type right now? Cheers, Dave From jim@digicool.com Wed Apr 21 22:15:24 1999 From: jim@digicool.com (Jim Fulton) Date: Wed, 21 Apr 1999 17:15:24 -0400 Subject: [Python-Dev] Notice of intent: rich comparisons References: <199904211904.PAA14966@eric.cnri.reston.va.us> <199904212006.PAA17138@tartarus.cs.uchicago.edu> Message-ID: <371E3FEC.9D19607A@digicool.com> David Beazley wrote: > > Guido van Rossum writes: > > > > ANSI C > > > > I'm tired of supporting K&R C. All code should be converted > > to using prototypes. The Py_PROTO macros should go. We can > > add const-correctness to all code. Too bad for platforms > > without decent compilers (let them get GCC). > > > > Maybe I'm just lucky, but I've written nothing but ANSI C for the last > 8 years and have never had a problem compiling it on any machine. I > don't see this as being a huge issue. I've had the same experience with things like prototypes. The recent introduction of indented preprocessor instructions caused me significant pain on some platforms. Fortunately, I haven't had to deal with those platforms recently, still, the elegence of indented preporicessor instructions wasn't worth the pain it caused. As far as choice of compilers goes, sometimes gcc isn't an option. I've had cases where I *had* to use the native compiler in order to link to third-party libraries. I support moving to ANSI C, for example, wrt prototypes, but lets still be somewhat sensative to portability and not abuse bad compilers without good reason. > > > > > Misc > > > > Depending on how deep I want to dig, I may have some patches to > ParseTuple() that would make life easier for some of us extension > writing fans. As it is right now, my experimental version of Swig > is using it's own version of ParseTuple (for various reasons). > Also, out of curiousity, is anyone making heavy use of the CObject > type right now? Yes. Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats. From jeremy@cnri.reston.va.us Wed Apr 21 22:23:57 1999 From: jeremy@cnri.reston.va.us (Jeremy Hylton) Date: Wed, 21 Apr 1999 17:23:57 -0400 (EDT) Subject: [Python-Dev] Notice of intent: rich comparisons In-Reply-To: <199904212006.PAA17138@tartarus.cs.uchicago.edu> References: <199904211904.PAA14966@eric.cnri.reston.va.us> <199904212006.PAA17138@tartarus.cs.uchicago.edu> Message-ID: <14110.16787.893181.642806@bitdiddle.cnri.reston.va.us> >>>>> "DB" == David Beazley writes: DB> various reasons). Also, out of curiousity, is anyone making DB> heavy use of the CObject type right now? I used it a little, but only in a modified Python backend for SWIG. Jeremy From mal@lemburg.com Wed Apr 21 22:46:46 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 21 Apr 1999 23:46:46 +0200 Subject: [Python-Dev] Notice of intent: rich comparisons References: <199904211904.PAA14966@eric.cnri.reston.va.us> Message-ID: <371E4746.22A84506@lemburg.com> Guido van Rossum wrote: > > Break up into VM, parser, import, mainloop, and other components? > > The porting efforts to seriously small machines (Win/CE, > Pilot, etc.) all seem to need a Python VM that doesn't > automatically pull in the parser and interactive main loop. > There are other reasons as well to isolate various parts > of the functionality (including all numeric data types except > ints). > > This could include: restructuring of the parser so codeop.py > can be simplified; making the interactive main loop a script. There's some good work out there by Skip Montanaro to revamp the VM into a combined register/stack machine. He calls it rattlesnake. More infos can be found in the list archive (it's currently sleeping): http://www.egroups.com/folders/rattlesnake I would like to see the VM/compiler pluggable so that experiments like rattlesnake become easier to implement (extension modules vs. patches to the core interpreter). > Coercions > > Marc-Andre Lemburg has some good suggestions here: > http://starship.python.net/~lemburg/coercion-0.6.zip I will continue to work on these patches now that 1.5.2 is out. There is a (more or less) detailed explanation of the patch set at: http://starship.skyport.net/~lemburg/CoercionProposal.html Instead of using of using the PY_NEWSTYLENUMBER approach I'll turn to the new type flags that were introduced in 1.5.2. The Py_NotImplemented singleton return value will stay, because performance tests have shown that this method does not cause any significant hit where as the exception raise and catch method does introduce a significant slow-down. > Import revamp Greg's imputil.py (it's in the distutils package) should provide a good start. > Buffer object API extensions I'll put the complete patch up on starship later this week... here are the basic prototypes: DL_IMPORT(int) PyObject_AsCharBuffer Py_PROTO((PyObject *obj, const char **buffer, int *buffer_len)); /* Takes an arbitrary object which must support the (character, single segment) buffer interface and returns a pointer to a read-only memory location useable as character based input for subsequent processing. buffer and buffer_len are only set in case no error occurrs. Otherwise, -1 is returned and an exception set. */ DL_IMPORT(int) PyObject_AsReadBuffer Py_PROTO((PyObject *obj, const void **buffer, int *buffer_len)); /* Same as PyObject_AsCharBuffer() except that this API expects (readable, single segment) buffer interface and returns a pointer to a read-only memory location which can contain arbitrary data. buffer and buffer_len are only set in case no error occurrs. Otherwise, -1 is returned and an exception set. */ DL_IMPORT(int) PyObject_AsWriteBuffer Py_PROTO((PyObject *obj, void **buffer, int *buffer_len)); /* Takes an arbitrary object which must support the (writeable, single segment) buffer interface and returns a pointer to a writeable memory location in buffer of size buffer_len. buffer and buffer_len are only set in case no error occurrs. Otherwise, -1 is returned and an exception set. */ > Distutil > > Should we start integrating some of the results of the > distutil SIG? (What's the status? I haven't been paying > attention.) With all the different modules and packages available for Python starting to slowly introduce dependencies, I think the main objective should be introducing a well organized installation info system, e.g. a registry where modules and packages can query and save version and dependency information. Someone on the main list mentioned that JPython has something like this... > Misc > > Jeremy Hylton's urllib2.py > > Greg Stein's new httplib.py (or Jeremy's?) > > Andrew Kuchling's new PCRE release? > > The IPv6 patches? These are on my wish list, so I'll simply add them here: � APIs to faciliate creation of extensions classes (using Python classes and C functions as methods) The main open question here is where and how to store C data in the instances. This could also provide a way to migrate to all Python classes for some future version. � Restructure the calling mechanism used in ceval.c to make it clearer, more flexible and faster (of course, :-). Also, inline calling of C functions/methods (this produces a noticable speedup). I have a patch for the restructuring and an old one (against 1.5) for the C function call inlining. � A "fastpath" hook made available through the sys module. This should hook into the module/package loader and should be used whenever set to find a module (reverting to the standard lookup method in case it can't find it). I have an old patch that does this. It uses a simple Python function to redirect the lookup to a precalculated dictionary of installed modules/packages. This results in faster startup of the Python interpreter (by saving a few hundred stat() calls). -- Marc-Andre Lemburg Y2000: 254 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From mal@lemburg.com Wed Apr 21 22:51:11 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 21 Apr 1999 23:51:11 +0200 Subject: [Python-Dev] Notice of intent: rich comparisons References: <199904211904.PAA14966@eric.cnri.reston.va.us> <199904212006.PAA17138@tartarus.cs.uchicago.edu> Message-ID: <371E484F.22046FE9@lemburg.com> David Beazley wrote: > > > > > Misc > > > > Depending on how deep I want to dig, I may have some patches to > ParseTuple() that would make life easier for some of us extension > writing fans. As it is right now, my experimental version of Swig > is using it's own version of ParseTuple (for various reasons). > Also, out of curiousity, is anyone making heavy use of the CObject > type right now? You mean the one in Objects/cobject.c ? Sure, all my type extensions export their C API that way... and it works just great (no more linker problems, nice error messages when extensions are not found, etc.). -- Marc-Andre Lemburg Y2000: 254 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From da@ski.org Wed Apr 21 22:56:17 1999 From: da@ski.org (David Ascher) Date: Wed, 21 Apr 1999 14:56:17 -0700 (Pacific Daylight Time) Subject: [Python-Dev] Notice of intent: rich comparisons In-Reply-To: <371E484F.22046FE9@lemburg.com> Message-ID: David Beazley wrote: > Also, out of curiousity, is anyone making heavy use of the CObject > type right now? NumPy does. --da From MHammond@skippinet.com.au Thu Apr 22 00:45:19 1999 From: MHammond@skippinet.com.au (Mark Hammond) Date: Thu, 22 Apr 1999 09:45:19 +1000 Subject: [Python-Dev] Notice of intent: rich comparisons In-Reply-To: <092701be8c32$3a4ad9f0$f29b12c2@pythonware.com> Message-ID: <004c01be8c51$043f27c0$0801a8c0@bobcat> [Guido and /F] > > Unicode > > > > What is the status of /F's latest attempts? > > most of the code is written and tested; the API still > needs some cleaning up. I also have a few patches > and other contributions in my inbox that I gotta > look into... Im one of those contributors :-) I have made changes to the Win32 extensions that allows it to use /F's type instead of its own built-in Unicode type. Further, the Windows CE port of these extensions actually enables this - so we have some code actively using it. However, this still doesnt give me anything more than I had before. We need at least _some_ level of integration of this type into Python. The key areas to me are: * PyArg_ParseTuple and Py_BuildValue - Seems OK we use the "u" format character analogous to "s". We havent thought of a "z" equivilent. This is fairly easy. * Some way for these functions to auto-convert. Eg, when the user passes an 8bit string object, but the C side of the world wants a Unicode string. This is harder, as an extra memory buffer for the conversion is needed. This second problem is, to me, the next stumbling block. When we sort these out, I feel we would have the start of a good platform to start experimenting. Mark. From Fred L. Drake, Jr." Message-ID: <14111.13959.211874.750734@weyr.cnri.reston.va.us> David Beazley writes: > Maybe I'm just lucky, but I've written nothing but ANSI C for the last > 8 years and have never had a problem compiling it on any machine. I > don't see this as being a huge issue. Wasn't SunOS 4.x the problem child here? There are still a lot of people using these systems, for reasons that aren't clear to me. (Did support for some older hardware get dropped? Sounds like the most reasonable reason to use the old OS is legacy hardware.) -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Thu Apr 22 16:37:46 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Thu, 22 Apr 1999 11:37:46 -0400 (EDT) Subject: [Python-Dev] Notice of intent: rich comparisons References: <16290078@toto.iv> <14111.13959.211874.750734@weyr.cnri.reston.va.us> Message-ID: <14111.16970.839894.147748@anthem.cnri.reston.va.us> >>>>> "Fred" == Fred L Drake writes: Fred> Wasn't SunOS 4.x the problem child here? There are still Fred> a lot of people using these systems, for reasons that aren't Fred> clear to me. (Did support for some older hardware get Fred> dropped? Sounds like the most reasonable reason to use the Fred> old OS is legacy hardware.) There might be, but the bundled compiler in SunOS 4 was never intended to be used for anything more than recompiling the kernel. Years ago, I had conversations with Sun engineers who claimed that no bug in the bundled compiler was ever fixed unless it directly impacted on kernel rebuilds. Even back then they recommended using something other than the bundled crufty old K&R compiler for building all other stuff, and this was when there was that huge hoopla over the unbundling of the compiler. SunOS 4 users can probably be mostly satisfied with gcc. -Barry From Fred L. Drake, Jr." References: <16290078@toto.iv> <14111.13959.211874.750734@weyr.cnri.reston.va.us> <14111.16970.839894.147748@anthem.cnri.reston.va.us> Message-ID: <14111.17281.999490.718527@weyr.cnri.reston.va.us> Barry A. Warsaw writes: > There might be, but the bundled compiler in SunOS 4 was never intended > to be used for anything more than recompiling the kernel. Years ago, ... > SunOS 4 users can probably be mostly satisfied with gcc. Barry, This is good enough for me. I'd certainly rather avoid K&R C! -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From skip@mojam.com (Skip Montanaro) Thu Apr 22 18:18:39 1999 From: skip@mojam.com (Skip Montanaro) (skip@mojam.com (Skip Montanaro)) Date: Thu, 22 Apr 1999 13:18:39 -0400 (EDT) Subject: [Python-Dev] Notice of intent: rich comparisons In-Reply-To: <14111.17281.999490.718527@weyr.cnri.reston.va.us> References: <16290078@toto.iv> <14111.13959.211874.750734@weyr.cnri.reston.va.us> <14111.16970.839894.147748@anthem.cnri.reston.va.us> <14111.17281.999490.718527@weyr.cnri.reston.va.us> Message-ID: <14111.22873.161727.15206@cm-29-94-14.nycap.rr.com> Barry> SunOS 4 users can probably be mostly satisfied with gcc. Fred> This is good enough for me. I'd certainly rather avoid K&R C! Besides, aren't there tools available that can strip most of the ANSI-ness out of ANSI C? (Un)Protoize? For those (few?) people who are really still stuck using a K&R compiler I would think those tools, perhaps supplemented with some patch files maintained outside the main Python source tree, would be sufficient. Skip Montanaro | Mojam: "Uniting the World of Music" http://www.mojam.com/ skip@mojam.com | Musi-Cal: http://www.musi-cal.com/ 518-372-5583 From bwarsaw@python.org Thu Apr 22 19:07:57 1999 From: bwarsaw@python.org (Barry A. Warsaw) Date: Thu, 22 Apr 1999 14:07:57 -0400 (EDT) Subject: [Python-Dev] Notice of intent: rich comparisons References: <16290078@toto.iv> <14111.13959.211874.750734@weyr.cnri.reston.va.us> <14111.16970.839894.147748@anthem.cnri.reston.va.us> <14111.17281.999490.718527@weyr.cnri.reston.va.us> <14111.22873.161727.15206@cm-29-94-14.nycap.rr.com> Message-ID: <14111.25981.74738.355264@anthem.cnri.reston.va.us> >>>>> "skip" == writes: skip> Besides, aren't there tools available that can strip most of skip> the ANSI-ness out of ANSI C? (Un)Protoize? I think so. Seems I have unprotoize already; probably got it for free with gcc, or some other GNU tool. -B From skip@mojam.com (Skip Montanaro) Thu Apr 22 19:22:51 1999 From: skip@mojam.com (Skip Montanaro) (skip@mojam.com (Skip Montanaro)) Date: Thu, 22 Apr 1999 14:22:51 -0400 (EDT) Subject: [Python-Dev] Notice of intent: rich comparisons In-Reply-To: <371E4746.22A84506@lemburg.com> References: <199904211904.PAA14966@eric.cnri.reston.va.us> <371E4746.22A84506@lemburg.com> Message-ID: <14111.23085.737365.582406@cm-29-94-14.nycap.rr.com> mal> There's some good work out there by Skip Montanaro to revamp the VM mal> into a combined register/stack machine. He calls it rattlesnake. mal> More infos can be found in the list archive (it's currently mal> sleeping): Thanks to Marc-Andre for mentioning this. Rattlesnake is indeed sleeping at the moment. If anyone is interested in the idea I'd be happy to awaken it. The main observation was that much of the virtual machine's activity is pushing/popping objects to/from the stack. By treating a chunk of storage as a register file much of that churn can be avoided. Skip Montanaro | Mojam: "Uniting the World of Music" http://www.mojam.com/ skip@mojam.com | Musi-Cal: http://www.musi-cal.com/ 518-372-5583 From fredrik@pythonware.com Fri Apr 23 08:48:14 1999 From: fredrik@pythonware.com (Fredrik Lundh) Date: Fri, 23 Apr 1999 09:48:14 +0200 Subject: [Python-Dev] Compiling ANSI C on K&R compilers References: <16290078@toto.iv><14111.13959.211874.750734@weyr.cnri.reston.va.us><14111.16970.839894.147748@anthem.cnri.reston.va.us><14111.17281.999490.718527@weyr.cnri.reston.va.us> <14111.22873.161727.15206@cm-29-94-14.nycap.rr.com> Message-ID: <00df01be8d5d$a82b2f70$f29b12c2@pythonware.com> > Besides, aren't there tools available that can strip most of the ANSI-ness > out of ANSI C? (Un)Protoize? For those (few?) people who are really still > stuck using a K&R compiler I would think those tools, perhaps supplemented > with some patch files maintained outside the main Python source tree, would > be sufficient. I mentioned ansi2knr.c in an earlier post. It's a small utility, and can be distributed with the Python core (it's GPL'd, but since it isn't linked with Python, that's not a problem). this is used by ghostscript and the ijg jpeg library, among others: ftp://ftp.cs.wisc.edu/ghost/ansi2knr.c (or via http://www.cs.wisc.edu/~ghost/) Cheers /F fredrik@pythonware.com http://www.pythonware.com From gstein@lyra.org Fri Apr 23 11:37:02 1999 From: gstein@lyra.org (Greg Stein) Date: Fri, 23 Apr 1999 03:37:02 -0700 Subject: [Python-Dev] Notice of intent: rich comparisons References: <199904211904.PAA14966@eric.cnri.reston.va.us> Message-ID: <37204D4E.2C02ABE2@lyra.org> Guido van Rossum wrote: >... > Import revamp > > It should be much easier to add hooks to allow importing > from zip files, from a URL, etc., or (different) hooks to > allow looking for different extensions (e.g. to automatically > generate ILU stubs). This should help the small platforms > too, since they often don't have a filesystem, so their > imports will have to come from some other place. I would recommend that Python's import mechanism be changed to use some of the concepts from my imputil.py module and in a couple of my posts to distutils-sig: http://www.python.org/pipermail/distutils-sig/1999-January/000142.html http://www.python.org/pipermail/distutils-sig/1998-December/000077.html > ANSI C > > I'm tired of supporting K&R C. All code should be converted > to using prototypes. The Py_PROTO macros should go. We can > add const-correctness to all code. Too bad for platforms > without decent compilers (let them get GCC). Or those platforms can stick with Python 1.5.2 > Misc > > Jeremy Hylton's urllib2.py > > Greg Stein's new httplib.py (or Jeremy's?) Mine is a drop-in replacement for the current httplib.py. httplib.HTTP is compatible with the current version and does HTTP/1.0. httplib.HTTPConnection is similar to the other (but (IMO) cleans up a few elements of the API); it does HTTP/1.1, including persistent connections. This module follows the design of the original httplib.py much more closely. Jeremy's module uses a very different design approach (no value judgement here; it's just different); also, it simply copies over the old HTTP class, while mine derives the compatible version from HTTPConnection. I'm not sure how much testing Jeremy's has had, but I use my module for all Python-based http work now. Some number of other people have downloaded and used it, too. I would recommend my new module, given the two options. I'll eventually have a davlib.py to add to the distribution, but it needs more work. I'll contribute that later. --- I'd also like to see some cleanup of the build process. For example, (Guido:) I sent in a different way to handle the signal stuff (shifting files around and stuff) as opposed to the "hassignal" thing. About the build process: it may be nice to move to a single makefile. Here is an interesting paper about this: http://www.canb.auug.org.au/~millerp/rmch/recu-make-cons-harm.html Is it reasonable to split out the Demo, Doc, Misc, and Tools subdirs since those never really end up as part of an installed Python? e.g. into a python-extras distribution? (which would allow doc and tools updates at arbitrary times) Does it make sense to remove platform-specific modules? (e.g. the SGI modules) While distutils doesn't have anything *yet*, there are changes that can be made in the build process to improve the distutils process. I know that Greg Ward wants distutils to work on previous versions of Python, but (IMO) things would be simpler all around if distutils-based packages were simply designed for 1.6 systems as a basic dependency. However, that choice is quite separate from the decision to generate distutils support during the build. Oh: there were some things floating around at one point about using Python itself within the build process (e.g. for modules). Is any of that work useful? Cheers, -g -- Greg Stein, http://www.lyra.org/ From Fred L. Drake, Jr." References: <199904211904.PAA14966@eric.cnri.reston.va.us> <37204D4E.2C02ABE2@lyra.org> Message-ID: <14112.30060.552422.975547@weyr.cnri.reston.va.us> Greg Stein writes: > Is it reasonable to split out the Demo, Doc, Misc, and Tools subdirs > since those never really end up as part of an installed Python? e.g. > into a python-extras distribution? (which would allow doc and tools > updates at arbitrary times) The Doc/ stuff is already in a separate distribution; this has been in place for about a year (if I recall correctly). I try to make doc releases shortly after Python releases (I think the 1.5.2 doc release is the longest I've waited past the Python release so far, and it may end up being next week), and I have made interim releases as the documentation has grown. I certainly think that doing something similar for the Demo/ and Tools/ directories would be reasonable; they could share a single distribution. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From skip@mojam.com (Skip Montanaro) Fri Apr 23 14:59:02 1999 From: skip@mojam.com (Skip Montanaro) (skip@mojam.com (Skip Montanaro)) Date: Fri, 23 Apr 1999 09:59:02 -0400 (EDT) Subject: [Python-Dev] Notice of intent: rich comparisons In-Reply-To: <14112.30060.552422.975547@weyr.cnri.reston.va.us> References: <199904211904.PAA14966@eric.cnri.reston.va.us> <37204D4E.2C02ABE2@lyra.org> <14112.30060.552422.975547@weyr.cnri.reston.va.us> Message-ID: <14112.31858.374462.469793@cm-29-94-14.nycap.rr.com> Fred> I certainly think that doing something similar for the Demo/ and Fred> Tools/ directories would be reasonable; they could share a single Fred> distribution. We need to make sure none of the tools are needed in the install process. h2py comes to mind. Skip Montanaro | Mojam: "Uniting the World of Music" http://www.mojam.com/ skip@mojam.com | Musi-Cal: http://www.musi-cal.com/ 518-372-5583 From jeremy@cnri.reston.va.us Mon Apr 26 16:26:28 1999 From: jeremy@cnri.reston.va.us (Jeremy Hylton) Date: Mon, 26 Apr 1999 11:26:28 -0400 (EDT) Subject: [Python-Dev] Notice of intent: rich comparisons In-Reply-To: <37204D4E.2C02ABE2@lyra.org> References: <199904211904.PAA14966@eric.cnri.reston.va.us> <37204D4E.2C02ABE2@lyra.org> Message-ID: <14116.33341.371508.53071@bitdiddle.cnri.reston.va.us> >>>>> "GS" == Greg Stein writes: >> Greg Stein's new httplib.py (or Jeremy's?) GS> Mine is a drop-in replacement for the current GS> httplib.py. httplib.HTTP is compatible with the current version GS> and does HTTP/1.0. httplib.HTTPConnection is similar to the GS> other (but (IMO) cleans up a few elements of the API); it does GS> HTTP/1.1, including persistent connections. This module follows GS> the design of the original httplib.py much more GS> closely. Jeremy's module uses a very different design approach GS> (no value judgement here; it's just different); also, it simply GS> copies over the old HTTP class, while mine derives the GS> compatible version from HTTPConnection. I'm not sure how much GS> testing Jeremy's has had, but I use my module for all GS> Python-based http work now. Some number of other people have GS> downloaded and used it, too. GS> I would recommend my new module, given the two options. I think I agree. I stopped working on my version quite some time ago, before I made enough progress to make it useful. Thus, it makes a lot of sense to use Greg's working code. I'd be curious to see how to use HTTPConnection to do persistent connections and pipelined requests. It wasn't entirely clear from the code what I would need to do to keep the connection open. Do you just re-use the HTTPConnection object -- call putrequest again after getreply? I like the revised API that Greg's code uses. The request method on HTTPConnection objects cleans the API up in exactly the right way. It has always seemed unnecessary to have many separate calls to add headers and then a call to endheaders after putrequest. Packaging them all together in one method will simplify client code a lot. GS> I'll eventually have a davlib.py to add to the distribution, but GS> it needs more work. I'll contribute that later. Cool! Jeremy From guido@CNRI.Reston.VA.US Mon Apr 26 17:16:11 1999 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Mon, 26 Apr 1999 12:16:11 -0400 Subject: [Python-Dev] Public or private python-dev archives? Message-ID: <199904261616.MAA22036@eric.cnri.reston.va.us> In a private mail, Greg Stein suggested that the python-dev archives should be restricted to the members of the list. I prefer to make them public, but I won't want to impose this on others without discussion. So I've made the archives private for the time being while we discuss this meta-issue. (Also, the existence of the list isn't announced by mailman on its listinfo page.) Here's my argument for open archives. I don't think that we have anything to hide from the public -- I think of us as a technical forum whose discussions may affect others (e.g. Python users) and I think it's often useful for those others to be able to see what we've said. I want to keep membership of the list closed as a gentle way to enforce focus and quality of discussion. Jeremy pointed out that there's no restiction on posting, and mentioned that together with open archives this makes the list just as open as an open-subscription list. I don't see this equivalence -- certainly it makes a difference in practice, and the open posting is simply a mechanism to allow members with multiple email addresses to post from whereever they are. If we regularly get spammed or find the list is targeted by angry Python users we might have to restrict posting to members (and deal with the multiple address problem). I hope the discussion about this issue will be short (otherwise it would detract from the real goal of this list). I'll follow the desire of the majority of current members; once we have a decision I propose to stick with it and simply present new members with the facts. --Guido van Rossum (home page: http://www.python.org/~guido/) From gward@cnri.reston.va.us Mon Apr 26 17:30:43 1999 From: gward@cnri.reston.va.us (Greg Ward) Date: Mon, 26 Apr 1999 12:30:43 -0400 Subject: [Python-Dev] Public or private python-dev archives? In-Reply-To: <199904261616.MAA22036@eric.cnri.reston.va.us>; from Guido van Rossum on Mon, Apr 26, 1999 at 12:16:11PM -0400 References: <199904261616.MAA22036@eric.cnri.reston.va.us> Message-ID: <19990426123042.A2617@cnri.reston.va.us> On 26 April 1999, Guido van Rossum said: > In a private mail, Greg Stein suggested that the python-dev archives > should be restricted to the members of the list. I prefer to make > them public, but I won't want to impose this on others without > discussion. So I've made the archives private for the time being > while we discuss this meta-issue. (Also, the existence of the list > isn't announced by mailman on its listinfo page.) > > Here's my argument for open archives. I don't think that we have > anything to hide from the public -- I think of us as a technical forum > whose discussions may affect others (e.g. Python users) and I think > it's often useful for those others to be able to see what we've said. I favour as much openness as possible that's consistent with high signal-to-noise. Opening the archives doesn't affect SN ratio; for that matter, neither does allowing anyone to *read* the list while keeping posting privileges restricted. And letting the world know that the list exists -- even though posting privileges are restricted -- shouldn't affect quality. So I guess my position is: definitely open the archives and publicise the list -- the benefit of an open archive is reduced if people can't stumble across it like they can any sig. And consider the possibility of open subscription while keeping posting restricted. Not sure how easy that is with Mailman, but we can still consider the idea. The open, friendly nature of the Python community is a huge strength. I tentatively agree that posting privileges should be restricted to keep quality high, but the idea of a "secret cabal" discussing Python development off in a dark corner away from the grubby masses seems very counter to the spirit I've seen so far. Greg -- Greg Ward - software developer gward@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913 From da@ski.org Mon Apr 26 17:29:56 1999 From: da@ski.org (David Ascher) Date: Mon, 26 Apr 1999 09:29:56 -0700 (Pacific Daylight Time) Subject: [Python-Dev] Public or private python-dev archives? In-Reply-To: <199904261616.MAA22036@eric.cnri.reston.va.us> Message-ID: On Mon, 26 Apr 1999, Guido van Rossum wrote: > In a private mail, Greg Stein suggested that the python-dev archives > should be restricted to the members of the list. I prefer to make > them public, but I won't want to impose this on others without > discussion. So I've made the archives private for the time being > while we discuss this meta-issue. (Also, the existence of the list > isn't announced by mailman on its listinfo page.) If one has a public archive with restricted membership, then one needs to have a process for people to petition membership, including policies on deciding admission (which could be as vague as "up to GvR's whim"). FWIW, the perl5-porters list is open but the perl6-porters list is closed. My suggestion is that we can start with an open policy on archives, and the lax posting policy for the multiple email address business (which should be incorporated in mailman++ =), with the explicitely stated caveat that if it turns out that that policy doesn't work, we reserve the right to tighten things up. I also suggest that we don't advertise the fact that anyone can post. [Except of course that we've just mentioned this in archives which I'm arguing should be public =)] --david From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Mon Apr 26 18:44:36 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Mon, 26 Apr 1999 13:44:36 -0400 (EDT) Subject: [Python-Dev] Public or private python-dev archives? References: <199904261616.MAA22036@eric.cnri.reston.va.us> <19990426123042.A2617@cnri.reston.va.us> Message-ID: <14116.42500.284907.569281@anthem.cnri.reston.va.us> >>>>> "GW" == Greg Ward writes: GW> And consider the possibility of open subscription while GW> keeping posting restricted. Not sure how easy that is with GW> Mailman, but we can still consider the idea. It could be done in a number of ways. You could restrict postings to members only, but as Guido has pointed out, a lot of people post from more than one account and Mailman doesn't handle that very well yet. Or you could moderate the list, but then someone has to approve postings and that's more work than I think anybody wants to do. I'm also for an open-as-possible policy, with the right to restrict later if the s/n gets too low. I sort of view Python-dev to be the place that serious c.l.py proposals get fleshed out and implementation strategies discussed. The (hopefully) high level of technical detail on the list should self-select. -Barry From gmcm@hypernet.com Mon Apr 26 19:56:52 1999 From: gmcm@hypernet.com (Gordon McMillan) Date: Mon, 26 Apr 1999 13:56:52 -0500 Subject: [Python-Dev] Public or private python-dev archives? In-Reply-To: <14116.42500.284907.569281@anthem.cnri.reston.va.us> Message-ID: <1286969269-56980208@hypernet.com> [Barry] > The (hopefully) high level of > technical detail on the list should self-select. I thought the humor did that. If the public-archive were only updated weekly, it would make it's use (or abuse) as glorified help list pretty tenuous. No one has espoused Greg's reasoning. In the abscense of said arguments, I'm certainly inclined to vote for "as public as can be and still be focused". -OTOH-then-I'll-never-know-what-goes-on-in-the-smoke-filled-room-ly y'rs - Gordon From da@ski.org Mon Apr 26 20:12:54 1999 From: da@ski.org (David Ascher) Date: Mon, 26 Apr 1999 12:12:54 -0700 (Pacific Daylight Time) Subject: [Python-Dev] Why unbundle Tools and Demo? Message-ID: Several people argue for unbundling Tools/ and Demo/ in 1.6. I'd like to argue to leave them in. They're not especially big, and IMHO they are quite valuable, *especially* to the novice user. In fact, I'd like to argue that Demo/ should be promoted to the same status as Tools/ (by which I mean included in the Windows binary distribution). Unbundling Tools/ would mean unbundling IDLE, which IMHO would be a big strategic mistake. However, I wouldn't be against a cleanup of said directories. Some things should probably be removed (anything which uses stdwin), some of the code in classes is showing its age (notes about "being upgraded for Python 1.1" =), etc. That said, the tkinter/ directory is the best place to look for simple Tkinter code, and should be included, IMHO. --david From guido@CNRI.Reston.VA.US Mon Apr 26 20:20:26 1999 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Mon, 26 Apr 1999 15:20:26 -0400 Subject: [Python-Dev] Why unbundle Tools and Demo? In-Reply-To: Your message of "Mon, 26 Apr 1999 12:12:54 PDT." References: Message-ID: <199904261920.PAA22415@eric.cnri.reston.va.us> > Several people argue for unbundling Tools/ and Demo/ in 1.6. I'd like to > argue to leave them in. They're not especially big, and IMHO they are > quite valuable, *especially* to the novice user. In fact, I'd like to > argue that Demo/ should be promoted to the same status as Tools/ (by which > I mean included in the Windows binary distribution). Unbundling Tools/ > would mean unbundling IDLE, which IMHO would be a big strategic mistake. > > However, I wouldn't be against a cleanup of said directories. Some things > should probably be removed (anything which uses stdwin), some of the code > in classes is showing its age (notes about "being upgraded for Python 1.1" > =), etc. That said, the tkinter/ directory is the best place to look for > simple Tkinter code, and should be included, IMHO. Agreed. One simple thing that would help me immensely would be for someone to go through all the various Demo directories and make an inventary of what is there and how useful it is, (1) to all Python users, (2) to Windows users. Then, perhaps someone could write a simple document making these files (and Tools) more accessible... --Guido van Rossum (home page: http://www.python.org/~guido/) From da@ski.org Mon Apr 26 20:20:40 1999 From: da@ski.org (David Ascher) Date: Mon, 26 Apr 1999 12:20:40 -0700 (Pacific Daylight Time) Subject: [Python-Dev] Why unbundle Tools and Demo? In-Reply-To: <199904261920.PAA22415@eric.cnri.reston.va.us> Message-ID: > someone to go through all the various Demo directories and make an > inventary of what is there and how useful it is, (1) to all Python > users, (2) to Windows users. Then, perhaps someone could write a > simple document making these files (and Tools) more accessible... Ok. I can do that. From guido@CNRI.Reston.VA.US Mon Apr 26 20:22:55 1999 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Mon, 26 Apr 1999 15:22:55 -0400 Subject: [Python-Dev] Why unbundle Tools and Demo? In-Reply-To: Your message of "Mon, 26 Apr 1999 12:20:40 PDT." References: Message-ID: <199904261922.PAA22447@eric.cnri.reston.va.us> [me] > > someone to go through all the various Demo directories and make an > > inventary of what is there and how useful it is, (1) to all Python > > users, (2) to Windows users. Then, perhaps someone could write a > > simple document making these files (and Tools) more accessible... [Dave] > Ok. I can do that. Great! I didn't mean to volunteer you -- but I think you'd do a great job. --Guido van Rossum (home page: http://www.python.org/~guido/) From tim_one@email.msn.com Tue Apr 27 05:25:19 1999 From: tim_one@email.msn.com (Tim Peters) Date: Tue, 27 Apr 1999 00:25:19 -0400 Subject: [Python-Dev] Public or private python-dev archives? In-Reply-To: <19990426123042.A2617@cnri.reston.va.us> Message-ID: <000501be9065$f5e3db80$ab9e2299@tim> [Greg Ward, arguing in favor of ... a "secret cabal" discussing Python development off in a dark corner away from the grubby masses ] That's what I'd like too -- but somebody already let Gordon in . voting-to-leave-it-public-until-there's-a-problem-ly y'rs - tim From da@ski.org Tue Apr 27 20:23:55 1999 From: da@ski.org (David Ascher) Date: Tue, 27 Apr 1999 12:23:55 -0700 (Pacific Daylight Time) Subject: [Python-Dev] numpy Message-ID: What are the thoughts on NumPy integration into the core? --David From MHammond@skippinet.com.au Wed Apr 28 00:28:59 1999 From: MHammond@skippinet.com.au (Mark Hammond) Date: Wed, 28 Apr 1999 09:28:59 +1000 Subject: [Python-Dev] numpy In-Reply-To: Message-ID: <001c01be9105$bae7ccd0$0801a8c0@bobcat> > What are the thoughts on NumPy integration into the core? he he - and while we are at it :-) mxDateTime would need to be a popular choice for inclusion, and Guido has offered in-principle support for moving some of the Win32 stuff into the core - particularly the Registry stuff and the native Window Handle support... How far do we go :-) Personally, I would simply like to see the distutils SIG solve this problem for us. (sure). Eg, the "build" or "install" process (depending on the OS) could build a local HTML file with knowledge many "common" extensions - a single click, and it is downloaded, configured and built. Oh well, back to reality... [Which isnt to say I am opposed to NumPy and mxDateTime. Definately keen on the win32 stuff tho :-] Mark. From da@ski.org Wed Apr 28 00:31:56 1999 From: da@ski.org (David Ascher) Date: Tue, 27 Apr 1999 16:31:56 -0700 (Pacific Daylight Time) Subject: [Python-Dev] numpy In-Reply-To: <001c01be9105$bae7ccd0$0801a8c0@bobcat> Message-ID: On Wed, 28 Apr 1999, Mark Hammond wrote: > > What are the thoughts on NumPy integration into the core? > > he he - and while we are at it :-) mxDateTime would need to be a popular > choice for inclusion, and Guido has offered in-principle support for moving > some of the Win32 stuff into the core - particularly the Registry stuff and > the native Window Handle support... It may seem strange, but I'll argue for the win32 registry calls before the NumPy stuff. That could be because I've looked at NumPy code and not the win32 code. Not Jim's cleanest code. =) Mark, can you describe 'native Window Handle' support? --david From MHammond@skippinet.com.au Wed Apr 28 06:03:48 1999 From: MHammond@skippinet.com.au (Mark Hammond) Date: Wed, 28 Apr 1999 15:03:48 +1000 Subject: [Python-Dev] numpy In-Reply-To: Message-ID: <001e01be9134$809ca8f0$0801a8c0@bobcat> > It may seem strange, but I'll argue for the win32 registry > calls before > the NumPy stuff. That could be because I've looked at NumPy > code and not > the win32 code. Not Jim's cleanest code. =) he he - and I can even get out of the Win32 stuff - I wrote a string-only first version, and Bill Tutt rehashed it into what it is today, handling all the registry types. OTOH, there could also be a case for moving "win32api" completely to "core status" (whether that means truly core or simply a standard .pyd). For example, ntpath.py now has code that attempts to use "win32api.GetFullPathName()". The down-side is that win32api has nowhere near complete coverage, and is really a mixed bag of bits and pieces. Most later efforts where complete API sets are given coverage have different names - eg, win32file has the complete Win32 file API wrapped up - even if there are overlaps with existing functions in win32api. Im not sure what the answer is - my guess is a new core module with Win32 features deemed absolutely necessary for the core - stuff like the registry, and a few assorted other functions, such as GetFullPathName, but stopping well short of the full win32api set. > Mark, can you describe 'native Window Handle' support? Sure! We have a very light-weight "handle" object, representing a Win32 handle. It has no methods, and a single property for returning the underlying win32 handle as an integer. When the object destructs, it calls "CloseHandle()". Thats about it! It has no methods, so is passed as an argument. There has been no attempt to implement things like "handle.Read()" to represent "ReadFile(handle, ...)". There are 2 reasons for this: 1) Handles are fairly general purpose, and not restricted to IO operations. A handle is also used to represent a Mutex/Semaphores and threads/processes - certainly doesnt make sense to have a "Read()" method for those handles. 2) IMO, this should be done at the .py level anyway. The Win32 Handle support is pure C++ at the moment. A simple complication is that there are 3 types of handles in use at the moment - those that call "CloseHandle", those that call "RegCloseHandle" (registry handles) and a 3rd I cant recall. This is currently implemented using C++ inheritance. But even if the current implementation is not favoured, the object is so small that a rewrite would not be a problem. And for those that can be bothered to read this far, some more background: Some time ago, Greg and I decided to implement a "pywintypes" module. This defines what we considered "core types" for the Win32 world. All our extension modules (including win32api, COM; basically win32*.pyd) use this module. The objects it supports are: Unicode, Handles, Win32 Time, IIDs, Overlapped IO objects, 3 NT security related objects and importantly a standard Win32 exception and functions for filling it. Moving the registry stuff is dependant on the core having the Exception, Handle and Registry support (hence this discussion). We have our own Time object, but mxDateTime would be fine. One day, we hope to remove this pywintypes entirely, as the core will have it all :-) Mark. From gward@cnri.reston.va.us Wed Apr 28 13:51:43 1999 From: gward@cnri.reston.va.us (Greg Ward) Date: Wed, 28 Apr 1999 08:51:43 -0400 Subject: [Python-Dev] numpy In-Reply-To: <001c01be9105$bae7ccd0$0801a8c0@bobcat>; from Mark Hammond on Wed, Apr 28, 1999 at 09:28:59AM +1000 References: <001c01be9105$bae7ccd0$0801a8c0@bobcat> Message-ID: <19990428085143.A5571@cnri.reston.va.us> On 28 April 1999, Mark Hammond said: > How far do we go :-) > > Personally, I would simply like to see the distutils SIG solve this problem > for us. (sure). Eg, the "build" or "install" process (depending on the > OS) could build a local HTML file with knowledge many "common" extensions - > a single click, and it is downloaded, configured and built. Oh well, back > to reality... It's not impossible, it just takes a while. I think it took the Perl community about three years to go from "hey! let's have a standard build mechanism for modules!" to the point where I can install (almost) any module from CPAN with one shell command: perl -MCPAN -e 'install ("MIME::Base64");' which is insanely cool. (It took about two minutes to do the above just now; that included trying two CPAN mirrors that aren't being cooperative this morning, finding one that was working, downloading the current module list from it, determining that there is a more recent version available than the one installed here, downloading it, unpacking it, running "Makefile.PL" to generate the Makefile, running "make" [which compiles any extensions in the distribution, copies all the .pm files around, and generates the documentation], "make test" [run the module's self-test suite], and "make install" [install it in the "site-perl" library directory]. Amount of user interaction required: typing the above command line.) It's *still* rough around the edges, though, especially when building a new installation from scratch -- mainly because Perl doesn't ship with ftp or http libraries, so the CPAN.pm module has to try downloading stuff with lynx, ncftp, or plain ol' ftp until it has downloaded and installed the libnet and libwww-perl distributions. That's one problem we won't have with Python, at least. Oh yeah, and it all works *great* under Unix... but the rest of the world lags behind. Also, two major components of being able to do this -- the Perl Module List and CPAN -- are still vapourware in Python-land. But hey, if we can get to the "we *have* a standard build mechanism for modules!" point, then all the rest becomes a lot more feasible. Pep talk over... Greg -- Greg Ward - software developer gward@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913 From mal@lemburg.com Wed Apr 28 08:44:25 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 28 Apr 1999 09:44:25 +0200 Subject: [Python-Dev] numpy References: <001c01be9105$bae7ccd0$0801a8c0@bobcat> Message-ID: <3726BC59.35E3C9DB@lemburg.com> Mark Hammond wrote: > > > What are the thoughts on NumPy integration into the core? > > he he - and while we are at it :-) mxDateTime would need to be a popular > choice for inclusion, and Guido has offered in-principle support for moving > some of the Win32 stuff into the core - particularly the Registry stuff and > the native Window Handle support... > > How far do we go :-) > > Personally, I would simply like to see the distutils SIG solve this problem > for us. (sure). Eg, the "build" or "install" process (depending on the > OS) could build a local HTML file with knowledge many "common" extensions - > a single click, and it is downloaded, configured and built. Oh well, back > to reality... You're talking about fast moving targets there... are you sure that you want those in the standard distribution ? Maybe we have two distributions: the standard one and a pro edition with all the slick stuff included (together with a proper setup script to get those references to external libs and include files right). Actually, this is something I've been wanting to do for nearly a year now... just haven't found the time to really get things the way I want them. It's a project called Python Power Tools and includes many generic extensions (currently only ones that don't rely on external libs). If you're interested, have a look at an old version available at: http://starship.skyport.net/~lemburg/PowerTools-0.2.zip It includes the extensions BTree, mxDateTime, mxTools, mxStack, Trie, avl and kjbuckets. NumPy should probably also be included. The current setup uses a recursive Makefile approach (not too elegant, but works). A distutils setup would be much better. -- Marc-Andre Lemburg Y2000: 247 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From jack@oratrix.nl Wed Apr 28 14:48:21 1999 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 28 Apr 1999 15:48:21 +0200 Subject: [Python-Dev] numpy In-Reply-To: Message by "Mark Hammond" , Wed, 28 Apr 1999 09:28:59 +1000 , <001c01be9105$bae7ccd0$0801a8c0@bobcat> Message-ID: <19990428134821.E9A68300F57@snelboot.oratrix.nl> > [...] Guido has offered in-principle support for moving > some of the Win32 stuff into the core - particularly the Registry stuff and > the native Window Handle support... I think it would be nice to put all the stuff that is shared between modules (I think that's only PyWinTypes, but who am I to think I have a clue about the windows port:-) into the core. I just did the same for MacPython, and it makes life a whole lot easier. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@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 From skip@mojam.com (Skip Montanaro) Wed Apr 28 16:57:40 1999 From: skip@mojam.com (Skip Montanaro) (skip@mojam.com (Skip Montanaro)) Date: Wed, 28 Apr 1999 11:57:40 -0400 Subject: [Python-Dev] LLNL C++ as base for Python 2? Message-ID: <199904281557.LAA06491@cm-29-94-14.nycap.rr.com> Have we been talking about Python 2 or Python 1.6? If we're talking about Python 2, has anyone given a serious look at the LLNL gang's C++/Python stuff? If I recall Paul Dubois' talk at the last conference, it sounded like their work made it much easier to implement extension modules. Skip Montanaro | Mojam: "Uniting the World of Music" http://www.mojam.com/ skip@mojam.com | Musi-Cal: http://www.musi-cal.com/ 518-372-5583 From guido@CNRI.Reston.VA.US Wed Apr 28 17:06:03 1999 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Wed, 28 Apr 1999 12:06:03 -0400 Subject: [Python-Dev] LLNL C++ as base for Python 2? In-Reply-To: Your message of "Wed, 28 Apr 1999 11:57:40 EDT." <199904281557.LAA06491@cm-29-94-14.nycap.rr.com> References: <199904281557.LAA06491@cm-29-94-14.nycap.rr.com> Message-ID: <199904281606.MAA27526@eric.cnri.reston.va.us> > Have we been talking about Python 2 or Python 1.6? If we're talking about > Python 2, has anyone given a serious look at the LLNL gang's C++/Python > stuff? If I recall Paul Dubois' talk at the last conference, it sounded > like their work made it much easier to implement extension modules. I've mostly had 1.6 in mind. See recent traffic in the C++ SIG archives for the status of Paul's CXX. --Guido van Rossum (home page: http://www.python.org/~guido/) From da@ski.org Wed Apr 28 18:24:00 1999 From: da@ski.org (David Ascher) Date: Wed, 28 Apr 1999 10:24:00 -0700 (Pacific Daylight Time) Subject: [Python-Dev] LLNL C++ as base for Python 2? In-Reply-To: <199904281606.MAA27526@eric.cnri.reston.va.us> Message-ID: On Wed, 28 Apr 1999, Guido van Rossum wrote: > > Have we been talking about Python 2 or Python 1.6? If we're talking about > > Python 2, has anyone given a serious look at the LLNL gang's C++/Python > > stuff? If I recall Paul Dubois' talk at the last conference, it sounded > > like their work made it much easier to implement extension modules. > > I've mostly had 1.6 in mind. See recent traffic in the C++ SIG > archives for the status of Paul's CXX. Recent traffic? There's nothing in there that's substantive since... uh, well, I got tired of looking back. =) CXX is very cool, but it is still pushing the envelope of many C++ compilers. From what I gather, recent egcs' do manage with it, and since egcs is going to replace gcc, I expect that many platforms will be able to "do" CXX relatively soon. I vote to stay on the 1.6 track for now. From MHammond@skippinet.com.au Fri Apr 30 03:40:09 1999 From: MHammond@skippinet.com.au (Mark Hammond) Date: Fri, 30 Apr 1999 12:40:09 +1000 Subject: [Python-Dev] More flexible namespaces. Message-ID: <008d01be92b2$c56ef5d0$0801a8c0@bobcat> 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 ), 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. From guido@CNRI.Reston.VA.US Fri Apr 30 04:00:52 1999 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Thu, 29 Apr 1999 23:00:52 -0400 Subject: [Python-Dev] More flexible namespaces. In-Reply-To: Your message of "Fri, 30 Apr 1999 12:40:09 +1000." <008d01be92b2$c56ef5d0$0801a8c0@bobcat> References: <008d01be92b2$c56ef5d0$0801a8c0@bobcat> Message-ID: <199904300300.XAA00608@eric.cnri.reston.va.us> > 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. I agree that this would be seriously cool. It will definitely be in Python 2.0; it's already in JPython. Quite a while ago, Ian Castleden sent me patches for 1.5.1 to do this. It was a lot of code and I was indeed worried about slowing things down too much (and also about checking that he got all the endcases right). Ian did benchmarks and found that the new code was consistently slower, by 3-6%. Perhaps for Python 1.6 this will be acceptable (the "Python IS slow" thread notwithstanding :-); or perhaps someone can have a look at it and squeeze some more time out of it? I'll gladly forward the patches. --Guido van Rossum (home page: http://www.python.org/~guido/) From da@ski.org Fri Apr 30 04:21:04 1999 From: da@ski.org (David Ascher) Date: Thu, 29 Apr 1999 20:21:04 -0700 (Pacific Daylight Time) Subject: [Python-Dev] More flexible namespaces. In-Reply-To: <199904300300.XAA00608@eric.cnri.reston.va.us> Message-ID: > > 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. > > I agree that this would be seriously cool. It will definitely be in > Python 2.0; it's already in JPython. Seriously cool is an understatement. --david From MHammond@skippinet.com.au Fri Apr 30 05:13:25 1999 From: MHammond@skippinet.com.au (Mark Hammond) Date: Fri, 30 Apr 1999 14:13:25 +1000 Subject: [Python-Dev] More flexible namespaces. In-Reply-To: <199904300300.XAA00608@eric.cnri.reston.va.us> Message-ID: <009001be92bf$cb998f80$0801a8c0@bobcat> > Ian did benchmarks and found that the new code was consistently > slower, by 3-6%. Perhaps for Python 1.6 this will be acceptable (the > "Python IS slow" thread notwithstanding :-); or perhaps someone can As long as we get someone working on a consistent 3-6% speedup in other areas this wont be a problem :-) I will attach it to my long list - but Im going to put all my efforts here into Unicode first, and probably the threading stuff second :-) Mark. From tismer@appliedbiometrics.com Fri Apr 30 08:49:42 1999 From: tismer@appliedbiometrics.com (Christian Tismer) Date: Fri, 30 Apr 1999 09:49:42 +0200 Subject: [Python-Dev] More flexible namespaces. References: <008d01be92b2$c56ef5d0$0801a8c0@bobcat> <199904300300.XAA00608@eric.cnri.reston.va.us> Message-ID: <37296096.D0C9C2CC@appliedbiometrics.com> Guido van Rossum wrote: ... > Ian did benchmarks and found that the new code was consistently > slower, by 3-6%. Perhaps for Python 1.6 this will be acceptable (the > "Python IS slow" thread notwithstanding :-); or perhaps someone can > have a look at it and squeeze some more time out of it? I'll gladly > forward the patches. I'd really like to look into that. Also I wouldn't worry too much about speed, since this is such a cool feature. It might even be a speedup in some cases which otherwise would need more complex handling. May I have a look? ciao - chris -- Christian Tismer :^) 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 From mal@lemburg.com Fri Apr 30 09:22:46 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 30 Apr 1999 10:22:46 +0200 Subject: [Python-Dev] More flexible namespaces. References: <008d01be92b2$c56ef5d0$0801a8c0@bobcat> Message-ID: <37296856.5875AAAF@lemburg.com> Mark Hammond wrote: > > 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 involves a whole lot of changes: not only in the Python core, but also in extensions that rely on having real dictionaries available. Since you put out to objectives, I'd like to propose a little different approach... 1. Have eval/exec accept any mapping object as input 2. Make those two copy the content of the mapping object into real dictionaries 3. Provide a hook into the dictionary implementation that can be used to redirect KeyErrors and use that redirection to forward the request to the original mapping objects > This would give us 2 seriously cool features (that I want ), 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. This is covered by 1 and 2. > * 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. This is something for 3. I guess it wouldn't cause any significant slow-down and can be imlemented with much less code than the "change all PyDict_GetItem to PyObject_GetItem" thingie. The real thing could then be done for 2.0 where PyDict_Check() would presumably not rely on an adress but some kind of inheritance scheme indicating that the object is in fact a dictionary. Cheers, -- Marc-Andre Lemburg Y2000: 245 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From guido@CNRI.Reston.VA.US Fri Apr 30 16:17:20 1999 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Fri, 30 Apr 1999 11:17:20 -0400 Subject: [Python-Dev] More flexible namespaces. In-Reply-To: Your message of "Fri, 30 Apr 1999 09:49:42 +0200." <37296096.D0C9C2CC@appliedbiometrics.com> References: <008d01be92b2$c56ef5d0$0801a8c0@bobcat> <199904300300.XAA00608@eric.cnri.reston.va.us> <37296096.D0C9C2CC@appliedbiometrics.com> Message-ID: <199904301517.LAA01422@eric.cnri.reston.va.us> > From: Christian Tismer > I'd really like to look into that. > Also I wouldn't worry too much about speed, since this is > such a cool feature. It might even be a speedup in some cases > which otherwise would need more complex handling. > > May I have a look? Sure! (I've forwarded Christian the files per separate mail.) I'm also interested in your opinion on how well thought-out and robust the patches are -- I've never found the time to do a good close reading of them. --Guido van Rossum (home page: http://www.python.org/~guido/) From gmcm@hypernet.com Fri Apr 30 17:32:30 1999 From: gmcm@hypernet.com (Gordon McMillan) Date: Fri, 30 Apr 1999 11:32:30 -0500 Subject: [Python-Dev] More flexible namespaces. In-Reply-To: <199904301517.LAA01422@eric.cnri.reston.va.us> References: Your message of "Fri, 30 Apr 1999 09:49:42 +0200." <37296096.D0C9C2CC@appliedbiometrics.com> Message-ID: <1286632328-77246936@hypernet.com> Guido wrote: > > From: Christian Tismer > > > I'd really like to look into that. > > Also I wouldn't worry too much about speed, since this is ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > such a cool feature. It might even be a speedup in some cases > > which otherwise would need more complex handling. > > > > May I have a look? > > Sure! > > (I've forwarded Christian the files per separate mail.) I don't know who you sent that to, but it couldn't possibly have been Christian! - Gordon From tismer@appliedbiometrics.com Fri Apr 30 16:57:09 1999 From: tismer@appliedbiometrics.com (Christian Tismer) Date: Fri, 30 Apr 1999 17:57:09 +0200 Subject: [Python-Dev] More flexible namespaces. References: <008d01be92b2$c56ef5d0$0801a8c0@bobcat> <199904300300.XAA00608@eric.cnri.reston.va.us> <37296096.D0C9C2CC@appliedbiometrics.com> <199904301517.LAA01422@eric.cnri.reston.va.us> Message-ID: <3729D2D5.6844D6DA@appliedbiometrics.com> Guido van Rossum wrote: > > > From: Christian Tismer > > May I have a look? > > Sure! > > (I've forwarded Christian the files per separate mail.) Thanks a lot! > I'm also interested in your opinion on how well thought-out and robust > the patches are -- I've never found the time to do a good close > reading of them. Yes, it is quite long and not so very easy to digest. At first glance, most of the changes are replacements of dict access with mapping access where we pay for the extra indirection. It depends on how often this feature will really replace dicts. If dicts are more common, I'd like to figure out how much code bloat extra special casing for dicts would give. Puha - thanks - chris -- Christian Tismer :^) 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 From tismer@appliedbiometrics.com Fri Apr 30 17:19:57 1999 From: tismer@appliedbiometrics.com (Christian Tismer) Date: Fri, 30 Apr 1999 18:19:57 +0200 Subject: [Python-Dev] More flexible namespaces. References: Your message of "Fri, 30 Apr 1999 09:49:42 +0200." <37296096.D0C9C2CC@appliedbiometrics.com> <1286632328-77246936@hypernet.com> Message-ID: <3729D82D.CE16884@appliedbiometrics.com> Gordon McMillan wrote: > > Guido wrote: > > > > From: Christian Tismer > > > > > I'd really like to look into that. > > > Also I wouldn't worry too much about speed, since this is > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > such a cool feature. It might even be a speedup in some cases > > > which otherwise would need more complex handling. > > > > > > May I have a look? > > > > Sure! > > > > (I've forwarded Christian the files per separate mail.) > > I don't know who you sent that to, but it couldn't possibly have been > Christian! :-) :-) truely not if I had'n other things in mind. I know that I will not get more than 30-40 percent by compiling the interpreter away, so I will not even spend time at a register machine right now. Will also not follow the ideas of P2C any longer, doesn't pay off. Instead, If I can manage to create something like static binding snapshots, then I could resolve many of the lookups and internal method indirections, for time critical applications. For all the rest, Python is pretty much fast enough. I've begun to write s special platform dependant version which allows me to do all the things which can't go into the dist. For instance, I just saved some 10 percent by dynamically patching some of the ParseTuple and BuildObject calls out of the core code (ahem). I hope Python will stay as clean as it is, allowing me to try all kinds of tricks for one machine class. ciao - chris.speedy -- Christian Tismer :^) 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 From akuchlin@cnri.reston.va.us Fri Apr 30 17:33:34 1999 From: akuchlin@cnri.reston.va.us (Andrew M. Kuchling) Date: Fri, 30 Apr 1999 12:33:34 -0400 (EDT) Subject: [Python-Dev] More flexible namespaces. In-Reply-To: <3729D82D.CE16884@appliedbiometrics.com> References: <37296096.D0C9C2CC@appliedbiometrics.com> <1286632328-77246936@hypernet.com> <3729D82D.CE16884@appliedbiometrics.com> Message-ID: <14121.55659.754846.708467@amarok.cnri.reston.va.us> Christian Tismer writes: >Instead, If I can manage to create something like static binding >snapshots, then I could resolve many of the lookups and internal >method indirections, for time critical applications. The usual assumption is that the lookups are what takes time. Now, are we sure of that assumption? I'd expect the lookup code to be like: 1) Get hash of name 2) Retrieve object from dictionary 3) Do something with the object. Now, since string objects cache their hash value, 1) should usually be just "if (obj->cached_hash_value!=-1) return obj->cached_hash_value"; a comparision and a return. Step 2) should be very fast, barring a bad hash function. So perhaps most of the time is spent in 3), creating new local dicts, stack frames, and what not. (Yes, I know that doing this on every reference to an object is part of the problem.) I also wonder about the costs of all the Py_BuildValue and Py_ParseTuple calls going on under the hood. A performance improvement project would definitely be a good idea for 1.6, and a good sub-topic for python-dev. Incidentally, what's the verdict on python-dev archives: public or not? -- A.M. Kuchling http://starship.python.net/crew/amk/ Despair says little, and is patient. -- From SANDMAN: "Season of Mists", episode 0 From tismer@appliedbiometrics.com Fri Apr 30 17:55:55 1999 From: tismer@appliedbiometrics.com (Christian Tismer) Date: Fri, 30 Apr 1999 18:55:55 +0200 Subject: [Python-Dev] More flexible namespaces. References: <37296096.D0C9C2CC@appliedbiometrics.com> <1286632328-77246936@hypernet.com> <3729D82D.CE16884@appliedbiometrics.com> <14121.55659.754846.708467@amarok.cnri.reston.va.us> Message-ID: <3729E09B.5F65E3CA@appliedbiometrics.com> "Andrew M. Kuchling" wrote: > > Christian Tismer writes: > >Instead, If I can manage to create something like static binding > >snapshots, then I could resolve many of the lookups and internal > >method indirections, for time critical applications. > > The usual assumption is that the lookups are what takes time. > Now, are we sure of that assumption? I'd expect the lookup code to be > like: > > 1) Get hash of name > 2) Retrieve object from dictionary > 3) Do something with the object. ... Right, but when you become more restrictive, you can do lots, lots more. If I also allow to fix the type of an object, I can go under the hood of the Python API, so you could add some points 4) 5) 6) here. But I shouldn't have talked before I can show something. And at the time, I don't restrict myself to write clean code, but try very machine specific things which I don't believe should go into Python at all. > I also wonder about the costs of all the Py_BuildValue and > Py_ParseTuple calls going on under the hood. A performance > improvement project would definitely be a good idea for 1.6, and a > good sub-topic for python-dev. I wasn't sure, so I first wrote a module which does statistics on that, and I found a lot of these calls. Some are even involved in ceval's code, where things like "(OOOO)" is parsed all over again and again. Now I think this is ok in most cases. But in some places these are very bad: If your builtin function soes so very few work. Take len(): This uses ParseTuple, which calls a function to find out its object, then calls a function to get the object, then takes the len, and builds the result. But since everything has a length, checking for no NULL pointer and grabbing the len produces even shorter code. This applies to many places as well. But right now, I don't change the core, but build hacky little extension modules which squeak such things out at runtime. No big deal yet, but maybe it could pay off to introduce format strings which make them more suitableto be used in macro substitutions. sorry if I was too elaborate, this is so much fun :-) ciao - chris -- Christian Tismer :^) 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 From skip at mojam.com Wed Apr 21 15:17:32 1999 From: skip at mojam.com (skip at mojam.com) Date: Wed, 21 Apr 1999 09:17:32 -0400 Subject: [Python-Dev] ZServer 1.0b1: spurious colon in HTTP response line Message-ID: <199904211317.JAA26167@cm-29-94-14.nycap.rr.com> (Also reported to the bug catcher.) I'm trying to migrate from ZopeHTTPServer to ZServer 1.0b1. I was seeing the ZServer headers turning up in pages generated by the process. When I viewed the page source of the generated HTML I saw: HTTP/1.0: 200 OK Server: Zope/experimental ZServer/1.1b1 Date: Wed, 21 Apr 1999 13:00:38 GMT X-Powered-By: Zope (www.zope.org), Python (www.python.org) Connection: close Content-Type: text/html Content-Length: 7802 Musi-Cal... Concert Schedules: Folk Music, Country Music, Rock Music & more! ... I run ZServer behind an Apache 1.3.3 running mod_proxy. Apparently Apache doesn't recognize the HTTP response when there is a colon following the version number and adds a simple set of headers itself. I guess web browsers either ignore that line or are more lenient in their parsing of the response. The following simple patch corrects the problem: diff -c2 HTTPResponse.py.~1~ HTTPResponse.py *** HTTPResponse.py.~1~ Tue Apr 13 15:21:12 1999 --- HTTPResponse.py Wed Apr 21 09:05:00 1999 *************** *** 146,150 **** # status header must come first. ! append("HTTP/%s: %s" % (self._http_version, status)) if headers.has_key('status'): del headers['status'] --- 146,150 ---- # status header must come first. ! append("HTTP/%s %s" % (self._http_version, status)) if headers.has_key('status'): del headers['status'] *************** Skip Montanaro | Mojam: "Uniting the World of Music" http://www.mojam.com/ skip at mojam.com | Musi-Cal: http://www.musi-cal.com/ 518-372-5583 From da at ski.org Wed Apr 21 20:47:56 1999 From: da at ski.org (David Ascher) Date: Wed, 21 Apr 1999 11:47:56 -0700 (Pacific Daylight Time) Subject: [Python-Dev] Notice of intent: rich comparisons Message-ID: Now that 1.5.2 is finalized, I'll be starting to prepare a patch for the rich comparisons. Guido, how do you envision python-dev working? Do you want to hand out a TODO list for 1.6? --david From guido at CNRI.Reston.VA.US Wed Apr 21 21:04:40 1999 From: guido at CNRI.Reston.VA.US (Guido van Rossum) Date: Wed, 21 Apr 1999 15:04:40 -0400 Subject: [Python-Dev] Notice of intent: rich comparisons In-Reply-To: Your message of "Wed, 21 Apr 1999 11:47:56 PDT." References: Message-ID: <199904211904.PAA14966@eric.cnri.reston.va.us> > Now that 1.5.2 is finalized, I'll be starting to prepare a patch for the > rich comparisons. Cool! > Guido, how do you envision python-dev working? I though we'd just crack Monty Python jokes while pretending to work :-) > Do you want to hand out a TODO list for 1.6? Well, I'm not saying that this is the definitive list, but certainly there are a bunch of things that definitely need to be incorporated. Here's an excerpt of a list that I keep for myself, in no particular order, with brief annotations (I have a meeting in 15 minutes :): Redesign thread/init APIs See the recent discussion in the thread-sig. There should be some kind of micro-init that initializes essential components (including the thread lock!) but doesn't create an interpreter or a threadstate object. There should also be a notion of a default interpreter. Break up into VM, parser, import, mainloop, and other components? The porting efforts to seriously small machines (Win/CE, Pilot, etc.) all seem to need a Python VM that doesn't automatically pull in the parser and interactive main loop. There are other reasons as well to isolate various parts of the functionality (including all numeric data types except ints). This could include: restructuring of the parser so codeop.py can be simplified; making the interactive main loop a script. String methods Barry has his patches ready. Unicode What is the status of /F's latest attempts? Rich comparisons This is Dave's plan. Coercions Marc-Andre Lemburg has some good suggestions here: http://starship.python.net/~lemburg/coercion-0.6.zip Import revamp It should be much easier to add hooks to allow importing from zip files, from a URL, etc., or (different) hooks to allow looking for different extensions (e.g. to automatically generate ILU stubs). This should help the small platforms too, since they often don't have a filesystem, so their imports will have to come from some other place. ANSI C I'm tired of supporting K&R C. All code should be converted to using prototypes. The Py_PROTO macros should go. We can add const-correctness to all code. Too bad for platforms without decent compilers (let them get GCC). Buffer object API extensions Marc-Andre Lemburg has a patch Distutil Should we start integrating some of the results of the distutil SIG? (What's the status? I haven't been paying attention.) Misc Jeremy Hylton's urllib2.py Greg Stein's new httplib.py (or Jeremy's?) Andrew Kuchling's new PCRE release? The IPv6 patches? Gotta run! --Guido van Rossum (home page: http://www.python.org/~guido/) From gward at cnri.reston.va.us Wed Apr 21 21:10:08 1999 From: gward at cnri.reston.va.us (Greg Ward) Date: Wed, 21 Apr 1999 15:10:08 -0400 Subject: [Python-Dev] Notice of intent: rich comparisons In-Reply-To: <199904211904.PAA14966@eric.cnri.reston.va.us>; from Guido van Rossum on Wed, Apr 21, 1999 at 03:04:40PM -0400 References: <199904211904.PAA14966@eric.cnri.reston.va.us> Message-ID: <19990421151008.D6167@cnri.reston.va.us> On 21 April 1999, Guido van Rossum said: > Distutil > > Should we start integrating some of the results of the > distutil SIG? (What's the status? I haven't been paying > attention.) It's in a state that other people can look at the code, but (apparently) not yet good enough for floods of patches to come in. Right now, Distutils has *just* enough marbles to "build" and install itself on Unix systems, and someone has contributed a patch so it works on NT. No support yet for compiling extensions, which of course is the important thing. Greg -- Greg Ward - software developer gward at cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913 From da at ski.org Wed Apr 21 21:19:42 1999 From: da at ski.org (David Ascher) Date: Wed, 21 Apr 1999 12:19:42 -0700 (Pacific Daylight Time) Subject: [Python-Dev] Notice of intent: rich comparisons In-Reply-To: <199904211904.PAA14966@eric.cnri.reston.va.us> Message-ID: On Wed, 21 Apr 1999, Guido van Rossum wrote: > > Guido, how do you envision python-dev working? > > I though we'd just crack Monty Python jokes while pretending to work :-) That'd be better than what I've read on the perl5-porters list in the last couple of days (which I'm reading because of the ad hoopla). They seem to spend their time arguing about whether Perl codes are programs or scripts. Viciously, too. =) More seriously, some of the discussions they're having a worth keeping an eye on, just as a form of legal industrial spying. > Import revamp There was an interesting bit from Greg, Jack, and MarkH on this topic recently in the distutil-sig. Maybe one of them can bring the rest of us up to date on the effort. --david From fredrik at pythonware.com Wed Apr 21 22:04:54 1999 From: fredrik at pythonware.com (Fredrik Lundh) Date: Wed, 21 Apr 1999 22:04:54 +0200 Subject: [Python-Dev] Notice of intent: rich comparisons References: <199904211904.PAA14966@eric.cnri.reston.va.us> Message-ID: <092701be8c32$3a4ad9f0$f29b12c2@pythonware.com> Guido wrote: > String methods > > Barry has his patches ready. > > Unicode > > What is the status of /F's latest attempts? most of the code is written and tested; the API still needs some cleaning up. I also have a few patches and other contributions in my inbox that I gotta look into... btw, the unicode module can be compiled for 8-bit characters too. we could merge it with the string module (one place to fix bugs...) > Import revamp > > It should be much easier to add hooks to allow importing > from zip files, from a URL, etc., or (different) hooks to > allow looking for different extensions (e.g. to automatically > generate ILU stubs). This should help the small platforms > too, since they often don't have a filesystem, so their > imports will have to come from some other place. something similar to greg's imputil.py should definitely be in the core... > ANSI C > > I'm tired of supporting K&R C. All code should be converted > to using prototypes. The Py_PROTO macros should go. We can > add const-correctness to all code. Too bad for platforms > without decent compilers (let them get GCC). or ansi2knr.c (available from http://www.cs.wisc.edu/~ghost/). otoh, it only converts function headers, so I'm not sure it's worth the effort... From beazley at cs.uchicago.edu Wed Apr 21 22:06:50 1999 From: beazley at cs.uchicago.edu (David Beazley) Date: Wed, 21 Apr 1999 15:06:50 -0500 (CDT) Subject: [Python-Dev] Notice of intent: rich comparisons References: <199904211904.PAA14966@eric.cnri.reston.va.us> Message-ID: <199904212006.PAA17138@tartarus.cs.uchicago.edu> Guido van Rossum writes: > > ANSI C > > I'm tired of supporting K&R C. All code should be converted > to using prototypes. The Py_PROTO macros should go. We can > add const-correctness to all code. Too bad for platforms > without decent compilers (let them get GCC). > Maybe I'm just lucky, but I've written nothing but ANSI C for the last 8 years and have never had a problem compiling it on any machine. I don't see this as being a huge issue. > > Misc > Depending on how deep I want to dig, I may have some patches to ParseTuple() that would make life easier for some of us extension writing fans. As it is right now, my experimental version of Swig is using it's own version of ParseTuple (for various reasons). Also, out of curiousity, is anyone making heavy use of the CObject type right now? Cheers, Dave From jim at digicool.com Wed Apr 21 23:15:24 1999 From: jim at digicool.com (Jim Fulton) Date: Wed, 21 Apr 1999 17:15:24 -0400 Subject: [Python-Dev] Notice of intent: rich comparisons References: <199904211904.PAA14966@eric.cnri.reston.va.us> <199904212006.PAA17138@tartarus.cs.uchicago.edu> Message-ID: <371E3FEC.9D19607A@digicool.com> David Beazley wrote: > > Guido van Rossum writes: > > > > ANSI C > > > > I'm tired of supporting K&R C. All code should be converted > > to using prototypes. The Py_PROTO macros should go. We can > > add const-correctness to all code. Too bad for platforms > > without decent compilers (let them get GCC). > > > > Maybe I'm just lucky, but I've written nothing but ANSI C for the last > 8 years and have never had a problem compiling it on any machine. I > don't see this as being a huge issue. I've had the same experience with things like prototypes. The recent introduction of indented preprocessor instructions caused me significant pain on some platforms. Fortunately, I haven't had to deal with those platforms recently, still, the elegence of indented preporicessor instructions wasn't worth the pain it caused. As far as choice of compilers goes, sometimes gcc isn't an option. I've had cases where I *had* to use the native compiler in order to link to third-party libraries. I support moving to ANSI C, for example, wrt prototypes, but lets still be somewhat sensative to portability and not abuse bad compilers without good reason. > > > > > Misc > > > > Depending on how deep I want to dig, I may have some patches to > ParseTuple() that would make life easier for some of us extension > writing fans. As it is right now, my experimental version of Swig > is using it's own version of ParseTuple (for various reasons). > Also, out of curiousity, is anyone making heavy use of the CObject > type right now? Yes. Jim -- Jim Fulton mailto:jim at digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats. From jeremy at cnri.reston.va.us Wed Apr 21 23:23:57 1999 From: jeremy at cnri.reston.va.us (Jeremy Hylton) Date: Wed, 21 Apr 1999 17:23:57 -0400 (EDT) Subject: [Python-Dev] Notice of intent: rich comparisons In-Reply-To: <199904212006.PAA17138@tartarus.cs.uchicago.edu> References: <199904211904.PAA14966@eric.cnri.reston.va.us> <199904212006.PAA17138@tartarus.cs.uchicago.edu> Message-ID: <14110.16787.893181.642806@bitdiddle.cnri.reston.va.us> >>>>> "DB" == David Beazley writes: DB> various reasons). Also, out of curiousity, is anyone making DB> heavy use of the CObject type right now? I used it a little, but only in a modified Python backend for SWIG. Jeremy From mal at lemburg.com Wed Apr 21 23:46:46 1999 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 21 Apr 1999 23:46:46 +0200 Subject: [Python-Dev] Notice of intent: rich comparisons References: <199904211904.PAA14966@eric.cnri.reston.va.us> Message-ID: <371E4746.22A84506@lemburg.com> Guido van Rossum wrote: > > Break up into VM, parser, import, mainloop, and other components? > > The porting efforts to seriously small machines (Win/CE, > Pilot, etc.) all seem to need a Python VM that doesn't > automatically pull in the parser and interactive main loop. > There are other reasons as well to isolate various parts > of the functionality (including all numeric data types except > ints). > > This could include: restructuring of the parser so codeop.py > can be simplified; making the interactive main loop a script. There's some good work out there by Skip Montanaro to revamp the VM into a combined register/stack machine. He calls it rattlesnake. More infos can be found in the list archive (it's currently sleeping): http://www.egroups.com/folders/rattlesnake I would like to see the VM/compiler pluggable so that experiments like rattlesnake become easier to implement (extension modules vs. patches to the core interpreter). > Coercions > > Marc-Andre Lemburg has some good suggestions here: > http://starship.python.net/~lemburg/coercion-0.6.zip I will continue to work on these patches now that 1.5.2 is out. There is a (more or less) detailed explanation of the patch set at: http://starship.skyport.net/~lemburg/CoercionProposal.html Instead of using of using the PY_NEWSTYLENUMBER approach I'll turn to the new type flags that were introduced in 1.5.2. The Py_NotImplemented singleton return value will stay, because performance tests have shown that this method does not cause any significant hit where as the exception raise and catch method does introduce a significant slow-down. > Import revamp Greg's imputil.py (it's in the distutils package) should provide a good start. > Buffer object API extensions I'll put the complete patch up on starship later this week... here are the basic prototypes: DL_IMPORT(int) PyObject_AsCharBuffer Py_PROTO((PyObject *obj, const char **buffer, int *buffer_len)); /* Takes an arbitrary object which must support the (character, single segment) buffer interface and returns a pointer to a read-only memory location useable as character based input for subsequent processing. buffer and buffer_len are only set in case no error occurrs. Otherwise, -1 is returned and an exception set. */ DL_IMPORT(int) PyObject_AsReadBuffer Py_PROTO((PyObject *obj, const void **buffer, int *buffer_len)); /* Same as PyObject_AsCharBuffer() except that this API expects (readable, single segment) buffer interface and returns a pointer to a read-only memory location which can contain arbitrary data. buffer and buffer_len are only set in case no error occurrs. Otherwise, -1 is returned and an exception set. */ DL_IMPORT(int) PyObject_AsWriteBuffer Py_PROTO((PyObject *obj, void **buffer, int *buffer_len)); /* Takes an arbitrary object which must support the (writeable, single segment) buffer interface and returns a pointer to a writeable memory location in buffer of size buffer_len. buffer and buffer_len are only set in case no error occurrs. Otherwise, -1 is returned and an exception set. */ > Distutil > > Should we start integrating some of the results of the > distutil SIG? (What's the status? I haven't been paying > attention.) With all the different modules and packages available for Python starting to slowly introduce dependencies, I think the main objective should be introducing a well organized installation info system, e.g. a registry where modules and packages can query and save version and dependency information. Someone on the main list mentioned that JPython has something like this... > Misc > > Jeremy Hylton's urllib2.py > > Greg Stein's new httplib.py (or Jeremy's?) > > Andrew Kuchling's new PCRE release? > > The IPv6 patches? These are on my wish list, so I'll simply add them here: ? APIs to faciliate creation of extensions classes (using Python classes and C functions as methods) The main open question here is where and how to store C data in the instances. This could also provide a way to migrate to all Python classes for some future version. ? Restructure the calling mechanism used in ceval.c to make it clearer, more flexible and faster (of course, :-). Also, inline calling of C functions/methods (this produces a noticable speedup). I have a patch for the restructuring and an old one (against 1.5) for the C function call inlining. ? A "fastpath" hook made available through the sys module. This should hook into the module/package loader and should be used whenever set to find a module (reverting to the standard lookup method in case it can't find it). I have an old patch that does this. It uses a simple Python function to redirect the lookup to a precalculated dictionary of installed modules/packages. This results in faster startup of the Python interpreter (by saving a few hundred stat() calls). -- Marc-Andre Lemburg Y2000: 254 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From mal at lemburg.com Wed Apr 21 23:51:11 1999 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 21 Apr 1999 23:51:11 +0200 Subject: [Python-Dev] Notice of intent: rich comparisons References: <199904211904.PAA14966@eric.cnri.reston.va.us> <199904212006.PAA17138@tartarus.cs.uchicago.edu> Message-ID: <371E484F.22046FE9@lemburg.com> David Beazley wrote: > > > > > Misc > > > > Depending on how deep I want to dig, I may have some patches to > ParseTuple() that would make life easier for some of us extension > writing fans. As it is right now, my experimental version of Swig > is using it's own version of ParseTuple (for various reasons). > Also, out of curiousity, is anyone making heavy use of the CObject > type right now? You mean the one in Objects/cobject.c ? Sure, all my type extensions export their C API that way... and it works just great (no more linker problems, nice error messages when extensions are not found, etc.). -- Marc-Andre Lemburg Y2000: 254 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From da at ski.org Wed Apr 21 23:56:17 1999 From: da at ski.org (David Ascher) Date: Wed, 21 Apr 1999 14:56:17 -0700 (Pacific Daylight Time) Subject: [Python-Dev] Notice of intent: rich comparisons In-Reply-To: <371E484F.22046FE9@lemburg.com> Message-ID: David Beazley wrote: > Also, out of curiousity, is anyone making heavy use of the CObject > type right now? NumPy does. --da From MHammond at skippinet.com.au Thu Apr 22 01:45:19 1999 From: MHammond at skippinet.com.au (Mark Hammond) Date: Thu, 22 Apr 1999 09:45:19 +1000 Subject: [Python-Dev] Notice of intent: rich comparisons In-Reply-To: <092701be8c32$3a4ad9f0$f29b12c2@pythonware.com> Message-ID: <004c01be8c51$043f27c0$0801a8c0@bobcat> [Guido and /F] > > Unicode > > > > What is the status of /F's latest attempts? > > most of the code is written and tested; the API still > needs some cleaning up. I also have a few patches > and other contributions in my inbox that I gotta > look into... Im one of those contributors :-) I have made changes to the Win32 extensions that allows it to use /F's type instead of its own built-in Unicode type. Further, the Windows CE port of these extensions actually enables this - so we have some code actively using it. However, this still doesnt give me anything more than I had before. We need at least _some_ level of integration of this type into Python. The key areas to me are: * PyArg_ParseTuple and Py_BuildValue - Seems OK we use the "u" format character analogous to "s". We havent thought of a "z" equivilent. This is fairly easy. * Some way for these functions to auto-convert. Eg, when the user passes an 8bit string object, but the C side of the world wants a Unicode string. This is harder, as an extra memory buffer for the conversion is needed. This second problem is, to me, the next stumbling block. When we sort these out, I feel we would have the start of a good platform to start experimenting. Mark. From fdrake at cnri.reston.va.us Thu Apr 22 16:47:35 1999 From: fdrake at cnri.reston.va.us (Fred L. Drake) Date: Thu, 22 Apr 1999 10:47:35 -0400 (EDT) Subject: [Python-Dev] Notice of intent: rich comparisons In-Reply-To: <16290078@toto.iv> Message-ID: <14111.13959.211874.750734@weyr.cnri.reston.va.us> David Beazley writes: > Maybe I'm just lucky, but I've written nothing but ANSI C for the last > 8 years and have never had a problem compiling it on any machine. I > don't see this as being a huge issue. Wasn't SunOS 4.x the problem child here? There are still a lot of people using these systems, for reasons that aren't clear to me. (Did support for some older hardware get dropped? Sounds like the most reasonable reason to use the old OS is legacy hardware.) -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From bwarsaw at cnri.reston.va.us Thu Apr 22 17:37:46 1999 From: bwarsaw at cnri.reston.va.us (Barry A. Warsaw) Date: Thu, 22 Apr 1999 11:37:46 -0400 (EDT) Subject: [Python-Dev] Notice of intent: rich comparisons References: <16290078@toto.iv> <14111.13959.211874.750734@weyr.cnri.reston.va.us> Message-ID: <14111.16970.839894.147748@anthem.cnri.reston.va.us> >>>>> "Fred" == Fred L Drake writes: Fred> Wasn't SunOS 4.x the problem child here? There are still Fred> a lot of people using these systems, for reasons that aren't Fred> clear to me. (Did support for some older hardware get Fred> dropped? Sounds like the most reasonable reason to use the Fred> old OS is legacy hardware.) There might be, but the bundled compiler in SunOS 4 was never intended to be used for anything more than recompiling the kernel. Years ago, I had conversations with Sun engineers who claimed that no bug in the bundled compiler was ever fixed unless it directly impacted on kernel rebuilds. Even back then they recommended using something other than the bundled crufty old K&R compiler for building all other stuff, and this was when there was that huge hoopla over the unbundling of the compiler. SunOS 4 users can probably be mostly satisfied with gcc. -Barry From fdrake at cnri.reston.va.us Thu Apr 22 17:42:57 1999 From: fdrake at cnri.reston.va.us (Fred L. Drake) Date: Thu, 22 Apr 1999 11:42:57 -0400 (EDT) Subject: [Python-Dev] Notice of intent: rich comparisons In-Reply-To: <14111.16970.839894.147748@anthem.cnri.reston.va.us> References: <16290078@toto.iv> <14111.13959.211874.750734@weyr.cnri.reston.va.us> <14111.16970.839894.147748@anthem.cnri.reston.va.us> Message-ID: <14111.17281.999490.718527@weyr.cnri.reston.va.us> Barry A. Warsaw writes: > There might be, but the bundled compiler in SunOS 4 was never intended > to be used for anything more than recompiling the kernel. Years ago, ... > SunOS 4 users can probably be mostly satisfied with gcc. Barry, This is good enough for me. I'd certainly rather avoid K&R C! -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From skip at mojam.com Thu Apr 22 19:18:39 1999 From: skip at mojam.com (skip at mojam.com) Date: Thu, 22 Apr 1999 13:18:39 -0400 (EDT) Subject: [Python-Dev] Notice of intent: rich comparisons In-Reply-To: <14111.17281.999490.718527@weyr.cnri.reston.va.us> References: <16290078@toto.iv> <14111.13959.211874.750734@weyr.cnri.reston.va.us> <14111.16970.839894.147748@anthem.cnri.reston.va.us> <14111.17281.999490.718527@weyr.cnri.reston.va.us> Message-ID: <14111.22873.161727.15206@cm-29-94-14.nycap.rr.com> Barry> SunOS 4 users can probably be mostly satisfied with gcc. Fred> This is good enough for me. I'd certainly rather avoid K&R C! Besides, aren't there tools available that can strip most of the ANSI-ness out of ANSI C? (Un)Protoize? For those (few?) people who are really still stuck using a K&R compiler I would think those tools, perhaps supplemented with some patch files maintained outside the main Python source tree, would be sufficient. Skip Montanaro | Mojam: "Uniting the World of Music" http://www.mojam.com/ skip at mojam.com | Musi-Cal: http://www.musi-cal.com/ 518-372-5583 From bwarsaw at cnri.reston.va.us Thu Apr 22 20:07:57 1999 From: bwarsaw at cnri.reston.va.us (Barry A. Warsaw) Date: Thu, 22 Apr 1999 14:07:57 -0400 (EDT) Subject: [Python-Dev] Notice of intent: rich comparisons References: <16290078@toto.iv> <14111.13959.211874.750734@weyr.cnri.reston.va.us> <14111.16970.839894.147748@anthem.cnri.reston.va.us> <14111.17281.999490.718527@weyr.cnri.reston.va.us> <14111.22873.161727.15206@cm-29-94-14.nycap.rr.com> Message-ID: <14111.25981.74738.355264@anthem.cnri.reston.va.us> >>>>> "skip" == writes: skip> Besides, aren't there tools available that can strip most of skip> the ANSI-ness out of ANSI C? (Un)Protoize? I think so. Seems I have unprotoize already; probably got it for free with gcc, or some other GNU tool. -B From skip at mojam.com Thu Apr 22 20:22:51 1999 From: skip at mojam.com (skip at mojam.com) Date: Thu, 22 Apr 1999 14:22:51 -0400 (EDT) Subject: [Python-Dev] Notice of intent: rich comparisons In-Reply-To: <371E4746.22A84506@lemburg.com> References: <199904211904.PAA14966@eric.cnri.reston.va.us> <371E4746.22A84506@lemburg.com> Message-ID: <14111.23085.737365.582406@cm-29-94-14.nycap.rr.com> mal> There's some good work out there by Skip Montanaro to revamp the VM mal> into a combined register/stack machine. He calls it rattlesnake. mal> More infos can be found in the list archive (it's currently mal> sleeping): Thanks to Marc-Andre for mentioning this. Rattlesnake is indeed sleeping at the moment. If anyone is interested in the idea I'd be happy to awaken it. The main observation was that much of the virtual machine's activity is pushing/popping objects to/from the stack. By treating a chunk of storage as a register file much of that churn can be avoided. Skip Montanaro | Mojam: "Uniting the World of Music" http://www.mojam.com/ skip at mojam.com | Musi-Cal: http://www.musi-cal.com/ 518-372-5583 From fredrik at pythonware.com Fri Apr 23 09:48:14 1999 From: fredrik at pythonware.com (Fredrik Lundh) Date: Fri, 23 Apr 1999 09:48:14 +0200 Subject: [Python-Dev] Compiling ANSI C on K&R compilers References: <16290078@toto.iv><14111.13959.211874.750734@weyr.cnri.reston.va.us><14111.16970.839894.147748@anthem.cnri.reston.va.us><14111.17281.999490.718527@weyr.cnri.reston.va.us> <14111.22873.161727.15206@cm-29-94-14.nycap.rr.com> Message-ID: <00df01be8d5d$a82b2f70$f29b12c2@pythonware.com> > Besides, aren't there tools available that can strip most of the ANSI-ness > out of ANSI C? (Un)Protoize? For those (few?) people who are really still > stuck using a K&R compiler I would think those tools, perhaps supplemented > with some patch files maintained outside the main Python source tree, would > be sufficient. I mentioned ansi2knr.c in an earlier post. It's a small utility, and can be distributed with the Python core (it's GPL'd, but since it isn't linked with Python, that's not a problem). this is used by ghostscript and the ijg jpeg library, among others: ftp://ftp.cs.wisc.edu/ghost/ansi2knr.c (or via http://www.cs.wisc.edu/~ghost/) Cheers /F fredrik at pythonware.com http://www.pythonware.com From gstein at lyra.org Fri Apr 23 12:37:02 1999 From: gstein at lyra.org (Greg Stein) Date: Fri, 23 Apr 1999 03:37:02 -0700 Subject: [Python-Dev] Notice of intent: rich comparisons References: <199904211904.PAA14966@eric.cnri.reston.va.us> Message-ID: <37204D4E.2C02ABE2@lyra.org> Guido van Rossum wrote: >... > Import revamp > > It should be much easier to add hooks to allow importing > from zip files, from a URL, etc., or (different) hooks to > allow looking for different extensions (e.g. to automatically > generate ILU stubs). This should help the small platforms > too, since they often don't have a filesystem, so their > imports will have to come from some other place. I would recommend that Python's import mechanism be changed to use some of the concepts from my imputil.py module and in a couple of my posts to distutils-sig: http://www.python.org/pipermail/distutils-sig/1999-January/000142.html http://www.python.org/pipermail/distutils-sig/1998-December/000077.html > ANSI C > > I'm tired of supporting K&R C. All code should be converted > to using prototypes. The Py_PROTO macros should go. We can > add const-correctness to all code. Too bad for platforms > without decent compilers (let them get GCC). Or those platforms can stick with Python 1.5.2 > Misc > > Jeremy Hylton's urllib2.py > > Greg Stein's new httplib.py (or Jeremy's?) Mine is a drop-in replacement for the current httplib.py. httplib.HTTP is compatible with the current version and does HTTP/1.0. httplib.HTTPConnection is similar to the other (but (IMO) cleans up a few elements of the API); it does HTTP/1.1, including persistent connections. This module follows the design of the original httplib.py much more closely. Jeremy's module uses a very different design approach (no value judgement here; it's just different); also, it simply copies over the old HTTP class, while mine derives the compatible version from HTTPConnection. I'm not sure how much testing Jeremy's has had, but I use my module for all Python-based http work now. Some number of other people have downloaded and used it, too. I would recommend my new module, given the two options. I'll eventually have a davlib.py to add to the distribution, but it needs more work. I'll contribute that later. --- I'd also like to see some cleanup of the build process. For example, (Guido:) I sent in a different way to handle the signal stuff (shifting files around and stuff) as opposed to the "hassignal" thing. About the build process: it may be nice to move to a single makefile. Here is an interesting paper about this: http://www.canb.auug.org.au/~millerp/rmch/recu-make-cons-harm.html Is it reasonable to split out the Demo, Doc, Misc, and Tools subdirs since those never really end up as part of an installed Python? e.g. into a python-extras distribution? (which would allow doc and tools updates at arbitrary times) Does it make sense to remove platform-specific modules? (e.g. the SGI modules) While distutils doesn't have anything *yet*, there are changes that can be made in the build process to improve the distutils process. I know that Greg Ward wants distutils to work on previous versions of Python, but (IMO) things would be simpler all around if distutils-based packages were simply designed for 1.6 systems as a basic dependency. However, that choice is quite separate from the decision to generate distutils support during the build. Oh: there were some things floating around at one point about using Python itself within the build process (e.g. for modules). Is any of that work useful? Cheers, -g -- Greg Stein, http://www.lyra.org/ From fdrake at cnri.reston.va.us Fri Apr 23 15:28:12 1999 From: fdrake at cnri.reston.va.us (Fred L. Drake) Date: Fri, 23 Apr 1999 09:28:12 -0400 (EDT) Subject: [Python-Dev] Notice of intent: rich comparisons In-Reply-To: <37204D4E.2C02ABE2@lyra.org> References: <199904211904.PAA14966@eric.cnri.reston.va.us> <37204D4E.2C02ABE2@lyra.org> Message-ID: <14112.30060.552422.975547@weyr.cnri.reston.va.us> Greg Stein writes: > Is it reasonable to split out the Demo, Doc, Misc, and Tools subdirs > since those never really end up as part of an installed Python? e.g. > into a python-extras distribution? (which would allow doc and tools > updates at arbitrary times) The Doc/ stuff is already in a separate distribution; this has been in place for about a year (if I recall correctly). I try to make doc releases shortly after Python releases (I think the 1.5.2 doc release is the longest I've waited past the Python release so far, and it may end up being next week), and I have made interim releases as the documentation has grown. I certainly think that doing something similar for the Demo/ and Tools/ directories would be reasonable; they could share a single distribution. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From skip at mojam.com Fri Apr 23 15:59:02 1999 From: skip at mojam.com (skip at mojam.com) Date: Fri, 23 Apr 1999 09:59:02 -0400 (EDT) Subject: [Python-Dev] Notice of intent: rich comparisons In-Reply-To: <14112.30060.552422.975547@weyr.cnri.reston.va.us> References: <199904211904.PAA14966@eric.cnri.reston.va.us> <37204D4E.2C02ABE2@lyra.org> <14112.30060.552422.975547@weyr.cnri.reston.va.us> Message-ID: <14112.31858.374462.469793@cm-29-94-14.nycap.rr.com> Fred> I certainly think that doing something similar for the Demo/ and Fred> Tools/ directories would be reasonable; they could share a single Fred> distribution. We need to make sure none of the tools are needed in the install process. h2py comes to mind. Skip Montanaro | Mojam: "Uniting the World of Music" http://www.mojam.com/ skip at mojam.com | Musi-Cal: http://www.musi-cal.com/ 518-372-5583 From jeremy at cnri.reston.va.us Mon Apr 26 17:26:28 1999 From: jeremy at cnri.reston.va.us (Jeremy Hylton) Date: Mon, 26 Apr 1999 11:26:28 -0400 (EDT) Subject: [Python-Dev] Notice of intent: rich comparisons In-Reply-To: <37204D4E.2C02ABE2@lyra.org> References: <199904211904.PAA14966@eric.cnri.reston.va.us> <37204D4E.2C02ABE2@lyra.org> Message-ID: <14116.33341.371508.53071@bitdiddle.cnri.reston.va.us> >>>>> "GS" == Greg Stein writes: >> Greg Stein's new httplib.py (or Jeremy's?) GS> Mine is a drop-in replacement for the current GS> httplib.py. httplib.HTTP is compatible with the current version GS> and does HTTP/1.0. httplib.HTTPConnection is similar to the GS> other (but (IMO) cleans up a few elements of the API); it does GS> HTTP/1.1, including persistent connections. This module follows GS> the design of the original httplib.py much more GS> closely. Jeremy's module uses a very different design approach GS> (no value judgement here; it's just different); also, it simply GS> copies over the old HTTP class, while mine derives the GS> compatible version from HTTPConnection. I'm not sure how much GS> testing Jeremy's has had, but I use my module for all GS> Python-based http work now. Some number of other people have GS> downloaded and used it, too. GS> I would recommend my new module, given the two options. I think I agree. I stopped working on my version quite some time ago, before I made enough progress to make it useful. Thus, it makes a lot of sense to use Greg's working code. I'd be curious to see how to use HTTPConnection to do persistent connections and pipelined requests. It wasn't entirely clear from the code what I would need to do to keep the connection open. Do you just re-use the HTTPConnection object -- call putrequest again after getreply? I like the revised API that Greg's code uses. The request method on HTTPConnection objects cleans the API up in exactly the right way. It has always seemed unnecessary to have many separate calls to add headers and then a call to endheaders after putrequest. Packaging them all together in one method will simplify client code a lot. GS> I'll eventually have a davlib.py to add to the distribution, but GS> it needs more work. I'll contribute that later. Cool! Jeremy From guido at CNRI.Reston.VA.US Mon Apr 26 18:16:11 1999 From: guido at CNRI.Reston.VA.US (Guido van Rossum) Date: Mon, 26 Apr 1999 12:16:11 -0400 Subject: [Python-Dev] Public or private python-dev archives? Message-ID: <199904261616.MAA22036@eric.cnri.reston.va.us> In a private mail, Greg Stein suggested that the python-dev archives should be restricted to the members of the list. I prefer to make them public, but I won't want to impose this on others without discussion. So I've made the archives private for the time being while we discuss this meta-issue. (Also, the existence of the list isn't announced by mailman on its listinfo page.) Here's my argument for open archives. I don't think that we have anything to hide from the public -- I think of us as a technical forum whose discussions may affect others (e.g. Python users) and I think it's often useful for those others to be able to see what we've said. I want to keep membership of the list closed as a gentle way to enforce focus and quality of discussion. Jeremy pointed out that there's no restiction on posting, and mentioned that together with open archives this makes the list just as open as an open-subscription list. I don't see this equivalence -- certainly it makes a difference in practice, and the open posting is simply a mechanism to allow members with multiple email addresses to post from whereever they are. If we regularly get spammed or find the list is targeted by angry Python users we might have to restrict posting to members (and deal with the multiple address problem). I hope the discussion about this issue will be short (otherwise it would detract from the real goal of this list). I'll follow the desire of the majority of current members; once we have a decision I propose to stick with it and simply present new members with the facts. --Guido van Rossum (home page: http://www.python.org/~guido/) From gward at cnri.reston.va.us Mon Apr 26 18:30:43 1999 From: gward at cnri.reston.va.us (Greg Ward) Date: Mon, 26 Apr 1999 12:30:43 -0400 Subject: [Python-Dev] Public or private python-dev archives? In-Reply-To: <199904261616.MAA22036@eric.cnri.reston.va.us>; from Guido van Rossum on Mon, Apr 26, 1999 at 12:16:11PM -0400 References: <199904261616.MAA22036@eric.cnri.reston.va.us> Message-ID: <19990426123042.A2617@cnri.reston.va.us> On 26 April 1999, Guido van Rossum said: > In a private mail, Greg Stein suggested that the python-dev archives > should be restricted to the members of the list. I prefer to make > them public, but I won't want to impose this on others without > discussion. So I've made the archives private for the time being > while we discuss this meta-issue. (Also, the existence of the list > isn't announced by mailman on its listinfo page.) > > Here's my argument for open archives. I don't think that we have > anything to hide from the public -- I think of us as a technical forum > whose discussions may affect others (e.g. Python users) and I think > it's often useful for those others to be able to see what we've said. I favour as much openness as possible that's consistent with high signal-to-noise. Opening the archives doesn't affect SN ratio; for that matter, neither does allowing anyone to *read* the list while keeping posting privileges restricted. And letting the world know that the list exists -- even though posting privileges are restricted -- shouldn't affect quality. So I guess my position is: definitely open the archives and publicise the list -- the benefit of an open archive is reduced if people can't stumble across it like they can any sig. And consider the possibility of open subscription while keeping posting restricted. Not sure how easy that is with Mailman, but we can still consider the idea. The open, friendly nature of the Python community is a huge strength. I tentatively agree that posting privileges should be restricted to keep quality high, but the idea of a "secret cabal" discussing Python development off in a dark corner away from the grubby masses seems very counter to the spirit I've seen so far. Greg -- Greg Ward - software developer gward at cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913 From da at ski.org Mon Apr 26 18:29:56 1999 From: da at ski.org (David Ascher) Date: Mon, 26 Apr 1999 09:29:56 -0700 (Pacific Daylight Time) Subject: [Python-Dev] Public or private python-dev archives? In-Reply-To: <199904261616.MAA22036@eric.cnri.reston.va.us> Message-ID: On Mon, 26 Apr 1999, Guido van Rossum wrote: > In a private mail, Greg Stein suggested that the python-dev archives > should be restricted to the members of the list. I prefer to make > them public, but I won't want to impose this on others without > discussion. So I've made the archives private for the time being > while we discuss this meta-issue. (Also, the existence of the list > isn't announced by mailman on its listinfo page.) If one has a public archive with restricted membership, then one needs to have a process for people to petition membership, including policies on deciding admission (which could be as vague as "up to GvR's whim"). FWIW, the perl5-porters list is open but the perl6-porters list is closed. My suggestion is that we can start with an open policy on archives, and the lax posting policy for the multiple email address business (which should be incorporated in mailman++ =), with the explicitely stated caveat that if it turns out that that policy doesn't work, we reserve the right to tighten things up. I also suggest that we don't advertise the fact that anyone can post. [Except of course that we've just mentioned this in archives which I'm arguing should be public =)] --david From bwarsaw at cnri.reston.va.us Mon Apr 26 19:44:36 1999 From: bwarsaw at cnri.reston.va.us (Barry A. Warsaw) Date: Mon, 26 Apr 1999 13:44:36 -0400 (EDT) Subject: [Python-Dev] Public or private python-dev archives? References: <199904261616.MAA22036@eric.cnri.reston.va.us> <19990426123042.A2617@cnri.reston.va.us> Message-ID: <14116.42500.284907.569281@anthem.cnri.reston.va.us> >>>>> "GW" == Greg Ward writes: GW> And consider the possibility of open subscription while GW> keeping posting restricted. Not sure how easy that is with GW> Mailman, but we can still consider the idea. It could be done in a number of ways. You could restrict postings to members only, but as Guido has pointed out, a lot of people post from more than one account and Mailman doesn't handle that very well yet. Or you could moderate the list, but then someone has to approve postings and that's more work than I think anybody wants to do. I'm also for an open-as-possible policy, with the right to restrict later if the s/n gets too low. I sort of view Python-dev to be the place that serious c.l.py proposals get fleshed out and implementation strategies discussed. The (hopefully) high level of technical detail on the list should self-select. -Barry From gmcm at hypernet.com Mon Apr 26 20:56:52 1999 From: gmcm at hypernet.com (Gordon McMillan) Date: Mon, 26 Apr 1999 13:56:52 -0500 Subject: [Python-Dev] Public or private python-dev archives? In-Reply-To: <14116.42500.284907.569281@anthem.cnri.reston.va.us> Message-ID: <1286969269-56980208@hypernet.com> [Barry] > The (hopefully) high level of > technical detail on the list should self-select. I thought the humor did that. If the public-archive were only updated weekly, it would make it's use (or abuse) as glorified help list pretty tenuous. No one has espoused Greg's reasoning. In the abscense of said arguments, I'm certainly inclined to vote for "as public as can be and still be focused". -OTOH-then-I'll-never-know-what-goes-on-in-the-smoke-filled-room-ly y'rs - Gordon From da at ski.org Mon Apr 26 21:12:54 1999 From: da at ski.org (David Ascher) Date: Mon, 26 Apr 1999 12:12:54 -0700 (Pacific Daylight Time) Subject: [Python-Dev] Why unbundle Tools and Demo? Message-ID: Several people argue for unbundling Tools/ and Demo/ in 1.6. I'd like to argue to leave them in. They're not especially big, and IMHO they are quite valuable, *especially* to the novice user. In fact, I'd like to argue that Demo/ should be promoted to the same status as Tools/ (by which I mean included in the Windows binary distribution). Unbundling Tools/ would mean unbundling IDLE, which IMHO would be a big strategic mistake. However, I wouldn't be against a cleanup of said directories. Some things should probably be removed (anything which uses stdwin), some of the code in classes is showing its age (notes about "being upgraded for Python 1.1" =), etc. That said, the tkinter/ directory is the best place to look for simple Tkinter code, and should be included, IMHO. --david From guido at CNRI.Reston.VA.US Mon Apr 26 21:20:26 1999 From: guido at CNRI.Reston.VA.US (Guido van Rossum) Date: Mon, 26 Apr 1999 15:20:26 -0400 Subject: [Python-Dev] Why unbundle Tools and Demo? In-Reply-To: Your message of "Mon, 26 Apr 1999 12:12:54 PDT." References: Message-ID: <199904261920.PAA22415@eric.cnri.reston.va.us> > Several people argue for unbundling Tools/ and Demo/ in 1.6. I'd like to > argue to leave them in. They're not especially big, and IMHO they are > quite valuable, *especially* to the novice user. In fact, I'd like to > argue that Demo/ should be promoted to the same status as Tools/ (by which > I mean included in the Windows binary distribution). Unbundling Tools/ > would mean unbundling IDLE, which IMHO would be a big strategic mistake. > > However, I wouldn't be against a cleanup of said directories. Some things > should probably be removed (anything which uses stdwin), some of the code > in classes is showing its age (notes about "being upgraded for Python 1.1" > =), etc. That said, the tkinter/ directory is the best place to look for > simple Tkinter code, and should be included, IMHO. Agreed. One simple thing that would help me immensely would be for someone to go through all the various Demo directories and make an inventary of what is there and how useful it is, (1) to all Python users, (2) to Windows users. Then, perhaps someone could write a simple document making these files (and Tools) more accessible... --Guido van Rossum (home page: http://www.python.org/~guido/) From da at ski.org Mon Apr 26 21:20:40 1999 From: da at ski.org (David Ascher) Date: Mon, 26 Apr 1999 12:20:40 -0700 (Pacific Daylight Time) Subject: [Python-Dev] Why unbundle Tools and Demo? In-Reply-To: <199904261920.PAA22415@eric.cnri.reston.va.us> Message-ID: > someone to go through all the various Demo directories and make an > inventary of what is there and how useful it is, (1) to all Python > users, (2) to Windows users. Then, perhaps someone could write a > simple document making these files (and Tools) more accessible... Ok. I can do that. From guido at CNRI.Reston.VA.US Mon Apr 26 21:22:55 1999 From: guido at CNRI.Reston.VA.US (Guido van Rossum) Date: Mon, 26 Apr 1999 15:22:55 -0400 Subject: [Python-Dev] Why unbundle Tools and Demo? In-Reply-To: Your message of "Mon, 26 Apr 1999 12:20:40 PDT." References: Message-ID: <199904261922.PAA22447@eric.cnri.reston.va.us> [me] > > someone to go through all the various Demo directories and make an > > inventary of what is there and how useful it is, (1) to all Python > > users, (2) to Windows users. Then, perhaps someone could write a > > simple document making these files (and Tools) more accessible... [Dave] > Ok. I can do that. Great! I didn't mean to volunteer you -- but I think you'd do a great job. --Guido van Rossum (home page: http://www.python.org/~guido/) From tim_one at email.msn.com Tue Apr 27 06:25:19 1999 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 27 Apr 1999 00:25:19 -0400 Subject: [Python-Dev] Public or private python-dev archives? In-Reply-To: <19990426123042.A2617@cnri.reston.va.us> Message-ID: <000501be9065$f5e3db80$ab9e2299@tim> [Greg Ward, arguing in favor of ... a "secret cabal" discussing Python development off in a dark corner away from the grubby masses ] That's what I'd like too -- but somebody already let Gordon in . voting-to-leave-it-public-until-there's-a-problem-ly y'rs - tim From da at ski.org Tue Apr 27 21:23:55 1999 From: da at ski.org (David Ascher) Date: Tue, 27 Apr 1999 12:23:55 -0700 (Pacific Daylight Time) Subject: [Python-Dev] numpy Message-ID: What are the thoughts on NumPy integration into the core? --David From MHammond at skippinet.com.au Wed Apr 28 01:28:59 1999 From: MHammond at skippinet.com.au (Mark Hammond) Date: Wed, 28 Apr 1999 09:28:59 +1000 Subject: [Python-Dev] numpy In-Reply-To: Message-ID: <001c01be9105$bae7ccd0$0801a8c0@bobcat> > What are the thoughts on NumPy integration into the core? he he - and while we are at it :-) mxDateTime would need to be a popular choice for inclusion, and Guido has offered in-principle support for moving some of the Win32 stuff into the core - particularly the Registry stuff and the native Window Handle support... How far do we go :-) Personally, I would simply like to see the distutils SIG solve this problem for us. (sure). Eg, the "build" or "install" process (depending on the OS) could build a local HTML file with knowledge many "common" extensions - a single click, and it is downloaded, configured and built. Oh well, back to reality... [Which isnt to say I am opposed to NumPy and mxDateTime. Definately keen on the win32 stuff tho :-] Mark. From da at ski.org Wed Apr 28 01:31:56 1999 From: da at ski.org (David Ascher) Date: Tue, 27 Apr 1999 16:31:56 -0700 (Pacific Daylight Time) Subject: [Python-Dev] numpy In-Reply-To: <001c01be9105$bae7ccd0$0801a8c0@bobcat> Message-ID: On Wed, 28 Apr 1999, Mark Hammond wrote: > > What are the thoughts on NumPy integration into the core? > > he he - and while we are at it :-) mxDateTime would need to be a popular > choice for inclusion, and Guido has offered in-principle support for moving > some of the Win32 stuff into the core - particularly the Registry stuff and > the native Window Handle support... It may seem strange, but I'll argue for the win32 registry calls before the NumPy stuff. That could be because I've looked at NumPy code and not the win32 code. Not Jim's cleanest code. =) Mark, can you describe 'native Window Handle' support? --david From MHammond at skippinet.com.au Wed Apr 28 07:03:48 1999 From: MHammond at skippinet.com.au (Mark Hammond) Date: Wed, 28 Apr 1999 15:03:48 +1000 Subject: [Python-Dev] numpy In-Reply-To: Message-ID: <001e01be9134$809ca8f0$0801a8c0@bobcat> > It may seem strange, but I'll argue for the win32 registry > calls before > the NumPy stuff. That could be because I've looked at NumPy > code and not > the win32 code. Not Jim's cleanest code. =) he he - and I can even get out of the Win32 stuff - I wrote a string-only first version, and Bill Tutt rehashed it into what it is today, handling all the registry types. OTOH, there could also be a case for moving "win32api" completely to "core status" (whether that means truly core or simply a standard .pyd). For example, ntpath.py now has code that attempts to use "win32api.GetFullPathName()". The down-side is that win32api has nowhere near complete coverage, and is really a mixed bag of bits and pieces. Most later efforts where complete API sets are given coverage have different names - eg, win32file has the complete Win32 file API wrapped up - even if there are overlaps with existing functions in win32api. Im not sure what the answer is - my guess is a new core module with Win32 features deemed absolutely necessary for the core - stuff like the registry, and a few assorted other functions, such as GetFullPathName, but stopping well short of the full win32api set. > Mark, can you describe 'native Window Handle' support? Sure! We have a very light-weight "handle" object, representing a Win32 handle. It has no methods, and a single property for returning the underlying win32 handle as an integer. When the object destructs, it calls "CloseHandle()". Thats about it! It has no methods, so is passed as an argument. There has been no attempt to implement things like "handle.Read()" to represent "ReadFile(handle, ...)". There are 2 reasons for this: 1) Handles are fairly general purpose, and not restricted to IO operations. A handle is also used to represent a Mutex/Semaphores and threads/processes - certainly doesnt make sense to have a "Read()" method for those handles. 2) IMO, this should be done at the .py level anyway. The Win32 Handle support is pure C++ at the moment. A simple complication is that there are 3 types of handles in use at the moment - those that call "CloseHandle", those that call "RegCloseHandle" (registry handles) and a 3rd I cant recall. This is currently implemented using C++ inheritance. But even if the current implementation is not favoured, the object is so small that a rewrite would not be a problem. And for those that can be bothered to read this far, some more background: Some time ago, Greg and I decided to implement a "pywintypes" module. This defines what we considered "core types" for the Win32 world. All our extension modules (including win32api, COM; basically win32*.pyd) use this module. The objects it supports are: Unicode, Handles, Win32 Time, IIDs, Overlapped IO objects, 3 NT security related objects and importantly a standard Win32 exception and functions for filling it. Moving the registry stuff is dependant on the core having the Exception, Handle and Registry support (hence this discussion). We have our own Time object, but mxDateTime would be fine. One day, we hope to remove this pywintypes entirely, as the core will have it all :-) Mark. From gward at cnri.reston.va.us Wed Apr 28 14:51:43 1999 From: gward at cnri.reston.va.us (Greg Ward) Date: Wed, 28 Apr 1999 08:51:43 -0400 Subject: [Python-Dev] numpy In-Reply-To: <001c01be9105$bae7ccd0$0801a8c0@bobcat>; from Mark Hammond on Wed, Apr 28, 1999 at 09:28:59AM +1000 References: <001c01be9105$bae7ccd0$0801a8c0@bobcat> Message-ID: <19990428085143.A5571@cnri.reston.va.us> On 28 April 1999, Mark Hammond said: > How far do we go :-) > > Personally, I would simply like to see the distutils SIG solve this problem > for us. (sure). Eg, the "build" or "install" process (depending on the > OS) could build a local HTML file with knowledge many "common" extensions - > a single click, and it is downloaded, configured and built. Oh well, back > to reality... It's not impossible, it just takes a while. I think it took the Perl community about three years to go from "hey! let's have a standard build mechanism for modules!" to the point where I can install (almost) any module from CPAN with one shell command: perl -MCPAN -e 'install ("MIME::Base64");' which is insanely cool. (It took about two minutes to do the above just now; that included trying two CPAN mirrors that aren't being cooperative this morning, finding one that was working, downloading the current module list from it, determining that there is a more recent version available than the one installed here, downloading it, unpacking it, running "Makefile.PL" to generate the Makefile, running "make" [which compiles any extensions in the distribution, copies all the .pm files around, and generates the documentation], "make test" [run the module's self-test suite], and "make install" [install it in the "site-perl" library directory]. Amount of user interaction required: typing the above command line.) It's *still* rough around the edges, though, especially when building a new installation from scratch -- mainly because Perl doesn't ship with ftp or http libraries, so the CPAN.pm module has to try downloading stuff with lynx, ncftp, or plain ol' ftp until it has downloaded and installed the libnet and libwww-perl distributions. That's one problem we won't have with Python, at least. Oh yeah, and it all works *great* under Unix... but the rest of the world lags behind. Also, two major components of being able to do this -- the Perl Module List and CPAN -- are still vapourware in Python-land. But hey, if we can get to the "we *have* a standard build mechanism for modules!" point, then all the rest becomes a lot more feasible. Pep talk over... Greg -- Greg Ward - software developer gward at cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913 From mal at lemburg.com Wed Apr 28 09:44:25 1999 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 28 Apr 1999 09:44:25 +0200 Subject: [Python-Dev] numpy References: <001c01be9105$bae7ccd0$0801a8c0@bobcat> Message-ID: <3726BC59.35E3C9DB@lemburg.com> Mark Hammond wrote: > > > What are the thoughts on NumPy integration into the core? > > he he - and while we are at it :-) mxDateTime would need to be a popular > choice for inclusion, and Guido has offered in-principle support for moving > some of the Win32 stuff into the core - particularly the Registry stuff and > the native Window Handle support... > > How far do we go :-) > > Personally, I would simply like to see the distutils SIG solve this problem > for us. (sure). Eg, the "build" or "install" process (depending on the > OS) could build a local HTML file with knowledge many "common" extensions - > a single click, and it is downloaded, configured and built. Oh well, back > to reality... You're talking about fast moving targets there... are you sure that you want those in the standard distribution ? Maybe we have two distributions: the standard one and a pro edition with all the slick stuff included (together with a proper setup script to get those references to external libs and include files right). Actually, this is something I've been wanting to do for nearly a year now... just haven't found the time to really get things the way I want them. It's a project called Python Power Tools and includes many generic extensions (currently only ones that don't rely on external libs). If you're interested, have a look at an old version available at: http://starship.skyport.net/~lemburg/PowerTools-0.2.zip It includes the extensions BTree, mxDateTime, mxTools, mxStack, Trie, avl and kjbuckets. NumPy should probably also be included. The current setup uses a recursive Makefile approach (not too elegant, but works). A distutils setup would be much better. -- Marc-Andre Lemburg Y2000: 247 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From jack at oratrix.nl Wed Apr 28 15:48:21 1999 From: jack at oratrix.nl (Jack Jansen) Date: Wed, 28 Apr 1999 15:48:21 +0200 Subject: [Python-Dev] numpy In-Reply-To: Message by "Mark Hammond" , Wed, 28 Apr 1999 09:28:59 +1000 , <001c01be9105$bae7ccd0$0801a8c0@bobcat> Message-ID: <19990428134821.E9A68300F57@snelboot.oratrix.nl> > [...] Guido has offered in-principle support for moving > some of the Win32 stuff into the core - particularly the Registry stuff and > the native Window Handle support... I think it would be nice to put all the stuff that is shared between modules (I think that's only PyWinTypes, but who am I to think I have a clue about the windows port:-) into the core. I just did the same for MacPython, and it makes life a whole lot easier. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at 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 From skip at mojam.com Wed Apr 28 17:57:40 1999 From: skip at mojam.com (skip at mojam.com) Date: Wed, 28 Apr 1999 11:57:40 -0400 Subject: [Python-Dev] LLNL C++ as base for Python 2? Message-ID: <199904281557.LAA06491@cm-29-94-14.nycap.rr.com> Have we been talking about Python 2 or Python 1.6? If we're talking about Python 2, has anyone given a serious look at the LLNL gang's C++/Python stuff? If I recall Paul Dubois' talk at the last conference, it sounded like their work made it much easier to implement extension modules. Skip Montanaro | Mojam: "Uniting the World of Music" http://www.mojam.com/ skip at mojam.com | Musi-Cal: http://www.musi-cal.com/ 518-372-5583 From guido at CNRI.Reston.VA.US Wed Apr 28 18:06:03 1999 From: guido at CNRI.Reston.VA.US (Guido van Rossum) Date: Wed, 28 Apr 1999 12:06:03 -0400 Subject: [Python-Dev] LLNL C++ as base for Python 2? In-Reply-To: Your message of "Wed, 28 Apr 1999 11:57:40 EDT." <199904281557.LAA06491@cm-29-94-14.nycap.rr.com> References: <199904281557.LAA06491@cm-29-94-14.nycap.rr.com> Message-ID: <199904281606.MAA27526@eric.cnri.reston.va.us> > Have we been talking about Python 2 or Python 1.6? If we're talking about > Python 2, has anyone given a serious look at the LLNL gang's C++/Python > stuff? If I recall Paul Dubois' talk at the last conference, it sounded > like their work made it much easier to implement extension modules. I've mostly had 1.6 in mind. See recent traffic in the C++ SIG archives for the status of Paul's CXX. --Guido van Rossum (home page: http://www.python.org/~guido/) From da at ski.org Wed Apr 28 19:24:00 1999 From: da at ski.org (David Ascher) Date: Wed, 28 Apr 1999 10:24:00 -0700 (Pacific Daylight Time) Subject: [Python-Dev] LLNL C++ as base for Python 2? In-Reply-To: <199904281606.MAA27526@eric.cnri.reston.va.us> Message-ID: On Wed, 28 Apr 1999, Guido van Rossum wrote: > > Have we been talking about Python 2 or Python 1.6? If we're talking about > > Python 2, has anyone given a serious look at the LLNL gang's C++/Python > > stuff? If I recall Paul Dubois' talk at the last conference, it sounded > > like their work made it much easier to implement extension modules. > > I've mostly had 1.6 in mind. See recent traffic in the C++ SIG > archives for the status of Paul's CXX. Recent traffic? There's nothing in there that's substantive since... uh, well, I got tired of looking back. =) CXX is very cool, but it is still pushing the envelope of many C++ compilers. From what I gather, recent egcs' do manage with it, and since egcs is going to replace gcc, I expect that many platforms will be able to "do" CXX relatively soon. I vote to stay on the 1.6 track for now. From MHammond at skippinet.com.au Fri Apr 30 04:40:09 1999 From: MHammond at skippinet.com.au (Mark Hammond) Date: Fri, 30 Apr 1999 12:40:09 +1000 Subject: [Python-Dev] More flexible namespaces. Message-ID: <008d01be92b2$c56ef5d0$0801a8c0@bobcat> 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 ), 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. From guido at CNRI.Reston.VA.US Fri Apr 30 05:00:52 1999 From: guido at CNRI.Reston.VA.US (Guido van Rossum) Date: Thu, 29 Apr 1999 23:00:52 -0400 Subject: [Python-Dev] More flexible namespaces. In-Reply-To: Your message of "Fri, 30 Apr 1999 12:40:09 +1000." <008d01be92b2$c56ef5d0$0801a8c0@bobcat> References: <008d01be92b2$c56ef5d0$0801a8c0@bobcat> Message-ID: <199904300300.XAA00608@eric.cnri.reston.va.us> > 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. I agree that this would be seriously cool. It will definitely be in Python 2.0; it's already in JPython. Quite a while ago, Ian Castleden sent me patches for 1.5.1 to do this. It was a lot of code and I was indeed worried about slowing things down too much (and also about checking that he got all the endcases right). Ian did benchmarks and found that the new code was consistently slower, by 3-6%. Perhaps for Python 1.6 this will be acceptable (the "Python IS slow" thread notwithstanding :-); or perhaps someone can have a look at it and squeeze some more time out of it? I'll gladly forward the patches. --Guido van Rossum (home page: http://www.python.org/~guido/) From da at ski.org Fri Apr 30 05:21:04 1999 From: da at ski.org (David Ascher) Date: Thu, 29 Apr 1999 20:21:04 -0700 (Pacific Daylight Time) Subject: [Python-Dev] More flexible namespaces. In-Reply-To: <199904300300.XAA00608@eric.cnri.reston.va.us> Message-ID: > > 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. > > I agree that this would be seriously cool. It will definitely be in > Python 2.0; it's already in JPython. Seriously cool is an understatement. --david From MHammond at skippinet.com.au Fri Apr 30 06:13:25 1999 From: MHammond at skippinet.com.au (Mark Hammond) Date: Fri, 30 Apr 1999 14:13:25 +1000 Subject: [Python-Dev] More flexible namespaces. In-Reply-To: <199904300300.XAA00608@eric.cnri.reston.va.us> Message-ID: <009001be92bf$cb998f80$0801a8c0@bobcat> > Ian did benchmarks and found that the new code was consistently > slower, by 3-6%. Perhaps for Python 1.6 this will be acceptable (the > "Python IS slow" thread notwithstanding :-); or perhaps someone can As long as we get someone working on a consistent 3-6% speedup in other areas this wont be a problem :-) I will attach it to my long list - but Im going to put all my efforts here into Unicode first, and probably the threading stuff second :-) Mark. From tismer at appliedbiometrics.com Fri Apr 30 09:49:42 1999 From: tismer at appliedbiometrics.com (Christian Tismer) Date: Fri, 30 Apr 1999 09:49:42 +0200 Subject: [Python-Dev] More flexible namespaces. References: <008d01be92b2$c56ef5d0$0801a8c0@bobcat> <199904300300.XAA00608@eric.cnri.reston.va.us> Message-ID: <37296096.D0C9C2CC@appliedbiometrics.com> Guido van Rossum wrote: ... > Ian did benchmarks and found that the new code was consistently > slower, by 3-6%. Perhaps for Python 1.6 this will be acceptable (the > "Python IS slow" thread notwithstanding :-); or perhaps someone can > have a look at it and squeeze some more time out of it? I'll gladly > forward the patches. I'd really like to look into that. Also I wouldn't worry too much about speed, since this is such a cool feature. It might even be a speedup in some cases which otherwise would need more complex handling. May I have a look? ciao - chris -- Christian Tismer :^) 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 From mal at lemburg.com Fri Apr 30 10:22:46 1999 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 30 Apr 1999 10:22:46 +0200 Subject: [Python-Dev] More flexible namespaces. References: <008d01be92b2$c56ef5d0$0801a8c0@bobcat> Message-ID: <37296856.5875AAAF@lemburg.com> Mark Hammond wrote: > > 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 involves a whole lot of changes: not only in the Python core, but also in extensions that rely on having real dictionaries available. Since you put out to objectives, I'd like to propose a little different approach... 1. Have eval/exec accept any mapping object as input 2. Make those two copy the content of the mapping object into real dictionaries 3. Provide a hook into the dictionary implementation that can be used to redirect KeyErrors and use that redirection to forward the request to the original mapping objects > This would give us 2 seriously cool features (that I want ), 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. This is covered by 1 and 2. > * 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. This is something for 3. I guess it wouldn't cause any significant slow-down and can be imlemented with much less code than the "change all PyDict_GetItem to PyObject_GetItem" thingie. The real thing could then be done for 2.0 where PyDict_Check() would presumably not rely on an adress but some kind of inheritance scheme indicating that the object is in fact a dictionary. Cheers, -- Marc-Andre Lemburg Y2000: 245 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From guido at CNRI.Reston.VA.US Fri Apr 30 17:17:20 1999 From: guido at CNRI.Reston.VA.US (Guido van Rossum) Date: Fri, 30 Apr 1999 11:17:20 -0400 Subject: [Python-Dev] More flexible namespaces. In-Reply-To: Your message of "Fri, 30 Apr 1999 09:49:42 +0200." <37296096.D0C9C2CC@appliedbiometrics.com> References: <008d01be92b2$c56ef5d0$0801a8c0@bobcat> <199904300300.XAA00608@eric.cnri.reston.va.us> <37296096.D0C9C2CC@appliedbiometrics.com> Message-ID: <199904301517.LAA01422@eric.cnri.reston.va.us> > From: Christian Tismer > I'd really like to look into that. > Also I wouldn't worry too much about speed, since this is > such a cool feature. It might even be a speedup in some cases > which otherwise would need more complex handling. > > May I have a look? Sure! (I've forwarded Christian the files per separate mail.) I'm also interested in your opinion on how well thought-out and robust the patches are -- I've never found the time to do a good close reading of them. --Guido van Rossum (home page: http://www.python.org/~guido/) From gmcm at hypernet.com Fri Apr 30 18:32:30 1999 From: gmcm at hypernet.com (Gordon McMillan) Date: Fri, 30 Apr 1999 11:32:30 -0500 Subject: [Python-Dev] More flexible namespaces. In-Reply-To: <199904301517.LAA01422@eric.cnri.reston.va.us> References: Your message of "Fri, 30 Apr 1999 09:49:42 +0200." <37296096.D0C9C2CC@appliedbiometrics.com> Message-ID: <1286632328-77246936@hypernet.com> Guido wrote: > > From: Christian Tismer > > > I'd really like to look into that. > > Also I wouldn't worry too much about speed, since this is ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > such a cool feature. It might even be a speedup in some cases > > which otherwise would need more complex handling. > > > > May I have a look? > > Sure! > > (I've forwarded Christian the files per separate mail.) I don't know who you sent that to, but it couldn't possibly have been Christian! - Gordon From tismer at appliedbiometrics.com Fri Apr 30 17:57:09 1999 From: tismer at appliedbiometrics.com (Christian Tismer) Date: Fri, 30 Apr 1999 17:57:09 +0200 Subject: [Python-Dev] More flexible namespaces. References: <008d01be92b2$c56ef5d0$0801a8c0@bobcat> <199904300300.XAA00608@eric.cnri.reston.va.us> <37296096.D0C9C2CC@appliedbiometrics.com> <199904301517.LAA01422@eric.cnri.reston.va.us> Message-ID: <3729D2D5.6844D6DA@appliedbiometrics.com> Guido van Rossum wrote: > > > From: Christian Tismer > > May I have a look? > > Sure! > > (I've forwarded Christian the files per separate mail.) Thanks a lot! > I'm also interested in your opinion on how well thought-out and robust > the patches are -- I've never found the time to do a good close > reading of them. Yes, it is quite long and not so very easy to digest. At first glance, most of the changes are replacements of dict access with mapping access where we pay for the extra indirection. It depends on how often this feature will really replace dicts. If dicts are more common, I'd like to figure out how much code bloat extra special casing for dicts would give. Puha - thanks - chris -- Christian Tismer :^) 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 From tismer at appliedbiometrics.com Fri Apr 30 18:19:57 1999 From: tismer at appliedbiometrics.com (Christian Tismer) Date: Fri, 30 Apr 1999 18:19:57 +0200 Subject: [Python-Dev] More flexible namespaces. References: Your message of "Fri, 30 Apr 1999 09:49:42 +0200." <37296096.D0C9C2CC@appliedbiometrics.com> <1286632328-77246936@hypernet.com> Message-ID: <3729D82D.CE16884@appliedbiometrics.com> Gordon McMillan wrote: > > Guido wrote: > > > > From: Christian Tismer > > > > > I'd really like to look into that. > > > Also I wouldn't worry too much about speed, since this is > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > such a cool feature. It might even be a speedup in some cases > > > which otherwise would need more complex handling. > > > > > > May I have a look? > > > > Sure! > > > > (I've forwarded Christian the files per separate mail.) > > I don't know who you sent that to, but it couldn't possibly have been > Christian! :-) :-) truely not if I had'n other things in mind. I know that I will not get more than 30-40 percent by compiling the interpreter away, so I will not even spend time at a register machine right now. Will also not follow the ideas of P2C any longer, doesn't pay off. Instead, If I can manage to create something like static binding snapshots, then I could resolve many of the lookups and internal method indirections, for time critical applications. For all the rest, Python is pretty much fast enough. I've begun to write s special platform dependant version which allows me to do all the things which can't go into the dist. For instance, I just saved some 10 percent by dynamically patching some of the ParseTuple and BuildObject calls out of the core code (ahem). I hope Python will stay as clean as it is, allowing me to try all kinds of tricks for one machine class. ciao - chris.speedy -- Christian Tismer :^) 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 From akuchlin at cnri.reston.va.us Fri Apr 30 18:33:34 1999 From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling) Date: Fri, 30 Apr 1999 12:33:34 -0400 (EDT) Subject: [Python-Dev] More flexible namespaces. In-Reply-To: <3729D82D.CE16884@appliedbiometrics.com> References: <37296096.D0C9C2CC@appliedbiometrics.com> <1286632328-77246936@hypernet.com> <3729D82D.CE16884@appliedbiometrics.com> Message-ID: <14121.55659.754846.708467@amarok.cnri.reston.va.us> Christian Tismer writes: >Instead, If I can manage to create something like static binding >snapshots, then I could resolve many of the lookups and internal >method indirections, for time critical applications. The usual assumption is that the lookups are what takes time. Now, are we sure of that assumption? I'd expect the lookup code to be like: 1) Get hash of name 2) Retrieve object from dictionary 3) Do something with the object. Now, since string objects cache their hash value, 1) should usually be just "if (obj->cached_hash_value!=-1) return obj->cached_hash_value"; a comparision and a return. Step 2) should be very fast, barring a bad hash function. So perhaps most of the time is spent in 3), creating new local dicts, stack frames, and what not. (Yes, I know that doing this on every reference to an object is part of the problem.) I also wonder about the costs of all the Py_BuildValue and Py_ParseTuple calls going on under the hood. A performance improvement project would definitely be a good idea for 1.6, and a good sub-topic for python-dev. Incidentally, what's the verdict on python-dev archives: public or not? -- A.M. Kuchling http://starship.python.net/crew/amk/ Despair says little, and is patient. -- From SANDMAN: "Season of Mists", episode 0 From tismer at appliedbiometrics.com Fri Apr 30 18:55:55 1999 From: tismer at appliedbiometrics.com (Christian Tismer) Date: Fri, 30 Apr 1999 18:55:55 +0200 Subject: [Python-Dev] More flexible namespaces. References: <37296096.D0C9C2CC@appliedbiometrics.com> <1286632328-77246936@hypernet.com> <3729D82D.CE16884@appliedbiometrics.com> <14121.55659.754846.708467@amarok.cnri.reston.va.us> Message-ID: <3729E09B.5F65E3CA@appliedbiometrics.com> "Andrew M. Kuchling" wrote: > > Christian Tismer writes: > >Instead, If I can manage to create something like static binding > >snapshots, then I could resolve many of the lookups and internal > >method indirections, for time critical applications. > > The usual assumption is that the lookups are what takes time. > Now, are we sure of that assumption? I'd expect the lookup code to be > like: > > 1) Get hash of name > 2) Retrieve object from dictionary > 3) Do something with the object. ... Right, but when you become more restrictive, you can do lots, lots more. If I also allow to fix the type of an object, I can go under the hood of the Python API, so you could add some points 4) 5) 6) here. But I shouldn't have talked before I can show something. And at the time, I don't restrict myself to write clean code, but try very machine specific things which I don't believe should go into Python at all. > I also wonder about the costs of all the Py_BuildValue and > Py_ParseTuple calls going on under the hood. A performance > improvement project would definitely be a good idea for 1.6, and a > good sub-topic for python-dev. I wasn't sure, so I first wrote a module which does statistics on that, and I found a lot of these calls. Some are even involved in ceval's code, where things like "(OOOO)" is parsed all over again and again. Now I think this is ok in most cases. But in some places these are very bad: If your builtin function soes so very few work. Take len(): This uses ParseTuple, which calls a function to find out its object, then calls a function to get the object, then takes the len, and builds the result. But since everything has a length, checking for no NULL pointer and grabbing the len produces even shorter code. This applies to many places as well. But right now, I don't change the core, but build hacky little extension modules which squeak such things out at runtime. No big deal yet, but maybe it could pay off to introduce format strings which make them more suitableto be used in macro substitutions. sorry if I was too elaborate, this is so much fun :-) ciao - chris -- Christian Tismer :^) 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 From skip at mojam.com Wed Apr 21 15:17:32 1999 From: skip at mojam.com (skip at mojam.com) Date: Wed, 21 Apr 1999 09:17:32 -0400 Subject: [Python-Dev] ZServer 1.0b1: spurious colon in HTTP response line Message-ID: <199904211317.JAA26167@cm-29-94-14.nycap.rr.com> (Also reported to the bug catcher.) I'm trying to migrate from ZopeHTTPServer to ZServer 1.0b1. I was seeing the ZServer headers turning up in pages generated by the process. When I viewed the page source of the generated HTML I saw: HTTP/1.0: 200 OK Server: Zope/experimental ZServer/1.1b1 Date: Wed, 21 Apr 1999 13:00:38 GMT X-Powered-By: Zope (www.zope.org), Python (www.python.org) Connection: close Content-Type: text/html Content-Length: 7802 Musi-Cal... Concert Schedules: Folk Music, Country Music, Rock Music & more! ... I run ZServer behind an Apache 1.3.3 running mod_proxy. Apparently Apache doesn't recognize the HTTP response when there is a colon following the version number and adds a simple set of headers itself. I guess web browsers either ignore that line or are more lenient in their parsing of the response. The following simple patch corrects the problem: diff -c2 HTTPResponse.py.~1~ HTTPResponse.py *** HTTPResponse.py.~1~ Tue Apr 13 15:21:12 1999 --- HTTPResponse.py Wed Apr 21 09:05:00 1999 *************** *** 146,150 **** # status header must come first. ! append("HTTP/%s: %s" % (self._http_version, status)) if headers.has_key('status'): del headers['status'] --- 146,150 ---- # status header must come first. ! append("HTTP/%s %s" % (self._http_version, status)) if headers.has_key('status'): del headers['status'] *************** Skip Montanaro | Mojam: "Uniting the World of Music" http://www.mojam.com/ skip at mojam.com | Musi-Cal: http://www.musi-cal.com/ 518-372-5583 From da at ski.org Wed Apr 21 20:47:56 1999 From: da at ski.org (David Ascher) Date: Wed, 21 Apr 1999 11:47:56 -0700 (Pacific Daylight Time) Subject: [Python-Dev] Notice of intent: rich comparisons Message-ID: Now that 1.5.2 is finalized, I'll be starting to prepare a patch for the rich comparisons. Guido, how do you envision python-dev working? Do you want to hand out a TODO list for 1.6? --david From guido at CNRI.Reston.VA.US Wed Apr 21 21:04:40 1999 From: guido at CNRI.Reston.VA.US (Guido van Rossum) Date: Wed, 21 Apr 1999 15:04:40 -0400 Subject: [Python-Dev] Notice of intent: rich comparisons In-Reply-To: Your message of "Wed, 21 Apr 1999 11:47:56 PDT." References: Message-ID: <199904211904.PAA14966@eric.cnri.reston.va.us> > Now that 1.5.2 is finalized, I'll be starting to prepare a patch for the > rich comparisons. Cool! > Guido, how do you envision python-dev working? I though we'd just crack Monty Python jokes while pretending to work :-) > Do you want to hand out a TODO list for 1.6? Well, I'm not saying that this is the definitive list, but certainly there are a bunch of things that definitely need to be incorporated. Here's an excerpt of a list that I keep for myself, in no particular order, with brief annotations (I have a meeting in 15 minutes :): Redesign thread/init APIs See the recent discussion in the thread-sig. There should be some kind of micro-init that initializes essential components (including the thread lock!) but doesn't create an interpreter or a threadstate object. There should also be a notion of a default interpreter. Break up into VM, parser, import, mainloop, and other components? The porting efforts to seriously small machines (Win/CE, Pilot, etc.) all seem to need a Python VM that doesn't automatically pull in the parser and interactive main loop. There are other reasons as well to isolate various parts of the functionality (including all numeric data types except ints). This could include: restructuring of the parser so codeop.py can be simplified; making the interactive main loop a script. String methods Barry has his patches ready. Unicode What is the status of /F's latest attempts? Rich comparisons This is Dave's plan. Coercions Marc-Andre Lemburg has some good suggestions here: http://starship.python.net/~lemburg/coercion-0.6.zip Import revamp It should be much easier to add hooks to allow importing from zip files, from a URL, etc., or (different) hooks to allow looking for different extensions (e.g. to automatically generate ILU stubs). This should help the small platforms too, since they often don't have a filesystem, so their imports will have to come from some other place. ANSI C I'm tired of supporting K&R C. All code should be converted to using prototypes. The Py_PROTO macros should go. We can add const-correctness to all code. Too bad for platforms without decent compilers (let them get GCC). Buffer object API extensions Marc-Andre Lemburg has a patch Distutil Should we start integrating some of the results of the distutil SIG? (What's the status? I haven't been paying attention.) Misc Jeremy Hylton's urllib2.py Greg Stein's new httplib.py (or Jeremy's?) Andrew Kuchling's new PCRE release? The IPv6 patches? Gotta run! --Guido van Rossum (home page: http://www.python.org/~guido/) From gward at cnri.reston.va.us Wed Apr 21 21:10:08 1999 From: gward at cnri.reston.va.us (Greg Ward) Date: Wed, 21 Apr 1999 15:10:08 -0400 Subject: [Python-Dev] Notice of intent: rich comparisons In-Reply-To: <199904211904.PAA14966@eric.cnri.reston.va.us>; from Guido van Rossum on Wed, Apr 21, 1999 at 03:04:40PM -0400 References: <199904211904.PAA14966@eric.cnri.reston.va.us> Message-ID: <19990421151008.D6167@cnri.reston.va.us> On 21 April 1999, Guido van Rossum said: > Distutil > > Should we start integrating some of the results of the > distutil SIG? (What's the status? I haven't been paying > attention.) It's in a state that other people can look at the code, but (apparently) not yet good enough for floods of patches to come in. Right now, Distutils has *just* enough marbles to "build" and install itself on Unix systems, and someone has contributed a patch so it works on NT. No support yet for compiling extensions, which of course is the important thing. Greg -- Greg Ward - software developer gward at cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913 From da at ski.org Wed Apr 21 21:19:42 1999 From: da at ski.org (David Ascher) Date: Wed, 21 Apr 1999 12:19:42 -0700 (Pacific Daylight Time) Subject: [Python-Dev] Notice of intent: rich comparisons In-Reply-To: <199904211904.PAA14966@eric.cnri.reston.va.us> Message-ID: On Wed, 21 Apr 1999, Guido van Rossum wrote: > > Guido, how do you envision python-dev working? > > I though we'd just crack Monty Python jokes while pretending to work :-) That'd be better than what I've read on the perl5-porters list in the last couple of days (which I'm reading because of the ad hoopla). They seem to spend their time arguing about whether Perl codes are programs or scripts. Viciously, too. =) More seriously, some of the discussions they're having a worth keeping an eye on, just as a form of legal industrial spying. > Import revamp There was an interesting bit from Greg, Jack, and MarkH on this topic recently in the distutil-sig. Maybe one of them can bring the rest of us up to date on the effort. --david From fredrik at pythonware.com Wed Apr 21 22:04:54 1999 From: fredrik at pythonware.com (Fredrik Lundh) Date: Wed, 21 Apr 1999 22:04:54 +0200 Subject: [Python-Dev] Notice of intent: rich comparisons References: <199904211904.PAA14966@eric.cnri.reston.va.us> Message-ID: <092701be8c32$3a4ad9f0$f29b12c2@pythonware.com> Guido wrote: > String methods > > Barry has his patches ready. > > Unicode > > What is the status of /F's latest attempts? most of the code is written and tested; the API still needs some cleaning up. I also have a few patches and other contributions in my inbox that I gotta look into... btw, the unicode module can be compiled for 8-bit characters too. we could merge it with the string module (one place to fix bugs...) > Import revamp > > It should be much easier to add hooks to allow importing > from zip files, from a URL, etc., or (different) hooks to > allow looking for different extensions (e.g. to automatically > generate ILU stubs). This should help the small platforms > too, since they often don't have a filesystem, so their > imports will have to come from some other place. something similar to greg's imputil.py should definitely be in the core... > ANSI C > > I'm tired of supporting K&R C. All code should be converted > to using prototypes. The Py_PROTO macros should go. We can > add const-correctness to all code. Too bad for platforms > without decent compilers (let them get GCC). or ansi2knr.c (available from http://www.cs.wisc.edu/~ghost/). otoh, it only converts function headers, so I'm not sure it's worth the effort... From beazley at cs.uchicago.edu Wed Apr 21 22:06:50 1999 From: beazley at cs.uchicago.edu (David Beazley) Date: Wed, 21 Apr 1999 15:06:50 -0500 (CDT) Subject: [Python-Dev] Notice of intent: rich comparisons References: <199904211904.PAA14966@eric.cnri.reston.va.us> Message-ID: <199904212006.PAA17138@tartarus.cs.uchicago.edu> Guido van Rossum writes: > > ANSI C > > I'm tired of supporting K&R C. All code should be converted > to using prototypes. The Py_PROTO macros should go. We can > add const-correctness to all code. Too bad for platforms > without decent compilers (let them get GCC). > Maybe I'm just lucky, but I've written nothing but ANSI C for the last 8 years and have never had a problem compiling it on any machine. I don't see this as being a huge issue. > > Misc > Depending on how deep I want to dig, I may have some patches to ParseTuple() that would make life easier for some of us extension writing fans. As it is right now, my experimental version of Swig is using it's own version of ParseTuple (for various reasons). Also, out of curiousity, is anyone making heavy use of the CObject type right now? Cheers, Dave From jim at digicool.com Wed Apr 21 23:15:24 1999 From: jim at digicool.com (Jim Fulton) Date: Wed, 21 Apr 1999 17:15:24 -0400 Subject: [Python-Dev] Notice of intent: rich comparisons References: <199904211904.PAA14966@eric.cnri.reston.va.us> <199904212006.PAA17138@tartarus.cs.uchicago.edu> Message-ID: <371E3FEC.9D19607A@digicool.com> David Beazley wrote: > > Guido van Rossum writes: > > > > ANSI C > > > > I'm tired of supporting K&R C. All code should be converted > > to using prototypes. The Py_PROTO macros should go. We can > > add const-correctness to all code. Too bad for platforms > > without decent compilers (let them get GCC). > > > > Maybe I'm just lucky, but I've written nothing but ANSI C for the last > 8 years and have never had a problem compiling it on any machine. I > don't see this as being a huge issue. I've had the same experience with things like prototypes. The recent introduction of indented preprocessor instructions caused me significant pain on some platforms. Fortunately, I haven't had to deal with those platforms recently, still, the elegence of indented preporicessor instructions wasn't worth the pain it caused. As far as choice of compilers goes, sometimes gcc isn't an option. I've had cases where I *had* to use the native compiler in order to link to third-party libraries. I support moving to ANSI C, for example, wrt prototypes, but lets still be somewhat sensative to portability and not abuse bad compilers without good reason. > > > > > Misc > > > > Depending on how deep I want to dig, I may have some patches to > ParseTuple() that would make life easier for some of us extension > writing fans. As it is right now, my experimental version of Swig > is using it's own version of ParseTuple (for various reasons). > Also, out of curiousity, is anyone making heavy use of the CObject > type right now? Yes. Jim -- Jim Fulton mailto:jim at digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats. From jeremy at cnri.reston.va.us Wed Apr 21 23:23:57 1999 From: jeremy at cnri.reston.va.us (Jeremy Hylton) Date: Wed, 21 Apr 1999 17:23:57 -0400 (EDT) Subject: [Python-Dev] Notice of intent: rich comparisons In-Reply-To: <199904212006.PAA17138@tartarus.cs.uchicago.edu> References: <199904211904.PAA14966@eric.cnri.reston.va.us> <199904212006.PAA17138@tartarus.cs.uchicago.edu> Message-ID: <14110.16787.893181.642806@bitdiddle.cnri.reston.va.us> >>>>> "DB" == David Beazley writes: DB> various reasons). Also, out of curiousity, is anyone making DB> heavy use of the CObject type right now? I used it a little, but only in a modified Python backend for SWIG. Jeremy From mal at lemburg.com Wed Apr 21 23:46:46 1999 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 21 Apr 1999 23:46:46 +0200 Subject: [Python-Dev] Notice of intent: rich comparisons References: <199904211904.PAA14966@eric.cnri.reston.va.us> Message-ID: <371E4746.22A84506@lemburg.com> Guido van Rossum wrote: > > Break up into VM, parser, import, mainloop, and other components? > > The porting efforts to seriously small machines (Win/CE, > Pilot, etc.) all seem to need a Python VM that doesn't > automatically pull in the parser and interactive main loop. > There are other reasons as well to isolate various parts > of the functionality (including all numeric data types except > ints). > > This could include: restructuring of the parser so codeop.py > can be simplified; making the interactive main loop a script. There's some good work out there by Skip Montanaro to revamp the VM into a combined register/stack machine. He calls it rattlesnake. More infos can be found in the list archive (it's currently sleeping): http://www.egroups.com/folders/rattlesnake I would like to see the VM/compiler pluggable so that experiments like rattlesnake become easier to implement (extension modules vs. patches to the core interpreter). > Coercions > > Marc-Andre Lemburg has some good suggestions here: > http://starship.python.net/~lemburg/coercion-0.6.zip I will continue to work on these patches now that 1.5.2 is out. There is a (more or less) detailed explanation of the patch set at: http://starship.skyport.net/~lemburg/CoercionProposal.html Instead of using of using the PY_NEWSTYLENUMBER approach I'll turn to the new type flags that were introduced in 1.5.2. The Py_NotImplemented singleton return value will stay, because performance tests have shown that this method does not cause any significant hit where as the exception raise and catch method does introduce a significant slow-down. > Import revamp Greg's imputil.py (it's in the distutils package) should provide a good start. > Buffer object API extensions I'll put the complete patch up on starship later this week... here are the basic prototypes: DL_IMPORT(int) PyObject_AsCharBuffer Py_PROTO((PyObject *obj, const char **buffer, int *buffer_len)); /* Takes an arbitrary object which must support the (character, single segment) buffer interface and returns a pointer to a read-only memory location useable as character based input for subsequent processing. buffer and buffer_len are only set in case no error occurrs. Otherwise, -1 is returned and an exception set. */ DL_IMPORT(int) PyObject_AsReadBuffer Py_PROTO((PyObject *obj, const void **buffer, int *buffer_len)); /* Same as PyObject_AsCharBuffer() except that this API expects (readable, single segment) buffer interface and returns a pointer to a read-only memory location which can contain arbitrary data. buffer and buffer_len are only set in case no error occurrs. Otherwise, -1 is returned and an exception set. */ DL_IMPORT(int) PyObject_AsWriteBuffer Py_PROTO((PyObject *obj, void **buffer, int *buffer_len)); /* Takes an arbitrary object which must support the (writeable, single segment) buffer interface and returns a pointer to a writeable memory location in buffer of size buffer_len. buffer and buffer_len are only set in case no error occurrs. Otherwise, -1 is returned and an exception set. */ > Distutil > > Should we start integrating some of the results of the > distutil SIG? (What's the status? I haven't been paying > attention.) With all the different modules and packages available for Python starting to slowly introduce dependencies, I think the main objective should be introducing a well organized installation info system, e.g. a registry where modules and packages can query and save version and dependency information. Someone on the main list mentioned that JPython has something like this... > Misc > > Jeremy Hylton's urllib2.py > > Greg Stein's new httplib.py (or Jeremy's?) > > Andrew Kuchling's new PCRE release? > > The IPv6 patches? These are on my wish list, so I'll simply add them here: ? APIs to faciliate creation of extensions classes (using Python classes and C functions as methods) The main open question here is where and how to store C data in the instances. This could also provide a way to migrate to all Python classes for some future version. ? Restructure the calling mechanism used in ceval.c to make it clearer, more flexible and faster (of course, :-). Also, inline calling of C functions/methods (this produces a noticable speedup). I have a patch for the restructuring and an old one (against 1.5) for the C function call inlining. ? A "fastpath" hook made available through the sys module. This should hook into the module/package loader and should be used whenever set to find a module (reverting to the standard lookup method in case it can't find it). I have an old patch that does this. It uses a simple Python function to redirect the lookup to a precalculated dictionary of installed modules/packages. This results in faster startup of the Python interpreter (by saving a few hundred stat() calls). -- Marc-Andre Lemburg Y2000: 254 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From mal at lemburg.com Wed Apr 21 23:51:11 1999 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 21 Apr 1999 23:51:11 +0200 Subject: [Python-Dev] Notice of intent: rich comparisons References: <199904211904.PAA14966@eric.cnri.reston.va.us> <199904212006.PAA17138@tartarus.cs.uchicago.edu> Message-ID: <371E484F.22046FE9@lemburg.com> David Beazley wrote: > > > > > Misc > > > > Depending on how deep I want to dig, I may have some patches to > ParseTuple() that would make life easier for some of us extension > writing fans. As it is right now, my experimental version of Swig > is using it's own version of ParseTuple (for various reasons). > Also, out of curiousity, is anyone making heavy use of the CObject > type right now? You mean the one in Objects/cobject.c ? Sure, all my type extensions export their C API that way... and it works just great (no more linker problems, nice error messages when extensions are not found, etc.). -- Marc-Andre Lemburg Y2000: 254 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From da at ski.org Wed Apr 21 23:56:17 1999 From: da at ski.org (David Ascher) Date: Wed, 21 Apr 1999 14:56:17 -0700 (Pacific Daylight Time) Subject: [Python-Dev] Notice of intent: rich comparisons In-Reply-To: <371E484F.22046FE9@lemburg.com> Message-ID: David Beazley wrote: > Also, out of curiousity, is anyone making heavy use of the CObject > type right now? NumPy does. --da From MHammond at skippinet.com.au Thu Apr 22 01:45:19 1999 From: MHammond at skippinet.com.au (Mark Hammond) Date: Thu, 22 Apr 1999 09:45:19 +1000 Subject: [Python-Dev] Notice of intent: rich comparisons In-Reply-To: <092701be8c32$3a4ad9f0$f29b12c2@pythonware.com> Message-ID: <004c01be8c51$043f27c0$0801a8c0@bobcat> [Guido and /F] > > Unicode > > > > What is the status of /F's latest attempts? > > most of the code is written and tested; the API still > needs some cleaning up. I also have a few patches > and other contributions in my inbox that I gotta > look into... Im one of those contributors :-) I have made changes to the Win32 extensions that allows it to use /F's type instead of its own built-in Unicode type. Further, the Windows CE port of these extensions actually enables this - so we have some code actively using it. However, this still doesnt give me anything more than I had before. We need at least _some_ level of integration of this type into Python. The key areas to me are: * PyArg_ParseTuple and Py_BuildValue - Seems OK we use the "u" format character analogous to "s". We havent thought of a "z" equivilent. This is fairly easy. * Some way for these functions to auto-convert. Eg, when the user passes an 8bit string object, but the C side of the world wants a Unicode string. This is harder, as an extra memory buffer for the conversion is needed. This second problem is, to me, the next stumbling block. When we sort these out, I feel we would have the start of a good platform to start experimenting. Mark. From fdrake at cnri.reston.va.us Thu Apr 22 16:47:35 1999 From: fdrake at cnri.reston.va.us (Fred L. Drake) Date: Thu, 22 Apr 1999 10:47:35 -0400 (EDT) Subject: [Python-Dev] Notice of intent: rich comparisons In-Reply-To: <16290078@toto.iv> Message-ID: <14111.13959.211874.750734@weyr.cnri.reston.va.us> David Beazley writes: > Maybe I'm just lucky, but I've written nothing but ANSI C for the last > 8 years and have never had a problem compiling it on any machine. I > don't see this as being a huge issue. Wasn't SunOS 4.x the problem child here? There are still a lot of people using these systems, for reasons that aren't clear to me. (Did support for some older hardware get dropped? Sounds like the most reasonable reason to use the old OS is legacy hardware.) -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From bwarsaw at cnri.reston.va.us Thu Apr 22 17:37:46 1999 From: bwarsaw at cnri.reston.va.us (Barry A. Warsaw) Date: Thu, 22 Apr 1999 11:37:46 -0400 (EDT) Subject: [Python-Dev] Notice of intent: rich comparisons References: <16290078@toto.iv> <14111.13959.211874.750734@weyr.cnri.reston.va.us> Message-ID: <14111.16970.839894.147748@anthem.cnri.reston.va.us> >>>>> "Fred" == Fred L Drake writes: Fred> Wasn't SunOS 4.x the problem child here? There are still Fred> a lot of people using these systems, for reasons that aren't Fred> clear to me. (Did support for some older hardware get Fred> dropped? Sounds like the most reasonable reason to use the Fred> old OS is legacy hardware.) There might be, but the bundled compiler in SunOS 4 was never intended to be used for anything more than recompiling the kernel. Years ago, I had conversations with Sun engineers who claimed that no bug in the bundled compiler was ever fixed unless it directly impacted on kernel rebuilds. Even back then they recommended using something other than the bundled crufty old K&R compiler for building all other stuff, and this was when there was that huge hoopla over the unbundling of the compiler. SunOS 4 users can probably be mostly satisfied with gcc. -Barry From fdrake at cnri.reston.va.us Thu Apr 22 17:42:57 1999 From: fdrake at cnri.reston.va.us (Fred L. Drake) Date: Thu, 22 Apr 1999 11:42:57 -0400 (EDT) Subject: [Python-Dev] Notice of intent: rich comparisons In-Reply-To: <14111.16970.839894.147748@anthem.cnri.reston.va.us> References: <16290078@toto.iv> <14111.13959.211874.750734@weyr.cnri.reston.va.us> <14111.16970.839894.147748@anthem.cnri.reston.va.us> Message-ID: <14111.17281.999490.718527@weyr.cnri.reston.va.us> Barry A. Warsaw writes: > There might be, but the bundled compiler in SunOS 4 was never intended > to be used for anything more than recompiling the kernel. Years ago, ... > SunOS 4 users can probably be mostly satisfied with gcc. Barry, This is good enough for me. I'd certainly rather avoid K&R C! -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From skip at mojam.com Thu Apr 22 19:18:39 1999 From: skip at mojam.com (skip at mojam.com) Date: Thu, 22 Apr 1999 13:18:39 -0400 (EDT) Subject: [Python-Dev] Notice of intent: rich comparisons In-Reply-To: <14111.17281.999490.718527@weyr.cnri.reston.va.us> References: <16290078@toto.iv> <14111.13959.211874.750734@weyr.cnri.reston.va.us> <14111.16970.839894.147748@anthem.cnri.reston.va.us> <14111.17281.999490.718527@weyr.cnri.reston.va.us> Message-ID: <14111.22873.161727.15206@cm-29-94-14.nycap.rr.com> Barry> SunOS 4 users can probably be mostly satisfied with gcc. Fred> This is good enough for me. I'd certainly rather avoid K&R C! Besides, aren't there tools available that can strip most of the ANSI-ness out of ANSI C? (Un)Protoize? For those (few?) people who are really still stuck using a K&R compiler I would think those tools, perhaps supplemented with some patch files maintained outside the main Python source tree, would be sufficient. Skip Montanaro | Mojam: "Uniting the World of Music" http://www.mojam.com/ skip at mojam.com | Musi-Cal: http://www.musi-cal.com/ 518-372-5583 From bwarsaw at cnri.reston.va.us Thu Apr 22 20:07:57 1999 From: bwarsaw at cnri.reston.va.us (Barry A. Warsaw) Date: Thu, 22 Apr 1999 14:07:57 -0400 (EDT) Subject: [Python-Dev] Notice of intent: rich comparisons References: <16290078@toto.iv> <14111.13959.211874.750734@weyr.cnri.reston.va.us> <14111.16970.839894.147748@anthem.cnri.reston.va.us> <14111.17281.999490.718527@weyr.cnri.reston.va.us> <14111.22873.161727.15206@cm-29-94-14.nycap.rr.com> Message-ID: <14111.25981.74738.355264@anthem.cnri.reston.va.us> >>>>> "skip" == writes: skip> Besides, aren't there tools available that can strip most of skip> the ANSI-ness out of ANSI C? (Un)Protoize? I think so. Seems I have unprotoize already; probably got it for free with gcc, or some other GNU tool. -B From skip at mojam.com Thu Apr 22 20:22:51 1999 From: skip at mojam.com (skip at mojam.com) Date: Thu, 22 Apr 1999 14:22:51 -0400 (EDT) Subject: [Python-Dev] Notice of intent: rich comparisons In-Reply-To: <371E4746.22A84506@lemburg.com> References: <199904211904.PAA14966@eric.cnri.reston.va.us> <371E4746.22A84506@lemburg.com> Message-ID: <14111.23085.737365.582406@cm-29-94-14.nycap.rr.com> mal> There's some good work out there by Skip Montanaro to revamp the VM mal> into a combined register/stack machine. He calls it rattlesnake. mal> More infos can be found in the list archive (it's currently mal> sleeping): Thanks to Marc-Andre for mentioning this. Rattlesnake is indeed sleeping at the moment. If anyone is interested in the idea I'd be happy to awaken it. The main observation was that much of the virtual machine's activity is pushing/popping objects to/from the stack. By treating a chunk of storage as a register file much of that churn can be avoided. Skip Montanaro | Mojam: "Uniting the World of Music" http://www.mojam.com/ skip at mojam.com | Musi-Cal: http://www.musi-cal.com/ 518-372-5583 From fredrik at pythonware.com Fri Apr 23 09:48:14 1999 From: fredrik at pythonware.com (Fredrik Lundh) Date: Fri, 23 Apr 1999 09:48:14 +0200 Subject: [Python-Dev] Compiling ANSI C on K&R compilers References: <16290078@toto.iv><14111.13959.211874.750734@weyr.cnri.reston.va.us><14111.16970.839894.147748@anthem.cnri.reston.va.us><14111.17281.999490.718527@weyr.cnri.reston.va.us> <14111.22873.161727.15206@cm-29-94-14.nycap.rr.com> Message-ID: <00df01be8d5d$a82b2f70$f29b12c2@pythonware.com> > Besides, aren't there tools available that can strip most of the ANSI-ness > out of ANSI C? (Un)Protoize? For those (few?) people who are really still > stuck using a K&R compiler I would think those tools, perhaps supplemented > with some patch files maintained outside the main Python source tree, would > be sufficient. I mentioned ansi2knr.c in an earlier post. It's a small utility, and can be distributed with the Python core (it's GPL'd, but since it isn't linked with Python, that's not a problem). this is used by ghostscript and the ijg jpeg library, among others: ftp://ftp.cs.wisc.edu/ghost/ansi2knr.c (or via http://www.cs.wisc.edu/~ghost/) Cheers /F fredrik at pythonware.com http://www.pythonware.com From gstein at lyra.org Fri Apr 23 12:37:02 1999 From: gstein at lyra.org (Greg Stein) Date: Fri, 23 Apr 1999 03:37:02 -0700 Subject: [Python-Dev] Notice of intent: rich comparisons References: <199904211904.PAA14966@eric.cnri.reston.va.us> Message-ID: <37204D4E.2C02ABE2@lyra.org> Guido van Rossum wrote: >... > Import revamp > > It should be much easier to add hooks to allow importing > from zip files, from a URL, etc., or (different) hooks to > allow looking for different extensions (e.g. to automatically > generate ILU stubs). This should help the small platforms > too, since they often don't have a filesystem, so their > imports will have to come from some other place. I would recommend that Python's import mechanism be changed to use some of the concepts from my imputil.py module and in a couple of my posts to distutils-sig: http://www.python.org/pipermail/distutils-sig/1999-January/000142.html http://www.python.org/pipermail/distutils-sig/1998-December/000077.html > ANSI C > > I'm tired of supporting K&R C. All code should be converted > to using prototypes. The Py_PROTO macros should go. We can > add const-correctness to all code. Too bad for platforms > without decent compilers (let them get GCC). Or those platforms can stick with Python 1.5.2 > Misc > > Jeremy Hylton's urllib2.py > > Greg Stein's new httplib.py (or Jeremy's?) Mine is a drop-in replacement for the current httplib.py. httplib.HTTP is compatible with the current version and does HTTP/1.0. httplib.HTTPConnection is similar to the other (but (IMO) cleans up a few elements of the API); it does HTTP/1.1, including persistent connections. This module follows the design of the original httplib.py much more closely. Jeremy's module uses a very different design approach (no value judgement here; it's just different); also, it simply copies over the old HTTP class, while mine derives the compatible version from HTTPConnection. I'm not sure how much testing Jeremy's has had, but I use my module for all Python-based http work now. Some number of other people have downloaded and used it, too. I would recommend my new module, given the two options. I'll eventually have a davlib.py to add to the distribution, but it needs more work. I'll contribute that later. --- I'd also like to see some cleanup of the build process. For example, (Guido:) I sent in a different way to handle the signal stuff (shifting files around and stuff) as opposed to the "hassignal" thing. About the build process: it may be nice to move to a single makefile. Here is an interesting paper about this: http://www.canb.auug.org.au/~millerp/rmch/recu-make-cons-harm.html Is it reasonable to split out the Demo, Doc, Misc, and Tools subdirs since those never really end up as part of an installed Python? e.g. into a python-extras distribution? (which would allow doc and tools updates at arbitrary times) Does it make sense to remove platform-specific modules? (e.g. the SGI modules) While distutils doesn't have anything *yet*, there are changes that can be made in the build process to improve the distutils process. I know that Greg Ward wants distutils to work on previous versions of Python, but (IMO) things would be simpler all around if distutils-based packages were simply designed for 1.6 systems as a basic dependency. However, that choice is quite separate from the decision to generate distutils support during the build. Oh: there were some things floating around at one point about using Python itself within the build process (e.g. for modules). Is any of that work useful? Cheers, -g -- Greg Stein, http://www.lyra.org/ From fdrake at cnri.reston.va.us Fri Apr 23 15:28:12 1999 From: fdrake at cnri.reston.va.us (Fred L. Drake) Date: Fri, 23 Apr 1999 09:28:12 -0400 (EDT) Subject: [Python-Dev] Notice of intent: rich comparisons In-Reply-To: <37204D4E.2C02ABE2@lyra.org> References: <199904211904.PAA14966@eric.cnri.reston.va.us> <37204D4E.2C02ABE2@lyra.org> Message-ID: <14112.30060.552422.975547@weyr.cnri.reston.va.us> Greg Stein writes: > Is it reasonable to split out the Demo, Doc, Misc, and Tools subdirs > since those never really end up as part of an installed Python? e.g. > into a python-extras distribution? (which would allow doc and tools > updates at arbitrary times) The Doc/ stuff is already in a separate distribution; this has been in place for about a year (if I recall correctly). I try to make doc releases shortly after Python releases (I think the 1.5.2 doc release is the longest I've waited past the Python release so far, and it may end up being next week), and I have made interim releases as the documentation has grown. I certainly think that doing something similar for the Demo/ and Tools/ directories would be reasonable; they could share a single distribution. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From skip at mojam.com Fri Apr 23 15:59:02 1999 From: skip at mojam.com (skip at mojam.com) Date: Fri, 23 Apr 1999 09:59:02 -0400 (EDT) Subject: [Python-Dev] Notice of intent: rich comparisons In-Reply-To: <14112.30060.552422.975547@weyr.cnri.reston.va.us> References: <199904211904.PAA14966@eric.cnri.reston.va.us> <37204D4E.2C02ABE2@lyra.org> <14112.30060.552422.975547@weyr.cnri.reston.va.us> Message-ID: <14112.31858.374462.469793@cm-29-94-14.nycap.rr.com> Fred> I certainly think that doing something similar for the Demo/ and Fred> Tools/ directories would be reasonable; they could share a single Fred> distribution. We need to make sure none of the tools are needed in the install process. h2py comes to mind. Skip Montanaro | Mojam: "Uniting the World of Music" http://www.mojam.com/ skip at mojam.com | Musi-Cal: http://www.musi-cal.com/ 518-372-5583 From jeremy at cnri.reston.va.us Mon Apr 26 17:26:28 1999 From: jeremy at cnri.reston.va.us (Jeremy Hylton) Date: Mon, 26 Apr 1999 11:26:28 -0400 (EDT) Subject: [Python-Dev] Notice of intent: rich comparisons In-Reply-To: <37204D4E.2C02ABE2@lyra.org> References: <199904211904.PAA14966@eric.cnri.reston.va.us> <37204D4E.2C02ABE2@lyra.org> Message-ID: <14116.33341.371508.53071@bitdiddle.cnri.reston.va.us> >>>>> "GS" == Greg Stein writes: >> Greg Stein's new httplib.py (or Jeremy's?) GS> Mine is a drop-in replacement for the current GS> httplib.py. httplib.HTTP is compatible with the current version GS> and does HTTP/1.0. httplib.HTTPConnection is similar to the GS> other (but (IMO) cleans up a few elements of the API); it does GS> HTTP/1.1, including persistent connections. This module follows GS> the design of the original httplib.py much more GS> closely. Jeremy's module uses a very different design approach GS> (no value judgement here; it's just different); also, it simply GS> copies over the old HTTP class, while mine derives the GS> compatible version from HTTPConnection. I'm not sure how much GS> testing Jeremy's has had, but I use my module for all GS> Python-based http work now. Some number of other people have GS> downloaded and used it, too. GS> I would recommend my new module, given the two options. I think I agree. I stopped working on my version quite some time ago, before I made enough progress to make it useful. Thus, it makes a lot of sense to use Greg's working code. I'd be curious to see how to use HTTPConnection to do persistent connections and pipelined requests. It wasn't entirely clear from the code what I would need to do to keep the connection open. Do you just re-use the HTTPConnection object -- call putrequest again after getreply? I like the revised API that Greg's code uses. The request method on HTTPConnection objects cleans the API up in exactly the right way. It has always seemed unnecessary to have many separate calls to add headers and then a call to endheaders after putrequest. Packaging them all together in one method will simplify client code a lot. GS> I'll eventually have a davlib.py to add to the distribution, but GS> it needs more work. I'll contribute that later. Cool! Jeremy From guido at CNRI.Reston.VA.US Mon Apr 26 18:16:11 1999 From: guido at CNRI.Reston.VA.US (Guido van Rossum) Date: Mon, 26 Apr 1999 12:16:11 -0400 Subject: [Python-Dev] Public or private python-dev archives? Message-ID: <199904261616.MAA22036@eric.cnri.reston.va.us> In a private mail, Greg Stein suggested that the python-dev archives should be restricted to the members of the list. I prefer to make them public, but I won't want to impose this on others without discussion. So I've made the archives private for the time being while we discuss this meta-issue. (Also, the existence of the list isn't announced by mailman on its listinfo page.) Here's my argument for open archives. I don't think that we have anything to hide from the public -- I think of us as a technical forum whose discussions may affect others (e.g. Python users) and I think it's often useful for those others to be able to see what we've said. I want to keep membership of the list closed as a gentle way to enforce focus and quality of discussion. Jeremy pointed out that there's no restiction on posting, and mentioned that together with open archives this makes the list just as open as an open-subscription list. I don't see this equivalence -- certainly it makes a difference in practice, and the open posting is simply a mechanism to allow members with multiple email addresses to post from whereever they are. If we regularly get spammed or find the list is targeted by angry Python users we might have to restrict posting to members (and deal with the multiple address problem). I hope the discussion about this issue will be short (otherwise it would detract from the real goal of this list). I'll follow the desire of the majority of current members; once we have a decision I propose to stick with it and simply present new members with the facts. --Guido van Rossum (home page: http://www.python.org/~guido/) From gward at cnri.reston.va.us Mon Apr 26 18:30:43 1999 From: gward at cnri.reston.va.us (Greg Ward) Date: Mon, 26 Apr 1999 12:30:43 -0400 Subject: [Python-Dev] Public or private python-dev archives? In-Reply-To: <199904261616.MAA22036@eric.cnri.reston.va.us>; from Guido van Rossum on Mon, Apr 26, 1999 at 12:16:11PM -0400 References: <199904261616.MAA22036@eric.cnri.reston.va.us> Message-ID: <19990426123042.A2617@cnri.reston.va.us> On 26 April 1999, Guido van Rossum said: > In a private mail, Greg Stein suggested that the python-dev archives > should be restricted to the members of the list. I prefer to make > them public, but I won't want to impose this on others without > discussion. So I've made the archives private for the time being > while we discuss this meta-issue. (Also, the existence of the list > isn't announced by mailman on its listinfo page.) > > Here's my argument for open archives. I don't think that we have > anything to hide from the public -- I think of us as a technical forum > whose discussions may affect others (e.g. Python users) and I think > it's often useful for those others to be able to see what we've said. I favour as much openness as possible that's consistent with high signal-to-noise. Opening the archives doesn't affect SN ratio; for that matter, neither does allowing anyone to *read* the list while keeping posting privileges restricted. And letting the world know that the list exists -- even though posting privileges are restricted -- shouldn't affect quality. So I guess my position is: definitely open the archives and publicise the list -- the benefit of an open archive is reduced if people can't stumble across it like they can any sig. And consider the possibility of open subscription while keeping posting restricted. Not sure how easy that is with Mailman, but we can still consider the idea. The open, friendly nature of the Python community is a huge strength. I tentatively agree that posting privileges should be restricted to keep quality high, but the idea of a "secret cabal" discussing Python development off in a dark corner away from the grubby masses seems very counter to the spirit I've seen so far. Greg -- Greg Ward - software developer gward at cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913 From da at ski.org Mon Apr 26 18:29:56 1999 From: da at ski.org (David Ascher) Date: Mon, 26 Apr 1999 09:29:56 -0700 (Pacific Daylight Time) Subject: [Python-Dev] Public or private python-dev archives? In-Reply-To: <199904261616.MAA22036@eric.cnri.reston.va.us> Message-ID: On Mon, 26 Apr 1999, Guido van Rossum wrote: > In a private mail, Greg Stein suggested that the python-dev archives > should be restricted to the members of the list. I prefer to make > them public, but I won't want to impose this on others without > discussion. So I've made the archives private for the time being > while we discuss this meta-issue. (Also, the existence of the list > isn't announced by mailman on its listinfo page.) If one has a public archive with restricted membership, then one needs to have a process for people to petition membership, including policies on deciding admission (which could be as vague as "up to GvR's whim"). FWIW, the perl5-porters list is open but the perl6-porters list is closed. My suggestion is that we can start with an open policy on archives, and the lax posting policy for the multiple email address business (which should be incorporated in mailman++ =), with the explicitely stated caveat that if it turns out that that policy doesn't work, we reserve the right to tighten things up. I also suggest that we don't advertise the fact that anyone can post. [Except of course that we've just mentioned this in archives which I'm arguing should be public =)] --david From bwarsaw at cnri.reston.va.us Mon Apr 26 19:44:36 1999 From: bwarsaw at cnri.reston.va.us (Barry A. Warsaw) Date: Mon, 26 Apr 1999 13:44:36 -0400 (EDT) Subject: [Python-Dev] Public or private python-dev archives? References: <199904261616.MAA22036@eric.cnri.reston.va.us> <19990426123042.A2617@cnri.reston.va.us> Message-ID: <14116.42500.284907.569281@anthem.cnri.reston.va.us> >>>>> "GW" == Greg Ward writes: GW> And consider the possibility of open subscription while GW> keeping posting restricted. Not sure how easy that is with GW> Mailman, but we can still consider the idea. It could be done in a number of ways. You could restrict postings to members only, but as Guido has pointed out, a lot of people post from more than one account and Mailman doesn't handle that very well yet. Or you could moderate the list, but then someone has to approve postings and that's more work than I think anybody wants to do. I'm also for an open-as-possible policy, with the right to restrict later if the s/n gets too low. I sort of view Python-dev to be the place that serious c.l.py proposals get fleshed out and implementation strategies discussed. The (hopefully) high level of technical detail on the list should self-select. -Barry From gmcm at hypernet.com Mon Apr 26 20:56:52 1999 From: gmcm at hypernet.com (Gordon McMillan) Date: Mon, 26 Apr 1999 13:56:52 -0500 Subject: [Python-Dev] Public or private python-dev archives? In-Reply-To: <14116.42500.284907.569281@anthem.cnri.reston.va.us> Message-ID: <1286969269-56980208@hypernet.com> [Barry] > The (hopefully) high level of > technical detail on the list should self-select. I thought the humor did that. If the public-archive were only updated weekly, it would make it's use (or abuse) as glorified help list pretty tenuous. No one has espoused Greg's reasoning. In the abscense of said arguments, I'm certainly inclined to vote for "as public as can be and still be focused". -OTOH-then-I'll-never-know-what-goes-on-in-the-smoke-filled-room-ly y'rs - Gordon From da at ski.org Mon Apr 26 21:12:54 1999 From: da at ski.org (David Ascher) Date: Mon, 26 Apr 1999 12:12:54 -0700 (Pacific Daylight Time) Subject: [Python-Dev] Why unbundle Tools and Demo? Message-ID: Several people argue for unbundling Tools/ and Demo/ in 1.6. I'd like to argue to leave them in. They're not especially big, and IMHO they are quite valuable, *especially* to the novice user. In fact, I'd like to argue that Demo/ should be promoted to the same status as Tools/ (by which I mean included in the Windows binary distribution). Unbundling Tools/ would mean unbundling IDLE, which IMHO would be a big strategic mistake. However, I wouldn't be against a cleanup of said directories. Some things should probably be removed (anything which uses stdwin), some of the code in classes is showing its age (notes about "being upgraded for Python 1.1" =), etc. That said, the tkinter/ directory is the best place to look for simple Tkinter code, and should be included, IMHO. --david From guido at CNRI.Reston.VA.US Mon Apr 26 21:20:26 1999 From: guido at CNRI.Reston.VA.US (Guido van Rossum) Date: Mon, 26 Apr 1999 15:20:26 -0400 Subject: [Python-Dev] Why unbundle Tools and Demo? In-Reply-To: Your message of "Mon, 26 Apr 1999 12:12:54 PDT." References: Message-ID: <199904261920.PAA22415@eric.cnri.reston.va.us> > Several people argue for unbundling Tools/ and Demo/ in 1.6. I'd like to > argue to leave them in. They're not especially big, and IMHO they are > quite valuable, *especially* to the novice user. In fact, I'd like to > argue that Demo/ should be promoted to the same status as Tools/ (by which > I mean included in the Windows binary distribution). Unbundling Tools/ > would mean unbundling IDLE, which IMHO would be a big strategic mistake. > > However, I wouldn't be against a cleanup of said directories. Some things > should probably be removed (anything which uses stdwin), some of the code > in classes is showing its age (notes about "being upgraded for Python 1.1" > =), etc. That said, the tkinter/ directory is the best place to look for > simple Tkinter code, and should be included, IMHO. Agreed. One simple thing that would help me immensely would be for someone to go through all the various Demo directories and make an inventary of what is there and how useful it is, (1) to all Python users, (2) to Windows users. Then, perhaps someone could write a simple document making these files (and Tools) more accessible... --Guido van Rossum (home page: http://www.python.org/~guido/) From da at ski.org Mon Apr 26 21:20:40 1999 From: da at ski.org (David Ascher) Date: Mon, 26 Apr 1999 12:20:40 -0700 (Pacific Daylight Time) Subject: [Python-Dev] Why unbundle Tools and Demo? In-Reply-To: <199904261920.PAA22415@eric.cnri.reston.va.us> Message-ID: > someone to go through all the various Demo directories and make an > inventary of what is there and how useful it is, (1) to all Python > users, (2) to Windows users. Then, perhaps someone could write a > simple document making these files (and Tools) more accessible... Ok. I can do that. From guido at CNRI.Reston.VA.US Mon Apr 26 21:22:55 1999 From: guido at CNRI.Reston.VA.US (Guido van Rossum) Date: Mon, 26 Apr 1999 15:22:55 -0400 Subject: [Python-Dev] Why unbundle Tools and Demo? In-Reply-To: Your message of "Mon, 26 Apr 1999 12:20:40 PDT." References: Message-ID: <199904261922.PAA22447@eric.cnri.reston.va.us> [me] > > someone to go through all the various Demo directories and make an > > inventary of what is there and how useful it is, (1) to all Python > > users, (2) to Windows users. Then, perhaps someone could write a > > simple document making these files (and Tools) more accessible... [Dave] > Ok. I can do that. Great! I didn't mean to volunteer you -- but I think you'd do a great job. --Guido van Rossum (home page: http://www.python.org/~guido/) From tim_one at email.msn.com Tue Apr 27 06:25:19 1999 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 27 Apr 1999 00:25:19 -0400 Subject: [Python-Dev] Public or private python-dev archives? In-Reply-To: <19990426123042.A2617@cnri.reston.va.us> Message-ID: <000501be9065$f5e3db80$ab9e2299@tim> [Greg Ward, arguing in favor of ... a "secret cabal" discussing Python development off in a dark corner away from the grubby masses ] That's what I'd like too -- but somebody already let Gordon in . voting-to-leave-it-public-until-there's-a-problem-ly y'rs - tim From da at ski.org Tue Apr 27 21:23:55 1999 From: da at ski.org (David Ascher) Date: Tue, 27 Apr 1999 12:23:55 -0700 (Pacific Daylight Time) Subject: [Python-Dev] numpy Message-ID: What are the thoughts on NumPy integration into the core? --David From MHammond at skippinet.com.au Wed Apr 28 01:28:59 1999 From: MHammond at skippinet.com.au (Mark Hammond) Date: Wed, 28 Apr 1999 09:28:59 +1000 Subject: [Python-Dev] numpy In-Reply-To: Message-ID: <001c01be9105$bae7ccd0$0801a8c0@bobcat> > What are the thoughts on NumPy integration into the core? he he - and while we are at it :-) mxDateTime would need to be a popular choice for inclusion, and Guido has offered in-principle support for moving some of the Win32 stuff into the core - particularly the Registry stuff and the native Window Handle support... How far do we go :-) Personally, I would simply like to see the distutils SIG solve this problem for us. (sure). Eg, the "build" or "install" process (depending on the OS) could build a local HTML file with knowledge many "common" extensions - a single click, and it is downloaded, configured and built. Oh well, back to reality... [Which isnt to say I am opposed to NumPy and mxDateTime. Definately keen on the win32 stuff tho :-] Mark. From da at ski.org Wed Apr 28 01:31:56 1999 From: da at ski.org (David Ascher) Date: Tue, 27 Apr 1999 16:31:56 -0700 (Pacific Daylight Time) Subject: [Python-Dev] numpy In-Reply-To: <001c01be9105$bae7ccd0$0801a8c0@bobcat> Message-ID: On Wed, 28 Apr 1999, Mark Hammond wrote: > > What are the thoughts on NumPy integration into the core? > > he he - and while we are at it :-) mxDateTime would need to be a popular > choice for inclusion, and Guido has offered in-principle support for moving > some of the Win32 stuff into the core - particularly the Registry stuff and > the native Window Handle support... It may seem strange, but I'll argue for the win32 registry calls before the NumPy stuff. That could be because I've looked at NumPy code and not the win32 code. Not Jim's cleanest code. =) Mark, can you describe 'native Window Handle' support? --david From MHammond at skippinet.com.au Wed Apr 28 07:03:48 1999 From: MHammond at skippinet.com.au (Mark Hammond) Date: Wed, 28 Apr 1999 15:03:48 +1000 Subject: [Python-Dev] numpy In-Reply-To: Message-ID: <001e01be9134$809ca8f0$0801a8c0@bobcat> > It may seem strange, but I'll argue for the win32 registry > calls before > the NumPy stuff. That could be because I've looked at NumPy > code and not > the win32 code. Not Jim's cleanest code. =) he he - and I can even get out of the Win32 stuff - I wrote a string-only first version, and Bill Tutt rehashed it into what it is today, handling all the registry types. OTOH, there could also be a case for moving "win32api" completely to "core status" (whether that means truly core or simply a standard .pyd). For example, ntpath.py now has code that attempts to use "win32api.GetFullPathName()". The down-side is that win32api has nowhere near complete coverage, and is really a mixed bag of bits and pieces. Most later efforts where complete API sets are given coverage have different names - eg, win32file has the complete Win32 file API wrapped up - even if there are overlaps with existing functions in win32api. Im not sure what the answer is - my guess is a new core module with Win32 features deemed absolutely necessary for the core - stuff like the registry, and a few assorted other functions, such as GetFullPathName, but stopping well short of the full win32api set. > Mark, can you describe 'native Window Handle' support? Sure! We have a very light-weight "handle" object, representing a Win32 handle. It has no methods, and a single property for returning the underlying win32 handle as an integer. When the object destructs, it calls "CloseHandle()". Thats about it! It has no methods, so is passed as an argument. There has been no attempt to implement things like "handle.Read()" to represent "ReadFile(handle, ...)". There are 2 reasons for this: 1) Handles are fairly general purpose, and not restricted to IO operations. A handle is also used to represent a Mutex/Semaphores and threads/processes - certainly doesnt make sense to have a "Read()" method for those handles. 2) IMO, this should be done at the .py level anyway. The Win32 Handle support is pure C++ at the moment. A simple complication is that there are 3 types of handles in use at the moment - those that call "CloseHandle", those that call "RegCloseHandle" (registry handles) and a 3rd I cant recall. This is currently implemented using C++ inheritance. But even if the current implementation is not favoured, the object is so small that a rewrite would not be a problem. And for those that can be bothered to read this far, some more background: Some time ago, Greg and I decided to implement a "pywintypes" module. This defines what we considered "core types" for the Win32 world. All our extension modules (including win32api, COM; basically win32*.pyd) use this module. The objects it supports are: Unicode, Handles, Win32 Time, IIDs, Overlapped IO objects, 3 NT security related objects and importantly a standard Win32 exception and functions for filling it. Moving the registry stuff is dependant on the core having the Exception, Handle and Registry support (hence this discussion). We have our own Time object, but mxDateTime would be fine. One day, we hope to remove this pywintypes entirely, as the core will have it all :-) Mark. From gward at cnri.reston.va.us Wed Apr 28 14:51:43 1999 From: gward at cnri.reston.va.us (Greg Ward) Date: Wed, 28 Apr 1999 08:51:43 -0400 Subject: [Python-Dev] numpy In-Reply-To: <001c01be9105$bae7ccd0$0801a8c0@bobcat>; from Mark Hammond on Wed, Apr 28, 1999 at 09:28:59AM +1000 References: <001c01be9105$bae7ccd0$0801a8c0@bobcat> Message-ID: <19990428085143.A5571@cnri.reston.va.us> On 28 April 1999, Mark Hammond said: > How far do we go :-) > > Personally, I would simply like to see the distutils SIG solve this problem > for us. (sure). Eg, the "build" or "install" process (depending on the > OS) could build a local HTML file with knowledge many "common" extensions - > a single click, and it is downloaded, configured and built. Oh well, back > to reality... It's not impossible, it just takes a while. I think it took the Perl community about three years to go from "hey! let's have a standard build mechanism for modules!" to the point where I can install (almost) any module from CPAN with one shell command: perl -MCPAN -e 'install ("MIME::Base64");' which is insanely cool. (It took about two minutes to do the above just now; that included trying two CPAN mirrors that aren't being cooperative this morning, finding one that was working, downloading the current module list from it, determining that there is a more recent version available than the one installed here, downloading it, unpacking it, running "Makefile.PL" to generate the Makefile, running "make" [which compiles any extensions in the distribution, copies all the .pm files around, and generates the documentation], "make test" [run the module's self-test suite], and "make install" [install it in the "site-perl" library directory]. Amount of user interaction required: typing the above command line.) It's *still* rough around the edges, though, especially when building a new installation from scratch -- mainly because Perl doesn't ship with ftp or http libraries, so the CPAN.pm module has to try downloading stuff with lynx, ncftp, or plain ol' ftp until it has downloaded and installed the libnet and libwww-perl distributions. That's one problem we won't have with Python, at least. Oh yeah, and it all works *great* under Unix... but the rest of the world lags behind. Also, two major components of being able to do this -- the Perl Module List and CPAN -- are still vapourware in Python-land. But hey, if we can get to the "we *have* a standard build mechanism for modules!" point, then all the rest becomes a lot more feasible. Pep talk over... Greg -- Greg Ward - software developer gward at cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913 From mal at lemburg.com Wed Apr 28 09:44:25 1999 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 28 Apr 1999 09:44:25 +0200 Subject: [Python-Dev] numpy References: <001c01be9105$bae7ccd0$0801a8c0@bobcat> Message-ID: <3726BC59.35E3C9DB@lemburg.com> Mark Hammond wrote: > > > What are the thoughts on NumPy integration into the core? > > he he - and while we are at it :-) mxDateTime would need to be a popular > choice for inclusion, and Guido has offered in-principle support for moving > some of the Win32 stuff into the core - particularly the Registry stuff and > the native Window Handle support... > > How far do we go :-) > > Personally, I would simply like to see the distutils SIG solve this problem > for us. (sure). Eg, the "build" or "install" process (depending on the > OS) could build a local HTML file with knowledge many "common" extensions - > a single click, and it is downloaded, configured and built. Oh well, back > to reality... You're talking about fast moving targets there... are you sure that you want those in the standard distribution ? Maybe we have two distributions: the standard one and a pro edition with all the slick stuff included (together with a proper setup script to get those references to external libs and include files right). Actually, this is something I've been wanting to do for nearly a year now... just haven't found the time to really get things the way I want them. It's a project called Python Power Tools and includes many generic extensions (currently only ones that don't rely on external libs). If you're interested, have a look at an old version available at: http://starship.skyport.net/~lemburg/PowerTools-0.2.zip It includes the extensions BTree, mxDateTime, mxTools, mxStack, Trie, avl and kjbuckets. NumPy should probably also be included. The current setup uses a recursive Makefile approach (not too elegant, but works). A distutils setup would be much better. -- Marc-Andre Lemburg Y2000: 247 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From jack at oratrix.nl Wed Apr 28 15:48:21 1999 From: jack at oratrix.nl (Jack Jansen) Date: Wed, 28 Apr 1999 15:48:21 +0200 Subject: [Python-Dev] numpy In-Reply-To: Message by "Mark Hammond" , Wed, 28 Apr 1999 09:28:59 +1000 , <001c01be9105$bae7ccd0$0801a8c0@bobcat> Message-ID: <19990428134821.E9A68300F57@snelboot.oratrix.nl> > [...] Guido has offered in-principle support for moving > some of the Win32 stuff into the core - particularly the Registry stuff and > the native Window Handle support... I think it would be nice to put all the stuff that is shared between modules (I think that's only PyWinTypes, but who am I to think I have a clue about the windows port:-) into the core. I just did the same for MacPython, and it makes life a whole lot easier. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at 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 From skip at mojam.com Wed Apr 28 17:57:40 1999 From: skip at mojam.com (skip at mojam.com) Date: Wed, 28 Apr 1999 11:57:40 -0400 Subject: [Python-Dev] LLNL C++ as base for Python 2? Message-ID: <199904281557.LAA06491@cm-29-94-14.nycap.rr.com> Have we been talking about Python 2 or Python 1.6? If we're talking about Python 2, has anyone given a serious look at the LLNL gang's C++/Python stuff? If I recall Paul Dubois' talk at the last conference, it sounded like their work made it much easier to implement extension modules. Skip Montanaro | Mojam: "Uniting the World of Music" http://www.mojam.com/ skip at mojam.com | Musi-Cal: http://www.musi-cal.com/ 518-372-5583 From guido at CNRI.Reston.VA.US Wed Apr 28 18:06:03 1999 From: guido at CNRI.Reston.VA.US (Guido van Rossum) Date: Wed, 28 Apr 1999 12:06:03 -0400 Subject: [Python-Dev] LLNL C++ as base for Python 2? In-Reply-To: Your message of "Wed, 28 Apr 1999 11:57:40 EDT." <199904281557.LAA06491@cm-29-94-14.nycap.rr.com> References: <199904281557.LAA06491@cm-29-94-14.nycap.rr.com> Message-ID: <199904281606.MAA27526@eric.cnri.reston.va.us> > Have we been talking about Python 2 or Python 1.6? If we're talking about > Python 2, has anyone given a serious look at the LLNL gang's C++/Python > stuff? If I recall Paul Dubois' talk at the last conference, it sounded > like their work made it much easier to implement extension modules. I've mostly had 1.6 in mind. See recent traffic in the C++ SIG archives for the status of Paul's CXX. --Guido van Rossum (home page: http://www.python.org/~guido/) From da at ski.org Wed Apr 28 19:24:00 1999 From: da at ski.org (David Ascher) Date: Wed, 28 Apr 1999 10:24:00 -0700 (Pacific Daylight Time) Subject: [Python-Dev] LLNL C++ as base for Python 2? In-Reply-To: <199904281606.MAA27526@eric.cnri.reston.va.us> Message-ID: On Wed, 28 Apr 1999, Guido van Rossum wrote: > > Have we been talking about Python 2 or Python 1.6? If we're talking about > > Python 2, has anyone given a serious look at the LLNL gang's C++/Python > > stuff? If I recall Paul Dubois' talk at the last conference, it sounded > > like their work made it much easier to implement extension modules. > > I've mostly had 1.6 in mind. See recent traffic in the C++ SIG > archives for the status of Paul's CXX. Recent traffic? There's nothing in there that's substantive since... uh, well, I got tired of looking back. =) CXX is very cool, but it is still pushing the envelope of many C++ compilers. From what I gather, recent egcs' do manage with it, and since egcs is going to replace gcc, I expect that many platforms will be able to "do" CXX relatively soon. I vote to stay on the 1.6 track for now. From MHammond at skippinet.com.au Fri Apr 30 04:40:09 1999 From: MHammond at skippinet.com.au (Mark Hammond) Date: Fri, 30 Apr 1999 12:40:09 +1000 Subject: [Python-Dev] More flexible namespaces. Message-ID: <008d01be92b2$c56ef5d0$0801a8c0@bobcat> 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 ), 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. From guido at CNRI.Reston.VA.US Fri Apr 30 05:00:52 1999 From: guido at CNRI.Reston.VA.US (Guido van Rossum) Date: Thu, 29 Apr 1999 23:00:52 -0400 Subject: [Python-Dev] More flexible namespaces. In-Reply-To: Your message of "Fri, 30 Apr 1999 12:40:09 +1000." <008d01be92b2$c56ef5d0$0801a8c0@bobcat> References: <008d01be92b2$c56ef5d0$0801a8c0@bobcat> Message-ID: <199904300300.XAA00608@eric.cnri.reston.va.us> > 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. I agree that this would be seriously cool. It will definitely be in Python 2.0; it's already in JPython. Quite a while ago, Ian Castleden sent me patches for 1.5.1 to do this. It was a lot of code and I was indeed worried about slowing things down too much (and also about checking that he got all the endcases right). Ian did benchmarks and found that the new code was consistently slower, by 3-6%. Perhaps for Python 1.6 this will be acceptable (the "Python IS slow" thread notwithstanding :-); or perhaps someone can have a look at it and squeeze some more time out of it? I'll gladly forward the patches. --Guido van Rossum (home page: http://www.python.org/~guido/) From da at ski.org Fri Apr 30 05:21:04 1999 From: da at ski.org (David Ascher) Date: Thu, 29 Apr 1999 20:21:04 -0700 (Pacific Daylight Time) Subject: [Python-Dev] More flexible namespaces. In-Reply-To: <199904300300.XAA00608@eric.cnri.reston.va.us> Message-ID: > > 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. > > I agree that this would be seriously cool. It will definitely be in > Python 2.0; it's already in JPython. Seriously cool is an understatement. --david From MHammond at skippinet.com.au Fri Apr 30 06:13:25 1999 From: MHammond at skippinet.com.au (Mark Hammond) Date: Fri, 30 Apr 1999 14:13:25 +1000 Subject: [Python-Dev] More flexible namespaces. In-Reply-To: <199904300300.XAA00608@eric.cnri.reston.va.us> Message-ID: <009001be92bf$cb998f80$0801a8c0@bobcat> > Ian did benchmarks and found that the new code was consistently > slower, by 3-6%. Perhaps for Python 1.6 this will be acceptable (the > "Python IS slow" thread notwithstanding :-); or perhaps someone can As long as we get someone working on a consistent 3-6% speedup in other areas this wont be a problem :-) I will attach it to my long list - but Im going to put all my efforts here into Unicode first, and probably the threading stuff second :-) Mark. From tismer at appliedbiometrics.com Fri Apr 30 09:49:42 1999 From: tismer at appliedbiometrics.com (Christian Tismer) Date: Fri, 30 Apr 1999 09:49:42 +0200 Subject: [Python-Dev] More flexible namespaces. References: <008d01be92b2$c56ef5d0$0801a8c0@bobcat> <199904300300.XAA00608@eric.cnri.reston.va.us> Message-ID: <37296096.D0C9C2CC@appliedbiometrics.com> Guido van Rossum wrote: ... > Ian did benchmarks and found that the new code was consistently > slower, by 3-6%. Perhaps for Python 1.6 this will be acceptable (the > "Python IS slow" thread notwithstanding :-); or perhaps someone can > have a look at it and squeeze some more time out of it? I'll gladly > forward the patches. I'd really like to look into that. Also I wouldn't worry too much about speed, since this is such a cool feature. It might even be a speedup in some cases which otherwise would need more complex handling. May I have a look? ciao - chris -- Christian Tismer :^) 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 From mal at lemburg.com Fri Apr 30 10:22:46 1999 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 30 Apr 1999 10:22:46 +0200 Subject: [Python-Dev] More flexible namespaces. References: <008d01be92b2$c56ef5d0$0801a8c0@bobcat> Message-ID: <37296856.5875AAAF@lemburg.com> Mark Hammond wrote: > > 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 involves a whole lot of changes: not only in the Python core, but also in extensions that rely on having real dictionaries available. Since you put out to objectives, I'd like to propose a little different approach... 1. Have eval/exec accept any mapping object as input 2. Make those two copy the content of the mapping object into real dictionaries 3. Provide a hook into the dictionary implementation that can be used to redirect KeyErrors and use that redirection to forward the request to the original mapping objects > This would give us 2 seriously cool features (that I want ), 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. This is covered by 1 and 2. > * 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. This is something for 3. I guess it wouldn't cause any significant slow-down and can be imlemented with much less code than the "change all PyDict_GetItem to PyObject_GetItem" thingie. The real thing could then be done for 2.0 where PyDict_Check() would presumably not rely on an adress but some kind of inheritance scheme indicating that the object is in fact a dictionary. Cheers, -- Marc-Andre Lemburg Y2000: 245 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From guido at CNRI.Reston.VA.US Fri Apr 30 17:17:20 1999 From: guido at CNRI.Reston.VA.US (Guido van Rossum) Date: Fri, 30 Apr 1999 11:17:20 -0400 Subject: [Python-Dev] More flexible namespaces. In-Reply-To: Your message of "Fri, 30 Apr 1999 09:49:42 +0200." <37296096.D0C9C2CC@appliedbiometrics.com> References: <008d01be92b2$c56ef5d0$0801a8c0@bobcat> <199904300300.XAA00608@eric.cnri.reston.va.us> <37296096.D0C9C2CC@appliedbiometrics.com> Message-ID: <199904301517.LAA01422@eric.cnri.reston.va.us> > From: Christian Tismer > I'd really like to look into that. > Also I wouldn't worry too much about speed, since this is > such a cool feature. It might even be a speedup in some cases > which otherwise would need more complex handling. > > May I have a look? Sure! (I've forwarded Christian the files per separate mail.) I'm also interested in your opinion on how well thought-out and robust the patches are -- I've never found the time to do a good close reading of them. --Guido van Rossum (home page: http://www.python.org/~guido/) From gmcm at hypernet.com Fri Apr 30 18:32:30 1999 From: gmcm at hypernet.com (Gordon McMillan) Date: Fri, 30 Apr 1999 11:32:30 -0500 Subject: [Python-Dev] More flexible namespaces. In-Reply-To: <199904301517.LAA01422@eric.cnri.reston.va.us> References: Your message of "Fri, 30 Apr 1999 09:49:42 +0200." <37296096.D0C9C2CC@appliedbiometrics.com> Message-ID: <1286632328-77246936@hypernet.com> Guido wrote: > > From: Christian Tismer > > > I'd really like to look into that. > > Also I wouldn't worry too much about speed, since this is ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > such a cool feature. It might even be a speedup in some cases > > which otherwise would need more complex handling. > > > > May I have a look? > > Sure! > > (I've forwarded Christian the files per separate mail.) I don't know who you sent that to, but it couldn't possibly have been Christian! - Gordon From tismer at appliedbiometrics.com Fri Apr 30 17:57:09 1999 From: tismer at appliedbiometrics.com (Christian Tismer) Date: Fri, 30 Apr 1999 17:57:09 +0200 Subject: [Python-Dev] More flexible namespaces. References: <008d01be92b2$c56ef5d0$0801a8c0@bobcat> <199904300300.XAA00608@eric.cnri.reston.va.us> <37296096.D0C9C2CC@appliedbiometrics.com> <199904301517.LAA01422@eric.cnri.reston.va.us> Message-ID: <3729D2D5.6844D6DA@appliedbiometrics.com> Guido van Rossum wrote: > > > From: Christian Tismer > > May I have a look? > > Sure! > > (I've forwarded Christian the files per separate mail.) Thanks a lot! > I'm also interested in your opinion on how well thought-out and robust > the patches are -- I've never found the time to do a good close > reading of them. Yes, it is quite long and not so very easy to digest. At first glance, most of the changes are replacements of dict access with mapping access where we pay for the extra indirection. It depends on how often this feature will really replace dicts. If dicts are more common, I'd like to figure out how much code bloat extra special casing for dicts would give. Puha - thanks - chris -- Christian Tismer :^) 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 From tismer at appliedbiometrics.com Fri Apr 30 18:19:57 1999 From: tismer at appliedbiometrics.com (Christian Tismer) Date: Fri, 30 Apr 1999 18:19:57 +0200 Subject: [Python-Dev] More flexible namespaces. References: Your message of "Fri, 30 Apr 1999 09:49:42 +0200." <37296096.D0C9C2CC@appliedbiometrics.com> <1286632328-77246936@hypernet.com> Message-ID: <3729D82D.CE16884@appliedbiometrics.com> Gordon McMillan wrote: > > Guido wrote: > > > > From: Christian Tismer > > > > > I'd really like to look into that. > > > Also I wouldn't worry too much about speed, since this is > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > such a cool feature. It might even be a speedup in some cases > > > which otherwise would need more complex handling. > > > > > > May I have a look? > > > > Sure! > > > > (I've forwarded Christian the files per separate mail.) > > I don't know who you sent that to, but it couldn't possibly have been > Christian! :-) :-) truely not if I had'n other things in mind. I know that I will not get more than 30-40 percent by compiling the interpreter away, so I will not even spend time at a register machine right now. Will also not follow the ideas of P2C any longer, doesn't pay off. Instead, If I can manage to create something like static binding snapshots, then I could resolve many of the lookups and internal method indirections, for time critical applications. For all the rest, Python is pretty much fast enough. I've begun to write s special platform dependant version which allows me to do all the things which can't go into the dist. For instance, I just saved some 10 percent by dynamically patching some of the ParseTuple and BuildObject calls out of the core code (ahem). I hope Python will stay as clean as it is, allowing me to try all kinds of tricks for one machine class. ciao - chris.speedy -- Christian Tismer :^) 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 From akuchlin at cnri.reston.va.us Fri Apr 30 18:33:34 1999 From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling) Date: Fri, 30 Apr 1999 12:33:34 -0400 (EDT) Subject: [Python-Dev] More flexible namespaces. In-Reply-To: <3729D82D.CE16884@appliedbiometrics.com> References: <37296096.D0C9C2CC@appliedbiometrics.com> <1286632328-77246936@hypernet.com> <3729D82D.CE16884@appliedbiometrics.com> Message-ID: <14121.55659.754846.708467@amarok.cnri.reston.va.us> Christian Tismer writes: >Instead, If I can manage to create something like static binding >snapshots, then I could resolve many of the lookups and internal >method indirections, for time critical applications. The usual assumption is that the lookups are what takes time. Now, are we sure of that assumption? I'd expect the lookup code to be like: 1) Get hash of name 2) Retrieve object from dictionary 3) Do something with the object. Now, since string objects cache their hash value, 1) should usually be just "if (obj->cached_hash_value!=-1) return obj->cached_hash_value"; a comparision and a return. Step 2) should be very fast, barring a bad hash function. So perhaps most of the time is spent in 3), creating new local dicts, stack frames, and what not. (Yes, I know that doing this on every reference to an object is part of the problem.) I also wonder about the costs of all the Py_BuildValue and Py_ParseTuple calls going on under the hood. A performance improvement project would definitely be a good idea for 1.6, and a good sub-topic for python-dev. Incidentally, what's the verdict on python-dev archives: public or not? -- A.M. Kuchling http://starship.python.net/crew/amk/ Despair says little, and is patient. -- From SANDMAN: "Season of Mists", episode 0 From tismer at appliedbiometrics.com Fri Apr 30 18:55:55 1999 From: tismer at appliedbiometrics.com (Christian Tismer) Date: Fri, 30 Apr 1999 18:55:55 +0200 Subject: [Python-Dev] More flexible namespaces. References: <37296096.D0C9C2CC@appliedbiometrics.com> <1286632328-77246936@hypernet.com> <3729D82D.CE16884@appliedbiometrics.com> <14121.55659.754846.708467@amarok.cnri.reston.va.us> Message-ID: <3729E09B.5F65E3CA@appliedbiometrics.com> "Andrew M. Kuchling" wrote: > > Christian Tismer writes: > >Instead, If I can manage to create something like static binding > >snapshots, then I could resolve many of the lookups and internal > >method indirections, for time critical applications. > > The usual assumption is that the lookups are what takes time. > Now, are we sure of that assumption? I'd expect the lookup code to be > like: > > 1) Get hash of name > 2) Retrieve object from dictionary > 3) Do something with the object. ... Right, but when you become more restrictive, you can do lots, lots more. If I also allow to fix the type of an object, I can go under the hood of the Python API, so you could add some points 4) 5) 6) here. But I shouldn't have talked before I can show something. And at the time, I don't restrict myself to write clean code, but try very machine specific things which I don't believe should go into Python at all. > I also wonder about the costs of all the Py_BuildValue and > Py_ParseTuple calls going on under the hood. A performance > improvement project would definitely be a good idea for 1.6, and a > good sub-topic for python-dev. I wasn't sure, so I first wrote a module which does statistics on that, and I found a lot of these calls. Some are even involved in ceval's code, where things like "(OOOO)" is parsed all over again and again. Now I think this is ok in most cases. But in some places these are very bad: If your builtin function soes so very few work. Take len(): This uses ParseTuple, which calls a function to find out its object, then calls a function to get the object, then takes the len, and builds the result. But since everything has a length, checking for no NULL pointer and grabbing the len produces even shorter code. This applies to many places as well. But right now, I don't change the core, but build hacky little extension modules which squeak such things out at runtime. No big deal yet, but maybe it could pay off to introduce format strings which make them more suitableto be used in macro substitutions. sorry if I was too elaborate, this is so much fun :-) ciao - chris -- Christian Tismer :^) 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 From skip at mojam.com Wed Apr 21 15:17:32 1999 From: skip at mojam.com (skip at mojam.com) Date: Wed, 21 Apr 1999 09:17:32 -0400 Subject: [Python-Dev] ZServer 1.0b1: spurious colon in HTTP response line Message-ID: <199904211317.JAA26167@cm-29-94-14.nycap.rr.com> (Also reported to the bug catcher.) I'm trying to migrate from ZopeHTTPServer to ZServer 1.0b1. I was seeing the ZServer headers turning up in pages generated by the process. When I viewed the page source of the generated HTML I saw: HTTP/1.0: 200 OK Server: Zope/experimental ZServer/1.1b1 Date: Wed, 21 Apr 1999 13:00:38 GMT X-Powered-By: Zope (www.zope.org), Python (www.python.org) Connection: close Content-Type: text/html Content-Length: 7802 Musi-Cal... Concert Schedules: Folk Music, Country Music, Rock Music & more! ... I run ZServer behind an Apache 1.3.3 running mod_proxy. Apparently Apache doesn't recognize the HTTP response when there is a colon following the version number and adds a simple set of headers itself. I guess web browsers either ignore that line or are more lenient in their parsing of the response. The following simple patch corrects the problem: diff -c2 HTTPResponse.py.~1~ HTTPResponse.py *** HTTPResponse.py.~1~ Tue Apr 13 15:21:12 1999 --- HTTPResponse.py Wed Apr 21 09:05:00 1999 *************** *** 146,150 **** # status header must come first. ! append("HTTP/%s: %s" % (self._http_version, status)) if headers.has_key('status'): del headers['status'] --- 146,150 ---- # status header must come first. ! append("HTTP/%s %s" % (self._http_version, status)) if headers.has_key('status'): del headers['status'] *************** Skip Montanaro | Mojam: "Uniting the World of Music" http://www.mojam.com/ skip at mojam.com | Musi-Cal: http://www.musi-cal.com/ 518-372-5583 From da at ski.org Wed Apr 21 20:47:56 1999 From: da at ski.org (David Ascher) Date: Wed, 21 Apr 1999 11:47:56 -0700 (Pacific Daylight Time) Subject: [Python-Dev] Notice of intent: rich comparisons Message-ID: Now that 1.5.2 is finalized, I'll be starting to prepare a patch for the rich comparisons. Guido, how do you envision python-dev working? Do you want to hand out a TODO list for 1.6? --david From guido at CNRI.Reston.VA.US Wed Apr 21 21:04:40 1999 From: guido at CNRI.Reston.VA.US (Guido van Rossum) Date: Wed, 21 Apr 1999 15:04:40 -0400 Subject: [Python-Dev] Notice of intent: rich comparisons In-Reply-To: Your message of "Wed, 21 Apr 1999 11:47:56 PDT." References: Message-ID: <199904211904.PAA14966@eric.cnri.reston.va.us> > Now that 1.5.2 is finalized, I'll be starting to prepare a patch for the > rich comparisons. Cool! > Guido, how do you envision python-dev working? I though we'd just crack Monty Python jokes while pretending to work :-) > Do you want to hand out a TODO list for 1.6? Well, I'm not saying that this is the definitive list, but certainly there are a bunch of things that definitely need to be incorporated. Here's an excerpt of a list that I keep for myself, in no particular order, with brief annotations (I have a meeting in 15 minutes :): Redesign thread/init APIs See the recent discussion in the thread-sig. There should be some kind of micro-init that initializes essential components (including the thread lock!) but doesn't create an interpreter or a threadstate object. There should also be a notion of a default interpreter. Break up into VM, parser, import, mainloop, and other components? The porting efforts to seriously small machines (Win/CE, Pilot, etc.) all seem to need a Python VM that doesn't automatically pull in the parser and interactive main loop. There are other reasons as well to isolate various parts of the functionality (including all numeric data types except ints). This could include: restructuring of the parser so codeop.py can be simplified; making the interactive main loop a script. String methods Barry has his patches ready. Unicode What is the status of /F's latest attempts? Rich comparisons This is Dave's plan. Coercions Marc-Andre Lemburg has some good suggestions here: http://starship.python.net/~lemburg/coercion-0.6.zip Import revamp It should be much easier to add hooks to allow importing from zip files, from a URL, etc., or (different) hooks to allow looking for different extensions (e.g. to automatically generate ILU stubs). This should help the small platforms too, since they often don't have a filesystem, so their imports will have to come from some other place. ANSI C I'm tired of supporting K&R C. All code should be converted to using prototypes. The Py_PROTO macros should go. We can add const-correctness to all code. Too bad for platforms without decent compilers (let them get GCC). Buffer object API extensions Marc-Andre Lemburg has a patch Distutil Should we start integrating some of the results of the distutil SIG? (What's the status? I haven't been paying attention.) Misc Jeremy Hylton's urllib2.py Greg Stein's new httplib.py (or Jeremy's?) Andrew Kuchling's new PCRE release? The IPv6 patches? Gotta run! --Guido van Rossum (home page: http://www.python.org/~guido/) From gward at cnri.reston.va.us Wed Apr 21 21:10:08 1999 From: gward at cnri.reston.va.us (Greg Ward) Date: Wed, 21 Apr 1999 15:10:08 -0400 Subject: [Python-Dev] Notice of intent: rich comparisons In-Reply-To: <199904211904.PAA14966@eric.cnri.reston.va.us>; from Guido van Rossum on Wed, Apr 21, 1999 at 03:04:40PM -0400 References: <199904211904.PAA14966@eric.cnri.reston.va.us> Message-ID: <19990421151008.D6167@cnri.reston.va.us> On 21 April 1999, Guido van Rossum said: > Distutil > > Should we start integrating some of the results of the > distutil SIG? (What's the status? I haven't been paying > attention.) It's in a state that other people can look at the code, but (apparently) not yet good enough for floods of patches to come in. Right now, Distutils has *just* enough marbles to "build" and install itself on Unix systems, and someone has contributed a patch so it works on NT. No support yet for compiling extensions, which of course is the important thing. Greg -- Greg Ward - software developer gward at cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913 From da at ski.org Wed Apr 21 21:19:42 1999 From: da at ski.org (David Ascher) Date: Wed, 21 Apr 1999 12:19:42 -0700 (Pacific Daylight Time) Subject: [Python-Dev] Notice of intent: rich comparisons In-Reply-To: <199904211904.PAA14966@eric.cnri.reston.va.us> Message-ID: On Wed, 21 Apr 1999, Guido van Rossum wrote: > > Guido, how do you envision python-dev working? > > I though we'd just crack Monty Python jokes while pretending to work :-) That'd be better than what I've read on the perl5-porters list in the last couple of days (which I'm reading because of the ad hoopla). They seem to spend their time arguing about whether Perl codes are programs or scripts. Viciously, too. =) More seriously, some of the discussions they're having a worth keeping an eye on, just as a form of legal industrial spying. > Import revamp There was an interesting bit from Greg, Jack, and MarkH on this topic recently in the distutil-sig. Maybe one of them can bring the rest of us up to date on the effort. --david From fredrik at pythonware.com Wed Apr 21 22:04:54 1999 From: fredrik at pythonware.com (Fredrik Lundh) Date: Wed, 21 Apr 1999 22:04:54 +0200 Subject: [Python-Dev] Notice of intent: rich comparisons References: <199904211904.PAA14966@eric.cnri.reston.va.us> Message-ID: <092701be8c32$3a4ad9f0$f29b12c2@pythonware.com> Guido wrote: > String methods > > Barry has his patches ready. > > Unicode > > What is the status of /F's latest attempts? most of the code is written and tested; the API still needs some cleaning up. I also have a few patches and other contributions in my inbox that I gotta look into... btw, the unicode module can be compiled for 8-bit characters too. we could merge it with the string module (one place to fix bugs...) > Import revamp > > It should be much easier to add hooks to allow importing > from zip files, from a URL, etc., or (different) hooks to > allow looking for different extensions (e.g. to automatically > generate ILU stubs). This should help the small platforms > too, since they often don't have a filesystem, so their > imports will have to come from some other place. something similar to greg's imputil.py should definitely be in the core... > ANSI C > > I'm tired of supporting K&R C. All code should be converted > to using prototypes. The Py_PROTO macros should go. We can > add const-correctness to all code. Too bad for platforms > without decent compilers (let them get GCC). or ansi2knr.c (available from http://www.cs.wisc.edu/~ghost/). otoh, it only converts function headers, so I'm not sure it's worth the effort... From beazley at cs.uchicago.edu Wed Apr 21 22:06:50 1999 From: beazley at cs.uchicago.edu (David Beazley) Date: Wed, 21 Apr 1999 15:06:50 -0500 (CDT) Subject: [Python-Dev] Notice of intent: rich comparisons References: <199904211904.PAA14966@eric.cnri.reston.va.us> Message-ID: <199904212006.PAA17138@tartarus.cs.uchicago.edu> Guido van Rossum writes: > > ANSI C > > I'm tired of supporting K&R C. All code should be converted > to using prototypes. The Py_PROTO macros should go. We can > add const-correctness to all code. Too bad for platforms > without decent compilers (let them get GCC). > Maybe I'm just lucky, but I've written nothing but ANSI C for the last 8 years and have never had a problem compiling it on any machine. I don't see this as being a huge issue. > > Misc > Depending on how deep I want to dig, I may have some patches to ParseTuple() that would make life easier for some of us extension writing fans. As it is right now, my experimental version of Swig is using it's own version of ParseTuple (for various reasons). Also, out of curiousity, is anyone making heavy use of the CObject type right now? Cheers, Dave From jim at digicool.com Wed Apr 21 23:15:24 1999 From: jim at digicool.com (Jim Fulton) Date: Wed, 21 Apr 1999 17:15:24 -0400 Subject: [Python-Dev] Notice of intent: rich comparisons References: <199904211904.PAA14966@eric.cnri.reston.va.us> <199904212006.PAA17138@tartarus.cs.uchicago.edu> Message-ID: <371E3FEC.9D19607A@digicool.com> David Beazley wrote: > > Guido van Rossum writes: > > > > ANSI C > > > > I'm tired of supporting K&R C. All code should be converted > > to using prototypes. The Py_PROTO macros should go. We can > > add const-correctness to all code. Too bad for platforms > > without decent compilers (let them get GCC). > > > > Maybe I'm just lucky, but I've written nothing but ANSI C for the last > 8 years and have never had a problem compiling it on any machine. I > don't see this as being a huge issue. I've had the same experience with things like prototypes. The recent introduction of indented preprocessor instructions caused me significant pain on some platforms. Fortunately, I haven't had to deal with those platforms recently, still, the elegence of indented preporicessor instructions wasn't worth the pain it caused. As far as choice of compilers goes, sometimes gcc isn't an option. I've had cases where I *had* to use the native compiler in order to link to third-party libraries. I support moving to ANSI C, for example, wrt prototypes, but lets still be somewhat sensative to portability and not abuse bad compilers without good reason. > > > > > Misc > > > > Depending on how deep I want to dig, I may have some patches to > ParseTuple() that would make life easier for some of us extension > writing fans. As it is right now, my experimental version of Swig > is using it's own version of ParseTuple (for various reasons). > Also, out of curiousity, is anyone making heavy use of the CObject > type right now? Yes. Jim -- Jim Fulton mailto:jim at digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats. From jeremy at cnri.reston.va.us Wed Apr 21 23:23:57 1999 From: jeremy at cnri.reston.va.us (Jeremy Hylton) Date: Wed, 21 Apr 1999 17:23:57 -0400 (EDT) Subject: [Python-Dev] Notice of intent: rich comparisons In-Reply-To: <199904212006.PAA17138@tartarus.cs.uchicago.edu> References: <199904211904.PAA14966@eric.cnri.reston.va.us> <199904212006.PAA17138@tartarus.cs.uchicago.edu> Message-ID: <14110.16787.893181.642806@bitdiddle.cnri.reston.va.us> >>>>> "DB" == David Beazley writes: DB> various reasons). Also, out of curiousity, is anyone making DB> heavy use of the CObject type right now? I used it a little, but only in a modified Python backend for SWIG. Jeremy From mal at lemburg.com Wed Apr 21 23:46:46 1999 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 21 Apr 1999 23:46:46 +0200 Subject: [Python-Dev] Notice of intent: rich comparisons References: <199904211904.PAA14966@eric.cnri.reston.va.us> Message-ID: <371E4746.22A84506@lemburg.com> Guido van Rossum wrote: > > Break up into VM, parser, import, mainloop, and other components? > > The porting efforts to seriously small machines (Win/CE, > Pilot, etc.) all seem to need a Python VM that doesn't > automatically pull in the parser and interactive main loop. > There are other reasons as well to isolate various parts > of the functionality (including all numeric data types except > ints). > > This could include: restructuring of the parser so codeop.py > can be simplified; making the interactive main loop a script. There's some good work out there by Skip Montanaro to revamp the VM into a combined register/stack machine. He calls it rattlesnake. More infos can be found in the list archive (it's currently sleeping): http://www.egroups.com/folders/rattlesnake I would like to see the VM/compiler pluggable so that experiments like rattlesnake become easier to implement (extension modules vs. patches to the core interpreter). > Coercions > > Marc-Andre Lemburg has some good suggestions here: > http://starship.python.net/~lemburg/coercion-0.6.zip I will continue to work on these patches now that 1.5.2 is out. There is a (more or less) detailed explanation of the patch set at: http://starship.skyport.net/~lemburg/CoercionProposal.html Instead of using of using the PY_NEWSTYLENUMBER approach I'll turn to the new type flags that were introduced in 1.5.2. The Py_NotImplemented singleton return value will stay, because performance tests have shown that this method does not cause any significant hit where as the exception raise and catch method does introduce a significant slow-down. > Import revamp Greg's imputil.py (it's in the distutils package) should provide a good start. > Buffer object API extensions I'll put the complete patch up on starship later this week... here are the basic prototypes: DL_IMPORT(int) PyObject_AsCharBuffer Py_PROTO((PyObject *obj, const char **buffer, int *buffer_len)); /* Takes an arbitrary object which must support the (character, single segment) buffer interface and returns a pointer to a read-only memory location useable as character based input for subsequent processing. buffer and buffer_len are only set in case no error occurrs. Otherwise, -1 is returned and an exception set. */ DL_IMPORT(int) PyObject_AsReadBuffer Py_PROTO((PyObject *obj, const void **buffer, int *buffer_len)); /* Same as PyObject_AsCharBuffer() except that this API expects (readable, single segment) buffer interface and returns a pointer to a read-only memory location which can contain arbitrary data. buffer and buffer_len are only set in case no error occurrs. Otherwise, -1 is returned and an exception set. */ DL_IMPORT(int) PyObject_AsWriteBuffer Py_PROTO((PyObject *obj, void **buffer, int *buffer_len)); /* Takes an arbitrary object which must support the (writeable, single segment) buffer interface and returns a pointer to a writeable memory location in buffer of size buffer_len. buffer and buffer_len are only set in case no error occurrs. Otherwise, -1 is returned and an exception set. */ > Distutil > > Should we start integrating some of the results of the > distutil SIG? (What's the status? I haven't been paying > attention.) With all the different modules and packages available for Python starting to slowly introduce dependencies, I think the main objective should be introducing a well organized installation info system, e.g. a registry where modules and packages can query and save version and dependency information. Someone on the main list mentioned that JPython has something like this... > Misc > > Jeremy Hylton's urllib2.py > > Greg Stein's new httplib.py (or Jeremy's?) > > Andrew Kuchling's new PCRE release? > > The IPv6 patches? These are on my wish list, so I'll simply add them here: ? APIs to faciliate creation of extensions classes (using Python classes and C functions as methods) The main open question here is where and how to store C data in the instances. This could also provide a way to migrate to all Python classes for some future version. ? Restructure the calling mechanism used in ceval.c to make it clearer, more flexible and faster (of course, :-). Also, inline calling of C functions/methods (this produces a noticable speedup). I have a patch for the restructuring and an old one (against 1.5) for the C function call inlining. ? A "fastpath" hook made available through the sys module. This should hook into the module/package loader and should be used whenever set to find a module (reverting to the standard lookup method in case it can't find it). I have an old patch that does this. It uses a simple Python function to redirect the lookup to a precalculated dictionary of installed modules/packages. This results in faster startup of the Python interpreter (by saving a few hundred stat() calls). -- Marc-Andre Lemburg Y2000: 254 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From mal at lemburg.com Wed Apr 21 23:51:11 1999 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 21 Apr 1999 23:51:11 +0200 Subject: [Python-Dev] Notice of intent: rich comparisons References: <199904211904.PAA14966@eric.cnri.reston.va.us> <199904212006.PAA17138@tartarus.cs.uchicago.edu> Message-ID: <371E484F.22046FE9@lemburg.com> David Beazley wrote: > > > > > Misc > > > > Depending on how deep I want to dig, I may have some patches to > ParseTuple() that would make life easier for some of us extension > writing fans. As it is right now, my experimental version of Swig > is using it's own version of ParseTuple (for various reasons). > Also, out of curiousity, is anyone making heavy use of the CObject > type right now? You mean the one in Objects/cobject.c ? Sure, all my type extensions export their C API that way... and it works just great (no more linker problems, nice error messages when extensions are not found, etc.). -- Marc-Andre Lemburg Y2000: 254 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From da at ski.org Wed Apr 21 23:56:17 1999 From: da at ski.org (David Ascher) Date: Wed, 21 Apr 1999 14:56:17 -0700 (Pacific Daylight Time) Subject: [Python-Dev] Notice of intent: rich comparisons In-Reply-To: <371E484F.22046FE9@lemburg.com> Message-ID: David Beazley wrote: > Also, out of curiousity, is anyone making heavy use of the CObject > type right now? NumPy does. --da From MHammond at skippinet.com.au Thu Apr 22 01:45:19 1999 From: MHammond at skippinet.com.au (Mark Hammond) Date: Thu, 22 Apr 1999 09:45:19 +1000 Subject: [Python-Dev] Notice of intent: rich comparisons In-Reply-To: <092701be8c32$3a4ad9f0$f29b12c2@pythonware.com> Message-ID: <004c01be8c51$043f27c0$0801a8c0@bobcat> [Guido and /F] > > Unicode > > > > What is the status of /F's latest attempts? > > most of the code is written and tested; the API still > needs some cleaning up. I also have a few patches > and other contributions in my inbox that I gotta > look into... Im one of those contributors :-) I have made changes to the Win32 extensions that allows it to use /F's type instead of its own built-in Unicode type. Further, the Windows CE port of these extensions actually enables this - so we have some code actively using it. However, this still doesnt give me anything more than I had before. We need at least _some_ level of integration of this type into Python. The key areas to me are: * PyArg_ParseTuple and Py_BuildValue - Seems OK we use the "u" format character analogous to "s". We havent thought of a "z" equivilent. This is fairly easy. * Some way for these functions to auto-convert. Eg, when the user passes an 8bit string object, but the C side of the world wants a Unicode string. This is harder, as an extra memory buffer for the conversion is needed. This second problem is, to me, the next stumbling block. When we sort these out, I feel we would have the start of a good platform to start experimenting. Mark. From fdrake at cnri.reston.va.us Thu Apr 22 16:47:35 1999 From: fdrake at cnri.reston.va.us (Fred L. Drake) Date: Thu, 22 Apr 1999 10:47:35 -0400 (EDT) Subject: [Python-Dev] Notice of intent: rich comparisons In-Reply-To: <16290078@toto.iv> Message-ID: <14111.13959.211874.750734@weyr.cnri.reston.va.us> David Beazley writes: > Maybe I'm just lucky, but I've written nothing but ANSI C for the last > 8 years and have never had a problem compiling it on any machine. I > don't see this as being a huge issue. Wasn't SunOS 4.x the problem child here? There are still a lot of people using these systems, for reasons that aren't clear to me. (Did support for some older hardware get dropped? Sounds like the most reasonable reason to use the old OS is legacy hardware.) -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From bwarsaw at cnri.reston.va.us Thu Apr 22 17:37:46 1999 From: bwarsaw at cnri.reston.va.us (Barry A. Warsaw) Date: Thu, 22 Apr 1999 11:37:46 -0400 (EDT) Subject: [Python-Dev] Notice of intent: rich comparisons References: <16290078@toto.iv> <14111.13959.211874.750734@weyr.cnri.reston.va.us> Message-ID: <14111.16970.839894.147748@anthem.cnri.reston.va.us> >>>>> "Fred" == Fred L Drake writes: Fred> Wasn't SunOS 4.x the problem child here? There are still Fred> a lot of people using these systems, for reasons that aren't Fred> clear to me. (Did support for some older hardware get Fred> dropped? Sounds like the most reasonable reason to use the Fred> old OS is legacy hardware.) There might be, but the bundled compiler in SunOS 4 was never intended to be used for anything more than recompiling the kernel. Years ago, I had conversations with Sun engineers who claimed that no bug in the bundled compiler was ever fixed unless it directly impacted on kernel rebuilds. Even back then they recommended using something other than the bundled crufty old K&R compiler for building all other stuff, and this was when there was that huge hoopla over the unbundling of the compiler. SunOS 4 users can probably be mostly satisfied with gcc. -Barry From fdrake at cnri.reston.va.us Thu Apr 22 17:42:57 1999 From: fdrake at cnri.reston.va.us (Fred L. Drake) Date: Thu, 22 Apr 1999 11:42:57 -0400 (EDT) Subject: [Python-Dev] Notice of intent: rich comparisons In-Reply-To: <14111.16970.839894.147748@anthem.cnri.reston.va.us> References: <16290078@toto.iv> <14111.13959.211874.750734@weyr.cnri.reston.va.us> <14111.16970.839894.147748@anthem.cnri.reston.va.us> Message-ID: <14111.17281.999490.718527@weyr.cnri.reston.va.us> Barry A. Warsaw writes: > There might be, but the bundled compiler in SunOS 4 was never intended > to be used for anything more than recompiling the kernel. Years ago, ... > SunOS 4 users can probably be mostly satisfied with gcc. Barry, This is good enough for me. I'd certainly rather avoid K&R C! -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From skip at mojam.com Thu Apr 22 19:18:39 1999 From: skip at mojam.com (skip at mojam.com) Date: Thu, 22 Apr 1999 13:18:39 -0400 (EDT) Subject: [Python-Dev] Notice of intent: rich comparisons In-Reply-To: <14111.17281.999490.718527@weyr.cnri.reston.va.us> References: <16290078@toto.iv> <14111.13959.211874.750734@weyr.cnri.reston.va.us> <14111.16970.839894.147748@anthem.cnri.reston.va.us> <14111.17281.999490.718527@weyr.cnri.reston.va.us> Message-ID: <14111.22873.161727.15206@cm-29-94-14.nycap.rr.com> Barry> SunOS 4 users can probably be mostly satisfied with gcc. Fred> This is good enough for me. I'd certainly rather avoid K&R C! Besides, aren't there tools available that can strip most of the ANSI-ness out of ANSI C? (Un)Protoize? For those (few?) people who are really still stuck using a K&R compiler I would think those tools, perhaps supplemented with some patch files maintained outside the main Python source tree, would be sufficient. Skip Montanaro | Mojam: "Uniting the World of Music" http://www.mojam.com/ skip at mojam.com | Musi-Cal: http://www.musi-cal.com/ 518-372-5583 From bwarsaw at cnri.reston.va.us Thu Apr 22 20:07:57 1999 From: bwarsaw at cnri.reston.va.us (Barry A. Warsaw) Date: Thu, 22 Apr 1999 14:07:57 -0400 (EDT) Subject: [Python-Dev] Notice of intent: rich comparisons References: <16290078@toto.iv> <14111.13959.211874.750734@weyr.cnri.reston.va.us> <14111.16970.839894.147748@anthem.cnri.reston.va.us> <14111.17281.999490.718527@weyr.cnri.reston.va.us> <14111.22873.161727.15206@cm-29-94-14.nycap.rr.com> Message-ID: <14111.25981.74738.355264@anthem.cnri.reston.va.us> >>>>> "skip" == writes: skip> Besides, aren't there tools available that can strip most of skip> the ANSI-ness out of ANSI C? (Un)Protoize? I think so. Seems I have unprotoize already; probably got it for free with gcc, or some other GNU tool. -B From skip at mojam.com Thu Apr 22 20:22:51 1999 From: skip at mojam.com (skip at mojam.com) Date: Thu, 22 Apr 1999 14:22:51 -0400 (EDT) Subject: [Python-Dev] Notice of intent: rich comparisons In-Reply-To: <371E4746.22A84506@lemburg.com> References: <199904211904.PAA14966@eric.cnri.reston.va.us> <371E4746.22A84506@lemburg.com> Message-ID: <14111.23085.737365.582406@cm-29-94-14.nycap.rr.com> mal> There's some good work out there by Skip Montanaro to revamp the VM mal> into a combined register/stack machine. He calls it rattlesnake. mal> More infos can be found in the list archive (it's currently mal> sleeping): Thanks to Marc-Andre for mentioning this. Rattlesnake is indeed sleeping at the moment. If anyone is interested in the idea I'd be happy to awaken it. The main observation was that much of the virtual machine's activity is pushing/popping objects to/from the stack. By treating a chunk of storage as a register file much of that churn can be avoided. Skip Montanaro | Mojam: "Uniting the World of Music" http://www.mojam.com/ skip at mojam.com | Musi-Cal: http://www.musi-cal.com/ 518-372-5583 From fredrik at pythonware.com Fri Apr 23 09:48:14 1999 From: fredrik at pythonware.com (Fredrik Lundh) Date: Fri, 23 Apr 1999 09:48:14 +0200 Subject: [Python-Dev] Compiling ANSI C on K&R compilers References: <16290078@toto.iv><14111.13959.211874.750734@weyr.cnri.reston.va.us><14111.16970.839894.147748@anthem.cnri.reston.va.us><14111.17281.999490.718527@weyr.cnri.reston.va.us> <14111.22873.161727.15206@cm-29-94-14.nycap.rr.com> Message-ID: <00df01be8d5d$a82b2f70$f29b12c2@pythonware.com> > Besides, aren't there tools available that can strip most of the ANSI-ness > out of ANSI C? (Un)Protoize? For those (few?) people who are really still > stuck using a K&R compiler I would think those tools, perhaps supplemented > with some patch files maintained outside the main Python source tree, would > be sufficient. I mentioned ansi2knr.c in an earlier post. It's a small utility, and can be distributed with the Python core (it's GPL'd, but since it isn't linked with Python, that's not a problem). this is used by ghostscript and the ijg jpeg library, among others: ftp://ftp.cs.wisc.edu/ghost/ansi2knr.c (or via http://www.cs.wisc.edu/~ghost/) Cheers /F fredrik at pythonware.com http://www.pythonware.com From gstein at lyra.org Fri Apr 23 12:37:02 1999 From: gstein at lyra.org (Greg Stein) Date: Fri, 23 Apr 1999 03:37:02 -0700 Subject: [Python-Dev] Notice of intent: rich comparisons References: <199904211904.PAA14966@eric.cnri.reston.va.us> Message-ID: <37204D4E.2C02ABE2@lyra.org> Guido van Rossum wrote: >... > Import revamp > > It should be much easier to add hooks to allow importing > from zip files, from a URL, etc., or (different) hooks to > allow looking for different extensions (e.g. to automatically > generate ILU stubs). This should help the small platforms > too, since they often don't have a filesystem, so their > imports will have to come from some other place. I would recommend that Python's import mechanism be changed to use some of the concepts from my imputil.py module and in a couple of my posts to distutils-sig: http://www.python.org/pipermail/distutils-sig/1999-January/000142.html http://www.python.org/pipermail/distutils-sig/1998-December/000077.html > ANSI C > > I'm tired of supporting K&R C. All code should be converted > to using prototypes. The Py_PROTO macros should go. We can > add const-correctness to all code. Too bad for platforms > without decent compilers (let them get GCC). Or those platforms can stick with Python 1.5.2 > Misc > > Jeremy Hylton's urllib2.py > > Greg Stein's new httplib.py (or Jeremy's?) Mine is a drop-in replacement for the current httplib.py. httplib.HTTP is compatible with the current version and does HTTP/1.0. httplib.HTTPConnection is similar to the other (but (IMO) cleans up a few elements of the API); it does HTTP/1.1, including persistent connections. This module follows the design of the original httplib.py much more closely. Jeremy's module uses a very different design approach (no value judgement here; it's just different); also, it simply copies over the old HTTP class, while mine derives the compatible version from HTTPConnection. I'm not sure how much testing Jeremy's has had, but I use my module for all Python-based http work now. Some number of other people have downloaded and used it, too. I would recommend my new module, given the two options. I'll eventually have a davlib.py to add to the distribution, but it needs more work. I'll contribute that later. --- I'd also like to see some cleanup of the build process. For example, (Guido:) I sent in a different way to handle the signal stuff (shifting files around and stuff) as opposed to the "hassignal" thing. About the build process: it may be nice to move to a single makefile. Here is an interesting paper about this: http://www.canb.auug.org.au/~millerp/rmch/recu-make-cons-harm.html Is it reasonable to split out the Demo, Doc, Misc, and Tools subdirs since those never really end up as part of an installed Python? e.g. into a python-extras distribution? (which would allow doc and tools updates at arbitrary times) Does it make sense to remove platform-specific modules? (e.g. the SGI modules) While distutils doesn't have anything *yet*, there are changes that can be made in the build process to improve the distutils process. I know that Greg Ward wants distutils to work on previous versions of Python, but (IMO) things would be simpler all around if distutils-based packages were simply designed for 1.6 systems as a basic dependency. However, that choice is quite separate from the decision to generate distutils support during the build. Oh: there were some things floating around at one point about using Python itself within the build process (e.g. for modules). Is any of that work useful? Cheers, -g -- Greg Stein, http://www.lyra.org/ From fdrake at cnri.reston.va.us Fri Apr 23 15:28:12 1999 From: fdrake at cnri.reston.va.us (Fred L. Drake) Date: Fri, 23 Apr 1999 09:28:12 -0400 (EDT) Subject: [Python-Dev] Notice of intent: rich comparisons In-Reply-To: <37204D4E.2C02ABE2@lyra.org> References: <199904211904.PAA14966@eric.cnri.reston.va.us> <37204D4E.2C02ABE2@lyra.org> Message-ID: <14112.30060.552422.975547@weyr.cnri.reston.va.us> Greg Stein writes: > Is it reasonable to split out the Demo, Doc, Misc, and Tools subdirs > since those never really end up as part of an installed Python? e.g. > into a python-extras distribution? (which would allow doc and tools > updates at arbitrary times) The Doc/ stuff is already in a separate distribution; this has been in place for about a year (if I recall correctly). I try to make doc releases shortly after Python releases (I think the 1.5.2 doc release is the longest I've waited past the Python release so far, and it may end up being next week), and I have made interim releases as the documentation has grown. I certainly think that doing something similar for the Demo/ and Tools/ directories would be reasonable; they could share a single distribution. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From skip at mojam.com Fri Apr 23 15:59:02 1999 From: skip at mojam.com (skip at mojam.com) Date: Fri, 23 Apr 1999 09:59:02 -0400 (EDT) Subject: [Python-Dev] Notice of intent: rich comparisons In-Reply-To: <14112.30060.552422.975547@weyr.cnri.reston.va.us> References: <199904211904.PAA14966@eric.cnri.reston.va.us> <37204D4E.2C02ABE2@lyra.org> <14112.30060.552422.975547@weyr.cnri.reston.va.us> Message-ID: <14112.31858.374462.469793@cm-29-94-14.nycap.rr.com> Fred> I certainly think that doing something similar for the Demo/ and Fred> Tools/ directories would be reasonable; they could share a single Fred> distribution. We need to make sure none of the tools are needed in the install process. h2py comes to mind. Skip Montanaro | Mojam: "Uniting the World of Music" http://www.mojam.com/ skip at mojam.com | Musi-Cal: http://www.musi-cal.com/ 518-372-5583 From jeremy at cnri.reston.va.us Mon Apr 26 17:26:28 1999 From: jeremy at cnri.reston.va.us (Jeremy Hylton) Date: Mon, 26 Apr 1999 11:26:28 -0400 (EDT) Subject: [Python-Dev] Notice of intent: rich comparisons In-Reply-To: <37204D4E.2C02ABE2@lyra.org> References: <199904211904.PAA14966@eric.cnri.reston.va.us> <37204D4E.2C02ABE2@lyra.org> Message-ID: <14116.33341.371508.53071@bitdiddle.cnri.reston.va.us> >>>>> "GS" == Greg Stein writes: >> Greg Stein's new httplib.py (or Jeremy's?) GS> Mine is a drop-in replacement for the current GS> httplib.py. httplib.HTTP is compatible with the current version GS> and does HTTP/1.0. httplib.HTTPConnection is similar to the GS> other (but (IMO) cleans up a few elements of the API); it does GS> HTTP/1.1, including persistent connections. This module follows GS> the design of the original httplib.py much more GS> closely. Jeremy's module uses a very different design approach GS> (no value judgement here; it's just different); also, it simply GS> copies over the old HTTP class, while mine derives the GS> compatible version from HTTPConnection. I'm not sure how much GS> testing Jeremy's has had, but I use my module for all GS> Python-based http work now. Some number of other people have GS> downloaded and used it, too. GS> I would recommend my new module, given the two options. I think I agree. I stopped working on my version quite some time ago, before I made enough progress to make it useful. Thus, it makes a lot of sense to use Greg's working code. I'd be curious to see how to use HTTPConnection to do persistent connections and pipelined requests. It wasn't entirely clear from the code what I would need to do to keep the connection open. Do you just re-use the HTTPConnection object -- call putrequest again after getreply? I like the revised API that Greg's code uses. The request method on HTTPConnection objects cleans the API up in exactly the right way. It has always seemed unnecessary to have many separate calls to add headers and then a call to endheaders after putrequest. Packaging them all together in one method will simplify client code a lot. GS> I'll eventually have a davlib.py to add to the distribution, but GS> it needs more work. I'll contribute that later. Cool! Jeremy From guido at CNRI.Reston.VA.US Mon Apr 26 18:16:11 1999 From: guido at CNRI.Reston.VA.US (Guido van Rossum) Date: Mon, 26 Apr 1999 12:16:11 -0400 Subject: [Python-Dev] Public or private python-dev archives? Message-ID: <199904261616.MAA22036@eric.cnri.reston.va.us> In a private mail, Greg Stein suggested that the python-dev archives should be restricted to the members of the list. I prefer to make them public, but I won't want to impose this on others without discussion. So I've made the archives private for the time being while we discuss this meta-issue. (Also, the existence of the list isn't announced by mailman on its listinfo page.) Here's my argument for open archives. I don't think that we have anything to hide from the public -- I think of us as a technical forum whose discussions may affect others (e.g. Python users) and I think it's often useful for those others to be able to see what we've said. I want to keep membership of the list closed as a gentle way to enforce focus and quality of discussion. Jeremy pointed out that there's no restiction on posting, and mentioned that together with open archives this makes the list just as open as an open-subscription list. I don't see this equivalence -- certainly it makes a difference in practice, and the open posting is simply a mechanism to allow members with multiple email addresses to post from whereever they are. If we regularly get spammed or find the list is targeted by angry Python users we might have to restrict posting to members (and deal with the multiple address problem). I hope the discussion about this issue will be short (otherwise it would detract from the real goal of this list). I'll follow the desire of the majority of current members; once we have a decision I propose to stick with it and simply present new members with the facts. --Guido van Rossum (home page: http://www.python.org/~guido/) From gward at cnri.reston.va.us Mon Apr 26 18:30:43 1999 From: gward at cnri.reston.va.us (Greg Ward) Date: Mon, 26 Apr 1999 12:30:43 -0400 Subject: [Python-Dev] Public or private python-dev archives? In-Reply-To: <199904261616.MAA22036@eric.cnri.reston.va.us>; from Guido van Rossum on Mon, Apr 26, 1999 at 12:16:11PM -0400 References: <199904261616.MAA22036@eric.cnri.reston.va.us> Message-ID: <19990426123042.A2617@cnri.reston.va.us> On 26 April 1999, Guido van Rossum said: > In a private mail, Greg Stein suggested that the python-dev archives > should be restricted to the members of the list. I prefer to make > them public, but I won't want to impose this on others without > discussion. So I've made the archives private for the time being > while we discuss this meta-issue. (Also, the existence of the list > isn't announced by mailman on its listinfo page.) > > Here's my argument for open archives. I don't think that we have > anything to hide from the public -- I think of us as a technical forum > whose discussions may affect others (e.g. Python users) and I think > it's often useful for those others to be able to see what we've said. I favour as much openness as possible that's consistent with high signal-to-noise. Opening the archives doesn't affect SN ratio; for that matter, neither does allowing anyone to *read* the list while keeping posting privileges restricted. And letting the world know that the list exists -- even though posting privileges are restricted -- shouldn't affect quality. So I guess my position is: definitely open the archives and publicise the list -- the benefit of an open archive is reduced if people can't stumble across it like they can any sig. And consider the possibility of open subscription while keeping posting restricted. Not sure how easy that is with Mailman, but we can still consider the idea. The open, friendly nature of the Python community is a huge strength. I tentatively agree that posting privileges should be restricted to keep quality high, but the idea of a "secret cabal" discussing Python development off in a dark corner away from the grubby masses seems very counter to the spirit I've seen so far. Greg -- Greg Ward - software developer gward at cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913 From da at ski.org Mon Apr 26 18:29:56 1999 From: da at ski.org (David Ascher) Date: Mon, 26 Apr 1999 09:29:56 -0700 (Pacific Daylight Time) Subject: [Python-Dev] Public or private python-dev archives? In-Reply-To: <199904261616.MAA22036@eric.cnri.reston.va.us> Message-ID: On Mon, 26 Apr 1999, Guido van Rossum wrote: > In a private mail, Greg Stein suggested that the python-dev archives > should be restricted to the members of the list. I prefer to make > them public, but I won't want to impose this on others without > discussion. So I've made the archives private for the time being > while we discuss this meta-issue. (Also, the existence of the list > isn't announced by mailman on its listinfo page.) If one has a public archive with restricted membership, then one needs to have a process for people to petition membership, including policies on deciding admission (which could be as vague as "up to GvR's whim"). FWIW, the perl5-porters list is open but the perl6-porters list is closed. My suggestion is that we can start with an open policy on archives, and the lax posting policy for the multiple email address business (which should be incorporated in mailman++ =), with the explicitely stated caveat that if it turns out that that policy doesn't work, we reserve the right to tighten things up. I also suggest that we don't advertise the fact that anyone can post. [Except of course that we've just mentioned this in archives which I'm arguing should be public =)] --david From bwarsaw at cnri.reston.va.us Mon Apr 26 19:44:36 1999 From: bwarsaw at cnri.reston.va.us (Barry A. Warsaw) Date: Mon, 26 Apr 1999 13:44:36 -0400 (EDT) Subject: [Python-Dev] Public or private python-dev archives? References: <199904261616.MAA22036@eric.cnri.reston.va.us> <19990426123042.A2617@cnri.reston.va.us> Message-ID: <14116.42500.284907.569281@anthem.cnri.reston.va.us> >>>>> "GW" == Greg Ward writes: GW> And consider the possibility of open subscription while GW> keeping posting restricted. Not sure how easy that is with GW> Mailman, but we can still consider the idea. It could be done in a number of ways. You could restrict postings to members only, but as Guido has pointed out, a lot of people post from more than one account and Mailman doesn't handle that very well yet. Or you could moderate the list, but then someone has to approve postings and that's more work than I think anybody wants to do. I'm also for an open-as-possible policy, with the right to restrict later if the s/n gets too low. I sort of view Python-dev to be the place that serious c.l.py proposals get fleshed out and implementation strategies discussed. The (hopefully) high level of technical detail on the list should self-select. -Barry From gmcm at hypernet.com Mon Apr 26 20:56:52 1999 From: gmcm at hypernet.com (Gordon McMillan) Date: Mon, 26 Apr 1999 13:56:52 -0500 Subject: [Python-Dev] Public or private python-dev archives? In-Reply-To: <14116.42500.284907.569281@anthem.cnri.reston.va.us> Message-ID: <1286969269-56980208@hypernet.com> [Barry] > The (hopefully) high level of > technical detail on the list should self-select. I thought the humor did that. If the public-archive were only updated weekly, it would make it's use (or abuse) as glorified help list pretty tenuous. No one has espoused Greg's reasoning. In the abscense of said arguments, I'm certainly inclined to vote for "as public as can be and still be focused". -OTOH-then-I'll-never-know-what-goes-on-in-the-smoke-filled-room-ly y'rs - Gordon From da at ski.org Mon Apr 26 21:12:54 1999 From: da at ski.org (David Ascher) Date: Mon, 26 Apr 1999 12:12:54 -0700 (Pacific Daylight Time) Subject: [Python-Dev] Why unbundle Tools and Demo? Message-ID: Several people argue for unbundling Tools/ and Demo/ in 1.6. I'd like to argue to leave them in. They're not especially big, and IMHO they are quite valuable, *especially* to the novice user. In fact, I'd like to argue that Demo/ should be promoted to the same status as Tools/ (by which I mean included in the Windows binary distribution). Unbundling Tools/ would mean unbundling IDLE, which IMHO would be a big strategic mistake. However, I wouldn't be against a cleanup of said directories. Some things should probably be removed (anything which uses stdwin), some of the code in classes is showing its age (notes about "being upgraded for Python 1.1" =), etc. That said, the tkinter/ directory is the best place to look for simple Tkinter code, and should be included, IMHO. --david From guido at CNRI.Reston.VA.US Mon Apr 26 21:20:26 1999 From: guido at CNRI.Reston.VA.US (Guido van Rossum) Date: Mon, 26 Apr 1999 15:20:26 -0400 Subject: [Python-Dev] Why unbundle Tools and Demo? In-Reply-To: Your message of "Mon, 26 Apr 1999 12:12:54 PDT." References: Message-ID: <199904261920.PAA22415@eric.cnri.reston.va.us> > Several people argue for unbundling Tools/ and Demo/ in 1.6. I'd like to > argue to leave them in. They're not especially big, and IMHO they are > quite valuable, *especially* to the novice user. In fact, I'd like to > argue that Demo/ should be promoted to the same status as Tools/ (by which > I mean included in the Windows binary distribution). Unbundling Tools/ > would mean unbundling IDLE, which IMHO would be a big strategic mistake. > > However, I wouldn't be against a cleanup of said directories. Some things > should probably be removed (anything which uses stdwin), some of the code > in classes is showing its age (notes about "being upgraded for Python 1.1" > =), etc. That said, the tkinter/ directory is the best place to look for > simple Tkinter code, and should be included, IMHO. Agreed. One simple thing that would help me immensely would be for someone to go through all the various Demo directories and make an inventary of what is there and how useful it is, (1) to all Python users, (2) to Windows users. Then, perhaps someone could write a simple document making these files (and Tools) more accessible... --Guido van Rossum (home page: http://www.python.org/~guido/) From da at ski.org Mon Apr 26 21:20:40 1999 From: da at ski.org (David Ascher) Date: Mon, 26 Apr 1999 12:20:40 -0700 (Pacific Daylight Time) Subject: [Python-Dev] Why unbundle Tools and Demo? In-Reply-To: <199904261920.PAA22415@eric.cnri.reston.va.us> Message-ID: > someone to go through all the various Demo directories and make an > inventary of what is there and how useful it is, (1) to all Python > users, (2) to Windows users. Then, perhaps someone could write a > simple document making these files (and Tools) more accessible... Ok. I can do that. From guido at CNRI.Reston.VA.US Mon Apr 26 21:22:55 1999 From: guido at CNRI.Reston.VA.US (Guido van Rossum) Date: Mon, 26 Apr 1999 15:22:55 -0400 Subject: [Python-Dev] Why unbundle Tools and Demo? In-Reply-To: Your message of "Mon, 26 Apr 1999 12:20:40 PDT." References: Message-ID: <199904261922.PAA22447@eric.cnri.reston.va.us> [me] > > someone to go through all the various Demo directories and make an > > inventary of what is there and how useful it is, (1) to all Python > > users, (2) to Windows users. Then, perhaps someone could write a > > simple document making these files (and Tools) more accessible... [Dave] > Ok. I can do that. Great! I didn't mean to volunteer you -- but I think you'd do a great job. --Guido van Rossum (home page: http://www.python.org/~guido/) From tim_one at email.msn.com Tue Apr 27 06:25:19 1999 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 27 Apr 1999 00:25:19 -0400 Subject: [Python-Dev] Public or private python-dev archives? In-Reply-To: <19990426123042.A2617@cnri.reston.va.us> Message-ID: <000501be9065$f5e3db80$ab9e2299@tim> [Greg Ward, arguing in favor of ... a "secret cabal" discussing Python development off in a dark corner away from the grubby masses ] That's what I'd like too -- but somebody already let Gordon in . voting-to-leave-it-public-until-there's-a-problem-ly y'rs - tim From da at ski.org Tue Apr 27 21:23:55 1999 From: da at ski.org (David Ascher) Date: Tue, 27 Apr 1999 12:23:55 -0700 (Pacific Daylight Time) Subject: [Python-Dev] numpy Message-ID: What are the thoughts on NumPy integration into the core? --David From MHammond at skippinet.com.au Wed Apr 28 01:28:59 1999 From: MHammond at skippinet.com.au (Mark Hammond) Date: Wed, 28 Apr 1999 09:28:59 +1000 Subject: [Python-Dev] numpy In-Reply-To: Message-ID: <001c01be9105$bae7ccd0$0801a8c0@bobcat> > What are the thoughts on NumPy integration into the core? he he - and while we are at it :-) mxDateTime would need to be a popular choice for inclusion, and Guido has offered in-principle support for moving some of the Win32 stuff into the core - particularly the Registry stuff and the native Window Handle support... How far do we go :-) Personally, I would simply like to see the distutils SIG solve this problem for us. (sure). Eg, the "build" or "install" process (depending on the OS) could build a local HTML file with knowledge many "common" extensions - a single click, and it is downloaded, configured and built. Oh well, back to reality... [Which isnt to say I am opposed to NumPy and mxDateTime. Definately keen on the win32 stuff tho :-] Mark. From da at ski.org Wed Apr 28 01:31:56 1999 From: da at ski.org (David Ascher) Date: Tue, 27 Apr 1999 16:31:56 -0700 (Pacific Daylight Time) Subject: [Python-Dev] numpy In-Reply-To: <001c01be9105$bae7ccd0$0801a8c0@bobcat> Message-ID: On Wed, 28 Apr 1999, Mark Hammond wrote: > > What are the thoughts on NumPy integration into the core? > > he he - and while we are at it :-) mxDateTime would need to be a popular > choice for inclusion, and Guido has offered in-principle support for moving > some of the Win32 stuff into the core - particularly the Registry stuff and > the native Window Handle support... It may seem strange, but I'll argue for the win32 registry calls before the NumPy stuff. That could be because I've looked at NumPy code and not the win32 code. Not Jim's cleanest code. =) Mark, can you describe 'native Window Handle' support? --david From MHammond at skippinet.com.au Wed Apr 28 07:03:48 1999 From: MHammond at skippinet.com.au (Mark Hammond) Date: Wed, 28 Apr 1999 15:03:48 +1000 Subject: [Python-Dev] numpy In-Reply-To: Message-ID: <001e01be9134$809ca8f0$0801a8c0@bobcat> > It may seem strange, but I'll argue for the win32 registry > calls before > the NumPy stuff. That could be because I've looked at NumPy > code and not > the win32 code. Not Jim's cleanest code. =) he he - and I can even get out of the Win32 stuff - I wrote a string-only first version, and Bill Tutt rehashed it into what it is today, handling all the registry types. OTOH, there could also be a case for moving "win32api" completely to "core status" (whether that means truly core or simply a standard .pyd). For example, ntpath.py now has code that attempts to use "win32api.GetFullPathName()". The down-side is that win32api has nowhere near complete coverage, and is really a mixed bag of bits and pieces. Most later efforts where complete API sets are given coverage have different names - eg, win32file has the complete Win32 file API wrapped up - even if there are overlaps with existing functions in win32api. Im not sure what the answer is - my guess is a new core module with Win32 features deemed absolutely necessary for the core - stuff like the registry, and a few assorted other functions, such as GetFullPathName, but stopping well short of the full win32api set. > Mark, can you describe 'native Window Handle' support? Sure! We have a very light-weight "handle" object, representing a Win32 handle. It has no methods, and a single property for returning the underlying win32 handle as an integer. When the object destructs, it calls "CloseHandle()". Thats about it! It has no methods, so is passed as an argument. There has been no attempt to implement things like "handle.Read()" to represent "ReadFile(handle, ...)". There are 2 reasons for this: 1) Handles are fairly general purpose, and not restricted to IO operations. A handle is also used to represent a Mutex/Semaphores and threads/processes - certainly doesnt make sense to have a "Read()" method for those handles. 2) IMO, this should be done at the .py level anyway. The Win32 Handle support is pure C++ at the moment. A simple complication is that there are 3 types of handles in use at the moment - those that call "CloseHandle", those that call "RegCloseHandle" (registry handles) and a 3rd I cant recall. This is currently implemented using C++ inheritance. But even if the current implementation is not favoured, the object is so small that a rewrite would not be a problem. And for those that can be bothered to read this far, some more background: Some time ago, Greg and I decided to implement a "pywintypes" module. This defines what we considered "core types" for the Win32 world. All our extension modules (including win32api, COM; basically win32*.pyd) use this module. The objects it supports are: Unicode, Handles, Win32 Time, IIDs, Overlapped IO objects, 3 NT security related objects and importantly a standard Win32 exception and functions for filling it. Moving the registry stuff is dependant on the core having the Exception, Handle and Registry support (hence this discussion). We have our own Time object, but mxDateTime would be fine. One day, we hope to remove this pywintypes entirely, as the core will have it all :-) Mark. From gward at cnri.reston.va.us Wed Apr 28 14:51:43 1999 From: gward at cnri.reston.va.us (Greg Ward) Date: Wed, 28 Apr 1999 08:51:43 -0400 Subject: [Python-Dev] numpy In-Reply-To: <001c01be9105$bae7ccd0$0801a8c0@bobcat>; from Mark Hammond on Wed, Apr 28, 1999 at 09:28:59AM +1000 References: <001c01be9105$bae7ccd0$0801a8c0@bobcat> Message-ID: <19990428085143.A5571@cnri.reston.va.us> On 28 April 1999, Mark Hammond said: > How far do we go :-) > > Personally, I would simply like to see the distutils SIG solve this problem > for us. (sure). Eg, the "build" or "install" process (depending on the > OS) could build a local HTML file with knowledge many "common" extensions - > a single click, and it is downloaded, configured and built. Oh well, back > to reality... It's not impossible, it just takes a while. I think it took the Perl community about three years to go from "hey! let's have a standard build mechanism for modules!" to the point where I can install (almost) any module from CPAN with one shell command: perl -MCPAN -e 'install ("MIME::Base64");' which is insanely cool. (It took about two minutes to do the above just now; that included trying two CPAN mirrors that aren't being cooperative this morning, finding one that was working, downloading the current module list from it, determining that there is a more recent version available than the one installed here, downloading it, unpacking it, running "Makefile.PL" to generate the Makefile, running "make" [which compiles any extensions in the distribution, copies all the .pm files around, and generates the documentation], "make test" [run the module's self-test suite], and "make install" [install it in the "site-perl" library directory]. Amount of user interaction required: typing the above command line.) It's *still* rough around the edges, though, especially when building a new installation from scratch -- mainly because Perl doesn't ship with ftp or http libraries, so the CPAN.pm module has to try downloading stuff with lynx, ncftp, or plain ol' ftp until it has downloaded and installed the libnet and libwww-perl distributions. That's one problem we won't have with Python, at least. Oh yeah, and it all works *great* under Unix... but the rest of the world lags behind. Also, two major components of being able to do this -- the Perl Module List and CPAN -- are still vapourware in Python-land. But hey, if we can get to the "we *have* a standard build mechanism for modules!" point, then all the rest becomes a lot more feasible. Pep talk over... Greg -- Greg Ward - software developer gward at cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913 From mal at lemburg.com Wed Apr 28 09:44:25 1999 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 28 Apr 1999 09:44:25 +0200 Subject: [Python-Dev] numpy References: <001c01be9105$bae7ccd0$0801a8c0@bobcat> Message-ID: <3726BC59.35E3C9DB@lemburg.com> Mark Hammond wrote: > > > What are the thoughts on NumPy integration into the core? > > he he - and while we are at it :-) mxDateTime would need to be a popular > choice for inclusion, and Guido has offered in-principle support for moving > some of the Win32 stuff into the core - particularly the Registry stuff and > the native Window Handle support... > > How far do we go :-) > > Personally, I would simply like to see the distutils SIG solve this problem > for us. (sure). Eg, the "build" or "install" process (depending on the > OS) could build a local HTML file with knowledge many "common" extensions - > a single click, and it is downloaded, configured and built. Oh well, back > to reality... You're talking about fast moving targets there... are you sure that you want those in the standard distribution ? Maybe we have two distributions: the standard one and a pro edition with all the slick stuff included (together with a proper setup script to get those references to external libs and include files right). Actually, this is something I've been wanting to do for nearly a year now... just haven't found the time to really get things the way I want them. It's a project called Python Power Tools and includes many generic extensions (currently only ones that don't rely on external libs). If you're interested, have a look at an old version available at: http://starship.skyport.net/~lemburg/PowerTools-0.2.zip It includes the extensions BTree, mxDateTime, mxTools, mxStack, Trie, avl and kjbuckets. NumPy should probably also be included. The current setup uses a recursive Makefile approach (not too elegant, but works). A distutils setup would be much better. -- Marc-Andre Lemburg Y2000: 247 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From jack at oratrix.nl Wed Apr 28 15:48:21 1999 From: jack at oratrix.nl (Jack Jansen) Date: Wed, 28 Apr 1999 15:48:21 +0200 Subject: [Python-Dev] numpy In-Reply-To: Message by "Mark Hammond" , Wed, 28 Apr 1999 09:28:59 +1000 , <001c01be9105$bae7ccd0$0801a8c0@bobcat> Message-ID: <19990428134821.E9A68300F57@snelboot.oratrix.nl> > [...] Guido has offered in-principle support for moving > some of the Win32 stuff into the core - particularly the Registry stuff and > the native Window Handle support... I think it would be nice to put all the stuff that is shared between modules (I think that's only PyWinTypes, but who am I to think I have a clue about the windows port:-) into the core. I just did the same for MacPython, and it makes life a whole lot easier. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at 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 From skip at mojam.com Wed Apr 28 17:57:40 1999 From: skip at mojam.com (skip at mojam.com) Date: Wed, 28 Apr 1999 11:57:40 -0400 Subject: [Python-Dev] LLNL C++ as base for Python 2? Message-ID: <199904281557.LAA06491@cm-29-94-14.nycap.rr.com> Have we been talking about Python 2 or Python 1.6? If we're talking about Python 2, has anyone given a serious look at the LLNL gang's C++/Python stuff? If I recall Paul Dubois' talk at the last conference, it sounded like their work made it much easier to implement extension modules. Skip Montanaro | Mojam: "Uniting the World of Music" http://www.mojam.com/ skip at mojam.com | Musi-Cal: http://www.musi-cal.com/ 518-372-5583 From guido at CNRI.Reston.VA.US Wed Apr 28 18:06:03 1999 From: guido at CNRI.Reston.VA.US (Guido van Rossum) Date: Wed, 28 Apr 1999 12:06:03 -0400 Subject: [Python-Dev] LLNL C++ as base for Python 2? In-Reply-To: Your message of "Wed, 28 Apr 1999 11:57:40 EDT." <199904281557.LAA06491@cm-29-94-14.nycap.rr.com> References: <199904281557.LAA06491@cm-29-94-14.nycap.rr.com> Message-ID: <199904281606.MAA27526@eric.cnri.reston.va.us> > Have we been talking about Python 2 or Python 1.6? If we're talking about > Python 2, has anyone given a serious look at the LLNL gang's C++/Python > stuff? If I recall Paul Dubois' talk at the last conference, it sounded > like their work made it much easier to implement extension modules. I've mostly had 1.6 in mind. See recent traffic in the C++ SIG archives for the status of Paul's CXX. --Guido van Rossum (home page: http://www.python.org/~guido/) From da at ski.org Wed Apr 28 19:24:00 1999 From: da at ski.org (David Ascher) Date: Wed, 28 Apr 1999 10:24:00 -0700 (Pacific Daylight Time) Subject: [Python-Dev] LLNL C++ as base for Python 2? In-Reply-To: <199904281606.MAA27526@eric.cnri.reston.va.us> Message-ID: On Wed, 28 Apr 1999, Guido van Rossum wrote: > > Have we been talking about Python 2 or Python 1.6? If we're talking about > > Python 2, has anyone given a serious look at the LLNL gang's C++/Python > > stuff? If I recall Paul Dubois' talk at the last conference, it sounded > > like their work made it much easier to implement extension modules. > > I've mostly had 1.6 in mind. See recent traffic in the C++ SIG > archives for the status of Paul's CXX. Recent traffic? There's nothing in there that's substantive since... uh, well, I got tired of looking back. =) CXX is very cool, but it is still pushing the envelope of many C++ compilers. From what I gather, recent egcs' do manage with it, and since egcs is going to replace gcc, I expect that many platforms will be able to "do" CXX relatively soon. I vote to stay on the 1.6 track for now. From MHammond at skippinet.com.au Fri Apr 30 04:40:09 1999 From: MHammond at skippinet.com.au (Mark Hammond) Date: Fri, 30 Apr 1999 12:40:09 +1000 Subject: [Python-Dev] More flexible namespaces. Message-ID: <008d01be92b2$c56ef5d0$0801a8c0@bobcat> 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 ), 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. From guido at CNRI.Reston.VA.US Fri Apr 30 05:00:52 1999 From: guido at CNRI.Reston.VA.US (Guido van Rossum) Date: Thu, 29 Apr 1999 23:00:52 -0400 Subject: [Python-Dev] More flexible namespaces. In-Reply-To: Your message of "Fri, 30 Apr 1999 12:40:09 +1000." <008d01be92b2$c56ef5d0$0801a8c0@bobcat> References: <008d01be92b2$c56ef5d0$0801a8c0@bobcat> Message-ID: <199904300300.XAA00608@eric.cnri.reston.va.us> > 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. I agree that this would be seriously cool. It will definitely be in Python 2.0; it's already in JPython. Quite a while ago, Ian Castleden sent me patches for 1.5.1 to do this. It was a lot of code and I was indeed worried about slowing things down too much (and also about checking that he got all the endcases right). Ian did benchmarks and found that the new code was consistently slower, by 3-6%. Perhaps for Python 1.6 this will be acceptable (the "Python IS slow" thread notwithstanding :-); or perhaps someone can have a look at it and squeeze some more time out of it? I'll gladly forward the patches. --Guido van Rossum (home page: http://www.python.org/~guido/) From da at ski.org Fri Apr 30 05:21:04 1999 From: da at ski.org (David Ascher) Date: Thu, 29 Apr 1999 20:21:04 -0700 (Pacific Daylight Time) Subject: [Python-Dev] More flexible namespaces. In-Reply-To: <199904300300.XAA00608@eric.cnri.reston.va.us> Message-ID: > > 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. > > I agree that this would be seriously cool. It will definitely be in > Python 2.0; it's already in JPython. Seriously cool is an understatement. --david From MHammond at skippinet.com.au Fri Apr 30 06:13:25 1999 From: MHammond at skippinet.com.au (Mark Hammond) Date: Fri, 30 Apr 1999 14:13:25 +1000 Subject: [Python-Dev] More flexible namespaces. In-Reply-To: <199904300300.XAA00608@eric.cnri.reston.va.us> Message-ID: <009001be92bf$cb998f80$0801a8c0@bobcat> > Ian did benchmarks and found that the new code was consistently > slower, by 3-6%. Perhaps for Python 1.6 this will be acceptable (the > "Python IS slow" thread notwithstanding :-); or perhaps someone can As long as we get someone working on a consistent 3-6% speedup in other areas this wont be a problem :-) I will attach it to my long list - but Im going to put all my efforts here into Unicode first, and probably the threading stuff second :-) Mark. From tismer at appliedbiometrics.com Fri Apr 30 09:49:42 1999 From: tismer at appliedbiometrics.com (Christian Tismer) Date: Fri, 30 Apr 1999 09:49:42 +0200 Subject: [Python-Dev] More flexible namespaces. References: <008d01be92b2$c56ef5d0$0801a8c0@bobcat> <199904300300.XAA00608@eric.cnri.reston.va.us> Message-ID: <37296096.D0C9C2CC@appliedbiometrics.com> Guido van Rossum wrote: ... > Ian did benchmarks and found that the new code was consistently > slower, by 3-6%. Perhaps for Python 1.6 this will be acceptable (the > "Python IS slow" thread notwithstanding :-); or perhaps someone can > have a look at it and squeeze some more time out of it? I'll gladly > forward the patches. I'd really like to look into that. Also I wouldn't worry too much about speed, since this is such a cool feature. It might even be a speedup in some cases which otherwise would need more complex handling. May I have a look? ciao - chris -- Christian Tismer :^) 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 From mal at lemburg.com Fri Apr 30 10:22:46 1999 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 30 Apr 1999 10:22:46 +0200 Subject: [Python-Dev] More flexible namespaces. References: <008d01be92b2$c56ef5d0$0801a8c0@bobcat> Message-ID: <37296856.5875AAAF@lemburg.com> Mark Hammond wrote: > > 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 involves a whole lot of changes: not only in the Python core, but also in extensions that rely on having real dictionaries available. Since you put out to objectives, I'd like to propose a little different approach... 1. Have eval/exec accept any mapping object as input 2. Make those two copy the content of the mapping object into real dictionaries 3. Provide a hook into the dictionary implementation that can be used to redirect KeyErrors and use that redirection to forward the request to the original mapping objects > This would give us 2 seriously cool features (that I want ), 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. This is covered by 1 and 2. > * 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. This is something for 3. I guess it wouldn't cause any significant slow-down and can be imlemented with much less code than the "change all PyDict_GetItem to PyObject_GetItem" thingie. The real thing could then be done for 2.0 where PyDict_Check() would presumably not rely on an adress but some kind of inheritance scheme indicating that the object is in fact a dictionary. Cheers, -- Marc-Andre Lemburg Y2000: 245 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From guido at CNRI.Reston.VA.US Fri Apr 30 17:17:20 1999 From: guido at CNRI.Reston.VA.US (Guido van Rossum) Date: Fri, 30 Apr 1999 11:17:20 -0400 Subject: [Python-Dev] More flexible namespaces. In-Reply-To: Your message of "Fri, 30 Apr 1999 09:49:42 +0200." <37296096.D0C9C2CC@appliedbiometrics.com> References: <008d01be92b2$c56ef5d0$0801a8c0@bobcat> <199904300300.XAA00608@eric.cnri.reston.va.us> <37296096.D0C9C2CC@appliedbiometrics.com> Message-ID: <199904301517.LAA01422@eric.cnri.reston.va.us> > From: Christian Tismer > I'd really like to look into that. > Also I wouldn't worry too much about speed, since this is > such a cool feature. It might even be a speedup in some cases > which otherwise would need more complex handling. > > May I have a look? Sure! (I've forwarded Christian the files per separate mail.) I'm also interested in your opinion on how well thought-out and robust the patches are -- I've never found the time to do a good close reading of them. --Guido van Rossum (home page: http://www.python.org/~guido/) From gmcm at hypernet.com Fri Apr 30 18:32:30 1999 From: gmcm at hypernet.com (Gordon McMillan) Date: Fri, 30 Apr 1999 11:32:30 -0500 Subject: [Python-Dev] More flexible namespaces. In-Reply-To: <199904301517.LAA01422@eric.cnri.reston.va.us> References: Your message of "Fri, 30 Apr 1999 09:49:42 +0200." <37296096.D0C9C2CC@appliedbiometrics.com> Message-ID: <1286632328-77246936@hypernet.com> Guido wrote: > > From: Christian Tismer > > > I'd really like to look into that. > > Also I wouldn't worry too much about speed, since this is ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > such a cool feature. It might even be a speedup in some cases > > which otherwise would need more complex handling. > > > > May I have a look? > > Sure! > > (I've forwarded Christian the files per separate mail.) I don't know who you sent that to, but it couldn't possibly have been Christian! - Gordon From tismer at appliedbiometrics.com Fri Apr 30 17:57:09 1999 From: tismer at appliedbiometrics.com (Christian Tismer) Date: Fri, 30 Apr 1999 17:57:09 +0200 Subject: [Python-Dev] More flexible namespaces. References: <008d01be92b2$c56ef5d0$0801a8c0@bobcat> <199904300300.XAA00608@eric.cnri.reston.va.us> <37296096.D0C9C2CC@appliedbiometrics.com> <199904301517.LAA01422@eric.cnri.reston.va.us> Message-ID: <3729D2D5.6844D6DA@appliedbiometrics.com> Guido van Rossum wrote: > > > From: Christian Tismer > > May I have a look? > > Sure! > > (I've forwarded Christian the files per separate mail.) Thanks a lot! > I'm also interested in your opinion on how well thought-out and robust > the patches are -- I've never found the time to do a good close > reading of them. Yes, it is quite long and not so very easy to digest. At first glance, most of the changes are replacements of dict access with mapping access where we pay for the extra indirection. It depends on how often this feature will really replace dicts. If dicts are more common, I'd like to figure out how much code bloat extra special casing for dicts would give. Puha - thanks - chris -- Christian Tismer :^) 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 From tismer at appliedbiometrics.com Fri Apr 30 18:19:57 1999 From: tismer at appliedbiometrics.com (Christian Tismer) Date: Fri, 30 Apr 1999 18:19:57 +0200 Subject: [Python-Dev] More flexible namespaces. References: Your message of "Fri, 30 Apr 1999 09:49:42 +0200." <37296096.D0C9C2CC@appliedbiometrics.com> <1286632328-77246936@hypernet.com> Message-ID: <3729D82D.CE16884@appliedbiometrics.com> Gordon McMillan wrote: > > Guido wrote: > > > > From: Christian Tismer > > > > > I'd really like to look into that. > > > Also I wouldn't worry too much about speed, since this is > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > such a cool feature. It might even be a speedup in some cases > > > which otherwise would need more complex handling. > > > > > > May I have a look? > > > > Sure! > > > > (I've forwarded Christian the files per separate mail.) > > I don't know who you sent that to, but it couldn't possibly have been > Christian! :-) :-) truely not if I had'n other things in mind. I know that I will not get more than 30-40 percent by compiling the interpreter away, so I will not even spend time at a register machine right now. Will also not follow the ideas of P2C any longer, doesn't pay off. Instead, If I can manage to create something like static binding snapshots, then I could resolve many of the lookups and internal method indirections, for time critical applications. For all the rest, Python is pretty much fast enough. I've begun to write s special platform dependant version which allows me to do all the things which can't go into the dist. For instance, I just saved some 10 percent by dynamically patching some of the ParseTuple and BuildObject calls out of the core code (ahem). I hope Python will stay as clean as it is, allowing me to try all kinds of tricks for one machine class. ciao - chris.speedy -- Christian Tismer :^) 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 From akuchlin at cnri.reston.va.us Fri Apr 30 18:33:34 1999 From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling) Date: Fri, 30 Apr 1999 12:33:34 -0400 (EDT) Subject: [Python-Dev] More flexible namespaces. In-Reply-To: <3729D82D.CE16884@appliedbiometrics.com> References: <37296096.D0C9C2CC@appliedbiometrics.com> <1286632328-77246936@hypernet.com> <3729D82D.CE16884@appliedbiometrics.com> Message-ID: <14121.55659.754846.708467@amarok.cnri.reston.va.us> Christian Tismer writes: >Instead, If I can manage to create something like static binding >snapshots, then I could resolve many of the lookups and internal >method indirections, for time critical applications. The usual assumption is that the lookups are what takes time. Now, are we sure of that assumption? I'd expect the lookup code to be like: 1) Get hash of name 2) Retrieve object from dictionary 3) Do something with the object. Now, since string objects cache their hash value, 1) should usually be just "if (obj->cached_hash_value!=-1) return obj->cached_hash_value"; a comparision and a return. Step 2) should be very fast, barring a bad hash function. So perhaps most of the time is spent in 3), creating new local dicts, stack frames, and what not. (Yes, I know that doing this on every reference to an object is part of the problem.) I also wonder about the costs of all the Py_BuildValue and Py_ParseTuple calls going on under the hood. A performance improvement project would definitely be a good idea for 1.6, and a good sub-topic for python-dev. Incidentally, what's the verdict on python-dev archives: public or not? -- A.M. Kuchling http://starship.python.net/crew/amk/ Despair says little, and is patient. -- From SANDMAN: "Season of Mists", episode 0 From tismer at appliedbiometrics.com Fri Apr 30 18:55:55 1999 From: tismer at appliedbiometrics.com (Christian Tismer) Date: Fri, 30 Apr 1999 18:55:55 +0200 Subject: [Python-Dev] More flexible namespaces. References: <37296096.D0C9C2CC@appliedbiometrics.com> <1286632328-77246936@hypernet.com> <3729D82D.CE16884@appliedbiometrics.com> <14121.55659.754846.708467@amarok.cnri.reston.va.us> Message-ID: <3729E09B.5F65E3CA@appliedbiometrics.com> "Andrew M. Kuchling" wrote: > > Christian Tismer writes: > >Instead, If I can manage to create something like static binding > >snapshots, then I could resolve many of the lookups and internal > >method indirections, for time critical applications. > > The usual assumption is that the lookups are what takes time. > Now, are we sure of that assumption? I'd expect the lookup code to be > like: > > 1) Get hash of name > 2) Retrieve object from dictionary > 3) Do something with the object. ... Right, but when you become more restrictive, you can do lots, lots more. If I also allow to fix the type of an object, I can go under the hood of the Python API, so you could add some points 4) 5) 6) here. But I shouldn't have talked before I can show something. And at the time, I don't restrict myself to write clean code, but try very machine specific things which I don't believe should go into Python at all. > I also wonder about the costs of all the Py_BuildValue and > Py_ParseTuple calls going on under the hood. A performance > improvement project would definitely be a good idea for 1.6, and a > good sub-topic for python-dev. I wasn't sure, so I first wrote a module which does statistics on that, and I found a lot of these calls. Some are even involved in ceval's code, where things like "(OOOO)" is parsed all over again and again. Now I think this is ok in most cases. But in some places these are very bad: If your builtin function soes so very few work. Take len(): This uses ParseTuple, which calls a function to find out its object, then calls a function to get the object, then takes the len, and builds the result. But since everything has a length, checking for no NULL pointer and grabbing the len produces even shorter code. This applies to many places as well. But right now, I don't change the core, but build hacky little extension modules which squeak such things out at runtime. No big deal yet, but maybe it could pay off to introduce format strings which make them more suitableto be used in macro substitutions. sorry if I was too elaborate, this is so much fun :-) ciao - chris -- Christian Tismer :^) 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