From fdrake@acm.org Thu Jun 1 02:30:28 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Wed, 31 May 2000 21:30:28 -0400 (EDT) Subject: [Python-Dev] Adding LDAP to the Python core... ?! In-Reply-To: References: <14645.36702.769794.807329@cj42289-a.reston1.va.home.com> Message-ID: <14645.48308.347086.279280@cj42289-a.reston1.va.home.com> Greg Stein writes: > davlib.py is pure Python, building upon my upgraded httplib.py and > xml.utils.qp_xml (and pyexpat) So the dependencies are definately an issue. > [ and recall my email last week that I've updated httplib.py and posted it > to my web pages; it is awaiting review for integration into the Python > core; it still needs docs and more testing scenarios, tho > > http://www.python.org/pipermail/python-dev/2000-May/005643.html > ] Jeremy, were you looking at this? > davlib will probably be a 1.7 item. It still needs some heavy work to > easily deal with authentication (which is usually going to be required for Sounds good to me; let's take a look at it in 3 or 4 months. I'd hope to have at least preliminary reference documentation for review. -Fred -- Fred L. Drake, Jr. PythonLabs at BeOpen.com From skip@mojam.com (Skip Montanaro) Thu Jun 1 14:48:41 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Thu, 1 Jun 2000 08:48:41 -0500 (CDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Objects listobject.c,2.69,2.70 stringobject.c,2.65,2.66 tupleobject.c,2.33,2.34 In-Reply-To: <200006010312.UAA10844@slayer.i.sourceforge.net> References: <200006010312.UAA10844@slayer.i.sourceforge.net> Message-ID: <14646.27065.279988.93102@beluga.mojam.com> Fred> Log Message: Fred> Michael Hudson : Fred> Removed PyErr_BadArgument() calls and replaced them with more Fred> useful error messages. ... Fred> --- 389,395 ---- Fred> PyListObject *np; Fred> if (!PyList_Check(bb)) { Fred> ! PyErr_Format(PyExc_TypeError, Fred> ! "can only append list (not \"%.200s\") to list", Fred> ! bb->ob_type->tp_name); Fred> return NULL; Fred> } Fred> *************** ... I've seen this new error message cross my mailbox a few times. On the face of it, it's incorrect, because you can append any sort of object to a list, right? This message appears in the list_concat method. Shouldn't it be something like can't concatenate \"%.200s\" object with list ? I would consider this change very picky except for the fact that it's making a statement about the properties of lists that is clearly not true. -- Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ "We have become ... the stewards of life's continuity on earth. We did not ask for this role... We may not be suited to it, but here we are." - Stephen Jay Gould From fdrake@acm.org Thu Jun 1 15:29:17 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Thu, 1 Jun 2000 10:29:17 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Objects listobject.c,2.69,2.70 stringobject.c,2.65,2.66 tupleobject.c,2.33,2.34 In-Reply-To: <14646.27065.279988.93102@beluga.mojam.com> References: <200006010312.UAA10844@slayer.i.sourceforge.net> <14646.27065.279988.93102@beluga.mojam.com> Message-ID: <14646.29501.378585.828457@cj42289-a.reston1.va.home.com> Skip Montanaro writes: > I've seen this new error message cross my mailbox a few times. On the face > of it, it's incorrect, because you can append any sort of object to a list, > right? This message appears in the list_concat method. Shouldn't it be > something like > > can't concatenate \"%.200s\" object with list Skip, You're right! How about: can only concatenate list (not \"%.200s\") to list If you don't object by the time this mail reaches you, I'll check it in. ;) -Fred -- Fred L. Drake, Jr. PythonLabs at BeOpen.com From mwh21@cam.ac.uk Thu Jun 1 16:39:59 2000 From: mwh21@cam.ac.uk (Michael Hudson) Date: Thu, 1 Jun 2000 16:39:59 +0100 (BST) Subject: [Python-Dev] CVS: python/dist/src/Objects listobject.c,2.69,2.70 and friends In-Reply-To: <14646.29501.378585.828457@cj42289-a.reston1.va.home.com> Message-ID: On Thu, 1 Jun 2000, Fred L. Drake, Jr. wrote: > > Skip Montanaro writes: > > I've seen this new error message cross my mailbox a few times. On the face > > of it, it's incorrect, because you can append any sort of object to a list, > > right? This message appears in the list_concat method. Shouldn't it be > > something like > > > > can't concatenate \"%.200s\" object with list > > Skip, > You're right! How about: > > can only concatenate list (not \"%.200s\") to list > > If you don't object by the time this mail reaches you, I'll check it > in. ;) Then you'd better do something about tupleobject.c as well; I'd also say can only concatenate list (not \"%.200s\") and list can only concatenate tuple (not \"%.200s\") and tuple are slightly preferable, on reflection (note the s/to/and/). Cheers, Michael From andy@reportlab.com Thu Jun 1 17:23:36 2000 From: andy@reportlab.com (Andy Robinson) Date: Thu, 1 Jun 2000 17:23:36 +0100 Subject: [Python-Dev] SIG: python-lang Message-ID: It seems to me that the main problem is that comp.lang.python is too big to follow. So why not split it? I don't know the right subgroups, but if (say) comp.lang.python.language focusses on the core language, it might enable people to start reading it again. I asked this twice on c.l.p, one year ago and two years ago, and the answer was always "the traffic is too low". I used to subscribe to the NeXTSteap groups, and splitting worked really well there. - Andy Robinson From mal@lemburg.com Thu Jun 1 14:10:42 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 01 Jun 2000 15:10:42 +0200 Subject: [Python-Dev] Adding LDAP to the Python core... ?! References: Message-ID: <393660D2.4926E5C1@lemburg.com> Greg Stein wrote: > > On Wed, 31 May 2000, Barry A. Warsaw wrote: > > >>>>> "M" == M writes: > > > > M> Would there be interest in adding the python-ldap module > > M> (http://sourceforge.net/project/?group_id=2072) to the > > M> core distribution ? > > > > I haven't looked at this stuff, but yes, I think a standard LDAP > > module would be quite useful. It's a well enough established > > protocol, and it would be good to be able to count on it "being > > there". > > My WebDAV module implements an established protocol (an RFC tends to do > that :-), but the API within the module is still in flux (IMO). > > Is the LDAP module's API pretty solid? Is it changing? It is closing in on version 2.0 -- not sure how much it still changes. I just thought I'd query here before asking Daniel about his thoughts on including the module in the core (wouldn't make much sense if there was no interest). > And is this module a C extension, or a pure Python implementation? It's a Python module which uses a C wrapper to interface to OpenLDAP, which is a portable C lib dealing with all aspects of LDAP. There are at least two other projects built on top of python-ldap (see Parnassus for infos). I just thought I'd mention it here, because LDAP is certainly a widely used protocol in the corporate world and many decision makers have this on their list of buzz words. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gward@mems-exchange.org Thu Jun 1 22:01:41 2000 From: gward@mems-exchange.org (Greg Ward) Date: Thu, 1 Jun 2000 17:01:41 -0400 Subject: [Python-Dev] What's that sound? In-Reply-To: <393547A2.30CB7113@prescod.net>; from paul@prescod.net on Wed, May 31, 2000 at 12:10:58PM -0500 References: <39353CCD.1F3E9A0B@prescod.net> <14645.17611.318538.986772@anthem.python.org> <393547A2.30CB7113@prescod.net> Message-ID: <20000601170140.A24794@mems-exchange.org> On 31 May 2000, Paul Prescod said: > Look closer, big-egoed-four-stringed-guitar-playing-one. It could just > as easily be a J. > > And you know what you get when you put P and J together? Pajamas! Yes, that's right, when Python takes over the world, we'll all have to sleep BUCK NAKED!!! (What was that about "zero noise" on python-dev? Oh well, we must have our fun...) Greg From esr@snark.thyrsus.com Thu Jun 1 23:36:29 2000 From: esr@snark.thyrsus.com (Eric S. Raymond) Date: Thu, 1 Jun 2000 18:36:29 -0400 Subject: [Python-Dev] ascii.py? Message-ID: <200006012236.SAA03578@snark.thyrsus.com> There has been a vast and echoing silence about the ascii.py module I posted here at Fred Drake's request. Is it really such a bad idea? -- Eric S. Raymond "Those who make peaceful revolution impossible will make violent revolution inevitable." -- John F. Kennedy From Ka-Ping Yee Thu Jun 1 23:33:19 2000 From: Ka-Ping Yee (Ka-Ping Yee) Date: Thu, 1 Jun 2000 15:33:19 -0700 (PDT) Subject: [Python-Dev] ascii.py? In-Reply-To: <200006012236.SAA03578@snark.thyrsus.com> Message-ID: On Thu, 1 Jun 2000, Eric S. Raymond wrote: > There has been a vast and echoing silence about the ascii.py module I > posted here at Fred Drake's request. Is it really such a bad idea? Don't look at me. I'm busy working on inspect and htmldoc. :) Actually, i guess i probably didn't respond because it isn't of immediate use to me. Maybe this is the sort of thing that might come in handy one day but that hordes of people aren't desperate for. Hmm. Perhaps it's because people are used to saying "in string.digits" instead of wanting isdigit() &c. Hmm. Perhaps it's also something that ought to be eventually handled via the Unicode character property route. Dunno. -- ?!ng "China is a big country, inhabited by many Chinese." -- Former French President Charles de Gaulle From gstein@lyra.org Thu Jun 1 23:34:13 2000 From: gstein@lyra.org (Greg Stein) Date: Thu, 1 Jun 2000 15:34:13 -0700 (PDT) Subject: [Python-Dev] ascii.py? In-Reply-To: <200006012236.SAA03578@snark.thyrsus.com> Message-ID: On Thu, 1 Jun 2000, Eric S. Raymond wrote: > There has been a vast and echoing silence about the ascii.py module I > posted here at Fred Drake's request. Is it really such a bad idea? hehe... I'd say silence implies a +0 from people ("seems reasonable to go in, but I wouldn't be upset if it doesn't"). If people thought it was bad, then you'd hear about it :-) I took a quick look at it. Doesn't seem too bad, but I can't think of anything that I've done in a long while that would require it. So I can't really say "wow! put that baby in the distro!" YMMV, of course :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From esr@thyrsus.com Thu Jun 1 23:51:45 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Thu, 1 Jun 2000 18:51:45 -0400 Subject: [Python-Dev] ascii.py? In-Reply-To: ; from gstein@lyra.org on Thu, Jun 01, 2000 at 03:34:13PM -0700 References: <200006012236.SAA03578@snark.thyrsus.com> Message-ID: <20000601185145.A3667@thyrsus.com> Greg Stein : > I took a quick look at it. Doesn't seem too bad, but I can't think of > anything that I've done in a long while that would require it. So I can't > really say "wow! put that baby in the distro!" It starts to get pretty useful in conjunction with curses -- for example, in writing interpreters for character-at-a-time command loops. I have a new version that adds the following: \begin{funcdesc}{ascii}{c} Return the ASCII value corresponding to the low 7 bits of c. \end{funcdesc} The following function takes either a single-character string or integer byte value; it returns a string. \begin{funcdesc}{unctrl}{c} Return a string representation of the ASCII character c. If c is printable, this string is the character itself. If the character is a control character (0x00-0x1f) the string consists of a caret (^) followed by the corresponding uppercase letter. If the character is an ASCII delete (0x7f) the string is "^?". If the character has its meta bit (0x80) set, the meta bit is stripped, the preceding rules applied, and "!" prepended to the result. \end{funcdesc} Finally, the module supplies a 33-element string array called controlnames that contains the ASCII mnemonics for the thirty-two ASCII control characters from 0 (NUL) to 0x1f (US), in order, plus the mnemonic "SP" for space. -- Eric S. Raymond Certainly one of the chief guarantees of freedom under any government, no matter how popular and respected, is the right of the citizens to keep and bear arms. [...] the right of the citizens to bear arms is just one guarantee against arbitrary government and one more safeguard against a tyranny which now appears remote in America, but which historically has proved to be always possible. -- Hubert H. Humphrey, 1960 From akuchlin@mems-exchange.org Fri Jun 2 00:32:32 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Thu, 1 Jun 2000 19:32:32 -0400 Subject: [Python-Dev] ascii.py? In-Reply-To: <200006012236.SAA03578@snark.thyrsus.com>; from esr@snark.thyrsus.com on Thu, Jun 01, 2000 at 06:36:29PM -0400 References: <200006012236.SAA03578@snark.thyrsus.com> Message-ID: <20000601193232.A12831@newcnri.cnri.reston.va.us> On Thu, Jun 01, 2000 at 06:36:29PM -0400, Eric S. Raymond wrote: >There has been a vast and echoing silence about the ascii.py module I >posted here at Fred Drake's request. Is it really such a bad idea? One misgiving I had was locales; is it a bug or a feature that locales aren't supported, as they are for the C isdigit(), isalpha(), &c, functions? I'm not entirely sure which it is. (The locale module doesn't expose the C is*() functions, though I think they're used in constructing string.letters.) --amk From esr@thyrsus.com Fri Jun 2 00:45:11 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Thu, 1 Jun 2000 19:45:11 -0400 Subject: [Python-Dev] ascii.py? In-Reply-To: <20000601193232.A12831@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Thu, Jun 01, 2000 at 07:32:32PM -0400 References: <200006012236.SAA03578@snark.thyrsus.com> <20000601193232.A12831@newcnri.cnri.reston.va.us> Message-ID: <20000601194511.A3948@thyrsus.com> Andrew Kuchling : > On Thu, Jun 01, 2000 at 06:36:29PM -0400, Eric S. Raymond wrote: > >There has been a vast and echoing silence about the ascii.py module I > >posted here at Fred Drake's request. Is it really such a bad idea? > > One misgiving I had was locales; is it a bug or a feature that locales > aren't supported, as they are for the C isdigit(), isalpha(), &c, > functions? I'm not entirely sure which it is. (The locale module > doesn't expose the C is*() functions, though I think they're used in > constructing string.letters.) It's a feature. That's why this module is called ascii, not string :-) -- Eric S. Raymond "...quemadmodum gladius neminem occidit, occidentis telum est." [...a sword never kills anybody; it's a tool in the killer's hand.] -- (Lucius Annaeus) Seneca "the Younger" (ca. 4 BC-65 AD), From paul@prescod.net Fri Jun 2 04:53:41 2000 From: paul@prescod.net (Paul Prescod) Date: Thu, 01 Jun 2000 22:53:41 -0500 Subject: [Python-Dev] ascii.py? References: <200006012236.SAA03578@snark.thyrsus.com> Message-ID: <39372FC5.DE1CE8EA@prescod.net> "Eric S. Raymond" wrote: > > There has been a vast and echoing silence about the ascii.py module I > posted here at Fred Drake's request. Is it really such a bad idea? Without looking closely, or even being particularly knowledgable (how's that for a disclaimer!) my instinctive reaction was: "does the ASCII subset of Unicode need its own module just before we add Unicode to the language?" It may be that there are some semantics of ASCII that are not captured in the Unicode spec. and thus are not generalizable. I'm pretty confident that these ones ARE generalizable: isalnum isalpha isascii islower isupper isspace isxdigit How do Unicode users get this information from the famous Unicode database and why not merge the Unicode and ASCII versions in 1.6? -- Paul Prescod - ISOGEN Consulting Engineer speaking for himself Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From esr@thyrsus.com Fri Jun 2 06:43:54 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Fri, 2 Jun 2000 01:43:54 -0400 Subject: [Python-Dev] ascii.py? In-Reply-To: <39372FC5.DE1CE8EA@prescod.net>; from paul@prescod.net on Thu, Jun 01, 2000 at 10:53:41PM -0500 References: <200006012236.SAA03578@snark.thyrsus.com> <39372FC5.DE1CE8EA@prescod.net> Message-ID: <20000602014353.A5211@thyrsus.com> Paul Prescod : > "Eric S. Raymond" wrote: > > > > There has been a vast and echoing silence about the ascii.py module I > > posted here at Fred Drake's request. Is it really such a bad idea? > > Without looking closely, or even being particularly knowledgable (how's > that for a disclaimer!) my instinctive reaction was: "does the ASCII > subset of Unicode need its own module just before we add Unicode to the > language?" > > It may be that there are some semantics of ASCII that are not captured > in the Unicode spec. and thus are not generalizable. ascii.ctrl is one such. > I'm pretty > confident that these ones ARE generalizable: > > isalnum > isalpha > isascii > islower > isupper > isspace > isxdigit > > How do Unicode users get this information from the famous Unicode > database and why not merge the Unicode and ASCII versions in 1.6? Answer: ascii.py is not designed for text processing. I wrote it to package some functions useful for classifying *ASCII* data, especially in the context of roguelike programs that interpret keystrokes coming in through a curses interface. (Where this all touches ground is CML2, my replacement configuration system for the Linux kernel.) -- Eric S. Raymond ..every Man has a Property in his own Person. This no Body has any Right to but himself. The Labour of his Body, and the Work of his Hands, we may say, are properly his. .... The great and chief end therefore, of Mens uniting into Commonwealths, and putting themselves under Government, is the Preservation of their Property. -- John Locke, "A Treatise Concerning Civil Government" From gstein@lyra.org Fri Jun 2 09:43:13 2000 From: gstein@lyra.org (Greg Stein) Date: Fri, 2 Jun 2000 01:43:13 -0700 (PDT) Subject: [Python-Dev] httplib (was: Adding LDAP to the Python core... ?!) In-Reply-To: <14645.51445.963154.817309@localhost.localdomain> Message-ID: It looks like a definite bug. I have *no* idea, tho, why it is doing that... I did quite a bit of testing with chunked replies. Admittedly, though, I didn't stack up requests like you've done in your test. I'm wrapping up mod_dav at the moment, so I don't really have time to look deeply into this. Mebbe next week? Regarding the pipeline request thing. I think it would probably be best to just drop the whole "hold the previous response and wait for it to be closed" thing. I don't know why that is in there; probably a leftover (converted) semantic from the old-style HTTP() class. I'd be quite fine just axing it and allowing the client to shove ten requests down the pipe before pulling the first response back out. Oh. Wait. Maybe that was it. You can't read the "next" response until the first one has been read. Well... no need to block putting new responses; we just need to create a way to "get the next reply" and/or "can I get the next reply yet?" Cheers, -g p.s. Moshe also had a short list of review items. I read thru them, but not with the code in hand to understand some of his specifics. On Wed, 31 May 2000, Jeremy Hylton wrote: > >>>>> "GS" == Greg Stein writes: > > GS> [ and recall my email last week that I've updated httplib.py and > GS> posted it to my web pages; it is awaiting review for integration > GS> into the Python core; it still needs docs and more testing > GS> scenarios, tho > > I've been looking at the httplib code, and I found what may be a bug. > Not sure, because I'm not sure how the API works for pipelined > requests. > > I've got some test code that looks a bit like this: > > def test_new_interface_series(urls): > paths = [] > the_host = None > for url in urls: > host, path = get_host_and_path(url) > if the_host is None: > the_host = host > else: > assert host == the_host > paths.append(path) > > conn = httplib.HTTPConnection(the_host) > for path in paths: > conn.request('GET', path, headers={'User-Agent': 'httplib/Python'}) > for path in paths: > errcode, errmsg, resp = conn.getreply() > buf = resp.read() > if errcode == 200: > print errcode, resp.headers > else: > print errcode, `errmsg`, resp > print resp.getheader('Content-Length'), len(buf) > print repr(buf[:40]) > print repr(buf[-40:]) > print > conn.close() > > test_new_interface_series(['http://www.python.org/', > 'http://www.python.org/pics/PyBanner054.gif', > 'http://www.python.org/pics/PythonHi.gif', > 'http://www.python.org/Jobs.html', > 'http://www.python.org/doc/', > 'http://www.python.org/doc/current/', > ]) > > The second loop that reads the replies gets fouled up after a couple > of responses. I added even more debugging and found that the first > line of the corrupted response is > > > 'ontent-Type: text/html\015\012' > > It looks like some part of the program is consuming too much input. I > haven't been able to figure out what part yet. Hoping that you might > have some good ideas. > > Thinking about this issue, I came up with a potential API problem. > You must read the body after calling getreply and before calling > getreply a second time. This kind of implicit requirement is a bit > tricky. It would help if the implementation could raise an error if > this happens. It might be even better if it just worked, although it > seems a bit too magical. > > Jeremy > -- Greg Stein, http://www.lyra.org/ From mal@lemburg.com Fri Jun 2 09:11:05 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 02 Jun 2000 10:11:05 +0200 Subject: [Python-Dev] Re: [Patches] Translating doc strings References: <200006020701.JAA28620@pandora> Message-ID: <39376C19.53A01A27@lemburg.com> Martin von Loewis wrote: > > To simplify usage of Python for people who don't speak English well, > I'd like to start a project translating the doc strings in the Python > library. This has two aspects: > > 1. there must be a simple way to access the translated doc strings Do you plan to use GNU gettext here ? (This would cause the translated version of Python to fall under GPL, AFAIK) I'd propose to use the existing doc-strings as keys to a translation mapping. This assures that existing doc-strings remain intact and that the actual translation process is done at query time, e.g. by using a help() built-in function. > 2. there must be actual translations to the various native languages > of Python users. > > Since the second task is much more complicated, I submit a snapshot of > this project, namely, a message catalog of the doc strings in the > Python libraries, taken from the CVS; along with a snapshot of the > German translations. I intend to complete the German translations in > the coming weeks, but I want to give other translators a chance to > also start working on that. > > Please note that extracting the docstrings was not straight-forward; > I've used François Pinard's most excellent po-utils 0.5 as a starting > point, and enhanced it with the capability to recognize __doc__[] in C > code, so that I would also get (most of) the doc strings in C modules. > I plan to update this catalog a few times before Python 1.6 is > released, so that translators can update their translations. > > A key point is finding translators. I propose to use the > infrastructure of the GNU translation project for that: There are > established teams for all major languages, and an infrastructure (also > maintained by François) where notifications about new catalogs are > automatically distributed to the teams. That should not stop > volunteers which don't currently participate in the GNU translation > project from translating - however, they should announce that they > plan to work on translating these messages to avoid duplication of > work. This will only work iff the translations can be submitted via the usual "post to patches with dislcaimer" method... aren't the GNU people interested in putting the translations under the GPL ? > Another matter is where the catalogs should live in the Python source > tree. I propose to have a Misc/po directory, which will contain both > the PO catalogues, as well as the binary .mo objects; only the latter > will be installed during the installation process. > > Please let me know what you think, in particular, whether I can submit > the catalog to the translation teams. > > Regards, > Martin > > --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > Name: doc.tgz > doc.tgz Type: unspecified type (application/octet-stream) > Encoding: base64 -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Fri Jun 2 08:55:04 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 02 Jun 2000 09:55:04 +0200 Subject: [Python-Dev] ascii.py? References: <200006012236.SAA03578@snark.thyrsus.com> <20000601193232.A12831@newcnri.cnri.reston.va.us> Message-ID: <39376858.55D4F778@lemburg.com> Andrew Kuchling wrote: > > On Thu, Jun 01, 2000 at 06:36:29PM -0400, Eric S. Raymond wrote: > >There has been a vast and echoing silence about the ascii.py module I > >posted here at Fred Drake's request. Is it really such a bad idea? > > One misgiving I had was locales; is it a bug or a feature that locales > aren't supported, as they are for the C isdigit(), isalpha(), &c, > functions? I'm not entirely sure which it is. (The locale module > doesn't expose the C is*() functions, though I think they're used in > constructing string.letters.) FYI, both strings and Unicode object already have a few .isXXX() methods: isdigit(), islower(), isspace(), istitle(), isupper() For strings these use the C APIs (which are locale aware), for Unicode the built in mappings are used. BTW, I haven't looked at the docs lately, but are the string and Unicode methods already documented ? All of them have doc-strings, so it should be easy extracting the data to build a TeX-file. On the topic of adding ascii.py, I'm +0 -- I don't currently have a need for it, but writing .append(ascii.CR + ascii.LF) does add to the readability of scripts. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Fri Jun 2 09:02:35 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 02 Jun 2000 10:02:35 +0200 Subject: [I18n-sig] Re: [Python-Dev] ascii.py? References: <200006012236.SAA03578@snark.thyrsus.com> <39372FC5.DE1CE8EA@prescod.net> Message-ID: <39376A1B.10E45C7B@lemburg.com> Paul Prescod wrote: > > "Eric S. Raymond" wrote: > > > > There has been a vast and echoing silence about the ascii.py module I > > posted here at Fred Drake's request. Is it really such a bad idea? > > Without looking closely, or even being particularly knowledgable (how's > that for a disclaimer!) my instinctive reaction was: "does the ASCII > subset of Unicode need its own module just before we add Unicode to the > language?" > > It may be that there are some semantics of ASCII that are not captured > in the Unicode spec. and thus are not generalizable. I'm pretty > confident that these ones ARE generalizable: > > isalnum > isalpha > isascii > islower > isupper > isspace > isxdigit > > How do Unicode users get this information from the famous Unicode > database and why not merge the Unicode and ASCII versions in 1.6? Note that many of the above are already implemented as string|Unicode methods. The Unicode database is accessible via the unicodedata module. The specs for the used APIs and constants can be found in the Unicode database description file on www.unicode.org. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From loewis@informatik.hu-berlin.de Fri Jun 2 13:33:07 2000 From: loewis@informatik.hu-berlin.de (Martin von Loewis) Date: Fri, 2 Jun 2000 14:33:07 +0200 (MET DST) Subject: [Python-Dev] Re: [Patches] Translating doc strings In-Reply-To: <39376C19.53A01A27@lemburg.com> (mal@lemburg.com) References: <200006020701.JAA28620@pandora> <39376C19.53A01A27@lemburg.com> Message-ID: <200006021233.OAA16962@pandora> > Do you plan to use GNU gettext here ? (This would cause the > translated version of Python to fall under GPL, AFAIK) No, I plan to use the Python gettext module, which is currently being integrated into Python. It will either use the system's gettext library, or read mo files using pure Python. > I'd propose to use the existing doc-strings as keys to=20 > a translation mapping. This assures that existing doc-strings > remain intact and that the actual translation process is > done at query time, e.g. by using a help() built-in function. This is more or less what I've planned. I'd propose to call the function doc, with an interface like >>> doc(time.time) time() -> Gleitkommazahl Gib die aktuelle Zeit in Sekunden seit Beginn der Epoche zur=FCck. Sekundenbruchteile sind vorhanden, falls die Systemuhr sie bereitstellt. It won't use a dictionary, though, but the underlying gettext query mechanism. Exact naming and parameters are certainly subject to discussion, my proposal would be doc(object, doprint=3D1, translate=3D1) so that users save quite some typing over >>> print time.time.__doc__=20 time() -> floating point number Return the current time in seconds since the Epoch. Fractions of a second may be present if the system clock provides them. > This will only work iff the translations can be submitted > via the usual "post to patches with dislcaimer" method... > aren't the GNU people interested in putting the translations > under the GPL ? Is it really necessary to have the translations posted to patches@python.org? Or would it be sufficient if translators express their disclaimer in some other way. I don't think the translation teams are "the GNU people"; the translators accepted to assign their copyright to the FSF for the translations they did - I'd assume at least some of them would also accept maintaining the copyright, or assigning it to the Python Consortium (or whoever else wants it). It's more that the Python distributor would need to make suggestions what the copyright on translations should be - I'm sure that could be clearly communicated to the translators. Regards, Martin From fdrake@acm.org Fri Jun 2 13:50:35 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Fri, 2 Jun 2000 08:50:35 -0400 (EDT) Subject: [Python-Dev] ascii.py? In-Reply-To: <200006012236.SAA03578@snark.thyrsus.com> References: <200006012236.SAA03578@snark.thyrsus.com> Message-ID: <14647.44443.651246.979946@cj42289-a.reston1.va.home.com> Eric S. Raymond writes: > There has been a vast and echoing silence about the ascii.py module I > posted here at Fred Drake's request. Is it really such a bad idea? Did you get my comments? -Fred -- Fred L. Drake, Jr. PythonLabs at BeOpen.com From bwarsaw@python.org Fri Jun 2 14:37:42 2000 From: bwarsaw@python.org (Barry A. Warsaw) Date: Fri, 2 Jun 2000 09:37:42 -0400 (EDT) Subject: [Python-Dev] Re: [Patches] Translating doc strings References: <200006020701.JAA28620@pandora> <39376C19.53A01A27@lemburg.com> <200006021233.OAA16962@pandora> Message-ID: <14647.47270.330318.807347@anthem.python.org> >>>>> "MvL" == Martin von Loewis writes: MvL> No, I plan to use the Python gettext module, which is MvL> currently being integrated into Python. It will either use MvL> the system's gettext library, or read mo files using pure MvL> Python. pygettext is in Tools/i18n, and I've been working with James Henstridge and Peter Funk on getting a standard gettext module integrated into the core. A few other things have bumped that down on my list, but it's still there. We'll still need xgettext to scan the C code. Also, marking Python module docstrings is a bit problematic. I've resorted to Something Really Ugly: -------------------- snip snip -------------------- try: import fintl _ = fintl.gettext except ImportError: def _(s): return s __doc__ = _("""pygettext -- Python equivalent of xgettext(1) ...") -------------------- snip snip -------------------- Yuck. -Barry From pf@artcom-gmbh.de Fri Jun 2 14:57:32 2000 From: pf@artcom-gmbh.de (Peter Funk) Date: Fri, 2 Jun 2000 15:57:32 +0200 (MEST) Subject: [Python-Dev] Re: [Patches] Translating doc strings In-Reply-To: <14647.47270.330318.807347@anthem.python.org> from "Barry A. Warsaw" at "Jun 2, 2000 9:37:42 am" Message-ID: Hi, [Barry A. Warsaw]: > pygettext is in Tools/i18n, and I've been working with James > Henstridge and Peter Funk on getting a standard gettext module > integrated into the core. A few other things have bumped that down on > my list, but it's still there. I will try to make some progress. Currently I'm not sure how to define a class 'Translator' ... I'm open for suggestions. James has also made some interesting points. > We'll still need xgettext to scan the C code. Also, marking Python > module docstrings is a bit problematic. I've resorted to Something > Really Ugly: > > -------------------- snip snip -------------------- > try: > import fintl > _ = fintl.gettext > except ImportError: > def _(s): return s > > > __doc__ = _("""pygettext -- Python equivalent of xgettext(1) > ...") > -------------------- snip snip -------------------- > > Yuck. I agree: this is really ugly. Since doc-strings are something special, I don't think, we should travel further down this road. I believe, we should use a special doc-string extration-tool (possibly build on top of ping's 'inspect.py'?), which will then create a .pot-file solely out of __doc__-strings. Regards, Peter. From loewis@informatik.hu-berlin.de Fri Jun 2 16:03:50 2000 From: loewis@informatik.hu-berlin.de (Martin von Loewis) Date: Fri, 2 Jun 2000 17:03:50 +0200 (MET DST) Subject: [Python-Dev] Re: [Patches] Translating doc strings In-Reply-To: <14647.47270.330318.807347@anthem.python.org> (bwarsaw@python.org) References: <200006020701.JAA28620@pandora> <39376C19.53A01A27@lemburg.com> <200006021233.OAA16962@pandora> <14647.47270.330318.807347@anthem.python.org> Message-ID: <200006021503.RAA26314@pandora> > We'll still need xgettext to scan the C code. Please have a look at my lib.pot; I've been using xpot to extract the C doc strings, which aren't currently marked-up in the Python source. As for module docstrings: xpot doesn't recognize them either, but I think it could be improved to do so. However, that would give a substantial increase of the catalogs, so I'd recommend to add them only when the translators are done with the first round of translation. Having the full set of distutils doc strings in the catalog is already a substantial amount of text to translate... Regards, Martin From loewis@informatik.hu-berlin.de Fri Jun 2 16:05:35 2000 From: loewis@informatik.hu-berlin.de (Martin von Loewis) Date: Fri, 2 Jun 2000 17:05:35 +0200 (MET DST) Subject: [Python-Dev] Re: [Patches] Translating doc strings In-Reply-To: (pf@artcom-gmbh.de) References: Message-ID: <200006021505.RAA26338@pandora> > I agree: this is really ugly. Since doc-strings are something special, > I don't think, we should travel further down this road. I believe, > we should use a special doc-string extration-tool (possibly build > on top of ping's 'inspect.py'?), which will then create a .pot-file > solely out of __doc__-strings. I agree. Again, I'd like to advertise Fran=E7ois Pinard's xpot, which can extract doc strings from both Python code and C code. Regards, Martin From Moshe Zadka Fri Jun 2 18:52:59 2000 From: Moshe Zadka (Moshe Zadka) Date: Fri, 2 Jun 2000 20:52:59 +0300 (IDT) Subject: [Python-Dev] Suggestion: stopping to trust os mtimes Message-ID: Trusting OS-based mtimes for .pyc caching has some inherent problems. (Clock syncing and similar) Frankly, though I've never been bitten by this, it does give me an uncomfortable feeling. What if, instead, we'd use md5- or sha-based approach? I'm willing to bet that the 2^128 chance of problems is miniscule compared to the real problems clock syncing has already caused. (I think I remember some problem with .pyc's on IIS, but I may just be hallucinating) Problems: .pyc size would increase by 24 bytes -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com From trentm@activestate.com Fri Jun 2 19:14:17 2000 From: trentm@activestate.com (Trent Mick) Date: Fri, 2 Jun 2000 11:14:17 -0700 Subject: [Python-Dev] PyMarshal_WriteLongToFile: writes 'long' or 32-bit integer? Message-ID: <20000602111417.A17233@activestate.com> So, is PyMarshal_WriteLongToFile intended to write a C long, regardless of its size, or is it intended to alway write 32-bits? Currently it just writes 32-bits and if sizeof(long) > 4 for that platform then it is silently truncated. PyMarshal_WriteLongToFile is currently only used (in the core anyway) to write the magic number and timestamp for .pyc files in import.c. The current situation is pretty misleading. If you write a long directly with PyMarshal_WriteLongToFile your long is truncated to 32-bits. However, if you write a long indirectly by PyMarshal_WriteObjectToFile, where that Python object is or contains a PyInt (C long), then the long is *not* truncated. Options: 1. leave it, who cares 2. - change PyMarshal_WriteLongToFile to write 64-bits if long is 64-bits - add something like PyMarshal_WriteInt32ToFile for the benefit of users like import.c that want to control exactly how many bytes get written 3. - change PyMarshal_WriteLongToFile to raise an exception if the long overflows a 32-bit range Thanks, Trent -- Trent Mick trentm@activestate.com From pf@artcom-gmbh.de Fri Jun 2 20:21:30 2000 From: pf@artcom-gmbh.de (Peter Funk) Date: Fri, 2 Jun 2000 21:21:30 +0200 (MEST) Subject: [Python-Dev] Suggestion: stopping to trust os mtimes In-Reply-To: from Moshe Zadka at "Jun 2, 2000 8:52:59 pm" Message-ID: hi, Moshe Zadka wrote: > Trusting OS-based mtimes for .pyc caching has some inherent problems. > (Clock syncing and similar) Frankly, though I've never been bitten by > this, it does give me an uncomfortable feeling. What if, instead, we'd use > md5- or sha-based approach? I'm willing to bet that the 2^128 chance of > problems is miniscule compared to the real problems clock syncing has > already caused. (I think I remember some problem with .pyc's on IIS, but > I may just be hallucinating) The timestamp is returned by simply 'stat'ing the .py file. If you want more, you actually would have to open the .py files all the time. This would be trading a big performance penalty for a security, that will almost always not needed. In Unix many sub systems (for example 'make' depend on a monotone system clock. A random jumping clock would break many of them anyway. Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen) From gstein@lyra.org Fri Jun 2 20:53:21 2000 From: gstein@lyra.org (Greg Stein) Date: Fri, 2 Jun 2000 12:53:21 -0700 (PDT) Subject: [Python-Dev] Suggestion: stopping to trust os mtimes In-Reply-To: Message-ID: On Fri, 2 Jun 2000, Moshe Zadka wrote: > Trusting OS-based mtimes for .pyc caching has some inherent problems. > (Clock syncing and similar) Frankly, though I've never been bitten by > this, it does give me an uncomfortable feeling. What if, instead, we'd use > md5- or sha-based approach? That is an expensive computation. You'd have to read the whole file in and compute the hash. Today, we simply stat() each file. If the .pyc looks valid, we open it and check the date stamp against one of those stat's. You would be adding an open(), a read of the full file, and compute a hash -- to every import of a .pyc. -1 Cheers, -g -- Greg Stein, http://www.lyra.org/ From mal@lemburg.com Fri Jun 2 20:13:20 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 02 Jun 2000 21:13:20 +0200 Subject: [Python-Dev] Suggestion: stopping to trust os mtimes References: Message-ID: <39380750.97CD3BA0@lemburg.com> Moshe Zadka wrote: > > Trusting OS-based mtimes for .pyc caching has some inherent problems. > (Clock syncing and similar) Frankly, though I've never been bitten by > this, it does give me an uncomfortable feeling. What if, instead, we'd use > md5- or sha-based approach? I'm willing to bet that the 2^128 chance of > problems is miniscule compared to the real problems clock syncing has > already caused. (I think I remember some problem with .pyc's on IIS, but > I may just be hallucinating) > > Problems: > .pyc size would increase by 24 bytes Much worse: you'd have to recalculate the MD5-sum every time you import the .pyc file... Frankly, I don't think this is needed at all ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From loewis@informatik.hu-berlin.de Fri Jun 2 21:46:34 2000 From: loewis@informatik.hu-berlin.de (Martin von Loewis) Date: Fri, 2 Jun 2000 22:46:34 +0200 (MET DST) Subject: [Python-Dev] Re: [Patches] Translating doc strings In-Reply-To: (message from Ka-Ping Yee on Fri, 2 Jun 2000 12:07:22 -0700 (PDT)) References: Message-ID: <200006022046.WAA29600@pandora> > But presumably we want to get all the strings, don't we? Certainly not. For example, in ftplib, the string "anonymous" should not be translated - it would end up as "anonym" in German, and that would not be accepted by FTP servers. In general, great care is needed to select translatable strings. For example, the GNU ls program was localized to print the month names in German. Pretty safe, eh? Now, the emacs dired mode wouldn't recognize any file names in the list output anymore, because it had a regular expression to detect the various fields, which involved an alternative list for all the month names... Regards, Martin From pingster@ilm.com Fri Jun 2 20:07:22 2000 From: pingster@ilm.com (Ka-Ping Yee) Date: Fri, 2 Jun 2000 12:07:22 -0700 (PDT) Subject: [Python-Dev] Re: [Patches] Translating doc strings In-Reply-To: Message-ID: On Fri, 2 Jun 2000, Peter Funk wrote: > > I agree: this is really ugly. Since doc-strings are something special, > I don't think, we should travel further down this road. I believe, > we should use a special doc-string extration-tool (possibly build > on top of ping's 'inspect.py'?), which will then create a .pot-file > solely out of __doc__-strings. Getting __doc__ strings is pretty easy (inspect.py is one possibility). But presumably we want to get all the strings, don't we? That should be trivial with tokenize, right? ---- getstrings.py ----- import sys, tokenize strings = [] def tokeneater(type, token, start, end, line): if type == tokenize.STRING: strings.append(eval(token)) file = open(sys.argv[1]) tokenize.tokenize(file.readline, tokeneater) print strings ------------------------ % ./getstrings.py /usr/local/lib/python1.5/calendar.py ['calendar.error', 'Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday', 'Saturday', 'Sunday', 'Mon', 'Tue', 'Wed', 'Thu', 'Fri', 'Sat', 'Sun', '', 'January', 'February', 'March', 'April', 'May', 'June', 'July', 'August', 'September', 'October', 'No vember', 'December', ' ', 'Jan', 'Feb', 'Mar', 'Apr', 'May', 'Jun', 'Jul', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec', 'bad month number', ' ', ' ', '', '', ' ', ' ', '\012', '\012', '\012', ' ', '', '', ' '] Am i missing something? -- ?!ng From gstein@lyra.org Fri Jun 2 22:32:52 2000 From: gstein@lyra.org (Greg Stein) Date: Fri, 2 Jun 2000 14:32:52 -0700 (PDT) Subject: [Python-Dev] Suggestion: stopping to trust os mtimes In-Reply-To: Message-ID: On Fri, 2 Jun 2000, Peter Funk wrote: > Moshe Zadka wrote: > > Trusting OS-based mtimes for .pyc caching has some inherent problems. > > (Clock syncing and similar) Frankly, though I've never been bitten by > > this, it does give me an uncomfortable feeling. What if, instead, we'd use > > md5- or sha-based approach? I'm willing to bet that the 2^128 chance of > > problems is miniscule compared to the real problems clock syncing has > > already caused. (I think I remember some problem with .pyc's on IIS, but > > I may just be hallucinating) > > The timestamp is returned by simply 'stat'ing the .py file. If you > want more, you actually would have to open the .py files all the time. > This would be trading a big performance penalty for a security, that > will almost always not needed. In Unix many sub systems (for example > 'make' depend on a monotone system clock. A random jumping clock > would break many of them anyway. He does have a point, but I think the wrong solution :-) While the clock may be monotonically increasing on one system, it isn't always the case when things like NFS come into play. I recall a case back '95 when I was editing a .py over an NFS mount and running the code on the target machine. The clocks on the two boxes were off by about three seconds. I was going thru the edit/run/edit/run cycle so quickly, that at one point, I saved a .py file that was older than the associated .pyc file. Needless to say, I was really confused that my recent edit didn't produce the desired result :-) Cheers, -g p.s. and no, I don't know why the internal timestamp didn't take effect -- Greg Stein, http://www.lyra.org/ From pingster@ilm.com Sat Jun 3 00:10:01 2000 From: pingster@ilm.com (Ka-Ping Yee) Date: Fri, 2 Jun 2000 16:10:01 -0700 (PDT) Subject: [Python-Dev] Protecting __name__ &c. Message-ID: Would it be too much trouble to prevent replacing double-underscore attributes like __name__ and __file__? I'll accept a "consenting adults" argument -- it's just that somehow this makes me uneasy: Python 1.5.2 (#54, Jul 14 1999, 12:50:51) [C] on irix6 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import foo >>> foo.__name__ 'bar' >>> foo.__file__ 'bar.py' >>> foo Of course, there is no 'bar.py'. 'foo.py' just contains __file__ = 'bar.py' __name__ = 'bar' (If you say i deserved to be punished for such heresy, fine...) -- ?!ng From mhammond@skippinet.com.au Sat Jun 3 00:21:07 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Sat, 3 Jun 2000 09:21:07 +1000 Subject: [Python-Dev] Protecting __name__ &c. In-Reply-To: Message-ID: > Would it be too much trouble to prevent replacing > double-underscore attributes like __name__ and __file__? This can be handy sometimes. > I'll accept a "consenting adults" argument -- it's just > that somehow this makes me uneasy: OK - accept it :-) Just dont do it if it makes you uneasy. > >>> import foo > >>> foo.__name__ > 'bar' > >>> foo.__file__ > 'bar.py' > >>> foo > That is no worse than, say: >>> a=1 >>> globals()['a']=2 >>> a 2 So you could make the same argument that globals() should be read-only, to force you to do the "normal" thing. To me, this is one of Python's big features. I dont want it holding my hand so tightly it cuts circulation :-) Mark. From akuchlin@mems-exchange.org Sat Jun 3 04:15:50 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Fri, 2 Jun 2000 23:15:50 -0400 Subject: [Python-Dev] What's New (first draft) Message-ID: <20000602231550.A986@newcnri.cnri.reston.va.us> I've put up the crude first draft of a "What's New in Python 1.6" article, co-written with Moshe Zadka. Please offer comments (or even patches to the LaTeX!). http://www.python.net/crew/amk/python/writing/new-python/ PDF, DVI, ASCII, and the LaTeX source are in: ftp://www.python.net/pub/crew/amk/new/ Various people are mentioned by name in the document ("effbot did this; MAL did that; Christian did that other thing...") because I want to emphasize the number of contributors to this release; does everyone think this is a good idea? If I've missed your name, or credited you wrongly, please let me know. --amk From akuchlin@mems-exchange.org Sat Jun 3 04:25:21 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Fri, 2 Jun 2000 23:25:21 -0400 Subject: [Python-Dev] Revised 1.6 jobs list Message-ID: <20000602232521.B986@newcnri.cnri.reston.va.us> I've slightly revised the 1.6 jobs list at http://www.python.net/crew/amk/python/1.6-jobs.html . Things still on the TODO list, maybe: Import hooks revamp (or is this a post-1.6 thing?) Update the documentation to match 1.6 changes. Document more undocumented modules (goes without saying, really...) : codecs, unicodedata, mmap, pyexpat, curses, regrtest. Unicode: Compress the size of unicodedatabase Unicode: Write \N{SMILEY} codec for Unicode (Bill Tutt has a patch) Unicode: the various XXX itemsin Misc/unicode.txt (or are they done?) Delete obsolete subdirectories in Demo/ directory Refurbish Demo subdirectories to be properly documented, match modern coding style, etc. Fix ./ld_so_aix installation problem on AIX Make test.regrtest.py more usable outside of thePython test suite Conservative garbage collection of cycles (maybe -- I don't know what GvR thinks about this) Changes to PyExpat module Test the hell out of SRE The end of coding may be in sight, leaving only the job of documenting everything new. I'm getting kind of worried about the lengthening backlog of patches, though; maybe next week we can start cutting it down? (Quick, while Guido's away, everyone come up with new keywords and check them in!) --amk From esr@thyrsus.com Sat Jun 3 04:49:16 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Fri, 2 Jun 2000 23:49:16 -0400 Subject: [Python-Dev] Revised 1.6 jobs list In-Reply-To: <20000602232521.B986@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Fri, Jun 02, 2000 at 11:25:21PM -0400 References: <20000602232521.B986@newcnri.cnri.reston.va.us> Message-ID: <20000602234916.B9680@thyrsus.com> Andrew Kuchling : > Document more undocumented modules (goes without saying, really...) : codecs, > unicodedata, mmap, pyexpat, curses, regrtest. About curses. Have you got the entry points listed and dxescribed yet? If so, I'll flesh out the docs with my tutorial stuff. We have a volunteer maintainer for curses after release, now, BTW. It's new Pythoneer Jim Dennis, the "Answer Guy" from the Linux Gazette. -- Eric S. Raymond The end move in politics is always to pick up a gun. -- R. Buckminster Fuller From bwarsaw@python.org Sat Jun 3 05:41:42 2000 From: bwarsaw@python.org (Barry A. Warsaw) Date: Sat, 3 Jun 2000 00:41:42 -0400 (EDT) Subject: [Python-Dev] Revised 1.6 jobs list References: <20000602232521.B986@newcnri.cnri.reston.va.us> Message-ID: <14648.35974.486959.379543@anthem.python.org> Did we ever decide on building in thread support by default? I'd really like to see threads enabled by default in 1.6 and I /think/ it'll just take some autoconf hacking, which I'm willing to do. Are there any objections to building in threads support by default if autoconf detects threads? -Barry From Moshe Zadka Sat Jun 3 07:05:09 2000 From: Moshe Zadka (Moshe Zadka) Date: Sat, 3 Jun 2000 09:05:09 +0300 (IDT) Subject: [Python-Dev] Suggestion: stopping to trust os mtimes In-Reply-To: Message-ID: On Fri, 2 Jun 2000, Greg Stein wrote: > He does have a point, but I think the wrong solution :-) In my defense, it was after spending the whole day on my feet giving a lecture, or driving (for 12 hours). But it does bother me, even if the solution is terrible. How about having, in addition to the time-stamp, the size of the file? At least on UNIX, it comes for free with the same stat call. -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com From Moshe Zadka Sat Jun 3 08:56:15 2000 From: Moshe Zadka (Moshe Zadka) Date: Sat, 3 Jun 2000 10:56:15 +0300 (IDT) Subject: [Python-Dev] PyMarshal_WriteLongToFile: writes 'long' or 32-bit integer? In-Reply-To: <20000602111417.A17233@activestate.com> Message-ID: On Fri, 2 Jun 2000, Trent Mick wrote: > 3. - change PyMarshal_WriteLongToFile to raise an exception if the long > overflows a 32-bit range +1 on that, finally non-portable integers will cause an exception. -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com From Moshe Zadka Sat Jun 3 09:11:45 2000 From: Moshe Zadka (Moshe Zadka) Date: Sat, 3 Jun 2000 11:11:45 +0300 (IDT) Subject: [Python-Dev] Protecting __name__ &c. In-Reply-To: Message-ID: On Fri, 2 Jun 2000, Ka-Ping Yee wrote: > Would it be too much trouble to prevent replacing > double-underscore attributes like __name__ and __file__? Well, special casing seems like a bad idea on the face of it. Where does it stop? The correct way to "solve" this, is to add declarations to Python, including "constant" declaration, and then saying that __name__ and __file__ are "implicitly declared" constants. please-scatter-IMHOs-generously-throughtout-the-mail-ly y'rs, Z. -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com From gstein@lyra.org Sat Jun 3 10:52:39 2000 From: gstein@lyra.org (Greg Stein) Date: Sat, 3 Jun 2000 02:52:39 -0700 (PDT) Subject: [Python-Dev] Revised 1.6 jobs list In-Reply-To: <14648.35974.486959.379543@anthem.python.org> Message-ID: On Sat, 3 Jun 2000, Barry A. Warsaw wrote: > Did we ever decide on building in thread support by default? I'd > really like to see threads enabled by default in 1.6 and I /think/ > it'll just take some autoconf hacking, which I'm willing to do. Are > there any objections to building in threads support by default if > autoconf detects threads? +1 -- if they are there, then build them in! Cheers, -g -- Greg Stein, http://www.lyra.org/ From gmcm@hypernet.com Sat Jun 3 12:26:18 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Sat, 3 Jun 2000 07:26:18 -0400 Subject: [Python-Dev] Revised 1.6 jobs list In-Reply-To: <20000602232521.B986@newcnri.cnri.reston.va.us> Message-ID: <1252090883-19062603@hypernet.com> Andrew Kuchling wrote: > I've slightly revised the 1.6 jobs list > at http://www.python.net/crew/amk/python/1.6-jobs.html . > Things still on the TODO list, maybe: > > Import hooks revamp (or is this a post-1.6 thing?) The import SIG was created to resolve the controversies around imputils. The archives of the import SIG contain absolutely no controversy. So I say do it. - Gordon From skip@mojam.com (Skip Montanaro) Sat Jun 3 13:15:28 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Sat, 3 Jun 2000 07:15:28 -0500 (CDT) Subject: [Python-Dev] Suggestion: stopping to trust os mtimes In-Reply-To: References: Message-ID: <14648.63200.850429.304545@beluga.mojam.com> Greg> I recall a case back '95 when I was editing a .py over an NFS Greg> mount and running the code on the target machine. The clocks on Greg> the two boxes were off by about three seconds. I was going thru Greg> the edit/run/edit/run cycle so quickly, that at one point, I saved Greg> a .py file that was older than the associated .pyc file. A help I think would be to compare the mtimes of the .py and .pyc files with the current system clock and squawk if either appears to have been created in the future. I believe this is what GNU make does. Of course, the best solution to all of this is the non-Python solution: use NTP so your clocks stay sync'd. It's even available out-of-the-box on my iMac... -- Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ "We have become ... the stewards of life's continuity on earth. We did not ask for this role... We may not be suited to it, but here we are." - Stephen Jay Gould From Moshe Zadka Sat Jun 3 13:53:47 2000 From: Moshe Zadka (Moshe Zadka) Date: Sat, 3 Jun 2000 15:53:47 +0300 (IDT) Subject: [Python-Dev] Suggestion: stopping to trust os mtimes In-Reply-To: <14648.63200.850429.304545@beluga.mojam.com> Message-ID: On Sat, 3 Jun 2000, Skip Montanaro wrote: > Of course, the best solution to all of this is the non-Python solution: use > NTP so your clocks stay sync'd. It's even available out-of-the-box on my > iMac... But the "Python Way" was always to adapt: not to require One True Way, but to use the facilities where it finds itself. In any case, is there any objection to storing the size of the .py alongside it's mtime in the .pyc, and regenerating if either is changed? This is just as efficient, and much more reliable. -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com From mal@lemburg.com Sat Jun 3 10:55:26 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat, 03 Jun 2000 11:55:26 +0200 Subject: [Python-Dev] Revised 1.6 jobs list References: <20000602232521.B986@newcnri.cnri.reston.va.us> Message-ID: <3938D60E.391AAF31@lemburg.com> Andrew Kuchling wrote: > > I've slightly revised the 1.6 jobs list > at http://www.python.net/crew/amk/python/1.6-jobs.html . > Things still on the TODO list, maybe: > > Import hooks revamp (or is this a post-1.6 thing?) > Update the documentation to match 1.6 changes. > Document more undocumented modules (goes without saying, really...) : codecs, > unicodedata, mmap, pyexpat, curses, regrtest. I would appreciate some help with codec and unicodedata. codec.py has quite a bit of __doc__ string documentation which can be used more or less directly for the TeX docs. > Unicode: Compress the size of unicodedatabase Christian was working on this one, but I never got the patches ... Chris ? > Unicode: Write \N{SMILEY} codec for Unicode (Bill Tutt has a patch) I wonder why that patch hasn't been accepted yet -- I guess the patches list needs some more people willing to review things and of course people with check in permissions. I would volunteer to handle the above for the Unicode parts of the distribution if someone would explain to me how to checkin new code into SourceForge CVS. > Unicode: the various XXX itemsin Misc/unicode.txt (or are they done?) Hmm, there are no XXX markings left in my version of that file -- perhaps I've missed adding it to the patch sets... Anyway, the file will have to undergo some rewrite now that the default encoding strategy has changed. I'll fix that next week. > Delete obsolete subdirectories in Demo/ directory > Refurbish Demo subdirectories to be properly documented, match modern coding > style, etc. > Fix ./ld_so_aix installation problem on AIX > Make test.regrtest.py more usable outside of thePython test suite > Conservative garbage collection of cycles (maybe -- I don't know what GvR > thinks about this) > Changes to PyExpat module > Test the hell out of SRE > > The end of coding may be in sight, leaving only the job of documenting > everything new. I'm getting kind of worried about the lengthening backlog > of patches, though; maybe next week we can start cutting it down? (Quick, > while Guido's away, everyone come up with new keywords and check them in!) :-) Still, you've got a point there: Trent's patches are getting piled up and due to the fact that they touch many different parts of the code, they are likely to get in the way of other patches. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From jeremy@beopen.com Sat Jun 3 17:11:48 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Sat, 3 Jun 2000 12:11:48 -0400 Subject: [Python-Dev] Revised 1.6 jobs list In-Reply-To: <3938D60E.391AAF31@lemburg.com> Message-ID: M.-A. Lemburg wrote: >I wonder why that patch hasn't been accepted yet -- I guess >the patches list needs some more people willing to review things >and of course people with check in permissions. One of the problems I'm having is keeping track of which patches are still outstanding. This is really a management/tools problem. I have a mailbox full of messages from the patches list -- some of the messages are patches, others are discussion. Some patches supercede others or are duplicates. It would help if we had better tools for managing the submitted/pending patches. SourceForge makes it a little more inconvenient to check which patches have been applied. Under the old CVS arrangement, it was a local operation to do a cvs log or diff. Now it's a slow network operation that requires authentication. (I really want a local mirror of the entire CVS repository!) Sorry for the excuses. I think better tools would help a lot, but we'll have to get more people checkin privileges regardless. Jeremy From tismer@tismer.com Sat Jun 3 17:43:51 2000 From: tismer@tismer.com (Christian Tismer) Date: Sat, 03 Jun 2000 18:43:51 +0200 Subject: [Python-Dev] Revised 1.6 jobs list References: <20000602232521.B986@newcnri.cnri.reston.va.us> <3938D60E.391AAF31@lemburg.com> Message-ID: <393935C7.7624448A@tismer.com> "M.-A. Lemburg" wrote: > > Unicode: Compress the size of unicodedatabase > > Christian was working on this one, but I never got the > patches ... Chris ? Schmurpel :-> Something came in between where I couldn't resist to work on... yes, the microthread stuff was it. Ok, it is a pain for me to go for a sub-optimum solution, but yep, I'll force me to write the code gen now. ... > Still, you've got a point there: Trent's patches are getting > piled up and due to the fact that they touch many different > parts of the code, they are likely to get in the way of other > patches. patch-as-patch-can-ly y'rs - chris -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaunstr. 26 : *Starship* http://starship.python.net 14163 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF where do you want to jump today? http://www.stackless.com From tismer@tismer.com Sat Jun 3 17:44:31 2000 From: tismer@tismer.com (Christian Tismer) Date: Sat, 03 Jun 2000 18:44:31 +0200 Subject: [Python-Dev] Revised 1.6 jobs list References: <20000602232521.B986@newcnri.cnri.reston.va.us> <3938D60E.391AAF31@lemburg.com> Message-ID: <393935EF.89AA40DF@tismer.com> "M.-A. Lemburg" wrote: > > Unicode: Compress the size of unicodedatabase > > Christian was working on this one, but I never got the > patches ... Chris ? Schmurpel :-> Something came in between where I couldn't resist to work on... yes, the microthread stuff was it. Not to talk of the starship mess, which will hopefully end by this weekend... Ok, it is a pain for me to go for a sub-optimum solution, but yep, I'll force me to write the code gen now. ... > Still, you've got a point there: Trent's patches are getting > piled up and due to the fact that they touch many different > parts of the code, they are likely to get in the way of other > patches. patch-as-patch-can-ly y'rs - chris -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaunstr. 26 : *Starship* http://starship.python.net 14163 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF where do you want to jump today? http://www.stackless.com From gstein@lyra.org Sat Jun 3 20:41:19 2000 From: gstein@lyra.org (Greg Stein) Date: Sat, 3 Jun 2000 12:41:19 -0700 (PDT) Subject: [Python-Dev] Suggestion: stopping to trust os mtimes In-Reply-To: <14648.63200.850429.304545@beluga.mojam.com> Message-ID: On Sat, 3 Jun 2000, Skip Montanaro wrote: > Greg> I recall a case back '95 when I was editing a .py over an NFS > Greg> mount and running the code on the target machine. The clocks on > Greg> the two boxes were off by about three seconds. I was going thru > Greg> the edit/run/edit/run cycle so quickly, that at one point, I saved > Greg> a .py file that was older than the associated .pyc file. > > A help I think would be to compare the mtimes of the .py and .pyc files with > the current system clock and squawk if either appears to have been created > in the future. I believe this is what GNU make does. Sure, but to the target machine, the .pyc was fine and the .py was in the past. :-) Of course, the proper solution is to introduce compile/link stages into Python so that we don't get bitten by 3-second clock differences. :-) -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Sat Jun 3 21:26:00 2000 From: gstein@lyra.org (Greg Stein) Date: Sat, 3 Jun 2000 13:26:00 -0700 (PDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules mmapmodule.c,2.8,2.9 In-Reply-To: <200006031941.MAA21418@slayer.i.sourceforge.net> Message-ID: Actually, PyArg_ParseTuple() is a better call for this. It allows you to specify the method name: if (!PyArg_ParseTuple(args, ":close")) return NULL; Cheers,, -g On Sat, 3 Jun 2000, A.M. Kuchling wrote: > Update of /cvsroot/python/python/dist/src/Modules > In directory slayer.i.sourceforge.net:/tmp/cvs-serv21410 > > Modified Files: > mmapmodule.c > Log Message: > Add missing PyArg_NoArgs() calls to methods that didn't take arguments > (Pointed out by Moshe Zadka) > > > Index: mmapmodule.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Modules/mmapmodule.c,v > retrieving revision 2.8 > retrieving revision 2.9 > diff -C2 -r2.8 -r2.9 > *** mmapmodule.c 2000/05/03 23:44:32 2.8 > --- mmapmodule.c 2000/06/03 19:41:42 2.9 > *************** > *** 2,6 **** > / Author: Sam Rushing > / Hacked for Unix by A.M. Kuchling > ! / $Id: mmapmodule.c,v 2.8 2000/05/03 23:44:32 guido Exp $ > > / mmapmodule.cpp -- map a view of a file into memory > --- 2,6 ---- > / Author: Sam Rushing > / Hacked for Unix by A.M. Kuchling > ! / $Id: mmapmodule.c,v 2.9 2000/06/03 19:41:42 akuchling Exp $ > > / mmapmodule.cpp -- map a view of a file into memory > *************** > *** 76,79 **** > --- 76,81 ---- > mmap_close_method (mmap_object * self, PyObject * args) > { > + if (!PyArg_NoArgs(args)) > + return NULL; > #ifdef MS_WIN32 > UnmapViewOfFile (self->data); > *************** > *** 119,122 **** > --- 121,126 ---- > char * where; > CHECK_VALID(NULL); > + if (!PyArg_NoArgs(args)) > + return NULL; > if (self->pos >= 0 && self->pos < self->size) { > where = self->data + self->pos; > *************** > *** 132,136 **** > static PyObject * > mmap_read_line_method (mmap_object * self, > ! PyObject * args) > { > char * start = self->data+self->pos; > --- 136,140 ---- > static PyObject * > mmap_read_line_method (mmap_object * self, > ! PyObject * args) > { > char * start = self->data+self->pos; > *************** > *** 140,143 **** > --- 144,149 ---- > > CHECK_VALID(NULL); > + if (!PyArg_NoArgs(args)) > + return NULL; > > eol = memchr(start, '\n', self->size - self->pos); > *************** > *** 154,158 **** > static PyObject * > mmap_read_method (mmap_object * self, > ! PyObject * args) > { > long num_bytes; > --- 160,164 ---- > static PyObject * > mmap_read_method (mmap_object * self, > ! PyObject * args) > { > long num_bytes; > *************** > *** 226,230 **** > static PyObject * > mmap_write_byte_method (mmap_object * self, > ! PyObject * args) > { > char value; > --- 232,236 ---- > static PyObject * > mmap_write_byte_method (mmap_object * self, > ! PyObject * args) > { > char value; > *************** > *** 242,248 **** > static PyObject * > mmap_size_method (mmap_object * self, > ! PyObject * args) > { > CHECK_VALID(NULL); > > #ifdef MS_WIN32 > --- 248,256 ---- > static PyObject * > mmap_size_method (mmap_object * self, > ! PyObject * args) > { > CHECK_VALID(NULL); > + if (!PyArg_NoArgs(args)) > + return NULL; > > #ifdef MS_WIN32 > *************** > *** 347,350 **** > --- 355,360 ---- > { > CHECK_VALID(NULL); > + if (!PyArg_NoArgs(args)) > + return NULL; > return (Py_BuildValue ("l", self->pos) ); > } > *************** > *** 463,470 **** > > static int > ! mmap_buffer_getreadbuf(self, index, ptr) > ! mmap_object *self; > ! int index; > ! const void **ptr; > { > CHECK_VALID(-1); > --- 473,477 ---- > > static int > ! mmap_buffer_getreadbuf(mmap_object *self, int index, const void **ptr) > { > CHECK_VALID(-1); > *************** > *** 868,869 **** > --- 875,877 ---- > > } > + > > > _______________________________________________ > Python-checkins mailing list > Python-checkins@python.org > http://www.python.org/mailman/listinfo/python-checkins > -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Sat Jun 3 21:34:26 2000 From: gstein@lyra.org (Greg Stein) Date: Sat, 3 Jun 2000 13:34:26 -0700 (PDT) Subject: [Python-Dev] autoconf macros (was: RE: [Patches] Patch to Modules/pcre.h) In-Reply-To: Message-ID: [moving to python-dev] On Sun, 4 Jun 2000, Mark Hammond wrote: > > I don't even see where DONT_HAVE_SYS_TYPES_H is ever defined: > ... > > Is it defined in some Mac-specific project file? > > A few existed before, but I know I submitted a couple of the listed ones > for Windows CE. However, the CE config.h has never made it into the core, > hence you can't find that particular definition... Well, as I pointed out, the best way to do this is to add sys/types.h, sys/stat.h, and stat.h to the AC_CHECK_HEADER() macro in configure.in. The HAVE_SYS_TYPES_H macro and friends could then be checked. PC/wince_config.h (or whatever it is called) would just #undef the HAVE_* macros. The underlying issue here, is that autoconf can take care of these things for us quite easily -- that we don't need manual maintenance of the macros. For the odd platform without sys/types.h, autoconf will handle it, rather than Python needing to do a special-case declaration. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Sat Jun 3 21:44:07 2000 From: gstein@lyra.org (Greg Stein) Date: Sat, 3 Jun 2000 13:44:07 -0700 (PDT) Subject: [Python-Dev] Revised 1.6 jobs list In-Reply-To: Message-ID: On Sat, 3 Jun 2000, Jeremy Hylton wrote: >... > Sorry for the excuses. I think better tools would help a lot, but > we'll have to get more people checkin privileges regardless. There are several issues with expanded checkin privs: 1) trust: will the person make sure it is Right And Proper to do the checkin? (have they reviewed the code? is a a Good Change? etc) The counter here is that we don't want people that will simply take stuff arriving at patches@ and checking them in. 2) more people reviewing changes on the -checkins mailing list. Assuming that you want more than one pair of eyeballs looking at patches/code, that more people with commit privs increases the rate of commits, then you need more reviewers to keep up (because the reviewers probably are not going to review ALL checkins) 3) increasing dependence on -checkins means that patches MUST be smaller chunks. they MUST be single-purpose patches. practically nobody will review a 200k patch, or patches that fix N different things at once. A small, focused patch is easily reviewed. For example: Trent has recently mailed a bunch of patches to the patches list. This is Goodness: each one is focused and can be individually reviewed. Since they are not a single, giant blob, it also keeps them short and reviewable... each can have a +1/-1 independent of the others. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Sat Jun 3 22:14:49 2000 From: gstein@lyra.org (Greg Stein) Date: Sat, 3 Jun 2000 14:14:49 -0700 (PDT) Subject: [Python-Dev] Suggestion: stopping to trust os mtimes In-Reply-To: Message-ID: On Sat, 3 Jun 2000, Moshe Zadka wrote: >... > In any case, is there any objection to storing the size of the .py > alongside it's mtime in the .pyc, and regenerating if either is changed? > This is just as efficient, and much more reliable. If we change the header size, then this would be fine. At the moment, I don't think that anybody is suggesting a change to the .pyc header format because of the number of tool breakages that would ensue. People have seemed interested in my idea to update the marshal format to record a version number -- it doesn't require a change to the .pyc header. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Sat Jun 3 23:53:18 2000 From: gstein@lyra.org (Greg Stein) Date: Sat, 3 Jun 2000 15:53:18 -0700 (PDT) Subject: [Python-Dev] Re: httplib (was: Adding LDAP to the Python core... ?!) In-Reply-To: Message-ID: I found the problem. Sneaky... sock.makefile() does a dup() on the file descriptor, then opens a FILE* with that. See it coming yet? ... FILE* is a buffered thingy. stdio chunked in a block of data on the dup'd file descriptor. When we went to grab another chunk on the *original* descriptor, we missed input [that is now sitting in the FILE* buffer]. Answer: change the .makefile() in getreply() to: file = self.sock.makefile('rb', 0) This problem is going to affect the original httplib, too. IMO, we're about to replace the sucker, so no worries... Cheers, -g On Fri, 2 Jun 2000, Greg Stein wrote: > It looks like a definite bug. I have *no* idea, tho, why it is doing > that... I did quite a bit of testing with chunked replies. Admittedly, > though, I didn't stack up requests like you've done in your test. I'm > wrapping up mod_dav at the moment, so I don't really have time to look > deeply into this. Mebbe next week? > > Regarding the pipeline request thing. I think it would probably be best to > just drop the whole "hold the previous response and wait for it to be > closed" thing. I don't know why that is in there; probably a leftover > (converted) semantic from the old-style HTTP() class. I'd be quite fine > just axing it and allowing the client to shove ten requests down the pipe > before pulling the first response back out. > > Oh. Wait. Maybe that was it. You can't read the "next" response until the > first one has been read. Well... no need to block putting new responses; > we just need to create a way to "get the next reply" and/or "can I get the > next reply yet?" > > Cheers, > -g > > p.s. Moshe also had a short list of review items. I read thru them, but > not with the code in hand to understand some of his specifics. > > > On Wed, 31 May 2000, Jeremy Hylton wrote: > > >>>>> "GS" == Greg Stein writes: > > > > GS> [ and recall my email last week that I've updated httplib.py and > > GS> posted it to my web pages; it is awaiting review for integration > > GS> into the Python core; it still needs docs and more testing > > GS> scenarios, tho > > > > I've been looking at the httplib code, and I found what may be a bug. > > Not sure, because I'm not sure how the API works for pipelined > > requests. > > > > I've got some test code that looks a bit like this: > > > > def test_new_interface_series(urls): > > paths = [] > > the_host = None > > for url in urls: > > host, path = get_host_and_path(url) > > if the_host is None: > > the_host = host > > else: > > assert host == the_host > > paths.append(path) > > > > conn = httplib.HTTPConnection(the_host) > > for path in paths: > > conn.request('GET', path, headers={'User-Agent': 'httplib/Python'}) > > for path in paths: > > errcode, errmsg, resp = conn.getreply() > > buf = resp.read() > > if errcode == 200: > > print errcode, resp.headers > > else: > > print errcode, `errmsg`, resp > > print resp.getheader('Content-Length'), len(buf) > > print repr(buf[:40]) > > print repr(buf[-40:]) > > print > > conn.close() > > > > test_new_interface_series(['http://www.python.org/', > > 'http://www.python.org/pics/PyBanner054.gif', > > 'http://www.python.org/pics/PythonHi.gif', > > 'http://www.python.org/Jobs.html', > > 'http://www.python.org/doc/', > > 'http://www.python.org/doc/current/', > > ]) > > > > The second loop that reads the replies gets fouled up after a couple > > of responses. I added even more debugging and found that the first > > line of the corrupted response is > > > > > 'ontent-Type: text/html\015\012' > > > > It looks like some part of the program is consuming too much input. I > > haven't been able to figure out what part yet. Hoping that you might > > have some good ideas. > > > > Thinking about this issue, I came up with a potential API problem. > > You must read the body after calling getreply and before calling > > getreply a second time. This kind of implicit requirement is a bit > > tricky. It would help if the implementation could raise an error if > > this happens. It might be even better if it just worked, although it > > seems a bit too magical. > > > > Jeremy > > > > -- > Greg Stein, http://www.lyra.org/ > > > > -- Greg Stein, http://www.lyra.org/ From thomas@xs4all.net Sat Jun 3 23:56:01 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Sun, 4 Jun 2000 00:56:01 +0200 Subject: [Python-Dev] Re: Is it just Syntactic Sugar ? In-Reply-To: <3935B383.469032AE@python.org>; from guido@python.org on Wed, May 31, 2000 at 11:49:57PM +0000 References: <3929E47E.993727CF@roguewave.com> <3933F800.9CCE3B6D@cs.byu.edu> <20000530213957.E469@xs4all.nl> <20000531090045.I469@xs4all.nl> <3935B383.469032AE@python.org> Message-ID: <20000604005601.T469@xs4all.nl> On Wed, May 31, 2000 at 11:49:57PM +0000, Guido van Rossum wrote: > I know I shouldn't be posting in this thread, and I won't be there to read > the responses, but here's what I thought would be cool. As the 'lucky, lucky bastard' is probably standing before the altar about now, I'll send this to the dev-list instead. Not that I expect anyone *not* to be at the wedding, but I bet the rest is back sooner ;-) > x+=y is syntactic sugar for x=x.__add_ab__(y); the "ab" means "and becomes" > (an old Algol-68 naming convention; we could pick something better later > but this will do for the explanation). > For immutable types, this is defined as > def __add_ab__(self, other): > return self+other > For mutable types, this is defined as a self-mutating operation, > e.g. for lists it could be > def __add_ab__(self, other): > self.extend(other) > return self This was what I had in mind, and was trying to explain. Does you voicing your opinion mean someone (you ? someone else ?) is working on this, or soon going to work on this ? I had a chat with Michael about fixing up his patch to work all the way (it's currently a proof-of-concept-quick-hack that only works for builtin types) which prompted me to study Python's internals a bit closer. (I hope I dont sound too patronizing when I say I was impressed ;-) I'm curious what should happen with index-assignment and slice-assignment: x[y] += z x[:y] += z (Obviously this wont make sense for a lot of types, or will be too un-obvious to include, but I can imagine matrix-types to happily add this.) Would this call x.__add_item_ab__(y, z) and x.__add_slice_ab__(0, y, z) ? Or would x[y] += z always call x[y].__add_item_ab__() and x[:y] create a new object, a slice of x, and call its __add_ab__() method ? Or would it try all of them, or more, until it gets a good result ? Or am I running ahead of things and should we wait for a working patch first ? :) If I suddenly grow a deep understanding of Python's internals (not ruled out, it's fairly obvious) and hack-up something that works before anyone else, I'll be sure to mail ;) oh-and-congratulations-to-Mrs.-van-Rossum-too-ly yr's, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From gstein@lyra.org Sun Jun 4 00:06:07 2000 From: gstein@lyra.org (Greg Stein) Date: Sat, 3 Jun 2000 16:06:07 -0700 (PDT) Subject: [Python-Dev] httplib In-Reply-To: Message-ID: On Sat, 3 Jun 2000, Greg Stein wrote: > I found the problem. Sneaky... > > sock.makefile() does a dup() on the file descriptor, then opens a FILE* > with that. See it coming yet? ... > > FILE* is a buffered thingy. stdio chunked in a block of data on the dup'd > file descriptor. When we went to grab another chunk on the *original* > descriptor, we missed input [that is now sitting in the FILE* buffer]. > > Answer: change the .makefile() in getreply() to: > > file = self.sock.makefile('rb', 0) > > This problem is going to affect the original httplib, too. IMO, we're > about to replace the sucker, so no worries... Oh... actually it won't affect the original since that doesn't pipeline requests. -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Sun Jun 4 00:13:55 2000 From: gstein@lyra.org (Greg Stein) Date: Sat, 3 Jun 2000 16:13:55 -0700 (PDT) Subject: [Python-Dev] more on httplib Message-ID: I would like to propose a few changes to the (new) httplib: *) drop HTTPS() -- this class isn't in 1.5.2, so there isn't a reason to provide backwards-compat for it *) revamp the pipeline support: - record the "last response object" ... when a new getreply() is done, then we store the "last" into response.prior - reading of the "HTTP/1.1 " line is deferred, and performed by the response object - the read of that line is lazy - if the response line is read *before* the "prior" response (if any) is "closed", then an exception is raised: ResponseNotReady *) address some of Moshe's concerns: - use class-based exceptions - clarify that HTTPConnection is designed for *blocking* sockets - conn.close() followed by conn.send() will reopen the socket. This could lead to programming errors. I'll add a class-based default flag to disable this behavior. - in request(), we check for errno==32 ... what to do on Windows? I will implement these changes in small chunks so that each can be reviewed in my CVS repository. The history is available at: http://www.lyra.org/cgi-bin/viewcvs.cgi/gjspy/httplib.py/ Cheers, -g -- Greg Stein, http://www.lyra.org/ From mhammond@skippinet.com.au Sun Jun 4 03:03:34 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Sun, 4 Jun 2000 12:03:34 +1000 Subject: [Python-Dev] What's New (first draft) In-Reply-To: <20000602231550.A986@newcnri.cnri.reston.va.us> Message-ID: > emphasize the number of contributors to this release; does everyone think > this is a good idea? If I've missed your name, or credited you wrongly, > please let me know. OK - as you insist :-) Bill Tutt and I could do with a credit for the new winreg module. Thanks, Mark. From tim_one@email.msn.com Sun Jun 4 05:09:02 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 4 Jun 2000 00:09:02 -0400 Subject: [Python-Dev] Suggestion: stopping to trust os mtimes In-Reply-To: Message-ID: <000a01bfcdda$9e876060$1d2d153f@tim> [Moshe] > How about having, in addition to the time-stamp, the size of the file? > At least on UNIX, it comes for free with the same stat call. +1 from me. Note that, besides inter-machine clock skew, some filesystems have a timestamp granularity too coarse to distinguish close-in-time writes. For those (& related) reasons, the attentive Pythoneer will have noted that all of the winning 1st-round Software Carpentry "make"-replacement designs provide for alternatives to timestamps. Tom Tromey's has the clearest discussion of the problems with timestamps: http://software-carpentry.codesourcery.com/entries/build/Tromey/Tromey.html In my industrial experience, (timestamp, size) pairs have never failed in practice. However, "my industrial experience" has been entirely in projects where source-control wrappers add a checkin comment block to every checked-in file, and that alone made it exceedingly unlikely that any two successive versions of a file would have the same size. In Python I'm still (a little) worried about cases like SOME_GLOBAL_CONFIG_OPTION = 0 where "0" gets replaced by "1" or "2" or ... there are lots of interesting things you can do to Python programs without changing their size. At Dragon, checked-in Python files were also subject to the "checkin comment block" rule, so no project under source control suffered from this. I suspect it burned people in their pre-source-controlled development projects, though! One group in particular had a project that involved acres of machine-generated Python modules, and I know they suffered from coarse timestamps on their flavor of Unix (so part of their "make" procedure was to nuke all .pyc's on each build). it's-easy-to-laugh-at-problems-you-don't-have-ly y'rs - tim From Moshe Zadka Sun Jun 4 05:59:31 2000 From: Moshe Zadka (Moshe Zadka) Date: Sun, 4 Jun 2000 07:59:31 +0300 (IDT) Subject: [Python-Dev] Suggestion: stopping to trust os mtimes In-Reply-To: <000a01bfcdda$9e876060$1d2d153f@tim> Message-ID: On Sun, 4 Jun 2000, Tim Peters wrote: [Moshe] > How about having, in addition to the time-stamp, the size of the file? > At least on UNIX, it comes for free with the same stat call. [Tim] > +1 from me. Now there is the big problem, that this will be changing the header size. I thought that this would be a good time anyway, since 1.5.2 pycs aren't compatible with 1.6, but changing the header size is a bigger thing. so-this-waits-until-guido-comes-back-i-guess-ly y'rs, Z. -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com From bwarsaw@python.org Sun Jun 4 21:51:30 2000 From: bwarsaw@python.org (Barry A. Warsaw) Date: Sun, 4 Jun 2000 16:51:30 -0400 (EDT) Subject: [Python-Dev] Revised 1.6 jobs list References: <3938D60E.391AAF31@lemburg.com> Message-ID: <14650.49490.725648.798719@anthem.python.org> >>>>> "JH" == Jeremy Hylton writes: JH> One of the problems I'm having is keeping track of which JH> patches are still outstanding. SF has a patch manager but I haven't played with it much. In fact, I can't seem to find it for the Python project, but it's there in the Mailman project. -Barry From gstein@lyra.org Sun Jun 4 21:55:09 2000 From: gstein@lyra.org (Greg Stein) Date: Sun, 4 Jun 2000 13:55:09 -0700 (PDT) Subject: [Python-Dev] Revised 1.6 jobs list In-Reply-To: <14650.49490.725648.798719@anthem.python.org> Message-ID: On Sun, 4 Jun 2000, Barry A. Warsaw wrote: > >>>>> "JH" == Jeremy Hylton writes: > > JH> One of the problems I'm having is keeping track of which > JH> patches are still outstanding. > > SF has a patch manager but I haven't played with it much. In fact, I > can't seem to find it for the Python project, but it's there in the > Mailman project. You can administratively turn those things on/off, I thought. You're an admin, Barry, so you should be able to turn the thing on. Cheers, -g p.s. and yah.. there are damn too many projects at SF that are just a project name. no code, no description, all features enabled for no purpose, etc... Newbie coders, me thinks. Python is Goodness because it does disable the unused items. -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Mon Jun 5 00:30:08 2000 From: gstein@lyra.org (Greg Stein) Date: Sun, 4 Jun 2000 16:30:08 -0700 (PDT) Subject: [Python-Dev] release forms? (was: [Patches] New sys method to return total reference count in debug builds.) Message-ID: Given the New World Order, how does that impact the need for these release statements and/or wet signatures? Or a better way to put it, who "owns" Python now? Given a "who", then we can ask that person/entity whether they want release statements. Given that Python is now on SourceForge, and there are multiple people (at CNRI and otherwise) that can directly make modifications, then the release below is certainly a bit "off". For example, David Ascher has commit privs, so at his "sole discretion, [he may] decide whether or not to incorporiate this contribution..." :-) Thoughts? Cheers, -g p.s. IMO, I'd like to see Guido own the Copyright for all current and future Python development -- Greg Stein, http://www.lyra.org/ ---------- Forwarded message ---------- Date: Mon, 5 Jun 2000 09:18:30 +1000 From: Mark Hammond To: patches@python.org Subject: [Patches] New sys method to return total reference count in debug builds. [... snip ...] Release info: I confirm that, to the best of my knowledge and belief, this contribution is free of any claims of third parties under copyright, patent or other rights or interests ("claims"). To the extent that I have any such claims, I hereby grant to CNRI a nonexclusive, irrevocable, royalty-free, worldwide license to reproduce, distribute, perform and/or display publicly, prepare derivative versions, and otherwise use this contribution as part of the Python software and its related documentation, or any derivative versions thereof, at no cost to CNRI or its licensed users, and to authorize others to do so. I acknowledge that CNRI may, at its sole discretion, decide whether or not to incorporate this contribution in the Python software and its related documentation. I further grant CNRI permission to use my name and other identifying information provided to CNRI by me for use in connection with the Python software and its related documentation. Mark. _______________________________________________ Patches mailing list Patches@python.org http://www.python.org/mailman/listinfo/patches From bwarsaw@python.org Mon Jun 5 04:09:36 2000 From: bwarsaw@python.org (bwarsaw@python.org) Date: Sun, 4 Jun 2000 23:09:36 -0400 (EDT) Subject: [Python-Dev] Revised 1.6 jobs list References: <14650.49490.725648.798719@anthem.python.org> Message-ID: <14651.6640.709657.306682@anthem.python.org> >>>>> "GS" == Greg Stein writes: GS> You can administratively turn those things on/off, I GS> thought. You're an admin, Barry, so you should be able to turn GS> the thing on. I'm happy to if people think it will help. SF's patch management is a durn site better than Python's is now . I'd also consider shutting off Jitterbug on python.org but I'm not sure how to (or if we should) migrate the current bug set to SF. -Barry From gstein@lyra.org Mon Jun 5 07:13:39 2000 From: gstein@lyra.org (Greg Stein) Date: Sun, 4 Jun 2000 23:13:39 -0700 (PDT) Subject: [Python-Dev] Revised 1.6 jobs list In-Reply-To: <14651.6640.709657.306682@anthem.python.org> Message-ID: On Sun, 4 Jun 2000 bwarsaw@python.org wrote: > >>>>> "GS" == Greg Stein writes: > > GS> You can administratively turn those things on/off, I > GS> thought. You're an admin, Barry, so you should be able to turn > GS> the thing on. > > I'm happy to if people think it will help. SF's patch management is a > durn site better than Python's is now . I'd also consider > shutting off Jitterbug on python.org but I'm not sure how to (or if we > should) migrate the current bug set to SF. IMO, use the provided tools. The Patch Manager is more than we have now. It also allows assignment, which can be nice :-) (compared to the arbitrary "who is taking care of this patch?" thing today) The SF bug database certainly works, and it provides additional "locality" for the code + bugs + patches. Cheers, -g -- Greg Stein, http://www.lyra.org/ From jeremy@beopen.com Mon Jun 5 05:43:45 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Mon, 5 Jun 2000 00:43:45 -0400 (EDT) Subject: [Python-Dev] Revised 1.6 jobs list In-Reply-To: <3938D60E.391AAF31@lemburg.com> References: <20000602232521.B986@newcnri.cnri.reston.va.us> <3938D60E.391AAF31@lemburg.com> Message-ID: <14651.12289.191631.704477@localhost.localdomain> [Entry from AMK's 1.6 jobs list:] > Conservative garbage collection of cycles (maybe -- I don't know what GvR > thinks about this) I believe Guido would like to see a version of Neil's patches integrated into Python 1.6, most likely turned off by default but with a configure flag to enable. I would like to check the patch in soon but I have had some trouble with segfaults. I ran a simple benchmark using the compiler code in the nondist tree to compile itself. I get a crash during a routine collect pass, where it looks like the GC header info is getting trashed. I haven't had much time to track it any farther. If anyone else is interested, I'd love to hear about successes using the GC patch with other large programs. I'd like to run at least Gadfly and Grail successfully before committing the patch. I wonder if "conservative" is the right word to describe the GC approach? I think conservative means that the garbage collector is not told what is a pointer and what is not, so it must conservatively assume that every bit pattern could represent a pointer. The GC patch is not conservative in this sense. It does have a mechanism that is "conservative" in a very broad sense, i.e. it does not attempt to trace every reference, but depends on the ref count fields to account for references held in untraced variables on the C stack. I'm not sure what the right terminology for this approach is. I also worry that the performance impact of the GC patch is not at all understood. I don't know what informed the choice of heuristics for deciding how often to collect and how to move objects between generations. (The current scheme has three generations.) It would be good to get a working patch in before the next alpha release and then gather a lot of data to help make good choices about these parameters. Jeremy PS Even if Guido doesn't think the GC patch should go in, we've got a golden opportunity. I caught him in a state of newly-wedded bliss this morning and convinced him to let me check in my non-optional braces patch while he's on his honeymoon. He's so happy he'll let us get away with anything. PPS I don't know if we should really carry on about personal matters on a development list, but I hope no one minds if I indulge briefly: Guido & Kim's wedding yesterday was beautiful and fun, held outside in meadow looking out on hills and woods. They are great couple and I'm sure they'll be very happy. From jeremy@beopen.com Mon Jun 5 05:58:11 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Mon, 5 Jun 2000 00:58:11 -0400 (EDT) Subject: [Python-Dev] Re: httplib (was: Adding LDAP to the Python core... ?!) In-Reply-To: References: Message-ID: <14651.13155.253651.575394@localhost.localdomain> >>>>> "GS" == Greg Stein writes: GS> I found the problem. Sneaky... sock.makefile() does a dup() on GS> the file descriptor, then opens a FILE* with that. See it coming GS> yet? ... Bingo! I was suspicious of all these dup'd file descriptors, but missed the connection to a FILE* object. [In a previous message you wrote:] >> >> Regarding the pipeline request thing. I think it would probably >> be best to just drop the whole "hold the previous response and >> wait for it to be closed" thing. [...] >> >> Oh. Wait. Maybe that was it. You can't read the "next" response >> until the first one has been read. Well... no need to block >> putting new responses; we just need to create a way to "get the >> next reply" and/or "can I get the next reply yet?" >> Maybe I should clarify the concern I had here. I think we're on the same page, but I'm not sure. The problem with pipelined requests is that the client must be sure to read all of response I before it can call getreply to get response I+1. I imagine that it could add a lot of complexity to use code to implement this requirement, e.g. when multiple threads are sharing a single connection. It would be good if the library could do something reasonable about the multiplexing. In the absence of making it just work, the library could raise an error that makes clear what has gone wrong -- that the client isn't using the interface properly. Jeremy From jeremy@beopen.com Mon Jun 5 06:00:06 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Mon, 5 Jun 2000 01:00:06 -0400 (EDT) Subject: [Python-Dev] Re: Is it just Syntactic Sugar ? In-Reply-To: <20000604005601.T469@xs4all.nl> References: <3929E47E.993727CF@roguewave.com> <3933F800.9CCE3B6D@cs.byu.edu> <20000530213957.E469@xs4all.nl> <20000531090045.I469@xs4all.nl> <3935B383.469032AE@python.org> <20000604005601.T469@xs4all.nl> Message-ID: <14651.13270.353056.246432@localhost.localdomain> >>>>> "TW" == Thomas Wouters writes: TW> On Wed, May 31, 2000 at 11:49:57PM +0000, Guido van Rossum TW> wrote: >> I know I shouldn't be posting in this thread, and I won't be >> there to read the responses, but here's what I thought would be >> cool. >> x+=y is syntactic sugar for x=x.__add_ab__(y); the "ab" means >> "and becomes" (an old Algol-68 naming convention; we could pick >> something better later but this will do for the explanation). [...] TW> This was what I had in mind, and was trying to explain. Does you TW> voicing your opinion mean someone (you ? someone else ?) is TW> working on this, or soon going to work on this ? I don't believe anyone at PythonLabs is working on this now, certainly not Guido or I. Jeremy From jeremy@beopen.com Mon Jun 5 05:53:32 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Mon, 5 Jun 2000 00:53:32 -0400 (EDT) Subject: [Python-Dev] Revised 1.6 jobs list In-Reply-To: References: Message-ID: <14651.12876.575925.701737@localhost.localdomain> >>>>> "GS" == Greg Stein writes: GS> On Sat, 3 Jun 2000, Jeremy Hylton wrote: >> ... Sorry for the excuses. I think better tools would help a >> lot, but we'll have to get more people checkin privileges >> regardless. GS> There are several issues with expanded checkin privs: GS> 1) trust: will the person make sure it is Right And Proper to do GS> the checkin? (have they reviewed the code? is a a Good Change? GS> etc) The counter here is that we don't want people that will GS> simply take stuff arriving at patches@ and checking them in. Many of the people who ultimately have checkin privileges should limit themselves to their particular domains. There are a bunch of modules that are owned by other people, e.g. Eric's netrc module, your new httplib, MAL for Unicode, etc. We'll probably develop a second group of developers who have broader privileges to make changes, but they'll know how they are. Ultimately, I think I agree with Mark's suggestion that we be a little more liberal with changes and risk backing out the occasional changes. (For some definition of "a little more" :-). GS> 2) more people reviewing changes on the -checkins mailing GS> list. Assuming that you want more than one pair of eyeballs GS> looking at patches/code, that more people with commit privs GS> increases the rate of commits, then you need more reviewers to GS> keep up (because the reviewers probably are not going to review GS> ALL checkins) You're doing a great job so far. We'll just have to get you to spend more time on it <0.8 wink>. GS> 3) increasing dependence on -checkins means that patches MUST be GS> smaller chunks. they MUST be single-purpose patches. practically GS> nobody will review a 200k patch, or patches that fix N different GS> things at once. A small, focused patch is easily reviewed. GS> For example: Trent has recently mailed a bunch of patches to GS> the patches list. This is Goodness: each one is focused and can GS> be individually reviewed. Since they are not a single, giant GS> blob, it also keeps them short and reviewable... each can have a GS> +1/-1 independent of the others. I agree in principle, but there are times when it will make more sense to commit a set of changes as one big patch. The GC patches are going to affect a bunch of files, but probably ought to be done as one big commit. Jeremy From jeremy@beopen.com Mon Jun 5 06:03:46 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Mon, 5 Jun 2000 01:03:46 -0400 (EDT) Subject: [Python-Dev] release forms? (was: [Patches] New sys method to return total reference count in debug builds.) In-Reply-To: References: Message-ID: <14651.13490.858960.390030@localhost.localdomain> Off the top of my head, I'd say that your questions aren't going to get answered until Guido gets back and gets a chance to answer them. In the interim, I think we should stick with the current approach. In the long run, of course, you won't need to grant CNRI permission to do anything with a submission. Jeremy From nascheme@enme.ucalgary.ca Mon Jun 5 07:35:00 2000 From: nascheme@enme.ucalgary.ca (Neil Schemenauer) Date: Mon, 5 Jun 2000 00:35:00 -0600 Subject: [Python-Dev] Revised 1.6 jobs list In-Reply-To: <14651.12289.191631.704477@localhost.localdomain>; from jeremy@beopen.com on Mon, Jun 05, 2000 at 12:43:45AM -0400 References: <20000602232521.B986@newcnri.cnri.reston.va.us> <3938D60E.391AAF31@lemburg.com> <14651.12289.191631.704477@localhost.localdomain> Message-ID: <20000605003500.B6169@acs.ucalgary.ca> On Mon, Jun 05, 2000 at 12:43:45AM -0400, Jeremy Hylton wrote: > [Entry from AMK's 1.6 jobs list:] > > Conservative garbage collection of cycles (maybe -- I don't know what GvR > > thinks about this) > > I believe Guido would like to see a version of Neil's patches > integrated into Python 1.6, most likely turned off by default but with > a configure flag to enable. Okay, I was thinking he had passed it over for 1.6 since I didn't hear any comments from him for a long time. > I would like to check the patch in soon but I have had some trouble > with segfaults. I ran a simple benchmark using the compiler code in > the nondist tree to compile itself. I get a crash during a routine > collect pass, where it looks like the GC header info is getting > trashed. I haven't had much time to track it any farther. Yow. I will try to see if I can reproduce this. What platform? > If anyone else is interested, I'd love to hear about successes using > the GC patch with other large programs. I'd like to run at least > Gadfly and Grail successfully before committing the patch. I've used it with Grail, Sketch, IDLE as well as some of my own software. I may have introduced that SEGV bug when porting the patch to a newer version of the CVS sources. I will check it out. > I also worry that the performance impact of the GC patch is not > at all understood. Me too. > I don't know what informed the choice of heuristics for > deciding how often to collect and how to move objects between > generations. (The current scheme has three generations.) It > would be good to get a working patch in before the next alpha > release and then gather a lot of data to help make good choices > about these parameters. Getting good performance will be a matter of tuning how often the collector runs. I don't think there is any substitute for running real programs and collecting data. Programs that allocate lots of objects will be most interesting. It would probably be a good idea to add more support for keeping collection statistics. Unfortunately my time is very limited right now. > PS Even if Guido doesn't think the GC patch should go in, we've got a > golden opportunity. I caught him in a state of newly-wedded bliss > this morning and convinced him to let me check in my non-optional > braces patch while he's on his honeymoon. He's so happy he'll let us > get away with anything. I wonder if he will be scowling less at the conferences now that he is hitched. :) Neil From gstein@lyra.org Mon Jun 5 07:42:35 2000 From: gstein@lyra.org (Greg Stein) Date: Sun, 4 Jun 2000 23:42:35 -0700 (PDT) Subject: [Python-Dev] Revised 1.6 jobs list In-Reply-To: <14651.12876.575925.701737@localhost.localdomain> Message-ID: On Mon, 5 Jun 2000, Jeremy Hylton wrote: > >>>>> "GS" == Greg Stein writes: >... > GS> 1) trust: will the person make sure it is Right And Proper to do > GS> the checkin? (have they reviewed the code? is a a Good Change? > GS> etc) The counter here is that we don't want people that will > GS> simply take stuff arriving at patches@ and checking them in. > > Many of the people who ultimately have checkin privileges should limit > themselves to their particular domains. There are a bunch of modules > that are owned by other people, e.g. Eric's netrc module, your new > httplib, MAL for Unicode, etc. Agreed. Each person with commit privs will definitely need to operate under the premise of " is the area that I'm allowed to commit changes for." For example, I believe that Guido made it very clear, at some point in the past, that *nobody* but Guido will have commit access to the Parser/ area. Note that when I say "commit access" here, this is the same as "areas that I can commit for." In fact, it is really just an extension of the Basic Python Principle, "we're all adults here, don't do what you know you shouldn't be doing." :-) >... > Ultimately, I think I agree with Mark's suggestion that we be a little > more liberal with changes and risk backing out the occasional > changes. (For some definition of "a little more" :-). This only works if you have reasonably assurance of review via the -checkins alias. Otherwise, you simply need to accept that instabilities will creep in. (and that broader alpha/beta/etc cycles may be desirable) In the Apache group, we have a very good set of eyeballs watching the checkins. I'd say that each checkin is reviewed by two or three people in detail. Invariably, there are several checkins each week that result in a thread discussing: (a) you broke it, (b) why was it done that way, (c) couldn't it be done this way, (d) this appears to be missing, (e) etc. IMO, for that to happen several (or more!) times every week means that we have a good set of eyeballs. Maybe it also means the committers just suck lollipops, but I'd like to think otherwise :-) > GS> 2) more people reviewing changes on the -checkins mailing > GS> list. Assuming that you want more than one pair of eyeballs > GS> looking at patches/code, that more people with commit privs > GS> increases the rate of commits, then you need more reviewers to > GS> keep up (because the reviewers probably are not going to review > GS> ALL checkins) > > You're doing a great job so far. We'll just have to get you to spend > more time on it <0.8 wink>. hehe... well, I just completed a big-ass wave of mod_dav work. In fact, I don't know what else to do to the thing. I made a snapshot and am waiting for feedback, if any, before declaring it 1.0. Maybe I'll add some comments to the code :-) Anyways... that's why I've been working on httplib. Free time! :-) > GS> 3) increasing dependence on -checkins means that patches MUST be > GS> smaller chunks. they MUST be single-purpose patches. practically > GS> nobody will review a 200k patch, or patches that fix N different > GS> things at once. A small, focused patch is easily reviewed. > > GS> For example: Trent has recently mailed a bunch of patches to > GS> the patches list. This is Goodness: each one is focused and can > GS> be individually reviewed. Since they are not a single, giant > GS> blob, it also keeps them short and reviewable... each can have a > GS> +1/-1 independent of the others. > > I agree in principle, but there are times when it will make more sense > to commit a set of changes as one big patch. The GC patches are going > to affect a bunch of files, but probably ought to be done as one big > commit. Actually, I will disagree here. I've reviewed the GC patch a couple times. There are a number of changes in there that can/should be done separately from the "real" GC patch. For example, there were a number of changes to use PyMem_Allco() instead of PyMEM_Alloc(). Or whatever. Point being, that they had *nothing* to do with GC -- they could be checked in *independent* of the actual GC work. The changes to the PyTypeObject declaration (adding tp_clean) can also be done without doing the "real work". After these "zero impact" changes are completed, then the GC patch will be greatly reduced in size and complexity. It makes it much more reviewable. The point being: even big patches can usually be broken down into layers. One layer after another, adding "platform" functionality until you get to the meat of the matter. The GC patch was a definite case of this. Really huge patches are okay if they have a *seriously* narrow focus. For example, Skip's patch to use PyArg_ParseTuple() with the ":method" stuff. That was pretty brain-dead to review. The hardest part was that the context-diff wasn't contextual enough to verify that the name in the ParseTuple matched the method that it occurred in. [ I found a case where they did not match. not easy... ] Cheers, -g -- Greg Stein, http://www.lyra.org/ From pf@artcom-gmbh.de Mon Jun 5 08:28:38 2000 From: pf@artcom-gmbh.de (Peter Funk) Date: Mon, 5 Jun 2000 09:28:38 +0200 (MEST) Subject: [Python-Dev] Suggestion: stopping to trust os mtimes In-Reply-To: from Greg Stein at "Jun 2, 2000 2:32:52 pm" Message-ID: Hi, Greg Stein: > He does have a point, but I think the wrong solution :-) > > While the clock may be monotonically increasing on one system, it isn't > always the case when things like NFS come into play. That is a well known and common trap. Don't use NFS for Software development unless you've read and understood RFC 868. ;-) BTW.: Last year someone posted a pure Python implementation of RFC 868 time server and clients to c.l.p. This might be useful on those WinXX boxes. > I recall a case back '95 when I was editing a .py over an NFS mount and > running the code on the target machine. The clocks on the two boxes were > off by about three seconds. I was going thru the edit/run/edit/run cycle > so quickly, that at one point, I saved a .py file that was older than the > associated .pyc file. > > Needless to say, I was really confused that my recent edit didn't produce > the desired result :-) Sure. ;-) But the same would have happenend, if you edited a .c source file and if your target computer has C-compiler/linker, which is fast enough to have a edit/compile/run cycle completed faster than the clock difference. This is not uncommon today. So the problem is not Python's fault and so I see no need to fix it there. One thing could be added though: If Python 'stat's a .py file, which has a time stamp in the future, it could issue a warning similar to that displayed by 'make': *** Warning: File `%s' has modification time in the future (%ld > %ld Possibly this message could point the user to RFC 868 and the 'netdate' Unix command. But that would be sugar on the cake. Regards, Peter From Moshe Zadka Mon Jun 5 11:21:32 2000 From: Moshe Zadka (Moshe Zadka) Date: Mon, 5 Jun 2000 13:21:32 +0300 (IDT) Subject: [Python-Dev] Suggestion: stopping to trust os mtimes In-Reply-To: Message-ID: On Mon, 5 Jun 2000, Peter Funk wrote: > Greg Stein: > > He does have a point, but I think the wrong solution :-) > > > > While the clock may be monotonically increasing on one system, it isn't > > always the case when things like NFS come into play. > > That is a well known and common trap. Don't use NFS for Software > development unless you've read and understood RFC 868. ;-) "Make"'s philosphy for basing the decision on which files need to be remade on the timestapmps is not necessarily the best -- but the user can replace mkae if it doesn't "do the right thing". Since Python takes on some of Make's roles (regenrating files only if those need to be regenerated), it is subject to the same problems. So it is Python's fault, and that's where the problem should be fixed. -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com From bwarsaw@python.org Mon Jun 5 14:21:05 2000 From: bwarsaw@python.org (bwarsaw@python.org) Date: Mon, 5 Jun 2000 09:21:05 -0400 (EDT) Subject: [Python-Dev] Revised 1.6 jobs list References: <14651.6640.709657.306682@anthem.python.org> Message-ID: <14651.43329.783797.949349@anthem.python.org> >>>>> "GS" == Greg Stein writes: GS> IMO, use the provided tools. The Patch Manager is more than we GS> have now. It also allows assignment, which can be nice :-) GS> (compared to the arbitrary "who is taking care of this patch?" GS> thing today) GS> The SF bug database certainly works, and it provides GS> additional "locality" for the code + bugs + patches. I've turned on the SF patch manager and bug database. -Barry From bwarsaw@python.org Mon Jun 5 14:32:54 2000 From: bwarsaw@python.org (Barry A. Warsaw) Date: Mon, 5 Jun 2000 09:32:54 -0400 (EDT) Subject: [Python-Dev] Revised 1.6 jobs list References: <14651.12876.575925.701737@localhost.localdomain> Message-ID: <14651.44038.828370.123514@anthem.python.org> >>>>> "JH" == Jeremy Hylton writes: JH> Many of the people who ultimately have checkin privileges JH> should limit themselves to their particular domains. There JH> are a bunch of modules that are owned by other people, JH> e.g. Eric's netrc module, your new httplib, MAL for Unicode, JH> etc. Right. I think GregS was the one advocating a more Apache-like model, where people have the ability to check into the whole tree, but generally don't or risk the derision of their peers. Python's big enough for people to assert their expertise over various corners. JH> Ultimately, I think I agree with Mark's suggestion that we be JH> a little more liberal with changes and risk backing out the JH> occasional changes. (For some definition of "a little more" JH> :-). It all depends on the scope of the changes. If it's fairly localized to a single library module, then we don't worry as much. More important there will be the API design. If it's a more sweeping change like GC or Unicode, or a change in the language definition, then there /has/ to be broader support. For Big Changes, I really like the RFC idea someone suggested. Gets everything documented for newbies and posterity. Has a shelf life, etc. -Barry From bwarsaw@python.org Mon Jun 5 14:36:28 2000 From: bwarsaw@python.org (Barry A. Warsaw) Date: Mon, 5 Jun 2000 09:36:28 -0400 (EDT) Subject: [Python-Dev] Revised 1.6 jobs list References: <14651.12876.575925.701737@localhost.localdomain> Message-ID: <14651.44252.78362.195436@anthem.python.org> >>>>> "GS" == Greg Stein writes: GS> In the Apache group, we have a very good set of eyeballs GS> watching the checkins. I'd say that each checkin is reviewed GS> by two or three people in detail. Invariably, there are GS> several checkins each week that result in a thread discussing: GS> (a) you broke it, (b) why was it done that way, (c) couldn't GS> it be done this way, (d) this appears to be missing, (e) etc. Maybe we also need to expand on the test suite, do nightly builds, and post the results. Kind of the way Mozilla does it. Well, Python probably doesn't change so radically every night, but a more expanded test suite with web based feedback would be cool. -Barry From bwarsaw@python.org Mon Jun 5 14:38:20 2000 From: bwarsaw@python.org (Barry A. Warsaw) Date: Mon, 5 Jun 2000 09:38:20 -0400 (EDT) Subject: [Python-Dev] Re: Is it just Syntactic Sugar ? References: <3929E47E.993727CF@roguewave.com> <3933F800.9CCE3B6D@cs.byu.edu> <20000530213957.E469@xs4all.nl> <20000531090045.I469@xs4all.nl> <3935B383.469032AE@python.org> <20000604005601.T469@xs4all.nl> <14651.13270.353056.246432@localhost.localdomain> Message-ID: <14651.44364.408119.422821@anthem.python.org> >>>>> "JH" == Jeremy Hylton writes: >>>>> "TW" == Thomas Wouters writes: TW> This was what I had in mind, and was trying to explain. Does TW> you voicing your opinion mean someone (you ? someone else ?) TW> is working on this, or soon going to work on this ? JH> I don't believe anyone at PythonLabs is working on this now, JH> certainly not Guido or I. I'm not tracking this either. -Barry From bwarsaw@python.org Mon Jun 5 14:41:39 2000 From: bwarsaw@python.org (Barry A. Warsaw) Date: Mon, 5 Jun 2000 09:41:39 -0400 (EDT) Subject: [Python-Dev] release forms? (was: [Patches] New sys method to return total reference count in debug builds.) References: Message-ID: <14651.44563.556790.469651@anthem.python.org> >>>>> "GS" == Greg Stein writes: GS> Given the New World Order, how does that impact the need for GS> these release statements and/or wet signatures? GS> Or a better way to put it, who "owns" Python now? Given a GS> "who", then we can ask that person/entity whether they want GS> release statements. GS> Given that Python is now on SourceForge, and there are GS> multiple people (at CNRI and otherwise) that can directly make GS> modifications, then the release below is certainly a bit GS> "off". For example, David Ascher has commit privs, so at his GS> "sole discretion, [he may] decide whether or not to GS> incorporiate this contribution..." :-) I talked to Guido briefly about this. Since 1.6 is the last "CNRI release", he wants to continue along the current path for the time being. I'm sure he'll be just as happy to chuck all this crap as Greg, and we probably will for 1.7. -Barry From fdrake@beopen.com Mon Jun 5 17:40:26 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Mon, 5 Jun 2000 12:40:26 -0400 (EDT) Subject: [Python-Dev] Revised 1.6 jobs list In-Reply-To: <14648.35974.486959.379543@anthem.python.org> References: <20000602232521.B986@newcnri.cnri.reston.va.us> <14648.35974.486959.379543@anthem.python.org> Message-ID: <14651.55290.728256.183107@cj42289-a.reston1.va.home.com> Barry A. Warsaw writes: > Did we ever decide on building in thread support by default? I'd > really like to see threads enabled by default in 1.6 and I /think/ > it'll just take some autoconf hacking, which I'm willing to do. Are > there any objections to building in threads support by default if > autoconf detects threads? test_fork1 fails on Linux with threads on SMP machines. (It's irrelevant without threads.) This is a hard failure -- the process can either SEGV or hang forever. Is this a showstopper? SMP boxes are becoming increasingly common both as servers and workstations. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From bwarsaw@python.org Mon Jun 5 17:55:49 2000 From: bwarsaw@python.org (bwarsaw@python.org) Date: Mon, 5 Jun 2000 12:55:49 -0400 (EDT) Subject: [Python-Dev] Revised 1.6 jobs list References: <20000602232521.B986@newcnri.cnri.reston.va.us> <14648.35974.486959.379543@anthem.python.org> <14651.55290.728256.183107@cj42289-a.reston1.va.home.com> Message-ID: <14651.56213.661929.481476@anthem.python.org> >>>>> "Fred" == Fred L Drake, Jr writes: Fred> test_fork1 fails on Linux with threads on SMP machines. Fred> (It's irrelevant without threads.) This is a hard failure Fred> -- the process can either SEGV or hang forever. Is this a Fred> showstopper? I would think so, regardless of whether threads are built-in by default or not. From fdrake@beopen.com Mon Jun 5 18:59:31 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Mon, 5 Jun 2000 13:59:31 -0400 (EDT) Subject: [Python-Dev] What's New (first draft) In-Reply-To: References: <20000602231550.A986@newcnri.cnri.reston.va.us> Message-ID: <14651.60035.502321.510452@cj42289-a.reston1.va.home.com> Mark Hammond writes: > Bill Tutt and I could do with a credit for the new winreg module. The documentation for winreg could stand to be written as well -- care to extract the docstrings, or is that in my court? ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From DavidA@ActiveState.com Mon Jun 5 20:26:13 2000 From: DavidA@ActiveState.com (David Ascher) Date: Mon, 5 Jun 2000 12:26:13 -0700 Subject: [Python-Dev] Revised 1.6 jobs list In-Reply-To: <14651.55290.728256.183107@cj42289-a.reston1.va.home.com> Message-ID: > test_fork1 fails on Linux with threads on SMP machines. (It's > irrelevant without threads.) This is a hard failure -- the process > can either SEGV or hang forever. > Is this a showstopper? SMP boxes are becoming increasingly common > both as servers and workstations. Why does the test fail? I'd hate to see the thousands (nay, hundreds of thousands) of users complain that foo isn't working just because the test for a rarely used feature on a rare platform is broken. --david From nascheme@enme.ucalgary.ca Mon Jun 5 22:03:13 2000 From: nascheme@enme.ucalgary.ca (Neil Schemenauer) Date: Mon, 5 Jun 2000 15:03:13 -0600 Subject: [Python-Dev] Re: Revised 1.6 jobs list Message-ID: <20000605150313.A15917@acs.ucalgary.ca> [David Ascher] >> test_fork1 fails on Linux with threads on SMP machines. (It's >> irrelevant without threads.) This is a hard failure -- the >> process can either SEGV or hang forever. Is this a showstopper? >> SMP boxes are becoming increasingly common both as servers and >> workstations. > > Why does the test fail? I'd hate to see the thousands (nay, > hundreds of thousands) of users complain that foo isn't working > just because the test for a rarely used feature on a rare > platform is broken. Threads and fork() don't seem to mix on Linux. Even on a UP machine things seem strange: http://www.deja.com/[ST_rn=ps]/getdoc.xp?AN=613477888&fmt=text I tried to reproduce the problem with a C program but could not. When things hang the forking thread is stuck in wait4() while the child process is suspended: #0 0x4027d9ba in sigsuspend () from /lib/libc.so.6 #1 0x40232c77 in __pthread_wait_for_restart_signal () from /lib/libpthread.so.0 #2 0x4023406e in __pthread_lock () from /lib/libpthread.so.0 #3 0x4023186a in pthread_mutex_lock () from /lib/libpthread.so.0 #4 0x806fbaa in PyThread_release_lock (lock=0x81ebb68) at thread_pthread.h:339 #5 0x805617b in eval_code2 (co=0x81eca68, globals=0x81c4f64, locals=0x0, args=0x81be278, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, owner=0x0) at ceval.c:630 #6 0x805ac19 in call_function (func=0x81ebb2c, arg=0x81be26c, kw=0x0) at ceval.c:2552 #7 0x805a5a4 in PyEval_CallObjectWithKeywords (func=0x81ebb2c, arg=0x81be26c, kw=0x0) at ceval.c:2390 #8 0x80b2c7b in t_bootstrap (boot_raw=0x81ebb50) at ./threadmodule.c:224 #9 0x40230c8f in pthread_start_thread () from /lib/libpthread.so.0 I don't know if this is a LinuxThread problem or a Python problem. Neil -- The internet: Learn what you know. Share what you don't. From DavidA@ActiveState.com Mon Jun 5 22:23:11 2000 From: DavidA@ActiveState.com (David Ascher) Date: Mon, 5 Jun 2000 14:23:11 -0700 Subject: [Python-Dev] RE: Revised 1.6 jobs list In-Reply-To: <20000605150313.A15917@acs.ucalgary.ca> Message-ID: > Threads and fork() don't seem to mix on Linux. Even on a > UP machine things seem strange: I believe it. My general point however is that even if the problem can't be fixed because Linux is broken in some way, the test suite should be fixed even if it means to ignore failures of test_fork1 if the system was configured --with-thread. --david From mhammond@skippinet.com.au Tue Jun 6 00:47:44 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Tue, 6 Jun 2000 09:47:44 +1000 Subject: [Python-Dev] Re: Revised 1.6 jobs list In-Reply-To: <20000605150313.A15917@acs.ucalgary.ca> Message-ID: > I tried to reproduce the problem with a C program but could not. > When things hang the forking thread is stuck in wait4() while the > child process is suspended: This looks very suspect. > > #0 0x4027d9ba in sigsuspend () from /lib/libc.so.6 > #1 0x40232c77 in __pthread_wait_for_restart_signal () > from /lib/libpthread.so.0 > #2 0x4023406e in __pthread_lock () from /lib/libpthread.so.0 > #3 0x4023186a in pthread_mutex_lock () from /lib/libpthread.so.0 > #4 0x806fbaa in PyThread_release_lock (lock=0x81ebb68) at > thread_pthread.h:339 > #5 0x805617b in eval_code2 (co=0x81eca68, globals=0x81c4f64, And very much like the Python thread-state is not being managed correctly with fork. From my understanding of fork (which is small), and of the Python thread-state management, this doesnt surprise me. Given the stack trace, it appears that Python is doing its periodic thread-release as part of running around the main loop. In the process of _releasing_ the thread-lock, it needs to _acquire_ a mutex. I dont know the Python threading on pthreads at all - would this be correct (it would seem likely that such an implementation would be done). But in the process of acquiring that mutex, we call __pthread_wait_for_restart_signal() Is it possible that is is something as simple as thread-idents changing underneath Python when using fork? It seems to me that the thread thinks it is either new, or stale? Just my 2c worth - and given my knowledge of Linux and pthreads, plus the state of our dollar at the moment, it has better be AUD $0.02 :-) Mark. From trentm@activestate.com Tue Jun 6 01:14:03 2000 From: trentm@activestate.com (Trent Mick) Date: Mon, 5 Jun 2000 17:14:03 -0700 Subject: [Python-Dev] PyMarshal_WriteLongToFile: writes 'long' or 32-bit integer? In-Reply-To: References: <20000602111417.A17233@activestate.com> Message-ID: <20000605171403.A21808@activestate.com> On Sat, Jun 03, 2000 at 10:56:15AM +0300, Moshe Zadka wrote: > On Fri, 2 Jun 2000, Trent Mick wrote: > > > 3. - change PyMarshal_WriteLongToFile to raise an exception if the long > > overflows a 32-bit range > > +1 on that, finally non-portable integers will cause an exception. > Okay, I have to reiterate and ask again because I have the suspicion that I may be missing the point and you all may not realize that. Stop me when I go astray: - the PyMarshal interface is used for all the .pyc content writing - PyMarshal_WriteLongToFile is only used for writing the magic number and the time stamp - the rest of the .pyc is written via PyMarshal_WriteObjectToFile - PyMarshal_WriteLongToFile will currently silently truncate a 64-bit long to 32-bits - PyMarshal_WriteObjectToFile, when writing a PyInt and hence a C long, will *NOT* truncate the 64-bit integer but will write the whole thing - On reading a .pyc the PyMarshal_ReadObjectFromFile will complain on stderr when a 64-bit integral value is read and the current platform is 32-bit. The question is: Do we want PyMarshal_WriteLongToFile *AND* PyMarshal_WriteObjectToFile to raise an exception when a long value overflows 32-bits? Up til now I was only proposing the former. Trent -- Trent Mick trentm@activestate.com From esr@thyrsus.com Tue Jun 6 02:02:31 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Mon, 5 Jun 2000 21:02:31 -0400 Subject: [Python-Dev] ascii.py Message-ID: <20000605210231.A25895@thyrsus.com> --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Latest version. Adds isctrl() and ismeta() functions (because I use them...) Um. What's the checkin procedure for library modules? And do I have permissions to do it? -- Eric S. Raymond "Guard with jealous attention the public liberty. Suspect every one who approaches that jewel. Unfortunately, nothing will preserve it but downright force. Whenever you give up that force, you are inevitably ruined." -- Patrick Henry, speech of June 5 1788 --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ascii.py" # # ascii.py -- constants and memembership tests for ASCII characters # NUL = 0x00 # ^@ SOH = 0x01 # ^A STX = 0x02 # ^B ETX = 0x03 # ^C EOT = 0x04 # ^D ENQ = 0x05 # ^E ACK = 0x06 # ^F BEL = 0x07 # ^G BS = 0x08 # ^H TAB = 0x09 # ^I HT = 0x09 # ^I LF = 0x0a # ^J NL = 0x0a # ^J VT = 0x0b # ^K FF = 0x0c # ^L CR = 0x0d # ^M SO = 0x0e # ^N SI = 0x0f # ^O DLE = 0x10 # ^P DC1 = 0x11 # ^Q DC2 = 0x12 # ^R DC3 = 0x13 # ^S DC4 = 0x14 # ^T NAK = 0x15 # ^U SYN = 0x16 # ^V ETB = 0x17 # ^W CAN = 0x18 # ^X EM = 0x19 # ^Y SUB = 0x1a # ^Z ESC = 0x1b # ^[ FS = 0x1c # ^\ GS = 0x1d # ^] RS = 0x1e # ^^ US = 0x1f # ^_ SP = 0x20 # space DEL = 0x7f # delete controlnames = [ "NUL", "SOH", "STX", "ETX", "EOT", "ENQ", "ACK", "BEL", "BS", "HT", "LF", "VT", "FF", "CR", "SO", "SI", "DLE", "DC1", "DC2", "DC3", "DC4", "NAK", "SYN", "ETB", "CAN", "EM", "SUB", "ESC", "FS", "GS", "RS", "US", "SP" ] def _ctoi(c): if type(c) == type(""): return ord(c) else: return c def isalnum(c): return isalpha(c) or isdigit(c) def isalpha(c): return isupper(c) or islower(c) def isascii(c): return _ctoi(c) <= 127 # ? def isblank(c): return _ctoi(c) in (8,32) def iscntrl(c): return _ctoi(c) <= 31 def isdigit(c): return _ctoi(c) >= 48 and _ctoi(c) <= 57 def isgraph(c): return _ctoi(c) >= 33 and _ctoi(c) <= 126 def islower(c): return _ctoi(c) >= 97 and _ctoi(c) <= 122 def isprint(c): return _ctoi(c) >= 32 and _ctoi(c) <= 126 def ispunct(c): return _ctoi(c) != 32 and not isalnum(c) def isspace(c): return _ctoi(c) in (12, 10, 13, 9, 11) def isupper(c): return _ctoi(c) >= 65 and _ctoi(c) <= 90 def isxdigit(c): return isdigit(c) or \ (_ctoi(c) >= 65 and _ctoi(c) <= 70) or (_ctoi(c) >= 97 and _ctoi(c) <= 102) def isctrl(c): return _ctoi(c) < 32 def ismeta(c): return _ctoi(c) > 127 def ascii(c): if type(c) == type(""): return chr(_ctoi(c) & 0x7f) else: return _ctoi(c) & 0x7f def ctrl(c): if type(c) == type(""): return chr(_ctoi(c) & 0x1f) else: return _ctoi(c) & 0x1f def alt(c): if type(c) == type(""): return chr(_ctoi(c) | 0x80) else: return _ctoi(c) | 0x80 def unctrl(c): bits = _ctoi(c) if bits == 0x7f: rep = "^?" elif bits & 0x20: rep = chr((bits & 0x7f) | 0x20) else: rep = "^" + chr(((bits & 0x7f) | 0x20) + 0x20) if bits & 0x80: return "!" + rep return rep --82I3+IH0IqGh5yIs Content-Type: application/x-tex Content-Disposition: attachment; filename="libascii.tex" \section{\module{ascii} --- Constants and set-membership functions for ASCII characters.} \declaremodule{standard}{ascii} \modulesynopsis{Constants and set-membership functions for ASCII characters.} \moduleauthor{Eric S. Raymond}{esr@thyrsus.com} \sectionauthor{Eric S. Raymond}{esr@thyrsus.com} \versionadded{1.6} The \module{ascii} module supplies name constants for ASCII characters and functions to test membership in various ASCII character classes. The constants supplied are names for control characters as follows: NUL, SOH, STX, ETX, EOT, ENQ, ACK, BEL, BS, TAB, HT, LF, NL, VT, FF, CR, SO, SI, DLE, DC1, DC2, DC3, DC4, NAK, SYN, ETB, CAN, EM, SUB, ESC, FS, GS, RS, US, SP, DEL. NL and LF are synonyms; so are HT and TAB. The module also supplies the following functions, patterned on those in the standard C library: \begin{funcdesc}{isalnum}{c} Checks for an ASCII alphanumeric character; it is equivalent to isalpha(c) or isdigit(c)) \end{funcdesc} \begin{funcdesc}{isalpha}{c} Checks for an ASCII alphabetic character; it is equivalent to isupper(c) or islower(c)) \end{funcdesc} \begin{funcdesc}{isascii}{c} Checks for a character value that fits in the 7-bit ASCII set. \end{funcdesc} \begin{funcdesc}{isblank}{c} Checks for an ASCII alphanumeric character; it is equivalent to isalpha(c) or isdigit(c)) \end{funcdesc} \begin{funcdesc}{iscntrl}{c} Checks for an ASCII control character (range 0x00 to 0x1f). \end{funcdesc} \begin{funcdesc}{isdigit}{c} Checks for an ASCII decimal digit, 0 through 9. \end{funcdesc} \begin{funcdesc}{isgraph}{c} Checks for ASCII any printable character except space. \end{funcdesc} \begin{funcdesc}{islower}{c} Checks for an ASCII lower-case character. \end{funcdesc} \begin{funcdesc}{isprint}{c} Checks for any ASCII printable character including space. \end{funcdesc} \begin{funcdesc}{ispunct}{c} Checks for any printable ASCII character which is not a space or an alphanumeric character. \end{funcdesc} \begin{funcdesc}{isspace}{c} Checks for ASCII white-space characters; space, tab, line feed, carriage return, form feed, horizontal tab, vertical tab. \end{funcdesc} \begin{funcdesc}{isupper}{c} Checks for an ASCII uppercase letter. \end{funcdesc} \begin{funcdesc}{isxdigit}{c} Checks for an ASCII hexadecimal digit, i.e. one of 0123456789abcdefABCDEF. \end{funcdesc} \begin{funcdesc}{isctrl}{c} Checks for an ASCII control character, bit values 0 to 31. \end{funcdesc} \begin{funcdesc}{ismeta}{c} Checks for a (non-ASCII) character, bit values 0x80 and above. \end{funcdesc} These functions accept either integers or strings; when the argument is a string, it is first converted using the built-in function ord(). Note that all these functions check ordinal bit values derived from the first character of the string you pass in; they do not actually know anything about the host machine's character encoding. For functions that know about the character encoding (and handle internationalization properly) see the string module. The following two functions take either a single-character string or integer byte value; they return a value of the same type. \begin{funcdesc}{ascii}{c} Return the ASCII value corresponding to the low 7 bits of c. \end{funcdesc} \begin{funcdesc}{ctrl}{c} Return the control character corresponding to the given character (the character bit value is logical-anded with 0x1f). \end{funcdesc} \begin{funcdesc}{alt}{c} Return the 8-bit character corresponding to the given ASCII character (the character bit value is logical-ored with 0x80). \end{funcdesc} The following function takes either a single-character string or integer byte value; it returns a string. \begin{funcdesc}{unctrl}{c} Return a string representation of the ASCII character c. If c is printable, this string is the character itself. If the character is a control character (0x00-0x1f) the string consists of a caret (^) followed by the corresponding uppercase letter. If the character is an ASCII delete (0x7f) the string is "^?". If the character has its meta bit (0x80) set, the meta bit is stripped, the preceding rules applied, and "!" prepended to the result. \end{funcdesc} Finally, the module supplies a 33-element string array called controlnames that contains the ASCII mnemonics for the thirty-two ASCII control characters from 0 (NUL) to 0x1f (US), in order, plus the mnemonic "SP" for space. --82I3+IH0IqGh5yIs-- From gstein@lyra.org Tue Jun 6 02:10:17 2000 From: gstein@lyra.org (Greg Stein) Date: Mon, 5 Jun 2000 18:10:17 -0700 (PDT) Subject: [Python-Dev] ascii.py In-Reply-To: <20000605210231.A25895@thyrsus.com> Message-ID: On Mon, 5 Jun 2000, Eric S. Raymond wrote: > Latest version. Adds isctrl() and ismeta() functions (because I use them...) > > Um. What's the checkin procedure for library modules? Guido has to give his blessing -- that he finds this useful and appropriate for the Python library. He does that using his own criteria and feedback from people here. For example, I'm "+0" on it. (meaning that it seems okay, but I can also live without it) The actual mechanics are outlined at SourceForge: http://sourceforge.net/cvs/?group_id=5470 > And do I have permissions to do it? Nope. There are ten people with checkin privs: http://sourceforge.net/project/memberlist.php?group_id=5470 Five of them are admins (Barry, Fred, Guido, Jeremy, Tim). They use policy to determine whether a given person should become a SF project member. That policy is probably just a gut feeling rather than concrete rules, so I can't say "X, Y, and Z." I also don't know what kinds of policies that they are asserting on people with privs. Cheers, -g -- Greg Stein, http://www.lyra.org/ From jeremy@beopen.com Tue Jun 6 02:23:40 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Mon, 5 Jun 2000 21:23:40 -0400 (EDT) Subject: [Python-Dev] ascii.py In-Reply-To: References: <20000605210231.A25895@thyrsus.com> Message-ID: <14652.21148.139774.192634@localhost.localdomain> Greg seems to understand this process better than the admins -- or at least he can explain it quickly and clearly :-). I apologize for the rather confused state of affairs. We'll clean up the process and document it soon. >>>>> "GS" == Greg Stein writes: GS> On Mon, 5 Jun 2000, Eric S. Raymond wrote: >> Latest version. Adds isctrl() and ismeta() functions (because I >> use them...) >> >> Um. What's the checkin procedure for library modules? GS> Guido has to give his blessing -- that he finds this useful and GS> appropriate for the Python library. He does that using his own GS> criteria and feedback from people here. I think I can safely speak for the admins when I say that we're not sure what the process is other than securing Guido's blessing. We need to work out a clearer policy, but that will have to wait until Guido gets back from his honeymoon. Any new checkins we are making are limited for the most part to modules we've already gotten his blessing for. There won't be another alpha release until he returns, so it's not like we have to worry about getting new code in before a code freeze. GS> For example, I'm "+0" on it. (meaning that it seems okay, but I GS> can also live without it) I'm in the same boat. GS> There are ten people with checkin privs: GS> http://sourceforge.net/project/memberlist.php?group_id=5470 GS> Five of them are admins (Barry, Fred, Guido, Jeremy, Tim). They GS> use policy to determine whether a given person should GS> become a SF project member. That policy is probably just a gut GS> feeling rather than concrete rules, so I can't say "X, Y, and GS> Z." I also don't know what kinds of policies that they are GS> asserting on people with privs. Another policy that needs to be defined. "" is surprisingly close to what we actually have written down in our policies and procedures manual. I expect we will arrive at a policy where people own pieces of the library and are free to maintain it. Guido will probably retain control over what modules come and go. -- Jeremy Hylton From esr@thyrsus.com Tue Jun 6 02:33:24 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Mon, 5 Jun 2000 21:33:24 -0400 Subject: [Python-Dev] ascii.py In-Reply-To: <14652.21148.139774.192634@localhost.localdomain>; from jeremy@beopen.com on Mon, Jun 05, 2000 at 09:23:40PM -0400 References: <20000605210231.A25895@thyrsus.com> <14652.21148.139774.192634@localhost.localdomain> Message-ID: <20000605213324.A26055@thyrsus.com> Jeremy Hylton : > Another policy that needs to be defined. "" is surprisingly > close to what we actually have written down in our policies and > procedures manual. I expect we will arrive at a policy where people > own pieces of the library and are free to maintain it. Guido will > probably retain control over what modules come and go. Pretty much as I expected. OK. Let us know when things settle out a little. -- Eric S. Raymond Before a standing army can rule, the people must be disarmed, as they are in almost every kingdom in Europe. The supreme power in America cannot enforce unjust laws by the sword, because the people are armed, and constitute a force superior to any band of regular troops. -- Noah Webster From tim_one@email.msn.com Tue Jun 6 03:09:22 2000 From: tim_one@email.msn.com (Tim Peters) Date: Mon, 5 Jun 2000 22:09:22 -0400 Subject: Augmented assignment (was RE: [Python-Dev] Re: Is it just Syntactic Sugar ?) In-Reply-To: <20000604005601.T469@xs4all.nl> Message-ID: <001601bfcf5c$3bcb8e00$0ca0143f@tim> [posted & mailed] [Thomas Wouters, asking about Guido's sketch] > This was what I had in mind, and was trying to explain. Does you > voicing your opinion mean someone (you ? someone else ?) is working > on this, or soon going to work on this ? It's the same scheme he sketched the last time he was provoked into writing about this , and that was at least a year ago. > ... > I'm curious what should happen with index-assignment and > slice-assignment: Nothing special! You're reading far too much into Guido's sketch -- it doesn't have all these convolutions. Try reading his msg again, but this time thinking like him too . > x[y] += z temp1 = x # perhaps the first three are permuted, though temp2 = y temp3 = z temp1[temp2] = temp1[temp2].__add_ab__(temp3) And, yes, indexing is done twice (although "x" and "y" are evaluated only once each). > x[:y] += z temp1 = x temp2 = y temp3 = z temp1[:temp2] = temp1[:temp2].__add_ab__(temp3) Similarly slicing is done twice. > (Obviously this wont make sense for a lot of types, or will be too > un-obvious to include, but I can imagine matrix-types to happily > add this.) Every type is free to implement __add_ab__ or not, in whatever way it likes. But Python can't tell at compile-time which types do and don't implement it, so chances are great that doing x += y for x of a type that does not implement __add_ab__ will raise a runtime AttributeError. > Would this call x.__add_item_ab__(y, z) and x.__add_slice_ab__(0, > y, z) ? No. *All* instances of "+=" are mapped straightforwardly to __add_ab__. Context is irrelevent; indexing and slicing are not special cases (except to the extent that they are already ...). > Or would x[y] += z always call x[y].__add_item_ab__() No. > and x[:y] create a new object, a slice of x What x[:y] means is entirely up to the type of x, and has no connection to augmented assignment (except in that the author of the type may design both to work smoothly together). > and call its __add_ab__() method ? __add_ab__ would be invoked on whatever x[:y] returns; whether that's "a new object" or not is x.__get_slice__'s choice to make. > Or would it try all of them, or more, until it gets a good result ? No. It works or it doesn't. > Or am I running ahead of things and should we wait for a working > patch first ? :) No, you're running a few years behind things , and imagining complications Guido would never sign up for. and-now-the-spirits-must-rest-ly y'rs - tim From bwarsaw@python.org Tue Jun 6 03:27:42 2000 From: bwarsaw@python.org (Barry A. Warsaw) Date: Mon, 5 Jun 2000 22:27:42 -0400 (EDT) Subject: [Python-Dev] ascii.py References: <20000605210231.A25895@thyrsus.com> <14652.21148.139774.192634@localhost.localdomain> Message-ID: <14652.24990.563016.976820@anthem.python.org> >>>>> "JH" == Jeremy Hylton writes: JH> I think I can safely speak for the admins when I say that JH> we're not sure what the process is other than securing Guido's JH> blessing. We need to work out a clearer policy, but that will JH> have to wait until Guido gets back from his honeymoon. Any JH> new checkins we are making are limited for the most part to JH> modules we've already gotten his blessing for. My suggestion would be to upload to the SourceForge patch manager, any patches or code you care about that you don't want us to lose track of. Things get buried in my inbox pretty easily, but at least with the patch manager, we've got a record of it, and can eventually assign a developer to tracking it. -Barry From trentm@activestate.com Tue Jun 6 03:52:44 2000 From: trentm@activestate.com (Trent Mick) Date: Mon, 5 Jun 2000 19:52:44 -0700 Subject: [Python-Dev] about patches on SourceForge Message-ID: <20000605195244.A25437@activestate.com> I just put up one my patches from this past week on SOurceForge. Question: WWould you all prefer to have the "raw patch" just include the actually patch/diff and for the first comment to be the patch description (and legal stuff?) or would you prefer for the patch description and legal stuff to be part of the "raw patch". I am inclined to think that the former would be preferable. Is there some "apply patch" button in SourceForge that would require the "raw patch" to actually be raw? Go check it out and you will know what I am talking about. http://sourceforge.net/patch/?func=browse&group_id=5470&set=open When I get an good opinion from some of you I will send up my other patches. Trent -- Trent Mick trentm@activestate.com From gstein@lyra.org Tue Jun 6 04:32:27 2000 From: gstein@lyra.org (Greg Stein) Date: Mon, 5 Jun 2000 20:32:27 -0700 (PDT) Subject: [Python-Dev] Re: httplib In-Reply-To: <14651.13155.253651.575394@localhost.localdomain> Message-ID: On Mon, 5 Jun 2000, Jeremy Hylton wrote: > >>>>> "GS" == Greg Stein writes: >... > >> Oh. Wait. Maybe that was it. You can't read the "next" response > >> until the first one has been read. Well... no need to block > >> putting new responses; we just need to create a way to "get the > >> next reply" and/or "can I get the next reply yet?" > > Maybe I should clarify the concern I had here. I think we're on the > same page, but I'm not sure. > > The problem with pipelined requests is that the client must be sure to > read all of response I before it can call getreply to get response > I+1. Actually, you can issue a getreply() after you've read the prior response's headers, but before you completely read its body. Once you have the header, then you know whether the connection will remain open or not. Assuming it *will* remain open, then you can go ahead and do a request/reply sequence. If the connection is going to close, then you have to fail at request time. > I imagine that it could add a lot of complexity to use code to > implement this requirement, e.g. when multiple threads are sharing a > single connection. It would be good if the library could do something > reasonable about the multiplexing. In the absence of making it just > work, the library could raise an error that makes clear what has gone > wrong -- that the client isn't using the interface properly. I'm working through this stuff right now. It is a bit tricky to get it right *and* have it clear. I'm concentrating on the latter as much as possible. At the moment, HTTPResponse instances can be created without problems. I'm locating the "can you issue a request [and get a response]" logic in the connection object itself. Another detail that I'm trying to work through is where the connection is allowed to get the HTTPResponse to read the HTTP header. Reading off the network could block, so we need to be a bit more careful about what methods can block (if any). In any case, the current httplib (at www.lyra.org/greg/python/) has got just about everything. The next checkin will deal with this pipelining issue. QUESTION #2: I *really* want to get rid of the HTTPS() class. It is introducing excessive complexity, with the only purpose being compatibility against the post-1.5.2 CVS. Anyone? Thoughts on removal? Cheers, -g -- Greg Stein, http://www.lyra.org/ From mhammond@skippinet.com.au Tue Jun 6 04:43:15 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Tue, 6 Jun 2000 13:43:15 +1000 Subject: [Python-Dev] about patches on SourceForge In-Reply-To: <20000605195244.A25437@activestate.com> Message-ID: > When I get an good opinion from some of you I will send up my > other patches. How do you qualify a "good" opinion? One that matches yours? This is all too hard until Guido gets back. But personally I believe the raw patch should be just the CVS diff output, and the comments should reflect all other text, including the release notice while it is still necessary. I hope my opinion is good enough :-) Mark. From jeremy@beopen.com Tue Jun 6 04:46:01 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Mon, 5 Jun 2000 23:46:01 -0400 (EDT) Subject: [Python-Dev] Re: httplib In-Reply-To: References: <14651.13155.253651.575394@localhost.localdomain> Message-ID: <14652.29689.663218.777234@localhost.localdomain> >>>>> "GS" == Greg Stein writes: GS> QUESTION #2: I *really* want to get rid of the HTTPS() class. It GS> is introducing excessive complexity, with the only purpose being GS> compatibility against the post-1.5.2 CVS. GS> Anyone? Thoughts on removal? I've got two answers. I don't particularly like the old-style HTTP interface, so I'm happy to see it replaced with a better one. I say who cares about HTTPS. On the other hand, there is a lot of existing code that uses the old interface. It would be good if that code could be modified to use the new SSL interface without having to also re-write the code to use the new http interface. Perhaps we should keep it to provide a future upgrade path for all the legacy code. I could probably be convinced that the amount of effort to change from the old interface to the new interface is fairly small. If you're going to make one change to the code anyway, might as well start using the modern interface, too. Is there anyone who actually has http code to maintain that has an opinion? Jeremy From fdrake@beopen.com Tue Jun 6 04:45:54 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Mon, 5 Jun 2000 23:45:54 -0400 (EDT) Subject: [Python-Dev] about patches on SourceForge In-Reply-To: References: <20000605195244.A25437@activestate.com> Message-ID: <14652.29682.819341.881773@cj42289-a.reston1.va.home.com> Mark Hammond writes: > This is all too hard until Guido gets back. But personally I believe the > raw patch should be just the CVS diff output, and the comments should > reflect all other text, including the release notice while it is still > necessary. Sounds good to me. Let's do it this way until there's a god reason to do it differently. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From pf@artcom-gmbh.de Tue Jun 6 10:05:58 2000 From: pf@artcom-gmbh.de (Peter Funk) Date: Tue, 6 Jun 2000 11:05:58 +0200 (MEST) Subject: [Python-Dev] PyMarshal_WriteLongToFile: writes 'long' or 32-bit integer? In-Reply-To: <20000605171403.A21808@activestate.com> from Trent Mick at "Jun 5, 2000 5:14: 3 pm" Message-ID: Hi, [Trent Mick]: [...] > - PyMarshal_WriteObjectToFile, when writing a PyInt and hence a C long, will > *NOT* truncate the 64-bit integer but will write the whole thing > > - On reading a .pyc the PyMarshal_ReadObjectFromFile will complain on stderr > when a 64-bit integral value is read and the current platform is 32-bit. [...] > The question is: Do we want PyMarshal_WriteLongToFile *AND* > PyMarshal_WriteObjectToFile to raise an exception when a long value overflows > 32-bits? Up til now I was only proposing the former. Yes. This should at least be the default behaviour of Python. The current behaviour would otherwise cause great damage in the following scenario, where an innocent software developer working on a 64-Bit system trusts on the cross platform portability of Pythons bytecode files and unintentional uses a huge integer literal. If some people really don't care about portability, there could be switch/option/pragma/whatever to disable this behaviour. IMO the portability of Python bytecode files is a *very* valuable property, which we shouldn't give up on. Regards, Peter From gstein@lyra.org Tue Jun 6 10:58:44 2000 From: gstein@lyra.org (Greg Stein) Date: Tue, 6 Jun 2000 02:58:44 -0700 (PDT) Subject: [Python-Dev] PyMarshal_WriteLongToFile: writes 'long' or 32-bit integer? In-Reply-To: Message-ID: On Tue, 6 Jun 2000, Peter Funk wrote: > [Trent Mick]: > [...] > > - PyMarshal_WriteObjectToFile, when writing a PyInt and hence a C long, will > > *NOT* truncate the 64-bit integer but will write the whole thing > > > > - On reading a .pyc the PyMarshal_ReadObjectFromFile will complain on stderr > > when a 64-bit integral value is read and the current platform is 32-bit. > [...] > > The question is: Do we want PyMarshal_WriteLongToFile *AND* > > PyMarshal_WriteObjectToFile to raise an exception when a long value overflows > > 32-bits? Up til now I was only proposing the former. > > Yes. This should at least be the default behaviour of Python. > > The current behaviour would otherwise cause great damage in the > following scenario, where an innocent software developer working on > a 64-Bit system trusts on the cross platform portability of Pythons > bytecode files and unintentional uses a huge integer literal. > > If some people really don't care about portability, there could be > switch/option/pragma/whatever to disable this behaviour. > > IMO the portability of Python bytecode files is a *very* valuable property, > which we shouldn't give up on. It isn't only bytecodes. As I mentioned before, marshal byte streams are specified as portable. Therefore, they are used all the time for passing over the network, for persistence mechanisms, etc. Having a marshal stream that is *not* cross-platform is just plain busted. So... you can silently truncate to 32-bits or you can raise an exception. You cannot, however, marshal a 64-bit value when the definition of an "marshal integer" is only 32. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gvwilson@nevex.com Tue Jun 6 15:40:25 2000 From: gvwilson@nevex.com (Greg Wilson) Date: Tue, 6 Jun 2000 10:40:25 -0400 (EDT) Subject: [Python-Dev] req: Software Carpentry / coding standards Message-ID: Hi, everyone. We're a month away from final submissions in the Software Carpentry design competition, which means we're two months away from announcing winners and starting implementation effort, and we're wondering whether there are generally-accepted coding standards, naming conventions, or other guidelines that we should adopt. If so, URLs would be welcome... Also, it appears that there are two implementations of the xUnit testing framework in Python: Steve Purcell: http://sourceforge.net/project/?group_id=3912 Cayte Lindner: ftp://bio.perl.org/pub/katel/biopython/UnitTests/PyUnit.zip We'd be grateful for comments on either. Thanks, Greg Wilson Software Carpentry Project Coordinator From klm@digicool.com Tue Jun 6 17:16:58 2000 From: klm@digicool.com (Ken Manheimer) Date: Tue, 6 Jun 2000 12:16:58 -0400 (EDT) Subject: [Python-Dev] Guido and Kim married Message-ID: <14653.9210.757666.324583@korak.digicool.com> Guido van Rossum and Kim Knapp were married Saturday afternoon on the lawn of a graceful southern estate, Claymont Court, in West Virginia, USA. The weather was *stunningly* fine - a great boon, considering the rain the night before (a torrential downpour in nearby DC) - and the couple left for their honeymoon sunday. Hooray! The crowd consisted of i would guess 70 to 100 people, a mixture of hollanders (including several van rossum relatives - hiya Just!), knapps, pythoners, contact improvisors, economists, martial artists, and sundry other friends and family. I leave to others to quibble about whether or not this qualifies as a "python development". (I probably made enough of a fool of myself at the wedding, with pronouncements of good will and dancing and such, that i can't do any more harm...-) Yay! Ken klm@digicool.com From tim_one@email.msn.com Tue Jun 6 18:20:49 2000 From: tim_one@email.msn.com (Tim Peters) Date: Tue, 6 Jun 2000 13:20:49 -0400 Subject: [Python-Dev] req: Software Carpentry / coding standards In-Reply-To: Message-ID: <001001bfcfdb$8f64d240$48a2143f@tim> [Greg Wilson] > Hi, everyone. We're a month away from final submissions in the > Software Carpentry design competition, which means we're two months > away from announcing winners and starting implementation effort, Yay! This is a wonderful competition, and if nobody yet has bothered to thank you for spearheading it, let me know & I'll find someone who will . > and we're wondering whether there are generally-accepted coding > standards, naming conventions, or other guidelines that we should > adopt. If so, URLs would be welcome... When you can't fight about where to put curly braces, there's not much left to argue. The only serious attempt at a Python style guide I've seen is Guido's: http://www.python.org/doc/essays/styleguide.html Two from there large numbers of people will still argue about, but to no avail: + No hard tabs. Indents are 4 spaces, period. + Keep lines strictly less than 80 characters wide (I happen to keep them under 77, to allow for one level of "> " mail quoting). These rules ensure that code is readable as intended across all platforms. > Also, it appears that there are two implementations of the xUnit > testing framework in Python: > > Steve Purcell: http://sourceforge.net/project/?group_id=3912 > Cayte Lindner: ftp://bio.perl.org/pub/katel/biopython/UnitTests/PyUnit.zip > > We'd be grateful for comments on either. Sorry, unfamiliar with these. From pingster@ilm.com Tue Jun 6 18:25:57 2000 From: pingster@ilm.com (Ka-Ping Yee) Date: Tue, 6 Jun 2000 10:25:57 -0700 (PDT) Subject: [Python-Dev] req: Software Carpentry / coding standards In-Reply-To: <001001bfcfdb$8f64d240$48a2143f@tim> Message-ID: On Tue, 6 Jun 2000, Tim Peters wrote: > > Yay! This is a wonderful competition, and if nobody yet has bothered to > thank you for spearheading it, let me know & I'll find someone who will > . Yeah, what he said. :) > The only serious attempt at a Python style guide I've seen is Guido's: > > http://www.python.org/doc/essays/styleguide.html I love this style guide. I know it's a strange reaction to have to a style guide, but i agree with basically everything in it, which is probably pretty rare for these sorts of things. > + No hard tabs. Indents are 4 spaces, period. Tab characters are the work of the devil. -- ?!ng "China is a big country, inhabited by many Chinese." -- Former French President Charles de Gaulle From gvwilson@nevex.com Tue Jun 6 18:31:32 2000 From: gvwilson@nevex.com (Greg Wilson) Date: Tue, 6 Jun 2000 13:31:32 -0400 (EDT) Subject: [Python-Dev] req: Software Carpentry / coding standards In-Reply-To: <001001bfcfdb$8f64d240$48a2143f@tim> Message-ID: > Tim Peters wrote: > When you can't fight about where to put curly braces, there's not much > left to argue. The only serious attempt at a Python style guide I've > seen is Guido's: > http://www.python.org/doc/essays/styleguide.html Yes, I've seen this. I was wondering (a) whether it's up to date (i.e. whether common practice has moved on), and (b) whether there is now a consensus about module structure --- we're expecting several packages that will be shared between tools, plus multiple modules within tools. I've been tracking the occasional message about re-organizing the standard Python library, and would like whatever we do to be in line with wherever Python itself is going. Thanks, Greg From esr@thyrsus.com Tue Jun 6 18:47:13 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Tue, 6 Jun 2000 13:47:13 -0400 Subject: [Python-Dev] req: Software Carpentry / coding standards In-Reply-To: ; from pingster@ilm.com on Tue, Jun 06, 2000 at 10:25:57AM -0700 References: <001001bfcfdb$8f64d240$48a2143f@tim> Message-ID: <20000606134713.A29204@thyrsus.com> Ka-Ping Yee : > > The only serious attempt at a Python style guide I've seen is Guido's: > > > > http://www.python.org/doc/essays/styleguide.html > > I love this style guide. I know it's a strange reaction to > have to a style guide, but i agree with basically everything > in it, which is probably pretty rare for these sorts of things. Likewise. I never read this before, but it's spooky how closely the style I evolved myself tracks it. -- Eric S. Raymond If a thousand men were not to pay their tax-bills this year, that would ... [be] the definition of a peaceable revolution, if any such is possible. -- Henry David Thoreau From petrilli@amber.org Tue Jun 6 18:52:50 2000 From: petrilli@amber.org (Christopher Petrilli) Date: Tue, 6 Jun 2000 13:52:50 -0400 Subject: [Python-Dev] req: Software Carpentry / coding standards In-Reply-To: <001001bfcfdb$8f64d240$48a2143f@tim>; from tim_one@email.msn.com on Tue, Jun 06, 2000 at 01:20:49PM -0400 References: <001001bfcfdb$8f64d240$48a2143f@tim> Message-ID: <20000606135250.A25856@trump.amber.org> Tim Peters [tim_one@email.msn.com] wrote: > When you can't fight about where to put curly braces, there's not much left > to argue. The only serious attempt at a Python style guide I've seen is > Guido's: > > http://www.python.org/doc/essays/styleguide.html The only thing that might be added (I haven't looked in a while, but didn't see it last time I did), is some naming convention issues. I follow pretty standard Smalltalk guidelines: - No '_', use camelCase for seps - Capitalize all Classes, and also global variables - Lowercase for all methods (i.e. setNewBreakpoint) This is just me, and obviously not everyone does this :-) Chris -- | Christopher Petrilli | petrilli@amber.org From gvwilson@nevex.com Tue Jun 6 18:50:38 2000 From: gvwilson@nevex.com (Greg Wilson) Date: Tue, 6 Jun 2000 13:50:38 -0400 (EDT) Subject: [Python-Dev] req: Software Carpentry / coding standards In-Reply-To: <20000606135250.A25856@trump.amber.org> Message-ID: > > Tim Peters: > > http://www.python.org/doc/essays/styleguide.html > On Tue, 6 Jun 2000, Christopher Petrilli wrote: > The only thing that might be added (I haven't looked in a while, but > didn't see it last time I did), is some naming convention issues. I > follow pretty standard Smalltalk guidelines: > > - No '_', use camelCase for seps I know this is become common practice, but I've been told by two different HCI specialists that studies have shown CamelBackNotation to be harder for non-native speakers to read than underbar_separated_text, particularly when acronyms are part of the name. If anyone has a pointer to an original reference for this, I'd be grateful. Thanks, Greg From klm@digicool.com Tue Jun 6 19:32:12 2000 From: klm@digicool.com (Ken Manheimer) Date: Tue, 6 Jun 2000 14:32:12 -0400 (EDT) Subject: [Python-Dev] req: Software Carpentry / coding standards In-Reply-To: Message-ID: On Tue, 6 Jun 2000, Ka-Ping Yee wrote: > > The only serious attempt at a Python style guide I've seen is Guido's: > > > > http://www.python.org/doc/essays/styleguide.html > > I love this style guide. I know it's a strange reaction to > have to a style guide, but i agree with basically everything > in it, which is probably pretty rare for these sorts of things. Me too! (Or three, or four by now...) Ken klm@digicool.com From tim_one@email.msn.com Tue Jun 6 19:36:26 2000 From: tim_one@email.msn.com (Tim Peters) Date: Tue, 6 Jun 2000 14:36:26 -0400 Subject: [Python-Dev] PyMarshal_WriteLongToFile: writes 'long' or 32-bitinteger? In-Reply-To: Message-ID: <001201bfcfe6$1fe51dc0$48a2143f@tim> [GregS] > It isn't only bytecodes. As I mentioned before, marshal byte streams are > specified as portable. Therefore, they are used all the time for passing > over the network, for persistence mechanisms, etc. > > Having a marshal stream that is *not* cross-platform is just plain busted. > > So... you can silently truncate to 32-bits or you can raise an exception. But in either of those cases it's not cross-platform == it's just plain busted. > You cannot, however, marshal a 64-bit value when the definition of an > "marshal integer" is only 32. The current code is insane. Long-term the visible distinction between (Python) ints and longs should vanish. Short-term the PyInt_Check case of w_object should see whether the int fits in 4 bytes, and if so write it as a C long, and if not write the thing as a Python long (that's the only way to keep the marshal portable!). Any code keying off the SIZEOF_LONG symbol is highly suspect, piling another layer of "convenient but wrong" assumptions on top of the current layer. Code in marshal should *never* try to exploit that C longs happen to be bigger than 4 bytes on the current platform. PyMarshal_WriteLongToFile should be changed to raise an exception if passed something that doesn't fit in 4 bytes, and should be declared obsolete. The Python core should be changed now never to call PyMarshal_WriteLongToFile (in answer to Trent's original question, the intent of that code can't be distinguished from what it does, which is to blindly write exactly 4 bytes no matter what). Most of this crap is in support of a bad assumption about mtimes, and, sorry, but it sure looks to me like the .pyc header format is "just plain busted" too. Let's bite the bullet and fix the header -- then all the rest of this will be clearly seen as the broken hackery it really is. From trentm@activestate.com Tue Jun 6 19:57:52 2000 From: trentm@activestate.com (Trent Mick) Date: Tue, 6 Jun 2000 11:57:52 -0700 Subject: [Python-Dev] about patches on SourceForge In-Reply-To: <14652.29682.819341.881773@cj42289-a.reston1.va.home.com> References: <20000605195244.A25437@activestate.com> <14652.29682.819341.881773@cj42289-a.reston1.va.home.com> Message-ID: <20000606115752.D28943@activestate.com> On Mon, Jun 05, 2000 at 11:45:54PM -0400, Fred L. Drake, Jr. wrote: > > Mark Hammond writes: > > This is all too hard until Guido gets back. But personally I believe the > > raw patch should be just the CVS diff output, and the comments should > > reflect all other text, including the release notice while it is still > > necessary. > > Sounds good to me. Let's do it this way until there's a god reason ^^^ > to do it differently. > I think maybe that you meant 'good', but I am not so sure. ;-) Trent -- Trent Mick trentm@activestate.com From gmcm@hypernet.com Tue Jun 6 19:59:49 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Tue, 6 Jun 2000 14:59:49 -0400 Subject: [Python-Dev] req: Software Carpentry / coding standards In-Reply-To: References: <001001bfcfdb$8f64d240$48a2143f@tim> Message-ID: <1251804473-5567942@hypernet.com> Greg Wilson wrote: > > Tim Peters wrote: [Guido's style guide] > Yes, I've seen this. I was wondering > ... whether > there is now a consensus about module structure ... No, there's not. And if you ask me, (which you didn't) there's some very bad precedents getting set in the misguided pursuit of "ease of use". Time to call out the PSU before things get out of hand... - Gordon From gstein@lyra.org Tue Jun 6 20:04:25 2000 From: gstein@lyra.org (Greg Stein) Date: Tue, 6 Jun 2000 12:04:25 -0700 (PDT) Subject: [Python-Dev] req: Software Carpentry / coding standards In-Reply-To: Message-ID: On Tue, 6 Jun 2000, Greg Wilson wrote: > > > Tim Peters: > > > http://www.python.org/doc/essays/styleguide.html > > > On Tue, 6 Jun 2000, Christopher Petrilli wrote: > > The only thing that might be added (I haven't looked in a while, but > > didn't see it last time I did), is some naming convention issues. I > > follow pretty standard Smalltalk guidelines: > > > > - No '_', use camelCase for seps > > I know this is become common practice, but I've been told by two different > HCI specialists that studies have shown CamelBackNotation to be harder for > non-native speakers to read than underbar_separated_text, particularly > when acronyms are part of the name. If anyone has a pointer to an > original reference for this, I'd be grateful. Actually, the "camel case" for identifiers is not a standard Python style. I've seen three forms: - no separator or case usage (e.g. getattr()) - mixed case - lower case with underscores Chris' other points: upper-case-initial classes and lower-case-initial methods are *definitely* standard. Globals are a bit different. I don't think it is standard to capitalize them as Chris mentioned (they might look like classes in that case). There isn't much of a standard there. Definitely another point is the use of "_" for the initial character to signify "private -- don't touch" Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Tue Jun 6 20:29:56 2000 From: gstein@lyra.org (Greg Stein) Date: Tue, 6 Jun 2000 12:29:56 -0700 (PDT) Subject: [Python-Dev] ANSI-fication (was: RE: [Patches] fix simple 64-bit warnings/errors in signalmodule.c and bufferobject.c) In-Reply-To: <001c01bfcfea$b73a2040$48a2143f@tim> Message-ID: On Tue, 6 Jun 2000, Tim Peters wrote: >... > [on K&R style declarations failing to act as prototypes] > > ... > > Give the man a prize. That was it. We'll just forget that part of the > > patch then and thank you Tim for changing all function declarations > > from K&R to ANSI. :) > > Believe it or not, I do intend to do that, although I expect resistance from > Guido <0.5 wink>. Python's infrastructure is creaking from age, and an > update to ANSI C is l-o-n-g overdue. It appears to me that a very large > part of your "Win64" efforts have amounted to fighting long-obsolete K&R C > assumptions! Euh... I thought Guido was entirely supportive of ANSI-fying the source. Something like changing from K&R functions over to ANSI declarations is "brain-dead" that should not introduce errors. Going through and revamping the protoypes (e.g. PyString_FromStringAndSize to now use size_t) is a bit different, though... I shouldn't think Guido would be upset about prototypes. Cheers, -g -- Greg Stein, http://www.lyra.org/ From Fredrik Lundh" Message-ID: <01b101bfcff5$1000faa0$f2a6b5d4@hagrid> greg wrote: > Euh... I thought Guido was entirely supportive of ANSI-fying the = source. note that 1.6 won't build on non-ANSI platforms; lots of new stuff, including the unicode type, the builtin exceptions, and SRE are pure ANSI. (btw, what are all those "register" declarations doing in MAL's version of unicodeobject.c? does any modern compiler even care about that keyword?) From tim_one@email.msn.com Tue Jun 6 22:00:33 2000 From: tim_one@email.msn.com (Tim Peters) Date: Tue, 6 Jun 2000 17:00:33 -0400 Subject: [Python-Dev] RE: ANSI-fication (was: RE: [Patches] fix simple 64-bit warnings/errorsin signalmodule.c and bufferobject.c) In-Reply-To: Message-ID: <001f01bfcffa$41ed2f20$48a2143f@tim> [Greg Stein] > Euh... I thought Guido was entirely supportive of ANSI-fying the source. > Something like changing from K&R functions over to ANSI declarations is > "brain-dead" that should not introduce errors. ... He'll be less & less in favor of it when it hits home how time-consuming and massive the changes will be. They won't be viewed as "a feature" to BeOpen, so BeOpen will give him grief about it too. Etc. I've fought the same stinking infrastructure battles for 20+ years, and don't expect that having a new boss will make any material difference to that <0.7 wink>. Testing is expensive, robustness is expensive, portability is expensive (and C doesn't help! honest to God, it's much worse than Fortran for portability). > Going through and revamping the protoypes (e.g. PyString_FromStringAndSize > to now use size_t) is a bit different, though... > > I shouldn't think Guido would be upset about prototypes. Nobody should get upset about *having* them, it's getting them done that takes away from getting everything else done. That's why every project I've ever seen puts it off year after year. Note that if Guido valued this *highly*, it would already have been done. been-there-done-that-been-there-done-that-been-there-done-that-ly y'rs - tim From jack@oratrix.nl Tue Jun 6 22:14:10 2000 From: jack@oratrix.nl (Jack Jansen) Date: Tue, 06 Jun 2000 23:14:10 +0200 Subject: [Python-Dev] Trying again: [Patches] Patch to import.c Message-ID: <20000606211416.10B6ED8397@oratrix.oratrix.nl> --boogadaboogadabooga Content-Type: text/plain; charset="us-ascii" Folks, I posted this message to the patches mailing list last week, but either I missed the reply (we had full disks over the weekend) or nobody replied yet. And I am waiting for these patches, or rather other people who want to play with MacPython and MacOSX are, so I'd really like to know whether I should revise the patches and in what direction or have them checked in.... Hmm, that may all sound a bit pushy, but that isn't the intention. I really just want to know (a) what the status of my patches is and (b) what I can expect in the future.... Jack --boogadaboogadabooga Content-Type: message/rfc822 From jack@oratrix.nl Sat Jun 3 13: 06:03 2000 Delivered-To: jack@oratrix.nl Received: by oratrix.oratrix.nl (Postfix, from userid 201) id 63987D7210; Sat, 3 Jun 2000 13:06:02 +0200 (MET DST) Received: from localhost (localhost [127.0.0.1]) by oratrix.oratrix.nl (Postfix) with ESMTP id 3EED619B1E9A; Sat, 3 Jun 2000 13:05:57 +0200 (MET DST) To: patches@python.org Cc: jack@oratrix.nl Subject: Re: [Patches] Patch to import.c In-Reply-To: Message by Greg Stein , Sat, 3 Jun 2000 03:26:25 -0700 (PDT) , Organisation: Oratrix Development, Valeriusplein 30, 1075 BJ Amsterdam, NL Phone: +31 20 6795452(work), +31 20 6795309 (fax), +31 20 6160335(home) X-Last-Band-Seen: Stiff Little Fingers (Melkweg, 4-5) X-Mini-Review: Absolutely brilliant!!! Date: Sat, 03 Jun 2000 13:05:57 +0200 From: Jack Jansen Return-Path: Message-Id: <20000603110602.63987D7210@oratrix.oratrix.nl> I'm a bit confused as to the current procedure for patches. It used to be that Guido said "yes" or "no", and that was it. Nowadays there seem to be very many people on the patches mailing list, and a patch gets a number of replies ranging from "don't do this" to "can't you do this differently". I've tried to reply to all the issues, but I'm now completely in the dark as to the status of my patches: I'm under the impression that I've defended the case for my patches satisfactorily (hehe:-), but people on the patch mailing list may think that I've some fixing up to do. As I didn't follow discussions on the new patch system: is there a procedure and, if so, could it be documented on python.org/patches? And if there isn't one: could one be designed and documented, please? A time-limit on patch acceptance/rejection would also be nice, if possible: I use the repository to sync my home machine and work machine, which worked fine when Guido alone was responsible as he worked what seems to be 19 hours per day, so patches usually ended up in the repository before I had the chance to cycle from home to work or vv., but with the new procedure it can apparently take a lot longer for patches to appear, so I may have to come up with another scheme to sync my multiple machines... -- 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 --boogadaboogadabooga-- From mal@lemburg.com Tue Jun 6 23:53:02 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 07 Jun 2000 00:53:02 +0200 Subject: [Python-Dev] ANSI-fication (was: RE: [Patches] fix simple 64-bit warnings/errorsin signalmodule.c and bufferobject.c) References: <01b101bfcff5$1000faa0$f2a6b5d4@hagrid> Message-ID: <393D80CE.D6C387AA@lemburg.com> Fredrik Lundh wrote: > > note that 1.6 won't build on non-ANSI platforms; lots of new > stuff, including the unicode type, the builtin exceptions, and > SRE are pure ANSI. > > (btw, what are all those "register" declarations doing in MAL's > version of unicodeobject.c? does any modern compiler even > care about that keyword?) "register" helps compilers in situations where normal optimizations don't give satisfying results, e.g. to aid in keeping often used variables or counters in registers rather than on the stack. It can also help with inling functions and can speed up parameter passing. GCC is one such modern compiler that does care, not sure about MSVC++. IBM's OS/2 compilers did (last time I looked some 5 years ago ;). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From pf@artcom-gmbh.de Tue Jun 6 23:47:41 2000 From: pf@artcom-gmbh.de (Peter Funk) Date: Wed, 7 Jun 2000 00:47:41 +0200 (MEST) Subject: Style guide (was Re: [Python-Dev] req: Software Carpentry / coding standards) In-Reply-To: from Greg Wilson at "Jun 6, 2000 1:50:38 pm" Message-ID: Hi, Greg Wilson: > > > Tim Peters: > > > http://www.python.org/doc/essays/styleguide.html > > > On Tue, 6 Jun 2000, Christopher Petrilli wrote: > > The only thing that might be added (I haven't looked in a while, but > > didn't see it last time I did), is some naming convention issues. I > > follow pretty standard Smalltalk guidelines: > > > > - No '_', use camelCase for seps > > I know this is become common practice, but I've been told by two different > HCI specialists that studies have shown CamelBackNotation to be harder for > non-native speakers to read than underbar_separated_text, particularly > when acronyms are part of the name. If anyone has a pointer to an > original reference for this, I'd be grateful. This would be indeed very interesting. But my own experiences support this POV: This naming style issue is similar in Python and one of its early anchestors Modula-2. In 1985 we started our company programming in Modula-2. At that time we decided to code conforming to the original Modula-2 language definition as published by N.Wirth in March, 1980: underscores were not allowed in identifiers! German: '_' verboten! ;-) The software is in use until today and several of our employees still have to use Modula-2 for maintainance. The code base is currently about 1 Mio. LOC. We tried to use english identifiers, although all programmers are native german speakers. We too adopted a style using first char lowercase or uppercase to distinguish identifier classes (modules and procedure names uppercase and all other identifiers lowercase) and later we ran into the problems described above. A few years ago we allowed the use of '_' in identifiers, because the compiler support was available. This has improved the situation somewhat. All our programmers like the possibility to occasionally use '_' in identifiers, especially if idents contain acronyms. Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen) From pf@artcom-gmbh.de Wed Jun 7 10:34:12 2000 From: pf@artcom-gmbh.de (Peter Funk) Date: Wed, 7 Jun 2000 11:34:12 +0200 (MEST) Subject: [Python-Dev] Idea: emulating _locale (was Re: [Python-checkins] CVS: python/dist/src/Lib locale.py,1.4,1.5) In-Reply-To: <200006070911.CAA17368@slayer.i.sourceforge.net> from Marc-Andre Lemburg at "Jun 7, 2000 2:11:43 am" Message-ID: Hi, Marc-Andre Lemburg: [...] > Added a new locale name aliasing engine which also supports > locale encodings, a feature which is used by the new default > encoding support in site.py. > > Index: locale.py [...] > + ### C lib locale APIs > + > + from _locale import * Wouldn't it be clever to provide some dummy stubs on those platforms, where the _locale module was not enabled? try: from _locale import * except: def setlocale(.... def localeconv(.... ... Especially the MacOS 1.5.2 release provided by Jack Jansen was compiled without '_locale'. And at least in Python 1.6a2 '_locale' is still disabled per default in 'Modules/Setup.in'. I didn't had a look into the current CVS though, so this may have changed. I think the name aliasing tables might be also useful on those systems lacking locale support in their C-library. Regards, Peter From pf@artcom-gmbh.de Wed Jun 7 10:40:17 2000 From: pf@artcom-gmbh.de (Peter Funk) Date: Wed, 7 Jun 2000 11:40:17 +0200 (MEST) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules Setup.in,1.100,1.101 In-Reply-To: <200006070912.CAA17814@slayer.i.sourceforge.net> from Marc-Andre Lemburg at "Jun 7, 2000 2:12:56 am" Message-ID: Uoooppps.... I was just too fast with my previous email about _locale emulation. Marc-Andre Lemburg: > *** Setup.in 2000/05/26 19:02:42 1.100 > --- Setup.in 2000/06/07 09:12:54 1.101 > *************** > *** 141,145 **** > # static Unicode character database > > ! #_locale _localemodule.c # access to ISO C locale support > > > --- 141,145 ---- > # static Unicode character database > > ! _locale _localemodule.c # access to ISO C locale support > Is this likely to work on the Mac with C-libraries coming with Metrowerks CodeWarrior? Jack? Regards, Peter From fredrik@pythonware.com Wed Jun 7 11:24:46 2000 From: fredrik@pythonware.com (Fredrik Lundh) Date: Wed, 7 Jun 2000 12:24:46 +0200 Subject: [Python-Dev] ANSI-fication (was: RE: [Patches] fix simple 64-bit warnings/errorsin signalmodule.c and bufferobject.c) References: <01b101bfcff5$1000faa0$f2a6b5d4@hagrid> <393D80CE.D6C387AA@lemburg.com> Message-ID: <007a01bfd06a$9d3db140$0500a8c0@secret.pythonware.com> MAL wrote: > > (btw, what are all those "register" declarations doing in MAL's > > version of unicodeobject.c? does any modern compiler even > > care about that keyword?) >=20 > "register" helps compilers in situations where normal > optimizations don't give satisfying results, e.g. to aid > in keeping often used variables or counters in registers > rather than on the stack. It can also help with inling > functions and can speed up parameter passing. Yeah, I know what register is supposed to do. But common knowledge (at least where I live) is that modern optimizers know better than you, and usually ignore "register" altogether if you = use higher optimization levels... (and if they don't, using "register" is = likely to make things worse on some platforms). In other words, "register" should not be used in portable code. fwiw, a certain Linux kernel hacker seem to agree with me on that one: http://www2.linuxjournal.com/lj-issues/issue17/1138.html ... #define register ... "Gcc, the normal Linux C compiler, understands the register keyword, but the code optimiser is sufficiently good that using register is = normally a bad idea." ... (If it's good enough for Alan Cox etc). But never mind. I doubt that removing them would matter on any con- temporary platform, but on the other hand, keeping them in there won't hurt much either. It just makes the source code a little bit more ver- bose than it has to be... From mal@lemburg.com Wed Jun 7 11:25:08 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 07 Jun 2000 12:25:08 +0200 Subject: [Python-Dev] Idea: emulating _locale (was Re: [Python-checkins] CVS: python/dist/src/Lib locale.py,1.4,1.5) References: Message-ID: <393E2304.4BE8CDE0@lemburg.com> Peter Funk wrote: > > Hi, > > Marc-Andre Lemburg: > [...] > > Added a new locale name aliasing engine which also supports > > locale encodings, a feature which is used by the new default > > encoding support in site.py. > > > > Index: locale.py > [...] > > + ### C lib locale APIs > > + > > + from _locale import * > > Wouldn't it be clever to provide some dummy stubs on those platforms, where > the _locale module was not enabled? > > try: > from _locale import * > except: > def setlocale(.... > def localeconv(.... > ... > > Especially the MacOS 1.5.2 release provided by Jack Jansen was > compiled without '_locale'. And at least in Python 1.6a2 '_locale' > is still disabled per default in 'Modules/Setup.in'. I didn't had > a look into the current CVS though, so this may have changed. > > I think the name aliasing tables might be also useful on those > systems lacking locale support in their C-library. setlocale and localeconv are ANSI C and Python requires an ANSI C compiler, so there should be no problem (at least in theory). If there is a problem, adding the missing symbols would be no problem: the APIs could always report locale 'C' and its numeric settings. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Wed Jun 7 11:40:24 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 07 Jun 2000 12:40:24 +0200 Subject: [Python-Dev] ANSI-fication (was: RE: [Patches] fix simple 64-bit warnings/errorsin signalmodule.c and bufferobject.c) References: <01b101bfcff5$1000faa0$f2a6b5d4@hagrid> <393D80CE.D6C387AA@lemburg.com> <007a01bfd06a$9d3db140$0500a8c0@secret.pythonware.com> Message-ID: <393E2698.D2DFFC91@lemburg.com> Fredrik Lundh wrote: > > MAL wrote: > > > (btw, what are all those "register" declarations doing in MAL's > > > version of unicodeobject.c? does any modern compiler even > > > care about that keyword?) > > > > "register" helps compilers in situations where normal > > optimizations don't give satisfying results, e.g. to aid > > in keeping often used variables or counters in registers > > rather than on the stack. It can also help with inling > > functions and can speed up parameter passing. > > Yeah, I know what register is supposed to do. I know you know, but I find adding some explanations for others which might not know is good practice. > But common knowledge (at least where I live) is that modern optimizers > know better than you, and usually ignore "register" altogether if you use > higher optimization levels... (and if they don't, using "register" is likely to > make things worse on some platforms). In other words, "register" should > not be used in portable code. > > fwiw, a certain Linux kernel hacker seem to agree with me on that one: > > http://www2.linuxjournal.com/lj-issues/issue17/1138.html > ... > #define register > ... > "Gcc, the normal Linux C compiler, understands the register keyword, > but the code optimiser is sufficiently good that using register is normally > a bad idea." > ... Well, make that "normally not needed": gcc sometimes doesn't inline functions because it thinks that the function needs parameters to be on the stack. The register keyword can do wonders here. Adding "register" is like adding salt & pepper: things usually taste better than before ;-). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gward@mems-exchange.org Wed Jun 7 14:19:06 2000 From: gward@mems-exchange.org (Greg Ward) Date: Wed, 7 Jun 2000 09:19:06 -0400 Subject: [Python-Dev] Re: [Patches] Translating doc strings In-Reply-To: <200006021503.RAA26314@pandora>; from loewis@informatik.hu-berlin.de on Fri, Jun 02, 2000 at 05:03:50PM +0200 References: <200006020701.JAA28620@pandora> <39376C19.53A01A27@lemburg.com> <200006021233.OAA16962@pandora> <14647.47270.330318.807347@anthem.python.org> <200006021503.RAA26314@pandora> Message-ID: <20000607091906.A5559@ludwig.cnri.reston.va.us> On 02 June 2000, Martin von Loewis said: > Having the full set of distutils doc strings in the > catalog is already a substantial amount of text to translate... Most of those docstrings in the Distutils are not really for public consumption; they're there so that Distutils developers can remember (or learn) what the heck such-and-such a method is supposed to do. Also, they're a moving target; things are still changing in the Distutils, and trying to keep on top of translating internal docstrings would be a hopeless and frustrating task. Greg From jack@oratrix.nl Wed Jun 7 14:51:54 2000 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 07 Jun 2000 15:51:54 +0200 Subject: [Python-Dev] Idea: emulating _locale (was Re: [Python-checkins] CVS: python/dist/src/Lib locale.py,1.4,1.5) In-Reply-To: Message by "M.-A. Lemburg" , Wed, 07 Jun 2000 12:25:08 +0200 , <393E2304.4BE8CDE0@lemburg.com> Message-ID: <20000607135154.8DCFD370CF2@snelboot.oratrix.nl> The locale stuff in the CodeWarrior libraries is basically a dummy placeholder, that's why I didn't export it to Python. But it appears that it's better to export it anyway, if I understand the dsicussion correctly, so I'll do so from the next release. -- 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 gward@mems-exchange.org Wed Jun 7 14:56:38 2000 From: gward@mems-exchange.org (Greg Ward) Date: Wed, 7 Jun 2000 09:56:38 -0400 Subject: [Python-Dev] Revised 1.6 jobs list In-Reply-To: ; from jeremy@beopen.com on Sat, Jun 03, 2000 at 12:11:48PM -0400 References: <3938D60E.391AAF31@lemburg.com> Message-ID: <20000607095638.B5559@ludwig.cnri.reston.va.us> On 03 June 2000, Jeremy Hylton said: > SourceForge makes it a little more inconvenient to check which > patches have been applied. Under the old CVS arrangement, it was > a local operation to do a cvs log or diff. Now it's a slow network > operation that requires authentication. (I really want a local > mirror of the entire CVS repository!) I have come up with a partial solution to the inconvenience of accessing SourceForge, specifically the need for constant authentication. I generated a new, unencrypted SSH key and put it in ~/.ssh/alt-identity. Then I wrote a little C program (source attached) that does the equivalent of os.exec ("ssh", "-i", "$HOME/.ssh/alt-identity") (in an imaginary dialect of Python that interpolates environment variables ;-). Then I set CVS_RSH to this little C program (~/bin/alt_ssh). (It could have easily been a script, but I wanted to avoid the overhead of launching an interpreter for every authentication.) So now CVS operations against SF are just s..l..o..w, and I'm not forever typing in my SSH passphrase. Of course, anyone with root access at CNRI could now steal my unencrypted key -- which I *only* use for CVS access to SF -- and use it to impersonate me for checkins. But I think the only person who knows how to do that already has Python checkin privilege. ;-) But yeah, remote CVS still bites the big one. Very painful over a 28.8k modem line. (It sucks being a cheap bastard!) Greg -- Greg Ward - software developer gward@mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From gward@mems-exchange.org Wed Jun 7 14:57:41 2000 From: gward@mems-exchange.org (Greg Ward) Date: Wed, 7 Jun 2000 09:57:41 -0400 Subject: [Python-Dev] Revised 1.6 jobs list In-Reply-To: <20000607095638.B5559@ludwig.cnri.reston.va.us>; from gward@ludwig.cnri.reston.va.us on Wed, Jun 07, 2000 at 09:56:38AM -0400 References: <3938D60E.391AAF31@lemburg.com> <20000607095638.B5559@ludwig.cnri.reston.va.us> Message-ID: <20000607095741.C5559@ludwig.cnri.reston.va.us> --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=us-ascii On 07 June 2000, I said: > Then I wrote a little C program (source attached) that does the > equivalent of Oops, forgot the attachment. Here 'tis. --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="alt_ssh.c" /* * alt_ssh * * exec ssh with an alternate "identity" (key pair) -- needed since * the CVS_RSH variable can't include options for the rsh-like * command. * * GPW 2000/05/28 * * $Id: alt_ssh.c,v 1.3 2000/06/07 13:54:19 gward Exp $ */ #include #include #include #include #include int main (int argc, char * argv[]) { char * keyfile = "/.ssh/alt-identity"; char * keyfile_full; char * home; int num_args; char ** ssh_args; int i; home = getenv("HOME"); keyfile_full = (char *) malloc (strlen(home) + strlen(keyfile) + 1); assert (home != NULL && keyfile_full != NULL); strcpy(keyfile_full, home); strcat(keyfile_full, keyfile); num_args = argc + 2; /* -i, identity-file */ ssh_args = (char **) calloc (num_args+1, sizeof(char *)); ssh_args[0] = "ssh"; ssh_args[1] = "-i"; ssh_args[2] = keyfile_full; for (i = 3; i < num_args; i++) ssh_args[i] = argv[i-2]; ssh_args[i] = NULL; for (i = 0; i < num_args; i++) { printf(ssh_args[i]); if (i < num_args) printf(" "); } printf("\n"); execvp("ssh", ssh_args); perror("couldn't exec ssh"); exit(1); } --NzB8fVQJ5HfG6fxh-- From jeremy@beopen.com Wed Jun 7 15:04:12 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Wed, 7 Jun 2000 10:04:12 -0400 (EDT) Subject: [Python-Dev] Fwd: Hmmmm... (Jim Anderson) Message-ID: <14654.22108.959934.552869@localhost.localdomain> --iNprjKW4TE Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit You guys haven't seen more Perl traffic on this list have you? :-) Jeremy --iNprjKW4TE Content-Type: message/rfc822 Content-Description: forwarded message Content-Transfer-Encoding: 7bit X-Digest: perl5-porters Digest 7 Jun 2000 05:57:31 -0000 Issue 490 Message-ID: <14653.8785.324733.949201@gargle.gargle.HOWL> MIME-Version: 1.0 Content-Type: text/plain From: "Jim Anderson" To: perl5-porters@perl.org Subject: Hmmmm... Date: Tue, 6 Jun 2000 12:09:53 -0400 (EDT) This list has been ominously quiet the last couple of days. What's the deal? Is everyone: 1. stressed out? 2. on holiday? 3. switching to python? :) jim --iNprjKW4TE-- From gward@mems-exchange.org Wed Jun 7 15:11:46 2000 From: gward@mems-exchange.org (Greg Ward) Date: Wed, 7 Jun 2000 10:11:46 -0400 Subject: [Python-Dev] release forms? (was: [Patches] New sys method to return total reference count in debug builds.) In-Reply-To: ; from gstein@lyra.org on Sun, Jun 04, 2000 at 04:30:08PM -0700 References: Message-ID: <20000607101146.D5559@ludwig.cnri.reston.va.us> On 04 June 2000, Greg Stein said: > p.s. IMO, I'd like to see Guido own the Copyright for all current and > future Python development Second that. Given that I work for CNRI and was forced (at gunpoint, as I recall) to sign an incredibly draconian IP agreement -- along the lines of "everything you have ever created, or will ever consider creating, in any medium whatsoever, no matter where you did it or who pays for it, is the property of CNRI for all time" -- I'd have a hard time getting away with slapping "Copyright (c) 1999-2000 Gregory P. Ward" all over the Distutils code. And given that fair chunks of that code have been contributed by other people, I couldn't even ethically do that. So, given that I probably can't claim ownership in the code, and that CNRI has absolutely no moral right to it (although probably some legal right), I'd prefer to sign it away to Guido. Or optionally, to some legal fiction that represents the Python community; preferably *not* the Python Consortium, as long as CNRI is in any way connected. Death to the lawyers! Greg -- Greg Ward - software developer gward@mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From Moshe Zadka Wed Jun 7 15:33:10 2000 From: Moshe Zadka (Moshe Zadka) Date: Wed, 7 Jun 2000 17:33:10 +0300 (IDT) Subject: [Python-Dev] release forms? (was: [Patches] New sys method to return total reference count in debug builds.) In-Reply-To: <20000607101146.D5559@ludwig.cnri.reston.va.us> Message-ID: On Wed, 7 Jun 2000, Greg Ward wrote: > CNRI has absolutely no moral right to it (although probably some legal > right), I'd prefer to sign it away to Guido. Or optionally, to some > legal fiction that represents the Python community; preferably *not* the > Python Consortium, as long as CNRI is in any way connected. Who's in charge of the PSA? Or should we form *another* non-profit, and sign it over to it? (Personally, I couldn't care less who I transfer copyright over my Python contributions to -- I'd put it in the public domain if that's what it took) -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com From pf@artcom-gmbh.de Wed Jun 7 15:44:30 2000 From: pf@artcom-gmbh.de (Peter Funk) Date: Wed, 7 Jun 2000 16:44:30 +0200 (MEST) Subject: [Python-Dev] Revised 1.6 jobs list In-Reply-To: <20000607095638.B5559@ludwig.cnri.reston.va.us> from Greg Ward at "Jun 7, 2000 9:56:38 am" Message-ID: Hi, Greg Ward: > But yeah, remote CVS still bites the big one. Very painful over a 28.8k > modem line. (It sucks being a cheap bastard!) Certainly you know about 'rsync'? Would this help here? Let me quote a small section from the 'rsync' man page: """ To synchronize my samba source trees I use the following Makefile targets: get: rsync -avuzb --exclude ´*~´ samba:samba/ . put: rsync -Cavuzb . samba:samba/ sync: get put this allows me to sync with a CVS directory at the other end of the link. I then do cvs operations on the remote machine, which saves a lot of time as the remote cvs pro­ tocol isn´t very efficient. """ I can't access CVS because of our restrictive HTTP/UUCP only firewall, but in our company we use 'rsync' a lot. Regards, Peter From bwarsaw@python.org Wed Jun 7 16:06:42 2000 From: bwarsaw@python.org (Barry A. Warsaw) Date: Wed, 7 Jun 2000 11:06:42 -0400 (EDT) Subject: [Python-Dev] Revised 1.6 jobs list References: <3938D60E.391AAF31@lemburg.com> <20000607095638.B5559@ludwig.cnri.reston.va.us> Message-ID: <14654.25858.564089.574043@anthem.python.org> >>>>> "GW" == Greg Ward writes: GW> I have come up with a partial solution to the inconvenience of GW> accessing SourceForge, specifically the need for constant GW> authentication. Greg, are you aware of ssh-agent? Same convenience, same possible exploits, but at least they've done the hard work for ya. :) I usually just run XEmacs under ssh-agent. First thing you do is fire up a shell buffer, run ssh-add to authenticate once, and from there on, all your ssh interactions (not just with SF) yank the private key out of the ssh-agent process and never bother you with a passphrase prompt. -Barry From bwarsaw@python.org Wed Jun 7 16:22:20 2000 From: bwarsaw@python.org (Barry A. Warsaw) Date: Wed, 7 Jun 2000 11:22:20 -0400 (EDT) Subject: [Python-Dev] release forms? (was: [Patches] New sys method to return total reference count in debug builds.) References: <20000607101146.D5559@ludwig.cnri.reston.va.us> Message-ID: <14654.26796.936980.875783@anthem.python.org> >>>>> "MZ" == Moshe Zadka writes: MZ> Who's in charge of the PSA? Or should we form *another* MZ> non-profit, and sign it over to it? (Personally, I couldn't MZ> care less who I transfer copyright over my Python MZ> contributions to -- I'd put it in the public domain if that's MZ> what it took) Please remember that the copyright holder can release the code under whatever license they want, even multiple different licenses. Copyright != license. I'm not sure what the right thing to do here is. On the one hand, Bob Kahn always said nobody would use Python if its heritage (i.e. copyright ownership) were not nailed down like Java. On the other hand, there's a lot of nobodies out there right now :). For GNU projects, the FSF wants to own all the copyrights to the code. They actually want you to legally assign the copyright to them. Their explanation for this onerous requirement is that if they were not the copyright holder, they would not have the legal standing to defend GPL violations, or would have to coordinate with a ton of developers, making such legal defenses practically impossible. Python is in a different situation, IMO, because it has a /less/ restrictive license than the GPL, so there's less to get all huffy about in court. If someone builds a binary-only proprietary blend of Python and starts selling it without source code, well, there's no license violation there, so what's to defend? The argument has been made that without clear legal title, someone could claim that some of the donated code in Python violated a copyright or patent and try to stop 3rd parties from using Python. Who knows what the actual legal possibility of that happening are, but I don't see how 1) we could take any real defense against this or 2) it affects Python any differently than any other large multi-contributor open source system. -Barry From andy@robanal.demon.co.uk Wed Jun 7 21:48:48 2000 From: andy@robanal.demon.co.uk (Andy Robinson) Date: Wed, 07 Jun 2000 20:48:48 GMT Subject: [Python-Dev] Package ambiguities Message-ID: <393eb52b.47053339@post.demon.co.uk> We hit some very weird behaviour recently while setting up a package hierarchy. Robin Becker managed to distil this into a simple example. Can anyone shed any light on what is happening below? Is Python behaving as it should? Create a package A, empty __init__.py, with modules as follows: --------parent.py---------- class Parent: pass --------child.py------------ from parent import Parent class Child(Parent): pass ---------test.py-------- from parent import * class Examiner: def examine(self, arg): print 'examining argument:' print 'class of arg =3D', arg.__class__ print 'bases of arg =3D', arg.__class__.__bases__ print 'arg =3D', arg if isinstance(arg, Parent): print "arg is an instance of Parent" else: print "arg IS NOT an instance of Parent" print =20 if __name__=3D=3D'__main__': from traceback import print_exc import sys def run0(): from A.child import Child e =3D Examiner() e.examine(Child()) def run1(): from A.child import Child from A.test import Examiner e =3D Examiner() e.examine(Child()) run0() run1() Running this script produces the following output: C:\users\andy\A>test.py examining argument: class of arg =3D A.child.Child bases of arg =3D (,) arg =3D arg IS NOT an instance of Parent examining argument: class of arg =3D A.child.Child bases of arg =3D (,) arg =3D arg is an instance of Parent Many thanks, Andy Robinson From Ka-Ping Yee Wed Jun 7 22:05:26 2000 From: Ka-Ping Yee (Ka-Ping Yee) Date: Wed, 7 Jun 2000 14:05:26 -0700 (PDT) Subject: [Python-Dev] Package ambiguities In-Reply-To: <393eb52b.47053339@post.demon.co.uk> Message-ID: On Wed, 7 Jun 2000, Andy Robinson wrote: > We hit some very weird behaviour recently while setting up a package > hierarchy. Robin Becker managed to distil this into a simple example. > Can anyone shed any light on what is happening below? Is Python > behaving as it should? It looks to me like you have two "parent" modules. When you run "test.py" directly from the command line, the first "from parent import *" imports parent.py as module "parent". But subsequently parent.py is imported again as module "A.parent". Similarly, you have two "Examiner" classes. In run0() you get Examiner from __main__, which contains the Parent class from module "parent". In run1() you get Examiner from A.test, which contains the Parent class imported from module "A.parent". If you insert print 'in module', __name__, 'parent is', repr(Parent) at the beginning of the examine() method, it should make things clear. The solution is to avoid directly running scripts that are inside packages; the confusion is produced by the fact that you're running "test.py" from within the A/ directory. -- ?!ng From jeremy@beopen.com Wed Jun 7 22:25:53 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Wed, 7 Jun 2000 17:25:53 -0400 (EDT) Subject: [Python-Dev] revamped Python web site Message-ID: <14654.48609.710990.321688@localhost.localdomain> Say a startup company decided to put some resources behind the Python Web site -- a full-time Web master, some content developers, etc. What would you have them do? What could be done to open up the site to the community and make it more responsive to developers and users? What's your wish list for content, services, etc.? If you've got any ideas, please get back to me soon. Jeremy From esr@thyrsus.com Wed Jun 7 22:41:48 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Wed, 7 Jun 2000 17:41:48 -0400 Subject: [Python-Dev] revamped Python web site In-Reply-To: <14654.48609.710990.321688@localhost.localdomain>; from jeremy@beopen.com on Wed, Jun 07, 2000 at 05:25:53PM -0400 References: <14654.48609.710990.321688@localhost.localdomain> Message-ID: <20000607174148.A6801@thyrsus.com> Jeremy Hylton : > Say a startup company decided to put some resources behind the Python > Web site -- a full-time Web master, some content developers, etc. > What would you have them do? What could be done to open up the site > to the community and make it more responsive to developers and users? > What's your wish list for content, services, etc.? I think it's pretty good as is -- lots of content, pretty well organized. My top wishlist item is "Burn all your GIFs". -- Eric S. Raymond The right of self-defense is the first law of nature: in most governments it has been the study of rulers to confine this right within the narrowest limits possible. Wherever standing armies are kept up, and when the right of the people to keep and bear arms is, under any color or pretext whatsoever, prohibited, liberty, if not already annihilated, is on the brink of destruction." -- Henry St. George Tucker (in Blackstone's Commentaries) From jack@oratrix.nl Wed Jun 7 22:47:01 2000 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 07 Jun 2000 23:47:01 +0200 Subject: [Python-Dev] hey, who broke the array module? In-Reply-To: Message by Guido van Rossum , Thu, 18 May 2000 15:05:45 -0700 , <200005182205.PAA12830@cj20424-a.reston1.va.home.com> Message-ID: <20000607214706.65CB2D8397@oratrix.oratrix.nl> Recently, Guido van Rossum said: > > On Thu, May 18, 2000 at 12:01:16PM +0200, Jack Jansen wrote: > > > > I broke it with my patches to test overflow for some of the PyArg_Parse > *() > > > > formatting characters. The upshot of testing for overflow is that now t > hose > > > > formatting characters ('b', 'h', 'i', 'l') enforce signed-ness or > > > > unsigned-ness as appropriate (you have to know if the value is signed o > r > > > > unsigned to know what limits to check against for overflow). Two > > > > possibilities presented themselves: > > > > > > I think this is a _very_ bad idea. I have a few thousand (literally) rout > ines > > > calling to Macintosh system calls that use "h" for 16 bit flag-word value > s, > > > and the constants are all of the form > > > > > > kDoSomething = 0x0001 > > > kDoSomethingElse = 0x0002 > > > ... > > > kDoSomethingEvenMoreBrilliant = 0x8000 > > > > > > I'm pretty sure other operating systems have lots of calls with similar > > > problems. I would strongly suggest using a new format char if you want > > > overflow-tested integers. > > > > Sigh. What do you think Guido? This is your call. > > > > 1. go back to no bounds testing > > 2. bounds check for [SHRT_MIN, USHRT_MAX] etc (this would allow signed and > > unsigned values but is sort of false security for bounds checking) > > 3. keep it the way it is: 'b' is unsigned and the rest are signed > > 4. add new format characters or a modifying character for signed and unsign > ed > > versions of these. > > Sigh indeed. Ideally, we'd introduce H for unsigned and then lock > Jack in a room with his Macintosh computer for 48 hours to fix all his > code... Hmm, hmm. As stated before I'm not too fond of this as it is a gratuitous change that breaks lots of things (not only in Mac modules: the array module was what started this discussion, test_cPickle and test_pkg crash, socketmodule, os.stat() and I assume all code that uses structmodule will also have to be looked at, and quite possibly there's a lot more) and for which I don't really see all that much benefit. As a datapoint: a quick search for 8-digit hex numbers starting with digit 8-F and not suffixed with an L throughout the Python files in the distribution found a stunning 464 matches. Add another 1147 4-digit hex numbers with the sign bit on and there are an awful lot of candidates for breaking... -- 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 gmcm@hypernet.com Wed Jun 7 22:59:20 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Wed, 7 Jun 2000 17:59:20 -0400 Subject: [Python-Dev] Package ambiguities In-Reply-To: References: <393eb52b.47053339@post.demon.co.uk> Message-ID: <1251707300-11412775@hypernet.com> Ka-Ping wrote: > On Wed, 7 Jun 2000, Andy Robinson wrote: > > We hit some very weird behaviour recently while setting up a > > package hierarchy. Robin Becker managed to distil this into a > > simple example. Can anyone shed any light on what is happening > > below? Is Python behaving as it should? [snip entirely correct analysis] > The solution is to avoid directly running scripts that are > inside packages; the confusion is produced by the fact that > you're running "test.py" from within the A/ directory. I disagree with the moral. If test.py uses "import A.parent" and changes references accordingly, it works. So my version of the moral is that import * is EVIL. Not only that, but relative imports are EVIL. This is what I meant when I said (in reply to Greg Wilson's inquiry about package structures) that there are some very bad precedents getting set. Doing this junk (usually in __init__.py) not only makes your package fragile, it also makes the package structure mysterious to the user (who's a developer - making things mysterious to him/her is just making both your lives harder!). If you want to make it friendly to lazy coders, then something like: import A.parent Parent = A.parent.Parent also works, (leaving references as Parent). I'm not terribly fond of this, either, but at least the coder has a reasonable hope of tracking down what "Parent" actually is. I'm not necessarily yelling at you, Andy. It seems that most package developers are going down this slope. It stinks. - Gordon From jeremy@beopen.com Wed Jun 7 23:06:29 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Wed, 7 Jun 2000 18:06:29 -0400 (EDT) Subject: [Python-Dev] Package ambiguities In-Reply-To: <1251707300-11412775@hypernet.com> References: <393eb52b.47053339@post.demon.co.uk> <1251707300-11412775@hypernet.com> Message-ID: <14654.51045.18807.74677@localhost.localdomain> Gordon's comments are on the money. An import in a module inside a package should be fully qualified. I'd put that in the style guide if it were up to me (and, of course, it's not). Jeremy From bwarsaw@python.org Wed Jun 7 23:38:02 2000 From: bwarsaw@python.org (Barry A. Warsaw) Date: Wed, 7 Jun 2000 18:38:02 -0400 (EDT) Subject: [Python-Dev] Package ambiguities References: <393eb52b.47053339@post.demon.co.uk> <1251707300-11412775@hypernet.com> <14654.51045.18807.74677@localhost.localdomain> Message-ID: <14654.52938.139406.371556@anthem.concentric.net> >>>>> "JH" == Jeremy Hylton writes: JH> Gordon's comments are on the money. An import in a module JH> inside a package should be fully qualified. I'd put that in JH> the style guide if it were up to me (and, of course, it's JH> not). I concur on both points. BTW, one of the Things I'd Like To Do, is update and flesh out the style guide. It's incomplete in places and out of date in others. If someone else has the gumption to lead this effort, I'd be happy to send my comments instead. -Barry From Ka-Ping Yee Wed Jun 7 23:39:28 2000 From: Ka-Ping Yee (Ka-Ping Yee) Date: Wed, 7 Jun 2000 15:39:28 -0700 (PDT) Subject: [Python-Dev] Package ambiguities In-Reply-To: <1251707300-11412775@hypernet.com> Message-ID: On Wed, 7 Jun 2000, Gordon McMillan wrote: > I disagree with the moral. > > If test.py uses "import A.parent" and changes references > accordingly, it works. Correct. Well, maybe there are two things going on here. I agree that import * isn't usually a very good idea. However, notice that the problem occurs even if the first line of test.py is "import parent" (no star). When you talk about changing references accordingly, the real issue is referencing "A.parent" rather than "parent". In fact, if you change the first line to "from A.parent import *" (not that i am advocating this!) -- it works. In short: from parent import * ... Parent doesn't work import parent ... parent.Parent doesn't work from A.parent import * ... Parent works import A.parent ... A.parent.Parent works The first two cases -- attempting to import "parent" -- are only made possible by the fact that we're executing test.py from within the A/ directory, and hence the confusion. This problem is an "advanced" version of a simpler issue which a friend of mine discovered and complained about recently to me: the __main__ vs. module-name conflict. Allow me to paraphrase his example. Exhibit A: ---- spam.py ---- import eggs def go(): print "was", eggs.a eggs.a = 3 print "now", eggs.a ---- eggs.py ---- import spam a = 1 def go(): spam.go() print "finally", a if __name__ == "__main__": go() --- watch what happens ---- % python eggs.py was 1 now 3 finally 1 % python >>> import eggs >>> eggs.go() was 1 now 3 finally 3 Exhibit B: ---- one.py ---- import two def go(): pass ---- two.py ---- import one one.go() ---- watch what happens ---- % python one.py % python two.py Traceback (innermost last): File "two.py", line 1, in ? import one File "./one.py", line 1, in ? import two File "./two.py", line 2, in ? one.go() AttributeError: go Exit 1 % python >>> import one Traceback (innermost last): File "", line 1, in ? File "./one.py", line 1, in ? import two File "./two.py", line 2, in ? one.go() AttributeError: go >>> import two >>> The facts that eggs.a appears to behave differently in Exhibit A, and that one.py can be run but two.py cannot, yet "two" can be imported and "one" cannot, in Exhibit B, both result from the duplication namespaces in __main__ and in a module. Normally, this only affects the main file that you are running, the one with the __main__ namespace. However, attempting to run scripts in package directories allows this problem to propagate further into the duplication of other modules: __main__ imports parent which imports child A.test imports A.parent which imports A.child ...and that can cause duplicate classes all over the place, which is what happened to Andy. My friend was quite irked by the existence of __main__, citing it as the culprit for this duplication. But naturally Python can't always know the name of the script being run -- in the case of a file ending in .py, perhaps, it's easy, but the script might come from a pipe, for example. So eliminating __main__ doesn't seem like a feasible response. Depending how "real" you consider this problem, leaving things as they are and instructing people in the discipline of keeping modules and scripts separated may be the best response. I bet this crops up all the time in those "testing" sections of modules that use the 'if __name__ == "__main__"' convention, though... -- ?!ng "Computers are useless. They can only give you answers." -- Pablo Picasso From petrilli@amber.org Wed Jun 7 23:51:50 2000 From: petrilli@amber.org (Christopher Petrilli) Date: Wed, 7 Jun 2000 18:51:50 -0400 Subject: [Python-Dev] Package ambiguities In-Reply-To: <14654.52938.139406.371556@anthem.concentric.net>; from bwarsaw@python.org on Wed, Jun 07, 2000 at 06:38:02PM -0400 References: <393eb52b.47053339@post.demon.co.uk> <1251707300-11412775@hypernet.com> <14654.51045.18807.74677@localhost.localdomain> <14654.52938.139406.371556@anthem.concentric.net> Message-ID: <20000607185150.A29156@trump.amber.org> Barry A. Warsaw [bwarsaw@python.org] wrote: > > >>>>> "JH" == Jeremy Hylton writes: > > JH> Gordon's comments are on the money. An import in a module > JH> inside a package should be fully qualified. I'd put that in > JH> the style guide if it were up to me (and, of course, it's > JH> not). > > I concur on both points. BTW, one of the Things I'd Like To Do, is > update and flesh out the style guide. It's incomplete in places and > out of date in others. If someone else has the gumption to lead this > effort, I'd be happy to send my comments instead. Something we futzed with at Digital Creations was "commentable" or discussable web pages. This would be a great use for this. If you took and made each basic topic/issue a page, and let people "discuss" them. A nice threaded discussion could add a lot of insight. This is versus a wiki where it's more "free for all", which isn't really appropraiate for a "guide". Chris -- | Christopher Petrilli | petrilli@amber.org From pingster@ilm.com Wed Jun 7 23:48:29 2000 From: pingster@ilm.com (Ka-Ping Yee) Date: Wed, 7 Jun 2000 15:48:29 -0700 (PDT) Subject: [Python-Dev] Package ambiguities In-Reply-To: <20000607185150.A29156@trump.amber.org> Message-ID: On Wed, 7 Jun 2000, Christopher Petrilli wrote: > Something we futzed with at Digital Creations was "commentable" or > discussable web pages. This would be a great use for this. If you > took and made each basic topic/issue a page, and let people "discuss" > them. A nice threaded discussion could add a lot of insight. This > is versus a wiki where it's more "free for all", which isn't really > appropraiate for a "guide". Well, y'all could go nuts marking up the style guide with Crit. http://crit.org/ ...or marking up anything else on the whole Web, for that matter. :) -- ?!ng "To be human is to continually change. Your desire to remain what you are is what ultimately limits you." -- The Puppet Master, Ghost in the Shell From jeremy@beopen.com Thu Jun 8 00:00:36 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Wed, 7 Jun 2000 19:00:36 -0400 (EDT) Subject: [Python-Dev] Package ambiguities In-Reply-To: References: <1251707300-11412775@hypernet.com> Message-ID: <14654.54292.711289.254224@localhost.localdomain> >In fact, if you change the first line to "from A.parent import *" >(not that i am advocating this!) -- it works. In short: > > from parent import * ... Parent doesn't work > import parent ... parent.Parent doesn't work > > from A.parent import * ... Parent works > import A.parent ... A.parent.Parent works One other possibility that ought to work (?) from A import parent Jeremy From gmcm@hypernet.com Thu Jun 8 00:47:47 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Wed, 7 Jun 2000 19:47:47 -0400 Subject: [Python-Dev] Package ambiguities In-Reply-To: References: <1251707300-11412775@hypernet.com> Message-ID: <1251700795-11803988@hypernet.com> Ka-Ping wrote: > ... In short: > > from parent import * ... Parent doesn't work > import parent ... parent.Parent doesn't work > > from A.parent import * ... Parent works > import A.parent ... A.parent.Parent works Right. That's why I cast relative imports as evil. > This problem is an "advanced" version of a simpler issue > which a friend of mine discovered and complained about > recently to me: the __main__ vs. module-name conflict. This comes up a whole lot. In those periods where I have the time, energy and patience to monitor c.l.py closely, I've seen this come up 4 or 5 times in one week. Almost always in conjunction with import *. I can live with explaining how __main__ is special. That's one of those "you only have to explain it once" problems. But the import * problems (name hiding, the fact that assignments aren't seen) and relative imports are things that come up over and over again, and trip up even experienced people (and them more than once). - Gordon From gstein@lyra.org Thu Jun 8 03:30:14 2000 From: gstein@lyra.org (Greg Stein) Date: Wed, 7 Jun 2000 19:30:14 -0700 Subject: [Python-Dev] Idea: emulating _locale In-Reply-To: <393E2304.4BE8CDE0@lemburg.com>; from mal@lemburg.com on Wed, Jun 07, 2000 at 12:25:08PM +0200 References: <393E2304.4BE8CDE0@lemburg.com> Message-ID: <20000607193014.P3348@lyra.org> On Wed, Jun 07, 2000 at 12:25:08PM +0200, M.-A. Lemburg wrote: >... > Peter Funk wrote: >... > > > + ### C lib locale APIs > > > + > > > + from _locale import * > > > > Wouldn't it be clever to provide some dummy stubs on those platforms, where > > the _locale module was not enabled? > > > > try: > > from _locale import * > > except: > > def setlocale(.... > > def localeconv(.... > > ... > > > > Especially the MacOS 1.5.2 release provided by Jack Jansen was > > compiled without '_locale'. And at least in Python 1.6a2 '_locale' > > is still disabled per default in 'Modules/Setup.in'. I didn't had > > a look into the current CVS though, so this may have changed. > > > > I think the name aliasing tables might be also useful on those > > systems lacking locale support in their C-library. > > setlocale and localeconv are ANSI C and Python requires an ANSI C > compiler, so there should be no problem (at least in theory). > > If there is a problem, adding the missing symbols would > be no problem: the APIs could always report locale 'C' > and its numeric settings. An ANSI C compiler and the ANSI C library are very different. Just because Python requires an ANSI compiler (or close to it), does NOT mean that we can or should depend upon particular elements in the library. IMO, we should follow Peter's advice and have stubs for the platforms where _locale is not built. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Thu Jun 8 03:35:37 2000 From: gstein@lyra.org (Greg Stein) Date: Wed, 7 Jun 2000 19:35:37 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Objects unicodeobject.c,2.21,2.22 In-Reply-To: <200006070913.CAA18060@slayer.i.sourceforge.net>; from lemburg@slayer.i.sourceforge.net on Wed, Jun 07, 2000 at 02:13:24AM -0700 References: <200006070913.CAA18060@slayer.i.sourceforge.net> Message-ID: <20000607193537.Q3348@lyra.org> On Wed, Jun 07, 2000 at 02:13:24AM -0700, Marc-Andre Lemburg wrote: > Update of /cvsroot/python/python/dist/src/Objects > In directory slayer.i.sourceforge.net:/tmp/cvs-serv17917/Objects > > Modified Files: > unicodeobject.c > Log Message: > Marc-Andre Lemburg : > Change the default encoding to 'ascii' (it was previously > defined as UTF-8). > > Note: The implementation still uses UTF-8 to implement > the buffer protocol, so C APIs will still see UTF-8. This > is on purpose: rather than fixing the Unicode implementation, > the C APIs should be made Unicode aware. I'm a little confused on where this gets applied. Is this when somebody says "str(unicode_ob)", they get back ASCII rather than UTF-8? Or is this when somebody says "unicode(str)" and we expect to be ASCII? Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Thu Jun 8 04:06:24 2000 From: gstein@lyra.org (Greg Stein) Date: Wed, 7 Jun 2000 20:06:24 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils/command sdist.py,1.25,1.26 In-Reply-To: <200006080008.RAA15980@slayer.i.sourceforge.net>; from gward@slayer.i.sourceforge.net on Wed, Jun 07, 2000 at 05:08:17PM -0700 References: <200006080008.RAA15980@slayer.i.sourceforge.net> Message-ID: <20000607200624.R3348@lyra.org> On Wed, Jun 07, 2000 at 05:08:17PM -0700, Greg Ward wrote: > Update of /cvsroot/python/distutils/distutils/command > In directory slayer.i.sourceforge.net:/tmp/cvs-serv15881 > > Modified Files: > sdist.py > Log Message: > Made all debug output go through the 'debug_print()' method instead of > directly printing to stdout. This was a bit more work than it sounds like > it should have been: > * turned 'select_pattern()' and 'exclude_pattern()' from functions into > methods, so they can refer to 'self' to access the method You wouldn't have to do this if you make debug_print() a function. There is nothing in debug_print() that requires "self", so its existence as a method is suspect in the first place. Considering the fallout changes, I'd say move debug_print() to a plain function (in "utils"). Unless you were planning on more stuff in there; if so, then a comment in debug_print would be nice. >... > *************** > *** 297,301 **** > if (cur_dir == dir and > (pattern_re is None or pattern_re.match (cur_base))): > ! print "removing %s" % self.files[i] > del self.files[i] > > --- 298,302 ---- > if (cur_dir == dir and > (pattern_re is None or pattern_re.match (cur_base))): > ! self.debug_print("removing %s" % self.files[i]) > del self.files[i] Gah... "pattern_re.match (cur_base)" ... You do realize that God intended there to be no spaces between a function name and the opening paren? Heretic! :-) Really -- I have noticed this throughout a lot of the distutils code. That space in there is really awful. It reduces the "binding" of the name to the paren, which changes the meaning during a quick read. Put another way: when you skim code, NAME( is a function call and NAME ( is something else. A space after a name usually indicates the name is participating in an expression, rather than being used as a function name. Then, you hit the paren and go "what the heck? oh. a function call." Please... can they be removed? Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Thu Jun 8 05:05:55 2000 From: gstein@lyra.org (Greg Stein) Date: Wed, 7 Jun 2000 21:05:55 -0700 Subject: [Python-Dev] release forms? (was: [Patches] New sys method to return total reference count in debug builds.) In-Reply-To: ; from moshez@math.huji.ac.il on Wed, Jun 07, 2000 at 05:33:10PM +0300 References: <20000607101146.D5559@ludwig.cnri.reston.va.us> Message-ID: <20000607210555.X3348@lyra.org> On Wed, Jun 07, 2000 at 05:33:10PM +0300, Moshe Zadka wrote: > On Wed, 7 Jun 2000, Greg Ward wrote: > > > CNRI has absolutely no moral right to it (although probably some legal > > right), I'd prefer to sign it away to Guido. Or optionally, to some > > legal fiction that represents the Python community; preferably *not* the > > Python Consortium, as long as CNRI is in any way connected. > > Who's in charge of the PSA? CNRI Effectively, the PSA is a legal fiction for collecting donations to further the development of Python. The Consortium is similar, but members have the actual/explicit capability to steer Python's development. I believe this ability to steer the development is (was?) rooted in the fact that CNRI employed Guido. I have no idea how that will work now -- the "steering" will (essentially) have to rely entirely on Guido's good graces. Guido is an excellent listener to people's needs, so there is no immediate problem here. > Or should we form *another* non-profit, and sign it over to it? The Apache Software Foundation is already a legal, formed, non-profit corporation. If the desire is to transfer copyright to a non-profit, then I'd recommend reusing the ASF rather than trying to start a new one. Recognize that running a company (even a non-profit) is not a "zero cost" item. Somebody would have to put that time in. CNRI is also non-profit, but its members/board/directors/etc are not as Open Source minded as the ASF. > (Personally, I couldn't care less who I transfer copyright over my Python > contributions to -- I'd put it in the public domain if that's what it > took) As Barry said: license and copyright are different. Since you own the copyright, then you *can* put it into the public domain Right Now. I've done that with some of my modules (e.g. qp_xml and imputil). Here is the header from qp_xml.py: # # qp_xml: Quick Parsing for XML # # Written by Greg Stein. Public Domain. # No Copyright, no Rights Reserved, and no Warranties. # Fun, huh? :-) On the other hand, I have given Guido two pieces of code: httplib.py and davlib.py: # # DAV client library # # Copyright (C) 1998-1999 Guido van Rossum. All Rights Reserved. # Written by Greg Stein. Given to Guido. Licensed using the Python license. # Oh. I need to update his copyright year :-) Want to know something really funny? Presuming my httplib.py goes into the Python distribution, that will be the first piece of code that Guido truly owns in Python. All the other code he wrote is owned by CWI or CNRI.... Cheers, -g -- Greg Stein, http://www.lyra.org/ From fredrik@pythonware.com Thu Jun 8 09:30:39 2000 From: fredrik@pythonware.com (Fredrik Lundh) Date: Thu, 8 Jun 2000 10:30:39 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils/command sdist.py,1.25,1.26 References: <200006080008.RAA15980@slayer.i.sourceforge.net> <20000607200624.R3348@lyra.org> Message-ID: <009501bfd123$d4b2c750$0500a8c0@secret.pythonware.com> greg wrote: > Gah... "pattern_re.match (cur_base)" ... >=20 > You do realize that God intended there to be no spaces between a = function > name and the opening paren? Heretic! http://www.python.org/doc/essays/styleguide.html ... I hate whitespace in the following places:=20 ... Immediately before the open parenthesis that starts the argument list of a function call, as in spam (1). Always write this as = spam(1). ... Don't bother to argue with me on any of the above ... From andy@reportlab.com Thu Jun 8 09:42:46 2000 From: andy@reportlab.com (Andy Robinson) Date: Thu, 8 Jun 2000 09:42:46 +0100 Subject: [Python-Dev] Package Style Guide In-Reply-To: <20000608030555.532221CDEF@dinsdale.python.org> Message-ID: Thanks for all the replies. We really need a 'style guide' on package use, so I hope this example can be thrashed out and used to help others. We need to decide something and release next week, and also provide good docs for other users who will be new to Python. Apart from the ambiguity, which was a surprise but which we can work around, I have some general questions on the "right thing". Here are my examples: 1. use of __init__ to save users work ------------------------------------ ReportLab has a subpackage called 'platypus' which we have just reorganized and not yet released. The division into subpackages is clear - each exposes a different kind of functionality - but the division of each package into modules is based on keeping a sane length for each and not on providing a friendly user interface. reportlab pdfgen canvas.py defines class Canvas textobject.py defines class TextObject pathobject.py defines class PathObject platypus (the same problem, but 3x worse) lib (loads of modules, all independent) We reached a point where users need to import eight or ten classes to do useful work and were having to put eight or ten different import lines at the top of every script. This just feels dumb and wrong. So, the 'least messy' idea was to put __init__.py methods in each subpackage which explicitly import what they need. (We have not used "import *") ---reportlab/pdfgen/__init__.py-------- from canvas import Canvas from textobject.py import TextObject from pathobject.py impory PathObject Then users can just do: from reportlab.pdfgen import Canvas, PathObject, TextObject It seems that this (a) makes life easier for users, and (b) gives us freedom to refactor code as it grows, without changing the user interface. Is this style evil? If so, why? 2. Ambiguities running scripts within package --------------------------------------------- We have various test functions scattered throughout our distribution. A control script iterates through the lot and kicks them off before every release, executing everything with an 'if __name__=='__main__' handler. If these were standalone scripts just for testing, they could import "reportlab.platypus.tables" or whatever. But if I just want to put a test routine at the end of "reportlab.platypus.tables" then I seem destined to run into exactly the ambiguity outlined before. Should test scripts all be moved out of the package? Indeed, is Python behaving the way it ought to? 3. Preferred subpackage import technique ---------------------------------------- I have two scripts 'spam.py' and 'eggs.py' in subpackage 'A.B'. spam imports eggs. Should it say... import eggs or... import A.B.eggs? Both work sometimes, but can lead to different behavious sometimes. Which is the preferred style? Thanks, Andy Robinson From pf@artcom-gmbh.de Thu Jun 8 10:35:14 2000 From: pf@artcom-gmbh.de (Peter Funk) Date: Thu, 8 Jun 2000 11:35:14 +0200 (MEST) Subject: [Python-Dev] Package Style Guide In-Reply-To: from Andy Robinson at "Jun 8, 2000 9:42:46 am" Message-ID: Hi Andy, > Thanks for all the replies. > We really need a 'style guide' on package use, On 'import', packages and modules: ---------------------------------- You should definitely have a look at the approach used by Greg McFarlane in his 'Pmw' package. In particular at his PmwLoader class and the Pmw.def. For my own project I've simplified and somewhat generalized his approach to dynamic and lazy importing. I posted a preliminary implemantation of this to comp.lang.python a while ago but didn't got much feedback. May be due to fact, that I had to repost the thing, because the TABs went wrong in the first try :-( [...] > Is this style evil? If so, why? I believe it will get really hard to come up with a 'namespace style guide' which everybody can aggree on. But who cares: let's start a rant: --> IMO 'from ... import ...' is EVIL and its use should be banned! <-- Why? Because if software becomes bigger (> 100k LOC), these unqualified names definitely become a maintaince nightmare, since you didn't know what names are defined in the module you are currently staring at and what names come from the "outside world". I believe Python inherited two of its three forms of import syntax at least in part from its anchestors Modula-2 and Modula-3. My perception of this import-problem may be blurred by programming in Modula-2 in our company since 1985, where the code base now is about ~1 Mio. LOC. Some of the older code contains still modules using a lot of 'FROM foobar IMPORT ....;' lines in the header. These have usually been harder to read and understand by new employees than those having 'IMPORT foobar;' in the header and than using 'foobar.component' everywhere in the code body below. from .... import * is *EVEN MORE EVIL*. Well: at least if people use 'from' to import arbitrary objects and classes. Using 'from package.subpackage import module' is an idiom, with which I can live with comfortably. > Should test scripts all be moved out of the package? This would defeat the use of Tim Peters wonderful 'doctest' module. I'm still thinking, 'doctest' should be made part of the standard library in order to give the publicity this elegant approach deserves. Regards, Peter From Vladimir.Marangozov@inrialpes.fr Thu Jun 8 11:27:10 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Thu, 8 Jun 2000 12:27:10 +0200 (CEST) Subject: [Python-Dev] revamped Python web site In-Reply-To: <20000607174148.A6801@thyrsus.com> from "Eric S. Raymond" at Jun 07, 2000 05:41:48 PM Message-ID: <200006081027.MAA02445@python.inrialpes.fr> [Jeremy Hylton] > > Say a startup company decided to put some resources behind the Python > Web site -- a full-time Web master, some content developers, etc. > What would you have them do? What could be done to open up the site > to the community and make it more responsive to developers and users? > What's your wish list for content, services, etc.? The content is good. Some wishes on its presentation, not taking into account any cosmetic changes. With my webmaster's hat, I would say: 1. Make the content accessible, i.e. compliant to the standards HTML tidy does a pretty good job in cleaning up existing Web pages I would suggest sticking with valid XHTML 1.0 transitional or HTML 4.x transitional. 2. Use CSS -- not too much, though, given its growing but still limited support. I am using myself parts of CSS1. My approach is to use styles *and* attributes (which is redundant, for now). Browsers that understand styles would honor them, while those that don't would take into account the attributes. The aim is to have the same end result. With the evolution of the browsers, the attributes would disappear. A compromise that introduces styles smoothly. 3. Have a comprehensible site map for direct access to the major topics. I tend to like ours which is convenient for small to medium sized sites (http://www.inrialpes.fr/plansite.html) 4. Do not use frames, do not use JavaScript or similar, do not use anything that hurts content accessibility. [Eric S. Raymond] > > My top wishlist item is "Burn all your GIFs". This seems to be an important symbol for an organization with an Open Source spirit. Hopefully, a gif2png batch processing should make things easier. -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From gstein@lyra.org Thu Jun 8 12:43:24 2000 From: gstein@lyra.org (Greg Stein) Date: Thu, 8 Jun 2000 04:43:24 -0700 Subject: [Python-Dev] Package Style Guide In-Reply-To: ; from pf@artcom-gmbh.de on Thu, Jun 08, 2000 at 11:35:14AM +0200 References: Message-ID: <20000608044324.L3348@lyra.org> On Thu, Jun 08, 2000 at 11:35:14AM +0200, Peter Funk wrote: >... > > Is this style evil? If so, why? > > I believe it will get really hard to come up with a 'namespace style guide' > which everybody can aggree on. But who cares: let's start a rant: > > --> IMO 'from ... import ...' is EVIL and its use should be banned! <-- You are being overly strict here. I use this all the time: from module import submodule ... submodule.Class() or even from module.submodule import subsub ... subsub.Blargle() In other words, "from package import module" is a Fine Thing. It can simplify your code without hiding where the symbols come from. In general, I agree with you: importing symbols from a module into your namespace is a Bad Thing. Cheers, -g -- Greg Stein, http://www.lyra.org/ From fdrake@beopen.com Thu Jun 8 13:37:04 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 8 Jun 2000 08:37:04 -0400 (EDT) Subject: [Python-Dev] revamped Python web site In-Reply-To: <200006081027.MAA02445@python.inrialpes.fr> References: <20000607174148.A6801@thyrsus.com> <200006081027.MAA02445@python.inrialpes.fr> Message-ID: <14655.37744.352128.72841@cj42289-a.reston1.va.home.com> Vladimir Marangozov writes: > 2. Use CSS -- not too much, though, given its growing but still limited > support. I am using myself parts of CSS1. My approach is to use styles > *and* attributes (which is redundant, for now). Browsers that understand > styles would honor them, while those that don't would take into account > the attributes. The aim is to have the same end result. With the evolution > of the browsers, the attributes would disappear. The approach to CSS I've taken with the documentation is to use attributes for anything that's really needed to make the presentation readable and then an external CSS stylesheet for everything else. This seems like a reasonable approach to me, and avoids including too much duplicate information. This also seems like the best way to maintain support for older browsers. Perhaps we should collect browser statistics on python.org so we'll know how many "legacy" browsers are in use? I would be surprised if many of the text-mode browsers support CSS well (and there are several being actively worked on these days, so please don't tell me they don't count!). > 4. Do not use frames, do not use JavaScript or similar, do not use anything > that hurts content accessibility. I do have some JavaScript on python.org, but it's only to make data entry in a form a little easier by making adjustments to related fields, so it remains completely operational without JavaScript. I don't think there's currently any required JavaScript. And I have yet to see a frame, thank goodness! [Eric S. Raymond] > > My top wishlist item is "Burn all your GIFs". Is it more important than accessibility? This is a real issue for legacy browsers, especially on minority platforms. One of the big wins for Python is that it is as portable as it is. Does that matter if information is hard to get to? A good reason to avoid using images for anything that isn't cosmetic! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From pf@artcom-gmbh.de Thu Jun 8 13:28:11 2000 From: pf@artcom-gmbh.de (Peter Funk) Date: Thu, 8 Jun 2000 14:28:11 +0200 (MEST) Subject: [Python-Dev] Package Style Guide In-Reply-To: <20000608044324.L3348@lyra.org> from Greg Stein at "Jun 8, 2000 4:43:24 am" Message-ID: Hi Greg, [me] > > --> IMO 'from ... import ...' is EVIL and its use should be banned! <-- [Greg Stein]: > You are being overly strict here. I use this all the time: > > from module import submodule > ... > submodule.Class() > > or even > > from module.submodule import subsub > ... > subsub.Blargle() Okay. Later in my rant I wrote: < Well: at least if people use 'from' to import arbitrary objects and < classes. Using 'from package.subpackage import module' is an idiom, < with which I can live with comfortably. [Greg Stein]: > In other words, "from package import module" is a Fine Thing. It can > simplify your code without hiding where the symbols come from. Yes, you are right. But if you put the facade pattern[*] into use within such packages, this will even simplify your live, if you later have to redesign the internal substructure of your package. [*] Design patterns and especially the "facade pattern" were AFAIK introduced in the so called "Gang of four" book: "Design Patterns - Elements of Reusable Object-Oriented Software", Addison Wesley, 1995. The somewhat similar "whole part" design pattern is discussed in the book "A System of Patterns" written by Buschmann, Meunier, Rohnert, Sommerlad, Stal; published by John Wiley & Sons, New York; 1996; ISBN 0 471 95869 7 > In general, I agree with you: importing symbols from a module into your > namespace is a Bad Thing. Fine. Consensus gives a warm and fuzzy feeling. ;-) Regards, Peter From esr@thyrsus.com Thu Jun 8 13:53:51 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Thu, 8 Jun 2000 08:53:51 -0400 Subject: [Python-Dev] revamped Python web site In-Reply-To: <14655.37744.352128.72841@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Thu, Jun 08, 2000 at 08:37:04AM -0400 References: <20000607174148.A6801@thyrsus.com> <200006081027.MAA02445@python.inrialpes.fr> <14655.37744.352128.72841@cj42289-a.reston1.va.home.com> Message-ID: <20000608085351.A9299@thyrsus.com> Fred L. Drake, Jr. : > [Eric S. Raymond] > > > > My top wishlist item is "Burn all your GIFs". > > Is it more important than accessibility? This is a real issue for > legacy browsers, especially on minority platforms. One of the big > wins for Python is that it is as portable as it is. Does that matter > if information is hard to get to? Go check out the PNG site's census of PNG support in "legacy" browsers. Basically, as long as your PNGs don't use transparency or animation, you're fine. You've already had the good taste to eschew animation. I don't think you're using transparency anywhere that simply matteing the image on a white background won't fix it -- and gif2png has an option to do that. > A good reason to avoid using images for anything that isn't > cosmetic! I agree with that. -- Eric S. Raymond Sometimes the law defends plunder and participates in it. Sometimes the law places the whole apparatus of judges, police, prisons and gendarmes at the service of the plunderers, and treats the victim -- when he defends himself -- as a criminal. -- Frederic Bastiat, "The Law" From jeremy@beopen.com Thu Jun 8 14:58:42 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Thu, 8 Jun 2000 09:58:42 -0400 (EDT) Subject: [Python-Dev] release forms? (was: [Patches] New sys method to return total reference count in debug builds.) In-Reply-To: <20000607210555.X3348@lyra.org> References: <20000607101146.D5559@ludwig.cnri.reston.va.us> <20000607210555.X3348@lyra.org> Message-ID: <14655.42642.608768.433695@localhost.localdomain> >>>>> "GS" == Greg Stein writes: GS> On Wed, Jun 07, 2000 at 05:33:10PM +0300, Moshe Zadka wrote: >> On Wed, 7 Jun 2000, Greg Ward wrote: >> >> > CNRI has absolutely no moral right to it (although probably >> some legal > right), I'd prefer to sign it away to Guido. Or >> optionally, to some > legal fiction that represents the Python >> community; preferably *not* the > Python Consortium, as long as >> CNRI is in any way connected. >> >> Who's in charge of the PSA? GS> CNRI GS> Effectively, the PSA is a legal fiction for collecting donations GS> to further the development of Python. The Consortium is similar, GS> but members have the actual/explicit capability to steer GS> Python's development. I believe this ability to steer the GS> development is (was?) rooted in the fact that CNRI employed GS> Guido. I have no idea how that will work now -- the "steering" GS> will (essentially) have to rely entirely on Guido's good GS> graces. Guido is an excellent listener to people's needs, so GS> there is no immediate problem here. The description of the PSA isn't exactly right. The PSA FAQ has an official explanation, which may not be right either, but at least it's what CNRI wants you to think. (And it may be right; I don't mean to suggest a nefarious plot, just that the relationship is convoluted enough that the explanation could be wrong.) http://www.python.org/psa/FAQ.html An abbreviated version follows: |Where does the money from membership fees go and who pays the rest? | | The money goes towards the salary of those who maintain and | coordinate the Python web site, ftp server, mailing lists, | conference expenses etc.... The case for these expenditures is | that a seed community is being incubated. CNRI officers and | directors see proof of the existence of such a community from the | fact that some members of that community are willing to pay some | of their own money to foster the activity. | |Who funds Python's development? | PSA fees do not fund the Python development effort.... CNRI is no longer maintaining python.org, although it still owns the domain and maintains the equipment it runs on. The existence of a community should be obvious now, without the need for people to pay money to prove it. Jeremy From skip@mojam.com (Skip Montanaro) Thu Jun 8 15:08:13 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Thu, 8 Jun 2000 09:08:13 -0500 Subject: [Python-Dev] impact of cycle gc... Message-ID: <200006081408.JAA03136@beluga.mojam.com> I spent a little time poking around with a very simple test script (appended) that makes use of Neil's cycle gc patch. It measures the time it takes to instantiate and delete a cycle-producing instance 100,000 times (based upon a report in python-bugs). For vanilla 1.6a2 ("./configure" ; make") I got the following (last of six runs): memory usage @ start: 5560 clock: 1.33 elapsed: 1.34805500507 memory usage @ end: 18816 For 1.6a2 configured --with-cycle-gc ("./configure --with-cycle-gc ; make") I got the following (also the last of six runs): memory usage @ start: 5576 clock: 2.34 elapsed: 2.33785700798 memory usage @ end: 5576 I was very impressed with the memory usage, but dismayed at the increased execution time (about 75% more). Of course, this is a test script that is bound to show the potential performance penalty in the worst possible light. Maybe pystone will be more indicative of the performance hit we can expect from it. (There's a new one - pystone.py being a better indicator of true system performance than some other test script!) Plain: Pystone(1.1) time for 10000 passes = 1.76 This machine benchmarks at 5681.82 pystones/second --with-cycle-gc: Pystone(1.1) time for 10000 passes = 1.83 This machine benchmarks at 5464.48 pystones/second That suggests something more like a 4% performance penalty. I suspect that may be the lower limit. While I haven't looked at pystone recently, I doubt it creates any cyclic garbage. My next step will be to try it out on my development database server and see what happens. just-another-data-point-ly y'rs, -- Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ "We have become ... the stewards of life's continuity on earth. We did not ask for this role... We may not be suited to it, but here we are." - Stephen Jay Gould class fred: def __init__(self): self.indirectFunc = self.theFunc def theFunc(self): return "blah" def test(): f = fred() del f if __name__ == "__main__": import os, time, sys sys.stdout.write("memory usage @ start: ") sys.stdout.flush() os.system("ps auxww | egrep method | egrep -v egrep | awk '{print $5}'") t = time.clock(), time.time() for x in xrange(100000): test() print "clock:", time.clock()-t[0], "elapsed:", time.time()-t[1] sys.stdout.write("memory usage @ end: ") sys.stdout.flush() os.system("ps auxww | egrep method | egrep -v egrep | awk '{print $5}'") From gmcm@hypernet.com Thu Jun 8 15:48:01 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Thu, 8 Jun 2000 10:48:01 -0400 Subject: [Python-Dev] Package Style Guide In-Reply-To: References: <20000608030555.532221CDEF@dinsdale.python.org> Message-ID: <1251646781-15052905@hypernet.com> Andy wrote: > 1. use of __init__ to save users work [package structure] > reportlab > pdfgen > canvas.py defines class Canvas > textobject.py defines class TextObject > pathobject.py defines class PathObject > platypus > (the same problem, but 3x worse) > lib > (loads of modules, all independent) > ---reportlab/pdfgen/__init__.py-------- > from canvas import Canvas > from textobject.py import TextObject > from pathobject.py impory PathObject I would suggest that these not use relative names. from reportlab.pdfgen.canvas import Canvas will ensure that Canvas is only found in one way (no matter where the script is, or rather, what sys.path[0] evaluates to at import time). Your other choice is to disallow any scripts within reportlab/ and deliver 220 V shocks to any user who starts Python anyplace within reportlab/ (or otherwise lets any part of sys.path evaluate to anything within reportlab/). > Then users can just do: > from reportlab.pdfgen import Canvas, PathObject, TextObject > > It seems that this (a) makes life easier for users, and > (b) gives us freedom to refactor code as it grows, without > changing the user interface. Since you're doing this for "convenience", another option is to provide convenience methods: def newCanvas(): return reportlab.pdfgen.canvas.Canvas() > 2. Ambiguities running scripts within package > --------------------------------------------- > Should test scripts all be moved out of the package? > Indeed, is Python behaving the way it ought to? If you use relative imports, yes. But even so, you incur a risk in using relative imports (see above). And you only do it from laziness. So I say don't use relative imports. > 3. Preferred subpackage import technique > ---------------------------------------- > I have two scripts 'spam.py' and 'eggs.py' in > subpackage 'A.B'. spam imports eggs. > Should it say... > import eggs > or... > import A.B.eggs? You know what I'm going to say... - Gordon From mal@lemburg.com Thu Jun 8 15:48:49 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 08 Jun 2000 16:48:49 +0200 Subject: [Python-Dev] revamped Python web site References: <14654.48609.710990.321688@localhost.localdomain> Message-ID: <393FB251.6100175B@lemburg.com> Jeremy Hylton wrote: > > Say a startup company decided to put some resources behind the Python > Web site -- a full-time Web master, some content developers, etc. > What would you have them do? What could be done to open up the site > to the community and make it more responsive to developers and users? > What's your wish list for content, services, etc.? > > If you've got any ideas, please get back to me soon. Why not turn python.org into a Python portal site with all the jazz that goes with it, e.g. newsletters, browsable news forums for different news aspects (business news, new developments, press references, Python related meetings, etc.), customization of the information layout, email notification when things change, chat forums, a Python knowledge base, etc. etc. The reasoning is that Python is starting to go business and the site should reflect this move. As more companies start producing Python tools, I think it might even be worthwhile considering Python related marketing on the Python site, e.g. small banners, external links, etc. This would help finance the site and its administrators. As far as content goes, I think Python.org is hardly beatable :-) What's missing is some more service to push its fun factor which in return pushes Python's acceptance. Anyway, just a thought... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Thu Jun 8 15:54:01 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 08 Jun 2000 16:54:01 +0200 Subject: [Python-Dev] Package ambiguities References: <393eb52b.47053339@post.demon.co.uk> <1251707300-11412775@hypernet.com> <14654.51045.18807.74677@localhost.localdomain> Message-ID: <393FB389.893D20E3@lemburg.com> Jeremy Hylton wrote: > > Gordon's comments are on the money. An import in a module inside a > package should be fully qualified. I'd put that in the style guide if > it were up to me (and, of course, it's not). +1 from here :-) I usually write things like this: from mx.DateTime import now print 'The time is', now() If you don't do so, you'll run into strange problems, the most subtle one I've encountered is with pickled objects... if unpickled inside the same package they can cause the same module to be loaded *twice* with all the consequences attached to this (e.g. issubclass() no longer works). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Thu Jun 8 16:20:23 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 08 Jun 2000 17:20:23 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Objects unicodeobject.c,2.21,2.22 References: <200006070913.CAA18060@slayer.i.sourceforge.net> <20000607193537.Q3348@lyra.org> Message-ID: <393FB9B7.B93A7C61@lemburg.com> Greg Stein wrote: > > On Wed, Jun 07, 2000 at 02:13:24AM -0700, Marc-Andre Lemburg wrote: > > Update of /cvsroot/python/python/dist/src/Objects > > In directory slayer.i.sourceforge.net:/tmp/cvs-serv17917/Objects > > > > Modified Files: > > unicodeobject.c > > Log Message: > > Marc-Andre Lemburg : > > Change the default encoding to 'ascii' (it was previously > > defined as UTF-8). > > > > Note: The implementation still uses UTF-8 to implement > > the buffer protocol, so C APIs will still see UTF-8. This > > is on purpose: rather than fixing the Unicode implementation, > > the C APIs should be made Unicode aware. > > I'm a little confused on where this gets applied. Is this when somebody says > "str(unicode_ob)", they get back ASCII rather than UTF-8? Or is this when > somebody says "unicode(str)" and we expect to be ASCII? The buffer protocol is used for "s", "t" and "s#" argument parsing in C. Since these pass back pointers to internal buffers of the object which must be kept alive until the object is GCed, there's no easy way to change the encoding of that buffer. To play safe I left that buffer encoded in UTF-8 (the hash value is also computed from the UTF-8 encoding of the unicode value to make it compatible to ASCII 8-bit strings). Note that both str(unicode) and unicode(str) will use the default encoding. %-formatting and comparisons also use the default encoding. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Thu Jun 8 16:08:45 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 08 Jun 2000 17:08:45 +0200 Subject: [Python-Dev] Idea: emulating _locale References: <393E2304.4BE8CDE0@lemburg.com> <20000607193014.P3348@lyra.org> Message-ID: <393FB6FD.AB0124E2@lemburg.com> Greg Stein wrote: > > On Wed, Jun 07, 2000 at 12:25:08PM +0200, M.-A. Lemburg wrote: > >... > > Peter Funk wrote: > >... > > > > + ### C lib locale APIs > > > > + > > > > + from _locale import * > > > > > > Wouldn't it be clever to provide some dummy stubs on those platforms, where > > > the _locale module was not enabled? > > > > > > try: > > > from _locale import * > > > except: > > > def setlocale(.... > > > def localeconv(.... > > > ... > > > > > > Especially the MacOS 1.5.2 release provided by Jack Jansen was > > > compiled without '_locale'. And at least in Python 1.6a2 '_locale' > > > is still disabled per default in 'Modules/Setup.in'. I didn't had > > > a look into the current CVS though, so this may have changed. > > > > > > I think the name aliasing tables might be also useful on those > > > systems lacking locale support in their C-library. > > > > setlocale and localeconv are ANSI C and Python requires an ANSI C > > compiler, so there should be no problem (at least in theory). > > > > If there is a problem, adding the missing symbols would > > be no problem: the APIs could always report locale 'C' > > and its numeric settings. > > An ANSI C compiler and the ANSI C library are very different. Just because > Python requires an ANSI compiler (or close to it), does NOT mean that we can > or should depend upon particular elements in the library. Well, ok, it's POSIX.1 too, but... > IMO, we should follow Peter's advice and have stubs for the platforms where > _locale is not built. ...ok, since it doesn't hurt, I'll add some dummies to locale.py which return the same thing as the 'C' locale. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From pingster@ilm.com Thu Jun 8 18:10:46 2000 From: pingster@ilm.com (Ka-Ping Yee) Date: Thu, 8 Jun 2000 10:10:46 -0700 (PDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils/command sdist.py,1.25,1.26 In-Reply-To: <20000607200624.R3348@lyra.org> Message-ID: On Wed, 7 Jun 2000, Greg Stein wrote: > Gah... "pattern_re.match (cur_base)" ... > > You do realize that God intended there to be no spaces between a function > name and the opening paren? Heretic! [...] > Put another way: when > you skim code, NAME( is a function call and NAME ( is something else. A > space after a name usually indicates the name is participating in an > expression, rather than being used as a function name. Yesyesyes! This is an absolute rule for me (in other languages too: in C, for example, *always* a space between "if" or "for" and the open-paren). I colourize based on this. It's great -- the one green word on the line stands out; it's the verb, and that lets me know what's going on at a quick glance. (My "Principle of Syntax Highlighting" is to highlight not by what things are, but by what *role* they play. Defining occurrence of anything is a biggie. Comments and docstrings are coloured alike; docstrings are not data. And so on.) -- ?!ng From klm@digicool.com Thu Jun 8 19:38:32 2000 From: klm@digicool.com (Ken Manheimer) Date: Thu, 8 Jun 2000 14:38:32 -0400 (EDT) Subject: [Python-Dev] revamped Python web site In-Reply-To: <14654.48609.710990.321688@localhost.localdomain> Message-ID: On Wed, 7 Jun 2000, Jeremy Hylton wrote: > Say a startup company decided to put some resources behind the Python > Web site -- a full-time Web master, some content developers, etc. > What would you have them do? What could be done to open up the site > to the community and make it more responsive to developers and users? > What's your wish list for content, services, etc.? > > If you've got any ideas, please get back to me soon. Here's some suggestions - i put things more important to me closer to the top, more or less. 1. Delegation of sections to individuals or groups. Eg: - topic guides - particular people get management of areas. (Of course, i'd do this with zope, including zwiki pages as well as regular zope documents for the respective topic-guide managers to use in constructing their content - and for delegating or openning up portions of *their* sections to others...) - The humor page (i'm sad to see that languishing) - Other incidental stuff in the Documentation section of the current site 2. Community-contributed news and hints - portal-style membership/ contribution of news items, reviewed for release or rejection (maybe with community-based reviewers voting) 3. Vaults of parnassus already does this, but i'll still mention - Contributed software/docs/etc - managed similar to moderated news postings, but with classification/cataloguing of artifacts, ability for people to vote on desirability for ranking purposes 5. Jobs board - job postings possibly also managed with news-style reviewing process 6. Subscription to pages, to get notifcations when they change (probably batched, so people don't get too many as something is undergoing development). 7. Discussion "area" for coordinating and collecting logs of IRC-style chats when hot-topics arise that need rendezvous. 8. Open community wiki(s) for growing interesting little worlds (and with my new zwiki nesting-organization features, it may not be too chaotic). Ken klm@digicool.com From gvwilson@nevex.com Thu Jun 8 19:45:37 2000 From: gvwilson@nevex.com (Greg Wilson) Date: Thu, 8 Jun 2000 14:45:37 -0400 (EDT) Subject: [Python-Dev] revamped Python web site In-Reply-To: Message-ID: > Ken Manheimer said > 3. Vaults of parnassus already does this, but i'll still mention - > Contributed software/docs/etc - managed similar to moderated news > postings, but with classification/cataloguing of artifacts, ability for > people to vote on desirability for ranking purposes I'd like to see the Vaults, Starship, and other sub-sites folded into, or become subsections of, a larger Python site, so that I've got the same kind of one-stop shopping that CPAN gives me. Thanks, Greg From esr@thyrsus.com Thu Jun 8 19:54:45 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Thu, 8 Jun 2000 14:54:45 -0400 Subject: [Python-Dev] revamped Python web site In-Reply-To: ; from gvwilson@nevex.com on Thu, Jun 08, 2000 at 02:45:37PM -0400 References: Message-ID: <20000608145445.A10500@thyrsus.com> Greg Wilson : > > Ken Manheimer said > > 3. Vaults of parnassus already does this, but i'll still mention - > > Contributed software/docs/etc - managed similar to moderated news > > postings, but with classification/cataloguing of artifacts, ability for > > people to vote on desirability for ranking purposes > > I'd like to see the Vaults, Starship, and other sub-sites folded into, or > become subsections of, a larger Python site, so that I've got the same > kind of one-stop shopping that CPAN gives me. Second that. -- Eric S. Raymond Such are a well regulated militia, composed of the freeholders, citizen and husbandman, who take up arms to preserve their property, as individuals, and their rights as freemen. -- "M.T. Cicero", in a newspaper letter of 1788 touching the "militia" referred to in the Second Amendment to the Constitution. From gmcm@hypernet.com Thu Jun 8 19:57:51 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Thu, 8 Jun 2000 14:57:51 -0400 Subject: [Python-Dev] revamped Python web site In-Reply-To: References: <14654.48609.710990.321688@localhost.localdomain> Message-ID: <1251631791-15954519@hypernet.com> From Ken Manheimer's Python web site wishlist: > - The humor page (i'm sad to see that languishing) A weekly nude Tim Peters jpeg! - Gordon From fdrake@beopen.com Thu Jun 8 20:46:00 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 8 Jun 2000 15:46:00 -0400 (EDT) Subject: [Python-Dev] revamped Python web site In-Reply-To: <20000608085351.A9299@thyrsus.com> References: <20000607174148.A6801@thyrsus.com> <200006081027.MAA02445@python.inrialpes.fr> <14655.37744.352128.72841@cj42289-a.reston1.va.home.com> <20000608085351.A9299@thyrsus.com> Message-ID: <14655.63480.384525.129125@cj42289-a.reston1.va.home.com> Eric S. Raymond writes: > Go check out the PNG site's census of PNG support in "legacy" > browsers. Basically, as long as your PNGs don't use transparency or > animation, you're fine. You've already had the good taste to eschew Excellent! I'll review the list next week probably. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From jeremy@beopen.com Thu Jun 8 21:24:51 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Thu, 8 Jun 2000 16:24:51 -0400 (EDT) Subject: [Python-Dev] revamped Python web site In-Reply-To: <1251631791-15954519@hypernet.com> References: <14654.48609.710990.321688@localhost.localdomain> <1251631791-15954519@hypernet.com> Message-ID: <14656.275.83488.186898@localhost.localdomain> >>>>> "GM" == Gordon McMillan writes: >> From Ken Manheimer's Python web site wishlist: - The humor page >> (i'm sad to see that languishing) GM> A weekly nude Tim Peters jpeg! We were going to keep those on the pythonlabs.com internal site, but if Tim doesn't object... Jeremy From jeremy@beopen.com Thu Jun 8 22:19:49 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Thu, 8 Jun 2000 17:19:49 -0400 (EDT) Subject: [Python-Dev] impact of cycle gc... In-Reply-To: <200006081408.JAA03136@beluga.mojam.com> References: <200006081408.JAA03136@beluga.mojam.com> Message-ID: <14656.3573.754658.791617@localhost.localdomain> Skip, I don't have time today to look at your post in detail, but one thing you said rtiggered a pretty immediate response: We should worry more about the GC performance on examples like the one you posted, and less about pystone. pystone is a good benchmark for testing the overhead in cases when the garbage collector isn't invoked. There's so little memory allocation that nothing interesting happens. The GC patch ought to have no effect in this case. I suppose 4% is okay. The worry is about programs that allocate a lot of objects, even if they never create circular references. The compiler test is one example, because the parser tree consumes an enormous number of tuples and objects. I suspect big slowdowns like the one you posted just mean we don't know how to adjust the tuneable parameters. Jeremy From gstein@lyra.org Fri Jun 9 01:01:08 2000 From: gstein@lyra.org (Greg Stein) Date: Thu, 8 Jun 2000 17:01:08 -0700 Subject: [Python-Dev] revamped Python web site In-Reply-To: ; from gvwilson@nevex.com on Thu, Jun 08, 2000 at 02:45:37PM -0400 References: Message-ID: <20000608170108.B16880@lyra.org> On Thu, Jun 08, 2000 at 02:45:37PM -0400, Greg Wilson wrote: > > Ken Manheimer said > > 3. Vaults of parnassus already does this, but i'll still mention - > > Contributed software/docs/etc - managed similar to moderated news > > postings, but with classification/cataloguing of artifacts, ability for > > people to vote on desirability for ranking purposes > > I'd like to see the Vaults, Starship, and other sub-sites folded into, or > become subsections of, a larger Python site, so that I've got the same > kind of one-stop shopping that CPAN gives me. +1 on that! If python.org opens up (beyond what was possible w.r.t CNRI's security policy), then I see a lot of the impetus for separate sites, such as Starship and Parnassus, simply disappearing. While we're at it: Python-URL has some funny location that I can't ever remember. Providing a way for the organizers to publish those onto python.org (and maintain the archive there) would be good. If /F is still doing the daily URL, then it could go there, too... Cheers, -g -- Greg Stein, http://www.lyra.org/ From nascheme@enme.ucalgary.ca Fri Jun 9 02:29:00 2000 From: nascheme@enme.ucalgary.ca (Neil Schemenauer) Date: Thu, 8 Jun 2000 19:29:00 -0600 Subject: [Python-Dev] impact of cycle gc... Message-ID: <20000608192900.A21668@acs.ucalgary.ca> Just a few points and then I will get off python-dev. :) First of all, I don't think it is very meaningful to use leaking applications to do timing comparisons. The collector has be quite careful when freeing structures containing reference cycles. However, using something other than pystone is definitely a good idea. Here the pybench results for the latest patch: PYBENCH 0.6 Benchmark: b_nogc (rounds=4, warp=30) Tests: per run per oper. diff * ------------------------------------------------------------------------ BuiltinFunctionCalls: 286.25 ms 3.37 us -4.22% BuiltinMethodLookup: 367.50 ms 1.05 us -4.55% ConcatStrings: 368.37 ms 3.68 us +42.50% CreateInstances: 477.87 ms 17.07 us -4.45% CreateStringsWithConcat: 322.12 ms 2.42 us +10.27% DictCreation: 382.75 ms 3.83 us +1.29% ForLoops: 536.88 ms 80.73 us +0.99% IfThenElse: 432.75 ms 0.96 us -3.21% ListSlicing: 236.87 ms 104.12 us +11.73% NestedForLoops: 320.00 ms 1.28 us +0.16% NormalClassAttribute: 386.50 ms 0.97 us +0.00% PythonFunctionCalls: 477.87 ms 4.34 us -3.51% PythonMethodCalls: 379.12 ms 7.59 us -12.67% Recursion: 280.75 ms 33.70 us -0.88% SecondImport: 206.62 ms 12.41 us -5.76% SecondPackageImport: 216.75 ms 13.02 us -4.41% SecondSubmoduleImport: 279.25 ms 16.77 us -2.57% SimpleComplexArithmetic: 351.00 ms 2.39 us +0.72% SimpleDictManipulation: 320.75 ms 1.60 us -2.99% SimpleFloatArithmetic: 361.50 ms 0.99 us -20.37% SimpleIntFloatArithmetic: 336.00 ms 0.76 us +0.04% SimpleIntegerArithmetic: 328.38 ms 0.75 us -0.76% SimpleListManipulation: 312.88 ms 1.74 us -1.61% SimpleLongArithmetic: 308.75 ms 2.81 us +9.88% SmallLists: 470.13 ms 2.77 us -5.05% SmallTuples: 374.62 ms 2.34 us -15.74% SpecialClassAttribute: 384.00 ms 0.96 us -1.88% SpecialInstanceAttribute: 446.38 ms 1.12 us -2.75% StringSlicing: 315.50 ms 2.70 us +16.58% TryExcept: 585.37 ms 0.59 us -1.70% TryRaiseExcept: 312.75 ms 31.28 us -5.30% TupleSlicing: 299.38 ms 4.39 us +12.18% ------------------------------------------------------------------------ Average round time: 13615.00 ms -1.13% My AMD-K6-II processor is a pretty quirky beast so I don't think you can conclude too much for those results. Here are the median timings from running Jeremy's compiler on its own source: $ time python compile.py `find . -name '*.py'` Python 1.6 without GC: real 0m16.926s user 0m16.810s sys 0m0.110s Python 1.6 with GC: real 0m21.593s user 0m21.470s sys 0m0.080s Python 1.6 with GC, collection disabled (ie. gc.set_threshold(0)): real 0m18.441s user 0m18.220s sys 0m0.220s We can tune the collection frequency all we want but we won't do any better than the last numbers. Those numbers reflect the cost of keeping track of the objects and the increase in object size. On a related note, I would like to cleanup the PyGC_{NEW, VAR_NEW} macros but I can't figure out a way to transform this code into a macro: op = PyObject_MALLOC(sizeof(PyGCInfo) + _PyObject_SIZE(tp)); if (op) op = PyGC_OBJ((PyGCInfo *)op); If C's || operator was like the Python or I could do something like: #define PyGC_OBJ_SAFE(g) ((PyGCInfo *)(((g) || -1) + 1)) Any ideas? Using an inline function in the header file would be nice but of course it is not portable. GCC has statement expressions but again they are not portable. Neil From Vladimir.Marangozov@inrialpes.fr Fri Jun 9 03:03:59 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Fri, 9 Jun 2000 04:03:59 +0200 (CEST) Subject: [Python-Dev] impact of cycle gc... In-Reply-To: <20000608192900.A21668@acs.ucalgary.ca> from "Neil Schemenauer" at Jun 08, 2000 07:29:00 PM Message-ID: <200006090204.EAA11518@python.inrialpes.fr> Neil Schemenauer wrote: > > On a related note, I would like to cleanup the PyGC_{NEW, > VAR_NEW} macros but I can't figure out a way to transform this > code into a macro: > > op = PyObject_MALLOC(sizeof(PyGCInfo) + _PyObject_SIZE(tp)); > if (op) > op = PyGC_OBJ((PyGCInfo *)op); The correct thing to do, IMO, is to reflect the sizeof(PyGCInfo) mem increment in the tp_basicsize slot of the type object. Thus, we can reuse the current PyObject_New/NEW code, which boils down to PyObject_MALLOC(_PyObject_SIZE(tp)). There is no need for PyGC_NEW/NEW_VAR. This would imply some additional changes to PyObject_Init when the GC_FLAG is set for a given typeobj. I had a closer look at the patch today. It looks good, but I think it needs some more work for a smooth integration with the existing APIs. There's room for optimisations (there are lots of function calls in there, so I am not surprised about the performance hit), but they'll come later on, once the big chunks of the patch fit in their places. One thing that bothered me is that the current gc object allocation code won't fly with C++, where the object storage is allocated (and its size is computed) automatically. There is no PyObject_New, and a C++ object constructor is supposed to begin with PyObject_Init. Another thing is the function names: PyGC_NEW, PyGC_Info, PyGC_Insert, etc. It would be better if they reflect the fact that we're talking about GC on PyObjects, and not about GC in general (on arbitrary mem chunks). I would suggest renaming them along these lines: PyGC_Info -> PyGC_ObjectHead PyGC_Insert -> PyGC_ObjectInit PyGC_Remove -> PyGC_ObjectFini ... All this needs some more thought though... -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From mal@lemburg.com Fri Jun 9 12:03:56 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 09 Jun 2000 13:03:56 +0200 Subject: [Python-Dev] Japanese Codecs Message-ID: <3940CF1C.2C625624@lemburg.com> Python currently supports lots of different code pages and other more specific codecs. I was wondering what your thoughts on this are: should we proceed to include an even wider range of codecs or limit the available number to an absolute minimum ? I'm asking this, because Tamito KAJIYAMA wrote a set of codecs for EUC-JP and Shift_JIS which would probably be very useful for Japanese Python users -- I just don't know how many there are and whether inclusion of an extra 650k of source code would hurt or not. Thoughts ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From akuchlin@mems-exchange.org Fri Jun 9 16:08:46 2000 From: akuchlin@mems-exchange.org (Andrew M. Kuchling) Date: Fri, 9 Jun 2000 11:08:46 -0400 Subject: [Python-Dev] Japanese Codecs In-Reply-To: <3940CF1C.2C625624@lemburg.com>; from mal@lemburg.com on Fri, Jun 09, 2000 at 01:03:56PM +0200 References: <3940CF1C.2C625624@lemburg.com> Message-ID: <20000609110846.C10688@amarok.cnri.reston.va.us> On Fri, Jun 09, 2000 at 01:03:56PM +0200, M.-A. Lemburg wrote: >I'm asking this, because Tamito KAJIYAMA wrote a set of >codecs for EUC-JP and Shift_JIS which would probably >be very useful for Japanese Python users -- I just don't >know how many there are and whether inclusion of an extra >650k of source code would hurt or not. This seems too much code added that would only be of use to a limited audience, so -1 from me. Japanese packagers of Python would probably include them, of course. -- A.M. Kuchling http://starship.python.net/crew/amk/ I confidently expect it to be a fairly resounding failure. -- John Cleese, on the Monty Python reunion planned for 1999 From skip@mojam.com (Skip Montanaro) Fri Jun 9 16:19:59 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Fri, 9 Jun 2000 10:19:59 -0500 (CDT) Subject: [Python-Dev] impact of cycle gc... In-Reply-To: <14656.3573.754658.791617@localhost.localdomain> References: <200006081408.JAA03136@beluga.mojam.com> <14656.3573.754658.791617@localhost.localdomain> Message-ID: <14657.2847.914770.368965@beluga.mojam.com> Jeremy> I don't have time today to look at your post in detail, but one Jeremy> thing you said rtiggered a pretty immediate response: We should Jeremy> worry more about the GC performance on examples like the one you Jeremy> posted, and less about pystone. I wasn't really worried about pystone, just looking for something quick that didn't generate cycles... ;-) Your suggestion is an excellent one. To try and account for the typical case, I modified the test slightly. I added a new class, ethyl: def foo(): pass class ethyl: def __init__(self): self.indirectFunc = foo def theFunc(self): return "blah" which performs essentially the same work at instantiation time as fred, but doesn't create a cycle. The time (in seconds) to create and delete 100,000 freds and ethyls with and without cycle-gc enabled looks like (last of six consecutive runs): ./python ./python-cycle-gc fred (cycle) 1.4 2.51 ethyl (no cycle) 1.39 1.55 The memory consumption is as you would expect - leaky when creating fred's without using cycle-gc, stable otherwise. So, the penalty for creating and deleting objects that don't contain cycles would appear to be reasonable (about 10-15%). As more experience is gained with it, I imagine it can be reduced further. Skip From mal@lemburg.com Fri Jun 9 16:32:41 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 09 Jun 2000 17:32:41 +0200 Subject: [Python-Dev] Japanese Codecs References: <3940CF1C.2C625624@lemburg.com> <20000609110846.C10688@amarok.cnri.reston.va.us> Message-ID: <39410E19.4E4B1EE7@lemburg.com> "Andrew M. Kuchling" wrote: > > On Fri, Jun 09, 2000 at 01:03:56PM +0200, M.-A. Lemburg wrote: > >I'm asking this, because Tamito KAJIYAMA wrote a set of > >codecs for EUC-JP and Shift_JIS which would probably > >be very useful for Japanese Python users -- I just don't > >know how many there are and whether inclusion of an extra > >650k of source code would hurt or not. > > This seems too much code added that would only be of use to a limited > audience, so -1 from me. Japanese packagers of Python would probably > include them, of course. I just wish that these packagers actually become a reality some day... the concept is good, but there currently seem to be no volunteers or companies jumping in :-( -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From DavidA@ActiveState.com Fri Jun 9 19:54:03 2000 From: DavidA@ActiveState.com (David Ascher) Date: Fri, 9 Jun 2000 11:54:03 -0700 Subject: [Python-Dev] Japanese Codecs In-Reply-To: <39410E19.4E4B1EE7@lemburg.com> Message-ID: > I just wish that these packagers actually become a reality > some day... the concept is good, but there currently seem to > be no volunteers or companies jumping in :-( I can't speak for Japanese packagers, but ActiveState will be packaging Python in various ways. --david From klm@digicool.com Fri Jun 9 19:59:26 2000 From: klm@digicool.com (Ken Manheimer) Date: Fri, 9 Jun 2000 14:59:26 -0400 (EDT) Subject: [Python-Dev] revamped Python web site In-Reply-To: <14656.275.83488.186898@localhost.localdomain> Message-ID: On Thu, 8 Jun 2000, Jeremy Hylton wrote: > >>>>> "GM" == Gordon McMillan writes: > > >> From Ken Manheimer's Python web site wishlist: - The humor page > >> (i'm sad to see that languishing) > > GM> A weekly nude Tim Peters jpeg! > > We were going to keep those on the pythonlabs.com internal site, but > if Tim doesn't object... Anything for a buck, ay, now that you're in the commercial world?-) Ken klm@digicool.com From tim_one@email.msn.com Fri Jun 9 20:11:42 2000 From: tim_one@email.msn.com (Tim Peters) Date: Fri, 9 Jun 2000 15:11:42 -0400 Subject: [Python-Dev] revamped Python web site In-Reply-To: Message-ID: <000c01bfd246$8c02ca40$a12d153f@tim> [KenM] > - The humor page (i'm sad to see that languishing) [Gordon, as always, guides our youth] > A weekly nude Tim Peters jpeg! [JeremyH] > We were going to keep those on the pythonlabs.com internal site, but > if Tim doesn't object... [KenM] > Anything for a buck, ay, now that you're in the commercial world?-) After one of my recent "going away" parties here (I "get to" move to VA next week), a group of old chums were sitting around the restaurant table, belching up bad Italian cooking and speculating on our places in God's Inscrutable Plan. When it came time to pick on me, one naturally pugnacious fellow-- emboldened beyond his normal aggression by wine --looked me straight in the eye and demanded to know if there's *anything* I wouldn't do for money. Well, in point of fact I believe there are a great many such things, but in the moment God only inspired me with one, and so I heard myself retorting: "Ya, sure, I'd fuck a dog for science ... but I wouldn't take a job at Microsoft!". strangely-enough-i-think-that's-backwards-ly y'rs - tim From Moshe Zadka Fri Jun 9 20:20:17 2000 From: Moshe Zadka (Moshe Zadka) Date: Fri, 9 Jun 2000 22:20:17 +0300 (IDT) Subject: [Python-Dev] revamped Python web site In-Reply-To: <000c01bfd246$8c02ca40$a12d153f@tim> Message-ID: On Fri, 9 Jun 2000, Tim Peters wrote: > In the moment God only inspired me with one, and so I heard > myself retorting: "Ya, sure, I'd fuck a dog for science ... but I wouldn't > take a job at Microsoft!". > > strangely-enough-i-think-that's-backwards-ly y'rs - tim Backwards? You mean you'd fuck Microsoft for science but wouldn't take a job at a dog? Or you'd fuck a dog for Microsoft but wouldn't take a job at science? Or you'd take a job for science, but wouldn't fuck at Microsoft? misunderstanding-tim-seems-to-be-a-common-pass-time-around-here-ly y'rs, Z -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com Return-Path: Delivered-To: python-dev@python.org Received: from math.ma.huji.ac.il (ma.huji.ac.il [132.64.32.5]) by dinsdale.python.org (Postfix) with ESMTP id C19A61CD28; Fri, 9 Jun 2000 14:37:53 -0400 (EDT) Received: from localhost (moshez@localhost) by math.ma.huji.ac.il (8.9.1b+Sun/8.9.3) with ESMTP id VAA28640; Fri, 9 Jun 2000 21:37:03 +0300 (IDT) Date: Fri, 9 Jun 2000 21:37:03 +0300 (IDT) From: Moshe Zadka X-Sender: moshez@sundial Reply-To: Moshe Zadka To: perl_monkey@my-deja.com Cc: python-list@python.org, s2mdalle@titan.vcu.edu In-Reply-To: <8hrbph$a4n$1@nnrp1.deja.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Python-Dev] Re: Porting CPython Sender: python-dev-admin@python.org Errors-To: python-dev-admin@python.org X-BeenThere: python-dev@python.org X-Mailman-Version: 2.0beta3 Precedence: bulk List-Id: Python core developers Not a lot I can help you with, but: On Fri, 9 Jun 2000 perl_monkey@my-deja.com wrote: > - Excluding Modules > > What is the build procedure for omitting certain built in C modules? > (I"m talking about the stuff in Modules/) Edit the "Setup.in" file. Instructions for how are inside the file, but if you have any more specific questions, please ask again. > Any help on any of these issues would be appreciated. Also, when/if I > finish this, I'd be willing to diff the source and put it into the main > python branch if that's something people would be interested in. I'm CCing Python-Dev on this, so hopefully someone from the BeOpen team can respond. I can just say I'm for it. (Python-dev is on BCC so replies to this won't automatically go there.) -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com From jeremy@beopen.com Fri Jun 9 22:00:09 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Fri, 9 Jun 2000 17:00:09 -0400 (EDT) Subject: [Python-Dev] Japanese Codecs In-Reply-To: References: <39410E19.4E4B1EE7@lemburg.com> Message-ID: <14657.23257.478479.141319@localhost.localdomain> >>>>> "DA" == David Ascher writes: >> I just wish that these packagers actually become a reality some >> day... the concept is good, but there currently seem to be no >> volunteers or companies jumping in :-( DA> I can't speak for Japanese packagers, but ActiveState will be DA> packaging Python in various ways. BeOpen also has packaging plans :-). Jeremy From mal@lemburg.com Fri Jun 9 22:49:37 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 09 Jun 2000 23:49:37 +0200 Subject: [Python-Dev] Japanese Codecs References: <39410E19.4E4B1EE7@lemburg.com> <14657.23257.478479.141319@localhost.localdomain> Message-ID: <39416671.AF78100F@lemburg.com> Jeremy Hylton wrote: > > >>>>> "DA" == David Ascher writes: > > >> I just wish that these packagers actually become a reality some > >> day... the concept is good, but there currently seem to be no > >> volunteers or companies jumping in :-( > > DA> I can't speak for Japanese packagers, but ActiveState will be > DA> packaging Python in various ways. > > BeOpen also has packaging plans :-). Sounds cool. I just hope that someone will hint me of the first Python IPO *before* it hits NASDAQ ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Fredrik Lundh" <14657.23257.478479.141319@localhost.localdomain> Message-ID: <001101bfd25d$f6a0fb80$f2a6b5d4@hagrid> > I can't speak for Japanese packagers, but ActiveState will be > packaging Python in various ways. >=20 > BeOpen also has packaging plans :-). get in line, guys ;-) From esr@thyrsus.com Fri Jun 9 23:19:24 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Fri, 9 Jun 2000 18:19:24 -0400 Subject: [Python-Dev] RFC: Including PIL in 1.6 In-Reply-To: <20000609215719.47624E2673@oratrix.oratrix.nl>; from jack@oratrix.nl on Fri, Jun 09, 2000 at 11:57:14PM +0200 References: <20000609215719.47624E2673@oratrix.oratrix.nl> Message-ID: <20000609181924.A15728@thyrsus.com> Jack Jansen : > I include PIL in the standard MacPython and Mac users are apparently > very happy with that [...] I think it's time to consider including PIL in the core Python 1.6 release. I've been following the work being done over there, and I believe the code has reached a sufficient level of maturity to justify this. The "Batteries are included" philosophy seems to me to imply that we ought to be looking for application libraries to promote into the core once we're satisfied that they meet core-Pythonic standards of good API design, stability, general usefulness, and documentation quality. PIL seems to me like a good candidate on all counts. Guido has to make the final call, of course. But let's have the discussion now so we can develop a yea or nay consensus on ther list. -- Eric S. Raymond Society in every state is a blessing, but government even in its best state is but a necessary evil; in its worst state an intolerable one; for when we suffer, or are exposed to the same miseries *by a government*, which we might expect in a country *without government*, our calamities is heightened by reflecting that we furnish the means by which we suffer." -- Thomas Paine From pingster@ilm.com Fri Jun 9 23:28:27 2000 From: pingster@ilm.com (Ka-Ping Yee) Date: Fri, 9 Jun 2000 15:28:27 -0700 (PDT) Subject: [Python-Dev] RFC: Including PIL in 1.6 In-Reply-To: <20000609181924.A15728@thyrsus.com> Message-ID: On Fri, 9 Jun 2000, Eric S. Raymond wrote: > Jack Jansen : > > I include PIL in the standard MacPython and Mac users are apparently > > very happy with that [...] > > I think it's time to consider including PIL in the core Python 1.6 release. > I've been following the work being done over there, and I believe the > code has reached a sufficient level of maturity to justify this. I'm +0. Well, perhaps +0.1. I guess what i would really be "+" about is something to the effect of "a popular Linux distribution decides to throw in the .so for PIL". Then it wouldn't really matter to me whether it was in the "real" standard distribution. -- ?!ng "The police are not here to create disorder. They're here to preserve disorder." -- Former Chicago mayor Daley From akuchlin@mems-exchange.org Sat Jun 10 02:52:23 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Fri, 9 Jun 2000 21:52:23 -0400 Subject: [Python-Dev] Re: [Image-SIG] RFC: Including PIL in 1.6 In-Reply-To: <20000609181924.A15728@thyrsus.com>; from esr@thyrsus.com on Fri, Jun 09, 2000 at 06:19:24PM -0400 References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> Message-ID: <20000609215223.A23230@newcnri.cnri.reston.va.us> On Fri, Jun 09, 2000 at 06:19:24PM -0400, Eric S. Raymond wrote: >I think it's time to consider including PIL in the core Python 1.6 release. -1 unless Fredrik says there's a C and Python API for extending PIL that he's happy with, in which case it's +0. I've written a few extensions for PIL and it required a fair amount of grubbing around inside of C structures; it isn't clear that the structures will be the same in future versions of PIL. We don't want to add something that people will extend messily, which will then make fixing the API more difficult because of backward compatibility. (Disclaimer: I haven't looked at PIL 1.1 yet; maybe /F has documented an API, or maybe he's pretty sure the data structures will remain the same.) OTOH, given that the Distutils is making good progress on building RPMs for an arbitrary Python package, installing PIL may get much easier in future, reducing the need to add it to the core. But then Paul always yells at me for that argument. :) -- A.M. Kuchling akuchlin@mems-exchange.org Posting "Please send e-mail, since I don't read this group": Poster is rendered illiterate by a simple trepanation. -- Kibo, in the Happynet Manifesto From akuchlin@mems-exchange.org Sat Jun 10 03:50:08 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Fri, 9 Jun 2000 22:50:08 -0400 Subject: [Python-Dev] What's New: 2nd draft Message-ID: <20000609225008.A23369@newcnri.cnri.reston.va.us> We've made a second pass at the "What's New in 1.6" document; the only unwritten section is IDLE, and I don't think either Moshe or I use IDLE. Can anyone tell us what the new features are? Again, suggestions on style, forgotten changes, *anything*, are welcomed: http://starship.python.net/crew/amk/python/writing/new-python/ -- A.M. Kuchling http://starship.python.net/crew/amk/ "How about you -- what're you up to?" "Issue #3." -- Vic and Zot, in ZOT! #3 From Moshe Zadka Sat Jun 10 06:29:56 2000 From: Moshe Zadka (Moshe Zadka) Date: Sat, 10 Jun 2000 08:29:56 +0300 (IDT) Subject: [Python-Dev] Japanese Codecs In-Reply-To: <001101bfd25d$f6a0fb80$f2a6b5d4@hagrid> Message-ID: On Fri, 9 Jun 2000, Fredrik Lundh wrote: > > I can't speak for Japanese packagers, but ActiveState will be > > packaging Python in various ways. > > > > BeOpen also has packaging plans :-). > > get in line, guys ;-) I wonder if next we'll see threads on slashdot about "PythonOne is just trying to get on the Python hype. It has nothing to offer except for a trivial installer anyone can write in 5 minutes in Python" (cf: the LinuxOne fiasco) -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com From paul@prescod.net Thu Jun 8 22:32:27 2000 From: paul@prescod.net (Paul Prescod) Date: Thu, 08 Jun 2000 23:32:27 +0200 Subject: [Python-Dev] [Fwd: Re: Case sensitivity] Message-ID: <394010EB.DBCBC5FD@prescod.net> Here's a good summary of how XML's case sensitivity came to be. -------- Original Message -------- Subject: Re: Case sensitivity Date: Mon, 3 Apr 2000 12:44:37 -0400 From: Steve DeRose To: xml-dev@lists.oasis-open.org References: Languages with no need for case folding are not much of a problem: the case-folding table or program would merely have no effect on characters belonging to such languages: It would change 26 of our 26 alphabetic code points, and no others. After all, in English we already use lots of characters that don't get case-folded (like digits). The serious problems are subtler: The practical problem that with Unicode your folding table gets really big; on the order of 128Kbytes instead of 256 bytes (barring compresson): this is a pain on small devices (like a cell-phone browser), a pain to load, a pain to implement compression for, etc. The theoretical problem is more important: it's not the caseless languages that pose problems, but the complicated case-folding ones. For example, lots of languages only apply diacritical marks to lower-case letters: for example, "a" may come with 6 different accents, but "A" takes none -- which makes case-folding unreversible. If there are languages that operate the other way as well, then neither fold-to-upper nor fold-to-lower can work for all languages: either way would trash some languages. That said, I think it incumbent on XML *search engines* to support case-folding (as well as decent treatment of accents, types of hyphens, etc) for text content searches: Making English speakers search for "the" | "thE" | "tHe" | "tHE" | "The" | "ThE" | "THe" | "THE" or "[tT][hH][eE] is patently absurd; and besides, there is no user cost to (say) a Japanese speaker if an engine *does* case-fold. Also, many languages use Roman characters occasionally, as for acronyms; so their speakers also pay a price if searches aren't smart enough. And the primary problems with case-folding do not weigh so heavily in the search engine world (for example, AltaVista isn't likely to run their main servers on cell phones for a while yet). From esr@thyrsus.com Sat Jun 10 16:42:27 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Sat, 10 Jun 2000 11:42:27 -0400 Subject: [Python-Dev] Suggestion to Windows- and Mac-library people Message-ID: <20000610114227.A19052@thyrsus.com> Last night I sent the following patch for urllib to python-patches: # Support for launching a browser if os.environ.has_key("BROWSER"): _browsers = string.split(os.environ["BROWSER"], ":") else: _browsers = ["mozilla %s &", "netscape -remote 'openURL(%s)'", "netscape %s &", "lynx %s &", "w3m %s &"] def urlbrowse(url): """Launch a browser, in background, pointed at the given URL. Accept either a string or a parsed URL tuple. Interpret the BROWSER environment variable, if it exists, as a colon-separated list of browser commands to try. """ from urlparse import urlunparse if type(url) == (): url = urlunparse(url) for browser in _browsers: if not os.system('which 1>/dev/null 2>&1 '+string.split(browser)[0]): if os.system((browser % url)) == 0: return 1 return 0 Obviously this is not portable off Unix. Equally obviously it should be possible to do an equivalent thing under Windows (at least). For anybody writing interactive programs in this Web-mad era, this function is just too useful not to have in the toolbox. So this is a nudge to any Windows and Mac wizards on this list -- let's make this function available cross-platform. I've also copied this note to Chip Salzenberg. Perl ought to have this capability too -- and I'm sufficiently serious about that to (gasp) code in Perl myself to make it happen if I have to. -- Eric S. Raymond (Those) who are trying to read the Second Amendment out of the Constitution by claiming it's not an individual right (are) courting disaster by encouraging others to use the same means to eliminate portions of the Constitution they don't like. -- Alan Dershowitz, Harvard Law School From akuchlin@mems-exchange.org Sat Jun 10 16:42:50 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Sat, 10 Jun 2000 11:42:50 -0400 Subject: [Python-Dev] Creating curses package: OK? In-Reply-To: <20000610113124.B18982@thyrsus.com>; from esr@thyrsus.com on Sat, Jun 10, 2000 at 11:31:24AM -0400 References: <200006100748.DAA17920@snark.thyrsus.com> <20000610111323.A24895@newcnri.cnri.reston.va.us> <20000610113124.B18982@thyrsus.com> Message-ID: <20000610114250.A25014@newcnri.cnri.reston.va.us> [Redirecting a private conversation to python-dev] On Sat, Jun 10, 2000 at 11:31:24AM -0400, Eric S. Raymond wrote: >I found a workaround. The two curses enhancements (traceback wrapper >and text pad) are now working and ready to be integrated into the >1.6 library. How should we proceed? OK; python-dev has discussed creating a curses package, and reaction seemed favorable. So, my plan of action is: 1) Rename cursesmodule.c to _cursesmodule.c. (Barry, can you do a 'mv' inside the SourceForge CVS repository so the complete history of the module doesn't get lost with the renaming?) 2) Create a Lib/curses/ directory; __init__.py does 'from _curses import *'. 3) The traceback wrapper can then be put into __init__.py, since I assume it's fairly small and everyone should use it. The text pad stuff could then go in another module in the curses package. Seem reasonable to everyone? --amk From esr@thyrsus.com Sat Jun 10 17:01:48 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Sat, 10 Jun 2000 12:01:48 -0400 Subject: [Python-Dev] Creating curses package: OK? In-Reply-To: <20000610114250.A25014@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Sat, Jun 10, 2000 at 11:42:50AM -0400 References: <200006100748.DAA17920@snark.thyrsus.com> <20000610111323.A24895@newcnri.cnri.reston.va.us> <20000610113124.B18982@thyrsus.com> <20000610114250.A25014@newcnri.cnri.reston.va.us> Message-ID: <20000610120148.A19168@thyrsus.com> Andrew Kuchling : > OK; python-dev has discussed creating a curses package, and reaction > seemed favorable. So, my plan of action is: > > 1) Rename cursesmodule.c to _cursesmodule.c. (Barry, can you do a 'mv' > inside the SourceForge CVS repository so the complete history of the > module doesn't get lost with the renaming?) > > 2) Create a Lib/curses/ > directory; __init__.py does 'from _curses import *'. > > 3) The traceback wrapper can then be put into __init__.py, since I > assume it's fairly small and everyone should use it. The text pad > stuff could then go in another module in the curses package. > > Seem reasonable to everyone? Works for me. -- Eric S. Raymond We shall not cease from exploration, and the end of all our exploring will be to arrive where we started and know the place for the first time. -- T.S. Eliot From Moshe Zadka Sat Jun 10 18:03:51 2000 From: Moshe Zadka (Moshe Zadka) Date: Sat, 10 Jun 2000 20:03:51 +0300 (IDT) Subject: [Python-Dev] Creating curses package: OK? In-Reply-To: <20000610114250.A25014@newcnri.cnri.reston.va.us> Message-ID: On Sat, 10 Jun 2000, Andrew Kuchling wrote: > OK; python-dev has discussed creating a curses package, and reaction > seemed favorable. So, my plan of action is: > > 1) Rename cursesmodule.c to _cursesmodule.c. (Barry, can you do a 'mv' > inside the SourceForge CVS repository so the complete history of the > module doesn't get lost with the renaming?) > > 2) Create a Lib/curses/ > directory; __init__.py does 'from _curses import *'. > > 3) The traceback wrapper can then be put into __init__.py, since I > assume it's fairly small and everyone should use it. The text pad > stuff could then go in another module in the curses package. > > Seem reasonable to everyone? I'm +1, except for some nagging doubt about the traceback wrapper. Why not put it in its own (small, granted) module? There are no backward compatabilities to worry here, so there shouldn't be any excuse to put code in __init__.py. But it is so small, that I don't really feel strongly about it. i'll-be-+1-on-the-text-pad-stuff-when-you-get-it-ready-eric-ly y'rs, Z. -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com From esr@thyrsus.com Sat Jun 10 18:24:18 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Sat, 10 Jun 2000 13:24:18 -0400 Subject: [Python-Dev] Creating curses package: OK? In-Reply-To: ; from moshez@math.huji.ac.il on Sat, Jun 10, 2000 at 08:03:51PM +0300 References: <20000610114250.A25014@newcnri.cnri.reston.va.us> Message-ID: <20000610132418.A19442@thyrsus.com> Moshe Zadka : > I'm +1, except for some nagging doubt about the traceback wrapper. > Why not put it in its own (small, granted) module? I don't understand. Whuy do you want to do this? > i'll-be-+1-on-the-text-pad-stuff-when-you-get-it-ready-eric-ly y'rs, Z. You can try it out now: # # Curses extensions -- these are expected to be in the 1.6 Python library # import sys, curses, ascii def wrapper(func, *rest): "Wrapper function that restores normal keyboard/screen behavior on error." res = None try: # Initialize curses stdscr=curses.initscr() # Turn off echoing of keys, and enter cbreak mode, # where no buffering is performed on keyboard input curses.noecho() ; curses.cbreak() # In keypad mode, escape sequences for special keys # (like the cursor keys) will be interpreted and # a special value like curses.KEY_LEFT will be returned stdscr.keypad(1) res = apply(func, (stdscr,) + rest) except: # In the event of an error, restore the terminal # to a sane state. stdscr.keypad(0) curses.echo() ; curses.nocbreak() curses.endwin() # Pass the exception upwards (exc_type, exc_value, exc_traceback) = sys.exc_info() raise exc_type, exc_value, exc_traceback else: # Set everything back to normal stdscr.keypad(0) curses.echo() ; curses.nocbreak() curses.endwin() # Terminate curses return res def rectangle(win, uly, ulx, lry, lrx): "Draw a rectangle." win.vline(uly+1, ulx, curses.ACS_VLINE, lry - uly - 1) win.hline(uly, ulx+1, curses.ACS_HLINE, lrx - ulx - 1) win.hline(lry, ulx+1, curses.ACS_HLINE, lrx - ulx - 1) win.vline(uly+1, lrx, curses.ACS_VLINE, lry - uly - 1) win.addch(uly, ulx, curses.ACS_ULCORNER) win.addch(uly, lrx, curses.ACS_URCORNER) win.addch(lry, lrx, curses.ACS_LRCORNER) win.addch(lry, ulx, curses.ACS_LLCORNER) class textbox: """Editing widget using the interior of a window object. Supports the following Emacs-like key bindings: Ctrl-A Go to left edge of window. Ctrl-B Cursor left, wrapping to previous line if appropriate. Ctrl-D Delete character under cursor. Ctrl-E Go to right edge (nospaces off) or end of line (nospaces on). Ctrl-F Cursor right, wrapping to next line when appropriate. Ctrl-G Terminate, returning the window contents. Ctrl-J Terminate if the window is 1 line, otherwise insert newline. Ctrl-K If line is blank, delete it, otherwise clear to end of line. Ctrl-L Refresh screen Ctrl-N Cursor down; move down one line. Ctrl-O Insert a blank line at cursor location. Ctrl-P Cursor up; move up one line. Move operations do nothing if the cursor is at an edge where the movement is not possible. The following synonyms are supported where possible: KEY_LEFT = Ctrl-B, KEY_RIGHT = Ctrl-F, KEY_UP = Ctrl-P, KEY_DOWN = Ctrl-N """ def __init__(self, win): self.win = win (self.maxy, self.maxx) = win.getmaxyx() self.maxy = self.maxy - 1 self.maxx = self.maxx - 1 self.stripspaces = 1 win.keypad(1) def firstblank(self, y): "Go to the location of the first blank on the given line." (oldy, oldx) = self.win.getyx() self.win.move(y, self.maxx-1) last = self.maxx-1 while 1: if last == 0: break if ascii.ascii(self.win.inch(y, last)) != ascii.SP: last = last + 1 break last = last - 1 self.win.move(oldy, oldx) return last def do_command(self, ch): "Process a single editing command." (y, x) = self.win.getyx() if ascii.isprint(ch): if y < self.maxy or x < self.maxx: # The try-catch ignores the error we trigger from some curses # versions by trying to write into the lowest-rightmost spot # in the self.window. try: self.win.addch(ch) except ERR: pass elif ch == ascii.SOH: # Ctrl-a self.win.move(y, 0) elif ch in (ascii.STX, curses.KEY_LEFT): # Ctrl-b if x > 0: self.win.move(y, x-1) elif y == 0: pass elif self.stripspaces: self.win.move(y-1, self.firstblank(y-1)) else: self.win.move(y-1, self.maxx) elif ch == ascii.EOT: # Ctrl-d self.win.delch() elif ch == ascii.ENQ: # Ctrl-e if self.stripspaces: self.win.move(y, self.firstblank(y, maxx)) else: self.win.move(y, self.maxx) elif ch in (ascii.ACK, curses.KEY_RIGHT): # Ctrl-f if x < self.maxx: self.win.move(y, x+1) elif y == self.maxx: pass else: self.win.move(y+1, 0) elif ch == ascii.BEL: # Ctrl-g return 0 elif ch == ascii.NL: # Ctrl-j if self.maxy == 0: return 0 elif y < self.maxy: self.win.move(y+1, 0) elif ch == ascii.VT: # Ctrl-k if x == 0 and self.firstblank(y) == 0: self.win.deleteln() else: self.win.clrtoeol() elif ch == ascii.FF: # Ctrl-l self.win.refresh() elif ch in (ascii.SO, curses.KEY_DOWN): # Ctrl-n if y < self.maxy: self.win.move(y+1, x) elif ch == ascii.SI: # Ctrl-o self.win.insertln() elif ch in (ascii.DLE, curses.KEY_UP): # Ctrl-p if y > 0: self.win.move(y-1, x) self.win.refresh() return 1 def gather(self): "Collect and return the contents of the window." result = "" for y in range(self.maxy+1): self.win.move(y, 0) stop = self.firstblank(y) if stop == 0 and self.stripspaces: continue for x in range(self.maxx+1): if self.stripspaces and x == stop: break result = result + chr(ascii.ascii(self.win.inch(y, x))) if self.maxy > 0: result = result + "\n" return result def edit(self, validate=None): "Edit in the widget window and collect the results." while 1: ch = self.win.getch() if self.validate: ch = validate(ch) if not self.do_command(ch): break return self.gather() if __name__ == '__main__': def test_editbox(stdscr): win = curses.newwin(4, 9, 15, 20) rectangle(stdscr, 14, 19, 19, 29) stdscr.refresh() return textbox(win).edit() str = wrapper(test_editbox) print str -- Eric S. Raymond The danger (where there is any) from armed citizens, is only to the *government*, not to *society*; and as long as they have nothing to revenge in the government (which they cannot have while it is in their own hands) there are many advantages in their being accustomed to the use of arms, and no possible disadvantage. -- Joel Barlow, "Advice to the Privileged Orders", 1792-93 From bwarsaw@python.org Sat Jun 10 18:58:04 2000 From: bwarsaw@python.org (Barry A. Warsaw) Date: Sat, 10 Jun 2000 13:58:04 -0400 (EDT) Subject: [Python-Dev] Creating curses package: OK? References: <200006100748.DAA17920@snark.thyrsus.com> <20000610111323.A24895@newcnri.cnri.reston.va.us> <20000610113124.B18982@thyrsus.com> <20000610114250.A25014@newcnri.cnri.reston.va.us> Message-ID: <14658.33196.426211.329070@anthem.concentric.net> >>>>> "AK" == Andrew Kuchling writes: AK> 1) Rename cursesmodule.c to _cursesmodule.c. (Barry, can you AK> do a 'mv' inside the SourceForge CVS repository so the AK> complete history of the module doesn't get lost with the AK> renaming?) Not easily (IOW, I have to play several rounds of ugly loginfo games which are hard to get right). Best thing to do would be to submit a SF admin request, which I think since you're a developer you can do. -Barry From Moshe Zadka Sat Jun 10 21:12:32 2000 From: Moshe Zadka (Moshe Zadka) Date: Sat, 10 Jun 2000 23:12:32 +0300 (IDT) Subject: [Python-Dev] Creating curses package: OK? In-Reply-To: <20000610132418.A19442@thyrsus.com> Message-ID: [Moshe Zadka] > I'm +1, except for some nagging doubt about the traceback wrapper. > Why not put it in its own (small, granted) module? [Eric S. Raymond] > I don't understand. Why do you want to do this? I have religious beliefs, and I follow them without thinking. Like "HTTP good, FTP bad". "Python good, C++ bad". Or, in that case "Putting real code in __init__.py bad". (I think that should go in the package style guide, BTW) religions-are-bad-of-course-ly y'rs, Z. -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com From esr@thyrsus.com Sat Jun 10 21:24:40 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Sat, 10 Jun 2000 16:24:40 -0400 Subject: [Python-Dev] Creating curses package: OK? In-Reply-To: ; from moshez@math.huji.ac.il on Sat, Jun 10, 2000 at 11:12:32PM +0300 References: <20000610132418.A19442@thyrsus.com> Message-ID: <20000610162440.A19859@thyrsus.com> Moshe Zadka : > [Eric S. Raymond] > > I don't understand. Why do you want to do this? > > I have religious beliefs, and I follow them without thinking. Like > "HTTP good, FTP bad". "Python good, C++ bad". Or, in that case "Putting > real code in __init__.py bad". I'm even more confused now. Why would the traceback wrapper I'm proposing go in __init__.py? -- Eric S. Raymond The Bible is not my book, and Christianity is not my religion. I could never give assent to the long, complicated statements of Christian dogma. -- Abraham Lincoln From Moshe Zadka Sat Jun 10 21:21:57 2000 From: Moshe Zadka (Moshe Zadka) Date: Sat, 10 Jun 2000 23:21:57 +0300 (IDT) Subject: [Python-Dev] Creating curses package: OK? In-Reply-To: <20000610162440.A19859@thyrsus.com> Message-ID: On Sat, 10 Jun 2000, Eric S. Raymond wrote: > I'm even more confused now. Why would the traceback wrapper I'm proposing > go in __init__.py? Maybe I'm confused here. I thought that was what AMK suggested, no? Where would you want it to go? There are currently 3 planned files in the curses package: __init__.py: apparently not textpad.py: why here? it has nothing to do with text pads _curses.so: certainly not here...you don't want to code in C more then you have to I'm proposing: wrapper.py: put it here i-hope-i-managed-to-confuse-everyone-further-ly y'rs, Z. -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com From akuchlin@mems-exchange.org Sat Jun 10 23:25:14 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Sat, 10 Jun 2000 18:25:14 -0400 Subject: [Python-Dev] Creating curses package: OK? In-Reply-To: ; from moshez@math.huji.ac.il on Sat, Jun 10, 2000 at 11:21:57PM +0300 References: <20000610162440.A19859@thyrsus.com> Message-ID: <20000610182514.A25949@newcnri.cnri.reston.va.us> On Sat, Jun 10, 2000 at 11:21:57PM +0300, Moshe Zadka wrote: >Maybe I'm confused here. I thought that was what AMK suggested, no? I did in fact suggest that, since the wrapper is small, and we ideally want every Python/curses application using it, so they don't leave the terminal in a wacky state if they raise an exception. But it's not a big deal and could easily go in wrapper.py, though __init__.py might still import it automatically. --amk From esr@thyrsus.com Sat Jun 10 23:38:06 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Sat, 10 Jun 2000 18:38:06 -0400 Subject: [Python-Dev] Creating curses package: OK? In-Reply-To: <20000610182514.A25949@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Sat, Jun 10, 2000 at 06:25:14PM -0400 References: <20000610162440.A19859@thyrsus.com> <20000610182514.A25949@newcnri.cnri.reston.va.us> Message-ID: <20000610183806.A20280@thyrsus.com> Andrew Kuchling : > On Sat, Jun 10, 2000 at 11:21:57PM +0300, Moshe Zadka wrote: > >Maybe I'm confused here. I thought that was what AMK suggested, no? > > I did in fact suggest that, since the wrapper is small, and we ideally > want every Python/curses application using it, so they don't leave the > terminal in a wacky state if they raise an exception. But it's not a > big deal and could easily go in wrapper.py, though __init__.py might > still import it automatically. The traceback wrapper is not the only Python code I'll be supplying... -- Eric S. Raymond I do not find in orthodox Christianity one redeeming feature. -- Thomas Jefferson From gstein@lyra.org Sat Jun 10 23:33:20 2000 From: gstein@lyra.org (Greg Stein) Date: Sat, 10 Jun 2000 15:33:20 -0700 Subject: [Python-Dev] Creating curses package: OK? In-Reply-To: <20000610182514.A25949@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Sat, Jun 10, 2000 at 06:25:14PM -0400 References: <20000610162440.A19859@thyrsus.com> <20000610182514.A25949@newcnri.cnri.reston.va.us> Message-ID: <20000610153320.A19484@lyra.org> On Sat, Jun 10, 2000 at 06:25:14PM -0400, Andrew Kuchling wrote: > On Sat, Jun 10, 2000 at 11:21:57PM +0300, Moshe Zadka wrote: > >Maybe I'm confused here. I thought that was what AMK suggested, no? > > I did in fact suggest that, since the wrapper is small, and we ideally > want every Python/curses application using it, so they don't leave the > terminal in a wacky state if they raise an exception. But it's not a > big deal and could easily go in wrapper.py, though __init__.py might > still import it automatically. Yes, I think we'd want it to import the stuff; just organizationally to place the source code outside of __init__.py I'd agree that real code should not go into __init__. It should preload some standard modules, maybe expose some symbols, but otherwise no code. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Sun Jun 11 00:30:13 2000 From: gstein@lyra.org (Greg Stein) Date: Sat, 10 Jun 2000 16:30:13 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses __init__.py,NONE,1.1 wrapper.py,NONE,1.1 In-Reply-To: <200006102306.QAA18088@slayer.i.sourceforge.net>; from akuchling@slayer.i.sourceforge.net on Sat, Jun 10, 2000 at 04:06:55PM -0700 References: <200006102306.QAA18088@slayer.i.sourceforge.net> Message-ID: <20000610163013.B19484@lyra.org> On Sat, Jun 10, 2000 at 04:06:55PM -0700, A.M. Kuchling wrote: >... > def wrapper(func, *rest): > """Wrapper function that initializes curses and calls another function, > restoring normal keyboard/screen behavior on error. > The callable object 'func' is then passed the main window 'stdscr' > as its first argument, followed by any other arguments passed to > wrapper(). > """ > > res = None > try: > # Initialize curses > stdscr=curses.initscr() > # Turn off echoing of keys, and enter cbreak mode, > # where no buffering is performed on keyboard input > curses.noecho() ; curses.cbreak() > > # In keypad mode, escape sequences for special keys > # (like the cursor keys) will be interpreted and > # a special value like curses.KEY_LEFT will be returned > stdscr.keypad(1) > > res = apply(func, (stdscr,) + rest) > except: > # In the event of an error, restore the terminal > # to a sane state. > stdscr.keypad(0) > curses.echo() ; curses.nocbreak() > curses.endwin() > # Pass the exception upwards > (exc_type, exc_value, exc_traceback) = sys.exc_info() > raise exc_type, exc_value, exc_traceback > else: > # Set everything back to normal > stdscr.keypad(0) > curses.echo() ; curses.nocbreak() > curses.endwin() # Terminate curses > > return res This is too complicated. It should read: ... return apply(func, (stdscr,) + rest) finally: # Set everything back to normal stdscr.keypad(0) curses.echo() curses.nocbreak() curses.endwin() Andrew: can you make this change? Separate from the above simplification, it is important to note: exc_type, exc_value, exc_traceback = sys.exc_info() raise exc_type, exc_value, exc_traceback and raise are equivalent in (most) function. The difference is that the former places the traceback into local variable storage (exc_traceback) which then introduces a reference loop. Whenever sys.exc_info() is used, it is very important to watch out for loops caused by the traceback object. "del exc_traceback" is very handy :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Sun Jun 11 00:33:05 2000 From: gstein@lyra.org (Greg Stein) Date: Sat, 10 Jun 2000 16:33:05 -0700 Subject: [Python-Dev] curses wrapper checkin In-Reply-To: <20000610163013.B19484@lyra.org>; from gstein@lyra.org on Sat, Jun 10, 2000 at 04:30:13PM -0700 References: <200006102306.QAA18088@slayer.i.sourceforge.net> <20000610163013.B19484@lyra.org> Message-ID: <20000610163305.C19484@lyra.org> On Sat, Jun 10, 2000 at 04:30:13PM -0700, Greg Stein wrote: > On Sat, Jun 10, 2000 at 04:06:55PM -0700, A.M. Kuchling wrote: > >... > > def wrapper(func, *rest): > > """Wrapper function that initializes curses and calls another function, > > restoring normal keyboard/screen behavior on error. > > The callable object 'func' is then passed the main window 'stdscr' > > as its first argument, followed by any other arguments passed to > > wrapper(). > > """ > > > > res = None Oh. This line can disappear, too. Cheers, -g -- Greg Stein, http://www.lyra.org/ From akuchlin@mems-exchange.org Sun Jun 11 00:33:12 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Sat, 10 Jun 2000 19:33:12 -0400 Subject: [Python-Dev] Creating curses package: done In-Reply-To: <14658.33196.426211.329070@anthem.concentric.net>; from bwarsaw@python.org on Sat, Jun 10, 2000 at 01:58:04PM -0400 References: <200006100748.DAA17920@snark.thyrsus.com> <20000610111323.A24895@newcnri.cnri.reston.va.us> <20000610113124.B18982@thyrsus.com> <20000610114250.A25014@newcnri.cnri.reston.va.us> <14658.33196.426211.329070@anthem.concentric.net> Message-ID: <20000610193312.A26098@newcnri.cnri.reston.va.us> On Sat, Jun 10, 2000 at 01:58:04PM -0400, Barry A. Warsaw wrote: >which are hard to get right). Best thing to do would be to submit a >SF admin request, which I think since you're a developer you can do. I've submitted a support request to rename the file, and checked in the Lib/curses subdirectory, containing only __init__.py and wrapper.py, along with the required Makefile.in and Setup.in changes. If you compile the CVS tree right now, you'll need to rename cursesmodule.c to _cursesmodule.c manually. The textbox stuff poses two problems. First, it requires ascii.py, and wasn't the decision to wait for GvR on adding that module? Second, Eric, I'm not sure what you want as the module name for the textbox stuff: textbox.py? Your call... (I'll check it in, and if ascii.py is vetoed, it can be rewritten to not require ascii.py, or we can have curses.ascii.) --amk From esr@thyrsus.com Sun Jun 11 00:48:22 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Sat, 10 Jun 2000 19:48:22 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses __init__.py,NONE,1.1 wrapper.py,NONE,1.1 In-Reply-To: <20000610163013.B19484@lyra.org>; from gstein@lyra.org on Sat, Jun 10, 2000 at 04:30:13PM -0700 References: <200006102306.QAA18088@slayer.i.sourceforge.net> <20000610163013.B19484@lyra.org> Message-ID: <20000610194822.A882@thyrsus.com> Greg Stein : > This is too complicated. It should read: > > ... > return apply(func, (stdscr,) + rest) > finally: > # Set everything back to normal > stdscr.keypad(0) > curses.echo() > curses.nocbreak() > curses.endwin() > > Andrew: can you make this change? I'll test it and make the change in my masters if it works for both cases. I haven't actually shipped the box of goodies yet... -- Eric S. Raymond Alcohol still kills more people every year than all `illegal' drugs put together, and Prohibition only made it worse. Oppose the War On Some Drugs! From esr@thyrsus.com Sun Jun 11 00:50:27 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Sat, 10 Jun 2000 19:50:27 -0400 Subject: [Python-Dev] Creating curses package: done In-Reply-To: <20000610193312.A26098@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Sat, Jun 10, 2000 at 07:33:12PM -0400 References: <200006100748.DAA17920@snark.thyrsus.com> <20000610111323.A24895@newcnri.cnri.reston.va.us> <20000610113124.B18982@thyrsus.com> <20000610114250.A25014@newcnri.cnri.reston.va.us> <14658.33196.426211.329070@anthem.concentric.net> <20000610193312.A26098@newcnri.cnri.reston.va.us> Message-ID: <20000610195027.B882@thyrsus.com> Andrew Kuchling : > The textbox stuff poses two problems. First, it requires ascii.py, > and wasn't the decision to wait for GvR on adding that module? > Second, Eric, I'm not sure what you want as the module name for the > textbox stuff: textbox.py? Your call... (I'll check it in, and if > ascii.py is vetoed, it can be rewritten to not require ascii.py, or > we can have curses.ascii.) I thought it was going to become part of curses from the user's point of view, so that "import curses" brings it in. That seemed to be the intent of the request at the end of the curses HOWTO. -- Eric S. Raymond "Taking my gun away because I might shoot someone is like cutting my tongue out because I might yell `Fire!' in a crowded theater." -- Peter Venetoklis From akuchlin@mems-exchange.org Sun Jun 11 00:44:54 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Sat, 10 Jun 2000 19:44:54 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses __init__.py,NONE,1.1 wrapper.py,NONE,1.1 In-Reply-To: <20000610194822.A882@thyrsus.com>; from esr@thyrsus.com on Sat, Jun 10, 2000 at 07:48:22PM -0400 References: <200006102306.QAA18088@slayer.i.sourceforge.net> <20000610163013.B19484@lyra.org> <20000610194822.A882@thyrsus.com> Message-ID: <20000610194454.B26098@newcnri.cnri.reston.va.us> On Sat, Jun 10, 2000 at 07:48:22PM -0400, Eric S. Raymond wrote: >I'll test it and make the change in my masters if it works for both >cases. I haven't actually shipped the box of goodies yet... Already tested and checked in. If you make other changes, just ship me the new version. (Oh, I forgot about the stupid legal stuff; you should probably send wrapper.py and textbox.py to patches@python.org with the requisite legal disclaimer.) --amk From esr@thyrsus.com Sun Jun 11 00:59:31 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Sat, 10 Jun 2000 19:59:31 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses __init__.py,NONE,1.1 wrapper.py,NONE,1.1 In-Reply-To: <20000610194454.B26098@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Sat, Jun 10, 2000 at 07:44:54PM -0400 References: <200006102306.QAA18088@slayer.i.sourceforge.net> <20000610163013.B19484@lyra.org> <20000610194822.A882@thyrsus.com> <20000610194454.B26098@newcnri.cnri.reston.va.us> Message-ID: <20000610195931.A985@thyrsus.com> Andrew Kuchling : > On Sat, Jun 10, 2000 at 07:48:22PM -0400, Eric S. Raymond wrote: > >I'll test it and make the change in my masters if it works for both > >cases. I haven't actually shipped the box of goodies yet... > > Already tested and checked in. If you make other changes, just ship > me the new version. Well, dang. Didn't you want me to document it first? :-) -- Eric S. Raymond Rifles, muskets, long-bows and hand-grenades are inherently democratic weapons. A complex weapon makes the strong stronger, while a simple weapon -- so long as there is no answer to it -- gives claws to the weak. -- George Orwell, "You and the Atom Bomb", 1945 From akuchlin@mems-exchange.org Sun Jun 11 00:51:30 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Sat, 10 Jun 2000 19:51:30 -0400 Subject: [Python-Dev] Creating curses package: done In-Reply-To: <20000610195027.B882@thyrsus.com>; from esr@thyrsus.com on Sat, Jun 10, 2000 at 07:50:27PM -0400 References: <200006100748.DAA17920@snark.thyrsus.com> <20000610111323.A24895@newcnri.cnri.reston.va.us> <20000610113124.B18982@thyrsus.com> <20000610114250.A25014@newcnri.cnri.reston.va.us> <14658.33196.426211.329070@anthem.concentric.net> <20000610193312.A26098@newcnri.cnri.reston.va.us> <20000610195027.B882@thyrsus.com> Message-ID: <20000610195130.C26098@newcnri.cnri.reston.va.us> On Sat, Jun 10, 2000 at 07:50:27PM -0400, Eric S. Raymond wrote: >I thought it was going to become part of curses from the user's point >of view, so that "import curses" brings it in. That seemed to be the >intent of the request at the end of the curses HOWTO. Ooh, no; that text is saying that an editor would make a good example to put in the HOWTO. I'd rather have the curses module contain only a fairly close mapping of the C API, and extensions written in Python would be in submodules like curses.editor, curses.textbox, whatever. Similar to how socketmodule.c is a thin veneer over the BSD socket API, and the spiffy extensions are in asyncore.py, httplib.py, &c. --amk From nhodgson@bigpond.net.au Sun Jun 11 01:04:53 2000 From: nhodgson@bigpond.net.au (Neil Hodgson) Date: Sun, 11 Jun 2000 10:04:53 +1000 Subject: [Python-Dev] Suggestion to Windows- and Mac-library people References: <20000610114227.A19052@thyrsus.com> Message-ID: <016301bfd338$ab8458f0$e3cb8490@neil> > Obviously this is not portable off Unix. Equally obviously it should > be possible to do an equivalent thing under Windows (at least). For > anybody writing interactive programs in this Web-mad era, this > function is just too useful not to have in the toolbox. So this is a > nudge to any Windows and Mac wizards on this list -- let's make this > function available cross-platform. The most common way on Windows to launch the user's preferred browser with an URL would be: >>> import win32api >>> win32api.ShellExecute(0,None,"http://www.python.org",None,"",1) # Note to Mark - more of the parameters should be optional However this, like most process control stuff, requires the Win32 extensions, not the base Python distribution. Trying to hack this up with os.system would be unpleasant. ShellExecute knows when to do icky stuff like use DDE to open the correct URL. Does this type of UI operation really belong in urllib? Neil From esr@thyrsus.com Sun Jun 11 02:26:08 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Sat, 10 Jun 2000 21:26:08 -0400 Subject: [Python-Dev] Suggestion to Windows- and Mac-library people In-Reply-To: <016301bfd338$ab8458f0$e3cb8490@neil>; from nhodgson@bigpond.net.au on Sun, Jun 11, 2000 at 10:04:53AM +1000 References: <20000610114227.A19052@thyrsus.com> <016301bfd338$ab8458f0$e3cb8490@neil> Message-ID: <20000610212608.A1109@thyrsus.com> Neil Hodgson : > Does this type of UI operation really belong in urllib? It fetches the contents of an URL for inspection. Where else would you put it? -- Eric S. Raymond It would be thought a hard government that should tax its people one tenth part. -- Benjamin Franklin From nhodgson@bigpond.net.au Sun Jun 11 02:51:34 2000 From: nhodgson@bigpond.net.au (Neil Hodgson) Date: Sun, 11 Jun 2000 11:51:34 +1000 Subject: [Python-Dev] Suggestion to Windows- and Mac-library people References: <20000610114227.A19052@thyrsus.com> <016301bfd338$ab8458f0$e3cb8490@neil> <20000610212608.A1109@thyrsus.com> Message-ID: <01af01bfd347$937b3fd0$e3cb8490@neil> > > Does this type of UI operation really belong in urllib? > > It fetches the contents of an URL for inspection. Where else would you put it? os? Or a submodule of os. The current os has a bunch of executable-oriented process creation and managment functions. On Macintosh and Windows, data-oriented process creation would be useful. os.process.open("http://www.python.org") os.process.print("c:\src\map.png") Neil From esr@thyrsus.com Sun Jun 11 03:14:56 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Sat, 10 Jun 2000 22:14:56 -0400 Subject: [Python-Dev] Suggestion to Windows- and Mac-library people In-Reply-To: <01af01bfd347$937b3fd0$e3cb8490@neil>; from nhodgson@bigpond.net.au on Sun, Jun 11, 2000 at 11:51:34AM +1000 References: <20000610114227.A19052@thyrsus.com> <016301bfd338$ab8458f0$e3cb8490@neil> <20000610212608.A1109@thyrsus.com> <01af01bfd347$937b3fd0$e3cb8490@neil> Message-ID: <20000610221456.A1223@thyrsus.com> Neil Hodgson : > > It fetches the contents of an URL for inspection. Where else would you > put it? > > os? > Or a submodule of os. > > The current os has a bunch of executable-oriented process creation and > managment functions. On Macintosh and Windows, data-oriented process > creation would be useful. I don't really care where it lives, and will cheerfully defer to those with religious beliefs about the namespace ;-). If it's not obvious, this flurry of library suggestions you've been seeing from me lately all come straight out of the CML2 project. I use the urlbrowse() function to make URLs in help windows into live objects that you can click on. -- Eric S. Raymond This would be the best of all possible worlds, if there were no religion in it. -- John Adams, in a letter to Thomas Jefferson. From esr@snark.thyrsus.com Sun Jun 11 05:29:37 2000 From: esr@snark.thyrsus.com (Eric S. Raymond) Date: Sun, 11 Jun 2000 00:29:37 -0400 Subject: [Python-Dev] Greg Stein's correction broke my traceback wrapper Message-ID: <200006110429.AAA01719@snark.thyrsus.com> Greg Stein's correction broke my traceback wrapper. I now do *not* see a traceback on an exit due to Python runtime errors. I don't know why this is. -- Eric S. Raymond No one who's seen it in action can say the phrase "government help" without either laughing or crying. From gstein@lyra.org Sun Jun 11 06:44:30 2000 From: gstein@lyra.org (Greg Stein) Date: Sat, 10 Jun 2000 22:44:30 -0700 Subject: [Python-Dev] Greg Stein's correction broke my traceback wrapper In-Reply-To: <200006110429.AAA01719@snark.thyrsus.com>; from esr@snark.thyrsus.com on Sun, Jun 11, 2000 at 12:29:37AM -0400 References: <200006110429.AAA01719@snark.thyrsus.com> Message-ID: <20000610224430.E19484@lyra.org> On Sun, Jun 11, 2000 at 12:29:37AM -0400, Eric S. Raymond wrote: > Greg Stein's correction broke my traceback wrapper. I now do *not* > see a traceback on an exit due to Python runtime errors. I don't know > why this is. That's strange... a "finally" does not munge tracebacks at all. An exception from a lower level should propagate outwards without interference. Do you still have an "except:" in your code somewhere? (that could be eating your exception) Maybe your test case isn't failing as expected :-) If you'd like, post a copy of the test, and we can debug the wrapper and/or test. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Sun Jun 11 12:01:50 2000 From: gstein@lyra.org (Greg Stein) Date: Sun, 11 Jun 2000 04:01:50 -0700 Subject: [Python-Dev] more on httplib In-Reply-To: ; from gstein@lyra.org on Sat, Jun 03, 2000 at 04:13:55PM -0700 References: Message-ID: <20000611040150.K19484@lyra.org> All of the work below has been completed except for the errno==32 stuff. Module: http://www.lyra.org/greg/python/httplib.py History: http://www.lyra.org/cgi-bin/viewcvs.cgi/gjspy/httplib.py/ There are three items left, that I know of: 1) need doc for new stuff 2) need new test cases 3) I want to remove a "feature" of the old HTTP class. This would be a change in behavior, but (IMO) minor. Specifically, if the Status-Line is malformed, the old httplib.py would return (-1, , None) and store into self.file. Nominally, that file object allows a client to read more data from the socket after the parse problem on the malformed Status-Line. I think it is useless, unused by any clients out there, and it causes me pain to provide it :-) I'd like to just store None into self.file Thoughts? Comments? I'd like to get this thing into Python RSN. Cheers, -g On Sat, Jun 03, 2000 at 04:13:55PM -0700, Greg Stein wrote: > I would like to propose a few changes to the (new) httplib: > > *) drop HTTPS() -- this class isn't in 1.5.2, so there isn't a reason to > provide backwards-compat for it > > *) revamp the pipeline support: > > - record the "last response object" ... when a new getreply() is done, > then we store the "last" into response.prior > - reading of the "HTTP/1.1 " line is deferred, and > performed by the response object > - the read of that line is lazy > - if the response line is read *before* the "prior" response (if any) > is "closed", then an exception is raised: ResponseNotReady > > *) address some of Moshe's concerns: > > - use class-based exceptions > - clarify that HTTPConnection is designed for *blocking* sockets > - conn.close() followed by conn.send() will reopen the socket. This > could lead to programming errors. I'll add a class-based default flag > to disable this behavior. > - in request(), we check for errno==32 ... what to do on Windows? > > > I will implement these changes in small chunks so that each can be > reviewed in my CVS repository. The history is available at: > > http://www.lyra.org/cgi-bin/viewcvs.cgi/gjspy/httplib.py/ -- Greg Stein, http://www.lyra.org/ From Moshe Zadka Sun Jun 11 12:58:28 2000 From: Moshe Zadka (Moshe Zadka) Date: Sun, 11 Jun 2000 14:58:28 +0300 (IDT) Subject: [Python-Dev] more on httplib In-Reply-To: <20000611040150.K19484@lyra.org> Message-ID: On Sun, 11 Jun 2000, Greg Stein wrote: > 3) I want to remove a "feature" of the old HTTP class. This would be a > change in behavior, but (IMO) minor. Specifically, if the Status-Line > is malformed, the old httplib.py would return (-1, , > None) and store into self.file. Nominally, > that file object allows a client to read more data from the socket > after the parse problem on the malformed Status-Line. I think it is > useless, unused by any clients out there, and it causes me pain to > provide it :-) I'd like to just store None into self.file What do the old docs say about this? \begin{methoddesc}{getfile}{} Return a file object from which the data returned by the server can be read, using the \method{read()}, \method{readline()} or \method{readlines()} methods. \end{methoddesc} So why not put a "dummy" file: one whose read(), readline() or readlines() act as if it was at EOF? (IOW, the Pythonic equivalent of open("/dev/null")) -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com From akuchlin@mems-exchange.org Sun Jun 11 14:19:48 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Sun, 11 Jun 2000 09:19:48 -0400 Subject: [Python-Dev] Greg Stein's correction broke my traceback wrapper In-Reply-To: <20000610224430.E19484@lyra.org>; from gstein@lyra.org on Sat, Jun 10, 2000 at 10:44:30PM -0700 References: <200006110429.AAA01719@snark.thyrsus.com> <20000610224430.E19484@lyra.org> Message-ID: <20000611091948.A27835@newcnri.cnri.reston.va.us> On Sat, Jun 10, 2000 at 10:44:30PM -0700, Greg Stein wrote: >On Sun, Jun 11, 2000 at 12:29:37AM -0400, Eric S. Raymond wrote: >> Greg Stein's correction broke my traceback wrapper. >If you'd like, post a copy of the test, and we can debug the wrapper >and/or test. I'll leave it to the two of you to figure out what's going on and submit a corrected version, if necessary. I did test the simplified version and it seemed fine, though maybe there's a subtle problem. I'm off to CA, and will be back on Wednesday. (Mmmm... hours of plane hacking...) --amk From gstein@lyra.org Sun Jun 11 20:18:26 2000 From: gstein@lyra.org (Greg Stein) Date: Sun, 11 Jun 2000 12:18:26 -0700 Subject: [Python-Dev] more on httplib In-Reply-To: ; from moshez@math.huji.ac.il on Sun, Jun 11, 2000 at 02:58:28PM +0300 References: <20000611040150.K19484@lyra.org> Message-ID: <20000611121826.L19484@lyra.org> On Sun, Jun 11, 2000 at 02:58:28PM +0300, Moshe Zadka wrote: > On Sun, 11 Jun 2000, Greg Stein wrote: > > > 3) I want to remove a "feature" of the old HTTP class. This would be a > > change in behavior, but (IMO) minor. Specifically, if the Status-Line > > is malformed, the old httplib.py would return (-1, , > > None) and store into self.file. Nominally, > > that file object allows a client to read more data from the socket > > after the parse problem on the malformed Status-Line. I think it is > > useless, unused by any clients out there, and it causes me pain to > > provide it :-) I'd like to just store None into self.file > > What do the old docs say about this? > > \begin{methoddesc}{getfile}{} > Return a file object from which the data returned by the server can be > read, using the \method{read()}, \method{readline()} or > \method{readlines()} methods. > \end{methoddesc} > > So why not put a "dummy" file: one whose read(), readline() or readlines() > act as if it was at EOF? > (IOW, the Pythonic equivalent of open("/dev/null")) Sure, I can put different things there, but that would also be a change in semantics. The backwards compat class, HTTP, preserves the API completely -- even down to how it reacts in error situations. (although, it *can* raise errors that it didn't before, when you use methods in the wrong order) I'd like to make a change in the semantics for this particular error condition. Where a client used to be able to do: errcode, errmsg, hdrs = h.getreply() if errcode == -1: file = h.getfile() print 'ERROR: some kind of error occurred' print ' partial read:', `errmsg` print ' next 100 bytes:', `file.read(100)` I'd like to eliminate that "next 100 bytes" ability, and just close the socket when a protocol error occurs. Before making a change in behavior for this (central) class, I'd like to get some feedback. Some voting? Cheers, -g -- Greg Stein, http://www.lyra.org/ From andy@reportlab.com Mon Jun 12 12:45:57 2000 From: andy@reportlab.com (Andy Robinson) Date: Mon, 12 Jun 2000 12:45:57 +0100 Subject: [Python-Dev] Japanese Codecs In-Reply-To: <20000610160032.0004A1CFA2@dinsdale.python.org> Message-ID: > > Message: 2 > From: "David Ascher" > To: "Python Developers @ python.org" > Subject: RE: [Python-Dev] Japanese Codecs > Date: Fri, 9 Jun 2000 11:54:03 -0700 > charset="US-ASCII" > > > I just wish that these packagers actually become a reality > > some day... the concept is good, but there currently seem to > > be no volunteers or companies jumping in :-( > > I can't speak for Japanese packagers, but ActiveState will be packaging > Python in various ways. > The handful of Python users who know some Japanese are kind of busy at the moment, and the codec work takes more than a night or two; I was hoping to tackle it myself, but as the only Python startup without any venture funding, it is hard to clear aside the time without a customer; and it also needs C skills. I believe we should try and put resources together to fund this work and ensure it gets done this year. I can tell you that HP are now well and truly out of the picture as a sponsor. AFAIK the organisations who should talk are at least... PythonLabs/BeOpen ActiveState Digital Garage PythonWare / Secret Labs ??? (not sure how rapid their global plans are) ReportLab Are there any others? Please get in touch with me... feeling-rather-guilty-as-i18n-sig-coordinator-ly-yrs, Andy Robinson From mal@lemburg.com Mon Jun 12 13:51:11 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 12 Jun 2000 14:51:11 +0200 Subject: [Python-Dev] Japanese Codecs References: Message-ID: <3944DCBF.34DA9E4B@lemburg.com> Andy Robinson wrote: > > > > I just wish that these packagers actually become a reality > > > some day... the concept is good, but there currently seem to > > > be no volunteers or companies jumping in :-( > > > > I can't speak for Japanese packagers, but ActiveState will be packaging > > Python in various ways. > > > The handful of Python users who know some Japanese are kind of busy at the > moment, and the codec work takes more than a night or two; I was hoping to > tackle it myself, but as the only Python startup without any venture > funding, it is hard to clear aside the time without a customer; and it also > needs C skills. > > I believe we should try and put resources together to fund this work and > ensure it gets done this year. I can tell you that HP are now well and > truly out of the picture as a sponsor. How come ...wheren't they the initial sponsors for the i18n of Python ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gstein@lyra.org Mon Jun 12 19:19:07 2000 From: gstein@lyra.org (Greg Stein) Date: Mon, 12 Jun 2000 11:19:07 -0700 Subject: [Python-Dev] Japanese Codecs In-Reply-To: ; from andy@robanal.demon.co.uk on Mon, Jun 12, 2000 at 12:45:57PM +0100 References: <20000610160032.0004A1CFA2@dinsdale.python.org> Message-ID: <20000612111907.B19484@lyra.org> On Mon, Jun 12, 2000 at 12:45:57PM +0100, Andy Robinson wrote: > > Message: 2 > > From: "David Ascher" > > To: "Python Developers @ python.org" > > Subject: RE: [Python-Dev] Japanese Codecs > > Date: Fri, 9 Jun 2000 11:54:03 -0700 > > charset="US-ASCII" > > > > > I just wish that these packagers actually become a reality > > > some day... the concept is good, but there currently seem to > > > be no volunteers or companies jumping in :-( > > > > I can't speak for Japanese packagers, but ActiveState will be packaging > > Python in various ways. > > > The handful of Python users who know some Japanese are kind of busy at the > moment, and the codec work takes more than a night or two; I was hoping to > tackle it myself, but as the only Python startup without any venture > funding, it is hard to clear aside the time without a customer; and it also > needs C skills. > > I believe we should try and put resources together to fund this work and > ensure it gets done this year. Um... why is it incumbent upon "us" (for whatever definition of "us" you want to apply :-) to find/fund the work for the Japanese codecs? Why isn't this up to the people who want/need it? Yes, being proactive is a very nice thing to do, but I don't see that we must be, in this case. > I can tell you that HP are now well and truly out of the picture as a > sponsor. eh? What's going on with that? Cheers, -g -- Greg Stein, http://www.lyra.org/ From bwarsaw@python.org Mon Jun 12 21:53:10 2000 From: bwarsaw@python.org (Barry A. Warsaw) Date: Mon, 12 Jun 2000 16:53:10 -0400 (EDT) Subject: [Python-Dev] Towards 1.6 Final Message-ID: <14661.19894.465676.770545@anthem.concentric.net> Okay, let me just preface this by saying none of the following has been blessed by Guido in any way. I'm sure he's still getting nice and tan and drinking exotic tropical alcohol-based beverages, and not thinking about Python one little bit. :) Fred and Jeremy and I had a meeting today and thought about a schedule /we'd/ like to see for Python 1.6 final. This may or may not be feasible but I throw it out here for discussion anyway. The O'Reilly Open Source conference[1] starts July 17th and it would be a nice target to release 1.6 final on the 14th, the Friday before the conference. We all plan on being there.n What do we need to do to hit this target? If we figure a 2 week beta cycle, 1.6beta1 would have to be released June 30, with probably the last alpha on June 23. This is a tight schedule; is it even feasible?. Looking at Andrew's TODO list[2], here's what we came up with: - import hooks revamped (push this to 1.7) - update docos to match 1.6 changes (Fred is going to integrate what's sitting in his inbox) - document more undocumented modules (codes - done; unicodedata - needs work; mmap & pyexpat - Fred to integrate; curses - needs updates; regrtest - push to 1.7, see below) - Unicode: Compress the size of unicodedatabase (waiting for Chris Tismer patches?) - Unicode: Write \N{SMILEY} codec for Unicode (Bill Tutt has a patch, but none of us know what the state of this is -- is it crucial anyway?). - Unicode: the various XXX items in Misc/unicode.txt (we didn't actually find such outstanding issues in this file). - Delete obsolete subdirs in Demo/ directory (done) - Refurbish Demo subdirs to be properly documented, match modern coding style, etc. (???) - Fix ./ld_so_aix installation problem on AIX (anybody know more about this???) - Make test/regrtest.py more usable outside of the Python test suite & document it. (push to 1.7) - Conservative GC, of cycles (this is basically done but needs a lot more testing) - Changes to PyExpat module (Fred says this is done) - Test the hell out of SRE. (waiting for /F's complete implementation) - enable threads by default if OS supports it - integrate intl/gettext module - clear the patches and bugs backlog As we saw it the most critical things that need to get done are testing the GC stuff and the SRE module. Of those, the most critical is SRE since AFAIK, we're still waiting for the final complete code from /F. I could be wrong about that. The last three weren't on Andrew's list. I'm on the hook for enabling threads support by default and integrating intl/gettext. I think those will just be a couple of days work. The final one requires Us to go through the outstanding bug and patches lists and address the critical bugs. Thoughts? What have I missed? -Barry [1] http://conferences.oreilly.com/oscon2000/ [2] http://starship.python.net/crew/amk/python/1.6-jobs.html From gstein@lyra.org Tue Jun 13 01:32:14 2000 From: gstein@lyra.org (Greg Stein) Date: Mon, 12 Jun 2000 17:32:14 -0700 Subject: [Python-Dev] Towards 1.6 Final In-Reply-To: <14661.19894.465676.770545@anthem.concentric.net>; from bwarsaw@python.org on Mon, Jun 12, 2000 at 04:53:10PM -0400 References: <14661.19894.465676.770545@anthem.concentric.net> Message-ID: <20000612173214.F19484@lyra.org> On Mon, Jun 12, 2000 at 04:53:10PM -0400, Barry A. Warsaw wrote: > ... disclaimers applied ... > > - import hooks revamped (push this to 1.7) The latest thought had two items here: 1) incorporate feedback into imputil.py. [ the feedback is visible at the end of the most recent version: http://www.lyra.org/cgi-bin/viewcvs.cgi/gjspy/imputil.py/ ] 2) drop imputil into the standard library, but don't go down the "replace Python's default mechanism with imputil" Essentially, this gets imputil out there and usable, but it doesn't directly impact Python's operation in 1.6. >... > - Unicode: Write \N{SMILEY} codec for Unicode (Bill Tutt has a patch, > but none of us know what the state of this is -- is it crucial > anyway?). Bill posted some patches. Little feedback. He will be reposting an updated patch. >... > - Conservative GC, of cycles (this is basically done but needs a lot > more testing) I would recommend doing this in small, reviewable steps. I believe there are a lot of "framework" changes that can occur without actually changing Python itself. After that first round, which will make adding GC easier, then we can do Step 2 and add the real GC stuff. >... New item: - replace httplib.py with Greg's new module. plus docs/test. >... > As we saw it the most critical things that need to get done are > testing the GC stuff and the SRE module. Of those, the most critical > is SRE since AFAIK, we're still waiting for the final complete code > from /F. I could be wrong about that. I believe his recent patch (which AMK applied) brings it up to "current". Cheers, -g -- Greg Stein, http://www.lyra.org/ From Vladimir.Marangozov@inrialpes.fr Tue Jun 13 03:37:23 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Tue, 13 Jun 2000 04:37:23 +0200 (CEST) Subject: [Python-Dev] Towards 1.6 Final In-Reply-To: <14661.19894.465676.770545@anthem.concentric.net> from "Barry A. Warsaw" at Jun 12, 2000 04:53:10 PM Message-ID: <200006130237.EAA10373@python.inrialpes.fr> Barry A. Warsaw wrote: > > - document more undocumented modules (codes - done; unicodedata - > needs work; mmap & pyexpat - Fred to integrate; curses - needs > updates; regrtest - push to 1.7, see below) + Write missing bits in the extend/embed docs (me) Also, last time I ran the 1.6 alpha on AIX, test_mmap failed. I have to take a closer look at this... > - Fix ./ld_so_aix installation problem on AIX (anybody know more about > this???) Yes, AMK, Greg Ward and I know more. It's more an automation (path) problem for building C extensions with distutils than an installation problem per se. Some time ago, I saw a workaround checked in by Greg. If this is still judged as a problem, I'd like to hear about it. This is a minor thing. I have yet to install & run the distutil package on AIX, though, and see what happens. > - enable threads by default if OS supports it Who's going to champion this? I recall Greg Stein volunteering for it ;) (or for something related) > - Test the hell out of SRE. (waiting for /F's complete implementation) ... > As we saw it the most critical things that need to get done are > testing the GC stuff and the SRE module. Of those, the most critical > is SRE since AFAIK, we're still waiting for the final complete code > from /F. I could be wrong about that. It thas been my impression that people are pushing /F for SRE deliveries, but he feels uncomfortable with a number of Unicode compromises (affecting the SRE code and/or design???) and has some implementation hesitations. Add to this the pression of the recent PythonWorks' release. In this context, if there's something to be finished, it would be nice to stop pushing him and help him finishing this project. Unfortunately, I can't offer any help as I don't know much about RE engines. -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From bwarsaw@python.org Tue Jun 13 14:17:07 2000 From: bwarsaw@python.org (bwarsaw@python.org) Date: Tue, 13 Jun 2000 09:17:07 -0400 (EDT) Subject: [Python-Dev] Towards 1.6 Final References: <14661.19894.465676.770545@anthem.concentric.net> <200006130237.EAA10373@python.inrialpes.fr> Message-ID: <14662.13395.520180.272688@anthem.concentric.net> >>>>> "VM" == Vladimir Marangozov writes: >> - enable threads by default if OS supports it VM> Who's going to champion this? I recall Greg Stein volunteering VM> for it ;) (or for something related) This isn't the free-threading stuff, which I think we're pushing back to 1.7, right? Just making --with-threads turned on by default if the OS supports it. >> - Test the hell out of SRE. (waiting for /F's complete >> implementation) VM> ... >> As we saw it the most critical things that need to get done are >> testing the GC stuff and the SRE module. Of those, the most >> critical is SRE since AFAIK, we're still waiting for the final >> complete code from /F. I could be wrong about that. VM> It thas been my impression that people are pushing /F for SRE VM> deliveries, but he feels uncomfortable with a number of VM> Unicode compromises (affecting the SRE code and/or design???) VM> and has some implementation hesitations. Add to this the VM> pression of the recent PythonWorks' release. In this context, VM> if there's something to be finished, it would be nice to stop VM> pushing him and help him finishing this VM> project. Unfortunately, I can't offer any help as I don't know VM> much about RE engines. Neither do I. /F, how can we help? -Barry From mal@lemburg.com Tue Jun 13 14:18:59 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 13 Jun 2000 15:18:59 +0200 Subject: [Python-Dev] Towards 1.6 Final References: <14661.19894.465676.770545@anthem.concentric.net> <200006130237.EAA10373@python.inrialpes.fr> <14662.13395.520180.272688@anthem.concentric.net> Message-ID: <394634C3.9C217913@lemburg.com> bwarsaw@python.org wrote: > > >>>>> "VM" == Vladimir Marangozov writes: > > >> - enable threads by default if OS supports it > > VM> Who's going to champion this? I recall Greg Stein volunteering > VM> for it ;) (or for something related) > > This isn't the free-threading stuff, which I think we're pushing back > to 1.7, right? Just making --with-threads turned on by default if the > OS supports it. Ehm, didn't we agree on not enabling this by default ? From what I've heard there are simply too many problems with thread implementations which cause Python to break in different ways (not necessarily Python's faults). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gstein@lyra.org Tue Jun 13 14:26:08 2000 From: gstein@lyra.org (Greg Stein) Date: Tue, 13 Jun 2000 06:26:08 -0700 Subject: [Python-Dev] Towards 1.6 Final In-Reply-To: <394634C3.9C217913@lemburg.com>; from mal@lemburg.com on Tue, Jun 13, 2000 at 03:18:59PM +0200 References: <14661.19894.465676.770545@anthem.concentric.net> <200006130237.EAA10373@python.inrialpes.fr> <14662.13395.520180.272688@anthem.concentric.net> <394634C3.9C217913@lemburg.com> Message-ID: <20000613062608.A19484@lyra.org> On Tue, Jun 13, 2000 at 03:18:59PM +0200, M.-A. Lemburg wrote: > bwarsaw@python.org wrote: > > > > >>>>> "VM" == Vladimir Marangozov writes: > > > > >> - enable threads by default if OS supports it > > > > VM> Who's going to champion this? I recall Greg Stein volunteering > > VM> for it ;) (or for something related) > > > > This isn't the free-threading stuff, which I think we're pushing back > > to 1.7, right? Just making --with-threads turned on by default if the > > OS supports it. > > Ehm, didn't we agree on not enabling this by default ? From what > I've heard there are simply too many problems with thread > implementations which cause Python to break in different ways > (not necessarily Python's faults). Threads are quite fine nowadays. Windows has enabled threads for years. Recent Linux distros all turn it on. etc No sense in being afraid any more. :-) Cheers, -g p.s. and yes: free-threading is post 1.6 -- Greg Stein, http://www.lyra.org/ From jim@interet.com Tue Jun 13 14:32:33 2000 From: jim@interet.com (James C. Ahlstrom) Date: Tue, 13 Jun 2000 09:32:33 -0400 Subject: [Python-Dev] Towards 1.6 Final References: <14661.19894.465676.770545@anthem.concentric.net> Message-ID: <394637F1.73E24380@interet.com> Just a heads up that there is a patch in patches@python.org to fix a bug in zipfile.py. JimA From mal@lemburg.com Tue Jun 13 14:35:26 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 13 Jun 2000 15:35:26 +0200 Subject: [Python-Dev] Towards 1.6 Final References: <14661.19894.465676.770545@anthem.concentric.net> <200006130237.EAA10373@python.inrialpes.fr> <14662.13395.520180.272688@anthem.concentric.net> <394634C3.9C217913@lemburg.com> <20000613062608.A19484@lyra.org> Message-ID: <3946389E.B9C5E2F5@lemburg.com> Greg Stein wrote: > > On Tue, Jun 13, 2000 at 03:18:59PM +0200, M.-A. Lemburg wrote: > > bwarsaw@python.org wrote: > > > > > > >>>>> "VM" == Vladimir Marangozov writes: > > > > > > >> - enable threads by default if OS supports it > > > > > > VM> Who's going to champion this? I recall Greg Stein volunteering > > > VM> for it ;) (or for something related) > > > > > > This isn't the free-threading stuff, which I think we're pushing back > > > to 1.7, right? Just making --with-threads turned on by default if the > > > OS supports it. > > > > Ehm, didn't we agree on not enabling this by default ? From what > > I've heard there are simply too many problems with thread > > implementations which cause Python to break in different ways > > (not necessarily Python's faults). > > Threads are quite fine nowadays. Windows has enabled threads for years. > Recent Linux distros all turn it on. Ok, then make it default on Linux and Windows... but leave it turned off on other platforms which still have problems such as AIX. > No sense in being afraid any more. :-) Naa, not being afraid :-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From jim@interet.com Tue Jun 13 14:49:36 2000 From: jim@interet.com (James C. Ahlstrom) Date: Tue, 13 Jun 2000 09:49:36 -0400 Subject: [Python-Dev] Towards 1.6 Final References: <14661.19894.465676.770545@anthem.concentric.net> <20000612173214.F19484@lyra.org> Message-ID: <39463BF0.823C0366@interet.com> Greg Stein wrote: > > On Mon, Jun 12, 2000 at 04:53:10PM -0400, Barry A. Warsaw wrote: > > ... disclaimers applied ... > > > > - import hooks revamped (push this to 1.7) > > The latest thought had two items here: > > 1) incorporate feedback into imputil.py. > [ the feedback is visible at the end of the most recent version: > http://www.lyra.org/cgi-bin/viewcvs.cgi/gjspy/imputil.py/ > ] > 2) drop imputil into the standard library, but don't go down the "replace > Python's default mechanism with imputil" > > Essentially, this gets imputil out there and usable, but it doesn't directly > impact Python's operation in 1.6. I would very much like to see imputil.py in the distribution. I currently use ZIP importing, and I have the ZIP importer class done, except that it is based on the old imputil.py. I think ZIP importing could be a popular feature. JimA From Vladimir.Marangozov@inrialpes.fr Tue Jun 13 14:54:13 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Tue, 13 Jun 2000 15:54:13 +0200 (CEST) Subject: [Python-Dev] Towards 1.6 Final In-Reply-To: <3946389E.B9C5E2F5@lemburg.com> from "M.-A. Lemburg" at Jun 13, 2000 03:35:26 PM Message-ID: <200006131354.PAA11656@python.inrialpes.fr> M.-A. Lemburg wrote: > > Ok, then make it default on Linux and Windows... but leave it > turned off on other platforms which still have problems > such as AIX. No, I'd suggest turning it on by default everywhere and provide a --without-thread configure option if it isn't there yet. On AIX there are identified compiler/libthread combinations that work or don't work. They can be detected though and since the compiler is detected earlier, --with-thread can be automatically disabled with a notification message about the conflict. -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From mal@lemburg.com Tue Jun 13 15:05:55 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 13 Jun 2000 16:05:55 +0200 Subject: [Python-Dev] Towards 1.6 Final References: <200006131354.PAA11656@python.inrialpes.fr> Message-ID: <39463FC3.16D6718@lemburg.com> Vladimir Marangozov wrote: > > M.-A. Lemburg wrote: > > > > Ok, then make it default on Linux and Windows... but leave it > > turned off on other platforms which still have problems > > such as AIX. > > No, I'd suggest turning it on by default everywhere and provide a > --without-thread configure option if it isn't there yet. > > On AIX there are identified compiler/libthread combinations that work > or don't work. They can be detected though and since the compiler is > detected earlier, --with-thread can be automatically disabled with a > notification message about the conflict. Ok, let me drop in another argument: How you are going to sell the performance loss due to enabled thread support even when a script doesn't need threads at all ? How about building two versions of the interpreter per default: one with threads enabled and one without threads ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gstein@lyra.org Tue Jun 13 15:09:02 2000 From: gstein@lyra.org (Greg Stein) Date: Tue, 13 Jun 2000 07:09:02 -0700 Subject: [Python-Dev] Towards 1.6 Final In-Reply-To: <39463FC3.16D6718@lemburg.com>; from mal@lemburg.com on Tue, Jun 13, 2000 at 04:05:55PM +0200 References: <200006131354.PAA11656@python.inrialpes.fr> <39463FC3.16D6718@lemburg.com> Message-ID: <20000613070902.G19484@lyra.org> On Tue, Jun 13, 2000 at 04:05:55PM +0200, M.-A. Lemburg wrote: > Vladimir Marangozov wrote: > > > > M.-A. Lemburg wrote: > > > > > > Ok, then make it default on Linux and Windows... but leave it > > > turned off on other platforms which still have problems > > > such as AIX. > > > > No, I'd suggest turning it on by default everywhere and provide a > > --without-thread configure option if it isn't there yet. > > > > On AIX there are identified compiler/libthread combinations that work > > or don't work. They can be detected though and since the compiler is > > detected earlier, --with-thread can be automatically disabled with a > > notification message about the conflict. > > Ok, let me drop in another argument: > > How you are going to sell the performance loss due to > enabled thread support even when a script doesn't > need threads at all ? > > How about building two versions of the interpreter per default: > one with threads enabled and one without threads ? Hey, the sky is falling, too. If people are concerned with the performance and want to eek that gain out, then they can build with --without-threads Not a problem. "Gee. My operating system is too slow because it deals with all these process and threads. Why can't I have a single-process OS like DOS? It runs *so* much faster." :-) -- Greg Stein, http://www.lyra.org/ From bwarsaw@python.org Tue Jun 13 15:34:34 2000 From: bwarsaw@python.org (Barry A. Warsaw) Date: Tue, 13 Jun 2000 10:34:34 -0400 (EDT) Subject: [Python-Dev] Towards 1.6 Final References: <3946389E.B9C5E2F5@lemburg.com> <200006131354.PAA11656@python.inrialpes.fr> Message-ID: <14662.18042.397439.614107@anthem.concentric.net> >>>>> "VM" == Vladimir Marangozov writes: VM> On AIX there are identified compiler/libthread combinations VM> that work or don't work. They can be detected though and since VM> the compiler is detected earlier, --with-thread can be VM> automatically disabled with a notification message about the VM> conflict. Can you provide a list of such combinations? -Barry From mal@lemburg.com Tue Jun 13 15:44:20 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 13 Jun 2000 16:44:20 +0200 Subject: [Python-Dev] Towards 1.6 Final References: <200006131354.PAA11656@python.inrialpes.fr> <39463FC3.16D6718@lemburg.com> <20000613070902.G19484@lyra.org> Message-ID: <394648C4.2A701B5B@lemburg.com> [enabling threads per default] > > > > How you are going to sell the performance loss due to > > enabled thread support even when a script doesn't > > need threads at all ? > > > > How about building two versions of the interpreter per default: > > one with threads enabled and one without threads ? > > Hey, the sky is falling, too. > > If people are concerned with the performance and want to eek that gain out, > then they can build with --without-threads > > Not a problem. > > "Gee. My operating system is too slow because it deals with all these > process and threads. Why can't I have a single-process OS like DOS? It runs > *so* much faster." Oh well... never mind, as long as I can still build my Python without threads, I'm fine :-) BTW, what about the idea of adding threads at Python level that was tossed around a few years ago ? Should be easy to do given Christian's stackless patches together with the asyncore libs... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From bwarsaw@python.org Tue Jun 13 15:47:21 2000 From: bwarsaw@python.org (Barry A. Warsaw) Date: Tue, 13 Jun 2000 10:47:21 -0400 (EDT) Subject: [Python-Dev] Towards 1.6 Final References: <200006131354.PAA11656@python.inrialpes.fr> <39463FC3.16D6718@lemburg.com> Message-ID: <14662.18809.468033.931803@anthem.concentric.net> >>>>> "M" == M writes: M> How about building two versions of the interpreter per default: M> one with threads enabled and one without threads ? Python 1.6, current CVS snapshot on a Dell PIII 650, RH 6.1. with threads: 8547.01 pystones/second without threads: 9259.26 pystones/second So an 8% hit isn't negligible but I think it's acceptable for the benefit of being confidently able to distribute threaded apps. -Barry From petrilli@amber.org Tue Jun 13 16:02:01 2000 From: petrilli@amber.org (Christopher Petrilli) Date: Tue, 13 Jun 2000 11:02:01 -0400 Subject: [Python-Dev] Towards 1.6 Final In-Reply-To: <14662.18809.468033.931803@anthem.concentric.net>; from bwarsaw@python.org on Tue, Jun 13, 2000 at 10:47:21AM -0400 References: <200006131354.PAA11656@python.inrialpes.fr> <39463FC3.16D6718@lemburg.com> <14662.18809.468033.931803@anthem.concentric.net> Message-ID: <20000613110201.B25344@trump.amber.org> Barry A. Warsaw [bwarsaw@python.org] wrote: > > >>>>> "M" == M writes: > > M> How about building two versions of the interpreter per default: > M> one with threads enabled and one without threads ? > > Python 1.6, current CVS snapshot on a Dell PIII 650, RH 6.1. > > with threads: 8547.01 pystones/second > without threads: 9259.26 pystones/second > > So an 8% hit isn't negligible but I think it's acceptable for the > benefit of being confidently able to distribute threaded apps. Just as a data point, in the "Python problems" with Zope, this, along with soe idiocy in packaging of RPMs in RedHat are the two biggest problems we have a the Python level. People not compiling with threads turned on, and RedHat's decision to ship the header files separate than the regular Python files. BLAH! Chris -- | Christopher Petrilli | petrilli@amber.org From bwarsaw@python.org Tue Jun 13 15:52:24 2000 From: bwarsaw@python.org (Barry A. Warsaw) Date: Tue, 13 Jun 2000 10:52:24 -0400 (EDT) Subject: [Python-Dev] Towards 1.6 Final References: <200006131354.PAA11656@python.inrialpes.fr> <39463FC3.16D6718@lemburg.com> <20000613070902.G19484@lyra.org> <394648C4.2A701B5B@lemburg.com> Message-ID: <14662.19112.118940.63296@anthem.concentric.net> >>>>> "M" == M writes: M> BTW, what about the idea of adding threads at Python level M> that was tossed around a few years ago ? Should be easy to M> do given Christian's stackless patches together with the M> asyncore libs... Definitely not for 1.6! From mal@lemburg.com Tue Jun 13 16:17:13 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 13 Jun 2000 17:17:13 +0200 Subject: [Python-Dev] Towards 1.6 Final References: <200006131354.PAA11656@python.inrialpes.fr> <39463FC3.16D6718@lemburg.com> <20000613070902.G19484@lyra.org> <394648C4.2A701B5B@lemburg.com> <14662.19112.118940.63296@anthem.concentric.net> Message-ID: <39465079.64174882@lemburg.com> "Barry A. Warsaw" wrote: > > >>>>> "M" == M writes: > > M> BTW, what about the idea of adding threads at Python level > M> that was tossed around a few years ago ? Should be easy to > M> do given Christian's stackless patches together with the > M> asyncore libs... > > Definitely not for 1.6! Sure... just wanted to add a hint for 1.7 :-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From DavidA@ActiveState.com Tue Jun 13 18:31:32 2000 From: DavidA@ActiveState.com (David Ascher) Date: Tue, 13 Jun 2000 10:31:32 -0700 Subject: [Python-Dev] O'Reilly Python Conference Early Registration Deadline Looming Message-ID: It's that time of year again, the O'Reilly Open Source Convention, including the Python track, is fast approaching. You can save up to $280 if you register by Friday July 16. The event will be held this July 17-20 in Monterey, California. Meet all the key Python players, meet fellow Python enthusiasts, learn about new Python developments, find Python-related jobs, and have fun at this yearly event in sunny Monterey, CA. For details on the Python tutorials, see http://www.oreillynet.com/pub/w/python_tutorials.html For details on the Python talks, see http://www.oreillynet.com/pub/w/python_presentations.html For details on the Conference as a whole, see http://conferences.oreilly.com/oscon2000/index.html Looking forward to meeting you there, -- David Ascher OSCON Python Track Program Chair Senior Developer, ActiveState Tool Corporation Students and academics should remember to sign up for reduced fees: http://conferences.oreilly.com/oscon2000/register/ From DavidA@ActiveState.com Tue Jun 13 19:00:41 2000 From: DavidA@ActiveState.com (David Ascher) Date: Tue, 13 Jun 2000 11:00:41 -0700 Subject: [Python-Dev] O'Reilly Python Conference Early Registration Deadline Looming In-Reply-To: Message-ID: > It's that time of year again, the O'Reilly Open Source > Convention, including the Python track, is fast approaching. > You can save up to $280 if you register by Friday July 16. Make that June 19. Sorry about that. --david ascher From mal@lemburg.com Tue Jun 13 20:25:04 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 13 Jun 2000 21:25:04 +0200 Subject: [Python-Dev] Towards 1.6 Final References: <14661.19894.465676.770545@anthem.concentric.net> Message-ID: <39468A90.697D1CE5@lemburg.com> "Barry A. Warsaw" wrote: > > The O'Reilly Open Source conference[1] starts July 17th and it would > be a nice target to release 1.6 final on the 14th, the Friday before > the conference. We all plan on being there.n > > What do we need to do to hit this target? If we figure a 2 week beta > cycle, 1.6beta1 would have to be released June 30, with probably the > last alpha on June 23. This is a tight schedule; is it even > feasible?. Looking at Andrew's TODO list[2], here's what we came up > with: > > [...] > - document more undocumented modules (codes - done; unicodedata - > needs work; mmap & pyexpat - Fred to integrate; curses - needs > updates; regrtest - push to 1.7, see below) I'll take care of unicodedata. What's "codes" -- or did you mean codecs ? > - Unicode: Compress the size of unicodedatabase (waiting for Chris > Tismer patches?) Right... > - Unicode: Write \N{SMILEY} codec for Unicode (Bill Tutt has a patch, > but none of us know what the state of this is -- is it crucial > anyway?). Not crucial, but would be nice to have. > - Unicode: the various XXX items in Misc/unicode.txt (we didn't > actually find such outstanding issues in this file). There are no more discussion points... at least not in that file ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From bwarsaw@python.org Tue Jun 13 20:31:51 2000 From: bwarsaw@python.org (bwarsaw@python.org) Date: Tue, 13 Jun 2000 15:31:51 -0400 (EDT) Subject: [Python-Dev] Towards 1.6 Final References: <14661.19894.465676.770545@anthem.concentric.net> <39468A90.697D1CE5@lemburg.com> Message-ID: <14662.35879.156976.61686@anthem.concentric.net> >>>>> "M" == M writes: M> I'll take care of unicodedata. What's "codes" -- or did you M> mean codecs ? Oops, yes, "codecs". M> There are no more discussion points... at least not in that M> file ;-) :) -Barry From gstein@lyra.org Tue Jun 13 21:11:45 2000 From: gstein@lyra.org (Greg Stein) Date: Tue, 13 Jun 2000 13:11:45 -0700 Subject: [Python-Dev] Towards 1.6 Final In-Reply-To: <39463BF0.823C0366@interet.com>; from jim@interet.com on Tue, Jun 13, 2000 at 09:49:36AM -0400 References: <14661.19894.465676.770545@anthem.concentric.net> <20000612173214.F19484@lyra.org> <39463BF0.823C0366@interet.com> Message-ID: <20000613131145.O19484@lyra.org> On Tue, Jun 13, 2000 at 09:49:36AM -0400, James C. Ahlstrom wrote: > Greg Stein wrote: > > On Mon, Jun 12, 2000 at 04:53:10PM -0400, Barry A. Warsaw wrote: > > > ... disclaimers applied ... > > > > > > - import hooks revamped (push this to 1.7) > > > > The latest thought had two items here: > > > > 1) incorporate feedback into imputil.py. > > [ the feedback is visible at the end of the most recent version: > > http://www.lyra.org/cgi-bin/viewcvs.cgi/gjspy/imputil.py/ > > ] > > 2) drop imputil into the standard library, but don't go down the "replace > > Python's default mechanism with imputil" > > > > Essentially, this gets imputil out there and usable, but it doesn't directly > > impact Python's operation in 1.6. > > I would very much like to see imputil.py in the distribution. I > currently > use ZIP importing, and I have the ZIP importer class done, except that > it > is based on the old imputil.py. I think ZIP importing could be a > popular feature. Yes, this should happen. In my current setup, I've got a second module named "importers.py" that has some of the "standard" importers. It would go into there. Oh, so I guess we'd also want to include importers.py into the distro. All of this is preconditioned on getting at least some of that imputil work done that is listed in the TODO area at the bottom of the file... I'm not sure how soon I'll be able to get to that. Cheers, -g -- Greg Stein, http://www.lyra.org/ From Vladimir.Marangozov@inrialpes.fr Wed Jun 14 01:57:05 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Wed, 14 Jun 2000 02:57:05 +0200 (CEST) Subject: [Python-Dev] --with-threads by default (was: Towards 1.6 Final) In-Reply-To: <14662.18042.397439.614107@anthem.concentric.net> from "Barry A. Warsaw" at Jun 13, 2000 10:34:34 AM Message-ID: <200006140057.CAA12560@python.inrialpes.fr> Barry A. Warsaw wrote: > > > >>>>> "VM" == Vladimir Marangozov writes: > > VM> On AIX there are identified compiler/libthread combinations > VM> that work or don't work. They can be detected though and since > VM> the compiler is detected earlier, --with-thread can be > VM> automatically disabled with a notification message about the > VM> conflict. > > Can you provide a list of such combinations? > This is outlined in Misc/AIX-NOTES, section thread support. I've heard that recent versions of gcc work as well, so long as the executable is linked with AIX ld (not GNU ld). Ideally, IMO, there should be an appropriate AC_TRY_RUN little threaded program (or a program suite corresponding to different thread libs and or standards for a given platform) that would disable threads on failure. This approach has the merit of being applicable to all Unix flavors. -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From trentm@activestate.com Wed Jun 14 06:21:42 2000 From: trentm@activestate.com (Trent Mick) Date: Tue, 13 Jun 2000 22:21:42 -0700 Subject: [Python-Dev] Re: stringobject question In-Reply-To: <394701D6.37E6F560@yahoo.com> References: <394701D6.37E6F560@yahoo.com> Message-ID: <20000613222142.A27523@activestate.com> On Tue, Jun 13, 2000 at 10:53:58PM -0500, Al-Amerrho H. Amerin wrote: > Is this a bug or a feature?: > > Python 1.6a2 (#4, Jun 9 2000, 02:22:41) [GCC 2.95.2 19991024 > (release)] on linux2 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) > > >>> ''.isdigit() > 1 > >>> ''.isspace() > 1 > Good point, maybe. The __docs__ say: "S.isdigit() -> int\n\ \n\ Return 1 if there are only digit characters in S,\n\ 0 otherwise."; static char isspace__doc__[] = "S.isspace() -> int\n\ \n\ Return 1 if there are only whitespace characters in S,\n\ 0 otherwise."; I am not an English language lawyer so I could see both interpretations from the doc strings. I agree, that the result with a zero length string is surprising. Hi All, Which should it be? Sorry, if this has been covered. Trent -- Trent Mick trentm@activestate.com From mal@lemburg.com Wed Jun 14 09:43:45 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 14 Jun 2000 10:43:45 +0200 Subject: [Python-Dev] Re: stringobject question References: <394701D6.37E6F560@yahoo.com> <20000613222142.A27523@activestate.com> Message-ID: <394745C1.7FA27DCB@lemburg.com> Trent Mick wrote: > > On Tue, Jun 13, 2000 at 10:53:58PM -0500, Al-Amerrho H. Amerin wrote: > > Is this a bug or a feature?: > > > > Python 1.6a2 (#4, Jun 9 2000, 02:22:41) [GCC 2.95.2 19991024 > > (release)] on linux2 > > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > > Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) > > > > >>> ''.isdigit() > > 1 > > >>> ''.isspace() > > 1 > > > > Good point, maybe. The __docs__ say: > > "S.isdigit() -> int\n\ > \n\ > Return 1 if there are only digit characters in S,\n\ > 0 otherwise."; > > static char isspace__doc__[] = > "S.isspace() -> int\n\ > \n\ > Return 1 if there are only whitespace characters in S,\n\ > 0 otherwise."; > > I am not an English language lawyer so I could see both interpretations from > the doc strings. I agree, that the result with a zero length string is > surprising. > > Hi All, > Which should it be? Sorry, if this has been covered. I guess it's a bug... a subtle one though, because in a certain sense both 1 and 0 are acceptable. But since '' is considered to be false, I think that returning 0 makes more sense. I'll fix this to return 0 for emtpy strings and Unicode objects. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Moshe Zadka Wed Jun 14 09:46:48 2000 From: Moshe Zadka (Moshe Zadka) Date: Wed, 14 Jun 2000 11:46:48 +0300 (IDT) Subject: [Python-Dev] Re: stringobject question In-Reply-To: <394745C1.7FA27DCB@lemburg.com> Message-ID: On Wed, 14 Jun 2000, M.-A. Lemburg wrote: > > > >>> ''.isdigit() > > > 1 > > > >>> ''.isspace() > > > 1 > > > > > > > Good point, maybe. The __docs__ say: > > > > "S.isdigit() -> int\n\ > > \n\ > > Return 1 if there are only digit characters in S,\n\ > > 0 otherwise."; > > > > static char isspace__doc__[] = > > "S.isspace() -> int\n\ > > \n\ > > Return 1 if there are only whitespace characters in S,\n\ > > 0 otherwise."; > > > > I am not an English language lawyer so I could see both interpretations from > > the doc strings. I agree, that the result with a zero length string is > > surprising. > > > > Hi All, > > Which should it be? Sorry, if this has been covered. > > I guess it's a bug... a subtle one though, because in a > certain sense both 1 and 0 are acceptable. But since > '' is considered to be false, I think that returning 0 > makes more sense. > > I'll fix this to return 0 for emtpy strings and Unicode objects. I just realized something: if you change the semantics to mean "number of digits", you'll get the right answer for all 0- and 1- length strings and unicode objects. just-an-observation-ly y'rs, Z. -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com From mal@lemburg.com Wed Jun 14 10:18:10 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 14 Jun 2000 11:18:10 +0200 Subject: [Python-Dev] Re: stringobject question References: Message-ID: <39474DD2.BF51C872@lemburg.com> Moshe Zadka wrote: > > On Wed, 14 Jun 2000, M.-A. Lemburg wrote: > > > > > >>> ''.isdigit() > > > > 1 > > > > >>> ''.isspace() > > > > 1 > > > > > > > > > > Good point, maybe. The __docs__ say: > > > > > > "S.isdigit() -> int\n\ > > > \n\ > > > Return 1 if there are only digit characters in S,\n\ > > > 0 otherwise."; > > > > > > static char isspace__doc__[] = > > > "S.isspace() -> int\n\ > > > \n\ > > > Return 1 if there are only whitespace characters in S,\n\ > > > 0 otherwise."; > > > > > > I am not an English language lawyer so I could see both interpretations from > > > the doc strings. I agree, that the result with a zero length string is > > > surprising. > > > > > > Hi All, > > > Which should it be? Sorry, if this has been covered. > > > > I guess it's a bug... a subtle one though, because in a > > certain sense both 1 and 0 are acceptable. But since > > '' is considered to be false, I think that returning 0 > > makes more sense. > > > > I'll fix this to return 0 for emtpy strings and Unicode objects. > > I just realized something: if you change the semantics to mean "number of > digits", you'll get the right answer for all 0- and 1- length strings > and unicode objects. Hmm, the .isXXX() tests should return 1/0 since they test properties rather than count characters. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From billtut@microsoft.com Wed Jun 14 11:12:48 2000 From: billtut@microsoft.com (Bill Tutt) Date: Wed, 14 Jun 2000 03:12:48 -0700 Subject: [Python-Dev] AIX shared library support Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E4@RED-MSG-50> Is there any particular reason that dynload_aix.c doesn't use AIX's dlopen? From what I can tell, libtool seems to use dlopen on AIX 3.xxx and AIX 4.xxx. I was all set to integrate the \N{...} support into the Unicode-escape encoding, and dynamically load the hash table data in on demand, but dynload_aix only cares about module entry points and won't let you specify an explicit function name. Ugh, how annoying... Bill From mal@lemburg.com Wed Jun 14 11:19:44 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 14 Jun 2000 12:19:44 +0200 Subject: [Python-Dev] AIX shared library support References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E4@RED-MSG-50> Message-ID: <39475C40.EF9CE51B@lemburg.com> Bill Tutt wrote: > > Is there any particular reason that dynload_aix.c doesn't use AIX's dlopen? > >From what I can tell, libtool seems to use dlopen on AIX 3.xxx and AIX > 4.xxx. > > I was all set to integrate the \N{...} support into the Unicode-escape > encoding, and dynamically load the hash table data in on demand, but > dynload_aix only cares about module entry points and won't let you specify > an explicit function name. Uhm, why do you need to go that deep into the internals of the import mechanism ? Wouldn't is suffice to put the hash table into a _ucnhash module which get imported on demand (the import mechanism would then take care of the rest) ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From billtut@microsoft.com Wed Jun 14 11:12:48 2000 From: billtut@microsoft.com (Bill Tutt) Date: Wed, 14 Jun 2000 03:12:48 -0700 Subject: [Python-Dev] AIX shared library support Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E4@RED-MSG-50> Is there any particular reason that dynload_aix.c doesn't use AIX's dlopen? From what I can tell, libtool seems to use dlopen on AIX 3.xxx and AIX 4.xxx. I was all set to integrate the \N{...} support into the Unicode-escape encoding, and dynamically load the hash table data in on demand, but dynload_aix only cares about module entry points and won't let you specify an explicit function name. Ugh, how annoying... Bill From billtut@microsoft.com Wed Jun 14 11:33:11 2000 From: billtut@microsoft.com (Bill Tutt) Date: Wed, 14 Jun 2000 03:33:11 -0700 Subject: [Python-Dev] unicode character name patch status Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E5@RED-MSG-50> I was all set to integrate the \N{...} support into the Unicode-escape encoding, and dynamically load the hash table data in on demand, but dynload_aix only cares about module entry points and won't let you specify an explicit function name. Ugh. So, its question and answer time folks: 1) If we can't dynamically load the hash table data, is it that big of a deal? Probably only for WinCE, palm pilot, etc, and they already have patches against CVS. 2) Or, should I just have a separate encoding? I'd prefer to pick option #1 since Perl natively supports the syntax in their strings. The data is all constant read/only data that will be mmapped directly from the binary, so it only effects working set if the feature is used. Barry, Greg, Guido? The only feedback I got last time I submitted the patch was from MAL, it'd help if some other folks would comment on it. Thanks, Bill From mal@lemburg.com Wed Jun 14 11:45:01 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 14 Jun 2000 12:45:01 +0200 Subject: [Python-Dev] unicode character name patch status References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E5@RED-MSG-50> Message-ID: <3947622D.9995572E@lemburg.com> [Me again, hope you don't mind ;-)] Bill Tutt wrote: > > I was all set to integrate the \N{...} support into the Unicode-escape > encoding, and dynamically load the hash table data in on demand, but > dynload_aix only cares about module entry points and won't let you specify > an explicit function name. > > Ugh. So, its question and answer time folks: > 1) If we can't dynamically load the hash table data, is it that big of > a deal? > Probably only for WinCE, palm pilot, etc, and they already > have patches against CVS. > 2) Or, should I just have a separate encoding? > > I'd prefer to pick option #1 since Perl natively supports the syntax in > their strings. The data is all constant read/only data that will be mmapped > directly from the binary, so it only effects working set if the feature is > used. Why can't you use PyImport_Import() to do the dynamic loading and combine this with the standard unicode-escape codec ? If it fails (e.g. the user has disabled the module entry in Setup), then simply raise an exception. I wouldn't want the hash table around linked statically -- it's simply to big. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From billtut@microsoft.com Wed Jun 14 11:48:49 2000 From: billtut@microsoft.com (Bill Tutt) Date: Wed, 14 Jun 2000 03:48:49 -0700 Subject: [Python-Dev] AIX shared library support Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E6@RED-MSG-50> MAL wrote: > Bill Tutt wrote: > > > > Is there any particular reason that dynload_aix.c doesn't use AIX's dlopen? > > >From what I can tell, libtool seems to use dlopen on AIX 3.xxx and AIX > > 4.xxx. > > > I was all set to integrate the \N{...} support into the Unicode-escape > > encoding, and dynamically load the hash table data in on demand, but > > dynload_aix only cares about module entry points and won't let you specify > > an explicit function name. > Uhm, why do you need to go that deep into the internals > of the import mechanism ? > Wouldn't is suffice to put the hash table into a _ucnhash module > which get imported on demand (the import mechanism would then > take care of the rest) ? It would suffice, but it'd be less efficient (and more work) since I'd then have to access the data/hash functions through the normal PyObject mechanisms instead of directly as C functions. That is, I'm trying to avoid creating a PyString of whatever is inside the braces. (\N{SMILEY}). Then again, maybe I'm just being too performance sensitive. The import mechanism got redone weirdly, all of the ways of doing dynamic loading except AIX encode the idea that the function name must be preceeded by "init". Dynload_xxx.c is the wrong place to put that requirement. Whomever calls _PyImport_GetDynLoadFunc() should handle that issue. Just as an FYI, the only problem I've found so far with my last patch was wrt handling Unicode characters with values in the UCS-4 code space. (Not that there are any yet, but the code must handle that case anyway, sine I don't want to have to go change it later.) Bill From mal@lemburg.com Wed Jun 14 12:00:50 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 14 Jun 2000 13:00:50 +0200 Subject: [Python-Dev] AIX shared library support References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E6@RED-MSG-50> Message-ID: <394765E2.BFBEA135@lemburg.com> Bill Tutt wrote: > > MAL wrote: > > > Bill Tutt wrote: > > > > > > Is there any particular reason that dynload_aix.c doesn't use AIX's > dlopen? > > > >From what I can tell, libtool seems to use dlopen on AIX 3.xxx and AIX > > > 4.xxx. > > > > > I was all set to integrate the \N{...} support into the Unicode-escape > > > encoding, and dynamically load the hash table data in on demand, but > > > dynload_aix only cares about module entry points and won't let you > specify > > > an explicit function name. > > > Uhm, why do you need to go that deep into the internals > > of the import mechanism ? > > > Wouldn't is suffice to put the hash table into a _ucnhash module > > which get imported on demand (the import mechanism would then > > take care of the rest) ? > > It would suffice, but it'd be less efficient (and more work) since I'd then > have to access the data/hash functions through the normal PyObject > mechanisms instead of directly as C functions. That is, I'm trying to avoid > creating a PyString of whatever is inside the braces. (\N{SMILEY}). Then > again, maybe I'm just being too performance sensitive. You could pass a pointer to the char* via a PyCObject. I usually export the whole module C API via such an object and it works great: you can rely on module import to get the magic right and still have a C API around which you can call directly from C -- without the need to wrap anything in Python objects. FYI, mxODBC and mxDateTime are tied together using this mechanism; look in the mxDateTime.h|c files for details. > The import mechanism got redone weirdly, all of the ways of doing dynamic > loading except AIX encode the idea that the function name must be preceeded > by "init". > Dynload_xxx.c is the wrong place to put that requirement. Whomever calls > _PyImport_GetDynLoadFunc() should handle that issue. That's to Greg's address, I guess ;-) > Just as an FYI, the only problem I've found so far with my last patch was > wrt handling Unicode characters with values in the UCS-4 code space. (Not > that there are any yet, but the code must handle that case anyway, sine I > don't want to have to go change it later.) Why is there a problem there ? Python currently uses UTF16 as native format. UTF-16 surrogates are not supported though... and probably won't be for a while. I don't see much of a problem here. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From billtut@microsoft.com Wed Jun 14 12:10:44 2000 From: billtut@microsoft.com (Bill Tutt) Date: Wed, 14 Jun 2000 04:10:44 -0700 Subject: [Python-Dev] AIX shared library support Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E7@RED-MSG-50> MAL: > Bill: > > Just as an FYI, the only problem I've found so far with my last patch was > > wrt handling Unicode characters with values in the UCS-4 code space. (Not > > that there are any yet, but the code must handle that case anyway, sine I > > don't want to have to go change it later.) > Why is there a problem there ? Python currently uses UTF16 > as native format. UTF-16 surrogates are not supported though... > and probably won't be for a while. The rest of Python may not care about UTF-16, but that's no particular reason to not have this code support generating surrogates if an input UnicodeData.txt happens to have character names for code points that require surrogates. Bill From mwh21@cam.ac.uk Wed Jun 14 12:18:27 2000 From: mwh21@cam.ac.uk (Michael Hudson) Date: 14 Jun 2000 12:18:27 +0100 Subject: [Python-Dev] Can starship please have its front page back? Message-ID: I'm not sure if I should ask this here, but I've tried crew@starship and comp.lang.python, so forgive me please. There are links all over the place (eg. python.org, oriellynet) to "http://starship.python.net/", which currently gets the gentle browsing newbie a rather forbidding, somewhat out-of-date status page. I don't really think this gives a good impression. Particularly as said page is no longer on the machine that had the hard disc failure... Cheers, M. From mal@lemburg.com Wed Jun 14 12:36:25 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 14 Jun 2000 13:36:25 +0200 Subject: [Python-Dev] AIX shared library support References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E7@RED-MSG-50> Message-ID: <39476E39.E4163D20@lemburg.com> Bill Tutt wrote: > > MAL: > > Bill: > > > Just as an FYI, the only problem I've found so far with my last patch > was > > > wrt handling Unicode characters with values in the UCS-4 code space. > (Not > > > that there are any yet, but the code must handle that case anyway, sine > I > > > don't want to have to go change it later.) > > > Why is there a problem there ? Python currently uses UTF16 > > as native format. UTF-16 surrogates are not supported though... > > and probably won't be for a while. > > The rest of Python may not care about UTF-16, but that's no particular > reason to not have this code support generating surrogates if an input > UnicodeData.txt happens to have character names for code points that require > surrogates. True. As long as the design permitts generating surrogates, there should be no problem. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Vladimir.Marangozov@inrialpes.fr Wed Jun 14 15:48:01 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Wed, 14 Jun 2000 16:48:01 +0200 (CEST) Subject: [Python-Dev] AIX shared library support In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E4@RED-MSG-50> from "Bill Tutt" at Jun 14, 2000 03:12:48 AM Message-ID: <200006141448.QAA14090@python.inrialpes.fr> Bill Tutt wrote: > > Is there any particular reason that dynload_aix.c doesn't use AIX's dlopen? > >From what I can tell, libtool seems to use dlopen on AIX 3.xxx and AIX > 4.xxx. Historically, the dlopen interface (originally a Sun thing) was included as a standard library (libdl.a) starting from AIX 4.3 (or 4.2). It doesn't exist on AIX 3.x and AIX 4.1.x. There was a dlopen emulation library, though, written by an old AIX guru, but it had to be installed manually on these versions of AIX. Then, slowly, IBM started to be more receptive about some defacto standards, included libdl.a in the standard AIX distribution and introduced the -G flag in ld (a la Sun and others) which adds -ldl to the link automatically. But all this really works on AIX 4.3 and up. So what is implemented in Python relies on lower-level dynamic linker primitives that exist on all AIX releases. Furthermore, our original goal was not to provide a complete (per symbol) runtime linker, hence the current state of affairs. The 'init' entry point convention is a Python convention. It can be changed at link time, but still, there is no a full featured dynamic linker and there is no reason to have it in Python. Python wisely limits itself to the loading of a shared object (lib) in memory, then to invoke an init function, without going into subtle per-platform dynlinking details, which would have been a royal pain to maintain anyway. I second MAL's opinions: you really don't want to be so deep about dynloads and it's better to fit in the current architecture. Personnally, I won't care if my smiley takes half a second to load in memory. :-) -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From gstein@lyra.org Wed Jun 14 16:00:23 2000 From: gstein@lyra.org (Greg Stein) Date: Wed, 14 Jun 2000 08:00:23 -0700 Subject: [Python-Dev] unicode character name patch status In-Reply-To: <3947622D.9995572E@lemburg.com>; from mal@lemburg.com on Wed, Jun 14, 2000 at 12:45:01PM +0200 References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E5@RED-MSG-50> <3947622D.9995572E@lemburg.com> Message-ID: <20000614080023.L27338@lyra.org> On Wed, Jun 14, 2000 at 12:45:01PM +0200, M.-A. Lemburg wrote: >... > Bill Tutt wrote: > > I was all set to integrate the \N{...} support into the Unicode-escape > > encoding, and dynamically load the hash table data in on demand, but > > dynload_aix only cares about module entry points and won't let you specify > > an explicit function name. > > > > Ugh. So, its question and answer time folks: > > 1) If we can't dynamically load the hash table data, is it that big of > > a deal? > > Probably only for WinCE, palm pilot, etc, and they already > > have patches against CVS. > > 2) Or, should I just have a separate encoding? > > > > I'd prefer to pick option #1 since Perl natively supports the syntax in > > their strings. The data is all constant read/only data that will be mmapped > > directly from the binary, so it only effects working set if the feature is > > used. > > Why can't you use PyImport_Import() to do the dynamic loading and > combine this with the standard unicode-escape codec ? > If it fails (e.g. the user has disabled the module entry in > Setup), then simply raise an exception. > > I wouldn't want the hash table around linked statically -- it's > simply to big. I'm with MAL. Use Python's import mechanism. That gets you the dynamic load stuff no problem. It *also* handles the case where the module is statically linked. If you go play games with the dynload stuff, then it would be a bitch to build a single, statically-linked executable. Cheers, -g -- Greg Stein, http://www.lyra.org/ From akuchlin@mems-exchange.org Wed Jun 14 17:13:23 2000 From: akuchlin@mems-exchange.org (Andrew M. Kuchling) Date: Wed, 14 Jun 2000 12:13:23 -0400 Subject: [Python-Dev] Towards 1.6 Final In-Reply-To: <14661.19894.465676.770545@anthem.concentric.net>; from bwarsaw@python.org on Mon, Jun 12, 2000 at 04:53:10PM -0400 References: <14661.19894.465676.770545@anthem.concentric.net> Message-ID: <20000614121323.A13993@amarok.cnri.reston.va.us> On Mon, Jun 12, 2000 at 04:53:10PM -0400, Barry A. Warsaw wrote: >If we figure a 2 week beta cycle, ... Unicode support, a new regex engine, various minor backward incompatible changes that may or may not cause people problems... a 2-week beta seems too short. --amk From billtut@microsoft.com Wed Jun 14 17:29:30 2000 From: billtut@microsoft.com (Bill Tutt) Date: Wed, 14 Jun 2000 09:29:30 -0700 Subject: [Python-Dev] unicode character name patch status Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E8@RED-MSG-50> > From: Greg Stein [mailto:gstein@lyra.org] > I'm with MAL. Use Python's import mechanism. That gets you > the dynamic load > stuff no problem. It *also* handles the case where the module > is statically > linked. > Ok, ok, so much for the idea about modifying as few lines as possible in my patch. :) > If you go play games with the dynload stuff, then it would be > a bitch to > build a single, statically-linked executable. > Nah, thats what the config.h hAVE_... for dynamic load support #define is for. :) Bill From trentm@activestate.com Wed Jun 14 18:36:32 2000 From: trentm@activestate.com (Trent Mick) Date: Wed, 14 Jun 2000 10:36:32 -0700 Subject: [Python-Dev] Re: stringobject question In-Reply-To: <394745C1.7FA27DCB@lemburg.com> References: <394701D6.37E6F560@yahoo.com> <20000613222142.A27523@activestate.com> <394745C1.7FA27DCB@lemburg.com> Message-ID: <20000614103632.C29778@activestate.com> On Wed, Jun 14, 2000 at 10:43:45AM +0200, M . -A . Lemburg wrote: > > I guess it's a bug... a subtle one though, because in a > certain sense both 1 and 0 are acceptable. But since > '' is considered to be false, I think that returning 0 > makes more sense. > > I'll fix this to return 0 for emtpy strings and Unicode objects. These are copied from Java, are they not? What do the Java equivalents return? Trent -- Trent Mick trentm@activestate.com From gstein@lyra.org Wed Jun 14 22:52:08 2000 From: gstein@lyra.org (Greg Stein) Date: Wed, 14 Jun 2000 14:52:08 -0700 Subject: [Python-Dev] unicode character name patch status In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E8@RED-MSG-50>; from billtut@microsoft.com on Wed, Jun 14, 2000 at 09:29:30AM -0700 References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E8@RED-MSG-50> Message-ID: <20000614145208.D28280@lyra.org> On Wed, Jun 14, 2000 at 09:29:30AM -0700, Bill Tutt wrote: > > From: Greg Stein [mailto:gstein@lyra.org] >... > > If you go play games with the dynload stuff, then it would be > > a bitch to > > build a single, statically-linked executable. > > Nah, thats what the config.h hAVE_... for dynamic load support #define is > for. :) Just to beat a dead horse here: no. Just because config.h says that I *could* dynamically load doesn't mean that I *want* to. If I want to build a mother, static Python and I want the name table bundled in, then any dynamic loading that you make explicit is just going to gum up the process. Now shut up, and drink your Kool-Aid. :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From thomas@xs4all.net Thu Jun 15 18:53:27 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Thu, 15 Jun 2000 19:53:27 +0200 Subject: [Python-Dev] Augmented assignment Message-ID: <20000615195327.R8000@xs4all.nl> I'd like some (minor) feedback on the augmented assignment thing I'm working on. I understand Guido is the only one who accepts patches like this, and appreciate that, but I'm hoping someone can at least tell me what I'm doing wrong so I can fix it before Guido sees it ;-) But if I'm being an impatient flap, just tell me so and I'll calm down. I also appreciate the fact that the patch is quite large, and not many people have the time to scrutinize each version, so I'll summerize the issues I'm uncertain about. * The patch needs to add a new type of opcode, one that takes 2 arguments. This is because the opcodes that load, change and store a name need one argument for the index in the name table (or local variable number), and one argument for the actual operation. It could also work by using PyInt or another PyObject to pass the extra argument on the stack, but I don't think pushing a non-PyObject-pointer onto the stack is a good idea. Adding 2-argument opcodes seemed the easiest solution. However, I'm not really into Python-hacking (or was, I should say, because it's great fun) and the python-dev list doesn't seem to be searchable ;) so I can't know if this issue has come up before. Has it ? Would the new opcode-type be an unsurpassable problem ? should I use the stack instead ? * The patch also needs to add 11 new __hooks__, 11 new API calls, 11 new entries in the PyNumberMethods struct and 2 new entries in the PySequenceMethods struct. Would that conceivably be a problem ? I've heard people on the python-list complain about this ;-P * Should I start sending the patch, in pieces, to the patches-list, or is it a wasted effort because noone will touch it until Guido is back ? If I should send it, should I send it in one large patch (minus autogenerated files) or in nice functionality-sized pieces ? * How 'cool' does Guido actually think this syntax is ? Apparently the subject has come up a few times ;) and I got positive signals from both Tim and Guido, but if the patch won't go in as a patch, and won't actually be used other than some inspiration for a future rewrite of the CPython core, I'm not going to worry too much about the patch ;) I'm trying to get my boss to send me to OSCON2000 to harass Guido about these issues himself, but he (my boss) isn't co-operating ;-P (Not suprising, as Python isn't quite part of my job description, *snif*) Regards, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mal@lemburg.com Thu Jun 15 19:12:50 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 15 Jun 2000 20:12:50 +0200 Subject: [Python-Dev] Augmented assignment References: <20000615195327.R8000@xs4all.nl> Message-ID: <39491CA2.2BDC0DDC@lemburg.com> Thomas Wouters wrote: > > I'd like some (minor) feedback on the augmented assignment thing I'm working > on. I understand Guido is the only one who accepts patches like this, and > appreciate that, but I'm hoping someone can at least tell me what I'm doing > wrong so I can fix it before Guido sees it ;-) But if I'm being an impatient > flap, just tell me so and I'll calm down. I'd make this a 1.7 issue. 1.6 should go into the stabilization phase and big complicated patches like yours should receive some more design and concept discussion before getting checked in. BTW, with "augmented assign" I suppose you mean things like a += 1 and b *= 2, right ? > I also appreciate the fact that the patch is quite large, and not many > people have the time to scrutinize each version, so I'll summerize the > issues I'm uncertain about. > > * The patch needs to add a new type of opcode, one that takes 2 arguments. > This is because the opcodes that load, change and store a name need one > argument for the index in the name table (or local variable number), and one > argument for the actual operation. > > It could also work by using PyInt or another PyObject to pass the extra > argument on the stack, but I don't think pushing a non-PyObject-pointer onto > the stack is a good idea. Adding 2-argument opcodes seemed the easiest > solution. > > However, I'm not really into Python-hacking (or was, I should say, because > it's great fun) and the python-dev list doesn't seem to be searchable ;) so > I can't know if this issue has come up before. Has it ? Would the new > opcode-type be an unsurpassable problem ? should I use the stack instead ? Any reason you can't do this with the existing op codes ? E.g. a += b 1. load a 2. load b 3. add 4. store a > * The patch also needs to add 11 new __hooks__, 11 new API calls, 11 new entries > in the PyNumberMethods struct and 2 new entries in the PySequenceMethods > struct. Would that conceivably be a problem ? I've heard people on the > python-list complain about this ;-P More generic solutions are usually more accepted. BTW, before hacking too much into this, you ought to consider that we are planning for rich comparisons and decentralized coercion in 1.7 (this was planned for 1.6, but David and I got carried away with other things). I wouldn't want to have to hack 11 new slots to get this right... > * Should I start sending the patch, in pieces, to the patches-list, or is > it a wasted effort because noone will touch it until Guido is back ? If I > should send it, should I send it in one large patch (minus autogenerated > files) or in nice functionality-sized pieces ? Better put it on a web page and inform python-dev of new features, enhancements, etc. > * How 'cool' does Guido actually think this syntax is ? Apparently the > subject has come up a few times ;) and I got positive signals from both Tim > and Guido, but if the patch won't go in as a patch, and won't actually be > used other than some inspiration for a future rewrite of the CPython core, > I'm not going to worry too much about the patch ;) Having a patch is good for discussion, whether it gets incorporated is a different issue ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From bckfnn@worldonline.dk Thu Jun 15 19:16:03 2000 From: bckfnn@worldonline.dk (Finn Bock) Date: Thu, 15 Jun 2000 18:16:03 GMT Subject: [Python-Dev] Re: stringobject question In-Reply-To: <20000614103632.C29778@activestate.com> References: <394701D6.37E6F560@yahoo.com> <20000613222142.A27523@activestate.com> <394745C1.7FA27DCB@lemburg.com> <20000614103632.C29778@activestate.com> Message-ID: <39491d4f.4591422@smtp.worldonline.dk> >On Wed, Jun 14, 2000 at 10:43:45AM +0200, M . -A . Lemburg wrote: >> >> I guess it's a bug... a subtle one though, because in a >> certain sense both 1 and 0 are acceptable. But since >> '' is considered to be false, I think that returning 0 >> makes more sense. >> >> I'll fix this to return 0 for emtpy strings and Unicode objects. [Trent Mick] >These are copied from Java, are they not? What do the Java equivalents >return? The .isXX methods does not exists on java strings, only on the Character class. So in java they can never be called on anything with length 0. regards, finn From trentm@activestate.com Thu Jun 15 19:28:57 2000 From: trentm@activestate.com (Trent Mick) Date: Thu, 15 Jun 2000 11:28:57 -0700 Subject: [Python-Dev] Re: stringobject question In-Reply-To: <39491d4f.4591422@smtp.worldonline.dk> References: <394701D6.37E6F560@yahoo.com> <20000613222142.A27523@activestate.com> <394745C1.7FA27DCB@lemburg.com> <20000614103632.C29778@activestate.com> <39491d4f.4591422@smtp.worldonline.dk> Message-ID: <20000615112857.A4508@activestate.com> On Thu, Jun 15, 2000 at 06:16:03PM +0000, Finn Bock wrote: > >These are copied from Java, are they not? What do the Java equivalents > >return? > > The .isXX methods does not exists on java strings, only on the Character > class. So in java they can never be called on anything with length 0. > Okeedoke, so go with the changes that MAL made s.t. ''.isdigit() returns 0, unless others have any opposition. Trent -- Trent Mick trentm@activestate.com From fdrake@beopen.com Thu Jun 15 19:34:02 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 15 Jun 2000 14:34:02 -0400 (EDT) Subject: [Python-Dev] Re: stringobject question In-Reply-To: <20000615112857.A4508@activestate.com> References: <394701D6.37E6F560@yahoo.com> <20000613222142.A27523@activestate.com> <394745C1.7FA27DCB@lemburg.com> <20000614103632.C29778@activestate.com> <39491d4f.4591422@smtp.worldonline.dk> <20000615112857.A4508@activestate.com> Message-ID: <14665.8602.65230.481663@cj42289-a.reston1.va.home.com> Trent Mick writes: > Okeedoke, so go with the changes that MAL made s.t. ''.isdigit() returns 0, > unless others have any opposition. This sounds good to me. Marc-Andre, go ahead and checkin anything that isn't already in whenever you're ready; I've not seen any hints of opposition yet, and there's been enough waiting to just check it in. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From trentm@activestate.com Thu Jun 15 19:58:27 2000 From: trentm@activestate.com (Trent Mick) Date: Thu, 15 Jun 2000 11:58:27 -0700 Subject: [Python-Dev] Re: stringobject question In-Reply-To: <14665.8602.65230.481663@cj42289-a.reston1.va.home.com> References: <394701D6.37E6F560@yahoo.com> <20000613222142.A27523@activestate.com> <394745C1.7FA27DCB@lemburg.com> <20000614103632.C29778@activestate.com> <39491d4f.4591422@smtp.worldonline.dk> <20000615112857.A4508@activestate.com> <14665.8602.65230.481663@cj42289-a.reston1.va.home.com> Message-ID: <20000615115827.A4657@activestate.com> On Thu, Jun 15, 2000 at 02:34:02PM -0400, Fred L. Drake, Jr. wrote: > > Trent Mick writes: > > Okeedoke, so go with the changes that MAL made s.t. ''.isdigit() returns 0, > > unless others have any opposition. > > This sounds good to me. > Marc-Andre, go ahead and checkin anything that isn't already in > whenever you're ready; I've not seen any hints of opposition yet, and > there's been enough waiting to just check it in. > From what I have seen it is already in. Trent -- Trent Mick trentm@activestate.com From mal@lemburg.com Thu Jun 15 20:10:43 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 15 Jun 2000 21:10:43 +0200 Subject: [Python-Dev] Re: stringobject question References: <394701D6.37E6F560@yahoo.com> <20000613222142.A27523@activestate.com> <394745C1.7FA27DCB@lemburg.com> <20000614103632.C29778@activestate.com> <39491d4f.4591422@smtp.worldonline.dk> <20000615112857.A4508@activestate.com> <14665.8602.65230.481663@cj42289-a.reston1.va.home.com> <20000615115827.A4657@activestate.com> Message-ID: <39492A33.75440AA4@lemburg.com> Trent Mick wrote: > > On Thu, Jun 15, 2000 at 02:34:02PM -0400, Fred L. Drake, Jr. wrote: > > > > Trent Mick writes: > > > Okeedoke, so go with the changes that MAL made s.t. ''.isdigit() returns 0, > > > unless others have any opposition. > > > > This sounds good to me. > > Marc-Andre, go ahead and checkin anything that isn't already in > > whenever you're ready; I've not seen any hints of opposition yet, and > > there's been enough waiting to just check it in. > > > > >From what I have seen it is already in. Right ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fdrake@beopen.com Thu Jun 15 20:21:40 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 15 Jun 2000 15:21:40 -0400 (EDT) Subject: [Python-Dev] Re: stringobject question In-Reply-To: <39492A33.75440AA4@lemburg.com> References: <394701D6.37E6F560@yahoo.com> <20000613222142.A27523@activestate.com> <394745C1.7FA27DCB@lemburg.com> <20000614103632.C29778@activestate.com> <39491d4f.4591422@smtp.worldonline.dk> <20000615112857.A4508@activestate.com> <14665.8602.65230.481663@cj42289-a.reston1.va.home.com> <20000615115827.A4657@activestate.com> <39492A33.75440AA4@lemburg.com> Message-ID: <14665.11460.597390.222317@cj42289-a.reston1.va.home.com> M.-A. Lemburg writes: > Trent Mick wrote: > > >From what I have seen it is already in. > > Right ;-) I may have mentioned that I've been losing track of all the patches. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From thomas@xs4all.net Thu Jun 15 22:41:53 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Thu, 15 Jun 2000 23:41:53 +0200 Subject: [Python-Dev] Augmented assignment In-Reply-To: <39491CA2.2BDC0DDC@lemburg.com>; from mal@lemburg.com on Thu, Jun 15, 2000 at 08:12:50PM +0200 References: <20000615195327.R8000@xs4all.nl> <39491CA2.2BDC0DDC@lemburg.com> Message-ID: <20000615234153.S8000@xs4all.nl> On Thu, Jun 15, 2000 at 08:12:50PM +0200, M.-A. Lemburg wrote: > > I'd like some (minor) feedback on the augmented assignment thing I'm working > > on. I understand Guido is the only one who accepts patches like this, and > > appreciate that, but I'm hoping someone can at least tell me what I'm doing > > wrong so I can fix it before Guido sees it ;-) But if I'm being an impatient > > flap, just tell me so and I'll calm down. > I'd make this a 1.7 issue. 1.6 should go into the stabilization > phase and big complicated patches like yours should receive some > more design and concept discussion before getting checked in. That's more or less what I figured, though I wasn't aware of the revised schedule on 1.6 ;) > BTW, with "augmented assign" I suppose you mean things like > a += 1 and b *= 2, right ? Yes; All binary operands, to be exact: '+=' | '-=' | '*=' | '/=' | '%=' | '&=' | '|=' | '^=' | '<<=' | '>>=' | '**=' > Any reason you can't do this with the existing op codes ? > > E.g. a += b > > 1. load a > 2. load b > 3. add > 4. store a Yes: It wouldn't be thread-safe, and it would be impossible (or at least very hard and complicated) to see the difference between 'a += b' and 'a = a + b', which would make it very hard to make them functionally different. The patch not only adds the syntax (Michael Hudsons' patch did that, roughly how you describe it) but also adds generic semantics for in-place operations on builtin types, extension types and classes. > > * The patch also needs to add 11 new __hooks__, 11 new API calls, 11 new entries > > in the PyNumberMethods struct and 2 new entries in the PySequenceMethods > > struct. Would that conceivably be a problem ? I've heard people on the > > python-list complain about this ;-P > More generic solutions are usually more accepted. I thought so, but I didn't see a good, simple addition to the API that wasn't too complicated. What it adds now is 'PyNumber_InPlaceAdd()', which is functionally the same as 'PyNumber_Add()', except that the left-hand-side object is given the chance to define the operation in-place. That's also where the new PyNumberMethods/PySequenceMethods members come in. > BTW, before hacking too much into this, you ought to consider > that we are planning for rich comparisons and decentralized > coercion in 1.7 (this was planned for 1.6, but David and I > got carried away with other things). Too late. Most, if not all, of the patch is already written. Not that that's a reason to accept it, not at all ;) > I wouldn't want to have to hack 11 new slots to get this right... I'm not sure if that's necessary, but I'll have to look into your comparison/coercion work before I can say that for sure. In any case, I'd be perfectly happy with adjusting the augmented-assignment patch to the comparison/coercion change, instead of the other way 'round ;) > > * Should I start sending the patch, in pieces, to the patches-list, or is > > it a wasted effort because noone will touch it until Guido is back ? If I > > should send it, should I send it in one large patch (minus autogenerated > > files) or in nice functionality-sized pieces ? > Better put it on a web page and inform python-dev of new features, > enhancements, etc. The webpage is already there, with the version I sent to python-list last Friday. That patch is missing quite a few things, but it serves as an example of what it should do: http://www.xs4all.nl/~thomas/python/ I hope to upload an almost-finished version tomorrow morning (Amsterdam time) - if work doesn't intervene again. > > * How 'cool' does Guido actually think this syntax is ? Apparently the > > subject has come up a few times ;) and I got positive signals from both Tim > > and Guido, but if the patch won't go in as a patch, and won't actually be > > used other than some inspiration for a future rewrite of the CPython core, > > I'm not going to worry too much about the patch ;) > Having a patch is good for discussion, whether it gets incorporated > is a different issue ;-) Of course :) The thing is, the patch is actually quite done. What I'm doing now is more or less auditing and optimizing it, and that is probably a waste of time if the patch is going to need a complete rewrite anyway. On the other hand, I'm getting a couple of ideas for optimization of the 'normal' operations too, so it's not like it's wasted time. I guess I'll start a new thread on that issue if/when I reach it ;) Thanx for the feedback! -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From pf@artcom-gmbh.de Thu Jun 15 22:30:45 2000 From: pf@artcom-gmbh.de (Peter Funk) Date: Thu, 15 Jun 2000 23:30:45 +0200 (MEST) Subject: [Python-Dev] Augmented assignment In-Reply-To: <20000615195327.R8000@xs4all.nl> from Thomas Wouters at "Jun 15, 2000 7:53:27 pm" Message-ID: Hi! Thomas Wouters: > I'd like some (minor) feedback on the augmented assignment thing I'm working > on. I understand Guido is the only one who accepts patches like this, and > appreciate that, but I'm hoping someone can at least tell me what I'm doing > wrong so I can fix it before Guido sees it ;-) But if I'm being an impatient > flap, just tell me so and I'll calm down. Disclaimer: The following is only *my* personal opinion. But since you have asked for it. ;-) I don't like this augmented assignment syntax at all! (independent from your particular implementation, which I didn't had a look at). Augmented assignments are unPythonic because they don't add any new functionality to the language. From what I've seen, all people, who ever missed it, were experienced C-programmers. And C shows its inheritance from various assembler languages in its augmented assignment and its ++pre and post increment++ and decrement-- operators. Many of these features were born in the 70s of the last century: At that time optimizing was very important and compilers were relatively dumb. This applies in no way to the situation we have today with Python. What remains is, that augmented assignments are only a short cut notation, which introduces more variability to express the same algorithms and so they hurt readability. This feature must be learned additionally, where normal assignment are easiely understood from school mathematics. It also introduces many more possibilities to make subtle mistakes, since it is not obvious (at least to No-C-programmers) when and how often the index expression will be valuated. Look at the following example: class Bar: def __init__(self): self.val = 0 def __call__(self): self.val = self.val + 1 return self.val bar = Bar() foo = range(4) and than foo[bar()] = foo[bar()] + bar() print foo versus foo[bar()] += bar() print foo Todays Python forces the programmer to explicitly say, what should happen. So I think these +=,-=,*= features are evil. In the same sense as macro preprocessors are evil in 'C' and 'from module import *' is already evil in Python. Add more and more of this stuff and you end up on the dark side of programming. If augmented assignments will ever become part of Python, I would at least like to see a strong recommendation added to the styleguide not to use this feature. Enough with this rant. Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen) From nascheme@enme.ucalgary.ca Thu Jun 15 23:26:35 2000 From: nascheme@enme.ucalgary.ca (Neil Schemenauer) Date: Thu, 15 Jun 2000 16:26:35 -0600 Subject: [Python-Dev] Augmented assignment In-Reply-To: ; from pf@artcom-gmbh.de on Thu, Jun 15, 2000 at 11:30:45PM +0200 References: <20000615195327.R8000@xs4all.nl> Message-ID: <20000615162635.B11507@acs.ucalgary.ca> On Thu, Jun 15, 2000 at 11:30:45PM +0200, Peter Funk wrote: > Augmented assignments are unPythonic because they don't add any new > functionality to the language. [...] > foo[bar()] = foo[bar()] + bar() > versus > foo[bar()] += bar() Not quite. I think with the proposed implementation += could modify the LHS object in place. This could be a big performance win for things like NumPy objects. OTOH, the same effect can be achieved with a method call: foo[bar()].add(bar()) Neil From thomas@xs4all.net Thu Jun 15 23:25:23 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Fri, 16 Jun 2000 00:25:23 +0200 Subject: [Python-Dev] Augmented assignment In-Reply-To: ; from pf@artcom-gmbh.de on Thu, Jun 15, 2000 at 11:30:45PM +0200 References: <20000615195327.R8000@xs4all.nl> Message-ID: <20000616002523.T8000@xs4all.nl> On Thu, Jun 15, 2000 at 11:30:45PM +0200, Peter Funk wrote: > Thomas Wouters: > > I'd like some (minor) feedback on the augmented assignment thing I'm working > > on. I understand Guido is the only one who accepts patches like this, and > > appreciate that, but I'm hoping someone can at least tell me what I'm doing > > wrong so I can fix it before Guido sees it ;-) But if I'm being an impatient > > flap, just tell me so and I'll calm down. > I don't like this augmented assignment syntax at all! (independent > from your particular implementation, which I didn't had a look at). > Augmented assignments are unPythonic because they don't add any new > functionality to the language. [ snip quite good summary of the problems with augmented assignment ] I agree with almost all of the above, except the statement that they do not add anything. If augmented assignment was only syntactic sugar I would not have taken Michael's patch and rewritten it; I do not propose auto-increment operators, and would have a hard time accepting them. However, augmented assignment *does* add new functionality, because it is a way to inform the object that is being operated on, that it can do the operation in-place if it so wants. Instead of having to create a new object, which might be costly in cpu and/or memory, and doing the operation on that, the object can choose to do the operation on itself, and return 'self'. If the object doesn't want to do that, it doesn't have to be any different from 'x = x + 1'. (In fact, augmented assignment should, and does, fall back to that.) > > > [ snip good example of indexes-with-sideffect ] > > This actually proves the point of augmented assignment. With the syntax foo[bar()] += 1 You can see that bar() is only called once, so you *know* what index is being retrieved, and that the new value is stored in the same place. Using foo[bar()] = foo[bar()] + 1 you can't see by the expression which value is being retrieved and where the result is stored. You have to remember the rules about operand evaluation to see that. Yes, foo[bar()] += bar() is indeed more complicated than the above example, but absolutely not more complicated than the normal-add version that calls bar() three times. The augmented assignment syntax is actually clearer and more easy to explain, in my opinion. You can only (accurately) explain a = a + 1 as 'add a and 1, and store the result in a'. However, a += 1 is simply 'add 1 to a'. > So I think these +=,-=,*= features are evil. In the same sense as macro > preprocessors are evil in 'C' and 'from module import *' is already evil > in Python. Add more and more of this stuff and you end up on the dark > side of programming. Well, I like the odd Star Wars film, but I do not believe that the Dark Side lies opposite the Right Way. The Right Way can't help but be very close to the Dark Side. You may dislike macro preprocessors in C, but CPython (and almost all other C code) do use them alot, for functionality which would otherwise be very hard (or complicated and unreadable) to achieve. The same goes for 'from module import *' in Python. The funny thing is that augmented assignment operators and auto in/decrement operators might be added to C because they were easier to optimize (I dont think that was the main reason, but I wasn't there ;) but any halfway decent C compiler doesn't need that explicitness, and can optimize the 'x = x + 1' expression directly. Python, however, can (currently) not do that, and *does* need the added syntax to be able to do optimization, even if only to let the object know it's safe to operate on itself. Of course, once there are semantics for inplace-operations, it _might_ be possible to optimize 'x = x + 1' into 'x += 1' ;) > If augmented assignments will ever become part of Python, I would at least > like to see a strong recommendation added to the styleguide not to use > this feature. If such a recommendation was added, the change would be useless. Better get Guido to not add this feature instead, or Python will end up like Perl ;) I honestly do not care much wether it gets added or not. If Guido decides not to add it, I'm certain he has very valid rasons for it, and I dont assume to know as much about Python, the applicability of Python, the average usage of Python or the Future of Python as he sees it, as him ;) I-don't-know-any-of-that-in-fact-ly y'rs ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From gmcm@hypernet.com Fri Jun 16 01:44:38 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Thu, 15 Jun 2000 20:44:38 -0400 Subject: [Python-Dev] Augmented assignment In-Reply-To: References: <20000615195327.R8000@xs4all.nl> from Thomas Wouters at "Jun 15, 2000 7:53:27 pm" Message-ID: <1251006162-53585376@hypernet.com> Peter Funk wrote: > Augmented assignments are unPythonic because they don't add any > new functionality to the language. Most changes to Python are nothing but syntactic sugar. In concept, I'm +0.9 on simple "name += val". I'm -0.9 on "expr += val" if the behavior requires an understanding of Python internals, and +0 otherwise (since I avoid "expr = expr + val" if possible). Thomas's statement that the complexity is largely due to problems of thread safety is eminently believable, and I doubt that the syntactic sugar (which is at least somewhat desirable) is worth the price. > .... Many of these features were born in the > 70s of the last century: At that time optimizing was very > important and compilers were relatively dumb. This applies in no > way to the situation we have today with Python. Actually, Python's compiler is very dumb, and optimization is still important. So where I would use "expr" 3 times in 3 lines in C / C++ and *expect* the compiler to optimize it into one evaluation, I have to remind myself to use an extra line and compute it once in Python myself. One might argue that that's unPythonic, because it inhibits the direct expression of the idea. One might, but I won't. > What remains is, that augmented assignments are only a short cut > notation, which introduces more variability to express the same > algorithms and so they hurt readability. It definitely *improves* the readability of incrementing very-long- expression. Just not to the point of readability ;-). > ... It also introduces many more > possibilities to make subtle mistakes, and eliminates othes, such as typos... > since it is not obvious > (at least to No-C-programmers) when and how often the index > expression will be valuated. Look at the following example: > > class Bar: > def __init__(self): > self.val = 0 > def __call__(self): > self.val = self.val + 1 > return self.val > bar = Bar() > foo = range(4) > and than > foo[bar()] = foo[bar()] + bar() > print foo > versus > foo[bar()] += bar() > print foo To understand the first requires a sufficiently deep understanding of how Python works that I doubt the 2nd is really much worse. They're both the other side of horrid. I don't care very much myself, but none of these arguments are without strong counters (which we've all read many times on c.l.py). The only real basis, I think, is whether the changes complexify things too much. - Gordon From pf@artcom-gmbh.de Fri Jun 16 08:11:57 2000 From: pf@artcom-gmbh.de (Peter Funk) Date: Fri, 16 Jun 2000 09:11:57 +0200 (MEST) Subject: [Python-Dev] Augmented assignment In-Reply-To: <1251006162-53585376@hypernet.com> from Gordon McMillan at "Jun 15, 2000 8:44:38 pm" Message-ID: Hi, [...] [me]: > > What remains is, that augmented assignments are only a short cut > > notation, which introduces more variability to express the same > > algorithms and so they hurt readability. [Gordon McMillan]: > It definitely *improves* the readability of incrementing very-long- > expression. Just not to the point of readability ;-). I agree, that very complicated multidimensional expressions, (possible mixing tuples, lists, dicts and computations) are even more errorprone , if you have to repeat them twice just to increment an element. But than you would use an helper variable to hold the index expression anyway. example: foo = range(3); bar = range(3); cols = ('red', 'green', 'blue') chans = {'red':2, 'green':1, 'blue':0} foo[chans[cols[2-bar[0]]]] = foo[chans[cols[2-bar[0]]]] + 1 is indeed ugly. But i = chans[cols[2-bar[0]]]; foo[i] = foo[i] + 1 is at least just as (un)readable as foo[chans[cols[bar[0]]]] += 1 with the exception, that even newbies get a chance to figure out, what the former line is supposed to do without having to read a language reference manual telling them something about augmented assignments. But you are right: This has been discussed often enough on c.l.p. Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen) From Fredrik Lundh" (the eff-bot is back!) is there any special reason for this restriction: Python 1.6a2 (#0, Jun 14 2000, 23:07:49) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> a =3D [1, 2, 3] >>> a.extend((4, 5, 6)) Traceback (most recent call last): File "", line 1, in ? TypeError: list.extend() argument must be a list from the look of it, it should be trivial to change list.extend to use the abstract sequence API instead of the list API. has anyone benchmarked the abstract sequence API? how much slower is it? would it be a good idea to treat lists as a special case, to avoid slowing down existing code? other comments? if I don't hear anything, I'll post patches later this weekend. From Fredrik Lundh" the _flatten method in Tkinter is one of the major performance bottlenecks for Python/Tk programmers. the method "flattens" a nested sequence, by repeatedly adding tuples to each other. obviously, this isn't very efficient if the sequences are longer than, say, five to ten items... and has of course led to claims like "wxPython is a thousand times faster than Tkinter". anyway, taking recent changes to Python into account, it should be possible to speed this up quite a bit. the old code looked like this: def _flatten(tuple): res =3D () for item in tuple: if type(item) in (TupleType, ListType): res =3D res + _flatten(item) elif item is not None: res =3D res + (item,) return res after a some trials and errors, here's my proposed replacement: def _flatten1(seq): res =3D [] for item in seq: if type(item) in (TupleType, ListType): res.extend(_flatten1(item)) elif item is not None: res.append(item) return res =20 def _flatten(seq): return tuple(_flatten1(seq)) in my tests, this is slighly faster on very short sequences (two coordinate pairs, which is a common case for e.g. rectangles), and much faster on long sequences (polylines, polygons). for example, for a 5000-point line, it's about 15 times faster. on a 10,000 point line, it's over 50 times faster. etc. comments? can anyone come up with an even faster way to do this? if I don't hear anything negative, I'll post patches (etc) PS. even after this optimization, uiToolkit is still about 100 times faster than Tkinter, but that's another story ;-) From Fredrik Lundh" Python 1.6a2 (#0, Jun 14 2000, 23:07:49) [MSC 32 bit (Intel)] on win32 >>> (1, 2, 3) + [1, 2, 3] Traceback (most recent call last): File "", line 1, in ? TypeError: can only append tuple (not "list") to tuple is "append" really the right word here? sure confused the hell out of yours truly... ("there's no friggin' append call in this code") From jeremy@beopen.com Fri Jun 16 17:45:07 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Fri, 16 Jun 2000 12:45:07 -0400 (EDT) Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface? In-Reply-To: <000a01bfd7af$582a9ea0$f2a6b5d4@hagrid> References: <000a01bfd7af$582a9ea0$f2a6b5d4@hagrid> Message-ID: <14666.22931.521438.936776@localhost.localdomain> >>>>> "FL" == Fredrik Lundh writes: FL> has anyone benchmarked the abstract sequence API? how much FL> slower is it? would it be a good idea to treat lists as a FL> special case, to avoid slowing down existing code? The abstract interface is fairly expensive. The current code uses PyList_GET_ITEM to access the elements of the list. The abstract interface adds two function calls (PySequence_GetItem, PyList_GetItem). The first function just does a couple of sanity checks (verify arg is sequence & that it has get_item). The second function verifies that the arg is a list, then does a bounds check. None of the work that either of these functions does is necessary for the list case! In the extended call syntax implementation, I used PySequence_Tuple to handle non-standard sequences. Once converted to a tuple, they can be processed using the macros. If you support user-defined sequences, the sanity checking can get pretty hairy if you don't coerce to a tuple; e.g. the PySequence_Length method can lie! I don't remember considering the cost of allocating the new tuple, which is only used internally. Jeremy From thomas@xs4all.net Fri Jun 16 17:45:14 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Fri, 16 Jun 2000 18:45:14 +0200 Subject: [Python-Dev] Augmented assignment, update Message-ID: <20000616184514.Q26436@xs4all.nl> I've more or less finished the augmented-assignment patch I posted last week. It can be found, including a longish explanation, here: http://www.xs4all.nl/~thomas/python/ (For those who missed it, the previous posting is here: http://www.python.org/pipermail/python-list/2000-June/060680.html The link in the posting, however, points to the new patch.) I do not know if augmented assignment will every be incorporated into Python (this patch or something entirely different) but at least noone can claim the groundwork is missing :-) Feel free to send questions, comments and verbal abuse my way ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mwh21@cam.ac.uk Fri Jun 16 17:53:42 2000 From: mwh21@cam.ac.uk (Michael Hudson) Date: 16 Jun 2000 17:53:42 +0100 Subject: [Python-Dev] Q: is concatenation and append really the same thing? In-Reply-To: "Fredrik Lundh"'s message of "Fri, 16 Jun 2000 18:47:01 +0200" References: <001e01bfd7b2$7fc91ba0$f2a6b5d4@hagrid> Message-ID: "Fredrik Lundh" writes: > Python 1.6a2 (#0, Jun 14 2000, 23:07:49) [MSC 32 bit (Intel)] on win32 > >>> (1, 2, 3) + [1, 2, 3] > Traceback (most recent call last): > File "", line 1, in ? > TypeError: can only append tuple (not "list") to tuple > > is "append" really the right word here? My fault. I have sent at least one patch to patches@python.org to change it to can only concatenate tuple (not "list") to tuple to bring it into line with listobject.c; here it is again: Index: Objects/tupleobject.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Objects/tupleobject.c,v retrieving revision 2.34 diff -u -r2.34 tupleobject.c --- Objects/tupleobject.c 2000/06/01 03:12:13 2.34 +++ Objects/tupleobject.c 2000/06/06 16:30:39 @@ -362,7 +362,7 @@ PyTupleObject *np; if (!PyTuple_Check(bb)) { PyErr_Format(PyExc_TypeError, - "can only append tuple (not \"%.200s\") to tuple", + "can only concatenate tuple (not \"%.200s\") to tuple", bb->ob_type->tp_name); return NULL; } HTH, HAND, Michael From mal@lemburg.com Fri Jun 16 17:53:59 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 16 Jun 2000 18:53:59 +0200 Subject: [Python-Dev] possible Tkinter speedup References: <001401bfd7b1$bdf9a120$f2a6b5d4@hagrid> Message-ID: <394A5BA7.F001E220@lemburg.com> Fredrik Lundh wrote: > > the _flatten method in Tkinter is one of the major performance > bottlenecks for Python/Tk programmers. the method "flattens" > a nested sequence, by repeatedly adding tuples to each other. > > obviously, this isn't very efficient if the sequences are longer > than, say, five to ten items... and has of course led to claims > like "wxPython is a thousand times faster than Tkinter". > > anyway, taking recent changes to Python into account, it should > be possible to speed this up quite a bit. > > the old code looked like this: > > def _flatten(tuple): > res = () > for item in tuple: > if type(item) in (TupleType, ListType): > res = res + _flatten(item) > elif item is not None: > res = res + (item,) > return res > > after a some trials and errors, here's my proposed replacement: > > def _flatten1(seq): > res = [] > for item in seq: > if type(item) in (TupleType, ListType): > res.extend(_flatten1(item)) > elif item is not None: > res.append(item) > return res > > def _flatten(seq): > return tuple(_flatten1(seq)) > > in my tests, this is slighly faster on very short sequences (two > coordinate pairs, which is a common case for e.g. rectangles), > and much faster on long sequences (polylines, polygons). > > for example, for a 5000-point line, it's about 15 times faster. > on a 10,000 point line, it's over 50 times faster. etc. > > comments? Why not implement this in C and add it to _tkinter.c ? It might even make a nice standard builtin... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fdrake@beopen.com Fri Jun 16 18:02:22 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Fri, 16 Jun 2000 13:02:22 -0400 (EDT) Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface? In-Reply-To: <000a01bfd7af$582a9ea0$f2a6b5d4@hagrid> References: <000a01bfd7af$582a9ea0$f2a6b5d4@hagrid> Message-ID: <14666.23966.437909.949260@cj42289-a.reston1.va.home.com> Fredrik Lundh writes: > if I don't hear anything, I'll post patches later this weekend. Sounds good to me! If lists and tuples are special cased, it shouldn't even matter if the sequence API is too slow -- that's new functionality for [].extend(), and can be optimized later if it needs to be. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From mal@lemburg.com Fri Jun 16 18:07:40 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 16 Jun 2000 19:07:40 +0200 Subject: [Python-Dev] Q: is concatenation and append really the same thing? References: <001e01bfd7b2$7fc91ba0$f2a6b5d4@hagrid> Message-ID: <394A5EDC.7431C900@lemburg.com> Michael Hudson wrote: > > "Fredrik Lundh" writes: > > > Python 1.6a2 (#0, Jun 14 2000, 23:07:49) [MSC 32 bit (Intel)] on win32 > > >>> (1, 2, 3) + [1, 2, 3] > > Traceback (most recent call last): > > File "", line 1, in ? > > TypeError: can only append tuple (not "list") to tuple > > > > is "append" really the right word here? > > My fault. I have sent at least one patch to patches@python.org to > change it to > > can only concatenate tuple (not "list") to tuple > > to bring it into line with listobject.c; here it is again: > > Index: Objects/tupleobject.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Objects/tupleobject.c,v > retrieving revision 2.34 > diff -u -r2.34 tupleobject.c > --- Objects/tupleobject.c 2000/06/01 03:12:13 2.34 > +++ Objects/tupleobject.c 2000/06/06 16:30:39 > @@ -362,7 +362,7 @@ > PyTupleObject *np; > if (!PyTuple_Check(bb)) { > PyErr_Format(PyExc_TypeError, > - "can only append tuple (not \"%.200s\") to tuple", > + "can only concatenate tuple (not \"%.200s\") to tuple", > bb->ob_type->tp_name); > return NULL; > } > Should be in CVS by now... Thanks, -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fdrake@beopen.com Fri Jun 16 18:13:55 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Fri, 16 Jun 2000 13:13:55 -0400 (EDT) Subject: [Python-Dev] mailbox formats Message-ID: <14666.24659.9174.717901@cj42289-a.reston1.va.home.com> I've been playing with a function to open a mailbox and return the appropriate type of mailbox object from the mailbox module, but I don't have examples of anything but mbox style mailboxes to test with. Could anyone send real examples of MMDF, MH, maildir, and Babyl mailboxes? The mail can be junk; don't send anything I shouldn't see! Essentially, I'd like to see two new functions added to the mailbox module: open('name'), which returns a mailbox object opened for reading, and which('name'), which returns the name of the mailbox constructor, and possibly a flag indicating whether a __builtin__.open() is needed. Thanks! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From mal@lemburg.com Fri Jun 16 19:59:39 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 16 Jun 2000 20:59:39 +0200 Subject: [Python-Dev] Announcment list Message-ID: <394A791B.17F5AEFF@lemburg.com> Does anybody know about the state of the python-announce mailing list ? I've sent an announcement there (about mxCGIPython), but have only received an error message and got no posting back from the list. I posted a note to the postmaster@beopen.com, but have heard nothing from there yet. Can somebody please look into this ?! BTW, what about the announcement list -> c.l.p.a gateway ? Will that happen anytime soon (or do I have to hack the headers to post there ? ;-) Here's the error message: """ Subject: failure notice Date: 13 Jun 2000 11:34:39 -0000 From: MAILER-DAEMON@starship.beopen.com To: mal@lemburg.com Hi. This is the qmail-send program at starship.beopen.com. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. : Sorry, no mailbox here by that name. (#5.1.1) --- Below this line is a copy of the message. Return-Path: Received: (qmail 31495 invoked from network); 13 Jun 2000 11:34:38 -0000 Received: from dinsdale.cnri.reston.va.us (HELO dinsdale.python.org) (132.151.1.21) by starship.beopen.com with SMTP; 13 Jun 2000 11:34:38 -0000 Received: by dinsdale.python.org (Postfix) id AD6DD1CDE3; Tue, 13 Jun 2000 07:29:56 -0400 (EDT) Delivered-To: python-announce-people@python.org ... """ -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From bwarsaw@python.org Fri Jun 16 20:24:21 2000 From: bwarsaw@python.org (Barry A. Warsaw) Date: Fri, 16 Jun 2000 15:24:21 -0400 (EDT) Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface? References: <000a01bfd7af$582a9ea0$f2a6b5d4@hagrid> <14666.23966.437909.949260@cj42289-a.reston1.va.home.com> Message-ID: <14666.32485.172984.122789@anthem.concentric.net> >>>>> "Fred" == Fred L Drake, Jr writes: Fred> Sounds good to me! If lists and tuples are special cased, Fred> it shouldn't even matter if the sequence API is too slow -- Fred> that's new functionality for [].extend(), and can be Fred> optimized later if it needs to be. This has been a typical implementation strategy for a long while now, and I think successfully so. When I removed the distinction between list and tuple unpacking to allow any sequence unpacking (and incidently w/o special syntax), I did exactly this. Special case for tuples and lists, and if it was neither then use the sequence API. Jeremy's right that this can get hairy if your as anal as I am about error checking and refcounting. In addition to PySequence_Length() ability to lie, there are all sorts of errors that can happen, which should abort the whole process and clean up any temporary objects. Plus you've now got three very similar branches in the code, which adds its own overhead. So you should decide whether this situation will be used widely enough to warrant the extra coding complexity for the performance win. list.extend() is probably not used too often these days, but it should be 'cause it's cool. So maybe it's worth it in this case. On the other hand, this is a situation that comes up often, and if we were to really audit the APIs, we'd probably find even more cases where restrictions to concrete lists or tuples should be relaxed to accept any sequence. Maybe there's a way we can factor this out in a single function which handles this once and for all? -Barry From paul@prescod.net Fri Jun 16 20:22:08 2000 From: paul@prescod.net (Paul Prescod) Date: Fri, 16 Jun 2000 21:22:08 +0200 Subject: [Python-Dev] Augmented assignment References: Message-ID: <394A7E60.6F715424@prescod.net> Many people have given examples where the augmented assignment version is substantially more readable. Others have argued that it is more explicit in that it says *exactly what you mean* rather than using a more general operator in a specific (common) situation. Another important argument is that augmented assignment allows *in place* assignment for some types. That's really important for matrix math etc. All of these arguments convince me that this is not a simple matter of "another notation for what we already do." > Augmented assignments are unPythonic because they don't add any new > functionality to the language. From what I've seen, all people, > who ever missed it, were experienced C-programmers. That's true, but we should not be ashamed to steal good ideas from other languages. Probably the only people who would miss __getattr__ would be SmallTalk programmers and the original proponents of the various operator overloading features may well have come from C++. > ... > This feature must be learned > additionally, where normal assignment are easiely understood from > school mathematics. Not really! a=a+1 is totally illegal in basic arithmetic. > It also introduces many more possibilities to make > subtle mistakes, since it is not obvious (at least to No-C-programmers) > when and how often the index expression will be valuated. As I understand the proposal, the function will be called exactly as many times as it is printed in the source code: > versus > foo[bar()] += bar() > print foo Presumably bar() gets called twice. The only argument against this that is persusaive to me is that it makes the core Python language larger and thus a (little) harder to learn. My impression is that the design of the feature has been well done. My personal opinion is that the cost in education probably outweighs the benefits in clarity but others who work a lot with matrices etc. would probably have a different view. -- Paul Prescod - ISOGEN Consulting Engineer speaking for himself "Music is the stuff between the notes." - Claude Debussy From petrilli@amber.org Fri Jun 16 20:42:46 2000 From: petrilli@amber.org (Christopher Petrilli) Date: Fri, 16 Jun 2000 15:42:46 -0400 Subject: [Python-Dev] Augmented assignment In-Reply-To: <394A7E60.6F715424@prescod.net>; from paul@prescod.net on Fri, Jun 16, 2000 at 09:22:08PM +0200 References: <394A7E60.6F715424@prescod.net> Message-ID: <20000616154246.A5513@trump.amber.org> Paul Prescod [paul@prescod.net] wrote: > That's true, but we should not be ashamed to steal good ideas from other > languages. Probably the only people who would miss __getattr__ would be > SmallTalk programmers and the original proponents of the various > operator overloading features may well have come from C++. Actually as a good Talker, I write methods for everything, so I almost nver use __getattr__ except as a way to force people to use methods and not directly access attributes. Long story. Chris -- | Christopher Petrilli | petrilli@amber.org From fdrake@beopen.com Fri Jun 16 20:42:12 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Fri, 16 Jun 2000 15:42:12 -0400 (EDT) Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface? In-Reply-To: <14666.32485.172984.122789@anthem.concentric.net> References: <000a01bfd7af$582a9ea0$f2a6b5d4@hagrid> <14666.23966.437909.949260@cj42289-a.reston1.va.home.com> <14666.32485.172984.122789@anthem.concentric.net> Message-ID: <14666.33556.123258.252030@cj42289-a.reston1.va.home.com> Barry A. Warsaw writes: > Jeremy's right that this can get hairy if your as anal as I am about > error checking and refcounting. In addition to PySequence_Length() > ability to lie, there are all sorts of errors that can happen, which > should abort the whole process and clean up any temporary objects. > Plus you've now got three very similar branches in the code, which > adds its own overhead. > > So you should decide whether this situation will be used widely enough > to warrant the extra coding complexity for the performance win. > list.extend() is probably not used too often these days, but it should > be 'cause it's cool. So maybe it's worth it in this case. > > On the other hand, this is a situation that comes up often, and if we > were to really audit the APIs, we'd probably find even more cases > where restrictions to concrete lists or tuples should be relaxed to > accept any sequence. Maybe there's a way we can factor this out in a > single function which handles this once and for all? How about this: special case the list & tuple flavors (since that'll be roughly what's in there now), and for other sequences, convert to either a tuple or a list and let it pass through that special case, keeping a flag to discard the temporary list when done? There are two APIs, PySequence_List() and PySequence_Tuple(), which can take care of a lot of the machinery in dealing with sequences that lie about their length or otherwise break (during __getitem__() calls or whatever), that a large part of the work is done. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From mal@lemburg.com Fri Jun 16 20:45:16 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 16 Jun 2000 21:45:16 +0200 Subject: [Python-Dev] Augmented assignment References: <394A7E60.6F715424@prescod.net> Message-ID: <394A83CC.98F177DC@lemburg.com> Paul Prescod wrote: > > Augmented assignments are unPythonic because they don't add any new > > functionality to the language. From what I've seen, all people, > > who ever missed it, were experienced C-programmers. > > That's true, but we should not be ashamed to steal good ideas from other > languages. Probably the only people who would miss __getattr__ would be > SmallTalk programmers and the original proponents of the various > operator overloading features may well have come from C++. Don't forget the crowd of people doing environmental acquisition (you know who they are ;-). Honestly, I think that __getattr__ is one of the most useful hooks available on Python objects. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From jeremy@beopen.com Fri Jun 16 21:01:18 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Fri, 16 Jun 2000 16:01:18 -0400 (EDT) Subject: [Python-Dev] Augmented assignment In-Reply-To: <394A83CC.98F177DC@lemburg.com> References: <394A7E60.6F715424@prescod.net> <394A83CC.98F177DC@lemburg.com> Message-ID: <14666.34702.801826.453565@localhost.localdomain> I'm leery of acquisition, but we gotta have __getattr__. Jeremy >>>>> "MAL" == M -A Lemburg writes: MAL> Paul Prescod wrote: >> > Augmented assignments are unPythonic because they don't add any >> > new functionality to the language. From what I've seen, all >> > people, who ever missed it, were experienced C-programmers. >> >> That's true, but we should not be ashamed to steal good ideas >> from other languages. Probably the only people who would miss >> __getattr__ would be SmallTalk programmers and the original >> proponents of the various operator overloading features may well >> have come from C++. MAL> Don't forget the crowd of people doing environmental MAL> acquisition (you know who they are ;-). MAL> Honestly, I think that __getattr__ is one of the most useful MAL> hooks available on Python objects. From fdrake@beopen.com Fri Jun 16 22:44:05 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Fri, 16 Jun 2000 17:44:05 -0400 (EDT) Subject: [Python-Dev] possible Tkinter speedup In-Reply-To: <394A5BA7.F001E220@lemburg.com> References: <001401bfd7b1$bdf9a120$f2a6b5d4@hagrid> <394A5BA7.F001E220@lemburg.com> Message-ID: <14666.40869.331831.90682@cj42289-a.reston1.va.home.com> M.-A. Lemburg writes: > Why not implement this in C and add it to _tkinter.c ? I think this is the right approach; do you have an implementation? ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From Fredrik Lundh" <394A5BA7.F001E220@lemburg.com> Message-ID: <015e01bfd7dc$f53daca0$f2a6b5d4@hagrid> mal wrote: > > for example, for a 5000-point line, it's about 15 times faster. > > on a 10,000 point line, it's over 50 times faster. etc. > >=20 > > comments? >=20 > Why not implement this in C and add it to _tkinter.c ? > It might even make a nice standard builtin... bang for the buck? getting a working C version is a whole lot of work, and I'd rather spend that time on things that can speed things up a whole lot more [1]. but if it's still raining tomorrow... 1) http://w1.132.telia.com/~u13208596/tkinter From Fredrik Lundh" <394A5BA7.F001E220@lemburg.com> <015e01bfd7dc$f53daca0$f2a6b5d4@hagrid> Message-ID: <017101bfd7e2$f2d3a2c0$f2a6b5d4@hagrid> eff-bot wrote: > bang for the buck? >=20 > getting a working C version is a whole lot of work okay, I just proved that I don't know what I'm talking about. it wasn't that hard, and the performance boost is rather interesting... for 5000 vertices: Tkinter 1.6: 10.44 seconds Tkinter 1.6 with new flatten: 0.27 seconds Tkinter 1.6 with C version of flatten: 2.57 milliseconds patch follows. From Fredrik Lundh" <14666.22931.521438.936776@localhost.localdomain> Message-ID: <003501bfd831$8bb11a60$f2a6b5d4@hagrid> jeremy wrote: > FL> has anyone benchmarked the abstract sequence API? how much > FL> slower is it? would it be a good idea to treat lists as a > FL> special case, to avoid slowing down existing code? >=20 > The abstract interface is fairly expensive. The current code uses > PyList_GET_ITEM to access the elements of the list. The abstract > interface adds two function calls (PySequence_GetItem, > PyList_GetItem). The first function just does a couple of sanity > checks (verify arg is sequence & that it has get_item). The second > function verifies that the arg is a list, then does a bounds check. > None of the work that either of these functions does is necessary for > the list case! just for the record, I just changed some generic sequence code to something like: if (PyList_Check(seq) || PyTuple_Check(seq)) Py_INCREF(seq); else if (PySequence_Check(seq)) { seq =3D PySequence_Tuple(seq); if (!seq) return NULL; } else { PyErr_SetString(PyExc_TypeError, "argument must be a sequence"); return NULL; } ... allocate PyObject_Length(seq) slots ... if (PyList_Check(seq)) ... list code using PyList_GET_ITEM else ... tuple code using PyTuple_GET_ITEM Py_DECREF(seq); for the standard case (lists, in this case), this resulted in a total speedup of 4 times (this includes some other overhead). so in other words, this construct is more than 4 times faster than plain use of PySequence_GetItem. guess it's time to fix a couple of things in PIL... From mhammond@skippinet.com.au Sat Jun 17 09:16:18 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Sat, 17 Jun 2000 18:16:18 +1000 Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface? In-Reply-To: <003501bfd831$8bb11a60$f2a6b5d4@hagrid> Message-ID: /F: > just for the record, I just changed some generic sequence code > to something like: ... > so in other words, this construct is more than 4 times faster > than plain use of PySequence_GetItem. Good stuff! > guess it's time to fix a couple of things in PIL... Its a fair bit of code to duplicate everywhere you want the speed increase. How can we add a similar scheme to the core, so the changes people need to make are trivial (to the point where the change is zero!)? Mark. From Fredrik Lundh" Message-ID: <006a01bfd837$ac689840$f2a6b5d4@hagrid> mark wrote: > > so in other words, this construct is more than 4 times faster > > than plain use of PySequence_GetItem. >=20 > Good stuff! >=20 > > guess it's time to fix a couple of things in PIL... >=20 > Its a fair bit of code to duplicate everywhere you want the speed = increase. > How can we add a similar scheme to the core, so the changes people = need to > make are trivial (to the point where the change is zero!)? the first part is trivial; just add something like this to Objects/abstract.c: PyObject* PySequence_TupleOrList(PyObject* seq) { if (PyList_Check(seq) || PyTuple_Check(seq)) Py_INCREF(seq); else if (PySequence_Check(seq)) seq =3D PySequence_Tuple(seq); else { PyErr_SetString(PyExc_TypeError, "argument must be a sequence"); seq =3D NULL; } return seq; } the second parts is harder -- and that's of course where the real performance boost comes from. as far as I'm aware, very few C compilers can "specialize" loops for you... From mal@lemburg.com Sat Jun 17 09:41:25 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat, 17 Jun 2000 10:41:25 +0200 Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface? References: Message-ID: <394B39B5.B478720E@lemburg.com> Mark Hammond wrote: > > /F: > > just for the record, I just changed some generic sequence code > > to something like: > ... > > so in other words, this construct is more than 4 times faster > > than plain use of PySequence_GetItem. > > Good stuff! > > > guess it's time to fix a couple of things in PIL... > > Its a fair bit of code to duplicate everywhere you want the speed increase. > How can we add a similar scheme to the core, so the changes people need to > make are trivial (to the point where the change is zero!)? We could add special code the standard type to PySequence_GetItem() et al., but it would still cause a C function call (not much, but noticable in inner loops). How about adding some inline markers to the most often used (and small) routines in the medium level abstract interface (PySequence_*, PyMapping_*, etc.) ?! Together with the special code for the native Python types this should yield a speedup for all extensions by simple virtue of a recompile... OTOH, changes to these APIs would need a recompile of the extensions too. BTW, I've used the same approach as Fredrik in mx.Tools. It does make great a difference... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Sat Jun 17 09:53:20 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat, 17 Jun 2000 10:53:20 +0200 Subject: [Python-Dev] Re: [Python-bugs-list] PRIVATE: interned->ma_table never free'd (PR#361) References: <20000617000834.C29B41CF4A@dinsdale.python.org> Message-ID: <394B3C80.248B4CB1@lemburg.com> cfandrich@8cs.com wrote: > > Full_Name: Christopher Fandrich > Version: 1.5.2 > OS: Windows > Submission from: (NULL) (208.41.174.4) > > I'm embedding Python in an application. For now, all I'm doing is initializing > and finalizing Python. > > When I run my app I get a memory leak of 12288 bytes. The memory is malloc'ed > by dictresize() which is called by PyDict_SetItem() which is called by > PyString_InternInPlace(). > > For now, I've added > PyDict_Clear(interned); > interned = NULL; > to PyString_Fini(). So far it works fine, but I don't know if it's safe to do > in the grand scheme of things. I would suggest adding code to dealloc the interned dict iff it is empty after the sweeping action in PyString_Fini(). I have a feeling that this is not the case though, since interned strings are used quite a lot in the core interpreter (e.g. in classobject.c) and these are usually not recovered. Perhaps we ought to add some code which takes care of cleaning up all remaining garbage left over after the call to call_ll_exitfuncs() in Py_Finalize(), e.g. force free'ing of all interned strings and cached ints/floats and associated free lists or dicts. We'd need new APIs in string|float|intobject.c to implement this. Thoughts ? Patches ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Fredrik Lundh" <006a01bfd837$ac689840$f2a6b5d4@hagrid> Message-ID: <00d701bfd859$fd435300$f2a6b5d4@hagrid> the eff-bot wrote: > the first part is trivial; just add something like this to > Objects/abstract.c: >=20 > PyObject* > PySequence_TupleOrList(PyObject* seq) > ... >=20 > the second parts is harder -- and that's of course where the > real performance boost comes from. as far as I'm aware, very > few C compilers can "specialize" loops for you... in the same test setup, moving the PyList_Check inside the loop gives a 25-30% slowdown (or to look at it from the other side, 3 times instead of 4 times faster than naive code). a compromise solution could be to combine the above function with a macro: #define PySequence_TupleOrList_GET_ITEM(seq, index)\ (PyList_Check(seq) ? PyList_GET_ITEM(seq, index) :\ PyTuple_GET_ITEM(seq, index) (anyone got a better name? ;-) standard usage: seq =3D PySequence_TupleOrList(seq_in); size =3D PyObject_Length(seq); =20 for (i =3D 0; i < size; i++) { PyObject* obj =3D PySequence_TupleOrList_GET_ITEM(seq, i); ... } comments? From mal@lemburg.com Sat Jun 17 15:18:26 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat, 17 Jun 2000 16:18:26 +0200 Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface? References: <006a01bfd837$ac689840$f2a6b5d4@hagrid> <00d701bfd859$fd435300$f2a6b5d4@hagrid> Message-ID: <394B88B2.EA116971@lemburg.com> Fredrik Lundh wrote: > > the eff-bot wrote: > > > the first part is trivial; just add something like this to > > Objects/abstract.c: > > > > PyObject* > > PySequence_TupleOrList(PyObject* seq) > > ... > > > > the second parts is harder -- and that's of course where the > > real performance boost comes from. as far as I'm aware, very > > few C compilers can "specialize" loops for you... > > in the same test setup, moving the PyList_Check inside the > loop gives a 25-30% slowdown (or to look at it from the other > side, 3 times instead of 4 times faster than naive code). > > a compromise solution could be to combine the above function > with a macro: > > #define PySequence_TupleOrList_GET_ITEM(seq, index)\ > (PyList_Check(seq) ? PyList_GET_ITEM(seq, index) :\ > PyTuple_GET_ITEM(seq, index) > > (anyone got a better name? ;-) > > standard usage: > > seq = PySequence_TupleOrList(seq_in); > > size = PyObject_Length(seq); > > for (i = 0; i < size; i++) { > PyObject* obj = PySequence_TupleOrList_GET_ITEM(seq, i); > ... > } > > comments? The above looks a lot like an iterator... how about providing a standard PySequence_Iterate(obj, callback) with the callback being called for every element of the sequence ?! The iterator could then be optimized for lists and tuples. Not as fast as inlining, but a more generic solution... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Fredrik Lundh" <006a01bfd837$ac689840$f2a6b5d4@hagrid> <00d701bfd859$fd435300$f2a6b5d4@hagrid> <394B88B2.EA116971@lemburg.com> Message-ID: <010401bfd86a$5282cca0$f2a6b5d4@hagrid> mal wrote: > The above looks a lot like an iterator... how about > providing a standard PySequence_Iterate(obj, callback) > with the callback being called for every element of the > sequence ?! PySequence_Enumerate, perhaps? > The iterator could then be optimized for lists and tuples. > Not as fast as inlining, but a more generic solution... more generic than useful, imo: - it's slower. - it's awkward to use: you need to put the state in a structure, invert your program logic, etc. - it doesn't scale: what if you want to loop over two structures? what if you want to loop over two objects, using two different indices? From mal@lemburg.com Sat Jun 17 15:44:47 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat, 17 Jun 2000 16:44:47 +0200 Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface? References: <006a01bfd837$ac689840$f2a6b5d4@hagrid> <00d701bfd859$fd435300$f2a6b5d4@hagrid> <394B88B2.EA116971@lemburg.com> <010401bfd86a$5282cca0$f2a6b5d4@hagrid> Message-ID: <394B8EDF.57630FE9@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > The above looks a lot like an iterator... how about > > providing a standard PySequence_Iterate(obj, callback) > > with the callback being called for every element of the > > sequence ?! > > PySequence_Enumerate, perhaps? > > > The iterator could then be optimized for lists and tuples. > > Not as fast as inlining, but a more generic solution... > > more generic than useful, imo: > > - it's slower. > > - it's awkward to use: you need to put the state in a > structure, invert your program logic, etc. > > - it doesn't scale: what if you want to loop over two > structures? what if you want to loop over two objects, > using two different indices? Or perhaps, use a different iteration technique: the one used by PyDict_Next(). It doesn't need a callback, but instead plays with pointers you pass to it via output variables. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Fredrik Lundh" mark wrote: > Its a fair bit of code to duplicate everywhere you want the speed = increase. > How can we add a similar scheme to the core, so the changes people = need to > make are trivial (to the point where the change is zero!)? okay, here's my current proposal: PyObject* PySequence_Fast(PyObject *o)=20 Return value: New reference.=20 Returns the o as a tuple or a list on success, and NULL on failure. If o doesn't have the right type, it is converted to a tuple using PySequence_Tuple. This is equivalent to the following Python code: if type(o) in (ListType, TupleType): return o return tuple(o) This function is intended to be used together with PySequence_Fast_GET_ITEM, for functions that need to loop over a read-only sequence as fast as they possibly can, while still supporting any object that implements the sequence protocol. PyObject* PySequence_Fast_GET_ITEM(PyObject *seq, int i) Return value: Borrowed reference.=20 Returns the object at position i, from the sequence seq (which must be a list or a tuple). This is a macro, and has no error checking. If you need error checking, use PySequence_GetItem. for the rationale, see my earlier posts in the "list.extend" thread. unless somebody comes up with a more efficient solution, I'll wrap this up together with the list.extend patch (first thing tomorrow). From gstein@lyra.org Sat Jun 17 21:52:31 2000 From: gstein@lyra.org (Greg Stein) Date: Sat, 17 Jun 2000 13:52:31 -0700 Subject: [Python-Dev] proposal: core support for "fast" sequence iteration In-Reply-To: <011901bfd873$00632740$f2a6b5d4@hagrid>; from effbot@telia.com on Sat, Jun 17, 2000 at 05:44:58PM +0200 References: <011901bfd873$00632740$f2a6b5d4@hagrid> Message-ID: <20000617135231.E29590@lyra.org> +1 coolness. On Sat, Jun 17, 2000 at 05:44:58PM +0200, Fredrik Lundh wrote: > mark wrote: > > > Its a fair bit of code to duplicate everywhere you want the speed increase. > > How can we add a similar scheme to the core, so the changes people need to > > make are trivial (to the point where the change is zero!)? > > okay, here's my current proposal: > > PyObject* PySequence_Fast(PyObject *o) > > Return value: New reference. > > Returns the o as a tuple or a list on success, and > NULL on failure. If o doesn't have the right type, > it is converted to a tuple using PySequence_Tuple. > > This is equivalent to the following Python code: > > if type(o) in (ListType, TupleType): > return o > return tuple(o) > > This function is intended to be used together with > PySequence_Fast_GET_ITEM, for functions that need > to loop over a read-only sequence as fast as they > possibly can, while still supporting any object that > implements the sequence protocol. > > PyObject* PySequence_Fast_GET_ITEM(PyObject *seq, int i) > > Return value: Borrowed reference. > > Returns the object at position i, from the sequence > seq (which must be a list or a tuple). This is a > macro, and has no error checking. > > If you need error checking, use PySequence_GetItem. > > for the rationale, see my earlier posts in the "list.extend" thread. > > unless somebody comes up with a more efficient solution, I'll wrap > this up together with the list.extend patch (first thing tomorrow). > > > > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://www.python.org/mailman/listinfo/python-dev -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Sat Jun 17 23:37:26 2000 From: gstein@lyra.org (Greg Stein) Date: Sat, 17 Jun 2000 15:37:26 -0700 Subject: [Python-Dev] Re: [Python-bugs-list] PRIVATE: interned->ma_table never free'd (PR#361) In-Reply-To: <394B3C80.248B4CB1@lemburg.com>; from mal@lemburg.com on Sat, Jun 17, 2000 at 10:53:20AM +0200 References: <20000617000834.C29B41CF4A@dinsdale.python.org> <394B3C80.248B4CB1@lemburg.com> Message-ID: <20000617153726.H29590@lyra.org> On Sat, Jun 17, 2000 at 10:53:20AM +0200, M.-A. Lemburg wrote: >... > I would suggest adding code to dealloc the interned dict > iff it is empty after the sweeping action in PyString_Fini(). > I have a feeling that this is not the case though, since interned > strings are used quite a lot in the core interpreter (e.g. in > classobject.c) and these are usually not recovered. > > Perhaps we ought to add some code which takes care of cleaning > up all remaining garbage left over after the call to > call_ll_exitfuncs() in Py_Finalize(), e.g. force free'ing > of all interned strings and cached ints/floats and associated > free lists or dicts. > > We'd need new APIs in string|float|intobject.c to implement this. > > Thoughts ? Patches ? I would definitely like to see this, and suggested it to Guido about four years ago :-) During my threading work, I looked at all the globals, which includes the pools and the one-off allocations in classobject.c and friends. I figured it would be a Good Thing(tm) to write a general object pool API which could be used by tuples, floats, frames, etc. Having the single implementation of a pool would mean that we could add thread locks in a single place. Similarly, for cleanup reasons, I also suggested a general API for allocating the "constants" and torching them at shutdown. As we all know, though... suggestions don't mean crap. Code counts. :-) That said, I'll look into some of this with the free-threading work. That is all post-1.6, though. It would be great if somebody could do it before then. Cheers, -g -- Greg Stein, http://www.lyra.org/ From Vladimir.Marangozov@inrialpes.fr Sun Jun 18 00:01:30 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Sun, 18 Jun 2000 01:01:30 +0200 (CEST) Subject: [Python-Dev] Re: [Python-bugs-list] PRIVATE: interned->ma_table never free'd (PR#361) In-Reply-To: <20000617153726.H29590@lyra.org> from "Greg Stein" at Jun 17, 2000 03:37:26 PM Message-ID: <200006172301.BAA01642@python.inrialpes.fr> Greg Stein wrote: > > On Sat, Jun 17, 2000 at 10:53:20AM +0200, M.-A. Lemburg wrote: > >... > > Perhaps we ought to add some code which takes care of cleaning > > up all remaining garbage left over after the call to > > call_ll_exitfuncs() in Py_Finalize(), e.g. force free'ing > > of all interned strings and cached ints/floats and associated > > free lists or dicts. > > > > We'd need new APIs in string|float|intobject.c to implement this. > > > > Thoughts ? Patches ? > > I would definitely like to see this, and suggested it to Guido about four > years ago :-) > > During my threading work, I looked at all the globals, which includes the > pools and the one-off allocations in classobject.c and friends. I figured it > would be a Good Thing(tm) to write a general object pool API which could be > used by tuples, floats, frames, etc. Having the single implementation of a > pool would mean that we could add thread locks in a single place. > > Similarly, for cleanup reasons, I also suggested a general API for > allocating the "constants" and torching them at shutdown. > > As we all know, though... suggestions don't mean crap. Code counts. :-) pymalloc (the debugging stuff put aside) is an efficient implementation of this pool concept. The interface just needs to be exported under an appropriate PyObject_ API, not as a general malloc replacement. Maybe it needs some more work regarding finalization, but the code is there. Per pool locking is there too. Maybe it needs to be adjusted wrt the pool granularity we want. The various core object allocators would use this API with PyObject_NEW inlined. > > That said, I'll look into some of this with the free-threading work. That is > all post-1.6, though. It would be great if somebody could do it before then. Voila. -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From Vladimir.Marangozov@inrialpes.fr Sun Jun 18 01:50:51 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Sun, 18 Jun 2000 02:50:51 +0200 (CEST) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules mmapmodule.c,2.10,2.11 In-Reply-To: <200006172241.PAA02080@slayer.i.sourceforge.net> from "A.M. Kuchling" at Jun 17, 2000 03:41:24 PM Message-ID: <200006180050.CAA07547@python.inrialpes.fr> A.M. Kuchling wrote: > > Update of /cvsroot/python/python/dist/src/Modules > In directory slayer.i.sourceforge.net:/tmp/cvs-serv2060 > > Modified Files: > mmapmodule.c > Log Message: > Fix the size() method to return the size of the file on Unix, not the > size of the mapped area. This seems to be what the Windows version does. > This change requires keeping around the fd of the mapped file. On AIX, the test_mmap fails with errno=EINVAL on the m.flush() method. It works okay without the MS_INVALIDATE flag though, so I'd suggest removing it from msync in the flush and dealloc methods. Also, it would probably be a good idea to allow optional flags for flush, as it's done in new_mmap_object, the default being only MS_SYNC. Given that this module is enabled by default, I think that it needs some more stress-testing in test_mmap.py. I'll try to add a couple of tests shortly. -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From trentm@activestate.com Sun Jun 18 04:20:09 2000 From: trentm@activestate.com (Trent Mick) Date: Sat, 17 Jun 2000 20:20:09 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules mmapmodule.c,2.10,2.11 In-Reply-To: <200006180050.CAA07547@python.inrialpes.fr> References: <200006172241.PAA02080@slayer.i.sourceforge.net> <200006180050.CAA07547@python.inrialpes.fr> Message-ID: <20000617202009.A20019@activestate.com> On Sun, Jun 18, 2000 at 02:50:51AM +0200, Vladimir Marangozov wrote: > > A.M. Kuchling wrote: > > > > Update of /cvsroot/python/python/dist/src/Modules > > In directory slayer.i.sourceforge.net:/tmp/cvs-serv2060 > > > > Modified Files: > > mmapmodule.c > > Log Message: > > Fix the size() method to return the size of the file on Unix, not the > > size of the mapped area. This seems to be what the Windows version does. > > This change requires keeping around the fd of the mapped file. > > On AIX, the test_mmap fails with errno=EINVAL on the m.flush() method. > It works okay without the MS_INVALIDATE flag though, so I'd suggest > removing it from msync in the flush and dealloc methods. > > Also, it would probably be a good idea to allow optional flags for > flush, as it's done in new_mmap_object, the default being only MS_SYNC. > > Given that this module is enabled by default, I think that it needs some > more stress-testing in test_mmap.py. I'll try to add a couple of tests > shortly. > Just to add to the mmap fray. The seek() method is broken for any 'whence' value (seek from start, current, orend) other than the default. Ihave a patch that fixes that as well as gets mmap'd files working on Linux64 and Win64. The test_mmap was also extended. The patch is up on SourceForge for your perusal. :) https://sourceforge.net/patch/?func=detailpatch&patch_id=100515&group_id=5470 Cheers, Trent -- Trent Mick trentm@activestate.com From mhammond@skippinet.com.au Sun Jun 18 04:35:00 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Sun, 18 Jun 2000 13:35:00 +1000 Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/Doc/lib libmmap.tex,NONE,1.1 In-Reply-To: <200006172239.PAA01994@slayer.i.sourceforge.net> Message-ID: > Documentation for the mmap module: proofreaders welcomed OK :-) > the file handle \var{fileno}, and returns a mmap object. If you have > a Python file object, its > \method{fileno()} method returns the file's handle, which is > just an integer. This could be a little clearer - on first reading, I thought you were talking about the return value. Maybe something like: "if you wish to pass an existing Python file object for this parameter, use its \method{fileno()} method to obtain the fileno." > \var{tagname}, if specified, is a string giving a tag name for > the mapping. XXX what is the purpose of the tag name? Something like: Windows allows you to have many different mappings against the same file. If you specify the name of an existing tag, that tag is opened, otherwise a new tag of this name is created. If this parameter is None, the mapping is created without a name. Avoiding the use of the tag parameter will assist in keeping your code portable between Unix and Windows. > \begin{funcdesc}{mmap}{file, size \optional{, flags, prot}} > (Unix version) Maps \var{length} bytes from the file specified by the > file handle \var{fileno}, and returns a mmap object. If you have a > Python file object, its \method{fileno()} method returns the file's > handle, which is just an integer. I believe you mean the signature to say "fileno" instead of "file" - this makes it consistent with the Windows signature, and reinforces that this param is indeed identical. As a meta-comment, the structure of this implies that the param signatures are more different than they are - eg, it should be possible to write portable mmap code in most cases, without concern for the platform. the platform only becomes relevant when you use the optional params for each platform? > \begin{methoddesc}{read}{\var{num}} > Return a string containing up to \var{num} bytes taken from the "taken from" -> "starting from" ?? > \begin{methoddesc}{write_byte}{\var{byte}} > Write \var{byte} into memory at the current position of > the file pointer; the file position is advanced by 1. > \end{methoddesc} The type of "byte" should be explained - its never clear to me if a "byte" should be an int or a string of size 1. In this case, it is the latter. Looks good! Mark. From mhammond@skippinet.com.au Sun Jun 18 04:35:33 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Sun, 18 Jun 2000 13:35:33 +1000 Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/Doc/lib libmmap.tex,NONE,1.1 In-Reply-To: <200006172239.PAA01994@slayer.i.sourceforge.net> Message-ID: Sorry about that - I meant to send it direct to Andrew... Mark. From Vladimir.Marangozov@inrialpes.fr Sun Jun 18 05:24:05 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Sun, 18 Jun 2000 06:24:05 +0200 (CEST) Subject: [Python-Dev] Towards selective compilation to native code? Message-ID: <200006180424.GAA14040@python.inrialpes.fr> There was a cool seminar the other day here, focusing on embedded & real-time Java, so I'll throw here some impressions while they're fresh. One of the presenters talked extensively about compilation strategies and techniques for Java bytecode to native code, and while I know that Java is not Python, it would be interesting to, at least, try to project some of the ideas to Python in the long run, where applicable. Needless to say, the guy & his environment (ex-OSF, now Silicomp) are experts in compiler technology and I'm not in a position to comment on everything, but you may find the second half of the slides enlightening: http://cgi-serv.inrialpes.fr/InTech/2000-06-15/ejava-silicomp.ppt So, the interesting part of the talk was about a "new" compiler architecture, built upon the concept of "Flash compiling" (quite unappropriate name), which produces a mixture of the following: 1. Bytecode 2. Native code 3. Native code is compiled selectively on demand and/or ahead of time (!= JIT) for "expensive" methods. 4. Expensive methods are, on one hand, detected by dynamic profiling of the bytecode, and OTOH, determined ahead of time according to the following 2 simple creteria: - methods containing loops - methods calling native code from bytecode (to avoid bytecode to native and vice versa arg conversion paths which are expensive -- btw Python has the same perf. bottleneck) 5. Everything relies on dyn loading & late binding of native code (front-end loads dynamically the back-end, native code is stored in the code stream, but linked incrementally & dynamically during execution) 6. The whole thing is designed to avoid code explosion and to preserve the advantage of bytecode == small code size, and the presented preliminary results are quite optimistic -- the figures differ depending on the code size / speed tradeoff. Of course, this is Java and there's static typing in there, but it would be interesting to see whether Python can steal something from these ideas. For instance, I'm trying to foresee what kind of static typing (i.e. how much static info) would be appropriate in Python from this point of view but I fail to obtain any realistic image :). I see most parts of the dyn loading / late binding aspect though -- they are typical for Python. Hm. Sounds like I'll be harrassing Tim to make him finally write something valuable for Python ;-) -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From akuchlin@mems-exchange.org Sun Jun 18 05:22:24 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Sun, 18 Jun 2000 00:22:24 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules mmapmodule.c,2.10,2.11 In-Reply-To: <200006180050.CAA07547@python.inrialpes.fr>; from Vladimir.Marangozov@inrialpes.fr on Sun, Jun 18, 2000 at 02:50:51AM +0200 References: <200006172241.PAA02080@slayer.i.sourceforge.net> <200006180050.CAA07547@python.inrialpes.fr> Message-ID: <20000618002224.A12729@newcnri.cnri.reston.va.us> On Sun, Jun 18, 2000 at 02:50:51AM +0200, Vladimir Marangozov wrote: >On AIX, the test_mmap fails with errno=EINVAL on the m.flush() method. >It works okay without the MS_INVALIDATE flag though, so I'd suggest >removing it from msync in the flush and dealloc methods. Ooh, you're right. The Linux msync man page says "MS_ASYNC specifies that an update be scheduled, but the call returns immediately. MS_SYNC asks for an update and waits for it to complete. MS_INVALIDATE asks to invalidate other mappings of the same file (so that they can be updated with the fresh values just written)." So MS_INVALIDATE seems far too drastic. >Also, it would probably be a good idea to allow optional flags for >flush, as it's done in new_mmap_object, the default being only MS_SYNC. The problem is: does Windows provide equivalent functionality? (Is there documentation available online for CreateFileMapping that I could look at?) >Given that this module is enabled by default, I think that it needs some >more stress-testing in test_mmap.py. I'll try to add a couple of tests >shortly. Good idea. I'll try to look at Trent Mick's patch and apply it ASAP if it checks out. --amk From akuchlin@mems-exchange.org Sun Jun 18 06:03:16 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Sun, 18 Jun 2000 01:03:16 -0400 Subject: [Python-Dev] Re: Almost insignificant patch for mmapmodule In-Reply-To: ; from lorenzo@sancho.ccd.uniroma2.it on Sat, Jun 17, 2000 at 04:29:14PM +0200 References: Message-ID: <20000618010316.D12729@newcnri.cnri.reston.va.us> On Sat, Jun 17, 2000 at 04:29:14PM +0200, Lorenzo M. Catucci wrote: >therefore, here is the change: if we are compiling for linux, define >_GNU_SOURCE before including mman.h, and all is done. It seems the Hmm... IMHO this points out a bug; if MREMAP_MAYMOVE is not present, that doesn't imply that mremap() doesn't work at all; instead, a resize may fail if the mapping would have to be moved to a different virtual address. Quoting from the Linux man page: MREMAP_MAYMOVE indicates if the operation should fail, or change the virtual address if the resize cannot be done at the current virtual address. I think the correct fix is to simply specify MREMAP_MAYMOVE if it's defined, but still support attempting to resize. Possibly the configure script should also check for mremap()'s existence. --amk From lorenzo@sancho.ccd.uniroma2.it Sun Jun 18 08:39:55 2000 From: lorenzo@sancho.ccd.uniroma2.it (Lorenzo M. Catucci) Date: Sun, 18 Jun 2000 09:39:55 +0200 (CEST) Subject: [Python-Dev] Re: Almost insignificant patch for mmapmodule In-Reply-To: <20000618010316.D12729@newcnri.cnri.reston.va.us> Message-ID: On Sun, 18 Jun 2000, Andrew Kuchling wrote: AK> On Sat, Jun 17, 2000 at 04:29:14PM +0200, Lorenzo M. Catucci wrote: AK> >therefore, here is the change: if we are compiling for linux, define AK> >_GNU_SOURCE before including mman.h, and all is done. It seems the AK>=20 AK> Hmm... IMHO this points out a bug; if MREMAP_MAYMOVE is not present, AK> that doesn't imply that mremap() doesn't work at all; instead, a AK> resize may fail if the mapping would have to be moved to a different AK> virtual address. Quoting from the Linux man page: AK>=20 AK> MREMAP_MAYMOVE AK> indicates if the operation should fail, or change AK> the virtual address if the resize cannot be done at AK> the current virtual address. AK>=20 AK> I think the correct fix is to simply specify MREMAP_MAYMOVE if it's AK> defined, but still support attempting to resize. Possibly the AK> configure script should also check for mremap()'s existence. AK>=20 I think I've been too dense... Here I see two problems: on one hand, from what I have understood of python's object, it's much better if the c pointers are movable in VM on the remap, and the MAYMOVE flag is only defined in mman.h if _GNU_SOURCE is; on the other hand, we only know about linux mremap semantics: for what I see in linix mremap(2) """ CONFORMING TO This call is Linux-specific, and should not be used in programs intended to be portable. 4.2BSD had a (never actually implemented) mremap(2) call with completely dif=AD ferent semantics. """ Therefore, I think that really checking for __linux__ and using the MAYMOVE flag, which is thefined there, is going towards the right way. If someone else comes out with another kernel supporting a mremap syscall[1], I think we'll be able to add proper support afterwards. As for the configure script, on linux we have both mremap and MAYMOVE; if you go to the Extended UNIX A= BI, M* Page,=20 you'll find: =09GNU Unix98 Unix95 POSIX ISO C SVID 3 4.3BSD XPG mremap X It seems only the systems supported by GNU libc-2 (only linux systems, then) support mremap... Have a nice time. lmc * Just tried searching for mremap on=20 http://www.FreeBSD.org/cgi/man.cgi?query=3Dmmap and looked around the various BSD derivatives whose man pages are available there.=20 +-------------------------+----------------------------------------------+ | Lorenzo M. Catucci | Centro di Calcolo e Documentazione | | catucci@ccd.uniroma2.it | Universit=E0 degli Studi di Roma "Tor Vergata" = | | | Via O. Raimondo 18 ** I-00173 ROMA ** ITALY | | Tel. +39 06 7259 2255 | Fax. +39 06 7259 2125 | +-------------------------+----------------------------------------------+ From petrilli@amber.org Sun Jun 18 19:50:22 2000 From: petrilli@amber.org (Christopher Petrilli) Date: Sun, 18 Jun 2000 14:50:22 -0400 Subject: [Python-Dev] Towards selective compilation to native code? In-Reply-To: <200006180424.GAA14040@python.inrialpes.fr>; from Vladimir.Marangozov@inrialpes.fr on Sun, Jun 18, 2000 at 06:24:05AM +0200 References: <200006180424.GAA14040@python.inrialpes.fr> Message-ID: <20000618145022.A13031@trump.amber.org> Vladimir Marangozov [Vladimir.Marangozov@inrialpes.fr] wrote: > > Of course, this is Java and there's static typing in there, but it > would be interesting to see whether Python can steal something from these > ideas. For instance, I'm trying to foresee what kind of static typing > (i.e. how much static info) would be appropriate in Python from this > point of view but I fail to obtain any realistic image :). > I see most parts of the dyn loading / late binding aspect though -- > they are typical for Python. One might take a look at Smalltalk/X which compiles into C, and has a pretty (ney very) high performance reputation. There are some other Smalltalk implementations taht do this as well. This would be closer I think to what Python would use than Java will be. Chris -- | Christopher Petrilli | petrilli@amber.org From Fredrik Lundh" consider this little program: import time, sre k =3D u"foo" p =3D sre.compile(k) s =3D "*"*500 + k + "*"*500 def f1(): p.search(s) def f2(): s.find(k) def bench(f): t0 =3D time.clock() for i in range(100000): f() print f, time.clock() - t0 bench(f1) bench(f2) which prints: 2.94704487169 10.5247875425 (Windows 95, 233 MHz) if I change the k variable to an 8-bit string, it prints: 2.47613520173 2.5178698939 (for some reason, sre is still slighty faster...) so in other words, something in unicode land isn't as efficient as it should... From akuchlin@mems-exchange.org Sun Jun 18 20:20:20 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Sun, 18 Jun 2000 15:20:20 -0400 Subject: [Python-Dev] talking about performance... In-Reply-To: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid>; from effbot@telia.com on Sun, Jun 18, 2000 at 09:06:45PM +0200 References: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid> Message-ID: <20000618152020.B14713@newcnri.cnri.reston.va.us> On Sun, Jun 18, 2000 at 09:06:45PM +0200, Fredrik Lundh wrote: >so in other words, something in unicode land isn't >as efficient as it should... The relevant bit of findstring() in unicodeobject.c: if (direction < 0) { for (; end >= start; end--) if (Py_UNICODE_MATCH(self, end, substring)) return end; } else { for (; start <= end; start++) if (Py_UNICODE_MATCH(self, start, substring)) return start; } And... #define Py_UNICODE_MATCH(string, offset, substring)\ (!memcmp((string)->str + (offset), (substring)->str,\ (substring)->length*sizeof(Py_UNICODE))) Proposed patch: Index: unicodeobject.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v retrieving revision 2.26 diff -u -r2.26 unicodeobject.c --- unicodeobject.c 2000/06/14 09:18:32 2.26 +++ unicodeobject.c 2000/06/18 19:18:01 @@ -2168,11 +2168,13 @@ if (direction < 0) { for (; end >= start; end--) - if (Py_UNICODE_MATCH(self, end, substring)) + if ( *(self->str + end) == *(substring->str) && + Py_UNICODE_MATCH(self, end, substring)) return end; } else { for (; start <= end; start++) - if (Py_UNICODE_MATCH(self, start, substring)) + if (*(self->str + start) == *(substring->str) && + Py_UNICODE_MATCH(self, start, substring)) return start; } --amk From akuchlin@mems-exchange.org Sun Jun 18 20:32:37 2000 From: akuchlin@mems-exchange.org (A.M. Kuchling) Date: Sun, 18 Jun 2000 15:32:37 -0400 Subject: [Python-Dev] Turning on sre? Message-ID: <200006181932.PAA03968@207-172-113-141.s141.tnt5.ann.va.dialup.rcn.com> Before 1.6a3, should the sre module be turned on, replacing re? That way it'll start getting tested; better we find problems sooner rather than later... --amk From guido@python.org Sun Jun 18 21:47:22 2000 From: guido@python.org (Guido van Rossum) Date: Sun, 18 Jun 2000 15:47:22 -0500 Subject: [Python-Dev] Turning on sre? In-Reply-To: Your message of "Sun, 18 Jun 2000 15:32:37 -0400." <200006181932.PAA03968@207-172-113-141.s141.tnt5.ann.va.dialup.rcn.com> References: <200006181932.PAA03968@207-172-113-141.s141.tnt5.ann.va.dialup.rcn.com> Message-ID: <200006182047.PAA03008@cj20424-a.reston1.va.home.com> > Before 1.6a3, should the sre module be turned on, replacing re? That > way it'll start getting tested; better we find problems sooner rather > than later... That would be nice. If I replace re.py with "from sre import *" and run test_re.py, I grt in trouble in the sub() test: $ ./python ../Lib/test/test_re.py Running tests on re.search and re.match Running tests on re.sub Traceback (most recent call last): File "../Lib/test/test_re.py", line 41, in ? assert re.sub(r'\d+', bump_num, '08.2 -2 23x99y') == '9.3 -3 24x100y' File "./../Lib/sre.py", line 35, in sub return _compile(pattern).sub(repl, string, count) File "./../Lib/sre.py", line 84, in _sub return _subn(pattern, template, string, count)[0] File "./../Lib/sre.py", line 114, in _subn return string[:0].join(s), n TypeError: sequence item 0 not a string $ It appears that the value of s is a list containing alternating zeros and strings: [0, '.', 0, ' -', 0, ' ', 0, 'x', 0, 'y']. No time to look into this further, but it could be a bug in sre._subn(). --Guido van Rossum (home page: http://www.python.org/~guido/) From akuchlin@mems-exchange.org Sun Jun 18 21:28:59 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Sun, 18 Jun 2000 16:28:59 -0400 Subject: [Python-Dev] Turning on sre? In-Reply-To: <200006182047.PAA03008@cj20424-a.reston1.va.home.com>; from guido@python.org on Sun, Jun 18, 2000 at 03:47:22PM -0500 References: <200006181932.PAA03968@207-172-113-141.s141.tnt5.ann.va.dialup.rcn.com> <200006182047.PAA03008@cj20424-a.reston1.va.home.com> Message-ID: <20000618162859.A15018@newcnri.cnri.reston.va.us> On Sun, Jun 18, 2000 at 03:47:22PM -0500, Guido van Rossum wrote: >No time to look into this further, but it could be a bug in sre._subn(). It's a typo; fixed. However, test_re then runs into the fact that _expand(), which should expand escapes in the replacement string, isn't implemented yet. --amk From Fredrik Lundh" <20000618152020.B14713@newcnri.cnri.reston.va.us> Message-ID: <008301bfd96e$0bd98d20$f2a6b5d4@hagrid> amk wrote: > On Sun, Jun 18, 2000 at 09:06:45PM +0200, Fredrik Lundh wrote: > >so in other words, something in unicode land isn't > >as efficient as it should... >=20 > The relevant bit of findstring() in unicodeobject.c: >=20 > if (direction < 0) { > for (; end >=3D start; end--) > if (Py_UNICODE_MATCH(self, end, substring)) > return end; > } else { > for (; start <=3D end; start++) > if (Py_UNICODE_MATCH(self, start, substring)) > return start; > } >=20 > And... >=20 > #define Py_UNICODE_MATCH(string, offset, substring)\ > (!memcmp((string)->str + (offset), (substring)->str,\ > (substring)->length*sizeof(Py_UNICODE))) heh. it's my own code, of course... > Proposed patch: >=20 > Index: unicodeobject.c MATCH is used in a couple of places; it's probably a better idea to change the macro (in Include/unicodeobject.h). MAL? From Fredrik Lundh" Message-ID: <009501bfd96e$4d11b7e0$f2a6b5d4@hagrid> amk wrote: > Before 1.6a3, should the sre module be turned on, replacing re? That > way it'll start getting tested; better we find problems sooner rather > than later... in addition to the typo you noticed, there's a backtracking (I think) problem that affects xmllib.py and tokenize.py... I'm working on it. From mal@lemburg.com Sun Jun 18 22:48:32 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Sun, 18 Jun 2000 23:48:32 +0200 Subject: [Python-Dev] talking about performance... References: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid> <20000618152020.B14713@newcnri.cnri.reston.va.us> <008301bfd96e$0bd98d20$f2a6b5d4@hagrid> Message-ID: <394D43B0.8CC7070@lemburg.com> Fredrik Lundh wrote: > > amk wrote: > > > On Sun, Jun 18, 2000 at 09:06:45PM +0200, Fredrik Lundh wrote: > > >so in other words, something in unicode land isn't > > >as efficient as it should... > > > > The relevant bit of findstring() in unicodeobject.c: > > > > if (direction < 0) { > > for (; end >= start; end--) > > if (Py_UNICODE_MATCH(self, end, substring)) > > return end; > > } else { > > for (; start <= end; start++) > > if (Py_UNICODE_MATCH(self, start, substring)) > > return start; > > } > > > > And... > > > > #define Py_UNICODE_MATCH(string, offset, substring)\ > > (!memcmp((string)->str + (offset), (substring)->str,\ > > (substring)->length*sizeof(Py_UNICODE))) > > heh. it's my own code, of course... > > > Proposed patch: > > > > Index: unicodeobject.c > > MATCH is used in a couple of places; it's probably a better idea > to change the macro (in Include/unicodeobject.h). MAL? Right. I'll add Andrew's proposed patch to the macro def. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Fredrik Lundh" Message-ID: <00c601bfd975$358d0aa0$f2a6b5d4@hagrid> mal wrote: > =20 > #define Py_UNICODE_MATCH(string, offset, substring)\ > ! ((*((string)->str + (offset)) =3D=3D *((substring)->str)) &&\ > ! !memcmp((string)->str + (offset), (substring)->str,\ > (substring)->length*sizeof(Py_UNICODE))) > =20 I completely forgot that this has different semantics if the substring happens to be empty. (substrings are null terminated, but "\0" isn't the same thing as ""...) don't have time to screen unicodeobject.c right now, but maybe someone else can do it? if not, maybe amk's patch was a better idea after all... From mwh21@cam.ac.uk Mon Jun 19 00:15:25 2000 From: mwh21@cam.ac.uk (Michael Hudson) Date: 19 Jun 2000 00:15:25 +0100 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules _tkinter.c,1.99,1.100 In-Reply-To: "A.M. Kuchling"'s message of "Sun, 18 Jun 2000 11:45:52 -0700" References: <200006181845.LAA10182@slayer.i.sourceforge.net> Message-ID: "A.M. Kuchling" writes: > Update of /cvsroot/python/python/dist/src/Modules > In directory slayer.i.sourceforge.net:/tmp/cvs-serv10064/Modules > > Modified Files: > _tkinter.c > Log Message: > Patch from /F: > this patch adds a fast _flatten function to the _tkinter > module, and imports it from Tkinter.py (if available). > > this speeds up canvas operations like create_line and > create_polygon. for example, a create_line with 5000 > vertices runs about 50 times faster with this patch in > place. Unfortunately this introduces another Way To Make Python Core: [mwh21@atrus build]$ ./python Python 1.6a2 (#4, Jun 18 2000, 23:57:36) [GCC 2.95.1 19990816/Linux (release)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> import Tkinter >>> l = [] >>> l.append(l) >>> Tkinter._flatten(l) Segmentation fault (core dumped) Here's a simple solution: Index: _tkinter.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/_tkinter.c,v retrieving revision 1.100 diff -u -r1.100 _tkinter.c --- _tkinter.c 2000/06/18 18:45:50 1.100 +++ _tkinter.c 2000/06/18 23:13:22 @@ -2001,13 +2001,16 @@ } static int -_flatten1(FlattenContext* context, PyObject* item) +_flatten1(FlattenContext* context, PyObject* item, int depth) { /* add tuple or list to argument tuple (recursively) */ int i, size; - if (PyList_Check(item)) { + if (depth > 1000) { + PyErr_SetString(PyExc_ValueError,"nesting too deep in _flatten"); + return 0; + } else if (PyList_Check(item)) { size = PyList_GET_SIZE(item); /* preallocate (assume no nesting) */ if (context->size + size > context->maxsize && !_bump(context, size)) @@ -2016,7 +2019,7 @@ for (i = 0; i < size; i++) { PyObject *o = PyList_GET_ITEM(item, i); if (PyList_Check(o) || PyTuple_Check(o)) { - if (!_flatten1(context, o)) + if (!_flatten1(context, o, depth + 1)) return 0; } else if (o != Py_None) { if (context->size + 1 > context->maxsize && !_bump(context, 1)) @@ -2033,7 +2036,7 @@ for (i = 0; i < size; i++) { PyObject *o = PyTuple_GET_ITEM(item, i); if (PyList_Check(o) || PyTuple_Check(o)) { - if (!_flatten1(context, o)) + if (!_flatten1(context, o, depth + 1)) return 0; } else if (o != Py_None) { if (context->size + 1 > context->maxsize && !_bump(context, 1)) @@ -2068,7 +2071,7 @@ context.size = 0; - if (!_flatten1(&context, item)) + if (!_flatten1(&context, item,0)) return NULL; if (_PyTuple_Resize(&context.tuple, context.size, 0)) "seems to work"; I've not tested it for performance, but I can't believe this is too hard a hit. Cheers, M. From mal@lemburg.com Mon Jun 19 00:20:27 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 19 Jun 2000 01:20:27 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Include unicodeobject.h,2.9,2.10 References: <200006182222.PAA19408@slayer.i.sourceforge.net> <00c601bfd975$358d0aa0$f2a6b5d4@hagrid> Message-ID: <394D593B.DD4804E6@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > > > #define Py_UNICODE_MATCH(string, offset, substring)\ > > ! ((*((string)->str + (offset)) == *((substring)->str)) &&\ > > ! !memcmp((string)->str + (offset), (substring)->str,\ > > (substring)->length*sizeof(Py_UNICODE))) > > > > I completely forgot that this has different semantics if the > substring happens to be empty. > > (substrings are null terminated, but "\0" isn't the same > thing as ""...) > > don't have time to screen unicodeobject.c right now, but > maybe someone else can do it? if not, maybe amk's patch > was a better idea after all... I've checked the places where this macro is used: all except the in .count() method showed the same behaviour as for 8-bit strings. The Unicode .count() method now also returns the same value for empty substrings as the 8-bit strings. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Fredrik Lundh" Message-ID: <002701bfd97d$09d8b640$f2a6b5d4@hagrid> michael wrote: > > this patch adds a fast _flatten function to the _tkinter > > module, and imports it from Tkinter.py (if available). > > Unfortunately this introduces another Way To Make Python Core: well, there are lots of way to dump core through Tkinter/Tk, so I convinced myself that it wasn't really worth the effort to prevent it in _flatten... either way, the patch looks okay to me. From mwh21@cam.ac.uk Mon Jun 19 00:41:22 2000 From: mwh21@cam.ac.uk (Michael Hudson) Date: 19 Jun 2000 00:41:22 +0100 Subject: [Python-Dev] CVS: python/dist/src/Modules _tkinter.c,1.99,1.100 In-Reply-To: "Fredrik Lundh"'s message of "Mon, 19 Jun 2000 01:29:23 +0200" References: <200006181845.LAA10182@slayer.i.sourceforge.net> <002701bfd97d$09d8b640$f2a6b5d4@hagrid> Message-ID: "Fredrik Lundh" writes: > michael wrote: > > > this patch adds a fast _flatten function to the _tkinter > > > module, and imports it from Tkinter.py (if available). > > > > Unfortunately this introduces another Way To Make Python Core: > > well, there are lots of way to dump core through Tkinter/Tk, so I > convinced myself that it wasn't really worth the effort to prevent > it in _flatten... Are there? (I hardly know Tkinter). Oh well. I don't know of many "core" methods of doing it; the only one I can think of is marshalling a recursive list, and as there seems to be a loud party going on next door to me, I may write a patch for that this evening... Cheers, M. From mhammond@skippinet.com.au Mon Jun 19 01:05:00 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Mon, 19 Jun 2000 10:05:00 +1000 Subject: [Python-Dev] Welcome back In-Reply-To: <200006182047.PAA03008@cj20424-a.reston1.va.home.com> Message-ID: Welcome back, welcome back, welcome baaaaack - Welcome back, welcome back, welcome baaaaack Good to see you return. Im sure you had a wonderful time! From all accounts, your wedding was beautiful, as Im sure your honeymoon was... Now-were-just-waiting-for-the-baby-announcements-ly, Mark. > -----Original Message----- > From: python-dev-admin@python.org [mailto:python-dev-admin@python.org]On > Behalf Of Guido van Rossum > Sent: Monday, 19 June 2000 6:47 AM > To: akuchlin@mems-exchange.org > Cc: python-dev@python.org > Subject: Re: [Python-Dev] Turning on sre? From tim_one@email.msn.com Mon Jun 19 03:05:16 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 18 Jun 2000 22:05:16 -0400 Subject: [Python-Dev] Welcome back In-Reply-To: Message-ID: [Mark Hammond] > ... > Good to see you return. Im sure you had a wonderful time! From > all accounts, your wedding was beautiful, as Im sure your > honeymoon was... > > Now-were-just-waiting-for-the-baby-announcements-ly, Guido & Kim just spent the last night of their honeymoon with Uncle Timmy (who is now living in a Virginia motel room), and I can assure you no babies were made by any pair of us tonight. Unless Guido is quicker than he looks. i'm-certainly-not-ly y'rs - tim From skip@mojam.com (Skip Montanaro) Sat Jun 17 04:45:14 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Fri, 16 Jun 2000 22:45:14 -0500 (CDT) Subject: [Python-Dev] list comprehensions Message-ID: <14666.62538.988511.305499@beluga.mojam.com> Did list comprehensions ever make it into 1.6? I thought I submitted a 1.6-compatible update of Greg Ewing's mods awhile ago. Should I resubmit? To the patches list? -- Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On June 24th at 8AM, live your life for an hour as Ricky Byrdsong always lived his - run/walk in the Ricky Byrdsong Memorial 5K or just make a donation: https://www.SignmeupSports.com/Events/Index_Events.asp?EventID=1395 From guido@python.org Mon Jun 19 16:01:24 2000 From: guido@python.org (Guido van Rossum) Date: Mon, 19 Jun 2000 10:01:24 -0500 Subject: [Python-Dev] list comprehensions In-Reply-To: Your message of "Fri, 16 Jun 2000 22:45:14 EST." <14666.62538.988511.305499@beluga.mojam.com> References: <14666.62538.988511.305499@beluga.mojam.com> Message-ID: <200006191501.KAA02197@cj20424-a.reston1.va.home.com> > Did list comprehensions ever make it into 1.6? No (as far as I'm aware :-). > I thought I submitted a > 1.6-compatible update of Greg Ewing's mods awhile ago. Should I resubmit? > To the patches list? It's rather late in the release cycle -- I'm trying to get alpha 3 released, and i'm still 1400 messages behind on my email. But submitting a patch might be a good idea anyway so we won't forget about it (and maybe it's of such baffling simplicity that it'll charm its way past the guards :-). --Guido van Rossum (home page: http://www.python.org/~guido/) From ping@lfw.org Mon Jun 19 19:59:15 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Mon, 19 Jun 2000 13:59:15 -0500 (CDT) Subject: [Python-Dev] list comprehensions In-Reply-To: <200006191501.KAA02197@cj20424-a.reston1.va.home.com> Message-ID: On Mon, 19 Jun 2000, Guido van Rossum wrote: > > Did list comprehensions ever make it into 1.6? > > No (as far as I'm aware :-). [...] > But submitting a patch might be a good idea anyway so we won't forget > about it (and maybe it's of such baffling simplicity that it'll charm > its way past the guards :-). I just have to say i thought list comprehensions were really cool. -- ?!ng From skip@mojam.com (Skip Montanaro) Mon Jun 19 21:17:59 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Mon, 19 Jun 2000 15:17:59 -0500 Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions... Message-ID: <200006192017.PAA00690@beluga.mojam.com> Python's sys module defines an exitfunc variable that is settable from Python scripts. At exit, that function will be called with no arguments. While this is a good start at supporting standard cleanup activities, it defines no protocol to be used by modules that wish to use sys.exitfunc, which leads to one of two extremes: 1, two modules wishing to define cleanup functions both clobber sys.exitfunc or 2, to avoid collisions they don't use the functionality provided. At an application level this is okay. Within a single application you can define an application-specific protocol to handle the situation. Unfortunately, this still leaves Python's core modules without a good way to register exit functions. I ran into this problem today. I would really like the rlcompleter module to read and write readline history files from Python. Reading a history file at module startup is no problem, but deciding where to write the history file is a problem. The logical place is at the time sys.exitfunc is executed. For my own applications I long ago wrote a very simple module (called exit.py, appended to this message) that defines two functions: * exit.register_exitfunc takes a function object and a set of optional arguments and appends them to a list. * exit._run_exitfuncs is bound to sys.exitfunc and executes the registered exit functions in the order they appear in the list. I propose exit.py as the starting point for a well-defined protocol for modules to register exit functions without collisions. -- Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On June 24th at 8AM, live your life for an hour as Ricky Byrdsong always lived his - run/walk in the Ricky Byrdsong Memorial 5K or just make a donation: https://www.SignmeupSports.com/Events/Index_Events.asp?EventID=1395 """ allow programmer to define multiple exit functions to be executed upon normal program termination. """ _exithandlers = [] def _run_exitfuncs(): while _exithandlers: func, targs, kargs = _exithandlers[0] apply(func, targs, kargs) _exithandlers.remove(_exithandlers[0]) def register_exitfunc(func, *targs, **kargs): """register a function to be executed upon normal program termination arguments are a function object, and zero or more arguments to pass to it. """ _exithandlers.append((func, targs, kargs)) import sys try: x = sys.exitfunc except AttributeError: sys.exitfunc = _run_exitfuncs del sys if __name__ == "__main__": def x1(): print "running x1" def x2(n): print "running x2(%s)" % `n` def x3(n, kwd=None): print "running x3(%s, kwd=%s)" % (`n`, `kwd`) register_exitfunc(x1) register_exitfunc(x2, 12) register_exitfunc(x3, 5, "bar") register_exitfunc(x3, "no kwd args") From DavidA@ActiveState.com Mon Jun 19 21:27:48 2000 From: DavidA@ActiveState.com (David Ascher) Date: Mon, 19 Jun 2000 13:27:48 -0700 Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions... In-Reply-To: <200006192017.PAA00690@beluga.mojam.com> Message-ID: +1 on the idea. I wonder if it makes sense to publish a mechanism to allow de-registering of callbacks, or if that's featuritis. Also, I'd change: > try: > x = sys.exitfunc > except AttributeError: > sys.exitfunc = _run_exitfuncs > del sys to: try: register_exitfuncs(sys.exitfunc) finally: sys.exitfunc = _run_exitfuncs Or some such. --david > -----Original Message----- > From: python-dev-admin@python.org [mailto:python-dev-admin@python.org]On > Behalf Of Skip Montanaro > Sent: Monday, June 19, 2000 1:18 PM > To: python-dev@python.org > Subject: [Python-Dev] Proposal: standard way of defining and executing > "atexit" functions... > Importance: Low > > > > Python's sys module defines an exitfunc variable that is settable from > Python scripts. At exit, that function will be called with no arguments. > While this is a good start at supporting standard cleanup activities, it > defines no protocol to be used by modules that wish to use sys.exitfunc, > which leads to one of two extremes: 1, two modules wishing to > define cleanup > functions both clobber sys.exitfunc or 2, to avoid collisions > they don't use > the functionality provided. > > At an application level this is okay. Within a single application you can > define an application-specific protocol to handle the situation. > Unfortunately, this still leaves Python's core modules without a > good way to > register exit functions. > > I ran into this problem today. I would really like the rlcompleter module > to read and write readline history files from Python. Reading a history > file at module startup is no problem, but deciding where to write the > history file is a problem. The logical place is at the time > sys.exitfunc is > executed. > > For my own applications I long ago wrote a very simple module (called > exit.py, appended to this message) that defines two functions: > > * exit.register_exitfunc takes a function object and a set of optional > arguments and appends them to a list. > > * exit._run_exitfuncs is bound to sys.exitfunc and executes the > registered exit functions in the order they appear in the list. > > I propose exit.py as the starting point for a well-defined protocol for > modules to register exit functions without collisions. > > -- > Skip Montanaro, skip@mojam.com, http://www.mojam.com/, > http://www.musi-cal.com/ > On June 24th at 8AM, live your life for an hour as Ricky Byrdsong always > lived > his - run/walk in the Ricky Byrdsong Memorial 5K or just make a donation: > https://www.SignmeupSports.com/Events/Index_Events.asp?EventID=1395 > > > """ > allow programmer to define multiple exit functions to be executed upon > normal > program termination. > """ > > _exithandlers = [] > def _run_exitfuncs(): > while _exithandlers: > func, targs, kargs = _exithandlers[0] > apply(func, targs, kargs) > _exithandlers.remove(_exithandlers[0]) > > def register_exitfunc(func, *targs, **kargs): > """register a function to be executed upon normal program termination > > arguments are a function object, and zero or more arguments to pass to > it. > """ > _exithandlers.append((func, targs, kargs)) > > import sys > try: > x = sys.exitfunc > except AttributeError: > sys.exitfunc = _run_exitfuncs > del sys > > if __name__ == "__main__": > def x1(): > print "running x1" > def x2(n): > print "running x2(%s)" % `n` > def x3(n, kwd=None): > print "running x3(%s, kwd=%s)" % (`n`, `kwd`) > > register_exitfunc(x1) > register_exitfunc(x2, 12) > register_exitfunc(x3, 5, "bar") > register_exitfunc(x3, "no kwd args") > > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://www.python.org/mailman/listinfo/python-dev > From skip@mojam.com (Skip Montanaro) Mon Jun 19 21:55:09 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Mon, 19 Jun 2000 15:55:09 -0500 (CDT) Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions... In-Reply-To: References: <200006192017.PAA00690@beluga.mojam.com> Message-ID: <14670.34989.887973.797947@beluga.mojam.com> David> +1 on the idea. I wonder if it makes sense to publish a David> mechanism to allow de-registering of callbacks, or if that's David> featuritis. While writing my message I thought, "I'll bet the first question asked will be about unregistering exit functions." I've been using the module I appended to my message unchanged for a couple years and never needed such functionality. I'm sure there are applications that could use it, but I think they'd be a small minority. Since the only defined interface is a single registration function (_run_exitfuncs is only used internally), I think you'd be free to add some unregister function protocol at a later time if it was deemed necessary. David> Also, I'd change: >> try: >> x = sys.exitfunc >> except AttributeError: >> sys.exitfunc = _run_exitfuncs >> del sys David> to: David> try: David> register_exitfuncs(sys.exitfunc) David> finally: David> sys.exitfunc = _run_exitfuncs David> Or some such. register_exitfunc is only meant to be called by clients of the module, not used internally. You're assuming that if something else was already bound to sys.exitfunc that it's not _run_exitfuncs. With your try/finally code try the following (mentally is fine): import exit def foo(): print 1 exit.register_exitfunc(foo) reload(exit) I think you'll see that exit._run_exitfuncs is on its own list of exit functions. That could be bad. The setup code: try: x = sys.exitfunc except AttributeError: sys.exitfunc = _run_exitfuncs is meant to avoid doing anything if any other module beat us to sys.exitfunc. Perhaps it should just be sys.exitfunc = _run_exitfuncs If someone fails to use the defined protocol, screw 'em... ;-) Skip From DavidA@ActiveState.com Mon Jun 19 22:12:03 2000 From: DavidA@ActiveState.com (David Ascher) Date: Mon, 19 Jun 2000 14:12:03 -0700 Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions... In-Reply-To: <14670.34989.887973.797947@beluga.mojam.com> Message-ID: > If someone fails to use the defined protocol, screw 'em... ;-) That's unreasonable given that existing tools might include a library which might be upgraded to use the new mechanism while the old code used its own mechanism happily. For example, I've used my own protocols in the past which went something like... def register_exitfunc(func): old_exitfunc = getattr(sys, 'exitfunc', None) def wrapper(old_exitfunc=old_exitfunc, new_func=func): if old_exitfunc is not None: old_exitfunc() new_func() sys.exitfunc = wrapper or some such, creating a call chain instead of a sequence of calls, and it's a 'fine' protocol in that it worked fine in the absence of a standard. No need to break code if we can avoid it. The point of my pseudo-patch, if it wasn't clear, was that if a function is already in sys.exitfunc, then it should still be called on exit after the new exit module is imported. You're right that my patch didn't properly check that _run_exitfuncs might be that function. --david From skip@mojam.com (Skip Montanaro) Mon Jun 19 22:41:54 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Mon, 19 Jun 2000 16:41:54 -0500 (CDT) Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions... In-Reply-To: References: <14670.34989.887973.797947@beluga.mojam.com> Message-ID: <14670.37794.998270.762852@beluga.mojam.com> >> If someone fails to use the defined protocol, screw 'em... ;-) David> That's unreasonable given that existing tools might include a David> library which might be upgraded to use the new mechanism while David> the old code used its own mechanism happily. Point taken. I'll look at extending the module to accommodate other sys.exitfunc callers. Skip From Vladimir.Marangozov@inrialpes.fr Tue Jun 20 02:11:24 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Tue, 20 Jun 2000 03:11:24 +0200 (CEST) Subject: [Python-Dev] mmapmodule.c,2.10,2.11 In-Reply-To: <20000618002224.A12729@newcnri.cnri.reston.va.us> from "Andrew Kuchling" at Jun 18, 2000 12:22:24 AM Message-ID: <200006200111.DAA01591@python.inrialpes.fr> Andrew Kuchling wrote: > > On Sun, Jun 18, 2000 at 02:50:51AM +0200, Vladimir Marangozov wrote: > >On AIX, the test_mmap fails with errno=EINVAL on the m.flush() method. > >It works okay without the MS_INVALIDATE flag though, so I'd suggest > >removing it from msync in the flush and dealloc methods. > > Ooh, you're right. The Linux msync man page says "MS_ASYNC specifies > that an update be scheduled, but the call returns immediately. > MS_SYNC asks for an update and waits for it to complete. > MS_INVALIDATE asks to invalidate other mappings of the same file (so > that they can be updated with the fresh values just written)." So > MS_INVALIDATE seems far too drastic. Yes. > > >Also, it would probably be a good idea to allow optional flags for > >flush, as it's done in new_mmap_object, the default being only MS_SYNC. > > The problem is: does Windows provide equivalent functionality? (Is > there documentation available online for CreateFileMapping that I > could look at?) Well, I had a look at my Windows book. Although the mmap functionnality is equivalent, overall, there are no equivalent flags in FlushViewOfFile, etc. Maybe this is too subtle to be of any real use after all, so I retract the idea. MS_SYNC alone is fine. Another point: I'm not thrilled about the idea of raising a SystemError for m.resize if native mremap is missing (which is also AIX's case). unmap/mmap again with the new size is the emulation solution everybody would do in Python when m.resize is not implemented. So I'd suggest implementing it in C (which is what the Windows version does, btw). Furthermore, having an unimplemented method makes little sense to me. For implementing this emulation on Unix, however, we would need to remember in additional slots the original mmap flags & rights, so that the second (or any subsequent) mmap call uses the same flags & rights as the first one. -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From pf@artcom-gmbh.de Tue Jun 20 08:32:33 2000 From: pf@artcom-gmbh.de (Peter Funk) Date: Tue, 20 Jun 2000 09:32:33 +0200 (MEST) Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions... In-Reply-To: from David Ascher at "Jun 19, 2000 2:12: 3 pm" Message-ID: Hi Skip, Hi David, David Ascher: > > If someone fails to use the defined protocol, screw 'em... ;-) > > That's unreasonable given that existing tools might include a library which > might be upgraded to use the new mechanism while the old code used its own > mechanism happily. For example, I've used my own protocols in the past > which went something like... > > def register_exitfunc(func): > old_exitfunc = getattr(sys, 'exitfunc', None) > def wrapper(old_exitfunc=old_exitfunc, new_func=func): > if old_exitfunc is not None: old_exitfunc() > new_func() > sys.exitfunc = wrapper > > or some such, creating a call chain instead of a sequence of calls, and it's > a 'fine' protocol in that it worked fine in the absence of a standard. No > need to break code if we can avoid it. Davids wrapper function implements a FIFO strategy for termination. I think this is not desired. Normally you want LIFO, because higher level services in an application are initialized later during startup. Those services usually depend on lower level services, which should still be available at termination time of the higher level services. I try to explain this by an example: Module A provides some kind of network connections. Module B uses (imports) Module A to access a remote resource administration server to provide access to remote devices or resources. During program termination Module B likes to release all resources reserved for (owned by) the program. It uses Module A to submit a cleanup request to the server. Module A however wants to close all open network connections. The following function (termination protocol) solves this by exchanging the sequence of calls within the wrapper: def register_exit_func(func, *args, **kw): import sys previous_func = sys.exit_func def wrapped_func(previous_func=previous_func, func=func, args=args, kw=kw): try: apply(func, args, kw) finally: if previous_func is not None: previous_func() sys.exit_func = wrapped_func In the past I've placed such a function into a common base module of my apps. But I think, Skip is right, that a termination protocol should be part of the standard library. But a separate module 'exit.py' seems to be overkill for single basic function. May be it should be put into the module 'os'? Handling of program termination is something, which considered as a generic operating system service. From the users point of view 'sys' would be a better place, but this would require rewriting in C: ugly. I also agree with Skip, that the possibility to unregister an exit_func is normally not needed. The same effect can be achieved by doing nothing in the exit_func. Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen) From mhammond@skippinet.com.au Tue Jun 20 09:02:14 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Tue, 20 Jun 2000 18:02:14 +1000 Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions... In-Reply-To: Message-ID: Peter: > Davids wrapper function implements a FIFO strategy for termination. > I think this is not desired. Normally you want LIFO, Agreed. LIFO is definately preferred IMO. Mark. From pf@artcom-gmbh.de Tue Jun 20 09:08:16 2000 From: pf@artcom-gmbh.de (Peter Funk) Date: Tue, 20 Jun 2000 10:08:16 +0200 (MEST) Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions... In-Reply-To: From "(env:" "pf)" at "Jun 20, 2000 9:32:33 am" Message-ID: Hi, I wrote: > def register_exit_func(func, *args, **kw): > import sys > previous_func = sys.exit_func this should have been 'sys.exitfunc'. I've also misssed to note, that I placed the following line into the module init code: import sys; def _nop(): pass; sys.exitfunc = _nop Otherwise I had to use getattr(sys, 'exitfunc', None) as David suggested. Next time I should actually cut'n'paste working code instead typing from blurred memory. :-( Another point I forgot, was that you usually want to install signal handlers on unices, that handle the signal.SIGTERM, signal.SIGHUP and signal.SIGINT signals and invoke exit function to do some final cleanup. Regards, Peter From mal@lemburg.com Tue Jun 20 10:01:50 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 20 Jun 2000 11:01:50 +0200 Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions... References: Message-ID: <394F32FE.B926C19A@lemburg.com> This is a multi-part message in MIME format. --------------23EABAE62CA66BEF28D4AF1B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Attached you find a similar module which I have used for years. It has all the requested features, plus allows deregistration and supports a more OO-like interface. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ --------------23EABAE62CA66BEF28D4AF1B Content-Type: text/python; charset=us-ascii; name="ExitFunctions.py" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ExitFunctions.py" """ Central Registry for sys.exitfunc()-type functions """ __version__ = "0.1" __package_info__ = """ BEGIN PYTHON-PACKAGE-INFO 1.0 Title: Central Registry for sys.exitfunc()-type functions Current-Version: 0.1 Home-Page: http://starship.skyport.net/~lemburg Primary-Site: http://starship.skyport.net/~lemburg/ExitFunctions.py END PYTHON-PACKAGE-INFO """ import sys,traceback class ExitFunctionDispatcher: """ Singleton that manages exit functions. These function will be called upon system exit in reverse order of their registering. """ def __init__(self): """ Install the dispatcher as sys.exitfunc() """ self.exitfunc_list = [] if hasattr(sys,'exitfunc'): self.old_exitfunc = sys.exitfunc else: self.old_exitfunc = None sys.exitfunc = self.exitfunc def exitfunc(self, write=sys.stderr.write,print_exc=traceback.print_exc, stderr=sys.stderr): """ This is the exitfunc that we install to dispatch the processing to the registered other functions """ for f in self.exitfunc_list: try: f() except: write('Error while executing Exitfunction %s:\n' % f.__name__) print_exc(10,stderr) # Now that we're finished, call the previously installed exitfunc() if self.old_exitfunc: self.old_exitfunc() def register(self,f,position=0): """ Register f as exit function. These functions must not take parameters. - position = 0: register the function at the beginning of the list; these functions get called before the functions already in the list (default) - position = -1: register the function at the end of the list; the function will get called after all other functions """ if position < 0: position = position + len(self.exitfunc_list) + 1 self.exitfunc_list.insert(position,f) def deregister(self,f): """ Remove the function f from the exitfunc list; if it is not found, the error is silently ignored. """ try: self.exitfunc_list.remove(f) except: pass # Create the singleton ExitFunctions = ExitFunctionDispatcher() --------------23EABAE62CA66BEF28D4AF1B-- From fredrik@pythonware.com Tue Jun 20 11:15:01 2000 From: fredrik@pythonware.com (Fredrik Lundh) Date: Tue, 20 Jun 2000 12:15:01 +0200 Subject: [Python-Dev] talking about performance... [case closed] References: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid> <20000618152020.B14713@newcnri.cnri.reston.va.us> <008301bfd96e$0bd98d20$f2a6b5d4@hagrid> <394D43B0.8CC7070@lemburg.com> Message-ID: <003101bfdaa0$693b4de0$0900a8c0@SPIFF> mal wrote: > > > Index: unicodeobject.c > > > > MATCH is used in a couple of places; it's probably a better idea > > to change the macro (in Include/unicodeobject.h). MAL? > > Right. I'll add Andrew's proposed patch to the macro def. for the record, my little benchmark now runs about five times faster than before -- which means that 16-bit find is now ~30% faster than 8-bit find (barry? ;-) cheers /F footnote: for the exact figures, see: http://hem.passagen.se/eff/2000_06_01_bot-archive.htm#361472 From mhammond@skippinet.com.au Tue Jun 20 12:42:53 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Tue, 20 Jun 2000 21:42:53 +1000 Subject: [Python-Dev] Fw: Access violation when no memory Message-ID: From the newsgroup. Any thoughts? Mark. "Phil Mayes" wrote in message news:... > The following program progressively allocates all memory: > size = 1 << 20 > list = [None,] > while size: > try: > mem = [None] * size > mem[0] = list > list = mem > except: > size = size / 2 > > It fails with an access violation. (Turn off virtual memory > to provoke it.) This is not a theoretical situation for me: > I have a beta release in the field that is crashing like this. > The immediate cause is this: > > 1. we are handling a MemoryError > 2. the following call cannot allocate a traceback object > ceval.c line 1800: PyErr_Fetch(&exc, &val, &tb); > 3. the NULL pointer at tb is pushed here: > ceval.c line 1816: PUSH(tb); > ceval.c line 1817: PUSH(val); > ceval.c line 1818: PUSH(exc); > 4. later it is popped here and its ref count is decremented: > ceval.c line 682: case POP_TOP: > ceval.c line 683: v = POP(); > ceval.c line 684: Py_DECREF(v); > ceval.c line 685: continue; > > This is with 1.5.2 but the crash still happens with 1.6a2. > At this stage I am way out of my depth, and the only way I > see to fix this is to change Py_DECREF to Py_XDECREF, which > is a (minor?) inefficiency. Can anyone recommend a better way? > > And should I report this at http://www.python.org/python-bugs? > I do not have access to the current CVS tree. > > TIA, Phil Mayes > -- > pmayes AT olivebr DOT com > > > From gward@mems-exchange.org Tue Jun 20 13:33:44 2000 From: gward@mems-exchange.org (Greg Ward) Date: Tue, 20 Jun 2000 08:33:44 -0400 Subject: [Python-Dev] RFC: Including PIL in 1.6 In-Reply-To: <20000609181924.A15728@thyrsus.com>; from esr@thyrsus.com on Fri, Jun 09, 2000 at 06:19:24PM -0400 References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> Message-ID: <20000620083344.A3499@ludwig.cnri.reston.va.us> On 09 June 2000, Eric S. Raymond said: > I think it's time to consider including PIL in the core Python 1.6 release. > I've been following the work being done over there, and I believe the > code has reached a sufficient level of maturity to justify this. -1 from me. What's the point of the Distutils if we just throw everything "useful" into the standard distribution? Greg From gward@mems-exchange.org Tue Jun 20 13:40:41 2000 From: gward@mems-exchange.org (Greg Ward) Date: Tue, 20 Jun 2000 08:40:41 -0400 Subject: [Python-Dev] Towards 1.6 Final In-Reply-To: <200006130237.EAA10373@python.inrialpes.fr>; from Vladimir.Marangozov@inrialpes.fr on Tue, Jun 13, 2000 at 04:37:23AM +0200 References: <14661.19894.465676.770545@anthem.concentric.net> <200006130237.EAA10373@python.inrialpes.fr> Message-ID: <20000620084040.B3499@ludwig.cnri.reston.va.us> On 13 June 2000, Vladimir Marangozov said: > > - Fix ./ld_so_aix installation problem on AIX (anybody know more about > > this???) > > Yes, AMK, Greg Ward and I know more. It's more an automation (path) problem > for building C extensions with distutils than an installation problem per se. > Some time ago, I saw a workaround checked in by Greg. If this is still judged > as a problem, I'd like to hear about it. This is a minor thing. I have yet > to install & run the distutil package on AIX, though, and see what happens. As I recall, my workaround didn't work. (Would that make it a failaround?) Vladimir, *please* give the Distutils a whirl on AIX -- I suspect some sort of hack is needed to get extension-building working there. I don't much care if the Makefile installed by Python is "fixed" to have an absolute path to "ld_so_aix" instead of "./ld_so_aix" -- that should make extension-building with the Distutils OK, but it will break the relocatability of a Python installation on AIX. Also, it won't fix Distutils with Python 1.5.2. Thanks -- Greg From paul@prescod.net Tue Jun 20 14:30:13 2000 From: paul@prescod.net (Paul Prescod) Date: Tue, 20 Jun 2000 15:30:13 +0200 Subject: [Python-Dev] RFC: Including PIL in 1.6 References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us> Message-ID: <394F71E5.C7CEC32D@prescod.net> Greg Ward wrote: > > ... > -1 from me. What's the point of the Distutils if we just throw > everything "useful" into the standard distribution? One way to look at it is vertical versus horizontal. I think that that's how the Java world works (unofficially). If Java is one extreme and ANSI C is on the other, I prefer to err on the Java side (which we probably do). The big issue is configuration management. if we put PIL (or anything else) in the standard distribution we are promising to keep that code in sync with everything else. This is a big boon to users and a big headache for maintainers. The question is when the boon is enough to justify the headache. It's one thing to tell a user: "Just type distutils and everything will magically become available." But they usually come back: "I'm getting an error message about append not taking that many arguments..." or something like that. Libraries breaking libraries is actually the most common case. -- Paul Prescod - ISOGEN Consulting Engineer speaking for himself "Music is the stuff between the notes." - Claude Debussy From bwarsaw@python.org Tue Jun 20 14:43:32 2000 From: bwarsaw@python.org (Barry A. Warsaw) Date: Tue, 20 Jun 2000 09:43:32 -0400 (EDT) Subject: [Python-Dev] talking about performance... [case closed] References: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid> <20000618152020.B14713@newcnri.cnri.reston.va.us> <008301bfd96e$0bd98d20$f2a6b5d4@hagrid> <394D43B0.8CC7070@lemburg.com> <003101bfdaa0$693b4de0$0900a8c0@SPIFF> Message-ID: <14671.29956.819067.208771@anthem.concentric.net> >>>>> "FL" == Fredrik Lundh writes: FL> for the record, my little benchmark now runs about five FL> times faster than before -- which means that 16-bit find FL> is now ~30% faster than 8-bit find (barry? ;-) Awesome! From akuchlin@mems-exchange.org Tue Jun 20 14:53:09 2000 From: akuchlin@mems-exchange.org (Andrew M. Kuchling) Date: Tue, 20 Jun 2000 09:53:09 -0400 Subject: [Python-Dev] talking about performance... [case closed] In-Reply-To: <003101bfdaa0$693b4de0$0900a8c0@SPIFF>; from fredrik@pythonware.com on Tue, Jun 20, 2000 at 12:15:01PM +0200 References: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid> <20000618152020.B14713@newcnri.cnri.reston.va.us> <008301bfd96e$0bd98d20$f2a6b5d4@hagrid> <394D43B0.8CC7070@lemburg.com> <003101bfdaa0$693b4de0$0900a8c0@SPIFF> Message-ID: <20000620095309.A3039@amarok.cnri.reston.va.us> On Tue, Jun 20, 2000 at 12:15:01PM +0200, Fredrik Lundh wrote: >for the record, my little benchmark now runs about five >times faster than before -- which means that 16-bit find >is now ~30% faster than 8-bit find (barry? ;-) Speculation: the code in stringobject.c looks like this: for (; i <= last; ++i) if (s[i] == sub[0] && (n == 1 || memcmp(&s[i+1], &sub[1], n-1) == 0)) return (long)i; It checks the first character, and then does the memcmp() skipping the first character, or succeeds if the substring length is 1; the Unicode find is simpler, just doing the full memcmp. I wonder if the extra n == 1 and i+1, n-1 arithmetic costs more than it saves? This is probably delicately tied to the speed of your memcmp(). Anyone want to try the simpler version and report on whether it makes a difference? --amk From Fredrik Lundh" <20000618152020.B14713@newcnri.cnri.reston.va.us> <008301bfd96e$0bd98d20$f2a6b5d4@hagrid> <394D43B0.8CC7070@lemburg.com> <003101bfdaa0$693b4de0$0900a8c0@SPIFF> <20000620095309.A3039@amarok.cnri.reston.va.us> Message-ID: <007701bfdacc$0d2e87c0$f2a6b5d4@hagrid> This is a multi-part message in MIME format. ------=_NextPart_000_0071_01BFDADC.B3488D80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [as discussed on python-dev] amk wrote: > On Tue, Jun 20, 2000 at 12:15:01PM +0200, Fredrik Lundh wrote: > >for the record, my little benchmark now runs about five > >times faster than before -- which means that 16-bit find > >is now ~30% faster than 8-bit find (barry? ;-) >=20 > Speculation: the code in stringobject.c looks like this: > for (; i <=3D last; ++i) > if (s[i] =3D=3D sub[0] && > (n =3D=3D 1 || memcmp(&s[i+1], &sub[1], = n-1) =3D=3D 0)) > return (long)i; > =20 > It checks the first character, and then does the memcmp() skipping the > first character, or succeeds if the substring length is 1; the Unicode > find is simpler, just doing the full memcmp. I wonder if the extra n > =3D=3D 1 and i+1, n-1 arithmetic costs more than it saves? at least on my box (win95, msvc 5)... after simplifying the code, string.find is now faster than sre.search. it's still 15% slower than the 16-bit string find, but I don't have time to dig into that right now... patches are included. =20 I confirm that, to the best of my knowledge and belief, this contribution is free of any claims of third parties under copyright, patent or other rights or interests ("claims"). To the extent that I have any such claims, I hereby grant to CNRI a nonexclusive, irrevocable, royalty-free, worldwide license to reproduce, distribute, perform and/or display publicly, prepare derivative versions, and otherwise use this contribution as part of the Python software and its related documentation, or any derivative versions thereof, at no cost to CNRI or its licensed users, and to authorize others to do so. I acknowledge that CNRI may, at its sole discretion, decide whether or not to incorporate this contribution in the Python software and its related documentation. I further grant CNRI permission to use my name and other identifying information provided to CNRI by me for use in connection with the Python software and its related documentation. ------=_NextPart_000_0071_01BFDADC.B3488D80 Content-Type: text/plain; name="string-patch.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="string-patch.txt" Index: Objects/stringobject.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Objects/stringobject.c,v retrieving revision 2.68 diff -u -r2.68 stringobject.c --- Objects/stringobject.c 2000/06/14 09:18:09 2.68 +++ Objects/stringobject.c 2000/06/20 15:07:51 @@ -651,7 +651,7 @@ i = j = 0; while (i+n <= len) { - if (s[i] == sub[0] && (n == 1 || memcmp(s+i, sub, n) == 0)) { + if (s[i] == sub[0] && memcmp(s+i, sub, n) == 0) { if (maxsplit-- <= 0) break; item = PyString_FromStringAndSize(s+j, (int)(i-j)); @@ -852,8 +852,7 @@ return (long)i; last -= n; for (; i <= last; ++i) - if (s[i] == sub[0] && - (n == 1 || memcmp(&s[i+1], &sub[1], n-1) == 0)) + if (s[i] == sub[0] && memcmp(s+i, sub, n) == 0) return (long)i; } else { @@ -862,8 +861,7 @@ if (n == 0 && i <= last) return (long)last; for (j = last-n; j >= i; --j) - if (s[j] == sub[0] && - (n == 1 || memcmp(&s[j+1], &sub[1], n-1) == 0)) + if (s[j] == sub[0] && memcmp(s+j, sub, n) == 0) return (long)j; } @@ -1415,9 +1413,7 @@ len -= pat_len; for (ii = 0; ii <= len; ii++) { - if (mem[ii] == pat[0] && - (pat_len == 1 || - memcmp(&mem[ii+1], &pat[1], pat_len-1) == 0)) { + if (mem[ii] == pat[0] && memcmp(mem+ii, pat, pat_len) == 0) { return ii; } } ------=_NextPart_000_0071_01BFDADC.B3488D80-- From fdrake@beopen.com Tue Jun 20 16:47:35 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Tue, 20 Jun 2000 11:47:35 -0400 (EDT) Subject: [Python-Dev] faster 8-bit find/split (was: talking about performance...) In-Reply-To: <007701bfdacc$0d2e87c0$f2a6b5d4@hagrid> References: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid> <20000618152020.B14713@newcnri.cnri.reston.va.us> <008301bfd96e$0bd98d20$f2a6b5d4@hagrid> <394D43B0.8CC7070@lemburg.com> <003101bfdaa0$693b4de0$0900a8c0@SPIFF> <20000620095309.A3039@amarok.cnri.reston.va.us> <007701bfdacc$0d2e87c0$f2a6b5d4@hagrid> Message-ID: <14671.37399.809253.945519@cj42289-a.reston1.va.home.com> Fredrik Lundh writes: > patches are included. Now checked in, thanks! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one@email.msn.com Tue Jun 20 17:47:47 2000 From: tim_one@email.msn.com (Tim Peters) Date: Tue, 20 Jun 2000 12:47:47 -0400 Subject: [Python-Dev] talking about performance... [case closed] In-Reply-To: <20000620095309.A3039@amarok.cnri.reston.va.us> Message-ID: [Fredrik Lundh] > for the record, my little benchmark now runs about five > times faster than before -- which means that 16-bit find > is now ~30% faster than 8-bit find (barry? ;-) [Andrew M. Kuchling]/ > Speculation: the code in stringobject.c looks like this: > for (; i <= last; ++i) > if (s[i] == sub[0] && > (n == 1 || memcmp(&s[i+1], &sub[1], > n-1) == 0)) > return (long)i; > ... > the Unicode find is simpler, just doing the full memcmp. I wonder > if the extra n == 1 and i+1, n-1 arithmetic costs more than it > saves? So the intent of the code is to avoid the expense of calling memcmp if a full n-character memcmp can't possibly find equality at i (due to mismatch of first characters), and the assumption is that first characters mismatch frequently. Both seem like good calls to me! > This is probably delicately tied to the speed of your memcmp(). Also on whether your memcmp() is an actual external function or a full or partial inline expansion (e.g., the strcmp at KSR expanded into code much like the "by-hand" stuff above, skipping "the real" strcmp if the first characters weren't equal). > Anyone want to try the simpler version and report on whether > it makes a difference? No . But if someone does, a good compromise might be to split this into two loops, one for the n==1 case and another for n>1. The "+1/-1" are dubious in any case (i.e., "memcmp(s+i, sub, n) == 0" saves the fiddly arithmetic at the also-minor cost of making memcmp do one redundant character compare). From dan@cgsoftware.com Tue Jun 20 17:55:11 2000 From: dan@cgsoftware.com (Daniel Berlin) Date: Tue, 20 Jun 2000 09:55:11 -0700 (PDT) Subject: [Python-Dev] talking about performance... [case closed] In-Reply-To: Message-ID: > So the intent of the code is to avoid the expense of calling memcmp if a > full n-character memcmp can't possibly find equality at i (due to mismatch > of first characters), and the assumption is that first characters mismatch > frequently. Both seem like good calls to me! However, smart compilers (gcc 2.95+ fer instance) will produce an inline memcmp call that is faster, and has no overhead (IE it's not making a library call). Thus, the first character mismatch test is useless. We had the same thing in strcmp macros in GDB, where we tested the first character, then strcmp'd. It was faster to just strcmp, even when they *did* mismatch. --Dan From esr@thyrsus.com Tue Jun 20 18:21:50 2000 From: esr@thyrsus.com (esr@thyrsus.com) Date: Tue, 20 Jun 2000 13:21:50 -0400 Subject: [Python-Dev] list comprehensions In-Reply-To: References: <200006191501.KAA02197@cj20424-a.reston1.va.home.com> Message-ID: <20000620132150.O8678@thyrsus.com> Ka-Ping Yee : > On Mon, 19 Jun 2000, Guido van Rossum wrote: > > But submitting a patch might be a good idea anyway so we won't forget > > about it (and maybe it's of such baffling simplicity that it'll charm > > its way past the guards :-). > > I just have to say i thought list comprehensions were > really cool. Ditto. I would like to see this in 1.6. -- Eric S. Raymond The men and women who founded our country knew, by experience, that there are times when the free person's answer to oppressive government has to be delivered with a bullet. Thus, the right to bear arms is not just *a* freedom; it's the mother of all freedoms. Don't let them disarm you! From esr@thyrsus.com Tue Jun 20 19:04:19 2000 From: esr@thyrsus.com (esr@thyrsus.com) Date: Tue, 20 Jun 2000 14:04:19 -0400 Subject: [Python-Dev] RFC: Including PIL in 1.6 In-Reply-To: <20000620083344.A3499@ludwig.cnri.reston.va.us> References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us> Message-ID: <20000620140419.C10038@thyrsus.com> Greg Ward : > -1 from me. What's the point of the Distutils if we just throw > everything "useful" into the standard distribution? Watch that argument -- it could turn and bite you. What's the justification for including, e.g. POP client classes in the standard distribution? One of Python's most important strengths is the "batteries *are* included" richness of the standard environment. -- Eric S. Raymond The two pillars of `political correctness' are, a) willful ignorance, and b) a steadfast refusal to face the truth -- George MacDonald Fraser From Fredrik Lundh" <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us> Message-ID: <001101bfdae1$5094f7a0$f2a6b5d4@hagrid> greg wrote: > On 09 June 2000, Eric S. Raymond said: > > I think it's time to consider including PIL in the core Python 1.6 = release. > > I've been following the work being done over there, and I believe = the=20 > > code has reached a sufficient level of maturity to justify this. >=20 > -1 from me. What's the point of the Distutils if we just throw > everything "useful" into the standard distribution? strange argument. what's the point of including *anything* if we have distutils? ... fwiw, I'm -0 on this one; it might better to work on a "Python Standards Base" which specifies a bunch of extensions that people are encouraged to include in their distributions. let's see: zlib, expat, (portions of) numpy, pil, piddle, ... From Fredrik Lundh" Message-ID: <002001bfdae1$b28942e0$f2a6b5d4@hagrid> tim wrote: > No . But if someone does, a good compromise might be to split = this > into two loops, one for the n=3D=3D1 case and another for n>1. how about this one: if (dir > 0) { char *p, *e; if (n =3D=3D 0 && i <=3D last) return (long)i; e =3D s + last - n + 1; for (;;) { p =3D memchr(s, sub[0], e - s); if (p =3D=3D NULL) break; if (n =3D=3D 1 || memcmp(p, sub, n) =3D=3D 0) return (long) (p - s); s =3D p + 1; } } new record time: 1.6 seconds (down from 2.2) From akuchlin@mems-exchange.org Tue Jun 20 19:04:06 2000 From: akuchlin@mems-exchange.org (Andrew M. Kuchling) Date: Tue, 20 Jun 2000 14:04:06 -0400 Subject: [Python-Dev] RFC: Including PIL in 1.6 In-Reply-To: <20000620140419.C10038@thyrsus.com>; from esr@thyrsus.com on Tue, Jun 20, 2000 at 02:04:19PM -0400 References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us> <20000620140419.C10038@thyrsus.com> Message-ID: <20000620140406.B3142@amarok.cnri.reston.va.us> >Watch that argument -- it could turn and bite you. What's the justification >for including, e.g. POP client classes in the standard distribution? >One of Python's most important strengths is the "batteries *are* >included" richness of the standard environment. Once there are enough pieces to make finding and getting the software near-automatic, I actually wouldn't mind splitting them out and shipping a much smaller core distribution, perhaps with a script that downloads the latest versions of what's in the standard library. Debian did that for a while, with python-net, python-base, python-text, &c. I just compiled XEmacs 21.1.10 on a new Linux machine; you compile the binary, and install two packages of Elisp code (EFS and xemacs-base). Then you run xemacs, do Options > Manage Packages > List and Install, and you get a nice list containing GNUS, W3, programming language modes, etc. Pick the ones you want, it adds the ones needed by the ones you selected, and it fetches and installs them. Easy! Now imagine doing the same thing with Python modules. Of course, we'd have to design that feature first... (ESR & Paul Prescod vs. AMK & GPW: the First Pythonic War! :) ) -- A.M. Kuchling http://starship.python.net/crew/amk/ This is, after all, a book about reading, and the kind of reader I am addressing does not care primarily about being in fashion. -- Robertson Davies, _A Voice from the Attic_ From DavidA@ActiveState.com Tue Jun 20 19:16:40 2000 From: DavidA@ActiveState.com (David Ascher) Date: Tue, 20 Jun 2000 11:16:40 -0700 Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions... In-Reply-To: Message-ID: > Peter: > > > Davids wrapper function implements a FIFO strategy for termination. > > I think this is not desired. Normally you want LIFO, > > Agreed. LIFO is definately preferred IMO. Agreed. My wrapper was also from memory, and that was not at all the main point of my post =). --da From akuchlin@mems-exchange.org Tue Jun 20 19:17:47 2000 From: akuchlin@mems-exchange.org (Andrew M. Kuchling) Date: Tue, 20 Jun 2000 14:17:47 -0400 Subject: [Python-Dev] Re: [Patches] Adding sip to urlparse In-Reply-To: <002c01bfdae3$e4b71ba0$f2a6b5d4@hagrid>; from effbot@telia.com on Tue, Jun 20, 2000 at 08:18:03PM +0200 References: <14671.44450.197852.869640@rama.research.nokia.com> <14671.45733.968387.361146@cj42289-a.reston1.va.home.com> <002c01bfdae3$e4b71ba0$f2a6b5d4@hagrid> Message-ID: <20000620141747.D3142@amarok.cnri.reston.va.us> On Tue, Jun 20, 2000 at 08:18:03PM +0200, Fredrik Lundh quoted FLD: >> What is "sip"? Is it defined by an RFC (which?), or Internet Draft >> (which? what's the expected activity?). Is there a canonical list of all the defined URL types anywhere? I notice that 'ldap' isn't there, and maybe there are more missing. (Some of the ones in there are marginal: who cares about Prospero?) -- A.M. Kuchling http://starship.python.net/crew/amk/ That's so obvious that someone has already got a patent on it. -- Guido van Rossum, 12 Jan 1999 From DavidA@ActiveState.com Tue Jun 20 19:29:26 2000 From: DavidA@ActiveState.com (David Ascher) Date: Tue, 20 Jun 2000 11:29:26 -0700 Subject: [Python-Dev] Re: [Patches] Adding sip to urlparse In-Reply-To: <20000620141747.D3142@amarok.cnri.reston.va.us> Message-ID: > Is there a canonical list of all the defined URL types anywhere? I > notice that 'ldap' isn't there, and maybe there are more missing. > (Some of the ones in there are marginal: who cares about Prospero?) Mozilla defines a bunch, which I doubt are RFC anything. (chrome://, component://, etc.). --david From jeremy@beopen.com Tue Jun 20 19:33:59 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Tue, 20 Jun 2000 14:33:59 -0400 (EDT) Subject: [Python-Dev] RFC: Including PIL in 1.6 In-Reply-To: <20000620140406.B3142@amarok.cnri.reston.va.us> References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us> <20000620140419.C10038@thyrsus.com> <20000620140406.B3142@amarok.cnri.reston.va.us> Message-ID: <14671.47383.313007.531923@localhost.localdomain> >>>>> "AMK" == Andrew M Kuchling writes: AMK> I just compiled XEmacs 21.1.10 on a new Linux machine; you AMK> compile the binary, and install two packages of Elisp code (EFS AMK> and xemacs-base). Then you run xemacs, do Options > Manage AMK> Packages > List and Install, and you get a nice list containing AMK> GNUS, W3, programming language modes, etc. Pick the ones you AMK> want, it adds the ones needed by the ones you selected, and it AMK> fetches and installs them. Easy! Now imagine doing the same AMK> thing with Python modules. Of course, we'd have to design that AMK> feature first... I did the same install on my new Linux box last month. I was similarly pleased with the ease of installation. Let's get working on a design for this feature! Jeremy From Fredrik Lundh" <14671.45733.968387.361146@cj42289-a.reston1.va.home.com> <002c01bfdae3$e4b71ba0$f2a6b5d4@hagrid> <20000620141747.D3142@amarok.cnri.reston.va.us> Message-ID: <004c01bfdae6$9abbdec0$f2a6b5d4@hagrid> amk wrote: > Is there a canonical list of all the defined URL types anywhere? I > notice that 'ldap' isn't there, and maybe there are more missing. your local search bot to the rescue: http://www.isi.edu/in-notes/iana/assignments/url-schemes (see http://www.iana.org/numbers.htm for a full list of things they keep track of) From akuchlin@mems-exchange.org Tue Jun 20 19:44:40 2000 From: akuchlin@mems-exchange.org (Andrew M. Kuchling) Date: Tue, 20 Jun 2000 14:44:40 -0400 Subject: [Python-Dev] RFC: Including PIL in 1.6 In-Reply-To: <14671.47383.313007.531923@localhost.localdomain>; from jeremy@beopen.com on Tue, Jun 20, 2000 at 02:33:59PM -0400 References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us> <20000620140419.C10038@thyrsus.com> <20000620140406.B3142@amarok.cnri.reston.va.us> <14671.47383.313007.531923@localhost.localdomain> Message-ID: <20000620144440.E3142@amarok.cnri.reston.va.us> On Tue, Jun 20, 2000 at 02:33:59PM -0400, Jeremy Hylton wrote: >I did the same install on my new Linux box last month. I was >similarly pleased with the ease of installation. Let's get working on >a design for this feature! I have some notes on this, but they're at home. I'll post them tonight. --amk From paul@prescod.net Tue Jun 20 19:42:21 2000 From: paul@prescod.net (Paul Prescod) Date: Tue, 20 Jun 2000 13:42:21 -0500 Subject: [Python-Dev] RFC: Including PIL in 1.6 References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us> <20000620140419.C10038@thyrsus.com> <20000620140406.B3142@amarok.cnri.reston.va.us> Message-ID: <394FBB0D.96D88DBB@prescod.net> "Andrew M. Kuchling" wrote: > > ... > > I just compiled XEmacs 21.1.10 on a new Linux machine; you compile the > binary, and install two packages of Elisp code (EFS and xemacs-base). > Then you run xemacs, do Options > Manage Packages > List and Install, > and you get a nice list containing GNUS, W3, programming language > modes, etc. Pick the ones you want, it adds the ones needed by the > ones you selected, and it fetches and installs them. Easy! Now > imagine doing the same thing with Python modules. Of course, we'd > have to design that feature first... Let me repeat that I don't think that the main issue is whether it lives in this tarfile versus that tarfile. It's a) about agreeing to keep everything comptible. b) about being able to depend on the thing being there when you write a module. *In theory* Red Hat linux could be a kernel, a shell and the RPM engine. In practice, people like to be able to say: "if you have Red Hat version X then such and such will work because it comes with a functional package Y." Distutils is extremely important for vertical modules but if we start to use it as an excuse for leaving out core modules then I have to go with ESR and say: "where do we stop?" Unicode on demand? re on demand? pickle on demand? I think that the more relevant criteria are the ones we have always used: * how big is it * how easy is it to maintain * how integrated is it with everything else * how well-thought-out is it * and most important: how many people want it? I think that PIL is not yet a clear home run. -- Paul Prescod - ISOGEN Consulting Engineer speaking for himself "Music is the stuff between the notes." - Claude Debussy From guido@python.org Tue Jun 20 21:09:05 2000 From: guido@python.org (Guido van Rossum) Date: Tue, 20 Jun 2000 15:09:05 -0500 Subject: [Python-Dev] RFC: Including PIL in 1.6 In-Reply-To: Your message of "Tue, 20 Jun 2000 14:04:06 -0400." <20000620140406.B3142@amarok.cnri.reston.va.us> References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us> <20000620140419.C10038@thyrsus.com> <20000620140406.B3142@amarok.cnri.reston.va.us> Message-ID: <200006202009.PAA01064@cj20424-a.reston1.va.home.com> > I just compiled XEmacs 21.1.10 on a new Linux machine; you compile the > binary, and install two packages of Elisp code (EFS and xemacs-base). > Then you run xemacs, do Options > Manage Packages > List and Install, > and you get a nice list containing GNUS, W3, programming language > modes, etc. Pick the ones you want, it adds the ones needed by the > ones you selected, and it fetches and installs them. Easy! Now > imagine doing the same thing with Python modules. Of course, we'd > have to design that feature first... I just had to go through that process. It was actually rather painful, and I wouldn't have been able to succeed if it wasn't for XEmax grandmaster Barry Warsaw standing next to me holding my hand for a really long time... The autofetcher appeared broken at first, then had some unintuitive behavior next, before we finally got it running. Finally I got the hang of it, but after that I still had about a week where I occasionally used a familiar keystroke that triggered an error, and usually it took an email to Barry to find out which package contained the module defining the missing function. Not to say that I'm against this kind of thing, but warning that even in the best circumstances it can be a hurdle for newcomers... Which is why there's a market for packagers like Red Hat. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Tue Jun 20 21:12:09 2000 From: guido@python.org (Guido van Rossum) Date: Tue, 20 Jun 2000 15:12:09 -0500 Subject: [Python-Dev] Re: [Patches] Adding sip to urlparse In-Reply-To: Your message of "Tue, 20 Jun 2000 20:37:30 +0200." <004c01bfdae6$9abbdec0$f2a6b5d4@hagrid> References: <14671.44450.197852.869640@rama.research.nokia.com> <14671.45733.968387.361146@cj42289-a.reston1.va.home.com> <002c01bfdae3$e4b71ba0$f2a6b5d4@hagrid> <20000620141747.D3142@amarok.cnri.reston.va.us> <004c01bfdae6$9abbdec0$f2a6b5d4@hagrid> Message-ID: <200006202012.PAA01130@cj20424-a.reston1.va.home.com> > > Is there a canonical list of all the defined URL types anywhere? I > > notice that 'ldap' isn't there, and maybe there are more missing. > > your local search bot to the rescue: > http://www.isi.edu/in-notes/iana/assignments/url-schemes Of course now the trick is which ones are still relevant (as the doubt expressed about prospero exemplify). --Guido van Rossum (home page: http://www.python.org/~guido/) From fdrake@beopen.com Tue Jun 20 20:10:31 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Tue, 20 Jun 2000 15:10:31 -0400 (EDT) Subject: [Python-Dev] David Ascher's compile.py script? Message-ID: <14671.49575.161122.528241@cj42289-a.reston1.va.home.com> Does anyone have a copy of David Ascher's compile.py from his starship pages? The links there appear to be broken, and David appearantly hasn't been able to find time to look for a copy, or can't find it (I've sent him another mail about it in case it has turned up), and documentation users are asking about it. (There's a link from the extending & embedding manual.) If anyone has a copy, perhaps I could find provide a temporary location for it and revise the link in the online documentation to point there, as a stop-gap measure. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From nascheme@enme.ucalgary.ca Tue Jun 20 20:18:03 2000 From: nascheme@enme.ucalgary.ca (Neil Schemenauer) Date: Tue, 20 Jun 2000 13:18:03 -0600 Subject: [Python-Dev] David Ascher's compile.py script? In-Reply-To: <14671.49575.161122.528241@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Tue, Jun 20, 2000 at 03:10:31PM -0400 References: <14671.49575.161122.528241@cj42289-a.reston1.va.home.com> Message-ID: <20000620131803.A13811@acs.ucalgary.ca> On Tue, Jun 20, 2000 at 03:10:31PM -0400, Fred L. Drake, Jr. wrote: > Does anyone have a copy of David Ascher's compile.py from his > starship pages? I don't know how recent this copy is: http://www.enme.ucalgary.ca/~nascheme/python/compile.py Neil From fdrake@beopen.com Tue Jun 20 20:19:05 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Tue, 20 Jun 2000 15:19:05 -0400 (EDT) Subject: [Python-Dev] David Ascher's compile.py script? In-Reply-To: <20000620131803.A13811@acs.ucalgary.ca> References: <14671.49575.161122.528241@cj42289-a.reston1.va.home.com> <20000620131803.A13811@acs.ucalgary.ca> Message-ID: <14671.50089.860177.145255@cj42289-a.reston1.va.home.com> Neil Schemenauer writes: > I don't know how recent this copy is: > > http://www.enme.ucalgary.ca/~nascheme/python/compile.py Thanks! If nothing else shows up within the next day, I'll use this one. David, is this sufficiently recent? -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From skip@mojam.com (Skip Montanaro) Tue Jun 20 20:33:20 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Tue, 20 Jun 2000 14:33:20 -0500 (CDT) Subject: [Python-Dev] RFC: Including PIL in 1.6 In-Reply-To: <200006202009.PAA01064@cj20424-a.reston1.va.home.com> References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us> <20000620140419.C10038@thyrsus.com> <20000620140406.B3142@amarok.cnri.reston.va.us> <200006202009.PAA01064@cj20424-a.reston1.va.home.com> Message-ID: <14671.50944.796299.47756@beluga.mojam.com> Guido> I just had to go through that process. It was actually rather Guido> painful ... I will echo that sentiment. Actually, the first time I upgraded to the package stuff it went without a hitch. The next time it took me awhile to figure out why it didn't work. I imagine it's just teething pain that will get worked out as the XEmacs folks get more experience themselves, but auto-package install is definitely something that would have to be pretty bulletproof. I doubt the average Python user will have a similar level of computer savvy as the average XEmacs user. On top of that, how will you know that you want package X until you download it and try it out? I presume that carried to its logical conclusion, a package's documentation would be installed along with its source... chicken-and-egg-ly y'rs, -- Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On June 24th at 8AM, live your life for an hour as Ricky Byrdsong always lived his - run/walk in the Ricky Byrdsong Memorial 5K or just make a donation: https://www.SignmeupSports.com/Events/Index_Events.asp?EventID=1395 From paul@prescod.net Tue Jun 20 21:09:18 2000 From: paul@prescod.net (Paul Prescod) Date: Tue, 20 Jun 2000 15:09:18 -0500 Subject: [Python-Dev] Argh... Message-ID: <394FCF6E.85559D56@prescod.net> Okay, this is blatantly off-topic. I'm trying to increase the noise ratio so that people here will go back to comp.lang.python. All I need is for someone to email me in private email what's the Java equivalent of a=sys.argv[0] (it's almost over, it's almost over, it's almost over) Okay, here's an obPython: why doesn't the main module have an __file__ if it happens to be a file. I can understand why one piped in wouldn't but the interpreter knows when the main module is a file. -- Paul Prescod "Music is the stuff between the notes." - Claude Debussy From guido@python.org Tue Jun 20 22:31:00 2000 From: guido@python.org (Guido van Rossum) Date: Tue, 20 Jun 2000 16:31:00 -0500 Subject: [Python-Dev] Argh... In-Reply-To: Your message of "Tue, 20 Jun 2000 15:09:18 EST." <394FCF6E.85559D56@prescod.net> References: <394FCF6E.85559D56@prescod.net> Message-ID: <200006202131.QAA01631@cj20424-a.reston1.va.home.com> > Okay, here's an obPython: why doesn't the main module have an __file__ > if it happens to be a file. I can understand why one piped in wouldn't > but the interpreter knows when the main module is a file. Mostly because it's tough to pass that information around all the way to where it's needed. --Guido van Rossum (home page: http://www.python.org/~guido/) From mhammond@skippinet.com.au Wed Jun 21 00:06:57 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Wed, 21 Jun 2000 09:06:57 +1000 Subject: [Python-Dev] RFC: Including PIL in 1.6 In-Reply-To: <200006202009.PAA01064@cj20424-a.reston1.va.home.com> Message-ID: [Guido] > Not to say that I'm against this kind of thing, but warning that even > in the best circumstances it can be a hurdle for newcomers... > > Which is why there's a market for packagers like Red Hat. And even _then_ it is hard to get right. My experience similar to this was with debian, and its xptselect package. I was a Linux newbie, and the entire installation went pretty well until I was asked which packages I want to fetch and install. I was _soooo_ lost. I found the interface a complete mystery. It appeard to make random selections of stuff I didnt want, then randomly de-select stuff I didnt want. I had no idea how to search for anything, and the help was less than useful. Sometimes it wanted to download nothing, other times it wanted to download 400MB to complete the install!!! I only just resisted the temptation to go and buy a bunch of MS stock . Of course, within a week, I understood what was going on, and the sofware was indeed functioning correctly. But it took me that entire week to have a Linux system with everything I wanted installed and working correctly. The point I am trying to make is that for stuff that should be considered "core", the bar is very very high for these auto-configure applications. The usual audience will be _complete_ newbies. In my example, it was clear that a complete linux newbie was never let loose on this program while sitting in the same room as the author or the marketting team ;-) But I expect those with reasonable Linux experience quite like it, and themselves would not be happy with the complete-newbie version. The-included-batteries-were-the-wrong-size-ly, Mark. From Vladimir.Marangozov@inrialpes.fr Wed Jun 21 00:34:31 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Wed, 21 Jun 2000 01:34:31 +0200 (CEST) Subject: [Python-Dev] Fw: Access violation when no memory In-Reply-To: from "Mark Hammond" at Jun 20, 2000 09:42:53 PM Message-ID: <200006202334.BAA03150@python.inrialpes.fr> Mark Hammond wrote: > > >From the newsgroup. Any thoughts? > > Mark. > > "Phil Mayes" wrote in message > news:... > > The following program progressively allocates all memory: > > size = 1 << 20 > > list = [None,] > > while size: > > try: > > mem = [None] * size > > mem[0] = list > > list = mem > > except: > > size = size / 2 > > > > It fails with an access violation. The only immediate thought I have is that Python does not have builtin emergency procedures for such extreme situations. Although there are some safety checks, it is fairly easy to crash the interpreter in a number of ways. For example, with the introduction of the mmapmodule, there are even more "risks", like managing to mmap the python executable and screw it up completely (not speaking of the possibility to introduce Trojan horses and similar if this is done on purpose). There would probably be more checks, but complete safety is hard to achieve in the current state. The proposed solution is not a solution. The example program dumps core in different locations on my machine. We just do not have enough control from Python for managing such extreme cases. Sad, but true... -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From akuchlin@mems-exchange.org Wed Jun 21 02:46:43 2000 From: akuchlin@mems-exchange.org (A.M. Kuchling) Date: Tue, 20 Jun 2000 21:46:43 -0400 Subject: [Python-Dev] Installation requirements Message-ID: <200006210146.VAA01220@207-172-37-166.s166.tnt7.ann.va.dialup.rcn.com> [Follow-up to the Distutils SIG, please.] There are a few steps needed to find and install a package: 1) Discovery : which module does what I need? 2) Download : where can I get a copy? 3) Security : is this actually from the package author, and not a Trojan? 4) Installation : how do I set it up? 5) Checking for new versions: I have 1.0 installed; is a newer version available? Distutils focuses on the hardest and most complicated step, #4. For #1, you would need to browse through a list of available packages, browse through a hierarchy like Parnassus, or do keyword searches. #2 is pretty simple, since you just get one or more download URLs corresponding to a given package name, using the same database as in #1. For #3, you'd have to check a signature on the downloaded package, using something external like GnuPG. This means this step has to be skipped if the external tool isn't available. We could implement our own signature scheme with Python code, but that's a bad idea; security is hard, and few people will bother to generate keys that are only useful for this one application of distributing Python modules. (Side note: the sdist and bdist_* commands should have a --sign switch to sign the generated .tgz, .rpm, or whatever file.) For #5, the existing stuff in Tools/versioncheck might be partially applicable, though it requires that every package have a text file somewhere which gives the latest version. You'd want to use the same database for everything, to ensure that people actually use it! To start off with, we'd need some sort of generic API to the above functions, so that different interfaces can be written. A command-line interface would then be easiest. I don't know how network communications should be handled: HTTP to CGI scripts that return sets of RFC-822 headers, maybe? Combined with a DNS alias like modules.python.org, or modules.{us,uk,...}.python.org? Some potential sources of inspiration: Debian: apt Perl: CPAM.pm FreeBSD: ports system RPMfind (rpmfind.net) XEmacs: packages system -- A.M. Kuchling http://starship.python.net/crew/amk/ "Jo, it's a pity escapology wasn't part of your curriculum." "Funny you should say that. Look." -- The Doctor and Jo, tied up, in "Terror of the Autons" From tim_one@email.msn.com Wed Jun 21 04:44:18 2000 From: tim_one@email.msn.com (Tim Peters) Date: Tue, 20 Jun 2000 23:44:18 -0400 Subject: [Python-Dev] talking about performance... In-Reply-To: <002001bfdae1$b28942e0$f2a6b5d4@hagrid> Message-ID: [posted & mailed] [Fredrik Lundh] > how about this one: > > if (dir > 0) { > char *p, *e; > if (n == 0 && i <= last) > return (long)i; > e = s + last - n + 1; > for (;;) { > p = memchr(s, sub[0], e - s); > if (p == NULL) > break; > if (n == 1 || memcmp(p, sub, n) == 0) > return (long) (p - s); > s = p + 1; > } > } > > new record time: 1.6 seconds (down from 2.2) I expect that whether this is faster or slower depends on both the compiler you're using and the exact strings you're using to time it. In any case, it appears to be incorrect: p & s both change inside the infinite loop, and the innermost return computes their difference. Surely it should be returning the difference between p and the value s had *before* the loop was entered. If this passed your tests, then, it suggests you had no "false hits" (i.e., that the inner loop returned on its first iteration, else the return value would have been wrong), which are probably the cases in which using memchr rather than the current code is least likely to slow things down. It's bad that the original code never bothered to document what it's supposed to return, but that's no excuse to return probabilistically-correct gibberish . From tim_one@email.msn.com Wed Jun 21 04:44:25 2000 From: tim_one@email.msn.com (Tim Peters) Date: Tue, 20 Jun 2000 23:44:25 -0400 Subject: [Python-Dev] list comprehensions In-Reply-To: <20000620132150.O8678@thyrsus.com> Message-ID: [Ka-Ping Yee] > I just have to say i thought list comprehensions were > really cool. [Eric S. Raymond] > Ditto. I would like to see this in 1.6. Nobody has been more vocal in support of these (& augmented assignments) than me, but I very strongly doubt they'll be in 1.6. In the interests of getting that out the door, Guido considers the 1.6 feature set to be frozen already. I think part of the pressure to get one more feature in Python (again & again & again) is that release cycles have been soooooo protracted, now slobbering well over the full year mark. If I accomplish nothing else at BeOpen, I want to give that a major speed boost -- I don't think we should ever let 6 months go by without at least pumping out a bugfix release. there-are-other-things-guido-doesn't-yet-know-he-believes-too-ly y'rs - tim From skip@mojam.com (Skip Montanaro) Wed Jun 21 05:33:12 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Tue, 20 Jun 2000 23:33:12 -0500 (CDT) Subject: [Python-Dev] feeble attempt at list comprehensions doc... Message-ID: <14672.17800.994102.266619@beluga.mojam.com> --R/cQMyfgKa Content-Type: text/plain; charset=us-ascii Content-Description: message body and .signature Content-Transfer-Encoding: 7bit Attached to this message are two patches, one for Doc/ref/ref5.tex and one for Doc/tut/tut.tex. They provide minimal documentation for list comprehensions. I'm sure just about anyone else could do better. Feel free to embellish. The BNF used in the reference manual doesn't seem to match the BNF in the Grammar file very well, so I'm not even certain I have the correct BNF or have it in the correct place. In particular, I'm pretty sure the BNF for list_for and list_if are incorrect. -- Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On June 24th at 8AM, live your life for an hour as Ricky Byrdsong always lived his - run/walk in the Ricky Byrdsong Memorial 5K or just make a donation: https://www.SignmeupSports.com/Events/Index_Events.asp?EventID=1395 --R/cQMyfgKa Content-Type: application/octet-stream Content-Description: list comprehension diffs Content-Disposition: attachment; filename="tut.diff" Content-Transfer-Encoding: base64 KioqIC90bXAvdHV0LnRleC5+MS4xMDd+CVR1ZSBKdW4gMjAgMjM6MjY6MzggMjAwMAotLS0g L3RtcC90dXQudGV4CVR1ZSBKdW4gMjAgMjM6MjY6MzggMjAwMAoqKioqKioqKioqKioqKioK KioqIDE3NTIsMTc1NyAqKioqCi0tLSAxNzUyLDE3NzggLS0tLQogIDAKICBcZW5ke3ZlcmJh dGltfQogIAorIFxzdWJzZWN0aW9ue0xpc3QgQ29tcHJlaGVuc2lvbnN9CisgCisgTGlzdCBj b21wcmVoZW5zaW9ucyBwcm92aWRlIGEgY29uY2lzZSB3YXkgdG8gY3JlYXRlIGxpc3RzIHdp dGhvdXQgcmVzb3J0aW5nCisgdG8gdXNlIG9mIHRoZSBcZnVuY3ttYXAoKX0gb3IgXGZ1bmN7 ZmlsdGVyKCl9IGZ1bmN0aW9ucy4gIFRoZSByZXN1bHRpbmcKKyBjb25zdHJ1Y3QgdGVuZHMg b2Z0ZW4gdG8gYmUgY2xlYXJlciB0aGFuIHVzZSBvZiB0aG9zZSBmdW5jdGlvbnMuCisgCisg XGJlZ2lue3ZlcmJhdGltfQorID4+PiBzcGNzID0gWyIgIEFwcGxlIiwgIiBCYW5hbmEgIiwg IkNvY28gIG51dCAgIl0KKyA+Pj4gcHJpbnQgW3Muc3RyaXAoKSBmb3IgcyBpbiBzcGNzXQor IFsnQXBwbGUnLCAnQmFuYW5hJywgJ0NvY28gIG51dCddCisgPj4+IHZlYyA9IFsyLCA0LCA2 XQorID4+PiBwcmludCBbMyp4IGZvciB4IGluIHZlY10KKyBbNiwgMTIsIDE4XQorID4+PiB2 ZWMxID0gWzIsIDQsIDZdCisgPj4+IHZlYzIgPSBbNCwgMywgLTldCisgPj4+IHByaW50IFt4 KnkgZm9yIHggaW4gdmVjMSBmb3IgeSBpbiB2ZWMyXQorIFs4LCA2LCAtMTgsIDE2LCAxMiwg LTM2LCAyNCwgMTgsIC01NF0KKyA+Pj4gcHJpbnQgW3greSBmb3IgeCBpbiB2ZWMxIGZvciB5 IGluIHZlYzJdCisgWzYsIDUsIC03LCA4LCA3LCAtNSwgMTAsIDksIC0zXQorIFxlbmR7dmVy YmF0aW19CisgCiAgXHNlY3Rpb257VGhlIFxrZXl3b3Jke2RlbH0gc3RhdGVtZW50IFxsYWJl bHtkZWx9fQogIAogIFRoZXJlIGlzIGEgd2F5IHRvIHJlbW92ZSBhbiBpdGVtIGZyb20gYSBs aXN0IGdpdmVuIGl0cyBpbmRleCBpbnN0ZWFkCg== --R/cQMyfgKa Content-Type: application/octet-stream Content-Description: reference manual diff Content-Disposition: attachment; filename="ref5.diff" Content-Transfer-Encoding: base64 KioqIC90bXAvcmVmNS50ZXgufjEuMjl+CVR1ZSBKdW4gMjAgMjM6Mjc6MTQgMjAwMAotLS0g L3RtcC9yZWY1LnRleAlUdWUgSnVuIDIwIDIzOjI3OjE0IDIwMDAKKioqKioqKioqKioqKioq CioqKiAxNTIsMTY0ICoqKioKICBzcXVhcmUgYnJhY2tldHM6CiAgCiAgXGJlZ2lue3ZlcmJh dGltfQohIGxpc3RfZGlzcGxheTogICAiWyIgW2V4cHJlc3Npb25fbGlzdF0gIl0iCiAgXGVu ZHt2ZXJiYXRpbX0KICAKICBBIGxpc3QgZGlzcGxheSB5aWVsZHMgYSBuZXcgbGlzdCBvYmpl Y3QuICBJZiBpdCBoYXMgbm8gZXhwcmVzc2lvbgogIGxpc3QsIHRoZSBsaXN0IG9iamVjdCBo YXMgbm8gaXRlbXMuICBPdGhlcndpc2UsIHRoZSBlbGVtZW50cyBvZiB0aGUKICBleHByZXNz aW9uIGxpc3QgYXJlIGV2YWx1YXRlZCBmcm9tIGxlZnQgdG8gcmlnaHQgYW5kIGluc2VydGVk IGluIHRoZQohIGxpc3Qgb2JqZWN0IGluIHRoYXQgb3JkZXIuCiAgXG9iaW5kZXh7bGlzdH0K ICBcaW5kZXhpaXtlbXB0eX17bGlzdH0KICAKLS0tIDE1MiwxNjkgLS0tLQogIHNxdWFyZSBi cmFja2V0czoKICAKICBcYmVnaW57dmVyYmF0aW19CiEgbGlzdF9kaXNwbGF5OiAgICJbIiBb ZXhwcmVzc2lvbl9saXN0IFtsaXN0X2l0ZXJdXSAiXSIKISBsaXN0X2l0ZXI6ICAgbGlzdF9m b3IgfCBsaXN0X2lmCiEgbGlzdF9mb3I6ICAgICJmb3IiIGV4cHJlc3Npb25fbGlzdCAiaW4i IHRlc3RsaXN0IFtsaXN0X2l0ZXJdCiEgbGlzdF9pZjogICAgICJpZiIgdGVzdCBbbGlzdF9p dGVyXQogIFxlbmR7dmVyYmF0aW19CiAgCiAgQSBsaXN0IGRpc3BsYXkgeWllbGRzIGEgbmV3 IGxpc3Qgb2JqZWN0LiAgSWYgaXQgaGFzIG5vIGV4cHJlc3Npb24KICBsaXN0LCB0aGUgbGlz dCBvYmplY3QgaGFzIG5vIGl0ZW1zLiAgT3RoZXJ3aXNlLCB0aGUgZWxlbWVudHMgb2YgdGhl CiAgZXhwcmVzc2lvbiBsaXN0IGFyZSBldmFsdWF0ZWQgZnJvbSBsZWZ0IHRvIHJpZ2h0IGFu ZCBpbnNlcnRlZCBpbiB0aGUKISBsaXN0IG9iamVjdCBpbiB0aGF0IG9yZGVyLiBMaXN0IGNv bXByZWhlbnNpb25zIGRlZmluZSBjb25kaXRpb25hbAohIGV4cHJlc3Npb25zIHVzZWQgdG8g ZGVmaW5lIGxpc3RzLgohIAogIFxvYmluZGV4e2xpc3R9CiAgXGluZGV4aWl7ZW1wdHl9e2xp c3R9CiAgCg== --R/cQMyfgKa-- From tim_one@email.msn.com Wed Jun 21 05:53:59 2000 From: tim_one@email.msn.com (Tim Peters) Date: Wed, 21 Jun 2000 00:53:59 -0400 Subject: [Python-Dev] Warnings in mmapmodule Message-ID: I get these warnings in Modules/mmapmodule.c, all about signed/unsigned mismatches: Modules\mmapmodule.c(571) : warning C4018: '>=' : signed/unsigned mismatch if (i < 0 || i >= self->size) { Modules\mmapmodule.c(586) : warning C4018: '>' : signed/unsigned mismatch else if (ilow > self->size) Modules\mmapmodule.c(592) : warning C4018: '>' : signed/unsigned mismatch else if (ihigh > self->size) Modules\mmapmodule.c(631) : warning C4018: '>' : signed/unsigned mismatch else if (ilow > self->size) Modules\mmapmodule.c(637) : warning C4018: '>' : signed/unsigned mismatch else if (ihigh > self->size) Modules\mmapmodule.c(664) : warning C4018: '>=' : signed/unsigned mismatch if (i < 0 || i >= self->size) { I'll volunteer to fix these if nobody else does (although at the moment I'm not able to produce either a patch or check in). new-laptops-in-hotel-rooms-have-their-limitations-ly y'rs - tim From mhammond@skippinet.com.au Wed Jun 21 05:57:54 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Wed, 21 Jun 2000 14:57:54 +1000 Subject: [Python-Dev] Warnings in mmapmodule In-Reply-To: Message-ID: > I get these warnings in Modules/mmapmodule.c, all about signed/unsigned > mismatches: Me too :-) > I'll volunteer to fix these if nobody else does (although at the > moment I'm > not able to produce either a patch or check in). I nearly did, but then couldnt find the time to chase up how Unix declared the relevant items - I didnt want to assume they were identical to Windows. My intention was to make the patch, then test it out on my gleaming Linux box. But-the-road-to-hell-is-paved-with-good-intentions-ly, Mark. From tim_one@email.msn.com Wed Jun 21 06:22:37 2000 From: tim_one@email.msn.com (Tim Peters) Date: Wed, 21 Jun 2000 01:22:37 -0400 Subject: [Python-Dev] Warnings in mmapmodule In-Reply-To: Message-ID: [posted & mailed] [Tim] > I get these warnings in Modules/mmapmodule.c, all about signed/unsigned > mismatches: [Mark Hammond] > Me too :-) > > I nearly [fixed them], but then couldnt find the time to chase up how > Unix declared the relevant items - I didnt want to assume they were > identical to Windows. They all involve mixing ints with mmap_object.size in comparisons, which latter is declared size_t and so will resolve to *some* unsigned integral type on all platforms. The proper fix is to get rid of the ints before making these tests -- ask Trent, he should be able to do this in his sleep now . > My intention was to make the patch, then test it out on my gleaming Linux > box. > > But-the-road-to-hell-is-paved-with-good-intentions-ly, No, it's paved with Linux: I've been using Windows so long I forgot why Unix is supposed to be more usable <0.9 wink>. Mark, if you've figured out how to do a SourceForge checkin from a Windows box, drop me a line offline! It would save me from figuring out which one of the 10,000 SSH+Windows search hits actually leads to something that works (and, no, so long as my entire life is sitting on my laptop, I'm not getting another OS anywhere near this box). becoming-a-linux-true-believer-again-is-on-my-schedule-but-not- for-a-couple-months-ly y'rs - tim From DavidA@ActiveState.com Wed Jun 21 06:40:36 2000 From: DavidA@ActiveState.com (David Ascher) Date: Tue, 20 Jun 2000 22:40:36 -0700 Subject: [Python-Dev] Warnings in mmapmodule In-Reply-To: Message-ID: > No, it's paved with Linux: I've been using Windows so long I forgot why > Unix is supposed to be more usable <0.9 wink>. Mark, if you've > figured out > how to do a SourceForge checkin from a Windows box, drop me a > line offline! No, please, drop us all a line online! I've decided that I'm not going to waste any more of my time dealing w/ SourceForge. Luckily I seem to have found some helpers for the PyOpenGL transition who are willing to deal with that! --david From mhammond@skippinet.com.au Wed Jun 21 06:49:45 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Wed, 21 Jun 2000 15:49:45 +1000 Subject: [Python-Dev] CVS and SSH under windows. In-Reply-To: Message-ID: [David] > No, please, drop us all a line online! OK - here it is, for what it is worth. You will notice that I spent the time to research my facts carefully before giving out this information (NOT!) Sure. It is a bit of a PITA (surprise, surprise, surprise): First, get the latest WinCVS. Has some nice new features. Mine shows as 1.1b13. It has a slightly “slicker” more windowsy look than the older one. What we really want is the version with the Options/Preferences dialog that allows you to supply the “RAS identity” file when you select “SSH Server” as the auth method. Previous versions allow you to select the SSH Server, but give you nowhere to put the identity file. Hence previous versions used a batch file wrapper, which you probably saw reference to. This version makes it much simpler. I use the standard SSH Version 1.2.14 binary set. I cant recall the URL, but it is quite small and only a few binary files. “ssh” shows usage - “ssh -v” shows versbose usage, “verbose” in this context apparently means showing the version number (took me ages to work that one out :-) There were only a few files, so I just dumped them all in the same directory as the CVS binaries. You then need to make a “key” file - I cant recall the exact process, but it is pretty simple. This is creating the identify file you specify to WinCVS, as well as the public key you upload to source-force. NOTE - from memory, you MUST have a HOME env var set, and you MUST have a “.ssh” directory under your home. Otherwise you get cryptic errors from SSH that give no clue that this is the problem. After uploading the public key to source forge, you are nearly set. The last step is convinving CVS that you want to use this new SSH setting, and not the setting CVS so kindly persists in its “CVS\Root” files. The only way I found to do this was to either edit the Root files manually, or remove the directories locally and force CVS to re-create them (and thereby re-pull everything - I assume you have ADSL in that hotel room :-) Alternatively, dig up that CVS script posted to py-dev recently and change it - personally, I never trusted it :-) All my root files look like: :ext:mhammond@cvs.python.sourceforge.net:/cvsroot/python Yours almost certainly will be setup for anon access, not using ssh. Hope that makes sense. Im happy to chase anything else up I can for you... Mark. From Fredrik Lundh" Message-ID: <006401bfdb56$6f84ae60$f2a6b5d4@hagrid> tim wrote: > > p =3D memchr(s, sub[0], e - s); > > if (p =3D=3D NULL) > > break; > > if (n =3D=3D 1 || memcmp(p, sub, n) =3D=3D 0) > > return (long) (p - s); > I expect that whether this is faster or slower depends on both the = compiler > you're using and the exact strings you're using to time it. With test strings that contain false matches for every single position, it's 30% slower than the old code in my tests. With test strings that contain no false matches, it's 50% faster. But without more extensive tests on a variety of platforms, we might as well forget about this one... From mal@lemburg.com Wed Jun 21 09:23:02 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 21 Jun 2000 10:23:02 +0200 Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions... References: Message-ID: <39507B66.763DB418@lemburg.com> [Skip's exit.py module + David's extension to support already registered exitfunc'tions] Looks like everyone agrees -- with a final word from Guido we'd only need some docs to go with it and then check Skip's module in as new standard module. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From skip@mojam.com (Skip Montanaro) Wed Jun 21 14:38:01 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Wed, 21 Jun 2000 08:38:01 -0500 (CDT) Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions... In-Reply-To: <39507B66.763DB418@lemburg.com> References: <39507B66.763DB418@lemburg.com> Message-ID: <14672.50489.611301.616242@beluga.mojam.com> MA> Looks like everyone agrees -- with a final word from Guido we'd only MA> need some docs to go with it and then check Skip's module in as new MA> standard module. I'll try to get David's enhancement added to my code and write some simple documentation today. Is "exit.py" acceptable with everyone as the name of the module? Skip From skip@mojam.com (Skip Montanaro) Wed Jun 21 19:15:19 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Wed, 21 Jun 2000 13:15:19 -0500 (CDT) Subject: [Python-Dev] updated exit.py and supporting files for your perusal Message-ID: <14673.1591.506532.170015@beluga.mojam.com> --tqfUNARIjv Content-Type: text/plain; charset=us-ascii Content-Description: message body and .signature Content-Transfer-Encoding: 7bit This message contains four attached files: Lib/exit.py - a module that allows users to register cleanup functions Lib/test/test_exit.py - a simple test script Lib/test/output/test_exit - expected test output Doc/lib/libexit.tex - library reference manual section Besides adding documentation and a test script, the following two mods were made to exit.py since I previously posted it: 1. It implements a LIFO execution order 2. If sys.exitfunc is already defined and not exit._run_exitfuncs, it is treated as an exit function and appended to the exit function list. Comments, please. Also, can someone tell me how to coax CVS into creating a unified diff that actually contains new files? I tried cvs diff -RNau without success. Thanks, -- Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On June 24th at 8AM, live your life for an hour as Ricky Byrdsong always lived his - run/walk in the Ricky Byrdsong Memorial 5K or just make a donation: https://www.SignmeupSports.com/Events/Index_Events.asp?EventID=1395 --tqfUNARIjv Content-Type: text/plain Content-Description: Lib/exit.py Content-Disposition: inline; filename="exit.py" Content-Transfer-Encoding: 7bit """ exit.py - allow programmer to define multiple exit functions to be executed upon normal program termination. One public function, register_exitfunc, is defined. """ _exithandlers = [] def _run_exitfuncs(): """run any registered exit functions _exithandlers is traversed in reverse order so functions are executed last in, first out. """ while _exithandlers: func, targs, kargs = _exithandlers[-1] apply(func, targs, kargs) _exithandlers.remove(_exithandlers[-1]) def register_exitfunc(func, *targs, **kargs): """register a function to be executed upon normal program termination func - function to be called at exit targs - optional arguments to pass to func kargs - optional keyword arguments to pass to func """ _exithandlers.append((func, targs, kargs)) import sys try: x = sys.exitfunc except AttributeError: sys.exitfunc = _run_exitfuncs else: # if x isn't our own exit func executive, assume it's another # registered exit function - append it to our list... if x != _run_exitfuncs: register_exitfunc(x) del sys if __name__ == "__main__": def x1(): print "running x1" def x2(n): print "running x2(%s)" % `n` def x3(n, kwd=None): print "running x3(%s, kwd=%s)" % (`n`, `kwd`) register_exitfunc(x1) register_exitfunc(x2, 12) register_exitfunc(x3, 5, "bar") register_exitfunc(x3, "no kwd args") --tqfUNARIjv Content-Type: text/plain Content-Description: Lib/test/test_exit.py Content-Disposition: inline; filename="test_exit.py" Content-Transfer-Encoding: 7bit # Test the exit module from test_support import verbose import exit def handler1(): print "handler1" def handler2(*args, **kargs): print "handler2", args, kargs # save any exit functions that may have been registered as part of the # test framework _exithandlers = exit._exithandlers exit._exithandlers = [] exit.register_exitfunc(handler1) exit.register_exitfunc(handler2) exit.register_exitfunc(handler2, 7, kw="abc") # simulate exit behavior by calling exit._run_exitfuncs directly... exit._run_exitfuncs() # restore exit handlers exit._exithandlers = _exithandlers --tqfUNARIjv Content-Type: text/plain Content-Description: Lib/test/output/test_exit Content-Disposition: inline; filename="test_exit" Content-Transfer-Encoding: 7bit test_exit handler2 (7,) {'kw': 'abc'} handler2 () {} handler1 --tqfUNARIjv Content-Type: text/plain Content-Description: Doc/lib/libexit.tex Content-Disposition: inline; filename="libexit.tex" Content-Transfer-Encoding: 7bit \section{\module{exit} --- exit handlers} \declaremodule{standard}{exit} \sectionauthor{Skip Montanaro}{skip@mojam.com} \modulesynopsis{Register and execute cleanup functions.} The \module{exit} module defines a single function to register cleanup functions. Functions thus registered are automatically executed upon normal interpreter termination. \begin{funcdesc}{register_exitfunc}{func\optional{, *args\optional{, **kargs}}} Register \code{func} as a function to be executed at termination. Any optional arguments that are to be passed to func must be passed as arguments to \func{register_exitfunc}. At normal program termination (for instance, if \func{sys.exit} is called or the main module's execution completes), all functions registered are called in last in, first out order. The assumption is that lower level modules will normally be imported before higher level modules and thus must be cleaned up later. \subsection{Example} The following simple example demonstrates how a module can initialize a counter from a file when it is imported and save the counter's updated value automatically when the program terminates. \begin{verbatim} try: _count = eval(open("/tmp/counter").read()) except IOError: _count = 0 def incrcounter(n): global _count _count = _count + n def savecounter(): open("/tmp/counter", "w").write("%d" % _count) import exit exit.register_exitfunc(savecounter) \end{verbatim} --tqfUNARIjv-- From trentm@activestate.com Wed Jun 21 20:20:12 2000 From: trentm@activestate.com (Trent Mick) Date: Wed, 21 Jun 2000 12:20:12 -0700 Subject: [Python-Dev] Warnings in mmapmodule In-Reply-To: References: Message-ID: <20000621122012.A28236@activestate.com> On Wed, Jun 21, 2000 at 01:22:37AM -0400, Tim Peters wrote: > [posted & mailed] > > [Tim] > > I get these warnings in Modules/mmapmodule.c, all about signed/unsigned > > mismatches: > > [Mark Hammond] > > Me too :-) > > > > I nearly [fixed them], but then couldnt find the time to chase up how > > Unix declared the relevant items - I didnt want to assume they were > > identical to Windows. > > They all involve mixing ints with mmap_object.size in comparisons, which > latter is declared size_t and so will resolve to *some* unsigned integral > type on all platforms. The proper fix is to get rid of the ints before > making these tests -- ask Trent, he should be able to do this in his sleep > now . > I wish I could do it in my sleep, then I would be much more well rested. Yes I will clean these up. I was going to look at mmap a little anyway as test_mmap currently fails on Win32 (probably as a resul of my mmpa patch). Trent -- Trent Mick trentm@activestate.com From DavidA@ActiveState.com Wed Jun 21 18:25:07 2000 From: DavidA@ActiveState.com (David Ascher) Date: Wed, 21 Jun 2000 10:25:07 -0700 Subject: [Python-Dev] CVS and SSH under windows. In-Reply-To: Message-ID: > First, get the latest WinCVS. http://www.wincvs.org/download.html > I use the standard SSH Version 1.2.14 binary set. I cant recall the URL, There's a version at: ftp://ftp.cs.hut.fi/pub/ssh/contrib/ssh-1.2.14-win32bin.zip BUT... > You then need to make a “key” file - I cant recall the exact process, but > it is pretty simple. This is creating the identify file you specify to > WinCVS, as well as the public key you upload to source-force. C:\WinCVS>ssh-keygen I always get a 'gethostname: no such file or directory' so I had to create the key on Linux (as is mentioned in the page http://bmrc.berkeley.edu/people/chaffee/winntutil.html). Maybe you have a better binary for ssh? > NOTE - from memory, you MUST have a HOME env var set, and you MUST have a > “.ssh” directory under your home. Otherwise you get cryptic errors from > SSH that give no clue that this is the problem. > > After uploading the public key to source forge, you are nearly set. How do you do that? > The > last step is convinving CVS that you want to use this new SSH setting, and > not the setting CVS so kindly persists in its “CVS\Root” files. The only > way I found to do this was to either edit the Root files manually, or > remove the directories locally and force CVS to re-create them > (and thereby > re-pull everything - I assume you have ADSL in that hotel room :-) > Alternatively, dig up that CVS script posted to py-dev recently and change > it - personally, I never trusted it :-) > > All my root files look like: > :ext:mhammond@cvs.python.sourceforge.net:/cvsroot/python > > Yours almost certainly will be setup for anon access, not using ssh. > > Hope that makes sense. Im happy to chase anything else up I can > for you... > > Mark. > > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://www.python.org/mailman/listinfo/python-dev > From akuchlin@mems-exchange.org Wed Jun 21 21:27:31 2000 From: akuchlin@mems-exchange.org (Andrew M. Kuchling) Date: Wed, 21 Jun 2000 16:27:31 -0400 Subject: [Python-Dev] Patch management (was: Warnings in pythonrun.c) In-Reply-To: <14673.158.183876.75480@localhost.localdomain>; from jeremy@beopen.com on Wed, Jun 21, 2000 at 01:51:26PM -0400 References: <008c01bfdb58$103e8140$f2a6b5d4@hagrid> <14673.158.183876.75480@localhost.localdomain> Message-ID: <20000621162731.B3918@amarok.cnri.reston.va.us> On Wed, Jun 21, 2000 at 01:51:26PM -0400, Jeremy Hylton wrote: >>>>>> "TP" == Tim Peters writes: > TP> + This mailing list doesn't work. At least the SourceForge >I agree that it's a complete mess, though. While you're all admiring the difficulty of the problem, how about actually checking in the pythonrun.c patch, assuming it's reasonable? Frankly, I don't think the current mailing list is broken, *as long as patches are handled with reasonable speed* so that the backlog doesn't build up. That hasn't been done, and I don't understand why. Obviously the CNRI->BeOpen transaction resulted in some downtime for everyone, but now it's a month later and there's still stagnation. Why aren't incoming patches being handled now? It's not like there are very many patches per day; an hour or two should suffice to keep the queue from growing. At this point, the best fix is to do two things: 1) Someone downloads the mbox archives of the patches list, and goes through all the past patches: apply them, discard them, send them back for revision. 2) Commit to handling new patches that arrive, and either apply/discard/revise them. Worrying about patch management mechanism, while more patches pile up and are ignored in the meantime, is not going to help and will just results in continued stagnation. -- A.M. Kuchling http://starship.python.net/crew/amk/ I couldn't think of one clever way to stop this guy, so I just trusted to mindless violence. -- Cliff Steele in DOOM PATROL #21 From akuchlin@mems-exchange.org Wed Jun 21 21:27:31 2000 From: akuchlin@mems-exchange.org (Andrew M. Kuchling) Date: Wed, 21 Jun 2000 16:27:31 -0400 Subject: [Python-Dev] Patch management (was: Warnings in pythonrun.c) In-Reply-To: <14673.158.183876.75480@localhost.localdomain>; from jeremy@beopen.com on Wed, Jun 21, 2000 at 01:51:26PM -0400 References: <008c01bfdb58$103e8140$f2a6b5d4@hagrid> <14673.158.183876.75480@localhost.localdomain> Message-ID: <20000621162731.B3918@amarok.cnri.reston.va.us> On Wed, Jun 21, 2000 at 01:51:26PM -0400, Jeremy Hylton wrote: >>>>>> "TP" == Tim Peters writes: > TP> + This mailing list doesn't work. At least the SourceForge >I agree that it's a complete mess, though. While you're all admiring the difficulty of the problem, how about actually checking in the pythonrun.c patch, assuming it's reasonable? Frankly, I don't think the current mailing list is broken, *as long as patches are handled with reasonable speed* so that the backlog doesn't build up. That hasn't been done, and I don't understand why. Obviously the CNRI->BeOpen transaction resulted in some downtime for everyone, but now it's a month later and there's still stagnation. Why aren't incoming patches being handled now? It's not like there are very many patches per day; an hour or two should suffice to keep the queue from growing. At this point, the best fix is to do two things: 1) Someone downloads the mbox archives of the patches list, and goes through all the past patches: apply them, discard them, send them back for revision. 2) Commit to handling new patches that arrive, and either apply/discard/revise them. Worrying about patch management mechanism, while more patches pile up and are ignored in the meantime, is not going to help and will just results in continued stagnation. -- A.M. Kuchling http://starship.python.net/crew/amk/ I couldn't think of one clever way to stop this guy, so I just trusted to mindless violence. -- Cliff Steele in DOOM PATROL #21 From akuchlin@mems-exchange.org Wed Jun 21 21:27:31 2000 From: akuchlin@mems-exchange.org (Andrew M. Kuchling) Date: Wed, 21 Jun 2000 16:27:31 -0400 Subject: [Python-Dev] Patch management (was: Warnings in pythonrun.c) In-Reply-To: <14673.158.183876.75480@localhost.localdomain>; from jeremy@beopen.com on Wed, Jun 21, 2000 at 01:51:26PM -0400 References: <008c01bfdb58$103e8140$f2a6b5d4@hagrid> <14673.158.183876.75480@localhost.localdomain> Message-ID: <20000621162731.B3918@amarok.cnri.reston.va.us> On Wed, Jun 21, 2000 at 01:51:26PM -0400, Jeremy Hylton wrote: >>>>>> "TP" == Tim Peters writes: > TP> + This mailing list doesn't work. At least the SourceForge >I agree that it's a complete mess, though. While you're all admiring the difficulty of the problem, how about actually checking in the pythonrun.c patch, assuming it's reasonable? Frankly, I don't think the current mailing list is broken, *as long as patches are handled with reasonable speed* so that the backlog doesn't build up. That hasn't been done, and I don't understand why. Obviously the CNRI->BeOpen transaction resulted in some downtime for everyone, but now it's a month later and there's still stagnation. Why aren't incoming patches being handled now? It's not like there are very many patches per day; an hour or two should suffice to keep the queue from growing. At this point, the best fix is to do two things: 1) Someone downloads the mbox archives of the patches list, and goes through all the past patches: apply them, discard them, send them back for revision. 2) Commit to handling new patches that arrive, and either apply/discard/revise them. Worrying about patch management mechanism, while more patches pile up and are ignored in the meantime, is not going to help and will just results in continued stagnation. -- A.M. Kuchling http://starship.python.net/crew/amk/ I couldn't think of one clever way to stop this guy, so I just trusted to mindless violence. -- Cliff Steele in DOOM PATROL #21 From guido@python.org Wed Jun 21 23:55:22 2000 From: guido@python.org (Guido van Rossum) Date: Wed, 21 Jun 2000 17:55:22 -0500 Subject: [Python-Dev] updated exit.py and supporting files for your perusal In-Reply-To: Your message of "Wed, 21 Jun 2000 13:15:19 EST." <14673.1591.506532.170015@beluga.mojam.com> References: <14673.1591.506532.170015@beluga.mojam.com> Message-ID: <200006212255.RAA02444@cj20424-a.reston1.va.home.com> If I had designed this, I might have called the module "onexit" or "atexit" and the public function simply "register()". But I've got only a +0 for my own proposal. A +1 for the general idea. --Guido van Rossum (home page: http://www.python.org/~guido/) From paul@prescod.net Wed Jun 21 23:13:39 2000 From: paul@prescod.net (Paul Prescod) Date: Wed, 21 Jun 2000 17:13:39 -0500 Subject: [Python-Dev] list comprehensions References: Message-ID: <39513E13.F8082811@prescod.net> Tim Peters wrote: > > ... > Nobody has been more vocal in support of these (& augmented assignments) > than me, but I very strongly doubt they'll be in 1.6. In the interests of > getting that out the door, Guido considers the 1.6 feature set to be frozen > already. Is there an argument for putting in features with flaming red neon lights: "warning, experimental, use at your risk." We want to follow a bazaar (if not outright bizarre) development strategy after all. Putting a patch "out there" really doesn't do much about having people really play with and comment on a feature. I would never have experimented (and decided against using...) metaclasses if they hadn't popped up as an experimental feature. Of course if there is a decent chance of breaking something already in there that works then that's another issue... > I think part of the pressure to get one more feature in Python (again & > again & again) is that release cycles have been soooooo protracted, now > slobbering well over the full year mark. Nah, no matter how quick you do the turnarounds, nobody wants to wait for their favorite feature. :) -- Paul Prescod - ISOGEN Consulting Engineer speaking for himself Floggings will continue until morale improves. From DavidA@ActiveState.com Wed Jun 21 18:25:07 2000 From: DavidA@ActiveState.com (David Ascher) Date: Wed, 21 Jun 2000 10:25:07 -0700 Subject: [Python-Dev] CVS and SSH under windows. In-Reply-To: Message-ID: > First, get the latest WinCVS. http://www.wincvs.org/download.html > I use the standard SSH Version 1.2.14 binary set. I cant recall the URL, There's a version at: ftp://ftp.cs.hut.fi/pub/ssh/contrib/ssh-1.2.14-win32bin.zip BUT... > You then need to make a “key” file - I cant recall the exact process, but > it is pretty simple. This is creating the identify file you specify to > WinCVS, as well as the public key you upload to source-force. C:\WinCVS>ssh-keygen I always get a 'gethostname: no such file or directory' so I had to create the key on Linux (as is mentioned in the page http://bmrc.berkeley.edu/people/chaffee/winntutil.html). Maybe you have a better binary for ssh? > NOTE - from memory, you MUST have a HOME env var set, and you MUST have a > “.ssh” directory under your home. Otherwise you get cryptic errors from > SSH that give no clue that this is the problem. > > After uploading the public key to source forge, you are nearly set. How do you do that? > The > last step is convinving CVS that you want to use this new SSH setting, and > not the setting CVS so kindly persists in its “CVS\Root” files. The only > way I found to do this was to either edit the Root files manually, or > remove the directories locally and force CVS to re-create them > (and thereby > re-pull everything - I assume you have ADSL in that hotel room :-) > Alternatively, dig up that CVS script posted to py-dev recently and change > it - personally, I never trusted it :-) > > All my root files look like: > :ext:mhammond@cvs.python.sourceforge.net:/cvsroot/python > > Yours almost certainly will be setup for anon access, not using ssh. > > Hope that makes sense. Im happy to chase anything else up I can > for you... > > Mark. > > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://www.python.org/mailman/listinfo/python-dev > From nascheme@enme.ucalgary.ca Thu Jun 22 01:25:46 2000 From: nascheme@enme.ucalgary.ca (Neil Schemenauer) Date: Wed, 21 Jun 2000 18:25:46 -0600 Subject: [Python-Dev] updated exit.py and supporting files for your perusal In-Reply-To: <14673.1591.506532.170015@beluga.mojam.com>; from skip@mojam.com on Wed, Jun 21, 2000 at 01:15:19PM -0500 References: <14673.1591.506532.170015@beluga.mojam.com> Message-ID: <20000621182546.B25879@acs.ucalgary.ca> On Wed, Jun 21, 2000 at 01:15:19PM -0500, Skip Montanaro wrote: > Also, can someone tell me how to coax CVS into creating a > unified diff that actually contains new files? I tried > > cvs diff -RNau > > without success. Did you "cvs add" them? Neil -- "Simplicity does not precede complexity, but follows it." -- Alan Perlis From skip@mojam.com (Skip Montanaro) Thu Jun 22 01:39:03 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Wed, 21 Jun 2000 19:39:03 -0500 (CDT) Subject: [Python-Dev] updated exit.py and supporting files for your perusal In-Reply-To: <20000621182546.B25879@acs.ucalgary.ca> References: <14673.1591.506532.170015@beluga.mojam.com> <20000621182546.B25879@acs.ucalgary.ca> Message-ID: <14673.24615.291912.261214@beluga.mojam.com> >> Also, can someone tell me how to coax CVS into creating a unified >> diff that actually contains new files? I tried >> >> cvs diff -RNau >> >> without success. Neil> Did you "cvs add" them? Not something I could do, since I'm cvs'ing against the sourceforge repository. The best I guess I can do is to mirror the repository twice, add the new files to one tree, then perform a regular diff... Skip From esr@thyrsus.com Thu Jun 22 03:09:35 2000 From: esr@thyrsus.com (esr@thyrsus.com) Date: Wed, 21 Jun 2000 22:09:35 -0400 Subject: [Python-Dev] list comprehensions In-Reply-To: References: <20000620132150.O8678@thyrsus.com> Message-ID: <20000621220934.A1044@thyrsus.com> Tim Peters : > Nobody has been more vocal in support of these (& augmented assignments) > than me, but I very strongly doubt they'll be in 1.6. In the interests of > getting that out the door, Guido considers the 1.6 feature set to be frozen > already. > > I think part of the pressure to get one more feature in Python (again & > again & again) is that release cycles have been soooooo protracted, now > slobbering well over the full year mark. If I accomplish nothing else at > BeOpen, I want to give that a major speed boost -- I don't think we should > ever let 6 months go by without at least pumping out a bugfix release. OK, I can buy this. Are there concrete plans (as in, a specified timeframe) for a release in which new features will be admitted? -- Eric S. Raymond What, then is law [government]? It is the collective organization of the individual right to lawful defense." -- Frederic Bastiat, "The Law" From mal@lemburg.com Thu Jun 22 10:05:09 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 22 Jun 2000 11:05:09 +0200 Subject: [Python-Dev] updated exit.py and supporting files for your perusal References: <14673.1591.506532.170015@beluga.mojam.com> Message-ID: <3951D6C5.BA31276B@lemburg.com> > This message contains four attached files: > > Lib/exit.py - a module that allows users to register cleanup functions > Lib/test/test_exit.py - a simple test script > Lib/test/output/test_exit - expected test output > Doc/lib/libexit.tex - library reference manual section > > Besides adding documentation and a test script, the following two mods were > made to exit.py since I previously posted it: > > 1. It implements a LIFO execution order > 2. If sys.exitfunc is already defined and not exit._run_exitfuncs, it is > treated as an exit function and appended to the exit function list. > > Comments, please. Looks ok to me, but since this is going to be a new standard module I guess we should wait for Guido's ok before checking it in. > Also, can someone tell me how to coax CVS into creating a > unified diff that actually contains new files? I tried > > cvs diff -RNau > > without success. I'm not an CVS expert, but I could imagine that you'll have to add the files to CVS first and then run the above diff. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gstein@lyra.org Thu Jun 22 14:30:53 2000 From: gstein@lyra.org (Greg Stein) Date: Thu, 22 Jun 2000 06:30:53 -0700 Subject: [Python-Dev] CVS and SSH under windows. In-Reply-To: ; from DavidA@ActiveState.com on Wed, Jun 21, 2000 at 10:25:07AM -0700 References: Message-ID: <20000622063053.M29590@lyra.org> On Wed, Jun 21, 2000 at 10:25:07AM -0700, David Ascher wrote: >... > > You then need to make a “key” file - I cant recall the exact process, but > > it is pretty simple. This is creating the identify file you specify to > > WinCVS, as well as the public key you upload to source-force. > > C:\WinCVS>ssh-keygen > > I always get a 'gethostname: no such file or directory' so I had to create > the key on Linux (as is mentioned in the page > http://bmrc.berkeley.edu/people/chaffee/winntutil.html). > > Maybe you have a better binary for ssh? Nah. Mark just forgets that I generated the key for him from my Linux box :-) hehe... Cheers, -g -- Greg Stein, http://www.lyra.org/ From tim_one@email.msn.com Thu Jun 22 14:46:15 2000 From: tim_one@email.msn.com (Tim Peters) Date: Thu, 22 Jun 2000 09:46:15 -0400 Subject: [Python-Dev] SourceForge vs Windows In-Reply-To: Message-ID: I have to get SourceForge developer access working with Windows (Win98SE, specifically), so I'll write up detailed instructions along the way, building on Mark Hammond's good clues. Play along! I'll accumulate everyone's input & make a coherent how-to out of it. Today's installment only covers the first step, as it took 12 hours for meto complete it (rotten connectivity today, via 56K modem, requiring many attempts at downloading before one succeeded): [Mark Hammond] > First, get the latest WinCVS. Has some nice new features. Mine shows > as 1.1b13. It has a slightly “slicker” more windowsy look than the > older one. What we really want is the version with the Options/Preferences > dialog that allows you to supply the “RAS identity” file when you select > “SSH Server” as the auth method. Previous versions allow you to select > the SSH Server, but give you nowhere to put the identity file. Hence > previous versions used a batch file wrapper, which you probably saw > reference to. This version makes it much simpler. I picked up the 1.1b14 version, released 19 Jun 2000, from http://www.wincvs.org/download.html It's a 3.21 Mb zip file. hard-to-blow-it-so-far-ly y'rs - tim From tim_one@email.msn.com Thu Jun 22 14:46:17 2000 From: tim_one@email.msn.com (Tim Peters) Date: Thu, 22 Jun 2000 09:46:17 -0400 Subject: [Python-Dev] list comprehensions In-Reply-To: <20000621220934.A1044@thyrsus.com> Message-ID: [Tim, sez the 1.6 feature set should be considered frozen, and that Python should move to a much less sloth-like release schedule thereafter] [esr@thyrsus.com] > OK, I can buy this. Comes with a 30-day warranty, too . > Are there concrete plans (as in, a specified timeframe) > for a release in which new features will be admitted? There damn well ought to be. PythonLabs will be having its first all-hands meeting tomorrow (Guido's been gone, I've been in this state less than a week, & I'm still not sure Jeremy Hylton exists), and rational, timely release schedules are certainly on my agenda. I have no problem with new features in minor releases either, provided they're 100% backward-compatible (e.g., list comprehensions, yes (so long as they don't introduce new bytecodes); having str(long) strip the trailing "L", no). More when we know more. and-less-when-we-know-less-ly y'rs - tim From nascheme@enme.ucalgary.ca Thu Jun 22 16:24:16 2000 From: nascheme@enme.ucalgary.ca (Neil Schemenauer) Date: Thu, 22 Jun 2000 09:24:16 -0600 Subject: [Python-Dev] updated exit.py and supporting files for your perusal In-Reply-To: <14673.24615.291912.261214@beluga.mojam.com>; from skip@mojam.com on Wed, Jun 21, 2000 at 07:39:03PM -0500 References: <14673.1591.506532.170015@beluga.mojam.com> <20000621182546.B25879@acs.ucalgary.ca> <14673.24615.291912.261214@beluga.mojam.com> Message-ID: <20000622092416.A31223@acs.ucalgary.ca> On Wed, Jun 21, 2000 at 07:39:03PM -0500, Skip Montanaro wrote: > Neil> Did you "cvs add" them? > > Not something I could do, since I'm cvs'ing against the sourceforge > repository. That's okay. "cvs add" only modifies things locally. You have to "cvs commit" to change things in the repository. Neil -- The internet: Learn what you know. Share what you don't. From klm@digicool.com Thu Jun 22 17:13:46 2000 From: klm@digicool.com (Ken Manheimer) Date: Thu, 22 Jun 2000 12:13:46 -0400 (EDT) Subject: [Python-Dev] CVS and SSH under windows. In-Reply-To: <20000622063053.M29590@lyra.org> Message-ID: A bit of a tangent, but MindTerm - http://www.mindbright.se/mindterm - is a pretty nice java SSH client which you can use on windows to generate the RSA identity. (It also is a fine SSH client, with just about all the nicities except compression - scp, x11 forwarding, arbitrary tunneling, etc are all in there...) Ken klm@digicool.com On Thu, 22 Jun 2000, Greg Stein wrote: > On Wed, Jun 21, 2000 at 10:25:07AM -0700, David Ascher wrote: > >... > > > You then need to make a =93key=94 file - I cant recall the exact proc= ess, but > > > it is pretty simple. This is creating the identify file you specify = to > > > WinCVS, as well as the public key you upload to source-force. > >=20 > > =09C:\WinCVS>ssh-keygen > >=20 > > I always get a 'gethostname: no such file or directory' so I had to cre= ate > > the key on Linux (as is mentioned in the page > > http://bmrc.berkeley.edu/people/chaffee/winntutil.html). > >=20 > > Maybe you have a better binary for ssh? >=20 > Nah. Mark just forgets that I generated the key for him from my Linux box= :-) >=20 > hehe... >=20 > Cheers, > -g >=20 > --=20 > Greg Stein, http://www.lyra.org/ >=20 > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://www.python.org/mailman/listinfo/python-dev >=20 From skip@mojam.com (Skip Montanaro) Thu Jun 22 18:21:04 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Thu, 22 Jun 2000 12:21:04 -0500 (CDT) Subject: [Python-Dev] updated exit.py and supporting files for your perusal In-Reply-To: <200006212255.RAA02444@cj20424-a.reston1.va.home.com> References: <14673.1591.506532.170015@beluga.mojam.com> <200006212255.RAA02444@cj20424-a.reston1.va.home.com> Message-ID: <14674.19200.325533.979792@beluga.mojam.com> Guido> If I had designed this, I might have called the module "onexit" Guido> or "atexit" and the public function simply "register()". But Guido> I've got only a +0 for my own proposal. A +1 for the general Guido> idea. I'm happy to change things. I was a bit curious if people would ask about such a common word for a new module name. What module name do people prefer, "atexit", "onexit" (reads quickly like "one exit" if you're not careful), or something else? Skip From skip@mojam.com (Skip Montanaro) Thu Jun 22 18:27:18 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Thu, 22 Jun 2000 12:27:18 -0500 (CDT) Subject: [Python-Dev] updated exit.py and supporting files for your perusal In-Reply-To: <20000622092416.A31223@acs.ucalgary.ca> References: <14673.1591.506532.170015@beluga.mojam.com> <20000621182546.B25879@acs.ucalgary.ca> <14673.24615.291912.261214@beluga.mojam.com> <20000622092416.A31223@acs.ucalgary.ca> Message-ID: <14674.19574.609843.392230@beluga.mojam.com> Neil> That's okay. "cvs add" only modifies things locally. You have to Neil> "cvs commit" to change things in the repository. Ah, thanks for the tip. I'll try that next time... Skip From tim_one@email.msn.com Fri Jun 23 02:38:43 2000 From: tim_one@email.msn.com (Tim Peters) Date: Thu, 22 Jun 2000 21:38:43 -0400 Subject: [Python-Dev] RE: [Patches] Patch management (was: Warnings in pythonrun.c) In-Reply-To: <20000621162731.B3918@amarok.cnri.reston.va.us> Message-ID: [Andrew M. Kuchling] > While you're all admiring the difficulty of the problem, how about > actually checking in the pythonrun.c patch, assuming it's reasonable? I can't yet. Be my guest! > > > Frankly, I don't think the current mailing list is broken, *as long as > patches are handled with reasonable speed* so that the backlog doesn't > build up. Andrew, this is saying that if it didn't display all the symptoms of illness, it wouldn't be sick. The consistent (this started long before Guido's honeymoon!) lack of timely action here *is* the brokenness. > That hasn't been done, and I don't understand why. Why didn't you check in the pythonrun.c patch? Multiply by 10 people and 100 patches. There are no mechanisms in a mailing list for assigning, recording or checking responsibility, neither for recording or querying disposition status. Nobody owns any part of the problem now, and it's extraordinarly difficult to determine the status of any particular patch you may be interested in via this mish-mash of archived all-topic email scattered across patches and python-dev. Prior to this mailing list, Guido owned every problem and the database was in his head. I think it's the lack of the "owned" and "database" parts we're suffering from here, not especially the lack of the "Guido" part. SourceForge provides rudimentary mechanisms for both of the former; a Python replacement for Guido is one of BeOpen's highest secret priorities . > ... > Worrying about patch management mechanism, while more patches pile up > and are ignored in the meantime, is not going to help and will just > results in continued stagnation. At an all-hands PythonLabs group mtg today, it was decided to move patch activity to SourceForge and kill the patches list. I'll send more about that later. There is absolutely nothing new stopping checkins while the move to the SourceForge patch manager is in progress, so if the patches continue to pile up it's certainly not the move's fault. If the pythonrun.c patch is still sitting untouched after the move, I'll assign it to you <0.7 wink>. the-only-one-working-on-the-move-is-me-and-i-haven't-done-a-checkin- yet-anyway-ly y'rs - tim From mal@lemburg.com Fri Jun 23 09:03:41 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 23 Jun 2000 10:03:41 +0200 Subject: [Python-Dev] Re: [Patches] Patch management (was: Warnings in pythonrun.c) References: Message-ID: <395319DD.F2584321@lemburg.com> Tim Peters wrote: > > > Worrying about patch management mechanism, while more patches pile up > > and are ignored in the meantime, is not going to help and will just > > results in continued stagnation. > > At an all-hands PythonLabs group mtg today, it was decided to move patch > activity to SourceForge and kill the patches list. I'll send more about > that later. There is absolutely nothing new stopping checkins while the > move to the SourceForge patch manager is in progress, so if the patches > continue to pile up it's certainly not the move's fault. If the pythonrun.c > patch is still sitting untouched after the move, I'll assign it to you <0.7 > wink>. But how are we going to discuss new patches from people outside python-dev then ? I do see the use of moving patch submission to SourceForge, but posting the patches on the list for revision by everyone who listens is certainly better than having to scan the patch manager entries... (push strategies usually produce more feedback than pull ones). A gateway from the patch manager to the patches list would solve this nicely. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Vladimir.Marangozov@inrialpes.fr Fri Jun 23 11:00:23 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Fri, 23 Jun 2000 12:00:23 +0200 (CEST) Subject: [Python-Dev] updated exit.py and supporting files for your perusal In-Reply-To: <14674.19200.325533.979792@beluga.mojam.com> from "Skip Montanaro" at Jun 22, 2000 12:21:04 PM Message-ID: <200006231000.MAA03550@python.inrialpes.fr> Skip Montanaro wrote: > > > Guido> If I had designed this, I might have called the module "onexit" > Guido> or "atexit" and the public function simply "register()". But > Guido> I've got only a +0 for my own proposal. A +1 for the general > Guido> idea. > > I'm happy to change things. I was a bit curious if people would ask about > such a common word for a new module name. What module name do people > prefer, "atexit", "onexit" (reads quickly like "one exit" if you're not > careful), or something else? > > Skip atexit.py -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From mal@lemburg.com Fri Jun 23 11:08:46 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 23 Jun 2000 12:08:46 +0200 Subject: [Python-Dev] updated exit.py and supporting files for your perusal References: <200006231000.MAA03550@python.inrialpes.fr> Message-ID: <3953372E.274907AB@lemburg.com> Vladimir Marangozov wrote: > > Skip Montanaro wrote: > > > > > > Guido> If I had designed this, I might have called the module "onexit" > > Guido> or "atexit" and the public function simply "register()". But > > Guido> I've got only a +0 for my own proposal. A +1 for the general > > Guido> idea. > > > > I'm happy to change things. I was a bit curious if people would ask about > > such a common word for a new module name. What module name do people > > prefer, "atexit", "onexit" (reads quickly like "one exit" if you're not > > careful), or something else? > > > > Skip > > atexit.py How about exitfunc.py ? It would make the relation to sys.exitfunc pretty clear. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From akuchlin@mems-exchange.org Fri Jun 23 12:30:02 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Fri, 23 Jun 2000 07:30:02 -0400 Subject: [Python-Dev] Patch management In-Reply-To: <395319DD.F2584321@lemburg.com>; from mal@lemburg.com on Fri, Jun 23, 2000 at 10:03:41AM +0200 References: <395319DD.F2584321@lemburg.com> Message-ID: <20000623073002.B9385@newcnri.cnri.reston.va.us> On Fri, Jun 23, 2000 at 10:03:41AM +0200, M.-A. Lemburg wrote: >A gateway from the patch manager to the patches list would >solve this nicely. According to what was said to me, it's thought that mailing new patches to an e-mail address is supported, and therefore setting up a So, I no longer have much of a problem with moving patches to SF, though I *still* think the mailing list would be sufficient with a bit more focused effort; sorry, Tim! But at least we're not going to burn weeks looking at different patch manager products, and then arguing about them, which is what I feared most. --amk From bwarsaw@python.org Fri Jun 23 15:33:11 2000 From: bwarsaw@python.org (Barry A. Warsaw) Date: Fri, 23 Jun 2000 10:33:11 -0400 (EDT) Subject: [Python-Dev] updated exit.py and supporting files for your perusal References: <14674.19200.325533.979792@beluga.mojam.com> <200006231000.MAA03550@python.inrialpes.fr> Message-ID: <14675.29991.933911.446078@anthem.concentric.net> >>>>> "VM" == Vladimir Marangozov writes: VM> atexit.py +1 From gward@mems-exchange.org Fri Jun 23 16:42:03 2000 From: gward@mems-exchange.org (Greg Ward) Date: Fri, 23 Jun 2000 11:42:03 -0400 Subject: [Python-Dev] RFC: Including PIL in 1.6 In-Reply-To: <20000620140419.C10038@thyrsus.com>; from esr@thyrsus.com on Tue, Jun 20, 2000 at 02:04:19PM -0400 References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us> <20000620140419.C10038@thyrsus.com> Message-ID: <20000623114202.A1778@ludwig.cnri.reston.va.us> On 20 June 2000, esr@thyrsus.com said: > Watch that argument -- it could turn and bite you. What's the justification > for including, e.g. POP client classes in the standard distribution? > > One of Python's most important strengths is the "batteries *are* > included" richness of the standard environment. I totally agree. There are two extremes, both completely silly: include nothing with Python (except string, re, os, and sys -- because Distutils needs them ;-), and include every useful, working, documented module under the sun. I don't think anyone would seriously argue for either approach. (Although you could argue that a completely stripped-down Python might be useful in certain environments, eg. a hand-held. But I don't think you'd win that argument.) And I will be the first to admit that the Distutils still aren't good enough: in most respects, they're better than MakeMaker (IMHO), but there's nothing like CPAN.pm or the XEmacs package manager. And I know from personal experience that, amazing as CPAN.pm is, it's not The Answer; and others have attested, that XEmacs is pretty damn good but still not perfect. But I still don't think PIL should be included in the core, if only because it's one of the Distutils "test cases". ;-) Greg -- Greg Ward - software developer gward@mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From gward@mems-exchange.org Fri Jun 23 16:45:16 2000 From: gward@mems-exchange.org (Greg Ward) Date: Fri, 23 Jun 2000 11:45:16 -0400 Subject: [Python-Dev] list comprehensions In-Reply-To: <39513E13.F8082811@prescod.net>; from paul@prescod.net on Wed, Jun 21, 2000 at 05:13:39PM -0500 References: <39513E13.F8082811@prescod.net> Message-ID: <20000623114516.B1778@ludwig.cnri.reston.va.us> On 21 June 2000, Paul Prescod said: > Is there an argument for putting in features with flaming red neon > lights: "warning, experimental, use at your risk." We want to follow a > bazaar (if not outright bizarre) development strategy after all. Putting > a patch "out there" really doesn't do much about having people really > play with and comment on a feature. I would never have experimented (and > decided against using...) metaclasses if they hadn't popped up as an > experimental feature. Well, remember there will probably be a "--with-gc" option to the configure script in 1.6. That's a good example of getting an experimental feature out there. However, a "--with-list-comprehensions" option would be a really bad idea; all of a sudden, it's no longer enough to say, "You need Python 1.6" to run this script/use this module, now you need to say, "You need Python 1.6 built with list comprehensions". Ugh. Real language features should not be selectable: either the language is Python 1.6 or it isn't. Greg -- Greg Ward - software developer gward@mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From akuchlin@mems-exchange.org Fri Jun 23 16:54:02 2000 From: akuchlin@mems-exchange.org (Andrew M. Kuchling) Date: Fri, 23 Jun 2000 11:54:02 -0400 Subject: [Python-Dev] list comprehensions In-Reply-To: <20000623114516.B1778@ludwig.cnri.reston.va.us>; from gward@mems-exchange.org on Fri, Jun 23, 2000 at 11:45:16AM -0400 References: <39513E13.F8082811@prescod.net> <20000623114516.B1778@ludwig.cnri.reston.va.us> Message-ID: <20000623115402.B4805@amarok.cnri.reston.va.us> On Fri, Jun 23, 2000 at 11:45:16AM -0400, Greg Ward wrote: >idea; all of a sudden, it's no longer enough to say, "You need Python >1.6" to run this script/use this module, now you need to say, "You need >Python 1.6 built with list comprehensions". Ugh. The same argument applies to --with-gc, though, since people might write code that creates cycles and needs GC to run without leaking like a sieve. Making GC optional is still the right solution, though, because its performance effects are still unknown and might be costly. --amk From gvwilson@nevex.com Fri Jun 23 17:09:36 2000 From: gvwilson@nevex.com (Greg Wilson) Date: Fri, 23 Jun 2000 12:09:36 -0400 (EDT) Subject: [Python-Dev] Re: list comprehensions / garbage collection / optional features In-Reply-To: <20000623115402.B4805@amarok.cnri.reston.va.us> Message-ID: > >Greg Ward wrote: > >idea; all of a sudden, it's no longer enough to say, "You need Python > >1.6" to run this script/use this module, now you need to say, "You need > >Python 1.6 built with list comprehensions". Ugh. > Andrew Kuchling wrote: > The same argument applies to --with-gc, though, since people might > write code that creates cycles and needs GC to run without leaking > like a sieve. Making GC optional is still the right solution, though, > because its performance effects are still unknown and might be costly. Greg Wilson writes: I'm really looking forward to recycling my rusty SETL idioms when list comprehensions become part of the "official" release, and to creating graphs in the obvious way if GC ever becomes standard. However, the more variations there are in the "standard" (as opposed to "developer") release, the more expensive (in time and sweat) it is to manage Python at large sites (like Los Alamos). This in turn makes it harder to persuade people that using Python will make their lives easier... Thanks, Greg Footnote: The existence of JPython was one of the arguments in favor of choosing Python for the Software Carpentry project. The fact that JPython and CPython have very different memory management behaviors almost negated that point: as one thirty-year veteran said, "It's no use having code that runs in lots of places if it runs differently in each." From nascheme@enme.ucalgary.ca Fri Jun 23 18:12:51 2000 From: nascheme@enme.ucalgary.ca (Neil Schemenauer) Date: Fri, 23 Jun 2000 11:12:51 -0600 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Objects classobject.c,2.86,2.87 dictobject.c,2.52,2.53 funcobject.c,2.20,2.21 listobject.c,2.73,2.74 tupleobject.c,2.36,2.37 In-Reply-To: <200006231418.HAA02869@slayer.i.sourceforge.net>; from jhylton@users.sourceforge.net on Fri, Jun 23, 2000 at 07:18:13AM -0700 References: <200006231418.HAA02869@slayer.i.sourceforge.net> Message-ID: <20000623111251.B10850@acs.ucalgary.ca> On Fri, Jun 23, 2000 at 07:18:13AM -0700, Jeremy Hylton wrote: > Round 1 of Neil Schemenauer's GC patches: Yay. :) > + class_traverse(PyClassObject *o, visitproc visit, void *arg) > + { ... > + return 0; > + } > + instance_traverse(PyInstanceObject *o, visitproc visit, void *arg) > + { ... > + return 1; > + } Oops. I think "return 0" is the proper thing to do. There are a few other functions that return 1 as well. Neil From fdrake@acm.org Fri Jun 23 19:08:06 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Fri, 23 Jun 2000 11:08:06 -0700 (PDT) Subject: [Python-Dev] out of touch Message-ID: <14675.42886.423185.310220@mailhost.beopen.com> My laptop has died, so I'm catching up with a couple of days of mail. I've not had time to look at Paul's proposed DOM-like additions to the standard library. Hopefully Andrew can (or has) summarized the relevant portions of our discussion from yesterday; if I don't see it, I'll try to get another message out later. (But I don't have my saved mail or files, so there's still not a lot I can do. ;( ) -Fred -- Fred L. Drake, Jr. From fdrake@beopen.com Fri Jun 23 20:04:55 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Fri, 23 Jun 2000 12:04:55 -0700 (PDT) Subject: [Python-Dev] updated exit.py and supporting files for your perusal In-Reply-To: <14674.19200.325533.979792@beluga.mojam.com> References: <14673.1591.506532.170015@beluga.mojam.com> <200006212255.RAA02444@cj20424-a.reston1.va.home.com> <14674.19200.325533.979792@beluga.mojam.com> Message-ID: <14675.46295.836727.117258@mailhost.beopen.com> Skip Montanaro writes: > I'm happy to change things. I was a bit curious if people would ask about > such a common word for a new module name. What module name do people > prefer, "atexit", "onexit" (reads quickly like "one exit" if you're not I like "atexit" better. -Fred -- Fred L. Drake, Jr. From guido@python.org Fri Jun 23 21:08:36 2000 From: guido@python.org (Guido van Rossum) Date: Fri, 23 Jun 2000 15:08:36 -0500 Subject: [Python-Dev] updated exit.py and supporting files for your perusal In-Reply-To: Your message of "Fri, 23 Jun 2000 12:04:55 MST." <14675.46295.836727.117258@mailhost.beopen.com> References: <14673.1591.506532.170015@beluga.mojam.com> <200006212255.RAA02444@cj20424-a.reston1.va.home.com> <14674.19200.325533.979792@beluga.mojam.com> <14675.46295.836727.117258@mailhost.beopen.com> Message-ID: <200006232008.PAA02759@cj20424-a.reston1.va.home.com> > Skip Montanaro writes: > > I'm happy to change things. I was a bit curious if people would ask about > > such a common word for a new module name. What module name do people > > prefer, "atexit", "onexit" (reads quickly like "one exit" if you're not [fred] > I like "atexit" better. OK, let it be atexit. I'm glad this time the naming debate is at least civilized. :-) --Guido van Rossum (home page: http://www.python.org/~guido/) From DavidA@ActiveState.com Fri Jun 23 20:30:31 2000 From: DavidA@ActiveState.com (David Ascher) Date: Fri, 23 Jun 2000 12:30:31 -0700 Subject: [Python-Dev] updated exit.py and supporting files for your perusal In-Reply-To: <200006232008.PAA02759@cj20424-a.reston1.va.home.com> Message-ID: > OK, let it be atexit. I'm glad this time the naming debate is at > least civilized. :-) No, wait, i think it should be exit_AT! Actually, I'm sick of this english-centricity. You american jerks are all the same! Go home Yankee! It should be en_sortant or nothing at all! --david "I try..." ascher From nascheme@enme.ucalgary.ca Fri Jun 23 21:11:03 2000 From: nascheme@enme.ucalgary.ca (Neil Schemenauer) Date: Fri, 23 Jun 2000 14:11:03 -0600 Subject: [Python-Dev] Fwd: Re: Linux/NT python startup speed Message-ID: <20000623141103.A13079@acs.ucalgary.ca> Has this been addressed yet for 1.6? It is probably an easy fix. The original poster claimed it took 4 seconds to start Python on his machine. Neil ----- Forwarded message from Johannes Stezenbach ----- Date: Thu, 22 Jun 2000 15:03:01 +0200 From: yawyi@gmx.de (Johannes Stezenbach) Subject: Re: Linux/NT python startup speed Niklas Frykholm wrote: >Can someone explain this difference. (The processor on the Linux system is >certainly not 40 times faster.) This was discussed here a few months ago. The reason for the slow startup is the winsound module (source: PC/winsound.c) which is unnecessarily a builtin. winsound causes Python to load the Windows multimedia DLLs, which can be slow if your sound drivers make it so. Two solutions were discussed: a) make winsound a .pyd b) use some obscure "delayload" feature of the M$ linker. There is a ready to use python15.dll for Python 1.5.2 with this feature somewhere out there (I don't remember where, though, since I use Linux now) IMHO solution a) should be standard in Python 1.6 (it isn't in 1.6a2). Johannes ----- End forwarded message ----- From tim_one@email.msn.com Fri Jun 23 21:11:47 2000 From: tim_one@email.msn.com (Tim Peters) Date: Fri, 23 Jun 2000 16:11:47 -0400 Subject: [Python-Dev] updated exit.py and supporting files for your perusal In-Reply-To: Message-ID: [Guido] >> OK, let it be atexit. I'm glad this time the naming debate is at >> least civilized. :-) {David Ascher] > No, wait, i think it should be exit_AT! > > Actually, I'm sick of this english-centricity. You american jerks are all > the same! Go home Yankee! It should be en_sortant or nothing at all! Oh, screw you and the frog you rode in, Frenchie. Using an inferior language is no excuse for poor grammar: "exit at" reads like a freeway sign, as in "Kentucky Fried Chicken, exit at 12B". en_sortant is no better -- worse, I have no idea what this has to do with arranging ants in order (and what kind of algorithm is en_sort anyway?). uponbutpriortoexiting is an idea that can't even be expressed in French, I bet. internationally y'rs - tim From guido@python.org Fri Jun 23 22:49:05 2000 From: guido@python.org (Guido van Rossum) Date: Fri, 23 Jun 2000 16:49:05 -0500 Subject: [Python-Dev] Fwd: Re: Linux/NT python startup speed In-Reply-To: Your message of "Fri, 23 Jun 2000 14:11:03 CST." <20000623141103.A13079@acs.ucalgary.ca> References: <20000623141103.A13079@acs.ucalgary.ca> Message-ID: <200006232149.QAA03157@cj20424-a.reston1.va.home.com> > Has this been addressed yet for 1.6? It is probably an easy fix. > The original poster claimed it took 4 seconds to start Python on > his machine. In 1.6, winsound is a separate subproject and hence a separately loadable DLL, so it doesn't slow down the main code. Ditto for socket and a few others. --Guido van Rossum (home page: http://www.python.org/~guido/) From jeremy@beopen.com Fri Jun 23 23:01:19 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Fri, 23 Jun 2000 18:01:19 -0400 Subject: [Python-Dev] Python 1.6 planning Message-ID: We discussed plans for Python 1.6 at the all-hands PythonLabs staff meeting yesterday. (At this meeting, the PythonLabs staff closed ranks and agreed to say that Tim Peters exists.) I'd like to quickly summarize plans. The target release date for Python 1.6 beta 1 is early July. Any code that is going to be in the beta must be checked in before July 1. Tim Peters pushed us to take care of the patches backlog. Our plan is to close the patches list and move all patch management to Sourceforge. We know the list is broken; we don't know that Sourceforge is broken. There are a bunch of modules and technical issues that must be resolved one way or another. SRE-- /F needs to finish this up. Unanswered question is whether the beta will ship with known bugs. GC-- Neil's garbage collector will be shipped as experimental feature requiring configure option. XML-- Some parts of the XML package will be included in the library under the xmlcore package. SAX and DOM (provided that it is stable enough). Andrew gets to decide, I believe. List comprehensions -- Next release. Despite the love fest at the meeting (everyone seems to want them), there is no way an implementation will be ready or stable enough. httplib-- We will include Greg Stein's new httplib, provided that it supports an old-style HTTPS class. curses-- one return type needs to be implemented (5-tuple). Andrew will finish ASAP. ESR's ascii module will be part of the curses package. imputil-- The imputil module will be dropped in the std library to enable wider distribution, but no changes will be made to the normal import machinery. Unicode shorthand-- Andrew will look at Bill Tutt's code. We intend to add it. Unicode compression-- We need to find out if Christian will be able to provide a compressed database. ldso_aix-- I still don't understand, but I didn't really try; Vladimir must help threads-- They will be on by default if the platform supports. gettext-- Barry will check in his gettext module. atexit.py-- add it Jeremy From nascheme@enme.ucalgary.ca Fri Jun 23 23:22:50 2000 From: nascheme@enme.ucalgary.ca (Neil Schemenauer) Date: Fri, 23 Jun 2000 16:22:50 -0600 Subject: [Python-Dev] Python 1.6 planning In-Reply-To: ; from jeremy@beopen.com on Fri, Jun 23, 2000 at 06:01:19PM -0400 References: Message-ID: <20000623162250.A14311@acs.ucalgary.ca> On Fri, Jun 23, 2000 at 06:01:19PM -0400, Jeremy Hylton wrote: > threads-- They will be on by default if the platform supports. Does the Linux thread/fork problem still exist? It would be nice to kill this before 1.6 final. I will test this with the CVS source this weekend. Neil From skip@mojam.com (Skip Montanaro) Sat Jun 24 02:09:04 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Fri, 23 Jun 2000 20:09:04 -0500 Subject: [Python-Dev] test failures... Message-ID: <200006240109.UAA14738@beluga.mojam.com> Using the latest CVS code, I get failures for three tests on my Linux Mandrake 6.1 laptop: test test_exceptions failed -- Writing: 'spam', expected: 'Attr' test test_types crashed -- exceptions.OverflowError : long int too long to convert test test_long failed -- int(long(-sys.maxint-1)) overflowed! Are these known/expected or unknown/unexpected failures? From skip@mojam.com (Skip Montanaro) Sat Jun 24 02:27:39 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Fri, 23 Jun 2000 20:27:39 -0500 (CDT) Subject: [Python-Dev] atexit.py patch Message-ID: <14676.3723.916135.602@beluga.mojam.com> --0bkw+IZ+u3 Content-Type: text/plain; charset=us-ascii Content-Description: message body and .signature Content-Transfer-Encoding: 7bit Here's the latest version of my exit module. Per the earlier discussion, the module has been renamed to atexit.py. I also took the suggestion from someone (Guido?) that the registration function be renamed to simply "register". Other than that everything else should be the same. I'm only sending this to python-dev, operating under the assumption that the patches list is about to take a long vacation... -- Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille O'Neal said: "He's got the rings. I listen to the man with the rings." --0bkw+IZ+u3 Content-Type: application/octet-stream Content-Description: atexit.py & doc Content-Disposition: attachment; filename="atexit.diff" Content-Transfer-Encoding: base64 ZGlmZiAtTmF1ciBzcmMub3JpZy9Eb2MvbGliL2xpYmF0ZXhpdC50ZXggc3JjL0RvYy9saWIv bGliYXRleGl0LnRleAotLS0gc3JjLm9yaWcvRG9jL2xpYi9saWJhdGV4aXQudGV4CVdlZCBE ZWMgMzEgMTg6MDA6MDAgMTk2OQorKysgc3JjL0RvYy9saWIvbGliYXRleGl0LnRleAlGcmkg SnVuIDIzIDE3OjI2OjIzIDIwMDAKQEAgLTAsMCArMSw0NSBAQAorXHNlY3Rpb257XG1vZHVs ZXthdGV4aXR9IC0tLQorICAgICAgICAgZXhpdCBoYW5kbGVyc30KKworXGRlY2xhcmVtb2R1 bGV7c3RhbmRhcmR9e2F0ZXhpdH0KK1xzZWN0aW9uYXV0aG9ye1NraXAgTW9udGFuYXJvfXtz a2lwQG1vamFtLmNvbX0KK1xtb2R1bGVzeW5vcHNpc3tSZWdpc3RlciBhbmQgZXhlY3V0ZSBj bGVhbnVwIGZ1bmN0aW9ucy59CisKK1RoZSBcbW9kdWxle2F0ZXhpdH0gbW9kdWxlIGRlZmlu ZXMgYSBzaW5nbGUgZnVuY3Rpb24gdG8gcmVnaXN0ZXIgY2xlYW51cAorZnVuY3Rpb25zLiAg RnVuY3Rpb25zIHRodXMgcmVnaXN0ZXJlZCBhcmUgYXV0b21hdGljYWxseSBleGVjdXRlZCB1 cG9uIG5vcm1hbAoraW50ZXJwcmV0ZXIgdGVybWluYXRpb24uCisKK1xiZWdpbntmdW5jZGVz Y317cmVnaXN0ZXJ9e2Z1bmNcb3B0aW9uYWx7LCAqYXJnc1xvcHRpb25hbHssICoqa2FyZ3N9 fX0KK1JlZ2lzdGVyIFxjb2Rle2Z1bmN9IGFzIGEgZnVuY3Rpb24gdG8gYmUgZXhlY3V0ZWQg YXQgdGVybWluYXRpb24uICBBbnkKK29wdGlvbmFsIGFyZ3VtZW50cyB0aGF0IGFyZSB0byBi ZSBwYXNzZWQgdG8gZnVuYyBtdXN0IGJlIHBhc3NlZCBhcyBhcmd1bWVudHMKK3RvIFxmdW5j e3JlZ2lzdGVyfS4KKworQXQgbm9ybWFsIHByb2dyYW0gdGVybWluYXRpb24gKGZvciBpbnN0 YW5jZSwgaWYgXGZ1bmN7c3lzLmV4aXR9IGlzIGNhbGxlZCBvcgordGhlIG1haW4gbW9kdWxl J3MgZXhlY3V0aW9uIGNvbXBsZXRlcyksIGFsbCBmdW5jdGlvbnMgcmVnaXN0ZXJlZCBhcmUg Y2FsbGVkCitpbiBsYXN0IGluLCBmaXJzdCBvdXQgb3JkZXIuICBUaGUgYXNzdW1wdGlvbiBp cyB0aGF0IGxvd2VyIGxldmVsIG1vZHVsZXMKK3dpbGwgbm9ybWFsbHkgYmUgaW1wb3J0ZWQg YmVmb3JlIGhpZ2hlciBsZXZlbCBtb2R1bGVzIGFuZCB0aHVzIG11c3QgYmUKK2NsZWFuZWQg dXAgbGF0ZXIuCisKK1xzdWJzZWN0aW9ue0V4YW1wbGV9CisKK1RoZSBmb2xsb3dpbmcgc2lt cGxlIGV4YW1wbGUgZGVtb25zdHJhdGVzIGhvdyBhIG1vZHVsZSBjYW4gaW5pdGlhbGl6ZSBh Citjb3VudGVyIGZyb20gYSBmaWxlIHdoZW4gaXQgaXMgaW1wb3J0ZWQgYW5kIHNhdmUgdGhl IGNvdW50ZXIncyB1cGRhdGVkIHZhbHVlCithdXRvbWF0aWNhbGx5IHdoZW4gdGhlIHByb2dy YW0gdGVybWluYXRlcy4KKworXGJlZ2lue3ZlcmJhdGltfQordHJ5OgorICAgIF9jb3VudCA9 IGV2YWwob3BlbigiL3RtcC9jb3VudGVyIikucmVhZCgpKQorZXhjZXB0IElPRXJyb3I6Cisg ICAgX2NvdW50ID0gMAorCitkZWYgaW5jcmNvdW50ZXIobik6CisgICAgZ2xvYmFsIF9jb3Vu dAorICAgIF9jb3VudCA9IF9jb3VudCArIG4KKworZGVmIHNhdmVjb3VudGVyKCk6CisgICAg b3BlbigiL3RtcC9jb3VudGVyIiwgInciKS53cml0ZSgiJWQiICUgX2NvdW50KQorCitpbXBv cnQgYXRleGl0CithdGV4aXQucmVnaXN0ZXIoc2F2ZWNvdW50ZXIpCitcZW5ke3ZlcmJhdGlt fQorCmRpZmYgLU5hdXIgc3JjLm9yaWcvTGliL2F0ZXhpdC5weSBzcmMvTGliL2F0ZXhpdC5w eQotLS0gc3JjLm9yaWcvTGliL2F0ZXhpdC5weQlXZWQgRGVjIDMxIDE4OjAwOjAwIDE5NjkK KysrIHNyYy9MaWIvYXRleGl0LnB5CUZyaSBKdW4gMjMgMTc6Mjc6MzIgMjAwMApAQCAtMCww ICsxLDU0IEBACisiIiIKK2F0ZXhpdC5weSAtIGFsbG93IHByb2dyYW1tZXIgdG8gZGVmaW5l IG11bHRpcGxlIGV4aXQgZnVuY3Rpb25zIHRvIGJlIGV4ZWN1dGVkCit1cG9uIG5vcm1hbCBw cm9ncmFtIHRlcm1pbmF0aW9uLgorCitPbmUgcHVibGljIGZ1bmN0aW9uLCByZWdpc3Rlciwg aXMgZGVmaW5lZC4gIAorIiIiCisKK19leGl0aGFuZGxlcnMgPSBbXQorZGVmIF9ydW5fZXhp dGZ1bmNzKCk6CisgICAgIiIicnVuIGFueSByZWdpc3RlcmVkIGV4aXQgZnVuY3Rpb25zCisK KyAgICBfZXhpdGhhbmRsZXJzIGlzIHRyYXZlcnNlZCBpbiByZXZlcnNlIG9yZGVyIHNvIGZ1 bmN0aW9ucyBhcmUgZXhlY3V0ZWQKKyAgICBsYXN0IGluLCBmaXJzdCBvdXQuCisgICAgIiIi CisgICAgCisgICAgd2hpbGUgX2V4aXRoYW5kbGVyczoKKyAgICAgICAgZnVuYywgdGFyZ3Ms IGthcmdzID0gX2V4aXRoYW5kbGVyc1stMV0KKyAgICAgICAgYXBwbHkoZnVuYywgdGFyZ3Ms IGthcmdzKQorICAgICAgICBfZXhpdGhhbmRsZXJzLnJlbW92ZShfZXhpdGhhbmRsZXJzWy0x XSkKKworZGVmIHJlZ2lzdGVyKGZ1bmMsICp0YXJncywgKiprYXJncyk6CisgICAgIiIicmVn aXN0ZXIgYSBmdW5jdGlvbiB0byBiZSBleGVjdXRlZCB1cG9uIG5vcm1hbCBwcm9ncmFtIHRl cm1pbmF0aW9uCisKKyAgICBmdW5jIC0gZnVuY3Rpb24gdG8gYmUgY2FsbGVkIGF0IGV4aXQK KyAgICB0YXJncyAtIG9wdGlvbmFsIGFyZ3VtZW50cyB0byBwYXNzIHRvIGZ1bmMKKyAgICBr YXJncyAtIG9wdGlvbmFsIGtleXdvcmQgYXJndW1lbnRzIHRvIHBhc3MgdG8gZnVuYworICAg ICIiIgorICAgIF9leGl0aGFuZGxlcnMuYXBwZW5kKChmdW5jLCB0YXJncywga2FyZ3MpKQor CitpbXBvcnQgc3lzCit0cnk6CisgICAgeCA9IHN5cy5leGl0ZnVuYworZXhjZXB0IEF0dHJp YnV0ZUVycm9yOgorICAgIHN5cy5leGl0ZnVuYyA9IF9ydW5fZXhpdGZ1bmNzCitlbHNlOgor ICAgICMgaWYgeCBpc24ndCBvdXIgb3duIGV4aXQgZnVuYyBleGVjdXRpdmUsIGFzc3VtZSBp dCdzIGFub3RoZXIKKyAgICAjIHJlZ2lzdGVyZWQgZXhpdCBmdW5jdGlvbiAtIGFwcGVuZCBp dCB0byBvdXIgbGlzdC4uLgorICAgIGlmIHggIT0gX3J1bl9leGl0ZnVuY3M6CisgICAgICAg IHJlZ2lzdGVyKHgpCitkZWwgc3lzCisKK2lmIF9fbmFtZV9fID09ICJfX21haW5fXyI6Cisg ICAgZGVmIHgxKCk6CisgICAgICAgIHByaW50ICJydW5uaW5nIHgxIgorICAgIGRlZiB4Mihu KToKKyAgICAgICAgcHJpbnQgInJ1bm5pbmcgeDIoJXMpIiAlIGBuYAorICAgIGRlZiB4Myhu LCBrd2Q9Tm9uZSk6CisgICAgICAgIHByaW50ICJydW5uaW5nIHgzKCVzLCBrd2Q9JXMpIiAl IChgbmAsIGBrd2RgKQorCisgICAgcmVnaXN0ZXIoeDEpCisgICAgcmVnaXN0ZXIoeDIsIDEy KQorICAgIHJlZ2lzdGVyKHgzLCA1LCAiYmFyIikKKyAgICByZWdpc3Rlcih4MywgIm5vIGt3 ZCBhcmdzIikKKwpkaWZmIC1OYXVyIHNyYy5vcmlnL0xpYi90ZXN0L291dHB1dC90ZXN0X2F0 ZXhpdCBzcmMvTGliL3Rlc3Qvb3V0cHV0L3Rlc3RfYXRleGl0Ci0tLSBzcmMub3JpZy9MaWIv dGVzdC9vdXRwdXQvdGVzdF9hdGV4aXQJV2VkIERlYyAzMSAxODowMDowMCAxOTY5CisrKyBz cmMvTGliL3Rlc3Qvb3V0cHV0L3Rlc3RfYXRleGl0CUZyaSBKdW4gMjMgMTc6Mjg6NTMgMjAw MApAQCAtMCwwICsxLDQgQEAKK3Rlc3RfYXRleGl0CitoYW5kbGVyMiAoNywpIHsna3cnOiAn YWJjJ30KK2hhbmRsZXIyICgpIHt9CitoYW5kbGVyMQpkaWZmIC1OYXVyIHNyYy5vcmlnL0xp Yi90ZXN0L3Rlc3RfYXRleGl0LnB5IHNyYy9MaWIvdGVzdC90ZXN0X2F0ZXhpdC5weQotLS0g c3JjLm9yaWcvTGliL3Rlc3QvdGVzdF9hdGV4aXQucHkJV2VkIERlYyAzMSAxODowMDowMCAx OTY5CisrKyBzcmMvTGliL3Rlc3QvdGVzdF9hdGV4aXQucHkJRnJpIEp1biAyMyAxNzoyODoz MSAyMDAwCkBAIC0wLDAgKzEsMjQgQEAKKyMgVGVzdCB0aGUgZXhpdCBtb2R1bGUKK2Zyb20g dGVzdF9zdXBwb3J0IGltcG9ydCB2ZXJib3NlCitpbXBvcnQgYXRleGl0CisKK2RlZiBoYW5k bGVyMSgpOgorICAgIHByaW50ICJoYW5kbGVyMSIKKworZGVmIGhhbmRsZXIyKCphcmdzLCAq KmthcmdzKToKKyAgICBwcmludCAiaGFuZGxlcjIiLCBhcmdzLCBrYXJncworCisjIHNhdmUg YW55IGV4aXQgZnVuY3Rpb25zIHRoYXQgbWF5IGhhdmUgYmVlbiByZWdpc3RlcmVkIGFzIHBh cnQgb2YgdGhlCisjIHRlc3QgZnJhbWV3b3JrCitfZXhpdGhhbmRsZXJzID0gYXRleGl0Ll9l eGl0aGFuZGxlcnMKK2F0ZXhpdC5fZXhpdGhhbmRsZXJzID0gW10KKworYXRleGl0LnJlZ2lz dGVyKGhhbmRsZXIxKQorYXRleGl0LnJlZ2lzdGVyKGhhbmRsZXIyKQorYXRleGl0LnJlZ2lz dGVyKGhhbmRsZXIyLCA3LCBrdz0iYWJjIikKKworIyBzaW11bGF0ZSBleGl0IGJlaGF2aW9y IGJ5IGNhbGxpbmcgYXRleGl0Ll9ydW5fZXhpdGZ1bmNzIGRpcmVjdGx5Li4uCithdGV4aXQu X3J1bl9leGl0ZnVuY3MoKQorCisjIHJlc3RvcmUgZXhpdCBoYW5kbGVycworYXRleGl0Ll9l eGl0aGFuZGxlcnMgPSBfZXhpdGhhbmRsZXJzCg== --0bkw+IZ+u3-- From trentm@activestate.com Sat Jun 24 03:19:23 2000 From: trentm@activestate.com (Trent Mick) Date: Fri, 23 Jun 2000 19:19:23 -0700 Subject: [Python-Dev] test failures... In-Reply-To: <200006240109.UAA14738@beluga.mojam.com> References: <200006240109.UAA14738@beluga.mojam.com> Message-ID: <20000623191923.A25730@activestate.com> On Fri, Jun 23, 2000 at 08:09:04PM -0500, Skip Montanaro wrote: > Using the latest CVS code, I get failures for three tests on my Linux > Mandrake 6.1 laptop: > > test test_exceptions failed -- Writing: 'spam', expected: 'Attr' Don't know about this one. > test test_types crashed -- exceptions.OverflowError : long int too long to convert This is related to some conversion checking that I added a while back, I believe. > test test_long failed -- int(long(-sys.maxint-1)) overflowed! > Same thing. Potentially this *should* overflow and the test should expect that. Don't take my word on this right now, only looked quickly. I will look at it this weekend (hopefully). Skip, I don't get the test failures, although I am a few days behind Python-CVS. Are these very new failures? Could you provide the verbose output from running these tests indepedently? Thanks. Trent -- Trent Mick trentm@activestate.com From tim_one@email.msn.com Sat Jun 24 03:32:46 2000 From: tim_one@email.msn.com (Tim Peters) Date: Fri, 23 Jun 2000 22:32:46 -0400 Subject: [Python-Dev] test failures... In-Reply-To: <200006240109.UAA14738@beluga.mojam.com> Message-ID: [Skip Montanaro] > Using the latest CVS code, I get failures for three tests on my Linux > Mandrake 6.1 laptop: > > test test_exceptions failed -- Writing: 'spam', expected: 'Attr' > test test_types crashed -- exceptions.OverflowError : long int > too long to convert > test test_long failed -- int(long(-sys.maxint-1)) overflowed! > > Are these known/expected or unknown/unexpected failures? First two don't ring a bell, last one has shown up several times & each time traced to an optimization bug, usually in a particular older version of gcc. Recompile with optimization off and see whether that makes all of them go away. If so, try using a recent gcc. From tim_one@email.msn.com Sat Jun 24 03:41:23 2000 From: tim_one@email.msn.com (Tim Peters) Date: Fri, 23 Jun 2000 22:41:23 -0400 Subject: [Python-Dev] test failures... In-Reply-To: <20000623191923.A25730@activestate.com> Message-ID: >> test test_types crashed -- exceptions.OverflowError : long >> int too long to convert > This is related to some conversion checking that I added a while back, I > believe. Possible but doubt it. >> test test_long failed -- int(long(-sys.maxint-1)) overflowed! > Same thing. Potentially this *should* overflow and the test should expect > that. Definitely not on this one: sys.maxint is by defn the largest positive Python int, so on any 2's-comp machine -sys.maxint-1 should be a legit Python int too. This bogus failure has popped up due to compiler optimization bugs under at least two older different compilers, though (gcc being by far the more often reported culprit -- I think the other was one of those HP compilers that seems to generate more bad code than good <0.3 wink>). The first step in test failures like this is to recompile with optimization off. From skip@mojam.com (Skip Montanaro) Sat Jun 24 04:45:04 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Fri, 23 Jun 2000 22:45:04 -0500 (CDT) Subject: [Python-Dev] test failures... In-Reply-To: References: <200006240109.UAA14738@beluga.mojam.com> Message-ID: <14676.11968.263924.752216@beluga.mojam.com> >> test test_exceptions failed -- Writing: 'spam', expected: 'Attr' >> test test_types crashed -- exceptions.OverflowError : long int too long to convert >> test test_long failed -- int(long(-sys.maxint-1)) overflowed! Tim> First two don't ring a bell, last one has shown up several times & Tim> each time traced to an optimization bug, usually in a particular Tim> older version of gcc. Recompile with optimization off and see Tim> whether that makes all of them go away. If so, try using a recent Tim> gcc. Turning off optimization got rid of the test_types and test_long failures. The test_exceptins failure remains. Here's a diff: diff test_exceptions.save test_exceptions 2a3 > spam 3a5 > spam 4a7 > spam 5a9 > spam 6a11 > spam 7a13 > spam 8a15 > spam 10a18 > spam 12a21 > spam 13a23 > spam 14a25 > spam 16a28 > spam 17a30 > spam 19a33 > spam 20a35 > spam 21a37 > spam 22a39 > spam 23a41 > spam I'm not sure what that means, but it seems consistent. ;-) As for the age of my gcc, I think I'm reasonably current (only a bit over a year old): % gcc -v Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/pgcc-2.91.66/specs gcc version pgcc-2.91.66 19990314 (egcs-1.1.2 release) I will try downloading a newer RPM. Skip From ping@lfw.org Sat Jun 24 07:08:42 2000 From: ping@lfw.org (Ka-Ping Yee) Date: Sat, 24 Jun 2000 01:08:42 -0500 (CDT) Subject: [Python-Dev] updated exit.py and supporting files for your perusal In-Reply-To: <200006232008.PAA02759@cj20424-a.reston1.va.home.com> Message-ID: On Fri, 23 Jun 2000, Guido van Rossum wrote: > [fred] > > I like "atexit" better. > > OK, let it be atexit. I'm glad this time the naming debate is at > least civilized. :-) Sorry to confuddle things, but what happened to the idea of sticking it in "sys"? If sys.exitfunc lives there, doesn't sys.atexit(...) also make sense? It can't be very hard to do... -- ?!ng From guido@python.org Sat Jun 24 17:03:07 2000 From: guido@python.org (Guido van Rossum) Date: Sat, 24 Jun 2000 11:03:07 -0500 Subject: [Python-Dev] test failures... In-Reply-To: Your message of "Fri, 23 Jun 2000 20:09:04 EST." <200006240109.UAA14738@beluga.mojam.com> References: <200006240109.UAA14738@beluga.mojam.com> Message-ID: <200006241603.LAA05123@cj20424-a.reston1.va.home.com> > test test_exceptions failed -- Writing: 'spam', expected: 'Attr' There's a "print buf" at the end of the new function test_raise_catch() that causes this. Jeremy added this; either the "print buf" shouldn't be there, or the file Lib/test/output/test_exceptions should be updated. It's up to Jeremy now. --Guido van Rossum (home page: http://www.python.org/~guido/) From skip@mojam.com (Skip Montanaro) Sat Jun 24 16:11:18 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Sat, 24 Jun 2000 10:11:18 -0500 (CDT) Subject: [Python-Dev] updated exit.py and supporting files for your perusal In-Reply-To: References: <200006232008.PAA02759@cj20424-a.reston1.va.home.com> Message-ID: <14676.53142.263320.435588@beluga.mojam.com> Ping> Sorry to confuddle things, but what happened to the idea of Ping> sticking it in "sys"? If sys.exitfunc lives there, doesn't Ping> sys.atexit(...) also make sense? It can't be very hard to do... I like the general idea that stuff implemented in C is just a thin interface layer on top of existing system services and that higher level protocols are implemented in Python where there's no overriding need for them to be written in C. This fits that model, at least to a first approximation. The sys.exitfunc variable functions pretty much like calling the atexit(3) library call (though that's not how sys.exitfunc is implemented), and the atexit module provides a protocol that dictates how that mechanism is used in a cooperative setting. There's almost certainly no performance reason this code should be implemented in C. It's going to be easier to maintain and enhance if written in Python, and won't add size to the interpreter for those programmers who don't use it (or don't use other modules that do). -- Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille O'Neal said: "He's got the rings. I listen to the man with the rings." From nascheme@enme.ucalgary.ca Sat Jun 24 17:04:18 2000 From: nascheme@enme.ucalgary.ca (Neil Schemenauer) Date: Sat, 24 Jun 2000 10:04:18 -0600 Subject: [Python-Dev] test failures... In-Reply-To: ; from tim_one@email.msn.com on Fri, Jun 23, 2000 at 10:41:23PM -0400 References: <20000623191923.A25730@activestate.com> Message-ID: <20000624100418.A20411@acs.ucalgary.ca> On Fri, Jun 23, 2000 at 10:41:23PM -0400, Tim Peters wrote: > The first step in test failures like this is to recompile with > optimization off. Mandrake is known for shipping bad compilers. They used to ship pgcc as the default compiler even though it was know to have a lot of problems. Neil From tim_one@email.msn.com Sat Jun 24 18:27:19 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sat, 24 Jun 2000 13:27:19 -0400 Subject: [Python-Dev] test failures... In-Reply-To: <14676.11968.263924.752216@beluga.mojam.com> Message-ID: [Skip Montanaro] > Turning off optimization got rid of the test_types and test_long failures. > The test_exceptins failure remains. Bingo, and Guido pinned test_exceptions on Jeremy. You can likely get a usable Python by disabling optimization only for longobject.c, if for some reason you need to stick with that compiler. > As for the age of my gcc, I think I'm reasonably current (only a > bit over a year old): > > % gcc -v > Reading specs from > /usr/lib/gcc-lib/i686-pc-linux-gnu/pgcc-2.91.66/specs > gcc version pgcc-2.91.66 19990314 (egcs-1.1.2 release) Well, I haven't had need of following the gcc/egcs soap opera, but I think "a year" (& particularly the last one ) is a lifetime in that saga. "2.95" rings a vague bell, as the only compiler in that line my former employer felt was usable for their development work under Linux. unlike-python-so-far-they've-had-some-bad-releases-ly y'rs - tim From tim_one@email.msn.com Sat Jun 24 18:30:54 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sat, 24 Jun 2000 13:30:54 -0400 Subject: [Python-Dev] atexit.py patch In-Reply-To: <14676.3723.916135.602@beluga.mojam.com> Message-ID: [Skip] > I'm only sending this to python-dev, operating under the > assumption that the patches list is about to take a long vacation... Skip, if you can't put it on SourceForge for some reason (like what?), the patches list is certainly better than python-dev! I've got enough to do trying to disentangle multi-megabytes of patches-list archives that I'm not going to expand my search to other archives (like python-dev) too. From gstein@lyra.org Sat Jun 24 18:39:34 2000 From: gstein@lyra.org (Greg Stein) Date: Sat, 24 Jun 2000 10:39:34 -0700 Subject: [Python-Dev] test failures... In-Reply-To: ; from tim_one@email.msn.com on Sat, Jun 24, 2000 at 01:27:19PM -0400 References: <14676.11968.263924.752216@beluga.mojam.com> Message-ID: <20000624103934.Y29590@lyra.org> On Sat, Jun 24, 2000 at 01:27:19PM -0400, Tim Peters wrote: > [Skip Montanaro] > > Turning off optimization got rid of the test_types and test_long failures. > > The test_exceptins failure remains. > > Bingo, and Guido pinned test_exceptions on Jeremy. You can likely get a > usable Python by disabling optimization only for longobject.c, if for some > reason you need to stick with that compiler. Euh... shouldn't we insert some defensive code into longobject.c? Great, Skip knows to disable opt for that file... what about all the other people? Cheers, -g -- Greg Stein, http://www.lyra.org/ From tim_one@email.msn.com Sat Jun 24 18:42:29 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sat, 24 Jun 2000 13:42:29 -0400 Subject: [Python-Dev] Patch management In-Reply-To: <20000623073002.B9385@newcnri.cnri.reston.va.us> Message-ID: [Andrew Kuchling] > ... > So, I no longer have much of a problem with moving patches to SF, > though I *still* think the mailing list would be sufficient with a bit > more focused effort; sorry, Tim! "Do something" to supply that focus on this mailing list, and then I can stop bothering with the move. That would be great. But repeating that if the list worked, it wouldn't be broken <0.7 wink>, has not proven sufficient to fix it. > But at least we're not going to burn weeks looking at different patch > manager products, and then arguing about them, which is what I feared > most. Same here. well-actually-the-radio-on-the-drive-down-to-va-got-me-more-worried- about-lyme-disease-ly y'rs - tim From tim_one@email.msn.com Sat Jun 24 18:51:14 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sat, 24 Jun 2000 13:51:14 -0400 Subject: [Python-Dev] test failures... In-Reply-To: <20000624103934.Y29590@lyra.org> Message-ID: [Greg Stein] > Euh... shouldn't we insert some defensive code into longobject.c? Great, > Skip knows to disable opt for that file... what about all the > other people? Don't understand what you want to see. The compiler in question is both broken & old. At most I'd put a note in one of the readmes saying so. From fdrake@beopen.com Sat Jun 24 22:19:50 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Sat, 24 Jun 2000 14:19:50 -0700 (PDT) Subject: [Python-Dev] updated exit.py and supporting files for your perusal In-Reply-To: References: <200006232008.PAA02759@cj20424-a.reston1.va.home.com> Message-ID: <14677.9718.880695.265962@mailhost.beopen.com> Ka-Ping Yee writes: > Sorry to confuddle things, but what happened to the idea of > sticking it in "sys"? If sys.exitfunc lives there, doesn't > sys.atexit(...) also make sense? It can't be very hard to do... I'd be happy with this as well, but I don't think it's required to do it that way. -Fred -- Fred L. Drake, Jr. From gstein@lyra.org Sat Jun 24 23:18:24 2000 From: gstein@lyra.org (Greg Stein) Date: Sat, 24 Jun 2000 15:18:24 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils util.py,1.36,1.37 In-Reply-To: <200006242040.NAA28315@slayer.i.sourceforge.net>; from gward@users.sourceforge.net on Sat, Jun 24, 2000 at 01:40:05PM -0700 References: <200006242040.NAA28315@slayer.i.sourceforge.net> Message-ID: <20000624151824.A29590@lyra.org> Would the "shlex" module be helpful here? It is in the standard library and is (well?) maintained by ESR. It could help reduce the code inside distutils. [ I've always questioned the need for distutils' own "copy file" functions and whatnot... seems there is a bit of duplication occurring... ] Cheers, -g On Sat, Jun 24, 2000 at 01:40:05PM -0700, Greg Ward wrote: > Update of /cvsroot/python/distutils/distutils > In directory slayer.i.sourceforge.net:/tmp/cvs-serv28287 > > Modified Files: > util.py > Log Message: > Added 'split_quoted()' function to deal with strings that are quoted in > Unix shell-like syntax (eg. in Python's Makefile, for one thing -- now that > I have this function, I'll probably allow quoted strings in config files too. > > Index: util.py > =================================================================== > RCS file: /cvsroot/python/distutils/distutils/util.py,v > retrieving revision 1.36 > retrieving revision 1.37 > diff -C2 -r1.36 -r1.37 > *** util.py 2000/06/18 15:45:55 1.36 > --- util.py 2000/06/24 20:40:02 1.37 > *************** > *** 167,168 **** > --- 167,235 ---- > > return error > + > + > + # Needed by 'split_quoted()' > + _wordchars_re = re.compile(r'[^\\\'\"\ ]*') > + _squote_re = re.compile(r"'(?:[^'\\]|\\.)*'") > + _dquote_re = re.compile(r'"(?:[^"\\]|\\.)*"') > + > + def split_quoted (s): > + """Split a string up according to Unix shell-like rules for quotes and > + backslashes. In short: words are delimited by spaces, as long as those > + spaces are not escaped by a backslash, or inside a quoted string. > + Single and double quotes are equivalent, and the quote characters can > + be backslash-escaped. The backslash is stripped from any two-character > + escape sequence, leaving only the escaped character. The quote > + characters are stripped from any quoted string. Returns a list of > + words. > + """ > + > + # This is a nice algorithm for splitting up a single string, since it > + # doesn't require character-by-character examination. It was a little > + # bit of a brain-bender to get it working right, though... > + > + s = string.strip(s) > + words = [] > + pos = 0 > + > + while s: > + m = _wordchars_re.match(s, pos) > + end = m.end() > + if end == len(s): > + words.append(s[:end]) > + break > + > + if s[end] == ' ': # unescaped, unquoted space: now > + words.append(s[:end]) # we definitely have a word delimiter > + s = string.lstrip(s[end:]) > + pos = 0 > + > + elif s[end] == '\\': # preserve whatever is being escaped; > + # will become part of the current word > + s = s[:end] + s[end+1:] > + pos = end+1 > + > + else: > + if s[end] == "'": # slurp singly-quoted string > + m = _squote_re.match(s, end) > + elif s[end] == '"': # slurp doubly-quoted string > + m = _dquote_re.match(s, end) > + else: > + raise RuntimeError, \ > + "this can't happen (bad char '%c')" % s[end] > + > + if m is None: > + raise ValueError, \ > + "bad string (mismatched %s quotes?)" % s[end] > + > + (beg, end) = m.span() > + s = s[:beg] + s[beg+1:end-1] + s[end:] > + pos = m.end() - 2 > + > + if pos >= len(s): > + words.append(s) > + break > + > + return words > + > + # split_quoted () > > > _______________________________________________ > Python-checkins mailing list > Python-checkins@python.org > http://www.python.org/mailman/listinfo/python-checkins -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Sat Jun 24 23:50:23 2000 From: gstein@lyra.org (Greg Stein) Date: Sat, 24 Jun 2000 15:50:23 -0700 Subject: [Python-Dev] test failures... In-Reply-To: ; from tim_one@email.msn.com on Sat, Jun 24, 2000 at 01:51:14PM -0400 References: <20000624103934.Y29590@lyra.org> Message-ID: <20000624155023.B29590@lyra.org> On Sat, Jun 24, 2000 at 01:51:14PM -0400, Tim Peters wrote: > [Greg Stein] > > Euh... shouldn't we insert some defensive code into longobject.c? Great, > > Skip knows to disable opt for that file... what about all the > > other people? > > Don't understand what you want to see. The compiler in question is both > broken & old. At most I'd put a note in one of the readmes saying so. The compiler Skip quoted was pgcc-2.91.66. The "pgcc" part may have introduced the problem, but my RedHat 6.2 (i.e. the LATEST) has the following: Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) Maybe 2.91.66 is "old" but that is the compiler being shipped on RedHat 6.2. Having said that, I bet the pgcc people messed up the compiler :-). I set -O9 on my box and recompiled longobject.c. It wouldn't reproduce the problem. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gmcm@hypernet.com Sun Jun 25 00:01:05 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Sat, 24 Jun 2000 19:01:05 -0400 Subject: [Python-Dev] test failures... In-Reply-To: References: <14676.11968.263924.752216@beluga.mojam.com> Message-ID: <1250234786-20097552@hypernet.com> Tim "The Windows Guy" Peters wrote: > [Skip Montanaro] > > /usr/lib/gcc-lib/i686-pc-linux-gnu/pgcc-2.91.66/specs > > gcc version pgcc-2.91.66 19990314 (egcs-1.1.2 release) > > Well, I haven't had need of following the gcc/egcs soap opera, > but I think "a year" (& particularly the last one ) is a > lifetime in that saga. gcc 2.90 (egcs 1.0.3) that came with RH 5.2 was broken - but got fixed by rebuilding it from source. - Gordon From gstein@lyra.org Sun Jun 25 09:40:23 2000 From: gstein@lyra.org (Greg Stein) Date: Sun, 25 Jun 2000 01:40:23 -0700 Subject: [Python-Dev] [rasmus@apache.org: Re: PMCs and Apache] Message-ID: <20000625014023.D29590@lyra.org> Woah... this is an interesting factoid about the number of committers for a project. I had no idea PHP had this many... Can this work with Python? Dunno. I think if a "true core" group pays attention to the -checkins alias, then yah. If that review is ever lost, then those "edge" committers could introduce crap. I'm not asking for more committers to Python. But if some people were worried about the "explosion" of committers from about six a couple months ago to the current 13, then just look to PHP and count your thanks :-) Mostly, this email is for pondering... Cheers, -g ----- Forwarded message from Rasmus Lerdorf ----- Reply-To: members@apache.org Date: Sat, 24 Jun 2000 20:52:01 -0700 (PDT) From: Rasmus Lerdorf To: members@apache.org Subject: Re: PMCs and Apache > More relevant is the process by which I became a contributor. For PHP, I > sent a note describing what I was exploring, and I was sent a note with a > password. I didn't know CVS. I didn't know PHP. I didn't know open > source. But like a stranger offering to help at a barn raising, I was > simply handed a hammer and expected to get busy. That has always been the atmosphere. It isn't quite as free as that. We get 10-20 cvs write account requests every week and tend to only hand out 1 or 2 actual accounts. There are a lot of clueless people out there. However, if the person has shown any sign of being competent by explaining in a rational manner what they plan on working on, I see no reason not to let them bash away. Reversing somebodys' changes and removing a cvs account is trivial, and in the past 5 years we have yet to revoke an account. We have reversed changes of course, but even that doesn't happen too often. There are currently 165 people with write access to the PHP source tree. This does also relate to the fact that the PHP project is a very broad project. No single person could possibly know all 16 supported low-level database apis, for example. For other projects with a much more limited scope, this approach is probably not optimal, but for PHP it works nicely. Someone will write a bit of broken code that shows some good ideas, and others will pounce on it and fix it. Often the people who fix it are poor sods who tried to use the broken feature and had to dive in and fix it themselves. They request a cvs account to do this, and they are hooked. They tend to never stop at fixing just one thing once they have been given the golden keys. This approach has also done wonders for the PHP documentation. The current manual is around 1100 pages long and has been fully translated to German, Italian and Japanese with more languages on the way. (check out http://snaps.php.net/manual/) -Rasmus ----- End forwarded message ----- -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Mon Jun 26 00:20:43 2000 From: gstein@lyra.org (Greg Stein) Date: Sun, 25 Jun 2000 16:20:43 -0700 Subject: [Python-Dev] Python/Apache stuff (was: Re: [XML-SIG] speed question re DOM parsing) In-Reply-To: <200006251540.JAA13556@localhost.localdomain>; from uogbuji@fourthought.com on Sun, Jun 25, 2000 at 09:40:59AM -0600 References: <200006251540.JAA13556@localhost.localdomain> Message-ID: <20000625162043.J29590@lyra.org> On Sun, Jun 25, 2000 at 09:40:59AM -0600, Uche Ogbuji wrote: > Greg Stein: > > When could I get to it? eek. I *will*, but dunno when. It is amazing just > > how much stuff can fall on a person's plate despite having no job :-). I've > > got some layered I/O in Apache, mod_dav integration, a new httplib, imputil > > issues, these qp_xml upgrades, ViewCVS stuff, edna releases, free threading > > changes, Python/Apache integration, and coding for Subversion. Fuggin > > frightening. > > Ooh! Ooh! Can you tell us more about the Python/Apache integration item? > We've been discussing distributing a 4Suite kit bundled with PyApache, but > that package is quite complex and I'm not sure how strongly maintained. Are > you talking about improvements to PyApache? Another approach entirely > (PyApache still has much more overhead than, say mod_perl)? Do you have an > approximate time-line? A project URL? There are several Python/Apache efforts (where Python is embedded into the Apache process): *) PyApache: essentially this is just a CGI accelerator. Take a standard CGI script and it will "run faster." (URL? dunno) *) mod_python: similar to mod_perl. Built for Apache 1.3. Despite its version 2.4, it is still a bit rough. I've been working with the author to improve the code. I did a code review a while back with a lot of suggestions. It is reasonable, but not as mature as mod_perl. http://www.modpython.org/ *) mod_snake: obvious misnomer :-). This is a module built for Apache 2.0, with the intent of making use of Apache 2.0's threadedness (plus a few of A2's other internal features). The code is very good looking. - available at SourceForge *) mod_slimpy: my name for an Apache 2.0 module which will be even lighter weight than mod_snake. There will be only the slimmest layer of C code to interface Apache and Python. Most/all operational logic will be deferred to the Python side. I've used this design to good effect in some of the Python/COM work and its univgw package in particular. Obviously, the latter two will compete, but oh well :-). The first two fit their problem environment without particular complications. When I start the mod_slimpy work, I'm also going to push on setting up python.apache.org. Essentially, it will host (under the ASF umbrella) the mod_slimpy work plus any other efforts that may want to operate there. I'm going to ask the authors of the other packages whether they would like to be hosted there, too. Of course, python.apache.org can host any Python project. It doesn't have to be related to the web server, or any other ASF project for that matter. Consider all the non-web stuff that operates under xml.apache.org, java.apache.org, and jakarta.apache.org. Cheers, -g -- Greg Stein, http://www.lyra.org/ From Vladimir.Marangozov@inrialpes.fr Mon Jun 26 12:33:56 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Mon, 26 Jun 2000 13:33:56 +0200 (CEST) Subject: [Python-Dev] Fw: Access violation when no memory In-Reply-To: from "Mark Hammond" at Jun 20, 2000 09:42:53 PM Message-ID: <200006261133.NAA03073@python.inrialpes.fr> Mark Hammond wrote: > > >From the newsgroup. Any thoughts? > > Mark. > > "Phil Mayes" wrote in message > news:... > > The following program progressively allocates all memory: > > size = 1 << 20 > > list = [None,] > > while size: > > try: > > mem = [None] * size > > mem[0] = list > > list = mem > > except: > > size = size / 2 > > > > It fails with an access violation. (Turn off virtual memory > > to provoke it.) I had a closer look at this report. It revealed a buglet in Instance_New and raises a question on how to handle the possible NULL values pushed on the stack in ceval.c, at the exception handling code block: > > 3. the NULL pointer at tb is pushed here: > > ceval.c line 1816: PUSH(tb); > > ceval.c line 1817: PUSH(val); > > ceval.c line 1818: PUSH(exc); 1. In PyInstance_New, when the inst->in_dict allocation fails, there's a DECREF(inst) which triggers the instance_dealloc function. The latter goes on checking whether __del__ is defined in the instance's dict (by calling getattr2) whithout checking first whether inst->in_dict is not NULL. I.e. the dealloc_function assumes the instance has been initialized successfully. The net effect is a segfault in PyDict_GetItem which is called with a NULL dict. There are two possible fixes, and I'm not sure which one is better: a) Fix the Instance_New code, by freeing the instance on inst->in_dict allocation failure (without decref'ing the instance). b) Fix the dealloc code, by checking whether in_dict is not NULL before proceeding with the __del__ finalization logic. Opinions? 2. In ceval.c, there are indeed cases where 'tb' and 'exc' are NULL on low-memory conditions. They are pushed on the stack, then popped with a segfault. The only reasonable behavior I get, after some testing, is by setting the tb and exc to Py_None if any of them is NULL before pushing them onto the stack. The program succeeds or the process is killed by the OS (tested on Linux). However, I'm not sure that setting tb and/or exc to Py_None, if NULL, makes any sense and won't cause side effects. Any other suggestions? -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From guido@python.org Mon Jun 26 15:49:11 2000 From: guido@python.org (Guido van Rossum) Date: Mon, 26 Jun 2000 09:49:11 -0500 Subject: [Python-Dev] Let's use the SourceForge Patch Manager In-Reply-To: Your message of "Fri, 23 Jun 2000 10:03:41 +0200." <395319DD.F2584321@lemburg.com> References: <395319DD.F2584321@lemburg.com> Message-ID: <200006261449.JAA01684@cj20424-a.reston1.va.home.com> It's official: I've changed the patch submission guidelines (http://www.python.org/patches/) to point to the patch manager at SourceForge. We are no longer bound by CNRI's legal department, so the requirement for disclaimers or wet signatures is gone. We'll have to see how it works in practice. I've set the address where new patches are mailed to patches@python.org; this should send notifications to the patches list. We could change this to python-dev perhaps, so we can retire the patches address completely (giving it an auto-respond pointing to the SF patch manager, as barry suggested). There are several tasks to be assigned now: we need a triage person who should go through the list of new patches regularly to assign them to developers; we need developers who are willing to have patches assigned to them. We also need a consensus process to decide which patches will be allowed through. I'm hoping to experiment with SF in the coming days to come up with something. Finally, we still need to do something about the existing backlog of patches. The PythonLabs team will try to do something reasonable here. This is not the end -- it's the beginning! --Guido van Rossum (home page: http://www.python.org/~guido/) From jack@oratrix.nl Mon Jun 26 15:29:05 2000 From: jack@oratrix.nl (Jack Jansen) Date: Mon, 26 Jun 2000 16:29:05 +0200 Subject: [Python-Dev] [rasmus@apache.org: Re: PMCs and Apache] In-Reply-To: Message by Greg Stein , Sun, 25 Jun 2000 01:40:23 -0700 , <20000625014023.D29590@lyra.org> Message-ID: <20000626142906.1DDBD37186E@snelboot.oratrix.nl> > Woah... this is an interesting factoid about the number of committers for a > project. I had no idea PHP had this many... > > Can this work with Python? Dunno. I think if a "true core" group pays > attention to the -checkins alias, then yah. If that review is ever lost, > then those "edge" committers could introduce crap. This is one of the reasons I never asked for committer status: the fewer people doing commits the better. I can live with the <2days delay we had upto recently, and for now I'm expecting it to go down to that again after all the turmoil is over. -- 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 guido@python.org Mon Jun 26 16:43:38 2000 From: guido@python.org (Guido van Rossum) Date: Mon, 26 Jun 2000 10:43:38 -0500 Subject: [Python-Dev] [rasmus@apache.org: Re: PMCs and Apache] In-Reply-To: Your message of "Mon, 26 Jun 2000 16:29:05 +0200." <20000626142906.1DDBD37186E@snelboot.oratrix.nl> References: <20000626142906.1DDBD37186E@snelboot.oratrix.nl> Message-ID: <200006261543.KAA02198@cj20424-a.reston1.va.home.com> [Jack Jansen] > This is one of the reasons I never asked for committer status: the > fewer people doing commits the better. I can live with the <2days > delay we had upto recently, and for now I'm expecting it to go down > to that again after all the turmoil is over. Actually, I'd be glad to give you committer status (your colleague Sjoerd just got his :-). I expect that the majority of the subscribers to python-dev can be trusted as committers. I fully expect that most committers won't be committing much -- I don't expect a frenzy of work by committers on the source tree. However the committer status offloads the responsibility of applying the patches you submit after they have been approved -- you can now do it yourself. Less work for me and the others here at PythonLabs! BTW, I would heartily recommend putting the Macintosh tree for Python under SourceForge! --Guido van Rossum (home page: http://www.python.org/~guido/) From mal@lemburg.com Mon Jun 26 16:03:30 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 26 Jun 2000 17:03:30 +0200 Subject: [Python-Dev] Let's use the SourceForge Patch Manager References: <395319DD.F2584321@lemburg.com> <200006261449.JAA01684@cj20424-a.reston1.va.home.com> Message-ID: <395770C2.B903724A@lemburg.com> Guido van Rossum wrote: > > It's official: I've changed the patch submission guidelines > (http://www.python.org/patches/) to point to the patch manager at > SourceForge. We are no longer bound by CNRI's legal department, so > the requirement for disclaimers or wet signatures is gone. > > We'll have to see how it works in practice. I've set the address > where new patches are mailed to patches@python.org; this should send > notifications to the patches list. We could change this to python-dev > perhaps, so we can retire the patches address completely (giving it an > auto-respond pointing to the SF patch manager, as barry suggested). Will there be a list which gets the patches mailed to it by SF ? I'm just asking because the current setup of having the patches available through mail really helps in discussing patch details. > There are several tasks to be assigned now: we need a triage person > who should go through the list of new patches regularly to assign them > to developers; we need developers who are willing to have patches > assigned to them. I'll volunteer for the Unicode side of things :-) > We also need a consensus process to decide which patches will be > allowed through. I'm hoping to experiment with SF in the coming days > to come up with something. > > Finally, we still need to do something about the existing backlog of > patches. The PythonLabs team will try to do something reasonable > here. > > This is not the end -- it's the beginning! -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From jack@oratrix.nl Mon Jun 26 16:13:54 2000 From: jack@oratrix.nl (Jack Jansen) Date: Mon, 26 Jun 2000 17:13:54 +0200 Subject: [Python-Dev] [rasmus@apache.org: Re: PMCs and Apache] In-Reply-To: Message by Guido van Rossum , Mon, 26 Jun 2000 10:43:38 -0500 , <200006261543.KAA02198@cj20424-a.reston1.va.home.com> Message-ID: <20000626151355.3EF8C37186E@snelboot.oratrix.nl> > Actually, I'd be glad to give you committer status (your colleague > Sjoerd just got his :-). I expect that the majority of the > subscribers to python-dev can be trusted as committers. Oww, grumble grumble... Okay, I'll apply for committer status. So there. > BTW, I would heartily recommend putting the Macintosh tree for Python > under SourceForge! I don't think MacCVS can do ssh authorization, and if I followed the discussion here that is needed, right? But if that hurdle can be taken: fine! -- 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 guido@python.org Mon Jun 26 17:32:37 2000 From: guido@python.org (Guido van Rossum) Date: Mon, 26 Jun 2000 11:32:37 -0500 Subject: [Python-Dev] Let's use the SourceForge Patch Manager In-Reply-To: Your message of "Mon, 26 Jun 2000 17:03:30 +0200." <395770C2.B903724A@lemburg.com> References: <395319DD.F2584321@lemburg.com> <200006261449.JAA01684@cj20424-a.reston1.va.home.com> <395770C2.B903724A@lemburg.com> Message-ID: <200006261632.LAA02506@cj20424-a.reston1.va.home.com> [MAL] > Will there be a list which gets the patches mailed to it > by SF ? > > I'm just asking because the current setup of having the patches > available through mail really helps in discussing patch details. I don't think this feature is part of the SF Patch Manager just yet. You could submit it as a request to the SF PM developers though -- apparently they're still working on it. --Guido van Rossum (home page: http://www.python.org/~guido/) From paul@prescod.net Mon Jun 26 16:43:31 2000 From: paul@prescod.net (Paul Prescod) Date: Mon, 26 Jun 2000 08:43:31 -0700 Subject: [Python-Dev] winreg Message-ID: <39577A23.EF7DE922@prescod.net> [I'm having mail troubles so my response time may be slow...] I've just had a chance to look at the winreg module. I think that it is too low-level. I wrote a wrapper class that I feel is more Pythonic. I'll outline the basic ideas and then if there is interest I'll develop a test suite and send it out for eyeballing by Mark and others. Yes, I am proposing this for 1.6. If we're going to put in a registry module, it should be as Pythonic as possible. First, about Winreg 1: It was perfect when it was part of the win32 package and was supposed to mirror the win32 APIs exactly (for reasons of documentation and familiarity) but as the "standard" Python registry manipulation module it seems too low-level to me. I'm sure Mark would be the first to admit that it isn't very Pythonic. It's more Microsoft-ic. In one part of the docs he says: "this API is lame, lame, lame. Don't use it." :) There are also bogus parameters that Microsoft hasn't got around to assigning values to, undocumented constants and so forth. My favorite is "WHOLE_HIVE_VOLATILE". Winreg 2: The basic idea in the pythonic wrapper is that there are key "objects" rather than just handles. winreg already has a primtive "handle object" but for some reason most of the stuff that would logically be methods are actually functions that take the handle as the first param. Keys can have subkeys. So in winreg 1 you would say: winreg.CreateKey( winreg.CreateKey( winreg.HKEY_LOCAL_MACHINE, "HARDWARE"), "DESCRIPTION" ) now you say: winreg.HKEY_LOCAL_MACHINE.createKey( "HARDWARE").createKey( "DESCRIPTION" ) (you could also use a path syntax in either case) You can get a complete list of existant subkeys with a getSubkeys() method call. This list behaves like a Python mapping and also like a sequence. You can use either string key names or integer ordinal indexes. You can fetch and delete keys based on those indexes: for key in winreg.HKEY_LOCAL_MACHINE.getSubkeys(): dosomething( key ) Before it was something like this: for index in xrange( 0, sys.maxint ): try: dosomething( winreg.EnumKey( index ) ) except WindowsError: break "Values" (in the Microsoft sense) are handled the same basic way. Looping, deleting, etc. is the same. When you fetch a value, you get a (type,value) tuple. Types are objects with properties: typeobj.intval -> 0..10 typeobj.msname -> REG_SZ, REG_SZ_MULTI, ... typeobj.friendlyname -> "String", "Sting List", ... Type coercions are all done by the underlying module (the old winreg) except that I've decided that binary data should be returned as an array.array('c') rather than an 8-bit string. -- Paul Prescod Out of timber so crooked as that which man is made nothing entirely straight can be built. - Immanuel Kant From fdrake@beopen.com Mon Jun 26 17:04:40 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Mon, 26 Jun 2000 09:04:40 -0700 (PDT) Subject: [Python-Dev] Let's use the SourceForge Patch Manager In-Reply-To: <395770C2.B903724A@lemburg.com> References: <395319DD.F2584321@lemburg.com> <200006261449.JAA01684@cj20424-a.reston1.va.home.com> <395770C2.B903724A@lemburg.com> Message-ID: <14679.32536.133849.573542@mailhost.beopen.com> M.-A. Lemburg writes: > Will there be a list which gets the patches mailed to it > by SF ? patches@python.org should get messages of patch manager activity (at least certain actions; not sure which ones yet, but at least additions). > I'm just asking because the current setup of having the patches > available through mail really helps in discussing patch details. Yes! I'd really hate to lose notifications! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake@beopen.com Mon Jun 26 17:04:40 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Mon, 26 Jun 2000 09:04:40 -0700 (PDT) Subject: [Python-Dev] Let's use the SourceForge Patch Manager In-Reply-To: <395770C2.B903724A@lemburg.com> References: <395319DD.F2584321@lemburg.com> <200006261449.JAA01684@cj20424-a.reston1.va.home.com> <395770C2.B903724A@lemburg.com> Message-ID: <14679.32536.133849.573542@mailhost.beopen.com> M.-A. Lemburg writes: > Will there be a list which gets the patches mailed to it > by SF ? patches@python.org should get messages of patch manager activity (at least certain actions; not sure which ones yet, but at least additions). > I'm just asking because the current setup of having the patches > available through mail really helps in discussing patch details. Yes! I'd really hate to lose notifications! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From paul@prescod.net Mon Jun 26 16:43:31 2000 From: paul@prescod.net (Paul Prescod) Date: Mon, 26 Jun 2000 08:43:31 -0700 Subject: [Python-Dev] winreg Message-ID: <39577A23.EF7DE922@prescod.net> [I'm having mail troubles so my response time may be slow...] I've just had a chance to look at the winreg module. I think that it is too low-level. I wrote a wrapper class that I feel is more Pythonic. I'll outline the basic ideas and then if there is interest I'll develop a test suite and send it out for eyeballing by Mark and others. Yes, I am proposing this for 1.6. If we're going to put in a registry module, it should be as Pythonic as possible. First, about Winreg 1: It was perfect when it was part of the win32 package and was supposed to mirror the win32 APIs exactly (for reasons of documentation and familiarity) but as the "standard" Python registry manipulation module it seems too low-level to me. I'm sure Mark would be the first to admit that it isn't very Pythonic. It's more Microsoft-ic. In one part of the docs he says: "this API is lame, lame, lame. Don't use it." :) There are also bogus parameters that Microsoft hasn't got around to assigning values to, undocumented constants and so forth. My favorite is "WHOLE_HIVE_VOLATILE". Winreg 2: The basic idea in the pythonic wrapper is that there are key "objects" rather than just handles. winreg already has a primtive "handle object" but for some reason most of the stuff that would logically be methods are actually functions that take the handle as the first param. Keys can have subkeys. So in winreg 1 you would say: winreg.CreateKey( winreg.CreateKey( winreg.HKEY_LOCAL_MACHINE, "HARDWARE"), "DESCRIPTION" ) now you say: winreg.HKEY_LOCAL_MACHINE.createKey( "HARDWARE").createKey( "DESCRIPTION" ) (you could also use a path syntax in either case) You can get a complete list of existant subkeys with a getSubkeys() method call. This list behaves like a Python mapping and also like a sequence. You can use either string key names or integer ordinal indexes. You can fetch and delete keys based on those indexes: for key in winreg.HKEY_LOCAL_MACHINE.getSubkeys(): dosomething( key ) Before it was something like this: for index in xrange( 0, sys.maxint ): try: dosomething( winreg.EnumKey( index ) ) except WindowsError: break "Values" (in the Microsoft sense) are handled the same basic way. Looping, deleting, etc. is the same. When you fetch a value, you get a (type,value) tuple. Types are objects with properties: typeobj.intval -> 0..10 typeobj.msname -> REG_SZ, REG_SZ_MULTI, ... typeobj.friendlyname -> "String", "Sting List", ... Type coercions are all done by the underlying module (the old winreg) except that I've decided that binary data should be returned as an array.array('c') rather than an 8-bit string. -- Paul Prescod Out of timber so crooked as that which man is made nothing entirely straight can be built. - Immanuel Kant From fdrake@beopen.com Mon Jun 26 16:46:23 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Mon, 26 Jun 2000 08:46:23 -0700 (PDT) Subject: [Python-Dev] Fw: Access violation when no memory In-Reply-To: <200006261133.NAA03073@python.inrialpes.fr> References: <200006261133.NAA03073@python.inrialpes.fr> Message-ID: <14679.31439.11309.105239@mailhost.beopen.com> Vladimir Marangozov writes: > There are two possible fixes, and I'm not sure which one is better: > > a) Fix the Instance_New code, by freeing the instance on inst->in_dict > allocation failure (without decref'ing the instance). I think this is the right one; this *shold* be all that's ever needed, and isolates the check to the cod ethat can experiance failure. > b) Fix the dealloc code, by checking whether in_dict is not NULL > before proceeding with the __del__ finalization logic. This protects against bad C code elsewhere that makes a mess of existing objects by stepping around the API (such as by setting inst->in_dict to NULL). I'm not sure we want to protect against that since it could mask bugs (I doubt anyone would do that deliberatly, so I feel safe calling it a bug!). > Opinions? And for free! So infer what you will about their worth. :) > 2. In ceval.c, there are indeed cases where 'tb' and 'exc' are NULL on > low-memory conditions. They are pushed on the stack, then popped with > a segfault. The only reasonable behavior I get, after some testing, > is by setting the tb and exc to Py_None if any of them is NULL before > pushing them onto the stack. The program succeeds or the process is > killed by the OS (tested on Linux). > > However, I'm not sure that setting tb and/or exc to Py_None, if NULL, > makes any sense and won't cause side effects. This doesn't seem like a situation where you'd be masking some other kind of bug by using Py_None, and it avoids the core dump. Since you're not masking anything, I'd go ahead and use Py_None here. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From esr@thyrsus.com Mon Jun 26 19:01:25 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Mon, 26 Jun 2000 14:01:25 -0400 Subject: [Python-Dev] Now that the man is back... Message-ID: <20000626140125.A3266@thyrsus.com> --k1lZvvs/B4yU6o8G Content-Type: text/plain; charset=us-ascii Guido, can we get these into 1.6? They're needed for the the ncurses extensions I'm working on. -- Eric S. Raymond "This country, with its institutions, belongs to the people who inhabit it. Whenever they shall grow weary of the existing government, they can exercise their constitutional right of amending it or their revolutionary right to dismember it or overthrow it." -- Abraham Lincoln, 4 April 1861 --k1lZvvs/B4yU6o8G Content-Type: application/x-tex Content-Disposition: attachment; filename="libascii.tex" \section{\module{ascii} --- Constants and set-membership functions for ASCII characters.} \declaremodule{standard}{ascii} \modulesynopsis{Constants and set-membership functions for ASCII characters.} \moduleauthor{Eric S. Raymond}{esr@thyrsus.com} \sectionauthor{Eric S. Raymond}{esr@thyrsus.com} \versionadded{1.6} The \module{ascii} module supplies name constants for ASCII characters and functions to test membership in various ASCII character classes. The constants supplied are names for control characters as follows: NUL, SOH, STX, ETX, EOT, ENQ, ACK, BEL, BS, TAB, HT, LF, NL, VT, FF, CR, SO, SI, DLE, DC1, DC2, DC3, DC4, NAK, SYN, ETB, CAN, EM, SUB, ESC, FS, GS, RS, US, SP, DEL. NL and LF are synonyms; so are HT and TAB. The module also supplies the following functions, patterned on those in the standard C library: \begin{funcdesc}{isalnum}{c} Checks for an ASCII alphanumeric character; it is equivalent to isalpha(c) or isdigit(c)) \end{funcdesc} \begin{funcdesc}{isalpha}{c} Checks for an ASCII alphabetic character; it is equivalent to isupper(c) or islower(c)) \end{funcdesc} \begin{funcdesc}{isascii}{c} Checks for a character value that fits in the 7-bit ASCII set. \end{funcdesc} \begin{funcdesc}{isblank}{c} Checks for an ASCII alphanumeric character; it is equivalent to isalpha(c) or isdigit(c)) \end{funcdesc} \begin{funcdesc}{iscntrl}{c} Checks for an ASCII control character (range 0x00 to 0x1f). \end{funcdesc} \begin{funcdesc}{isdigit}{c} Checks for an ASCII decimal digit, 0 through 9. \end{funcdesc} \begin{funcdesc}{isgraph}{c} Checks for ASCII any printable character except space. \end{funcdesc} \begin{funcdesc}{islower}{c} Checks for an ASCII lower-case character. \end{funcdesc} \begin{funcdesc}{isprint}{c} Checks for any ASCII printable character including space. \end{funcdesc} \begin{funcdesc}{ispunct}{c} Checks for any printable ASCII character which is not a space or an alphanumeric character. \end{funcdesc} \begin{funcdesc}{isspace}{c} Checks for ASCII white-space characters; space, tab, line feed, carriage return, form feed, horizontal tab, vertical tab. \end{funcdesc} \begin{funcdesc}{isupper}{c} Checks for an ASCII uppercase letter. \end{funcdesc} \begin{funcdesc}{isxdigit}{c} Checks for an ASCII hexadecimal digit, i.e. one of 0123456789abcdefABCDEF. \end{funcdesc} \begin{funcdesc}{isctrl}{c} Checks for an ASCII control character, bit values 0 to 31. \end{funcdesc} \begin{funcdesc}{ismeta}{c} Checks for a (non-ASCII) character, bit values 0x80 and above. \end{funcdesc} These functions accept either integers or strings; when the argument is a string, it is first converted using the built-in function ord(). Note that all these functions check ordinal bit values derived from the first character of the string you pass in; they do not actually know anything about the host machine's character encoding. For functions that know about the character encoding (and handle internationalization properly) see the string module. The following two functions take either a single-character string or integer byte value; they return a value of the same type. \begin{funcdesc}{ascii}{c} Return the ASCII value corresponding to the low 7 bits of c. \end{funcdesc} \begin{funcdesc}{ctrl}{c} Return the control character corresponding to the given character (the character bit value is logical-anded with 0x1f). \end{funcdesc} \begin{funcdesc}{alt}{c} Return the 8-bit character corresponding to the given ASCII character (the character bit value is logical-ored with 0x80). \end{funcdesc} The following function takes either a single-character string or integer byte value; it returns a string. \begin{funcdesc}{unctrl}{c} Return a string representation of the ASCII character c. If c is printable, this string is the character itself. If the character is a control character (0x00-0x1f) the string consists of a caret (^) followed by the corresponding uppercase letter. If the character is an ASCII delete (0x7f) the string is "^?". If the character has its meta bit (0x80) set, the meta bit is stripped, the preceding rules applied, and "!" prepended to the result. \end{funcdesc} Finally, the module supplies a 33-element string array called controlnames that contains the ASCII mnemonics for the thirty-two ASCII control characters from 0 (NUL) to 0x1f (US), in order, plus the mnemonic "SP" for space. --k1lZvvs/B4yU6o8G Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ascii.py" # # ascii.py -- constants and memembership tests for ASCII characters # NUL = 0x00 # ^@ SOH = 0x01 # ^A STX = 0x02 # ^B ETX = 0x03 # ^C EOT = 0x04 # ^D ENQ = 0x05 # ^E ACK = 0x06 # ^F BEL = 0x07 # ^G BS = 0x08 # ^H TAB = 0x09 # ^I HT = 0x09 # ^I LF = 0x0a # ^J NL = 0x0a # ^J VT = 0x0b # ^K FF = 0x0c # ^L CR = 0x0d # ^M SO = 0x0e # ^N SI = 0x0f # ^O DLE = 0x10 # ^P DC1 = 0x11 # ^Q DC2 = 0x12 # ^R DC3 = 0x13 # ^S DC4 = 0x14 # ^T NAK = 0x15 # ^U SYN = 0x16 # ^V ETB = 0x17 # ^W CAN = 0x18 # ^X EM = 0x19 # ^Y SUB = 0x1a # ^Z ESC = 0x1b # ^[ FS = 0x1c # ^\ GS = 0x1d # ^] RS = 0x1e # ^^ US = 0x1f # ^_ SP = 0x20 # space DEL = 0x7f # delete controlnames = [ "NUL", "SOH", "STX", "ETX", "EOT", "ENQ", "ACK", "BEL", "BS", "HT", "LF", "VT", "FF", "CR", "SO", "SI", "DLE", "DC1", "DC2", "DC3", "DC4", "NAK", "SYN", "ETB", "CAN", "EM", "SUB", "ESC", "FS", "GS", "RS", "US", "SP" ] def _ctoi(c): if type(c) == type(""): return ord(c) else: return c def isalnum(c): return isalpha(c) or isdigit(c) def isalpha(c): return isupper(c) or islower(c) def isascii(c): return _ctoi(c) <= 127 # ? def isblank(c): return _ctoi(c) in (8,32) def iscntrl(c): return _ctoi(c) <= 31 def isdigit(c): return _ctoi(c) >= 48 and _ctoi(c) <= 57 def isgraph(c): return _ctoi(c) >= 33 and _ctoi(c) <= 126 def islower(c): return _ctoi(c) >= 97 and _ctoi(c) <= 122 def isprint(c): return _ctoi(c) >= 32 and _ctoi(c) <= 126 def ispunct(c): return _ctoi(c) != 32 and not isalnum(c) def isspace(c): return _ctoi(c) in (12, 10, 13, 9, 11) def isupper(c): return _ctoi(c) >= 65 and _ctoi(c) <= 90 def isxdigit(c): return isdigit(c) or \ (_ctoi(c) >= 65 and _ctoi(c) <= 70) or (_ctoi(c) >= 97 and _ctoi(c) <= 102) def isctrl(c): return _ctoi(c) < 32 def ismeta(c): return _ctoi(c) > 127 def ascii(c): if type(c) == type(""): return chr(_ctoi(c) & 0x7f) else: return _ctoi(c) & 0x7f def ctrl(c): if type(c) == type(""): return chr(_ctoi(c) & 0x1f) else: return _ctoi(c) & 0x1f def alt(c): if type(c) == type(""): return chr(_ctoi(c) | 0x80) else: return _ctoi(c) | 0x80 def unctrl(c): bits = _ctoi(c) if bits == 0x7f: rep = "^?" elif bits & 0x20: rep = chr((bits & 0x7f) | 0x20) else: rep = "^" + chr(((bits & 0x7f) | 0x20) + 0x20) if bits & 0x80: return "!" + rep return rep --k1lZvvs/B4yU6o8G-- From tpeters@beopen.com Mon Jun 26 19:41:12 2000 From: tpeters@beopen.com (Tim Peters) Date: Mon, 26 Jun 2000 14:41:12 -0400 Subject: [Python-Dev] RE: [Patches] Let's use the SourceForge Patch Manager In-Reply-To: <200006261449.JAA01684@cj20424-a.reston1.va.home.com> Message-ID: [Guido] > It's official: I've changed the patch submission guidelines > (http://www.python.org/patches/) to point to the patch manager at > SourceForge. We are no longer bound by CNRI's legal department, so > the requirement for disclaimers or wet signatures is gone. Yay! Wonder how long that will last . Attached is a first cut at documenting the intended use of SourceForge's patch status tags, and the workflow associated with patch status changes. The areas in need of fleshing out are marked with "[xxx ...]". Gripe at will. I don't think anyone expects this to work smoothly at first. Strive for patience, and let's work to make SF a really *good* place for patches! never-thought-i'd-actually-miss-lotus-notes-ly y'rs - tim PS: I'll move this (& related info) to a reasonable place eventually, so don't bother griping about email for now. Intended use of SourceForge patch status tags --------------------------------------------- revision 1 26-Jun-2000 Open The initial status of all patches. The patch is under consideration, but has not been reviewed yet. The status will normally change to Accepted or Rejected next. The person submitting the patch should (if they can) assign it to the person they most want to review it. Else the patch will be assigned via [xxx a list of expertise areas should be developed] Discussion of patches is carried out via [xxx Python-Dev? patches list? without a mail gateway, the SourceForge patch interface looks too clumsy to use for controversial patches] Accepted The powers that be have accepted the patch, but it has not been applied yet. [xxx flesh out -- Guido Bottleneck avoidable here?] The status will normally change to Closed next. The person changing the status to Accepted should, at the same time, assign the patch to whoever they believe is most likely to be able & willing to apply it (the submitter if possible). Closed The patch has been accepted and applied. The previous status was Accepted, or possibly Open if the submitter was Guido (or moral equivalent in some particular area of expertise). If possible, the submitter should apply the patch and change the status to Closed. Else anyone with sufficient power should feel encouraged to do these on the submitter's behalf. Rejected The patch has been reviewed and rejected. When the objections are addressed, the status may change to Open again. Note that SourceForge allows the submitter to overwrite the patch with a new version. Out of date Previous status was Open or Accepted or Postponed, but the patch no longer works. Please enter a comment when changing the status to "Out of date", to record the nature of the problem and the previous status. Postponed The previous status was Open or Accepted, but for some reason (e.g., pending release) the patch should not be reviewed or applied until further notice. The status will normally change to Open or Accepted next. Please enter a comment when changing the status to Postponed, to record the reason, the previous status, and the conditions under which the patch should revert to Open or Accepted. Deleted Bit bucket. Use only if it's OK for the patch and its SourceForge history to disappear. As of 26-June-2000, SF does not actually throw away Deleted patches, but that may change. From DavidA@ActiveState.com Mon Jun 26 20:10:04 2000 From: DavidA@ActiveState.com (David Ascher) Date: Mon, 26 Jun 2000 12:10:04 -0700 Subject: [Python-Dev] semaphore support in thread_*.h Message-ID: I noticed that the support for the semaphore calls in the various thread_* is very very spotty, with a comment in the BeOS implementation that read: * Guido says not to implement this because it's not used anywhere; * I'll do it anyway, you never know when it might be handy, and it's * easy... (that last bit is not true of all implementations, apparently =). 1) Is it true that the sema_ calls are never used? 2) If yes, shouldn't we remove the sema_ calls from the thread API and have similar functionality on all platforms? (There are related issues re: for example whether async thread locking is available, whether threads are joinable or not (see thread_cthread.h), etc.) --david From tpeters@beopen.com Mon Jun 26 20:19:58 2000 From: tpeters@beopen.com (Tim Peters) Date: Mon, 26 Jun 2000 15:19:58 -0400 Subject: [Python-Dev] Let's use the SourceForge Patch Manager In-Reply-To: <395770C2.B903724A@lemburg.com> Message-ID: [MAL] > Will there be a list which gets the patches mailed to it > by SF ? > > I'm just asking because the current setup of having the patches > available through mail really helps in discussing patch details. I agree -- SF isn't (yet) good for patch discussions. Plugging away, but haven't yet figured out exactly when or how SF decides to send email. In particular, don't yet know how (or whether it's possible) to trick current SF into populating a mailing list. From guido@python.org Mon Jun 26 21:24:57 2000 From: guido@python.org (Guido van Rossum) Date: Mon, 26 Jun 2000 15:24:57 -0500 Subject: [Python-Dev] Now that the man is back... In-Reply-To: Your message of "Mon, 26 Jun 2000 14:01:25 -0400." <20000626140125.A3266@thyrsus.com> References: <20000626140125.A3266@thyrsus.com> Message-ID: <200006262024.PAA01212@cj20424-a.reston1.va.home.com> [ESR] > Guido, can we get these into 1.6? They're needed for the the ncurses > extensions I'm working on. Eric, We (PythonLabs + Andrew Kuchling & Greg Ward) discussed this at our recent 1.6 planning meeting. This doesn't have much use outside curses. Therefore, Andrew will check it in as a submodule of the new curses package. --Guido van Rossum (home page: http://www.python.org/~guido/) From fdrake@beopen.com Mon Jun 26 20:24:40 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Mon, 26 Jun 2000 12:24:40 -0700 (PDT) Subject: [Python-Dev] Now that the man is back... In-Reply-To: <20000626140125.A3266@thyrsus.com> References: <20000626140125.A3266@thyrsus.com> Message-ID: <14679.44536.931222.448738@mailhost.beopen.com> Eric S. Raymond writes: > Guido, can we get these into 1.6? They're needed for the the ncurses > extensions I'm working on. This will be the curses.ascii module per a discussion last week which included both Guido and Andrew. Andrew, my Unix machine is down for repairs; can you check these in for me, changing the module name to curses.ascii in the documentation file? I don't want to hold up since Eric is still developing some of the ncurses support. Thanks! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From jeremy@beopen.com Mon Jun 26 20:35:17 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Mon, 26 Jun 2000 15:35:17 -0400 (EDT) Subject: [Python-Dev] Now that the man is back... In-Reply-To: <20000626140125.A3266@thyrsus.com> References: <20000626140125.A3266@thyrsus.com> Message-ID: <14679.45173.439937.800007@bitdiddle.concentric.com> The ascii module is going into the curses package. Andrew Kuchling is responsible for it. Jeremy From esr@thyrsus.com Mon Jun 26 20:46:50 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Mon, 26 Jun 2000 15:46:50 -0400 Subject: [Python-Dev] Now that the man is back... In-Reply-To: <14679.44536.931222.448738@mailhost.beopen.com>; from fdrake@beopen.com on Mon, Jun 26, 2000 at 12:24:40PM -0700 References: <20000626140125.A3266@thyrsus.com> <14679.44536.931222.448738@mailhost.beopen.com> Message-ID: <20000626154650.C3685@thyrsus.com> Fred L. Drake, Jr. : > This will be the curses.ascii module per a discussion last week > which included both Guido and Andrew. OK, I guess. It will be useful for more than curses, though, so I don't understand the naming choice. -- Eric S. Raymond Hoplophobia (n.): The irrational fear of weapons, correctly described by Freud as "a sign of emotional and sexual immaturity". Hoplophobia, like homophobia, is a displacement symptom; hoplophobes fear their own "forbidden" feelings and urges to commit violence. This would be harmless, except that they project these feelings onto others. The sequelae of this neurosis include irrational and dangerous behaviors such as passing "gun-control" laws and trashing the Constitution. From paul@prescod.net Mon Jun 26 20:53:18 2000 From: paul@prescod.net (Paul Prescod) Date: Mon, 26 Jun 2000 12:53:18 -0700 Subject: [Python-Dev] winreg Message-ID: <3957B4AE.5562716C@prescod.net> I haven't seen this message come through: http://www.python.org/pipermail/python-dev/2000-June/006346.html I'm not sure if I missed it due to an email problem. Paul Prescod - Not encumbered by corporate consensus When George Bush entered office, a Washington Post-ABC News poll found that 62 percent of Americans "would be willing to give up a few of the freedoms we have" for the war effort. They have gotten their wish. - "This is your bill of rights...on drugs", Harpers, Dec. 1999 From fdrake@beopen.com Mon Jun 26 20:59:10 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Mon, 26 Jun 2000 12:59:10 -0700 (PDT) Subject: [Python-Dev] Now that the man is back... In-Reply-To: <20000626154650.C3685@thyrsus.com> References: <20000626140125.A3266@thyrsus.com> <14679.44536.931222.448738@mailhost.beopen.com> <20000626154650.C3685@thyrsus.com> Message-ID: <14679.46606.287276.330659@mailhost.beopen.com> Eric S. Raymond writes: > OK, I guess. It will be useful for more than curses, though, so I don't > understand the naming choice. Eric, In theory, yes, but... there have not been a lot of requests for the is*() functions (which are the ones I think you're referring to as generally useful). I think some of these are already take care of by things like "if c in string.hexdigits:", and others can be handled by making queries on the Unicode character properties. Given the dearth of requests for this, I don't see a clear need to place this elsewhere. If feedback to the beta suggests a better location, we'll certainly consider it! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido@python.org Mon Jun 26 22:28:16 2000 From: guido@python.org (Guido van Rossum) Date: Mon, 26 Jun 2000 16:28:16 -0500 Subject: [Python-Dev] semaphore support in thread_*.h In-Reply-To: Your message of "Mon, 26 Jun 2000 12:10:04 MST." References: Message-ID: <200006262128.QAA01518@cj20424-a.reston1.va.home.com> > I noticed that the support for the semaphore calls in the various thread_* > is very very spotty, with a comment in the BeOS implementation that read: > > * Guido says not to implement this because it's not used anywhere; > * I'll do it anyway, you never know when it might be handy, and it's > * easy... > > (that last bit is not true of all implementations, apparently =). > > 1) Is it true that the sema_ calls are never used? > > 2) If yes, shouldn't we remove the sema_ calls from the thread API and have > similar functionality on all platforms? > > (There are related issues re: for example whether async thread locking is > available, whether threads are joinable or not (see thread_cthread.h), etc.) The sema_ calls aren't used anywhere in the current source. I'd be for removing them. I'm not even sure why they are there -- maybe Sjoerd remembers? (This code was once part of something else than Python.) --Guido van Rossum (home page: http://www.python.org/~guido/) From akuchlin@mems-exchange.org Mon Jun 26 22:28:26 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Mon, 26 Jun 2000 17:28:26 -0400 Subject: [Python-Dev] Now that the man is back... In-Reply-To: <14679.44536.931222.448738@mailhost.beopen.com> References: <20000626140125.A3266@thyrsus.com> <14679.44536.931222.448738@mailhost.beopen.com> Message-ID: <20000626172826.E2282@kronos.cnri.reston.va.us> On Mon, Jun 26, 2000 at 12:24:40PM -0700, Fred L. Drake, Jr. wrote: > Andrew, my Unix machine is down for repairs; can you check these in >for me, changing the module name to curses.ascii in the documentation >file? I don't want to hold up since Eric is still developing some of >the ncurses support. I'll do that tonight; I had no time for Python hacking over the weekend... --amk From mhammond@skippinet.com.au Tue Jun 27 01:03:16 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Tue, 27 Jun 2000 10:03:16 +1000 Subject: [Python-Dev] winreg In-Reply-To: <39577A23.EF7DE922@prescod.net> Message-ID: > I've just had a chance to look at the winreg module. I think that it is > too low-level. I agree. There was a proposal (from Thomas Heller, IIRC) to do just this. I successfully argued there should be _2_ modules for Python - the raw low-level API, which guarantees you can do (almost) anything. A higher-level API could cover the 80% of cases. It is probably worth getting in touch with Thomas - he may be able to dig up his proposed high-level API. Ive CCd him on this message [I hope is _was_ you Thomas - otherwise you will be wondering WTF I am on about :] I was very keen to ensure the win32api code was used as the low-level API, simply because it has been well tested and used. We _know_ it has no significant limitations. Im happy to support a high-level API, but didnt have the inclination to provide one. Every one I have seen and every one I have tried to design has started to fall-apart under real-world use - Ive needed to revert back to the low-level. > There are also bogus parameters that Microsoft hasn't got around to > assigning values to, undocumented constants and so forth. My favorite is > "WHOLE_HIVE_VOLATILE". This is exactly my concern with a high-level API - you cant hope to capture all this - especially the undocumented ones - so having a low-level API means you can do anything, even stuff never dreamt of by the high-level designer. I have no real problem with your proposed design, as long as it it written in Python, _using_ the low-level API. It could be called "registry" or I would even be happy for "winreg.pyd" -> "_winreg.pyd" and your new module to be called "winreg.py" Mark. From tpeters@beopen.com Mon Jun 26 23:13:42 2000 From: tpeters@beopen.com (Tim Peters) Date: Mon, 26 Jun 2000 18:13:42 -0400 Subject: [Python-Dev] semaphore support in thread_*.h In-Reply-To: Message-ID: [David Ascher] > I noticed that the support for the semaphore calls in the various thread_* > is very very spotty, with a comment in the BeOS implementation that read: > > * Guido says not to implement this because it's not used anywhere; > * I'll do it anyway, you never know when it might be handy, and it's > * easy... > (that last bit is not true of all implementations, apparently =). > > 1) Is it true that the sema_ calls are never used? Best I can tell, the following sema functions are indeed never used: PyThread_allocate_sema PyThread_free_sema PyThread_down_sema PyThread_up_sema the following #define's are never used: WAIT_SEMA NOWAIT_SEMA and the following non-sema pythread.h functions are not only never used, they're defined only in thread_sgi.h: PyThread_create_key PyThread_delete_key PyThread_set_key_value PyThread_get_key_value > 2) If yes, shouldn't we remove the sema_ calls from the thread > API and have similar functionality on all platforms? +1 from me. If someone wants platform-specific thread functions, they should be in a platform-specific extension module, not messing up the core. > (There are related issues re: for example whether async thread locking is > available, whether threads are joinable or not (see > thread_cthread.h), etc.) Sorry, don't know what you're getting at here (e.g., have any specific line or function of thread_cthread.h in mind?). From fdrake@beopen.com Mon Jun 26 23:25:42 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Mon, 26 Jun 2000 15:25:42 -0700 (PDT) Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager In-Reply-To: References: <14679.32536.133849.573542@mailhost.beopen.com> Message-ID: <14679.55398.996503.269852@mailhost.beopen.com> Tim Peters writes: > Fred, would you please explain how that works or where that was set up? > I've puttered away many hours now playing with the SourceForge facilities From the "project page", go to "Project Admin" on the left navigation bar, then "Edit Public Info" at the top of the page. There are places to edit some email addresses near the bottom of the page. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tpeters@beopen.com Mon Jun 26 22:38:51 2000 From: tpeters@beopen.com (Tim Peters) Date: Mon, 26 Jun 2000 17:38:51 -0400 Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager In-Reply-To: <14679.32536.133849.573542@mailhost.beopen.com> Message-ID: [Fred] > patches@python.org should get messages of patch manager activity (at > least certain actions; not sure which ones yet, but at least > additions). Fred, would you please explain how that works or where that was set up? I've puttered away many hours now playing with the SourceForge facilities (alas, most of that time waiting for web pages to load), but haven't stumbled into anything that hints the patch manager knows anything about patches@python.org. so-stupid-in-so-many-ways-ly y'rs - tim From tpeters@beopen.com Tue Jun 27 00:14:06 2000 From: tpeters@beopen.com (Tim Peters) Date: Mon, 26 Jun 2000 19:14:06 -0400 Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager In-Reply-To: <14679.55398.996503.269852@mailhost.beopen.com> Message-ID: [Fred L. Drake, Jr.] > From the "project page", go to "Project Admin" on the left > navigation bar, then "Edit Public Info" at the top of the page. There > are places to edit some email addresses near the bottom of the page. Aha! The one & only link I had never clicked -- I bet I could have figured that out myself in another week or two . Thank you. Now why do we have "Use Bug Tracker" checked? If nobody objects, I'll turn that off -- we're still doing bugs w/ Jitterbug on python.org. ten-stop-shopping-ly y'rs - tim From guido@beopen.com Tue Jun 27 03:35:52 2000 From: guido@beopen.com (Guido van Rossum) Date: Mon, 26 Jun 2000 21:35:52 -0500 Subject: [Python-Dev] ANN: Release schedule Message-ID: <200006270235.VAA02631@cj20424-a.reston1.va.home.com> Here at BeOpen we're scrambling to get the release schedule for the rest of Python 1.6 planned. We're now looking at releasing Python 1.6b1 (or maybe it's going to be called 1.6a3 after all) on June 30! This means that if SRE isn't ready, we'll go with an incomplete SRE. Still better than no SRE! Please, PLEASE, if you have pending patches that you think should go into 1.6b1, submit them to SourceForge. We'll do our best to have a look at every patch submitted; but don't wait until the last moment. (Trent Mick, it would be helpful if you assigned each of your patches a potential reviewer from the list of existing developers -- that way we can split up the review load.) --Guido van Rossum (home page: http://www.python.org/~guido/) From trentm@activestate.com Tue Jun 27 04:52:59 2000 From: trentm@activestate.com (Trent Mick) Date: Mon, 26 Jun 2000 20:52:59 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test test_pyexpat.py,1.2,1.3 In-Reply-To: <200006270037.RAA25539@slayer.i.sourceforge.net> References: <200006270037.RAA25539@slayer.i.sourceforge.net> Message-ID: <20000626205259.A3866@activestate.com> On Mon, Jun 26, 2000 at 05:37:27PM -0700, A . M . Kuchling wrote: > Update of /cvsroot/python/python/dist/src/Lib/test > In directory slayer.i.sourceforge.net:/tmp/cvs-serv25501 > > Modified Files: > test_pyexpat.py > Log Message: > Change pyexpat test suite to exercise the .returns_unicode attribute, > parsing the sample data once with 8-bit strings and once with Unicode. > Does this require a new Lib/test/output/test_pyexpat? Trent -- Trent Mick trentm@activestate.com From DavidA@ActiveState.com Tue Jun 27 06:34:13 2000 From: DavidA@ActiveState.com (David Ascher) Date: Mon, 26 Jun 2000 22:34:13 -0700 Subject: [Python-Dev] semaphore support in thread_*.h In-Reply-To: Message-ID: > > (There are related issues re: for example whether async thread > locking is > > available, whether threads are joinable or not (see > > thread_cthread.h), etc.) > > Sorry, don't know what you're getting at here (e.g., have any > specific line > or function of thread_cthread.h in mind?). /* looks like solaris detaches the thread to never rejoin * so well do it here */ in thread_cthread.h The async thread locking comment was one of my personal issues -- I considered briefly providing a thread layer on top of the NSPR (Netscape Portable runtime) which is part of Mozilla. It has locks, but no async locking calls. --david From rob@hooft.net Tue Jun 27 10:32:02 2000 From: rob@hooft.net (Rob W. W. Hooft) Date: Tue, 27 Jun 2000 11:32:02 +0200 (CEST) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses ascii.py,NONE,1.1 textpad.py,NONE,1.1 In-Reply-To: <200006262355.QAA17089@slayer.i.sourceforge.net> References: <200006262355.QAA17089@slayer.i.sourceforge.net> Message-ID: <14680.29842.372192.274003@temoleh.chem.uu.nl> AMK> Update of /cvsroot/python/python/dist/src/Lib/curses AMK> In directory slayer.i.sourceforge.net:/tmp/cvs-serv17079 AMK> Added Files: AMK> ascii.py textpad.py AMK> Log Message: AMK> Added two modules for ASCII characters and a simple editing form (ESR) AMK> --- NEW FILE --- AMK> # AMK> # ascii.py -- constants and memembership tests for ASCII characters AMK> # ^^^^^ two letters too much? Rob From gvwilson@nevex.com Tue Jun 27 11:30:55 2000 From: gvwilson@nevex.com (Greg Wilson) Date: Tue, 27 Jun 2000 06:30:55 -0400 (EDT) Subject: [Python-Dev] C# (new language from Microsoft) Message-ID: I'm sure many of you will have seen this announcement already, but for those who haven't, Microsoft is launching a new language to compete with C, C++, and Java: http://msdn.microsoft.com/vstudio/nextgen/technology/csharpintro.asp Greg From Fredrik Lundh" Message-ID: <017501bfe023$684fca40$f2a6b5d4@hagrid> guido wrote: > Here at BeOpen we're scrambling to get the release schedule for the > rest of Python 1.6 planned. We're now looking at releasing Python > 1.6b1 (or maybe it's going to be called 1.6a3 after all) on June 30! > This means that if SRE isn't ready, we'll go with an incomplete SRE. > Still better than no SRE! a major SRE patch is coming up later today. btw, what would it take for me to check it in myself (assuming someone will give me commit privs, of course)? can I apply patches via = sourceforge's web interface, or do I have to figure out how to run cvs over ssh etc = etc (tim? where's the second installment of your sourceforge vs. windows = series?) From gmcm@hypernet.com Tue Jun 27 11:36:07 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Tue, 27 Jun 2000 06:36:07 -0400 Subject: [Python-Dev] winreg In-Reply-To: References: <39577A23.EF7DE922@prescod.net> Message-ID: <1250020276-32999633@hypernet.com> Mark wrote: [Paul] > > I've just had a chance to look at the winreg module. I think > > that it is too low-level. > > I agree. There was a proposal (from Thomas Heller, IIRC) to do > just this. I successfully argued there should be _2_ modules for > Python - the raw low-level API, which guarantees you can do > (almost) anything. A higher-level API could cover the 80% of > cases. It is probably worth getting in touch with Thomas - he > may be able to dig up his proposed high-level API. Found it. ------- Forwarded message follows ------- From: "Thomas Heller" To: , Date sent: Thu, 3 Feb 2000 14:27:00 +0100 Subject: [Python-Dev] Revised proposal (and preliminary implementation): Registry access module for Python on Windows Ok, at least the first proposal did start the discussion. Here is a revised one: A preliminary implementation is available at http://starship.python.net/crew/theller/ ----------------------------------------------------------------- ----- winreg - windows registry access module Exception: error - raised when a function fails. Will contain a windows error code and a textual description. Objects: regnode object - represents a open key in the registry. Functions: OpenKey (name) -> regnode object Opens an existing key with the specified access rights and returns a regnode object. name is specified like "HKLM\Software\Python" or "HKEY_LOCAL_MACHINE\Software\Python" CreateKey (name) -> regnode object Creates a new key or opens an existing one and returns a regnode object. For the name format see OpenKey regnode object methods: Values () -> dict Returns a dictionary mapping names to values. The or unnamed value has the key ''. The values are either strings or integers, depending on the REG_* type. GetValue ([name]) -> integer or string Returns a value specified by name or the default value. SetValue ([name,] value) Set a named or the value. Named values must be integers or string (which are stored as REG_DWORD or REG_SZ). Should an optional third parameter be used, allowing to store in other REG_* typecodes? I dont think so. DeleteValue ([name]) Deletes a named or the value. SubKeys () -> sequence Returns a sequence containing the names of all subkeys. DeleteKey (name [,recursive=0]) If recursive is 0, deletes the named key if no subkeys exist. If there are subkeys an error is raised. If recursive is not 0, the named key is deleted including subkeys. OpenKey (name) -> regnode object Openes an existing subkey and returns a regnode object pointing to it. CreateKey (name) -> regnode object Creates a new or openes an existing subkey and returns a regnode object pointing to it. regnode objects have the following properties: name - the name of the RegistryKey, something like "HKLM\Software\Python" hkey - the integer keyhandle ----------------------------------------------------------------- ----- Thomas Heller _______________________________________________ Python-Dev maillist - Python-Dev@python.org http://www.python.org/mailman/listinfo/python-dev ------- End of forwarded message ------- - Gordon From gstein@lyra.org Tue Jun 27 11:52:02 2000 From: gstein@lyra.org (Greg Stein) Date: Tue, 27 Jun 2000 03:52:02 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses wrapper.py,1.2,1.3 In-Reply-To: <200006270050.RAA26210@slayer.i.sourceforge.net>; from akuchling@users.sourceforge.net on Mon, Jun 26, 2000 at 05:50:42PM -0700 References: <200006270050.RAA26210@slayer.i.sourceforge.net> Message-ID: <20000627035202.M29590@lyra.org> I just don't buy this. Look at that code. Look at the definition of finally. That code simply screams for the use of finally. Eric: just what happens? What is "broke things"? Do you have a reproducible test case that I can use? In good conscience, I have to disagree with reverting this stuff. If we're seeking to make the code the best possible, then this is a backward step. Besides its redundancy, it also places the traceback into a local variable and then raises an exception -- a perfect recipe for creating a ref loop. Cheers, -g On Mon, Jun 26, 2000 at 05:50:42PM -0700, A.M. Kuchling wrote: > Update of /cvsroot/python/python/dist/src/Lib/curses > In directory slayer.i.sourceforge.net:/tmp/cvs-serv26153 > > Modified Files: > wrapper.py > Log Message: > Drop back to old version of wrapper(); ESR reports that it broke things, > and I lack the time to track down the cause. > > > Index: wrapper.py > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Lib/curses/wrapper.py,v > retrieving revision 1.2 > retrieving revision 1.3 > diff -C2 -r1.2 -r1.3 > *** wrapper.py 2000/06/10 23:39:05 1.2 > --- wrapper.py 2000/06/27 00:50:40 1.3 > *************** > *** 18,24 **** > --- 18,26 ---- > """ > > + res = None > try: > # Initialize curses > stdscr=curses.initscr() > + > # Turn off echoing of keys, and enter cbreak mode, > # where no buffering is performed on keyboard input > *************** > *** 30,39 **** > stdscr.keypad(1) > > ! return apply(func, (stdscr,) + rest) > ! > ! finally: > ! # Restore the terminal to a sane state on the way out. > stdscr.keypad(0) > curses.echo() ; curses.nocbreak() > curses.endwin() > > --- 32,51 ---- > stdscr.keypad(1) > > ! res = apply(func, (stdscr,) + rest) > ! except: > ! # In the event of an error, restore the terminal > ! # to a sane state. > stdscr.keypad(0) > curses.echo() ; curses.nocbreak() > curses.endwin() > + > + # Pass the exception upwards > + (exc_type, exc_value, exc_traceback) = sys.exc_info() > + raise exc_type, exc_value, exc_traceback > + else: > + # Set everything back to normal > + stdscr.keypad(0) > + curses.echo() ; curses.nocbreak() > + curses.endwin() # Terminate curses > > + return res > > > _______________________________________________ > Python-checkins mailing list > Python-checkins@python.org > http://www.python.org/mailman/listinfo/python-checkins -- Greg Stein, http://www.lyra.org/ From thomas.heller@ion-tof.com Tue Jun 27 12:09:24 2000 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Tue, 27 Jun 2000 13:09:24 +0200 Subject: [Python-Dev] winreg References: Message-ID: <019601bfe028$281dab90$4500a8c0@thomasnb> > > I've just had a chance to look at the winreg module. I think that it is > > too low-level. > > I agree. There was a proposal (from Thomas Heller, IIRC) to do just this. > I successfully argued there should be _2_ modules for Python - the raw > low-level API, which guarantees you can do (almost) anything. A > higher-level API could cover the 80% of cases. It is probably worth > getting in touch with Thomas - he may be able to dig up his proposed > high-level API. Ive CCd him on this message [I hope is _was_ you Thomas - > otherwise you will be wondering WTF I am on about :] Yes, it was me :-) Here is the 3. (final?) proposal, earlier ones are in the archives: http://www.python.org/pipermail/python-dev/2000-February/003417.html and http://www.python.org/pipermail/python-dev/2000-February/003472.html ---------------------------------------------------------------------- winreg - windows registry access module Exception: error - raised when a function fails. Will contain a windows error code and a textual description. Objects: regkey object - represents a open key in the registry. Functions: OpenKey (name) -> regkey object Opens an existing key with the specified access rights and returns a regkey object. name is specified like "HKLM\Software\Python" or "HKEY_LOCAL_MACHINE\Software\Python" CreateKey (name) -> regkey object Creates a new key or opens an existing one and returns a regkey object. For the name format see OpenKey regkey object methods: Standard Mapping protocol: len (r) r[k] r[k] = x del r[k] r.clear() r.has_key(k) r.items() r.keys() r.update(dict) r.values() r.get(k[, x]) todict() -> dictionary Returns a dictionary mapping value names to values. SubKeys () -> sequence Returns a sequence containing the names of all subkeys. DeleteKey (name [,recursive=0]) If recursive is 0, deletes the named key if no subkeys exist. If there are subkeys an error is raised. If recursive is not 0, the named key is deleted including subkeys. OpenKey (name) -> regkey object Openes an existing subkey and returns a regkey object pointing to it. CreateKey (name) -> regkey object Creates a new or openes an existing subkey and returns a regkey object pointing to it. regkey objects have the following properties: name - the name of the RegistryKey, something like "HKLM\Software\Python" hkey - the integer keyhandle ---------------------------------------------------------------------- It would not be too much work to implement it, but I will be away the next 20 days... > I have no real problem with your proposed design, as long as it it written > in Python, _using_ the low-level API. It could be called "registry" or I > would even be happy for "winreg.pyd" -> "_winreg.pyd" and your new module > to be called "winreg.py" > If we change the name of the low level api module, we have to change Distutils, because it is used there. Maybe we would better use the high level api then, but there is still this 1.5 compatibility using the win32api module. Thomas From guido@beopen.com Tue Jun 27 13:23:36 2000 From: guido@beopen.com (Guido van Rossum) Date: Tue, 27 Jun 2000 07:23:36 -0500 Subject: [Python-Dev] ANN: Release schedule In-Reply-To: Your message of "Tue, 27 Jun 2000 12:35:22 +0200." <017501bfe023$684fca40$f2a6b5d4@hagrid> References: <200006270235.VAA02631@cj20424-a.reston1.va.home.com> <017501bfe023$684fca40$f2a6b5d4@hagrid> Message-ID: <200006271223.HAA01391@cj20424-a.reston1.va.home.com> [effbot] > a major SRE patch is coming up later today. Great! > btw, what would it take for me to check it in myself (assuming someone > will give me commit privs, of course)? can I apply patches via sourceforge's > web interface, or do I have to figure out how to run cvs over ssh etc etc Erm, the latter. From a Unix system it's a breeze. From Windows, it's a relative breeze to do an *anonymous* checkout (no SSH required), but getting commit permission is a pain -- Tim will research this. (Do you have access to any Unix or Linux system at all?) I'll make you a developer anyway. > (tim? where's the second installment of your sourceforge vs. windows series?) I'm waiting too! --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@beopen.com Tue Jun 27 15:30:30 2000 From: guido@beopen.com (Guido van Rossum) Date: Tue, 27 Jun 2000 09:30:30 -0500 Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager In-Reply-To: Your message of "Mon, 26 Jun 2000 17:38:51 -0400." References: Message-ID: <200006271430.JAA01769@cj20424-a.reston1.va.home.com> > [Fred] > > patches@python.org should get messages of patch manager activity (at > > least certain actions; not sure which ones yet, but at least > > additions). [Tim] > Fred, would you please explain how that works or where that was set up? > I've puttered away many hours now playing with the SourceForge facilities > (alas, most of that time waiting for web pages to load), but haven't > stumbled into anything that hints the patch manager knows anything about > patches@python.org. Yes, it's hidden, and Fred had to show me too. First, login to SourceForge. Then, go to the Python Project. In the left sidebar, under Project: Python, go to Project Admin. Near the top, you now see some navigation links; go to Edit Public Info. At the very bottom there are three text fields for email addresses. The address for New Patches (a misnomer -- it's really all changes made to the Patch Manager) says patches@python.org. The address for New Bugs is currently set to guido@beopen.com. I suppose I should set it to pythoneers@beopen.com or even to python-dev@python.org? We're not using the Support manager yet. --Guido van Rossum (home page: http://www.python.org/~guido/) From mhammond@skippinet.com.au Tue Jun 27 15:45:07 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Wed, 28 Jun 2000 00:45:07 +1000 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses wrapper.py,1.2,1.3 In-Reply-To: <20000627035202.M29590@lyra.org> Message-ID: > Besides its redundancy, it also places the traceback into a > local variable > and then raises an exception -- a perfect recipe for creating a ref loop. Isnt it true that _every_ time you store a traceback object as a local variable, and that traceback has a reference to the frame holding the local, you _always_ get a reference loop, regardless of how you exit the function? ie, I believe that _every_ time you store a traceback obtained from inside an except handler, you _always_ get a ref-loop, period. The only way to clean the cycle is to explictly unbind the local from the traceback. Mark. From mhammond@skippinet.com.au Tue Jun 27 15:39:15 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Wed, 28 Jun 2000 00:39:15 +1000 Subject: [Python-Dev] C# (new language from Microsoft) In-Reply-To: Message-ID: I cant say much, as I am still under NDA. However, I probably can say: * C Sharp is really not the interesting part of this technology. MS are controlling the way (the order, really) the information is coming out; as more info comes out, C Sharp should move back into perspective for what is really is. Suffice it to say, hardly anyone on slashdot is even in the ball-park! * The MS PDC in a couple of weeks will be the official announcement of the more interesting things. After this, everyone involved in the project will be completely free to discuss all they know, including me (and a few other Pythoneers) * Python has a very good and interesting story in all this - there is no need to be alarmed. If anything, be excited :-) Mark. > -----Original Message----- > From: python-dev-admin@python.org [mailto:python-dev-admin@python.org]On > Behalf Of Greg Wilson > Sent: Tuesday, 27 June 2000 8:31 PM > To: Python Developers > Subject: [Python-Dev] C# (new language from Microsoft) > > > I'm sure many of you will have seen this announcement already, but for > those who haven't, Microsoft is launching a new language to compete with > C, C++, and Java: > > http://msdn.microsoft.com/vstudio/nextgen/technology/csharpintro.asp > > Greg > > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://www.python.org/mailman/listinfo/python-dev > From paul@prescod.net Tue Jun 27 16:15:29 2000 From: paul@prescod.net (Paul Prescod) Date: Tue, 27 Jun 2000 08:15:29 -0700 Subject: [Python-Dev] winreg References: <019601bfe028$281dab90$4500a8c0@thomasnb> Message-ID: <3958C511.17282EF7@prescod.net> Mark, Thomas and whoever, thanks for your input and I hope you can spare some more... Thomas Heller wrote: > This is similar to what I have implemented... > ---------------------------------------------------------------------- > winreg - windows registry access module > > Exception: > error - raised when a function fails. Will contain > a windows error code and a textual description. As an aside, I notice that the winreg documentation says it will raise an EnvironmentError but it actually raises a WindowsError. > Objects: > regkey object - represents a open key in the > registry. Right. Even the same name. My stance was that keys would always be created from keys, so you would start with HKEY_LOCAL_MACHINE.CreateKey("Software\Python") That mirrors the underlying API a little closer and reduces the number of functions to 0. The question is whether the CreateKey and OpenKey functions are important enough as "convenience functions". > regkey object methods: > Standard Mapping protocol: > len (r) > r[k] > r[k] = x > del r[k] > r.clear() > r.has_key(k) > r.items() > r.keys() > r.update(dict) > r.values() > r.get(k[, x]) I had a separate object for values. I couldn't really justify elevating either the Subkeys or the Values. I tried to treat them as alike as possible. > todict() -> dictionary > Returns a dictionary mapping value names to values. I called this getValues() and it returned an object that was both a mapping and a sequence and allowed read/write/delete of values. > SubKeys () -> sequence > Returns a sequence containing the names of all subkeys. > > DeleteKey (name [,recursive=0]) > If recursive is 0, deletes the named key if no subkeys exist. > If there are subkeys an error is raised. > If recursive is not 0, the named key is deleted > including subkeys. I may or may not get around to implementing the recursive version. You have to be VERY CAREFUL when you test such a thing. :) > OpenKey (name) -> regkey object > Openes an existing subkey and returns a regkey > object pointing to it. Okay. > CreateKey (name) -> regkey object > Creates a new or openes an existing subkey and > returns a regkey object pointing to it. Okay. > regkey objects have the following properties: > name - the name of the RegistryKey, something > like "HKLM\Software\Python" Okay. > hkey - the integer keyhandle Is this really useful? Better to use the low-level API in that case... > If we change the name of the low level api module, we have to change > Distutils, > because it is used there. Maybe we would better use the high level api then, > but there is still this 1.5 compatibility using the win32api module. The high level could probably be made compatible with 1.5 like this: try: import _winreg except ImportError: import win32api winreg=win32api It would probably be good for DistUtils to use the high level API as soon as it is possible for testing purposes. I am considering doing away with the two enumeration interfaces. The cost/benefit of having two more objects is probably low. We can simplify the whole thing by just using methods on the regkey object: deleteValue(name) getValue(name)-> (type, value) setValue(name,(type,value)) getValueNames() -> List of strings getSubkey(name) -> regkey deleteSubkey(name) getSubkeyNames( ) -> List of strings Iterating will be slightly less efficient because it will loop twice, once to gather the names and once to do whatever you need to do but that's not the typical registry use case anyhow. Anyone who needs absolute performance can use the low-level API. Recursive iteration under the existing model: def doit( key ): for subkey in key.getSubkeyNames(): doit( subkey ) Recursive iteration under the proposed model: def doit( key ): for keyname in key.getSubkeyNames(): doit( key.getSubkey( name )) -- Paul Prescod - Not encumbered by corporate consensus When George Bush entered office, a Washington Post-ABC News poll found that 62 percent of Americans "would be willing to give up a few of the freedoms we have" for the war effort. They have gotten their wish. - "This is your bill of rights...on drugs", Harpers, Dec. 1999 From paul@prescod.net Tue Jun 27 16:28:55 2000 From: paul@prescod.net (Paul Prescod) Date: Tue, 27 Jun 2000 08:28:55 -0700 Subject: [Python-Dev] winreg features References: <019601bfe028$281dab90$4500a8c0@thomasnb> Message-ID: <3958C837.ECD925CC@prescod.net> There are a few features missing from the proposed API. I don't think that this API should serve the 80%, but rather the 97%. The only things I plan to exclude from the low level API are things that are undocumented and a little bit of performance. I see no reason not to add support for close, flush, save, remote keys and REG_FOO types. If I ever figure out how to use HIVE_VOLATILE_IS_TRUE I would add support for that too. :) -- Paul Prescod - Not encumbered by corporate consensus When George Bush entered office, a Washington Post-ABC News poll found that 62 percent of Americans "would be willing to give up a few of the freedoms we have" for the war effort. They have gotten their wish. - "This is your bill of rights...on drugs", Harpers, Dec. 1999 From paul@prescod.net Tue Jun 27 16:29:16 2000 From: paul@prescod.net (Paul Prescod) Date: Tue, 27 Jun 2000 08:29:16 -0700 Subject: [Python-Dev] winreg features References: <019601bfe028$281dab90$4500a8c0@thomasnb> Message-ID: <3958C84C.37C3EAD@prescod.net> There are a few features missing from the proposed API. I don't think that this API should serve the 80%, but rather the 97%. The only things I plan to exclude from the low level API are things that are undocumented and a little bit of performance. I want to simplify the API, not dumb it down. I see no reason not to add support for close, flush, save, remote keys and REG_FOO types. If I ever figure out how to use HIVE_VOLATILE_IS_TRUE I would add support for that too. :) -- Paul Prescod - Not encumbered by corporate consensus When George Bush entered office, a Washington Post-ABC News poll found that 62 percent of Americans "would be willing to give up a few of the freedoms we have" for the war effort. They have gotten their wish. - "This is your bill of rights...on drugs", Harpers, Dec. 1999 From thomas.heller@ion-tof.com Tue Jun 27 16:42:26 2000 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Tue, 27 Jun 2000 17:42:26 +0200 Subject: [Python-Dev] winreg References: <019601bfe028$281dab90$4500a8c0@thomasnb> <3958C511.17282EF7@prescod.net> Message-ID: <02e201bfe04e$4cecc700$4500a8c0@thomasnb> (Hopefully it is ok to use the reply-all button) > ... > My stance was that keys would always be created from keys, so you would > start with > > HKEY_LOCAL_MACHINE.CreateKey("Software\Python") > > That mirrors the underlying API a little closer and reduces the number > of functions to 0. Good idea! Maybe HKLM and so on should be provided as aliases. > > > > DeleteKey (name [,recursive=0]) > > If recursive is 0, deletes the named key if no subkeys exist. > > If there are subkeys an error is raised. > > If recursive is not 0, the named key is deleted > > including subkeys. > > I may or may not get around to implementing the recursive version. You > have to be VERY CAREFUL when you test such a thing. :) Someone (I don't remember who) mentioned in the discussion about my proposal that one should use SHDeleteKey for recursive deletion of keys. See the MSDN docs on RegDeleteKey for details. Don't know if this is exposed by the lowlevel module. > > > If we change the name of the low level api module, we have to change > > Distutils, > > because it is used there. Maybe we would better use the high level api then, > > but there is still this 1.5 compatibility using the win32api module. > > The high level could probably be made compatible with 1.5 like this: > > try: > import _winreg > except ImportError: > import win32api > winreg=win32api Currently it goes like this, because win32api and winreg (which will soon be _winreg) have slightly different apis, but it will doubtlessly be solved: try: import winreg _can_read_reg = 1 hkey_mod = winreg RegOpenKeyEx = winreg.OpenKeyEx RegEnumKey = winreg.EnumKey RegEnumValue = winreg.EnumValue RegError = winreg.error except ImportError: try: import win32api import win32con _can_read_reg = 1 hkey_mod = win32con RegOpenKeyEx = win32api.RegOpenKeyEx RegEnumKey = win32api.RegEnumKey RegEnumValue = win32api.RegEnumValue RegError = win32api.error except ImportError: pass Thomas From paul@prescod.net Tue Jun 27 16:52:27 2000 From: paul@prescod.net (Paul Prescod) Date: Tue, 27 Jun 2000 08:52:27 -0700 Subject: [Python-Dev] winreg References: <019601bfe028$281dab90$4500a8c0@thomasnb> <3958C511.17282EF7@prescod.net> <02e201bfe04e$4cecc700$4500a8c0@thomasnb> Message-ID: <3958CDBB.3F354C97@prescod.net> Right now the Python list is a little slow (at least for me) so I appreciate cc:s directly to me. Thomas Heller wrote: > > Good idea! > Maybe HKLM and so on should be provided as aliases. Sure. > Someone (I don't remember who) mentioned in the discussion > about my proposal that one should use SHDeleteKey for recursive > deletion of keys. See the MSDN docs on RegDeleteKey for details. > Don't know if this is exposed by the lowlevel module. Don't think so. > Currently it goes like this, because win32api and winreg (which > will soon be _winreg) have slightly different apis, but it will > doubtlessly be solved: Ouch. I don't know if I have time to figure out all of the correspondances. Are the only differences those four method names or are those the only four differences that DistUtils happened to care about. I'm not interested in 1.5 compatibility if it will take a lot of work. -- Paul Prescod - Not encumbered by corporate consensus When George Bush entered office, a Washington Post-ABC News poll found that 62 percent of Americans "would be willing to give up a few of the freedoms we have" for the war effort. They have gotten their wish. - "This is your bill of rights...on drugs", Harpers, Dec. 1999 From thomas.heller@ion-tof.com Tue Jun 27 17:03:30 2000 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Tue, 27 Jun 2000 18:03:30 +0200 Subject: [Python-Dev] winreg References: <019601bfe028$281dab90$4500a8c0@thomasnb> <3958C511.17282EF7@prescod.net> <02e201bfe04e$4cecc700$4500a8c0@thomasnb> <3958CDBB.3F354C97@prescod.net> Message-ID: <02fe01bfe051$3df655b0$4500a8c0@thomasnb> > Right now the Python list is a little slow (at least for me) so I > appreciate cc:s directly to me. Same for me: All python lists take hours to distribute the mails. > > Someone (I don't remember who) mentioned in the discussion > > about my proposal that one should use SHDeleteKey for recursive > > deletion of keys. See the MSDN docs on RegDeleteKey for details. > > Don't know if this is exposed by the lowlevel module. > > Don't think so. The tricky thing is: Deletion of keys behaves differently on Win95/98 and NT/2000. (Quoting MSDN:) The RegDeleteKey function deletes a subkey. Windows 95/98: The function also deletes all subkeys and values. To delete a key only if the key has no subkeys or values, use the SHDeleteEmptyKey function. Windows NT/2000: The subkey to be deleted must not have subkeys. To delete a key and all its subkeys, you need to recursively enumerate the subkeys and delete them individually. To recursively delete keys, use the SHDeleteKey function. (end quote) The SHDelete* funtions require version 4.71 of shlwapi.dll, which is included in Win98 or 2000 (or in IE 4.0). > > > Currently it goes like this, because win32api and winreg (which > > will soon be _winreg) have slightly different apis, but it will > > doubtlessly be solved: > > Ouch. I don't know if I have time to figure out all of the > correspondances. Are the only differences those four method names or are > those the only four differences that DistUtils happened to care about. > I'm not interested in 1.5 compatibility if it will take a lot of work. So you should simply ignore this. We will work it out on distutils. Thomas (I will disappear soon for holidays) From Vladimir.Marangozov@inrialpes.fr Tue Jun 27 17:23:52 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Tue, 27 Jun 2000 18:23:52 +0200 (CEST) Subject: [Python-Dev] ANN: Release schedule In-Reply-To: <200006270235.VAA02631@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Jun 26, 2000 09:35:52 PM Message-ID: <200006271623.SAA04926@python.inrialpes.fr> Guido van Rossum wrote: > > Here at BeOpen we're scrambling to get the release schedule for the > rest of Python 1.6 planned. We're now looking at releasing Python > 1.6b1 (or maybe it's going to be called 1.6a3 after all) on June 30! > This means that if SRE isn't ready, we'll go with an incomplete SRE. > Still better than no SRE! > > Please, PLEASE, if you have pending patches that you think should go > into 1.6b1, submit them to SourceForge. We'll do our best to have a > look at every patch submitted; but don't wait until the last moment. So, to sum up (because I'm a bit lost after all this patch-related messages), what should I do to avoid at best adding to the collective burden : 1. Should I send patches to SF and be quiet until June 30 ? 2. Should I apply for privileges and spend installing an SSH client on my box (illegal in France ;), then make my Python way into the SF galaxy ? 3. If I volunteer for help with the patches backlog, what do I do ? 4. Other options presented to me ? Context : I (will) have some patches lying around, there are some patches of mine on the pile sent to patches@python.org that I'm confident about, I have read the FAQ at SF which gave me 0 clues on how things are being set up there (only general info about who why and what for + terms of service), and I managed to create an account with a personal page containing two bookmarks in it (after being distracted with personal and project ratings + gobs of links to gobs of stuff). -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From guido@beopen.com Tue Jun 27 18:27:24 2000 From: guido@beopen.com (Guido van Rossum) Date: Tue, 27 Jun 2000 12:27:24 -0500 Subject: [Python-Dev] ANN: Release schedule In-Reply-To: Your message of "Tue, 27 Jun 2000 18:23:52 +0200." <200006271623.SAA04926@python.inrialpes.fr> References: <200006271623.SAA04926@python.inrialpes.fr> Message-ID: <200006271727.MAA03564@cj20424-a.reston1.va.home.com> > 1. Should I send patches to SF and be quiet until June 30 ? Yes. Not too quiet -- helping selecting which old patches are good would help. Also downloading patches from SF and commenting on them (+1/-1) in the patches list would help. > 2. Should I apply for privileges and spend installing > an SSH client on my box (illegal in France ;), then make my Python > way into the SF galaxy ? Probably no. > 3. If I volunteer for help with the patches backlog, what do I do ? Go through the patches archives and review patches. If you find one for which you would vote +1 and which you think I might like, submit it to SF. > 4. Other options presented to me ? > > Context : I (will) have some patches lying around, there are some > patches of mine on the pile sent to patches@python.org that I'm > confident about, I have read the FAQ at SF which gave me 0 clues > on how things are being set up there (only general info about > who why and what for + terms of service), and I managed to create > an account with a personal page containing two bookmarks in it > (after being distracted with personal and project ratings + gobs of > links to gobs of stuff). Go to the Python Project Summary, then to the Patch Manager. At the top, click on Submit Patch. --Guido van Rossum (home page: http://www.python.org/~guido/) From mal@lemburg.com Tue Jun 27 17:38:54 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 27 Jun 2000 18:38:54 +0200 Subject: [Python-Dev] SF patch manager... Message-ID: <3958D89E.39D084C8@lemburg.com> [Please excuse my ranting... :-)] I've received the first round of notification message from the patch manager and can't really say that I like them. Ok, I understand that the patch manager is still alpha or beta software, but these messages really don't have any usable content at all: """ Patch #100646 has been updated. Visit SourceForge.net for more info. http://sourceforge.net/patch/?func=detailpatch&patch_id=100646&group_id=5470 """ Also, reviewing the patches has become a pain and discussing them is nearly impossible (I don't consider the slashdot like comment mechanism to be of any use: there's simply no audience for discussion). Is there any chance of tee'ing patches from SF to the patches list or some other patch discussion and review forum ? I do understand that the mechanism can help with patch *checkins*, but it's certainly not going to help much with the discussion step needed before conidering any actions. The independent peer review principal doesn't work with this kind of setup. Ok, enough whining, let's get on with business now ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From esr@thyrsus.com Tue Jun 27 17:50:53 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Tue, 27 Jun 2000 12:50:53 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses wrapper.py,1.2,1.3 In-Reply-To: <20000627035202.M29590@lyra.org>; from gstein@lyra.org on Tue, Jun 27, 2000 at 03:52:02AM -0700 References: <200006270050.RAA26210@slayer.i.sourceforge.net> <20000627035202.M29590@lyra.org> Message-ID: <20000627125053.B6531@thyrsus.com> Greg Stein : > I just don't buy this. > > Look at that code. Look at the definition of finally. That code simply > screams for the use of finally. > > Eric: just what happens? What is "broke things"? Do you have a reproducible > test case that I can use? What happened is that your version failed to pass an error exception upwards after fielding it. My test case was a buggy version of cmlconfigure.py, bug since fixed. Cleanliness is good, but the code has to work first. -- Eric S. Raymond Faith may be defined briefly as an illogical belief in the occurrence of the improbable...A man full of faith is simply one who has lost (or never had) the capacity for clear and realistic thought. He is not a mere ass: he is actually ill. -- H. L. Mencken From trentm@activestate.com Tue Jun 27 17:46:58 2000 From: trentm@activestate.com (Trent Mick) Date: Tue, 27 Jun 2000 09:46:58 -0700 Subject: [Python-Dev] ANN: Release schedule In-Reply-To: <200006270235.VAA02631@cj20424-a.reston1.va.home.com> References: <200006270235.VAA02631@cj20424-a.reston1.va.home.com> Message-ID: <20000627094658.B7257@activestate.com> On Mon, Jun 26, 2000 at 09:35:52PM -0500, Guido van Rossum wrote: > (Trent Mick, it would be helpful if you assigned each of your patches > a potential reviewer from the list of existing developers -- that way > we can split up the review load.) > Do you mean I should reassigned patch-reviewing over and above the assignments that you have done recently? I was just going to put up twenty more patches and assign them all to Tim as well. :) Kidding. If, "yes", then I will make a go at that today. BTW I have answered a couple a questions on my patches. Does the person to whom the patch is assigned get an update notification? Trent -- Trent Mick trentm@activestate.com From trentm@activestate.com Tue Jun 27 17:57:38 2000 From: trentm@activestate.com (Trent Mick) Date: Tue, 27 Jun 2000 09:57:38 -0700 Subject: [Python-Dev] testing the Python/C API (was: Re: [Patches] PyObject_GetAttr/PyObject_SetAttr core dumps if given non-string names) In-Reply-To: <14679.36964.766774.864078@localhost.localdomain> References: <20000622193610.27452.qmail@eik.g.aas.no> <395272D0.B82A0353@lemburg.com> <39531A20.1BEAA51E@lemburg.com> <14675.30233.658776.764865@localhost.localdomain> <14679.36964.766774.864078@localhost.localdomain> Message-ID: <20000627095738.D7257@activestate.com> On Mon, Jun 26, 2000 at 01:18:28PM -0400, Jeremy Hylton wrote: > Ok. I was looking for a test case to include in the test suite. I've > made the change, but it looks like it will have to go without an > accompanying test. I asked the question a while back if it would reasonable/useful/popular to have a mechanism where parts of the Python/C Api could be tested directly. My proposal used an extension module _testmodule (although I made it a core module on UN*X it should not bog down the core) which exported a bunch o' test_* routines that tested specific parts of the Python/C API. A test_internal.py module would be added to the std regression test suite that would import this module and call each of the exported test_* routines in turn. This would allow things like the _GetAttr/_SetAttr behaviour to be tested. Anybody have any opinions? Trent p.s. I have a patch largely (all except the above menntion limitation) ready for this, including some tests that I used for my 64-bit porting stuff. -- Trent Mick trentm@activestate.com From skip@mojam.com (Skip Montanaro) Tue Jun 27 18:11:33 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Tue, 27 Jun 2000 12:11:33 -0500 (CDT) Subject: [Python-Dev] semi-subtle atexit gotcha? Message-ID: <14680.57413.385666.482385@beluga.mojam.com> In thinking about the new atexit module a little more, it occurred to me that I've handled the case where the atexit module gets loaded after another module that wants to set sys.exitfunc (it just incorporates that function into its list of functions), but not if atexit gets loaded before another modules that uses sys.exitfunc. I see two possible choices: 1. Punt and put a bit of verbiage in the atexit section of the library reference manual and the 1.6 release notes. 2. Have atexit.register check each time it's called to see if sys.exitfunc is what it expects. This isn't a perfect solution for a couple reasons. One, there's no guarantee that other sys.exitfunc- modifying code isn't executed after the last call to atexit.register. Two, there's no guarantee that the other code doesn't attempt to be "intelligent" in a fashion similar to atexit (can you say dueling banjos?). I vote for option number one since there appears to be no guaranteed way to make it work, but I'm open to other suggestions. -- Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille O'Neal said: "He's got the rings. I listen to the man with the rings." From trentm@activestate.com Tue Jun 27 18:16:58 2000 From: trentm@activestate.com (Trent Mick) Date: Tue, 27 Jun 2000 10:16:58 -0700 Subject: [Python-Dev] Re: [Patches] Let's use the SourceForge Patch Manager In-Reply-To: References: <200006261449.JAA01684@cj20424-a.reston1.va.home.com> Message-ID: <20000627101658.E7257@activestate.com> On Mon, Jun 26, 2000 at 02:41:12PM -0400, Tim Peters wrote: > Intended use of SourceForge patch status tags > --------------------------------------------- > revision 1 26-Jun-2000 > > > Open > The initial status of all patches. > The patch is under consideration, but has not > been reviewed yet. > The status will normally change to Accepted or Rejected next. > The person submitting the patch should (if they can) assign > it to the person they most want to review it. > Else the patch will be assigned via > [xxx a list of expertise areas should be developed] What are the chances of getting other meta data fields on patches, i.e. changes to the patch manager? Categorizing patches could really help as a filter. For instance, I may be a Unicode genius and would like to see the patches associated with it. > Discussion of patches is carried out via > [xxx Python-Dev? patches list? without a mail gateway, > the SourceForge patch interface looks too clumsy > to use for controversial patches] I like the separation of python-dev and patches, but it is not a biggie for me. > Postponed > The previous status was Open or Accepted, but for some reason > (e.g., pending release) the patch should not be reviewed or > applied until further notice. > The status will normally change to Open or Accepted next. > Please enter a comment when changing the status to Postponed, > to record the reason, the previous status, and the conditions > under which the patch should revert to Open or Accepted. Perhaps ownership (i.e. 'assigned to') of the patch should transfer to the person responsible for later taking to patch out of 'postponed' status. Trent -- Trent Mick trentm@activestate.com From jeremy@beopen.com Tue Jun 27 18:21:28 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Tue, 27 Jun 2000 13:21:28 -0400 (EDT) Subject: [Python-Dev] Re: testing the Python/C API (was: Re: [Patches] PyObject_GetAttr/PyObject_SetAttr core dumps if given non-string names) In-Reply-To: <20000627095738.D7257@activestate.com> References: <20000622193610.27452.qmail@eik.g.aas.no> <395272D0.B82A0353@lemburg.com> <39531A20.1BEAA51E@lemburg.com> <14675.30233.658776.764865@localhost.localdomain> <14679.36964.766774.864078@localhost.localdomain> <20000627095738.D7257@activestate.com> Message-ID: <14680.58008.466802.160183@bitdiddle.concentric.com> I think testing the C API directly is a great idea! Sorry I missed it the first time around. I don't think I understand the suggested approach well enough to critique it. Most of the tests need to be written in C, right? When an error is encountered, it seems that you should check what the C API returns *and* what happens at the Python level, i.e. whether the call sets a Python exception (or clears an existing Python exception). I guess you ought to show us the code. I don't think it will go in Python 1.6, but it sounds like a valuable component for future releases. Jeremy From trentm@activestate.com Tue Jun 27 18:37:00 2000 From: trentm@activestate.com (Trent Mick) Date: Tue, 27 Jun 2000 10:37:00 -0700 Subject: [Python-Dev] Re: testing the Python/C API (was: Re: [Patches] PyObject_GetAttr/PyObject_SetAttr core dumps if given non-string names) In-Reply-To: <14680.58008.466802.160183@bitdiddle.concentric.com> References: <20000622193610.27452.qmail@eik.g.aas.no> <395272D0.B82A0353@lemburg.com> <39531A20.1BEAA51E@lemburg.com> <14675.30233.658776.764865@localhost.localdomain> <14679.36964.766774.864078@localhost.localdomain> <20000627095738.D7257@activestate.com> <14680.58008.466802.160183@bitdiddle.concentric.com> Message-ID: <20000627103700.G7257@activestate.com> On Tue, Jun 27, 2000 at 01:21:28PM -0400, Jeremy Hylton wrote: > > I don't think I understand the suggested approach well enough to > critique it. Most of the tests need to be written in C, right? When All of the testing code would be in C, in the _testmodule.c, or whatever name. > an error is encountered, it seems that you should check what the C API > returns *and* what happens at the Python level, i.e. whether the call > sets a Python exception (or clears an existing Python exception). Yes you are right. It depends on the API under test. Basically you just try to test all conditions to ensure that the API behaves as expected/advertised. > > I guess you ought to show us the code. I don't think it will go in > Python 1.6, but it sounds like a valuable component for future > releases. > Okay. I agree that this would probably not make 1.6 so I will probably wait on this for a little while. Busy. Trent -- Trent Mick trentm@activestate.com From trentm@activestate.com Tue Jun 27 18:56:47 2000 From: trentm@activestate.com (Trent Mick) Date: Tue, 27 Jun 2000 10:56:47 -0700 Subject: [Python-Dev] my dev status on SourceForge In-Reply-To: <200006271430.JAA01769@cj20424-a.reston1.va.home.com> References: <200006271430.JAA01769@cj20424-a.reston1.va.home.com> Message-ID: <20000627105647.H7257@activestate.com> SPeaking of surprising little SourceForge things: I just made the mistake of clicking on the little garbage can beside "Python" in "My Projects". I seem to have booted myself from the Python project. Can I put myself back on? or can one of you with admin status please do that for me? my SourceForge username is: tmick Sorry and thanks, Trent -- Trent Mick trentm@activestate.com From akuchlin@mems-exchange.org Tue Jun 27 19:20:21 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Tue, 27 Jun 2000 14:20:21 -0400 Subject: [Python-Dev] curses/wrapper.py In-Reply-To: References: <20000627035202.M29590@lyra.org> Message-ID: <20000627142021.G19033@kronos.cnri.reston.va.us> On Wed, Jun 28, 2000 at 12:45:07AM +1000, Mark Hammond quoted: >> Besides its redundancy, it also places the traceback into a >> local variable >> and then raises an exception -- a perfect recipe for creating a ref loop. I think this is irrelevant for the curses.wrapper() function, which simply restores the terminal state before re-raising the exception. It probably won't ever be called repeatedly, making the question of a memory leak moot. Yes, I'd like to have wrapper() use Greg Stein's simpler and tidier code. Yes, I'd like to know why ESR claims the simpler version doesn't work and have a replicable test case. But right now there are higher priority things to do, so I'm shelving this until after 1.6b1. (Right now I'm trying to get the curses module compiling on Tru64, and things don't look good.) --amk From Ka-Ping Yee Tue Jun 27 19:25:01 2000 From: Ka-Ping Yee (Ka-Ping Yee) Date: Tue, 27 Jun 2000 11:25:01 -0700 (PDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses ascii.py,NONE,1.1 textpad.py,NONE,1.1 In-Reply-To: <14680.29842.372192.274003@temoleh.chem.uu.nl> Message-ID: On Tue, 27 Jun 2000, Rob W. W. Hooft wrote: > AMK> --- NEW FILE --- > AMK> # > AMK> # ascii.py -- constants and memembership tests for ASCII characters > AMK> # > ^^^^^ two letters too much? Grrrr... surely by now we should be getting docstrings instead of comments at the top of modules! In keeping with the format of most other modules, i also suggest not repeating the module name. Thus: """Constants and membership tests for ASCII characters.""" -- ?!ng (166 irender improvements since May 1999) From Vladimir.Marangozov@inrialpes.fr Tue Jun 27 19:39:35 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Tue, 27 Jun 2000 20:39:35 +0200 (CEST) Subject: [Python-Dev] ANN: Release schedule In-Reply-To: from "Vladimir Marangozov" at Jun 27, 2000 06:23:52 PM Message-ID: <200006271839.UAA05354@python.inrialpes.fr> I'm resending this msg since it didn't seem to get through the 1st time (and we're experiencing some major hw&sw router problems lately) Vladimir Marangozov wrote: > > Guido van Rossum wrote: > > > > Here at BeOpen we're scrambling to get the release schedule for the > > rest of Python 1.6 planned. We're now looking at releasing Python > > 1.6b1 (or maybe it's going to be called 1.6a3 after all) on June 30! > > This means that if SRE isn't ready, we'll go with an incomplete SRE. > > Still better than no SRE! > > > > Please, PLEASE, if you have pending patches that you think should go > > into 1.6b1, submit them to SourceForge. We'll do our best to have a > > look at every patch submitted; but don't wait until the last moment. > > So, to sum up (because I'm a bit lost after all this patch-related > messages), what should I do to avoid at best adding to the collective > burden : > > 1. Should I send patches to SF and be quiet until June 30 ? > > 2. Should I apply for privileges and spend installing > an SSH client on my box (illegal in France ;), then make my Python > way into the SF galaxy ? > > 3. If I volunteer for help with the patches backlog, what do I do ? > > 4. Other options presented to me ? > > Context : I (will) have some patches lying around, there are some > patches of mine on the pile sent to patches@python.org that I'm > confident about, I have read the FAQ at SF which gave me 0 clues > on how things are being set up there (only general info about > who why and what for + terms of service), and I managed to create > an account with a personal page containing two bookmarks in it > (after being distracted with personal and project ratings + gobs of > links to gobs of stuff). > > -- > Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr > http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 > -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From paul@prescod.net Tue Jun 27 19:46:40 2000 From: paul@prescod.net (Paul Prescod) Date: Tue, 27 Jun 2000 11:46:40 -0700 Subject: [Python-Dev] winreg References: <019601bfe028$281dab90$4500a8c0@thomasnb> <3958C511.17282EF7@prescod.net> <02e201bfe04e$4cecc700$4500a8c0@thomasnb> <3958CDBB.3F354C97@prescod.net> <02fe01bfe051$3df655b0$4500a8c0@thomasnb> Message-ID: <3958F690.EDB27D07@prescod.net> I'm trying to figure out all of the constants in _winreg. Some of them seem related to functions that _winreg doesn't support. I won't put those in new winreg because they can't be used. The only one I can't figure out through web searches is REG_OPTION_OPEN_LINK. RegNotifyChangeKeyValue (unsupported) REG_NOTIFY_CHANGE_NAME REG_NOTIFY_CHANGE_LAST_SET REG_NOTIFY_CHANGE_SECURITY REG_NOTIFY_CHANGE_ATTRIBUTES RegRestoreKey (unsupported) REG_FORCE_RESTORE REG_NO_LAZY_FLUSH REG_REFRESH_HIVE REG_WHOLE_HIVE_VOLATILE RegCreateKeyEx (unxupported) REG_OPTION_RESERVED REG_OPTION_VOLATILE REG_OPTION_NON_VOLATILE REG_OPTION_BACKUP_RESTORE REG_CREATED_NEW_KEY REG_OPENED_EXISTING_KEY REG_OPTION_CREATE_LINK I presume that nobody intends to add these three functions to _winreg in time for Python 1.6! -- Paul Prescod - Not encumbered by corporate consensus When George Bush entered office, a Washington Post-ABC News poll found that 62 percent of Americans "would be willing to give up a few of the freedoms we have" for the war effort. They have gotten their wish. - "This is your bill of rights...on drugs", Harpers, Dec. 1999 From Fredrik Lundh" <20000627035202.M29590@lyra.org> <20000627125053.B6531@thyrsus.com> Message-ID: <001f01bfe06d$753492a0$f2a6b5d4@hagrid> Eric S. Raymond wrote: > What happened is that your version failed to pass an error exception = upwards > after fielding it. My test case was a buggy version of = cmlconfigure.py, bug > since fixed. >=20 > Cleanliness is good, but the code has to work first. umm. as far as I can tell from the patch, there's no way your code can work in a situation where try/finally wouldn't do exactly the same thing. if you *do* get different results (try inserting "raise whatever" in the try clause to test this), it might be that you've stumbled upon a real bug (either in Python or in the curses C bindings)... From guido@beopen.com Tue Jun 27 21:25:49 2000 From: guido@beopen.com (Guido van Rossum) Date: Tue, 27 Jun 2000 15:25:49 -0500 Subject: [Python-Dev] Re: my dev status on SourceForge In-Reply-To: Your message of "Tue, 27 Jun 2000 10:56:47 MST." <20000627105647.H7257@activestate.com> References: <200006271430.JAA01769@cj20424-a.reston1.va.home.com> <20000627105647.H7257@activestate.com> Message-ID: <200006272025.PAA04010@cj20424-a.reston1.va.home.com> > SPeaking of surprising little SourceForge things: > > I just made the mistake of clicking on the little garbage can beside "Python" > in "My Projects". I seem to have booted myself from the Python project. Can I > put myself back on? or can one of you with admin status please do that for > me? > > my SourceForge username is: tmick OK, you're back! --Guido van Rossum (home page: http://www.python.org/~guido/) From pingster@ilm.com Tue Jun 27 20:38:15 2000 From: pingster@ilm.com (Ka-Ping Yee) Date: Tue, 27 Jun 2000 12:38:15 -0700 (PDT) Subject: [Python-Dev] SF patch manager... In-Reply-To: <3958D89E.39D084C8@lemburg.com> Message-ID: On Tue, 27 Jun 2000, M.-A. Lemburg wrote: > I've received the first round of notification message from the > patch manager and can't really say that I like them. I wish i could propose Roundup, but it currently lacks the ability to decode e-mail attachments. Aside from that, it has reasonable (if basic) e-mail handling, colour-coded status and priorities, and so on. I would jump on it in a second except that the Software Carpentry deadline is also this Friday and i'm still barely pulling that thing together. Of course, if you feel like hacking it up to do attachments feel free to get it at http://pingster.com/roundup.html and hack away! Alternatively i suppose you could keep the patch files on SourceForge and do the discussions in Roundup as an interim solution? Messy, i know, but it might be an improvement. -- ?!ng From paul@prescod.net Tue Jun 27 20:45:16 2000 From: paul@prescod.net (Paul Prescod) Date: Tue, 27 Jun 2000 12:45:16 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses ascii.py,NONE,1.1 textpad.py,NONE,1.1 References: Message-ID: <3959044C.B5C537FA@prescod.net> Ka-Ping Yee wrote: > > -- ?!ng > > (166 irender improvements since May 1999) > Although some shots were composited with Sabre, ILM's extensions > to Discreet Logic's Flame and Inferno software, CompTime was > the compositing tool for the CG department, according to > Jeff Yost. First used for one shot in Saving Private Ryan, > CompTime is based on the studio's long-time scripted system, but > now boasts a graphical user interface and hooks for plug-ins that > can be written in Python or C++. Is it safe to say that "Without Python, Saving Private Ryan would not have been possible, much less an Oscar winner?" -- Paul Prescod - Not encumbered by corporate consensus When George Bush entered office, a Washington Post-ABC News poll found that 62 percent of Americans "would be willing to give up a few of the freedoms we have" for the war effort. They have gotten their wish. - "This is your bill of rights...on drugs", Harpers, Dec. 1999 From Fredrik Lundh" <395272D0.B82A0353@lemburg.com> <39531A20.1BEAA51E@lemburg.com> <14675.30233.658776.764865@localhost.localdomain> <14679.36964.766774.864078@localhost.localdomain> <20000627095738.D7257@activestate.com> <14680.58008.466802.160183@bitdiddle.concentric.com> <20000627103700.G7257@activestate.com> Message-ID: <006801bfe072$7abc0820$f2a6b5d4@hagrid> trent wrote: > > I don't think I understand the suggested approach well enough to > > critique it. Most of the tests need to be written in C, right? = When >=20 > All of the testing code would be in C, in the _testmodule.c, or = whatever > name. SWIG, anyone? From Fredrik Lundh" Message-ID: <007801bfe073$3008b0c0$f2a6b5d4@hagrid> mal wrote: > I've received the first round of notification message from the > patch manager and can't really say that I like them. Ok, I=20 > understand that the patch manager is still alpha or beta software, > but these messages really don't have any usable content at all: >=20 > """ > Patch #100646 has been updated.=20 > Visit SourceForge.net for more info. >=20 > = http://sourceforge.net/patch/?func=3Ddetailpatch&patch_id=3D100646&group_= id=3D5470 > """ >=20 > Also, reviewing the patches has become a pain and discussing them > is nearly impossible (I don't consider the slashdot like comment > mechanism to be of any use: there's simply no audience for > discussion). >=20 > Is there any chance of tee'ing patches from SF to the patches > list or some other patch discussion and review forum ? I do > understand that the mechanism can help with patch *checkins*, > but it's certainly not going to help much with the discussion > step needed before conidering any actions. The independent > peer review principal doesn't work with this kind of setup. I fully agree. someone really needs to fuse the patch manager with roundup (that we should use roundup for bug tracking goes without saying...) how much work would it be to move the entire repository over to pythonlabs, btw? sourceforget is frustratingly slow... From guido@beopen.com Tue Jun 27 22:07:41 2000 From: guido@beopen.com (Guido van Rossum) Date: Tue, 27 Jun 2000 16:07:41 -0500 Subject: [Python-Dev] testing the Python/C API (was: Re: [Patches] PyObject_GetAttr/PyObject_SetAttr core dumps if given non-string names) In-Reply-To: Your message of "Tue, 27 Jun 2000 09:57:38 MST." <20000627095738.D7257@activestate.com> References: <20000622193610.27452.qmail@eik.g.aas.no> <395272D0.B82A0353@lemburg.com> <39531A20.1BEAA51E@lemburg.com> <14675.30233.658776.764865@localhost.localdomain> <14679.36964.766774.864078@localhost.localdomain> <20000627095738.D7257@activestate.com> Message-ID: <200006272107.QAA04498@cj20424-a.reston1.va.home.com> > I asked the question a while back if it would reasonable/useful/popular to > have a mechanism where parts of the Python/C Api could be tested directly. > > My proposal used an extension module _testmodule (although I made it a core > module on UN*X it should not bog down the core) which exported a bunch o' > test_* routines that tested specific parts of the Python/C API. A > test_internal.py module would be added to the std regression test suite that > would import this module and call each of the exported test_* routines in > turn. This would allow things like the _GetAttr/_SetAttr behaviour to be tested. > > Anybody have any opinions? > > > Trent > > p.s. I have a patch largely (all except the above menntion limitation) ready > for this, including some tests that I used for my 64-bit porting stuff. Great idea. Please wait for 1.7. There *will* be releases after 1.6! --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@beopen.com Tue Jun 27 22:08:42 2000 From: guido@beopen.com (Guido van Rossum) Date: Tue, 27 Jun 2000 16:08:42 -0500 Subject: [Python-Dev] semi-subtle atexit gotcha? In-Reply-To: Your message of "Tue, 27 Jun 2000 12:11:33 EST." <14680.57413.385666.482385@beluga.mojam.com> References: <14680.57413.385666.482385@beluga.mojam.com> Message-ID: <200006272108.QAA04509@cj20424-a.reston1.va.home.com> > In thinking about the new atexit module a little more, it occurred to me > that I've handled the case where the atexit module gets loaded after another > module that wants to set sys.exitfunc (it just incorporates that function > into its list of functions), but not if atexit gets loaded before another > modules that uses sys.exitfunc. I see two possible choices: > > 1. Punt and put a bit of verbiage in the atexit section of the library > reference manual and the 1.6 release notes. > > 2. Have atexit.register check each time it's called to see if > sys.exitfunc is what it expects. This isn't a perfect solution for a > couple reasons. One, there's no guarantee that other sys.exitfunc- > modifying code isn't executed after the last call to > atexit.register. Two, there's no guarantee that the other code > doesn't attempt to be "intelligent" in a fashion similar to atexit > (can you say dueling banjos?). > > I vote for option number one since there appears to be no guaranteed way to > make it work, but I'm open to other suggestions. Yes, #1 is good enough. I don't think there will be lots of people bitten by this... --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@beopen.com Tue Jun 27 22:11:46 2000 From: guido@beopen.com (Guido van Rossum) Date: Tue, 27 Jun 2000 16:11:46 -0500 Subject: [Python-Dev] Re: [Patches] Let's use the SourceForge Patch Manager In-Reply-To: Your message of "Tue, 27 Jun 2000 10:16:58 MST." <20000627101658.E7257@activestate.com> References: <200006261449.JAA01684@cj20424-a.reston1.va.home.com> <20000627101658.E7257@activestate.com> Message-ID: <200006272111.QAA04542@cj20424-a.reston1.va.home.com> > What are the chances of getting other meta data fields on patches, i.e. > changes to the patch manager? Categorizing patches could really help as a > filter. For instance, I may be a Unicode genius and would like to see the > patches associated with it. Good idea. The PM clearly needs work. I see two places where you could submit feature requests: (1) the "Report SF Bug" item in the left side bar; (2) the "Feature Requests" discussion forum (http://sourceforge.net/forum/forum.php?forum_id=4&et=0) > I like the separation of python-dev and patches, but it is not a biggie for > me. For me it's just an annoyance, especially when cross-posting is used. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@beopen.com Tue Jun 27 22:36:57 2000 From: guido@beopen.com (Guido van Rossum) Date: Tue, 27 Jun 2000 16:36:57 -0500 Subject: [Python-Dev] python.org mail unclogged Message-ID: <200006272136.QAA04723@cj20424-a.reston1.va.home.com> It seems we've removed a major source of email cloggage on python.org -- a site in France was hitting every page in the mailman membership administration using a commercial crawler (Teleport Pro) that didn't honor our robots.txt file, and forking a 4 Mb CGI script for each user in each mailing list. Thanks for Barry and Andrew! This was on top of problems caused when the Ultraseek crawler ran out of memory and caused postfix or mailman to fail. :-( Mail seems to be flowing again, the queues are emptying. Once we're happy, we'll turn on the Ultraseek crawler and search service. --Guido van Rossum (home page: http://www.python.org/~guido/) From jeremy@beopen.com Tue Jun 27 21:54:38 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Tue, 27 Jun 2000 16:54:38 -0400 (EDT) Subject: [Python-Dev] SF patch manager... In-Reply-To: References: <3958D89E.39D084C8@lemburg.com> Message-ID: <14681.5262.464079.557095@bitdiddle.concentric.com> Maybe the right solution is to work with the SourceForge maintainers to make roundup part of the standard support software. jeremy From fdrake@beopen.com Tue Jun 27 22:01:54 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Tue, 27 Jun 2000 17:01:54 -0400 (EDT) Subject: [Python-Dev] Re: [Patches] Let's use the SourceForge Patch Manager In-Reply-To: <20000627101658.E7257@activestate.com> References: <200006261449.JAA01684@cj20424-a.reston1.va.home.com> <20000627101658.E7257@activestate.com> Message-ID: <14681.5698.732269.523890@cj42289-a.reston1.va.home.com> Trent Mick writes: > Perhaps ownership (i.e. 'assigned to') of the patch should transfer to the > person responsible for later taking to patch out of 'postponed' status. Agreed; assignment should be changed whenever the next person required to deal with it changes. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From nascheme@enme.ucalgary.ca Tue Jun 27 22:05:55 2000 From: nascheme@enme.ucalgary.ca (Neil Schemenauer) Date: Tue, 27 Jun 2000 15:05:55 -0600 Subject: [Python-Dev] SF patch manager... In-Reply-To: <007801bfe073$3008b0c0$f2a6b5d4@hagrid>; from effbot@telia.com on Tue, Jun 27, 2000 at 10:06:30PM +0200 References: <3958D89E.39D084C8@lemburg.com> <007801bfe073$3008b0c0$f2a6b5d4@hagrid> Message-ID: <20000627150555.A3083@acs.ucalgary.ca> On Tue, Jun 27, 2000 at 10:06:30PM +0200, Fredrik Lundh wrote: > how much work would it be to move the entire repository over to > pythonlabs, btw? sourceforget is frustratingly slow... rsync access to the CVS repository would be nice too. rsync should be faster than "cvs update". Also, once you have the whole repository making diffs and checking out different versions is much faster. Neil -- "I saw `cout' being shifted "Hello world" times to the left and stopped right there." -- Steve Gonedes From jeremy@beopen.com Tue Jun 27 22:49:01 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Tue, 27 Jun 2000 17:49:01 -0400 (EDT) Subject: [Python-Dev] SF patch manager... In-Reply-To: <20000627150555.A3083@acs.ucalgary.ca> References: <3958D89E.39D084C8@lemburg.com> <007801bfe073$3008b0c0$f2a6b5d4@hagrid> <20000627150555.A3083@acs.ucalgary.ca> Message-ID: <14681.8525.343786.194271@bitdiddle.concentric.com> >>>>> "NS" == Neil Schemenauer writes: NS> On Tue, Jun 27, 2000 at 10:06:30PM +0200, Fredrik Lundh wrote: >> how much work would it be to move the entire repository over to >> pythonlabs, btw? sourceforget is frustratingly slow... NS> rsync access to the CVS repository would be nice too. rsync NS> should be faster than "cvs update". Also, once you have the NS> whole repository making diffs and checking out different NS> versions is much faster. Absolutely! OpenSSL works this way and I find it much more convenient than using a remote CVS server. I use commands like diff, log, and annotate frequently during development. Have you suggested that as a SourceForge feature? Jeremy From akuchlin@mems-exchange.org Tue Jun 27 22:47:07 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Tue, 27 Jun 2000 17:47:07 -0400 Subject: [Python-Dev] Testdrive systems Message-ID: <20000627174707.P19033@kronos.cnri.reston.va.us> Portability-related note: I've just fixed a reported compilation problem with the curses module on Tru64 Unix using a machine made available by Compaq. If you go to http://www.testdrive.compaq.com/, you can sign up for a free 30-day account on a variety of machines: Alphas running Tru64, FreeBSD, and Linux, and Intel machines running BSD or Linux. A nice way to fix reported problems quickly... The environment on the systems is a bit Spartan; emacs is there, but no fancy shells and no CVS (which is especially annoying). --amk From nascheme@enme.ucalgary.ca Tue Jun 27 23:56:09 2000 From: nascheme@enme.ucalgary.ca (Neil Schemenauer) Date: Tue, 27 Jun 2000 16:56:09 -0600 Subject: [Python-Dev] SF patch manager... In-Reply-To: <14681.8525.343786.194271@bitdiddle.concentric.com>; from jeremy@beopen.com on Tue, Jun 27, 2000 at 05:49:01PM -0400 References: <3958D89E.39D084C8@lemburg.com> <007801bfe073$3008b0c0$f2a6b5d4@hagrid> <20000627150555.A3083@acs.ucalgary.ca> <14681.8525.343786.194271@bitdiddle.concentric.com> Message-ID: <20000627165609.A3941@acs.ucalgary.ca> On Tue, Jun 27, 2000 at 05:49:01PM -0400, Jeremy Hylton wrote: > Have you suggested [rsync access to CVS] as a SourceForge feature? Nope. Be my guest. :) Neil From tpeters@beopen.com Wed Jun 28 01:11:44 2000 From: tpeters@beopen.com (Tim Peters) Date: Tue, 27 Jun 2000 20:11:44 -0400 Subject: [Python-Dev] SF patch manager... In-Reply-To: <3958D89E.39D084C8@lemburg.com> Message-ID: [MAL] > [Please excuse my ranting... :-)] No problem -- you're not complaining about *our* software . > I've received the first round of notification message from the > patch manager and can't really say that I like them. Ok, I > understand that the patch manager is still alpha or beta software, > but these messages really don't have any usable content at all: > > """ > Patch #100646 has been updated. > Visit SourceForge.net for more info. > > http://sourceforge.net/patch/?func=detailpatch&patch_id=100646&group_id=5470 > """ I expect the title of the patch was also in the Subject line, yes? And a live link to the patch is certainly "usable". I've found both those right on target as I've been assigned or deassigned to patches so far, although I'd sure like to see something in the body saying exactly *what* about the patch "has been updated". Not saying I think it's good enough, am saying it's (barely) a start. > Also, reviewing the patches has become a pain I don't understand that, in that the text of the patch is what you got before, and what you can get now. Is your complaint here specifically that patches don't show up in your mailbox by magic? Or something else? > and discussing them is nearly impossible (I don't consider the > slashdot like comment mechanism to be of any use: there's simply > no audience for discussion). Wholly agreed there. So use python-dev for discussions for now; I agree too with Guido that the rampant but inconsistent x-posting between patches and python-dev was part of the problem. > Is there any chance of tee'ing patches from SF to the patches > list or some other patch discussion and review forum ? I expect you know as much about SF's possibilities as anyone <0.5 wink>: don't know. The SF docs are either non-existent or inadequate, far as I can tell, and I believe I share a mistaken belief with Fred Drake that new patches "should" *already* be showing up on the patches list. > I do understand that the mechanism can help with patch *checkins*, Yes, but not yet as much as it should (e.g., the default view of patches lacks basic info like the patch current status, and there's apparently not yet any way to define a different view). > but it's certainly not going to help much with the discussion > step needed before conidering any actions. Python-Dev now, possibly roundup later. OTOH, it's perfectly adequate for tiny little principal-reviewer <-> submitter give-and-take; many patches are really quite trivial. > The independent peer review principal doesn't work with this > kind of setup. I think your view is warped on this one, as you've been in the extremely favored position of pumping out crucial patches for a hot area. Most other peoples' patches have been flatly ignored for *months* now. It's not necessarily bad if other people get some attention now too . From tpeters@beopen.com Wed Jun 28 01:11:52 2000 From: tpeters@beopen.com (Tim Peters) Date: Tue, 27 Jun 2000 20:11:52 -0400 Subject: [Python-Dev] SF patch manager... In-Reply-To: <007801bfe073$3008b0c0$f2a6b5d4@hagrid> Message-ID: [Fredrik Lundh] > ... > how much work would it be to move the entire repository over to > pythonlabs, btw? Impossibly more than we could make time for soon. > sourceforget is frustratingly slow... 'Tis very erratic indeed. It *can* be speedy, but that seems much more the exception than the rule. From Ka-Ping Yee Wed Jun 28 00:29:04 2000 From: Ka-Ping Yee (Ka-Ping Yee) Date: Tue, 27 Jun 2000 16:29:04 -0700 (PDT) Subject: [Python-Dev] Re: [Patches] Let's use the SourceForge Patch Manager In-Reply-To: <200006272111.QAA04542@cj20424-a.reston1.va.home.com> Message-ID: Fredrik Lundh wrote: > someone really needs to fuse the patch manager with roundup (that > we should use roundup for bug tracking goes without saying...) How sweet! Why, thank you. :) Trent Mick wrote: > What are the chances of getting other meta data fields on patches, i.e. > changes to the patch manager? Categorizing patches could really help as a > filter. For instance, I may be a Unicode genius and would like to see the > patches associated with it. I agree that doing that kind of filtering is very useful. I have a discussion thingie (based on Roundup) at http://headspaces.com/. (Also prototype -- very prototype.) I hacked out the "status" and "fixer" fields and added a "keywords" field. Not much volume yet, but i think it will work well. Perhaps something like that for discussing patches? Jeremy Hylton wrote: > Maybe the right solution is to work with the SourceForge maintainers > to make roundup part of the standard support software. Hmmm... maybe i should look into that after i've figured out how super-Roundup is going to work. -- ?!ng From gward@python.net Wed Jun 28 01:58:43 2000 From: gward@python.net (Greg Ward) Date: Tue, 27 Jun 2000 20:58:43 -0400 Subject: [Python-Dev] DOS text files and CVS Message-ID: <20000627205843.A1607@beelzebub> Hi all -- can anyone enlighten me on the right way to check in DOS text files to a CVS repository? I have Thomas Heller's C source for his simple graphical installer for Python modules, and it should definitely be in the Distutils CVS tree. But I don't want to check it in if it'll screw up line-endings for anyone. Is there a Right Way to do this? Thanks -- Greg -- Greg Ward - Linux nerd gward@python.net http://starship.python.net/~gward/ Just because you're paranoid doesn't mean they *aren't* out to get you. From tpeters@beopen.com Wed Jun 28 02:13:54 2000 From: tpeters@beopen.com (Tim Peters) Date: Tue, 27 Jun 2000 21:13:54 -0400 Subject: [Python-Dev] ANN: Release schedule In-Reply-To: <017501bfe023$684fca40$f2a6b5d4@hagrid> Message-ID: [Fredrik Lundh] > (tim? where's the second installment of your sourceforge vs. > windows series?) Waiting for you to finish SRE . Seriously, I don't *need* to get Windows checkin access for the imminent release, so I moved this down my priority list. I needed to move *something* down because finding a place to live around here is both urgent & consuming much more time than I had planned on (vacancy rate: 0%). Windows vs SourceForge is still on my plate, and I'm not giving up on it, just slipping it. just-carrying-my-plans-between-the-bathroom-&-the-bed-is- invigorating-exercise-ly y'rs - tim From mhammond@skippinet.com.au Wed Jun 28 02:18:44 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Wed, 28 Jun 2000 11:18:44 +1000 Subject: [Python-Dev] ANN: Release schedule In-Reply-To: Message-ID: > just-carrying-my-plans-between-the-bathroom-&-the-bed-is- > invigorating-exercise-ly y'rs - tim Your plans, or your pans? I-knew-you-were-old-but-not-that-old--ly, Mark. From tpeters@beopen.com Wed Jun 28 02:39:31 2000 From: tpeters@beopen.com (Tim Peters) Date: Tue, 27 Jun 2000 21:39:31 -0400 Subject: [Python-Dev] RE: [Distutils] DOS text files and CVS In-Reply-To: <20000627205843.A1607@beelzebub> Message-ID: [Greg Ward] > can anyone enlighten me on the right way to check in DOS text files to a > CVS repository? Aargh, I haven't used CVS in about 6 years ... somehow or other, I believe you need to convince CVS that it's a binary (not text) file. Then it will skip line-end conversions. not-a-solution-but-maybe-a-clue-ly y'rs - tim From gstein@lyra.org Wed Jun 28 02:46:15 2000 From: gstein@lyra.org (Greg Stein) Date: Tue, 27 Jun 2000 18:46:15 -0700 Subject: [Python-Dev] add Demo/imputil/importers.py ? Message-ID: <20000627184615.A29590@lyra.org> A while back, I pulled the "demo" importers out of imputil.py. I think those should be added into Demo/imputil/. It would also be Goodness to include JimA's zipimporter. Where would that go? Cheers, -g -- Greg Stein, http://www.lyra.org/ From gmcm@hypernet.com Wed Jun 28 02:47:30 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Tue, 27 Jun 2000 21:47:30 -0400 Subject: [Python-Dev] DOS text files and CVS In-Reply-To: <20000627205843.A1607@beelzebub> Message-ID: <1249965584-36289880@hypernet.com> Greg Ward asks: > can anyone enlighten me on the right way to check in DOS text > files to a CVS repository? I have Thomas Heller's C source for > his simple graphical installer for Python modules, and it should > definitely be in the Distutils CVS tree. But I don't want to > check it in if it'll screw up line-endings for anyone. Is there > a Right Way to do this? Well, if you checked it in from a Windows box, CVS would translate line endings to native, then a Windows checkout would translate back to Windows endings. So assuming you don't want to get your fingers dirty, give it *n*x line endings and check it in. CVS does understand text, you know :-). (And about the only Windows editor that barfs on *n*x line endings is Notepad.) - Gordon From davida@pobox.com Wed Jun 28 02:50:24 2000 From: davida@pobox.com (David Arnold) Date: Wed, 28 Jun 2000 11:50:24 +1000 Subject: [Python-Dev] Re: [Distutils] DOS text files and CVS In-Reply-To: Your message of "Tue, 27 Jun 2000 21:39:31 -0400." Message-ID: <200006280150.LAA17759@xevious.dstc.monash.edu.au> -->"Tim" == Tim Peters writes: Tim> Aargh, I haven't used CVS in about 6 years ... somehow or Tim> other, I believe you need to convince CVS that it's a binary Tim> (not text) file. Then it will skip line-end conversions. cvs add -kb file should work to add a binary file. not sure that this is the best way to deal with DOS files, but it should work ... d From akuchlin@mems-exchange.org Wed Jun 28 03:04:53 2000 From: akuchlin@mems-exchange.org (A.M. Kuchling) Date: Tue, 27 Jun 2000 22:04:53 -0400 Subject: [Python-Dev] Text about cycle GC Message-ID: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com> I've written some text for the What's New article on the GCing of cycles, but it wasn't a topic I paid close attention to at the time, so I'd like corrections. Here's what I've got; please send me comments privately. 6. Optional Collection of Cycles The C implementation of Python uses reference counting to implement garbage collection. Every Python object maintains a count of the number of references pointing to itself, and adjusts the count as references are created or destroyed. Once the reference count reaches zero, the object is no longer accessible, since you need to have a reference to an object to access it, and if the count is zero, no references exist any longer. Reference counting has some pleasant properties: it's easy to understand and implement, and the resulting implementation is portable, fairly fast, and reacts well with other libraries that implement their own memory handling schemes. The major problem with reference counting is that it sometimes doesn't realise that objects are no longer accessible, resulting in a memory leak. This happens when there are cycles of references. Consider the simplest possible cycle, a class instance which has a reference to itself: instance = SomeClass() instance.myself = instance After the above two lines of code have been executed, the reference count of instance is 2; one reference is from the variable named "'instance'", and the other is from the "myself"attribute of the instance. If the next line of code is del instance, what happens? The reference count of instance is decreased by 1, so it has a reference count of 1; the reference in the "myself" attribute still exists. Yet the instance is no longer accessible through Python code, and it could be deleted. Several objects can participate in a cycle if they have references to each other, causing all of the objects to be leaked. An experimental step has been made toward fixing this problem. When compiling Python, the -with-cycle-gc (XXX correct option flag?) option can be specified. This causes a cycle detection algorithm to be periodically executed, which looks for inaccessible cycles and deletes the objects involved. Why isn't this enabled by default? Running the cycle detection algorithm takes some time, and some tuning will be required to minimize the overhead cost. It's not yet obvious how much performance is lost, because benchmarking this is tricky and depends sensitively on how often the program creates and destroys objects. XXX is this actually the correct reason? Or is it fear of breaking software that runs happily while leaving garbage? Several people worked on this problem. Early versions were written by XXX1, XXX2. (I vaguely remember several people writing first cuts at this. Anyone recall who?) The implementation that's in Python 1.6 is a rewritten version, this time done by Neil Schemenauer. Lots of other people offered suggestions along the way, such as (in alphabetical order) Marc-André Lemburg, Tim Peters, Greg Stein, Eric Tiedemann. (XXX other names? If you feel you should be added, e-mail me). The March 2000 archives of the python-dev mailing list contain most of the relevant discussion, especially in the threads titled ``Reference cycle collection for Python'' and ``Finalization again''. From ians@amc.com Wed Jun 28 02:51:45 2000 From: ians@amc.com (Ian Searle) Date: Tue, 27 Jun 2000 18:51:45 -0700 Subject: [Python-Dev] Re: [Distutils] DOS text files and CVS References: Message-ID: <39595A31.6462CA42@amc.com> The best way to check DOS text files into CVS is from a Windows/DOS machine using the CVS client/pserver route. Using this method, the files are stored in canonical format. When someone checks them out from a Unix client they get /n only. And, when someone checks them out from a Windows/DOS client, they get /r/n. And, everyone is happy (well, as much as can be expected :-) If you do a 'cvs add -kb foo.dos-txt' then CVS will treat the file as binary and forego the keyword substitutions and end of line translations. But, folks checking them out will always get the /r/n regardless of platform. -Ian Tim Peters wrote: > > [Greg Ward] > > can anyone enlighten me on the right way to check in DOS text files to a > > CVS repository? > > Aargh, I haven't used CVS in about 6 years ... somehow or other, I believe > you need to convince CVS that it's a binary (not text) file. Then it will > skip line-end conversions. > > not-a-solution-but-maybe-a-clue-ly y'rs - tim > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > http://www.python.org/mailman/listinfo/distutils-sig From akuchlin@mems-exchange.org Wed Jun 28 03:04:15 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Tue, 27 Jun 2000 22:04:15 -0400 Subject: [Python-Dev] add Demo/imputil/importers.py ? In-Reply-To: <20000627184615.A29590@lyra.org>; from gstein@lyra.org on Tue, Jun 27, 2000 at 06:46:15PM -0700 References: <20000627184615.A29590@lyra.org> Message-ID: <20000627220415.A22246@newcnri.cnri.reston.va.us> On Tue, Jun 27, 2000 at 06:46:15PM -0700, Greg Stein wrote: >A while back, I pulled the "demo" importers out of imputil.py. I think those >should be added into Demo/imputil/. While on the subject of adding demo directories, I'd like to add a Demo/curses directory. (Not going to happen until after b1, though; cute little demos aren't a high priority at the moment.) --amk From bwarsaw@beopen.com Wed Jun 28 03:25:47 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Tue, 27 Jun 2000 22:25:47 -0400 (EDT) Subject: [Python-Dev] DOS text files and CVS References: <20000627205843.A1607@beelzebub> Message-ID: <14681.25131.166235.152210@anthem.concentric.net> >>>>> "GW" == Greg Ward writes: GW> can anyone enlighten me on the right way to check in DOS text GW> files to a CVS repository? I have Thomas Heller's C source GW> for his simple graphical installer for Python modules, and it GW> should definitely be in the Distutils CVS tree. But I don't GW> want to check it in if it'll screw up line-endings for anyone. GW> Is there a Right Way to do this? If there's no reason why it /has/ to be DOS text, convert it to Unix line endings first. XEmacs will even do the conversion for you! That is, if the other suggestions people have made don't help. -Barry From skip@mojam.com (Skip Montanaro) Wed Jun 28 03:51:03 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Tue, 27 Jun 2000 21:51:03 -0500 (CDT) Subject: [Python-Dev] readline history read/write Message-ID: <14681.26647.228866.236111@beluga.mojam.com> --lhrBnbs8QA Content-Type: text/plain; charset=us-ascii Content-Description: message body and .signature Content-Transfer-Encoding: 7bit The original thing that motivated me to propose what became atexit.py was my desire to read and write readline history files. The two attached context diffs patch Modules/readline.c and Lib/rlcompleter.py to do that. Two new functions are added to the readline module and rlcompleter is tweaked to read the history file referenced by the PYTHONHISTORY environment variable (if it's defined) and automatically save it when the interpreter exits. I'm looking for a little feedback. Here are a few things that jumped to my mind: 1. Is it okay to add the read and register/write code to rlcompleter.py? Reading and writing readline history files doesn't have anything directly to do with identifier completion, but they both have to do with readline. 2. Assuming that history file read/write is desired, should it be predicated on the presence of an environment variable or (as in bash and other readline-aware programs) should it just happen? 3. Am I correct in assuming that this capability will only be available to Unix/Linux environments, or is readline generally available, thus forcing me to think about cross-platform issues? 4. Is there some mechanism already present in IDLE and/or PythonWin I should be aware of and try to emulate? The two context diffs are both short. You should be able to follow everything just by reading the bits of code. Offering your thoughts on the above questions shouldn't require actually modifying your interpreter. Thx, -- Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille O'Neal said: "He's got the rings. I listen to the man with the rings." --lhrBnbs8QA Content-Type: text/plain Content-Description: read/write history files Content-Disposition: inline; filename="readline.dif" Content-Transfer-Encoding: 7bit *** /tmp/readline.c.~2.17~SlD5BD Tue Jun 27 21:38:08 2000 --- /tmp/readline.cSlDGMJ Tue Jun 27 21:38:08 2000 *************** *** 94,99 **** --- 94,147 ---- "; + /* Exported function to load a readline history file */ + + static PyObject * + read_history_file(self, args) + PyObject *self; + PyObject *args; + { + char *s = NULL; + if (!PyArg_ParseTuple(args, "|z:read_history_file", &s)) + return NULL; + errno = read_history(s); + if (errno) + return PyErr_SetFromErrno(PyExc_IOError); + Py_INCREF(Py_None); + return Py_None; + } + + static char doc_read_history_file[] = "\ + read_history_file([filename]) -> None\n\ + Load a readline history file.\n\ + The default filename is ~/.history.\ + "; + + + /* Exported function to save a readline history file */ + + static PyObject * + write_history_file(self, args) + PyObject *self; + PyObject *args; + { + char *s = NULL; + if (!PyArg_ParseTuple(args, "|z:write_history_file", &s)) + return NULL; + errno = write_history(s); + if (errno) + return PyErr_SetFromErrno(PyExc_IOError); + Py_INCREF(Py_None); + return Py_None; + } + + static char doc_write_history_file[] = "\ + write_history_file([filename]) -> None\n\ + Save a readline history file.\n\ + The default filename is ~/.history.\ + "; + + /* Exported function to specify a word completer in Python */ static PyObject *completer = NULL; *************** *** 261,266 **** --- 309,316 ---- {"get_line_buffer", get_line_buffer, 0, doc_get_line_buffer}, {"insert_text", insert_text, 1, doc_insert_text}, {"read_init_file", read_init_file, 1, doc_read_init_file}, + {"read_history_file", read_history_file, 1, doc_read_history_file}, + {"write_history_file", write_history_file, 1, doc_write_history_file}, {"set_completer", set_completer, 1, doc_set_completer}, {"get_begidx", get_begidx, 0, doc_get_begidx}, {"get_endidx", get_endidx, 0, doc_get_endidx}, --lhrBnbs8QA Content-Type: text/plain Content-Description: load and save readline history files automatically Content-Disposition: inline; filename="rlcompleter.dif" Content-Transfer-Encoding: 7bit *** /tmp/rlcompleter.py.~1.7~SlDswI Tue Jun 27 21:36:32 2000 --- /tmp/rlcompleter.pySlD56O Tue Jun 27 21:36:32 2000 *************** *** 118,120 **** --- 118,131 ---- return ret readline.set_completer(Completer().complete) + + import os + histfile = os.getenv("PYTHONHISTORY") + if histfile is not None: + try: + readline.read_history_file(histfile) + except IOError: + pass + import atexit + atexit.register(readline.write_history_file, histfile) + del os, histfile --lhrBnbs8QA-- From gstein@lyra.org Wed Jun 28 04:08:46 2000 From: gstein@lyra.org (Greg Stein) Date: Tue, 27 Jun 2000 20:08:46 -0700 Subject: [Python-Dev] SF patch manager... In-Reply-To: ; from tim_one@email.msn.com on Tue, Jun 27, 2000 at 08:11:52PM -0400 References: <007801bfe073$3008b0c0$f2a6b5d4@hagrid> Message-ID: <20000627200846.D29590@lyra.org> On Tue, Jun 27, 2000 at 08:11:52PM -0400, Tim Peters wrote: > [Fredrik Lundh] > > ... > > how much work would it be to move the entire repository over to > > pythonlabs, btw? > > Impossibly more than we could make time for soon. > > > sourceforget is frustratingly slow... > > 'Tis very erratic indeed. It *can* be speedy, but that seems much more the > exception than the rule. hehe... I have 30ms pings and have observed multiple Mb/sec :-) download.sourceforge.net is excellent given those stats... Of course, I'm practically just down the street. Cheers, -g -- Greg Stein, http://www.lyra.org/ From tpeters@beopen.com Wed Jun 28 04:13:52 2000 From: tpeters@beopen.com (Tim Peters) Date: Tue, 27 Jun 2000 23:13:52 -0400 Subject: [Python-Dev] SF patch manager... In-Reply-To: <20000627200846.D29590@lyra.org> Message-ID: [Greg Stein] > hehe... I have 30ms pings and have observed multiple Mb/sec :-) > > download.sourceforge.net is excellent given those stats... > > Of course, I'm practically just down the street. Would please send me the Python script you use to configure Win98 so that I can get multiple Mb/sec too? Thanks in advance. I always *knew* there was a secret way to boost these 56K laptop modems . keep-gloating-pal-and-we'll-move-everything-to-a-server-in-barry's- basement-ly y'rs - tim From gstein@lyra.org Wed Jun 28 04:25:31 2000 From: gstein@lyra.org (Greg Stein) Date: Tue, 27 Jun 2000 20:25:31 -0700 Subject: [Python-Dev] SF patch manager... In-Reply-To: ; from tim_one@email.msn.com on Tue, Jun 27, 2000 at 11:13:52PM -0400 References: <20000627200846.D29590@lyra.org> Message-ID: <20000627202531.G29590@lyra.org> On Tue, Jun 27, 2000 at 11:13:52PM -0400, Tim Peters wrote: > [Greg Stein] > > hehe... I have 30ms pings and have observed multiple Mb/sec :-) > > > > download.sourceforge.net is excellent given those stats... > > > > Of course, I'm practically just down the street. > > Would please send me the Python script you use to configure Win98 so that I > can get multiple Mb/sec too? Thanks in advance. I always *knew* there was > a secret way to boost these 56K laptop modems . DSL big boy! DSL! And I use a real OS :-) > keep-gloating-pal-and-we'll-move-everything-to-a-server-in-barry's- > basement-ly y'rs - tim eek! -- Greg Stein, http://www.lyra.org/ From tpeters@beopen.com Wed Jun 28 05:11:22 2000 From: tpeters@beopen.com (Tim Peters) Date: Wed, 28 Jun 2000 00:11:22 -0400 Subject: [Python-Dev] ANN: Release schedule In-Reply-To: Message-ID: >> just-carrying-my-plans-between-the-bathroom-&-the-bed-is- >> invigorating-exercise-ly y'rs - tim [Mark Hammond] > Your plans, or your pans? > > I-knew-you-were-old-but-not-that-old--ly, My pans are in storage somewhere in Baltimore, so I can't report on their possible growth. Or is this an Australian thing ? put-another-pan-on-the-barbie-mate?-ly y'rs - tim PS: My testicles *have* grown since I moved to VA! I'm wondering whether it's an early symptom of Lyme disease. They're still easy to carry from room to room, though, provided simply I'm careful not to trip over them. From bwarsaw@beopen.com Wed Jun 28 05:13:32 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Wed, 28 Jun 2000 00:13:32 -0400 (EDT) Subject: [Python-Dev] SF patch manager... References: <20000627200846.D29590@lyra.org> Message-ID: <14681.31596.221693.491788@anthem.concentric.net> >>>>> "TP" == Tim Peters writes: TP> keep-gloating-pal-and-we'll-move-everything-to-a-server-in-barry's- TP> basement-ly y'rs - tim Say the word, send me some hardware, and I'll clear a space between the drums, bass rig, and litter boxes. cover-it-in-sisal-and-even-the-cats'll-be-happy-ly y'rs, -Barry From tpeters@beopen.com Wed Jun 28 06:04:36 2000 From: tpeters@beopen.com (Tim Peters) Date: Wed, 28 Jun 2000 01:04:36 -0400 Subject: [Python-Dev] testing the Python/C API (was: Re: [Patches] PyObject_GetAttr/PyObject_SetAttr core dumps if given non-string names) In-Reply-To: <20000627095738.D7257@activestate.com> Message-ID: [Trent Mick] > I asked the question a while back if it would reasonable/useful/popular > to have a mechanism where parts of the Python/C Api could be tested > directly. Not only reasonable, IMO it's essential. "If it's not tested, it's broken." Tattoo that on your neighbor's forehead so it's always in mind . Every time we get a legit bug report on Python, I view it as a failure of the test suite. That's one of the things I hope to spend a lot of time on (but have not been promised I can spend any time on -- aren't startups great ?). > My proposal used an extension module _testmodule (although I made > it a core module on UN*X it should not bog down the core) which exported > a bunch o' test_* routines that tested specific parts of the Python/C > API. A test_internal.py module would be added to the std regression test > suite that would import this module and call each of the exported test_* > routines in turn. This would allow things like the _GetAttr/_SetAttr > behaviour to be tested. > > Anybody have any opinions? Great start! But the people who most need to take this seriously (including but not limited to me) have no bandwidth to spare before 1.6 is out the door. focus!-it's-not-just-for-breakfast-anymore-ly y'rs - tim From DavidA@ActiveState.com Wed Jun 28 06:33:37 2000 From: DavidA@ActiveState.com (David Ascher) Date: Tue, 27 Jun 2000 22:33:37 -0700 Subject: [Python-Dev] testing the Python/C API (was: Re: [Patches] PyObject_GetAttr/PyObject_SetAttr core dumps if given non-string names) In-Reply-To: Message-ID: > [Trent Mick] > > I asked the question a while back if it would reasonable/useful/popular > > to have a mechanism where parts of the Python/C Api could be tested > > directly. > > Not only reasonable, IMO it's essential. "If it's not tested, > it's broken." Tattoo that on your neighbor's forehead so it's always in mind . Stay _off_ my forehead, thank you very much. My hairline is receding enough without ink stains killing off hair follicles. Besides, I like my lobster-colored forehead just fine. --da From tpeters@beopen.com Wed Jun 28 07:23:38 2000 From: tpeters@beopen.com (Tim Peters) Date: Wed, 28 Jun 2000 02:23:38 -0400 Subject: [Python-Dev] C# (new language from Microsoft) In-Reply-To: Message-ID: [Mark Hammond] > ... > * Python has a very good and interesting story in all this - there is no > need to be alarmed. If anything, be excited :-) I was never worried about Python, but I lay awake at night worrying about MS -- I'm still an MS shareholder, so don't screw this up . every-new-c#-programmer-is-a-potential-python-convert-ly y'rs - tim From tpeters@beopen.com Wed Jun 28 07:23:40 2000 From: tpeters@beopen.com (Tim Peters) Date: Wed, 28 Jun 2000 02:23:40 -0400 Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager In-Reply-To: <200006271430.JAA01769@cj20424-a.reston1.va.home.com> Message-ID: [Guido van Rossum] > ... > The address for New Bugs is currently set to guido@beopen.com. I > suppose I should set it to pythoneers@beopen.com or even to > python-dev@python.org? Since we (PythonLabs, last week) decided to continue using Jitterbug (on python.org) for now, should the SF Bug Manager even be enabled? If it is enabled, and we are using Jitterbug, then someone has to own reentering SF bugs into the Jitterbug system. obviously y'rs - tim From gstein@lyra.org Wed Jun 28 07:47:06 2000 From: gstein@lyra.org (Greg Stein) Date: Tue, 27 Jun 2000 23:47:06 -0700 Subject: [Python-Dev] C# (new language from Microsoft) In-Reply-To: ; from tim_one@email.msn.com on Wed, Jun 28, 2000 at 02:23:38AM -0400 References: Message-ID: <20000627234706.N29590@lyra.org> On Wed, Jun 28, 2000 at 02:23:38AM -0400, Tim Peters wrote: > [Mark Hammond] > > ... > > * Python has a very good and interesting story in all this - there is no > > need to be alarmed. If anything, be excited :-) > > I was never worried about Python, but I lay awake at night worrying about > MS -- I'm still an MS shareholder, so don't screw this up . I'm an MS shareholder, too. Oh. Wait. Did I say I was involved? Don't think so... ahem. -g -- Greg Stein, http://www.lyra.org/ From andy@reportlab.com Wed Jun 28 08:03:07 2000 From: andy@reportlab.com (Andy Robinson) Date: Wed, 28 Jun 2000 08:03:07 +0100 Subject: [Python-Dev] SourceForge win32 HOWTO Message-ID: Sorry, I've been offline and missed this thread. I could have saved you some time. These are the instructions we've used at ReportLab to work with SourceForge on Win32. No problems so far despite several Unix and CVS newbies, myself included. They are adapted from an article by Jay Andrew Kay somewhere on Sourceforge and are generic rather than specific to the Python source. I have used the ReportLab project and my user name as an example but I'm sure you guys can adapt that.... 1. Get ftp.reportlab.com/tools/cvs-1.10-win.zip and ftp.reportlab.com/tools/ssh-1.2.14-win32bin.zip (copied from somewhere obscure for safety, I forget where) 2. Unzip these to a location on your path. Type 'cvs' or 'shh' from somewhere else to verify. 3. Choose where to keep your CVS projects; let's assume C:\code 4. Create a subdirectory c:\code\.ssh (yes, dot-ssh) 5. Create two environment variables: HOME=C:\CODE CVS_RSH=SSH On Win9x, this can be done in a batch file or autoexec.bat; on NT or 2000, go to Control Panel | System | Environment and set them at either user or machine level. The first must point to the directory above your .ssh directory. 6. If not done so, get a Sourceforge account and a project you can log in to. 7. Test SSH independently by doing SSH -l username myproject.sourceforge.net It should prompt for a password, then tell you that "myproject.sourceforge.net" is added to the list of known hosts; then give you a shell. 8. You will need either a lengthy command line or a batch file for each sourceforge project. I set cvsroot in a batch file in my 'c:\code' directory, and have one such file for each CVS project I use (about ten of them!): ------cvsreportlab.bat-------------- set HOME=C:\CODE set CVS_RSH=SSH set CVSROOT=:ext:my_user_name@cvs.myproject.sourceforge.net:/cvsroot/dirname --------------------------------------- 'dirname' is the top level directory in the CVS tree; a project can have several, but usually there is just one. 9. execute this batch file. You can now go to C:\Code and do cvs -z7 checkout myproject (z7 means 'compress network traffic', handy over dialup lines) 10. From now on, just use CVS normally. I wouldn't survive without Karl Fogel's book "Open Source Development with CVS", Coriolis Press. Footnote: for anonymous checkout, I think you just omit the 'my_user_name@' part from the CVSROOT variable. I hope this helps; let me know if people have any problems with the instructions. - Andy Robinson ReportLab From andy@reportlab.com Wed Jun 28 08:03:08 2000 From: andy@reportlab.com (Andy Robinson) Date: Wed, 28 Jun 2000 08:03:08 +0100 Subject: [Python-Dev] Sourceforge Interface Concerns In-Reply-To: <20000628025304.BB64A1CE0D@dinsdale.python.org> Message-ID: I missed all the SourceForge discussions, but ReportLab have been running all our development on SourceForge for five months and I'd like to share some concerns. First, we all use command line CVS, mostly from Windows; I just posted our setup instructions. It works fine but a bit slowly. I find the web interface totally unusable from IE5 and Netscape 4.XX, working over 64k lines or dialup lines. Once one logs in via SSL, only about one click in five ever returns a sensible page, and most just time out and give an error message. Many other people on the reportlab-users list and my team report similar problems. On the other hand, many are incredulous and say they have never had a problem. I found no complaints on the SF discussion groups, but as far as I can tell hardly anyone uses them. It seems to be better over big corporate connections. I don't think it is because I am in Europe; we never have trouble with our US ISPs. As a result of this, we have not used the wonderful looking bug tracking, to-do-list, patch manager etc. How many people here have actually created accounts for themselves on SourceForge and tried to do stuff when logged in - raise bugs and so on? Did it work for you? We ought to get a few data points before making this the way Python is managed. - Andy Robinson From nhodgson@bigpond.net.au Wed Jun 28 08:23:52 2000 From: nhodgson@bigpond.net.au (Neil Hodgson) Date: Wed, 28 Jun 2000 17:23:52 +1000 Subject: [Python-Dev] Sourceforge Interface Concerns References: Message-ID: <002401bfe0d1$d05a9fd0$e3cb8490@neil> > How many people here have actually created accounts for themselves on > SourceForge and tried to do stuff when logged in - raise bugs and so on? > Did it work for you? We ought to get a few data points before making this > the way Python is managed. Its generally quite good for me now that I've upgraded from a modem to a cable connection although there are brown-out periods. The only web browser I have any success with is Navigator 4.6 and 4.7. Both IE and Mozilla give poor results with SSL login. As far as getting other people to use the bug logger, its been a complete failure. Its much easier to email me or the mailing list. Some parts of SourceForge such as the file release upload are quite poorly designed and are too unpleasant to use on a slow connection if you have several packages for each release. Neil From tpeters@beopen.com Wed Jun 28 08:28:10 2000 From: tpeters@beopen.com (Tim Peters) Date: Wed, 28 Jun 2000 03:28:10 -0400 Subject: [Python-Dev] SourceForge win32 HOWTO In-Reply-To: Message-ID: [Andy Robinson] > Sorry, I've been offline and missed this thread. I could have saved you > some time. These are the instructions we've used at ReportLab to work with > SourceForge on Win32. No problems so far despite several Unix and CVS > newbies, myself included. ... Thanks, Andy! I just *knew* that if I sat on my ass, someone would solve this one for me . I'll give these instructions a try, and also see what it takes to adapt them to wincvs. Note that I'm going to be putting similar (perhaps, by an amazing coincidence, even identical) instructions up on pythonlabs.com, so if you want to stop maintaining this, dump it on me. From tpeters@beopen.com Wed Jun 28 08:28:26 2000 From: tpeters@beopen.com (Tim Peters) Date: Wed, 28 Jun 2000 03:28:26 -0400 Subject: [Python-Dev] Sourceforge Interface Concerns In-Reply-To: Message-ID: [Andy Robinson] > ... > I find the web interface totally unusable from IE5 and Netscape 4.XX, > working over 64k lines or dialup lines. Once one logs in via SSL, only > about one click in five ever returns a sensible page, and most > just time out and give an error message. Many other people on the > reportlab-users list and my team report similar problems. On the other > hand, many are incredulous and say they have never had a problem. > I found no complaints on the SF discussion groups, but as far as I can > tell hardly anyone uses them. It seems to be better over big corporate > connections. I don't think it is because I am in Europe; we never have > trouble with our US ISPs. I'm in the middle: sometimes it works great, sometimes slow as molasses (IE5 via 56K modem on the other side of the country), and an error each one of two clicks. Greg Stein lives near it, and reports wonderful access via DSL. > As a result of this, we have not used the wonderful looking bug tracking, > to-do-list, patch manager etc. They're actually pretty feeble. > How many people here have actually created accounts for themselves on > SourceForge and tried to do stuff when logged in - raise bugs and so on? > Did it work for you? We ought to get a few data points before making this > the way Python is managed. We're not using the bug tracker, task list, news, forum or support managers. Just the CVS tree and the patch manager. There are particular reasons for using those particular two, and I doubt we'll be moving more there until SF gets better. OTOH, we're also interested in *helping* SF get better! SF is as much an Open Source project as Python, and it could become an incredible resource for the entire OS community. doesn't-mean-i-won't-gripe-too-though-ly y'rs - tim From gstein@lyra.org Wed Jun 28 09:04:07 2000 From: gstein@lyra.org (Greg Stein) Date: Wed, 28 Jun 2000 01:04:07 -0700 Subject: [Python-Dev] Sourceforge Interface Concerns In-Reply-To: ; from tim_one@email.msn.com on Wed, Jun 28, 2000 at 03:28:26AM -0400 References: Message-ID: <20000628010407.T29590@lyra.org> On Wed, Jun 28, 2000 at 03:28:26AM -0400, Tim Peters wrote: >... > We're not using the bug tracker, task list, news, forum or support managers. > Just the CVS tree and the patch manager. There are particular reasons for > using those particular two, and I doubt we'll be moving more there until SF > gets better. OTOH, we're also interested in *helping* SF get better! SF is > as much an Open Source project as Python, and it could become an incredible > resource for the entire OS community. This last statement is (unfortunately) not quite true. SourceForge is developed in a closed, cathedral environment. There is no CVS access to it, and all the developers work at VA Linux. Strictly speaking, the *output* of this closed development is GPL'd. But it isn't what you would expect. The documentation for SF is separate. Apparently, there was an independent effort to help do some documentation and they got a good ways. Then the VA guys suddenly popped out the "SFDocs" project, ignoring the work from the other people. Not sure where I read that, so I can't provide a reference to the stories/threads :-( btw, there is a survey about SF that you can fill out: http://sourceforge.net/survey/survey.php?group_id=1&survey_id=10599 Cheers, -g -- Greg Stein, http://www.lyra.org/ From mal@lemburg.com Wed Jun 28 09:03:00 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 28 Jun 2000 10:03:00 +0200 Subject: [Python-Dev] SF patch manager... References: Message-ID: <3959B134.1538B4B7@lemburg.com> Tim Peters wrote: > > [MAL] > > [Please excuse my ranting... :-)] > > No problem -- you're not complaining about *our* software . > > > I've received the first round of notification message from the > > patch manager and can't really say that I like them. Ok, I > > understand that the patch manager is still alpha or beta software, > > but these messages really don't have any usable content at all: > > > > """ > > Patch #100646 has been updated. > > Visit SourceForge.net for more info. > > > > > http://sourceforge.net/patch/?func=detailpatch&patch_id=100646&group_id=5470 > > """ > > I expect the title of the patch was also in the Subject line, yes? Right, but that's just about all the information you get: the title, the fact that something changed and a link to the patch page. > And a > live link to the patch is certainly "usable". I've found both those right > on target as I've been assigned or deassigned to patches so far, although > I'd sure like to see something in the body saying exactly *what* about the > patch "has been updated". > > Not saying I think it's good enough, am saying it's (barely) a start. True and I don't want to put this down. The only reason for my ranting is that I'd rather get more infos in mail than via some link to a page. Discussing patches via quoting email is just so much more convenient -- opening two or three browsers to get at the hard facts isn't and, as others have already noted, is rather slow too. > > Also, reviewing the patches has become a pain > > I don't understand that, in that the text of the patch is what you got > before, and what you can get now. Is your complaint here specifically that > patches don't show up in your mailbox by magic? Or something else? I would very much prefer to get the patches or changes appended to the update messages (much like was manually done on patches@python.org). That way I can read the patch and then reply to the sender and the list community from within the mail application -- without copy&paste, looking up email addresses in SF etc. > > and discussing them is nearly impossible (I don't consider the > > slashdot like comment mechanism to be of any use: there's simply > > no audience for discussion). > > Wholly agreed there. So use python-dev for discussions for now; I agree too > with Guido that the rampant but inconsistent x-posting between patches and > python-dev was part of the problem. > > > Is there any chance of tee'ing patches from SF to the patches > > list or some other patch discussion and review forum ? > > I expect you know as much about SF's possibilities as anyone <0.5 wink>: > don't know. The SF docs are either non-existent or inadequate, far as I can > tell, and I believe I share a mistaken belief with Fred Drake that new > patches "should" *already* be showing up on the patches list. They are showing up there... at least new ones are. Discussions (via posting comments on the patch page) are not relayed to the list though: only the comment authors get an email. > > I do understand that the mechanism can help with patch *checkins*, > > Yes, but not yet as much as it should (e.g., the default view of patches > lacks basic info like the patch current status, and there's apparently not > yet any way to define a different view). > > > but it's certainly not going to help much with the discussion > > step needed before conidering any actions. > > Python-Dev now, possibly roundup later. OTOH, it's perfectly adequate for > tiny little principal-reviewer <-> submitter give-and-take; many patches are > really quite trivial. True, but even small patches occasionally need peer review from more people than just the assigned developer. > > The independent peer review principal doesn't work with this > > kind of setup. > > I think your view is warped on this one, as you've been in the extremely > favored position of pumping out crucial patches for a hot area. Most other > peoples' patches have been flatly ignored for *months* now. It's not > necessarily bad if other people get some attention now too . Oops, did it shine through that much ? ;-) Seriously, I would like to see a processing speedup too, it's just the workflow that bothers me a bit. BTW, another great feature for the patch manager would be a button to perform the actual checkin via the web interface. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From rob@hooft.net Wed Jun 28 10:27:18 2000 From: rob@hooft.net (Rob W. W. Hooft) Date: Wed, 28 Jun 2000 11:27:18 +0200 (CEST) Subject: [Python-Dev] Typo's Message-ID: <14681.50422.966321.780406@temoleh.chem.uu.nl> I located some typo's in the CVS. Here is a patch. Warning: I'm a non-native English speaker. Please verify fixes. Rob Index: Demo/pdist/rcslib.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Demo/pdist/rcslib.py,v retrieving revision 1.6 diff -u -r1.6 rcslib.py --- Demo/pdist/rcslib.py 1998/09/14 16:43:57 1.6 +++ Demo/pdist/rcslib.py 2000/06/28 07:42:50 @@ -296,7 +296,7 @@ def _system(self, cmd): """INTERNAL: run COMMAND in a subshell. - Standard input for the command is taken fron /dev/null. + Standard input for the command is taken from /dev/null. Raise IOError when the exit status is not zero. Index: Demo/sgi/video/Vcopy.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Demo/sgi/video/Vcopy.py,v retrieving revision 1.7 diff -u -r1.7 Vcopy.py --- Demo/sgi/video/Vcopy.py 1996/11/27 19:50:07 1.7 +++ Demo/sgi/video/Vcopy.py 2000/06/28 07:42:50 @@ -8,7 +8,7 @@ # - Manipulate the time base: # = resample at a fixed rate # = divide the time codes by a speed factor (to make it go faster/slower) -# = drop frames that are less than n msec apart (to accomodate slow players) +# = drop frames that are less than n msec apart (to accommodate slow players) # - Convert to a different format # - Magnify (scale) the image Index: Demo/sgi/video/Vtime.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Demo/sgi/video/Vtime.py,v retrieving revision 1.4 diff -u -r1.4 Vtime.py --- Demo/sgi/video/Vtime.py 1996/11/27 19:50:28 1.4 +++ Demo/sgi/video/Vtime.py 2000/06/28 07:42:50 @@ -7,7 +7,7 @@ # # - resample at a fixed rate # - divide the time codes by a speed factor (to make it go faster/slower) -# - drop frames that are less than n msec apart (to accomodate slow players) +# - drop frames that are less than n msec apart (to accommodate slow players) # Usage: Index: Lib/Queue.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/Queue.py,v retrieving revision 1.10 diff -u -r1.10 Queue.py --- Lib/Queue.py 2000/02/02 15:10:14 1.10 +++ Lib/Queue.py 2000/06/28 07:42:51 @@ -119,7 +119,7 @@ def _qsize(self): return len(self.queue) - # Check wheter the queue is empty + # Check whether the queue is empty def _empty(self): return not self.queue Index: Lib/binhex.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/binhex.py,v retrieving revision 1.12 diff -u -r1.12 binhex.py --- Lib/binhex.py 2000/02/04 15:39:29 1.12 +++ Lib/binhex.py 2000/06/28 07:42:51 @@ -13,7 +13,7 @@ # XXXX Note: currently, textfiles appear in mac-form on all platforms. # We seem to lack a simple character-translate in python. # (we should probably use ISO-Latin-1 on all but the mac platform). -# XXXX The simeple routines are too simple: they expect to hold the complete +# XXXX The simple routines are too simple: they expect to hold the complete # files in-core. Should be fixed. # XXXX It would be nice to handle AppleDouble format on unix # (for servers serving macs). @@ -48,7 +48,7 @@ try: openrf = MacOS.openrf except AttributeError: - # Backward compatability + # Backward compatibility openrf = open def FInfo(): Index: Lib/calendar.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/calendar.py,v retrieving revision 1.15 diff -u -r1.15 calendar.py --- Lib/calendar.py 2000/02/02 15:10:14 1.15 +++ Lib/calendar.py 2000/06/28 07:42:51 @@ -1,6 +1,6 @@ """Calendar printing functions""" -# Revision 2: uses funtions from built-in time module +# Revision 2: uses functions from built-in time module # Import functions and variables from time module from time import localtime, mktime Index: Lib/fnmatch.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/fnmatch.py,v retrieving revision 1.7 diff -u -r1.7 fnmatch.py --- Lib/fnmatch.py 1997/10/22 20:57:40 1.7 +++ Lib/fnmatch.py 2000/06/28 07:42:51 @@ -36,7 +36,7 @@ return fnmatchcase(name, pat) def fnmatchcase(name, pat): - """Test wheter FILENAME matches PATTERN, including case. + """Test whether FILENAME matches PATTERN, including case. This is a version of fnmatch() which doesn't case-normalize its arguments. Index: Lib/locale.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/locale.py,v retrieving revision 1.6 diff -u -r1.6 locale.py --- Lib/locale.py 2000/06/08 17:49:41 1.6 +++ Lib/locale.py 2000/06/28 07:42:52 @@ -220,7 +220,7 @@ The language code corresponds to RFC 1766. code and encoding can be None in case the values cannot be determined or are - unkown to this implementation. + unknown to this implementation. """ code = normalize(localename) @@ -229,7 +229,7 @@ elif code == 'C': return None, None else: - raise ValueError,'unkown locale: %s' % localename + raise ValueError,'unknown locale: %s' % localename return l def _build_localename(localetuple): Index: Lib/posixpath.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/posixpath.py,v retrieving revision 1.30 diff -u -r1.30 posixpath.py --- Lib/posixpath.py 2000/02/29 13:31:16 1.30 +++ Lib/posixpath.py 2000/06/28 07:42:52 @@ -24,7 +24,7 @@ return s -# Return wheter a path is absolute. +# Return whether a path is absolute. # Trivial in Posix, harder on the Mac or MS-DOS. def isabs(s): @@ -304,7 +304,7 @@ # Expand paths containing shell variable substitutions. # This expands the forms $variable and ${variable} only. -# Non-existant variables are left unchanged. +# Non-existent variables are left unchanged. _varprog = None Index: Lib/sgmllib.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/sgmllib.py,v retrieving revision 1.19 diff -u -r1.19 sgmllib.py --- Lib/sgmllib.py 2000/02/04 15:28:40 1.19 +++ Lib/sgmllib.py 2000/06/28 07:42:53 @@ -47,7 +47,7 @@ # and , respectively, or do_foo to handle by itself. # (Tags are converted to lower case for this purpose.) The data # between tags is passed to the parser by calling self.handle_data() -# with some data as argument (the data may be split up in arbutrary +# with some data as argument (the data may be split up in arbitrary # chunks). Entity references are passed by calling # self.handle_entityref() with the entity reference as argument. Index: Lib/site.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/site.py,v retrieving revision 1.11 diff -u -r1.11 site.py --- Lib/site.py 2000/06/07 09:12:09 1.11 +++ Lib/site.py 2000/06/28 07:42:53 @@ -122,7 +122,7 @@ # # Set the string encoding used by the Unicode implementation to the # encoding used by the default locale of this system. If the default -# encoding cannot be determined or is unkown, it defaults to 'ascii'. +# encoding cannot be determined or is unknown, it defaults to 'ascii'. # def locale_aware_defaultencoding(): import locale Index: Lib/urllib2.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/urllib2.py,v retrieving revision 1.3 diff -u -r1.3 urllib2.py --- Lib/urllib2.py 2000/02/10 17:17:14 1.3 +++ Lib/urllib2.py 2000/06/28 07:42:54 @@ -141,7 +141,7 @@ _opener = opener # do these error classes make sense? -# make sure all of the IOError stuff is overriden. we just want to be +# make sure all of the IOError stuff is overridden. we just want to be # subtypes. class URLError(IOError): Index: Lib/xmllib.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/xmllib.py,v retrieving revision 1.18 diff -u -r1.18 xmllib.py --- Lib/xmllib.py 2000/06/21 20:01:10 1.18 +++ Lib/xmllib.py 2000/06/28 07:42:54 @@ -79,7 +79,7 @@ # special names to handle tags: start_foo and end_foo to handle # and , respectively. The data between tags is passed to the # parser by calling self.handle_data() with some data as argument (the -# data may be split up in arbutrary chunks). +# data may be split up in arbitrary chunks). class XMLParser: attributes = {} # default, to be overridden Index: Lib/distutils/cmd.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/distutils/cmd.py,v retrieving revision 1.18 diff -u -r1.18 cmd.py --- Lib/distutils/cmd.py 2000/06/08 00:02:36 1.18 +++ Lib/distutils/cmd.py 2000/06/28 07:42:55 @@ -323,7 +323,7 @@ should be disabled by the "dry run" flag, and should announce themselves if the current verbosity level is high enough. This method takes care of all that bureaucracy for you; all you have to - do is supply the funtion to call and an argument tuple for it (to + do is supply the function to call and an argument tuple for it (to embody the "external action" being performed), a message to print if the verbosity level is high enough, and an optional verbosity threshold. Index: Lib/distutils/util.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/distutils/util.py,v retrieving revision 1.37 diff -u -r1.37 util.py --- Lib/distutils/util.py 2000/06/24 20:40:02 1.37 +++ Lib/distutils/util.py 2000/06/28 07:42:55 @@ -28,7 +28,7 @@ return os.path.normpath(path) -# More backwards compatability hacks +# More backwards compatibility hacks def extend (list, new_list): """Appends the list 'new_list' to 'list', just like the 'extend()' list method does in Python 1.5.2 -- but this works on earlier Index: Lib/distutils/version.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/distutils/version.py,v retrieving revision 1.1 diff -u -r1.1 version.py --- Lib/distutils/version.py 1998/12/18 22:00:30 1.1 +++ Lib/distutils/version.py 2000/06/28 07:42:55 @@ -207,7 +207,7 @@ # provides enough benefit to be worth using, and will submit their # version numbering scheme to its domination. The free-thinking # anarchists in the lot will never give in, though, and something needs -# to be done to accomodate them. +# to be done to accommodate them. # # Perhaps a "moderately strict" version class could be implemented that # lets almost anything slide (syntactically), and makes some heuristic Index: Lib/distutils/command/build_ext.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/distutils/command/build_ext.py,v retrieving revision 1.51 diff -u -r1.51 build_ext.py --- Lib/distutils/command/build_ext.py 2000/06/28 01:29:37 1.51 +++ Lib/distutils/command/build_ext.py 2000/06/28 07:42:56 @@ -1,7 +1,7 @@ """distutils.command.build_ext Implements the Distutils 'build_ext' command, for building extension -modules (currently limited to C extensions, should accomodate C++ +modules (currently limited to C extensions, should accommodate C++ extensions ASAP).""" # created 1999/08/09, Greg Ward @@ -385,7 +385,7 @@ # Next, compile the source code to object files. # XXX not honouring 'define_macros' or 'undef_macros' -- the - # CCompiler API needs to change to accomodate this, and I + # CCompiler API needs to change to accommodate this, and I # want to do one thing at a time! # Two possible sources for extra compiler arguments: Index: Lib/dos-8x3/posixpat.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/dos-8x3/posixpat.py,v retrieving revision 1.10 diff -u -r1.10 posixpat.py --- Lib/dos-8x3/posixpat.py 2000/05/08 17:31:00 1.10 +++ Lib/dos-8x3/posixpat.py 2000/06/28 07:42:56 @@ -24,7 +24,7 @@ return s -# Return wheter a path is absolute. +# Return whether a path is absolute. # Trivial in Posix, harder on the Mac or MS-DOS. def isabs(s): @@ -304,7 +304,7 @@ # Expand paths containing shell variable substitutions. # This expands the forms $variable and ${variable} only. -# Non-existant variables are left unchanged. +# Non-existent variables are left unchanged. _varprog = None Index: Lib/dos-8x3/queue.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/dos-8x3/queue.py,v retrieving revision 1.7 diff -u -r1.7 queue.py --- Lib/dos-8x3/queue.py 2000/05/08 17:31:00 1.7 +++ Lib/dos-8x3/queue.py 2000/06/28 07:42:56 @@ -119,7 +119,7 @@ def _qsize(self): return len(self.queue) - # Check wheter the queue is empty + # Check whether the queue is empty def _empty(self): return not self.queue Index: Lib/dos-8x3/test_win.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/dos-8x3/test_win.py,v retrieving revision 1.1 diff -u -r1.1 test_win.py --- Lib/dos-8x3/test_win.py 2000/05/08 17:31:03 1.1 +++ Lib/dos-8x3/test_win.py 2000/06/28 07:42:57 @@ -115,7 +115,7 @@ # Opening should now fail! try: key = OpenKey(root_key, test_key_name) - assert 0, "Could open the non-existant key" + assert 0, "Could open the non-existent key" except WindowsError: # Use this error name this time pass Index: Lib/dos-8x3/test_zli.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/dos-8x3/test_zli.py,v retrieving revision 1.5 diff -u -r1.5 test_zli.py --- Lib/dos-8x3/test_zli.py 2000/05/08 17:31:03 1.5 +++ Lib/dos-8x3/test_zli.py 2000/06/28 07:42:57 @@ -11,7 +11,7 @@ buf = file.read() * 8 file.close() -# test the chucksums (hex so the test doesn't break on 64-bit machines) +# test the checksums (hex so the test doesn't break on 64-bit machines) print hex(zlib.crc32('penguin')), hex(zlib.crc32('penguin', 1)) print hex(zlib.adler32('penguin')), hex(zlib.adler32('penguin', 1)) Index: Lib/plat-irix5/CL_old.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/plat-irix5/CL_old.py,v retrieving revision 1.1 diff -u -r1.1 CL_old.py --- Lib/plat-irix5/CL_old.py 1995/05/17 11:18:22 1.1 +++ Lib/plat-irix5/CL_old.py 2000/06/28 07:42:57 @@ -200,7 +200,7 @@ BOTTOM_UP = 1 # -# SGI Proprietaty Algorithm Header Start Code +# SGI Proprietary Algorithm Header Start Code # HEADER_START_CODE = 0xc1C0DEC Index: Lib/plat-irix5/flp.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/plat-irix5/flp.py,v retrieving revision 1.17 diff -u -r1.17 flp.py --- Lib/plat-irix5/flp.py 1998/03/26 20:22:58 1.17 +++ Lib/plat-irix5/flp.py 2000/06/28 07:42:57 @@ -203,7 +203,7 @@ return datum[1] # # Internal: parse fd form, or skip if name doesn't match. -# the special value None means 'allways parse it'. +# the special value None means 'always parse it'. # def _parse_fd_form(file, name): datum = _parse_1_line(file) @@ -222,7 +222,7 @@ return None # -# Internal class: a convient place to store object info fields +# Internal class: a convenient place to store object info fields # class _newobj: def add(self, name, value): Index: Lib/plat-irix5/panel.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/plat-irix5/panel.py,v retrieving revision 1.4 diff -u -r1.4 panel.py --- Lib/plat-irix5/panel.py 1995/09/18 22:00:37 1.4 +++ Lib/plat-irix5/panel.py 2000/06/28 07:42:58 @@ -2,7 +2,7 @@ # # Support for the Panel library. # Uses built-in module 'pnl'. -# Applciations should use 'panel.function' instead of 'pnl.function'; +# Applications should use 'panel.function' instead of 'pnl.function'; # most 'pnl' functions are transparently exported by 'panel', # but dopanel() is overridden and you have to use this version # if you want to use callbacks. @@ -137,7 +137,7 @@ print 'assign failed:', stmt -# Build a real actuator from an actuator descriptior. +# Build a real actuator from an actuator description. # Return a pair (actuator, name). # def build_actuator(descr): Index: Lib/plat-irix6/flp.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/plat-irix6/flp.py,v retrieving revision 1.4 diff -u -r1.4 flp.py --- Lib/plat-irix6/flp.py 1998/03/26 20:23:01 1.4 +++ Lib/plat-irix6/flp.py 2000/06/28 07:42:58 @@ -203,7 +203,7 @@ return datum[1] # # Internal: parse fd form, or skip if name doesn't match. -# the special value None means 'allways parse it'. +# the special value None means 'always parse it'. # def _parse_fd_form(file, name): datum = _parse_1_line(file) @@ -222,7 +222,7 @@ return None # -# Internal class: a convient place to store object info fields +# Internal class: a convenient place to store object info fields # class _newobj: def add(self, name, value): Index: Lib/plat-irix6/panel.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/plat-irix6/panel.py,v retrieving revision 1.1 diff -u -r1.1 panel.py --- Lib/plat-irix6/panel.py 1997/01/15 19:19:11 1.1 +++ Lib/plat-irix6/panel.py 2000/06/28 07:42:58 @@ -2,7 +2,7 @@ # # Support for the Panel library. # Uses built-in module 'pnl'. -# Applciations should use 'panel.function' instead of 'pnl.function'; +# Applications should use 'panel.function' instead of 'pnl.function'; # most 'pnl' functions are transparently exported by 'panel', # but dopanel() is overridden and you have to use this version # if you want to use callbacks. @@ -137,7 +137,7 @@ print 'assign failed:', stmt -# Build a real actuator from an actuator descriptior. +# Build a real actuator from an actuator description. # Return a pair (actuator, name). # def build_actuator(descr): Index: Lib/test/test_al.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/test/test_al.py,v retrieving revision 1.2 diff -u -r1.2 test_al.py --- Lib/test/test_al.py 1998/03/26 19:41:38 1.2 +++ Lib/test/test_al.py 2000/06/28 07:42:58 @@ -8,7 +8,7 @@ alattrs = ['__doc__', '__name__', 'getdefault', 'getminmax', 'getname', 'getparams', 'newconfig', 'openport', 'queryparams', 'setparams'] -# This is a very inobstrusive test for the existance of the al module and all it's +# This is a very inobtrusive test for the existence of the al module and all it's # attributes. More comprehensive examples can be found in Demo/al def main(): Index: Lib/test/test_b1.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/test/test_b1.py,v retrieving revision 1.22 diff -u -r1.22 test_b1.py --- Lib/test/test_b1.py 2000/04/14 19:13:22 1.22 +++ Lib/test/test_b1.py 2000/06/28 07:42:58 @@ -270,7 +270,7 @@ # Different base: if int("10",16) <> 16L: raise TestFailed, 'int("10",16)' if int(u"10",16) <> 16L: raise TestFailed, 'int(u"10",16)' -# Test conversion fron strings and various anomalies +# Test conversion from strings and various anomalies L = [ ('0', 0), ('1', 1), Index: Lib/test/test_cd.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/test/test_cd.py,v retrieving revision 1.2 diff -u -r1.2 test_cd.py --- Lib/test/test_cd.py 1998/03/26 19:41:49 1.2 +++ Lib/test/test_cd.py 2000/06/28 07:42:58 @@ -10,7 +10,7 @@ 'ident', 'index', 'msftoframe', 'open', 'pnum', 'ptime'] -# This is a very inobstrusive test for the existance of the cd module and all it's +# This is a very inobtrusive test for the existence of the cd module and all it's # attributes. More comprehensive examples can be found in Demo/cd and # require that you have a CD and a CD ROM drive Index: Lib/test/test_cl.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/test/test_cl.py,v retrieving revision 1.2 diff -u -r1.2 test_cl.py --- Lib/test/test_cl.py 1998/03/26 19:41:52 1.2 +++ Lib/test/test_cl.py 2000/06/28 07:42:58 @@ -63,7 +63,7 @@ 'YUV422DC', 'YUV422HC', '__doc__', '__name__', 'cvt_type', 'error'] -# This is a very inobstrusive test for the existance of the cl +# This is a very inobtrusive test for the existence of the cl # module and all it's attributes. def main(): Index: Lib/test/test_pwd.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/test/test_pwd.py,v retrieving revision 1.5 diff -u -r1.5 test_pwd.py --- Lib/test/test_pwd.py 1998/03/26 19:42:32 1.5 +++ Lib/test/test_pwd.py 2000/06/28 07:42:58 @@ -59,7 +59,7 @@ else: print 'fakename', fakename, 'did not except pwd.getpwnam()' -# Choose a non-existant uid. +# Choose a non-existent uid. fakeuid = 4127 while byuids.has_key(fakeuid): fakeuid = (fakeuid * 3) % 0x10000 Index: Lib/test/test_winreg.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/test/test_winreg.py,v retrieving revision 1.2 diff -u -r1.2 test_winreg.py --- Lib/test/test_winreg.py 2000/04/01 05:25:57 1.2 +++ Lib/test/test_winreg.py 2000/06/28 07:42:58 @@ -115,7 +115,7 @@ # Opening should now fail! try: key = OpenKey(root_key, test_key_name) - assert 0, "Could open the non-existant key" + assert 0, "Could open the non-existent key" except WindowsError: # Use this error name this time pass Index: Lib/test/test_zlib.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/test/test_zlib.py,v retrieving revision 1.7 diff -u -r1.7 test_zlib.py --- Lib/test/test_zlib.py 2000/02/10 15:31:07 1.7 +++ Lib/test/test_zlib.py 2000/06/28 07:42:59 @@ -11,7 +11,7 @@ buf = file.read() * 8 file.close() -# test the chucksums (hex so the test doesn't break on 64-bit machines) +# test the checksums (hex so the test doesn't break on 64-bit machines) print hex(zlib.crc32('penguin')), hex(zlib.crc32('penguin', 1)) print hex(zlib.adler32('penguin')), hex(zlib.adler32('penguin', 1)) Index: Python/exceptions.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/exceptions.c,v retrieving revision 1.2 diff -u -r1.2 exceptions.c --- Python/exceptions.c 2000/06/20 18:36:26 1.2 +++ Python/exceptions.c 2000/06/28 07:42:59 @@ -189,7 +189,7 @@ * * First thing we create is the base class for all exceptions, called * appropriately enough: Exception. Creation of this class makes no - * assumptions about the existance of any other exception class -- except + * assumptions about the existence of any other exception class -- except * for TypeError, which can conditionally exist. * * Next, StandardError is created (which is quite simple) followed by Index: Python/import.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/import.c,v retrieving revision 2.134 diff -u -r2.134 import.c --- Python/import.c 2000/05/03 23:44:39 2.134 +++ Python/import.c 2000/06/28 07:43:01 @@ -87,7 +87,7 @@ #define MAGIC (50428 | ((long)'\r'<<16) | ((long)'\n'<<24)) /* Magic word as global; note that _PyImport_Init() can change the - value of this global to accomodate for alterations of how the + value of this global to accommodate for alterations of how the compiler works which are enabled by command line switches. */ static long pyc_magic = MAGIC; From Fredrik Lundh" Message-ID: <012f01bfe0e5$e3dce360$f2a6b5d4@hagrid> > I located some typo's in the CVS. Here is a patch. wow! just one nit: "inobstrusive" should be "unobtrusive" (not "inobtrusive") (and it's not clear if "descriptior" means "description" or "descriptor"...) > Warning: I'm a non-native English speaker. same here. From Fredrik Lundh" http://prometheus.frii.com/~gnat/yapc/2000-p5p.txt unfortunately, his "What is it with those Python fucks anyway" talk isn't posted... ;-) From fdrake@beopen.com Wed Jun 28 12:16:53 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Wed, 28 Jun 2000 07:16:53 -0400 (EDT) Subject: [Python-Dev] back up & running Message-ID: <14681.56997.50955.892954@cj42289-a.reston1.va.home.com> My mega-laptop got fixed faster than I'd expected, so I'm back up to doing useful work. My top priorities are handling patches and going back through my email to find all the documentation patches that have sat idle for too long. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From mwh21@cam.ac.uk Wed Jun 28 12:54:27 2000 From: mwh21@cam.ac.uk (Michael Hudson) Date: 28 Jun 2000 12:54:27 +0100 Subject: [Python-Dev] Sourceforge Interface Concerns In-Reply-To: "Andy Robinson"'s message of "Wed, 28 Jun 2000 08:03:08 +0100" References: Message-ID: "Andy Robinson" writes: > It seems to be better over big corporate connections. I don't think it is > because I am in Europe; we never have trouble with our US ISPs. FWIW, it's pretty good from here (but then the university has pretty serious bandwidth). It seems a bit odd that it's so much worse with lower badwidth (in particular that people on modems get more errors). Oh well. Cheers, M. From Vladimir.Marangozov@inrialpes.fr Wed Jun 28 13:22:56 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Wed, 28 Jun 2000 14:22:56 +0200 (CEST) Subject: [Python-Dev] back up & running In-Reply-To: <14681.56997.50955.892954@cj42289-a.reston1.va.home.com> from "Fred L. Drake, Jr." at Jun 28, 2000 07:16:53 AM Message-ID: <200006281222.OAA03150@python.inrialpes.fr> Fred L. Drake, Jr. wrote: > > My mega-laptop got fixed faster than I'd expected, so I'm back up to > doing useful work. My top priorities are handling patches and going > back through my email to find all the documentation patches that have > sat idle for too long. Excellent! Finally someone who cares to checkin patches. I've been disappointed to see that the June 30 intent-date was announced, but people keep chewing-gumming about SourceForge caveats while the patches backlog grows and the number of closed patches stays invariably to 3, of which one is a test! -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From bwarsaw@beopen.com Wed Jun 28 14:27:12 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Wed, 28 Jun 2000 09:27:12 -0400 (EDT) Subject: [Python-Dev] Sourceforge Interface Concerns References: <20000628025304.BB64A1CE0D@dinsdale.python.org> Message-ID: <14681.64816.561341.920024@anthem.concentric.net> >>>>> "AR" == Andy Robinson writes: AR> How many people here have actually created accounts for AR> themselves on SourceForge and tried to do stuff when logged in AR> - raise bugs and so on? Did it work for you? We ought to get AR> a few data points before making this the way Python is AR> managed. In general SF's web has been fine for me, although it is sometimes unavailable due to routing problems. I'm on a fairly reliable DSL line now, though I don't remember significantly more SF-blamable problems when I was on a 56K line. It's often quite slow to do CVS/SSH to SF. Sometimes I'll have to spin for several minutes just to do an update or a diff. That sucks. -Barry From fdrake@beopen.com Wed Jun 28 14:30:22 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Wed, 28 Jun 2000 09:30:22 -0400 (EDT) Subject: [Python-Dev] Sourceforge Interface Concerns In-Reply-To: References: <20000628025304.BB64A1CE0D@dinsdale.python.org> Message-ID: <14681.65006.782463.491824@cj42289-a.reston1.va.home.com> Andy Robinson writes: > I find the web interface totally unusable from IE5 and Netscape 4.XX, > working over 64k lines or dialup lines. Once one logs in via SSL, only > about one click in five ever returns a sensible page, and most just time out I've not been able to reproduce this behavior; the Web interface seems to work well with IE5 and Netscape 4.XX for me; the only problem I've had with IE5 is accessing a project's anonymous FTP area from the project page (IE5 just froze completely). Netscape didn't exhibit that problem for me and allowed perfectly reasonable use. Sometimes it seems a little slow, but I attribute that to load and the public-key crypto using SSH for CVS access; I understand that CVS doesn't have the most efficient wire-protocol either. I should note that I've mostly used it over T1 and cable modem links; I don't know that smaller pipes would make a huge difference though. I'd be more suspicious of trans-Atlantic linkage than anything else without having more information. Routing can do strange things, so you may be getting the worst-possible link for SourceForge while other things get better routes, but I wouldn't expect that to be terribly consistent. > How many people here have actually created accounts for themselves on > SourceForge and tried to do stuff when logged in - raise bugs and so on? > Did it work for you? We ought to get a few data points before making this > the way Python is managed. I've never had the kind of problems you describe. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From Vladimir.Marangozov@inrialpes.fr Wed Jun 28 14:58:26 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Wed, 28 Jun 2000 15:58:26 +0200 (CEST) Subject: [Python-Dev] Typo's In-Reply-To: <012f01bfe0e5$e3dce360$f2a6b5d4@hagrid> from "Fredrik Lundh" at Jun 28, 2000 11:47:32 AM Message-ID: <200006281358.PAA03368@python.inrialpes.fr> Fredrik Lundh wrote: > > > I located some typo's in the CVS. Here is a patch. > > wow! Wow, indeed. +1 I've uploaded this patch to SourceForge. > > just one nit: > > "inobstrusive" should be "unobtrusive" (not "inobtrusive") fixed in the patch. > > (and it's not clear if "descriptior" means "description" or > "descriptor"...) I examined the patched file - it's "description". > > > Warning: I'm a non-native English speaker. > > same here. same here :-) -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From guido@beopen.com Wed Jun 28 15:55:00 2000 From: guido@beopen.com (Guido van Rossum) Date: Wed, 28 Jun 2000 09:55:00 -0500 Subject: [Python-Dev] add Demo/imputil/importers.py ? In-Reply-To: Your message of "Tue, 27 Jun 2000 18:46:15 MST." <20000627184615.A29590@lyra.org> References: <20000627184615.A29590@lyra.org> Message-ID: <200006281455.JAA01690@cj20424-a.reston1.va.home.com> > A while back, I pulled the "demo" importers out of imputil.py. I think those > should be added into Demo/imputil/. OK. Go ahead and create that directory and add the demo importers. > It would also be Goodness to include JimA's zipimporter. Where would that go? Same place I'd hope? Can you check that it works? We're dependent on you volunteers to maintain relatively non-core things like this -- I don't want to extend the feature freeze to Demo/, but I also don't have the time to keep the stuff there up to date. Maybe at some point the Demo directory should become a separate distribution, or just a collection of stuff on the web? --Guido van Rossum (home page: http://www.python.org/~guido/) From akuchlin@mems-exchange.org Wed Jun 28 15:07:22 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Wed, 28 Jun 2000 10:07:22 -0400 Subject: [Python-Dev] Sourceforge Interface Concerns In-Reply-To: <14681.65006.782463.491824@cj42289-a.reston1.va.home.com> References: <20000628025304.BB64A1CE0D@dinsdale.python.org> <14681.65006.782463.491824@cj42289-a.reston1.va.home.com> Message-ID: <20000628100722.A9063@kronos.cnri.reston.va.us> On Wed, Jun 28, 2000 at 09:30:22AM -0400, Fred L. Drake, Jr. wrote: > I should note that I've mostly used it over T1 and cable modem >links; I don't know that smaller pipes would make a huge difference >though. At home I have a 28.8 modem (never figured out how to upgrade it to 56K), and while CVS operations are fairly slow, there usually aren't any problems. The same goes for accessing the Web pages through SSL; somewhat slow, but reliable. --amk From gward@mems-exchange.org Wed Jun 28 15:18:12 2000 From: gward@mems-exchange.org (Greg Ward) Date: Wed, 28 Jun 2000 10:18:12 -0400 Subject: [Python-Dev] Python 1.6 planning In-Reply-To: ; from jeremy@beopen.com on Fri, Jun 23, 2000 at 06:01:19PM -0400 References: Message-ID: <20000628101812.A15643@ludwig.cnri.reston.va.us> On 23 June 2000, Jeremy Hylton said: > ldso_aix-- I still don't understand, but I didn't really try; Vladimir must > help This has been fixed in the Distutils. AFAIK it's still broken for Makefile.pre.in builds -- as long as the installed Makefile is fixed (not the actual installation location of ld_so_aix), then Distutils builds will continue to work. (Thanks to Rene Liebscher for providing the Distutils fix, and Vladimir for testing it.) Greg From gward@mems-exchange.org Wed Jun 28 15:29:02 2000 From: gward@mems-exchange.org (Greg Ward) Date: Wed, 28 Jun 2000 10:29:02 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils util.py,1.36,1.37 In-Reply-To: <20000624151824.A29590@lyra.org>; from gstein@lyra.org on Sat, Jun 24, 2000 at 03:18:24PM -0700 References: <200006242040.NAA28315@slayer.i.sourceforge.net> <20000624151824.A29590@lyra.org> Message-ID: <20000628102901.B15643@ludwig.cnri.reston.va.us> On 24 June 2000, Greg Stein said: > Would the "shlex" module be helpful here? It is in the standard library and > is (well?) maintained by ESR. It could help reduce the code inside > distutils. I looked at "shlex", but didn't like the fact that it 1) does character-by-character analysis of input, and 2) requires a file-like object. Just a performance concern, really. > [ I've always questioned the need for distutils' own "copy file" functions > and whatnot... seems there is a bit of duplication occurring... ] Two reasons for that: bugs in the standard library versions, and missing features in the standard library versions. I think the first argument goes away now that I've given up on 1.5.1 compatibility (shutil.py was really broken in 1.5.1), but the fact remains that the copy functions in shutil.py don't have a dry_run option, don't have a verbose option, don't have a preserve_times option, don't have a preserve_symlinks option, etc. All of these things are somewhere between useful and necessary. I'm always open for ideas on reducing the amount of code in the Distutils; it really is getting ridiculous. It cracked 10k lines of code+comments+doc this weekend -- about 5300 lines of straight code, I think. Anyways, the basic required functionality is now in place, so I'm open to clever refactoring/reduction/simplification patches. Greg From guido@beopen.com Wed Jun 28 16:41:26 2000 From: guido@beopen.com (Guido van Rossum) Date: Wed, 28 Jun 2000 10:41:26 -0500 Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager In-Reply-To: Your message of "Wed, 28 Jun 2000 02:23:40 -0400." References: Message-ID: <200006281541.KAA02041@cj20424-a.reston1.va.home.com> > Since we (PythonLabs, last week) decided to continue using Jitterbug (on > python.org) for now, should the SF Bug Manager even be enabled? If it is > enabled, and we are using Jitterbug, then someone has to own reentering SF > bugs into the Jitterbug system. OK, I've disabled the SF bugs manager. There were two bugs submitted so far. I've assigned one to you (about os.listdir on Windows) and one to MAL (about -U vs. exec/eval). You two can take care of entering these into JB. You can still access the bugs database via this URL: https://sourceforge.net/bugs/?group_id=5470 --Guido van Rossum (home page: http://www.python.org/~guido/) From gward@mems-exchange.org Wed Jun 28 16:35:05 2000 From: gward@mems-exchange.org (Greg Ward) Date: Wed, 28 Jun 2000 11:35:05 -0400 Subject: [Python-Dev] OT: A Day in the Life of p5p In-Reply-To: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid>; from effbot@telia.com on Wed, Jun 28, 2000 at 01:07:24PM +0200 References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> Message-ID: <20000628113505.C15643@ludwig.cnri.reston.va.us> On 28 June 2000, Fredrik Lundh said: > http://prometheus.frii.com/~gnat/yapc/2000-p5p.txt > > unfortunately, his "What is it with those Python fucks anyway" talk > isn't posted... ;-) But the "Conclusion" of his "Lies We Tell" talk: Perl sucks. Use Python. Presumably tongue-in-cheek, but you never know... Greg From trentm@activestate.com Wed Jun 28 17:53:19 2000 From: trentm@activestate.com (Trent Mick) Date: Wed, 28 Jun 2000 09:53:19 -0700 Subject: [Python-Dev] back up & running In-Reply-To: <200006281222.OAA03150@python.inrialpes.fr> References: <14681.56997.50955.892954@cj42289-a.reston1.va.home.com> <200006281222.OAA03150@python.inrialpes.fr> Message-ID: <20000628095319.C14129@activestate.com> On Wed, Jun 28, 2000 at 02:22:56PM +0200, Vladimir Marangozov wrote: > Fred L. Drake, Jr. wrote: > > > > My mega-laptop got fixed faster than I'd expected, so I'm back up to > > doing useful work. My top priorities are handling patches and going > > back through my email to find all the documentation patches that have > > sat idle for too long. > > Excellent! > > Finally someone who cares to checkin patches. I've been disappointed > to see that the June 30 intent-date was announced, but people keep > chewing-gumming about SourceForge caveats while the patches backlog > grows and the number of closed patches stays invariably to 3, of which > one is a test! > You can count me as one of the significatn bottlenecks here. Tim and Guido have accepted some of my patches, I just have to check them in. Real Soon Now (tm). Trent Mick (also tm) -- Trent Mick trentm@activestate.com From mal@lemburg.com Wed Jun 28 17:57:35 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 28 Jun 2000 18:57:35 +0200 Subject: [Python-Dev] Named Unicode Characters Message-ID: <395A2E7F.A1DDEC35@lemburg.com> I've just checked in the patches by Bill Tutt, which add support for \N{NAMED UNICODE CHARACTERS}. The new escape code is available per default in the standard unicode-escape codec. The (big) hash table needed to drive the mapping is loaded on demand to reduce memory overhead. The patch also includes a new tool called perfecthash which is used to generate the hash table (and function) from names to ordinals. I'm sure this can be of use in other areas too... but it needs some more work to become more generic (currently you have to edit the source code to generate other mapping modules). Thanks to Bill Tutt -- this is great work ! -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From paul@prescod.net Wed Jun 28 18:11:19 2000 From: paul@prescod.net (Paul Prescod) Date: Wed, 28 Jun 2000 10:11:19 -0700 Subject: [Python-Dev] OT: A Day in the Life of p5p References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> Message-ID: <395A31B7.911D9BC2@prescod.net> Fredrik Lundh wrote: > > http://prometheus.frii.com/~gnat/yapc/2000-p5p.txt How about this one: http://gisle.aas.no/perl/illguts/ Just thank your lucky stars... -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From paul@prescod.net Wed Jun 28 18:16:45 2000 From: paul@prescod.net (Paul Prescod) Date: Wed, 28 Jun 2000 10:16:45 -0700 Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager References: Message-ID: <395A32FD.D3C58B23@prescod.net> I don't want to be paranoid, but are we putting any important information into SourceForge that we are not backing up elsewhere? I mean okay, we've all got CVS dumps, but if it went away (DOJ antitrust suit...) would we have backups of our patches, bugs, wish lists and so forth? I hope that's a criteria in deciding what services to move to SourceForge. I am in the business of preserving investments in data and of telling customers to avoid software that does not keep them in complete control of their data. SF makes me nervous that way.... -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From mal@lemburg.com Wed Jun 28 18:22:40 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 28 Jun 2000 19:22:40 +0200 Subject: [Python-Dev] Checkin Utility Message-ID: <395A3460.3FF013F0@lemburg.com> This is a multi-part message in MIME format. --------------4A599D73348784E859687D01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I thought you might have some use for the attached utility. It's a simple script which helps with checking in patches which I've been using for a while now. It also hides the CVS options and parameters away as far as possible, so that CVS knowledge is not really needed to complete the task. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ --------------4A599D73348784E859687D01 Content-Type: text/python; charset=us-ascii; name="checkin.py" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="checkin.py" #!/usr/local/bin/python -u """ Tools for (interactive) CVS checkins. (c) Marc-Andre Lemburg, mal@lemburg.com, All Rights Reserved. Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee or royalty is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation or portions thereof, including modifications, that you make. THE AUTHOR MARC-ANDRE LEMBURG DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE ! """#" import string,os,exceptions,tempfile,sys __version__ = '0.3' ### Configuration # CVS Options which will always be used CVSOPTIONS = '-z3' # Path of the cvs tool CVS = "/usr/bin/cvs" # Default name of patcher default_author = 'Marc-Andre Lemburg' default_email = 'mal@lemburg.com' # Check the settings if not os.path.exists(CVS): CVS = 'cvs' # Debug ? __debug__ = 0 ### Errors class CVSError(exceptions.StandardError): pass ### Low Level interface def cvs(command, flags=(), files=(), options=(), test=0): if options: options = '-' + string.join(options, ' -') else: options = '' if flags: flags = '-' + string.join(flags, ' -') else: flags = '' cmd = '%s %s %s %s %s %s' % (CVS, CVSOPTIONS, options, command, flags, string.join(files, ' ')) if test: print '* exec "%s"' % cmd return '' try: p = os.popen(cmd) except os.error,why: raise CVSError, why return p.read() def check_files(files=('.',), modify=0): options = options=('q',) if not modify: options = options + ('n',) output = cvs('update', files=files, options=options) lines = string.split(output, '\n') added_files = [] modified_files = [] updated_files = [] patched_files = [] for line in lines: if not line: continue try: marker, filename = string.split(line) except ValueError: if __debug__: print '* could not parse: "%s"' % line continue if marker == '?': list = added_files elif marker == 'M': list = modified_files elif marker == 'U': list = updated_files elif marker == 'P': list = patched_files else: if __debug__: print '* unkown marker: "%s" for file "%s"' % \ (marker, filename) continue list.append(filename) return added_files, modified_files, updated_files, patched_files def update_files(files=('.',), verbose=0): return check_files(files, modify=1) def print_check_results(a, m, u, p): if a: print 'Added to work dir:' for filename in a: print ' ',filename if m: print 'Modified in work dir:' for filename in m: print ' ',filename if u: print 'Updated in repository:' for filename in u: print ' ',filename if p: print 'Patched in repository:' for filename in p: print ' ',filename def checkin_files(files, message='', rev=''): options = ('Q',) flags = () if message: tempname = tempfile.mktemp() open(tempname, 'w').write(message) flags = flags + ('F %s' % tempname,) else: tempname = '' if rev: flags = flags + ('r %s' % rev,) try: if not __debug__: output = cvs('commit', files=files, options=options, flags=flags) else: output = cvs('commit', files=files, options=options, flags=flags, test=1) print message if output: if __debug__: print '* commit output:' print output finally: os.unlink(tempname) def checkin_file(file, message='', rev=''): return checkin_files((file,), message, rev) def add_files(files): if not __debug__: output = cvs('add', files=files, options=('Q',)) else: output = cvs('add', files=files, options=('Q',), test=1) if output: if __debug__: print '* add output:' print output def add_file(file): return add_files((file,)) def multiline_input(prompt='', term='.', linesep='\n'): lines = [] while 1: line = raw_input(prompt) if not lines and \ not line: return '' if line == term or \ lines and lines[-1] == line: return string.join(lines, linesep) lines.append(line) def format_message(message, author, email=''): if email: header = '%s <%s>:\n' % (author, email) elif author: header = '%s:\n' % (author) else: header = '' msg = header + message return string.strip(msg) if __name__ == '__main__': # -f cmd line switch if len(sys.argv) > 1 and sys.argv[1] == '-f': force = 1 else: force = 0 print '='*72 print 'CVS Checkin Utility' print '-'*72 print print 'Checking work dir...', a,m,u,p = check_files() if not force and \ (u or p): print print '* Files changed in the repository since the last update.' print '* Please update before proceeding with the checkin or run' print '* this script with switch -f.' print print 'For your information, these files were found to be out' print 'of sync:' print print_check_results((),(),u,p) sys.exit(1) print 'done.' print if not a and not m: print '* No files need to be checked in.' print sys.exit(1) print 'These files will be checked in:' print print_check_results(a,m,u,p) print print '='*72 print 'Please enter the name and email of the patch author:' print author = raw_input('Name: [%s] ' % default_author) or default_author email = raw_input('EMail: [%s] ' % default_email) or default_email print print '='*72 print 'Please enter the commit messages for each file below...' print print '[Emtpy entries will be skipped, comments must be terminated by' print ' line containing a single dot or two consecutive empty lines]' if a: print print '# New Files:' for file in a: print print '%s' % file print '-'*72 message = multiline_input(term='.') print '-'*72 if not message: print '>>> (commit skipped)' continue print '>>> Adding to CVS Repository...', message = format_message(message, author, email) add_file(file) checkin_file(file, message) print 'done.' if m: print print '# Modified Files:' for file in m: print print '%s' % file print '-'*72 message = multiline_input(term='.') print '-'*72 if not message: print '>>> (commit skipped)' continue print '>>> Committing to CVS Repository...', message = format_message(message, author, email) checkin_file(file, message) print 'done.' print print 'Done. Thanks :-)' --------------4A599D73348784E859687D01-- From esr@thyrsus.com Wed Jun 28 18:38:05 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Wed, 28 Jun 2000 13:38:05 -0400 Subject: [Python-Dev] OT: A Day in the Life of p5p In-Reply-To: <395A31B7.911D9BC2@prescod.net>; from paul@prescod.net on Wed, Jun 28, 2000 at 10:11:19AM -0700 References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> <395A31B7.911D9BC2@prescod.net> Message-ID: <20000628133805.D20855@thyrsus.com> Paul Prescod : > http://gisle.aas.no/perl/illguts/ > > Just thank your lucky stars... Ghods. Reading that just about ruined my lunch. -- Eric S. Raymond "The power to tax involves the power to destroy;...the power to destroy may defeat and render useless the power to create...." -- Chief Justice John Marshall, 1819. From paul@prescod.net Wed Jun 28 18:27:54 2000 From: paul@prescod.net (Paul Prescod) Date: Wed, 28 Jun 2000 10:27:54 -0700 Subject: [Python-Dev] Text about cycle GC References: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com> Message-ID: <395A359A.2CF0CA70@prescod.net> "A.M. Kuchling" wrote: > > ... > > An experimental step has been made toward fixing this problem. When > compiling Python, the -with-cycle-gc (XXX correct option flag?) option > can be specified. This causes a cycle detection algorithm to be > periodically executed, which looks for inaccessible cycles and deletes > the objects involved. I propose (without any investigation into the difficulty of implementation) that import cyclicgc should turn on the -with-cycle-gc flag. Then you could do a import cyclicgc import someDOM And not worry about cycles. If it's too slow, you remove the line and take responsibility for cycle checking. The important thing is that you don't have to tell YOUR USERS to turn on GC in order for your code to work. I think that this model will get more people actively using (and depending upon!) GC and thus give us a better idea about usage patterns, stability and performance. This is especially important in the beta period when we are trying to shake out bugs. Really, this comes back to Greg's point that we should not have incompatible sub-languages running around. A module depends on the feature or it doesn't. The end-user should not be responsible for knowing whether any module in a whole program needs GC. -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From paul@prescod.net Wed Jun 28 18:34:35 2000 From: paul@prescod.net (Paul Prescod) Date: Wed, 28 Jun 2000 10:34:35 -0700 Subject: [Python-Dev] OT: A Day in the Life of p5p References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> <395A31B7.911D9BC2@prescod.net> <20000628133805.D20855@thyrsus.com> Message-ID: <395A372B.34E15A62@prescod.net> "Eric S. Raymond" wrote: > > Ghods. Reading that just about ruined my lunch. You read it? Eric, I was just kidding! Actually, my theory is that the whole thing is a big, extended, April Fools joke. Not the document. The language. (rimshot) SvOOK-vs-SvIV-and-SvNV-indeed-ly 'yrs -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From gmcm@hypernet.com Wed Jun 28 18:37:07 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Wed, 28 Jun 2000 13:37:07 -0400 Subject: [Python-Dev] OT: A Day in the Life of p5p In-Reply-To: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> Message-ID: <1249908601-39717068@hypernet.com> > http://prometheus.frii.com/~gnat/yapc/2000-p5p.txt What I noticed is that Tim is mentioned in every other paragraph. Where-does-he-find-the-time?-ly y'rs - Gordon From jeremy@beopen.com Wed Jun 28 18:41:50 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Wed, 28 Jun 2000 13:41:50 -0400 (EDT) Subject: [Python-Dev] OT: A Day in the Life of p5p In-Reply-To: <395A31B7.911D9BC2@prescod.net> References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> <395A31B7.911D9BC2@prescod.net> Message-ID: <14682.14558.380773.307392@bitdiddle.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> Fredrik Lundh wrote: >> http://prometheus.frii.com/~gnat/yapc/2000-p5p.txt PP> How about this one: PP> http://gisle.aas.no/perl/illguts/ PP> Just thank your lucky stars... What beautiful diagrams! It almost makes me wish Python was complicated enough to require such pretty pictures. Jeremy From guido@beopen.com Wed Jun 28 19:41:48 2000 From: guido@beopen.com (Guido van Rossum) Date: Wed, 28 Jun 2000 13:41:48 -0500 Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager In-Reply-To: Your message of "Wed, 28 Jun 2000 10:16:45 MST." <395A32FD.D3C58B23@prescod.net> References: <395A32FD.D3C58B23@prescod.net> Message-ID: <200006281841.NAA03154@cj20424-a.reston1.va.home.com> [PP] > I don't want to be paranoid, but are we putting any important > information into SourceForge that we are not backing up elsewhere? I > mean okay, we've all got CVS dumps, but if it went away (DOJ antitrust > suit...) would we have backups of our patches, bugs, wish lists and so > forth? I hope that's a criteria in deciding what services to move to > SourceForge. I am in the business of preserving investments in data and > of telling customers to avoid software that does not keep them in > complete control of their data. SF makes me nervous that way.... Good point. SF has a way to get a nightly snapshot of the CVS tree. We should suggest that they provide snapshots (in XML of course!) of the bugs database too. Note that I have no bandwidth left to communicate to SF folks so this is up to the user community. (I'm also very optimistic and trusting in nature. :-) --Guido van Rossum (home page: http://www.python.org/~guido/) From jeremy@beopen.com Wed Jun 28 18:49:32 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Wed, 28 Jun 2000 13:49:32 -0400 (EDT) Subject: [Python-Dev] Text about cycle GC In-Reply-To: <395A359A.2CF0CA70@prescod.net> References: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com> <395A359A.2CF0CA70@prescod.net> Message-ID: <14682.15020.589514.702145@bitdiddle.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> "A.M. Kuchling" wrote: >> ... >> >> An experimental step has been made toward fixing this >> problem. When compiling Python, the -with-cycle-gc (XXX correct >> option flag?) option can be specified. This causes a cycle >> detection algorithm to be periodically executed, which looks for >> inaccessible cycles and deletes the objects involved. PP> I propose (without any investigation into the difficulty of PP> implementation) that PP> import cyclicgc PP> should turn on the -with-cycle-gc flag. The -with-cycle-gc flag is an option to configure when you build Python. It can't be turned on or off at runtime. We hope that everyone will build with the -with-cycle-gc flag during the beta testing, but we don't expect to have enough confidence in it by final release to make it anything other than an experimental option. Jeremy From esr@thyrsus.com Wed Jun 28 19:02:37 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Wed, 28 Jun 2000 14:02:37 -0400 Subject: [Python-Dev] OT: A Day in the Life of p5p In-Reply-To: <395A372B.34E15A62@prescod.net>; from paul@prescod.net on Wed, Jun 28, 2000 at 10:34:35AM -0700 References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> <395A31B7.911D9BC2@prescod.net> <20000628133805.D20855@thyrsus.com> <395A372B.34E15A62@prescod.net> Message-ID: <20000628140237.A21043@thyrsus.com> Paul Prescod : > "Eric S. Raymond" wrote: > > > > Ghods. Reading that just about ruined my lunch. > > You read it? Eric, I was just kidding! Yes, I read it. Un-fscking-believable. I knew Perl was complicated and ugly on the inside, but the full horror had not obtruded itself on me before now. If I'm any judge, that's an implementation on the brink of collapsing under its own weight. -- Eric S. Raymond Non-cooperation with evil is as much a duty as cooperation with good. -- Mohandas Gandhi From paul@prescod.net Wed Jun 28 18:53:16 2000 From: paul@prescod.net (Paul Prescod) Date: Wed, 28 Jun 2000 10:53:16 -0700 Subject: [Python-Dev] OT: A Day in the Life of p5p References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> <395A31B7.911D9BC2@prescod.net> <14682.14558.380773.307392@bitdiddle.concentric.net> Message-ID: <395A3B8B.B6117DA1@prescod.net> Note that the document doesn't yet cover the regular expression engine or the "PerlInterpreter". I can't think of a disclaimer that doesn't sound like it is tongue in cheek but I do feel bad about beating up on a design which, in its own way, has a certain kind of quality (just not one I happen to prefer). When you optimize the snot out of things they tend to start looking ugly. Perl runs faster than Python. That's probably not a coincidence. Jeremy Hylton wrote: > > What beautiful diagrams! It almost makes me wish Python was > complicated enough to require such pretty pictures. To be fair, our internals documentation needs some work. I'll bet there are a lot of people in comp.lang.python that would be interested in a project like that or another one, such as adding a full warning infrastructure to Python. I wonder how we could do a Software Carpentry like deal (no money) where we get people to submit designs and ideas and then "award" the job to someone. They could do it for reputational capital and an opportunity to join "the team" (of CVS committers, PythonDev denizens etc.). It's probably better to give people ideas rather than have them implement random things that we will need to turn down. Like stackless. -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From paul@prescod.net Wed Jun 28 19:09:38 2000 From: paul@prescod.net (Paul Prescod) Date: Wed, 28 Jun 2000 11:09:38 -0700 Subject: [Python-Dev] Text about cycle GC References: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com> <395A359A.2CF0CA70@prescod.net> <14682.15020.589514.702145@bitdiddle.concentric.net> Message-ID: <395A3F62.EA1E8B89@prescod.net> Jeremy Hylton wrote: > > .... > > The -with-cycle-gc flag is an option to configure when you build > Python. It can't be turned on or off at runtime. Doh! Sorry. Andrew's text does say that but I didn't read carefully and testing it with my stuff hasn't floated to the top yet (because when I looked into it, I realized I'd have to recompile...double doh!) Compiling is really slow on my "transitional" computer. I'm a little disappointed that it will be so difficult for people to test with GC on, but I'm not going to claim that there is some easy way to make it a runtime option because I haven't looked at it at all. There probably isn't. -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From nascheme@enme.ucalgary.ca Wed Jun 28 19:27:25 2000 From: nascheme@enme.ucalgary.ca (Neil Schemenauer) Date: Wed, 28 Jun 2000 12:27:25 -0600 Subject: [Python-Dev] Text about cycle GC In-Reply-To: <395A3F62.EA1E8B89@prescod.net>; from paul@prescod.net on Wed, Jun 28, 2000 at 11:09:38AM -0700 References: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com> <395A359A.2CF0CA70@prescod.net> <14682.15020.589514.702145@bitdiddle.concentric.net> <395A3F62.EA1E8B89@prescod.net> Message-ID: <20000628122725.A13473@acs.ucalgary.ca> On Wed, Jun 28, 2000 at 11:09:38AM -0700, Paul Prescod wrote: > I'm a little disappointed that it will be so difficult for people to > test with GC on, but I'm not going to claim that there is some easy way > to make it a runtime option because I haven't looked at it at all. There > probably isn't. There isn't. With an interpreter compiled --with-cycle-gc you can turn off the collection with gc.set_threshold(0) but that's not the same thing. Neil From bwarsaw@beopen.com Wed Jun 28 19:33:23 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Wed, 28 Jun 2000 14:33:23 -0400 (EDT) Subject: [Python-Dev] OT: A Day in the Life of p5p References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> <395A31B7.911D9BC2@prescod.net> <20000628133805.D20855@thyrsus.com> <395A372B.34E15A62@prescod.net> <20000628140237.A21043@thyrsus.com> Message-ID: <14682.17651.552666.318592@anthem.concentric.net> >>>>> "ESR" == Eric S Raymond writes: ESR> Yes, I read it. Un-fscking-believable. I knew Perl was ESR> complicated and ugly on the inside, but the full horror had ESR> not obtruded itself on me before now. If I'm any judge, ESR> that's an implementation on the brink of collapsing under its ESR> own weight. And of course, we'll be right there to pick up the pieces. :) From guido@beopen.com Wed Jun 28 20:43:06 2000 From: guido@beopen.com (Guido van Rossum) Date: Wed, 28 Jun 2000 14:43:06 -0500 Subject: [Python-Dev] Python 1.6 schedule Message-ID: <200006281943.OAA03414@cj20424-a.reston1.va.home.com> I've updated the 1.6 page on python.org (http://www.python.org/1.6/) to include the latest schedule for 1.6. I've also included a link to Andrew's "what's new" article. Here's the new schedule in text form: July 1: beta 1; feature freeze. July 14: beta 2, in time for the O'Reilly Open Source Software Convention. August 1: release candidate. August 15: final release. I'm happy with how the patches are coming along today (/F even submitted the SRE patch...). We may actually have a release party Saturday! --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@beopen.com Wed Jun 28 21:27:43 2000 From: guido@beopen.com (Guido van Rossum) Date: Wed, 28 Jun 2000 15:27:43 -0500 Subject: [Python-Dev] Named Unicode Characters In-Reply-To: Your message of "Wed, 28 Jun 2000 18:57:35 +0200." <395A2E7F.A1DDEC35@lemburg.com> References: <395A2E7F.A1DDEC35@lemburg.com> Message-ID: <200006282027.PAA04607@cj20424-a.reston1.va.home.com> > I've just checked in the patches by Bill Tutt, which add > support for \N{NAMED UNICODE CHARACTERS}. The new escape > code is available per default in the standard unicode-escape > codec. The (big) hash table needed to drive the mapping > is loaded on demand to reduce memory overhead. > > The patch also includes a new tool called perfecthash which > is used to generate the hash table (and function) from > names to ordinals. I'm sure this can be of use in other > areas too... but it needs some more work to become more > generic (currently you have to edit the source code to generate > other mapping modules). > > Thanks to Bill Tutt -- this is great work ! Thanks Bill and Marc-Andre! I've closed the patch in SF now. --Guido van Rossum (home page: http://www.python.org/~guido/) From tpeters@beopen.com Wed Jun 28 20:40:18 2000 From: tpeters@beopen.com (Tim Peters) Date: Wed, 28 Jun 2000 15:40:18 -0400 Subject: [Python-Dev] back up & running In-Reply-To: <20000628095319.C14129@activestate.com> Message-ID: [Vladimir Marangozov] > ... > I've been disappointed to see that the June 30 intent-date was > announced, but people keep chewing-gumming about SourceForge > caveats while the patches backlog grows and the number of closed > patches stays invariably to 3, of which one is a test! Absolutely on-target, Vladimir! The current state of our world is embarrassing. Someday when the bosses aren't listening, I'll explain to you how it got this way <0.9 wink>. [Trent Mick] > You can count me as one of the significant bottlenecks here. Tim and > Guido have accepted some of my patches, I just have to check them in. > Real Soon Now (tm). Trent, you are *not* a bottleneck! You've cooperated with the process (or lack thereof) every step of the way, and it hasn't even been 12 hours since I accepted some of your patches. And the bulk of them are still on my plate to review. I don't think we have an actual bottleneck now, but we do have a large backlog to work off, and people with too many things that need to be done. perseverance-and-patience-will-probably-work-better-than-their-opposites-ly y'rs - tim From gstein@lyra.org Wed Jun 28 20:46:06 2000 From: gstein@lyra.org (Greg Stein) Date: Wed, 28 Jun 2000 12:46:06 -0700 Subject: [Python-Dev] add Demo/imputil/importers.py ? In-Reply-To: <200006281455.JAA01690@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Wed, Jun 28, 2000 at 09:55:00AM -0500 References: <20000627184615.A29590@lyra.org> <200006281455.JAA01690@cj20424-a.reston1.va.home.com> Message-ID: <20000628124606.K29590@lyra.org> On Wed, Jun 28, 2000 at 09:55:00AM -0500, Guido van Rossum wrote: > > A while back, I pulled the "demo" importers out of imputil.py. I think those > > should be added into Demo/imputil/. > > OK. Go ahead and create that directory and add the demo importers. Will do. > > It would also be Goodness to include JimA's zipimporter. Where would that go? > > Same place I'd hope? Can you check that it works? Yup and yup. > We're dependent on you volunteers to maintain relatively non-core > things like this -- I don't want to extend the feature freeze to > Demo/, but I also don't have the time to keep the stuff there up to > date. Not a problem, and I had figured on being the "point man" on keeping it working. My query here was more along the lines of "is Demo/imputil/ a good idea? If so, then I'll run with it." You said "yes", so I'll go put on my shoes. > Maybe at some point the Demo directory should become a separate > distribution, or just a collection of stuff on the web? I believe a separate distribution. Unpacking the bugger to the main web site would also be a good option, but that would be a second priority. I'd throw Tools into the same thing. As a separate distro, you can have a faster release cycle. ... you could release Idle updates easily and distinctly from the Python core. Note: by a "collection on the web", the only view that I have, is that the collection exists on the python.org web site. Distributed pieces "here and there" is handled by the Vaults (and similar). The Demo/ directory is a bit more newbie-ish, so (IMO) it ought to get bundled up somehow since the Vaults are a bit daunting to find "example of embedding". If the bundle also happens to reside in an obvious area on python.org? Great. Cheers, -g -- Greg Stein, http://www.lyra.org/ From tpeters@beopen.com Wed Jun 28 20:54:42 2000 From: tpeters@beopen.com (Tim Peters) Date: Wed, 28 Jun 2000 15:54:42 -0400 Subject: [Python-Dev] OT: A Day in the Life of p5p In-Reply-To: <395A31B7.911D9BC2@prescod.net> Message-ID: [Paul Prescod] > How about this one: > > http://gisle.aas.no/perl/illguts/ > Just thank your lucky stars... Ack, don't get me started -- well, I'd love to, but have real work to do. I've posted about that before. I'm not infrequently amazed that they manage to keep Perl running at all. The amazing thing about the PerlGuts doc above is that it was apparently reverse-engineered by staring at Perl's implementation code. You can't find any of it explained in the source! either-those-guys-are-nuts-or-they're-a-*whole*-lot-smarter- than-us-and-i-know-which-of-those-i'm-more-likely-to- believe-ly y'rs - tim From guido@beopen.com Wed Jun 28 21:59:46 2000 From: guido@beopen.com (Guido van Rossum) Date: Wed, 28 Jun 2000 15:59:46 -0500 Subject: [Python-Dev] Text about cycle GC In-Reply-To: Your message of "Wed, 28 Jun 2000 12:27:25 CST." <20000628122725.A13473@acs.ucalgary.ca> References: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com> <395A359A.2CF0CA70@prescod.net> <14682.15020.589514.702145@bitdiddle.concentric.net> <395A3F62.EA1E8B89@prescod.net> <20000628122725.A13473@acs.ucalgary.ca> Message-ID: <200006282059.PAA04852@cj20424-a.reston1.va.home.com> > On Wed, Jun 28, 2000 at 11:09:38AM -0700, Paul Prescod wrote: > > I'm a little disappointed that it will be so difficult for people to > > test with GC on, but I'm not going to claim that there is some easy way > > to make it a runtime option because I haven't looked at it at all. There > > probably isn't. > > There isn't. With an interpreter compiled --with-cycle-gc you can > turn off the collection with gc.set_threshold(0) but that's not > the same thing. > > Neil I wonder if we should turn this option *on* during beta testing? That way we gather a lot more experience with its use! Maybe nobody complains and we can leave it on in the final release... --Guido van Rossum (home page: http://www.python.org/~guido/) From akuchlin@mems-exchange.org Wed Jun 28 21:10:28 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Wed, 28 Jun 2000 16:10:28 -0400 Subject: [Python-Dev] OT: A Day in the Life of p5p In-Reply-To: <395A3B8B.B6117DA1@prescod.net> References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> <395A31B7.911D9BC2@prescod.net> <14682.14558.380773.307392@bitdiddle.concentric.net> <395A3B8B.B6117DA1@prescod.net> Message-ID: <20000628161028.C23352@kronos.cnri.reston.va.us> On Wed, Jun 28, 2000 at 10:53:16AM -0700, Paul Prescod wrote: >Note that the document doesn't yet cover the regular expression engine >or the "PerlInterpreter". The regex engine's pretty hard to read, mostly because comments are infrequent and not very helpful, and disentangling it from the rest of Perl would require a skilled wizard. (PCRE, if slower, is at least much clearer and easier to understand, though the compile() function is pretty ugly.) A while ago I saw a p5p post from Ilya Zakharevich who did most of the recent regex hacking; he draw attention to one flag variable in the code and said basically "I don't know what this flag means; I think it's some sort of UTF-8 setting, but Larry didn't explain it." >I can't think of a disclaimer that doesn't sound like it is tongue in >cheek but I do feel bad about beating up on a design which, in its own >way, has a certain kind of quality (just not one I happen to prefer). Agreed; it could be made much simpler, but maybe at a performance cost. (Though performance is tricky, and maybe the extra work costs more than it saves.) For example, note the flag bits in SvNULL, which have values like GMAGICAL. You could imagine a Python implementation that added flag bits to every object, and set a bit if there was a __getattr__ method defined; code could then do 'if (obj->flags & GMAGICAL) ...' instead of the more complicated 'if (PyObject_HasAttrString(obj, "__getattr__")'. It would be interesting to know if Topaz, Chip Salzenberg's experimental C++ implementation, preserves this complexity or aims to cut it away. The use of several levels of C structs is also reminiscent of the way you do OO in C, as in X toolkits. You can also see the importance of text processing in the SvPVBM type, for attaching a Boyer-Moore related table to a string and speeding up regex searches. --amk From tpeters@beopen.com Wed Jun 28 21:15:34 2000 From: tpeters@beopen.com (Tim Peters) Date: Wed, 28 Jun 2000 16:15:34 -0400 Subject: [Python-Dev] OT: A Day in the Life of p5p In-Reply-To: <395A3B8B.B6117DA1@prescod.net> Message-ID: [Paul Prescod] > ... > When you optimize the snot out of things they tend to start looking > ugly. Perl runs faster than Python. That's probably not a coincidence. More, IMO it's not even true. I can't make time for this now, but on several occasions I've coded the same algorithm in idiomatic Perl and Python, and Python was invariably faster (not talking orders of magnitude, but 10-40%). The catch is that I know something about both implementations, and avoided the sweet spots in both. Perl gets enormous bang out of its line-at-a-time text file input "cheating", and its integrated regexps. Avoid those, and it's generally *slower* in my experience, which is perfectly consistent with the relative messiness of its implementation (all those magic flags aren't passive, they need runtime conditionals to use! Perl can't even inline its refcount manipulations because they're so complicated due to the flags). Against that, line-at-a-time text file input in particular is something that every newbie bumps into at once, and Perl does have a monster advantage there (at least 2x faster, probably closer to 3 on most platforms). Perl doesn't really look like it was designed to "be fast" in general -- it looks like it was designed to be supernaturally fast in specific situations. Best I've been able to tell, that's how it *acts*, too. I'm keen to add comparable (but limited) internal warts to Python, but for *general* speedup ideas we'll be much better off looking to, e.g., Dylan and Squeak. all-that-said-python-is-fast-enough-for-me-already!-ly y'rs - tim From DavidA@ActiveState.com Wed Jun 28 21:17:46 2000 From: DavidA@ActiveState.com (David Ascher) Date: Wed, 28 Jun 2000 13:17:46 -0700 Subject: [Python-Dev] OT: A Day in the Life of p5p In-Reply-To: Message-ID: > either-those-guys-are-nuts-or-they're-a-*whole*-lot-smarter- > than-us-and-i-know-which-of-those-i'm-more-likely-to- > believe-ly y'rs - tim I was sitting next to Gisle (the author of said document) when he started to work on the Perl methods work for Zope. Within a day, starting w/ not knowing anything about Python, he had Perl embedded in Python. It says much about the cleanliness of Python's design and the quality of its documentation that Gisle could do that. It also says a lot about Gisle, as does the perlguts document Not saying anything about anyone being nuts, especially when responding to someone who talks about his in public. --david From pingster@ilm.com Wed Jun 28 21:22:15 2000 From: pingster@ilm.com (Ka-Ping Yee) Date: Wed, 28 Jun 2000 13:22:15 -0700 (PDT) Subject: [Python-Dev] OT: A Day in the Life of p5p In-Reply-To: <20000628161028.C23352@kronos.cnri.reston.va.us> Message-ID: On Wed, 28 Jun 2000, Andrew Kuchling wrote: > You could imagine a Python implementation that added flag > bits to every object, and set a bit if there was a __getattr__ method > defined; code could then do 'if (obj->flags & GMAGICAL) ...' instead > of the more complicated 'if (PyObject_HasAttrString(obj, > "__getattr__")'. That looks like a reasonable sort of optimization to me, though as far as i can tell it looks like that optimization has already been done: in PyClass_New(bases, dict, name): [...] op->cl_getattr = class_lookup(op, getattrstr, &dummy); [...] in instance_getattr(inst, name): if (res == NULL && (func = inst->in_class->cl_getattr) != NULL) { [...special __getattr__ handling...] } In general, optimizations of the form "add a flag to avoid a frequent expensive test" seem okay to me, as long they are a demonstrable win and the flag can be given a clear, simple name. -- ?!ng "To be human is to continually change. Your desire to remain what you are is what ultimately limits you." -- The Puppet Master, Ghost in the Shell From akuchlin@mems-exchange.org Wed Jun 28 21:25:54 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Wed, 28 Jun 2000 16:25:54 -0400 Subject: [Python-Dev] OT: A Day in the Life of p5p In-Reply-To: References: <20000628161028.C23352@kronos.cnri.reston.va.us> Message-ID: <20000628162554.E23352@kronos.cnri.reston.va.us> On Wed, Jun 28, 2000 at 01:22:15PM -0700, Ka-Ping Yee wrote: >That looks like a reasonable sort of optimization to me, though >as far as i can tell it looks like that optimization has already >been done: Damn time machine again... --amk From tpeters@beopen.com Wed Jun 28 21:31:58 2000 From: tpeters@beopen.com (Tim Peters) Date: Wed, 28 Jun 2000 16:31:58 -0400 Subject: SourceForge patch notifications (was RE: [Python-Dev] ANN: Release schedule) In-Reply-To: <20000628090230.A14129@activestate.com> Message-ID: [Trent Mick] > ... > BTW I have answered a couple a questions on my patches. Does > the person to whom the patch is assigned get an update notification? Trent & I investigated this offline: he added a comment to one of his patches to which I am assigned. I did indeed get prompt email notification, although as everyone has noticed by now, there's no indication from SF about *why* I was getting notified; just: From: noreply@sourceforge.net [mailto:noreply@sourceforge.net] Sent: Wednesday, June 28, 2000 12:01 PM To: tmick@mail.com; tim_one@email.msn.com Subject: [Patch #100513] fix posixmodule for 64-bit systems (mainly Win64) Patch #100513 has been updated. Visit SourceForge.net for more info. http://sourceforge.net/patch/?func=detailpatch&patch_id=100513&group_id=5470 So the outcome could have been worse . a-new-criterion-for-excellence-ly y'rs - tim From Fredrik Lundh" Message-ID: <033a01bfe141$71b0cfc0$f2a6b5d4@hagrid> tim wrote: > Against that, line-at-a-time text file input in particular is = something that > every newbie bumps into at once, and Perl does have a monster = advantage > there (at least 2x faster, probably closer to 3 on most platforms). and 2-3x is what you get if you replace readline with readlines, as described in this note: http://w1.132.telia.com/~u13208596/notes/readline-performance.htm it would be very nice if the file object could do something similar internally (only in text mode, perhaps). maybe in 1.7? (as I've mentioned earlier, SRE+faster IO can result in a 10x speedup for a straightforward while/readline/match loop...) From jack@oratrix.nl Wed Jun 28 21:58:27 2000 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 28 Jun 2000 22:58:27 +0200 Subject: [Python-Dev] ucnhash module Message-ID: <20000628205832.C3234E2673@oratrix.oratrix.nl> I'm a bit worried about the ucnhash module and its huge size. I didn't follow the discussion closely at the time, because I thought I could always exclude it from the Pythons without dynamic linking, but now it seems that if i don't include it test_unicode doesn't run anymore. Is this a problem with test_unicode, or should I consider ucnhash a mandatory module? (BTW: there were also a couple of bugs in the module, include <> in stead of include "", and static in stead of staticforward declarations, I'll submit patches for those shortly). -- 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/ ++++ From gstein@lyra.org Wed Jun 28 22:03:42 2000 From: gstein@lyra.org (Greg Stein) Date: Wed, 28 Jun 2000 14:03:42 -0700 Subject: [Python-Dev] OT: A Day in the Life of p5p In-Reply-To: <033a01bfe141$71b0cfc0$f2a6b5d4@hagrid>; from effbot@telia.com on Wed, Jun 28, 2000 at 10:42:56PM +0200 References: <033a01bfe141$71b0cfc0$f2a6b5d4@hagrid> Message-ID: <20000628140342.Q29590@lyra.org> On Wed, Jun 28, 2000 at 10:42:56PM +0200, Fredrik Lundh wrote: > tim wrote: > > Against that, line-at-a-time text file input in particular is something that > > every newbie bumps into at once, and Perl does have a monster advantage > > there (at least 2x faster, probably closer to 3 on most platforms). > > and 2-3x is what you get if you replace readline with readlines, > as described in this note: > http://w1.132.telia.com/~u13208596/notes/readline-performance.htm > > it would be very nice if the file object could do something similar > internally (only in text mode, perhaps). maybe in 1.7? That could be troublesome. It should only be done if the file is seekable so that you can rewind. If a readline() on (say) a socket moved you *past* the newline, then you could be in big trouble. Or what happens in said socket is blocking? etc. Now... please don't start a thread about this now. Wait for post 1.6. Maybe I'm totally off, and some smart guy here can say so. But it just doesn't matter, so I'd rather not have to read a whole thread on the stuff :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Wed Jun 28 22:14:41 2000 From: gstein@lyra.org (Greg Stein) Date: Wed, 28 Jun 2000 14:14:41 -0700 Subject: [Python-Dev] PyOS_AfterFork() (was: CVS: python/dist/src/Doc/api api.tex,1.68,1.69) In-Reply-To: <200006281553.IAA11238@slayer.i.sourceforge.net>; from fdrake@users.sourceforge.net on Wed, Jun 28, 2000 at 08:53:17AM -0700 References: <200006281553.IAA11238@slayer.i.sourceforge.net> Message-ID: <20000628141441.R29590@lyra.org> Woah. Never knew this was in Python. It is quite interesting, as there is a very similar concept within Apache. In that model, you register a cleanup function for the particular data that needs to be cleaned post-fork. After the fork occurs, the cleanups are called. In essence, Python would register PyOS_AfterFork. Of course, any schmoe can call fork() and avoid the cleanups, so it bungs up the whole scheme. In Apache, the "only" way to fork is to call an APR function, which guarantees the cleanups. Cheers, -g On Wed, Jun 28, 2000 at 08:53:17AM -0700, Fred L. Drake wrote: > Update of /cvsroot/python/python/dist/src/Doc/api > In directory slayer.i.sourceforge.net:/tmp/cvs-serv11228/api > > Modified Files: > api.tex > Log Message: > > Added documentation for PyOS_AfterFork(). > > > Index: api.tex > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Doc/api/api.tex,v > retrieving revision 1.68 > retrieving revision 1.69 > diff -C2 -r1.68 -r1.69 > *** api.tex 2000/06/18 05:21:21 1.68 > --- api.tex 2000/06/28 15:53:13 1.69 > *************** > *** 1034,1037 **** > --- 1034,1044 ---- > \end{cfuncdesc} > > + \begin{cfuncdesc}{void}{PyOS_AfterFork}{} > + Function to update some internal state after a process fork; this > + should be called in the new process if the Python interpreter will > + continue to be used. If a new executable is loaded into the new > + process, this function does not need to be called. > + \end{cfuncdesc} > + > > \section{Process Control \label{processControl}} > > > _______________________________________________ > Python-checkins mailing list > Python-checkins@python.org > http://www.python.org/mailman/listinfo/python-checkins -- Greg Stein, http://www.lyra.org/ From Fredrik Lundh" import traceback try: raise SyntaxError, "argument" except: traceback.print_exc() prints: Traceback (most recent call last): File "test.py", line 3, in ? raise SyntaxError, "argument" Traceback (most recent call last): File "test.py", line 5, in ? traceback.print_exc() File "C:\py16\lib\traceback.py", line 182, in print_exc print_exception(etype, value, tb, limit, file) File "C:\py16\lib\traceback.py", line 110, in print_exception lines =3D format_exception_only(etype, value) File "C:\py16\lib\traceback.py", line 169, in format_exception_only list.append('%s: %s\n' % (str(stype), str(value))) SystemError: new style getargs format but argument is not a tuple not really what I expected. am I out of sync, or have I stumbled upon a bug in the new exceptions code? From tpeters@beopen.com Wed Jun 28 22:21:52 2000 From: tpeters@beopen.com (Tim Peters) Date: Wed, 28 Jun 2000 17:21:52 -0400 Subject: [Python-Dev] OT: A Day in the Life of p5p In-Reply-To: <20000628140342.Q29590@lyra.org> Message-ID: [Greg Stein] > ... > Now... please don't start a thread about this now. Wait for post > 1.6. Amen. > Maybe I'm totally off, and some smart guy here can say so. But it > just doesn't matter, so I'd rather not have to read a whole thread > on the stuff :-) If you change your mind, you can go back in the archives and read at least two old threads on the topic -- it's not like there's actually anything new here . From akuchlin@mems-exchange.org Wed Jun 28 22:30:38 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Wed, 28 Jun 2000 17:30:38 -0400 Subject: [Python-Dev] exceptions trouble In-Reply-To: <036201bfe146$90b7fb00$f2a6b5d4@hagrid> References: <036201bfe146$90b7fb00$f2a6b5d4@hagrid> Message-ID: <20000628173038.B28659@kronos.cnri.reston.va.us> On Wed, Jun 28, 2000 at 11:19:36PM +0200, Fredrik Lundh wrote: >SystemError: new style getargs format but argument is not a tuple >not really what I expected. am I out of sync, or have I >stumbled upon a bug in the new exceptions code? It works fine in my current copy of the CVS tree, and I think I rebuilt everything this morning. --amk From fdrake@beopen.com Wed Jun 28 22:32:36 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Wed, 28 Jun 2000 17:32:36 -0400 (EDT) Subject: [Python-Dev] PyOS_AfterFork() (was: CVS: python/dist/src/Doc/api api.tex,1.68,1.69) In-Reply-To: <20000628141441.R29590@lyra.org> References: <200006281553.IAA11238@slayer.i.sourceforge.net> <20000628141441.R29590@lyra.org> Message-ID: <14682.28404.125379.249287@cj42289-a.reston1.va.home.com> Greg Stein writes: > Woah. Never knew this was in Python. I didn't either, until I read a patch that used it. That's one way to keep the documentation up to date! ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From gstein@lyra.org Wed Jun 28 22:48:00 2000 From: gstein@lyra.org (Greg Stein) Date: Wed, 28 Jun 2000 14:48:00 -0700 Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163) In-Reply-To: <200006282112.OAA03095@slayer.i.sourceforge.net>; from gvanrossum@users.sourceforge.net on Wed, Jun 28, 2000 at 02:12:28PM -0700 References: <200006282112.OAA03095@slayer.i.sourceforge.net> Message-ID: <20000628144800.T29590@lyra.org> On Wed, Jun 28, 2000 at 02:12:28PM -0700, Guido van Rossum wrote: >... > - chunk #2: > The id() function guarantees a unique return value for different > objects. It does this by returning the pointer to the object. By > returning a PyInt, on Win64 (sizeof(long) < sizeof(void*)) the pointer > is truncated and the guarantee may be proven false. The appropriate > return function is PyLong_FromVoidPtr, this returns a PyLong if that > is necessary to return the pointer without truncation. > > [GvR: note that this means that id() can now return a long on Win32 > platforms. This *might* break some code...] Strictly speaking: the Long only occurs on Win64 platforms. I would guess that it is also possible on say, an Alpha running Linux. Presuming that has 64-bit pointers(?). Regardless: yes, it can certainly break some code. IMO, if any code out there makes any kinds of assumptions about id(), then they deserve to be broken :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From paul@prescod.net Wed Jun 28 22:44:33 2000 From: paul@prescod.net (Paul Prescod) Date: Wed, 28 Jun 2000 14:44:33 -0700 Subject: [Python-Dev] OT: A Day in the Life of p5p References: <033a01bfe141$71b0cfc0$f2a6b5d4@hagrid> <20000628140342.Q29590@lyra.org> Message-ID: <395A71C1.A4E332D@prescod.net> Re: Performance At the very least this readlines() optimization should be in FileInput which was invented, after all, in order to compete with Perl. --- Re: Inline Unicode smily faces Bill and Mark-Andre, you rock. Another feature stolen from Perl. If only it were as easy to steal cleanliness and elegance. :) --- Re: GC On by default in beta would be peachy. -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From bwarsaw@beopen.com Wed Jun 28 23:01:00 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Wed, 28 Jun 2000 18:01:00 -0400 (EDT) Subject: [Python-Dev] exceptions trouble References: <036201bfe146$90b7fb00$f2a6b5d4@hagrid> <20000628173038.B28659@kronos.cnri.reston.va.us> Message-ID: <14682.30108.714768.740415@anthem.concentric.net> >>>>> "AK" == Andrew Kuchling writes: AK> It works fine in my current copy of the CVS tree, and I think AK> I rebuilt everything this morning. Same here. From trentm@activestate.com Wed Jun 28 23:04:28 2000 From: trentm@activestate.com (Trent Mick) Date: Wed, 28 Jun 2000 15:04:28 -0700 Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163) In-Reply-To: <20000628144800.T29590@lyra.org> References: <200006282112.OAA03095@slayer.i.sourceforge.net> <20000628144800.T29590@lyra.org> Message-ID: <20000628150428.E17875@activestate.com> On Wed, Jun 28, 2000 at 02:48:00PM -0700, Greg Stein wrote: > Regardless: yes, it can certainly break some code. IMO, if any code out > there makes any kinds of assumptions about id(), then they deserve to be > broken :-) Amen. Trent -- Trent Mick trentm@activestate.com From nascheme@enme.ucalgary.ca Wed Jun 28 23:07:43 2000 From: nascheme@enme.ucalgary.ca (Neil Schemenauer) Date: Wed, 28 Jun 2000 16:07:43 -0600 Subject: [Python-Dev] id() on Win64 Message-ID: <20000628160743.A16262@acs.ucalgary.ca> [Greg Stein] >Strictly speaking: the Long only occurs on Win64 platforms. > >I would guess that it is also possible on say, an Alpha running >Linux. Presuming that has 64-bit pointers(?). I think the Alpha is okay. The problem is strange type models were int is 32 bits and pointers are 64. AFAIK, the Alpha uses 64 bits for both. Neil From guido@beopen.com Thu Jun 29 00:10:52 2000 From: guido@beopen.com (Guido van Rossum) Date: Wed, 28 Jun 2000 18:10:52 -0500 Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163) In-Reply-To: Your message of "Wed, 28 Jun 2000 14:48:00 MST." <20000628144800.T29590@lyra.org> References: <200006282112.OAA03095@slayer.i.sourceforge.net> <20000628144800.T29590@lyra.org> Message-ID: <200006282310.SAA05850@cj20424-a.reston1.va.home.com> > > [GvR: note that this means that id() can now return a long on Win32 > > platforms. This *might* break some code...] > > Strictly speaking: the Long only occurs on Win64 platforms. You're right. > I would guess that it is also possible on say, an Alpha running Linux. > Presuming that has 64-bit pointers(?). No, because their longs are also 64 bits, and hence so are Python ints. > Regardless: yes, it can certainly break some code. IMO, if any code out > there makes any kinds of assumptions about id(), then they deserve to be > broken :-) That depends. It is documented as an integer -- which may be vague enough to encompass longs, but that's weasel-wording. ;-) I do think that the likelihood of this breaking significant code is low. --Guido van Rossum (home page: http://www.python.org/~guido/) From gstein@lyra.org Wed Jun 28 23:17:58 2000 From: gstein@lyra.org (Greg Stein) Date: Wed, 28 Jun 2000 15:17:58 -0700 Subject: [Python-Dev] PyString_GET_SIZE() (was: CVS: python/dist/src/Objects classobject.c,2.89,2.90 object.c,2.72,2.73) In-Reply-To: <200006282157.OAA05880@slayer.i.sourceforge.net>; from gvanrossum@users.sourceforge.net on Wed, Jun 28, 2000 at 02:57:20PM -0700 References: <200006282157.OAA05880@slayer.i.sourceforge.net> Message-ID: <20000628151758.X29590@lyra.org> On Wed, Jun 28, 2000 at 02:57:20PM -0700, Guido van Rossum wrote: > Update of /cvsroot/python/python/dist/src/Objects > In directory slayer.i.sourceforge.net:/tmp/cvs-serv5838 > > Modified Files: > classobject.c object.c > Log Message: > Trent Mick: change a few casts for Win64 compatibility. > > > Index: classobject.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Objects/classobject.c,v > retrieving revision 2.89 > retrieving revision 2.90 > diff -C2 -r2.89 -r2.90 > *** classobject.c 2000/06/23 19:37:01 2.89 > --- classobject.c 2000/06/28 21:57:18 2.90 > *************** > *** 284,288 **** > if (v == NULL || !PyString_Check(v)) > return "__name__ must be a string object"; > ! if ((long)strlen(PyString_AS_STRING(v)) != PyString_GET_SIZE(v)) > return "__name__ must not contain null bytes"; > set_slot(&c->cl_name, v); > --- 284,288 ---- > if (v == NULL || !PyString_Check(v)) > return "__name__ must be a string object"; > ! if (strlen(PyString_AS_STRING(v)) != (size_t)PyString_GET_SIZE(v)) > return "__name__ must not contain null bytes"; > set_slot(&c->cl_name, v); Actually, it would seem to make more sense to place the cast *inside* the PyString_GET_SIZE() macro. That is the "true" semantic for GET_SIZE. May as well start some ANSI-fication while we can... Guido: any problem with my changing the macro? Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Wed Jun 28 23:16:17 2000 From: gstein@lyra.org (Greg Stein) Date: Wed, 28 Jun 2000 15:16:17 -0700 Subject: [Python-Dev] httplib doc (was: CVS: python/dist/src/Doc/lib libhttplib.tex,1.19,1.20) In-Reply-To: <200006282151.OAA05489@slayer.i.sourceforge.net>; from fdrake@users.sourceforge.net on Wed, Jun 28, 2000 at 02:51:46PM -0700 References: <200006282151.OAA05489@slayer.i.sourceforge.net> Message-ID: <20000628151617.W29590@lyra.org> Please mark me for a TODO to update the httplib doc. For example, the code below is more effectively written as: h = httplib.HTTPConnection('www.musi-cal.com') h.request('POST', '/cgi-bin/query', paramstring, {'Accept': 'text/plain'}) response = h.getresponse() print response.status # should be 200 data = response.read() # get the raw HTML Note that 'Accept' is usually not a required header and can be omitted in most scenarios. I left it in the example simply to show how to fully map between the old/new APIs. [ Content-Length and Host are sent automatically by HTTPConnection. ] Cheers, -g On Wed, Jun 28, 2000 at 02:51:46PM -0700, Fred L. Drake wrote: > Update of /cvsroot/python/python/dist/src/Doc/lib > In directory slayer.i.sourceforge.net:/tmp/cvs-serv5474/lib > > Modified Files: > libhttplib.tex > Log Message: > > Skip Montanaro : > Added an example of using an HTTP POST request. > > > Index: libhttplib.tex > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Doc/lib/libhttplib.tex,v > retrieving revision 1.19 > retrieving revision 1.20 > diff -C2 -r1.19 -r1.20 > *** libhttplib.tex 1999/04/22 16:47:27 1.19 > --- libhttplib.tex 2000/06/28 21:51:43 1.20 > *************** > *** 115,119 **** > \nodename{HTTP Example} > > ! Here is an example session: > > \begin{verbatim} > --- 115,119 ---- > \nodename{HTTP Example} > > ! Here is an example session that uses the \samp{GET} method: > > \begin{verbatim} > *************** > *** 129,131 **** > --- 129,148 ---- > >>> data = f.read() # Get the raw HTML > >>> f.close() > + \end{verbatim} > + > + Here is an example session that shows how to \samp{POST} requests: > + > + \begin{verbatim} > + >>> import httplib, urllib > + >>> params = urllib.urlencode({'spam': 1, 'eggs': 2, 'bacon': 0}) > + >>> h = httplib.HTTP("www.musi-cal.com:80") > + >>> h.putrequest("POST", "/cgi-bin/query") > + >>> h.putheader("Content-length", "%d" % len(params)) > + >>> h.putheader('Accept', 'text/plain') > + >>> h.putheader('Host', 'www.musi-cal.com') > + >>> h.endheaders() > + >>> h.send(paramstring) > + >>> reply, msg, hdrs = h.getreply() > + >>> print errcode # should be 200 > + >>> data = h.getfile().read() # get the raw HTML > \end{verbatim} > > > _______________________________________________ > Python-checkins mailing list > Python-checkins@python.org > http://www.python.org/mailman/listinfo/python-checkins -- Greg Stein, http://www.lyra.org/ From mal@lemburg.com Wed Jun 28 23:38:29 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 29 Jun 2000 00:38:29 +0200 Subject: [Python-Dev] ucnhash module References: <20000628205832.C3234E2673@oratrix.oratrix.nl> Message-ID: <395A7E65.2271C723@lemburg.com> Jack Jansen wrote: > > I'm a bit worried about the ucnhash module and its huge size. I didn't > follow the discussion closely at the time, because I thought I could > always exclude it from the Pythons without dynamic linking, but now it > seems that if i don't include it test_unicode doesn't run anymore. > > Is this a problem with test_unicode, or should I consider ucnhash a > mandatory module? The ucnhash module is loaded on demand to avoid memory bloat. In practice the difference is not really noticeable since loading a shared module or swapping in a few pages of static C data result in pretty much the same overall memory usage. If no-one complains, I'll fix the test suite though to make the tests of the named Unicode characters optional. Is this ok with you, Bill ? > (BTW: there were also a couple of bugs in the module, include <> in > stead of include "", and static in stead of staticforward > declarations, I'll submit patches for those shortly). I didn't have any problem compiling the module (don't even get warnings when compiling with -Wall) ... but you're right: these ought to get fixed. BTW, since ucnhash.h|c are generated using the scripts in Tools/perfecthash/ your patch should probably also fix the instances of the problems found in there. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From tpeters@beopen.com Wed Jun 28 23:47:04 2000 From: tpeters@beopen.com (Tim Peters) Date: Wed, 28 Jun 2000 18:47:04 -0400 Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163) In-Reply-To: <20000628150428.E17875@activestate.com> Message-ID: [Greg Stein] > Regardless: yes, it can certainly break some code. IMO, if any code out > there makes any kinds of assumptions about id(), then they deserve to be > broken :-) [Trent Mick] > Amen. Guys, it's almost never that simple, and developers are the last ones to think of the reasonable cases that may break. In this case, e.g., code may be doing something as harmless as printing an id() via a "... %d ..." format in a log, and-- BOOM! --that blows up with an OverflowError if you feed it a Python long larger than a C long. I'd rather fix %d formats than leave id() broken, though! id() has to return a unique value. but-i'll-sympathize-with-the-users-even-in-public-ly y'rs - tim From trentm@activestate.com Thu Jun 29 00:49:55 2000 From: trentm@activestate.com (Trent Mick) Date: Wed, 28 Jun 2000 16:49:55 -0700 Subject: [Python-Dev] PyString_GET_SIZE() (was: CVS: python/dist/src/Objects classobject.c,2.89,2.90 object.c,2.72,2.73) In-Reply-To: <20000628151758.X29590@lyra.org> References: <200006282157.OAA05880@slayer.i.sourceforge.net> <20000628151758.X29590@lyra.org> Message-ID: <20000628164955.B19053@activestate.com> On Wed, Jun 28, 2000 at 03:17:58PM -0700, Greg Stein wrote: > On Wed, Jun 28, 2000 at 02:57:20PM -0700, Guido van Rossum wrote: > > Update of /cvsroot/python/python/dist/src/Objects > > In directory slayer.i.sourceforge.net:/tmp/cvs-serv5838 > > > > Modified Files: > > classobject.c object.c > > Log Message: > > Trent Mick: change a few casts for Win64 compatibility. > > > > > > Index: classobject.c > > =================================================================== > > RCS file: /cvsroot/python/python/dist/src/Objects/classobject.c,v > > retrieving revision 2.89 > > retrieving revision 2.90 > > diff -C2 -r2.89 -r2.90 > > *** classobject.c 2000/06/23 19:37:01 2.89 > > --- classobject.c 2000/06/28 21:57:18 2.90 > > *************** > > *** 284,288 **** > > if (v == NULL || !PyString_Check(v)) > > return "__name__ must be a string object"; > > ! if ((long)strlen(PyString_AS_STRING(v)) != PyString_GET_SIZE(v)) > > return "__name__ must not contain null bytes"; > > set_slot(&c->cl_name, v); > > --- 284,288 ---- > > if (v == NULL || !PyString_Check(v)) > > return "__name__ must be a string object"; > > ! if (strlen(PyString_AS_STRING(v)) != (size_t)PyString_GET_SIZE(v)) > > return "__name__ must not contain null bytes"; > > set_slot(&c->cl_name, v); > > Actually, it would seem to make more sense to place the cast *inside* the > PyString_GET_SIZE() macro. That is the "true" semantic for GET_SIZE. > > May as well start some ANSI-fication while we can... > I agree. Go to town, Greg. :) Trent -- Trent Mick trentm@activestate.com From gstein@lyra.org Thu Jun 29 01:08:40 2000 From: gstein@lyra.org (Greg Stein) Date: Wed, 28 Jun 2000 17:08:40 -0700 Subject: [Python-Dev] Text about cycle GC In-Reply-To: <200006282059.PAA04852@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Wed, Jun 28, 2000 at 03:59:46PM -0500 References: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com> <395A359A.2CF0CA70@prescod.net> <14682.15020.589514.702145@bitdiddle.concentric.net> <395A3F62.EA1E8B89@prescod.net> <20000628122725.A13473@acs.ucalgary.ca> <200006282059.PAA04852@cj20424-a.reston1.va.home.com> Message-ID: <20000628170840.E29590@lyra.org> On Wed, Jun 28, 2000 at 03:59:46PM -0500, Guido van Rossum wrote: > > On Wed, Jun 28, 2000 at 11:09:38AM -0700, Paul Prescod wrote: > > > I'm a little disappointed that it will be so difficult for people to > > > test with GC on, but I'm not going to claim that there is some easy way > > > to make it a runtime option because I haven't looked at it at all. There > > > probably isn't. > > > > There isn't. With an interpreter compiled --with-cycle-gc you can > > turn off the collection with gc.set_threshold(0) but that's not > > the same thing. > > > > Neil > > I wonder if we should turn this option *on* during beta testing? > > That way we gather a lot more experience with its use! Maybe nobody > complains and we can leave it on in the final release... That presumes an adequate number of testers and a wide variety of deployment/usage scenarios. Given the relatively short timeframe, that may be a bit aggressive. I *do* agree with enabling it during the beta. But I'm just not sure about leaving it on. Cheers, -g -- Greg Stein, http://www.lyra.org/ From tpeters@beopen.com Thu Jun 29 01:07:20 2000 From: tpeters@beopen.com (Tim Peters) Date: Wed, 28 Jun 2000 20:07:20 -0400 Subject: [Python-Dev] add Demo/imputil/importers.py ? In-Reply-To: <20000628124606.K29590@lyra.org> Message-ID: [Greg Stein] > ... > I'd throw Tools into the same thing [as Demos]. As a separate distro, > you can have a faster release cycle. ... you could release Idle > updates easily and distinctly from the Python core. Note that Guido gave his blessing for a "wide open" policy on IDLE (== its own project in SourceForge, and anyone can be a developer). If that's a success (& I predict it will be, provided someone actually bothers to set up the SF project!), I'd like to see it spread to Tools and Demos too. ignoring-the-downsides-cuz-they'll-make-themselves-known-ly y'rs - tim From guido@beopen.com Thu Jun 29 02:11:36 2000 From: guido@beopen.com (Guido van Rossum) Date: Wed, 28 Jun 2000 20:11:36 -0500 Subject: [Python-Dev] PyString_GET_SIZE() (was: CVS: python/dist/src/Objects classobject.c,2.89,2.90 object.c,2.72,2.73) In-Reply-To: Your message of "Wed, 28 Jun 2000 15:17:58 MST." <20000628151758.X29590@lyra.org> References: <200006282157.OAA05880@slayer.i.sourceforge.net> <20000628151758.X29590@lyra.org> Message-ID: <200006290111.UAA08357@cj20424-a.reston1.va.home.com> > > ! if (strlen(PyString_AS_STRING(v)) != (size_t)PyString_GET_SIZE(v)) > > Actually, it would seem to make more sense to place the cast *inside* the > PyString_GET_SIZE() macro. That is the "true" semantic for GET_SIZE. > > May as well start some ANSI-fication while we can... > > Guido: any problem with my changing the macro? Please leave the macro alone. The type of the macro should be the same as the type of the function -- PyString_Size() -- which is int. If you change this, you potentially get tons of warnings because of the signed / unsigned nature. ANSI-fication is a good project for after 1.6. But even then, it's a separate decision whether the size of a string should be a size_t instead of an int. (The ob_size field should also change, if so -- with even more consequences.) --Guido van Rossum (home page: http://www.python.org/~guido/) From gstein@lyra.org Thu Jun 29 01:29:20 2000 From: gstein@lyra.org (Greg Stein) Date: Wed, 28 Jun 2000 17:29:20 -0700 Subject: [Python-Dev] PyString_GET_SIZE() In-Reply-To: <200006290111.UAA08357@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Wed, Jun 28, 2000 at 08:11:36PM -0500 References: <200006282157.OAA05880@slayer.i.sourceforge.net> <20000628151758.X29590@lyra.org> <200006290111.UAA08357@cj20424-a.reston1.va.home.com> Message-ID: <20000628172919.G29590@lyra.org> On Wed, Jun 28, 2000 at 08:11:36PM -0500, Guido van Rossum wrote: > > > ! if (strlen(PyString_AS_STRING(v)) != (size_t)PyString_GET_SIZE(v)) > > > > Actually, it would seem to make more sense to place the cast *inside* the > > PyString_GET_SIZE() macro. That is the "true" semantic for GET_SIZE. > > > > May as well start some ANSI-fication while we can... > > > > Guido: any problem with my changing the macro? > > Please leave the macro alone. The type of the macro should be the > same as the type of the function -- PyString_Size() -- which is int. > If you change this, you potentially get tons of warnings because of > the signed / unsigned nature. > > ANSI-fication is a good project for after 1.6. But even then, it's a > separate decision whether the size of a string should be a size_t > instead of an int. (The ob_size field should also change, if so -- > with even more consequences.) Post 1.6, yes... I had figured on ob_size changing. Certainly not now :-) But I understand the point about different return types. No problem. [ of course, I would state that PyString_Size should also change and we fix those warnings... but I'll be patient :-) ] How about removing Py_PROTO() usage, and changing function definitions from K&R arg declaration to ANSI declarations? That kind of work is pretty simple, straight-forward, and if somebody has free time to plod through the work... so much the better. I believe that these changes would not introduce any stability problems, and could be done independently from your busy schedule. Hmm. Is there a good place to start listing these todo items? One that we can truly use for communicating this info? In Apache, we have a file named STATUS that everybody uses for dropping ideas, patch references, critical bugs, etc. As that file gets changed, we see it in the -checkins alias, so everybody is aware of the suggested changes/problems/available patches/etc. It also holds people's votes on particular changes. Can we institute something similar? Possibly Misc/STATUS? Should I post Apache's STATUS file as an example? Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Thu Jun 29 01:34:24 2000 From: gstein@lyra.org (Greg Stein) Date: Wed, 28 Jun 2000 17:34:24 -0700 Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager In-Reply-To: <395A32FD.D3C58B23@prescod.net>; from paul@prescod.net on Wed, Jun 28, 2000 at 10:16:45AM -0700 References: <395A32FD.D3C58B23@prescod.net> Message-ID: <20000628173424.H29590@lyra.org> I think you are being paranoid :-) Consider that this same issue applies to all 5900 projects and 38000 developers at SourceForge. VA Linux has a brand identity entirely built on the trust and support of the Linux (and Open Source) communities. If they blow away that trust, they are simply screwed. That said: it would still be a good thing to have export capabilities. I recall that certain portions of the data (the Trove map?) can be exported in XML format. I don't recall the magic URL for that, however. Cheers, -g On Wed, Jun 28, 2000 at 10:16:45AM -0700, Paul Prescod wrote: > I don't want to be paranoid, but are we putting any important > information into SourceForge that we are not backing up elsewhere? I > mean okay, we've all got CVS dumps, but if it went away (DOJ antitrust > suit...) would we have backups of our patches, bugs, wish lists and so > forth? I hope that's a criteria in deciding what services to move to > SourceForge. I am in the business of preserving investments in data and > of telling customers to avoid software that does not keep them in > complete control of their data. SF makes me nervous that way.... > > -- > Paul Prescod - Not encumbered by corporate consensus > The calculus and the rich body of mathematical analysis to which it > gave rise made modern science possible, but it was the algorithm that > made the modern world possible. > - The Advent of the Algorithm (pending), by David Berlinski > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://www.python.org/mailman/listinfo/python-dev -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Thu Jun 29 01:36:41 2000 From: gstein@lyra.org (Greg Stein) Date: Wed, 28 Jun 2000 17:36:41 -0700 Subject: [Python-Dev] RTFM: SourceForge access for Win32 Message-ID: <20000628173641.I29590@lyra.org> All right guys... all this banter about setting up CVS access for Win32 users has been quite silly. Did anybody even stop to look at the docs? http://sfdocs.sourceforge.net/sfdocs/ In particular: http://sfdocs.sourceforge.net/sfdocs/display_topic.php?topicid=19 http://sfdocs.sourceforge.net/sfdocs/display_topic.php?topicid=20 http://sfdocs.sourceforge.net/sfdocs/display_topic.php?topicid=46 There is also a new tool available (released today); http://sfsetup.sourceforge.net/ Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Thu Jun 29 02:01:40 2000 From: gstein@lyra.org (Greg Stein) Date: Wed, 28 Jun 2000 18:01:40 -0700 Subject: [Python-Dev] add Demo/imputil/importers.py ? In-Reply-To: ; from tim_one@email.msn.com on Wed, Jun 28, 2000 at 08:07:20PM -0400 References: <20000628124606.K29590@lyra.org> Message-ID: <20000628180140.M29590@lyra.org> On Wed, Jun 28, 2000 at 08:07:20PM -0400, Tim Peters wrote: > [Greg Stein] > > ... > > I'd throw Tools into the same thing [as Demos]. As a separate distro, > > you can have a faster release cycle. ... you could release Idle > > updates easily and distinctly from the Python core. > > Note that Guido gave his blessing for a "wide open" policy on IDLE (== its > own project in SourceForge, and anyone can be a developer). If that's a > success (& I predict it will be, provided someone actually bothers to set up > the SF project!), I'd like to see it spread to Tools and Demos too. Are you suggesting that IDLE be separate from a Tools/Demo package, or that the whole bunch be shoved out into the wild? Hmm... I guess that I don't much have an opinion one way or the other, but was mostly looking for clarification. Cheers, -g -- Greg Stein, http://www.lyra.org/ From jeremy@beopen.com Thu Jun 29 03:08:51 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Wed, 28 Jun 2000 22:08:51 -0400 (EDT) Subject: [Python-Dev] how do I build pyexpat? Message-ID: <14682.44979.673881.83798@bitdiddle.concentric.net> Setup.in contains the following comment: # (Note: the expat build process doesn't yet build a libexpat.a; you can # do this manually while we try convince the author to add it.) I've got expat, and I've built it, but I don't have any idea how to build libexpat.a. It may be possible to do it manually, but it would help a lot if the comments could say how to build it or contain a link to instructions on how to build it. Jeremy From gward@python.net Thu Jun 29 03:37:08 2000 From: gward@python.net (Greg Ward) Date: Wed, 28 Jun 2000 22:37:08 -0400 Subject: [Python-Dev] Just spotted on SourceForge main page Message-ID: <20000628223707.A1168@beelzebub> Maybe this is what all you Windows folks are looking for. SFSetup v1 released mhearn - 06/28/00 11:00 - SourceForge Setup for Win32 SFSetup is a program to automatically setup SSH and WinCVS for SourceForge projects under the Windows 32 platform. It's now available for download so if you have not yet set up SSH and WinCVS and want it done for you, you can use this program. Go to sfsetup.sourceforge.net to find out how to use it. It's open source and written in Delphi - the code is in CVS and any improvements are welcome! Thanks -mike -- Greg Ward - Linux nerd gward@python.net http://starship.python.net/~gward/ I love ROCK 'N ROLL! I memorized the all WORDS to "WIPE-OUT" in 1965!! From fdrake@beopen.com Thu Jun 29 04:26:55 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Wed, 28 Jun 2000 23:26:55 -0400 (EDT) Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163) In-Reply-To: <200006282310.SAA05850@cj20424-a.reston1.va.home.com> References: <200006282112.OAA03095@slayer.i.sourceforge.net> <20000628144800.T29590@lyra.org> <200006282310.SAA05850@cj20424-a.reston1.va.home.com> Message-ID: <14682.49663.208158.88794@cj42289-a.reston1.va.home.com> Guido van Rossum writes: > That depends. It is documented as an integer -- which may be vague > enough to encompass longs, but that's weasel-wording. ;-) The 1.6 documentation will make it clear that this may be a long integer, but I don't think we need to promise on which platforms this will be the case. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From paul@prescod.net Thu Jun 29 05:21:41 2000 From: paul@prescod.net (Paul Prescod) Date: Wed, 28 Jun 2000 21:21:41 -0700 Subject: [Python-Dev] how do I build pyexpat? References: <14682.44979.673881.83798@bitdiddle.concentric.net> Message-ID: <395ACED5.83764D45@prescod.net> I don't know where you got your expat or how new it is, but with the one I got from the xml-sig, I can type "make libexpat.a" -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From tpeters@beopen.com Thu Jun 29 05:55:22 2000 From: tpeters@beopen.com (Tim Peters) Date: Thu, 29 Jun 2000 00:55:22 -0400 Subject: [Python-Dev] PyString_GET_SIZE() In-Reply-To: <20000628172919.G29590@lyra.org> Message-ID: [Greg Stein] > ... > How about removing Py_PROTO() usage, and changing function > definitions from K&R arg declaration to ANSI declarations? That > kind of work is pretty simple, straight-forward, and if somebody > has free time to plod through the work... so much the better. I think it's too late in the cycle to suggest work for others to do and get any payback from that. Unless you're the one with the free time -- in which case full speed ahead and God bless! I previously volunteered to take the Py_PROTO crap on, as I use an editor with a symbol database that gets confused by that stuff, but I'm sure not going to start that this week. > ... > Hmm. Is there a good place to start listing these todo items? Not that I know of. "Group whiteboards" and shared journals etc are darned useful, though. > One that we can truly use for communicating this info? In Apache, we > have a file named STATUS that everybody uses for dropping ideas, patch > references, critical bugs, etc. As that file gets changed, we see it > in the -checkins alias, so everybody is aware of the suggested > changes/problems/available patches/etc. It also holds people's votes > on particular changes. > > Can we institute something similar? Possibly Misc/STATUS? Should I post > Apache's STATUS file as an example? Yes, sure, no: just check one in! If Guido hates it, we can remove it later. In the meantime, I bet we'll find great ways to use it. In the spirit of Unix, maybe it should be called Misc/gwtbd . let-a-thousand-idiosyncracies-bloom-ly y'rs - tim From tpeters@beopen.com Thu Jun 29 05:55:24 2000 From: tpeters@beopen.com (Tim Peters) Date: Thu, 29 Jun 2000 00:55:24 -0400 Subject: [Python-Dev] RTFM: SourceForge access for Win32 In-Reply-To: <20000628173641.I29590@lyra.org> Message-ID: > All right guys... all this banter about setting up CVS access for Win32 > users has been quite silly. It's been a valuable object lesson, Greg: I showed everyone the value of sitting on their ass until someone who knows what they're doing can't stand it anymore <0.8 wink>. > Did anybody even stop to look at the docs? Didn't seem so to me. I personally never found any docs, despite looking for them. > http://sfdocs.sourceforge.net/sfdocs/ Great! Thank you. > ... > There is also a new tool available (released today); > > http://sfsetup.sourceforge.net/ From tpeters@beopen.com Thu Jun 29 06:08:27 2000 From: tpeters@beopen.com (Tim Peters) Date: Thu, 29 Jun 2000 01:08:27 -0400 Subject: [Python-Dev] add Demo/imputil/importers.py ? In-Reply-To: <20000628180140.M29590@lyra.org> Message-ID: [Greg Stein] > Are you suggesting that IDLE be separate from a Tools/Demo > package, or that the whole bunch be shoved out into the wild? There's already an IDLE distribution distinct from Python's: http://www.python.org/idle/ Note that the IDLE 0.5 there is not what was shipped with 1.5.2; I'm not clear on why that hasn't been updated to IDLE 0.6 already (suspect just lack of time). > Hmm... I guess that I don't much have an opinion one way or the other, but > was mostly looking for clarification. I don't have a specific plan in mind either -- just "me too"ing on the idea that it would do no harm and possibly do real good to let these peripheral (to the core) things live on their own schedules. I don't see any harm in including "the latest" snapshot of them with the core distribution, though -- it's handy for newcomers to get these things without needing to search for them. I know I learned a lot about Python at the start from browsing these directories. From skip@mojam.com (Skip Montanaro) Thu Jun 29 06:27:02 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Thu, 29 Jun 2000 00:27:02 -0500 (CDT) Subject: [Python-Dev] Another Python-based company makes good... Message-ID: <14682.56870.790737.261865@beluga.mojam.com> Saw this on InfoBeat today: ** Yahoo to buy EGroups Yahoo said it would buy e-mail service provider EGroups (www.egroups.com) for $437.5 million in stock to enhance the Internet giant's communications services. Yahoo (YHOO) said it would issue 3.43 million shares of stock for all of EGroups shares, options, and warrants. The purchase will be accounted for as a pooling of interests and is expected to close in the third quarter. Yahoo said it would report a one-time charge during the third quarter for expenses to cover the takeover. Looks like Scott Hassan can safely drop out of grad school now (if he hasn't already)... ;-) -- Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille O'Neal said: "He's got the rings. I listen to the man with the rings." From skip@mojam.com (Skip Montanaro) Thu Jun 29 06:39:09 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Thu, 29 Jun 2000 00:39:09 -0500 (CDT) Subject: [Python-Dev] OT: A Day in the Life of p5p In-Reply-To: <395A31B7.911D9BC2@prescod.net> References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> <395A31B7.911D9BC2@prescod.net> Message-ID: <14682.57597.600123.167311@beluga.mojam.com> Paul> http://gisle.aas.no/perl/illguts/ The author of all those pretty diagrams is going to be really pissed when they rename all the data structures in Perl 6... :-/ Skip From tpeters@beopen.com Thu Jun 29 07:47:41 2000 From: tpeters@beopen.com (Tim Peters) Date: Thu, 29 Jun 2000 02:47:41 -0400 Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager In-Reply-To: <200006281541.KAA02041@cj20424-a.reston1.va.home.com> Message-ID: [Guido] > OK, I've disabled the SF bugs manager. There were two bugs submitted > so far. I've assigned one to you (about os.listdir on Windows) and > one to MAL (about -U vs. exec/eval). You two can take care of > entering these into JB. You can still access the bugs database via > this URL: > > https://sourceforge.net/bugs/?group_id=5470 I moved "my" bug to Jitterbug, and moved Marc-Andre's too to save him the bother. Marked them "Closed" and "Duplicate" on SourceForge, so that if we reenable bug management there someday they won't confuse us. From Moshe Zadka Thu Jun 29 08:12:17 2000 From: Moshe Zadka (Moshe Zadka) Date: Thu, 29 Jun 2000 10:12:17 +0300 (IDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Doc TODO,1.26,1.27 In-Reply-To: <200006282213.PAA13365@slayer.i.sourceforge.net> Message-ID: On Wed, 28 Jun 2000, Fred L. Drake wrote: > + * Update the filecmp documentation (Moshe?). I'm waiting for Gordon to check-in his directory comparisons to filecmp. Gordon? -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com From Fredrik Lundh" Message-ID: <00d501bfe1a2$c93f8cc0$f2a6b5d4@hagrid> tim wrote: > [Greg Stein] > > Regardless: yes, it can certainly break some code. IMO, if any code = out > > there makes any kinds of assumptions about id(), then they deserve = to be > > broken :-) >=20 > [Trent Mick] > > Amen. >=20 > Guys, it's almost never that simple, and developers are the last ones = to > think of the reasonable cases that may break. especially since it's documented to be an integer: id (object)=20 Return the `identity' of an object. This is an integer which is guaranteed to be unique and constant for this object during its lifetime. (section 2.1.4 says that "integer" is the same thing as a "plain integer", and that "long integer" is something different). From gstein@lyra.org Thu Jun 29 10:15:08 2000 From: gstein@lyra.org (Greg Stein) Date: Thu, 29 Jun 2000 02:15:08 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules _sre.c,2.4,2.5 In-Reply-To: <200006290857.BAA11219@slayer.i.sourceforge.net>; from effbot@users.sourceforge.net on Thu, Jun 29, 2000 at 01:57:57AM -0700 References: <200006290857.BAA11219@slayer.i.sourceforge.net> Message-ID: <20000629021508.P29590@lyra.org> Euh... can we get a bit more information in that checkin message. "towards 1.6b1" says zippo about what is changing or why. Cheers, -g On Thu, Jun 29, 2000 at 01:57:57AM -0700, Fredrik Lundh wrote: > Update of /cvsroot/python/python/dist/src/Modules > In directory slayer.i.sourceforge.net:/tmp/cvs-serv11206 > > Modified Files: > _sre.c > Log Message: > towards 1.6b1 > > Index: _sre.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Modules/_sre.c,v > retrieving revision 2.4 > retrieving revision 2.5 > diff -C2 -r2.4 -r2.5 > *** _sre.c 2000/06/01 17:34:20 2.4 > --- _sre.c 2000/06/29 08:57:54 2.5 > *************** > *** 4,20 **** > * $Id$ > * > ! * simple regular expression matching engine > * > * partial history: > ! * 99-10-24 fl created (based on the template matcher) > * 99-11-13 fl added categories, branching, and more (0.2) > * 99-11-16 fl some tweaks to compile on non-Windows platforms > * 99-12-18 fl non-literals, generic maximizing repeat (0.3) > ! * 99-02-28 fl tons of changes (not all to the better ;-) (0.4) > [...1589 lines suppressed...] > > void > ! #if defined(WIN32) > __declspec(dllexport) > #endif > *************** > *** 1708,1713 **** > Cursor_Type.ob_type = &PyType_Type; > > ! Py_InitModule("_sre", _functions); > } > > ! #endif > --- 1846,1851 ---- > Cursor_Type.ob_type = &PyType_Type; > > ! Py_InitModule("_" MODULE, _functions); > } > > ! #endif /* !defined(SRE_RECURSIVE) */ > > > _______________________________________________ > Python-checkins mailing list > Python-checkins@python.org > http://www.python.org/mailman/listinfo/python-checkins -- Greg Stein, http://www.lyra.org/ From Fredrik Lundh" <20000629021508.P29590@lyra.org> Message-ID: <005601bfe1ac$7e014460$f2a6b5d4@hagrid> greg wrote: > Euh... can we get a bit more information in that checkin message. = "towards > 1.6b1" says zippo about what is changing or why. just bringing the repository in sync with the current development snapshot -- I promise to provide more info when the checkins are more focused... just gotta reach "1.6b1 quality" first... From bckfnn@worldonline.dk Thu Jun 29 10:42:03 2000 From: bckfnn@worldonline.dk (Finn Bock) Date: Thu, 29 Jun 2000 09:42:03 GMT Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163) In-Reply-To: References: Message-ID: <395b1528.5978476@smtp.worldonline.dk> [Tim Peters] >id() has to return a unique value. This property of id() does not hold in JPython. When used with hotspot, id() is not unique. regards, finn From Vladimir.Marangozov@inrialpes.fr Thu Jun 29 11:05:12 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Thu, 29 Jun 2000 12:05:12 +0200 (CEST) Subject: [Python-Dev] id() on Win64 In-Reply-To: <395b1528.5978476@smtp.worldonline.dk> from "Finn Bock" at Jun 29, 2000 09:42:03 AM Message-ID: <200006291005.MAA20940@python.inrialpes.fr> Finn Bock wrote: > > [Tim Peters] > > >id() has to return a unique value. > > This property of id() does not hold in JPython. When used with hotspot, > id() is not unique. Is it? Not unique or not persistent during the object's lifetime? -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From Fredrik Lundh" Python\thread_nt.h(185) : error C2065: 'INT_PTR' : undeclared identifier Python\thread_nt.h(185) : error C2146: syntax error : missing ';' before = identifier 'rv' Python\thread_nt.h(185) : error C2065: 'rv' : undeclared identifier Python\thread_nt.h(186) : error C2143: syntax error : missing ';' before = 'type' Python\thread_nt.h(195) : error C2065: 'success' : undeclared identifier in MSVC 5.0, _beginthread returns an "unsigned long" (this is also how it's documented in MSDN). I suggest changing the declaration in thread_nt.h to: #if _MSC_VER >=3D 1200 INT_PTR rv; #else unsigned long rv; #endif on the other hand, the same docs claim that it returns -1 on errors. doesn't exactly look like an unsigned long to me, but that's another story... From Fredrik Lundh" just checked everything out and rebuilt, the exceptions problem sure disappeared, but I still get this error: >>> import array >>> array.array("H", [60000]) Traceback (most recent call last): File "", line 1, in ? OverflowError: signed short integer is greater than maximum second opinion, anyone? From bckfnn@worldonline.dk Thu Jun 29 11:43:55 2000 From: bckfnn@worldonline.dk (Finn Bock) Date: Thu, 29 Jun 2000 10:43:55 GMT Subject: [Python-Dev] id() on Win64 In-Reply-To: <200006291005.MAA20940@python.inrialpes.fr> References: <200006291005.MAA20940@python.inrialpes.fr> Message-ID: <395b26e6.10520397@smtp.worldonline.dk> [Finn Bock] > This property of id() does not hold in JPython. When used with hotspot, > id() is not unique. [Vladimir Marangozov} >Is it? >Not unique or not persistent during the object's lifetime? Not unique. Two different objects can return the same value from System.identityHashCode(). The HTML java docs have this to say about hashCodes: """ As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. (This is typically implemented by converting the internal address of the object into an integer, but this implementation technique is not required by the JavaTM programming language.) """ Its just one of those small difference that we have to live with. In pratical term I have seen it cause problems in pickle.py and copy.deepcopy() regards, finn From gmcm@hypernet.com Thu Jun 29 13:22:12 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Thu, 29 Jun 2000 08:22:12 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Doc TODO,1.26,1.27 In-Reply-To: References: <200006282213.PAA13365@slayer.i.sourceforge.net> Message-ID: <1249841091-43777448@hypernet.com> Moshe wrote: > On Wed, 28 Jun 2000, Fred L. Drake wrote: > > > + * Update the filecmp documentation (Moshe?). > > I'm waiting for Gordon to check-in his directory comparisons to > filecmp. Gordon? Looking at CVS, my stuff was there in filecmp revision 1.2 (+299 -38) and wiped out by 1.3 (+38 -299) which was done the following day. - Gordon From akuchlin@mems-exchange.org Thu Jun 29 13:25:19 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Thu, 29 Jun 2000 08:25:19 -0400 Subject: [Python-Dev] how do I build pyexpat? In-Reply-To: <395ACED5.83764D45@prescod.net>; from paul@prescod.net on Wed, Jun 28, 2000 at 09:21:41PM -0700 References: <14682.44979.673881.83798@bitdiddle.concentric.net> <395ACED5.83764D45@prescod.net> Message-ID: <20000629082519.A13839@newcnri.cnri.reston.va.us> On Wed, Jun 28, 2000 at 09:21:41PM -0700, Paul Prescod wrote: >I don't know where you got your expat or how new it is, but with the one >I got from the xml-sig, I can type >"make libexpat.a" That's a patch I made to the Makefile and submitted to James Clark. For Modules/Setup.in, I can change it to explicitly list the 8 files from Expat that need to be linked to. The problem is that one of the files will vary: # Use one of the next two lines; unixfilemap is better if it works. FILEMAP_OBJ=xmlwf/unixfilemap.o #FILEMAP_OBJ=xmlwf/readfilemap.o --amk From gward@mems-exchange.org Thu Jun 29 13:26:47 2000 From: gward@mems-exchange.org (Greg Ward) Date: Thu, 29 Jun 2000 08:26:47 -0400 Subject: [Python-Dev] OT: A Day in the Life of p5p In-Reply-To: <033a01bfe141$71b0cfc0$f2a6b5d4@hagrid>; from effbot@telia.com on Wed, Jun 28, 2000 at 10:42:56PM +0200 References: <033a01bfe141$71b0cfc0$f2a6b5d4@hagrid> Message-ID: <20000629082647.A27322@ludwig.cnri.reston.va.us> On 28 June 2000, Fredrik Lundh said: > it would be very nice if the file object could do something similar > internally (only in text mode, perhaps). maybe in 1.7? Oddly enough, I've been idly contemplating writing an extension type (hypothetically called "superfile") that makes most of Perl's file-handling semantics, and maybe some of the speedup, available in Python. At one level, it would be a rewrite of my 'text_file' module/TextFile class in C. But this is all speculation, mainly predicated on the theory that I *really* should be eating my own dogfood and distributing some Python extension, instead of just telling other people how to do it. ;-) Greg From gward@mems-exchange.org Thu Jun 29 13:33:39 2000 From: gward@mems-exchange.org (Greg Ward) Date: Thu, 29 Jun 2000 08:33:39 -0400 Subject: [Python-Dev] Text about cycle GC In-Reply-To: <14682.15020.589514.702145@bitdiddle.concentric.net>; from jeremy@beopen.com on Wed, Jun 28, 2000 at 01:49:32PM -0400 References: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com> <395A359A.2CF0CA70@prescod.net> <14682.15020.589514.702145@bitdiddle.concentric.net> Message-ID: <20000629083339.B27322@ludwig.cnri.reston.va.us> On 28 June 2000, Jeremy Hylton said: > PP> import cyclicgc > > PP> should turn on the -with-cycle-gc flag. > > The -with-cycle-gc flag is an option to configure when you build > Python. It can't be turned on or off at runtime. No, no, *obviously* Paul meant that "import cyclicgc" should configure and compile a new Python interpreter with "--with-cycle-gc" and 'exec()' it for you. What else would it mean? ;-) Greg (PS. if this were Perl, you could say use cyclegc; to turn it on, and then elsewhere in your code no cyclegc; to turn it off. Maybe Python needs an "unimport" command?) (Kidding!) From gward@mems-exchange.org Thu Jun 29 13:39:08 2000 From: gward@mems-exchange.org (Greg Ward) Date: Thu, 29 Jun 2000 08:39:08 -0400 Subject: [Python-Dev] ucnhash module In-Reply-To: <395A7E65.2271C723@lemburg.com>; from mal@lemburg.com on Thu, Jun 29, 2000 at 12:38:29AM +0200 References: <20000628205832.C3234E2673@oratrix.oratrix.nl> <395A7E65.2271C723@lemburg.com> Message-ID: <20000629083908.D27322@ludwig.cnri.reston.va.us> On 29 June 2000, M.-A. Lemburg said: > The ucnhash module is loaded on demand to avoid memory bloat. > In practice the difference is not really noticeable since > loading a shared module or swapping in a few pages of static > C data result in pretty much the same overall memory usage. > > If no-one complains, I'll fix the test suite though to make > the tests of the named Unicode characters optional. How 'bout a separate "test_ucn" to test this feature? ...of course, this is yet another case of language syntax features becoming optional and selectable at compile-time, which I still think is a bad idea. Hmmm. Greg From guido@beopen.com Thu Jun 29 14:39:59 2000 From: guido@beopen.com (Guido van Rossum) Date: Thu, 29 Jun 2000 08:39:59 -0500 Subject: [Python-Dev] add Demo/imputil/importers.py ? In-Reply-To: Your message of "Thu, 29 Jun 2000 01:08:27 -0400." References: Message-ID: <200006291339.IAA09887@cj20424-a.reston1.va.home.com> > There's already an IDLE distribution distinct from Python's: > > http://www.python.org/idle/ > > Note that the IDLE 0.5 there is not what was shipped with 1.5.2; I'm not > clear on why that hasn't been updated to IDLE 0.6 already (suspect just lack > of time). Yes. > > Hmm... I guess that I don't much have an opinion one way or the other, but > > was mostly looking for clarification. > > I don't have a specific plan in mind either -- just "me too"ing on the idea > that it would do no harm and possibly do real good to let these peripheral > (to the core) things live on their own schedules. I don't see any harm in > including "the latest" snapshot of them with the core distribution, > though -- it's handy for newcomers to get these things without needing to > search for them. I know I learned a lot about Python at the start from > browsing these directories. Additionally, it's great for Python on Windows to come with a working GUI. Pythonwin may be more like Windows, but it's much more fragile than (recent versions of) IDLE in my experience. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@beopen.com Thu Jun 29 14:49:32 2000 From: guido@beopen.com (Guido van Rossum) Date: Thu, 29 Jun 2000 08:49:32 -0500 Subject: [Python-Dev] PyString_GET_SIZE() In-Reply-To: Your message of "Wed, 28 Jun 2000 17:29:20 MST." <20000628172919.G29590@lyra.org> References: <200006282157.OAA05880@slayer.i.sourceforge.net> <20000628151758.X29590@lyra.org> <200006290111.UAA08357@cj20424-a.reston1.va.home.com> <20000628172919.G29590@lyra.org> Message-ID: <200006291349.IAA09962@cj20424-a.reston1.va.home.com> > Hmm. Is there a good place to start listing these todo items? One that we > can truly use for communicating this info? In Apache, we have a file named > STATUS that everybody uses for dropping ideas, patch references, critical > bugs, etc. As that file gets changed, we see it in the -checkins alias, so > everybody is aware of the suggested changes/problems/available patches/etc. > It also holds people's votes on particular changes. > > Can we institute something similar? Possibly Misc/STATUS? Should I post > Apache's STATUS file as an example? Possibly, but I'm somewhat skeptical. I used to have a large TODO file -- still have it -- but it's so full of long-term ideas that never happened that I rarely look in it any more. I never got into the discipline of using it for my day-to-day priorities -- it was more of a place to write down long-term ideas so I could forget about them. I'll append it. I appreciate a copy of Apache's STATUS file. --Guido van Rossum (home page: http://www.python.org/~guido/) NEW TODO LIST FOR 1.6 ===================== IDLE: set window class? socket/ssl version mystery UNIFIED TODO LIST ================= From psa-members post --------------------- Documentation. I am working on api.tex. The ext.tex file needs a major overhaul too -- it's rather out of date. I still haven't gotten Harlequin's webmaker to produce decent HTML from the FrameMaker version of the reference manual. Unbundling. I'm thinking of unbundling the documentation, demos, most tools, and some platform specific or rarely used extension modules. A proposal would be welcome. There are some unresolved issued with the Py_NewInterpreter() interface and cleaning up threads, e.g. Demo/threads/condition.py doesn't work. I think I may have to change some interfaces (arguably this is more than just a bug). Some stuff that I have pending (the really small or well understood bugs left out): - urllib or ftplib seems to be getting the second transfer not quite right; needs investigation - tmb submitted patches to make creating large lists by appending items one at a time faster; these were controversial because they work by doubling the allocation size, which may waste precious mmmory for very large lists; it is not clear whether it's actually needed - my attempts at threading _tkinter backfired; the Tcl group says I have to build my own version of Tcl and write my own notifier; but I don't want to! - and what to do about createfilehandler on Win and Mac platforms with Tk 8.0? - repr(), str(), print and cmp() may run into infinite loops when comparing recursive objects; this should be fixed by checking the recursion limit present in the thread state - when the byte code gets too big, a better warning should be issued; I've seen it dump core - I'm not sure that dict objects always propagate exceptions in comparisons properly - there's discussion about __init__.py when using ni; should it be a submodule of the project or run in the project's module? - more places should accept arbitrary sequences or mappings instead of lists/tuples and dicts - there's a bunch of typedefs (e.g. binaryfunc) that should be grandly renamed - the .h files should all be renamed - some .c files in Modules are better moved to Python now - doc strings everywhere? - some modules still break on 64-bit platforms - sometimes test_select fails on Win (NT or 95?) with 'error 0' 1.5 TODO list ============= urllib ftp problems -- see message from Wolfgang Weitz finish api.tex! especially, document new threading/embedding interface fix ref.doc look into tmb's diffs (perhaps with an ifdef?) make cPickle use new PyImporty_Import() Showstoppers ------------ Plain old bugs -------------- problem in _tkinter when passing a non-str'able object to tk.call() check photoimage bug reported by Roman Milner to psa-members GetAttr/SetAttr/DelAttr don't check for string object "Must do" wishes ---------------- check for NULL from Py_Initmodule*() limit recursion in repr() etc. a la stack check error when bytecode gets too big is confusing (even core dumps possible!) catch and propagate errors in comparisons in dictobject.c Thread problems --------------- Windows 95/NT ------------- Tk 8.0 compatibility -- what do do about CreateFileHandler? seeks in mailbox.py cause it not to work with files opened in text mode ??? select test fails on Windows with 'error 0' (is this w95?) 64-bit problems --------------- verify that (2L**3671-1)%107423446849988119 is gone test_audioop gives loads of "unaligned access" errors but reports OK test_rgbimg and test_imageop gives segmentation faults Other platform specific ----------------------- mac Tk 8.0 compatibility -- what do do about CreateFileHandler? AIX and linux have broken strftime ultrix needs -li (i18n library) to use threads FAQ --- officially discard the python FAQ from usenet list of FAQs add copyright boilerplate to FAQ (???) point to faq wiz on website point faq maintainers to faq wiz Documentation ------------- \code{~connolly} in liburllib.tex loses the ~ in html conversion add __doc__ strings to type objects (and everywhere else :-) PC/example_nt should also support DevStudio VC++ 5.0 restructure tutorial according to Skip M's suggestions @e in HTML generated from libregex.tex. Cleanup ------- get rid of rgbimg and imgop (and audioop?) move Demo and (some?) Tools from distribution to ftp/web site? merge objimpl.h into object.h; clean up the comments a bunch of typedefs (e.g. binaryfunc) in object.h are still old style; also things like BAD_STATIC_FORWARD, staticforward, statichere (and all the configure macros of course -- HAVE_*) use size_t more often (e.g. for all string and list lengths) (problem: can't be negative) more routines should take arbitrary sequences -- e.g. string.join(), apply() unified uu unpacking of image files for tests urllib ftp cache behaves strangely when files are not read till EOF Wishes ------ improve finalization order in modules need portable file locking primitives look into Embed.Lutz example add fileevent to Tkinter better output when regrtest detects an output difference better diagnostic for skipping tests of optional features Get rid of all references to old cgi module from web site better unified drivers for uu, quopri, base64, binhex, and mimify ni.py interferes with Mark Hammond's special module location mods. ni.py and __init__.py? argcount errors in Tk callbacks show up in traceback for mainloop(n). Done/fixed/dealt with --------------------- [fixed] copy.py bug (use of temp objects in memo?) [that was on purpose] (dl_nt.c lost some code :-) [done] see if method objects can be allocated from a free list [done] the PC/example_nt readme file should be updated [done] document new behavior of os.environ [done] embedding example [done] remove old FAQ from distribution; move new FAQ.html in [done, I presume] AIX 4.2 supports ld -G [fixed] test_strftime crashes on Mac with float -> int conversion [never mind] report of 'str' not defined in NT freeze sometimes [done] build debug and release versions like customary [done] get 5.0 compiler to work; or reinstall 4.2 compiler [done] rename mapping*c to dict*c in project file [fixed] cgi.py uses nonportable unlink semantics [fixed] bug I found in sortmail.py regexes [done] look into JimF's PyImport_Import (to work with ni and rexec) [done] generate ref/postscript [fixed] test_strftime for windows [done] get new cPickle [done] Jim F's cgi.py and tempfile.py (?) [done] Jack's diffs [fixed] __del__ fails if __builtins__ is already gone [done] Lee Busby's patches [no; mhammond has dropped his dialog.py] Lib/tkinter/Dialog.c should be renamed to avoid conflict with PythonWin's Dialog [fixed] fileno() is undocumented [done] Should add HAVE_KILL to configure.in [never mind] look into greg's comments about thread state [fixed] After running test_thread interactively, my sys.exitfunc() dies: Fatal Python error: eval_code2 called without a current thread IOT trap [done] add sys.executable == path of Python binary [done] add SocketType to socket module [done] in regrtest, wrap __import__(test) in try/except+traceback [no; rippped out] is the last_name trick in dictobject.c still needed? [taken care of] delete _ on EOF for better GC? [done] _tkinter threading [fixed] Leak in: while 1: a=eval("1") (also in while 1: exec "a=1") [fixed] urlparse clearcache makes the module non reentrant! [explained] leak in exec reported by Just [yes] make sure Lemburg's regex complaint is taken care of [done] cgi.py should be runnable without environment or input [fixed] shouldn't ignore exceptions in comparisons [probably fixed] exception in ftplib.close can trip urllib [fixed] PyFile_WriteString masks exceptions! [fixed] test_audioop fails [fixed] test_pwd uses an unreliable way to pick a non-existing uid for fakeuid (if the largerst uid is the largest unsigned short, adding 1 makes it 0) [fixed] object.[ch] doesn't have PyObject_HasAttr() even though abstract.h has it [fixed] win32 should guess sys.path like Unix getpath.c [fixed] [by using sleep 5] DG/UX fails test_signal [fixed] getpath.c doesn't work on DOS or OS/2 (Jim A submitted getpathp.c) [fixed] use binary mode in ftpmirror script [fixed] unlink before rename in ftpmirror script [fixed] complexobject.c still has the c_error global [fixed] ihooks' __import__ is leaking file descriptors (cause: the following) [fixed] catching exceptions leaks frames!!! (same as following) [fixed] ceval.c :: set_exc_info() appears to have a refcount problem w.r.t. tstate->exc_* (it never does a DECREF on the prior contents). [fixed] socket test fails on Windows in os.fork() [fixed] add PIL init to tkappinit.c [fixed] cPickle is broken [fixed] Try curses and ncurses for readline (make it a loop?) [fixed] make sure dis.py is up to date. [fixed] read() of 8M file should be more efficient on Windows... [fixed] regexpr.c: '^' doesn't match after '\n' [done] python.exp (AIX) needs to have new symbols added [fixed] README: use Digital Unix, not OSF/1. [fixed] the vc40.mak and example.mak still has different linkage flags (/MD vs. /MTd). don't ask me what they're called in dev studio... [done] remove TODO file from the distribution [ignore] Lundh can't get ``CC=compiler ./configure'' to work [fixed] 64-bit warnings in regexpr.c (Lundh) [done] Set -Olimit 1500 [fixed] test_builtin is broken on 64-bit platforms: if hex(-16) != '0xfffffff0': raise TestFailed, 'hex(-16)' alternative: if len(hex(-1)) != len(hex(sys.maxint)): raise TestFailed, 'len(hex(-1))' if hex(-16) not in ('0xfffffff0', '0xfffffffffffffff0'): raise TestFailed, 'hex(-16)' [fixed] Donn Cave's problems with getpath.c - absolute VPATH doesn't do the right thing - stop after PREFIX [fixed -- use O_NONBLOCK] Why doesn't FCNTL always define FNDELAY? [fixed] re search and match were slowed down 10x by extraneous string copy [fixed] 64-bit shift in cPickle.c:678 ====================================================================== AMK's list: Wishlist for Python 1.5: ======================== * Enhanced regex test suite (AMK) * Updated cursesmodule (documented, supports ncurses) -- add conditionalized ncurses support and a way to detect it (OA) -- document the module (AMK) -- a few demos (Life game, text mode browser(?) ) (AMK & others) * Update BSDDB module to work with version 2.0 of the DB code at http://www.bostic.com/db/ (but 2.0 isn't compatible with 1.85--groan...) * Did anything ever come of the DateTime class that someone had? * More docstrings! * Remove knowledge of the long int representation from Python/marshal.c * minor typo fixes * test suite for dumbdbm.py * whatswrong.py (suggested by Fredrik Lundh) Documentation issues ==================== * Note from someone: calling __dict__ readonly is a massive piece of misinformation, especially when the docs immediately show it being modified. . . (Technically incorrect--__dict__ returns a mutable object, but you can't say i.__dict__={} ) * Document SocketServer. * More documentation on threads * Rework the tutorial, to avoid all the many "New features in Python 1.X" sections (Guido) * Updated Tkinter life preserver (Frederik Lundh) * Better LaTeX typography--narrower margins, nicer appearance -- ragged setting & no hyphenation? -- Decrease the space after periods -- Try to remove footnotes -- Improve conversion to Texinfo and HTML * Improve the index--look for references on making good book indices. GB: A global master index of all identifiers and macros, with descriptions, references to point of definition, and scope, would kick some *serious* butt, but may require some serious sweat... * Text at the start of the index encouraging the user to report index flaws to some e-mail address * Crossreferences across modules. For example, rand.py could have "Related modules: whrandom (sect. X.Y.Z), random (sect. I.J.K)" * A style guide for the documentation * Use macros and styles consistently throughout -- this will involve writing a style guide, and then reading through the TeX source looking for nits... ====================================================================== my own older lists... ====================================================================== Bugs: ... exception in __del__ when __builtins__ has been deleted Features: ... simple threading support (with lock) for Tk Documentation: ... Add section on filesystem interface to tutorial ... Update tutorial for changes in the language & library ... New sections for library reference manual (use NEWS file for hints) ... add stuff to ext.tex about threads and embedded Python ... mention that -2147483648 doesn't work ... mention that 0e0 and 01.0 etc. don't work Maybe not (yet): ... get rid of 'owner' passed around for newframeobject and evalcode ... rename init to PyInit_. ... import ni seems to interpret the current directory as a package. ... prototype for PyOS_CheckStack() somewhere ... On some Linuxes, ``python -c "print 12" | wc'' produces no output??? ... Add INSTALL_ROOT variable to Makefile.in ... More thread testing (Solaris?), wait for David Arnold ... Get rid of more modules: (stdwin, soundex, SGI specific?) ... Use autoconf features to find X11 libraries ... Use more modern autoconf features (e.g. for platform testing) ====================================================================== ====================================================================== The following is old and I haven't checked whether it still applies: (-) many module should export their symbolic constants instead of relying on a module written in Python (-) change regexmodule.c to cooperate with other non-python users and to export the symbolic constants (-) save/restore sys.exc_{type,value,traceback} around except clauses. (-) don't call class instance's __del__ more than once????? (-) add "access" to posix? What name should it have? (-) add facility to "freeze" lists and dictionaries? (-) add WNOHANG to posix (-) support lists in newgetargs() (-) syntax errors detected during compilation should give line number (-) dbm.open(): rwmode, filemode should be made optional; same for gdbm (-) find a bsd hash interface (-) posix.mkdir(): mode should be made optional (-) find a more useful order than alphabetical for Doc/libfuncs.tex ====================================================================== (-) investigate PPRC (-) interface to getdtablesize() in posix (-) reentrancy with global variables vs. decref in ./Modules/cdmodule.c ./Modules/flmodule.c ./Objects/accessobject.c ./Objects/frameobject.c ./Python/traceback.c (-) speed up regsub.gsub (-) try posixenviron.c and merge back into posixmodule.c? (-) add and document chroot() ? (-) Add `@CFLAGS@', `@CPPFLAGS@', and `@LDFLAGS@' to `Makefile.in' (-) modules should be able to define a module destructor hook (-) destroy modules in reverse order of importation? (-) make array a standard built-in object (-) makesetup should accept .o files without corresponding .c file (-) try Boehm/Dehmers/Weiser conservative garbage collector (-) document new Python/C API (-) add various things to module dictionary, e.g. pathname, dictionary where found, __version__ string? (-) pass dict of builtins to exec / execfile / eval ??? (?) stack frame correspondence problem (Jim Roskind) (probably solved by err_fetch / err_restore) (-) make lots of places use newgetargs (-) readline 2.0 on sequent has ^C problem (works only first time) (-) need to add truncate() and ftruncate() to posixmodule.c (Windows: chsize(fd, size) (solution: added to file objects instead) (-) improve performance of list.append/insert etc. by keeping high/low watermark instead of realloc'ing each time? (-) findmethod should cache (also findmember?) (-) sysget("check_interval") is called before each method call which breaks dictlookup caching (-) core dump on repr / print of deeply nested or recursive object (-) whrandom doc needs update (-) fix signalmodule.c to re-establish SIGC[H]LD handler (-) redesign error handling (cf. Donald's mail) (-) does MPW 3.2 need the MPW_881_BUG defined in Parser/acceler.c (-) rename MPW_3_1 define (which really means 3.x) (-) add warning to docs about sys.exc_traceback and sys.last_traceback. (-) latex docs for signal module (-) systematically create /usr/local/lib/python/-/ subdirectories, with a lib/ subdirectory containing the lib*.a files etc. (-) need newer DOS binary (16 bit version doesn't do default args) (-) document Tk (-) class browser (-) interactive Python GUI (a la NT thingie) (-) more stuff under CVS (demo, extensions) (-) use const for char * parameters (and many more) where possible (-) The Great Renaming! (-) document __getattr__, __setattr__ (-) many things that take strings should also take arrays of chars (-) add list of existing extensions to FAQ (-) update "recent additions" chapter in tutorial (-) rewrite "output formatting" chapter in tutorial (-) document addpack, urllib, ... (-) make regsub.[g]sub() optionally case insensitive (-) dynamic linking on the Mac (is this a dream?) (-) Later: - put the offending object in IOError and posix.error - make module marshal work with user-defined file-like objects - built-in help? - hierarchical module names? Big plans: - allow separate interpreters (a la Xt's Applocation Contexts, and Tcl) - complete reflexive nature of the language, e.g. have interfaces et create any kind of object FAQ: why don't list methods return self Even older: make .pyc files executable (how?) thread status and improvements (lock stmt; signal/wait) optional optimizations pthread migration multiple interpreter objects persistency new Dbhash.py, dbhash library (-) dbm objects miss items(), values() methods (-) answer q about coerce() (-) describe() ? (-) distribute demo2 with Holmes (-) classes are too slow (-) add += etc. ? optimize tuple = tuple allow (a, b) = [1, 2] and [1, 2] = (1, 2) ??? explain rules about == vs. 'is' for strings (* by others on the list) rewrite section on formatting in tutorial ====================================================================== TODO-TOO list: test for overflow when converting python long to float lift restrictions on tuple or list in many cases Should double-check all changes with docs! (?) Interrupting output still sometimes doesn't call clearerr() properly sometimes ghost errors when interrupting during debugging in 'continue' mode? typing a comment to a primary prompt shouldn't issue a secondary prompt readline: add hooks to recognize Python syntax and to expand Python commands and names should have absolute pathnames in function objects in general check that all the exceptions are modernized and that the messages aren't giving the same error twice (e.g., stdwinmodule.c!) - check read/write allowed for file objects - introduce macros to set/inspect errno for syscalls, to support things like getoserr() ====================================================================== DOS/Windows Python (???) command line options? (???) interrupts (???) wrap From Fredrik Lundh" <20000628151758.X29590@lyra.org> <200006290111.UAA08357@cj20424-a.reston1.va.home.com> <20000628172919.G29590@lyra.org> <200006291349.IAA09962@cj20424-a.reston1.va.home.com> Message-ID: <006201bfe1c9$b928d400$f2a6b5d4@hagrid> guido wrote: > > Hmm. Is there a good place to start listing these todo items? One = that we > > can truly use for communicating this info? In Apache, we have a file = named > > STATUS that everybody uses for dropping ideas, patch references, = critical > > bugs, etc. As that file gets changed, we see it in the -checkins = alias, so > > everybody is aware of the suggested changes/problems/available = patches/etc. > > It also holds people's votes on particular changes. > >=20 > > Can we institute something similar? Possibly Misc/STATUS? Should I = post > > Apache's STATUS file as an example? >=20 > Possibly, but I'm somewhat skeptical. I used to have a large TODO > file -- still have it -- but it's so full of long-term ideas that > never happened that I rarely look in it any more. instead of a file, I suggest taking a look at ?!ng's Roundup (once 1.6 final is out, of course). From guido@beopen.com Thu Jun 29 14:58:00 2000 From: guido@beopen.com (Guido van Rossum) Date: Thu, 29 Jun 2000 08:58:00 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Doc TODO,1.26,1.27 In-Reply-To: Your message of "Thu, 29 Jun 2000 08:22:12 -0400." <1249841091-43777448@hypernet.com> References: <200006282213.PAA13365@slayer.i.sourceforge.net> <1249841091-43777448@hypernet.com> Message-ID: <200006291358.IAA10045@cj20424-a.reston1.va.home.com> > Moshe wrote: > > > On Wed, 28 Jun 2000, Fred L. Drake wrote: > > > > > + * Update the filecmp documentation (Moshe?). > > > > I'm waiting for Gordon to check-in his directory comparisons to > > filecmp. Gordon? > > Looking at CVS, my stuff was there in filecmp revision 1.2 > (+299 -38) and wiped out by 1.3 (+38 -299) which was done > the following day. Argh! An inappropriate side effect of Ping's cleanup -- thanks for catching this. Apparently Ping didn't do a CVS update before generating his diffs. I can restore version 1.2 easily, but I'm not sure what to do with /F's changes (1.3 -> 1.4). Gordon, can you look at this and suggest what to do? --Guido van Rossum (home page: http://www.python.org/~guido/) From mal@lemburg.com Thu Jun 29 14:04:24 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 29 Jun 2000 15:04:24 +0200 Subject: [Python-Dev] ucnhash module References: <20000628205832.C3234E2673@oratrix.oratrix.nl> <395A7E65.2271C723@lemburg.com> <20000629083908.D27322@ludwig.cnri.reston.va.us> Message-ID: <395B4958.C9909145@lemburg.com> Greg Ward wrote: > > On 29 June 2000, M.-A. Lemburg said: > > The ucnhash module is loaded on demand to avoid memory bloat. > > In practice the difference is not really noticeable since > > loading a shared module or swapping in a few pages of static > > C data result in pretty much the same overall memory usage. > > > > If no-one complains, I'll fix the test suite though to make > > the tests of the named Unicode characters optional. > > How 'bout a separate "test_ucn" to test this feature? Good idea. > ...of course, this is yet another case of language syntax features > becoming optional and selectable at compile-time, which I still think is > a bad idea. Hmmm. It's not selectable at run-time: either you have compiled the module or not. It is enabled per default. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Vladimir.Marangozov@inrialpes.fr Thu Jun 29 14:31:21 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Thu, 29 Jun 2000 15:31:21 +0200 (CEST) Subject: [Python-Dev] Text about cycle GC In-Reply-To: <200006282059.PAA04852@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Jun 28, 2000 03:59:46 PM Message-ID: <200006291331.PAA21571@python.inrialpes.fr> Guido van Rossum wrote: > > I wonder if we should turn this option *on* during beta testing? Why not, as long as --without-gc does not suffer from bugs hidden by --with-gc. > > That way we gather a lot more experience with its use! Maybe nobody > complains and we can leave it on in the final release... This is risky. We don't have enough experience with this implementation. All we know is that things get slower and consume more memory. Without a clear picture of the impact of this GC implementation, it's probably a bad idea to enable (i.e. impose) it by default. The "optional experimental feature" label is good and IMO it complies with anybody's expectations. Interested people will jump in and will eventually contribute with improvements, those who don't care won't and will live happily without it (at least until the day the feature and its implementation reach their expected maturity). -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From gmcm@hypernet.com Thu Jun 29 14:27:01 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Thu, 29 Jun 2000 09:27:01 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Doc TODO,1.26,1.27 In-Reply-To: <200006291358.IAA10045@cj20424-a.reston1.va.home.com> References: Your message of "Thu, 29 Jun 2000 08:22:12 -0400." <1249841091-43777448@hypernet.com> Message-ID: <1249837203-44011365@hypernet.com> [Gordon] > > Looking at CVS, my stuff was there in filecmp revision 1.2 > > (+299 -38) and wiped out by 1.3 (+38 -299) which was done the > > following day. [Guido] > Argh! An inappropriate side effect of Ping's cleanup -- thanks > for catching this. Apparently Ping didn't do a CVS update before > generating his diffs. > > I can restore version 1.2 easily, but I'm not sure what to do > with /F's changes (1.3 -> 1.4). Gordon, can you look at this and > suggest what to do? If you have the eff-bot's diff, it should apply to 1.2 (my changes are all below there - basically I added a rewritten dircmp). I think a CVS merge would do the right thing, too. - Gordon From mal@lemburg.com Thu Jun 29 14:33:36 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 29 Jun 2000 15:33:36 +0200 Subject: [Python-Dev] CVS locks on SF Message-ID: <395B5030.C0F08E82@lemburg.com> I'm getting loads of lock messages during CVS checkins recently. Is this due to overload ? (I wonder why anoncvs access causes locking at all -- there is no write access so why should there be file locking ?): [06:31:40] waiting for anoncvs_python's lock in /cvsroot/python/python/dist/src/Lib/test cvs server: [06:32:10] waiting for anoncvs_python's lock in /cvsroot/python/python/dist/src/Lib/test cvs server: [06:32:41] waiting for anoncvs_python's lock in /cvsroot/python/python/dist/src/Lib/test cvs server: [06:33:11] waiting for anoncvs_python's lock in /cvsroot/python/python/dist/src/Lib/test -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fdrake@beopen.com Thu Jun 29 14:52:40 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 29 Jun 2000 09:52:40 -0400 (EDT) Subject: [Python-Dev] how do I build pyexpat? In-Reply-To: <20000629082519.A13839@newcnri.cnri.reston.va.us> References: <14682.44979.673881.83798@bitdiddle.concentric.net> <395ACED5.83764D45@prescod.net> <20000629082519.A13839@newcnri.cnri.reston.va.us> Message-ID: <14683.21672.414396.364125@cj42289-a.reston1.va.home.com> Andrew Kuchling writes: > That's a patch I made to the Makefile and submitted to James Clark. > For Modules/Setup.in, I can change it to explicitly list the 8 files > from Expat that need to be linked to. The problem is that one of the It's not in the stable version I picked up last night; I'll dig up the experimental version today. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From paul@prescod.net Thu Jun 29 14:52:21 2000 From: paul@prescod.net (Paul Prescod) Date: Thu, 29 Jun 2000 06:52:21 -0700 Subject: [Python-Dev] Text about cycle GC References: <200006291331.PAA21571@python.inrialpes.fr> Message-ID: <395B5495.CF274583@prescod.net> Vladimir Marangozov wrote: > >... > > This is risky. We don't have enough experience with this implementation. > All we know is that things get slower and consume more memory. Without > a clear picture of the impact of this GC implementation, it's probably > a bad idea to enable (i.e. impose) it by default. Won't we have a clear picture by the end of the beta period? > The "optional experimental feature" label is good and IMO it complies > with anybody's expectations. Interested people will jump in and will > eventually contribute with improvements, those who don't care won't > and will live happily without it (at least until the day the feature > and its implementation reach their expected maturity). A million Window users will live unhappily without it because they don't know how to recompile to get it! -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From billtut@microsoft.com Thu Jun 29 14:54:21 2000 From: billtut@microsoft.com (Bill Tutt) Date: Thu, 29 Jun 2000 06:54:21 -0700 Subject: [Python-Dev] re: ucnhash Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD24F@RED-MSG-50> Re: ucnhash and where the stuff gets tested Doesn't matter to me where the test goes. WRT how big it is, thats why its dynamically loaded at run time. If you don't compile it at all, then the \N{...} syntax just won't owrk. Re: static vs. staticforward I can actually do a patch for that, and regen ucnhash.c for you. Re: "" vs. <> Whats wrong with what I'm currently doing? All of the .h files I'm including are on the include file path. "" usage just means stick "." before everything else in your include path. None of the files need that. :) If there's a diffferent policy in the Python source 'bout that that I'm not aware of, then I can fix that issue too. Bill From guido@beopen.com Thu Jun 29 16:03:36 2000 From: guido@beopen.com (Guido van Rossum) Date: Thu, 29 Jun 2000 10:03:36 -0500 Subject: [Python-Dev] CVS locks on SF In-Reply-To: Your message of "Thu, 29 Jun 2000 15:33:36 +0200." <395B5030.C0F08E82@lemburg.com> References: <395B5030.C0F08E82@lemburg.com> Message-ID: <200006291503.KAA10324@cj20424-a.reston1.va.home.com> > I'm getting loads of lock messages during CVS checkins recently. > Is this due to overload ? (I wonder why anoncvs access causes > locking at all -- there is no write access so why should there > be file locking ?): I haven't seen this myself. Could be you were just unlucky. Could be someone was doing a full checkout over a slow connection. I think the anon checkouts still use (read) locks because they need to get a consistent version. --Guido van Rossum (home page: http://www.python.org/~guido/) From gstein@lyra.org Thu Jun 29 15:10:51 2000 From: gstein@lyra.org (Greg Stein) Date: Thu, 29 Jun 2000 07:10:51 -0700 Subject: [Python-Dev] STATUS files (was: PyString_GET_SIZE()) In-Reply-To: <200006291349.IAA09962@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jun 29, 2000 at 08:49:32AM -0500 References: <200006282157.OAA05880@slayer.i.sourceforge.net> <20000628151758.X29590@lyra.org> <200006290111.UAA08357@cj20424-a.reston1.va.home.com> <20000628172919.G29590@lyra.org> <200006291349.IAA09962@cj20424-a.reston1.va.home.com> Message-ID: <20000629071051.T29590@lyra.org> On Thu, Jun 29, 2000 at 08:49:32AM -0500, Guido van Rossum wrote: > > Hmm. Is there a good place to start listing these todo items? One that we > > can truly use for communicating this info? In Apache, we have a file named > > STATUS that everybody uses for dropping ideas, patch references, critical > > bugs, etc. As that file gets changed, we see it in the -checkins alias, so > > everybody is aware of the suggested changes/problems/available patches/etc. > > It also holds people's votes on particular changes. > > > > Can we institute something similar? Possibly Misc/STATUS? Should I post > > Apache's STATUS file as an example? > > Possibly, but I'm somewhat skeptical. I used to have a large TODO > file -- still have it -- but it's so full of long-term ideas that > never happened that I rarely look in it any more. I never got into > the discipline of using it for my day-to-day priorities -- it was more > of a place to write down long-term ideas so I could forget about > them. I'll append it. I appreciate a copy of Apache's STATUS file. Attached below... -- Greg Stein, http://www.lyra.org/ Apache 2.0 STATUS: Last modified at [$Date: 2000/06/28 11:41:14 $] Release: 2.0a5 : ??? 2.0a4 : released June 7, 2000 2.0a3 : released April 28, 2000 2.0a2 : released March 31, 2000 2.0a1 : released March 10, 2000 RELEASE SHOWSTOPPERS: * Win32: Get mod_auth_digest working under win32 - APR_HAS_RANDOM should be defined on windows and there is a lib/apr/misc/win32/rand.c which is basically a copy of what mod_auth_digest used to use. * Re-work configuration for top level Apache. Work should start with trying to clean the autoconf stuff. If and only if this proves impossible to do (very unlikely), autoconf should be removed and we will roll our own config implementation. * suEXEC doesn't work Status: Manoj has posted an patch to fix this. <19991103003605.A20612@samosa.mindspring.com> * Win32: Enable the Windows MPM to honor max_requests_per_child Status: Bill will fix this. * Win32: Get Apache working on Windows 95/98. The following work (at least) needs to be done: - winnt MPM: Fix 95/98 code paths in the winnt MPM. There is some NT specific code that is still not in NT only code paths - IOL binds to APR sendfile, implemented with TransmitFile, which is not available on 95/98. * Win32: Test access logging with multiple threads. Will the native file I/O calls serialize automagically like the CRT calls or do we need to add region locking each time we access the logs? Status: * Win32: Complete the revamp the service environment and relocation into the WinNT MPM. Changes ServerRoot service registry parameter into ConfigArgs for multiple service startup parameters. Problems to fix in the revamp: -k shutdown/restart are broken, signals are not being acknowledged. Close window and shutdown also seem out of sorts. OtherBill is working on this * Win32: fix build/run time environment to remove ApacheCore.dll linkage from ab.exe and htdigest.exe. * We need a thread-safe resolver, at least on Unix. Status: The best known candidate would be something from BIND v9. Status: Greg asks, "why? doesn't gethostbyname_r() handle this?" * Modify mod_cgi and mod_cgid to deal with directories. This allows a lot of directives to be removed from the core. RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: * OS/2: Get loadable modules working again. Requires shared core support which doesn't appear to be catered for in the current build system. * OS/2: Make mod_status work for spmt_os2 MPM. * Build scripts do not recognise AIX 4.2.1 pthreads, so the pthread MPMs will not build. * Win32: Reuse accept socket after transmitfile/close This is not a bug, but would be nice to get this feature in before ship. * Win32: Enable the winnt MPM to use the new scoreboard API * Win32: Implement ap_shm_ functions in APR. * Win32: Win9x console window still won't play nice with the close window, logoff and shutdown scenarios. * Win32: Add a simple hold console open patch (wait for close or the ESC key, with a nice message) if the server died a bad death (non-zero exit code) in console mode. * Platforms that do not support fork (primarily Win32 and AS/400) Consider introducing HAVE_FORK feature macro. Architect start-up code that avoids initializing all the modules in the parent process on platforms that do not support fork. * Clean the code. There are a lot of places we used APR but didn't remove the hacks that were required for the cross-platform code in 1.3. We need to make the code look like APR was supposed to be there. * Go throught the 1.3 Bug DB and research the bugs marked "suspended". People were told these would be considered for inclusion in Apache 2.0, it would be nice to actually do so. * Win32: Migrate the MPM over to use APR thread/process calls. This would eliminate some code in the Win32 branch that essentially duplicates what is in APR. Bill says we need a new procattr, APR_CREATE_SUSPENDED (or something similar) to direct ap_create_process to create the process suspended. We also need a call to wake up the suspended process This may not be able to be implemented everywhere though. Status: * Move I/O layering into APR. * There are still a number of places in the code where we are loosing error status (i.e. throwing away the error returned by a system call and replacing it with a generic error code) * Win32: Implement reliable piped logs on Windows Status: * Use APR to get rid of more platform dependancies. Status: Ryan Bloom is working on this. * The connection status table is not very efficient. Also, very few stats are exported to the connection status table (easy to fix), and mod_status is ugly. * Mass vhosting version of suEXEC. * Replace tables with a proper opaque ADT that has pluggable implementations (including something like the existing data type, plus hash tables for speed, with options for more later). Status: fanf is working on this. * configuration option to use *DBM Status: Greg +1 (volunteers) * add SDBM into src/lib/sdbm/ as a default/fallback DBM implementation. SDBM is used by Perl, mod_dav, mod_sssl, others for basic DBM support. Status: Greg +1 (volunteers) * Integrate mod_dav. Message-id: <20000625173247.M29590@lyra.org> Status: in process. - APR does not provide a couple needed things: chmod() and ap_finfo_t.st_dev. - expat-lite needs to be brought up to parity with the 1.3 vsn and inserted into the config/build process - SDBM needs to go into the config/build process - fix up include dirs to pick up expat-lite, sdbm, dav/main - APR-ization to the dav/fs/ stuff - case_preserved_filename stuff * ap_core_translate() and its use by mod_mmap_static are a bit wonky. The function should probably be exposed as a utility function (such as ap_translate_url2fs() or ap_validate_fs_url() or something). Another approach would be a new hook phase after "translate" which would allow mod_mmap_static to munge what the translation has decided to do. Status: Greg +1 (volunteers), Ryan +1 * Go through ap_config.h and namespace-protect the symbols (e.g. USE_*). Some symbols can/should move to mpm_common.h where possible. * Explore use of a post-config hook for the code in http_main.c which calls ap_fixup_virutal_hosts(), ap_fini_vhost_config(), and ap_sort_hooks() [to reduce the logic in main()] * read the config tree just once, and process N times (as necessary) * add a version number to ap_initialize() as an extra failsafe against (APR) library version skew. MsgID: Status: Greg +1 (volunteers), Jeff +1, Ryan +1, Tony -0(?) * mod_info to use the configuration tree * add output filtering. there are a couple variants for this. - The "link-based" variant is ready to go: MsgID: <20000627044436.N29590@lyra.org> (patch) MsgID: <20000627053302.O29590@lyra.org> (demo usage) MsgID: (problems with the patch) Status: Greg +1, Ryan -1 Other bugs that need fixing: * MaxRequestsPerChild measures connections, not requests. Until someone has a better way, we'll probably just rename it "MaxConnectionsPerChild". * Regex containers don't work in an intutive way Status: No one has come up with an efficient way to fix this behavior. Dean has suggested getting rid of regex containers completely. * SIGSEGV on Linux (glibc 2.1.2) isn't caught properly by a sigwaiting thread. We need to work around this, perhaps unless there is hope soon for a fixed glibc. * The mod_cgid daemon process isn't always cleaned up when httpd gets SIGTERM. Jeff thinks it may be as simple as registering the daemon process for cleanup with the proper pool, but he hasn't looked at it in enough detail. * The MM library is built as static and shared library. This should be set up to build only the required version. Other features that need writing: * Finish infrastructure in core for async MPMs Status: post 2.0 * TODO in source -- just do an egrep on "TODO" and see what's there Documentation that needs writing: * Mod_status docs are needed. * The concept of MPMs, especially if we ship more than one MPM for a given platform * New directives in the various MPMs and appropriate links from obsolete directives in core.html to the MPM documentation. * Revise manual/stopping.html and the last part of manual/misc/perf-tuning.html to take account of the MPMs. * API documentation Status: Ben Laurie has written some hooks documentation (apache-2.0/htdocs/hooks.html) * Changes since 1.3.9 can be more easily seen in the commitlog file dev.apache.org:/home/cvs/CVSROOT/commitlogs/apache-2.0 which includes some of Roy's comments when the changes were committed in rough change-sets by purpose. Note that the commitlog does not show the contents of new files until later. * mod_dav documentation (once integrated) Available Patches: * Mike Abbott's patches to improve performance Status: These were written for 1.3, and are awaiting a port to 2.0 * Jim Winstead's patch to add CookieDomain and other small mod_usertrack features Open issues: * What do we do about mod_proxy? * Which MPMs will be included with Apache 2.0? * Is conf/highperformance.conf-dist obsolete? It looks obsolete. From fredrik@pythonware.com Thu Jun 29 15:11:26 2000 From: fredrik@pythonware.com (Fredrik Lundh) Date: Thu, 29 Jun 2000 16:11:26 +0200 Subject: [Python-Dev] Text about cycle GC References: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com> <395A359A.2CF0CA70@prescod.net> <14682.15020.589514.702145@bitdiddle.concentric.net> <395A3F62.EA1E8B89@prescod.net> <20000628122725.A13473@acs.ucalgary.ca> <200006282059.PAA04852@cj20424-a.reston1.va.home.com> Message-ID: <016a01bfe1d3$ea2474b0$0900a8c0@SPIFF> guido wrote: > I wonder if we should turn this option *on* during beta testing? +1 from me. > That way we gather a lot more experience with its use! Maybe nobody > complains and we can leave it on in the final release... I won't mind (unless it breaks my code, of course). From mal@lemburg.com Thu Jun 29 15:10:28 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 29 Jun 2000 16:10:28 +0200 Subject: [Python-Dev] re: ucnhash References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD24F@RED-MSG-50> Message-ID: <395B58D4.E52CBBD6@lemburg.com> Bill Tutt wrote: > > Re: ucnhash and where the stuff gets tested > > Doesn't matter to me where the test goes. I'm currently trying to check these changes in... doesn't work though due to some obscure CVS locks. > WRT how big it is, thats why its dynamically loaded at run time. > If you don't compile it at all, then the \N{...} syntax just won't owrk. > > Re: static vs. staticforward > I can actually do a patch for that, and regen ucnhash.c for you. Someone (Fred ?) already patches those places for you. He didn't send patches for the perfect hash tool though. > Re: "" vs. <> > Whats wrong with what I'm currently doing? <> uses a differnt header file lookup path... normally doesn't hurt, but... > All of the .h files I'm including are on the include file path. "" usage > just means stick "." before everything else in your include path. > None of the files need that. :) If there's a diffferent policy in the Python > source 'bout that that I'm not aware of, then I can fix that issue too. ... you already know that ;-) Again, these are already fixed :-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido@beopen.com Thu Jun 29 16:15:09 2000 From: guido@beopen.com (Guido van Rossum) Date: Thu, 29 Jun 2000 10:15:09 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Doc TODO,1.26,1.27 In-Reply-To: Your message of "Thu, 29 Jun 2000 09:27:01 -0400." <1249837203-44011365@hypernet.com> References: Your message of "Thu, 29 Jun 2000 08:22:12 -0400." <1249841091-43777448@hypernet.com> <1249837203-44011365@hypernet.com> Message-ID: <200006291515.KAA10374@cj20424-a.reston1.va.home.com> > [Gordon] > > > Looking at CVS, my stuff was there in filecmp revision 1.2 > > > (+299 -38) and wiped out by 1.3 (+38 -299) which was done the > > > following day. > [Guido] > > Argh! An inappropriate side effect of Ping's cleanup -- thanks > > for catching this. Apparently Ping didn't do a CVS update before > > generating his diffs. > > > > I can restore version 1.2 easily, but I'm not sure what to do > > with /F's changes (1.3 -> 1.4). Gordon, can you look at this and > > suggest what to do? [Gordon] > If you have the eff-bot's diff, it should apply to 1.2 (my changes > are all below there - basically I added a rewritten dircmp). I > think a CVS merge would do the right thing, too. There was a change in indent style, so effbot's diff didn't apply cleanly -- but your suggestion made me realize that it was easy to re-apply manually. It's all fixed now. Thanks all! --Guido van Rossum (home page: http://www.python.org/~guido/) From mal@lemburg.com Thu Jun 29 15:15:23 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 29 Jun 2000 16:15:23 +0200 Subject: [Python-Dev] CVS locks on SF References: <395B5030.C0F08E82@lemburg.com> <200006291503.KAA10324@cj20424-a.reston1.va.home.com> Message-ID: <395B59FB.1CD472AE@lemburg.com> Guido van Rossum wrote: > > > I'm getting loads of lock messages during CVS checkins recently. > > Is this due to overload ? (I wonder why anoncvs access causes > > locking at all -- there is no write access so why should there > > be file locking ?): > > I haven't seen this myself. Could be you were just unlucky. Could be > someone was doing a full checkout over a slow connection. > > I think the anon checkouts still use (read) locks because they need to > get a consistent version. Looks like someone is using a 9.6kBaud mobile phone connection ;-) The problem still persists and I've been trying for about half an hour now. I'll try again later today... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido@beopen.com Thu Jun 29 16:21:47 2000 From: guido@beopen.com (Guido van Rossum) Date: Thu, 29 Jun 2000 10:21:47 -0500 Subject: [Python-Dev] Text about cycle GC In-Reply-To: Your message of "Thu, 29 Jun 2000 06:52:21 MST." <395B5495.CF274583@prescod.net> References: <200006291331.PAA21571@python.inrialpes.fr> <395B5495.CF274583@prescod.net> Message-ID: <200006291521.KAA10440@cj20424-a.reston1.va.home.com> > Won't we have a clear picture by the end of the beta period? Not clear. Unfortunately, few people who run important apps will download a beta and try it. But they *will* download a new release labeled "final" and install it without making sure it works for their app. This has been my experience throughout Python's life. I've become pretty conservative about staying backwards compatible as a result... > > The "optional experimental feature" label is good and IMO it complies > > with anybody's expectations. Interested people will jump in and will > > eventually contribute with improvements, those who don't care won't > > and will live happily without it (at least until the day the feature > > and its implementation reach their expected maturity). > > A million Window users will live unhappily without it because they don't > know how to recompile to get it! This can be solved the way we solve everything for Windows users: give them two distributions to choose from -- or maybe one distribution with a checkbox to choose which version to use. --Guido van Rossum (home page: http://www.python.org/~guido/) From skip@mojam.com (Skip Montanaro) Thu Jun 29 14:38:20 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Thu, 29 Jun 2000 08:38:20 -0500 (CDT) Subject: [Python-Dev] Sourceforge Interface Concerns In-Reply-To: References: <20000628025304.BB64A1CE0D@dinsdale.python.org> Message-ID: <14683.20812.615266.196934@beluga.mojam.com> Andy> How many people here have actually created accounts for themselves Andy> on SourceForge and tried to do stuff when logged in - raise bugs Andy> and so on? Did it work for you? I've submitted a few patches with no problems. My usual connections are a corporate T1-ish connection or cable modem access from home, however. -- Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille O'Neal said: "He's got the rings. I listen to the man with the rings." From jeremy@beopen.com Thu Jun 29 15:45:27 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Thu, 29 Jun 2000 10:45:27 -0400 (EDT) Subject: [Python-Dev] how do I build pyexpat? In-Reply-To: <14683.21672.414396.364125@cj42289-a.reston1.va.home.com> References: <14682.44979.673881.83798@bitdiddle.concentric.net> <395ACED5.83764D45@prescod.net> <20000629082519.A13839@newcnri.cnri.reston.va.us> <14683.21672.414396.364125@cj42289-a.reston1.va.home.com> Message-ID: <14683.24839.650558.23732@bitdiddle.concentric.net> >>>>> "FLD" == Fred L Drake, writes: FLD> Andrew Kuchling writes: >> That's a patch I made to the Makefile and submitted to James >> Clark. For Modules/Setup.in, I can change it to explicitly list >> the 8 files from Expat that need to be linked to. The problem is >> that one of the FLD> It's not in the stable version I picked up last night; I'll FLD> dig up the experimental version today. I downloaded version 1.1 from the expat home page. The URL for the download is ftp://ftp.jclark.com/pub/xml/expat.zip. This version hasn't changed in the last two weeks. The instructions Fred include worked almost just right. I checked in the corrected ar command and it looks good. Jeremy From fdrake@beopen.com Thu Jun 29 15:46:48 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 29 Jun 2000 10:46:48 -0400 (EDT) Subject: [Python-Dev] CVS locks on SF In-Reply-To: <200006291503.KAA10324@cj20424-a.reston1.va.home.com> References: <395B5030.C0F08E82@lemburg.com> <200006291503.KAA10324@cj20424-a.reston1.va.home.com> Message-ID: <14683.24920.264911.840500@cj42289-a.reston1.va.home.com> Guido van Rossum writes: > I think the anon checkouts still use (read) locks because they need to > get a consistent version. Yes; you need a directory lock to avoid files getting modified or deleted underneath you while checking out/updating. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake@beopen.com Thu Jun 29 15:48:38 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 29 Jun 2000 10:48:38 -0400 (EDT) Subject: [Python-Dev] re: ucnhash In-Reply-To: <395B58D4.E52CBBD6@lemburg.com> References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD24F@RED-MSG-50> <395B58D4.E52CBBD6@lemburg.com> Message-ID: <14683.25030.205960.13328@cj42289-a.reston1.va.home.com> M.-A. Lemburg writes: > Someone (Fred ?) already patches those places for you. He didn't > send patches for the perfect hash tool though. Not this Fred... -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake@beopen.com Thu Jun 29 15:52:28 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 29 Jun 2000 10:52:28 -0400 (EDT) Subject: [Python-Dev] how do I build pyexpat? In-Reply-To: <14683.24839.650558.23732@bitdiddle.concentric.net> References: <14682.44979.673881.83798@bitdiddle.concentric.net> <395ACED5.83764D45@prescod.net> <20000629082519.A13839@newcnri.cnri.reston.va.us> <14683.21672.414396.364125@cj42289-a.reston1.va.home.com> <14683.24839.650558.23732@bitdiddle.concentric.net> Message-ID: <14683.25260.182929.808330@cj42289-a.reston1.va.home.com> Jeremy Hylton writes: > The instructions Fred include worked almost just right. I checked in > the corrected ar command and it looks good. That's what I get for typing in the dark on a dark keyboard. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tpeters@beopen.com Thu Jun 29 17:23:54 2000 From: tpeters@beopen.com (Tim Peters) Date: Thu, 29 Jun 2000 12:23:54 -0400 Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163) In-Reply-To: <395b1528.5978476@smtp.worldonline.dk> Message-ID: [posted & mailed] [Tim] > id() has to return a unique value. [Finn Bock] > This property of id() does not hold in JPython. When used with hotspot, > id() is not unique. So it's possible there for one of these be true: id(x) == id(y) and x is not y id(x) != id(x) ? Then that's a bug in JPython or hotspot. Know which? Filed a bug report? In CPython, we just use the address of an object's header, and as CPython never moves an object's header in memory, the good stuff follows trivially. Don't know what JPython tries to do, but it's bound to be harder there (as Java can move memory around). From bckfnn@worldonline.dk Thu Jun 29 17:43:09 2000 From: bckfnn@worldonline.dk (Finn Bock) Date: Thu, 29 Jun 2000 16:43:09 GMT Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163) In-Reply-To: References: Message-ID: <395b79a7.31704869@smtp.worldonline.dk> [Tim] >So it's possible there for one of these be true: > > id(x) == id(y) and x is not y > id(x) != id(x) > >? Yes, the first. d = {} cnt = 0 for i in xrange(100000): s = "test" + `i` j = id(s) if d.has_key(j): cnt = cnt + 1 d[j] = s print cnt, "failures" Will print 500+ failures when run by JPython & JDK1.3 on win2k. >Then that's a bug in JPython or hotspot. Know which? JPython. > Filed a bug report? Years ago : http://www.python.org/jpython-bugs/incoming?id=118 >In CPython, we just use the address of an object's header, and as CPython >never moves an object's header in memory, the good stuff follows trivially. >Don't know what JPython tries to do, but it's bound to be harder there (as >Java can move memory around). That is also my guess. I cannot see what we can do about it, except inform users that not all python platform behave exactly the same. Which is why I brought it up. regards, finn From trentm@activestate.com Thu Jun 29 17:42:56 2000 From: trentm@activestate.com (Trent Mick) Date: Thu, 29 Jun 2000 09:42:56 -0700 Subject: [Python-Dev] arraymodule still broken? In-Reply-To: <009e01bfe1b3$c6cd4480$f2a6b5d4@hagrid> References: <009e01bfe1b3$c6cd4480$f2a6b5d4@hagrid> Message-ID: <20000629094256.A21926@activestate.com> On Thu, Jun 29, 2000 at 12:21:22PM +0200, Fredrik Lundh wrote: > just checked everything out and rebuilt, the exceptions > problem sure disappeared, but I still get this error: > > >>> import array > >>> array.array("H", [60000]) > Traceback (most recent call last): > File "", line 1, in ? > OverflowError: signed short integer is greater than maximum > > second opinion, anyone? > I think this is because we are in the middling state where all of my patches have not gotten in yet. I say this because this is what I get with my version that has all of my patches applied: Python 1.6a2 (#1, Jun 29 2000, 09:28:15) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> import array >>> array.array("H", [60000]) array('H', [60000]) >>> Specifically, I haven't looked for the issue. Is it alright if I look at this this weekend? Trent -- Trent Mick trentm@activestate.com From trentm@activestate.com Thu Jun 29 17:53:43 2000 From: trentm@activestate.com (Trent Mick) Date: Thu, 29 Jun 2000 09:53:43 -0700 Subject: [Python-Dev] build problems under MSVC 5.0 In-Reply-To: <008a01bfe1b1$e08a8a60$f2a6b5d4@hagrid> References: <008a01bfe1b1$e08a8a60$f2a6b5d4@hagrid> Message-ID: <20000629095343.B21926@activestate.com> On Thu, Jun 29, 2000 at 12:07:42PM +0200, Fredrik Lundh wrote: > Python\thread_nt.h(185) : error C2065: 'INT_PTR' : undeclared identifier > Python\thread_nt.h(185) : error C2146: syntax error : missing ';' before identifier 'rv' > Python\thread_nt.h(185) : error C2065: 'rv' : undeclared identifier > Python\thread_nt.h(186) : error C2143: syntax error : missing ';' before 'type' > Python\thread_nt.h(195) : error C2065: 'success' : undeclared identifier > This is a result of one of my patches. I was using MSVC 6.0, where INT_PTR is defined as you would expect. I did not realize that it was new to that version of the headers. BTW, INT_PTR, UINT_PTR, etc are the standard defines that I saw Microsoft suggesting in their Win64 docs. I don't like those names, because they are not portable. I should have used the (ANSI?) equivalents: intptr_t, uintptr_t. In fact, I *did* use those in some of my patches where the code portability was required (as obviously it is not in thread_*nt*.h). > in MSVC 5.0, _beginthread returns an "unsigned long" (this is also > how it's documented in MSDN). Yup. And in the Win64 headers _beginthread returns uintptr_t, which makes me wonder why I picked INT_PTR. > > I suggest changing the declaration in thread_nt.h to: > > #if _MSC_VER >= 1200 > INT_PTR rv; > #else > unsigned long rv; > #endif > As I said above, I acknowledge that I should not have used INT_PTR. Win32: unsigned long _beginthread() Win64: uintptr_t _beginthread() I think (am I wrong?) to generalize that the intention for both Win32 and Win64 is to have _beginthread return an unsigned pointer-sized integer: hence uintptr_t. This would eliminate the #ifdef but would require a typedef for uintptr_t on Win32. This can be done in PC/config.h (I already did this for intptr_t, because I needed *that* elsewhere.) Does this also need to be generalized to typedef uintptr_t whereever it is not defined, i.e. in the autoconf files. I can look at this this weekend, if that is soon enough. > on the other hand, the same docs claim that it returns -1 on errors. > doesn't exactly look like an unsigned long to me, but that's another > story... > Yes, strange. Trent -- Trent Mick trentm@activestate.com From Fredrik Lundh" <20000629095343.B21926@activestate.com> Message-ID: <019e01bfe1ec$728c6c00$f2a6b5d4@hagrid> trent wrote: > I think (am I wrong?) to generalize that the intention for both Win32 = and > Win64 is to have _beginthread return an unsigned pointer-sized = integer: hence > uintptr_t. >=20 > This would eliminate the #ifdef but would require a typedef for = uintptr_t on > Win32. This can be done in PC/config.h (I already did this for = intptr_t, > because I needed *that* elsewhere.) Does this also need to be = generalized to > typedef uintptr_t whereever it is not defined, i.e. in the autoconf = files. >=20 > I can look at this this weekend, if that is soon enough. I suggest checking in the #ifdef as a stopgap measure, if you promise to come up with the right thing (whatever that is) in time for 1.6 final. Should I go ahead and check it in? From tpeters@beopen.com Thu Jun 29 18:15:08 2000 From: tpeters@beopen.com (Tim Peters) Date: Thu, 29 Jun 2000 13:15:08 -0400 Subject: [Python-Dev] CVS locks on SF In-Reply-To: <395B5030.C0F08E82@lemburg.com> Message-ID: [MAL] > I'm getting loads of lock messages during CVS checkins recently. > Is this due to overload ? (I wonder why anoncvs access causes > locking at all -- there is no write access so why should there > be file locking ?): IIRC, CVS maintains the illusion of being a multi-user system by using per-*directory* locks. That means it gives you the warm fuzzy feeling that you're being protected against (e.g.) getting an inconsistent snapshot while someone else is committing, but in fact you're not protected at all (inter-directory). It locks per-directory to ensure the integrity of its own data files, but users are subject to the luck of the draw. Note that Perl is maintained under (the commercial, alas) Perforce, which is one of the few SCMs to take multi-developer multi-directory issues seriously. So the good news is that when you see a CVS lock gripe, that means CVS is protecting itself from corruption. The bad news is that if we used a system that protected *us* against inconsistencies too, we'd probably see lock gripes even more often. From gmcm@hypernet.com Thu Jun 29 18:19:51 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Thu, 29 Jun 2000 13:19:51 -0400 Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163) In-Reply-To: References: <395b1528.5978476@smtp.worldonline.dk> Message-ID: <1249823239-44851587@hypernet.com> [Finn Bock] > > This property of id() does not hold in JPython. When used with > > hotspot, id() is not unique. [Tim] > So it's possible there for one of these be true: > > id(x) == id(y) and x is not y > id(x) != id(x) > > ? Then that's a bug in JPython or hotspot. Know which? Filed a > bug report? Oh, you silly boy. There are (by definition) no bugs in hotspot. it's-only-'cause-Guido's-a-weenie-that-Python-has-'em-ly y'rs - Gordon From tpeters@beopen.com Thu Jun 29 18:44:45 2000 From: tpeters@beopen.com (Tim Peters) Date: Thu, 29 Jun 2000 13:44:45 -0400 Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163) In-Reply-To: <395b79a7.31704869@smtp.worldonline.dk> Message-ID: [Finn Bock, says id() is buggy under JPython] [Tim] >> Filed a bug report? [Finn] > Years ago : > http://www.python.org/jpython-bugs/incoming?id=118 >> In CPython, we just use the address of an object's header, and as CPython >> never moves an object's header in memory, the good stuff follows >> trivially. Don't know what JPython tries to do, but it's bound to be >> harder there (as Java can move memory around). > That is also my guess. I cannot see what we can do about it, except > inform users that not all python platform behave exactly the same. Which > is why I brought it up. Well, neither Java's hashCode nor identityHashCode are correct implementations of Python's id(), so JPython's id() is simply wrong. I don't know anything about the internals of JPython. If there's a "choke point" for allocating Python objects, the quickest way out may be to add a write-once "id" field to each Python object under JPython, and simply fill it with an integer that's (safely) incremented by 1 on each allocation. Python doesn't guarantee you'll get the *same* id(x) across implementations, or even across runs under a single implementation, so the implementations of id() in CPython and JPython can do entirely different things. They have to meet the promises in the Python docs, though, and JPython's currently doesn't. From Fredrik Lundh" <395A32FD.D3C58B23@prescod.net> <20000628173424.H29590@lyra.org> Message-ID: <025701bfe1f2$ab5b8420$f2a6b5d4@hagrid> greg wrote: > I think you are being paranoid :-) >=20 > Consider that this same issue applies to all 5900 projects and 38000 > developers at SourceForge. VA Linux has a brand identity entirely = built on > the trust and support of the Linux (and Open Source) communities. If = they > blow away that trust, they are simply screwed. on the other hand, lots of people thought that dejanews would store usenet postings forever... http://salon.com/tech/log/2000/06/20/deja/index.html From Ka-Ping Yee Thu Jun 29 18:47:13 2000 From: Ka-Ping Yee (Ka-Ping Yee) Date: Thu, 29 Jun 2000 10:47:13 -0700 (PDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Doc TODO,1.26,1.27 In-Reply-To: <200006291358.IAA10045@cj20424-a.reston1.va.home.com> Message-ID: On Thu, 29 Jun 2000, Guido van Rossum wrote: > > Argh! An inappropriate side effect of Ping's cleanup -- thanks for > catching this. Apparently Ping didn't do a CVS update before > generating his diffs. My apologies! I'm pretty sure i did an update, but i must have left too long a gap during which 1.2 got checked in. You'd think somehow a version-control system would have noticed the inconsistency between ancestor versions... Anyway, very sorry for the trouble. Glad it appears to be cleared up now. -- ?!ng From Fredrik Lundh" Message-ID: <027101bfe1f3$4d478ae0$f2a6b5d4@hagrid> neil wrote: > [Greg Stein] > >Strictly speaking: the Long only occurs on Win64 platforms. > > > >I would guess that it is also possible on say, an Alpha running > >Linux. Presuming that has 64-bit pointers(?). >=20 > I think the Alpha is okay. The problem is strange type models > were int is 32 bits and pointers are 64. AFAIK, the Alpha uses > 64 bits for both. is this true for linux alpha too? it's definitely true for tru64; we've been using python extensively on that platform since 1995: http://www.smhi.se/weather/satelitbilder/satellitbilder.htm (in swedish, but I suppose you all can figure out what it is anyway ;-) From gward@mems-exchange.org Thu Jun 29 18:55:25 2000 From: gward@mems-exchange.org (Greg Ward) Date: Thu, 29 Jun 2000 13:55:25 -0400 Subject: [Python-Dev] Test results of linuxaudiodev.c Message-ID: <20000629135525.A5221@ludwig.cnri.reston.va.us> Hi -- here are results from testing linuxaudiodev from the latest CVS Python 1.6. This is on a Dell Dimension with on-board audio hardware: the Yamaha YMF724 chipset. I'm using the ALSA 0.5.8a driver (the latest as of a week or two ago, and the only one that supports the YMF724). Bottom line: the test sound plays, but it sounds horrible when played by linuxaudiodev. If I do this: $ play Lib/test/audiotest.au then Cardinal Fang comes through loud and clear. ("play" is a shell script wrapper for "sox", writing to /dev/dsp.) But if I do this: $ ./python Lib/test/regrtest.py test_linuxaudiodev he's still audible (and at the same volume), but very scratchy. Sounds kind of like a very over-driven amp, or like a cheap car radio that somebody attacked with a knife. [...some time passes...] OK, I just tried it on another machine, also a Dell but with a different sound chip: the Crystal CS4232. I'm pretty sure this one is using the OSS drivers included with the kernel, which is probably the second most important difference after the chipset itself. Bottom line: it also sounds horrible. Greg -- Greg Ward - software developer gward@mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From bwarsaw@beopen.com Thu Jun 29 18:57:27 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Thu, 29 Jun 2000 13:57:27 -0400 (EDT) Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163) References: <395b79a7.31704869@smtp.worldonline.dk> Message-ID: <14683.36359.864478.495915@anthem.concentric.net> >>>>> "TP" == Tim Peters writes: TP> Well, neither Java's hashCode nor identityHashCode are correct TP> implementations of Python's id(), so JPython's id() is simply TP> wrong. I don't know anything about the internals of JPython. TP> If there's a "choke point" for allocating Python objects, the TP> quickest way out may be to add a write-once "id" field to each TP> Python object under JPython, and simply fill it with an TP> integer that's (safely) incremented by 1 on each allocation. TP> Python doesn't guarantee you'll get the *same* id(x) across TP> implementations, or even across runs under a single TP> implementation, so the implementations of id() in CPython and TP> JPython can do entirely different things. They have to meet TP> the promises in the Python docs, though, and JPython's TP> currently doesn't. I can't generate patches right now, but what you need to change is in __builtin__.java, the id() function. It should probably call object.id() which would fill in the monotonically incrementing id as Tim suggestions. One question is what to do about Java proxies. Currently built-in id() returns the identityHashCode() of the proxy object, which is just an Object. I'm not sure sticking the id in the wrapper is the right thing or not. -Barry From Fredrik Lundh" <395A32FD.D3C58B23@prescod.net> <20000628173424.H29590@lyra.org> <025701bfe1f2$ab5b8420$f2a6b5d4@hagrid> <20000629110557.W29590@lyra.org> Message-ID: <02d901bfe1f6$720ca920$f2a6b5d4@hagrid> greg wrote: > > on the other hand, lots of people thought that dejanews > > would store usenet postings forever... >=20 > Different problem space. They weren't holding people's data. well, they dropped a few thousand eff-bot postings ;-) > Worrying about it is a useless exercise, IMO. well, I'm not worried. but in the internet universe, strange things happen all the time... (checked out http://www.fuckedcompany.com/ lately?) ... btw, has anyone checked what's in: http://cvs.sourceforge.net/cvstarballs/python-cvsroot.tar.gz=20 (with ping times somewhere around one second, it's too large for me to check out...) From Fredrik Lundh" <20000628113505.C15643@ludwig.cnri.reston.va.us> Message-ID: <02cd01bfe1f4$a271cca0$f2a6b5d4@hagrid> greg wrote: > On 28 June 2000, Fredrik Lundh said: > > http://prometheus.frii.com/~gnat/yapc/2000-p5p.txt > >=20 > > unfortunately, his "What is it with those Python fucks anyway" talk > > isn't posted... ;-) >=20 > But the "Conclusion" of his "Lies We Tell" talk: >=20 > Perl sucks. Use Python. >=20 > Presumably tongue-in-cheek, but you never know... note that all lies he mentioned earlier in that talk was quoted; this one wasn't. in other words, it's a fact. but we already know that, don't we ;-) From bwarsaw@beopen.com Thu Jun 29 19:56:52 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Thu, 29 Jun 2000 14:56:52 -0400 (EDT) Subject: [Python-Dev] Test results of linuxaudiodev.c References: <20000629135525.A5221@ludwig.cnri.reston.va.us> Message-ID: <14683.39924.477408.233069@anthem.concentric.net> >>>>> "GW" == Greg Ward writes: GW> then Cardinal Fang comes through loud and clear. ("play" is a GW> shell script wrapper for "sox", writing to /dev/dsp.) But if GW> I do this: GW> $ ./python Lib/test/regrtest.py test_linuxaudiodev GW> he's still audible (and at the same volume), but very GW> scratchy. Sounds kind of like a very over-driven amp, or like GW> a cheap car radio that somebody attacked with a knife. I don't even get that. play works fine for me too, but on this Dell Optiplex GX110 with unknown sound chip set, test_linuxaudiodev gives me nothing. -Barry From gstein@lyra.org Thu Jun 29 19:05:57 2000 From: gstein@lyra.org (Greg Stein) Date: Thu, 29 Jun 2000 11:05:57 -0700 Subject: [Python-Dev] sourceforge data (was: Let's use the SourceForge Patch Manager) In-Reply-To: <025701bfe1f2$ab5b8420$f2a6b5d4@hagrid>; from effbot@telia.com on Thu, Jun 29, 2000 at 07:51:32PM +0200 References: <395A32FD.D3C58B23@prescod.net> <20000628173424.H29590@lyra.org> <025701bfe1f2$ab5b8420$f2a6b5d4@hagrid> Message-ID: <20000629110557.W29590@lyra.org> On Thu, Jun 29, 2000 at 07:51:32PM +0200, Fredrik Lundh wrote: > greg wrote: > > I think you are being paranoid :-) > > > > Consider that this same issue applies to all 5900 projects and 38000 > > developers at SourceForge. VA Linux has a brand identity entirely built on > > the trust and support of the Linux (and Open Source) communities. If they > > blow away that trust, they are simply screwed. > > on the other hand, lots of people thought that dejanews > would store usenet postings forever... Different problem space. They weren't holding people's data. If SourceForge were ever to close, then I have 100% faith that they would make sure to provide a way for everybody to get their data off the machines. Worrying about it is a useless exercise, IMO. Cheers, -g -- Greg Stein, http://www.lyra.org/ From guido@beopen.com Thu Jun 29 20:05:11 2000 From: guido@beopen.com (Guido van Rossum) Date: Thu, 29 Jun 2000 14:05:11 -0500 Subject: [Python-Dev] CVS locks on SF In-Reply-To: Your message of "Thu, 29 Jun 2000 13:15:08 -0400." References: Message-ID: <200006291905.OAA17265@cj20424-a.reston1.va.home.com> > [MAL] > > I'm getting loads of lock messages during CVS checkins recently. > > Is this due to overload ? (I wonder why anoncvs access causes > > locking at all -- there is no write access so why should there > > be file locking ?): > > IIRC, CVS maintains the illusion of being a multi-user system by using > per-*directory* locks. That means it gives you the warm fuzzy feeling that > you're being protected against (e.g.) getting an inconsistent snapshot while > someone else is committing, but in fact you're not protected at all > (inter-directory). It locks per-directory to ensure the integrity of its > own data files, but users are subject to the luck of the draw. Yes, that's how it works... > Note that Perl is maintained under (the commercial, alas) Perforce, which is > one of the few SCMs to take multi-developer multi-directory issues > seriously. We tried Perforce at CNRI. It's really neat, but somehow it was lacking some stuff we were used to and we never converted. Note that Perforce is free for open source projects -- at least at the time it was. (CNRI paid a license fee, but that was just an expression of CNRI's reluctance against free software. :-) There's also bitkeeper. It stayed in beta so long that we gave up (and they have a weird license) -- but it's out of beta since May 4: see http://www.bitkeeper.com/. But there's no immediate download! You must sign up and they send you instructions in the mail... > So the good news is that when you see a CVS lock gripe, that means CVS is > protecting itself from corruption. The bad news is that if we used a system > that protected *us* against inconsistencies too, we'd probably see lock > gripes even more often. Well, the implementation could save the previous consistent version and give you that while an update was under way... There are other ways to protect against inconsistencies. But I'm not sure that you always *want* this -- as a system grows, it's better to be able to deal with inconsistencies than to try to avoid them (and have the world blow up in your face when the avoidance fails). Anyway, I submitted a service request to have the lock in the Lib/test lock removed. (Apparently some process didn't clear up its lock. That's rare, but sometimes it happens.) It's been fixed now, so checkins in the Lib/test directory should move forward again. --Guido van Rossum (home page: http://www.python.org/~guido/) From bckfnn@worldonline.dk Thu Jun 29 20:15:45 2000 From: bckfnn@worldonline.dk (Finn Bock) Date: Thu, 29 Jun 2000 19:15:45 GMT Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163) In-Reply-To: References: Message-ID: <395b9f71.41379240@smtp.worldonline.dk> [Tim] >Well, neither Java's hashCode nor identityHashCode are correct >implementations of Python's id(), so JPython's id() is simply wrong. I agree. >I don't know anything about the internals of JPython. If there's a "choke >point" for allocating Python objects, The constructor of PyObject should do nicely. >the quickest way out may be to add a >write-once "id" field to each Python object under JPython, and simply fill >it with an integer that's (safely) incremented by 1 on each allocation. Properly have to be a java long to avoid overflowing. >Python doesn't guarantee you'll get the *same* id(x) across implementations, >or even across runs under a single implementation, so the implementations of >id() in CPython and JPython can do entirely different things. They have to >meet the promises in the Python docs, though, and JPython's currently >doesn't. I haven't considered it to be so important. It is possible to fix the std modules so it doesn't cause problems (as is done in cPickle.java). [Barry] >One question is what to do about Java proxies. Currently built-in >id() returns the identityHashCode() of the proxy object, which is just >an Object. I'm not sure sticking the id in the wrapper is the right >thing or not. It properly isn't. New wrappers can be created for the same object. F.ex when a java object is passed from python into java code and returned back into python, two wrappers will exists for the same java object. Since these two wrappers represent the same object they should (as it does now) return the same id() value. regards, finn From bwarsaw@beopen.com Thu Jun 29 20:23:48 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Thu, 29 Jun 2000 15:23:48 -0400 (EDT) Subject: [Python-Dev] Re: sourceforge data (was: Let's use the SourceForge Patch Manager) References: <395A32FD.D3C58B23@prescod.net> <20000628173424.H29590@lyra.org> <025701bfe1f2$ab5b8420$f2a6b5d4@hagrid> <20000629110557.W29590@lyra.org> <02d901bfe1f6$720ca920$f2a6b5d4@hagrid> Message-ID: <14683.41540.530581.459708@anthem.concentric.net> >>>>> "FL" == Fredrik Lundh writes: FL> btw, has anyone checked what's in: FL> http://cvs.sourceforge.net/cvstarballs/python-cvsroot.tar.gz I suck down nightly copies of that file and the corresponding Mailman tarball. I looked at them when I first set up my script, but haven't checked them lately. -Barry From nascheme@enme.ucalgary.ca Thu Jun 29 21:02:02 2000 From: nascheme@enme.ucalgary.ca (Neil Schemenauer) Date: Thu, 29 Jun 2000 14:02:02 -0600 Subject: [Python-Dev] CVS locks on SF In-Reply-To: <200006291905.OAA17265@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jun 29, 2000 at 02:05:11PM -0500 References: <200006291905.OAA17265@cj20424-a.reston1.va.home.com> Message-ID: <20000629140201.A20446@acs.ucalgary.ca> I recently made the conversion from CVS to PRCS. I like PRCS much better. It is easier to use, implemented indepentant of rcs, faster, more flexible and has versioned project meta-data. Branching and merging is much simpiler than CVS. Operations on project versions are atomic. Renaming and moving files is easy. It is well documented. Unfortunately version 1 does not support distributed repositories. Josh has informed my that version to is coming (hopefully this year) and will support distributed repositories. For Python I don't think that a multi-user version control system is strictly necessary anyhow. The PRCS repository could be made available via rsync and a process could be setup for checking patches into the central repository. It should actually be more efficient than the current CVS setup. I just looked at the webpage and the beta for 2.0 is out: http://www.xcf.berkeley.edu/~jmacd/prcs.html If PythonLabs is interested in using PRCS I will even volunteer to make sure those Windows weenies have a good port. :) Neil From jeremy@beopen.com Thu Jun 29 21:40:14 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Thu, 29 Jun 2000 16:40:14 -0400 (EDT) Subject: [Python-Dev] CVS locks on SF In-Reply-To: <20000629140201.A20446@acs.ucalgary.ca> References: <200006291905.OAA17265@cj20424-a.reston1.va.home.com> <20000629140201.A20446@acs.ucalgary.ca> Message-ID: <14683.46126.19856.447975@bitdiddle.concentric.net> I was just looking at Josh's work last week, and thought it looks quite interesting. Despite my interest, I don't expect we would use it for Python unless SourceForge adopted it. We moved the Python CVS tree to SourceForge to avoid maintaing a large installation of software development/management tools. Jeremy From klm@digicool.com Thu Jun 29 21:53:21 2000 From: klm@digicool.com (Ken Manheimer) Date: Thu, 29 Jun 2000 16:53:21 -0400 (EDT) Subject: [Python-Dev] Wikis for todo lists, etc (was PyString_GET_SIZE()) In-Reply-To: Message-ID: On Thu, 29 Jun 2000, Tim Peters wrote: > > ... > > Hmm. Is there a good place to start listing these todo items? > > Not that I know of. "Group whiteboards" and shared journals etc are darned > useful, though. Wiki = Group whiteboard Zope could do a lot of this stuff well. As is, ZWiki offers some organizational features. I've held off on pushing them because they're still baking - things like change notifications, discretion about change privileges, versions (with differences, based on your ndiff.py), etc are coming soonish. (Exactly how soonish is hard to say, the way time and more direct business obligations are - but this stuff actually is important to us, we're using them a lot for collaboration, and need for the dynamics to scale...) I also have the feeling that our tracker would be good for patch management - except, i don't really know what the requirements are, there, and once again, tracker only gives notifications via email, it doesn't take input that way. Anyway, to see leads on both zwikis and tracker, see: http://www.zope.org/Members/klm/TrackerWiki Oh, and it would be easy to set up a wiki for python dev on zope.org somewhere - i could put it in my account, or we could situate one more centrally, in a storage that's never packed, so the version history is maintained. Or any of you could get a zope.org membership and set some up, yerselves. Or set up a zope somewhere - it'd be !cool! if sourceforge were willing... Ken klm@zope.org From klm@digicool.com Thu Jun 29 22:25:55 2000 From: klm@digicool.com (Ken Manheimer) Date: Thu, 29 Jun 2000 17:25:55 -0400 (EDT) Subject: [Python-Dev] Wikis for todo lists, etc (was PyString_GET_SIZE()) In-Reply-To: Message-ID: On Thu, 29 Jun 2000, Ken Manheimer wrote: > Wiki = Group whiteboard > [...] > Oh, and it would be easy to set up a wiki for python dev on zope.org > somewhere - i could put it in my account, or we could situate one more http://www.zope.org/Members/klm/PythonDev/TodoLists There's nothing else of substance there, but anyone who's a member at zope.org can edit and add pages... Ken From guido@python.org Fri Jun 30 00:25:09 2000 From: guido@python.org (Guido van Rossum) Date: Thu, 29 Jun 2000 18:25:09 -0500 Subject: [Python-Dev] New PythonLabs site revealed! Message-ID: <200006292325.SAA19744@cj20424-a.reston1.va.home.com> Today, without much fanfare, we opened the new PythonLabs website. The design is by BeOpen's creative Director, Jun Simmons. Thanks to Jeremy Hylton, who did most of the actual HTML editing to get our contents in place. The new beta will be released via this site. And since you python-dev folks will find this out through my checkins anyway, let this be an advance warning that it will be called Python 2.0. Here's my explanation for the version bump (soon to be checked in to README): """ While Pythoneers have grown fond of Python's exceedingly slow version incrementing, that same quality makes parts of the rest of the world think Python is barely out of its first alpha test. Especially enterprise customers are often fearful of anything that's version 1.x! The new version number also clearly marks Python's departure from CNRI. Previously, the version number 2.0 was associated with a mythical and elusive incompatible future release. That release (still ways off, and not as incompatible as people fear!) is now referred to as Python 3000. """ --Guido van Rossum (home page: http://www.python.org/~guido/) From mwh21@cam.ac.uk Thu Jun 29 23:53:39 2000 From: mwh21@cam.ac.uk (Michael Hudson) Date: 29 Jun 2000 23:53:39 +0100 Subject: [Python-Dev] Test results of linuxaudiodev.c In-Reply-To: Greg Ward's message of "Thu, 29 Jun 2000 13:55:25 -0400" References: <20000629135525.A5221@ludwig.cnri.reston.va.us> Message-ID: Greg Ward writes: > Hi -- > > here are results from testing linuxaudiodev from the latest CVS Python > 1.6. This is on a Dell Dimension with on-board audio hardware: the > Yamaha YMF724 chipset. I'm using the ALSA 0.5.8a driver (the latest as > of a week or two ago, and the only one that supports the YMF724). > > Bottom line: the test sound plays, but it sounds horrible when played by > linuxaudiodev. If I do this: > > $ play Lib/test/audiotest.au > > then Cardinal Fang comes through loud and clear. ("play" is a shell > script wrapper for "sox", writing to /dev/dsp.) But if I do this: > > $ ./python Lib/test/regrtest.py test_linuxaudiodev > > he's still audible (and at the same volume), but very scratchy. Sounds > kind of like a very over-driven amp, or like a cheap car radio that > somebody attacked with a knife. > > [...some time passes...] > > OK, I just tried it on another machine, also a Dell but with a different > sound chip: the Crystal CS4232. I'm pretty sure this one is using the > OSS drivers included with the kernel, which is probably the second most > important difference after the chipset itself. Bottom line: it also > sounds horrible. Just tried that here; ouch. I have a Dell Dimension XPS D233 (which has an on-board Yamaha chipset - the OPL2, I believe). I use the sound driver that comes with the redhat built kernel (which is the OSS one I think). $ play audiotest.au sounds fine, $ ../../../build/python regrtest.py test_linuxaudiodev.py \ test_linuxaudiodev sounds horrible; it sounds like it's being rammed through at far too high a volume, but playing with the PCM or volume sliders in gmix has no appreciable effect on the quality. This suggests somewhat that the problem lies in linuxaudiodev.c, doesn't it? Is this stuff, like, documented anywhere? I can't find any helpful manpages... I presume this module must work better than this for some people? Cheers, M. From guido@python.org Fri Jun 30 01:20:15 2000 From: guido@python.org (Guido van Rossum) Date: Thu, 29 Jun 2000 19:20:15 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils msvccompiler.py,1.33,1.34 In-Reply-To: Your message of "Thu, 29 Jun 2000 16:05:01 MST." <200006292305.QAA11929@slayer.i.sourceforge.net> References: <200006292305.QAA11929@slayer.i.sourceforge.net> Message-ID: <200006300020.TAA21877@cj20424-a.reston1.va.home.com> > On second thought, first try for _winreg, and then winreg. Only if both > fail do we try for win32api/win32con. If *those* both fail, then we don't > have registry access. Phew! Is this smart? Doesn't the new winreg have a very different I/F than the old one? --Guido van Rossum (home page: http://www.python.org/~guido/) From pingster@ilm.com Fri Jun 30 00:24:28 2000 From: pingster@ilm.com (Ka-Ping Yee) Date: Thu, 29 Jun 2000 16:24:28 -0700 (PDT) Subject: [Python-Dev] Test results of linuxaudiodev.c In-Reply-To: Message-ID: On 29 Jun 2000, Michael Hudson wrote: > $ play audiotest.au > > sounds fine, > > $ ../../../build/python regrtest.py test_linuxaudiodev.py \ > test_linuxaudiodev > > sounds horrible; it sounds like it's being rammed through at far too > high a volume Sounds like u-law to me. linuxaudiodev.c selects /dev/dsp by default, which accepts raw data, not .au format. Try setting the environment variable AUDIODEV to /dev/audio before running the test script. Does that work any better? -- ?!ng From fdrake@beopen.com Fri Jun 30 00:29:42 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 29 Jun 2000 19:29:42 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils msvccompiler.py,1.33,1.34 In-Reply-To: <200006300020.TAA21877@cj20424-a.reston1.va.home.com> References: <200006292305.QAA11929@slayer.i.sourceforge.net> <200006300020.TAA21877@cj20424-a.reston1.va.home.com> Message-ID: <14683.56294.836295.923883@cj42289-a.reston1.va.home.com> Greg Ward wrote in a checkin message: > On second thought, first try for _winreg, and then winreg. Only if both > fail do we try for win32api/win32con. If *those* both fail, then we don't > have registry access. Phew! Guido van Rossum writes on python-dev: > Is this smart? Doesn't the new winreg have a very different I/F than > the old one? No, this is bad. It *will* break with winreg; if _winreg isn't available, it should use the win32api/win32con/whatever stuff; it's a Python 1.5.2 interpreter at that point. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From skip@mojam.com (Skip Montanaro) Thu Jun 29 23:22:18 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Thu, 29 Jun 2000 17:22:18 -0500 (CDT) Subject: [Python-Dev] Mysterious SF message... Message-ID: <14683.52250.789900.357275@beluga.mojam.com> I just submitted a patch for lib/libatexit.tex. In the response page it displayed a list of patches, then the following cryptic message: Patch Uploaded Successfully Added Patch Could Not Send Patch Update Any idea what that means? -- Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille O'Neal said: "He's got the rings. I listen to the man with the rings." From tpeters@beopen.com Fri Jun 30 00:32:42 2000 From: tpeters@beopen.com (Tim Peters) Date: Thu, 29 Jun 2000 19:32:42 -0400 Subject: [Python-Dev] Controversial patch (cmath) Message-ID: I just voted to accept a patch that's broken. If you want to argue it, be my guest, but I'm out of it now . Here's the patch: https://sourceforge.net/patch/?func=detailpatch&patch_id=100651&group_id=547 0 Here's my comment (also available on that page): Accepted (but reluctantly; see below), and assigned back to Guido for checkin. cmathmodule is not production quality, and this patch isn't either, but its asinh and acosh are better than what's there now. The author avoided some of the numerical foolishness in the original, but didn't avoid all of it. For example, it's harder to get asinh to do something ridiculous now than it was before, but still possible: >>> cmath.acosh(1e200) (461.210165779+0j) >>> cmath.asinh(1e200) (1.#INF+0j) >>> asinh should have returned something approximately equal to what acosh returned. That may not be the patch's problem, though! I suspect that's due to one of the module's other functions that's too naive about the limits of floating point. In any case, it is much easier to provoke the *current* cmath functions into cases like this one. Another possible problem has to do with principal values. My reference books are in storage, so about the best I can do right now is compare what this code does to Macsyma (which I have on my laptop). The acosh in this patch often returns the negative of what Macysma computes. For example, >>> cmath.acosh(-1-1j) (1.06127506191-2.23703575929j) >>> Macsyma returns the negation of that. On the other hand, the *original* acosh doesn't agree with Macsyma on some signs where this acosh does. So call this one a wash. I may have mentioned this before : robust math libraries are extremely difficult to get right. It would take several months to write a production-quality cmath module from scratch, which is several months more than were devoted to Python's current cmath . I vote we check this in anyway (since it *is*, overall, an improvement), and look into borrowing some other language's complex math library later (note in particular that C9X adds complex numbers and these functions on them, so if we sit on our asses long enough, we can inherit libc's!). From mwh21@cam.ac.uk Fri Jun 30 00:33:37 2000 From: mwh21@cam.ac.uk (Michael Hudson) Date: 30 Jun 2000 00:33:37 +0100 Subject: [Python-Dev] Test results of linuxaudiodev.c In-Reply-To: Ka-Ping Yee's message of "Thu, 29 Jun 2000 16:24:28 -0700 (PDT)" References: Message-ID: Ka-Ping Yee writes: > On 29 Jun 2000, Michael Hudson wrote: > > $ play audiotest.au > > > > sounds fine, > > > > $ ../../../build/python regrtest.py test_linuxaudiodev.py \ > > test_linuxaudiodev > > > > sounds horrible; it sounds like it's being rammed through at far too > > high a volume > > Sounds like u-law to me. linuxaudiodev.c selects /dev/dsp by > default, which accepts raw data, not .au format. > > Try setting the environment variable AUDIODEV to /dev/audio > before running the test script. Does that work any better? That's the ticket. "play" and the test now sound identical, modulo some pops & cracks at the start and end of the test. I presume what follows is thus a good idea? Index: test_linuxaudiodev.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/test/test_linuxaudiodev.py,v retrieving revision 1.1 diff -u -r1.1 test_linuxaudiodev.py --- test_linuxaudiodev.py 2000/06/10 04:22:57 1.1 +++ test_linuxaudiodev.py 2000/06/29 23:32:55 @@ -17,4 +17,6 @@ def test(): play_sound_file(findfile('audiotest.au')) +os.environ["AUDIODEV"] = "/dev/audio" + test() Cheers, M. From Vladimir.Marangozov@inrialpes.fr Fri Jun 30 00:38:19 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Fri, 30 Jun 2000 01:38:19 +0200 (CEST) Subject: [Python-Dev] New PythonLabs site revealed! In-Reply-To: <200006292325.SAA19744@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Jun 29, 2000 06:25:09 PM Message-ID: <200006292338.BAA07798@python.inrialpes.fr> Guido van Rossum wrote: > > Today, without much fanfare, we opened the new PythonLabs website. > The design is by BeOpen's creative Director, Jun Simmons. Thanks to > Jeremy Hylton, who did most of the actual HTML editing to get our > contents in place. > > The new beta will be released via this site. > > And since you python-dev folks will find this out through my checkins > anyway, let this be an advance warning that it will be called Python > 2.0. Here's my explanation for the version bump (soon to be checked > in to README): Guido van Rossum just won't stop surprising us! :-) Witness the three shocking news that arrived in one day: (1) very strict self-discipline about "long-term" TODO's full of short-term and less than medium-term topics that were very logically left behind, (2) major version number revision one day before the official beta-cycle, (3) a new PythonLabs corporate-style Web site with a flashing color palette & tutti quanti. I am really (positively) amazed! :-) spanish-inquisition-is-all-we-deserve--ly y'rs -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From fdrake@beopen.com Fri Jun 30 00:39:48 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 29 Jun 2000 19:39:48 -0400 (EDT) Subject: [Python-Dev] documentation patch guidelines Message-ID: <14683.56900.433607.125111@cj42289-a.reston1.va.home.com> I've updated the patch guidelines for documentation to match other patches, and added a patch category for documentation. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From pingster@ilm.com Fri Jun 30 00:46:32 2000 From: pingster@ilm.com (Ka-Ping Yee) Date: Thu, 29 Jun 2000 16:46:32 -0700 (PDT) Subject: [Python-Dev] Test results of linuxaudiodev.c In-Reply-To: Message-ID: On Thu, 29 Jun 2000, Ka-Ping Yee wrote: > Try setting the environment variable AUDIODEV to /dev/audio > before running the test script. Does that work any better? Even if that works, i realize that's not the way the interface was intended to be used. To play an AU file, the routine should look something like this (not tested, as i don't have a working Linux box)... def play_au_file(path): fp = open(path, "r") # Read the .au file header. header = fp.read(24) hdrsize, length, encoding, rate, channels = \ struct.unpack(">xxxxiiiii", header) fp.read(hdrsize - 24) data = fp.read() fp.close() # Set the data format according to the code in the .au header. if encoding == 1: size, fmt = 8, linuxaudiodev.AFMT_MU_LAW elif encoding == 2: size, fmt = 8, linuxaudiodev.AFMT_S8 elif encoding == 3: size, fmt = 16, linuxaudiodev.AFMT_S16_BE else: raise "audio format not supported" dsp = linuxaudiodev.open("w") dsp.setparameters(rate, size, channels, fmt) dsp.write(data) dsp.close() -- ?!ng Explicit hoc totum; This completes the whole; Pro Christo da mihi potum. For Christ's sake give me a drink. -- from the colophon of a 12th-century copyist From nascheme@enme.ucalgary.ca Fri Jun 30 01:00:37 2000 From: nascheme@enme.ucalgary.ca (Neil Schemenauer) Date: Thu, 29 Jun 2000 18:00:37 -0600 Subject: [Python-Dev] Mysterious SF message... In-Reply-To: <14683.52250.789900.357275@beluga.mojam.com>; from skip@mojam.com on Thu, Jun 29, 2000 at 05:22:18PM -0500 References: <14683.52250.789900.357275@beluga.mojam.com> Message-ID: <20000629180037.A22566@acs.ucalgary.ca> On Thu, Jun 29, 2000 at 05:22:18PM -0500, Skip Montanaro wrote: > > I just submitted a patch for lib/libatexit.tex. In the response page it > displayed a list of patches, then the following cryptic message: > > Patch Uploaded Successfully Added Patch Could Not Send Patch Update > > Any idea what that means? SourceForge sucks? Seriously though, I think it means: Patch Uploaded Successfully, Added Patch, Could Not Send Patch Update For some reason it couldn't email out the patch update URL. Neil From mwh21@cam.ac.uk Fri Jun 30 01:06:04 2000 From: mwh21@cam.ac.uk (Michael Hudson) Date: 30 Jun 2000 01:06:04 +0100 Subject: [Python-Dev] Test results of linuxaudiodev.c In-Reply-To: Ka-Ping Yee's message of "Thu, 29 Jun 2000 16:46:32 -0700 (PDT)" References: Message-ID: Ka-Ping Yee writes: > On Thu, 29 Jun 2000, Ka-Ping Yee wrote: > > Try setting the environment variable AUDIODEV to /dev/audio > > before running the test script. Does that work any better? > > Even if that works, i realize that's not the way the interface > was intended to be used. To play an AU file, the routine should > look something like this (not tested, as i don't have a working > Linux box)... [snip] Yup, that works fine. Don't understand the details - and as I have my graduation ceremony tomorrow I'm going to go to bed and leave learning them until some other occasion! Cheers, M. PS: my Lib/test/test_linuxaudiodev.py is now this: from test_support import verbose, findfile, TestFailed import linuxaudiodev import os,struct def play_au_file(path): fp = open(path, "r") # Read the .au file header. header = fp.read(24) hdrsize, length, encoding, rate, channels = \ struct.unpack(">xxxxiiiii", header) fp.read(hdrsize - 24) data = fp.read() fp.close() # Set the data format according to the code in the .au header. if encoding == 1: size, fmt = 8, linuxaudiodev.AFMT_MU_LAW elif encoding == 2: size, fmt = 8, linuxaudiodev.AFMT_S8 elif encoding == 3: size, fmt = 16, linuxaudiodev.AFMT_S16_BE else: raise "audio format not supported" dsp = linuxaudiodev.open("w") dsp.setparameters(rate, size, channels, fmt) dsp.write(data) dsp.close() def test(): play_au_file(findfile('audiotest.au')) test() ... which is an improvement on what's there now. From pingster@ilm.com Fri Jun 30 01:44:35 2000 From: pingster@ilm.com (Ka-Ping Yee) Date: Thu, 29 Jun 2000 17:44:35 -0700 (PDT) Subject: [Python-Dev] Test results of linuxaudiodev.c In-Reply-To: Message-ID: On 30 Jun 2000, Michael Hudson wrote: > Yup, that works fine. Don't understand the details - and as I have my > graduation ceremony tomorrow I'm going to go to bed and leave learning > them until some other occasion! Cool. Okay, i just discovered sunau.py. Here's my real shot at test_linuxaudiodev.py. Can you give this a try? ---- test_linuxaudiodev.py ---- from test_support import verbose, findfile, TestFailed import linuxaudiodev import os, sunau formats = {("ULAW", 1): linuxaudiodev.AFMT_MU_LAW, ("NONE", 1): linuxaudiodev.AFMT_S8, ("NONE", 2): linuxaudiodev.AFMT_S16_BE} def play_au_file(path): au = sunau.open(path, "r") data = au.readframes(sunau.AUDIO_UNKNOWN_SIZE) au.close() spec = (au.getcomptype(), au.getsampwidth()) if not has_key(formats, spec): raise "audio format not supported by linuxaudiodev" dsp = linuxaudiodev.open("w") dsp.setparameters(au.getframerate(), au.getsampwidth() * 8, au.getnchannels(), formats[spec]) dsp.write(data) dsp.close() def test(): play_au_file(findfile('audiotest.au')) test() ---- test_linuxaudiodev.py ---- -- ?!ng From gstein@lyra.org Fri Jun 30 02:03:11 2000 From: gstein@lyra.org (Greg Stein) Date: Thu, 29 Jun 2000 18:03:11 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib sre.py,1.9,1.10 sre_compile.py,1.7,1.8 sre_constants.py,1.7,1.8 sre_parse.py,1.7,1.8 In-Reply-To: <200006291238.FAA01061@slayer.i.sourceforge.net>; from effbot@users.sourceforge.net on Thu, Jun 29, 2000 at 05:38:48AM -0700 References: <200006291238.FAA01061@slayer.i.sourceforge.net> Message-ID: <20000629180311.I29590@lyra.org> Fredrik, Something you are doing is forcing CVS to issue a new revision for some of those files, even when you are not changing them. These "false" revisions are probably not a good thing. Could you review your checkin process to see what is up? I would guess that you have the "-f" option in your commit line. Cheers, -g On Thu, Jun 29, 2000 at 05:38:48AM -0700, Fredrik Lundh wrote: > Update of /cvsroot/python/python/dist/src/Lib > In directory slayer.i.sourceforge.net:/tmp/cvs-serv899/Lib > > Modified Files: > sre.py sre_compile.py sre_constants.py sre_parse.py > Log Message: > > > - make sure group names are valid identifiers > (closes the "SRE: symbolic reference" bug) > > Index: sre.py > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Lib/sre.py,v > retrieving revision 1.9 > retrieving revision 1.10 > diff -C2 -r1.9 -r1.10 > > Index: sre_compile.py > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Lib/sre_compile.py,v > retrieving revision 1.7 > retrieving revision 1.8 > diff -C2 -r1.7 -r1.8 > > Index: sre_constants.py > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Lib/sre_constants.py,v > retrieving revision 1.7 > retrieving revision 1.8 > diff -C2 -r1.7 -r1.8 > > Index: sre_parse.py > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Lib/sre_parse.py,v > retrieving revision 1.7 > retrieving revision 1.8 > diff -C2 -r1.7 -r1.8 > *** sre_parse.py 2000/06/29 11:34:27 1.7 > --- sre_parse.py 2000/06/29 12:38:45 1.8 > *************** > *** 169,172 **** > --- 169,190 ---- > return this > > + def isident(char): > + return "a" <= char <= "z" or "A" <= char <= "Z" or char == "_" > + > + def isdigit(char): > + return "0" <= char <= "9" > + > + def isname(name): > + # check that group name is a valid string > + # FIXME: this code is really lame. should use a regular > + # expression instead, but I seem to have certain bootstrapping > + # problems here ;-) > + if not isident(name[0]): > + return 0 > + for char in name: > + if not isident(char) and not isdigit(char): > + return 0 > + return 1 > + > def _group(escape, state): > # check if the escape string represents a valid group > *************** > *** 419,425 **** > if char == ">": > break > - # FIXME: check for valid character > name = name + char > group = 1 > elif source.match("="): > # named backreference > --- 437,444 ---- > if char == ">": > break > name = name + char > group = 1 > + if not isname(name): > + raise error, "illegal character in group name" > elif source.match("="): > # named backreference > *************** > *** 523,540 **** > char = s.get() > if char is None: > ! raise error, "unterminated index" > if char == ">": > break > - # FIXME: check for valid character > name = name + char > if not name: > ! raise error, "bad index" > try: > index = int(name) > except ValueError: > try: > index = pattern.groupindex[name] > except KeyError: > ! raise IndexError, "unknown index" > a((MARK, index)) > elif len(this) > 1 and this[1] in DIGITS: > --- 542,560 ---- > char = s.get() > if char is None: > ! raise error, "unterminated group name" > if char == ">": > break > name = name + char > if not name: > ! raise error, "bad group name" > try: > index = int(name) > except ValueError: > + if not isname(name): > + raise error, "illegal character in group name" > try: > index = pattern.groupindex[name] > except KeyError: > ! raise IndexError, "unknown group name" > a((MARK, index)) > elif len(this) > 1 and this[1] in DIGITS: > > > _______________________________________________ > Python-checkins mailing list > Python-checkins@python.org > http://www.python.org/mailman/listinfo/python-checkins -- Greg Stein, http://www.lyra.org/ From akuchlin@mems-exchange.org Fri Jun 30 02:29:41 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Thu, 29 Jun 2000 21:29:41 -0400 Subject: [Python-Dev] Removing modules Message-ID: <20000629212941.A21563@newcnri.cnri.reston.va.us> For the "deleted modules" section of the 2.0 article, I drew up a list of modules that might be outdated, mostly the SGI-specific ones. Are those modules still useful, and do the libraries they were written for still exist? For your cogitation, here's the list: sgimodule.c, glmodule.c (and hence cgenmodule.c), imgfile.c, svmodule.c, flmodule.c, fmmodule.c, almodule.c, clmodule.c, knee.py. Also, can someone explain why importing a third party extension built for Python 1.5.x is supposed to result in an immediate crash on Windows? I'd like to explain why this happens... --amk From guido@python.org Fri Jun 30 04:13:13 2000 From: guido@python.org (Guido van Rossum) Date: Thu, 29 Jun 2000 22:13:13 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib sre.py,1.9,1.10 sre_compile.py,1.7,1.8 sre_constants.py,1.7,1.8 sre_parse.py,1.7,1.8 In-Reply-To: Your message of "Thu, 29 Jun 2000 18:03:11 MST." <20000629180311.I29590@lyra.org> References: <200006291238.FAA01061@slayer.i.sourceforge.net> <20000629180311.I29590@lyra.org> Message-ID: <200006300313.WAA22134@cj20424-a.reston1.va.home.com> > Fredrik, > > Something you are doing is forcing CVS to issue a new revision for some of > those files, even when you are not changing them. These "false" revisions > are probably not a good thing. > > Could you review your checkin process to see what is up? I would guess that > you have the "-f" option in your commit line. > > Cheers, > -g Greg, we already know why this is. It's the $ID$. --Guido van Rossum (home page: http://www.python.org/~guido/) From mhammond@skippinet.com.au Fri Jun 30 03:49:06 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Fri, 30 Jun 2000 12:49:06 +1000 Subject: [Python-Dev] Removing modules In-Reply-To: <20000629212941.A21563@newcnri.cnri.reston.va.us> Message-ID: > Also, can someone explain why importing a third party extension built > for Python 1.5.x is supposed to result in an immediate crash on > Windows? I'd like to explain why this happens... The 1.5 module is linked against Python15.dll. When Python.exe (linked against Python16.dll) starts up, it initializes the Python data structures in Python16.dll. When Python then imports foo.pyd (linked against Python15.dll), it immediately tries to call the functions in that DLL (such as getting the thread state). As Python has not been initialized in that DLL, we immediately die. Ironically, if Python1x.dll was simply named "Python.dll", there is a _reasonable_ chance it would work fine. The cost of doing this tho, is that you can not have Python 1.5 and Python 1.6 "side by side" on the same machine. There are a few possibilities for magic tricks we could pull, but to be honest Im not too inclined to bother with them myself... They would also require a commitment to a fully backwards compatible C API, which I dont think we can afford to commit to! Mark. From gward@python.net Fri Jun 30 04:30:03 2000 From: gward@python.net (Greg Ward) Date: Thu, 29 Jun 2000 23:30:03 -0400 Subject: [Python-Dev] Hey! who changed sys.platform?! Message-ID: <20000629233003.A1766@beelzebub> Curses! I just noticed that sys.platform in 1.6a2 (and the latest CVS from this morning) returns "linux2" on my PC, not "linux-i386". As I recall this decision is made in the configure script. Does anyone know why it changed? This is not the end of the world, but the OS name alone is not really enough on a multi-architecture OS... ...back to calling os.uname() myself, I guess. ;-( Greg -- Greg Ward - programmer-at-big gward@python.net http://starship.python.net/~gward/ God made machine language; all the rest is the work of man. From fdrake@beopen.com Fri Jun 30 04:33:45 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Thu, 29 Jun 2000 23:33:45 -0400 (EDT) Subject: [Python-Dev] Hey! who changed sys.platform?! In-Reply-To: <20000629233003.A1766@beelzebub> References: <20000629233003.A1766@beelzebub> Message-ID: <14684.5401.518766.362678@cj42289-a.reston1.va.home.com> Greg Ward writes: > I just noticed that sys.platform in 1.6a2 (and the latest CVS from this > morning) returns "linux2" on my PC, not "linux-i386". As I recall this I didn't know it ever returned linux-i386; perhaps you're thinking of Marc-Andre's platform module? -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From trentm@activestate.com Fri Jun 30 04:34:17 2000 From: trentm@activestate.com (Trent Mick) Date: Thu, 29 Jun 2000 20:34:17 -0700 Subject: [Python-Dev] Controversial patch (cmath) In-Reply-To: References: Message-ID: <20000629203417.B23077@activestate.com> [Tim discusses god awful math details] Would you want to foward this to python-list to see if any lurking mathematicians might be spurred to action? Trent -- Trent Mick trentm@activestate.com From gward@python.net Fri Jun 30 04:53:34 2000 From: gward@python.net (Greg Ward) Date: Thu, 29 Jun 2000 23:53:34 -0400 Subject: [Python-Dev] Hey! who changed sys.platform?! In-Reply-To: <14684.5401.518766.362678@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Thu, Jun 29, 2000 at 11:33:45PM -0400 References: <20000629233003.A1766@beelzebub> <14684.5401.518766.362678@cj42289-a.reston1.va.home.com> Message-ID: <20000629235334.B1294@beelzebub> On 29 June 2000, Fred L. Drake, Jr. said: > I didn't know it ever returned linux-i386; perhaps you're thinking > of Marc-Andre's platform module? D'ohh! That appears to be an artifact of Red Hat's build -- I was using /usr/bin/python (theirs), not /usr/local/bin/python (mine). $ /usr/bin/python Python 1.5.2 (#1, Feb 1 2000, 16:32:16) [GCC egcs-2.91.66 19990314/Linux (egcs- on linux-i386 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> sys.platform 'linux-i386' Sorry for getting alarmist. Guess I never should have started using sys.platform in the first place (or just not worry about getting the CPU in there too). Greg -- Greg Ward - geek gward@python.net http://starship.python.net/~gward/ Support bacteria -- it's the only culture some people have! From skip@mojam.com (Skip Montanaro) Fri Jun 30 03:57:47 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Thu, 29 Jun 2000 21:57:47 -0500 (CDT) Subject: [Python-Dev] available to look at bugs and patches... Message-ID: <14684.3243.480545.880199@beluga.mojam.com> Barry added me as a developer yesterday. Those people assigning bugs and patches can use me as a resource... Skip From gward@python.net Fri Jun 30 05:26:20 2000 From: gward@python.net (Greg Ward) Date: Fri, 30 Jun 2000 00:26:20 -0400 Subject: [Python-Dev] ANNOUNCE: Distutils 0.9 Message-ID: <20000630002620.A2329@beelzebub> Python Distribution Utilities release 0.9 June 29, 2000 The Python Distribution Utilities, or Distutils for short, are a collection of modules that aid in the development, distribution, and installation of Python modules. (It is intended that ultimately the Distutils will grow up into a system for distributing and installing whole Python applications, but for now their scope is limited to module distributions.) The Distutils are a standard part of Python 2.0; if you are running 2.0 (or one of the 1.6 alpha releases that preceded it), you don't need to install the Distutils separately. This release is primarily so that you can add the Distutils to a Python 1.5.2 installation -- you will then be able to install modules that require the Distutils, or use the Distutils to distribute your own modules. More information is available at the Distutils web page: http://www.python.org/sigs/distutils-sig/ and in the README.txt included in the Distutils source distribution. You can download the Distutils from http://www.python.org/sigs/distutils-sig/download.html Trivial patches can be sent to me (Greg Ward) at gward@python.net. Larger patches should be discussed on the Distutils mailing list: distutils-sig@python.org. From tpeters@beopen.com Fri Jun 30 06:05:32 2000 From: tpeters@beopen.com (Tim Peters) Date: Fri, 30 Jun 2000 01:05:32 -0400 Subject: [Python-Dev] Controversial patch (cmath) In-Reply-To: <20000629203417.B23077@activestate.com> Message-ID: [Trent Mick] > [Tim discusses god awful math details] > Would you want to foward this to python-list to see if any lurking > mathematicians might be spurred to action? God, please no! This requires a numerical analyst, not a mathematician. Voting by talented amateurs is only going to make things worse <0.5 wink>. I was an NA in a previous life, and know what needs to be done to resolve all this. But that takes way more time than we have before 2.0b1. The patch in question makes life better for the world's only known user of cmath . may-as-well-ask-c.l.py-to-discuss-python's-version-number-ly y'rs - tim From jeremy@beopen.com Fri Jun 30 06:08:30 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Fri, 30 Jun 2000 01:08:30 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Include objimpl.h,2.16,2.17 In-Reply-To: <200006300502.WAA03256@slayer.i.sourceforge.net> References: <200006300502.WAA03256@slayer.i.sourceforge.net> Message-ID: <14684.11086.47325.776691@bitdiddle.concentric.net> These patches should catch up with Neil's latest submissions, but may not have the very latest changes suggested by Neil and Vladimir. I will double-check with them in the morning. I will also change configure.in to enable GC by default for the beta test phase, unless there is strong objection. Jeremy From skip@mojam.com (Skip Montanaro) Fri Jun 30 05:00:29 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Thu, 29 Jun 2000 23:00:29 -0500 (CDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test/output test_gc,NONE,1.1 In-Reply-To: <200006300502.WAA03286@slayer.i.sourceforge.net> References: <200006300502.WAA03286@slayer.i.sourceforge.net> Message-ID: <14684.7005.661874.713000@beluga.mojam.com> Jeremy> Log Message: Jeremy> final patches from Neil Schemenauer for garbage collection Jeremy> --- NEW FILE --- Jeremy> test_gc Jeremy> list 0x831a754 Jeremy> dict 0x831a754 ... Jeremy> dict 0x831a9bc Jeremy> func 0x831d9e4 I can all but guarantee you this test will always fail. Printing absolute machine addresses (via calls to id() in this case) in test cases should be verboten. -- Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille O'Neal said: "He's got the rings. I listen to the man with the rings." From trentm@activestate.com Fri Jun 30 07:05:50 2000 From: trentm@activestate.com (Trent Mick) Date: Thu, 29 Jun 2000 23:05:50 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/PCbuild python16.dsp,1.6,1.7 In-Reply-To: <200006300502.WAA03275@slayer.i.sourceforge.net> References: <200006300502.WAA03275@slayer.i.sourceforge.net> Message-ID: <20000629230550.A24811@activestate.com> On Thu, Jun 29, 2000 at 10:02:55PM -0700, Jeremy Hylton wrote: > Update of /cvsroot/python/python/dist/src/PCbuild > In directory slayer.i.sourceforge.net:/tmp/cvs-serv3220/PCbuild > > Modified Files: > python16.dsp > Log Message: > final patches from Neil Schemenauer for garbage collection > > > Index: python16.dsp > =================================================================== > RCS file: /cvsroot/python/python/dist/src/PCbuild/python16.dsp,v > retrieving revision 1.6 > retrieving revision 1.7 > diff -C2 -r1.6 -r1.7 > *** python16.dsp 2000/06/06 23:29:09 1.6 > --- python16.dsp 2000/06/30 05:02:53 1.7 > *************** > *** 660,663 **** > --- 660,677 ---- > # End Source File > # Begin Source File > + SOURCE=..\Modules\gcmodule.c > + > + !IF "$(CFG)" == "python16 - Win32 Release" > + > + !ELSEIF "$(CFG)" == "python16 - Win32 Debug" > + > + !ELSEIF "$(CFG)" == "python16 - Win32 Alpha Debug" > + > + !ELSEIF "$(CFG)" == "python16 - Win32 Alpha Release" > + > + !ENDIF > + > + # End Source File > + # Begin Source File > > SOURCE=..\Python\getargs.c > Pardon me if I am wrong (I have not actually checked the repository) but is this correct now that the version number is 2.0? Trent -- Trent Mick trentm@activestate.com From trentm@activestate.com Fri Jun 30 07:27:33 2000 From: trentm@activestate.com (Trent Mick) Date: Thu, 29 Jun 2000 23:27:33 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test README,NONE,1.1 In-Reply-To: <200006300608.XAA13124@slayer.i.sourceforge.net> References: <200006300608.XAA13124@slayer.i.sourceforge.net> Message-ID: <20000629232733.D24811@activestate.com> Cool On Thu, Jun 29, 2000 at 11:08:38PM -0700, Skip Montanaro wrote: > > --- NEW FILE --- > Writing Python Test Cases > ------------------------- > Skip Montanaro > > > To run the entire test suite, make the "test" target at the top level: > > cd ... > make test This is a UN*Xism, on Windows and UN*X: cd ...\Lib\test python regrtest.py A sample walk through to create a test might make it more approachable for people. As well, it would be helpful to mention test_support.{verbose|TESTFN|...}. But I have no right to bitch about good work. Trent -- Trent Mick trentm@activestate.com From tpeters@beopen.com Fri Jun 30 07:39:15 2000 From: tpeters@beopen.com (Tim Peters) Date: Fri, 30 Jun 2000 02:39:15 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test README,NONE,1.1 In-Reply-To: <20000629232733.D24811@activestate.com> Message-ID: [Trent Mick] > ... > But I have no right to bitch about good work. How do you figure that? We do it to you enough . BTW, I'd just like to say what a delight it is to work with *all* of you folks! I wanted to say that before I can be accused of pimping for my employer -- so far, BeOpen hasn't paid me a dime, so you know my opinion hasn't yet been bought. well-maybe-on-credit-ly y'rs - tim From tpeters@beopen.com Fri Jun 30 07:39:12 2000 From: tpeters@beopen.com (Tim Peters) Date: Fri, 30 Jun 2000 02:39:12 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/PCbuild python16.dsp,1.6,1.7 In-Reply-To: <20000629230550.A24811@activestate.com> Message-ID: [Trent Mick, on Guido's late-night (for him ) checkin of python16.dsp] > Pardon me if I am wrong (I have not actually checked the > repository) but is this correct now that the version number is 2.0? No, it is not, and the Windows build is slightly damaged now. I've already yelled at Guido about this, but I suspect he's asleep. I'm sure it will get sorted out in the morning. From trentm@activestate.com Fri Jun 30 07:52:47 2000 From: trentm@activestate.com (Trent Mick) Date: Thu, 29 Jun 2000 23:52:47 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test README,NONE,1.1 In-Reply-To: References: <20000629232733.D24811@activestate.com> Message-ID: <20000629235247.A25090@activestate.com> On Fri, Jun 30, 2000 at 02:39:15AM -0400, Tim Peters wrote: > BTW, I'd just like to say what a delight it is to work with *all* of you > folks! I feel a group hug coming on in the morning. Or maybe I am just moved by the beer that I had for dinner. :) Likewise, Tim. As my first foray into community development I find this, Python dev, a refreshing pleasure. Trent -- Trent Mick trentm@activestate.com From tpeters@beopen.com Fri Jun 30 08:41:28 2000 From: tpeters@beopen.com (Tim Peters) Date: Fri, 30 Jun 2000 03:41:28 -0400 Subject: [Python-Dev] Wikis for todo lists, etc (was PyString_GET_SIZE()) In-Reply-To: Message-ID: [Tim] > ... "Group whiteboards" and shared journals etc are darned > useful, though. [Ken Manheimer] > Wiki = Group whiteboard Ya, I kind of picked that up from your last passionate advertisement for this stuff . Not knocking it! Never tried it. Believe it or not, I spend as little time on the web as possible. After I've gotten into a place to live here, and this current release crunch is behind us, I'm definitely going to check out your leads. For the past several years my development group worked thru Lotus Notes, which I didn't much care for at the time, but I'm increasingly realizing just how essential group-modifiable shared persistent documents were to our productivity. Notes is the purest example of a whole being greater than the sum of its parts I've ever seen (lousy mail system, lousy database, lousy change manager, lousy bug tracker, lousy workflow manager, worse than lousy native scripting ... but they all sucked in ways that were downright synergistic <0.9 wink>). > ... > Anyway, to see leads on both zwikis and tracker, see: > > http://www.zope.org/Members/klm/TrackerWiki can-beopen-zwiki-2.0-be-far-behind?-ly y'rs - tim From pingster@ilm.com Fri Jun 30 09:21:08 2000 From: pingster@ilm.com (Ka-Ping Yee) Date: Fri, 30 Jun 2000 01:21:08 -0700 (PDT) Subject: [Python-Dev] New PythonLabs site revealed! In-Reply-To: <200006292338.BAA07798@python.inrialpes.fr> Message-ID: Guido van Rossum wrote: > let this be an advance warning that it will be called Python 2.0. On Fri, 30 Jun 2000, Vladimir Marangozov wrote: > Guido van Rossum just won't stop surprising us! :-) Will many be spooked by the jump in version number into fearing incompatibility with older scripts...? I wonder if we'll end up trying to persuade the user community that the changes are small ("no, don't worry, your scripts will still work") and yet big ("honest, it really deserves to be called 2.0, it's not just a ploy") at the same time. Perl 5 was basically incompatible with Perl 4. Some things run, but a lot don't. (Actually many microversions of Perl 5 were mutually incompatible with each other, but i'll ignore that. :) ) I've thought of the jump to Python3k (lowercase "k", please) much like the Perl-4-to-Perl-5 jump: simple stuff is still okay but a lot of guts have changed. If i hadn't been "on the inside" watching development activity, i might expect something of similar magnitude upon hearing of going from Python 1.x to 2.0. I guess we can point at Unicode and SRE as big things. -- ?!ng From Fredrik Lundh" just checked in a test script for sre. the test_sre file is a copy of test_re, with some minor changes: -- disabled one test (caused by bug #8; see below) -- added T (template mode, experimental, unsupported) and U (unicode locale) flags to the flag test -- removed keyword arguments in pattern test loop: result =3D obj.search(s, pos=3Dresult.start(0), = endpos=3Dresult.end(0)+1) was changed to: result =3D obj.search(s, result.start(0), result.end(0)+1) as far as I can tell, the docs don't mention anything about keyword arguments... -- added unicode pattern / target string / locale tests to the pattern test loop. however, the current version SRE doesn't fully pass the test. here's an annotated version of Lib/test/output/test_sre: 1) test_support -- test failed re module pickle 2) test_support -- test failed re module cPickle under SRE, patterns are C objects, not class instances. to allow pickling, I need to modify copy_reg (either by modifing the file itself, or by updating the registry when SRE is first imported). see patch #100650 for more info, 3) =3D=3D=3D Syntax error: ('(?Pa)(?P=3Dfoo_123)', 'aa', 0, = 'g1', 'a') this is a bug in the SRE parser. should be easy to fix. 4) =3D=3D=3D Failed incorrectly ('^(.+)?B', 'AB', 0, 'g1', 'A') this is a bug in the engine (nested repetitions). needs further research. 5) =3D=3D=3D Failed incorrectly ('(a+)+\\1', 'aa', 0, 'found+"-"+g1', = 'aa-a') this is a bug in the engine or in the parser. needs further research. 6) =3D=3D=3D grouping error ('([^/]*/)*sub1/', = 'd:msgs/tdir/sub1/trial/away.cpp', 0, 'found+"-"+g1', = 'd:msgs/tdir/sub1/-tdir/') 'd:msgs/tdir/sub1/-trial/' should be = 'd:msgs/tdir/sub1/-tdir/' same as #5. 7) =3D=3D=3D Syntax error: ('(?Paa)(?P=3Did)', 'aaaa', 0, = 'found+"-"+id', 'aaaa-aa') same as #3. 8) =3D=3D=3D grouping error ('([abc])*bcd', 'abcd', 0, 'found+"-"+g1', = 'abcd-a') 'abcd-c' should be 'abcd-a' this is a bug in the engine. should be easy to fix, I think. in fact, I could have sworn that I'd fixed it already. 9) =3D=3D=3D grouping error ('(?i)([abc])*bcd', 'ABCD', 0, = 'found+"-"+g1', 'ABCD-A') 'ABCD-C' should be 'ABCD-A' same as #8 10) =3D=3D=3D Syntax error: ('a(?!b).', 'abad', 0, 'found', 'ad') this is bug in the parser. should be easy to fix. 11) =3D=3D=3D Syntax error: ('a(?=3Dd).', 'abad', 0, 'found', 'ad') same as (or at least related to) #10 12) =3D=3D=3D Syntax error: ('a(?=3Dc|d).', 'abad', 0, 'found', 'ad') same as #11 13) =3D=3D=3D Failed incorrectly ('^(.+)?B', 'AB', 0, 'g1', 'A') same as #4 (literally!). ... fwiw, *all* RE-based code I've played with seem to work. ymmv. let me know asap if it does. From mhammond@skippinet.com.au Fri Jun 30 09:41:44 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Fri, 30 Jun 2000 18:41:44 +1000 Subject: [Python-Dev] New PythonLabs site revealed! In-Reply-To: Message-ID: > Will many be spooked by the jump in version number into fearing > incompatibility with older scripts...? > > I wonder if we'll end up trying to persuade the user community that > the changes are small ("no, don't worry, your scripts will still > work") and yet big ("honest, it really deserves to be called 2.0, > it's not just a ploy") at the same time. I see your concerns, but I think the trick is to be honest, just as Guido was. We simply say it was bumped to V2 for the reasons of percieved maturity, and a clear break from CNRI Python. Both seem reasonable. I believe many people will simply wait for some form of consensus on the newsgroup, regardless of the version number. Personally, Im a little - umm - lets just say that I can see the irony in the fact that I recently changed a few bits of code that were dependent on a hard-coded "Python15.dll" to work not only with 1.6, but _all_ of the 1.x family. I figured there was no point trying to predict the packaging details of the 2.x family, seeing it as still some time off. Nothing like foresight :-) And-"foresight"-isnt-an-excuse-for-Tim-to-get-back-on-the-topic-of-his-geni tals--ly, Mark. From Fredrik Lundh" Message-ID: <005801bfe270$e140d440$f2a6b5d4@hagrid> mark wrote: > Personally, Im a little - umm - lets just say that I can see the irony = in > the fact that I recently changed a few bits of code that were = dependent on > a hard-coded "Python15.dll" to work not only with 1.6, but _all_ of = the 1.x > family. heh. you're not the only one... btw, now that we're bumping to 2.0, maybe we can break socket.connect and friends once again? if somebody com- plains, just tell them "it's a major release, dammit" ;-) From gstein@lyra.org Fri Jun 30 09:59:56 2000 From: gstein@lyra.org (Greg Stein) Date: Fri, 30 Jun 2000 01:59:56 -0700 Subject: [Python-Dev] CVS locks on SF In-Reply-To: <200006291905.OAA17265@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jun 29, 2000 at 02:05:11PM -0500 References: <200006291905.OAA17265@cj20424-a.reston1.va.home.com> Message-ID: <20000630015956.S29590@lyra.org> On Thu, Jun 29, 2000 at 02:05:11PM -0500, Guido van Rossum wrote: >... > > Note that Perl is maintained under (the commercial, alas) Perforce, which is > > one of the few SCMs to take multi-developer multi-directory issues > > seriously. > > We tried Perforce at CNRI. It's really neat, but somehow it was > lacking some stuff we were used to and we never converted. > > Note that Perforce is free for open source projects -- at least at the > time it was. (CNRI paid a license fee, but that was just an > expression of CNRI's reluctance against free software. :-) > > There's also bitkeeper. It stayed in beta so long that we gave up > (and they have a weird license) -- but it's out of beta since May 4: > see http://www.bitkeeper.com/. But there's no immediate download! > You must sign up and they send you instructions in the mail... And coming down the pipe (end of the year) is Subversion: http://subversion.tigris.org/ Cheers, -g -- Greg Stein, http://www.lyra.org/ From mhammond@skippinet.com.au Fri Jun 30 10:23:53 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Fri, 30 Jun 2000 19:23:53 +1000 Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/PCbuild readme.txt,1.5,1.6 In-Reply-To: <200006300904.CAA04151@slayer.i.sourceforge.net> Message-ID: > Making a tiny change to figure out what I'm going to screw up > by trying to use CVS under Windows at all ... Congratulations :-) Mark. From mhammond@skippinet.com.au Fri Jun 30 10:25:39 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Fri, 30 Jun 2000 19:25:39 +1000 Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/PCbuild readme.txt,1.5,1.6 In-Reply-To: Message-ID: > To: python-dev@python.org Damn damn damn - did it again. Sorry. [I wishing mailing-lists would agree on how they handle reply-to :-] Mark. From mal@lemburg.com Fri Jun 30 10:27:57 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 30 Jun 2000 11:27:57 +0200 Subject: [Python-Dev] Hey! who changed sys.platform?! References: <20000629233003.A1766@beelzebub> <14684.5401.518766.362678@cj42289-a.reston1.va.home.com> Message-ID: <395C681D.C3211F6@lemburg.com> "Fred L. Drake, Jr." wrote: > > Greg Ward writes: > > I just noticed that sys.platform in 1.6a2 (and the latest CVS from this > > morning) returns "linux2" on my PC, not "linux-i386". As I recall this > > I didn't know it ever returned linux-i386; perhaps you're thinking > of Marc-Andre's platform module? Python has returned 'linux2' on my machine ever since I moved to a 2.x kernel -- why should it return 'linux-i386' (without any indication of version) ? As Fred mentioned, you should probably use platform.py to access the information you have in mind. It supports loads of different architectures and has pretty much all the information you need for distutils warpped in nice APIs. Why not simply include it in distutils ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Fredrik Lundh" Message-ID: <00b001bfe27a$845f7880$f2a6b5d4@hagrid> MAL wrote: > out.write(header) > out =3D open(cFileName, "w") > ! out.write("#include "%s"\n" % headerFileName) > out.write(code) > perfHash.generate_graph(out) umm. I suppose you meant: > ! out.write('#include "%s"\n' % headerFileName) or possibly: > ! out.write("#include \"%s\"\n" % headerFileName) From mal@lemburg.com Fri Jun 30 11:15:23 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 30 Jun 2000 12:15:23 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Tools/perfecthash GenUCNHash.py,1.1,1.2 References: <200006300953.CAA14782@slayer.i.sourceforge.net> <00b001bfe27a$845f7880$f2a6b5d4@hagrid> Message-ID: <395C733B.4E2AFFA3@lemburg.com> Fredrik Lundh wrote: > > MAL wrote: > > out.write(header) > > out = open(cFileName, "w") > > ! out.write("#include "%s"\n" % headerFileName) > > out.write(code) > > perfHash.generate_graph(out) > > umm. I suppose you meant: > > > ! out.write('#include "%s"\n' % headerFileName) > > or possibly: > > > ! out.write("#include \"%s\"\n" % headerFileName) Oops, you're right. Thanks. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fdrake@beopen.com Fri Jun 30 14:20:23 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Fri, 30 Jun 2000 09:20:23 -0400 (EDT) Subject: [Python-Dev] Wikis for todo lists, etc (was PyString_GET_SIZE()) In-Reply-To: References: Message-ID: <14684.40599.135974.497497@cj42289-a.reston1.va.home.com> Tim Peters writes: > productivity. Notes is the purest example of a whole being greater than the > sum of its parts I've ever seen (lousy mail system, lousy database, lousy > change manager, lousy bug tracker, lousy workflow manager, worse than lousy > native scripting ... but they all sucked in ways that were downright > synergistic <0.9 wink>). I had to use Notes before working at CNRI, and wouldn't have described all those sucky components as "synergistic". ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake@beopen.com Fri Jun 30 14:26:15 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Fri, 30 Jun 2000 09:26:15 -0400 (EDT) Subject: [Python-Dev] New PythonLabs site revealed! In-Reply-To: References: <200006292338.BAA07798@python.inrialpes.fr> Message-ID: <14684.40951.644965.274278@cj42289-a.reston1.va.home.com> Ka-Ping Yee writes: > Will many be spooked by the jump in version number into fearing > incompatibility with older scripts...? > > I wonder if we'll end up trying to persuade the user community that > the changes are small ("no, don't worry, your scripts will still > work") and yet big ("honest, it really deserves to be called 2.0, > it's not just a ploy") at the same time. Ping, Haven't we heard our users complain about the conservative version numbering a lot? Pushing to 2.0 allows us to make the next release 2.1, which neither the "never 1.x!" crowd nor the "never x.0!" will worry about. Sounds like a good move to me! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake@beopen.com Fri Jun 30 14:28:15 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Fri, 30 Jun 2000 09:28:15 -0400 (EDT) Subject: [Python-Dev] New PythonLabs site revealed! In-Reply-To: <005801bfe270$e140d440$f2a6b5d4@hagrid> References: <005801bfe270$e140d440$f2a6b5d4@hagrid> Message-ID: <14684.41071.958061.743836@cj42289-a.reston1.va.home.com> Fredrik Lundh writes: > btw, now that we're bumping to 2.0, maybe we can break > socket.connect and friends once again? if somebody com- > plains, just tell them "it's a major release, dammit" ;-) If by "break" you mean "tightly conform to the documentation", I'm all for it! ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake@beopen.com Fri Jun 30 14:32:24 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Fri, 30 Jun 2000 09:32:24 -0400 (EDT) Subject: [Python-Dev] Hey! who changed sys.platform?! In-Reply-To: <395C681D.C3211F6@lemburg.com> References: <20000629233003.A1766@beelzebub> <14684.5401.518766.362678@cj42289-a.reston1.va.home.com> <395C681D.C3211F6@lemburg.com> Message-ID: <14684.41320.38954.833643@cj42289-a.reston1.va.home.com> Regarding platform.py: M.-A. Lemburg writes: > Why not simply include it in distutils ? Why not include it in the standard library? Guido? I'll document it if Marc-Andre is willing to provide the module and the regression test. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From mal@lemburg.com Fri Jun 30 14:40:36 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 30 Jun 2000 15:40:36 +0200 Subject: [Python-Dev] Hey! who changed sys.platform?! References: <20000629233003.A1766@beelzebub> <14684.5401.518766.362678@cj42289-a.reston1.va.home.com> <395C681D.C3211F6@lemburg.com> <14684.41320.38954.833643@cj42289-a.reston1.va.home.com> Message-ID: <395CA354.16AC5B7E@lemburg.com> "Fred L. Drake, Jr." wrote: > > Regarding platform.py: > > M.-A. Lemburg writes: > > Why not simply include it in distutils ? > > Why not include it in the standard library? > Guido? I'll document it if Marc-Andre is willing to provide the > module and the regression test. No objection from here. I've attached my most recent copy to this mail. I'm not sure how to write the regr. test though since output is dependent on the platform running the functions... perhaps I'll just add something like the audio thingie: "This string ought to identify the platform you are currently running... if not, then something is wrong ;-)". -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From bwarsaw@beopen.com Fri Jun 30 14:42:19 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Fri, 30 Jun 2000 09:42:19 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules gcmodule.c,NONE,2.1 Setup.thread.in,2.2,2.3 cPickle.c,2.43,2.44 newmodule.c,2.20,2.21 References: <200006300502.WAA03262@slayer.i.sourceforge.net> Message-ID: <14684.41915.59835.325026@anthem.concentric.net> So, Setup.thread.in isn't used just for threads anymore. Perhaps it should be renamed? At the very least, a comment should be added to the top that this file is for configure enabled modules. -Barry Index: Setup.thread.in =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/Setup.thread.in,v retrieving revision 2.2 retrieving revision 2.3 diff -C2 -r2.2 -r2.3 *** Setup.thread.in 2000/06/29 16:08:28 2.2 --- Setup.thread.in 2000/06/30 05:02:53 2.3 *************** *** 11,12 **** --- 11,15 ---- @USE_THREAD_MODULE@thread threadmodule.c + + # Garbage collection enabled with --with-cycle-gc + @USE_GC_MODULE@gc gcmodule.c From mal@lemburg.com Fri Jun 30 14:42:06 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 30 Jun 2000 15:42:06 +0200 Subject: [Python-Dev] Hey! who changed sys.platform?! References: <20000629233003.A1766@beelzebub> <14684.5401.518766.362678@cj42289-a.reston1.va.home.com> <395C681D.C3211F6@lemburg.com> <14684.41320.38954.833643@cj42289-a.reston1.va.home.com> <395CA354.16AC5B7E@lemburg.com> Message-ID: <395CA3AE.8A5800F1@lemburg.com> This is a multi-part message in MIME format. --------------B32584A17EA1E930287FE86F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ooops, forgot the attachement... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ --------------B32584A17EA1E930287FE86F Content-Type: text/python; charset=iso-8859-1; name="platform.py" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="platform.py" #!/usr/local/bin/python """ This module tries to retrieve as much platform identifying data as possible. It makes this information available via function APIs. If called from the command line, it prints the platform information concatenated as single string to stdout. The output format is useable as part of a filename. Note that this module is a fast moving target. I plan to release version 1.0 as the final version. Still needed: · more support for WinCE · support for MS-DOS (PythonDX ?) · support for Amiga and other still unsupported platforms running Python · support for additional Linux distributions Many thanks to all those who helped adding platform specific checks (in no particular order): Charles G Waldman, David Arnold, Gordon McMillan, Ben Darnell, Jeff Bauer, Cliff Crawford, Ivan Van Laningham, Josef Betancourt, Randall Hopper, Karl Putland, John Farrell, Greg Andruk, Just van Rossum, Thomas Heller, Mark R. Levinson, Mark Hammond, Bill Tutt, Hans Nowak, Uwe Zessin (OpenVMS support), Colin Kong, Trent Mick History: 0.7.2 - fixed architecture() to use sizeof(pointer) where available 0.7.1 - added support for Caldera OpenLinux 0.7.0 - some fixes for WinCE; untabified the source file 0.6.2 - support for OpenVMS - requires version 1.5.2-V006 or higher and vms_lib.getsyi() configured 0.6.1 - added code to prevent 'uname -p' on platforms which are known not to support it 0.6.0 - fixed win32_ver() to hopefully work on Win95,98,NT and Win2k; did some cleanup of the interfaces - some APIs have changed 0.5.5 - fixed another type in the MacOS code... should have used more coffee today ;-) 0.5.4 - fixed a few typos in the MacOS code 0.5.3 - added experimental MacOS support; added better popen() workarounds in _syscmd_ver() -- still not 100% elegant though 0.5.2 - fixed uname() to return '' instead of 'unkown' in all return values (the system uname command tends to return 'unkown' instead of just leaving the field emtpy) 0.5.1 - included code for slackware dist; added exception handlers to cover up situations where platforms don't have os.popen (e.g. Mac) or fail on socket.gethostname(); fixed libc detection RE 0.5.0 - changed the API names referring to system commands to *syscmd*; added java_ver(); made syscmd_ver() a private API (was system_ver() in previous versions) -- use uname() instead; extended the win32_ver() to also return processor type information 0.4.0 - added win32_ver() and modified the platform() output for WinXX 0.3.4 - fixed a bug in _follow_symlinks() 0.3.3 - fixed popen() and "file" command invokation bugs 0.3.2 - added architecture() API and support for it in platform() 0.3.1 - fixed syscmd_ver() RE to support Windows NT 0.3.0 - added system alias support 0.2.3 - removed 'wince' again... oh well. 0.2.2 - added 'wince' to syscmd_ver() supported platforms 0.2.1 - added cache logic and changed the platform string format 0.2.0 - changed the API to use functions instead of module globals since some action take too long to be run on module import 0.1.0 - first release You can always get the latest version of this module at: http://starship.python.net/~lemburg/platform.py If that URL should fail, try contacting the author. ---------------------------------------------------------------------- (c) Copyright by Marc-Andre Lemburg (mailto:mal@lemburg.com) Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee or royalty is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation or portions thereof, including modifications, that you make. THE AUTHOR MARC-ANDRE LEMBURG DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE ! """ __version__ = '0.7.0' import sys,string,os,re ### Platform specific APIs def libc_ver(executable=sys.executable,lib='',version='', chunksize=2048, libc_search=re.compile('(__libc_init)' '|' '(GLIBC_([0-9.]+))' '|' '(libc(_\w+)?\.so(?:\.(\d[0-9.]*))?)' ) ): """ Tries to determine the libc version against which the file executable (defaults to the Python interpreter) is linked. Returns a tuple of strings (lib,version) which default to the given parameters in case the lookup fails. Note that the function has intimate knowledge of how different libc versions add symbols to the executable is probably only useable for executables compiled using gcc. The file is read and scanned in chunks of chunksize bytes. """ f = open(executable,'rb') binary = f.read(chunksize) pos = 0 while 1: m = libc_search.search(binary,pos) if not m: binary = f.read(chunksize) if not binary: break pos = 0 continue libcinit,glibc,glibcversion,so,threads,soversion = m.groups() if libcinit and not lib: lib = 'libc' elif glibc: if lib != 'glibc': lib = 'glibc' version = glibcversion elif glibcversion > version: version = glibcversion elif so: if lib != 'glibc': lib = 'libc' if soversion > version: version = soversion if threads and version[-len(threads):] != threads: version = version + threads pos = m.end() f.close() return lib,version def _dist_try_harder(distname,version,id): """ Tries some special tricks to get the distribution information in case the default method fails. Currently supports older SuSE Linux, Caldera OpenLinux and Slackware Linux distributions. """ if os.path.exists('/var/adm/inst-log/info'): # SuSE Linux stores distribution information in that file info = open('/var/adm/inst-log/info').readlines() distname = 'SuSE' for line in info: tv = string.split(line) if len(tv) == 2: tag,value = tv else: continue if tag == 'MIN_DIST_VERSION': version = string.strip(value) elif tag == 'DIST_IDENT': values = string.split(value,'-') id = values[2] return distname,version,id if os.path.exists('/etc/.installed'): # Caldera OpenLinux has some infos in that file (thanks to Colin Kong) info = open('/etc/.installed').readlines() for line in info: pkg = string.split(line,'-') if len(pkg) >= 2 and pkg[0] == 'OpenLinux': # XXX does Caldera support non Intel platforms ? If yes, # where can we find the needed id ? return 'OpenLinux',pkg[1],id if os.path.isdir('/usr/lib/setup'): # Check for slackware verson tag file (thanks to Greg Andruk) verfiles = os.listdir('/usr/lib/setup') for n in range(len(verfiles)-1, -1, -1): if verfiles[n][:14] != 'slack-version-': del verfiles[n] if verfiles: verfiles.sort() distname = 'slackware' version = verfiles[-1][14:] return distname,version,id return distname,version,id def dist(distname='',version='',id='', supported_dists=('SuSE','debian','redhat','mandrake'), release_filename=re.compile('(\w+)[-_](release|version)'), release_version=re.compile('([\d.]+)[^(]*(?:\((.+)\))?')): """ Tries to determine the name of the OS distribution name The function first looks for a distribution release file in /etc and then reverts to _dist_try_harder() in case no suitable files are found. Returns a tuple distname,version,id which default to the args given as parameters. """ try: etc = os.listdir('/etc') except os.error: # Probably not a Unix system return distname,version,id for file in etc: m = release_filename.match(file) if m: _distname,dummy = m.groups() if _distname in supported_dists: distname = _distname break else: return _dist_try_harder(distname,version,id) f = open('/etc/'+file,'r') firstline = f.readline() f.close() m = release_version.search(firstline) if m: _version,_id = m.groups() if _version: version = _version if _id: id = _id else: # Unkown format... take the first two words l = string.split(string.strip(firstline)) if l: version = l[0] if len(l) > 1: id = l[1] return distname,version,id class _popen: """ Fairly portable (alternative) popen implementation. This is mostly needed in case os.popen() is not available, or doesn't work as advertised, e.g. in Win9X GUI programs like PythonWin or IDLE. XXX Writing to the pipe is currently not supported. """ tmpfile = '' pipe = None bufsize = None mode = 'r' def __init__(self,cmd,mode='r',bufsize=None): if mode != 'r': raise ValueError,'popen()-emulation only support read mode' import tempfile self.tmpfile = tmpfile = tempfile.mktemp() os.system(cmd + ' > %s' % tmpfile) self.pipe = open(tmpfile,'rb') self.bufsize = bufsize self.mode = mode def read(self): return self.pipe.read() def readlines(self): if self.bufsize is not None: return self.pipe.readlines() def close(self, remove=os.unlink,error=os.error): if self.pipe: rc = self.pipe.close() else: rc = 255 if self.tmpfile: try: remove(self.tmpfile) except error: pass return rc # Alias __del__ = close def popen(cmd, mode='r', bufsize=None): """ Portable popen() interface. """ # Find a working popen implementation preferring win32pipe.popen # over os.popen over _popen popen = None if os.environ.get('OS','') == 'Windows_NT': # On NT win32pipe should work; on Win9x it hangs due to bugs # in the MS C lib (see MS KnowledgeBase article Q150956) try: import win32pipe except ImportError: pass else: popen = win32pipe.popen if popen is None: if hasattr(os,'popen'): popen = os.popen # Check whether it works... it doesn't in GUI programs # on Windows platforms if sys.platform == 'win32': # XXX Others too ? try: popen('') except os.error: popen = _popen else: popen = _popen if bufsize is None: return popen(cmd,mode) else: return popen(cmd,mode,bufsize) def _norm_version(version,build=''): """ Normalize the version and build strings and return a sinlge vesion string using the format major.minor.build (or patchlevel). """ l = string.split(version,'.') if build: l.append(build) try: ints = map(int,l) except ValueError: strings = l else: strings = map(str,ints) version = string.join(strings[:3],'.') return version def _syscmd_ver(system='',release='',version='', supported_platforms=('win32','win16','dos','os2'), ver_output=re.compile('(?:([\w ]+) ([\w.]+) ' '.*' 'Version ([\d.]+))')): """ Tries to figure out the OS version used and returns a tuple (system,release,version). It uses the "ver" shell command for this which is known to exists on Windows, DOS and OS/2. XXX Others too ? In case this fails, the given parameters are used as defaults. """ if sys.platform not in supported_platforms: return system,release,version # Try some common cmd strings for cmd in ('ver','command /c ver','cmd /c ver'): try: pipe = popen(cmd) info = pipe.read() if pipe.close(): raise os.error,'command failed' # XXX How can I supress shell errors from being written # to stderr ? except os.error,why: #print 'Command %s failed: %s' % (cmd,why) continue except IOError,why: #print 'Command %s failed: %s' % (cmd,why) continue else: break else: return system,release,version # Parse the output info = string.strip(info) m = ver_output.match(info) if m: system,release,version = m.groups() # Strip trailing dots from version and release if release[-1] == '.': release = release[:-1] if version[-1] == '.': version = version[:-1] # Normalize the version and build strings (eliminating additional # zeros) version = _norm_version(version) return system,release,version def _win32_getvalue(key,name,default=''): """ Read a value for name from the registry key. In case this fails, default is returned. """ from win32api import RegQueryValueEx try: return RegQueryValueEx(key,name) except: return default def win32_ver(release='',version='',csd='',ptype=''): """ Get additional version information from the Windows Registry and return a tuple (version,csd,ptype) referring to version number, CSD level and OS type (multi/single processor). As a hint: ptype returns 'Uniprocessor Free' on single processor NT machines and 'Multiprocessor Free' on multi processor machines. The 'Free' refers to the OS version being free of debugging code. It could also state 'Checked' which means the OS version uses debugging code, i.e. code that checks arguments, ranges, etc. (Thomas Heller). Note: this functions only works if Mark Hammond's win32 package is installed and obviously only runs on Win32 compatible platforms. XXX Is there any way to find out the processor type on WinXX ? XXX Is win32 available on Windows CE ? Adapted from code posted by Karl Putland to comp.lang.python. """ # Import the needed APIs try: import win32api except ImportError: return release,version,csd,ptype from win32api import RegQueryValueEx,RegOpenKeyEx,RegCloseKey,GetVersionEx from win32con import HKEY_LOCAL_MACHINE,VER_PLATFORM_WIN32_NT,\ VER_PLATFORM_WIN32_WINDOWS # Find out the registry key and some general version infos maj,min,buildno,plat,csd = GetVersionEx() version = '%i.%i.%i' % (maj,min,buildno & 0xFFFF) if csd[:13] == 'Service Pack ': csd = 'SP' + csd[13:] if plat == VER_PLATFORM_WIN32_WINDOWS: regkey = 'SOFTWARE\\Microsoft\\Windows\\CurrentVersion' # Try to guess the release name if maj == 4: if min == 0: release = '95' else: release = '98' elif maj == 5: release = '2000' elif plat == VER_PLATFORM_WIN32_NT: regkey = 'SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion' if maj <= 4: release = 'NT' elif maj == 5: release = '2000' else: if not release: # E.g. Win3.1 with win32s release = '%i.%i' % (maj,min) return release,version,csd,ptype # Open the registry key try: keyCurVer = RegOpenKeyEx(HKEY_LOCAL_MACHINE,regkey) # Get a value to make sure the key exists... RegQueryValueEx(keyCurVer,'SystemRoot') except: return release,version,csd,ptype # Parse values #subversion = _win32_getvalue(keyCurVer, # 'SubVersionNumber', # ('',1))[0] #if subversion: # release = release + subversion # 95a, 95b, etc. build = _win32_getvalue(keyCurVer, 'CurrentBuildNumber', ('',1))[0] ptype = _win32_getvalue(keyCurVer, 'CurrentType', (ptype,1))[0] # Normalize version version = _norm_version(version,build) # Close key RegCloseKey(keyCurVer) return release,version,csd,ptype def _mac_ver_lookup(selectors,default=None): from gestalt import gestalt l = [] append = l.append for selector in selectors: try: append(gestalt(selector)) except RuntimeError: append(default) return l def _bcd2str(bcd): return hex(bcd)[2:] def mac_ver(release='',versioninfo=('','',''),machine=''): """ Get MacOS version information and return it as tuple (release, versioninfo, machine) with versioninfo being a tuple (version, dev_stage, non_release_version). Entries which cannot be determined are set to ''. All tuple entries are strings. Thanks to Mark R. Levinson for mailing documentation links and code examples for this function. Documentation for the gestalt() API is available online at: http://www.rgaros.nl/gestalt/ """ # Check whether the version info module is available try: import gestalt except ImportError: return release,versioninfo,machine # Get the infos sysv,sysu,sysa = _mac_ver_lookup(('sysv','sysu','sysa')) # Decode the infos if sysv: major = (sysv & 0xFF00) >> 8 minor = (sysv & 0x00F0) >> 4 patch = (sysv & 0x000F) release = '%s.%i.%i' % (_bcd2str(major),minor,patch) if sysu: major = (sysu & 0xFF000000) >> 24 minor = (sysu & 0x00F00000) >> 20 bugfix = (sysu & 0x000F0000) >> 16 stage = (sysu & 0x0000FF00) >> 8 nonrel = (sysu & 0x000000FF) version = '%s.%i.%i' % (_bcd2str(major),minor,bugfix) nonrel = _bcd2str(nonrel) stage = {0x20:'development', 0x40:'alpha', 0x60:'beta', 0x80:'final'}.get(stage,'') versioninfo = (version,stage,nonrel) if sysa: machine = {0x1: '68k', 0x2: 'PowerPC'}.get(sysa,'') return release,versioninfo,machine def _java_getprop(self,name,default): from java.lang import System try: return System.getProperty(name) except: return default def java_ver(release='',vendor='',vminfo=('','',''),osinfo=('','','')): """ Version interface for JPython. Returns a tuple (release,vendor,vminfo,osinfo) with vminfo being a tuple (vm_name,vm_release,vm_vendor) and osinfo being a tuple (os_name,os_version,os_arch). Values which cannot be determined are set to the defaults given as parameters (which all default to ''). """ # Import the needed APIs try: import java.lang except ImportError: return release,vendor,vminfo,osinfo vendor = _java_getprop('java.vendor',vendor) release = _java_getprop('java.version',release) vm_name,vm_release,vm_vendor = vminfo vm_name = _java_getprop('java.vm.name',vm_name) vm_vendor = _java_getprop('java.vm.vendor',vm_vendor) vm_release = _java_getprop('java.vm.version',vm_release) vminfo = vm_name,vm_release,vm_vendor os_name,os_version,os_arch = osinfo os_arch = _java_getprop('java.os.arch',os_arch) os_name = _java_getprop('java.os.name',os_name) os_version = _java_getprop('java.os.version',os_version) osinfo = os_name,os_version,os_arch return release,vendor,vminfo,osinfo ### System name aliasing def system_alias(system,release,version): """ Returns (system,release,version) aliased to common marketing names used for some systems. It also does some reordering of the information in some cases where it would otherwise cause confusion. """ if system == 'Rhapsody': # Apple's BSD derivative # XXX How can we determine the marketing release number ? return 'MacOS X Server',system+release,version elif system == 'SunOS': # Sun's OS if release < '5': # These releases use the old name SunOS return system,release,version # Modify release (marketing release = SunOS release - 3) l = string.split(release,'.') if l: try: major = int(l[0]) except ValueError: pass else: major = major - 3 l[0] = str(major) release = string.join(l,'.') if release < '6': system = 'Solaris' else: # XXX Whatever the new SunOS marketing name is... system = 'Solaris' elif system == 'IRIX64': # IRIX reports IRIX64 on platforms with 64-bit support; yet it # is really a version and not a different platform, since 32-bit # apps are also supported.. system = 'IRIX' if version: version = version + ' (64bit)' else: version = '64bit' elif system in ('win32','win16'): # In case one of the other tricks system = 'Windows' return system,release,version ### Various internal helpers def _platform(*args): """ Helper to format the platform string in a filename compatible format e.g. "system-version-machine". """ # Format the platform string platform = string.join( map(string.strip, filter(len,args)), '-') # Cleanup some possible filename obstacles... replace = string.replace platform = replace(platform,' ','_') platform = replace(platform,'/','-') platform = replace(platform,'\\','-') platform = replace(platform,':','-') platform = replace(platform,';','-') platform = replace(platform,'"','-') platform = replace(platform,'(','-') platform = replace(platform,')','-') # No need to report 'unkown' information... platform = replace(platform,'unknown','') # Fold '--'s and remove trailing '-' while 1: cleaned = replace(platform,'--','-') if cleaned == platform: break platform = cleaned while platform[-1] == '-': platform = platform[:-1] return platform def _node(default=''): """ Helper to determine the node name of this machine. """ try: import socket except ImportError: # No sockets... return default try: return socket.gethostname() except socket.error: # Still not working... return default # os.path.abspath is new in Python 1.5.2: if not hasattr(os.path,'abspath'): def _abspath(path, isabs=os.path.isabs,join=os.path.join,getcwd=os.getcwd, normpath=os.path.normpath): if not isabs(path): path = join(getcwd(), path) return normpath(path) else: _abspath = os.path.abspath def _follow_symlinks(filepath): """ In case filepath is a symlink, follow it until a real file is reached. """ filepath = _abspath(filepath) while os.path.islink(filepath): filepath = os.path.normpath( os.path.join(filepath,os.readlink(filepath))) return filepath def _syscmd_uname(option,default=''): """ Interface to the system's uname command. """ if sys.platform in ('dos','win32','win16','os2'): # XXX Others too ? return default try: f = os.popen('uname %s 2> /dev/null' % option) except (AttributeError,os.error): return default output = string.strip(f.read()) rc = f.close() if not output or rc: return default else: return output def _syscmd_file(target,default=''): """ Interface to the system's file command. The function uses the -b option of the file command to have it ommit the filename in its output and if possible the -L option to have the command follow symlinks. It returns default in case the command should fail. """ target = _follow_symlinks(target) try: f = os.popen('file %s 2> /dev/null' % target) except (AttributeError,os.error): return default output = string.strip(f.read()) rc = f.close() if not output or rc: return default else: return output ### Information about the used architecture # Default values for architecture; non-empty strings override the # defaults given as parameters _default_architecture = { 'win32': ('','WindowsPE'), 'win16': ('','Windows'), 'dos': ('','MSDOS'), } def architecture(executable=sys.executable,bits='',linkage='', split=re.compile('[\s,]').split): """ Queries the given executable (defaults to the Python interpreter binary) for various architecture informations. Returns a tuple (bits,linkage) which contain information about the bit architecture and the linkage format used for the executable. Both values are returned as strings. Values that cannot be determined are returned as given by the parameter presets. If bits is given as '', the sizeof(pointer) (or sizeof(long) on Python version < 1.5.2) is used as indicator for the supported pointer size. The function relies on the system's "file" command to do the actual work. This is available on most if not all Unix platforms. On some non-Unix platforms and then only if the executable points to the Python interpreter defaults from _default_architecture are used. """ # Use the sizeof(pointer) as default number of bits if nothing # else is given as default. if not bits: import struct try: size = struct.calcsize('P') except struct.error: # Older installations can only query longs size = struct.calcsize('l') bits = str(size*8) + 'bit' # Get data from the 'file' system command output = _syscmd_file(executable,'') if not output and \ executable == sys.executable: # "file" command did not return anything; we'll try to provide # some sensible defaults then... if _default_architecture.has_key(sys.platform): b,l = _default_architecture[sys.platform] if b: bits = b if l: linkage = l return bits,linkage # Split the output into a list of strings omitting the filename fileout = split(output)[1:] if 'executable' not in fileout: # Format not supported return bits,linkage # Bits if '32-bit' in fileout: bits = '32bit' elif 'N32' in fileout: # On Irix only bits = 'n32bit' elif '64-bit' in fileout: bits = '64bit' # Linkage if 'ELF' in fileout: linkage = 'ELF' elif 'PE' in fileout: # E.g. Windows uses this format if 'Windows' in fileout: linkage = 'WindowsPE' else: linkage = 'PE' elif 'COFF' in fileout: linkage = 'COFF' elif 'MS-DOS' in fileout: linkage = 'MSDOS' else: # XXX the A.OUT format also falls under this class... pass return bits,linkage ### Portable uname() interface _uname_cache = None def uname(): """ Fairly portable uname interface. Returns a tuple of strings (system,node,release,version,machine,processor) identifying the underlying platform. Note that unlike the os.uname function this also returns possible processor information as additional tuple entry. Entries which cannot be determined are set to ''. """ global _uname_cache if _uname_cache is not None: return _uname_cache # Get some infos from the builtin os.uname API... try: system,node,release,version,machine = os.uname() except AttributeError: # Hmm, no uname... we'll have to poke around the system then. system = sys.platform release = '' version = '' node = _node() machine = '' processor = '' use_syscmd_ver = 1 # Try win32_ver() on win32 platforms if system == 'win32': release,version,csd,ptype = win32_ver() if release and version: use_syscmd_ver = 0 # Try the 'ver' system command available on some # platforms if use_syscmd_ver: system,release,version = _syscmd_ver(system) # In case we still don't know anything useful, we'll try to # help ourselves if system in ('win32','win16'): if not version: if system == 'win32': version = '32bit' else: version = '16bit' system = 'Windows' elif system[:4] == 'java': release,vendor,vminfo,osinfo = java_ver() system = 'Java' version = string.join(vminfo,', ') if not version: version = vendor elif os.name == 'mac': release,(version,stage,nonrel),machine = mac_ver() system = 'MacOS' else: # System specific extensions if system == 'OpenVMS': # OpenVMS seems to have release and version mixed up if not release or release == '0': release = version version = '' # Get processor information try: import vms_lib except ImportError: pass else: csid, cpu_number = vms_lib.getsyi('SYI$_CPU',0) if (cpu_number >= 128): processor = 'Alpha' else: processor = 'VAX' else: # Get processor information from the uname system command processor = _syscmd_uname('-p','') # 'unkown' is not really any useful as information; we'll convert # it to '' which is more portable if system == 'unknown': system = '' if node == 'unknown': node = '' if release == 'unknown': release = '' if version == 'unknown': version = '' if machine == 'unknown': machine = '' if processor == 'unknown': processor = '' _uname_cache = system,node,release,version,machine,processor return _uname_cache ### Direct interfaces to some of the uname() return values def system(): """ Returns the system/OS name, e.g. 'Linux', 'Windows' or 'Java'. An empty string is returned if the value cannot be determined. """ return uname()[0] def node(): """ Returns the computer's network name (may not be fully qualified !) An empty string is returned if the value cannot be determined. """ return uname()[1] def release(): """ Returns the system's release, e.g. '2.2.0' or 'NT' An empty string is returned if the value cannot be determined. """ return uname()[2] def version(): """ Returns the system's release version, e.g. '#3 on degas' An empty string is returned if the value cannot be determined. """ return uname()[3] def machine(): """ Returns the machine type, e.g. 'i386' An empty string is returned if the value cannot be determined. """ return uname()[4] def processor(): """ Returns the (true) processor name, e.g. 'amdk6' An empty string is returned if the value cannot be determined. Note that many platforms do not provide this information or simply return the same value as for machine(), e.g. NetBSD does this. """ return uname()[5] ### The Opus Magnum of platform strings :-) _platform_cache = None _platform_aliased_cache = None def platform(aliased=0, terse=0): """ Returns a single string identifying the underlying platform with as much useful information as possible (but no more :). The output is intended to be human readable rather than machine parseable. It may look different on different platforms and this is intended. If "aliased" is true, the function will use aliases for various platforms that report system names which differ from their common names, e.g. SunOS will be reported as Solaris. The system_alias() function is used to implement this. Setting terse to true causes the function to return only the absolute minimum information needed to identify the platform. """ global _platform_cache,_platform_aliased_cache if not aliased and (_platform_cache is not None): return _platform_cache elif _platform_aliased_cache is not None: return _platform_aliased_cache # Get uname information and then apply platform specific cosmetics # to it... system,node,release,version,machine,processor = uname() if machine == processor: processor = '' if aliased: system,release,version = system_alias(system,release,version) if system == 'Windows': # MS platforms rel,vers,csd,ptype = win32_ver(version) if terse: platform = _platform(system,release) else: platform = _platform(system,release,version,csd) elif system in ('Linux',): # Linux based systems distname,distversion,distid = dist('') if distname and not terse: platform = _platform(system,release,machine,processor, 'with', distname,distversion,distid) else: # If the distribution name is unknown check for libc vs. glibc libcname,libcversion = libc_ver(sys.executable) platform = _platform(system,release,machine,processor, 'with', libcname+libcversion) elif system == 'Java': # Java platforms r,v,vminfo,(os_name,os_version,os_arch) = java_ver() if terse: platform = _platform(system,release,version) else: platform = _platform(system,release,version, 'on', os_name,os_version,os_arch) elif system == 'MacOS': # MacOS platforms if terse: platform = _platform(system,release) else: platform = _platform(system,release,machine) else: # Generic handler if terse: platform = _platform(system,release) else: bits,linkage = architecture(sys.executable) platform = _platform(system,release,machine,processor,bits,linkage) if aliased: _platform_aliased_cache = platform elif terse: pass else: _platform_cache = platform return platform if __name__ == '__main__': # Default is to print the aliased verbose platform string terse = 'terse' in sys.argv aliased = not 'nonaliased' in sys.argv print platform(aliased,terse) sys.exit(0) --------------B32584A17EA1E930287FE86F-- From guido@python.org Fri Jun 30 15:47:29 2000 From: guido@python.org (Guido van Rossum) Date: Fri, 30 Jun 2000 09:47:29 -0500 Subject: [Python-Dev] Removing modules In-Reply-To: Your message of "Thu, 29 Jun 2000 21:29:41 -0400." <20000629212941.A21563@newcnri.cnri.reston.va.us> References: <20000629212941.A21563@newcnri.cnri.reston.va.us> Message-ID: <200006301447.JAA30671@cj20424-a.reston1.va.home.com> > For the "deleted modules" section of the 2.0 article, I drew up a list > of modules that might be outdated, mostly the SGI-specific ones. Are > those modules still useful, and do the libraries they were written for > still exist? Doubtful. I've asked Sjoerd and Jack, who were most involved in using these. > For your cogitation, here's the list: sgimodule.c, glmodule.c (and > hence cgenmodule.c), imgfile.c, svmodule.c, flmodule.c, fmmodule.c, > almodule.c, clmodule.c, knee.py. I'd like to keep knee.py -- it's a nice piece of *documentation* of the package import. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Fri Jun 30 15:55:08 2000 From: guido@python.org (Guido van Rossum) Date: Fri, 30 Jun 2000 09:55:08 -0500 Subject: [Python-Dev] Hey! who changed sys.platform?! In-Reply-To: Your message of "Fri, 30 Jun 2000 15:40:36 +0200." <395CA354.16AC5B7E@lemburg.com> References: <20000629233003.A1766@beelzebub> <14684.5401.518766.362678@cj42289-a.reston1.va.home.com> <395C681D.C3211F6@lemburg.com> <14684.41320.38954.833643@cj42289-a.reston1.va.home.com> <395CA354.16AC5B7E@lemburg.com> Message-ID: <200006301455.JAA30721@cj20424-a.reston1.va.home.com> > > Regarding platform.py: > > > > M.-A. Lemburg writes: > > > Why not simply include it in distutils ? > > > > Why not include it in the standard library? > > Guido? I'll document it if Marc-Andre is willing to provide the > > module and the regression test. > > No objection from here. > > I've attached my most recent copy to this mail. I'm not sure > how to write the regr. test though since output is dependent > on the platform running the functions... perhaps I'll just > add something like the audio thingie: "This string ought > to identify the platform you are currently running... if not, > then something is wrong ;-)". You didn't include it! But I vote -1 on this one anyway -- it's too much code and almost by its very nature not something that belongs in a "standard" library. Plus, I don't want to be responsible for maintaining it. Sorry, --Guido van Rossum (home page: http://www.python.org/~guido/) From bwarsaw@beopen.com Fri Jun 30 14:57:47 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Fri, 30 Jun 2000 09:57:47 -0400 (EDT) Subject: [Python-Dev] New PythonLabs site revealed! References: <005801bfe270$e140d440$f2a6b5d4@hagrid> Message-ID: <14684.42843.472230.609828@anthem.concentric.net> >>>>> "FL" == Fredrik Lundh writes: FL> btw, now that we're bumping to 2.0, maybe we can break FL> socket.connect and friends once again? if somebody com- FL> plains, just tell them "it's a major release, dammit" ;-) That's a good point. A bump in major rev number is an /opportunity/ to break things, like a bone that hasn't healed right, so that they can be fixed correctly. We'll lose that for 2.0, mostly likely because of the tight release schedule. There's always 3.0 though, which will mesh nicely with the mythical Py3k. -Barry From Fredrik Lundh" <005801bfe270$e140d440$f2a6b5d4@hagrid> <14684.42843.472230.609828@anthem.concentric.net> Message-ID: <016e01bfe29c$a2e8bb00$f2a6b5d4@hagrid> barry wrote: > >>>>> "FL" =3D=3D Fredrik Lundh writes: >=20 > FL> btw, now that we're bumping to 2.0, maybe we can break > FL> socket.connect and friends once again? if somebody com- > FL> plains, just tell them "it's a major release, dammit" ;-) >=20 > That's a good point. A bump in major rev number is an /opportunity/ > to break things, like a bone that hasn't healed right, so that they > can be fixed correctly. We'll lose that for 2.0, mostly likely > because of the tight release schedule. yeah, but I'm sure Guido has the patches somewhere (after all, the 1.6 release notes still mention this change). if not, the mad patcher volunteers to fix (or rather, break) this. Guido? From bwarsaw@beopen.com Fri Jun 30 15:07:47 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Fri, 30 Jun 2000 10:07:47 -0400 (EDT) Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/PCbuild readme.txt,1.5,1.6 References: Message-ID: <14684.43443.919858.897738@anthem.concentric.net> >>>>> "MH" == Mark Hammond writes: MH> [I wishing mailing-lists would agree on how they handle MH> reply-to :-] It's fundamentally broken, but the problem is in the mail readers (MUA). There's no header (that I'm aware of) that portably tells an MUA - "Hey, for a group follow up, don't go to the original list, go to THIS one instead, but for an individual followup (i.e. reply) still address that to the original author." This is one reason why munging reply-to is evil. But in this case we've agreed that following up to python-dev is more important than preserving the ability to reply to the author. -Barry From mal@lemburg.com Fri Jun 30 15:11:54 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 30 Jun 2000 16:11:54 +0200 Subject: [Python-Dev] Hey! who changed sys.platform?! References: <20000629233003.A1766@beelzebub> <14684.5401.518766.362678@cj42289-a.reston1.va.home.com> <395C681D.C3211F6@lemburg.com> <14684.41320.38954.833643@cj42289-a.reston1.va.home.com> <395CA354.16AC5B7E@lemburg.com> <200006301455.JAA30721@cj20424-a.reston1.va.home.com> Message-ID: <395CAAAA.5975A617@lemburg.com> Guido van Rossum wrote: > > > > Regarding platform.py: > > > > > > M.-A. Lemburg writes: > > > > Why not simply include it in distutils ? > > > > > > Why not include it in the standard library? > > > Guido? I'll document it if Marc-Andre is willing to provide the > > > module and the regression test. > > > > No objection from here. > > > > I've attached my most recent copy to this mail. I'm not sure > > how to write the regr. test though since output is dependent > > on the platform running the functions... perhaps I'll just > > add something like the audio thingie: "This string ought > > to identify the platform you are currently running... if not, > > then something is wrong ;-)". > > You didn't include it! I posted a reply to fix this ;-) > But I vote -1 on this one anyway -- it's too much code and almost by > its very nature not something that belongs in a "standard" library. > Plus, I don't want to be responsible for maintaining it. Sorry, You don't have to maintain it... I will anyway since it's part of mxCGIPython. Anyway, perhaps Greg Ward can find some use for it in distutils. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Fredrik Lundh" my latest changes fixed a couple of things, but broke one of the old RE tests, namely: re.match('\\x00ffffffffffffff', '\377') !=3D None or in other words, long hexadecimal escapes are cast down to 8-bit characters in RE. in SRE (after the latest change), they're cast down to the size of the engine's internal word size (currently 16 bits). is the old behaviour worth keeping? I'd rather not make the engine dependent on string types; it shouldn't really matter if you're using unicode patterns on 8-bit target strings, or vice versa. From gward@mems-exchange.org Fri Jun 30 15:13:40 2000 From: gward@mems-exchange.org (Greg Ward) Date: Fri, 30 Jun 2000 10:13:40 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils msvccompiler.py,1.33,1.34 In-Reply-To: <14683.56294.836295.923883@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Thu, Jun 29, 2000 at 07:29:42PM -0400 References: <200006292305.QAA11929@slayer.i.sourceforge.net> <200006300020.TAA21877@cj20424-a.reston1.va.home.com> <14683.56294.836295.923883@cj42289-a.reston1.va.home.com> Message-ID: <20000630101340.A16350@ludwig.cnri.reston.va.us> On 29 June 2000, Fred L. Drake, Jr. said: > > Greg Ward wrote in a checkin message: > > On second thought, first try for _winreg, and then winreg. Only if both > > fail do we try for win32api/win32con. If *those* both fail, then we don't > > have registry access. Phew! > > Guido van Rossum writes on python-dev: > > Is this smart? Doesn't the new winreg have a very different I/F than > > the old one? > > No, this is bad. It *will* break with winreg; if _winreg isn't > available, it should use the win32api/win32con/whatever stuff; it's a > Python 1.5.2 interpreter at that point. What if it's a 1.6a1 or 1.6a2 interpreter? Presumably people will try Distutils 0.9 with them. Should I remove that feature now that 0.9 is out, but before Python 2.0b1? Greg -- Greg Ward - software developer gward@mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From esr@thyrsus.com Fri Jun 30 15:27:07 2000 From: esr@thyrsus.com (Eric S. Raymond) Date: Fri, 30 Jun 2000 10:27:07 -0400 Subject: [Python-Dev] Removing modules In-Reply-To: <200006301447.JAA30671@cj20424-a.reston1.va.home.com>; from guido@python.org on Fri, Jun 30, 2000 at 09:47:29AM -0500 References: <20000629212941.A21563@newcnri.cnri.reston.va.us> <200006301447.JAA30671@cj20424-a.reston1.va.home.com> Message-ID: <20000630102707.A27830@thyrsus.com> Guido van Rossum : > > For the "deleted modules" section of the 2.0 article, I drew up a list > > of modules that might be outdated, mostly the SGI-specific ones. Are > > those modules still useful, and do the libraries they were written for > > still exist? > > Doubtful. I've asked Sjoerd and Jack, who were most involved in using > these. > > > For your cogitation, here's the list: sgimodule.c, glmodule.c (and > > hence cgenmodule.c), imgfile.c, svmodule.c, flmodule.c, fmmodule.c, > > almodule.c, clmodule.c, knee.py. > > I'd like to keep knee.py -- it's a nice piece of *documentation* of > the package import. +1 on giving the SGI-specific modules the heave-ho. Their presence has always struck me as a sort of vermiform appendix in a core library otherwise clearly aimed at being as platform-independent as rdeasonably possible (e.g. given the Unix-vs.Windows differences). -- Eric S. Raymond Power concedes nothing without a demand. It never did, and it never will. Find out just what people will submit to, and you have found out the exact amount of injustice and wrong which will be imposed upon them; and these will continue until they are resisted with either words or blows, or with both. The limits of tyrants are prescribed by the endurance of those whom they oppress. -- Frederick Douglass, August 4, 1857 From gward@mems-exchange.org Fri Jun 30 15:22:42 2000 From: gward@mems-exchange.org (Greg Ward) Date: Fri, 30 Jun 2000 10:22:42 -0400 Subject: [Python-Dev] Hey! who changed sys.platform?! In-Reply-To: <395CAAAA.5975A617@lemburg.com>; from mal@lemburg.com on Fri, Jun 30, 2000 at 04:11:54PM +0200 References: <20000629233003.A1766@beelzebub> <14684.5401.518766.362678@cj42289-a.reston1.va.home.com> <395C681D.C3211F6@lemburg.com> <14684.41320.38954.833643@cj42289-a.reston1.va.home.com> <395CA354.16AC5B7E@lemburg.com> <200006301455.JAA30721@cj20424-a.reston1.va.home.com> <395CAAAA.5975A617@lemburg.com> Message-ID: <20000630102242.B16350@ludwig.cnri.reston.va.us> On 30 June 2000, M.-A. Lemburg said: > > But I vote -1 on this one anyway -- it's too much code and almost by > > its very nature not something that belongs in a "standard" library. > > Plus, I don't want to be responsible for maintaining it. Sorry, > > You don't have to maintain it... I will anyway since it's part > of mxCGIPython. > > Anyway, perhaps Greg Ward can find some use for it in > distutils. I looked at platform.py once briefly, and my impression was similar to Guido's: too big! All I want(ed) is "osname-cpu" -- linux-i386, solaris-sparc, whatever. osversion is optional. But, consider that that the Distutils might want to know if it should generate RPMs or Debian packages... then the stuff about grokking which Linux distribution it's running on is relevant. Argh! Anyways, I'm already taking static about too much code in the Distutils, and I partly agree. (I agree there's a *lot* of code, I know there are bits that can be refactored and reduced, but I'm not sure it's too much.) So I'll stick with sys.platform for now -- it's good enough. Greg -- Greg Ward - software developer gward@mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From sjoerd@oratrix.nl Fri Jun 30 15:21:53 2000 From: sjoerd@oratrix.nl (Sjoerd Mullender) Date: Fri, 30 Jun 2000 16:21:53 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Objects unicodeobject.c,2.31,2.32 In-Reply-To: Your message of Fri, 30 Jun 2000 03:29:59 -0700. <200006301029.DAA25494@slayer.i.sourceforge.net> References: <200006301029.DAA25494@slayer.i.sourceforge.net> Message-ID: <20000630142154.968F831047C@bireme.oratrix.nl> Why was the change that occurred in revision 2.31 reverted? Accident? The change log said: Jack Jansen: Use include "" instead of <>; and staticforward declarations On Fri, Jun 30 2000 "M.-A. Lemburg" wrote: > Update of /cvsroot/python/python/dist/src/Objects > In directory slayer.i.sourceforge.net:/tmp/cvs-serv25442/Objects > > Modified Files: > unicodeobject.c > Log Message: > Marc-Andre Lemburg : > New buffer overflow checks for formatting strings. > > By Trent Mick. > > Index: unicodeobject.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v > retrieving revision 2.31 > retrieving revision 2.32 > diff -C2 -r2.31 -r2.32 > *** unicodeobject.c 2000/06/29 00:06:39 2.31 > --- unicodeobject.c 2000/06/30 10:29:57 2.32 > *************** > *** 67,71 **** > #include "mymath.h" > #include "unicodeobject.h" > ! #include "ucnhash.h" > > #if defined(HAVE_LIMITS_H) > --- 67,71 ---- > #include "mymath.h" > #include "unicodeobject.h" > ! #include > > #if defined(HAVE_LIMITS_H) > *************** > *** 1245,1249 **** > ucnFallthrough: > /* fall through on purpose */ > ! default: > *p++ = '\\'; > *p++ = (unsigned char)s[-1]; > --- 1245,1249 ---- > ucnFallthrough: > /* fall through on purpose */ > ! default: > *p++ = '\\'; > *p++ = (unsigned char)s[-1]; > *************** > *** 1252,1256 **** > } > if (_PyUnicode_Resize(v, (int)(p - buf))) > ! goto onError; > return (PyObject *)v; > > --- 1252,1256 ---- > } > if (_PyUnicode_Resize(v, (int)(p - buf))) > ! goto onError; > return (PyObject *)v; > > *************** > *** 4374,4377 **** > --- 4374,4378 ---- > static int > formatfloat(Py_UNICODE *buf, > + size_t buflen, > int flags, > int prec, > *************** > *** 4379,4382 **** > --- 4380,4385 ---- > PyObject *v) > { > + /* fmt = '%#.' + `prec` + `type` > + worst case length = 3 + 10 (len of INT_MAX) + 1 = 14 (use 20)*/ > char fmt[20]; > double x; > *************** > *** 4387,4395 **** > if (prec < 0) > prec = 6; > - if (prec > 50) > - prec = 50; /* Arbitrary limitation */ > if (type == 'f' && (fabs(x) / 1e25) >= 1e25) > type = 'g'; > sprintf(fmt, "%%%s.%d%c", (flags & F_ALT) ? "#" : "", prec, type); > return usprintf(buf, fmt, x); > } > --- 4390,4408 ---- > if (prec < 0) > prec = 6; > if (type == 'f' && (fabs(x) / 1e25) >= 1e25) > type = 'g'; > sprintf(fmt, "%%%s.%d%c", (flags & F_ALT) ? "#" : "", prec, type); > + /* worst case length calc to ensure no buffer overrun: > + fmt = %#.g > + buf = '-' + [0-9]*prec + '.' + 'e+' + (longest exp > + for any double rep.) > + len = 1 + prec + 1 + 2 + 5 = 9 + prec > + If prec=0 the effective precision is 1 (the leading digit is > + always given), therefore increase by one to 10+prec. */ > + if (buflen <= (size_t)10 + (size_t)prec) { > + PyErr_SetString(PyExc_OverflowError, > + "formatted float is too long (precision too long?)"); > + return -1; > + } > return usprintf(buf, fmt, x); > } > *************** > *** 4397,4400 **** > --- 4410,4414 ---- > static int > formatint(Py_UNICODE *buf, > + size_t buflen, > int flags, > int prec, > *************** > *** 4402,4405 **** > --- 4416,4421 ---- > PyObject *v) > { > + /* fmt = '%#.' + `prec` + 'l' + `type` > + worst case length = 3 + 10 (len of INT_MAX) + 1 + 1 = 15 (use 20)*/ > char fmt[20]; > long x; > *************** > *** 4410,4413 **** > --- 4426,4436 ---- > if (prec < 0) > prec = 1; > + /* buf = '+'/'-'/'0'/'0x' + '[0-9]'*max(prec,len(x in octal)) > + worst case buf = '0x' + [0-9]*prec, where prec >= 11 */ > + if (buflen <= 13 || buflen <= (size_t)2+(size_t)prec) { > + PyErr_SetString(PyExc_OverflowError, > + "formatted integer is too long (precision too long?)"); > + return -1; > + } > sprintf(fmt, "%%%s.%dl%c", (flags & F_ALT) ? "#" : "", prec, type); > return usprintf(buf, fmt, x); > *************** > *** 4416,4421 **** > static int > formatchar(Py_UNICODE *buf, > ! PyObject *v) > { > if (PyUnicode_Check(v)) { > if (PyUnicode_GET_SIZE(v) != 1) > --- 4439,4446 ---- > static int > formatchar(Py_UNICODE *buf, > ! size_t buflen, > ! PyObject *v) > { > + /* presume that the buffer is at least 2 characters long */ > if (PyUnicode_Check(v)) { > if (PyUnicode_GET_SIZE(v) != 1) > *************** > *** 4447,4450 **** > --- 4472,4485 ---- > } > > + /* fmt%(v1,v2,...) is roughly equivalent to sprintf(fmt, v1, v2, ...) > + > + FORMATBUFLEN is the length of the buffer in which the floats, ints, & > + chars are formatted. XXX This is a magic number. Each formatting > + routine does bounds checking to ensure no overflow, but a better > + solution may be to malloc a buffer of appropriate size for each > + format. For now, the current solution is sufficient. > + */ > + #define FORMATBUFLEN (size_t)120 > + > PyObject *PyUnicode_Format(PyObject *format, > PyObject *args) > *************** > *** 4506,4513 **** > PyObject *v = NULL; > PyObject *temp = NULL; > ! Py_UNICODE *buf; > Py_UNICODE sign; > int len; > ! Py_UNICODE tmpbuf[120]; /* For format{float,int,char}() */ > > fmt++; > --- 4541,4548 ---- > PyObject *v = NULL; > PyObject *temp = NULL; > ! Py_UNICODE *pbuf; > Py_UNICODE sign; > int len; > ! Py_UNICODE formatbuf[FORMATBUFLEN]; /* For format{float,int,char}() */ > > fmt++; > *************** > *** 4659,4664 **** > > case '%': > ! buf = tmpbuf; > ! buf[0] = '%'; > len = 1; > break; > --- 4694,4700 ---- > > case '%': > ! pbuf = formatbuf; > ! /* presume that buffer length is at least 1 */ > ! pbuf[0] = '%'; > len = 1; > break; > *************** > *** 4696,4700 **** > goto onError; > } > ! buf = PyUnicode_AS_UNICODE(temp); > len = PyUnicode_GET_SIZE(temp); > if (prec >= 0 && len > prec) > --- 4732,4736 ---- > goto onError; > } > ! pbuf = PyUnicode_AS_UNICODE(temp); > len = PyUnicode_GET_SIZE(temp); > if (prec >= 0 && len > prec) > *************** > *** 4710,4715 **** > if (c == 'i') > c = 'd'; > ! buf = tmpbuf; > ! len = formatint(buf, flags, prec, c, v); > if (len < 0) > goto onError; > --- 4746,4752 ---- > if (c == 'i') > c = 'd'; > ! pbuf = formatbuf; > ! len = formatint(pbuf, sizeof(formatbuf)/sizeof(Py_UNICODE), > ! flags, prec, c, v); > if (len < 0) > goto onError; > *************** > *** 4719,4725 **** > if ((flags&F_ALT) && > (c == 'x' || c == 'X') && > ! buf[0] == '0' && buf[1] == c) { > ! *res++ = *buf++; > ! *res++ = *buf++; > rescnt -= 2; > len -= 2; > --- 4756,4762 ---- > if ((flags&F_ALT) && > (c == 'x' || c == 'X') && > ! pbuf[0] == '0' && pbuf[1] == c) { > ! *res++ = *pbuf++; > ! *res++ = *pbuf++; > rescnt -= 2; > len -= 2; > *************** > *** 4736,4741 **** > case 'g': > case 'G': > ! buf = tmpbuf; > ! len = formatfloat(buf, flags, prec, c, v); > if (len < 0) > goto onError; > --- 4773,4779 ---- > case 'g': > case 'G': > ! pbuf = formatbuf; > ! len = formatfloat(pbuf, sizeof(formatbuf)/sizeof(Py_UNICODE), > ! flags, prec, c, v); > if (len < 0) > goto onError; > *************** > *** 4746,4751 **** > > case 'c': > ! buf = tmpbuf; > ! len = formatchar(buf, v); > if (len < 0) > goto onError; > --- 4784,4789 ---- > > case 'c': > ! pbuf = formatbuf; > ! len = formatchar(pbuf, sizeof(formatbuf)/sizeof(Py_UNICODE), v); > if (len < 0) > goto onError; > *************** > *** 4759,4764 **** > } > if (sign) { > ! if (*buf == '-' || *buf == '+') { > ! sign = *buf++; > len--; > } > --- 4797,4802 ---- > } > if (sign) { > ! if (*pbuf == '-' || *pbuf == '+') { > ! sign = *pbuf++; len--; > } > *************** > *** 4796,4800 **** > if (sign && fill == ' ') > *res++ = sign; > ! memcpy(res, buf, len * sizeof(Py_UNICODE)); > res += len; > rescnt -= len; > --- 4834,4838 ---- > if (sign && fill == ' ') > *res++ = sign; > ! memcpy(res, pbuf, len * sizeof(Py_UNICODE)); > res += len; > rescnt -= len; > > -- Sjoerd Mullender From akuchlin@mems-exchange.org Fri Jun 30 15:29:00 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Fri, 30 Jun 2000 10:29:00 -0400 Subject: [Python-Dev] SRE incompatibility In-Reply-To: <018401bfe29e$07f26720$f2a6b5d4@hagrid>; from effbot@telia.com on Fri, Jun 30, 2000 at 04:18:13PM +0200 References: <018401bfe29e$07f26720$f2a6b5d4@hagrid> Message-ID: <20000630102900.A19597@kronos.cnri.reston.va.us> On Fri, Jun 30, 2000 at 04:18:13PM +0200, Fredrik Lundh wrote: > re.match('\\x00ffffffffffffff', '\377') != None >or in other words, long hexadecimal escapes are cast >down to 8-bit characters in RE. This is for compatibility with Python string literals: kronos Python-1.6>./python >>> '\x00fffffff' '\377' >>> u'\x00fffffff' u'\uFFFF' (Where do these semantics come from, BTW? C's \x seems to take any number of hex digits but then reports an error if the character is greater than 256, too large to fit into a byte.) Note that the \u escape for Unicode characters uses exactly 4 digits, no more, no less. It would certainly be simpler and clearer to only support a fixed number of digits with \x, since I find the casting down behaviour is magical and not obvious. But I don't know if we want to make that change now. (Guido now realizes the downside to numbering it 2.0, as everyone hurries to suggest their favorite backward-incompatible change.) That doesn't help with regexes, of course, since a pattern might be written as a regular string but be intended to match Unicode. Maybe the simplest rule is the best; always take 4 digits, even if it winds up being incompatible with the \x in string literals. --amk From fdrake@beopen.com Fri Jun 30 15:33:47 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Fri, 30 Jun 2000 10:33:47 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils msvccompiler.py,1.33,1.34 In-Reply-To: <20000630101340.A16350@ludwig.cnri.reston.va.us> References: <200006292305.QAA11929@slayer.i.sourceforge.net> <200006300020.TAA21877@cj20424-a.reston1.va.home.com> <14683.56294.836295.923883@cj42289-a.reston1.va.home.com> <20000630101340.A16350@ludwig.cnri.reston.va.us> Message-ID: <14684.45003.193701.382599@cj42289-a.reston1.va.home.com> Greg Ward writes: > What if it's a 1.6a1 or 1.6a2 interpreter? Presumably people will try > Distutils 0.9 with them. Should I remove that feature now that 0.9 is > out, but before Python 2.0b1? You're placing too much value on code labelled "alpha". ;) There are two interesting versions -- 1.5.2 (since you scrapped support for versions before that), and 2.0. And the CVS version is the closest approximation to 2.0 that anyone has. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake@beopen.com Fri Jun 30 15:38:51 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Fri, 30 Jun 2000 10:38:51 -0400 (EDT) Subject: [Python-Dev] Hey! who changed sys.platform?! In-Reply-To: <20000630102242.B16350@ludwig.cnri.reston.va.us> References: <20000629233003.A1766@beelzebub> <14684.5401.518766.362678@cj42289-a.reston1.va.home.com> <395C681D.C3211F6@lemburg.com> <14684.41320.38954.833643@cj42289-a.reston1.va.home.com> <395CA354.16AC5B7E@lemburg.com> <200006301455.JAA30721@cj20424-a.reston1.va.home.com> <395CAAAA.5975A617@lemburg.com> <20000630102242.B16350@ludwig.cnri.reston.va.us> Message-ID: <14684.45307.983394.125671@cj42289-a.reston1.va.home.com> Greg Ward writes: > But, consider that that the Distutils might want to know if it should > generate RPMs or Debian packages... then the stuff about grokking which > Linux distribution it's running on is relevant. Argh! Why would you need to figure this out? Are you selecting a platform-specific packaging system automatically? In that case, I'd search for the presence of the tools rather than asking what sort of distribution you're running on -- several distros use RPM, a few use .deb packages, etc. When the user specifies one on the command line, just use the one they name and be done with it. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From mal@lemburg.com Fri Jun 30 15:53:31 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 30 Jun 2000 16:53:31 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Objects unicodeobject.c,2.31,2.32 References: <200006301029.DAA25494@slayer.i.sourceforge.net> <20000630142154.968F831047C@bireme.oratrix.nl> Message-ID: <395CB46B.34053D3E@lemburg.com> > Why was the change that occurred in revision 2.31 reverted? Accident? > > The change log said: > Jack Jansen: Use include "" instead of <>; and staticforward declarations Accident... I'll revert that change. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido@python.org Fri Jun 30 17:07:16 2000 From: guido@python.org (Guido van Rossum) Date: Fri, 30 Jun 2000 11:07:16 -0500 Subject: [Python-Dev] SRE incompatibility In-Reply-To: Your message of "Fri, 30 Jun 2000 16:18:13 +0200." <018401bfe29e$07f26720$f2a6b5d4@hagrid> References: <018401bfe29e$07f26720$f2a6b5d4@hagrid> Message-ID: <200006301607.LAA10829@cj20424-a.reston1.va.home.com> > my latest changes fixed a couple of things, but broke > one of the old RE tests, namely: > > re.match('\\x00ffffffffffffff', '\377') != None > > or in other words, long hexadecimal escapes are cast > down to 8-bit characters in RE. > > in SRE (after the latest change), they're cast down to > the size of the engine's internal word size (currently 16 > bits). > > is the old behaviour worth keeping? I'd rather not make > the engine dependent on string types; it shouldn't really > matter if you're using unicode patterns on 8-bit target > strings, or vice versa. To someone familiar with '\x00ffffffffffffff' == '\377', the failure is surprising. What Would Larry Do? (I.e. is this in Perl?) Maybe make it dependent on the type of the searched string ('\377') rather than on the type of the pattern? --Guido van Rossum (home page: http://www.python.org/~guido/) From skip@mojam.com (Skip Montanaro) Fri Jun 30 14:54:49 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Fri, 30 Jun 2000 08:54:49 -0500 (CDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test README,NONE,1.1 In-Reply-To: <20000629232733.D24811@activestate.com> References: <200006300608.XAA13124@slayer.i.sourceforge.net> <20000629232733.D24811@activestate.com> Message-ID: <14684.42665.221905.911205@beluga.mojam.com> Trent> Cool Thanks. >> To run the entire test suite, make the "test" target at the top level: >> >> cd ... >> make test Trent> This is a UN*Xism, on Windows and UN*X: Trent> cd ...\Lib\test Trent> python regrtest.py Thanks, I'll check into it. I'm a Unix weenie so am (blissfully) unaware of how Windows weenies do these things... ;-) Trent> A sample walk through to create a test might make it more Trent> approachable for people. As well, it would be helpful to mention Trent> test_support.{verbose|TESTFN|...}. But I have no right to bitch Trent> about good work. I'll check into that as well. The README file was created in about 30 minutes and was a good excuse to test my checkin capabilities on something that wouldn't break anything. ;-) Skip From mhammond@skippinet.com.au Fri Jun 30 16:48:43 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Sat, 1 Jul 2000 01:48:43 +1000 Subject: [Python-Dev] Checked in new PC\config.h Message-ID: Hi all, I noticed that PC\config.h still had a reference to "Python16.lib". I simply checked in a new version without submitting a patch or following any other process. I hope this was appropriate. Mark. From akuchlin@mems-exchange.org Fri Jun 30 17:03:48 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Fri, 30 Jun 2000 12:03:48 -0400 Subject: [Python-Dev] SRE incompatibility In-Reply-To: <200006301607.LAA10829@cj20424-a.reston1.va.home.com>; from guido@python.org on Fri, Jun 30, 2000 at 11:07:16AM -0500 References: <018401bfe29e$07f26720$f2a6b5d4@hagrid> <200006301607.LAA10829@cj20424-a.reston1.va.home.com> Message-ID: <20000630120348.C19597@kronos.cnri.reston.va.us> On Fri, Jun 30, 2000 at 11:07:16AM -0500, Guido van Rossum wrote: >To someone familiar with '\x00ffffffffffffff' == '\377', the failure >is surprising. What Would Larry Do? (I.e. is this in Perl?) It uses two digits: "\x00ffff" is the string "ffff". >Maybe make it dependent on the type of the searched string ('\377') >rather than on the type of the pattern? Won't work; you could just be compiling a pattern to make a regex object, and have no idea what you're matching against. --amk From jeremy@beopen.com Fri Jun 30 17:10:09 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Fri, 30 Jun 2000 12:10:09 -0400 (EDT) Subject: [Python-Dev] SRE incompatibility In-Reply-To: <018401bfe29e$07f26720$f2a6b5d4@hagrid> References: <018401bfe29e$07f26720$f2a6b5d4@hagrid> Message-ID: <14684.50785.245652.345591@bitdiddle.concentric.net> I don't know if this is related, exactly, but there is some kind of problem with the current test. When I run make test, I see: test test_sre crashed -- exceptions.SyntaxError : inconsistent use of tabs and spaces in indentation tabnanny thinks test_sre.py is fine, so I'm not sure what the problem is. Jeremy From tpeters@beopen.com Fri Jun 30 17:18:03 2000 From: tpeters@beopen.com (Tim Peters) Date: Fri, 30 Jun 2000 12:18:03 -0400 Subject: [Python-Dev] Checked in new PC\config.h In-Reply-To: Message-ID: [Mark Hammond] > I noticed that PC\config.h still had a reference to > "Python16.lib". I simply checked in a new version without > submitting a patch or following any other process. I hope > this was appropriate. IMO, if you're an expert in an area and need to make a change in that area that indeed needs to be made and isn't going to screw anybody (and because you're an expert in that area, you're not wrong in your judgment of that ), just do it! We'll see the diffs come by later. Guido, Barry, Jeremy, & Fred have been working that way a long time now. If they didn't want us to work that way too, they shouldn't have given us the ability to commit. empowering-the-masses-ly y'rs - tim From guido@python.org Fri Jun 30 18:18:10 2000 From: guido@python.org (Guido van Rossum) Date: Fri, 30 Jun 2000 12:18:10 -0500 Subject: [Python-Dev] SRE incompatibility In-Reply-To: Your message of "Fri, 30 Jun 2000 12:03:48 -0400." <20000630120348.C19597@kronos.cnri.reston.va.us> References: <018401bfe29e$07f26720$f2a6b5d4@hagrid> <200006301607.LAA10829@cj20424-a.reston1.va.home.com> <20000630120348.C19597@kronos.cnri.reston.va.us> Message-ID: <200006301718.MAA12448@cj20424-a.reston1.va.home.com> > On Fri, Jun 30, 2000 at 11:07:16AM -0500, Guido van Rossum wrote: > >To someone familiar with '\x00ffffffffffffff' == '\377', the failure > >is surprising. What Would Larry Do? (I.e. is this in Perl?) > > It uses two digits: "\x00ffff" is the string "ffff". > > >Maybe make it dependent on the type of the searched string ('\377') > >rather than on the type of the pattern? > > Won't work; you could just be compiling a pattern to make a regex > object, and have no idea what you're matching against. OK. Let's change our spec. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Fri Jun 30 18:26:51 2000 From: guido@python.org (Guido van Rossum) Date: Fri, 30 Jun 2000 12:26:51 -0500 Subject: [Python-Dev] Checked in new PC\config.h In-Reply-To: Your message of "Fri, 30 Jun 2000 12:18:03 -0400." References: Message-ID: <200006301726.MAA12560@cj20424-a.reston1.va.home.com> > IMO, if you're an expert in an area and need to make a change in that area > that indeed needs to be made and isn't going to screw anybody (and because > you're an expert in that area, you're not wrong in your judgment of that > ), just do it! We'll see the diffs come by later. Guido, Barry, > Jeremy, & Fred have been working that way a long time now. If they didn't > want us to work that way too, they shouldn't have given us the ability to > commit. Exactly! So far it's working like a charm! --Guido van Rossum (home page: http://www.python.org/~guido/) From tpeters@beopen.com Fri Jun 30 17:38:21 2000 From: tpeters@beopen.com (Tim Peters) Date: Fri, 30 Jun 2000 12:38:21 -0400 Subject: [Python-Dev] SRE incompatibility In-Reply-To: <20000630102900.A19597@kronos.cnri.reston.va.us> Message-ID: [Andrew Kuchling] > ... > This is for compatibility with Python string literals: > > kronos Python-1.6>./python > >>> '\x00fffffff' > '\377' > >>> u'\x00fffffff' > u'\uFFFF' > > (Where do these semantics come from, BTW? C's \x seems to take any > number of hex digits but then reports an error if the character is > greater than 256, too large to fit into a byte.) The behavior of \x in C is mostly implementation-defined. The committee knew that C had to do *something* to support "large characters" down the road, but in those early days they had no clear idea exactly what. So, rather than do something sensible <0.5 wink>, they invented a perfectly general mechanism without portable semantics. "C itself" isn't complaining if the character "is greater than 256", it's the specific implementation of C you're using that's complaining. A different implementation is free to (& probably will!) do something different. Guido adopted the most commonly implemented semantics (ignore all but the last byte) in Python, apparently under the delusion that this would be a Good Thing . Marc-Andre followed suit by generalizing this madness to Unicode. > Note that the \u escape for Unicode characters uses exactly 4 digits, > no more, no less. I pushed for that obnoxiously. Glad you appreciate it . Java does the same. > It would certainly be simpler and clearer to only support a fixed > number of digits with \x, since I find the casting down behaviour is > magical and not obvious. Yes, it's basically nuts. > But I don't know if we want to make that change now. No from me, because it may break stuff. Wait for Python 2.0 . > (Guido now realizes the downside to numbering it 2.0, as everyone > hurries to suggest their favorite backward-incompatible change.) Guido always realized that, I believe. It's a "least of evils" kind of thing, mixed with a celebration, not a pure win. > That doesn't help with regexes, of course, since a pattern might be > written as a regular string but be intended to match Unicode. Maybe > the simplest rule is the best; always take 4 digits, even if it winds > up being incompatible with the \x in string literals. I vote for backward compatibility for now, and not only because that will irritate /F the most. From bwarsaw@beopen.com Fri Jun 30 17:51:15 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Fri, 30 Jun 2000 12:51:15 -0400 (EDT) Subject: [Python-Dev] --with-cycle-gc switch Message-ID: <14684.53251.309942.13110@anthem.concentric.net> I don't like --with-cycle-gc as the configure switch, and unfortunately configure is explicitly designed not to complain about bogus switches. I just typed --without-gc and was momentarily surprised that the module was still enabled. I propose to change the switch to --with(out)-gc and to not recognize --with(out)-cycle-gc. The switch hasn't been there long enough to support both. -Barry From jeremy@beopen.com Fri Jun 30 18:02:42 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Fri, 30 Jun 2000 13:02:42 -0400 (EDT) Subject: [Python-Dev] --with-cycle-gc switch In-Reply-To: <14684.53251.309942.13110@anthem.concentric.net> References: <14684.53251.309942.13110@anthem.concentric.net> Message-ID: <14684.53938.307841.921051@bitdiddle.concentric.net> The problem with the name --without-gc is that it suggests a build without any garbage collection. The new patch only handles one special case of garbage collection. The name --without-cycle-gc is a little unwieldy, but clearer. Jeremy From Vladimir.Marangozov@inrialpes.fr Fri Jun 30 18:11:50 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Fri, 30 Jun 2000 19:11:50 +0200 (CEST) Subject: [Python-Dev] --with-cycle-gc switch In-Reply-To: <14684.53251.309942.13110@anthem.concentric.net> from "Barry A. Warsaw" at Jun 30, 2000 12:51:15 PM Message-ID: <200006301711.TAA21382@python.inrialpes.fr> Barry A. Warsaw wrote: > > I propose to change the switch to --with(out)-gc and to not recognize > --with(out)-cycle-gc. The switch hasn't been there long enough to > support both. -0 for the reason summarized by Jeremy -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From Fredrik Lundh" Message-ID: <02cc01bfe2b9$61b8ee80$f2a6b5d4@hagrid> from the new re.py: > ! # change this to "pre" if your regexps stopped working. don't > ! # forget to send a bug report to is bugs-py@python.org suitable? or should we refer people to=20 http://www.python.org/search/search_bugs.html or should they pester me directly? (i.e. effbot@telia.com) From guido@python.org Fri Jun 30 19:33:46 2000 From: guido@python.org (Guido van Rossum) Date: Fri, 30 Jun 2000 13:33:46 -0500 Subject: [Python-Dev] SRE: a minor glitch in re.py In-Reply-To: Your message of "Fri, 30 Jun 2000 19:33:55 +0200." <02cc01bfe2b9$61b8ee80$f2a6b5d4@hagrid> References: <200006301625.JAA32503@slayer.i.sourceforge.net> <02cc01bfe2b9$61b8ee80$f2a6b5d4@hagrid> Message-ID: <200006301833.NAA18667@cj20424-a.reston1.va.home.com> > from the new re.py: > > > ! # change this to "pre" if your regexps stopped working. don't > > ! # forget to send a bug report to > > is bugs-py@python.org suitable? > > or should we refer people to > http://www.python.org/search/search_bugs.html > > or should they pester me directly? (i.e. effbot@telia.com) Probably. You decide and check it in! --Guido van Rossum (home page: http://www.python.org/~guido/) From bwarsaw@beopen.com Fri Jun 30 18:39:12 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Fri, 30 Jun 2000 13:39:12 -0400 (EDT) Subject: [Python-Dev] --with-cycle-gc switch References: <14684.53251.309942.13110@anthem.concentric.net> <200006301711.TAA21382@python.inrialpes.fr> Message-ID: <14684.56128.700037.255534@anthem.concentric.net> >>>>> "VM" == Vladimir Marangozov writes: VM> -0 VM> for the reason summarized by Jeremy Okay, I'll leave it alone. From Vladimir.Marangozov@inrialpes.fr Fri Jun 30 18:52:15 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Fri, 30 Jun 2000 19:52:15 +0200 (CEST) Subject: [Python-Dev] Oops on AIX Message-ID: <200006301752.TAA22474@python.inrialpes.fr> After the CVS commit storm that occurred during the last 3 days, I wanted to validate the current build on AIX. And I am stalled. I am not sure, but it seems like the errors I get relate with the latest 64-bit support patches, and I don't dare to suggest corrections in this area, so I welcome any help... xlc_r -O -I./../Include -I.. -DHAVE_CONFIG_H -c methodobject.c "methodobject.c", line 183.36: 1506-280 (E) Function argument assignment between types "void*" and "struct _object*(*)(struct _object*,struct _object*)" is not allowed. xlc_r -O -I./../Include -I.. -DHAVE_CONFIG_H -c ./posixmodule.c "./posixmodule.c", line 293.16: 1506-213 (S) Macro name STAT cannot be redefined. "./posixmodule.c", line 293.16: 1506-358 (I) "STAT" is defined on line 170 of /usr/include/sys/dir.h. make: 1254-004 The error code from the last command is 1. Thanks. -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From Fredrik Lundh" Message-ID: <032701bfe2bc$23da47a0$f2a6b5d4@hagrid> tim wrote: > > That doesn't help with regexes, of course, since a pattern might be > > written as a regular string but be intended to match Unicode. Maybe > > the simplest rule is the best; always take 4 digits, even if it = winds > > up being incompatible with the \x in string literals. >=20 > I vote for backward compatibility for now, and not only because that = will > irritate /F the most. backward compatibility with what? 8-bit string literals or unicode string literals? the problem here is that the pattern is compiled once (from either 8-bit or unicode strings), and can then be used on either 8-bit or unicode targets. to be fully backwards compatible, this means that the compiler should use 8 bits, no matter what string type you're using. another solution would be to use the type of the pattern string to choose between 8 and 16 bits. I almost implemented that, before I realized that it broke the following rather nice property: sre.compile("some pattern") =3D=3D sre.compile(u"some pattern") (well, the pattern type doesn't implement __cmp__, but you get the idea). the current implementation guarantees "=3D=3D", but I'm planning to change that to "is" (!). anyway, I suspect it's too late to change this in 2.0b1. if enough people complain about this, we can always label it a "critical bug", and do something about it in b2. From bwarsaw@beopen.com Fri Jun 30 19:04:06 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Fri, 30 Jun 2000 14:04:06 -0400 (EDT) Subject: [Python-Dev] Odd behavior with `make test' Message-ID: <14684.57622.9807.868551@anthem.concentric.net> make test is behaving strangely. The first time I ran it I got test test_mmap crashed -- exceptions.SyntaxError : inconsistent use of tabs and spaces in indentation which I believe Jeremy has seen with test_sre. tabnanny says everything's fine, and running the module manually (and individually w/ regrtest) shows no problems with the test. Similarly, I got a different crash in test_sre. It says: test test_sre failed -- sre.search and I also get test test_re failed -- re.search I'm also getting bizare stuff like test test_strftime crashed -- exceptions.AttributeError : match test test_tokenize crashed -- exceptions.AttributeError : compile test test_xmllib crashed -- exceptions.AttributeError : compile This is all with a CVS updated Python 2.0b1. Now if I run "./python Lib/test/test_mmap.py" manually, this succeeds, and now either the failures go away or are transmorgrified into something more reasonable: mmap, strftime, tokenize, sre, and xmllib all pass. test_re still fails, but this time with test test_re failed -- Writing: '=== Failed incorrectly', expected: "('abc', 'abc', 0, 'fou" Blowing away the Lib/test/*.pyc's doesn't seem to re-trigger the problem once it's fixed, but doing a `make distclean' and `make test' gets me back to the initial situation. Weird! -Barry From Fredrik Lundh" <20000629235247.A25090@activestate.com> Message-ID: <037e01bfe2be$b814d5a0$f2a6b5d4@hagrid> trent wrote: > On Fri, Jun 30, 2000 at 02:39:15AM -0400, Tim Peters wrote: > > BTW, I'd just like to say what a delight it is to work with *all* of = you > > folks! >=20 > I feel a group hug coming on in the morning. Or maybe I am just moved = by the > beer that I had for dinner. :) beer for dinner? what an excellent idea. didn't I have some strong lager somewhere? ah, yes... hey, maybe I should rewrite the SRE core again, to get rid of those last glitches... From Fredrik Lundh" Message-ID: <038601bfe2bf$31c52da0$f2a6b5d4@hagrid> > test_re still fails, but this time with >=20 > test test_re failed -- Writing: '=3D=3D=3D Failed incorrectly', = expected: "('abc', 'abc', 0, 'fou" note that test_re should fail; someone (me?) needs to regenerate the output file. the rest looks a bit scary, to say the least. does someone (sre?) overwrite something? does anyone have purify (dmalloc, fences, whatever) within reach? From Vladimir.Marangozov@inrialpes.fr Fri Jun 30 19:22:03 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Fri, 30 Jun 2000 20:22:03 +0200 (CEST) Subject: [Python-Dev] Odd behavior with `make test' In-Reply-To: <14684.57622.9807.868551@anthem.concentric.net> from "Barry A. Warsaw" at Jun 30, 2000 02:04:06 PM Message-ID: <200006301822.UAA22606@python.inrialpes.fr> Barry A. Warsaw wrote: > > make test is behaving strangely. The first time I ran it I got On which platform? Linux seems to do fine with most of this. On AIX (after some hacking related to my previous msg "Oops on AIX", I managed to compile everything but I'll dump an error log on Trent :-) > > test test_mmap crashed -- exceptions.SyntaxError : inconsistent use of tabs and spaces in indentation same here > test test_sre failed -- sre.search > ... > test test_re failed -- re.search > ... > test test_strftime crashed -- exceptions.AttributeError : match > test test_tokenize crashed -- exceptions.AttributeError : compile > test test_xmllib crashed -- exceptions.AttributeError : compile same here. I believe Guido & al. are aware as per the checkin msg, saying that /F promises to fix this. But on AIX I get in addition to the above failures: test test_array failed -- array('b') overflowed assigning -128L -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From tpeters@beopen.com Fri Jun 30 19:20:46 2000 From: tpeters@beopen.com (Tim Peters) Date: Fri, 30 Jun 2000 14:20:46 -0400 Subject: [Python-Dev] SRE incompatibility In-Reply-To: <032701bfe2bc$23da47a0$f2a6b5d4@hagrid> Message-ID: [Tim] > I vote for backward compatibility for now, and not only because > that will irritate /F the most. [/F] > backward compatibility with what? 1.5.2. > 8-bit string literals At least, because they were in 1.5.2. > or unicode string literals? I'm sorry \x escapes are even allowed in those -- \x notation is a gimmick for making strings hold arbitrary binary data, which we're trying to get away from. To the extent that they make any sense at all in Unicode strings, \u should be used instead. > the problem here is that the pattern is compiled once (from either > 8-bit or unicode strings), and can then be used on either 8-bit or > unicode targets. to be fully backwards compatible, this means that > the compiler should use 8 bits, no matter what string type you're > using. Unicode strings weren't in 1.5.2, so there can't possibly be a backwards compatibility issue with them -- at least not in the sense I'm using the phrase here. > another solution would be to use the type of the pattern string to > choose between 8 and 16 bits. I almost implemented that, before > I realized that it broke the following rather nice property: > > sre.compile("some pattern") == sre.compile(u"some pattern") > > (well, the pattern type doesn't implement __cmp__, but you get the > idea). the current implementation guarantees "==", but I'm planning > to change that to "is" (!). Do you mean that, e.g., sre.compile("\u0045") == sre.compile(u"\u0045") too? If so, that doesn't make any sense to me (interpreting \u in 8-bit strings is even more confused than interpreting \x in Unicode strings). But if you didn't mean to include this case, then the equality doesn't actually hold now, so there's nothing to preserve . > anyway, I suspect it's too late to change this in 2.0b1. if enough > people complain about this, we can always label it a "critical bug", > and do something about it in b2. I think the real problem here was MAL's generalization of \x to 2-byte stuff in Unicode strings. If Unicode strings *have* to support \x, then \x0123456789abcdef in Unicode strings should act like \u00ef in Unicode strings, and SRE should play along with that too. \x was broken to begin with; better to wipe it out than try to generalize it. OTOH, I didn't get much sleep last night <0.8 wink>. From Fredrik Lundh" Message-ID: <03ae01bfe2c1$30be3300$f2a6b5d4@hagrid> > > test test_sre failed -- sre.search > > ... > > test test_re failed -- re.search > > ... > > test test_strftime crashed -- exceptions.AttributeError : match > > test test_tokenize crashed -- exceptions.AttributeError : compile > > test test_xmllib crashed -- exceptions.AttributeError : compile >=20 > same here. I believe Guido & al. are aware as per the checkin msg, > saying that /F promises to fix this. I have no idea what causes this. however, I just noticed that evil tabs had snucked their way into sre_parse and sre_compile. new, properly untabified versions are on their way to the repository. maybe the interpreter messes up badly once -tt has reported an error? try removing -tt from the TESTPYTHON line in the makefile, and see what happens. From gward@mems-exchange.org Fri Jun 30 19:26:51 2000 From: gward@mems-exchange.org (Greg Ward) Date: Fri, 30 Jun 2000 14:26:51 -0400 Subject: [Python-Dev] Hey! who changed sys.platform?! In-Reply-To: <14684.45307.983394.125671@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Fri, Jun 30, 2000 at 10:38:51AM -0400 References: <20000629233003.A1766@beelzebub> <14684.5401.518766.362678@cj42289-a.reston1.va.home.com> <395C681D.C3211F6@lemburg.com> <14684.41320.38954.833643@cj42289-a.reston1.va.home.com> <395CA354.16AC5B7E@lemburg.com> <200006301455.JAA30721@cj20424-a.reston1.va.home.com> <395CAAAA.5975A617@lemburg.com> <20000630102242.B16350@ludwig.cnri.reston.va.us> <14684.45307.983394.125671@cj42289-a.reston1.va.home.com> Message-ID: <20000630142650.B16028@ludwig.cnri.reston.va.us> On 30 June 2000, Fred L. Drake, Jr. said: > Why would you need to figure this out? Are you selecting a > platform-specific packaging system automatically? In that case, I'd > search for the presence of the tools rather than asking what sort of > distribution you're running on -- several distros use RPM, a few use > .deb packages, etc. When the user specifies one on the command line, > just use the one they name and be done with it. Currently it's up to the user to decide which kind of built distribution they want, with stupid defaults: dumb tarball for Unix, dumb ZIP file for Windows. If you want an RPM or a Windows installer, you have to say so explicitly. This is not a big deal, but it might be nice to detect automatically if we can build (say) RPMs and do so. This is not a high-priority feature, though. I'll accept a patch if someone out there is interested enough to implement it. Greg From Fredrik Lundh" Message-ID: <03ce01bfe2c2$38308560$f2a6b5d4@hagrid> tim wrote: > > to be fully backwards compatible, this means that the compiler > > should use 8 bits, no matter what string type you're using. ... > I think the real problem here was MAL's generalization of \x to 2-byte = stuff > in Unicode strings. If Unicode strings *have* to support \x, then >=20 > \x0123456789abcdef >=20 > in Unicode strings should act like >=20 > \u00ef >=20 > in Unicode strings, and SRE should play along with that too. \x was = broken > to begin with; better to wipe it out than try to generalize it. I think this means that we agree -- \x is a wart that can only be used to embed *binary bytes* in a string. From Vladimir.Marangozov@inrialpes.fr Fri Jun 30 19:37:35 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Fri, 30 Jun 2000 20:37:35 +0200 (CEST) Subject: [Python-Dev] Odd behavior with `make test' In-Reply-To: <03ae01bfe2c1$30be3300$f2a6b5d4@hagrid> from "Fredrik Lundh" at Jun 30, 2000 08:29:54 PM Message-ID: <200006301837.UAA22688@python.inrialpes.fr> Fredrik Lundh wrote: > > maybe the interpreter messes up badly once -tt has reported an > error? try removing -tt from the TESTPYTHON line in the makefile, > and see what happens. Matches Barry's report exactly. To which I'll add the array('b') failure which is not due to an optimization of arraymodule.c. Will investigate this tonight. -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From DavidA@ActiveState.com Fri Jun 30 19:43:14 2000 From: DavidA@ActiveState.com (David Ascher) Date: Fri, 30 Jun 2000 11:43:14 -0700 Subject: [Python-Dev] Hey! who changed sys.platform?! In-Reply-To: <200006301455.JAA30721@cj20424-a.reston1.va.home.com> Message-ID: > But I vote -1 on this one anyway -- it's too much code and almost by > its very nature not something that belongs in a "standard" library. > Plus, I don't want to be responsible for maintaining it. Sorry, > > --Guido van Rossum (home page: http://www.python.org/~guido/) Not that I hope to override the heavy -1, but I don't agree with the second point. It embodies a huge amount of knowledge that is needed to write portable code. As such, IMO, it _does_ belong in the standard library. How is it different in its nature from sys.platform, which is only a much weaker version of the same concept? --david From skip@mojam.com (Skip Montanaro) Fri Jun 30 18:35:20 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Fri, 30 Jun 2000 12:35:20 -0500 (CDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Misc COPYRIGHT,1.4,1.5 In-Reply-To: <200006301841.LAA20523@slayer.i.sourceforge.net> References: <200006301841.LAA20523@slayer.i.sourceforge.net> Message-ID: <14684.55896.890339.982232@beluga.mojam.com> Fred> The new copyright / license. ... Fred> ! ... IN NO EVENT SHALL THE REGENTS OR Fred> ! CONTRIBUTORS BE LIABLE FOR ... Who are the "regents" and the "contributors"? Should those terms be defined somewhere? not-a-lawyer-and-never-wanted-to-be-ly y'rs, -- Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille O'Neal said: "He's got the rings. I listen to the man with the rings." From nascheme@enme.ucalgary.ca Fri Jun 30 19:53:06 2000 From: nascheme@enme.ucalgary.ca (Neil Schemenauer) Date: Fri, 30 Jun 2000 12:53:06 -0600 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test/output test_gc,NONE,1.1 In-Reply-To: <14684.7005.661874.713000@beluga.mojam.com>; from skip@mojam.com on Thu, Jun 29, 2000 at 11:00:29PM -0500 References: <200006300502.WAA03286@slayer.i.sourceforge.net> <14684.7005.661874.713000@beluga.mojam.com> Message-ID: <20000630125306.B32568@acs.ucalgary.ca> --AqsLC8rIMeq19msA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Jun 29, 2000 at 11:00:29PM -0500, Skip Montanaro wrote: > I can all but guarantee you this test will always fail. Printing absolute > machine addresses (via calls to id() in this case) in test cases should be > verboten. This test script should be better. It doesn't generate any output (the stuff the old script printed was pretty useless anyhow). Neil --AqsLC8rIMeq19msA Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="test_gc.py" import gc from test_support import * def test_list(): l = [] l.append(l) gc.collect() del l assert gc.collect() == 1 def test_dict(): d = {} d[1] = d gc.collect() del d assert gc.collect() == 1 def test_tuple(): l = [] t = (l,) l.append(t) gc.collect() del t del l assert gc.collect() == 2 def test_class(): class A: pass A.a = A gc.collect() del A assert gc.collect() > 0 def test_instance(): class A: pass a = A() a.a = a gc.collect() del a assert gc.collect() > 0 def test_method(): class A: def __init__(self): self.init = self.__init__ a = A() gc.collect() del a assert gc.collect() > 0 def test_finalizer(): class A: def __del__(self): pass class B: pass a = A() a.a = a id_a = id(a) b = B() b.b = b gc.collect() del a del b assert gc.collect() > 0 for obj in gc.garbage: if id(obj) == id_a: return raise TestFailed def test_function(): d = {} exec("def f(): pass\n") in d gc.collect() del d assert gc.collect() > 0 def test_all(): threshold = gc.get_threshold() gc.set_threshold(0) # disable automatic collection gc.collect() test_list() test_dict() test_tuple() test_class() test_instance() test_method() test_finalizer() test_function() apply(gc.set_threshold, threshold) test_all() --AqsLC8rIMeq19msA-- From tpeters@beopen.com Fri Jun 30 19:51:59 2000 From: tpeters@beopen.com (Tim Peters) Date: Fri, 30 Jun 2000 14:51:59 -0400 Subject: [Python-Dev] SRE incompatibility In-Reply-To: <03ce01bfe2c2$38308560$f2a6b5d4@hagrid> Message-ID: [/F] > I think this means that we agree -- \x is a wart that can only > be used to embed *binary bytes* in a string. We certainly agree about that part! I thought my > I'm sorry \x escapes are even allowed in [u-strings] -- \x notation > is a gimmick for making strings hold arbitrary binary data, which > we're trying to get away from. To the extent that they make any > sense at all in Unicode strings, \u should be used instead. was pretty explicit . What we may still disagree on is how SRE should deal with the \x mess. I'm in favor of making \x mean "just the last byte" in plain and Unicode strings -- do the least harm with this (mis)feature. Making \x mean anything other than that for plain strings, regardless of context, is not backward compatible (with 1.5.2). And since Unicode strings haven't been released yet, it's not too late to change what they do with \x. That would make SRE's job clear here, yes? And in a way that allows the now-failing test to pass again? From skip@mojam.com (Skip Montanaro) Fri Jun 30 18:43:21 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Fri, 30 Jun 2000 12:43:21 -0500 (CDT) Subject: [Python-Dev] "make test" vs. "-tt" Message-ID: <14684.56377.293211.329273@beluga.mojam.com> Per Fredrik's suggestion, I changed "-tt" to simply "-t". I've not yet done a "cvs update" to grab the tab-corrected versions of whatever files were causing the indigestion. I'm down to a single test failure (test_re) now when running "make test" before .py[co] files have been created. I noticed a couple warnings when test_mmap was running though: ./Lib/sre_compile.py: inconsistent tab/space usage ./Lib/sre_parse.py: inconsistent tab/space usage Could it be that when "-tt" detects a problem it causes a broken .py[co] file to be generated? -- Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille O'Neal said: "He's got the rings. I listen to the man with the rings." From DavidA@ActiveState.com Fri Jun 30 19:58:20 2000 From: DavidA@ActiveState.com (David Ascher) Date: Fri, 30 Jun 2000 11:58:20 -0700 Subject: [Python-Dev] New PythonLabs site revealed! In-Reply-To: <14684.42843.472230.609828@anthem.concentric.net> Message-ID: > That's a good point. A bump in major rev number is an /opportunity/ > to break things, like a bone that hasn't healed right, so that they > can be fixed correctly. We'll lose that for 2.0, mostly likely > because of the tight release schedule. Yes, I find that frustrating. The story for months (years?) has been that we don't break things because it's a 'dot-release', and so we've shelved improvements left and right. Now we don't have time to do those things even when it _is_ a major release. Some advance notice would have been nice. --david From fdrake@beopen.com Fri Jun 30 20:05:42 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Fri, 30 Jun 2000 15:05:42 -0400 (EDT) Subject: [Python-Dev] New PythonLabs site revealed! In-Reply-To: References: <14684.42843.472230.609828@anthem.concentric.net> Message-ID: <14684.61318.668529.402341@cj42289-a.reston1.va.home.com> David Ascher writes: > Yes, I find that frustrating. The story for months (years?) has been that > we don't break things because it's a 'dot-release', and so we've shelved > improvements left and right. Now we don't have time to do those things even > when it _is_ a major release. > > Some advance notice would have been nice. I agree, but this was news to at least some of us even Wednesday. The upside is that major releases are more likely to happen now that the precedent has been set. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tpeters@beopen.com Fri Jun 30 20:06:04 2000 From: tpeters@beopen.com (Tim Peters) Date: Fri, 30 Jun 2000 15:06:04 -0400 Subject: [Python-Dev] New PythonLabs site revealed! In-Reply-To: Message-ID: [David Ascher, wishing he had had the opportunity to break things with 2.0] > ... > Some advance notice would have been nice. David, it would have been nice for us too <0.3 wink>. we're-not-keeping-secrets-we're-just-another-thrashing-startup-ly y'rs - tim From nascheme@enme.ucalgary.ca Fri Jun 30 20:50:52 2000 From: nascheme@enme.ucalgary.ca (Neil Schemenauer) Date: Fri, 30 Jun 2000 13:50:52 -0600 Subject: [Python-Dev] Windows build issues Message-ID: <20000630135052.A405@acs.ucalgary.ca> A couple of things: PCbuild/readme.txt Should be updated for the new release. PC/config.h VC++ 5.0 will not compile python20 unless "#include " is commented out. Trent? WITH_CYCLE_GC should be uncommented if we want to have GC enabled in the beta. PCbuild/python20.dsp Line endings seem to be incorrect. Someone probably edited the file on a Unix machine and munched things up. VC++ 5.0 likes DOS line endings otherwise it refuses to load the project. Also, I get a few warnings when compiling. One is about an /IZ (I think) option being ignored. There are a few other warnings as well which I didn't write down. Neil From Fredrik Lundh" Message-ID: <03f501bfe2cc$cf5dcce0$f2a6b5d4@hagrid> tim wrote: > That would make SRE's job clear here, yes? And in a way that allows = the > now-failing test to pass again? sure. quoting from python-checkins: RCS file: /cvsroot/python/python/dist/src/Lib/test/output/test_sre,v ... test_sre - =3D=3D=3D Failed incorrectly ('\\x00ffffffffffffff', '\377', 0, = 'found', '\377') =3D=3D=3D Failed incorrectly ('^(.+)?B', 'AB', 0, 'g1', 'A') ... still messes up on nested repetitions, but that's entirely different problem... From fdrake@beopen.com Fri Jun 30 21:23:35 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Fri, 30 Jun 2000 16:23:35 -0400 (EDT) Subject: [Python-Dev] 2.0b1 documentation online Message-ID: <14685.455.115147.446238@cj42289-a.reston1.va.home.com> See it at: http://www.python.org/doc/devel/ -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido@python.org Fri Jun 30 22:23:09 2000 From: guido@python.org (Guido van Rossum) Date: Fri, 30 Jun 2000 16:23:09 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Misc COPYRIGHT,1.4,1.5 In-Reply-To: Your message of "Fri, 30 Jun 2000 12:35:20 EST." <14684.55896.890339.982232@beluga.mojam.com> References: <200006301841.LAA20523@slayer.i.sourceforge.net> <14684.55896.890339.982232@beluga.mojam.com> Message-ID: <200006302123.QAA20537@cj20424-a.reston1.va.home.com> > Fred> The new copyright / license. > ... > Fred> ! ... IN NO EVENT SHALL THE REGENTS OR > Fred> ! CONTRIBUTORS BE LIABLE FOR ... > > Who are the "regents" and the "contributors"? Should those terms be > defined somewhere? Oops. I thought I caught all the regents and replaced them with a more politically correct term. Seems one got away. Fixed now. > not-a-lawyer-and-never-wanted-to-be-ly y'rs, Ditto, --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Fri Jun 30 22:26:21 2000 From: guido@python.org (Guido van Rossum) Date: Fri, 30 Jun 2000 16:26:21 -0500 Subject: [Python-Dev] New PythonLabs site revealed! In-Reply-To: Your message of "Fri, 30 Jun 2000 11:58:20 MST." References: Message-ID: <200006302126.QAA20621@cj20424-a.reston1.va.home.com> > > That's a good point. A bump in major rev number is an /opportunity/ > > to break things, like a bone that hasn't healed right, so that they > > can be fixed correctly. We'll lose that for 2.0, mostly likely > > because of the tight release schedule. [David Ascher] > Yes, I find that frustrating. The story for months (years?) has been that > we don't break things because it's a 'dot-release', and so we've shelved > improvements left and right. Now we don't have time to do those things even > when it _is_ a major release. You have no idea how frustration it is for me! But sometimes the marketing people force us engineers to act quickly. Just be glad I'm not following the release schedule that they had *wanted* me to use... :-) > Some advance notice would have been nice. Same here. :-) --Guido van Rossum (home page: http://www.python.org/~guido/) From nascheme@enme.ucalgary.ca Fri Jun 30 21:31:48 2000 From: nascheme@enme.ucalgary.ca (Neil Schemenauer) Date: Fri, 30 Jun 2000 14:31:48 -0600 Subject: [Python-Dev] Idle breakage Message-ID: <20000630143148.A9725@acs.ucalgary.ca> Caused by _sre perhaps? $ python Tools/idle/idle.py Traceback (most recent call last): File "Tools/idle/idle.py", line 8, in ? IdleConf.load(idle_dir) File "Tools/idle/IdleConf.py", line 109, in load idleconf.read((os.path.join(dir, "config.txt"), genplatfile, platfile, File "/usr/local/lib/python2.0/ConfigParser.py", line 207, in read self.__read(fp, filename) File "/usr/local/lib/python2.0/ConfigParser.py", line 382, in __read raise e ConfigParser.ParsingError: File contains parsing errors: Tools/idle/config.txt [line 21]: 'width= 80\012' [line 22]: 'height= 24\012' [line 26]: 'normal-foreground= black\012' [line 27]: 'normal-background= white\012' [line 29]: 'keyword-foreground= #ff7700\012' [line 30]: 'comment-foreground= #dd0000\012' [line 31]: 'string-foreground= #00aa00\012' [line 32]: 'definition-foreground= #0000ff\012' [line 33]: 'hilite-foreground= #000068\012' [line 34]: 'hilite-background= #006868\012' [line 35]: 'break-foreground= #ff7777\012' [line 36]: 'hit-foreground= #ffffff\012' [line 37]: 'hit-background= #000000\012' [line 38]: 'stdout-foreground= blue\012' [line 39]: 'stderr-foreground= red\012' [line 40]: 'console-foreground= #770000\012' [line 41]: 'error-background= #ff7777\012' [line 42]: 'cursor-background= black\012' [line 59]: 'enable= 0\012' [line 60]: 'style= expression\012' [line 61]: 'flash-delay= 500\012' [line 62]: 'bell= 1\012' [line 63]: 'hilite-foreground= black\012' [line 64]: 'hilite-background= #43cd80\012' From jeremy@beopen.com Fri Jun 30 21:33:01 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Fri, 30 Jun 2000 16:33:01 -0400 (EDT) Subject: [Python-Dev] New PythonLabs site revealed! In-Reply-To: <200006302126.QAA20621@cj20424-a.reston1.va.home.com> References: <200006302126.QAA20621@cj20424-a.reston1.va.home.com> Message-ID: <14685.1021.870885.796187@bitdiddle.concentric.net> >>>>> "GvR" == Guido van Rossum writes: >> That's a good point. A bump in major rev number is an >> /opportunity/ to break things, like a bone that hasn't healed >> right, so that they can be fixed correctly. We'll lose that >> for 2.0, mostly likely because of the tight release schedule. GvR> [David Ascher] >> Yes, I find that frustrating. The story for months (years?) has >> been that we don't break things because it's a 'dot-release', and >> so we've shelved improvements left and right. Now we don't have >> time to do those things even when it _is_ a major release. GvR> You have no idea how frustration it is for me! But sometimes GvR> the marketing people force us engineers to act quickly. Just GvR> be glad I'm not following the release schedule that they had GvR> *wanted* me to use... :-) Perhaps I am too easy-going, but I consider the 2.0 release a 'dot-release' masquerading as a major revision. It might be a little silly, but it seems even sillier to preserve a naming scheme that makes users think that the technology is immature. Jeremy From guido@python.org Fri Jun 30 22:33:52 2000 From: guido@python.org (Guido van Rossum) Date: Fri, 30 Jun 2000 16:33:52 -0500 Subject: [Python-Dev] Windows build issues In-Reply-To: Your message of "Fri, 30 Jun 2000 13:50:52 CST." <20000630135052.A405@acs.ucalgary.ca> References: <20000630135052.A405@acs.ucalgary.ca> Message-ID: <200006302133.QAA20696@cj20424-a.reston1.va.home.com> > A couple of things: > > PCbuild/readme.txt > > Should be updated for the new release. Tim will do this. > PC/config.h > > VC++ 5.0 will not compile python20 unless "#include > " is commented out. Trent? I'll leave this to Trent -- I don't know how to check for VC 5.0 vs. 6.0. > WITH_CYCLE_GC should be uncommented if we want to have GC > enabled in the beta. Done. > PCbuild/python20.dsp > > Line endings seem to be incorrect. Someone probably edited > the file on a Unix machine and munched things up. VC++ 5.0 > likes DOS line endings otherwise it refuses to load the > project. There was one missing CR. Fixed now. > Also, I get a few warnings when compiling. One is about an /IZ > (I think) option being ignored. There are a few other warnings > as well which I didn't write down. Probably 6.0 flags that 5.0 doesn't have. What can we do? --Guido van Rossum (home page: http://www.python.org/~guido/) From nascheme@enme.ucalgary.ca Fri Jun 30 21:40:21 2000 From: nascheme@enme.ucalgary.ca (Neil Schemenauer) Date: Fri, 30 Jun 2000 14:40:21 -0600 Subject: [Python-Dev] Idle breakage In-Reply-To: <20000630143148.A9725@acs.ucalgary.ca>; from nascheme@enme.ucalgary.ca on Fri, Jun 30, 2000 at 02:31:48PM -0600 References: <20000630143148.A9725@acs.ucalgary.ca> Message-ID: <20000630144021.A9847@acs.ucalgary.ca> Changing to pre fixes the problem. Neil From mwh21@cam.ac.uk Fri Jun 30 21:50:37 2000 From: mwh21@cam.ac.uk (Michael Hudson) Date: 30 Jun 2000 21:50:37 +0100 Subject: [Python-Dev] Re: Test results of linuxaudiodev.c In-Reply-To: Ka-Ping Yee's message of "Thu, 29 Jun 2000 17:44:35 -0700 (PDT)" References: Message-ID: To python-dev: Sorry for the hiatus. To python-list: does someone who knows about audio and can run linux want to play with this (Ping and I fall into just one of these categories each!). Ka-Ping Yee writes: > On 30 Jun 2000, Michael Hudson wrote: > > Yup, that works fine. Don't understand the details - and as I have my > > graduation ceremony tomorrow I'm going to go to bed and leave learning > > them until some other occasion! > > Cool. > > Okay, i just discovered sunau.py. Here's my real shot at > test_linuxaudiodev.py. Can you give this a try? > > > ---- test_linuxaudiodev.py ---- > from test_support import verbose, findfile, TestFailed > import linuxaudiodev > import os, sunau > > formats = {("ULAW", 1): linuxaudiodev.AFMT_MU_LAW, > ("NONE", 1): linuxaudiodev.AFMT_S8, > ("NONE", 2): linuxaudiodev.AFMT_S16_BE} > > def play_au_file(path): > au = sunau.open(path, "r") > data = au.readframes(sunau.AUDIO_UNKNOWN_SIZE) > au.close() > > spec = (au.getcomptype(), au.getsampwidth()) > if not has_key(formats, spec): ^^^^^^^ Oops? > raise "audio format not supported by linuxaudiodev" Maybe you mean: raise TestFailed, "audio format not supported by linuxaudiodev" ? I thought string exceptions were deprecated... > dsp = linuxaudiodev.open("w") > dsp.setparameters(au.getframerate(), au.getsampwidth() * 8, > au.getnchannels(), formats[spec]) > dsp.write(data) > dsp.close() > > def test(): > play_au_file(findfile('audiotest.au')) > > test() This doesn't work. I don't really understand why. For audiotest.au, |spec| is ("ULAW",2), which I don't think is right; file(1) says audiotest.au: Sun/NeXT audio data: 8-bit ISDN u-law, mono, 8000 Hz So I think this could be a bug in sunau. The other data (au.getframerate(), au.getnchannels()) agrees with file(1). Anybody have a better idea? Cheers, Michael Hudson, BA (as of today! woohoo!) From jeremy@beopen.com Fri Jun 30 21:57:44 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Fri, 30 Jun 2000 16:57:44 -0400 (EDT) Subject: [Python-Dev] last minute GC questions Message-ID: <14685.2504.722378.79294@bitdiddle.concentric.net> I've got two last minute questions. Does it look to you like I checked in all of the changes that you and Vladimir discussed? Might we change the strategy for deciding when to collect? There are two parts of the strategy that could probably change. The first is what kind of allocation events we count to determine when to collect. Right now, the gc is counting the net effect of allocations and deallocations. This isn't effective for at least a couple of cases. If we allocate N objects and don't deallocate anything, then no garbage is going to be created. If we have many objects currently allocated and then dealloc N objects without allocating any, we could create collectible garbage, but the collector won't run because there haven't been any allocations. It seems to me that counting deallocations only would be more effective. It is only the deallocations that cause a live object to become garbage. The other part of the strategy that might be changed is the collection frequency. Right now, the threshold is 100 net allocations & dealloactions. On the compiler benchmark, this leads to some 2600 collections, which seems like a lot. (I have no idea why it seems like a lot, but it does.) I experimented with a policy that runs the collected every N deallocations (not counting deallocations the occur during a collection). I set N == 1000 and got 1600 collections on the compiler benchmark. There is only a small speedup (just a few percent), so maybe this change doesn't have a big effect. I don't recall much about the cost/complexity of various GC approaches. Jeremy From nascheme@enme.ucalgary.ca Fri Jun 30 22:12:06 2000 From: nascheme@enme.ucalgary.ca (Neil Schemenauer) Date: Fri, 30 Jun 2000 15:12:06 -0600 Subject: [Python-Dev] Re: last minute GC questions In-Reply-To: <14685.2504.722378.79294@bitdiddle.concentric.net>; from jeremy@beopen.com on Fri, Jun 30, 2000 at 04:57:44PM -0400 References: <14685.2504.722378.79294@bitdiddle.concentric.net> Message-ID: <20000630151206.A10333@acs.ucalgary.ca> On Fri, Jun 30, 2000 at 04:57:44PM -0400, Jeremy Hylton wrote: > I've got two last minute questions. > > Does it look to you like I checked in all of the changes that you and > Vladimir discussed? Nope. Neil Index: 0.13/Include/objimpl.h *** 0.13/Include/objimpl.h Fri, 30 Jun 2000 13:05:40 -0600 nas (python/o/19_objimpl.h 1.1.2.1.2.1.2.1 644) --- 0.13(w)/Include/objimpl.h Fri, 30 Jun 2000 15:09:51 -0600 nas (python/o/19_objimpl.h 1.1.2.1.2.1.2.1 644) *************** *** 204,209 **** --- 204,211 ---- (PyVarObject *) PyObject_MALLOC( _PyObject_VAR_SIZE((typeobj),(n)) ),\ (typeobj), (n)) ) + #define PyObject_DEL(op) PyObject_FREE(op) + /* This example code implements an object constructor with a custom allocator, where PyObject_New is inlined, and shows the important distinction between two steps (at least): *************** *** 242,248 **** PyObject_{New, VarNew, Del} to manage the memory. Set the type flag Py_TPFLAGS_GC and define the type method tp_recurse. You should also add the method tp_clear if your object is mutable. Include ! PyGC_INFO_SIZE in the calculation of tp_basicsize. Call PyObject_GC_Init after the pointers followed by tp_recurse become valid (usually just before returning the object from the allocation method. Call PyObject_GC_Fini before those pointers become invalid --- 244,250 ---- PyObject_{New, VarNew, Del} to manage the memory. Set the type flag Py_TPFLAGS_GC and define the type method tp_recurse. You should also add the method tp_clear if your object is mutable. Include ! PyGC_HEAD_SIZE in the calculation of tp_basicsize. Call PyObject_GC_Init after the pointers followed by tp_recurse become valid (usually just before returning the object from the allocation method. Call PyObject_GC_Fini before those pointers become invalid *************** *** 255,261 **** #define PyObject_GC_Fini(op) #define PyObject_AS_GC(op) (op) #define PyObject_FROM_GC(op) (op) - #define PyObject_DEL(op) PyObject_FREE(op) #else --- 257,262 ---- *************** *** 289,295 **** /* Get the object given the PyGC_Head */ #define PyObject_FROM_GC(g) ((PyObject *)(((PyGC_Head *)g)+1)) ! #define PyObject_DEL(op) PyObject_FREE( PyObject_IS_GC(op) ? \ (ANY *)PyObject_AS_GC(op) : \ (ANY *)(op) ) --- 290,297 ---- /* Get the object given the PyGC_Head */ #define PyObject_FROM_GC(g) ((PyObject *)(((PyGC_Head *)g)+1)) ! #undef PyObject_DEL ! #define PyObject_DEL(op) PyObject_FREE( (op && PyObject_IS_GC(op)) ? \ (ANY *)PyObject_AS_GC(op) : \ (ANY *)(op) ) Index: 0.13/Objects/object.c *** 0.13/Objects/object.c Fri, 30 Jun 2000 13:05:40 -0600 nas (python/E/29_object.c 1.1.1.1.1.1.1.1.1.1.1.1 644) --- 0.13(w)/Objects/object.c Fri, 30 Jun 2000 15:05:26 -0600 nas (python/E/29_object.c 1.1.1.1.1.1.1.1.1.1.1.1 644) *************** *** 192,205 **** PyObject *op; { #ifdef WITH_CYCLE_GC ! if (PyType_IS_GC(op->ob_type)) { ! PyGC_Head *g = PyObject_AS_GC(op); ! PyObject_FREE(g); ! } else ! #endif ! { ! PyObject_FREE(op); } } #ifndef WITH_CYCLE_GC --- 192,202 ---- PyObject *op; { #ifdef WITH_CYCLE_GC ! if (op && PyType_IS_GC(op->ob_type)) { ! op = (PyObject *) PyObject_AS_GC(op); } + #endif + PyObject_FREE(op); } #ifndef WITH_CYCLE_GC From Fredrik Lundh" <200006302133.QAA20696@cj20424-a.reston1.va.home.com> Message-ID: <044b01bfe2d9$01dcee60$f2a6b5d4@hagrid> guido wrote: > > PC/config.h=20 > >=20 > > VC++ 5.0 will not compile python20 unless "#include > > " is commented out. Trent? >=20 > I'll leave this to Trent -- I don't know how to check for VC 5.0 > vs. 6.0. #if _MSC_VER >=3D 1200 VC 6.0 #else VC 5.0 or earlier =20 #endif (we added a similar workaround to Python/thread_nt.c) > > Also, I get a few warnings when compiling. One is about an /IZ > > (I think) option being ignored. There are a few other warnings > > as well which I didn't write down. >=20 > Probably 6.0 flags that 5.0 doesn't have. What can we do? ignore it, for now. I remember seeing a few type warnings, but nothing critical. there's plenty of time to sort that out on the way to 2.0 final. From Fredrik Lundh" Message-ID: <046a01bfe2d9$88302360$f2a6b5d4@hagrid> neil wrote: > Caused by _sre perhaps? >=20 > ConfigParser.ParsingError: File contains parsing errors: = Tools/idle/config.txt > [line 21]: 'width=3D 80\012' probably; I'll dig into this. when's the 2.0 deadline? From nascheme@enme.ucalgary.ca Fri Jun 30 22:30:08 2000 From: nascheme@enme.ucalgary.ca (Neil Schemenauer) Date: Fri, 30 Jun 2000 15:30:08 -0600 Subject: [Python-Dev] Fwd: Re: last minute GC questions Message-ID: <20000630153008.C10333@acs.ucalgary.ca> Oops, should have cc python-dev. ----- Forwarded message from Neil Schemenauer ----- Date: Fri, 30 Jun 2000 15:27:48 -0600 From: Neil Schemenauer Subject: Re: last minute GC questions To: Jeremy Hylton X-Url: http://www.enme.ucalgary.ca/~nascheme/ On Fri, Jun 30, 2000 at 04:57:44PM -0400, Jeremy Hylton wrote: > Might we change the strategy for deciding when to collect? We might. :) > It seems to me that counting deallocations only would be more > effective. It is only the deallocations that cause a live object to > become garbage. You can easily run out of memory with that strategy though: N = 10000 while 1: l = [] for i in xrange(N): l.append([]) l[0] = l You only get a couple of deallocations while a large amount of garbage is created. Think of large cyclic structures like graphs being created and then becoming garbage due to one deallocation. By counting the net new objects we guarantee that this doesn't happen. > The other part of the strategy that might be changed is the collection > frequency. Right now, the threshold is 100 net allocations & > dealloactions. On the compiler benchmark, this leads to some 2600 > collections, which seems like a lot. (I have no idea why it seems > like a lot, but it does.) Try setting the threshold to zero. The major part of the GC overhead does not seem to be running the collector. OTOH, the frequency could probably be decreased without the risk of running out of memory. No Python applications currently exist that create that amount of garbage anyhow. Neil ----- End forwarded message ----- From Fredrik Lundh" <046a01bfe2d9$88302360$f2a6b5d4@hagrid> Message-ID: <049601bfe2db$acea1380$f2a6b5d4@hagrid> I wrote: > > Caused by _sre perhaps? > >=20 > > ConfigParser.ParsingError: File contains parsing errors: = Tools/idle/config.txt > > [line 21]: 'width=3D 80\012' >=20 > probably; I'll dig into this. confirmed. SRE implements $ exactly as described in the library reference, RE doesn't ;-) patch coming within 30 minutes. From bwarsaw@beopen.com Fri Jun 30 22:57:19 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Fri, 30 Jun 2000 17:57:19 -0400 (EDT) Subject: [Python-Dev] Odd behavior with `make test' References: <14684.57622.9807.868551@anthem.concentric.net> <038601bfe2bf$31c52da0$f2a6b5d4@hagrid> Message-ID: <14685.6079.779817.674190@anthem.concentric.net> >>>>> "FL" == Fredrik Lundh writes: FL> the rest looks a bit scary, to say the least. does someone FL> (sre?) overwrite something? does anyone have purify (dmalloc, FL> fences, whatever) within reach? I will very soon. I found a Solaris box on which I could load up an eval copy of Purify. Will report back soon. -Barry From guido@python.org Fri Jun 30 23:57:45 2000 From: guido@python.org (Guido van Rossum) Date: Fri, 30 Jun 2000 17:57:45 -0500 Subject: [Python-Dev] Idle breakage In-Reply-To: Your message of "Fri, 30 Jun 2000 23:24:06 +0200." <046a01bfe2d9$88302360$f2a6b5d4@hagrid> References: <20000630143148.A9725@acs.ucalgary.ca> <046a01bfe2d9$88302360$f2a6b5d4@hagrid> Message-ID: <200006302257.RAA21104@cj20424-a.reston1.va.home.com> > when's the 2.0 deadline? In a couple of hours. --Guido van Rossum (home page: http://www.python.org/~guido/) From Fredrik Lundh" <046a01bfe2d9$88302360$f2a6b5d4@hagrid> <049601bfe2db$acea1380$f2a6b5d4@hagrid> <200006302302.SAA21232@cj20424-a.reston1.va.home.com> Message-ID: <04ca01bfe2e0$9ceea360$f2a6b5d4@hagrid> guido wrote: > > confirmed. SRE implements $ exactly as described in > > the library reference, RE doesn't ;-) >=20 > All this is done to match what Perl does. :-( guess we have to update the docs; I'll take care of that when I've recovered from all this... > emit(ATCODES[AT_MULTILINE[av]]) > KeyError: at_boundary sigh. with ~1000 patterns in my collection of test scripts, one could have hoped I'd seen it all. but that's a new one. patch coming within 30 minutes (when will I ever sleep?) From bwarsaw@beopen.com Fri Jun 30 23:15:34 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Fri, 30 Jun 2000 18:15:34 -0400 (EDT) Subject: [Python-Dev] Idle breakage References: <20000630143148.A9725@acs.ucalgary.ca> <046a01bfe2d9$88302360$f2a6b5d4@hagrid> <049601bfe2db$acea1380$f2a6b5d4@hagrid> <200006302302.SAA21232@cj20424-a.reston1.va.home.com> <04ca01bfe2e0$9ceea360$f2a6b5d4@hagrid> Message-ID: <14685.7174.668568.445940@anthem.concentric.net> >>>>> "FL" == Fredrik Lundh writes: FL> patch coming within 30 minutes (when will I ever sleep?) When WE say you can :) -Barry From DavidA@ActiveState.com Fri Jun 30 23:20:12 2000 From: DavidA@ActiveState.com (David Ascher) Date: Fri, 30 Jun 2000 15:20:12 -0700 Subject: [Python-Dev] Hey! who changed sys.platform?! In-Reply-To: <200006302314.SAA21371@cj20424-a.reston1.va.home.com> Message-ID: > > Not that I hope to override the heavy -1, but I don't agree > with the second > > point. It embodies a huge amount of knowledge that is needed to write > > portable code. As such, IMO, it _does_ belong in the standard > library. How > > is it different in its nature from sys.platform, which is only > a much weaker > > version of the same concept? > > A more subtle way of stating my opinion could be: if we were to do > something in the standard distribution about the problems that this is > addressing, I think we would do it in a much more direct fashion, > e.g. by making the appropriate enquiry functions directly accessible. > > --Guido van Rossum (home page: http://www.python.org/~guido/) I much prefer that answer, as it leaves the door open to a patch. I don't care about the implementation, just the feature. Thanks. --david From Fredrik Lundh" <046a01bfe2d9$88302360$f2a6b5d4@hagrid> <049601bfe2db$acea1380$f2a6b5d4@hagrid> <200006302302.SAA21232@cj20424-a.reston1.va.home.com> <04ca01bfe2e0$9ceea360$f2a6b5d4@hagrid> Message-ID: <050501bfe2e3$b2517680$f2a6b5d4@hagrid> > > KeyError: at_boundary >=20 > sigh. with ~1000 patterns in my collection of test scripts, > one could have hoped I'd seen it all. but that's a new one. umm. I'm not sure I want to check this one in. of all stupid bugs... I really gotta do something about that regression test suite. (don't worry, the patch is on its way. unfortunately, my setup is botched, so I cannot test drive IDLE myself. or to put it another way, I cannot guarantee that this is the last problem with IDLE+SRE...) From bwarsaw@beopen.com Fri Jun 30 23:37:20 2000 From: bwarsaw@beopen.com (Barry A. Warsaw) Date: Fri, 30 Jun 2000 18:37:20 -0400 (EDT) Subject: [Python-Dev] Idle breakage References: <20000630143148.A9725@acs.ucalgary.ca> <046a01bfe2d9$88302360$f2a6b5d4@hagrid> <049601bfe2db$acea1380$f2a6b5d4@hagrid> <200006302302.SAA21232@cj20424-a.reston1.va.home.com> <04ca01bfe2e0$9ceea360$f2a6b5d4@hagrid> <050501bfe2e3$b2517680$f2a6b5d4@hagrid> Message-ID: <14685.8480.389966.608982@anthem.concentric.net> >>>>> "FL" == Fredrik Lundh writes: FL> (don't worry, the patch is on its way. unfortunately, my FL> setup is botched, so I cannot test drive IDLE myself. or FL> to put it another way, I cannot guarantee that this is the FL> last problem with IDLE+SRE...) Go ahead and check it in. I'll run idle and see wot hoppens. -B From Vladimir.Marangozov@inrialpes.fr Fri Jun 30 23:46:37 2000 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Sat, 1 Jul 2000 00:46:37 +0200 (CEST) Subject: [Python-Dev] Oops on AIX In-Reply-To: <200006302310.SAA21344@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Jun 30, 2000 06:10:30 PM Message-ID: <200006302246.AAA23519@python.inrialpes.fr> Guido van Rossum wrote: > > let me suggest patches... If these work, please check them in: Yes, they do, thanks! (I can't check them in) There's one error left, occuring at two locations in the signalmodule, but I think the solution would be to have an appropriate cast: "./signalmodule.c", line 359.49: 1506-280 (E) Function argument assignment between types "void*" and "void(*)(int)" is not allowed. "./signalmodule.c", line 363.48: 1506-280 (E) Function argument assignment between types "void*" and "void(*)(int)" is not allowed. > > > xlc_r -O -I./../Include -I.. -DHAVE_CONFIG_H -c methodobject.c > > "methodobject.c", line 183.36: 1506-280 (E) Function argument assignment between types "void*" and "struct _object*(*)(struct _object*,struct _object*)" is not allowed. > > > Index: methodobject.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Objects/methodobject.c,v > retrieving revision 2.28 > diff -c -r2.28 methodobject.c > *** methodobject.c 2000/06/30 15:01:00 2.28 > --- methodobject.c 2000/06/30 22:09:55 > *************** > *** 180,186 **** > if (x == -1) > return -1; > } > ! y = _Py_HashPointer(a->m_ml->ml_meth); > if (y == -1) > return -1; > x ^= y; > --- 180,186 ---- > if (x == -1) > return -1; > } > ! y = _Py_HashPointer((void*)(a->m_ml->ml_meth)); > if (y == -1) > return -1; > x ^= y; > > > > > xlc_r -O -I./../Include -I.. -DHAVE_CONFIG_H -c ./posixmodule.c > > "./posixmodule.c", line 293.16: 1506-213 (S) Macro name STAT cannot be redefined. > > "./posixmodule.c", line 293.16: 1506-358 (I) "STAT" is defined on line 170 of /usr/include/sys/dir.h. > > make: 1254-004 The error code from the last command is 1. > > Index: posixmodule.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Modules/posixmodule.c,v > retrieving revision 2.138 > diff -c -r2.138 posixmodule.c > *** posixmodule.c 2000/06/29 21:12:41 2.138 > --- posixmodule.c 2000/06/30 22:10:39 > *************** > *** 285,290 **** > --- 285,291 ---- > #endif > > /* choose the appropriate stat and fstat functions and return structs */ > + #undef STAT > #ifdef MS_WIN64 > # define STAT _stati64 > # define FSTAT _fstati64 > > --Guido van Rossum (home page: http://www.python.org/~guido/) > -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From fdrake@beopen.com Fri Jun 30 23:46:18 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Fri, 30 Jun 2000 18:46:18 -0400 (EDT) Subject: [Python-Dev] Idle breakage In-Reply-To: <04ca01bfe2e0$9ceea360$f2a6b5d4@hagrid> References: <20000630143148.A9725@acs.ucalgary.ca> <046a01bfe2d9$88302360$f2a6b5d4@hagrid> <049601bfe2db$acea1380$f2a6b5d4@hagrid> <200006302302.SAA21232@cj20424-a.reston1.va.home.com> <04ca01bfe2e0$9ceea360$f2a6b5d4@hagrid> Message-ID: <14685.9018.355154.468866@cj42289-a.reston1.va.home.com> Fredrik Lundh writes: > guess we have to update the docs; I'll take care of that > when I've recovered from all this... The docs are frozen & published for this release, so next week is fine. ** THANKS! ** > patch coming within 30 minutes (when will I ever sleep?) You sleep??? -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From klm at digicool.com Thu Jun 1 00:03:31 2000 From: klm at digicool.com (Ken Manheimer) Date: Wed, 31 May 2000 18:03:31 -0400 (EDT) Subject: [Python-Dev] SIG: python-lang In-Reply-To: <643145F79272D211914B0020AFF640190BAA8F@gandalf.digicool.com> Message-ID: On Wed, 31 May 2000, Ka-Ping Yee wrote: > Hey, i admit it's a bit primitive, but it seems significantly > better than nothing. The software people at ILM have coped > with it fairly well for a year, and for the most part we like it. I'm not sure about the requirements - particularly, submissions and correspondence about bugs via email, which my zope "tracker" doesn't do - but the tracker may be worth looking at, also: http://www.zope.org/Members/klm/SoftwareCarpentry (See the prototype tracker, mentioned there, or my "tracker tracker" at http://www.zope.org/Members/klm/Tracker , for flagrant, embarrassing exposure of the outstanding tracker complaints...) (I haven't had the time to take care of the tracker as i would like, or to look at how tracker and roundup could inform eachother - but i haven't even gotten as far as examining that. I get the feeling they take fairly different approaches - which could mean neat synergy, or total disconnection. Ping, any thoughts?) Ken klm at digicool.com From fdrake at acm.org Thu Jun 1 00:17:02 2000 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Wed, 31 May 2000 18:17:02 -0400 (EDT) Subject: [Python-Dev] Adding LDAP to the Python core... ?! In-Reply-To: References: <14645.17446.749848.895965@anthem.python.org> Message-ID: <14645.36702.769794.807329@cj42289-a.reston1.va.home.com> Greg Stein writes: > My WebDAV module implements an established protocol (an RFC tends to do > that :-), but the API within the module is still in flux (IMO). I'd love to see this sort of thing added to the standard library, esp. once packages are used there. Especially if the implementation is pure Python (which I think your WebDAV stuff is, right?) > Is the LDAP module's API pretty solid? Is it changing? This I don't know. > And is this module a C extension, or a pure Python implementation? Mixed, I think. There is definately a C component. I'd rather it be pure Python, but I think it's a SWIGged wrapper around a C client library. Is anyone talking to the developer about this yet? -Fred -- Fred L. Drake, Jr. PythonLabs at BeOpen.com From gstein at lyra.org Thu Jun 1 00:27:04 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 31 May 2000 15:27:04 -0700 (PDT) Subject: [Python-Dev] Adding LDAP to the Python core... ?! In-Reply-To: <14645.36702.769794.807329@cj42289-a.reston1.va.home.com> Message-ID: On Wed, 31 May 2000, Fred L. Drake, Jr. wrote: > Greg Stein writes: > > My WebDAV module implements an established protocol (an RFC tends to do > > that :-), but the API within the module is still in flux (IMO). > > I'd love to see this sort of thing added to the standard library, > esp. once packages are used there. Especially if the implementation > is pure Python (which I think your WebDAV stuff is, right?) davlib.py is pure Python, building upon my upgraded httplib.py and xml.utils.qp_xml (and pyexpat) [ and recall my email last week that I've updated httplib.py and posted it to my web pages; it is awaiting review for integration into the Python core; it still needs docs and more testing scenarios, tho http://www.python.org/pipermail/python-dev/2000-May/005643.html ] davlib will probably be a 1.7 item. It still needs some heavy work to easily deal with authentication (which is usually going to be required for DAV operations). Cheers, -g -- Greg Stein, http://www.lyra.org/ From mhammond at skippinet.com.au Thu Jun 1 00:53:15 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Thu, 1 Jun 2000 08:53:15 +1000 Subject: [Python-Dev] SIG: python-lang In-Reply-To: Message-ID: [Ken writes] > I'm not sure about the requirements - particularly, submissions and > correspondence about bugs via email, which my zope "tracker" doesn't do - > but the tracker may be worth looking at, also: > > http://www.zope.org/Members/klm/SoftwareCarpentry > Another alternative could be Bugzilla: http://bugzilla.mozilla.org/ Sources at: http://www.mozilla.org/bugs/source.html Has many of the features people seem to want, and obviously supports large projects - which may be the biggest problem - it may be too "heavy" for our requirement... Mark. From fdrake at acm.org Thu Jun 1 03:30:28 2000 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Wed, 31 May 2000 21:30:28 -0400 (EDT) Subject: [Python-Dev] Adding LDAP to the Python core... ?! In-Reply-To: References: <14645.36702.769794.807329@cj42289-a.reston1.va.home.com> Message-ID: <14645.48308.347086.279280@cj42289-a.reston1.va.home.com> Greg Stein writes: > davlib.py is pure Python, building upon my upgraded httplib.py and > xml.utils.qp_xml (and pyexpat) So the dependencies are definately an issue. > [ and recall my email last week that I've updated httplib.py and posted it > to my web pages; it is awaiting review for integration into the Python > core; it still needs docs and more testing scenarios, tho > > http://www.python.org/pipermail/python-dev/2000-May/005643.html > ] Jeremy, were you looking at this? > davlib will probably be a 1.7 item. It still needs some heavy work to > easily deal with authentication (which is usually going to be required for Sounds good to me; let's take a look at it in 3 or 4 months. I'd hope to have at least preliminary reference documentation for review. -Fred -- Fred L. Drake, Jr. PythonLabs at BeOpen.com From skip at mojam.com Thu Jun 1 15:48:41 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 1 Jun 2000 08:48:41 -0500 (CDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Objects listobject.c,2.69,2.70 stringobject.c,2.65,2.66 tupleobject.c,2.33,2.34 In-Reply-To: <200006010312.UAA10844@slayer.i.sourceforge.net> References: <200006010312.UAA10844@slayer.i.sourceforge.net> Message-ID: <14646.27065.279988.93102@beluga.mojam.com> Fred> Log Message: Fred> Michael Hudson : Fred> Removed PyErr_BadArgument() calls and replaced them with more Fred> useful error messages. ... Fred> --- 389,395 ---- Fred> PyListObject *np; Fred> if (!PyList_Check(bb)) { Fred> ! PyErr_Format(PyExc_TypeError, Fred> ! "can only append list (not \"%.200s\") to list", Fred> ! bb->ob_type->tp_name); Fred> return NULL; Fred> } Fred> *************** ... I've seen this new error message cross my mailbox a few times. On the face of it, it's incorrect, because you can append any sort of object to a list, right? This message appears in the list_concat method. Shouldn't it be something like can't concatenate \"%.200s\" object with list ? I would consider this change very picky except for the fact that it's making a statement about the properties of lists that is clearly not true. -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ "We have become ... the stewards of life's continuity on earth. We did not ask for this role... We may not be suited to it, but here we are." - Stephen Jay Gould From fdrake at acm.org Thu Jun 1 16:29:17 2000 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Thu, 1 Jun 2000 10:29:17 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Objects listobject.c,2.69,2.70 stringobject.c,2.65,2.66 tupleobject.c,2.33,2.34 In-Reply-To: <14646.27065.279988.93102@beluga.mojam.com> References: <200006010312.UAA10844@slayer.i.sourceforge.net> <14646.27065.279988.93102@beluga.mojam.com> Message-ID: <14646.29501.378585.828457@cj42289-a.reston1.va.home.com> Skip Montanaro writes: > I've seen this new error message cross my mailbox a few times. On the face > of it, it's incorrect, because you can append any sort of object to a list, > right? This message appears in the list_concat method. Shouldn't it be > something like > > can't concatenate \"%.200s\" object with list Skip, You're right! How about: can only concatenate list (not \"%.200s\") to list If you don't object by the time this mail reaches you, I'll check it in. ;) -Fred -- Fred L. Drake, Jr. PythonLabs at BeOpen.com From mwh21 at cam.ac.uk Thu Jun 1 17:39:59 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: Thu, 1 Jun 2000 16:39:59 +0100 (BST) Subject: [Python-Dev] CVS: python/dist/src/Objects listobject.c,2.69,2.70 and friends In-Reply-To: <14646.29501.378585.828457@cj42289-a.reston1.va.home.com> Message-ID: On Thu, 1 Jun 2000, Fred L. Drake, Jr. wrote: > > Skip Montanaro writes: > > I've seen this new error message cross my mailbox a few times. On the face > > of it, it's incorrect, because you can append any sort of object to a list, > > right? This message appears in the list_concat method. Shouldn't it be > > something like > > > > can't concatenate \"%.200s\" object with list > > Skip, > You're right! How about: > > can only concatenate list (not \"%.200s\") to list > > If you don't object by the time this mail reaches you, I'll check it > in. ;) Then you'd better do something about tupleobject.c as well; I'd also say can only concatenate list (not \"%.200s\") and list can only concatenate tuple (not \"%.200s\") and tuple are slightly preferable, on reflection (note the s/to/and/). Cheers, Michael From andy at reportlab.com Thu Jun 1 18:23:36 2000 From: andy at reportlab.com (Andy Robinson) Date: Thu, 1 Jun 2000 17:23:36 +0100 Subject: [Python-Dev] SIG: python-lang Message-ID: It seems to me that the main problem is that comp.lang.python is too big to follow. So why not split it? I don't know the right subgroups, but if (say) comp.lang.python.language focusses on the core language, it might enable people to start reading it again. I asked this twice on c.l.p, one year ago and two years ago, and the answer was always "the traffic is too low". I used to subscribe to the NeXTSteap groups, and splitting worked really well there. - Andy Robinson From mal at lemburg.com Thu Jun 1 15:10:42 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 01 Jun 2000 15:10:42 +0200 Subject: [Python-Dev] Adding LDAP to the Python core... ?! References: Message-ID: <393660D2.4926E5C1@lemburg.com> Greg Stein wrote: > > On Wed, 31 May 2000, Barry A. Warsaw wrote: > > >>>>> "M" == M writes: > > > > M> Would there be interest in adding the python-ldap module > > M> (http://sourceforge.net/project/?group_id=2072) to the > > M> core distribution ? > > > > I haven't looked at this stuff, but yes, I think a standard LDAP > > module would be quite useful. It's a well enough established > > protocol, and it would be good to be able to count on it "being > > there". > > My WebDAV module implements an established protocol (an RFC tends to do > that :-), but the API within the module is still in flux (IMO). > > Is the LDAP module's API pretty solid? Is it changing? It is closing in on version 2.0 -- not sure how much it still changes. I just thought I'd query here before asking Daniel about his thoughts on including the module in the core (wouldn't make much sense if there was no interest). > And is this module a C extension, or a pure Python implementation? It's a Python module which uses a C wrapper to interface to OpenLDAP, which is a portable C lib dealing with all aspects of LDAP. There are at least two other projects built on top of python-ldap (see Parnassus for infos). I just thought I'd mention it here, because LDAP is certainly a widely used protocol in the corporate world and many decision makers have this on their list of buzz words. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gward at mems-exchange.org Thu Jun 1 23:01:41 2000 From: gward at mems-exchange.org (Greg Ward) Date: Thu, 1 Jun 2000 17:01:41 -0400 Subject: [Python-Dev] What's that sound? In-Reply-To: <393547A2.30CB7113@prescod.net>; from paul@prescod.net on Wed, May 31, 2000 at 12:10:58PM -0500 References: <39353CCD.1F3E9A0B@prescod.net> <14645.17611.318538.986772@anthem.python.org> <393547A2.30CB7113@prescod.net> Message-ID: <20000601170140.A24794@mems-exchange.org> On 31 May 2000, Paul Prescod said: > Look closer, big-egoed-four-stringed-guitar-playing-one. It could just > as easily be a J. > > And you know what you get when you put P and J together? Pajamas! Yes, that's right, when Python takes over the world, we'll all have to sleep BUCK NAKED!!! (What was that about "zero noise" on python-dev? Oh well, we must have our fun...) Greg From esr at snark.thyrsus.com Fri Jun 2 00:36:29 2000 From: esr at snark.thyrsus.com (Eric S. Raymond) Date: Thu, 1 Jun 2000 18:36:29 -0400 Subject: [Python-Dev] ascii.py? Message-ID: <200006012236.SAA03578@snark.thyrsus.com> There has been a vast and echoing silence about the ascii.py module I posted here at Fred Drake's request. Is it really such a bad idea? -- Eric S. Raymond "Those who make peaceful revolution impossible will make violent revolution inevitable." -- John F. Kennedy From pingster at ilm.com Fri Jun 2 00:33:19 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Thu, 1 Jun 2000 15:33:19 -0700 (PDT) Subject: [Python-Dev] ascii.py? In-Reply-To: <200006012236.SAA03578@snark.thyrsus.com> Message-ID: On Thu, 1 Jun 2000, Eric S. Raymond wrote: > There has been a vast and echoing silence about the ascii.py module I > posted here at Fred Drake's request. Is it really such a bad idea? Don't look at me. I'm busy working on inspect and htmldoc. :) Actually, i guess i probably didn't respond because it isn't of immediate use to me. Maybe this is the sort of thing that might come in handy one day but that hordes of people aren't desperate for. Hmm. Perhaps it's because people are used to saying "in string.digits" instead of wanting isdigit() &c. Hmm. Perhaps it's also something that ought to be eventually handled via the Unicode character property route. Dunno. -- ?!ng "China is a big country, inhabited by many Chinese." -- Former French President Charles de Gaulle From gstein at lyra.org Fri Jun 2 00:34:13 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 1 Jun 2000 15:34:13 -0700 (PDT) Subject: [Python-Dev] ascii.py? In-Reply-To: <200006012236.SAA03578@snark.thyrsus.com> Message-ID: On Thu, 1 Jun 2000, Eric S. Raymond wrote: > There has been a vast and echoing silence about the ascii.py module I > posted here at Fred Drake's request. Is it really such a bad idea? hehe... I'd say silence implies a +0 from people ("seems reasonable to go in, but I wouldn't be upset if it doesn't"). If people thought it was bad, then you'd hear about it :-) I took a quick look at it. Doesn't seem too bad, but I can't think of anything that I've done in a long while that would require it. So I can't really say "wow! put that baby in the distro!" YMMV, of course :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From esr at thyrsus.com Fri Jun 2 00:51:45 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 1 Jun 2000 18:51:45 -0400 Subject: [Python-Dev] ascii.py? In-Reply-To: ; from gstein@lyra.org on Thu, Jun 01, 2000 at 03:34:13PM -0700 References: <200006012236.SAA03578@snark.thyrsus.com> Message-ID: <20000601185145.A3667@thyrsus.com> Greg Stein : > I took a quick look at it. Doesn't seem too bad, but I can't think of > anything that I've done in a long while that would require it. So I can't > really say "wow! put that baby in the distro!" It starts to get pretty useful in conjunction with curses -- for example, in writing interpreters for character-at-a-time command loops. I have a new version that adds the following: \begin{funcdesc}{ascii}{c} Return the ASCII value corresponding to the low 7 bits of c. \end{funcdesc} The following function takes either a single-character string or integer byte value; it returns a string. \begin{funcdesc}{unctrl}{c} Return a string representation of the ASCII character c. If c is printable, this string is the character itself. If the character is a control character (0x00-0x1f) the string consists of a caret (^) followed by the corresponding uppercase letter. If the character is an ASCII delete (0x7f) the string is "^?". If the character has its meta bit (0x80) set, the meta bit is stripped, the preceding rules applied, and "!" prepended to the result. \end{funcdesc} Finally, the module supplies a 33-element string array called controlnames that contains the ASCII mnemonics for the thirty-two ASCII control characters from 0 (NUL) to 0x1f (US), in order, plus the mnemonic "SP" for space. -- Eric S. Raymond Certainly one of the chief guarantees of freedom under any government, no matter how popular and respected, is the right of the citizens to keep and bear arms. [...] the right of the citizens to bear arms is just one guarantee against arbitrary government and one more safeguard against a tyranny which now appears remote in America, but which historically has proved to be always possible. -- Hubert H. Humphrey, 1960 From akuchlin at cnri.reston.va.us Fri Jun 2 01:32:32 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Thu, 1 Jun 2000 19:32:32 -0400 Subject: [Python-Dev] ascii.py? In-Reply-To: <200006012236.SAA03578@snark.thyrsus.com>; from esr@snark.thyrsus.com on Thu, Jun 01, 2000 at 06:36:29PM -0400 References: <200006012236.SAA03578@snark.thyrsus.com> Message-ID: <20000601193232.A12831@newcnri.cnri.reston.va.us> On Thu, Jun 01, 2000 at 06:36:29PM -0400, Eric S. Raymond wrote: >There has been a vast and echoing silence about the ascii.py module I >posted here at Fred Drake's request. Is it really such a bad idea? One misgiving I had was locales; is it a bug or a feature that locales aren't supported, as they are for the C isdigit(), isalpha(), &c, functions? I'm not entirely sure which it is. (The locale module doesn't expose the C is*() functions, though I think they're used in constructing string.letters.) --amk From esr at thyrsus.com Fri Jun 2 01:45:11 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 1 Jun 2000 19:45:11 -0400 Subject: [Python-Dev] ascii.py? In-Reply-To: <20000601193232.A12831@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Thu, Jun 01, 2000 at 07:32:32PM -0400 References: <200006012236.SAA03578@snark.thyrsus.com> <20000601193232.A12831@newcnri.cnri.reston.va.us> Message-ID: <20000601194511.A3948@thyrsus.com> Andrew Kuchling : > On Thu, Jun 01, 2000 at 06:36:29PM -0400, Eric S. Raymond wrote: > >There has been a vast and echoing silence about the ascii.py module I > >posted here at Fred Drake's request. Is it really such a bad idea? > > One misgiving I had was locales; is it a bug or a feature that locales > aren't supported, as they are for the C isdigit(), isalpha(), &c, > functions? I'm not entirely sure which it is. (The locale module > doesn't expose the C is*() functions, though I think they're used in > constructing string.letters.) It's a feature. That's why this module is called ascii, not string :-) -- Eric S. Raymond "...quemadmodum gladius neminem occidit, occidentis telum est." [...a sword never kills anybody; it's a tool in the killer's hand.] -- (Lucius Annaeus) Seneca "the Younger" (ca. 4 BC-65 AD), From paul at prescod.net Fri Jun 2 05:53:41 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 01 Jun 2000 22:53:41 -0500 Subject: [Python-Dev] ascii.py? References: <200006012236.SAA03578@snark.thyrsus.com> Message-ID: <39372FC5.DE1CE8EA@prescod.net> "Eric S. Raymond" wrote: > > There has been a vast and echoing silence about the ascii.py module I > posted here at Fred Drake's request. Is it really such a bad idea? Without looking closely, or even being particularly knowledgable (how's that for a disclaimer!) my instinctive reaction was: "does the ASCII subset of Unicode need its own module just before we add Unicode to the language?" It may be that there are some semantics of ASCII that are not captured in the Unicode spec. and thus are not generalizable. I'm pretty confident that these ones ARE generalizable: isalnum isalpha isascii islower isupper isspace isxdigit How do Unicode users get this information from the famous Unicode database and why not merge the Unicode and ASCII versions in 1.6? -- Paul Prescod - ISOGEN Consulting Engineer speaking for himself Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From esr at thyrsus.com Fri Jun 2 07:43:54 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 2 Jun 2000 01:43:54 -0400 Subject: [Python-Dev] ascii.py? In-Reply-To: <39372FC5.DE1CE8EA@prescod.net>; from paul@prescod.net on Thu, Jun 01, 2000 at 10:53:41PM -0500 References: <200006012236.SAA03578@snark.thyrsus.com> <39372FC5.DE1CE8EA@prescod.net> Message-ID: <20000602014353.A5211@thyrsus.com> Paul Prescod : > "Eric S. Raymond" wrote: > > > > There has been a vast and echoing silence about the ascii.py module I > > posted here at Fred Drake's request. Is it really such a bad idea? > > Without looking closely, or even being particularly knowledgable (how's > that for a disclaimer!) my instinctive reaction was: "does the ASCII > subset of Unicode need its own module just before we add Unicode to the > language?" > > It may be that there are some semantics of ASCII that are not captured > in the Unicode spec. and thus are not generalizable. ascii.ctrl is one such. > I'm pretty > confident that these ones ARE generalizable: > > isalnum > isalpha > isascii > islower > isupper > isspace > isxdigit > > How do Unicode users get this information from the famous Unicode > database and why not merge the Unicode and ASCII versions in 1.6? Answer: ascii.py is not designed for text processing. I wrote it to package some functions useful for classifying *ASCII* data, especially in the context of roguelike programs that interpret keystrokes coming in through a curses interface. (Where this all touches ground is CML2, my replacement configuration system for the Linux kernel.) -- Eric S. Raymond ..every Man has a Property in his own Person. This no Body has any Right to but himself. The Labour of his Body, and the Work of his Hands, we may say, are properly his. .... The great and chief end therefore, of Mens uniting into Commonwealths, and putting themselves under Government, is the Preservation of their Property. -- John Locke, "A Treatise Concerning Civil Government" From gstein at lyra.org Fri Jun 2 10:43:13 2000 From: gstein at lyra.org (Greg Stein) Date: Fri, 2 Jun 2000 01:43:13 -0700 (PDT) Subject: [Python-Dev] httplib (was: Adding LDAP to the Python core... ?!) In-Reply-To: <14645.51445.963154.817309@localhost.localdomain> Message-ID: It looks like a definite bug. I have *no* idea, tho, why it is doing that... I did quite a bit of testing with chunked replies. Admittedly, though, I didn't stack up requests like you've done in your test. I'm wrapping up mod_dav at the moment, so I don't really have time to look deeply into this. Mebbe next week? Regarding the pipeline request thing. I think it would probably be best to just drop the whole "hold the previous response and wait for it to be closed" thing. I don't know why that is in there; probably a leftover (converted) semantic from the old-style HTTP() class. I'd be quite fine just axing it and allowing the client to shove ten requests down the pipe before pulling the first response back out. Oh. Wait. Maybe that was it. You can't read the "next" response until the first one has been read. Well... no need to block putting new responses; we just need to create a way to "get the next reply" and/or "can I get the next reply yet?" Cheers, -g p.s. Moshe also had a short list of review items. I read thru them, but not with the code in hand to understand some of his specifics. On Wed, 31 May 2000, Jeremy Hylton wrote: > >>>>> "GS" == Greg Stein writes: > > GS> [ and recall my email last week that I've updated httplib.py and > GS> posted it to my web pages; it is awaiting review for integration > GS> into the Python core; it still needs docs and more testing > GS> scenarios, tho > > I've been looking at the httplib code, and I found what may be a bug. > Not sure, because I'm not sure how the API works for pipelined > requests. > > I've got some test code that looks a bit like this: > > def test_new_interface_series(urls): > paths = [] > the_host = None > for url in urls: > host, path = get_host_and_path(url) > if the_host is None: > the_host = host > else: > assert host == the_host > paths.append(path) > > conn = httplib.HTTPConnection(the_host) > for path in paths: > conn.request('GET', path, headers={'User-Agent': 'httplib/Python'}) > for path in paths: > errcode, errmsg, resp = conn.getreply() > buf = resp.read() > if errcode == 200: > print errcode, resp.headers > else: > print errcode, `errmsg`, resp > print resp.getheader('Content-Length'), len(buf) > print repr(buf[:40]) > print repr(buf[-40:]) > print > conn.close() > > test_new_interface_series(['http://www.python.org/', > 'http://www.python.org/pics/PyBanner054.gif', > 'http://www.python.org/pics/PythonHi.gif', > 'http://www.python.org/Jobs.html', > 'http://www.python.org/doc/', > 'http://www.python.org/doc/current/', > ]) > > The second loop that reads the replies gets fouled up after a couple > of responses. I added even more debugging and found that the first > line of the corrupted response is > > > 'ontent-Type: text/html\015\012' > > It looks like some part of the program is consuming too much input. I > haven't been able to figure out what part yet. Hoping that you might > have some good ideas. > > Thinking about this issue, I came up with a potential API problem. > You must read the body after calling getreply and before calling > getreply a second time. This kind of implicit requirement is a bit > tricky. It would help if the implementation could raise an error if > this happens. It might be even better if it just worked, although it > seems a bit too magical. > > Jeremy > -- Greg Stein, http://www.lyra.org/ From mal at lemburg.com Fri Jun 2 10:11:05 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 02 Jun 2000 10:11:05 +0200 Subject: [Python-Dev] Re: [Patches] Translating doc strings References: <200006020701.JAA28620@pandora> Message-ID: <39376C19.53A01A27@lemburg.com> Martin von Loewis wrote: > > To simplify usage of Python for people who don't speak English well, > I'd like to start a project translating the doc strings in the Python > library. This has two aspects: > > 1. there must be a simple way to access the translated doc strings Do you plan to use GNU gettext here ? (This would cause the translated version of Python to fall under GPL, AFAIK) I'd propose to use the existing doc-strings as keys to a translation mapping. This assures that existing doc-strings remain intact and that the actual translation process is done at query time, e.g. by using a help() built-in function. > 2. there must be actual translations to the various native languages > of Python users. > > Since the second task is much more complicated, I submit a snapshot of > this project, namely, a message catalog of the doc strings in the > Python libraries, taken from the CVS; along with a snapshot of the > German translations. I intend to complete the German translations in > the coming weeks, but I want to give other translators a chance to > also start working on that. > > Please note that extracting the docstrings was not straight-forward; > I've used Fran?ois Pinard's most excellent po-utils 0.5 as a starting > point, and enhanced it with the capability to recognize __doc__[] in C > code, so that I would also get (most of) the doc strings in C modules. > I plan to update this catalog a few times before Python 1.6 is > released, so that translators can update their translations. > > A key point is finding translators. I propose to use the > infrastructure of the GNU translation project for that: There are > established teams for all major languages, and an infrastructure (also > maintained by Fran?ois) where notifications about new catalogs are > automatically distributed to the teams. That should not stop > volunteers which don't currently participate in the GNU translation > project from translating - however, they should announce that they > plan to work on translating these messages to avoid duplication of > work. This will only work iff the translations can be submitted via the usual "post to patches with dislcaimer" method... aren't the GNU people interested in putting the translations under the GPL ? > Another matter is where the catalogs should live in the Python source > tree. I propose to have a Misc/po directory, which will contain both > the PO catalogues, as well as the binary .mo objects; only the latter > will be installed during the installation process. > > Please let me know what you think, in particular, whether I can submit > the catalog to the translation teams. > > Regards, > Martin > > --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > Name: doc.tgz > doc.tgz Type: unspecified type (application/octet-stream) > Encoding: base64 -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Fri Jun 2 09:55:04 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 02 Jun 2000 09:55:04 +0200 Subject: [Python-Dev] ascii.py? References: <200006012236.SAA03578@snark.thyrsus.com> <20000601193232.A12831@newcnri.cnri.reston.va.us> Message-ID: <39376858.55D4F778@lemburg.com> Andrew Kuchling wrote: > > On Thu, Jun 01, 2000 at 06:36:29PM -0400, Eric S. Raymond wrote: > >There has been a vast and echoing silence about the ascii.py module I > >posted here at Fred Drake's request. Is it really such a bad idea? > > One misgiving I had was locales; is it a bug or a feature that locales > aren't supported, as they are for the C isdigit(), isalpha(), &c, > functions? I'm not entirely sure which it is. (The locale module > doesn't expose the C is*() functions, though I think they're used in > constructing string.letters.) FYI, both strings and Unicode object already have a few .isXXX() methods: isdigit(), islower(), isspace(), istitle(), isupper() For strings these use the C APIs (which are locale aware), for Unicode the built in mappings are used. BTW, I haven't looked at the docs lately, but are the string and Unicode methods already documented ? All of them have doc-strings, so it should be easy extracting the data to build a TeX-file. On the topic of adding ascii.py, I'm +0 -- I don't currently have a need for it, but writing .append(ascii.CR + ascii.LF) does add to the readability of scripts. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Fri Jun 2 10:02:35 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 02 Jun 2000 10:02:35 +0200 Subject: [I18n-sig] Re: [Python-Dev] ascii.py? References: <200006012236.SAA03578@snark.thyrsus.com> <39372FC5.DE1CE8EA@prescod.net> Message-ID: <39376A1B.10E45C7B@lemburg.com> Paul Prescod wrote: > > "Eric S. Raymond" wrote: > > > > There has been a vast and echoing silence about the ascii.py module I > > posted here at Fred Drake's request. Is it really such a bad idea? > > Without looking closely, or even being particularly knowledgable (how's > that for a disclaimer!) my instinctive reaction was: "does the ASCII > subset of Unicode need its own module just before we add Unicode to the > language?" > > It may be that there are some semantics of ASCII that are not captured > in the Unicode spec. and thus are not generalizable. I'm pretty > confident that these ones ARE generalizable: > > isalnum > isalpha > isascii > islower > isupper > isspace > isxdigit > > How do Unicode users get this information from the famous Unicode > database and why not merge the Unicode and ASCII versions in 1.6? Note that many of the above are already implemented as string|Unicode methods. The Unicode database is accessible via the unicodedata module. The specs for the used APIs and constants can be found in the Unicode database description file on www.unicode.org. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From loewis at informatik.hu-berlin.de Fri Jun 2 14:33:07 2000 From: loewis at informatik.hu-berlin.de (Martin von Loewis) Date: Fri, 2 Jun 2000 14:33:07 +0200 (MET DST) Subject: [Python-Dev] Re: [Patches] Translating doc strings In-Reply-To: <39376C19.53A01A27@lemburg.com> (mal@lemburg.com) References: <200006020701.JAA28620@pandora> <39376C19.53A01A27@lemburg.com> Message-ID: <200006021233.OAA16962@pandora> > Do you plan to use GNU gettext here ? (This would cause the > translated version of Python to fall under GPL, AFAIK) No, I plan to use the Python gettext module, which is currently being integrated into Python. It will either use the system's gettext library, or read mo files using pure Python. > I'd propose to use the existing doc-strings as keys to > a translation mapping. This assures that existing doc-strings > remain intact and that the actual translation process is > done at query time, e.g. by using a help() built-in function. This is more or less what I've planned. I'd propose to call the function doc, with an interface like >>> doc(time.time) time() -> Gleitkommazahl Gib die aktuelle Zeit in Sekunden seit Beginn der Epoche zur?ck. Sekundenbruchteile sind vorhanden, falls die Systemuhr sie bereitstellt. It won't use a dictionary, though, but the underlying gettext query mechanism. Exact naming and parameters are certainly subject to discussion, my proposal would be doc(object, doprint=1, translate=1) so that users save quite some typing over >>> print time.time.__doc__ time() -> floating point number Return the current time in seconds since the Epoch. Fractions of a second may be present if the system clock provides them. > This will only work iff the translations can be submitted > via the usual "post to patches with dislcaimer" method... > aren't the GNU people interested in putting the translations > under the GPL ? Is it really necessary to have the translations posted to patches at python.org? Or would it be sufficient if translators express their disclaimer in some other way. I don't think the translation teams are "the GNU people"; the translators accepted to assign their copyright to the FSF for the translations they did - I'd assume at least some of them would also accept maintaining the copyright, or assigning it to the Python Consortium (or whoever else wants it). It's more that the Python distributor would need to make suggestions what the copyright on translations should be - I'm sure that could be clearly communicated to the translators. Regards, Martin From fdrake at acm.org Fri Jun 2 14:50:35 2000 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Fri, 2 Jun 2000 08:50:35 -0400 (EDT) Subject: [Python-Dev] ascii.py? In-Reply-To: <200006012236.SAA03578@snark.thyrsus.com> References: <200006012236.SAA03578@snark.thyrsus.com> Message-ID: <14647.44443.651246.979946@cj42289-a.reston1.va.home.com> Eric S. Raymond writes: > There has been a vast and echoing silence about the ascii.py module I > posted here at Fred Drake's request. Is it really such a bad idea? Did you get my comments? -Fred -- Fred L. Drake, Jr. PythonLabs at BeOpen.com From bwarsaw at python.org Fri Jun 2 15:37:42 2000 From: bwarsaw at python.org (Barry A. Warsaw) Date: Fri, 2 Jun 2000 09:37:42 -0400 (EDT) Subject: [Python-Dev] Re: [Patches] Translating doc strings References: <200006020701.JAA28620@pandora> <39376C19.53A01A27@lemburg.com> <200006021233.OAA16962@pandora> Message-ID: <14647.47270.330318.807347@anthem.python.org> >>>>> "MvL" == Martin von Loewis writes: MvL> No, I plan to use the Python gettext module, which is MvL> currently being integrated into Python. It will either use MvL> the system's gettext library, or read mo files using pure MvL> Python. pygettext is in Tools/i18n, and I've been working with James Henstridge and Peter Funk on getting a standard gettext module integrated into the core. A few other things have bumped that down on my list, but it's still there. We'll still need xgettext to scan the C code. Also, marking Python module docstrings is a bit problematic. I've resorted to Something Really Ugly: -------------------- snip snip -------------------- try: import fintl _ = fintl.gettext except ImportError: def _(s): return s __doc__ = _("""pygettext -- Python equivalent of xgettext(1) ...") -------------------- snip snip -------------------- Yuck. -Barry From pf at artcom-gmbh.de Fri Jun 2 15:57:32 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Fri, 2 Jun 2000 15:57:32 +0200 (MEST) Subject: [Python-Dev] Re: [Patches] Translating doc strings In-Reply-To: <14647.47270.330318.807347@anthem.python.org> from "Barry A. Warsaw" at "Jun 2, 2000 9:37:42 am" Message-ID: Hi, [Barry A. Warsaw]: > pygettext is in Tools/i18n, and I've been working with James > Henstridge and Peter Funk on getting a standard gettext module > integrated into the core. A few other things have bumped that down on > my list, but it's still there. I will try to make some progress. Currently I'm not sure how to define a class 'Translator' ... I'm open for suggestions. James has also made some interesting points. > We'll still need xgettext to scan the C code. Also, marking Python > module docstrings is a bit problematic. I've resorted to Something > Really Ugly: > > -------------------- snip snip -------------------- > try: > import fintl > _ = fintl.gettext > except ImportError: > def _(s): return s > > > __doc__ = _("""pygettext -- Python equivalent of xgettext(1) > ...") > -------------------- snip snip -------------------- > > Yuck. I agree: this is really ugly. Since doc-strings are something special, I don't think, we should travel further down this road. I believe, we should use a special doc-string extration-tool (possibly build on top of ping's 'inspect.py'?), which will then create a .pot-file solely out of __doc__-strings. Regards, Peter. From loewis at informatik.hu-berlin.de Fri Jun 2 17:03:50 2000 From: loewis at informatik.hu-berlin.de (Martin von Loewis) Date: Fri, 2 Jun 2000 17:03:50 +0200 (MET DST) Subject: [Python-Dev] Re: [Patches] Translating doc strings In-Reply-To: <14647.47270.330318.807347@anthem.python.org> (bwarsaw@python.org) References: <200006020701.JAA28620@pandora> <39376C19.53A01A27@lemburg.com> <200006021233.OAA16962@pandora> <14647.47270.330318.807347@anthem.python.org> Message-ID: <200006021503.RAA26314@pandora> > We'll still need xgettext to scan the C code. Please have a look at my lib.pot; I've been using xpot to extract the C doc strings, which aren't currently marked-up in the Python source. As for module docstrings: xpot doesn't recognize them either, but I think it could be improved to do so. However, that would give a substantial increase of the catalogs, so I'd recommend to add them only when the translators are done with the first round of translation. Having the full set of distutils doc strings in the catalog is already a substantial amount of text to translate... Regards, Martin From loewis at informatik.hu-berlin.de Fri Jun 2 17:05:35 2000 From: loewis at informatik.hu-berlin.de (Martin von Loewis) Date: Fri, 2 Jun 2000 17:05:35 +0200 (MET DST) Subject: [Python-Dev] Re: [Patches] Translating doc strings In-Reply-To: (pf@artcom-gmbh.de) References: Message-ID: <200006021505.RAA26338@pandora> > I agree: this is really ugly. Since doc-strings are something special, > I don't think, we should travel further down this road. I believe, > we should use a special doc-string extration-tool (possibly build > on top of ping's 'inspect.py'?), which will then create a .pot-file > solely out of __doc__-strings. I agree. Again, I'd like to advertise Fran?ois Pinard's xpot, which can extract doc strings from both Python code and C code. Regards, Martin From moshez at math.huji.ac.il Fri Jun 2 19:52:59 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Fri, 2 Jun 2000 20:52:59 +0300 (IDT) Subject: [Python-Dev] Suggestion: stopping to trust os mtimes Message-ID: Trusting OS-based mtimes for .pyc caching has some inherent problems. (Clock syncing and similar) Frankly, though I've never been bitten by this, it does give me an uncomfortable feeling. What if, instead, we'd use md5- or sha-based approach? I'm willing to bet that the 2^128 chance of problems is miniscule compared to the real problems clock syncing has already caused. (I think I remember some problem with .pyc's on IIS, but I may just be hallucinating) Problems: .pyc size would increase by 24 bytes -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com From trentm at activestate.com Fri Jun 2 20:14:17 2000 From: trentm at activestate.com (Trent Mick) Date: Fri, 2 Jun 2000 11:14:17 -0700 Subject: [Python-Dev] PyMarshal_WriteLongToFile: writes 'long' or 32-bit integer? Message-ID: <20000602111417.A17233@activestate.com> So, is PyMarshal_WriteLongToFile intended to write a C long, regardless of its size, or is it intended to alway write 32-bits? Currently it just writes 32-bits and if sizeof(long) > 4 for that platform then it is silently truncated. PyMarshal_WriteLongToFile is currently only used (in the core anyway) to write the magic number and timestamp for .pyc files in import.c. The current situation is pretty misleading. If you write a long directly with PyMarshal_WriteLongToFile your long is truncated to 32-bits. However, if you write a long indirectly by PyMarshal_WriteObjectToFile, where that Python object is or contains a PyInt (C long), then the long is *not* truncated. Options: 1. leave it, who cares 2. - change PyMarshal_WriteLongToFile to write 64-bits if long is 64-bits - add something like PyMarshal_WriteInt32ToFile for the benefit of users like import.c that want to control exactly how many bytes get written 3. - change PyMarshal_WriteLongToFile to raise an exception if the long overflows a 32-bit range Thanks, Trent -- Trent Mick trentm at activestate.com From pf at artcom-gmbh.de Fri Jun 2 21:21:30 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Fri, 2 Jun 2000 21:21:30 +0200 (MEST) Subject: [Python-Dev] Suggestion: stopping to trust os mtimes In-Reply-To: from Moshe Zadka at "Jun 2, 2000 8:52:59 pm" Message-ID: hi, Moshe Zadka wrote: > Trusting OS-based mtimes for .pyc caching has some inherent problems. > (Clock syncing and similar) Frankly, though I've never been bitten by > this, it does give me an uncomfortable feeling. What if, instead, we'd use > md5- or sha-based approach? I'm willing to bet that the 2^128 chance of > problems is miniscule compared to the real problems clock syncing has > already caused. (I think I remember some problem with .pyc's on IIS, but > I may just be hallucinating) The timestamp is returned by simply 'stat'ing the .py file. If you want more, you actually would have to open the .py files all the time. This would be trading a big performance penalty for a security, that will almost always not needed. In Unix many sub systems (for example 'make' depend on a monotone system clock. A random jumping clock would break many of them anyway. Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen) From gstein at lyra.org Fri Jun 2 21:53:21 2000 From: gstein at lyra.org (Greg Stein) Date: Fri, 2 Jun 2000 12:53:21 -0700 (PDT) Subject: [Python-Dev] Suggestion: stopping to trust os mtimes In-Reply-To: Message-ID: On Fri, 2 Jun 2000, Moshe Zadka wrote: > Trusting OS-based mtimes for .pyc caching has some inherent problems. > (Clock syncing and similar) Frankly, though I've never been bitten by > this, it does give me an uncomfortable feeling. What if, instead, we'd use > md5- or sha-based approach? That is an expensive computation. You'd have to read the whole file in and compute the hash. Today, we simply stat() each file. If the .pyc looks valid, we open it and check the date stamp against one of those stat's. You would be adding an open(), a read of the full file, and compute a hash -- to every import of a .pyc. -1 Cheers, -g -- Greg Stein, http://www.lyra.org/ From mal at lemburg.com Fri Jun 2 21:13:20 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 02 Jun 2000 21:13:20 +0200 Subject: [Python-Dev] Suggestion: stopping to trust os mtimes References: Message-ID: <39380750.97CD3BA0@lemburg.com> Moshe Zadka wrote: > > Trusting OS-based mtimes for .pyc caching has some inherent problems. > (Clock syncing and similar) Frankly, though I've never been bitten by > this, it does give me an uncomfortable feeling. What if, instead, we'd use > md5- or sha-based approach? I'm willing to bet that the 2^128 chance of > problems is miniscule compared to the real problems clock syncing has > already caused. (I think I remember some problem with .pyc's on IIS, but > I may just be hallucinating) > > Problems: > .pyc size would increase by 24 bytes Much worse: you'd have to recalculate the MD5-sum every time you import the .pyc file... Frankly, I don't think this is needed at all ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From loewis at informatik.hu-berlin.de Fri Jun 2 22:46:34 2000 From: loewis at informatik.hu-berlin.de (Martin von Loewis) Date: Fri, 2 Jun 2000 22:46:34 +0200 (MET DST) Subject: [Python-Dev] Re: [Patches] Translating doc strings In-Reply-To: (message from Ka-Ping Yee on Fri, 2 Jun 2000 12:07:22 -0700 (PDT)) References: Message-ID: <200006022046.WAA29600@pandora> > But presumably we want to get all the strings, don't we? Certainly not. For example, in ftplib, the string "anonymous" should not be translated - it would end up as "anonym" in German, and that would not be accepted by FTP servers. In general, great care is needed to select translatable strings. For example, the GNU ls program was localized to print the month names in German. Pretty safe, eh? Now, the emacs dired mode wouldn't recognize any file names in the list output anymore, because it had a regular expression to detect the various fields, which involved an alternative list for all the month names... Regards, Martin From pingster at ilm.com Fri Jun 2 21:07:22 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Fri, 2 Jun 2000 12:07:22 -0700 (PDT) Subject: [Python-Dev] Re: [Patches] Translating doc strings In-Reply-To: Message-ID: On Fri, 2 Jun 2000, Peter Funk wrote: > > I agree: this is really ugly. Since doc-strings are something special, > I don't think, we should travel further down this road. I believe, > we should use a special doc-string extration-tool (possibly build > on top of ping's 'inspect.py'?), which will then create a .pot-file > solely out of __doc__-strings. Getting __doc__ strings is pretty easy (inspect.py is one possibility). But presumably we want to get all the strings, don't we? That should be trivial with tokenize, right? ---- getstrings.py ----- import sys, tokenize strings = [] def tokeneater(type, token, start, end, line): if type == tokenize.STRING: strings.append(eval(token)) file = open(sys.argv[1]) tokenize.tokenize(file.readline, tokeneater) print strings ------------------------ % ./getstrings.py /usr/local/lib/python1.5/calendar.py ['calendar.error', 'Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday', 'Saturday', 'Sunday', 'Mon', 'Tue', 'Wed', 'Thu', 'Fri', 'Sat', 'Sun', '', 'January', 'February', 'March', 'April', 'May', 'June', 'July', 'August', 'September', 'October', 'No vember', 'December', ' ', 'Jan', 'Feb', 'Mar', 'Apr', 'May', 'Jun', 'Jul', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec', 'bad month number', ' ', ' ', '', '', ' ', ' ', '\012', '\012', '\012', ' ', '', '', ' '] Am i missing something? -- ?!ng From gstein at lyra.org Fri Jun 2 23:32:52 2000 From: gstein at lyra.org (Greg Stein) Date: Fri, 2 Jun 2000 14:32:52 -0700 (PDT) Subject: [Python-Dev] Suggestion: stopping to trust os mtimes In-Reply-To: Message-ID: On Fri, 2 Jun 2000, Peter Funk wrote: > Moshe Zadka wrote: > > Trusting OS-based mtimes for .pyc caching has some inherent problems. > > (Clock syncing and similar) Frankly, though I've never been bitten by > > this, it does give me an uncomfortable feeling. What if, instead, we'd use > > md5- or sha-based approach? I'm willing to bet that the 2^128 chance of > > problems is miniscule compared to the real problems clock syncing has > > already caused. (I think I remember some problem with .pyc's on IIS, but > > I may just be hallucinating) > > The timestamp is returned by simply 'stat'ing the .py file. If you > want more, you actually would have to open the .py files all the time. > This would be trading a big performance penalty for a security, that > will almost always not needed. In Unix many sub systems (for example > 'make' depend on a monotone system clock. A random jumping clock > would break many of them anyway. He does have a point, but I think the wrong solution :-) While the clock may be monotonically increasing on one system, it isn't always the case when things like NFS come into play. I recall a case back '95 when I was editing a .py over an NFS mount and running the code on the target machine. The clocks on the two boxes were off by about three seconds. I was going thru the edit/run/edit/run cycle so quickly, that at one point, I saved a .py file that was older than the associated .pyc file. Needless to say, I was really confused that my recent edit didn't produce the desired result :-) Cheers, -g p.s. and no, I don't know why the internal timestamp didn't take effect -- Greg Stein, http://www.lyra.org/ From pingster at ilm.com Sat Jun 3 01:10:01 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Fri, 2 Jun 2000 16:10:01 -0700 (PDT) Subject: [Python-Dev] Protecting __name__ &c. Message-ID: Would it be too much trouble to prevent replacing double-underscore attributes like __name__ and __file__? I'll accept a "consenting adults" argument -- it's just that somehow this makes me uneasy: Python 1.5.2 (#54, Jul 14 1999, 12:50:51) [C] on irix6 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import foo >>> foo.__name__ 'bar' >>> foo.__file__ 'bar.py' >>> foo Of course, there is no 'bar.py'. 'foo.py' just contains __file__ = 'bar.py' __name__ = 'bar' (If you say i deserved to be punished for such heresy, fine...) -- ?!ng From mhammond at skippinet.com.au Sat Jun 3 01:21:07 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sat, 3 Jun 2000 09:21:07 +1000 Subject: [Python-Dev] Protecting __name__ &c. In-Reply-To: Message-ID: > Would it be too much trouble to prevent replacing > double-underscore attributes like __name__ and __file__? This can be handy sometimes. > I'll accept a "consenting adults" argument -- it's just > that somehow this makes me uneasy: OK - accept it :-) Just dont do it if it makes you uneasy. > >>> import foo > >>> foo.__name__ > 'bar' > >>> foo.__file__ > 'bar.py' > >>> foo > That is no worse than, say: >>> a=1 >>> globals()['a']=2 >>> a 2 So you could make the same argument that globals() should be read-only, to force you to do the "normal" thing. To me, this is one of Python's big features. I dont want it holding my hand so tightly it cuts circulation :-) Mark. From akuchlin at cnri.reston.va.us Sat Jun 3 05:15:50 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Fri, 2 Jun 2000 23:15:50 -0400 Subject: [Python-Dev] What's New (first draft) Message-ID: <20000602231550.A986@newcnri.cnri.reston.va.us> I've put up the crude first draft of a "What's New in Python 1.6" article, co-written with Moshe Zadka. Please offer comments (or even patches to the LaTeX!). http://www.python.net/crew/amk/python/writing/new-python/ PDF, DVI, ASCII, and the LaTeX source are in: ftp://www.python.net/pub/crew/amk/new/ Various people are mentioned by name in the document ("effbot did this; MAL did that; Christian did that other thing...") because I want to emphasize the number of contributors to this release; does everyone think this is a good idea? If I've missed your name, or credited you wrongly, please let me know. --amk From akuchlin at cnri.reston.va.us Sat Jun 3 05:25:21 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Fri, 2 Jun 2000 23:25:21 -0400 Subject: [Python-Dev] Revised 1.6 jobs list Message-ID: <20000602232521.B986@newcnri.cnri.reston.va.us> I've slightly revised the 1.6 jobs list at http://www.python.net/crew/amk/python/1.6-jobs.html . Things still on the TODO list, maybe: Import hooks revamp (or is this a post-1.6 thing?) Update the documentation to match 1.6 changes. Document more undocumented modules (goes without saying, really...) : codecs, unicodedata, mmap, pyexpat, curses, regrtest. Unicode: Compress the size of unicodedatabase Unicode: Write \N{SMILEY} codec for Unicode (Bill Tutt has a patch) Unicode: the various XXX itemsin Misc/unicode.txt (or are they done?) Delete obsolete subdirectories in Demo/ directory Refurbish Demo subdirectories to be properly documented, match modern coding style, etc. Fix ./ld_so_aix installation problem on AIX Make test.regrtest.py more usable outside of thePython test suite Conservative garbage collection of cycles (maybe -- I don't know what GvR thinks about this) Changes to PyExpat module Test the hell out of SRE The end of coding may be in sight, leaving only the job of documenting everything new. I'm getting kind of worried about the lengthening backlog of patches, though; maybe next week we can start cutting it down? (Quick, while Guido's away, everyone come up with new keywords and check them in!) --amk From esr at thyrsus.com Sat Jun 3 05:49:16 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 2 Jun 2000 23:49:16 -0400 Subject: [Python-Dev] Revised 1.6 jobs list In-Reply-To: <20000602232521.B986@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Fri, Jun 02, 2000 at 11:25:21PM -0400 References: <20000602232521.B986@newcnri.cnri.reston.va.us> Message-ID: <20000602234916.B9680@thyrsus.com> Andrew Kuchling : > Document more undocumented modules (goes without saying, really...) : codecs, > unicodedata, mmap, pyexpat, curses, regrtest. About curses. Have you got the entry points listed and dxescribed yet? If so, I'll flesh out the docs with my tutorial stuff. We have a volunteer maintainer for curses after release, now, BTW. It's new Pythoneer Jim Dennis, the "Answer Guy" from the Linux Gazette. -- Eric S. Raymond The end move in politics is always to pick up a gun. -- R. Buckminster Fuller From bwarsaw at python.org Sat Jun 3 06:41:42 2000 From: bwarsaw at python.org (Barry A. Warsaw) Date: Sat, 3 Jun 2000 00:41:42 -0400 (EDT) Subject: [Python-Dev] Revised 1.6 jobs list References: <20000602232521.B986@newcnri.cnri.reston.va.us> Message-ID: <14648.35974.486959.379543@anthem.python.org> Did we ever decide on building in thread support by default? I'd really like to see threads enabled by default in 1.6 and I /think/ it'll just take some autoconf hacking, which I'm willing to do. Are there any objections to building in threads support by default if autoconf detects threads? -Barry From moshez at math.huji.ac.il Sat Jun 3 08:05:09 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sat, 3 Jun 2000 09:05:09 +0300 (IDT) Subject: [Python-Dev] Suggestion: stopping to trust os mtimes In-Reply-To: Message-ID: On Fri, 2 Jun 2000, Greg Stein wrote: > He does have a point, but I think the wrong solution :-) In my defense, it was after spending the whole day on my feet giving a lecture, or driving (for 12 hours). But it does bother me, even if the solution is terrible. How about having, in addition to the time-stamp, the size of the file? At least on UNIX, it comes for free with the same stat call. -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com From moshez at math.huji.ac.il Sat Jun 3 09:56:15 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sat, 3 Jun 2000 10:56:15 +0300 (IDT) Subject: [Python-Dev] PyMarshal_WriteLongToFile: writes 'long' or 32-bit integer? In-Reply-To: <20000602111417.A17233@activestate.com> Message-ID: On Fri, 2 Jun 2000, Trent Mick wrote: > 3. - change PyMarshal_WriteLongToFile to raise an exception if the long > overflows a 32-bit range +1 on that, finally non-portable integers will cause an exception. -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com From moshez at math.huji.ac.il Sat Jun 3 10:11:45 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sat, 3 Jun 2000 11:11:45 +0300 (IDT) Subject: [Python-Dev] Protecting __name__ &c. In-Reply-To: Message-ID: On Fri, 2 Jun 2000, Ka-Ping Yee wrote: > Would it be too much trouble to prevent replacing > double-underscore attributes like __name__ and __file__? Well, special casing seems like a bad idea on the face of it. Where does it stop? The correct way to "solve" this, is to add declarations to Python, including "constant" declaration, and then saying that __name__ and __file__ are "implicitly declared" constants. please-scatter-IMHOs-generously-throughtout-the-mail-ly y'rs, Z. -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com From gstein at lyra.org Sat Jun 3 11:52:39 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 3 Jun 2000 02:52:39 -0700 (PDT) Subject: [Python-Dev] Revised 1.6 jobs list In-Reply-To: <14648.35974.486959.379543@anthem.python.org> Message-ID: On Sat, 3 Jun 2000, Barry A. Warsaw wrote: > Did we ever decide on building in thread support by default? I'd > really like to see threads enabled by default in 1.6 and I /think/ > it'll just take some autoconf hacking, which I'm willing to do. Are > there any objections to building in threads support by default if > autoconf detects threads? +1 -- if they are there, then build them in! Cheers, -g -- Greg Stein, http://www.lyra.org/ From gmcm at hypernet.com Sat Jun 3 13:26:18 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Sat, 3 Jun 2000 07:26:18 -0400 Subject: [Python-Dev] Revised 1.6 jobs list In-Reply-To: <20000602232521.B986@newcnri.cnri.reston.va.us> Message-ID: <1252090883-19062603@hypernet.com> Andrew Kuchling wrote: > I've slightly revised the 1.6 jobs list > at http://www.python.net/crew/amk/python/1.6-jobs.html . > Things still on the TODO list, maybe: > > Import hooks revamp (or is this a post-1.6 thing?) The import SIG was created to resolve the controversies around imputils. The archives of the import SIG contain absolutely no controversy. So I say do it. - Gordon From skip at mojam.com Sat Jun 3 14:15:28 2000 From: skip at mojam.com (Skip Montanaro) Date: Sat, 3 Jun 2000 07:15:28 -0500 (CDT) Subject: [Python-Dev] Suggestion: stopping to trust os mtimes In-Reply-To: References: Message-ID: <14648.63200.850429.304545@beluga.mojam.com> Greg> I recall a case back '95 when I was editing a .py over an NFS Greg> mount and running the code on the target machine. The clocks on Greg> the two boxes were off by about three seconds. I was going thru Greg> the edit/run/edit/run cycle so quickly, that at one point, I saved Greg> a .py file that was older than the associated .pyc file. A help I think would be to compare the mtimes of the .py and .pyc files with the current system clock and squawk if either appears to have been created in the future. I believe this is what GNU make does. Of course, the best solution to all of this is the non-Python solution: use NTP so your clocks stay sync'd. It's even available out-of-the-box on my iMac... -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ "We have become ... the stewards of life's continuity on earth. We did not ask for this role... We may not be suited to it, but here we are." - Stephen Jay Gould From moshez at math.huji.ac.il Sat Jun 3 14:53:47 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sat, 3 Jun 2000 15:53:47 +0300 (IDT) Subject: [Python-Dev] Suggestion: stopping to trust os mtimes In-Reply-To: <14648.63200.850429.304545@beluga.mojam.com> Message-ID: On Sat, 3 Jun 2000, Skip Montanaro wrote: > Of course, the best solution to all of this is the non-Python solution: use > NTP so your clocks stay sync'd. It's even available out-of-the-box on my > iMac... But the "Python Way" was always to adapt: not to require One True Way, but to use the facilities where it finds itself. In any case, is there any objection to storing the size of the .py alongside it's mtime in the .pyc, and regenerating if either is changed? This is just as efficient, and much more reliable. -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com From mal at lemburg.com Sat Jun 3 11:55:26 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat, 03 Jun 2000 11:55:26 +0200 Subject: [Python-Dev] Revised 1.6 jobs list References: <20000602232521.B986@newcnri.cnri.reston.va.us> Message-ID: <3938D60E.391AAF31@lemburg.com> Andrew Kuchling wrote: > > I've slightly revised the 1.6 jobs list > at http://www.python.net/crew/amk/python/1.6-jobs.html . > Things still on the TODO list, maybe: > > Import hooks revamp (or is this a post-1.6 thing?) > Update the documentation to match 1.6 changes. > Document more undocumented modules (goes without saying, really...) : codecs, > unicodedata, mmap, pyexpat, curses, regrtest. I would appreciate some help with codec and unicodedata. codec.py has quite a bit of __doc__ string documentation which can be used more or less directly for the TeX docs. > Unicode: Compress the size of unicodedatabase Christian was working on this one, but I never got the patches ... Chris ? > Unicode: Write \N{SMILEY} codec for Unicode (Bill Tutt has a patch) I wonder why that patch hasn't been accepted yet -- I guess the patches list needs some more people willing to review things and of course people with check in permissions. I would volunteer to handle the above for the Unicode parts of the distribution if someone would explain to me how to checkin new code into SourceForge CVS. > Unicode: the various XXX itemsin Misc/unicode.txt (or are they done?) Hmm, there are no XXX markings left in my version of that file -- perhaps I've missed adding it to the patch sets... Anyway, the file will have to undergo some rewrite now that the default encoding strategy has changed. I'll fix that next week. > Delete obsolete subdirectories in Demo/ directory > Refurbish Demo subdirectories to be properly documented, match modern coding > style, etc. > Fix ./ld_so_aix installation problem on AIX > Make test.regrtest.py more usable outside of thePython test suite > Conservative garbage collection of cycles (maybe -- I don't know what GvR > thinks about this) > Changes to PyExpat module > Test the hell out of SRE > > The end of coding may be in sight, leaving only the job of documenting > everything new. I'm getting kind of worried about the lengthening backlog > of patches, though; maybe next week we can start cutting it down? (Quick, > while Guido's away, everyone come up with new keywords and check them in!) :-) Still, you've got a point there: Trent's patches are getting piled up and due to the fact that they touch many different parts of the code, they are likely to get in the way of other patches. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From jeremy at beopen.com Sat Jun 3 18:11:48 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Sat, 3 Jun 2000 12:11:48 -0400 Subject: [Python-Dev] Revised 1.6 jobs list In-Reply-To: <3938D60E.391AAF31@lemburg.com> Message-ID: M.-A. Lemburg wrote: >I wonder why that patch hasn't been accepted yet -- I guess >the patches list needs some more people willing to review things >and of course people with check in permissions. One of the problems I'm having is keeping track of which patches are still outstanding. This is really a management/tools problem. I have a mailbox full of messages from the patches list -- some of the messages are patches, others are discussion. Some patches supercede others or are duplicates. It would help if we had better tools for managing the submitted/pending patches. SourceForge makes it a little more inconvenient to check which patches have been applied. Under the old CVS arrangement, it was a local operation to do a cvs log or diff. Now it's a slow network operation that requires authentication. (I really want a local mirror of the entire CVS repository!) Sorry for the excuses. I think better tools would help a lot, but we'll have to get more people checkin privileges regardless. Jeremy From tismer at tismer.com Sat Jun 3 18:43:51 2000 From: tismer at tismer.com (Christian Tismer) Date: Sat, 03 Jun 2000 18:43:51 +0200 Subject: [Python-Dev] Revised 1.6 jobs list References: <20000602232521.B986@newcnri.cnri.reston.va.us> <3938D60E.391AAF31@lemburg.com> Message-ID: <393935C7.7624448A@tismer.com> "M.-A. Lemburg" wrote: > > Unicode: Compress the size of unicodedatabase > > Christian was working on this one, but I never got the > patches ... Chris ? Schmurpel :-> Something came in between where I couldn't resist to work on... yes, the microthread stuff was it. Ok, it is a pain for me to go for a sub-optimum solution, but yep, I'll force me to write the code gen now. ... > Still, you've got a point there: Trent's patches are getting > piled up and due to the fact that they touch many different > parts of the code, they are likely to get in the way of other > patches. patch-as-patch-can-ly y'rs - chris -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaunstr. 26 : *Starship* http://starship.python.net 14163 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF where do you want to jump today? http://www.stackless.com From tismer at tismer.com Sat Jun 3 18:44:31 2000 From: tismer at tismer.com (Christian Tismer) Date: Sat, 03 Jun 2000 18:44:31 +0200 Subject: [Python-Dev] Revised 1.6 jobs list References: <20000602232521.B986@newcnri.cnri.reston.va.us> <3938D60E.391AAF31@lemburg.com> Message-ID: <393935EF.89AA40DF@tismer.com> "M.-A. Lemburg" wrote: > > Unicode: Compress the size of unicodedatabase > > Christian was working on this one, but I never got the > patches ... Chris ? Schmurpel :-> Something came in between where I couldn't resist to work on... yes, the microthread stuff was it. Not to talk of the starship mess, which will hopefully end by this weekend... Ok, it is a pain for me to go for a sub-optimum solution, but yep, I'll force me to write the code gen now. ... > Still, you've got a point there: Trent's patches are getting > piled up and due to the fact that they touch many different > parts of the code, they are likely to get in the way of other > patches. patch-as-patch-can-ly y'rs - chris -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaunstr. 26 : *Starship* http://starship.python.net 14163 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF where do you want to jump today? http://www.stackless.com From gstein at lyra.org Sat Jun 3 21:41:19 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 3 Jun 2000 12:41:19 -0700 (PDT) Subject: [Python-Dev] Suggestion: stopping to trust os mtimes In-Reply-To: <14648.63200.850429.304545@beluga.mojam.com> Message-ID: On Sat, 3 Jun 2000, Skip Montanaro wrote: > Greg> I recall a case back '95 when I was editing a .py over an NFS > Greg> mount and running the code on the target machine. The clocks on > Greg> the two boxes were off by about three seconds. I was going thru > Greg> the edit/run/edit/run cycle so quickly, that at one point, I saved > Greg> a .py file that was older than the associated .pyc file. > > A help I think would be to compare the mtimes of the .py and .pyc files with > the current system clock and squawk if either appears to have been created > in the future. I believe this is what GNU make does. Sure, but to the target machine, the .pyc was fine and the .py was in the past. :-) Of course, the proper solution is to introduce compile/link stages into Python so that we don't get bitten by 3-second clock differences. :-) -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Sat Jun 3 22:26:00 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 3 Jun 2000 13:26:00 -0700 (PDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules mmapmodule.c,2.8,2.9 In-Reply-To: <200006031941.MAA21418@slayer.i.sourceforge.net> Message-ID: Actually, PyArg_ParseTuple() is a better call for this. It allows you to specify the method name: if (!PyArg_ParseTuple(args, ":close")) return NULL; Cheers,, -g On Sat, 3 Jun 2000, A.M. Kuchling wrote: > Update of /cvsroot/python/python/dist/src/Modules > In directory slayer.i.sourceforge.net:/tmp/cvs-serv21410 > > Modified Files: > mmapmodule.c > Log Message: > Add missing PyArg_NoArgs() calls to methods that didn't take arguments > (Pointed out by Moshe Zadka) > > > Index: mmapmodule.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Modules/mmapmodule.c,v > retrieving revision 2.8 > retrieving revision 2.9 > diff -C2 -r2.8 -r2.9 > *** mmapmodule.c 2000/05/03 23:44:32 2.8 > --- mmapmodule.c 2000/06/03 19:41:42 2.9 > *************** > *** 2,6 **** > / Author: Sam Rushing > / Hacked for Unix by A.M. Kuchling > ! / $Id: mmapmodule.c,v 2.8 2000/05/03 23:44:32 guido Exp $ > > / mmapmodule.cpp -- map a view of a file into memory > --- 2,6 ---- > / Author: Sam Rushing > / Hacked for Unix by A.M. Kuchling > ! / $Id: mmapmodule.c,v 2.9 2000/06/03 19:41:42 akuchling Exp $ > > / mmapmodule.cpp -- map a view of a file into memory > *************** > *** 76,79 **** > --- 76,81 ---- > mmap_close_method (mmap_object * self, PyObject * args) > { > + if (!PyArg_NoArgs(args)) > + return NULL; > #ifdef MS_WIN32 > UnmapViewOfFile (self->data); > *************** > *** 119,122 **** > --- 121,126 ---- > char * where; > CHECK_VALID(NULL); > + if (!PyArg_NoArgs(args)) > + return NULL; > if (self->pos >= 0 && self->pos < self->size) { > where = self->data + self->pos; > *************** > *** 132,136 **** > static PyObject * > mmap_read_line_method (mmap_object * self, > ! PyObject * args) > { > char * start = self->data+self->pos; > --- 136,140 ---- > static PyObject * > mmap_read_line_method (mmap_object * self, > ! PyObject * args) > { > char * start = self->data+self->pos; > *************** > *** 140,143 **** > --- 144,149 ---- > > CHECK_VALID(NULL); > + if (!PyArg_NoArgs(args)) > + return NULL; > > eol = memchr(start, '\n', self->size - self->pos); > *************** > *** 154,158 **** > static PyObject * > mmap_read_method (mmap_object * self, > ! PyObject * args) > { > long num_bytes; > --- 160,164 ---- > static PyObject * > mmap_read_method (mmap_object * self, > ! PyObject * args) > { > long num_bytes; > *************** > *** 226,230 **** > static PyObject * > mmap_write_byte_method (mmap_object * self, > ! PyObject * args) > { > char value; > --- 232,236 ---- > static PyObject * > mmap_write_byte_method (mmap_object * self, > ! PyObject * args) > { > char value; > *************** > *** 242,248 **** > static PyObject * > mmap_size_method (mmap_object * self, > ! PyObject * args) > { > CHECK_VALID(NULL); > > #ifdef MS_WIN32 > --- 248,256 ---- > static PyObject * > mmap_size_method (mmap_object * self, > ! PyObject * args) > { > CHECK_VALID(NULL); > + if (!PyArg_NoArgs(args)) > + return NULL; > > #ifdef MS_WIN32 > *************** > *** 347,350 **** > --- 355,360 ---- > { > CHECK_VALID(NULL); > + if (!PyArg_NoArgs(args)) > + return NULL; > return (Py_BuildValue ("l", self->pos) ); > } > *************** > *** 463,470 **** > > static int > ! mmap_buffer_getreadbuf(self, index, ptr) > ! mmap_object *self; > ! int index; > ! const void **ptr; > { > CHECK_VALID(-1); > --- 473,477 ---- > > static int > ! mmap_buffer_getreadbuf(mmap_object *self, int index, const void **ptr) > { > CHECK_VALID(-1); > *************** > *** 868,869 **** > --- 875,877 ---- > > } > + > > > _______________________________________________ > Python-checkins mailing list > Python-checkins at python.org > http://www.python.org/mailman/listinfo/python-checkins > -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Sat Jun 3 22:34:26 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 3 Jun 2000 13:34:26 -0700 (PDT) Subject: [Python-Dev] autoconf macros (was: RE: [Patches] Patch to Modules/pcre.h) In-Reply-To: Message-ID: [moving to python-dev] On Sun, 4 Jun 2000, Mark Hammond wrote: > > I don't even see where DONT_HAVE_SYS_TYPES_H is ever defined: > ... > > Is it defined in some Mac-specific project file? > > A few existed before, but I know I submitted a couple of the listed ones > for Windows CE. However, the CE config.h has never made it into the core, > hence you can't find that particular definition... Well, as I pointed out, the best way to do this is to add sys/types.h, sys/stat.h, and stat.h to the AC_CHECK_HEADER() macro in configure.in. The HAVE_SYS_TYPES_H macro and friends could then be checked. PC/wince_config.h (or whatever it is called) would just #undef the HAVE_* macros. The underlying issue here, is that autoconf can take care of these things for us quite easily -- that we don't need manual maintenance of the macros. For the odd platform without sys/types.h, autoconf will handle it, rather than Python needing to do a special-case declaration. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Sat Jun 3 22:44:07 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 3 Jun 2000 13:44:07 -0700 (PDT) Subject: [Python-Dev] Revised 1.6 jobs list In-Reply-To: Message-ID: On Sat, 3 Jun 2000, Jeremy Hylton wrote: >... > Sorry for the excuses. I think better tools would help a lot, but > we'll have to get more people checkin privileges regardless. There are several issues with expanded checkin privs: 1) trust: will the person make sure it is Right And Proper to do the checkin? (have they reviewed the code? is a a Good Change? etc) The counter here is that we don't want people that will simply take stuff arriving at patches@ and checking them in. 2) more people reviewing changes on the -checkins mailing list. Assuming that you want more than one pair of eyeballs looking at patches/code, that more people with commit privs increases the rate of commits, then you need more reviewers to keep up (because the reviewers probably are not going to review ALL checkins) 3) increasing dependence on -checkins means that patches MUST be smaller chunks. they MUST be single-purpose patches. practically nobody will review a 200k patch, or patches that fix N different things at once. A small, focused patch is easily reviewed. For example: Trent has recently mailed a bunch of patches to the patches list. This is Goodness: each one is focused and can be individually reviewed. Since they are not a single, giant blob, it also keeps them short and reviewable... each can have a +1/-1 independent of the others. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Sat Jun 3 23:14:49 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 3 Jun 2000 14:14:49 -0700 (PDT) Subject: [Python-Dev] Suggestion: stopping to trust os mtimes In-Reply-To: Message-ID: On Sat, 3 Jun 2000, Moshe Zadka wrote: >... > In any case, is there any objection to storing the size of the .py > alongside it's mtime in the .pyc, and regenerating if either is changed? > This is just as efficient, and much more reliable. If we change the header size, then this would be fine. At the moment, I don't think that anybody is suggesting a change to the .pyc header format because of the number of tool breakages that would ensue. People have seemed interested in my idea to update the marshal format to record a version number -- it doesn't require a change to the .pyc header. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Sun Jun 4 00:53:18 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 3 Jun 2000 15:53:18 -0700 (PDT) Subject: [Python-Dev] Re: httplib (was: Adding LDAP to the Python core... ?!) In-Reply-To: Message-ID: I found the problem. Sneaky... sock.makefile() does a dup() on the file descriptor, then opens a FILE* with that. See it coming yet? ... FILE* is a buffered thingy. stdio chunked in a block of data on the dup'd file descriptor. When we went to grab another chunk on the *original* descriptor, we missed input [that is now sitting in the FILE* buffer]. Answer: change the .makefile() in getreply() to: file = self.sock.makefile('rb', 0) This problem is going to affect the original httplib, too. IMO, we're about to replace the sucker, so no worries... Cheers, -g On Fri, 2 Jun 2000, Greg Stein wrote: > It looks like a definite bug. I have *no* idea, tho, why it is doing > that... I did quite a bit of testing with chunked replies. Admittedly, > though, I didn't stack up requests like you've done in your test. I'm > wrapping up mod_dav at the moment, so I don't really have time to look > deeply into this. Mebbe next week? > > Regarding the pipeline request thing. I think it would probably be best to > just drop the whole "hold the previous response and wait for it to be > closed" thing. I don't know why that is in there; probably a leftover > (converted) semantic from the old-style HTTP() class. I'd be quite fine > just axing it and allowing the client to shove ten requests down the pipe > before pulling the first response back out. > > Oh. Wait. Maybe that was it. You can't read the "next" response until the > first one has been read. Well... no need to block putting new responses; > we just need to create a way to "get the next reply" and/or "can I get the > next reply yet?" > > Cheers, > -g > > p.s. Moshe also had a short list of review items. I read thru them, but > not with the code in hand to understand some of his specifics. > > > On Wed, 31 May 2000, Jeremy Hylton wrote: > > >>>>> "GS" == Greg Stein writes: > > > > GS> [ and recall my email last week that I've updated httplib.py and > > GS> posted it to my web pages; it is awaiting review for integration > > GS> into the Python core; it still needs docs and more testing > > GS> scenarios, tho > > > > I've been looking at the httplib code, and I found what may be a bug. > > Not sure, because I'm not sure how the API works for pipelined > > requests. > > > > I've got some test code that looks a bit like this: > > > > def test_new_interface_series(urls): > > paths = [] > > the_host = None > > for url in urls: > > host, path = get_host_and_path(url) > > if the_host is None: > > the_host = host > > else: > > assert host == the_host > > paths.append(path) > > > > conn = httplib.HTTPConnection(the_host) > > for path in paths: > > conn.request('GET', path, headers={'User-Agent': 'httplib/Python'}) > > for path in paths: > > errcode, errmsg, resp = conn.getreply() > > buf = resp.read() > > if errcode == 200: > > print errcode, resp.headers > > else: > > print errcode, `errmsg`, resp > > print resp.getheader('Content-Length'), len(buf) > > print repr(buf[:40]) > > print repr(buf[-40:]) > > print > > conn.close() > > > > test_new_interface_series(['http://www.python.org/', > > 'http://www.python.org/pics/PyBanner054.gif', > > 'http://www.python.org/pics/PythonHi.gif', > > 'http://www.python.org/Jobs.html', > > 'http://www.python.org/doc/', > > 'http://www.python.org/doc/current/', > > ]) > > > > The second loop that reads the replies gets fouled up after a couple > > of responses. I added even more debugging and found that the first > > line of the corrupted response is > > > > > 'ontent-Type: text/html\015\012' > > > > It looks like some part of the program is consuming too much input. I > > haven't been able to figure out what part yet. Hoping that you might > > have some good ideas. > > > > Thinking about this issue, I came up with a potential API problem. > > You must read the body after calling getreply and before calling > > getreply a second time. This kind of implicit requirement is a bit > > tricky. It would help if the implementation could raise an error if > > this happens. It might be even better if it just worked, although it > > seems a bit too magical. > > > > Jeremy > > > > -- > Greg Stein, http://www.lyra.org/ > > > > -- Greg Stein, http://www.lyra.org/ From thomas at xs4all.net Sun Jun 4 00:56:01 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 4 Jun 2000 00:56:01 +0200 Subject: [Python-Dev] Re: Is it just Syntactic Sugar ? In-Reply-To: <3935B383.469032AE@python.org>; from guido@python.org on Wed, May 31, 2000 at 11:49:57PM +0000 References: <3929E47E.993727CF@roguewave.com> <3933F800.9CCE3B6D@cs.byu.edu> <20000530213957.E469@xs4all.nl> <20000531090045.I469@xs4all.nl> <3935B383.469032AE@python.org> Message-ID: <20000604005601.T469@xs4all.nl> On Wed, May 31, 2000 at 11:49:57PM +0000, Guido van Rossum wrote: > I know I shouldn't be posting in this thread, and I won't be there to read > the responses, but here's what I thought would be cool. As the 'lucky, lucky bastard' is probably standing before the altar about now, I'll send this to the dev-list instead. Not that I expect anyone *not* to be at the wedding, but I bet the rest is back sooner ;-) > x+=y is syntactic sugar for x=x.__add_ab__(y); the "ab" means "and becomes" > (an old Algol-68 naming convention; we could pick something better later > but this will do for the explanation). > For immutable types, this is defined as > def __add_ab__(self, other): > return self+other > For mutable types, this is defined as a self-mutating operation, > e.g. for lists it could be > def __add_ab__(self, other): > self.extend(other) > return self This was what I had in mind, and was trying to explain. Does you voicing your opinion mean someone (you ? someone else ?) is working on this, or soon going to work on this ? I had a chat with Michael about fixing up his patch to work all the way (it's currently a proof-of-concept-quick-hack that only works for builtin types) which prompted me to study Python's internals a bit closer. (I hope I dont sound too patronizing when I say I was impressed ;-) I'm curious what should happen with index-assignment and slice-assignment: x[y] += z x[:y] += z (Obviously this wont make sense for a lot of types, or will be too un-obvious to include, but I can imagine matrix-types to happily add this.) Would this call x.__add_item_ab__(y, z) and x.__add_slice_ab__(0, y, z) ? Or would x[y] += z always call x[y].__add_item_ab__() and x[:y] create a new object, a slice of x, and call its __add_ab__() method ? Or would it try all of them, or more, until it gets a good result ? Or am I running ahead of things and should we wait for a working patch first ? :) If I suddenly grow a deep understanding of Python's internals (not ruled out, it's fairly obvious) and hack-up something that works before anyone else, I'll be sure to mail ;) oh-and-congratulations-to-Mrs.-van-Rossum-too-ly yr's, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From gstein at lyra.org Sun Jun 4 01:06:07 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 3 Jun 2000 16:06:07 -0700 (PDT) Subject: [Python-Dev] httplib In-Reply-To: Message-ID: On Sat, 3 Jun 2000, Greg Stein wrote: > I found the problem. Sneaky... > > sock.makefile() does a dup() on the file descriptor, then opens a FILE* > with that. See it coming yet? ... > > FILE* is a buffered thingy. stdio chunked in a block of data on the dup'd > file descriptor. When we went to grab another chunk on the *original* > descriptor, we missed input [that is now sitting in the FILE* buffer]. > > Answer: change the .makefile() in getreply() to: > > file = self.sock.makefile('rb', 0) > > This problem is going to affect the original httplib, too. IMO, we're > about to replace the sucker, so no worries... Oh... actually it won't affect the original since that doesn't pipeline requests. -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Sun Jun 4 01:13:55 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 3 Jun 2000 16:13:55 -0700 (PDT) Subject: [Python-Dev] more on httplib Message-ID: I would like to propose a few changes to the (new) httplib: *) drop HTTPS() -- this class isn't in 1.5.2, so there isn't a reason to provide backwards-compat for it *) revamp the pipeline support: - record the "last response object" ... when a new getreply() is done, then we store the "last" into response.prior - reading of the "HTTP/1.1 " line is deferred, and performed by the response object - the read of that line is lazy - if the response line is read *before* the "prior" response (if any) is "closed", then an exception is raised: ResponseNotReady *) address some of Moshe's concerns: - use class-based exceptions - clarify that HTTPConnection is designed for *blocking* sockets - conn.close() followed by conn.send() will reopen the socket. This could lead to programming errors. I'll add a class-based default flag to disable this behavior. - in request(), we check for errno==32 ... what to do on Windows? I will implement these changes in small chunks so that each can be reviewed in my CVS repository. The history is available at: http://www.lyra.org/cgi-bin/viewcvs.cgi/gjspy/httplib.py/ Cheers, -g -- Greg Stein, http://www.lyra.org/ From mhammond at skippinet.com.au Sun Jun 4 04:03:34 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sun, 4 Jun 2000 12:03:34 +1000 Subject: [Python-Dev] What's New (first draft) In-Reply-To: <20000602231550.A986@newcnri.cnri.reston.va.us> Message-ID: > emphasize the number of contributors to this release; does everyone think > this is a good idea? If I've missed your name, or credited you wrongly, > please let me know. OK - as you insist :-) Bill Tutt and I could do with a credit for the new winreg module. Thanks, Mark. From tim_one at email.msn.com Sun Jun 4 06:09:02 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 4 Jun 2000 00:09:02 -0400 Subject: [Python-Dev] Suggestion: stopping to trust os mtimes In-Reply-To: Message-ID: <000a01bfcdda$9e876060$1d2d153f@tim> [Moshe] > How about having, in addition to the time-stamp, the size of the file? > At least on UNIX, it comes for free with the same stat call. +1 from me. Note that, besides inter-machine clock skew, some filesystems have a timestamp granularity too coarse to distinguish close-in-time writes. For those (& related) reasons, the attentive Pythoneer will have noted that all of the winning 1st-round Software Carpentry "make"-replacement designs provide for alternatives to timestamps. Tom Tromey's has the clearest discussion of the problems with timestamps: http://software-carpentry.codesourcery.com/entries/build/Tromey/Tromey.html In my industrial experience, (timestamp, size) pairs have never failed in practice. However, "my industrial experience" has been entirely in projects where source-control wrappers add a checkin comment block to every checked-in file, and that alone made it exceedingly unlikely that any two successive versions of a file would have the same size. In Python I'm still (a little) worried about cases like SOME_GLOBAL_CONFIG_OPTION = 0 where "0" gets replaced by "1" or "2" or ... there are lots of interesting things you can do to Python programs without changing their size. At Dragon, checked-in Python files were also subject to the "checkin comment block" rule, so no project under source control suffered from this. I suspect it burned people in their pre-source-controlled development projects, though! One group in particular had a project that involved acres of machine-generated Python modules, and I know they suffered from coarse timestamps on their flavor of Unix (so part of their "make" procedure was to nuke all .pyc's on each build). it's-easy-to-laugh-at-problems-you-don't-have-ly y'rs - tim From moshez at math.huji.ac.il Sun Jun 4 06:59:31 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sun, 4 Jun 2000 07:59:31 +0300 (IDT) Subject: [Python-Dev] Suggestion: stopping to trust os mtimes In-Reply-To: <000a01bfcdda$9e876060$1d2d153f@tim> Message-ID: On Sun, 4 Jun 2000, Tim Peters wrote: [Moshe] > How about having, in addition to the time-stamp, the size of the file? > At least on UNIX, it comes for free with the same stat call. [Tim] > +1 from me. Now there is the big problem, that this will be changing the header size. I thought that this would be a good time anyway, since 1.5.2 pycs aren't compatible with 1.6, but changing the header size is a bigger thing. so-this-waits-until-guido-comes-back-i-guess-ly y'rs, Z. -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com From bwarsaw at python.org Sun Jun 4 22:51:30 2000 From: bwarsaw at python.org (Barry A. Warsaw) Date: Sun, 4 Jun 2000 16:51:30 -0400 (EDT) Subject: [Python-Dev] Revised 1.6 jobs list References: <3938D60E.391AAF31@lemburg.com> Message-ID: <14650.49490.725648.798719@anthem.python.org> >>>>> "JH" == Jeremy Hylton writes: JH> One of the problems I'm having is keeping track of which JH> patches are still outstanding. SF has a patch manager but I haven't played with it much. In fact, I can't seem to find it for the Python project, but it's there in the Mailman project. -Barry From gstein at lyra.org Sun Jun 4 22:55:09 2000 From: gstein at lyra.org (Greg Stein) Date: Sun, 4 Jun 2000 13:55:09 -0700 (PDT) Subject: [Python-Dev] Revised 1.6 jobs list In-Reply-To: <14650.49490.725648.798719@anthem.python.org> Message-ID: On Sun, 4 Jun 2000, Barry A. Warsaw wrote: > >>>>> "JH" == Jeremy Hylton writes: > > JH> One of the problems I'm having is keeping track of which > JH> patches are still outstanding. > > SF has a patch manager but I haven't played with it much. In fact, I > can't seem to find it for the Python project, but it's there in the > Mailman project. You can administratively turn those things on/off, I thought. You're an admin, Barry, so you should be able to turn the thing on. Cheers, -g p.s. and yah.. there are damn too many projects at SF that are just a project name. no code, no description, all features enabled for no purpose, etc... Newbie coders, me thinks. Python is Goodness because it does disable the unused items. -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Mon Jun 5 01:30:08 2000 From: gstein at lyra.org (Greg Stein) Date: Sun, 4 Jun 2000 16:30:08 -0700 (PDT) Subject: [Python-Dev] release forms? (was: [Patches] New sys method to return total reference count in debug builds.) Message-ID: Given the New World Order, how does that impact the need for these release statements and/or wet signatures? Or a better way to put it, who "owns" Python now? Given a "who", then we can ask that person/entity whether they want release statements. Given that Python is now on SourceForge, and there are multiple people (at CNRI and otherwise) that can directly make modifications, then the release below is certainly a bit "off". For example, David Ascher has commit privs, so at his "sole discretion, [he may] decide whether or not to incorporiate this contribution..." :-) Thoughts? Cheers, -g p.s. IMO, I'd like to see Guido own the Copyright for all current and future Python development -- Greg Stein, http://www.lyra.org/ ---------- Forwarded message ---------- Date: Mon, 5 Jun 2000 09:18:30 +1000 From: Mark Hammond To: patches at python.org Subject: [Patches] New sys method to return total reference count in debug builds. [... snip ...] Release info: I confirm that, to the best of my knowledge and belief, this contribution is free of any claims of third parties under copyright, patent or other rights or interests ("claims"). To the extent that I have any such claims, I hereby grant to CNRI a nonexclusive, irrevocable, royalty-free, worldwide license to reproduce, distribute, perform and/or display publicly, prepare derivative versions, and otherwise use this contribution as part of the Python software and its related documentation, or any derivative versions thereof, at no cost to CNRI or its licensed users, and to authorize others to do so. I acknowledge that CNRI may, at its sole discretion, decide whether or not to incorporate this contribution in the Python software and its related documentation. I further grant CNRI permission to use my name and other identifying information provided to CNRI by me for use in connection with the Python software and its related documentation. Mark. _______________________________________________ Patches mailing list Patches at python.org http://www.python.org/mailman/listinfo/patches From bwarsaw at python.org Mon Jun 5 05:09:36 2000 From: bwarsaw at python.org (bwarsaw at python.org) Date: Sun, 4 Jun 2000 23:09:36 -0400 (EDT) Subject: [Python-Dev] Revised 1.6 jobs list References: <14650.49490.725648.798719@anthem.python.org> Message-ID: <14651.6640.709657.306682@anthem.python.org> >>>>> "GS" == Greg Stein writes: GS> You can administratively turn those things on/off, I GS> thought. You're an admin, Barry, so you should be able to turn GS> the thing on. I'm happy to if people think it will help. SF's patch management is a durn site better than Python's is now . I'd also consider shutting off Jitterbug on python.org but I'm not sure how to (or if we should) migrate the current bug set to SF. -Barry From gstein at lyra.org Mon Jun 5 08:13:39 2000 From: gstein at lyra.org (Greg Stein) Date: Sun, 4 Jun 2000 23:13:39 -0700 (PDT) Subject: [Python-Dev] Revised 1.6 jobs list In-Reply-To: <14651.6640.709657.306682@anthem.python.org> Message-ID: On Sun, 4 Jun 2000 bwarsaw at python.org wrote: > >>>>> "GS" == Greg Stein writes: > > GS> You can administratively turn those things on/off, I > GS> thought. You're an admin, Barry, so you should be able to turn > GS> the thing on. > > I'm happy to if people think it will help. SF's patch management is a > durn site better than Python's is now . I'd also consider > shutting off Jitterbug on python.org but I'm not sure how to (or if we > should) migrate the current bug set to SF. IMO, use the provided tools. The Patch Manager is more than we have now. It also allows assignment, which can be nice :-) (compared to the arbitrary "who is taking care of this patch?" thing today) The SF bug database certainly works, and it provides additional "locality" for the code + bugs + patches. Cheers, -g -- Greg Stein, http://www.lyra.org/ From jeremy at beopen.com Mon Jun 5 06:43:45 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 5 Jun 2000 00:43:45 -0400 (EDT) Subject: [Python-Dev] Revised 1.6 jobs list In-Reply-To: <3938D60E.391AAF31@lemburg.com> References: <20000602232521.B986@newcnri.cnri.reston.va.us> <3938D60E.391AAF31@lemburg.com> Message-ID: <14651.12289.191631.704477@localhost.localdomain> [Entry from AMK's 1.6 jobs list:] > Conservative garbage collection of cycles (maybe -- I don't know what GvR > thinks about this) I believe Guido would like to see a version of Neil's patches integrated into Python 1.6, most likely turned off by default but with a configure flag to enable. I would like to check the patch in soon but I have had some trouble with segfaults. I ran a simple benchmark using the compiler code in the nondist tree to compile itself. I get a crash during a routine collect pass, where it looks like the GC header info is getting trashed. I haven't had much time to track it any farther. If anyone else is interested, I'd love to hear about successes using the GC patch with other large programs. I'd like to run at least Gadfly and Grail successfully before committing the patch. I wonder if "conservative" is the right word to describe the GC approach? I think conservative means that the garbage collector is not told what is a pointer and what is not, so it must conservatively assume that every bit pattern could represent a pointer. The GC patch is not conservative in this sense. It does have a mechanism that is "conservative" in a very broad sense, i.e. it does not attempt to trace every reference, but depends on the ref count fields to account for references held in untraced variables on the C stack. I'm not sure what the right terminology for this approach is. I also worry that the performance impact of the GC patch is not at all understood. I don't know what informed the choice of heuristics for deciding how often to collect and how to move objects between generations. (The current scheme has three generations.) It would be good to get a working patch in before the next alpha release and then gather a lot of data to help make good choices about these parameters. Jeremy PS Even if Guido doesn't think the GC patch should go in, we've got a golden opportunity. I caught him in a state of newly-wedded bliss this morning and convinced him to let me check in my non-optional braces patch while he's on his honeymoon. He's so happy he'll let us get away with anything. PPS I don't know if we should really carry on about personal matters on a development list, but I hope no one minds if I indulge briefly: Guido & Kim's wedding yesterday was beautiful and fun, held outside in meadow looking out on hills and woods. They are great couple and I'm sure they'll be very happy. From jeremy at beopen.com Mon Jun 5 06:58:11 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 5 Jun 2000 00:58:11 -0400 (EDT) Subject: [Python-Dev] Re: httplib (was: Adding LDAP to the Python core... ?!) In-Reply-To: References: Message-ID: <14651.13155.253651.575394@localhost.localdomain> >>>>> "GS" == Greg Stein writes: GS> I found the problem. Sneaky... sock.makefile() does a dup() on GS> the file descriptor, then opens a FILE* with that. See it coming GS> yet? ... Bingo! I was suspicious of all these dup'd file descriptors, but missed the connection to a FILE* object. [In a previous message you wrote:] >> >> Regarding the pipeline request thing. I think it would probably >> be best to just drop the whole "hold the previous response and >> wait for it to be closed" thing. [...] >> >> Oh. Wait. Maybe that was it. You can't read the "next" response >> until the first one has been read. Well... no need to block >> putting new responses; we just need to create a way to "get the >> next reply" and/or "can I get the next reply yet?" >> Maybe I should clarify the concern I had here. I think we're on the same page, but I'm not sure. The problem with pipelined requests is that the client must be sure to read all of response I before it can call getreply to get response I+1. I imagine that it could add a lot of complexity to use code to implement this requirement, e.g. when multiple threads are sharing a single connection. It would be good if the library could do something reasonable about the multiplexing. In the absence of making it just work, the library could raise an error that makes clear what has gone wrong -- that the client isn't using the interface properly. Jeremy From jeremy at beopen.com Mon Jun 5 07:00:06 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 5 Jun 2000 01:00:06 -0400 (EDT) Subject: [Python-Dev] Re: Is it just Syntactic Sugar ? In-Reply-To: <20000604005601.T469@xs4all.nl> References: <3929E47E.993727CF@roguewave.com> <3933F800.9CCE3B6D@cs.byu.edu> <20000530213957.E469@xs4all.nl> <20000531090045.I469@xs4all.nl> <3935B383.469032AE@python.org> <20000604005601.T469@xs4all.nl> Message-ID: <14651.13270.353056.246432@localhost.localdomain> >>>>> "TW" == Thomas Wouters writes: TW> On Wed, May 31, 2000 at 11:49:57PM +0000, Guido van Rossum TW> wrote: >> I know I shouldn't be posting in this thread, and I won't be >> there to read the responses, but here's what I thought would be >> cool. >> x+=y is syntactic sugar for x=x.__add_ab__(y); the "ab" means >> "and becomes" (an old Algol-68 naming convention; we could pick >> something better later but this will do for the explanation). [...] TW> This was what I had in mind, and was trying to explain. Does you TW> voicing your opinion mean someone (you ? someone else ?) is TW> working on this, or soon going to work on this ? I don't believe anyone at PythonLabs is working on this now, certainly not Guido or I. Jeremy From jeremy at beopen.com Mon Jun 5 06:53:32 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 5 Jun 2000 00:53:32 -0400 (EDT) Subject: [Python-Dev] Revised 1.6 jobs list In-Reply-To: References: Message-ID: <14651.12876.575925.701737@localhost.localdomain> >>>>> "GS" == Greg Stein writes: GS> On Sat, 3 Jun 2000, Jeremy Hylton wrote: >> ... Sorry for the excuses. I think better tools would help a >> lot, but we'll have to get more people checkin privileges >> regardless. GS> There are several issues with expanded checkin privs: GS> 1) trust: will the person make sure it is Right And Proper to do GS> the checkin? (have they reviewed the code? is a a Good Change? GS> etc) The counter here is that we don't want people that will GS> simply take stuff arriving at patches@ and checking them in. Many of the people who ultimately have checkin privileges should limit themselves to their particular domains. There are a bunch of modules that are owned by other people, e.g. Eric's netrc module, your new httplib, MAL for Unicode, etc. We'll probably develop a second group of developers who have broader privileges to make changes, but they'll know how they are. Ultimately, I think I agree with Mark's suggestion that we be a little more liberal with changes and risk backing out the occasional changes. (For some definition of "a little more" :-). GS> 2) more people reviewing changes on the -checkins mailing GS> list. Assuming that you want more than one pair of eyeballs GS> looking at patches/code, that more people with commit privs GS> increases the rate of commits, then you need more reviewers to GS> keep up (because the reviewers probably are not going to review GS> ALL checkins) You're doing a great job so far. We'll just have to get you to spend more time on it <0.8 wink>. GS> 3) increasing dependence on -checkins means that patches MUST be GS> smaller chunks. they MUST be single-purpose patches. practically GS> nobody will review a 200k patch, or patches that fix N different GS> things at once. A small, focused patch is easily reviewed. GS> For example: Trent has recently mailed a bunch of patches to GS> the patches list. This is Goodness: each one is focused and can GS> be individually reviewed. Since they are not a single, giant GS> blob, it also keeps them short and reviewable... each can have a GS> +1/-1 independent of the others. I agree in principle, but there are times when it will make more sense to commit a set of changes as one big patch. The GC patches are going to affect a bunch of files, but probably ought to be done as one big commit. Jeremy From jeremy at beopen.com Mon Jun 5 07:03:46 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 5 Jun 2000 01:03:46 -0400 (EDT) Subject: [Python-Dev] release forms? (was: [Patches] New sys method to return total reference count in debug builds.) In-Reply-To: References: Message-ID: <14651.13490.858960.390030@localhost.localdomain> Off the top of my head, I'd say that your questions aren't going to get answered until Guido gets back and gets a chance to answer them. In the interim, I think we should stick with the current approach. In the long run, of course, you won't need to grant CNRI permission to do anything with a submission. Jeremy From nascheme at enme.ucalgary.ca Mon Jun 5 08:35:00 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Mon, 5 Jun 2000 00:35:00 -0600 Subject: [Python-Dev] Revised 1.6 jobs list In-Reply-To: <14651.12289.191631.704477@localhost.localdomain>; from jeremy@beopen.com on Mon, Jun 05, 2000 at 12:43:45AM -0400 References: <20000602232521.B986@newcnri.cnri.reston.va.us> <3938D60E.391AAF31@lemburg.com> <14651.12289.191631.704477@localhost.localdomain> Message-ID: <20000605003500.B6169@acs.ucalgary.ca> On Mon, Jun 05, 2000 at 12:43:45AM -0400, Jeremy Hylton wrote: > [Entry from AMK's 1.6 jobs list:] > > Conservative garbage collection of cycles (maybe -- I don't know what GvR > > thinks about this) > > I believe Guido would like to see a version of Neil's patches > integrated into Python 1.6, most likely turned off by default but with > a configure flag to enable. Okay, I was thinking he had passed it over for 1.6 since I didn't hear any comments from him for a long time. > I would like to check the patch in soon but I have had some trouble > with segfaults. I ran a simple benchmark using the compiler code in > the nondist tree to compile itself. I get a crash during a routine > collect pass, where it looks like the GC header info is getting > trashed. I haven't had much time to track it any farther. Yow. I will try to see if I can reproduce this. What platform? > If anyone else is interested, I'd love to hear about successes using > the GC patch with other large programs. I'd like to run at least > Gadfly and Grail successfully before committing the patch. I've used it with Grail, Sketch, IDLE as well as some of my own software. I may have introduced that SEGV bug when porting the patch to a newer version of the CVS sources. I will check it out. > I also worry that the performance impact of the GC patch is not > at all understood. Me too. > I don't know what informed the choice of heuristics for > deciding how often to collect and how to move objects between > generations. (The current scheme has three generations.) It > would be good to get a working patch in before the next alpha > release and then gather a lot of data to help make good choices > about these parameters. Getting good performance will be a matter of tuning how often the collector runs. I don't think there is any substitute for running real programs and collecting data. Programs that allocate lots of objects will be most interesting. It would probably be a good idea to add more support for keeping collection statistics. Unfortunately my time is very limited right now. > PS Even if Guido doesn't think the GC patch should go in, we've got a > golden opportunity. I caught him in a state of newly-wedded bliss > this morning and convinced him to let me check in my non-optional > braces patch while he's on his honeymoon. He's so happy he'll let us > get away with anything. I wonder if he will be scowling less at the conferences now that he is hitched. :) Neil From gstein at lyra.org Mon Jun 5 08:42:35 2000 From: gstein at lyra.org (Greg Stein) Date: Sun, 4 Jun 2000 23:42:35 -0700 (PDT) Subject: [Python-Dev] Revised 1.6 jobs list In-Reply-To: <14651.12876.575925.701737@localhost.localdomain> Message-ID: On Mon, 5 Jun 2000, Jeremy Hylton wrote: > >>>>> "GS" == Greg Stein writes: >... > GS> 1) trust: will the person make sure it is Right And Proper to do > GS> the checkin? (have they reviewed the code? is a a Good Change? > GS> etc) The counter here is that we don't want people that will > GS> simply take stuff arriving at patches@ and checking them in. > > Many of the people who ultimately have checkin privileges should limit > themselves to their particular domains. There are a bunch of modules > that are owned by other people, e.g. Eric's netrc module, your new > httplib, MAL for Unicode, etc. Agreed. Each person with commit privs will definitely need to operate under the premise of " is the area that I'm allowed to commit changes for." For example, I believe that Guido made it very clear, at some point in the past, that *nobody* but Guido will have commit access to the Parser/ area. Note that when I say "commit access" here, this is the same as "areas that I can commit for." In fact, it is really just an extension of the Basic Python Principle, "we're all adults here, don't do what you know you shouldn't be doing." :-) >... > Ultimately, I think I agree with Mark's suggestion that we be a little > more liberal with changes and risk backing out the occasional > changes. (For some definition of "a little more" :-). This only works if you have reasonably assurance of review via the -checkins alias. Otherwise, you simply need to accept that instabilities will creep in. (and that broader alpha/beta/etc cycles may be desirable) In the Apache group, we have a very good set of eyeballs watching the checkins. I'd say that each checkin is reviewed by two or three people in detail. Invariably, there are several checkins each week that result in a thread discussing: (a) you broke it, (b) why was it done that way, (c) couldn't it be done this way, (d) this appears to be missing, (e) etc. IMO, for that to happen several (or more!) times every week means that we have a good set of eyeballs. Maybe it also means the committers just suck lollipops, but I'd like to think otherwise :-) > GS> 2) more people reviewing changes on the -checkins mailing > GS> list. Assuming that you want more than one pair of eyeballs > GS> looking at patches/code, that more people with commit privs > GS> increases the rate of commits, then you need more reviewers to > GS> keep up (because the reviewers probably are not going to review > GS> ALL checkins) > > You're doing a great job so far. We'll just have to get you to spend > more time on it <0.8 wink>. hehe... well, I just completed a big-ass wave of mod_dav work. In fact, I don't know what else to do to the thing. I made a snapshot and am waiting for feedback, if any, before declaring it 1.0. Maybe I'll add some comments to the code :-) Anyways... that's why I've been working on httplib. Free time! :-) > GS> 3) increasing dependence on -checkins means that patches MUST be > GS> smaller chunks. they MUST be single-purpose patches. practically > GS> nobody will review a 200k patch, or patches that fix N different > GS> things at once. A small, focused patch is easily reviewed. > > GS> For example: Trent has recently mailed a bunch of patches to > GS> the patches list. This is Goodness: each one is focused and can > GS> be individually reviewed. Since they are not a single, giant > GS> blob, it also keeps them short and reviewable... each can have a > GS> +1/-1 independent of the others. > > I agree in principle, but there are times when it will make more sense > to commit a set of changes as one big patch. The GC patches are going > to affect a bunch of files, but probably ought to be done as one big > commit. Actually, I will disagree here. I've reviewed the GC patch a couple times. There are a number of changes in there that can/should be done separately from the "real" GC patch. For example, there were a number of changes to use PyMem_Allco() instead of PyMEM_Alloc(). Or whatever. Point being, that they had *nothing* to do with GC -- they could be checked in *independent* of the actual GC work. The changes to the PyTypeObject declaration (adding tp_clean) can also be done without doing the "real work". After these "zero impact" changes are completed, then the GC patch will be greatly reduced in size and complexity. It makes it much more reviewable. The point being: even big patches can usually be broken down into layers. One layer after another, adding "platform" functionality until you get to the meat of the matter. The GC patch was a definite case of this. Really huge patches are okay if they have a *seriously* narrow focus. For example, Skip's patch to use PyArg_ParseTuple() with the ":method" stuff. That was pretty brain-dead to review. The hardest part was that the context-diff wasn't contextual enough to verify that the name in the ParseTuple matched the method that it occurred in. [ I found a case where they did not match. not easy... ] Cheers, -g -- Greg Stein, http://www.lyra.org/ From pf at artcom-gmbh.de Mon Jun 5 09:28:38 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Mon, 5 Jun 2000 09:28:38 +0200 (MEST) Subject: [Python-Dev] Suggestion: stopping to trust os mtimes In-Reply-To: from Greg Stein at "Jun 2, 2000 2:32:52 pm" Message-ID: Hi, Greg Stein: > He does have a point, but I think the wrong solution :-) > > While the clock may be monotonically increasing on one system, it isn't > always the case when things like NFS come into play. That is a well known and common trap. Don't use NFS for Software development unless you've read and understood RFC 868. ;-) BTW.: Last year someone posted a pure Python implementation of RFC 868 time server and clients to c.l.p. This might be useful on those WinXX boxes. > I recall a case back '95 when I was editing a .py over an NFS mount and > running the code on the target machine. The clocks on the two boxes were > off by about three seconds. I was going thru the edit/run/edit/run cycle > so quickly, that at one point, I saved a .py file that was older than the > associated .pyc file. > > Needless to say, I was really confused that my recent edit didn't produce > the desired result :-) Sure. ;-) But the same would have happenend, if you edited a .c source file and if your target computer has C-compiler/linker, which is fast enough to have a edit/compile/run cycle completed faster than the clock difference. This is not uncommon today. So the problem is not Python's fault and so I see no need to fix it there. One thing could be added though: If Python 'stat's a .py file, which has a time stamp in the future, it could issue a warning similar to that displayed by 'make': *** Warning: File `%s' has modification time in the future (%ld > %ld Possibly this message could point the user to RFC 868 and the 'netdate' Unix command. But that would be sugar on the cake. Regards, Peter From moshez at math.huji.ac.il Mon Jun 5 12:21:32 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Mon, 5 Jun 2000 13:21:32 +0300 (IDT) Subject: [Python-Dev] Suggestion: stopping to trust os mtimes In-Reply-To: Message-ID: On Mon, 5 Jun 2000, Peter Funk wrote: > Greg Stein: > > He does have a point, but I think the wrong solution :-) > > > > While the clock may be monotonically increasing on one system, it isn't > > always the case when things like NFS come into play. > > That is a well known and common trap. Don't use NFS for Software > development unless you've read and understood RFC 868. ;-) "Make"'s philosphy for basing the decision on which files need to be remade on the timestapmps is not necessarily the best -- but the user can replace mkae if it doesn't "do the right thing". Since Python takes on some of Make's roles (regenrating files only if those need to be regenerated), it is subject to the same problems. So it is Python's fault, and that's where the problem should be fixed. -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com From bwarsaw at python.org Mon Jun 5 15:21:05 2000 From: bwarsaw at python.org (bwarsaw at python.org) Date: Mon, 5 Jun 2000 09:21:05 -0400 (EDT) Subject: [Python-Dev] Revised 1.6 jobs list References: <14651.6640.709657.306682@anthem.python.org> Message-ID: <14651.43329.783797.949349@anthem.python.org> >>>>> "GS" == Greg Stein writes: GS> IMO, use the provided tools. The Patch Manager is more than we GS> have now. It also allows assignment, which can be nice :-) GS> (compared to the arbitrary "who is taking care of this patch?" GS> thing today) GS> The SF bug database certainly works, and it provides GS> additional "locality" for the code + bugs + patches. I've turned on the SF patch manager and bug database. -Barry From bwarsaw at python.org Mon Jun 5 15:32:54 2000 From: bwarsaw at python.org (Barry A. Warsaw) Date: Mon, 5 Jun 2000 09:32:54 -0400 (EDT) Subject: [Python-Dev] Revised 1.6 jobs list References: <14651.12876.575925.701737@localhost.localdomain> Message-ID: <14651.44038.828370.123514@anthem.python.org> >>>>> "JH" == Jeremy Hylton writes: JH> Many of the people who ultimately have checkin privileges JH> should limit themselves to their particular domains. There JH> are a bunch of modules that are owned by other people, JH> e.g. Eric's netrc module, your new httplib, MAL for Unicode, JH> etc. Right. I think GregS was the one advocating a more Apache-like model, where people have the ability to check into the whole tree, but generally don't or risk the derision of their peers. Python's big enough for people to assert their expertise over various corners. JH> Ultimately, I think I agree with Mark's suggestion that we be JH> a little more liberal with changes and risk backing out the JH> occasional changes. (For some definition of "a little more" JH> :-). It all depends on the scope of the changes. If it's fairly localized to a single library module, then we don't worry as much. More important there will be the API design. If it's a more sweeping change like GC or Unicode, or a change in the language definition, then there /has/ to be broader support. For Big Changes, I really like the RFC idea someone suggested. Gets everything documented for newbies and posterity. Has a shelf life, etc. -Barry From bwarsaw at python.org Mon Jun 5 15:36:28 2000 From: bwarsaw at python.org (Barry A. Warsaw) Date: Mon, 5 Jun 2000 09:36:28 -0400 (EDT) Subject: [Python-Dev] Revised 1.6 jobs list References: <14651.12876.575925.701737@localhost.localdomain> Message-ID: <14651.44252.78362.195436@anthem.python.org> >>>>> "GS" == Greg Stein writes: GS> In the Apache group, we have a very good set of eyeballs GS> watching the checkins. I'd say that each checkin is reviewed GS> by two or three people in detail. Invariably, there are GS> several checkins each week that result in a thread discussing: GS> (a) you broke it, (b) why was it done that way, (c) couldn't GS> it be done this way, (d) this appears to be missing, (e) etc. Maybe we also need to expand on the test suite, do nightly builds, and post the results. Kind of the way Mozilla does it. Well, Python probably doesn't change so radically every night, but a more expanded test suite with web based feedback would be cool. -Barry From bwarsaw at python.org Mon Jun 5 15:38:20 2000 From: bwarsaw at python.org (Barry A. Warsaw) Date: Mon, 5 Jun 2000 09:38:20 -0400 (EDT) Subject: [Python-Dev] Re: Is it just Syntactic Sugar ? References: <3929E47E.993727CF@roguewave.com> <3933F800.9CCE3B6D@cs.byu.edu> <20000530213957.E469@xs4all.nl> <20000531090045.I469@xs4all.nl> <3935B383.469032AE@python.org> <20000604005601.T469@xs4all.nl> <14651.13270.353056.246432@localhost.localdomain> Message-ID: <14651.44364.408119.422821@anthem.python.org> >>>>> "JH" == Jeremy Hylton writes: >>>>> "TW" == Thomas Wouters writes: TW> This was what I had in mind, and was trying to explain. Does TW> you voicing your opinion mean someone (you ? someone else ?) TW> is working on this, or soon going to work on this ? JH> I don't believe anyone at PythonLabs is working on this now, JH> certainly not Guido or I. I'm not tracking this either. -Barry From bwarsaw at python.org Mon Jun 5 15:41:39 2000 From: bwarsaw at python.org (Barry A. Warsaw) Date: Mon, 5 Jun 2000 09:41:39 -0400 (EDT) Subject: [Python-Dev] release forms? (was: [Patches] New sys method to return total reference count in debug builds.) References: Message-ID: <14651.44563.556790.469651@anthem.python.org> >>>>> "GS" == Greg Stein writes: GS> Given the New World Order, how does that impact the need for GS> these release statements and/or wet signatures? GS> Or a better way to put it, who "owns" Python now? Given a GS> "who", then we can ask that person/entity whether they want GS> release statements. GS> Given that Python is now on SourceForge, and there are GS> multiple people (at CNRI and otherwise) that can directly make GS> modifications, then the release below is certainly a bit GS> "off". For example, David Ascher has commit privs, so at his GS> "sole discretion, [he may] decide whether or not to GS> incorporiate this contribution..." :-) I talked to Guido briefly about this. Since 1.6 is the last "CNRI release", he wants to continue along the current path for the time being. I'm sure he'll be just as happy to chuck all this crap as Greg, and we probably will for 1.7. -Barry From fdrake at beopen.com Mon Jun 5 18:40:26 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 5 Jun 2000 12:40:26 -0400 (EDT) Subject: [Python-Dev] Revised 1.6 jobs list In-Reply-To: <14648.35974.486959.379543@anthem.python.org> References: <20000602232521.B986@newcnri.cnri.reston.va.us> <14648.35974.486959.379543@anthem.python.org> Message-ID: <14651.55290.728256.183107@cj42289-a.reston1.va.home.com> Barry A. Warsaw writes: > Did we ever decide on building in thread support by default? I'd > really like to see threads enabled by default in 1.6 and I /think/ > it'll just take some autoconf hacking, which I'm willing to do. Are > there any objections to building in threads support by default if > autoconf detects threads? test_fork1 fails on Linux with threads on SMP machines. (It's irrelevant without threads.) This is a hard failure -- the process can either SEGV or hang forever. Is this a showstopper? SMP boxes are becoming increasingly common both as servers and workstations. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From bwarsaw at python.org Mon Jun 5 18:55:49 2000 From: bwarsaw at python.org (bwarsaw at python.org) Date: Mon, 5 Jun 2000 12:55:49 -0400 (EDT) Subject: [Python-Dev] Revised 1.6 jobs list References: <20000602232521.B986@newcnri.cnri.reston.va.us> <14648.35974.486959.379543@anthem.python.org> <14651.55290.728256.183107@cj42289-a.reston1.va.home.com> Message-ID: <14651.56213.661929.481476@anthem.python.org> >>>>> "Fred" == Fred L Drake, Jr writes: Fred> test_fork1 fails on Linux with threads on SMP machines. Fred> (It's irrelevant without threads.) This is a hard failure Fred> -- the process can either SEGV or hang forever. Is this a Fred> showstopper? I would think so, regardless of whether threads are built-in by default or not. From fdrake at beopen.com Mon Jun 5 19:59:31 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 5 Jun 2000 13:59:31 -0400 (EDT) Subject: [Python-Dev] What's New (first draft) In-Reply-To: References: <20000602231550.A986@newcnri.cnri.reston.va.us> Message-ID: <14651.60035.502321.510452@cj42289-a.reston1.va.home.com> Mark Hammond writes: > Bill Tutt and I could do with a credit for the new winreg module. The documentation for winreg could stand to be written as well -- care to extract the docstrings, or is that in my court? ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From DavidA at ActiveState.com Mon Jun 5 21:26:13 2000 From: DavidA at ActiveState.com (David Ascher) Date: Mon, 5 Jun 2000 12:26:13 -0700 Subject: [Python-Dev] Revised 1.6 jobs list In-Reply-To: <14651.55290.728256.183107@cj42289-a.reston1.va.home.com> Message-ID: > test_fork1 fails on Linux with threads on SMP machines. (It's > irrelevant without threads.) This is a hard failure -- the process > can either SEGV or hang forever. > Is this a showstopper? SMP boxes are becoming increasingly common > both as servers and workstations. Why does the test fail? I'd hate to see the thousands (nay, hundreds of thousands) of users complain that foo isn't working just because the test for a rarely used feature on a rare platform is broken. --david From nascheme at enme.ucalgary.ca Mon Jun 5 23:03:13 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Mon, 5 Jun 2000 15:03:13 -0600 Subject: [Python-Dev] Re: Revised 1.6 jobs list Message-ID: <20000605150313.A15917@acs.ucalgary.ca> [David Ascher] >> test_fork1 fails on Linux with threads on SMP machines. (It's >> irrelevant without threads.) This is a hard failure -- the >> process can either SEGV or hang forever. Is this a showstopper? >> SMP boxes are becoming increasingly common both as servers and >> workstations. > > Why does the test fail? I'd hate to see the thousands (nay, > hundreds of thousands) of users complain that foo isn't working > just because the test for a rarely used feature on a rare > platform is broken. Threads and fork() don't seem to mix on Linux. Even on a UP machine things seem strange: http://www.deja.com/[ST_rn=ps]/getdoc.xp?AN=613477888&fmt=text I tried to reproduce the problem with a C program but could not. When things hang the forking thread is stuck in wait4() while the child process is suspended: #0 0x4027d9ba in sigsuspend () from /lib/libc.so.6 #1 0x40232c77 in __pthread_wait_for_restart_signal () from /lib/libpthread.so.0 #2 0x4023406e in __pthread_lock () from /lib/libpthread.so.0 #3 0x4023186a in pthread_mutex_lock () from /lib/libpthread.so.0 #4 0x806fbaa in PyThread_release_lock (lock=0x81ebb68) at thread_pthread.h:339 #5 0x805617b in eval_code2 (co=0x81eca68, globals=0x81c4f64, locals=0x0, args=0x81be278, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, owner=0x0) at ceval.c:630 #6 0x805ac19 in call_function (func=0x81ebb2c, arg=0x81be26c, kw=0x0) at ceval.c:2552 #7 0x805a5a4 in PyEval_CallObjectWithKeywords (func=0x81ebb2c, arg=0x81be26c, kw=0x0) at ceval.c:2390 #8 0x80b2c7b in t_bootstrap (boot_raw=0x81ebb50) at ./threadmodule.c:224 #9 0x40230c8f in pthread_start_thread () from /lib/libpthread.so.0 I don't know if this is a LinuxThread problem or a Python problem. Neil -- The internet: Learn what you know. Share what you don't. From DavidA at ActiveState.com Mon Jun 5 23:23:11 2000 From: DavidA at ActiveState.com (David Ascher) Date: Mon, 5 Jun 2000 14:23:11 -0700 Subject: [Python-Dev] RE: Revised 1.6 jobs list In-Reply-To: <20000605150313.A15917@acs.ucalgary.ca> Message-ID: > Threads and fork() don't seem to mix on Linux. Even on a > UP machine things seem strange: I believe it. My general point however is that even if the problem can't be fixed because Linux is broken in some way, the test suite should be fixed even if it means to ignore failures of test_fork1 if the system was configured --with-thread. --david From mhammond at skippinet.com.au Tue Jun 6 01:47:44 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Tue, 6 Jun 2000 09:47:44 +1000 Subject: [Python-Dev] Re: Revised 1.6 jobs list In-Reply-To: <20000605150313.A15917@acs.ucalgary.ca> Message-ID: > I tried to reproduce the problem with a C program but could not. > When things hang the forking thread is stuck in wait4() while the > child process is suspended: This looks very suspect. > > #0 0x4027d9ba in sigsuspend () from /lib/libc.so.6 > #1 0x40232c77 in __pthread_wait_for_restart_signal () > from /lib/libpthread.so.0 > #2 0x4023406e in __pthread_lock () from /lib/libpthread.so.0 > #3 0x4023186a in pthread_mutex_lock () from /lib/libpthread.so.0 > #4 0x806fbaa in PyThread_release_lock (lock=0x81ebb68) at > thread_pthread.h:339 > #5 0x805617b in eval_code2 (co=0x81eca68, globals=0x81c4f64, And very much like the Python thread-state is not being managed correctly with fork. From my understanding of fork (which is small), and of the Python thread-state management, this doesnt surprise me. Given the stack trace, it appears that Python is doing its periodic thread-release as part of running around the main loop. In the process of _releasing_ the thread-lock, it needs to _acquire_ a mutex. I dont know the Python threading on pthreads at all - would this be correct (it would seem likely that such an implementation would be done). But in the process of acquiring that mutex, we call __pthread_wait_for_restart_signal() Is it possible that is is something as simple as thread-idents changing underneath Python when using fork? It seems to me that the thread thinks it is either new, or stale? Just my 2c worth - and given my knowledge of Linux and pthreads, plus the state of our dollar at the moment, it has better be AUD $0.02 :-) Mark. From trentm at activestate.com Tue Jun 6 02:14:03 2000 From: trentm at activestate.com (Trent Mick) Date: Mon, 5 Jun 2000 17:14:03 -0700 Subject: [Python-Dev] PyMarshal_WriteLongToFile: writes 'long' or 32-bit integer? In-Reply-To: References: <20000602111417.A17233@activestate.com> Message-ID: <20000605171403.A21808@activestate.com> On Sat, Jun 03, 2000 at 10:56:15AM +0300, Moshe Zadka wrote: > On Fri, 2 Jun 2000, Trent Mick wrote: > > > 3. - change PyMarshal_WriteLongToFile to raise an exception if the long > > overflows a 32-bit range > > +1 on that, finally non-portable integers will cause an exception. > Okay, I have to reiterate and ask again because I have the suspicion that I may be missing the point and you all may not realize that. Stop me when I go astray: - the PyMarshal interface is used for all the .pyc content writing - PyMarshal_WriteLongToFile is only used for writing the magic number and the time stamp - the rest of the .pyc is written via PyMarshal_WriteObjectToFile - PyMarshal_WriteLongToFile will currently silently truncate a 64-bit long to 32-bits - PyMarshal_WriteObjectToFile, when writing a PyInt and hence a C long, will *NOT* truncate the 64-bit integer but will write the whole thing - On reading a .pyc the PyMarshal_ReadObjectFromFile will complain on stderr when a 64-bit integral value is read and the current platform is 32-bit. The question is: Do we want PyMarshal_WriteLongToFile *AND* PyMarshal_WriteObjectToFile to raise an exception when a long value overflows 32-bits? Up til now I was only proposing the former. Trent -- Trent Mick trentm at activestate.com From esr at thyrsus.com Tue Jun 6 03:02:31 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 5 Jun 2000 21:02:31 -0400 Subject: [Python-Dev] ascii.py Message-ID: <20000605210231.A25895@thyrsus.com> Latest version. Adds isctrl() and ismeta() functions (because I use them...) Um. What's the checkin procedure for library modules? And do I have permissions to do it? -- Eric S. Raymond "Guard with jealous attention the public liberty. Suspect every one who approaches that jewel. Unfortunately, nothing will preserve it but downright force. Whenever you give up that force, you are inevitably ruined." -- Patrick Henry, speech of June 5 1788 -------------- next part -------------- # # ascii.py -- constants and memembership tests for ASCII characters # NUL = 0x00 # ^@ SOH = 0x01 # ^A STX = 0x02 # ^B ETX = 0x03 # ^C EOT = 0x04 # ^D ENQ = 0x05 # ^E ACK = 0x06 # ^F BEL = 0x07 # ^G BS = 0x08 # ^H TAB = 0x09 # ^I HT = 0x09 # ^I LF = 0x0a # ^J NL = 0x0a # ^J VT = 0x0b # ^K FF = 0x0c # ^L CR = 0x0d # ^M SO = 0x0e # ^N SI = 0x0f # ^O DLE = 0x10 # ^P DC1 = 0x11 # ^Q DC2 = 0x12 # ^R DC3 = 0x13 # ^S DC4 = 0x14 # ^T NAK = 0x15 # ^U SYN = 0x16 # ^V ETB = 0x17 # ^W CAN = 0x18 # ^X EM = 0x19 # ^Y SUB = 0x1a # ^Z ESC = 0x1b # ^[ FS = 0x1c # ^\ GS = 0x1d # ^] RS = 0x1e # ^^ US = 0x1f # ^_ SP = 0x20 # space DEL = 0x7f # delete controlnames = [ "NUL", "SOH", "STX", "ETX", "EOT", "ENQ", "ACK", "BEL", "BS", "HT", "LF", "VT", "FF", "CR", "SO", "SI", "DLE", "DC1", "DC2", "DC3", "DC4", "NAK", "SYN", "ETB", "CAN", "EM", "SUB", "ESC", "FS", "GS", "RS", "US", "SP" ] def _ctoi(c): if type(c) == type(""): return ord(c) else: return c def isalnum(c): return isalpha(c) or isdigit(c) def isalpha(c): return isupper(c) or islower(c) def isascii(c): return _ctoi(c) <= 127 # ? def isblank(c): return _ctoi(c) in (8,32) def iscntrl(c): return _ctoi(c) <= 31 def isdigit(c): return _ctoi(c) >= 48 and _ctoi(c) <= 57 def isgraph(c): return _ctoi(c) >= 33 and _ctoi(c) <= 126 def islower(c): return _ctoi(c) >= 97 and _ctoi(c) <= 122 def isprint(c): return _ctoi(c) >= 32 and _ctoi(c) <= 126 def ispunct(c): return _ctoi(c) != 32 and not isalnum(c) def isspace(c): return _ctoi(c) in (12, 10, 13, 9, 11) def isupper(c): return _ctoi(c) >= 65 and _ctoi(c) <= 90 def isxdigit(c): return isdigit(c) or \ (_ctoi(c) >= 65 and _ctoi(c) <= 70) or (_ctoi(c) >= 97 and _ctoi(c) <= 102) def isctrl(c): return _ctoi(c) < 32 def ismeta(c): return _ctoi(c) > 127 def ascii(c): if type(c) == type(""): return chr(_ctoi(c) & 0x7f) else: return _ctoi(c) & 0x7f def ctrl(c): if type(c) == type(""): return chr(_ctoi(c) & 0x1f) else: return _ctoi(c) & 0x1f def alt(c): if type(c) == type(""): return chr(_ctoi(c) | 0x80) else: return _ctoi(c) | 0x80 def unctrl(c): bits = _ctoi(c) if bits == 0x7f: rep = "^?" elif bits & 0x20: rep = chr((bits & 0x7f) | 0x20) else: rep = "^" + chr(((bits & 0x7f) | 0x20) + 0x20) if bits & 0x80: return "!" + rep return rep -------------- next part -------------- A non-text attachment was scrubbed... Name: libascii.tex Type: application/x-tex Size: 4408 bytes Desc: not available URL: From gstein at lyra.org Tue Jun 6 03:10:17 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 5 Jun 2000 18:10:17 -0700 (PDT) Subject: [Python-Dev] ascii.py In-Reply-To: <20000605210231.A25895@thyrsus.com> Message-ID: On Mon, 5 Jun 2000, Eric S. Raymond wrote: > Latest version. Adds isctrl() and ismeta() functions (because I use them...) > > Um. What's the checkin procedure for library modules? Guido has to give his blessing -- that he finds this useful and appropriate for the Python library. He does that using his own criteria and feedback from people here. For example, I'm "+0" on it. (meaning that it seems okay, but I can also live without it) The actual mechanics are outlined at SourceForge: http://sourceforge.net/cvs/?group_id=5470 > And do I have permissions to do it? Nope. There are ten people with checkin privs: http://sourceforge.net/project/memberlist.php?group_id=5470 Five of them are admins (Barry, Fred, Guido, Jeremy, Tim). They use policy to determine whether a given person should become a SF project member. That policy is probably just a gut feeling rather than concrete rules, so I can't say "X, Y, and Z." I also don't know what kinds of policies that they are asserting on people with privs. Cheers, -g -- Greg Stein, http://www.lyra.org/ From jeremy at beopen.com Tue Jun 6 03:23:40 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 5 Jun 2000 21:23:40 -0400 (EDT) Subject: [Python-Dev] ascii.py In-Reply-To: References: <20000605210231.A25895@thyrsus.com> Message-ID: <14652.21148.139774.192634@localhost.localdomain> Greg seems to understand this process better than the admins -- or at least he can explain it quickly and clearly :-). I apologize for the rather confused state of affairs. We'll clean up the process and document it soon. >>>>> "GS" == Greg Stein writes: GS> On Mon, 5 Jun 2000, Eric S. Raymond wrote: >> Latest version. Adds isctrl() and ismeta() functions (because I >> use them...) >> >> Um. What's the checkin procedure for library modules? GS> Guido has to give his blessing -- that he finds this useful and GS> appropriate for the Python library. He does that using his own GS> criteria and feedback from people here. I think I can safely speak for the admins when I say that we're not sure what the process is other than securing Guido's blessing. We need to work out a clearer policy, but that will have to wait until Guido gets back from his honeymoon. Any new checkins we are making are limited for the most part to modules we've already gotten his blessing for. There won't be another alpha release until he returns, so it's not like we have to worry about getting new code in before a code freeze. GS> For example, I'm "+0" on it. (meaning that it seems okay, but I GS> can also live without it) I'm in the same boat. GS> There are ten people with checkin privs: GS> http://sourceforge.net/project/memberlist.php?group_id=5470 GS> Five of them are admins (Barry, Fred, Guido, Jeremy, Tim). They GS> use policy to determine whether a given person should GS> become a SF project member. That policy is probably just a gut GS> feeling rather than concrete rules, so I can't say "X, Y, and GS> Z." I also don't know what kinds of policies that they are GS> asserting on people with privs. Another policy that needs to be defined. "" is surprisingly close to what we actually have written down in our policies and procedures manual. I expect we will arrive at a policy where people own pieces of the library and are free to maintain it. Guido will probably retain control over what modules come and go. -- Jeremy Hylton From esr at thyrsus.com Tue Jun 6 03:33:24 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 5 Jun 2000 21:33:24 -0400 Subject: [Python-Dev] ascii.py In-Reply-To: <14652.21148.139774.192634@localhost.localdomain>; from jeremy@beopen.com on Mon, Jun 05, 2000 at 09:23:40PM -0400 References: <20000605210231.A25895@thyrsus.com> <14652.21148.139774.192634@localhost.localdomain> Message-ID: <20000605213324.A26055@thyrsus.com> Jeremy Hylton : > Another policy that needs to be defined. "" is surprisingly > close to what we actually have written down in our policies and > procedures manual. I expect we will arrive at a policy where people > own pieces of the library and are free to maintain it. Guido will > probably retain control over what modules come and go. Pretty much as I expected. OK. Let us know when things settle out a little. -- Eric S. Raymond Before a standing army can rule, the people must be disarmed, as they are in almost every kingdom in Europe. The supreme power in America cannot enforce unjust laws by the sword, because the people are armed, and constitute a force superior to any band of regular troops. -- Noah Webster From tim_one at email.msn.com Tue Jun 6 04:09:22 2000 From: tim_one at email.msn.com (Tim Peters) Date: Mon, 5 Jun 2000 22:09:22 -0400 Subject: Augmented assignment (was RE: [Python-Dev] Re: Is it just Syntactic Sugar ?) In-Reply-To: <20000604005601.T469@xs4all.nl> Message-ID: <001601bfcf5c$3bcb8e00$0ca0143f@tim> [posted & mailed] [Thomas Wouters, asking about Guido's sketch] > This was what I had in mind, and was trying to explain. Does you > voicing your opinion mean someone (you ? someone else ?) is working > on this, or soon going to work on this ? It's the same scheme he sketched the last time he was provoked into writing about this , and that was at least a year ago. > ... > I'm curious what should happen with index-assignment and > slice-assignment: Nothing special! You're reading far too much into Guido's sketch -- it doesn't have all these convolutions. Try reading his msg again, but this time thinking like him too . > x[y] += z temp1 = x # perhaps the first three are permuted, though temp2 = y temp3 = z temp1[temp2] = temp1[temp2].__add_ab__(temp3) And, yes, indexing is done twice (although "x" and "y" are evaluated only once each). > x[:y] += z temp1 = x temp2 = y temp3 = z temp1[:temp2] = temp1[:temp2].__add_ab__(temp3) Similarly slicing is done twice. > (Obviously this wont make sense for a lot of types, or will be too > un-obvious to include, but I can imagine matrix-types to happily > add this.) Every type is free to implement __add_ab__ or not, in whatever way it likes. But Python can't tell at compile-time which types do and don't implement it, so chances are great that doing x += y for x of a type that does not implement __add_ab__ will raise a runtime AttributeError. > Would this call x.__add_item_ab__(y, z) and x.__add_slice_ab__(0, > y, z) ? No. *All* instances of "+=" are mapped straightforwardly to __add_ab__. Context is irrelevent; indexing and slicing are not special cases (except to the extent that they are already ...). > Or would x[y] += z always call x[y].__add_item_ab__() No. > and x[:y] create a new object, a slice of x What x[:y] means is entirely up to the type of x, and has no connection to augmented assignment (except in that the author of the type may design both to work smoothly together). > and call its __add_ab__() method ? __add_ab__ would be invoked on whatever x[:y] returns; whether that's "a new object" or not is x.__get_slice__'s choice to make. > Or would it try all of them, or more, until it gets a good result ? No. It works or it doesn't. > Or am I running ahead of things and should we wait for a working > patch first ? :) No, you're running a few years behind things , and imagining complications Guido would never sign up for. and-now-the-spirits-must-rest-ly y'rs - tim From bwarsaw at python.org Tue Jun 6 04:27:42 2000 From: bwarsaw at python.org (Barry A. Warsaw) Date: Mon, 5 Jun 2000 22:27:42 -0400 (EDT) Subject: [Python-Dev] ascii.py References: <20000605210231.A25895@thyrsus.com> <14652.21148.139774.192634@localhost.localdomain> Message-ID: <14652.24990.563016.976820@anthem.python.org> >>>>> "JH" == Jeremy Hylton writes: JH> I think I can safely speak for the admins when I say that JH> we're not sure what the process is other than securing Guido's JH> blessing. We need to work out a clearer policy, but that will JH> have to wait until Guido gets back from his honeymoon. Any JH> new checkins we are making are limited for the most part to JH> modules we've already gotten his blessing for. My suggestion would be to upload to the SourceForge patch manager, any patches or code you care about that you don't want us to lose track of. Things get buried in my inbox pretty easily, but at least with the patch manager, we've got a record of it, and can eventually assign a developer to tracking it. -Barry From trentm at activestate.com Tue Jun 6 04:52:44 2000 From: trentm at activestate.com (Trent Mick) Date: Mon, 5 Jun 2000 19:52:44 -0700 Subject: [Python-Dev] about patches on SourceForge Message-ID: <20000605195244.A25437@activestate.com> I just put up one my patches from this past week on SOurceForge. Question: WWould you all prefer to have the "raw patch" just include the actually patch/diff and for the first comment to be the patch description (and legal stuff?) or would you prefer for the patch description and legal stuff to be part of the "raw patch". I am inclined to think that the former would be preferable. Is there some "apply patch" button in SourceForge that would require the "raw patch" to actually be raw? Go check it out and you will know what I am talking about. http://sourceforge.net/patch/?func=browse&group_id=5470&set=open When I get an good opinion from some of you I will send up my other patches. Trent -- Trent Mick trentm at activestate.com From gstein at lyra.org Tue Jun 6 05:32:27 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 5 Jun 2000 20:32:27 -0700 (PDT) Subject: [Python-Dev] Re: httplib In-Reply-To: <14651.13155.253651.575394@localhost.localdomain> Message-ID: On Mon, 5 Jun 2000, Jeremy Hylton wrote: > >>>>> "GS" == Greg Stein writes: >... > >> Oh. Wait. Maybe that was it. You can't read the "next" response > >> until the first one has been read. Well... no need to block > >> putting new responses; we just need to create a way to "get the > >> next reply" and/or "can I get the next reply yet?" > > Maybe I should clarify the concern I had here. I think we're on the > same page, but I'm not sure. > > The problem with pipelined requests is that the client must be sure to > read all of response I before it can call getreply to get response > I+1. Actually, you can issue a getreply() after you've read the prior response's headers, but before you completely read its body. Once you have the header, then you know whether the connection will remain open or not. Assuming it *will* remain open, then you can go ahead and do a request/reply sequence. If the connection is going to close, then you have to fail at request time. > I imagine that it could add a lot of complexity to use code to > implement this requirement, e.g. when multiple threads are sharing a > single connection. It would be good if the library could do something > reasonable about the multiplexing. In the absence of making it just > work, the library could raise an error that makes clear what has gone > wrong -- that the client isn't using the interface properly. I'm working through this stuff right now. It is a bit tricky to get it right *and* have it clear. I'm concentrating on the latter as much as possible. At the moment, HTTPResponse instances can be created without problems. I'm locating the "can you issue a request [and get a response]" logic in the connection object itself. Another detail that I'm trying to work through is where the connection is allowed to get the HTTPResponse to read the HTTP header. Reading off the network could block, so we need to be a bit more careful about what methods can block (if any). In any case, the current httplib (at www.lyra.org/greg/python/) has got just about everything. The next checkin will deal with this pipelining issue. QUESTION #2: I *really* want to get rid of the HTTPS() class. It is introducing excessive complexity, with the only purpose being compatibility against the post-1.5.2 CVS. Anyone? Thoughts on removal? Cheers, -g -- Greg Stein, http://www.lyra.org/ From mhammond at skippinet.com.au Tue Jun 6 05:43:15 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Tue, 6 Jun 2000 13:43:15 +1000 Subject: [Python-Dev] about patches on SourceForge In-Reply-To: <20000605195244.A25437@activestate.com> Message-ID: > When I get an good opinion from some of you I will send up my > other patches. How do you qualify a "good" opinion? One that matches yours? This is all too hard until Guido gets back. But personally I believe the raw patch should be just the CVS diff output, and the comments should reflect all other text, including the release notice while it is still necessary. I hope my opinion is good enough :-) Mark. From jeremy at beopen.com Tue Jun 6 05:46:01 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 5 Jun 2000 23:46:01 -0400 (EDT) Subject: [Python-Dev] Re: httplib In-Reply-To: References: <14651.13155.253651.575394@localhost.localdomain> Message-ID: <14652.29689.663218.777234@localhost.localdomain> >>>>> "GS" == Greg Stein writes: GS> QUESTION #2: I *really* want to get rid of the HTTPS() class. It GS> is introducing excessive complexity, with the only purpose being GS> compatibility against the post-1.5.2 CVS. GS> Anyone? Thoughts on removal? I've got two answers. I don't particularly like the old-style HTTP interface, so I'm happy to see it replaced with a better one. I say who cares about HTTPS. On the other hand, there is a lot of existing code that uses the old interface. It would be good if that code could be modified to use the new SSL interface without having to also re-write the code to use the new http interface. Perhaps we should keep it to provide a future upgrade path for all the legacy code. I could probably be convinced that the amount of effort to change from the old interface to the new interface is fairly small. If you're going to make one change to the code anyway, might as well start using the modern interface, too. Is there anyone who actually has http code to maintain that has an opinion? Jeremy From fdrake at beopen.com Tue Jun 6 05:45:54 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 5 Jun 2000 23:45:54 -0400 (EDT) Subject: [Python-Dev] about patches on SourceForge In-Reply-To: References: <20000605195244.A25437@activestate.com> Message-ID: <14652.29682.819341.881773@cj42289-a.reston1.va.home.com> Mark Hammond writes: > This is all too hard until Guido gets back. But personally I believe the > raw patch should be just the CVS diff output, and the comments should > reflect all other text, including the release notice while it is still > necessary. Sounds good to me. Let's do it this way until there's a god reason to do it differently. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From pf at artcom-gmbh.de Tue Jun 6 11:05:58 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Tue, 6 Jun 2000 11:05:58 +0200 (MEST) Subject: [Python-Dev] PyMarshal_WriteLongToFile: writes 'long' or 32-bit integer? In-Reply-To: <20000605171403.A21808@activestate.com> from Trent Mick at "Jun 5, 2000 5:14: 3 pm" Message-ID: Hi, [Trent Mick]: [...] > - PyMarshal_WriteObjectToFile, when writing a PyInt and hence a C long, will > *NOT* truncate the 64-bit integer but will write the whole thing > > - On reading a .pyc the PyMarshal_ReadObjectFromFile will complain on stderr > when a 64-bit integral value is read and the current platform is 32-bit. [...] > The question is: Do we want PyMarshal_WriteLongToFile *AND* > PyMarshal_WriteObjectToFile to raise an exception when a long value overflows > 32-bits? Up til now I was only proposing the former. Yes. This should at least be the default behaviour of Python. The current behaviour would otherwise cause great damage in the following scenario, where an innocent software developer working on a 64-Bit system trusts on the cross platform portability of Pythons bytecode files and unintentional uses a huge integer literal. If some people really don't care about portability, there could be switch/option/pragma/whatever to disable this behaviour. IMO the portability of Python bytecode files is a *very* valuable property, which we shouldn't give up on. Regards, Peter From gstein at lyra.org Tue Jun 6 11:58:44 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 6 Jun 2000 02:58:44 -0700 (PDT) Subject: [Python-Dev] PyMarshal_WriteLongToFile: writes 'long' or 32-bit integer? In-Reply-To: Message-ID: On Tue, 6 Jun 2000, Peter Funk wrote: > [Trent Mick]: > [...] > > - PyMarshal_WriteObjectToFile, when writing a PyInt and hence a C long, will > > *NOT* truncate the 64-bit integer but will write the whole thing > > > > - On reading a .pyc the PyMarshal_ReadObjectFromFile will complain on stderr > > when a 64-bit integral value is read and the current platform is 32-bit. > [...] > > The question is: Do we want PyMarshal_WriteLongToFile *AND* > > PyMarshal_WriteObjectToFile to raise an exception when a long value overflows > > 32-bits? Up til now I was only proposing the former. > > Yes. This should at least be the default behaviour of Python. > > The current behaviour would otherwise cause great damage in the > following scenario, where an innocent software developer working on > a 64-Bit system trusts on the cross platform portability of Pythons > bytecode files and unintentional uses a huge integer literal. > > If some people really don't care about portability, there could be > switch/option/pragma/whatever to disable this behaviour. > > IMO the portability of Python bytecode files is a *very* valuable property, > which we shouldn't give up on. It isn't only bytecodes. As I mentioned before, marshal byte streams are specified as portable. Therefore, they are used all the time for passing over the network, for persistence mechanisms, etc. Having a marshal stream that is *not* cross-platform is just plain busted. So... you can silently truncate to 32-bits or you can raise an exception. You cannot, however, marshal a 64-bit value when the definition of an "marshal integer" is only 32. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gvwilson at nevex.com Tue Jun 6 16:40:25 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Tue, 6 Jun 2000 10:40:25 -0400 (EDT) Subject: [Python-Dev] req: Software Carpentry / coding standards Message-ID: Hi, everyone. We're a month away from final submissions in the Software Carpentry design competition, which means we're two months away from announcing winners and starting implementation effort, and we're wondering whether there are generally-accepted coding standards, naming conventions, or other guidelines that we should adopt. If so, URLs would be welcome... Also, it appears that there are two implementations of the xUnit testing framework in Python: Steve Purcell: http://sourceforge.net/project/?group_id=3912 Cayte Lindner: ftp://bio.perl.org/pub/katel/biopython/UnitTests/PyUnit.zip We'd be grateful for comments on either. Thanks, Greg Wilson Software Carpentry Project Coordinator From klm at digicool.com Tue Jun 6 18:16:58 2000 From: klm at digicool.com (Ken Manheimer) Date: Tue, 6 Jun 2000 12:16:58 -0400 (EDT) Subject: [Python-Dev] Guido and Kim married Message-ID: <14653.9210.757666.324583@korak.digicool.com> Guido van Rossum and Kim Knapp were married Saturday afternoon on the lawn of a graceful southern estate, Claymont Court, in West Virginia, USA. The weather was *stunningly* fine - a great boon, considering the rain the night before (a torrential downpour in nearby DC) - and the couple left for their honeymoon sunday. Hooray! The crowd consisted of i would guess 70 to 100 people, a mixture of hollanders (including several van rossum relatives - hiya Just!), knapps, pythoners, contact improvisors, economists, martial artists, and sundry other friends and family. I leave to others to quibble about whether or not this qualifies as a "python development". (I probably made enough of a fool of myself at the wedding, with pronouncements of good will and dancing and such, that i can't do any more harm...-) Yay! Ken klm at digicool.com From tim_one at email.msn.com Tue Jun 6 19:20:49 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 6 Jun 2000 13:20:49 -0400 Subject: [Python-Dev] req: Software Carpentry / coding standards In-Reply-To: Message-ID: <001001bfcfdb$8f64d240$48a2143f@tim> [Greg Wilson] > Hi, everyone. We're a month away from final submissions in the > Software Carpentry design competition, which means we're two months > away from announcing winners and starting implementation effort, Yay! This is a wonderful competition, and if nobody yet has bothered to thank you for spearheading it, let me know & I'll find someone who will . > and we're wondering whether there are generally-accepted coding > standards, naming conventions, or other guidelines that we should > adopt. If so, URLs would be welcome... When you can't fight about where to put curly braces, there's not much left to argue. The only serious attempt at a Python style guide I've seen is Guido's: http://www.python.org/doc/essays/styleguide.html Two from there large numbers of people will still argue about, but to no avail: + No hard tabs. Indents are 4 spaces, period. + Keep lines strictly less than 80 characters wide (I happen to keep them under 77, to allow for one level of "> " mail quoting). These rules ensure that code is readable as intended across all platforms. > Also, it appears that there are two implementations of the xUnit > testing framework in Python: > > Steve Purcell: http://sourceforge.net/project/?group_id=3912 > Cayte Lindner: ftp://bio.perl.org/pub/katel/biopython/UnitTests/PyUnit.zip > > We'd be grateful for comments on either. Sorry, unfamiliar with these. From pingster at ilm.com Tue Jun 6 19:25:57 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Tue, 6 Jun 2000 10:25:57 -0700 (PDT) Subject: [Python-Dev] req: Software Carpentry / coding standards In-Reply-To: <001001bfcfdb$8f64d240$48a2143f@tim> Message-ID: On Tue, 6 Jun 2000, Tim Peters wrote: > > Yay! This is a wonderful competition, and if nobody yet has bothered to > thank you for spearheading it, let me know & I'll find someone who will > . Yeah, what he said. :) > The only serious attempt at a Python style guide I've seen is Guido's: > > http://www.python.org/doc/essays/styleguide.html I love this style guide. I know it's a strange reaction to have to a style guide, but i agree with basically everything in it, which is probably pretty rare for these sorts of things. > + No hard tabs. Indents are 4 spaces, period. Tab characters are the work of the devil. -- ?!ng "China is a big country, inhabited by many Chinese." -- Former French President Charles de Gaulle From gvwilson at nevex.com Tue Jun 6 19:31:32 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Tue, 6 Jun 2000 13:31:32 -0400 (EDT) Subject: [Python-Dev] req: Software Carpentry / coding standards In-Reply-To: <001001bfcfdb$8f64d240$48a2143f@tim> Message-ID: > Tim Peters wrote: > When you can't fight about where to put curly braces, there's not much > left to argue. The only serious attempt at a Python style guide I've > seen is Guido's: > http://www.python.org/doc/essays/styleguide.html Yes, I've seen this. I was wondering (a) whether it's up to date (i.e. whether common practice has moved on), and (b) whether there is now a consensus about module structure --- we're expecting several packages that will be shared between tools, plus multiple modules within tools. I've been tracking the occasional message about re-organizing the standard Python library, and would like whatever we do to be in line with wherever Python itself is going. Thanks, Greg From esr at thyrsus.com Tue Jun 6 19:47:13 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Tue, 6 Jun 2000 13:47:13 -0400 Subject: [Python-Dev] req: Software Carpentry / coding standards In-Reply-To: ; from pingster@ilm.com on Tue, Jun 06, 2000 at 10:25:57AM -0700 References: <001001bfcfdb$8f64d240$48a2143f@tim> Message-ID: <20000606134713.A29204@thyrsus.com> Ka-Ping Yee : > > The only serious attempt at a Python style guide I've seen is Guido's: > > > > http://www.python.org/doc/essays/styleguide.html > > I love this style guide. I know it's a strange reaction to > have to a style guide, but i agree with basically everything > in it, which is probably pretty rare for these sorts of things. Likewise. I never read this before, but it's spooky how closely the style I evolved myself tracks it. -- Eric S. Raymond If a thousand men were not to pay their tax-bills this year, that would ... [be] the definition of a peaceable revolution, if any such is possible. -- Henry David Thoreau From petrilli at amber.org Tue Jun 6 19:52:50 2000 From: petrilli at amber.org (Christopher Petrilli) Date: Tue, 6 Jun 2000 13:52:50 -0400 Subject: [Python-Dev] req: Software Carpentry / coding standards In-Reply-To: <001001bfcfdb$8f64d240$48a2143f@tim>; from tim_one@email.msn.com on Tue, Jun 06, 2000 at 01:20:49PM -0400 References: <001001bfcfdb$8f64d240$48a2143f@tim> Message-ID: <20000606135250.A25856@trump.amber.org> Tim Peters [tim_one at email.msn.com] wrote: > When you can't fight about where to put curly braces, there's not much left > to argue. The only serious attempt at a Python style guide I've seen is > Guido's: > > http://www.python.org/doc/essays/styleguide.html The only thing that might be added (I haven't looked in a while, but didn't see it last time I did), is some naming convention issues. I follow pretty standard Smalltalk guidelines: - No '_', use camelCase for seps - Capitalize all Classes, and also global variables - Lowercase for all methods (i.e. setNewBreakpoint) This is just me, and obviously not everyone does this :-) Chris -- | Christopher Petrilli | petrilli at amber.org From gvwilson at nevex.com Tue Jun 6 19:50:38 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Tue, 6 Jun 2000 13:50:38 -0400 (EDT) Subject: [Python-Dev] req: Software Carpentry / coding standards In-Reply-To: <20000606135250.A25856@trump.amber.org> Message-ID: > > Tim Peters: > > http://www.python.org/doc/essays/styleguide.html > On Tue, 6 Jun 2000, Christopher Petrilli wrote: > The only thing that might be added (I haven't looked in a while, but > didn't see it last time I did), is some naming convention issues. I > follow pretty standard Smalltalk guidelines: > > - No '_', use camelCase for seps I know this is become common practice, but I've been told by two different HCI specialists that studies have shown CamelBackNotation to be harder for non-native speakers to read than underbar_separated_text, particularly when acronyms are part of the name. If anyone has a pointer to an original reference for this, I'd be grateful. Thanks, Greg From klm at digicool.com Tue Jun 6 20:32:12 2000 From: klm at digicool.com (Ken Manheimer) Date: Tue, 6 Jun 2000 14:32:12 -0400 (EDT) Subject: [Python-Dev] req: Software Carpentry / coding standards In-Reply-To: Message-ID: On Tue, 6 Jun 2000, Ka-Ping Yee wrote: > > The only serious attempt at a Python style guide I've seen is Guido's: > > > > http://www.python.org/doc/essays/styleguide.html > > I love this style guide. I know it's a strange reaction to > have to a style guide, but i agree with basically everything > in it, which is probably pretty rare for these sorts of things. Me too! (Or three, or four by now...) Ken klm at digicool.com From tim_one at email.msn.com Tue Jun 6 20:36:26 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 6 Jun 2000 14:36:26 -0400 Subject: [Python-Dev] PyMarshal_WriteLongToFile: writes 'long' or 32-bitinteger? In-Reply-To: Message-ID: <001201bfcfe6$1fe51dc0$48a2143f@tim> [GregS] > It isn't only bytecodes. As I mentioned before, marshal byte streams are > specified as portable. Therefore, they are used all the time for passing > over the network, for persistence mechanisms, etc. > > Having a marshal stream that is *not* cross-platform is just plain busted. > > So... you can silently truncate to 32-bits or you can raise an exception. But in either of those cases it's not cross-platform == it's just plain busted. > You cannot, however, marshal a 64-bit value when the definition of an > "marshal integer" is only 32. The current code is insane. Long-term the visible distinction between (Python) ints and longs should vanish. Short-term the PyInt_Check case of w_object should see whether the int fits in 4 bytes, and if so write it as a C long, and if not write the thing as a Python long (that's the only way to keep the marshal portable!). Any code keying off the SIZEOF_LONG symbol is highly suspect, piling another layer of "convenient but wrong" assumptions on top of the current layer. Code in marshal should *never* try to exploit that C longs happen to be bigger than 4 bytes on the current platform. PyMarshal_WriteLongToFile should be changed to raise an exception if passed something that doesn't fit in 4 bytes, and should be declared obsolete. The Python core should be changed now never to call PyMarshal_WriteLongToFile (in answer to Trent's original question, the intent of that code can't be distinguished from what it does, which is to blindly write exactly 4 bytes no matter what). Most of this crap is in support of a bad assumption about mtimes, and, sorry, but it sure looks to me like the .pyc header format is "just plain busted" too. Let's bite the bullet and fix the header -- then all the rest of this will be clearly seen as the broken hackery it really is. From trentm at activestate.com Tue Jun 6 20:57:52 2000 From: trentm at activestate.com (Trent Mick) Date: Tue, 6 Jun 2000 11:57:52 -0700 Subject: [Python-Dev] about patches on SourceForge In-Reply-To: <14652.29682.819341.881773@cj42289-a.reston1.va.home.com> References: <20000605195244.A25437@activestate.com> <14652.29682.819341.881773@cj42289-a.reston1.va.home.com> Message-ID: <20000606115752.D28943@activestate.com> On Mon, Jun 05, 2000 at 11:45:54PM -0400, Fred L. Drake, Jr. wrote: > > Mark Hammond writes: > > This is all too hard until Guido gets back. But personally I believe the > > raw patch should be just the CVS diff output, and the comments should > > reflect all other text, including the release notice while it is still > > necessary. > > Sounds good to me. Let's do it this way until there's a god reason ^^^ > to do it differently. > I think maybe that you meant 'good', but I am not so sure. ;-) Trent -- Trent Mick trentm at activestate.com From gmcm at hypernet.com Tue Jun 6 20:59:49 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Tue, 6 Jun 2000 14:59:49 -0400 Subject: [Python-Dev] req: Software Carpentry / coding standards In-Reply-To: References: <001001bfcfdb$8f64d240$48a2143f@tim> Message-ID: <1251804473-5567942@hypernet.com> Greg Wilson wrote: > > Tim Peters wrote: [Guido's style guide] > Yes, I've seen this. I was wondering > ... whether > there is now a consensus about module structure ... No, there's not. And if you ask me, (which you didn't) there's some very bad precedents getting set in the misguided pursuit of "ease of use". Time to call out the PSU before things get out of hand... - Gordon From gstein at lyra.org Tue Jun 6 21:04:25 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 6 Jun 2000 12:04:25 -0700 (PDT) Subject: [Python-Dev] req: Software Carpentry / coding standards In-Reply-To: Message-ID: On Tue, 6 Jun 2000, Greg Wilson wrote: > > > Tim Peters: > > > http://www.python.org/doc/essays/styleguide.html > > > On Tue, 6 Jun 2000, Christopher Petrilli wrote: > > The only thing that might be added (I haven't looked in a while, but > > didn't see it last time I did), is some naming convention issues. I > > follow pretty standard Smalltalk guidelines: > > > > - No '_', use camelCase for seps > > I know this is become common practice, but I've been told by two different > HCI specialists that studies have shown CamelBackNotation to be harder for > non-native speakers to read than underbar_separated_text, particularly > when acronyms are part of the name. If anyone has a pointer to an > original reference for this, I'd be grateful. Actually, the "camel case" for identifiers is not a standard Python style. I've seen three forms: - no separator or case usage (e.g. getattr()) - mixed case - lower case with underscores Chris' other points: upper-case-initial classes and lower-case-initial methods are *definitely* standard. Globals are a bit different. I don't think it is standard to capitalize them as Chris mentioned (they might look like classes in that case). There isn't much of a standard there. Definitely another point is the use of "_" for the initial character to signify "private -- don't touch" Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Tue Jun 6 21:29:56 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 6 Jun 2000 12:29:56 -0700 (PDT) Subject: [Python-Dev] ANSI-fication (was: RE: [Patches] fix simple 64-bit warnings/errors in signalmodule.c and bufferobject.c) In-Reply-To: <001c01bfcfea$b73a2040$48a2143f@tim> Message-ID: On Tue, 6 Jun 2000, Tim Peters wrote: >... > [on K&R style declarations failing to act as prototypes] > > ... > > Give the man a prize. That was it. We'll just forget that part of the > > patch then and thank you Tim for changing all function declarations > > from K&R to ANSI. :) > > Believe it or not, I do intend to do that, although I expect resistance from > Guido <0.5 wink>. Python's infrastructure is creaking from age, and an > update to ANSI C is l-o-n-g overdue. It appears to me that a very large > part of your "Win64" efforts have amounted to fighting long-obsolete K&R C > assumptions! Euh... I thought Guido was entirely supportive of ANSI-fying the source. Something like changing from K&R functions over to ANSI declarations is "brain-dead" that should not introduce errors. Going through and revamping the protoypes (e.g. PyString_FromStringAndSize to now use size_t) is a bit different, though... I shouldn't think Guido would be upset about prototypes. Cheers, -g -- Greg Stein, http://www.lyra.org/ From effbot at telia.com Tue Jun 6 22:23:19 2000 From: effbot at telia.com (Fredrik Lundh) Date: Tue, 6 Jun 2000 22:23:19 +0200 Subject: [Python-Dev] ANSI-fication (was: RE: [Patches] fix simple 64-bit warnings/errorsin signalmodule.c and bufferobject.c) References: Message-ID: <01b101bfcff5$1000faa0$f2a6b5d4@hagrid> greg wrote: > Euh... I thought Guido was entirely supportive of ANSI-fying the source. note that 1.6 won't build on non-ANSI platforms; lots of new stuff, including the unicode type, the builtin exceptions, and SRE are pure ANSI. (btw, what are all those "register" declarations doing in MAL's version of unicodeobject.c? does any modern compiler even care about that keyword?) From tim_one at email.msn.com Tue Jun 6 23:00:33 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 6 Jun 2000 17:00:33 -0400 Subject: [Python-Dev] RE: ANSI-fication (was: RE: [Patches] fix simple 64-bit warnings/errorsin signalmodule.c and bufferobject.c) In-Reply-To: Message-ID: <001f01bfcffa$41ed2f20$48a2143f@tim> [Greg Stein] > Euh... I thought Guido was entirely supportive of ANSI-fying the source. > Something like changing from K&R functions over to ANSI declarations is > "brain-dead" that should not introduce errors. ... He'll be less & less in favor of it when it hits home how time-consuming and massive the changes will be. They won't be viewed as "a feature" to BeOpen, so BeOpen will give him grief about it too. Etc. I've fought the same stinking infrastructure battles for 20+ years, and don't expect that having a new boss will make any material difference to that <0.7 wink>. Testing is expensive, robustness is expensive, portability is expensive (and C doesn't help! honest to God, it's much worse than Fortran for portability). > Going through and revamping the protoypes (e.g. PyString_FromStringAndSize > to now use size_t) is a bit different, though... > > I shouldn't think Guido would be upset about prototypes. Nobody should get upset about *having* them, it's getting them done that takes away from getting everything else done. That's why every project I've ever seen puts it off year after year. Note that if Guido valued this *highly*, it would already have been done. been-there-done-that-been-there-done-that-been-there-done-that-ly y'rs - tim From jack at oratrix.nl Tue Jun 6 23:14:10 2000 From: jack at oratrix.nl (Jack Jansen) Date: Tue, 06 Jun 2000 23:14:10 +0200 Subject: [Python-Dev] Trying again: [Patches] Patch to import.c Message-ID: <20000606211416.10B6ED8397@oratrix.oratrix.nl> Folks, I posted this message to the patches mailing list last week, but either I missed the reply (we had full disks over the weekend) or nobody replied yet. And I am waiting for these patches, or rather other people who want to play with MacPython and MacOSX are, so I'd really like to know whether I should revise the patches and in what direction or have them checked in.... Hmm, that may all sound a bit pushy, but that isn't the intention. I really just want to know (a) what the status of my patches is and (b) what I can expect in the future.... Jack -------------- next part -------------- An embedded message was scrubbed... From: unknown sender Subject: no subject Date: no date Size: 38 URL: From mal at lemburg.com Wed Jun 7 00:53:02 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 07 Jun 2000 00:53:02 +0200 Subject: [Python-Dev] ANSI-fication (was: RE: [Patches] fix simple 64-bit warnings/errorsin signalmodule.c and bufferobject.c) References: <01b101bfcff5$1000faa0$f2a6b5d4@hagrid> Message-ID: <393D80CE.D6C387AA@lemburg.com> Fredrik Lundh wrote: > > note that 1.6 won't build on non-ANSI platforms; lots of new > stuff, including the unicode type, the builtin exceptions, and > SRE are pure ANSI. > > (btw, what are all those "register" declarations doing in MAL's > version of unicodeobject.c? does any modern compiler even > care about that keyword?) "register" helps compilers in situations where normal optimizations don't give satisfying results, e.g. to aid in keeping often used variables or counters in registers rather than on the stack. It can also help with inling functions and can speed up parameter passing. GCC is one such modern compiler that does care, not sure about MSVC++. IBM's OS/2 compilers did (last time I looked some 5 years ago ;). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From pf at artcom-gmbh.de Wed Jun 7 00:47:41 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Wed, 7 Jun 2000 00:47:41 +0200 (MEST) Subject: Style guide (was Re: [Python-Dev] req: Software Carpentry / coding standards) In-Reply-To: from Greg Wilson at "Jun 6, 2000 1:50:38 pm" Message-ID: Hi, Greg Wilson: > > > Tim Peters: > > > http://www.python.org/doc/essays/styleguide.html > > > On Tue, 6 Jun 2000, Christopher Petrilli wrote: > > The only thing that might be added (I haven't looked in a while, but > > didn't see it last time I did), is some naming convention issues. I > > follow pretty standard Smalltalk guidelines: > > > > - No '_', use camelCase for seps > > I know this is become common practice, but I've been told by two different > HCI specialists that studies have shown CamelBackNotation to be harder for > non-native speakers to read than underbar_separated_text, particularly > when acronyms are part of the name. If anyone has a pointer to an > original reference for this, I'd be grateful. This would be indeed very interesting. But my own experiences support this POV: This naming style issue is similar in Python and one of its early anchestors Modula-2. In 1985 we started our company programming in Modula-2. At that time we decided to code conforming to the original Modula-2 language definition as published by N.Wirth in March, 1980: underscores were not allowed in identifiers! German: '_' verboten! ;-) The software is in use until today and several of our employees still have to use Modula-2 for maintainance. The code base is currently about 1 Mio. LOC. We tried to use english identifiers, although all programmers are native german speakers. We too adopted a style using first char lowercase or uppercase to distinguish identifier classes (modules and procedure names uppercase and all other identifiers lowercase) and later we ran into the problems described above. A few years ago we allowed the use of '_' in identifiers, because the compiler support was available. This has improved the situation somewhat. All our programmers like the possibility to occasionally use '_' in identifiers, especially if idents contain acronyms. Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen) From pf at artcom-gmbh.de Wed Jun 7 11:34:12 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Wed, 7 Jun 2000 11:34:12 +0200 (MEST) Subject: [Python-Dev] Idea: emulating _locale (was Re: [Python-checkins] CVS: python/dist/src/Lib locale.py,1.4,1.5) In-Reply-To: <200006070911.CAA17368@slayer.i.sourceforge.net> from Marc-Andre Lemburg at "Jun 7, 2000 2:11:43 am" Message-ID: Hi, Marc-Andre Lemburg: [...] > Added a new locale name aliasing engine which also supports > locale encodings, a feature which is used by the new default > encoding support in site.py. > > Index: locale.py [...] > + ### C lib locale APIs > + > + from _locale import * Wouldn't it be clever to provide some dummy stubs on those platforms, where the _locale module was not enabled? try: from _locale import * except: def setlocale(.... def localeconv(.... ... Especially the MacOS 1.5.2 release provided by Jack Jansen was compiled without '_locale'. And at least in Python 1.6a2 '_locale' is still disabled per default in 'Modules/Setup.in'. I didn't had a look into the current CVS though, so this may have changed. I think the name aliasing tables might be also useful on those systems lacking locale support in their C-library. Regards, Peter From pf at artcom-gmbh.de Wed Jun 7 11:40:17 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Wed, 7 Jun 2000 11:40:17 +0200 (MEST) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules Setup.in,1.100,1.101 In-Reply-To: <200006070912.CAA17814@slayer.i.sourceforge.net> from Marc-Andre Lemburg at "Jun 7, 2000 2:12:56 am" Message-ID: Uoooppps.... I was just too fast with my previous email about _locale emulation. Marc-Andre Lemburg: > *** Setup.in 2000/05/26 19:02:42 1.100 > --- Setup.in 2000/06/07 09:12:54 1.101 > *************** > *** 141,145 **** > # static Unicode character database > > ! #_locale _localemodule.c # access to ISO C locale support > > > --- 141,145 ---- > # static Unicode character database > > ! _locale _localemodule.c # access to ISO C locale support > Is this likely to work on the Mac with C-libraries coming with Metrowerks CodeWarrior? Jack? Regards, Peter From fredrik at pythonware.com Wed Jun 7 12:24:46 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Wed, 7 Jun 2000 12:24:46 +0200 Subject: [Python-Dev] ANSI-fication (was: RE: [Patches] fix simple 64-bit warnings/errorsin signalmodule.c and bufferobject.c) References: <01b101bfcff5$1000faa0$f2a6b5d4@hagrid> <393D80CE.D6C387AA@lemburg.com> Message-ID: <007a01bfd06a$9d3db140$0500a8c0@secret.pythonware.com> MAL wrote: > > (btw, what are all those "register" declarations doing in MAL's > > version of unicodeobject.c? does any modern compiler even > > care about that keyword?) > > "register" helps compilers in situations where normal > optimizations don't give satisfying results, e.g. to aid > in keeping often used variables or counters in registers > rather than on the stack. It can also help with inling > functions and can speed up parameter passing. Yeah, I know what register is supposed to do. But common knowledge (at least where I live) is that modern optimizers know better than you, and usually ignore "register" altogether if you use higher optimization levels... (and if they don't, using "register" is likely to make things worse on some platforms). In other words, "register" should not be used in portable code. fwiw, a certain Linux kernel hacker seem to agree with me on that one: http://www2.linuxjournal.com/lj-issues/issue17/1138.html ... #define register ... "Gcc, the normal Linux C compiler, understands the register keyword, but the code optimiser is sufficiently good that using register is normally a bad idea." ... (If it's good enough for Alan Cox etc). But never mind. I doubt that removing them would matter on any con- temporary platform, but on the other hand, keeping them in there won't hurt much either. It just makes the source code a little bit more ver- bose than it has to be... From mal at lemburg.com Wed Jun 7 12:25:08 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 07 Jun 2000 12:25:08 +0200 Subject: [Python-Dev] Idea: emulating _locale (was Re: [Python-checkins] CVS: python/dist/src/Lib locale.py,1.4,1.5) References: Message-ID: <393E2304.4BE8CDE0@lemburg.com> Peter Funk wrote: > > Hi, > > Marc-Andre Lemburg: > [...] > > Added a new locale name aliasing engine which also supports > > locale encodings, a feature which is used by the new default > > encoding support in site.py. > > > > Index: locale.py > [...] > > + ### C lib locale APIs > > + > > + from _locale import * > > Wouldn't it be clever to provide some dummy stubs on those platforms, where > the _locale module was not enabled? > > try: > from _locale import * > except: > def setlocale(.... > def localeconv(.... > ... > > Especially the MacOS 1.5.2 release provided by Jack Jansen was > compiled without '_locale'. And at least in Python 1.6a2 '_locale' > is still disabled per default in 'Modules/Setup.in'. I didn't had > a look into the current CVS though, so this may have changed. > > I think the name aliasing tables might be also useful on those > systems lacking locale support in their C-library. setlocale and localeconv are ANSI C and Python requires an ANSI C compiler, so there should be no problem (at least in theory). If there is a problem, adding the missing symbols would be no problem: the APIs could always report locale 'C' and its numeric settings. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Wed Jun 7 12:40:24 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 07 Jun 2000 12:40:24 +0200 Subject: [Python-Dev] ANSI-fication (was: RE: [Patches] fix simple 64-bit warnings/errorsin signalmodule.c and bufferobject.c) References: <01b101bfcff5$1000faa0$f2a6b5d4@hagrid> <393D80CE.D6C387AA@lemburg.com> <007a01bfd06a$9d3db140$0500a8c0@secret.pythonware.com> Message-ID: <393E2698.D2DFFC91@lemburg.com> Fredrik Lundh wrote: > > MAL wrote: > > > (btw, what are all those "register" declarations doing in MAL's > > > version of unicodeobject.c? does any modern compiler even > > > care about that keyword?) > > > > "register" helps compilers in situations where normal > > optimizations don't give satisfying results, e.g. to aid > > in keeping often used variables or counters in registers > > rather than on the stack. It can also help with inling > > functions and can speed up parameter passing. > > Yeah, I know what register is supposed to do. I know you know, but I find adding some explanations for others which might not know is good practice. > But common knowledge (at least where I live) is that modern optimizers > know better than you, and usually ignore "register" altogether if you use > higher optimization levels... (and if they don't, using "register" is likely to > make things worse on some platforms). In other words, "register" should > not be used in portable code. > > fwiw, a certain Linux kernel hacker seem to agree with me on that one: > > http://www2.linuxjournal.com/lj-issues/issue17/1138.html > ... > #define register > ... > "Gcc, the normal Linux C compiler, understands the register keyword, > but the code optimiser is sufficiently good that using register is normally > a bad idea." > ... Well, make that "normally not needed": gcc sometimes doesn't inline functions because it thinks that the function needs parameters to be on the stack. The register keyword can do wonders here. Adding "register" is like adding salt & pepper: things usually taste better than before ;-). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gward at mems-exchange.org Wed Jun 7 15:19:06 2000 From: gward at mems-exchange.org (Greg Ward) Date: Wed, 7 Jun 2000 09:19:06 -0400 Subject: [Python-Dev] Re: [Patches] Translating doc strings In-Reply-To: <200006021503.RAA26314@pandora>; from loewis@informatik.hu-berlin.de on Fri, Jun 02, 2000 at 05:03:50PM +0200 References: <200006020701.JAA28620@pandora> <39376C19.53A01A27@lemburg.com> <200006021233.OAA16962@pandora> <14647.47270.330318.807347@anthem.python.org> <200006021503.RAA26314@pandora> Message-ID: <20000607091906.A5559@ludwig.cnri.reston.va.us> On 02 June 2000, Martin von Loewis said: > Having the full set of distutils doc strings in the > catalog is already a substantial amount of text to translate... Most of those docstrings in the Distutils are not really for public consumption; they're there so that Distutils developers can remember (or learn) what the heck such-and-such a method is supposed to do. Also, they're a moving target; things are still changing in the Distutils, and trying to keep on top of translating internal docstrings would be a hopeless and frustrating task. Greg From jack at oratrix.nl Wed Jun 7 15:51:54 2000 From: jack at oratrix.nl (Jack Jansen) Date: Wed, 07 Jun 2000 15:51:54 +0200 Subject: [Python-Dev] Idea: emulating _locale (was Re: [Python-checkins] CVS: python/dist/src/Lib locale.py,1.4,1.5) In-Reply-To: Message by "M.-A. Lemburg" , Wed, 07 Jun 2000 12:25:08 +0200 , <393E2304.4BE8CDE0@lemburg.com> Message-ID: <20000607135154.8DCFD370CF2@snelboot.oratrix.nl> The locale stuff in the CodeWarrior libraries is basically a dummy placeholder, that's why I didn't export it to Python. But it appears that it's better to export it anyway, if I understand the dsicussion correctly, so I'll do so from the next release. -- 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 gward at mems-exchange.org Wed Jun 7 15:56:38 2000 From: gward at mems-exchange.org (Greg Ward) Date: Wed, 7 Jun 2000 09:56:38 -0400 Subject: [Python-Dev] Revised 1.6 jobs list In-Reply-To: ; from jeremy@beopen.com on Sat, Jun 03, 2000 at 12:11:48PM -0400 References: <3938D60E.391AAF31@lemburg.com> Message-ID: <20000607095638.B5559@ludwig.cnri.reston.va.us> On 03 June 2000, Jeremy Hylton said: > SourceForge makes it a little more inconvenient to check which > patches have been applied. Under the old CVS arrangement, it was > a local operation to do a cvs log or diff. Now it's a slow network > operation that requires authentication. (I really want a local > mirror of the entire CVS repository!) I have come up with a partial solution to the inconvenience of accessing SourceForge, specifically the need for constant authentication. I generated a new, unencrypted SSH key and put it in ~/.ssh/alt-identity. Then I wrote a little C program (source attached) that does the equivalent of os.exec ("ssh", "-i", "$HOME/.ssh/alt-identity") (in an imaginary dialect of Python that interpolates environment variables ;-). Then I set CVS_RSH to this little C program (~/bin/alt_ssh). (It could have easily been a script, but I wanted to avoid the overhead of launching an interpreter for every authentication.) So now CVS operations against SF are just s..l..o..w, and I'm not forever typing in my SSH passphrase. Of course, anyone with root access at CNRI could now steal my unencrypted key -- which I *only* use for CVS access to SF -- and use it to impersonate me for checkins. But I think the only person who knows how to do that already has Python checkin privilege. ;-) But yeah, remote CVS still bites the big one. Very painful over a 28.8k modem line. (It sucks being a cheap bastard!) Greg -- Greg Ward - software developer gward at mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From gward at mems-exchange.org Wed Jun 7 15:57:41 2000 From: gward at mems-exchange.org (Greg Ward) Date: Wed, 7 Jun 2000 09:57:41 -0400 Subject: [Python-Dev] Revised 1.6 jobs list In-Reply-To: <20000607095638.B5559@ludwig.cnri.reston.va.us>; from gward@ludwig.cnri.reston.va.us on Wed, Jun 07, 2000 at 09:56:38AM -0400 References: <3938D60E.391AAF31@lemburg.com> <20000607095638.B5559@ludwig.cnri.reston.va.us> Message-ID: <20000607095741.C5559@ludwig.cnri.reston.va.us> On 07 June 2000, I said: > Then I wrote a little C program (source attached) that does the > equivalent of Oops, forgot the attachment. Here 'tis. -------------- next part -------------- /* * alt_ssh * * exec ssh with an alternate "identity" (key pair) -- needed since * the CVS_RSH variable can't include options for the rsh-like * command. * * GPW 2000/05/28 * * $Id: alt_ssh.c,v 1.3 2000/06/07 13:54:19 gward Exp $ */ #include #include #include #include #include int main (int argc, char * argv[]) { char * keyfile = "/.ssh/alt-identity"; char * keyfile_full; char * home; int num_args; char ** ssh_args; int i; home = getenv("HOME"); keyfile_full = (char *) malloc (strlen(home) + strlen(keyfile) + 1); assert (home != NULL && keyfile_full != NULL); strcpy(keyfile_full, home); strcat(keyfile_full, keyfile); num_args = argc + 2; /* -i, identity-file */ ssh_args = (char **) calloc (num_args+1, sizeof(char *)); ssh_args[0] = "ssh"; ssh_args[1] = "-i"; ssh_args[2] = keyfile_full; for (i = 3; i < num_args; i++) ssh_args[i] = argv[i-2]; ssh_args[i] = NULL; for (i = 0; i < num_args; i++) { printf(ssh_args[i]); if (i < num_args) printf(" "); } printf("\n"); execvp("ssh", ssh_args); perror("couldn't exec ssh"); exit(1); } From jeremy at beopen.com Wed Jun 7 16:04:12 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Wed, 7 Jun 2000 10:04:12 -0400 (EDT) Subject: [Python-Dev] Fwd: Hmmmm... (Jim Anderson) Message-ID: <14654.22108.959934.552869@localhost.localdomain> You guys haven't seen more Perl traffic on this list have you? :-) Jeremy -------------- next part -------------- An embedded message was scrubbed... From: "Jim Anderson" Subject: Hmmmm... Date: Tue, 6 Jun 2000 12:09:53 -0400 (EDT) Size: 490 URL: From gward at mems-exchange.org Wed Jun 7 16:11:46 2000 From: gward at mems-exchange.org (Greg Ward) Date: Wed, 7 Jun 2000 10:11:46 -0400 Subject: [Python-Dev] release forms? (was: [Patches] New sys method to return total reference count in debug builds.) In-Reply-To: ; from gstein@lyra.org on Sun, Jun 04, 2000 at 04:30:08PM -0700 References: Message-ID: <20000607101146.D5559@ludwig.cnri.reston.va.us> On 04 June 2000, Greg Stein said: > p.s. IMO, I'd like to see Guido own the Copyright for all current and > future Python development Second that. Given that I work for CNRI and was forced (at gunpoint, as I recall) to sign an incredibly draconian IP agreement -- along the lines of "everything you have ever created, or will ever consider creating, in any medium whatsoever, no matter where you did it or who pays for it, is the property of CNRI for all time" -- I'd have a hard time getting away with slapping "Copyright (c) 1999-2000 Gregory P. Ward" all over the Distutils code. And given that fair chunks of that code have been contributed by other people, I couldn't even ethically do that. So, given that I probably can't claim ownership in the code, and that CNRI has absolutely no moral right to it (although probably some legal right), I'd prefer to sign it away to Guido. Or optionally, to some legal fiction that represents the Python community; preferably *not* the Python Consortium, as long as CNRI is in any way connected. Death to the lawyers! Greg -- Greg Ward - software developer gward at mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From moshez at math.huji.ac.il Wed Jun 7 16:33:10 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 7 Jun 2000 17:33:10 +0300 (IDT) Subject: [Python-Dev] release forms? (was: [Patches] New sys method to return total reference count in debug builds.) In-Reply-To: <20000607101146.D5559@ludwig.cnri.reston.va.us> Message-ID: On Wed, 7 Jun 2000, Greg Ward wrote: > CNRI has absolutely no moral right to it (although probably some legal > right), I'd prefer to sign it away to Guido. Or optionally, to some > legal fiction that represents the Python community; preferably *not* the > Python Consortium, as long as CNRI is in any way connected. Who's in charge of the PSA? Or should we form *another* non-profit, and sign it over to it? (Personally, I couldn't care less who I transfer copyright over my Python contributions to -- I'd put it in the public domain if that's what it took) -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com From pf at artcom-gmbh.de Wed Jun 7 16:44:30 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Wed, 7 Jun 2000 16:44:30 +0200 (MEST) Subject: [Python-Dev] Revised 1.6 jobs list In-Reply-To: <20000607095638.B5559@ludwig.cnri.reston.va.us> from Greg Ward at "Jun 7, 2000 9:56:38 am" Message-ID: Hi, Greg Ward: > But yeah, remote CVS still bites the big one. Very painful over a 28.8k > modem line. (It sucks being a cheap bastard!) Certainly you know about 'rsync'? Would this help here? Let me quote a small section from the 'rsync' man page: """ To synchronize my samba source trees I use the following Makefile targets: get: rsync -avuzb --exclude ?*~? samba:samba/ . put: rsync -Cavuzb . samba:samba/ sync: get put this allows me to sync with a CVS directory at the other end of the link. I then do cvs operations on the remote machine, which saves a lot of time as the remote cvs pro? tocol isn?t very efficient. """ I can't access CVS because of our restrictive HTTP/UUCP only firewall, but in our company we use 'rsync' a lot. Regards, Peter From bwarsaw at python.org Wed Jun 7 17:06:42 2000 From: bwarsaw at python.org (Barry A. Warsaw) Date: Wed, 7 Jun 2000 11:06:42 -0400 (EDT) Subject: [Python-Dev] Revised 1.6 jobs list References: <3938D60E.391AAF31@lemburg.com> <20000607095638.B5559@ludwig.cnri.reston.va.us> Message-ID: <14654.25858.564089.574043@anthem.python.org> >>>>> "GW" == Greg Ward writes: GW> I have come up with a partial solution to the inconvenience of GW> accessing SourceForge, specifically the need for constant GW> authentication. Greg, are you aware of ssh-agent? Same convenience, same possible exploits, but at least they've done the hard work for ya. :) I usually just run XEmacs under ssh-agent. First thing you do is fire up a shell buffer, run ssh-add to authenticate once, and from there on, all your ssh interactions (not just with SF) yank the private key out of the ssh-agent process and never bother you with a passphrase prompt. -Barry From bwarsaw at python.org Wed Jun 7 17:22:20 2000 From: bwarsaw at python.org (Barry A. Warsaw) Date: Wed, 7 Jun 2000 11:22:20 -0400 (EDT) Subject: [Python-Dev] release forms? (was: [Patches] New sys method to return total reference count in debug builds.) References: <20000607101146.D5559@ludwig.cnri.reston.va.us> Message-ID: <14654.26796.936980.875783@anthem.python.org> >>>>> "MZ" == Moshe Zadka writes: MZ> Who's in charge of the PSA? Or should we form *another* MZ> non-profit, and sign it over to it? (Personally, I couldn't MZ> care less who I transfer copyright over my Python MZ> contributions to -- I'd put it in the public domain if that's MZ> what it took) Please remember that the copyright holder can release the code under whatever license they want, even multiple different licenses. Copyright != license. I'm not sure what the right thing to do here is. On the one hand, Bob Kahn always said nobody would use Python if its heritage (i.e. copyright ownership) were not nailed down like Java. On the other hand, there's a lot of nobodies out there right now :). For GNU projects, the FSF wants to own all the copyrights to the code. They actually want you to legally assign the copyright to them. Their explanation for this onerous requirement is that if they were not the copyright holder, they would not have the legal standing to defend GPL violations, or would have to coordinate with a ton of developers, making such legal defenses practically impossible. Python is in a different situation, IMO, because it has a /less/ restrictive license than the GPL, so there's less to get all huffy about in court. If someone builds a binary-only proprietary blend of Python and starts selling it without source code, well, there's no license violation there, so what's to defend? The argument has been made that without clear legal title, someone could claim that some of the donated code in Python violated a copyright or patent and try to stop 3rd parties from using Python. Who knows what the actual legal possibility of that happening are, but I don't see how 1) we could take any real defense against this or 2) it affects Python any differently than any other large multi-contributor open source system. -Barry From andy at robanal.demon.co.uk Wed Jun 7 22:48:48 2000 From: andy at robanal.demon.co.uk (Andy Robinson) Date: Wed, 07 Jun 2000 20:48:48 GMT Subject: [Python-Dev] Package ambiguities Message-ID: <393eb52b.47053339@post.demon.co.uk> We hit some very weird behaviour recently while setting up a package hierarchy. Robin Becker managed to distil this into a simple example. Can anyone shed any light on what is happening below? Is Python behaving as it should? Create a package A, empty __init__.py, with modules as follows: --------parent.py---------- class Parent: pass --------child.py------------ from parent import Parent class Child(Parent): pass ---------test.py-------- from parent import * class Examiner: def examine(self, arg): print 'examining argument:' print 'class of arg =', arg.__class__ print 'bases of arg =', arg.__class__.__bases__ print 'arg =', arg if isinstance(arg, Parent): print "arg is an instance of Parent" else: print "arg IS NOT an instance of Parent" print if __name__=='__main__': from traceback import print_exc import sys def run0(): from A.child import Child e = Examiner() e.examine(Child()) def run1(): from A.child import Child from A.test import Examiner e = Examiner() e.examine(Child()) run0() run1() Running this script produces the following output: C:\users\andy\A>test.py examining argument: class of arg = A.child.Child bases of arg = (,) arg = arg IS NOT an instance of Parent examining argument: class of arg = A.child.Child bases of arg = (,) arg = arg is an instance of Parent Many thanks, Andy Robinson From pingster at ilm.com Wed Jun 7 23:05:26 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Wed, 7 Jun 2000 14:05:26 -0700 (PDT) Subject: [Python-Dev] Package ambiguities In-Reply-To: <393eb52b.47053339@post.demon.co.uk> Message-ID: On Wed, 7 Jun 2000, Andy Robinson wrote: > We hit some very weird behaviour recently while setting up a package > hierarchy. Robin Becker managed to distil this into a simple example. > Can anyone shed any light on what is happening below? Is Python > behaving as it should? It looks to me like you have two "parent" modules. When you run "test.py" directly from the command line, the first "from parent import *" imports parent.py as module "parent". But subsequently parent.py is imported again as module "A.parent". Similarly, you have two "Examiner" classes. In run0() you get Examiner from __main__, which contains the Parent class from module "parent". In run1() you get Examiner from A.test, which contains the Parent class imported from module "A.parent". If you insert print 'in module', __name__, 'parent is', repr(Parent) at the beginning of the examine() method, it should make things clear. The solution is to avoid directly running scripts that are inside packages; the confusion is produced by the fact that you're running "test.py" from within the A/ directory. -- ?!ng From jeremy at beopen.com Wed Jun 7 23:25:53 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Wed, 7 Jun 2000 17:25:53 -0400 (EDT) Subject: [Python-Dev] revamped Python web site Message-ID: <14654.48609.710990.321688@localhost.localdomain> Say a startup company decided to put some resources behind the Python Web site -- a full-time Web master, some content developers, etc. What would you have them do? What could be done to open up the site to the community and make it more responsive to developers and users? What's your wish list for content, services, etc.? If you've got any ideas, please get back to me soon. Jeremy From esr at thyrsus.com Wed Jun 7 23:41:48 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 7 Jun 2000 17:41:48 -0400 Subject: [Python-Dev] revamped Python web site In-Reply-To: <14654.48609.710990.321688@localhost.localdomain>; from jeremy@beopen.com on Wed, Jun 07, 2000 at 05:25:53PM -0400 References: <14654.48609.710990.321688@localhost.localdomain> Message-ID: <20000607174148.A6801@thyrsus.com> Jeremy Hylton : > Say a startup company decided to put some resources behind the Python > Web site -- a full-time Web master, some content developers, etc. > What would you have them do? What could be done to open up the site > to the community and make it more responsive to developers and users? > What's your wish list for content, services, etc.? I think it's pretty good as is -- lots of content, pretty well organized. My top wishlist item is "Burn all your GIFs". -- Eric S. Raymond The right of self-defense is the first law of nature: in most governments it has been the study of rulers to confine this right within the narrowest limits possible. Wherever standing armies are kept up, and when the right of the people to keep and bear arms is, under any color or pretext whatsoever, prohibited, liberty, if not already annihilated, is on the brink of destruction." -- Henry St. George Tucker (in Blackstone's Commentaries) From jack at oratrix.nl Wed Jun 7 23:47:01 2000 From: jack at oratrix.nl (Jack Jansen) Date: Wed, 07 Jun 2000 23:47:01 +0200 Subject: [Python-Dev] hey, who broke the array module? In-Reply-To: Message by Guido van Rossum , Thu, 18 May 2000 15:05:45 -0700 , <200005182205.PAA12830@cj20424-a.reston1.va.home.com> Message-ID: <20000607214706.65CB2D8397@oratrix.oratrix.nl> Recently, Guido van Rossum said: > > On Thu, May 18, 2000 at 12:01:16PM +0200, Jack Jansen wrote: > > > > I broke it with my patches to test overflow for some of the PyArg_Parse > *() > > > > formatting characters. The upshot of testing for overflow is that now t > hose > > > > formatting characters ('b', 'h', 'i', 'l') enforce signed-ness or > > > > unsigned-ness as appropriate (you have to know if the value is signed o > r > > > > unsigned to know what limits to check against for overflow). Two > > > > possibilities presented themselves: > > > > > > I think this is a _very_ bad idea. I have a few thousand (literally) rout > ines > > > calling to Macintosh system calls that use "h" for 16 bit flag-word value > s, > > > and the constants are all of the form > > > > > > kDoSomething = 0x0001 > > > kDoSomethingElse = 0x0002 > > > ... > > > kDoSomethingEvenMoreBrilliant = 0x8000 > > > > > > I'm pretty sure other operating systems have lots of calls with similar > > > problems. I would strongly suggest using a new format char if you want > > > overflow-tested integers. > > > > Sigh. What do you think Guido? This is your call. > > > > 1. go back to no bounds testing > > 2. bounds check for [SHRT_MIN, USHRT_MAX] etc (this would allow signed and > > unsigned values but is sort of false security for bounds checking) > > 3. keep it the way it is: 'b' is unsigned and the rest are signed > > 4. add new format characters or a modifying character for signed and unsign > ed > > versions of these. > > Sigh indeed. Ideally, we'd introduce H for unsigned and then lock > Jack in a room with his Macintosh computer for 48 hours to fix all his > code... Hmm, hmm. As stated before I'm not too fond of this as it is a gratuitous change that breaks lots of things (not only in Mac modules: the array module was what started this discussion, test_cPickle and test_pkg crash, socketmodule, os.stat() and I assume all code that uses structmodule will also have to be looked at, and quite possibly there's a lot more) and for which I don't really see all that much benefit. As a datapoint: a quick search for 8-digit hex numbers starting with digit 8-F and not suffixed with an L throughout the Python files in the distribution found a stunning 464 matches. Add another 1147 4-digit hex numbers with the sign bit on and there are an awful lot of candidates for breaking... -- 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 gmcm at hypernet.com Wed Jun 7 23:59:20 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Wed, 7 Jun 2000 17:59:20 -0400 Subject: [Python-Dev] Package ambiguities In-Reply-To: References: <393eb52b.47053339@post.demon.co.uk> Message-ID: <1251707300-11412775@hypernet.com> Ka-Ping wrote: > On Wed, 7 Jun 2000, Andy Robinson wrote: > > We hit some very weird behaviour recently while setting up a > > package hierarchy. Robin Becker managed to distil this into a > > simple example. Can anyone shed any light on what is happening > > below? Is Python behaving as it should? [snip entirely correct analysis] > The solution is to avoid directly running scripts that are > inside packages; the confusion is produced by the fact that > you're running "test.py" from within the A/ directory. I disagree with the moral. If test.py uses "import A.parent" and changes references accordingly, it works. So my version of the moral is that import * is EVIL. Not only that, but relative imports are EVIL. This is what I meant when I said (in reply to Greg Wilson's inquiry about package structures) that there are some very bad precedents getting set. Doing this junk (usually in __init__.py) not only makes your package fragile, it also makes the package structure mysterious to the user (who's a developer - making things mysterious to him/her is just making both your lives harder!). If you want to make it friendly to lazy coders, then something like: import A.parent Parent = A.parent.Parent also works, (leaving references as Parent). I'm not terribly fond of this, either, but at least the coder has a reasonable hope of tracking down what "Parent" actually is. I'm not necessarily yelling at you, Andy. It seems that most package developers are going down this slope. It stinks. - Gordon From jeremy at beopen.com Thu Jun 8 00:06:29 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Wed, 7 Jun 2000 18:06:29 -0400 (EDT) Subject: [Python-Dev] Package ambiguities In-Reply-To: <1251707300-11412775@hypernet.com> References: <393eb52b.47053339@post.demon.co.uk> <1251707300-11412775@hypernet.com> Message-ID: <14654.51045.18807.74677@localhost.localdomain> Gordon's comments are on the money. An import in a module inside a package should be fully qualified. I'd put that in the style guide if it were up to me (and, of course, it's not). Jeremy From bwarsaw at python.org Thu Jun 8 00:38:02 2000 From: bwarsaw at python.org (Barry A. Warsaw) Date: Wed, 7 Jun 2000 18:38:02 -0400 (EDT) Subject: [Python-Dev] Package ambiguities References: <393eb52b.47053339@post.demon.co.uk> <1251707300-11412775@hypernet.com> <14654.51045.18807.74677@localhost.localdomain> Message-ID: <14654.52938.139406.371556@anthem.concentric.net> >>>>> "JH" == Jeremy Hylton writes: JH> Gordon's comments are on the money. An import in a module JH> inside a package should be fully qualified. I'd put that in JH> the style guide if it were up to me (and, of course, it's JH> not). I concur on both points. BTW, one of the Things I'd Like To Do, is update and flesh out the style guide. It's incomplete in places and out of date in others. If someone else has the gumption to lead this effort, I'd be happy to send my comments instead. -Barry From pingster at ilm.com Thu Jun 8 00:39:28 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Wed, 7 Jun 2000 15:39:28 -0700 (PDT) Subject: [Python-Dev] Package ambiguities In-Reply-To: <1251707300-11412775@hypernet.com> Message-ID: On Wed, 7 Jun 2000, Gordon McMillan wrote: > I disagree with the moral. > > If test.py uses "import A.parent" and changes references > accordingly, it works. Correct. Well, maybe there are two things going on here. I agree that import * isn't usually a very good idea. However, notice that the problem occurs even if the first line of test.py is "import parent" (no star). When you talk about changing references accordingly, the real issue is referencing "A.parent" rather than "parent". In fact, if you change the first line to "from A.parent import *" (not that i am advocating this!) -- it works. In short: from parent import * ... Parent doesn't work import parent ... parent.Parent doesn't work from A.parent import * ... Parent works import A.parent ... A.parent.Parent works The first two cases -- attempting to import "parent" -- are only made possible by the fact that we're executing test.py from within the A/ directory, and hence the confusion. This problem is an "advanced" version of a simpler issue which a friend of mine discovered and complained about recently to me: the __main__ vs. module-name conflict. Allow me to paraphrase his example. Exhibit A: ---- spam.py ---- import eggs def go(): print "was", eggs.a eggs.a = 3 print "now", eggs.a ---- eggs.py ---- import spam a = 1 def go(): spam.go() print "finally", a if __name__ == "__main__": go() --- watch what happens ---- % python eggs.py was 1 now 3 finally 1 % python >>> import eggs >>> eggs.go() was 1 now 3 finally 3 Exhibit B: ---- one.py ---- import two def go(): pass ---- two.py ---- import one one.go() ---- watch what happens ---- % python one.py % python two.py Traceback (innermost last): File "two.py", line 1, in ? import one File "./one.py", line 1, in ? import two File "./two.py", line 2, in ? one.go() AttributeError: go Exit 1 % python >>> import one Traceback (innermost last): File "", line 1, in ? File "./one.py", line 1, in ? import two File "./two.py", line 2, in ? one.go() AttributeError: go >>> import two >>> The facts that eggs.a appears to behave differently in Exhibit A, and that one.py can be run but two.py cannot, yet "two" can be imported and "one" cannot, in Exhibit B, both result from the duplication namespaces in __main__ and in a module. Normally, this only affects the main file that you are running, the one with the __main__ namespace. However, attempting to run scripts in package directories allows this problem to propagate further into the duplication of other modules: __main__ imports parent which imports child A.test imports A.parent which imports A.child ...and that can cause duplicate classes all over the place, which is what happened to Andy. My friend was quite irked by the existence of __main__, citing it as the culprit for this duplication. But naturally Python can't always know the name of the script being run -- in the case of a file ending in .py, perhaps, it's easy, but the script might come from a pipe, for example. So eliminating __main__ doesn't seem like a feasible response. Depending how "real" you consider this problem, leaving things as they are and instructing people in the discipline of keeping modules and scripts separated may be the best response. I bet this crops up all the time in those "testing" sections of modules that use the 'if __name__ == "__main__"' convention, though... -- ?!ng "Computers are useless. They can only give you answers." -- Pablo Picasso From petrilli at amber.org Thu Jun 8 00:51:50 2000 From: petrilli at amber.org (Christopher Petrilli) Date: Wed, 7 Jun 2000 18:51:50 -0400 Subject: [Python-Dev] Package ambiguities In-Reply-To: <14654.52938.139406.371556@anthem.concentric.net>; from bwarsaw@python.org on Wed, Jun 07, 2000 at 06:38:02PM -0400 References: <393eb52b.47053339@post.demon.co.uk> <1251707300-11412775@hypernet.com> <14654.51045.18807.74677@localhost.localdomain> <14654.52938.139406.371556@anthem.concentric.net> Message-ID: <20000607185150.A29156@trump.amber.org> Barry A. Warsaw [bwarsaw at python.org] wrote: > > >>>>> "JH" == Jeremy Hylton writes: > > JH> Gordon's comments are on the money. An import in a module > JH> inside a package should be fully qualified. I'd put that in > JH> the style guide if it were up to me (and, of course, it's > JH> not). > > I concur on both points. BTW, one of the Things I'd Like To Do, is > update and flesh out the style guide. It's incomplete in places and > out of date in others. If someone else has the gumption to lead this > effort, I'd be happy to send my comments instead. Something we futzed with at Digital Creations was "commentable" or discussable web pages. This would be a great use for this. If you took and made each basic topic/issue a page, and let people "discuss" them. A nice threaded discussion could add a lot of insight. This is versus a wiki where it's more "free for all", which isn't really appropraiate for a "guide". Chris -- | Christopher Petrilli | petrilli at amber.org From pingster at ilm.com Thu Jun 8 00:48:29 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Wed, 7 Jun 2000 15:48:29 -0700 (PDT) Subject: [Python-Dev] Package ambiguities In-Reply-To: <20000607185150.A29156@trump.amber.org> Message-ID: On Wed, 7 Jun 2000, Christopher Petrilli wrote: > Something we futzed with at Digital Creations was "commentable" or > discussable web pages. This would be a great use for this. If you > took and made each basic topic/issue a page, and let people "discuss" > them. A nice threaded discussion could add a lot of insight. This > is versus a wiki where it's more "free for all", which isn't really > appropraiate for a "guide". Well, y'all could go nuts marking up the style guide with Crit. http://crit.org/ ...or marking up anything else on the whole Web, for that matter. :) -- ?!ng "To be human is to continually change. Your desire to remain what you are is what ultimately limits you." -- The Puppet Master, Ghost in the Shell From jeremy at beopen.com Thu Jun 8 01:00:36 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Wed, 7 Jun 2000 19:00:36 -0400 (EDT) Subject: [Python-Dev] Package ambiguities In-Reply-To: References: <1251707300-11412775@hypernet.com> Message-ID: <14654.54292.711289.254224@localhost.localdomain> >In fact, if you change the first line to "from A.parent import *" >(not that i am advocating this!) -- it works. In short: > > from parent import * ... Parent doesn't work > import parent ... parent.Parent doesn't work > > from A.parent import * ... Parent works > import A.parent ... A.parent.Parent works One other possibility that ought to work (?) from A import parent Jeremy From gmcm at hypernet.com Thu Jun 8 01:47:47 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Wed, 7 Jun 2000 19:47:47 -0400 Subject: [Python-Dev] Package ambiguities In-Reply-To: References: <1251707300-11412775@hypernet.com> Message-ID: <1251700795-11803988@hypernet.com> Ka-Ping wrote: > ... In short: > > from parent import * ... Parent doesn't work > import parent ... parent.Parent doesn't work > > from A.parent import * ... Parent works > import A.parent ... A.parent.Parent works Right. That's why I cast relative imports as evil. > This problem is an "advanced" version of a simpler issue > which a friend of mine discovered and complained about > recently to me: the __main__ vs. module-name conflict. This comes up a whole lot. In those periods where I have the time, energy and patience to monitor c.l.py closely, I've seen this come up 4 or 5 times in one week. Almost always in conjunction with import *. I can live with explaining how __main__ is special. That's one of those "you only have to explain it once" problems. But the import * problems (name hiding, the fact that assignments aren't seen) and relative imports are things that come up over and over again, and trip up even experienced people (and them more than once). - Gordon From gstein at lyra.org Thu Jun 8 04:30:14 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 7 Jun 2000 19:30:14 -0700 Subject: [Python-Dev] Idea: emulating _locale In-Reply-To: <393E2304.4BE8CDE0@lemburg.com>; from mal@lemburg.com on Wed, Jun 07, 2000 at 12:25:08PM +0200 References: <393E2304.4BE8CDE0@lemburg.com> Message-ID: <20000607193014.P3348@lyra.org> On Wed, Jun 07, 2000 at 12:25:08PM +0200, M.-A. Lemburg wrote: >... > Peter Funk wrote: >... > > > + ### C lib locale APIs > > > + > > > + from _locale import * > > > > Wouldn't it be clever to provide some dummy stubs on those platforms, where > > the _locale module was not enabled? > > > > try: > > from _locale import * > > except: > > def setlocale(.... > > def localeconv(.... > > ... > > > > Especially the MacOS 1.5.2 release provided by Jack Jansen was > > compiled without '_locale'. And at least in Python 1.6a2 '_locale' > > is still disabled per default in 'Modules/Setup.in'. I didn't had > > a look into the current CVS though, so this may have changed. > > > > I think the name aliasing tables might be also useful on those > > systems lacking locale support in their C-library. > > setlocale and localeconv are ANSI C and Python requires an ANSI C > compiler, so there should be no problem (at least in theory). > > If there is a problem, adding the missing symbols would > be no problem: the APIs could always report locale 'C' > and its numeric settings. An ANSI C compiler and the ANSI C library are very different. Just because Python requires an ANSI compiler (or close to it), does NOT mean that we can or should depend upon particular elements in the library. IMO, we should follow Peter's advice and have stubs for the platforms where _locale is not built. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Thu Jun 8 04:35:37 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 7 Jun 2000 19:35:37 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Objects unicodeobject.c,2.21,2.22 In-Reply-To: <200006070913.CAA18060@slayer.i.sourceforge.net>; from lemburg@slayer.i.sourceforge.net on Wed, Jun 07, 2000 at 02:13:24AM -0700 References: <200006070913.CAA18060@slayer.i.sourceforge.net> Message-ID: <20000607193537.Q3348@lyra.org> On Wed, Jun 07, 2000 at 02:13:24AM -0700, Marc-Andre Lemburg wrote: > Update of /cvsroot/python/python/dist/src/Objects > In directory slayer.i.sourceforge.net:/tmp/cvs-serv17917/Objects > > Modified Files: > unicodeobject.c > Log Message: > Marc-Andre Lemburg : > Change the default encoding to 'ascii' (it was previously > defined as UTF-8). > > Note: The implementation still uses UTF-8 to implement > the buffer protocol, so C APIs will still see UTF-8. This > is on purpose: rather than fixing the Unicode implementation, > the C APIs should be made Unicode aware. I'm a little confused on where this gets applied. Is this when somebody says "str(unicode_ob)", they get back ASCII rather than UTF-8? Or is this when somebody says "unicode(str)" and we expect to be ASCII? Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Thu Jun 8 05:06:24 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 7 Jun 2000 20:06:24 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils/command sdist.py,1.25,1.26 In-Reply-To: <200006080008.RAA15980@slayer.i.sourceforge.net>; from gward@slayer.i.sourceforge.net on Wed, Jun 07, 2000 at 05:08:17PM -0700 References: <200006080008.RAA15980@slayer.i.sourceforge.net> Message-ID: <20000607200624.R3348@lyra.org> On Wed, Jun 07, 2000 at 05:08:17PM -0700, Greg Ward wrote: > Update of /cvsroot/python/distutils/distutils/command > In directory slayer.i.sourceforge.net:/tmp/cvs-serv15881 > > Modified Files: > sdist.py > Log Message: > Made all debug output go through the 'debug_print()' method instead of > directly printing to stdout. This was a bit more work than it sounds like > it should have been: > * turned 'select_pattern()' and 'exclude_pattern()' from functions into > methods, so they can refer to 'self' to access the method You wouldn't have to do this if you make debug_print() a function. There is nothing in debug_print() that requires "self", so its existence as a method is suspect in the first place. Considering the fallout changes, I'd say move debug_print() to a plain function (in "utils"). Unless you were planning on more stuff in there; if so, then a comment in debug_print would be nice. >... > *************** > *** 297,301 **** > if (cur_dir == dir and > (pattern_re is None or pattern_re.match (cur_base))): > ! print "removing %s" % self.files[i] > del self.files[i] > > --- 298,302 ---- > if (cur_dir == dir and > (pattern_re is None or pattern_re.match (cur_base))): > ! self.debug_print("removing %s" % self.files[i]) > del self.files[i] Gah... "pattern_re.match (cur_base)" ... You do realize that God intended there to be no spaces between a function name and the opening paren? Heretic! :-) Really -- I have noticed this throughout a lot of the distutils code. That space in there is really awful. It reduces the "binding" of the name to the paren, which changes the meaning during a quick read. Put another way: when you skim code, NAME( is a function call and NAME ( is something else. A space after a name usually indicates the name is participating in an expression, rather than being used as a function name. Then, you hit the paren and go "what the heck? oh. a function call." Please... can they be removed? Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Thu Jun 8 06:05:55 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 7 Jun 2000 21:05:55 -0700 Subject: [Python-Dev] release forms? (was: [Patches] New sys method to return total reference count in debug builds.) In-Reply-To: ; from moshez@math.huji.ac.il on Wed, Jun 07, 2000 at 05:33:10PM +0300 References: <20000607101146.D5559@ludwig.cnri.reston.va.us> Message-ID: <20000607210555.X3348@lyra.org> On Wed, Jun 07, 2000 at 05:33:10PM +0300, Moshe Zadka wrote: > On Wed, 7 Jun 2000, Greg Ward wrote: > > > CNRI has absolutely no moral right to it (although probably some legal > > right), I'd prefer to sign it away to Guido. Or optionally, to some > > legal fiction that represents the Python community; preferably *not* the > > Python Consortium, as long as CNRI is in any way connected. > > Who's in charge of the PSA? CNRI Effectively, the PSA is a legal fiction for collecting donations to further the development of Python. The Consortium is similar, but members have the actual/explicit capability to steer Python's development. I believe this ability to steer the development is (was?) rooted in the fact that CNRI employed Guido. I have no idea how that will work now -- the "steering" will (essentially) have to rely entirely on Guido's good graces. Guido is an excellent listener to people's needs, so there is no immediate problem here. > Or should we form *another* non-profit, and sign it over to it? The Apache Software Foundation is already a legal, formed, non-profit corporation. If the desire is to transfer copyright to a non-profit, then I'd recommend reusing the ASF rather than trying to start a new one. Recognize that running a company (even a non-profit) is not a "zero cost" item. Somebody would have to put that time in. CNRI is also non-profit, but its members/board/directors/etc are not as Open Source minded as the ASF. > (Personally, I couldn't care less who I transfer copyright over my Python > contributions to -- I'd put it in the public domain if that's what it > took) As Barry said: license and copyright are different. Since you own the copyright, then you *can* put it into the public domain Right Now. I've done that with some of my modules (e.g. qp_xml and imputil). Here is the header from qp_xml.py: # # qp_xml: Quick Parsing for XML # # Written by Greg Stein. Public Domain. # No Copyright, no Rights Reserved, and no Warranties. # Fun, huh? :-) On the other hand, I have given Guido two pieces of code: httplib.py and davlib.py: # # DAV client library # # Copyright (C) 1998-1999 Guido van Rossum. All Rights Reserved. # Written by Greg Stein. Given to Guido. Licensed using the Python license. # Oh. I need to update his copyright year :-) Want to know something really funny? Presuming my httplib.py goes into the Python distribution, that will be the first piece of code that Guido truly owns in Python. All the other code he wrote is owned by CWI or CNRI.... Cheers, -g -- Greg Stein, http://www.lyra.org/ From fredrik at pythonware.com Thu Jun 8 10:30:39 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Thu, 8 Jun 2000 10:30:39 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils/command sdist.py,1.25,1.26 References: <200006080008.RAA15980@slayer.i.sourceforge.net> <20000607200624.R3348@lyra.org> Message-ID: <009501bfd123$d4b2c750$0500a8c0@secret.pythonware.com> greg wrote: > Gah... "pattern_re.match (cur_base)" ... > > You do realize that God intended there to be no spaces between a function > name and the opening paren? Heretic! http://www.python.org/doc/essays/styleguide.html ... I hate whitespace in the following places: ... Immediately before the open parenthesis that starts the argument list of a function call, as in spam (1). Always write this as spam(1). ... Don't bother to argue with me on any of the above ... From andy at robanal.demon.co.uk Thu Jun 8 10:42:46 2000 From: andy at robanal.demon.co.uk (Andy Robinson) Date: Thu, 8 Jun 2000 09:42:46 +0100 Subject: [Python-Dev] Package Style Guide In-Reply-To: <20000608030555.532221CDEF@dinsdale.python.org> Message-ID: Thanks for all the replies. We really need a 'style guide' on package use, so I hope this example can be thrashed out and used to help others. We need to decide something and release next week, and also provide good docs for other users who will be new to Python. Apart from the ambiguity, which was a surprise but which we can work around, I have some general questions on the "right thing". Here are my examples: 1. use of __init__ to save users work ------------------------------------ ReportLab has a subpackage called 'platypus' which we have just reorganized and not yet released. The division into subpackages is clear - each exposes a different kind of functionality - but the division of each package into modules is based on keeping a sane length for each and not on providing a friendly user interface. reportlab pdfgen canvas.py defines class Canvas textobject.py defines class TextObject pathobject.py defines class PathObject platypus (the same problem, but 3x worse) lib (loads of modules, all independent) We reached a point where users need to import eight or ten classes to do useful work and were having to put eight or ten different import lines at the top of every script. This just feels dumb and wrong. So, the 'least messy' idea was to put __init__.py methods in each subpackage which explicitly import what they need. (We have not used "import *") ---reportlab/pdfgen/__init__.py-------- from canvas import Canvas from textobject.py import TextObject from pathobject.py impory PathObject Then users can just do: from reportlab.pdfgen import Canvas, PathObject, TextObject It seems that this (a) makes life easier for users, and (b) gives us freedom to refactor code as it grows, without changing the user interface. Is this style evil? If so, why? 2. Ambiguities running scripts within package --------------------------------------------- We have various test functions scattered throughout our distribution. A control script iterates through the lot and kicks them off before every release, executing everything with an 'if __name__=='__main__' handler. If these were standalone scripts just for testing, they could import "reportlab.platypus.tables" or whatever. But if I just want to put a test routine at the end of "reportlab.platypus.tables" then I seem destined to run into exactly the ambiguity outlined before. Should test scripts all be moved out of the package? Indeed, is Python behaving the way it ought to? 3. Preferred subpackage import technique ---------------------------------------- I have two scripts 'spam.py' and 'eggs.py' in subpackage 'A.B'. spam imports eggs. Should it say... import eggs or... import A.B.eggs? Both work sometimes, but can lead to different behavious sometimes. Which is the preferred style? Thanks, Andy Robinson From pf at artcom-gmbh.de Thu Jun 8 11:35:14 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Thu, 8 Jun 2000 11:35:14 +0200 (MEST) Subject: [Python-Dev] Package Style Guide In-Reply-To: from Andy Robinson at "Jun 8, 2000 9:42:46 am" Message-ID: Hi Andy, > Thanks for all the replies. > We really need a 'style guide' on package use, On 'import', packages and modules: ---------------------------------- You should definitely have a look at the approach used by Greg McFarlane in his 'Pmw' package. In particular at his PmwLoader class and the Pmw.def. For my own project I've simplified and somewhat generalized his approach to dynamic and lazy importing. I posted a preliminary implemantation of this to comp.lang.python a while ago but didn't got much feedback. May be due to fact, that I had to repost the thing, because the TABs went wrong in the first try :-( [...] > Is this style evil? If so, why? I believe it will get really hard to come up with a 'namespace style guide' which everybody can aggree on. But who cares: let's start a rant: --> IMO 'from ... import ...' is EVIL and its use should be banned! <-- Why? Because if software becomes bigger (> 100k LOC), these unqualified names definitely become a maintaince nightmare, since you didn't know what names are defined in the module you are currently staring at and what names come from the "outside world". I believe Python inherited two of its three forms of import syntax at least in part from its anchestors Modula-2 and Modula-3. My perception of this import-problem may be blurred by programming in Modula-2 in our company since 1985, where the code base now is about ~1 Mio. LOC. Some of the older code contains still modules using a lot of 'FROM foobar IMPORT ....;' lines in the header. These have usually been harder to read and understand by new employees than those having 'IMPORT foobar;' in the header and than using 'foobar.component' everywhere in the code body below. from .... import * is *EVEN MORE EVIL*. Well: at least if people use 'from' to import arbitrary objects and classes. Using 'from package.subpackage import module' is an idiom, with which I can live with comfortably. > Should test scripts all be moved out of the package? This would defeat the use of Tim Peters wonderful 'doctest' module. I'm still thinking, 'doctest' should be made part of the standard library in order to give the publicity this elegant approach deserves. Regards, Peter From Vladimir.Marangozov at inrialpes.fr Thu Jun 8 12:27:10 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Thu, 8 Jun 2000 12:27:10 +0200 (CEST) Subject: [Python-Dev] revamped Python web site In-Reply-To: <20000607174148.A6801@thyrsus.com> from "Eric S. Raymond" at Jun 07, 2000 05:41:48 PM Message-ID: <200006081027.MAA02445@python.inrialpes.fr> [Jeremy Hylton] > > Say a startup company decided to put some resources behind the Python > Web site -- a full-time Web master, some content developers, etc. > What would you have them do? What could be done to open up the site > to the community and make it more responsive to developers and users? > What's your wish list for content, services, etc.? The content is good. Some wishes on its presentation, not taking into account any cosmetic changes. With my webmaster's hat, I would say: 1. Make the content accessible, i.e. compliant to the standards HTML tidy does a pretty good job in cleaning up existing Web pages I would suggest sticking with valid XHTML 1.0 transitional or HTML 4.x transitional. 2. Use CSS -- not too much, though, given its growing but still limited support. I am using myself parts of CSS1. My approach is to use styles *and* attributes (which is redundant, for now). Browsers that understand styles would honor them, while those that don't would take into account the attributes. The aim is to have the same end result. With the evolution of the browsers, the attributes would disappear. A compromise that introduces styles smoothly. 3. Have a comprehensible site map for direct access to the major topics. I tend to like ours which is convenient for small to medium sized sites (http://www.inrialpes.fr/plansite.html) 4. Do not use frames, do not use JavaScript or similar, do not use anything that hurts content accessibility. [Eric S. Raymond] > > My top wishlist item is "Burn all your GIFs". This seems to be an important symbol for an organization with an Open Source spirit. Hopefully, a gif2png batch processing should make things easier. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From gstein at lyra.org Thu Jun 8 13:43:24 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 8 Jun 2000 04:43:24 -0700 Subject: [Python-Dev] Package Style Guide In-Reply-To: ; from pf@artcom-gmbh.de on Thu, Jun 08, 2000 at 11:35:14AM +0200 References: Message-ID: <20000608044324.L3348@lyra.org> On Thu, Jun 08, 2000 at 11:35:14AM +0200, Peter Funk wrote: >... > > Is this style evil? If so, why? > > I believe it will get really hard to come up with a 'namespace style guide' > which everybody can aggree on. But who cares: let's start a rant: > > --> IMO 'from ... import ...' is EVIL and its use should be banned! <-- You are being overly strict here. I use this all the time: from module import submodule ... submodule.Class() or even from module.submodule import subsub ... subsub.Blargle() In other words, "from package import module" is a Fine Thing. It can simplify your code without hiding where the symbols come from. In general, I agree with you: importing symbols from a module into your namespace is a Bad Thing. Cheers, -g -- Greg Stein, http://www.lyra.org/ From fdrake at beopen.com Thu Jun 8 14:37:04 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 8 Jun 2000 08:37:04 -0400 (EDT) Subject: [Python-Dev] revamped Python web site In-Reply-To: <200006081027.MAA02445@python.inrialpes.fr> References: <20000607174148.A6801@thyrsus.com> <200006081027.MAA02445@python.inrialpes.fr> Message-ID: <14655.37744.352128.72841@cj42289-a.reston1.va.home.com> Vladimir Marangozov writes: > 2. Use CSS -- not too much, though, given its growing but still limited > support. I am using myself parts of CSS1. My approach is to use styles > *and* attributes (which is redundant, for now). Browsers that understand > styles would honor them, while those that don't would take into account > the attributes. The aim is to have the same end result. With the evolution > of the browsers, the attributes would disappear. The approach to CSS I've taken with the documentation is to use attributes for anything that's really needed to make the presentation readable and then an external CSS stylesheet for everything else. This seems like a reasonable approach to me, and avoids including too much duplicate information. This also seems like the best way to maintain support for older browsers. Perhaps we should collect browser statistics on python.org so we'll know how many "legacy" browsers are in use? I would be surprised if many of the text-mode browsers support CSS well (and there are several being actively worked on these days, so please don't tell me they don't count!). > 4. Do not use frames, do not use JavaScript or similar, do not use anything > that hurts content accessibility. I do have some JavaScript on python.org, but it's only to make data entry in a form a little easier by making adjustments to related fields, so it remains completely operational without JavaScript. I don't think there's currently any required JavaScript. And I have yet to see a frame, thank goodness! [Eric S. Raymond] > > My top wishlist item is "Burn all your GIFs". Is it more important than accessibility? This is a real issue for legacy browsers, especially on minority platforms. One of the big wins for Python is that it is as portable as it is. Does that matter if information is hard to get to? A good reason to avoid using images for anything that isn't cosmetic! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From pf at artcom-gmbh.de Thu Jun 8 14:28:11 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Thu, 8 Jun 2000 14:28:11 +0200 (MEST) Subject: [Python-Dev] Package Style Guide In-Reply-To: <20000608044324.L3348@lyra.org> from Greg Stein at "Jun 8, 2000 4:43:24 am" Message-ID: Hi Greg, [me] > > --> IMO 'from ... import ...' is EVIL and its use should be banned! <-- [Greg Stein]: > You are being overly strict here. I use this all the time: > > from module import submodule > ... > submodule.Class() > > or even > > from module.submodule import subsub > ... > subsub.Blargle() Okay. Later in my rant I wrote: < Well: at least if people use 'from' to import arbitrary objects and < classes. Using 'from package.subpackage import module' is an idiom, < with which I can live with comfortably. [Greg Stein]: > In other words, "from package import module" is a Fine Thing. It can > simplify your code without hiding where the symbols come from. Yes, you are right. But if you put the facade pattern[*] into use within such packages, this will even simplify your live, if you later have to redesign the internal substructure of your package. [*] Design patterns and especially the "facade pattern" were AFAIK introduced in the so called "Gang of four" book: "Design Patterns - Elements of Reusable Object-Oriented Software", Addison Wesley, 1995. The somewhat similar "whole part" design pattern is discussed in the book "A System of Patterns" written by Buschmann, Meunier, Rohnert, Sommerlad, Stal; published by John Wiley & Sons, New York; 1996; ISBN 0 471 95869 7 > In general, I agree with you: importing symbols from a module into your > namespace is a Bad Thing. Fine. Consensus gives a warm and fuzzy feeling. ;-) Regards, Peter From esr at thyrsus.com Thu Jun 8 14:53:51 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 8 Jun 2000 08:53:51 -0400 Subject: [Python-Dev] revamped Python web site In-Reply-To: <14655.37744.352128.72841@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Thu, Jun 08, 2000 at 08:37:04AM -0400 References: <20000607174148.A6801@thyrsus.com> <200006081027.MAA02445@python.inrialpes.fr> <14655.37744.352128.72841@cj42289-a.reston1.va.home.com> Message-ID: <20000608085351.A9299@thyrsus.com> Fred L. Drake, Jr. : > [Eric S. Raymond] > > > > My top wishlist item is "Burn all your GIFs". > > Is it more important than accessibility? This is a real issue for > legacy browsers, especially on minority platforms. One of the big > wins for Python is that it is as portable as it is. Does that matter > if information is hard to get to? Go check out the PNG site's census of PNG support in "legacy" browsers. Basically, as long as your PNGs don't use transparency or animation, you're fine. You've already had the good taste to eschew animation. I don't think you're using transparency anywhere that simply matteing the image on a white background won't fix it -- and gif2png has an option to do that. > A good reason to avoid using images for anything that isn't > cosmetic! I agree with that. -- Eric S. Raymond Sometimes the law defends plunder and participates in it. Sometimes the law places the whole apparatus of judges, police, prisons and gendarmes at the service of the plunderers, and treats the victim -- when he defends himself -- as a criminal. -- Frederic Bastiat, "The Law" From jeremy at beopen.com Thu Jun 8 15:58:42 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 8 Jun 2000 09:58:42 -0400 (EDT) Subject: [Python-Dev] release forms? (was: [Patches] New sys method to return total reference count in debug builds.) In-Reply-To: <20000607210555.X3348@lyra.org> References: <20000607101146.D5559@ludwig.cnri.reston.va.us> <20000607210555.X3348@lyra.org> Message-ID: <14655.42642.608768.433695@localhost.localdomain> >>>>> "GS" == Greg Stein writes: GS> On Wed, Jun 07, 2000 at 05:33:10PM +0300, Moshe Zadka wrote: >> On Wed, 7 Jun 2000, Greg Ward wrote: >> >> > CNRI has absolutely no moral right to it (although probably >> some legal > right), I'd prefer to sign it away to Guido. Or >> optionally, to some > legal fiction that represents the Python >> community; preferably *not* the > Python Consortium, as long as >> CNRI is in any way connected. >> >> Who's in charge of the PSA? GS> CNRI GS> Effectively, the PSA is a legal fiction for collecting donations GS> to further the development of Python. The Consortium is similar, GS> but members have the actual/explicit capability to steer GS> Python's development. I believe this ability to steer the GS> development is (was?) rooted in the fact that CNRI employed GS> Guido. I have no idea how that will work now -- the "steering" GS> will (essentially) have to rely entirely on Guido's good GS> graces. Guido is an excellent listener to people's needs, so GS> there is no immediate problem here. The description of the PSA isn't exactly right. The PSA FAQ has an official explanation, which may not be right either, but at least it's what CNRI wants you to think. (And it may be right; I don't mean to suggest a nefarious plot, just that the relationship is convoluted enough that the explanation could be wrong.) http://www.python.org/psa/FAQ.html An abbreviated version follows: |Where does the money from membership fees go and who pays the rest? | | The money goes towards the salary of those who maintain and | coordinate the Python web site, ftp server, mailing lists, | conference expenses etc.... The case for these expenditures is | that a seed community is being incubated. CNRI officers and | directors see proof of the existence of such a community from the | fact that some members of that community are willing to pay some | of their own money to foster the activity. | |Who funds Python's development? | PSA fees do not fund the Python development effort.... CNRI is no longer maintaining python.org, although it still owns the domain and maintains the equipment it runs on. The existence of a community should be obvious now, without the need for people to pay money to prove it. Jeremy From skip at mojam.com Thu Jun 8 16:08:13 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 8 Jun 2000 09:08:13 -0500 Subject: [Python-Dev] impact of cycle gc... Message-ID: <200006081408.JAA03136@beluga.mojam.com> I spent a little time poking around with a very simple test script (appended) that makes use of Neil's cycle gc patch. It measures the time it takes to instantiate and delete a cycle-producing instance 100,000 times (based upon a report in python-bugs). For vanilla 1.6a2 ("./configure" ; make") I got the following (last of six runs): memory usage @ start: 5560 clock: 1.33 elapsed: 1.34805500507 memory usage @ end: 18816 For 1.6a2 configured --with-cycle-gc ("./configure --with-cycle-gc ; make") I got the following (also the last of six runs): memory usage @ start: 5576 clock: 2.34 elapsed: 2.33785700798 memory usage @ end: 5576 I was very impressed with the memory usage, but dismayed at the increased execution time (about 75% more). Of course, this is a test script that is bound to show the potential performance penalty in the worst possible light. Maybe pystone will be more indicative of the performance hit we can expect from it. (There's a new one - pystone.py being a better indicator of true system performance than some other test script!) Plain: Pystone(1.1) time for 10000 passes = 1.76 This machine benchmarks at 5681.82 pystones/second --with-cycle-gc: Pystone(1.1) time for 10000 passes = 1.83 This machine benchmarks at 5464.48 pystones/second That suggests something more like a 4% performance penalty. I suspect that may be the lower limit. While I haven't looked at pystone recently, I doubt it creates any cyclic garbage. My next step will be to try it out on my development database server and see what happens. just-another-data-point-ly y'rs, -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ "We have become ... the stewards of life's continuity on earth. We did not ask for this role... We may not be suited to it, but here we are." - Stephen Jay Gould class fred: def __init__(self): self.indirectFunc = self.theFunc def theFunc(self): return "blah" def test(): f = fred() del f if __name__ == "__main__": import os, time, sys sys.stdout.write("memory usage @ start: ") sys.stdout.flush() os.system("ps auxww | egrep method | egrep -v egrep | awk '{print $5}'") t = time.clock(), time.time() for x in xrange(100000): test() print "clock:", time.clock()-t[0], "elapsed:", time.time()-t[1] sys.stdout.write("memory usage @ end: ") sys.stdout.flush() os.system("ps auxww | egrep method | egrep -v egrep | awk '{print $5}'") From gmcm at hypernet.com Thu Jun 8 16:48:01 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Thu, 8 Jun 2000 10:48:01 -0400 Subject: [Python-Dev] Package Style Guide In-Reply-To: References: <20000608030555.532221CDEF@dinsdale.python.org> Message-ID: <1251646781-15052905@hypernet.com> Andy wrote: > 1. use of __init__ to save users work [package structure] > reportlab > pdfgen > canvas.py defines class Canvas > textobject.py defines class TextObject > pathobject.py defines class PathObject > platypus > (the same problem, but 3x worse) > lib > (loads of modules, all independent) > ---reportlab/pdfgen/__init__.py-------- > from canvas import Canvas > from textobject.py import TextObject > from pathobject.py impory PathObject I would suggest that these not use relative names. from reportlab.pdfgen.canvas import Canvas will ensure that Canvas is only found in one way (no matter where the script is, or rather, what sys.path[0] evaluates to at import time). Your other choice is to disallow any scripts within reportlab/ and deliver 220 V shocks to any user who starts Python anyplace within reportlab/ (or otherwise lets any part of sys.path evaluate to anything within reportlab/). > Then users can just do: > from reportlab.pdfgen import Canvas, PathObject, TextObject > > It seems that this (a) makes life easier for users, and > (b) gives us freedom to refactor code as it grows, without > changing the user interface. Since you're doing this for "convenience", another option is to provide convenience methods: def newCanvas(): return reportlab.pdfgen.canvas.Canvas() > 2. Ambiguities running scripts within package > --------------------------------------------- > Should test scripts all be moved out of the package? > Indeed, is Python behaving the way it ought to? If you use relative imports, yes. But even so, you incur a risk in using relative imports (see above). And you only do it from laziness. So I say don't use relative imports. > 3. Preferred subpackage import technique > ---------------------------------------- > I have two scripts 'spam.py' and 'eggs.py' in > subpackage 'A.B'. spam imports eggs. > Should it say... > import eggs > or... > import A.B.eggs? You know what I'm going to say... - Gordon From mal at lemburg.com Thu Jun 8 16:48:49 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 08 Jun 2000 16:48:49 +0200 Subject: [Python-Dev] revamped Python web site References: <14654.48609.710990.321688@localhost.localdomain> Message-ID: <393FB251.6100175B@lemburg.com> Jeremy Hylton wrote: > > Say a startup company decided to put some resources behind the Python > Web site -- a full-time Web master, some content developers, etc. > What would you have them do? What could be done to open up the site > to the community and make it more responsive to developers and users? > What's your wish list for content, services, etc.? > > If you've got any ideas, please get back to me soon. Why not turn python.org into a Python portal site with all the jazz that goes with it, e.g. newsletters, browsable news forums for different news aspects (business news, new developments, press references, Python related meetings, etc.), customization of the information layout, email notification when things change, chat forums, a Python knowledge base, etc. etc. The reasoning is that Python is starting to go business and the site should reflect this move. As more companies start producing Python tools, I think it might even be worthwhile considering Python related marketing on the Python site, e.g. small banners, external links, etc. This would help finance the site and its administrators. As far as content goes, I think Python.org is hardly beatable :-) What's missing is some more service to push its fun factor which in return pushes Python's acceptance. Anyway, just a thought... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Thu Jun 8 16:54:01 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 08 Jun 2000 16:54:01 +0200 Subject: [Python-Dev] Package ambiguities References: <393eb52b.47053339@post.demon.co.uk> <1251707300-11412775@hypernet.com> <14654.51045.18807.74677@localhost.localdomain> Message-ID: <393FB389.893D20E3@lemburg.com> Jeremy Hylton wrote: > > Gordon's comments are on the money. An import in a module inside a > package should be fully qualified. I'd put that in the style guide if > it were up to me (and, of course, it's not). +1 from here :-) I usually write things like this: from mx.DateTime import now print 'The time is', now() If you don't do so, you'll run into strange problems, the most subtle one I've encountered is with pickled objects... if unpickled inside the same package they can cause the same module to be loaded *twice* with all the consequences attached to this (e.g. issubclass() no longer works). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Thu Jun 8 17:20:23 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 08 Jun 2000 17:20:23 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Objects unicodeobject.c,2.21,2.22 References: <200006070913.CAA18060@slayer.i.sourceforge.net> <20000607193537.Q3348@lyra.org> Message-ID: <393FB9B7.B93A7C61@lemburg.com> Greg Stein wrote: > > On Wed, Jun 07, 2000 at 02:13:24AM -0700, Marc-Andre Lemburg wrote: > > Update of /cvsroot/python/python/dist/src/Objects > > In directory slayer.i.sourceforge.net:/tmp/cvs-serv17917/Objects > > > > Modified Files: > > unicodeobject.c > > Log Message: > > Marc-Andre Lemburg : > > Change the default encoding to 'ascii' (it was previously > > defined as UTF-8). > > > > Note: The implementation still uses UTF-8 to implement > > the buffer protocol, so C APIs will still see UTF-8. This > > is on purpose: rather than fixing the Unicode implementation, > > the C APIs should be made Unicode aware. > > I'm a little confused on where this gets applied. Is this when somebody says > "str(unicode_ob)", they get back ASCII rather than UTF-8? Or is this when > somebody says "unicode(str)" and we expect to be ASCII? The buffer protocol is used for "s", "t" and "s#" argument parsing in C. Since these pass back pointers to internal buffers of the object which must be kept alive until the object is GCed, there's no easy way to change the encoding of that buffer. To play safe I left that buffer encoded in UTF-8 (the hash value is also computed from the UTF-8 encoding of the unicode value to make it compatible to ASCII 8-bit strings). Note that both str(unicode) and unicode(str) will use the default encoding. %-formatting and comparisons also use the default encoding. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Thu Jun 8 17:08:45 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 08 Jun 2000 17:08:45 +0200 Subject: [Python-Dev] Idea: emulating _locale References: <393E2304.4BE8CDE0@lemburg.com> <20000607193014.P3348@lyra.org> Message-ID: <393FB6FD.AB0124E2@lemburg.com> Greg Stein wrote: > > On Wed, Jun 07, 2000 at 12:25:08PM +0200, M.-A. Lemburg wrote: > >... > > Peter Funk wrote: > >... > > > > + ### C lib locale APIs > > > > + > > > > + from _locale import * > > > > > > Wouldn't it be clever to provide some dummy stubs on those platforms, where > > > the _locale module was not enabled? > > > > > > try: > > > from _locale import * > > > except: > > > def setlocale(.... > > > def localeconv(.... > > > ... > > > > > > Especially the MacOS 1.5.2 release provided by Jack Jansen was > > > compiled without '_locale'. And at least in Python 1.6a2 '_locale' > > > is still disabled per default in 'Modules/Setup.in'. I didn't had > > > a look into the current CVS though, so this may have changed. > > > > > > I think the name aliasing tables might be also useful on those > > > systems lacking locale support in their C-library. > > > > setlocale and localeconv are ANSI C and Python requires an ANSI C > > compiler, so there should be no problem (at least in theory). > > > > If there is a problem, adding the missing symbols would > > be no problem: the APIs could always report locale 'C' > > and its numeric settings. > > An ANSI C compiler and the ANSI C library are very different. Just because > Python requires an ANSI compiler (or close to it), does NOT mean that we can > or should depend upon particular elements in the library. Well, ok, it's POSIX.1 too, but... > IMO, we should follow Peter's advice and have stubs for the platforms where > _locale is not built. ...ok, since it doesn't hurt, I'll add some dummies to locale.py which return the same thing as the 'C' locale. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From pingster at ilm.com Thu Jun 8 19:10:46 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Thu, 8 Jun 2000 10:10:46 -0700 (PDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils/command sdist.py,1.25,1.26 In-Reply-To: <20000607200624.R3348@lyra.org> Message-ID: On Wed, 7 Jun 2000, Greg Stein wrote: > Gah... "pattern_re.match (cur_base)" ... > > You do realize that God intended there to be no spaces between a function > name and the opening paren? Heretic! [...] > Put another way: when > you skim code, NAME( is a function call and NAME ( is something else. A > space after a name usually indicates the name is participating in an > expression, rather than being used as a function name. Yesyesyes! This is an absolute rule for me (in other languages too: in C, for example, *always* a space between "if" or "for" and the open-paren). I colourize based on this. It's great -- the one green word on the line stands out; it's the verb, and that lets me know what's going on at a quick glance. (My "Principle of Syntax Highlighting" is to highlight not by what things are, but by what *role* they play. Defining occurrence of anything is a biggie. Comments and docstrings are coloured alike; docstrings are not data. And so on.) -- ?!ng From klm at digicool.com Thu Jun 8 20:38:32 2000 From: klm at digicool.com (Ken Manheimer) Date: Thu, 8 Jun 2000 14:38:32 -0400 (EDT) Subject: [Python-Dev] revamped Python web site In-Reply-To: <14654.48609.710990.321688@localhost.localdomain> Message-ID: On Wed, 7 Jun 2000, Jeremy Hylton wrote: > Say a startup company decided to put some resources behind the Python > Web site -- a full-time Web master, some content developers, etc. > What would you have them do? What could be done to open up the site > to the community and make it more responsive to developers and users? > What's your wish list for content, services, etc.? > > If you've got any ideas, please get back to me soon. Here's some suggestions - i put things more important to me closer to the top, more or less. 1. Delegation of sections to individuals or groups. Eg: - topic guides - particular people get management of areas. (Of course, i'd do this with zope, including zwiki pages as well as regular zope documents for the respective topic-guide managers to use in constructing their content - and for delegating or openning up portions of *their* sections to others...) - The humor page (i'm sad to see that languishing) - Other incidental stuff in the Documentation section of the current site 2. Community-contributed news and hints - portal-style membership/ contribution of news items, reviewed for release or rejection (maybe with community-based reviewers voting) 3. Vaults of parnassus already does this, but i'll still mention - Contributed software/docs/etc - managed similar to moderated news postings, but with classification/cataloguing of artifacts, ability for people to vote on desirability for ranking purposes 5. Jobs board - job postings possibly also managed with news-style reviewing process 6. Subscription to pages, to get notifcations when they change (probably batched, so people don't get too many as something is undergoing development). 7. Discussion "area" for coordinating and collecting logs of IRC-style chats when hot-topics arise that need rendezvous. 8. Open community wiki(s) for growing interesting little worlds (and with my new zwiki nesting-organization features, it may not be too chaotic). Ken klm at digicool.com From gvwilson at nevex.com Thu Jun 8 20:45:37 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Thu, 8 Jun 2000 14:45:37 -0400 (EDT) Subject: [Python-Dev] revamped Python web site In-Reply-To: Message-ID: > Ken Manheimer said > 3. Vaults of parnassus already does this, but i'll still mention - > Contributed software/docs/etc - managed similar to moderated news > postings, but with classification/cataloguing of artifacts, ability for > people to vote on desirability for ranking purposes I'd like to see the Vaults, Starship, and other sub-sites folded into, or become subsections of, a larger Python site, so that I've got the same kind of one-stop shopping that CPAN gives me. Thanks, Greg From esr at thyrsus.com Thu Jun 8 20:54:45 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 8 Jun 2000 14:54:45 -0400 Subject: [Python-Dev] revamped Python web site In-Reply-To: ; from gvwilson@nevex.com on Thu, Jun 08, 2000 at 02:45:37PM -0400 References: Message-ID: <20000608145445.A10500@thyrsus.com> Greg Wilson : > > Ken Manheimer said > > 3. Vaults of parnassus already does this, but i'll still mention - > > Contributed software/docs/etc - managed similar to moderated news > > postings, but with classification/cataloguing of artifacts, ability for > > people to vote on desirability for ranking purposes > > I'd like to see the Vaults, Starship, and other sub-sites folded into, or > become subsections of, a larger Python site, so that I've got the same > kind of one-stop shopping that CPAN gives me. Second that. -- Eric S. Raymond Such are a well regulated militia, composed of the freeholders, citizen and husbandman, who take up arms to preserve their property, as individuals, and their rights as freemen. -- "M.T. Cicero", in a newspaper letter of 1788 touching the "militia" referred to in the Second Amendment to the Constitution. From gmcm at hypernet.com Thu Jun 8 20:57:51 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Thu, 8 Jun 2000 14:57:51 -0400 Subject: [Python-Dev] revamped Python web site In-Reply-To: References: <14654.48609.710990.321688@localhost.localdomain> Message-ID: <1251631791-15954519@hypernet.com> From fdrake at beopen.com Thu Jun 8 21:46:00 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 8 Jun 2000 15:46:00 -0400 (EDT) Subject: [Python-Dev] revamped Python web site In-Reply-To: <20000608085351.A9299@thyrsus.com> References: <20000607174148.A6801@thyrsus.com> <200006081027.MAA02445@python.inrialpes.fr> <14655.37744.352128.72841@cj42289-a.reston1.va.home.com> <20000608085351.A9299@thyrsus.com> Message-ID: <14655.63480.384525.129125@cj42289-a.reston1.va.home.com> Eric S. Raymond writes: > Go check out the PNG site's census of PNG support in "legacy" > browsers. Basically, as long as your PNGs don't use transparency or > animation, you're fine. You've already had the good taste to eschew Excellent! I'll review the list next week probably. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From jeremy at beopen.com Thu Jun 8 22:24:51 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 8 Jun 2000 16:24:51 -0400 (EDT) Subject: [Python-Dev] revamped Python web site In-Reply-To: <1251631791-15954519@hypernet.com> References: <14654.48609.710990.321688@localhost.localdomain> <1251631791-15954519@hypernet.com> Message-ID: <14656.275.83488.186898@localhost.localdomain> >>>>> "GM" == Gordon McMillan writes: >> From Ken Manheimer's Python web site wishlist: - The humor page >> (i'm sad to see that languishing) GM> A weekly nude Tim Peters jpeg! We were going to keep those on the pythonlabs.com internal site, but if Tim doesn't object... Jeremy From jeremy at beopen.com Thu Jun 8 23:19:49 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 8 Jun 2000 17:19:49 -0400 (EDT) Subject: [Python-Dev] impact of cycle gc... In-Reply-To: <200006081408.JAA03136@beluga.mojam.com> References: <200006081408.JAA03136@beluga.mojam.com> Message-ID: <14656.3573.754658.791617@localhost.localdomain> Skip, I don't have time today to look at your post in detail, but one thing you said rtiggered a pretty immediate response: We should worry more about the GC performance on examples like the one you posted, and less about pystone. pystone is a good benchmark for testing the overhead in cases when the garbage collector isn't invoked. There's so little memory allocation that nothing interesting happens. The GC patch ought to have no effect in this case. I suppose 4% is okay. The worry is about programs that allocate a lot of objects, even if they never create circular references. The compiler test is one example, because the parser tree consumes an enormous number of tuples and objects. I suspect big slowdowns like the one you posted just mean we don't know how to adjust the tuneable parameters. Jeremy From gstein at lyra.org Fri Jun 9 02:01:08 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 8 Jun 2000 17:01:08 -0700 Subject: [Python-Dev] revamped Python web site In-Reply-To: ; from gvwilson@nevex.com on Thu, Jun 08, 2000 at 02:45:37PM -0400 References: Message-ID: <20000608170108.B16880@lyra.org> On Thu, Jun 08, 2000 at 02:45:37PM -0400, Greg Wilson wrote: > > Ken Manheimer said > > 3. Vaults of parnassus already does this, but i'll still mention - > > Contributed software/docs/etc - managed similar to moderated news > > postings, but with classification/cataloguing of artifacts, ability for > > people to vote on desirability for ranking purposes > > I'd like to see the Vaults, Starship, and other sub-sites folded into, or > become subsections of, a larger Python site, so that I've got the same > kind of one-stop shopping that CPAN gives me. +1 on that! If python.org opens up (beyond what was possible w.r.t CNRI's security policy), then I see a lot of the impetus for separate sites, such as Starship and Parnassus, simply disappearing. While we're at it: Python-URL has some funny location that I can't ever remember. Providing a way for the organizers to publish those onto python.org (and maintain the archive there) would be good. If /F is still doing the daily URL, then it could go there, too... Cheers, -g -- Greg Stein, http://www.lyra.org/ From nascheme at enme.ucalgary.ca Fri Jun 9 03:29:00 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Thu, 8 Jun 2000 19:29:00 -0600 Subject: [Python-Dev] impact of cycle gc... Message-ID: <20000608192900.A21668@acs.ucalgary.ca> Just a few points and then I will get off python-dev. :) First of all, I don't think it is very meaningful to use leaking applications to do timing comparisons. The collector has be quite careful when freeing structures containing reference cycles. However, using something other than pystone is definitely a good idea. Here the pybench results for the latest patch: PYBENCH 0.6 Benchmark: b_nogc (rounds=4, warp=30) Tests: per run per oper. diff * ------------------------------------------------------------------------ BuiltinFunctionCalls: 286.25 ms 3.37 us -4.22% BuiltinMethodLookup: 367.50 ms 1.05 us -4.55% ConcatStrings: 368.37 ms 3.68 us +42.50% CreateInstances: 477.87 ms 17.07 us -4.45% CreateStringsWithConcat: 322.12 ms 2.42 us +10.27% DictCreation: 382.75 ms 3.83 us +1.29% ForLoops: 536.88 ms 80.73 us +0.99% IfThenElse: 432.75 ms 0.96 us -3.21% ListSlicing: 236.87 ms 104.12 us +11.73% NestedForLoops: 320.00 ms 1.28 us +0.16% NormalClassAttribute: 386.50 ms 0.97 us +0.00% PythonFunctionCalls: 477.87 ms 4.34 us -3.51% PythonMethodCalls: 379.12 ms 7.59 us -12.67% Recursion: 280.75 ms 33.70 us -0.88% SecondImport: 206.62 ms 12.41 us -5.76% SecondPackageImport: 216.75 ms 13.02 us -4.41% SecondSubmoduleImport: 279.25 ms 16.77 us -2.57% SimpleComplexArithmetic: 351.00 ms 2.39 us +0.72% SimpleDictManipulation: 320.75 ms 1.60 us -2.99% SimpleFloatArithmetic: 361.50 ms 0.99 us -20.37% SimpleIntFloatArithmetic: 336.00 ms 0.76 us +0.04% SimpleIntegerArithmetic: 328.38 ms 0.75 us -0.76% SimpleListManipulation: 312.88 ms 1.74 us -1.61% SimpleLongArithmetic: 308.75 ms 2.81 us +9.88% SmallLists: 470.13 ms 2.77 us -5.05% SmallTuples: 374.62 ms 2.34 us -15.74% SpecialClassAttribute: 384.00 ms 0.96 us -1.88% SpecialInstanceAttribute: 446.38 ms 1.12 us -2.75% StringSlicing: 315.50 ms 2.70 us +16.58% TryExcept: 585.37 ms 0.59 us -1.70% TryRaiseExcept: 312.75 ms 31.28 us -5.30% TupleSlicing: 299.38 ms 4.39 us +12.18% ------------------------------------------------------------------------ Average round time: 13615.00 ms -1.13% My AMD-K6-II processor is a pretty quirky beast so I don't think you can conclude too much for those results. Here are the median timings from running Jeremy's compiler on its own source: $ time python compile.py `find . -name '*.py'` Python 1.6 without GC: real 0m16.926s user 0m16.810s sys 0m0.110s Python 1.6 with GC: real 0m21.593s user 0m21.470s sys 0m0.080s Python 1.6 with GC, collection disabled (ie. gc.set_threshold(0)): real 0m18.441s user 0m18.220s sys 0m0.220s We can tune the collection frequency all we want but we won't do any better than the last numbers. Those numbers reflect the cost of keeping track of the objects and the increase in object size. On a related note, I would like to cleanup the PyGC_{NEW, VAR_NEW} macros but I can't figure out a way to transform this code into a macro: op = PyObject_MALLOC(sizeof(PyGCInfo) + _PyObject_SIZE(tp)); if (op) op = PyGC_OBJ((PyGCInfo *)op); If C's || operator was like the Python or I could do something like: #define PyGC_OBJ_SAFE(g) ((PyGCInfo *)(((g) || -1) + 1)) Any ideas? Using an inline function in the header file would be nice but of course it is not portable. GCC has statement expressions but again they are not portable. Neil From Vladimir.Marangozov at inrialpes.fr Fri Jun 9 04:03:59 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Fri, 9 Jun 2000 04:03:59 +0200 (CEST) Subject: [Python-Dev] impact of cycle gc... In-Reply-To: <20000608192900.A21668@acs.ucalgary.ca> from "Neil Schemenauer" at Jun 08, 2000 07:29:00 PM Message-ID: <200006090204.EAA11518@python.inrialpes.fr> Neil Schemenauer wrote: > > On a related note, I would like to cleanup the PyGC_{NEW, > VAR_NEW} macros but I can't figure out a way to transform this > code into a macro: > > op = PyObject_MALLOC(sizeof(PyGCInfo) + _PyObject_SIZE(tp)); > if (op) > op = PyGC_OBJ((PyGCInfo *)op); The correct thing to do, IMO, is to reflect the sizeof(PyGCInfo) mem increment in the tp_basicsize slot of the type object. Thus, we can reuse the current PyObject_New/NEW code, which boils down to PyObject_MALLOC(_PyObject_SIZE(tp)). There is no need for PyGC_NEW/NEW_VAR. This would imply some additional changes to PyObject_Init when the GC_FLAG is set for a given typeobj. I had a closer look at the patch today. It looks good, but I think it needs some more work for a smooth integration with the existing APIs. There's room for optimisations (there are lots of function calls in there, so I am not surprised about the performance hit), but they'll come later on, once the big chunks of the patch fit in their places. One thing that bothered me is that the current gc object allocation code won't fly with C++, where the object storage is allocated (and its size is computed) automatically. There is no PyObject_New, and a C++ object constructor is supposed to begin with PyObject_Init. Another thing is the function names: PyGC_NEW, PyGC_Info, PyGC_Insert, etc. It would be better if they reflect the fact that we're talking about GC on PyObjects, and not about GC in general (on arbitrary mem chunks). I would suggest renaming them along these lines: PyGC_Info -> PyGC_ObjectHead PyGC_Insert -> PyGC_ObjectInit PyGC_Remove -> PyGC_ObjectFini ... All this needs some more thought though... -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From mal at lemburg.com Fri Jun 9 13:03:56 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 09 Jun 2000 13:03:56 +0200 Subject: [Python-Dev] Japanese Codecs Message-ID: <3940CF1C.2C625624@lemburg.com> Python currently supports lots of different code pages and other more specific codecs. I was wondering what your thoughts on this are: should we proceed to include an even wider range of codecs or limit the available number to an absolute minimum ? I'm asking this, because Tamito KAJIYAMA wrote a set of codecs for EUC-JP and Shift_JIS which would probably be very useful for Japanese Python users -- I just don't know how many there are and whether inclusion of an extra 650k of source code would hurt or not. Thoughts ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From akuchlin at cnri.reston.va.us Fri Jun 9 17:08:46 2000 From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling) Date: Fri, 9 Jun 2000 11:08:46 -0400 Subject: [Python-Dev] Japanese Codecs In-Reply-To: <3940CF1C.2C625624@lemburg.com>; from mal@lemburg.com on Fri, Jun 09, 2000 at 01:03:56PM +0200 References: <3940CF1C.2C625624@lemburg.com> Message-ID: <20000609110846.C10688@amarok.cnri.reston.va.us> On Fri, Jun 09, 2000 at 01:03:56PM +0200, M.-A. Lemburg wrote: >I'm asking this, because Tamito KAJIYAMA wrote a set of >codecs for EUC-JP and Shift_JIS which would probably >be very useful for Japanese Python users -- I just don't >know how many there are and whether inclusion of an extra >650k of source code would hurt or not. This seems too much code added that would only be of use to a limited audience, so -1 from me. Japanese packagers of Python would probably include them, of course. -- A.M. Kuchling http://starship.python.net/crew/amk/ I confidently expect it to be a fairly resounding failure. -- John Cleese, on the Monty Python reunion planned for 1999 From skip at mojam.com Fri Jun 9 17:19:59 2000 From: skip at mojam.com (Skip Montanaro) Date: Fri, 9 Jun 2000 10:19:59 -0500 (CDT) Subject: [Python-Dev] impact of cycle gc... In-Reply-To: <14656.3573.754658.791617@localhost.localdomain> References: <200006081408.JAA03136@beluga.mojam.com> <14656.3573.754658.791617@localhost.localdomain> Message-ID: <14657.2847.914770.368965@beluga.mojam.com> Jeremy> I don't have time today to look at your post in detail, but one Jeremy> thing you said rtiggered a pretty immediate response: We should Jeremy> worry more about the GC performance on examples like the one you Jeremy> posted, and less about pystone. I wasn't really worried about pystone, just looking for something quick that didn't generate cycles... ;-) Your suggestion is an excellent one. To try and account for the typical case, I modified the test slightly. I added a new class, ethyl: def foo(): pass class ethyl: def __init__(self): self.indirectFunc = foo def theFunc(self): return "blah" which performs essentially the same work at instantiation time as fred, but doesn't create a cycle. The time (in seconds) to create and delete 100,000 freds and ethyls with and without cycle-gc enabled looks like (last of six consecutive runs): ./python ./python-cycle-gc fred (cycle) 1.4 2.51 ethyl (no cycle) 1.39 1.55 The memory consumption is as you would expect - leaky when creating fred's without using cycle-gc, stable otherwise. So, the penalty for creating and deleting objects that don't contain cycles would appear to be reasonable (about 10-15%). As more experience is gained with it, I imagine it can be reduced further. Skip From mal at lemburg.com Fri Jun 9 17:32:41 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 09 Jun 2000 17:32:41 +0200 Subject: [Python-Dev] Japanese Codecs References: <3940CF1C.2C625624@lemburg.com> <20000609110846.C10688@amarok.cnri.reston.va.us> Message-ID: <39410E19.4E4B1EE7@lemburg.com> "Andrew M. Kuchling" wrote: > > On Fri, Jun 09, 2000 at 01:03:56PM +0200, M.-A. Lemburg wrote: > >I'm asking this, because Tamito KAJIYAMA wrote a set of > >codecs for EUC-JP and Shift_JIS which would probably > >be very useful for Japanese Python users -- I just don't > >know how many there are and whether inclusion of an extra > >650k of source code would hurt or not. > > This seems too much code added that would only be of use to a limited > audience, so -1 from me. Japanese packagers of Python would probably > include them, of course. I just wish that these packagers actually become a reality some day... the concept is good, but there currently seem to be no volunteers or companies jumping in :-( -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From DavidA at ActiveState.com Fri Jun 9 20:54:03 2000 From: DavidA at ActiveState.com (David Ascher) Date: Fri, 9 Jun 2000 11:54:03 -0700 Subject: [Python-Dev] Japanese Codecs In-Reply-To: <39410E19.4E4B1EE7@lemburg.com> Message-ID: > I just wish that these packagers actually become a reality > some day... the concept is good, but there currently seem to > be no volunteers or companies jumping in :-( I can't speak for Japanese packagers, but ActiveState will be packaging Python in various ways. --david From klm at digicool.com Fri Jun 9 20:59:26 2000 From: klm at digicool.com (Ken Manheimer) Date: Fri, 9 Jun 2000 14:59:26 -0400 (EDT) Subject: [Python-Dev] revamped Python web site In-Reply-To: <14656.275.83488.186898@localhost.localdomain> Message-ID: On Thu, 8 Jun 2000, Jeremy Hylton wrote: > >>>>> "GM" == Gordon McMillan writes: > > >> From Ken Manheimer's Python web site wishlist: - The humor page > >> (i'm sad to see that languishing) > > GM> A weekly nude Tim Peters jpeg! > > We were going to keep those on the pythonlabs.com internal site, but > if Tim doesn't object... Anything for a buck, ay, now that you're in the commercial world?-) Ken klm at digicool.com From tim_one at email.msn.com Fri Jun 9 21:11:42 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 9 Jun 2000 15:11:42 -0400 Subject: [Python-Dev] revamped Python web site In-Reply-To: Message-ID: <000c01bfd246$8c02ca40$a12d153f@tim> [KenM] > - The humor page (i'm sad to see that languishing) [Gordon, as always, guides our youth] > A weekly nude Tim Peters jpeg! [JeremyH] > We were going to keep those on the pythonlabs.com internal site, but > if Tim doesn't object... [KenM] > Anything for a buck, ay, now that you're in the commercial world?-) After one of my recent "going away" parties here (I "get to" move to VA next week), a group of old chums were sitting around the restaurant table, belching up bad Italian cooking and speculating on our places in God's Inscrutable Plan. When it came time to pick on me, one naturally pugnacious fellow-- emboldened beyond his normal aggression by wine --looked me straight in the eye and demanded to know if there's *anything* I wouldn't do for money. Well, in point of fact I believe there are a great many such things, but in the moment God only inspired me with one, and so I heard myself retorting: "Ya, sure, I'd fuck a dog for science ... but I wouldn't take a job at Microsoft!". strangely-enough-i-think-that's-backwards-ly y'rs - tim From moshez at math.huji.ac.il Fri Jun 9 21:20:17 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Fri, 9 Jun 2000 22:20:17 +0300 (IDT) Subject: [Python-Dev] revamped Python web site In-Reply-To: <000c01bfd246$8c02ca40$a12d153f@tim> Message-ID: On Fri, 9 Jun 2000, Tim Peters wrote: > In the moment God only inspired me with one, and so I heard > myself retorting: "Ya, sure, I'd fuck a dog for science ... but I wouldn't > take a job at Microsoft!". > > strangely-enough-i-think-that's-backwards-ly y'rs - tim Backwards? You mean you'd fuck Microsoft for science but wouldn't take a job at a dog? Or you'd fuck a dog for Microsoft but wouldn't take a job at science? Or you'd take a job for science, but wouldn't fuck at Microsoft? misunderstanding-tim-seems-to-be-a-common-pass-time-around-here-ly y'rs, Z -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com Return-Path: Delivered-To: python-dev at python.org Received: from math.ma.huji.ac.il (ma.huji.ac.il [132.64.32.5]) by dinsdale.python.org (Postfix) with ESMTP id C19A61CD28; Fri, 9 Jun 2000 14:37:53 -0400 (EDT) Received: from localhost (moshez at localhost) by math.ma.huji.ac.il (8.9.1b+Sun/8.9.3) with ESMTP id VAA28640; Fri, 9 Jun 2000 21:37:03 +0300 (IDT) Date: Fri, 9 Jun 2000 21:37:03 +0300 (IDT) From: Moshe Zadka X-Sender: moshez at sundial Reply-To: Moshe Zadka To: perl_monkey at my-deja.com Cc: python-list at python.org, s2mdalle at titan.vcu.edu In-Reply-To: <8hrbph$a4n$1 at nnrp1.deja.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Python-Dev] Re: Porting CPython Sender: python-dev-admin at python.org Errors-To: python-dev-admin at python.org X-BeenThere: python-dev at python.org X-Mailman-Version: 2.0beta3 Precedence: bulk List-Id: Python core developers Not a lot I can help you with, but: On Fri, 9 Jun 2000 perl_monkey at my-deja.com wrote: > - Excluding Modules > > What is the build procedure for omitting certain built in C modules? > (I"m talking about the stuff in Modules/) Edit the "Setup.in" file. Instructions for how are inside the file, but if you have any more specific questions, please ask again. > Any help on any of these issues would be appreciated. Also, when/if I > finish this, I'd be willing to diff the source and put it into the main > python branch if that's something people would be interested in. I'm CCing Python-Dev on this, so hopefully someone from the BeOpen team can respond. I can just say I'm for it. (Python-dev is on BCC so replies to this won't automatically go there.) -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com From jeremy at beopen.com Fri Jun 9 23:00:09 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 9 Jun 2000 17:00:09 -0400 (EDT) Subject: [Python-Dev] Japanese Codecs In-Reply-To: References: <39410E19.4E4B1EE7@lemburg.com> Message-ID: <14657.23257.478479.141319@localhost.localdomain> >>>>> "DA" == David Ascher writes: >> I just wish that these packagers actually become a reality some >> day... the concept is good, but there currently seem to be no >> volunteers or companies jumping in :-( DA> I can't speak for Japanese packagers, but ActiveState will be DA> packaging Python in various ways. BeOpen also has packaging plans :-). Jeremy From mal at lemburg.com Fri Jun 9 23:49:37 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 09 Jun 2000 23:49:37 +0200 Subject: [Python-Dev] Japanese Codecs References: <39410E19.4E4B1EE7@lemburg.com> <14657.23257.478479.141319@localhost.localdomain> Message-ID: <39416671.AF78100F@lemburg.com> Jeremy Hylton wrote: > > >>>>> "DA" == David Ascher writes: > > >> I just wish that these packagers actually become a reality some > >> day... the concept is good, but there currently seem to be no > >> volunteers or companies jumping in :-( > > DA> I can't speak for Japanese packagers, but ActiveState will be > DA> packaging Python in various ways. > > BeOpen also has packaging plans :-). Sounds cool. I just hope that someone will hint me of the first Python IPO *before* it hits NASDAQ ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From effbot at telia.com Fri Jun 9 23:59:18 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 9 Jun 2000 23:59:18 +0200 Subject: [Python-Dev] Japanese Codecs References: <39410E19.4E4B1EE7@lemburg.com> <14657.23257.478479.141319@localhost.localdomain> Message-ID: <001101bfd25d$f6a0fb80$f2a6b5d4@hagrid> > I can't speak for Japanese packagers, but ActiveState will be > packaging Python in various ways. > > BeOpen also has packaging plans :-). get in line, guys ;-) From esr at thyrsus.com Sat Jun 10 00:19:24 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 9 Jun 2000 18:19:24 -0400 Subject: [Python-Dev] RFC: Including PIL in 1.6 In-Reply-To: <20000609215719.47624E2673@oratrix.oratrix.nl>; from jack@oratrix.nl on Fri, Jun 09, 2000 at 11:57:14PM +0200 References: <20000609215719.47624E2673@oratrix.oratrix.nl> Message-ID: <20000609181924.A15728@thyrsus.com> Jack Jansen : > I include PIL in the standard MacPython and Mac users are apparently > very happy with that [...] I think it's time to consider including PIL in the core Python 1.6 release. I've been following the work being done over there, and I believe the code has reached a sufficient level of maturity to justify this. The "Batteries are included" philosophy seems to me to imply that we ought to be looking for application libraries to promote into the core once we're satisfied that they meet core-Pythonic standards of good API design, stability, general usefulness, and documentation quality. PIL seems to me like a good candidate on all counts. Guido has to make the final call, of course. But let's have the discussion now so we can develop a yea or nay consensus on ther list. -- Eric S. Raymond Society in every state is a blessing, but government even in its best state is but a necessary evil; in its worst state an intolerable one; for when we suffer, or are exposed to the same miseries *by a government*, which we might expect in a country *without government*, our calamities is heightened by reflecting that we furnish the means by which we suffer." -- Thomas Paine From pingster at ilm.com Sat Jun 10 00:28:27 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Fri, 9 Jun 2000 15:28:27 -0700 (PDT) Subject: [Python-Dev] RFC: Including PIL in 1.6 In-Reply-To: <20000609181924.A15728@thyrsus.com> Message-ID: On Fri, 9 Jun 2000, Eric S. Raymond wrote: > Jack Jansen : > > I include PIL in the standard MacPython and Mac users are apparently > > very happy with that [...] > > I think it's time to consider including PIL in the core Python 1.6 release. > I've been following the work being done over there, and I believe the > code has reached a sufficient level of maturity to justify this. I'm +0. Well, perhaps +0.1. I guess what i would really be "+" about is something to the effect of "a popular Linux distribution decides to throw in the .so for PIL". Then it wouldn't really matter to me whether it was in the "real" standard distribution. -- ?!ng "The police are not here to create disorder. They're here to preserve disorder." -- Former Chicago mayor Daley From akuchlin at cnri.reston.va.us Sat Jun 10 03:52:23 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Fri, 9 Jun 2000 21:52:23 -0400 Subject: [Python-Dev] Re: [Image-SIG] RFC: Including PIL in 1.6 In-Reply-To: <20000609181924.A15728@thyrsus.com>; from esr@thyrsus.com on Fri, Jun 09, 2000 at 06:19:24PM -0400 References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> Message-ID: <20000609215223.A23230@newcnri.cnri.reston.va.us> On Fri, Jun 09, 2000 at 06:19:24PM -0400, Eric S. Raymond wrote: >I think it's time to consider including PIL in the core Python 1.6 release. -1 unless Fredrik says there's a C and Python API for extending PIL that he's happy with, in which case it's +0. I've written a few extensions for PIL and it required a fair amount of grubbing around inside of C structures; it isn't clear that the structures will be the same in future versions of PIL. We don't want to add something that people will extend messily, which will then make fixing the API more difficult because of backward compatibility. (Disclaimer: I haven't looked at PIL 1.1 yet; maybe /F has documented an API, or maybe he's pretty sure the data structures will remain the same.) OTOH, given that the Distutils is making good progress on building RPMs for an arbitrary Python package, installing PIL may get much easier in future, reducing the need to add it to the core. But then Paul always yells at me for that argument. :) -- A.M. Kuchling akuchlin at mems-exchange.org Posting "Please send e-mail, since I don't read this group": Poster is rendered illiterate by a simple trepanation. -- Kibo, in the Happynet Manifesto From akuchlin at cnri.reston.va.us Sat Jun 10 04:50:08 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Fri, 9 Jun 2000 22:50:08 -0400 Subject: [Python-Dev] What's New: 2nd draft Message-ID: <20000609225008.A23369@newcnri.cnri.reston.va.us> We've made a second pass at the "What's New in 1.6" document; the only unwritten section is IDLE, and I don't think either Moshe or I use IDLE. Can anyone tell us what the new features are? Again, suggestions on style, forgotten changes, *anything*, are welcomed: http://starship.python.net/crew/amk/python/writing/new-python/ -- A.M. Kuchling http://starship.python.net/crew/amk/ "How about you -- what're you up to?" "Issue #3." -- Vic and Zot, in ZOT! #3 From moshez at math.huji.ac.il Sat Jun 10 07:29:56 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sat, 10 Jun 2000 08:29:56 +0300 (IDT) Subject: [Python-Dev] Japanese Codecs In-Reply-To: <001101bfd25d$f6a0fb80$f2a6b5d4@hagrid> Message-ID: On Fri, 9 Jun 2000, Fredrik Lundh wrote: > > I can't speak for Japanese packagers, but ActiveState will be > > packaging Python in various ways. > > > > BeOpen also has packaging plans :-). > > get in line, guys ;-) I wonder if next we'll see threads on slashdot about "PythonOne is just trying to get on the Python hype. It has nothing to offer except for a trivial installer anyone can write in 5 minutes in Python" (cf: the LinuxOne fiasco) -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com From paul at prescod.net Thu Jun 8 23:32:27 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 08 Jun 2000 23:32:27 +0200 Subject: [Python-Dev] [Fwd: Re: Case sensitivity] Message-ID: <394010EB.DBCBC5FD@prescod.net> Here's a good summary of how XML's case sensitivity came to be. -------- Original Message -------- Subject: Re: Case sensitivity Date: Mon, 3 Apr 2000 12:44:37 -0400 From: Steve DeRose To: xml-dev at lists.oasis-open.org References: Languages with no need for case folding are not much of a problem: the case-folding table or program would merely have no effect on characters belonging to such languages: It would change 26 of our 26 alphabetic code points, and no others. After all, in English we already use lots of characters that don't get case-folded (like digits). The serious problems are subtler: The practical problem that with Unicode your folding table gets really big; on the order of 128Kbytes instead of 256 bytes (barring compresson): this is a pain on small devices (like a cell-phone browser), a pain to load, a pain to implement compression for, etc. The theoretical problem is more important: it's not the caseless languages that pose problems, but the complicated case-folding ones. For example, lots of languages only apply diacritical marks to lower-case letters: for example, "a" may come with 6 different accents, but "A" takes none -- which makes case-folding unreversible. If there are languages that operate the other way as well, then neither fold-to-upper nor fold-to-lower can work for all languages: either way would trash some languages. That said, I think it incumbent on XML *search engines* to support case-folding (as well as decent treatment of accents, types of hyphens, etc) for text content searches: Making English speakers search for "the" | "thE" | "tHe" | "tHE" | "The" | "ThE" | "THe" | "THE" or "[tT][hH][eE] is patently absurd; and besides, there is no user cost to (say) a Japanese speaker if an engine *does* case-fold. Also, many languages use Roman characters occasionally, as for acronyms; so their speakers also pay a price if searches aren't smart enough. And the primary problems with case-folding do not weigh so heavily in the search engine world (for example, AltaVista isn't likely to run their main servers on cell phones for a while yet). From esr at thyrsus.com Sat Jun 10 17:42:27 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Sat, 10 Jun 2000 11:42:27 -0400 Subject: [Python-Dev] Suggestion to Windows- and Mac-library people Message-ID: <20000610114227.A19052@thyrsus.com> Last night I sent the following patch for urllib to python-patches: # Support for launching a browser if os.environ.has_key("BROWSER"): _browsers = string.split(os.environ["BROWSER"], ":") else: _browsers = ["mozilla %s &", "netscape -remote 'openURL(%s)'", "netscape %s &", "lynx %s &", "w3m %s &"] def urlbrowse(url): """Launch a browser, in background, pointed at the given URL. Accept either a string or a parsed URL tuple. Interpret the BROWSER environment variable, if it exists, as a colon-separated list of browser commands to try. """ from urlparse import urlunparse if type(url) == (): url = urlunparse(url) for browser in _browsers: if not os.system('which 1>/dev/null 2>&1 '+string.split(browser)[0]): if os.system((browser % url)) == 0: return 1 return 0 Obviously this is not portable off Unix. Equally obviously it should be possible to do an equivalent thing under Windows (at least). For anybody writing interactive programs in this Web-mad era, this function is just too useful not to have in the toolbox. So this is a nudge to any Windows and Mac wizards on this list -- let's make this function available cross-platform. I've also copied this note to Chip Salzenberg. Perl ought to have this capability too -- and I'm sufficiently serious about that to (gasp) code in Perl myself to make it happen if I have to. -- Eric S. Raymond (Those) who are trying to read the Second Amendment out of the Constitution by claiming it's not an individual right (are) courting disaster by encouraging others to use the same means to eliminate portions of the Constitution they don't like. -- Alan Dershowitz, Harvard Law School From akuchlin at cnri.reston.va.us Sat Jun 10 17:42:50 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Sat, 10 Jun 2000 11:42:50 -0400 Subject: [Python-Dev] Creating curses package: OK? In-Reply-To: <20000610113124.B18982@thyrsus.com>; from esr@thyrsus.com on Sat, Jun 10, 2000 at 11:31:24AM -0400 References: <200006100748.DAA17920@snark.thyrsus.com> <20000610111323.A24895@newcnri.cnri.reston.va.us> <20000610113124.B18982@thyrsus.com> Message-ID: <20000610114250.A25014@newcnri.cnri.reston.va.us> [Redirecting a private conversation to python-dev] On Sat, Jun 10, 2000 at 11:31:24AM -0400, Eric S. Raymond wrote: >I found a workaround. The two curses enhancements (traceback wrapper >and text pad) are now working and ready to be integrated into the >1.6 library. How should we proceed? OK; python-dev has discussed creating a curses package, and reaction seemed favorable. So, my plan of action is: 1) Rename cursesmodule.c to _cursesmodule.c. (Barry, can you do a 'mv' inside the SourceForge CVS repository so the complete history of the module doesn't get lost with the renaming?) 2) Create a Lib/curses/ directory; __init__.py does 'from _curses import *'. 3) The traceback wrapper can then be put into __init__.py, since I assume it's fairly small and everyone should use it. The text pad stuff could then go in another module in the curses package. Seem reasonable to everyone? --amk From esr at thyrsus.com Sat Jun 10 18:01:48 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Sat, 10 Jun 2000 12:01:48 -0400 Subject: [Python-Dev] Creating curses package: OK? In-Reply-To: <20000610114250.A25014@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Sat, Jun 10, 2000 at 11:42:50AM -0400 References: <200006100748.DAA17920@snark.thyrsus.com> <20000610111323.A24895@newcnri.cnri.reston.va.us> <20000610113124.B18982@thyrsus.com> <20000610114250.A25014@newcnri.cnri.reston.va.us> Message-ID: <20000610120148.A19168@thyrsus.com> Andrew Kuchling : > OK; python-dev has discussed creating a curses package, and reaction > seemed favorable. So, my plan of action is: > > 1) Rename cursesmodule.c to _cursesmodule.c. (Barry, can you do a 'mv' > inside the SourceForge CVS repository so the complete history of the > module doesn't get lost with the renaming?) > > 2) Create a Lib/curses/ > directory; __init__.py does 'from _curses import *'. > > 3) The traceback wrapper can then be put into __init__.py, since I > assume it's fairly small and everyone should use it. The text pad > stuff could then go in another module in the curses package. > > Seem reasonable to everyone? Works for me. -- Eric S. Raymond We shall not cease from exploration, and the end of all our exploring will be to arrive where we started and know the place for the first time. -- T.S. Eliot From moshez at math.huji.ac.il Sat Jun 10 19:03:51 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sat, 10 Jun 2000 20:03:51 +0300 (IDT) Subject: [Python-Dev] Creating curses package: OK? In-Reply-To: <20000610114250.A25014@newcnri.cnri.reston.va.us> Message-ID: On Sat, 10 Jun 2000, Andrew Kuchling wrote: > OK; python-dev has discussed creating a curses package, and reaction > seemed favorable. So, my plan of action is: > > 1) Rename cursesmodule.c to _cursesmodule.c. (Barry, can you do a 'mv' > inside the SourceForge CVS repository so the complete history of the > module doesn't get lost with the renaming?) > > 2) Create a Lib/curses/ > directory; __init__.py does 'from _curses import *'. > > 3) The traceback wrapper can then be put into __init__.py, since I > assume it's fairly small and everyone should use it. The text pad > stuff could then go in another module in the curses package. > > Seem reasonable to everyone? I'm +1, except for some nagging doubt about the traceback wrapper. Why not put it in its own (small, granted) module? There are no backward compatabilities to worry here, so there shouldn't be any excuse to put code in __init__.py. But it is so small, that I don't really feel strongly about it. i'll-be-+1-on-the-text-pad-stuff-when-you-get-it-ready-eric-ly y'rs, Z. -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com From esr at thyrsus.com Sat Jun 10 19:24:18 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Sat, 10 Jun 2000 13:24:18 -0400 Subject: [Python-Dev] Creating curses package: OK? In-Reply-To: ; from moshez@math.huji.ac.il on Sat, Jun 10, 2000 at 08:03:51PM +0300 References: <20000610114250.A25014@newcnri.cnri.reston.va.us> Message-ID: <20000610132418.A19442@thyrsus.com> Moshe Zadka : > I'm +1, except for some nagging doubt about the traceback wrapper. > Why not put it in its own (small, granted) module? I don't understand. Whuy do you want to do this? > i'll-be-+1-on-the-text-pad-stuff-when-you-get-it-ready-eric-ly y'rs, Z. You can try it out now: # # Curses extensions -- these are expected to be in the 1.6 Python library # import sys, curses, ascii def wrapper(func, *rest): "Wrapper function that restores normal keyboard/screen behavior on error." res = None try: # Initialize curses stdscr=curses.initscr() # Turn off echoing of keys, and enter cbreak mode, # where no buffering is performed on keyboard input curses.noecho() ; curses.cbreak() # In keypad mode, escape sequences for special keys # (like the cursor keys) will be interpreted and # a special value like curses.KEY_LEFT will be returned stdscr.keypad(1) res = apply(func, (stdscr,) + rest) except: # In the event of an error, restore the terminal # to a sane state. stdscr.keypad(0) curses.echo() ; curses.nocbreak() curses.endwin() # Pass the exception upwards (exc_type, exc_value, exc_traceback) = sys.exc_info() raise exc_type, exc_value, exc_traceback else: # Set everything back to normal stdscr.keypad(0) curses.echo() ; curses.nocbreak() curses.endwin() # Terminate curses return res def rectangle(win, uly, ulx, lry, lrx): "Draw a rectangle." win.vline(uly+1, ulx, curses.ACS_VLINE, lry - uly - 1) win.hline(uly, ulx+1, curses.ACS_HLINE, lrx - ulx - 1) win.hline(lry, ulx+1, curses.ACS_HLINE, lrx - ulx - 1) win.vline(uly+1, lrx, curses.ACS_VLINE, lry - uly - 1) win.addch(uly, ulx, curses.ACS_ULCORNER) win.addch(uly, lrx, curses.ACS_URCORNER) win.addch(lry, lrx, curses.ACS_LRCORNER) win.addch(lry, ulx, curses.ACS_LLCORNER) class textbox: """Editing widget using the interior of a window object. Supports the following Emacs-like key bindings: Ctrl-A Go to left edge of window. Ctrl-B Cursor left, wrapping to previous line if appropriate. Ctrl-D Delete character under cursor. Ctrl-E Go to right edge (nospaces off) or end of line (nospaces on). Ctrl-F Cursor right, wrapping to next line when appropriate. Ctrl-G Terminate, returning the window contents. Ctrl-J Terminate if the window is 1 line, otherwise insert newline. Ctrl-K If line is blank, delete it, otherwise clear to end of line. Ctrl-L Refresh screen Ctrl-N Cursor down; move down one line. Ctrl-O Insert a blank line at cursor location. Ctrl-P Cursor up; move up one line. Move operations do nothing if the cursor is at an edge where the movement is not possible. The following synonyms are supported where possible: KEY_LEFT = Ctrl-B, KEY_RIGHT = Ctrl-F, KEY_UP = Ctrl-P, KEY_DOWN = Ctrl-N """ def __init__(self, win): self.win = win (self.maxy, self.maxx) = win.getmaxyx() self.maxy = self.maxy - 1 self.maxx = self.maxx - 1 self.stripspaces = 1 win.keypad(1) def firstblank(self, y): "Go to the location of the first blank on the given line." (oldy, oldx) = self.win.getyx() self.win.move(y, self.maxx-1) last = self.maxx-1 while 1: if last == 0: break if ascii.ascii(self.win.inch(y, last)) != ascii.SP: last = last + 1 break last = last - 1 self.win.move(oldy, oldx) return last def do_command(self, ch): "Process a single editing command." (y, x) = self.win.getyx() if ascii.isprint(ch): if y < self.maxy or x < self.maxx: # The try-catch ignores the error we trigger from some curses # versions by trying to write into the lowest-rightmost spot # in the self.window. try: self.win.addch(ch) except ERR: pass elif ch == ascii.SOH: # Ctrl-a self.win.move(y, 0) elif ch in (ascii.STX, curses.KEY_LEFT): # Ctrl-b if x > 0: self.win.move(y, x-1) elif y == 0: pass elif self.stripspaces: self.win.move(y-1, self.firstblank(y-1)) else: self.win.move(y-1, self.maxx) elif ch == ascii.EOT: # Ctrl-d self.win.delch() elif ch == ascii.ENQ: # Ctrl-e if self.stripspaces: self.win.move(y, self.firstblank(y, maxx)) else: self.win.move(y, self.maxx) elif ch in (ascii.ACK, curses.KEY_RIGHT): # Ctrl-f if x < self.maxx: self.win.move(y, x+1) elif y == self.maxx: pass else: self.win.move(y+1, 0) elif ch == ascii.BEL: # Ctrl-g return 0 elif ch == ascii.NL: # Ctrl-j if self.maxy == 0: return 0 elif y < self.maxy: self.win.move(y+1, 0) elif ch == ascii.VT: # Ctrl-k if x == 0 and self.firstblank(y) == 0: self.win.deleteln() else: self.win.clrtoeol() elif ch == ascii.FF: # Ctrl-l self.win.refresh() elif ch in (ascii.SO, curses.KEY_DOWN): # Ctrl-n if y < self.maxy: self.win.move(y+1, x) elif ch == ascii.SI: # Ctrl-o self.win.insertln() elif ch in (ascii.DLE, curses.KEY_UP): # Ctrl-p if y > 0: self.win.move(y-1, x) self.win.refresh() return 1 def gather(self): "Collect and return the contents of the window." result = "" for y in range(self.maxy+1): self.win.move(y, 0) stop = self.firstblank(y) if stop == 0 and self.stripspaces: continue for x in range(self.maxx+1): if self.stripspaces and x == stop: break result = result + chr(ascii.ascii(self.win.inch(y, x))) if self.maxy > 0: result = result + "\n" return result def edit(self, validate=None): "Edit in the widget window and collect the results." while 1: ch = self.win.getch() if self.validate: ch = validate(ch) if not self.do_command(ch): break return self.gather() if __name__ == '__main__': def test_editbox(stdscr): win = curses.newwin(4, 9, 15, 20) rectangle(stdscr, 14, 19, 19, 29) stdscr.refresh() return textbox(win).edit() str = wrapper(test_editbox) print str -- Eric S. Raymond The danger (where there is any) from armed citizens, is only to the *government*, not to *society*; and as long as they have nothing to revenge in the government (which they cannot have while it is in their own hands) there are many advantages in their being accustomed to the use of arms, and no possible disadvantage. -- Joel Barlow, "Advice to the Privileged Orders", 1792-93 From bwarsaw at python.org Sat Jun 10 19:58:04 2000 From: bwarsaw at python.org (Barry A. Warsaw) Date: Sat, 10 Jun 2000 13:58:04 -0400 (EDT) Subject: [Python-Dev] Creating curses package: OK? References: <200006100748.DAA17920@snark.thyrsus.com> <20000610111323.A24895@newcnri.cnri.reston.va.us> <20000610113124.B18982@thyrsus.com> <20000610114250.A25014@newcnri.cnri.reston.va.us> Message-ID: <14658.33196.426211.329070@anthem.concentric.net> >>>>> "AK" == Andrew Kuchling writes: AK> 1) Rename cursesmodule.c to _cursesmodule.c. (Barry, can you AK> do a 'mv' inside the SourceForge CVS repository so the AK> complete history of the module doesn't get lost with the AK> renaming?) Not easily (IOW, I have to play several rounds of ugly loginfo games which are hard to get right). Best thing to do would be to submit a SF admin request, which I think since you're a developer you can do. -Barry From moshez at math.huji.ac.il Sat Jun 10 22:12:32 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sat, 10 Jun 2000 23:12:32 +0300 (IDT) Subject: [Python-Dev] Creating curses package: OK? In-Reply-To: <20000610132418.A19442@thyrsus.com> Message-ID: [Moshe Zadka] > I'm +1, except for some nagging doubt about the traceback wrapper. > Why not put it in its own (small, granted) module? [Eric S. Raymond] > I don't understand. Why do you want to do this? I have religious beliefs, and I follow them without thinking. Like "HTTP good, FTP bad". "Python good, C++ bad". Or, in that case "Putting real code in __init__.py bad". (I think that should go in the package style guide, BTW) religions-are-bad-of-course-ly y'rs, Z. -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com From esr at thyrsus.com Sat Jun 10 22:24:40 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Sat, 10 Jun 2000 16:24:40 -0400 Subject: [Python-Dev] Creating curses package: OK? In-Reply-To: ; from moshez@math.huji.ac.il on Sat, Jun 10, 2000 at 11:12:32PM +0300 References: <20000610132418.A19442@thyrsus.com> Message-ID: <20000610162440.A19859@thyrsus.com> Moshe Zadka : > [Eric S. Raymond] > > I don't understand. Why do you want to do this? > > I have religious beliefs, and I follow them without thinking. Like > "HTTP good, FTP bad". "Python good, C++ bad". Or, in that case "Putting > real code in __init__.py bad". I'm even more confused now. Why would the traceback wrapper I'm proposing go in __init__.py? -- Eric S. Raymond The Bible is not my book, and Christianity is not my religion. I could never give assent to the long, complicated statements of Christian dogma. -- Abraham Lincoln From moshez at math.huji.ac.il Sat Jun 10 22:21:57 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sat, 10 Jun 2000 23:21:57 +0300 (IDT) Subject: [Python-Dev] Creating curses package: OK? In-Reply-To: <20000610162440.A19859@thyrsus.com> Message-ID: On Sat, 10 Jun 2000, Eric S. Raymond wrote: > I'm even more confused now. Why would the traceback wrapper I'm proposing > go in __init__.py? Maybe I'm confused here. I thought that was what AMK suggested, no? Where would you want it to go? There are currently 3 planned files in the curses package: __init__.py: apparently not textpad.py: why here? it has nothing to do with text pads _curses.so: certainly not here...you don't want to code in C more then you have to I'm proposing: wrapper.py: put it here i-hope-i-managed-to-confuse-everyone-further-ly y'rs, Z. -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com From akuchlin at cnri.reston.va.us Sun Jun 11 00:25:14 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Sat, 10 Jun 2000 18:25:14 -0400 Subject: [Python-Dev] Creating curses package: OK? In-Reply-To: ; from moshez@math.huji.ac.il on Sat, Jun 10, 2000 at 11:21:57PM +0300 References: <20000610162440.A19859@thyrsus.com> Message-ID: <20000610182514.A25949@newcnri.cnri.reston.va.us> On Sat, Jun 10, 2000 at 11:21:57PM +0300, Moshe Zadka wrote: >Maybe I'm confused here. I thought that was what AMK suggested, no? I did in fact suggest that, since the wrapper is small, and we ideally want every Python/curses application using it, so they don't leave the terminal in a wacky state if they raise an exception. But it's not a big deal and could easily go in wrapper.py, though __init__.py might still import it automatically. --amk From esr at thyrsus.com Sun Jun 11 00:38:06 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Sat, 10 Jun 2000 18:38:06 -0400 Subject: [Python-Dev] Creating curses package: OK? In-Reply-To: <20000610182514.A25949@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Sat, Jun 10, 2000 at 06:25:14PM -0400 References: <20000610162440.A19859@thyrsus.com> <20000610182514.A25949@newcnri.cnri.reston.va.us> Message-ID: <20000610183806.A20280@thyrsus.com> Andrew Kuchling : > On Sat, Jun 10, 2000 at 11:21:57PM +0300, Moshe Zadka wrote: > >Maybe I'm confused here. I thought that was what AMK suggested, no? > > I did in fact suggest that, since the wrapper is small, and we ideally > want every Python/curses application using it, so they don't leave the > terminal in a wacky state if they raise an exception. But it's not a > big deal and could easily go in wrapper.py, though __init__.py might > still import it automatically. The traceback wrapper is not the only Python code I'll be supplying... -- Eric S. Raymond I do not find in orthodox Christianity one redeeming feature. -- Thomas Jefferson From gstein at lyra.org Sun Jun 11 00:33:20 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 10 Jun 2000 15:33:20 -0700 Subject: [Python-Dev] Creating curses package: OK? In-Reply-To: <20000610182514.A25949@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Sat, Jun 10, 2000 at 06:25:14PM -0400 References: <20000610162440.A19859@thyrsus.com> <20000610182514.A25949@newcnri.cnri.reston.va.us> Message-ID: <20000610153320.A19484@lyra.org> On Sat, Jun 10, 2000 at 06:25:14PM -0400, Andrew Kuchling wrote: > On Sat, Jun 10, 2000 at 11:21:57PM +0300, Moshe Zadka wrote: > >Maybe I'm confused here. I thought that was what AMK suggested, no? > > I did in fact suggest that, since the wrapper is small, and we ideally > want every Python/curses application using it, so they don't leave the > terminal in a wacky state if they raise an exception. But it's not a > big deal and could easily go in wrapper.py, though __init__.py might > still import it automatically. Yes, I think we'd want it to import the stuff; just organizationally to place the source code outside of __init__.py I'd agree that real code should not go into __init__. It should preload some standard modules, maybe expose some symbols, but otherwise no code. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Sun Jun 11 01:30:13 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 10 Jun 2000 16:30:13 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses __init__.py,NONE,1.1 wrapper.py,NONE,1.1 In-Reply-To: <200006102306.QAA18088@slayer.i.sourceforge.net>; from akuchling@slayer.i.sourceforge.net on Sat, Jun 10, 2000 at 04:06:55PM -0700 References: <200006102306.QAA18088@slayer.i.sourceforge.net> Message-ID: <20000610163013.B19484@lyra.org> On Sat, Jun 10, 2000 at 04:06:55PM -0700, A.M. Kuchling wrote: >... > def wrapper(func, *rest): > """Wrapper function that initializes curses and calls another function, > restoring normal keyboard/screen behavior on error. > The callable object 'func' is then passed the main window 'stdscr' > as its first argument, followed by any other arguments passed to > wrapper(). > """ > > res = None > try: > # Initialize curses > stdscr=curses.initscr() > # Turn off echoing of keys, and enter cbreak mode, > # where no buffering is performed on keyboard input > curses.noecho() ; curses.cbreak() > > # In keypad mode, escape sequences for special keys > # (like the cursor keys) will be interpreted and > # a special value like curses.KEY_LEFT will be returned > stdscr.keypad(1) > > res = apply(func, (stdscr,) + rest) > except: > # In the event of an error, restore the terminal > # to a sane state. > stdscr.keypad(0) > curses.echo() ; curses.nocbreak() > curses.endwin() > # Pass the exception upwards > (exc_type, exc_value, exc_traceback) = sys.exc_info() > raise exc_type, exc_value, exc_traceback > else: > # Set everything back to normal > stdscr.keypad(0) > curses.echo() ; curses.nocbreak() > curses.endwin() # Terminate curses > > return res This is too complicated. It should read: ... return apply(func, (stdscr,) + rest) finally: # Set everything back to normal stdscr.keypad(0) curses.echo() curses.nocbreak() curses.endwin() Andrew: can you make this change? Separate from the above simplification, it is important to note: exc_type, exc_value, exc_traceback = sys.exc_info() raise exc_type, exc_value, exc_traceback and raise are equivalent in (most) function. The difference is that the former places the traceback into local variable storage (exc_traceback) which then introduces a reference loop. Whenever sys.exc_info() is used, it is very important to watch out for loops caused by the traceback object. "del exc_traceback" is very handy :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Sun Jun 11 01:33:05 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 10 Jun 2000 16:33:05 -0700 Subject: [Python-Dev] curses wrapper checkin In-Reply-To: <20000610163013.B19484@lyra.org>; from gstein@lyra.org on Sat, Jun 10, 2000 at 04:30:13PM -0700 References: <200006102306.QAA18088@slayer.i.sourceforge.net> <20000610163013.B19484@lyra.org> Message-ID: <20000610163305.C19484@lyra.org> On Sat, Jun 10, 2000 at 04:30:13PM -0700, Greg Stein wrote: > On Sat, Jun 10, 2000 at 04:06:55PM -0700, A.M. Kuchling wrote: > >... > > def wrapper(func, *rest): > > """Wrapper function that initializes curses and calls another function, > > restoring normal keyboard/screen behavior on error. > > The callable object 'func' is then passed the main window 'stdscr' > > as its first argument, followed by any other arguments passed to > > wrapper(). > > """ > > > > res = None Oh. This line can disappear, too. Cheers, -g -- Greg Stein, http://www.lyra.org/ From akuchlin at cnri.reston.va.us Sun Jun 11 01:33:12 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Sat, 10 Jun 2000 19:33:12 -0400 Subject: [Python-Dev] Creating curses package: done In-Reply-To: <14658.33196.426211.329070@anthem.concentric.net>; from bwarsaw@python.org on Sat, Jun 10, 2000 at 01:58:04PM -0400 References: <200006100748.DAA17920@snark.thyrsus.com> <20000610111323.A24895@newcnri.cnri.reston.va.us> <20000610113124.B18982@thyrsus.com> <20000610114250.A25014@newcnri.cnri.reston.va.us> <14658.33196.426211.329070@anthem.concentric.net> Message-ID: <20000610193312.A26098@newcnri.cnri.reston.va.us> On Sat, Jun 10, 2000 at 01:58:04PM -0400, Barry A. Warsaw wrote: >which are hard to get right). Best thing to do would be to submit a >SF admin request, which I think since you're a developer you can do. I've submitted a support request to rename the file, and checked in the Lib/curses subdirectory, containing only __init__.py and wrapper.py, along with the required Makefile.in and Setup.in changes. If you compile the CVS tree right now, you'll need to rename cursesmodule.c to _cursesmodule.c manually. The textbox stuff poses two problems. First, it requires ascii.py, and wasn't the decision to wait for GvR on adding that module? Second, Eric, I'm not sure what you want as the module name for the textbox stuff: textbox.py? Your call... (I'll check it in, and if ascii.py is vetoed, it can be rewritten to not require ascii.py, or we can have curses.ascii.) --amk From esr at thyrsus.com Sun Jun 11 01:48:22 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Sat, 10 Jun 2000 19:48:22 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses __init__.py,NONE,1.1 wrapper.py,NONE,1.1 In-Reply-To: <20000610163013.B19484@lyra.org>; from gstein@lyra.org on Sat, Jun 10, 2000 at 04:30:13PM -0700 References: <200006102306.QAA18088@slayer.i.sourceforge.net> <20000610163013.B19484@lyra.org> Message-ID: <20000610194822.A882@thyrsus.com> Greg Stein : > This is too complicated. It should read: > > ... > return apply(func, (stdscr,) + rest) > finally: > # Set everything back to normal > stdscr.keypad(0) > curses.echo() > curses.nocbreak() > curses.endwin() > > Andrew: can you make this change? I'll test it and make the change in my masters if it works for both cases. I haven't actually shipped the box of goodies yet... -- Eric S. Raymond Alcohol still kills more people every year than all `illegal' drugs put together, and Prohibition only made it worse. Oppose the War On Some Drugs! From esr at thyrsus.com Sun Jun 11 01:50:27 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Sat, 10 Jun 2000 19:50:27 -0400 Subject: [Python-Dev] Creating curses package: done In-Reply-To: <20000610193312.A26098@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Sat, Jun 10, 2000 at 07:33:12PM -0400 References: <200006100748.DAA17920@snark.thyrsus.com> <20000610111323.A24895@newcnri.cnri.reston.va.us> <20000610113124.B18982@thyrsus.com> <20000610114250.A25014@newcnri.cnri.reston.va.us> <14658.33196.426211.329070@anthem.concentric.net> <20000610193312.A26098@newcnri.cnri.reston.va.us> Message-ID: <20000610195027.B882@thyrsus.com> Andrew Kuchling : > The textbox stuff poses two problems. First, it requires ascii.py, > and wasn't the decision to wait for GvR on adding that module? > Second, Eric, I'm not sure what you want as the module name for the > textbox stuff: textbox.py? Your call... (I'll check it in, and if > ascii.py is vetoed, it can be rewritten to not require ascii.py, or > we can have curses.ascii.) I thought it was going to become part of curses from the user's point of view, so that "import curses" brings it in. That seemed to be the intent of the request at the end of the curses HOWTO. -- Eric S. Raymond "Taking my gun away because I might shoot someone is like cutting my tongue out because I might yell `Fire!' in a crowded theater." -- Peter Venetoklis From akuchlin at cnri.reston.va.us Sun Jun 11 01:44:54 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Sat, 10 Jun 2000 19:44:54 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses __init__.py,NONE,1.1 wrapper.py,NONE,1.1 In-Reply-To: <20000610194822.A882@thyrsus.com>; from esr@thyrsus.com on Sat, Jun 10, 2000 at 07:48:22PM -0400 References: <200006102306.QAA18088@slayer.i.sourceforge.net> <20000610163013.B19484@lyra.org> <20000610194822.A882@thyrsus.com> Message-ID: <20000610194454.B26098@newcnri.cnri.reston.va.us> On Sat, Jun 10, 2000 at 07:48:22PM -0400, Eric S. Raymond wrote: >I'll test it and make the change in my masters if it works for both >cases. I haven't actually shipped the box of goodies yet... Already tested and checked in. If you make other changes, just ship me the new version. (Oh, I forgot about the stupid legal stuff; you should probably send wrapper.py and textbox.py to patches at python.org with the requisite legal disclaimer.) --amk From esr at thyrsus.com Sun Jun 11 01:59:31 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Sat, 10 Jun 2000 19:59:31 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses __init__.py,NONE,1.1 wrapper.py,NONE,1.1 In-Reply-To: <20000610194454.B26098@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Sat, Jun 10, 2000 at 07:44:54PM -0400 References: <200006102306.QAA18088@slayer.i.sourceforge.net> <20000610163013.B19484@lyra.org> <20000610194822.A882@thyrsus.com> <20000610194454.B26098@newcnri.cnri.reston.va.us> Message-ID: <20000610195931.A985@thyrsus.com> Andrew Kuchling : > On Sat, Jun 10, 2000 at 07:48:22PM -0400, Eric S. Raymond wrote: > >I'll test it and make the change in my masters if it works for both > >cases. I haven't actually shipped the box of goodies yet... > > Already tested and checked in. If you make other changes, just ship > me the new version. Well, dang. Didn't you want me to document it first? :-) -- Eric S. Raymond Rifles, muskets, long-bows and hand-grenades are inherently democratic weapons. A complex weapon makes the strong stronger, while a simple weapon -- so long as there is no answer to it -- gives claws to the weak. -- George Orwell, "You and the Atom Bomb", 1945 From akuchlin at cnri.reston.va.us Sun Jun 11 01:51:30 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Sat, 10 Jun 2000 19:51:30 -0400 Subject: [Python-Dev] Creating curses package: done In-Reply-To: <20000610195027.B882@thyrsus.com>; from esr@thyrsus.com on Sat, Jun 10, 2000 at 07:50:27PM -0400 References: <200006100748.DAA17920@snark.thyrsus.com> <20000610111323.A24895@newcnri.cnri.reston.va.us> <20000610113124.B18982@thyrsus.com> <20000610114250.A25014@newcnri.cnri.reston.va.us> <14658.33196.426211.329070@anthem.concentric.net> <20000610193312.A26098@newcnri.cnri.reston.va.us> <20000610195027.B882@thyrsus.com> Message-ID: <20000610195130.C26098@newcnri.cnri.reston.va.us> On Sat, Jun 10, 2000 at 07:50:27PM -0400, Eric S. Raymond wrote: >I thought it was going to become part of curses from the user's point >of view, so that "import curses" brings it in. That seemed to be the >intent of the request at the end of the curses HOWTO. Ooh, no; that text is saying that an editor would make a good example to put in the HOWTO. I'd rather have the curses module contain only a fairly close mapping of the C API, and extensions written in Python would be in submodules like curses.editor, curses.textbox, whatever. Similar to how socketmodule.c is a thin veneer over the BSD socket API, and the spiffy extensions are in asyncore.py, httplib.py, &c. --amk From nhodgson at bigpond.net.au Sun Jun 11 02:04:53 2000 From: nhodgson at bigpond.net.au (Neil Hodgson) Date: Sun, 11 Jun 2000 10:04:53 +1000 Subject: [Python-Dev] Suggestion to Windows- and Mac-library people References: <20000610114227.A19052@thyrsus.com> Message-ID: <016301bfd338$ab8458f0$e3cb8490@neil> > Obviously this is not portable off Unix. Equally obviously it should > be possible to do an equivalent thing under Windows (at least). For > anybody writing interactive programs in this Web-mad era, this > function is just too useful not to have in the toolbox. So this is a > nudge to any Windows and Mac wizards on this list -- let's make this > function available cross-platform. The most common way on Windows to launch the user's preferred browser with an URL would be: >>> import win32api >>> win32api.ShellExecute(0,None,"http://www.python.org",None,"",1) # Note to Mark - more of the parameters should be optional However this, like most process control stuff, requires the Win32 extensions, not the base Python distribution. Trying to hack this up with os.system would be unpleasant. ShellExecute knows when to do icky stuff like use DDE to open the correct URL. Does this type of UI operation really belong in urllib? Neil From esr at thyrsus.com Sun Jun 11 03:26:08 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Sat, 10 Jun 2000 21:26:08 -0400 Subject: [Python-Dev] Suggestion to Windows- and Mac-library people In-Reply-To: <016301bfd338$ab8458f0$e3cb8490@neil>; from nhodgson@bigpond.net.au on Sun, Jun 11, 2000 at 10:04:53AM +1000 References: <20000610114227.A19052@thyrsus.com> <016301bfd338$ab8458f0$e3cb8490@neil> Message-ID: <20000610212608.A1109@thyrsus.com> Neil Hodgson : > Does this type of UI operation really belong in urllib? It fetches the contents of an URL for inspection. Where else would you put it? -- Eric S. Raymond It would be thought a hard government that should tax its people one tenth part. -- Benjamin Franklin From nhodgson at bigpond.net.au Sun Jun 11 03:51:34 2000 From: nhodgson at bigpond.net.au (Neil Hodgson) Date: Sun, 11 Jun 2000 11:51:34 +1000 Subject: [Python-Dev] Suggestion to Windows- and Mac-library people References: <20000610114227.A19052@thyrsus.com> <016301bfd338$ab8458f0$e3cb8490@neil> <20000610212608.A1109@thyrsus.com> Message-ID: <01af01bfd347$937b3fd0$e3cb8490@neil> > > Does this type of UI operation really belong in urllib? > > It fetches the contents of an URL for inspection. Where else would you put it? os? Or a submodule of os. The current os has a bunch of executable-oriented process creation and managment functions. On Macintosh and Windows, data-oriented process creation would be useful. os.process.open("http://www.python.org") os.process.print("c:\src\map.png") Neil From esr at thyrsus.com Sun Jun 11 04:14:56 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Sat, 10 Jun 2000 22:14:56 -0400 Subject: [Python-Dev] Suggestion to Windows- and Mac-library people In-Reply-To: <01af01bfd347$937b3fd0$e3cb8490@neil>; from nhodgson@bigpond.net.au on Sun, Jun 11, 2000 at 11:51:34AM +1000 References: <20000610114227.A19052@thyrsus.com> <016301bfd338$ab8458f0$e3cb8490@neil> <20000610212608.A1109@thyrsus.com> <01af01bfd347$937b3fd0$e3cb8490@neil> Message-ID: <20000610221456.A1223@thyrsus.com> Neil Hodgson : > > It fetches the contents of an URL for inspection. Where else would you > put it? > > os? > Or a submodule of os. > > The current os has a bunch of executable-oriented process creation and > managment functions. On Macintosh and Windows, data-oriented process > creation would be useful. I don't really care where it lives, and will cheerfully defer to those with religious beliefs about the namespace ;-). If it's not obvious, this flurry of library suggestions you've been seeing from me lately all come straight out of the CML2 project. I use the urlbrowse() function to make URLs in help windows into live objects that you can click on. -- Eric S. Raymond This would be the best of all possible worlds, if there were no religion in it. -- John Adams, in a letter to Thomas Jefferson. From esr at snark.thyrsus.com Sun Jun 11 06:29:37 2000 From: esr at snark.thyrsus.com (Eric S. Raymond) Date: Sun, 11 Jun 2000 00:29:37 -0400 Subject: [Python-Dev] Greg Stein's correction broke my traceback wrapper Message-ID: <200006110429.AAA01719@snark.thyrsus.com> Greg Stein's correction broke my traceback wrapper. I now do *not* see a traceback on an exit due to Python runtime errors. I don't know why this is. -- Eric S. Raymond No one who's seen it in action can say the phrase "government help" without either laughing or crying. From gstein at lyra.org Sun Jun 11 07:44:30 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 10 Jun 2000 22:44:30 -0700 Subject: [Python-Dev] Greg Stein's correction broke my traceback wrapper In-Reply-To: <200006110429.AAA01719@snark.thyrsus.com>; from esr@snark.thyrsus.com on Sun, Jun 11, 2000 at 12:29:37AM -0400 References: <200006110429.AAA01719@snark.thyrsus.com> Message-ID: <20000610224430.E19484@lyra.org> On Sun, Jun 11, 2000 at 12:29:37AM -0400, Eric S. Raymond wrote: > Greg Stein's correction broke my traceback wrapper. I now do *not* > see a traceback on an exit due to Python runtime errors. I don't know > why this is. That's strange... a "finally" does not munge tracebacks at all. An exception from a lower level should propagate outwards without interference. Do you still have an "except:" in your code somewhere? (that could be eating your exception) Maybe your test case isn't failing as expected :-) If you'd like, post a copy of the test, and we can debug the wrapper and/or test. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Sun Jun 11 13:01:50 2000 From: gstein at lyra.org (Greg Stein) Date: Sun, 11 Jun 2000 04:01:50 -0700 Subject: [Python-Dev] more on httplib In-Reply-To: ; from gstein@lyra.org on Sat, Jun 03, 2000 at 04:13:55PM -0700 References: Message-ID: <20000611040150.K19484@lyra.org> All of the work below has been completed except for the errno==32 stuff. Module: http://www.lyra.org/greg/python/httplib.py History: http://www.lyra.org/cgi-bin/viewcvs.cgi/gjspy/httplib.py/ There are three items left, that I know of: 1) need doc for new stuff 2) need new test cases 3) I want to remove a "feature" of the old HTTP class. This would be a change in behavior, but (IMO) minor. Specifically, if the Status-Line is malformed, the old httplib.py would return (-1, , None) and store into self.file. Nominally, that file object allows a client to read more data from the socket after the parse problem on the malformed Status-Line. I think it is useless, unused by any clients out there, and it causes me pain to provide it :-) I'd like to just store None into self.file Thoughts? Comments? I'd like to get this thing into Python RSN. Cheers, -g On Sat, Jun 03, 2000 at 04:13:55PM -0700, Greg Stein wrote: > I would like to propose a few changes to the (new) httplib: > > *) drop HTTPS() -- this class isn't in 1.5.2, so there isn't a reason to > provide backwards-compat for it > > *) revamp the pipeline support: > > - record the "last response object" ... when a new getreply() is done, > then we store the "last" into response.prior > - reading of the "HTTP/1.1 " line is deferred, and > performed by the response object > - the read of that line is lazy > - if the response line is read *before* the "prior" response (if any) > is "closed", then an exception is raised: ResponseNotReady > > *) address some of Moshe's concerns: > > - use class-based exceptions > - clarify that HTTPConnection is designed for *blocking* sockets > - conn.close() followed by conn.send() will reopen the socket. This > could lead to programming errors. I'll add a class-based default flag > to disable this behavior. > - in request(), we check for errno==32 ... what to do on Windows? > > > I will implement these changes in small chunks so that each can be > reviewed in my CVS repository. The history is available at: > > http://www.lyra.org/cgi-bin/viewcvs.cgi/gjspy/httplib.py/ -- Greg Stein, http://www.lyra.org/ From moshez at math.huji.ac.il Sun Jun 11 13:58:28 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sun, 11 Jun 2000 14:58:28 +0300 (IDT) Subject: [Python-Dev] more on httplib In-Reply-To: <20000611040150.K19484@lyra.org> Message-ID: On Sun, 11 Jun 2000, Greg Stein wrote: > 3) I want to remove a "feature" of the old HTTP class. This would be a > change in behavior, but (IMO) minor. Specifically, if the Status-Line > is malformed, the old httplib.py would return (-1, , > None) and store into self.file. Nominally, > that file object allows a client to read more data from the socket > after the parse problem on the malformed Status-Line. I think it is > useless, unused by any clients out there, and it causes me pain to > provide it :-) I'd like to just store None into self.file What do the old docs say about this? \begin{methoddesc}{getfile}{} Return a file object from which the data returned by the server can be read, using the \method{read()}, \method{readline()} or \method{readlines()} methods. \end{methoddesc} So why not put a "dummy" file: one whose read(), readline() or readlines() act as if it was at EOF? (IOW, the Pythonic equivalent of open("/dev/null")) -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com From akuchlin at cnri.reston.va.us Sun Jun 11 15:19:48 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Sun, 11 Jun 2000 09:19:48 -0400 Subject: [Python-Dev] Greg Stein's correction broke my traceback wrapper In-Reply-To: <20000610224430.E19484@lyra.org>; from gstein@lyra.org on Sat, Jun 10, 2000 at 10:44:30PM -0700 References: <200006110429.AAA01719@snark.thyrsus.com> <20000610224430.E19484@lyra.org> Message-ID: <20000611091948.A27835@newcnri.cnri.reston.va.us> On Sat, Jun 10, 2000 at 10:44:30PM -0700, Greg Stein wrote: >On Sun, Jun 11, 2000 at 12:29:37AM -0400, Eric S. Raymond wrote: >> Greg Stein's correction broke my traceback wrapper. >If you'd like, post a copy of the test, and we can debug the wrapper >and/or test. I'll leave it to the two of you to figure out what's going on and submit a corrected version, if necessary. I did test the simplified version and it seemed fine, though maybe there's a subtle problem. I'm off to CA, and will be back on Wednesday. (Mmmm... hours of plane hacking...) --amk From gstein at lyra.org Sun Jun 11 21:18:26 2000 From: gstein at lyra.org (Greg Stein) Date: Sun, 11 Jun 2000 12:18:26 -0700 Subject: [Python-Dev] more on httplib In-Reply-To: ; from moshez@math.huji.ac.il on Sun, Jun 11, 2000 at 02:58:28PM +0300 References: <20000611040150.K19484@lyra.org> Message-ID: <20000611121826.L19484@lyra.org> On Sun, Jun 11, 2000 at 02:58:28PM +0300, Moshe Zadka wrote: > On Sun, 11 Jun 2000, Greg Stein wrote: > > > 3) I want to remove a "feature" of the old HTTP class. This would be a > > change in behavior, but (IMO) minor. Specifically, if the Status-Line > > is malformed, the old httplib.py would return (-1, , > > None) and store into self.file. Nominally, > > that file object allows a client to read more data from the socket > > after the parse problem on the malformed Status-Line. I think it is > > useless, unused by any clients out there, and it causes me pain to > > provide it :-) I'd like to just store None into self.file > > What do the old docs say about this? > > \begin{methoddesc}{getfile}{} > Return a file object from which the data returned by the server can be > read, using the \method{read()}, \method{readline()} or > \method{readlines()} methods. > \end{methoddesc} > > So why not put a "dummy" file: one whose read(), readline() or readlines() > act as if it was at EOF? > (IOW, the Pythonic equivalent of open("/dev/null")) Sure, I can put different things there, but that would also be a change in semantics. The backwards compat class, HTTP, preserves the API completely -- even down to how it reacts in error situations. (although, it *can* raise errors that it didn't before, when you use methods in the wrong order) I'd like to make a change in the semantics for this particular error condition. Where a client used to be able to do: errcode, errmsg, hdrs = h.getreply() if errcode == -1: file = h.getfile() print 'ERROR: some kind of error occurred' print ' partial read:', `errmsg` print ' next 100 bytes:', `file.read(100)` I'd like to eliminate that "next 100 bytes" ability, and just close the socket when a protocol error occurs. Before making a change in behavior for this (central) class, I'd like to get some feedback. Some voting? Cheers, -g -- Greg Stein, http://www.lyra.org/ From andy at robanal.demon.co.uk Mon Jun 12 13:45:57 2000 From: andy at robanal.demon.co.uk (Andy Robinson) Date: Mon, 12 Jun 2000 12:45:57 +0100 Subject: [Python-Dev] Japanese Codecs In-Reply-To: <20000610160032.0004A1CFA2@dinsdale.python.org> Message-ID: > > Message: 2 > From: "David Ascher" > To: "Python Developers @ python.org" > Subject: RE: [Python-Dev] Japanese Codecs > Date: Fri, 9 Jun 2000 11:54:03 -0700 > charset="US-ASCII" > > > I just wish that these packagers actually become a reality > > some day... the concept is good, but there currently seem to > > be no volunteers or companies jumping in :-( > > I can't speak for Japanese packagers, but ActiveState will be packaging > Python in various ways. > The handful of Python users who know some Japanese are kind of busy at the moment, and the codec work takes more than a night or two; I was hoping to tackle it myself, but as the only Python startup without any venture funding, it is hard to clear aside the time without a customer; and it also needs C skills. I believe we should try and put resources together to fund this work and ensure it gets done this year. I can tell you that HP are now well and truly out of the picture as a sponsor. AFAIK the organisations who should talk are at least... PythonLabs/BeOpen ActiveState Digital Garage PythonWare / Secret Labs ??? (not sure how rapid their global plans are) ReportLab Are there any others? Please get in touch with me... feeling-rather-guilty-as-i18n-sig-coordinator-ly-yrs, Andy Robinson From mal at lemburg.com Mon Jun 12 14:51:11 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 12 Jun 2000 14:51:11 +0200 Subject: [Python-Dev] Japanese Codecs References: Message-ID: <3944DCBF.34DA9E4B@lemburg.com> Andy Robinson wrote: > > > > I just wish that these packagers actually become a reality > > > some day... the concept is good, but there currently seem to > > > be no volunteers or companies jumping in :-( > > > > I can't speak for Japanese packagers, but ActiveState will be packaging > > Python in various ways. > > > The handful of Python users who know some Japanese are kind of busy at the > moment, and the codec work takes more than a night or two; I was hoping to > tackle it myself, but as the only Python startup without any venture > funding, it is hard to clear aside the time without a customer; and it also > needs C skills. > > I believe we should try and put resources together to fund this work and > ensure it gets done this year. I can tell you that HP are now well and > truly out of the picture as a sponsor. How come ...wheren't they the initial sponsors for the i18n of Python ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gstein at lyra.org Mon Jun 12 20:19:07 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 12 Jun 2000 11:19:07 -0700 Subject: [Python-Dev] Japanese Codecs In-Reply-To: ; from andy@robanal.demon.co.uk on Mon, Jun 12, 2000 at 12:45:57PM +0100 References: <20000610160032.0004A1CFA2@dinsdale.python.org> Message-ID: <20000612111907.B19484@lyra.org> On Mon, Jun 12, 2000 at 12:45:57PM +0100, Andy Robinson wrote: > > Message: 2 > > From: "David Ascher" > > To: "Python Developers @ python.org" > > Subject: RE: [Python-Dev] Japanese Codecs > > Date: Fri, 9 Jun 2000 11:54:03 -0700 > > charset="US-ASCII" > > > > > I just wish that these packagers actually become a reality > > > some day... the concept is good, but there currently seem to > > > be no volunteers or companies jumping in :-( > > > > I can't speak for Japanese packagers, but ActiveState will be packaging > > Python in various ways. > > > The handful of Python users who know some Japanese are kind of busy at the > moment, and the codec work takes more than a night or two; I was hoping to > tackle it myself, but as the only Python startup without any venture > funding, it is hard to clear aside the time without a customer; and it also > needs C skills. > > I believe we should try and put resources together to fund this work and > ensure it gets done this year. Um... why is it incumbent upon "us" (for whatever definition of "us" you want to apply :-) to find/fund the work for the Japanese codecs? Why isn't this up to the people who want/need it? Yes, being proactive is a very nice thing to do, but I don't see that we must be, in this case. > I can tell you that HP are now well and truly out of the picture as a > sponsor. eh? What's going on with that? Cheers, -g -- Greg Stein, http://www.lyra.org/ From bwarsaw at python.org Mon Jun 12 22:53:10 2000 From: bwarsaw at python.org (Barry A. Warsaw) Date: Mon, 12 Jun 2000 16:53:10 -0400 (EDT) Subject: [Python-Dev] Towards 1.6 Final Message-ID: <14661.19894.465676.770545@anthem.concentric.net> Okay, let me just preface this by saying none of the following has been blessed by Guido in any way. I'm sure he's still getting nice and tan and drinking exotic tropical alcohol-based beverages, and not thinking about Python one little bit. :) Fred and Jeremy and I had a meeting today and thought about a schedule /we'd/ like to see for Python 1.6 final. This may or may not be feasible but I throw it out here for discussion anyway. The O'Reilly Open Source conference[1] starts July 17th and it would be a nice target to release 1.6 final on the 14th, the Friday before the conference. We all plan on being there.n What do we need to do to hit this target? If we figure a 2 week beta cycle, 1.6beta1 would have to be released June 30, with probably the last alpha on June 23. This is a tight schedule; is it even feasible?. Looking at Andrew's TODO list[2], here's what we came up with: - import hooks revamped (push this to 1.7) - update docos to match 1.6 changes (Fred is going to integrate what's sitting in his inbox) - document more undocumented modules (codes - done; unicodedata - needs work; mmap & pyexpat - Fred to integrate; curses - needs updates; regrtest - push to 1.7, see below) - Unicode: Compress the size of unicodedatabase (waiting for Chris Tismer patches?) - Unicode: Write \N{SMILEY} codec for Unicode (Bill Tutt has a patch, but none of us know what the state of this is -- is it crucial anyway?). - Unicode: the various XXX items in Misc/unicode.txt (we didn't actually find such outstanding issues in this file). - Delete obsolete subdirs in Demo/ directory (done) - Refurbish Demo subdirs to be properly documented, match modern coding style, etc. (???) - Fix ./ld_so_aix installation problem on AIX (anybody know more about this???) - Make test/regrtest.py more usable outside of the Python test suite & document it. (push to 1.7) - Conservative GC, of cycles (this is basically done but needs a lot more testing) - Changes to PyExpat module (Fred says this is done) - Test the hell out of SRE. (waiting for /F's complete implementation) - enable threads by default if OS supports it - integrate intl/gettext module - clear the patches and bugs backlog As we saw it the most critical things that need to get done are testing the GC stuff and the SRE module. Of those, the most critical is SRE since AFAIK, we're still waiting for the final complete code from /F. I could be wrong about that. The last three weren't on Andrew's list. I'm on the hook for enabling threads support by default and integrating intl/gettext. I think those will just be a couple of days work. The final one requires Us to go through the outstanding bug and patches lists and address the critical bugs. Thoughts? What have I missed? -Barry [1] http://conferences.oreilly.com/oscon2000/ [2] http://starship.python.net/crew/amk/python/1.6-jobs.html From gstein at lyra.org Tue Jun 13 02:32:14 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 12 Jun 2000 17:32:14 -0700 Subject: [Python-Dev] Towards 1.6 Final In-Reply-To: <14661.19894.465676.770545@anthem.concentric.net>; from bwarsaw@python.org on Mon, Jun 12, 2000 at 04:53:10PM -0400 References: <14661.19894.465676.770545@anthem.concentric.net> Message-ID: <20000612173214.F19484@lyra.org> On Mon, Jun 12, 2000 at 04:53:10PM -0400, Barry A. Warsaw wrote: > ... disclaimers applied ... > > - import hooks revamped (push this to 1.7) The latest thought had two items here: 1) incorporate feedback into imputil.py. [ the feedback is visible at the end of the most recent version: http://www.lyra.org/cgi-bin/viewcvs.cgi/gjspy/imputil.py/ ] 2) drop imputil into the standard library, but don't go down the "replace Python's default mechanism with imputil" Essentially, this gets imputil out there and usable, but it doesn't directly impact Python's operation in 1.6. >... > - Unicode: Write \N{SMILEY} codec for Unicode (Bill Tutt has a patch, > but none of us know what the state of this is -- is it crucial > anyway?). Bill posted some patches. Little feedback. He will be reposting an updated patch. >... > - Conservative GC, of cycles (this is basically done but needs a lot > more testing) I would recommend doing this in small, reviewable steps. I believe there are a lot of "framework" changes that can occur without actually changing Python itself. After that first round, which will make adding GC easier, then we can do Step 2 and add the real GC stuff. >... New item: - replace httplib.py with Greg's new module. plus docs/test. >... > As we saw it the most critical things that need to get done are > testing the GC stuff and the SRE module. Of those, the most critical > is SRE since AFAIK, we're still waiting for the final complete code > from /F. I could be wrong about that. I believe his recent patch (which AMK applied) brings it up to "current". Cheers, -g -- Greg Stein, http://www.lyra.org/ From Vladimir.Marangozov at inrialpes.fr Tue Jun 13 04:37:23 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Tue, 13 Jun 2000 04:37:23 +0200 (CEST) Subject: [Python-Dev] Towards 1.6 Final In-Reply-To: <14661.19894.465676.770545@anthem.concentric.net> from "Barry A. Warsaw" at Jun 12, 2000 04:53:10 PM Message-ID: <200006130237.EAA10373@python.inrialpes.fr> Barry A. Warsaw wrote: > > - document more undocumented modules (codes - done; unicodedata - > needs work; mmap & pyexpat - Fred to integrate; curses - needs > updates; regrtest - push to 1.7, see below) + Write missing bits in the extend/embed docs (me) Also, last time I ran the 1.6 alpha on AIX, test_mmap failed. I have to take a closer look at this... > - Fix ./ld_so_aix installation problem on AIX (anybody know more about > this???) Yes, AMK, Greg Ward and I know more. It's more an automation (path) problem for building C extensions with distutils than an installation problem per se. Some time ago, I saw a workaround checked in by Greg. If this is still judged as a problem, I'd like to hear about it. This is a minor thing. I have yet to install & run the distutil package on AIX, though, and see what happens. > - enable threads by default if OS supports it Who's going to champion this? I recall Greg Stein volunteering for it ;) (or for something related) > - Test the hell out of SRE. (waiting for /F's complete implementation) ... > As we saw it the most critical things that need to get done are > testing the GC stuff and the SRE module. Of those, the most critical > is SRE since AFAIK, we're still waiting for the final complete code > from /F. I could be wrong about that. It thas been my impression that people are pushing /F for SRE deliveries, but he feels uncomfortable with a number of Unicode compromises (affecting the SRE code and/or design???) and has some implementation hesitations. Add to this the pression of the recent PythonWorks' release. In this context, if there's something to be finished, it would be nice to stop pushing him and help him finishing this project. Unfortunately, I can't offer any help as I don't know much about RE engines. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From bwarsaw at python.org Tue Jun 13 15:17:07 2000 From: bwarsaw at python.org (bwarsaw at python.org) Date: Tue, 13 Jun 2000 09:17:07 -0400 (EDT) Subject: [Python-Dev] Towards 1.6 Final References: <14661.19894.465676.770545@anthem.concentric.net> <200006130237.EAA10373@python.inrialpes.fr> Message-ID: <14662.13395.520180.272688@anthem.concentric.net> >>>>> "VM" == Vladimir Marangozov writes: >> - enable threads by default if OS supports it VM> Who's going to champion this? I recall Greg Stein volunteering VM> for it ;) (or for something related) This isn't the free-threading stuff, which I think we're pushing back to 1.7, right? Just making --with-threads turned on by default if the OS supports it. >> - Test the hell out of SRE. (waiting for /F's complete >> implementation) VM> ... >> As we saw it the most critical things that need to get done are >> testing the GC stuff and the SRE module. Of those, the most >> critical is SRE since AFAIK, we're still waiting for the final >> complete code from /F. I could be wrong about that. VM> It thas been my impression that people are pushing /F for SRE VM> deliveries, but he feels uncomfortable with a number of VM> Unicode compromises (affecting the SRE code and/or design???) VM> and has some implementation hesitations. Add to this the VM> pression of the recent PythonWorks' release. In this context, VM> if there's something to be finished, it would be nice to stop VM> pushing him and help him finishing this VM> project. Unfortunately, I can't offer any help as I don't know VM> much about RE engines. Neither do I. /F, how can we help? -Barry From mal at lemburg.com Tue Jun 13 15:18:59 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 13 Jun 2000 15:18:59 +0200 Subject: [Python-Dev] Towards 1.6 Final References: <14661.19894.465676.770545@anthem.concentric.net> <200006130237.EAA10373@python.inrialpes.fr> <14662.13395.520180.272688@anthem.concentric.net> Message-ID: <394634C3.9C217913@lemburg.com> bwarsaw at python.org wrote: > > >>>>> "VM" == Vladimir Marangozov writes: > > >> - enable threads by default if OS supports it > > VM> Who's going to champion this? I recall Greg Stein volunteering > VM> for it ;) (or for something related) > > This isn't the free-threading stuff, which I think we're pushing back > to 1.7, right? Just making --with-threads turned on by default if the > OS supports it. Ehm, didn't we agree on not enabling this by default ? From what I've heard there are simply too many problems with thread implementations which cause Python to break in different ways (not necessarily Python's faults). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gstein at lyra.org Tue Jun 13 15:26:08 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 13 Jun 2000 06:26:08 -0700 Subject: [Python-Dev] Towards 1.6 Final In-Reply-To: <394634C3.9C217913@lemburg.com>; from mal@lemburg.com on Tue, Jun 13, 2000 at 03:18:59PM +0200 References: <14661.19894.465676.770545@anthem.concentric.net> <200006130237.EAA10373@python.inrialpes.fr> <14662.13395.520180.272688@anthem.concentric.net> <394634C3.9C217913@lemburg.com> Message-ID: <20000613062608.A19484@lyra.org> On Tue, Jun 13, 2000 at 03:18:59PM +0200, M.-A. Lemburg wrote: > bwarsaw at python.org wrote: > > > > >>>>> "VM" == Vladimir Marangozov writes: > > > > >> - enable threads by default if OS supports it > > > > VM> Who's going to champion this? I recall Greg Stein volunteering > > VM> for it ;) (or for something related) > > > > This isn't the free-threading stuff, which I think we're pushing back > > to 1.7, right? Just making --with-threads turned on by default if the > > OS supports it. > > Ehm, didn't we agree on not enabling this by default ? From what > I've heard there are simply too many problems with thread > implementations which cause Python to break in different ways > (not necessarily Python's faults). Threads are quite fine nowadays. Windows has enabled threads for years. Recent Linux distros all turn it on. etc No sense in being afraid any more. :-) Cheers, -g p.s. and yes: free-threading is post 1.6 -- Greg Stein, http://www.lyra.org/ From jim at interet.com Tue Jun 13 15:32:33 2000 From: jim at interet.com (James C. Ahlstrom) Date: Tue, 13 Jun 2000 09:32:33 -0400 Subject: [Python-Dev] Towards 1.6 Final References: <14661.19894.465676.770545@anthem.concentric.net> Message-ID: <394637F1.73E24380@interet.com> Just a heads up that there is a patch in patches at python.org to fix a bug in zipfile.py. JimA From mal at lemburg.com Tue Jun 13 15:35:26 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 13 Jun 2000 15:35:26 +0200 Subject: [Python-Dev] Towards 1.6 Final References: <14661.19894.465676.770545@anthem.concentric.net> <200006130237.EAA10373@python.inrialpes.fr> <14662.13395.520180.272688@anthem.concentric.net> <394634C3.9C217913@lemburg.com> <20000613062608.A19484@lyra.org> Message-ID: <3946389E.B9C5E2F5@lemburg.com> Greg Stein wrote: > > On Tue, Jun 13, 2000 at 03:18:59PM +0200, M.-A. Lemburg wrote: > > bwarsaw at python.org wrote: > > > > > > >>>>> "VM" == Vladimir Marangozov writes: > > > > > > >> - enable threads by default if OS supports it > > > > > > VM> Who's going to champion this? I recall Greg Stein volunteering > > > VM> for it ;) (or for something related) > > > > > > This isn't the free-threading stuff, which I think we're pushing back > > > to 1.7, right? Just making --with-threads turned on by default if the > > > OS supports it. > > > > Ehm, didn't we agree on not enabling this by default ? From what > > I've heard there are simply too many problems with thread > > implementations which cause Python to break in different ways > > (not necessarily Python's faults). > > Threads are quite fine nowadays. Windows has enabled threads for years. > Recent Linux distros all turn it on. Ok, then make it default on Linux and Windows... but leave it turned off on other platforms which still have problems such as AIX. > No sense in being afraid any more. :-) Naa, not being afraid :-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From jim at interet.com Tue Jun 13 15:49:36 2000 From: jim at interet.com (James C. Ahlstrom) Date: Tue, 13 Jun 2000 09:49:36 -0400 Subject: [Python-Dev] Towards 1.6 Final References: <14661.19894.465676.770545@anthem.concentric.net> <20000612173214.F19484@lyra.org> Message-ID: <39463BF0.823C0366@interet.com> Greg Stein wrote: > > On Mon, Jun 12, 2000 at 04:53:10PM -0400, Barry A. Warsaw wrote: > > ... disclaimers applied ... > > > > - import hooks revamped (push this to 1.7) > > The latest thought had two items here: > > 1) incorporate feedback into imputil.py. > [ the feedback is visible at the end of the most recent version: > http://www.lyra.org/cgi-bin/viewcvs.cgi/gjspy/imputil.py/ > ] > 2) drop imputil into the standard library, but don't go down the "replace > Python's default mechanism with imputil" > > Essentially, this gets imputil out there and usable, but it doesn't directly > impact Python's operation in 1.6. I would very much like to see imputil.py in the distribution. I currently use ZIP importing, and I have the ZIP importer class done, except that it is based on the old imputil.py. I think ZIP importing could be a popular feature. JimA From Vladimir.Marangozov at inrialpes.fr Tue Jun 13 15:54:13 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Tue, 13 Jun 2000 15:54:13 +0200 (CEST) Subject: [Python-Dev] Towards 1.6 Final In-Reply-To: <3946389E.B9C5E2F5@lemburg.com> from "M.-A. Lemburg" at Jun 13, 2000 03:35:26 PM Message-ID: <200006131354.PAA11656@python.inrialpes.fr> M.-A. Lemburg wrote: > > Ok, then make it default on Linux and Windows... but leave it > turned off on other platforms which still have problems > such as AIX. No, I'd suggest turning it on by default everywhere and provide a --without-thread configure option if it isn't there yet. On AIX there are identified compiler/libthread combinations that work or don't work. They can be detected though and since the compiler is detected earlier, --with-thread can be automatically disabled with a notification message about the conflict. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From mal at lemburg.com Tue Jun 13 16:05:55 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 13 Jun 2000 16:05:55 +0200 Subject: [Python-Dev] Towards 1.6 Final References: <200006131354.PAA11656@python.inrialpes.fr> Message-ID: <39463FC3.16D6718@lemburg.com> Vladimir Marangozov wrote: > > M.-A. Lemburg wrote: > > > > Ok, then make it default on Linux and Windows... but leave it > > turned off on other platforms which still have problems > > such as AIX. > > No, I'd suggest turning it on by default everywhere and provide a > --without-thread configure option if it isn't there yet. > > On AIX there are identified compiler/libthread combinations that work > or don't work. They can be detected though and since the compiler is > detected earlier, --with-thread can be automatically disabled with a > notification message about the conflict. Ok, let me drop in another argument: How you are going to sell the performance loss due to enabled thread support even when a script doesn't need threads at all ? How about building two versions of the interpreter per default: one with threads enabled and one without threads ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gstein at lyra.org Tue Jun 13 16:09:02 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 13 Jun 2000 07:09:02 -0700 Subject: [Python-Dev] Towards 1.6 Final In-Reply-To: <39463FC3.16D6718@lemburg.com>; from mal@lemburg.com on Tue, Jun 13, 2000 at 04:05:55PM +0200 References: <200006131354.PAA11656@python.inrialpes.fr> <39463FC3.16D6718@lemburg.com> Message-ID: <20000613070902.G19484@lyra.org> On Tue, Jun 13, 2000 at 04:05:55PM +0200, M.-A. Lemburg wrote: > Vladimir Marangozov wrote: > > > > M.-A. Lemburg wrote: > > > > > > Ok, then make it default on Linux and Windows... but leave it > > > turned off on other platforms which still have problems > > > such as AIX. > > > > No, I'd suggest turning it on by default everywhere and provide a > > --without-thread configure option if it isn't there yet. > > > > On AIX there are identified compiler/libthread combinations that work > > or don't work. They can be detected though and since the compiler is > > detected earlier, --with-thread can be automatically disabled with a > > notification message about the conflict. > > Ok, let me drop in another argument: > > How you are going to sell the performance loss due to > enabled thread support even when a script doesn't > need threads at all ? > > How about building two versions of the interpreter per default: > one with threads enabled and one without threads ? Hey, the sky is falling, too. If people are concerned with the performance and want to eek that gain out, then they can build with --without-threads Not a problem. "Gee. My operating system is too slow because it deals with all these process and threads. Why can't I have a single-process OS like DOS? It runs *so* much faster." :-) -- Greg Stein, http://www.lyra.org/ From bwarsaw at python.org Tue Jun 13 16:34:34 2000 From: bwarsaw at python.org (Barry A. Warsaw) Date: Tue, 13 Jun 2000 10:34:34 -0400 (EDT) Subject: [Python-Dev] Towards 1.6 Final References: <3946389E.B9C5E2F5@lemburg.com> <200006131354.PAA11656@python.inrialpes.fr> Message-ID: <14662.18042.397439.614107@anthem.concentric.net> >>>>> "VM" == Vladimir Marangozov writes: VM> On AIX there are identified compiler/libthread combinations VM> that work or don't work. They can be detected though and since VM> the compiler is detected earlier, --with-thread can be VM> automatically disabled with a notification message about the VM> conflict. Can you provide a list of such combinations? -Barry From mal at lemburg.com Tue Jun 13 16:44:20 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 13 Jun 2000 16:44:20 +0200 Subject: [Python-Dev] Towards 1.6 Final References: <200006131354.PAA11656@python.inrialpes.fr> <39463FC3.16D6718@lemburg.com> <20000613070902.G19484@lyra.org> Message-ID: <394648C4.2A701B5B@lemburg.com> [enabling threads per default] > > > > How you are going to sell the performance loss due to > > enabled thread support even when a script doesn't > > need threads at all ? > > > > How about building two versions of the interpreter per default: > > one with threads enabled and one without threads ? > > Hey, the sky is falling, too. > > If people are concerned with the performance and want to eek that gain out, > then they can build with --without-threads > > Not a problem. > > "Gee. My operating system is too slow because it deals with all these > process and threads. Why can't I have a single-process OS like DOS? It runs > *so* much faster." Oh well... never mind, as long as I can still build my Python without threads, I'm fine :-) BTW, what about the idea of adding threads at Python level that was tossed around a few years ago ? Should be easy to do given Christian's stackless patches together with the asyncore libs... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From bwarsaw at python.org Tue Jun 13 16:47:21 2000 From: bwarsaw at python.org (Barry A. Warsaw) Date: Tue, 13 Jun 2000 10:47:21 -0400 (EDT) Subject: [Python-Dev] Towards 1.6 Final References: <200006131354.PAA11656@python.inrialpes.fr> <39463FC3.16D6718@lemburg.com> Message-ID: <14662.18809.468033.931803@anthem.concentric.net> >>>>> "M" == M writes: M> How about building two versions of the interpreter per default: M> one with threads enabled and one without threads ? Python 1.6, current CVS snapshot on a Dell PIII 650, RH 6.1. with threads: 8547.01 pystones/second without threads: 9259.26 pystones/second So an 8% hit isn't negligible but I think it's acceptable for the benefit of being confidently able to distribute threaded apps. -Barry From petrilli at amber.org Tue Jun 13 17:02:01 2000 From: petrilli at amber.org (Christopher Petrilli) Date: Tue, 13 Jun 2000 11:02:01 -0400 Subject: [Python-Dev] Towards 1.6 Final In-Reply-To: <14662.18809.468033.931803@anthem.concentric.net>; from bwarsaw@python.org on Tue, Jun 13, 2000 at 10:47:21AM -0400 References: <200006131354.PAA11656@python.inrialpes.fr> <39463FC3.16D6718@lemburg.com> <14662.18809.468033.931803@anthem.concentric.net> Message-ID: <20000613110201.B25344@trump.amber.org> Barry A. Warsaw [bwarsaw at python.org] wrote: > > >>>>> "M" == M writes: > > M> How about building two versions of the interpreter per default: > M> one with threads enabled and one without threads ? > > Python 1.6, current CVS snapshot on a Dell PIII 650, RH 6.1. > > with threads: 8547.01 pystones/second > without threads: 9259.26 pystones/second > > So an 8% hit isn't negligible but I think it's acceptable for the > benefit of being confidently able to distribute threaded apps. Just as a data point, in the "Python problems" with Zope, this, along with soe idiocy in packaging of RPMs in RedHat are the two biggest problems we have a the Python level. People not compiling with threads turned on, and RedHat's decision to ship the header files separate than the regular Python files. BLAH! Chris -- | Christopher Petrilli | petrilli at amber.org From bwarsaw at python.org Tue Jun 13 16:52:24 2000 From: bwarsaw at python.org (Barry A. Warsaw) Date: Tue, 13 Jun 2000 10:52:24 -0400 (EDT) Subject: [Python-Dev] Towards 1.6 Final References: <200006131354.PAA11656@python.inrialpes.fr> <39463FC3.16D6718@lemburg.com> <20000613070902.G19484@lyra.org> <394648C4.2A701B5B@lemburg.com> Message-ID: <14662.19112.118940.63296@anthem.concentric.net> >>>>> "M" == M writes: M> BTW, what about the idea of adding threads at Python level M> that was tossed around a few years ago ? Should be easy to M> do given Christian's stackless patches together with the M> asyncore libs... Definitely not for 1.6! From mal at lemburg.com Tue Jun 13 17:17:13 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 13 Jun 2000 17:17:13 +0200 Subject: [Python-Dev] Towards 1.6 Final References: <200006131354.PAA11656@python.inrialpes.fr> <39463FC3.16D6718@lemburg.com> <20000613070902.G19484@lyra.org> <394648C4.2A701B5B@lemburg.com> <14662.19112.118940.63296@anthem.concentric.net> Message-ID: <39465079.64174882@lemburg.com> "Barry A. Warsaw" wrote: > > >>>>> "M" == M writes: > > M> BTW, what about the idea of adding threads at Python level > M> that was tossed around a few years ago ? Should be easy to > M> do given Christian's stackless patches together with the > M> asyncore libs... > > Definitely not for 1.6! Sure... just wanted to add a hint for 1.7 :-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From DavidA at ActiveState.com Tue Jun 13 19:31:32 2000 From: DavidA at ActiveState.com (David Ascher) Date: Tue, 13 Jun 2000 10:31:32 -0700 Subject: [Python-Dev] O'Reilly Python Conference Early Registration Deadline Looming Message-ID: It's that time of year again, the O'Reilly Open Source Convention, including the Python track, is fast approaching. You can save up to $280 if you register by Friday July 16. The event will be held this July 17-20 in Monterey, California. Meet all the key Python players, meet fellow Python enthusiasts, learn about new Python developments, find Python-related jobs, and have fun at this yearly event in sunny Monterey, CA. For details on the Python tutorials, see http://www.oreillynet.com/pub/w/python_tutorials.html For details on the Python talks, see http://www.oreillynet.com/pub/w/python_presentations.html For details on the Conference as a whole, see http://conferences.oreilly.com/oscon2000/index.html Looking forward to meeting you there, -- David Ascher OSCON Python Track Program Chair Senior Developer, ActiveState Tool Corporation Students and academics should remember to sign up for reduced fees: http://conferences.oreilly.com/oscon2000/register/ From DavidA at ActiveState.com Tue Jun 13 20:00:41 2000 From: DavidA at ActiveState.com (David Ascher) Date: Tue, 13 Jun 2000 11:00:41 -0700 Subject: [Python-Dev] O'Reilly Python Conference Early Registration Deadline Looming In-Reply-To: Message-ID: > It's that time of year again, the O'Reilly Open Source > Convention, including the Python track, is fast approaching. > You can save up to $280 if you register by Friday July 16. Make that June 19. Sorry about that. --david ascher From mal at lemburg.com Tue Jun 13 21:25:04 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 13 Jun 2000 21:25:04 +0200 Subject: [Python-Dev] Towards 1.6 Final References: <14661.19894.465676.770545@anthem.concentric.net> Message-ID: <39468A90.697D1CE5@lemburg.com> "Barry A. Warsaw" wrote: > > The O'Reilly Open Source conference[1] starts July 17th and it would > be a nice target to release 1.6 final on the 14th, the Friday before > the conference. We all plan on being there.n > > What do we need to do to hit this target? If we figure a 2 week beta > cycle, 1.6beta1 would have to be released June 30, with probably the > last alpha on June 23. This is a tight schedule; is it even > feasible?. Looking at Andrew's TODO list[2], here's what we came up > with: > > [...] > - document more undocumented modules (codes - done; unicodedata - > needs work; mmap & pyexpat - Fred to integrate; curses - needs > updates; regrtest - push to 1.7, see below) I'll take care of unicodedata. What's "codes" -- or did you mean codecs ? > - Unicode: Compress the size of unicodedatabase (waiting for Chris > Tismer patches?) Right... > - Unicode: Write \N{SMILEY} codec for Unicode (Bill Tutt has a patch, > but none of us know what the state of this is -- is it crucial > anyway?). Not crucial, but would be nice to have. > - Unicode: the various XXX items in Misc/unicode.txt (we didn't > actually find such outstanding issues in this file). There are no more discussion points... at least not in that file ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From bwarsaw at python.org Tue Jun 13 21:31:51 2000 From: bwarsaw at python.org (bwarsaw at python.org) Date: Tue, 13 Jun 2000 15:31:51 -0400 (EDT) Subject: [Python-Dev] Towards 1.6 Final References: <14661.19894.465676.770545@anthem.concentric.net> <39468A90.697D1CE5@lemburg.com> Message-ID: <14662.35879.156976.61686@anthem.concentric.net> >>>>> "M" == M writes: M> I'll take care of unicodedata. What's "codes" -- or did you M> mean codecs ? Oops, yes, "codecs". M> There are no more discussion points... at least not in that M> file ;-) :) -Barry From gstein at lyra.org Tue Jun 13 22:11:45 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 13 Jun 2000 13:11:45 -0700 Subject: [Python-Dev] Towards 1.6 Final In-Reply-To: <39463BF0.823C0366@interet.com>; from jim@interet.com on Tue, Jun 13, 2000 at 09:49:36AM -0400 References: <14661.19894.465676.770545@anthem.concentric.net> <20000612173214.F19484@lyra.org> <39463BF0.823C0366@interet.com> Message-ID: <20000613131145.O19484@lyra.org> On Tue, Jun 13, 2000 at 09:49:36AM -0400, James C. Ahlstrom wrote: > Greg Stein wrote: > > On Mon, Jun 12, 2000 at 04:53:10PM -0400, Barry A. Warsaw wrote: > > > ... disclaimers applied ... > > > > > > - import hooks revamped (push this to 1.7) > > > > The latest thought had two items here: > > > > 1) incorporate feedback into imputil.py. > > [ the feedback is visible at the end of the most recent version: > > http://www.lyra.org/cgi-bin/viewcvs.cgi/gjspy/imputil.py/ > > ] > > 2) drop imputil into the standard library, but don't go down the "replace > > Python's default mechanism with imputil" > > > > Essentially, this gets imputil out there and usable, but it doesn't directly > > impact Python's operation in 1.6. > > I would very much like to see imputil.py in the distribution. I > currently > use ZIP importing, and I have the ZIP importer class done, except that > it > is based on the old imputil.py. I think ZIP importing could be a > popular feature. Yes, this should happen. In my current setup, I've got a second module named "importers.py" that has some of the "standard" importers. It would go into there. Oh, so I guess we'd also want to include importers.py into the distro. All of this is preconditioned on getting at least some of that imputil work done that is listed in the TODO area at the bottom of the file... I'm not sure how soon I'll be able to get to that. Cheers, -g -- Greg Stein, http://www.lyra.org/ From Vladimir.Marangozov at inrialpes.fr Wed Jun 14 02:57:05 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Wed, 14 Jun 2000 02:57:05 +0200 (CEST) Subject: [Python-Dev] --with-threads by default (was: Towards 1.6 Final) In-Reply-To: <14662.18042.397439.614107@anthem.concentric.net> from "Barry A. Warsaw" at Jun 13, 2000 10:34:34 AM Message-ID: <200006140057.CAA12560@python.inrialpes.fr> Barry A. Warsaw wrote: > > > >>>>> "VM" == Vladimir Marangozov writes: > > VM> On AIX there are identified compiler/libthread combinations > VM> that work or don't work. They can be detected though and since > VM> the compiler is detected earlier, --with-thread can be > VM> automatically disabled with a notification message about the > VM> conflict. > > Can you provide a list of such combinations? > This is outlined in Misc/AIX-NOTES, section thread support. I've heard that recent versions of gcc work as well, so long as the executable is linked with AIX ld (not GNU ld). Ideally, IMO, there should be an appropriate AC_TRY_RUN little threaded program (or a program suite corresponding to different thread libs and or standards for a given platform) that would disable threads on failure. This approach has the merit of being applicable to all Unix flavors. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From trentm at activestate.com Wed Jun 14 07:21:42 2000 From: trentm at activestate.com (Trent Mick) Date: Tue, 13 Jun 2000 22:21:42 -0700 Subject: [Python-Dev] Re: stringobject question In-Reply-To: <394701D6.37E6F560@yahoo.com> References: <394701D6.37E6F560@yahoo.com> Message-ID: <20000613222142.A27523@activestate.com> On Tue, Jun 13, 2000 at 10:53:58PM -0500, Al-Amerrho H. Amerin wrote: > Is this a bug or a feature?: > > Python 1.6a2 (#4, Jun 9 2000, 02:22:41) [GCC 2.95.2 19991024 > (release)] on linux2 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) > > >>> ''.isdigit() > 1 > >>> ''.isspace() > 1 > Good point, maybe. The __docs__ say: "S.isdigit() -> int\n\ \n\ Return 1 if there are only digit characters in S,\n\ 0 otherwise."; static char isspace__doc__[] = "S.isspace() -> int\n\ \n\ Return 1 if there are only whitespace characters in S,\n\ 0 otherwise."; I am not an English language lawyer so I could see both interpretations from the doc strings. I agree, that the result with a zero length string is surprising. Hi All, Which should it be? Sorry, if this has been covered. Trent -- Trent Mick trentm at activestate.com From mal at lemburg.com Wed Jun 14 10:43:45 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 14 Jun 2000 10:43:45 +0200 Subject: [Python-Dev] Re: stringobject question References: <394701D6.37E6F560@yahoo.com> <20000613222142.A27523@activestate.com> Message-ID: <394745C1.7FA27DCB@lemburg.com> Trent Mick wrote: > > On Tue, Jun 13, 2000 at 10:53:58PM -0500, Al-Amerrho H. Amerin wrote: > > Is this a bug or a feature?: > > > > Python 1.6a2 (#4, Jun 9 2000, 02:22:41) [GCC 2.95.2 19991024 > > (release)] on linux2 > > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > > Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) > > > > >>> ''.isdigit() > > 1 > > >>> ''.isspace() > > 1 > > > > Good point, maybe. The __docs__ say: > > "S.isdigit() -> int\n\ > \n\ > Return 1 if there are only digit characters in S,\n\ > 0 otherwise."; > > static char isspace__doc__[] = > "S.isspace() -> int\n\ > \n\ > Return 1 if there are only whitespace characters in S,\n\ > 0 otherwise."; > > I am not an English language lawyer so I could see both interpretations from > the doc strings. I agree, that the result with a zero length string is > surprising. > > Hi All, > Which should it be? Sorry, if this has been covered. I guess it's a bug... a subtle one though, because in a certain sense both 1 and 0 are acceptable. But since '' is considered to be false, I think that returning 0 makes more sense. I'll fix this to return 0 for emtpy strings and Unicode objects. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From moshez at math.huji.ac.il Wed Jun 14 10:46:48 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 14 Jun 2000 11:46:48 +0300 (IDT) Subject: [Python-Dev] Re: stringobject question In-Reply-To: <394745C1.7FA27DCB@lemburg.com> Message-ID: On Wed, 14 Jun 2000, M.-A. Lemburg wrote: > > > >>> ''.isdigit() > > > 1 > > > >>> ''.isspace() > > > 1 > > > > > > > Good point, maybe. The __docs__ say: > > > > "S.isdigit() -> int\n\ > > \n\ > > Return 1 if there are only digit characters in S,\n\ > > 0 otherwise."; > > > > static char isspace__doc__[] = > > "S.isspace() -> int\n\ > > \n\ > > Return 1 if there are only whitespace characters in S,\n\ > > 0 otherwise."; > > > > I am not an English language lawyer so I could see both interpretations from > > the doc strings. I agree, that the result with a zero length string is > > surprising. > > > > Hi All, > > Which should it be? Sorry, if this has been covered. > > I guess it's a bug... a subtle one though, because in a > certain sense both 1 and 0 are acceptable. But since > '' is considered to be false, I think that returning 0 > makes more sense. > > I'll fix this to return 0 for emtpy strings and Unicode objects. I just realized something: if you change the semantics to mean "number of digits", you'll get the right answer for all 0- and 1- length strings and unicode objects. just-an-observation-ly y'rs, Z. -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com From mal at lemburg.com Wed Jun 14 11:18:10 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 14 Jun 2000 11:18:10 +0200 Subject: [Python-Dev] Re: stringobject question References: Message-ID: <39474DD2.BF51C872@lemburg.com> Moshe Zadka wrote: > > On Wed, 14 Jun 2000, M.-A. Lemburg wrote: > > > > > >>> ''.isdigit() > > > > 1 > > > > >>> ''.isspace() > > > > 1 > > > > > > > > > > Good point, maybe. The __docs__ say: > > > > > > "S.isdigit() -> int\n\ > > > \n\ > > > Return 1 if there are only digit characters in S,\n\ > > > 0 otherwise."; > > > > > > static char isspace__doc__[] = > > > "S.isspace() -> int\n\ > > > \n\ > > > Return 1 if there are only whitespace characters in S,\n\ > > > 0 otherwise."; > > > > > > I am not an English language lawyer so I could see both interpretations from > > > the doc strings. I agree, that the result with a zero length string is > > > surprising. > > > > > > Hi All, > > > Which should it be? Sorry, if this has been covered. > > > > I guess it's a bug... a subtle one though, because in a > > certain sense both 1 and 0 are acceptable. But since > > '' is considered to be false, I think that returning 0 > > makes more sense. > > > > I'll fix this to return 0 for emtpy strings and Unicode objects. > > I just realized something: if you change the semantics to mean "number of > digits", you'll get the right answer for all 0- and 1- length strings > and unicode objects. Hmm, the .isXXX() tests should return 1/0 since they test properties rather than count characters. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From billtut at microsoft.com Wed Jun 14 12:12:48 2000 From: billtut at microsoft.com (Bill Tutt) Date: Wed, 14 Jun 2000 03:12:48 -0700 Subject: [Python-Dev] AIX shared library support Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E4@RED-MSG-50> Is there any particular reason that dynload_aix.c doesn't use AIX's dlopen? From mal at lemburg.com Wed Jun 14 12:19:44 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 14 Jun 2000 12:19:44 +0200 Subject: [Python-Dev] AIX shared library support References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E4@RED-MSG-50> Message-ID: <39475C40.EF9CE51B@lemburg.com> Bill Tutt wrote: > > Is there any particular reason that dynload_aix.c doesn't use AIX's dlopen? > >From what I can tell, libtool seems to use dlopen on AIX 3.xxx and AIX > 4.xxx. > > I was all set to integrate the \N{...} support into the Unicode-escape > encoding, and dynamically load the hash table data in on demand, but > dynload_aix only cares about module entry points and won't let you specify > an explicit function name. Uhm, why do you need to go that deep into the internals of the import mechanism ? Wouldn't is suffice to put the hash table into a _ucnhash module which get imported on demand (the import mechanism would then take care of the rest) ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From billtut at microsoft.com Wed Jun 14 12:12:48 2000 From: billtut at microsoft.com (Bill Tutt) Date: Wed, 14 Jun 2000 03:12:48 -0700 Subject: [Python-Dev] AIX shared library support Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E4@RED-MSG-50> Is there any particular reason that dynload_aix.c doesn't use AIX's dlopen? From billtut at microsoft.com Wed Jun 14 12:33:11 2000 From: billtut at microsoft.com (Bill Tutt) Date: Wed, 14 Jun 2000 03:33:11 -0700 Subject: [Python-Dev] unicode character name patch status Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E5@RED-MSG-50> I was all set to integrate the \N{...} support into the Unicode-escape encoding, and dynamically load the hash table data in on demand, but dynload_aix only cares about module entry points and won't let you specify an explicit function name. Ugh. So, its question and answer time folks: 1) If we can't dynamically load the hash table data, is it that big of a deal? Probably only for WinCE, palm pilot, etc, and they already have patches against CVS. 2) Or, should I just have a separate encoding? I'd prefer to pick option #1 since Perl natively supports the syntax in their strings. The data is all constant read/only data that will be mmapped directly from the binary, so it only effects working set if the feature is used. Barry, Greg, Guido? The only feedback I got last time I submitted the patch was from MAL, it'd help if some other folks would comment on it. Thanks, Bill From mal at lemburg.com Wed Jun 14 12:45:01 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 14 Jun 2000 12:45:01 +0200 Subject: [Python-Dev] unicode character name patch status References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E5@RED-MSG-50> Message-ID: <3947622D.9995572E@lemburg.com> [Me again, hope you don't mind ;-)] Bill Tutt wrote: > > I was all set to integrate the \N{...} support into the Unicode-escape > encoding, and dynamically load the hash table data in on demand, but > dynload_aix only cares about module entry points and won't let you specify > an explicit function name. > > Ugh. So, its question and answer time folks: > 1) If we can't dynamically load the hash table data, is it that big of > a deal? > Probably only for WinCE, palm pilot, etc, and they already > have patches against CVS. > 2) Or, should I just have a separate encoding? > > I'd prefer to pick option #1 since Perl natively supports the syntax in > their strings. The data is all constant read/only data that will be mmapped > directly from the binary, so it only effects working set if the feature is > used. Why can't you use PyImport_Import() to do the dynamic loading and combine this with the standard unicode-escape codec ? If it fails (e.g. the user has disabled the module entry in Setup), then simply raise an exception. I wouldn't want the hash table around linked statically -- it's simply to big. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From billtut at microsoft.com Wed Jun 14 12:48:49 2000 From: billtut at microsoft.com (Bill Tutt) Date: Wed, 14 Jun 2000 03:48:49 -0700 Subject: [Python-Dev] AIX shared library support Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E6@RED-MSG-50> MAL wrote: > Bill Tutt wrote: > > > > Is there any particular reason that dynload_aix.c doesn't use AIX's dlopen? > > >From what I can tell, libtool seems to use dlopen on AIX 3.xxx and AIX > > 4.xxx. > > > I was all set to integrate the \N{...} support into the Unicode-escape > > encoding, and dynamically load the hash table data in on demand, but > > dynload_aix only cares about module entry points and won't let you specify > > an explicit function name. > Uhm, why do you need to go that deep into the internals > of the import mechanism ? > Wouldn't is suffice to put the hash table into a _ucnhash module > which get imported on demand (the import mechanism would then > take care of the rest) ? It would suffice, but it'd be less efficient (and more work) since I'd then have to access the data/hash functions through the normal PyObject mechanisms instead of directly as C functions. That is, I'm trying to avoid creating a PyString of whatever is inside the braces. (\N{SMILEY}). Then again, maybe I'm just being too performance sensitive. The import mechanism got redone weirdly, all of the ways of doing dynamic loading except AIX encode the idea that the function name must be preceeded by "init". Dynload_xxx.c is the wrong place to put that requirement. Whomever calls _PyImport_GetDynLoadFunc() should handle that issue. Just as an FYI, the only problem I've found so far with my last patch was wrt handling Unicode characters with values in the UCS-4 code space. (Not that there are any yet, but the code must handle that case anyway, sine I don't want to have to go change it later.) Bill From mal at lemburg.com Wed Jun 14 13:00:50 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 14 Jun 2000 13:00:50 +0200 Subject: [Python-Dev] AIX shared library support References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E6@RED-MSG-50> Message-ID: <394765E2.BFBEA135@lemburg.com> Bill Tutt wrote: > > MAL wrote: > > > Bill Tutt wrote: > > > > > > Is there any particular reason that dynload_aix.c doesn't use AIX's > dlopen? > > > >From what I can tell, libtool seems to use dlopen on AIX 3.xxx and AIX > > > 4.xxx. > > > > > I was all set to integrate the \N{...} support into the Unicode-escape > > > encoding, and dynamically load the hash table data in on demand, but > > > dynload_aix only cares about module entry points and won't let you > specify > > > an explicit function name. > > > Uhm, why do you need to go that deep into the internals > > of the import mechanism ? > > > Wouldn't is suffice to put the hash table into a _ucnhash module > > which get imported on demand (the import mechanism would then > > take care of the rest) ? > > It would suffice, but it'd be less efficient (and more work) since I'd then > have to access the data/hash functions through the normal PyObject > mechanisms instead of directly as C functions. That is, I'm trying to avoid > creating a PyString of whatever is inside the braces. (\N{SMILEY}). Then > again, maybe I'm just being too performance sensitive. You could pass a pointer to the char* via a PyCObject. I usually export the whole module C API via such an object and it works great: you can rely on module import to get the magic right and still have a C API around which you can call directly from C -- without the need to wrap anything in Python objects. FYI, mxODBC and mxDateTime are tied together using this mechanism; look in the mxDateTime.h|c files for details. > The import mechanism got redone weirdly, all of the ways of doing dynamic > loading except AIX encode the idea that the function name must be preceeded > by "init". > Dynload_xxx.c is the wrong place to put that requirement. Whomever calls > _PyImport_GetDynLoadFunc() should handle that issue. That's to Greg's address, I guess ;-) > Just as an FYI, the only problem I've found so far with my last patch was > wrt handling Unicode characters with values in the UCS-4 code space. (Not > that there are any yet, but the code must handle that case anyway, sine I > don't want to have to go change it later.) Why is there a problem there ? Python currently uses UTF16 as native format. UTF-16 surrogates are not supported though... and probably won't be for a while. I don't see much of a problem here. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From billtut at microsoft.com Wed Jun 14 13:10:44 2000 From: billtut at microsoft.com (Bill Tutt) Date: Wed, 14 Jun 2000 04:10:44 -0700 Subject: [Python-Dev] AIX shared library support Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E7@RED-MSG-50> MAL: > Bill: > > Just as an FYI, the only problem I've found so far with my last patch was > > wrt handling Unicode characters with values in the UCS-4 code space. (Not > > that there are any yet, but the code must handle that case anyway, sine I > > don't want to have to go change it later.) > Why is there a problem there ? Python currently uses UTF16 > as native format. UTF-16 surrogates are not supported though... > and probably won't be for a while. The rest of Python may not care about UTF-16, but that's no particular reason to not have this code support generating surrogates if an input UnicodeData.txt happens to have character names for code points that require surrogates. Bill From mwh21 at cam.ac.uk Wed Jun 14 13:18:27 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 14 Jun 2000 12:18:27 +0100 Subject: [Python-Dev] Can starship please have its front page back? Message-ID: I'm not sure if I should ask this here, but I've tried crew at starship and comp.lang.python, so forgive me please. There are links all over the place (eg. python.org, oriellynet) to "http://starship.python.net/", which currently gets the gentle browsing newbie a rather forbidding, somewhat out-of-date status page. I don't really think this gives a good impression. Particularly as said page is no longer on the machine that had the hard disc failure... Cheers, M. From mal at lemburg.com Wed Jun 14 13:36:25 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 14 Jun 2000 13:36:25 +0200 Subject: [Python-Dev] AIX shared library support References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E7@RED-MSG-50> Message-ID: <39476E39.E4163D20@lemburg.com> Bill Tutt wrote: > > MAL: > > Bill: > > > Just as an FYI, the only problem I've found so far with my last patch > was > > > wrt handling Unicode characters with values in the UCS-4 code space. > (Not > > > that there are any yet, but the code must handle that case anyway, sine > I > > > don't want to have to go change it later.) > > > Why is there a problem there ? Python currently uses UTF16 > > as native format. UTF-16 surrogates are not supported though... > > and probably won't be for a while. > > The rest of Python may not care about UTF-16, but that's no particular > reason to not have this code support generating surrogates if an input > UnicodeData.txt happens to have character names for code points that require > surrogates. True. As long as the design permitts generating surrogates, there should be no problem. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Vladimir.Marangozov at inrialpes.fr Wed Jun 14 16:48:01 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Wed, 14 Jun 2000 16:48:01 +0200 (CEST) Subject: [Python-Dev] AIX shared library support In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E4@RED-MSG-50> from "Bill Tutt" at Jun 14, 2000 03:12:48 AM Message-ID: <200006141448.QAA14090@python.inrialpes.fr> Bill Tutt wrote: > > Is there any particular reason that dynload_aix.c doesn't use AIX's dlopen? > >From what I can tell, libtool seems to use dlopen on AIX 3.xxx and AIX > 4.xxx. Historically, the dlopen interface (originally a Sun thing) was included as a standard library (libdl.a) starting from AIX 4.3 (or 4.2). It doesn't exist on AIX 3.x and AIX 4.1.x. There was a dlopen emulation library, though, written by an old AIX guru, but it had to be installed manually on these versions of AIX. Then, slowly, IBM started to be more receptive about some defacto standards, included libdl.a in the standard AIX distribution and introduced the -G flag in ld (a la Sun and others) which adds -ldl to the link automatically. But all this really works on AIX 4.3 and up. So what is implemented in Python relies on lower-level dynamic linker primitives that exist on all AIX releases. Furthermore, our original goal was not to provide a complete (per symbol) runtime linker, hence the current state of affairs. The 'init' entry point convention is a Python convention. It can be changed at link time, but still, there is no a full featured dynamic linker and there is no reason to have it in Python. Python wisely limits itself to the loading of a shared object (lib) in memory, then to invoke an init function, without going into subtle per-platform dynlinking details, which would have been a royal pain to maintain anyway. I second MAL's opinions: you really don't want to be so deep about dynloads and it's better to fit in the current architecture. Personnally, I won't care if my smiley takes half a second to load in memory. :-) -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From gstein at lyra.org Wed Jun 14 17:00:23 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 14 Jun 2000 08:00:23 -0700 Subject: [Python-Dev] unicode character name patch status In-Reply-To: <3947622D.9995572E@lemburg.com>; from mal@lemburg.com on Wed, Jun 14, 2000 at 12:45:01PM +0200 References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E5@RED-MSG-50> <3947622D.9995572E@lemburg.com> Message-ID: <20000614080023.L27338@lyra.org> On Wed, Jun 14, 2000 at 12:45:01PM +0200, M.-A. Lemburg wrote: >... > Bill Tutt wrote: > > I was all set to integrate the \N{...} support into the Unicode-escape > > encoding, and dynamically load the hash table data in on demand, but > > dynload_aix only cares about module entry points and won't let you specify > > an explicit function name. > > > > Ugh. So, its question and answer time folks: > > 1) If we can't dynamically load the hash table data, is it that big of > > a deal? > > Probably only for WinCE, palm pilot, etc, and they already > > have patches against CVS. > > 2) Or, should I just have a separate encoding? > > > > I'd prefer to pick option #1 since Perl natively supports the syntax in > > their strings. The data is all constant read/only data that will be mmapped > > directly from the binary, so it only effects working set if the feature is > > used. > > Why can't you use PyImport_Import() to do the dynamic loading and > combine this with the standard unicode-escape codec ? > If it fails (e.g. the user has disabled the module entry in > Setup), then simply raise an exception. > > I wouldn't want the hash table around linked statically -- it's > simply to big. I'm with MAL. Use Python's import mechanism. That gets you the dynamic load stuff no problem. It *also* handles the case where the module is statically linked. If you go play games with the dynload stuff, then it would be a bitch to build a single, statically-linked executable. Cheers, -g -- Greg Stein, http://www.lyra.org/ From akuchlin at cnri.reston.va.us Wed Jun 14 18:13:23 2000 From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling) Date: Wed, 14 Jun 2000 12:13:23 -0400 Subject: [Python-Dev] Towards 1.6 Final In-Reply-To: <14661.19894.465676.770545@anthem.concentric.net>; from bwarsaw@python.org on Mon, Jun 12, 2000 at 04:53:10PM -0400 References: <14661.19894.465676.770545@anthem.concentric.net> Message-ID: <20000614121323.A13993@amarok.cnri.reston.va.us> On Mon, Jun 12, 2000 at 04:53:10PM -0400, Barry A. Warsaw wrote: >If we figure a 2 week beta cycle, ... Unicode support, a new regex engine, various minor backward incompatible changes that may or may not cause people problems... a 2-week beta seems too short. --amk From billtut at microsoft.com Wed Jun 14 18:29:30 2000 From: billtut at microsoft.com (Bill Tutt) Date: Wed, 14 Jun 2000 09:29:30 -0700 Subject: [Python-Dev] unicode character name patch status Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E8@RED-MSG-50> > From: Greg Stein [mailto:gstein at lyra.org] > I'm with MAL. Use Python's import mechanism. That gets you > the dynamic load > stuff no problem. It *also* handles the case where the module > is statically > linked. > Ok, ok, so much for the idea about modifying as few lines as possible in my patch. :) > If you go play games with the dynload stuff, then it would be > a bitch to > build a single, statically-linked executable. > Nah, thats what the config.h hAVE_... for dynamic load support #define is for. :) Bill From trentm at activestate.com Wed Jun 14 19:36:32 2000 From: trentm at activestate.com (Trent Mick) Date: Wed, 14 Jun 2000 10:36:32 -0700 Subject: [Python-Dev] Re: stringobject question In-Reply-To: <394745C1.7FA27DCB@lemburg.com> References: <394701D6.37E6F560@yahoo.com> <20000613222142.A27523@activestate.com> <394745C1.7FA27DCB@lemburg.com> Message-ID: <20000614103632.C29778@activestate.com> On Wed, Jun 14, 2000 at 10:43:45AM +0200, M . -A . Lemburg wrote: > > I guess it's a bug... a subtle one though, because in a > certain sense both 1 and 0 are acceptable. But since > '' is considered to be false, I think that returning 0 > makes more sense. > > I'll fix this to return 0 for emtpy strings and Unicode objects. These are copied from Java, are they not? What do the Java equivalents return? Trent -- Trent Mick trentm at activestate.com From gstein at lyra.org Wed Jun 14 23:52:08 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 14 Jun 2000 14:52:08 -0700 Subject: [Python-Dev] unicode character name patch status In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E8@RED-MSG-50>; from billtut@microsoft.com on Wed, Jun 14, 2000 at 09:29:30AM -0700 References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E8@RED-MSG-50> Message-ID: <20000614145208.D28280@lyra.org> On Wed, Jun 14, 2000 at 09:29:30AM -0700, Bill Tutt wrote: > > From: Greg Stein [mailto:gstein at lyra.org] >... > > If you go play games with the dynload stuff, then it would be > > a bitch to > > build a single, statically-linked executable. > > Nah, thats what the config.h hAVE_... for dynamic load support #define is > for. :) Just to beat a dead horse here: no. Just because config.h says that I *could* dynamically load doesn't mean that I *want* to. If I want to build a mother, static Python and I want the name table bundled in, then any dynamic loading that you make explicit is just going to gum up the process. Now shut up, and drink your Kool-Aid. :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From thomas at xs4all.net Thu Jun 15 19:53:27 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 15 Jun 2000 19:53:27 +0200 Subject: [Python-Dev] Augmented assignment Message-ID: <20000615195327.R8000@xs4all.nl> I'd like some (minor) feedback on the augmented assignment thing I'm working on. I understand Guido is the only one who accepts patches like this, and appreciate that, but I'm hoping someone can at least tell me what I'm doing wrong so I can fix it before Guido sees it ;-) But if I'm being an impatient flap, just tell me so and I'll calm down. I also appreciate the fact that the patch is quite large, and not many people have the time to scrutinize each version, so I'll summerize the issues I'm uncertain about. * The patch needs to add a new type of opcode, one that takes 2 arguments. This is because the opcodes that load, change and store a name need one argument for the index in the name table (or local variable number), and one argument for the actual operation. It could also work by using PyInt or another PyObject to pass the extra argument on the stack, but I don't think pushing a non-PyObject-pointer onto the stack is a good idea. Adding 2-argument opcodes seemed the easiest solution. However, I'm not really into Python-hacking (or was, I should say, because it's great fun) and the python-dev list doesn't seem to be searchable ;) so I can't know if this issue has come up before. Has it ? Would the new opcode-type be an unsurpassable problem ? should I use the stack instead ? * The patch also needs to add 11 new __hooks__, 11 new API calls, 11 new entries in the PyNumberMethods struct and 2 new entries in the PySequenceMethods struct. Would that conceivably be a problem ? I've heard people on the python-list complain about this ;-P * Should I start sending the patch, in pieces, to the patches-list, or is it a wasted effort because noone will touch it until Guido is back ? If I should send it, should I send it in one large patch (minus autogenerated files) or in nice functionality-sized pieces ? * How 'cool' does Guido actually think this syntax is ? Apparently the subject has come up a few times ;) and I got positive signals from both Tim and Guido, but if the patch won't go in as a patch, and won't actually be used other than some inspiration for a future rewrite of the CPython core, I'm not going to worry too much about the patch ;) I'm trying to get my boss to send me to OSCON2000 to harass Guido about these issues himself, but he (my boss) isn't co-operating ;-P (Not suprising, as Python isn't quite part of my job description, *snif*) Regards, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mal at lemburg.com Thu Jun 15 20:12:50 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 15 Jun 2000 20:12:50 +0200 Subject: [Python-Dev] Augmented assignment References: <20000615195327.R8000@xs4all.nl> Message-ID: <39491CA2.2BDC0DDC@lemburg.com> Thomas Wouters wrote: > > I'd like some (minor) feedback on the augmented assignment thing I'm working > on. I understand Guido is the only one who accepts patches like this, and > appreciate that, but I'm hoping someone can at least tell me what I'm doing > wrong so I can fix it before Guido sees it ;-) But if I'm being an impatient > flap, just tell me so and I'll calm down. I'd make this a 1.7 issue. 1.6 should go into the stabilization phase and big complicated patches like yours should receive some more design and concept discussion before getting checked in. BTW, with "augmented assign" I suppose you mean things like a += 1 and b *= 2, right ? > I also appreciate the fact that the patch is quite large, and not many > people have the time to scrutinize each version, so I'll summerize the > issues I'm uncertain about. > > * The patch needs to add a new type of opcode, one that takes 2 arguments. > This is because the opcodes that load, change and store a name need one > argument for the index in the name table (or local variable number), and one > argument for the actual operation. > > It could also work by using PyInt or another PyObject to pass the extra > argument on the stack, but I don't think pushing a non-PyObject-pointer onto > the stack is a good idea. Adding 2-argument opcodes seemed the easiest > solution. > > However, I'm not really into Python-hacking (or was, I should say, because > it's great fun) and the python-dev list doesn't seem to be searchable ;) so > I can't know if this issue has come up before. Has it ? Would the new > opcode-type be an unsurpassable problem ? should I use the stack instead ? Any reason you can't do this with the existing op codes ? E.g. a += b 1. load a 2. load b 3. add 4. store a > * The patch also needs to add 11 new __hooks__, 11 new API calls, 11 new entries > in the PyNumberMethods struct and 2 new entries in the PySequenceMethods > struct. Would that conceivably be a problem ? I've heard people on the > python-list complain about this ;-P More generic solutions are usually more accepted. BTW, before hacking too much into this, you ought to consider that we are planning for rich comparisons and decentralized coercion in 1.7 (this was planned for 1.6, but David and I got carried away with other things). I wouldn't want to have to hack 11 new slots to get this right... > * Should I start sending the patch, in pieces, to the patches-list, or is > it a wasted effort because noone will touch it until Guido is back ? If I > should send it, should I send it in one large patch (minus autogenerated > files) or in nice functionality-sized pieces ? Better put it on a web page and inform python-dev of new features, enhancements, etc. > * How 'cool' does Guido actually think this syntax is ? Apparently the > subject has come up a few times ;) and I got positive signals from both Tim > and Guido, but if the patch won't go in as a patch, and won't actually be > used other than some inspiration for a future rewrite of the CPython core, > I'm not going to worry too much about the patch ;) Having a patch is good for discussion, whether it gets incorporated is a different issue ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From bckfnn at worldonline.dk Thu Jun 15 20:16:03 2000 From: bckfnn at worldonline.dk (Finn Bock) Date: Thu, 15 Jun 2000 18:16:03 GMT Subject: [Python-Dev] Re: stringobject question In-Reply-To: <20000614103632.C29778@activestate.com> References: <394701D6.37E6F560@yahoo.com> <20000613222142.A27523@activestate.com> <394745C1.7FA27DCB@lemburg.com> <20000614103632.C29778@activestate.com> Message-ID: <39491d4f.4591422@smtp.worldonline.dk> >On Wed, Jun 14, 2000 at 10:43:45AM +0200, M . -A . Lemburg wrote: >> >> I guess it's a bug... a subtle one though, because in a >> certain sense both 1 and 0 are acceptable. But since >> '' is considered to be false, I think that returning 0 >> makes more sense. >> >> I'll fix this to return 0 for emtpy strings and Unicode objects. [Trent Mick] >These are copied from Java, are they not? What do the Java equivalents >return? The .isXX methods does not exists on java strings, only on the Character class. So in java they can never be called on anything with length 0. regards, finn From trentm at activestate.com Thu Jun 15 20:28:57 2000 From: trentm at activestate.com (Trent Mick) Date: Thu, 15 Jun 2000 11:28:57 -0700 Subject: [Python-Dev] Re: stringobject question In-Reply-To: <39491d4f.4591422@smtp.worldonline.dk> References: <394701D6.37E6F560@yahoo.com> <20000613222142.A27523@activestate.com> <394745C1.7FA27DCB@lemburg.com> <20000614103632.C29778@activestate.com> <39491d4f.4591422@smtp.worldonline.dk> Message-ID: <20000615112857.A4508@activestate.com> On Thu, Jun 15, 2000 at 06:16:03PM +0000, Finn Bock wrote: > >These are copied from Java, are they not? What do the Java equivalents > >return? > > The .isXX methods does not exists on java strings, only on the Character > class. So in java they can never be called on anything with length 0. > Okeedoke, so go with the changes that MAL made s.t. ''.isdigit() returns 0, unless others have any opposition. Trent -- Trent Mick trentm at activestate.com From fdrake at beopen.com Thu Jun 15 20:34:02 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 15 Jun 2000 14:34:02 -0400 (EDT) Subject: [Python-Dev] Re: stringobject question In-Reply-To: <20000615112857.A4508@activestate.com> References: <394701D6.37E6F560@yahoo.com> <20000613222142.A27523@activestate.com> <394745C1.7FA27DCB@lemburg.com> <20000614103632.C29778@activestate.com> <39491d4f.4591422@smtp.worldonline.dk> <20000615112857.A4508@activestate.com> Message-ID: <14665.8602.65230.481663@cj42289-a.reston1.va.home.com> Trent Mick writes: > Okeedoke, so go with the changes that MAL made s.t. ''.isdigit() returns 0, > unless others have any opposition. This sounds good to me. Marc-Andre, go ahead and checkin anything that isn't already in whenever you're ready; I've not seen any hints of opposition yet, and there's been enough waiting to just check it in. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From trentm at activestate.com Thu Jun 15 20:58:27 2000 From: trentm at activestate.com (Trent Mick) Date: Thu, 15 Jun 2000 11:58:27 -0700 Subject: [Python-Dev] Re: stringobject question In-Reply-To: <14665.8602.65230.481663@cj42289-a.reston1.va.home.com> References: <394701D6.37E6F560@yahoo.com> <20000613222142.A27523@activestate.com> <394745C1.7FA27DCB@lemburg.com> <20000614103632.C29778@activestate.com> <39491d4f.4591422@smtp.worldonline.dk> <20000615112857.A4508@activestate.com> <14665.8602.65230.481663@cj42289-a.reston1.va.home.com> Message-ID: <20000615115827.A4657@activestate.com> On Thu, Jun 15, 2000 at 02:34:02PM -0400, Fred L. Drake, Jr. wrote: > > Trent Mick writes: > > Okeedoke, so go with the changes that MAL made s.t. ''.isdigit() returns 0, > > unless others have any opposition. > > This sounds good to me. > Marc-Andre, go ahead and checkin anything that isn't already in > whenever you're ready; I've not seen any hints of opposition yet, and > there's been enough waiting to just check it in. > From mal at lemburg.com Thu Jun 15 21:10:43 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 15 Jun 2000 21:10:43 +0200 Subject: [Python-Dev] Re: stringobject question References: <394701D6.37E6F560@yahoo.com> <20000613222142.A27523@activestate.com> <394745C1.7FA27DCB@lemburg.com> <20000614103632.C29778@activestate.com> <39491d4f.4591422@smtp.worldonline.dk> <20000615112857.A4508@activestate.com> <14665.8602.65230.481663@cj42289-a.reston1.va.home.com> <20000615115827.A4657@activestate.com> Message-ID: <39492A33.75440AA4@lemburg.com> Trent Mick wrote: > > On Thu, Jun 15, 2000 at 02:34:02PM -0400, Fred L. Drake, Jr. wrote: > > > > Trent Mick writes: > > > Okeedoke, so go with the changes that MAL made s.t. ''.isdigit() returns 0, > > > unless others have any opposition. > > > > This sounds good to me. > > Marc-Andre, go ahead and checkin anything that isn't already in > > whenever you're ready; I've not seen any hints of opposition yet, and > > there's been enough waiting to just check it in. > > > > >From what I have seen it is already in. Right ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fdrake at beopen.com Thu Jun 15 21:21:40 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 15 Jun 2000 15:21:40 -0400 (EDT) Subject: [Python-Dev] Re: stringobject question In-Reply-To: <39492A33.75440AA4@lemburg.com> References: <394701D6.37E6F560@yahoo.com> <20000613222142.A27523@activestate.com> <394745C1.7FA27DCB@lemburg.com> <20000614103632.C29778@activestate.com> <39491d4f.4591422@smtp.worldonline.dk> <20000615112857.A4508@activestate.com> <14665.8602.65230.481663@cj42289-a.reston1.va.home.com> <20000615115827.A4657@activestate.com> <39492A33.75440AA4@lemburg.com> Message-ID: <14665.11460.597390.222317@cj42289-a.reston1.va.home.com> M.-A. Lemburg writes: > Trent Mick wrote: > > >From what I have seen it is already in. > > Right ;-) I may have mentioned that I've been losing track of all the patches. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From thomas at xs4all.net Thu Jun 15 23:41:53 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 15 Jun 2000 23:41:53 +0200 Subject: [Python-Dev] Augmented assignment In-Reply-To: <39491CA2.2BDC0DDC@lemburg.com>; from mal@lemburg.com on Thu, Jun 15, 2000 at 08:12:50PM +0200 References: <20000615195327.R8000@xs4all.nl> <39491CA2.2BDC0DDC@lemburg.com> Message-ID: <20000615234153.S8000@xs4all.nl> On Thu, Jun 15, 2000 at 08:12:50PM +0200, M.-A. Lemburg wrote: > > I'd like some (minor) feedback on the augmented assignment thing I'm working > > on. I understand Guido is the only one who accepts patches like this, and > > appreciate that, but I'm hoping someone can at least tell me what I'm doing > > wrong so I can fix it before Guido sees it ;-) But if I'm being an impatient > > flap, just tell me so and I'll calm down. > I'd make this a 1.7 issue. 1.6 should go into the stabilization > phase and big complicated patches like yours should receive some > more design and concept discussion before getting checked in. That's more or less what I figured, though I wasn't aware of the revised schedule on 1.6 ;) > BTW, with "augmented assign" I suppose you mean things like > a += 1 and b *= 2, right ? Yes; All binary operands, to be exact: '+=' | '-=' | '*=' | '/=' | '%=' | '&=' | '|=' | '^=' | '<<=' | '>>=' | '**=' > Any reason you can't do this with the existing op codes ? > > E.g. a += b > > 1. load a > 2. load b > 3. add > 4. store a Yes: It wouldn't be thread-safe, and it would be impossible (or at least very hard and complicated) to see the difference between 'a += b' and 'a = a + b', which would make it very hard to make them functionally different. The patch not only adds the syntax (Michael Hudsons' patch did that, roughly how you describe it) but also adds generic semantics for in-place operations on builtin types, extension types and classes. > > * The patch also needs to add 11 new __hooks__, 11 new API calls, 11 new entries > > in the PyNumberMethods struct and 2 new entries in the PySequenceMethods > > struct. Would that conceivably be a problem ? I've heard people on the > > python-list complain about this ;-P > More generic solutions are usually more accepted. I thought so, but I didn't see a good, simple addition to the API that wasn't too complicated. What it adds now is 'PyNumber_InPlaceAdd()', which is functionally the same as 'PyNumber_Add()', except that the left-hand-side object is given the chance to define the operation in-place. That's also where the new PyNumberMethods/PySequenceMethods members come in. > BTW, before hacking too much into this, you ought to consider > that we are planning for rich comparisons and decentralized > coercion in 1.7 (this was planned for 1.6, but David and I > got carried away with other things). Too late. Most, if not all, of the patch is already written. Not that that's a reason to accept it, not at all ;) > I wouldn't want to have to hack 11 new slots to get this right... I'm not sure if that's necessary, but I'll have to look into your comparison/coercion work before I can say that for sure. In any case, I'd be perfectly happy with adjusting the augmented-assignment patch to the comparison/coercion change, instead of the other way 'round ;) > > * Should I start sending the patch, in pieces, to the patches-list, or is > > it a wasted effort because noone will touch it until Guido is back ? If I > > should send it, should I send it in one large patch (minus autogenerated > > files) or in nice functionality-sized pieces ? > Better put it on a web page and inform python-dev of new features, > enhancements, etc. The webpage is already there, with the version I sent to python-list last Friday. That patch is missing quite a few things, but it serves as an example of what it should do: http://www.xs4all.nl/~thomas/python/ I hope to upload an almost-finished version tomorrow morning (Amsterdam time) - if work doesn't intervene again. > > * How 'cool' does Guido actually think this syntax is ? Apparently the > > subject has come up a few times ;) and I got positive signals from both Tim > > and Guido, but if the patch won't go in as a patch, and won't actually be > > used other than some inspiration for a future rewrite of the CPython core, > > I'm not going to worry too much about the patch ;) > Having a patch is good for discussion, whether it gets incorporated > is a different issue ;-) Of course :) The thing is, the patch is actually quite done. What I'm doing now is more or less auditing and optimizing it, and that is probably a waste of time if the patch is going to need a complete rewrite anyway. On the other hand, I'm getting a couple of ideas for optimization of the 'normal' operations too, so it's not like it's wasted time. I guess I'll start a new thread on that issue if/when I reach it ;) Thanx for the feedback! -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From pf at artcom-gmbh.de Thu Jun 15 23:30:45 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Thu, 15 Jun 2000 23:30:45 +0200 (MEST) Subject: [Python-Dev] Augmented assignment In-Reply-To: <20000615195327.R8000@xs4all.nl> from Thomas Wouters at "Jun 15, 2000 7:53:27 pm" Message-ID: Hi! Thomas Wouters: > I'd like some (minor) feedback on the augmented assignment thing I'm working > on. I understand Guido is the only one who accepts patches like this, and > appreciate that, but I'm hoping someone can at least tell me what I'm doing > wrong so I can fix it before Guido sees it ;-) But if I'm being an impatient > flap, just tell me so and I'll calm down. Disclaimer: The following is only *my* personal opinion. But since you have asked for it. ;-) I don't like this augmented assignment syntax at all! (independent from your particular implementation, which I didn't had a look at). Augmented assignments are unPythonic because they don't add any new functionality to the language. From what I've seen, all people, who ever missed it, were experienced C-programmers. And C shows its inheritance from various assembler languages in its augmented assignment and its ++pre and post increment++ and decrement-- operators. Many of these features were born in the 70s of the last century: At that time optimizing was very important and compilers were relatively dumb. This applies in no way to the situation we have today with Python. What remains is, that augmented assignments are only a short cut notation, which introduces more variability to express the same algorithms and so they hurt readability. This feature must be learned additionally, where normal assignment are easiely understood from school mathematics. It also introduces many more possibilities to make subtle mistakes, since it is not obvious (at least to No-C-programmers) when and how often the index expression will be valuated. Look at the following example: class Bar: def __init__(self): self.val = 0 def __call__(self): self.val = self.val + 1 return self.val bar = Bar() foo = range(4) and than foo[bar()] = foo[bar()] + bar() print foo versus foo[bar()] += bar() print foo Todays Python forces the programmer to explicitly say, what should happen. So I think these +=,-=,*= features are evil. In the same sense as macro preprocessors are evil in 'C' and 'from module import *' is already evil in Python. Add more and more of this stuff and you end up on the dark side of programming. If augmented assignments will ever become part of Python, I would at least like to see a strong recommendation added to the styleguide not to use this feature. Enough with this rant. Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen) From nascheme at enme.ucalgary.ca Fri Jun 16 00:26:35 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Thu, 15 Jun 2000 16:26:35 -0600 Subject: [Python-Dev] Augmented assignment In-Reply-To: ; from pf@artcom-gmbh.de on Thu, Jun 15, 2000 at 11:30:45PM +0200 References: <20000615195327.R8000@xs4all.nl> Message-ID: <20000615162635.B11507@acs.ucalgary.ca> On Thu, Jun 15, 2000 at 11:30:45PM +0200, Peter Funk wrote: > Augmented assignments are unPythonic because they don't add any new > functionality to the language. [...] > foo[bar()] = foo[bar()] + bar() > versus > foo[bar()] += bar() Not quite. I think with the proposed implementation += could modify the LHS object in place. This could be a big performance win for things like NumPy objects. OTOH, the same effect can be achieved with a method call: foo[bar()].add(bar()) Neil From thomas at xs4all.net Fri Jun 16 00:25:23 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 16 Jun 2000 00:25:23 +0200 Subject: [Python-Dev] Augmented assignment In-Reply-To: ; from pf@artcom-gmbh.de on Thu, Jun 15, 2000 at 11:30:45PM +0200 References: <20000615195327.R8000@xs4all.nl> Message-ID: <20000616002523.T8000@xs4all.nl> On Thu, Jun 15, 2000 at 11:30:45PM +0200, Peter Funk wrote: > Thomas Wouters: > > I'd like some (minor) feedback on the augmented assignment thing I'm working > > on. I understand Guido is the only one who accepts patches like this, and > > appreciate that, but I'm hoping someone can at least tell me what I'm doing > > wrong so I can fix it before Guido sees it ;-) But if I'm being an impatient > > flap, just tell me so and I'll calm down. > I don't like this augmented assignment syntax at all! (independent > from your particular implementation, which I didn't had a look at). > Augmented assignments are unPythonic because they don't add any new > functionality to the language. [ snip quite good summary of the problems with augmented assignment ] I agree with almost all of the above, except the statement that they do not add anything. If augmented assignment was only syntactic sugar I would not have taken Michael's patch and rewritten it; I do not propose auto-increment operators, and would have a hard time accepting them. However, augmented assignment *does* add new functionality, because it is a way to inform the object that is being operated on, that it can do the operation in-place if it so wants. Instead of having to create a new object, which might be costly in cpu and/or memory, and doing the operation on that, the object can choose to do the operation on itself, and return 'self'. If the object doesn't want to do that, it doesn't have to be any different from 'x = x + 1'. (In fact, augmented assignment should, and does, fall back to that.) > > > [ snip good example of indexes-with-sideffect ] > > This actually proves the point of augmented assignment. With the syntax foo[bar()] += 1 You can see that bar() is only called once, so you *know* what index is being retrieved, and that the new value is stored in the same place. Using foo[bar()] = foo[bar()] + 1 you can't see by the expression which value is being retrieved and where the result is stored. You have to remember the rules about operand evaluation to see that. Yes, foo[bar()] += bar() is indeed more complicated than the above example, but absolutely not more complicated than the normal-add version that calls bar() three times. The augmented assignment syntax is actually clearer and more easy to explain, in my opinion. You can only (accurately) explain a = a + 1 as 'add a and 1, and store the result in a'. However, a += 1 is simply 'add 1 to a'. > So I think these +=,-=,*= features are evil. In the same sense as macro > preprocessors are evil in 'C' and 'from module import *' is already evil > in Python. Add more and more of this stuff and you end up on the dark > side of programming. Well, I like the odd Star Wars film, but I do not believe that the Dark Side lies opposite the Right Way. The Right Way can't help but be very close to the Dark Side. You may dislike macro preprocessors in C, but CPython (and almost all other C code) do use them alot, for functionality which would otherwise be very hard (or complicated and unreadable) to achieve. The same goes for 'from module import *' in Python. The funny thing is that augmented assignment operators and auto in/decrement operators might be added to C because they were easier to optimize (I dont think that was the main reason, but I wasn't there ;) but any halfway decent C compiler doesn't need that explicitness, and can optimize the 'x = x + 1' expression directly. Python, however, can (currently) not do that, and *does* need the added syntax to be able to do optimization, even if only to let the object know it's safe to operate on itself. Of course, once there are semantics for inplace-operations, it _might_ be possible to optimize 'x = x + 1' into 'x += 1' ;) > If augmented assignments will ever become part of Python, I would at least > like to see a strong recommendation added to the styleguide not to use > this feature. If such a recommendation was added, the change would be useless. Better get Guido to not add this feature instead, or Python will end up like Perl ;) I honestly do not care much wether it gets added or not. If Guido decides not to add it, I'm certain he has very valid rasons for it, and I dont assume to know as much about Python, the applicability of Python, the average usage of Python or the Future of Python as he sees it, as him ;) I-don't-know-any-of-that-in-fact-ly y'rs ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From gmcm at hypernet.com Fri Jun 16 02:44:38 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Thu, 15 Jun 2000 20:44:38 -0400 Subject: [Python-Dev] Augmented assignment In-Reply-To: References: <20000615195327.R8000@xs4all.nl> from Thomas Wouters at "Jun 15, 2000 7:53:27 pm" Message-ID: <1251006162-53585376@hypernet.com> Peter Funk wrote: > Augmented assignments are unPythonic because they don't add any > new functionality to the language. Most changes to Python are nothing but syntactic sugar. In concept, I'm +0.9 on simple "name += val". I'm -0.9 on "expr += val" if the behavior requires an understanding of Python internals, and +0 otherwise (since I avoid "expr = expr + val" if possible). Thomas's statement that the complexity is largely due to problems of thread safety is eminently believable, and I doubt that the syntactic sugar (which is at least somewhat desirable) is worth the price. > .... Many of these features were born in the > 70s of the last century: At that time optimizing was very > important and compilers were relatively dumb. This applies in no > way to the situation we have today with Python. Actually, Python's compiler is very dumb, and optimization is still important. So where I would use "expr" 3 times in 3 lines in C / C++ and *expect* the compiler to optimize it into one evaluation, I have to remind myself to use an extra line and compute it once in Python myself. One might argue that that's unPythonic, because it inhibits the direct expression of the idea. One might, but I won't. > What remains is, that augmented assignments are only a short cut > notation, which introduces more variability to express the same > algorithms and so they hurt readability. It definitely *improves* the readability of incrementing very-long- expression. Just not to the point of readability ;-). > ... It also introduces many more > possibilities to make subtle mistakes, and eliminates othes, such as typos... > since it is not obvious > (at least to No-C-programmers) when and how often the index > expression will be valuated. Look at the following example: > > class Bar: > def __init__(self): > self.val = 0 > def __call__(self): > self.val = self.val + 1 > return self.val > bar = Bar() > foo = range(4) > and than > foo[bar()] = foo[bar()] + bar() > print foo > versus > foo[bar()] += bar() > print foo To understand the first requires a sufficiently deep understanding of how Python works that I doubt the 2nd is really much worse. They're both the other side of horrid. I don't care very much myself, but none of these arguments are without strong counters (which we've all read many times on c.l.py). The only real basis, I think, is whether the changes complexify things too much. - Gordon From pf at artcom-gmbh.de Fri Jun 16 09:11:57 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Fri, 16 Jun 2000 09:11:57 +0200 (MEST) Subject: [Python-Dev] Augmented assignment In-Reply-To: <1251006162-53585376@hypernet.com> from Gordon McMillan at "Jun 15, 2000 8:44:38 pm" Message-ID: Hi, [...] [me]: > > What remains is, that augmented assignments are only a short cut > > notation, which introduces more variability to express the same > > algorithms and so they hurt readability. [Gordon McMillan]: > It definitely *improves* the readability of incrementing very-long- > expression. Just not to the point of readability ;-). I agree, that very complicated multidimensional expressions, (possible mixing tuples, lists, dicts and computations) are even more errorprone , if you have to repeat them twice just to increment an element. But than you would use an helper variable to hold the index expression anyway. example: foo = range(3); bar = range(3); cols = ('red', 'green', 'blue') chans = {'red':2, 'green':1, 'blue':0} foo[chans[cols[2-bar[0]]]] = foo[chans[cols[2-bar[0]]]] + 1 is indeed ugly. But i = chans[cols[2-bar[0]]]; foo[i] = foo[i] + 1 is at least just as (un)readable as foo[chans[cols[bar[0]]]] += 1 with the exception, that even newbies get a chance to figure out, what the former line is supposed to do without having to read a language reference manual telling them something about augmented assignments. But you are right: This has been discussed often enough on c.l.p. Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen) From effbot at telia.com Fri Jun 16 18:24:26 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 16 Jun 2000 18:24:26 +0200 Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface? Message-ID: <000a01bfd7af$582a9ea0$f2a6b5d4@hagrid> (the eff-bot is back!) is there any special reason for this restriction: Python 1.6a2 (#0, Jun 14 2000, 23:07:49) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> a = [1, 2, 3] >>> a.extend((4, 5, 6)) Traceback (most recent call last): File "", line 1, in ? TypeError: list.extend() argument must be a list from the look of it, it should be trivial to change list.extend to use the abstract sequence API instead of the list API. has anyone benchmarked the abstract sequence API? how much slower is it? would it be a good idea to treat lists as a special case, to avoid slowing down existing code? other comments? if I don't hear anything, I'll post patches later this weekend. From effbot at telia.com Fri Jun 16 18:41:36 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 16 Jun 2000 18:41:36 +0200 Subject: [Python-Dev] possible Tkinter speedup Message-ID: <001401bfd7b1$bdf9a120$f2a6b5d4@hagrid> the _flatten method in Tkinter is one of the major performance bottlenecks for Python/Tk programmers. the method "flattens" a nested sequence, by repeatedly adding tuples to each other. obviously, this isn't very efficient if the sequences are longer than, say, five to ten items... and has of course led to claims like "wxPython is a thousand times faster than Tkinter". anyway, taking recent changes to Python into account, it should be possible to speed this up quite a bit. the old code looked like this: def _flatten(tuple): res = () for item in tuple: if type(item) in (TupleType, ListType): res = res + _flatten(item) elif item is not None: res = res + (item,) return res after a some trials and errors, here's my proposed replacement: def _flatten1(seq): res = [] for item in seq: if type(item) in (TupleType, ListType): res.extend(_flatten1(item)) elif item is not None: res.append(item) return res def _flatten(seq): return tuple(_flatten1(seq)) in my tests, this is slighly faster on very short sequences (two coordinate pairs, which is a common case for e.g. rectangles), and much faster on long sequences (polylines, polygons). for example, for a 5000-point line, it's about 15 times faster. on a 10,000 point line, it's over 50 times faster. etc. comments? can anyone come up with an even faster way to do this? if I don't hear anything negative, I'll post patches (etc) PS. even after this optimization, uiToolkit is still about 100 times faster than Tkinter, but that's another story ;-) From effbot at telia.com Fri Jun 16 18:47:01 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 16 Jun 2000 18:47:01 +0200 Subject: [Python-Dev] Q: is concatenation and append really the same thing? Message-ID: <001e01bfd7b2$7fc91ba0$f2a6b5d4@hagrid> Python 1.6a2 (#0, Jun 14 2000, 23:07:49) [MSC 32 bit (Intel)] on win32 >>> (1, 2, 3) + [1, 2, 3] Traceback (most recent call last): File "", line 1, in ? TypeError: can only append tuple (not "list") to tuple is "append" really the right word here? sure confused the hell out of yours truly... ("there's no friggin' append call in this code") From jeremy at beopen.com Fri Jun 16 18:45:07 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 16 Jun 2000 12:45:07 -0400 (EDT) Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface? In-Reply-To: <000a01bfd7af$582a9ea0$f2a6b5d4@hagrid> References: <000a01bfd7af$582a9ea0$f2a6b5d4@hagrid> Message-ID: <14666.22931.521438.936776@localhost.localdomain> >>>>> "FL" == Fredrik Lundh writes: FL> has anyone benchmarked the abstract sequence API? how much FL> slower is it? would it be a good idea to treat lists as a FL> special case, to avoid slowing down existing code? The abstract interface is fairly expensive. The current code uses PyList_GET_ITEM to access the elements of the list. The abstract interface adds two function calls (PySequence_GetItem, PyList_GetItem). The first function just does a couple of sanity checks (verify arg is sequence & that it has get_item). The second function verifies that the arg is a list, then does a bounds check. None of the work that either of these functions does is necessary for the list case! In the extended call syntax implementation, I used PySequence_Tuple to handle non-standard sequences. Once converted to a tuple, they can be processed using the macros. If you support user-defined sequences, the sanity checking can get pretty hairy if you don't coerce to a tuple; e.g. the PySequence_Length method can lie! I don't remember considering the cost of allocating the new tuple, which is only used internally. Jeremy From thomas at xs4all.net Fri Jun 16 18:45:14 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 16 Jun 2000 18:45:14 +0200 Subject: [Python-Dev] Augmented assignment, update Message-ID: <20000616184514.Q26436@xs4all.nl> I've more or less finished the augmented-assignment patch I posted last week. It can be found, including a longish explanation, here: http://www.xs4all.nl/~thomas/python/ (For those who missed it, the previous posting is here: http://www.python.org/pipermail/python-list/2000-June/060680.html The link in the posting, however, points to the new patch.) I do not know if augmented assignment will every be incorporated into Python (this patch or something entirely different) but at least noone can claim the groundwork is missing :-) Feel free to send questions, comments and verbal abuse my way ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mwh21 at cam.ac.uk Fri Jun 16 18:53:42 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 16 Jun 2000 17:53:42 +0100 Subject: [Python-Dev] Q: is concatenation and append really the same thing? In-Reply-To: "Fredrik Lundh"'s message of "Fri, 16 Jun 2000 18:47:01 +0200" References: <001e01bfd7b2$7fc91ba0$f2a6b5d4@hagrid> Message-ID: "Fredrik Lundh" writes: > Python 1.6a2 (#0, Jun 14 2000, 23:07:49) [MSC 32 bit (Intel)] on win32 > >>> (1, 2, 3) + [1, 2, 3] > Traceback (most recent call last): > File "", line 1, in ? > TypeError: can only append tuple (not "list") to tuple > > is "append" really the right word here? My fault. I have sent at least one patch to patches at python.org to change it to can only concatenate tuple (not "list") to tuple to bring it into line with listobject.c; here it is again: Index: Objects/tupleobject.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Objects/tupleobject.c,v retrieving revision 2.34 diff -u -r2.34 tupleobject.c --- Objects/tupleobject.c 2000/06/01 03:12:13 2.34 +++ Objects/tupleobject.c 2000/06/06 16:30:39 @@ -362,7 +362,7 @@ PyTupleObject *np; if (!PyTuple_Check(bb)) { PyErr_Format(PyExc_TypeError, - "can only append tuple (not \"%.200s\") to tuple", + "can only concatenate tuple (not \"%.200s\") to tuple", bb->ob_type->tp_name); return NULL; } HTH, HAND, Michael From mal at lemburg.com Fri Jun 16 18:53:59 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 16 Jun 2000 18:53:59 +0200 Subject: [Python-Dev] possible Tkinter speedup References: <001401bfd7b1$bdf9a120$f2a6b5d4@hagrid> Message-ID: <394A5BA7.F001E220@lemburg.com> Fredrik Lundh wrote: > > the _flatten method in Tkinter is one of the major performance > bottlenecks for Python/Tk programmers. the method "flattens" > a nested sequence, by repeatedly adding tuples to each other. > > obviously, this isn't very efficient if the sequences are longer > than, say, five to ten items... and has of course led to claims > like "wxPython is a thousand times faster than Tkinter". > > anyway, taking recent changes to Python into account, it should > be possible to speed this up quite a bit. > > the old code looked like this: > > def _flatten(tuple): > res = () > for item in tuple: > if type(item) in (TupleType, ListType): > res = res + _flatten(item) > elif item is not None: > res = res + (item,) > return res > > after a some trials and errors, here's my proposed replacement: > > def _flatten1(seq): > res = [] > for item in seq: > if type(item) in (TupleType, ListType): > res.extend(_flatten1(item)) > elif item is not None: > res.append(item) > return res > > def _flatten(seq): > return tuple(_flatten1(seq)) > > in my tests, this is slighly faster on very short sequences (two > coordinate pairs, which is a common case for e.g. rectangles), > and much faster on long sequences (polylines, polygons). > > for example, for a 5000-point line, it's about 15 times faster. > on a 10,000 point line, it's over 50 times faster. etc. > > comments? Why not implement this in C and add it to _tkinter.c ? It might even make a nice standard builtin... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fdrake at beopen.com Fri Jun 16 19:02:22 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 16 Jun 2000 13:02:22 -0400 (EDT) Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface? In-Reply-To: <000a01bfd7af$582a9ea0$f2a6b5d4@hagrid> References: <000a01bfd7af$582a9ea0$f2a6b5d4@hagrid> Message-ID: <14666.23966.437909.949260@cj42289-a.reston1.va.home.com> Fredrik Lundh writes: > if I don't hear anything, I'll post patches later this weekend. Sounds good to me! If lists and tuples are special cased, it shouldn't even matter if the sequence API is too slow -- that's new functionality for [].extend(), and can be optimized later if it needs to be. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From mal at lemburg.com Fri Jun 16 19:07:40 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 16 Jun 2000 19:07:40 +0200 Subject: [Python-Dev] Q: is concatenation and append really the same thing? References: <001e01bfd7b2$7fc91ba0$f2a6b5d4@hagrid> Message-ID: <394A5EDC.7431C900@lemburg.com> Michael Hudson wrote: > > "Fredrik Lundh" writes: > > > Python 1.6a2 (#0, Jun 14 2000, 23:07:49) [MSC 32 bit (Intel)] on win32 > > >>> (1, 2, 3) + [1, 2, 3] > > Traceback (most recent call last): > > File "", line 1, in ? > > TypeError: can only append tuple (not "list") to tuple > > > > is "append" really the right word here? > > My fault. I have sent at least one patch to patches at python.org to > change it to > > can only concatenate tuple (not "list") to tuple > > to bring it into line with listobject.c; here it is again: > > Index: Objects/tupleobject.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Objects/tupleobject.c,v > retrieving revision 2.34 > diff -u -r2.34 tupleobject.c > --- Objects/tupleobject.c 2000/06/01 03:12:13 2.34 > +++ Objects/tupleobject.c 2000/06/06 16:30:39 > @@ -362,7 +362,7 @@ > PyTupleObject *np; > if (!PyTuple_Check(bb)) { > PyErr_Format(PyExc_TypeError, > - "can only append tuple (not \"%.200s\") to tuple", > + "can only concatenate tuple (not \"%.200s\") to tuple", > bb->ob_type->tp_name); > return NULL; > } > Should be in CVS by now... Thanks, -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fdrake at beopen.com Fri Jun 16 19:13:55 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 16 Jun 2000 13:13:55 -0400 (EDT) Subject: [Python-Dev] mailbox formats Message-ID: <14666.24659.9174.717901@cj42289-a.reston1.va.home.com> I've been playing with a function to open a mailbox and return the appropriate type of mailbox object from the mailbox module, but I don't have examples of anything but mbox style mailboxes to test with. Could anyone send real examples of MMDF, MH, maildir, and Babyl mailboxes? The mail can be junk; don't send anything I shouldn't see! Essentially, I'd like to see two new functions added to the mailbox module: open('name'), which returns a mailbox object opened for reading, and which('name'), which returns the name of the mailbox constructor, and possibly a flag indicating whether a __builtin__.open() is needed. Thanks! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From mal at lemburg.com Fri Jun 16 20:59:39 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 16 Jun 2000 20:59:39 +0200 Subject: [Python-Dev] Announcment list Message-ID: <394A791B.17F5AEFF@lemburg.com> Does anybody know about the state of the python-announce mailing list ? I've sent an announcement there (about mxCGIPython), but have only received an error message and got no posting back from the list. I posted a note to the postmaster at beopen.com, but have heard nothing from there yet. Can somebody please look into this ?! BTW, what about the announcement list -> c.l.p.a gateway ? Will that happen anytime soon (or do I have to hack the headers to post there ? ;-) Here's the error message: """ Subject: failure notice Date: 13 Jun 2000 11:34:39 -0000 From: MAILER-DAEMON at starship.beopen.com To: mal at lemburg.com Hi. This is the qmail-send program at starship.beopen.com. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. : Sorry, no mailbox here by that name. (#5.1.1) --- Below this line is a copy of the message. Return-Path: Received: (qmail 31495 invoked from network); 13 Jun 2000 11:34:38 -0000 Received: from dinsdale.cnri.reston.va.us (HELO dinsdale.python.org) (132.151.1.21) by starship.beopen.com with SMTP; 13 Jun 2000 11:34:38 -0000 Received: by dinsdale.python.org (Postfix) id AD6DD1CDE3; Tue, 13 Jun 2000 07:29:56 -0400 (EDT) Delivered-To: python-announce-people at python.org ... """ -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From bwarsaw at python.org Fri Jun 16 21:24:21 2000 From: bwarsaw at python.org (Barry A. Warsaw) Date: Fri, 16 Jun 2000 15:24:21 -0400 (EDT) Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface? References: <000a01bfd7af$582a9ea0$f2a6b5d4@hagrid> <14666.23966.437909.949260@cj42289-a.reston1.va.home.com> Message-ID: <14666.32485.172984.122789@anthem.concentric.net> >>>>> "Fred" == Fred L Drake, Jr writes: Fred> Sounds good to me! If lists and tuples are special cased, Fred> it shouldn't even matter if the sequence API is too slow -- Fred> that's new functionality for [].extend(), and can be Fred> optimized later if it needs to be. This has been a typical implementation strategy for a long while now, and I think successfully so. When I removed the distinction between list and tuple unpacking to allow any sequence unpacking (and incidently w/o special syntax), I did exactly this. Special case for tuples and lists, and if it was neither then use the sequence API. Jeremy's right that this can get hairy if your as anal as I am about error checking and refcounting. In addition to PySequence_Length() ability to lie, there are all sorts of errors that can happen, which should abort the whole process and clean up any temporary objects. Plus you've now got three very similar branches in the code, which adds its own overhead. So you should decide whether this situation will be used widely enough to warrant the extra coding complexity for the performance win. list.extend() is probably not used too often these days, but it should be 'cause it's cool. So maybe it's worth it in this case. On the other hand, this is a situation that comes up often, and if we were to really audit the APIs, we'd probably find even more cases where restrictions to concrete lists or tuples should be relaxed to accept any sequence. Maybe there's a way we can factor this out in a single function which handles this once and for all? -Barry From paul at prescod.net Fri Jun 16 21:22:08 2000 From: paul at prescod.net (Paul Prescod) Date: Fri, 16 Jun 2000 21:22:08 +0200 Subject: [Python-Dev] Augmented assignment References: Message-ID: <394A7E60.6F715424@prescod.net> Many people have given examples where the augmented assignment version is substantially more readable. Others have argued that it is more explicit in that it says *exactly what you mean* rather than using a more general operator in a specific (common) situation. Another important argument is that augmented assignment allows *in place* assignment for some types. That's really important for matrix math etc. All of these arguments convince me that this is not a simple matter of "another notation for what we already do." > Augmented assignments are unPythonic because they don't add any new > functionality to the language. From what I've seen, all people, > who ever missed it, were experienced C-programmers. That's true, but we should not be ashamed to steal good ideas from other languages. Probably the only people who would miss __getattr__ would be SmallTalk programmers and the original proponents of the various operator overloading features may well have come from C++. > ... > This feature must be learned > additionally, where normal assignment are easiely understood from > school mathematics. Not really! a=a+1 is totally illegal in basic arithmetic. > It also introduces many more possibilities to make > subtle mistakes, since it is not obvious (at least to No-C-programmers) > when and how often the index expression will be valuated. As I understand the proposal, the function will be called exactly as many times as it is printed in the source code: > versus > foo[bar()] += bar() > print foo Presumably bar() gets called twice. The only argument against this that is persusaive to me is that it makes the core Python language larger and thus a (little) harder to learn. My impression is that the design of the feature has been well done. My personal opinion is that the cost in education probably outweighs the benefits in clarity but others who work a lot with matrices etc. would probably have a different view. -- Paul Prescod - ISOGEN Consulting Engineer speaking for himself "Music is the stuff between the notes." - Claude Debussy From petrilli at amber.org Fri Jun 16 21:42:46 2000 From: petrilli at amber.org (Christopher Petrilli) Date: Fri, 16 Jun 2000 15:42:46 -0400 Subject: [Python-Dev] Augmented assignment In-Reply-To: <394A7E60.6F715424@prescod.net>; from paul@prescod.net on Fri, Jun 16, 2000 at 09:22:08PM +0200 References: <394A7E60.6F715424@prescod.net> Message-ID: <20000616154246.A5513@trump.amber.org> Paul Prescod [paul at prescod.net] wrote: > That's true, but we should not be ashamed to steal good ideas from other > languages. Probably the only people who would miss __getattr__ would be > SmallTalk programmers and the original proponents of the various > operator overloading features may well have come from C++. Actually as a good Talker, I write methods for everything, so I almost nver use __getattr__ except as a way to force people to use methods and not directly access attributes. Long story. Chris -- | Christopher Petrilli | petrilli at amber.org From fdrake at beopen.com Fri Jun 16 21:42:12 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 16 Jun 2000 15:42:12 -0400 (EDT) Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface? In-Reply-To: <14666.32485.172984.122789@anthem.concentric.net> References: <000a01bfd7af$582a9ea0$f2a6b5d4@hagrid> <14666.23966.437909.949260@cj42289-a.reston1.va.home.com> <14666.32485.172984.122789@anthem.concentric.net> Message-ID: <14666.33556.123258.252030@cj42289-a.reston1.va.home.com> Barry A. Warsaw writes: > Jeremy's right that this can get hairy if your as anal as I am about > error checking and refcounting. In addition to PySequence_Length() > ability to lie, there are all sorts of errors that can happen, which > should abort the whole process and clean up any temporary objects. > Plus you've now got three very similar branches in the code, which > adds its own overhead. > > So you should decide whether this situation will be used widely enough > to warrant the extra coding complexity for the performance win. > list.extend() is probably not used too often these days, but it should > be 'cause it's cool. So maybe it's worth it in this case. > > On the other hand, this is a situation that comes up often, and if we > were to really audit the APIs, we'd probably find even more cases > where restrictions to concrete lists or tuples should be relaxed to > accept any sequence. Maybe there's a way we can factor this out in a > single function which handles this once and for all? How about this: special case the list & tuple flavors (since that'll be roughly what's in there now), and for other sequences, convert to either a tuple or a list and let it pass through that special case, keeping a flag to discard the temporary list when done? There are two APIs, PySequence_List() and PySequence_Tuple(), which can take care of a lot of the machinery in dealing with sequences that lie about their length or otherwise break (during __getitem__() calls or whatever), that a large part of the work is done. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From mal at lemburg.com Fri Jun 16 21:45:16 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 16 Jun 2000 21:45:16 +0200 Subject: [Python-Dev] Augmented assignment References: <394A7E60.6F715424@prescod.net> Message-ID: <394A83CC.98F177DC@lemburg.com> Paul Prescod wrote: > > Augmented assignments are unPythonic because they don't add any new > > functionality to the language. From what I've seen, all people, > > who ever missed it, were experienced C-programmers. > > That's true, but we should not be ashamed to steal good ideas from other > languages. Probably the only people who would miss __getattr__ would be > SmallTalk programmers and the original proponents of the various > operator overloading features may well have come from C++. Don't forget the crowd of people doing environmental acquisition (you know who they are ;-). Honestly, I think that __getattr__ is one of the most useful hooks available on Python objects. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From jeremy at beopen.com Fri Jun 16 22:01:18 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 16 Jun 2000 16:01:18 -0400 (EDT) Subject: [Python-Dev] Augmented assignment In-Reply-To: <394A83CC.98F177DC@lemburg.com> References: <394A7E60.6F715424@prescod.net> <394A83CC.98F177DC@lemburg.com> Message-ID: <14666.34702.801826.453565@localhost.localdomain> I'm leery of acquisition, but we gotta have __getattr__. Jeremy >>>>> "MAL" == M -A Lemburg writes: MAL> Paul Prescod wrote: >> > Augmented assignments are unPythonic because they don't add any >> > new functionality to the language. From what I've seen, all >> > people, who ever missed it, were experienced C-programmers. >> >> That's true, but we should not be ashamed to steal good ideas >> from other languages. Probably the only people who would miss >> __getattr__ would be SmallTalk programmers and the original >> proponents of the various operator overloading features may well >> have come from C++. MAL> Don't forget the crowd of people doing environmental MAL> acquisition (you know who they are ;-). MAL> Honestly, I think that __getattr__ is one of the most useful MAL> hooks available on Python objects. From fdrake at beopen.com Fri Jun 16 23:44:05 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 16 Jun 2000 17:44:05 -0400 (EDT) Subject: [Python-Dev] possible Tkinter speedup In-Reply-To: <394A5BA7.F001E220@lemburg.com> References: <001401bfd7b1$bdf9a120$f2a6b5d4@hagrid> <394A5BA7.F001E220@lemburg.com> Message-ID: <14666.40869.331831.90682@cj42289-a.reston1.va.home.com> M.-A. Lemburg writes: > Why not implement this in C and add it to _tkinter.c ? I think this is the right approach; do you have an implementation? ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From effbot at telia.com Fri Jun 16 23:50:58 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 16 Jun 2000 23:50:58 +0200 Subject: [Python-Dev] possible Tkinter speedup References: <001401bfd7b1$bdf9a120$f2a6b5d4@hagrid> <394A5BA7.F001E220@lemburg.com> Message-ID: <015e01bfd7dc$f53daca0$f2a6b5d4@hagrid> mal wrote: > > for example, for a 5000-point line, it's about 15 times faster. > > on a 10,000 point line, it's over 50 times faster. etc. > > > > comments? > > Why not implement this in C and add it to _tkinter.c ? > It might even make a nice standard builtin... bang for the buck? getting a working C version is a whole lot of work, and I'd rather spend that time on things that can speed things up a whole lot more [1]. but if it's still raining tomorrow... 1) http://w1.132.telia.com/~u13208596/tkinter From effbot at telia.com Sat Jun 17 00:33:43 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 17 Jun 2000 00:33:43 +0200 Subject: [Python-Dev] possible Tkinter speedup References: <001401bfd7b1$bdf9a120$f2a6b5d4@hagrid> <394A5BA7.F001E220@lemburg.com> <015e01bfd7dc$f53daca0$f2a6b5d4@hagrid> Message-ID: <017101bfd7e2$f2d3a2c0$f2a6b5d4@hagrid> eff-bot wrote: > bang for the buck? > > getting a working C version is a whole lot of work okay, I just proved that I don't know what I'm talking about. it wasn't that hard, and the performance boost is rather interesting... for 5000 vertices: Tkinter 1.6: 10.44 seconds Tkinter 1.6 with new flatten: 0.27 seconds Tkinter 1.6 with C version of flatten: 2.57 milliseconds patch follows. From effbot at telia.com Sat Jun 17 09:55:16 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 17 Jun 2000 09:55:16 +0200 Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface? References: <000a01bfd7af$582a9ea0$f2a6b5d4@hagrid> <14666.22931.521438.936776@localhost.localdomain> Message-ID: <003501bfd831$8bb11a60$f2a6b5d4@hagrid> jeremy wrote: > FL> has anyone benchmarked the abstract sequence API? how much > FL> slower is it? would it be a good idea to treat lists as a > FL> special case, to avoid slowing down existing code? > > The abstract interface is fairly expensive. The current code uses > PyList_GET_ITEM to access the elements of the list. The abstract > interface adds two function calls (PySequence_GetItem, > PyList_GetItem). The first function just does a couple of sanity > checks (verify arg is sequence & that it has get_item). The second > function verifies that the arg is a list, then does a bounds check. > None of the work that either of these functions does is necessary for > the list case! just for the record, I just changed some generic sequence code to something like: if (PyList_Check(seq) || PyTuple_Check(seq)) Py_INCREF(seq); else if (PySequence_Check(seq)) { seq = PySequence_Tuple(seq); if (!seq) return NULL; } else { PyErr_SetString(PyExc_TypeError, "argument must be a sequence"); return NULL; } ... allocate PyObject_Length(seq) slots ... if (PyList_Check(seq)) ... list code using PyList_GET_ITEM else ... tuple code using PyTuple_GET_ITEM Py_DECREF(seq); for the standard case (lists, in this case), this resulted in a total speedup of 4 times (this includes some other overhead). so in other words, this construct is more than 4 times faster than plain use of PySequence_GetItem. guess it's time to fix a couple of things in PIL... From mhammond at skippinet.com.au Sat Jun 17 10:16:18 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sat, 17 Jun 2000 18:16:18 +1000 Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface? In-Reply-To: <003501bfd831$8bb11a60$f2a6b5d4@hagrid> Message-ID: /F: > just for the record, I just changed some generic sequence code > to something like: ... > so in other words, this construct is more than 4 times faster > than plain use of PySequence_GetItem. Good stuff! > guess it's time to fix a couple of things in PIL... Its a fair bit of code to duplicate everywhere you want the speed increase. How can we add a similar scheme to the core, so the changes people need to make are trivial (to the point where the change is zero!)? Mark. From effbot at telia.com Sat Jun 17 10:40:20 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 17 Jun 2000 10:40:20 +0200 Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface? References: Message-ID: <006a01bfd837$ac689840$f2a6b5d4@hagrid> mark wrote: > > so in other words, this construct is more than 4 times faster > > than plain use of PySequence_GetItem. > > Good stuff! > > > guess it's time to fix a couple of things in PIL... > > Its a fair bit of code to duplicate everywhere you want the speed increase. > How can we add a similar scheme to the core, so the changes people need to > make are trivial (to the point where the change is zero!)? the first part is trivial; just add something like this to Objects/abstract.c: PyObject* PySequence_TupleOrList(PyObject* seq) { if (PyList_Check(seq) || PyTuple_Check(seq)) Py_INCREF(seq); else if (PySequence_Check(seq)) seq = PySequence_Tuple(seq); else { PyErr_SetString(PyExc_TypeError, "argument must be a sequence"); seq = NULL; } return seq; } the second parts is harder -- and that's of course where the real performance boost comes from. as far as I'm aware, very few C compilers can "specialize" loops for you... From mal at lemburg.com Sat Jun 17 10:41:25 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat, 17 Jun 2000 10:41:25 +0200 Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface? References: Message-ID: <394B39B5.B478720E@lemburg.com> Mark Hammond wrote: > > /F: > > just for the record, I just changed some generic sequence code > > to something like: > ... > > so in other words, this construct is more than 4 times faster > > than plain use of PySequence_GetItem. > > Good stuff! > > > guess it's time to fix a couple of things in PIL... > > Its a fair bit of code to duplicate everywhere you want the speed increase. > How can we add a similar scheme to the core, so the changes people need to > make are trivial (to the point where the change is zero!)? We could add special code the standard type to PySequence_GetItem() et al., but it would still cause a C function call (not much, but noticable in inner loops). How about adding some inline markers to the most often used (and small) routines in the medium level abstract interface (PySequence_*, PyMapping_*, etc.) ?! Together with the special code for the native Python types this should yield a speedup for all extensions by simple virtue of a recompile... OTOH, changes to these APIs would need a recompile of the extensions too. BTW, I've used the same approach as Fredrik in mx.Tools. It does make great a difference... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Sat Jun 17 10:53:20 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat, 17 Jun 2000 10:53:20 +0200 Subject: [Python-Dev] Re: [Python-bugs-list] PRIVATE: interned->ma_table never free'd (PR#361) References: <20000617000834.C29B41CF4A@dinsdale.python.org> Message-ID: <394B3C80.248B4CB1@lemburg.com> cfandrich at 8cs.com wrote: > > Full_Name: Christopher Fandrich > Version: 1.5.2 > OS: Windows > Submission from: (NULL) (208.41.174.4) > > I'm embedding Python in an application. For now, all I'm doing is initializing > and finalizing Python. > > When I run my app I get a memory leak of 12288 bytes. The memory is malloc'ed > by dictresize() which is called by PyDict_SetItem() which is called by > PyString_InternInPlace(). > > For now, I've added > PyDict_Clear(interned); > interned = NULL; > to PyString_Fini(). So far it works fine, but I don't know if it's safe to do > in the grand scheme of things. I would suggest adding code to dealloc the interned dict iff it is empty after the sweeping action in PyString_Fini(). I have a feeling that this is not the case though, since interned strings are used quite a lot in the core interpreter (e.g. in classobject.c) and these are usually not recovered. Perhaps we ought to add some code which takes care of cleaning up all remaining garbage left over after the call to call_ll_exitfuncs() in Py_Finalize(), e.g. force free'ing of all interned strings and cached ints/floats and associated free lists or dicts. We'd need new APIs in string|float|intobject.c to implement this. Thoughts ? Patches ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From effbot at telia.com Sat Jun 17 14:45:57 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 17 Jun 2000 14:45:57 +0200 Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface? References: <006a01bfd837$ac689840$f2a6b5d4@hagrid> Message-ID: <00d701bfd859$fd435300$f2a6b5d4@hagrid> the eff-bot wrote: > the first part is trivial; just add something like this to > Objects/abstract.c: > > PyObject* > PySequence_TupleOrList(PyObject* seq) > ... > > the second parts is harder -- and that's of course where the > real performance boost comes from. as far as I'm aware, very > few C compilers can "specialize" loops for you... in the same test setup, moving the PyList_Check inside the loop gives a 25-30% slowdown (or to look at it from the other side, 3 times instead of 4 times faster than naive code). a compromise solution could be to combine the above function with a macro: #define PySequence_TupleOrList_GET_ITEM(seq, index)\ (PyList_Check(seq) ? PyList_GET_ITEM(seq, index) :\ PyTuple_GET_ITEM(seq, index) (anyone got a better name? ;-) standard usage: seq = PySequence_TupleOrList(seq_in); size = PyObject_Length(seq); for (i = 0; i < size; i++) { PyObject* obj = PySequence_TupleOrList_GET_ITEM(seq, i); ... } comments? From mal at lemburg.com Sat Jun 17 16:18:26 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat, 17 Jun 2000 16:18:26 +0200 Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface? References: <006a01bfd837$ac689840$f2a6b5d4@hagrid> <00d701bfd859$fd435300$f2a6b5d4@hagrid> Message-ID: <394B88B2.EA116971@lemburg.com> Fredrik Lundh wrote: > > the eff-bot wrote: > > > the first part is trivial; just add something like this to > > Objects/abstract.c: > > > > PyObject* > > PySequence_TupleOrList(PyObject* seq) > > ... > > > > the second parts is harder -- and that's of course where the > > real performance boost comes from. as far as I'm aware, very > > few C compilers can "specialize" loops for you... > > in the same test setup, moving the PyList_Check inside the > loop gives a 25-30% slowdown (or to look at it from the other > side, 3 times instead of 4 times faster than naive code). > > a compromise solution could be to combine the above function > with a macro: > > #define PySequence_TupleOrList_GET_ITEM(seq, index)\ > (PyList_Check(seq) ? PyList_GET_ITEM(seq, index) :\ > PyTuple_GET_ITEM(seq, index) > > (anyone got a better name? ;-) > > standard usage: > > seq = PySequence_TupleOrList(seq_in); > > size = PyObject_Length(seq); > > for (i = 0; i < size; i++) { > PyObject* obj = PySequence_TupleOrList_GET_ITEM(seq, i); > ... > } > > comments? The above looks a lot like an iterator... how about providing a standard PySequence_Iterate(obj, callback) with the callback being called for every element of the sequence ?! The iterator could then be optimized for lists and tuples. Not as fast as inlining, but a more generic solution... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From effbot at telia.com Sat Jun 17 16:42:52 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 17 Jun 2000 16:42:52 +0200 Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface? References: <006a01bfd837$ac689840$f2a6b5d4@hagrid> <00d701bfd859$fd435300$f2a6b5d4@hagrid> <394B88B2.EA116971@lemburg.com> Message-ID: <010401bfd86a$5282cca0$f2a6b5d4@hagrid> mal wrote: > The above looks a lot like an iterator... how about > providing a standard PySequence_Iterate(obj, callback) > with the callback being called for every element of the > sequence ?! PySequence_Enumerate, perhaps? > The iterator could then be optimized for lists and tuples. > Not as fast as inlining, but a more generic solution... more generic than useful, imo: - it's slower. - it's awkward to use: you need to put the state in a structure, invert your program logic, etc. - it doesn't scale: what if you want to loop over two structures? what if you want to loop over two objects, using two different indices? From mal at lemburg.com Sat Jun 17 16:44:47 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat, 17 Jun 2000 16:44:47 +0200 Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface? References: <006a01bfd837$ac689840$f2a6b5d4@hagrid> <00d701bfd859$fd435300$f2a6b5d4@hagrid> <394B88B2.EA116971@lemburg.com> <010401bfd86a$5282cca0$f2a6b5d4@hagrid> Message-ID: <394B8EDF.57630FE9@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > The above looks a lot like an iterator... how about > > providing a standard PySequence_Iterate(obj, callback) > > with the callback being called for every element of the > > sequence ?! > > PySequence_Enumerate, perhaps? > > > The iterator could then be optimized for lists and tuples. > > Not as fast as inlining, but a more generic solution... > > more generic than useful, imo: > > - it's slower. > > - it's awkward to use: you need to put the state in a > structure, invert your program logic, etc. > > - it doesn't scale: what if you want to loop over two > structures? what if you want to loop over two objects, > using two different indices? Or perhaps, use a different iteration technique: the one used by PyDict_Next(). It doesn't need a callback, but instead plays with pointers you pass to it via output variables. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From effbot at telia.com Sat Jun 17 17:44:58 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 17 Jun 2000 17:44:58 +0200 Subject: [Python-Dev] proposal: core support for "fast" sequence iteration Message-ID: <011901bfd873$00632740$f2a6b5d4@hagrid> mark wrote: > Its a fair bit of code to duplicate everywhere you want the speed increase. > How can we add a similar scheme to the core, so the changes people need to > make are trivial (to the point where the change is zero!)? okay, here's my current proposal: PyObject* PySequence_Fast(PyObject *o) Return value: New reference. Returns the o as a tuple or a list on success, and NULL on failure. If o doesn't have the right type, it is converted to a tuple using PySequence_Tuple. This is equivalent to the following Python code: if type(o) in (ListType, TupleType): return o return tuple(o) This function is intended to be used together with PySequence_Fast_GET_ITEM, for functions that need to loop over a read-only sequence as fast as they possibly can, while still supporting any object that implements the sequence protocol. PyObject* PySequence_Fast_GET_ITEM(PyObject *seq, int i) Return value: Borrowed reference. Returns the object at position i, from the sequence seq (which must be a list or a tuple). This is a macro, and has no error checking. If you need error checking, use PySequence_GetItem. for the rationale, see my earlier posts in the "list.extend" thread. unless somebody comes up with a more efficient solution, I'll wrap this up together with the list.extend patch (first thing tomorrow). From gstein at lyra.org Sat Jun 17 22:52:31 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 17 Jun 2000 13:52:31 -0700 Subject: [Python-Dev] proposal: core support for "fast" sequence iteration In-Reply-To: <011901bfd873$00632740$f2a6b5d4@hagrid>; from effbot@telia.com on Sat, Jun 17, 2000 at 05:44:58PM +0200 References: <011901bfd873$00632740$f2a6b5d4@hagrid> Message-ID: <20000617135231.E29590@lyra.org> +1 coolness. On Sat, Jun 17, 2000 at 05:44:58PM +0200, Fredrik Lundh wrote: > mark wrote: > > > Its a fair bit of code to duplicate everywhere you want the speed increase. > > How can we add a similar scheme to the core, so the changes people need to > > make are trivial (to the point where the change is zero!)? > > okay, here's my current proposal: > > PyObject* PySequence_Fast(PyObject *o) > > Return value: New reference. > > Returns the o as a tuple or a list on success, and > NULL on failure. If o doesn't have the right type, > it is converted to a tuple using PySequence_Tuple. > > This is equivalent to the following Python code: > > if type(o) in (ListType, TupleType): > return o > return tuple(o) > > This function is intended to be used together with > PySequence_Fast_GET_ITEM, for functions that need > to loop over a read-only sequence as fast as they > possibly can, while still supporting any object that > implements the sequence protocol. > > PyObject* PySequence_Fast_GET_ITEM(PyObject *seq, int i) > > Return value: Borrowed reference. > > Returns the object at position i, from the sequence > seq (which must be a list or a tuple). This is a > macro, and has no error checking. > > If you need error checking, use PySequence_GetItem. > > for the rationale, see my earlier posts in the "list.extend" thread. > > unless somebody comes up with a more efficient solution, I'll wrap > this up together with the list.extend patch (first thing tomorrow). > > > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Sun Jun 18 00:37:26 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 17 Jun 2000 15:37:26 -0700 Subject: [Python-Dev] Re: [Python-bugs-list] PRIVATE: interned->ma_table never free'd (PR#361) In-Reply-To: <394B3C80.248B4CB1@lemburg.com>; from mal@lemburg.com on Sat, Jun 17, 2000 at 10:53:20AM +0200 References: <20000617000834.C29B41CF4A@dinsdale.python.org> <394B3C80.248B4CB1@lemburg.com> Message-ID: <20000617153726.H29590@lyra.org> On Sat, Jun 17, 2000 at 10:53:20AM +0200, M.-A. Lemburg wrote: >... > I would suggest adding code to dealloc the interned dict > iff it is empty after the sweeping action in PyString_Fini(). > I have a feeling that this is not the case though, since interned > strings are used quite a lot in the core interpreter (e.g. in > classobject.c) and these are usually not recovered. > > Perhaps we ought to add some code which takes care of cleaning > up all remaining garbage left over after the call to > call_ll_exitfuncs() in Py_Finalize(), e.g. force free'ing > of all interned strings and cached ints/floats and associated > free lists or dicts. > > We'd need new APIs in string|float|intobject.c to implement this. > > Thoughts ? Patches ? I would definitely like to see this, and suggested it to Guido about four years ago :-) During my threading work, I looked at all the globals, which includes the pools and the one-off allocations in classobject.c and friends. I figured it would be a Good Thing(tm) to write a general object pool API which could be used by tuples, floats, frames, etc. Having the single implementation of a pool would mean that we could add thread locks in a single place. Similarly, for cleanup reasons, I also suggested a general API for allocating the "constants" and torching them at shutdown. As we all know, though... suggestions don't mean crap. Code counts. :-) That said, I'll look into some of this with the free-threading work. That is all post-1.6, though. It would be great if somebody could do it before then. Cheers, -g -- Greg Stein, http://www.lyra.org/ From Vladimir.Marangozov at inrialpes.fr Sun Jun 18 01:01:30 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Sun, 18 Jun 2000 01:01:30 +0200 (CEST) Subject: [Python-Dev] Re: [Python-bugs-list] PRIVATE: interned->ma_table never free'd (PR#361) In-Reply-To: <20000617153726.H29590@lyra.org> from "Greg Stein" at Jun 17, 2000 03:37:26 PM Message-ID: <200006172301.BAA01642@python.inrialpes.fr> Greg Stein wrote: > > On Sat, Jun 17, 2000 at 10:53:20AM +0200, M.-A. Lemburg wrote: > >... > > Perhaps we ought to add some code which takes care of cleaning > > up all remaining garbage left over after the call to > > call_ll_exitfuncs() in Py_Finalize(), e.g. force free'ing > > of all interned strings and cached ints/floats and associated > > free lists or dicts. > > > > We'd need new APIs in string|float|intobject.c to implement this. > > > > Thoughts ? Patches ? > > I would definitely like to see this, and suggested it to Guido about four > years ago :-) > > During my threading work, I looked at all the globals, which includes the > pools and the one-off allocations in classobject.c and friends. I figured it > would be a Good Thing(tm) to write a general object pool API which could be > used by tuples, floats, frames, etc. Having the single implementation of a > pool would mean that we could add thread locks in a single place. > > Similarly, for cleanup reasons, I also suggested a general API for > allocating the "constants" and torching them at shutdown. > > As we all know, though... suggestions don't mean crap. Code counts. :-) pymalloc (the debugging stuff put aside) is an efficient implementation of this pool concept. The interface just needs to be exported under an appropriate PyObject_ API, not as a general malloc replacement. Maybe it needs some more work regarding finalization, but the code is there. Per pool locking is there too. Maybe it needs to be adjusted wrt the pool granularity we want. The various core object allocators would use this API with PyObject_NEW inlined. > > That said, I'll look into some of this with the free-threading work. That is > all post-1.6, though. It would be great if somebody could do it before then. Voila. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From Vladimir.Marangozov at inrialpes.fr Sun Jun 18 02:50:51 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Sun, 18 Jun 2000 02:50:51 +0200 (CEST) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules mmapmodule.c,2.10,2.11 In-Reply-To: <200006172241.PAA02080@slayer.i.sourceforge.net> from "A.M. Kuchling" at Jun 17, 2000 03:41:24 PM Message-ID: <200006180050.CAA07547@python.inrialpes.fr> A.M. Kuchling wrote: > > Update of /cvsroot/python/python/dist/src/Modules > In directory slayer.i.sourceforge.net:/tmp/cvs-serv2060 > > Modified Files: > mmapmodule.c > Log Message: > Fix the size() method to return the size of the file on Unix, not the > size of the mapped area. This seems to be what the Windows version does. > This change requires keeping around the fd of the mapped file. On AIX, the test_mmap fails with errno=EINVAL on the m.flush() method. It works okay without the MS_INVALIDATE flag though, so I'd suggest removing it from msync in the flush and dealloc methods. Also, it would probably be a good idea to allow optional flags for flush, as it's done in new_mmap_object, the default being only MS_SYNC. Given that this module is enabled by default, I think that it needs some more stress-testing in test_mmap.py. I'll try to add a couple of tests shortly. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From trentm at activestate.com Sun Jun 18 05:20:09 2000 From: trentm at activestate.com (Trent Mick) Date: Sat, 17 Jun 2000 20:20:09 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules mmapmodule.c,2.10,2.11 In-Reply-To: <200006180050.CAA07547@python.inrialpes.fr> References: <200006172241.PAA02080@slayer.i.sourceforge.net> <200006180050.CAA07547@python.inrialpes.fr> Message-ID: <20000617202009.A20019@activestate.com> On Sun, Jun 18, 2000 at 02:50:51AM +0200, Vladimir Marangozov wrote: > > A.M. Kuchling wrote: > > > > Update of /cvsroot/python/python/dist/src/Modules > > In directory slayer.i.sourceforge.net:/tmp/cvs-serv2060 > > > > Modified Files: > > mmapmodule.c > > Log Message: > > Fix the size() method to return the size of the file on Unix, not the > > size of the mapped area. This seems to be what the Windows version does. > > This change requires keeping around the fd of the mapped file. > > On AIX, the test_mmap fails with errno=EINVAL on the m.flush() method. > It works okay without the MS_INVALIDATE flag though, so I'd suggest > removing it from msync in the flush and dealloc methods. > > Also, it would probably be a good idea to allow optional flags for > flush, as it's done in new_mmap_object, the default being only MS_SYNC. > > Given that this module is enabled by default, I think that it needs some > more stress-testing in test_mmap.py. I'll try to add a couple of tests > shortly. > Just to add to the mmap fray. The seek() method is broken for any 'whence' value (seek from start, current, orend) other than the default. Ihave a patch that fixes that as well as gets mmap'd files working on Linux64 and Win64. The test_mmap was also extended. The patch is up on SourceForge for your perusal. :) https://sourceforge.net/patch/?func=detailpatch&patch_id=100515&group_id=5470 Cheers, Trent -- Trent Mick trentm at activestate.com From mhammond at skippinet.com.au Sun Jun 18 05:35:00 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sun, 18 Jun 2000 13:35:00 +1000 Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/Doc/lib libmmap.tex,NONE,1.1 In-Reply-To: <200006172239.PAA01994@slayer.i.sourceforge.net> Message-ID: > Documentation for the mmap module: proofreaders welcomed OK :-) > the file handle \var{fileno}, and returns a mmap object. If you have > a Python file object, its > \method{fileno()} method returns the file's handle, which is > just an integer. This could be a little clearer - on first reading, I thought you were talking about the return value. Maybe something like: "if you wish to pass an existing Python file object for this parameter, use its \method{fileno()} method to obtain the fileno." > \var{tagname}, if specified, is a string giving a tag name for > the mapping. XXX what is the purpose of the tag name? Something like: Windows allows you to have many different mappings against the same file. If you specify the name of an existing tag, that tag is opened, otherwise a new tag of this name is created. If this parameter is None, the mapping is created without a name. Avoiding the use of the tag parameter will assist in keeping your code portable between Unix and Windows. > \begin{funcdesc}{mmap}{file, size \optional{, flags, prot}} > (Unix version) Maps \var{length} bytes from the file specified by the > file handle \var{fileno}, and returns a mmap object. If you have a > Python file object, its \method{fileno()} method returns the file's > handle, which is just an integer. I believe you mean the signature to say "fileno" instead of "file" - this makes it consistent with the Windows signature, and reinforces that this param is indeed identical. As a meta-comment, the structure of this implies that the param signatures are more different than they are - eg, it should be possible to write portable mmap code in most cases, without concern for the platform. the platform only becomes relevant when you use the optional params for each platform? > \begin{methoddesc}{read}{\var{num}} > Return a string containing up to \var{num} bytes taken from the "taken from" -> "starting from" ?? > \begin{methoddesc}{write_byte}{\var{byte}} > Write \var{byte} into memory at the current position of > the file pointer; the file position is advanced by 1. > \end{methoddesc} The type of "byte" should be explained - its never clear to me if a "byte" should be an int or a string of size 1. In this case, it is the latter. Looks good! Mark. From mhammond at skippinet.com.au Sun Jun 18 05:35:33 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sun, 18 Jun 2000 13:35:33 +1000 Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/Doc/lib libmmap.tex,NONE,1.1 In-Reply-To: <200006172239.PAA01994@slayer.i.sourceforge.net> Message-ID: Sorry about that - I meant to send it direct to Andrew... Mark. From Vladimir.Marangozov at inrialpes.fr Sun Jun 18 06:24:05 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Sun, 18 Jun 2000 06:24:05 +0200 (CEST) Subject: [Python-Dev] Towards selective compilation to native code? Message-ID: <200006180424.GAA14040@python.inrialpes.fr> There was a cool seminar the other day here, focusing on embedded & real-time Java, so I'll throw here some impressions while they're fresh. One of the presenters talked extensively about compilation strategies and techniques for Java bytecode to native code, and while I know that Java is not Python, it would be interesting to, at least, try to project some of the ideas to Python in the long run, where applicable. Needless to say, the guy & his environment (ex-OSF, now Silicomp) are experts in compiler technology and I'm not in a position to comment on everything, but you may find the second half of the slides enlightening: http://cgi-serv.inrialpes.fr/InTech/2000-06-15/ejava-silicomp.ppt So, the interesting part of the talk was about a "new" compiler architecture, built upon the concept of "Flash compiling" (quite unappropriate name), which produces a mixture of the following: 1. Bytecode 2. Native code 3. Native code is compiled selectively on demand and/or ahead of time (!= JIT) for "expensive" methods. 4. Expensive methods are, on one hand, detected by dynamic profiling of the bytecode, and OTOH, determined ahead of time according to the following 2 simple creteria: - methods containing loops - methods calling native code from bytecode (to avoid bytecode to native and vice versa arg conversion paths which are expensive -- btw Python has the same perf. bottleneck) 5. Everything relies on dyn loading & late binding of native code (front-end loads dynamically the back-end, native code is stored in the code stream, but linked incrementally & dynamically during execution) 6. The whole thing is designed to avoid code explosion and to preserve the advantage of bytecode == small code size, and the presented preliminary results are quite optimistic -- the figures differ depending on the code size / speed tradeoff. Of course, this is Java and there's static typing in there, but it would be interesting to see whether Python can steal something from these ideas. For instance, I'm trying to foresee what kind of static typing (i.e. how much static info) would be appropriate in Python from this point of view but I fail to obtain any realistic image :). I see most parts of the dyn loading / late binding aspect though -- they are typical for Python. Hm. Sounds like I'll be harrassing Tim to make him finally write something valuable for Python ;-) -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From akuchlin at cnri.reston.va.us Sun Jun 18 06:22:24 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Sun, 18 Jun 2000 00:22:24 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules mmapmodule.c,2.10,2.11 In-Reply-To: <200006180050.CAA07547@python.inrialpes.fr>; from Vladimir.Marangozov@inrialpes.fr on Sun, Jun 18, 2000 at 02:50:51AM +0200 References: <200006172241.PAA02080@slayer.i.sourceforge.net> <200006180050.CAA07547@python.inrialpes.fr> Message-ID: <20000618002224.A12729@newcnri.cnri.reston.va.us> On Sun, Jun 18, 2000 at 02:50:51AM +0200, Vladimir Marangozov wrote: >On AIX, the test_mmap fails with errno=EINVAL on the m.flush() method. >It works okay without the MS_INVALIDATE flag though, so I'd suggest >removing it from msync in the flush and dealloc methods. Ooh, you're right. The Linux msync man page says "MS_ASYNC specifies that an update be scheduled, but the call returns immediately. MS_SYNC asks for an update and waits for it to complete. MS_INVALIDATE asks to invalidate other mappings of the same file (so that they can be updated with the fresh values just written)." So MS_INVALIDATE seems far too drastic. >Also, it would probably be a good idea to allow optional flags for >flush, as it's done in new_mmap_object, the default being only MS_SYNC. The problem is: does Windows provide equivalent functionality? (Is there documentation available online for CreateFileMapping that I could look at?) >Given that this module is enabled by default, I think that it needs some >more stress-testing in test_mmap.py. I'll try to add a couple of tests >shortly. Good idea. I'll try to look at Trent Mick's patch and apply it ASAP if it checks out. --amk From akuchlin at cnri.reston.va.us Sun Jun 18 07:03:16 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Sun, 18 Jun 2000 01:03:16 -0400 Subject: [Python-Dev] Re: Almost insignificant patch for mmapmodule In-Reply-To: ; from lorenzo@sancho.ccd.uniroma2.it on Sat, Jun 17, 2000 at 04:29:14PM +0200 References: Message-ID: <20000618010316.D12729@newcnri.cnri.reston.va.us> On Sat, Jun 17, 2000 at 04:29:14PM +0200, Lorenzo M. Catucci wrote: >therefore, here is the change: if we are compiling for linux, define >_GNU_SOURCE before including mman.h, and all is done. It seems the Hmm... IMHO this points out a bug; if MREMAP_MAYMOVE is not present, that doesn't imply that mremap() doesn't work at all; instead, a resize may fail if the mapping would have to be moved to a different virtual address. Quoting from the Linux man page: MREMAP_MAYMOVE indicates if the operation should fail, or change the virtual address if the resize cannot be done at the current virtual address. I think the correct fix is to simply specify MREMAP_MAYMOVE if it's defined, but still support attempting to resize. Possibly the configure script should also check for mremap()'s existence. --amk From lorenzo at sancho.ccd.uniroma2.it Sun Jun 18 09:39:55 2000 From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci) Date: Sun, 18 Jun 2000 09:39:55 +0200 (CEST) Subject: [Python-Dev] Re: Almost insignificant patch for mmapmodule In-Reply-To: <20000618010316.D12729@newcnri.cnri.reston.va.us> Message-ID: On Sun, 18 Jun 2000, Andrew Kuchling wrote: AK> On Sat, Jun 17, 2000 at 04:29:14PM +0200, Lorenzo M. Catucci wrote: AK> >therefore, here is the change: if we are compiling for linux, define AK> >_GNU_SOURCE before including mman.h, and all is done. It seems the AK> AK> Hmm... IMHO this points out a bug; if MREMAP_MAYMOVE is not present, AK> that doesn't imply that mremap() doesn't work at all; instead, a AK> resize may fail if the mapping would have to be moved to a different AK> virtual address. Quoting from the Linux man page: AK> AK> MREMAP_MAYMOVE AK> indicates if the operation should fail, or change AK> the virtual address if the resize cannot be done at AK> the current virtual address. AK> AK> I think the correct fix is to simply specify MREMAP_MAYMOVE if it's AK> defined, but still support attempting to resize. Possibly the AK> configure script should also check for mremap()'s existence. AK> I think I've been too dense... Here I see two problems: on one hand, from what I have understood of python's object, it's much better if the c pointers are movable in VM on the remap, and the MAYMOVE flag is only defined in mman.h if _GNU_SOURCE is; on the other hand, we only know about linux mremap semantics: for what I see in linix mremap(2) """ CONFORMING TO This call is Linux-specific, and should not be used in programs intended to be portable. 4.2BSD had a (never actually implemented) mremap(2) call with completely dif? ferent semantics. """ Therefore, I think that really checking for __linux__ and using the MAYMOVE flag, which is thefined there, is going towards the right way. If someone else comes out with another kernel supporting a mremap syscall[1], I think we'll be able to add proper support afterwards. As for the configure script, on linux we have both mremap and MAYMOVE; if you go to the Extended UNIX ABI, M* Page, you'll find: GNU Unix98 Unix95 POSIX ISO C SVID 3 4.3BSD XPG mremap X It seems only the systems supported by GNU libc-2 (only linux systems, then) support mremap... Have a nice time. lmc * Just tried searching for mremap on http://www.FreeBSD.org/cgi/man.cgi?query=mmap and looked around the various BSD derivatives whose man pages are available there. +-------------------------+----------------------------------------------+ | Lorenzo M. Catucci | Centro di Calcolo e Documentazione | | catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" | | | Via O. Raimondo 18 ** I-00173 ROMA ** ITALY | | Tel. +39 06 7259 2255 | Fax. +39 06 7259 2125 | +-------------------------+----------------------------------------------+ From petrilli at amber.org Sun Jun 18 20:50:22 2000 From: petrilli at amber.org (Christopher Petrilli) Date: Sun, 18 Jun 2000 14:50:22 -0400 Subject: [Python-Dev] Towards selective compilation to native code? In-Reply-To: <200006180424.GAA14040@python.inrialpes.fr>; from Vladimir.Marangozov@inrialpes.fr on Sun, Jun 18, 2000 at 06:24:05AM +0200 References: <200006180424.GAA14040@python.inrialpes.fr> Message-ID: <20000618145022.A13031@trump.amber.org> Vladimir Marangozov [Vladimir.Marangozov at inrialpes.fr] wrote: > > Of course, this is Java and there's static typing in there, but it > would be interesting to see whether Python can steal something from these > ideas. For instance, I'm trying to foresee what kind of static typing > (i.e. how much static info) would be appropriate in Python from this > point of view but I fail to obtain any realistic image :). > I see most parts of the dyn loading / late binding aspect though -- > they are typical for Python. One might take a look at Smalltalk/X which compiles into C, and has a pretty (ney very) high performance reputation. There are some other Smalltalk implementations taht do this as well. This would be closer I think to what Python would use than Java will be. Chris -- | Christopher Petrilli | petrilli at amber.org From effbot at telia.com Sun Jun 18 21:06:45 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 18 Jun 2000 21:06:45 +0200 Subject: [Python-Dev] talking about performance... Message-ID: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid> consider this little program: import time, sre k = u"foo" p = sre.compile(k) s = "*"*500 + k + "*"*500 def f1(): p.search(s) def f2(): s.find(k) def bench(f): t0 = time.clock() for i in range(100000): f() print f, time.clock() - t0 bench(f1) bench(f2) which prints: 2.94704487169 10.5247875425 (Windows 95, 233 MHz) if I change the k variable to an 8-bit string, it prints: 2.47613520173 2.5178698939 (for some reason, sre is still slighty faster...) so in other words, something in unicode land isn't as efficient as it should... From akuchlin at cnri.reston.va.us Sun Jun 18 21:20:20 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Sun, 18 Jun 2000 15:20:20 -0400 Subject: [Python-Dev] talking about performance... In-Reply-To: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid>; from effbot@telia.com on Sun, Jun 18, 2000 at 09:06:45PM +0200 References: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid> Message-ID: <20000618152020.B14713@newcnri.cnri.reston.va.us> On Sun, Jun 18, 2000 at 09:06:45PM +0200, Fredrik Lundh wrote: >so in other words, something in unicode land isn't >as efficient as it should... The relevant bit of findstring() in unicodeobject.c: if (direction < 0) { for (; end >= start; end--) if (Py_UNICODE_MATCH(self, end, substring)) return end; } else { for (; start <= end; start++) if (Py_UNICODE_MATCH(self, start, substring)) return start; } And... #define Py_UNICODE_MATCH(string, offset, substring)\ (!memcmp((string)->str + (offset), (substring)->str,\ (substring)->length*sizeof(Py_UNICODE))) Proposed patch: Index: unicodeobject.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v retrieving revision 2.26 diff -u -r2.26 unicodeobject.c --- unicodeobject.c 2000/06/14 09:18:32 2.26 +++ unicodeobject.c 2000/06/18 19:18:01 @@ -2168,11 +2168,13 @@ if (direction < 0) { for (; end >= start; end--) - if (Py_UNICODE_MATCH(self, end, substring)) + if ( *(self->str + end) == *(substring->str) && + Py_UNICODE_MATCH(self, end, substring)) return end; } else { for (; start <= end; start++) - if (Py_UNICODE_MATCH(self, start, substring)) + if (*(self->str + start) == *(substring->str) && + Py_UNICODE_MATCH(self, start, substring)) return start; } --amk From amk1 at erols.com Sun Jun 18 21:32:37 2000 From: amk1 at erols.com (A.M. Kuchling) Date: Sun, 18 Jun 2000 15:32:37 -0400 Subject: [Python-Dev] Turning on sre? Message-ID: <200006181932.PAA03968@207-172-113-141.s141.tnt5.ann.va.dialup.rcn.com> Before 1.6a3, should the sre module be turned on, replacing re? That way it'll start getting tested; better we find problems sooner rather than later... --amk From guido at python.org Sun Jun 18 22:47:22 2000 From: guido at python.org (Guido van Rossum) Date: Sun, 18 Jun 2000 15:47:22 -0500 Subject: [Python-Dev] Turning on sre? In-Reply-To: Your message of "Sun, 18 Jun 2000 15:32:37 -0400." <200006181932.PAA03968@207-172-113-141.s141.tnt5.ann.va.dialup.rcn.com> References: <200006181932.PAA03968@207-172-113-141.s141.tnt5.ann.va.dialup.rcn.com> Message-ID: <200006182047.PAA03008@cj20424-a.reston1.va.home.com> > Before 1.6a3, should the sre module be turned on, replacing re? That > way it'll start getting tested; better we find problems sooner rather > than later... That would be nice. If I replace re.py with "from sre import *" and run test_re.py, I grt in trouble in the sub() test: $ ./python ../Lib/test/test_re.py Running tests on re.search and re.match Running tests on re.sub Traceback (most recent call last): File "../Lib/test/test_re.py", line 41, in ? assert re.sub(r'\d+', bump_num, '08.2 -2 23x99y') == '9.3 -3 24x100y' File "./../Lib/sre.py", line 35, in sub return _compile(pattern).sub(repl, string, count) File "./../Lib/sre.py", line 84, in _sub return _subn(pattern, template, string, count)[0] File "./../Lib/sre.py", line 114, in _subn return string[:0].join(s), n TypeError: sequence item 0 not a string $ It appears that the value of s is a list containing alternating zeros and strings: [0, '.', 0, ' -', 0, ' ', 0, 'x', 0, 'y']. No time to look into this further, but it could be a bug in sre._subn(). --Guido van Rossum (home page: http://www.python.org/~guido/) From akuchlin at cnri.reston.va.us Sun Jun 18 22:28:59 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Sun, 18 Jun 2000 16:28:59 -0400 Subject: [Python-Dev] Turning on sre? In-Reply-To: <200006182047.PAA03008@cj20424-a.reston1.va.home.com>; from guido@python.org on Sun, Jun 18, 2000 at 03:47:22PM -0500 References: <200006181932.PAA03968@207-172-113-141.s141.tnt5.ann.va.dialup.rcn.com> <200006182047.PAA03008@cj20424-a.reston1.va.home.com> Message-ID: <20000618162859.A15018@newcnri.cnri.reston.va.us> On Sun, Jun 18, 2000 at 03:47:22PM -0500, Guido van Rossum wrote: >No time to look into this further, but it could be a bug in sre._subn(). It's a typo; fixed. However, test_re then runs into the fact that _expand(), which should expand escapes in the replacement string, isn't implemented yet. --amk From effbot at telia.com Sun Jun 18 23:42:00 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 18 Jun 2000 23:42:00 +0200 Subject: [Python-Dev] talking about performance... References: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid> <20000618152020.B14713@newcnri.cnri.reston.va.us> Message-ID: <008301bfd96e$0bd98d20$f2a6b5d4@hagrid> amk wrote: > On Sun, Jun 18, 2000 at 09:06:45PM +0200, Fredrik Lundh wrote: > >so in other words, something in unicode land isn't > >as efficient as it should... > > The relevant bit of findstring() in unicodeobject.c: > > if (direction < 0) { > for (; end >= start; end--) > if (Py_UNICODE_MATCH(self, end, substring)) > return end; > } else { > for (; start <= end; start++) > if (Py_UNICODE_MATCH(self, start, substring)) > return start; > } > > And... > > #define Py_UNICODE_MATCH(string, offset, substring)\ > (!memcmp((string)->str + (offset), (substring)->str,\ > (substring)->length*sizeof(Py_UNICODE))) heh. it's my own code, of course... > Proposed patch: > > Index: unicodeobject.c MATCH is used in a couple of places; it's probably a better idea to change the macro (in Include/unicodeobject.h). MAL? From effbot at telia.com Sun Jun 18 23:43:51 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 18 Jun 2000 23:43:51 +0200 Subject: [Python-Dev] Turning on sre? References: <200006181932.PAA03968@207-172-113-141.s141.tnt5.ann.va.dialup.rcn.com> Message-ID: <009501bfd96e$4d11b7e0$f2a6b5d4@hagrid> amk wrote: > Before 1.6a3, should the sre module be turned on, replacing re? That > way it'll start getting tested; better we find problems sooner rather > than later... in addition to the typo you noticed, there's a backtracking (I think) problem that affects xmllib.py and tokenize.py... I'm working on it. From mal at lemburg.com Sun Jun 18 23:48:32 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun, 18 Jun 2000 23:48:32 +0200 Subject: [Python-Dev] talking about performance... References: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid> <20000618152020.B14713@newcnri.cnri.reston.va.us> <008301bfd96e$0bd98d20$f2a6b5d4@hagrid> Message-ID: <394D43B0.8CC7070@lemburg.com> Fredrik Lundh wrote: > > amk wrote: > > > On Sun, Jun 18, 2000 at 09:06:45PM +0200, Fredrik Lundh wrote: > > >so in other words, something in unicode land isn't > > >as efficient as it should... > > > > The relevant bit of findstring() in unicodeobject.c: > > > > if (direction < 0) { > > for (; end >= start; end--) > > if (Py_UNICODE_MATCH(self, end, substring)) > > return end; > > } else { > > for (; start <= end; start++) > > if (Py_UNICODE_MATCH(self, start, substring)) > > return start; > > } > > > > And... > > > > #define Py_UNICODE_MATCH(string, offset, substring)\ > > (!memcmp((string)->str + (offset), (substring)->str,\ > > (substring)->length*sizeof(Py_UNICODE))) > > heh. it's my own code, of course... > > > Proposed patch: > > > > Index: unicodeobject.c > > MATCH is used in a couple of places; it's probably a better idea > to change the macro (in Include/unicodeobject.h). MAL? Right. I'll add Andrew's proposed patch to the macro def. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From effbot at telia.com Mon Jun 19 00:33:10 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 19 Jun 2000 00:33:10 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Include unicodeobject.h,2.9,2.10 References: <200006182222.PAA19408@slayer.i.sourceforge.net> Message-ID: <00c601bfd975$358d0aa0$f2a6b5d4@hagrid> mal wrote: > > #define Py_UNICODE_MATCH(string, offset, substring)\ > ! ((*((string)->str + (offset)) == *((substring)->str)) &&\ > ! !memcmp((string)->str + (offset), (substring)->str,\ > (substring)->length*sizeof(Py_UNICODE))) > I completely forgot that this has different semantics if the substring happens to be empty. (substrings are null terminated, but "\0" isn't the same thing as ""...) don't have time to screen unicodeobject.c right now, but maybe someone else can do it? if not, maybe amk's patch was a better idea after all... From mwh21 at cam.ac.uk Mon Jun 19 01:15:25 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 19 Jun 2000 00:15:25 +0100 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules _tkinter.c,1.99,1.100 In-Reply-To: "A.M. Kuchling"'s message of "Sun, 18 Jun 2000 11:45:52 -0700" References: <200006181845.LAA10182@slayer.i.sourceforge.net> Message-ID: "A.M. Kuchling" writes: > Update of /cvsroot/python/python/dist/src/Modules > In directory slayer.i.sourceforge.net:/tmp/cvs-serv10064/Modules > > Modified Files: > _tkinter.c > Log Message: > Patch from /F: > this patch adds a fast _flatten function to the _tkinter > module, and imports it from Tkinter.py (if available). > > this speeds up canvas operations like create_line and > create_polygon. for example, a create_line with 5000 > vertices runs about 50 times faster with this patch in > place. Unfortunately this introduces another Way To Make Python Core: [mwh21 at atrus build]$ ./python Python 1.6a2 (#4, Jun 18 2000, 23:57:36) [GCC 2.95.1 19990816/Linux (release)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> import Tkinter >>> l = [] >>> l.append(l) >>> Tkinter._flatten(l) Segmentation fault (core dumped) Here's a simple solution: Index: _tkinter.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/_tkinter.c,v retrieving revision 1.100 diff -u -r1.100 _tkinter.c --- _tkinter.c 2000/06/18 18:45:50 1.100 +++ _tkinter.c 2000/06/18 23:13:22 @@ -2001,13 +2001,16 @@ } static int -_flatten1(FlattenContext* context, PyObject* item) +_flatten1(FlattenContext* context, PyObject* item, int depth) { /* add tuple or list to argument tuple (recursively) */ int i, size; - if (PyList_Check(item)) { + if (depth > 1000) { + PyErr_SetString(PyExc_ValueError,"nesting too deep in _flatten"); + return 0; + } else if (PyList_Check(item)) { size = PyList_GET_SIZE(item); /* preallocate (assume no nesting) */ if (context->size + size > context->maxsize && !_bump(context, size)) @@ -2016,7 +2019,7 @@ for (i = 0; i < size; i++) { PyObject *o = PyList_GET_ITEM(item, i); if (PyList_Check(o) || PyTuple_Check(o)) { - if (!_flatten1(context, o)) + if (!_flatten1(context, o, depth + 1)) return 0; } else if (o != Py_None) { if (context->size + 1 > context->maxsize && !_bump(context, 1)) @@ -2033,7 +2036,7 @@ for (i = 0; i < size; i++) { PyObject *o = PyTuple_GET_ITEM(item, i); if (PyList_Check(o) || PyTuple_Check(o)) { - if (!_flatten1(context, o)) + if (!_flatten1(context, o, depth + 1)) return 0; } else if (o != Py_None) { if (context->size + 1 > context->maxsize && !_bump(context, 1)) @@ -2068,7 +2071,7 @@ context.size = 0; - if (!_flatten1(&context, item)) + if (!_flatten1(&context, item,0)) return NULL; if (_PyTuple_Resize(&context.tuple, context.size, 0)) "seems to work"; I've not tested it for performance, but I can't believe this is too hard a hit. Cheers, M. From mal at lemburg.com Mon Jun 19 01:20:27 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 19 Jun 2000 01:20:27 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Include unicodeobject.h,2.9,2.10 References: <200006182222.PAA19408@slayer.i.sourceforge.net> <00c601bfd975$358d0aa0$f2a6b5d4@hagrid> Message-ID: <394D593B.DD4804E6@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > > > #define Py_UNICODE_MATCH(string, offset, substring)\ > > ! ((*((string)->str + (offset)) == *((substring)->str)) &&\ > > ! !memcmp((string)->str + (offset), (substring)->str,\ > > (substring)->length*sizeof(Py_UNICODE))) > > > > I completely forgot that this has different semantics if the > substring happens to be empty. > > (substrings are null terminated, but "\0" isn't the same > thing as ""...) > > don't have time to screen unicodeobject.c right now, but > maybe someone else can do it? if not, maybe amk's patch > was a better idea after all... I've checked the places where this macro is used: all except the in .count() method showed the same behaviour as for 8-bit strings. The Unicode .count() method now also returns the same value for empty substrings as the 8-bit strings. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From effbot at telia.com Mon Jun 19 01:29:23 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 19 Jun 2000 01:29:23 +0200 Subject: [Python-Dev] CVS: python/dist/src/Modules _tkinter.c,1.99,1.100 References: <200006181845.LAA10182@slayer.i.sourceforge.net> Message-ID: <002701bfd97d$09d8b640$f2a6b5d4@hagrid> michael wrote: > > this patch adds a fast _flatten function to the _tkinter > > module, and imports it from Tkinter.py (if available). > > Unfortunately this introduces another Way To Make Python Core: well, there are lots of way to dump core through Tkinter/Tk, so I convinced myself that it wasn't really worth the effort to prevent it in _flatten... either way, the patch looks okay to me. From mwh21 at cam.ac.uk Mon Jun 19 01:41:22 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 19 Jun 2000 00:41:22 +0100 Subject: [Python-Dev] CVS: python/dist/src/Modules _tkinter.c,1.99,1.100 In-Reply-To: "Fredrik Lundh"'s message of "Mon, 19 Jun 2000 01:29:23 +0200" References: <200006181845.LAA10182@slayer.i.sourceforge.net> <002701bfd97d$09d8b640$f2a6b5d4@hagrid> Message-ID: "Fredrik Lundh" writes: > michael wrote: > > > this patch adds a fast _flatten function to the _tkinter > > > module, and imports it from Tkinter.py (if available). > > > > Unfortunately this introduces another Way To Make Python Core: > > well, there are lots of way to dump core through Tkinter/Tk, so I > convinced myself that it wasn't really worth the effort to prevent > it in _flatten... Are there? (I hardly know Tkinter). Oh well. I don't know of many "core" methods of doing it; the only one I can think of is marshalling a recursive list, and as there seems to be a loud party going on next door to me, I may write a patch for that this evening... Cheers, M. From mhammond at skippinet.com.au Mon Jun 19 02:05:00 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Mon, 19 Jun 2000 10:05:00 +1000 Subject: [Python-Dev] Welcome back In-Reply-To: <200006182047.PAA03008@cj20424-a.reston1.va.home.com> Message-ID: Welcome back, welcome back, welcome baaaaack - Welcome back, welcome back, welcome baaaaack Good to see you return. Im sure you had a wonderful time! From all accounts, your wedding was beautiful, as Im sure your honeymoon was... Now-were-just-waiting-for-the-baby-announcements-ly, Mark. > -----Original Message----- > From: python-dev-admin at python.org [mailto:python-dev-admin at python.org]On > Behalf Of Guido van Rossum > Sent: Monday, 19 June 2000 6:47 AM > To: akuchlin at mems-exchange.org > Cc: python-dev at python.org > Subject: Re: [Python-Dev] Turning on sre? From tim_one at email.msn.com Mon Jun 19 04:05:16 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 18 Jun 2000 22:05:16 -0400 Subject: [Python-Dev] Welcome back In-Reply-To: Message-ID: [Mark Hammond] > ... > Good to see you return. Im sure you had a wonderful time! From > all accounts, your wedding was beautiful, as Im sure your > honeymoon was... > > Now-were-just-waiting-for-the-baby-announcements-ly, Guido & Kim just spent the last night of their honeymoon with Uncle Timmy (who is now living in a Virginia motel room), and I can assure you no babies were made by any pair of us tonight. Unless Guido is quicker than he looks. i'm-certainly-not-ly y'rs - tim From skip at mojam.com Sat Jun 17 05:45:14 2000 From: skip at mojam.com (Skip Montanaro) Date: Fri, 16 Jun 2000 22:45:14 -0500 (CDT) Subject: [Python-Dev] list comprehensions Message-ID: <14666.62538.988511.305499@beluga.mojam.com> Did list comprehensions ever make it into 1.6? I thought I submitted a 1.6-compatible update of Greg Ewing's mods awhile ago. Should I resubmit? To the patches list? -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On June 24th at 8AM, live your life for an hour as Ricky Byrdsong always lived his - run/walk in the Ricky Byrdsong Memorial 5K or just make a donation: https://www.SignmeupSports.com/Events/Index_Events.asp?EventID=1395 From guido at python.org Mon Jun 19 17:01:24 2000 From: guido at python.org (Guido van Rossum) Date: Mon, 19 Jun 2000 10:01:24 -0500 Subject: [Python-Dev] list comprehensions In-Reply-To: Your message of "Fri, 16 Jun 2000 22:45:14 EST." <14666.62538.988511.305499@beluga.mojam.com> References: <14666.62538.988511.305499@beluga.mojam.com> Message-ID: <200006191501.KAA02197@cj20424-a.reston1.va.home.com> > Did list comprehensions ever make it into 1.6? No (as far as I'm aware :-). > I thought I submitted a > 1.6-compatible update of Greg Ewing's mods awhile ago. Should I resubmit? > To the patches list? It's rather late in the release cycle -- I'm trying to get alpha 3 released, and i'm still 1400 messages behind on my email. But submitting a patch might be a good idea anyway so we won't forget about it (and maybe it's of such baffling simplicity that it'll charm its way past the guards :-). --Guido van Rossum (home page: http://www.python.org/~guido/) From ping at lfw.org Mon Jun 19 20:59:15 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Mon, 19 Jun 2000 13:59:15 -0500 (CDT) Subject: [Python-Dev] list comprehensions In-Reply-To: <200006191501.KAA02197@cj20424-a.reston1.va.home.com> Message-ID: On Mon, 19 Jun 2000, Guido van Rossum wrote: > > Did list comprehensions ever make it into 1.6? > > No (as far as I'm aware :-). [...] > But submitting a patch might be a good idea anyway so we won't forget > about it (and maybe it's of such baffling simplicity that it'll charm > its way past the guards :-). I just have to say i thought list comprehensions were really cool. -- ?!ng From skip at mojam.com Mon Jun 19 22:17:59 2000 From: skip at mojam.com (Skip Montanaro) Date: Mon, 19 Jun 2000 15:17:59 -0500 Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions... Message-ID: <200006192017.PAA00690@beluga.mojam.com> Python's sys module defines an exitfunc variable that is settable from Python scripts. At exit, that function will be called with no arguments. While this is a good start at supporting standard cleanup activities, it defines no protocol to be used by modules that wish to use sys.exitfunc, which leads to one of two extremes: 1, two modules wishing to define cleanup functions both clobber sys.exitfunc or 2, to avoid collisions they don't use the functionality provided. At an application level this is okay. Within a single application you can define an application-specific protocol to handle the situation. Unfortunately, this still leaves Python's core modules without a good way to register exit functions. I ran into this problem today. I would really like the rlcompleter module to read and write readline history files from Python. Reading a history file at module startup is no problem, but deciding where to write the history file is a problem. The logical place is at the time sys.exitfunc is executed. For my own applications I long ago wrote a very simple module (called exit.py, appended to this message) that defines two functions: * exit.register_exitfunc takes a function object and a set of optional arguments and appends them to a list. * exit._run_exitfuncs is bound to sys.exitfunc and executes the registered exit functions in the order they appear in the list. I propose exit.py as the starting point for a well-defined protocol for modules to register exit functions without collisions. -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On June 24th at 8AM, live your life for an hour as Ricky Byrdsong always lived his - run/walk in the Ricky Byrdsong Memorial 5K or just make a donation: https://www.SignmeupSports.com/Events/Index_Events.asp?EventID=1395 """ allow programmer to define multiple exit functions to be executed upon normal program termination. """ _exithandlers = [] def _run_exitfuncs(): while _exithandlers: func, targs, kargs = _exithandlers[0] apply(func, targs, kargs) _exithandlers.remove(_exithandlers[0]) def register_exitfunc(func, *targs, **kargs): """register a function to be executed upon normal program termination arguments are a function object, and zero or more arguments to pass to it. """ _exithandlers.append((func, targs, kargs)) import sys try: x = sys.exitfunc except AttributeError: sys.exitfunc = _run_exitfuncs del sys if __name__ == "__main__": def x1(): print "running x1" def x2(n): print "running x2(%s)" % `n` def x3(n, kwd=None): print "running x3(%s, kwd=%s)" % (`n`, `kwd`) register_exitfunc(x1) register_exitfunc(x2, 12) register_exitfunc(x3, 5, "bar") register_exitfunc(x3, "no kwd args") From DavidA at ActiveState.com Mon Jun 19 22:27:48 2000 From: DavidA at ActiveState.com (David Ascher) Date: Mon, 19 Jun 2000 13:27:48 -0700 Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions... In-Reply-To: <200006192017.PAA00690@beluga.mojam.com> Message-ID: +1 on the idea. I wonder if it makes sense to publish a mechanism to allow de-registering of callbacks, or if that's featuritis. Also, I'd change: > try: > x = sys.exitfunc > except AttributeError: > sys.exitfunc = _run_exitfuncs > del sys to: try: register_exitfuncs(sys.exitfunc) finally: sys.exitfunc = _run_exitfuncs Or some such. --david > -----Original Message----- > From: python-dev-admin at python.org [mailto:python-dev-admin at python.org]On > Behalf Of Skip Montanaro > Sent: Monday, June 19, 2000 1:18 PM > To: python-dev at python.org > Subject: [Python-Dev] Proposal: standard way of defining and executing > "atexit" functions... > Importance: Low > > > > Python's sys module defines an exitfunc variable that is settable from > Python scripts. At exit, that function will be called with no arguments. > While this is a good start at supporting standard cleanup activities, it > defines no protocol to be used by modules that wish to use sys.exitfunc, > which leads to one of two extremes: 1, two modules wishing to > define cleanup > functions both clobber sys.exitfunc or 2, to avoid collisions > they don't use > the functionality provided. > > At an application level this is okay. Within a single application you can > define an application-specific protocol to handle the situation. > Unfortunately, this still leaves Python's core modules without a > good way to > register exit functions. > > I ran into this problem today. I would really like the rlcompleter module > to read and write readline history files from Python. Reading a history > file at module startup is no problem, but deciding where to write the > history file is a problem. The logical place is at the time > sys.exitfunc is > executed. > > For my own applications I long ago wrote a very simple module (called > exit.py, appended to this message) that defines two functions: > > * exit.register_exitfunc takes a function object and a set of optional > arguments and appends them to a list. > > * exit._run_exitfuncs is bound to sys.exitfunc and executes the > registered exit functions in the order they appear in the list. > > I propose exit.py as the starting point for a well-defined protocol for > modules to register exit functions without collisions. > > -- > Skip Montanaro, skip at mojam.com, http://www.mojam.com/, > http://www.musi-cal.com/ > On June 24th at 8AM, live your life for an hour as Ricky Byrdsong always > lived > his - run/walk in the Ricky Byrdsong Memorial 5K or just make a donation: > https://www.SignmeupSports.com/Events/Index_Events.asp?EventID=1395 > > > """ > allow programmer to define multiple exit functions to be executed upon > normal > program termination. > """ > > _exithandlers = [] > def _run_exitfuncs(): > while _exithandlers: > func, targs, kargs = _exithandlers[0] > apply(func, targs, kargs) > _exithandlers.remove(_exithandlers[0]) > > def register_exitfunc(func, *targs, **kargs): > """register a function to be executed upon normal program termination > > arguments are a function object, and zero or more arguments to pass to > it. > """ > _exithandlers.append((func, targs, kargs)) > > import sys > try: > x = sys.exitfunc > except AttributeError: > sys.exitfunc = _run_exitfuncs > del sys > > if __name__ == "__main__": > def x1(): > print "running x1" > def x2(n): > print "running x2(%s)" % `n` > def x3(n, kwd=None): > print "running x3(%s, kwd=%s)" % (`n`, `kwd`) > > register_exitfunc(x1) > register_exitfunc(x2, 12) > register_exitfunc(x3, 5, "bar") > register_exitfunc(x3, "no kwd args") > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev > From skip at mojam.com Mon Jun 19 22:55:09 2000 From: skip at mojam.com (Skip Montanaro) Date: Mon, 19 Jun 2000 15:55:09 -0500 (CDT) Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions... In-Reply-To: References: <200006192017.PAA00690@beluga.mojam.com> Message-ID: <14670.34989.887973.797947@beluga.mojam.com> David> +1 on the idea. I wonder if it makes sense to publish a David> mechanism to allow de-registering of callbacks, or if that's David> featuritis. While writing my message I thought, "I'll bet the first question asked will be about unregistering exit functions." I've been using the module I appended to my message unchanged for a couple years and never needed such functionality. I'm sure there are applications that could use it, but I think they'd be a small minority. Since the only defined interface is a single registration function (_run_exitfuncs is only used internally), I think you'd be free to add some unregister function protocol at a later time if it was deemed necessary. David> Also, I'd change: >> try: >> x = sys.exitfunc >> except AttributeError: >> sys.exitfunc = _run_exitfuncs >> del sys David> to: David> try: David> register_exitfuncs(sys.exitfunc) David> finally: David> sys.exitfunc = _run_exitfuncs David> Or some such. register_exitfunc is only meant to be called by clients of the module, not used internally. You're assuming that if something else was already bound to sys.exitfunc that it's not _run_exitfuncs. With your try/finally code try the following (mentally is fine): import exit def foo(): print 1 exit.register_exitfunc(foo) reload(exit) I think you'll see that exit._run_exitfuncs is on its own list of exit functions. That could be bad. The setup code: try: x = sys.exitfunc except AttributeError: sys.exitfunc = _run_exitfuncs is meant to avoid doing anything if any other module beat us to sys.exitfunc. Perhaps it should just be sys.exitfunc = _run_exitfuncs If someone fails to use the defined protocol, screw 'em... ;-) Skip From DavidA at ActiveState.com Mon Jun 19 23:12:03 2000 From: DavidA at ActiveState.com (David Ascher) Date: Mon, 19 Jun 2000 14:12:03 -0700 Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions... In-Reply-To: <14670.34989.887973.797947@beluga.mojam.com> Message-ID: > If someone fails to use the defined protocol, screw 'em... ;-) That's unreasonable given that existing tools might include a library which might be upgraded to use the new mechanism while the old code used its own mechanism happily. For example, I've used my own protocols in the past which went something like... def register_exitfunc(func): old_exitfunc = getattr(sys, 'exitfunc', None) def wrapper(old_exitfunc=old_exitfunc, new_func=func): if old_exitfunc is not None: old_exitfunc() new_func() sys.exitfunc = wrapper or some such, creating a call chain instead of a sequence of calls, and it's a 'fine' protocol in that it worked fine in the absence of a standard. No need to break code if we can avoid it. The point of my pseudo-patch, if it wasn't clear, was that if a function is already in sys.exitfunc, then it should still be called on exit after the new exit module is imported. You're right that my patch didn't properly check that _run_exitfuncs might be that function. --david From skip at mojam.com Mon Jun 19 23:41:54 2000 From: skip at mojam.com (Skip Montanaro) Date: Mon, 19 Jun 2000 16:41:54 -0500 (CDT) Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions... In-Reply-To: References: <14670.34989.887973.797947@beluga.mojam.com> Message-ID: <14670.37794.998270.762852@beluga.mojam.com> >> If someone fails to use the defined protocol, screw 'em... ;-) David> That's unreasonable given that existing tools might include a David> library which might be upgraded to use the new mechanism while David> the old code used its own mechanism happily. Point taken. I'll look at extending the module to accommodate other sys.exitfunc callers. Skip From Vladimir.Marangozov at inrialpes.fr Tue Jun 20 03:11:24 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Tue, 20 Jun 2000 03:11:24 +0200 (CEST) Subject: [Python-Dev] mmapmodule.c,2.10,2.11 In-Reply-To: <20000618002224.A12729@newcnri.cnri.reston.va.us> from "Andrew Kuchling" at Jun 18, 2000 12:22:24 AM Message-ID: <200006200111.DAA01591@python.inrialpes.fr> Andrew Kuchling wrote: > > On Sun, Jun 18, 2000 at 02:50:51AM +0200, Vladimir Marangozov wrote: > >On AIX, the test_mmap fails with errno=EINVAL on the m.flush() method. > >It works okay without the MS_INVALIDATE flag though, so I'd suggest > >removing it from msync in the flush and dealloc methods. > > Ooh, you're right. The Linux msync man page says "MS_ASYNC specifies > that an update be scheduled, but the call returns immediately. > MS_SYNC asks for an update and waits for it to complete. > MS_INVALIDATE asks to invalidate other mappings of the same file (so > that they can be updated with the fresh values just written)." So > MS_INVALIDATE seems far too drastic. Yes. > > >Also, it would probably be a good idea to allow optional flags for > >flush, as it's done in new_mmap_object, the default being only MS_SYNC. > > The problem is: does Windows provide equivalent functionality? (Is > there documentation available online for CreateFileMapping that I > could look at?) Well, I had a look at my Windows book. Although the mmap functionnality is equivalent, overall, there are no equivalent flags in FlushViewOfFile, etc. Maybe this is too subtle to be of any real use after all, so I retract the idea. MS_SYNC alone is fine. Another point: I'm not thrilled about the idea of raising a SystemError for m.resize if native mremap is missing (which is also AIX's case). unmap/mmap again with the new size is the emulation solution everybody would do in Python when m.resize is not implemented. So I'd suggest implementing it in C (which is what the Windows version does, btw). Furthermore, having an unimplemented method makes little sense to me. For implementing this emulation on Unix, however, we would need to remember in additional slots the original mmap flags & rights, so that the second (or any subsequent) mmap call uses the same flags & rights as the first one. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From pf at artcom-gmbh.de Tue Jun 20 09:32:33 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Tue, 20 Jun 2000 09:32:33 +0200 (MEST) Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions... In-Reply-To: from David Ascher at "Jun 19, 2000 2:12: 3 pm" Message-ID: Hi Skip, Hi David, David Ascher: > > If someone fails to use the defined protocol, screw 'em... ;-) > > That's unreasonable given that existing tools might include a library which > might be upgraded to use the new mechanism while the old code used its own > mechanism happily. For example, I've used my own protocols in the past > which went something like... > > def register_exitfunc(func): > old_exitfunc = getattr(sys, 'exitfunc', None) > def wrapper(old_exitfunc=old_exitfunc, new_func=func): > if old_exitfunc is not None: old_exitfunc() > new_func() > sys.exitfunc = wrapper > > or some such, creating a call chain instead of a sequence of calls, and it's > a 'fine' protocol in that it worked fine in the absence of a standard. No > need to break code if we can avoid it. Davids wrapper function implements a FIFO strategy for termination. I think this is not desired. Normally you want LIFO, because higher level services in an application are initialized later during startup. Those services usually depend on lower level services, which should still be available at termination time of the higher level services. I try to explain this by an example: Module A provides some kind of network connections. Module B uses (imports) Module A to access a remote resource administration server to provide access to remote devices or resources. During program termination Module B likes to release all resources reserved for (owned by) the program. It uses Module A to submit a cleanup request to the server. Module A however wants to close all open network connections. The following function (termination protocol) solves this by exchanging the sequence of calls within the wrapper: def register_exit_func(func, *args, **kw): import sys previous_func = sys.exit_func def wrapped_func(previous_func=previous_func, func=func, args=args, kw=kw): try: apply(func, args, kw) finally: if previous_func is not None: previous_func() sys.exit_func = wrapped_func In the past I've placed such a function into a common base module of my apps. But I think, Skip is right, that a termination protocol should be part of the standard library. But a separate module 'exit.py' seems to be overkill for single basic function. May be it should be put into the module 'os'? Handling of program termination is something, which considered as a generic operating system service. From the users point of view 'sys' would be a better place, but this would require rewriting in C: ugly. I also agree with Skip, that the possibility to unregister an exit_func is normally not needed. The same effect can be achieved by doing nothing in the exit_func. Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen) From mhammond at skippinet.com.au Tue Jun 20 10:02:14 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Tue, 20 Jun 2000 18:02:14 +1000 Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions... In-Reply-To: Message-ID: Peter: > Davids wrapper function implements a FIFO strategy for termination. > I think this is not desired. Normally you want LIFO, Agreed. LIFO is definately preferred IMO. Mark. From pf at artcom-gmbh.de Tue Jun 20 10:08:16 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Tue, 20 Jun 2000 10:08:16 +0200 (MEST) Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions... In-Reply-To: From "(env:" "pf)" at "Jun 20, 2000 9:32:33 am" Message-ID: Hi, I wrote: > def register_exit_func(func, *args, **kw): > import sys > previous_func = sys.exit_func this should have been 'sys.exitfunc'. I've also misssed to note, that I placed the following line into the module init code: import sys; def _nop(): pass; sys.exitfunc = _nop Otherwise I had to use getattr(sys, 'exitfunc', None) as David suggested. Next time I should actually cut'n'paste working code instead typing from blurred memory. :-( Another point I forgot, was that you usually want to install signal handlers on unices, that handle the signal.SIGTERM, signal.SIGHUP and signal.SIGINT signals and invoke exit function to do some final cleanup. Regards, Peter From mal at lemburg.com Tue Jun 20 11:01:50 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 20 Jun 2000 11:01:50 +0200 Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions... References: Message-ID: <394F32FE.B926C19A@lemburg.com> Attached you find a similar module which I have used for years. It has all the requested features, plus allows deregistration and supports a more OO-like interface. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ -------------- next part -------------- A non-text attachment was scrubbed... Name: ExitFunctions.py Type: text/python Size: 2444 bytes Desc: not available URL: From fredrik at pythonware.com Tue Jun 20 12:15:01 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Tue, 20 Jun 2000 12:15:01 +0200 Subject: [Python-Dev] talking about performance... [case closed] References: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid> <20000618152020.B14713@newcnri.cnri.reston.va.us> <008301bfd96e$0bd98d20$f2a6b5d4@hagrid> <394D43B0.8CC7070@lemburg.com> Message-ID: <003101bfdaa0$693b4de0$0900a8c0@SPIFF> mal wrote: > > > Index: unicodeobject.c > > > > MATCH is used in a couple of places; it's probably a better idea > > to change the macro (in Include/unicodeobject.h). MAL? > > Right. I'll add Andrew's proposed patch to the macro def. for the record, my little benchmark now runs about five times faster than before -- which means that 16-bit find is now ~30% faster than 8-bit find (barry? ;-) cheers /F footnote: for the exact figures, see: http://hem.passagen.se/eff/2000_06_01_bot-archive.htm#361472 From mhammond at skippinet.com.au Tue Jun 20 13:42:53 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Tue, 20 Jun 2000 21:42:53 +1000 Subject: [Python-Dev] Fw: Access violation when no memory Message-ID: From gward at mems-exchange.org Tue Jun 20 14:33:44 2000 From: gward at mems-exchange.org (Greg Ward) Date: Tue, 20 Jun 2000 08:33:44 -0400 Subject: [Python-Dev] RFC: Including PIL in 1.6 In-Reply-To: <20000609181924.A15728@thyrsus.com>; from esr@thyrsus.com on Fri, Jun 09, 2000 at 06:19:24PM -0400 References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> Message-ID: <20000620083344.A3499@ludwig.cnri.reston.va.us> On 09 June 2000, Eric S. Raymond said: > I think it's time to consider including PIL in the core Python 1.6 release. > I've been following the work being done over there, and I believe the > code has reached a sufficient level of maturity to justify this. -1 from me. What's the point of the Distutils if we just throw everything "useful" into the standard distribution? Greg From gward at mems-exchange.org Tue Jun 20 14:40:41 2000 From: gward at mems-exchange.org (Greg Ward) Date: Tue, 20 Jun 2000 08:40:41 -0400 Subject: [Python-Dev] Towards 1.6 Final In-Reply-To: <200006130237.EAA10373@python.inrialpes.fr>; from Vladimir.Marangozov@inrialpes.fr on Tue, Jun 13, 2000 at 04:37:23AM +0200 References: <14661.19894.465676.770545@anthem.concentric.net> <200006130237.EAA10373@python.inrialpes.fr> Message-ID: <20000620084040.B3499@ludwig.cnri.reston.va.us> On 13 June 2000, Vladimir Marangozov said: > > - Fix ./ld_so_aix installation problem on AIX (anybody know more about > > this???) > > Yes, AMK, Greg Ward and I know more. It's more an automation (path) problem > for building C extensions with distutils than an installation problem per se. > Some time ago, I saw a workaround checked in by Greg. If this is still judged > as a problem, I'd like to hear about it. This is a minor thing. I have yet > to install & run the distutil package on AIX, though, and see what happens. As I recall, my workaround didn't work. (Would that make it a failaround?) Vladimir, *please* give the Distutils a whirl on AIX -- I suspect some sort of hack is needed to get extension-building working there. I don't much care if the Makefile installed by Python is "fixed" to have an absolute path to "ld_so_aix" instead of "./ld_so_aix" -- that should make extension-building with the Distutils OK, but it will break the relocatability of a Python installation on AIX. Also, it won't fix Distutils with Python 1.5.2. Thanks -- Greg From paul at prescod.net Tue Jun 20 15:30:13 2000 From: paul at prescod.net (Paul Prescod) Date: Tue, 20 Jun 2000 15:30:13 +0200 Subject: [Python-Dev] RFC: Including PIL in 1.6 References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us> Message-ID: <394F71E5.C7CEC32D@prescod.net> Greg Ward wrote: > > ... > -1 from me. What's the point of the Distutils if we just throw > everything "useful" into the standard distribution? One way to look at it is vertical versus horizontal. I think that that's how the Java world works (unofficially). If Java is one extreme and ANSI C is on the other, I prefer to err on the Java side (which we probably do). The big issue is configuration management. if we put PIL (or anything else) in the standard distribution we are promising to keep that code in sync with everything else. This is a big boon to users and a big headache for maintainers. The question is when the boon is enough to justify the headache. It's one thing to tell a user: "Just type distutils and everything will magically become available." But they usually come back: "I'm getting an error message about append not taking that many arguments..." or something like that. Libraries breaking libraries is actually the most common case. -- Paul Prescod - ISOGEN Consulting Engineer speaking for himself "Music is the stuff between the notes." - Claude Debussy From bwarsaw at python.org Tue Jun 20 15:43:32 2000 From: bwarsaw at python.org (Barry A. Warsaw) Date: Tue, 20 Jun 2000 09:43:32 -0400 (EDT) Subject: [Python-Dev] talking about performance... [case closed] References: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid> <20000618152020.B14713@newcnri.cnri.reston.va.us> <008301bfd96e$0bd98d20$f2a6b5d4@hagrid> <394D43B0.8CC7070@lemburg.com> <003101bfdaa0$693b4de0$0900a8c0@SPIFF> Message-ID: <14671.29956.819067.208771@anthem.concentric.net> >>>>> "FL" == Fredrik Lundh writes: FL> for the record, my little benchmark now runs about five FL> times faster than before -- which means that 16-bit find FL> is now ~30% faster than 8-bit find (barry? ;-) Awesome! From akuchlin at cnri.reston.va.us Tue Jun 20 15:53:09 2000 From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling) Date: Tue, 20 Jun 2000 09:53:09 -0400 Subject: [Python-Dev] talking about performance... [case closed] In-Reply-To: <003101bfdaa0$693b4de0$0900a8c0@SPIFF>; from fredrik@pythonware.com on Tue, Jun 20, 2000 at 12:15:01PM +0200 References: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid> <20000618152020.B14713@newcnri.cnri.reston.va.us> <008301bfd96e$0bd98d20$f2a6b5d4@hagrid> <394D43B0.8CC7070@lemburg.com> <003101bfdaa0$693b4de0$0900a8c0@SPIFF> Message-ID: <20000620095309.A3039@amarok.cnri.reston.va.us> On Tue, Jun 20, 2000 at 12:15:01PM +0200, Fredrik Lundh wrote: >for the record, my little benchmark now runs about five >times faster than before -- which means that 16-bit find >is now ~30% faster than 8-bit find (barry? ;-) Speculation: the code in stringobject.c looks like this: for (; i <= last; ++i) if (s[i] == sub[0] && (n == 1 || memcmp(&s[i+1], &sub[1], n-1) == 0)) return (long)i; It checks the first character, and then does the memcmp() skipping the first character, or succeeds if the substring length is 1; the Unicode find is simpler, just doing the full memcmp. I wonder if the extra n == 1 and i+1, n-1 arithmetic costs more than it saves? This is probably delicately tied to the speed of your memcmp(). Anyone want to try the simpler version and report on whether it makes a difference? --amk From effbot at telia.com Tue Jun 20 17:26:42 2000 From: effbot at telia.com (Fredrik Lundh) Date: Tue, 20 Jun 2000 17:26:42 +0200 Subject: [Python-Dev] faster 8-bit find/split (was: talking about performance...) References: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid> <20000618152020.B14713@newcnri.cnri.reston.va.us> <008301bfd96e$0bd98d20$f2a6b5d4@hagrid> <394D43B0.8CC7070@lemburg.com> <003101bfdaa0$693b4de0$0900a8c0@SPIFF> <20000620095309.A3039@amarok.cnri.reston.va.us> Message-ID: <007701bfdacc$0d2e87c0$f2a6b5d4@hagrid> [as discussed on python-dev] amk wrote: > On Tue, Jun 20, 2000 at 12:15:01PM +0200, Fredrik Lundh wrote: > >for the record, my little benchmark now runs about five > >times faster than before -- which means that 16-bit find > >is now ~30% faster than 8-bit find (barry? ;-) > > Speculation: the code in stringobject.c looks like this: > for (; i <= last; ++i) > if (s[i] == sub[0] && > (n == 1 || memcmp(&s[i+1], &sub[1], n-1) == 0)) > return (long)i; > > It checks the first character, and then does the memcmp() skipping the > first character, or succeeds if the substring length is 1; the Unicode > find is simpler, just doing the full memcmp. I wonder if the extra n > == 1 and i+1, n-1 arithmetic costs more than it saves? at least on my box (win95, msvc 5)... after simplifying the code, string.find is now faster than sre.search. it's still 15% slower than the 16-bit string find, but I don't have time to dig into that right now... patches are included. I confirm that, to the best of my knowledge and belief, this contribution is free of any claims of third parties under copyright, patent or other rights or interests ("claims"). To the extent that I have any such claims, I hereby grant to CNRI a nonexclusive, irrevocable, royalty-free, worldwide license to reproduce, distribute, perform and/or display publicly, prepare derivative versions, and otherwise use this contribution as part of the Python software and its related documentation, or any derivative versions thereof, at no cost to CNRI or its licensed users, and to authorize others to do so. I acknowledge that CNRI may, at its sole discretion, decide whether or not to incorporate this contribution in the Python software and its related documentation. I further grant CNRI permission to use my name and other identifying information provided to CNRI by me for use in connection with the Python software and its related documentation. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: string-patch.txt URL: From fdrake at beopen.com Tue Jun 20 17:47:35 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 20 Jun 2000 11:47:35 -0400 (EDT) Subject: [Python-Dev] faster 8-bit find/split (was: talking about performance...) In-Reply-To: <007701bfdacc$0d2e87c0$f2a6b5d4@hagrid> References: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid> <20000618152020.B14713@newcnri.cnri.reston.va.us> <008301bfd96e$0bd98d20$f2a6b5d4@hagrid> <394D43B0.8CC7070@lemburg.com> <003101bfdaa0$693b4de0$0900a8c0@SPIFF> <20000620095309.A3039@amarok.cnri.reston.va.us> <007701bfdacc$0d2e87c0$f2a6b5d4@hagrid> Message-ID: <14671.37399.809253.945519@cj42289-a.reston1.va.home.com> Fredrik Lundh writes: > patches are included. Now checked in, thanks! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one at email.msn.com Tue Jun 20 18:47:47 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 20 Jun 2000 12:47:47 -0400 Subject: [Python-Dev] talking about performance... [case closed] In-Reply-To: <20000620095309.A3039@amarok.cnri.reston.va.us> Message-ID: [Fredrik Lundh] > for the record, my little benchmark now runs about five > times faster than before -- which means that 16-bit find > is now ~30% faster than 8-bit find (barry? ;-) [Andrew M. Kuchling]/ > Speculation: the code in stringobject.c looks like this: > for (; i <= last; ++i) > if (s[i] == sub[0] && > (n == 1 || memcmp(&s[i+1], &sub[1], > n-1) == 0)) > return (long)i; > ... > the Unicode find is simpler, just doing the full memcmp. I wonder > if the extra n == 1 and i+1, n-1 arithmetic costs more than it > saves? So the intent of the code is to avoid the expense of calling memcmp if a full n-character memcmp can't possibly find equality at i (due to mismatch of first characters), and the assumption is that first characters mismatch frequently. Both seem like good calls to me! > This is probably delicately tied to the speed of your memcmp(). Also on whether your memcmp() is an actual external function or a full or partial inline expansion (e.g., the strcmp at KSR expanded into code much like the "by-hand" stuff above, skipping "the real" strcmp if the first characters weren't equal). > Anyone want to try the simpler version and report on whether > it makes a difference? No . But if someone does, a good compromise might be to split this into two loops, one for the n==1 case and another for n>1. The "+1/-1" are dubious in any case (i.e., "memcmp(s+i, sub, n) == 0" saves the fiddly arithmetic at the also-minor cost of making memcmp do one redundant character compare). From dan at cgsoftware.com Tue Jun 20 18:55:11 2000 From: dan at cgsoftware.com (Daniel Berlin) Date: Tue, 20 Jun 2000 09:55:11 -0700 (PDT) Subject: [Python-Dev] talking about performance... [case closed] In-Reply-To: Message-ID: > So the intent of the code is to avoid the expense of calling memcmp if a > full n-character memcmp can't possibly find equality at i (due to mismatch > of first characters), and the assumption is that first characters mismatch > frequently. Both seem like good calls to me! However, smart compilers (gcc 2.95+ fer instance) will produce an inline memcmp call that is faster, and has no overhead (IE it's not making a library call). Thus, the first character mismatch test is useless. We had the same thing in strcmp macros in GDB, where we tested the first character, then strcmp'd. It was faster to just strcmp, even when they *did* mismatch. --Dan From esr at thyrsus.com Tue Jun 20 19:21:50 2000 From: esr at thyrsus.com (esr at thyrsus.com) Date: Tue, 20 Jun 2000 13:21:50 -0400 Subject: [Python-Dev] list comprehensions In-Reply-To: References: <200006191501.KAA02197@cj20424-a.reston1.va.home.com> Message-ID: <20000620132150.O8678@thyrsus.com> Ka-Ping Yee : > On Mon, 19 Jun 2000, Guido van Rossum wrote: > > But submitting a patch might be a good idea anyway so we won't forget > > about it (and maybe it's of such baffling simplicity that it'll charm > > its way past the guards :-). > > I just have to say i thought list comprehensions were > really cool. Ditto. I would like to see this in 1.6. -- Eric S. Raymond The men and women who founded our country knew, by experience, that there are times when the free person's answer to oppressive government has to be delivered with a bullet. Thus, the right to bear arms is not just *a* freedom; it's the mother of all freedoms. Don't let them disarm you! From esr at thyrsus.com Tue Jun 20 20:04:19 2000 From: esr at thyrsus.com (esr at thyrsus.com) Date: Tue, 20 Jun 2000 14:04:19 -0400 Subject: [Python-Dev] RFC: Including PIL in 1.6 In-Reply-To: <20000620083344.A3499@ludwig.cnri.reston.va.us> References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us> Message-ID: <20000620140419.C10038@thyrsus.com> Greg Ward : > -1 from me. What's the point of the Distutils if we just throw > everything "useful" into the standard distribution? Watch that argument -- it could turn and bite you. What's the justification for including, e.g. POP client classes in the standard distribution? One of Python's most important strengths is the "batteries *are* included" richness of the standard environment. -- Eric S. Raymond The two pillars of `political correctness' are, a) willful ignorance, and b) a steadfast refusal to face the truth -- George MacDonald Fraser From effbot at telia.com Tue Jun 20 19:59:35 2000 From: effbot at telia.com (Fredrik Lundh) Date: Tue, 20 Jun 2000 19:59:35 +0200 Subject: [Python-Dev] RFC: Including PIL in 1.6 References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us> Message-ID: <001101bfdae1$5094f7a0$f2a6b5d4@hagrid> greg wrote: > On 09 June 2000, Eric S. Raymond said: > > I think it's time to consider including PIL in the core Python 1.6 release. > > I've been following the work being done over there, and I believe the > > code has reached a sufficient level of maturity to justify this. > > -1 from me. What's the point of the Distutils if we just throw > everything "useful" into the standard distribution? strange argument. what's the point of including *anything* if we have distutils? ... fwiw, I'm -0 on this one; it might better to work on a "Python Standards Base" which specifies a bunch of extensions that people are encouraged to include in their distributions. let's see: zlib, expat, (portions of) numpy, pil, piddle, ... From effbot at telia.com Tue Jun 20 20:02:24 2000 From: effbot at telia.com (Fredrik Lundh) Date: Tue, 20 Jun 2000 20:02:24 +0200 Subject: [Python-Dev] talking about performance... References: Message-ID: <002001bfdae1$b28942e0$f2a6b5d4@hagrid> tim wrote: > No . But if someone does, a good compromise might be to split this > into two loops, one for the n==1 case and another for n>1. how about this one: if (dir > 0) { char *p, *e; if (n == 0 && i <= last) return (long)i; e = s + last - n + 1; for (;;) { p = memchr(s, sub[0], e - s); if (p == NULL) break; if (n == 1 || memcmp(p, sub, n) == 0) return (long) (p - s); s = p + 1; } } new record time: 1.6 seconds (down from 2.2) From akuchlin at cnri.reston.va.us Tue Jun 20 20:04:06 2000 From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling) Date: Tue, 20 Jun 2000 14:04:06 -0400 Subject: [Python-Dev] RFC: Including PIL in 1.6 In-Reply-To: <20000620140419.C10038@thyrsus.com>; from esr@thyrsus.com on Tue, Jun 20, 2000 at 02:04:19PM -0400 References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us> <20000620140419.C10038@thyrsus.com> Message-ID: <20000620140406.B3142@amarok.cnri.reston.va.us> >Watch that argument -- it could turn and bite you. What's the justification >for including, e.g. POP client classes in the standard distribution? >One of Python's most important strengths is the "batteries *are* >included" richness of the standard environment. Once there are enough pieces to make finding and getting the software near-automatic, I actually wouldn't mind splitting them out and shipping a much smaller core distribution, perhaps with a script that downloads the latest versions of what's in the standard library. Debian did that for a while, with python-net, python-base, python-text, &c. I just compiled XEmacs 21.1.10 on a new Linux machine; you compile the binary, and install two packages of Elisp code (EFS and xemacs-base). Then you run xemacs, do Options > Manage Packages > List and Install, and you get a nice list containing GNUS, W3, programming language modes, etc. Pick the ones you want, it adds the ones needed by the ones you selected, and it fetches and installs them. Easy! Now imagine doing the same thing with Python modules. Of course, we'd have to design that feature first... (ESR & Paul Prescod vs. AMK & GPW: the First Pythonic War! :) ) -- A.M. Kuchling http://starship.python.net/crew/amk/ This is, after all, a book about reading, and the kind of reader I am addressing does not care primarily about being in fashion. -- Robertson Davies, _A Voice from the Attic_ From DavidA at ActiveState.com Tue Jun 20 20:16:40 2000 From: DavidA at ActiveState.com (David Ascher) Date: Tue, 20 Jun 2000 11:16:40 -0700 Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions... In-Reply-To: Message-ID: > Peter: > > > Davids wrapper function implements a FIFO strategy for termination. > > I think this is not desired. Normally you want LIFO, > > Agreed. LIFO is definately preferred IMO. Agreed. My wrapper was also from memory, and that was not at all the main point of my post =). --da From akuchlin at cnri.reston.va.us Tue Jun 20 20:17:47 2000 From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling) Date: Tue, 20 Jun 2000 14:17:47 -0400 Subject: [Python-Dev] Re: [Patches] Adding sip to urlparse In-Reply-To: <002c01bfdae3$e4b71ba0$f2a6b5d4@hagrid>; from effbot@telia.com on Tue, Jun 20, 2000 at 08:18:03PM +0200 References: <14671.44450.197852.869640@rama.research.nokia.com> <14671.45733.968387.361146@cj42289-a.reston1.va.home.com> <002c01bfdae3$e4b71ba0$f2a6b5d4@hagrid> Message-ID: <20000620141747.D3142@amarok.cnri.reston.va.us> On Tue, Jun 20, 2000 at 08:18:03PM +0200, Fredrik Lundh quoted FLD: >> What is "sip"? Is it defined by an RFC (which?), or Internet Draft >> (which? what's the expected activity?). Is there a canonical list of all the defined URL types anywhere? I notice that 'ldap' isn't there, and maybe there are more missing. (Some of the ones in there are marginal: who cares about Prospero?) -- A.M. Kuchling http://starship.python.net/crew/amk/ That's so obvious that someone has already got a patent on it. -- Guido van Rossum, 12 Jan 1999 From DavidA at ActiveState.com Tue Jun 20 20:29:26 2000 From: DavidA at ActiveState.com (David Ascher) Date: Tue, 20 Jun 2000 11:29:26 -0700 Subject: [Python-Dev] Re: [Patches] Adding sip to urlparse In-Reply-To: <20000620141747.D3142@amarok.cnri.reston.va.us> Message-ID: > Is there a canonical list of all the defined URL types anywhere? I > notice that 'ldap' isn't there, and maybe there are more missing. > (Some of the ones in there are marginal: who cares about Prospero?) Mozilla defines a bunch, which I doubt are RFC anything. (chrome://, component://, etc.). --david From jeremy at beopen.com Tue Jun 20 20:33:59 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Tue, 20 Jun 2000 14:33:59 -0400 (EDT) Subject: [Python-Dev] RFC: Including PIL in 1.6 In-Reply-To: <20000620140406.B3142@amarok.cnri.reston.va.us> References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us> <20000620140419.C10038@thyrsus.com> <20000620140406.B3142@amarok.cnri.reston.va.us> Message-ID: <14671.47383.313007.531923@localhost.localdomain> >>>>> "AMK" == Andrew M Kuchling writes: AMK> I just compiled XEmacs 21.1.10 on a new Linux machine; you AMK> compile the binary, and install two packages of Elisp code (EFS AMK> and xemacs-base). Then you run xemacs, do Options > Manage AMK> Packages > List and Install, and you get a nice list containing AMK> GNUS, W3, programming language modes, etc. Pick the ones you AMK> want, it adds the ones needed by the ones you selected, and it AMK> fetches and installs them. Easy! Now imagine doing the same AMK> thing with Python modules. Of course, we'd have to design that AMK> feature first... I did the same install on my new Linux box last month. I was similarly pleased with the ease of installation. Let's get working on a design for this feature! Jeremy From effbot at telia.com Tue Jun 20 20:37:30 2000 From: effbot at telia.com (Fredrik Lundh) Date: Tue, 20 Jun 2000 20:37:30 +0200 Subject: [Python-Dev] Re: [Patches] Adding sip to urlparse References: <14671.44450.197852.869640@rama.research.nokia.com> <14671.45733.968387.361146@cj42289-a.reston1.va.home.com> <002c01bfdae3$e4b71ba0$f2a6b5d4@hagrid> <20000620141747.D3142@amarok.cnri.reston.va.us> Message-ID: <004c01bfdae6$9abbdec0$f2a6b5d4@hagrid> amk wrote: > Is there a canonical list of all the defined URL types anywhere? I > notice that 'ldap' isn't there, and maybe there are more missing. your local search bot to the rescue: http://www.isi.edu/in-notes/iana/assignments/url-schemes (see http://www.iana.org/numbers.htm for a full list of things they keep track of) From akuchlin at cnri.reston.va.us Tue Jun 20 20:44:40 2000 From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling) Date: Tue, 20 Jun 2000 14:44:40 -0400 Subject: [Python-Dev] RFC: Including PIL in 1.6 In-Reply-To: <14671.47383.313007.531923@localhost.localdomain>; from jeremy@beopen.com on Tue, Jun 20, 2000 at 02:33:59PM -0400 References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us> <20000620140419.C10038@thyrsus.com> <20000620140406.B3142@amarok.cnri.reston.va.us> <14671.47383.313007.531923@localhost.localdomain> Message-ID: <20000620144440.E3142@amarok.cnri.reston.va.us> On Tue, Jun 20, 2000 at 02:33:59PM -0400, Jeremy Hylton wrote: >I did the same install on my new Linux box last month. I was >similarly pleased with the ease of installation. Let's get working on >a design for this feature! I have some notes on this, but they're at home. I'll post them tonight. --amk From paul at prescod.net Tue Jun 20 20:42:21 2000 From: paul at prescod.net (Paul Prescod) Date: Tue, 20 Jun 2000 13:42:21 -0500 Subject: [Python-Dev] RFC: Including PIL in 1.6 References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us> <20000620140419.C10038@thyrsus.com> <20000620140406.B3142@amarok.cnri.reston.va.us> Message-ID: <394FBB0D.96D88DBB@prescod.net> "Andrew M. Kuchling" wrote: > > ... > > I just compiled XEmacs 21.1.10 on a new Linux machine; you compile the > binary, and install two packages of Elisp code (EFS and xemacs-base). > Then you run xemacs, do Options > Manage Packages > List and Install, > and you get a nice list containing GNUS, W3, programming language > modes, etc. Pick the ones you want, it adds the ones needed by the > ones you selected, and it fetches and installs them. Easy! Now > imagine doing the same thing with Python modules. Of course, we'd > have to design that feature first... Let me repeat that I don't think that the main issue is whether it lives in this tarfile versus that tarfile. It's a) about agreeing to keep everything comptible. b) about being able to depend on the thing being there when you write a module. *In theory* Red Hat linux could be a kernel, a shell and the RPM engine. In practice, people like to be able to say: "if you have Red Hat version X then such and such will work because it comes with a functional package Y." Distutils is extremely important for vertical modules but if we start to use it as an excuse for leaving out core modules then I have to go with ESR and say: "where do we stop?" Unicode on demand? re on demand? pickle on demand? I think that the more relevant criteria are the ones we have always used: * how big is it * how easy is it to maintain * how integrated is it with everything else * how well-thought-out is it * and most important: how many people want it? I think that PIL is not yet a clear home run. -- Paul Prescod - ISOGEN Consulting Engineer speaking for himself "Music is the stuff between the notes." - Claude Debussy From guido at python.org Tue Jun 20 22:09:05 2000 From: guido at python.org (Guido van Rossum) Date: Tue, 20 Jun 2000 15:09:05 -0500 Subject: [Python-Dev] RFC: Including PIL in 1.6 In-Reply-To: Your message of "Tue, 20 Jun 2000 14:04:06 -0400." <20000620140406.B3142@amarok.cnri.reston.va.us> References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us> <20000620140419.C10038@thyrsus.com> <20000620140406.B3142@amarok.cnri.reston.va.us> Message-ID: <200006202009.PAA01064@cj20424-a.reston1.va.home.com> > I just compiled XEmacs 21.1.10 on a new Linux machine; you compile the > binary, and install two packages of Elisp code (EFS and xemacs-base). > Then you run xemacs, do Options > Manage Packages > List and Install, > and you get a nice list containing GNUS, W3, programming language > modes, etc. Pick the ones you want, it adds the ones needed by the > ones you selected, and it fetches and installs them. Easy! Now > imagine doing the same thing with Python modules. Of course, we'd > have to design that feature first... I just had to go through that process. It was actually rather painful, and I wouldn't have been able to succeed if it wasn't for XEmax grandmaster Barry Warsaw standing next to me holding my hand for a really long time... The autofetcher appeared broken at first, then had some unintuitive behavior next, before we finally got it running. Finally I got the hang of it, but after that I still had about a week where I occasionally used a familiar keystroke that triggered an error, and usually it took an email to Barry to find out which package contained the module defining the missing function. Not to say that I'm against this kind of thing, but warning that even in the best circumstances it can be a hurdle for newcomers... Which is why there's a market for packagers like Red Hat. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Tue Jun 20 22:12:09 2000 From: guido at python.org (Guido van Rossum) Date: Tue, 20 Jun 2000 15:12:09 -0500 Subject: [Python-Dev] Re: [Patches] Adding sip to urlparse In-Reply-To: Your message of "Tue, 20 Jun 2000 20:37:30 +0200." <004c01bfdae6$9abbdec0$f2a6b5d4@hagrid> References: <14671.44450.197852.869640@rama.research.nokia.com> <14671.45733.968387.361146@cj42289-a.reston1.va.home.com> <002c01bfdae3$e4b71ba0$f2a6b5d4@hagrid> <20000620141747.D3142@amarok.cnri.reston.va.us> <004c01bfdae6$9abbdec0$f2a6b5d4@hagrid> Message-ID: <200006202012.PAA01130@cj20424-a.reston1.va.home.com> > > Is there a canonical list of all the defined URL types anywhere? I > > notice that 'ldap' isn't there, and maybe there are more missing. > > your local search bot to the rescue: > http://www.isi.edu/in-notes/iana/assignments/url-schemes Of course now the trick is which ones are still relevant (as the doubt expressed about prospero exemplify). --Guido van Rossum (home page: http://www.python.org/~guido/) From fdrake at beopen.com Tue Jun 20 21:10:31 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 20 Jun 2000 15:10:31 -0400 (EDT) Subject: [Python-Dev] David Ascher's compile.py script? Message-ID: <14671.49575.161122.528241@cj42289-a.reston1.va.home.com> Does anyone have a copy of David Ascher's compile.py from his starship pages? The links there appear to be broken, and David appearantly hasn't been able to find time to look for a copy, or can't find it (I've sent him another mail about it in case it has turned up), and documentation users are asking about it. (There's a link from the extending & embedding manual.) If anyone has a copy, perhaps I could find provide a temporary location for it and revise the link in the online documentation to point there, as a stop-gap measure. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From nascheme at enme.ucalgary.ca Tue Jun 20 21:18:03 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Tue, 20 Jun 2000 13:18:03 -0600 Subject: [Python-Dev] David Ascher's compile.py script? In-Reply-To: <14671.49575.161122.528241@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Tue, Jun 20, 2000 at 03:10:31PM -0400 References: <14671.49575.161122.528241@cj42289-a.reston1.va.home.com> Message-ID: <20000620131803.A13811@acs.ucalgary.ca> On Tue, Jun 20, 2000 at 03:10:31PM -0400, Fred L. Drake, Jr. wrote: > Does anyone have a copy of David Ascher's compile.py from his > starship pages? I don't know how recent this copy is: http://www.enme.ucalgary.ca/~nascheme/python/compile.py Neil From fdrake at beopen.com Tue Jun 20 21:19:05 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 20 Jun 2000 15:19:05 -0400 (EDT) Subject: [Python-Dev] David Ascher's compile.py script? In-Reply-To: <20000620131803.A13811@acs.ucalgary.ca> References: <14671.49575.161122.528241@cj42289-a.reston1.va.home.com> <20000620131803.A13811@acs.ucalgary.ca> Message-ID: <14671.50089.860177.145255@cj42289-a.reston1.va.home.com> Neil Schemenauer writes: > I don't know how recent this copy is: > > http://www.enme.ucalgary.ca/~nascheme/python/compile.py Thanks! If nothing else shows up within the next day, I'll use this one. David, is this sufficiently recent? -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From skip at mojam.com Tue Jun 20 21:33:20 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 20 Jun 2000 14:33:20 -0500 (CDT) Subject: [Python-Dev] RFC: Including PIL in 1.6 In-Reply-To: <200006202009.PAA01064@cj20424-a.reston1.va.home.com> References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us> <20000620140419.C10038@thyrsus.com> <20000620140406.B3142@amarok.cnri.reston.va.us> <200006202009.PAA01064@cj20424-a.reston1.va.home.com> Message-ID: <14671.50944.796299.47756@beluga.mojam.com> Guido> I just had to go through that process. It was actually rather Guido> painful ... I will echo that sentiment. Actually, the first time I upgraded to the package stuff it went without a hitch. The next time it took me awhile to figure out why it didn't work. I imagine it's just teething pain that will get worked out as the XEmacs folks get more experience themselves, but auto-package install is definitely something that would have to be pretty bulletproof. I doubt the average Python user will have a similar level of computer savvy as the average XEmacs user. On top of that, how will you know that you want package X until you download it and try it out? I presume that carried to its logical conclusion, a package's documentation would be installed along with its source... chicken-and-egg-ly y'rs, -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On June 24th at 8AM, live your life for an hour as Ricky Byrdsong always lived his - run/walk in the Ricky Byrdsong Memorial 5K or just make a donation: https://www.SignmeupSports.com/Events/Index_Events.asp?EventID=1395 From paul at prescod.net Tue Jun 20 22:09:18 2000 From: paul at prescod.net (Paul Prescod) Date: Tue, 20 Jun 2000 15:09:18 -0500 Subject: [Python-Dev] Argh... Message-ID: <394FCF6E.85559D56@prescod.net> Okay, this is blatantly off-topic. I'm trying to increase the noise ratio so that people here will go back to comp.lang.python. All I need is for someone to email me in private email what's the Java equivalent of a=sys.argv[0] (it's almost over, it's almost over, it's almost over) Okay, here's an obPython: why doesn't the main module have an __file__ if it happens to be a file. I can understand why one piped in wouldn't but the interpreter knows when the main module is a file. -- Paul Prescod "Music is the stuff between the notes." - Claude Debussy From guido at python.org Tue Jun 20 23:31:00 2000 From: guido at python.org (Guido van Rossum) Date: Tue, 20 Jun 2000 16:31:00 -0500 Subject: [Python-Dev] Argh... In-Reply-To: Your message of "Tue, 20 Jun 2000 15:09:18 EST." <394FCF6E.85559D56@prescod.net> References: <394FCF6E.85559D56@prescod.net> Message-ID: <200006202131.QAA01631@cj20424-a.reston1.va.home.com> > Okay, here's an obPython: why doesn't the main module have an __file__ > if it happens to be a file. I can understand why one piped in wouldn't > but the interpreter knows when the main module is a file. Mostly because it's tough to pass that information around all the way to where it's needed. --Guido van Rossum (home page: http://www.python.org/~guido/) From mhammond at skippinet.com.au Wed Jun 21 01:06:57 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Wed, 21 Jun 2000 09:06:57 +1000 Subject: [Python-Dev] RFC: Including PIL in 1.6 In-Reply-To: <200006202009.PAA01064@cj20424-a.reston1.va.home.com> Message-ID: [Guido] > Not to say that I'm against this kind of thing, but warning that even > in the best circumstances it can be a hurdle for newcomers... > > Which is why there's a market for packagers like Red Hat. And even _then_ it is hard to get right. My experience similar to this was with debian, and its xptselect package. I was a Linux newbie, and the entire installation went pretty well until I was asked which packages I want to fetch and install. I was _soooo_ lost. I found the interface a complete mystery. It appeard to make random selections of stuff I didnt want, then randomly de-select stuff I didnt want. I had no idea how to search for anything, and the help was less than useful. Sometimes it wanted to download nothing, other times it wanted to download 400MB to complete the install!!! I only just resisted the temptation to go and buy a bunch of MS stock . Of course, within a week, I understood what was going on, and the sofware was indeed functioning correctly. But it took me that entire week to have a Linux system with everything I wanted installed and working correctly. The point I am trying to make is that for stuff that should be considered "core", the bar is very very high for these auto-configure applications. The usual audience will be _complete_ newbies. In my example, it was clear that a complete linux newbie was never let loose on this program while sitting in the same room as the author or the marketting team ;-) But I expect those with reasonable Linux experience quite like it, and themselves would not be happy with the complete-newbie version. The-included-batteries-were-the-wrong-size-ly, Mark. From Vladimir.Marangozov at inrialpes.fr Wed Jun 21 01:34:31 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Wed, 21 Jun 2000 01:34:31 +0200 (CEST) Subject: [Python-Dev] Fw: Access violation when no memory In-Reply-To: from "Mark Hammond" at Jun 20, 2000 09:42:53 PM Message-ID: <200006202334.BAA03150@python.inrialpes.fr> Mark Hammond wrote: > > >From the newsgroup. Any thoughts? > > Mark. > > "Phil Mayes" wrote in message > news:... > > The following program progressively allocates all memory: > > size = 1 << 20 > > list = [None,] > > while size: > > try: > > mem = [None] * size > > mem[0] = list > > list = mem > > except: > > size = size / 2 > > > > It fails with an access violation. The only immediate thought I have is that Python does not have builtin emergency procedures for such extreme situations. Although there are some safety checks, it is fairly easy to crash the interpreter in a number of ways. For example, with the introduction of the mmapmodule, there are even more "risks", like managing to mmap the python executable and screw it up completely (not speaking of the possibility to introduce Trojan horses and similar if this is done on purpose). There would probably be more checks, but complete safety is hard to achieve in the current state. The proposed solution is not a solution. The example program dumps core in different locations on my machine. We just do not have enough control from Python for managing such extreme cases. Sad, but true... -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From amk1 at erols.com Wed Jun 21 03:46:43 2000 From: amk1 at erols.com (A.M. Kuchling) Date: Tue, 20 Jun 2000 21:46:43 -0400 Subject: [Python-Dev] Installation requirements Message-ID: <200006210146.VAA01220@207-172-37-166.s166.tnt7.ann.va.dialup.rcn.com> [Follow-up to the Distutils SIG, please.] There are a few steps needed to find and install a package: 1) Discovery : which module does what I need? 2) Download : where can I get a copy? 3) Security : is this actually from the package author, and not a Trojan? 4) Installation : how do I set it up? 5) Checking for new versions: I have 1.0 installed; is a newer version available? Distutils focuses on the hardest and most complicated step, #4. For #1, you would need to browse through a list of available packages, browse through a hierarchy like Parnassus, or do keyword searches. #2 is pretty simple, since you just get one or more download URLs corresponding to a given package name, using the same database as in #1. For #3, you'd have to check a signature on the downloaded package, using something external like GnuPG. This means this step has to be skipped if the external tool isn't available. We could implement our own signature scheme with Python code, but that's a bad idea; security is hard, and few people will bother to generate keys that are only useful for this one application of distributing Python modules. (Side note: the sdist and bdist_* commands should have a --sign switch to sign the generated .tgz, .rpm, or whatever file.) For #5, the existing stuff in Tools/versioncheck might be partially applicable, though it requires that every package have a text file somewhere which gives the latest version. You'd want to use the same database for everything, to ensure that people actually use it! To start off with, we'd need some sort of generic API to the above functions, so that different interfaces can be written. A command-line interface would then be easiest. I don't know how network communications should be handled: HTTP to CGI scripts that return sets of RFC-822 headers, maybe? Combined with a DNS alias like modules.python.org, or modules.{us,uk,...}.python.org? Some potential sources of inspiration: Debian: apt Perl: CPAM.pm FreeBSD: ports system RPMfind (rpmfind.net) XEmacs: packages system -- A.M. Kuchling http://starship.python.net/crew/amk/ "Jo, it's a pity escapology wasn't part of your curriculum." "Funny you should say that. Look." -- The Doctor and Jo, tied up, in "Terror of the Autons" From tim_one at email.msn.com Wed Jun 21 05:44:18 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 20 Jun 2000 23:44:18 -0400 Subject: [Python-Dev] talking about performance... In-Reply-To: <002001bfdae1$b28942e0$f2a6b5d4@hagrid> Message-ID: [posted & mailed] [Fredrik Lundh] > how about this one: > > if (dir > 0) { > char *p, *e; > if (n == 0 && i <= last) > return (long)i; > e = s + last - n + 1; > for (;;) { > p = memchr(s, sub[0], e - s); > if (p == NULL) > break; > if (n == 1 || memcmp(p, sub, n) == 0) > return (long) (p - s); > s = p + 1; > } > } > > new record time: 1.6 seconds (down from 2.2) I expect that whether this is faster or slower depends on both the compiler you're using and the exact strings you're using to time it. In any case, it appears to be incorrect: p & s both change inside the infinite loop, and the innermost return computes their difference. Surely it should be returning the difference between p and the value s had *before* the loop was entered. If this passed your tests, then, it suggests you had no "false hits" (i.e., that the inner loop returned on its first iteration, else the return value would have been wrong), which are probably the cases in which using memchr rather than the current code is least likely to slow things down. It's bad that the original code never bothered to document what it's supposed to return, but that's no excuse to return probabilistically-correct gibberish . From tim_one at email.msn.com Wed Jun 21 05:44:25 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 20 Jun 2000 23:44:25 -0400 Subject: [Python-Dev] list comprehensions In-Reply-To: <20000620132150.O8678@thyrsus.com> Message-ID: [Ka-Ping Yee] > I just have to say i thought list comprehensions were > really cool. [Eric S. Raymond] > Ditto. I would like to see this in 1.6. Nobody has been more vocal in support of these (& augmented assignments) than me, but I very strongly doubt they'll be in 1.6. In the interests of getting that out the door, Guido considers the 1.6 feature set to be frozen already. I think part of the pressure to get one more feature in Python (again & again & again) is that release cycles have been soooooo protracted, now slobbering well over the full year mark. If I accomplish nothing else at BeOpen, I want to give that a major speed boost -- I don't think we should ever let 6 months go by without at least pumping out a bugfix release. there-are-other-things-guido-doesn't-yet-know-he-believes-too-ly y'rs - tim From skip at mojam.com Wed Jun 21 06:33:12 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 20 Jun 2000 23:33:12 -0500 (CDT) Subject: [Python-Dev] feeble attempt at list comprehensions doc... Message-ID: <14672.17800.994102.266619@beluga.mojam.com> Attached to this message are two patches, one for Doc/ref/ref5.tex and one for Doc/tut/tut.tex. They provide minimal documentation for list comprehensions. I'm sure just about anyone else could do better. Feel free to embellish. The BNF used in the reference manual doesn't seem to match the BNF in the Grammar file very well, so I'm not even certain I have the correct BNF or have it in the correct place. In particular, I'm pretty sure the BNF for list_for and list_if are incorrect. -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On June 24th at 8AM, live your life for an hour as Ricky Byrdsong always lived his - run/walk in the Ricky Byrdsong Memorial 5K or just make a donation: https://www.SignmeupSports.com/Events/Index_Events.asp?EventID=1395 -------------- next part -------------- A non-text attachment was scrubbed... Name: tut.diff Type: application/octet-stream Size: 1000 bytes Desc: list comprehension diffs URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ref5.diff Type: application/octet-stream Size: 1141 bytes Desc: reference manual diff URL: From tim_one at email.msn.com Wed Jun 21 06:53:59 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 21 Jun 2000 00:53:59 -0400 Subject: [Python-Dev] Warnings in mmapmodule Message-ID: I get these warnings in Modules/mmapmodule.c, all about signed/unsigned mismatches: Modules\mmapmodule.c(571) : warning C4018: '>=' : signed/unsigned mismatch if (i < 0 || i >= self->size) { Modules\mmapmodule.c(586) : warning C4018: '>' : signed/unsigned mismatch else if (ilow > self->size) Modules\mmapmodule.c(592) : warning C4018: '>' : signed/unsigned mismatch else if (ihigh > self->size) Modules\mmapmodule.c(631) : warning C4018: '>' : signed/unsigned mismatch else if (ilow > self->size) Modules\mmapmodule.c(637) : warning C4018: '>' : signed/unsigned mismatch else if (ihigh > self->size) Modules\mmapmodule.c(664) : warning C4018: '>=' : signed/unsigned mismatch if (i < 0 || i >= self->size) { I'll volunteer to fix these if nobody else does (although at the moment I'm not able to produce either a patch or check in). new-laptops-in-hotel-rooms-have-their-limitations-ly y'rs - tim From mhammond at skippinet.com.au Wed Jun 21 06:57:54 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Wed, 21 Jun 2000 14:57:54 +1000 Subject: [Python-Dev] Warnings in mmapmodule In-Reply-To: Message-ID: > I get these warnings in Modules/mmapmodule.c, all about signed/unsigned > mismatches: Me too :-) > I'll volunteer to fix these if nobody else does (although at the > moment I'm > not able to produce either a patch or check in). I nearly did, but then couldnt find the time to chase up how Unix declared the relevant items - I didnt want to assume they were identical to Windows. My intention was to make the patch, then test it out on my gleaming Linux box. But-the-road-to-hell-is-paved-with-good-intentions-ly, Mark. From tim_one at email.msn.com Wed Jun 21 07:22:37 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 21 Jun 2000 01:22:37 -0400 Subject: [Python-Dev] Warnings in mmapmodule In-Reply-To: Message-ID: [posted & mailed] [Tim] > I get these warnings in Modules/mmapmodule.c, all about signed/unsigned > mismatches: [Mark Hammond] > Me too :-) > > I nearly [fixed them], but then couldnt find the time to chase up how > Unix declared the relevant items - I didnt want to assume they were > identical to Windows. They all involve mixing ints with mmap_object.size in comparisons, which latter is declared size_t and so will resolve to *some* unsigned integral type on all platforms. The proper fix is to get rid of the ints before making these tests -- ask Trent, he should be able to do this in his sleep now . > My intention was to make the patch, then test it out on my gleaming Linux > box. > > But-the-road-to-hell-is-paved-with-good-intentions-ly, No, it's paved with Linux: I've been using Windows so long I forgot why Unix is supposed to be more usable <0.9 wink>. Mark, if you've figured out how to do a SourceForge checkin from a Windows box, drop me a line offline! It would save me from figuring out which one of the 10,000 SSH+Windows search hits actually leads to something that works (and, no, so long as my entire life is sitting on my laptop, I'm not getting another OS anywhere near this box). becoming-a-linux-true-believer-again-is-on-my-schedule-but-not- for-a-couple-months-ly y'rs - tim From DavidA at ActiveState.com Wed Jun 21 07:40:36 2000 From: DavidA at ActiveState.com (David Ascher) Date: Tue, 20 Jun 2000 22:40:36 -0700 Subject: [Python-Dev] Warnings in mmapmodule In-Reply-To: Message-ID: > No, it's paved with Linux: I've been using Windows so long I forgot why > Unix is supposed to be more usable <0.9 wink>. Mark, if you've > figured out > how to do a SourceForge checkin from a Windows box, drop me a > line offline! No, please, drop us all a line online! I've decided that I'm not going to waste any more of my time dealing w/ SourceForge. Luckily I seem to have found some helpers for the PyOpenGL transition who are willing to deal with that! --david From mhammond at skippinet.com.au Wed Jun 21 07:49:45 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Wed, 21 Jun 2000 15:49:45 +1000 Subject: [Python-Dev] CVS and SSH under windows. In-Reply-To: Message-ID: [David] > No, please, drop us all a line online! OK - here it is, for what it is worth. You will notice that I spent the time to research my facts carefully before giving out this information (NOT!) Sure. It is a bit of a PITA (surprise, surprise, surprise): First, get the latest WinCVS. Has some nice new features. Mine shows as 1.1b13. It has a slightly ?slicker? more windowsy look than the older one. What we really want is the version with the Options/Preferences dialog that allows you to supply the ?RAS identity? file when you select ?SSH Server? as the auth method. Previous versions allow you to select the SSH Server, but give you nowhere to put the identity file. Hence previous versions used a batch file wrapper, which you probably saw reference to. This version makes it much simpler. I use the standard SSH Version 1.2.14 binary set. I cant recall the URL, but it is quite small and only a few binary files. ?ssh? shows usage - ?ssh -v? shows versbose usage, ?verbose? in this context apparently means showing the version number (took me ages to work that one out :-) There were only a few files, so I just dumped them all in the same directory as the CVS binaries. You then need to make a ?key? file - I cant recall the exact process, but it is pretty simple. This is creating the identify file you specify to WinCVS, as well as the public key you upload to source-force. NOTE - from memory, you MUST have a HOME env var set, and you MUST have a ?.ssh? directory under your home. Otherwise you get cryptic errors from SSH that give no clue that this is the problem. After uploading the public key to source forge, you are nearly set. The last step is convinving CVS that you want to use this new SSH setting, and not the setting CVS so kindly persists in its ?CVS\Root? files. The only way I found to do this was to either edit the Root files manually, or remove the directories locally and force CVS to re-create them (and thereby re-pull everything - I assume you have ADSL in that hotel room :-) Alternatively, dig up that CVS script posted to py-dev recently and change it - personally, I never trusted it :-) All my root files look like: :ext:mhammond at cvs.python.sourceforge.net:/cvsroot/python Yours almost certainly will be setup for anon access, not using ssh. Hope that makes sense. Im happy to chase anything else up I can for you... Mark. From effbot at telia.com Wed Jun 21 09:58:06 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 21 Jun 2000 09:58:06 +0200 Subject: [Python-Dev] talking about performance... References: Message-ID: <006401bfdb56$6f84ae60$f2a6b5d4@hagrid> tim wrote: > > p = memchr(s, sub[0], e - s); > > if (p == NULL) > > break; > > if (n == 1 || memcmp(p, sub, n) == 0) > > return (long) (p - s); > I expect that whether this is faster or slower depends on both the compiler > you're using and the exact strings you're using to time it. With test strings that contain false matches for every single position, it's 30% slower than the old code in my tests. With test strings that contain no false matches, it's 50% faster. But without more extensive tests on a variety of platforms, we might as well forget about this one... From mal at lemburg.com Wed Jun 21 10:23:02 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 21 Jun 2000 10:23:02 +0200 Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions... References: Message-ID: <39507B66.763DB418@lemburg.com> [Skip's exit.py module + David's extension to support already registered exitfunc'tions] Looks like everyone agrees -- with a final word from Guido we'd only need some docs to go with it and then check Skip's module in as new standard module. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From skip at mojam.com Wed Jun 21 15:38:01 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 21 Jun 2000 08:38:01 -0500 (CDT) Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions... In-Reply-To: <39507B66.763DB418@lemburg.com> References: <39507B66.763DB418@lemburg.com> Message-ID: <14672.50489.611301.616242@beluga.mojam.com> MA> Looks like everyone agrees -- with a final word from Guido we'd only MA> need some docs to go with it and then check Skip's module in as new MA> standard module. I'll try to get David's enhancement added to my code and write some simple documentation today. Is "exit.py" acceptable with everyone as the name of the module? Skip From skip at mojam.com Wed Jun 21 20:15:19 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 21 Jun 2000 13:15:19 -0500 (CDT) Subject: [Python-Dev] updated exit.py and supporting files for your perusal Message-ID: <14673.1591.506532.170015@beluga.mojam.com> This message contains four attached files: Lib/exit.py - a module that allows users to register cleanup functions Lib/test/test_exit.py - a simple test script Lib/test/output/test_exit - expected test output Doc/lib/libexit.tex - library reference manual section Besides adding documentation and a test script, the following two mods were made to exit.py since I previously posted it: 1. It implements a LIFO execution order 2. If sys.exitfunc is already defined and not exit._run_exitfuncs, it is treated as an exit function and appended to the exit function list. Comments, please. Also, can someone tell me how to coax CVS into creating a unified diff that actually contains new files? I tried cvs diff -RNau without success. Thanks, -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On June 24th at 8AM, live your life for an hour as Ricky Byrdsong always lived his - run/walk in the Ricky Byrdsong Memorial 5K or just make a donation: https://www.SignmeupSports.com/Events/Index_Events.asp?EventID=1395 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: exit.py URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: test_exit.py URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: test_exit URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: libexit.tex URL: From trentm at activestate.com Wed Jun 21 21:20:12 2000 From: trentm at activestate.com (Trent Mick) Date: Wed, 21 Jun 2000 12:20:12 -0700 Subject: [Python-Dev] Warnings in mmapmodule In-Reply-To: References: Message-ID: <20000621122012.A28236@activestate.com> On Wed, Jun 21, 2000 at 01:22:37AM -0400, Tim Peters wrote: > [posted & mailed] > > [Tim] > > I get these warnings in Modules/mmapmodule.c, all about signed/unsigned > > mismatches: > > [Mark Hammond] > > Me too :-) > > > > I nearly [fixed them], but then couldnt find the time to chase up how > > Unix declared the relevant items - I didnt want to assume they were > > identical to Windows. > > They all involve mixing ints with mmap_object.size in comparisons, which > latter is declared size_t and so will resolve to *some* unsigned integral > type on all platforms. The proper fix is to get rid of the ints before > making these tests -- ask Trent, he should be able to do this in his sleep > now . > I wish I could do it in my sleep, then I would be much more well rested. Yes I will clean these up. I was going to look at mmap a little anyway as test_mmap currently fails on Win32 (probably as a resul of my mmpa patch). Trent -- Trent Mick trentm at activestate.com From DavidA at ActiveState.com Wed Jun 21 19:25:07 2000 From: DavidA at ActiveState.com (David Ascher) Date: Wed, 21 Jun 2000 10:25:07 -0700 Subject: [Python-Dev] CVS and SSH under windows. In-Reply-To: Message-ID: > First, get the latest WinCVS. http://www.wincvs.org/download.html > I use the standard SSH Version 1.2.14 binary set. I cant recall the URL, There's a version at: ftp://ftp.cs.hut.fi/pub/ssh/contrib/ssh-1.2.14-win32bin.zip BUT... > You then need to make a ?key? file - I cant recall the exact process, but > it is pretty simple. This is creating the identify file you specify to > WinCVS, as well as the public key you upload to source-force. C:\WinCVS>ssh-keygen I always get a 'gethostname: no such file or directory' so I had to create the key on Linux (as is mentioned in the page http://bmrc.berkeley.edu/people/chaffee/winntutil.html). Maybe you have a better binary for ssh? > NOTE - from memory, you MUST have a HOME env var set, and you MUST have a > ?.ssh? directory under your home. Otherwise you get cryptic errors from > SSH that give no clue that this is the problem. > > After uploading the public key to source forge, you are nearly set. How do you do that? > The > last step is convinving CVS that you want to use this new SSH setting, and > not the setting CVS so kindly persists in its ?CVS\Root? files. The only > way I found to do this was to either edit the Root files manually, or > remove the directories locally and force CVS to re-create them > (and thereby > re-pull everything - I assume you have ADSL in that hotel room :-) > Alternatively, dig up that CVS script posted to py-dev recently and change > it - personally, I never trusted it :-) > > All my root files look like: > :ext:mhammond at cvs.python.sourceforge.net:/cvsroot/python > > Yours almost certainly will be setup for anon access, not using ssh. > > Hope that makes sense. Im happy to chase anything else up I can > for you... > > Mark. > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev > From akuchlin at cnri.reston.va.us Wed Jun 21 22:27:31 2000 From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling) Date: Wed, 21 Jun 2000 16:27:31 -0400 Subject: [Python-Dev] Patch management (was: Warnings in pythonrun.c) In-Reply-To: <14673.158.183876.75480@localhost.localdomain>; from jeremy@beopen.com on Wed, Jun 21, 2000 at 01:51:26PM -0400 References: <008c01bfdb58$103e8140$f2a6b5d4@hagrid> <14673.158.183876.75480@localhost.localdomain> Message-ID: <20000621162731.B3918@amarok.cnri.reston.va.us> On Wed, Jun 21, 2000 at 01:51:26PM -0400, Jeremy Hylton wrote: >>>>>> "TP" == Tim Peters writes: > TP> + This mailing list doesn't work. At least the SourceForge >I agree that it's a complete mess, though. While you're all admiring the difficulty of the problem, how about actually checking in the pythonrun.c patch, assuming it's reasonable? Frankly, I don't think the current mailing list is broken, *as long as patches are handled with reasonable speed* so that the backlog doesn't build up. That hasn't been done, and I don't understand why. Obviously the CNRI->BeOpen transaction resulted in some downtime for everyone, but now it's a month later and there's still stagnation. Why aren't incoming patches being handled now? It's not like there are very many patches per day; an hour or two should suffice to keep the queue from growing. At this point, the best fix is to do two things: 1) Someone downloads the mbox archives of the patches list, and goes through all the past patches: apply them, discard them, send them back for revision. 2) Commit to handling new patches that arrive, and either apply/discard/revise them. Worrying about patch management mechanism, while more patches pile up and are ignored in the meantime, is not going to help and will just results in continued stagnation. -- A.M. Kuchling http://starship.python.net/crew/amk/ I couldn't think of one clever way to stop this guy, so I just trusted to mindless violence. -- Cliff Steele in DOOM PATROL #21 From akuchlin at cnri.reston.va.us Wed Jun 21 22:27:31 2000 From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling) Date: Wed, 21 Jun 2000 16:27:31 -0400 Subject: [Python-Dev] Patch management (was: Warnings in pythonrun.c) In-Reply-To: <14673.158.183876.75480@localhost.localdomain>; from jeremy@beopen.com on Wed, Jun 21, 2000 at 01:51:26PM -0400 References: <008c01bfdb58$103e8140$f2a6b5d4@hagrid> <14673.158.183876.75480@localhost.localdomain> Message-ID: <20000621162731.B3918@amarok.cnri.reston.va.us> On Wed, Jun 21, 2000 at 01:51:26PM -0400, Jeremy Hylton wrote: >>>>>> "TP" == Tim Peters writes: > TP> + This mailing list doesn't work. At least the SourceForge >I agree that it's a complete mess, though. While you're all admiring the difficulty of the problem, how about actually checking in the pythonrun.c patch, assuming it's reasonable? Frankly, I don't think the current mailing list is broken, *as long as patches are handled with reasonable speed* so that the backlog doesn't build up. That hasn't been done, and I don't understand why. Obviously the CNRI->BeOpen transaction resulted in some downtime for everyone, but now it's a month later and there's still stagnation. Why aren't incoming patches being handled now? It's not like there are very many patches per day; an hour or two should suffice to keep the queue from growing. At this point, the best fix is to do two things: 1) Someone downloads the mbox archives of the patches list, and goes through all the past patches: apply them, discard them, send them back for revision. 2) Commit to handling new patches that arrive, and either apply/discard/revise them. Worrying about patch management mechanism, while more patches pile up and are ignored in the meantime, is not going to help and will just results in continued stagnation. -- A.M. Kuchling http://starship.python.net/crew/amk/ I couldn't think of one clever way to stop this guy, so I just trusted to mindless violence. -- Cliff Steele in DOOM PATROL #21 From akuchlin at cnri.reston.va.us Wed Jun 21 22:27:31 2000 From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling) Date: Wed, 21 Jun 2000 16:27:31 -0400 Subject: [Python-Dev] Patch management (was: Warnings in pythonrun.c) In-Reply-To: <14673.158.183876.75480@localhost.localdomain>; from jeremy@beopen.com on Wed, Jun 21, 2000 at 01:51:26PM -0400 References: <008c01bfdb58$103e8140$f2a6b5d4@hagrid> <14673.158.183876.75480@localhost.localdomain> Message-ID: <20000621162731.B3918@amarok.cnri.reston.va.us> On Wed, Jun 21, 2000 at 01:51:26PM -0400, Jeremy Hylton wrote: >>>>>> "TP" == Tim Peters writes: > TP> + This mailing list doesn't work. At least the SourceForge >I agree that it's a complete mess, though. While you're all admiring the difficulty of the problem, how about actually checking in the pythonrun.c patch, assuming it's reasonable? Frankly, I don't think the current mailing list is broken, *as long as patches are handled with reasonable speed* so that the backlog doesn't build up. That hasn't been done, and I don't understand why. Obviously the CNRI->BeOpen transaction resulted in some downtime for everyone, but now it's a month later and there's still stagnation. Why aren't incoming patches being handled now? It's not like there are very many patches per day; an hour or two should suffice to keep the queue from growing. At this point, the best fix is to do two things: 1) Someone downloads the mbox archives of the patches list, and goes through all the past patches: apply them, discard them, send them back for revision. 2) Commit to handling new patches that arrive, and either apply/discard/revise them. Worrying about patch management mechanism, while more patches pile up and are ignored in the meantime, is not going to help and will just results in continued stagnation. -- A.M. Kuchling http://starship.python.net/crew/amk/ I couldn't think of one clever way to stop this guy, so I just trusted to mindless violence. -- Cliff Steele in DOOM PATROL #21 From guido at python.org Thu Jun 22 00:55:22 2000 From: guido at python.org (Guido van Rossum) Date: Wed, 21 Jun 2000 17:55:22 -0500 Subject: [Python-Dev] updated exit.py and supporting files for your perusal In-Reply-To: Your message of "Wed, 21 Jun 2000 13:15:19 EST." <14673.1591.506532.170015@beluga.mojam.com> References: <14673.1591.506532.170015@beluga.mojam.com> Message-ID: <200006212255.RAA02444@cj20424-a.reston1.va.home.com> If I had designed this, I might have called the module "onexit" or "atexit" and the public function simply "register()". But I've got only a +0 for my own proposal. A +1 for the general idea. --Guido van Rossum (home page: http://www.python.org/~guido/) From paul at prescod.net Thu Jun 22 00:13:39 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 21 Jun 2000 17:13:39 -0500 Subject: [Python-Dev] list comprehensions References: Message-ID: <39513E13.F8082811@prescod.net> Tim Peters wrote: > > ... > Nobody has been more vocal in support of these (& augmented assignments) > than me, but I very strongly doubt they'll be in 1.6. In the interests of > getting that out the door, Guido considers the 1.6 feature set to be frozen > already. Is there an argument for putting in features with flaming red neon lights: "warning, experimental, use at your risk." We want to follow a bazaar (if not outright bizarre) development strategy after all. Putting a patch "out there" really doesn't do much about having people really play with and comment on a feature. I would never have experimented (and decided against using...) metaclasses if they hadn't popped up as an experimental feature. Of course if there is a decent chance of breaking something already in there that works then that's another issue... > I think part of the pressure to get one more feature in Python (again & > again & again) is that release cycles have been soooooo protracted, now > slobbering well over the full year mark. Nah, no matter how quick you do the turnarounds, nobody wants to wait for their favorite feature. :) -- Paul Prescod - ISOGEN Consulting Engineer speaking for himself Floggings will continue until morale improves. From DavidA at ActiveState.com Wed Jun 21 19:25:07 2000 From: DavidA at ActiveState.com (David Ascher) Date: Wed, 21 Jun 2000 10:25:07 -0700 Subject: [Python-Dev] CVS and SSH under windows. In-Reply-To: Message-ID: > First, get the latest WinCVS. http://www.wincvs.org/download.html > I use the standard SSH Version 1.2.14 binary set. I cant recall the URL, There's a version at: ftp://ftp.cs.hut.fi/pub/ssh/contrib/ssh-1.2.14-win32bin.zip BUT... > You then need to make a ?key? file - I cant recall the exact process, but > it is pretty simple. This is creating the identify file you specify to > WinCVS, as well as the public key you upload to source-force. C:\WinCVS>ssh-keygen I always get a 'gethostname: no such file or directory' so I had to create the key on Linux (as is mentioned in the page http://bmrc.berkeley.edu/people/chaffee/winntutil.html). Maybe you have a better binary for ssh? > NOTE - from memory, you MUST have a HOME env var set, and you MUST have a > ?.ssh? directory under your home. Otherwise you get cryptic errors from > SSH that give no clue that this is the problem. > > After uploading the public key to source forge, you are nearly set. How do you do that? > The > last step is convinving CVS that you want to use this new SSH setting, and > not the setting CVS so kindly persists in its ?CVS\Root? files. The only > way I found to do this was to either edit the Root files manually, or > remove the directories locally and force CVS to re-create them > (and thereby > re-pull everything - I assume you have ADSL in that hotel room :-) > Alternatively, dig up that CVS script posted to py-dev recently and change > it - personally, I never trusted it :-) > > All my root files look like: > :ext:mhammond at cvs.python.sourceforge.net:/cvsroot/python > > Yours almost certainly will be setup for anon access, not using ssh. > > Hope that makes sense. Im happy to chase anything else up I can > for you... > > Mark. > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev > From nascheme at enme.ucalgary.ca Thu Jun 22 02:25:46 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Wed, 21 Jun 2000 18:25:46 -0600 Subject: [Python-Dev] updated exit.py and supporting files for your perusal In-Reply-To: <14673.1591.506532.170015@beluga.mojam.com>; from skip@mojam.com on Wed, Jun 21, 2000 at 01:15:19PM -0500 References: <14673.1591.506532.170015@beluga.mojam.com> Message-ID: <20000621182546.B25879@acs.ucalgary.ca> On Wed, Jun 21, 2000 at 01:15:19PM -0500, Skip Montanaro wrote: > Also, can someone tell me how to coax CVS into creating a > unified diff that actually contains new files? I tried > > cvs diff -RNau > > without success. Did you "cvs add" them? Neil -- "Simplicity does not precede complexity, but follows it." -- Alan Perlis From skip at mojam.com Thu Jun 22 02:39:03 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 21 Jun 2000 19:39:03 -0500 (CDT) Subject: [Python-Dev] updated exit.py and supporting files for your perusal In-Reply-To: <20000621182546.B25879@acs.ucalgary.ca> References: <14673.1591.506532.170015@beluga.mojam.com> <20000621182546.B25879@acs.ucalgary.ca> Message-ID: <14673.24615.291912.261214@beluga.mojam.com> >> Also, can someone tell me how to coax CVS into creating a unified >> diff that actually contains new files? I tried >> >> cvs diff -RNau >> >> without success. Neil> Did you "cvs add" them? Not something I could do, since I'm cvs'ing against the sourceforge repository. The best I guess I can do is to mirror the repository twice, add the new files to one tree, then perform a regular diff... Skip From esr at thyrsus.com Thu Jun 22 04:09:35 2000 From: esr at thyrsus.com (esr at thyrsus.com) Date: Wed, 21 Jun 2000 22:09:35 -0400 Subject: [Python-Dev] list comprehensions In-Reply-To: References: <20000620132150.O8678@thyrsus.com> Message-ID: <20000621220934.A1044@thyrsus.com> Tim Peters : > Nobody has been more vocal in support of these (& augmented assignments) > than me, but I very strongly doubt they'll be in 1.6. In the interests of > getting that out the door, Guido considers the 1.6 feature set to be frozen > already. > > I think part of the pressure to get one more feature in Python (again & > again & again) is that release cycles have been soooooo protracted, now > slobbering well over the full year mark. If I accomplish nothing else at > BeOpen, I want to give that a major speed boost -- I don't think we should > ever let 6 months go by without at least pumping out a bugfix release. OK, I can buy this. Are there concrete plans (as in, a specified timeframe) for a release in which new features will be admitted? -- Eric S. Raymond What, then is law [government]? It is the collective organization of the individual right to lawful defense." -- Frederic Bastiat, "The Law" From mal at lemburg.com Thu Jun 22 11:05:09 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 22 Jun 2000 11:05:09 +0200 Subject: [Python-Dev] updated exit.py and supporting files for your perusal References: <14673.1591.506532.170015@beluga.mojam.com> Message-ID: <3951D6C5.BA31276B@lemburg.com> > This message contains four attached files: > > Lib/exit.py - a module that allows users to register cleanup functions > Lib/test/test_exit.py - a simple test script > Lib/test/output/test_exit - expected test output > Doc/lib/libexit.tex - library reference manual section > > Besides adding documentation and a test script, the following two mods were > made to exit.py since I previously posted it: > > 1. It implements a LIFO execution order > 2. If sys.exitfunc is already defined and not exit._run_exitfuncs, it is > treated as an exit function and appended to the exit function list. > > Comments, please. Looks ok to me, but since this is going to be a new standard module I guess we should wait for Guido's ok before checking it in. > Also, can someone tell me how to coax CVS into creating a > unified diff that actually contains new files? I tried > > cvs diff -RNau > > without success. I'm not an CVS expert, but I could imagine that you'll have to add the files to CVS first and then run the above diff. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gstein at lyra.org Thu Jun 22 15:30:53 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 22 Jun 2000 06:30:53 -0700 Subject: [Python-Dev] CVS and SSH under windows. In-Reply-To: ; from DavidA@ActiveState.com on Wed, Jun 21, 2000 at 10:25:07AM -0700 References: Message-ID: <20000622063053.M29590@lyra.org> On Wed, Jun 21, 2000 at 10:25:07AM -0700, David Ascher wrote: >... > > You then need to make a ?key? file - I cant recall the exact process, but > > it is pretty simple. This is creating the identify file you specify to > > WinCVS, as well as the public key you upload to source-force. > > C:\WinCVS>ssh-keygen > > I always get a 'gethostname: no such file or directory' so I had to create > the key on Linux (as is mentioned in the page > http://bmrc.berkeley.edu/people/chaffee/winntutil.html). > > Maybe you have a better binary for ssh? Nah. Mark just forgets that I generated the key for him from my Linux box :-) hehe... Cheers, -g -- Greg Stein, http://www.lyra.org/ From tim_one at email.msn.com Thu Jun 22 15:46:15 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 22 Jun 2000 09:46:15 -0400 Subject: [Python-Dev] SourceForge vs Windows In-Reply-To: Message-ID: I have to get SourceForge developer access working with Windows (Win98SE, specifically), so I'll write up detailed instructions along the way, building on Mark Hammond's good clues. Play along! I'll accumulate everyone's input & make a coherent how-to out of it. Today's installment only covers the first step, as it took 12 hours for meto complete it (rotten connectivity today, via 56K modem, requiring many attempts at downloading before one succeeded): [Mark Hammond] > First, get the latest WinCVS. Has some nice new features. Mine shows > as 1.1b13. It has a slightly ?slicker? more windowsy look than the > older one. What we really want is the version with the Options/Preferences > dialog that allows you to supply the ?RAS identity? file when you select > ?SSH Server? as the auth method. Previous versions allow you to select > the SSH Server, but give you nowhere to put the identity file. Hence > previous versions used a batch file wrapper, which you probably saw > reference to. This version makes it much simpler. I picked up the 1.1b14 version, released 19 Jun 2000, from http://www.wincvs.org/download.html It's a 3.21 Mb zip file. hard-to-blow-it-so-far-ly y'rs - tim From tim_one at email.msn.com Thu Jun 22 15:46:17 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 22 Jun 2000 09:46:17 -0400 Subject: [Python-Dev] list comprehensions In-Reply-To: <20000621220934.A1044@thyrsus.com> Message-ID: [Tim, sez the 1.6 feature set should be considered frozen, and that Python should move to a much less sloth-like release schedule thereafter] [esr at thyrsus.com] > OK, I can buy this. Comes with a 30-day warranty, too . > Are there concrete plans (as in, a specified timeframe) > for a release in which new features will be admitted? There damn well ought to be. PythonLabs will be having its first all-hands meeting tomorrow (Guido's been gone, I've been in this state less than a week, & I'm still not sure Jeremy Hylton exists), and rational, timely release schedules are certainly on my agenda. I have no problem with new features in minor releases either, provided they're 100% backward-compatible (e.g., list comprehensions, yes (so long as they don't introduce new bytecodes); having str(long) strip the trailing "L", no). More when we know more. and-less-when-we-know-less-ly y'rs - tim From nascheme at enme.ucalgary.ca Thu Jun 22 17:24:16 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Thu, 22 Jun 2000 09:24:16 -0600 Subject: [Python-Dev] updated exit.py and supporting files for your perusal In-Reply-To: <14673.24615.291912.261214@beluga.mojam.com>; from skip@mojam.com on Wed, Jun 21, 2000 at 07:39:03PM -0500 References: <14673.1591.506532.170015@beluga.mojam.com> <20000621182546.B25879@acs.ucalgary.ca> <14673.24615.291912.261214@beluga.mojam.com> Message-ID: <20000622092416.A31223@acs.ucalgary.ca> On Wed, Jun 21, 2000 at 07:39:03PM -0500, Skip Montanaro wrote: > Neil> Did you "cvs add" them? > > Not something I could do, since I'm cvs'ing against the sourceforge > repository. That's okay. "cvs add" only modifies things locally. You have to "cvs commit" to change things in the repository. Neil -- The internet: Learn what you know. Share what you don't. From klm at digicool.com Thu Jun 22 18:13:46 2000 From: klm at digicool.com (Ken Manheimer) Date: Thu, 22 Jun 2000 12:13:46 -0400 (EDT) Subject: [Python-Dev] CVS and SSH under windows. In-Reply-To: <20000622063053.M29590@lyra.org> Message-ID: A bit of a tangent, but MindTerm - http://www.mindbright.se/mindterm - is a pretty nice java SSH client which you can use on windows to generate the RSA identity. (It also is a fine SSH client, with just about all the nicities except compression - scp, x11 forwarding, arbitrary tunneling, etc are all in there...) Ken klm at digicool.com On Thu, 22 Jun 2000, Greg Stein wrote: > On Wed, Jun 21, 2000 at 10:25:07AM -0700, David Ascher wrote: > >... > > > You then need to make a ?key? file - I cant recall the exact process, but > > > it is pretty simple. This is creating the identify file you specify to > > > WinCVS, as well as the public key you upload to source-force. > > > > C:\WinCVS>ssh-keygen > > > > I always get a 'gethostname: no such file or directory' so I had to create > > the key on Linux (as is mentioned in the page > > http://bmrc.berkeley.edu/people/chaffee/winntutil.html). > > > > Maybe you have a better binary for ssh? > > Nah. Mark just forgets that I generated the key for him from my Linux box :-) > > hehe... > > Cheers, > -g > > -- > Greg Stein, http://www.lyra.org/ > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev > From skip at mojam.com Thu Jun 22 19:21:04 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 22 Jun 2000 12:21:04 -0500 (CDT) Subject: [Python-Dev] updated exit.py and supporting files for your perusal In-Reply-To: <200006212255.RAA02444@cj20424-a.reston1.va.home.com> References: <14673.1591.506532.170015@beluga.mojam.com> <200006212255.RAA02444@cj20424-a.reston1.va.home.com> Message-ID: <14674.19200.325533.979792@beluga.mojam.com> Guido> If I had designed this, I might have called the module "onexit" Guido> or "atexit" and the public function simply "register()". But Guido> I've got only a +0 for my own proposal. A +1 for the general Guido> idea. I'm happy to change things. I was a bit curious if people would ask about such a common word for a new module name. What module name do people prefer, "atexit", "onexit" (reads quickly like "one exit" if you're not careful), or something else? Skip From skip at mojam.com Thu Jun 22 19:27:18 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 22 Jun 2000 12:27:18 -0500 (CDT) Subject: [Python-Dev] updated exit.py and supporting files for your perusal In-Reply-To: <20000622092416.A31223@acs.ucalgary.ca> References: <14673.1591.506532.170015@beluga.mojam.com> <20000621182546.B25879@acs.ucalgary.ca> <14673.24615.291912.261214@beluga.mojam.com> <20000622092416.A31223@acs.ucalgary.ca> Message-ID: <14674.19574.609843.392230@beluga.mojam.com> Neil> That's okay. "cvs add" only modifies things locally. You have to Neil> "cvs commit" to change things in the repository. Ah, thanks for the tip. I'll try that next time... Skip From tim_one at email.msn.com Fri Jun 23 03:38:43 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 22 Jun 2000 21:38:43 -0400 Subject: [Python-Dev] RE: [Patches] Patch management (was: Warnings in pythonrun.c) In-Reply-To: <20000621162731.B3918@amarok.cnri.reston.va.us> Message-ID: [Andrew M. Kuchling] > While you're all admiring the difficulty of the problem, how about > actually checking in the pythonrun.c patch, assuming it's reasonable? I can't yet. Be my guest! > > > Frankly, I don't think the current mailing list is broken, *as long as > patches are handled with reasonable speed* so that the backlog doesn't > build up. Andrew, this is saying that if it didn't display all the symptoms of illness, it wouldn't be sick. The consistent (this started long before Guido's honeymoon!) lack of timely action here *is* the brokenness. > That hasn't been done, and I don't understand why. Why didn't you check in the pythonrun.c patch? Multiply by 10 people and 100 patches. There are no mechanisms in a mailing list for assigning, recording or checking responsibility, neither for recording or querying disposition status. Nobody owns any part of the problem now, and it's extraordinarly difficult to determine the status of any particular patch you may be interested in via this mish-mash of archived all-topic email scattered across patches and python-dev. Prior to this mailing list, Guido owned every problem and the database was in his head. I think it's the lack of the "owned" and "database" parts we're suffering from here, not especially the lack of the "Guido" part. SourceForge provides rudimentary mechanisms for both of the former; a Python replacement for Guido is one of BeOpen's highest secret priorities . > ... > Worrying about patch management mechanism, while more patches pile up > and are ignored in the meantime, is not going to help and will just > results in continued stagnation. At an all-hands PythonLabs group mtg today, it was decided to move patch activity to SourceForge and kill the patches list. I'll send more about that later. There is absolutely nothing new stopping checkins while the move to the SourceForge patch manager is in progress, so if the patches continue to pile up it's certainly not the move's fault. If the pythonrun.c patch is still sitting untouched after the move, I'll assign it to you <0.7 wink>. the-only-one-working-on-the-move-is-me-and-i-haven't-done-a-checkin- yet-anyway-ly y'rs - tim From mal at lemburg.com Fri Jun 23 10:03:41 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 23 Jun 2000 10:03:41 +0200 Subject: [Python-Dev] Re: [Patches] Patch management (was: Warnings in pythonrun.c) References: Message-ID: <395319DD.F2584321@lemburg.com> Tim Peters wrote: > > > Worrying about patch management mechanism, while more patches pile up > > and are ignored in the meantime, is not going to help and will just > > results in continued stagnation. > > At an all-hands PythonLabs group mtg today, it was decided to move patch > activity to SourceForge and kill the patches list. I'll send more about > that later. There is absolutely nothing new stopping checkins while the > move to the SourceForge patch manager is in progress, so if the patches > continue to pile up it's certainly not the move's fault. If the pythonrun.c > patch is still sitting untouched after the move, I'll assign it to you <0.7 > wink>. But how are we going to discuss new patches from people outside python-dev then ? I do see the use of moving patch submission to SourceForge, but posting the patches on the list for revision by everyone who listens is certainly better than having to scan the patch manager entries... (push strategies usually produce more feedback than pull ones). A gateway from the patch manager to the patches list would solve this nicely. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Vladimir.Marangozov at inrialpes.fr Fri Jun 23 12:00:23 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Fri, 23 Jun 2000 12:00:23 +0200 (CEST) Subject: [Python-Dev] updated exit.py and supporting files for your perusal In-Reply-To: <14674.19200.325533.979792@beluga.mojam.com> from "Skip Montanaro" at Jun 22, 2000 12:21:04 PM Message-ID: <200006231000.MAA03550@python.inrialpes.fr> Skip Montanaro wrote: > > > Guido> If I had designed this, I might have called the module "onexit" > Guido> or "atexit" and the public function simply "register()". But > Guido> I've got only a +0 for my own proposal. A +1 for the general > Guido> idea. > > I'm happy to change things. I was a bit curious if people would ask about > such a common word for a new module name. What module name do people > prefer, "atexit", "onexit" (reads quickly like "one exit" if you're not > careful), or something else? > > Skip atexit.py -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From mal at lemburg.com Fri Jun 23 12:08:46 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 23 Jun 2000 12:08:46 +0200 Subject: [Python-Dev] updated exit.py and supporting files for your perusal References: <200006231000.MAA03550@python.inrialpes.fr> Message-ID: <3953372E.274907AB@lemburg.com> Vladimir Marangozov wrote: > > Skip Montanaro wrote: > > > > > > Guido> If I had designed this, I might have called the module "onexit" > > Guido> or "atexit" and the public function simply "register()". But > > Guido> I've got only a +0 for my own proposal. A +1 for the general > > Guido> idea. > > > > I'm happy to change things. I was a bit curious if people would ask about > > such a common word for a new module name. What module name do people > > prefer, "atexit", "onexit" (reads quickly like "one exit" if you're not > > careful), or something else? > > > > Skip > > atexit.py How about exitfunc.py ? It would make the relation to sys.exitfunc pretty clear. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From akuchlin at cnri.reston.va.us Fri Jun 23 13:30:02 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Fri, 23 Jun 2000 07:30:02 -0400 Subject: [Python-Dev] Patch management In-Reply-To: <395319DD.F2584321@lemburg.com>; from mal@lemburg.com on Fri, Jun 23, 2000 at 10:03:41AM +0200 References: <395319DD.F2584321@lemburg.com> Message-ID: <20000623073002.B9385@newcnri.cnri.reston.va.us> On Fri, Jun 23, 2000 at 10:03:41AM +0200, M.-A. Lemburg wrote: >A gateway from the patch manager to the patches list would >solve this nicely. According to what was said to me, it's thought that mailing new patches to an e-mail address is supported, and therefore setting up a So, I no longer have much of a problem with moving patches to SF, though I *still* think the mailing list would be sufficient with a bit more focused effort; sorry, Tim! But at least we're not going to burn weeks looking at different patch manager products, and then arguing about them, which is what I feared most. --amk From bwarsaw at python.org Fri Jun 23 16:33:11 2000 From: bwarsaw at python.org (Barry A. Warsaw) Date: Fri, 23 Jun 2000 10:33:11 -0400 (EDT) Subject: [Python-Dev] updated exit.py and supporting files for your perusal References: <14674.19200.325533.979792@beluga.mojam.com> <200006231000.MAA03550@python.inrialpes.fr> Message-ID: <14675.29991.933911.446078@anthem.concentric.net> >>>>> "VM" == Vladimir Marangozov writes: VM> atexit.py +1 From gward at mems-exchange.org Fri Jun 23 17:42:03 2000 From: gward at mems-exchange.org (Greg Ward) Date: Fri, 23 Jun 2000 11:42:03 -0400 Subject: [Python-Dev] RFC: Including PIL in 1.6 In-Reply-To: <20000620140419.C10038@thyrsus.com>; from esr@thyrsus.com on Tue, Jun 20, 2000 at 02:04:19PM -0400 References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us> <20000620140419.C10038@thyrsus.com> Message-ID: <20000623114202.A1778@ludwig.cnri.reston.va.us> On 20 June 2000, esr at thyrsus.com said: > Watch that argument -- it could turn and bite you. What's the justification > for including, e.g. POP client classes in the standard distribution? > > One of Python's most important strengths is the "batteries *are* > included" richness of the standard environment. I totally agree. There are two extremes, both completely silly: include nothing with Python (except string, re, os, and sys -- because Distutils needs them ;-), and include every useful, working, documented module under the sun. I don't think anyone would seriously argue for either approach. (Although you could argue that a completely stripped-down Python might be useful in certain environments, eg. a hand-held. But I don't think you'd win that argument.) And I will be the first to admit that the Distutils still aren't good enough: in most respects, they're better than MakeMaker (IMHO), but there's nothing like CPAN.pm or the XEmacs package manager. And I know from personal experience that, amazing as CPAN.pm is, it's not The Answer; and others have attested, that XEmacs is pretty damn good but still not perfect. But I still don't think PIL should be included in the core, if only because it's one of the Distutils "test cases". ;-) Greg -- Greg Ward - software developer gward at mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From gward at mems-exchange.org Fri Jun 23 17:45:16 2000 From: gward at mems-exchange.org (Greg Ward) Date: Fri, 23 Jun 2000 11:45:16 -0400 Subject: [Python-Dev] list comprehensions In-Reply-To: <39513E13.F8082811@prescod.net>; from paul@prescod.net on Wed, Jun 21, 2000 at 05:13:39PM -0500 References: <39513E13.F8082811@prescod.net> Message-ID: <20000623114516.B1778@ludwig.cnri.reston.va.us> On 21 June 2000, Paul Prescod said: > Is there an argument for putting in features with flaming red neon > lights: "warning, experimental, use at your risk." We want to follow a > bazaar (if not outright bizarre) development strategy after all. Putting > a patch "out there" really doesn't do much about having people really > play with and comment on a feature. I would never have experimented (and > decided against using...) metaclasses if they hadn't popped up as an > experimental feature. Well, remember there will probably be a "--with-gc" option to the configure script in 1.6. That's a good example of getting an experimental feature out there. However, a "--with-list-comprehensions" option would be a really bad idea; all of a sudden, it's no longer enough to say, "You need Python 1.6" to run this script/use this module, now you need to say, "You need Python 1.6 built with list comprehensions". Ugh. Real language features should not be selectable: either the language is Python 1.6 or it isn't. Greg -- Greg Ward - software developer gward at mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From akuchlin at cnri.reston.va.us Fri Jun 23 17:54:02 2000 From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling) Date: Fri, 23 Jun 2000 11:54:02 -0400 Subject: [Python-Dev] list comprehensions In-Reply-To: <20000623114516.B1778@ludwig.cnri.reston.va.us>; from gward@mems-exchange.org on Fri, Jun 23, 2000 at 11:45:16AM -0400 References: <39513E13.F8082811@prescod.net> <20000623114516.B1778@ludwig.cnri.reston.va.us> Message-ID: <20000623115402.B4805@amarok.cnri.reston.va.us> On Fri, Jun 23, 2000 at 11:45:16AM -0400, Greg Ward wrote: >idea; all of a sudden, it's no longer enough to say, "You need Python >1.6" to run this script/use this module, now you need to say, "You need >Python 1.6 built with list comprehensions". Ugh. The same argument applies to --with-gc, though, since people might write code that creates cycles and needs GC to run without leaking like a sieve. Making GC optional is still the right solution, though, because its performance effects are still unknown and might be costly. --amk From gvwilson at nevex.com Fri Jun 23 18:09:36 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Fri, 23 Jun 2000 12:09:36 -0400 (EDT) Subject: [Python-Dev] Re: list comprehensions / garbage collection / optional features In-Reply-To: <20000623115402.B4805@amarok.cnri.reston.va.us> Message-ID: > >Greg Ward wrote: > >idea; all of a sudden, it's no longer enough to say, "You need Python > >1.6" to run this script/use this module, now you need to say, "You need > >Python 1.6 built with list comprehensions". Ugh. > Andrew Kuchling wrote: > The same argument applies to --with-gc, though, since people might > write code that creates cycles and needs GC to run without leaking > like a sieve. Making GC optional is still the right solution, though, > because its performance effects are still unknown and might be costly. Greg Wilson writes: I'm really looking forward to recycling my rusty SETL idioms when list comprehensions become part of the "official" release, and to creating graphs in the obvious way if GC ever becomes standard. However, the more variations there are in the "standard" (as opposed to "developer") release, the more expensive (in time and sweat) it is to manage Python at large sites (like Los Alamos). This in turn makes it harder to persuade people that using Python will make their lives easier... Thanks, Greg Footnote: The existence of JPython was one of the arguments in favor of choosing Python for the Software Carpentry project. The fact that JPython and CPython have very different memory management behaviors almost negated that point: as one thirty-year veteran said, "It's no use having code that runs in lots of places if it runs differently in each." From nascheme at enme.ucalgary.ca Fri Jun 23 19:12:51 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Fri, 23 Jun 2000 11:12:51 -0600 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Objects classobject.c,2.86,2.87 dictobject.c,2.52,2.53 funcobject.c,2.20,2.21 listobject.c,2.73,2.74 tupleobject.c,2.36,2.37 In-Reply-To: <200006231418.HAA02869@slayer.i.sourceforge.net>; from jhylton@users.sourceforge.net on Fri, Jun 23, 2000 at 07:18:13AM -0700 References: <200006231418.HAA02869@slayer.i.sourceforge.net> Message-ID: <20000623111251.B10850@acs.ucalgary.ca> On Fri, Jun 23, 2000 at 07:18:13AM -0700, Jeremy Hylton wrote: > Round 1 of Neil Schemenauer's GC patches: Yay. :) > + class_traverse(PyClassObject *o, visitproc visit, void *arg) > + { ... > + return 0; > + } > + instance_traverse(PyInstanceObject *o, visitproc visit, void *arg) > + { ... > + return 1; > + } Oops. I think "return 0" is the proper thing to do. There are a few other functions that return 1 as well. Neil From fdrake at acm.org Fri Jun 23 20:08:06 2000 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Fri, 23 Jun 2000 11:08:06 -0700 (PDT) Subject: [Python-Dev] out of touch Message-ID: <14675.42886.423185.310220@mailhost.beopen.com> My laptop has died, so I'm catching up with a couple of days of mail. I've not had time to look at Paul's proposed DOM-like additions to the standard library. Hopefully Andrew can (or has) summarized the relevant portions of our discussion from yesterday; if I don't see it, I'll try to get another message out later. (But I don't have my saved mail or files, so there's still not a lot I can do. ;( ) -Fred -- Fred L. Drake, Jr. From fdrake at beopen.com Fri Jun 23 21:04:55 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 23 Jun 2000 12:04:55 -0700 (PDT) Subject: [Python-Dev] updated exit.py and supporting files for your perusal In-Reply-To: <14674.19200.325533.979792@beluga.mojam.com> References: <14673.1591.506532.170015@beluga.mojam.com> <200006212255.RAA02444@cj20424-a.reston1.va.home.com> <14674.19200.325533.979792@beluga.mojam.com> Message-ID: <14675.46295.836727.117258@mailhost.beopen.com> Skip Montanaro writes: > I'm happy to change things. I was a bit curious if people would ask about > such a common word for a new module name. What module name do people > prefer, "atexit", "onexit" (reads quickly like "one exit" if you're not I like "atexit" better. -Fred -- Fred L. Drake, Jr. From guido at python.org Fri Jun 23 22:08:36 2000 From: guido at python.org (Guido van Rossum) Date: Fri, 23 Jun 2000 15:08:36 -0500 Subject: [Python-Dev] updated exit.py and supporting files for your perusal In-Reply-To: Your message of "Fri, 23 Jun 2000 12:04:55 MST." <14675.46295.836727.117258@mailhost.beopen.com> References: <14673.1591.506532.170015@beluga.mojam.com> <200006212255.RAA02444@cj20424-a.reston1.va.home.com> <14674.19200.325533.979792@beluga.mojam.com> <14675.46295.836727.117258@mailhost.beopen.com> Message-ID: <200006232008.PAA02759@cj20424-a.reston1.va.home.com> > Skip Montanaro writes: > > I'm happy to change things. I was a bit curious if people would ask about > > such a common word for a new module name. What module name do people > > prefer, "atexit", "onexit" (reads quickly like "one exit" if you're not [fred] > I like "atexit" better. OK, let it be atexit. I'm glad this time the naming debate is at least civilized. :-) --Guido van Rossum (home page: http://www.python.org/~guido/) From DavidA at ActiveState.com Fri Jun 23 21:30:31 2000 From: DavidA at ActiveState.com (David Ascher) Date: Fri, 23 Jun 2000 12:30:31 -0700 Subject: [Python-Dev] updated exit.py and supporting files for your perusal In-Reply-To: <200006232008.PAA02759@cj20424-a.reston1.va.home.com> Message-ID: > OK, let it be atexit. I'm glad this time the naming debate is at > least civilized. :-) No, wait, i think it should be exit_AT! Actually, I'm sick of this english-centricity. You american jerks are all the same! Go home Yankee! It should be en_sortant or nothing at all! --david "I try..." ascher From nascheme at enme.ucalgary.ca Fri Jun 23 22:11:03 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Fri, 23 Jun 2000 14:11:03 -0600 Subject: [Python-Dev] Fwd: Re: Linux/NT python startup speed Message-ID: <20000623141103.A13079@acs.ucalgary.ca> Has this been addressed yet for 1.6? It is probably an easy fix. The original poster claimed it took 4 seconds to start Python on his machine. Neil ----- Forwarded message from Johannes Stezenbach ----- Date: Thu, 22 Jun 2000 15:03:01 +0200 From: yawyi at gmx.de (Johannes Stezenbach) Subject: Re: Linux/NT python startup speed Niklas Frykholm wrote: >Can someone explain this difference. (The processor on the Linux system is >certainly not 40 times faster.) This was discussed here a few months ago. The reason for the slow startup is the winsound module (source: PC/winsound.c) which is unnecessarily a builtin. winsound causes Python to load the Windows multimedia DLLs, which can be slow if your sound drivers make it so. Two solutions were discussed: a) make winsound a .pyd b) use some obscure "delayload" feature of the M$ linker. There is a ready to use python15.dll for Python 1.5.2 with this feature somewhere out there (I don't remember where, though, since I use Linux now) IMHO solution a) should be standard in Python 1.6 (it isn't in 1.6a2). Johannes ----- End forwarded message ----- From tim_one at email.msn.com Fri Jun 23 22:11:47 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 23 Jun 2000 16:11:47 -0400 Subject: [Python-Dev] updated exit.py and supporting files for your perusal In-Reply-To: Message-ID: [Guido] >> OK, let it be atexit. I'm glad this time the naming debate is at >> least civilized. :-) {David Ascher] > No, wait, i think it should be exit_AT! > > Actually, I'm sick of this english-centricity. You american jerks are all > the same! Go home Yankee! It should be en_sortant or nothing at all! Oh, screw you and the frog you rode in, Frenchie. Using an inferior language is no excuse for poor grammar: "exit at" reads like a freeway sign, as in "Kentucky Fried Chicken, exit at 12B". en_sortant is no better -- worse, I have no idea what this has to do with arranging ants in order (and what kind of algorithm is en_sort anyway?). uponbutpriortoexiting is an idea that can't even be expressed in French, I bet. internationally y'rs - tim From guido at python.org Fri Jun 23 23:49:05 2000 From: guido at python.org (Guido van Rossum) Date: Fri, 23 Jun 2000 16:49:05 -0500 Subject: [Python-Dev] Fwd: Re: Linux/NT python startup speed In-Reply-To: Your message of "Fri, 23 Jun 2000 14:11:03 CST." <20000623141103.A13079@acs.ucalgary.ca> References: <20000623141103.A13079@acs.ucalgary.ca> Message-ID: <200006232149.QAA03157@cj20424-a.reston1.va.home.com> > Has this been addressed yet for 1.6? It is probably an easy fix. > The original poster claimed it took 4 seconds to start Python on > his machine. In 1.6, winsound is a separate subproject and hence a separately loadable DLL, so it doesn't slow down the main code. Ditto for socket and a few others. --Guido van Rossum (home page: http://www.python.org/~guido/) From jeremy at beopen.com Sat Jun 24 00:01:19 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 23 Jun 2000 18:01:19 -0400 Subject: [Python-Dev] Python 1.6 planning Message-ID: We discussed plans for Python 1.6 at the all-hands PythonLabs staff meeting yesterday. (At this meeting, the PythonLabs staff closed ranks and agreed to say that Tim Peters exists.) I'd like to quickly summarize plans. The target release date for Python 1.6 beta 1 is early July. Any code that is going to be in the beta must be checked in before July 1. Tim Peters pushed us to take care of the patches backlog. Our plan is to close the patches list and move all patch management to Sourceforge. We know the list is broken; we don't know that Sourceforge is broken. There are a bunch of modules and technical issues that must be resolved one way or another. SRE-- /F needs to finish this up. Unanswered question is whether the beta will ship with known bugs. GC-- Neil's garbage collector will be shipped as experimental feature requiring configure option. XML-- Some parts of the XML package will be included in the library under the xmlcore package. SAX and DOM (provided that it is stable enough). Andrew gets to decide, I believe. List comprehensions -- Next release. Despite the love fest at the meeting (everyone seems to want them), there is no way an implementation will be ready or stable enough. httplib-- We will include Greg Stein's new httplib, provided that it supports an old-style HTTPS class. curses-- one return type needs to be implemented (5-tuple). Andrew will finish ASAP. ESR's ascii module will be part of the curses package. imputil-- The imputil module will be dropped in the std library to enable wider distribution, but no changes will be made to the normal import machinery. Unicode shorthand-- Andrew will look at Bill Tutt's code. We intend to add it. Unicode compression-- We need to find out if Christian will be able to provide a compressed database. ldso_aix-- I still don't understand, but I didn't really try; Vladimir must help threads-- They will be on by default if the platform supports. gettext-- Barry will check in his gettext module. atexit.py-- add it Jeremy From nascheme at enme.ucalgary.ca Sat Jun 24 00:22:50 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Fri, 23 Jun 2000 16:22:50 -0600 Subject: [Python-Dev] Python 1.6 planning In-Reply-To: ; from jeremy@beopen.com on Fri, Jun 23, 2000 at 06:01:19PM -0400 References: Message-ID: <20000623162250.A14311@acs.ucalgary.ca> On Fri, Jun 23, 2000 at 06:01:19PM -0400, Jeremy Hylton wrote: > threads-- They will be on by default if the platform supports. Does the Linux thread/fork problem still exist? It would be nice to kill this before 1.6 final. I will test this with the CVS source this weekend. Neil From skip at mojam.com Sat Jun 24 03:09:04 2000 From: skip at mojam.com (Skip Montanaro) Date: Fri, 23 Jun 2000 20:09:04 -0500 Subject: [Python-Dev] test failures... Message-ID: <200006240109.UAA14738@beluga.mojam.com> Using the latest CVS code, I get failures for three tests on my Linux Mandrake 6.1 laptop: test test_exceptions failed -- Writing: 'spam', expected: 'Attr' test test_types crashed -- exceptions.OverflowError : long int too long to convert test test_long failed -- int(long(-sys.maxint-1)) overflowed! Are these known/expected or unknown/unexpected failures? From skip at mojam.com Sat Jun 24 03:27:39 2000 From: skip at mojam.com (Skip Montanaro) Date: Fri, 23 Jun 2000 20:27:39 -0500 (CDT) Subject: [Python-Dev] atexit.py patch Message-ID: <14676.3723.916135.602@beluga.mojam.com> Here's the latest version of my exit module. Per the earlier discussion, the module has been renamed to atexit.py. I also took the suggestion from someone (Guido?) that the registration function be renamed to simply "register". Other than that everything else should be the same. I'm only sending this to python-dev, operating under the assumption that the patches list is about to take a long vacation... -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille O'Neal said: "He's got the rings. I listen to the man with the rings." -------------- next part -------------- A non-text attachment was scrubbed... Name: atexit.diff Type: application/octet-stream Size: 4402 bytes Desc: atexit.py & doc URL: From trentm at activestate.com Sat Jun 24 04:19:23 2000 From: trentm at activestate.com (Trent Mick) Date: Fri, 23 Jun 2000 19:19:23 -0700 Subject: [Python-Dev] test failures... In-Reply-To: <200006240109.UAA14738@beluga.mojam.com> References: <200006240109.UAA14738@beluga.mojam.com> Message-ID: <20000623191923.A25730@activestate.com> On Fri, Jun 23, 2000 at 08:09:04PM -0500, Skip Montanaro wrote: > Using the latest CVS code, I get failures for three tests on my Linux > Mandrake 6.1 laptop: > > test test_exceptions failed -- Writing: 'spam', expected: 'Attr' Don't know about this one. > test test_types crashed -- exceptions.OverflowError : long int too long to convert This is related to some conversion checking that I added a while back, I believe. > test test_long failed -- int(long(-sys.maxint-1)) overflowed! > Same thing. Potentially this *should* overflow and the test should expect that. Don't take my word on this right now, only looked quickly. I will look at it this weekend (hopefully). Skip, I don't get the test failures, although I am a few days behind Python-CVS. Are these very new failures? Could you provide the verbose output from running these tests indepedently? Thanks. Trent -- Trent Mick trentm at activestate.com From tim_one at email.msn.com Sat Jun 24 04:32:46 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 23 Jun 2000 22:32:46 -0400 Subject: [Python-Dev] test failures... In-Reply-To: <200006240109.UAA14738@beluga.mojam.com> Message-ID: [Skip Montanaro] > Using the latest CVS code, I get failures for three tests on my Linux > Mandrake 6.1 laptop: > > test test_exceptions failed -- Writing: 'spam', expected: 'Attr' > test test_types crashed -- exceptions.OverflowError : long int > too long to convert > test test_long failed -- int(long(-sys.maxint-1)) overflowed! > > Are these known/expected or unknown/unexpected failures? First two don't ring a bell, last one has shown up several times & each time traced to an optimization bug, usually in a particular older version of gcc. Recompile with optimization off and see whether that makes all of them go away. If so, try using a recent gcc. From tim_one at email.msn.com Sat Jun 24 04:41:23 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 23 Jun 2000 22:41:23 -0400 Subject: [Python-Dev] test failures... In-Reply-To: <20000623191923.A25730@activestate.com> Message-ID: >> test test_types crashed -- exceptions.OverflowError : long >> int too long to convert > This is related to some conversion checking that I added a while back, I > believe. Possible but doubt it. >> test test_long failed -- int(long(-sys.maxint-1)) overflowed! > Same thing. Potentially this *should* overflow and the test should expect > that. Definitely not on this one: sys.maxint is by defn the largest positive Python int, so on any 2's-comp machine -sys.maxint-1 should be a legit Python int too. This bogus failure has popped up due to compiler optimization bugs under at least two older different compilers, though (gcc being by far the more often reported culprit -- I think the other was one of those HP compilers that seems to generate more bad code than good <0.3 wink>). The first step in test failures like this is to recompile with optimization off. From skip at mojam.com Sat Jun 24 05:45:04 2000 From: skip at mojam.com (Skip Montanaro) Date: Fri, 23 Jun 2000 22:45:04 -0500 (CDT) Subject: [Python-Dev] test failures... In-Reply-To: References: <200006240109.UAA14738@beluga.mojam.com> Message-ID: <14676.11968.263924.752216@beluga.mojam.com> >> test test_exceptions failed -- Writing: 'spam', expected: 'Attr' >> test test_types crashed -- exceptions.OverflowError : long int too long to convert >> test test_long failed -- int(long(-sys.maxint-1)) overflowed! Tim> First two don't ring a bell, last one has shown up several times & Tim> each time traced to an optimization bug, usually in a particular Tim> older version of gcc. Recompile with optimization off and see Tim> whether that makes all of them go away. If so, try using a recent Tim> gcc. Turning off optimization got rid of the test_types and test_long failures. The test_exceptins failure remains. Here's a diff: diff test_exceptions.save test_exceptions 2a3 > spam 3a5 > spam 4a7 > spam 5a9 > spam 6a11 > spam 7a13 > spam 8a15 > spam 10a18 > spam 12a21 > spam 13a23 > spam 14a25 > spam 16a28 > spam 17a30 > spam 19a33 > spam 20a35 > spam 21a37 > spam 22a39 > spam 23a41 > spam I'm not sure what that means, but it seems consistent. ;-) As for the age of my gcc, I think I'm reasonably current (only a bit over a year old): % gcc -v Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/pgcc-2.91.66/specs gcc version pgcc-2.91.66 19990314 (egcs-1.1.2 release) I will try downloading a newer RPM. Skip From ping at lfw.org Sat Jun 24 08:08:42 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Sat, 24 Jun 2000 01:08:42 -0500 (CDT) Subject: [Python-Dev] updated exit.py and supporting files for your perusal In-Reply-To: <200006232008.PAA02759@cj20424-a.reston1.va.home.com> Message-ID: On Fri, 23 Jun 2000, Guido van Rossum wrote: > [fred] > > I like "atexit" better. > > OK, let it be atexit. I'm glad this time the naming debate is at > least civilized. :-) Sorry to confuddle things, but what happened to the idea of sticking it in "sys"? If sys.exitfunc lives there, doesn't sys.atexit(...) also make sense? It can't be very hard to do... -- ?!ng From guido at python.org Sat Jun 24 18:03:07 2000 From: guido at python.org (Guido van Rossum) Date: Sat, 24 Jun 2000 11:03:07 -0500 Subject: [Python-Dev] test failures... In-Reply-To: Your message of "Fri, 23 Jun 2000 20:09:04 EST." <200006240109.UAA14738@beluga.mojam.com> References: <200006240109.UAA14738@beluga.mojam.com> Message-ID: <200006241603.LAA05123@cj20424-a.reston1.va.home.com> > test test_exceptions failed -- Writing: 'spam', expected: 'Attr' There's a "print buf" at the end of the new function test_raise_catch() that causes this. Jeremy added this; either the "print buf" shouldn't be there, or the file Lib/test/output/test_exceptions should be updated. It's up to Jeremy now. --Guido van Rossum (home page: http://www.python.org/~guido/) From skip at mojam.com Sat Jun 24 17:11:18 2000 From: skip at mojam.com (Skip Montanaro) Date: Sat, 24 Jun 2000 10:11:18 -0500 (CDT) Subject: [Python-Dev] updated exit.py and supporting files for your perusal In-Reply-To: References: <200006232008.PAA02759@cj20424-a.reston1.va.home.com> Message-ID: <14676.53142.263320.435588@beluga.mojam.com> Ping> Sorry to confuddle things, but what happened to the idea of Ping> sticking it in "sys"? If sys.exitfunc lives there, doesn't Ping> sys.atexit(...) also make sense? It can't be very hard to do... I like the general idea that stuff implemented in C is just a thin interface layer on top of existing system services and that higher level protocols are implemented in Python where there's no overriding need for them to be written in C. This fits that model, at least to a first approximation. The sys.exitfunc variable functions pretty much like calling the atexit(3) library call (though that's not how sys.exitfunc is implemented), and the atexit module provides a protocol that dictates how that mechanism is used in a cooperative setting. There's almost certainly no performance reason this code should be implemented in C. It's going to be easier to maintain and enhance if written in Python, and won't add size to the interpreter for those programmers who don't use it (or don't use other modules that do). -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille O'Neal said: "He's got the rings. I listen to the man with the rings." From nascheme at enme.ucalgary.ca Sat Jun 24 18:04:18 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Sat, 24 Jun 2000 10:04:18 -0600 Subject: [Python-Dev] test failures... In-Reply-To: ; from tim_one@email.msn.com on Fri, Jun 23, 2000 at 10:41:23PM -0400 References: <20000623191923.A25730@activestate.com> Message-ID: <20000624100418.A20411@acs.ucalgary.ca> On Fri, Jun 23, 2000 at 10:41:23PM -0400, Tim Peters wrote: > The first step in test failures like this is to recompile with > optimization off. Mandrake is known for shipping bad compilers. They used to ship pgcc as the default compiler even though it was know to have a lot of problems. Neil From tim_one at email.msn.com Sat Jun 24 19:27:19 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 24 Jun 2000 13:27:19 -0400 Subject: [Python-Dev] test failures... In-Reply-To: <14676.11968.263924.752216@beluga.mojam.com> Message-ID: [Skip Montanaro] > Turning off optimization got rid of the test_types and test_long failures. > The test_exceptins failure remains. Bingo, and Guido pinned test_exceptions on Jeremy. You can likely get a usable Python by disabling optimization only for longobject.c, if for some reason you need to stick with that compiler. > As for the age of my gcc, I think I'm reasonably current (only a > bit over a year old): > > % gcc -v > Reading specs from > /usr/lib/gcc-lib/i686-pc-linux-gnu/pgcc-2.91.66/specs > gcc version pgcc-2.91.66 19990314 (egcs-1.1.2 release) Well, I haven't had need of following the gcc/egcs soap opera, but I think "a year" (& particularly the last one ) is a lifetime in that saga. "2.95" rings a vague bell, as the only compiler in that line my former employer felt was usable for their development work under Linux. unlike-python-so-far-they've-had-some-bad-releases-ly y'rs - tim From tim_one at email.msn.com Sat Jun 24 19:30:54 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 24 Jun 2000 13:30:54 -0400 Subject: [Python-Dev] atexit.py patch In-Reply-To: <14676.3723.916135.602@beluga.mojam.com> Message-ID: [Skip] > I'm only sending this to python-dev, operating under the > assumption that the patches list is about to take a long vacation... Skip, if you can't put it on SourceForge for some reason (like what?), the patches list is certainly better than python-dev! I've got enough to do trying to disentangle multi-megabytes of patches-list archives that I'm not going to expand my search to other archives (like python-dev) too. From gstein at lyra.org Sat Jun 24 19:39:34 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 24 Jun 2000 10:39:34 -0700 Subject: [Python-Dev] test failures... In-Reply-To: ; from tim_one@email.msn.com on Sat, Jun 24, 2000 at 01:27:19PM -0400 References: <14676.11968.263924.752216@beluga.mojam.com> Message-ID: <20000624103934.Y29590@lyra.org> On Sat, Jun 24, 2000 at 01:27:19PM -0400, Tim Peters wrote: > [Skip Montanaro] > > Turning off optimization got rid of the test_types and test_long failures. > > The test_exceptins failure remains. > > Bingo, and Guido pinned test_exceptions on Jeremy. You can likely get a > usable Python by disabling optimization only for longobject.c, if for some > reason you need to stick with that compiler. Euh... shouldn't we insert some defensive code into longobject.c? Great, Skip knows to disable opt for that file... what about all the other people? Cheers, -g -- Greg Stein, http://www.lyra.org/ From tim_one at email.msn.com Sat Jun 24 19:42:29 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 24 Jun 2000 13:42:29 -0400 Subject: [Python-Dev] Patch management In-Reply-To: <20000623073002.B9385@newcnri.cnri.reston.va.us> Message-ID: [Andrew Kuchling] > ... > So, I no longer have much of a problem with moving patches to SF, > though I *still* think the mailing list would be sufficient with a bit > more focused effort; sorry, Tim! "Do something" to supply that focus on this mailing list, and then I can stop bothering with the move. That would be great. But repeating that if the list worked, it wouldn't be broken <0.7 wink>, has not proven sufficient to fix it. > But at least we're not going to burn weeks looking at different patch > manager products, and then arguing about them, which is what I feared > most. Same here. well-actually-the-radio-on-the-drive-down-to-va-got-me-more-worried- about-lyme-disease-ly y'rs - tim From tim_one at email.msn.com Sat Jun 24 19:51:14 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 24 Jun 2000 13:51:14 -0400 Subject: [Python-Dev] test failures... In-Reply-To: <20000624103934.Y29590@lyra.org> Message-ID: [Greg Stein] > Euh... shouldn't we insert some defensive code into longobject.c? Great, > Skip knows to disable opt for that file... what about all the > other people? Don't understand what you want to see. The compiler in question is both broken & old. At most I'd put a note in one of the readmes saying so. From fdrake at beopen.com Sat Jun 24 23:19:50 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sat, 24 Jun 2000 14:19:50 -0700 (PDT) Subject: [Python-Dev] updated exit.py and supporting files for your perusal In-Reply-To: References: <200006232008.PAA02759@cj20424-a.reston1.va.home.com> Message-ID: <14677.9718.880695.265962@mailhost.beopen.com> Ka-Ping Yee writes: > Sorry to confuddle things, but what happened to the idea of > sticking it in "sys"? If sys.exitfunc lives there, doesn't > sys.atexit(...) also make sense? It can't be very hard to do... I'd be happy with this as well, but I don't think it's required to do it that way. -Fred -- Fred L. Drake, Jr. From gstein at lyra.org Sun Jun 25 00:18:24 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 24 Jun 2000 15:18:24 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils util.py,1.36,1.37 In-Reply-To: <200006242040.NAA28315@slayer.i.sourceforge.net>; from gward@users.sourceforge.net on Sat, Jun 24, 2000 at 01:40:05PM -0700 References: <200006242040.NAA28315@slayer.i.sourceforge.net> Message-ID: <20000624151824.A29590@lyra.org> Would the "shlex" module be helpful here? It is in the standard library and is (well?) maintained by ESR. It could help reduce the code inside distutils. [ I've always questioned the need for distutils' own "copy file" functions and whatnot... seems there is a bit of duplication occurring... ] Cheers, -g On Sat, Jun 24, 2000 at 01:40:05PM -0700, Greg Ward wrote: > Update of /cvsroot/python/distutils/distutils > In directory slayer.i.sourceforge.net:/tmp/cvs-serv28287 > > Modified Files: > util.py > Log Message: > Added 'split_quoted()' function to deal with strings that are quoted in > Unix shell-like syntax (eg. in Python's Makefile, for one thing -- now that > I have this function, I'll probably allow quoted strings in config files too. > > Index: util.py > =================================================================== > RCS file: /cvsroot/python/distutils/distutils/util.py,v > retrieving revision 1.36 > retrieving revision 1.37 > diff -C2 -r1.36 -r1.37 > *** util.py 2000/06/18 15:45:55 1.36 > --- util.py 2000/06/24 20:40:02 1.37 > *************** > *** 167,168 **** > --- 167,235 ---- > > return error > + > + > + # Needed by 'split_quoted()' > + _wordchars_re = re.compile(r'[^\\\'\"\ ]*') > + _squote_re = re.compile(r"'(?:[^'\\]|\\.)*'") > + _dquote_re = re.compile(r'"(?:[^"\\]|\\.)*"') > + > + def split_quoted (s): > + """Split a string up according to Unix shell-like rules for quotes and > + backslashes. In short: words are delimited by spaces, as long as those > + spaces are not escaped by a backslash, or inside a quoted string. > + Single and double quotes are equivalent, and the quote characters can > + be backslash-escaped. The backslash is stripped from any two-character > + escape sequence, leaving only the escaped character. The quote > + characters are stripped from any quoted string. Returns a list of > + words. > + """ > + > + # This is a nice algorithm for splitting up a single string, since it > + # doesn't require character-by-character examination. It was a little > + # bit of a brain-bender to get it working right, though... > + > + s = string.strip(s) > + words = [] > + pos = 0 > + > + while s: > + m = _wordchars_re.match(s, pos) > + end = m.end() > + if end == len(s): > + words.append(s[:end]) > + break > + > + if s[end] == ' ': # unescaped, unquoted space: now > + words.append(s[:end]) # we definitely have a word delimiter > + s = string.lstrip(s[end:]) > + pos = 0 > + > + elif s[end] == '\\': # preserve whatever is being escaped; > + # will become part of the current word > + s = s[:end] + s[end+1:] > + pos = end+1 > + > + else: > + if s[end] == "'": # slurp singly-quoted string > + m = _squote_re.match(s, end) > + elif s[end] == '"': # slurp doubly-quoted string > + m = _dquote_re.match(s, end) > + else: > + raise RuntimeError, \ > + "this can't happen (bad char '%c')" % s[end] > + > + if m is None: > + raise ValueError, \ > + "bad string (mismatched %s quotes?)" % s[end] > + > + (beg, end) = m.span() > + s = s[:beg] + s[beg+1:end-1] + s[end:] > + pos = m.end() - 2 > + > + if pos >= len(s): > + words.append(s) > + break > + > + return words > + > + # split_quoted () > > > _______________________________________________ > Python-checkins mailing list > Python-checkins at python.org > http://www.python.org/mailman/listinfo/python-checkins -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Sun Jun 25 00:50:23 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 24 Jun 2000 15:50:23 -0700 Subject: [Python-Dev] test failures... In-Reply-To: ; from tim_one@email.msn.com on Sat, Jun 24, 2000 at 01:51:14PM -0400 References: <20000624103934.Y29590@lyra.org> Message-ID: <20000624155023.B29590@lyra.org> On Sat, Jun 24, 2000 at 01:51:14PM -0400, Tim Peters wrote: > [Greg Stein] > > Euh... shouldn't we insert some defensive code into longobject.c? Great, > > Skip knows to disable opt for that file... what about all the > > other people? > > Don't understand what you want to see. The compiler in question is both > broken & old. At most I'd put a note in one of the readmes saying so. The compiler Skip quoted was pgcc-2.91.66. The "pgcc" part may have introduced the problem, but my RedHat 6.2 (i.e. the LATEST) has the following: Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) Maybe 2.91.66 is "old" but that is the compiler being shipped on RedHat 6.2. Having said that, I bet the pgcc people messed up the compiler :-). I set -O9 on my box and recompiled longobject.c. It wouldn't reproduce the problem. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gmcm at hypernet.com Sun Jun 25 01:01:05 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Sat, 24 Jun 2000 19:01:05 -0400 Subject: [Python-Dev] test failures... In-Reply-To: References: <14676.11968.263924.752216@beluga.mojam.com> Message-ID: <1250234786-20097552@hypernet.com> Tim "The Windows Guy" Peters wrote: > [Skip Montanaro] > > /usr/lib/gcc-lib/i686-pc-linux-gnu/pgcc-2.91.66/specs > > gcc version pgcc-2.91.66 19990314 (egcs-1.1.2 release) > > Well, I haven't had need of following the gcc/egcs soap opera, > but I think "a year" (& particularly the last one ) is a > lifetime in that saga. gcc 2.90 (egcs 1.0.3) that came with RH 5.2 was broken - but got fixed by rebuilding it from source. - Gordon From gstein at lyra.org Sun Jun 25 10:40:23 2000 From: gstein at lyra.org (Greg Stein) Date: Sun, 25 Jun 2000 01:40:23 -0700 Subject: [Python-Dev] [rasmus@apache.org: Re: PMCs and Apache] Message-ID: <20000625014023.D29590@lyra.org> Woah... this is an interesting factoid about the number of committers for a project. I had no idea PHP had this many... Can this work with Python? Dunno. I think if a "true core" group pays attention to the -checkins alias, then yah. If that review is ever lost, then those "edge" committers could introduce crap. I'm not asking for more committers to Python. But if some people were worried about the "explosion" of committers from about six a couple months ago to the current 13, then just look to PHP and count your thanks :-) Mostly, this email is for pondering... Cheers, -g ----- Forwarded message from Rasmus Lerdorf ----- Reply-To: members at apache.org Date: Sat, 24 Jun 2000 20:52:01 -0700 (PDT) From: Rasmus Lerdorf To: members at apache.org Subject: Re: PMCs and Apache > More relevant is the process by which I became a contributor. For PHP, I > sent a note describing what I was exploring, and I was sent a note with a > password. I didn't know CVS. I didn't know PHP. I didn't know open > source. But like a stranger offering to help at a barn raising, I was > simply handed a hammer and expected to get busy. That has always been the atmosphere. It isn't quite as free as that. We get 10-20 cvs write account requests every week and tend to only hand out 1 or 2 actual accounts. There are a lot of clueless people out there. However, if the person has shown any sign of being competent by explaining in a rational manner what they plan on working on, I see no reason not to let them bash away. Reversing somebodys' changes and removing a cvs account is trivial, and in the past 5 years we have yet to revoke an account. We have reversed changes of course, but even that doesn't happen too often. There are currently 165 people with write access to the PHP source tree. This does also relate to the fact that the PHP project is a very broad project. No single person could possibly know all 16 supported low-level database apis, for example. For other projects with a much more limited scope, this approach is probably not optimal, but for PHP it works nicely. Someone will write a bit of broken code that shows some good ideas, and others will pounce on it and fix it. Often the people who fix it are poor sods who tried to use the broken feature and had to dive in and fix it themselves. They request a cvs account to do this, and they are hooked. They tend to never stop at fixing just one thing once they have been given the golden keys. This approach has also done wonders for the PHP documentation. The current manual is around 1100 pages long and has been fully translated to German, Italian and Japanese with more languages on the way. (check out http://snaps.php.net/manual/) -Rasmus ----- End forwarded message ----- -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Mon Jun 26 01:20:43 2000 From: gstein at lyra.org (Greg Stein) Date: Sun, 25 Jun 2000 16:20:43 -0700 Subject: [Python-Dev] Python/Apache stuff (was: Re: [XML-SIG] speed question re DOM parsing) In-Reply-To: <200006251540.JAA13556@localhost.localdomain>; from uogbuji@fourthought.com on Sun, Jun 25, 2000 at 09:40:59AM -0600 References: <200006251540.JAA13556@localhost.localdomain> Message-ID: <20000625162043.J29590@lyra.org> On Sun, Jun 25, 2000 at 09:40:59AM -0600, Uche Ogbuji wrote: > Greg Stein: > > When could I get to it? eek. I *will*, but dunno when. It is amazing just > > how much stuff can fall on a person's plate despite having no job :-). I've > > got some layered I/O in Apache, mod_dav integration, a new httplib, imputil > > issues, these qp_xml upgrades, ViewCVS stuff, edna releases, free threading > > changes, Python/Apache integration, and coding for Subversion. Fuggin > > frightening. > > Ooh! Ooh! Can you tell us more about the Python/Apache integration item? > We've been discussing distributing a 4Suite kit bundled with PyApache, but > that package is quite complex and I'm not sure how strongly maintained. Are > you talking about improvements to PyApache? Another approach entirely > (PyApache still has much more overhead than, say mod_perl)? Do you have an > approximate time-line? A project URL? There are several Python/Apache efforts (where Python is embedded into the Apache process): *) PyApache: essentially this is just a CGI accelerator. Take a standard CGI script and it will "run faster." (URL? dunno) *) mod_python: similar to mod_perl. Built for Apache 1.3. Despite its version 2.4, it is still a bit rough. I've been working with the author to improve the code. I did a code review a while back with a lot of suggestions. It is reasonable, but not as mature as mod_perl. http://www.modpython.org/ *) mod_snake: obvious misnomer :-). This is a module built for Apache 2.0, with the intent of making use of Apache 2.0's threadedness (plus a few of A2's other internal features). The code is very good looking. - available at SourceForge *) mod_slimpy: my name for an Apache 2.0 module which will be even lighter weight than mod_snake. There will be only the slimmest layer of C code to interface Apache and Python. Most/all operational logic will be deferred to the Python side. I've used this design to good effect in some of the Python/COM work and its univgw package in particular. Obviously, the latter two will compete, but oh well :-). The first two fit their problem environment without particular complications. When I start the mod_slimpy work, I'm also going to push on setting up python.apache.org. Essentially, it will host (under the ASF umbrella) the mod_slimpy work plus any other efforts that may want to operate there. I'm going to ask the authors of the other packages whether they would like to be hosted there, too. Of course, python.apache.org can host any Python project. It doesn't have to be related to the web server, or any other ASF project for that matter. Consider all the non-web stuff that operates under xml.apache.org, java.apache.org, and jakarta.apache.org. Cheers, -g -- Greg Stein, http://www.lyra.org/ From Vladimir.Marangozov at inrialpes.fr Mon Jun 26 13:33:56 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Mon, 26 Jun 2000 13:33:56 +0200 (CEST) Subject: [Python-Dev] Fw: Access violation when no memory In-Reply-To: from "Mark Hammond" at Jun 20, 2000 09:42:53 PM Message-ID: <200006261133.NAA03073@python.inrialpes.fr> Mark Hammond wrote: > > >From the newsgroup. Any thoughts? > > Mark. > > "Phil Mayes" wrote in message > news:... > > The following program progressively allocates all memory: > > size = 1 << 20 > > list = [None,] > > while size: > > try: > > mem = [None] * size > > mem[0] = list > > list = mem > > except: > > size = size / 2 > > > > It fails with an access violation. (Turn off virtual memory > > to provoke it.) I had a closer look at this report. It revealed a buglet in Instance_New and raises a question on how to handle the possible NULL values pushed on the stack in ceval.c, at the exception handling code block: > > 3. the NULL pointer at tb is pushed here: > > ceval.c line 1816: PUSH(tb); > > ceval.c line 1817: PUSH(val); > > ceval.c line 1818: PUSH(exc); 1. In PyInstance_New, when the inst->in_dict allocation fails, there's a DECREF(inst) which triggers the instance_dealloc function. The latter goes on checking whether __del__ is defined in the instance's dict (by calling getattr2) whithout checking first whether inst->in_dict is not NULL. I.e. the dealloc_function assumes the instance has been initialized successfully. The net effect is a segfault in PyDict_GetItem which is called with a NULL dict. There are two possible fixes, and I'm not sure which one is better: a) Fix the Instance_New code, by freeing the instance on inst->in_dict allocation failure (without decref'ing the instance). b) Fix the dealloc code, by checking whether in_dict is not NULL before proceeding with the __del__ finalization logic. Opinions? 2. In ceval.c, there are indeed cases where 'tb' and 'exc' are NULL on low-memory conditions. They are pushed on the stack, then popped with a segfault. The only reasonable behavior I get, after some testing, is by setting the tb and exc to Py_None if any of them is NULL before pushing them onto the stack. The program succeeds or the process is killed by the OS (tested on Linux). However, I'm not sure that setting tb and/or exc to Py_None, if NULL, makes any sense and won't cause side effects. Any other suggestions? -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From guido at python.org Mon Jun 26 16:49:11 2000 From: guido at python.org (Guido van Rossum) Date: Mon, 26 Jun 2000 09:49:11 -0500 Subject: [Python-Dev] Let's use the SourceForge Patch Manager In-Reply-To: Your message of "Fri, 23 Jun 2000 10:03:41 +0200." <395319DD.F2584321@lemburg.com> References: <395319DD.F2584321@lemburg.com> Message-ID: <200006261449.JAA01684@cj20424-a.reston1.va.home.com> It's official: I've changed the patch submission guidelines (http://www.python.org/patches/) to point to the patch manager at SourceForge. We are no longer bound by CNRI's legal department, so the requirement for disclaimers or wet signatures is gone. We'll have to see how it works in practice. I've set the address where new patches are mailed to patches at python.org; this should send notifications to the patches list. We could change this to python-dev perhaps, so we can retire the patches address completely (giving it an auto-respond pointing to the SF patch manager, as barry suggested). There are several tasks to be assigned now: we need a triage person who should go through the list of new patches regularly to assign them to developers; we need developers who are willing to have patches assigned to them. We also need a consensus process to decide which patches will be allowed through. I'm hoping to experiment with SF in the coming days to come up with something. Finally, we still need to do something about the existing backlog of patches. The PythonLabs team will try to do something reasonable here. This is not the end -- it's the beginning! --Guido van Rossum (home page: http://www.python.org/~guido/) From jack at oratrix.nl Mon Jun 26 16:29:05 2000 From: jack at oratrix.nl (Jack Jansen) Date: Mon, 26 Jun 2000 16:29:05 +0200 Subject: [Python-Dev] [rasmus@apache.org: Re: PMCs and Apache] In-Reply-To: Message by Greg Stein , Sun, 25 Jun 2000 01:40:23 -0700 , <20000625014023.D29590@lyra.org> Message-ID: <20000626142906.1DDBD37186E@snelboot.oratrix.nl> > Woah... this is an interesting factoid about the number of committers for a > project. I had no idea PHP had this many... > > Can this work with Python? Dunno. I think if a "true core" group pays > attention to the -checkins alias, then yah. If that review is ever lost, > then those "edge" committers could introduce crap. This is one of the reasons I never asked for committer status: the fewer people doing commits the better. I can live with the <2days delay we had upto recently, and for now I'm expecting it to go down to that again after all the turmoil is over. -- 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 guido at python.org Mon Jun 26 17:43:38 2000 From: guido at python.org (Guido van Rossum) Date: Mon, 26 Jun 2000 10:43:38 -0500 Subject: [Python-Dev] [rasmus@apache.org: Re: PMCs and Apache] In-Reply-To: Your message of "Mon, 26 Jun 2000 16:29:05 +0200." <20000626142906.1DDBD37186E@snelboot.oratrix.nl> References: <20000626142906.1DDBD37186E@snelboot.oratrix.nl> Message-ID: <200006261543.KAA02198@cj20424-a.reston1.va.home.com> [Jack Jansen] > This is one of the reasons I never asked for committer status: the > fewer people doing commits the better. I can live with the <2days > delay we had upto recently, and for now I'm expecting it to go down > to that again after all the turmoil is over. Actually, I'd be glad to give you committer status (your colleague Sjoerd just got his :-). I expect that the majority of the subscribers to python-dev can be trusted as committers. I fully expect that most committers won't be committing much -- I don't expect a frenzy of work by committers on the source tree. However the committer status offloads the responsibility of applying the patches you submit after they have been approved -- you can now do it yourself. Less work for me and the others here at PythonLabs! BTW, I would heartily recommend putting the Macintosh tree for Python under SourceForge! --Guido van Rossum (home page: http://www.python.org/~guido/) From mal at lemburg.com Mon Jun 26 17:03:30 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 26 Jun 2000 17:03:30 +0200 Subject: [Python-Dev] Let's use the SourceForge Patch Manager References: <395319DD.F2584321@lemburg.com> <200006261449.JAA01684@cj20424-a.reston1.va.home.com> Message-ID: <395770C2.B903724A@lemburg.com> Guido van Rossum wrote: > > It's official: I've changed the patch submission guidelines > (http://www.python.org/patches/) to point to the patch manager at > SourceForge. We are no longer bound by CNRI's legal department, so > the requirement for disclaimers or wet signatures is gone. > > We'll have to see how it works in practice. I've set the address > where new patches are mailed to patches at python.org; this should send > notifications to the patches list. We could change this to python-dev > perhaps, so we can retire the patches address completely (giving it an > auto-respond pointing to the SF patch manager, as barry suggested). Will there be a list which gets the patches mailed to it by SF ? I'm just asking because the current setup of having the patches available through mail really helps in discussing patch details. > There are several tasks to be assigned now: we need a triage person > who should go through the list of new patches regularly to assign them > to developers; we need developers who are willing to have patches > assigned to them. I'll volunteer for the Unicode side of things :-) > We also need a consensus process to decide which patches will be > allowed through. I'm hoping to experiment with SF in the coming days > to come up with something. > > Finally, we still need to do something about the existing backlog of > patches. The PythonLabs team will try to do something reasonable > here. > > This is not the end -- it's the beginning! -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From jack at oratrix.nl Mon Jun 26 17:13:54 2000 From: jack at oratrix.nl (Jack Jansen) Date: Mon, 26 Jun 2000 17:13:54 +0200 Subject: [Python-Dev] [rasmus@apache.org: Re: PMCs and Apache] In-Reply-To: Message by Guido van Rossum , Mon, 26 Jun 2000 10:43:38 -0500 , <200006261543.KAA02198@cj20424-a.reston1.va.home.com> Message-ID: <20000626151355.3EF8C37186E@snelboot.oratrix.nl> > Actually, I'd be glad to give you committer status (your colleague > Sjoerd just got his :-). I expect that the majority of the > subscribers to python-dev can be trusted as committers. Oww, grumble grumble... Okay, I'll apply for committer status. So there. > BTW, I would heartily recommend putting the Macintosh tree for Python > under SourceForge! I don't think MacCVS can do ssh authorization, and if I followed the discussion here that is needed, right? But if that hurdle can be taken: fine! -- 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 guido at python.org Mon Jun 26 18:32:37 2000 From: guido at python.org (Guido van Rossum) Date: Mon, 26 Jun 2000 11:32:37 -0500 Subject: [Python-Dev] Let's use the SourceForge Patch Manager In-Reply-To: Your message of "Mon, 26 Jun 2000 17:03:30 +0200." <395770C2.B903724A@lemburg.com> References: <395319DD.F2584321@lemburg.com> <200006261449.JAA01684@cj20424-a.reston1.va.home.com> <395770C2.B903724A@lemburg.com> Message-ID: <200006261632.LAA02506@cj20424-a.reston1.va.home.com> [MAL] > Will there be a list which gets the patches mailed to it > by SF ? > > I'm just asking because the current setup of having the patches > available through mail really helps in discussing patch details. I don't think this feature is part of the SF Patch Manager just yet. You could submit it as a request to the SF PM developers though -- apparently they're still working on it. --Guido van Rossum (home page: http://www.python.org/~guido/) From paul at prescod.net Mon Jun 26 17:43:31 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 26 Jun 2000 08:43:31 -0700 Subject: [Python-Dev] winreg Message-ID: <39577A23.EF7DE922@prescod.net> [I'm having mail troubles so my response time may be slow...] I've just had a chance to look at the winreg module. I think that it is too low-level. I wrote a wrapper class that I feel is more Pythonic. I'll outline the basic ideas and then if there is interest I'll develop a test suite and send it out for eyeballing by Mark and others. Yes, I am proposing this for 1.6. If we're going to put in a registry module, it should be as Pythonic as possible. First, about Winreg 1: It was perfect when it was part of the win32 package and was supposed to mirror the win32 APIs exactly (for reasons of documentation and familiarity) but as the "standard" Python registry manipulation module it seems too low-level to me. I'm sure Mark would be the first to admit that it isn't very Pythonic. It's more Microsoft-ic. In one part of the docs he says: "this API is lame, lame, lame. Don't use it." :) There are also bogus parameters that Microsoft hasn't got around to assigning values to, undocumented constants and so forth. My favorite is "WHOLE_HIVE_VOLATILE". Winreg 2: The basic idea in the pythonic wrapper is that there are key "objects" rather than just handles. winreg already has a primtive "handle object" but for some reason most of the stuff that would logically be methods are actually functions that take the handle as the first param. Keys can have subkeys. So in winreg 1 you would say: winreg.CreateKey( winreg.CreateKey( winreg.HKEY_LOCAL_MACHINE, "HARDWARE"), "DESCRIPTION" ) now you say: winreg.HKEY_LOCAL_MACHINE.createKey( "HARDWARE").createKey( "DESCRIPTION" ) (you could also use a path syntax in either case) You can get a complete list of existant subkeys with a getSubkeys() method call. This list behaves like a Python mapping and also like a sequence. You can use either string key names or integer ordinal indexes. You can fetch and delete keys based on those indexes: for key in winreg.HKEY_LOCAL_MACHINE.getSubkeys(): dosomething( key ) Before it was something like this: for index in xrange( 0, sys.maxint ): try: dosomething( winreg.EnumKey( index ) ) except WindowsError: break "Values" (in the Microsoft sense) are handled the same basic way. Looping, deleting, etc. is the same. When you fetch a value, you get a (type,value) tuple. Types are objects with properties: typeobj.intval -> 0..10 typeobj.msname -> REG_SZ, REG_SZ_MULTI, ... typeobj.friendlyname -> "String", "Sting List", ... Type coercions are all done by the underlying module (the old winreg) except that I've decided that binary data should be returned as an array.array('c') rather than an 8-bit string. -- Paul Prescod Out of timber so crooked as that which man is made nothing entirely straight can be built. - Immanuel Kant From fdrake at beopen.com Mon Jun 26 18:04:40 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 26 Jun 2000 09:04:40 -0700 (PDT) Subject: [Python-Dev] Let's use the SourceForge Patch Manager In-Reply-To: <395770C2.B903724A@lemburg.com> References: <395319DD.F2584321@lemburg.com> <200006261449.JAA01684@cj20424-a.reston1.va.home.com> <395770C2.B903724A@lemburg.com> Message-ID: <14679.32536.133849.573542@mailhost.beopen.com> M.-A. Lemburg writes: > Will there be a list which gets the patches mailed to it > by SF ? patches at python.org should get messages of patch manager activity (at least certain actions; not sure which ones yet, but at least additions). > I'm just asking because the current setup of having the patches > available through mail really helps in discussing patch details. Yes! I'd really hate to lose notifications! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Mon Jun 26 18:04:40 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 26 Jun 2000 09:04:40 -0700 (PDT) Subject: [Python-Dev] Let's use the SourceForge Patch Manager In-Reply-To: <395770C2.B903724A@lemburg.com> References: <395319DD.F2584321@lemburg.com> <200006261449.JAA01684@cj20424-a.reston1.va.home.com> <395770C2.B903724A@lemburg.com> Message-ID: <14679.32536.133849.573542@mailhost.beopen.com> M.-A. Lemburg writes: > Will there be a list which gets the patches mailed to it > by SF ? patches at python.org should get messages of patch manager activity (at least certain actions; not sure which ones yet, but at least additions). > I'm just asking because the current setup of having the patches > available through mail really helps in discussing patch details. Yes! I'd really hate to lose notifications! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From paul at prescod.net Mon Jun 26 17:43:31 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 26 Jun 2000 08:43:31 -0700 Subject: [Python-Dev] winreg Message-ID: <39577A23.EF7DE922@prescod.net> [I'm having mail troubles so my response time may be slow...] I've just had a chance to look at the winreg module. I think that it is too low-level. I wrote a wrapper class that I feel is more Pythonic. I'll outline the basic ideas and then if there is interest I'll develop a test suite and send it out for eyeballing by Mark and others. Yes, I am proposing this for 1.6. If we're going to put in a registry module, it should be as Pythonic as possible. First, about Winreg 1: It was perfect when it was part of the win32 package and was supposed to mirror the win32 APIs exactly (for reasons of documentation and familiarity) but as the "standard" Python registry manipulation module it seems too low-level to me. I'm sure Mark would be the first to admit that it isn't very Pythonic. It's more Microsoft-ic. In one part of the docs he says: "this API is lame, lame, lame. Don't use it." :) There are also bogus parameters that Microsoft hasn't got around to assigning values to, undocumented constants and so forth. My favorite is "WHOLE_HIVE_VOLATILE". Winreg 2: The basic idea in the pythonic wrapper is that there are key "objects" rather than just handles. winreg already has a primtive "handle object" but for some reason most of the stuff that would logically be methods are actually functions that take the handle as the first param. Keys can have subkeys. So in winreg 1 you would say: winreg.CreateKey( winreg.CreateKey( winreg.HKEY_LOCAL_MACHINE, "HARDWARE"), "DESCRIPTION" ) now you say: winreg.HKEY_LOCAL_MACHINE.createKey( "HARDWARE").createKey( "DESCRIPTION" ) (you could also use a path syntax in either case) You can get a complete list of existant subkeys with a getSubkeys() method call. This list behaves like a Python mapping and also like a sequence. You can use either string key names or integer ordinal indexes. You can fetch and delete keys based on those indexes: for key in winreg.HKEY_LOCAL_MACHINE.getSubkeys(): dosomething( key ) Before it was something like this: for index in xrange( 0, sys.maxint ): try: dosomething( winreg.EnumKey( index ) ) except WindowsError: break "Values" (in the Microsoft sense) are handled the same basic way. Looping, deleting, etc. is the same. When you fetch a value, you get a (type,value) tuple. Types are objects with properties: typeobj.intval -> 0..10 typeobj.msname -> REG_SZ, REG_SZ_MULTI, ... typeobj.friendlyname -> "String", "Sting List", ... Type coercions are all done by the underlying module (the old winreg) except that I've decided that binary data should be returned as an array.array('c') rather than an 8-bit string. -- Paul Prescod Out of timber so crooked as that which man is made nothing entirely straight can be built. - Immanuel Kant From fdrake at beopen.com Mon Jun 26 17:46:23 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 26 Jun 2000 08:46:23 -0700 (PDT) Subject: [Python-Dev] Fw: Access violation when no memory In-Reply-To: <200006261133.NAA03073@python.inrialpes.fr> References: <200006261133.NAA03073@python.inrialpes.fr> Message-ID: <14679.31439.11309.105239@mailhost.beopen.com> Vladimir Marangozov writes: > There are two possible fixes, and I'm not sure which one is better: > > a) Fix the Instance_New code, by freeing the instance on inst->in_dict > allocation failure (without decref'ing the instance). I think this is the right one; this *shold* be all that's ever needed, and isolates the check to the cod ethat can experiance failure. > b) Fix the dealloc code, by checking whether in_dict is not NULL > before proceeding with the __del__ finalization logic. This protects against bad C code elsewhere that makes a mess of existing objects by stepping around the API (such as by setting inst->in_dict to NULL). I'm not sure we want to protect against that since it could mask bugs (I doubt anyone would do that deliberatly, so I feel safe calling it a bug!). > Opinions? And for free! So infer what you will about their worth. :) > 2. In ceval.c, there are indeed cases where 'tb' and 'exc' are NULL on > low-memory conditions. They are pushed on the stack, then popped with > a segfault. The only reasonable behavior I get, after some testing, > is by setting the tb and exc to Py_None if any of them is NULL before > pushing them onto the stack. The program succeeds or the process is > killed by the OS (tested on Linux). > > However, I'm not sure that setting tb and/or exc to Py_None, if NULL, > makes any sense and won't cause side effects. This doesn't seem like a situation where you'd be masking some other kind of bug by using Py_None, and it avoids the core dump. Since you're not masking anything, I'd go ahead and use Py_None here. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From esr at thyrsus.com Mon Jun 26 20:01:25 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 26 Jun 2000 14:01:25 -0400 Subject: [Python-Dev] Now that the man is back... Message-ID: <20000626140125.A3266@thyrsus.com> Guido, can we get these into 1.6? They're needed for the the ncurses extensions I'm working on. -- Eric S. Raymond "This country, with its institutions, belongs to the people who inhabit it. Whenever they shall grow weary of the existing government, they can exercise their constitutional right of amending it or their revolutionary right to dismember it or overthrow it." -- Abraham Lincoln, 4 April 1861 -------------- next part -------------- A non-text attachment was scrubbed... Name: libascii.tex Type: application/x-tex Size: 4408 bytes Desc: not available URL: -------------- next part -------------- # # ascii.py -- constants and memembership tests for ASCII characters # NUL = 0x00 # ^@ SOH = 0x01 # ^A STX = 0x02 # ^B ETX = 0x03 # ^C EOT = 0x04 # ^D ENQ = 0x05 # ^E ACK = 0x06 # ^F BEL = 0x07 # ^G BS = 0x08 # ^H TAB = 0x09 # ^I HT = 0x09 # ^I LF = 0x0a # ^J NL = 0x0a # ^J VT = 0x0b # ^K FF = 0x0c # ^L CR = 0x0d # ^M SO = 0x0e # ^N SI = 0x0f # ^O DLE = 0x10 # ^P DC1 = 0x11 # ^Q DC2 = 0x12 # ^R DC3 = 0x13 # ^S DC4 = 0x14 # ^T NAK = 0x15 # ^U SYN = 0x16 # ^V ETB = 0x17 # ^W CAN = 0x18 # ^X EM = 0x19 # ^Y SUB = 0x1a # ^Z ESC = 0x1b # ^[ FS = 0x1c # ^\ GS = 0x1d # ^] RS = 0x1e # ^^ US = 0x1f # ^_ SP = 0x20 # space DEL = 0x7f # delete controlnames = [ "NUL", "SOH", "STX", "ETX", "EOT", "ENQ", "ACK", "BEL", "BS", "HT", "LF", "VT", "FF", "CR", "SO", "SI", "DLE", "DC1", "DC2", "DC3", "DC4", "NAK", "SYN", "ETB", "CAN", "EM", "SUB", "ESC", "FS", "GS", "RS", "US", "SP" ] def _ctoi(c): if type(c) == type(""): return ord(c) else: return c def isalnum(c): return isalpha(c) or isdigit(c) def isalpha(c): return isupper(c) or islower(c) def isascii(c): return _ctoi(c) <= 127 # ? def isblank(c): return _ctoi(c) in (8,32) def iscntrl(c): return _ctoi(c) <= 31 def isdigit(c): return _ctoi(c) >= 48 and _ctoi(c) <= 57 def isgraph(c): return _ctoi(c) >= 33 and _ctoi(c) <= 126 def islower(c): return _ctoi(c) >= 97 and _ctoi(c) <= 122 def isprint(c): return _ctoi(c) >= 32 and _ctoi(c) <= 126 def ispunct(c): return _ctoi(c) != 32 and not isalnum(c) def isspace(c): return _ctoi(c) in (12, 10, 13, 9, 11) def isupper(c): return _ctoi(c) >= 65 and _ctoi(c) <= 90 def isxdigit(c): return isdigit(c) or \ (_ctoi(c) >= 65 and _ctoi(c) <= 70) or (_ctoi(c) >= 97 and _ctoi(c) <= 102) def isctrl(c): return _ctoi(c) < 32 def ismeta(c): return _ctoi(c) > 127 def ascii(c): if type(c) == type(""): return chr(_ctoi(c) & 0x7f) else: return _ctoi(c) & 0x7f def ctrl(c): if type(c) == type(""): return chr(_ctoi(c) & 0x1f) else: return _ctoi(c) & 0x1f def alt(c): if type(c) == type(""): return chr(_ctoi(c) | 0x80) else: return _ctoi(c) | 0x80 def unctrl(c): bits = _ctoi(c) if bits == 0x7f: rep = "^?" elif bits & 0x20: rep = chr((bits & 0x7f) | 0x20) else: rep = "^" + chr(((bits & 0x7f) | 0x20) + 0x20) if bits & 0x80: return "!" + rep return rep From tim_one at email.msn.com Mon Jun 26 20:41:12 2000 From: tim_one at email.msn.com (Tim Peters) Date: Mon, 26 Jun 2000 14:41:12 -0400 Subject: [Python-Dev] RE: [Patches] Let's use the SourceForge Patch Manager In-Reply-To: <200006261449.JAA01684@cj20424-a.reston1.va.home.com> Message-ID: [Guido] > It's official: I've changed the patch submission guidelines > (http://www.python.org/patches/) to point to the patch manager at > SourceForge. We are no longer bound by CNRI's legal department, so > the requirement for disclaimers or wet signatures is gone. Yay! Wonder how long that will last . Attached is a first cut at documenting the intended use of SourceForge's patch status tags, and the workflow associated with patch status changes. The areas in need of fleshing out are marked with "[xxx ...]". Gripe at will. I don't think anyone expects this to work smoothly at first. Strive for patience, and let's work to make SF a really *good* place for patches! never-thought-i'd-actually-miss-lotus-notes-ly y'rs - tim PS: I'll move this (& related info) to a reasonable place eventually, so don't bother griping about email for now. Intended use of SourceForge patch status tags --------------------------------------------- revision 1 26-Jun-2000 Open The initial status of all patches. The patch is under consideration, but has not been reviewed yet. The status will normally change to Accepted or Rejected next. The person submitting the patch should (if they can) assign it to the person they most want to review it. Else the patch will be assigned via [xxx a list of expertise areas should be developed] Discussion of patches is carried out via [xxx Python-Dev? patches list? without a mail gateway, the SourceForge patch interface looks too clumsy to use for controversial patches] Accepted The powers that be have accepted the patch, but it has not been applied yet. [xxx flesh out -- Guido Bottleneck avoidable here?] The status will normally change to Closed next. The person changing the status to Accepted should, at the same time, assign the patch to whoever they believe is most likely to be able & willing to apply it (the submitter if possible). Closed The patch has been accepted and applied. The previous status was Accepted, or possibly Open if the submitter was Guido (or moral equivalent in some particular area of expertise). If possible, the submitter should apply the patch and change the status to Closed. Else anyone with sufficient power should feel encouraged to do these on the submitter's behalf. Rejected The patch has been reviewed and rejected. When the objections are addressed, the status may change to Open again. Note that SourceForge allows the submitter to overwrite the patch with a new version. Out of date Previous status was Open or Accepted or Postponed, but the patch no longer works. Please enter a comment when changing the status to "Out of date", to record the nature of the problem and the previous status. Postponed The previous status was Open or Accepted, but for some reason (e.g., pending release) the patch should not be reviewed or applied until further notice. The status will normally change to Open or Accepted next. Please enter a comment when changing the status to Postponed, to record the reason, the previous status, and the conditions under which the patch should revert to Open or Accepted. Deleted Bit bucket. Use only if it's OK for the patch and its SourceForge history to disappear. As of 26-June-2000, SF does not actually throw away Deleted patches, but that may change. From DavidA at ActiveState.com Mon Jun 26 21:10:04 2000 From: DavidA at ActiveState.com (David Ascher) Date: Mon, 26 Jun 2000 12:10:04 -0700 Subject: [Python-Dev] semaphore support in thread_*.h Message-ID: I noticed that the support for the semaphore calls in the various thread_* is very very spotty, with a comment in the BeOS implementation that read: * Guido says not to implement this because it's not used anywhere; * I'll do it anyway, you never know when it might be handy, and it's * easy... (that last bit is not true of all implementations, apparently =). 1) Is it true that the sema_ calls are never used? 2) If yes, shouldn't we remove the sema_ calls from the thread API and have similar functionality on all platforms? (There are related issues re: for example whether async thread locking is available, whether threads are joinable or not (see thread_cthread.h), etc.) --david From tim_one at email.msn.com Mon Jun 26 21:19:58 2000 From: tim_one at email.msn.com (Tim Peters) Date: Mon, 26 Jun 2000 15:19:58 -0400 Subject: [Python-Dev] Let's use the SourceForge Patch Manager In-Reply-To: <395770C2.B903724A@lemburg.com> Message-ID: [MAL] > Will there be a list which gets the patches mailed to it > by SF ? > > I'm just asking because the current setup of having the patches > available through mail really helps in discussing patch details. I agree -- SF isn't (yet) good for patch discussions. Plugging away, but haven't yet figured out exactly when or how SF decides to send email. In particular, don't yet know how (or whether it's possible) to trick current SF into populating a mailing list. From guido at python.org Mon Jun 26 22:24:57 2000 From: guido at python.org (Guido van Rossum) Date: Mon, 26 Jun 2000 15:24:57 -0500 Subject: [Python-Dev] Now that the man is back... In-Reply-To: Your message of "Mon, 26 Jun 2000 14:01:25 -0400." <20000626140125.A3266@thyrsus.com> References: <20000626140125.A3266@thyrsus.com> Message-ID: <200006262024.PAA01212@cj20424-a.reston1.va.home.com> [ESR] > Guido, can we get these into 1.6? They're needed for the the ncurses > extensions I'm working on. Eric, We (PythonLabs + Andrew Kuchling & Greg Ward) discussed this at our recent 1.6 planning meeting. This doesn't have much use outside curses. Therefore, Andrew will check it in as a submodule of the new curses package. --Guido van Rossum (home page: http://www.python.org/~guido/) From fdrake at beopen.com Mon Jun 26 21:24:40 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 26 Jun 2000 12:24:40 -0700 (PDT) Subject: [Python-Dev] Now that the man is back... In-Reply-To: <20000626140125.A3266@thyrsus.com> References: <20000626140125.A3266@thyrsus.com> Message-ID: <14679.44536.931222.448738@mailhost.beopen.com> Eric S. Raymond writes: > Guido, can we get these into 1.6? They're needed for the the ncurses > extensions I'm working on. This will be the curses.ascii module per a discussion last week which included both Guido and Andrew. Andrew, my Unix machine is down for repairs; can you check these in for me, changing the module name to curses.ascii in the documentation file? I don't want to hold up since Eric is still developing some of the ncurses support. Thanks! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From jeremy at beopen.com Mon Jun 26 21:35:17 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 26 Jun 2000 15:35:17 -0400 (EDT) Subject: [Python-Dev] Now that the man is back... In-Reply-To: <20000626140125.A3266@thyrsus.com> References: <20000626140125.A3266@thyrsus.com> Message-ID: <14679.45173.439937.800007@bitdiddle.concentric.com> The ascii module is going into the curses package. Andrew Kuchling is responsible for it. Jeremy From esr at thyrsus.com Mon Jun 26 21:46:50 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 26 Jun 2000 15:46:50 -0400 Subject: [Python-Dev] Now that the man is back... In-Reply-To: <14679.44536.931222.448738@mailhost.beopen.com>; from fdrake@beopen.com on Mon, Jun 26, 2000 at 12:24:40PM -0700 References: <20000626140125.A3266@thyrsus.com> <14679.44536.931222.448738@mailhost.beopen.com> Message-ID: <20000626154650.C3685@thyrsus.com> Fred L. Drake, Jr. : > This will be the curses.ascii module per a discussion last week > which included both Guido and Andrew. OK, I guess. It will be useful for more than curses, though, so I don't understand the naming choice. -- Eric S. Raymond Hoplophobia (n.): The irrational fear of weapons, correctly described by Freud as "a sign of emotional and sexual immaturity". Hoplophobia, like homophobia, is a displacement symptom; hoplophobes fear their own "forbidden" feelings and urges to commit violence. This would be harmless, except that they project these feelings onto others. The sequelae of this neurosis include irrational and dangerous behaviors such as passing "gun-control" laws and trashing the Constitution. From paul at prescod.net Mon Jun 26 21:53:18 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 26 Jun 2000 12:53:18 -0700 Subject: [Python-Dev] winreg Message-ID: <3957B4AE.5562716C@prescod.net> I haven't seen this message come through: http://www.python.org/pipermail/python-dev/2000-June/006346.html I'm not sure if I missed it due to an email problem. Paul Prescod - Not encumbered by corporate consensus When George Bush entered office, a Washington Post-ABC News poll found that 62 percent of Americans "would be willing to give up a few of the freedoms we have" for the war effort. They have gotten their wish. - "This is your bill of rights...on drugs", Harpers, Dec. 1999 From fdrake at beopen.com Mon Jun 26 21:59:10 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 26 Jun 2000 12:59:10 -0700 (PDT) Subject: [Python-Dev] Now that the man is back... In-Reply-To: <20000626154650.C3685@thyrsus.com> References: <20000626140125.A3266@thyrsus.com> <14679.44536.931222.448738@mailhost.beopen.com> <20000626154650.C3685@thyrsus.com> Message-ID: <14679.46606.287276.330659@mailhost.beopen.com> Eric S. Raymond writes: > OK, I guess. It will be useful for more than curses, though, so I don't > understand the naming choice. Eric, In theory, yes, but... there have not been a lot of requests for the is*() functions (which are the ones I think you're referring to as generally useful). I think some of these are already take care of by things like "if c in string.hexdigits:", and others can be handled by making queries on the Unicode character properties. Given the dearth of requests for this, I don't see a clear need to place this elsewhere. If feedback to the beta suggests a better location, we'll certainly consider it! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido at python.org Mon Jun 26 23:28:16 2000 From: guido at python.org (Guido van Rossum) Date: Mon, 26 Jun 2000 16:28:16 -0500 Subject: [Python-Dev] semaphore support in thread_*.h In-Reply-To: Your message of "Mon, 26 Jun 2000 12:10:04 MST." References: Message-ID: <200006262128.QAA01518@cj20424-a.reston1.va.home.com> > I noticed that the support for the semaphore calls in the various thread_* > is very very spotty, with a comment in the BeOS implementation that read: > > * Guido says not to implement this because it's not used anywhere; > * I'll do it anyway, you never know when it might be handy, and it's > * easy... > > (that last bit is not true of all implementations, apparently =). > > 1) Is it true that the sema_ calls are never used? > > 2) If yes, shouldn't we remove the sema_ calls from the thread API and have > similar functionality on all platforms? > > (There are related issues re: for example whether async thread locking is > available, whether threads are joinable or not (see thread_cthread.h), etc.) The sema_ calls aren't used anywhere in the current source. I'd be for removing them. I'm not even sure why they are there -- maybe Sjoerd remembers? (This code was once part of something else than Python.) --Guido van Rossum (home page: http://www.python.org/~guido/) From akuchlin at mems-exchange.org Mon Jun 26 23:28:26 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Mon, 26 Jun 2000 17:28:26 -0400 Subject: [Python-Dev] Now that the man is back... In-Reply-To: <14679.44536.931222.448738@mailhost.beopen.com> References: <20000626140125.A3266@thyrsus.com> <14679.44536.931222.448738@mailhost.beopen.com> Message-ID: <20000626172826.E2282@kronos.cnri.reston.va.us> On Mon, Jun 26, 2000 at 12:24:40PM -0700, Fred L. Drake, Jr. wrote: > Andrew, my Unix machine is down for repairs; can you check these in >for me, changing the module name to curses.ascii in the documentation >file? I don't want to hold up since Eric is still developing some of >the ncurses support. I'll do that tonight; I had no time for Python hacking over the weekend... --amk From mhammond at skippinet.com.au Tue Jun 27 02:03:16 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Tue, 27 Jun 2000 10:03:16 +1000 Subject: [Python-Dev] winreg In-Reply-To: <39577A23.EF7DE922@prescod.net> Message-ID: > I've just had a chance to look at the winreg module. I think that it is > too low-level. I agree. There was a proposal (from Thomas Heller, IIRC) to do just this. I successfully argued there should be _2_ modules for Python - the raw low-level API, which guarantees you can do (almost) anything. A higher-level API could cover the 80% of cases. It is probably worth getting in touch with Thomas - he may be able to dig up his proposed high-level API. Ive CCd him on this message [I hope is _was_ you Thomas - otherwise you will be wondering WTF I am on about :] I was very keen to ensure the win32api code was used as the low-level API, simply because it has been well tested and used. We _know_ it has no significant limitations. Im happy to support a high-level API, but didnt have the inclination to provide one. Every one I have seen and every one I have tried to design has started to fall-apart under real-world use - Ive needed to revert back to the low-level. > There are also bogus parameters that Microsoft hasn't got around to > assigning values to, undocumented constants and so forth. My favorite is > "WHOLE_HIVE_VOLATILE". This is exactly my concern with a high-level API - you cant hope to capture all this - especially the undocumented ones - so having a low-level API means you can do anything, even stuff never dreamt of by the high-level designer. I have no real problem with your proposed design, as long as it it written in Python, _using_ the low-level API. It could be called "registry" or I would even be happy for "winreg.pyd" -> "_winreg.pyd" and your new module to be called "winreg.py" Mark. From tim_one at email.msn.com Tue Jun 27 00:13:42 2000 From: tim_one at email.msn.com (Tim Peters) Date: Mon, 26 Jun 2000 18:13:42 -0400 Subject: [Python-Dev] semaphore support in thread_*.h In-Reply-To: Message-ID: [David Ascher] > I noticed that the support for the semaphore calls in the various thread_* > is very very spotty, with a comment in the BeOS implementation that read: > > * Guido says not to implement this because it's not used anywhere; > * I'll do it anyway, you never know when it might be handy, and it's > * easy... > (that last bit is not true of all implementations, apparently =). > > 1) Is it true that the sema_ calls are never used? Best I can tell, the following sema functions are indeed never used: PyThread_allocate_sema PyThread_free_sema PyThread_down_sema PyThread_up_sema the following #define's are never used: WAIT_SEMA NOWAIT_SEMA and the following non-sema pythread.h functions are not only never used, they're defined only in thread_sgi.h: PyThread_create_key PyThread_delete_key PyThread_set_key_value PyThread_get_key_value > 2) If yes, shouldn't we remove the sema_ calls from the thread > API and have similar functionality on all platforms? +1 from me. If someone wants platform-specific thread functions, they should be in a platform-specific extension module, not messing up the core. > (There are related issues re: for example whether async thread locking is > available, whether threads are joinable or not (see > thread_cthread.h), etc.) Sorry, don't know what you're getting at here (e.g., have any specific line or function of thread_cthread.h in mind?). From fdrake at beopen.com Tue Jun 27 00:25:42 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 26 Jun 2000 15:25:42 -0700 (PDT) Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager In-Reply-To: References: <14679.32536.133849.573542@mailhost.beopen.com> Message-ID: <14679.55398.996503.269852@mailhost.beopen.com> Tim Peters writes: > Fred, would you please explain how that works or where that was set up? > I've puttered away many hours now playing with the SourceForge facilities From the "project page", go to "Project Admin" on the left navigation bar, then "Edit Public Info" at the top of the page. There are places to edit some email addresses near the bottom of the page. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one at email.msn.com Mon Jun 26 23:38:51 2000 From: tim_one at email.msn.com (Tim Peters) Date: Mon, 26 Jun 2000 17:38:51 -0400 Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager In-Reply-To: <14679.32536.133849.573542@mailhost.beopen.com> Message-ID: [Fred] > patches at python.org should get messages of patch manager activity (at > least certain actions; not sure which ones yet, but at least > additions). Fred, would you please explain how that works or where that was set up? I've puttered away many hours now playing with the SourceForge facilities (alas, most of that time waiting for web pages to load), but haven't stumbled into anything that hints the patch manager knows anything about patches at python.org. so-stupid-in-so-many-ways-ly y'rs - tim From tim_one at email.msn.com Tue Jun 27 01:14:06 2000 From: tim_one at email.msn.com (Tim Peters) Date: Mon, 26 Jun 2000 19:14:06 -0400 Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager In-Reply-To: <14679.55398.996503.269852@mailhost.beopen.com> Message-ID: [Fred L. Drake, Jr.] > From the "project page", go to "Project Admin" on the left > navigation bar, then "Edit Public Info" at the top of the page. There > are places to edit some email addresses near the bottom of the page. Aha! The one & only link I had never clicked -- I bet I could have figured that out myself in another week or two . Thank you. Now why do we have "Use Bug Tracker" checked? If nobody objects, I'll turn that off -- we're still doing bugs w/ Jitterbug on python.org. ten-stop-shopping-ly y'rs - tim From guido at beopen.com Tue Jun 27 04:35:52 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 26 Jun 2000 21:35:52 -0500 Subject: [Python-Dev] ANN: Release schedule Message-ID: <200006270235.VAA02631@cj20424-a.reston1.va.home.com> Here at BeOpen we're scrambling to get the release schedule for the rest of Python 1.6 planned. We're now looking at releasing Python 1.6b1 (or maybe it's going to be called 1.6a3 after all) on June 30! This means that if SRE isn't ready, we'll go with an incomplete SRE. Still better than no SRE! Please, PLEASE, if you have pending patches that you think should go into 1.6b1, submit them to SourceForge. We'll do our best to have a look at every patch submitted; but don't wait until the last moment. (Trent Mick, it would be helpful if you assigned each of your patches a potential reviewer from the list of existing developers -- that way we can split up the review load.) --Guido van Rossum (home page: http://www.python.org/~guido/) From trentm at activestate.com Tue Jun 27 05:52:59 2000 From: trentm at activestate.com (Trent Mick) Date: Mon, 26 Jun 2000 20:52:59 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test test_pyexpat.py,1.2,1.3 In-Reply-To: <200006270037.RAA25539@slayer.i.sourceforge.net> References: <200006270037.RAA25539@slayer.i.sourceforge.net> Message-ID: <20000626205259.A3866@activestate.com> On Mon, Jun 26, 2000 at 05:37:27PM -0700, A . M . Kuchling wrote: > Update of /cvsroot/python/python/dist/src/Lib/test > In directory slayer.i.sourceforge.net:/tmp/cvs-serv25501 > > Modified Files: > test_pyexpat.py > Log Message: > Change pyexpat test suite to exercise the .returns_unicode attribute, > parsing the sample data once with 8-bit strings and once with Unicode. > Does this require a new Lib/test/output/test_pyexpat? Trent -- Trent Mick trentm at activestate.com From DavidA at ActiveState.com Tue Jun 27 07:34:13 2000 From: DavidA at ActiveState.com (David Ascher) Date: Mon, 26 Jun 2000 22:34:13 -0700 Subject: [Python-Dev] semaphore support in thread_*.h In-Reply-To: Message-ID: > > (There are related issues re: for example whether async thread > locking is > > available, whether threads are joinable or not (see > > thread_cthread.h), etc.) > > Sorry, don't know what you're getting at here (e.g., have any > specific line > or function of thread_cthread.h in mind?). /* looks like solaris detaches the thread to never rejoin * so well do it here */ in thread_cthread.h The async thread locking comment was one of my personal issues -- I considered briefly providing a thread layer on top of the NSPR (Netscape Portable runtime) which is part of Mozilla. It has locks, but no async locking calls. --david From rob at hooft.net Tue Jun 27 11:32:02 2000 From: rob at hooft.net (Rob W. W. Hooft) Date: Tue, 27 Jun 2000 11:32:02 +0200 (CEST) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses ascii.py,NONE,1.1 textpad.py,NONE,1.1 In-Reply-To: <200006262355.QAA17089@slayer.i.sourceforge.net> References: <200006262355.QAA17089@slayer.i.sourceforge.net> Message-ID: <14680.29842.372192.274003@temoleh.chem.uu.nl> AMK> Update of /cvsroot/python/python/dist/src/Lib/curses AMK> In directory slayer.i.sourceforge.net:/tmp/cvs-serv17079 AMK> Added Files: AMK> ascii.py textpad.py AMK> Log Message: AMK> Added two modules for ASCII characters and a simple editing form (ESR) AMK> --- NEW FILE --- AMK> # AMK> # ascii.py -- constants and memembership tests for ASCII characters AMK> # ^^^^^ two letters too much? Rob From gvwilson at nevex.com Tue Jun 27 12:30:55 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Tue, 27 Jun 2000 06:30:55 -0400 (EDT) Subject: [Python-Dev] C# (new language from Microsoft) Message-ID: I'm sure many of you will have seen this announcement already, but for those who haven't, Microsoft is launching a new language to compete with C, C++, and Java: http://msdn.microsoft.com/vstudio/nextgen/technology/csharpintro.asp Greg From effbot at telia.com Tue Jun 27 12:35:22 2000 From: effbot at telia.com (Fredrik Lundh) Date: Tue, 27 Jun 2000 12:35:22 +0200 Subject: [Python-Dev] ANN: Release schedule References: <200006270235.VAA02631@cj20424-a.reston1.va.home.com> Message-ID: <017501bfe023$684fca40$f2a6b5d4@hagrid> guido wrote: > Here at BeOpen we're scrambling to get the release schedule for the > rest of Python 1.6 planned. We're now looking at releasing Python > 1.6b1 (or maybe it's going to be called 1.6a3 after all) on June 30! > This means that if SRE isn't ready, we'll go with an incomplete SRE. > Still better than no SRE! a major SRE patch is coming up later today. btw, what would it take for me to check it in myself (assuming someone will give me commit privs, of course)? can I apply patches via sourceforge's web interface, or do I have to figure out how to run cvs over ssh etc etc (tim? where's the second installment of your sourceforge vs. windows series?) From gmcm at hypernet.com Tue Jun 27 12:36:07 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Tue, 27 Jun 2000 06:36:07 -0400 Subject: [Python-Dev] winreg In-Reply-To: References: <39577A23.EF7DE922@prescod.net> Message-ID: <1250020276-32999633@hypernet.com> Mark wrote: [Paul] > > I've just had a chance to look at the winreg module. I think > > that it is too low-level. > > I agree. There was a proposal (from Thomas Heller, IIRC) to do > just this. I successfully argued there should be _2_ modules for > Python - the raw low-level API, which guarantees you can do > (almost) anything. A higher-level API could cover the 80% of > cases. It is probably worth getting in touch with Thomas - he > may be able to dig up his proposed high-level API. Found it. ------- Forwarded message follows ------- From: "Thomas Heller" To: , Date sent: Thu, 3 Feb 2000 14:27:00 +0100 Subject: [Python-Dev] Revised proposal (and preliminary implementation): Registry access module for Python on Windows Ok, at least the first proposal did start the discussion. Here is a revised one: A preliminary implementation is available at http://starship.python.net/crew/theller/ ----------------------------------------------------------------- ----- winreg - windows registry access module Exception: error - raised when a function fails. Will contain a windows error code and a textual description. Objects: regnode object - represents a open key in the registry. Functions: OpenKey (name) -> regnode object Opens an existing key with the specified access rights and returns a regnode object. name is specified like "HKLM\Software\Python" or "HKEY_LOCAL_MACHINE\Software\Python" CreateKey (name) -> regnode object Creates a new key or opens an existing one and returns a regnode object. For the name format see OpenKey regnode object methods: Values () -> dict Returns a dictionary mapping names to values. The or unnamed value has the key ''. The values are either strings or integers, depending on the REG_* type. GetValue ([name]) -> integer or string Returns a value specified by name or the default value. SetValue ([name,] value) Set a named or the value. Named values must be integers or string (which are stored as REG_DWORD or REG_SZ). Should an optional third parameter be used, allowing to store in other REG_* typecodes? I dont think so. DeleteValue ([name]) Deletes a named or the value. SubKeys () -> sequence Returns a sequence containing the names of all subkeys. DeleteKey (name [,recursive=0]) If recursive is 0, deletes the named key if no subkeys exist. If there are subkeys an error is raised. If recursive is not 0, the named key is deleted including subkeys. OpenKey (name) -> regnode object Openes an existing subkey and returns a regnode object pointing to it. CreateKey (name) -> regnode object Creates a new or openes an existing subkey and returns a regnode object pointing to it. regnode objects have the following properties: name - the name of the RegistryKey, something like "HKLM\Software\Python" hkey - the integer keyhandle ----------------------------------------------------------------- ----- Thomas Heller _______________________________________________ Python-Dev maillist - Python-Dev at python.org http://www.python.org/mailman/listinfo/python-dev ------- End of forwarded message ------- - Gordon From gstein at lyra.org Tue Jun 27 12:52:02 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 27 Jun 2000 03:52:02 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses wrapper.py,1.2,1.3 In-Reply-To: <200006270050.RAA26210@slayer.i.sourceforge.net>; from akuchling@users.sourceforge.net on Mon, Jun 26, 2000 at 05:50:42PM -0700 References: <200006270050.RAA26210@slayer.i.sourceforge.net> Message-ID: <20000627035202.M29590@lyra.org> I just don't buy this. Look at that code. Look at the definition of finally. That code simply screams for the use of finally. Eric: just what happens? What is "broke things"? Do you have a reproducible test case that I can use? In good conscience, I have to disagree with reverting this stuff. If we're seeking to make the code the best possible, then this is a backward step. Besides its redundancy, it also places the traceback into a local variable and then raises an exception -- a perfect recipe for creating a ref loop. Cheers, -g On Mon, Jun 26, 2000 at 05:50:42PM -0700, A.M. Kuchling wrote: > Update of /cvsroot/python/python/dist/src/Lib/curses > In directory slayer.i.sourceforge.net:/tmp/cvs-serv26153 > > Modified Files: > wrapper.py > Log Message: > Drop back to old version of wrapper(); ESR reports that it broke things, > and I lack the time to track down the cause. > > > Index: wrapper.py > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Lib/curses/wrapper.py,v > retrieving revision 1.2 > retrieving revision 1.3 > diff -C2 -r1.2 -r1.3 > *** wrapper.py 2000/06/10 23:39:05 1.2 > --- wrapper.py 2000/06/27 00:50:40 1.3 > *************** > *** 18,24 **** > --- 18,26 ---- > """ > > + res = None > try: > # Initialize curses > stdscr=curses.initscr() > + > # Turn off echoing of keys, and enter cbreak mode, > # where no buffering is performed on keyboard input > *************** > *** 30,39 **** > stdscr.keypad(1) > > ! return apply(func, (stdscr,) + rest) > ! > ! finally: > ! # Restore the terminal to a sane state on the way out. > stdscr.keypad(0) > curses.echo() ; curses.nocbreak() > curses.endwin() > > --- 32,51 ---- > stdscr.keypad(1) > > ! res = apply(func, (stdscr,) + rest) > ! except: > ! # In the event of an error, restore the terminal > ! # to a sane state. > stdscr.keypad(0) > curses.echo() ; curses.nocbreak() > curses.endwin() > + > + # Pass the exception upwards > + (exc_type, exc_value, exc_traceback) = sys.exc_info() > + raise exc_type, exc_value, exc_traceback > + else: > + # Set everything back to normal > + stdscr.keypad(0) > + curses.echo() ; curses.nocbreak() > + curses.endwin() # Terminate curses > > + return res > > > _______________________________________________ > Python-checkins mailing list > Python-checkins at python.org > http://www.python.org/mailman/listinfo/python-checkins -- Greg Stein, http://www.lyra.org/ From thomas.heller at ion-tof.com Tue Jun 27 13:09:24 2000 From: thomas.heller at ion-tof.com (Thomas Heller) Date: Tue, 27 Jun 2000 13:09:24 +0200 Subject: [Python-Dev] winreg References: Message-ID: <019601bfe028$281dab90$4500a8c0@thomasnb> > > I've just had a chance to look at the winreg module. I think that it is > > too low-level. > > I agree. There was a proposal (from Thomas Heller, IIRC) to do just this. > I successfully argued there should be _2_ modules for Python - the raw > low-level API, which guarantees you can do (almost) anything. A > higher-level API could cover the 80% of cases. It is probably worth > getting in touch with Thomas - he may be able to dig up his proposed > high-level API. Ive CCd him on this message [I hope is _was_ you Thomas - > otherwise you will be wondering WTF I am on about :] Yes, it was me :-) Here is the 3. (final?) proposal, earlier ones are in the archives: http://www.python.org/pipermail/python-dev/2000-February/003417.html and http://www.python.org/pipermail/python-dev/2000-February/003472.html ---------------------------------------------------------------------- winreg - windows registry access module Exception: error - raised when a function fails. Will contain a windows error code and a textual description. Objects: regkey object - represents a open key in the registry. Functions: OpenKey (name) -> regkey object Opens an existing key with the specified access rights and returns a regkey object. name is specified like "HKLM\Software\Python" or "HKEY_LOCAL_MACHINE\Software\Python" CreateKey (name) -> regkey object Creates a new key or opens an existing one and returns a regkey object. For the name format see OpenKey regkey object methods: Standard Mapping protocol: len (r) r[k] r[k] = x del r[k] r.clear() r.has_key(k) r.items() r.keys() r.update(dict) r.values() r.get(k[, x]) todict() -> dictionary Returns a dictionary mapping value names to values. SubKeys () -> sequence Returns a sequence containing the names of all subkeys. DeleteKey (name [,recursive=0]) If recursive is 0, deletes the named key if no subkeys exist. If there are subkeys an error is raised. If recursive is not 0, the named key is deleted including subkeys. OpenKey (name) -> regkey object Openes an existing subkey and returns a regkey object pointing to it. CreateKey (name) -> regkey object Creates a new or openes an existing subkey and returns a regkey object pointing to it. regkey objects have the following properties: name - the name of the RegistryKey, something like "HKLM\Software\Python" hkey - the integer keyhandle ---------------------------------------------------------------------- It would not be too much work to implement it, but I will be away the next 20 days... > I have no real problem with your proposed design, as long as it it written > in Python, _using_ the low-level API. It could be called "registry" or I > would even be happy for "winreg.pyd" -> "_winreg.pyd" and your new module > to be called "winreg.py" > If we change the name of the low level api module, we have to change Distutils, because it is used there. Maybe we would better use the high level api then, but there is still this 1.5 compatibility using the win32api module. Thomas From guido at beopen.com Tue Jun 27 14:23:36 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 27 Jun 2000 07:23:36 -0500 Subject: [Python-Dev] ANN: Release schedule In-Reply-To: Your message of "Tue, 27 Jun 2000 12:35:22 +0200." <017501bfe023$684fca40$f2a6b5d4@hagrid> References: <200006270235.VAA02631@cj20424-a.reston1.va.home.com> <017501bfe023$684fca40$f2a6b5d4@hagrid> Message-ID: <200006271223.HAA01391@cj20424-a.reston1.va.home.com> [effbot] > a major SRE patch is coming up later today. Great! > btw, what would it take for me to check it in myself (assuming someone > will give me commit privs, of course)? can I apply patches via sourceforge's > web interface, or do I have to figure out how to run cvs over ssh etc etc Erm, the latter. From a Unix system it's a breeze. From Windows, it's a relative breeze to do an *anonymous* checkout (no SSH required), but getting commit permission is a pain -- Tim will research this. (Do you have access to any Unix or Linux system at all?) I'll make you a developer anyway. > (tim? where's the second installment of your sourceforge vs. windows series?) I'm waiting too! --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at beopen.com Tue Jun 27 16:30:30 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 27 Jun 2000 09:30:30 -0500 Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager In-Reply-To: Your message of "Mon, 26 Jun 2000 17:38:51 -0400." References: Message-ID: <200006271430.JAA01769@cj20424-a.reston1.va.home.com> > [Fred] > > patches at python.org should get messages of patch manager activity (at > > least certain actions; not sure which ones yet, but at least > > additions). [Tim] > Fred, would you please explain how that works or where that was set up? > I've puttered away many hours now playing with the SourceForge facilities > (alas, most of that time waiting for web pages to load), but haven't > stumbled into anything that hints the patch manager knows anything about > patches at python.org. Yes, it's hidden, and Fred had to show me too. First, login to SourceForge. Then, go to the Python Project. In the left sidebar, under Project: Python, go to Project Admin. Near the top, you now see some navigation links; go to Edit Public Info. At the very bottom there are three text fields for email addresses. The address for New Patches (a misnomer -- it's really all changes made to the Patch Manager) says patches at python.org. The address for New Bugs is currently set to guido at beopen.com. I suppose I should set it to pythoneers at beopen.com or even to python-dev at python.org? We're not using the Support manager yet. --Guido van Rossum (home page: http://www.python.org/~guido/) From mhammond at skippinet.com.au Tue Jun 27 16:45:07 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Wed, 28 Jun 2000 00:45:07 +1000 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses wrapper.py,1.2,1.3 In-Reply-To: <20000627035202.M29590@lyra.org> Message-ID: > Besides its redundancy, it also places the traceback into a > local variable > and then raises an exception -- a perfect recipe for creating a ref loop. Isnt it true that _every_ time you store a traceback object as a local variable, and that traceback has a reference to the frame holding the local, you _always_ get a reference loop, regardless of how you exit the function? ie, I believe that _every_ time you store a traceback obtained from inside an except handler, you _always_ get a ref-loop, period. The only way to clean the cycle is to explictly unbind the local from the traceback. Mark. From mhammond at skippinet.com.au Tue Jun 27 16:39:15 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Wed, 28 Jun 2000 00:39:15 +1000 Subject: [Python-Dev] C# (new language from Microsoft) In-Reply-To: Message-ID: I cant say much, as I am still under NDA. However, I probably can say: * C Sharp is really not the interesting part of this technology. MS are controlling the way (the order, really) the information is coming out; as more info comes out, C Sharp should move back into perspective for what is really is. Suffice it to say, hardly anyone on slashdot is even in the ball-park! * The MS PDC in a couple of weeks will be the official announcement of the more interesting things. After this, everyone involved in the project will be completely free to discuss all they know, including me (and a few other Pythoneers) * Python has a very good and interesting story in all this - there is no need to be alarmed. If anything, be excited :-) Mark. > -----Original Message----- > From: python-dev-admin at python.org [mailto:python-dev-admin at python.org]On > Behalf Of Greg Wilson > Sent: Tuesday, 27 June 2000 8:31 PM > To: Python Developers > Subject: [Python-Dev] C# (new language from Microsoft) > > > I'm sure many of you will have seen this announcement already, but for > those who haven't, Microsoft is launching a new language to compete with > C, C++, and Java: > > http://msdn.microsoft.com/vstudio/nextgen/technology/csharpintro.asp > > Greg > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev > From paul at prescod.net Tue Jun 27 17:15:29 2000 From: paul at prescod.net (Paul Prescod) Date: Tue, 27 Jun 2000 08:15:29 -0700 Subject: [Python-Dev] winreg References: <019601bfe028$281dab90$4500a8c0@thomasnb> Message-ID: <3958C511.17282EF7@prescod.net> Mark, Thomas and whoever, thanks for your input and I hope you can spare some more... Thomas Heller wrote: > This is similar to what I have implemented... > ---------------------------------------------------------------------- > winreg - windows registry access module > > Exception: > error - raised when a function fails. Will contain > a windows error code and a textual description. As an aside, I notice that the winreg documentation says it will raise an EnvironmentError but it actually raises a WindowsError. > Objects: > regkey object - represents a open key in the > registry. Right. Even the same name. My stance was that keys would always be created from keys, so you would start with HKEY_LOCAL_MACHINE.CreateKey("Software\Python") That mirrors the underlying API a little closer and reduces the number of functions to 0. The question is whether the CreateKey and OpenKey functions are important enough as "convenience functions". > regkey object methods: > Standard Mapping protocol: > len (r) > r[k] > r[k] = x > del r[k] > r.clear() > r.has_key(k) > r.items() > r.keys() > r.update(dict) > r.values() > r.get(k[, x]) I had a separate object for values. I couldn't really justify elevating either the Subkeys or the Values. I tried to treat them as alike as possible. > todict() -> dictionary > Returns a dictionary mapping value names to values. I called this getValues() and it returned an object that was both a mapping and a sequence and allowed read/write/delete of values. > SubKeys () -> sequence > Returns a sequence containing the names of all subkeys. > > DeleteKey (name [,recursive=0]) > If recursive is 0, deletes the named key if no subkeys exist. > If there are subkeys an error is raised. > If recursive is not 0, the named key is deleted > including subkeys. I may or may not get around to implementing the recursive version. You have to be VERY CAREFUL when you test such a thing. :) > OpenKey (name) -> regkey object > Openes an existing subkey and returns a regkey > object pointing to it. Okay. > CreateKey (name) -> regkey object > Creates a new or openes an existing subkey and > returns a regkey object pointing to it. Okay. > regkey objects have the following properties: > name - the name of the RegistryKey, something > like "HKLM\Software\Python" Okay. > hkey - the integer keyhandle Is this really useful? Better to use the low-level API in that case... > If we change the name of the low level api module, we have to change > Distutils, > because it is used there. Maybe we would better use the high level api then, > but there is still this 1.5 compatibility using the win32api module. The high level could probably be made compatible with 1.5 like this: try: import _winreg except ImportError: import win32api winreg=win32api It would probably be good for DistUtils to use the high level API as soon as it is possible for testing purposes. I am considering doing away with the two enumeration interfaces. The cost/benefit of having two more objects is probably low. We can simplify the whole thing by just using methods on the regkey object: deleteValue(name) getValue(name)-> (type, value) setValue(name,(type,value)) getValueNames() -> List of strings getSubkey(name) -> regkey deleteSubkey(name) getSubkeyNames( ) -> List of strings Iterating will be slightly less efficient because it will loop twice, once to gather the names and once to do whatever you need to do but that's not the typical registry use case anyhow. Anyone who needs absolute performance can use the low-level API. Recursive iteration under the existing model: def doit( key ): for subkey in key.getSubkeyNames(): doit( subkey ) Recursive iteration under the proposed model: def doit( key ): for keyname in key.getSubkeyNames(): doit( key.getSubkey( name )) -- Paul Prescod - Not encumbered by corporate consensus When George Bush entered office, a Washington Post-ABC News poll found that 62 percent of Americans "would be willing to give up a few of the freedoms we have" for the war effort. They have gotten their wish. - "This is your bill of rights...on drugs", Harpers, Dec. 1999 From paul at prescod.net Tue Jun 27 17:28:55 2000 From: paul at prescod.net (Paul Prescod) Date: Tue, 27 Jun 2000 08:28:55 -0700 Subject: [Python-Dev] winreg features References: <019601bfe028$281dab90$4500a8c0@thomasnb> Message-ID: <3958C837.ECD925CC@prescod.net> There are a few features missing from the proposed API. I don't think that this API should serve the 80%, but rather the 97%. The only things I plan to exclude from the low level API are things that are undocumented and a little bit of performance. I see no reason not to add support for close, flush, save, remote keys and REG_FOO types. If I ever figure out how to use HIVE_VOLATILE_IS_TRUE I would add support for that too. :) -- Paul Prescod - Not encumbered by corporate consensus When George Bush entered office, a Washington Post-ABC News poll found that 62 percent of Americans "would be willing to give up a few of the freedoms we have" for the war effort. They have gotten their wish. - "This is your bill of rights...on drugs", Harpers, Dec. 1999 From paul at prescod.net Tue Jun 27 17:29:16 2000 From: paul at prescod.net (Paul Prescod) Date: Tue, 27 Jun 2000 08:29:16 -0700 Subject: [Python-Dev] winreg features References: <019601bfe028$281dab90$4500a8c0@thomasnb> Message-ID: <3958C84C.37C3EAD@prescod.net> There are a few features missing from the proposed API. I don't think that this API should serve the 80%, but rather the 97%. The only things I plan to exclude from the low level API are things that are undocumented and a little bit of performance. I want to simplify the API, not dumb it down. I see no reason not to add support for close, flush, save, remote keys and REG_FOO types. If I ever figure out how to use HIVE_VOLATILE_IS_TRUE I would add support for that too. :) -- Paul Prescod - Not encumbered by corporate consensus When George Bush entered office, a Washington Post-ABC News poll found that 62 percent of Americans "would be willing to give up a few of the freedoms we have" for the war effort. They have gotten their wish. - "This is your bill of rights...on drugs", Harpers, Dec. 1999 From thomas.heller at ion-tof.com Tue Jun 27 17:42:26 2000 From: thomas.heller at ion-tof.com (Thomas Heller) Date: Tue, 27 Jun 2000 17:42:26 +0200 Subject: [Python-Dev] winreg References: <019601bfe028$281dab90$4500a8c0@thomasnb> <3958C511.17282EF7@prescod.net> Message-ID: <02e201bfe04e$4cecc700$4500a8c0@thomasnb> (Hopefully it is ok to use the reply-all button) > ... > My stance was that keys would always be created from keys, so you would > start with > > HKEY_LOCAL_MACHINE.CreateKey("Software\Python") > > That mirrors the underlying API a little closer and reduces the number > of functions to 0. Good idea! Maybe HKLM and so on should be provided as aliases. > > > > DeleteKey (name [,recursive=0]) > > If recursive is 0, deletes the named key if no subkeys exist. > > If there are subkeys an error is raised. > > If recursive is not 0, the named key is deleted > > including subkeys. > > I may or may not get around to implementing the recursive version. You > have to be VERY CAREFUL when you test such a thing. :) Someone (I don't remember who) mentioned in the discussion about my proposal that one should use SHDeleteKey for recursive deletion of keys. See the MSDN docs on RegDeleteKey for details. Don't know if this is exposed by the lowlevel module. > > > If we change the name of the low level api module, we have to change > > Distutils, > > because it is used there. Maybe we would better use the high level api then, > > but there is still this 1.5 compatibility using the win32api module. > > The high level could probably be made compatible with 1.5 like this: > > try: > import _winreg > except ImportError: > import win32api > winreg=win32api Currently it goes like this, because win32api and winreg (which will soon be _winreg) have slightly different apis, but it will doubtlessly be solved: try: import winreg _can_read_reg = 1 hkey_mod = winreg RegOpenKeyEx = winreg.OpenKeyEx RegEnumKey = winreg.EnumKey RegEnumValue = winreg.EnumValue RegError = winreg.error except ImportError: try: import win32api import win32con _can_read_reg = 1 hkey_mod = win32con RegOpenKeyEx = win32api.RegOpenKeyEx RegEnumKey = win32api.RegEnumKey RegEnumValue = win32api.RegEnumValue RegError = win32api.error except ImportError: pass Thomas From paul at prescod.net Tue Jun 27 17:52:27 2000 From: paul at prescod.net (Paul Prescod) Date: Tue, 27 Jun 2000 08:52:27 -0700 Subject: [Python-Dev] winreg References: <019601bfe028$281dab90$4500a8c0@thomasnb> <3958C511.17282EF7@prescod.net> <02e201bfe04e$4cecc700$4500a8c0@thomasnb> Message-ID: <3958CDBB.3F354C97@prescod.net> Right now the Python list is a little slow (at least for me) so I appreciate cc:s directly to me. Thomas Heller wrote: > > Good idea! > Maybe HKLM and so on should be provided as aliases. Sure. > Someone (I don't remember who) mentioned in the discussion > about my proposal that one should use SHDeleteKey for recursive > deletion of keys. See the MSDN docs on RegDeleteKey for details. > Don't know if this is exposed by the lowlevel module. Don't think so. > Currently it goes like this, because win32api and winreg (which > will soon be _winreg) have slightly different apis, but it will > doubtlessly be solved: Ouch. I don't know if I have time to figure out all of the correspondances. Are the only differences those four method names or are those the only four differences that DistUtils happened to care about. I'm not interested in 1.5 compatibility if it will take a lot of work. -- Paul Prescod - Not encumbered by corporate consensus When George Bush entered office, a Washington Post-ABC News poll found that 62 percent of Americans "would be willing to give up a few of the freedoms we have" for the war effort. They have gotten their wish. - "This is your bill of rights...on drugs", Harpers, Dec. 1999 From thomas.heller at ion-tof.com Tue Jun 27 18:03:30 2000 From: thomas.heller at ion-tof.com (Thomas Heller) Date: Tue, 27 Jun 2000 18:03:30 +0200 Subject: [Python-Dev] winreg References: <019601bfe028$281dab90$4500a8c0@thomasnb> <3958C511.17282EF7@prescod.net> <02e201bfe04e$4cecc700$4500a8c0@thomasnb> <3958CDBB.3F354C97@prescod.net> Message-ID: <02fe01bfe051$3df655b0$4500a8c0@thomasnb> > Right now the Python list is a little slow (at least for me) so I > appreciate cc:s directly to me. Same for me: All python lists take hours to distribute the mails. > > Someone (I don't remember who) mentioned in the discussion > > about my proposal that one should use SHDeleteKey for recursive > > deletion of keys. See the MSDN docs on RegDeleteKey for details. > > Don't know if this is exposed by the lowlevel module. > > Don't think so. The tricky thing is: Deletion of keys behaves differently on Win95/98 and NT/2000. (Quoting MSDN:) The RegDeleteKey function deletes a subkey. Windows 95/98: The function also deletes all subkeys and values. To delete a key only if the key has no subkeys or values, use the SHDeleteEmptyKey function. Windows NT/2000: The subkey to be deleted must not have subkeys. To delete a key and all its subkeys, you need to recursively enumerate the subkeys and delete them individually. To recursively delete keys, use the SHDeleteKey function. (end quote) The SHDelete* funtions require version 4.71 of shlwapi.dll, which is included in Win98 or 2000 (or in IE 4.0). > > > Currently it goes like this, because win32api and winreg (which > > will soon be _winreg) have slightly different apis, but it will > > doubtlessly be solved: > > Ouch. I don't know if I have time to figure out all of the > correspondances. Are the only differences those four method names or are > those the only four differences that DistUtils happened to care about. > I'm not interested in 1.5 compatibility if it will take a lot of work. So you should simply ignore this. We will work it out on distutils. Thomas (I will disappear soon for holidays) From Vladimir.Marangozov at inrialpes.fr Tue Jun 27 18:23:52 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Tue, 27 Jun 2000 18:23:52 +0200 (CEST) Subject: [Python-Dev] ANN: Release schedule In-Reply-To: <200006270235.VAA02631@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Jun 26, 2000 09:35:52 PM Message-ID: <200006271623.SAA04926@python.inrialpes.fr> Guido van Rossum wrote: > > Here at BeOpen we're scrambling to get the release schedule for the > rest of Python 1.6 planned. We're now looking at releasing Python > 1.6b1 (or maybe it's going to be called 1.6a3 after all) on June 30! > This means that if SRE isn't ready, we'll go with an incomplete SRE. > Still better than no SRE! > > Please, PLEASE, if you have pending patches that you think should go > into 1.6b1, submit them to SourceForge. We'll do our best to have a > look at every patch submitted; but don't wait until the last moment. So, to sum up (because I'm a bit lost after all this patch-related messages), what should I do to avoid at best adding to the collective burden : 1. Should I send patches to SF and be quiet until June 30 ? 2. Should I apply for privileges and spend installing an SSH client on my box (illegal in France ;), then make my Python way into the SF galaxy ? 3. If I volunteer for help with the patches backlog, what do I do ? 4. Other options presented to me ? Context : I (will) have some patches lying around, there are some patches of mine on the pile sent to patches at python.org that I'm confident about, I have read the FAQ at SF which gave me 0 clues on how things are being set up there (only general info about who why and what for + terms of service), and I managed to create an account with a personal page containing two bookmarks in it (after being distracted with personal and project ratings + gobs of links to gobs of stuff). -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From guido at beopen.com Tue Jun 27 19:27:24 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 27 Jun 2000 12:27:24 -0500 Subject: [Python-Dev] ANN: Release schedule In-Reply-To: Your message of "Tue, 27 Jun 2000 18:23:52 +0200." <200006271623.SAA04926@python.inrialpes.fr> References: <200006271623.SAA04926@python.inrialpes.fr> Message-ID: <200006271727.MAA03564@cj20424-a.reston1.va.home.com> > 1. Should I send patches to SF and be quiet until June 30 ? Yes. Not too quiet -- helping selecting which old patches are good would help. Also downloading patches from SF and commenting on them (+1/-1) in the patches list would help. > 2. Should I apply for privileges and spend installing > an SSH client on my box (illegal in France ;), then make my Python > way into the SF galaxy ? Probably no. > 3. If I volunteer for help with the patches backlog, what do I do ? Go through the patches archives and review patches. If you find one for which you would vote +1 and which you think I might like, submit it to SF. > 4. Other options presented to me ? > > Context : I (will) have some patches lying around, there are some > patches of mine on the pile sent to patches at python.org that I'm > confident about, I have read the FAQ at SF which gave me 0 clues > on how things are being set up there (only general info about > who why and what for + terms of service), and I managed to create > an account with a personal page containing two bookmarks in it > (after being distracted with personal and project ratings + gobs of > links to gobs of stuff). Go to the Python Project Summary, then to the Patch Manager. At the top, click on Submit Patch. --Guido van Rossum (home page: http://www.python.org/~guido/) From mal at lemburg.com Tue Jun 27 18:38:54 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 27 Jun 2000 18:38:54 +0200 Subject: [Python-Dev] SF patch manager... Message-ID: <3958D89E.39D084C8@lemburg.com> [Please excuse my ranting... :-)] I've received the first round of notification message from the patch manager and can't really say that I like them. Ok, I understand that the patch manager is still alpha or beta software, but these messages really don't have any usable content at all: """ Patch #100646 has been updated. Visit SourceForge.net for more info. http://sourceforge.net/patch/?func=detailpatch&patch_id=100646&group_id=5470 """ Also, reviewing the patches has become a pain and discussing them is nearly impossible (I don't consider the slashdot like comment mechanism to be of any use: there's simply no audience for discussion). Is there any chance of tee'ing patches from SF to the patches list or some other patch discussion and review forum ? I do understand that the mechanism can help with patch *checkins*, but it's certainly not going to help much with the discussion step needed before conidering any actions. The independent peer review principal doesn't work with this kind of setup. Ok, enough whining, let's get on with business now ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From esr at thyrsus.com Tue Jun 27 18:50:53 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Tue, 27 Jun 2000 12:50:53 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses wrapper.py,1.2,1.3 In-Reply-To: <20000627035202.M29590@lyra.org>; from gstein@lyra.org on Tue, Jun 27, 2000 at 03:52:02AM -0700 References: <200006270050.RAA26210@slayer.i.sourceforge.net> <20000627035202.M29590@lyra.org> Message-ID: <20000627125053.B6531@thyrsus.com> Greg Stein : > I just don't buy this. > > Look at that code. Look at the definition of finally. That code simply > screams for the use of finally. > > Eric: just what happens? What is "broke things"? Do you have a reproducible > test case that I can use? What happened is that your version failed to pass an error exception upwards after fielding it. My test case was a buggy version of cmlconfigure.py, bug since fixed. Cleanliness is good, but the code has to work first. -- Eric S. Raymond Faith may be defined briefly as an illogical belief in the occurrence of the improbable...A man full of faith is simply one who has lost (or never had) the capacity for clear and realistic thought. He is not a mere ass: he is actually ill. -- H. L. Mencken From trentm at activestate.com Tue Jun 27 18:46:58 2000 From: trentm at activestate.com (Trent Mick) Date: Tue, 27 Jun 2000 09:46:58 -0700 Subject: [Python-Dev] ANN: Release schedule In-Reply-To: <200006270235.VAA02631@cj20424-a.reston1.va.home.com> References: <200006270235.VAA02631@cj20424-a.reston1.va.home.com> Message-ID: <20000627094658.B7257@activestate.com> On Mon, Jun 26, 2000 at 09:35:52PM -0500, Guido van Rossum wrote: > (Trent Mick, it would be helpful if you assigned each of your patches > a potential reviewer from the list of existing developers -- that way > we can split up the review load.) > Do you mean I should reassigned patch-reviewing over and above the assignments that you have done recently? I was just going to put up twenty more patches and assign them all to Tim as well. :) Kidding. If, "yes", then I will make a go at that today. BTW I have answered a couple a questions on my patches. Does the person to whom the patch is assigned get an update notification? Trent -- Trent Mick trentm at activestate.com From trentm at activestate.com Tue Jun 27 18:57:38 2000 From: trentm at activestate.com (Trent Mick) Date: Tue, 27 Jun 2000 09:57:38 -0700 Subject: [Python-Dev] testing the Python/C API (was: Re: [Patches] PyObject_GetAttr/PyObject_SetAttr core dumps if given non-string names) In-Reply-To: <14679.36964.766774.864078@localhost.localdomain> References: <20000622193610.27452.qmail@eik.g.aas.no> <395272D0.B82A0353@lemburg.com> <39531A20.1BEAA51E@lemburg.com> <14675.30233.658776.764865@localhost.localdomain> <14679.36964.766774.864078@localhost.localdomain> Message-ID: <20000627095738.D7257@activestate.com> On Mon, Jun 26, 2000 at 01:18:28PM -0400, Jeremy Hylton wrote: > Ok. I was looking for a test case to include in the test suite. I've > made the change, but it looks like it will have to go without an > accompanying test. I asked the question a while back if it would reasonable/useful/popular to have a mechanism where parts of the Python/C Api could be tested directly. My proposal used an extension module _testmodule (although I made it a core module on UN*X it should not bog down the core) which exported a bunch o' test_* routines that tested specific parts of the Python/C API. A test_internal.py module would be added to the std regression test suite that would import this module and call each of the exported test_* routines in turn. This would allow things like the _GetAttr/_SetAttr behaviour to be tested. Anybody have any opinions? Trent p.s. I have a patch largely (all except the above menntion limitation) ready for this, including some tests that I used for my 64-bit porting stuff. -- Trent Mick trentm at activestate.com From skip at mojam.com Tue Jun 27 19:11:33 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 27 Jun 2000 12:11:33 -0500 (CDT) Subject: [Python-Dev] semi-subtle atexit gotcha? Message-ID: <14680.57413.385666.482385@beluga.mojam.com> In thinking about the new atexit module a little more, it occurred to me that I've handled the case where the atexit module gets loaded after another module that wants to set sys.exitfunc (it just incorporates that function into its list of functions), but not if atexit gets loaded before another modules that uses sys.exitfunc. I see two possible choices: 1. Punt and put a bit of verbiage in the atexit section of the library reference manual and the 1.6 release notes. 2. Have atexit.register check each time it's called to see if sys.exitfunc is what it expects. This isn't a perfect solution for a couple reasons. One, there's no guarantee that other sys.exitfunc- modifying code isn't executed after the last call to atexit.register. Two, there's no guarantee that the other code doesn't attempt to be "intelligent" in a fashion similar to atexit (can you say dueling banjos?). I vote for option number one since there appears to be no guaranteed way to make it work, but I'm open to other suggestions. -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille O'Neal said: "He's got the rings. I listen to the man with the rings." From trentm at activestate.com Tue Jun 27 19:16:58 2000 From: trentm at activestate.com (Trent Mick) Date: Tue, 27 Jun 2000 10:16:58 -0700 Subject: [Python-Dev] Re: [Patches] Let's use the SourceForge Patch Manager In-Reply-To: References: <200006261449.JAA01684@cj20424-a.reston1.va.home.com> Message-ID: <20000627101658.E7257@activestate.com> On Mon, Jun 26, 2000 at 02:41:12PM -0400, Tim Peters wrote: > Intended use of SourceForge patch status tags > --------------------------------------------- > revision 1 26-Jun-2000 > > > Open > The initial status of all patches. > The patch is under consideration, but has not > been reviewed yet. > The status will normally change to Accepted or Rejected next. > The person submitting the patch should (if they can) assign > it to the person they most want to review it. > Else the patch will be assigned via > [xxx a list of expertise areas should be developed] What are the chances of getting other meta data fields on patches, i.e. changes to the patch manager? Categorizing patches could really help as a filter. For instance, I may be a Unicode genius and would like to see the patches associated with it. > Discussion of patches is carried out via > [xxx Python-Dev? patches list? without a mail gateway, > the SourceForge patch interface looks too clumsy > to use for controversial patches] I like the separation of python-dev and patches, but it is not a biggie for me. > Postponed > The previous status was Open or Accepted, but for some reason > (e.g., pending release) the patch should not be reviewed or > applied until further notice. > The status will normally change to Open or Accepted next. > Please enter a comment when changing the status to Postponed, > to record the reason, the previous status, and the conditions > under which the patch should revert to Open or Accepted. Perhaps ownership (i.e. 'assigned to') of the patch should transfer to the person responsible for later taking to patch out of 'postponed' status. Trent -- Trent Mick trentm at activestate.com From jeremy at beopen.com Tue Jun 27 19:21:28 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Tue, 27 Jun 2000 13:21:28 -0400 (EDT) Subject: [Python-Dev] Re: testing the Python/C API (was: Re: [Patches] PyObject_GetAttr/PyObject_SetAttr core dumps if given non-string names) In-Reply-To: <20000627095738.D7257@activestate.com> References: <20000622193610.27452.qmail@eik.g.aas.no> <395272D0.B82A0353@lemburg.com> <39531A20.1BEAA51E@lemburg.com> <14675.30233.658776.764865@localhost.localdomain> <14679.36964.766774.864078@localhost.localdomain> <20000627095738.D7257@activestate.com> Message-ID: <14680.58008.466802.160183@bitdiddle.concentric.com> I think testing the C API directly is a great idea! Sorry I missed it the first time around. I don't think I understand the suggested approach well enough to critique it. Most of the tests need to be written in C, right? When an error is encountered, it seems that you should check what the C API returns *and* what happens at the Python level, i.e. whether the call sets a Python exception (or clears an existing Python exception). I guess you ought to show us the code. I don't think it will go in Python 1.6, but it sounds like a valuable component for future releases. Jeremy From trentm at activestate.com Tue Jun 27 19:37:00 2000 From: trentm at activestate.com (Trent Mick) Date: Tue, 27 Jun 2000 10:37:00 -0700 Subject: [Python-Dev] Re: testing the Python/C API (was: Re: [Patches] PyObject_GetAttr/PyObject_SetAttr core dumps if given non-string names) In-Reply-To: <14680.58008.466802.160183@bitdiddle.concentric.com> References: <20000622193610.27452.qmail@eik.g.aas.no> <395272D0.B82A0353@lemburg.com> <39531A20.1BEAA51E@lemburg.com> <14675.30233.658776.764865@localhost.localdomain> <14679.36964.766774.864078@localhost.localdomain> <20000627095738.D7257@activestate.com> <14680.58008.466802.160183@bitdiddle.concentric.com> Message-ID: <20000627103700.G7257@activestate.com> On Tue, Jun 27, 2000 at 01:21:28PM -0400, Jeremy Hylton wrote: > > I don't think I understand the suggested approach well enough to > critique it. Most of the tests need to be written in C, right? When All of the testing code would be in C, in the _testmodule.c, or whatever name. > an error is encountered, it seems that you should check what the C API > returns *and* what happens at the Python level, i.e. whether the call > sets a Python exception (or clears an existing Python exception). Yes you are right. It depends on the API under test. Basically you just try to test all conditions to ensure that the API behaves as expected/advertised. > > I guess you ought to show us the code. I don't think it will go in > Python 1.6, but it sounds like a valuable component for future > releases. > Okay. I agree that this would probably not make 1.6 so I will probably wait on this for a little while. Busy. Trent -- Trent Mick trentm at activestate.com From trentm at activestate.com Tue Jun 27 19:56:47 2000 From: trentm at activestate.com (Trent Mick) Date: Tue, 27 Jun 2000 10:56:47 -0700 Subject: [Python-Dev] my dev status on SourceForge In-Reply-To: <200006271430.JAA01769@cj20424-a.reston1.va.home.com> References: <200006271430.JAA01769@cj20424-a.reston1.va.home.com> Message-ID: <20000627105647.H7257@activestate.com> SPeaking of surprising little SourceForge things: I just made the mistake of clicking on the little garbage can beside "Python" in "My Projects". I seem to have booted myself from the Python project. Can I put myself back on? or can one of you with admin status please do that for me? my SourceForge username is: tmick Sorry and thanks, Trent -- Trent Mick trentm at activestate.com From akuchlin at mems-exchange.org Tue Jun 27 20:20:21 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Tue, 27 Jun 2000 14:20:21 -0400 Subject: [Python-Dev] curses/wrapper.py In-Reply-To: References: <20000627035202.M29590@lyra.org> Message-ID: <20000627142021.G19033@kronos.cnri.reston.va.us> On Wed, Jun 28, 2000 at 12:45:07AM +1000, Mark Hammond quoted: >> Besides its redundancy, it also places the traceback into a >> local variable >> and then raises an exception -- a perfect recipe for creating a ref loop. I think this is irrelevant for the curses.wrapper() function, which simply restores the terminal state before re-raising the exception. It probably won't ever be called repeatedly, making the question of a memory leak moot. Yes, I'd like to have wrapper() use Greg Stein's simpler and tidier code. Yes, I'd like to know why ESR claims the simpler version doesn't work and have a replicable test case. But right now there are higher priority things to do, so I'm shelving this until after 1.6b1. (Right now I'm trying to get the curses module compiling on Tru64, and things don't look good.) --amk From pingster at ilm.com Tue Jun 27 20:25:01 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Tue, 27 Jun 2000 11:25:01 -0700 (PDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses ascii.py,NONE,1.1 textpad.py,NONE,1.1 In-Reply-To: <14680.29842.372192.274003@temoleh.chem.uu.nl> Message-ID: On Tue, 27 Jun 2000, Rob W. W. Hooft wrote: > AMK> --- NEW FILE --- > AMK> # > AMK> # ascii.py -- constants and memembership tests for ASCII characters > AMK> # > ^^^^^ two letters too much? Grrrr... surely by now we should be getting docstrings instead of comments at the top of modules! In keeping with the format of most other modules, i also suggest not repeating the module name. Thus: """Constants and membership tests for ASCII characters.""" -- ?!ng (166 irender improvements since May 1999) From Vladimir.Marangozov at inrialpes.fr Tue Jun 27 20:39:35 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Tue, 27 Jun 2000 20:39:35 +0200 (CEST) Subject: [Python-Dev] ANN: Release schedule In-Reply-To: from "Vladimir Marangozov" at Jun 27, 2000 06:23:52 PM Message-ID: <200006271839.UAA05354@python.inrialpes.fr> I'm resending this msg since it didn't seem to get through the 1st time (and we're experiencing some major hw&sw router problems lately) Vladimir Marangozov wrote: > > Guido van Rossum wrote: > > > > Here at BeOpen we're scrambling to get the release schedule for the > > rest of Python 1.6 planned. We're now looking at releasing Python > > 1.6b1 (or maybe it's going to be called 1.6a3 after all) on June 30! > > This means that if SRE isn't ready, we'll go with an incomplete SRE. > > Still better than no SRE! > > > > Please, PLEASE, if you have pending patches that you think should go > > into 1.6b1, submit them to SourceForge. We'll do our best to have a > > look at every patch submitted; but don't wait until the last moment. > > So, to sum up (because I'm a bit lost after all this patch-related > messages), what should I do to avoid at best adding to the collective > burden : > > 1. Should I send patches to SF and be quiet until June 30 ? > > 2. Should I apply for privileges and spend installing > an SSH client on my box (illegal in France ;), then make my Python > way into the SF galaxy ? > > 3. If I volunteer for help with the patches backlog, what do I do ? > > 4. Other options presented to me ? > > Context : I (will) have some patches lying around, there are some > patches of mine on the pile sent to patches at python.org that I'm > confident about, I have read the FAQ at SF which gave me 0 clues > on how things are being set up there (only general info about > who why and what for + terms of service), and I managed to create > an account with a personal page containing two bookmarks in it > (after being distracted with personal and project ratings + gobs of > links to gobs of stuff). > > -- > Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr > http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 > -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From paul at prescod.net Tue Jun 27 20:46:40 2000 From: paul at prescod.net (Paul Prescod) Date: Tue, 27 Jun 2000 11:46:40 -0700 Subject: [Python-Dev] winreg References: <019601bfe028$281dab90$4500a8c0@thomasnb> <3958C511.17282EF7@prescod.net> <02e201bfe04e$4cecc700$4500a8c0@thomasnb> <3958CDBB.3F354C97@prescod.net> <02fe01bfe051$3df655b0$4500a8c0@thomasnb> Message-ID: <3958F690.EDB27D07@prescod.net> I'm trying to figure out all of the constants in _winreg. Some of them seem related to functions that _winreg doesn't support. I won't put those in new winreg because they can't be used. The only one I can't figure out through web searches is REG_OPTION_OPEN_LINK. RegNotifyChangeKeyValue (unsupported) REG_NOTIFY_CHANGE_NAME REG_NOTIFY_CHANGE_LAST_SET REG_NOTIFY_CHANGE_SECURITY REG_NOTIFY_CHANGE_ATTRIBUTES RegRestoreKey (unsupported) REG_FORCE_RESTORE REG_NO_LAZY_FLUSH REG_REFRESH_HIVE REG_WHOLE_HIVE_VOLATILE RegCreateKeyEx (unxupported) REG_OPTION_RESERVED REG_OPTION_VOLATILE REG_OPTION_NON_VOLATILE REG_OPTION_BACKUP_RESTORE REG_CREATED_NEW_KEY REG_OPENED_EXISTING_KEY REG_OPTION_CREATE_LINK I presume that nobody intends to add these three functions to _winreg in time for Python 1.6! -- Paul Prescod - Not encumbered by corporate consensus When George Bush entered office, a Washington Post-ABC News poll found that 62 percent of Americans "would be willing to give up a few of the freedoms we have" for the war effort. They have gotten their wish. - "This is your bill of rights...on drugs", Harpers, Dec. 1999 From effbot at telia.com Tue Jun 27 21:25:23 2000 From: effbot at telia.com (Fredrik Lundh) Date: Tue, 27 Jun 2000 21:25:23 +0200 Subject: [Python-Dev] CVS: python/dist/src/Lib/curses wrapper.py,1.2,1.3 References: <200006270050.RAA26210@slayer.i.sourceforge.net> <20000627035202.M29590@lyra.org> <20000627125053.B6531@thyrsus.com> Message-ID: <001f01bfe06d$753492a0$f2a6b5d4@hagrid> Eric S. Raymond wrote: > What happened is that your version failed to pass an error exception upwards > after fielding it. My test case was a buggy version of cmlconfigure.py, bug > since fixed. > > Cleanliness is good, but the code has to work first. umm. as far as I can tell from the patch, there's no way your code can work in a situation where try/finally wouldn't do exactly the same thing. if you *do* get different results (try inserting "raise whatever" in the try clause to test this), it might be that you've stumbled upon a real bug (either in Python or in the curses C bindings)... From guido at beopen.com Tue Jun 27 22:25:49 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 27 Jun 2000 15:25:49 -0500 Subject: [Python-Dev] Re: my dev status on SourceForge In-Reply-To: Your message of "Tue, 27 Jun 2000 10:56:47 MST." <20000627105647.H7257@activestate.com> References: <200006271430.JAA01769@cj20424-a.reston1.va.home.com> <20000627105647.H7257@activestate.com> Message-ID: <200006272025.PAA04010@cj20424-a.reston1.va.home.com> > SPeaking of surprising little SourceForge things: > > I just made the mistake of clicking on the little garbage can beside "Python" > in "My Projects". I seem to have booted myself from the Python project. Can I > put myself back on? or can one of you with admin status please do that for > me? > > my SourceForge username is: tmick OK, you're back! --Guido van Rossum (home page: http://www.python.org/~guido/) From pingster at ilm.com Tue Jun 27 21:38:15 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Tue, 27 Jun 2000 12:38:15 -0700 (PDT) Subject: [Python-Dev] SF patch manager... In-Reply-To: <3958D89E.39D084C8@lemburg.com> Message-ID: On Tue, 27 Jun 2000, M.-A. Lemburg wrote: > I've received the first round of notification message from the > patch manager and can't really say that I like them. I wish i could propose Roundup, but it currently lacks the ability to decode e-mail attachments. Aside from that, it has reasonable (if basic) e-mail handling, colour-coded status and priorities, and so on. I would jump on it in a second except that the Software Carpentry deadline is also this Friday and i'm still barely pulling that thing together. Of course, if you feel like hacking it up to do attachments feel free to get it at http://pingster.com/roundup.html and hack away! Alternatively i suppose you could keep the patch files on SourceForge and do the discussions in Roundup as an interim solution? Messy, i know, but it might be an improvement. -- ?!ng From paul at prescod.net Tue Jun 27 21:45:16 2000 From: paul at prescod.net (Paul Prescod) Date: Tue, 27 Jun 2000 12:45:16 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses ascii.py,NONE,1.1 textpad.py,NONE,1.1 References: Message-ID: <3959044C.B5C537FA@prescod.net> Ka-Ping Yee wrote: > > -- ?!ng > > (166 irender improvements since May 1999) > Although some shots were composited with Sabre, ILM's extensions > to Discreet Logic's Flame and Inferno software, CompTime was > the compositing tool for the CG department, according to > Jeff Yost. First used for one shot in Saving Private Ryan, > CompTime is based on the studio's long-time scripted system, but > now boasts a graphical user interface and hooks for plug-ins that > can be written in Python or C++. Is it safe to say that "Without Python, Saving Private Ryan would not have been possible, much less an Oscar winner?" -- Paul Prescod - Not encumbered by corporate consensus When George Bush entered office, a Washington Post-ABC News poll found that 62 percent of Americans "would be willing to give up a few of the freedoms we have" for the war effort. They have gotten their wish. - "This is your bill of rights...on drugs", Harpers, Dec. 1999 From effbot at telia.com Tue Jun 27 22:01:26 2000 From: effbot at telia.com (Fredrik Lundh) Date: Tue, 27 Jun 2000 22:01:26 +0200 Subject: [Python-Dev] Re: testing the Python/C API References: <20000622193610.27452.qmail@eik.g.aas.no> <395272D0.B82A0353@lemburg.com> <39531A20.1BEAA51E@lemburg.com> <14675.30233.658776.764865@localhost.localdomain> <14679.36964.766774.864078@localhost.localdomain> <20000627095738.D7257@activestate.com> <14680.58008.466802.160183@bitdiddle.concentric.com> <20000627103700.G7257@activestate.com> Message-ID: <006801bfe072$7abc0820$f2a6b5d4@hagrid> trent wrote: > > I don't think I understand the suggested approach well enough to > > critique it. Most of the tests need to be written in C, right? When > > All of the testing code would be in C, in the _testmodule.c, or whatever > name. SWIG, anyone? From effbot at telia.com Tue Jun 27 22:06:30 2000 From: effbot at telia.com (Fredrik Lundh) Date: Tue, 27 Jun 2000 22:06:30 +0200 Subject: [Python-Dev] SF patch manager... References: <3958D89E.39D084C8@lemburg.com> Message-ID: <007801bfe073$3008b0c0$f2a6b5d4@hagrid> mal wrote: > I've received the first round of notification message from the > patch manager and can't really say that I like them. Ok, I > understand that the patch manager is still alpha or beta software, > but these messages really don't have any usable content at all: > > """ > Patch #100646 has been updated. > Visit SourceForge.net for more info. > > http://sourceforge.net/patch/?func=detailpatch&patch_id=100646&group_id=5470 > """ > > Also, reviewing the patches has become a pain and discussing them > is nearly impossible (I don't consider the slashdot like comment > mechanism to be of any use: there's simply no audience for > discussion). > > Is there any chance of tee'ing patches from SF to the patches > list or some other patch discussion and review forum ? I do > understand that the mechanism can help with patch *checkins*, > but it's certainly not going to help much with the discussion > step needed before conidering any actions. The independent > peer review principal doesn't work with this kind of setup. I fully agree. someone really needs to fuse the patch manager with roundup (that we should use roundup for bug tracking goes without saying...) how much work would it be to move the entire repository over to pythonlabs, btw? sourceforget is frustratingly slow... From guido at beopen.com Tue Jun 27 23:07:41 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 27 Jun 2000 16:07:41 -0500 Subject: [Python-Dev] testing the Python/C API (was: Re: [Patches] PyObject_GetAttr/PyObject_SetAttr core dumps if given non-string names) In-Reply-To: Your message of "Tue, 27 Jun 2000 09:57:38 MST." <20000627095738.D7257@activestate.com> References: <20000622193610.27452.qmail@eik.g.aas.no> <395272D0.B82A0353@lemburg.com> <39531A20.1BEAA51E@lemburg.com> <14675.30233.658776.764865@localhost.localdomain> <14679.36964.766774.864078@localhost.localdomain> <20000627095738.D7257@activestate.com> Message-ID: <200006272107.QAA04498@cj20424-a.reston1.va.home.com> > I asked the question a while back if it would reasonable/useful/popular to > have a mechanism where parts of the Python/C Api could be tested directly. > > My proposal used an extension module _testmodule (although I made it a core > module on UN*X it should not bog down the core) which exported a bunch o' > test_* routines that tested specific parts of the Python/C API. A > test_internal.py module would be added to the std regression test suite that > would import this module and call each of the exported test_* routines in > turn. This would allow things like the _GetAttr/_SetAttr behaviour to be tested. > > Anybody have any opinions? > > > Trent > > p.s. I have a patch largely (all except the above menntion limitation) ready > for this, including some tests that I used for my 64-bit porting stuff. Great idea. Please wait for 1.7. There *will* be releases after 1.6! --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at beopen.com Tue Jun 27 23:08:42 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 27 Jun 2000 16:08:42 -0500 Subject: [Python-Dev] semi-subtle atexit gotcha? In-Reply-To: Your message of "Tue, 27 Jun 2000 12:11:33 EST." <14680.57413.385666.482385@beluga.mojam.com> References: <14680.57413.385666.482385@beluga.mojam.com> Message-ID: <200006272108.QAA04509@cj20424-a.reston1.va.home.com> > In thinking about the new atexit module a little more, it occurred to me > that I've handled the case where the atexit module gets loaded after another > module that wants to set sys.exitfunc (it just incorporates that function > into its list of functions), but not if atexit gets loaded before another > modules that uses sys.exitfunc. I see two possible choices: > > 1. Punt and put a bit of verbiage in the atexit section of the library > reference manual and the 1.6 release notes. > > 2. Have atexit.register check each time it's called to see if > sys.exitfunc is what it expects. This isn't a perfect solution for a > couple reasons. One, there's no guarantee that other sys.exitfunc- > modifying code isn't executed after the last call to > atexit.register. Two, there's no guarantee that the other code > doesn't attempt to be "intelligent" in a fashion similar to atexit > (can you say dueling banjos?). > > I vote for option number one since there appears to be no guaranteed way to > make it work, but I'm open to other suggestions. Yes, #1 is good enough. I don't think there will be lots of people bitten by this... --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at beopen.com Tue Jun 27 23:11:46 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 27 Jun 2000 16:11:46 -0500 Subject: [Python-Dev] Re: [Patches] Let's use the SourceForge Patch Manager In-Reply-To: Your message of "Tue, 27 Jun 2000 10:16:58 MST." <20000627101658.E7257@activestate.com> References: <200006261449.JAA01684@cj20424-a.reston1.va.home.com> <20000627101658.E7257@activestate.com> Message-ID: <200006272111.QAA04542@cj20424-a.reston1.va.home.com> > What are the chances of getting other meta data fields on patches, i.e. > changes to the patch manager? Categorizing patches could really help as a > filter. For instance, I may be a Unicode genius and would like to see the > patches associated with it. Good idea. The PM clearly needs work. I see two places where you could submit feature requests: (1) the "Report SF Bug" item in the left side bar; (2) the "Feature Requests" discussion forum (http://sourceforge.net/forum/forum.php?forum_id=4&et=0) > I like the separation of python-dev and patches, but it is not a biggie for > me. For me it's just an annoyance, especially when cross-posting is used. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at beopen.com Tue Jun 27 23:36:57 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 27 Jun 2000 16:36:57 -0500 Subject: [Python-Dev] python.org mail unclogged Message-ID: <200006272136.QAA04723@cj20424-a.reston1.va.home.com> It seems we've removed a major source of email cloggage on python.org -- a site in France was hitting every page in the mailman membership administration using a commercial crawler (Teleport Pro) that didn't honor our robots.txt file, and forking a 4 Mb CGI script for each user in each mailing list. Thanks for Barry and Andrew! This was on top of problems caused when the Ultraseek crawler ran out of memory and caused postfix or mailman to fail. :-( Mail seems to be flowing again, the queues are emptying. Once we're happy, we'll turn on the Ultraseek crawler and search service. --Guido van Rossum (home page: http://www.python.org/~guido/) From jeremy at beopen.com Tue Jun 27 22:54:38 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Tue, 27 Jun 2000 16:54:38 -0400 (EDT) Subject: [Python-Dev] SF patch manager... In-Reply-To: References: <3958D89E.39D084C8@lemburg.com> Message-ID: <14681.5262.464079.557095@bitdiddle.concentric.com> Maybe the right solution is to work with the SourceForge maintainers to make roundup part of the standard support software. jeremy From fdrake at beopen.com Tue Jun 27 23:01:54 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 27 Jun 2000 17:01:54 -0400 (EDT) Subject: [Python-Dev] Re: [Patches] Let's use the SourceForge Patch Manager In-Reply-To: <20000627101658.E7257@activestate.com> References: <200006261449.JAA01684@cj20424-a.reston1.va.home.com> <20000627101658.E7257@activestate.com> Message-ID: <14681.5698.732269.523890@cj42289-a.reston1.va.home.com> Trent Mick writes: > Perhaps ownership (i.e. 'assigned to') of the patch should transfer to the > person responsible for later taking to patch out of 'postponed' status. Agreed; assignment should be changed whenever the next person required to deal with it changes. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From nascheme at enme.ucalgary.ca Tue Jun 27 23:05:55 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Tue, 27 Jun 2000 15:05:55 -0600 Subject: [Python-Dev] SF patch manager... In-Reply-To: <007801bfe073$3008b0c0$f2a6b5d4@hagrid>; from effbot@telia.com on Tue, Jun 27, 2000 at 10:06:30PM +0200 References: <3958D89E.39D084C8@lemburg.com> <007801bfe073$3008b0c0$f2a6b5d4@hagrid> Message-ID: <20000627150555.A3083@acs.ucalgary.ca> On Tue, Jun 27, 2000 at 10:06:30PM +0200, Fredrik Lundh wrote: > how much work would it be to move the entire repository over to > pythonlabs, btw? sourceforget is frustratingly slow... rsync access to the CVS repository would be nice too. rsync should be faster than "cvs update". Also, once you have the whole repository making diffs and checking out different versions is much faster. Neil -- "I saw `cout' being shifted "Hello world" times to the left and stopped right there." -- Steve Gonedes From jeremy at beopen.com Tue Jun 27 23:49:01 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Tue, 27 Jun 2000 17:49:01 -0400 (EDT) Subject: [Python-Dev] SF patch manager... In-Reply-To: <20000627150555.A3083@acs.ucalgary.ca> References: <3958D89E.39D084C8@lemburg.com> <007801bfe073$3008b0c0$f2a6b5d4@hagrid> <20000627150555.A3083@acs.ucalgary.ca> Message-ID: <14681.8525.343786.194271@bitdiddle.concentric.com> >>>>> "NS" == Neil Schemenauer writes: NS> On Tue, Jun 27, 2000 at 10:06:30PM +0200, Fredrik Lundh wrote: >> how much work would it be to move the entire repository over to >> pythonlabs, btw? sourceforget is frustratingly slow... NS> rsync access to the CVS repository would be nice too. rsync NS> should be faster than "cvs update". Also, once you have the NS> whole repository making diffs and checking out different NS> versions is much faster. Absolutely! OpenSSL works this way and I find it much more convenient than using a remote CVS server. I use commands like diff, log, and annotate frequently during development. Have you suggested that as a SourceForge feature? Jeremy From akuchlin at mems-exchange.org Tue Jun 27 23:47:07 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Tue, 27 Jun 2000 17:47:07 -0400 Subject: [Python-Dev] Testdrive systems Message-ID: <20000627174707.P19033@kronos.cnri.reston.va.us> Portability-related note: I've just fixed a reported compilation problem with the curses module on Tru64 Unix using a machine made available by Compaq. If you go to http://www.testdrive.compaq.com/, you can sign up for a free 30-day account on a variety of machines: Alphas running Tru64, FreeBSD, and Linux, and Intel machines running BSD or Linux. A nice way to fix reported problems quickly... The environment on the systems is a bit Spartan; emacs is there, but no fancy shells and no CVS (which is especially annoying). --amk From nascheme at enme.ucalgary.ca Wed Jun 28 00:56:09 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Tue, 27 Jun 2000 16:56:09 -0600 Subject: [Python-Dev] SF patch manager... In-Reply-To: <14681.8525.343786.194271@bitdiddle.concentric.com>; from jeremy@beopen.com on Tue, Jun 27, 2000 at 05:49:01PM -0400 References: <3958D89E.39D084C8@lemburg.com> <007801bfe073$3008b0c0$f2a6b5d4@hagrid> <20000627150555.A3083@acs.ucalgary.ca> <14681.8525.343786.194271@bitdiddle.concentric.com> Message-ID: <20000627165609.A3941@acs.ucalgary.ca> On Tue, Jun 27, 2000 at 05:49:01PM -0400, Jeremy Hylton wrote: > Have you suggested [rsync access to CVS] as a SourceForge feature? Nope. Be my guest. :) Neil From tim_one at email.msn.com Wed Jun 28 02:11:44 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 27 Jun 2000 20:11:44 -0400 Subject: [Python-Dev] SF patch manager... In-Reply-To: <3958D89E.39D084C8@lemburg.com> Message-ID: [MAL] > [Please excuse my ranting... :-)] No problem -- you're not complaining about *our* software . > I've received the first round of notification message from the > patch manager and can't really say that I like them. Ok, I > understand that the patch manager is still alpha or beta software, > but these messages really don't have any usable content at all: > > """ > Patch #100646 has been updated. > Visit SourceForge.net for more info. > > http://sourceforge.net/patch/?func=detailpatch&patch_id=100646&group_id=5470 > """ I expect the title of the patch was also in the Subject line, yes? And a live link to the patch is certainly "usable". I've found both those right on target as I've been assigned or deassigned to patches so far, although I'd sure like to see something in the body saying exactly *what* about the patch "has been updated". Not saying I think it's good enough, am saying it's (barely) a start. > Also, reviewing the patches has become a pain I don't understand that, in that the text of the patch is what you got before, and what you can get now. Is your complaint here specifically that patches don't show up in your mailbox by magic? Or something else? > and discussing them is nearly impossible (I don't consider the > slashdot like comment mechanism to be of any use: there's simply > no audience for discussion). Wholly agreed there. So use python-dev for discussions for now; I agree too with Guido that the rampant but inconsistent x-posting between patches and python-dev was part of the problem. > Is there any chance of tee'ing patches from SF to the patches > list or some other patch discussion and review forum ? I expect you know as much about SF's possibilities as anyone <0.5 wink>: don't know. The SF docs are either non-existent or inadequate, far as I can tell, and I believe I share a mistaken belief with Fred Drake that new patches "should" *already* be showing up on the patches list. > I do understand that the mechanism can help with patch *checkins*, Yes, but not yet as much as it should (e.g., the default view of patches lacks basic info like the patch current status, and there's apparently not yet any way to define a different view). > but it's certainly not going to help much with the discussion > step needed before conidering any actions. Python-Dev now, possibly roundup later. OTOH, it's perfectly adequate for tiny little principal-reviewer <-> submitter give-and-take; many patches are really quite trivial. > The independent peer review principal doesn't work with this > kind of setup. I think your view is warped on this one, as you've been in the extremely favored position of pumping out crucial patches for a hot area. Most other peoples' patches have been flatly ignored for *months* now. It's not necessarily bad if other people get some attention now too . From tim_one at email.msn.com Wed Jun 28 02:11:52 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 27 Jun 2000 20:11:52 -0400 Subject: [Python-Dev] SF patch manager... In-Reply-To: <007801bfe073$3008b0c0$f2a6b5d4@hagrid> Message-ID: [Fredrik Lundh] > ... > how much work would it be to move the entire repository over to > pythonlabs, btw? Impossibly more than we could make time for soon. > sourceforget is frustratingly slow... 'Tis very erratic indeed. It *can* be speedy, but that seems much more the exception than the rule. From pingster at ilm.com Wed Jun 28 01:29:04 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Tue, 27 Jun 2000 16:29:04 -0700 (PDT) Subject: [Python-Dev] Re: [Patches] Let's use the SourceForge Patch Manager In-Reply-To: <200006272111.QAA04542@cj20424-a.reston1.va.home.com> Message-ID: Fredrik Lundh wrote: > someone really needs to fuse the patch manager with roundup (that > we should use roundup for bug tracking goes without saying...) How sweet! Why, thank you. :) Trent Mick wrote: > What are the chances of getting other meta data fields on patches, i.e. > changes to the patch manager? Categorizing patches could really help as a > filter. For instance, I may be a Unicode genius and would like to see the > patches associated with it. I agree that doing that kind of filtering is very useful. I have a discussion thingie (based on Roundup) at http://headspaces.com/. (Also prototype -- very prototype.) I hacked out the "status" and "fixer" fields and added a "keywords" field. Not much volume yet, but i think it will work well. Perhaps something like that for discussing patches? Jeremy Hylton wrote: > Maybe the right solution is to work with the SourceForge maintainers > to make roundup part of the standard support software. Hmmm... maybe i should look into that after i've figured out how super-Roundup is going to work. -- ?!ng From gward at python.net Wed Jun 28 02:58:43 2000 From: gward at python.net (Greg Ward) Date: Tue, 27 Jun 2000 20:58:43 -0400 Subject: [Python-Dev] DOS text files and CVS Message-ID: <20000627205843.A1607@beelzebub> Hi all -- can anyone enlighten me on the right way to check in DOS text files to a CVS repository? I have Thomas Heller's C source for his simple graphical installer for Python modules, and it should definitely be in the Distutils CVS tree. But I don't want to check it in if it'll screw up line-endings for anyone. Is there a Right Way to do this? Thanks -- Greg -- Greg Ward - Linux nerd gward at python.net http://starship.python.net/~gward/ Just because you're paranoid doesn't mean they *aren't* out to get you. From tim_one at email.msn.com Wed Jun 28 03:13:54 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 27 Jun 2000 21:13:54 -0400 Subject: [Python-Dev] ANN: Release schedule In-Reply-To: <017501bfe023$684fca40$f2a6b5d4@hagrid> Message-ID: [Fredrik Lundh] > (tim? where's the second installment of your sourceforge vs. > windows series?) Waiting for you to finish SRE . Seriously, I don't *need* to get Windows checkin access for the imminent release, so I moved this down my priority list. I needed to move *something* down because finding a place to live around here is both urgent & consuming much more time than I had planned on (vacancy rate: 0%). Windows vs SourceForge is still on my plate, and I'm not giving up on it, just slipping it. just-carrying-my-plans-between-the-bathroom-&-the-bed-is- invigorating-exercise-ly y'rs - tim From mhammond at skippinet.com.au Wed Jun 28 03:18:44 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Wed, 28 Jun 2000 11:18:44 +1000 Subject: [Python-Dev] ANN: Release schedule In-Reply-To: Message-ID: > just-carrying-my-plans-between-the-bathroom-&-the-bed-is- > invigorating-exercise-ly y'rs - tim Your plans, or your pans? I-knew-you-were-old-but-not-that-old--ly, Mark. From tim_one at email.msn.com Wed Jun 28 03:39:31 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 27 Jun 2000 21:39:31 -0400 Subject: [Python-Dev] RE: [Distutils] DOS text files and CVS In-Reply-To: <20000627205843.A1607@beelzebub> Message-ID: [Greg Ward] > can anyone enlighten me on the right way to check in DOS text files to a > CVS repository? Aargh, I haven't used CVS in about 6 years ... somehow or other, I believe you need to convince CVS that it's a binary (not text) file. Then it will skip line-end conversions. not-a-solution-but-maybe-a-clue-ly y'rs - tim From gstein at lyra.org Wed Jun 28 03:46:15 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 27 Jun 2000 18:46:15 -0700 Subject: [Python-Dev] add Demo/imputil/importers.py ? Message-ID: <20000627184615.A29590@lyra.org> A while back, I pulled the "demo" importers out of imputil.py. I think those should be added into Demo/imputil/. It would also be Goodness to include JimA's zipimporter. Where would that go? Cheers, -g -- Greg Stein, http://www.lyra.org/ From gmcm at hypernet.com Wed Jun 28 03:47:30 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Tue, 27 Jun 2000 21:47:30 -0400 Subject: [Python-Dev] DOS text files and CVS In-Reply-To: <20000627205843.A1607@beelzebub> Message-ID: <1249965584-36289880@hypernet.com> Greg Ward asks: > can anyone enlighten me on the right way to check in DOS text > files to a CVS repository? I have Thomas Heller's C source for > his simple graphical installer for Python modules, and it should > definitely be in the Distutils CVS tree. But I don't want to > check it in if it'll screw up line-endings for anyone. Is there > a Right Way to do this? Well, if you checked it in from a Windows box, CVS would translate line endings to native, then a Windows checkout would translate back to Windows endings. So assuming you don't want to get your fingers dirty, give it *n*x line endings and check it in. CVS does understand text, you know :-). (And about the only Windows editor that barfs on *n*x line endings is Notepad.) - Gordon From arnold at dstc.monash.edu.au Wed Jun 28 03:50:24 2000 From: arnold at dstc.monash.edu.au (David Arnold) Date: Wed, 28 Jun 2000 11:50:24 +1000 Subject: [Python-Dev] Re: [Distutils] DOS text files and CVS In-Reply-To: Your message of "Tue, 27 Jun 2000 21:39:31 -0400." Message-ID: <200006280150.LAA17759@xevious.dstc.monash.edu.au> -->"Tim" == Tim Peters writes: Tim> Aargh, I haven't used CVS in about 6 years ... somehow or Tim> other, I believe you need to convince CVS that it's a binary Tim> (not text) file. Then it will skip line-end conversions. cvs add -kb file should work to add a binary file. not sure that this is the best way to deal with DOS files, but it should work ... d From amk1 at erols.com Wed Jun 28 04:04:53 2000 From: amk1 at erols.com (A.M. Kuchling) Date: Tue, 27 Jun 2000 22:04:53 -0400 Subject: [Python-Dev] Text about cycle GC Message-ID: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com> I've written some text for the What's New article on the GCing of cycles, but it wasn't a topic I paid close attention to at the time, so I'd like corrections. Here's what I've got; please send me comments privately. 6. Optional Collection of Cycles The C implementation of Python uses reference counting to implement garbage collection. Every Python object maintains a count of the number of references pointing to itself, and adjusts the count as references are created or destroyed. Once the reference count reaches zero, the object is no longer accessible, since you need to have a reference to an object to access it, and if the count is zero, no references exist any longer. Reference counting has some pleasant properties: it's easy to understand and implement, and the resulting implementation is portable, fairly fast, and reacts well with other libraries that implement their own memory handling schemes. The major problem with reference counting is that it sometimes doesn't realise that objects are no longer accessible, resulting in a memory leak. This happens when there are cycles of references. Consider the simplest possible cycle, a class instance which has a reference to itself: instance = SomeClass() instance.myself = instance After the above two lines of code have been executed, the reference count of instance is 2; one reference is from the variable named "'instance'", and the other is from the "myself"attribute of the instance. If the next line of code is del instance, what happens? The reference count of instance is decreased by 1, so it has a reference count of 1; the reference in the "myself" attribute still exists. Yet the instance is no longer accessible through Python code, and it could be deleted. Several objects can participate in a cycle if they have references to each other, causing all of the objects to be leaked. An experimental step has been made toward fixing this problem. When compiling Python, the -with-cycle-gc (XXX correct option flag?) option can be specified. This causes a cycle detection algorithm to be periodically executed, which looks for inaccessible cycles and deletes the objects involved. Why isn't this enabled by default? Running the cycle detection algorithm takes some time, and some tuning will be required to minimize the overhead cost. It's not yet obvious how much performance is lost, because benchmarking this is tricky and depends sensitively on how often the program creates and destroys objects. XXX is this actually the correct reason? Or is it fear of breaking software that runs happily while leaving garbage? Several people worked on this problem. Early versions were written by XXX1, XXX2. (I vaguely remember several people writing first cuts at this. Anyone recall who?) The implementation that's in Python 1.6 is a rewritten version, this time done by Neil Schemenauer. Lots of other people offered suggestions along the way, such as (in alphabetical order) Marc-Andr? Lemburg, Tim Peters, Greg Stein, Eric Tiedemann. (XXX other names? If you feel you should be added, e-mail me). The March 2000 archives of the python-dev mailing list contain most of the relevant discussion, especially in the threads titled ``Reference cycle collection for Python'' and ``Finalization again''. From ians at amc.com Wed Jun 28 03:51:45 2000 From: ians at amc.com (Ian Searle) Date: Tue, 27 Jun 2000 18:51:45 -0700 Subject: [Python-Dev] Re: [Distutils] DOS text files and CVS References: Message-ID: <39595A31.6462CA42@amc.com> The best way to check DOS text files into CVS is from a Windows/DOS machine using the CVS client/pserver route. Using this method, the files are stored in canonical format. When someone checks them out from a Unix client they get /n only. And, when someone checks them out from a Windows/DOS client, they get /r/n. And, everyone is happy (well, as much as can be expected :-) If you do a 'cvs add -kb foo.dos-txt' then CVS will treat the file as binary and forego the keyword substitutions and end of line translations. But, folks checking them out will always get the /r/n regardless of platform. -Ian Tim Peters wrote: > > [Greg Ward] > > can anyone enlighten me on the right way to check in DOS text files to a > > CVS repository? > > Aargh, I haven't used CVS in about 6 years ... somehow or other, I believe > you need to convince CVS that it's a binary (not text) file. Then it will > skip line-end conversions. > > not-a-solution-but-maybe-a-clue-ly y'rs - tim > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG at python.org > http://www.python.org/mailman/listinfo/distutils-sig From akuchlin at cnri.reston.va.us Wed Jun 28 04:04:15 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Tue, 27 Jun 2000 22:04:15 -0400 Subject: [Python-Dev] add Demo/imputil/importers.py ? In-Reply-To: <20000627184615.A29590@lyra.org>; from gstein@lyra.org on Tue, Jun 27, 2000 at 06:46:15PM -0700 References: <20000627184615.A29590@lyra.org> Message-ID: <20000627220415.A22246@newcnri.cnri.reston.va.us> On Tue, Jun 27, 2000 at 06:46:15PM -0700, Greg Stein wrote: >A while back, I pulled the "demo" importers out of imputil.py. I think those >should be added into Demo/imputil/. While on the subject of adding demo directories, I'd like to add a Demo/curses directory. (Not going to happen until after b1, though; cute little demos aren't a high priority at the moment.) --amk From bwarsaw at beopen.com Wed Jun 28 04:25:47 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 27 Jun 2000 22:25:47 -0400 (EDT) Subject: [Python-Dev] DOS text files and CVS References: <20000627205843.A1607@beelzebub> Message-ID: <14681.25131.166235.152210@anthem.concentric.net> >>>>> "GW" == Greg Ward writes: GW> can anyone enlighten me on the right way to check in DOS text GW> files to a CVS repository? I have Thomas Heller's C source GW> for his simple graphical installer for Python modules, and it GW> should definitely be in the Distutils CVS tree. But I don't GW> want to check it in if it'll screw up line-endings for anyone. GW> Is there a Right Way to do this? If there's no reason why it /has/ to be DOS text, convert it to Unix line endings first. XEmacs will even do the conversion for you! That is, if the other suggestions people have made don't help. -Barry From skip at mojam.com Wed Jun 28 04:51:03 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 27 Jun 2000 21:51:03 -0500 (CDT) Subject: [Python-Dev] readline history read/write Message-ID: <14681.26647.228866.236111@beluga.mojam.com> The original thing that motivated me to propose what became atexit.py was my desire to read and write readline history files. The two attached context diffs patch Modules/readline.c and Lib/rlcompleter.py to do that. Two new functions are added to the readline module and rlcompleter is tweaked to read the history file referenced by the PYTHONHISTORY environment variable (if it's defined) and automatically save it when the interpreter exits. I'm looking for a little feedback. Here are a few things that jumped to my mind: 1. Is it okay to add the read and register/write code to rlcompleter.py? Reading and writing readline history files doesn't have anything directly to do with identifier completion, but they both have to do with readline. 2. Assuming that history file read/write is desired, should it be predicated on the presence of an environment variable or (as in bash and other readline-aware programs) should it just happen? 3. Am I correct in assuming that this capability will only be available to Unix/Linux environments, or is readline generally available, thus forcing me to think about cross-platform issues? 4. Is there some mechanism already present in IDLE and/or PythonWin I should be aware of and try to emulate? The two context diffs are both short. You should be able to follow everything just by reading the bits of code. Offering your thoughts on the above questions shouldn't require actually modifying your interpreter. Thx, -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille O'Neal said: "He's got the rings. I listen to the man with the rings." -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: readline.dif URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rlcompleter.dif URL: From gstein at lyra.org Wed Jun 28 05:08:46 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 27 Jun 2000 20:08:46 -0700 Subject: [Python-Dev] SF patch manager... In-Reply-To: ; from tim_one@email.msn.com on Tue, Jun 27, 2000 at 08:11:52PM -0400 References: <007801bfe073$3008b0c0$f2a6b5d4@hagrid> Message-ID: <20000627200846.D29590@lyra.org> On Tue, Jun 27, 2000 at 08:11:52PM -0400, Tim Peters wrote: > [Fredrik Lundh] > > ... > > how much work would it be to move the entire repository over to > > pythonlabs, btw? > > Impossibly more than we could make time for soon. > > > sourceforget is frustratingly slow... > > 'Tis very erratic indeed. It *can* be speedy, but that seems much more the > exception than the rule. hehe... I have 30ms pings and have observed multiple Mb/sec :-) download.sourceforge.net is excellent given those stats... Of course, I'm practically just down the street. Cheers, -g -- Greg Stein, http://www.lyra.org/ From tim_one at email.msn.com Wed Jun 28 05:13:52 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 27 Jun 2000 23:13:52 -0400 Subject: [Python-Dev] SF patch manager... In-Reply-To: <20000627200846.D29590@lyra.org> Message-ID: [Greg Stein] > hehe... I have 30ms pings and have observed multiple Mb/sec :-) > > download.sourceforge.net is excellent given those stats... > > Of course, I'm practically just down the street. Would please send me the Python script you use to configure Win98 so that I can get multiple Mb/sec too? Thanks in advance. I always *knew* there was a secret way to boost these 56K laptop modems . keep-gloating-pal-and-we'll-move-everything-to-a-server-in-barry's- basement-ly y'rs - tim From gstein at lyra.org Wed Jun 28 05:25:31 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 27 Jun 2000 20:25:31 -0700 Subject: [Python-Dev] SF patch manager... In-Reply-To: ; from tim_one@email.msn.com on Tue, Jun 27, 2000 at 11:13:52PM -0400 References: <20000627200846.D29590@lyra.org> Message-ID: <20000627202531.G29590@lyra.org> On Tue, Jun 27, 2000 at 11:13:52PM -0400, Tim Peters wrote: > [Greg Stein] > > hehe... I have 30ms pings and have observed multiple Mb/sec :-) > > > > download.sourceforge.net is excellent given those stats... > > > > Of course, I'm practically just down the street. > > Would please send me the Python script you use to configure Win98 so that I > can get multiple Mb/sec too? Thanks in advance. I always *knew* there was > a secret way to boost these 56K laptop modems . DSL big boy! DSL! And I use a real OS :-) > keep-gloating-pal-and-we'll-move-everything-to-a-server-in-barry's- > basement-ly y'rs - tim eek! -- Greg Stein, http://www.lyra.org/ From tim_one at email.msn.com Wed Jun 28 06:11:22 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 28 Jun 2000 00:11:22 -0400 Subject: [Python-Dev] ANN: Release schedule In-Reply-To: Message-ID: >> just-carrying-my-plans-between-the-bathroom-&-the-bed-is- >> invigorating-exercise-ly y'rs - tim [Mark Hammond] > Your plans, or your pans? > > I-knew-you-were-old-but-not-that-old--ly, My pans are in storage somewhere in Baltimore, so I can't report on their possible growth. Or is this an Australian thing ? put-another-pan-on-the-barbie-mate?-ly y'rs - tim PS: My testicles *have* grown since I moved to VA! I'm wondering whether it's an early symptom of Lyme disease. They're still easy to carry from room to room, though, provided simply I'm careful not to trip over them. From bwarsaw at beopen.com Wed Jun 28 06:13:32 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 28 Jun 2000 00:13:32 -0400 (EDT) Subject: [Python-Dev] SF patch manager... References: <20000627200846.D29590@lyra.org> Message-ID: <14681.31596.221693.491788@anthem.concentric.net> >>>>> "TP" == Tim Peters writes: TP> keep-gloating-pal-and-we'll-move-everything-to-a-server-in-barry's- TP> basement-ly y'rs - tim Say the word, send me some hardware, and I'll clear a space between the drums, bass rig, and litter boxes. cover-it-in-sisal-and-even-the-cats'll-be-happy-ly y'rs, -Barry From tim_one at email.msn.com Wed Jun 28 07:04:36 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 28 Jun 2000 01:04:36 -0400 Subject: [Python-Dev] testing the Python/C API (was: Re: [Patches] PyObject_GetAttr/PyObject_SetAttr core dumps if given non-string names) In-Reply-To: <20000627095738.D7257@activestate.com> Message-ID: [Trent Mick] > I asked the question a while back if it would reasonable/useful/popular > to have a mechanism where parts of the Python/C Api could be tested > directly. Not only reasonable, IMO it's essential. "If it's not tested, it's broken." Tattoo that on your neighbor's forehead so it's always in mind . Every time we get a legit bug report on Python, I view it as a failure of the test suite. That's one of the things I hope to spend a lot of time on (but have not been promised I can spend any time on -- aren't startups great ?). > My proposal used an extension module _testmodule (although I made > it a core module on UN*X it should not bog down the core) which exported > a bunch o' test_* routines that tested specific parts of the Python/C > API. A test_internal.py module would be added to the std regression test > suite that would import this module and call each of the exported test_* > routines in turn. This would allow things like the _GetAttr/_SetAttr > behaviour to be tested. > > Anybody have any opinions? Great start! But the people who most need to take this seriously (including but not limited to me) have no bandwidth to spare before 1.6 is out the door. focus!-it's-not-just-for-breakfast-anymore-ly y'rs - tim From DavidA at ActiveState.com Wed Jun 28 07:33:37 2000 From: DavidA at ActiveState.com (David Ascher) Date: Tue, 27 Jun 2000 22:33:37 -0700 Subject: [Python-Dev] testing the Python/C API (was: Re: [Patches] PyObject_GetAttr/PyObject_SetAttr core dumps if given non-string names) In-Reply-To: Message-ID: > [Trent Mick] > > I asked the question a while back if it would reasonable/useful/popular > > to have a mechanism where parts of the Python/C Api could be tested > > directly. > > Not only reasonable, IMO it's essential. "If it's not tested, > it's broken." Tattoo that on your neighbor's forehead so it's always in mind . Stay _off_ my forehead, thank you very much. My hairline is receding enough without ink stains killing off hair follicles. Besides, I like my lobster-colored forehead just fine. --da From tim_one at email.msn.com Wed Jun 28 08:23:38 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 28 Jun 2000 02:23:38 -0400 Subject: [Python-Dev] C# (new language from Microsoft) In-Reply-To: Message-ID: [Mark Hammond] > ... > * Python has a very good and interesting story in all this - there is no > need to be alarmed. If anything, be excited :-) I was never worried about Python, but I lay awake at night worrying about MS -- I'm still an MS shareholder, so don't screw this up . every-new-c#-programmer-is-a-potential-python-convert-ly y'rs - tim From tim_one at email.msn.com Wed Jun 28 08:23:40 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 28 Jun 2000 02:23:40 -0400 Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager In-Reply-To: <200006271430.JAA01769@cj20424-a.reston1.va.home.com> Message-ID: [Guido van Rossum] > ... > The address for New Bugs is currently set to guido at beopen.com. I > suppose I should set it to pythoneers at beopen.com or even to > python-dev at python.org? Since we (PythonLabs, last week) decided to continue using Jitterbug (on python.org) for now, should the SF Bug Manager even be enabled? If it is enabled, and we are using Jitterbug, then someone has to own reentering SF bugs into the Jitterbug system. obviously y'rs - tim From gstein at lyra.org Wed Jun 28 08:47:06 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 27 Jun 2000 23:47:06 -0700 Subject: [Python-Dev] C# (new language from Microsoft) In-Reply-To: ; from tim_one@email.msn.com on Wed, Jun 28, 2000 at 02:23:38AM -0400 References: Message-ID: <20000627234706.N29590@lyra.org> On Wed, Jun 28, 2000 at 02:23:38AM -0400, Tim Peters wrote: > [Mark Hammond] > > ... > > * Python has a very good and interesting story in all this - there is no > > need to be alarmed. If anything, be excited :-) > > I was never worried about Python, but I lay awake at night worrying about > MS -- I'm still an MS shareholder, so don't screw this up . I'm an MS shareholder, too. Oh. Wait. Did I say I was involved? Don't think so... ahem. -g -- Greg Stein, http://www.lyra.org/ From andy at reportlab.com Wed Jun 28 09:03:07 2000 From: andy at reportlab.com (Andy Robinson) Date: Wed, 28 Jun 2000 08:03:07 +0100 Subject: [Python-Dev] SourceForge win32 HOWTO Message-ID: Sorry, I've been offline and missed this thread. I could have saved you some time. These are the instructions we've used at ReportLab to work with SourceForge on Win32. No problems so far despite several Unix and CVS newbies, myself included. They are adapted from an article by Jay Andrew Kay somewhere on Sourceforge and are generic rather than specific to the Python source. I have used the ReportLab project and my user name as an example but I'm sure you guys can adapt that.... 1. Get ftp.reportlab.com/tools/cvs-1.10-win.zip and ftp.reportlab.com/tools/ssh-1.2.14-win32bin.zip (copied from somewhere obscure for safety, I forget where) 2. Unzip these to a location on your path. Type 'cvs' or 'shh' from somewhere else to verify. 3. Choose where to keep your CVS projects; let's assume C:\code 4. Create a subdirectory c:\code\.ssh (yes, dot-ssh) 5. Create two environment variables: HOME=C:\CODE CVS_RSH=SSH On Win9x, this can be done in a batch file or autoexec.bat; on NT or 2000, go to Control Panel | System | Environment and set them at either user or machine level. The first must point to the directory above your .ssh directory. 6. If not done so, get a Sourceforge account and a project you can log in to. 7. Test SSH independently by doing SSH -l username myproject.sourceforge.net It should prompt for a password, then tell you that "myproject.sourceforge.net" is added to the list of known hosts; then give you a shell. 8. You will need either a lengthy command line or a batch file for each sourceforge project. I set cvsroot in a batch file in my 'c:\code' directory, and have one such file for each CVS project I use (about ten of them!): ------cvsreportlab.bat-------------- set HOME=C:\CODE set CVS_RSH=SSH set CVSROOT=:ext:my_user_name at cvs.myproject.sourceforge.net:/cvsroot/dirname --------------------------------------- 'dirname' is the top level directory in the CVS tree; a project can have several, but usually there is just one. 9. execute this batch file. You can now go to C:\Code and do cvs -z7 checkout myproject (z7 means 'compress network traffic', handy over dialup lines) 10. From now on, just use CVS normally. I wouldn't survive without Karl Fogel's book "Open Source Development with CVS", Coriolis Press. Footnote: for anonymous checkout, I think you just omit the 'my_user_name@' part from the CVSROOT variable. I hope this helps; let me know if people have any problems with the instructions. - Andy Robinson ReportLab From andy at robanal.demon.co.uk Wed Jun 28 09:03:08 2000 From: andy at robanal.demon.co.uk (Andy Robinson) Date: Wed, 28 Jun 2000 08:03:08 +0100 Subject: [Python-Dev] Sourceforge Interface Concerns In-Reply-To: <20000628025304.BB64A1CE0D@dinsdale.python.org> Message-ID: I missed all the SourceForge discussions, but ReportLab have been running all our development on SourceForge for five months and I'd like to share some concerns. First, we all use command line CVS, mostly from Windows; I just posted our setup instructions. It works fine but a bit slowly. I find the web interface totally unusable from IE5 and Netscape 4.XX, working over 64k lines or dialup lines. Once one logs in via SSL, only about one click in five ever returns a sensible page, and most just time out and give an error message. Many other people on the reportlab-users list and my team report similar problems. On the other hand, many are incredulous and say they have never had a problem. I found no complaints on the SF discussion groups, but as far as I can tell hardly anyone uses them. It seems to be better over big corporate connections. I don't think it is because I am in Europe; we never have trouble with our US ISPs. As a result of this, we have not used the wonderful looking bug tracking, to-do-list, patch manager etc. How many people here have actually created accounts for themselves on SourceForge and tried to do stuff when logged in - raise bugs and so on? Did it work for you? We ought to get a few data points before making this the way Python is managed. - Andy Robinson From nhodgson at bigpond.net.au Wed Jun 28 09:23:52 2000 From: nhodgson at bigpond.net.au (Neil Hodgson) Date: Wed, 28 Jun 2000 17:23:52 +1000 Subject: [Python-Dev] Sourceforge Interface Concerns References: Message-ID: <002401bfe0d1$d05a9fd0$e3cb8490@neil> > How many people here have actually created accounts for themselves on > SourceForge and tried to do stuff when logged in - raise bugs and so on? > Did it work for you? We ought to get a few data points before making this > the way Python is managed. Its generally quite good for me now that I've upgraded from a modem to a cable connection although there are brown-out periods. The only web browser I have any success with is Navigator 4.6 and 4.7. Both IE and Mozilla give poor results with SSL login. As far as getting other people to use the bug logger, its been a complete failure. Its much easier to email me or the mailing list. Some parts of SourceForge such as the file release upload are quite poorly designed and are too unpleasant to use on a slow connection if you have several packages for each release. Neil From tim_one at email.msn.com Wed Jun 28 09:28:10 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 28 Jun 2000 03:28:10 -0400 Subject: [Python-Dev] SourceForge win32 HOWTO In-Reply-To: Message-ID: [Andy Robinson] > Sorry, I've been offline and missed this thread. I could have saved you > some time. These are the instructions we've used at ReportLab to work with > SourceForge on Win32. No problems so far despite several Unix and CVS > newbies, myself included. ... Thanks, Andy! I just *knew* that if I sat on my ass, someone would solve this one for me . I'll give these instructions a try, and also see what it takes to adapt them to wincvs. Note that I'm going to be putting similar (perhaps, by an amazing coincidence, even identical) instructions up on pythonlabs.com, so if you want to stop maintaining this, dump it on me. From tim_one at email.msn.com Wed Jun 28 09:28:26 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 28 Jun 2000 03:28:26 -0400 Subject: [Python-Dev] Sourceforge Interface Concerns In-Reply-To: Message-ID: [Andy Robinson] > ... > I find the web interface totally unusable from IE5 and Netscape 4.XX, > working over 64k lines or dialup lines. Once one logs in via SSL, only > about one click in five ever returns a sensible page, and most > just time out and give an error message. Many other people on the > reportlab-users list and my team report similar problems. On the other > hand, many are incredulous and say they have never had a problem. > I found no complaints on the SF discussion groups, but as far as I can > tell hardly anyone uses them. It seems to be better over big corporate > connections. I don't think it is because I am in Europe; we never have > trouble with our US ISPs. I'm in the middle: sometimes it works great, sometimes slow as molasses (IE5 via 56K modem on the other side of the country), and an error each one of two clicks. Greg Stein lives near it, and reports wonderful access via DSL. > As a result of this, we have not used the wonderful looking bug tracking, > to-do-list, patch manager etc. They're actually pretty feeble. > How many people here have actually created accounts for themselves on > SourceForge and tried to do stuff when logged in - raise bugs and so on? > Did it work for you? We ought to get a few data points before making this > the way Python is managed. We're not using the bug tracker, task list, news, forum or support managers. Just the CVS tree and the patch manager. There are particular reasons for using those particular two, and I doubt we'll be moving more there until SF gets better. OTOH, we're also interested in *helping* SF get better! SF is as much an Open Source project as Python, and it could become an incredible resource for the entire OS community. doesn't-mean-i-won't-gripe-too-though-ly y'rs - tim From gstein at lyra.org Wed Jun 28 10:04:07 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 28 Jun 2000 01:04:07 -0700 Subject: [Python-Dev] Sourceforge Interface Concerns In-Reply-To: ; from tim_one@email.msn.com on Wed, Jun 28, 2000 at 03:28:26AM -0400 References: Message-ID: <20000628010407.T29590@lyra.org> On Wed, Jun 28, 2000 at 03:28:26AM -0400, Tim Peters wrote: >... > We're not using the bug tracker, task list, news, forum or support managers. > Just the CVS tree and the patch manager. There are particular reasons for > using those particular two, and I doubt we'll be moving more there until SF > gets better. OTOH, we're also interested in *helping* SF get better! SF is > as much an Open Source project as Python, and it could become an incredible > resource for the entire OS community. This last statement is (unfortunately) not quite true. SourceForge is developed in a closed, cathedral environment. There is no CVS access to it, and all the developers work at VA Linux. Strictly speaking, the *output* of this closed development is GPL'd. But it isn't what you would expect. The documentation for SF is separate. Apparently, there was an independent effort to help do some documentation and they got a good ways. Then the VA guys suddenly popped out the "SFDocs" project, ignoring the work from the other people. Not sure where I read that, so I can't provide a reference to the stories/threads :-( btw, there is a survey about SF that you can fill out: http://sourceforge.net/survey/survey.php?group_id=1&survey_id=10599 Cheers, -g -- Greg Stein, http://www.lyra.org/ From mal at lemburg.com Wed Jun 28 10:03:00 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 28 Jun 2000 10:03:00 +0200 Subject: [Python-Dev] SF patch manager... References: Message-ID: <3959B134.1538B4B7@lemburg.com> Tim Peters wrote: > > [MAL] > > [Please excuse my ranting... :-)] > > No problem -- you're not complaining about *our* software . > > > I've received the first round of notification message from the > > patch manager and can't really say that I like them. Ok, I > > understand that the patch manager is still alpha or beta software, > > but these messages really don't have any usable content at all: > > > > """ > > Patch #100646 has been updated. > > Visit SourceForge.net for more info. > > > > > http://sourceforge.net/patch/?func=detailpatch&patch_id=100646&group_id=5470 > > """ > > I expect the title of the patch was also in the Subject line, yes? Right, but that's just about all the information you get: the title, the fact that something changed and a link to the patch page. > And a > live link to the patch is certainly "usable". I've found both those right > on target as I've been assigned or deassigned to patches so far, although > I'd sure like to see something in the body saying exactly *what* about the > patch "has been updated". > > Not saying I think it's good enough, am saying it's (barely) a start. True and I don't want to put this down. The only reason for my ranting is that I'd rather get more infos in mail than via some link to a page. Discussing patches via quoting email is just so much more convenient -- opening two or three browsers to get at the hard facts isn't and, as others have already noted, is rather slow too. > > Also, reviewing the patches has become a pain > > I don't understand that, in that the text of the patch is what you got > before, and what you can get now. Is your complaint here specifically that > patches don't show up in your mailbox by magic? Or something else? I would very much prefer to get the patches or changes appended to the update messages (much like was manually done on patches at python.org). That way I can read the patch and then reply to the sender and the list community from within the mail application -- without copy&paste, looking up email addresses in SF etc. > > and discussing them is nearly impossible (I don't consider the > > slashdot like comment mechanism to be of any use: there's simply > > no audience for discussion). > > Wholly agreed there. So use python-dev for discussions for now; I agree too > with Guido that the rampant but inconsistent x-posting between patches and > python-dev was part of the problem. > > > Is there any chance of tee'ing patches from SF to the patches > > list or some other patch discussion and review forum ? > > I expect you know as much about SF's possibilities as anyone <0.5 wink>: > don't know. The SF docs are either non-existent or inadequate, far as I can > tell, and I believe I share a mistaken belief with Fred Drake that new > patches "should" *already* be showing up on the patches list. They are showing up there... at least new ones are. Discussions (via posting comments on the patch page) are not relayed to the list though: only the comment authors get an email. > > I do understand that the mechanism can help with patch *checkins*, > > Yes, but not yet as much as it should (e.g., the default view of patches > lacks basic info like the patch current status, and there's apparently not > yet any way to define a different view). > > > but it's certainly not going to help much with the discussion > > step needed before conidering any actions. > > Python-Dev now, possibly roundup later. OTOH, it's perfectly adequate for > tiny little principal-reviewer <-> submitter give-and-take; many patches are > really quite trivial. True, but even small patches occasionally need peer review from more people than just the assigned developer. > > The independent peer review principal doesn't work with this > > kind of setup. > > I think your view is warped on this one, as you've been in the extremely > favored position of pumping out crucial patches for a hot area. Most other > peoples' patches have been flatly ignored for *months* now. It's not > necessarily bad if other people get some attention now too . Oops, did it shine through that much ? ;-) Seriously, I would like to see a processing speedup too, it's just the workflow that bothers me a bit. BTW, another great feature for the patch manager would be a button to perform the actual checkin via the web interface. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From rob at hooft.net Wed Jun 28 11:27:18 2000 From: rob at hooft.net (Rob W. W. Hooft) Date: Wed, 28 Jun 2000 11:27:18 +0200 (CEST) Subject: [Python-Dev] Typo's Message-ID: <14681.50422.966321.780406@temoleh.chem.uu.nl> I located some typo's in the CVS. Here is a patch. Warning: I'm a non-native English speaker. Please verify fixes. Rob Index: Demo/pdist/rcslib.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Demo/pdist/rcslib.py,v retrieving revision 1.6 diff -u -r1.6 rcslib.py --- Demo/pdist/rcslib.py 1998/09/14 16:43:57 1.6 +++ Demo/pdist/rcslib.py 2000/06/28 07:42:50 @@ -296,7 +296,7 @@ def _system(self, cmd): """INTERNAL: run COMMAND in a subshell. - Standard input for the command is taken fron /dev/null. + Standard input for the command is taken from /dev/null. Raise IOError when the exit status is not zero. Index: Demo/sgi/video/Vcopy.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Demo/sgi/video/Vcopy.py,v retrieving revision 1.7 diff -u -r1.7 Vcopy.py --- Demo/sgi/video/Vcopy.py 1996/11/27 19:50:07 1.7 +++ Demo/sgi/video/Vcopy.py 2000/06/28 07:42:50 @@ -8,7 +8,7 @@ # - Manipulate the time base: # = resample at a fixed rate # = divide the time codes by a speed factor (to make it go faster/slower) -# = drop frames that are less than n msec apart (to accomodate slow players) +# = drop frames that are less than n msec apart (to accommodate slow players) # - Convert to a different format # - Magnify (scale) the image Index: Demo/sgi/video/Vtime.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Demo/sgi/video/Vtime.py,v retrieving revision 1.4 diff -u -r1.4 Vtime.py --- Demo/sgi/video/Vtime.py 1996/11/27 19:50:28 1.4 +++ Demo/sgi/video/Vtime.py 2000/06/28 07:42:50 @@ -7,7 +7,7 @@ # # - resample at a fixed rate # - divide the time codes by a speed factor (to make it go faster/slower) -# - drop frames that are less than n msec apart (to accomodate slow players) +# - drop frames that are less than n msec apart (to accommodate slow players) # Usage: Index: Lib/Queue.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/Queue.py,v retrieving revision 1.10 diff -u -r1.10 Queue.py --- Lib/Queue.py 2000/02/02 15:10:14 1.10 +++ Lib/Queue.py 2000/06/28 07:42:51 @@ -119,7 +119,7 @@ def _qsize(self): return len(self.queue) - # Check wheter the queue is empty + # Check whether the queue is empty def _empty(self): return not self.queue Index: Lib/binhex.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/binhex.py,v retrieving revision 1.12 diff -u -r1.12 binhex.py --- Lib/binhex.py 2000/02/04 15:39:29 1.12 +++ Lib/binhex.py 2000/06/28 07:42:51 @@ -13,7 +13,7 @@ # XXXX Note: currently, textfiles appear in mac-form on all platforms. # We seem to lack a simple character-translate in python. # (we should probably use ISO-Latin-1 on all but the mac platform). -# XXXX The simeple routines are too simple: they expect to hold the complete +# XXXX The simple routines are too simple: they expect to hold the complete # files in-core. Should be fixed. # XXXX It would be nice to handle AppleDouble format on unix # (for servers serving macs). @@ -48,7 +48,7 @@ try: openrf = MacOS.openrf except AttributeError: - # Backward compatability + # Backward compatibility openrf = open def FInfo(): Index: Lib/calendar.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/calendar.py,v retrieving revision 1.15 diff -u -r1.15 calendar.py --- Lib/calendar.py 2000/02/02 15:10:14 1.15 +++ Lib/calendar.py 2000/06/28 07:42:51 @@ -1,6 +1,6 @@ """Calendar printing functions""" -# Revision 2: uses funtions from built-in time module +# Revision 2: uses functions from built-in time module # Import functions and variables from time module from time import localtime, mktime Index: Lib/fnmatch.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/fnmatch.py,v retrieving revision 1.7 diff -u -r1.7 fnmatch.py --- Lib/fnmatch.py 1997/10/22 20:57:40 1.7 +++ Lib/fnmatch.py 2000/06/28 07:42:51 @@ -36,7 +36,7 @@ return fnmatchcase(name, pat) def fnmatchcase(name, pat): - """Test wheter FILENAME matches PATTERN, including case. + """Test whether FILENAME matches PATTERN, including case. This is a version of fnmatch() which doesn't case-normalize its arguments. Index: Lib/locale.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/locale.py,v retrieving revision 1.6 diff -u -r1.6 locale.py --- Lib/locale.py 2000/06/08 17:49:41 1.6 +++ Lib/locale.py 2000/06/28 07:42:52 @@ -220,7 +220,7 @@ The language code corresponds to RFC 1766. code and encoding can be None in case the values cannot be determined or are - unkown to this implementation. + unknown to this implementation. """ code = normalize(localename) @@ -229,7 +229,7 @@ elif code == 'C': return None, None else: - raise ValueError,'unkown locale: %s' % localename + raise ValueError,'unknown locale: %s' % localename return l def _build_localename(localetuple): Index: Lib/posixpath.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/posixpath.py,v retrieving revision 1.30 diff -u -r1.30 posixpath.py --- Lib/posixpath.py 2000/02/29 13:31:16 1.30 +++ Lib/posixpath.py 2000/06/28 07:42:52 @@ -24,7 +24,7 @@ return s -# Return wheter a path is absolute. +# Return whether a path is absolute. # Trivial in Posix, harder on the Mac or MS-DOS. def isabs(s): @@ -304,7 +304,7 @@ # Expand paths containing shell variable substitutions. # This expands the forms $variable and ${variable} only. -# Non-existant variables are left unchanged. +# Non-existent variables are left unchanged. _varprog = None Index: Lib/sgmllib.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/sgmllib.py,v retrieving revision 1.19 diff -u -r1.19 sgmllib.py --- Lib/sgmllib.py 2000/02/04 15:28:40 1.19 +++ Lib/sgmllib.py 2000/06/28 07:42:53 @@ -47,7 +47,7 @@ # and , respectively, or do_foo to handle by itself. # (Tags are converted to lower case for this purpose.) The data # between tags is passed to the parser by calling self.handle_data() -# with some data as argument (the data may be split up in arbutrary +# with some data as argument (the data may be split up in arbitrary # chunks). Entity references are passed by calling # self.handle_entityref() with the entity reference as argument. Index: Lib/site.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/site.py,v retrieving revision 1.11 diff -u -r1.11 site.py --- Lib/site.py 2000/06/07 09:12:09 1.11 +++ Lib/site.py 2000/06/28 07:42:53 @@ -122,7 +122,7 @@ # # Set the string encoding used by the Unicode implementation to the # encoding used by the default locale of this system. If the default -# encoding cannot be determined or is unkown, it defaults to 'ascii'. +# encoding cannot be determined or is unknown, it defaults to 'ascii'. # def locale_aware_defaultencoding(): import locale Index: Lib/urllib2.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/urllib2.py,v retrieving revision 1.3 diff -u -r1.3 urllib2.py --- Lib/urllib2.py 2000/02/10 17:17:14 1.3 +++ Lib/urllib2.py 2000/06/28 07:42:54 @@ -141,7 +141,7 @@ _opener = opener # do these error classes make sense? -# make sure all of the IOError stuff is overriden. we just want to be +# make sure all of the IOError stuff is overridden. we just want to be # subtypes. class URLError(IOError): Index: Lib/xmllib.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/xmllib.py,v retrieving revision 1.18 diff -u -r1.18 xmllib.py --- Lib/xmllib.py 2000/06/21 20:01:10 1.18 +++ Lib/xmllib.py 2000/06/28 07:42:54 @@ -79,7 +79,7 @@ # special names to handle tags: start_foo and end_foo to handle # and , respectively. The data between tags is passed to the # parser by calling self.handle_data() with some data as argument (the -# data may be split up in arbutrary chunks). +# data may be split up in arbitrary chunks). class XMLParser: attributes = {} # default, to be overridden Index: Lib/distutils/cmd.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/distutils/cmd.py,v retrieving revision 1.18 diff -u -r1.18 cmd.py --- Lib/distutils/cmd.py 2000/06/08 00:02:36 1.18 +++ Lib/distutils/cmd.py 2000/06/28 07:42:55 @@ -323,7 +323,7 @@ should be disabled by the "dry run" flag, and should announce themselves if the current verbosity level is high enough. This method takes care of all that bureaucracy for you; all you have to - do is supply the funtion to call and an argument tuple for it (to + do is supply the function to call and an argument tuple for it (to embody the "external action" being performed), a message to print if the verbosity level is high enough, and an optional verbosity threshold. Index: Lib/distutils/util.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/distutils/util.py,v retrieving revision 1.37 diff -u -r1.37 util.py --- Lib/distutils/util.py 2000/06/24 20:40:02 1.37 +++ Lib/distutils/util.py 2000/06/28 07:42:55 @@ -28,7 +28,7 @@ return os.path.normpath(path) -# More backwards compatability hacks +# More backwards compatibility hacks def extend (list, new_list): """Appends the list 'new_list' to 'list', just like the 'extend()' list method does in Python 1.5.2 -- but this works on earlier Index: Lib/distutils/version.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/distutils/version.py,v retrieving revision 1.1 diff -u -r1.1 version.py --- Lib/distutils/version.py 1998/12/18 22:00:30 1.1 +++ Lib/distutils/version.py 2000/06/28 07:42:55 @@ -207,7 +207,7 @@ # provides enough benefit to be worth using, and will submit their # version numbering scheme to its domination. The free-thinking # anarchists in the lot will never give in, though, and something needs -# to be done to accomodate them. +# to be done to accommodate them. # # Perhaps a "moderately strict" version class could be implemented that # lets almost anything slide (syntactically), and makes some heuristic Index: Lib/distutils/command/build_ext.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/distutils/command/build_ext.py,v retrieving revision 1.51 diff -u -r1.51 build_ext.py --- Lib/distutils/command/build_ext.py 2000/06/28 01:29:37 1.51 +++ Lib/distutils/command/build_ext.py 2000/06/28 07:42:56 @@ -1,7 +1,7 @@ """distutils.command.build_ext Implements the Distutils 'build_ext' command, for building extension -modules (currently limited to C extensions, should accomodate C++ +modules (currently limited to C extensions, should accommodate C++ extensions ASAP).""" # created 1999/08/09, Greg Ward @@ -385,7 +385,7 @@ # Next, compile the source code to object files. # XXX not honouring 'define_macros' or 'undef_macros' -- the - # CCompiler API needs to change to accomodate this, and I + # CCompiler API needs to change to accommodate this, and I # want to do one thing at a time! # Two possible sources for extra compiler arguments: Index: Lib/dos-8x3/posixpat.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/dos-8x3/posixpat.py,v retrieving revision 1.10 diff -u -r1.10 posixpat.py --- Lib/dos-8x3/posixpat.py 2000/05/08 17:31:00 1.10 +++ Lib/dos-8x3/posixpat.py 2000/06/28 07:42:56 @@ -24,7 +24,7 @@ return s -# Return wheter a path is absolute. +# Return whether a path is absolute. # Trivial in Posix, harder on the Mac or MS-DOS. def isabs(s): @@ -304,7 +304,7 @@ # Expand paths containing shell variable substitutions. # This expands the forms $variable and ${variable} only. -# Non-existant variables are left unchanged. +# Non-existent variables are left unchanged. _varprog = None Index: Lib/dos-8x3/queue.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/dos-8x3/queue.py,v retrieving revision 1.7 diff -u -r1.7 queue.py --- Lib/dos-8x3/queue.py 2000/05/08 17:31:00 1.7 +++ Lib/dos-8x3/queue.py 2000/06/28 07:42:56 @@ -119,7 +119,7 @@ def _qsize(self): return len(self.queue) - # Check wheter the queue is empty + # Check whether the queue is empty def _empty(self): return not self.queue Index: Lib/dos-8x3/test_win.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/dos-8x3/test_win.py,v retrieving revision 1.1 diff -u -r1.1 test_win.py --- Lib/dos-8x3/test_win.py 2000/05/08 17:31:03 1.1 +++ Lib/dos-8x3/test_win.py 2000/06/28 07:42:57 @@ -115,7 +115,7 @@ # Opening should now fail! try: key = OpenKey(root_key, test_key_name) - assert 0, "Could open the non-existant key" + assert 0, "Could open the non-existent key" except WindowsError: # Use this error name this time pass Index: Lib/dos-8x3/test_zli.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/dos-8x3/test_zli.py,v retrieving revision 1.5 diff -u -r1.5 test_zli.py --- Lib/dos-8x3/test_zli.py 2000/05/08 17:31:03 1.5 +++ Lib/dos-8x3/test_zli.py 2000/06/28 07:42:57 @@ -11,7 +11,7 @@ buf = file.read() * 8 file.close() -# test the chucksums (hex so the test doesn't break on 64-bit machines) +# test the checksums (hex so the test doesn't break on 64-bit machines) print hex(zlib.crc32('penguin')), hex(zlib.crc32('penguin', 1)) print hex(zlib.adler32('penguin')), hex(zlib.adler32('penguin', 1)) Index: Lib/plat-irix5/CL_old.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/plat-irix5/CL_old.py,v retrieving revision 1.1 diff -u -r1.1 CL_old.py --- Lib/plat-irix5/CL_old.py 1995/05/17 11:18:22 1.1 +++ Lib/plat-irix5/CL_old.py 2000/06/28 07:42:57 @@ -200,7 +200,7 @@ BOTTOM_UP = 1 # -# SGI Proprietaty Algorithm Header Start Code +# SGI Proprietary Algorithm Header Start Code # HEADER_START_CODE = 0xc1C0DEC Index: Lib/plat-irix5/flp.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/plat-irix5/flp.py,v retrieving revision 1.17 diff -u -r1.17 flp.py --- Lib/plat-irix5/flp.py 1998/03/26 20:22:58 1.17 +++ Lib/plat-irix5/flp.py 2000/06/28 07:42:57 @@ -203,7 +203,7 @@ return datum[1] # # Internal: parse fd form, or skip if name doesn't match. -# the special value None means 'allways parse it'. +# the special value None means 'always parse it'. # def _parse_fd_form(file, name): datum = _parse_1_line(file) @@ -222,7 +222,7 @@ return None # -# Internal class: a convient place to store object info fields +# Internal class: a convenient place to store object info fields # class _newobj: def add(self, name, value): Index: Lib/plat-irix5/panel.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/plat-irix5/panel.py,v retrieving revision 1.4 diff -u -r1.4 panel.py --- Lib/plat-irix5/panel.py 1995/09/18 22:00:37 1.4 +++ Lib/plat-irix5/panel.py 2000/06/28 07:42:58 @@ -2,7 +2,7 @@ # # Support for the Panel library. # Uses built-in module 'pnl'. -# Applciations should use 'panel.function' instead of 'pnl.function'; +# Applications should use 'panel.function' instead of 'pnl.function'; # most 'pnl' functions are transparently exported by 'panel', # but dopanel() is overridden and you have to use this version # if you want to use callbacks. @@ -137,7 +137,7 @@ print 'assign failed:', stmt -# Build a real actuator from an actuator descriptior. +# Build a real actuator from an actuator description. # Return a pair (actuator, name). # def build_actuator(descr): Index: Lib/plat-irix6/flp.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/plat-irix6/flp.py,v retrieving revision 1.4 diff -u -r1.4 flp.py --- Lib/plat-irix6/flp.py 1998/03/26 20:23:01 1.4 +++ Lib/plat-irix6/flp.py 2000/06/28 07:42:58 @@ -203,7 +203,7 @@ return datum[1] # # Internal: parse fd form, or skip if name doesn't match. -# the special value None means 'allways parse it'. +# the special value None means 'always parse it'. # def _parse_fd_form(file, name): datum = _parse_1_line(file) @@ -222,7 +222,7 @@ return None # -# Internal class: a convient place to store object info fields +# Internal class: a convenient place to store object info fields # class _newobj: def add(self, name, value): Index: Lib/plat-irix6/panel.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/plat-irix6/panel.py,v retrieving revision 1.1 diff -u -r1.1 panel.py --- Lib/plat-irix6/panel.py 1997/01/15 19:19:11 1.1 +++ Lib/plat-irix6/panel.py 2000/06/28 07:42:58 @@ -2,7 +2,7 @@ # # Support for the Panel library. # Uses built-in module 'pnl'. -# Applciations should use 'panel.function' instead of 'pnl.function'; +# Applications should use 'panel.function' instead of 'pnl.function'; # most 'pnl' functions are transparently exported by 'panel', # but dopanel() is overridden and you have to use this version # if you want to use callbacks. @@ -137,7 +137,7 @@ print 'assign failed:', stmt -# Build a real actuator from an actuator descriptior. +# Build a real actuator from an actuator description. # Return a pair (actuator, name). # def build_actuator(descr): Index: Lib/test/test_al.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/test/test_al.py,v retrieving revision 1.2 diff -u -r1.2 test_al.py --- Lib/test/test_al.py 1998/03/26 19:41:38 1.2 +++ Lib/test/test_al.py 2000/06/28 07:42:58 @@ -8,7 +8,7 @@ alattrs = ['__doc__', '__name__', 'getdefault', 'getminmax', 'getname', 'getparams', 'newconfig', 'openport', 'queryparams', 'setparams'] -# This is a very inobstrusive test for the existance of the al module and all it's +# This is a very inobtrusive test for the existence of the al module and all it's # attributes. More comprehensive examples can be found in Demo/al def main(): Index: Lib/test/test_b1.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/test/test_b1.py,v retrieving revision 1.22 diff -u -r1.22 test_b1.py --- Lib/test/test_b1.py 2000/04/14 19:13:22 1.22 +++ Lib/test/test_b1.py 2000/06/28 07:42:58 @@ -270,7 +270,7 @@ # Different base: if int("10",16) <> 16L: raise TestFailed, 'int("10",16)' if int(u"10",16) <> 16L: raise TestFailed, 'int(u"10",16)' -# Test conversion fron strings and various anomalies +# Test conversion from strings and various anomalies L = [ ('0', 0), ('1', 1), Index: Lib/test/test_cd.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/test/test_cd.py,v retrieving revision 1.2 diff -u -r1.2 test_cd.py --- Lib/test/test_cd.py 1998/03/26 19:41:49 1.2 +++ Lib/test/test_cd.py 2000/06/28 07:42:58 @@ -10,7 +10,7 @@ 'ident', 'index', 'msftoframe', 'open', 'pnum', 'ptime'] -# This is a very inobstrusive test for the existance of the cd module and all it's +# This is a very inobtrusive test for the existence of the cd module and all it's # attributes. More comprehensive examples can be found in Demo/cd and # require that you have a CD and a CD ROM drive Index: Lib/test/test_cl.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/test/test_cl.py,v retrieving revision 1.2 diff -u -r1.2 test_cl.py --- Lib/test/test_cl.py 1998/03/26 19:41:52 1.2 +++ Lib/test/test_cl.py 2000/06/28 07:42:58 @@ -63,7 +63,7 @@ 'YUV422DC', 'YUV422HC', '__doc__', '__name__', 'cvt_type', 'error'] -# This is a very inobstrusive test for the existance of the cl +# This is a very inobtrusive test for the existence of the cl # module and all it's attributes. def main(): Index: Lib/test/test_pwd.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/test/test_pwd.py,v retrieving revision 1.5 diff -u -r1.5 test_pwd.py --- Lib/test/test_pwd.py 1998/03/26 19:42:32 1.5 +++ Lib/test/test_pwd.py 2000/06/28 07:42:58 @@ -59,7 +59,7 @@ else: print 'fakename', fakename, 'did not except pwd.getpwnam()' -# Choose a non-existant uid. +# Choose a non-existent uid. fakeuid = 4127 while byuids.has_key(fakeuid): fakeuid = (fakeuid * 3) % 0x10000 Index: Lib/test/test_winreg.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/test/test_winreg.py,v retrieving revision 1.2 diff -u -r1.2 test_winreg.py --- Lib/test/test_winreg.py 2000/04/01 05:25:57 1.2 +++ Lib/test/test_winreg.py 2000/06/28 07:42:58 @@ -115,7 +115,7 @@ # Opening should now fail! try: key = OpenKey(root_key, test_key_name) - assert 0, "Could open the non-existant key" + assert 0, "Could open the non-existent key" except WindowsError: # Use this error name this time pass Index: Lib/test/test_zlib.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/test/test_zlib.py,v retrieving revision 1.7 diff -u -r1.7 test_zlib.py --- Lib/test/test_zlib.py 2000/02/10 15:31:07 1.7 +++ Lib/test/test_zlib.py 2000/06/28 07:42:59 @@ -11,7 +11,7 @@ buf = file.read() * 8 file.close() -# test the chucksums (hex so the test doesn't break on 64-bit machines) +# test the checksums (hex so the test doesn't break on 64-bit machines) print hex(zlib.crc32('penguin')), hex(zlib.crc32('penguin', 1)) print hex(zlib.adler32('penguin')), hex(zlib.adler32('penguin', 1)) Index: Python/exceptions.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/exceptions.c,v retrieving revision 1.2 diff -u -r1.2 exceptions.c --- Python/exceptions.c 2000/06/20 18:36:26 1.2 +++ Python/exceptions.c 2000/06/28 07:42:59 @@ -189,7 +189,7 @@ * * First thing we create is the base class for all exceptions, called * appropriately enough: Exception. Creation of this class makes no - * assumptions about the existance of any other exception class -- except + * assumptions about the existence of any other exception class -- except * for TypeError, which can conditionally exist. * * Next, StandardError is created (which is quite simple) followed by Index: Python/import.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/import.c,v retrieving revision 2.134 diff -u -r2.134 import.c --- Python/import.c 2000/05/03 23:44:39 2.134 +++ Python/import.c 2000/06/28 07:43:01 @@ -87,7 +87,7 @@ #define MAGIC (50428 | ((long)'\r'<<16) | ((long)'\n'<<24)) /* Magic word as global; note that _PyImport_Init() can change the - value of this global to accomodate for alterations of how the + value of this global to accommodate for alterations of how the compiler works which are enabled by command line switches. */ static long pyc_magic = MAGIC; From effbot at telia.com Wed Jun 28 11:47:32 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 28 Jun 2000 11:47:32 +0200 Subject: [Python-Dev] Typo's References: <14681.50422.966321.780406@temoleh.chem.uu.nl> Message-ID: <012f01bfe0e5$e3dce360$f2a6b5d4@hagrid> > I located some typo's in the CVS. Here is a patch. wow! just one nit: "inobstrusive" should be "unobtrusive" (not "inobtrusive") (and it's not clear if "descriptior" means "description" or "descriptor"...) > Warning: I'm a non-native English speaker. same here. From effbot at telia.com Wed Jun 28 13:07:24 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 28 Jun 2000 13:07:24 +0200 Subject: [Python-Dev] OT: A Day in the Life of p5p Message-ID: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> http://prometheus.frii.com/~gnat/yapc/2000-p5p.txt unfortunately, his "What is it with those Python fucks anyway" talk isn't posted... ;-) From fdrake at beopen.com Wed Jun 28 13:16:53 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Wed, 28 Jun 2000 07:16:53 -0400 (EDT) Subject: [Python-Dev] back up & running Message-ID: <14681.56997.50955.892954@cj42289-a.reston1.va.home.com> My mega-laptop got fixed faster than I'd expected, so I'm back up to doing useful work. My top priorities are handling patches and going back through my email to find all the documentation patches that have sat idle for too long. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From mwh21 at cam.ac.uk Wed Jun 28 13:54:27 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 28 Jun 2000 12:54:27 +0100 Subject: [Python-Dev] Sourceforge Interface Concerns In-Reply-To: "Andy Robinson"'s message of "Wed, 28 Jun 2000 08:03:08 +0100" References: Message-ID: "Andy Robinson" writes: > It seems to be better over big corporate connections. I don't think it is > because I am in Europe; we never have trouble with our US ISPs. FWIW, it's pretty good from here (but then the university has pretty serious bandwidth). It seems a bit odd that it's so much worse with lower badwidth (in particular that people on modems get more errors). Oh well. Cheers, M. From Vladimir.Marangozov at inrialpes.fr Wed Jun 28 14:22:56 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Wed, 28 Jun 2000 14:22:56 +0200 (CEST) Subject: [Python-Dev] back up & running In-Reply-To: <14681.56997.50955.892954@cj42289-a.reston1.va.home.com> from "Fred L. Drake, Jr." at Jun 28, 2000 07:16:53 AM Message-ID: <200006281222.OAA03150@python.inrialpes.fr> Fred L. Drake, Jr. wrote: > > My mega-laptop got fixed faster than I'd expected, so I'm back up to > doing useful work. My top priorities are handling patches and going > back through my email to find all the documentation patches that have > sat idle for too long. Excellent! Finally someone who cares to checkin patches. I've been disappointed to see that the June 30 intent-date was announced, but people keep chewing-gumming about SourceForge caveats while the patches backlog grows and the number of closed patches stays invariably to 3, of which one is a test! -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From bwarsaw at beopen.com Wed Jun 28 15:27:12 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 28 Jun 2000 09:27:12 -0400 (EDT) Subject: [Python-Dev] Sourceforge Interface Concerns References: <20000628025304.BB64A1CE0D@dinsdale.python.org> Message-ID: <14681.64816.561341.920024@anthem.concentric.net> >>>>> "AR" == Andy Robinson writes: AR> How many people here have actually created accounts for AR> themselves on SourceForge and tried to do stuff when logged in AR> - raise bugs and so on? Did it work for you? We ought to get AR> a few data points before making this the way Python is AR> managed. In general SF's web has been fine for me, although it is sometimes unavailable due to routing problems. I'm on a fairly reliable DSL line now, though I don't remember significantly more SF-blamable problems when I was on a 56K line. It's often quite slow to do CVS/SSH to SF. Sometimes I'll have to spin for several minutes just to do an update or a diff. That sucks. -Barry From fdrake at beopen.com Wed Jun 28 15:30:22 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Wed, 28 Jun 2000 09:30:22 -0400 (EDT) Subject: [Python-Dev] Sourceforge Interface Concerns In-Reply-To: References: <20000628025304.BB64A1CE0D@dinsdale.python.org> Message-ID: <14681.65006.782463.491824@cj42289-a.reston1.va.home.com> Andy Robinson writes: > I find the web interface totally unusable from IE5 and Netscape 4.XX, > working over 64k lines or dialup lines. Once one logs in via SSL, only > about one click in five ever returns a sensible page, and most just time out I've not been able to reproduce this behavior; the Web interface seems to work well with IE5 and Netscape 4.XX for me; the only problem I've had with IE5 is accessing a project's anonymous FTP area from the project page (IE5 just froze completely). Netscape didn't exhibit that problem for me and allowed perfectly reasonable use. Sometimes it seems a little slow, but I attribute that to load and the public-key crypto using SSH for CVS access; I understand that CVS doesn't have the most efficient wire-protocol either. I should note that I've mostly used it over T1 and cable modem links; I don't know that smaller pipes would make a huge difference though. I'd be more suspicious of trans-Atlantic linkage than anything else without having more information. Routing can do strange things, so you may be getting the worst-possible link for SourceForge while other things get better routes, but I wouldn't expect that to be terribly consistent. > How many people here have actually created accounts for themselves on > SourceForge and tried to do stuff when logged in - raise bugs and so on? > Did it work for you? We ought to get a few data points before making this > the way Python is managed. I've never had the kind of problems you describe. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From Vladimir.Marangozov at inrialpes.fr Wed Jun 28 15:58:26 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Wed, 28 Jun 2000 15:58:26 +0200 (CEST) Subject: [Python-Dev] Typo's In-Reply-To: <012f01bfe0e5$e3dce360$f2a6b5d4@hagrid> from "Fredrik Lundh" at Jun 28, 2000 11:47:32 AM Message-ID: <200006281358.PAA03368@python.inrialpes.fr> Fredrik Lundh wrote: > > > I located some typo's in the CVS. Here is a patch. > > wow! Wow, indeed. +1 I've uploaded this patch to SourceForge. > > just one nit: > > "inobstrusive" should be "unobtrusive" (not "inobtrusive") fixed in the patch. > > (and it's not clear if "descriptior" means "description" or > "descriptor"...) I examined the patched file - it's "description". > > > Warning: I'm a non-native English speaker. > > same here. same here :-) -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From guido at beopen.com Wed Jun 28 16:55:00 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 28 Jun 2000 09:55:00 -0500 Subject: [Python-Dev] add Demo/imputil/importers.py ? In-Reply-To: Your message of "Tue, 27 Jun 2000 18:46:15 MST." <20000627184615.A29590@lyra.org> References: <20000627184615.A29590@lyra.org> Message-ID: <200006281455.JAA01690@cj20424-a.reston1.va.home.com> > A while back, I pulled the "demo" importers out of imputil.py. I think those > should be added into Demo/imputil/. OK. Go ahead and create that directory and add the demo importers. > It would also be Goodness to include JimA's zipimporter. Where would that go? Same place I'd hope? Can you check that it works? We're dependent on you volunteers to maintain relatively non-core things like this -- I don't want to extend the feature freeze to Demo/, but I also don't have the time to keep the stuff there up to date. Maybe at some point the Demo directory should become a separate distribution, or just a collection of stuff on the web? --Guido van Rossum (home page: http://www.python.org/~guido/) From akuchlin at mems-exchange.org Wed Jun 28 16:07:22 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Wed, 28 Jun 2000 10:07:22 -0400 Subject: [Python-Dev] Sourceforge Interface Concerns In-Reply-To: <14681.65006.782463.491824@cj42289-a.reston1.va.home.com> References: <20000628025304.BB64A1CE0D@dinsdale.python.org> <14681.65006.782463.491824@cj42289-a.reston1.va.home.com> Message-ID: <20000628100722.A9063@kronos.cnri.reston.va.us> On Wed, Jun 28, 2000 at 09:30:22AM -0400, Fred L. Drake, Jr. wrote: > I should note that I've mostly used it over T1 and cable modem >links; I don't know that smaller pipes would make a huge difference >though. At home I have a 28.8 modem (never figured out how to upgrade it to 56K), and while CVS operations are fairly slow, there usually aren't any problems. The same goes for accessing the Web pages through SSL; somewhat slow, but reliable. --amk From gward at mems-exchange.org Wed Jun 28 16:18:12 2000 From: gward at mems-exchange.org (Greg Ward) Date: Wed, 28 Jun 2000 10:18:12 -0400 Subject: [Python-Dev] Python 1.6 planning In-Reply-To: ; from jeremy@beopen.com on Fri, Jun 23, 2000 at 06:01:19PM -0400 References: Message-ID: <20000628101812.A15643@ludwig.cnri.reston.va.us> On 23 June 2000, Jeremy Hylton said: > ldso_aix-- I still don't understand, but I didn't really try; Vladimir must > help This has been fixed in the Distutils. AFAIK it's still broken for Makefile.pre.in builds -- as long as the installed Makefile is fixed (not the actual installation location of ld_so_aix), then Distutils builds will continue to work. (Thanks to Rene Liebscher for providing the Distutils fix, and Vladimir for testing it.) Greg From gward at mems-exchange.org Wed Jun 28 16:29:02 2000 From: gward at mems-exchange.org (Greg Ward) Date: Wed, 28 Jun 2000 10:29:02 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils util.py,1.36,1.37 In-Reply-To: <20000624151824.A29590@lyra.org>; from gstein@lyra.org on Sat, Jun 24, 2000 at 03:18:24PM -0700 References: <200006242040.NAA28315@slayer.i.sourceforge.net> <20000624151824.A29590@lyra.org> Message-ID: <20000628102901.B15643@ludwig.cnri.reston.va.us> On 24 June 2000, Greg Stein said: > Would the "shlex" module be helpful here? It is in the standard library and > is (well?) maintained by ESR. It could help reduce the code inside > distutils. I looked at "shlex", but didn't like the fact that it 1) does character-by-character analysis of input, and 2) requires a file-like object. Just a performance concern, really. > [ I've always questioned the need for distutils' own "copy file" functions > and whatnot... seems there is a bit of duplication occurring... ] Two reasons for that: bugs in the standard library versions, and missing features in the standard library versions. I think the first argument goes away now that I've given up on 1.5.1 compatibility (shutil.py was really broken in 1.5.1), but the fact remains that the copy functions in shutil.py don't have a dry_run option, don't have a verbose option, don't have a preserve_times option, don't have a preserve_symlinks option, etc. All of these things are somewhere between useful and necessary. I'm always open for ideas on reducing the amount of code in the Distutils; it really is getting ridiculous. It cracked 10k lines of code+comments+doc this weekend -- about 5300 lines of straight code, I think. Anyways, the basic required functionality is now in place, so I'm open to clever refactoring/reduction/simplification patches. Greg From guido at beopen.com Wed Jun 28 17:41:26 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 28 Jun 2000 10:41:26 -0500 Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager In-Reply-To: Your message of "Wed, 28 Jun 2000 02:23:40 -0400." References: Message-ID: <200006281541.KAA02041@cj20424-a.reston1.va.home.com> > Since we (PythonLabs, last week) decided to continue using Jitterbug (on > python.org) for now, should the SF Bug Manager even be enabled? If it is > enabled, and we are using Jitterbug, then someone has to own reentering SF > bugs into the Jitterbug system. OK, I've disabled the SF bugs manager. There were two bugs submitted so far. I've assigned one to you (about os.listdir on Windows) and one to MAL (about -U vs. exec/eval). You two can take care of entering these into JB. You can still access the bugs database via this URL: https://sourceforge.net/bugs/?group_id=5470 --Guido van Rossum (home page: http://www.python.org/~guido/) From gward at mems-exchange.org Wed Jun 28 17:35:05 2000 From: gward at mems-exchange.org (Greg Ward) Date: Wed, 28 Jun 2000 11:35:05 -0400 Subject: [Python-Dev] OT: A Day in the Life of p5p In-Reply-To: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid>; from effbot@telia.com on Wed, Jun 28, 2000 at 01:07:24PM +0200 References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> Message-ID: <20000628113505.C15643@ludwig.cnri.reston.va.us> On 28 June 2000, Fredrik Lundh said: > http://prometheus.frii.com/~gnat/yapc/2000-p5p.txt > > unfortunately, his "What is it with those Python fucks anyway" talk > isn't posted... ;-) But the "Conclusion" of his "Lies We Tell" talk: Perl sucks. Use Python. Presumably tongue-in-cheek, but you never know... Greg From trentm at activestate.com Wed Jun 28 18:53:19 2000 From: trentm at activestate.com (Trent Mick) Date: Wed, 28 Jun 2000 09:53:19 -0700 Subject: [Python-Dev] back up & running In-Reply-To: <200006281222.OAA03150@python.inrialpes.fr> References: <14681.56997.50955.892954@cj42289-a.reston1.va.home.com> <200006281222.OAA03150@python.inrialpes.fr> Message-ID: <20000628095319.C14129@activestate.com> On Wed, Jun 28, 2000 at 02:22:56PM +0200, Vladimir Marangozov wrote: > Fred L. Drake, Jr. wrote: > > > > My mega-laptop got fixed faster than I'd expected, so I'm back up to > > doing useful work. My top priorities are handling patches and going > > back through my email to find all the documentation patches that have > > sat idle for too long. > > Excellent! > > Finally someone who cares to checkin patches. I've been disappointed > to see that the June 30 intent-date was announced, but people keep > chewing-gumming about SourceForge caveats while the patches backlog > grows and the number of closed patches stays invariably to 3, of which > one is a test! > You can count me as one of the significatn bottlenecks here. Tim and Guido have accepted some of my patches, I just have to check them in. Real Soon Now (tm). Trent Mick (also tm) -- Trent Mick trentm at activestate.com From mal at lemburg.com Wed Jun 28 18:57:35 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 28 Jun 2000 18:57:35 +0200 Subject: [Python-Dev] Named Unicode Characters Message-ID: <395A2E7F.A1DDEC35@lemburg.com> I've just checked in the patches by Bill Tutt, which add support for \N{NAMED UNICODE CHARACTERS}. The new escape code is available per default in the standard unicode-escape codec. The (big) hash table needed to drive the mapping is loaded on demand to reduce memory overhead. The patch also includes a new tool called perfecthash which is used to generate the hash table (and function) from names to ordinals. I'm sure this can be of use in other areas too... but it needs some more work to become more generic (currently you have to edit the source code to generate other mapping modules). Thanks to Bill Tutt -- this is great work ! -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From paul at prescod.net Wed Jun 28 19:11:19 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 28 Jun 2000 10:11:19 -0700 Subject: [Python-Dev] OT: A Day in the Life of p5p References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> Message-ID: <395A31B7.911D9BC2@prescod.net> Fredrik Lundh wrote: > > http://prometheus.frii.com/~gnat/yapc/2000-p5p.txt How about this one: http://gisle.aas.no/perl/illguts/ Just thank your lucky stars... -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From paul at prescod.net Wed Jun 28 19:16:45 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 28 Jun 2000 10:16:45 -0700 Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager References: Message-ID: <395A32FD.D3C58B23@prescod.net> I don't want to be paranoid, but are we putting any important information into SourceForge that we are not backing up elsewhere? I mean okay, we've all got CVS dumps, but if it went away (DOJ antitrust suit...) would we have backups of our patches, bugs, wish lists and so forth? I hope that's a criteria in deciding what services to move to SourceForge. I am in the business of preserving investments in data and of telling customers to avoid software that does not keep them in complete control of their data. SF makes me nervous that way.... -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From mal at lemburg.com Wed Jun 28 19:22:40 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 28 Jun 2000 19:22:40 +0200 Subject: [Python-Dev] Checkin Utility Message-ID: <395A3460.3FF013F0@lemburg.com> I thought you might have some use for the attached utility. It's a simple script which helps with checking in patches which I've been using for a while now. It also hides the CVS options and parameters away as far as possible, so that CVS knowledge is not really needed to complete the task. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ -------------- next part -------------- A non-text attachment was scrubbed... Name: checkin.py Type: text/python Size: 8070 bytes Desc: not available URL: From esr at thyrsus.com Wed Jun 28 19:38:05 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 28 Jun 2000 13:38:05 -0400 Subject: [Python-Dev] OT: A Day in the Life of p5p In-Reply-To: <395A31B7.911D9BC2@prescod.net>; from paul@prescod.net on Wed, Jun 28, 2000 at 10:11:19AM -0700 References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> <395A31B7.911D9BC2@prescod.net> Message-ID: <20000628133805.D20855@thyrsus.com> Paul Prescod : > http://gisle.aas.no/perl/illguts/ > > Just thank your lucky stars... Ghods. Reading that just about ruined my lunch. -- Eric S. Raymond "The power to tax involves the power to destroy;...the power to destroy may defeat and render useless the power to create...." -- Chief Justice John Marshall, 1819. From paul at prescod.net Wed Jun 28 19:27:54 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 28 Jun 2000 10:27:54 -0700 Subject: [Python-Dev] Text about cycle GC References: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com> Message-ID: <395A359A.2CF0CA70@prescod.net> "A.M. Kuchling" wrote: > > ... > > An experimental step has been made toward fixing this problem. When > compiling Python, the -with-cycle-gc (XXX correct option flag?) option > can be specified. This causes a cycle detection algorithm to be > periodically executed, which looks for inaccessible cycles and deletes > the objects involved. I propose (without any investigation into the difficulty of implementation) that import cyclicgc should turn on the -with-cycle-gc flag. Then you could do a import cyclicgc import someDOM And not worry about cycles. If it's too slow, you remove the line and take responsibility for cycle checking. The important thing is that you don't have to tell YOUR USERS to turn on GC in order for your code to work. I think that this model will get more people actively using (and depending upon!) GC and thus give us a better idea about usage patterns, stability and performance. This is especially important in the beta period when we are trying to shake out bugs. Really, this comes back to Greg's point that we should not have incompatible sub-languages running around. A module depends on the feature or it doesn't. The end-user should not be responsible for knowing whether any module in a whole program needs GC. -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From paul at prescod.net Wed Jun 28 19:34:35 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 28 Jun 2000 10:34:35 -0700 Subject: [Python-Dev] OT: A Day in the Life of p5p References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> <395A31B7.911D9BC2@prescod.net> <20000628133805.D20855@thyrsus.com> Message-ID: <395A372B.34E15A62@prescod.net> "Eric S. Raymond" wrote: > > Ghods. Reading that just about ruined my lunch. You read it? Eric, I was just kidding! Actually, my theory is that the whole thing is a big, extended, April Fools joke. Not the document. The language. (rimshot) SvOOK-vs-SvIV-and-SvNV-indeed-ly 'yrs -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From gmcm at hypernet.com Wed Jun 28 19:37:07 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Wed, 28 Jun 2000 13:37:07 -0400 Subject: [Python-Dev] OT: A Day in the Life of p5p In-Reply-To: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> Message-ID: <1249908601-39717068@hypernet.com> > http://prometheus.frii.com/~gnat/yapc/2000-p5p.txt What I noticed is that Tim is mentioned in every other paragraph. Where-does-he-find-the-time?-ly y'rs - Gordon From jeremy at beopen.com Wed Jun 28 19:41:50 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Wed, 28 Jun 2000 13:41:50 -0400 (EDT) Subject: [Python-Dev] OT: A Day in the Life of p5p In-Reply-To: <395A31B7.911D9BC2@prescod.net> References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> <395A31B7.911D9BC2@prescod.net> Message-ID: <14682.14558.380773.307392@bitdiddle.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> Fredrik Lundh wrote: >> http://prometheus.frii.com/~gnat/yapc/2000-p5p.txt PP> How about this one: PP> http://gisle.aas.no/perl/illguts/ PP> Just thank your lucky stars... What beautiful diagrams! It almost makes me wish Python was complicated enough to require such pretty pictures. Jeremy From guido at beopen.com Wed Jun 28 20:41:48 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 28 Jun 2000 13:41:48 -0500 Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager In-Reply-To: Your message of "Wed, 28 Jun 2000 10:16:45 MST." <395A32FD.D3C58B23@prescod.net> References: <395A32FD.D3C58B23@prescod.net> Message-ID: <200006281841.NAA03154@cj20424-a.reston1.va.home.com> [PP] > I don't want to be paranoid, but are we putting any important > information into SourceForge that we are not backing up elsewhere? I > mean okay, we've all got CVS dumps, but if it went away (DOJ antitrust > suit...) would we have backups of our patches, bugs, wish lists and so > forth? I hope that's a criteria in deciding what services to move to > SourceForge. I am in the business of preserving investments in data and > of telling customers to avoid software that does not keep them in > complete control of their data. SF makes me nervous that way.... Good point. SF has a way to get a nightly snapshot of the CVS tree. We should suggest that they provide snapshots (in XML of course!) of the bugs database too. Note that I have no bandwidth left to communicate to SF folks so this is up to the user community. (I'm also very optimistic and trusting in nature. :-) --Guido van Rossum (home page: http://www.python.org/~guido/) From jeremy at beopen.com Wed Jun 28 19:49:32 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Wed, 28 Jun 2000 13:49:32 -0400 (EDT) Subject: [Python-Dev] Text about cycle GC In-Reply-To: <395A359A.2CF0CA70@prescod.net> References: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com> <395A359A.2CF0CA70@prescod.net> Message-ID: <14682.15020.589514.702145@bitdiddle.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> "A.M. Kuchling" wrote: >> ... >> >> An experimental step has been made toward fixing this >> problem. When compiling Python, the -with-cycle-gc (XXX correct >> option flag?) option can be specified. This causes a cycle >> detection algorithm to be periodically executed, which looks for >> inaccessible cycles and deletes the objects involved. PP> I propose (without any investigation into the difficulty of PP> implementation) that PP> import cyclicgc PP> should turn on the -with-cycle-gc flag. The -with-cycle-gc flag is an option to configure when you build Python. It can't be turned on or off at runtime. We hope that everyone will build with the -with-cycle-gc flag during the beta testing, but we don't expect to have enough confidence in it by final release to make it anything other than an experimental option. Jeremy From esr at thyrsus.com Wed Jun 28 20:02:37 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 28 Jun 2000 14:02:37 -0400 Subject: [Python-Dev] OT: A Day in the Life of p5p In-Reply-To: <395A372B.34E15A62@prescod.net>; from paul@prescod.net on Wed, Jun 28, 2000 at 10:34:35AM -0700 References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> <395A31B7.911D9BC2@prescod.net> <20000628133805.D20855@thyrsus.com> <395A372B.34E15A62@prescod.net> Message-ID: <20000628140237.A21043@thyrsus.com> Paul Prescod : > "Eric S. Raymond" wrote: > > > > Ghods. Reading that just about ruined my lunch. > > You read it? Eric, I was just kidding! Yes, I read it. Un-fscking-believable. I knew Perl was complicated and ugly on the inside, but the full horror had not obtruded itself on me before now. If I'm any judge, that's an implementation on the brink of collapsing under its own weight. -- Eric S. Raymond Non-cooperation with evil is as much a duty as cooperation with good. -- Mohandas Gandhi From paul at prescod.net Wed Jun 28 19:53:16 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 28 Jun 2000 10:53:16 -0700 Subject: [Python-Dev] OT: A Day in the Life of p5p References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> <395A31B7.911D9BC2@prescod.net> <14682.14558.380773.307392@bitdiddle.concentric.net> Message-ID: <395A3B8B.B6117DA1@prescod.net> Note that the document doesn't yet cover the regular expression engine or the "PerlInterpreter". I can't think of a disclaimer that doesn't sound like it is tongue in cheek but I do feel bad about beating up on a design which, in its own way, has a certain kind of quality (just not one I happen to prefer). When you optimize the snot out of things they tend to start looking ugly. Perl runs faster than Python. That's probably not a coincidence. Jeremy Hylton wrote: > > What beautiful diagrams! It almost makes me wish Python was > complicated enough to require such pretty pictures. To be fair, our internals documentation needs some work. I'll bet there are a lot of people in comp.lang.python that would be interested in a project like that or another one, such as adding a full warning infrastructure to Python. I wonder how we could do a Software Carpentry like deal (no money) where we get people to submit designs and ideas and then "award" the job to someone. They could do it for reputational capital and an opportunity to join "the team" (of CVS committers, PythonDev denizens etc.). It's probably better to give people ideas rather than have them implement random things that we will need to turn down. Like stackless. -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From paul at prescod.net Wed Jun 28 20:09:38 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 28 Jun 2000 11:09:38 -0700 Subject: [Python-Dev] Text about cycle GC References: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com> <395A359A.2CF0CA70@prescod.net> <14682.15020.589514.702145@bitdiddle.concentric.net> Message-ID: <395A3F62.EA1E8B89@prescod.net> Jeremy Hylton wrote: > > .... > > The -with-cycle-gc flag is an option to configure when you build > Python. It can't be turned on or off at runtime. Doh! Sorry. Andrew's text does say that but I didn't read carefully and testing it with my stuff hasn't floated to the top yet (because when I looked into it, I realized I'd have to recompile...double doh!) Compiling is really slow on my "transitional" computer. I'm a little disappointed that it will be so difficult for people to test with GC on, but I'm not going to claim that there is some easy way to make it a runtime option because I haven't looked at it at all. There probably isn't. -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From nascheme at enme.ucalgary.ca Wed Jun 28 20:27:25 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Wed, 28 Jun 2000 12:27:25 -0600 Subject: [Python-Dev] Text about cycle GC In-Reply-To: <395A3F62.EA1E8B89@prescod.net>; from paul@prescod.net on Wed, Jun 28, 2000 at 11:09:38AM -0700 References: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com> <395A359A.2CF0CA70@prescod.net> <14682.15020.589514.702145@bitdiddle.concentric.net> <395A3F62.EA1E8B89@prescod.net> Message-ID: <20000628122725.A13473@acs.ucalgary.ca> On Wed, Jun 28, 2000 at 11:09:38AM -0700, Paul Prescod wrote: > I'm a little disappointed that it will be so difficult for people to > test with GC on, but I'm not going to claim that there is some easy way > to make it a runtime option because I haven't looked at it at all. There > probably isn't. There isn't. With an interpreter compiled --with-cycle-gc you can turn off the collection with gc.set_threshold(0) but that's not the same thing. Neil From bwarsaw at beopen.com Wed Jun 28 20:33:23 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 28 Jun 2000 14:33:23 -0400 (EDT) Subject: [Python-Dev] OT: A Day in the Life of p5p References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> <395A31B7.911D9BC2@prescod.net> <20000628133805.D20855@thyrsus.com> <395A372B.34E15A62@prescod.net> <20000628140237.A21043@thyrsus.com> Message-ID: <14682.17651.552666.318592@anthem.concentric.net> >>>>> "ESR" == Eric S Raymond writes: ESR> Yes, I read it. Un-fscking-believable. I knew Perl was ESR> complicated and ugly on the inside, but the full horror had ESR> not obtruded itself on me before now. If I'm any judge, ESR> that's an implementation on the brink of collapsing under its ESR> own weight. And of course, we'll be right there to pick up the pieces. :) From guido at beopen.com Wed Jun 28 21:43:06 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 28 Jun 2000 14:43:06 -0500 Subject: [Python-Dev] Python 1.6 schedule Message-ID: <200006281943.OAA03414@cj20424-a.reston1.va.home.com> I've updated the 1.6 page on python.org (http://www.python.org/1.6/) to include the latest schedule for 1.6. I've also included a link to Andrew's "what's new" article. Here's the new schedule in text form: July 1: beta 1; feature freeze. July 14: beta 2, in time for the O'Reilly Open Source Software Convention. August 1: release candidate. August 15: final release. I'm happy with how the patches are coming along today (/F even submitted the SRE patch...). We may actually have a release party Saturday! --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at beopen.com Wed Jun 28 22:27:43 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 28 Jun 2000 15:27:43 -0500 Subject: [Python-Dev] Named Unicode Characters In-Reply-To: Your message of "Wed, 28 Jun 2000 18:57:35 +0200." <395A2E7F.A1DDEC35@lemburg.com> References: <395A2E7F.A1DDEC35@lemburg.com> Message-ID: <200006282027.PAA04607@cj20424-a.reston1.va.home.com> > I've just checked in the patches by Bill Tutt, which add > support for \N{NAMED UNICODE CHARACTERS}. The new escape > code is available per default in the standard unicode-escape > codec. The (big) hash table needed to drive the mapping > is loaded on demand to reduce memory overhead. > > The patch also includes a new tool called perfecthash which > is used to generate the hash table (and function) from > names to ordinals. I'm sure this can be of use in other > areas too... but it needs some more work to become more > generic (currently you have to edit the source code to generate > other mapping modules). > > Thanks to Bill Tutt -- this is great work ! Thanks Bill and Marc-Andre! I've closed the patch in SF now. --Guido van Rossum (home page: http://www.python.org/~guido/) From tim_one at email.msn.com Wed Jun 28 21:40:18 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 28 Jun 2000 15:40:18 -0400 Subject: [Python-Dev] back up & running In-Reply-To: <20000628095319.C14129@activestate.com> Message-ID: [Vladimir Marangozov] > ... > I've been disappointed to see that the June 30 intent-date was > announced, but people keep chewing-gumming about SourceForge > caveats while the patches backlog grows and the number of closed > patches stays invariably to 3, of which one is a test! Absolutely on-target, Vladimir! The current state of our world is embarrassing. Someday when the bosses aren't listening, I'll explain to you how it got this way <0.9 wink>. [Trent Mick] > You can count me as one of the significant bottlenecks here. Tim and > Guido have accepted some of my patches, I just have to check them in. > Real Soon Now (tm). Trent, you are *not* a bottleneck! You've cooperated with the process (or lack thereof) every step of the way, and it hasn't even been 12 hours since I accepted some of your patches. And the bulk of them are still on my plate to review. I don't think we have an actual bottleneck now, but we do have a large backlog to work off, and people with too many things that need to be done. perseverance-and-patience-will-probably-work-better-than-their-opposites-ly y'rs - tim From gstein at lyra.org Wed Jun 28 21:46:06 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 28 Jun 2000 12:46:06 -0700 Subject: [Python-Dev] add Demo/imputil/importers.py ? In-Reply-To: <200006281455.JAA01690@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Wed, Jun 28, 2000 at 09:55:00AM -0500 References: <20000627184615.A29590@lyra.org> <200006281455.JAA01690@cj20424-a.reston1.va.home.com> Message-ID: <20000628124606.K29590@lyra.org> On Wed, Jun 28, 2000 at 09:55:00AM -0500, Guido van Rossum wrote: > > A while back, I pulled the "demo" importers out of imputil.py. I think those > > should be added into Demo/imputil/. > > OK. Go ahead and create that directory and add the demo importers. Will do. > > It would also be Goodness to include JimA's zipimporter. Where would that go? > > Same place I'd hope? Can you check that it works? Yup and yup. > We're dependent on you volunteers to maintain relatively non-core > things like this -- I don't want to extend the feature freeze to > Demo/, but I also don't have the time to keep the stuff there up to > date. Not a problem, and I had figured on being the "point man" on keeping it working. My query here was more along the lines of "is Demo/imputil/ a good idea? If so, then I'll run with it." You said "yes", so I'll go put on my shoes. > Maybe at some point the Demo directory should become a separate > distribution, or just a collection of stuff on the web? I believe a separate distribution. Unpacking the bugger to the main web site would also be a good option, but that would be a second priority. I'd throw Tools into the same thing. As a separate distro, you can have a faster release cycle. ... you could release Idle updates easily and distinctly from the Python core. Note: by a "collection on the web", the only view that I have, is that the collection exists on the python.org web site. Distributed pieces "here and there" is handled by the Vaults (and similar). The Demo/ directory is a bit more newbie-ish, so (IMO) it ought to get bundled up somehow since the Vaults are a bit daunting to find "example of embedding". If the bundle also happens to reside in an obvious area on python.org? Great. Cheers, -g -- Greg Stein, http://www.lyra.org/ From tim_one at email.msn.com Wed Jun 28 21:54:42 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 28 Jun 2000 15:54:42 -0400 Subject: [Python-Dev] OT: A Day in the Life of p5p In-Reply-To: <395A31B7.911D9BC2@prescod.net> Message-ID: [Paul Prescod] > How about this one: > > http://gisle.aas.no/perl/illguts/ > Just thank your lucky stars... Ack, don't get me started -- well, I'd love to, but have real work to do. I've posted about that before. I'm not infrequently amazed that they manage to keep Perl running at all. The amazing thing about the PerlGuts doc above is that it was apparently reverse-engineered by staring at Perl's implementation code. You can't find any of it explained in the source! either-those-guys-are-nuts-or-they're-a-*whole*-lot-smarter- than-us-and-i-know-which-of-those-i'm-more-likely-to- believe-ly y'rs - tim From guido at beopen.com Wed Jun 28 22:59:46 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 28 Jun 2000 15:59:46 -0500 Subject: [Python-Dev] Text about cycle GC In-Reply-To: Your message of "Wed, 28 Jun 2000 12:27:25 CST." <20000628122725.A13473@acs.ucalgary.ca> References: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com> <395A359A.2CF0CA70@prescod.net> <14682.15020.589514.702145@bitdiddle.concentric.net> <395A3F62.EA1E8B89@prescod.net> <20000628122725.A13473@acs.ucalgary.ca> Message-ID: <200006282059.PAA04852@cj20424-a.reston1.va.home.com> > On Wed, Jun 28, 2000 at 11:09:38AM -0700, Paul Prescod wrote: > > I'm a little disappointed that it will be so difficult for people to > > test with GC on, but I'm not going to claim that there is some easy way > > to make it a runtime option because I haven't looked at it at all. There > > probably isn't. > > There isn't. With an interpreter compiled --with-cycle-gc you can > turn off the collection with gc.set_threshold(0) but that's not > the same thing. > > Neil I wonder if we should turn this option *on* during beta testing? That way we gather a lot more experience with its use! Maybe nobody complains and we can leave it on in the final release... --Guido van Rossum (home page: http://www.python.org/~guido/) From akuchlin at mems-exchange.org Wed Jun 28 22:10:28 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Wed, 28 Jun 2000 16:10:28 -0400 Subject: [Python-Dev] OT: A Day in the Life of p5p In-Reply-To: <395A3B8B.B6117DA1@prescod.net> References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> <395A31B7.911D9BC2@prescod.net> <14682.14558.380773.307392@bitdiddle.concentric.net> <395A3B8B.B6117DA1@prescod.net> Message-ID: <20000628161028.C23352@kronos.cnri.reston.va.us> On Wed, Jun 28, 2000 at 10:53:16AM -0700, Paul Prescod wrote: >Note that the document doesn't yet cover the regular expression engine >or the "PerlInterpreter". The regex engine's pretty hard to read, mostly because comments are infrequent and not very helpful, and disentangling it from the rest of Perl would require a skilled wizard. (PCRE, if slower, is at least much clearer and easier to understand, though the compile() function is pretty ugly.) A while ago I saw a p5p post from Ilya Zakharevich who did most of the recent regex hacking; he draw attention to one flag variable in the code and said basically "I don't know what this flag means; I think it's some sort of UTF-8 setting, but Larry didn't explain it." >I can't think of a disclaimer that doesn't sound like it is tongue in >cheek but I do feel bad about beating up on a design which, in its own >way, has a certain kind of quality (just not one I happen to prefer). Agreed; it could be made much simpler, but maybe at a performance cost. (Though performance is tricky, and maybe the extra work costs more than it saves.) For example, note the flag bits in SvNULL, which have values like GMAGICAL. You could imagine a Python implementation that added flag bits to every object, and set a bit if there was a __getattr__ method defined; code could then do 'if (obj->flags & GMAGICAL) ...' instead of the more complicated 'if (PyObject_HasAttrString(obj, "__getattr__")'. It would be interesting to know if Topaz, Chip Salzenberg's experimental C++ implementation, preserves this complexity or aims to cut it away. The use of several levels of C structs is also reminiscent of the way you do OO in C, as in X toolkits. You can also see the importance of text processing in the SvPVBM type, for attaching a Boyer-Moore related table to a string and speeding up regex searches. --amk From tim_one at email.msn.com Wed Jun 28 22:15:34 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 28 Jun 2000 16:15:34 -0400 Subject: [Python-Dev] OT: A Day in the Life of p5p In-Reply-To: <395A3B8B.B6117DA1@prescod.net> Message-ID: [Paul Prescod] > ... > When you optimize the snot out of things they tend to start looking > ugly. Perl runs faster than Python. That's probably not a coincidence. More, IMO it's not even true. I can't make time for this now, but on several occasions I've coded the same algorithm in idiomatic Perl and Python, and Python was invariably faster (not talking orders of magnitude, but 10-40%). The catch is that I know something about both implementations, and avoided the sweet spots in both. Perl gets enormous bang out of its line-at-a-time text file input "cheating", and its integrated regexps. Avoid those, and it's generally *slower* in my experience, which is perfectly consistent with the relative messiness of its implementation (all those magic flags aren't passive, they need runtime conditionals to use! Perl can't even inline its refcount manipulations because they're so complicated due to the flags). Against that, line-at-a-time text file input in particular is something that every newbie bumps into at once, and Perl does have a monster advantage there (at least 2x faster, probably closer to 3 on most platforms). Perl doesn't really look like it was designed to "be fast" in general -- it looks like it was designed to be supernaturally fast in specific situations. Best I've been able to tell, that's how it *acts*, too. I'm keen to add comparable (but limited) internal warts to Python, but for *general* speedup ideas we'll be much better off looking to, e.g., Dylan and Squeak. all-that-said-python-is-fast-enough-for-me-already!-ly y'rs - tim From DavidA at ActiveState.com Wed Jun 28 22:17:46 2000 From: DavidA at ActiveState.com (David Ascher) Date: Wed, 28 Jun 2000 13:17:46 -0700 Subject: [Python-Dev] OT: A Day in the Life of p5p In-Reply-To: Message-ID: > either-those-guys-are-nuts-or-they're-a-*whole*-lot-smarter- > than-us-and-i-know-which-of-those-i'm-more-likely-to- > believe-ly y'rs - tim I was sitting next to Gisle (the author of said document) when he started to work on the Perl methods work for Zope. Within a day, starting w/ not knowing anything about Python, he had Perl embedded in Python. It says much about the cleanliness of Python's design and the quality of its documentation that Gisle could do that. It also says a lot about Gisle, as does the perlguts document Not saying anything about anyone being nuts, especially when responding to someone who talks about his in public. --david From pingster at ilm.com Wed Jun 28 22:22:15 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Wed, 28 Jun 2000 13:22:15 -0700 (PDT) Subject: [Python-Dev] OT: A Day in the Life of p5p In-Reply-To: <20000628161028.C23352@kronos.cnri.reston.va.us> Message-ID: On Wed, 28 Jun 2000, Andrew Kuchling wrote: > You could imagine a Python implementation that added flag > bits to every object, and set a bit if there was a __getattr__ method > defined; code could then do 'if (obj->flags & GMAGICAL) ...' instead > of the more complicated 'if (PyObject_HasAttrString(obj, > "__getattr__")'. That looks like a reasonable sort of optimization to me, though as far as i can tell it looks like that optimization has already been done: in PyClass_New(bases, dict, name): [...] op->cl_getattr = class_lookup(op, getattrstr, &dummy); [...] in instance_getattr(inst, name): if (res == NULL && (func = inst->in_class->cl_getattr) != NULL) { [...special __getattr__ handling...] } In general, optimizations of the form "add a flag to avoid a frequent expensive test" seem okay to me, as long they are a demonstrable win and the flag can be given a clear, simple name. -- ?!ng "To be human is to continually change. Your desire to remain what you are is what ultimately limits you." -- The Puppet Master, Ghost in the Shell From akuchlin at mems-exchange.org Wed Jun 28 22:25:54 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Wed, 28 Jun 2000 16:25:54 -0400 Subject: [Python-Dev] OT: A Day in the Life of p5p In-Reply-To: References: <20000628161028.C23352@kronos.cnri.reston.va.us> Message-ID: <20000628162554.E23352@kronos.cnri.reston.va.us> On Wed, Jun 28, 2000 at 01:22:15PM -0700, Ka-Ping Yee wrote: >That looks like a reasonable sort of optimization to me, though >as far as i can tell it looks like that optimization has already >been done: Damn time machine again... --amk From tim_one at email.msn.com Wed Jun 28 22:31:58 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 28 Jun 2000 16:31:58 -0400 Subject: SourceForge patch notifications (was RE: [Python-Dev] ANN: Release schedule) In-Reply-To: <20000628090230.A14129@activestate.com> Message-ID: [Trent Mick] > ... > BTW I have answered a couple a questions on my patches. Does > the person to whom the patch is assigned get an update notification? Trent & I investigated this offline: he added a comment to one of his patches to which I am assigned. I did indeed get prompt email notification, although as everyone has noticed by now, there's no indication from SF about *why* I was getting notified; just: From: noreply at sourceforge.net [mailto:noreply at sourceforge.net] Sent: Wednesday, June 28, 2000 12:01 PM To: tmick at mail.com; tim_one at email.msn.com Subject: [Patch #100513] fix posixmodule for 64-bit systems (mainly Win64) Patch #100513 has been updated. Visit SourceForge.net for more info. http://sourceforge.net/patch/?func=detailpatch&patch_id=100513&group_id=5470 So the outcome could have been worse . a-new-criterion-for-excellence-ly y'rs - tim From effbot at telia.com Wed Jun 28 22:42:56 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 28 Jun 2000 22:42:56 +0200 Subject: [Python-Dev] OT: A Day in the Life of p5p References: Message-ID: <033a01bfe141$71b0cfc0$f2a6b5d4@hagrid> tim wrote: > Against that, line-at-a-time text file input in particular is something that > every newbie bumps into at once, and Perl does have a monster advantage > there (at least 2x faster, probably closer to 3 on most platforms). and 2-3x is what you get if you replace readline with readlines, as described in this note: http://w1.132.telia.com/~u13208596/notes/readline-performance.htm it would be very nice if the file object could do something similar internally (only in text mode, perhaps). maybe in 1.7? (as I've mentioned earlier, SRE+faster IO can result in a 10x speedup for a straightforward while/readline/match loop...) From jack at oratrix.nl Wed Jun 28 22:58:27 2000 From: jack at oratrix.nl (Jack Jansen) Date: Wed, 28 Jun 2000 22:58:27 +0200 Subject: [Python-Dev] ucnhash module Message-ID: <20000628205832.C3234E2673@oratrix.oratrix.nl> I'm a bit worried about the ucnhash module and its huge size. I didn't follow the discussion closely at the time, because I thought I could always exclude it from the Pythons without dynamic linking, but now it seems that if i don't include it test_unicode doesn't run anymore. Is this a problem with test_unicode, or should I consider ucnhash a mandatory module? (BTW: there were also a couple of bugs in the module, include <> in stead of include "", and static in stead of staticforward declarations, I'll submit patches for those shortly). -- 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/ ++++ From gstein at lyra.org Wed Jun 28 23:03:42 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 28 Jun 2000 14:03:42 -0700 Subject: [Python-Dev] OT: A Day in the Life of p5p In-Reply-To: <033a01bfe141$71b0cfc0$f2a6b5d4@hagrid>; from effbot@telia.com on Wed, Jun 28, 2000 at 10:42:56PM +0200 References: <033a01bfe141$71b0cfc0$f2a6b5d4@hagrid> Message-ID: <20000628140342.Q29590@lyra.org> On Wed, Jun 28, 2000 at 10:42:56PM +0200, Fredrik Lundh wrote: > tim wrote: > > Against that, line-at-a-time text file input in particular is something that > > every newbie bumps into at once, and Perl does have a monster advantage > > there (at least 2x faster, probably closer to 3 on most platforms). > > and 2-3x is what you get if you replace readline with readlines, > as described in this note: > http://w1.132.telia.com/~u13208596/notes/readline-performance.htm > > it would be very nice if the file object could do something similar > internally (only in text mode, perhaps). maybe in 1.7? That could be troublesome. It should only be done if the file is seekable so that you can rewind. If a readline() on (say) a socket moved you *past* the newline, then you could be in big trouble. Or what happens in said socket is blocking? etc. Now... please don't start a thread about this now. Wait for post 1.6. Maybe I'm totally off, and some smart guy here can say so. But it just doesn't matter, so I'd rather not have to read a whole thread on the stuff :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Wed Jun 28 23:14:41 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 28 Jun 2000 14:14:41 -0700 Subject: [Python-Dev] PyOS_AfterFork() (was: CVS: python/dist/src/Doc/api api.tex,1.68,1.69) In-Reply-To: <200006281553.IAA11238@slayer.i.sourceforge.net>; from fdrake@users.sourceforge.net on Wed, Jun 28, 2000 at 08:53:17AM -0700 References: <200006281553.IAA11238@slayer.i.sourceforge.net> Message-ID: <20000628141441.R29590@lyra.org> Woah. Never knew this was in Python. It is quite interesting, as there is a very similar concept within Apache. In that model, you register a cleanup function for the particular data that needs to be cleaned post-fork. After the fork occurs, the cleanups are called. In essence, Python would register PyOS_AfterFork. Of course, any schmoe can call fork() and avoid the cleanups, so it bungs up the whole scheme. In Apache, the "only" way to fork is to call an APR function, which guarantees the cleanups. Cheers, -g On Wed, Jun 28, 2000 at 08:53:17AM -0700, Fred L. Drake wrote: > Update of /cvsroot/python/python/dist/src/Doc/api > In directory slayer.i.sourceforge.net:/tmp/cvs-serv11228/api > > Modified Files: > api.tex > Log Message: > > Added documentation for PyOS_AfterFork(). > > > Index: api.tex > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Doc/api/api.tex,v > retrieving revision 1.68 > retrieving revision 1.69 > diff -C2 -r1.68 -r1.69 > *** api.tex 2000/06/18 05:21:21 1.68 > --- api.tex 2000/06/28 15:53:13 1.69 > *************** > *** 1034,1037 **** > --- 1034,1044 ---- > \end{cfuncdesc} > > + \begin{cfuncdesc}{void}{PyOS_AfterFork}{} > + Function to update some internal state after a process fork; this > + should be called in the new process if the Python interpreter will > + continue to be used. If a new executable is loaded into the new > + process, this function does not need to be called. > + \end{cfuncdesc} > + > > \section{Process Control \label{processControl}} > > > _______________________________________________ > Python-checkins mailing list > Python-checkins at python.org > http://www.python.org/mailman/listinfo/python-checkins -- Greg Stein, http://www.lyra.org/ From effbot at telia.com Wed Jun 28 23:19:36 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 28 Jun 2000 23:19:36 +0200 Subject: [Python-Dev] exceptions trouble Message-ID: <036201bfe146$90b7fb00$f2a6b5d4@hagrid> import traceback try: raise SyntaxError, "argument" except: traceback.print_exc() prints: Traceback (most recent call last): File "test.py", line 3, in ? raise SyntaxError, "argument" Traceback (most recent call last): File "test.py", line 5, in ? traceback.print_exc() File "C:\py16\lib\traceback.py", line 182, in print_exc print_exception(etype, value, tb, limit, file) File "C:\py16\lib\traceback.py", line 110, in print_exception lines = format_exception_only(etype, value) File "C:\py16\lib\traceback.py", line 169, in format_exception_only list.append('%s: %s\n' % (str(stype), str(value))) SystemError: new style getargs format but argument is not a tuple not really what I expected. am I out of sync, or have I stumbled upon a bug in the new exceptions code? From tim_one at email.msn.com Wed Jun 28 23:21:52 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 28 Jun 2000 17:21:52 -0400 Subject: [Python-Dev] OT: A Day in the Life of p5p In-Reply-To: <20000628140342.Q29590@lyra.org> Message-ID: [Greg Stein] > ... > Now... please don't start a thread about this now. Wait for post > 1.6. Amen. > Maybe I'm totally off, and some smart guy here can say so. But it > just doesn't matter, so I'd rather not have to read a whole thread > on the stuff :-) If you change your mind, you can go back in the archives and read at least two old threads on the topic -- it's not like there's actually anything new here . From akuchlin at mems-exchange.org Wed Jun 28 23:30:38 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Wed, 28 Jun 2000 17:30:38 -0400 Subject: [Python-Dev] exceptions trouble In-Reply-To: <036201bfe146$90b7fb00$f2a6b5d4@hagrid> References: <036201bfe146$90b7fb00$f2a6b5d4@hagrid> Message-ID: <20000628173038.B28659@kronos.cnri.reston.va.us> On Wed, Jun 28, 2000 at 11:19:36PM +0200, Fredrik Lundh wrote: >SystemError: new style getargs format but argument is not a tuple >not really what I expected. am I out of sync, or have I >stumbled upon a bug in the new exceptions code? It works fine in my current copy of the CVS tree, and I think I rebuilt everything this morning. --amk From fdrake at beopen.com Wed Jun 28 23:32:36 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Wed, 28 Jun 2000 17:32:36 -0400 (EDT) Subject: [Python-Dev] PyOS_AfterFork() (was: CVS: python/dist/src/Doc/api api.tex,1.68,1.69) In-Reply-To: <20000628141441.R29590@lyra.org> References: <200006281553.IAA11238@slayer.i.sourceforge.net> <20000628141441.R29590@lyra.org> Message-ID: <14682.28404.125379.249287@cj42289-a.reston1.va.home.com> Greg Stein writes: > Woah. Never knew this was in Python. I didn't either, until I read a patch that used it. That's one way to keep the documentation up to date! ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From gstein at lyra.org Wed Jun 28 23:48:00 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 28 Jun 2000 14:48:00 -0700 Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163) In-Reply-To: <200006282112.OAA03095@slayer.i.sourceforge.net>; from gvanrossum@users.sourceforge.net on Wed, Jun 28, 2000 at 02:12:28PM -0700 References: <200006282112.OAA03095@slayer.i.sourceforge.net> Message-ID: <20000628144800.T29590@lyra.org> On Wed, Jun 28, 2000 at 02:12:28PM -0700, Guido van Rossum wrote: >... > - chunk #2: > The id() function guarantees a unique return value for different > objects. It does this by returning the pointer to the object. By > returning a PyInt, on Win64 (sizeof(long) < sizeof(void*)) the pointer > is truncated and the guarantee may be proven false. The appropriate > return function is PyLong_FromVoidPtr, this returns a PyLong if that > is necessary to return the pointer without truncation. > > [GvR: note that this means that id() can now return a long on Win32 > platforms. This *might* break some code...] Strictly speaking: the Long only occurs on Win64 platforms. I would guess that it is also possible on say, an Alpha running Linux. Presuming that has 64-bit pointers(?). Regardless: yes, it can certainly break some code. IMO, if any code out there makes any kinds of assumptions about id(), then they deserve to be broken :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From paul at prescod.net Wed Jun 28 23:44:33 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 28 Jun 2000 14:44:33 -0700 Subject: [Python-Dev] OT: A Day in the Life of p5p References: <033a01bfe141$71b0cfc0$f2a6b5d4@hagrid> <20000628140342.Q29590@lyra.org> Message-ID: <395A71C1.A4E332D@prescod.net> Re: Performance At the very least this readlines() optimization should be in FileInput which was invented, after all, in order to compete with Perl. --- Re: Inline Unicode smily faces Bill and Mark-Andre, you rock. Another feature stolen from Perl. If only it were as easy to steal cleanliness and elegance. :) --- Re: GC On by default in beta would be peachy. -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From bwarsaw at beopen.com Thu Jun 29 00:01:00 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 28 Jun 2000 18:01:00 -0400 (EDT) Subject: [Python-Dev] exceptions trouble References: <036201bfe146$90b7fb00$f2a6b5d4@hagrid> <20000628173038.B28659@kronos.cnri.reston.va.us> Message-ID: <14682.30108.714768.740415@anthem.concentric.net> >>>>> "AK" == Andrew Kuchling writes: AK> It works fine in my current copy of the CVS tree, and I think AK> I rebuilt everything this morning. Same here. From trentm at activestate.com Thu Jun 29 00:04:28 2000 From: trentm at activestate.com (Trent Mick) Date: Wed, 28 Jun 2000 15:04:28 -0700 Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163) In-Reply-To: <20000628144800.T29590@lyra.org> References: <200006282112.OAA03095@slayer.i.sourceforge.net> <20000628144800.T29590@lyra.org> Message-ID: <20000628150428.E17875@activestate.com> On Wed, Jun 28, 2000 at 02:48:00PM -0700, Greg Stein wrote: > Regardless: yes, it can certainly break some code. IMO, if any code out > there makes any kinds of assumptions about id(), then they deserve to be > broken :-) Amen. Trent -- Trent Mick trentm at activestate.com From nascheme at enme.ucalgary.ca Thu Jun 29 00:07:43 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Wed, 28 Jun 2000 16:07:43 -0600 Subject: [Python-Dev] id() on Win64 Message-ID: <20000628160743.A16262@acs.ucalgary.ca> [Greg Stein] >Strictly speaking: the Long only occurs on Win64 platforms. > >I would guess that it is also possible on say, an Alpha running >Linux. Presuming that has 64-bit pointers(?). I think the Alpha is okay. The problem is strange type models were int is 32 bits and pointers are 64. AFAIK, the Alpha uses 64 bits for both. Neil From guido at beopen.com Thu Jun 29 01:10:52 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 28 Jun 2000 18:10:52 -0500 Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163) In-Reply-To: Your message of "Wed, 28 Jun 2000 14:48:00 MST." <20000628144800.T29590@lyra.org> References: <200006282112.OAA03095@slayer.i.sourceforge.net> <20000628144800.T29590@lyra.org> Message-ID: <200006282310.SAA05850@cj20424-a.reston1.va.home.com> > > [GvR: note that this means that id() can now return a long on Win32 > > platforms. This *might* break some code...] > > Strictly speaking: the Long only occurs on Win64 platforms. You're right. > I would guess that it is also possible on say, an Alpha running Linux. > Presuming that has 64-bit pointers(?). No, because their longs are also 64 bits, and hence so are Python ints. > Regardless: yes, it can certainly break some code. IMO, if any code out > there makes any kinds of assumptions about id(), then they deserve to be > broken :-) That depends. It is documented as an integer -- which may be vague enough to encompass longs, but that's weasel-wording. ;-) I do think that the likelihood of this breaking significant code is low. --Guido van Rossum (home page: http://www.python.org/~guido/) From gstein at lyra.org Thu Jun 29 00:17:58 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 28 Jun 2000 15:17:58 -0700 Subject: [Python-Dev] PyString_GET_SIZE() (was: CVS: python/dist/src/Objects classobject.c,2.89,2.90 object.c,2.72,2.73) In-Reply-To: <200006282157.OAA05880@slayer.i.sourceforge.net>; from gvanrossum@users.sourceforge.net on Wed, Jun 28, 2000 at 02:57:20PM -0700 References: <200006282157.OAA05880@slayer.i.sourceforge.net> Message-ID: <20000628151758.X29590@lyra.org> On Wed, Jun 28, 2000 at 02:57:20PM -0700, Guido van Rossum wrote: > Update of /cvsroot/python/python/dist/src/Objects > In directory slayer.i.sourceforge.net:/tmp/cvs-serv5838 > > Modified Files: > classobject.c object.c > Log Message: > Trent Mick: change a few casts for Win64 compatibility. > > > Index: classobject.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Objects/classobject.c,v > retrieving revision 2.89 > retrieving revision 2.90 > diff -C2 -r2.89 -r2.90 > *** classobject.c 2000/06/23 19:37:01 2.89 > --- classobject.c 2000/06/28 21:57:18 2.90 > *************** > *** 284,288 **** > if (v == NULL || !PyString_Check(v)) > return "__name__ must be a string object"; > ! if ((long)strlen(PyString_AS_STRING(v)) != PyString_GET_SIZE(v)) > return "__name__ must not contain null bytes"; > set_slot(&c->cl_name, v); > --- 284,288 ---- > if (v == NULL || !PyString_Check(v)) > return "__name__ must be a string object"; > ! if (strlen(PyString_AS_STRING(v)) != (size_t)PyString_GET_SIZE(v)) > return "__name__ must not contain null bytes"; > set_slot(&c->cl_name, v); Actually, it would seem to make more sense to place the cast *inside* the PyString_GET_SIZE() macro. That is the "true" semantic for GET_SIZE. May as well start some ANSI-fication while we can... Guido: any problem with my changing the macro? Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Thu Jun 29 00:16:17 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 28 Jun 2000 15:16:17 -0700 Subject: [Python-Dev] httplib doc (was: CVS: python/dist/src/Doc/lib libhttplib.tex,1.19,1.20) In-Reply-To: <200006282151.OAA05489@slayer.i.sourceforge.net>; from fdrake@users.sourceforge.net on Wed, Jun 28, 2000 at 02:51:46PM -0700 References: <200006282151.OAA05489@slayer.i.sourceforge.net> Message-ID: <20000628151617.W29590@lyra.org> Please mark me for a TODO to update the httplib doc. For example, the code below is more effectively written as: h = httplib.HTTPConnection('www.musi-cal.com') h.request('POST', '/cgi-bin/query', paramstring, {'Accept': 'text/plain'}) response = h.getresponse() print response.status # should be 200 data = response.read() # get the raw HTML Note that 'Accept' is usually not a required header and can be omitted in most scenarios. I left it in the example simply to show how to fully map between the old/new APIs. [ Content-Length and Host are sent automatically by HTTPConnection. ] Cheers, -g On Wed, Jun 28, 2000 at 02:51:46PM -0700, Fred L. Drake wrote: > Update of /cvsroot/python/python/dist/src/Doc/lib > In directory slayer.i.sourceforge.net:/tmp/cvs-serv5474/lib > > Modified Files: > libhttplib.tex > Log Message: > > Skip Montanaro : > Added an example of using an HTTP POST request. > > > Index: libhttplib.tex > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Doc/lib/libhttplib.tex,v > retrieving revision 1.19 > retrieving revision 1.20 > diff -C2 -r1.19 -r1.20 > *** libhttplib.tex 1999/04/22 16:47:27 1.19 > --- libhttplib.tex 2000/06/28 21:51:43 1.20 > *************** > *** 115,119 **** > \nodename{HTTP Example} > > ! Here is an example session: > > \begin{verbatim} > --- 115,119 ---- > \nodename{HTTP Example} > > ! Here is an example session that uses the \samp{GET} method: > > \begin{verbatim} > *************** > *** 129,131 **** > --- 129,148 ---- > >>> data = f.read() # Get the raw HTML > >>> f.close() > + \end{verbatim} > + > + Here is an example session that shows how to \samp{POST} requests: > + > + \begin{verbatim} > + >>> import httplib, urllib > + >>> params = urllib.urlencode({'spam': 1, 'eggs': 2, 'bacon': 0}) > + >>> h = httplib.HTTP("www.musi-cal.com:80") > + >>> h.putrequest("POST", "/cgi-bin/query") > + >>> h.putheader("Content-length", "%d" % len(params)) > + >>> h.putheader('Accept', 'text/plain') > + >>> h.putheader('Host', 'www.musi-cal.com') > + >>> h.endheaders() > + >>> h.send(paramstring) > + >>> reply, msg, hdrs = h.getreply() > + >>> print errcode # should be 200 > + >>> data = h.getfile().read() # get the raw HTML > \end{verbatim} > > > _______________________________________________ > Python-checkins mailing list > Python-checkins at python.org > http://www.python.org/mailman/listinfo/python-checkins -- Greg Stein, http://www.lyra.org/ From mal at lemburg.com Thu Jun 29 00:38:29 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 29 Jun 2000 00:38:29 +0200 Subject: [Python-Dev] ucnhash module References: <20000628205832.C3234E2673@oratrix.oratrix.nl> Message-ID: <395A7E65.2271C723@lemburg.com> Jack Jansen wrote: > > I'm a bit worried about the ucnhash module and its huge size. I didn't > follow the discussion closely at the time, because I thought I could > always exclude it from the Pythons without dynamic linking, but now it > seems that if i don't include it test_unicode doesn't run anymore. > > Is this a problem with test_unicode, or should I consider ucnhash a > mandatory module? The ucnhash module is loaded on demand to avoid memory bloat. In practice the difference is not really noticeable since loading a shared module or swapping in a few pages of static C data result in pretty much the same overall memory usage. If no-one complains, I'll fix the test suite though to make the tests of the named Unicode characters optional. Is this ok with you, Bill ? > (BTW: there were also a couple of bugs in the module, include <> in > stead of include "", and static in stead of staticforward > declarations, I'll submit patches for those shortly). I didn't have any problem compiling the module (don't even get warnings when compiling with -Wall) ... but you're right: these ought to get fixed. BTW, since ucnhash.h|c are generated using the scripts in Tools/perfecthash/ your patch should probably also fix the instances of the problems found in there. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From tim_one at email.msn.com Thu Jun 29 00:47:04 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 28 Jun 2000 18:47:04 -0400 Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163) In-Reply-To: <20000628150428.E17875@activestate.com> Message-ID: [Greg Stein] > Regardless: yes, it can certainly break some code. IMO, if any code out > there makes any kinds of assumptions about id(), then they deserve to be > broken :-) [Trent Mick] > Amen. Guys, it's almost never that simple, and developers are the last ones to think of the reasonable cases that may break. In this case, e.g., code may be doing something as harmless as printing an id() via a "... %d ..." format in a log, and-- BOOM! --that blows up with an OverflowError if you feed it a Python long larger than a C long. I'd rather fix %d formats than leave id() broken, though! id() has to return a unique value. but-i'll-sympathize-with-the-users-even-in-public-ly y'rs - tim From trentm at activestate.com Thu Jun 29 01:49:55 2000 From: trentm at activestate.com (Trent Mick) Date: Wed, 28 Jun 2000 16:49:55 -0700 Subject: [Python-Dev] PyString_GET_SIZE() (was: CVS: python/dist/src/Objects classobject.c,2.89,2.90 object.c,2.72,2.73) In-Reply-To: <20000628151758.X29590@lyra.org> References: <200006282157.OAA05880@slayer.i.sourceforge.net> <20000628151758.X29590@lyra.org> Message-ID: <20000628164955.B19053@activestate.com> On Wed, Jun 28, 2000 at 03:17:58PM -0700, Greg Stein wrote: > On Wed, Jun 28, 2000 at 02:57:20PM -0700, Guido van Rossum wrote: > > Update of /cvsroot/python/python/dist/src/Objects > > In directory slayer.i.sourceforge.net:/tmp/cvs-serv5838 > > > > Modified Files: > > classobject.c object.c > > Log Message: > > Trent Mick: change a few casts for Win64 compatibility. > > > > > > Index: classobject.c > > =================================================================== > > RCS file: /cvsroot/python/python/dist/src/Objects/classobject.c,v > > retrieving revision 2.89 > > retrieving revision 2.90 > > diff -C2 -r2.89 -r2.90 > > *** classobject.c 2000/06/23 19:37:01 2.89 > > --- classobject.c 2000/06/28 21:57:18 2.90 > > *************** > > *** 284,288 **** > > if (v == NULL || !PyString_Check(v)) > > return "__name__ must be a string object"; > > ! if ((long)strlen(PyString_AS_STRING(v)) != PyString_GET_SIZE(v)) > > return "__name__ must not contain null bytes"; > > set_slot(&c->cl_name, v); > > --- 284,288 ---- > > if (v == NULL || !PyString_Check(v)) > > return "__name__ must be a string object"; > > ! if (strlen(PyString_AS_STRING(v)) != (size_t)PyString_GET_SIZE(v)) > > return "__name__ must not contain null bytes"; > > set_slot(&c->cl_name, v); > > Actually, it would seem to make more sense to place the cast *inside* the > PyString_GET_SIZE() macro. That is the "true" semantic for GET_SIZE. > > May as well start some ANSI-fication while we can... > I agree. Go to town, Greg. :) Trent -- Trent Mick trentm at activestate.com From gstein at lyra.org Thu Jun 29 02:08:40 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 28 Jun 2000 17:08:40 -0700 Subject: [Python-Dev] Text about cycle GC In-Reply-To: <200006282059.PAA04852@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Wed, Jun 28, 2000 at 03:59:46PM -0500 References: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com> <395A359A.2CF0CA70@prescod.net> <14682.15020.589514.702145@bitdiddle.concentric.net> <395A3F62.EA1E8B89@prescod.net> <20000628122725.A13473@acs.ucalgary.ca> <200006282059.PAA04852@cj20424-a.reston1.va.home.com> Message-ID: <20000628170840.E29590@lyra.org> On Wed, Jun 28, 2000 at 03:59:46PM -0500, Guido van Rossum wrote: > > On Wed, Jun 28, 2000 at 11:09:38AM -0700, Paul Prescod wrote: > > > I'm a little disappointed that it will be so difficult for people to > > > test with GC on, but I'm not going to claim that there is some easy way > > > to make it a runtime option because I haven't looked at it at all. There > > > probably isn't. > > > > There isn't. With an interpreter compiled --with-cycle-gc you can > > turn off the collection with gc.set_threshold(0) but that's not > > the same thing. > > > > Neil > > I wonder if we should turn this option *on* during beta testing? > > That way we gather a lot more experience with its use! Maybe nobody > complains and we can leave it on in the final release... That presumes an adequate number of testers and a wide variety of deployment/usage scenarios. Given the relatively short timeframe, that may be a bit aggressive. I *do* agree with enabling it during the beta. But I'm just not sure about leaving it on. Cheers, -g -- Greg Stein, http://www.lyra.org/ From tim_one at email.msn.com Thu Jun 29 02:07:20 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 28 Jun 2000 20:07:20 -0400 Subject: [Python-Dev] add Demo/imputil/importers.py ? In-Reply-To: <20000628124606.K29590@lyra.org> Message-ID: [Greg Stein] > ... > I'd throw Tools into the same thing [as Demos]. As a separate distro, > you can have a faster release cycle. ... you could release Idle > updates easily and distinctly from the Python core. Note that Guido gave his blessing for a "wide open" policy on IDLE (== its own project in SourceForge, and anyone can be a developer). If that's a success (& I predict it will be, provided someone actually bothers to set up the SF project!), I'd like to see it spread to Tools and Demos too. ignoring-the-downsides-cuz-they'll-make-themselves-known-ly y'rs - tim From guido at beopen.com Thu Jun 29 03:11:36 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 28 Jun 2000 20:11:36 -0500 Subject: [Python-Dev] PyString_GET_SIZE() (was: CVS: python/dist/src/Objects classobject.c,2.89,2.90 object.c,2.72,2.73) In-Reply-To: Your message of "Wed, 28 Jun 2000 15:17:58 MST." <20000628151758.X29590@lyra.org> References: <200006282157.OAA05880@slayer.i.sourceforge.net> <20000628151758.X29590@lyra.org> Message-ID: <200006290111.UAA08357@cj20424-a.reston1.va.home.com> > > ! if (strlen(PyString_AS_STRING(v)) != (size_t)PyString_GET_SIZE(v)) > > Actually, it would seem to make more sense to place the cast *inside* the > PyString_GET_SIZE() macro. That is the "true" semantic for GET_SIZE. > > May as well start some ANSI-fication while we can... > > Guido: any problem with my changing the macro? Please leave the macro alone. The type of the macro should be the same as the type of the function -- PyString_Size() -- which is int. If you change this, you potentially get tons of warnings because of the signed / unsigned nature. ANSI-fication is a good project for after 1.6. But even then, it's a separate decision whether the size of a string should be a size_t instead of an int. (The ob_size field should also change, if so -- with even more consequences.) --Guido van Rossum (home page: http://www.python.org/~guido/) From gstein at lyra.org Thu Jun 29 02:29:20 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 28 Jun 2000 17:29:20 -0700 Subject: [Python-Dev] PyString_GET_SIZE() In-Reply-To: <200006290111.UAA08357@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Wed, Jun 28, 2000 at 08:11:36PM -0500 References: <200006282157.OAA05880@slayer.i.sourceforge.net> <20000628151758.X29590@lyra.org> <200006290111.UAA08357@cj20424-a.reston1.va.home.com> Message-ID: <20000628172919.G29590@lyra.org> On Wed, Jun 28, 2000 at 08:11:36PM -0500, Guido van Rossum wrote: > > > ! if (strlen(PyString_AS_STRING(v)) != (size_t)PyString_GET_SIZE(v)) > > > > Actually, it would seem to make more sense to place the cast *inside* the > > PyString_GET_SIZE() macro. That is the "true" semantic for GET_SIZE. > > > > May as well start some ANSI-fication while we can... > > > > Guido: any problem with my changing the macro? > > Please leave the macro alone. The type of the macro should be the > same as the type of the function -- PyString_Size() -- which is int. > If you change this, you potentially get tons of warnings because of > the signed / unsigned nature. > > ANSI-fication is a good project for after 1.6. But even then, it's a > separate decision whether the size of a string should be a size_t > instead of an int. (The ob_size field should also change, if so -- > with even more consequences.) Post 1.6, yes... I had figured on ob_size changing. Certainly not now :-) But I understand the point about different return types. No problem. [ of course, I would state that PyString_Size should also change and we fix those warnings... but I'll be patient :-) ] How about removing Py_PROTO() usage, and changing function definitions from K&R arg declaration to ANSI declarations? That kind of work is pretty simple, straight-forward, and if somebody has free time to plod through the work... so much the better. I believe that these changes would not introduce any stability problems, and could be done independently from your busy schedule. Hmm. Is there a good place to start listing these todo items? One that we can truly use for communicating this info? In Apache, we have a file named STATUS that everybody uses for dropping ideas, patch references, critical bugs, etc. As that file gets changed, we see it in the -checkins alias, so everybody is aware of the suggested changes/problems/available patches/etc. It also holds people's votes on particular changes. Can we institute something similar? Possibly Misc/STATUS? Should I post Apache's STATUS file as an example? Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Thu Jun 29 02:34:24 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 28 Jun 2000 17:34:24 -0700 Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager In-Reply-To: <395A32FD.D3C58B23@prescod.net>; from paul@prescod.net on Wed, Jun 28, 2000 at 10:16:45AM -0700 References: <395A32FD.D3C58B23@prescod.net> Message-ID: <20000628173424.H29590@lyra.org> I think you are being paranoid :-) Consider that this same issue applies to all 5900 projects and 38000 developers at SourceForge. VA Linux has a brand identity entirely built on the trust and support of the Linux (and Open Source) communities. If they blow away that trust, they are simply screwed. That said: it would still be a good thing to have export capabilities. I recall that certain portions of the data (the Trove map?) can be exported in XML format. I don't recall the magic URL for that, however. Cheers, -g On Wed, Jun 28, 2000 at 10:16:45AM -0700, Paul Prescod wrote: > I don't want to be paranoid, but are we putting any important > information into SourceForge that we are not backing up elsewhere? I > mean okay, we've all got CVS dumps, but if it went away (DOJ antitrust > suit...) would we have backups of our patches, bugs, wish lists and so > forth? I hope that's a criteria in deciding what services to move to > SourceForge. I am in the business of preserving investments in data and > of telling customers to avoid software that does not keep them in > complete control of their data. SF makes me nervous that way.... > > -- > Paul Prescod - Not encumbered by corporate consensus > The calculus and the rich body of mathematical analysis to which it > gave rise made modern science possible, but it was the algorithm that > made the modern world possible. > - The Advent of the Algorithm (pending), by David Berlinski > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Thu Jun 29 02:36:41 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 28 Jun 2000 17:36:41 -0700 Subject: [Python-Dev] RTFM: SourceForge access for Win32 Message-ID: <20000628173641.I29590@lyra.org> All right guys... all this banter about setting up CVS access for Win32 users has been quite silly. Did anybody even stop to look at the docs? http://sfdocs.sourceforge.net/sfdocs/ In particular: http://sfdocs.sourceforge.net/sfdocs/display_topic.php?topicid=19 http://sfdocs.sourceforge.net/sfdocs/display_topic.php?topicid=20 http://sfdocs.sourceforge.net/sfdocs/display_topic.php?topicid=46 There is also a new tool available (released today); http://sfsetup.sourceforge.net/ Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Thu Jun 29 03:01:40 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 28 Jun 2000 18:01:40 -0700 Subject: [Python-Dev] add Demo/imputil/importers.py ? In-Reply-To: ; from tim_one@email.msn.com on Wed, Jun 28, 2000 at 08:07:20PM -0400 References: <20000628124606.K29590@lyra.org> Message-ID: <20000628180140.M29590@lyra.org> On Wed, Jun 28, 2000 at 08:07:20PM -0400, Tim Peters wrote: > [Greg Stein] > > ... > > I'd throw Tools into the same thing [as Demos]. As a separate distro, > > you can have a faster release cycle. ... you could release Idle > > updates easily and distinctly from the Python core. > > Note that Guido gave his blessing for a "wide open" policy on IDLE (== its > own project in SourceForge, and anyone can be a developer). If that's a > success (& I predict it will be, provided someone actually bothers to set up > the SF project!), I'd like to see it spread to Tools and Demos too. Are you suggesting that IDLE be separate from a Tools/Demo package, or that the whole bunch be shoved out into the wild? Hmm... I guess that I don't much have an opinion one way or the other, but was mostly looking for clarification. Cheers, -g -- Greg Stein, http://www.lyra.org/ From jeremy at beopen.com Thu Jun 29 04:08:51 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Wed, 28 Jun 2000 22:08:51 -0400 (EDT) Subject: [Python-Dev] how do I build pyexpat? Message-ID: <14682.44979.673881.83798@bitdiddle.concentric.net> Setup.in contains the following comment: # (Note: the expat build process doesn't yet build a libexpat.a; you can # do this manually while we try convince the author to add it.) I've got expat, and I've built it, but I don't have any idea how to build libexpat.a. It may be possible to do it manually, but it would help a lot if the comments could say how to build it or contain a link to instructions on how to build it. Jeremy From gward at python.net Thu Jun 29 04:37:08 2000 From: gward at python.net (Greg Ward) Date: Wed, 28 Jun 2000 22:37:08 -0400 Subject: [Python-Dev] Just spotted on SourceForge main page Message-ID: <20000628223707.A1168@beelzebub> Maybe this is what all you Windows folks are looking for. SFSetup v1 released mhearn - 06/28/00 11:00 - SourceForge Setup for Win32 SFSetup is a program to automatically setup SSH and WinCVS for SourceForge projects under the Windows 32 platform. It's now available for download so if you have not yet set up SSH and WinCVS and want it done for you, you can use this program. Go to sfsetup.sourceforge.net to find out how to use it. It's open source and written in Delphi - the code is in CVS and any improvements are welcome! Thanks -mike -- Greg Ward - Linux nerd gward at python.net http://starship.python.net/~gward/ I love ROCK 'N ROLL! I memorized the all WORDS to "WIPE-OUT" in 1965!! From fdrake at beopen.com Thu Jun 29 05:26:55 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Wed, 28 Jun 2000 23:26:55 -0400 (EDT) Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163) In-Reply-To: <200006282310.SAA05850@cj20424-a.reston1.va.home.com> References: <200006282112.OAA03095@slayer.i.sourceforge.net> <20000628144800.T29590@lyra.org> <200006282310.SAA05850@cj20424-a.reston1.va.home.com> Message-ID: <14682.49663.208158.88794@cj42289-a.reston1.va.home.com> Guido van Rossum writes: > That depends. It is documented as an integer -- which may be vague > enough to encompass longs, but that's weasel-wording. ;-) The 1.6 documentation will make it clear that this may be a long integer, but I don't think we need to promise on which platforms this will be the case. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From paul at prescod.net Thu Jun 29 06:21:41 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 28 Jun 2000 21:21:41 -0700 Subject: [Python-Dev] how do I build pyexpat? References: <14682.44979.673881.83798@bitdiddle.concentric.net> Message-ID: <395ACED5.83764D45@prescod.net> I don't know where you got your expat or how new it is, but with the one I got from the xml-sig, I can type "make libexpat.a" -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From tim_one at email.msn.com Thu Jun 29 06:55:22 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 29 Jun 2000 00:55:22 -0400 Subject: [Python-Dev] PyString_GET_SIZE() In-Reply-To: <20000628172919.G29590@lyra.org> Message-ID: [Greg Stein] > ... > How about removing Py_PROTO() usage, and changing function > definitions from K&R arg declaration to ANSI declarations? That > kind of work is pretty simple, straight-forward, and if somebody > has free time to plod through the work... so much the better. I think it's too late in the cycle to suggest work for others to do and get any payback from that. Unless you're the one with the free time -- in which case full speed ahead and God bless! I previously volunteered to take the Py_PROTO crap on, as I use an editor with a symbol database that gets confused by that stuff, but I'm sure not going to start that this week. > ... > Hmm. Is there a good place to start listing these todo items? Not that I know of. "Group whiteboards" and shared journals etc are darned useful, though. > One that we can truly use for communicating this info? In Apache, we > have a file named STATUS that everybody uses for dropping ideas, patch > references, critical bugs, etc. As that file gets changed, we see it > in the -checkins alias, so everybody is aware of the suggested > changes/problems/available patches/etc. It also holds people's votes > on particular changes. > > Can we institute something similar? Possibly Misc/STATUS? Should I post > Apache's STATUS file as an example? Yes, sure, no: just check one in! If Guido hates it, we can remove it later. In the meantime, I bet we'll find great ways to use it. In the spirit of Unix, maybe it should be called Misc/gwtbd . let-a-thousand-idiosyncracies-bloom-ly y'rs - tim From tim_one at email.msn.com Thu Jun 29 06:55:24 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 29 Jun 2000 00:55:24 -0400 Subject: [Python-Dev] RTFM: SourceForge access for Win32 In-Reply-To: <20000628173641.I29590@lyra.org> Message-ID: > All right guys... all this banter about setting up CVS access for Win32 > users has been quite silly. It's been a valuable object lesson, Greg: I showed everyone the value of sitting on their ass until someone who knows what they're doing can't stand it anymore <0.8 wink>. > Did anybody even stop to look at the docs? Didn't seem so to me. I personally never found any docs, despite looking for them. > http://sfdocs.sourceforge.net/sfdocs/ Great! Thank you. > ... > There is also a new tool available (released today); > > http://sfsetup.sourceforge.net/ From tim_one at email.msn.com Thu Jun 29 07:08:27 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 29 Jun 2000 01:08:27 -0400 Subject: [Python-Dev] add Demo/imputil/importers.py ? In-Reply-To: <20000628180140.M29590@lyra.org> Message-ID: [Greg Stein] > Are you suggesting that IDLE be separate from a Tools/Demo > package, or that the whole bunch be shoved out into the wild? There's already an IDLE distribution distinct from Python's: http://www.python.org/idle/ Note that the IDLE 0.5 there is not what was shipped with 1.5.2; I'm not clear on why that hasn't been updated to IDLE 0.6 already (suspect just lack of time). > Hmm... I guess that I don't much have an opinion one way or the other, but > was mostly looking for clarification. I don't have a specific plan in mind either -- just "me too"ing on the idea that it would do no harm and possibly do real good to let these peripheral (to the core) things live on their own schedules. I don't see any harm in including "the latest" snapshot of them with the core distribution, though -- it's handy for newcomers to get these things without needing to search for them. I know I learned a lot about Python at the start from browsing these directories. From skip at mojam.com Thu Jun 29 07:27:02 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 29 Jun 2000 00:27:02 -0500 (CDT) Subject: [Python-Dev] Another Python-based company makes good... Message-ID: <14682.56870.790737.261865@beluga.mojam.com> Saw this on InfoBeat today: ** Yahoo to buy EGroups Yahoo said it would buy e-mail service provider EGroups (www.egroups.com) for $437.5 million in stock to enhance the Internet giant's communications services. Yahoo (YHOO) said it would issue 3.43 million shares of stock for all of EGroups shares, options, and warrants. The purchase will be accounted for as a pooling of interests and is expected to close in the third quarter. Yahoo said it would report a one-time charge during the third quarter for expenses to cover the takeover. Looks like Scott Hassan can safely drop out of grad school now (if he hasn't already)... ;-) -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille O'Neal said: "He's got the rings. I listen to the man with the rings." From skip at mojam.com Thu Jun 29 07:39:09 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 29 Jun 2000 00:39:09 -0500 (CDT) Subject: [Python-Dev] OT: A Day in the Life of p5p In-Reply-To: <395A31B7.911D9BC2@prescod.net> References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> <395A31B7.911D9BC2@prescod.net> Message-ID: <14682.57597.600123.167311@beluga.mojam.com> Paul> http://gisle.aas.no/perl/illguts/ The author of all those pretty diagrams is going to be really pissed when they rename all the data structures in Perl 6... :-/ Skip From tim_one at email.msn.com Thu Jun 29 08:47:41 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 29 Jun 2000 02:47:41 -0400 Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager In-Reply-To: <200006281541.KAA02041@cj20424-a.reston1.va.home.com> Message-ID: [Guido] > OK, I've disabled the SF bugs manager. There were two bugs submitted > so far. I've assigned one to you (about os.listdir on Windows) and > one to MAL (about -U vs. exec/eval). You two can take care of > entering these into JB. You can still access the bugs database via > this URL: > > https://sourceforge.net/bugs/?group_id=5470 I moved "my" bug to Jitterbug, and moved Marc-Andre's too to save him the bother. Marked them "Closed" and "Duplicate" on SourceForge, so that if we reenable bug management there someday they won't confuse us. From moshez at math.huji.ac.il Thu Jun 29 09:12:17 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Thu, 29 Jun 2000 10:12:17 +0300 (IDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Doc TODO,1.26,1.27 In-Reply-To: <200006282213.PAA13365@slayer.i.sourceforge.net> Message-ID: On Wed, 28 Jun 2000, Fred L. Drake wrote: > + * Update the filecmp documentation (Moshe?). I'm waiting for Gordon to check-in his directory comparisons to filecmp. Gordon? -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com From effbot at telia.com Thu Jun 29 10:19:42 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 29 Jun 2000 10:19:42 +0200 Subject: [Python-Dev] id() on Win64 References: Message-ID: <00d501bfe1a2$c93f8cc0$f2a6b5d4@hagrid> tim wrote: > [Greg Stein] > > Regardless: yes, it can certainly break some code. IMO, if any code out > > there makes any kinds of assumptions about id(), then they deserve to be > > broken :-) > > [Trent Mick] > > Amen. > > Guys, it's almost never that simple, and developers are the last ones to > think of the reasonable cases that may break. especially since it's documented to be an integer: id (object) Return the `identity' of an object. This is an integer which is guaranteed to be unique and constant for this object during its lifetime. (section 2.1.4 says that "integer" is the same thing as a "plain integer", and that "long integer" is something different). From gstein at lyra.org Thu Jun 29 11:15:08 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 29 Jun 2000 02:15:08 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules _sre.c,2.4,2.5 In-Reply-To: <200006290857.BAA11219@slayer.i.sourceforge.net>; from effbot@users.sourceforge.net on Thu, Jun 29, 2000 at 01:57:57AM -0700 References: <200006290857.BAA11219@slayer.i.sourceforge.net> Message-ID: <20000629021508.P29590@lyra.org> Euh... can we get a bit more information in that checkin message. "towards 1.6b1" says zippo about what is changing or why. Cheers, -g On Thu, Jun 29, 2000 at 01:57:57AM -0700, Fredrik Lundh wrote: > Update of /cvsroot/python/python/dist/src/Modules > In directory slayer.i.sourceforge.net:/tmp/cvs-serv11206 > > Modified Files: > _sre.c > Log Message: > towards 1.6b1 > > Index: _sre.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Modules/_sre.c,v > retrieving revision 2.4 > retrieving revision 2.5 > diff -C2 -r2.4 -r2.5 > *** _sre.c 2000/06/01 17:34:20 2.4 > --- _sre.c 2000/06/29 08:57:54 2.5 > *************** > *** 4,20 **** > * $Id$ > * > ! * simple regular expression matching engine > * > * partial history: > ! * 99-10-24 fl created (based on the template matcher) > * 99-11-13 fl added categories, branching, and more (0.2) > * 99-11-16 fl some tweaks to compile on non-Windows platforms > * 99-12-18 fl non-literals, generic maximizing repeat (0.3) > ! * 99-02-28 fl tons of changes (not all to the better ;-) (0.4) > [...1589 lines suppressed...] > > void > ! #if defined(WIN32) > __declspec(dllexport) > #endif > *************** > *** 1708,1713 **** > Cursor_Type.ob_type = &PyType_Type; > > ! Py_InitModule("_sre", _functions); > } > > ! #endif > --- 1846,1851 ---- > Cursor_Type.ob_type = &PyType_Type; > > ! Py_InitModule("_" MODULE, _functions); > } > > ! #endif /* !defined(SRE_RECURSIVE) */ > > > _______________________________________________ > Python-checkins mailing list > Python-checkins at python.org > http://www.python.org/mailman/listinfo/python-checkins -- Greg Stein, http://www.lyra.org/ From effbot at telia.com Thu Jun 29 11:29:11 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 29 Jun 2000 11:29:11 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules _sre.c,2.4,2.5 References: <200006290857.BAA11219@slayer.i.sourceforge.net> <20000629021508.P29590@lyra.org> Message-ID: <005601bfe1ac$7e014460$f2a6b5d4@hagrid> greg wrote: > Euh... can we get a bit more information in that checkin message. "towards > 1.6b1" says zippo about what is changing or why. just bringing the repository in sync with the current development snapshot -- I promise to provide more info when the checkins are more focused... just gotta reach "1.6b1 quality" first... From bckfnn at worldonline.dk Thu Jun 29 11:42:03 2000 From: bckfnn at worldonline.dk (Finn Bock) Date: Thu, 29 Jun 2000 09:42:03 GMT Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163) In-Reply-To: References: Message-ID: <395b1528.5978476@smtp.worldonline.dk> [Tim Peters] >id() has to return a unique value. This property of id() does not hold in JPython. When used with hotspot, id() is not unique. regards, finn From Vladimir.Marangozov at inrialpes.fr Thu Jun 29 12:05:12 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Thu, 29 Jun 2000 12:05:12 +0200 (CEST) Subject: [Python-Dev] id() on Win64 In-Reply-To: <395b1528.5978476@smtp.worldonline.dk> from "Finn Bock" at Jun 29, 2000 09:42:03 AM Message-ID: <200006291005.MAA20940@python.inrialpes.fr> Finn Bock wrote: > > [Tim Peters] > > >id() has to return a unique value. > > This property of id() does not hold in JPython. When used with hotspot, > id() is not unique. Is it? Not unique or not persistent during the object's lifetime? -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From effbot at telia.com Thu Jun 29 12:07:42 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 29 Jun 2000 12:07:42 +0200 Subject: [Python-Dev] build problems under MSVC 5.0 Message-ID: <008a01bfe1b1$e08a8a60$f2a6b5d4@hagrid> Python\thread_nt.h(185) : error C2065: 'INT_PTR' : undeclared identifier Python\thread_nt.h(185) : error C2146: syntax error : missing ';' before identifier 'rv' Python\thread_nt.h(185) : error C2065: 'rv' : undeclared identifier Python\thread_nt.h(186) : error C2143: syntax error : missing ';' before 'type' Python\thread_nt.h(195) : error C2065: 'success' : undeclared identifier in MSVC 5.0, _beginthread returns an "unsigned long" (this is also how it's documented in MSDN). I suggest changing the declaration in thread_nt.h to: #if _MSC_VER >= 1200 INT_PTR rv; #else unsigned long rv; #endif on the other hand, the same docs claim that it returns -1 on errors. doesn't exactly look like an unsigned long to me, but that's another story... From effbot at telia.com Thu Jun 29 12:21:22 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 29 Jun 2000 12:21:22 +0200 Subject: [Python-Dev] arraymodule still broken? Message-ID: <009e01bfe1b3$c6cd4480$f2a6b5d4@hagrid> just checked everything out and rebuilt, the exceptions problem sure disappeared, but I still get this error: >>> import array >>> array.array("H", [60000]) Traceback (most recent call last): File "", line 1, in ? OverflowError: signed short integer is greater than maximum second opinion, anyone? From bckfnn at worldonline.dk Thu Jun 29 12:43:55 2000 From: bckfnn at worldonline.dk (Finn Bock) Date: Thu, 29 Jun 2000 10:43:55 GMT Subject: [Python-Dev] id() on Win64 In-Reply-To: <200006291005.MAA20940@python.inrialpes.fr> References: <200006291005.MAA20940@python.inrialpes.fr> Message-ID: <395b26e6.10520397@smtp.worldonline.dk> [Finn Bock] > This property of id() does not hold in JPython. When used with hotspot, > id() is not unique. [Vladimir Marangozov} >Is it? >Not unique or not persistent during the object's lifetime? Not unique. Two different objects can return the same value from System.identityHashCode(). The HTML java docs have this to say about hashCodes: """ As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. (This is typically implemented by converting the internal address of the object into an integer, but this implementation technique is not required by the JavaTM programming language.) """ Its just one of those small difference that we have to live with. In pratical term I have seen it cause problems in pickle.py and copy.deepcopy() regards, finn From gmcm at hypernet.com Thu Jun 29 14:22:12 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Thu, 29 Jun 2000 08:22:12 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Doc TODO,1.26,1.27 In-Reply-To: References: <200006282213.PAA13365@slayer.i.sourceforge.net> Message-ID: <1249841091-43777448@hypernet.com> Moshe wrote: > On Wed, 28 Jun 2000, Fred L. Drake wrote: > > > + * Update the filecmp documentation (Moshe?). > > I'm waiting for Gordon to check-in his directory comparisons to > filecmp. Gordon? Looking at CVS, my stuff was there in filecmp revision 1.2 (+299 -38) and wiped out by 1.3 (+38 -299) which was done the following day. - Gordon From akuchlin at cnri.reston.va.us Thu Jun 29 14:25:19 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Thu, 29 Jun 2000 08:25:19 -0400 Subject: [Python-Dev] how do I build pyexpat? In-Reply-To: <395ACED5.83764D45@prescod.net>; from paul@prescod.net on Wed, Jun 28, 2000 at 09:21:41PM -0700 References: <14682.44979.673881.83798@bitdiddle.concentric.net> <395ACED5.83764D45@prescod.net> Message-ID: <20000629082519.A13839@newcnri.cnri.reston.va.us> On Wed, Jun 28, 2000 at 09:21:41PM -0700, Paul Prescod wrote: >I don't know where you got your expat or how new it is, but with the one >I got from the xml-sig, I can type >"make libexpat.a" That's a patch I made to the Makefile and submitted to James Clark. For Modules/Setup.in, I can change it to explicitly list the 8 files from Expat that need to be linked to. The problem is that one of the files will vary: # Use one of the next two lines; unixfilemap is better if it works. FILEMAP_OBJ=xmlwf/unixfilemap.o #FILEMAP_OBJ=xmlwf/readfilemap.o --amk From gward at mems-exchange.org Thu Jun 29 14:26:47 2000 From: gward at mems-exchange.org (Greg Ward) Date: Thu, 29 Jun 2000 08:26:47 -0400 Subject: [Python-Dev] OT: A Day in the Life of p5p In-Reply-To: <033a01bfe141$71b0cfc0$f2a6b5d4@hagrid>; from effbot@telia.com on Wed, Jun 28, 2000 at 10:42:56PM +0200 References: <033a01bfe141$71b0cfc0$f2a6b5d4@hagrid> Message-ID: <20000629082647.A27322@ludwig.cnri.reston.va.us> On 28 June 2000, Fredrik Lundh said: > it would be very nice if the file object could do something similar > internally (only in text mode, perhaps). maybe in 1.7? Oddly enough, I've been idly contemplating writing an extension type (hypothetically called "superfile") that makes most of Perl's file-handling semantics, and maybe some of the speedup, available in Python. At one level, it would be a rewrite of my 'text_file' module/TextFile class in C. But this is all speculation, mainly predicated on the theory that I *really* should be eating my own dogfood and distributing some Python extension, instead of just telling other people how to do it. ;-) Greg From gward at mems-exchange.org Thu Jun 29 14:33:39 2000 From: gward at mems-exchange.org (Greg Ward) Date: Thu, 29 Jun 2000 08:33:39 -0400 Subject: [Python-Dev] Text about cycle GC In-Reply-To: <14682.15020.589514.702145@bitdiddle.concentric.net>; from jeremy@beopen.com on Wed, Jun 28, 2000 at 01:49:32PM -0400 References: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com> <395A359A.2CF0CA70@prescod.net> <14682.15020.589514.702145@bitdiddle.concentric.net> Message-ID: <20000629083339.B27322@ludwig.cnri.reston.va.us> On 28 June 2000, Jeremy Hylton said: > PP> import cyclicgc > > PP> should turn on the -with-cycle-gc flag. > > The -with-cycle-gc flag is an option to configure when you build > Python. It can't be turned on or off at runtime. No, no, *obviously* Paul meant that "import cyclicgc" should configure and compile a new Python interpreter with "--with-cycle-gc" and 'exec()' it for you. What else would it mean? ;-) Greg (PS. if this were Perl, you could say use cyclegc; to turn it on, and then elsewhere in your code no cyclegc; to turn it off. Maybe Python needs an "unimport" command?) (Kidding!) From gward at mems-exchange.org Thu Jun 29 14:39:08 2000 From: gward at mems-exchange.org (Greg Ward) Date: Thu, 29 Jun 2000 08:39:08 -0400 Subject: [Python-Dev] ucnhash module In-Reply-To: <395A7E65.2271C723@lemburg.com>; from mal@lemburg.com on Thu, Jun 29, 2000 at 12:38:29AM +0200 References: <20000628205832.C3234E2673@oratrix.oratrix.nl> <395A7E65.2271C723@lemburg.com> Message-ID: <20000629083908.D27322@ludwig.cnri.reston.va.us> On 29 June 2000, M.-A. Lemburg said: > The ucnhash module is loaded on demand to avoid memory bloat. > In practice the difference is not really noticeable since > loading a shared module or swapping in a few pages of static > C data result in pretty much the same overall memory usage. > > If no-one complains, I'll fix the test suite though to make > the tests of the named Unicode characters optional. How 'bout a separate "test_ucn" to test this feature? ...of course, this is yet another case of language syntax features becoming optional and selectable at compile-time, which I still think is a bad idea. Hmmm. Greg From guido at beopen.com Thu Jun 29 15:39:59 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 29 Jun 2000 08:39:59 -0500 Subject: [Python-Dev] add Demo/imputil/importers.py ? In-Reply-To: Your message of "Thu, 29 Jun 2000 01:08:27 -0400." References: Message-ID: <200006291339.IAA09887@cj20424-a.reston1.va.home.com> > There's already an IDLE distribution distinct from Python's: > > http://www.python.org/idle/ > > Note that the IDLE 0.5 there is not what was shipped with 1.5.2; I'm not > clear on why that hasn't been updated to IDLE 0.6 already (suspect just lack > of time). Yes. > > Hmm... I guess that I don't much have an opinion one way or the other, but > > was mostly looking for clarification. > > I don't have a specific plan in mind either -- just "me too"ing on the idea > that it would do no harm and possibly do real good to let these peripheral > (to the core) things live on their own schedules. I don't see any harm in > including "the latest" snapshot of them with the core distribution, > though -- it's handy for newcomers to get these things without needing to > search for them. I know I learned a lot about Python at the start from > browsing these directories. Additionally, it's great for Python on Windows to come with a working GUI. Pythonwin may be more like Windows, but it's much more fragile than (recent versions of) IDLE in my experience. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at beopen.com Thu Jun 29 15:49:32 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 29 Jun 2000 08:49:32 -0500 Subject: [Python-Dev] PyString_GET_SIZE() In-Reply-To: Your message of "Wed, 28 Jun 2000 17:29:20 MST." <20000628172919.G29590@lyra.org> References: <200006282157.OAA05880@slayer.i.sourceforge.net> <20000628151758.X29590@lyra.org> <200006290111.UAA08357@cj20424-a.reston1.va.home.com> <20000628172919.G29590@lyra.org> Message-ID: <200006291349.IAA09962@cj20424-a.reston1.va.home.com> > Hmm. Is there a good place to start listing these todo items? One that we > can truly use for communicating this info? In Apache, we have a file named > STATUS that everybody uses for dropping ideas, patch references, critical > bugs, etc. As that file gets changed, we see it in the -checkins alias, so > everybody is aware of the suggested changes/problems/available patches/etc. > It also holds people's votes on particular changes. > > Can we institute something similar? Possibly Misc/STATUS? Should I post > Apache's STATUS file as an example? Possibly, but I'm somewhat skeptical. I used to have a large TODO file -- still have it -- but it's so full of long-term ideas that never happened that I rarely look in it any more. I never got into the discipline of using it for my day-to-day priorities -- it was more of a place to write down long-term ideas so I could forget about them. I'll append it. I appreciate a copy of Apache's STATUS file. --Guido van Rossum (home page: http://www.python.org/~guido/) NEW TODO LIST FOR 1.6 ===================== IDLE: set window class? socket/ssl version mystery UNIFIED TODO LIST ================= From effbot at telia.com Thu Jun 29 14:58:13 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 29 Jun 2000 14:58:13 +0200 Subject: [Python-Dev] PyString_GET_SIZE() References: <200006282157.OAA05880@slayer.i.sourceforge.net> <20000628151758.X29590@lyra.org> <200006290111.UAA08357@cj20424-a.reston1.va.home.com> <20000628172919.G29590@lyra.org> <200006291349.IAA09962@cj20424-a.reston1.va.home.com> Message-ID: <006201bfe1c9$b928d400$f2a6b5d4@hagrid> guido wrote: > > Hmm. Is there a good place to start listing these todo items? One that we > > can truly use for communicating this info? In Apache, we have a file named > > STATUS that everybody uses for dropping ideas, patch references, critical > > bugs, etc. As that file gets changed, we see it in the -checkins alias, so > > everybody is aware of the suggested changes/problems/available patches/etc. > > It also holds people's votes on particular changes. > > > > Can we institute something similar? Possibly Misc/STATUS? Should I post > > Apache's STATUS file as an example? > > Possibly, but I'm somewhat skeptical. I used to have a large TODO > file -- still have it -- but it's so full of long-term ideas that > never happened that I rarely look in it any more. instead of a file, I suggest taking a look at ?!ng's Roundup (once 1.6 final is out, of course). From guido at beopen.com Thu Jun 29 15:58:00 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 29 Jun 2000 08:58:00 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Doc TODO,1.26,1.27 In-Reply-To: Your message of "Thu, 29 Jun 2000 08:22:12 -0400." <1249841091-43777448@hypernet.com> References: <200006282213.PAA13365@slayer.i.sourceforge.net> <1249841091-43777448@hypernet.com> Message-ID: <200006291358.IAA10045@cj20424-a.reston1.va.home.com> > Moshe wrote: > > > On Wed, 28 Jun 2000, Fred L. Drake wrote: > > > > > + * Update the filecmp documentation (Moshe?). > > > > I'm waiting for Gordon to check-in his directory comparisons to > > filecmp. Gordon? > > Looking at CVS, my stuff was there in filecmp revision 1.2 > (+299 -38) and wiped out by 1.3 (+38 -299) which was done > the following day. Argh! An inappropriate side effect of Ping's cleanup -- thanks for catching this. Apparently Ping didn't do a CVS update before generating his diffs. I can restore version 1.2 easily, but I'm not sure what to do with /F's changes (1.3 -> 1.4). Gordon, can you look at this and suggest what to do? --Guido van Rossum (home page: http://www.python.org/~guido/) From mal at lemburg.com Thu Jun 29 15:04:24 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 29 Jun 2000 15:04:24 +0200 Subject: [Python-Dev] ucnhash module References: <20000628205832.C3234E2673@oratrix.oratrix.nl> <395A7E65.2271C723@lemburg.com> <20000629083908.D27322@ludwig.cnri.reston.va.us> Message-ID: <395B4958.C9909145@lemburg.com> Greg Ward wrote: > > On 29 June 2000, M.-A. Lemburg said: > > The ucnhash module is loaded on demand to avoid memory bloat. > > In practice the difference is not really noticeable since > > loading a shared module or swapping in a few pages of static > > C data result in pretty much the same overall memory usage. > > > > If no-one complains, I'll fix the test suite though to make > > the tests of the named Unicode characters optional. > > How 'bout a separate "test_ucn" to test this feature? Good idea. > ...of course, this is yet another case of language syntax features > becoming optional and selectable at compile-time, which I still think is > a bad idea. Hmmm. It's not selectable at run-time: either you have compiled the module or not. It is enabled per default. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Vladimir.Marangozov at inrialpes.fr Thu Jun 29 15:31:21 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Thu, 29 Jun 2000 15:31:21 +0200 (CEST) Subject: [Python-Dev] Text about cycle GC In-Reply-To: <200006282059.PAA04852@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Jun 28, 2000 03:59:46 PM Message-ID: <200006291331.PAA21571@python.inrialpes.fr> Guido van Rossum wrote: > > I wonder if we should turn this option *on* during beta testing? Why not, as long as --without-gc does not suffer from bugs hidden by --with-gc. > > That way we gather a lot more experience with its use! Maybe nobody > complains and we can leave it on in the final release... This is risky. We don't have enough experience with this implementation. All we know is that things get slower and consume more memory. Without a clear picture of the impact of this GC implementation, it's probably a bad idea to enable (i.e. impose) it by default. The "optional experimental feature" label is good and IMO it complies with anybody's expectations. Interested people will jump in and will eventually contribute with improvements, those who don't care won't and will live happily without it (at least until the day the feature and its implementation reach their expected maturity). -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From gmcm at hypernet.com Thu Jun 29 15:27:01 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Thu, 29 Jun 2000 09:27:01 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Doc TODO,1.26,1.27 In-Reply-To: <200006291358.IAA10045@cj20424-a.reston1.va.home.com> References: Your message of "Thu, 29 Jun 2000 08:22:12 -0400." <1249841091-43777448@hypernet.com> Message-ID: <1249837203-44011365@hypernet.com> [Gordon] > > Looking at CVS, my stuff was there in filecmp revision 1.2 > > (+299 -38) and wiped out by 1.3 (+38 -299) which was done the > > following day. [Guido] > Argh! An inappropriate side effect of Ping's cleanup -- thanks > for catching this. Apparently Ping didn't do a CVS update before > generating his diffs. > > I can restore version 1.2 easily, but I'm not sure what to do > with /F's changes (1.3 -> 1.4). Gordon, can you look at this and > suggest what to do? If you have the eff-bot's diff, it should apply to 1.2 (my changes are all below there - basically I added a rewritten dircmp). I think a CVS merge would do the right thing, too. - Gordon From mal at lemburg.com Thu Jun 29 15:33:36 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 29 Jun 2000 15:33:36 +0200 Subject: [Python-Dev] CVS locks on SF Message-ID: <395B5030.C0F08E82@lemburg.com> I'm getting loads of lock messages during CVS checkins recently. Is this due to overload ? (I wonder why anoncvs access causes locking at all -- there is no write access so why should there be file locking ?): [06:31:40] waiting for anoncvs_python's lock in /cvsroot/python/python/dist/src/Lib/test cvs server: [06:32:10] waiting for anoncvs_python's lock in /cvsroot/python/python/dist/src/Lib/test cvs server: [06:32:41] waiting for anoncvs_python's lock in /cvsroot/python/python/dist/src/Lib/test cvs server: [06:33:11] waiting for anoncvs_python's lock in /cvsroot/python/python/dist/src/Lib/test -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fdrake at beopen.com Thu Jun 29 15:52:40 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 29 Jun 2000 09:52:40 -0400 (EDT) Subject: [Python-Dev] how do I build pyexpat? In-Reply-To: <20000629082519.A13839@newcnri.cnri.reston.va.us> References: <14682.44979.673881.83798@bitdiddle.concentric.net> <395ACED5.83764D45@prescod.net> <20000629082519.A13839@newcnri.cnri.reston.va.us> Message-ID: <14683.21672.414396.364125@cj42289-a.reston1.va.home.com> Andrew Kuchling writes: > That's a patch I made to the Makefile and submitted to James Clark. > For Modules/Setup.in, I can change it to explicitly list the 8 files > from Expat that need to be linked to. The problem is that one of the It's not in the stable version I picked up last night; I'll dig up the experimental version today. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From paul at prescod.net Thu Jun 29 15:52:21 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 29 Jun 2000 06:52:21 -0700 Subject: [Python-Dev] Text about cycle GC References: <200006291331.PAA21571@python.inrialpes.fr> Message-ID: <395B5495.CF274583@prescod.net> Vladimir Marangozov wrote: > >... > > This is risky. We don't have enough experience with this implementation. > All we know is that things get slower and consume more memory. Without > a clear picture of the impact of this GC implementation, it's probably > a bad idea to enable (i.e. impose) it by default. Won't we have a clear picture by the end of the beta period? > The "optional experimental feature" label is good and IMO it complies > with anybody's expectations. Interested people will jump in and will > eventually contribute with improvements, those who don't care won't > and will live happily without it (at least until the day the feature > and its implementation reach their expected maturity). A million Window users will live unhappily without it because they don't know how to recompile to get it! -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From billtut at microsoft.com Thu Jun 29 15:54:21 2000 From: billtut at microsoft.com (Bill Tutt) Date: Thu, 29 Jun 2000 06:54:21 -0700 Subject: [Python-Dev] re: ucnhash Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD24F@RED-MSG-50> Re: ucnhash and where the stuff gets tested Doesn't matter to me where the test goes. WRT how big it is, thats why its dynamically loaded at run time. If you don't compile it at all, then the \N{...} syntax just won't owrk. Re: static vs. staticforward I can actually do a patch for that, and regen ucnhash.c for you. Re: "" vs. <> Whats wrong with what I'm currently doing? All of the .h files I'm including are on the include file path. "" usage just means stick "." before everything else in your include path. None of the files need that. :) If there's a diffferent policy in the Python source 'bout that that I'm not aware of, then I can fix that issue too. Bill From guido at beopen.com Thu Jun 29 17:03:36 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 29 Jun 2000 10:03:36 -0500 Subject: [Python-Dev] CVS locks on SF In-Reply-To: Your message of "Thu, 29 Jun 2000 15:33:36 +0200." <395B5030.C0F08E82@lemburg.com> References: <395B5030.C0F08E82@lemburg.com> Message-ID: <200006291503.KAA10324@cj20424-a.reston1.va.home.com> > I'm getting loads of lock messages during CVS checkins recently. > Is this due to overload ? (I wonder why anoncvs access causes > locking at all -- there is no write access so why should there > be file locking ?): I haven't seen this myself. Could be you were just unlucky. Could be someone was doing a full checkout over a slow connection. I think the anon checkouts still use (read) locks because they need to get a consistent version. --Guido van Rossum (home page: http://www.python.org/~guido/) From gstein at lyra.org Thu Jun 29 16:10:51 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 29 Jun 2000 07:10:51 -0700 Subject: [Python-Dev] STATUS files (was: PyString_GET_SIZE()) In-Reply-To: <200006291349.IAA09962@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jun 29, 2000 at 08:49:32AM -0500 References: <200006282157.OAA05880@slayer.i.sourceforge.net> <20000628151758.X29590@lyra.org> <200006290111.UAA08357@cj20424-a.reston1.va.home.com> <20000628172919.G29590@lyra.org> <200006291349.IAA09962@cj20424-a.reston1.va.home.com> Message-ID: <20000629071051.T29590@lyra.org> On Thu, Jun 29, 2000 at 08:49:32AM -0500, Guido van Rossum wrote: > > Hmm. Is there a good place to start listing these todo items? One that we > > can truly use for communicating this info? In Apache, we have a file named > > STATUS that everybody uses for dropping ideas, patch references, critical > > bugs, etc. As that file gets changed, we see it in the -checkins alias, so > > everybody is aware of the suggested changes/problems/available patches/etc. > > It also holds people's votes on particular changes. > > > > Can we institute something similar? Possibly Misc/STATUS? Should I post > > Apache's STATUS file as an example? > > Possibly, but I'm somewhat skeptical. I used to have a large TODO > file -- still have it -- but it's so full of long-term ideas that > never happened that I rarely look in it any more. I never got into > the discipline of using it for my day-to-day priorities -- it was more > of a place to write down long-term ideas so I could forget about > them. I'll append it. I appreciate a copy of Apache's STATUS file. Attached below... -- Greg Stein, http://www.lyra.org/ Apache 2.0 STATUS: Last modified at [$Date: 2000/06/28 11:41:14 $] Release: 2.0a5 : ??? 2.0a4 : released June 7, 2000 2.0a3 : released April 28, 2000 2.0a2 : released March 31, 2000 2.0a1 : released March 10, 2000 RELEASE SHOWSTOPPERS: * Win32: Get mod_auth_digest working under win32 - APR_HAS_RANDOM should be defined on windows and there is a lib/apr/misc/win32/rand.c which is basically a copy of what mod_auth_digest used to use. * Re-work configuration for top level Apache. Work should start with trying to clean the autoconf stuff. If and only if this proves impossible to do (very unlikely), autoconf should be removed and we will roll our own config implementation. * suEXEC doesn't work Status: Manoj has posted an patch to fix this. <19991103003605.A20612 at samosa.mindspring.com> * Win32: Enable the Windows MPM to honor max_requests_per_child Status: Bill will fix this. * Win32: Get Apache working on Windows 95/98. The following work (at least) needs to be done: - winnt MPM: Fix 95/98 code paths in the winnt MPM. There is some NT specific code that is still not in NT only code paths - IOL binds to APR sendfile, implemented with TransmitFile, which is not available on 95/98. * Win32: Test access logging with multiple threads. Will the native file I/O calls serialize automagically like the CRT calls or do we need to add region locking each time we access the logs? Status: * Win32: Complete the revamp the service environment and relocation into the WinNT MPM. Changes ServerRoot service registry parameter into ConfigArgs for multiple service startup parameters. Problems to fix in the revamp: -k shutdown/restart are broken, signals are not being acknowledged. Close window and shutdown also seem out of sorts. OtherBill is working on this * Win32: fix build/run time environment to remove ApacheCore.dll linkage from ab.exe and htdigest.exe. * We need a thread-safe resolver, at least on Unix. Status: The best known candidate would be something from BIND v9. Status: Greg asks, "why? doesn't gethostbyname_r() handle this?" * Modify mod_cgi and mod_cgid to deal with directories. This allows a lot of directives to be removed from the core. RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: * OS/2: Get loadable modules working again. Requires shared core support which doesn't appear to be catered for in the current build system. * OS/2: Make mod_status work for spmt_os2 MPM. * Build scripts do not recognise AIX 4.2.1 pthreads, so the pthread MPMs will not build. * Win32: Reuse accept socket after transmitfile/close This is not a bug, but would be nice to get this feature in before ship. * Win32: Enable the winnt MPM to use the new scoreboard API * Win32: Implement ap_shm_ functions in APR. * Win32: Win9x console window still won't play nice with the close window, logoff and shutdown scenarios. * Win32: Add a simple hold console open patch (wait for close or the ESC key, with a nice message) if the server died a bad death (non-zero exit code) in console mode. * Platforms that do not support fork (primarily Win32 and AS/400) Consider introducing HAVE_FORK feature macro. Architect start-up code that avoids initializing all the modules in the parent process on platforms that do not support fork. * Clean the code. There are a lot of places we used APR but didn't remove the hacks that were required for the cross-platform code in 1.3. We need to make the code look like APR was supposed to be there. * Go throught the 1.3 Bug DB and research the bugs marked "suspended". People were told these would be considered for inclusion in Apache 2.0, it would be nice to actually do so. * Win32: Migrate the MPM over to use APR thread/process calls. This would eliminate some code in the Win32 branch that essentially duplicates what is in APR. Bill says we need a new procattr, APR_CREATE_SUSPENDED (or something similar) to direct ap_create_process to create the process suspended. We also need a call to wake up the suspended process This may not be able to be implemented everywhere though. Status: * Move I/O layering into APR. * There are still a number of places in the code where we are loosing error status (i.e. throwing away the error returned by a system call and replacing it with a generic error code) * Win32: Implement reliable piped logs on Windows Status: * Use APR to get rid of more platform dependancies. Status: Ryan Bloom is working on this. * The connection status table is not very efficient. Also, very few stats are exported to the connection status table (easy to fix), and mod_status is ugly. * Mass vhosting version of suEXEC. * Replace tables with a proper opaque ADT that has pluggable implementations (including something like the existing data type, plus hash tables for speed, with options for more later). Status: fanf is working on this. * configuration option to use *DBM Status: Greg +1 (volunteers) * add SDBM into src/lib/sdbm/ as a default/fallback DBM implementation. SDBM is used by Perl, mod_dav, mod_sssl, others for basic DBM support. Status: Greg +1 (volunteers) * Integrate mod_dav. Message-id: <20000625173247.M29590 at lyra.org> Status: in process. - APR does not provide a couple needed things: chmod() and ap_finfo_t.st_dev. - expat-lite needs to be brought up to parity with the 1.3 vsn and inserted into the config/build process - SDBM needs to go into the config/build process - fix up include dirs to pick up expat-lite, sdbm, dav/main - APR-ization to the dav/fs/ stuff - case_preserved_filename stuff * ap_core_translate() and its use by mod_mmap_static are a bit wonky. The function should probably be exposed as a utility function (such as ap_translate_url2fs() or ap_validate_fs_url() or something). Another approach would be a new hook phase after "translate" which would allow mod_mmap_static to munge what the translation has decided to do. Status: Greg +1 (volunteers), Ryan +1 * Go through ap_config.h and namespace-protect the symbols (e.g. USE_*). Some symbols can/should move to mpm_common.h where possible. * Explore use of a post-config hook for the code in http_main.c which calls ap_fixup_virutal_hosts(), ap_fini_vhost_config(), and ap_sort_hooks() [to reduce the logic in main()] * read the config tree just once, and process N times (as necessary) * add a version number to ap_initialize() as an extra failsafe against (APR) library version skew. MsgID: Status: Greg +1 (volunteers), Jeff +1, Ryan +1, Tony -0(?) * mod_info to use the configuration tree * add output filtering. there are a couple variants for this. - The "link-based" variant is ready to go: MsgID: <20000627044436.N29590 at lyra.org> (patch) MsgID: <20000627053302.O29590 at lyra.org> (demo usage) MsgID: (problems with the patch) Status: Greg +1, Ryan -1 Other bugs that need fixing: * MaxRequestsPerChild measures connections, not requests. Until someone has a better way, we'll probably just rename it "MaxConnectionsPerChild". * Regex containers don't work in an intutive way Status: No one has come up with an efficient way to fix this behavior. Dean has suggested getting rid of regex containers completely. * SIGSEGV on Linux (glibc 2.1.2) isn't caught properly by a sigwaiting thread. We need to work around this, perhaps unless there is hope soon for a fixed glibc. * The mod_cgid daemon process isn't always cleaned up when httpd gets SIGTERM. Jeff thinks it may be as simple as registering the daemon process for cleanup with the proper pool, but he hasn't looked at it in enough detail. * The MM library is built as static and shared library. This should be set up to build only the required version. Other features that need writing: * Finish infrastructure in core for async MPMs Status: post 2.0 * TODO in source -- just do an egrep on "TODO" and see what's there Documentation that needs writing: * Mod_status docs are needed. * The concept of MPMs, especially if we ship more than one MPM for a given platform * New directives in the various MPMs and appropriate links from obsolete directives in core.html to the MPM documentation. * Revise manual/stopping.html and the last part of manual/misc/perf-tuning.html to take account of the MPMs. * API documentation Status: Ben Laurie has written some hooks documentation (apache-2.0/htdocs/hooks.html) * Changes since 1.3.9 can be more easily seen in the commitlog file dev.apache.org:/home/cvs/CVSROOT/commitlogs/apache-2.0 which includes some of Roy's comments when the changes were committed in rough change-sets by purpose. Note that the commitlog does not show the contents of new files until later. * mod_dav documentation (once integrated) Available Patches: * Mike Abbott's patches to improve performance Status: These were written for 1.3, and are awaiting a port to 2.0 * Jim Winstead's patch to add CookieDomain and other small mod_usertrack features Open issues: * What do we do about mod_proxy? * Which MPMs will be included with Apache 2.0? * Is conf/highperformance.conf-dist obsolete? It looks obsolete. From fredrik at pythonware.com Thu Jun 29 16:11:26 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Thu, 29 Jun 2000 16:11:26 +0200 Subject: [Python-Dev] Text about cycle GC References: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com> <395A359A.2CF0CA70@prescod.net> <14682.15020.589514.702145@bitdiddle.concentric.net> <395A3F62.EA1E8B89@prescod.net> <20000628122725.A13473@acs.ucalgary.ca> <200006282059.PAA04852@cj20424-a.reston1.va.home.com> Message-ID: <016a01bfe1d3$ea2474b0$0900a8c0@SPIFF> guido wrote: > I wonder if we should turn this option *on* during beta testing? +1 from me. > That way we gather a lot more experience with its use! Maybe nobody > complains and we can leave it on in the final release... I won't mind (unless it breaks my code, of course). From mal at lemburg.com Thu Jun 29 16:10:28 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 29 Jun 2000 16:10:28 +0200 Subject: [Python-Dev] re: ucnhash References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD24F@RED-MSG-50> Message-ID: <395B58D4.E52CBBD6@lemburg.com> Bill Tutt wrote: > > Re: ucnhash and where the stuff gets tested > > Doesn't matter to me where the test goes. I'm currently trying to check these changes in... doesn't work though due to some obscure CVS locks. > WRT how big it is, thats why its dynamically loaded at run time. > If you don't compile it at all, then the \N{...} syntax just won't owrk. > > Re: static vs. staticforward > I can actually do a patch for that, and regen ucnhash.c for you. Someone (Fred ?) already patches those places for you. He didn't send patches for the perfect hash tool though. > Re: "" vs. <> > Whats wrong with what I'm currently doing? <> uses a differnt header file lookup path... normally doesn't hurt, but... > All of the .h files I'm including are on the include file path. "" usage > just means stick "." before everything else in your include path. > None of the files need that. :) If there's a diffferent policy in the Python > source 'bout that that I'm not aware of, then I can fix that issue too. ... you already know that ;-) Again, these are already fixed :-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido at beopen.com Thu Jun 29 17:15:09 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 29 Jun 2000 10:15:09 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Doc TODO,1.26,1.27 In-Reply-To: Your message of "Thu, 29 Jun 2000 09:27:01 -0400." <1249837203-44011365@hypernet.com> References: Your message of "Thu, 29 Jun 2000 08:22:12 -0400." <1249841091-43777448@hypernet.com> <1249837203-44011365@hypernet.com> Message-ID: <200006291515.KAA10374@cj20424-a.reston1.va.home.com> > [Gordon] > > > Looking at CVS, my stuff was there in filecmp revision 1.2 > > > (+299 -38) and wiped out by 1.3 (+38 -299) which was done the > > > following day. > [Guido] > > Argh! An inappropriate side effect of Ping's cleanup -- thanks > > for catching this. Apparently Ping didn't do a CVS update before > > generating his diffs. > > > > I can restore version 1.2 easily, but I'm not sure what to do > > with /F's changes (1.3 -> 1.4). Gordon, can you look at this and > > suggest what to do? [Gordon] > If you have the eff-bot's diff, it should apply to 1.2 (my changes > are all below there - basically I added a rewritten dircmp). I > think a CVS merge would do the right thing, too. There was a change in indent style, so effbot's diff didn't apply cleanly -- but your suggestion made me realize that it was easy to re-apply manually. It's all fixed now. Thanks all! --Guido van Rossum (home page: http://www.python.org/~guido/) From mal at lemburg.com Thu Jun 29 16:15:23 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 29 Jun 2000 16:15:23 +0200 Subject: [Python-Dev] CVS locks on SF References: <395B5030.C0F08E82@lemburg.com> <200006291503.KAA10324@cj20424-a.reston1.va.home.com> Message-ID: <395B59FB.1CD472AE@lemburg.com> Guido van Rossum wrote: > > > I'm getting loads of lock messages during CVS checkins recently. > > Is this due to overload ? (I wonder why anoncvs access causes > > locking at all -- there is no write access so why should there > > be file locking ?): > > I haven't seen this myself. Could be you were just unlucky. Could be > someone was doing a full checkout over a slow connection. > > I think the anon checkouts still use (read) locks because they need to > get a consistent version. Looks like someone is using a 9.6kBaud mobile phone connection ;-) The problem still persists and I've been trying for about half an hour now. I'll try again later today... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido at beopen.com Thu Jun 29 17:21:47 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 29 Jun 2000 10:21:47 -0500 Subject: [Python-Dev] Text about cycle GC In-Reply-To: Your message of "Thu, 29 Jun 2000 06:52:21 MST." <395B5495.CF274583@prescod.net> References: <200006291331.PAA21571@python.inrialpes.fr> <395B5495.CF274583@prescod.net> Message-ID: <200006291521.KAA10440@cj20424-a.reston1.va.home.com> > Won't we have a clear picture by the end of the beta period? Not clear. Unfortunately, few people who run important apps will download a beta and try it. But they *will* download a new release labeled "final" and install it without making sure it works for their app. This has been my experience throughout Python's life. I've become pretty conservative about staying backwards compatible as a result... > > The "optional experimental feature" label is good and IMO it complies > > with anybody's expectations. Interested people will jump in and will > > eventually contribute with improvements, those who don't care won't > > and will live happily without it (at least until the day the feature > > and its implementation reach their expected maturity). > > A million Window users will live unhappily without it because they don't > know how to recompile to get it! This can be solved the way we solve everything for Windows users: give them two distributions to choose from -- or maybe one distribution with a checkbox to choose which version to use. --Guido van Rossum (home page: http://www.python.org/~guido/) From skip at mojam.com Thu Jun 29 15:38:20 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 29 Jun 2000 08:38:20 -0500 (CDT) Subject: [Python-Dev] Sourceforge Interface Concerns In-Reply-To: References: <20000628025304.BB64A1CE0D@dinsdale.python.org> Message-ID: <14683.20812.615266.196934@beluga.mojam.com> Andy> How many people here have actually created accounts for themselves Andy> on SourceForge and tried to do stuff when logged in - raise bugs Andy> and so on? Did it work for you? I've submitted a few patches with no problems. My usual connections are a corporate T1-ish connection or cable modem access from home, however. -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille O'Neal said: "He's got the rings. I listen to the man with the rings." From jeremy at beopen.com Thu Jun 29 16:45:27 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 29 Jun 2000 10:45:27 -0400 (EDT) Subject: [Python-Dev] how do I build pyexpat? In-Reply-To: <14683.21672.414396.364125@cj42289-a.reston1.va.home.com> References: <14682.44979.673881.83798@bitdiddle.concentric.net> <395ACED5.83764D45@prescod.net> <20000629082519.A13839@newcnri.cnri.reston.va.us> <14683.21672.414396.364125@cj42289-a.reston1.va.home.com> Message-ID: <14683.24839.650558.23732@bitdiddle.concentric.net> >>>>> "FLD" == Fred L Drake, writes: FLD> Andrew Kuchling writes: >> That's a patch I made to the Makefile and submitted to James >> Clark. For Modules/Setup.in, I can change it to explicitly list >> the 8 files from Expat that need to be linked to. The problem is >> that one of the FLD> It's not in the stable version I picked up last night; I'll FLD> dig up the experimental version today. I downloaded version 1.1 from the expat home page. The URL for the download is ftp://ftp.jclark.com/pub/xml/expat.zip. This version hasn't changed in the last two weeks. The instructions Fred include worked almost just right. I checked in the corrected ar command and it looks good. Jeremy From fdrake at beopen.com Thu Jun 29 16:46:48 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 29 Jun 2000 10:46:48 -0400 (EDT) Subject: [Python-Dev] CVS locks on SF In-Reply-To: <200006291503.KAA10324@cj20424-a.reston1.va.home.com> References: <395B5030.C0F08E82@lemburg.com> <200006291503.KAA10324@cj20424-a.reston1.va.home.com> Message-ID: <14683.24920.264911.840500@cj42289-a.reston1.va.home.com> Guido van Rossum writes: > I think the anon checkouts still use (read) locks because they need to > get a consistent version. Yes; you need a directory lock to avoid files getting modified or deleted underneath you while checking out/updating. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Thu Jun 29 16:48:38 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 29 Jun 2000 10:48:38 -0400 (EDT) Subject: [Python-Dev] re: ucnhash In-Reply-To: <395B58D4.E52CBBD6@lemburg.com> References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD24F@RED-MSG-50> <395B58D4.E52CBBD6@lemburg.com> Message-ID: <14683.25030.205960.13328@cj42289-a.reston1.va.home.com> M.-A. Lemburg writes: > Someone (Fred ?) already patches those places for you. He didn't > send patches for the perfect hash tool though. Not this Fred... -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Thu Jun 29 16:52:28 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 29 Jun 2000 10:52:28 -0400 (EDT) Subject: [Python-Dev] how do I build pyexpat? In-Reply-To: <14683.24839.650558.23732@bitdiddle.concentric.net> References: <14682.44979.673881.83798@bitdiddle.concentric.net> <395ACED5.83764D45@prescod.net> <20000629082519.A13839@newcnri.cnri.reston.va.us> <14683.21672.414396.364125@cj42289-a.reston1.va.home.com> <14683.24839.650558.23732@bitdiddle.concentric.net> Message-ID: <14683.25260.182929.808330@cj42289-a.reston1.va.home.com> Jeremy Hylton writes: > The instructions Fred include worked almost just right. I checked in > the corrected ar command and it looks good. That's what I get for typing in the dark on a dark keyboard. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one at email.msn.com Thu Jun 29 18:23:54 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 29 Jun 2000 12:23:54 -0400 Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163) In-Reply-To: <395b1528.5978476@smtp.worldonline.dk> Message-ID: [posted & mailed] [Tim] > id() has to return a unique value. [Finn Bock] > This property of id() does not hold in JPython. When used with hotspot, > id() is not unique. So it's possible there for one of these be true: id(x) == id(y) and x is not y id(x) != id(x) ? Then that's a bug in JPython or hotspot. Know which? Filed a bug report? In CPython, we just use the address of an object's header, and as CPython never moves an object's header in memory, the good stuff follows trivially. Don't know what JPython tries to do, but it's bound to be harder there (as Java can move memory around). From bckfnn at worldonline.dk Thu Jun 29 18:43:09 2000 From: bckfnn at worldonline.dk (Finn Bock) Date: Thu, 29 Jun 2000 16:43:09 GMT Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163) In-Reply-To: References: Message-ID: <395b79a7.31704869@smtp.worldonline.dk> [Tim] >So it's possible there for one of these be true: > > id(x) == id(y) and x is not y > id(x) != id(x) > >? Yes, the first. d = {} cnt = 0 for i in xrange(100000): s = "test" + `i` j = id(s) if d.has_key(j): cnt = cnt + 1 d[j] = s print cnt, "failures" Will print 500+ failures when run by JPython & JDK1.3 on win2k. >Then that's a bug in JPython or hotspot. Know which? JPython. > Filed a bug report? Years ago : http://www.python.org/jpython-bugs/incoming?id=118 >In CPython, we just use the address of an object's header, and as CPython >never moves an object's header in memory, the good stuff follows trivially. >Don't know what JPython tries to do, but it's bound to be harder there (as >Java can move memory around). That is also my guess. I cannot see what we can do about it, except inform users that not all python platform behave exactly the same. Which is why I brought it up. regards, finn From trentm at activestate.com Thu Jun 29 18:42:56 2000 From: trentm at activestate.com (Trent Mick) Date: Thu, 29 Jun 2000 09:42:56 -0700 Subject: [Python-Dev] arraymodule still broken? In-Reply-To: <009e01bfe1b3$c6cd4480$f2a6b5d4@hagrid> References: <009e01bfe1b3$c6cd4480$f2a6b5d4@hagrid> Message-ID: <20000629094256.A21926@activestate.com> On Thu, Jun 29, 2000 at 12:21:22PM +0200, Fredrik Lundh wrote: > just checked everything out and rebuilt, the exceptions > problem sure disappeared, but I still get this error: > > >>> import array > >>> array.array("H", [60000]) > Traceback (most recent call last): > File "", line 1, in ? > OverflowError: signed short integer is greater than maximum > > second opinion, anyone? > I think this is because we are in the middling state where all of my patches have not gotten in yet. I say this because this is what I get with my version that has all of my patches applied: Python 1.6a2 (#1, Jun 29 2000, 09:28:15) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> import array >>> array.array("H", [60000]) array('H', [60000]) >>> Specifically, I haven't looked for the issue. Is it alright if I look at this this weekend? Trent -- Trent Mick trentm at activestate.com From trentm at activestate.com Thu Jun 29 18:53:43 2000 From: trentm at activestate.com (Trent Mick) Date: Thu, 29 Jun 2000 09:53:43 -0700 Subject: [Python-Dev] build problems under MSVC 5.0 In-Reply-To: <008a01bfe1b1$e08a8a60$f2a6b5d4@hagrid> References: <008a01bfe1b1$e08a8a60$f2a6b5d4@hagrid> Message-ID: <20000629095343.B21926@activestate.com> On Thu, Jun 29, 2000 at 12:07:42PM +0200, Fredrik Lundh wrote: > Python\thread_nt.h(185) : error C2065: 'INT_PTR' : undeclared identifier > Python\thread_nt.h(185) : error C2146: syntax error : missing ';' before identifier 'rv' > Python\thread_nt.h(185) : error C2065: 'rv' : undeclared identifier > Python\thread_nt.h(186) : error C2143: syntax error : missing ';' before 'type' > Python\thread_nt.h(195) : error C2065: 'success' : undeclared identifier > This is a result of one of my patches. I was using MSVC 6.0, where INT_PTR is defined as you would expect. I did not realize that it was new to that version of the headers. BTW, INT_PTR, UINT_PTR, etc are the standard defines that I saw Microsoft suggesting in their Win64 docs. I don't like those names, because they are not portable. I should have used the (ANSI?) equivalents: intptr_t, uintptr_t. In fact, I *did* use those in some of my patches where the code portability was required (as obviously it is not in thread_*nt*.h). > in MSVC 5.0, _beginthread returns an "unsigned long" (this is also > how it's documented in MSDN). Yup. And in the Win64 headers _beginthread returns uintptr_t, which makes me wonder why I picked INT_PTR. > > I suggest changing the declaration in thread_nt.h to: > > #if _MSC_VER >= 1200 > INT_PTR rv; > #else > unsigned long rv; > #endif > As I said above, I acknowledge that I should not have used INT_PTR. Win32: unsigned long _beginthread() Win64: uintptr_t _beginthread() I think (am I wrong?) to generalize that the intention for both Win32 and Win64 is to have _beginthread return an unsigned pointer-sized integer: hence uintptr_t. This would eliminate the #ifdef but would require a typedef for uintptr_t on Win32. This can be done in PC/config.h (I already did this for intptr_t, because I needed *that* elsewhere.) Does this also need to be generalized to typedef uintptr_t whereever it is not defined, i.e. in the autoconf files. I can look at this this weekend, if that is soon enough. > on the other hand, the same docs claim that it returns -1 on errors. > doesn't exactly look like an unsigned long to me, but that's another > story... > Yes, strange. Trent -- Trent Mick trentm at activestate.com From effbot at telia.com Thu Jun 29 19:07:02 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 29 Jun 2000 19:07:02 +0200 Subject: [Python-Dev] build problems under MSVC 5.0 References: <008a01bfe1b1$e08a8a60$f2a6b5d4@hagrid> <20000629095343.B21926@activestate.com> Message-ID: <019e01bfe1ec$728c6c00$f2a6b5d4@hagrid> trent wrote: > I think (am I wrong?) to generalize that the intention for both Win32 and > Win64 is to have _beginthread return an unsigned pointer-sized integer: hence > uintptr_t. > > This would eliminate the #ifdef but would require a typedef for uintptr_t on > Win32. This can be done in PC/config.h (I already did this for intptr_t, > because I needed *that* elsewhere.) Does this also need to be generalized to > typedef uintptr_t whereever it is not defined, i.e. in the autoconf files. > > I can look at this this weekend, if that is soon enough. I suggest checking in the #ifdef as a stopgap measure, if you promise to come up with the right thing (whatever that is) in time for 1.6 final. Should I go ahead and check it in? From tim_one at email.msn.com Thu Jun 29 19:15:08 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 29 Jun 2000 13:15:08 -0400 Subject: [Python-Dev] CVS locks on SF In-Reply-To: <395B5030.C0F08E82@lemburg.com> Message-ID: [MAL] > I'm getting loads of lock messages during CVS checkins recently. > Is this due to overload ? (I wonder why anoncvs access causes > locking at all -- there is no write access so why should there > be file locking ?): IIRC, CVS maintains the illusion of being a multi-user system by using per-*directory* locks. That means it gives you the warm fuzzy feeling that you're being protected against (e.g.) getting an inconsistent snapshot while someone else is committing, but in fact you're not protected at all (inter-directory). It locks per-directory to ensure the integrity of its own data files, but users are subject to the luck of the draw. Note that Perl is maintained under (the commercial, alas) Perforce, which is one of the few SCMs to take multi-developer multi-directory issues seriously. So the good news is that when you see a CVS lock gripe, that means CVS is protecting itself from corruption. The bad news is that if we used a system that protected *us* against inconsistencies too, we'd probably see lock gripes even more often. From gmcm at hypernet.com Thu Jun 29 19:19:51 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Thu, 29 Jun 2000 13:19:51 -0400 Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163) In-Reply-To: References: <395b1528.5978476@smtp.worldonline.dk> Message-ID: <1249823239-44851587@hypernet.com> [Finn Bock] > > This property of id() does not hold in JPython. When used with > > hotspot, id() is not unique. [Tim] > So it's possible there for one of these be true: > > id(x) == id(y) and x is not y > id(x) != id(x) > > ? Then that's a bug in JPython or hotspot. Know which? Filed a > bug report? Oh, you silly boy. There are (by definition) no bugs in hotspot. it's-only-'cause-Guido's-a-weenie-that-Python-has-'em-ly y'rs - Gordon From tim_one at email.msn.com Thu Jun 29 19:44:45 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 29 Jun 2000 13:44:45 -0400 Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163) In-Reply-To: <395b79a7.31704869@smtp.worldonline.dk> Message-ID: [Finn Bock, says id() is buggy under JPython] [Tim] >> Filed a bug report? [Finn] > Years ago : > http://www.python.org/jpython-bugs/incoming?id=118 >> In CPython, we just use the address of an object's header, and as CPython >> never moves an object's header in memory, the good stuff follows >> trivially. Don't know what JPython tries to do, but it's bound to be >> harder there (as Java can move memory around). > That is also my guess. I cannot see what we can do about it, except > inform users that not all python platform behave exactly the same. Which > is why I brought it up. Well, neither Java's hashCode nor identityHashCode are correct implementations of Python's id(), so JPython's id() is simply wrong. I don't know anything about the internals of JPython. If there's a "choke point" for allocating Python objects, the quickest way out may be to add a write-once "id" field to each Python object under JPython, and simply fill it with an integer that's (safely) incremented by 1 on each allocation. Python doesn't guarantee you'll get the *same* id(x) across implementations, or even across runs under a single implementation, so the implementations of id() in CPython and JPython can do entirely different things. They have to meet the promises in the Python docs, though, and JPython's currently doesn't. From effbot at telia.com Thu Jun 29 19:51:32 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 29 Jun 2000 19:51:32 +0200 Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager References: <395A32FD.D3C58B23@prescod.net> <20000628173424.H29590@lyra.org> Message-ID: <025701bfe1f2$ab5b8420$f2a6b5d4@hagrid> greg wrote: > I think you are being paranoid :-) > > Consider that this same issue applies to all 5900 projects and 38000 > developers at SourceForge. VA Linux has a brand identity entirely built on > the trust and support of the Linux (and Open Source) communities. If they > blow away that trust, they are simply screwed. on the other hand, lots of people thought that dejanews would store usenet postings forever... http://salon.com/tech/log/2000/06/20/deja/index.html From pingster at ilm.com Thu Jun 29 19:47:13 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Thu, 29 Jun 2000 10:47:13 -0700 (PDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Doc TODO,1.26,1.27 In-Reply-To: <200006291358.IAA10045@cj20424-a.reston1.va.home.com> Message-ID: On Thu, 29 Jun 2000, Guido van Rossum wrote: > > Argh! An inappropriate side effect of Ping's cleanup -- thanks for > catching this. Apparently Ping didn't do a CVS update before > generating his diffs. My apologies! I'm pretty sure i did an update, but i must have left too long a gap during which 1.2 got checked in. You'd think somehow a version-control system would have noticed the inconsistency between ancestor versions... Anyway, very sorry for the trouble. Glad it appears to be cleared up now. -- ?!ng From effbot at telia.com Thu Jun 29 19:56:02 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 29 Jun 2000 19:56:02 +0200 Subject: [Python-Dev] id() on Win64 References: <20000628160743.A16262@acs.ucalgary.ca> Message-ID: <027101bfe1f3$4d478ae0$f2a6b5d4@hagrid> neil wrote: > [Greg Stein] > >Strictly speaking: the Long only occurs on Win64 platforms. > > > >I would guess that it is also possible on say, an Alpha running > >Linux. Presuming that has 64-bit pointers(?). > > I think the Alpha is okay. The problem is strange type models > were int is 32 bits and pointers are 64. AFAIK, the Alpha uses > 64 bits for both. is this true for linux alpha too? it's definitely true for tru64; we've been using python extensively on that platform since 1995: http://www.smhi.se/weather/satelitbilder/satellitbilder.htm (in swedish, but I suppose you all can figure out what it is anyway ;-) From gward at mems-exchange.org Thu Jun 29 19:55:25 2000 From: gward at mems-exchange.org (Greg Ward) Date: Thu, 29 Jun 2000 13:55:25 -0400 Subject: [Python-Dev] Test results of linuxaudiodev.c Message-ID: <20000629135525.A5221@ludwig.cnri.reston.va.us> Hi -- here are results from testing linuxaudiodev from the latest CVS Python 1.6. This is on a Dell Dimension with on-board audio hardware: the Yamaha YMF724 chipset. I'm using the ALSA 0.5.8a driver (the latest as of a week or two ago, and the only one that supports the YMF724). Bottom line: the test sound plays, but it sounds horrible when played by linuxaudiodev. If I do this: $ play Lib/test/audiotest.au then Cardinal Fang comes through loud and clear. ("play" is a shell script wrapper for "sox", writing to /dev/dsp.) But if I do this: $ ./python Lib/test/regrtest.py test_linuxaudiodev he's still audible (and at the same volume), but very scratchy. Sounds kind of like a very over-driven amp, or like a cheap car radio that somebody attacked with a knife. [...some time passes...] OK, I just tried it on another machine, also a Dell but with a different sound chip: the Crystal CS4232. I'm pretty sure this one is using the OSS drivers included with the kernel, which is probably the second most important difference after the chipset itself. Bottom line: it also sounds horrible. Greg -- Greg Ward - software developer gward at mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From bwarsaw at beopen.com Thu Jun 29 19:57:27 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Thu, 29 Jun 2000 13:57:27 -0400 (EDT) Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163) References: <395b79a7.31704869@smtp.worldonline.dk> Message-ID: <14683.36359.864478.495915@anthem.concentric.net> >>>>> "TP" == Tim Peters writes: TP> Well, neither Java's hashCode nor identityHashCode are correct TP> implementations of Python's id(), so JPython's id() is simply TP> wrong. I don't know anything about the internals of JPython. TP> If there's a "choke point" for allocating Python objects, the TP> quickest way out may be to add a write-once "id" field to each TP> Python object under JPython, and simply fill it with an TP> integer that's (safely) incremented by 1 on each allocation. TP> Python doesn't guarantee you'll get the *same* id(x) across TP> implementations, or even across runs under a single TP> implementation, so the implementations of id() in CPython and TP> JPython can do entirely different things. They have to meet TP> the promises in the Python docs, though, and JPython's TP> currently doesn't. I can't generate patches right now, but what you need to change is in __builtin__.java, the id() function. It should probably call object.id() which would fill in the monotonically incrementing id as Tim suggestions. One question is what to do about Java proxies. Currently built-in id() returns the identityHashCode() of the proxy object, which is just an Object. I'm not sure sticking the id in the wrapper is the right thing or not. -Barry From effbot at telia.com Thu Jun 29 20:18:26 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 29 Jun 2000 20:18:26 +0200 Subject: [Python-Dev] Re: sourceforge data (was: Let's use the SourceForge Patch Manager) References: <395A32FD.D3C58B23@prescod.net> <20000628173424.H29590@lyra.org> <025701bfe1f2$ab5b8420$f2a6b5d4@hagrid> <20000629110557.W29590@lyra.org> Message-ID: <02d901bfe1f6$720ca920$f2a6b5d4@hagrid> greg wrote: > > on the other hand, lots of people thought that dejanews > > would store usenet postings forever... > > Different problem space. They weren't holding people's data. well, they dropped a few thousand eff-bot postings ;-) > Worrying about it is a useless exercise, IMO. well, I'm not worried. but in the internet universe, strange things happen all the time... (checked out http://www.fuckedcompany.com/ lately?) ... btw, has anyone checked what's in: http://cvs.sourceforge.net/cvstarballs/python-cvsroot.tar.gz (with ping times somewhere around one second, it's too large for me to check out...) From effbot at telia.com Thu Jun 29 20:05:34 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 29 Jun 2000 20:05:34 +0200 Subject: [Python-Dev] OT: A Day in the Life of p5p References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> <20000628113505.C15643@ludwig.cnri.reston.va.us> Message-ID: <02cd01bfe1f4$a271cca0$f2a6b5d4@hagrid> greg wrote: > On 28 June 2000, Fredrik Lundh said: > > http://prometheus.frii.com/~gnat/yapc/2000-p5p.txt > > > > unfortunately, his "What is it with those Python fucks anyway" talk > > isn't posted... ;-) > > But the "Conclusion" of his "Lies We Tell" talk: > > Perl sucks. Use Python. > > Presumably tongue-in-cheek, but you never know... note that all lies he mentioned earlier in that talk was quoted; this one wasn't. in other words, it's a fact. but we already know that, don't we ;-) From bwarsaw at beopen.com Thu Jun 29 20:56:52 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Thu, 29 Jun 2000 14:56:52 -0400 (EDT) Subject: [Python-Dev] Test results of linuxaudiodev.c References: <20000629135525.A5221@ludwig.cnri.reston.va.us> Message-ID: <14683.39924.477408.233069@anthem.concentric.net> >>>>> "GW" == Greg Ward writes: GW> then Cardinal Fang comes through loud and clear. ("play" is a GW> shell script wrapper for "sox", writing to /dev/dsp.) But if GW> I do this: GW> $ ./python Lib/test/regrtest.py test_linuxaudiodev GW> he's still audible (and at the same volume), but very GW> scratchy. Sounds kind of like a very over-driven amp, or like GW> a cheap car radio that somebody attacked with a knife. I don't even get that. play works fine for me too, but on this Dell Optiplex GX110 with unknown sound chip set, test_linuxaudiodev gives me nothing. -Barry From gstein at lyra.org Thu Jun 29 20:05:57 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 29 Jun 2000 11:05:57 -0700 Subject: [Python-Dev] sourceforge data (was: Let's use the SourceForge Patch Manager) In-Reply-To: <025701bfe1f2$ab5b8420$f2a6b5d4@hagrid>; from effbot@telia.com on Thu, Jun 29, 2000 at 07:51:32PM +0200 References: <395A32FD.D3C58B23@prescod.net> <20000628173424.H29590@lyra.org> <025701bfe1f2$ab5b8420$f2a6b5d4@hagrid> Message-ID: <20000629110557.W29590@lyra.org> On Thu, Jun 29, 2000 at 07:51:32PM +0200, Fredrik Lundh wrote: > greg wrote: > > I think you are being paranoid :-) > > > > Consider that this same issue applies to all 5900 projects and 38000 > > developers at SourceForge. VA Linux has a brand identity entirely built on > > the trust and support of the Linux (and Open Source) communities. If they > > blow away that trust, they are simply screwed. > > on the other hand, lots of people thought that dejanews > would store usenet postings forever... Different problem space. They weren't holding people's data. If SourceForge were ever to close, then I have 100% faith that they would make sure to provide a way for everybody to get their data off the machines. Worrying about it is a useless exercise, IMO. Cheers, -g -- Greg Stein, http://www.lyra.org/ From guido at beopen.com Thu Jun 29 21:05:11 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 29 Jun 2000 14:05:11 -0500 Subject: [Python-Dev] CVS locks on SF In-Reply-To: Your message of "Thu, 29 Jun 2000 13:15:08 -0400." References: Message-ID: <200006291905.OAA17265@cj20424-a.reston1.va.home.com> > [MAL] > > I'm getting loads of lock messages during CVS checkins recently. > > Is this due to overload ? (I wonder why anoncvs access causes > > locking at all -- there is no write access so why should there > > be file locking ?): > > IIRC, CVS maintains the illusion of being a multi-user system by using > per-*directory* locks. That means it gives you the warm fuzzy feeling that > you're being protected against (e.g.) getting an inconsistent snapshot while > someone else is committing, but in fact you're not protected at all > (inter-directory). It locks per-directory to ensure the integrity of its > own data files, but users are subject to the luck of the draw. Yes, that's how it works... > Note that Perl is maintained under (the commercial, alas) Perforce, which is > one of the few SCMs to take multi-developer multi-directory issues > seriously. We tried Perforce at CNRI. It's really neat, but somehow it was lacking some stuff we were used to and we never converted. Note that Perforce is free for open source projects -- at least at the time it was. (CNRI paid a license fee, but that was just an expression of CNRI's reluctance against free software. :-) There's also bitkeeper. It stayed in beta so long that we gave up (and they have a weird license) -- but it's out of beta since May 4: see http://www.bitkeeper.com/. But there's no immediate download! You must sign up and they send you instructions in the mail... > So the good news is that when you see a CVS lock gripe, that means CVS is > protecting itself from corruption. The bad news is that if we used a system > that protected *us* against inconsistencies too, we'd probably see lock > gripes even more often. Well, the implementation could save the previous consistent version and give you that while an update was under way... There are other ways to protect against inconsistencies. But I'm not sure that you always *want* this -- as a system grows, it's better to be able to deal with inconsistencies than to try to avoid them (and have the world blow up in your face when the avoidance fails). Anyway, I submitted a service request to have the lock in the Lib/test lock removed. (Apparently some process didn't clear up its lock. That's rare, but sometimes it happens.) It's been fixed now, so checkins in the Lib/test directory should move forward again. --Guido van Rossum (home page: http://www.python.org/~guido/) From bckfnn at worldonline.dk Thu Jun 29 21:15:45 2000 From: bckfnn at worldonline.dk (Finn Bock) Date: Thu, 29 Jun 2000 19:15:45 GMT Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163) In-Reply-To: References: Message-ID: <395b9f71.41379240@smtp.worldonline.dk> [Tim] >Well, neither Java's hashCode nor identityHashCode are correct >implementations of Python's id(), so JPython's id() is simply wrong. I agree. >I don't know anything about the internals of JPython. If there's a "choke >point" for allocating Python objects, The constructor of PyObject should do nicely. >the quickest way out may be to add a >write-once "id" field to each Python object under JPython, and simply fill >it with an integer that's (safely) incremented by 1 on each allocation. Properly have to be a java long to avoid overflowing. >Python doesn't guarantee you'll get the *same* id(x) across implementations, >or even across runs under a single implementation, so the implementations of >id() in CPython and JPython can do entirely different things. They have to >meet the promises in the Python docs, though, and JPython's currently >doesn't. I haven't considered it to be so important. It is possible to fix the std modules so it doesn't cause problems (as is done in cPickle.java). [Barry] >One question is what to do about Java proxies. Currently built-in >id() returns the identityHashCode() of the proxy object, which is just >an Object. I'm not sure sticking the id in the wrapper is the right >thing or not. It properly isn't. New wrappers can be created for the same object. F.ex when a java object is passed from python into java code and returned back into python, two wrappers will exists for the same java object. Since these two wrappers represent the same object they should (as it does now) return the same id() value. regards, finn From bwarsaw at beopen.com Thu Jun 29 21:23:48 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Thu, 29 Jun 2000 15:23:48 -0400 (EDT) Subject: [Python-Dev] Re: sourceforge data (was: Let's use the SourceForge Patch Manager) References: <395A32FD.D3C58B23@prescod.net> <20000628173424.H29590@lyra.org> <025701bfe1f2$ab5b8420$f2a6b5d4@hagrid> <20000629110557.W29590@lyra.org> <02d901bfe1f6$720ca920$f2a6b5d4@hagrid> Message-ID: <14683.41540.530581.459708@anthem.concentric.net> >>>>> "FL" == Fredrik Lundh writes: FL> btw, has anyone checked what's in: FL> http://cvs.sourceforge.net/cvstarballs/python-cvsroot.tar.gz I suck down nightly copies of that file and the corresponding Mailman tarball. I looked at them when I first set up my script, but haven't checked them lately. -Barry From nascheme at enme.ucalgary.ca Thu Jun 29 22:02:02 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Thu, 29 Jun 2000 14:02:02 -0600 Subject: [Python-Dev] CVS locks on SF In-Reply-To: <200006291905.OAA17265@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jun 29, 2000 at 02:05:11PM -0500 References: <200006291905.OAA17265@cj20424-a.reston1.va.home.com> Message-ID: <20000629140201.A20446@acs.ucalgary.ca> I recently made the conversion from CVS to PRCS. I like PRCS much better. It is easier to use, implemented indepentant of rcs, faster, more flexible and has versioned project meta-data. Branching and merging is much simpiler than CVS. Operations on project versions are atomic. Renaming and moving files is easy. It is well documented. Unfortunately version 1 does not support distributed repositories. Josh has informed my that version to is coming (hopefully this year) and will support distributed repositories. For Python I don't think that a multi-user version control system is strictly necessary anyhow. The PRCS repository could be made available via rsync and a process could be setup for checking patches into the central repository. It should actually be more efficient than the current CVS setup. I just looked at the webpage and the beta for 2.0 is out: http://www.xcf.berkeley.edu/~jmacd/prcs.html If PythonLabs is interested in using PRCS I will even volunteer to make sure those Windows weenies have a good port. :) Neil From jeremy at beopen.com Thu Jun 29 22:40:14 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 29 Jun 2000 16:40:14 -0400 (EDT) Subject: [Python-Dev] CVS locks on SF In-Reply-To: <20000629140201.A20446@acs.ucalgary.ca> References: <200006291905.OAA17265@cj20424-a.reston1.va.home.com> <20000629140201.A20446@acs.ucalgary.ca> Message-ID: <14683.46126.19856.447975@bitdiddle.concentric.net> I was just looking at Josh's work last week, and thought it looks quite interesting. Despite my interest, I don't expect we would use it for Python unless SourceForge adopted it. We moved the Python CVS tree to SourceForge to avoid maintaing a large installation of software development/management tools. Jeremy From klm at digicool.com Thu Jun 29 22:53:21 2000 From: klm at digicool.com (Ken Manheimer) Date: Thu, 29 Jun 2000 16:53:21 -0400 (EDT) Subject: [Python-Dev] Wikis for todo lists, etc (was PyString_GET_SIZE()) In-Reply-To: Message-ID: On Thu, 29 Jun 2000, Tim Peters wrote: > > ... > > Hmm. Is there a good place to start listing these todo items? > > Not that I know of. "Group whiteboards" and shared journals etc are darned > useful, though. Wiki = Group whiteboard Zope could do a lot of this stuff well. As is, ZWiki offers some organizational features. I've held off on pushing them because they're still baking - things like change notifications, discretion about change privileges, versions (with differences, based on your ndiff.py), etc are coming soonish. (Exactly how soonish is hard to say, the way time and more direct business obligations are - but this stuff actually is important to us, we're using them a lot for collaboration, and need for the dynamics to scale...) I also have the feeling that our tracker would be good for patch management - except, i don't really know what the requirements are, there, and once again, tracker only gives notifications via email, it doesn't take input that way. Anyway, to see leads on both zwikis and tracker, see: http://www.zope.org/Members/klm/TrackerWiki Oh, and it would be easy to set up a wiki for python dev on zope.org somewhere - i could put it in my account, or we could situate one more centrally, in a storage that's never packed, so the version history is maintained. Or any of you could get a zope.org membership and set some up, yerselves. Or set up a zope somewhere - it'd be !cool! if sourceforge were willing... Ken klm at zope.org From klm at digicool.com Thu Jun 29 23:25:55 2000 From: klm at digicool.com (Ken Manheimer) Date: Thu, 29 Jun 2000 17:25:55 -0400 (EDT) Subject: [Python-Dev] Wikis for todo lists, etc (was PyString_GET_SIZE()) In-Reply-To: Message-ID: On Thu, 29 Jun 2000, Ken Manheimer wrote: > Wiki = Group whiteboard > [...] > Oh, and it would be easy to set up a wiki for python dev on zope.org > somewhere - i could put it in my account, or we could situate one more http://www.zope.org/Members/klm/PythonDev/TodoLists There's nothing else of substance there, but anyone who's a member at zope.org can edit and add pages... Ken From guido at python.org Fri Jun 30 01:25:09 2000 From: guido at python.org (Guido van Rossum) Date: Thu, 29 Jun 2000 18:25:09 -0500 Subject: [Python-Dev] New PythonLabs site revealed! Message-ID: <200006292325.SAA19744@cj20424-a.reston1.va.home.com> Today, without much fanfare, we opened the new PythonLabs website. The design is by BeOpen's creative Director, Jun Simmons. Thanks to Jeremy Hylton, who did most of the actual HTML editing to get our contents in place. The new beta will be released via this site. And since you python-dev folks will find this out through my checkins anyway, let this be an advance warning that it will be called Python 2.0. Here's my explanation for the version bump (soon to be checked in to README): """ While Pythoneers have grown fond of Python's exceedingly slow version incrementing, that same quality makes parts of the rest of the world think Python is barely out of its first alpha test. Especially enterprise customers are often fearful of anything that's version 1.x! The new version number also clearly marks Python's departure from CNRI. Previously, the version number 2.0 was associated with a mythical and elusive incompatible future release. That release (still ways off, and not as incompatible as people fear!) is now referred to as Python 3000. """ --Guido van Rossum (home page: http://www.python.org/~guido/) From mwh21 at cam.ac.uk Fri Jun 30 00:53:39 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 29 Jun 2000 23:53:39 +0100 Subject: [Python-Dev] Test results of linuxaudiodev.c In-Reply-To: Greg Ward's message of "Thu, 29 Jun 2000 13:55:25 -0400" References: <20000629135525.A5221@ludwig.cnri.reston.va.us> Message-ID: Greg Ward writes: > Hi -- > > here are results from testing linuxaudiodev from the latest CVS Python > 1.6. This is on a Dell Dimension with on-board audio hardware: the > Yamaha YMF724 chipset. I'm using the ALSA 0.5.8a driver (the latest as > of a week or two ago, and the only one that supports the YMF724). > > Bottom line: the test sound plays, but it sounds horrible when played by > linuxaudiodev. If I do this: > > $ play Lib/test/audiotest.au > > then Cardinal Fang comes through loud and clear. ("play" is a shell > script wrapper for "sox", writing to /dev/dsp.) But if I do this: > > $ ./python Lib/test/regrtest.py test_linuxaudiodev > > he's still audible (and at the same volume), but very scratchy. Sounds > kind of like a very over-driven amp, or like a cheap car radio that > somebody attacked with a knife. > > [...some time passes...] > > OK, I just tried it on another machine, also a Dell but with a different > sound chip: the Crystal CS4232. I'm pretty sure this one is using the > OSS drivers included with the kernel, which is probably the second most > important difference after the chipset itself. Bottom line: it also > sounds horrible. Just tried that here; ouch. I have a Dell Dimension XPS D233 (which has an on-board Yamaha chipset - the OPL2, I believe). I use the sound driver that comes with the redhat built kernel (which is the OSS one I think). $ play audiotest.au sounds fine, $ ../../../build/python regrtest.py test_linuxaudiodev.py \ test_linuxaudiodev sounds horrible; it sounds like it's being rammed through at far too high a volume, but playing with the PCM or volume sliders in gmix has no appreciable effect on the quality. This suggests somewhat that the problem lies in linuxaudiodev.c, doesn't it? Is this stuff, like, documented anywhere? I can't find any helpful manpages... I presume this module must work better than this for some people? Cheers, M. From guido at python.org Fri Jun 30 02:20:15 2000 From: guido at python.org (Guido van Rossum) Date: Thu, 29 Jun 2000 19:20:15 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils msvccompiler.py,1.33,1.34 In-Reply-To: Your message of "Thu, 29 Jun 2000 16:05:01 MST." <200006292305.QAA11929@slayer.i.sourceforge.net> References: <200006292305.QAA11929@slayer.i.sourceforge.net> Message-ID: <200006300020.TAA21877@cj20424-a.reston1.va.home.com> > On second thought, first try for _winreg, and then winreg. Only if both > fail do we try for win32api/win32con. If *those* both fail, then we don't > have registry access. Phew! Is this smart? Doesn't the new winreg have a very different I/F than the old one? --Guido van Rossum (home page: http://www.python.org/~guido/) From pingster at ilm.com Fri Jun 30 01:24:28 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Thu, 29 Jun 2000 16:24:28 -0700 (PDT) Subject: [Python-Dev] Test results of linuxaudiodev.c In-Reply-To: Message-ID: On 29 Jun 2000, Michael Hudson wrote: > $ play audiotest.au > > sounds fine, > > $ ../../../build/python regrtest.py test_linuxaudiodev.py \ > test_linuxaudiodev > > sounds horrible; it sounds like it's being rammed through at far too > high a volume Sounds like u-law to me. linuxaudiodev.c selects /dev/dsp by default, which accepts raw data, not .au format. Try setting the environment variable AUDIODEV to /dev/audio before running the test script. Does that work any better? -- ?!ng From fdrake at beopen.com Fri Jun 30 01:29:42 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 29 Jun 2000 19:29:42 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils msvccompiler.py,1.33,1.34 In-Reply-To: <200006300020.TAA21877@cj20424-a.reston1.va.home.com> References: <200006292305.QAA11929@slayer.i.sourceforge.net> <200006300020.TAA21877@cj20424-a.reston1.va.home.com> Message-ID: <14683.56294.836295.923883@cj42289-a.reston1.va.home.com> Greg Ward wrote in a checkin message: > On second thought, first try for _winreg, and then winreg. Only if both > fail do we try for win32api/win32con. If *those* both fail, then we don't > have registry access. Phew! Guido van Rossum writes on python-dev: > Is this smart? Doesn't the new winreg have a very different I/F than > the old one? No, this is bad. It *will* break with winreg; if _winreg isn't available, it should use the win32api/win32con/whatever stuff; it's a Python 1.5.2 interpreter at that point. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From skip at mojam.com Fri Jun 30 00:22:18 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 29 Jun 2000 17:22:18 -0500 (CDT) Subject: [Python-Dev] Mysterious SF message... Message-ID: <14683.52250.789900.357275@beluga.mojam.com> I just submitted a patch for lib/libatexit.tex. In the response page it displayed a list of patches, then the following cryptic message: Patch Uploaded Successfully Added Patch Could Not Send Patch Update Any idea what that means? -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille O'Neal said: "He's got the rings. I listen to the man with the rings." From tim_one at email.msn.com Fri Jun 30 01:32:42 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 29 Jun 2000 19:32:42 -0400 Subject: [Python-Dev] Controversial patch (cmath) Message-ID: I just voted to accept a patch that's broken. If you want to argue it, be my guest, but I'm out of it now . Here's the patch: https://sourceforge.net/patch/?func=detailpatch&patch_id=100651&group_id=547 0 Here's my comment (also available on that page): Accepted (but reluctantly; see below), and assigned back to Guido for checkin. cmathmodule is not production quality, and this patch isn't either, but its asinh and acosh are better than what's there now. The author avoided some of the numerical foolishness in the original, but didn't avoid all of it. For example, it's harder to get asinh to do something ridiculous now than it was before, but still possible: >>> cmath.acosh(1e200) (461.210165779+0j) >>> cmath.asinh(1e200) (1.#INF+0j) >>> asinh should have returned something approximately equal to what acosh returned. That may not be the patch's problem, though! I suspect that's due to one of the module's other functions that's too naive about the limits of floating point. In any case, it is much easier to provoke the *current* cmath functions into cases like this one. Another possible problem has to do with principal values. My reference books are in storage, so about the best I can do right now is compare what this code does to Macsyma (which I have on my laptop). The acosh in this patch often returns the negative of what Macysma computes. For example, >>> cmath.acosh(-1-1j) (1.06127506191-2.23703575929j) >>> Macsyma returns the negation of that. On the other hand, the *original* acosh doesn't agree with Macsyma on some signs where this acosh does. So call this one a wash. I may have mentioned this before : robust math libraries are extremely difficult to get right. It would take several months to write a production-quality cmath module from scratch, which is several months more than were devoted to Python's current cmath . I vote we check this in anyway (since it *is*, overall, an improvement), and look into borrowing some other language's complex math library later (note in particular that C9X adds complex numbers and these functions on them, so if we sit on our asses long enough, we can inherit libc's!). From mwh21 at cam.ac.uk Fri Jun 30 01:33:37 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 30 Jun 2000 00:33:37 +0100 Subject: [Python-Dev] Test results of linuxaudiodev.c In-Reply-To: Ka-Ping Yee's message of "Thu, 29 Jun 2000 16:24:28 -0700 (PDT)" References: Message-ID: Ka-Ping Yee writes: > On 29 Jun 2000, Michael Hudson wrote: > > $ play audiotest.au > > > > sounds fine, > > > > $ ../../../build/python regrtest.py test_linuxaudiodev.py \ > > test_linuxaudiodev > > > > sounds horrible; it sounds like it's being rammed through at far too > > high a volume > > Sounds like u-law to me. linuxaudiodev.c selects /dev/dsp by > default, which accepts raw data, not .au format. > > Try setting the environment variable AUDIODEV to /dev/audio > before running the test script. Does that work any better? That's the ticket. "play" and the test now sound identical, modulo some pops & cracks at the start and end of the test. I presume what follows is thus a good idea? Index: test_linuxaudiodev.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/test/test_linuxaudiodev.py,v retrieving revision 1.1 diff -u -r1.1 test_linuxaudiodev.py --- test_linuxaudiodev.py 2000/06/10 04:22:57 1.1 +++ test_linuxaudiodev.py 2000/06/29 23:32:55 @@ -17,4 +17,6 @@ def test(): play_sound_file(findfile('audiotest.au')) +os.environ["AUDIODEV"] = "/dev/audio" + test() Cheers, M. From Vladimir.Marangozov at inrialpes.fr Fri Jun 30 01:38:19 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Fri, 30 Jun 2000 01:38:19 +0200 (CEST) Subject: [Python-Dev] New PythonLabs site revealed! In-Reply-To: <200006292325.SAA19744@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Jun 29, 2000 06:25:09 PM Message-ID: <200006292338.BAA07798@python.inrialpes.fr> Guido van Rossum wrote: > > Today, without much fanfare, we opened the new PythonLabs website. > The design is by BeOpen's creative Director, Jun Simmons. Thanks to > Jeremy Hylton, who did most of the actual HTML editing to get our > contents in place. > > The new beta will be released via this site. > > And since you python-dev folks will find this out through my checkins > anyway, let this be an advance warning that it will be called Python > 2.0. Here's my explanation for the version bump (soon to be checked > in to README): Guido van Rossum just won't stop surprising us! :-) Witness the three shocking news that arrived in one day: (1) very strict self-discipline about "long-term" TODO's full of short-term and less than medium-term topics that were very logically left behind, (2) major version number revision one day before the official beta-cycle, (3) a new PythonLabs corporate-style Web site with a flashing color palette & tutti quanti. I am really (positively) amazed! :-) spanish-inquisition-is-all-we-deserve--ly y'rs -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From fdrake at beopen.com Fri Jun 30 01:39:48 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 29 Jun 2000 19:39:48 -0400 (EDT) Subject: [Python-Dev] documentation patch guidelines Message-ID: <14683.56900.433607.125111@cj42289-a.reston1.va.home.com> I've updated the patch guidelines for documentation to match other patches, and added a patch category for documentation. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From pingster at ilm.com Fri Jun 30 01:46:32 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Thu, 29 Jun 2000 16:46:32 -0700 (PDT) Subject: [Python-Dev] Test results of linuxaudiodev.c In-Reply-To: Message-ID: On Thu, 29 Jun 2000, Ka-Ping Yee wrote: > Try setting the environment variable AUDIODEV to /dev/audio > before running the test script. Does that work any better? Even if that works, i realize that's not the way the interface was intended to be used. To play an AU file, the routine should look something like this (not tested, as i don't have a working Linux box)... def play_au_file(path): fp = open(path, "r") # Read the .au file header. header = fp.read(24) hdrsize, length, encoding, rate, channels = \ struct.unpack(">xxxxiiiii", header) fp.read(hdrsize - 24) data = fp.read() fp.close() # Set the data format according to the code in the .au header. if encoding == 1: size, fmt = 8, linuxaudiodev.AFMT_MU_LAW elif encoding == 2: size, fmt = 8, linuxaudiodev.AFMT_S8 elif encoding == 3: size, fmt = 16, linuxaudiodev.AFMT_S16_BE else: raise "audio format not supported" dsp = linuxaudiodev.open("w") dsp.setparameters(rate, size, channels, fmt) dsp.write(data) dsp.close() -- ?!ng Explicit hoc totum; This completes the whole; Pro Christo da mihi potum. For Christ's sake give me a drink. -- from the colophon of a 12th-century copyist From nascheme at enme.ucalgary.ca Fri Jun 30 02:00:37 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Thu, 29 Jun 2000 18:00:37 -0600 Subject: [Python-Dev] Mysterious SF message... In-Reply-To: <14683.52250.789900.357275@beluga.mojam.com>; from skip@mojam.com on Thu, Jun 29, 2000 at 05:22:18PM -0500 References: <14683.52250.789900.357275@beluga.mojam.com> Message-ID: <20000629180037.A22566@acs.ucalgary.ca> On Thu, Jun 29, 2000 at 05:22:18PM -0500, Skip Montanaro wrote: > > I just submitted a patch for lib/libatexit.tex. In the response page it > displayed a list of patches, then the following cryptic message: > > Patch Uploaded Successfully Added Patch Could Not Send Patch Update > > Any idea what that means? SourceForge sucks? Seriously though, I think it means: Patch Uploaded Successfully, Added Patch, Could Not Send Patch Update For some reason it couldn't email out the patch update URL. Neil From mwh21 at cam.ac.uk Fri Jun 30 02:06:04 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 30 Jun 2000 01:06:04 +0100 Subject: [Python-Dev] Test results of linuxaudiodev.c In-Reply-To: Ka-Ping Yee's message of "Thu, 29 Jun 2000 16:46:32 -0700 (PDT)" References: Message-ID: Ka-Ping Yee writes: > On Thu, 29 Jun 2000, Ka-Ping Yee wrote: > > Try setting the environment variable AUDIODEV to /dev/audio > > before running the test script. Does that work any better? > > Even if that works, i realize that's not the way the interface > was intended to be used. To play an AU file, the routine should > look something like this (not tested, as i don't have a working > Linux box)... [snip] Yup, that works fine. Don't understand the details - and as I have my graduation ceremony tomorrow I'm going to go to bed and leave learning them until some other occasion! Cheers, M. PS: my Lib/test/test_linuxaudiodev.py is now this: from test_support import verbose, findfile, TestFailed import linuxaudiodev import os,struct def play_au_file(path): fp = open(path, "r") # Read the .au file header. header = fp.read(24) hdrsize, length, encoding, rate, channels = \ struct.unpack(">xxxxiiiii", header) fp.read(hdrsize - 24) data = fp.read() fp.close() # Set the data format according to the code in the .au header. if encoding == 1: size, fmt = 8, linuxaudiodev.AFMT_MU_LAW elif encoding == 2: size, fmt = 8, linuxaudiodev.AFMT_S8 elif encoding == 3: size, fmt = 16, linuxaudiodev.AFMT_S16_BE else: raise "audio format not supported" dsp = linuxaudiodev.open("w") dsp.setparameters(rate, size, channels, fmt) dsp.write(data) dsp.close() def test(): play_au_file(findfile('audiotest.au')) test() ... which is an improvement on what's there now. From pingster at ilm.com Fri Jun 30 02:44:35 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Thu, 29 Jun 2000 17:44:35 -0700 (PDT) Subject: [Python-Dev] Test results of linuxaudiodev.c In-Reply-To: Message-ID: On 30 Jun 2000, Michael Hudson wrote: > Yup, that works fine. Don't understand the details - and as I have my > graduation ceremony tomorrow I'm going to go to bed and leave learning > them until some other occasion! Cool. Okay, i just discovered sunau.py. Here's my real shot at test_linuxaudiodev.py. Can you give this a try? ---- test_linuxaudiodev.py ---- from test_support import verbose, findfile, TestFailed import linuxaudiodev import os, sunau formats = {("ULAW", 1): linuxaudiodev.AFMT_MU_LAW, ("NONE", 1): linuxaudiodev.AFMT_S8, ("NONE", 2): linuxaudiodev.AFMT_S16_BE} def play_au_file(path): au = sunau.open(path, "r") data = au.readframes(sunau.AUDIO_UNKNOWN_SIZE) au.close() spec = (au.getcomptype(), au.getsampwidth()) if not has_key(formats, spec): raise "audio format not supported by linuxaudiodev" dsp = linuxaudiodev.open("w") dsp.setparameters(au.getframerate(), au.getsampwidth() * 8, au.getnchannels(), formats[spec]) dsp.write(data) dsp.close() def test(): play_au_file(findfile('audiotest.au')) test() ---- test_linuxaudiodev.py ---- -- ?!ng From gstein at lyra.org Fri Jun 30 03:03:11 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 29 Jun 2000 18:03:11 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib sre.py,1.9,1.10 sre_compile.py,1.7,1.8 sre_constants.py,1.7,1.8 sre_parse.py,1.7,1.8 In-Reply-To: <200006291238.FAA01061@slayer.i.sourceforge.net>; from effbot@users.sourceforge.net on Thu, Jun 29, 2000 at 05:38:48AM -0700 References: <200006291238.FAA01061@slayer.i.sourceforge.net> Message-ID: <20000629180311.I29590@lyra.org> Fredrik, Something you are doing is forcing CVS to issue a new revision for some of those files, even when you are not changing them. These "false" revisions are probably not a good thing. Could you review your checkin process to see what is up? I would guess that you have the "-f" option in your commit line. Cheers, -g On Thu, Jun 29, 2000 at 05:38:48AM -0700, Fredrik Lundh wrote: > Update of /cvsroot/python/python/dist/src/Lib > In directory slayer.i.sourceforge.net:/tmp/cvs-serv899/Lib > > Modified Files: > sre.py sre_compile.py sre_constants.py sre_parse.py > Log Message: > > > - make sure group names are valid identifiers > (closes the "SRE: symbolic reference" bug) > > Index: sre.py > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Lib/sre.py,v > retrieving revision 1.9 > retrieving revision 1.10 > diff -C2 -r1.9 -r1.10 > > Index: sre_compile.py > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Lib/sre_compile.py,v > retrieving revision 1.7 > retrieving revision 1.8 > diff -C2 -r1.7 -r1.8 > > Index: sre_constants.py > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Lib/sre_constants.py,v > retrieving revision 1.7 > retrieving revision 1.8 > diff -C2 -r1.7 -r1.8 > > Index: sre_parse.py > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Lib/sre_parse.py,v > retrieving revision 1.7 > retrieving revision 1.8 > diff -C2 -r1.7 -r1.8 > *** sre_parse.py 2000/06/29 11:34:27 1.7 > --- sre_parse.py 2000/06/29 12:38:45 1.8 > *************** > *** 169,172 **** > --- 169,190 ---- > return this > > + def isident(char): > + return "a" <= char <= "z" or "A" <= char <= "Z" or char == "_" > + > + def isdigit(char): > + return "0" <= char <= "9" > + > + def isname(name): > + # check that group name is a valid string > + # FIXME: this code is really lame. should use a regular > + # expression instead, but I seem to have certain bootstrapping > + # problems here ;-) > + if not isident(name[0]): > + return 0 > + for char in name: > + if not isident(char) and not isdigit(char): > + return 0 > + return 1 > + > def _group(escape, state): > # check if the escape string represents a valid group > *************** > *** 419,425 **** > if char == ">": > break > - # FIXME: check for valid character > name = name + char > group = 1 > elif source.match("="): > # named backreference > --- 437,444 ---- > if char == ">": > break > name = name + char > group = 1 > + if not isname(name): > + raise error, "illegal character in group name" > elif source.match("="): > # named backreference > *************** > *** 523,540 **** > char = s.get() > if char is None: > ! raise error, "unterminated index" > if char == ">": > break > - # FIXME: check for valid character > name = name + char > if not name: > ! raise error, "bad index" > try: > index = int(name) > except ValueError: > try: > index = pattern.groupindex[name] > except KeyError: > ! raise IndexError, "unknown index" > a((MARK, index)) > elif len(this) > 1 and this[1] in DIGITS: > --- 542,560 ---- > char = s.get() > if char is None: > ! raise error, "unterminated group name" > if char == ">": > break > name = name + char > if not name: > ! raise error, "bad group name" > try: > index = int(name) > except ValueError: > + if not isname(name): > + raise error, "illegal character in group name" > try: > index = pattern.groupindex[name] > except KeyError: > ! raise IndexError, "unknown group name" > a((MARK, index)) > elif len(this) > 1 and this[1] in DIGITS: > > > _______________________________________________ > Python-checkins mailing list > Python-checkins at python.org > http://www.python.org/mailman/listinfo/python-checkins -- Greg Stein, http://www.lyra.org/ From akuchlin at cnri.reston.va.us Fri Jun 30 03:29:41 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Thu, 29 Jun 2000 21:29:41 -0400 Subject: [Python-Dev] Removing modules Message-ID: <20000629212941.A21563@newcnri.cnri.reston.va.us> For the "deleted modules" section of the 2.0 article, I drew up a list of modules that might be outdated, mostly the SGI-specific ones. Are those modules still useful, and do the libraries they were written for still exist? For your cogitation, here's the list: sgimodule.c, glmodule.c (and hence cgenmodule.c), imgfile.c, svmodule.c, flmodule.c, fmmodule.c, almodule.c, clmodule.c, knee.py. Also, can someone explain why importing a third party extension built for Python 1.5.x is supposed to result in an immediate crash on Windows? I'd like to explain why this happens... --amk From guido at python.org Fri Jun 30 05:13:13 2000 From: guido at python.org (Guido van Rossum) Date: Thu, 29 Jun 2000 22:13:13 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib sre.py,1.9,1.10 sre_compile.py,1.7,1.8 sre_constants.py,1.7,1.8 sre_parse.py,1.7,1.8 In-Reply-To: Your message of "Thu, 29 Jun 2000 18:03:11 MST." <20000629180311.I29590@lyra.org> References: <200006291238.FAA01061@slayer.i.sourceforge.net> <20000629180311.I29590@lyra.org> Message-ID: <200006300313.WAA22134@cj20424-a.reston1.va.home.com> > Fredrik, > > Something you are doing is forcing CVS to issue a new revision for some of > those files, even when you are not changing them. These "false" revisions > are probably not a good thing. > > Could you review your checkin process to see what is up? I would guess that > you have the "-f" option in your commit line. > > Cheers, > -g Greg, we already know why this is. It's the $ID$. --Guido van Rossum (home page: http://www.python.org/~guido/) From mhammond at skippinet.com.au Fri Jun 30 04:49:06 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Fri, 30 Jun 2000 12:49:06 +1000 Subject: [Python-Dev] Removing modules In-Reply-To: <20000629212941.A21563@newcnri.cnri.reston.va.us> Message-ID: > Also, can someone explain why importing a third party extension built > for Python 1.5.x is supposed to result in an immediate crash on > Windows? I'd like to explain why this happens... The 1.5 module is linked against Python15.dll. When Python.exe (linked against Python16.dll) starts up, it initializes the Python data structures in Python16.dll. When Python then imports foo.pyd (linked against Python15.dll), it immediately tries to call the functions in that DLL (such as getting the thread state). As Python has not been initialized in that DLL, we immediately die. Ironically, if Python1x.dll was simply named "Python.dll", there is a _reasonable_ chance it would work fine. The cost of doing this tho, is that you can not have Python 1.5 and Python 1.6 "side by side" on the same machine. There are a few possibilities for magic tricks we could pull, but to be honest Im not too inclined to bother with them myself... They would also require a commitment to a fully backwards compatible C API, which I dont think we can afford to commit to! Mark. From gward at python.net Fri Jun 30 05:30:03 2000 From: gward at python.net (Greg Ward) Date: Thu, 29 Jun 2000 23:30:03 -0400 Subject: [Python-Dev] Hey! who changed sys.platform?! Message-ID: <20000629233003.A1766@beelzebub> Curses! I just noticed that sys.platform in 1.6a2 (and the latest CVS from this morning) returns "linux2" on my PC, not "linux-i386". As I recall this decision is made in the configure script. Does anyone know why it changed? This is not the end of the world, but the OS name alone is not really enough on a multi-architecture OS... ...back to calling os.uname() myself, I guess. ;-( Greg -- Greg Ward - programmer-at-big gward at python.net http://starship.python.net/~gward/ God made machine language; all the rest is the work of man. From fdrake at beopen.com Fri Jun 30 05:33:45 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 29 Jun 2000 23:33:45 -0400 (EDT) Subject: [Python-Dev] Hey! who changed sys.platform?! In-Reply-To: <20000629233003.A1766@beelzebub> References: <20000629233003.A1766@beelzebub> Message-ID: <14684.5401.518766.362678@cj42289-a.reston1.va.home.com> Greg Ward writes: > I just noticed that sys.platform in 1.6a2 (and the latest CVS from this > morning) returns "linux2" on my PC, not "linux-i386". As I recall this I didn't know it ever returned linux-i386; perhaps you're thinking of Marc-Andre's platform module? -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From trentm at activestate.com Fri Jun 30 05:34:17 2000 From: trentm at activestate.com (Trent Mick) Date: Thu, 29 Jun 2000 20:34:17 -0700 Subject: [Python-Dev] Controversial patch (cmath) In-Reply-To: References: Message-ID: <20000629203417.B23077@activestate.com> [Tim discusses god awful math details] Would you want to foward this to python-list to see if any lurking mathematicians might be spurred to action? Trent -- Trent Mick trentm at activestate.com From gward at python.net Fri Jun 30 05:53:34 2000 From: gward at python.net (Greg Ward) Date: Thu, 29 Jun 2000 23:53:34 -0400 Subject: [Python-Dev] Hey! who changed sys.platform?! In-Reply-To: <14684.5401.518766.362678@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Thu, Jun 29, 2000 at 11:33:45PM -0400 References: <20000629233003.A1766@beelzebub> <14684.5401.518766.362678@cj42289-a.reston1.va.home.com> Message-ID: <20000629235334.B1294@beelzebub> On 29 June 2000, Fred L. Drake, Jr. said: > I didn't know it ever returned linux-i386; perhaps you're thinking > of Marc-Andre's platform module? D'ohh! That appears to be an artifact of Red Hat's build -- I was using /usr/bin/python (theirs), not /usr/local/bin/python (mine). $ /usr/bin/python Python 1.5.2 (#1, Feb 1 2000, 16:32:16) [GCC egcs-2.91.66 19990314/Linux (egcs- on linux-i386 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> sys.platform 'linux-i386' Sorry for getting alarmist. Guess I never should have started using sys.platform in the first place (or just not worry about getting the CPU in there too). Greg -- Greg Ward - geek gward at python.net http://starship.python.net/~gward/ Support bacteria -- it's the only culture some people have! From skip at mojam.com Fri Jun 30 04:57:47 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 29 Jun 2000 21:57:47 -0500 (CDT) Subject: [Python-Dev] available to look at bugs and patches... Message-ID: <14684.3243.480545.880199@beluga.mojam.com> Barry added me as a developer yesterday. Those people assigning bugs and patches can use me as a resource... Skip From gward at python.net Fri Jun 30 06:26:20 2000 From: gward at python.net (Greg Ward) Date: Fri, 30 Jun 2000 00:26:20 -0400 Subject: [Python-Dev] ANNOUNCE: Distutils 0.9 Message-ID: <20000630002620.A2329@beelzebub> Python Distribution Utilities release 0.9 June 29, 2000 The Python Distribution Utilities, or Distutils for short, are a collection of modules that aid in the development, distribution, and installation of Python modules. (It is intended that ultimately the Distutils will grow up into a system for distributing and installing whole Python applications, but for now their scope is limited to module distributions.) The Distutils are a standard part of Python 2.0; if you are running 2.0 (or one of the 1.6 alpha releases that preceded it), you don't need to install the Distutils separately. This release is primarily so that you can add the Distutils to a Python 1.5.2 installation -- you will then be able to install modules that require the Distutils, or use the Distutils to distribute your own modules. More information is available at the Distutils web page: http://www.python.org/sigs/distutils-sig/ and in the README.txt included in the Distutils source distribution. You can download the Distutils from http://www.python.org/sigs/distutils-sig/download.html Trivial patches can be sent to me (Greg Ward) at gward at python.net. Larger patches should be discussed on the Distutils mailing list: distutils-sig at python.org. From tim_one at email.msn.com Fri Jun 30 07:05:32 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 30 Jun 2000 01:05:32 -0400 Subject: [Python-Dev] Controversial patch (cmath) In-Reply-To: <20000629203417.B23077@activestate.com> Message-ID: [Trent Mick] > [Tim discusses god awful math details] > Would you want to foward this to python-list to see if any lurking > mathematicians might be spurred to action? God, please no! This requires a numerical analyst, not a mathematician. Voting by talented amateurs is only going to make things worse <0.5 wink>. I was an NA in a previous life, and know what needs to be done to resolve all this. But that takes way more time than we have before 2.0b1. The patch in question makes life better for the world's only known user of cmath . may-as-well-ask-c.l.py-to-discuss-python's-version-number-ly y'rs - tim From jeremy at beopen.com Fri Jun 30 07:08:30 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 30 Jun 2000 01:08:30 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Include objimpl.h,2.16,2.17 In-Reply-To: <200006300502.WAA03256@slayer.i.sourceforge.net> References: <200006300502.WAA03256@slayer.i.sourceforge.net> Message-ID: <14684.11086.47325.776691@bitdiddle.concentric.net> These patches should catch up with Neil's latest submissions, but may not have the very latest changes suggested by Neil and Vladimir. I will double-check with them in the morning. I will also change configure.in to enable GC by default for the beta test phase, unless there is strong objection. Jeremy From skip at mojam.com Fri Jun 30 06:00:29 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 29 Jun 2000 23:00:29 -0500 (CDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test/output test_gc,NONE,1.1 In-Reply-To: <200006300502.WAA03286@slayer.i.sourceforge.net> References: <200006300502.WAA03286@slayer.i.sourceforge.net> Message-ID: <14684.7005.661874.713000@beluga.mojam.com> Jeremy> Log Message: Jeremy> final patches from Neil Schemenauer for garbage collection Jeremy> --- NEW FILE --- Jeremy> test_gc Jeremy> list 0x831a754 Jeremy> dict 0x831a754 ... Jeremy> dict 0x831a9bc Jeremy> func 0x831d9e4 I can all but guarantee you this test will always fail. Printing absolute machine addresses (via calls to id() in this case) in test cases should be verboten. -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille O'Neal said: "He's got the rings. I listen to the man with the rings." From trentm at activestate.com Fri Jun 30 08:05:50 2000 From: trentm at activestate.com (Trent Mick) Date: Thu, 29 Jun 2000 23:05:50 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/PCbuild python16.dsp,1.6,1.7 In-Reply-To: <200006300502.WAA03275@slayer.i.sourceforge.net> References: <200006300502.WAA03275@slayer.i.sourceforge.net> Message-ID: <20000629230550.A24811@activestate.com> On Thu, Jun 29, 2000 at 10:02:55PM -0700, Jeremy Hylton wrote: > Update of /cvsroot/python/python/dist/src/PCbuild > In directory slayer.i.sourceforge.net:/tmp/cvs-serv3220/PCbuild > > Modified Files: > python16.dsp > Log Message: > final patches from Neil Schemenauer for garbage collection > > > Index: python16.dsp > =================================================================== > RCS file: /cvsroot/python/python/dist/src/PCbuild/python16.dsp,v > retrieving revision 1.6 > retrieving revision 1.7 > diff -C2 -r1.6 -r1.7 > *** python16.dsp 2000/06/06 23:29:09 1.6 > --- python16.dsp 2000/06/30 05:02:53 1.7 > *************** > *** 660,663 **** > --- 660,677 ---- > # End Source File > # Begin Source File > + SOURCE=..\Modules\gcmodule.c > + > + !IF "$(CFG)" == "python16 - Win32 Release" > + > + !ELSEIF "$(CFG)" == "python16 - Win32 Debug" > + > + !ELSEIF "$(CFG)" == "python16 - Win32 Alpha Debug" > + > + !ELSEIF "$(CFG)" == "python16 - Win32 Alpha Release" > + > + !ENDIF > + > + # End Source File > + # Begin Source File > > SOURCE=..\Python\getargs.c > Pardon me if I am wrong (I have not actually checked the repository) but is this correct now that the version number is 2.0? Trent -- Trent Mick trentm at activestate.com From trentm at activestate.com Fri Jun 30 08:27:33 2000 From: trentm at activestate.com (Trent Mick) Date: Thu, 29 Jun 2000 23:27:33 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test README,NONE,1.1 In-Reply-To: <200006300608.XAA13124@slayer.i.sourceforge.net> References: <200006300608.XAA13124@slayer.i.sourceforge.net> Message-ID: <20000629232733.D24811@activestate.com> Cool On Thu, Jun 29, 2000 at 11:08:38PM -0700, Skip Montanaro wrote: > > --- NEW FILE --- > Writing Python Test Cases > ------------------------- > Skip Montanaro > > > To run the entire test suite, make the "test" target at the top level: > > cd ... > make test This is a UN*Xism, on Windows and UN*X: cd ...\Lib\test python regrtest.py A sample walk through to create a test might make it more approachable for people. As well, it would be helpful to mention test_support.{verbose|TESTFN|...}. But I have no right to bitch about good work. Trent -- Trent Mick trentm at activestate.com From tim_one at email.msn.com Fri Jun 30 08:39:15 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 30 Jun 2000 02:39:15 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test README,NONE,1.1 In-Reply-To: <20000629232733.D24811@activestate.com> Message-ID: [Trent Mick] > ... > But I have no right to bitch about good work. How do you figure that? We do it to you enough . BTW, I'd just like to say what a delight it is to work with *all* of you folks! I wanted to say that before I can be accused of pimping for my employer -- so far, BeOpen hasn't paid me a dime, so you know my opinion hasn't yet been bought. well-maybe-on-credit-ly y'rs - tim From tim_one at email.msn.com Fri Jun 30 08:39:12 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 30 Jun 2000 02:39:12 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/PCbuild python16.dsp,1.6,1.7 In-Reply-To: <20000629230550.A24811@activestate.com> Message-ID: [Trent Mick, on Guido's late-night (for him ) checkin of python16.dsp] > Pardon me if I am wrong (I have not actually checked the > repository) but is this correct now that the version number is 2.0? No, it is not, and the Windows build is slightly damaged now. I've already yelled at Guido about this, but I suspect he's asleep. I'm sure it will get sorted out in the morning. From trentm at activestate.com Fri Jun 30 08:52:47 2000 From: trentm at activestate.com (Trent Mick) Date: Thu, 29 Jun 2000 23:52:47 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test README,NONE,1.1 In-Reply-To: References: <20000629232733.D24811@activestate.com> Message-ID: <20000629235247.A25090@activestate.com> On Fri, Jun 30, 2000 at 02:39:15AM -0400, Tim Peters wrote: > BTW, I'd just like to say what a delight it is to work with *all* of you > folks! I feel a group hug coming on in the morning. Or maybe I am just moved by the beer that I had for dinner. :) Likewise, Tim. As my first foray into community development I find this, Python dev, a refreshing pleasure. Trent -- Trent Mick trentm at activestate.com From tim_one at email.msn.com Fri Jun 30 09:41:28 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 30 Jun 2000 03:41:28 -0400 Subject: [Python-Dev] Wikis for todo lists, etc (was PyString_GET_SIZE()) In-Reply-To: Message-ID: [Tim] > ... "Group whiteboards" and shared journals etc are darned > useful, though. [Ken Manheimer] > Wiki = Group whiteboard Ya, I kind of picked that up from your last passionate advertisement for this stuff . Not knocking it! Never tried it. Believe it or not, I spend as little time on the web as possible. After I've gotten into a place to live here, and this current release crunch is behind us, I'm definitely going to check out your leads. For the past several years my development group worked thru Lotus Notes, which I didn't much care for at the time, but I'm increasingly realizing just how essential group-modifiable shared persistent documents were to our productivity. Notes is the purest example of a whole being greater than the sum of its parts I've ever seen (lousy mail system, lousy database, lousy change manager, lousy bug tracker, lousy workflow manager, worse than lousy native scripting ... but they all sucked in ways that were downright synergistic <0.9 wink>). > ... > Anyway, to see leads on both zwikis and tracker, see: > > http://www.zope.org/Members/klm/TrackerWiki can-beopen-zwiki-2.0-be-far-behind?-ly y'rs - tim From pingster at ilm.com Fri Jun 30 10:21:08 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Fri, 30 Jun 2000 01:21:08 -0700 (PDT) Subject: [Python-Dev] New PythonLabs site revealed! In-Reply-To: <200006292338.BAA07798@python.inrialpes.fr> Message-ID: Guido van Rossum wrote: > let this be an advance warning that it will be called Python 2.0. On Fri, 30 Jun 2000, Vladimir Marangozov wrote: > Guido van Rossum just won't stop surprising us! :-) Will many be spooked by the jump in version number into fearing incompatibility with older scripts...? I wonder if we'll end up trying to persuade the user community that the changes are small ("no, don't worry, your scripts will still work") and yet big ("honest, it really deserves to be called 2.0, it's not just a ploy") at the same time. Perl 5 was basically incompatible with Perl 4. Some things run, but a lot don't. (Actually many microversions of Perl 5 were mutually incompatible with each other, but i'll ignore that. :) ) I've thought of the jump to Python3k (lowercase "k", please) much like the Perl-4-to-Perl-5 jump: simple stuff is still okay but a lot of guts have changed. If i hadn't been "on the inside" watching development activity, i might expect something of similar magnitude upon hearing of going from Python 1.x to 2.0. I guess we can point at Unicode and SRE as big things. -- ?!ng From effbot at telia.com Fri Jun 30 10:33:10 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 30 Jun 2000 10:33:10 +0200 Subject: [Python-Dev] SRE status report Message-ID: <005001bfe26d$d3dc3540$f2a6b5d4@hagrid> just checked in a test script for sre. the test_sre file is a copy of test_re, with some minor changes: -- disabled one test (caused by bug #8; see below) -- added T (template mode, experimental, unsupported) and U (unicode locale) flags to the flag test -- removed keyword arguments in pattern test loop: result = obj.search(s, pos=result.start(0), endpos=result.end(0)+1) was changed to: result = obj.search(s, result.start(0), result.end(0)+1) as far as I can tell, the docs don't mention anything about keyword arguments... -- added unicode pattern / target string / locale tests to the pattern test loop. however, the current version SRE doesn't fully pass the test. here's an annotated version of Lib/test/output/test_sre: 1) test_support -- test failed re module pickle 2) test_support -- test failed re module cPickle under SRE, patterns are C objects, not class instances. to allow pickling, I need to modify copy_reg (either by modifing the file itself, or by updating the registry when SRE is first imported). see patch #100650 for more info, 3) === Syntax error: ('(?Pa)(?P=foo_123)', 'aa', 0, 'g1', 'a') this is a bug in the SRE parser. should be easy to fix. 4) === Failed incorrectly ('^(.+)?B', 'AB', 0, 'g1', 'A') this is a bug in the engine (nested repetitions). needs further research. 5) === Failed incorrectly ('(a+)+\\1', 'aa', 0, 'found+"-"+g1', 'aa-a') this is a bug in the engine or in the parser. needs further research. 6) === grouping error ('([^/]*/)*sub1/', 'd:msgs/tdir/sub1/trial/away.cpp', 0, 'found+"-"+g1', 'd:msgs/tdir/sub1/-tdir/') 'd:msgs/tdir/sub1/-trial/' should be 'd:msgs/tdir/sub1/-tdir/' same as #5. 7) === Syntax error: ('(?Paa)(?P=id)', 'aaaa', 0, 'found+"-"+id', 'aaaa-aa') same as #3. 8) === grouping error ('([abc])*bcd', 'abcd', 0, 'found+"-"+g1', 'abcd-a') 'abcd-c' should be 'abcd-a' this is a bug in the engine. should be easy to fix, I think. in fact, I could have sworn that I'd fixed it already. 9) === grouping error ('(?i)([abc])*bcd', 'ABCD', 0, 'found+"-"+g1', 'ABCD-A') 'ABCD-C' should be 'ABCD-A' same as #8 10) === Syntax error: ('a(?!b).', 'abad', 0, 'found', 'ad') this is bug in the parser. should be easy to fix. 11) === Syntax error: ('a(?=d).', 'abad', 0, 'found', 'ad') same as (or at least related to) #10 12) === Syntax error: ('a(?=c|d).', 'abad', 0, 'found', 'ad') same as #11 13) === Failed incorrectly ('^(.+)?B', 'AB', 0, 'g1', 'A') same as #4 (literally!). ... fwiw, *all* RE-based code I've played with seem to work. ymmv. let me know asap if it does. From mhammond at skippinet.com.au Fri Jun 30 10:41:44 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Fri, 30 Jun 2000 18:41:44 +1000 Subject: [Python-Dev] New PythonLabs site revealed! In-Reply-To: Message-ID: > Will many be spooked by the jump in version number into fearing > incompatibility with older scripts...? > > I wonder if we'll end up trying to persuade the user community that > the changes are small ("no, don't worry, your scripts will still > work") and yet big ("honest, it really deserves to be called 2.0, > it's not just a ploy") at the same time. I see your concerns, but I think the trick is to be honest, just as Guido was. We simply say it was bumped to V2 for the reasons of percieved maturity, and a clear break from CNRI Python. Both seem reasonable. I believe many people will simply wait for some form of consensus on the newsgroup, regardless of the version number. Personally, Im a little - umm - lets just say that I can see the irony in the fact that I recently changed a few bits of code that were dependent on a hard-coded "Python15.dll" to work not only with 1.6, but _all_ of the 1.x family. I figured there was no point trying to predict the packaging details of the 2.x family, seeing it as still some time off. Nothing like foresight :-) And-"foresight"-isnt-an-excuse-for-Tim-to-get-back-on-the-topic-of-his-geni tals--ly, Mark. From effbot at telia.com Fri Jun 30 10:55:01 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 30 Jun 2000 10:55:01 +0200 Subject: [Python-Dev] New PythonLabs site revealed! References: Message-ID: <005801bfe270$e140d440$f2a6b5d4@hagrid> mark wrote: > Personally, Im a little - umm - lets just say that I can see the irony in > the fact that I recently changed a few bits of code that were dependent on > a hard-coded "Python15.dll" to work not only with 1.6, but _all_ of the 1.x > family. heh. you're not the only one... btw, now that we're bumping to 2.0, maybe we can break socket.connect and friends once again? if somebody com- plains, just tell them "it's a major release, dammit" ;-) From gstein at lyra.org Fri Jun 30 10:59:56 2000 From: gstein at lyra.org (Greg Stein) Date: Fri, 30 Jun 2000 01:59:56 -0700 Subject: [Python-Dev] CVS locks on SF In-Reply-To: <200006291905.OAA17265@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jun 29, 2000 at 02:05:11PM -0500 References: <200006291905.OAA17265@cj20424-a.reston1.va.home.com> Message-ID: <20000630015956.S29590@lyra.org> On Thu, Jun 29, 2000 at 02:05:11PM -0500, Guido van Rossum wrote: >... > > Note that Perl is maintained under (the commercial, alas) Perforce, which is > > one of the few SCMs to take multi-developer multi-directory issues > > seriously. > > We tried Perforce at CNRI. It's really neat, but somehow it was > lacking some stuff we were used to and we never converted. > > Note that Perforce is free for open source projects -- at least at the > time it was. (CNRI paid a license fee, but that was just an > expression of CNRI's reluctance against free software. :-) > > There's also bitkeeper. It stayed in beta so long that we gave up > (and they have a weird license) -- but it's out of beta since May 4: > see http://www.bitkeeper.com/. But there's no immediate download! > You must sign up and they send you instructions in the mail... And coming down the pipe (end of the year) is Subversion: http://subversion.tigris.org/ Cheers, -g -- Greg Stein, http://www.lyra.org/ From mhammond at skippinet.com.au Fri Jun 30 11:23:53 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Fri, 30 Jun 2000 19:23:53 +1000 Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/PCbuild readme.txt,1.5,1.6 In-Reply-To: <200006300904.CAA04151@slayer.i.sourceforge.net> Message-ID: > Making a tiny change to figure out what I'm going to screw up > by trying to use CVS under Windows at all ... Congratulations :-) Mark. From mhammond at skippinet.com.au Fri Jun 30 11:25:39 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Fri, 30 Jun 2000 19:25:39 +1000 Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/PCbuild readme.txt,1.5,1.6 In-Reply-To: Message-ID: > To: python-dev at python.org Damn damn damn - did it again. Sorry. [I wishing mailing-lists would agree on how they handle reply-to :-] Mark. From mal at lemburg.com Fri Jun 30 11:27:57 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 30 Jun 2000 11:27:57 +0200 Subject: [Python-Dev] Hey! who changed sys.platform?! References: <20000629233003.A1766@beelzebub> <14684.5401.518766.362678@cj42289-a.reston1.va.home.com> Message-ID: <395C681D.C3211F6@lemburg.com> "Fred L. Drake, Jr." wrote: > > Greg Ward writes: > > I just noticed that sys.platform in 1.6a2 (and the latest CVS from this > > morning) returns "linux2" on my PC, not "linux-i386". As I recall this > > I didn't know it ever returned linux-i386; perhaps you're thinking > of Marc-Andre's platform module? Python has returned 'linux2' on my machine ever since I moved to a 2.x kernel -- why should it return 'linux-i386' (without any indication of version) ? As Fred mentioned, you should probably use platform.py to access the information you have in mind. It supports loads of different architectures and has pretty much all the information you need for distutils warpped in nice APIs. Why not simply include it in distutils ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From effbot at telia.com Fri Jun 30 12:04:00 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 30 Jun 2000 12:04:00 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Tools/perfecthash GenUCNHash.py,1.1,1.2 References: <200006300953.CAA14782@slayer.i.sourceforge.net> Message-ID: <00b001bfe27a$845f7880$f2a6b5d4@hagrid> MAL wrote: > out.write(header) > out = open(cFileName, "w") > ! out.write("#include "%s"\n" % headerFileName) > out.write(code) > perfHash.generate_graph(out) umm. I suppose you meant: > ! out.write('#include "%s"\n' % headerFileName) or possibly: > ! out.write("#include \"%s\"\n" % headerFileName) From mal at lemburg.com Fri Jun 30 12:15:23 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 30 Jun 2000 12:15:23 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Tools/perfecthash GenUCNHash.py,1.1,1.2 References: <200006300953.CAA14782@slayer.i.sourceforge.net> <00b001bfe27a$845f7880$f2a6b5d4@hagrid> Message-ID: <395C733B.4E2AFFA3@lemburg.com> Fredrik Lundh wrote: > > MAL wrote: > > out.write(header) > > out = open(cFileName, "w") > > ! out.write("#include "%s"\n" % headerFileName) > > out.write(code) > > perfHash.generate_graph(out) > > umm. I suppose you meant: > > > ! out.write('#include "%s"\n' % headerFileName) > > or possibly: > > > ! out.write("#include \"%s\"\n" % headerFileName) Oops, you're right. Thanks. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fdrake at beopen.com Fri Jun 30 15:20:23 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 30 Jun 2000 09:20:23 -0400 (EDT) Subject: [Python-Dev] Wikis for todo lists, etc (was PyString_GET_SIZE()) In-Reply-To: References: Message-ID: <14684.40599.135974.497497@cj42289-a.reston1.va.home.com> Tim Peters writes: > productivity. Notes is the purest example of a whole being greater than the > sum of its parts I've ever seen (lousy mail system, lousy database, lousy > change manager, lousy bug tracker, lousy workflow manager, worse than lousy > native scripting ... but they all sucked in ways that were downright > synergistic <0.9 wink>). I had to use Notes before working at CNRI, and wouldn't have described all those sucky components as "synergistic". ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Fri Jun 30 15:26:15 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 30 Jun 2000 09:26:15 -0400 (EDT) Subject: [Python-Dev] New PythonLabs site revealed! In-Reply-To: References: <200006292338.BAA07798@python.inrialpes.fr> Message-ID: <14684.40951.644965.274278@cj42289-a.reston1.va.home.com> Ka-Ping Yee writes: > Will many be spooked by the jump in version number into fearing > incompatibility with older scripts...? > > I wonder if we'll end up trying to persuade the user community that > the changes are small ("no, don't worry, your scripts will still > work") and yet big ("honest, it really deserves to be called 2.0, > it's not just a ploy") at the same time. Ping, Haven't we heard our users complain about the conservative version numbering a lot? Pushing to 2.0 allows us to make the next release 2.1, which neither the "never 1.x!" crowd nor the "never x.0!" will worry about. Sounds like a good move to me! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Fri Jun 30 15:28:15 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 30 Jun 2000 09:28:15 -0400 (EDT) Subject: [Python-Dev] New PythonLabs site revealed! In-Reply-To: <005801bfe270$e140d440$f2a6b5d4@hagrid> References: <005801bfe270$e140d440$f2a6b5d4@hagrid> Message-ID: <14684.41071.958061.743836@cj42289-a.reston1.va.home.com> Fredrik Lundh writes: > btw, now that we're bumping to 2.0, maybe we can break > socket.connect and friends once again? if somebody com- > plains, just tell them "it's a major release, dammit" ;-) If by "break" you mean "tightly conform to the documentation", I'm all for it! ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Fri Jun 30 15:32:24 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 30 Jun 2000 09:32:24 -0400 (EDT) Subject: [Python-Dev] Hey! who changed sys.platform?! In-Reply-To: <395C681D.C3211F6@lemburg.com> References: <20000629233003.A1766@beelzebub> <14684.5401.518766.362678@cj42289-a.reston1.va.home.com> <395C681D.C3211F6@lemburg.com> Message-ID: <14684.41320.38954.833643@cj42289-a.reston1.va.home.com> Regarding platform.py: M.-A. Lemburg writes: > Why not simply include it in distutils ? Why not include it in the standard library? Guido? I'll document it if Marc-Andre is willing to provide the module and the regression test. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From mal at lemburg.com Fri Jun 30 15:40:36 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 30 Jun 2000 15:40:36 +0200 Subject: [Python-Dev] Hey! who changed sys.platform?! References: <20000629233003.A1766@beelzebub> <14684.5401.518766.362678@cj42289-a.reston1.va.home.com> <395C681D.C3211F6@lemburg.com> <14684.41320.38954.833643@cj42289-a.reston1.va.home.com> Message-ID: <395CA354.16AC5B7E@lemburg.com> "Fred L. Drake, Jr." wrote: > > Regarding platform.py: > > M.-A. Lemburg writes: > > Why not simply include it in distutils ? > > Why not include it in the standard library? > Guido? I'll document it if Marc-Andre is willing to provide the > module and the regression test. No objection from here. I've attached my most recent copy to this mail. I'm not sure how to write the regr. test though since output is dependent on the platform running the functions... perhaps I'll just add something like the audio thingie: "This string ought to identify the platform you are currently running... if not, then something is wrong ;-)". -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From bwarsaw at beopen.com Fri Jun 30 15:42:19 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Fri, 30 Jun 2000 09:42:19 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules gcmodule.c,NONE,2.1 Setup.thread.in,2.2,2.3 cPickle.c,2.43,2.44 newmodule.c,2.20,2.21 References: <200006300502.WAA03262@slayer.i.sourceforge.net> Message-ID: <14684.41915.59835.325026@anthem.concentric.net> So, Setup.thread.in isn't used just for threads anymore. Perhaps it should be renamed? At the very least, a comment should be added to the top that this file is for configure enabled modules. -Barry Index: Setup.thread.in =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/Setup.thread.in,v retrieving revision 2.2 retrieving revision 2.3 diff -C2 -r2.2 -r2.3 *** Setup.thread.in 2000/06/29 16:08:28 2.2 --- Setup.thread.in 2000/06/30 05:02:53 2.3 *************** *** 11,12 **** --- 11,15 ---- @USE_THREAD_MODULE at thread threadmodule.c + + # Garbage collection enabled with --with-cycle-gc + @USE_GC_MODULE at gc gcmodule.c From mal at lemburg.com Fri Jun 30 15:42:06 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 30 Jun 2000 15:42:06 +0200 Subject: [Python-Dev] Hey! who changed sys.platform?! References: <20000629233003.A1766@beelzebub> <14684.5401.518766.362678@cj42289-a.reston1.va.home.com> <395C681D.C3211F6@lemburg.com> <14684.41320.38954.833643@cj42289-a.reston1.va.home.com> <395CA354.16AC5B7E@lemburg.com> Message-ID: <395CA3AE.8A5800F1@lemburg.com> Ooops, forgot the attachement... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ -------------- next part -------------- A non-text attachment was scrubbed... Name: platform.py Type: text/python Size: 36884 bytes Desc: not available URL: From guido at python.org Fri Jun 30 16:47:29 2000 From: guido at python.org (Guido van Rossum) Date: Fri, 30 Jun 2000 09:47:29 -0500 Subject: [Python-Dev] Removing modules In-Reply-To: Your message of "Thu, 29 Jun 2000 21:29:41 -0400." <20000629212941.A21563@newcnri.cnri.reston.va.us> References: <20000629212941.A21563@newcnri.cnri.reston.va.us> Message-ID: <200006301447.JAA30671@cj20424-a.reston1.va.home.com> > For the "deleted modules" section of the 2.0 article, I drew up a list > of modules that might be outdated, mostly the SGI-specific ones. Are > those modules still useful, and do the libraries they were written for > still exist? Doubtful. I've asked Sjoerd and Jack, who were most involved in using these. > For your cogitation, here's the list: sgimodule.c, glmodule.c (and > hence cgenmodule.c), imgfile.c, svmodule.c, flmodule.c, fmmodule.c, > almodule.c, clmodule.c, knee.py. I'd like to keep knee.py -- it's a nice piece of *documentation* of the package import. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Fri Jun 30 16:55:08 2000 From: guido at python.org (Guido van Rossum) Date: Fri, 30 Jun 2000 09:55:08 -0500 Subject: [Python-Dev] Hey! who changed sys.platform?! In-Reply-To: Your message of "Fri, 30 Jun 2000 15:40:36 +0200." <395CA354.16AC5B7E@lemburg.com> References: <20000629233003.A1766@beelzebub> <14684.5401.518766.362678@cj42289-a.reston1.va.home.com> <395C681D.C3211F6@lemburg.com> <14684.41320.38954.833643@cj42289-a.reston1.va.home.com> <395CA354.16AC5B7E@lemburg.com> Message-ID: <200006301455.JAA30721@cj20424-a.reston1.va.home.com> > > Regarding platform.py: > > > > M.-A. Lemburg writes: > > > Why not simply include it in distutils ? > > > > Why not include it in the standard library? > > Guido? I'll document it if Marc-Andre is willing to provide the > > module and the regression test. > > No objection from here. > > I've attached my most recent copy to this mail. I'm not sure > how to write the regr. test though since output is dependent > on the platform running the functions... perhaps I'll just > add something like the audio thingie: "This string ought > to identify the platform you are currently running... if not, > then something is wrong ;-)". You didn't include it! But I vote -1 on this one anyway -- it's too much code and almost by its very nature not something that belongs in a "standard" library. Plus, I don't want to be responsible for maintaining it. Sorry, --Guido van Rossum (home page: http://www.python.org/~guido/) From bwarsaw at beopen.com Fri Jun 30 15:57:47 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Fri, 30 Jun 2000 09:57:47 -0400 (EDT) Subject: [Python-Dev] New PythonLabs site revealed! References: <005801bfe270$e140d440$f2a6b5d4@hagrid> Message-ID: <14684.42843.472230.609828@anthem.concentric.net> >>>>> "FL" == Fredrik Lundh writes: FL> btw, now that we're bumping to 2.0, maybe we can break FL> socket.connect and friends once again? if somebody com- FL> plains, just tell them "it's a major release, dammit" ;-) That's a good point. A bump in major rev number is an /opportunity/ to break things, like a bone that hasn't healed right, so that they can be fixed correctly. We'll lose that for 2.0, mostly likely because of the tight release schedule. There's always 3.0 though, which will mesh nicely with the mythical Py3k. -Barry From effbot at telia.com Fri Jun 30 16:08:13 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 30 Jun 2000 16:08:13 +0200 Subject: [Python-Dev] New PythonLabs site revealed! References: <005801bfe270$e140d440$f2a6b5d4@hagrid> <14684.42843.472230.609828@anthem.concentric.net> Message-ID: <016e01bfe29c$a2e8bb00$f2a6b5d4@hagrid> barry wrote: > >>>>> "FL" == Fredrik Lundh writes: > > FL> btw, now that we're bumping to 2.0, maybe we can break > FL> socket.connect and friends once again? if somebody com- > FL> plains, just tell them "it's a major release, dammit" ;-) > > That's a good point. A bump in major rev number is an /opportunity/ > to break things, like a bone that hasn't healed right, so that they > can be fixed correctly. We'll lose that for 2.0, mostly likely > because of the tight release schedule. yeah, but I'm sure Guido has the patches somewhere (after all, the 1.6 release notes still mention this change). if not, the mad patcher volunteers to fix (or rather, break) this. Guido? From bwarsaw at beopen.com Fri Jun 30 16:07:47 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Fri, 30 Jun 2000 10:07:47 -0400 (EDT) Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/PCbuild readme.txt,1.5,1.6 References: Message-ID: <14684.43443.919858.897738@anthem.concentric.net> >>>>> "MH" == Mark Hammond writes: MH> [I wishing mailing-lists would agree on how they handle MH> reply-to :-] It's fundamentally broken, but the problem is in the mail readers (MUA). There's no header (that I'm aware of) that portably tells an MUA - "Hey, for a group follow up, don't go to the original list, go to THIS one instead, but for an individual followup (i.e. reply) still address that to the original author." This is one reason why munging reply-to is evil. But in this case we've agreed that following up to python-dev is more important than preserving the ability to reply to the author. -Barry From mal at lemburg.com Fri Jun 30 16:11:54 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 30 Jun 2000 16:11:54 +0200 Subject: [Python-Dev] Hey! who changed sys.platform?! References: <20000629233003.A1766@beelzebub> <14684.5401.518766.362678@cj42289-a.reston1.va.home.com> <395C681D.C3211F6@lemburg.com> <14684.41320.38954.833643@cj42289-a.reston1.va.home.com> <395CA354.16AC5B7E@lemburg.com> <200006301455.JAA30721@cj20424-a.reston1.va.home.com> Message-ID: <395CAAAA.5975A617@lemburg.com> Guido van Rossum wrote: > > > > Regarding platform.py: > > > > > > M.-A. Lemburg writes: > > > > Why not simply include it in distutils ? > > > > > > Why not include it in the standard library? > > > Guido? I'll document it if Marc-Andre is willing to provide the > > > module and the regression test. > > > > No objection from here. > > > > I've attached my most recent copy to this mail. I'm not sure > > how to write the regr. test though since output is dependent > > on the platform running the functions... perhaps I'll just > > add something like the audio thingie: "This string ought > > to identify the platform you are currently running... if not, > > then something is wrong ;-)". > > You didn't include it! I posted a reply to fix this ;-) > But I vote -1 on this one anyway -- it's too much code and almost by > its very nature not something that belongs in a "standard" library. > Plus, I don't want to be responsible for maintaining it. Sorry, You don't have to maintain it... I will anyway since it's part of mxCGIPython. Anyway, perhaps Greg Ward can find some use for it in distutils. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From effbot at telia.com Fri Jun 30 16:18:13 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 30 Jun 2000 16:18:13 +0200 Subject: [Python-Dev] SRE incompatibility Message-ID: <018401bfe29e$07f26720$f2a6b5d4@hagrid> my latest changes fixed a couple of things, but broke one of the old RE tests, namely: re.match('\\x00ffffffffffffff', '\377') != None or in other words, long hexadecimal escapes are cast down to 8-bit characters in RE. in SRE (after the latest change), they're cast down to the size of the engine's internal word size (currently 16 bits). is the old behaviour worth keeping? I'd rather not make the engine dependent on string types; it shouldn't really matter if you're using unicode patterns on 8-bit target strings, or vice versa. From gward at mems-exchange.org Fri Jun 30 16:13:40 2000 From: gward at mems-exchange.org (Greg Ward) Date: Fri, 30 Jun 2000 10:13:40 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils msvccompiler.py,1.33,1.34 In-Reply-To: <14683.56294.836295.923883@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Thu, Jun 29, 2000 at 07:29:42PM -0400 References: <200006292305.QAA11929@slayer.i.sourceforge.net> <200006300020.TAA21877@cj20424-a.reston1.va.home.com> <14683.56294.836295.923883@cj42289-a.reston1.va.home.com> Message-ID: <20000630101340.A16350@ludwig.cnri.reston.va.us> On 29 June 2000, Fred L. Drake, Jr. said: > > Greg Ward wrote in a checkin message: > > On second thought, first try for _winreg, and then winreg. Only if both > > fail do we try for win32api/win32con. If *those* both fail, then we don't > > have registry access. Phew! > > Guido van Rossum writes on python-dev: > > Is this smart? Doesn't the new winreg have a very different I/F than > > the old one? > > No, this is bad. It *will* break with winreg; if _winreg isn't > available, it should use the win32api/win32con/whatever stuff; it's a > Python 1.5.2 interpreter at that point. What if it's a 1.6a1 or 1.6a2 interpreter? Presumably people will try Distutils 0.9 with them. Should I remove that feature now that 0.9 is out, but before Python 2.0b1? Greg -- Greg Ward - software developer gward at mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From esr at thyrsus.com Fri Jun 30 16:27:07 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 30 Jun 2000 10:27:07 -0400 Subject: [Python-Dev] Removing modules In-Reply-To: <200006301447.JAA30671@cj20424-a.reston1.va.home.com>; from guido@python.org on Fri, Jun 30, 2000 at 09:47:29AM -0500 References: <20000629212941.A21563@newcnri.cnri.reston.va.us> <200006301447.JAA30671@cj20424-a.reston1.va.home.com> Message-ID: <20000630102707.A27830@thyrsus.com> Guido van Rossum : > > For the "deleted modules" section of the 2.0 article, I drew up a list > > of modules that might be outdated, mostly the SGI-specific ones. Are > > those modules still useful, and do the libraries they were written for > > still exist? > > Doubtful. I've asked Sjoerd and Jack, who were most involved in using > these. > > > For your cogitation, here's the list: sgimodule.c, glmodule.c (and > > hence cgenmodule.c), imgfile.c, svmodule.c, flmodule.c, fmmodule.c, > > almodule.c, clmodule.c, knee.py. > > I'd like to keep knee.py -- it's a nice piece of *documentation* of > the package import. +1 on giving the SGI-specific modules the heave-ho. Their presence has always struck me as a sort of vermiform appendix in a core library otherwise clearly aimed at being as platform-independent as rdeasonably possible (e.g. given the Unix-vs.Windows differences). -- Eric S. Raymond Power concedes nothing without a demand. It never did, and it never will. Find out just what people will submit to, and you have found out the exact amount of injustice and wrong which will be imposed upon them; and these will continue until they are resisted with either words or blows, or with both. The limits of tyrants are prescribed by the endurance of those whom they oppress. -- Frederick Douglass, August 4, 1857 From gward at mems-exchange.org Fri Jun 30 16:22:42 2000 From: gward at mems-exchange.org (Greg Ward) Date: Fri, 30 Jun 2000 10:22:42 -0400 Subject: [Python-Dev] Hey! who changed sys.platform?! In-Reply-To: <395CAAAA.5975A617@lemburg.com>; from mal@lemburg.com on Fri, Jun 30, 2000 at 04:11:54PM +0200 References: <20000629233003.A1766@beelzebub> <14684.5401.518766.362678@cj42289-a.reston1.va.home.com> <395C681D.C3211F6@lemburg.com> <14684.41320.38954.833643@cj42289-a.reston1.va.home.com> <395CA354.16AC5B7E@lemburg.com> <200006301455.JAA30721@cj20424-a.reston1.va.home.com> <395CAAAA.5975A617@lemburg.com> Message-ID: <20000630102242.B16350@ludwig.cnri.reston.va.us> On 30 June 2000, M.-A. Lemburg said: > > But I vote -1 on this one anyway -- it's too much code and almost by > > its very nature not something that belongs in a "standard" library. > > Plus, I don't want to be responsible for maintaining it. Sorry, > > You don't have to maintain it... I will anyway since it's part > of mxCGIPython. > > Anyway, perhaps Greg Ward can find some use for it in > distutils. I looked at platform.py once briefly, and my impression was similar to Guido's: too big! All I want(ed) is "osname-cpu" -- linux-i386, solaris-sparc, whatever. osversion is optional. But, consider that that the Distutils might want to know if it should generate RPMs or Debian packages... then the stuff about grokking which Linux distribution it's running on is relevant. Argh! Anyways, I'm already taking static about too much code in the Distutils, and I partly agree. (I agree there's a *lot* of code, I know there are bits that can be refactored and reduced, but I'm not sure it's too much.) So I'll stick with sys.platform for now -- it's good enough. Greg -- Greg Ward - software developer gward at mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From sjoerd at oratrix.nl Fri Jun 30 16:21:53 2000 From: sjoerd at oratrix.nl (Sjoerd Mullender) Date: Fri, 30 Jun 2000 16:21:53 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Objects unicodeobject.c,2.31,2.32 In-Reply-To: Your message of Fri, 30 Jun 2000 03:29:59 -0700. <200006301029.DAA25494@slayer.i.sourceforge.net> References: <200006301029.DAA25494@slayer.i.sourceforge.net> Message-ID: <20000630142154.968F831047C@bireme.oratrix.nl> Why was the change that occurred in revision 2.31 reverted? Accident? The change log said: Jack Jansen: Use include "" instead of <>; and staticforward declarations On Fri, Jun 30 2000 "M.-A. Lemburg" wrote: > Update of /cvsroot/python/python/dist/src/Objects > In directory slayer.i.sourceforge.net:/tmp/cvs-serv25442/Objects > > Modified Files: > unicodeobject.c > Log Message: > Marc-Andre Lemburg : > New buffer overflow checks for formatting strings. > > By Trent Mick. > > Index: unicodeobject.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v > retrieving revision 2.31 > retrieving revision 2.32 > diff -C2 -r2.31 -r2.32 > *** unicodeobject.c 2000/06/29 00:06:39 2.31 > --- unicodeobject.c 2000/06/30 10:29:57 2.32 > *************** > *** 67,71 **** > #include "mymath.h" > #include "unicodeobject.h" > ! #include "ucnhash.h" > > #if defined(HAVE_LIMITS_H) > --- 67,71 ---- > #include "mymath.h" > #include "unicodeobject.h" > ! #include > > #if defined(HAVE_LIMITS_H) > *************** > *** 1245,1249 **** > ucnFallthrough: > /* fall through on purpose */ > ! default: > *p++ = '\\'; > *p++ = (unsigned char)s[-1]; > --- 1245,1249 ---- > ucnFallthrough: > /* fall through on purpose */ > ! default: > *p++ = '\\'; > *p++ = (unsigned char)s[-1]; > *************** > *** 1252,1256 **** > } > if (_PyUnicode_Resize(v, (int)(p - buf))) > ! goto onError; > return (PyObject *)v; > > --- 1252,1256 ---- > } > if (_PyUnicode_Resize(v, (int)(p - buf))) > ! goto onError; > return (PyObject *)v; > > *************** > *** 4374,4377 **** > --- 4374,4378 ---- > static int > formatfloat(Py_UNICODE *buf, > + size_t buflen, > int flags, > int prec, > *************** > *** 4379,4382 **** > --- 4380,4385 ---- > PyObject *v) > { > + /* fmt = '%#.' + `prec` + `type` > + worst case length = 3 + 10 (len of INT_MAX) + 1 = 14 (use 20)*/ > char fmt[20]; > double x; > *************** > *** 4387,4395 **** > if (prec < 0) > prec = 6; > - if (prec > 50) > - prec = 50; /* Arbitrary limitation */ > if (type == 'f' && (fabs(x) / 1e25) >= 1e25) > type = 'g'; > sprintf(fmt, "%%%s.%d%c", (flags & F_ALT) ? "#" : "", prec, type); > return usprintf(buf, fmt, x); > } > --- 4390,4408 ---- > if (prec < 0) > prec = 6; > if (type == 'f' && (fabs(x) / 1e25) >= 1e25) > type = 'g'; > sprintf(fmt, "%%%s.%d%c", (flags & F_ALT) ? "#" : "", prec, type); > + /* worst case length calc to ensure no buffer overrun: > + fmt = %#.g > + buf = '-' + [0-9]*prec + '.' + 'e+' + (longest exp > + for any double rep.) > + len = 1 + prec + 1 + 2 + 5 = 9 + prec > + If prec=0 the effective precision is 1 (the leading digit is > + always given), therefore increase by one to 10+prec. */ > + if (buflen <= (size_t)10 + (size_t)prec) { > + PyErr_SetString(PyExc_OverflowError, > + "formatted float is too long (precision too long?)"); > + return -1; > + } > return usprintf(buf, fmt, x); > } > *************** > *** 4397,4400 **** > --- 4410,4414 ---- > static int > formatint(Py_UNICODE *buf, > + size_t buflen, > int flags, > int prec, > *************** > *** 4402,4405 **** > --- 4416,4421 ---- > PyObject *v) > { > + /* fmt = '%#.' + `prec` + 'l' + `type` > + worst case length = 3 + 10 (len of INT_MAX) + 1 + 1 = 15 (use 20)*/ > char fmt[20]; > long x; > *************** > *** 4410,4413 **** > --- 4426,4436 ---- > if (prec < 0) > prec = 1; > + /* buf = '+'/'-'/'0'/'0x' + '[0-9]'*max(prec,len(x in octal)) > + worst case buf = '0x' + [0-9]*prec, where prec >= 11 */ > + if (buflen <= 13 || buflen <= (size_t)2+(size_t)prec) { > + PyErr_SetString(PyExc_OverflowError, > + "formatted integer is too long (precision too long?)"); > + return -1; > + } > sprintf(fmt, "%%%s.%dl%c", (flags & F_ALT) ? "#" : "", prec, type); > return usprintf(buf, fmt, x); > *************** > *** 4416,4421 **** > static int > formatchar(Py_UNICODE *buf, > ! PyObject *v) > { > if (PyUnicode_Check(v)) { > if (PyUnicode_GET_SIZE(v) != 1) > --- 4439,4446 ---- > static int > formatchar(Py_UNICODE *buf, > ! size_t buflen, > ! PyObject *v) > { > + /* presume that the buffer is at least 2 characters long */ > if (PyUnicode_Check(v)) { > if (PyUnicode_GET_SIZE(v) != 1) > *************** > *** 4447,4450 **** > --- 4472,4485 ---- > } > > + /* fmt%(v1,v2,...) is roughly equivalent to sprintf(fmt, v1, v2, ...) > + > + FORMATBUFLEN is the length of the buffer in which the floats, ints, & > + chars are formatted. XXX This is a magic number. Each formatting > + routine does bounds checking to ensure no overflow, but a better > + solution may be to malloc a buffer of appropriate size for each > + format. For now, the current solution is sufficient. > + */ > + #define FORMATBUFLEN (size_t)120 > + > PyObject *PyUnicode_Format(PyObject *format, > PyObject *args) > *************** > *** 4506,4513 **** > PyObject *v = NULL; > PyObject *temp = NULL; > ! Py_UNICODE *buf; > Py_UNICODE sign; > int len; > ! Py_UNICODE tmpbuf[120]; /* For format{float,int,char}() */ > > fmt++; > --- 4541,4548 ---- > PyObject *v = NULL; > PyObject *temp = NULL; > ! Py_UNICODE *pbuf; > Py_UNICODE sign; > int len; > ! Py_UNICODE formatbuf[FORMATBUFLEN]; /* For format{float,int,char}() */ > > fmt++; > *************** > *** 4659,4664 **** > > case '%': > ! buf = tmpbuf; > ! buf[0] = '%'; > len = 1; > break; > --- 4694,4700 ---- > > case '%': > ! pbuf = formatbuf; > ! /* presume that buffer length is at least 1 */ > ! pbuf[0] = '%'; > len = 1; > break; > *************** > *** 4696,4700 **** > goto onError; > } > ! buf = PyUnicode_AS_UNICODE(temp); > len = PyUnicode_GET_SIZE(temp); > if (prec >= 0 && len > prec) > --- 4732,4736 ---- > goto onError; > } > ! pbuf = PyUnicode_AS_UNICODE(temp); > len = PyUnicode_GET_SIZE(temp); > if (prec >= 0 && len > prec) > *************** > *** 4710,4715 **** > if (c == 'i') > c = 'd'; > ! buf = tmpbuf; > ! len = formatint(buf, flags, prec, c, v); > if (len < 0) > goto onError; > --- 4746,4752 ---- > if (c == 'i') > c = 'd'; > ! pbuf = formatbuf; > ! len = formatint(pbuf, sizeof(formatbuf)/sizeof(Py_UNICODE), > ! flags, prec, c, v); > if (len < 0) > goto onError; > *************** > *** 4719,4725 **** > if ((flags&F_ALT) && > (c == 'x' || c == 'X') && > ! buf[0] == '0' && buf[1] == c) { > ! *res++ = *buf++; > ! *res++ = *buf++; > rescnt -= 2; > len -= 2; > --- 4756,4762 ---- > if ((flags&F_ALT) && > (c == 'x' || c == 'X') && > ! pbuf[0] == '0' && pbuf[1] == c) { > ! *res++ = *pbuf++; > ! *res++ = *pbuf++; > rescnt -= 2; > len -= 2; > *************** > *** 4736,4741 **** > case 'g': > case 'G': > ! buf = tmpbuf; > ! len = formatfloat(buf, flags, prec, c, v); > if (len < 0) > goto onError; > --- 4773,4779 ---- > case 'g': > case 'G': > ! pbuf = formatbuf; > ! len = formatfloat(pbuf, sizeof(formatbuf)/sizeof(Py_UNICODE), > ! flags, prec, c, v); > if (len < 0) > goto onError; > *************** > *** 4746,4751 **** > > case 'c': > ! buf = tmpbuf; > ! len = formatchar(buf, v); > if (len < 0) > goto onError; > --- 4784,4789 ---- > > case 'c': > ! pbuf = formatbuf; > ! len = formatchar(pbuf, sizeof(formatbuf)/sizeof(Py_UNICODE), v); > if (len < 0) > goto onError; > *************** > *** 4759,4764 **** > } > if (sign) { > ! if (*buf == '-' || *buf == '+') { > ! sign = *buf++; > len--; > } > --- 4797,4802 ---- > } > if (sign) { > ! if (*pbuf == '-' || *pbuf == '+') { > ! sign = *pbuf++; len--; > } > *************** > *** 4796,4800 **** > if (sign && fill == ' ') > *res++ = sign; > ! memcpy(res, buf, len * sizeof(Py_UNICODE)); > res += len; > rescnt -= len; > --- 4834,4838 ---- > if (sign && fill == ' ') > *res++ = sign; > ! memcpy(res, pbuf, len * sizeof(Py_UNICODE)); > res += len; > rescnt -= len; > > -- Sjoerd Mullender From akuchlin at mems-exchange.org Fri Jun 30 16:29:00 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Fri, 30 Jun 2000 10:29:00 -0400 Subject: [Python-Dev] SRE incompatibility In-Reply-To: <018401bfe29e$07f26720$f2a6b5d4@hagrid>; from effbot@telia.com on Fri, Jun 30, 2000 at 04:18:13PM +0200 References: <018401bfe29e$07f26720$f2a6b5d4@hagrid> Message-ID: <20000630102900.A19597@kronos.cnri.reston.va.us> On Fri, Jun 30, 2000 at 04:18:13PM +0200, Fredrik Lundh wrote: > re.match('\\x00ffffffffffffff', '\377') != None >or in other words, long hexadecimal escapes are cast >down to 8-bit characters in RE. This is for compatibility with Python string literals: kronos Python-1.6>./python >>> '\x00fffffff' '\377' >>> u'\x00fffffff' u'\uFFFF' (Where do these semantics come from, BTW? C's \x seems to take any number of hex digits but then reports an error if the character is greater than 256, too large to fit into a byte.) Note that the \u escape for Unicode characters uses exactly 4 digits, no more, no less. It would certainly be simpler and clearer to only support a fixed number of digits with \x, since I find the casting down behaviour is magical and not obvious. But I don't know if we want to make that change now. (Guido now realizes the downside to numbering it 2.0, as everyone hurries to suggest their favorite backward-incompatible change.) That doesn't help with regexes, of course, since a pattern might be written as a regular string but be intended to match Unicode. Maybe the simplest rule is the best; always take 4 digits, even if it winds up being incompatible with the \x in string literals. --amk From fdrake at beopen.com Fri Jun 30 16:33:47 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 30 Jun 2000 10:33:47 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils msvccompiler.py,1.33,1.34 In-Reply-To: <20000630101340.A16350@ludwig.cnri.reston.va.us> References: <200006292305.QAA11929@slayer.i.sourceforge.net> <200006300020.TAA21877@cj20424-a.reston1.va.home.com> <14683.56294.836295.923883@cj42289-a.reston1.va.home.com> <20000630101340.A16350@ludwig.cnri.reston.va.us> Message-ID: <14684.45003.193701.382599@cj42289-a.reston1.va.home.com> Greg Ward writes: > What if it's a 1.6a1 or 1.6a2 interpreter? Presumably people will try > Distutils 0.9 with them. Should I remove that feature now that 0.9 is > out, but before Python 2.0b1? You're placing too much value on code labelled "alpha". ;) There are two interesting versions -- 1.5.2 (since you scrapped support for versions before that), and 2.0. And the CVS version is the closest approximation to 2.0 that anyone has. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Fri Jun 30 16:38:51 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 30 Jun 2000 10:38:51 -0400 (EDT) Subject: [Python-Dev] Hey! who changed sys.platform?! In-Reply-To: <20000630102242.B16350@ludwig.cnri.reston.va.us> References: <20000629233003.A1766@beelzebub> <14684.5401.518766.362678@cj42289-a.reston1.va.home.com> <395C681D.C3211F6@lemburg.com> <14684.41320.38954.833643@cj42289-a.reston1.va.home.com> <395CA354.16AC5B7E@lemburg.com> <200006301455.JAA30721@cj20424-a.reston1.va.home.com> <395CAAAA.5975A617@lemburg.com> <20000630102242.B16350@ludwig.cnri.reston.va.us> Message-ID: <14684.45307.983394.125671@cj42289-a.reston1.va.home.com> Greg Ward writes: > But, consider that that the Distutils might want to know if it should > generate RPMs or Debian packages... then the stuff about grokking which > Linux distribution it's running on is relevant. Argh! Why would you need to figure this out? Are you selecting a platform-specific packaging system automatically? In that case, I'd search for the presence of the tools rather than asking what sort of distribution you're running on -- several distros use RPM, a few use .deb packages, etc. When the user specifies one on the command line, just use the one they name and be done with it. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From mal at lemburg.com Fri Jun 30 16:53:31 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 30 Jun 2000 16:53:31 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Objects unicodeobject.c,2.31,2.32 References: <200006301029.DAA25494@slayer.i.sourceforge.net> <20000630142154.968F831047C@bireme.oratrix.nl> Message-ID: <395CB46B.34053D3E@lemburg.com> > Why was the change that occurred in revision 2.31 reverted? Accident? > > The change log said: > Jack Jansen: Use include "" instead of <>; and staticforward declarations Accident... I'll revert that change. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido at python.org Fri Jun 30 18:07:16 2000 From: guido at python.org (Guido van Rossum) Date: Fri, 30 Jun 2000 11:07:16 -0500 Subject: [Python-Dev] SRE incompatibility In-Reply-To: Your message of "Fri, 30 Jun 2000 16:18:13 +0200." <018401bfe29e$07f26720$f2a6b5d4@hagrid> References: <018401bfe29e$07f26720$f2a6b5d4@hagrid> Message-ID: <200006301607.LAA10829@cj20424-a.reston1.va.home.com> > my latest changes fixed a couple of things, but broke > one of the old RE tests, namely: > > re.match('\\x00ffffffffffffff', '\377') != None > > or in other words, long hexadecimal escapes are cast > down to 8-bit characters in RE. > > in SRE (after the latest change), they're cast down to > the size of the engine's internal word size (currently 16 > bits). > > is the old behaviour worth keeping? I'd rather not make > the engine dependent on string types; it shouldn't really > matter if you're using unicode patterns on 8-bit target > strings, or vice versa. To someone familiar with '\x00ffffffffffffff' == '\377', the failure is surprising. What Would Larry Do? (I.e. is this in Perl?) Maybe make it dependent on the type of the searched string ('\377') rather than on the type of the pattern? --Guido van Rossum (home page: http://www.python.org/~guido/) From skip at mojam.com Fri Jun 30 15:54:49 2000 From: skip at mojam.com (Skip Montanaro) Date: Fri, 30 Jun 2000 08:54:49 -0500 (CDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test README,NONE,1.1 In-Reply-To: <20000629232733.D24811@activestate.com> References: <200006300608.XAA13124@slayer.i.sourceforge.net> <20000629232733.D24811@activestate.com> Message-ID: <14684.42665.221905.911205@beluga.mojam.com> Trent> Cool Thanks. >> To run the entire test suite, make the "test" target at the top level: >> >> cd ... >> make test Trent> This is a UN*Xism, on Windows and UN*X: Trent> cd ...\Lib\test Trent> python regrtest.py Thanks, I'll check into it. I'm a Unix weenie so am (blissfully) unaware of how Windows weenies do these things... ;-) Trent> A sample walk through to create a test might make it more Trent> approachable for people. As well, it would be helpful to mention Trent> test_support.{verbose|TESTFN|...}. But I have no right to bitch Trent> about good work. I'll check into that as well. The README file was created in about 30 minutes and was a good excuse to test my checkin capabilities on something that wouldn't break anything. ;-) Skip From mhammond at skippinet.com.au Fri Jun 30 17:48:43 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sat, 1 Jul 2000 01:48:43 +1000 Subject: [Python-Dev] Checked in new PC\config.h Message-ID: Hi all, I noticed that PC\config.h still had a reference to "Python16.lib". I simply checked in a new version without submitting a patch or following any other process. I hope this was appropriate. Mark. From akuchlin at mems-exchange.org Fri Jun 30 18:03:48 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Fri, 30 Jun 2000 12:03:48 -0400 Subject: [Python-Dev] SRE incompatibility In-Reply-To: <200006301607.LAA10829@cj20424-a.reston1.va.home.com>; from guido@python.org on Fri, Jun 30, 2000 at 11:07:16AM -0500 References: <018401bfe29e$07f26720$f2a6b5d4@hagrid> <200006301607.LAA10829@cj20424-a.reston1.va.home.com> Message-ID: <20000630120348.C19597@kronos.cnri.reston.va.us> On Fri, Jun 30, 2000 at 11:07:16AM -0500, Guido van Rossum wrote: >To someone familiar with '\x00ffffffffffffff' == '\377', the failure >is surprising. What Would Larry Do? (I.e. is this in Perl?) It uses two digits: "\x00ffff" is the string "ffff". >Maybe make it dependent on the type of the searched string ('\377') >rather than on the type of the pattern? Won't work; you could just be compiling a pattern to make a regex object, and have no idea what you're matching against. --amk From jeremy at beopen.com Fri Jun 30 18:10:09 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 30 Jun 2000 12:10:09 -0400 (EDT) Subject: [Python-Dev] SRE incompatibility In-Reply-To: <018401bfe29e$07f26720$f2a6b5d4@hagrid> References: <018401bfe29e$07f26720$f2a6b5d4@hagrid> Message-ID: <14684.50785.245652.345591@bitdiddle.concentric.net> I don't know if this is related, exactly, but there is some kind of problem with the current test. When I run make test, I see: test test_sre crashed -- exceptions.SyntaxError : inconsistent use of tabs and spaces in indentation tabnanny thinks test_sre.py is fine, so I'm not sure what the problem is. Jeremy From tim_one at email.msn.com Fri Jun 30 18:18:03 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 30 Jun 2000 12:18:03 -0400 Subject: [Python-Dev] Checked in new PC\config.h In-Reply-To: Message-ID: [Mark Hammond] > I noticed that PC\config.h still had a reference to > "Python16.lib". I simply checked in a new version without > submitting a patch or following any other process. I hope > this was appropriate. IMO, if you're an expert in an area and need to make a change in that area that indeed needs to be made and isn't going to screw anybody (and because you're an expert in that area, you're not wrong in your judgment of that ), just do it! We'll see the diffs come by later. Guido, Barry, Jeremy, & Fred have been working that way a long time now. If they didn't want us to work that way too, they shouldn't have given us the ability to commit. empowering-the-masses-ly y'rs - tim From guido at python.org Fri Jun 30 19:18:10 2000 From: guido at python.org (Guido van Rossum) Date: Fri, 30 Jun 2000 12:18:10 -0500 Subject: [Python-Dev] SRE incompatibility In-Reply-To: Your message of "Fri, 30 Jun 2000 12:03:48 -0400." <20000630120348.C19597@kronos.cnri.reston.va.us> References: <018401bfe29e$07f26720$f2a6b5d4@hagrid> <200006301607.LAA10829@cj20424-a.reston1.va.home.com> <20000630120348.C19597@kronos.cnri.reston.va.us> Message-ID: <200006301718.MAA12448@cj20424-a.reston1.va.home.com> > On Fri, Jun 30, 2000 at 11:07:16AM -0500, Guido van Rossum wrote: > >To someone familiar with '\x00ffffffffffffff' == '\377', the failure > >is surprising. What Would Larry Do? (I.e. is this in Perl?) > > It uses two digits: "\x00ffff" is the string "ffff". > > >Maybe make it dependent on the type of the searched string ('\377') > >rather than on the type of the pattern? > > Won't work; you could just be compiling a pattern to make a regex > object, and have no idea what you're matching against. OK. Let's change our spec. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Fri Jun 30 19:26:51 2000 From: guido at python.org (Guido van Rossum) Date: Fri, 30 Jun 2000 12:26:51 -0500 Subject: [Python-Dev] Checked in new PC\config.h In-Reply-To: Your message of "Fri, 30 Jun 2000 12:18:03 -0400." References: Message-ID: <200006301726.MAA12560@cj20424-a.reston1.va.home.com> > IMO, if you're an expert in an area and need to make a change in that area > that indeed needs to be made and isn't going to screw anybody (and because > you're an expert in that area, you're not wrong in your judgment of that > ), just do it! We'll see the diffs come by later. Guido, Barry, > Jeremy, & Fred have been working that way a long time now. If they didn't > want us to work that way too, they shouldn't have given us the ability to > commit. Exactly! So far it's working like a charm! --Guido van Rossum (home page: http://www.python.org/~guido/) From tim_one at email.msn.com Fri Jun 30 18:38:21 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 30 Jun 2000 12:38:21 -0400 Subject: [Python-Dev] SRE incompatibility In-Reply-To: <20000630102900.A19597@kronos.cnri.reston.va.us> Message-ID: [Andrew Kuchling] > ... > This is for compatibility with Python string literals: > > kronos Python-1.6>./python > >>> '\x00fffffff' > '\377' > >>> u'\x00fffffff' > u'\uFFFF' > > (Where do these semantics come from, BTW? C's \x seems to take any > number of hex digits but then reports an error if the character is > greater than 256, too large to fit into a byte.) The behavior of \x in C is mostly implementation-defined. The committee knew that C had to do *something* to support "large characters" down the road, but in those early days they had no clear idea exactly what. So, rather than do something sensible <0.5 wink>, they invented a perfectly general mechanism without portable semantics. "C itself" isn't complaining if the character "is greater than 256", it's the specific implementation of C you're using that's complaining. A different implementation is free to (& probably will!) do something different. Guido adopted the most commonly implemented semantics (ignore all but the last byte) in Python, apparently under the delusion that this would be a Good Thing . Marc-Andre followed suit by generalizing this madness to Unicode. > Note that the \u escape for Unicode characters uses exactly 4 digits, > no more, no less. I pushed for that obnoxiously. Glad you appreciate it . Java does the same. > It would certainly be simpler and clearer to only support a fixed > number of digits with \x, since I find the casting down behaviour is > magical and not obvious. Yes, it's basically nuts. > But I don't know if we want to make that change now. No from me, because it may break stuff. Wait for Python 2.0 . > (Guido now realizes the downside to numbering it 2.0, as everyone > hurries to suggest their favorite backward-incompatible change.) Guido always realized that, I believe. It's a "least of evils" kind of thing, mixed with a celebration, not a pure win. > That doesn't help with regexes, of course, since a pattern might be > written as a regular string but be intended to match Unicode. Maybe > the simplest rule is the best; always take 4 digits, even if it winds > up being incompatible with the \x in string literals. I vote for backward compatibility for now, and not only because that will irritate /F the most. From bwarsaw at beopen.com Fri Jun 30 18:51:15 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Fri, 30 Jun 2000 12:51:15 -0400 (EDT) Subject: [Python-Dev] --with-cycle-gc switch Message-ID: <14684.53251.309942.13110@anthem.concentric.net> I don't like --with-cycle-gc as the configure switch, and unfortunately configure is explicitly designed not to complain about bogus switches. I just typed --without-gc and was momentarily surprised that the module was still enabled. I propose to change the switch to --with(out)-gc and to not recognize --with(out)-cycle-gc. The switch hasn't been there long enough to support both. -Barry From jeremy at beopen.com Fri Jun 30 19:02:42 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 30 Jun 2000 13:02:42 -0400 (EDT) Subject: [Python-Dev] --with-cycle-gc switch In-Reply-To: <14684.53251.309942.13110@anthem.concentric.net> References: <14684.53251.309942.13110@anthem.concentric.net> Message-ID: <14684.53938.307841.921051@bitdiddle.concentric.net> The problem with the name --without-gc is that it suggests a build without any garbage collection. The new patch only handles one special case of garbage collection. The name --without-cycle-gc is a little unwieldy, but clearer. Jeremy From Vladimir.Marangozov at inrialpes.fr Fri Jun 30 19:11:50 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Fri, 30 Jun 2000 19:11:50 +0200 (CEST) Subject: [Python-Dev] --with-cycle-gc switch In-Reply-To: <14684.53251.309942.13110@anthem.concentric.net> from "Barry A. Warsaw" at Jun 30, 2000 12:51:15 PM Message-ID: <200006301711.TAA21382@python.inrialpes.fr> Barry A. Warsaw wrote: > > I propose to change the switch to --with(out)-gc and to not recognize > --with(out)-cycle-gc. The switch hasn't been there long enough to > support both. -0 for the reason summarized by Jeremy -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From effbot at telia.com Fri Jun 30 19:33:55 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 30 Jun 2000 19:33:55 +0200 Subject: [Python-Dev] SRE: a minor glitch in re.py References: <200006301625.JAA32503@slayer.i.sourceforge.net> Message-ID: <02cc01bfe2b9$61b8ee80$f2a6b5d4@hagrid> from the new re.py: > ! # change this to "pre" if your regexps stopped working. don't > ! # forget to send a bug report to is bugs-py at python.org suitable? or should we refer people to http://www.python.org/search/search_bugs.html or should they pester me directly? (i.e. effbot at telia.com) From guido at python.org Fri Jun 30 20:33:46 2000 From: guido at python.org (Guido van Rossum) Date: Fri, 30 Jun 2000 13:33:46 -0500 Subject: [Python-Dev] SRE: a minor glitch in re.py In-Reply-To: Your message of "Fri, 30 Jun 2000 19:33:55 +0200." <02cc01bfe2b9$61b8ee80$f2a6b5d4@hagrid> References: <200006301625.JAA32503@slayer.i.sourceforge.net> <02cc01bfe2b9$61b8ee80$f2a6b5d4@hagrid> Message-ID: <200006301833.NAA18667@cj20424-a.reston1.va.home.com> > from the new re.py: > > > ! # change this to "pre" if your regexps stopped working. don't > > ! # forget to send a bug report to > > is bugs-py at python.org suitable? > > or should we refer people to > http://www.python.org/search/search_bugs.html > > or should they pester me directly? (i.e. effbot at telia.com) Probably. You decide and check it in! --Guido van Rossum (home page: http://www.python.org/~guido/) From bwarsaw at beopen.com Fri Jun 30 19:39:12 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Fri, 30 Jun 2000 13:39:12 -0400 (EDT) Subject: [Python-Dev] --with-cycle-gc switch References: <14684.53251.309942.13110@anthem.concentric.net> <200006301711.TAA21382@python.inrialpes.fr> Message-ID: <14684.56128.700037.255534@anthem.concentric.net> >>>>> "VM" == Vladimir Marangozov writes: VM> -0 VM> for the reason summarized by Jeremy Okay, I'll leave it alone. From Vladimir.Marangozov at inrialpes.fr Fri Jun 30 19:52:15 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Fri, 30 Jun 2000 19:52:15 +0200 (CEST) Subject: [Python-Dev] Oops on AIX Message-ID: <200006301752.TAA22474@python.inrialpes.fr> After the CVS commit storm that occurred during the last 3 days, I wanted to validate the current build on AIX. And I am stalled. I am not sure, but it seems like the errors I get relate with the latest 64-bit support patches, and I don't dare to suggest corrections in this area, so I welcome any help... xlc_r -O -I./../Include -I.. -DHAVE_CONFIG_H -c methodobject.c "methodobject.c", line 183.36: 1506-280 (E) Function argument assignment between types "void*" and "struct _object*(*)(struct _object*,struct _object*)" is not allowed. xlc_r -O -I./../Include -I.. -DHAVE_CONFIG_H -c ./posixmodule.c "./posixmodule.c", line 293.16: 1506-213 (S) Macro name STAT cannot be redefined. "./posixmodule.c", line 293.16: 1506-358 (I) "STAT" is defined on line 170 of /usr/include/sys/dir.h. make: 1254-004 The error code from the last command is 1. Thanks. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From effbot at telia.com Fri Jun 30 19:53:45 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 30 Jun 2000 19:53:45 +0200 Subject: [Python-Dev] SRE incompatibility References: Message-ID: <032701bfe2bc$23da47a0$f2a6b5d4@hagrid> tim wrote: > > That doesn't help with regexes, of course, since a pattern might be > > written as a regular string but be intended to match Unicode. Maybe > > the simplest rule is the best; always take 4 digits, even if it winds > > up being incompatible with the \x in string literals. > > I vote for backward compatibility for now, and not only because that will > irritate /F the most. backward compatibility with what? 8-bit string literals or unicode string literals? the problem here is that the pattern is compiled once (from either 8-bit or unicode strings), and can then be used on either 8-bit or unicode targets. to be fully backwards compatible, this means that the compiler should use 8 bits, no matter what string type you're using. another solution would be to use the type of the pattern string to choose between 8 and 16 bits. I almost implemented that, before I realized that it broke the following rather nice property: sre.compile("some pattern") == sre.compile(u"some pattern") (well, the pattern type doesn't implement __cmp__, but you get the idea). the current implementation guarantees "==", but I'm planning to change that to "is" (!). anyway, I suspect it's too late to change this in 2.0b1. if enough people complain about this, we can always label it a "critical bug", and do something about it in b2. From bwarsaw at beopen.com Fri Jun 30 20:04:06 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Fri, 30 Jun 2000 14:04:06 -0400 (EDT) Subject: [Python-Dev] Odd behavior with `make test' Message-ID: <14684.57622.9807.868551@anthem.concentric.net> make test is behaving strangely. The first time I ran it I got test test_mmap crashed -- exceptions.SyntaxError : inconsistent use of tabs and spaces in indentation which I believe Jeremy has seen with test_sre. tabnanny says everything's fine, and running the module manually (and individually w/ regrtest) shows no problems with the test. Similarly, I got a different crash in test_sre. It says: test test_sre failed -- sre.search and I also get test test_re failed -- re.search I'm also getting bizare stuff like test test_strftime crashed -- exceptions.AttributeError : match test test_tokenize crashed -- exceptions.AttributeError : compile test test_xmllib crashed -- exceptions.AttributeError : compile This is all with a CVS updated Python 2.0b1. Now if I run "./python Lib/test/test_mmap.py" manually, this succeeds, and now either the failures go away or are transmorgrified into something more reasonable: mmap, strftime, tokenize, sre, and xmllib all pass. test_re still fails, but this time with test test_re failed -- Writing: '=== Failed incorrectly', expected: "('abc', 'abc', 0, 'fou" Blowing away the Lib/test/*.pyc's doesn't seem to re-trigger the problem once it's fixed, but doing a `make distclean' and `make test' gets me back to the initial situation. Weird! -Barry From effbot at telia.com Fri Jun 30 20:12:11 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 30 Jun 2000 20:12:11 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test README,NONE,1.1 References: <20000629232733.D24811@activestate.com> <20000629235247.A25090@activestate.com> Message-ID: <037e01bfe2be$b814d5a0$f2a6b5d4@hagrid> trent wrote: > On Fri, Jun 30, 2000 at 02:39:15AM -0400, Tim Peters wrote: > > BTW, I'd just like to say what a delight it is to work with *all* of you > > folks! > > I feel a group hug coming on in the morning. Or maybe I am just moved by the > beer that I had for dinner. :) beer for dinner? what an excellent idea. didn't I have some strong lager somewhere? ah, yes... hey, maybe I should rewrite the SRE core again, to get rid of those last glitches... From effbot at telia.com Fri Jun 30 20:15:37 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 30 Jun 2000 20:15:37 +0200 Subject: [Python-Dev] Odd behavior with `make test' References: <14684.57622.9807.868551@anthem.concentric.net> Message-ID: <038601bfe2bf$31c52da0$f2a6b5d4@hagrid> > test_re still fails, but this time with > > test test_re failed -- Writing: '=== Failed incorrectly', expected: "('abc', 'abc', 0, 'fou" note that test_re should fail; someone (me?) needs to regenerate the output file. the rest looks a bit scary, to say the least. does someone (sre?) overwrite something? does anyone have purify (dmalloc, fences, whatever) within reach? From Vladimir.Marangozov at inrialpes.fr Fri Jun 30 20:22:03 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Fri, 30 Jun 2000 20:22:03 +0200 (CEST) Subject: [Python-Dev] Odd behavior with `make test' In-Reply-To: <14684.57622.9807.868551@anthem.concentric.net> from "Barry A. Warsaw" at Jun 30, 2000 02:04:06 PM Message-ID: <200006301822.UAA22606@python.inrialpes.fr> Barry A. Warsaw wrote: > > make test is behaving strangely. The first time I ran it I got On which platform? Linux seems to do fine with most of this. On AIX (after some hacking related to my previous msg "Oops on AIX", I managed to compile everything but I'll dump an error log on Trent :-) > > test test_mmap crashed -- exceptions.SyntaxError : inconsistent use of tabs and spaces in indentation same here > test test_sre failed -- sre.search > ... > test test_re failed -- re.search > ... > test test_strftime crashed -- exceptions.AttributeError : match > test test_tokenize crashed -- exceptions.AttributeError : compile > test test_xmllib crashed -- exceptions.AttributeError : compile same here. I believe Guido & al. are aware as per the checkin msg, saying that /F promises to fix this. But on AIX I get in addition to the above failures: test test_array failed -- array('b') overflowed assigning -128L -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From tim_one at email.msn.com Fri Jun 30 20:20:46 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 30 Jun 2000 14:20:46 -0400 Subject: [Python-Dev] SRE incompatibility In-Reply-To: <032701bfe2bc$23da47a0$f2a6b5d4@hagrid> Message-ID: [Tim] > I vote for backward compatibility for now, and not only because > that will irritate /F the most. [/F] > backward compatibility with what? 1.5.2. > 8-bit string literals At least, because they were in 1.5.2. > or unicode string literals? I'm sorry \x escapes are even allowed in those -- \x notation is a gimmick for making strings hold arbitrary binary data, which we're trying to get away from. To the extent that they make any sense at all in Unicode strings, \u should be used instead. > the problem here is that the pattern is compiled once (from either > 8-bit or unicode strings), and can then be used on either 8-bit or > unicode targets. to be fully backwards compatible, this means that > the compiler should use 8 bits, no matter what string type you're > using. Unicode strings weren't in 1.5.2, so there can't possibly be a backwards compatibility issue with them -- at least not in the sense I'm using the phrase here. > another solution would be to use the type of the pattern string to > choose between 8 and 16 bits. I almost implemented that, before > I realized that it broke the following rather nice property: > > sre.compile("some pattern") == sre.compile(u"some pattern") > > (well, the pattern type doesn't implement __cmp__, but you get the > idea). the current implementation guarantees "==", but I'm planning > to change that to "is" (!). Do you mean that, e.g., sre.compile("\u0045") == sre.compile(u"\u0045") too? If so, that doesn't make any sense to me (interpreting \u in 8-bit strings is even more confused than interpreting \x in Unicode strings). But if you didn't mean to include this case, then the equality doesn't actually hold now, so there's nothing to preserve . > anyway, I suspect it's too late to change this in 2.0b1. if enough > people complain about this, we can always label it a "critical bug", > and do something about it in b2. I think the real problem here was MAL's generalization of \x to 2-byte stuff in Unicode strings. If Unicode strings *have* to support \x, then \x0123456789abcdef in Unicode strings should act like \u00ef in Unicode strings, and SRE should play along with that too. \x was broken to begin with; better to wipe it out than try to generalize it. OTOH, I didn't get much sleep last night <0.8 wink>. From effbot at telia.com Fri Jun 30 20:29:54 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 30 Jun 2000 20:29:54 +0200 Subject: [Python-Dev] Odd behavior with `make test' References: <200006301822.UAA22606@python.inrialpes.fr> Message-ID: <03ae01bfe2c1$30be3300$f2a6b5d4@hagrid> > > test test_sre failed -- sre.search > > ... > > test test_re failed -- re.search > > ... > > test test_strftime crashed -- exceptions.AttributeError : match > > test test_tokenize crashed -- exceptions.AttributeError : compile > > test test_xmllib crashed -- exceptions.AttributeError : compile > > same here. I believe Guido & al. are aware as per the checkin msg, > saying that /F promises to fix this. I have no idea what causes this. however, I just noticed that evil tabs had snucked their way into sre_parse and sre_compile. new, properly untabified versions are on their way to the repository. maybe the interpreter messes up badly once -tt has reported an error? try removing -tt from the TESTPYTHON line in the makefile, and see what happens. From gward at mems-exchange.org Fri Jun 30 20:26:51 2000 From: gward at mems-exchange.org (Greg Ward) Date: Fri, 30 Jun 2000 14:26:51 -0400 Subject: [Python-Dev] Hey! who changed sys.platform?! In-Reply-To: <14684.45307.983394.125671@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Fri, Jun 30, 2000 at 10:38:51AM -0400 References: <20000629233003.A1766@beelzebub> <14684.5401.518766.362678@cj42289-a.reston1.va.home.com> <395C681D.C3211F6@lemburg.com> <14684.41320.38954.833643@cj42289-a.reston1.va.home.com> <395CA354.16AC5B7E@lemburg.com> <200006301455.JAA30721@cj20424-a.reston1.va.home.com> <395CAAAA.5975A617@lemburg.com> <20000630102242.B16350@ludwig.cnri.reston.va.us> <14684.45307.983394.125671@cj42289-a.reston1.va.home.com> Message-ID: <20000630142650.B16028@ludwig.cnri.reston.va.us> On 30 June 2000, Fred L. Drake, Jr. said: > Why would you need to figure this out? Are you selecting a > platform-specific packaging system automatically? In that case, I'd > search for the presence of the tools rather than asking what sort of > distribution you're running on -- several distros use RPM, a few use > .deb packages, etc. When the user specifies one on the command line, > just use the one they name and be done with it. Currently it's up to the user to decide which kind of built distribution they want, with stupid defaults: dumb tarball for Unix, dumb ZIP file for Windows. If you want an RPM or a Windows installer, you have to say so explicitly. This is not a big deal, but it might be nice to detect automatically if we can build (say) RPMs and do so. This is not a high-priority feature, though. I'll accept a patch if someone out there is interested enough to implement it. Greg From effbot at telia.com Fri Jun 30 20:37:16 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 30 Jun 2000 20:37:16 +0200 Subject: [Python-Dev] SRE incompatibility References: Message-ID: <03ce01bfe2c2$38308560$f2a6b5d4@hagrid> tim wrote: > > to be fully backwards compatible, this means that the compiler > > should use 8 bits, no matter what string type you're using. ... > I think the real problem here was MAL's generalization of \x to 2-byte stuff > in Unicode strings. If Unicode strings *have* to support \x, then > > \x0123456789abcdef > > in Unicode strings should act like > > \u00ef > > in Unicode strings, and SRE should play along with that too. \x was broken > to begin with; better to wipe it out than try to generalize it. I think this means that we agree -- \x is a wart that can only be used to embed *binary bytes* in a string. From Vladimir.Marangozov at inrialpes.fr Fri Jun 30 20:37:35 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Fri, 30 Jun 2000 20:37:35 +0200 (CEST) Subject: [Python-Dev] Odd behavior with `make test' In-Reply-To: <03ae01bfe2c1$30be3300$f2a6b5d4@hagrid> from "Fredrik Lundh" at Jun 30, 2000 08:29:54 PM Message-ID: <200006301837.UAA22688@python.inrialpes.fr> Fredrik Lundh wrote: > > maybe the interpreter messes up badly once -tt has reported an > error? try removing -tt from the TESTPYTHON line in the makefile, > and see what happens. Matches Barry's report exactly. To which I'll add the array('b') failure which is not due to an optimization of arraymodule.c. Will investigate this tonight. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From DavidA at ActiveState.com Fri Jun 30 20:43:14 2000 From: DavidA at ActiveState.com (David Ascher) Date: Fri, 30 Jun 2000 11:43:14 -0700 Subject: [Python-Dev] Hey! who changed sys.platform?! In-Reply-To: <200006301455.JAA30721@cj20424-a.reston1.va.home.com> Message-ID: > But I vote -1 on this one anyway -- it's too much code and almost by > its very nature not something that belongs in a "standard" library. > Plus, I don't want to be responsible for maintaining it. Sorry, > > --Guido van Rossum (home page: http://www.python.org/~guido/) Not that I hope to override the heavy -1, but I don't agree with the second point. It embodies a huge amount of knowledge that is needed to write portable code. As such, IMO, it _does_ belong in the standard library. How is it different in its nature from sys.platform, which is only a much weaker version of the same concept? --david From skip at mojam.com Fri Jun 30 19:35:20 2000 From: skip at mojam.com (Skip Montanaro) Date: Fri, 30 Jun 2000 12:35:20 -0500 (CDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Misc COPYRIGHT,1.4,1.5 In-Reply-To: <200006301841.LAA20523@slayer.i.sourceforge.net> References: <200006301841.LAA20523@slayer.i.sourceforge.net> Message-ID: <14684.55896.890339.982232@beluga.mojam.com> Fred> The new copyright / license. ... Fred> ! ... IN NO EVENT SHALL THE REGENTS OR Fred> ! CONTRIBUTORS BE LIABLE FOR ... Who are the "regents" and the "contributors"? Should those terms be defined somewhere? not-a-lawyer-and-never-wanted-to-be-ly y'rs, -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille O'Neal said: "He's got the rings. I listen to the man with the rings." From nascheme at enme.ucalgary.ca Fri Jun 30 20:53:06 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Fri, 30 Jun 2000 12:53:06 -0600 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test/output test_gc,NONE,1.1 In-Reply-To: <14684.7005.661874.713000@beluga.mojam.com>; from skip@mojam.com on Thu, Jun 29, 2000 at 11:00:29PM -0500 References: <200006300502.WAA03286@slayer.i.sourceforge.net> <14684.7005.661874.713000@beluga.mojam.com> Message-ID: <20000630125306.B32568@acs.ucalgary.ca> On Thu, Jun 29, 2000 at 11:00:29PM -0500, Skip Montanaro wrote: > I can all but guarantee you this test will always fail. Printing absolute > machine addresses (via calls to id() in this case) in test cases should be > verboten. This test script should be better. It doesn't generate any output (the stuff the old script printed was pretty useless anyhow). Neil -------------- next part -------------- import gc from test_support import * def test_list(): l = [] l.append(l) gc.collect() del l assert gc.collect() == 1 def test_dict(): d = {} d[1] = d gc.collect() del d assert gc.collect() == 1 def test_tuple(): l = [] t = (l,) l.append(t) gc.collect() del t del l assert gc.collect() == 2 def test_class(): class A: pass A.a = A gc.collect() del A assert gc.collect() > 0 def test_instance(): class A: pass a = A() a.a = a gc.collect() del a assert gc.collect() > 0 def test_method(): class A: def __init__(self): self.init = self.__init__ a = A() gc.collect() del a assert gc.collect() > 0 def test_finalizer(): class A: def __del__(self): pass class B: pass a = A() a.a = a id_a = id(a) b = B() b.b = b gc.collect() del a del b assert gc.collect() > 0 for obj in gc.garbage: if id(obj) == id_a: return raise TestFailed def test_function(): d = {} exec("def f(): pass\n") in d gc.collect() del d assert gc.collect() > 0 def test_all(): threshold = gc.get_threshold() gc.set_threshold(0) # disable automatic collection gc.collect() test_list() test_dict() test_tuple() test_class() test_instance() test_method() test_finalizer() test_function() apply(gc.set_threshold, threshold) test_all() From tim_one at email.msn.com Fri Jun 30 20:51:59 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 30 Jun 2000 14:51:59 -0400 Subject: [Python-Dev] SRE incompatibility In-Reply-To: <03ce01bfe2c2$38308560$f2a6b5d4@hagrid> Message-ID: [/F] > I think this means that we agree -- \x is a wart that can only > be used to embed *binary bytes* in a string. We certainly agree about that part! I thought my > I'm sorry \x escapes are even allowed in [u-strings] -- \x notation > is a gimmick for making strings hold arbitrary binary data, which > we're trying to get away from. To the extent that they make any > sense at all in Unicode strings, \u should be used instead. was pretty explicit . What we may still disagree on is how SRE should deal with the \x mess. I'm in favor of making \x mean "just the last byte" in plain and Unicode strings -- do the least harm with this (mis)feature. Making \x mean anything other than that for plain strings, regardless of context, is not backward compatible (with 1.5.2). And since Unicode strings haven't been released yet, it's not too late to change what they do with \x. That would make SRE's job clear here, yes? And in a way that allows the now-failing test to pass again? From skip at mojam.com Fri Jun 30 19:43:21 2000 From: skip at mojam.com (Skip Montanaro) Date: Fri, 30 Jun 2000 12:43:21 -0500 (CDT) Subject: [Python-Dev] "make test" vs. "-tt" Message-ID: <14684.56377.293211.329273@beluga.mojam.com> Per Fredrik's suggestion, I changed "-tt" to simply "-t". I've not yet done a "cvs update" to grab the tab-corrected versions of whatever files were causing the indigestion. I'm down to a single test failure (test_re) now when running "make test" before .py[co] files have been created. I noticed a couple warnings when test_mmap was running though: ./Lib/sre_compile.py: inconsistent tab/space usage ./Lib/sre_parse.py: inconsistent tab/space usage Could it be that when "-tt" detects a problem it causes a broken .py[co] file to be generated? -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille O'Neal said: "He's got the rings. I listen to the man with the rings." From DavidA at ActiveState.com Fri Jun 30 20:58:20 2000 From: DavidA at ActiveState.com (David Ascher) Date: Fri, 30 Jun 2000 11:58:20 -0700 Subject: [Python-Dev] New PythonLabs site revealed! In-Reply-To: <14684.42843.472230.609828@anthem.concentric.net> Message-ID: > That's a good point. A bump in major rev number is an /opportunity/ > to break things, like a bone that hasn't healed right, so that they > can be fixed correctly. We'll lose that for 2.0, mostly likely > because of the tight release schedule. Yes, I find that frustrating. The story for months (years?) has been that we don't break things because it's a 'dot-release', and so we've shelved improvements left and right. Now we don't have time to do those things even when it _is_ a major release. Some advance notice would have been nice. --david From fdrake at beopen.com Fri Jun 30 21:05:42 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 30 Jun 2000 15:05:42 -0400 (EDT) Subject: [Python-Dev] New PythonLabs site revealed! In-Reply-To: References: <14684.42843.472230.609828@anthem.concentric.net> Message-ID: <14684.61318.668529.402341@cj42289-a.reston1.va.home.com> David Ascher writes: > Yes, I find that frustrating. The story for months (years?) has been that > we don't break things because it's a 'dot-release', and so we've shelved > improvements left and right. Now we don't have time to do those things even > when it _is_ a major release. > > Some advance notice would have been nice. I agree, but this was news to at least some of us even Wednesday. The upside is that major releases are more likely to happen now that the precedent has been set. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one at email.msn.com Fri Jun 30 21:06:04 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 30 Jun 2000 15:06:04 -0400 Subject: [Python-Dev] New PythonLabs site revealed! In-Reply-To: Message-ID: [David Ascher, wishing he had had the opportunity to break things with 2.0] > ... > Some advance notice would have been nice. David, it would have been nice for us too <0.3 wink>. we're-not-keeping-secrets-we're-just-another-thrashing-startup-ly y'rs - tim From nascheme at enme.ucalgary.ca Fri Jun 30 21:50:52 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Fri, 30 Jun 2000 13:50:52 -0600 Subject: [Python-Dev] Windows build issues Message-ID: <20000630135052.A405@acs.ucalgary.ca> A couple of things: PCbuild/readme.txt Should be updated for the new release. PC/config.h VC++ 5.0 will not compile python20 unless "#include " is commented out. Trent? WITH_CYCLE_GC should be uncommented if we want to have GC enabled in the beta. PCbuild/python20.dsp Line endings seem to be incorrect. Someone probably edited the file on a Unix machine and munched things up. VC++ 5.0 likes DOS line endings otherwise it refuses to load the project. Also, I get a few warnings when compiling. One is about an /IZ (I think) option being ignored. There are a few other warnings as well which I didn't write down. Neil From effbot at telia.com Fri Jun 30 21:53:05 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 30 Jun 2000 21:53:05 +0200 Subject: [Python-Dev] SRE incompatibility References: Message-ID: <03f501bfe2cc$cf5dcce0$f2a6b5d4@hagrid> tim wrote: > That would make SRE's job clear here, yes? And in a way that allows the > now-failing test to pass again? sure. quoting from python-checkins: RCS file: /cvsroot/python/python/dist/src/Lib/test/output/test_sre,v ... test_sre - === Failed incorrectly ('\\x00ffffffffffffff', '\377', 0, 'found', '\377') === Failed incorrectly ('^(.+)?B', 'AB', 0, 'g1', 'A') ... still messes up on nested repetitions, but that's entirely different problem... From fdrake at beopen.com Fri Jun 30 22:23:35 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 30 Jun 2000 16:23:35 -0400 (EDT) Subject: [Python-Dev] 2.0b1 documentation online Message-ID: <14685.455.115147.446238@cj42289-a.reston1.va.home.com> See it at: http://www.python.org/doc/devel/ -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido at python.org Fri Jun 30 23:23:09 2000 From: guido at python.org (Guido van Rossum) Date: Fri, 30 Jun 2000 16:23:09 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Misc COPYRIGHT,1.4,1.5 In-Reply-To: Your message of "Fri, 30 Jun 2000 12:35:20 EST." <14684.55896.890339.982232@beluga.mojam.com> References: <200006301841.LAA20523@slayer.i.sourceforge.net> <14684.55896.890339.982232@beluga.mojam.com> Message-ID: <200006302123.QAA20537@cj20424-a.reston1.va.home.com> > Fred> The new copyright / license. > ... > Fred> ! ... IN NO EVENT SHALL THE REGENTS OR > Fred> ! CONTRIBUTORS BE LIABLE FOR ... > > Who are the "regents" and the "contributors"? Should those terms be > defined somewhere? Oops. I thought I caught all the regents and replaced them with a more politically correct term. Seems one got away. Fixed now. > not-a-lawyer-and-never-wanted-to-be-ly y'rs, Ditto, --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Fri Jun 30 23:26:21 2000 From: guido at python.org (Guido van Rossum) Date: Fri, 30 Jun 2000 16:26:21 -0500 Subject: [Python-Dev] New PythonLabs site revealed! In-Reply-To: Your message of "Fri, 30 Jun 2000 11:58:20 MST." References: Message-ID: <200006302126.QAA20621@cj20424-a.reston1.va.home.com> > > That's a good point. A bump in major rev number is an /opportunity/ > > to break things, like a bone that hasn't healed right, so that they > > can be fixed correctly. We'll lose that for 2.0, mostly likely > > because of the tight release schedule. [David Ascher] > Yes, I find that frustrating. The story for months (years?) has been that > we don't break things because it's a 'dot-release', and so we've shelved > improvements left and right. Now we don't have time to do those things even > when it _is_ a major release. You have no idea how frustration it is for me! But sometimes the marketing people force us engineers to act quickly. Just be glad I'm not following the release schedule that they had *wanted* me to use... :-) > Some advance notice would have been nice. Same here. :-) --Guido van Rossum (home page: http://www.python.org/~guido/) From nascheme at enme.ucalgary.ca Fri Jun 30 22:31:48 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Fri, 30 Jun 2000 14:31:48 -0600 Subject: [Python-Dev] Idle breakage Message-ID: <20000630143148.A9725@acs.ucalgary.ca> Caused by _sre perhaps? $ python Tools/idle/idle.py Traceback (most recent call last): File "Tools/idle/idle.py", line 8, in ? IdleConf.load(idle_dir) File "Tools/idle/IdleConf.py", line 109, in load idleconf.read((os.path.join(dir, "config.txt"), genplatfile, platfile, File "/usr/local/lib/python2.0/ConfigParser.py", line 207, in read self.__read(fp, filename) File "/usr/local/lib/python2.0/ConfigParser.py", line 382, in __read raise e ConfigParser.ParsingError: File contains parsing errors: Tools/idle/config.txt [line 21]: 'width= 80\012' [line 22]: 'height= 24\012' [line 26]: 'normal-foreground= black\012' [line 27]: 'normal-background= white\012' [line 29]: 'keyword-foreground= #ff7700\012' [line 30]: 'comment-foreground= #dd0000\012' [line 31]: 'string-foreground= #00aa00\012' [line 32]: 'definition-foreground= #0000ff\012' [line 33]: 'hilite-foreground= #000068\012' [line 34]: 'hilite-background= #006868\012' [line 35]: 'break-foreground= #ff7777\012' [line 36]: 'hit-foreground= #ffffff\012' [line 37]: 'hit-background= #000000\012' [line 38]: 'stdout-foreground= blue\012' [line 39]: 'stderr-foreground= red\012' [line 40]: 'console-foreground= #770000\012' [line 41]: 'error-background= #ff7777\012' [line 42]: 'cursor-background= black\012' [line 59]: 'enable= 0\012' [line 60]: 'style= expression\012' [line 61]: 'flash-delay= 500\012' [line 62]: 'bell= 1\012' [line 63]: 'hilite-foreground= black\012' [line 64]: 'hilite-background= #43cd80\012' From jeremy at beopen.com Fri Jun 30 22:33:01 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 30 Jun 2000 16:33:01 -0400 (EDT) Subject: [Python-Dev] New PythonLabs site revealed! In-Reply-To: <200006302126.QAA20621@cj20424-a.reston1.va.home.com> References: <200006302126.QAA20621@cj20424-a.reston1.va.home.com> Message-ID: <14685.1021.870885.796187@bitdiddle.concentric.net> >>>>> "GvR" == Guido van Rossum writes: >> That's a good point. A bump in major rev number is an >> /opportunity/ to break things, like a bone that hasn't healed >> right, so that they can be fixed correctly. We'll lose that >> for 2.0, mostly likely because of the tight release schedule. GvR> [David Ascher] >> Yes, I find that frustrating. The story for months (years?) has >> been that we don't break things because it's a 'dot-release', and >> so we've shelved improvements left and right. Now we don't have >> time to do those things even when it _is_ a major release. GvR> You have no idea how frustration it is for me! But sometimes GvR> the marketing people force us engineers to act quickly. Just GvR> be glad I'm not following the release schedule that they had GvR> *wanted* me to use... :-) Perhaps I am too easy-going, but I consider the 2.0 release a 'dot-release' masquerading as a major revision. It might be a little silly, but it seems even sillier to preserve a naming scheme that makes users think that the technology is immature. Jeremy From guido at python.org Fri Jun 30 23:33:52 2000 From: guido at python.org (Guido van Rossum) Date: Fri, 30 Jun 2000 16:33:52 -0500 Subject: [Python-Dev] Windows build issues In-Reply-To: Your message of "Fri, 30 Jun 2000 13:50:52 CST." <20000630135052.A405@acs.ucalgary.ca> References: <20000630135052.A405@acs.ucalgary.ca> Message-ID: <200006302133.QAA20696@cj20424-a.reston1.va.home.com> > A couple of things: > > PCbuild/readme.txt > > Should be updated for the new release. Tim will do this. > PC/config.h > > VC++ 5.0 will not compile python20 unless "#include > " is commented out. Trent? I'll leave this to Trent -- I don't know how to check for VC 5.0 vs. 6.0. > WITH_CYCLE_GC should be uncommented if we want to have GC > enabled in the beta. Done. > PCbuild/python20.dsp > > Line endings seem to be incorrect. Someone probably edited > the file on a Unix machine and munched things up. VC++ 5.0 > likes DOS line endings otherwise it refuses to load the > project. There was one missing CR. Fixed now. > Also, I get a few warnings when compiling. One is about an /IZ > (I think) option being ignored. There are a few other warnings > as well which I didn't write down. Probably 6.0 flags that 5.0 doesn't have. What can we do? --Guido van Rossum (home page: http://www.python.org/~guido/) From nascheme at enme.ucalgary.ca Fri Jun 30 22:40:21 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Fri, 30 Jun 2000 14:40:21 -0600 Subject: [Python-Dev] Idle breakage In-Reply-To: <20000630143148.A9725@acs.ucalgary.ca>; from nascheme@enme.ucalgary.ca on Fri, Jun 30, 2000 at 02:31:48PM -0600 References: <20000630143148.A9725@acs.ucalgary.ca> Message-ID: <20000630144021.A9847@acs.ucalgary.ca> Changing to pre fixes the problem. Neil From mwh21 at cam.ac.uk Fri Jun 30 22:50:37 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 30 Jun 2000 21:50:37 +0100 Subject: [Python-Dev] Re: Test results of linuxaudiodev.c In-Reply-To: Ka-Ping Yee's message of "Thu, 29 Jun 2000 17:44:35 -0700 (PDT)" References: Message-ID: To python-dev: Sorry for the hiatus. To python-list: does someone who knows about audio and can run linux want to play with this (Ping and I fall into just one of these categories each!). Ka-Ping Yee writes: > On 30 Jun 2000, Michael Hudson wrote: > > Yup, that works fine. Don't understand the details - and as I have my > > graduation ceremony tomorrow I'm going to go to bed and leave learning > > them until some other occasion! > > Cool. > > Okay, i just discovered sunau.py. Here's my real shot at > test_linuxaudiodev.py. Can you give this a try? > > > ---- test_linuxaudiodev.py ---- > from test_support import verbose, findfile, TestFailed > import linuxaudiodev > import os, sunau > > formats = {("ULAW", 1): linuxaudiodev.AFMT_MU_LAW, > ("NONE", 1): linuxaudiodev.AFMT_S8, > ("NONE", 2): linuxaudiodev.AFMT_S16_BE} > > def play_au_file(path): > au = sunau.open(path, "r") > data = au.readframes(sunau.AUDIO_UNKNOWN_SIZE) > au.close() > > spec = (au.getcomptype(), au.getsampwidth()) > if not has_key(formats, spec): ^^^^^^^ Oops? > raise "audio format not supported by linuxaudiodev" Maybe you mean: raise TestFailed, "audio format not supported by linuxaudiodev" ? I thought string exceptions were deprecated... > dsp = linuxaudiodev.open("w") > dsp.setparameters(au.getframerate(), au.getsampwidth() * 8, > au.getnchannels(), formats[spec]) > dsp.write(data) > dsp.close() > > def test(): > play_au_file(findfile('audiotest.au')) > > test() This doesn't work. I don't really understand why. For audiotest.au, |spec| is ("ULAW",2), which I don't think is right; file(1) says audiotest.au: Sun/NeXT audio data: 8-bit ISDN u-law, mono, 8000 Hz So I think this could be a bug in sunau. The other data (au.getframerate(), au.getnchannels()) agrees with file(1). Anybody have a better idea? Cheers, Michael Hudson, BA (as of today! woohoo!) From jeremy at beopen.com Fri Jun 30 22:57:44 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 30 Jun 2000 16:57:44 -0400 (EDT) Subject: [Python-Dev] last minute GC questions Message-ID: <14685.2504.722378.79294@bitdiddle.concentric.net> I've got two last minute questions. Does it look to you like I checked in all of the changes that you and Vladimir discussed? Might we change the strategy for deciding when to collect? There are two parts of the strategy that could probably change. The first is what kind of allocation events we count to determine when to collect. Right now, the gc is counting the net effect of allocations and deallocations. This isn't effective for at least a couple of cases. If we allocate N objects and don't deallocate anything, then no garbage is going to be created. If we have many objects currently allocated and then dealloc N objects without allocating any, we could create collectible garbage, but the collector won't run because there haven't been any allocations. It seems to me that counting deallocations only would be more effective. It is only the deallocations that cause a live object to become garbage. The other part of the strategy that might be changed is the collection frequency. Right now, the threshold is 100 net allocations & dealloactions. On the compiler benchmark, this leads to some 2600 collections, which seems like a lot. (I have no idea why it seems like a lot, but it does.) I experimented with a policy that runs the collected every N deallocations (not counting deallocations the occur during a collection). I set N == 1000 and got 1600 collections on the compiler benchmark. There is only a small speedup (just a few percent), so maybe this change doesn't have a big effect. I don't recall much about the cost/complexity of various GC approaches. Jeremy From nascheme at enme.ucalgary.ca Fri Jun 30 23:12:06 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Fri, 30 Jun 2000 15:12:06 -0600 Subject: [Python-Dev] Re: last minute GC questions In-Reply-To: <14685.2504.722378.79294@bitdiddle.concentric.net>; from jeremy@beopen.com on Fri, Jun 30, 2000 at 04:57:44PM -0400 References: <14685.2504.722378.79294@bitdiddle.concentric.net> Message-ID: <20000630151206.A10333@acs.ucalgary.ca> On Fri, Jun 30, 2000 at 04:57:44PM -0400, Jeremy Hylton wrote: > I've got two last minute questions. > > Does it look to you like I checked in all of the changes that you and > Vladimir discussed? Nope. Neil Index: 0.13/Include/objimpl.h *** 0.13/Include/objimpl.h Fri, 30 Jun 2000 13:05:40 -0600 nas (python/o/19_objimpl.h 1.1.2.1.2.1.2.1 644) --- 0.13(w)/Include/objimpl.h Fri, 30 Jun 2000 15:09:51 -0600 nas (python/o/19_objimpl.h 1.1.2.1.2.1.2.1 644) *************** *** 204,209 **** --- 204,211 ---- (PyVarObject *) PyObject_MALLOC( _PyObject_VAR_SIZE((typeobj),(n)) ),\ (typeobj), (n)) ) + #define PyObject_DEL(op) PyObject_FREE(op) + /* This example code implements an object constructor with a custom allocator, where PyObject_New is inlined, and shows the important distinction between two steps (at least): *************** *** 242,248 **** PyObject_{New, VarNew, Del} to manage the memory. Set the type flag Py_TPFLAGS_GC and define the type method tp_recurse. You should also add the method tp_clear if your object is mutable. Include ! PyGC_INFO_SIZE in the calculation of tp_basicsize. Call PyObject_GC_Init after the pointers followed by tp_recurse become valid (usually just before returning the object from the allocation method. Call PyObject_GC_Fini before those pointers become invalid --- 244,250 ---- PyObject_{New, VarNew, Del} to manage the memory. Set the type flag Py_TPFLAGS_GC and define the type method tp_recurse. You should also add the method tp_clear if your object is mutable. Include ! PyGC_HEAD_SIZE in the calculation of tp_basicsize. Call PyObject_GC_Init after the pointers followed by tp_recurse become valid (usually just before returning the object from the allocation method. Call PyObject_GC_Fini before those pointers become invalid *************** *** 255,261 **** #define PyObject_GC_Fini(op) #define PyObject_AS_GC(op) (op) #define PyObject_FROM_GC(op) (op) - #define PyObject_DEL(op) PyObject_FREE(op) #else --- 257,262 ---- *************** *** 289,295 **** /* Get the object given the PyGC_Head */ #define PyObject_FROM_GC(g) ((PyObject *)(((PyGC_Head *)g)+1)) ! #define PyObject_DEL(op) PyObject_FREE( PyObject_IS_GC(op) ? \ (ANY *)PyObject_AS_GC(op) : \ (ANY *)(op) ) --- 290,297 ---- /* Get the object given the PyGC_Head */ #define PyObject_FROM_GC(g) ((PyObject *)(((PyGC_Head *)g)+1)) ! #undef PyObject_DEL ! #define PyObject_DEL(op) PyObject_FREE( (op && PyObject_IS_GC(op)) ? \ (ANY *)PyObject_AS_GC(op) : \ (ANY *)(op) ) Index: 0.13/Objects/object.c *** 0.13/Objects/object.c Fri, 30 Jun 2000 13:05:40 -0600 nas (python/E/29_object.c 1.1.1.1.1.1.1.1.1.1.1.1 644) --- 0.13(w)/Objects/object.c Fri, 30 Jun 2000 15:05:26 -0600 nas (python/E/29_object.c 1.1.1.1.1.1.1.1.1.1.1.1 644) *************** *** 192,205 **** PyObject *op; { #ifdef WITH_CYCLE_GC ! if (PyType_IS_GC(op->ob_type)) { ! PyGC_Head *g = PyObject_AS_GC(op); ! PyObject_FREE(g); ! } else ! #endif ! { ! PyObject_FREE(op); } } #ifndef WITH_CYCLE_GC --- 192,202 ---- PyObject *op; { #ifdef WITH_CYCLE_GC ! if (op && PyType_IS_GC(op->ob_type)) { ! op = (PyObject *) PyObject_AS_GC(op); } + #endif + PyObject_FREE(op); } #ifndef WITH_CYCLE_GC From effbot at telia.com Fri Jun 30 23:20:20 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 30 Jun 2000 23:20:20 +0200 Subject: [Python-Dev] Windows build issues References: <20000630135052.A405@acs.ucalgary.ca> <200006302133.QAA20696@cj20424-a.reston1.va.home.com> Message-ID: <044b01bfe2d9$01dcee60$f2a6b5d4@hagrid> guido wrote: > > PC/config.h > > > > VC++ 5.0 will not compile python20 unless "#include > > " is commented out. Trent? > > I'll leave this to Trent -- I don't know how to check for VC 5.0 > vs. 6.0. #if _MSC_VER >= 1200 VC 6.0 #else VC 5.0 or earlier #endif (we added a similar workaround to Python/thread_nt.c) > > Also, I get a few warnings when compiling. One is about an /IZ > > (I think) option being ignored. There are a few other warnings > > as well which I didn't write down. > > Probably 6.0 flags that 5.0 doesn't have. What can we do? ignore it, for now. I remember seeing a few type warnings, but nothing critical. there's plenty of time to sort that out on the way to 2.0 final. From effbot at telia.com Fri Jun 30 23:24:06 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 30 Jun 2000 23:24:06 +0200 Subject: [Python-Dev] Idle breakage References: <20000630143148.A9725@acs.ucalgary.ca> Message-ID: <046a01bfe2d9$88302360$f2a6b5d4@hagrid> neil wrote: > Caused by _sre perhaps? > > ConfigParser.ParsingError: File contains parsing errors: Tools/idle/config.txt > [line 21]: 'width= 80\012' probably; I'll dig into this. when's the 2.0 deadline? From nascheme at enme.ucalgary.ca Fri Jun 30 23:30:08 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Fri, 30 Jun 2000 15:30:08 -0600 Subject: [Python-Dev] Fwd: Re: last minute GC questions Message-ID: <20000630153008.C10333@acs.ucalgary.ca> Oops, should have cc python-dev. ----- Forwarded message from Neil Schemenauer ----- Date: Fri, 30 Jun 2000 15:27:48 -0600 From: Neil Schemenauer Subject: Re: last minute GC questions To: Jeremy Hylton X-Url: http://www.enme.ucalgary.ca/~nascheme/ On Fri, Jun 30, 2000 at 04:57:44PM -0400, Jeremy Hylton wrote: > Might we change the strategy for deciding when to collect? We might. :) > It seems to me that counting deallocations only would be more > effective. It is only the deallocations that cause a live object to > become garbage. You can easily run out of memory with that strategy though: N = 10000 while 1: l = [] for i in xrange(N): l.append([]) l[0] = l You only get a couple of deallocations while a large amount of garbage is created. Think of large cyclic structures like graphs being created and then becoming garbage due to one deallocation. By counting the net new objects we guarantee that this doesn't happen. > The other part of the strategy that might be changed is the collection > frequency. Right now, the threshold is 100 net allocations & > dealloactions. On the compiler benchmark, this leads to some 2600 > collections, which seems like a lot. (I have no idea why it seems > like a lot, but it does.) Try setting the threshold to zero. The major part of the GC overhead does not seem to be running the collector. OTOH, the frequency could probably be decreased without the risk of running out of memory. No Python applications currently exist that create that amount of garbage anyhow. Neil ----- End forwarded message ----- From effbot at telia.com Fri Jun 30 23:39:26 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 30 Jun 2000 23:39:26 +0200 Subject: [Python-Dev] Idle breakage References: <20000630143148.A9725@acs.ucalgary.ca> <046a01bfe2d9$88302360$f2a6b5d4@hagrid> Message-ID: <049601bfe2db$acea1380$f2a6b5d4@hagrid> I wrote: > > Caused by _sre perhaps? > > > > ConfigParser.ParsingError: File contains parsing errors: Tools/idle/config.txt > > [line 21]: 'width= 80\012' > > probably; I'll dig into this. confirmed. SRE implements $ exactly as described in the library reference, RE doesn't ;-) patch coming within 30 minutes. From bwarsaw at beopen.com Fri Jun 30 23:57:19 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Fri, 30 Jun 2000 17:57:19 -0400 (EDT) Subject: [Python-Dev] Odd behavior with `make test' References: <14684.57622.9807.868551@anthem.concentric.net> <038601bfe2bf$31c52da0$f2a6b5d4@hagrid> Message-ID: <14685.6079.779817.674190@anthem.concentric.net> >>>>> "FL" == Fredrik Lundh writes: FL> the rest looks a bit scary, to say the least. does someone FL> (sre?) overwrite something? does anyone have purify (dmalloc, FL> fences, whatever) within reach? I will very soon. I found a Solaris box on which I could load up an eval copy of Purify. Will report back soon. -Barry From klm at digicool.com Thu Jun 1 00:03:31 2000 From: klm at digicool.com (Ken Manheimer) Date: Wed, 31 May 2000 18:03:31 -0400 (EDT) Subject: [Python-Dev] SIG: python-lang In-Reply-To: <643145F79272D211914B0020AFF640190BAA8F@gandalf.digicool.com> Message-ID: On Wed, 31 May 2000, Ka-Ping Yee wrote: > Hey, i admit it's a bit primitive, but it seems significantly > better than nothing. The software people at ILM have coped > with it fairly well for a year, and for the most part we like it. I'm not sure about the requirements - particularly, submissions and correspondence about bugs via email, which my zope "tracker" doesn't do - but the tracker may be worth looking at, also: http://www.zope.org/Members/klm/SoftwareCarpentry (See the prototype tracker, mentioned there, or my "tracker tracker" at http://www.zope.org/Members/klm/Tracker , for flagrant, embarrassing exposure of the outstanding tracker complaints...) (I haven't had the time to take care of the tracker as i would like, or to look at how tracker and roundup could inform eachother - but i haven't even gotten as far as examining that. I get the feeling they take fairly different approaches - which could mean neat synergy, or total disconnection. Ping, any thoughts?) Ken klm at digicool.com From fdrake at acm.org Thu Jun 1 00:17:02 2000 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Wed, 31 May 2000 18:17:02 -0400 (EDT) Subject: [Python-Dev] Adding LDAP to the Python core... ?! In-Reply-To: References: <14645.17446.749848.895965@anthem.python.org> Message-ID: <14645.36702.769794.807329@cj42289-a.reston1.va.home.com> Greg Stein writes: > My WebDAV module implements an established protocol (an RFC tends to do > that :-), but the API within the module is still in flux (IMO). I'd love to see this sort of thing added to the standard library, esp. once packages are used there. Especially if the implementation is pure Python (which I think your WebDAV stuff is, right?) > Is the LDAP module's API pretty solid? Is it changing? This I don't know. > And is this module a C extension, or a pure Python implementation? Mixed, I think. There is definately a C component. I'd rather it be pure Python, but I think it's a SWIGged wrapper around a C client library. Is anyone talking to the developer about this yet? -Fred -- Fred L. Drake, Jr. PythonLabs at BeOpen.com From gstein at lyra.org Thu Jun 1 00:27:04 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 31 May 2000 15:27:04 -0700 (PDT) Subject: [Python-Dev] Adding LDAP to the Python core... ?! In-Reply-To: <14645.36702.769794.807329@cj42289-a.reston1.va.home.com> Message-ID: On Wed, 31 May 2000, Fred L. Drake, Jr. wrote: > Greg Stein writes: > > My WebDAV module implements an established protocol (an RFC tends to do > > that :-), but the API within the module is still in flux (IMO). > > I'd love to see this sort of thing added to the standard library, > esp. once packages are used there. Especially if the implementation > is pure Python (which I think your WebDAV stuff is, right?) davlib.py is pure Python, building upon my upgraded httplib.py and xml.utils.qp_xml (and pyexpat) [ and recall my email last week that I've updated httplib.py and posted it to my web pages; it is awaiting review for integration into the Python core; it still needs docs and more testing scenarios, tho http://www.python.org/pipermail/python-dev/2000-May/005643.html ] davlib will probably be a 1.7 item. It still needs some heavy work to easily deal with authentication (which is usually going to be required for DAV operations). Cheers, -g -- Greg Stein, http://www.lyra.org/ From mhammond at skippinet.com.au Thu Jun 1 00:53:15 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Thu, 1 Jun 2000 08:53:15 +1000 Subject: [Python-Dev] SIG: python-lang In-Reply-To: Message-ID: [Ken writes] > I'm not sure about the requirements - particularly, submissions and > correspondence about bugs via email, which my zope "tracker" doesn't do - > but the tracker may be worth looking at, also: > > http://www.zope.org/Members/klm/SoftwareCarpentry > Another alternative could be Bugzilla: http://bugzilla.mozilla.org/ Sources at: http://www.mozilla.org/bugs/source.html Has many of the features people seem to want, and obviously supports large projects - which may be the biggest problem - it may be too "heavy" for our requirement... Mark. From fdrake at acm.org Thu Jun 1 03:30:28 2000 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Wed, 31 May 2000 21:30:28 -0400 (EDT) Subject: [Python-Dev] Adding LDAP to the Python core... ?! In-Reply-To: References: <14645.36702.769794.807329@cj42289-a.reston1.va.home.com> Message-ID: <14645.48308.347086.279280@cj42289-a.reston1.va.home.com> Greg Stein writes: > davlib.py is pure Python, building upon my upgraded httplib.py and > xml.utils.qp_xml (and pyexpat) So the dependencies are definately an issue. > [ and recall my email last week that I've updated httplib.py and posted it > to my web pages; it is awaiting review for integration into the Python > core; it still needs docs and more testing scenarios, tho > > http://www.python.org/pipermail/python-dev/2000-May/005643.html > ] Jeremy, were you looking at this? > davlib will probably be a 1.7 item. It still needs some heavy work to > easily deal with authentication (which is usually going to be required for Sounds good to me; let's take a look at it in 3 or 4 months. I'd hope to have at least preliminary reference documentation for review. -Fred -- Fred L. Drake, Jr. PythonLabs at BeOpen.com From skip at mojam.com Thu Jun 1 15:48:41 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 1 Jun 2000 08:48:41 -0500 (CDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Objects listobject.c,2.69,2.70 stringobject.c,2.65,2.66 tupleobject.c,2.33,2.34 In-Reply-To: <200006010312.UAA10844@slayer.i.sourceforge.net> References: <200006010312.UAA10844@slayer.i.sourceforge.net> Message-ID: <14646.27065.279988.93102@beluga.mojam.com> Fred> Log Message: Fred> Michael Hudson : Fred> Removed PyErr_BadArgument() calls and replaced them with more Fred> useful error messages. ... Fred> --- 389,395 ---- Fred> PyListObject *np; Fred> if (!PyList_Check(bb)) { Fred> ! PyErr_Format(PyExc_TypeError, Fred> ! "can only append list (not \"%.200s\") to list", Fred> ! bb->ob_type->tp_name); Fred> return NULL; Fred> } Fred> *************** ... I've seen this new error message cross my mailbox a few times. On the face of it, it's incorrect, because you can append any sort of object to a list, right? This message appears in the list_concat method. Shouldn't it be something like can't concatenate \"%.200s\" object with list ? I would consider this change very picky except for the fact that it's making a statement about the properties of lists that is clearly not true. -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ "We have become ... the stewards of life's continuity on earth. We did not ask for this role... We may not be suited to it, but here we are." - Stephen Jay Gould From fdrake at acm.org Thu Jun 1 16:29:17 2000 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Thu, 1 Jun 2000 10:29:17 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Objects listobject.c,2.69,2.70 stringobject.c,2.65,2.66 tupleobject.c,2.33,2.34 In-Reply-To: <14646.27065.279988.93102@beluga.mojam.com> References: <200006010312.UAA10844@slayer.i.sourceforge.net> <14646.27065.279988.93102@beluga.mojam.com> Message-ID: <14646.29501.378585.828457@cj42289-a.reston1.va.home.com> Skip Montanaro writes: > I've seen this new error message cross my mailbox a few times. On the face > of it, it's incorrect, because you can append any sort of object to a list, > right? This message appears in the list_concat method. Shouldn't it be > something like > > can't concatenate \"%.200s\" object with list Skip, You're right! How about: can only concatenate list (not \"%.200s\") to list If you don't object by the time this mail reaches you, I'll check it in. ;) -Fred -- Fred L. Drake, Jr. PythonLabs at BeOpen.com From mwh21 at cam.ac.uk Thu Jun 1 17:39:59 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: Thu, 1 Jun 2000 16:39:59 +0100 (BST) Subject: [Python-Dev] CVS: python/dist/src/Objects listobject.c,2.69,2.70 and friends In-Reply-To: <14646.29501.378585.828457@cj42289-a.reston1.va.home.com> Message-ID: On Thu, 1 Jun 2000, Fred L. Drake, Jr. wrote: > > Skip Montanaro writes: > > I've seen this new error message cross my mailbox a few times. On the face > > of it, it's incorrect, because you can append any sort of object to a list, > > right? This message appears in the list_concat method. Shouldn't it be > > something like > > > > can't concatenate \"%.200s\" object with list > > Skip, > You're right! How about: > > can only concatenate list (not \"%.200s\") to list > > If you don't object by the time this mail reaches you, I'll check it > in. ;) Then you'd better do something about tupleobject.c as well; I'd also say can only concatenate list (not \"%.200s\") and list can only concatenate tuple (not \"%.200s\") and tuple are slightly preferable, on reflection (note the s/to/and/). Cheers, Michael From andy at reportlab.com Thu Jun 1 18:23:36 2000 From: andy at reportlab.com (Andy Robinson) Date: Thu, 1 Jun 2000 17:23:36 +0100 Subject: [Python-Dev] SIG: python-lang Message-ID: It seems to me that the main problem is that comp.lang.python is too big to follow. So why not split it? I don't know the right subgroups, but if (say) comp.lang.python.language focusses on the core language, it might enable people to start reading it again. I asked this twice on c.l.p, one year ago and two years ago, and the answer was always "the traffic is too low". I used to subscribe to the NeXTSteap groups, and splitting worked really well there. - Andy Robinson From mal at lemburg.com Thu Jun 1 15:10:42 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 01 Jun 2000 15:10:42 +0200 Subject: [Python-Dev] Adding LDAP to the Python core... ?! References: Message-ID: <393660D2.4926E5C1@lemburg.com> Greg Stein wrote: > > On Wed, 31 May 2000, Barry A. Warsaw wrote: > > >>>>> "M" == M writes: > > > > M> Would there be interest in adding the python-ldap module > > M> (http://sourceforge.net/project/?group_id=2072) to the > > M> core distribution ? > > > > I haven't looked at this stuff, but yes, I think a standard LDAP > > module would be quite useful. It's a well enough established > > protocol, and it would be good to be able to count on it "being > > there". > > My WebDAV module implements an established protocol (an RFC tends to do > that :-), but the API within the module is still in flux (IMO). > > Is the LDAP module's API pretty solid? Is it changing? It is closing in on version 2.0 -- not sure how much it still changes. I just thought I'd query here before asking Daniel about his thoughts on including the module in the core (wouldn't make much sense if there was no interest). > And is this module a C extension, or a pure Python implementation? It's a Python module which uses a C wrapper to interface to OpenLDAP, which is a portable C lib dealing with all aspects of LDAP. There are at least two other projects built on top of python-ldap (see Parnassus for infos). I just thought I'd mention it here, because LDAP is certainly a widely used protocol in the corporate world and many decision makers have this on their list of buzz words. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gward at mems-exchange.org Thu Jun 1 23:01:41 2000 From: gward at mems-exchange.org (Greg Ward) Date: Thu, 1 Jun 2000 17:01:41 -0400 Subject: [Python-Dev] What's that sound? In-Reply-To: <393547A2.30CB7113@prescod.net>; from paul@prescod.net on Wed, May 31, 2000 at 12:10:58PM -0500 References: <39353CCD.1F3E9A0B@prescod.net> <14645.17611.318538.986772@anthem.python.org> <393547A2.30CB7113@prescod.net> Message-ID: <20000601170140.A24794@mems-exchange.org> On 31 May 2000, Paul Prescod said: > Look closer, big-egoed-four-stringed-guitar-playing-one. It could just > as easily be a J. > > And you know what you get when you put P and J together? Pajamas! Yes, that's right, when Python takes over the world, we'll all have to sleep BUCK NAKED!!! (What was that about "zero noise" on python-dev? Oh well, we must have our fun...) Greg From esr at snark.thyrsus.com Fri Jun 2 00:36:29 2000 From: esr at snark.thyrsus.com (Eric S. Raymond) Date: Thu, 1 Jun 2000 18:36:29 -0400 Subject: [Python-Dev] ascii.py? Message-ID: <200006012236.SAA03578@snark.thyrsus.com> There has been a vast and echoing silence about the ascii.py module I posted here at Fred Drake's request. Is it really such a bad idea? -- Eric S. Raymond "Those who make peaceful revolution impossible will make violent revolution inevitable." -- John F. Kennedy From pingster at ilm.com Fri Jun 2 00:33:19 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Thu, 1 Jun 2000 15:33:19 -0700 (PDT) Subject: [Python-Dev] ascii.py? In-Reply-To: <200006012236.SAA03578@snark.thyrsus.com> Message-ID: On Thu, 1 Jun 2000, Eric S. Raymond wrote: > There has been a vast and echoing silence about the ascii.py module I > posted here at Fred Drake's request. Is it really such a bad idea? Don't look at me. I'm busy working on inspect and htmldoc. :) Actually, i guess i probably didn't respond because it isn't of immediate use to me. Maybe this is the sort of thing that might come in handy one day but that hordes of people aren't desperate for. Hmm. Perhaps it's because people are used to saying "in string.digits" instead of wanting isdigit() &c. Hmm. Perhaps it's also something that ought to be eventually handled via the Unicode character property route. Dunno. -- ?!ng "China is a big country, inhabited by many Chinese." -- Former French President Charles de Gaulle From gstein at lyra.org Fri Jun 2 00:34:13 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 1 Jun 2000 15:34:13 -0700 (PDT) Subject: [Python-Dev] ascii.py? In-Reply-To: <200006012236.SAA03578@snark.thyrsus.com> Message-ID: On Thu, 1 Jun 2000, Eric S. Raymond wrote: > There has been a vast and echoing silence about the ascii.py module I > posted here at Fred Drake's request. Is it really such a bad idea? hehe... I'd say silence implies a +0 from people ("seems reasonable to go in, but I wouldn't be upset if it doesn't"). If people thought it was bad, then you'd hear about it :-) I took a quick look at it. Doesn't seem too bad, but I can't think of anything that I've done in a long while that would require it. So I can't really say "wow! put that baby in the distro!" YMMV, of course :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From esr at thyrsus.com Fri Jun 2 00:51:45 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 1 Jun 2000 18:51:45 -0400 Subject: [Python-Dev] ascii.py? In-Reply-To: ; from gstein@lyra.org on Thu, Jun 01, 2000 at 03:34:13PM -0700 References: <200006012236.SAA03578@snark.thyrsus.com> Message-ID: <20000601185145.A3667@thyrsus.com> Greg Stein : > I took a quick look at it. Doesn't seem too bad, but I can't think of > anything that I've done in a long while that would require it. So I can't > really say "wow! put that baby in the distro!" It starts to get pretty useful in conjunction with curses -- for example, in writing interpreters for character-at-a-time command loops. I have a new version that adds the following: \begin{funcdesc}{ascii}{c} Return the ASCII value corresponding to the low 7 bits of c. \end{funcdesc} The following function takes either a single-character string or integer byte value; it returns a string. \begin{funcdesc}{unctrl}{c} Return a string representation of the ASCII character c. If c is printable, this string is the character itself. If the character is a control character (0x00-0x1f) the string consists of a caret (^) followed by the corresponding uppercase letter. If the character is an ASCII delete (0x7f) the string is "^?". If the character has its meta bit (0x80) set, the meta bit is stripped, the preceding rules applied, and "!" prepended to the result. \end{funcdesc} Finally, the module supplies a 33-element string array called controlnames that contains the ASCII mnemonics for the thirty-two ASCII control characters from 0 (NUL) to 0x1f (US), in order, plus the mnemonic "SP" for space. -- Eric S. Raymond Certainly one of the chief guarantees of freedom under any government, no matter how popular and respected, is the right of the citizens to keep and bear arms. [...] the right of the citizens to bear arms is just one guarantee against arbitrary government and one more safeguard against a tyranny which now appears remote in America, but which historically has proved to be always possible. -- Hubert H. Humphrey, 1960 From akuchlin at cnri.reston.va.us Fri Jun 2 01:32:32 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Thu, 1 Jun 2000 19:32:32 -0400 Subject: [Python-Dev] ascii.py? In-Reply-To: <200006012236.SAA03578@snark.thyrsus.com>; from esr@snark.thyrsus.com on Thu, Jun 01, 2000 at 06:36:29PM -0400 References: <200006012236.SAA03578@snark.thyrsus.com> Message-ID: <20000601193232.A12831@newcnri.cnri.reston.va.us> On Thu, Jun 01, 2000 at 06:36:29PM -0400, Eric S. Raymond wrote: >There has been a vast and echoing silence about the ascii.py module I >posted here at Fred Drake's request. Is it really such a bad idea? One misgiving I had was locales; is it a bug or a feature that locales aren't supported, as they are for the C isdigit(), isalpha(), &c, functions? I'm not entirely sure which it is. (The locale module doesn't expose the C is*() functions, though I think they're used in constructing string.letters.) --amk From esr at thyrsus.com Fri Jun 2 01:45:11 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 1 Jun 2000 19:45:11 -0400 Subject: [Python-Dev] ascii.py? In-Reply-To: <20000601193232.A12831@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Thu, Jun 01, 2000 at 07:32:32PM -0400 References: <200006012236.SAA03578@snark.thyrsus.com> <20000601193232.A12831@newcnri.cnri.reston.va.us> Message-ID: <20000601194511.A3948@thyrsus.com> Andrew Kuchling : > On Thu, Jun 01, 2000 at 06:36:29PM -0400, Eric S. Raymond wrote: > >There has been a vast and echoing silence about the ascii.py module I > >posted here at Fred Drake's request. Is it really such a bad idea? > > One misgiving I had was locales; is it a bug or a feature that locales > aren't supported, as they are for the C isdigit(), isalpha(), &c, > functions? I'm not entirely sure which it is. (The locale module > doesn't expose the C is*() functions, though I think they're used in > constructing string.letters.) It's a feature. That's why this module is called ascii, not string :-) -- Eric S. Raymond "...quemadmodum gladius neminem occidit, occidentis telum est." [...a sword never kills anybody; it's a tool in the killer's hand.] -- (Lucius Annaeus) Seneca "the Younger" (ca. 4 BC-65 AD), From paul at prescod.net Fri Jun 2 05:53:41 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 01 Jun 2000 22:53:41 -0500 Subject: [Python-Dev] ascii.py? References: <200006012236.SAA03578@snark.thyrsus.com> Message-ID: <39372FC5.DE1CE8EA@prescod.net> "Eric S. Raymond" wrote: > > There has been a vast and echoing silence about the ascii.py module I > posted here at Fred Drake's request. Is it really such a bad idea? Without looking closely, or even being particularly knowledgable (how's that for a disclaimer!) my instinctive reaction was: "does the ASCII subset of Unicode need its own module just before we add Unicode to the language?" It may be that there are some semantics of ASCII that are not captured in the Unicode spec. and thus are not generalizable. I'm pretty confident that these ones ARE generalizable: isalnum isalpha isascii islower isupper isspace isxdigit How do Unicode users get this information from the famous Unicode database and why not merge the Unicode and ASCII versions in 1.6? -- Paul Prescod - ISOGEN Consulting Engineer speaking for himself Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From esr at thyrsus.com Fri Jun 2 07:43:54 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 2 Jun 2000 01:43:54 -0400 Subject: [Python-Dev] ascii.py? In-Reply-To: <39372FC5.DE1CE8EA@prescod.net>; from paul@prescod.net on Thu, Jun 01, 2000 at 10:53:41PM -0500 References: <200006012236.SAA03578@snark.thyrsus.com> <39372FC5.DE1CE8EA@prescod.net> Message-ID: <20000602014353.A5211@thyrsus.com> Paul Prescod : > "Eric S. Raymond" wrote: > > > > There has been a vast and echoing silence about the ascii.py module I > > posted here at Fred Drake's request. Is it really such a bad idea? > > Without looking closely, or even being particularly knowledgable (how's > that for a disclaimer!) my instinctive reaction was: "does the ASCII > subset of Unicode need its own module just before we add Unicode to the > language?" > > It may be that there are some semantics of ASCII that are not captured > in the Unicode spec. and thus are not generalizable. ascii.ctrl is one such. > I'm pretty > confident that these ones ARE generalizable: > > isalnum > isalpha > isascii > islower > isupper > isspace > isxdigit > > How do Unicode users get this information from the famous Unicode > database and why not merge the Unicode and ASCII versions in 1.6? Answer: ascii.py is not designed for text processing. I wrote it to package some functions useful for classifying *ASCII* data, especially in the context of roguelike programs that interpret keystrokes coming in through a curses interface. (Where this all touches ground is CML2, my replacement configuration system for the Linux kernel.) -- Eric S. Raymond ..every Man has a Property in his own Person. This no Body has any Right to but himself. The Labour of his Body, and the Work of his Hands, we may say, are properly his. .... The great and chief end therefore, of Mens uniting into Commonwealths, and putting themselves under Government, is the Preservation of their Property. -- John Locke, "A Treatise Concerning Civil Government" From gstein at lyra.org Fri Jun 2 10:43:13 2000 From: gstein at lyra.org (Greg Stein) Date: Fri, 2 Jun 2000 01:43:13 -0700 (PDT) Subject: [Python-Dev] httplib (was: Adding LDAP to the Python core... ?!) In-Reply-To: <14645.51445.963154.817309@localhost.localdomain> Message-ID: It looks like a definite bug. I have *no* idea, tho, why it is doing that... I did quite a bit of testing with chunked replies. Admittedly, though, I didn't stack up requests like you've done in your test. I'm wrapping up mod_dav at the moment, so I don't really have time to look deeply into this. Mebbe next week? Regarding the pipeline request thing. I think it would probably be best to just drop the whole "hold the previous response and wait for it to be closed" thing. I don't know why that is in there; probably a leftover (converted) semantic from the old-style HTTP() class. I'd be quite fine just axing it and allowing the client to shove ten requests down the pipe before pulling the first response back out. Oh. Wait. Maybe that was it. You can't read the "next" response until the first one has been read. Well... no need to block putting new responses; we just need to create a way to "get the next reply" and/or "can I get the next reply yet?" Cheers, -g p.s. Moshe also had a short list of review items. I read thru them, but not with the code in hand to understand some of his specifics. On Wed, 31 May 2000, Jeremy Hylton wrote: > >>>>> "GS" == Greg Stein writes: > > GS> [ and recall my email last week that I've updated httplib.py and > GS> posted it to my web pages; it is awaiting review for integration > GS> into the Python core; it still needs docs and more testing > GS> scenarios, tho > > I've been looking at the httplib code, and I found what may be a bug. > Not sure, because I'm not sure how the API works for pipelined > requests. > > I've got some test code that looks a bit like this: > > def test_new_interface_series(urls): > paths = [] > the_host = None > for url in urls: > host, path = get_host_and_path(url) > if the_host is None: > the_host = host > else: > assert host == the_host > paths.append(path) > > conn = httplib.HTTPConnection(the_host) > for path in paths: > conn.request('GET', path, headers={'User-Agent': 'httplib/Python'}) > for path in paths: > errcode, errmsg, resp = conn.getreply() > buf = resp.read() > if errcode == 200: > print errcode, resp.headers > else: > print errcode, `errmsg`, resp > print resp.getheader('Content-Length'), len(buf) > print repr(buf[:40]) > print repr(buf[-40:]) > print > conn.close() > > test_new_interface_series(['http://www.python.org/', > 'http://www.python.org/pics/PyBanner054.gif', > 'http://www.python.org/pics/PythonHi.gif', > 'http://www.python.org/Jobs.html', > 'http://www.python.org/doc/', > 'http://www.python.org/doc/current/', > ]) > > The second loop that reads the replies gets fouled up after a couple > of responses. I added even more debugging and found that the first > line of the corrupted response is > > > 'ontent-Type: text/html\015\012' > > It looks like some part of the program is consuming too much input. I > haven't been able to figure out what part yet. Hoping that you might > have some good ideas. > > Thinking about this issue, I came up with a potential API problem. > You must read the body after calling getreply and before calling > getreply a second time. This kind of implicit requirement is a bit > tricky. It would help if the implementation could raise an error if > this happens. It might be even better if it just worked, although it > seems a bit too magical. > > Jeremy > -- Greg Stein, http://www.lyra.org/ From mal at lemburg.com Fri Jun 2 10:11:05 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 02 Jun 2000 10:11:05 +0200 Subject: [Python-Dev] Re: [Patches] Translating doc strings References: <200006020701.JAA28620@pandora> Message-ID: <39376C19.53A01A27@lemburg.com> Martin von Loewis wrote: > > To simplify usage of Python for people who don't speak English well, > I'd like to start a project translating the doc strings in the Python > library. This has two aspects: > > 1. there must be a simple way to access the translated doc strings Do you plan to use GNU gettext here ? (This would cause the translated version of Python to fall under GPL, AFAIK) I'd propose to use the existing doc-strings as keys to a translation mapping. This assures that existing doc-strings remain intact and that the actual translation process is done at query time, e.g. by using a help() built-in function. > 2. there must be actual translations to the various native languages > of Python users. > > Since the second task is much more complicated, I submit a snapshot of > this project, namely, a message catalog of the doc strings in the > Python libraries, taken from the CVS; along with a snapshot of the > German translations. I intend to complete the German translations in > the coming weeks, but I want to give other translators a chance to > also start working on that. > > Please note that extracting the docstrings was not straight-forward; > I've used Fran?ois Pinard's most excellent po-utils 0.5 as a starting > point, and enhanced it with the capability to recognize __doc__[] in C > code, so that I would also get (most of) the doc strings in C modules. > I plan to update this catalog a few times before Python 1.6 is > released, so that translators can update their translations. > > A key point is finding translators. I propose to use the > infrastructure of the GNU translation project for that: There are > established teams for all major languages, and an infrastructure (also > maintained by Fran?ois) where notifications about new catalogs are > automatically distributed to the teams. That should not stop > volunteers which don't currently participate in the GNU translation > project from translating - however, they should announce that they > plan to work on translating these messages to avoid duplication of > work. This will only work iff the translations can be submitted via the usual "post to patches with dislcaimer" method... aren't the GNU people interested in putting the translations under the GPL ? > Another matter is where the catalogs should live in the Python source > tree. I propose to have a Misc/po directory, which will contain both > the PO catalogues, as well as the binary .mo objects; only the latter > will be installed during the installation process. > > Please let me know what you think, in particular, whether I can submit > the catalog to the translation teams. > > Regards, > Martin > > --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > Name: doc.tgz > doc.tgz Type: unspecified type (application/octet-stream) > Encoding: base64 -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Fri Jun 2 09:55:04 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 02 Jun 2000 09:55:04 +0200 Subject: [Python-Dev] ascii.py? References: <200006012236.SAA03578@snark.thyrsus.com> <20000601193232.A12831@newcnri.cnri.reston.va.us> Message-ID: <39376858.55D4F778@lemburg.com> Andrew Kuchling wrote: > > On Thu, Jun 01, 2000 at 06:36:29PM -0400, Eric S. Raymond wrote: > >There has been a vast and echoing silence about the ascii.py module I > >posted here at Fred Drake's request. Is it really such a bad idea? > > One misgiving I had was locales; is it a bug or a feature that locales > aren't supported, as they are for the C isdigit(), isalpha(), &c, > functions? I'm not entirely sure which it is. (The locale module > doesn't expose the C is*() functions, though I think they're used in > constructing string.letters.) FYI, both strings and Unicode object already have a few .isXXX() methods: isdigit(), islower(), isspace(), istitle(), isupper() For strings these use the C APIs (which are locale aware), for Unicode the built in mappings are used. BTW, I haven't looked at the docs lately, but are the string and Unicode methods already documented ? All of them have doc-strings, so it should be easy extracting the data to build a TeX-file. On the topic of adding ascii.py, I'm +0 -- I don't currently have a need for it, but writing .append(ascii.CR + ascii.LF) does add to the readability of scripts. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Fri Jun 2 10:02:35 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 02 Jun 2000 10:02:35 +0200 Subject: [I18n-sig] Re: [Python-Dev] ascii.py? References: <200006012236.SAA03578@snark.thyrsus.com> <39372FC5.DE1CE8EA@prescod.net> Message-ID: <39376A1B.10E45C7B@lemburg.com> Paul Prescod wrote: > > "Eric S. Raymond" wrote: > > > > There has been a vast and echoing silence about the ascii.py module I > > posted here at Fred Drake's request. Is it really such a bad idea? > > Without looking closely, or even being particularly knowledgable (how's > that for a disclaimer!) my instinctive reaction was: "does the ASCII > subset of Unicode need its own module just before we add Unicode to the > language?" > > It may be that there are some semantics of ASCII that are not captured > in the Unicode spec. and thus are not generalizable. I'm pretty > confident that these ones ARE generalizable: > > isalnum > isalpha > isascii > islower > isupper > isspace > isxdigit > > How do Unicode users get this information from the famous Unicode > database and why not merge the Unicode and ASCII versions in 1.6? Note that many of the above are already implemented as string|Unicode methods. The Unicode database is accessible via the unicodedata module. The specs for the used APIs and constants can be found in the Unicode database description file on www.unicode.org. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From loewis at informatik.hu-berlin.de Fri Jun 2 14:33:07 2000 From: loewis at informatik.hu-berlin.de (Martin von Loewis) Date: Fri, 2 Jun 2000 14:33:07 +0200 (MET DST) Subject: [Python-Dev] Re: [Patches] Translating doc strings In-Reply-To: <39376C19.53A01A27@lemburg.com> (mal@lemburg.com) References: <200006020701.JAA28620@pandora> <39376C19.53A01A27@lemburg.com> Message-ID: <200006021233.OAA16962@pandora> > Do you plan to use GNU gettext here ? (This would cause the > translated version of Python to fall under GPL, AFAIK) No, I plan to use the Python gettext module, which is currently being integrated into Python. It will either use the system's gettext library, or read mo files using pure Python. > I'd propose to use the existing doc-strings as keys to > a translation mapping. This assures that existing doc-strings > remain intact and that the actual translation process is > done at query time, e.g. by using a help() built-in function. This is more or less what I've planned. I'd propose to call the function doc, with an interface like >>> doc(time.time) time() -> Gleitkommazahl Gib die aktuelle Zeit in Sekunden seit Beginn der Epoche zur?ck. Sekundenbruchteile sind vorhanden, falls die Systemuhr sie bereitstellt. It won't use a dictionary, though, but the underlying gettext query mechanism. Exact naming and parameters are certainly subject to discussion, my proposal would be doc(object, doprint=1, translate=1) so that users save quite some typing over >>> print time.time.__doc__ time() -> floating point number Return the current time in seconds since the Epoch. Fractions of a second may be present if the system clock provides them. > This will only work iff the translations can be submitted > via the usual "post to patches with dislcaimer" method... > aren't the GNU people interested in putting the translations > under the GPL ? Is it really necessary to have the translations posted to patches at python.org? Or would it be sufficient if translators express their disclaimer in some other way. I don't think the translation teams are "the GNU people"; the translators accepted to assign their copyright to the FSF for the translations they did - I'd assume at least some of them would also accept maintaining the copyright, or assigning it to the Python Consortium (or whoever else wants it). It's more that the Python distributor would need to make suggestions what the copyright on translations should be - I'm sure that could be clearly communicated to the translators. Regards, Martin From fdrake at acm.org Fri Jun 2 14:50:35 2000 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Fri, 2 Jun 2000 08:50:35 -0400 (EDT) Subject: [Python-Dev] ascii.py? In-Reply-To: <200006012236.SAA03578@snark.thyrsus.com> References: <200006012236.SAA03578@snark.thyrsus.com> Message-ID: <14647.44443.651246.979946@cj42289-a.reston1.va.home.com> Eric S. Raymond writes: > There has been a vast and echoing silence about the ascii.py module I > posted here at Fred Drake's request. Is it really such a bad idea? Did you get my comments? -Fred -- Fred L. Drake, Jr. PythonLabs at BeOpen.com From bwarsaw at python.org Fri Jun 2 15:37:42 2000 From: bwarsaw at python.org (Barry A. Warsaw) Date: Fri, 2 Jun 2000 09:37:42 -0400 (EDT) Subject: [Python-Dev] Re: [Patches] Translating doc strings References: <200006020701.JAA28620@pandora> <39376C19.53A01A27@lemburg.com> <200006021233.OAA16962@pandora> Message-ID: <14647.47270.330318.807347@anthem.python.org> >>>>> "MvL" == Martin von Loewis writes: MvL> No, I plan to use the Python gettext module, which is MvL> currently being integrated into Python. It will either use MvL> the system's gettext library, or read mo files using pure MvL> Python. pygettext is in Tools/i18n, and I've been working with James Henstridge and Peter Funk on getting a standard gettext module integrated into the core. A few other things have bumped that down on my list, but it's still there. We'll still need xgettext to scan the C code. Also, marking Python module docstrings is a bit problematic. I've resorted to Something Really Ugly: -------------------- snip snip -------------------- try: import fintl _ = fintl.gettext except ImportError: def _(s): return s __doc__ = _("""pygettext -- Python equivalent of xgettext(1) ...") -------------------- snip snip -------------------- Yuck. -Barry From pf at artcom-gmbh.de Fri Jun 2 15:57:32 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Fri, 2 Jun 2000 15:57:32 +0200 (MEST) Subject: [Python-Dev] Re: [Patches] Translating doc strings In-Reply-To: <14647.47270.330318.807347@anthem.python.org> from "Barry A. Warsaw" at "Jun 2, 2000 9:37:42 am" Message-ID: Hi, [Barry A. Warsaw]: > pygettext is in Tools/i18n, and I've been working with James > Henstridge and Peter Funk on getting a standard gettext module > integrated into the core. A few other things have bumped that down on > my list, but it's still there. I will try to make some progress. Currently I'm not sure how to define a class 'Translator' ... I'm open for suggestions. James has also made some interesting points. > We'll still need xgettext to scan the C code. Also, marking Python > module docstrings is a bit problematic. I've resorted to Something > Really Ugly: > > -------------------- snip snip -------------------- > try: > import fintl > _ = fintl.gettext > except ImportError: > def _(s): return s > > > __doc__ = _("""pygettext -- Python equivalent of xgettext(1) > ...") > -------------------- snip snip -------------------- > > Yuck. I agree: this is really ugly. Since doc-strings are something special, I don't think, we should travel further down this road. I believe, we should use a special doc-string extration-tool (possibly build on top of ping's 'inspect.py'?), which will then create a .pot-file solely out of __doc__-strings. Regards, Peter. From loewis at informatik.hu-berlin.de Fri Jun 2 17:03:50 2000 From: loewis at informatik.hu-berlin.de (Martin von Loewis) Date: Fri, 2 Jun 2000 17:03:50 +0200 (MET DST) Subject: [Python-Dev] Re: [Patches] Translating doc strings In-Reply-To: <14647.47270.330318.807347@anthem.python.org> (bwarsaw@python.org) References: <200006020701.JAA28620@pandora> <39376C19.53A01A27@lemburg.com> <200006021233.OAA16962@pandora> <14647.47270.330318.807347@anthem.python.org> Message-ID: <200006021503.RAA26314@pandora> > We'll still need xgettext to scan the C code. Please have a look at my lib.pot; I've been using xpot to extract the C doc strings, which aren't currently marked-up in the Python source. As for module docstrings: xpot doesn't recognize them either, but I think it could be improved to do so. However, that would give a substantial increase of the catalogs, so I'd recommend to add them only when the translators are done with the first round of translation. Having the full set of distutils doc strings in the catalog is already a substantial amount of text to translate... Regards, Martin From loewis at informatik.hu-berlin.de Fri Jun 2 17:05:35 2000 From: loewis at informatik.hu-berlin.de (Martin von Loewis) Date: Fri, 2 Jun 2000 17:05:35 +0200 (MET DST) Subject: [Python-Dev] Re: [Patches] Translating doc strings In-Reply-To: (pf@artcom-gmbh.de) References: Message-ID: <200006021505.RAA26338@pandora> > I agree: this is really ugly. Since doc-strings are something special, > I don't think, we should travel further down this road. I believe, > we should use a special doc-string extration-tool (possibly build > on top of ping's 'inspect.py'?), which will then create a .pot-file > solely out of __doc__-strings. I agree. Again, I'd like to advertise Fran?ois Pinard's xpot, which can extract doc strings from both Python code and C code. Regards, Martin From moshez at math.huji.ac.il Fri Jun 2 19:52:59 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Fri, 2 Jun 2000 20:52:59 +0300 (IDT) Subject: [Python-Dev] Suggestion: stopping to trust os mtimes Message-ID: Trusting OS-based mtimes for .pyc caching has some inherent problems. (Clock syncing and similar) Frankly, though I've never been bitten by this, it does give me an uncomfortable feeling. What if, instead, we'd use md5- or sha-based approach? I'm willing to bet that the 2^128 chance of problems is miniscule compared to the real problems clock syncing has already caused. (I think I remember some problem with .pyc's on IIS, but I may just be hallucinating) Problems: .pyc size would increase by 24 bytes -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com From trentm at activestate.com Fri Jun 2 20:14:17 2000 From: trentm at activestate.com (Trent Mick) Date: Fri, 2 Jun 2000 11:14:17 -0700 Subject: [Python-Dev] PyMarshal_WriteLongToFile: writes 'long' or 32-bit integer? Message-ID: <20000602111417.A17233@activestate.com> So, is PyMarshal_WriteLongToFile intended to write a C long, regardless of its size, or is it intended to alway write 32-bits? Currently it just writes 32-bits and if sizeof(long) > 4 for that platform then it is silently truncated. PyMarshal_WriteLongToFile is currently only used (in the core anyway) to write the magic number and timestamp for .pyc files in import.c. The current situation is pretty misleading. If you write a long directly with PyMarshal_WriteLongToFile your long is truncated to 32-bits. However, if you write a long indirectly by PyMarshal_WriteObjectToFile, where that Python object is or contains a PyInt (C long), then the long is *not* truncated. Options: 1. leave it, who cares 2. - change PyMarshal_WriteLongToFile to write 64-bits if long is 64-bits - add something like PyMarshal_WriteInt32ToFile for the benefit of users like import.c that want to control exactly how many bytes get written 3. - change PyMarshal_WriteLongToFile to raise an exception if the long overflows a 32-bit range Thanks, Trent -- Trent Mick trentm at activestate.com From pf at artcom-gmbh.de Fri Jun 2 21:21:30 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Fri, 2 Jun 2000 21:21:30 +0200 (MEST) Subject: [Python-Dev] Suggestion: stopping to trust os mtimes In-Reply-To: from Moshe Zadka at "Jun 2, 2000 8:52:59 pm" Message-ID: hi, Moshe Zadka wrote: > Trusting OS-based mtimes for .pyc caching has some inherent problems. > (Clock syncing and similar) Frankly, though I've never been bitten by > this, it does give me an uncomfortable feeling. What if, instead, we'd use > md5- or sha-based approach? I'm willing to bet that the 2^128 chance of > problems is miniscule compared to the real problems clock syncing has > already caused. (I think I remember some problem with .pyc's on IIS, but > I may just be hallucinating) The timestamp is returned by simply 'stat'ing the .py file. If you want more, you actually would have to open the .py files all the time. This would be trading a big performance penalty for a security, that will almost always not needed. In Unix many sub systems (for example 'make' depend on a monotone system clock. A random jumping clock would break many of them anyway. Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen) From gstein at lyra.org Fri Jun 2 21:53:21 2000 From: gstein at lyra.org (Greg Stein) Date: Fri, 2 Jun 2000 12:53:21 -0700 (PDT) Subject: [Python-Dev] Suggestion: stopping to trust os mtimes In-Reply-To: Message-ID: On Fri, 2 Jun 2000, Moshe Zadka wrote: > Trusting OS-based mtimes for .pyc caching has some inherent problems. > (Clock syncing and similar) Frankly, though I've never been bitten by > this, it does give me an uncomfortable feeling. What if, instead, we'd use > md5- or sha-based approach? That is an expensive computation. You'd have to read the whole file in and compute the hash. Today, we simply stat() each file. If the .pyc looks valid, we open it and check the date stamp against one of those stat's. You would be adding an open(), a read of the full file, and compute a hash -- to every import of a .pyc. -1 Cheers, -g -- Greg Stein, http://www.lyra.org/ From mal at lemburg.com Fri Jun 2 21:13:20 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 02 Jun 2000 21:13:20 +0200 Subject: [Python-Dev] Suggestion: stopping to trust os mtimes References: Message-ID: <39380750.97CD3BA0@lemburg.com> Moshe Zadka wrote: > > Trusting OS-based mtimes for .pyc caching has some inherent problems. > (Clock syncing and similar) Frankly, though I've never been bitten by > this, it does give me an uncomfortable feeling. What if, instead, we'd use > md5- or sha-based approach? I'm willing to bet that the 2^128 chance of > problems is miniscule compared to the real problems clock syncing has > already caused. (I think I remember some problem with .pyc's on IIS, but > I may just be hallucinating) > > Problems: > .pyc size would increase by 24 bytes Much worse: you'd have to recalculate the MD5-sum every time you import the .pyc file... Frankly, I don't think this is needed at all ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From loewis at informatik.hu-berlin.de Fri Jun 2 22:46:34 2000 From: loewis at informatik.hu-berlin.de (Martin von Loewis) Date: Fri, 2 Jun 2000 22:46:34 +0200 (MET DST) Subject: [Python-Dev] Re: [Patches] Translating doc strings In-Reply-To: (message from Ka-Ping Yee on Fri, 2 Jun 2000 12:07:22 -0700 (PDT)) References: Message-ID: <200006022046.WAA29600@pandora> > But presumably we want to get all the strings, don't we? Certainly not. For example, in ftplib, the string "anonymous" should not be translated - it would end up as "anonym" in German, and that would not be accepted by FTP servers. In general, great care is needed to select translatable strings. For example, the GNU ls program was localized to print the month names in German. Pretty safe, eh? Now, the emacs dired mode wouldn't recognize any file names in the list output anymore, because it had a regular expression to detect the various fields, which involved an alternative list for all the month names... Regards, Martin From pingster at ilm.com Fri Jun 2 21:07:22 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Fri, 2 Jun 2000 12:07:22 -0700 (PDT) Subject: [Python-Dev] Re: [Patches] Translating doc strings In-Reply-To: Message-ID: On Fri, 2 Jun 2000, Peter Funk wrote: > > I agree: this is really ugly. Since doc-strings are something special, > I don't think, we should travel further down this road. I believe, > we should use a special doc-string extration-tool (possibly build > on top of ping's 'inspect.py'?), which will then create a .pot-file > solely out of __doc__-strings. Getting __doc__ strings is pretty easy (inspect.py is one possibility). But presumably we want to get all the strings, don't we? That should be trivial with tokenize, right? ---- getstrings.py ----- import sys, tokenize strings = [] def tokeneater(type, token, start, end, line): if type == tokenize.STRING: strings.append(eval(token)) file = open(sys.argv[1]) tokenize.tokenize(file.readline, tokeneater) print strings ------------------------ % ./getstrings.py /usr/local/lib/python1.5/calendar.py ['calendar.error', 'Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday', 'Saturday', 'Sunday', 'Mon', 'Tue', 'Wed', 'Thu', 'Fri', 'Sat', 'Sun', '', 'January', 'February', 'March', 'April', 'May', 'June', 'July', 'August', 'September', 'October', 'No vember', 'December', ' ', 'Jan', 'Feb', 'Mar', 'Apr', 'May', 'Jun', 'Jul', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec', 'bad month number', ' ', ' ', '', '', ' ', ' ', '\012', '\012', '\012', ' ', '', '', ' '] Am i missing something? -- ?!ng From gstein at lyra.org Fri Jun 2 23:32:52 2000 From: gstein at lyra.org (Greg Stein) Date: Fri, 2 Jun 2000 14:32:52 -0700 (PDT) Subject: [Python-Dev] Suggestion: stopping to trust os mtimes In-Reply-To: Message-ID: On Fri, 2 Jun 2000, Peter Funk wrote: > Moshe Zadka wrote: > > Trusting OS-based mtimes for .pyc caching has some inherent problems. > > (Clock syncing and similar) Frankly, though I've never been bitten by > > this, it does give me an uncomfortable feeling. What if, instead, we'd use > > md5- or sha-based approach? I'm willing to bet that the 2^128 chance of > > problems is miniscule compared to the real problems clock syncing has > > already caused. (I think I remember some problem with .pyc's on IIS, but > > I may just be hallucinating) > > The timestamp is returned by simply 'stat'ing the .py file. If you > want more, you actually would have to open the .py files all the time. > This would be trading a big performance penalty for a security, that > will almost always not needed. In Unix many sub systems (for example > 'make' depend on a monotone system clock. A random jumping clock > would break many of them anyway. He does have a point, but I think the wrong solution :-) While the clock may be monotonically increasing on one system, it isn't always the case when things like NFS come into play. I recall a case back '95 when I was editing a .py over an NFS mount and running the code on the target machine. The clocks on the two boxes were off by about three seconds. I was going thru the edit/run/edit/run cycle so quickly, that at one point, I saved a .py file that was older than the associated .pyc file. Needless to say, I was really confused that my recent edit didn't produce the desired result :-) Cheers, -g p.s. and no, I don't know why the internal timestamp didn't take effect -- Greg Stein, http://www.lyra.org/ From pingster at ilm.com Sat Jun 3 01:10:01 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Fri, 2 Jun 2000 16:10:01 -0700 (PDT) Subject: [Python-Dev] Protecting __name__ &c. Message-ID: Would it be too much trouble to prevent replacing double-underscore attributes like __name__ and __file__? I'll accept a "consenting adults" argument -- it's just that somehow this makes me uneasy: Python 1.5.2 (#54, Jul 14 1999, 12:50:51) [C] on irix6 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import foo >>> foo.__name__ 'bar' >>> foo.__file__ 'bar.py' >>> foo Of course, there is no 'bar.py'. 'foo.py' just contains __file__ = 'bar.py' __name__ = 'bar' (If you say i deserved to be punished for such heresy, fine...) -- ?!ng From mhammond at skippinet.com.au Sat Jun 3 01:21:07 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sat, 3 Jun 2000 09:21:07 +1000 Subject: [Python-Dev] Protecting __name__ &c. In-Reply-To: Message-ID: > Would it be too much trouble to prevent replacing > double-underscore attributes like __name__ and __file__? This can be handy sometimes. > I'll accept a "consenting adults" argument -- it's just > that somehow this makes me uneasy: OK - accept it :-) Just dont do it if it makes you uneasy. > >>> import foo > >>> foo.__name__ > 'bar' > >>> foo.__file__ > 'bar.py' > >>> foo > That is no worse than, say: >>> a=1 >>> globals()['a']=2 >>> a 2 So you could make the same argument that globals() should be read-only, to force you to do the "normal" thing. To me, this is one of Python's big features. I dont want it holding my hand so tightly it cuts circulation :-) Mark. From akuchlin at cnri.reston.va.us Sat Jun 3 05:15:50 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Fri, 2 Jun 2000 23:15:50 -0400 Subject: [Python-Dev] What's New (first draft) Message-ID: <20000602231550.A986@newcnri.cnri.reston.va.us> I've put up the crude first draft of a "What's New in Python 1.6" article, co-written with Moshe Zadka. Please offer comments (or even patches to the LaTeX!). http://www.python.net/crew/amk/python/writing/new-python/ PDF, DVI, ASCII, and the LaTeX source are in: ftp://www.python.net/pub/crew/amk/new/ Various people are mentioned by name in the document ("effbot did this; MAL did that; Christian did that other thing...") because I want to emphasize the number of contributors to this release; does everyone think this is a good idea? If I've missed your name, or credited you wrongly, please let me know. --amk From akuchlin at cnri.reston.va.us Sat Jun 3 05:25:21 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Fri, 2 Jun 2000 23:25:21 -0400 Subject: [Python-Dev] Revised 1.6 jobs list Message-ID: <20000602232521.B986@newcnri.cnri.reston.va.us> I've slightly revised the 1.6 jobs list at http://www.python.net/crew/amk/python/1.6-jobs.html . Things still on the TODO list, maybe: Import hooks revamp (or is this a post-1.6 thing?) Update the documentation to match 1.6 changes. Document more undocumented modules (goes without saying, really...) : codecs, unicodedata, mmap, pyexpat, curses, regrtest. Unicode: Compress the size of unicodedatabase Unicode: Write \N{SMILEY} codec for Unicode (Bill Tutt has a patch) Unicode: the various XXX itemsin Misc/unicode.txt (or are they done?) Delete obsolete subdirectories in Demo/ directory Refurbish Demo subdirectories to be properly documented, match modern coding style, etc. Fix ./ld_so_aix installation problem on AIX Make test.regrtest.py more usable outside of thePython test suite Conservative garbage collection of cycles (maybe -- I don't know what GvR thinks about this) Changes to PyExpat module Test the hell out of SRE The end of coding may be in sight, leaving only the job of documenting everything new. I'm getting kind of worried about the lengthening backlog of patches, though; maybe next week we can start cutting it down? (Quick, while Guido's away, everyone come up with new keywords and check them in!) --amk From esr at thyrsus.com Sat Jun 3 05:49:16 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 2 Jun 2000 23:49:16 -0400 Subject: [Python-Dev] Revised 1.6 jobs list In-Reply-To: <20000602232521.B986@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Fri, Jun 02, 2000 at 11:25:21PM -0400 References: <20000602232521.B986@newcnri.cnri.reston.va.us> Message-ID: <20000602234916.B9680@thyrsus.com> Andrew Kuchling : > Document more undocumented modules (goes without saying, really...) : codecs, > unicodedata, mmap, pyexpat, curses, regrtest. About curses. Have you got the entry points listed and dxescribed yet? If so, I'll flesh out the docs with my tutorial stuff. We have a volunteer maintainer for curses after release, now, BTW. It's new Pythoneer Jim Dennis, the "Answer Guy" from the Linux Gazette. -- Eric S. Raymond The end move in politics is always to pick up a gun. -- R. Buckminster Fuller From bwarsaw at python.org Sat Jun 3 06:41:42 2000 From: bwarsaw at python.org (Barry A. Warsaw) Date: Sat, 3 Jun 2000 00:41:42 -0400 (EDT) Subject: [Python-Dev] Revised 1.6 jobs list References: <20000602232521.B986@newcnri.cnri.reston.va.us> Message-ID: <14648.35974.486959.379543@anthem.python.org> Did we ever decide on building in thread support by default? I'd really like to see threads enabled by default in 1.6 and I /think/ it'll just take some autoconf hacking, which I'm willing to do. Are there any objections to building in threads support by default if autoconf detects threads? -Barry From moshez at math.huji.ac.il Sat Jun 3 08:05:09 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sat, 3 Jun 2000 09:05:09 +0300 (IDT) Subject: [Python-Dev] Suggestion: stopping to trust os mtimes In-Reply-To: Message-ID: On Fri, 2 Jun 2000, Greg Stein wrote: > He does have a point, but I think the wrong solution :-) In my defense, it was after spending the whole day on my feet giving a lecture, or driving (for 12 hours). But it does bother me, even if the solution is terrible. How about having, in addition to the time-stamp, the size of the file? At least on UNIX, it comes for free with the same stat call. -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com From moshez at math.huji.ac.il Sat Jun 3 09:56:15 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sat, 3 Jun 2000 10:56:15 +0300 (IDT) Subject: [Python-Dev] PyMarshal_WriteLongToFile: writes 'long' or 32-bit integer? In-Reply-To: <20000602111417.A17233@activestate.com> Message-ID: On Fri, 2 Jun 2000, Trent Mick wrote: > 3. - change PyMarshal_WriteLongToFile to raise an exception if the long > overflows a 32-bit range +1 on that, finally non-portable integers will cause an exception. -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com From moshez at math.huji.ac.il Sat Jun 3 10:11:45 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sat, 3 Jun 2000 11:11:45 +0300 (IDT) Subject: [Python-Dev] Protecting __name__ &c. In-Reply-To: Message-ID: On Fri, 2 Jun 2000, Ka-Ping Yee wrote: > Would it be too much trouble to prevent replacing > double-underscore attributes like __name__ and __file__? Well, special casing seems like a bad idea on the face of it. Where does it stop? The correct way to "solve" this, is to add declarations to Python, including "constant" declaration, and then saying that __name__ and __file__ are "implicitly declared" constants. please-scatter-IMHOs-generously-throughtout-the-mail-ly y'rs, Z. -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com From gstein at lyra.org Sat Jun 3 11:52:39 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 3 Jun 2000 02:52:39 -0700 (PDT) Subject: [Python-Dev] Revised 1.6 jobs list In-Reply-To: <14648.35974.486959.379543@anthem.python.org> Message-ID: On Sat, 3 Jun 2000, Barry A. Warsaw wrote: > Did we ever decide on building in thread support by default? I'd > really like to see threads enabled by default in 1.6 and I /think/ > it'll just take some autoconf hacking, which I'm willing to do. Are > there any objections to building in threads support by default if > autoconf detects threads? +1 -- if they are there, then build them in! Cheers, -g -- Greg Stein, http://www.lyra.org/ From gmcm at hypernet.com Sat Jun 3 13:26:18 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Sat, 3 Jun 2000 07:26:18 -0400 Subject: [Python-Dev] Revised 1.6 jobs list In-Reply-To: <20000602232521.B986@newcnri.cnri.reston.va.us> Message-ID: <1252090883-19062603@hypernet.com> Andrew Kuchling wrote: > I've slightly revised the 1.6 jobs list > at http://www.python.net/crew/amk/python/1.6-jobs.html . > Things still on the TODO list, maybe: > > Import hooks revamp (or is this a post-1.6 thing?) The import SIG was created to resolve the controversies around imputils. The archives of the import SIG contain absolutely no controversy. So I say do it. - Gordon From skip at mojam.com Sat Jun 3 14:15:28 2000 From: skip at mojam.com (Skip Montanaro) Date: Sat, 3 Jun 2000 07:15:28 -0500 (CDT) Subject: [Python-Dev] Suggestion: stopping to trust os mtimes In-Reply-To: References: Message-ID: <14648.63200.850429.304545@beluga.mojam.com> Greg> I recall a case back '95 when I was editing a .py over an NFS Greg> mount and running the code on the target machine. The clocks on Greg> the two boxes were off by about three seconds. I was going thru Greg> the edit/run/edit/run cycle so quickly, that at one point, I saved Greg> a .py file that was older than the associated .pyc file. A help I think would be to compare the mtimes of the .py and .pyc files with the current system clock and squawk if either appears to have been created in the future. I believe this is what GNU make does. Of course, the best solution to all of this is the non-Python solution: use NTP so your clocks stay sync'd. It's even available out-of-the-box on my iMac... -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ "We have become ... the stewards of life's continuity on earth. We did not ask for this role... We may not be suited to it, but here we are." - Stephen Jay Gould From moshez at math.huji.ac.il Sat Jun 3 14:53:47 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sat, 3 Jun 2000 15:53:47 +0300 (IDT) Subject: [Python-Dev] Suggestion: stopping to trust os mtimes In-Reply-To: <14648.63200.850429.304545@beluga.mojam.com> Message-ID: On Sat, 3 Jun 2000, Skip Montanaro wrote: > Of course, the best solution to all of this is the non-Python solution: use > NTP so your clocks stay sync'd. It's even available out-of-the-box on my > iMac... But the "Python Way" was always to adapt: not to require One True Way, but to use the facilities where it finds itself. In any case, is there any objection to storing the size of the .py alongside it's mtime in the .pyc, and regenerating if either is changed? This is just as efficient, and much more reliable. -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com From mal at lemburg.com Sat Jun 3 11:55:26 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat, 03 Jun 2000 11:55:26 +0200 Subject: [Python-Dev] Revised 1.6 jobs list References: <20000602232521.B986@newcnri.cnri.reston.va.us> Message-ID: <3938D60E.391AAF31@lemburg.com> Andrew Kuchling wrote: > > I've slightly revised the 1.6 jobs list > at http://www.python.net/crew/amk/python/1.6-jobs.html . > Things still on the TODO list, maybe: > > Import hooks revamp (or is this a post-1.6 thing?) > Update the documentation to match 1.6 changes. > Document more undocumented modules (goes without saying, really...) : codecs, > unicodedata, mmap, pyexpat, curses, regrtest. I would appreciate some help with codec and unicodedata. codec.py has quite a bit of __doc__ string documentation which can be used more or less directly for the TeX docs. > Unicode: Compress the size of unicodedatabase Christian was working on this one, but I never got the patches ... Chris ? > Unicode: Write \N{SMILEY} codec for Unicode (Bill Tutt has a patch) I wonder why that patch hasn't been accepted yet -- I guess the patches list needs some more people willing to review things and of course people with check in permissions. I would volunteer to handle the above for the Unicode parts of the distribution if someone would explain to me how to checkin new code into SourceForge CVS. > Unicode: the various XXX itemsin Misc/unicode.txt (or are they done?) Hmm, there are no XXX markings left in my version of that file -- perhaps I've missed adding it to the patch sets... Anyway, the file will have to undergo some rewrite now that the default encoding strategy has changed. I'll fix that next week. > Delete obsolete subdirectories in Demo/ directory > Refurbish Demo subdirectories to be properly documented, match modern coding > style, etc. > Fix ./ld_so_aix installation problem on AIX > Make test.regrtest.py more usable outside of thePython test suite > Conservative garbage collection of cycles (maybe -- I don't know what GvR > thinks about this) > Changes to PyExpat module > Test the hell out of SRE > > The end of coding may be in sight, leaving only the job of documenting > everything new. I'm getting kind of worried about the lengthening backlog > of patches, though; maybe next week we can start cutting it down? (Quick, > while Guido's away, everyone come up with new keywords and check them in!) :-) Still, you've got a point there: Trent's patches are getting piled up and due to the fact that they touch many different parts of the code, they are likely to get in the way of other patches. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From jeremy at beopen.com Sat Jun 3 18:11:48 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Sat, 3 Jun 2000 12:11:48 -0400 Subject: [Python-Dev] Revised 1.6 jobs list In-Reply-To: <3938D60E.391AAF31@lemburg.com> Message-ID: M.-A. Lemburg wrote: >I wonder why that patch hasn't been accepted yet -- I guess >the patches list needs some more people willing to review things >and of course people with check in permissions. One of the problems I'm having is keeping track of which patches are still outstanding. This is really a management/tools problem. I have a mailbox full of messages from the patches list -- some of the messages are patches, others are discussion. Some patches supercede others or are duplicates. It would help if we had better tools for managing the submitted/pending patches. SourceForge makes it a little more inconvenient to check which patches have been applied. Under the old CVS arrangement, it was a local operation to do a cvs log or diff. Now it's a slow network operation that requires authentication. (I really want a local mirror of the entire CVS repository!) Sorry for the excuses. I think better tools would help a lot, but we'll have to get more people checkin privileges regardless. Jeremy From tismer at tismer.com Sat Jun 3 18:43:51 2000 From: tismer at tismer.com (Christian Tismer) Date: Sat, 03 Jun 2000 18:43:51 +0200 Subject: [Python-Dev] Revised 1.6 jobs list References: <20000602232521.B986@newcnri.cnri.reston.va.us> <3938D60E.391AAF31@lemburg.com> Message-ID: <393935C7.7624448A@tismer.com> "M.-A. Lemburg" wrote: > > Unicode: Compress the size of unicodedatabase > > Christian was working on this one, but I never got the > patches ... Chris ? Schmurpel :-> Something came in between where I couldn't resist to work on... yes, the microthread stuff was it. Ok, it is a pain for me to go for a sub-optimum solution, but yep, I'll force me to write the code gen now. ... > Still, you've got a point there: Trent's patches are getting > piled up and due to the fact that they touch many different > parts of the code, they are likely to get in the way of other > patches. patch-as-patch-can-ly y'rs - chris -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaunstr. 26 : *Starship* http://starship.python.net 14163 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF where do you want to jump today? http://www.stackless.com From tismer at tismer.com Sat Jun 3 18:44:31 2000 From: tismer at tismer.com (Christian Tismer) Date: Sat, 03 Jun 2000 18:44:31 +0200 Subject: [Python-Dev] Revised 1.6 jobs list References: <20000602232521.B986@newcnri.cnri.reston.va.us> <3938D60E.391AAF31@lemburg.com> Message-ID: <393935EF.89AA40DF@tismer.com> "M.-A. Lemburg" wrote: > > Unicode: Compress the size of unicodedatabase > > Christian was working on this one, but I never got the > patches ... Chris ? Schmurpel :-> Something came in between where I couldn't resist to work on... yes, the microthread stuff was it. Not to talk of the starship mess, which will hopefully end by this weekend... Ok, it is a pain for me to go for a sub-optimum solution, but yep, I'll force me to write the code gen now. ... > Still, you've got a point there: Trent's patches are getting > piled up and due to the fact that they touch many different > parts of the code, they are likely to get in the way of other > patches. patch-as-patch-can-ly y'rs - chris -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaunstr. 26 : *Starship* http://starship.python.net 14163 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF where do you want to jump today? http://www.stackless.com From gstein at lyra.org Sat Jun 3 21:41:19 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 3 Jun 2000 12:41:19 -0700 (PDT) Subject: [Python-Dev] Suggestion: stopping to trust os mtimes In-Reply-To: <14648.63200.850429.304545@beluga.mojam.com> Message-ID: On Sat, 3 Jun 2000, Skip Montanaro wrote: > Greg> I recall a case back '95 when I was editing a .py over an NFS > Greg> mount and running the code on the target machine. The clocks on > Greg> the two boxes were off by about three seconds. I was going thru > Greg> the edit/run/edit/run cycle so quickly, that at one point, I saved > Greg> a .py file that was older than the associated .pyc file. > > A help I think would be to compare the mtimes of the .py and .pyc files with > the current system clock and squawk if either appears to have been created > in the future. I believe this is what GNU make does. Sure, but to the target machine, the .pyc was fine and the .py was in the past. :-) Of course, the proper solution is to introduce compile/link stages into Python so that we don't get bitten by 3-second clock differences. :-) -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Sat Jun 3 22:26:00 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 3 Jun 2000 13:26:00 -0700 (PDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules mmapmodule.c,2.8,2.9 In-Reply-To: <200006031941.MAA21418@slayer.i.sourceforge.net> Message-ID: Actually, PyArg_ParseTuple() is a better call for this. It allows you to specify the method name: if (!PyArg_ParseTuple(args, ":close")) return NULL; Cheers,, -g On Sat, 3 Jun 2000, A.M. Kuchling wrote: > Update of /cvsroot/python/python/dist/src/Modules > In directory slayer.i.sourceforge.net:/tmp/cvs-serv21410 > > Modified Files: > mmapmodule.c > Log Message: > Add missing PyArg_NoArgs() calls to methods that didn't take arguments > (Pointed out by Moshe Zadka) > > > Index: mmapmodule.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Modules/mmapmodule.c,v > retrieving revision 2.8 > retrieving revision 2.9 > diff -C2 -r2.8 -r2.9 > *** mmapmodule.c 2000/05/03 23:44:32 2.8 > --- mmapmodule.c 2000/06/03 19:41:42 2.9 > *************** > *** 2,6 **** > / Author: Sam Rushing > / Hacked for Unix by A.M. Kuchling > ! / $Id: mmapmodule.c,v 2.8 2000/05/03 23:44:32 guido Exp $ > > / mmapmodule.cpp -- map a view of a file into memory > --- 2,6 ---- > / Author: Sam Rushing > / Hacked for Unix by A.M. Kuchling > ! / $Id: mmapmodule.c,v 2.9 2000/06/03 19:41:42 akuchling Exp $ > > / mmapmodule.cpp -- map a view of a file into memory > *************** > *** 76,79 **** > --- 76,81 ---- > mmap_close_method (mmap_object * self, PyObject * args) > { > + if (!PyArg_NoArgs(args)) > + return NULL; > #ifdef MS_WIN32 > UnmapViewOfFile (self->data); > *************** > *** 119,122 **** > --- 121,126 ---- > char * where; > CHECK_VALID(NULL); > + if (!PyArg_NoArgs(args)) > + return NULL; > if (self->pos >= 0 && self->pos < self->size) { > where = self->data + self->pos; > *************** > *** 132,136 **** > static PyObject * > mmap_read_line_method (mmap_object * self, > ! PyObject * args) > { > char * start = self->data+self->pos; > --- 136,140 ---- > static PyObject * > mmap_read_line_method (mmap_object * self, > ! PyObject * args) > { > char * start = self->data+self->pos; > *************** > *** 140,143 **** > --- 144,149 ---- > > CHECK_VALID(NULL); > + if (!PyArg_NoArgs(args)) > + return NULL; > > eol = memchr(start, '\n', self->size - self->pos); > *************** > *** 154,158 **** > static PyObject * > mmap_read_method (mmap_object * self, > ! PyObject * args) > { > long num_bytes; > --- 160,164 ---- > static PyObject * > mmap_read_method (mmap_object * self, > ! PyObject * args) > { > long num_bytes; > *************** > *** 226,230 **** > static PyObject * > mmap_write_byte_method (mmap_object * self, > ! PyObject * args) > { > char value; > --- 232,236 ---- > static PyObject * > mmap_write_byte_method (mmap_object * self, > ! PyObject * args) > { > char value; > *************** > *** 242,248 **** > static PyObject * > mmap_size_method (mmap_object * self, > ! PyObject * args) > { > CHECK_VALID(NULL); > > #ifdef MS_WIN32 > --- 248,256 ---- > static PyObject * > mmap_size_method (mmap_object * self, > ! PyObject * args) > { > CHECK_VALID(NULL); > + if (!PyArg_NoArgs(args)) > + return NULL; > > #ifdef MS_WIN32 > *************** > *** 347,350 **** > --- 355,360 ---- > { > CHECK_VALID(NULL); > + if (!PyArg_NoArgs(args)) > + return NULL; > return (Py_BuildValue ("l", self->pos) ); > } > *************** > *** 463,470 **** > > static int > ! mmap_buffer_getreadbuf(self, index, ptr) > ! mmap_object *self; > ! int index; > ! const void **ptr; > { > CHECK_VALID(-1); > --- 473,477 ---- > > static int > ! mmap_buffer_getreadbuf(mmap_object *self, int index, const void **ptr) > { > CHECK_VALID(-1); > *************** > *** 868,869 **** > --- 875,877 ---- > > } > + > > > _______________________________________________ > Python-checkins mailing list > Python-checkins at python.org > http://www.python.org/mailman/listinfo/python-checkins > -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Sat Jun 3 22:34:26 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 3 Jun 2000 13:34:26 -0700 (PDT) Subject: [Python-Dev] autoconf macros (was: RE: [Patches] Patch to Modules/pcre.h) In-Reply-To: Message-ID: [moving to python-dev] On Sun, 4 Jun 2000, Mark Hammond wrote: > > I don't even see where DONT_HAVE_SYS_TYPES_H is ever defined: > ... > > Is it defined in some Mac-specific project file? > > A few existed before, but I know I submitted a couple of the listed ones > for Windows CE. However, the CE config.h has never made it into the core, > hence you can't find that particular definition... Well, as I pointed out, the best way to do this is to add sys/types.h, sys/stat.h, and stat.h to the AC_CHECK_HEADER() macro in configure.in. The HAVE_SYS_TYPES_H macro and friends could then be checked. PC/wince_config.h (or whatever it is called) would just #undef the HAVE_* macros. The underlying issue here, is that autoconf can take care of these things for us quite easily -- that we don't need manual maintenance of the macros. For the odd platform without sys/types.h, autoconf will handle it, rather than Python needing to do a special-case declaration. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Sat Jun 3 22:44:07 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 3 Jun 2000 13:44:07 -0700 (PDT) Subject: [Python-Dev] Revised 1.6 jobs list In-Reply-To: Message-ID: On Sat, 3 Jun 2000, Jeremy Hylton wrote: >... > Sorry for the excuses. I think better tools would help a lot, but > we'll have to get more people checkin privileges regardless. There are several issues with expanded checkin privs: 1) trust: will the person make sure it is Right And Proper to do the checkin? (have they reviewed the code? is a a Good Change? etc) The counter here is that we don't want people that will simply take stuff arriving at patches@ and checking them in. 2) more people reviewing changes on the -checkins mailing list. Assuming that you want more than one pair of eyeballs looking at patches/code, that more people with commit privs increases the rate of commits, then you need more reviewers to keep up (because the reviewers probably are not going to review ALL checkins) 3) increasing dependence on -checkins means that patches MUST be smaller chunks. they MUST be single-purpose patches. practically nobody will review a 200k patch, or patches that fix N different things at once. A small, focused patch is easily reviewed. For example: Trent has recently mailed a bunch of patches to the patches list. This is Goodness: each one is focused and can be individually reviewed. Since they are not a single, giant blob, it also keeps them short and reviewable... each can have a +1/-1 independent of the others. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Sat Jun 3 23:14:49 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 3 Jun 2000 14:14:49 -0700 (PDT) Subject: [Python-Dev] Suggestion: stopping to trust os mtimes In-Reply-To: Message-ID: On Sat, 3 Jun 2000, Moshe Zadka wrote: >... > In any case, is there any objection to storing the size of the .py > alongside it's mtime in the .pyc, and regenerating if either is changed? > This is just as efficient, and much more reliable. If we change the header size, then this would be fine. At the moment, I don't think that anybody is suggesting a change to the .pyc header format because of the number of tool breakages that would ensue. People have seemed interested in my idea to update the marshal format to record a version number -- it doesn't require a change to the .pyc header. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Sun Jun 4 00:53:18 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 3 Jun 2000 15:53:18 -0700 (PDT) Subject: [Python-Dev] Re: httplib (was: Adding LDAP to the Python core... ?!) In-Reply-To: Message-ID: I found the problem. Sneaky... sock.makefile() does a dup() on the file descriptor, then opens a FILE* with that. See it coming yet? ... FILE* is a buffered thingy. stdio chunked in a block of data on the dup'd file descriptor. When we went to grab another chunk on the *original* descriptor, we missed input [that is now sitting in the FILE* buffer]. Answer: change the .makefile() in getreply() to: file = self.sock.makefile('rb', 0) This problem is going to affect the original httplib, too. IMO, we're about to replace the sucker, so no worries... Cheers, -g On Fri, 2 Jun 2000, Greg Stein wrote: > It looks like a definite bug. I have *no* idea, tho, why it is doing > that... I did quite a bit of testing with chunked replies. Admittedly, > though, I didn't stack up requests like you've done in your test. I'm > wrapping up mod_dav at the moment, so I don't really have time to look > deeply into this. Mebbe next week? > > Regarding the pipeline request thing. I think it would probably be best to > just drop the whole "hold the previous response and wait for it to be > closed" thing. I don't know why that is in there; probably a leftover > (converted) semantic from the old-style HTTP() class. I'd be quite fine > just axing it and allowing the client to shove ten requests down the pipe > before pulling the first response back out. > > Oh. Wait. Maybe that was it. You can't read the "next" response until the > first one has been read. Well... no need to block putting new responses; > we just need to create a way to "get the next reply" and/or "can I get the > next reply yet?" > > Cheers, > -g > > p.s. Moshe also had a short list of review items. I read thru them, but > not with the code in hand to understand some of his specifics. > > > On Wed, 31 May 2000, Jeremy Hylton wrote: > > >>>>> "GS" == Greg Stein writes: > > > > GS> [ and recall my email last week that I've updated httplib.py and > > GS> posted it to my web pages; it is awaiting review for integration > > GS> into the Python core; it still needs docs and more testing > > GS> scenarios, tho > > > > I've been looking at the httplib code, and I found what may be a bug. > > Not sure, because I'm not sure how the API works for pipelined > > requests. > > > > I've got some test code that looks a bit like this: > > > > def test_new_interface_series(urls): > > paths = [] > > the_host = None > > for url in urls: > > host, path = get_host_and_path(url) > > if the_host is None: > > the_host = host > > else: > > assert host == the_host > > paths.append(path) > > > > conn = httplib.HTTPConnection(the_host) > > for path in paths: > > conn.request('GET', path, headers={'User-Agent': 'httplib/Python'}) > > for path in paths: > > errcode, errmsg, resp = conn.getreply() > > buf = resp.read() > > if errcode == 200: > > print errcode, resp.headers > > else: > > print errcode, `errmsg`, resp > > print resp.getheader('Content-Length'), len(buf) > > print repr(buf[:40]) > > print repr(buf[-40:]) > > print > > conn.close() > > > > test_new_interface_series(['http://www.python.org/', > > 'http://www.python.org/pics/PyBanner054.gif', > > 'http://www.python.org/pics/PythonHi.gif', > > 'http://www.python.org/Jobs.html', > > 'http://www.python.org/doc/', > > 'http://www.python.org/doc/current/', > > ]) > > > > The second loop that reads the replies gets fouled up after a couple > > of responses. I added even more debugging and found that the first > > line of the corrupted response is > > > > > 'ontent-Type: text/html\015\012' > > > > It looks like some part of the program is consuming too much input. I > > haven't been able to figure out what part yet. Hoping that you might > > have some good ideas. > > > > Thinking about this issue, I came up with a potential API problem. > > You must read the body after calling getreply and before calling > > getreply a second time. This kind of implicit requirement is a bit > > tricky. It would help if the implementation could raise an error if > > this happens. It might be even better if it just worked, although it > > seems a bit too magical. > > > > Jeremy > > > > -- > Greg Stein, http://www.lyra.org/ > > > > -- Greg Stein, http://www.lyra.org/ From thomas at xs4all.net Sun Jun 4 00:56:01 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Sun, 4 Jun 2000 00:56:01 +0200 Subject: [Python-Dev] Re: Is it just Syntactic Sugar ? In-Reply-To: <3935B383.469032AE@python.org>; from guido@python.org on Wed, May 31, 2000 at 11:49:57PM +0000 References: <3929E47E.993727CF@roguewave.com> <3933F800.9CCE3B6D@cs.byu.edu> <20000530213957.E469@xs4all.nl> <20000531090045.I469@xs4all.nl> <3935B383.469032AE@python.org> Message-ID: <20000604005601.T469@xs4all.nl> On Wed, May 31, 2000 at 11:49:57PM +0000, Guido van Rossum wrote: > I know I shouldn't be posting in this thread, and I won't be there to read > the responses, but here's what I thought would be cool. As the 'lucky, lucky bastard' is probably standing before the altar about now, I'll send this to the dev-list instead. Not that I expect anyone *not* to be at the wedding, but I bet the rest is back sooner ;-) > x+=y is syntactic sugar for x=x.__add_ab__(y); the "ab" means "and becomes" > (an old Algol-68 naming convention; we could pick something better later > but this will do for the explanation). > For immutable types, this is defined as > def __add_ab__(self, other): > return self+other > For mutable types, this is defined as a self-mutating operation, > e.g. for lists it could be > def __add_ab__(self, other): > self.extend(other) > return self This was what I had in mind, and was trying to explain. Does you voicing your opinion mean someone (you ? someone else ?) is working on this, or soon going to work on this ? I had a chat with Michael about fixing up his patch to work all the way (it's currently a proof-of-concept-quick-hack that only works for builtin types) which prompted me to study Python's internals a bit closer. (I hope I dont sound too patronizing when I say I was impressed ;-) I'm curious what should happen with index-assignment and slice-assignment: x[y] += z x[:y] += z (Obviously this wont make sense for a lot of types, or will be too un-obvious to include, but I can imagine matrix-types to happily add this.) Would this call x.__add_item_ab__(y, z) and x.__add_slice_ab__(0, y, z) ? Or would x[y] += z always call x[y].__add_item_ab__() and x[:y] create a new object, a slice of x, and call its __add_ab__() method ? Or would it try all of them, or more, until it gets a good result ? Or am I running ahead of things and should we wait for a working patch first ? :) If I suddenly grow a deep understanding of Python's internals (not ruled out, it's fairly obvious) and hack-up something that works before anyone else, I'll be sure to mail ;) oh-and-congratulations-to-Mrs.-van-Rossum-too-ly yr's, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From gstein at lyra.org Sun Jun 4 01:06:07 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 3 Jun 2000 16:06:07 -0700 (PDT) Subject: [Python-Dev] httplib In-Reply-To: Message-ID: On Sat, 3 Jun 2000, Greg Stein wrote: > I found the problem. Sneaky... > > sock.makefile() does a dup() on the file descriptor, then opens a FILE* > with that. See it coming yet? ... > > FILE* is a buffered thingy. stdio chunked in a block of data on the dup'd > file descriptor. When we went to grab another chunk on the *original* > descriptor, we missed input [that is now sitting in the FILE* buffer]. > > Answer: change the .makefile() in getreply() to: > > file = self.sock.makefile('rb', 0) > > This problem is going to affect the original httplib, too. IMO, we're > about to replace the sucker, so no worries... Oh... actually it won't affect the original since that doesn't pipeline requests. -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Sun Jun 4 01:13:55 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 3 Jun 2000 16:13:55 -0700 (PDT) Subject: [Python-Dev] more on httplib Message-ID: I would like to propose a few changes to the (new) httplib: *) drop HTTPS() -- this class isn't in 1.5.2, so there isn't a reason to provide backwards-compat for it *) revamp the pipeline support: - record the "last response object" ... when a new getreply() is done, then we store the "last" into response.prior - reading of the "HTTP/1.1 " line is deferred, and performed by the response object - the read of that line is lazy - if the response line is read *before* the "prior" response (if any) is "closed", then an exception is raised: ResponseNotReady *) address some of Moshe's concerns: - use class-based exceptions - clarify that HTTPConnection is designed for *blocking* sockets - conn.close() followed by conn.send() will reopen the socket. This could lead to programming errors. I'll add a class-based default flag to disable this behavior. - in request(), we check for errno==32 ... what to do on Windows? I will implement these changes in small chunks so that each can be reviewed in my CVS repository. The history is available at: http://www.lyra.org/cgi-bin/viewcvs.cgi/gjspy/httplib.py/ Cheers, -g -- Greg Stein, http://www.lyra.org/ From mhammond at skippinet.com.au Sun Jun 4 04:03:34 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sun, 4 Jun 2000 12:03:34 +1000 Subject: [Python-Dev] What's New (first draft) In-Reply-To: <20000602231550.A986@newcnri.cnri.reston.va.us> Message-ID: > emphasize the number of contributors to this release; does everyone think > this is a good idea? If I've missed your name, or credited you wrongly, > please let me know. OK - as you insist :-) Bill Tutt and I could do with a credit for the new winreg module. Thanks, Mark. From tim_one at email.msn.com Sun Jun 4 06:09:02 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 4 Jun 2000 00:09:02 -0400 Subject: [Python-Dev] Suggestion: stopping to trust os mtimes In-Reply-To: Message-ID: <000a01bfcdda$9e876060$1d2d153f@tim> [Moshe] > How about having, in addition to the time-stamp, the size of the file? > At least on UNIX, it comes for free with the same stat call. +1 from me. Note that, besides inter-machine clock skew, some filesystems have a timestamp granularity too coarse to distinguish close-in-time writes. For those (& related) reasons, the attentive Pythoneer will have noted that all of the winning 1st-round Software Carpentry "make"-replacement designs provide for alternatives to timestamps. Tom Tromey's has the clearest discussion of the problems with timestamps: http://software-carpentry.codesourcery.com/entries/build/Tromey/Tromey.html In my industrial experience, (timestamp, size) pairs have never failed in practice. However, "my industrial experience" has been entirely in projects where source-control wrappers add a checkin comment block to every checked-in file, and that alone made it exceedingly unlikely that any two successive versions of a file would have the same size. In Python I'm still (a little) worried about cases like SOME_GLOBAL_CONFIG_OPTION = 0 where "0" gets replaced by "1" or "2" or ... there are lots of interesting things you can do to Python programs without changing their size. At Dragon, checked-in Python files were also subject to the "checkin comment block" rule, so no project under source control suffered from this. I suspect it burned people in their pre-source-controlled development projects, though! One group in particular had a project that involved acres of machine-generated Python modules, and I know they suffered from coarse timestamps on their flavor of Unix (so part of their "make" procedure was to nuke all .pyc's on each build). it's-easy-to-laugh-at-problems-you-don't-have-ly y'rs - tim From moshez at math.huji.ac.il Sun Jun 4 06:59:31 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sun, 4 Jun 2000 07:59:31 +0300 (IDT) Subject: [Python-Dev] Suggestion: stopping to trust os mtimes In-Reply-To: <000a01bfcdda$9e876060$1d2d153f@tim> Message-ID: On Sun, 4 Jun 2000, Tim Peters wrote: [Moshe] > How about having, in addition to the time-stamp, the size of the file? > At least on UNIX, it comes for free with the same stat call. [Tim] > +1 from me. Now there is the big problem, that this will be changing the header size. I thought that this would be a good time anyway, since 1.5.2 pycs aren't compatible with 1.6, but changing the header size is a bigger thing. so-this-waits-until-guido-comes-back-i-guess-ly y'rs, Z. -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com From bwarsaw at python.org Sun Jun 4 22:51:30 2000 From: bwarsaw at python.org (Barry A. Warsaw) Date: Sun, 4 Jun 2000 16:51:30 -0400 (EDT) Subject: [Python-Dev] Revised 1.6 jobs list References: <3938D60E.391AAF31@lemburg.com> Message-ID: <14650.49490.725648.798719@anthem.python.org> >>>>> "JH" == Jeremy Hylton writes: JH> One of the problems I'm having is keeping track of which JH> patches are still outstanding. SF has a patch manager but I haven't played with it much. In fact, I can't seem to find it for the Python project, but it's there in the Mailman project. -Barry From gstein at lyra.org Sun Jun 4 22:55:09 2000 From: gstein at lyra.org (Greg Stein) Date: Sun, 4 Jun 2000 13:55:09 -0700 (PDT) Subject: [Python-Dev] Revised 1.6 jobs list In-Reply-To: <14650.49490.725648.798719@anthem.python.org> Message-ID: On Sun, 4 Jun 2000, Barry A. Warsaw wrote: > >>>>> "JH" == Jeremy Hylton writes: > > JH> One of the problems I'm having is keeping track of which > JH> patches are still outstanding. > > SF has a patch manager but I haven't played with it much. In fact, I > can't seem to find it for the Python project, but it's there in the > Mailman project. You can administratively turn those things on/off, I thought. You're an admin, Barry, so you should be able to turn the thing on. Cheers, -g p.s. and yah.. there are damn too many projects at SF that are just a project name. no code, no description, all features enabled for no purpose, etc... Newbie coders, me thinks. Python is Goodness because it does disable the unused items. -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Mon Jun 5 01:30:08 2000 From: gstein at lyra.org (Greg Stein) Date: Sun, 4 Jun 2000 16:30:08 -0700 (PDT) Subject: [Python-Dev] release forms? (was: [Patches] New sys method to return total reference count in debug builds.) Message-ID: Given the New World Order, how does that impact the need for these release statements and/or wet signatures? Or a better way to put it, who "owns" Python now? Given a "who", then we can ask that person/entity whether they want release statements. Given that Python is now on SourceForge, and there are multiple people (at CNRI and otherwise) that can directly make modifications, then the release below is certainly a bit "off". For example, David Ascher has commit privs, so at his "sole discretion, [he may] decide whether or not to incorporiate this contribution..." :-) Thoughts? Cheers, -g p.s. IMO, I'd like to see Guido own the Copyright for all current and future Python development -- Greg Stein, http://www.lyra.org/ ---------- Forwarded message ---------- Date: Mon, 5 Jun 2000 09:18:30 +1000 From: Mark Hammond To: patches at python.org Subject: [Patches] New sys method to return total reference count in debug builds. [... snip ...] Release info: I confirm that, to the best of my knowledge and belief, this contribution is free of any claims of third parties under copyright, patent or other rights or interests ("claims"). To the extent that I have any such claims, I hereby grant to CNRI a nonexclusive, irrevocable, royalty-free, worldwide license to reproduce, distribute, perform and/or display publicly, prepare derivative versions, and otherwise use this contribution as part of the Python software and its related documentation, or any derivative versions thereof, at no cost to CNRI or its licensed users, and to authorize others to do so. I acknowledge that CNRI may, at its sole discretion, decide whether or not to incorporate this contribution in the Python software and its related documentation. I further grant CNRI permission to use my name and other identifying information provided to CNRI by me for use in connection with the Python software and its related documentation. Mark. _______________________________________________ Patches mailing list Patches at python.org http://www.python.org/mailman/listinfo/patches From bwarsaw at python.org Mon Jun 5 05:09:36 2000 From: bwarsaw at python.org (bwarsaw at python.org) Date: Sun, 4 Jun 2000 23:09:36 -0400 (EDT) Subject: [Python-Dev] Revised 1.6 jobs list References: <14650.49490.725648.798719@anthem.python.org> Message-ID: <14651.6640.709657.306682@anthem.python.org> >>>>> "GS" == Greg Stein writes: GS> You can administratively turn those things on/off, I GS> thought. You're an admin, Barry, so you should be able to turn GS> the thing on. I'm happy to if people think it will help. SF's patch management is a durn site better than Python's is now . I'd also consider shutting off Jitterbug on python.org but I'm not sure how to (or if we should) migrate the current bug set to SF. -Barry From gstein at lyra.org Mon Jun 5 08:13:39 2000 From: gstein at lyra.org (Greg Stein) Date: Sun, 4 Jun 2000 23:13:39 -0700 (PDT) Subject: [Python-Dev] Revised 1.6 jobs list In-Reply-To: <14651.6640.709657.306682@anthem.python.org> Message-ID: On Sun, 4 Jun 2000 bwarsaw at python.org wrote: > >>>>> "GS" == Greg Stein writes: > > GS> You can administratively turn those things on/off, I > GS> thought. You're an admin, Barry, so you should be able to turn > GS> the thing on. > > I'm happy to if people think it will help. SF's patch management is a > durn site better than Python's is now . I'd also consider > shutting off Jitterbug on python.org but I'm not sure how to (or if we > should) migrate the current bug set to SF. IMO, use the provided tools. The Patch Manager is more than we have now. It also allows assignment, which can be nice :-) (compared to the arbitrary "who is taking care of this patch?" thing today) The SF bug database certainly works, and it provides additional "locality" for the code + bugs + patches. Cheers, -g -- Greg Stein, http://www.lyra.org/ From jeremy at beopen.com Mon Jun 5 06:43:45 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 5 Jun 2000 00:43:45 -0400 (EDT) Subject: [Python-Dev] Revised 1.6 jobs list In-Reply-To: <3938D60E.391AAF31@lemburg.com> References: <20000602232521.B986@newcnri.cnri.reston.va.us> <3938D60E.391AAF31@lemburg.com> Message-ID: <14651.12289.191631.704477@localhost.localdomain> [Entry from AMK's 1.6 jobs list:] > Conservative garbage collection of cycles (maybe -- I don't know what GvR > thinks about this) I believe Guido would like to see a version of Neil's patches integrated into Python 1.6, most likely turned off by default but with a configure flag to enable. I would like to check the patch in soon but I have had some trouble with segfaults. I ran a simple benchmark using the compiler code in the nondist tree to compile itself. I get a crash during a routine collect pass, where it looks like the GC header info is getting trashed. I haven't had much time to track it any farther. If anyone else is interested, I'd love to hear about successes using the GC patch with other large programs. I'd like to run at least Gadfly and Grail successfully before committing the patch. I wonder if "conservative" is the right word to describe the GC approach? I think conservative means that the garbage collector is not told what is a pointer and what is not, so it must conservatively assume that every bit pattern could represent a pointer. The GC patch is not conservative in this sense. It does have a mechanism that is "conservative" in a very broad sense, i.e. it does not attempt to trace every reference, but depends on the ref count fields to account for references held in untraced variables on the C stack. I'm not sure what the right terminology for this approach is. I also worry that the performance impact of the GC patch is not at all understood. I don't know what informed the choice of heuristics for deciding how often to collect and how to move objects between generations. (The current scheme has three generations.) It would be good to get a working patch in before the next alpha release and then gather a lot of data to help make good choices about these parameters. Jeremy PS Even if Guido doesn't think the GC patch should go in, we've got a golden opportunity. I caught him in a state of newly-wedded bliss this morning and convinced him to let me check in my non-optional braces patch while he's on his honeymoon. He's so happy he'll let us get away with anything. PPS I don't know if we should really carry on about personal matters on a development list, but I hope no one minds if I indulge briefly: Guido & Kim's wedding yesterday was beautiful and fun, held outside in meadow looking out on hills and woods. They are great couple and I'm sure they'll be very happy. From jeremy at beopen.com Mon Jun 5 06:58:11 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 5 Jun 2000 00:58:11 -0400 (EDT) Subject: [Python-Dev] Re: httplib (was: Adding LDAP to the Python core... ?!) In-Reply-To: References: Message-ID: <14651.13155.253651.575394@localhost.localdomain> >>>>> "GS" == Greg Stein writes: GS> I found the problem. Sneaky... sock.makefile() does a dup() on GS> the file descriptor, then opens a FILE* with that. See it coming GS> yet? ... Bingo! I was suspicious of all these dup'd file descriptors, but missed the connection to a FILE* object. [In a previous message you wrote:] >> >> Regarding the pipeline request thing. I think it would probably >> be best to just drop the whole "hold the previous response and >> wait for it to be closed" thing. [...] >> >> Oh. Wait. Maybe that was it. You can't read the "next" response >> until the first one has been read. Well... no need to block >> putting new responses; we just need to create a way to "get the >> next reply" and/or "can I get the next reply yet?" >> Maybe I should clarify the concern I had here. I think we're on the same page, but I'm not sure. The problem with pipelined requests is that the client must be sure to read all of response I before it can call getreply to get response I+1. I imagine that it could add a lot of complexity to use code to implement this requirement, e.g. when multiple threads are sharing a single connection. It would be good if the library could do something reasonable about the multiplexing. In the absence of making it just work, the library could raise an error that makes clear what has gone wrong -- that the client isn't using the interface properly. Jeremy From jeremy at beopen.com Mon Jun 5 07:00:06 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 5 Jun 2000 01:00:06 -0400 (EDT) Subject: [Python-Dev] Re: Is it just Syntactic Sugar ? In-Reply-To: <20000604005601.T469@xs4all.nl> References: <3929E47E.993727CF@roguewave.com> <3933F800.9CCE3B6D@cs.byu.edu> <20000530213957.E469@xs4all.nl> <20000531090045.I469@xs4all.nl> <3935B383.469032AE@python.org> <20000604005601.T469@xs4all.nl> Message-ID: <14651.13270.353056.246432@localhost.localdomain> >>>>> "TW" == Thomas Wouters writes: TW> On Wed, May 31, 2000 at 11:49:57PM +0000, Guido van Rossum TW> wrote: >> I know I shouldn't be posting in this thread, and I won't be >> there to read the responses, but here's what I thought would be >> cool. >> x+=y is syntactic sugar for x=x.__add_ab__(y); the "ab" means >> "and becomes" (an old Algol-68 naming convention; we could pick >> something better later but this will do for the explanation). [...] TW> This was what I had in mind, and was trying to explain. Does you TW> voicing your opinion mean someone (you ? someone else ?) is TW> working on this, or soon going to work on this ? I don't believe anyone at PythonLabs is working on this now, certainly not Guido or I. Jeremy From jeremy at beopen.com Mon Jun 5 06:53:32 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 5 Jun 2000 00:53:32 -0400 (EDT) Subject: [Python-Dev] Revised 1.6 jobs list In-Reply-To: References: Message-ID: <14651.12876.575925.701737@localhost.localdomain> >>>>> "GS" == Greg Stein writes: GS> On Sat, 3 Jun 2000, Jeremy Hylton wrote: >> ... Sorry for the excuses. I think better tools would help a >> lot, but we'll have to get more people checkin privileges >> regardless. GS> There are several issues with expanded checkin privs: GS> 1) trust: will the person make sure it is Right And Proper to do GS> the checkin? (have they reviewed the code? is a a Good Change? GS> etc) The counter here is that we don't want people that will GS> simply take stuff arriving at patches@ and checking them in. Many of the people who ultimately have checkin privileges should limit themselves to their particular domains. There are a bunch of modules that are owned by other people, e.g. Eric's netrc module, your new httplib, MAL for Unicode, etc. We'll probably develop a second group of developers who have broader privileges to make changes, but they'll know how they are. Ultimately, I think I agree with Mark's suggestion that we be a little more liberal with changes and risk backing out the occasional changes. (For some definition of "a little more" :-). GS> 2) more people reviewing changes on the -checkins mailing GS> list. Assuming that you want more than one pair of eyeballs GS> looking at patches/code, that more people with commit privs GS> increases the rate of commits, then you need more reviewers to GS> keep up (because the reviewers probably are not going to review GS> ALL checkins) You're doing a great job so far. We'll just have to get you to spend more time on it <0.8 wink>. GS> 3) increasing dependence on -checkins means that patches MUST be GS> smaller chunks. they MUST be single-purpose patches. practically GS> nobody will review a 200k patch, or patches that fix N different GS> things at once. A small, focused patch is easily reviewed. GS> For example: Trent has recently mailed a bunch of patches to GS> the patches list. This is Goodness: each one is focused and can GS> be individually reviewed. Since they are not a single, giant GS> blob, it also keeps them short and reviewable... each can have a GS> +1/-1 independent of the others. I agree in principle, but there are times when it will make more sense to commit a set of changes as one big patch. The GC patches are going to affect a bunch of files, but probably ought to be done as one big commit. Jeremy From jeremy at beopen.com Mon Jun 5 07:03:46 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 5 Jun 2000 01:03:46 -0400 (EDT) Subject: [Python-Dev] release forms? (was: [Patches] New sys method to return total reference count in debug builds.) In-Reply-To: References: Message-ID: <14651.13490.858960.390030@localhost.localdomain> Off the top of my head, I'd say that your questions aren't going to get answered until Guido gets back and gets a chance to answer them. In the interim, I think we should stick with the current approach. In the long run, of course, you won't need to grant CNRI permission to do anything with a submission. Jeremy From nascheme at enme.ucalgary.ca Mon Jun 5 08:35:00 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Mon, 5 Jun 2000 00:35:00 -0600 Subject: [Python-Dev] Revised 1.6 jobs list In-Reply-To: <14651.12289.191631.704477@localhost.localdomain>; from jeremy@beopen.com on Mon, Jun 05, 2000 at 12:43:45AM -0400 References: <20000602232521.B986@newcnri.cnri.reston.va.us> <3938D60E.391AAF31@lemburg.com> <14651.12289.191631.704477@localhost.localdomain> Message-ID: <20000605003500.B6169@acs.ucalgary.ca> On Mon, Jun 05, 2000 at 12:43:45AM -0400, Jeremy Hylton wrote: > [Entry from AMK's 1.6 jobs list:] > > Conservative garbage collection of cycles (maybe -- I don't know what GvR > > thinks about this) > > I believe Guido would like to see a version of Neil's patches > integrated into Python 1.6, most likely turned off by default but with > a configure flag to enable. Okay, I was thinking he had passed it over for 1.6 since I didn't hear any comments from him for a long time. > I would like to check the patch in soon but I have had some trouble > with segfaults. I ran a simple benchmark using the compiler code in > the nondist tree to compile itself. I get a crash during a routine > collect pass, where it looks like the GC header info is getting > trashed. I haven't had much time to track it any farther. Yow. I will try to see if I can reproduce this. What platform? > If anyone else is interested, I'd love to hear about successes using > the GC patch with other large programs. I'd like to run at least > Gadfly and Grail successfully before committing the patch. I've used it with Grail, Sketch, IDLE as well as some of my own software. I may have introduced that SEGV bug when porting the patch to a newer version of the CVS sources. I will check it out. > I also worry that the performance impact of the GC patch is not > at all understood. Me too. > I don't know what informed the choice of heuristics for > deciding how often to collect and how to move objects between > generations. (The current scheme has three generations.) It > would be good to get a working patch in before the next alpha > release and then gather a lot of data to help make good choices > about these parameters. Getting good performance will be a matter of tuning how often the collector runs. I don't think there is any substitute for running real programs and collecting data. Programs that allocate lots of objects will be most interesting. It would probably be a good idea to add more support for keeping collection statistics. Unfortunately my time is very limited right now. > PS Even if Guido doesn't think the GC patch should go in, we've got a > golden opportunity. I caught him in a state of newly-wedded bliss > this morning and convinced him to let me check in my non-optional > braces patch while he's on his honeymoon. He's so happy he'll let us > get away with anything. I wonder if he will be scowling less at the conferences now that he is hitched. :) Neil From gstein at lyra.org Mon Jun 5 08:42:35 2000 From: gstein at lyra.org (Greg Stein) Date: Sun, 4 Jun 2000 23:42:35 -0700 (PDT) Subject: [Python-Dev] Revised 1.6 jobs list In-Reply-To: <14651.12876.575925.701737@localhost.localdomain> Message-ID: On Mon, 5 Jun 2000, Jeremy Hylton wrote: > >>>>> "GS" == Greg Stein writes: >... > GS> 1) trust: will the person make sure it is Right And Proper to do > GS> the checkin? (have they reviewed the code? is a a Good Change? > GS> etc) The counter here is that we don't want people that will > GS> simply take stuff arriving at patches@ and checking them in. > > Many of the people who ultimately have checkin privileges should limit > themselves to their particular domains. There are a bunch of modules > that are owned by other people, e.g. Eric's netrc module, your new > httplib, MAL for Unicode, etc. Agreed. Each person with commit privs will definitely need to operate under the premise of " is the area that I'm allowed to commit changes for." For example, I believe that Guido made it very clear, at some point in the past, that *nobody* but Guido will have commit access to the Parser/ area. Note that when I say "commit access" here, this is the same as "areas that I can commit for." In fact, it is really just an extension of the Basic Python Principle, "we're all adults here, don't do what you know you shouldn't be doing." :-) >... > Ultimately, I think I agree with Mark's suggestion that we be a little > more liberal with changes and risk backing out the occasional > changes. (For some definition of "a little more" :-). This only works if you have reasonably assurance of review via the -checkins alias. Otherwise, you simply need to accept that instabilities will creep in. (and that broader alpha/beta/etc cycles may be desirable) In the Apache group, we have a very good set of eyeballs watching the checkins. I'd say that each checkin is reviewed by two or three people in detail. Invariably, there are several checkins each week that result in a thread discussing: (a) you broke it, (b) why was it done that way, (c) couldn't it be done this way, (d) this appears to be missing, (e) etc. IMO, for that to happen several (or more!) times every week means that we have a good set of eyeballs. Maybe it also means the committers just suck lollipops, but I'd like to think otherwise :-) > GS> 2) more people reviewing changes on the -checkins mailing > GS> list. Assuming that you want more than one pair of eyeballs > GS> looking at patches/code, that more people with commit privs > GS> increases the rate of commits, then you need more reviewers to > GS> keep up (because the reviewers probably are not going to review > GS> ALL checkins) > > You're doing a great job so far. We'll just have to get you to spend > more time on it <0.8 wink>. hehe... well, I just completed a big-ass wave of mod_dav work. In fact, I don't know what else to do to the thing. I made a snapshot and am waiting for feedback, if any, before declaring it 1.0. Maybe I'll add some comments to the code :-) Anyways... that's why I've been working on httplib. Free time! :-) > GS> 3) increasing dependence on -checkins means that patches MUST be > GS> smaller chunks. they MUST be single-purpose patches. practically > GS> nobody will review a 200k patch, or patches that fix N different > GS> things at once. A small, focused patch is easily reviewed. > > GS> For example: Trent has recently mailed a bunch of patches to > GS> the patches list. This is Goodness: each one is focused and can > GS> be individually reviewed. Since they are not a single, giant > GS> blob, it also keeps them short and reviewable... each can have a > GS> +1/-1 independent of the others. > > I agree in principle, but there are times when it will make more sense > to commit a set of changes as one big patch. The GC patches are going > to affect a bunch of files, but probably ought to be done as one big > commit. Actually, I will disagree here. I've reviewed the GC patch a couple times. There are a number of changes in there that can/should be done separately from the "real" GC patch. For example, there were a number of changes to use PyMem_Allco() instead of PyMEM_Alloc(). Or whatever. Point being, that they had *nothing* to do with GC -- they could be checked in *independent* of the actual GC work. The changes to the PyTypeObject declaration (adding tp_clean) can also be done without doing the "real work". After these "zero impact" changes are completed, then the GC patch will be greatly reduced in size and complexity. It makes it much more reviewable. The point being: even big patches can usually be broken down into layers. One layer after another, adding "platform" functionality until you get to the meat of the matter. The GC patch was a definite case of this. Really huge patches are okay if they have a *seriously* narrow focus. For example, Skip's patch to use PyArg_ParseTuple() with the ":method" stuff. That was pretty brain-dead to review. The hardest part was that the context-diff wasn't contextual enough to verify that the name in the ParseTuple matched the method that it occurred in. [ I found a case where they did not match. not easy... ] Cheers, -g -- Greg Stein, http://www.lyra.org/ From pf at artcom-gmbh.de Mon Jun 5 09:28:38 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Mon, 5 Jun 2000 09:28:38 +0200 (MEST) Subject: [Python-Dev] Suggestion: stopping to trust os mtimes In-Reply-To: from Greg Stein at "Jun 2, 2000 2:32:52 pm" Message-ID: Hi, Greg Stein: > He does have a point, but I think the wrong solution :-) > > While the clock may be monotonically increasing on one system, it isn't > always the case when things like NFS come into play. That is a well known and common trap. Don't use NFS for Software development unless you've read and understood RFC 868. ;-) BTW.: Last year someone posted a pure Python implementation of RFC 868 time server and clients to c.l.p. This might be useful on those WinXX boxes. > I recall a case back '95 when I was editing a .py over an NFS mount and > running the code on the target machine. The clocks on the two boxes were > off by about three seconds. I was going thru the edit/run/edit/run cycle > so quickly, that at one point, I saved a .py file that was older than the > associated .pyc file. > > Needless to say, I was really confused that my recent edit didn't produce > the desired result :-) Sure. ;-) But the same would have happenend, if you edited a .c source file and if your target computer has C-compiler/linker, which is fast enough to have a edit/compile/run cycle completed faster than the clock difference. This is not uncommon today. So the problem is not Python's fault and so I see no need to fix it there. One thing could be added though: If Python 'stat's a .py file, which has a time stamp in the future, it could issue a warning similar to that displayed by 'make': *** Warning: File `%s' has modification time in the future (%ld > %ld Possibly this message could point the user to RFC 868 and the 'netdate' Unix command. But that would be sugar on the cake. Regards, Peter From moshez at math.huji.ac.il Mon Jun 5 12:21:32 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Mon, 5 Jun 2000 13:21:32 +0300 (IDT) Subject: [Python-Dev] Suggestion: stopping to trust os mtimes In-Reply-To: Message-ID: On Mon, 5 Jun 2000, Peter Funk wrote: > Greg Stein: > > He does have a point, but I think the wrong solution :-) > > > > While the clock may be monotonically increasing on one system, it isn't > > always the case when things like NFS come into play. > > That is a well known and common trap. Don't use NFS for Software > development unless you've read and understood RFC 868. ;-) "Make"'s philosphy for basing the decision on which files need to be remade on the timestapmps is not necessarily the best -- but the user can replace mkae if it doesn't "do the right thing". Since Python takes on some of Make's roles (regenrating files only if those need to be regenerated), it is subject to the same problems. So it is Python's fault, and that's where the problem should be fixed. -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com From bwarsaw at python.org Mon Jun 5 15:21:05 2000 From: bwarsaw at python.org (bwarsaw at python.org) Date: Mon, 5 Jun 2000 09:21:05 -0400 (EDT) Subject: [Python-Dev] Revised 1.6 jobs list References: <14651.6640.709657.306682@anthem.python.org> Message-ID: <14651.43329.783797.949349@anthem.python.org> >>>>> "GS" == Greg Stein writes: GS> IMO, use the provided tools. The Patch Manager is more than we GS> have now. It also allows assignment, which can be nice :-) GS> (compared to the arbitrary "who is taking care of this patch?" GS> thing today) GS> The SF bug database certainly works, and it provides GS> additional "locality" for the code + bugs + patches. I've turned on the SF patch manager and bug database. -Barry From bwarsaw at python.org Mon Jun 5 15:32:54 2000 From: bwarsaw at python.org (Barry A. Warsaw) Date: Mon, 5 Jun 2000 09:32:54 -0400 (EDT) Subject: [Python-Dev] Revised 1.6 jobs list References: <14651.12876.575925.701737@localhost.localdomain> Message-ID: <14651.44038.828370.123514@anthem.python.org> >>>>> "JH" == Jeremy Hylton writes: JH> Many of the people who ultimately have checkin privileges JH> should limit themselves to their particular domains. There JH> are a bunch of modules that are owned by other people, JH> e.g. Eric's netrc module, your new httplib, MAL for Unicode, JH> etc. Right. I think GregS was the one advocating a more Apache-like model, where people have the ability to check into the whole tree, but generally don't or risk the derision of their peers. Python's big enough for people to assert their expertise over various corners. JH> Ultimately, I think I agree with Mark's suggestion that we be JH> a little more liberal with changes and risk backing out the JH> occasional changes. (For some definition of "a little more" JH> :-). It all depends on the scope of the changes. If it's fairly localized to a single library module, then we don't worry as much. More important there will be the API design. If it's a more sweeping change like GC or Unicode, or a change in the language definition, then there /has/ to be broader support. For Big Changes, I really like the RFC idea someone suggested. Gets everything documented for newbies and posterity. Has a shelf life, etc. -Barry From bwarsaw at python.org Mon Jun 5 15:36:28 2000 From: bwarsaw at python.org (Barry A. Warsaw) Date: Mon, 5 Jun 2000 09:36:28 -0400 (EDT) Subject: [Python-Dev] Revised 1.6 jobs list References: <14651.12876.575925.701737@localhost.localdomain> Message-ID: <14651.44252.78362.195436@anthem.python.org> >>>>> "GS" == Greg Stein writes: GS> In the Apache group, we have a very good set of eyeballs GS> watching the checkins. I'd say that each checkin is reviewed GS> by two or three people in detail. Invariably, there are GS> several checkins each week that result in a thread discussing: GS> (a) you broke it, (b) why was it done that way, (c) couldn't GS> it be done this way, (d) this appears to be missing, (e) etc. Maybe we also need to expand on the test suite, do nightly builds, and post the results. Kind of the way Mozilla does it. Well, Python probably doesn't change so radically every night, but a more expanded test suite with web based feedback would be cool. -Barry From bwarsaw at python.org Mon Jun 5 15:38:20 2000 From: bwarsaw at python.org (Barry A. Warsaw) Date: Mon, 5 Jun 2000 09:38:20 -0400 (EDT) Subject: [Python-Dev] Re: Is it just Syntactic Sugar ? References: <3929E47E.993727CF@roguewave.com> <3933F800.9CCE3B6D@cs.byu.edu> <20000530213957.E469@xs4all.nl> <20000531090045.I469@xs4all.nl> <3935B383.469032AE@python.org> <20000604005601.T469@xs4all.nl> <14651.13270.353056.246432@localhost.localdomain> Message-ID: <14651.44364.408119.422821@anthem.python.org> >>>>> "JH" == Jeremy Hylton writes: >>>>> "TW" == Thomas Wouters writes: TW> This was what I had in mind, and was trying to explain. Does TW> you voicing your opinion mean someone (you ? someone else ?) TW> is working on this, or soon going to work on this ? JH> I don't believe anyone at PythonLabs is working on this now, JH> certainly not Guido or I. I'm not tracking this either. -Barry From bwarsaw at python.org Mon Jun 5 15:41:39 2000 From: bwarsaw at python.org (Barry A. Warsaw) Date: Mon, 5 Jun 2000 09:41:39 -0400 (EDT) Subject: [Python-Dev] release forms? (was: [Patches] New sys method to return total reference count in debug builds.) References: Message-ID: <14651.44563.556790.469651@anthem.python.org> >>>>> "GS" == Greg Stein writes: GS> Given the New World Order, how does that impact the need for GS> these release statements and/or wet signatures? GS> Or a better way to put it, who "owns" Python now? Given a GS> "who", then we can ask that person/entity whether they want GS> release statements. GS> Given that Python is now on SourceForge, and there are GS> multiple people (at CNRI and otherwise) that can directly make GS> modifications, then the release below is certainly a bit GS> "off". For example, David Ascher has commit privs, so at his GS> "sole discretion, [he may] decide whether or not to GS> incorporiate this contribution..." :-) I talked to Guido briefly about this. Since 1.6 is the last "CNRI release", he wants to continue along the current path for the time being. I'm sure he'll be just as happy to chuck all this crap as Greg, and we probably will for 1.7. -Barry From fdrake at beopen.com Mon Jun 5 18:40:26 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 5 Jun 2000 12:40:26 -0400 (EDT) Subject: [Python-Dev] Revised 1.6 jobs list In-Reply-To: <14648.35974.486959.379543@anthem.python.org> References: <20000602232521.B986@newcnri.cnri.reston.va.us> <14648.35974.486959.379543@anthem.python.org> Message-ID: <14651.55290.728256.183107@cj42289-a.reston1.va.home.com> Barry A. Warsaw writes: > Did we ever decide on building in thread support by default? I'd > really like to see threads enabled by default in 1.6 and I /think/ > it'll just take some autoconf hacking, which I'm willing to do. Are > there any objections to building in threads support by default if > autoconf detects threads? test_fork1 fails on Linux with threads on SMP machines. (It's irrelevant without threads.) This is a hard failure -- the process can either SEGV or hang forever. Is this a showstopper? SMP boxes are becoming increasingly common both as servers and workstations. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From bwarsaw at python.org Mon Jun 5 18:55:49 2000 From: bwarsaw at python.org (bwarsaw at python.org) Date: Mon, 5 Jun 2000 12:55:49 -0400 (EDT) Subject: [Python-Dev] Revised 1.6 jobs list References: <20000602232521.B986@newcnri.cnri.reston.va.us> <14648.35974.486959.379543@anthem.python.org> <14651.55290.728256.183107@cj42289-a.reston1.va.home.com> Message-ID: <14651.56213.661929.481476@anthem.python.org> >>>>> "Fred" == Fred L Drake, Jr writes: Fred> test_fork1 fails on Linux with threads on SMP machines. Fred> (It's irrelevant without threads.) This is a hard failure Fred> -- the process can either SEGV or hang forever. Is this a Fred> showstopper? I would think so, regardless of whether threads are built-in by default or not. From fdrake at beopen.com Mon Jun 5 19:59:31 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 5 Jun 2000 13:59:31 -0400 (EDT) Subject: [Python-Dev] What's New (first draft) In-Reply-To: References: <20000602231550.A986@newcnri.cnri.reston.va.us> Message-ID: <14651.60035.502321.510452@cj42289-a.reston1.va.home.com> Mark Hammond writes: > Bill Tutt and I could do with a credit for the new winreg module. The documentation for winreg could stand to be written as well -- care to extract the docstrings, or is that in my court? ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From DavidA at ActiveState.com Mon Jun 5 21:26:13 2000 From: DavidA at ActiveState.com (David Ascher) Date: Mon, 5 Jun 2000 12:26:13 -0700 Subject: [Python-Dev] Revised 1.6 jobs list In-Reply-To: <14651.55290.728256.183107@cj42289-a.reston1.va.home.com> Message-ID: > test_fork1 fails on Linux with threads on SMP machines. (It's > irrelevant without threads.) This is a hard failure -- the process > can either SEGV or hang forever. > Is this a showstopper? SMP boxes are becoming increasingly common > both as servers and workstations. Why does the test fail? I'd hate to see the thousands (nay, hundreds of thousands) of users complain that foo isn't working just because the test for a rarely used feature on a rare platform is broken. --david From nascheme at enme.ucalgary.ca Mon Jun 5 23:03:13 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Mon, 5 Jun 2000 15:03:13 -0600 Subject: [Python-Dev] Re: Revised 1.6 jobs list Message-ID: <20000605150313.A15917@acs.ucalgary.ca> [David Ascher] >> test_fork1 fails on Linux with threads on SMP machines. (It's >> irrelevant without threads.) This is a hard failure -- the >> process can either SEGV or hang forever. Is this a showstopper? >> SMP boxes are becoming increasingly common both as servers and >> workstations. > > Why does the test fail? I'd hate to see the thousands (nay, > hundreds of thousands) of users complain that foo isn't working > just because the test for a rarely used feature on a rare > platform is broken. Threads and fork() don't seem to mix on Linux. Even on a UP machine things seem strange: http://www.deja.com/[ST_rn=ps]/getdoc.xp?AN=613477888&fmt=text I tried to reproduce the problem with a C program but could not. When things hang the forking thread is stuck in wait4() while the child process is suspended: #0 0x4027d9ba in sigsuspend () from /lib/libc.so.6 #1 0x40232c77 in __pthread_wait_for_restart_signal () from /lib/libpthread.so.0 #2 0x4023406e in __pthread_lock () from /lib/libpthread.so.0 #3 0x4023186a in pthread_mutex_lock () from /lib/libpthread.so.0 #4 0x806fbaa in PyThread_release_lock (lock=0x81ebb68) at thread_pthread.h:339 #5 0x805617b in eval_code2 (co=0x81eca68, globals=0x81c4f64, locals=0x0, args=0x81be278, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, owner=0x0) at ceval.c:630 #6 0x805ac19 in call_function (func=0x81ebb2c, arg=0x81be26c, kw=0x0) at ceval.c:2552 #7 0x805a5a4 in PyEval_CallObjectWithKeywords (func=0x81ebb2c, arg=0x81be26c, kw=0x0) at ceval.c:2390 #8 0x80b2c7b in t_bootstrap (boot_raw=0x81ebb50) at ./threadmodule.c:224 #9 0x40230c8f in pthread_start_thread () from /lib/libpthread.so.0 I don't know if this is a LinuxThread problem or a Python problem. Neil -- The internet: Learn what you know. Share what you don't. From DavidA at ActiveState.com Mon Jun 5 23:23:11 2000 From: DavidA at ActiveState.com (David Ascher) Date: Mon, 5 Jun 2000 14:23:11 -0700 Subject: [Python-Dev] RE: Revised 1.6 jobs list In-Reply-To: <20000605150313.A15917@acs.ucalgary.ca> Message-ID: > Threads and fork() don't seem to mix on Linux. Even on a > UP machine things seem strange: I believe it. My general point however is that even if the problem can't be fixed because Linux is broken in some way, the test suite should be fixed even if it means to ignore failures of test_fork1 if the system was configured --with-thread. --david From mhammond at skippinet.com.au Tue Jun 6 01:47:44 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Tue, 6 Jun 2000 09:47:44 +1000 Subject: [Python-Dev] Re: Revised 1.6 jobs list In-Reply-To: <20000605150313.A15917@acs.ucalgary.ca> Message-ID: > I tried to reproduce the problem with a C program but could not. > When things hang the forking thread is stuck in wait4() while the > child process is suspended: This looks very suspect. > > #0 0x4027d9ba in sigsuspend () from /lib/libc.so.6 > #1 0x40232c77 in __pthread_wait_for_restart_signal () > from /lib/libpthread.so.0 > #2 0x4023406e in __pthread_lock () from /lib/libpthread.so.0 > #3 0x4023186a in pthread_mutex_lock () from /lib/libpthread.so.0 > #4 0x806fbaa in PyThread_release_lock (lock=0x81ebb68) at > thread_pthread.h:339 > #5 0x805617b in eval_code2 (co=0x81eca68, globals=0x81c4f64, And very much like the Python thread-state is not being managed correctly with fork. From my understanding of fork (which is small), and of the Python thread-state management, this doesnt surprise me. Given the stack trace, it appears that Python is doing its periodic thread-release as part of running around the main loop. In the process of _releasing_ the thread-lock, it needs to _acquire_ a mutex. I dont know the Python threading on pthreads at all - would this be correct (it would seem likely that such an implementation would be done). But in the process of acquiring that mutex, we call __pthread_wait_for_restart_signal() Is it possible that is is something as simple as thread-idents changing underneath Python when using fork? It seems to me that the thread thinks it is either new, or stale? Just my 2c worth - and given my knowledge of Linux and pthreads, plus the state of our dollar at the moment, it has better be AUD $0.02 :-) Mark. From trentm at activestate.com Tue Jun 6 02:14:03 2000 From: trentm at activestate.com (Trent Mick) Date: Mon, 5 Jun 2000 17:14:03 -0700 Subject: [Python-Dev] PyMarshal_WriteLongToFile: writes 'long' or 32-bit integer? In-Reply-To: References: <20000602111417.A17233@activestate.com> Message-ID: <20000605171403.A21808@activestate.com> On Sat, Jun 03, 2000 at 10:56:15AM +0300, Moshe Zadka wrote: > On Fri, 2 Jun 2000, Trent Mick wrote: > > > 3. - change PyMarshal_WriteLongToFile to raise an exception if the long > > overflows a 32-bit range > > +1 on that, finally non-portable integers will cause an exception. > Okay, I have to reiterate and ask again because I have the suspicion that I may be missing the point and you all may not realize that. Stop me when I go astray: - the PyMarshal interface is used for all the .pyc content writing - PyMarshal_WriteLongToFile is only used for writing the magic number and the time stamp - the rest of the .pyc is written via PyMarshal_WriteObjectToFile - PyMarshal_WriteLongToFile will currently silently truncate a 64-bit long to 32-bits - PyMarshal_WriteObjectToFile, when writing a PyInt and hence a C long, will *NOT* truncate the 64-bit integer but will write the whole thing - On reading a .pyc the PyMarshal_ReadObjectFromFile will complain on stderr when a 64-bit integral value is read and the current platform is 32-bit. The question is: Do we want PyMarshal_WriteLongToFile *AND* PyMarshal_WriteObjectToFile to raise an exception when a long value overflows 32-bits? Up til now I was only proposing the former. Trent -- Trent Mick trentm at activestate.com From esr at thyrsus.com Tue Jun 6 03:02:31 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 5 Jun 2000 21:02:31 -0400 Subject: [Python-Dev] ascii.py Message-ID: <20000605210231.A25895@thyrsus.com> Latest version. Adds isctrl() and ismeta() functions (because I use them...) Um. What's the checkin procedure for library modules? And do I have permissions to do it? -- Eric S. Raymond "Guard with jealous attention the public liberty. Suspect every one who approaches that jewel. Unfortunately, nothing will preserve it but downright force. Whenever you give up that force, you are inevitably ruined." -- Patrick Henry, speech of June 5 1788 -------------- next part -------------- # # ascii.py -- constants and memembership tests for ASCII characters # NUL = 0x00 # ^@ SOH = 0x01 # ^A STX = 0x02 # ^B ETX = 0x03 # ^C EOT = 0x04 # ^D ENQ = 0x05 # ^E ACK = 0x06 # ^F BEL = 0x07 # ^G BS = 0x08 # ^H TAB = 0x09 # ^I HT = 0x09 # ^I LF = 0x0a # ^J NL = 0x0a # ^J VT = 0x0b # ^K FF = 0x0c # ^L CR = 0x0d # ^M SO = 0x0e # ^N SI = 0x0f # ^O DLE = 0x10 # ^P DC1 = 0x11 # ^Q DC2 = 0x12 # ^R DC3 = 0x13 # ^S DC4 = 0x14 # ^T NAK = 0x15 # ^U SYN = 0x16 # ^V ETB = 0x17 # ^W CAN = 0x18 # ^X EM = 0x19 # ^Y SUB = 0x1a # ^Z ESC = 0x1b # ^[ FS = 0x1c # ^\ GS = 0x1d # ^] RS = 0x1e # ^^ US = 0x1f # ^_ SP = 0x20 # space DEL = 0x7f # delete controlnames = [ "NUL", "SOH", "STX", "ETX", "EOT", "ENQ", "ACK", "BEL", "BS", "HT", "LF", "VT", "FF", "CR", "SO", "SI", "DLE", "DC1", "DC2", "DC3", "DC4", "NAK", "SYN", "ETB", "CAN", "EM", "SUB", "ESC", "FS", "GS", "RS", "US", "SP" ] def _ctoi(c): if type(c) == type(""): return ord(c) else: return c def isalnum(c): return isalpha(c) or isdigit(c) def isalpha(c): return isupper(c) or islower(c) def isascii(c): return _ctoi(c) <= 127 # ? def isblank(c): return _ctoi(c) in (8,32) def iscntrl(c): return _ctoi(c) <= 31 def isdigit(c): return _ctoi(c) >= 48 and _ctoi(c) <= 57 def isgraph(c): return _ctoi(c) >= 33 and _ctoi(c) <= 126 def islower(c): return _ctoi(c) >= 97 and _ctoi(c) <= 122 def isprint(c): return _ctoi(c) >= 32 and _ctoi(c) <= 126 def ispunct(c): return _ctoi(c) != 32 and not isalnum(c) def isspace(c): return _ctoi(c) in (12, 10, 13, 9, 11) def isupper(c): return _ctoi(c) >= 65 and _ctoi(c) <= 90 def isxdigit(c): return isdigit(c) or \ (_ctoi(c) >= 65 and _ctoi(c) <= 70) or (_ctoi(c) >= 97 and _ctoi(c) <= 102) def isctrl(c): return _ctoi(c) < 32 def ismeta(c): return _ctoi(c) > 127 def ascii(c): if type(c) == type(""): return chr(_ctoi(c) & 0x7f) else: return _ctoi(c) & 0x7f def ctrl(c): if type(c) == type(""): return chr(_ctoi(c) & 0x1f) else: return _ctoi(c) & 0x1f def alt(c): if type(c) == type(""): return chr(_ctoi(c) | 0x80) else: return _ctoi(c) | 0x80 def unctrl(c): bits = _ctoi(c) if bits == 0x7f: rep = "^?" elif bits & 0x20: rep = chr((bits & 0x7f) | 0x20) else: rep = "^" + chr(((bits & 0x7f) | 0x20) + 0x20) if bits & 0x80: return "!" + rep return rep -------------- next part -------------- A non-text attachment was scrubbed... Name: libascii.tex Type: application/x-tex Size: 4408 bytes Desc: not available URL: From gstein at lyra.org Tue Jun 6 03:10:17 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 5 Jun 2000 18:10:17 -0700 (PDT) Subject: [Python-Dev] ascii.py In-Reply-To: <20000605210231.A25895@thyrsus.com> Message-ID: On Mon, 5 Jun 2000, Eric S. Raymond wrote: > Latest version. Adds isctrl() and ismeta() functions (because I use them...) > > Um. What's the checkin procedure for library modules? Guido has to give his blessing -- that he finds this useful and appropriate for the Python library. He does that using his own criteria and feedback from people here. For example, I'm "+0" on it. (meaning that it seems okay, but I can also live without it) The actual mechanics are outlined at SourceForge: http://sourceforge.net/cvs/?group_id=5470 > And do I have permissions to do it? Nope. There are ten people with checkin privs: http://sourceforge.net/project/memberlist.php?group_id=5470 Five of them are admins (Barry, Fred, Guido, Jeremy, Tim). They use policy to determine whether a given person should become a SF project member. That policy is probably just a gut feeling rather than concrete rules, so I can't say "X, Y, and Z." I also don't know what kinds of policies that they are asserting on people with privs. Cheers, -g -- Greg Stein, http://www.lyra.org/ From jeremy at beopen.com Tue Jun 6 03:23:40 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 5 Jun 2000 21:23:40 -0400 (EDT) Subject: [Python-Dev] ascii.py In-Reply-To: References: <20000605210231.A25895@thyrsus.com> Message-ID: <14652.21148.139774.192634@localhost.localdomain> Greg seems to understand this process better than the admins -- or at least he can explain it quickly and clearly :-). I apologize for the rather confused state of affairs. We'll clean up the process and document it soon. >>>>> "GS" == Greg Stein writes: GS> On Mon, 5 Jun 2000, Eric S. Raymond wrote: >> Latest version. Adds isctrl() and ismeta() functions (because I >> use them...) >> >> Um. What's the checkin procedure for library modules? GS> Guido has to give his blessing -- that he finds this useful and GS> appropriate for the Python library. He does that using his own GS> criteria and feedback from people here. I think I can safely speak for the admins when I say that we're not sure what the process is other than securing Guido's blessing. We need to work out a clearer policy, but that will have to wait until Guido gets back from his honeymoon. Any new checkins we are making are limited for the most part to modules we've already gotten his blessing for. There won't be another alpha release until he returns, so it's not like we have to worry about getting new code in before a code freeze. GS> For example, I'm "+0" on it. (meaning that it seems okay, but I GS> can also live without it) I'm in the same boat. GS> There are ten people with checkin privs: GS> http://sourceforge.net/project/memberlist.php?group_id=5470 GS> Five of them are admins (Barry, Fred, Guido, Jeremy, Tim). They GS> use policy to determine whether a given person should GS> become a SF project member. That policy is probably just a gut GS> feeling rather than concrete rules, so I can't say "X, Y, and GS> Z." I also don't know what kinds of policies that they are GS> asserting on people with privs. Another policy that needs to be defined. "" is surprisingly close to what we actually have written down in our policies and procedures manual. I expect we will arrive at a policy where people own pieces of the library and are free to maintain it. Guido will probably retain control over what modules come and go. -- Jeremy Hylton From esr at thyrsus.com Tue Jun 6 03:33:24 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 5 Jun 2000 21:33:24 -0400 Subject: [Python-Dev] ascii.py In-Reply-To: <14652.21148.139774.192634@localhost.localdomain>; from jeremy@beopen.com on Mon, Jun 05, 2000 at 09:23:40PM -0400 References: <20000605210231.A25895@thyrsus.com> <14652.21148.139774.192634@localhost.localdomain> Message-ID: <20000605213324.A26055@thyrsus.com> Jeremy Hylton : > Another policy that needs to be defined. "" is surprisingly > close to what we actually have written down in our policies and > procedures manual. I expect we will arrive at a policy where people > own pieces of the library and are free to maintain it. Guido will > probably retain control over what modules come and go. Pretty much as I expected. OK. Let us know when things settle out a little. -- Eric S. Raymond Before a standing army can rule, the people must be disarmed, as they are in almost every kingdom in Europe. The supreme power in America cannot enforce unjust laws by the sword, because the people are armed, and constitute a force superior to any band of regular troops. -- Noah Webster From tim_one at email.msn.com Tue Jun 6 04:09:22 2000 From: tim_one at email.msn.com (Tim Peters) Date: Mon, 5 Jun 2000 22:09:22 -0400 Subject: Augmented assignment (was RE: [Python-Dev] Re: Is it just Syntactic Sugar ?) In-Reply-To: <20000604005601.T469@xs4all.nl> Message-ID: <001601bfcf5c$3bcb8e00$0ca0143f@tim> [posted & mailed] [Thomas Wouters, asking about Guido's sketch] > This was what I had in mind, and was trying to explain. Does you > voicing your opinion mean someone (you ? someone else ?) is working > on this, or soon going to work on this ? It's the same scheme he sketched the last time he was provoked into writing about this , and that was at least a year ago. > ... > I'm curious what should happen with index-assignment and > slice-assignment: Nothing special! You're reading far too much into Guido's sketch -- it doesn't have all these convolutions. Try reading his msg again, but this time thinking like him too . > x[y] += z temp1 = x # perhaps the first three are permuted, though temp2 = y temp3 = z temp1[temp2] = temp1[temp2].__add_ab__(temp3) And, yes, indexing is done twice (although "x" and "y" are evaluated only once each). > x[:y] += z temp1 = x temp2 = y temp3 = z temp1[:temp2] = temp1[:temp2].__add_ab__(temp3) Similarly slicing is done twice. > (Obviously this wont make sense for a lot of types, or will be too > un-obvious to include, but I can imagine matrix-types to happily > add this.) Every type is free to implement __add_ab__ or not, in whatever way it likes. But Python can't tell at compile-time which types do and don't implement it, so chances are great that doing x += y for x of a type that does not implement __add_ab__ will raise a runtime AttributeError. > Would this call x.__add_item_ab__(y, z) and x.__add_slice_ab__(0, > y, z) ? No. *All* instances of "+=" are mapped straightforwardly to __add_ab__. Context is irrelevent; indexing and slicing are not special cases (except to the extent that they are already ...). > Or would x[y] += z always call x[y].__add_item_ab__() No. > and x[:y] create a new object, a slice of x What x[:y] means is entirely up to the type of x, and has no connection to augmented assignment (except in that the author of the type may design both to work smoothly together). > and call its __add_ab__() method ? __add_ab__ would be invoked on whatever x[:y] returns; whether that's "a new object" or not is x.__get_slice__'s choice to make. > Or would it try all of them, or more, until it gets a good result ? No. It works or it doesn't. > Or am I running ahead of things and should we wait for a working > patch first ? :) No, you're running a few years behind things , and imagining complications Guido would never sign up for. and-now-the-spirits-must-rest-ly y'rs - tim From bwarsaw at python.org Tue Jun 6 04:27:42 2000 From: bwarsaw at python.org (Barry A. Warsaw) Date: Mon, 5 Jun 2000 22:27:42 -0400 (EDT) Subject: [Python-Dev] ascii.py References: <20000605210231.A25895@thyrsus.com> <14652.21148.139774.192634@localhost.localdomain> Message-ID: <14652.24990.563016.976820@anthem.python.org> >>>>> "JH" == Jeremy Hylton writes: JH> I think I can safely speak for the admins when I say that JH> we're not sure what the process is other than securing Guido's JH> blessing. We need to work out a clearer policy, but that will JH> have to wait until Guido gets back from his honeymoon. Any JH> new checkins we are making are limited for the most part to JH> modules we've already gotten his blessing for. My suggestion would be to upload to the SourceForge patch manager, any patches or code you care about that you don't want us to lose track of. Things get buried in my inbox pretty easily, but at least with the patch manager, we've got a record of it, and can eventually assign a developer to tracking it. -Barry From trentm at activestate.com Tue Jun 6 04:52:44 2000 From: trentm at activestate.com (Trent Mick) Date: Mon, 5 Jun 2000 19:52:44 -0700 Subject: [Python-Dev] about patches on SourceForge Message-ID: <20000605195244.A25437@activestate.com> I just put up one my patches from this past week on SOurceForge. Question: WWould you all prefer to have the "raw patch" just include the actually patch/diff and for the first comment to be the patch description (and legal stuff?) or would you prefer for the patch description and legal stuff to be part of the "raw patch". I am inclined to think that the former would be preferable. Is there some "apply patch" button in SourceForge that would require the "raw patch" to actually be raw? Go check it out and you will know what I am talking about. http://sourceforge.net/patch/?func=browse&group_id=5470&set=open When I get an good opinion from some of you I will send up my other patches. Trent -- Trent Mick trentm at activestate.com From gstein at lyra.org Tue Jun 6 05:32:27 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 5 Jun 2000 20:32:27 -0700 (PDT) Subject: [Python-Dev] Re: httplib In-Reply-To: <14651.13155.253651.575394@localhost.localdomain> Message-ID: On Mon, 5 Jun 2000, Jeremy Hylton wrote: > >>>>> "GS" == Greg Stein writes: >... > >> Oh. Wait. Maybe that was it. You can't read the "next" response > >> until the first one has been read. Well... no need to block > >> putting new responses; we just need to create a way to "get the > >> next reply" and/or "can I get the next reply yet?" > > Maybe I should clarify the concern I had here. I think we're on the > same page, but I'm not sure. > > The problem with pipelined requests is that the client must be sure to > read all of response I before it can call getreply to get response > I+1. Actually, you can issue a getreply() after you've read the prior response's headers, but before you completely read its body. Once you have the header, then you know whether the connection will remain open or not. Assuming it *will* remain open, then you can go ahead and do a request/reply sequence. If the connection is going to close, then you have to fail at request time. > I imagine that it could add a lot of complexity to use code to > implement this requirement, e.g. when multiple threads are sharing a > single connection. It would be good if the library could do something > reasonable about the multiplexing. In the absence of making it just > work, the library could raise an error that makes clear what has gone > wrong -- that the client isn't using the interface properly. I'm working through this stuff right now. It is a bit tricky to get it right *and* have it clear. I'm concentrating on the latter as much as possible. At the moment, HTTPResponse instances can be created without problems. I'm locating the "can you issue a request [and get a response]" logic in the connection object itself. Another detail that I'm trying to work through is where the connection is allowed to get the HTTPResponse to read the HTTP header. Reading off the network could block, so we need to be a bit more careful about what methods can block (if any). In any case, the current httplib (at www.lyra.org/greg/python/) has got just about everything. The next checkin will deal with this pipelining issue. QUESTION #2: I *really* want to get rid of the HTTPS() class. It is introducing excessive complexity, with the only purpose being compatibility against the post-1.5.2 CVS. Anyone? Thoughts on removal? Cheers, -g -- Greg Stein, http://www.lyra.org/ From mhammond at skippinet.com.au Tue Jun 6 05:43:15 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Tue, 6 Jun 2000 13:43:15 +1000 Subject: [Python-Dev] about patches on SourceForge In-Reply-To: <20000605195244.A25437@activestate.com> Message-ID: > When I get an good opinion from some of you I will send up my > other patches. How do you qualify a "good" opinion? One that matches yours? This is all too hard until Guido gets back. But personally I believe the raw patch should be just the CVS diff output, and the comments should reflect all other text, including the release notice while it is still necessary. I hope my opinion is good enough :-) Mark. From jeremy at beopen.com Tue Jun 6 05:46:01 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 5 Jun 2000 23:46:01 -0400 (EDT) Subject: [Python-Dev] Re: httplib In-Reply-To: References: <14651.13155.253651.575394@localhost.localdomain> Message-ID: <14652.29689.663218.777234@localhost.localdomain> >>>>> "GS" == Greg Stein writes: GS> QUESTION #2: I *really* want to get rid of the HTTPS() class. It GS> is introducing excessive complexity, with the only purpose being GS> compatibility against the post-1.5.2 CVS. GS> Anyone? Thoughts on removal? I've got two answers. I don't particularly like the old-style HTTP interface, so I'm happy to see it replaced with a better one. I say who cares about HTTPS. On the other hand, there is a lot of existing code that uses the old interface. It would be good if that code could be modified to use the new SSL interface without having to also re-write the code to use the new http interface. Perhaps we should keep it to provide a future upgrade path for all the legacy code. I could probably be convinced that the amount of effort to change from the old interface to the new interface is fairly small. If you're going to make one change to the code anyway, might as well start using the modern interface, too. Is there anyone who actually has http code to maintain that has an opinion? Jeremy From fdrake at beopen.com Tue Jun 6 05:45:54 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 5 Jun 2000 23:45:54 -0400 (EDT) Subject: [Python-Dev] about patches on SourceForge In-Reply-To: References: <20000605195244.A25437@activestate.com> Message-ID: <14652.29682.819341.881773@cj42289-a.reston1.va.home.com> Mark Hammond writes: > This is all too hard until Guido gets back. But personally I believe the > raw patch should be just the CVS diff output, and the comments should > reflect all other text, including the release notice while it is still > necessary. Sounds good to me. Let's do it this way until there's a god reason to do it differently. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From pf at artcom-gmbh.de Tue Jun 6 11:05:58 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Tue, 6 Jun 2000 11:05:58 +0200 (MEST) Subject: [Python-Dev] PyMarshal_WriteLongToFile: writes 'long' or 32-bit integer? In-Reply-To: <20000605171403.A21808@activestate.com> from Trent Mick at "Jun 5, 2000 5:14: 3 pm" Message-ID: Hi, [Trent Mick]: [...] > - PyMarshal_WriteObjectToFile, when writing a PyInt and hence a C long, will > *NOT* truncate the 64-bit integer but will write the whole thing > > - On reading a .pyc the PyMarshal_ReadObjectFromFile will complain on stderr > when a 64-bit integral value is read and the current platform is 32-bit. [...] > The question is: Do we want PyMarshal_WriteLongToFile *AND* > PyMarshal_WriteObjectToFile to raise an exception when a long value overflows > 32-bits? Up til now I was only proposing the former. Yes. This should at least be the default behaviour of Python. The current behaviour would otherwise cause great damage in the following scenario, where an innocent software developer working on a 64-Bit system trusts on the cross platform portability of Pythons bytecode files and unintentional uses a huge integer literal. If some people really don't care about portability, there could be switch/option/pragma/whatever to disable this behaviour. IMO the portability of Python bytecode files is a *very* valuable property, which we shouldn't give up on. Regards, Peter From gstein at lyra.org Tue Jun 6 11:58:44 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 6 Jun 2000 02:58:44 -0700 (PDT) Subject: [Python-Dev] PyMarshal_WriteLongToFile: writes 'long' or 32-bit integer? In-Reply-To: Message-ID: On Tue, 6 Jun 2000, Peter Funk wrote: > [Trent Mick]: > [...] > > - PyMarshal_WriteObjectToFile, when writing a PyInt and hence a C long, will > > *NOT* truncate the 64-bit integer but will write the whole thing > > > > - On reading a .pyc the PyMarshal_ReadObjectFromFile will complain on stderr > > when a 64-bit integral value is read and the current platform is 32-bit. > [...] > > The question is: Do we want PyMarshal_WriteLongToFile *AND* > > PyMarshal_WriteObjectToFile to raise an exception when a long value overflows > > 32-bits? Up til now I was only proposing the former. > > Yes. This should at least be the default behaviour of Python. > > The current behaviour would otherwise cause great damage in the > following scenario, where an innocent software developer working on > a 64-Bit system trusts on the cross platform portability of Pythons > bytecode files and unintentional uses a huge integer literal. > > If some people really don't care about portability, there could be > switch/option/pragma/whatever to disable this behaviour. > > IMO the portability of Python bytecode files is a *very* valuable property, > which we shouldn't give up on. It isn't only bytecodes. As I mentioned before, marshal byte streams are specified as portable. Therefore, they are used all the time for passing over the network, for persistence mechanisms, etc. Having a marshal stream that is *not* cross-platform is just plain busted. So... you can silently truncate to 32-bits or you can raise an exception. You cannot, however, marshal a 64-bit value when the definition of an "marshal integer" is only 32. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gvwilson at nevex.com Tue Jun 6 16:40:25 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Tue, 6 Jun 2000 10:40:25 -0400 (EDT) Subject: [Python-Dev] req: Software Carpentry / coding standards Message-ID: Hi, everyone. We're a month away from final submissions in the Software Carpentry design competition, which means we're two months away from announcing winners and starting implementation effort, and we're wondering whether there are generally-accepted coding standards, naming conventions, or other guidelines that we should adopt. If so, URLs would be welcome... Also, it appears that there are two implementations of the xUnit testing framework in Python: Steve Purcell: http://sourceforge.net/project/?group_id=3912 Cayte Lindner: ftp://bio.perl.org/pub/katel/biopython/UnitTests/PyUnit.zip We'd be grateful for comments on either. Thanks, Greg Wilson Software Carpentry Project Coordinator From klm at digicool.com Tue Jun 6 18:16:58 2000 From: klm at digicool.com (Ken Manheimer) Date: Tue, 6 Jun 2000 12:16:58 -0400 (EDT) Subject: [Python-Dev] Guido and Kim married Message-ID: <14653.9210.757666.324583@korak.digicool.com> Guido van Rossum and Kim Knapp were married Saturday afternoon on the lawn of a graceful southern estate, Claymont Court, in West Virginia, USA. The weather was *stunningly* fine - a great boon, considering the rain the night before (a torrential downpour in nearby DC) - and the couple left for their honeymoon sunday. Hooray! The crowd consisted of i would guess 70 to 100 people, a mixture of hollanders (including several van rossum relatives - hiya Just!), knapps, pythoners, contact improvisors, economists, martial artists, and sundry other friends and family. I leave to others to quibble about whether or not this qualifies as a "python development". (I probably made enough of a fool of myself at the wedding, with pronouncements of good will and dancing and such, that i can't do any more harm...-) Yay! Ken klm at digicool.com From tim_one at email.msn.com Tue Jun 6 19:20:49 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 6 Jun 2000 13:20:49 -0400 Subject: [Python-Dev] req: Software Carpentry / coding standards In-Reply-To: Message-ID: <001001bfcfdb$8f64d240$48a2143f@tim> [Greg Wilson] > Hi, everyone. We're a month away from final submissions in the > Software Carpentry design competition, which means we're two months > away from announcing winners and starting implementation effort, Yay! This is a wonderful competition, and if nobody yet has bothered to thank you for spearheading it, let me know & I'll find someone who will . > and we're wondering whether there are generally-accepted coding > standards, naming conventions, or other guidelines that we should > adopt. If so, URLs would be welcome... When you can't fight about where to put curly braces, there's not much left to argue. The only serious attempt at a Python style guide I've seen is Guido's: http://www.python.org/doc/essays/styleguide.html Two from there large numbers of people will still argue about, but to no avail: + No hard tabs. Indents are 4 spaces, period. + Keep lines strictly less than 80 characters wide (I happen to keep them under 77, to allow for one level of "> " mail quoting). These rules ensure that code is readable as intended across all platforms. > Also, it appears that there are two implementations of the xUnit > testing framework in Python: > > Steve Purcell: http://sourceforge.net/project/?group_id=3912 > Cayte Lindner: ftp://bio.perl.org/pub/katel/biopython/UnitTests/PyUnit.zip > > We'd be grateful for comments on either. Sorry, unfamiliar with these. From pingster at ilm.com Tue Jun 6 19:25:57 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Tue, 6 Jun 2000 10:25:57 -0700 (PDT) Subject: [Python-Dev] req: Software Carpentry / coding standards In-Reply-To: <001001bfcfdb$8f64d240$48a2143f@tim> Message-ID: On Tue, 6 Jun 2000, Tim Peters wrote: > > Yay! This is a wonderful competition, and if nobody yet has bothered to > thank you for spearheading it, let me know & I'll find someone who will > . Yeah, what he said. :) > The only serious attempt at a Python style guide I've seen is Guido's: > > http://www.python.org/doc/essays/styleguide.html I love this style guide. I know it's a strange reaction to have to a style guide, but i agree with basically everything in it, which is probably pretty rare for these sorts of things. > + No hard tabs. Indents are 4 spaces, period. Tab characters are the work of the devil. -- ?!ng "China is a big country, inhabited by many Chinese." -- Former French President Charles de Gaulle From gvwilson at nevex.com Tue Jun 6 19:31:32 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Tue, 6 Jun 2000 13:31:32 -0400 (EDT) Subject: [Python-Dev] req: Software Carpentry / coding standards In-Reply-To: <001001bfcfdb$8f64d240$48a2143f@tim> Message-ID: > Tim Peters wrote: > When you can't fight about where to put curly braces, there's not much > left to argue. The only serious attempt at a Python style guide I've > seen is Guido's: > http://www.python.org/doc/essays/styleguide.html Yes, I've seen this. I was wondering (a) whether it's up to date (i.e. whether common practice has moved on), and (b) whether there is now a consensus about module structure --- we're expecting several packages that will be shared between tools, plus multiple modules within tools. I've been tracking the occasional message about re-organizing the standard Python library, and would like whatever we do to be in line with wherever Python itself is going. Thanks, Greg From esr at thyrsus.com Tue Jun 6 19:47:13 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Tue, 6 Jun 2000 13:47:13 -0400 Subject: [Python-Dev] req: Software Carpentry / coding standards In-Reply-To: ; from pingster@ilm.com on Tue, Jun 06, 2000 at 10:25:57AM -0700 References: <001001bfcfdb$8f64d240$48a2143f@tim> Message-ID: <20000606134713.A29204@thyrsus.com> Ka-Ping Yee : > > The only serious attempt at a Python style guide I've seen is Guido's: > > > > http://www.python.org/doc/essays/styleguide.html > > I love this style guide. I know it's a strange reaction to > have to a style guide, but i agree with basically everything > in it, which is probably pretty rare for these sorts of things. Likewise. I never read this before, but it's spooky how closely the style I evolved myself tracks it. -- Eric S. Raymond If a thousand men were not to pay their tax-bills this year, that would ... [be] the definition of a peaceable revolution, if any such is possible. -- Henry David Thoreau From petrilli at amber.org Tue Jun 6 19:52:50 2000 From: petrilli at amber.org (Christopher Petrilli) Date: Tue, 6 Jun 2000 13:52:50 -0400 Subject: [Python-Dev] req: Software Carpentry / coding standards In-Reply-To: <001001bfcfdb$8f64d240$48a2143f@tim>; from tim_one@email.msn.com on Tue, Jun 06, 2000 at 01:20:49PM -0400 References: <001001bfcfdb$8f64d240$48a2143f@tim> Message-ID: <20000606135250.A25856@trump.amber.org> Tim Peters [tim_one at email.msn.com] wrote: > When you can't fight about where to put curly braces, there's not much left > to argue. The only serious attempt at a Python style guide I've seen is > Guido's: > > http://www.python.org/doc/essays/styleguide.html The only thing that might be added (I haven't looked in a while, but didn't see it last time I did), is some naming convention issues. I follow pretty standard Smalltalk guidelines: - No '_', use camelCase for seps - Capitalize all Classes, and also global variables - Lowercase for all methods (i.e. setNewBreakpoint) This is just me, and obviously not everyone does this :-) Chris -- | Christopher Petrilli | petrilli at amber.org From gvwilson at nevex.com Tue Jun 6 19:50:38 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Tue, 6 Jun 2000 13:50:38 -0400 (EDT) Subject: [Python-Dev] req: Software Carpentry / coding standards In-Reply-To: <20000606135250.A25856@trump.amber.org> Message-ID: > > Tim Peters: > > http://www.python.org/doc/essays/styleguide.html > On Tue, 6 Jun 2000, Christopher Petrilli wrote: > The only thing that might be added (I haven't looked in a while, but > didn't see it last time I did), is some naming convention issues. I > follow pretty standard Smalltalk guidelines: > > - No '_', use camelCase for seps I know this is become common practice, but I've been told by two different HCI specialists that studies have shown CamelBackNotation to be harder for non-native speakers to read than underbar_separated_text, particularly when acronyms are part of the name. If anyone has a pointer to an original reference for this, I'd be grateful. Thanks, Greg From klm at digicool.com Tue Jun 6 20:32:12 2000 From: klm at digicool.com (Ken Manheimer) Date: Tue, 6 Jun 2000 14:32:12 -0400 (EDT) Subject: [Python-Dev] req: Software Carpentry / coding standards In-Reply-To: Message-ID: On Tue, 6 Jun 2000, Ka-Ping Yee wrote: > > The only serious attempt at a Python style guide I've seen is Guido's: > > > > http://www.python.org/doc/essays/styleguide.html > > I love this style guide. I know it's a strange reaction to > have to a style guide, but i agree with basically everything > in it, which is probably pretty rare for these sorts of things. Me too! (Or three, or four by now...) Ken klm at digicool.com From tim_one at email.msn.com Tue Jun 6 20:36:26 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 6 Jun 2000 14:36:26 -0400 Subject: [Python-Dev] PyMarshal_WriteLongToFile: writes 'long' or 32-bitinteger? In-Reply-To: Message-ID: <001201bfcfe6$1fe51dc0$48a2143f@tim> [GregS] > It isn't only bytecodes. As I mentioned before, marshal byte streams are > specified as portable. Therefore, they are used all the time for passing > over the network, for persistence mechanisms, etc. > > Having a marshal stream that is *not* cross-platform is just plain busted. > > So... you can silently truncate to 32-bits or you can raise an exception. But in either of those cases it's not cross-platform == it's just plain busted. > You cannot, however, marshal a 64-bit value when the definition of an > "marshal integer" is only 32. The current code is insane. Long-term the visible distinction between (Python) ints and longs should vanish. Short-term the PyInt_Check case of w_object should see whether the int fits in 4 bytes, and if so write it as a C long, and if not write the thing as a Python long (that's the only way to keep the marshal portable!). Any code keying off the SIZEOF_LONG symbol is highly suspect, piling another layer of "convenient but wrong" assumptions on top of the current layer. Code in marshal should *never* try to exploit that C longs happen to be bigger than 4 bytes on the current platform. PyMarshal_WriteLongToFile should be changed to raise an exception if passed something that doesn't fit in 4 bytes, and should be declared obsolete. The Python core should be changed now never to call PyMarshal_WriteLongToFile (in answer to Trent's original question, the intent of that code can't be distinguished from what it does, which is to blindly write exactly 4 bytes no matter what). Most of this crap is in support of a bad assumption about mtimes, and, sorry, but it sure looks to me like the .pyc header format is "just plain busted" too. Let's bite the bullet and fix the header -- then all the rest of this will be clearly seen as the broken hackery it really is. From trentm at activestate.com Tue Jun 6 20:57:52 2000 From: trentm at activestate.com (Trent Mick) Date: Tue, 6 Jun 2000 11:57:52 -0700 Subject: [Python-Dev] about patches on SourceForge In-Reply-To: <14652.29682.819341.881773@cj42289-a.reston1.va.home.com> References: <20000605195244.A25437@activestate.com> <14652.29682.819341.881773@cj42289-a.reston1.va.home.com> Message-ID: <20000606115752.D28943@activestate.com> On Mon, Jun 05, 2000 at 11:45:54PM -0400, Fred L. Drake, Jr. wrote: > > Mark Hammond writes: > > This is all too hard until Guido gets back. But personally I believe the > > raw patch should be just the CVS diff output, and the comments should > > reflect all other text, including the release notice while it is still > > necessary. > > Sounds good to me. Let's do it this way until there's a god reason ^^^ > to do it differently. > I think maybe that you meant 'good', but I am not so sure. ;-) Trent -- Trent Mick trentm at activestate.com From gmcm at hypernet.com Tue Jun 6 20:59:49 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Tue, 6 Jun 2000 14:59:49 -0400 Subject: [Python-Dev] req: Software Carpentry / coding standards In-Reply-To: References: <001001bfcfdb$8f64d240$48a2143f@tim> Message-ID: <1251804473-5567942@hypernet.com> Greg Wilson wrote: > > Tim Peters wrote: [Guido's style guide] > Yes, I've seen this. I was wondering > ... whether > there is now a consensus about module structure ... No, there's not. And if you ask me, (which you didn't) there's some very bad precedents getting set in the misguided pursuit of "ease of use". Time to call out the PSU before things get out of hand... - Gordon From gstein at lyra.org Tue Jun 6 21:04:25 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 6 Jun 2000 12:04:25 -0700 (PDT) Subject: [Python-Dev] req: Software Carpentry / coding standards In-Reply-To: Message-ID: On Tue, 6 Jun 2000, Greg Wilson wrote: > > > Tim Peters: > > > http://www.python.org/doc/essays/styleguide.html > > > On Tue, 6 Jun 2000, Christopher Petrilli wrote: > > The only thing that might be added (I haven't looked in a while, but > > didn't see it last time I did), is some naming convention issues. I > > follow pretty standard Smalltalk guidelines: > > > > - No '_', use camelCase for seps > > I know this is become common practice, but I've been told by two different > HCI specialists that studies have shown CamelBackNotation to be harder for > non-native speakers to read than underbar_separated_text, particularly > when acronyms are part of the name. If anyone has a pointer to an > original reference for this, I'd be grateful. Actually, the "camel case" for identifiers is not a standard Python style. I've seen three forms: - no separator or case usage (e.g. getattr()) - mixed case - lower case with underscores Chris' other points: upper-case-initial classes and lower-case-initial methods are *definitely* standard. Globals are a bit different. I don't think it is standard to capitalize them as Chris mentioned (they might look like classes in that case). There isn't much of a standard there. Definitely another point is the use of "_" for the initial character to signify "private -- don't touch" Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Tue Jun 6 21:29:56 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 6 Jun 2000 12:29:56 -0700 (PDT) Subject: [Python-Dev] ANSI-fication (was: RE: [Patches] fix simple 64-bit warnings/errors in signalmodule.c and bufferobject.c) In-Reply-To: <001c01bfcfea$b73a2040$48a2143f@tim> Message-ID: On Tue, 6 Jun 2000, Tim Peters wrote: >... > [on K&R style declarations failing to act as prototypes] > > ... > > Give the man a prize. That was it. We'll just forget that part of the > > patch then and thank you Tim for changing all function declarations > > from K&R to ANSI. :) > > Believe it or not, I do intend to do that, although I expect resistance from > Guido <0.5 wink>. Python's infrastructure is creaking from age, and an > update to ANSI C is l-o-n-g overdue. It appears to me that a very large > part of your "Win64" efforts have amounted to fighting long-obsolete K&R C > assumptions! Euh... I thought Guido was entirely supportive of ANSI-fying the source. Something like changing from K&R functions over to ANSI declarations is "brain-dead" that should not introduce errors. Going through and revamping the protoypes (e.g. PyString_FromStringAndSize to now use size_t) is a bit different, though... I shouldn't think Guido would be upset about prototypes. Cheers, -g -- Greg Stein, http://www.lyra.org/ From effbot at telia.com Tue Jun 6 22:23:19 2000 From: effbot at telia.com (Fredrik Lundh) Date: Tue, 6 Jun 2000 22:23:19 +0200 Subject: [Python-Dev] ANSI-fication (was: RE: [Patches] fix simple 64-bit warnings/errorsin signalmodule.c and bufferobject.c) References: Message-ID: <01b101bfcff5$1000faa0$f2a6b5d4@hagrid> greg wrote: > Euh... I thought Guido was entirely supportive of ANSI-fying the source. note that 1.6 won't build on non-ANSI platforms; lots of new stuff, including the unicode type, the builtin exceptions, and SRE are pure ANSI. (btw, what are all those "register" declarations doing in MAL's version of unicodeobject.c? does any modern compiler even care about that keyword?) From tim_one at email.msn.com Tue Jun 6 23:00:33 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 6 Jun 2000 17:00:33 -0400 Subject: [Python-Dev] RE: ANSI-fication (was: RE: [Patches] fix simple 64-bit warnings/errorsin signalmodule.c and bufferobject.c) In-Reply-To: Message-ID: <001f01bfcffa$41ed2f20$48a2143f@tim> [Greg Stein] > Euh... I thought Guido was entirely supportive of ANSI-fying the source. > Something like changing from K&R functions over to ANSI declarations is > "brain-dead" that should not introduce errors. ... He'll be less & less in favor of it when it hits home how time-consuming and massive the changes will be. They won't be viewed as "a feature" to BeOpen, so BeOpen will give him grief about it too. Etc. I've fought the same stinking infrastructure battles for 20+ years, and don't expect that having a new boss will make any material difference to that <0.7 wink>. Testing is expensive, robustness is expensive, portability is expensive (and C doesn't help! honest to God, it's much worse than Fortran for portability). > Going through and revamping the protoypes (e.g. PyString_FromStringAndSize > to now use size_t) is a bit different, though... > > I shouldn't think Guido would be upset about prototypes. Nobody should get upset about *having* them, it's getting them done that takes away from getting everything else done. That's why every project I've ever seen puts it off year after year. Note that if Guido valued this *highly*, it would already have been done. been-there-done-that-been-there-done-that-been-there-done-that-ly y'rs - tim From jack at oratrix.nl Tue Jun 6 23:14:10 2000 From: jack at oratrix.nl (Jack Jansen) Date: Tue, 06 Jun 2000 23:14:10 +0200 Subject: [Python-Dev] Trying again: [Patches] Patch to import.c Message-ID: <20000606211416.10B6ED8397@oratrix.oratrix.nl> Folks, I posted this message to the patches mailing list last week, but either I missed the reply (we had full disks over the weekend) or nobody replied yet. And I am waiting for these patches, or rather other people who want to play with MacPython and MacOSX are, so I'd really like to know whether I should revise the patches and in what direction or have them checked in.... Hmm, that may all sound a bit pushy, but that isn't the intention. I really just want to know (a) what the status of my patches is and (b) what I can expect in the future.... Jack -------------- next part -------------- An embedded message was scrubbed... From: unknown sender Subject: no subject Date: no date Size: 38 URL: From mal at lemburg.com Wed Jun 7 00:53:02 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 07 Jun 2000 00:53:02 +0200 Subject: [Python-Dev] ANSI-fication (was: RE: [Patches] fix simple 64-bit warnings/errorsin signalmodule.c and bufferobject.c) References: <01b101bfcff5$1000faa0$f2a6b5d4@hagrid> Message-ID: <393D80CE.D6C387AA@lemburg.com> Fredrik Lundh wrote: > > note that 1.6 won't build on non-ANSI platforms; lots of new > stuff, including the unicode type, the builtin exceptions, and > SRE are pure ANSI. > > (btw, what are all those "register" declarations doing in MAL's > version of unicodeobject.c? does any modern compiler even > care about that keyword?) "register" helps compilers in situations where normal optimizations don't give satisfying results, e.g. to aid in keeping often used variables or counters in registers rather than on the stack. It can also help with inling functions and can speed up parameter passing. GCC is one such modern compiler that does care, not sure about MSVC++. IBM's OS/2 compilers did (last time I looked some 5 years ago ;). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From pf at artcom-gmbh.de Wed Jun 7 00:47:41 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Wed, 7 Jun 2000 00:47:41 +0200 (MEST) Subject: Style guide (was Re: [Python-Dev] req: Software Carpentry / coding standards) In-Reply-To: from Greg Wilson at "Jun 6, 2000 1:50:38 pm" Message-ID: Hi, Greg Wilson: > > > Tim Peters: > > > http://www.python.org/doc/essays/styleguide.html > > > On Tue, 6 Jun 2000, Christopher Petrilli wrote: > > The only thing that might be added (I haven't looked in a while, but > > didn't see it last time I did), is some naming convention issues. I > > follow pretty standard Smalltalk guidelines: > > > > - No '_', use camelCase for seps > > I know this is become common practice, but I've been told by two different > HCI specialists that studies have shown CamelBackNotation to be harder for > non-native speakers to read than underbar_separated_text, particularly > when acronyms are part of the name. If anyone has a pointer to an > original reference for this, I'd be grateful. This would be indeed very interesting. But my own experiences support this POV: This naming style issue is similar in Python and one of its early anchestors Modula-2. In 1985 we started our company programming in Modula-2. At that time we decided to code conforming to the original Modula-2 language definition as published by N.Wirth in March, 1980: underscores were not allowed in identifiers! German: '_' verboten! ;-) The software is in use until today and several of our employees still have to use Modula-2 for maintainance. The code base is currently about 1 Mio. LOC. We tried to use english identifiers, although all programmers are native german speakers. We too adopted a style using first char lowercase or uppercase to distinguish identifier classes (modules and procedure names uppercase and all other identifiers lowercase) and later we ran into the problems described above. A few years ago we allowed the use of '_' in identifiers, because the compiler support was available. This has improved the situation somewhat. All our programmers like the possibility to occasionally use '_' in identifiers, especially if idents contain acronyms. Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen) From pf at artcom-gmbh.de Wed Jun 7 11:34:12 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Wed, 7 Jun 2000 11:34:12 +0200 (MEST) Subject: [Python-Dev] Idea: emulating _locale (was Re: [Python-checkins] CVS: python/dist/src/Lib locale.py,1.4,1.5) In-Reply-To: <200006070911.CAA17368@slayer.i.sourceforge.net> from Marc-Andre Lemburg at "Jun 7, 2000 2:11:43 am" Message-ID: Hi, Marc-Andre Lemburg: [...] > Added a new locale name aliasing engine which also supports > locale encodings, a feature which is used by the new default > encoding support in site.py. > > Index: locale.py [...] > + ### C lib locale APIs > + > + from _locale import * Wouldn't it be clever to provide some dummy stubs on those platforms, where the _locale module was not enabled? try: from _locale import * except: def setlocale(.... def localeconv(.... ... Especially the MacOS 1.5.2 release provided by Jack Jansen was compiled without '_locale'. And at least in Python 1.6a2 '_locale' is still disabled per default in 'Modules/Setup.in'. I didn't had a look into the current CVS though, so this may have changed. I think the name aliasing tables might be also useful on those systems lacking locale support in their C-library. Regards, Peter From pf at artcom-gmbh.de Wed Jun 7 11:40:17 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Wed, 7 Jun 2000 11:40:17 +0200 (MEST) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules Setup.in,1.100,1.101 In-Reply-To: <200006070912.CAA17814@slayer.i.sourceforge.net> from Marc-Andre Lemburg at "Jun 7, 2000 2:12:56 am" Message-ID: Uoooppps.... I was just too fast with my previous email about _locale emulation. Marc-Andre Lemburg: > *** Setup.in 2000/05/26 19:02:42 1.100 > --- Setup.in 2000/06/07 09:12:54 1.101 > *************** > *** 141,145 **** > # static Unicode character database > > ! #_locale _localemodule.c # access to ISO C locale support > > > --- 141,145 ---- > # static Unicode character database > > ! _locale _localemodule.c # access to ISO C locale support > Is this likely to work on the Mac with C-libraries coming with Metrowerks CodeWarrior? Jack? Regards, Peter From fredrik at pythonware.com Wed Jun 7 12:24:46 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Wed, 7 Jun 2000 12:24:46 +0200 Subject: [Python-Dev] ANSI-fication (was: RE: [Patches] fix simple 64-bit warnings/errorsin signalmodule.c and bufferobject.c) References: <01b101bfcff5$1000faa0$f2a6b5d4@hagrid> <393D80CE.D6C387AA@lemburg.com> Message-ID: <007a01bfd06a$9d3db140$0500a8c0@secret.pythonware.com> MAL wrote: > > (btw, what are all those "register" declarations doing in MAL's > > version of unicodeobject.c? does any modern compiler even > > care about that keyword?) > > "register" helps compilers in situations where normal > optimizations don't give satisfying results, e.g. to aid > in keeping often used variables or counters in registers > rather than on the stack. It can also help with inling > functions and can speed up parameter passing. Yeah, I know what register is supposed to do. But common knowledge (at least where I live) is that modern optimizers know better than you, and usually ignore "register" altogether if you use higher optimization levels... (and if they don't, using "register" is likely to make things worse on some platforms). In other words, "register" should not be used in portable code. fwiw, a certain Linux kernel hacker seem to agree with me on that one: http://www2.linuxjournal.com/lj-issues/issue17/1138.html ... #define register ... "Gcc, the normal Linux C compiler, understands the register keyword, but the code optimiser is sufficiently good that using register is normally a bad idea." ... (If it's good enough for Alan Cox etc). But never mind. I doubt that removing them would matter on any con- temporary platform, but on the other hand, keeping them in there won't hurt much either. It just makes the source code a little bit more ver- bose than it has to be... From mal at lemburg.com Wed Jun 7 12:25:08 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 07 Jun 2000 12:25:08 +0200 Subject: [Python-Dev] Idea: emulating _locale (was Re: [Python-checkins] CVS: python/dist/src/Lib locale.py,1.4,1.5) References: Message-ID: <393E2304.4BE8CDE0@lemburg.com> Peter Funk wrote: > > Hi, > > Marc-Andre Lemburg: > [...] > > Added a new locale name aliasing engine which also supports > > locale encodings, a feature which is used by the new default > > encoding support in site.py. > > > > Index: locale.py > [...] > > + ### C lib locale APIs > > + > > + from _locale import * > > Wouldn't it be clever to provide some dummy stubs on those platforms, where > the _locale module was not enabled? > > try: > from _locale import * > except: > def setlocale(.... > def localeconv(.... > ... > > Especially the MacOS 1.5.2 release provided by Jack Jansen was > compiled without '_locale'. And at least in Python 1.6a2 '_locale' > is still disabled per default in 'Modules/Setup.in'. I didn't had > a look into the current CVS though, so this may have changed. > > I think the name aliasing tables might be also useful on those > systems lacking locale support in their C-library. setlocale and localeconv are ANSI C and Python requires an ANSI C compiler, so there should be no problem (at least in theory). If there is a problem, adding the missing symbols would be no problem: the APIs could always report locale 'C' and its numeric settings. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Wed Jun 7 12:40:24 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 07 Jun 2000 12:40:24 +0200 Subject: [Python-Dev] ANSI-fication (was: RE: [Patches] fix simple 64-bit warnings/errorsin signalmodule.c and bufferobject.c) References: <01b101bfcff5$1000faa0$f2a6b5d4@hagrid> <393D80CE.D6C387AA@lemburg.com> <007a01bfd06a$9d3db140$0500a8c0@secret.pythonware.com> Message-ID: <393E2698.D2DFFC91@lemburg.com> Fredrik Lundh wrote: > > MAL wrote: > > > (btw, what are all those "register" declarations doing in MAL's > > > version of unicodeobject.c? does any modern compiler even > > > care about that keyword?) > > > > "register" helps compilers in situations where normal > > optimizations don't give satisfying results, e.g. to aid > > in keeping often used variables or counters in registers > > rather than on the stack. It can also help with inling > > functions and can speed up parameter passing. > > Yeah, I know what register is supposed to do. I know you know, but I find adding some explanations for others which might not know is good practice. > But common knowledge (at least where I live) is that modern optimizers > know better than you, and usually ignore "register" altogether if you use > higher optimization levels... (and if they don't, using "register" is likely to > make things worse on some platforms). In other words, "register" should > not be used in portable code. > > fwiw, a certain Linux kernel hacker seem to agree with me on that one: > > http://www2.linuxjournal.com/lj-issues/issue17/1138.html > ... > #define register > ... > "Gcc, the normal Linux C compiler, understands the register keyword, > but the code optimiser is sufficiently good that using register is normally > a bad idea." > ... Well, make that "normally not needed": gcc sometimes doesn't inline functions because it thinks that the function needs parameters to be on the stack. The register keyword can do wonders here. Adding "register" is like adding salt & pepper: things usually taste better than before ;-). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gward at mems-exchange.org Wed Jun 7 15:19:06 2000 From: gward at mems-exchange.org (Greg Ward) Date: Wed, 7 Jun 2000 09:19:06 -0400 Subject: [Python-Dev] Re: [Patches] Translating doc strings In-Reply-To: <200006021503.RAA26314@pandora>; from loewis@informatik.hu-berlin.de on Fri, Jun 02, 2000 at 05:03:50PM +0200 References: <200006020701.JAA28620@pandora> <39376C19.53A01A27@lemburg.com> <200006021233.OAA16962@pandora> <14647.47270.330318.807347@anthem.python.org> <200006021503.RAA26314@pandora> Message-ID: <20000607091906.A5559@ludwig.cnri.reston.va.us> On 02 June 2000, Martin von Loewis said: > Having the full set of distutils doc strings in the > catalog is already a substantial amount of text to translate... Most of those docstrings in the Distutils are not really for public consumption; they're there so that Distutils developers can remember (or learn) what the heck such-and-such a method is supposed to do. Also, they're a moving target; things are still changing in the Distutils, and trying to keep on top of translating internal docstrings would be a hopeless and frustrating task. Greg From jack at oratrix.nl Wed Jun 7 15:51:54 2000 From: jack at oratrix.nl (Jack Jansen) Date: Wed, 07 Jun 2000 15:51:54 +0200 Subject: [Python-Dev] Idea: emulating _locale (was Re: [Python-checkins] CVS: python/dist/src/Lib locale.py,1.4,1.5) In-Reply-To: Message by "M.-A. Lemburg" , Wed, 07 Jun 2000 12:25:08 +0200 , <393E2304.4BE8CDE0@lemburg.com> Message-ID: <20000607135154.8DCFD370CF2@snelboot.oratrix.nl> The locale stuff in the CodeWarrior libraries is basically a dummy placeholder, that's why I didn't export it to Python. But it appears that it's better to export it anyway, if I understand the dsicussion correctly, so I'll do so from the next release. -- 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 gward at mems-exchange.org Wed Jun 7 15:56:38 2000 From: gward at mems-exchange.org (Greg Ward) Date: Wed, 7 Jun 2000 09:56:38 -0400 Subject: [Python-Dev] Revised 1.6 jobs list In-Reply-To: ; from jeremy@beopen.com on Sat, Jun 03, 2000 at 12:11:48PM -0400 References: <3938D60E.391AAF31@lemburg.com> Message-ID: <20000607095638.B5559@ludwig.cnri.reston.va.us> On 03 June 2000, Jeremy Hylton said: > SourceForge makes it a little more inconvenient to check which > patches have been applied. Under the old CVS arrangement, it was > a local operation to do a cvs log or diff. Now it's a slow network > operation that requires authentication. (I really want a local > mirror of the entire CVS repository!) I have come up with a partial solution to the inconvenience of accessing SourceForge, specifically the need for constant authentication. I generated a new, unencrypted SSH key and put it in ~/.ssh/alt-identity. Then I wrote a little C program (source attached) that does the equivalent of os.exec ("ssh", "-i", "$HOME/.ssh/alt-identity") (in an imaginary dialect of Python that interpolates environment variables ;-). Then I set CVS_RSH to this little C program (~/bin/alt_ssh). (It could have easily been a script, but I wanted to avoid the overhead of launching an interpreter for every authentication.) So now CVS operations against SF are just s..l..o..w, and I'm not forever typing in my SSH passphrase. Of course, anyone with root access at CNRI could now steal my unencrypted key -- which I *only* use for CVS access to SF -- and use it to impersonate me for checkins. But I think the only person who knows how to do that already has Python checkin privilege. ;-) But yeah, remote CVS still bites the big one. Very painful over a 28.8k modem line. (It sucks being a cheap bastard!) Greg -- Greg Ward - software developer gward at mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From gward at mems-exchange.org Wed Jun 7 15:57:41 2000 From: gward at mems-exchange.org (Greg Ward) Date: Wed, 7 Jun 2000 09:57:41 -0400 Subject: [Python-Dev] Revised 1.6 jobs list In-Reply-To: <20000607095638.B5559@ludwig.cnri.reston.va.us>; from gward@ludwig.cnri.reston.va.us on Wed, Jun 07, 2000 at 09:56:38AM -0400 References: <3938D60E.391AAF31@lemburg.com> <20000607095638.B5559@ludwig.cnri.reston.va.us> Message-ID: <20000607095741.C5559@ludwig.cnri.reston.va.us> On 07 June 2000, I said: > Then I wrote a little C program (source attached) that does the > equivalent of Oops, forgot the attachment. Here 'tis. -------------- next part -------------- /* * alt_ssh * * exec ssh with an alternate "identity" (key pair) -- needed since * the CVS_RSH variable can't include options for the rsh-like * command. * * GPW 2000/05/28 * * $Id: alt_ssh.c,v 1.3 2000/06/07 13:54:19 gward Exp $ */ #include #include #include #include #include int main (int argc, char * argv[]) { char * keyfile = "/.ssh/alt-identity"; char * keyfile_full; char * home; int num_args; char ** ssh_args; int i; home = getenv("HOME"); keyfile_full = (char *) malloc (strlen(home) + strlen(keyfile) + 1); assert (home != NULL && keyfile_full != NULL); strcpy(keyfile_full, home); strcat(keyfile_full, keyfile); num_args = argc + 2; /* -i, identity-file */ ssh_args = (char **) calloc (num_args+1, sizeof(char *)); ssh_args[0] = "ssh"; ssh_args[1] = "-i"; ssh_args[2] = keyfile_full; for (i = 3; i < num_args; i++) ssh_args[i] = argv[i-2]; ssh_args[i] = NULL; for (i = 0; i < num_args; i++) { printf(ssh_args[i]); if (i < num_args) printf(" "); } printf("\n"); execvp("ssh", ssh_args); perror("couldn't exec ssh"); exit(1); } From jeremy at beopen.com Wed Jun 7 16:04:12 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Wed, 7 Jun 2000 10:04:12 -0400 (EDT) Subject: [Python-Dev] Fwd: Hmmmm... (Jim Anderson) Message-ID: <14654.22108.959934.552869@localhost.localdomain> You guys haven't seen more Perl traffic on this list have you? :-) Jeremy -------------- next part -------------- An embedded message was scrubbed... From: "Jim Anderson" Subject: Hmmmm... Date: Tue, 6 Jun 2000 12:09:53 -0400 (EDT) Size: 490 URL: From gward at mems-exchange.org Wed Jun 7 16:11:46 2000 From: gward at mems-exchange.org (Greg Ward) Date: Wed, 7 Jun 2000 10:11:46 -0400 Subject: [Python-Dev] release forms? (was: [Patches] New sys method to return total reference count in debug builds.) In-Reply-To: ; from gstein@lyra.org on Sun, Jun 04, 2000 at 04:30:08PM -0700 References: Message-ID: <20000607101146.D5559@ludwig.cnri.reston.va.us> On 04 June 2000, Greg Stein said: > p.s. IMO, I'd like to see Guido own the Copyright for all current and > future Python development Second that. Given that I work for CNRI and was forced (at gunpoint, as I recall) to sign an incredibly draconian IP agreement -- along the lines of "everything you have ever created, or will ever consider creating, in any medium whatsoever, no matter where you did it or who pays for it, is the property of CNRI for all time" -- I'd have a hard time getting away with slapping "Copyright (c) 1999-2000 Gregory P. Ward" all over the Distutils code. And given that fair chunks of that code have been contributed by other people, I couldn't even ethically do that. So, given that I probably can't claim ownership in the code, and that CNRI has absolutely no moral right to it (although probably some legal right), I'd prefer to sign it away to Guido. Or optionally, to some legal fiction that represents the Python community; preferably *not* the Python Consortium, as long as CNRI is in any way connected. Death to the lawyers! Greg -- Greg Ward - software developer gward at mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From moshez at math.huji.ac.il Wed Jun 7 16:33:10 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 7 Jun 2000 17:33:10 +0300 (IDT) Subject: [Python-Dev] release forms? (was: [Patches] New sys method to return total reference count in debug builds.) In-Reply-To: <20000607101146.D5559@ludwig.cnri.reston.va.us> Message-ID: On Wed, 7 Jun 2000, Greg Ward wrote: > CNRI has absolutely no moral right to it (although probably some legal > right), I'd prefer to sign it away to Guido. Or optionally, to some > legal fiction that represents the Python community; preferably *not* the > Python Consortium, as long as CNRI is in any way connected. Who's in charge of the PSA? Or should we form *another* non-profit, and sign it over to it? (Personally, I couldn't care less who I transfer copyright over my Python contributions to -- I'd put it in the public domain if that's what it took) -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com From pf at artcom-gmbh.de Wed Jun 7 16:44:30 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Wed, 7 Jun 2000 16:44:30 +0200 (MEST) Subject: [Python-Dev] Revised 1.6 jobs list In-Reply-To: <20000607095638.B5559@ludwig.cnri.reston.va.us> from Greg Ward at "Jun 7, 2000 9:56:38 am" Message-ID: Hi, Greg Ward: > But yeah, remote CVS still bites the big one. Very painful over a 28.8k > modem line. (It sucks being a cheap bastard!) Certainly you know about 'rsync'? Would this help here? Let me quote a small section from the 'rsync' man page: """ To synchronize my samba source trees I use the following Makefile targets: get: rsync -avuzb --exclude ?*~? samba:samba/ . put: rsync -Cavuzb . samba:samba/ sync: get put this allows me to sync with a CVS directory at the other end of the link. I then do cvs operations on the remote machine, which saves a lot of time as the remote cvs pro? tocol isn?t very efficient. """ I can't access CVS because of our restrictive HTTP/UUCP only firewall, but in our company we use 'rsync' a lot. Regards, Peter From bwarsaw at python.org Wed Jun 7 17:06:42 2000 From: bwarsaw at python.org (Barry A. Warsaw) Date: Wed, 7 Jun 2000 11:06:42 -0400 (EDT) Subject: [Python-Dev] Revised 1.6 jobs list References: <3938D60E.391AAF31@lemburg.com> <20000607095638.B5559@ludwig.cnri.reston.va.us> Message-ID: <14654.25858.564089.574043@anthem.python.org> >>>>> "GW" == Greg Ward writes: GW> I have come up with a partial solution to the inconvenience of GW> accessing SourceForge, specifically the need for constant GW> authentication. Greg, are you aware of ssh-agent? Same convenience, same possible exploits, but at least they've done the hard work for ya. :) I usually just run XEmacs under ssh-agent. First thing you do is fire up a shell buffer, run ssh-add to authenticate once, and from there on, all your ssh interactions (not just with SF) yank the private key out of the ssh-agent process and never bother you with a passphrase prompt. -Barry From bwarsaw at python.org Wed Jun 7 17:22:20 2000 From: bwarsaw at python.org (Barry A. Warsaw) Date: Wed, 7 Jun 2000 11:22:20 -0400 (EDT) Subject: [Python-Dev] release forms? (was: [Patches] New sys method to return total reference count in debug builds.) References: <20000607101146.D5559@ludwig.cnri.reston.va.us> Message-ID: <14654.26796.936980.875783@anthem.python.org> >>>>> "MZ" == Moshe Zadka writes: MZ> Who's in charge of the PSA? Or should we form *another* MZ> non-profit, and sign it over to it? (Personally, I couldn't MZ> care less who I transfer copyright over my Python MZ> contributions to -- I'd put it in the public domain if that's MZ> what it took) Please remember that the copyright holder can release the code under whatever license they want, even multiple different licenses. Copyright != license. I'm not sure what the right thing to do here is. On the one hand, Bob Kahn always said nobody would use Python if its heritage (i.e. copyright ownership) were not nailed down like Java. On the other hand, there's a lot of nobodies out there right now :). For GNU projects, the FSF wants to own all the copyrights to the code. They actually want you to legally assign the copyright to them. Their explanation for this onerous requirement is that if they were not the copyright holder, they would not have the legal standing to defend GPL violations, or would have to coordinate with a ton of developers, making such legal defenses practically impossible. Python is in a different situation, IMO, because it has a /less/ restrictive license than the GPL, so there's less to get all huffy about in court. If someone builds a binary-only proprietary blend of Python and starts selling it without source code, well, there's no license violation there, so what's to defend? The argument has been made that without clear legal title, someone could claim that some of the donated code in Python violated a copyright or patent and try to stop 3rd parties from using Python. Who knows what the actual legal possibility of that happening are, but I don't see how 1) we could take any real defense against this or 2) it affects Python any differently than any other large multi-contributor open source system. -Barry From andy at robanal.demon.co.uk Wed Jun 7 22:48:48 2000 From: andy at robanal.demon.co.uk (Andy Robinson) Date: Wed, 07 Jun 2000 20:48:48 GMT Subject: [Python-Dev] Package ambiguities Message-ID: <393eb52b.47053339@post.demon.co.uk> We hit some very weird behaviour recently while setting up a package hierarchy. Robin Becker managed to distil this into a simple example. Can anyone shed any light on what is happening below? Is Python behaving as it should? Create a package A, empty __init__.py, with modules as follows: --------parent.py---------- class Parent: pass --------child.py------------ from parent import Parent class Child(Parent): pass ---------test.py-------- from parent import * class Examiner: def examine(self, arg): print 'examining argument:' print 'class of arg =', arg.__class__ print 'bases of arg =', arg.__class__.__bases__ print 'arg =', arg if isinstance(arg, Parent): print "arg is an instance of Parent" else: print "arg IS NOT an instance of Parent" print if __name__=='__main__': from traceback import print_exc import sys def run0(): from A.child import Child e = Examiner() e.examine(Child()) def run1(): from A.child import Child from A.test import Examiner e = Examiner() e.examine(Child()) run0() run1() Running this script produces the following output: C:\users\andy\A>test.py examining argument: class of arg = A.child.Child bases of arg = (,) arg = arg IS NOT an instance of Parent examining argument: class of arg = A.child.Child bases of arg = (,) arg = arg is an instance of Parent Many thanks, Andy Robinson From pingster at ilm.com Wed Jun 7 23:05:26 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Wed, 7 Jun 2000 14:05:26 -0700 (PDT) Subject: [Python-Dev] Package ambiguities In-Reply-To: <393eb52b.47053339@post.demon.co.uk> Message-ID: On Wed, 7 Jun 2000, Andy Robinson wrote: > We hit some very weird behaviour recently while setting up a package > hierarchy. Robin Becker managed to distil this into a simple example. > Can anyone shed any light on what is happening below? Is Python > behaving as it should? It looks to me like you have two "parent" modules. When you run "test.py" directly from the command line, the first "from parent import *" imports parent.py as module "parent". But subsequently parent.py is imported again as module "A.parent". Similarly, you have two "Examiner" classes. In run0() you get Examiner from __main__, which contains the Parent class from module "parent". In run1() you get Examiner from A.test, which contains the Parent class imported from module "A.parent". If you insert print 'in module', __name__, 'parent is', repr(Parent) at the beginning of the examine() method, it should make things clear. The solution is to avoid directly running scripts that are inside packages; the confusion is produced by the fact that you're running "test.py" from within the A/ directory. -- ?!ng From jeremy at beopen.com Wed Jun 7 23:25:53 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Wed, 7 Jun 2000 17:25:53 -0400 (EDT) Subject: [Python-Dev] revamped Python web site Message-ID: <14654.48609.710990.321688@localhost.localdomain> Say a startup company decided to put some resources behind the Python Web site -- a full-time Web master, some content developers, etc. What would you have them do? What could be done to open up the site to the community and make it more responsive to developers and users? What's your wish list for content, services, etc.? If you've got any ideas, please get back to me soon. Jeremy From esr at thyrsus.com Wed Jun 7 23:41:48 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 7 Jun 2000 17:41:48 -0400 Subject: [Python-Dev] revamped Python web site In-Reply-To: <14654.48609.710990.321688@localhost.localdomain>; from jeremy@beopen.com on Wed, Jun 07, 2000 at 05:25:53PM -0400 References: <14654.48609.710990.321688@localhost.localdomain> Message-ID: <20000607174148.A6801@thyrsus.com> Jeremy Hylton : > Say a startup company decided to put some resources behind the Python > Web site -- a full-time Web master, some content developers, etc. > What would you have them do? What could be done to open up the site > to the community and make it more responsive to developers and users? > What's your wish list for content, services, etc.? I think it's pretty good as is -- lots of content, pretty well organized. My top wishlist item is "Burn all your GIFs". -- Eric S. Raymond The right of self-defense is the first law of nature: in most governments it has been the study of rulers to confine this right within the narrowest limits possible. Wherever standing armies are kept up, and when the right of the people to keep and bear arms is, under any color or pretext whatsoever, prohibited, liberty, if not already annihilated, is on the brink of destruction." -- Henry St. George Tucker (in Blackstone's Commentaries) From jack at oratrix.nl Wed Jun 7 23:47:01 2000 From: jack at oratrix.nl (Jack Jansen) Date: Wed, 07 Jun 2000 23:47:01 +0200 Subject: [Python-Dev] hey, who broke the array module? In-Reply-To: Message by Guido van Rossum , Thu, 18 May 2000 15:05:45 -0700 , <200005182205.PAA12830@cj20424-a.reston1.va.home.com> Message-ID: <20000607214706.65CB2D8397@oratrix.oratrix.nl> Recently, Guido van Rossum said: > > On Thu, May 18, 2000 at 12:01:16PM +0200, Jack Jansen wrote: > > > > I broke it with my patches to test overflow for some of the PyArg_Parse > *() > > > > formatting characters. The upshot of testing for overflow is that now t > hose > > > > formatting characters ('b', 'h', 'i', 'l') enforce signed-ness or > > > > unsigned-ness as appropriate (you have to know if the value is signed o > r > > > > unsigned to know what limits to check against for overflow). Two > > > > possibilities presented themselves: > > > > > > I think this is a _very_ bad idea. I have a few thousand (literally) rout > ines > > > calling to Macintosh system calls that use "h" for 16 bit flag-word value > s, > > > and the constants are all of the form > > > > > > kDoSomething = 0x0001 > > > kDoSomethingElse = 0x0002 > > > ... > > > kDoSomethingEvenMoreBrilliant = 0x8000 > > > > > > I'm pretty sure other operating systems have lots of calls with similar > > > problems. I would strongly suggest using a new format char if you want > > > overflow-tested integers. > > > > Sigh. What do you think Guido? This is your call. > > > > 1. go back to no bounds testing > > 2. bounds check for [SHRT_MIN, USHRT_MAX] etc (this would allow signed and > > unsigned values but is sort of false security for bounds checking) > > 3. keep it the way it is: 'b' is unsigned and the rest are signed > > 4. add new format characters or a modifying character for signed and unsign > ed > > versions of these. > > Sigh indeed. Ideally, we'd introduce H for unsigned and then lock > Jack in a room with his Macintosh computer for 48 hours to fix all his > code... Hmm, hmm. As stated before I'm not too fond of this as it is a gratuitous change that breaks lots of things (not only in Mac modules: the array module was what started this discussion, test_cPickle and test_pkg crash, socketmodule, os.stat() and I assume all code that uses structmodule will also have to be looked at, and quite possibly there's a lot more) and for which I don't really see all that much benefit. As a datapoint: a quick search for 8-digit hex numbers starting with digit 8-F and not suffixed with an L throughout the Python files in the distribution found a stunning 464 matches. Add another 1147 4-digit hex numbers with the sign bit on and there are an awful lot of candidates for breaking... -- 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 gmcm at hypernet.com Wed Jun 7 23:59:20 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Wed, 7 Jun 2000 17:59:20 -0400 Subject: [Python-Dev] Package ambiguities In-Reply-To: References: <393eb52b.47053339@post.demon.co.uk> Message-ID: <1251707300-11412775@hypernet.com> Ka-Ping wrote: > On Wed, 7 Jun 2000, Andy Robinson wrote: > > We hit some very weird behaviour recently while setting up a > > package hierarchy. Robin Becker managed to distil this into a > > simple example. Can anyone shed any light on what is happening > > below? Is Python behaving as it should? [snip entirely correct analysis] > The solution is to avoid directly running scripts that are > inside packages; the confusion is produced by the fact that > you're running "test.py" from within the A/ directory. I disagree with the moral. If test.py uses "import A.parent" and changes references accordingly, it works. So my version of the moral is that import * is EVIL. Not only that, but relative imports are EVIL. This is what I meant when I said (in reply to Greg Wilson's inquiry about package structures) that there are some very bad precedents getting set. Doing this junk (usually in __init__.py) not only makes your package fragile, it also makes the package structure mysterious to the user (who's a developer - making things mysterious to him/her is just making both your lives harder!). If you want to make it friendly to lazy coders, then something like: import A.parent Parent = A.parent.Parent also works, (leaving references as Parent). I'm not terribly fond of this, either, but at least the coder has a reasonable hope of tracking down what "Parent" actually is. I'm not necessarily yelling at you, Andy. It seems that most package developers are going down this slope. It stinks. - Gordon From jeremy at beopen.com Thu Jun 8 00:06:29 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Wed, 7 Jun 2000 18:06:29 -0400 (EDT) Subject: [Python-Dev] Package ambiguities In-Reply-To: <1251707300-11412775@hypernet.com> References: <393eb52b.47053339@post.demon.co.uk> <1251707300-11412775@hypernet.com> Message-ID: <14654.51045.18807.74677@localhost.localdomain> Gordon's comments are on the money. An import in a module inside a package should be fully qualified. I'd put that in the style guide if it were up to me (and, of course, it's not). Jeremy From bwarsaw at python.org Thu Jun 8 00:38:02 2000 From: bwarsaw at python.org (Barry A. Warsaw) Date: Wed, 7 Jun 2000 18:38:02 -0400 (EDT) Subject: [Python-Dev] Package ambiguities References: <393eb52b.47053339@post.demon.co.uk> <1251707300-11412775@hypernet.com> <14654.51045.18807.74677@localhost.localdomain> Message-ID: <14654.52938.139406.371556@anthem.concentric.net> >>>>> "JH" == Jeremy Hylton writes: JH> Gordon's comments are on the money. An import in a module JH> inside a package should be fully qualified. I'd put that in JH> the style guide if it were up to me (and, of course, it's JH> not). I concur on both points. BTW, one of the Things I'd Like To Do, is update and flesh out the style guide. It's incomplete in places and out of date in others. If someone else has the gumption to lead this effort, I'd be happy to send my comments instead. -Barry From pingster at ilm.com Thu Jun 8 00:39:28 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Wed, 7 Jun 2000 15:39:28 -0700 (PDT) Subject: [Python-Dev] Package ambiguities In-Reply-To: <1251707300-11412775@hypernet.com> Message-ID: On Wed, 7 Jun 2000, Gordon McMillan wrote: > I disagree with the moral. > > If test.py uses "import A.parent" and changes references > accordingly, it works. Correct. Well, maybe there are two things going on here. I agree that import * isn't usually a very good idea. However, notice that the problem occurs even if the first line of test.py is "import parent" (no star). When you talk about changing references accordingly, the real issue is referencing "A.parent" rather than "parent". In fact, if you change the first line to "from A.parent import *" (not that i am advocating this!) -- it works. In short: from parent import * ... Parent doesn't work import parent ... parent.Parent doesn't work from A.parent import * ... Parent works import A.parent ... A.parent.Parent works The first two cases -- attempting to import "parent" -- are only made possible by the fact that we're executing test.py from within the A/ directory, and hence the confusion. This problem is an "advanced" version of a simpler issue which a friend of mine discovered and complained about recently to me: the __main__ vs. module-name conflict. Allow me to paraphrase his example. Exhibit A: ---- spam.py ---- import eggs def go(): print "was", eggs.a eggs.a = 3 print "now", eggs.a ---- eggs.py ---- import spam a = 1 def go(): spam.go() print "finally", a if __name__ == "__main__": go() --- watch what happens ---- % python eggs.py was 1 now 3 finally 1 % python >>> import eggs >>> eggs.go() was 1 now 3 finally 3 Exhibit B: ---- one.py ---- import two def go(): pass ---- two.py ---- import one one.go() ---- watch what happens ---- % python one.py % python two.py Traceback (innermost last): File "two.py", line 1, in ? import one File "./one.py", line 1, in ? import two File "./two.py", line 2, in ? one.go() AttributeError: go Exit 1 % python >>> import one Traceback (innermost last): File "", line 1, in ? File "./one.py", line 1, in ? import two File "./two.py", line 2, in ? one.go() AttributeError: go >>> import two >>> The facts that eggs.a appears to behave differently in Exhibit A, and that one.py can be run but two.py cannot, yet "two" can be imported and "one" cannot, in Exhibit B, both result from the duplication namespaces in __main__ and in a module. Normally, this only affects the main file that you are running, the one with the __main__ namespace. However, attempting to run scripts in package directories allows this problem to propagate further into the duplication of other modules: __main__ imports parent which imports child A.test imports A.parent which imports A.child ...and that can cause duplicate classes all over the place, which is what happened to Andy. My friend was quite irked by the existence of __main__, citing it as the culprit for this duplication. But naturally Python can't always know the name of the script being run -- in the case of a file ending in .py, perhaps, it's easy, but the script might come from a pipe, for example. So eliminating __main__ doesn't seem like a feasible response. Depending how "real" you consider this problem, leaving things as they are and instructing people in the discipline of keeping modules and scripts separated may be the best response. I bet this crops up all the time in those "testing" sections of modules that use the 'if __name__ == "__main__"' convention, though... -- ?!ng "Computers are useless. They can only give you answers." -- Pablo Picasso From petrilli at amber.org Thu Jun 8 00:51:50 2000 From: petrilli at amber.org (Christopher Petrilli) Date: Wed, 7 Jun 2000 18:51:50 -0400 Subject: [Python-Dev] Package ambiguities In-Reply-To: <14654.52938.139406.371556@anthem.concentric.net>; from bwarsaw@python.org on Wed, Jun 07, 2000 at 06:38:02PM -0400 References: <393eb52b.47053339@post.demon.co.uk> <1251707300-11412775@hypernet.com> <14654.51045.18807.74677@localhost.localdomain> <14654.52938.139406.371556@anthem.concentric.net> Message-ID: <20000607185150.A29156@trump.amber.org> Barry A. Warsaw [bwarsaw at python.org] wrote: > > >>>>> "JH" == Jeremy Hylton writes: > > JH> Gordon's comments are on the money. An import in a module > JH> inside a package should be fully qualified. I'd put that in > JH> the style guide if it were up to me (and, of course, it's > JH> not). > > I concur on both points. BTW, one of the Things I'd Like To Do, is > update and flesh out the style guide. It's incomplete in places and > out of date in others. If someone else has the gumption to lead this > effort, I'd be happy to send my comments instead. Something we futzed with at Digital Creations was "commentable" or discussable web pages. This would be a great use for this. If you took and made each basic topic/issue a page, and let people "discuss" them. A nice threaded discussion could add a lot of insight. This is versus a wiki where it's more "free for all", which isn't really appropraiate for a "guide". Chris -- | Christopher Petrilli | petrilli at amber.org From pingster at ilm.com Thu Jun 8 00:48:29 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Wed, 7 Jun 2000 15:48:29 -0700 (PDT) Subject: [Python-Dev] Package ambiguities In-Reply-To: <20000607185150.A29156@trump.amber.org> Message-ID: On Wed, 7 Jun 2000, Christopher Petrilli wrote: > Something we futzed with at Digital Creations was "commentable" or > discussable web pages. This would be a great use for this. If you > took and made each basic topic/issue a page, and let people "discuss" > them. A nice threaded discussion could add a lot of insight. This > is versus a wiki where it's more "free for all", which isn't really > appropraiate for a "guide". Well, y'all could go nuts marking up the style guide with Crit. http://crit.org/ ...or marking up anything else on the whole Web, for that matter. :) -- ?!ng "To be human is to continually change. Your desire to remain what you are is what ultimately limits you." -- The Puppet Master, Ghost in the Shell From jeremy at beopen.com Thu Jun 8 01:00:36 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Wed, 7 Jun 2000 19:00:36 -0400 (EDT) Subject: [Python-Dev] Package ambiguities In-Reply-To: References: <1251707300-11412775@hypernet.com> Message-ID: <14654.54292.711289.254224@localhost.localdomain> >In fact, if you change the first line to "from A.parent import *" >(not that i am advocating this!) -- it works. In short: > > from parent import * ... Parent doesn't work > import parent ... parent.Parent doesn't work > > from A.parent import * ... Parent works > import A.parent ... A.parent.Parent works One other possibility that ought to work (?) from A import parent Jeremy From gmcm at hypernet.com Thu Jun 8 01:47:47 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Wed, 7 Jun 2000 19:47:47 -0400 Subject: [Python-Dev] Package ambiguities In-Reply-To: References: <1251707300-11412775@hypernet.com> Message-ID: <1251700795-11803988@hypernet.com> Ka-Ping wrote: > ... In short: > > from parent import * ... Parent doesn't work > import parent ... parent.Parent doesn't work > > from A.parent import * ... Parent works > import A.parent ... A.parent.Parent works Right. That's why I cast relative imports as evil. > This problem is an "advanced" version of a simpler issue > which a friend of mine discovered and complained about > recently to me: the __main__ vs. module-name conflict. This comes up a whole lot. In those periods where I have the time, energy and patience to monitor c.l.py closely, I've seen this come up 4 or 5 times in one week. Almost always in conjunction with import *. I can live with explaining how __main__ is special. That's one of those "you only have to explain it once" problems. But the import * problems (name hiding, the fact that assignments aren't seen) and relative imports are things that come up over and over again, and trip up even experienced people (and them more than once). - Gordon From gstein at lyra.org Thu Jun 8 04:30:14 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 7 Jun 2000 19:30:14 -0700 Subject: [Python-Dev] Idea: emulating _locale In-Reply-To: <393E2304.4BE8CDE0@lemburg.com>; from mal@lemburg.com on Wed, Jun 07, 2000 at 12:25:08PM +0200 References: <393E2304.4BE8CDE0@lemburg.com> Message-ID: <20000607193014.P3348@lyra.org> On Wed, Jun 07, 2000 at 12:25:08PM +0200, M.-A. Lemburg wrote: >... > Peter Funk wrote: >... > > > + ### C lib locale APIs > > > + > > > + from _locale import * > > > > Wouldn't it be clever to provide some dummy stubs on those platforms, where > > the _locale module was not enabled? > > > > try: > > from _locale import * > > except: > > def setlocale(.... > > def localeconv(.... > > ... > > > > Especially the MacOS 1.5.2 release provided by Jack Jansen was > > compiled without '_locale'. And at least in Python 1.6a2 '_locale' > > is still disabled per default in 'Modules/Setup.in'. I didn't had > > a look into the current CVS though, so this may have changed. > > > > I think the name aliasing tables might be also useful on those > > systems lacking locale support in their C-library. > > setlocale and localeconv are ANSI C and Python requires an ANSI C > compiler, so there should be no problem (at least in theory). > > If there is a problem, adding the missing symbols would > be no problem: the APIs could always report locale 'C' > and its numeric settings. An ANSI C compiler and the ANSI C library are very different. Just because Python requires an ANSI compiler (or close to it), does NOT mean that we can or should depend upon particular elements in the library. IMO, we should follow Peter's advice and have stubs for the platforms where _locale is not built. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Thu Jun 8 04:35:37 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 7 Jun 2000 19:35:37 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Objects unicodeobject.c,2.21,2.22 In-Reply-To: <200006070913.CAA18060@slayer.i.sourceforge.net>; from lemburg@slayer.i.sourceforge.net on Wed, Jun 07, 2000 at 02:13:24AM -0700 References: <200006070913.CAA18060@slayer.i.sourceforge.net> Message-ID: <20000607193537.Q3348@lyra.org> On Wed, Jun 07, 2000 at 02:13:24AM -0700, Marc-Andre Lemburg wrote: > Update of /cvsroot/python/python/dist/src/Objects > In directory slayer.i.sourceforge.net:/tmp/cvs-serv17917/Objects > > Modified Files: > unicodeobject.c > Log Message: > Marc-Andre Lemburg : > Change the default encoding to 'ascii' (it was previously > defined as UTF-8). > > Note: The implementation still uses UTF-8 to implement > the buffer protocol, so C APIs will still see UTF-8. This > is on purpose: rather than fixing the Unicode implementation, > the C APIs should be made Unicode aware. I'm a little confused on where this gets applied. Is this when somebody says "str(unicode_ob)", they get back ASCII rather than UTF-8? Or is this when somebody says "unicode(str)" and we expect to be ASCII? Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Thu Jun 8 05:06:24 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 7 Jun 2000 20:06:24 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils/command sdist.py,1.25,1.26 In-Reply-To: <200006080008.RAA15980@slayer.i.sourceforge.net>; from gward@slayer.i.sourceforge.net on Wed, Jun 07, 2000 at 05:08:17PM -0700 References: <200006080008.RAA15980@slayer.i.sourceforge.net> Message-ID: <20000607200624.R3348@lyra.org> On Wed, Jun 07, 2000 at 05:08:17PM -0700, Greg Ward wrote: > Update of /cvsroot/python/distutils/distutils/command > In directory slayer.i.sourceforge.net:/tmp/cvs-serv15881 > > Modified Files: > sdist.py > Log Message: > Made all debug output go through the 'debug_print()' method instead of > directly printing to stdout. This was a bit more work than it sounds like > it should have been: > * turned 'select_pattern()' and 'exclude_pattern()' from functions into > methods, so they can refer to 'self' to access the method You wouldn't have to do this if you make debug_print() a function. There is nothing in debug_print() that requires "self", so its existence as a method is suspect in the first place. Considering the fallout changes, I'd say move debug_print() to a plain function (in "utils"). Unless you were planning on more stuff in there; if so, then a comment in debug_print would be nice. >... > *************** > *** 297,301 **** > if (cur_dir == dir and > (pattern_re is None or pattern_re.match (cur_base))): > ! print "removing %s" % self.files[i] > del self.files[i] > > --- 298,302 ---- > if (cur_dir == dir and > (pattern_re is None or pattern_re.match (cur_base))): > ! self.debug_print("removing %s" % self.files[i]) > del self.files[i] Gah... "pattern_re.match (cur_base)" ... You do realize that God intended there to be no spaces between a function name and the opening paren? Heretic! :-) Really -- I have noticed this throughout a lot of the distutils code. That space in there is really awful. It reduces the "binding" of the name to the paren, which changes the meaning during a quick read. Put another way: when you skim code, NAME( is a function call and NAME ( is something else. A space after a name usually indicates the name is participating in an expression, rather than being used as a function name. Then, you hit the paren and go "what the heck? oh. a function call." Please... can they be removed? Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Thu Jun 8 06:05:55 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 7 Jun 2000 21:05:55 -0700 Subject: [Python-Dev] release forms? (was: [Patches] New sys method to return total reference count in debug builds.) In-Reply-To: ; from moshez@math.huji.ac.il on Wed, Jun 07, 2000 at 05:33:10PM +0300 References: <20000607101146.D5559@ludwig.cnri.reston.va.us> Message-ID: <20000607210555.X3348@lyra.org> On Wed, Jun 07, 2000 at 05:33:10PM +0300, Moshe Zadka wrote: > On Wed, 7 Jun 2000, Greg Ward wrote: > > > CNRI has absolutely no moral right to it (although probably some legal > > right), I'd prefer to sign it away to Guido. Or optionally, to some > > legal fiction that represents the Python community; preferably *not* the > > Python Consortium, as long as CNRI is in any way connected. > > Who's in charge of the PSA? CNRI Effectively, the PSA is a legal fiction for collecting donations to further the development of Python. The Consortium is similar, but members have the actual/explicit capability to steer Python's development. I believe this ability to steer the development is (was?) rooted in the fact that CNRI employed Guido. I have no idea how that will work now -- the "steering" will (essentially) have to rely entirely on Guido's good graces. Guido is an excellent listener to people's needs, so there is no immediate problem here. > Or should we form *another* non-profit, and sign it over to it? The Apache Software Foundation is already a legal, formed, non-profit corporation. If the desire is to transfer copyright to a non-profit, then I'd recommend reusing the ASF rather than trying to start a new one. Recognize that running a company (even a non-profit) is not a "zero cost" item. Somebody would have to put that time in. CNRI is also non-profit, but its members/board/directors/etc are not as Open Source minded as the ASF. > (Personally, I couldn't care less who I transfer copyright over my Python > contributions to -- I'd put it in the public domain if that's what it > took) As Barry said: license and copyright are different. Since you own the copyright, then you *can* put it into the public domain Right Now. I've done that with some of my modules (e.g. qp_xml and imputil). Here is the header from qp_xml.py: # # qp_xml: Quick Parsing for XML # # Written by Greg Stein. Public Domain. # No Copyright, no Rights Reserved, and no Warranties. # Fun, huh? :-) On the other hand, I have given Guido two pieces of code: httplib.py and davlib.py: # # DAV client library # # Copyright (C) 1998-1999 Guido van Rossum. All Rights Reserved. # Written by Greg Stein. Given to Guido. Licensed using the Python license. # Oh. I need to update his copyright year :-) Want to know something really funny? Presuming my httplib.py goes into the Python distribution, that will be the first piece of code that Guido truly owns in Python. All the other code he wrote is owned by CWI or CNRI.... Cheers, -g -- Greg Stein, http://www.lyra.org/ From fredrik at pythonware.com Thu Jun 8 10:30:39 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Thu, 8 Jun 2000 10:30:39 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils/command sdist.py,1.25,1.26 References: <200006080008.RAA15980@slayer.i.sourceforge.net> <20000607200624.R3348@lyra.org> Message-ID: <009501bfd123$d4b2c750$0500a8c0@secret.pythonware.com> greg wrote: > Gah... "pattern_re.match (cur_base)" ... > > You do realize that God intended there to be no spaces between a function > name and the opening paren? Heretic! http://www.python.org/doc/essays/styleguide.html ... I hate whitespace in the following places: ... Immediately before the open parenthesis that starts the argument list of a function call, as in spam (1). Always write this as spam(1). ... Don't bother to argue with me on any of the above ... From andy at robanal.demon.co.uk Thu Jun 8 10:42:46 2000 From: andy at robanal.demon.co.uk (Andy Robinson) Date: Thu, 8 Jun 2000 09:42:46 +0100 Subject: [Python-Dev] Package Style Guide In-Reply-To: <20000608030555.532221CDEF@dinsdale.python.org> Message-ID: Thanks for all the replies. We really need a 'style guide' on package use, so I hope this example can be thrashed out and used to help others. We need to decide something and release next week, and also provide good docs for other users who will be new to Python. Apart from the ambiguity, which was a surprise but which we can work around, I have some general questions on the "right thing". Here are my examples: 1. use of __init__ to save users work ------------------------------------ ReportLab has a subpackage called 'platypus' which we have just reorganized and not yet released. The division into subpackages is clear - each exposes a different kind of functionality - but the division of each package into modules is based on keeping a sane length for each and not on providing a friendly user interface. reportlab pdfgen canvas.py defines class Canvas textobject.py defines class TextObject pathobject.py defines class PathObject platypus (the same problem, but 3x worse) lib (loads of modules, all independent) We reached a point where users need to import eight or ten classes to do useful work and were having to put eight or ten different import lines at the top of every script. This just feels dumb and wrong. So, the 'least messy' idea was to put __init__.py methods in each subpackage which explicitly import what they need. (We have not used "import *") ---reportlab/pdfgen/__init__.py-------- from canvas import Canvas from textobject.py import TextObject from pathobject.py impory PathObject Then users can just do: from reportlab.pdfgen import Canvas, PathObject, TextObject It seems that this (a) makes life easier for users, and (b) gives us freedom to refactor code as it grows, without changing the user interface. Is this style evil? If so, why? 2. Ambiguities running scripts within package --------------------------------------------- We have various test functions scattered throughout our distribution. A control script iterates through the lot and kicks them off before every release, executing everything with an 'if __name__=='__main__' handler. If these were standalone scripts just for testing, they could import "reportlab.platypus.tables" or whatever. But if I just want to put a test routine at the end of "reportlab.platypus.tables" then I seem destined to run into exactly the ambiguity outlined before. Should test scripts all be moved out of the package? Indeed, is Python behaving the way it ought to? 3. Preferred subpackage import technique ---------------------------------------- I have two scripts 'spam.py' and 'eggs.py' in subpackage 'A.B'. spam imports eggs. Should it say... import eggs or... import A.B.eggs? Both work sometimes, but can lead to different behavious sometimes. Which is the preferred style? Thanks, Andy Robinson From pf at artcom-gmbh.de Thu Jun 8 11:35:14 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Thu, 8 Jun 2000 11:35:14 +0200 (MEST) Subject: [Python-Dev] Package Style Guide In-Reply-To: from Andy Robinson at "Jun 8, 2000 9:42:46 am" Message-ID: Hi Andy, > Thanks for all the replies. > We really need a 'style guide' on package use, On 'import', packages and modules: ---------------------------------- You should definitely have a look at the approach used by Greg McFarlane in his 'Pmw' package. In particular at his PmwLoader class and the Pmw.def. For my own project I've simplified and somewhat generalized his approach to dynamic and lazy importing. I posted a preliminary implemantation of this to comp.lang.python a while ago but didn't got much feedback. May be due to fact, that I had to repost the thing, because the TABs went wrong in the first try :-( [...] > Is this style evil? If so, why? I believe it will get really hard to come up with a 'namespace style guide' which everybody can aggree on. But who cares: let's start a rant: --> IMO 'from ... import ...' is EVIL and its use should be banned! <-- Why? Because if software becomes bigger (> 100k LOC), these unqualified names definitely become a maintaince nightmare, since you didn't know what names are defined in the module you are currently staring at and what names come from the "outside world". I believe Python inherited two of its three forms of import syntax at least in part from its anchestors Modula-2 and Modula-3. My perception of this import-problem may be blurred by programming in Modula-2 in our company since 1985, where the code base now is about ~1 Mio. LOC. Some of the older code contains still modules using a lot of 'FROM foobar IMPORT ....;' lines in the header. These have usually been harder to read and understand by new employees than those having 'IMPORT foobar;' in the header and than using 'foobar.component' everywhere in the code body below. from .... import * is *EVEN MORE EVIL*. Well: at least if people use 'from' to import arbitrary objects and classes. Using 'from package.subpackage import module' is an idiom, with which I can live with comfortably. > Should test scripts all be moved out of the package? This would defeat the use of Tim Peters wonderful 'doctest' module. I'm still thinking, 'doctest' should be made part of the standard library in order to give the publicity this elegant approach deserves. Regards, Peter From Vladimir.Marangozov at inrialpes.fr Thu Jun 8 12:27:10 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Thu, 8 Jun 2000 12:27:10 +0200 (CEST) Subject: [Python-Dev] revamped Python web site In-Reply-To: <20000607174148.A6801@thyrsus.com> from "Eric S. Raymond" at Jun 07, 2000 05:41:48 PM Message-ID: <200006081027.MAA02445@python.inrialpes.fr> [Jeremy Hylton] > > Say a startup company decided to put some resources behind the Python > Web site -- a full-time Web master, some content developers, etc. > What would you have them do? What could be done to open up the site > to the community and make it more responsive to developers and users? > What's your wish list for content, services, etc.? The content is good. Some wishes on its presentation, not taking into account any cosmetic changes. With my webmaster's hat, I would say: 1. Make the content accessible, i.e. compliant to the standards HTML tidy does a pretty good job in cleaning up existing Web pages I would suggest sticking with valid XHTML 1.0 transitional or HTML 4.x transitional. 2. Use CSS -- not too much, though, given its growing but still limited support. I am using myself parts of CSS1. My approach is to use styles *and* attributes (which is redundant, for now). Browsers that understand styles would honor them, while those that don't would take into account the attributes. The aim is to have the same end result. With the evolution of the browsers, the attributes would disappear. A compromise that introduces styles smoothly. 3. Have a comprehensible site map for direct access to the major topics. I tend to like ours which is convenient for small to medium sized sites (http://www.inrialpes.fr/plansite.html) 4. Do not use frames, do not use JavaScript or similar, do not use anything that hurts content accessibility. [Eric S. Raymond] > > My top wishlist item is "Burn all your GIFs". This seems to be an important symbol for an organization with an Open Source spirit. Hopefully, a gif2png batch processing should make things easier. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From gstein at lyra.org Thu Jun 8 13:43:24 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 8 Jun 2000 04:43:24 -0700 Subject: [Python-Dev] Package Style Guide In-Reply-To: ; from pf@artcom-gmbh.de on Thu, Jun 08, 2000 at 11:35:14AM +0200 References: Message-ID: <20000608044324.L3348@lyra.org> On Thu, Jun 08, 2000 at 11:35:14AM +0200, Peter Funk wrote: >... > > Is this style evil? If so, why? > > I believe it will get really hard to come up with a 'namespace style guide' > which everybody can aggree on. But who cares: let's start a rant: > > --> IMO 'from ... import ...' is EVIL and its use should be banned! <-- You are being overly strict here. I use this all the time: from module import submodule ... submodule.Class() or even from module.submodule import subsub ... subsub.Blargle() In other words, "from package import module" is a Fine Thing. It can simplify your code without hiding where the symbols come from. In general, I agree with you: importing symbols from a module into your namespace is a Bad Thing. Cheers, -g -- Greg Stein, http://www.lyra.org/ From fdrake at beopen.com Thu Jun 8 14:37:04 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 8 Jun 2000 08:37:04 -0400 (EDT) Subject: [Python-Dev] revamped Python web site In-Reply-To: <200006081027.MAA02445@python.inrialpes.fr> References: <20000607174148.A6801@thyrsus.com> <200006081027.MAA02445@python.inrialpes.fr> Message-ID: <14655.37744.352128.72841@cj42289-a.reston1.va.home.com> Vladimir Marangozov writes: > 2. Use CSS -- not too much, though, given its growing but still limited > support. I am using myself parts of CSS1. My approach is to use styles > *and* attributes (which is redundant, for now). Browsers that understand > styles would honor them, while those that don't would take into account > the attributes. The aim is to have the same end result. With the evolution > of the browsers, the attributes would disappear. The approach to CSS I've taken with the documentation is to use attributes for anything that's really needed to make the presentation readable and then an external CSS stylesheet for everything else. This seems like a reasonable approach to me, and avoids including too much duplicate information. This also seems like the best way to maintain support for older browsers. Perhaps we should collect browser statistics on python.org so we'll know how many "legacy" browsers are in use? I would be surprised if many of the text-mode browsers support CSS well (and there are several being actively worked on these days, so please don't tell me they don't count!). > 4. Do not use frames, do not use JavaScript or similar, do not use anything > that hurts content accessibility. I do have some JavaScript on python.org, but it's only to make data entry in a form a little easier by making adjustments to related fields, so it remains completely operational without JavaScript. I don't think there's currently any required JavaScript. And I have yet to see a frame, thank goodness! [Eric S. Raymond] > > My top wishlist item is "Burn all your GIFs". Is it more important than accessibility? This is a real issue for legacy browsers, especially on minority platforms. One of the big wins for Python is that it is as portable as it is. Does that matter if information is hard to get to? A good reason to avoid using images for anything that isn't cosmetic! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From pf at artcom-gmbh.de Thu Jun 8 14:28:11 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Thu, 8 Jun 2000 14:28:11 +0200 (MEST) Subject: [Python-Dev] Package Style Guide In-Reply-To: <20000608044324.L3348@lyra.org> from Greg Stein at "Jun 8, 2000 4:43:24 am" Message-ID: Hi Greg, [me] > > --> IMO 'from ... import ...' is EVIL and its use should be banned! <-- [Greg Stein]: > You are being overly strict here. I use this all the time: > > from module import submodule > ... > submodule.Class() > > or even > > from module.submodule import subsub > ... > subsub.Blargle() Okay. Later in my rant I wrote: < Well: at least if people use 'from' to import arbitrary objects and < classes. Using 'from package.subpackage import module' is an idiom, < with which I can live with comfortably. [Greg Stein]: > In other words, "from package import module" is a Fine Thing. It can > simplify your code without hiding where the symbols come from. Yes, you are right. But if you put the facade pattern[*] into use within such packages, this will even simplify your live, if you later have to redesign the internal substructure of your package. [*] Design patterns and especially the "facade pattern" were AFAIK introduced in the so called "Gang of four" book: "Design Patterns - Elements of Reusable Object-Oriented Software", Addison Wesley, 1995. The somewhat similar "whole part" design pattern is discussed in the book "A System of Patterns" written by Buschmann, Meunier, Rohnert, Sommerlad, Stal; published by John Wiley & Sons, New York; 1996; ISBN 0 471 95869 7 > In general, I agree with you: importing symbols from a module into your > namespace is a Bad Thing. Fine. Consensus gives a warm and fuzzy feeling. ;-) Regards, Peter From esr at thyrsus.com Thu Jun 8 14:53:51 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 8 Jun 2000 08:53:51 -0400 Subject: [Python-Dev] revamped Python web site In-Reply-To: <14655.37744.352128.72841@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Thu, Jun 08, 2000 at 08:37:04AM -0400 References: <20000607174148.A6801@thyrsus.com> <200006081027.MAA02445@python.inrialpes.fr> <14655.37744.352128.72841@cj42289-a.reston1.va.home.com> Message-ID: <20000608085351.A9299@thyrsus.com> Fred L. Drake, Jr. : > [Eric S. Raymond] > > > > My top wishlist item is "Burn all your GIFs". > > Is it more important than accessibility? This is a real issue for > legacy browsers, especially on minority platforms. One of the big > wins for Python is that it is as portable as it is. Does that matter > if information is hard to get to? Go check out the PNG site's census of PNG support in "legacy" browsers. Basically, as long as your PNGs don't use transparency or animation, you're fine. You've already had the good taste to eschew animation. I don't think you're using transparency anywhere that simply matteing the image on a white background won't fix it -- and gif2png has an option to do that. > A good reason to avoid using images for anything that isn't > cosmetic! I agree with that. -- Eric S. Raymond Sometimes the law defends plunder and participates in it. Sometimes the law places the whole apparatus of judges, police, prisons and gendarmes at the service of the plunderers, and treats the victim -- when he defends himself -- as a criminal. -- Frederic Bastiat, "The Law" From jeremy at beopen.com Thu Jun 8 15:58:42 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 8 Jun 2000 09:58:42 -0400 (EDT) Subject: [Python-Dev] release forms? (was: [Patches] New sys method to return total reference count in debug builds.) In-Reply-To: <20000607210555.X3348@lyra.org> References: <20000607101146.D5559@ludwig.cnri.reston.va.us> <20000607210555.X3348@lyra.org> Message-ID: <14655.42642.608768.433695@localhost.localdomain> >>>>> "GS" == Greg Stein writes: GS> On Wed, Jun 07, 2000 at 05:33:10PM +0300, Moshe Zadka wrote: >> On Wed, 7 Jun 2000, Greg Ward wrote: >> >> > CNRI has absolutely no moral right to it (although probably >> some legal > right), I'd prefer to sign it away to Guido. Or >> optionally, to some > legal fiction that represents the Python >> community; preferably *not* the > Python Consortium, as long as >> CNRI is in any way connected. >> >> Who's in charge of the PSA? GS> CNRI GS> Effectively, the PSA is a legal fiction for collecting donations GS> to further the development of Python. The Consortium is similar, GS> but members have the actual/explicit capability to steer GS> Python's development. I believe this ability to steer the GS> development is (was?) rooted in the fact that CNRI employed GS> Guido. I have no idea how that will work now -- the "steering" GS> will (essentially) have to rely entirely on Guido's good GS> graces. Guido is an excellent listener to people's needs, so GS> there is no immediate problem here. The description of the PSA isn't exactly right. The PSA FAQ has an official explanation, which may not be right either, but at least it's what CNRI wants you to think. (And it may be right; I don't mean to suggest a nefarious plot, just that the relationship is convoluted enough that the explanation could be wrong.) http://www.python.org/psa/FAQ.html An abbreviated version follows: |Where does the money from membership fees go and who pays the rest? | | The money goes towards the salary of those who maintain and | coordinate the Python web site, ftp server, mailing lists, | conference expenses etc.... The case for these expenditures is | that a seed community is being incubated. CNRI officers and | directors see proof of the existence of such a community from the | fact that some members of that community are willing to pay some | of their own money to foster the activity. | |Who funds Python's development? | PSA fees do not fund the Python development effort.... CNRI is no longer maintaining python.org, although it still owns the domain and maintains the equipment it runs on. The existence of a community should be obvious now, without the need for people to pay money to prove it. Jeremy From skip at mojam.com Thu Jun 8 16:08:13 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 8 Jun 2000 09:08:13 -0500 Subject: [Python-Dev] impact of cycle gc... Message-ID: <200006081408.JAA03136@beluga.mojam.com> I spent a little time poking around with a very simple test script (appended) that makes use of Neil's cycle gc patch. It measures the time it takes to instantiate and delete a cycle-producing instance 100,000 times (based upon a report in python-bugs). For vanilla 1.6a2 ("./configure" ; make") I got the following (last of six runs): memory usage @ start: 5560 clock: 1.33 elapsed: 1.34805500507 memory usage @ end: 18816 For 1.6a2 configured --with-cycle-gc ("./configure --with-cycle-gc ; make") I got the following (also the last of six runs): memory usage @ start: 5576 clock: 2.34 elapsed: 2.33785700798 memory usage @ end: 5576 I was very impressed with the memory usage, but dismayed at the increased execution time (about 75% more). Of course, this is a test script that is bound to show the potential performance penalty in the worst possible light. Maybe pystone will be more indicative of the performance hit we can expect from it. (There's a new one - pystone.py being a better indicator of true system performance than some other test script!) Plain: Pystone(1.1) time for 10000 passes = 1.76 This machine benchmarks at 5681.82 pystones/second --with-cycle-gc: Pystone(1.1) time for 10000 passes = 1.83 This machine benchmarks at 5464.48 pystones/second That suggests something more like a 4% performance penalty. I suspect that may be the lower limit. While I haven't looked at pystone recently, I doubt it creates any cyclic garbage. My next step will be to try it out on my development database server and see what happens. just-another-data-point-ly y'rs, -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ "We have become ... the stewards of life's continuity on earth. We did not ask for this role... We may not be suited to it, but here we are." - Stephen Jay Gould class fred: def __init__(self): self.indirectFunc = self.theFunc def theFunc(self): return "blah" def test(): f = fred() del f if __name__ == "__main__": import os, time, sys sys.stdout.write("memory usage @ start: ") sys.stdout.flush() os.system("ps auxww | egrep method | egrep -v egrep | awk '{print $5}'") t = time.clock(), time.time() for x in xrange(100000): test() print "clock:", time.clock()-t[0], "elapsed:", time.time()-t[1] sys.stdout.write("memory usage @ end: ") sys.stdout.flush() os.system("ps auxww | egrep method | egrep -v egrep | awk '{print $5}'") From gmcm at hypernet.com Thu Jun 8 16:48:01 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Thu, 8 Jun 2000 10:48:01 -0400 Subject: [Python-Dev] Package Style Guide In-Reply-To: References: <20000608030555.532221CDEF@dinsdale.python.org> Message-ID: <1251646781-15052905@hypernet.com> Andy wrote: > 1. use of __init__ to save users work [package structure] > reportlab > pdfgen > canvas.py defines class Canvas > textobject.py defines class TextObject > pathobject.py defines class PathObject > platypus > (the same problem, but 3x worse) > lib > (loads of modules, all independent) > ---reportlab/pdfgen/__init__.py-------- > from canvas import Canvas > from textobject.py import TextObject > from pathobject.py impory PathObject I would suggest that these not use relative names. from reportlab.pdfgen.canvas import Canvas will ensure that Canvas is only found in one way (no matter where the script is, or rather, what sys.path[0] evaluates to at import time). Your other choice is to disallow any scripts within reportlab/ and deliver 220 V shocks to any user who starts Python anyplace within reportlab/ (or otherwise lets any part of sys.path evaluate to anything within reportlab/). > Then users can just do: > from reportlab.pdfgen import Canvas, PathObject, TextObject > > It seems that this (a) makes life easier for users, and > (b) gives us freedom to refactor code as it grows, without > changing the user interface. Since you're doing this for "convenience", another option is to provide convenience methods: def newCanvas(): return reportlab.pdfgen.canvas.Canvas() > 2. Ambiguities running scripts within package > --------------------------------------------- > Should test scripts all be moved out of the package? > Indeed, is Python behaving the way it ought to? If you use relative imports, yes. But even so, you incur a risk in using relative imports (see above). And you only do it from laziness. So I say don't use relative imports. > 3. Preferred subpackage import technique > ---------------------------------------- > I have two scripts 'spam.py' and 'eggs.py' in > subpackage 'A.B'. spam imports eggs. > Should it say... > import eggs > or... > import A.B.eggs? You know what I'm going to say... - Gordon From mal at lemburg.com Thu Jun 8 16:48:49 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 08 Jun 2000 16:48:49 +0200 Subject: [Python-Dev] revamped Python web site References: <14654.48609.710990.321688@localhost.localdomain> Message-ID: <393FB251.6100175B@lemburg.com> Jeremy Hylton wrote: > > Say a startup company decided to put some resources behind the Python > Web site -- a full-time Web master, some content developers, etc. > What would you have them do? What could be done to open up the site > to the community and make it more responsive to developers and users? > What's your wish list for content, services, etc.? > > If you've got any ideas, please get back to me soon. Why not turn python.org into a Python portal site with all the jazz that goes with it, e.g. newsletters, browsable news forums for different news aspects (business news, new developments, press references, Python related meetings, etc.), customization of the information layout, email notification when things change, chat forums, a Python knowledge base, etc. etc. The reasoning is that Python is starting to go business and the site should reflect this move. As more companies start producing Python tools, I think it might even be worthwhile considering Python related marketing on the Python site, e.g. small banners, external links, etc. This would help finance the site and its administrators. As far as content goes, I think Python.org is hardly beatable :-) What's missing is some more service to push its fun factor which in return pushes Python's acceptance. Anyway, just a thought... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Thu Jun 8 16:54:01 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 08 Jun 2000 16:54:01 +0200 Subject: [Python-Dev] Package ambiguities References: <393eb52b.47053339@post.demon.co.uk> <1251707300-11412775@hypernet.com> <14654.51045.18807.74677@localhost.localdomain> Message-ID: <393FB389.893D20E3@lemburg.com> Jeremy Hylton wrote: > > Gordon's comments are on the money. An import in a module inside a > package should be fully qualified. I'd put that in the style guide if > it were up to me (and, of course, it's not). +1 from here :-) I usually write things like this: from mx.DateTime import now print 'The time is', now() If you don't do so, you'll run into strange problems, the most subtle one I've encountered is with pickled objects... if unpickled inside the same package they can cause the same module to be loaded *twice* with all the consequences attached to this (e.g. issubclass() no longer works). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Thu Jun 8 17:20:23 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 08 Jun 2000 17:20:23 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Objects unicodeobject.c,2.21,2.22 References: <200006070913.CAA18060@slayer.i.sourceforge.net> <20000607193537.Q3348@lyra.org> Message-ID: <393FB9B7.B93A7C61@lemburg.com> Greg Stein wrote: > > On Wed, Jun 07, 2000 at 02:13:24AM -0700, Marc-Andre Lemburg wrote: > > Update of /cvsroot/python/python/dist/src/Objects > > In directory slayer.i.sourceforge.net:/tmp/cvs-serv17917/Objects > > > > Modified Files: > > unicodeobject.c > > Log Message: > > Marc-Andre Lemburg : > > Change the default encoding to 'ascii' (it was previously > > defined as UTF-8). > > > > Note: The implementation still uses UTF-8 to implement > > the buffer protocol, so C APIs will still see UTF-8. This > > is on purpose: rather than fixing the Unicode implementation, > > the C APIs should be made Unicode aware. > > I'm a little confused on where this gets applied. Is this when somebody says > "str(unicode_ob)", they get back ASCII rather than UTF-8? Or is this when > somebody says "unicode(str)" and we expect to be ASCII? The buffer protocol is used for "s", "t" and "s#" argument parsing in C. Since these pass back pointers to internal buffers of the object which must be kept alive until the object is GCed, there's no easy way to change the encoding of that buffer. To play safe I left that buffer encoded in UTF-8 (the hash value is also computed from the UTF-8 encoding of the unicode value to make it compatible to ASCII 8-bit strings). Note that both str(unicode) and unicode(str) will use the default encoding. %-formatting and comparisons also use the default encoding. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Thu Jun 8 17:08:45 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 08 Jun 2000 17:08:45 +0200 Subject: [Python-Dev] Idea: emulating _locale References: <393E2304.4BE8CDE0@lemburg.com> <20000607193014.P3348@lyra.org> Message-ID: <393FB6FD.AB0124E2@lemburg.com> Greg Stein wrote: > > On Wed, Jun 07, 2000 at 12:25:08PM +0200, M.-A. Lemburg wrote: > >... > > Peter Funk wrote: > >... > > > > + ### C lib locale APIs > > > > + > > > > + from _locale import * > > > > > > Wouldn't it be clever to provide some dummy stubs on those platforms, where > > > the _locale module was not enabled? > > > > > > try: > > > from _locale import * > > > except: > > > def setlocale(.... > > > def localeconv(.... > > > ... > > > > > > Especially the MacOS 1.5.2 release provided by Jack Jansen was > > > compiled without '_locale'. And at least in Python 1.6a2 '_locale' > > > is still disabled per default in 'Modules/Setup.in'. I didn't had > > > a look into the current CVS though, so this may have changed. > > > > > > I think the name aliasing tables might be also useful on those > > > systems lacking locale support in their C-library. > > > > setlocale and localeconv are ANSI C and Python requires an ANSI C > > compiler, so there should be no problem (at least in theory). > > > > If there is a problem, adding the missing symbols would > > be no problem: the APIs could always report locale 'C' > > and its numeric settings. > > An ANSI C compiler and the ANSI C library are very different. Just because > Python requires an ANSI compiler (or close to it), does NOT mean that we can > or should depend upon particular elements in the library. Well, ok, it's POSIX.1 too, but... > IMO, we should follow Peter's advice and have stubs for the platforms where > _locale is not built. ...ok, since it doesn't hurt, I'll add some dummies to locale.py which return the same thing as the 'C' locale. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From pingster at ilm.com Thu Jun 8 19:10:46 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Thu, 8 Jun 2000 10:10:46 -0700 (PDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils/command sdist.py,1.25,1.26 In-Reply-To: <20000607200624.R3348@lyra.org> Message-ID: On Wed, 7 Jun 2000, Greg Stein wrote: > Gah... "pattern_re.match (cur_base)" ... > > You do realize that God intended there to be no spaces between a function > name and the opening paren? Heretic! [...] > Put another way: when > you skim code, NAME( is a function call and NAME ( is something else. A > space after a name usually indicates the name is participating in an > expression, rather than being used as a function name. Yesyesyes! This is an absolute rule for me (in other languages too: in C, for example, *always* a space between "if" or "for" and the open-paren). I colourize based on this. It's great -- the one green word on the line stands out; it's the verb, and that lets me know what's going on at a quick glance. (My "Principle of Syntax Highlighting" is to highlight not by what things are, but by what *role* they play. Defining occurrence of anything is a biggie. Comments and docstrings are coloured alike; docstrings are not data. And so on.) -- ?!ng From klm at digicool.com Thu Jun 8 20:38:32 2000 From: klm at digicool.com (Ken Manheimer) Date: Thu, 8 Jun 2000 14:38:32 -0400 (EDT) Subject: [Python-Dev] revamped Python web site In-Reply-To: <14654.48609.710990.321688@localhost.localdomain> Message-ID: On Wed, 7 Jun 2000, Jeremy Hylton wrote: > Say a startup company decided to put some resources behind the Python > Web site -- a full-time Web master, some content developers, etc. > What would you have them do? What could be done to open up the site > to the community and make it more responsive to developers and users? > What's your wish list for content, services, etc.? > > If you've got any ideas, please get back to me soon. Here's some suggestions - i put things more important to me closer to the top, more or less. 1. Delegation of sections to individuals or groups. Eg: - topic guides - particular people get management of areas. (Of course, i'd do this with zope, including zwiki pages as well as regular zope documents for the respective topic-guide managers to use in constructing their content - and for delegating or openning up portions of *their* sections to others...) - The humor page (i'm sad to see that languishing) - Other incidental stuff in the Documentation section of the current site 2. Community-contributed news and hints - portal-style membership/ contribution of news items, reviewed for release or rejection (maybe with community-based reviewers voting) 3. Vaults of parnassus already does this, but i'll still mention - Contributed software/docs/etc - managed similar to moderated news postings, but with classification/cataloguing of artifacts, ability for people to vote on desirability for ranking purposes 5. Jobs board - job postings possibly also managed with news-style reviewing process 6. Subscription to pages, to get notifcations when they change (probably batched, so people don't get too many as something is undergoing development). 7. Discussion "area" for coordinating and collecting logs of IRC-style chats when hot-topics arise that need rendezvous. 8. Open community wiki(s) for growing interesting little worlds (and with my new zwiki nesting-organization features, it may not be too chaotic). Ken klm at digicool.com From gvwilson at nevex.com Thu Jun 8 20:45:37 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Thu, 8 Jun 2000 14:45:37 -0400 (EDT) Subject: [Python-Dev] revamped Python web site In-Reply-To: Message-ID: > Ken Manheimer said > 3. Vaults of parnassus already does this, but i'll still mention - > Contributed software/docs/etc - managed similar to moderated news > postings, but with classification/cataloguing of artifacts, ability for > people to vote on desirability for ranking purposes I'd like to see the Vaults, Starship, and other sub-sites folded into, or become subsections of, a larger Python site, so that I've got the same kind of one-stop shopping that CPAN gives me. Thanks, Greg From esr at thyrsus.com Thu Jun 8 20:54:45 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 8 Jun 2000 14:54:45 -0400 Subject: [Python-Dev] revamped Python web site In-Reply-To: ; from gvwilson@nevex.com on Thu, Jun 08, 2000 at 02:45:37PM -0400 References: Message-ID: <20000608145445.A10500@thyrsus.com> Greg Wilson : > > Ken Manheimer said > > 3. Vaults of parnassus already does this, but i'll still mention - > > Contributed software/docs/etc - managed similar to moderated news > > postings, but with classification/cataloguing of artifacts, ability for > > people to vote on desirability for ranking purposes > > I'd like to see the Vaults, Starship, and other sub-sites folded into, or > become subsections of, a larger Python site, so that I've got the same > kind of one-stop shopping that CPAN gives me. Second that. -- Eric S. Raymond Such are a well regulated militia, composed of the freeholders, citizen and husbandman, who take up arms to preserve their property, as individuals, and their rights as freemen. -- "M.T. Cicero", in a newspaper letter of 1788 touching the "militia" referred to in the Second Amendment to the Constitution. From gmcm at hypernet.com Thu Jun 8 20:57:51 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Thu, 8 Jun 2000 14:57:51 -0400 Subject: [Python-Dev] revamped Python web site In-Reply-To: References: <14654.48609.710990.321688@localhost.localdomain> Message-ID: <1251631791-15954519@hypernet.com> From fdrake at beopen.com Thu Jun 8 21:46:00 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 8 Jun 2000 15:46:00 -0400 (EDT) Subject: [Python-Dev] revamped Python web site In-Reply-To: <20000608085351.A9299@thyrsus.com> References: <20000607174148.A6801@thyrsus.com> <200006081027.MAA02445@python.inrialpes.fr> <14655.37744.352128.72841@cj42289-a.reston1.va.home.com> <20000608085351.A9299@thyrsus.com> Message-ID: <14655.63480.384525.129125@cj42289-a.reston1.va.home.com> Eric S. Raymond writes: > Go check out the PNG site's census of PNG support in "legacy" > browsers. Basically, as long as your PNGs don't use transparency or > animation, you're fine. You've already had the good taste to eschew Excellent! I'll review the list next week probably. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From jeremy at beopen.com Thu Jun 8 22:24:51 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 8 Jun 2000 16:24:51 -0400 (EDT) Subject: [Python-Dev] revamped Python web site In-Reply-To: <1251631791-15954519@hypernet.com> References: <14654.48609.710990.321688@localhost.localdomain> <1251631791-15954519@hypernet.com> Message-ID: <14656.275.83488.186898@localhost.localdomain> >>>>> "GM" == Gordon McMillan writes: >> From Ken Manheimer's Python web site wishlist: - The humor page >> (i'm sad to see that languishing) GM> A weekly nude Tim Peters jpeg! We were going to keep those on the pythonlabs.com internal site, but if Tim doesn't object... Jeremy From jeremy at beopen.com Thu Jun 8 23:19:49 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 8 Jun 2000 17:19:49 -0400 (EDT) Subject: [Python-Dev] impact of cycle gc... In-Reply-To: <200006081408.JAA03136@beluga.mojam.com> References: <200006081408.JAA03136@beluga.mojam.com> Message-ID: <14656.3573.754658.791617@localhost.localdomain> Skip, I don't have time today to look at your post in detail, but one thing you said rtiggered a pretty immediate response: We should worry more about the GC performance on examples like the one you posted, and less about pystone. pystone is a good benchmark for testing the overhead in cases when the garbage collector isn't invoked. There's so little memory allocation that nothing interesting happens. The GC patch ought to have no effect in this case. I suppose 4% is okay. The worry is about programs that allocate a lot of objects, even if they never create circular references. The compiler test is one example, because the parser tree consumes an enormous number of tuples and objects. I suspect big slowdowns like the one you posted just mean we don't know how to adjust the tuneable parameters. Jeremy From gstein at lyra.org Fri Jun 9 02:01:08 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 8 Jun 2000 17:01:08 -0700 Subject: [Python-Dev] revamped Python web site In-Reply-To: ; from gvwilson@nevex.com on Thu, Jun 08, 2000 at 02:45:37PM -0400 References: Message-ID: <20000608170108.B16880@lyra.org> On Thu, Jun 08, 2000 at 02:45:37PM -0400, Greg Wilson wrote: > > Ken Manheimer said > > 3. Vaults of parnassus already does this, but i'll still mention - > > Contributed software/docs/etc - managed similar to moderated news > > postings, but with classification/cataloguing of artifacts, ability for > > people to vote on desirability for ranking purposes > > I'd like to see the Vaults, Starship, and other sub-sites folded into, or > become subsections of, a larger Python site, so that I've got the same > kind of one-stop shopping that CPAN gives me. +1 on that! If python.org opens up (beyond what was possible w.r.t CNRI's security policy), then I see a lot of the impetus for separate sites, such as Starship and Parnassus, simply disappearing. While we're at it: Python-URL has some funny location that I can't ever remember. Providing a way for the organizers to publish those onto python.org (and maintain the archive there) would be good. If /F is still doing the daily URL, then it could go there, too... Cheers, -g -- Greg Stein, http://www.lyra.org/ From nascheme at enme.ucalgary.ca Fri Jun 9 03:29:00 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Thu, 8 Jun 2000 19:29:00 -0600 Subject: [Python-Dev] impact of cycle gc... Message-ID: <20000608192900.A21668@acs.ucalgary.ca> Just a few points and then I will get off python-dev. :) First of all, I don't think it is very meaningful to use leaking applications to do timing comparisons. The collector has be quite careful when freeing structures containing reference cycles. However, using something other than pystone is definitely a good idea. Here the pybench results for the latest patch: PYBENCH 0.6 Benchmark: b_nogc (rounds=4, warp=30) Tests: per run per oper. diff * ------------------------------------------------------------------------ BuiltinFunctionCalls: 286.25 ms 3.37 us -4.22% BuiltinMethodLookup: 367.50 ms 1.05 us -4.55% ConcatStrings: 368.37 ms 3.68 us +42.50% CreateInstances: 477.87 ms 17.07 us -4.45% CreateStringsWithConcat: 322.12 ms 2.42 us +10.27% DictCreation: 382.75 ms 3.83 us +1.29% ForLoops: 536.88 ms 80.73 us +0.99% IfThenElse: 432.75 ms 0.96 us -3.21% ListSlicing: 236.87 ms 104.12 us +11.73% NestedForLoops: 320.00 ms 1.28 us +0.16% NormalClassAttribute: 386.50 ms 0.97 us +0.00% PythonFunctionCalls: 477.87 ms 4.34 us -3.51% PythonMethodCalls: 379.12 ms 7.59 us -12.67% Recursion: 280.75 ms 33.70 us -0.88% SecondImport: 206.62 ms 12.41 us -5.76% SecondPackageImport: 216.75 ms 13.02 us -4.41% SecondSubmoduleImport: 279.25 ms 16.77 us -2.57% SimpleComplexArithmetic: 351.00 ms 2.39 us +0.72% SimpleDictManipulation: 320.75 ms 1.60 us -2.99% SimpleFloatArithmetic: 361.50 ms 0.99 us -20.37% SimpleIntFloatArithmetic: 336.00 ms 0.76 us +0.04% SimpleIntegerArithmetic: 328.38 ms 0.75 us -0.76% SimpleListManipulation: 312.88 ms 1.74 us -1.61% SimpleLongArithmetic: 308.75 ms 2.81 us +9.88% SmallLists: 470.13 ms 2.77 us -5.05% SmallTuples: 374.62 ms 2.34 us -15.74% SpecialClassAttribute: 384.00 ms 0.96 us -1.88% SpecialInstanceAttribute: 446.38 ms 1.12 us -2.75% StringSlicing: 315.50 ms 2.70 us +16.58% TryExcept: 585.37 ms 0.59 us -1.70% TryRaiseExcept: 312.75 ms 31.28 us -5.30% TupleSlicing: 299.38 ms 4.39 us +12.18% ------------------------------------------------------------------------ Average round time: 13615.00 ms -1.13% My AMD-K6-II processor is a pretty quirky beast so I don't think you can conclude too much for those results. Here are the median timings from running Jeremy's compiler on its own source: $ time python compile.py `find . -name '*.py'` Python 1.6 without GC: real 0m16.926s user 0m16.810s sys 0m0.110s Python 1.6 with GC: real 0m21.593s user 0m21.470s sys 0m0.080s Python 1.6 with GC, collection disabled (ie. gc.set_threshold(0)): real 0m18.441s user 0m18.220s sys 0m0.220s We can tune the collection frequency all we want but we won't do any better than the last numbers. Those numbers reflect the cost of keeping track of the objects and the increase in object size. On a related note, I would like to cleanup the PyGC_{NEW, VAR_NEW} macros but I can't figure out a way to transform this code into a macro: op = PyObject_MALLOC(sizeof(PyGCInfo) + _PyObject_SIZE(tp)); if (op) op = PyGC_OBJ((PyGCInfo *)op); If C's || operator was like the Python or I could do something like: #define PyGC_OBJ_SAFE(g) ((PyGCInfo *)(((g) || -1) + 1)) Any ideas? Using an inline function in the header file would be nice but of course it is not portable. GCC has statement expressions but again they are not portable. Neil From Vladimir.Marangozov at inrialpes.fr Fri Jun 9 04:03:59 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Fri, 9 Jun 2000 04:03:59 +0200 (CEST) Subject: [Python-Dev] impact of cycle gc... In-Reply-To: <20000608192900.A21668@acs.ucalgary.ca> from "Neil Schemenauer" at Jun 08, 2000 07:29:00 PM Message-ID: <200006090204.EAA11518@python.inrialpes.fr> Neil Schemenauer wrote: > > On a related note, I would like to cleanup the PyGC_{NEW, > VAR_NEW} macros but I can't figure out a way to transform this > code into a macro: > > op = PyObject_MALLOC(sizeof(PyGCInfo) + _PyObject_SIZE(tp)); > if (op) > op = PyGC_OBJ((PyGCInfo *)op); The correct thing to do, IMO, is to reflect the sizeof(PyGCInfo) mem increment in the tp_basicsize slot of the type object. Thus, we can reuse the current PyObject_New/NEW code, which boils down to PyObject_MALLOC(_PyObject_SIZE(tp)). There is no need for PyGC_NEW/NEW_VAR. This would imply some additional changes to PyObject_Init when the GC_FLAG is set for a given typeobj. I had a closer look at the patch today. It looks good, but I think it needs some more work for a smooth integration with the existing APIs. There's room for optimisations (there are lots of function calls in there, so I am not surprised about the performance hit), but they'll come later on, once the big chunks of the patch fit in their places. One thing that bothered me is that the current gc object allocation code won't fly with C++, where the object storage is allocated (and its size is computed) automatically. There is no PyObject_New, and a C++ object constructor is supposed to begin with PyObject_Init. Another thing is the function names: PyGC_NEW, PyGC_Info, PyGC_Insert, etc. It would be better if they reflect the fact that we're talking about GC on PyObjects, and not about GC in general (on arbitrary mem chunks). I would suggest renaming them along these lines: PyGC_Info -> PyGC_ObjectHead PyGC_Insert -> PyGC_ObjectInit PyGC_Remove -> PyGC_ObjectFini ... All this needs some more thought though... -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From mal at lemburg.com Fri Jun 9 13:03:56 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 09 Jun 2000 13:03:56 +0200 Subject: [Python-Dev] Japanese Codecs Message-ID: <3940CF1C.2C625624@lemburg.com> Python currently supports lots of different code pages and other more specific codecs. I was wondering what your thoughts on this are: should we proceed to include an even wider range of codecs or limit the available number to an absolute minimum ? I'm asking this, because Tamito KAJIYAMA wrote a set of codecs for EUC-JP and Shift_JIS which would probably be very useful for Japanese Python users -- I just don't know how many there are and whether inclusion of an extra 650k of source code would hurt or not. Thoughts ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From akuchlin at cnri.reston.va.us Fri Jun 9 17:08:46 2000 From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling) Date: Fri, 9 Jun 2000 11:08:46 -0400 Subject: [Python-Dev] Japanese Codecs In-Reply-To: <3940CF1C.2C625624@lemburg.com>; from mal@lemburg.com on Fri, Jun 09, 2000 at 01:03:56PM +0200 References: <3940CF1C.2C625624@lemburg.com> Message-ID: <20000609110846.C10688@amarok.cnri.reston.va.us> On Fri, Jun 09, 2000 at 01:03:56PM +0200, M.-A. Lemburg wrote: >I'm asking this, because Tamito KAJIYAMA wrote a set of >codecs for EUC-JP and Shift_JIS which would probably >be very useful for Japanese Python users -- I just don't >know how many there are and whether inclusion of an extra >650k of source code would hurt or not. This seems too much code added that would only be of use to a limited audience, so -1 from me. Japanese packagers of Python would probably include them, of course. -- A.M. Kuchling http://starship.python.net/crew/amk/ I confidently expect it to be a fairly resounding failure. -- John Cleese, on the Monty Python reunion planned for 1999 From skip at mojam.com Fri Jun 9 17:19:59 2000 From: skip at mojam.com (Skip Montanaro) Date: Fri, 9 Jun 2000 10:19:59 -0500 (CDT) Subject: [Python-Dev] impact of cycle gc... In-Reply-To: <14656.3573.754658.791617@localhost.localdomain> References: <200006081408.JAA03136@beluga.mojam.com> <14656.3573.754658.791617@localhost.localdomain> Message-ID: <14657.2847.914770.368965@beluga.mojam.com> Jeremy> I don't have time today to look at your post in detail, but one Jeremy> thing you said rtiggered a pretty immediate response: We should Jeremy> worry more about the GC performance on examples like the one you Jeremy> posted, and less about pystone. I wasn't really worried about pystone, just looking for something quick that didn't generate cycles... ;-) Your suggestion is an excellent one. To try and account for the typical case, I modified the test slightly. I added a new class, ethyl: def foo(): pass class ethyl: def __init__(self): self.indirectFunc = foo def theFunc(self): return "blah" which performs essentially the same work at instantiation time as fred, but doesn't create a cycle. The time (in seconds) to create and delete 100,000 freds and ethyls with and without cycle-gc enabled looks like (last of six consecutive runs): ./python ./python-cycle-gc fred (cycle) 1.4 2.51 ethyl (no cycle) 1.39 1.55 The memory consumption is as you would expect - leaky when creating fred's without using cycle-gc, stable otherwise. So, the penalty for creating and deleting objects that don't contain cycles would appear to be reasonable (about 10-15%). As more experience is gained with it, I imagine it can be reduced further. Skip From mal at lemburg.com Fri Jun 9 17:32:41 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 09 Jun 2000 17:32:41 +0200 Subject: [Python-Dev] Japanese Codecs References: <3940CF1C.2C625624@lemburg.com> <20000609110846.C10688@amarok.cnri.reston.va.us> Message-ID: <39410E19.4E4B1EE7@lemburg.com> "Andrew M. Kuchling" wrote: > > On Fri, Jun 09, 2000 at 01:03:56PM +0200, M.-A. Lemburg wrote: > >I'm asking this, because Tamito KAJIYAMA wrote a set of > >codecs for EUC-JP and Shift_JIS which would probably > >be very useful for Japanese Python users -- I just don't > >know how many there are and whether inclusion of an extra > >650k of source code would hurt or not. > > This seems too much code added that would only be of use to a limited > audience, so -1 from me. Japanese packagers of Python would probably > include them, of course. I just wish that these packagers actually become a reality some day... the concept is good, but there currently seem to be no volunteers or companies jumping in :-( -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From DavidA at ActiveState.com Fri Jun 9 20:54:03 2000 From: DavidA at ActiveState.com (David Ascher) Date: Fri, 9 Jun 2000 11:54:03 -0700 Subject: [Python-Dev] Japanese Codecs In-Reply-To: <39410E19.4E4B1EE7@lemburg.com> Message-ID: > I just wish that these packagers actually become a reality > some day... the concept is good, but there currently seem to > be no volunteers or companies jumping in :-( I can't speak for Japanese packagers, but ActiveState will be packaging Python in various ways. --david From klm at digicool.com Fri Jun 9 20:59:26 2000 From: klm at digicool.com (Ken Manheimer) Date: Fri, 9 Jun 2000 14:59:26 -0400 (EDT) Subject: [Python-Dev] revamped Python web site In-Reply-To: <14656.275.83488.186898@localhost.localdomain> Message-ID: On Thu, 8 Jun 2000, Jeremy Hylton wrote: > >>>>> "GM" == Gordon McMillan writes: > > >> From Ken Manheimer's Python web site wishlist: - The humor page > >> (i'm sad to see that languishing) > > GM> A weekly nude Tim Peters jpeg! > > We were going to keep those on the pythonlabs.com internal site, but > if Tim doesn't object... Anything for a buck, ay, now that you're in the commercial world?-) Ken klm at digicool.com From tim_one at email.msn.com Fri Jun 9 21:11:42 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 9 Jun 2000 15:11:42 -0400 Subject: [Python-Dev] revamped Python web site In-Reply-To: Message-ID: <000c01bfd246$8c02ca40$a12d153f@tim> [KenM] > - The humor page (i'm sad to see that languishing) [Gordon, as always, guides our youth] > A weekly nude Tim Peters jpeg! [JeremyH] > We were going to keep those on the pythonlabs.com internal site, but > if Tim doesn't object... [KenM] > Anything for a buck, ay, now that you're in the commercial world?-) After one of my recent "going away" parties here (I "get to" move to VA next week), a group of old chums were sitting around the restaurant table, belching up bad Italian cooking and speculating on our places in God's Inscrutable Plan. When it came time to pick on me, one naturally pugnacious fellow-- emboldened beyond his normal aggression by wine --looked me straight in the eye and demanded to know if there's *anything* I wouldn't do for money. Well, in point of fact I believe there are a great many such things, but in the moment God only inspired me with one, and so I heard myself retorting: "Ya, sure, I'd fuck a dog for science ... but I wouldn't take a job at Microsoft!". strangely-enough-i-think-that's-backwards-ly y'rs - tim From moshez at math.huji.ac.il Fri Jun 9 21:20:17 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Fri, 9 Jun 2000 22:20:17 +0300 (IDT) Subject: [Python-Dev] revamped Python web site In-Reply-To: <000c01bfd246$8c02ca40$a12d153f@tim> Message-ID: On Fri, 9 Jun 2000, Tim Peters wrote: > In the moment God only inspired me with one, and so I heard > myself retorting: "Ya, sure, I'd fuck a dog for science ... but I wouldn't > take a job at Microsoft!". > > strangely-enough-i-think-that's-backwards-ly y'rs - tim Backwards? You mean you'd fuck Microsoft for science but wouldn't take a job at a dog? Or you'd fuck a dog for Microsoft but wouldn't take a job at science? Or you'd take a job for science, but wouldn't fuck at Microsoft? misunderstanding-tim-seems-to-be-a-common-pass-time-around-here-ly y'rs, Z -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com Return-Path: Delivered-To: python-dev at python.org Received: from math.ma.huji.ac.il (ma.huji.ac.il [132.64.32.5]) by dinsdale.python.org (Postfix) with ESMTP id C19A61CD28; Fri, 9 Jun 2000 14:37:53 -0400 (EDT) Received: from localhost (moshez at localhost) by math.ma.huji.ac.il (8.9.1b+Sun/8.9.3) with ESMTP id VAA28640; Fri, 9 Jun 2000 21:37:03 +0300 (IDT) Date: Fri, 9 Jun 2000 21:37:03 +0300 (IDT) From: Moshe Zadka X-Sender: moshez at sundial Reply-To: Moshe Zadka To: perl_monkey at my-deja.com Cc: python-list at python.org, s2mdalle at titan.vcu.edu In-Reply-To: <8hrbph$a4n$1 at nnrp1.deja.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Python-Dev] Re: Porting CPython Sender: python-dev-admin at python.org Errors-To: python-dev-admin at python.org X-BeenThere: python-dev at python.org X-Mailman-Version: 2.0beta3 Precedence: bulk List-Id: Python core developers Not a lot I can help you with, but: On Fri, 9 Jun 2000 perl_monkey at my-deja.com wrote: > - Excluding Modules > > What is the build procedure for omitting certain built in C modules? > (I"m talking about the stuff in Modules/) Edit the "Setup.in" file. Instructions for how are inside the file, but if you have any more specific questions, please ask again. > Any help on any of these issues would be appreciated. Also, when/if I > finish this, I'd be willing to diff the source and put it into the main > python branch if that's something people would be interested in. I'm CCing Python-Dev on this, so hopefully someone from the BeOpen team can respond. I can just say I'm for it. (Python-dev is on BCC so replies to this won't automatically go there.) -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com From jeremy at beopen.com Fri Jun 9 23:00:09 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 9 Jun 2000 17:00:09 -0400 (EDT) Subject: [Python-Dev] Japanese Codecs In-Reply-To: References: <39410E19.4E4B1EE7@lemburg.com> Message-ID: <14657.23257.478479.141319@localhost.localdomain> >>>>> "DA" == David Ascher writes: >> I just wish that these packagers actually become a reality some >> day... the concept is good, but there currently seem to be no >> volunteers or companies jumping in :-( DA> I can't speak for Japanese packagers, but ActiveState will be DA> packaging Python in various ways. BeOpen also has packaging plans :-). Jeremy From mal at lemburg.com Fri Jun 9 23:49:37 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 09 Jun 2000 23:49:37 +0200 Subject: [Python-Dev] Japanese Codecs References: <39410E19.4E4B1EE7@lemburg.com> <14657.23257.478479.141319@localhost.localdomain> Message-ID: <39416671.AF78100F@lemburg.com> Jeremy Hylton wrote: > > >>>>> "DA" == David Ascher writes: > > >> I just wish that these packagers actually become a reality some > >> day... the concept is good, but there currently seem to be no > >> volunteers or companies jumping in :-( > > DA> I can't speak for Japanese packagers, but ActiveState will be > DA> packaging Python in various ways. > > BeOpen also has packaging plans :-). Sounds cool. I just hope that someone will hint me of the first Python IPO *before* it hits NASDAQ ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From effbot at telia.com Fri Jun 9 23:59:18 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 9 Jun 2000 23:59:18 +0200 Subject: [Python-Dev] Japanese Codecs References: <39410E19.4E4B1EE7@lemburg.com> <14657.23257.478479.141319@localhost.localdomain> Message-ID: <001101bfd25d$f6a0fb80$f2a6b5d4@hagrid> > I can't speak for Japanese packagers, but ActiveState will be > packaging Python in various ways. > > BeOpen also has packaging plans :-). get in line, guys ;-) From esr at thyrsus.com Sat Jun 10 00:19:24 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 9 Jun 2000 18:19:24 -0400 Subject: [Python-Dev] RFC: Including PIL in 1.6 In-Reply-To: <20000609215719.47624E2673@oratrix.oratrix.nl>; from jack@oratrix.nl on Fri, Jun 09, 2000 at 11:57:14PM +0200 References: <20000609215719.47624E2673@oratrix.oratrix.nl> Message-ID: <20000609181924.A15728@thyrsus.com> Jack Jansen : > I include PIL in the standard MacPython and Mac users are apparently > very happy with that [...] I think it's time to consider including PIL in the core Python 1.6 release. I've been following the work being done over there, and I believe the code has reached a sufficient level of maturity to justify this. The "Batteries are included" philosophy seems to me to imply that we ought to be looking for application libraries to promote into the core once we're satisfied that they meet core-Pythonic standards of good API design, stability, general usefulness, and documentation quality. PIL seems to me like a good candidate on all counts. Guido has to make the final call, of course. But let's have the discussion now so we can develop a yea or nay consensus on ther list. -- Eric S. Raymond Society in every state is a blessing, but government even in its best state is but a necessary evil; in its worst state an intolerable one; for when we suffer, or are exposed to the same miseries *by a government*, which we might expect in a country *without government*, our calamities is heightened by reflecting that we furnish the means by which we suffer." -- Thomas Paine From pingster at ilm.com Sat Jun 10 00:28:27 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Fri, 9 Jun 2000 15:28:27 -0700 (PDT) Subject: [Python-Dev] RFC: Including PIL in 1.6 In-Reply-To: <20000609181924.A15728@thyrsus.com> Message-ID: On Fri, 9 Jun 2000, Eric S. Raymond wrote: > Jack Jansen : > > I include PIL in the standard MacPython and Mac users are apparently > > very happy with that [...] > > I think it's time to consider including PIL in the core Python 1.6 release. > I've been following the work being done over there, and I believe the > code has reached a sufficient level of maturity to justify this. I'm +0. Well, perhaps +0.1. I guess what i would really be "+" about is something to the effect of "a popular Linux distribution decides to throw in the .so for PIL". Then it wouldn't really matter to me whether it was in the "real" standard distribution. -- ?!ng "The police are not here to create disorder. They're here to preserve disorder." -- Former Chicago mayor Daley From akuchlin at cnri.reston.va.us Sat Jun 10 03:52:23 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Fri, 9 Jun 2000 21:52:23 -0400 Subject: [Python-Dev] Re: [Image-SIG] RFC: Including PIL in 1.6 In-Reply-To: <20000609181924.A15728@thyrsus.com>; from esr@thyrsus.com on Fri, Jun 09, 2000 at 06:19:24PM -0400 References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> Message-ID: <20000609215223.A23230@newcnri.cnri.reston.va.us> On Fri, Jun 09, 2000 at 06:19:24PM -0400, Eric S. Raymond wrote: >I think it's time to consider including PIL in the core Python 1.6 release. -1 unless Fredrik says there's a C and Python API for extending PIL that he's happy with, in which case it's +0. I've written a few extensions for PIL and it required a fair amount of grubbing around inside of C structures; it isn't clear that the structures will be the same in future versions of PIL. We don't want to add something that people will extend messily, which will then make fixing the API more difficult because of backward compatibility. (Disclaimer: I haven't looked at PIL 1.1 yet; maybe /F has documented an API, or maybe he's pretty sure the data structures will remain the same.) OTOH, given that the Distutils is making good progress on building RPMs for an arbitrary Python package, installing PIL may get much easier in future, reducing the need to add it to the core. But then Paul always yells at me for that argument. :) -- A.M. Kuchling akuchlin at mems-exchange.org Posting "Please send e-mail, since I don't read this group": Poster is rendered illiterate by a simple trepanation. -- Kibo, in the Happynet Manifesto From akuchlin at cnri.reston.va.us Sat Jun 10 04:50:08 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Fri, 9 Jun 2000 22:50:08 -0400 Subject: [Python-Dev] What's New: 2nd draft Message-ID: <20000609225008.A23369@newcnri.cnri.reston.va.us> We've made a second pass at the "What's New in 1.6" document; the only unwritten section is IDLE, and I don't think either Moshe or I use IDLE. Can anyone tell us what the new features are? Again, suggestions on style, forgotten changes, *anything*, are welcomed: http://starship.python.net/crew/amk/python/writing/new-python/ -- A.M. Kuchling http://starship.python.net/crew/amk/ "How about you -- what're you up to?" "Issue #3." -- Vic and Zot, in ZOT! #3 From moshez at math.huji.ac.il Sat Jun 10 07:29:56 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sat, 10 Jun 2000 08:29:56 +0300 (IDT) Subject: [Python-Dev] Japanese Codecs In-Reply-To: <001101bfd25d$f6a0fb80$f2a6b5d4@hagrid> Message-ID: On Fri, 9 Jun 2000, Fredrik Lundh wrote: > > I can't speak for Japanese packagers, but ActiveState will be > > packaging Python in various ways. > > > > BeOpen also has packaging plans :-). > > get in line, guys ;-) I wonder if next we'll see threads on slashdot about "PythonOne is just trying to get on the Python hype. It has nothing to offer except for a trivial installer anyone can write in 5 minutes in Python" (cf: the LinuxOne fiasco) -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com From paul at prescod.net Thu Jun 8 23:32:27 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 08 Jun 2000 23:32:27 +0200 Subject: [Python-Dev] [Fwd: Re: Case sensitivity] Message-ID: <394010EB.DBCBC5FD@prescod.net> Here's a good summary of how XML's case sensitivity came to be. -------- Original Message -------- Subject: Re: Case sensitivity Date: Mon, 3 Apr 2000 12:44:37 -0400 From: Steve DeRose To: xml-dev at lists.oasis-open.org References: Languages with no need for case folding are not much of a problem: the case-folding table or program would merely have no effect on characters belonging to such languages: It would change 26 of our 26 alphabetic code points, and no others. After all, in English we already use lots of characters that don't get case-folded (like digits). The serious problems are subtler: The practical problem that with Unicode your folding table gets really big; on the order of 128Kbytes instead of 256 bytes (barring compresson): this is a pain on small devices (like a cell-phone browser), a pain to load, a pain to implement compression for, etc. The theoretical problem is more important: it's not the caseless languages that pose problems, but the complicated case-folding ones. For example, lots of languages only apply diacritical marks to lower-case letters: for example, "a" may come with 6 different accents, but "A" takes none -- which makes case-folding unreversible. If there are languages that operate the other way as well, then neither fold-to-upper nor fold-to-lower can work for all languages: either way would trash some languages. That said, I think it incumbent on XML *search engines* to support case-folding (as well as decent treatment of accents, types of hyphens, etc) for text content searches: Making English speakers search for "the" | "thE" | "tHe" | "tHE" | "The" | "ThE" | "THe" | "THE" or "[tT][hH][eE] is patently absurd; and besides, there is no user cost to (say) a Japanese speaker if an engine *does* case-fold. Also, many languages use Roman characters occasionally, as for acronyms; so their speakers also pay a price if searches aren't smart enough. And the primary problems with case-folding do not weigh so heavily in the search engine world (for example, AltaVista isn't likely to run their main servers on cell phones for a while yet). From esr at thyrsus.com Sat Jun 10 17:42:27 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Sat, 10 Jun 2000 11:42:27 -0400 Subject: [Python-Dev] Suggestion to Windows- and Mac-library people Message-ID: <20000610114227.A19052@thyrsus.com> Last night I sent the following patch for urllib to python-patches: # Support for launching a browser if os.environ.has_key("BROWSER"): _browsers = string.split(os.environ["BROWSER"], ":") else: _browsers = ["mozilla %s &", "netscape -remote 'openURL(%s)'", "netscape %s &", "lynx %s &", "w3m %s &"] def urlbrowse(url): """Launch a browser, in background, pointed at the given URL. Accept either a string or a parsed URL tuple. Interpret the BROWSER environment variable, if it exists, as a colon-separated list of browser commands to try. """ from urlparse import urlunparse if type(url) == (): url = urlunparse(url) for browser in _browsers: if not os.system('which 1>/dev/null 2>&1 '+string.split(browser)[0]): if os.system((browser % url)) == 0: return 1 return 0 Obviously this is not portable off Unix. Equally obviously it should be possible to do an equivalent thing under Windows (at least). For anybody writing interactive programs in this Web-mad era, this function is just too useful not to have in the toolbox. So this is a nudge to any Windows and Mac wizards on this list -- let's make this function available cross-platform. I've also copied this note to Chip Salzenberg. Perl ought to have this capability too -- and I'm sufficiently serious about that to (gasp) code in Perl myself to make it happen if I have to. -- Eric S. Raymond (Those) who are trying to read the Second Amendment out of the Constitution by claiming it's not an individual right (are) courting disaster by encouraging others to use the same means to eliminate portions of the Constitution they don't like. -- Alan Dershowitz, Harvard Law School From akuchlin at cnri.reston.va.us Sat Jun 10 17:42:50 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Sat, 10 Jun 2000 11:42:50 -0400 Subject: [Python-Dev] Creating curses package: OK? In-Reply-To: <20000610113124.B18982@thyrsus.com>; from esr@thyrsus.com on Sat, Jun 10, 2000 at 11:31:24AM -0400 References: <200006100748.DAA17920@snark.thyrsus.com> <20000610111323.A24895@newcnri.cnri.reston.va.us> <20000610113124.B18982@thyrsus.com> Message-ID: <20000610114250.A25014@newcnri.cnri.reston.va.us> [Redirecting a private conversation to python-dev] On Sat, Jun 10, 2000 at 11:31:24AM -0400, Eric S. Raymond wrote: >I found a workaround. The two curses enhancements (traceback wrapper >and text pad) are now working and ready to be integrated into the >1.6 library. How should we proceed? OK; python-dev has discussed creating a curses package, and reaction seemed favorable. So, my plan of action is: 1) Rename cursesmodule.c to _cursesmodule.c. (Barry, can you do a 'mv' inside the SourceForge CVS repository so the complete history of the module doesn't get lost with the renaming?) 2) Create a Lib/curses/ directory; __init__.py does 'from _curses import *'. 3) The traceback wrapper can then be put into __init__.py, since I assume it's fairly small and everyone should use it. The text pad stuff could then go in another module in the curses package. Seem reasonable to everyone? --amk From esr at thyrsus.com Sat Jun 10 18:01:48 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Sat, 10 Jun 2000 12:01:48 -0400 Subject: [Python-Dev] Creating curses package: OK? In-Reply-To: <20000610114250.A25014@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Sat, Jun 10, 2000 at 11:42:50AM -0400 References: <200006100748.DAA17920@snark.thyrsus.com> <20000610111323.A24895@newcnri.cnri.reston.va.us> <20000610113124.B18982@thyrsus.com> <20000610114250.A25014@newcnri.cnri.reston.va.us> Message-ID: <20000610120148.A19168@thyrsus.com> Andrew Kuchling : > OK; python-dev has discussed creating a curses package, and reaction > seemed favorable. So, my plan of action is: > > 1) Rename cursesmodule.c to _cursesmodule.c. (Barry, can you do a 'mv' > inside the SourceForge CVS repository so the complete history of the > module doesn't get lost with the renaming?) > > 2) Create a Lib/curses/ > directory; __init__.py does 'from _curses import *'. > > 3) The traceback wrapper can then be put into __init__.py, since I > assume it's fairly small and everyone should use it. The text pad > stuff could then go in another module in the curses package. > > Seem reasonable to everyone? Works for me. -- Eric S. Raymond We shall not cease from exploration, and the end of all our exploring will be to arrive where we started and know the place for the first time. -- T.S. Eliot From moshez at math.huji.ac.il Sat Jun 10 19:03:51 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sat, 10 Jun 2000 20:03:51 +0300 (IDT) Subject: [Python-Dev] Creating curses package: OK? In-Reply-To: <20000610114250.A25014@newcnri.cnri.reston.va.us> Message-ID: On Sat, 10 Jun 2000, Andrew Kuchling wrote: > OK; python-dev has discussed creating a curses package, and reaction > seemed favorable. So, my plan of action is: > > 1) Rename cursesmodule.c to _cursesmodule.c. (Barry, can you do a 'mv' > inside the SourceForge CVS repository so the complete history of the > module doesn't get lost with the renaming?) > > 2) Create a Lib/curses/ > directory; __init__.py does 'from _curses import *'. > > 3) The traceback wrapper can then be put into __init__.py, since I > assume it's fairly small and everyone should use it. The text pad > stuff could then go in another module in the curses package. > > Seem reasonable to everyone? I'm +1, except for some nagging doubt about the traceback wrapper. Why not put it in its own (small, granted) module? There are no backward compatabilities to worry here, so there shouldn't be any excuse to put code in __init__.py. But it is so small, that I don't really feel strongly about it. i'll-be-+1-on-the-text-pad-stuff-when-you-get-it-ready-eric-ly y'rs, Z. -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com From esr at thyrsus.com Sat Jun 10 19:24:18 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Sat, 10 Jun 2000 13:24:18 -0400 Subject: [Python-Dev] Creating curses package: OK? In-Reply-To: ; from moshez@math.huji.ac.il on Sat, Jun 10, 2000 at 08:03:51PM +0300 References: <20000610114250.A25014@newcnri.cnri.reston.va.us> Message-ID: <20000610132418.A19442@thyrsus.com> Moshe Zadka : > I'm +1, except for some nagging doubt about the traceback wrapper. > Why not put it in its own (small, granted) module? I don't understand. Whuy do you want to do this? > i'll-be-+1-on-the-text-pad-stuff-when-you-get-it-ready-eric-ly y'rs, Z. You can try it out now: # # Curses extensions -- these are expected to be in the 1.6 Python library # import sys, curses, ascii def wrapper(func, *rest): "Wrapper function that restores normal keyboard/screen behavior on error." res = None try: # Initialize curses stdscr=curses.initscr() # Turn off echoing of keys, and enter cbreak mode, # where no buffering is performed on keyboard input curses.noecho() ; curses.cbreak() # In keypad mode, escape sequences for special keys # (like the cursor keys) will be interpreted and # a special value like curses.KEY_LEFT will be returned stdscr.keypad(1) res = apply(func, (stdscr,) + rest) except: # In the event of an error, restore the terminal # to a sane state. stdscr.keypad(0) curses.echo() ; curses.nocbreak() curses.endwin() # Pass the exception upwards (exc_type, exc_value, exc_traceback) = sys.exc_info() raise exc_type, exc_value, exc_traceback else: # Set everything back to normal stdscr.keypad(0) curses.echo() ; curses.nocbreak() curses.endwin() # Terminate curses return res def rectangle(win, uly, ulx, lry, lrx): "Draw a rectangle." win.vline(uly+1, ulx, curses.ACS_VLINE, lry - uly - 1) win.hline(uly, ulx+1, curses.ACS_HLINE, lrx - ulx - 1) win.hline(lry, ulx+1, curses.ACS_HLINE, lrx - ulx - 1) win.vline(uly+1, lrx, curses.ACS_VLINE, lry - uly - 1) win.addch(uly, ulx, curses.ACS_ULCORNER) win.addch(uly, lrx, curses.ACS_URCORNER) win.addch(lry, lrx, curses.ACS_LRCORNER) win.addch(lry, ulx, curses.ACS_LLCORNER) class textbox: """Editing widget using the interior of a window object. Supports the following Emacs-like key bindings: Ctrl-A Go to left edge of window. Ctrl-B Cursor left, wrapping to previous line if appropriate. Ctrl-D Delete character under cursor. Ctrl-E Go to right edge (nospaces off) or end of line (nospaces on). Ctrl-F Cursor right, wrapping to next line when appropriate. Ctrl-G Terminate, returning the window contents. Ctrl-J Terminate if the window is 1 line, otherwise insert newline. Ctrl-K If line is blank, delete it, otherwise clear to end of line. Ctrl-L Refresh screen Ctrl-N Cursor down; move down one line. Ctrl-O Insert a blank line at cursor location. Ctrl-P Cursor up; move up one line. Move operations do nothing if the cursor is at an edge where the movement is not possible. The following synonyms are supported where possible: KEY_LEFT = Ctrl-B, KEY_RIGHT = Ctrl-F, KEY_UP = Ctrl-P, KEY_DOWN = Ctrl-N """ def __init__(self, win): self.win = win (self.maxy, self.maxx) = win.getmaxyx() self.maxy = self.maxy - 1 self.maxx = self.maxx - 1 self.stripspaces = 1 win.keypad(1) def firstblank(self, y): "Go to the location of the first blank on the given line." (oldy, oldx) = self.win.getyx() self.win.move(y, self.maxx-1) last = self.maxx-1 while 1: if last == 0: break if ascii.ascii(self.win.inch(y, last)) != ascii.SP: last = last + 1 break last = last - 1 self.win.move(oldy, oldx) return last def do_command(self, ch): "Process a single editing command." (y, x) = self.win.getyx() if ascii.isprint(ch): if y < self.maxy or x < self.maxx: # The try-catch ignores the error we trigger from some curses # versions by trying to write into the lowest-rightmost spot # in the self.window. try: self.win.addch(ch) except ERR: pass elif ch == ascii.SOH: # Ctrl-a self.win.move(y, 0) elif ch in (ascii.STX, curses.KEY_LEFT): # Ctrl-b if x > 0: self.win.move(y, x-1) elif y == 0: pass elif self.stripspaces: self.win.move(y-1, self.firstblank(y-1)) else: self.win.move(y-1, self.maxx) elif ch == ascii.EOT: # Ctrl-d self.win.delch() elif ch == ascii.ENQ: # Ctrl-e if self.stripspaces: self.win.move(y, self.firstblank(y, maxx)) else: self.win.move(y, self.maxx) elif ch in (ascii.ACK, curses.KEY_RIGHT): # Ctrl-f if x < self.maxx: self.win.move(y, x+1) elif y == self.maxx: pass else: self.win.move(y+1, 0) elif ch == ascii.BEL: # Ctrl-g return 0 elif ch == ascii.NL: # Ctrl-j if self.maxy == 0: return 0 elif y < self.maxy: self.win.move(y+1, 0) elif ch == ascii.VT: # Ctrl-k if x == 0 and self.firstblank(y) == 0: self.win.deleteln() else: self.win.clrtoeol() elif ch == ascii.FF: # Ctrl-l self.win.refresh() elif ch in (ascii.SO, curses.KEY_DOWN): # Ctrl-n if y < self.maxy: self.win.move(y+1, x) elif ch == ascii.SI: # Ctrl-o self.win.insertln() elif ch in (ascii.DLE, curses.KEY_UP): # Ctrl-p if y > 0: self.win.move(y-1, x) self.win.refresh() return 1 def gather(self): "Collect and return the contents of the window." result = "" for y in range(self.maxy+1): self.win.move(y, 0) stop = self.firstblank(y) if stop == 0 and self.stripspaces: continue for x in range(self.maxx+1): if self.stripspaces and x == stop: break result = result + chr(ascii.ascii(self.win.inch(y, x))) if self.maxy > 0: result = result + "\n" return result def edit(self, validate=None): "Edit in the widget window and collect the results." while 1: ch = self.win.getch() if self.validate: ch = validate(ch) if not self.do_command(ch): break return self.gather() if __name__ == '__main__': def test_editbox(stdscr): win = curses.newwin(4, 9, 15, 20) rectangle(stdscr, 14, 19, 19, 29) stdscr.refresh() return textbox(win).edit() str = wrapper(test_editbox) print str -- Eric S. Raymond The danger (where there is any) from armed citizens, is only to the *government*, not to *society*; and as long as they have nothing to revenge in the government (which they cannot have while it is in their own hands) there are many advantages in their being accustomed to the use of arms, and no possible disadvantage. -- Joel Barlow, "Advice to the Privileged Orders", 1792-93 From bwarsaw at python.org Sat Jun 10 19:58:04 2000 From: bwarsaw at python.org (Barry A. Warsaw) Date: Sat, 10 Jun 2000 13:58:04 -0400 (EDT) Subject: [Python-Dev] Creating curses package: OK? References: <200006100748.DAA17920@snark.thyrsus.com> <20000610111323.A24895@newcnri.cnri.reston.va.us> <20000610113124.B18982@thyrsus.com> <20000610114250.A25014@newcnri.cnri.reston.va.us> Message-ID: <14658.33196.426211.329070@anthem.concentric.net> >>>>> "AK" == Andrew Kuchling writes: AK> 1) Rename cursesmodule.c to _cursesmodule.c. (Barry, can you AK> do a 'mv' inside the SourceForge CVS repository so the AK> complete history of the module doesn't get lost with the AK> renaming?) Not easily (IOW, I have to play several rounds of ugly loginfo games which are hard to get right). Best thing to do would be to submit a SF admin request, which I think since you're a developer you can do. -Barry From moshez at math.huji.ac.il Sat Jun 10 22:12:32 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sat, 10 Jun 2000 23:12:32 +0300 (IDT) Subject: [Python-Dev] Creating curses package: OK? In-Reply-To: <20000610132418.A19442@thyrsus.com> Message-ID: [Moshe Zadka] > I'm +1, except for some nagging doubt about the traceback wrapper. > Why not put it in its own (small, granted) module? [Eric S. Raymond] > I don't understand. Why do you want to do this? I have religious beliefs, and I follow them without thinking. Like "HTTP good, FTP bad". "Python good, C++ bad". Or, in that case "Putting real code in __init__.py bad". (I think that should go in the package style guide, BTW) religions-are-bad-of-course-ly y'rs, Z. -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com From esr at thyrsus.com Sat Jun 10 22:24:40 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Sat, 10 Jun 2000 16:24:40 -0400 Subject: [Python-Dev] Creating curses package: OK? In-Reply-To: ; from moshez@math.huji.ac.il on Sat, Jun 10, 2000 at 11:12:32PM +0300 References: <20000610132418.A19442@thyrsus.com> Message-ID: <20000610162440.A19859@thyrsus.com> Moshe Zadka : > [Eric S. Raymond] > > I don't understand. Why do you want to do this? > > I have religious beliefs, and I follow them without thinking. Like > "HTTP good, FTP bad". "Python good, C++ bad". Or, in that case "Putting > real code in __init__.py bad". I'm even more confused now. Why would the traceback wrapper I'm proposing go in __init__.py? -- Eric S. Raymond The Bible is not my book, and Christianity is not my religion. I could never give assent to the long, complicated statements of Christian dogma. -- Abraham Lincoln From moshez at math.huji.ac.il Sat Jun 10 22:21:57 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sat, 10 Jun 2000 23:21:57 +0300 (IDT) Subject: [Python-Dev] Creating curses package: OK? In-Reply-To: <20000610162440.A19859@thyrsus.com> Message-ID: On Sat, 10 Jun 2000, Eric S. Raymond wrote: > I'm even more confused now. Why would the traceback wrapper I'm proposing > go in __init__.py? Maybe I'm confused here. I thought that was what AMK suggested, no? Where would you want it to go? There are currently 3 planned files in the curses package: __init__.py: apparently not textpad.py: why here? it has nothing to do with text pads _curses.so: certainly not here...you don't want to code in C more then you have to I'm proposing: wrapper.py: put it here i-hope-i-managed-to-confuse-everyone-further-ly y'rs, Z. -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com From akuchlin at cnri.reston.va.us Sun Jun 11 00:25:14 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Sat, 10 Jun 2000 18:25:14 -0400 Subject: [Python-Dev] Creating curses package: OK? In-Reply-To: ; from moshez@math.huji.ac.il on Sat, Jun 10, 2000 at 11:21:57PM +0300 References: <20000610162440.A19859@thyrsus.com> Message-ID: <20000610182514.A25949@newcnri.cnri.reston.va.us> On Sat, Jun 10, 2000 at 11:21:57PM +0300, Moshe Zadka wrote: >Maybe I'm confused here. I thought that was what AMK suggested, no? I did in fact suggest that, since the wrapper is small, and we ideally want every Python/curses application using it, so they don't leave the terminal in a wacky state if they raise an exception. But it's not a big deal and could easily go in wrapper.py, though __init__.py might still import it automatically. --amk From esr at thyrsus.com Sun Jun 11 00:38:06 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Sat, 10 Jun 2000 18:38:06 -0400 Subject: [Python-Dev] Creating curses package: OK? In-Reply-To: <20000610182514.A25949@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Sat, Jun 10, 2000 at 06:25:14PM -0400 References: <20000610162440.A19859@thyrsus.com> <20000610182514.A25949@newcnri.cnri.reston.va.us> Message-ID: <20000610183806.A20280@thyrsus.com> Andrew Kuchling : > On Sat, Jun 10, 2000 at 11:21:57PM +0300, Moshe Zadka wrote: > >Maybe I'm confused here. I thought that was what AMK suggested, no? > > I did in fact suggest that, since the wrapper is small, and we ideally > want every Python/curses application using it, so they don't leave the > terminal in a wacky state if they raise an exception. But it's not a > big deal and could easily go in wrapper.py, though __init__.py might > still import it automatically. The traceback wrapper is not the only Python code I'll be supplying... -- Eric S. Raymond I do not find in orthodox Christianity one redeeming feature. -- Thomas Jefferson From gstein at lyra.org Sun Jun 11 00:33:20 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 10 Jun 2000 15:33:20 -0700 Subject: [Python-Dev] Creating curses package: OK? In-Reply-To: <20000610182514.A25949@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Sat, Jun 10, 2000 at 06:25:14PM -0400 References: <20000610162440.A19859@thyrsus.com> <20000610182514.A25949@newcnri.cnri.reston.va.us> Message-ID: <20000610153320.A19484@lyra.org> On Sat, Jun 10, 2000 at 06:25:14PM -0400, Andrew Kuchling wrote: > On Sat, Jun 10, 2000 at 11:21:57PM +0300, Moshe Zadka wrote: > >Maybe I'm confused here. I thought that was what AMK suggested, no? > > I did in fact suggest that, since the wrapper is small, and we ideally > want every Python/curses application using it, so they don't leave the > terminal in a wacky state if they raise an exception. But it's not a > big deal and could easily go in wrapper.py, though __init__.py might > still import it automatically. Yes, I think we'd want it to import the stuff; just organizationally to place the source code outside of __init__.py I'd agree that real code should not go into __init__. It should preload some standard modules, maybe expose some symbols, but otherwise no code. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Sun Jun 11 01:30:13 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 10 Jun 2000 16:30:13 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses __init__.py,NONE,1.1 wrapper.py,NONE,1.1 In-Reply-To: <200006102306.QAA18088@slayer.i.sourceforge.net>; from akuchling@slayer.i.sourceforge.net on Sat, Jun 10, 2000 at 04:06:55PM -0700 References: <200006102306.QAA18088@slayer.i.sourceforge.net> Message-ID: <20000610163013.B19484@lyra.org> On Sat, Jun 10, 2000 at 04:06:55PM -0700, A.M. Kuchling wrote: >... > def wrapper(func, *rest): > """Wrapper function that initializes curses and calls another function, > restoring normal keyboard/screen behavior on error. > The callable object 'func' is then passed the main window 'stdscr' > as its first argument, followed by any other arguments passed to > wrapper(). > """ > > res = None > try: > # Initialize curses > stdscr=curses.initscr() > # Turn off echoing of keys, and enter cbreak mode, > # where no buffering is performed on keyboard input > curses.noecho() ; curses.cbreak() > > # In keypad mode, escape sequences for special keys > # (like the cursor keys) will be interpreted and > # a special value like curses.KEY_LEFT will be returned > stdscr.keypad(1) > > res = apply(func, (stdscr,) + rest) > except: > # In the event of an error, restore the terminal > # to a sane state. > stdscr.keypad(0) > curses.echo() ; curses.nocbreak() > curses.endwin() > # Pass the exception upwards > (exc_type, exc_value, exc_traceback) = sys.exc_info() > raise exc_type, exc_value, exc_traceback > else: > # Set everything back to normal > stdscr.keypad(0) > curses.echo() ; curses.nocbreak() > curses.endwin() # Terminate curses > > return res This is too complicated. It should read: ... return apply(func, (stdscr,) + rest) finally: # Set everything back to normal stdscr.keypad(0) curses.echo() curses.nocbreak() curses.endwin() Andrew: can you make this change? Separate from the above simplification, it is important to note: exc_type, exc_value, exc_traceback = sys.exc_info() raise exc_type, exc_value, exc_traceback and raise are equivalent in (most) function. The difference is that the former places the traceback into local variable storage (exc_traceback) which then introduces a reference loop. Whenever sys.exc_info() is used, it is very important to watch out for loops caused by the traceback object. "del exc_traceback" is very handy :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Sun Jun 11 01:33:05 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 10 Jun 2000 16:33:05 -0700 Subject: [Python-Dev] curses wrapper checkin In-Reply-To: <20000610163013.B19484@lyra.org>; from gstein@lyra.org on Sat, Jun 10, 2000 at 04:30:13PM -0700 References: <200006102306.QAA18088@slayer.i.sourceforge.net> <20000610163013.B19484@lyra.org> Message-ID: <20000610163305.C19484@lyra.org> On Sat, Jun 10, 2000 at 04:30:13PM -0700, Greg Stein wrote: > On Sat, Jun 10, 2000 at 04:06:55PM -0700, A.M. Kuchling wrote: > >... > > def wrapper(func, *rest): > > """Wrapper function that initializes curses and calls another function, > > restoring normal keyboard/screen behavior on error. > > The callable object 'func' is then passed the main window 'stdscr' > > as its first argument, followed by any other arguments passed to > > wrapper(). > > """ > > > > res = None Oh. This line can disappear, too. Cheers, -g -- Greg Stein, http://www.lyra.org/ From akuchlin at cnri.reston.va.us Sun Jun 11 01:33:12 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Sat, 10 Jun 2000 19:33:12 -0400 Subject: [Python-Dev] Creating curses package: done In-Reply-To: <14658.33196.426211.329070@anthem.concentric.net>; from bwarsaw@python.org on Sat, Jun 10, 2000 at 01:58:04PM -0400 References: <200006100748.DAA17920@snark.thyrsus.com> <20000610111323.A24895@newcnri.cnri.reston.va.us> <20000610113124.B18982@thyrsus.com> <20000610114250.A25014@newcnri.cnri.reston.va.us> <14658.33196.426211.329070@anthem.concentric.net> Message-ID: <20000610193312.A26098@newcnri.cnri.reston.va.us> On Sat, Jun 10, 2000 at 01:58:04PM -0400, Barry A. Warsaw wrote: >which are hard to get right). Best thing to do would be to submit a >SF admin request, which I think since you're a developer you can do. I've submitted a support request to rename the file, and checked in the Lib/curses subdirectory, containing only __init__.py and wrapper.py, along with the required Makefile.in and Setup.in changes. If you compile the CVS tree right now, you'll need to rename cursesmodule.c to _cursesmodule.c manually. The textbox stuff poses two problems. First, it requires ascii.py, and wasn't the decision to wait for GvR on adding that module? Second, Eric, I'm not sure what you want as the module name for the textbox stuff: textbox.py? Your call... (I'll check it in, and if ascii.py is vetoed, it can be rewritten to not require ascii.py, or we can have curses.ascii.) --amk From esr at thyrsus.com Sun Jun 11 01:48:22 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Sat, 10 Jun 2000 19:48:22 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses __init__.py,NONE,1.1 wrapper.py,NONE,1.1 In-Reply-To: <20000610163013.B19484@lyra.org>; from gstein@lyra.org on Sat, Jun 10, 2000 at 04:30:13PM -0700 References: <200006102306.QAA18088@slayer.i.sourceforge.net> <20000610163013.B19484@lyra.org> Message-ID: <20000610194822.A882@thyrsus.com> Greg Stein : > This is too complicated. It should read: > > ... > return apply(func, (stdscr,) + rest) > finally: > # Set everything back to normal > stdscr.keypad(0) > curses.echo() > curses.nocbreak() > curses.endwin() > > Andrew: can you make this change? I'll test it and make the change in my masters if it works for both cases. I haven't actually shipped the box of goodies yet... -- Eric S. Raymond Alcohol still kills more people every year than all `illegal' drugs put together, and Prohibition only made it worse. Oppose the War On Some Drugs! From esr at thyrsus.com Sun Jun 11 01:50:27 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Sat, 10 Jun 2000 19:50:27 -0400 Subject: [Python-Dev] Creating curses package: done In-Reply-To: <20000610193312.A26098@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Sat, Jun 10, 2000 at 07:33:12PM -0400 References: <200006100748.DAA17920@snark.thyrsus.com> <20000610111323.A24895@newcnri.cnri.reston.va.us> <20000610113124.B18982@thyrsus.com> <20000610114250.A25014@newcnri.cnri.reston.va.us> <14658.33196.426211.329070@anthem.concentric.net> <20000610193312.A26098@newcnri.cnri.reston.va.us> Message-ID: <20000610195027.B882@thyrsus.com> Andrew Kuchling : > The textbox stuff poses two problems. First, it requires ascii.py, > and wasn't the decision to wait for GvR on adding that module? > Second, Eric, I'm not sure what you want as the module name for the > textbox stuff: textbox.py? Your call... (I'll check it in, and if > ascii.py is vetoed, it can be rewritten to not require ascii.py, or > we can have curses.ascii.) I thought it was going to become part of curses from the user's point of view, so that "import curses" brings it in. That seemed to be the intent of the request at the end of the curses HOWTO. -- Eric S. Raymond "Taking my gun away because I might shoot someone is like cutting my tongue out because I might yell `Fire!' in a crowded theater." -- Peter Venetoklis From akuchlin at cnri.reston.va.us Sun Jun 11 01:44:54 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Sat, 10 Jun 2000 19:44:54 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses __init__.py,NONE,1.1 wrapper.py,NONE,1.1 In-Reply-To: <20000610194822.A882@thyrsus.com>; from esr@thyrsus.com on Sat, Jun 10, 2000 at 07:48:22PM -0400 References: <200006102306.QAA18088@slayer.i.sourceforge.net> <20000610163013.B19484@lyra.org> <20000610194822.A882@thyrsus.com> Message-ID: <20000610194454.B26098@newcnri.cnri.reston.va.us> On Sat, Jun 10, 2000 at 07:48:22PM -0400, Eric S. Raymond wrote: >I'll test it and make the change in my masters if it works for both >cases. I haven't actually shipped the box of goodies yet... Already tested and checked in. If you make other changes, just ship me the new version. (Oh, I forgot about the stupid legal stuff; you should probably send wrapper.py and textbox.py to patches at python.org with the requisite legal disclaimer.) --amk From esr at thyrsus.com Sun Jun 11 01:59:31 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Sat, 10 Jun 2000 19:59:31 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses __init__.py,NONE,1.1 wrapper.py,NONE,1.1 In-Reply-To: <20000610194454.B26098@newcnri.cnri.reston.va.us>; from akuchlin@cnri.reston.va.us on Sat, Jun 10, 2000 at 07:44:54PM -0400 References: <200006102306.QAA18088@slayer.i.sourceforge.net> <20000610163013.B19484@lyra.org> <20000610194822.A882@thyrsus.com> <20000610194454.B26098@newcnri.cnri.reston.va.us> Message-ID: <20000610195931.A985@thyrsus.com> Andrew Kuchling : > On Sat, Jun 10, 2000 at 07:48:22PM -0400, Eric S. Raymond wrote: > >I'll test it and make the change in my masters if it works for both > >cases. I haven't actually shipped the box of goodies yet... > > Already tested and checked in. If you make other changes, just ship > me the new version. Well, dang. Didn't you want me to document it first? :-) -- Eric S. Raymond Rifles, muskets, long-bows and hand-grenades are inherently democratic weapons. A complex weapon makes the strong stronger, while a simple weapon -- so long as there is no answer to it -- gives claws to the weak. -- George Orwell, "You and the Atom Bomb", 1945 From akuchlin at cnri.reston.va.us Sun Jun 11 01:51:30 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Sat, 10 Jun 2000 19:51:30 -0400 Subject: [Python-Dev] Creating curses package: done In-Reply-To: <20000610195027.B882@thyrsus.com>; from esr@thyrsus.com on Sat, Jun 10, 2000 at 07:50:27PM -0400 References: <200006100748.DAA17920@snark.thyrsus.com> <20000610111323.A24895@newcnri.cnri.reston.va.us> <20000610113124.B18982@thyrsus.com> <20000610114250.A25014@newcnri.cnri.reston.va.us> <14658.33196.426211.329070@anthem.concentric.net> <20000610193312.A26098@newcnri.cnri.reston.va.us> <20000610195027.B882@thyrsus.com> Message-ID: <20000610195130.C26098@newcnri.cnri.reston.va.us> On Sat, Jun 10, 2000 at 07:50:27PM -0400, Eric S. Raymond wrote: >I thought it was going to become part of curses from the user's point >of view, so that "import curses" brings it in. That seemed to be the >intent of the request at the end of the curses HOWTO. Ooh, no; that text is saying that an editor would make a good example to put in the HOWTO. I'd rather have the curses module contain only a fairly close mapping of the C API, and extensions written in Python would be in submodules like curses.editor, curses.textbox, whatever. Similar to how socketmodule.c is a thin veneer over the BSD socket API, and the spiffy extensions are in asyncore.py, httplib.py, &c. --amk From nhodgson at bigpond.net.au Sun Jun 11 02:04:53 2000 From: nhodgson at bigpond.net.au (Neil Hodgson) Date: Sun, 11 Jun 2000 10:04:53 +1000 Subject: [Python-Dev] Suggestion to Windows- and Mac-library people References: <20000610114227.A19052@thyrsus.com> Message-ID: <016301bfd338$ab8458f0$e3cb8490@neil> > Obviously this is not portable off Unix. Equally obviously it should > be possible to do an equivalent thing under Windows (at least). For > anybody writing interactive programs in this Web-mad era, this > function is just too useful not to have in the toolbox. So this is a > nudge to any Windows and Mac wizards on this list -- let's make this > function available cross-platform. The most common way on Windows to launch the user's preferred browser with an URL would be: >>> import win32api >>> win32api.ShellExecute(0,None,"http://www.python.org",None,"",1) # Note to Mark - more of the parameters should be optional However this, like most process control stuff, requires the Win32 extensions, not the base Python distribution. Trying to hack this up with os.system would be unpleasant. ShellExecute knows when to do icky stuff like use DDE to open the correct URL. Does this type of UI operation really belong in urllib? Neil From esr at thyrsus.com Sun Jun 11 03:26:08 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Sat, 10 Jun 2000 21:26:08 -0400 Subject: [Python-Dev] Suggestion to Windows- and Mac-library people In-Reply-To: <016301bfd338$ab8458f0$e3cb8490@neil>; from nhodgson@bigpond.net.au on Sun, Jun 11, 2000 at 10:04:53AM +1000 References: <20000610114227.A19052@thyrsus.com> <016301bfd338$ab8458f0$e3cb8490@neil> Message-ID: <20000610212608.A1109@thyrsus.com> Neil Hodgson : > Does this type of UI operation really belong in urllib? It fetches the contents of an URL for inspection. Where else would you put it? -- Eric S. Raymond It would be thought a hard government that should tax its people one tenth part. -- Benjamin Franklin From nhodgson at bigpond.net.au Sun Jun 11 03:51:34 2000 From: nhodgson at bigpond.net.au (Neil Hodgson) Date: Sun, 11 Jun 2000 11:51:34 +1000 Subject: [Python-Dev] Suggestion to Windows- and Mac-library people References: <20000610114227.A19052@thyrsus.com> <016301bfd338$ab8458f0$e3cb8490@neil> <20000610212608.A1109@thyrsus.com> Message-ID: <01af01bfd347$937b3fd0$e3cb8490@neil> > > Does this type of UI operation really belong in urllib? > > It fetches the contents of an URL for inspection. Where else would you put it? os? Or a submodule of os. The current os has a bunch of executable-oriented process creation and managment functions. On Macintosh and Windows, data-oriented process creation would be useful. os.process.open("http://www.python.org") os.process.print("c:\src\map.png") Neil From esr at thyrsus.com Sun Jun 11 04:14:56 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Sat, 10 Jun 2000 22:14:56 -0400 Subject: [Python-Dev] Suggestion to Windows- and Mac-library people In-Reply-To: <01af01bfd347$937b3fd0$e3cb8490@neil>; from nhodgson@bigpond.net.au on Sun, Jun 11, 2000 at 11:51:34AM +1000 References: <20000610114227.A19052@thyrsus.com> <016301bfd338$ab8458f0$e3cb8490@neil> <20000610212608.A1109@thyrsus.com> <01af01bfd347$937b3fd0$e3cb8490@neil> Message-ID: <20000610221456.A1223@thyrsus.com> Neil Hodgson : > > It fetches the contents of an URL for inspection. Where else would you > put it? > > os? > Or a submodule of os. > > The current os has a bunch of executable-oriented process creation and > managment functions. On Macintosh and Windows, data-oriented process > creation would be useful. I don't really care where it lives, and will cheerfully defer to those with religious beliefs about the namespace ;-). If it's not obvious, this flurry of library suggestions you've been seeing from me lately all come straight out of the CML2 project. I use the urlbrowse() function to make URLs in help windows into live objects that you can click on. -- Eric S. Raymond This would be the best of all possible worlds, if there were no religion in it. -- John Adams, in a letter to Thomas Jefferson. From esr at snark.thyrsus.com Sun Jun 11 06:29:37 2000 From: esr at snark.thyrsus.com (Eric S. Raymond) Date: Sun, 11 Jun 2000 00:29:37 -0400 Subject: [Python-Dev] Greg Stein's correction broke my traceback wrapper Message-ID: <200006110429.AAA01719@snark.thyrsus.com> Greg Stein's correction broke my traceback wrapper. I now do *not* see a traceback on an exit due to Python runtime errors. I don't know why this is. -- Eric S. Raymond No one who's seen it in action can say the phrase "government help" without either laughing or crying. From gstein at lyra.org Sun Jun 11 07:44:30 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 10 Jun 2000 22:44:30 -0700 Subject: [Python-Dev] Greg Stein's correction broke my traceback wrapper In-Reply-To: <200006110429.AAA01719@snark.thyrsus.com>; from esr@snark.thyrsus.com on Sun, Jun 11, 2000 at 12:29:37AM -0400 References: <200006110429.AAA01719@snark.thyrsus.com> Message-ID: <20000610224430.E19484@lyra.org> On Sun, Jun 11, 2000 at 12:29:37AM -0400, Eric S. Raymond wrote: > Greg Stein's correction broke my traceback wrapper. I now do *not* > see a traceback on an exit due to Python runtime errors. I don't know > why this is. That's strange... a "finally" does not munge tracebacks at all. An exception from a lower level should propagate outwards without interference. Do you still have an "except:" in your code somewhere? (that could be eating your exception) Maybe your test case isn't failing as expected :-) If you'd like, post a copy of the test, and we can debug the wrapper and/or test. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Sun Jun 11 13:01:50 2000 From: gstein at lyra.org (Greg Stein) Date: Sun, 11 Jun 2000 04:01:50 -0700 Subject: [Python-Dev] more on httplib In-Reply-To: ; from gstein@lyra.org on Sat, Jun 03, 2000 at 04:13:55PM -0700 References: Message-ID: <20000611040150.K19484@lyra.org> All of the work below has been completed except for the errno==32 stuff. Module: http://www.lyra.org/greg/python/httplib.py History: http://www.lyra.org/cgi-bin/viewcvs.cgi/gjspy/httplib.py/ There are three items left, that I know of: 1) need doc for new stuff 2) need new test cases 3) I want to remove a "feature" of the old HTTP class. This would be a change in behavior, but (IMO) minor. Specifically, if the Status-Line is malformed, the old httplib.py would return (-1, , None) and store into self.file. Nominally, that file object allows a client to read more data from the socket after the parse problem on the malformed Status-Line. I think it is useless, unused by any clients out there, and it causes me pain to provide it :-) I'd like to just store None into self.file Thoughts? Comments? I'd like to get this thing into Python RSN. Cheers, -g On Sat, Jun 03, 2000 at 04:13:55PM -0700, Greg Stein wrote: > I would like to propose a few changes to the (new) httplib: > > *) drop HTTPS() -- this class isn't in 1.5.2, so there isn't a reason to > provide backwards-compat for it > > *) revamp the pipeline support: > > - record the "last response object" ... when a new getreply() is done, > then we store the "last" into response.prior > - reading of the "HTTP/1.1 " line is deferred, and > performed by the response object > - the read of that line is lazy > - if the response line is read *before* the "prior" response (if any) > is "closed", then an exception is raised: ResponseNotReady > > *) address some of Moshe's concerns: > > - use class-based exceptions > - clarify that HTTPConnection is designed for *blocking* sockets > - conn.close() followed by conn.send() will reopen the socket. This > could lead to programming errors. I'll add a class-based default flag > to disable this behavior. > - in request(), we check for errno==32 ... what to do on Windows? > > > I will implement these changes in small chunks so that each can be > reviewed in my CVS repository. The history is available at: > > http://www.lyra.org/cgi-bin/viewcvs.cgi/gjspy/httplib.py/ -- Greg Stein, http://www.lyra.org/ From moshez at math.huji.ac.il Sun Jun 11 13:58:28 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Sun, 11 Jun 2000 14:58:28 +0300 (IDT) Subject: [Python-Dev] more on httplib In-Reply-To: <20000611040150.K19484@lyra.org> Message-ID: On Sun, 11 Jun 2000, Greg Stein wrote: > 3) I want to remove a "feature" of the old HTTP class. This would be a > change in behavior, but (IMO) minor. Specifically, if the Status-Line > is malformed, the old httplib.py would return (-1, , > None) and store into self.file. Nominally, > that file object allows a client to read more data from the socket > after the parse problem on the malformed Status-Line. I think it is > useless, unused by any clients out there, and it causes me pain to > provide it :-) I'd like to just store None into self.file What do the old docs say about this? \begin{methoddesc}{getfile}{} Return a file object from which the data returned by the server can be read, using the \method{read()}, \method{readline()} or \method{readlines()} methods. \end{methoddesc} So why not put a "dummy" file: one whose read(), readline() or readlines() act as if it was at EOF? (IOW, the Pythonic equivalent of open("/dev/null")) -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com From akuchlin at cnri.reston.va.us Sun Jun 11 15:19:48 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Sun, 11 Jun 2000 09:19:48 -0400 Subject: [Python-Dev] Greg Stein's correction broke my traceback wrapper In-Reply-To: <20000610224430.E19484@lyra.org>; from gstein@lyra.org on Sat, Jun 10, 2000 at 10:44:30PM -0700 References: <200006110429.AAA01719@snark.thyrsus.com> <20000610224430.E19484@lyra.org> Message-ID: <20000611091948.A27835@newcnri.cnri.reston.va.us> On Sat, Jun 10, 2000 at 10:44:30PM -0700, Greg Stein wrote: >On Sun, Jun 11, 2000 at 12:29:37AM -0400, Eric S. Raymond wrote: >> Greg Stein's correction broke my traceback wrapper. >If you'd like, post a copy of the test, and we can debug the wrapper >and/or test. I'll leave it to the two of you to figure out what's going on and submit a corrected version, if necessary. I did test the simplified version and it seemed fine, though maybe there's a subtle problem. I'm off to CA, and will be back on Wednesday. (Mmmm... hours of plane hacking...) --amk From gstein at lyra.org Sun Jun 11 21:18:26 2000 From: gstein at lyra.org (Greg Stein) Date: Sun, 11 Jun 2000 12:18:26 -0700 Subject: [Python-Dev] more on httplib In-Reply-To: ; from moshez@math.huji.ac.il on Sun, Jun 11, 2000 at 02:58:28PM +0300 References: <20000611040150.K19484@lyra.org> Message-ID: <20000611121826.L19484@lyra.org> On Sun, Jun 11, 2000 at 02:58:28PM +0300, Moshe Zadka wrote: > On Sun, 11 Jun 2000, Greg Stein wrote: > > > 3) I want to remove a "feature" of the old HTTP class. This would be a > > change in behavior, but (IMO) minor. Specifically, if the Status-Line > > is malformed, the old httplib.py would return (-1, , > > None) and store into self.file. Nominally, > > that file object allows a client to read more data from the socket > > after the parse problem on the malformed Status-Line. I think it is > > useless, unused by any clients out there, and it causes me pain to > > provide it :-) I'd like to just store None into self.file > > What do the old docs say about this? > > \begin{methoddesc}{getfile}{} > Return a file object from which the data returned by the server can be > read, using the \method{read()}, \method{readline()} or > \method{readlines()} methods. > \end{methoddesc} > > So why not put a "dummy" file: one whose read(), readline() or readlines() > act as if it was at EOF? > (IOW, the Pythonic equivalent of open("/dev/null")) Sure, I can put different things there, but that would also be a change in semantics. The backwards compat class, HTTP, preserves the API completely -- even down to how it reacts in error situations. (although, it *can* raise errors that it didn't before, when you use methods in the wrong order) I'd like to make a change in the semantics for this particular error condition. Where a client used to be able to do: errcode, errmsg, hdrs = h.getreply() if errcode == -1: file = h.getfile() print 'ERROR: some kind of error occurred' print ' partial read:', `errmsg` print ' next 100 bytes:', `file.read(100)` I'd like to eliminate that "next 100 bytes" ability, and just close the socket when a protocol error occurs. Before making a change in behavior for this (central) class, I'd like to get some feedback. Some voting? Cheers, -g -- Greg Stein, http://www.lyra.org/ From andy at robanal.demon.co.uk Mon Jun 12 13:45:57 2000 From: andy at robanal.demon.co.uk (Andy Robinson) Date: Mon, 12 Jun 2000 12:45:57 +0100 Subject: [Python-Dev] Japanese Codecs In-Reply-To: <20000610160032.0004A1CFA2@dinsdale.python.org> Message-ID: > > Message: 2 > From: "David Ascher" > To: "Python Developers @ python.org" > Subject: RE: [Python-Dev] Japanese Codecs > Date: Fri, 9 Jun 2000 11:54:03 -0700 > charset="US-ASCII" > > > I just wish that these packagers actually become a reality > > some day... the concept is good, but there currently seem to > > be no volunteers or companies jumping in :-( > > I can't speak for Japanese packagers, but ActiveState will be packaging > Python in various ways. > The handful of Python users who know some Japanese are kind of busy at the moment, and the codec work takes more than a night or two; I was hoping to tackle it myself, but as the only Python startup without any venture funding, it is hard to clear aside the time without a customer; and it also needs C skills. I believe we should try and put resources together to fund this work and ensure it gets done this year. I can tell you that HP are now well and truly out of the picture as a sponsor. AFAIK the organisations who should talk are at least... PythonLabs/BeOpen ActiveState Digital Garage PythonWare / Secret Labs ??? (not sure how rapid their global plans are) ReportLab Are there any others? Please get in touch with me... feeling-rather-guilty-as-i18n-sig-coordinator-ly-yrs, Andy Robinson From mal at lemburg.com Mon Jun 12 14:51:11 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 12 Jun 2000 14:51:11 +0200 Subject: [Python-Dev] Japanese Codecs References: Message-ID: <3944DCBF.34DA9E4B@lemburg.com> Andy Robinson wrote: > > > > I just wish that these packagers actually become a reality > > > some day... the concept is good, but there currently seem to > > > be no volunteers or companies jumping in :-( > > > > I can't speak for Japanese packagers, but ActiveState will be packaging > > Python in various ways. > > > The handful of Python users who know some Japanese are kind of busy at the > moment, and the codec work takes more than a night or two; I was hoping to > tackle it myself, but as the only Python startup without any venture > funding, it is hard to clear aside the time without a customer; and it also > needs C skills. > > I believe we should try and put resources together to fund this work and > ensure it gets done this year. I can tell you that HP are now well and > truly out of the picture as a sponsor. How come ...wheren't they the initial sponsors for the i18n of Python ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gstein at lyra.org Mon Jun 12 20:19:07 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 12 Jun 2000 11:19:07 -0700 Subject: [Python-Dev] Japanese Codecs In-Reply-To: ; from andy@robanal.demon.co.uk on Mon, Jun 12, 2000 at 12:45:57PM +0100 References: <20000610160032.0004A1CFA2@dinsdale.python.org> Message-ID: <20000612111907.B19484@lyra.org> On Mon, Jun 12, 2000 at 12:45:57PM +0100, Andy Robinson wrote: > > Message: 2 > > From: "David Ascher" > > To: "Python Developers @ python.org" > > Subject: RE: [Python-Dev] Japanese Codecs > > Date: Fri, 9 Jun 2000 11:54:03 -0700 > > charset="US-ASCII" > > > > > I just wish that these packagers actually become a reality > > > some day... the concept is good, but there currently seem to > > > be no volunteers or companies jumping in :-( > > > > I can't speak for Japanese packagers, but ActiveState will be packaging > > Python in various ways. > > > The handful of Python users who know some Japanese are kind of busy at the > moment, and the codec work takes more than a night or two; I was hoping to > tackle it myself, but as the only Python startup without any venture > funding, it is hard to clear aside the time without a customer; and it also > needs C skills. > > I believe we should try and put resources together to fund this work and > ensure it gets done this year. Um... why is it incumbent upon "us" (for whatever definition of "us" you want to apply :-) to find/fund the work for the Japanese codecs? Why isn't this up to the people who want/need it? Yes, being proactive is a very nice thing to do, but I don't see that we must be, in this case. > I can tell you that HP are now well and truly out of the picture as a > sponsor. eh? What's going on with that? Cheers, -g -- Greg Stein, http://www.lyra.org/ From bwarsaw at python.org Mon Jun 12 22:53:10 2000 From: bwarsaw at python.org (Barry A. Warsaw) Date: Mon, 12 Jun 2000 16:53:10 -0400 (EDT) Subject: [Python-Dev] Towards 1.6 Final Message-ID: <14661.19894.465676.770545@anthem.concentric.net> Okay, let me just preface this by saying none of the following has been blessed by Guido in any way. I'm sure he's still getting nice and tan and drinking exotic tropical alcohol-based beverages, and not thinking about Python one little bit. :) Fred and Jeremy and I had a meeting today and thought about a schedule /we'd/ like to see for Python 1.6 final. This may or may not be feasible but I throw it out here for discussion anyway. The O'Reilly Open Source conference[1] starts July 17th and it would be a nice target to release 1.6 final on the 14th, the Friday before the conference. We all plan on being there.n What do we need to do to hit this target? If we figure a 2 week beta cycle, 1.6beta1 would have to be released June 30, with probably the last alpha on June 23. This is a tight schedule; is it even feasible?. Looking at Andrew's TODO list[2], here's what we came up with: - import hooks revamped (push this to 1.7) - update docos to match 1.6 changes (Fred is going to integrate what's sitting in his inbox) - document more undocumented modules (codes - done; unicodedata - needs work; mmap & pyexpat - Fred to integrate; curses - needs updates; regrtest - push to 1.7, see below) - Unicode: Compress the size of unicodedatabase (waiting for Chris Tismer patches?) - Unicode: Write \N{SMILEY} codec for Unicode (Bill Tutt has a patch, but none of us know what the state of this is -- is it crucial anyway?). - Unicode: the various XXX items in Misc/unicode.txt (we didn't actually find such outstanding issues in this file). - Delete obsolete subdirs in Demo/ directory (done) - Refurbish Demo subdirs to be properly documented, match modern coding style, etc. (???) - Fix ./ld_so_aix installation problem on AIX (anybody know more about this???) - Make test/regrtest.py more usable outside of the Python test suite & document it. (push to 1.7) - Conservative GC, of cycles (this is basically done but needs a lot more testing) - Changes to PyExpat module (Fred says this is done) - Test the hell out of SRE. (waiting for /F's complete implementation) - enable threads by default if OS supports it - integrate intl/gettext module - clear the patches and bugs backlog As we saw it the most critical things that need to get done are testing the GC stuff and the SRE module. Of those, the most critical is SRE since AFAIK, we're still waiting for the final complete code from /F. I could be wrong about that. The last three weren't on Andrew's list. I'm on the hook for enabling threads support by default and integrating intl/gettext. I think those will just be a couple of days work. The final one requires Us to go through the outstanding bug and patches lists and address the critical bugs. Thoughts? What have I missed? -Barry [1] http://conferences.oreilly.com/oscon2000/ [2] http://starship.python.net/crew/amk/python/1.6-jobs.html From gstein at lyra.org Tue Jun 13 02:32:14 2000 From: gstein at lyra.org (Greg Stein) Date: Mon, 12 Jun 2000 17:32:14 -0700 Subject: [Python-Dev] Towards 1.6 Final In-Reply-To: <14661.19894.465676.770545@anthem.concentric.net>; from bwarsaw@python.org on Mon, Jun 12, 2000 at 04:53:10PM -0400 References: <14661.19894.465676.770545@anthem.concentric.net> Message-ID: <20000612173214.F19484@lyra.org> On Mon, Jun 12, 2000 at 04:53:10PM -0400, Barry A. Warsaw wrote: > ... disclaimers applied ... > > - import hooks revamped (push this to 1.7) The latest thought had two items here: 1) incorporate feedback into imputil.py. [ the feedback is visible at the end of the most recent version: http://www.lyra.org/cgi-bin/viewcvs.cgi/gjspy/imputil.py/ ] 2) drop imputil into the standard library, but don't go down the "replace Python's default mechanism with imputil" Essentially, this gets imputil out there and usable, but it doesn't directly impact Python's operation in 1.6. >... > - Unicode: Write \N{SMILEY} codec for Unicode (Bill Tutt has a patch, > but none of us know what the state of this is -- is it crucial > anyway?). Bill posted some patches. Little feedback. He will be reposting an updated patch. >... > - Conservative GC, of cycles (this is basically done but needs a lot > more testing) I would recommend doing this in small, reviewable steps. I believe there are a lot of "framework" changes that can occur without actually changing Python itself. After that first round, which will make adding GC easier, then we can do Step 2 and add the real GC stuff. >... New item: - replace httplib.py with Greg's new module. plus docs/test. >... > As we saw it the most critical things that need to get done are > testing the GC stuff and the SRE module. Of those, the most critical > is SRE since AFAIK, we're still waiting for the final complete code > from /F. I could be wrong about that. I believe his recent patch (which AMK applied) brings it up to "current". Cheers, -g -- Greg Stein, http://www.lyra.org/ From Vladimir.Marangozov at inrialpes.fr Tue Jun 13 04:37:23 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Tue, 13 Jun 2000 04:37:23 +0200 (CEST) Subject: [Python-Dev] Towards 1.6 Final In-Reply-To: <14661.19894.465676.770545@anthem.concentric.net> from "Barry A. Warsaw" at Jun 12, 2000 04:53:10 PM Message-ID: <200006130237.EAA10373@python.inrialpes.fr> Barry A. Warsaw wrote: > > - document more undocumented modules (codes - done; unicodedata - > needs work; mmap & pyexpat - Fred to integrate; curses - needs > updates; regrtest - push to 1.7, see below) + Write missing bits in the extend/embed docs (me) Also, last time I ran the 1.6 alpha on AIX, test_mmap failed. I have to take a closer look at this... > - Fix ./ld_so_aix installation problem on AIX (anybody know more about > this???) Yes, AMK, Greg Ward and I know more. It's more an automation (path) problem for building C extensions with distutils than an installation problem per se. Some time ago, I saw a workaround checked in by Greg. If this is still judged as a problem, I'd like to hear about it. This is a minor thing. I have yet to install & run the distutil package on AIX, though, and see what happens. > - enable threads by default if OS supports it Who's going to champion this? I recall Greg Stein volunteering for it ;) (or for something related) > - Test the hell out of SRE. (waiting for /F's complete implementation) ... > As we saw it the most critical things that need to get done are > testing the GC stuff and the SRE module. Of those, the most critical > is SRE since AFAIK, we're still waiting for the final complete code > from /F. I could be wrong about that. It thas been my impression that people are pushing /F for SRE deliveries, but he feels uncomfortable with a number of Unicode compromises (affecting the SRE code and/or design???) and has some implementation hesitations. Add to this the pression of the recent PythonWorks' release. In this context, if there's something to be finished, it would be nice to stop pushing him and help him finishing this project. Unfortunately, I can't offer any help as I don't know much about RE engines. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From bwarsaw at python.org Tue Jun 13 15:17:07 2000 From: bwarsaw at python.org (bwarsaw at python.org) Date: Tue, 13 Jun 2000 09:17:07 -0400 (EDT) Subject: [Python-Dev] Towards 1.6 Final References: <14661.19894.465676.770545@anthem.concentric.net> <200006130237.EAA10373@python.inrialpes.fr> Message-ID: <14662.13395.520180.272688@anthem.concentric.net> >>>>> "VM" == Vladimir Marangozov writes: >> - enable threads by default if OS supports it VM> Who's going to champion this? I recall Greg Stein volunteering VM> for it ;) (or for something related) This isn't the free-threading stuff, which I think we're pushing back to 1.7, right? Just making --with-threads turned on by default if the OS supports it. >> - Test the hell out of SRE. (waiting for /F's complete >> implementation) VM> ... >> As we saw it the most critical things that need to get done are >> testing the GC stuff and the SRE module. Of those, the most >> critical is SRE since AFAIK, we're still waiting for the final >> complete code from /F. I could be wrong about that. VM> It thas been my impression that people are pushing /F for SRE VM> deliveries, but he feels uncomfortable with a number of VM> Unicode compromises (affecting the SRE code and/or design???) VM> and has some implementation hesitations. Add to this the VM> pression of the recent PythonWorks' release. In this context, VM> if there's something to be finished, it would be nice to stop VM> pushing him and help him finishing this VM> project. Unfortunately, I can't offer any help as I don't know VM> much about RE engines. Neither do I. /F, how can we help? -Barry From mal at lemburg.com Tue Jun 13 15:18:59 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 13 Jun 2000 15:18:59 +0200 Subject: [Python-Dev] Towards 1.6 Final References: <14661.19894.465676.770545@anthem.concentric.net> <200006130237.EAA10373@python.inrialpes.fr> <14662.13395.520180.272688@anthem.concentric.net> Message-ID: <394634C3.9C217913@lemburg.com> bwarsaw at python.org wrote: > > >>>>> "VM" == Vladimir Marangozov writes: > > >> - enable threads by default if OS supports it > > VM> Who's going to champion this? I recall Greg Stein volunteering > VM> for it ;) (or for something related) > > This isn't the free-threading stuff, which I think we're pushing back > to 1.7, right? Just making --with-threads turned on by default if the > OS supports it. Ehm, didn't we agree on not enabling this by default ? From what I've heard there are simply too many problems with thread implementations which cause Python to break in different ways (not necessarily Python's faults). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gstein at lyra.org Tue Jun 13 15:26:08 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 13 Jun 2000 06:26:08 -0700 Subject: [Python-Dev] Towards 1.6 Final In-Reply-To: <394634C3.9C217913@lemburg.com>; from mal@lemburg.com on Tue, Jun 13, 2000 at 03:18:59PM +0200 References: <14661.19894.465676.770545@anthem.concentric.net> <200006130237.EAA10373@python.inrialpes.fr> <14662.13395.520180.272688@anthem.concentric.net> <394634C3.9C217913@lemburg.com> Message-ID: <20000613062608.A19484@lyra.org> On Tue, Jun 13, 2000 at 03:18:59PM +0200, M.-A. Lemburg wrote: > bwarsaw at python.org wrote: > > > > >>>>> "VM" == Vladimir Marangozov writes: > > > > >> - enable threads by default if OS supports it > > > > VM> Who's going to champion this? I recall Greg Stein volunteering > > VM> for it ;) (or for something related) > > > > This isn't the free-threading stuff, which I think we're pushing back > > to 1.7, right? Just making --with-threads turned on by default if the > > OS supports it. > > Ehm, didn't we agree on not enabling this by default ? From what > I've heard there are simply too many problems with thread > implementations which cause Python to break in different ways > (not necessarily Python's faults). Threads are quite fine nowadays. Windows has enabled threads for years. Recent Linux distros all turn it on. etc No sense in being afraid any more. :-) Cheers, -g p.s. and yes: free-threading is post 1.6 -- Greg Stein, http://www.lyra.org/ From jim at interet.com Tue Jun 13 15:32:33 2000 From: jim at interet.com (James C. Ahlstrom) Date: Tue, 13 Jun 2000 09:32:33 -0400 Subject: [Python-Dev] Towards 1.6 Final References: <14661.19894.465676.770545@anthem.concentric.net> Message-ID: <394637F1.73E24380@interet.com> Just a heads up that there is a patch in patches at python.org to fix a bug in zipfile.py. JimA From mal at lemburg.com Tue Jun 13 15:35:26 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 13 Jun 2000 15:35:26 +0200 Subject: [Python-Dev] Towards 1.6 Final References: <14661.19894.465676.770545@anthem.concentric.net> <200006130237.EAA10373@python.inrialpes.fr> <14662.13395.520180.272688@anthem.concentric.net> <394634C3.9C217913@lemburg.com> <20000613062608.A19484@lyra.org> Message-ID: <3946389E.B9C5E2F5@lemburg.com> Greg Stein wrote: > > On Tue, Jun 13, 2000 at 03:18:59PM +0200, M.-A. Lemburg wrote: > > bwarsaw at python.org wrote: > > > > > > >>>>> "VM" == Vladimir Marangozov writes: > > > > > > >> - enable threads by default if OS supports it > > > > > > VM> Who's going to champion this? I recall Greg Stein volunteering > > > VM> for it ;) (or for something related) > > > > > > This isn't the free-threading stuff, which I think we're pushing back > > > to 1.7, right? Just making --with-threads turned on by default if the > > > OS supports it. > > > > Ehm, didn't we agree on not enabling this by default ? From what > > I've heard there are simply too many problems with thread > > implementations which cause Python to break in different ways > > (not necessarily Python's faults). > > Threads are quite fine nowadays. Windows has enabled threads for years. > Recent Linux distros all turn it on. Ok, then make it default on Linux and Windows... but leave it turned off on other platforms which still have problems such as AIX. > No sense in being afraid any more. :-) Naa, not being afraid :-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From jim at interet.com Tue Jun 13 15:49:36 2000 From: jim at interet.com (James C. Ahlstrom) Date: Tue, 13 Jun 2000 09:49:36 -0400 Subject: [Python-Dev] Towards 1.6 Final References: <14661.19894.465676.770545@anthem.concentric.net> <20000612173214.F19484@lyra.org> Message-ID: <39463BF0.823C0366@interet.com> Greg Stein wrote: > > On Mon, Jun 12, 2000 at 04:53:10PM -0400, Barry A. Warsaw wrote: > > ... disclaimers applied ... > > > > - import hooks revamped (push this to 1.7) > > The latest thought had two items here: > > 1) incorporate feedback into imputil.py. > [ the feedback is visible at the end of the most recent version: > http://www.lyra.org/cgi-bin/viewcvs.cgi/gjspy/imputil.py/ > ] > 2) drop imputil into the standard library, but don't go down the "replace > Python's default mechanism with imputil" > > Essentially, this gets imputil out there and usable, but it doesn't directly > impact Python's operation in 1.6. I would very much like to see imputil.py in the distribution. I currently use ZIP importing, and I have the ZIP importer class done, except that it is based on the old imputil.py. I think ZIP importing could be a popular feature. JimA From Vladimir.Marangozov at inrialpes.fr Tue Jun 13 15:54:13 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Tue, 13 Jun 2000 15:54:13 +0200 (CEST) Subject: [Python-Dev] Towards 1.6 Final In-Reply-To: <3946389E.B9C5E2F5@lemburg.com> from "M.-A. Lemburg" at Jun 13, 2000 03:35:26 PM Message-ID: <200006131354.PAA11656@python.inrialpes.fr> M.-A. Lemburg wrote: > > Ok, then make it default on Linux and Windows... but leave it > turned off on other platforms which still have problems > such as AIX. No, I'd suggest turning it on by default everywhere and provide a --without-thread configure option if it isn't there yet. On AIX there are identified compiler/libthread combinations that work or don't work. They can be detected though and since the compiler is detected earlier, --with-thread can be automatically disabled with a notification message about the conflict. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From mal at lemburg.com Tue Jun 13 16:05:55 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 13 Jun 2000 16:05:55 +0200 Subject: [Python-Dev] Towards 1.6 Final References: <200006131354.PAA11656@python.inrialpes.fr> Message-ID: <39463FC3.16D6718@lemburg.com> Vladimir Marangozov wrote: > > M.-A. Lemburg wrote: > > > > Ok, then make it default on Linux and Windows... but leave it > > turned off on other platforms which still have problems > > such as AIX. > > No, I'd suggest turning it on by default everywhere and provide a > --without-thread configure option if it isn't there yet. > > On AIX there are identified compiler/libthread combinations that work > or don't work. They can be detected though and since the compiler is > detected earlier, --with-thread can be automatically disabled with a > notification message about the conflict. Ok, let me drop in another argument: How you are going to sell the performance loss due to enabled thread support even when a script doesn't need threads at all ? How about building two versions of the interpreter per default: one with threads enabled and one without threads ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gstein at lyra.org Tue Jun 13 16:09:02 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 13 Jun 2000 07:09:02 -0700 Subject: [Python-Dev] Towards 1.6 Final In-Reply-To: <39463FC3.16D6718@lemburg.com>; from mal@lemburg.com on Tue, Jun 13, 2000 at 04:05:55PM +0200 References: <200006131354.PAA11656@python.inrialpes.fr> <39463FC3.16D6718@lemburg.com> Message-ID: <20000613070902.G19484@lyra.org> On Tue, Jun 13, 2000 at 04:05:55PM +0200, M.-A. Lemburg wrote: > Vladimir Marangozov wrote: > > > > M.-A. Lemburg wrote: > > > > > > Ok, then make it default on Linux and Windows... but leave it > > > turned off on other platforms which still have problems > > > such as AIX. > > > > No, I'd suggest turning it on by default everywhere and provide a > > --without-thread configure option if it isn't there yet. > > > > On AIX there are identified compiler/libthread combinations that work > > or don't work. They can be detected though and since the compiler is > > detected earlier, --with-thread can be automatically disabled with a > > notification message about the conflict. > > Ok, let me drop in another argument: > > How you are going to sell the performance loss due to > enabled thread support even when a script doesn't > need threads at all ? > > How about building two versions of the interpreter per default: > one with threads enabled and one without threads ? Hey, the sky is falling, too. If people are concerned with the performance and want to eek that gain out, then they can build with --without-threads Not a problem. "Gee. My operating system is too slow because it deals with all these process and threads. Why can't I have a single-process OS like DOS? It runs *so* much faster." :-) -- Greg Stein, http://www.lyra.org/ From bwarsaw at python.org Tue Jun 13 16:34:34 2000 From: bwarsaw at python.org (Barry A. Warsaw) Date: Tue, 13 Jun 2000 10:34:34 -0400 (EDT) Subject: [Python-Dev] Towards 1.6 Final References: <3946389E.B9C5E2F5@lemburg.com> <200006131354.PAA11656@python.inrialpes.fr> Message-ID: <14662.18042.397439.614107@anthem.concentric.net> >>>>> "VM" == Vladimir Marangozov writes: VM> On AIX there are identified compiler/libthread combinations VM> that work or don't work. They can be detected though and since VM> the compiler is detected earlier, --with-thread can be VM> automatically disabled with a notification message about the VM> conflict. Can you provide a list of such combinations? -Barry From mal at lemburg.com Tue Jun 13 16:44:20 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 13 Jun 2000 16:44:20 +0200 Subject: [Python-Dev] Towards 1.6 Final References: <200006131354.PAA11656@python.inrialpes.fr> <39463FC3.16D6718@lemburg.com> <20000613070902.G19484@lyra.org> Message-ID: <394648C4.2A701B5B@lemburg.com> [enabling threads per default] > > > > How you are going to sell the performance loss due to > > enabled thread support even when a script doesn't > > need threads at all ? > > > > How about building two versions of the interpreter per default: > > one with threads enabled and one without threads ? > > Hey, the sky is falling, too. > > If people are concerned with the performance and want to eek that gain out, > then they can build with --without-threads > > Not a problem. > > "Gee. My operating system is too slow because it deals with all these > process and threads. Why can't I have a single-process OS like DOS? It runs > *so* much faster." Oh well... never mind, as long as I can still build my Python without threads, I'm fine :-) BTW, what about the idea of adding threads at Python level that was tossed around a few years ago ? Should be easy to do given Christian's stackless patches together with the asyncore libs... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From bwarsaw at python.org Tue Jun 13 16:47:21 2000 From: bwarsaw at python.org (Barry A. Warsaw) Date: Tue, 13 Jun 2000 10:47:21 -0400 (EDT) Subject: [Python-Dev] Towards 1.6 Final References: <200006131354.PAA11656@python.inrialpes.fr> <39463FC3.16D6718@lemburg.com> Message-ID: <14662.18809.468033.931803@anthem.concentric.net> >>>>> "M" == M writes: M> How about building two versions of the interpreter per default: M> one with threads enabled and one without threads ? Python 1.6, current CVS snapshot on a Dell PIII 650, RH 6.1. with threads: 8547.01 pystones/second without threads: 9259.26 pystones/second So an 8% hit isn't negligible but I think it's acceptable for the benefit of being confidently able to distribute threaded apps. -Barry From petrilli at amber.org Tue Jun 13 17:02:01 2000 From: petrilli at amber.org (Christopher Petrilli) Date: Tue, 13 Jun 2000 11:02:01 -0400 Subject: [Python-Dev] Towards 1.6 Final In-Reply-To: <14662.18809.468033.931803@anthem.concentric.net>; from bwarsaw@python.org on Tue, Jun 13, 2000 at 10:47:21AM -0400 References: <200006131354.PAA11656@python.inrialpes.fr> <39463FC3.16D6718@lemburg.com> <14662.18809.468033.931803@anthem.concentric.net> Message-ID: <20000613110201.B25344@trump.amber.org> Barry A. Warsaw [bwarsaw at python.org] wrote: > > >>>>> "M" == M writes: > > M> How about building two versions of the interpreter per default: > M> one with threads enabled and one without threads ? > > Python 1.6, current CVS snapshot on a Dell PIII 650, RH 6.1. > > with threads: 8547.01 pystones/second > without threads: 9259.26 pystones/second > > So an 8% hit isn't negligible but I think it's acceptable for the > benefit of being confidently able to distribute threaded apps. Just as a data point, in the "Python problems" with Zope, this, along with soe idiocy in packaging of RPMs in RedHat are the two biggest problems we have a the Python level. People not compiling with threads turned on, and RedHat's decision to ship the header files separate than the regular Python files. BLAH! Chris -- | Christopher Petrilli | petrilli at amber.org From bwarsaw at python.org Tue Jun 13 16:52:24 2000 From: bwarsaw at python.org (Barry A. Warsaw) Date: Tue, 13 Jun 2000 10:52:24 -0400 (EDT) Subject: [Python-Dev] Towards 1.6 Final References: <200006131354.PAA11656@python.inrialpes.fr> <39463FC3.16D6718@lemburg.com> <20000613070902.G19484@lyra.org> <394648C4.2A701B5B@lemburg.com> Message-ID: <14662.19112.118940.63296@anthem.concentric.net> >>>>> "M" == M writes: M> BTW, what about the idea of adding threads at Python level M> that was tossed around a few years ago ? Should be easy to M> do given Christian's stackless patches together with the M> asyncore libs... Definitely not for 1.6! From mal at lemburg.com Tue Jun 13 17:17:13 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 13 Jun 2000 17:17:13 +0200 Subject: [Python-Dev] Towards 1.6 Final References: <200006131354.PAA11656@python.inrialpes.fr> <39463FC3.16D6718@lemburg.com> <20000613070902.G19484@lyra.org> <394648C4.2A701B5B@lemburg.com> <14662.19112.118940.63296@anthem.concentric.net> Message-ID: <39465079.64174882@lemburg.com> "Barry A. Warsaw" wrote: > > >>>>> "M" == M writes: > > M> BTW, what about the idea of adding threads at Python level > M> that was tossed around a few years ago ? Should be easy to > M> do given Christian's stackless patches together with the > M> asyncore libs... > > Definitely not for 1.6! Sure... just wanted to add a hint for 1.7 :-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From DavidA at ActiveState.com Tue Jun 13 19:31:32 2000 From: DavidA at ActiveState.com (David Ascher) Date: Tue, 13 Jun 2000 10:31:32 -0700 Subject: [Python-Dev] O'Reilly Python Conference Early Registration Deadline Looming Message-ID: It's that time of year again, the O'Reilly Open Source Convention, including the Python track, is fast approaching. You can save up to $280 if you register by Friday July 16. The event will be held this July 17-20 in Monterey, California. Meet all the key Python players, meet fellow Python enthusiasts, learn about new Python developments, find Python-related jobs, and have fun at this yearly event in sunny Monterey, CA. For details on the Python tutorials, see http://www.oreillynet.com/pub/w/python_tutorials.html For details on the Python talks, see http://www.oreillynet.com/pub/w/python_presentations.html For details on the Conference as a whole, see http://conferences.oreilly.com/oscon2000/index.html Looking forward to meeting you there, -- David Ascher OSCON Python Track Program Chair Senior Developer, ActiveState Tool Corporation Students and academics should remember to sign up for reduced fees: http://conferences.oreilly.com/oscon2000/register/ From DavidA at ActiveState.com Tue Jun 13 20:00:41 2000 From: DavidA at ActiveState.com (David Ascher) Date: Tue, 13 Jun 2000 11:00:41 -0700 Subject: [Python-Dev] O'Reilly Python Conference Early Registration Deadline Looming In-Reply-To: Message-ID: > It's that time of year again, the O'Reilly Open Source > Convention, including the Python track, is fast approaching. > You can save up to $280 if you register by Friday July 16. Make that June 19. Sorry about that. --david ascher From mal at lemburg.com Tue Jun 13 21:25:04 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 13 Jun 2000 21:25:04 +0200 Subject: [Python-Dev] Towards 1.6 Final References: <14661.19894.465676.770545@anthem.concentric.net> Message-ID: <39468A90.697D1CE5@lemburg.com> "Barry A. Warsaw" wrote: > > The O'Reilly Open Source conference[1] starts July 17th and it would > be a nice target to release 1.6 final on the 14th, the Friday before > the conference. We all plan on being there.n > > What do we need to do to hit this target? If we figure a 2 week beta > cycle, 1.6beta1 would have to be released June 30, with probably the > last alpha on June 23. This is a tight schedule; is it even > feasible?. Looking at Andrew's TODO list[2], here's what we came up > with: > > [...] > - document more undocumented modules (codes - done; unicodedata - > needs work; mmap & pyexpat - Fred to integrate; curses - needs > updates; regrtest - push to 1.7, see below) I'll take care of unicodedata. What's "codes" -- or did you mean codecs ? > - Unicode: Compress the size of unicodedatabase (waiting for Chris > Tismer patches?) Right... > - Unicode: Write \N{SMILEY} codec for Unicode (Bill Tutt has a patch, > but none of us know what the state of this is -- is it crucial > anyway?). Not crucial, but would be nice to have. > - Unicode: the various XXX items in Misc/unicode.txt (we didn't > actually find such outstanding issues in this file). There are no more discussion points... at least not in that file ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From bwarsaw at python.org Tue Jun 13 21:31:51 2000 From: bwarsaw at python.org (bwarsaw at python.org) Date: Tue, 13 Jun 2000 15:31:51 -0400 (EDT) Subject: [Python-Dev] Towards 1.6 Final References: <14661.19894.465676.770545@anthem.concentric.net> <39468A90.697D1CE5@lemburg.com> Message-ID: <14662.35879.156976.61686@anthem.concentric.net> >>>>> "M" == M writes: M> I'll take care of unicodedata. What's "codes" -- or did you M> mean codecs ? Oops, yes, "codecs". M> There are no more discussion points... at least not in that M> file ;-) :) -Barry From gstein at lyra.org Tue Jun 13 22:11:45 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 13 Jun 2000 13:11:45 -0700 Subject: [Python-Dev] Towards 1.6 Final In-Reply-To: <39463BF0.823C0366@interet.com>; from jim@interet.com on Tue, Jun 13, 2000 at 09:49:36AM -0400 References: <14661.19894.465676.770545@anthem.concentric.net> <20000612173214.F19484@lyra.org> <39463BF0.823C0366@interet.com> Message-ID: <20000613131145.O19484@lyra.org> On Tue, Jun 13, 2000 at 09:49:36AM -0400, James C. Ahlstrom wrote: > Greg Stein wrote: > > On Mon, Jun 12, 2000 at 04:53:10PM -0400, Barry A. Warsaw wrote: > > > ... disclaimers applied ... > > > > > > - import hooks revamped (push this to 1.7) > > > > The latest thought had two items here: > > > > 1) incorporate feedback into imputil.py. > > [ the feedback is visible at the end of the most recent version: > > http://www.lyra.org/cgi-bin/viewcvs.cgi/gjspy/imputil.py/ > > ] > > 2) drop imputil into the standard library, but don't go down the "replace > > Python's default mechanism with imputil" > > > > Essentially, this gets imputil out there and usable, but it doesn't directly > > impact Python's operation in 1.6. > > I would very much like to see imputil.py in the distribution. I > currently > use ZIP importing, and I have the ZIP importer class done, except that > it > is based on the old imputil.py. I think ZIP importing could be a > popular feature. Yes, this should happen. In my current setup, I've got a second module named "importers.py" that has some of the "standard" importers. It would go into there. Oh, so I guess we'd also want to include importers.py into the distro. All of this is preconditioned on getting at least some of that imputil work done that is listed in the TODO area at the bottom of the file... I'm not sure how soon I'll be able to get to that. Cheers, -g -- Greg Stein, http://www.lyra.org/ From Vladimir.Marangozov at inrialpes.fr Wed Jun 14 02:57:05 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Wed, 14 Jun 2000 02:57:05 +0200 (CEST) Subject: [Python-Dev] --with-threads by default (was: Towards 1.6 Final) In-Reply-To: <14662.18042.397439.614107@anthem.concentric.net> from "Barry A. Warsaw" at Jun 13, 2000 10:34:34 AM Message-ID: <200006140057.CAA12560@python.inrialpes.fr> Barry A. Warsaw wrote: > > > >>>>> "VM" == Vladimir Marangozov writes: > > VM> On AIX there are identified compiler/libthread combinations > VM> that work or don't work. They can be detected though and since > VM> the compiler is detected earlier, --with-thread can be > VM> automatically disabled with a notification message about the > VM> conflict. > > Can you provide a list of such combinations? > This is outlined in Misc/AIX-NOTES, section thread support. I've heard that recent versions of gcc work as well, so long as the executable is linked with AIX ld (not GNU ld). Ideally, IMO, there should be an appropriate AC_TRY_RUN little threaded program (or a program suite corresponding to different thread libs and or standards for a given platform) that would disable threads on failure. This approach has the merit of being applicable to all Unix flavors. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From trentm at activestate.com Wed Jun 14 07:21:42 2000 From: trentm at activestate.com (Trent Mick) Date: Tue, 13 Jun 2000 22:21:42 -0700 Subject: [Python-Dev] Re: stringobject question In-Reply-To: <394701D6.37E6F560@yahoo.com> References: <394701D6.37E6F560@yahoo.com> Message-ID: <20000613222142.A27523@activestate.com> On Tue, Jun 13, 2000 at 10:53:58PM -0500, Al-Amerrho H. Amerin wrote: > Is this a bug or a feature?: > > Python 1.6a2 (#4, Jun 9 2000, 02:22:41) [GCC 2.95.2 19991024 > (release)] on linux2 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) > > >>> ''.isdigit() > 1 > >>> ''.isspace() > 1 > Good point, maybe. The __docs__ say: "S.isdigit() -> int\n\ \n\ Return 1 if there are only digit characters in S,\n\ 0 otherwise."; static char isspace__doc__[] = "S.isspace() -> int\n\ \n\ Return 1 if there are only whitespace characters in S,\n\ 0 otherwise."; I am not an English language lawyer so I could see both interpretations from the doc strings. I agree, that the result with a zero length string is surprising. Hi All, Which should it be? Sorry, if this has been covered. Trent -- Trent Mick trentm at activestate.com From mal at lemburg.com Wed Jun 14 10:43:45 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 14 Jun 2000 10:43:45 +0200 Subject: [Python-Dev] Re: stringobject question References: <394701D6.37E6F560@yahoo.com> <20000613222142.A27523@activestate.com> Message-ID: <394745C1.7FA27DCB@lemburg.com> Trent Mick wrote: > > On Tue, Jun 13, 2000 at 10:53:58PM -0500, Al-Amerrho H. Amerin wrote: > > Is this a bug or a feature?: > > > > Python 1.6a2 (#4, Jun 9 2000, 02:22:41) [GCC 2.95.2 19991024 > > (release)] on linux2 > > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > > Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) > > > > >>> ''.isdigit() > > 1 > > >>> ''.isspace() > > 1 > > > > Good point, maybe. The __docs__ say: > > "S.isdigit() -> int\n\ > \n\ > Return 1 if there are only digit characters in S,\n\ > 0 otherwise."; > > static char isspace__doc__[] = > "S.isspace() -> int\n\ > \n\ > Return 1 if there are only whitespace characters in S,\n\ > 0 otherwise."; > > I am not an English language lawyer so I could see both interpretations from > the doc strings. I agree, that the result with a zero length string is > surprising. > > Hi All, > Which should it be? Sorry, if this has been covered. I guess it's a bug... a subtle one though, because in a certain sense both 1 and 0 are acceptable. But since '' is considered to be false, I think that returning 0 makes more sense. I'll fix this to return 0 for emtpy strings and Unicode objects. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From moshez at math.huji.ac.il Wed Jun 14 10:46:48 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Wed, 14 Jun 2000 11:46:48 +0300 (IDT) Subject: [Python-Dev] Re: stringobject question In-Reply-To: <394745C1.7FA27DCB@lemburg.com> Message-ID: On Wed, 14 Jun 2000, M.-A. Lemburg wrote: > > > >>> ''.isdigit() > > > 1 > > > >>> ''.isspace() > > > 1 > > > > > > > Good point, maybe. The __docs__ say: > > > > "S.isdigit() -> int\n\ > > \n\ > > Return 1 if there are only digit characters in S,\n\ > > 0 otherwise."; > > > > static char isspace__doc__[] = > > "S.isspace() -> int\n\ > > \n\ > > Return 1 if there are only whitespace characters in S,\n\ > > 0 otherwise."; > > > > I am not an English language lawyer so I could see both interpretations from > > the doc strings. I agree, that the result with a zero length string is > > surprising. > > > > Hi All, > > Which should it be? Sorry, if this has been covered. > > I guess it's a bug... a subtle one though, because in a > certain sense both 1 and 0 are acceptable. But since > '' is considered to be false, I think that returning 0 > makes more sense. > > I'll fix this to return 0 for emtpy strings and Unicode objects. I just realized something: if you change the semantics to mean "number of digits", you'll get the right answer for all 0- and 1- length strings and unicode objects. just-an-observation-ly y'rs, Z. -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com From mal at lemburg.com Wed Jun 14 11:18:10 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 14 Jun 2000 11:18:10 +0200 Subject: [Python-Dev] Re: stringobject question References: Message-ID: <39474DD2.BF51C872@lemburg.com> Moshe Zadka wrote: > > On Wed, 14 Jun 2000, M.-A. Lemburg wrote: > > > > > >>> ''.isdigit() > > > > 1 > > > > >>> ''.isspace() > > > > 1 > > > > > > > > > > Good point, maybe. The __docs__ say: > > > > > > "S.isdigit() -> int\n\ > > > \n\ > > > Return 1 if there are only digit characters in S,\n\ > > > 0 otherwise."; > > > > > > static char isspace__doc__[] = > > > "S.isspace() -> int\n\ > > > \n\ > > > Return 1 if there are only whitespace characters in S,\n\ > > > 0 otherwise."; > > > > > > I am not an English language lawyer so I could see both interpretations from > > > the doc strings. I agree, that the result with a zero length string is > > > surprising. > > > > > > Hi All, > > > Which should it be? Sorry, if this has been covered. > > > > I guess it's a bug... a subtle one though, because in a > > certain sense both 1 and 0 are acceptable. But since > > '' is considered to be false, I think that returning 0 > > makes more sense. > > > > I'll fix this to return 0 for emtpy strings and Unicode objects. > > I just realized something: if you change the semantics to mean "number of > digits", you'll get the right answer for all 0- and 1- length strings > and unicode objects. Hmm, the .isXXX() tests should return 1/0 since they test properties rather than count characters. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From billtut at microsoft.com Wed Jun 14 12:12:48 2000 From: billtut at microsoft.com (Bill Tutt) Date: Wed, 14 Jun 2000 03:12:48 -0700 Subject: [Python-Dev] AIX shared library support Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E4@RED-MSG-50> Is there any particular reason that dynload_aix.c doesn't use AIX's dlopen? From mal at lemburg.com Wed Jun 14 12:19:44 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 14 Jun 2000 12:19:44 +0200 Subject: [Python-Dev] AIX shared library support References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E4@RED-MSG-50> Message-ID: <39475C40.EF9CE51B@lemburg.com> Bill Tutt wrote: > > Is there any particular reason that dynload_aix.c doesn't use AIX's dlopen? > >From what I can tell, libtool seems to use dlopen on AIX 3.xxx and AIX > 4.xxx. > > I was all set to integrate the \N{...} support into the Unicode-escape > encoding, and dynamically load the hash table data in on demand, but > dynload_aix only cares about module entry points and won't let you specify > an explicit function name. Uhm, why do you need to go that deep into the internals of the import mechanism ? Wouldn't is suffice to put the hash table into a _ucnhash module which get imported on demand (the import mechanism would then take care of the rest) ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From billtut at microsoft.com Wed Jun 14 12:12:48 2000 From: billtut at microsoft.com (Bill Tutt) Date: Wed, 14 Jun 2000 03:12:48 -0700 Subject: [Python-Dev] AIX shared library support Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E4@RED-MSG-50> Is there any particular reason that dynload_aix.c doesn't use AIX's dlopen? From billtut at microsoft.com Wed Jun 14 12:33:11 2000 From: billtut at microsoft.com (Bill Tutt) Date: Wed, 14 Jun 2000 03:33:11 -0700 Subject: [Python-Dev] unicode character name patch status Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E5@RED-MSG-50> I was all set to integrate the \N{...} support into the Unicode-escape encoding, and dynamically load the hash table data in on demand, but dynload_aix only cares about module entry points and won't let you specify an explicit function name. Ugh. So, its question and answer time folks: 1) If we can't dynamically load the hash table data, is it that big of a deal? Probably only for WinCE, palm pilot, etc, and they already have patches against CVS. 2) Or, should I just have a separate encoding? I'd prefer to pick option #1 since Perl natively supports the syntax in their strings. The data is all constant read/only data that will be mmapped directly from the binary, so it only effects working set if the feature is used. Barry, Greg, Guido? The only feedback I got last time I submitted the patch was from MAL, it'd help if some other folks would comment on it. Thanks, Bill From mal at lemburg.com Wed Jun 14 12:45:01 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 14 Jun 2000 12:45:01 +0200 Subject: [Python-Dev] unicode character name patch status References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E5@RED-MSG-50> Message-ID: <3947622D.9995572E@lemburg.com> [Me again, hope you don't mind ;-)] Bill Tutt wrote: > > I was all set to integrate the \N{...} support into the Unicode-escape > encoding, and dynamically load the hash table data in on demand, but > dynload_aix only cares about module entry points and won't let you specify > an explicit function name. > > Ugh. So, its question and answer time folks: > 1) If we can't dynamically load the hash table data, is it that big of > a deal? > Probably only for WinCE, palm pilot, etc, and they already > have patches against CVS. > 2) Or, should I just have a separate encoding? > > I'd prefer to pick option #1 since Perl natively supports the syntax in > their strings. The data is all constant read/only data that will be mmapped > directly from the binary, so it only effects working set if the feature is > used. Why can't you use PyImport_Import() to do the dynamic loading and combine this with the standard unicode-escape codec ? If it fails (e.g. the user has disabled the module entry in Setup), then simply raise an exception. I wouldn't want the hash table around linked statically -- it's simply to big. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From billtut at microsoft.com Wed Jun 14 12:48:49 2000 From: billtut at microsoft.com (Bill Tutt) Date: Wed, 14 Jun 2000 03:48:49 -0700 Subject: [Python-Dev] AIX shared library support Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E6@RED-MSG-50> MAL wrote: > Bill Tutt wrote: > > > > Is there any particular reason that dynload_aix.c doesn't use AIX's dlopen? > > >From what I can tell, libtool seems to use dlopen on AIX 3.xxx and AIX > > 4.xxx. > > > I was all set to integrate the \N{...} support into the Unicode-escape > > encoding, and dynamically load the hash table data in on demand, but > > dynload_aix only cares about module entry points and won't let you specify > > an explicit function name. > Uhm, why do you need to go that deep into the internals > of the import mechanism ? > Wouldn't is suffice to put the hash table into a _ucnhash module > which get imported on demand (the import mechanism would then > take care of the rest) ? It would suffice, but it'd be less efficient (and more work) since I'd then have to access the data/hash functions through the normal PyObject mechanisms instead of directly as C functions. That is, I'm trying to avoid creating a PyString of whatever is inside the braces. (\N{SMILEY}). Then again, maybe I'm just being too performance sensitive. The import mechanism got redone weirdly, all of the ways of doing dynamic loading except AIX encode the idea that the function name must be preceeded by "init". Dynload_xxx.c is the wrong place to put that requirement. Whomever calls _PyImport_GetDynLoadFunc() should handle that issue. Just as an FYI, the only problem I've found so far with my last patch was wrt handling Unicode characters with values in the UCS-4 code space. (Not that there are any yet, but the code must handle that case anyway, sine I don't want to have to go change it later.) Bill From mal at lemburg.com Wed Jun 14 13:00:50 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 14 Jun 2000 13:00:50 +0200 Subject: [Python-Dev] AIX shared library support References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E6@RED-MSG-50> Message-ID: <394765E2.BFBEA135@lemburg.com> Bill Tutt wrote: > > MAL wrote: > > > Bill Tutt wrote: > > > > > > Is there any particular reason that dynload_aix.c doesn't use AIX's > dlopen? > > > >From what I can tell, libtool seems to use dlopen on AIX 3.xxx and AIX > > > 4.xxx. > > > > > I was all set to integrate the \N{...} support into the Unicode-escape > > > encoding, and dynamically load the hash table data in on demand, but > > > dynload_aix only cares about module entry points and won't let you > specify > > > an explicit function name. > > > Uhm, why do you need to go that deep into the internals > > of the import mechanism ? > > > Wouldn't is suffice to put the hash table into a _ucnhash module > > which get imported on demand (the import mechanism would then > > take care of the rest) ? > > It would suffice, but it'd be less efficient (and more work) since I'd then > have to access the data/hash functions through the normal PyObject > mechanisms instead of directly as C functions. That is, I'm trying to avoid > creating a PyString of whatever is inside the braces. (\N{SMILEY}). Then > again, maybe I'm just being too performance sensitive. You could pass a pointer to the char* via a PyCObject. I usually export the whole module C API via such an object and it works great: you can rely on module import to get the magic right and still have a C API around which you can call directly from C -- without the need to wrap anything in Python objects. FYI, mxODBC and mxDateTime are tied together using this mechanism; look in the mxDateTime.h|c files for details. > The import mechanism got redone weirdly, all of the ways of doing dynamic > loading except AIX encode the idea that the function name must be preceeded > by "init". > Dynload_xxx.c is the wrong place to put that requirement. Whomever calls > _PyImport_GetDynLoadFunc() should handle that issue. That's to Greg's address, I guess ;-) > Just as an FYI, the only problem I've found so far with my last patch was > wrt handling Unicode characters with values in the UCS-4 code space. (Not > that there are any yet, but the code must handle that case anyway, sine I > don't want to have to go change it later.) Why is there a problem there ? Python currently uses UTF16 as native format. UTF-16 surrogates are not supported though... and probably won't be for a while. I don't see much of a problem here. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From billtut at microsoft.com Wed Jun 14 13:10:44 2000 From: billtut at microsoft.com (Bill Tutt) Date: Wed, 14 Jun 2000 04:10:44 -0700 Subject: [Python-Dev] AIX shared library support Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E7@RED-MSG-50> MAL: > Bill: > > Just as an FYI, the only problem I've found so far with my last patch was > > wrt handling Unicode characters with values in the UCS-4 code space. (Not > > that there are any yet, but the code must handle that case anyway, sine I > > don't want to have to go change it later.) > Why is there a problem there ? Python currently uses UTF16 > as native format. UTF-16 surrogates are not supported though... > and probably won't be for a while. The rest of Python may not care about UTF-16, but that's no particular reason to not have this code support generating surrogates if an input UnicodeData.txt happens to have character names for code points that require surrogates. Bill From mwh21 at cam.ac.uk Wed Jun 14 13:18:27 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 14 Jun 2000 12:18:27 +0100 Subject: [Python-Dev] Can starship please have its front page back? Message-ID: I'm not sure if I should ask this here, but I've tried crew at starship and comp.lang.python, so forgive me please. There are links all over the place (eg. python.org, oriellynet) to "http://starship.python.net/", which currently gets the gentle browsing newbie a rather forbidding, somewhat out-of-date status page. I don't really think this gives a good impression. Particularly as said page is no longer on the machine that had the hard disc failure... Cheers, M. From mal at lemburg.com Wed Jun 14 13:36:25 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 14 Jun 2000 13:36:25 +0200 Subject: [Python-Dev] AIX shared library support References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E7@RED-MSG-50> Message-ID: <39476E39.E4163D20@lemburg.com> Bill Tutt wrote: > > MAL: > > Bill: > > > Just as an FYI, the only problem I've found so far with my last patch > was > > > wrt handling Unicode characters with values in the UCS-4 code space. > (Not > > > that there are any yet, but the code must handle that case anyway, sine > I > > > don't want to have to go change it later.) > > > Why is there a problem there ? Python currently uses UTF16 > > as native format. UTF-16 surrogates are not supported though... > > and probably won't be for a while. > > The rest of Python may not care about UTF-16, but that's no particular > reason to not have this code support generating surrogates if an input > UnicodeData.txt happens to have character names for code points that require > surrogates. True. As long as the design permitts generating surrogates, there should be no problem. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Vladimir.Marangozov at inrialpes.fr Wed Jun 14 16:48:01 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Wed, 14 Jun 2000 16:48:01 +0200 (CEST) Subject: [Python-Dev] AIX shared library support In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E4@RED-MSG-50> from "Bill Tutt" at Jun 14, 2000 03:12:48 AM Message-ID: <200006141448.QAA14090@python.inrialpes.fr> Bill Tutt wrote: > > Is there any particular reason that dynload_aix.c doesn't use AIX's dlopen? > >From what I can tell, libtool seems to use dlopen on AIX 3.xxx and AIX > 4.xxx. Historically, the dlopen interface (originally a Sun thing) was included as a standard library (libdl.a) starting from AIX 4.3 (or 4.2). It doesn't exist on AIX 3.x and AIX 4.1.x. There was a dlopen emulation library, though, written by an old AIX guru, but it had to be installed manually on these versions of AIX. Then, slowly, IBM started to be more receptive about some defacto standards, included libdl.a in the standard AIX distribution and introduced the -G flag in ld (a la Sun and others) which adds -ldl to the link automatically. But all this really works on AIX 4.3 and up. So what is implemented in Python relies on lower-level dynamic linker primitives that exist on all AIX releases. Furthermore, our original goal was not to provide a complete (per symbol) runtime linker, hence the current state of affairs. The 'init' entry point convention is a Python convention. It can be changed at link time, but still, there is no a full featured dynamic linker and there is no reason to have it in Python. Python wisely limits itself to the loading of a shared object (lib) in memory, then to invoke an init function, without going into subtle per-platform dynlinking details, which would have been a royal pain to maintain anyway. I second MAL's opinions: you really don't want to be so deep about dynloads and it's better to fit in the current architecture. Personnally, I won't care if my smiley takes half a second to load in memory. :-) -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From gstein at lyra.org Wed Jun 14 17:00:23 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 14 Jun 2000 08:00:23 -0700 Subject: [Python-Dev] unicode character name patch status In-Reply-To: <3947622D.9995572E@lemburg.com>; from mal@lemburg.com on Wed, Jun 14, 2000 at 12:45:01PM +0200 References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E5@RED-MSG-50> <3947622D.9995572E@lemburg.com> Message-ID: <20000614080023.L27338@lyra.org> On Wed, Jun 14, 2000 at 12:45:01PM +0200, M.-A. Lemburg wrote: >... > Bill Tutt wrote: > > I was all set to integrate the \N{...} support into the Unicode-escape > > encoding, and dynamically load the hash table data in on demand, but > > dynload_aix only cares about module entry points and won't let you specify > > an explicit function name. > > > > Ugh. So, its question and answer time folks: > > 1) If we can't dynamically load the hash table data, is it that big of > > a deal? > > Probably only for WinCE, palm pilot, etc, and they already > > have patches against CVS. > > 2) Or, should I just have a separate encoding? > > > > I'd prefer to pick option #1 since Perl natively supports the syntax in > > their strings. The data is all constant read/only data that will be mmapped > > directly from the binary, so it only effects working set if the feature is > > used. > > Why can't you use PyImport_Import() to do the dynamic loading and > combine this with the standard unicode-escape codec ? > If it fails (e.g. the user has disabled the module entry in > Setup), then simply raise an exception. > > I wouldn't want the hash table around linked statically -- it's > simply to big. I'm with MAL. Use Python's import mechanism. That gets you the dynamic load stuff no problem. It *also* handles the case where the module is statically linked. If you go play games with the dynload stuff, then it would be a bitch to build a single, statically-linked executable. Cheers, -g -- Greg Stein, http://www.lyra.org/ From akuchlin at cnri.reston.va.us Wed Jun 14 18:13:23 2000 From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling) Date: Wed, 14 Jun 2000 12:13:23 -0400 Subject: [Python-Dev] Towards 1.6 Final In-Reply-To: <14661.19894.465676.770545@anthem.concentric.net>; from bwarsaw@python.org on Mon, Jun 12, 2000 at 04:53:10PM -0400 References: <14661.19894.465676.770545@anthem.concentric.net> Message-ID: <20000614121323.A13993@amarok.cnri.reston.va.us> On Mon, Jun 12, 2000 at 04:53:10PM -0400, Barry A. Warsaw wrote: >If we figure a 2 week beta cycle, ... Unicode support, a new regex engine, various minor backward incompatible changes that may or may not cause people problems... a 2-week beta seems too short. --amk From billtut at microsoft.com Wed Jun 14 18:29:30 2000 From: billtut at microsoft.com (Bill Tutt) Date: Wed, 14 Jun 2000 09:29:30 -0700 Subject: [Python-Dev] unicode character name patch status Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E8@RED-MSG-50> > From: Greg Stein [mailto:gstein at lyra.org] > I'm with MAL. Use Python's import mechanism. That gets you > the dynamic load > stuff no problem. It *also* handles the case where the module > is statically > linked. > Ok, ok, so much for the idea about modifying as few lines as possible in my patch. :) > If you go play games with the dynload stuff, then it would be > a bitch to > build a single, statically-linked executable. > Nah, thats what the config.h hAVE_... for dynamic load support #define is for. :) Bill From trentm at activestate.com Wed Jun 14 19:36:32 2000 From: trentm at activestate.com (Trent Mick) Date: Wed, 14 Jun 2000 10:36:32 -0700 Subject: [Python-Dev] Re: stringobject question In-Reply-To: <394745C1.7FA27DCB@lemburg.com> References: <394701D6.37E6F560@yahoo.com> <20000613222142.A27523@activestate.com> <394745C1.7FA27DCB@lemburg.com> Message-ID: <20000614103632.C29778@activestate.com> On Wed, Jun 14, 2000 at 10:43:45AM +0200, M . -A . Lemburg wrote: > > I guess it's a bug... a subtle one though, because in a > certain sense both 1 and 0 are acceptable. But since > '' is considered to be false, I think that returning 0 > makes more sense. > > I'll fix this to return 0 for emtpy strings and Unicode objects. These are copied from Java, are they not? What do the Java equivalents return? Trent -- Trent Mick trentm at activestate.com From gstein at lyra.org Wed Jun 14 23:52:08 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 14 Jun 2000 14:52:08 -0700 Subject: [Python-Dev] unicode character name patch status In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E8@RED-MSG-50>; from billtut@microsoft.com on Wed, Jun 14, 2000 at 09:29:30AM -0700 References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD1E8@RED-MSG-50> Message-ID: <20000614145208.D28280@lyra.org> On Wed, Jun 14, 2000 at 09:29:30AM -0700, Bill Tutt wrote: > > From: Greg Stein [mailto:gstein at lyra.org] >... > > If you go play games with the dynload stuff, then it would be > > a bitch to > > build a single, statically-linked executable. > > Nah, thats what the config.h hAVE_... for dynamic load support #define is > for. :) Just to beat a dead horse here: no. Just because config.h says that I *could* dynamically load doesn't mean that I *want* to. If I want to build a mother, static Python and I want the name table bundled in, then any dynamic loading that you make explicit is just going to gum up the process. Now shut up, and drink your Kool-Aid. :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From thomas at xs4all.net Thu Jun 15 19:53:27 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 15 Jun 2000 19:53:27 +0200 Subject: [Python-Dev] Augmented assignment Message-ID: <20000615195327.R8000@xs4all.nl> I'd like some (minor) feedback on the augmented assignment thing I'm working on. I understand Guido is the only one who accepts patches like this, and appreciate that, but I'm hoping someone can at least tell me what I'm doing wrong so I can fix it before Guido sees it ;-) But if I'm being an impatient flap, just tell me so and I'll calm down. I also appreciate the fact that the patch is quite large, and not many people have the time to scrutinize each version, so I'll summerize the issues I'm uncertain about. * The patch needs to add a new type of opcode, one that takes 2 arguments. This is because the opcodes that load, change and store a name need one argument for the index in the name table (or local variable number), and one argument for the actual operation. It could also work by using PyInt or another PyObject to pass the extra argument on the stack, but I don't think pushing a non-PyObject-pointer onto the stack is a good idea. Adding 2-argument opcodes seemed the easiest solution. However, I'm not really into Python-hacking (or was, I should say, because it's great fun) and the python-dev list doesn't seem to be searchable ;) so I can't know if this issue has come up before. Has it ? Would the new opcode-type be an unsurpassable problem ? should I use the stack instead ? * The patch also needs to add 11 new __hooks__, 11 new API calls, 11 new entries in the PyNumberMethods struct and 2 new entries in the PySequenceMethods struct. Would that conceivably be a problem ? I've heard people on the python-list complain about this ;-P * Should I start sending the patch, in pieces, to the patches-list, or is it a wasted effort because noone will touch it until Guido is back ? If I should send it, should I send it in one large patch (minus autogenerated files) or in nice functionality-sized pieces ? * How 'cool' does Guido actually think this syntax is ? Apparently the subject has come up a few times ;) and I got positive signals from both Tim and Guido, but if the patch won't go in as a patch, and won't actually be used other than some inspiration for a future rewrite of the CPython core, I'm not going to worry too much about the patch ;) I'm trying to get my boss to send me to OSCON2000 to harass Guido about these issues himself, but he (my boss) isn't co-operating ;-P (Not suprising, as Python isn't quite part of my job description, *snif*) Regards, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mal at lemburg.com Thu Jun 15 20:12:50 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 15 Jun 2000 20:12:50 +0200 Subject: [Python-Dev] Augmented assignment References: <20000615195327.R8000@xs4all.nl> Message-ID: <39491CA2.2BDC0DDC@lemburg.com> Thomas Wouters wrote: > > I'd like some (minor) feedback on the augmented assignment thing I'm working > on. I understand Guido is the only one who accepts patches like this, and > appreciate that, but I'm hoping someone can at least tell me what I'm doing > wrong so I can fix it before Guido sees it ;-) But if I'm being an impatient > flap, just tell me so and I'll calm down. I'd make this a 1.7 issue. 1.6 should go into the stabilization phase and big complicated patches like yours should receive some more design and concept discussion before getting checked in. BTW, with "augmented assign" I suppose you mean things like a += 1 and b *= 2, right ? > I also appreciate the fact that the patch is quite large, and not many > people have the time to scrutinize each version, so I'll summerize the > issues I'm uncertain about. > > * The patch needs to add a new type of opcode, one that takes 2 arguments. > This is because the opcodes that load, change and store a name need one > argument for the index in the name table (or local variable number), and one > argument for the actual operation. > > It could also work by using PyInt or another PyObject to pass the extra > argument on the stack, but I don't think pushing a non-PyObject-pointer onto > the stack is a good idea. Adding 2-argument opcodes seemed the easiest > solution. > > However, I'm not really into Python-hacking (or was, I should say, because > it's great fun) and the python-dev list doesn't seem to be searchable ;) so > I can't know if this issue has come up before. Has it ? Would the new > opcode-type be an unsurpassable problem ? should I use the stack instead ? Any reason you can't do this with the existing op codes ? E.g. a += b 1. load a 2. load b 3. add 4. store a > * The patch also needs to add 11 new __hooks__, 11 new API calls, 11 new entries > in the PyNumberMethods struct and 2 new entries in the PySequenceMethods > struct. Would that conceivably be a problem ? I've heard people on the > python-list complain about this ;-P More generic solutions are usually more accepted. BTW, before hacking too much into this, you ought to consider that we are planning for rich comparisons and decentralized coercion in 1.7 (this was planned for 1.6, but David and I got carried away with other things). I wouldn't want to have to hack 11 new slots to get this right... > * Should I start sending the patch, in pieces, to the patches-list, or is > it a wasted effort because noone will touch it until Guido is back ? If I > should send it, should I send it in one large patch (minus autogenerated > files) or in nice functionality-sized pieces ? Better put it on a web page and inform python-dev of new features, enhancements, etc. > * How 'cool' does Guido actually think this syntax is ? Apparently the > subject has come up a few times ;) and I got positive signals from both Tim > and Guido, but if the patch won't go in as a patch, and won't actually be > used other than some inspiration for a future rewrite of the CPython core, > I'm not going to worry too much about the patch ;) Having a patch is good for discussion, whether it gets incorporated is a different issue ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From bckfnn at worldonline.dk Thu Jun 15 20:16:03 2000 From: bckfnn at worldonline.dk (Finn Bock) Date: Thu, 15 Jun 2000 18:16:03 GMT Subject: [Python-Dev] Re: stringobject question In-Reply-To: <20000614103632.C29778@activestate.com> References: <394701D6.37E6F560@yahoo.com> <20000613222142.A27523@activestate.com> <394745C1.7FA27DCB@lemburg.com> <20000614103632.C29778@activestate.com> Message-ID: <39491d4f.4591422@smtp.worldonline.dk> >On Wed, Jun 14, 2000 at 10:43:45AM +0200, M . -A . Lemburg wrote: >> >> I guess it's a bug... a subtle one though, because in a >> certain sense both 1 and 0 are acceptable. But since >> '' is considered to be false, I think that returning 0 >> makes more sense. >> >> I'll fix this to return 0 for emtpy strings and Unicode objects. [Trent Mick] >These are copied from Java, are they not? What do the Java equivalents >return? The .isXX methods does not exists on java strings, only on the Character class. So in java they can never be called on anything with length 0. regards, finn From trentm at activestate.com Thu Jun 15 20:28:57 2000 From: trentm at activestate.com (Trent Mick) Date: Thu, 15 Jun 2000 11:28:57 -0700 Subject: [Python-Dev] Re: stringobject question In-Reply-To: <39491d4f.4591422@smtp.worldonline.dk> References: <394701D6.37E6F560@yahoo.com> <20000613222142.A27523@activestate.com> <394745C1.7FA27DCB@lemburg.com> <20000614103632.C29778@activestate.com> <39491d4f.4591422@smtp.worldonline.dk> Message-ID: <20000615112857.A4508@activestate.com> On Thu, Jun 15, 2000 at 06:16:03PM +0000, Finn Bock wrote: > >These are copied from Java, are they not? What do the Java equivalents > >return? > > The .isXX methods does not exists on java strings, only on the Character > class. So in java they can never be called on anything with length 0. > Okeedoke, so go with the changes that MAL made s.t. ''.isdigit() returns 0, unless others have any opposition. Trent -- Trent Mick trentm at activestate.com From fdrake at beopen.com Thu Jun 15 20:34:02 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 15 Jun 2000 14:34:02 -0400 (EDT) Subject: [Python-Dev] Re: stringobject question In-Reply-To: <20000615112857.A4508@activestate.com> References: <394701D6.37E6F560@yahoo.com> <20000613222142.A27523@activestate.com> <394745C1.7FA27DCB@lemburg.com> <20000614103632.C29778@activestate.com> <39491d4f.4591422@smtp.worldonline.dk> <20000615112857.A4508@activestate.com> Message-ID: <14665.8602.65230.481663@cj42289-a.reston1.va.home.com> Trent Mick writes: > Okeedoke, so go with the changes that MAL made s.t. ''.isdigit() returns 0, > unless others have any opposition. This sounds good to me. Marc-Andre, go ahead and checkin anything that isn't already in whenever you're ready; I've not seen any hints of opposition yet, and there's been enough waiting to just check it in. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From trentm at activestate.com Thu Jun 15 20:58:27 2000 From: trentm at activestate.com (Trent Mick) Date: Thu, 15 Jun 2000 11:58:27 -0700 Subject: [Python-Dev] Re: stringobject question In-Reply-To: <14665.8602.65230.481663@cj42289-a.reston1.va.home.com> References: <394701D6.37E6F560@yahoo.com> <20000613222142.A27523@activestate.com> <394745C1.7FA27DCB@lemburg.com> <20000614103632.C29778@activestate.com> <39491d4f.4591422@smtp.worldonline.dk> <20000615112857.A4508@activestate.com> <14665.8602.65230.481663@cj42289-a.reston1.va.home.com> Message-ID: <20000615115827.A4657@activestate.com> On Thu, Jun 15, 2000 at 02:34:02PM -0400, Fred L. Drake, Jr. wrote: > > Trent Mick writes: > > Okeedoke, so go with the changes that MAL made s.t. ''.isdigit() returns 0, > > unless others have any opposition. > > This sounds good to me. > Marc-Andre, go ahead and checkin anything that isn't already in > whenever you're ready; I've not seen any hints of opposition yet, and > there's been enough waiting to just check it in. > From mal at lemburg.com Thu Jun 15 21:10:43 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 15 Jun 2000 21:10:43 +0200 Subject: [Python-Dev] Re: stringobject question References: <394701D6.37E6F560@yahoo.com> <20000613222142.A27523@activestate.com> <394745C1.7FA27DCB@lemburg.com> <20000614103632.C29778@activestate.com> <39491d4f.4591422@smtp.worldonline.dk> <20000615112857.A4508@activestate.com> <14665.8602.65230.481663@cj42289-a.reston1.va.home.com> <20000615115827.A4657@activestate.com> Message-ID: <39492A33.75440AA4@lemburg.com> Trent Mick wrote: > > On Thu, Jun 15, 2000 at 02:34:02PM -0400, Fred L. Drake, Jr. wrote: > > > > Trent Mick writes: > > > Okeedoke, so go with the changes that MAL made s.t. ''.isdigit() returns 0, > > > unless others have any opposition. > > > > This sounds good to me. > > Marc-Andre, go ahead and checkin anything that isn't already in > > whenever you're ready; I've not seen any hints of opposition yet, and > > there's been enough waiting to just check it in. > > > > >From what I have seen it is already in. Right ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fdrake at beopen.com Thu Jun 15 21:21:40 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 15 Jun 2000 15:21:40 -0400 (EDT) Subject: [Python-Dev] Re: stringobject question In-Reply-To: <39492A33.75440AA4@lemburg.com> References: <394701D6.37E6F560@yahoo.com> <20000613222142.A27523@activestate.com> <394745C1.7FA27DCB@lemburg.com> <20000614103632.C29778@activestate.com> <39491d4f.4591422@smtp.worldonline.dk> <20000615112857.A4508@activestate.com> <14665.8602.65230.481663@cj42289-a.reston1.va.home.com> <20000615115827.A4657@activestate.com> <39492A33.75440AA4@lemburg.com> Message-ID: <14665.11460.597390.222317@cj42289-a.reston1.va.home.com> M.-A. Lemburg writes: > Trent Mick wrote: > > >From what I have seen it is already in. > > Right ;-) I may have mentioned that I've been losing track of all the patches. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From thomas at xs4all.net Thu Jun 15 23:41:53 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 15 Jun 2000 23:41:53 +0200 Subject: [Python-Dev] Augmented assignment In-Reply-To: <39491CA2.2BDC0DDC@lemburg.com>; from mal@lemburg.com on Thu, Jun 15, 2000 at 08:12:50PM +0200 References: <20000615195327.R8000@xs4all.nl> <39491CA2.2BDC0DDC@lemburg.com> Message-ID: <20000615234153.S8000@xs4all.nl> On Thu, Jun 15, 2000 at 08:12:50PM +0200, M.-A. Lemburg wrote: > > I'd like some (minor) feedback on the augmented assignment thing I'm working > > on. I understand Guido is the only one who accepts patches like this, and > > appreciate that, but I'm hoping someone can at least tell me what I'm doing > > wrong so I can fix it before Guido sees it ;-) But if I'm being an impatient > > flap, just tell me so and I'll calm down. > I'd make this a 1.7 issue. 1.6 should go into the stabilization > phase and big complicated patches like yours should receive some > more design and concept discussion before getting checked in. That's more or less what I figured, though I wasn't aware of the revised schedule on 1.6 ;) > BTW, with "augmented assign" I suppose you mean things like > a += 1 and b *= 2, right ? Yes; All binary operands, to be exact: '+=' | '-=' | '*=' | '/=' | '%=' | '&=' | '|=' | '^=' | '<<=' | '>>=' | '**=' > Any reason you can't do this with the existing op codes ? > > E.g. a += b > > 1. load a > 2. load b > 3. add > 4. store a Yes: It wouldn't be thread-safe, and it would be impossible (or at least very hard and complicated) to see the difference between 'a += b' and 'a = a + b', which would make it very hard to make them functionally different. The patch not only adds the syntax (Michael Hudsons' patch did that, roughly how you describe it) but also adds generic semantics for in-place operations on builtin types, extension types and classes. > > * The patch also needs to add 11 new __hooks__, 11 new API calls, 11 new entries > > in the PyNumberMethods struct and 2 new entries in the PySequenceMethods > > struct. Would that conceivably be a problem ? I've heard people on the > > python-list complain about this ;-P > More generic solutions are usually more accepted. I thought so, but I didn't see a good, simple addition to the API that wasn't too complicated. What it adds now is 'PyNumber_InPlaceAdd()', which is functionally the same as 'PyNumber_Add()', except that the left-hand-side object is given the chance to define the operation in-place. That's also where the new PyNumberMethods/PySequenceMethods members come in. > BTW, before hacking too much into this, you ought to consider > that we are planning for rich comparisons and decentralized > coercion in 1.7 (this was planned for 1.6, but David and I > got carried away with other things). Too late. Most, if not all, of the patch is already written. Not that that's a reason to accept it, not at all ;) > I wouldn't want to have to hack 11 new slots to get this right... I'm not sure if that's necessary, but I'll have to look into your comparison/coercion work before I can say that for sure. In any case, I'd be perfectly happy with adjusting the augmented-assignment patch to the comparison/coercion change, instead of the other way 'round ;) > > * Should I start sending the patch, in pieces, to the patches-list, or is > > it a wasted effort because noone will touch it until Guido is back ? If I > > should send it, should I send it in one large patch (minus autogenerated > > files) or in nice functionality-sized pieces ? > Better put it on a web page and inform python-dev of new features, > enhancements, etc. The webpage is already there, with the version I sent to python-list last Friday. That patch is missing quite a few things, but it serves as an example of what it should do: http://www.xs4all.nl/~thomas/python/ I hope to upload an almost-finished version tomorrow morning (Amsterdam time) - if work doesn't intervene again. > > * How 'cool' does Guido actually think this syntax is ? Apparently the > > subject has come up a few times ;) and I got positive signals from both Tim > > and Guido, but if the patch won't go in as a patch, and won't actually be > > used other than some inspiration for a future rewrite of the CPython core, > > I'm not going to worry too much about the patch ;) > Having a patch is good for discussion, whether it gets incorporated > is a different issue ;-) Of course :) The thing is, the patch is actually quite done. What I'm doing now is more or less auditing and optimizing it, and that is probably a waste of time if the patch is going to need a complete rewrite anyway. On the other hand, I'm getting a couple of ideas for optimization of the 'normal' operations too, so it's not like it's wasted time. I guess I'll start a new thread on that issue if/when I reach it ;) Thanx for the feedback! -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From pf at artcom-gmbh.de Thu Jun 15 23:30:45 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Thu, 15 Jun 2000 23:30:45 +0200 (MEST) Subject: [Python-Dev] Augmented assignment In-Reply-To: <20000615195327.R8000@xs4all.nl> from Thomas Wouters at "Jun 15, 2000 7:53:27 pm" Message-ID: Hi! Thomas Wouters: > I'd like some (minor) feedback on the augmented assignment thing I'm working > on. I understand Guido is the only one who accepts patches like this, and > appreciate that, but I'm hoping someone can at least tell me what I'm doing > wrong so I can fix it before Guido sees it ;-) But if I'm being an impatient > flap, just tell me so and I'll calm down. Disclaimer: The following is only *my* personal opinion. But since you have asked for it. ;-) I don't like this augmented assignment syntax at all! (independent from your particular implementation, which I didn't had a look at). Augmented assignments are unPythonic because they don't add any new functionality to the language. From what I've seen, all people, who ever missed it, were experienced C-programmers. And C shows its inheritance from various assembler languages in its augmented assignment and its ++pre and post increment++ and decrement-- operators. Many of these features were born in the 70s of the last century: At that time optimizing was very important and compilers were relatively dumb. This applies in no way to the situation we have today with Python. What remains is, that augmented assignments are only a short cut notation, which introduces more variability to express the same algorithms and so they hurt readability. This feature must be learned additionally, where normal assignment are easiely understood from school mathematics. It also introduces many more possibilities to make subtle mistakes, since it is not obvious (at least to No-C-programmers) when and how often the index expression will be valuated. Look at the following example: class Bar: def __init__(self): self.val = 0 def __call__(self): self.val = self.val + 1 return self.val bar = Bar() foo = range(4) and than foo[bar()] = foo[bar()] + bar() print foo versus foo[bar()] += bar() print foo Todays Python forces the programmer to explicitly say, what should happen. So I think these +=,-=,*= features are evil. In the same sense as macro preprocessors are evil in 'C' and 'from module import *' is already evil in Python. Add more and more of this stuff and you end up on the dark side of programming. If augmented assignments will ever become part of Python, I would at least like to see a strong recommendation added to the styleguide not to use this feature. Enough with this rant. Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen) From nascheme at enme.ucalgary.ca Fri Jun 16 00:26:35 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Thu, 15 Jun 2000 16:26:35 -0600 Subject: [Python-Dev] Augmented assignment In-Reply-To: ; from pf@artcom-gmbh.de on Thu, Jun 15, 2000 at 11:30:45PM +0200 References: <20000615195327.R8000@xs4all.nl> Message-ID: <20000615162635.B11507@acs.ucalgary.ca> On Thu, Jun 15, 2000 at 11:30:45PM +0200, Peter Funk wrote: > Augmented assignments are unPythonic because they don't add any new > functionality to the language. [...] > foo[bar()] = foo[bar()] + bar() > versus > foo[bar()] += bar() Not quite. I think with the proposed implementation += could modify the LHS object in place. This could be a big performance win for things like NumPy objects. OTOH, the same effect can be achieved with a method call: foo[bar()].add(bar()) Neil From thomas at xs4all.net Fri Jun 16 00:25:23 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 16 Jun 2000 00:25:23 +0200 Subject: [Python-Dev] Augmented assignment In-Reply-To: ; from pf@artcom-gmbh.de on Thu, Jun 15, 2000 at 11:30:45PM +0200 References: <20000615195327.R8000@xs4all.nl> Message-ID: <20000616002523.T8000@xs4all.nl> On Thu, Jun 15, 2000 at 11:30:45PM +0200, Peter Funk wrote: > Thomas Wouters: > > I'd like some (minor) feedback on the augmented assignment thing I'm working > > on. I understand Guido is the only one who accepts patches like this, and > > appreciate that, but I'm hoping someone can at least tell me what I'm doing > > wrong so I can fix it before Guido sees it ;-) But if I'm being an impatient > > flap, just tell me so and I'll calm down. > I don't like this augmented assignment syntax at all! (independent > from your particular implementation, which I didn't had a look at). > Augmented assignments are unPythonic because they don't add any new > functionality to the language. [ snip quite good summary of the problems with augmented assignment ] I agree with almost all of the above, except the statement that they do not add anything. If augmented assignment was only syntactic sugar I would not have taken Michael's patch and rewritten it; I do not propose auto-increment operators, and would have a hard time accepting them. However, augmented assignment *does* add new functionality, because it is a way to inform the object that is being operated on, that it can do the operation in-place if it so wants. Instead of having to create a new object, which might be costly in cpu and/or memory, and doing the operation on that, the object can choose to do the operation on itself, and return 'self'. If the object doesn't want to do that, it doesn't have to be any different from 'x = x + 1'. (In fact, augmented assignment should, and does, fall back to that.) > > > [ snip good example of indexes-with-sideffect ] > > This actually proves the point of augmented assignment. With the syntax foo[bar()] += 1 You can see that bar() is only called once, so you *know* what index is being retrieved, and that the new value is stored in the same place. Using foo[bar()] = foo[bar()] + 1 you can't see by the expression which value is being retrieved and where the result is stored. You have to remember the rules about operand evaluation to see that. Yes, foo[bar()] += bar() is indeed more complicated than the above example, but absolutely not more complicated than the normal-add version that calls bar() three times. The augmented assignment syntax is actually clearer and more easy to explain, in my opinion. You can only (accurately) explain a = a + 1 as 'add a and 1, and store the result in a'. However, a += 1 is simply 'add 1 to a'. > So I think these +=,-=,*= features are evil. In the same sense as macro > preprocessors are evil in 'C' and 'from module import *' is already evil > in Python. Add more and more of this stuff and you end up on the dark > side of programming. Well, I like the odd Star Wars film, but I do not believe that the Dark Side lies opposite the Right Way. The Right Way can't help but be very close to the Dark Side. You may dislike macro preprocessors in C, but CPython (and almost all other C code) do use them alot, for functionality which would otherwise be very hard (or complicated and unreadable) to achieve. The same goes for 'from module import *' in Python. The funny thing is that augmented assignment operators and auto in/decrement operators might be added to C because they were easier to optimize (I dont think that was the main reason, but I wasn't there ;) but any halfway decent C compiler doesn't need that explicitness, and can optimize the 'x = x + 1' expression directly. Python, however, can (currently) not do that, and *does* need the added syntax to be able to do optimization, even if only to let the object know it's safe to operate on itself. Of course, once there are semantics for inplace-operations, it _might_ be possible to optimize 'x = x + 1' into 'x += 1' ;) > If augmented assignments will ever become part of Python, I would at least > like to see a strong recommendation added to the styleguide not to use > this feature. If such a recommendation was added, the change would be useless. Better get Guido to not add this feature instead, or Python will end up like Perl ;) I honestly do not care much wether it gets added or not. If Guido decides not to add it, I'm certain he has very valid rasons for it, and I dont assume to know as much about Python, the applicability of Python, the average usage of Python or the Future of Python as he sees it, as him ;) I-don't-know-any-of-that-in-fact-ly y'rs ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From gmcm at hypernet.com Fri Jun 16 02:44:38 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Thu, 15 Jun 2000 20:44:38 -0400 Subject: [Python-Dev] Augmented assignment In-Reply-To: References: <20000615195327.R8000@xs4all.nl> from Thomas Wouters at "Jun 15, 2000 7:53:27 pm" Message-ID: <1251006162-53585376@hypernet.com> Peter Funk wrote: > Augmented assignments are unPythonic because they don't add any > new functionality to the language. Most changes to Python are nothing but syntactic sugar. In concept, I'm +0.9 on simple "name += val". I'm -0.9 on "expr += val" if the behavior requires an understanding of Python internals, and +0 otherwise (since I avoid "expr = expr + val" if possible). Thomas's statement that the complexity is largely due to problems of thread safety is eminently believable, and I doubt that the syntactic sugar (which is at least somewhat desirable) is worth the price. > .... Many of these features were born in the > 70s of the last century: At that time optimizing was very > important and compilers were relatively dumb. This applies in no > way to the situation we have today with Python. Actually, Python's compiler is very dumb, and optimization is still important. So where I would use "expr" 3 times in 3 lines in C / C++ and *expect* the compiler to optimize it into one evaluation, I have to remind myself to use an extra line and compute it once in Python myself. One might argue that that's unPythonic, because it inhibits the direct expression of the idea. One might, but I won't. > What remains is, that augmented assignments are only a short cut > notation, which introduces more variability to express the same > algorithms and so they hurt readability. It definitely *improves* the readability of incrementing very-long- expression. Just not to the point of readability ;-). > ... It also introduces many more > possibilities to make subtle mistakes, and eliminates othes, such as typos... > since it is not obvious > (at least to No-C-programmers) when and how often the index > expression will be valuated. Look at the following example: > > class Bar: > def __init__(self): > self.val = 0 > def __call__(self): > self.val = self.val + 1 > return self.val > bar = Bar() > foo = range(4) > and than > foo[bar()] = foo[bar()] + bar() > print foo > versus > foo[bar()] += bar() > print foo To understand the first requires a sufficiently deep understanding of how Python works that I doubt the 2nd is really much worse. They're both the other side of horrid. I don't care very much myself, but none of these arguments are without strong counters (which we've all read many times on c.l.py). The only real basis, I think, is whether the changes complexify things too much. - Gordon From pf at artcom-gmbh.de Fri Jun 16 09:11:57 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Fri, 16 Jun 2000 09:11:57 +0200 (MEST) Subject: [Python-Dev] Augmented assignment In-Reply-To: <1251006162-53585376@hypernet.com> from Gordon McMillan at "Jun 15, 2000 8:44:38 pm" Message-ID: Hi, [...] [me]: > > What remains is, that augmented assignments are only a short cut > > notation, which introduces more variability to express the same > > algorithms and so they hurt readability. [Gordon McMillan]: > It definitely *improves* the readability of incrementing very-long- > expression. Just not to the point of readability ;-). I agree, that very complicated multidimensional expressions, (possible mixing tuples, lists, dicts and computations) are even more errorprone , if you have to repeat them twice just to increment an element. But than you would use an helper variable to hold the index expression anyway. example: foo = range(3); bar = range(3); cols = ('red', 'green', 'blue') chans = {'red':2, 'green':1, 'blue':0} foo[chans[cols[2-bar[0]]]] = foo[chans[cols[2-bar[0]]]] + 1 is indeed ugly. But i = chans[cols[2-bar[0]]]; foo[i] = foo[i] + 1 is at least just as (un)readable as foo[chans[cols[bar[0]]]] += 1 with the exception, that even newbies get a chance to figure out, what the former line is supposed to do without having to read a language reference manual telling them something about augmented assignments. But you are right: This has been discussed often enough on c.l.p. Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen) From effbot at telia.com Fri Jun 16 18:24:26 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 16 Jun 2000 18:24:26 +0200 Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface? Message-ID: <000a01bfd7af$582a9ea0$f2a6b5d4@hagrid> (the eff-bot is back!) is there any special reason for this restriction: Python 1.6a2 (#0, Jun 14 2000, 23:07:49) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> a = [1, 2, 3] >>> a.extend((4, 5, 6)) Traceback (most recent call last): File "", line 1, in ? TypeError: list.extend() argument must be a list from the look of it, it should be trivial to change list.extend to use the abstract sequence API instead of the list API. has anyone benchmarked the abstract sequence API? how much slower is it? would it be a good idea to treat lists as a special case, to avoid slowing down existing code? other comments? if I don't hear anything, I'll post patches later this weekend. From effbot at telia.com Fri Jun 16 18:41:36 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 16 Jun 2000 18:41:36 +0200 Subject: [Python-Dev] possible Tkinter speedup Message-ID: <001401bfd7b1$bdf9a120$f2a6b5d4@hagrid> the _flatten method in Tkinter is one of the major performance bottlenecks for Python/Tk programmers. the method "flattens" a nested sequence, by repeatedly adding tuples to each other. obviously, this isn't very efficient if the sequences are longer than, say, five to ten items... and has of course led to claims like "wxPython is a thousand times faster than Tkinter". anyway, taking recent changes to Python into account, it should be possible to speed this up quite a bit. the old code looked like this: def _flatten(tuple): res = () for item in tuple: if type(item) in (TupleType, ListType): res = res + _flatten(item) elif item is not None: res = res + (item,) return res after a some trials and errors, here's my proposed replacement: def _flatten1(seq): res = [] for item in seq: if type(item) in (TupleType, ListType): res.extend(_flatten1(item)) elif item is not None: res.append(item) return res def _flatten(seq): return tuple(_flatten1(seq)) in my tests, this is slighly faster on very short sequences (two coordinate pairs, which is a common case for e.g. rectangles), and much faster on long sequences (polylines, polygons). for example, for a 5000-point line, it's about 15 times faster. on a 10,000 point line, it's over 50 times faster. etc. comments? can anyone come up with an even faster way to do this? if I don't hear anything negative, I'll post patches (etc) PS. even after this optimization, uiToolkit is still about 100 times faster than Tkinter, but that's another story ;-) From effbot at telia.com Fri Jun 16 18:47:01 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 16 Jun 2000 18:47:01 +0200 Subject: [Python-Dev] Q: is concatenation and append really the same thing? Message-ID: <001e01bfd7b2$7fc91ba0$f2a6b5d4@hagrid> Python 1.6a2 (#0, Jun 14 2000, 23:07:49) [MSC 32 bit (Intel)] on win32 >>> (1, 2, 3) + [1, 2, 3] Traceback (most recent call last): File "", line 1, in ? TypeError: can only append tuple (not "list") to tuple is "append" really the right word here? sure confused the hell out of yours truly... ("there's no friggin' append call in this code") From jeremy at beopen.com Fri Jun 16 18:45:07 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 16 Jun 2000 12:45:07 -0400 (EDT) Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface? In-Reply-To: <000a01bfd7af$582a9ea0$f2a6b5d4@hagrid> References: <000a01bfd7af$582a9ea0$f2a6b5d4@hagrid> Message-ID: <14666.22931.521438.936776@localhost.localdomain> >>>>> "FL" == Fredrik Lundh writes: FL> has anyone benchmarked the abstract sequence API? how much FL> slower is it? would it be a good idea to treat lists as a FL> special case, to avoid slowing down existing code? The abstract interface is fairly expensive. The current code uses PyList_GET_ITEM to access the elements of the list. The abstract interface adds two function calls (PySequence_GetItem, PyList_GetItem). The first function just does a couple of sanity checks (verify arg is sequence & that it has get_item). The second function verifies that the arg is a list, then does a bounds check. None of the work that either of these functions does is necessary for the list case! In the extended call syntax implementation, I used PySequence_Tuple to handle non-standard sequences. Once converted to a tuple, they can be processed using the macros. If you support user-defined sequences, the sanity checking can get pretty hairy if you don't coerce to a tuple; e.g. the PySequence_Length method can lie! I don't remember considering the cost of allocating the new tuple, which is only used internally. Jeremy From thomas at xs4all.net Fri Jun 16 18:45:14 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Fri, 16 Jun 2000 18:45:14 +0200 Subject: [Python-Dev] Augmented assignment, update Message-ID: <20000616184514.Q26436@xs4all.nl> I've more or less finished the augmented-assignment patch I posted last week. It can be found, including a longish explanation, here: http://www.xs4all.nl/~thomas/python/ (For those who missed it, the previous posting is here: http://www.python.org/pipermail/python-list/2000-June/060680.html The link in the posting, however, points to the new patch.) I do not know if augmented assignment will every be incorporated into Python (this patch or something entirely different) but at least noone can claim the groundwork is missing :-) Feel free to send questions, comments and verbal abuse my way ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From mwh21 at cam.ac.uk Fri Jun 16 18:53:42 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 16 Jun 2000 17:53:42 +0100 Subject: [Python-Dev] Q: is concatenation and append really the same thing? In-Reply-To: "Fredrik Lundh"'s message of "Fri, 16 Jun 2000 18:47:01 +0200" References: <001e01bfd7b2$7fc91ba0$f2a6b5d4@hagrid> Message-ID: "Fredrik Lundh" writes: > Python 1.6a2 (#0, Jun 14 2000, 23:07:49) [MSC 32 bit (Intel)] on win32 > >>> (1, 2, 3) + [1, 2, 3] > Traceback (most recent call last): > File "", line 1, in ? > TypeError: can only append tuple (not "list") to tuple > > is "append" really the right word here? My fault. I have sent at least one patch to patches at python.org to change it to can only concatenate tuple (not "list") to tuple to bring it into line with listobject.c; here it is again: Index: Objects/tupleobject.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Objects/tupleobject.c,v retrieving revision 2.34 diff -u -r2.34 tupleobject.c --- Objects/tupleobject.c 2000/06/01 03:12:13 2.34 +++ Objects/tupleobject.c 2000/06/06 16:30:39 @@ -362,7 +362,7 @@ PyTupleObject *np; if (!PyTuple_Check(bb)) { PyErr_Format(PyExc_TypeError, - "can only append tuple (not \"%.200s\") to tuple", + "can only concatenate tuple (not \"%.200s\") to tuple", bb->ob_type->tp_name); return NULL; } HTH, HAND, Michael From mal at lemburg.com Fri Jun 16 18:53:59 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 16 Jun 2000 18:53:59 +0200 Subject: [Python-Dev] possible Tkinter speedup References: <001401bfd7b1$bdf9a120$f2a6b5d4@hagrid> Message-ID: <394A5BA7.F001E220@lemburg.com> Fredrik Lundh wrote: > > the _flatten method in Tkinter is one of the major performance > bottlenecks for Python/Tk programmers. the method "flattens" > a nested sequence, by repeatedly adding tuples to each other. > > obviously, this isn't very efficient if the sequences are longer > than, say, five to ten items... and has of course led to claims > like "wxPython is a thousand times faster than Tkinter". > > anyway, taking recent changes to Python into account, it should > be possible to speed this up quite a bit. > > the old code looked like this: > > def _flatten(tuple): > res = () > for item in tuple: > if type(item) in (TupleType, ListType): > res = res + _flatten(item) > elif item is not None: > res = res + (item,) > return res > > after a some trials and errors, here's my proposed replacement: > > def _flatten1(seq): > res = [] > for item in seq: > if type(item) in (TupleType, ListType): > res.extend(_flatten1(item)) > elif item is not None: > res.append(item) > return res > > def _flatten(seq): > return tuple(_flatten1(seq)) > > in my tests, this is slighly faster on very short sequences (two > coordinate pairs, which is a common case for e.g. rectangles), > and much faster on long sequences (polylines, polygons). > > for example, for a 5000-point line, it's about 15 times faster. > on a 10,000 point line, it's over 50 times faster. etc. > > comments? Why not implement this in C and add it to _tkinter.c ? It might even make a nice standard builtin... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fdrake at beopen.com Fri Jun 16 19:02:22 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 16 Jun 2000 13:02:22 -0400 (EDT) Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface? In-Reply-To: <000a01bfd7af$582a9ea0$f2a6b5d4@hagrid> References: <000a01bfd7af$582a9ea0$f2a6b5d4@hagrid> Message-ID: <14666.23966.437909.949260@cj42289-a.reston1.va.home.com> Fredrik Lundh writes: > if I don't hear anything, I'll post patches later this weekend. Sounds good to me! If lists and tuples are special cased, it shouldn't even matter if the sequence API is too slow -- that's new functionality for [].extend(), and can be optimized later if it needs to be. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From mal at lemburg.com Fri Jun 16 19:07:40 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 16 Jun 2000 19:07:40 +0200 Subject: [Python-Dev] Q: is concatenation and append really the same thing? References: <001e01bfd7b2$7fc91ba0$f2a6b5d4@hagrid> Message-ID: <394A5EDC.7431C900@lemburg.com> Michael Hudson wrote: > > "Fredrik Lundh" writes: > > > Python 1.6a2 (#0, Jun 14 2000, 23:07:49) [MSC 32 bit (Intel)] on win32 > > >>> (1, 2, 3) + [1, 2, 3] > > Traceback (most recent call last): > > File "", line 1, in ? > > TypeError: can only append tuple (not "list") to tuple > > > > is "append" really the right word here? > > My fault. I have sent at least one patch to patches at python.org to > change it to > > can only concatenate tuple (not "list") to tuple > > to bring it into line with listobject.c; here it is again: > > Index: Objects/tupleobject.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Objects/tupleobject.c,v > retrieving revision 2.34 > diff -u -r2.34 tupleobject.c > --- Objects/tupleobject.c 2000/06/01 03:12:13 2.34 > +++ Objects/tupleobject.c 2000/06/06 16:30:39 > @@ -362,7 +362,7 @@ > PyTupleObject *np; > if (!PyTuple_Check(bb)) { > PyErr_Format(PyExc_TypeError, > - "can only append tuple (not \"%.200s\") to tuple", > + "can only concatenate tuple (not \"%.200s\") to tuple", > bb->ob_type->tp_name); > return NULL; > } > Should be in CVS by now... Thanks, -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fdrake at beopen.com Fri Jun 16 19:13:55 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 16 Jun 2000 13:13:55 -0400 (EDT) Subject: [Python-Dev] mailbox formats Message-ID: <14666.24659.9174.717901@cj42289-a.reston1.va.home.com> I've been playing with a function to open a mailbox and return the appropriate type of mailbox object from the mailbox module, but I don't have examples of anything but mbox style mailboxes to test with. Could anyone send real examples of MMDF, MH, maildir, and Babyl mailboxes? The mail can be junk; don't send anything I shouldn't see! Essentially, I'd like to see two new functions added to the mailbox module: open('name'), which returns a mailbox object opened for reading, and which('name'), which returns the name of the mailbox constructor, and possibly a flag indicating whether a __builtin__.open() is needed. Thanks! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From mal at lemburg.com Fri Jun 16 20:59:39 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 16 Jun 2000 20:59:39 +0200 Subject: [Python-Dev] Announcment list Message-ID: <394A791B.17F5AEFF@lemburg.com> Does anybody know about the state of the python-announce mailing list ? I've sent an announcement there (about mxCGIPython), but have only received an error message and got no posting back from the list. I posted a note to the postmaster at beopen.com, but have heard nothing from there yet. Can somebody please look into this ?! BTW, what about the announcement list -> c.l.p.a gateway ? Will that happen anytime soon (or do I have to hack the headers to post there ? ;-) Here's the error message: """ Subject: failure notice Date: 13 Jun 2000 11:34:39 -0000 From: MAILER-DAEMON at starship.beopen.com To: mal at lemburg.com Hi. This is the qmail-send program at starship.beopen.com. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. : Sorry, no mailbox here by that name. (#5.1.1) --- Below this line is a copy of the message. Return-Path: Received: (qmail 31495 invoked from network); 13 Jun 2000 11:34:38 -0000 Received: from dinsdale.cnri.reston.va.us (HELO dinsdale.python.org) (132.151.1.21) by starship.beopen.com with SMTP; 13 Jun 2000 11:34:38 -0000 Received: by dinsdale.python.org (Postfix) id AD6DD1CDE3; Tue, 13 Jun 2000 07:29:56 -0400 (EDT) Delivered-To: python-announce-people at python.org ... """ -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From bwarsaw at python.org Fri Jun 16 21:24:21 2000 From: bwarsaw at python.org (Barry A. Warsaw) Date: Fri, 16 Jun 2000 15:24:21 -0400 (EDT) Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface? References: <000a01bfd7af$582a9ea0$f2a6b5d4@hagrid> <14666.23966.437909.949260@cj42289-a.reston1.va.home.com> Message-ID: <14666.32485.172984.122789@anthem.concentric.net> >>>>> "Fred" == Fred L Drake, Jr writes: Fred> Sounds good to me! If lists and tuples are special cased, Fred> it shouldn't even matter if the sequence API is too slow -- Fred> that's new functionality for [].extend(), and can be Fred> optimized later if it needs to be. This has been a typical implementation strategy for a long while now, and I think successfully so. When I removed the distinction between list and tuple unpacking to allow any sequence unpacking (and incidently w/o special syntax), I did exactly this. Special case for tuples and lists, and if it was neither then use the sequence API. Jeremy's right that this can get hairy if your as anal as I am about error checking and refcounting. In addition to PySequence_Length() ability to lie, there are all sorts of errors that can happen, which should abort the whole process and clean up any temporary objects. Plus you've now got three very similar branches in the code, which adds its own overhead. So you should decide whether this situation will be used widely enough to warrant the extra coding complexity for the performance win. list.extend() is probably not used too often these days, but it should be 'cause it's cool. So maybe it's worth it in this case. On the other hand, this is a situation that comes up often, and if we were to really audit the APIs, we'd probably find even more cases where restrictions to concrete lists or tuples should be relaxed to accept any sequence. Maybe there's a way we can factor this out in a single function which handles this once and for all? -Barry From paul at prescod.net Fri Jun 16 21:22:08 2000 From: paul at prescod.net (Paul Prescod) Date: Fri, 16 Jun 2000 21:22:08 +0200 Subject: [Python-Dev] Augmented assignment References: Message-ID: <394A7E60.6F715424@prescod.net> Many people have given examples where the augmented assignment version is substantially more readable. Others have argued that it is more explicit in that it says *exactly what you mean* rather than using a more general operator in a specific (common) situation. Another important argument is that augmented assignment allows *in place* assignment for some types. That's really important for matrix math etc. All of these arguments convince me that this is not a simple matter of "another notation for what we already do." > Augmented assignments are unPythonic because they don't add any new > functionality to the language. From what I've seen, all people, > who ever missed it, were experienced C-programmers. That's true, but we should not be ashamed to steal good ideas from other languages. Probably the only people who would miss __getattr__ would be SmallTalk programmers and the original proponents of the various operator overloading features may well have come from C++. > ... > This feature must be learned > additionally, where normal assignment are easiely understood from > school mathematics. Not really! a=a+1 is totally illegal in basic arithmetic. > It also introduces many more possibilities to make > subtle mistakes, since it is not obvious (at least to No-C-programmers) > when and how often the index expression will be valuated. As I understand the proposal, the function will be called exactly as many times as it is printed in the source code: > versus > foo[bar()] += bar() > print foo Presumably bar() gets called twice. The only argument against this that is persusaive to me is that it makes the core Python language larger and thus a (little) harder to learn. My impression is that the design of the feature has been well done. My personal opinion is that the cost in education probably outweighs the benefits in clarity but others who work a lot with matrices etc. would probably have a different view. -- Paul Prescod - ISOGEN Consulting Engineer speaking for himself "Music is the stuff between the notes." - Claude Debussy From petrilli at amber.org Fri Jun 16 21:42:46 2000 From: petrilli at amber.org (Christopher Petrilli) Date: Fri, 16 Jun 2000 15:42:46 -0400 Subject: [Python-Dev] Augmented assignment In-Reply-To: <394A7E60.6F715424@prescod.net>; from paul@prescod.net on Fri, Jun 16, 2000 at 09:22:08PM +0200 References: <394A7E60.6F715424@prescod.net> Message-ID: <20000616154246.A5513@trump.amber.org> Paul Prescod [paul at prescod.net] wrote: > That's true, but we should not be ashamed to steal good ideas from other > languages. Probably the only people who would miss __getattr__ would be > SmallTalk programmers and the original proponents of the various > operator overloading features may well have come from C++. Actually as a good Talker, I write methods for everything, so I almost nver use __getattr__ except as a way to force people to use methods and not directly access attributes. Long story. Chris -- | Christopher Petrilli | petrilli at amber.org From fdrake at beopen.com Fri Jun 16 21:42:12 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 16 Jun 2000 15:42:12 -0400 (EDT) Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface? In-Reply-To: <14666.32485.172984.122789@anthem.concentric.net> References: <000a01bfd7af$582a9ea0$f2a6b5d4@hagrid> <14666.23966.437909.949260@cj42289-a.reston1.va.home.com> <14666.32485.172984.122789@anthem.concentric.net> Message-ID: <14666.33556.123258.252030@cj42289-a.reston1.va.home.com> Barry A. Warsaw writes: > Jeremy's right that this can get hairy if your as anal as I am about > error checking and refcounting. In addition to PySequence_Length() > ability to lie, there are all sorts of errors that can happen, which > should abort the whole process and clean up any temporary objects. > Plus you've now got three very similar branches in the code, which > adds its own overhead. > > So you should decide whether this situation will be used widely enough > to warrant the extra coding complexity for the performance win. > list.extend() is probably not used too often these days, but it should > be 'cause it's cool. So maybe it's worth it in this case. > > On the other hand, this is a situation that comes up often, and if we > were to really audit the APIs, we'd probably find even more cases > where restrictions to concrete lists or tuples should be relaxed to > accept any sequence. Maybe there's a way we can factor this out in a > single function which handles this once and for all? How about this: special case the list & tuple flavors (since that'll be roughly what's in there now), and for other sequences, convert to either a tuple or a list and let it pass through that special case, keeping a flag to discard the temporary list when done? There are two APIs, PySequence_List() and PySequence_Tuple(), which can take care of a lot of the machinery in dealing with sequences that lie about their length or otherwise break (during __getitem__() calls or whatever), that a large part of the work is done. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From mal at lemburg.com Fri Jun 16 21:45:16 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 16 Jun 2000 21:45:16 +0200 Subject: [Python-Dev] Augmented assignment References: <394A7E60.6F715424@prescod.net> Message-ID: <394A83CC.98F177DC@lemburg.com> Paul Prescod wrote: > > Augmented assignments are unPythonic because they don't add any new > > functionality to the language. From what I've seen, all people, > > who ever missed it, were experienced C-programmers. > > That's true, but we should not be ashamed to steal good ideas from other > languages. Probably the only people who would miss __getattr__ would be > SmallTalk programmers and the original proponents of the various > operator overloading features may well have come from C++. Don't forget the crowd of people doing environmental acquisition (you know who they are ;-). Honestly, I think that __getattr__ is one of the most useful hooks available on Python objects. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From jeremy at beopen.com Fri Jun 16 22:01:18 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 16 Jun 2000 16:01:18 -0400 (EDT) Subject: [Python-Dev] Augmented assignment In-Reply-To: <394A83CC.98F177DC@lemburg.com> References: <394A7E60.6F715424@prescod.net> <394A83CC.98F177DC@lemburg.com> Message-ID: <14666.34702.801826.453565@localhost.localdomain> I'm leery of acquisition, but we gotta have __getattr__. Jeremy >>>>> "MAL" == M -A Lemburg writes: MAL> Paul Prescod wrote: >> > Augmented assignments are unPythonic because they don't add any >> > new functionality to the language. From what I've seen, all >> > people, who ever missed it, were experienced C-programmers. >> >> That's true, but we should not be ashamed to steal good ideas >> from other languages. Probably the only people who would miss >> __getattr__ would be SmallTalk programmers and the original >> proponents of the various operator overloading features may well >> have come from C++. MAL> Don't forget the crowd of people doing environmental MAL> acquisition (you know who they are ;-). MAL> Honestly, I think that __getattr__ is one of the most useful MAL> hooks available on Python objects. From fdrake at beopen.com Fri Jun 16 23:44:05 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 16 Jun 2000 17:44:05 -0400 (EDT) Subject: [Python-Dev] possible Tkinter speedup In-Reply-To: <394A5BA7.F001E220@lemburg.com> References: <001401bfd7b1$bdf9a120$f2a6b5d4@hagrid> <394A5BA7.F001E220@lemburg.com> Message-ID: <14666.40869.331831.90682@cj42289-a.reston1.va.home.com> M.-A. Lemburg writes: > Why not implement this in C and add it to _tkinter.c ? I think this is the right approach; do you have an implementation? ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From effbot at telia.com Fri Jun 16 23:50:58 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 16 Jun 2000 23:50:58 +0200 Subject: [Python-Dev] possible Tkinter speedup References: <001401bfd7b1$bdf9a120$f2a6b5d4@hagrid> <394A5BA7.F001E220@lemburg.com> Message-ID: <015e01bfd7dc$f53daca0$f2a6b5d4@hagrid> mal wrote: > > for example, for a 5000-point line, it's about 15 times faster. > > on a 10,000 point line, it's over 50 times faster. etc. > > > > comments? > > Why not implement this in C and add it to _tkinter.c ? > It might even make a nice standard builtin... bang for the buck? getting a working C version is a whole lot of work, and I'd rather spend that time on things that can speed things up a whole lot more [1]. but if it's still raining tomorrow... 1) http://w1.132.telia.com/~u13208596/tkinter From effbot at telia.com Sat Jun 17 00:33:43 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 17 Jun 2000 00:33:43 +0200 Subject: [Python-Dev] possible Tkinter speedup References: <001401bfd7b1$bdf9a120$f2a6b5d4@hagrid> <394A5BA7.F001E220@lemburg.com> <015e01bfd7dc$f53daca0$f2a6b5d4@hagrid> Message-ID: <017101bfd7e2$f2d3a2c0$f2a6b5d4@hagrid> eff-bot wrote: > bang for the buck? > > getting a working C version is a whole lot of work okay, I just proved that I don't know what I'm talking about. it wasn't that hard, and the performance boost is rather interesting... for 5000 vertices: Tkinter 1.6: 10.44 seconds Tkinter 1.6 with new flatten: 0.27 seconds Tkinter 1.6 with C version of flatten: 2.57 milliseconds patch follows. From effbot at telia.com Sat Jun 17 09:55:16 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 17 Jun 2000 09:55:16 +0200 Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface? References: <000a01bfd7af$582a9ea0$f2a6b5d4@hagrid> <14666.22931.521438.936776@localhost.localdomain> Message-ID: <003501bfd831$8bb11a60$f2a6b5d4@hagrid> jeremy wrote: > FL> has anyone benchmarked the abstract sequence API? how much > FL> slower is it? would it be a good idea to treat lists as a > FL> special case, to avoid slowing down existing code? > > The abstract interface is fairly expensive. The current code uses > PyList_GET_ITEM to access the elements of the list. The abstract > interface adds two function calls (PySequence_GetItem, > PyList_GetItem). The first function just does a couple of sanity > checks (verify arg is sequence & that it has get_item). The second > function verifies that the arg is a list, then does a bounds check. > None of the work that either of these functions does is necessary for > the list case! just for the record, I just changed some generic sequence code to something like: if (PyList_Check(seq) || PyTuple_Check(seq)) Py_INCREF(seq); else if (PySequence_Check(seq)) { seq = PySequence_Tuple(seq); if (!seq) return NULL; } else { PyErr_SetString(PyExc_TypeError, "argument must be a sequence"); return NULL; } ... allocate PyObject_Length(seq) slots ... if (PyList_Check(seq)) ... list code using PyList_GET_ITEM else ... tuple code using PyTuple_GET_ITEM Py_DECREF(seq); for the standard case (lists, in this case), this resulted in a total speedup of 4 times (this includes some other overhead). so in other words, this construct is more than 4 times faster than plain use of PySequence_GetItem. guess it's time to fix a couple of things in PIL... From mhammond at skippinet.com.au Sat Jun 17 10:16:18 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sat, 17 Jun 2000 18:16:18 +1000 Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface? In-Reply-To: <003501bfd831$8bb11a60$f2a6b5d4@hagrid> Message-ID: /F: > just for the record, I just changed some generic sequence code > to something like: ... > so in other words, this construct is more than 4 times faster > than plain use of PySequence_GetItem. Good stuff! > guess it's time to fix a couple of things in PIL... Its a fair bit of code to duplicate everywhere you want the speed increase. How can we add a similar scheme to the core, so the changes people need to make are trivial (to the point where the change is zero!)? Mark. From effbot at telia.com Sat Jun 17 10:40:20 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 17 Jun 2000 10:40:20 +0200 Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface? References: Message-ID: <006a01bfd837$ac689840$f2a6b5d4@hagrid> mark wrote: > > so in other words, this construct is more than 4 times faster > > than plain use of PySequence_GetItem. > > Good stuff! > > > guess it's time to fix a couple of things in PIL... > > Its a fair bit of code to duplicate everywhere you want the speed increase. > How can we add a similar scheme to the core, so the changes people need to > make are trivial (to the point where the change is zero!)? the first part is trivial; just add something like this to Objects/abstract.c: PyObject* PySequence_TupleOrList(PyObject* seq) { if (PyList_Check(seq) || PyTuple_Check(seq)) Py_INCREF(seq); else if (PySequence_Check(seq)) seq = PySequence_Tuple(seq); else { PyErr_SetString(PyExc_TypeError, "argument must be a sequence"); seq = NULL; } return seq; } the second parts is harder -- and that's of course where the real performance boost comes from. as far as I'm aware, very few C compilers can "specialize" loops for you... From mal at lemburg.com Sat Jun 17 10:41:25 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat, 17 Jun 2000 10:41:25 +0200 Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface? References: Message-ID: <394B39B5.B478720E@lemburg.com> Mark Hammond wrote: > > /F: > > just for the record, I just changed some generic sequence code > > to something like: > ... > > so in other words, this construct is more than 4 times faster > > than plain use of PySequence_GetItem. > > Good stuff! > > > guess it's time to fix a couple of things in PIL... > > Its a fair bit of code to duplicate everywhere you want the speed increase. > How can we add a similar scheme to the core, so the changes people need to > make are trivial (to the point where the change is zero!)? We could add special code the standard type to PySequence_GetItem() et al., but it would still cause a C function call (not much, but noticable in inner loops). How about adding some inline markers to the most often used (and small) routines in the medium level abstract interface (PySequence_*, PyMapping_*, etc.) ?! Together with the special code for the native Python types this should yield a speedup for all extensions by simple virtue of a recompile... OTOH, changes to these APIs would need a recompile of the extensions too. BTW, I've used the same approach as Fredrik in mx.Tools. It does make great a difference... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal at lemburg.com Sat Jun 17 10:53:20 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat, 17 Jun 2000 10:53:20 +0200 Subject: [Python-Dev] Re: [Python-bugs-list] PRIVATE: interned->ma_table never free'd (PR#361) References: <20000617000834.C29B41CF4A@dinsdale.python.org> Message-ID: <394B3C80.248B4CB1@lemburg.com> cfandrich at 8cs.com wrote: > > Full_Name: Christopher Fandrich > Version: 1.5.2 > OS: Windows > Submission from: (NULL) (208.41.174.4) > > I'm embedding Python in an application. For now, all I'm doing is initializing > and finalizing Python. > > When I run my app I get a memory leak of 12288 bytes. The memory is malloc'ed > by dictresize() which is called by PyDict_SetItem() which is called by > PyString_InternInPlace(). > > For now, I've added > PyDict_Clear(interned); > interned = NULL; > to PyString_Fini(). So far it works fine, but I don't know if it's safe to do > in the grand scheme of things. I would suggest adding code to dealloc the interned dict iff it is empty after the sweeping action in PyString_Fini(). I have a feeling that this is not the case though, since interned strings are used quite a lot in the core interpreter (e.g. in classobject.c) and these are usually not recovered. Perhaps we ought to add some code which takes care of cleaning up all remaining garbage left over after the call to call_ll_exitfuncs() in Py_Finalize(), e.g. force free'ing of all interned strings and cached ints/floats and associated free lists or dicts. We'd need new APIs in string|float|intobject.c to implement this. Thoughts ? Patches ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From effbot at telia.com Sat Jun 17 14:45:57 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 17 Jun 2000 14:45:57 +0200 Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface? References: <006a01bfd837$ac689840$f2a6b5d4@hagrid> Message-ID: <00d701bfd859$fd435300$f2a6b5d4@hagrid> the eff-bot wrote: > the first part is trivial; just add something like this to > Objects/abstract.c: > > PyObject* > PySequence_TupleOrList(PyObject* seq) > ... > > the second parts is harder -- and that's of course where the > real performance boost comes from. as far as I'm aware, very > few C compilers can "specialize" loops for you... in the same test setup, moving the PyList_Check inside the loop gives a 25-30% slowdown (or to look at it from the other side, 3 times instead of 4 times faster than naive code). a compromise solution could be to combine the above function with a macro: #define PySequence_TupleOrList_GET_ITEM(seq, index)\ (PyList_Check(seq) ? PyList_GET_ITEM(seq, index) :\ PyTuple_GET_ITEM(seq, index) (anyone got a better name? ;-) standard usage: seq = PySequence_TupleOrList(seq_in); size = PyObject_Length(seq); for (i = 0; i < size; i++) { PyObject* obj = PySequence_TupleOrList_GET_ITEM(seq, i); ... } comments? From mal at lemburg.com Sat Jun 17 16:18:26 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat, 17 Jun 2000 16:18:26 +0200 Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface? References: <006a01bfd837$ac689840$f2a6b5d4@hagrid> <00d701bfd859$fd435300$f2a6b5d4@hagrid> Message-ID: <394B88B2.EA116971@lemburg.com> Fredrik Lundh wrote: > > the eff-bot wrote: > > > the first part is trivial; just add something like this to > > Objects/abstract.c: > > > > PyObject* > > PySequence_TupleOrList(PyObject* seq) > > ... > > > > the second parts is harder -- and that's of course where the > > real performance boost comes from. as far as I'm aware, very > > few C compilers can "specialize" loops for you... > > in the same test setup, moving the PyList_Check inside the > loop gives a 25-30% slowdown (or to look at it from the other > side, 3 times instead of 4 times faster than naive code). > > a compromise solution could be to combine the above function > with a macro: > > #define PySequence_TupleOrList_GET_ITEM(seq, index)\ > (PyList_Check(seq) ? PyList_GET_ITEM(seq, index) :\ > PyTuple_GET_ITEM(seq, index) > > (anyone got a better name? ;-) > > standard usage: > > seq = PySequence_TupleOrList(seq_in); > > size = PyObject_Length(seq); > > for (i = 0; i < size; i++) { > PyObject* obj = PySequence_TupleOrList_GET_ITEM(seq, i); > ... > } > > comments? The above looks a lot like an iterator... how about providing a standard PySequence_Iterate(obj, callback) with the callback being called for every element of the sequence ?! The iterator could then be optimized for lists and tuples. Not as fast as inlining, but a more generic solution... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From effbot at telia.com Sat Jun 17 16:42:52 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 17 Jun 2000 16:42:52 +0200 Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface? References: <006a01bfd837$ac689840$f2a6b5d4@hagrid> <00d701bfd859$fd435300$f2a6b5d4@hagrid> <394B88B2.EA116971@lemburg.com> Message-ID: <010401bfd86a$5282cca0$f2a6b5d4@hagrid> mal wrote: > The above looks a lot like an iterator... how about > providing a standard PySequence_Iterate(obj, callback) > with the callback being called for every element of the > sequence ?! PySequence_Enumerate, perhaps? > The iterator could then be optimized for lists and tuples. > Not as fast as inlining, but a more generic solution... more generic than useful, imo: - it's slower. - it's awkward to use: you need to put the state in a structure, invert your program logic, etc. - it doesn't scale: what if you want to loop over two structures? what if you want to loop over two objects, using two different indices? From mal at lemburg.com Sat Jun 17 16:44:47 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat, 17 Jun 2000 16:44:47 +0200 Subject: [Python-Dev] Q: why doesn't list.extend use the sequence interface? References: <006a01bfd837$ac689840$f2a6b5d4@hagrid> <00d701bfd859$fd435300$f2a6b5d4@hagrid> <394B88B2.EA116971@lemburg.com> <010401bfd86a$5282cca0$f2a6b5d4@hagrid> Message-ID: <394B8EDF.57630FE9@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > The above looks a lot like an iterator... how about > > providing a standard PySequence_Iterate(obj, callback) > > with the callback being called for every element of the > > sequence ?! > > PySequence_Enumerate, perhaps? > > > The iterator could then be optimized for lists and tuples. > > Not as fast as inlining, but a more generic solution... > > more generic than useful, imo: > > - it's slower. > > - it's awkward to use: you need to put the state in a > structure, invert your program logic, etc. > > - it doesn't scale: what if you want to loop over two > structures? what if you want to loop over two objects, > using two different indices? Or perhaps, use a different iteration technique: the one used by PyDict_Next(). It doesn't need a callback, but instead plays with pointers you pass to it via output variables. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From effbot at telia.com Sat Jun 17 17:44:58 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sat, 17 Jun 2000 17:44:58 +0200 Subject: [Python-Dev] proposal: core support for "fast" sequence iteration Message-ID: <011901bfd873$00632740$f2a6b5d4@hagrid> mark wrote: > Its a fair bit of code to duplicate everywhere you want the speed increase. > How can we add a similar scheme to the core, so the changes people need to > make are trivial (to the point where the change is zero!)? okay, here's my current proposal: PyObject* PySequence_Fast(PyObject *o) Return value: New reference. Returns the o as a tuple or a list on success, and NULL on failure. If o doesn't have the right type, it is converted to a tuple using PySequence_Tuple. This is equivalent to the following Python code: if type(o) in (ListType, TupleType): return o return tuple(o) This function is intended to be used together with PySequence_Fast_GET_ITEM, for functions that need to loop over a read-only sequence as fast as they possibly can, while still supporting any object that implements the sequence protocol. PyObject* PySequence_Fast_GET_ITEM(PyObject *seq, int i) Return value: Borrowed reference. Returns the object at position i, from the sequence seq (which must be a list or a tuple). This is a macro, and has no error checking. If you need error checking, use PySequence_GetItem. for the rationale, see my earlier posts in the "list.extend" thread. unless somebody comes up with a more efficient solution, I'll wrap this up together with the list.extend patch (first thing tomorrow). From gstein at lyra.org Sat Jun 17 22:52:31 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 17 Jun 2000 13:52:31 -0700 Subject: [Python-Dev] proposal: core support for "fast" sequence iteration In-Reply-To: <011901bfd873$00632740$f2a6b5d4@hagrid>; from effbot@telia.com on Sat, Jun 17, 2000 at 05:44:58PM +0200 References: <011901bfd873$00632740$f2a6b5d4@hagrid> Message-ID: <20000617135231.E29590@lyra.org> +1 coolness. On Sat, Jun 17, 2000 at 05:44:58PM +0200, Fredrik Lundh wrote: > mark wrote: > > > Its a fair bit of code to duplicate everywhere you want the speed increase. > > How can we add a similar scheme to the core, so the changes people need to > > make are trivial (to the point where the change is zero!)? > > okay, here's my current proposal: > > PyObject* PySequence_Fast(PyObject *o) > > Return value: New reference. > > Returns the o as a tuple or a list on success, and > NULL on failure. If o doesn't have the right type, > it is converted to a tuple using PySequence_Tuple. > > This is equivalent to the following Python code: > > if type(o) in (ListType, TupleType): > return o > return tuple(o) > > This function is intended to be used together with > PySequence_Fast_GET_ITEM, for functions that need > to loop over a read-only sequence as fast as they > possibly can, while still supporting any object that > implements the sequence protocol. > > PyObject* PySequence_Fast_GET_ITEM(PyObject *seq, int i) > > Return value: Borrowed reference. > > Returns the object at position i, from the sequence > seq (which must be a list or a tuple). This is a > macro, and has no error checking. > > If you need error checking, use PySequence_GetItem. > > for the rationale, see my earlier posts in the "list.extend" thread. > > unless somebody comes up with a more efficient solution, I'll wrap > this up together with the list.extend patch (first thing tomorrow). > > > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Sun Jun 18 00:37:26 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 17 Jun 2000 15:37:26 -0700 Subject: [Python-Dev] Re: [Python-bugs-list] PRIVATE: interned->ma_table never free'd (PR#361) In-Reply-To: <394B3C80.248B4CB1@lemburg.com>; from mal@lemburg.com on Sat, Jun 17, 2000 at 10:53:20AM +0200 References: <20000617000834.C29B41CF4A@dinsdale.python.org> <394B3C80.248B4CB1@lemburg.com> Message-ID: <20000617153726.H29590@lyra.org> On Sat, Jun 17, 2000 at 10:53:20AM +0200, M.-A. Lemburg wrote: >... > I would suggest adding code to dealloc the interned dict > iff it is empty after the sweeping action in PyString_Fini(). > I have a feeling that this is not the case though, since interned > strings are used quite a lot in the core interpreter (e.g. in > classobject.c) and these are usually not recovered. > > Perhaps we ought to add some code which takes care of cleaning > up all remaining garbage left over after the call to > call_ll_exitfuncs() in Py_Finalize(), e.g. force free'ing > of all interned strings and cached ints/floats and associated > free lists or dicts. > > We'd need new APIs in string|float|intobject.c to implement this. > > Thoughts ? Patches ? I would definitely like to see this, and suggested it to Guido about four years ago :-) During my threading work, I looked at all the globals, which includes the pools and the one-off allocations in classobject.c and friends. I figured it would be a Good Thing(tm) to write a general object pool API which could be used by tuples, floats, frames, etc. Having the single implementation of a pool would mean that we could add thread locks in a single place. Similarly, for cleanup reasons, I also suggested a general API for allocating the "constants" and torching them at shutdown. As we all know, though... suggestions don't mean crap. Code counts. :-) That said, I'll look into some of this with the free-threading work. That is all post-1.6, though. It would be great if somebody could do it before then. Cheers, -g -- Greg Stein, http://www.lyra.org/ From Vladimir.Marangozov at inrialpes.fr Sun Jun 18 01:01:30 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Sun, 18 Jun 2000 01:01:30 +0200 (CEST) Subject: [Python-Dev] Re: [Python-bugs-list] PRIVATE: interned->ma_table never free'd (PR#361) In-Reply-To: <20000617153726.H29590@lyra.org> from "Greg Stein" at Jun 17, 2000 03:37:26 PM Message-ID: <200006172301.BAA01642@python.inrialpes.fr> Greg Stein wrote: > > On Sat, Jun 17, 2000 at 10:53:20AM +0200, M.-A. Lemburg wrote: > >... > > Perhaps we ought to add some code which takes care of cleaning > > up all remaining garbage left over after the call to > > call_ll_exitfuncs() in Py_Finalize(), e.g. force free'ing > > of all interned strings and cached ints/floats and associated > > free lists or dicts. > > > > We'd need new APIs in string|float|intobject.c to implement this. > > > > Thoughts ? Patches ? > > I would definitely like to see this, and suggested it to Guido about four > years ago :-) > > During my threading work, I looked at all the globals, which includes the > pools and the one-off allocations in classobject.c and friends. I figured it > would be a Good Thing(tm) to write a general object pool API which could be > used by tuples, floats, frames, etc. Having the single implementation of a > pool would mean that we could add thread locks in a single place. > > Similarly, for cleanup reasons, I also suggested a general API for > allocating the "constants" and torching them at shutdown. > > As we all know, though... suggestions don't mean crap. Code counts. :-) pymalloc (the debugging stuff put aside) is an efficient implementation of this pool concept. The interface just needs to be exported under an appropriate PyObject_ API, not as a general malloc replacement. Maybe it needs some more work regarding finalization, but the code is there. Per pool locking is there too. Maybe it needs to be adjusted wrt the pool granularity we want. The various core object allocators would use this API with PyObject_NEW inlined. > > That said, I'll look into some of this with the free-threading work. That is > all post-1.6, though. It would be great if somebody could do it before then. Voila. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From Vladimir.Marangozov at inrialpes.fr Sun Jun 18 02:50:51 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Sun, 18 Jun 2000 02:50:51 +0200 (CEST) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules mmapmodule.c,2.10,2.11 In-Reply-To: <200006172241.PAA02080@slayer.i.sourceforge.net> from "A.M. Kuchling" at Jun 17, 2000 03:41:24 PM Message-ID: <200006180050.CAA07547@python.inrialpes.fr> A.M. Kuchling wrote: > > Update of /cvsroot/python/python/dist/src/Modules > In directory slayer.i.sourceforge.net:/tmp/cvs-serv2060 > > Modified Files: > mmapmodule.c > Log Message: > Fix the size() method to return the size of the file on Unix, not the > size of the mapped area. This seems to be what the Windows version does. > This change requires keeping around the fd of the mapped file. On AIX, the test_mmap fails with errno=EINVAL on the m.flush() method. It works okay without the MS_INVALIDATE flag though, so I'd suggest removing it from msync in the flush and dealloc methods. Also, it would probably be a good idea to allow optional flags for flush, as it's done in new_mmap_object, the default being only MS_SYNC. Given that this module is enabled by default, I think that it needs some more stress-testing in test_mmap.py. I'll try to add a couple of tests shortly. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From trentm at activestate.com Sun Jun 18 05:20:09 2000 From: trentm at activestate.com (Trent Mick) Date: Sat, 17 Jun 2000 20:20:09 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules mmapmodule.c,2.10,2.11 In-Reply-To: <200006180050.CAA07547@python.inrialpes.fr> References: <200006172241.PAA02080@slayer.i.sourceforge.net> <200006180050.CAA07547@python.inrialpes.fr> Message-ID: <20000617202009.A20019@activestate.com> On Sun, Jun 18, 2000 at 02:50:51AM +0200, Vladimir Marangozov wrote: > > A.M. Kuchling wrote: > > > > Update of /cvsroot/python/python/dist/src/Modules > > In directory slayer.i.sourceforge.net:/tmp/cvs-serv2060 > > > > Modified Files: > > mmapmodule.c > > Log Message: > > Fix the size() method to return the size of the file on Unix, not the > > size of the mapped area. This seems to be what the Windows version does. > > This change requires keeping around the fd of the mapped file. > > On AIX, the test_mmap fails with errno=EINVAL on the m.flush() method. > It works okay without the MS_INVALIDATE flag though, so I'd suggest > removing it from msync in the flush and dealloc methods. > > Also, it would probably be a good idea to allow optional flags for > flush, as it's done in new_mmap_object, the default being only MS_SYNC. > > Given that this module is enabled by default, I think that it needs some > more stress-testing in test_mmap.py. I'll try to add a couple of tests > shortly. > Just to add to the mmap fray. The seek() method is broken for any 'whence' value (seek from start, current, orend) other than the default. Ihave a patch that fixes that as well as gets mmap'd files working on Linux64 and Win64. The test_mmap was also extended. The patch is up on SourceForge for your perusal. :) https://sourceforge.net/patch/?func=detailpatch&patch_id=100515&group_id=5470 Cheers, Trent -- Trent Mick trentm at activestate.com From mhammond at skippinet.com.au Sun Jun 18 05:35:00 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sun, 18 Jun 2000 13:35:00 +1000 Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/Doc/lib libmmap.tex,NONE,1.1 In-Reply-To: <200006172239.PAA01994@slayer.i.sourceforge.net> Message-ID: > Documentation for the mmap module: proofreaders welcomed OK :-) > the file handle \var{fileno}, and returns a mmap object. If you have > a Python file object, its > \method{fileno()} method returns the file's handle, which is > just an integer. This could be a little clearer - on first reading, I thought you were talking about the return value. Maybe something like: "if you wish to pass an existing Python file object for this parameter, use its \method{fileno()} method to obtain the fileno." > \var{tagname}, if specified, is a string giving a tag name for > the mapping. XXX what is the purpose of the tag name? Something like: Windows allows you to have many different mappings against the same file. If you specify the name of an existing tag, that tag is opened, otherwise a new tag of this name is created. If this parameter is None, the mapping is created without a name. Avoiding the use of the tag parameter will assist in keeping your code portable between Unix and Windows. > \begin{funcdesc}{mmap}{file, size \optional{, flags, prot}} > (Unix version) Maps \var{length} bytes from the file specified by the > file handle \var{fileno}, and returns a mmap object. If you have a > Python file object, its \method{fileno()} method returns the file's > handle, which is just an integer. I believe you mean the signature to say "fileno" instead of "file" - this makes it consistent with the Windows signature, and reinforces that this param is indeed identical. As a meta-comment, the structure of this implies that the param signatures are more different than they are - eg, it should be possible to write portable mmap code in most cases, without concern for the platform. the platform only becomes relevant when you use the optional params for each platform? > \begin{methoddesc}{read}{\var{num}} > Return a string containing up to \var{num} bytes taken from the "taken from" -> "starting from" ?? > \begin{methoddesc}{write_byte}{\var{byte}} > Write \var{byte} into memory at the current position of > the file pointer; the file position is advanced by 1. > \end{methoddesc} The type of "byte" should be explained - its never clear to me if a "byte" should be an int or a string of size 1. In this case, it is the latter. Looks good! Mark. From mhammond at skippinet.com.au Sun Jun 18 05:35:33 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sun, 18 Jun 2000 13:35:33 +1000 Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/Doc/lib libmmap.tex,NONE,1.1 In-Reply-To: <200006172239.PAA01994@slayer.i.sourceforge.net> Message-ID: Sorry about that - I meant to send it direct to Andrew... Mark. From Vladimir.Marangozov at inrialpes.fr Sun Jun 18 06:24:05 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Sun, 18 Jun 2000 06:24:05 +0200 (CEST) Subject: [Python-Dev] Towards selective compilation to native code? Message-ID: <200006180424.GAA14040@python.inrialpes.fr> There was a cool seminar the other day here, focusing on embedded & real-time Java, so I'll throw here some impressions while they're fresh. One of the presenters talked extensively about compilation strategies and techniques for Java bytecode to native code, and while I know that Java is not Python, it would be interesting to, at least, try to project some of the ideas to Python in the long run, where applicable. Needless to say, the guy & his environment (ex-OSF, now Silicomp) are experts in compiler technology and I'm not in a position to comment on everything, but you may find the second half of the slides enlightening: http://cgi-serv.inrialpes.fr/InTech/2000-06-15/ejava-silicomp.ppt So, the interesting part of the talk was about a "new" compiler architecture, built upon the concept of "Flash compiling" (quite unappropriate name), which produces a mixture of the following: 1. Bytecode 2. Native code 3. Native code is compiled selectively on demand and/or ahead of time (!= JIT) for "expensive" methods. 4. Expensive methods are, on one hand, detected by dynamic profiling of the bytecode, and OTOH, determined ahead of time according to the following 2 simple creteria: - methods containing loops - methods calling native code from bytecode (to avoid bytecode to native and vice versa arg conversion paths which are expensive -- btw Python has the same perf. bottleneck) 5. Everything relies on dyn loading & late binding of native code (front-end loads dynamically the back-end, native code is stored in the code stream, but linked incrementally & dynamically during execution) 6. The whole thing is designed to avoid code explosion and to preserve the advantage of bytecode == small code size, and the presented preliminary results are quite optimistic -- the figures differ depending on the code size / speed tradeoff. Of course, this is Java and there's static typing in there, but it would be interesting to see whether Python can steal something from these ideas. For instance, I'm trying to foresee what kind of static typing (i.e. how much static info) would be appropriate in Python from this point of view but I fail to obtain any realistic image :). I see most parts of the dyn loading / late binding aspect though -- they are typical for Python. Hm. Sounds like I'll be harrassing Tim to make him finally write something valuable for Python ;-) -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From akuchlin at cnri.reston.va.us Sun Jun 18 06:22:24 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Sun, 18 Jun 2000 00:22:24 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules mmapmodule.c,2.10,2.11 In-Reply-To: <200006180050.CAA07547@python.inrialpes.fr>; from Vladimir.Marangozov@inrialpes.fr on Sun, Jun 18, 2000 at 02:50:51AM +0200 References: <200006172241.PAA02080@slayer.i.sourceforge.net> <200006180050.CAA07547@python.inrialpes.fr> Message-ID: <20000618002224.A12729@newcnri.cnri.reston.va.us> On Sun, Jun 18, 2000 at 02:50:51AM +0200, Vladimir Marangozov wrote: >On AIX, the test_mmap fails with errno=EINVAL on the m.flush() method. >It works okay without the MS_INVALIDATE flag though, so I'd suggest >removing it from msync in the flush and dealloc methods. Ooh, you're right. The Linux msync man page says "MS_ASYNC specifies that an update be scheduled, but the call returns immediately. MS_SYNC asks for an update and waits for it to complete. MS_INVALIDATE asks to invalidate other mappings of the same file (so that they can be updated with the fresh values just written)." So MS_INVALIDATE seems far too drastic. >Also, it would probably be a good idea to allow optional flags for >flush, as it's done in new_mmap_object, the default being only MS_SYNC. The problem is: does Windows provide equivalent functionality? (Is there documentation available online for CreateFileMapping that I could look at?) >Given that this module is enabled by default, I think that it needs some >more stress-testing in test_mmap.py. I'll try to add a couple of tests >shortly. Good idea. I'll try to look at Trent Mick's patch and apply it ASAP if it checks out. --amk From akuchlin at cnri.reston.va.us Sun Jun 18 07:03:16 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Sun, 18 Jun 2000 01:03:16 -0400 Subject: [Python-Dev] Re: Almost insignificant patch for mmapmodule In-Reply-To: ; from lorenzo@sancho.ccd.uniroma2.it on Sat, Jun 17, 2000 at 04:29:14PM +0200 References: Message-ID: <20000618010316.D12729@newcnri.cnri.reston.va.us> On Sat, Jun 17, 2000 at 04:29:14PM +0200, Lorenzo M. Catucci wrote: >therefore, here is the change: if we are compiling for linux, define >_GNU_SOURCE before including mman.h, and all is done. It seems the Hmm... IMHO this points out a bug; if MREMAP_MAYMOVE is not present, that doesn't imply that mremap() doesn't work at all; instead, a resize may fail if the mapping would have to be moved to a different virtual address. Quoting from the Linux man page: MREMAP_MAYMOVE indicates if the operation should fail, or change the virtual address if the resize cannot be done at the current virtual address. I think the correct fix is to simply specify MREMAP_MAYMOVE if it's defined, but still support attempting to resize. Possibly the configure script should also check for mremap()'s existence. --amk From lorenzo at sancho.ccd.uniroma2.it Sun Jun 18 09:39:55 2000 From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci) Date: Sun, 18 Jun 2000 09:39:55 +0200 (CEST) Subject: [Python-Dev] Re: Almost insignificant patch for mmapmodule In-Reply-To: <20000618010316.D12729@newcnri.cnri.reston.va.us> Message-ID: On Sun, 18 Jun 2000, Andrew Kuchling wrote: AK> On Sat, Jun 17, 2000 at 04:29:14PM +0200, Lorenzo M. Catucci wrote: AK> >therefore, here is the change: if we are compiling for linux, define AK> >_GNU_SOURCE before including mman.h, and all is done. It seems the AK> AK> Hmm... IMHO this points out a bug; if MREMAP_MAYMOVE is not present, AK> that doesn't imply that mremap() doesn't work at all; instead, a AK> resize may fail if the mapping would have to be moved to a different AK> virtual address. Quoting from the Linux man page: AK> AK> MREMAP_MAYMOVE AK> indicates if the operation should fail, or change AK> the virtual address if the resize cannot be done at AK> the current virtual address. AK> AK> I think the correct fix is to simply specify MREMAP_MAYMOVE if it's AK> defined, but still support attempting to resize. Possibly the AK> configure script should also check for mremap()'s existence. AK> I think I've been too dense... Here I see two problems: on one hand, from what I have understood of python's object, it's much better if the c pointers are movable in VM on the remap, and the MAYMOVE flag is only defined in mman.h if _GNU_SOURCE is; on the other hand, we only know about linux mremap semantics: for what I see in linix mremap(2) """ CONFORMING TO This call is Linux-specific, and should not be used in programs intended to be portable. 4.2BSD had a (never actually implemented) mremap(2) call with completely dif? ferent semantics. """ Therefore, I think that really checking for __linux__ and using the MAYMOVE flag, which is thefined there, is going towards the right way. If someone else comes out with another kernel supporting a mremap syscall[1], I think we'll be able to add proper support afterwards. As for the configure script, on linux we have both mremap and MAYMOVE; if you go to the Extended UNIX ABI, M* Page, you'll find: GNU Unix98 Unix95 POSIX ISO C SVID 3 4.3BSD XPG mremap X It seems only the systems supported by GNU libc-2 (only linux systems, then) support mremap... Have a nice time. lmc * Just tried searching for mremap on http://www.FreeBSD.org/cgi/man.cgi?query=mmap and looked around the various BSD derivatives whose man pages are available there. +-------------------------+----------------------------------------------+ | Lorenzo M. Catucci | Centro di Calcolo e Documentazione | | catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" | | | Via O. Raimondo 18 ** I-00173 ROMA ** ITALY | | Tel. +39 06 7259 2255 | Fax. +39 06 7259 2125 | +-------------------------+----------------------------------------------+ From petrilli at amber.org Sun Jun 18 20:50:22 2000 From: petrilli at amber.org (Christopher Petrilli) Date: Sun, 18 Jun 2000 14:50:22 -0400 Subject: [Python-Dev] Towards selective compilation to native code? In-Reply-To: <200006180424.GAA14040@python.inrialpes.fr>; from Vladimir.Marangozov@inrialpes.fr on Sun, Jun 18, 2000 at 06:24:05AM +0200 References: <200006180424.GAA14040@python.inrialpes.fr> Message-ID: <20000618145022.A13031@trump.amber.org> Vladimir Marangozov [Vladimir.Marangozov at inrialpes.fr] wrote: > > Of course, this is Java and there's static typing in there, but it > would be interesting to see whether Python can steal something from these > ideas. For instance, I'm trying to foresee what kind of static typing > (i.e. how much static info) would be appropriate in Python from this > point of view but I fail to obtain any realistic image :). > I see most parts of the dyn loading / late binding aspect though -- > they are typical for Python. One might take a look at Smalltalk/X which compiles into C, and has a pretty (ney very) high performance reputation. There are some other Smalltalk implementations taht do this as well. This would be closer I think to what Python would use than Java will be. Chris -- | Christopher Petrilli | petrilli at amber.org From effbot at telia.com Sun Jun 18 21:06:45 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 18 Jun 2000 21:06:45 +0200 Subject: [Python-Dev] talking about performance... Message-ID: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid> consider this little program: import time, sre k = u"foo" p = sre.compile(k) s = "*"*500 + k + "*"*500 def f1(): p.search(s) def f2(): s.find(k) def bench(f): t0 = time.clock() for i in range(100000): f() print f, time.clock() - t0 bench(f1) bench(f2) which prints: 2.94704487169 10.5247875425 (Windows 95, 233 MHz) if I change the k variable to an 8-bit string, it prints: 2.47613520173 2.5178698939 (for some reason, sre is still slighty faster...) so in other words, something in unicode land isn't as efficient as it should... From akuchlin at cnri.reston.va.us Sun Jun 18 21:20:20 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Sun, 18 Jun 2000 15:20:20 -0400 Subject: [Python-Dev] talking about performance... In-Reply-To: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid>; from effbot@telia.com on Sun, Jun 18, 2000 at 09:06:45PM +0200 References: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid> Message-ID: <20000618152020.B14713@newcnri.cnri.reston.va.us> On Sun, Jun 18, 2000 at 09:06:45PM +0200, Fredrik Lundh wrote: >so in other words, something in unicode land isn't >as efficient as it should... The relevant bit of findstring() in unicodeobject.c: if (direction < 0) { for (; end >= start; end--) if (Py_UNICODE_MATCH(self, end, substring)) return end; } else { for (; start <= end; start++) if (Py_UNICODE_MATCH(self, start, substring)) return start; } And... #define Py_UNICODE_MATCH(string, offset, substring)\ (!memcmp((string)->str + (offset), (substring)->str,\ (substring)->length*sizeof(Py_UNICODE))) Proposed patch: Index: unicodeobject.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v retrieving revision 2.26 diff -u -r2.26 unicodeobject.c --- unicodeobject.c 2000/06/14 09:18:32 2.26 +++ unicodeobject.c 2000/06/18 19:18:01 @@ -2168,11 +2168,13 @@ if (direction < 0) { for (; end >= start; end--) - if (Py_UNICODE_MATCH(self, end, substring)) + if ( *(self->str + end) == *(substring->str) && + Py_UNICODE_MATCH(self, end, substring)) return end; } else { for (; start <= end; start++) - if (Py_UNICODE_MATCH(self, start, substring)) + if (*(self->str + start) == *(substring->str) && + Py_UNICODE_MATCH(self, start, substring)) return start; } --amk From amk1 at erols.com Sun Jun 18 21:32:37 2000 From: amk1 at erols.com (A.M. Kuchling) Date: Sun, 18 Jun 2000 15:32:37 -0400 Subject: [Python-Dev] Turning on sre? Message-ID: <200006181932.PAA03968@207-172-113-141.s141.tnt5.ann.va.dialup.rcn.com> Before 1.6a3, should the sre module be turned on, replacing re? That way it'll start getting tested; better we find problems sooner rather than later... --amk From guido at python.org Sun Jun 18 22:47:22 2000 From: guido at python.org (Guido van Rossum) Date: Sun, 18 Jun 2000 15:47:22 -0500 Subject: [Python-Dev] Turning on sre? In-Reply-To: Your message of "Sun, 18 Jun 2000 15:32:37 -0400." <200006181932.PAA03968@207-172-113-141.s141.tnt5.ann.va.dialup.rcn.com> References: <200006181932.PAA03968@207-172-113-141.s141.tnt5.ann.va.dialup.rcn.com> Message-ID: <200006182047.PAA03008@cj20424-a.reston1.va.home.com> > Before 1.6a3, should the sre module be turned on, replacing re? That > way it'll start getting tested; better we find problems sooner rather > than later... That would be nice. If I replace re.py with "from sre import *" and run test_re.py, I grt in trouble in the sub() test: $ ./python ../Lib/test/test_re.py Running tests on re.search and re.match Running tests on re.sub Traceback (most recent call last): File "../Lib/test/test_re.py", line 41, in ? assert re.sub(r'\d+', bump_num, '08.2 -2 23x99y') == '9.3 -3 24x100y' File "./../Lib/sre.py", line 35, in sub return _compile(pattern).sub(repl, string, count) File "./../Lib/sre.py", line 84, in _sub return _subn(pattern, template, string, count)[0] File "./../Lib/sre.py", line 114, in _subn return string[:0].join(s), n TypeError: sequence item 0 not a string $ It appears that the value of s is a list containing alternating zeros and strings: [0, '.', 0, ' -', 0, ' ', 0, 'x', 0, 'y']. No time to look into this further, but it could be a bug in sre._subn(). --Guido van Rossum (home page: http://www.python.org/~guido/) From akuchlin at cnri.reston.va.us Sun Jun 18 22:28:59 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Sun, 18 Jun 2000 16:28:59 -0400 Subject: [Python-Dev] Turning on sre? In-Reply-To: <200006182047.PAA03008@cj20424-a.reston1.va.home.com>; from guido@python.org on Sun, Jun 18, 2000 at 03:47:22PM -0500 References: <200006181932.PAA03968@207-172-113-141.s141.tnt5.ann.va.dialup.rcn.com> <200006182047.PAA03008@cj20424-a.reston1.va.home.com> Message-ID: <20000618162859.A15018@newcnri.cnri.reston.va.us> On Sun, Jun 18, 2000 at 03:47:22PM -0500, Guido van Rossum wrote: >No time to look into this further, but it could be a bug in sre._subn(). It's a typo; fixed. However, test_re then runs into the fact that _expand(), which should expand escapes in the replacement string, isn't implemented yet. --amk From effbot at telia.com Sun Jun 18 23:42:00 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 18 Jun 2000 23:42:00 +0200 Subject: [Python-Dev] talking about performance... References: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid> <20000618152020.B14713@newcnri.cnri.reston.va.us> Message-ID: <008301bfd96e$0bd98d20$f2a6b5d4@hagrid> amk wrote: > On Sun, Jun 18, 2000 at 09:06:45PM +0200, Fredrik Lundh wrote: > >so in other words, something in unicode land isn't > >as efficient as it should... > > The relevant bit of findstring() in unicodeobject.c: > > if (direction < 0) { > for (; end >= start; end--) > if (Py_UNICODE_MATCH(self, end, substring)) > return end; > } else { > for (; start <= end; start++) > if (Py_UNICODE_MATCH(self, start, substring)) > return start; > } > > And... > > #define Py_UNICODE_MATCH(string, offset, substring)\ > (!memcmp((string)->str + (offset), (substring)->str,\ > (substring)->length*sizeof(Py_UNICODE))) heh. it's my own code, of course... > Proposed patch: > > Index: unicodeobject.c MATCH is used in a couple of places; it's probably a better idea to change the macro (in Include/unicodeobject.h). MAL? From effbot at telia.com Sun Jun 18 23:43:51 2000 From: effbot at telia.com (Fredrik Lundh) Date: Sun, 18 Jun 2000 23:43:51 +0200 Subject: [Python-Dev] Turning on sre? References: <200006181932.PAA03968@207-172-113-141.s141.tnt5.ann.va.dialup.rcn.com> Message-ID: <009501bfd96e$4d11b7e0$f2a6b5d4@hagrid> amk wrote: > Before 1.6a3, should the sre module be turned on, replacing re? That > way it'll start getting tested; better we find problems sooner rather > than later... in addition to the typo you noticed, there's a backtracking (I think) problem that affects xmllib.py and tokenize.py... I'm working on it. From mal at lemburg.com Sun Jun 18 23:48:32 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun, 18 Jun 2000 23:48:32 +0200 Subject: [Python-Dev] talking about performance... References: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid> <20000618152020.B14713@newcnri.cnri.reston.va.us> <008301bfd96e$0bd98d20$f2a6b5d4@hagrid> Message-ID: <394D43B0.8CC7070@lemburg.com> Fredrik Lundh wrote: > > amk wrote: > > > On Sun, Jun 18, 2000 at 09:06:45PM +0200, Fredrik Lundh wrote: > > >so in other words, something in unicode land isn't > > >as efficient as it should... > > > > The relevant bit of findstring() in unicodeobject.c: > > > > if (direction < 0) { > > for (; end >= start; end--) > > if (Py_UNICODE_MATCH(self, end, substring)) > > return end; > > } else { > > for (; start <= end; start++) > > if (Py_UNICODE_MATCH(self, start, substring)) > > return start; > > } > > > > And... > > > > #define Py_UNICODE_MATCH(string, offset, substring)\ > > (!memcmp((string)->str + (offset), (substring)->str,\ > > (substring)->length*sizeof(Py_UNICODE))) > > heh. it's my own code, of course... > > > Proposed patch: > > > > Index: unicodeobject.c > > MATCH is used in a couple of places; it's probably a better idea > to change the macro (in Include/unicodeobject.h). MAL? Right. I'll add Andrew's proposed patch to the macro def. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From effbot at telia.com Mon Jun 19 00:33:10 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 19 Jun 2000 00:33:10 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Include unicodeobject.h,2.9,2.10 References: <200006182222.PAA19408@slayer.i.sourceforge.net> Message-ID: <00c601bfd975$358d0aa0$f2a6b5d4@hagrid> mal wrote: > > #define Py_UNICODE_MATCH(string, offset, substring)\ > ! ((*((string)->str + (offset)) == *((substring)->str)) &&\ > ! !memcmp((string)->str + (offset), (substring)->str,\ > (substring)->length*sizeof(Py_UNICODE))) > I completely forgot that this has different semantics if the substring happens to be empty. (substrings are null terminated, but "\0" isn't the same thing as ""...) don't have time to screen unicodeobject.c right now, but maybe someone else can do it? if not, maybe amk's patch was a better idea after all... From mwh21 at cam.ac.uk Mon Jun 19 01:15:25 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 19 Jun 2000 00:15:25 +0100 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules _tkinter.c,1.99,1.100 In-Reply-To: "A.M. Kuchling"'s message of "Sun, 18 Jun 2000 11:45:52 -0700" References: <200006181845.LAA10182@slayer.i.sourceforge.net> Message-ID: "A.M. Kuchling" writes: > Update of /cvsroot/python/python/dist/src/Modules > In directory slayer.i.sourceforge.net:/tmp/cvs-serv10064/Modules > > Modified Files: > _tkinter.c > Log Message: > Patch from /F: > this patch adds a fast _flatten function to the _tkinter > module, and imports it from Tkinter.py (if available). > > this speeds up canvas operations like create_line and > create_polygon. for example, a create_line with 5000 > vertices runs about 50 times faster with this patch in > place. Unfortunately this introduces another Way To Make Python Core: [mwh21 at atrus build]$ ./python Python 1.6a2 (#4, Jun 18 2000, 23:57:36) [GCC 2.95.1 19990816/Linux (release)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> import Tkinter >>> l = [] >>> l.append(l) >>> Tkinter._flatten(l) Segmentation fault (core dumped) Here's a simple solution: Index: _tkinter.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/_tkinter.c,v retrieving revision 1.100 diff -u -r1.100 _tkinter.c --- _tkinter.c 2000/06/18 18:45:50 1.100 +++ _tkinter.c 2000/06/18 23:13:22 @@ -2001,13 +2001,16 @@ } static int -_flatten1(FlattenContext* context, PyObject* item) +_flatten1(FlattenContext* context, PyObject* item, int depth) { /* add tuple or list to argument tuple (recursively) */ int i, size; - if (PyList_Check(item)) { + if (depth > 1000) { + PyErr_SetString(PyExc_ValueError,"nesting too deep in _flatten"); + return 0; + } else if (PyList_Check(item)) { size = PyList_GET_SIZE(item); /* preallocate (assume no nesting) */ if (context->size + size > context->maxsize && !_bump(context, size)) @@ -2016,7 +2019,7 @@ for (i = 0; i < size; i++) { PyObject *o = PyList_GET_ITEM(item, i); if (PyList_Check(o) || PyTuple_Check(o)) { - if (!_flatten1(context, o)) + if (!_flatten1(context, o, depth + 1)) return 0; } else if (o != Py_None) { if (context->size + 1 > context->maxsize && !_bump(context, 1)) @@ -2033,7 +2036,7 @@ for (i = 0; i < size; i++) { PyObject *o = PyTuple_GET_ITEM(item, i); if (PyList_Check(o) || PyTuple_Check(o)) { - if (!_flatten1(context, o)) + if (!_flatten1(context, o, depth + 1)) return 0; } else if (o != Py_None) { if (context->size + 1 > context->maxsize && !_bump(context, 1)) @@ -2068,7 +2071,7 @@ context.size = 0; - if (!_flatten1(&context, item)) + if (!_flatten1(&context, item,0)) return NULL; if (_PyTuple_Resize(&context.tuple, context.size, 0)) "seems to work"; I've not tested it for performance, but I can't believe this is too hard a hit. Cheers, M. From mal at lemburg.com Mon Jun 19 01:20:27 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 19 Jun 2000 01:20:27 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Include unicodeobject.h,2.9,2.10 References: <200006182222.PAA19408@slayer.i.sourceforge.net> <00c601bfd975$358d0aa0$f2a6b5d4@hagrid> Message-ID: <394D593B.DD4804E6@lemburg.com> Fredrik Lundh wrote: > > mal wrote: > > > > #define Py_UNICODE_MATCH(string, offset, substring)\ > > ! ((*((string)->str + (offset)) == *((substring)->str)) &&\ > > ! !memcmp((string)->str + (offset), (substring)->str,\ > > (substring)->length*sizeof(Py_UNICODE))) > > > > I completely forgot that this has different semantics if the > substring happens to be empty. > > (substrings are null terminated, but "\0" isn't the same > thing as ""...) > > don't have time to screen unicodeobject.c right now, but > maybe someone else can do it? if not, maybe amk's patch > was a better idea after all... I've checked the places where this macro is used: all except the in .count() method showed the same behaviour as for 8-bit strings. The Unicode .count() method now also returns the same value for empty substrings as the 8-bit strings. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From effbot at telia.com Mon Jun 19 01:29:23 2000 From: effbot at telia.com (Fredrik Lundh) Date: Mon, 19 Jun 2000 01:29:23 +0200 Subject: [Python-Dev] CVS: python/dist/src/Modules _tkinter.c,1.99,1.100 References: <200006181845.LAA10182@slayer.i.sourceforge.net> Message-ID: <002701bfd97d$09d8b640$f2a6b5d4@hagrid> michael wrote: > > this patch adds a fast _flatten function to the _tkinter > > module, and imports it from Tkinter.py (if available). > > Unfortunately this introduces another Way To Make Python Core: well, there are lots of way to dump core through Tkinter/Tk, so I convinced myself that it wasn't really worth the effort to prevent it in _flatten... either way, the patch looks okay to me. From mwh21 at cam.ac.uk Mon Jun 19 01:41:22 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 19 Jun 2000 00:41:22 +0100 Subject: [Python-Dev] CVS: python/dist/src/Modules _tkinter.c,1.99,1.100 In-Reply-To: "Fredrik Lundh"'s message of "Mon, 19 Jun 2000 01:29:23 +0200" References: <200006181845.LAA10182@slayer.i.sourceforge.net> <002701bfd97d$09d8b640$f2a6b5d4@hagrid> Message-ID: "Fredrik Lundh" writes: > michael wrote: > > > this patch adds a fast _flatten function to the _tkinter > > > module, and imports it from Tkinter.py (if available). > > > > Unfortunately this introduces another Way To Make Python Core: > > well, there are lots of way to dump core through Tkinter/Tk, so I > convinced myself that it wasn't really worth the effort to prevent > it in _flatten... Are there? (I hardly know Tkinter). Oh well. I don't know of many "core" methods of doing it; the only one I can think of is marshalling a recursive list, and as there seems to be a loud party going on next door to me, I may write a patch for that this evening... Cheers, M. From mhammond at skippinet.com.au Mon Jun 19 02:05:00 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Mon, 19 Jun 2000 10:05:00 +1000 Subject: [Python-Dev] Welcome back In-Reply-To: <200006182047.PAA03008@cj20424-a.reston1.va.home.com> Message-ID: Welcome back, welcome back, welcome baaaaack - Welcome back, welcome back, welcome baaaaack Good to see you return. Im sure you had a wonderful time! From all accounts, your wedding was beautiful, as Im sure your honeymoon was... Now-were-just-waiting-for-the-baby-announcements-ly, Mark. > -----Original Message----- > From: python-dev-admin at python.org [mailto:python-dev-admin at python.org]On > Behalf Of Guido van Rossum > Sent: Monday, 19 June 2000 6:47 AM > To: akuchlin at mems-exchange.org > Cc: python-dev at python.org > Subject: Re: [Python-Dev] Turning on sre? From tim_one at email.msn.com Mon Jun 19 04:05:16 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 18 Jun 2000 22:05:16 -0400 Subject: [Python-Dev] Welcome back In-Reply-To: Message-ID: [Mark Hammond] > ... > Good to see you return. Im sure you had a wonderful time! From > all accounts, your wedding was beautiful, as Im sure your > honeymoon was... > > Now-were-just-waiting-for-the-baby-announcements-ly, Guido & Kim just spent the last night of their honeymoon with Uncle Timmy (who is now living in a Virginia motel room), and I can assure you no babies were made by any pair of us tonight. Unless Guido is quicker than he looks. i'm-certainly-not-ly y'rs - tim From skip at mojam.com Sat Jun 17 05:45:14 2000 From: skip at mojam.com (Skip Montanaro) Date: Fri, 16 Jun 2000 22:45:14 -0500 (CDT) Subject: [Python-Dev] list comprehensions Message-ID: <14666.62538.988511.305499@beluga.mojam.com> Did list comprehensions ever make it into 1.6? I thought I submitted a 1.6-compatible update of Greg Ewing's mods awhile ago. Should I resubmit? To the patches list? -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On June 24th at 8AM, live your life for an hour as Ricky Byrdsong always lived his - run/walk in the Ricky Byrdsong Memorial 5K or just make a donation: https://www.SignmeupSports.com/Events/Index_Events.asp?EventID=1395 From guido at python.org Mon Jun 19 17:01:24 2000 From: guido at python.org (Guido van Rossum) Date: Mon, 19 Jun 2000 10:01:24 -0500 Subject: [Python-Dev] list comprehensions In-Reply-To: Your message of "Fri, 16 Jun 2000 22:45:14 EST." <14666.62538.988511.305499@beluga.mojam.com> References: <14666.62538.988511.305499@beluga.mojam.com> Message-ID: <200006191501.KAA02197@cj20424-a.reston1.va.home.com> > Did list comprehensions ever make it into 1.6? No (as far as I'm aware :-). > I thought I submitted a > 1.6-compatible update of Greg Ewing's mods awhile ago. Should I resubmit? > To the patches list? It's rather late in the release cycle -- I'm trying to get alpha 3 released, and i'm still 1400 messages behind on my email. But submitting a patch might be a good idea anyway so we won't forget about it (and maybe it's of such baffling simplicity that it'll charm its way past the guards :-). --Guido van Rossum (home page: http://www.python.org/~guido/) From ping at lfw.org Mon Jun 19 20:59:15 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Mon, 19 Jun 2000 13:59:15 -0500 (CDT) Subject: [Python-Dev] list comprehensions In-Reply-To: <200006191501.KAA02197@cj20424-a.reston1.va.home.com> Message-ID: On Mon, 19 Jun 2000, Guido van Rossum wrote: > > Did list comprehensions ever make it into 1.6? > > No (as far as I'm aware :-). [...] > But submitting a patch might be a good idea anyway so we won't forget > about it (and maybe it's of such baffling simplicity that it'll charm > its way past the guards :-). I just have to say i thought list comprehensions were really cool. -- ?!ng From skip at mojam.com Mon Jun 19 22:17:59 2000 From: skip at mojam.com (Skip Montanaro) Date: Mon, 19 Jun 2000 15:17:59 -0500 Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions... Message-ID: <200006192017.PAA00690@beluga.mojam.com> Python's sys module defines an exitfunc variable that is settable from Python scripts. At exit, that function will be called with no arguments. While this is a good start at supporting standard cleanup activities, it defines no protocol to be used by modules that wish to use sys.exitfunc, which leads to one of two extremes: 1, two modules wishing to define cleanup functions both clobber sys.exitfunc or 2, to avoid collisions they don't use the functionality provided. At an application level this is okay. Within a single application you can define an application-specific protocol to handle the situation. Unfortunately, this still leaves Python's core modules without a good way to register exit functions. I ran into this problem today. I would really like the rlcompleter module to read and write readline history files from Python. Reading a history file at module startup is no problem, but deciding where to write the history file is a problem. The logical place is at the time sys.exitfunc is executed. For my own applications I long ago wrote a very simple module (called exit.py, appended to this message) that defines two functions: * exit.register_exitfunc takes a function object and a set of optional arguments and appends them to a list. * exit._run_exitfuncs is bound to sys.exitfunc and executes the registered exit functions in the order they appear in the list. I propose exit.py as the starting point for a well-defined protocol for modules to register exit functions without collisions. -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On June 24th at 8AM, live your life for an hour as Ricky Byrdsong always lived his - run/walk in the Ricky Byrdsong Memorial 5K or just make a donation: https://www.SignmeupSports.com/Events/Index_Events.asp?EventID=1395 """ allow programmer to define multiple exit functions to be executed upon normal program termination. """ _exithandlers = [] def _run_exitfuncs(): while _exithandlers: func, targs, kargs = _exithandlers[0] apply(func, targs, kargs) _exithandlers.remove(_exithandlers[0]) def register_exitfunc(func, *targs, **kargs): """register a function to be executed upon normal program termination arguments are a function object, and zero or more arguments to pass to it. """ _exithandlers.append((func, targs, kargs)) import sys try: x = sys.exitfunc except AttributeError: sys.exitfunc = _run_exitfuncs del sys if __name__ == "__main__": def x1(): print "running x1" def x2(n): print "running x2(%s)" % `n` def x3(n, kwd=None): print "running x3(%s, kwd=%s)" % (`n`, `kwd`) register_exitfunc(x1) register_exitfunc(x2, 12) register_exitfunc(x3, 5, "bar") register_exitfunc(x3, "no kwd args") From DavidA at ActiveState.com Mon Jun 19 22:27:48 2000 From: DavidA at ActiveState.com (David Ascher) Date: Mon, 19 Jun 2000 13:27:48 -0700 Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions... In-Reply-To: <200006192017.PAA00690@beluga.mojam.com> Message-ID: +1 on the idea. I wonder if it makes sense to publish a mechanism to allow de-registering of callbacks, or if that's featuritis. Also, I'd change: > try: > x = sys.exitfunc > except AttributeError: > sys.exitfunc = _run_exitfuncs > del sys to: try: register_exitfuncs(sys.exitfunc) finally: sys.exitfunc = _run_exitfuncs Or some such. --david > -----Original Message----- > From: python-dev-admin at python.org [mailto:python-dev-admin at python.org]On > Behalf Of Skip Montanaro > Sent: Monday, June 19, 2000 1:18 PM > To: python-dev at python.org > Subject: [Python-Dev] Proposal: standard way of defining and executing > "atexit" functions... > Importance: Low > > > > Python's sys module defines an exitfunc variable that is settable from > Python scripts. At exit, that function will be called with no arguments. > While this is a good start at supporting standard cleanup activities, it > defines no protocol to be used by modules that wish to use sys.exitfunc, > which leads to one of two extremes: 1, two modules wishing to > define cleanup > functions both clobber sys.exitfunc or 2, to avoid collisions > they don't use > the functionality provided. > > At an application level this is okay. Within a single application you can > define an application-specific protocol to handle the situation. > Unfortunately, this still leaves Python's core modules without a > good way to > register exit functions. > > I ran into this problem today. I would really like the rlcompleter module > to read and write readline history files from Python. Reading a history > file at module startup is no problem, but deciding where to write the > history file is a problem. The logical place is at the time > sys.exitfunc is > executed. > > For my own applications I long ago wrote a very simple module (called > exit.py, appended to this message) that defines two functions: > > * exit.register_exitfunc takes a function object and a set of optional > arguments and appends them to a list. > > * exit._run_exitfuncs is bound to sys.exitfunc and executes the > registered exit functions in the order they appear in the list. > > I propose exit.py as the starting point for a well-defined protocol for > modules to register exit functions without collisions. > > -- > Skip Montanaro, skip at mojam.com, http://www.mojam.com/, > http://www.musi-cal.com/ > On June 24th at 8AM, live your life for an hour as Ricky Byrdsong always > lived > his - run/walk in the Ricky Byrdsong Memorial 5K or just make a donation: > https://www.SignmeupSports.com/Events/Index_Events.asp?EventID=1395 > > > """ > allow programmer to define multiple exit functions to be executed upon > normal > program termination. > """ > > _exithandlers = [] > def _run_exitfuncs(): > while _exithandlers: > func, targs, kargs = _exithandlers[0] > apply(func, targs, kargs) > _exithandlers.remove(_exithandlers[0]) > > def register_exitfunc(func, *targs, **kargs): > """register a function to be executed upon normal program termination > > arguments are a function object, and zero or more arguments to pass to > it. > """ > _exithandlers.append((func, targs, kargs)) > > import sys > try: > x = sys.exitfunc > except AttributeError: > sys.exitfunc = _run_exitfuncs > del sys > > if __name__ == "__main__": > def x1(): > print "running x1" > def x2(n): > print "running x2(%s)" % `n` > def x3(n, kwd=None): > print "running x3(%s, kwd=%s)" % (`n`, `kwd`) > > register_exitfunc(x1) > register_exitfunc(x2, 12) > register_exitfunc(x3, 5, "bar") > register_exitfunc(x3, "no kwd args") > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev > From skip at mojam.com Mon Jun 19 22:55:09 2000 From: skip at mojam.com (Skip Montanaro) Date: Mon, 19 Jun 2000 15:55:09 -0500 (CDT) Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions... In-Reply-To: References: <200006192017.PAA00690@beluga.mojam.com> Message-ID: <14670.34989.887973.797947@beluga.mojam.com> David> +1 on the idea. I wonder if it makes sense to publish a David> mechanism to allow de-registering of callbacks, or if that's David> featuritis. While writing my message I thought, "I'll bet the first question asked will be about unregistering exit functions." I've been using the module I appended to my message unchanged for a couple years and never needed such functionality. I'm sure there are applications that could use it, but I think they'd be a small minority. Since the only defined interface is a single registration function (_run_exitfuncs is only used internally), I think you'd be free to add some unregister function protocol at a later time if it was deemed necessary. David> Also, I'd change: >> try: >> x = sys.exitfunc >> except AttributeError: >> sys.exitfunc = _run_exitfuncs >> del sys David> to: David> try: David> register_exitfuncs(sys.exitfunc) David> finally: David> sys.exitfunc = _run_exitfuncs David> Or some such. register_exitfunc is only meant to be called by clients of the module, not used internally. You're assuming that if something else was already bound to sys.exitfunc that it's not _run_exitfuncs. With your try/finally code try the following (mentally is fine): import exit def foo(): print 1 exit.register_exitfunc(foo) reload(exit) I think you'll see that exit._run_exitfuncs is on its own list of exit functions. That could be bad. The setup code: try: x = sys.exitfunc except AttributeError: sys.exitfunc = _run_exitfuncs is meant to avoid doing anything if any other module beat us to sys.exitfunc. Perhaps it should just be sys.exitfunc = _run_exitfuncs If someone fails to use the defined protocol, screw 'em... ;-) Skip From DavidA at ActiveState.com Mon Jun 19 23:12:03 2000 From: DavidA at ActiveState.com (David Ascher) Date: Mon, 19 Jun 2000 14:12:03 -0700 Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions... In-Reply-To: <14670.34989.887973.797947@beluga.mojam.com> Message-ID: > If someone fails to use the defined protocol, screw 'em... ;-) That's unreasonable given that existing tools might include a library which might be upgraded to use the new mechanism while the old code used its own mechanism happily. For example, I've used my own protocols in the past which went something like... def register_exitfunc(func): old_exitfunc = getattr(sys, 'exitfunc', None) def wrapper(old_exitfunc=old_exitfunc, new_func=func): if old_exitfunc is not None: old_exitfunc() new_func() sys.exitfunc = wrapper or some such, creating a call chain instead of a sequence of calls, and it's a 'fine' protocol in that it worked fine in the absence of a standard. No need to break code if we can avoid it. The point of my pseudo-patch, if it wasn't clear, was that if a function is already in sys.exitfunc, then it should still be called on exit after the new exit module is imported. You're right that my patch didn't properly check that _run_exitfuncs might be that function. --david From skip at mojam.com Mon Jun 19 23:41:54 2000 From: skip at mojam.com (Skip Montanaro) Date: Mon, 19 Jun 2000 16:41:54 -0500 (CDT) Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions... In-Reply-To: References: <14670.34989.887973.797947@beluga.mojam.com> Message-ID: <14670.37794.998270.762852@beluga.mojam.com> >> If someone fails to use the defined protocol, screw 'em... ;-) David> That's unreasonable given that existing tools might include a David> library which might be upgraded to use the new mechanism while David> the old code used its own mechanism happily. Point taken. I'll look at extending the module to accommodate other sys.exitfunc callers. Skip From Vladimir.Marangozov at inrialpes.fr Tue Jun 20 03:11:24 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Tue, 20 Jun 2000 03:11:24 +0200 (CEST) Subject: [Python-Dev] mmapmodule.c,2.10,2.11 In-Reply-To: <20000618002224.A12729@newcnri.cnri.reston.va.us> from "Andrew Kuchling" at Jun 18, 2000 12:22:24 AM Message-ID: <200006200111.DAA01591@python.inrialpes.fr> Andrew Kuchling wrote: > > On Sun, Jun 18, 2000 at 02:50:51AM +0200, Vladimir Marangozov wrote: > >On AIX, the test_mmap fails with errno=EINVAL on the m.flush() method. > >It works okay without the MS_INVALIDATE flag though, so I'd suggest > >removing it from msync in the flush and dealloc methods. > > Ooh, you're right. The Linux msync man page says "MS_ASYNC specifies > that an update be scheduled, but the call returns immediately. > MS_SYNC asks for an update and waits for it to complete. > MS_INVALIDATE asks to invalidate other mappings of the same file (so > that they can be updated with the fresh values just written)." So > MS_INVALIDATE seems far too drastic. Yes. > > >Also, it would probably be a good idea to allow optional flags for > >flush, as it's done in new_mmap_object, the default being only MS_SYNC. > > The problem is: does Windows provide equivalent functionality? (Is > there documentation available online for CreateFileMapping that I > could look at?) Well, I had a look at my Windows book. Although the mmap functionnality is equivalent, overall, there are no equivalent flags in FlushViewOfFile, etc. Maybe this is too subtle to be of any real use after all, so I retract the idea. MS_SYNC alone is fine. Another point: I'm not thrilled about the idea of raising a SystemError for m.resize if native mremap is missing (which is also AIX's case). unmap/mmap again with the new size is the emulation solution everybody would do in Python when m.resize is not implemented. So I'd suggest implementing it in C (which is what the Windows version does, btw). Furthermore, having an unimplemented method makes little sense to me. For implementing this emulation on Unix, however, we would need to remember in additional slots the original mmap flags & rights, so that the second (or any subsequent) mmap call uses the same flags & rights as the first one. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From pf at artcom-gmbh.de Tue Jun 20 09:32:33 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Tue, 20 Jun 2000 09:32:33 +0200 (MEST) Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions... In-Reply-To: from David Ascher at "Jun 19, 2000 2:12: 3 pm" Message-ID: Hi Skip, Hi David, David Ascher: > > If someone fails to use the defined protocol, screw 'em... ;-) > > That's unreasonable given that existing tools might include a library which > might be upgraded to use the new mechanism while the old code used its own > mechanism happily. For example, I've used my own protocols in the past > which went something like... > > def register_exitfunc(func): > old_exitfunc = getattr(sys, 'exitfunc', None) > def wrapper(old_exitfunc=old_exitfunc, new_func=func): > if old_exitfunc is not None: old_exitfunc() > new_func() > sys.exitfunc = wrapper > > or some such, creating a call chain instead of a sequence of calls, and it's > a 'fine' protocol in that it worked fine in the absence of a standard. No > need to break code if we can avoid it. Davids wrapper function implements a FIFO strategy for termination. I think this is not desired. Normally you want LIFO, because higher level services in an application are initialized later during startup. Those services usually depend on lower level services, which should still be available at termination time of the higher level services. I try to explain this by an example: Module A provides some kind of network connections. Module B uses (imports) Module A to access a remote resource administration server to provide access to remote devices or resources. During program termination Module B likes to release all resources reserved for (owned by) the program. It uses Module A to submit a cleanup request to the server. Module A however wants to close all open network connections. The following function (termination protocol) solves this by exchanging the sequence of calls within the wrapper: def register_exit_func(func, *args, **kw): import sys previous_func = sys.exit_func def wrapped_func(previous_func=previous_func, func=func, args=args, kw=kw): try: apply(func, args, kw) finally: if previous_func is not None: previous_func() sys.exit_func = wrapped_func In the past I've placed such a function into a common base module of my apps. But I think, Skip is right, that a termination protocol should be part of the standard library. But a separate module 'exit.py' seems to be overkill for single basic function. May be it should be put into the module 'os'? Handling of program termination is something, which considered as a generic operating system service. From the users point of view 'sys' would be a better place, but this would require rewriting in C: ugly. I also agree with Skip, that the possibility to unregister an exit_func is normally not needed. The same effect can be achieved by doing nothing in the exit_func. Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen) From mhammond at skippinet.com.au Tue Jun 20 10:02:14 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Tue, 20 Jun 2000 18:02:14 +1000 Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions... In-Reply-To: Message-ID: Peter: > Davids wrapper function implements a FIFO strategy for termination. > I think this is not desired. Normally you want LIFO, Agreed. LIFO is definately preferred IMO. Mark. From pf at artcom-gmbh.de Tue Jun 20 10:08:16 2000 From: pf at artcom-gmbh.de (Peter Funk) Date: Tue, 20 Jun 2000 10:08:16 +0200 (MEST) Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions... In-Reply-To: From "(env:" "pf)" at "Jun 20, 2000 9:32:33 am" Message-ID: Hi, I wrote: > def register_exit_func(func, *args, **kw): > import sys > previous_func = sys.exit_func this should have been 'sys.exitfunc'. I've also misssed to note, that I placed the following line into the module init code: import sys; def _nop(): pass; sys.exitfunc = _nop Otherwise I had to use getattr(sys, 'exitfunc', None) as David suggested. Next time I should actually cut'n'paste working code instead typing from blurred memory. :-( Another point I forgot, was that you usually want to install signal handlers on unices, that handle the signal.SIGTERM, signal.SIGHUP and signal.SIGINT signals and invoke exit function to do some final cleanup. Regards, Peter From mal at lemburg.com Tue Jun 20 11:01:50 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 20 Jun 2000 11:01:50 +0200 Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions... References: Message-ID: <394F32FE.B926C19A@lemburg.com> Attached you find a similar module which I have used for years. It has all the requested features, plus allows deregistration and supports a more OO-like interface. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ -------------- next part -------------- A non-text attachment was scrubbed... Name: ExitFunctions.py Type: text/python Size: 2444 bytes Desc: not available URL: From fredrik at pythonware.com Tue Jun 20 12:15:01 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Tue, 20 Jun 2000 12:15:01 +0200 Subject: [Python-Dev] talking about performance... [case closed] References: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid> <20000618152020.B14713@newcnri.cnri.reston.va.us> <008301bfd96e$0bd98d20$f2a6b5d4@hagrid> <394D43B0.8CC7070@lemburg.com> Message-ID: <003101bfdaa0$693b4de0$0900a8c0@SPIFF> mal wrote: > > > Index: unicodeobject.c > > > > MATCH is used in a couple of places; it's probably a better idea > > to change the macro (in Include/unicodeobject.h). MAL? > > Right. I'll add Andrew's proposed patch to the macro def. for the record, my little benchmark now runs about five times faster than before -- which means that 16-bit find is now ~30% faster than 8-bit find (barry? ;-) cheers /F footnote: for the exact figures, see: http://hem.passagen.se/eff/2000_06_01_bot-archive.htm#361472 From mhammond at skippinet.com.au Tue Jun 20 13:42:53 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Tue, 20 Jun 2000 21:42:53 +1000 Subject: [Python-Dev] Fw: Access violation when no memory Message-ID: From gward at mems-exchange.org Tue Jun 20 14:33:44 2000 From: gward at mems-exchange.org (Greg Ward) Date: Tue, 20 Jun 2000 08:33:44 -0400 Subject: [Python-Dev] RFC: Including PIL in 1.6 In-Reply-To: <20000609181924.A15728@thyrsus.com>; from esr@thyrsus.com on Fri, Jun 09, 2000 at 06:19:24PM -0400 References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> Message-ID: <20000620083344.A3499@ludwig.cnri.reston.va.us> On 09 June 2000, Eric S. Raymond said: > I think it's time to consider including PIL in the core Python 1.6 release. > I've been following the work being done over there, and I believe the > code has reached a sufficient level of maturity to justify this. -1 from me. What's the point of the Distutils if we just throw everything "useful" into the standard distribution? Greg From gward at mems-exchange.org Tue Jun 20 14:40:41 2000 From: gward at mems-exchange.org (Greg Ward) Date: Tue, 20 Jun 2000 08:40:41 -0400 Subject: [Python-Dev] Towards 1.6 Final In-Reply-To: <200006130237.EAA10373@python.inrialpes.fr>; from Vladimir.Marangozov@inrialpes.fr on Tue, Jun 13, 2000 at 04:37:23AM +0200 References: <14661.19894.465676.770545@anthem.concentric.net> <200006130237.EAA10373@python.inrialpes.fr> Message-ID: <20000620084040.B3499@ludwig.cnri.reston.va.us> On 13 June 2000, Vladimir Marangozov said: > > - Fix ./ld_so_aix installation problem on AIX (anybody know more about > > this???) > > Yes, AMK, Greg Ward and I know more. It's more an automation (path) problem > for building C extensions with distutils than an installation problem per se. > Some time ago, I saw a workaround checked in by Greg. If this is still judged > as a problem, I'd like to hear about it. This is a minor thing. I have yet > to install & run the distutil package on AIX, though, and see what happens. As I recall, my workaround didn't work. (Would that make it a failaround?) Vladimir, *please* give the Distutils a whirl on AIX -- I suspect some sort of hack is needed to get extension-building working there. I don't much care if the Makefile installed by Python is "fixed" to have an absolute path to "ld_so_aix" instead of "./ld_so_aix" -- that should make extension-building with the Distutils OK, but it will break the relocatability of a Python installation on AIX. Also, it won't fix Distutils with Python 1.5.2. Thanks -- Greg From paul at prescod.net Tue Jun 20 15:30:13 2000 From: paul at prescod.net (Paul Prescod) Date: Tue, 20 Jun 2000 15:30:13 +0200 Subject: [Python-Dev] RFC: Including PIL in 1.6 References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us> Message-ID: <394F71E5.C7CEC32D@prescod.net> Greg Ward wrote: > > ... > -1 from me. What's the point of the Distutils if we just throw > everything "useful" into the standard distribution? One way to look at it is vertical versus horizontal. I think that that's how the Java world works (unofficially). If Java is one extreme and ANSI C is on the other, I prefer to err on the Java side (which we probably do). The big issue is configuration management. if we put PIL (or anything else) in the standard distribution we are promising to keep that code in sync with everything else. This is a big boon to users and a big headache for maintainers. The question is when the boon is enough to justify the headache. It's one thing to tell a user: "Just type distutils and everything will magically become available." But they usually come back: "I'm getting an error message about append not taking that many arguments..." or something like that. Libraries breaking libraries is actually the most common case. -- Paul Prescod - ISOGEN Consulting Engineer speaking for himself "Music is the stuff between the notes." - Claude Debussy From bwarsaw at python.org Tue Jun 20 15:43:32 2000 From: bwarsaw at python.org (Barry A. Warsaw) Date: Tue, 20 Jun 2000 09:43:32 -0400 (EDT) Subject: [Python-Dev] talking about performance... [case closed] References: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid> <20000618152020.B14713@newcnri.cnri.reston.va.us> <008301bfd96e$0bd98d20$f2a6b5d4@hagrid> <394D43B0.8CC7070@lemburg.com> <003101bfdaa0$693b4de0$0900a8c0@SPIFF> Message-ID: <14671.29956.819067.208771@anthem.concentric.net> >>>>> "FL" == Fredrik Lundh writes: FL> for the record, my little benchmark now runs about five FL> times faster than before -- which means that 16-bit find FL> is now ~30% faster than 8-bit find (barry? ;-) Awesome! From akuchlin at cnri.reston.va.us Tue Jun 20 15:53:09 2000 From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling) Date: Tue, 20 Jun 2000 09:53:09 -0400 Subject: [Python-Dev] talking about performance... [case closed] In-Reply-To: <003101bfdaa0$693b4de0$0900a8c0@SPIFF>; from fredrik@pythonware.com on Tue, Jun 20, 2000 at 12:15:01PM +0200 References: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid> <20000618152020.B14713@newcnri.cnri.reston.va.us> <008301bfd96e$0bd98d20$f2a6b5d4@hagrid> <394D43B0.8CC7070@lemburg.com> <003101bfdaa0$693b4de0$0900a8c0@SPIFF> Message-ID: <20000620095309.A3039@amarok.cnri.reston.va.us> On Tue, Jun 20, 2000 at 12:15:01PM +0200, Fredrik Lundh wrote: >for the record, my little benchmark now runs about five >times faster than before -- which means that 16-bit find >is now ~30% faster than 8-bit find (barry? ;-) Speculation: the code in stringobject.c looks like this: for (; i <= last; ++i) if (s[i] == sub[0] && (n == 1 || memcmp(&s[i+1], &sub[1], n-1) == 0)) return (long)i; It checks the first character, and then does the memcmp() skipping the first character, or succeeds if the substring length is 1; the Unicode find is simpler, just doing the full memcmp. I wonder if the extra n == 1 and i+1, n-1 arithmetic costs more than it saves? This is probably delicately tied to the speed of your memcmp(). Anyone want to try the simpler version and report on whether it makes a difference? --amk From effbot at telia.com Tue Jun 20 17:26:42 2000 From: effbot at telia.com (Fredrik Lundh) Date: Tue, 20 Jun 2000 17:26:42 +0200 Subject: [Python-Dev] faster 8-bit find/split (was: talking about performance...) References: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid> <20000618152020.B14713@newcnri.cnri.reston.va.us> <008301bfd96e$0bd98d20$f2a6b5d4@hagrid> <394D43B0.8CC7070@lemburg.com> <003101bfdaa0$693b4de0$0900a8c0@SPIFF> <20000620095309.A3039@amarok.cnri.reston.va.us> Message-ID: <007701bfdacc$0d2e87c0$f2a6b5d4@hagrid> [as discussed on python-dev] amk wrote: > On Tue, Jun 20, 2000 at 12:15:01PM +0200, Fredrik Lundh wrote: > >for the record, my little benchmark now runs about five > >times faster than before -- which means that 16-bit find > >is now ~30% faster than 8-bit find (barry? ;-) > > Speculation: the code in stringobject.c looks like this: > for (; i <= last; ++i) > if (s[i] == sub[0] && > (n == 1 || memcmp(&s[i+1], &sub[1], n-1) == 0)) > return (long)i; > > It checks the first character, and then does the memcmp() skipping the > first character, or succeeds if the substring length is 1; the Unicode > find is simpler, just doing the full memcmp. I wonder if the extra n > == 1 and i+1, n-1 arithmetic costs more than it saves? at least on my box (win95, msvc 5)... after simplifying the code, string.find is now faster than sre.search. it's still 15% slower than the 16-bit string find, but I don't have time to dig into that right now... patches are included. I confirm that, to the best of my knowledge and belief, this contribution is free of any claims of third parties under copyright, patent or other rights or interests ("claims"). To the extent that I have any such claims, I hereby grant to CNRI a nonexclusive, irrevocable, royalty-free, worldwide license to reproduce, distribute, perform and/or display publicly, prepare derivative versions, and otherwise use this contribution as part of the Python software and its related documentation, or any derivative versions thereof, at no cost to CNRI or its licensed users, and to authorize others to do so. I acknowledge that CNRI may, at its sole discretion, decide whether or not to incorporate this contribution in the Python software and its related documentation. I further grant CNRI permission to use my name and other identifying information provided to CNRI by me for use in connection with the Python software and its related documentation. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: string-patch.txt URL: From fdrake at beopen.com Tue Jun 20 17:47:35 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 20 Jun 2000 11:47:35 -0400 (EDT) Subject: [Python-Dev] faster 8-bit find/split (was: talking about performance...) In-Reply-To: <007701bfdacc$0d2e87c0$f2a6b5d4@hagrid> References: <005401bfd958$5c0d7b00$f2a6b5d4@hagrid> <20000618152020.B14713@newcnri.cnri.reston.va.us> <008301bfd96e$0bd98d20$f2a6b5d4@hagrid> <394D43B0.8CC7070@lemburg.com> <003101bfdaa0$693b4de0$0900a8c0@SPIFF> <20000620095309.A3039@amarok.cnri.reston.va.us> <007701bfdacc$0d2e87c0$f2a6b5d4@hagrid> Message-ID: <14671.37399.809253.945519@cj42289-a.reston1.va.home.com> Fredrik Lundh writes: > patches are included. Now checked in, thanks! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one at email.msn.com Tue Jun 20 18:47:47 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 20 Jun 2000 12:47:47 -0400 Subject: [Python-Dev] talking about performance... [case closed] In-Reply-To: <20000620095309.A3039@amarok.cnri.reston.va.us> Message-ID: [Fredrik Lundh] > for the record, my little benchmark now runs about five > times faster than before -- which means that 16-bit find > is now ~30% faster than 8-bit find (barry? ;-) [Andrew M. Kuchling]/ > Speculation: the code in stringobject.c looks like this: > for (; i <= last; ++i) > if (s[i] == sub[0] && > (n == 1 || memcmp(&s[i+1], &sub[1], > n-1) == 0)) > return (long)i; > ... > the Unicode find is simpler, just doing the full memcmp. I wonder > if the extra n == 1 and i+1, n-1 arithmetic costs more than it > saves? So the intent of the code is to avoid the expense of calling memcmp if a full n-character memcmp can't possibly find equality at i (due to mismatch of first characters), and the assumption is that first characters mismatch frequently. Both seem like good calls to me! > This is probably delicately tied to the speed of your memcmp(). Also on whether your memcmp() is an actual external function or a full or partial inline expansion (e.g., the strcmp at KSR expanded into code much like the "by-hand" stuff above, skipping "the real" strcmp if the first characters weren't equal). > Anyone want to try the simpler version and report on whether > it makes a difference? No . But if someone does, a good compromise might be to split this into two loops, one for the n==1 case and another for n>1. The "+1/-1" are dubious in any case (i.e., "memcmp(s+i, sub, n) == 0" saves the fiddly arithmetic at the also-minor cost of making memcmp do one redundant character compare). From dan at cgsoftware.com Tue Jun 20 18:55:11 2000 From: dan at cgsoftware.com (Daniel Berlin) Date: Tue, 20 Jun 2000 09:55:11 -0700 (PDT) Subject: [Python-Dev] talking about performance... [case closed] In-Reply-To: Message-ID: > So the intent of the code is to avoid the expense of calling memcmp if a > full n-character memcmp can't possibly find equality at i (due to mismatch > of first characters), and the assumption is that first characters mismatch > frequently. Both seem like good calls to me! However, smart compilers (gcc 2.95+ fer instance) will produce an inline memcmp call that is faster, and has no overhead (IE it's not making a library call). Thus, the first character mismatch test is useless. We had the same thing in strcmp macros in GDB, where we tested the first character, then strcmp'd. It was faster to just strcmp, even when they *did* mismatch. --Dan From esr at thyrsus.com Tue Jun 20 19:21:50 2000 From: esr at thyrsus.com (esr at thyrsus.com) Date: Tue, 20 Jun 2000 13:21:50 -0400 Subject: [Python-Dev] list comprehensions In-Reply-To: References: <200006191501.KAA02197@cj20424-a.reston1.va.home.com> Message-ID: <20000620132150.O8678@thyrsus.com> Ka-Ping Yee : > On Mon, 19 Jun 2000, Guido van Rossum wrote: > > But submitting a patch might be a good idea anyway so we won't forget > > about it (and maybe it's of such baffling simplicity that it'll charm > > its way past the guards :-). > > I just have to say i thought list comprehensions were > really cool. Ditto. I would like to see this in 1.6. -- Eric S. Raymond The men and women who founded our country knew, by experience, that there are times when the free person's answer to oppressive government has to be delivered with a bullet. Thus, the right to bear arms is not just *a* freedom; it's the mother of all freedoms. Don't let them disarm you! From esr at thyrsus.com Tue Jun 20 20:04:19 2000 From: esr at thyrsus.com (esr at thyrsus.com) Date: Tue, 20 Jun 2000 14:04:19 -0400 Subject: [Python-Dev] RFC: Including PIL in 1.6 In-Reply-To: <20000620083344.A3499@ludwig.cnri.reston.va.us> References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us> Message-ID: <20000620140419.C10038@thyrsus.com> Greg Ward : > -1 from me. What's the point of the Distutils if we just throw > everything "useful" into the standard distribution? Watch that argument -- it could turn and bite you. What's the justification for including, e.g. POP client classes in the standard distribution? One of Python's most important strengths is the "batteries *are* included" richness of the standard environment. -- Eric S. Raymond The two pillars of `political correctness' are, a) willful ignorance, and b) a steadfast refusal to face the truth -- George MacDonald Fraser From effbot at telia.com Tue Jun 20 19:59:35 2000 From: effbot at telia.com (Fredrik Lundh) Date: Tue, 20 Jun 2000 19:59:35 +0200 Subject: [Python-Dev] RFC: Including PIL in 1.6 References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us> Message-ID: <001101bfdae1$5094f7a0$f2a6b5d4@hagrid> greg wrote: > On 09 June 2000, Eric S. Raymond said: > > I think it's time to consider including PIL in the core Python 1.6 release. > > I've been following the work being done over there, and I believe the > > code has reached a sufficient level of maturity to justify this. > > -1 from me. What's the point of the Distutils if we just throw > everything "useful" into the standard distribution? strange argument. what's the point of including *anything* if we have distutils? ... fwiw, I'm -0 on this one; it might better to work on a "Python Standards Base" which specifies a bunch of extensions that people are encouraged to include in their distributions. let's see: zlib, expat, (portions of) numpy, pil, piddle, ... From effbot at telia.com Tue Jun 20 20:02:24 2000 From: effbot at telia.com (Fredrik Lundh) Date: Tue, 20 Jun 2000 20:02:24 +0200 Subject: [Python-Dev] talking about performance... References: Message-ID: <002001bfdae1$b28942e0$f2a6b5d4@hagrid> tim wrote: > No . But if someone does, a good compromise might be to split this > into two loops, one for the n==1 case and another for n>1. how about this one: if (dir > 0) { char *p, *e; if (n == 0 && i <= last) return (long)i; e = s + last - n + 1; for (;;) { p = memchr(s, sub[0], e - s); if (p == NULL) break; if (n == 1 || memcmp(p, sub, n) == 0) return (long) (p - s); s = p + 1; } } new record time: 1.6 seconds (down from 2.2) From akuchlin at cnri.reston.va.us Tue Jun 20 20:04:06 2000 From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling) Date: Tue, 20 Jun 2000 14:04:06 -0400 Subject: [Python-Dev] RFC: Including PIL in 1.6 In-Reply-To: <20000620140419.C10038@thyrsus.com>; from esr@thyrsus.com on Tue, Jun 20, 2000 at 02:04:19PM -0400 References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us> <20000620140419.C10038@thyrsus.com> Message-ID: <20000620140406.B3142@amarok.cnri.reston.va.us> >Watch that argument -- it could turn and bite you. What's the justification >for including, e.g. POP client classes in the standard distribution? >One of Python's most important strengths is the "batteries *are* >included" richness of the standard environment. Once there are enough pieces to make finding and getting the software near-automatic, I actually wouldn't mind splitting them out and shipping a much smaller core distribution, perhaps with a script that downloads the latest versions of what's in the standard library. Debian did that for a while, with python-net, python-base, python-text, &c. I just compiled XEmacs 21.1.10 on a new Linux machine; you compile the binary, and install two packages of Elisp code (EFS and xemacs-base). Then you run xemacs, do Options > Manage Packages > List and Install, and you get a nice list containing GNUS, W3, programming language modes, etc. Pick the ones you want, it adds the ones needed by the ones you selected, and it fetches and installs them. Easy! Now imagine doing the same thing with Python modules. Of course, we'd have to design that feature first... (ESR & Paul Prescod vs. AMK & GPW: the First Pythonic War! :) ) -- A.M. Kuchling http://starship.python.net/crew/amk/ This is, after all, a book about reading, and the kind of reader I am addressing does not care primarily about being in fashion. -- Robertson Davies, _A Voice from the Attic_ From DavidA at ActiveState.com Tue Jun 20 20:16:40 2000 From: DavidA at ActiveState.com (David Ascher) Date: Tue, 20 Jun 2000 11:16:40 -0700 Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions... In-Reply-To: Message-ID: > Peter: > > > Davids wrapper function implements a FIFO strategy for termination. > > I think this is not desired. Normally you want LIFO, > > Agreed. LIFO is definately preferred IMO. Agreed. My wrapper was also from memory, and that was not at all the main point of my post =). --da From akuchlin at cnri.reston.va.us Tue Jun 20 20:17:47 2000 From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling) Date: Tue, 20 Jun 2000 14:17:47 -0400 Subject: [Python-Dev] Re: [Patches] Adding sip to urlparse In-Reply-To: <002c01bfdae3$e4b71ba0$f2a6b5d4@hagrid>; from effbot@telia.com on Tue, Jun 20, 2000 at 08:18:03PM +0200 References: <14671.44450.197852.869640@rama.research.nokia.com> <14671.45733.968387.361146@cj42289-a.reston1.va.home.com> <002c01bfdae3$e4b71ba0$f2a6b5d4@hagrid> Message-ID: <20000620141747.D3142@amarok.cnri.reston.va.us> On Tue, Jun 20, 2000 at 08:18:03PM +0200, Fredrik Lundh quoted FLD: >> What is "sip"? Is it defined by an RFC (which?), or Internet Draft >> (which? what's the expected activity?). Is there a canonical list of all the defined URL types anywhere? I notice that 'ldap' isn't there, and maybe there are more missing. (Some of the ones in there are marginal: who cares about Prospero?) -- A.M. Kuchling http://starship.python.net/crew/amk/ That's so obvious that someone has already got a patent on it. -- Guido van Rossum, 12 Jan 1999 From DavidA at ActiveState.com Tue Jun 20 20:29:26 2000 From: DavidA at ActiveState.com (David Ascher) Date: Tue, 20 Jun 2000 11:29:26 -0700 Subject: [Python-Dev] Re: [Patches] Adding sip to urlparse In-Reply-To: <20000620141747.D3142@amarok.cnri.reston.va.us> Message-ID: > Is there a canonical list of all the defined URL types anywhere? I > notice that 'ldap' isn't there, and maybe there are more missing. > (Some of the ones in there are marginal: who cares about Prospero?) Mozilla defines a bunch, which I doubt are RFC anything. (chrome://, component://, etc.). --david From jeremy at beopen.com Tue Jun 20 20:33:59 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Tue, 20 Jun 2000 14:33:59 -0400 (EDT) Subject: [Python-Dev] RFC: Including PIL in 1.6 In-Reply-To: <20000620140406.B3142@amarok.cnri.reston.va.us> References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us> <20000620140419.C10038@thyrsus.com> <20000620140406.B3142@amarok.cnri.reston.va.us> Message-ID: <14671.47383.313007.531923@localhost.localdomain> >>>>> "AMK" == Andrew M Kuchling writes: AMK> I just compiled XEmacs 21.1.10 on a new Linux machine; you AMK> compile the binary, and install two packages of Elisp code (EFS AMK> and xemacs-base). Then you run xemacs, do Options > Manage AMK> Packages > List and Install, and you get a nice list containing AMK> GNUS, W3, programming language modes, etc. Pick the ones you AMK> want, it adds the ones needed by the ones you selected, and it AMK> fetches and installs them. Easy! Now imagine doing the same AMK> thing with Python modules. Of course, we'd have to design that AMK> feature first... I did the same install on my new Linux box last month. I was similarly pleased with the ease of installation. Let's get working on a design for this feature! Jeremy From effbot at telia.com Tue Jun 20 20:37:30 2000 From: effbot at telia.com (Fredrik Lundh) Date: Tue, 20 Jun 2000 20:37:30 +0200 Subject: [Python-Dev] Re: [Patches] Adding sip to urlparse References: <14671.44450.197852.869640@rama.research.nokia.com> <14671.45733.968387.361146@cj42289-a.reston1.va.home.com> <002c01bfdae3$e4b71ba0$f2a6b5d4@hagrid> <20000620141747.D3142@amarok.cnri.reston.va.us> Message-ID: <004c01bfdae6$9abbdec0$f2a6b5d4@hagrid> amk wrote: > Is there a canonical list of all the defined URL types anywhere? I > notice that 'ldap' isn't there, and maybe there are more missing. your local search bot to the rescue: http://www.isi.edu/in-notes/iana/assignments/url-schemes (see http://www.iana.org/numbers.htm for a full list of things they keep track of) From akuchlin at cnri.reston.va.us Tue Jun 20 20:44:40 2000 From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling) Date: Tue, 20 Jun 2000 14:44:40 -0400 Subject: [Python-Dev] RFC: Including PIL in 1.6 In-Reply-To: <14671.47383.313007.531923@localhost.localdomain>; from jeremy@beopen.com on Tue, Jun 20, 2000 at 02:33:59PM -0400 References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us> <20000620140419.C10038@thyrsus.com> <20000620140406.B3142@amarok.cnri.reston.va.us> <14671.47383.313007.531923@localhost.localdomain> Message-ID: <20000620144440.E3142@amarok.cnri.reston.va.us> On Tue, Jun 20, 2000 at 02:33:59PM -0400, Jeremy Hylton wrote: >I did the same install on my new Linux box last month. I was >similarly pleased with the ease of installation. Let's get working on >a design for this feature! I have some notes on this, but they're at home. I'll post them tonight. --amk From paul at prescod.net Tue Jun 20 20:42:21 2000 From: paul at prescod.net (Paul Prescod) Date: Tue, 20 Jun 2000 13:42:21 -0500 Subject: [Python-Dev] RFC: Including PIL in 1.6 References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us> <20000620140419.C10038@thyrsus.com> <20000620140406.B3142@amarok.cnri.reston.va.us> Message-ID: <394FBB0D.96D88DBB@prescod.net> "Andrew M. Kuchling" wrote: > > ... > > I just compiled XEmacs 21.1.10 on a new Linux machine; you compile the > binary, and install two packages of Elisp code (EFS and xemacs-base). > Then you run xemacs, do Options > Manage Packages > List and Install, > and you get a nice list containing GNUS, W3, programming language > modes, etc. Pick the ones you want, it adds the ones needed by the > ones you selected, and it fetches and installs them. Easy! Now > imagine doing the same thing with Python modules. Of course, we'd > have to design that feature first... Let me repeat that I don't think that the main issue is whether it lives in this tarfile versus that tarfile. It's a) about agreeing to keep everything comptible. b) about being able to depend on the thing being there when you write a module. *In theory* Red Hat linux could be a kernel, a shell and the RPM engine. In practice, people like to be able to say: "if you have Red Hat version X then such and such will work because it comes with a functional package Y." Distutils is extremely important for vertical modules but if we start to use it as an excuse for leaving out core modules then I have to go with ESR and say: "where do we stop?" Unicode on demand? re on demand? pickle on demand? I think that the more relevant criteria are the ones we have always used: * how big is it * how easy is it to maintain * how integrated is it with everything else * how well-thought-out is it * and most important: how many people want it? I think that PIL is not yet a clear home run. -- Paul Prescod - ISOGEN Consulting Engineer speaking for himself "Music is the stuff between the notes." - Claude Debussy From guido at python.org Tue Jun 20 22:09:05 2000 From: guido at python.org (Guido van Rossum) Date: Tue, 20 Jun 2000 15:09:05 -0500 Subject: [Python-Dev] RFC: Including PIL in 1.6 In-Reply-To: Your message of "Tue, 20 Jun 2000 14:04:06 -0400." <20000620140406.B3142@amarok.cnri.reston.va.us> References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us> <20000620140419.C10038@thyrsus.com> <20000620140406.B3142@amarok.cnri.reston.va.us> Message-ID: <200006202009.PAA01064@cj20424-a.reston1.va.home.com> > I just compiled XEmacs 21.1.10 on a new Linux machine; you compile the > binary, and install two packages of Elisp code (EFS and xemacs-base). > Then you run xemacs, do Options > Manage Packages > List and Install, > and you get a nice list containing GNUS, W3, programming language > modes, etc. Pick the ones you want, it adds the ones needed by the > ones you selected, and it fetches and installs them. Easy! Now > imagine doing the same thing with Python modules. Of course, we'd > have to design that feature first... I just had to go through that process. It was actually rather painful, and I wouldn't have been able to succeed if it wasn't for XEmax grandmaster Barry Warsaw standing next to me holding my hand for a really long time... The autofetcher appeared broken at first, then had some unintuitive behavior next, before we finally got it running. Finally I got the hang of it, but after that I still had about a week where I occasionally used a familiar keystroke that triggered an error, and usually it took an email to Barry to find out which package contained the module defining the missing function. Not to say that I'm against this kind of thing, but warning that even in the best circumstances it can be a hurdle for newcomers... Which is why there's a market for packagers like Red Hat. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Tue Jun 20 22:12:09 2000 From: guido at python.org (Guido van Rossum) Date: Tue, 20 Jun 2000 15:12:09 -0500 Subject: [Python-Dev] Re: [Patches] Adding sip to urlparse In-Reply-To: Your message of "Tue, 20 Jun 2000 20:37:30 +0200." <004c01bfdae6$9abbdec0$f2a6b5d4@hagrid> References: <14671.44450.197852.869640@rama.research.nokia.com> <14671.45733.968387.361146@cj42289-a.reston1.va.home.com> <002c01bfdae3$e4b71ba0$f2a6b5d4@hagrid> <20000620141747.D3142@amarok.cnri.reston.va.us> <004c01bfdae6$9abbdec0$f2a6b5d4@hagrid> Message-ID: <200006202012.PAA01130@cj20424-a.reston1.va.home.com> > > Is there a canonical list of all the defined URL types anywhere? I > > notice that 'ldap' isn't there, and maybe there are more missing. > > your local search bot to the rescue: > http://www.isi.edu/in-notes/iana/assignments/url-schemes Of course now the trick is which ones are still relevant (as the doubt expressed about prospero exemplify). --Guido van Rossum (home page: http://www.python.org/~guido/) From fdrake at beopen.com Tue Jun 20 21:10:31 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 20 Jun 2000 15:10:31 -0400 (EDT) Subject: [Python-Dev] David Ascher's compile.py script? Message-ID: <14671.49575.161122.528241@cj42289-a.reston1.va.home.com> Does anyone have a copy of David Ascher's compile.py from his starship pages? The links there appear to be broken, and David appearantly hasn't been able to find time to look for a copy, or can't find it (I've sent him another mail about it in case it has turned up), and documentation users are asking about it. (There's a link from the extending & embedding manual.) If anyone has a copy, perhaps I could find provide a temporary location for it and revise the link in the online documentation to point there, as a stop-gap measure. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From nascheme at enme.ucalgary.ca Tue Jun 20 21:18:03 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Tue, 20 Jun 2000 13:18:03 -0600 Subject: [Python-Dev] David Ascher's compile.py script? In-Reply-To: <14671.49575.161122.528241@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Tue, Jun 20, 2000 at 03:10:31PM -0400 References: <14671.49575.161122.528241@cj42289-a.reston1.va.home.com> Message-ID: <20000620131803.A13811@acs.ucalgary.ca> On Tue, Jun 20, 2000 at 03:10:31PM -0400, Fred L. Drake, Jr. wrote: > Does anyone have a copy of David Ascher's compile.py from his > starship pages? I don't know how recent this copy is: http://www.enme.ucalgary.ca/~nascheme/python/compile.py Neil From fdrake at beopen.com Tue Jun 20 21:19:05 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 20 Jun 2000 15:19:05 -0400 (EDT) Subject: [Python-Dev] David Ascher's compile.py script? In-Reply-To: <20000620131803.A13811@acs.ucalgary.ca> References: <14671.49575.161122.528241@cj42289-a.reston1.va.home.com> <20000620131803.A13811@acs.ucalgary.ca> Message-ID: <14671.50089.860177.145255@cj42289-a.reston1.va.home.com> Neil Schemenauer writes: > I don't know how recent this copy is: > > http://www.enme.ucalgary.ca/~nascheme/python/compile.py Thanks! If nothing else shows up within the next day, I'll use this one. David, is this sufficiently recent? -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From skip at mojam.com Tue Jun 20 21:33:20 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 20 Jun 2000 14:33:20 -0500 (CDT) Subject: [Python-Dev] RFC: Including PIL in 1.6 In-Reply-To: <200006202009.PAA01064@cj20424-a.reston1.va.home.com> References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us> <20000620140419.C10038@thyrsus.com> <20000620140406.B3142@amarok.cnri.reston.va.us> <200006202009.PAA01064@cj20424-a.reston1.va.home.com> Message-ID: <14671.50944.796299.47756@beluga.mojam.com> Guido> I just had to go through that process. It was actually rather Guido> painful ... I will echo that sentiment. Actually, the first time I upgraded to the package stuff it went without a hitch. The next time it took me awhile to figure out why it didn't work. I imagine it's just teething pain that will get worked out as the XEmacs folks get more experience themselves, but auto-package install is definitely something that would have to be pretty bulletproof. I doubt the average Python user will have a similar level of computer savvy as the average XEmacs user. On top of that, how will you know that you want package X until you download it and try it out? I presume that carried to its logical conclusion, a package's documentation would be installed along with its source... chicken-and-egg-ly y'rs, -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On June 24th at 8AM, live your life for an hour as Ricky Byrdsong always lived his - run/walk in the Ricky Byrdsong Memorial 5K or just make a donation: https://www.SignmeupSports.com/Events/Index_Events.asp?EventID=1395 From paul at prescod.net Tue Jun 20 22:09:18 2000 From: paul at prescod.net (Paul Prescod) Date: Tue, 20 Jun 2000 15:09:18 -0500 Subject: [Python-Dev] Argh... Message-ID: <394FCF6E.85559D56@prescod.net> Okay, this is blatantly off-topic. I'm trying to increase the noise ratio so that people here will go back to comp.lang.python. All I need is for someone to email me in private email what's the Java equivalent of a=sys.argv[0] (it's almost over, it's almost over, it's almost over) Okay, here's an obPython: why doesn't the main module have an __file__ if it happens to be a file. I can understand why one piped in wouldn't but the interpreter knows when the main module is a file. -- Paul Prescod "Music is the stuff between the notes." - Claude Debussy From guido at python.org Tue Jun 20 23:31:00 2000 From: guido at python.org (Guido van Rossum) Date: Tue, 20 Jun 2000 16:31:00 -0500 Subject: [Python-Dev] Argh... In-Reply-To: Your message of "Tue, 20 Jun 2000 15:09:18 EST." <394FCF6E.85559D56@prescod.net> References: <394FCF6E.85559D56@prescod.net> Message-ID: <200006202131.QAA01631@cj20424-a.reston1.va.home.com> > Okay, here's an obPython: why doesn't the main module have an __file__ > if it happens to be a file. I can understand why one piped in wouldn't > but the interpreter knows when the main module is a file. Mostly because it's tough to pass that information around all the way to where it's needed. --Guido van Rossum (home page: http://www.python.org/~guido/) From mhammond at skippinet.com.au Wed Jun 21 01:06:57 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Wed, 21 Jun 2000 09:06:57 +1000 Subject: [Python-Dev] RFC: Including PIL in 1.6 In-Reply-To: <200006202009.PAA01064@cj20424-a.reston1.va.home.com> Message-ID: [Guido] > Not to say that I'm against this kind of thing, but warning that even > in the best circumstances it can be a hurdle for newcomers... > > Which is why there's a market for packagers like Red Hat. And even _then_ it is hard to get right. My experience similar to this was with debian, and its xptselect package. I was a Linux newbie, and the entire installation went pretty well until I was asked which packages I want to fetch and install. I was _soooo_ lost. I found the interface a complete mystery. It appeard to make random selections of stuff I didnt want, then randomly de-select stuff I didnt want. I had no idea how to search for anything, and the help was less than useful. Sometimes it wanted to download nothing, other times it wanted to download 400MB to complete the install!!! I only just resisted the temptation to go and buy a bunch of MS stock . Of course, within a week, I understood what was going on, and the sofware was indeed functioning correctly. But it took me that entire week to have a Linux system with everything I wanted installed and working correctly. The point I am trying to make is that for stuff that should be considered "core", the bar is very very high for these auto-configure applications. The usual audience will be _complete_ newbies. In my example, it was clear that a complete linux newbie was never let loose on this program while sitting in the same room as the author or the marketting team ;-) But I expect those with reasonable Linux experience quite like it, and themselves would not be happy with the complete-newbie version. The-included-batteries-were-the-wrong-size-ly, Mark. From Vladimir.Marangozov at inrialpes.fr Wed Jun 21 01:34:31 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Wed, 21 Jun 2000 01:34:31 +0200 (CEST) Subject: [Python-Dev] Fw: Access violation when no memory In-Reply-To: from "Mark Hammond" at Jun 20, 2000 09:42:53 PM Message-ID: <200006202334.BAA03150@python.inrialpes.fr> Mark Hammond wrote: > > >From the newsgroup. Any thoughts? > > Mark. > > "Phil Mayes" wrote in message > news:... > > The following program progressively allocates all memory: > > size = 1 << 20 > > list = [None,] > > while size: > > try: > > mem = [None] * size > > mem[0] = list > > list = mem > > except: > > size = size / 2 > > > > It fails with an access violation. The only immediate thought I have is that Python does not have builtin emergency procedures for such extreme situations. Although there are some safety checks, it is fairly easy to crash the interpreter in a number of ways. For example, with the introduction of the mmapmodule, there are even more "risks", like managing to mmap the python executable and screw it up completely (not speaking of the possibility to introduce Trojan horses and similar if this is done on purpose). There would probably be more checks, but complete safety is hard to achieve in the current state. The proposed solution is not a solution. The example program dumps core in different locations on my machine. We just do not have enough control from Python for managing such extreme cases. Sad, but true... -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From amk1 at erols.com Wed Jun 21 03:46:43 2000 From: amk1 at erols.com (A.M. Kuchling) Date: Tue, 20 Jun 2000 21:46:43 -0400 Subject: [Python-Dev] Installation requirements Message-ID: <200006210146.VAA01220@207-172-37-166.s166.tnt7.ann.va.dialup.rcn.com> [Follow-up to the Distutils SIG, please.] There are a few steps needed to find and install a package: 1) Discovery : which module does what I need? 2) Download : where can I get a copy? 3) Security : is this actually from the package author, and not a Trojan? 4) Installation : how do I set it up? 5) Checking for new versions: I have 1.0 installed; is a newer version available? Distutils focuses on the hardest and most complicated step, #4. For #1, you would need to browse through a list of available packages, browse through a hierarchy like Parnassus, or do keyword searches. #2 is pretty simple, since you just get one or more download URLs corresponding to a given package name, using the same database as in #1. For #3, you'd have to check a signature on the downloaded package, using something external like GnuPG. This means this step has to be skipped if the external tool isn't available. We could implement our own signature scheme with Python code, but that's a bad idea; security is hard, and few people will bother to generate keys that are only useful for this one application of distributing Python modules. (Side note: the sdist and bdist_* commands should have a --sign switch to sign the generated .tgz, .rpm, or whatever file.) For #5, the existing stuff in Tools/versioncheck might be partially applicable, though it requires that every package have a text file somewhere which gives the latest version. You'd want to use the same database for everything, to ensure that people actually use it! To start off with, we'd need some sort of generic API to the above functions, so that different interfaces can be written. A command-line interface would then be easiest. I don't know how network communications should be handled: HTTP to CGI scripts that return sets of RFC-822 headers, maybe? Combined with a DNS alias like modules.python.org, or modules.{us,uk,...}.python.org? Some potential sources of inspiration: Debian: apt Perl: CPAM.pm FreeBSD: ports system RPMfind (rpmfind.net) XEmacs: packages system -- A.M. Kuchling http://starship.python.net/crew/amk/ "Jo, it's a pity escapology wasn't part of your curriculum." "Funny you should say that. Look." -- The Doctor and Jo, tied up, in "Terror of the Autons" From tim_one at email.msn.com Wed Jun 21 05:44:18 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 20 Jun 2000 23:44:18 -0400 Subject: [Python-Dev] talking about performance... In-Reply-To: <002001bfdae1$b28942e0$f2a6b5d4@hagrid> Message-ID: [posted & mailed] [Fredrik Lundh] > how about this one: > > if (dir > 0) { > char *p, *e; > if (n == 0 && i <= last) > return (long)i; > e = s + last - n + 1; > for (;;) { > p = memchr(s, sub[0], e - s); > if (p == NULL) > break; > if (n == 1 || memcmp(p, sub, n) == 0) > return (long) (p - s); > s = p + 1; > } > } > > new record time: 1.6 seconds (down from 2.2) I expect that whether this is faster or slower depends on both the compiler you're using and the exact strings you're using to time it. In any case, it appears to be incorrect: p & s both change inside the infinite loop, and the innermost return computes their difference. Surely it should be returning the difference between p and the value s had *before* the loop was entered. If this passed your tests, then, it suggests you had no "false hits" (i.e., that the inner loop returned on its first iteration, else the return value would have been wrong), which are probably the cases in which using memchr rather than the current code is least likely to slow things down. It's bad that the original code never bothered to document what it's supposed to return, but that's no excuse to return probabilistically-correct gibberish . From tim_one at email.msn.com Wed Jun 21 05:44:25 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 20 Jun 2000 23:44:25 -0400 Subject: [Python-Dev] list comprehensions In-Reply-To: <20000620132150.O8678@thyrsus.com> Message-ID: [Ka-Ping Yee] > I just have to say i thought list comprehensions were > really cool. [Eric S. Raymond] > Ditto. I would like to see this in 1.6. Nobody has been more vocal in support of these (& augmented assignments) than me, but I very strongly doubt they'll be in 1.6. In the interests of getting that out the door, Guido considers the 1.6 feature set to be frozen already. I think part of the pressure to get one more feature in Python (again & again & again) is that release cycles have been soooooo protracted, now slobbering well over the full year mark. If I accomplish nothing else at BeOpen, I want to give that a major speed boost -- I don't think we should ever let 6 months go by without at least pumping out a bugfix release. there-are-other-things-guido-doesn't-yet-know-he-believes-too-ly y'rs - tim From skip at mojam.com Wed Jun 21 06:33:12 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 20 Jun 2000 23:33:12 -0500 (CDT) Subject: [Python-Dev] feeble attempt at list comprehensions doc... Message-ID: <14672.17800.994102.266619@beluga.mojam.com> Attached to this message are two patches, one for Doc/ref/ref5.tex and one for Doc/tut/tut.tex. They provide minimal documentation for list comprehensions. I'm sure just about anyone else could do better. Feel free to embellish. The BNF used in the reference manual doesn't seem to match the BNF in the Grammar file very well, so I'm not even certain I have the correct BNF or have it in the correct place. In particular, I'm pretty sure the BNF for list_for and list_if are incorrect. -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On June 24th at 8AM, live your life for an hour as Ricky Byrdsong always lived his - run/walk in the Ricky Byrdsong Memorial 5K or just make a donation: https://www.SignmeupSports.com/Events/Index_Events.asp?EventID=1395 -------------- next part -------------- A non-text attachment was scrubbed... Name: tut.diff Type: application/octet-stream Size: 1000 bytes Desc: list comprehension diffs URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ref5.diff Type: application/octet-stream Size: 1141 bytes Desc: reference manual diff URL: From tim_one at email.msn.com Wed Jun 21 06:53:59 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 21 Jun 2000 00:53:59 -0400 Subject: [Python-Dev] Warnings in mmapmodule Message-ID: I get these warnings in Modules/mmapmodule.c, all about signed/unsigned mismatches: Modules\mmapmodule.c(571) : warning C4018: '>=' : signed/unsigned mismatch if (i < 0 || i >= self->size) { Modules\mmapmodule.c(586) : warning C4018: '>' : signed/unsigned mismatch else if (ilow > self->size) Modules\mmapmodule.c(592) : warning C4018: '>' : signed/unsigned mismatch else if (ihigh > self->size) Modules\mmapmodule.c(631) : warning C4018: '>' : signed/unsigned mismatch else if (ilow > self->size) Modules\mmapmodule.c(637) : warning C4018: '>' : signed/unsigned mismatch else if (ihigh > self->size) Modules\mmapmodule.c(664) : warning C4018: '>=' : signed/unsigned mismatch if (i < 0 || i >= self->size) { I'll volunteer to fix these if nobody else does (although at the moment I'm not able to produce either a patch or check in). new-laptops-in-hotel-rooms-have-their-limitations-ly y'rs - tim From mhammond at skippinet.com.au Wed Jun 21 06:57:54 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Wed, 21 Jun 2000 14:57:54 +1000 Subject: [Python-Dev] Warnings in mmapmodule In-Reply-To: Message-ID: > I get these warnings in Modules/mmapmodule.c, all about signed/unsigned > mismatches: Me too :-) > I'll volunteer to fix these if nobody else does (although at the > moment I'm > not able to produce either a patch or check in). I nearly did, but then couldnt find the time to chase up how Unix declared the relevant items - I didnt want to assume they were identical to Windows. My intention was to make the patch, then test it out on my gleaming Linux box. But-the-road-to-hell-is-paved-with-good-intentions-ly, Mark. From tim_one at email.msn.com Wed Jun 21 07:22:37 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 21 Jun 2000 01:22:37 -0400 Subject: [Python-Dev] Warnings in mmapmodule In-Reply-To: Message-ID: [posted & mailed] [Tim] > I get these warnings in Modules/mmapmodule.c, all about signed/unsigned > mismatches: [Mark Hammond] > Me too :-) > > I nearly [fixed them], but then couldnt find the time to chase up how > Unix declared the relevant items - I didnt want to assume they were > identical to Windows. They all involve mixing ints with mmap_object.size in comparisons, which latter is declared size_t and so will resolve to *some* unsigned integral type on all platforms. The proper fix is to get rid of the ints before making these tests -- ask Trent, he should be able to do this in his sleep now . > My intention was to make the patch, then test it out on my gleaming Linux > box. > > But-the-road-to-hell-is-paved-with-good-intentions-ly, No, it's paved with Linux: I've been using Windows so long I forgot why Unix is supposed to be more usable <0.9 wink>. Mark, if you've figured out how to do a SourceForge checkin from a Windows box, drop me a line offline! It would save me from figuring out which one of the 10,000 SSH+Windows search hits actually leads to something that works (and, no, so long as my entire life is sitting on my laptop, I'm not getting another OS anywhere near this box). becoming-a-linux-true-believer-again-is-on-my-schedule-but-not- for-a-couple-months-ly y'rs - tim From DavidA at ActiveState.com Wed Jun 21 07:40:36 2000 From: DavidA at ActiveState.com (David Ascher) Date: Tue, 20 Jun 2000 22:40:36 -0700 Subject: [Python-Dev] Warnings in mmapmodule In-Reply-To: Message-ID: > No, it's paved with Linux: I've been using Windows so long I forgot why > Unix is supposed to be more usable <0.9 wink>. Mark, if you've > figured out > how to do a SourceForge checkin from a Windows box, drop me a > line offline! No, please, drop us all a line online! I've decided that I'm not going to waste any more of my time dealing w/ SourceForge. Luckily I seem to have found some helpers for the PyOpenGL transition who are willing to deal with that! --david From mhammond at skippinet.com.au Wed Jun 21 07:49:45 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Wed, 21 Jun 2000 15:49:45 +1000 Subject: [Python-Dev] CVS and SSH under windows. In-Reply-To: Message-ID: [David] > No, please, drop us all a line online! OK - here it is, for what it is worth. You will notice that I spent the time to research my facts carefully before giving out this information (NOT!) Sure. It is a bit of a PITA (surprise, surprise, surprise): First, get the latest WinCVS. Has some nice new features. Mine shows as 1.1b13. It has a slightly ?slicker? more windowsy look than the older one. What we really want is the version with the Options/Preferences dialog that allows you to supply the ?RAS identity? file when you select ?SSH Server? as the auth method. Previous versions allow you to select the SSH Server, but give you nowhere to put the identity file. Hence previous versions used a batch file wrapper, which you probably saw reference to. This version makes it much simpler. I use the standard SSH Version 1.2.14 binary set. I cant recall the URL, but it is quite small and only a few binary files. ?ssh? shows usage - ?ssh -v? shows versbose usage, ?verbose? in this context apparently means showing the version number (took me ages to work that one out :-) There were only a few files, so I just dumped them all in the same directory as the CVS binaries. You then need to make a ?key? file - I cant recall the exact process, but it is pretty simple. This is creating the identify file you specify to WinCVS, as well as the public key you upload to source-force. NOTE - from memory, you MUST have a HOME env var set, and you MUST have a ?.ssh? directory under your home. Otherwise you get cryptic errors from SSH that give no clue that this is the problem. After uploading the public key to source forge, you are nearly set. The last step is convinving CVS that you want to use this new SSH setting, and not the setting CVS so kindly persists in its ?CVS\Root? files. The only way I found to do this was to either edit the Root files manually, or remove the directories locally and force CVS to re-create them (and thereby re-pull everything - I assume you have ADSL in that hotel room :-) Alternatively, dig up that CVS script posted to py-dev recently and change it - personally, I never trusted it :-) All my root files look like: :ext:mhammond at cvs.python.sourceforge.net:/cvsroot/python Yours almost certainly will be setup for anon access, not using ssh. Hope that makes sense. Im happy to chase anything else up I can for you... Mark. From effbot at telia.com Wed Jun 21 09:58:06 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 21 Jun 2000 09:58:06 +0200 Subject: [Python-Dev] talking about performance... References: Message-ID: <006401bfdb56$6f84ae60$f2a6b5d4@hagrid> tim wrote: > > p = memchr(s, sub[0], e - s); > > if (p == NULL) > > break; > > if (n == 1 || memcmp(p, sub, n) == 0) > > return (long) (p - s); > I expect that whether this is faster or slower depends on both the compiler > you're using and the exact strings you're using to time it. With test strings that contain false matches for every single position, it's 30% slower than the old code in my tests. With test strings that contain no false matches, it's 50% faster. But without more extensive tests on a variety of platforms, we might as well forget about this one... From mal at lemburg.com Wed Jun 21 10:23:02 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 21 Jun 2000 10:23:02 +0200 Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions... References: Message-ID: <39507B66.763DB418@lemburg.com> [Skip's exit.py module + David's extension to support already registered exitfunc'tions] Looks like everyone agrees -- with a final word from Guido we'd only need some docs to go with it and then check Skip's module in as new standard module. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From skip at mojam.com Wed Jun 21 15:38:01 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 21 Jun 2000 08:38:01 -0500 (CDT) Subject: [Python-Dev] Proposal: standard way of defining and executing "atexit" functions... In-Reply-To: <39507B66.763DB418@lemburg.com> References: <39507B66.763DB418@lemburg.com> Message-ID: <14672.50489.611301.616242@beluga.mojam.com> MA> Looks like everyone agrees -- with a final word from Guido we'd only MA> need some docs to go with it and then check Skip's module in as new MA> standard module. I'll try to get David's enhancement added to my code and write some simple documentation today. Is "exit.py" acceptable with everyone as the name of the module? Skip From skip at mojam.com Wed Jun 21 20:15:19 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 21 Jun 2000 13:15:19 -0500 (CDT) Subject: [Python-Dev] updated exit.py and supporting files for your perusal Message-ID: <14673.1591.506532.170015@beluga.mojam.com> This message contains four attached files: Lib/exit.py - a module that allows users to register cleanup functions Lib/test/test_exit.py - a simple test script Lib/test/output/test_exit - expected test output Doc/lib/libexit.tex - library reference manual section Besides adding documentation and a test script, the following two mods were made to exit.py since I previously posted it: 1. It implements a LIFO execution order 2. If sys.exitfunc is already defined and not exit._run_exitfuncs, it is treated as an exit function and appended to the exit function list. Comments, please. Also, can someone tell me how to coax CVS into creating a unified diff that actually contains new files? I tried cvs diff -RNau without success. Thanks, -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On June 24th at 8AM, live your life for an hour as Ricky Byrdsong always lived his - run/walk in the Ricky Byrdsong Memorial 5K or just make a donation: https://www.SignmeupSports.com/Events/Index_Events.asp?EventID=1395 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: exit.py URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: test_exit.py URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: test_exit URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: libexit.tex URL: From trentm at activestate.com Wed Jun 21 21:20:12 2000 From: trentm at activestate.com (Trent Mick) Date: Wed, 21 Jun 2000 12:20:12 -0700 Subject: [Python-Dev] Warnings in mmapmodule In-Reply-To: References: Message-ID: <20000621122012.A28236@activestate.com> On Wed, Jun 21, 2000 at 01:22:37AM -0400, Tim Peters wrote: > [posted & mailed] > > [Tim] > > I get these warnings in Modules/mmapmodule.c, all about signed/unsigned > > mismatches: > > [Mark Hammond] > > Me too :-) > > > > I nearly [fixed them], but then couldnt find the time to chase up how > > Unix declared the relevant items - I didnt want to assume they were > > identical to Windows. > > They all involve mixing ints with mmap_object.size in comparisons, which > latter is declared size_t and so will resolve to *some* unsigned integral > type on all platforms. The proper fix is to get rid of the ints before > making these tests -- ask Trent, he should be able to do this in his sleep > now . > I wish I could do it in my sleep, then I would be much more well rested. Yes I will clean these up. I was going to look at mmap a little anyway as test_mmap currently fails on Win32 (probably as a resul of my mmpa patch). Trent -- Trent Mick trentm at activestate.com From DavidA at ActiveState.com Wed Jun 21 19:25:07 2000 From: DavidA at ActiveState.com (David Ascher) Date: Wed, 21 Jun 2000 10:25:07 -0700 Subject: [Python-Dev] CVS and SSH under windows. In-Reply-To: Message-ID: > First, get the latest WinCVS. http://www.wincvs.org/download.html > I use the standard SSH Version 1.2.14 binary set. I cant recall the URL, There's a version at: ftp://ftp.cs.hut.fi/pub/ssh/contrib/ssh-1.2.14-win32bin.zip BUT... > You then need to make a ?key? file - I cant recall the exact process, but > it is pretty simple. This is creating the identify file you specify to > WinCVS, as well as the public key you upload to source-force. C:\WinCVS>ssh-keygen I always get a 'gethostname: no such file or directory' so I had to create the key on Linux (as is mentioned in the page http://bmrc.berkeley.edu/people/chaffee/winntutil.html). Maybe you have a better binary for ssh? > NOTE - from memory, you MUST have a HOME env var set, and you MUST have a > ?.ssh? directory under your home. Otherwise you get cryptic errors from > SSH that give no clue that this is the problem. > > After uploading the public key to source forge, you are nearly set. How do you do that? > The > last step is convinving CVS that you want to use this new SSH setting, and > not the setting CVS so kindly persists in its ?CVS\Root? files. The only > way I found to do this was to either edit the Root files manually, or > remove the directories locally and force CVS to re-create them > (and thereby > re-pull everything - I assume you have ADSL in that hotel room :-) > Alternatively, dig up that CVS script posted to py-dev recently and change > it - personally, I never trusted it :-) > > All my root files look like: > :ext:mhammond at cvs.python.sourceforge.net:/cvsroot/python > > Yours almost certainly will be setup for anon access, not using ssh. > > Hope that makes sense. Im happy to chase anything else up I can > for you... > > Mark. > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev > From akuchlin at cnri.reston.va.us Wed Jun 21 22:27:31 2000 From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling) Date: Wed, 21 Jun 2000 16:27:31 -0400 Subject: [Python-Dev] Patch management (was: Warnings in pythonrun.c) In-Reply-To: <14673.158.183876.75480@localhost.localdomain>; from jeremy@beopen.com on Wed, Jun 21, 2000 at 01:51:26PM -0400 References: <008c01bfdb58$103e8140$f2a6b5d4@hagrid> <14673.158.183876.75480@localhost.localdomain> Message-ID: <20000621162731.B3918@amarok.cnri.reston.va.us> On Wed, Jun 21, 2000 at 01:51:26PM -0400, Jeremy Hylton wrote: >>>>>> "TP" == Tim Peters writes: > TP> + This mailing list doesn't work. At least the SourceForge >I agree that it's a complete mess, though. While you're all admiring the difficulty of the problem, how about actually checking in the pythonrun.c patch, assuming it's reasonable? Frankly, I don't think the current mailing list is broken, *as long as patches are handled with reasonable speed* so that the backlog doesn't build up. That hasn't been done, and I don't understand why. Obviously the CNRI->BeOpen transaction resulted in some downtime for everyone, but now it's a month later and there's still stagnation. Why aren't incoming patches being handled now? It's not like there are very many patches per day; an hour or two should suffice to keep the queue from growing. At this point, the best fix is to do two things: 1) Someone downloads the mbox archives of the patches list, and goes through all the past patches: apply them, discard them, send them back for revision. 2) Commit to handling new patches that arrive, and either apply/discard/revise them. Worrying about patch management mechanism, while more patches pile up and are ignored in the meantime, is not going to help and will just results in continued stagnation. -- A.M. Kuchling http://starship.python.net/crew/amk/ I couldn't think of one clever way to stop this guy, so I just trusted to mindless violence. -- Cliff Steele in DOOM PATROL #21 From akuchlin at cnri.reston.va.us Wed Jun 21 22:27:31 2000 From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling) Date: Wed, 21 Jun 2000 16:27:31 -0400 Subject: [Python-Dev] Patch management (was: Warnings in pythonrun.c) In-Reply-To: <14673.158.183876.75480@localhost.localdomain>; from jeremy@beopen.com on Wed, Jun 21, 2000 at 01:51:26PM -0400 References: <008c01bfdb58$103e8140$f2a6b5d4@hagrid> <14673.158.183876.75480@localhost.localdomain> Message-ID: <20000621162731.B3918@amarok.cnri.reston.va.us> On Wed, Jun 21, 2000 at 01:51:26PM -0400, Jeremy Hylton wrote: >>>>>> "TP" == Tim Peters writes: > TP> + This mailing list doesn't work. At least the SourceForge >I agree that it's a complete mess, though. While you're all admiring the difficulty of the problem, how about actually checking in the pythonrun.c patch, assuming it's reasonable? Frankly, I don't think the current mailing list is broken, *as long as patches are handled with reasonable speed* so that the backlog doesn't build up. That hasn't been done, and I don't understand why. Obviously the CNRI->BeOpen transaction resulted in some downtime for everyone, but now it's a month later and there's still stagnation. Why aren't incoming patches being handled now? It's not like there are very many patches per day; an hour or two should suffice to keep the queue from growing. At this point, the best fix is to do two things: 1) Someone downloads the mbox archives of the patches list, and goes through all the past patches: apply them, discard them, send them back for revision. 2) Commit to handling new patches that arrive, and either apply/discard/revise them. Worrying about patch management mechanism, while more patches pile up and are ignored in the meantime, is not going to help and will just results in continued stagnation. -- A.M. Kuchling http://starship.python.net/crew/amk/ I couldn't think of one clever way to stop this guy, so I just trusted to mindless violence. -- Cliff Steele in DOOM PATROL #21 From akuchlin at cnri.reston.va.us Wed Jun 21 22:27:31 2000 From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling) Date: Wed, 21 Jun 2000 16:27:31 -0400 Subject: [Python-Dev] Patch management (was: Warnings in pythonrun.c) In-Reply-To: <14673.158.183876.75480@localhost.localdomain>; from jeremy@beopen.com on Wed, Jun 21, 2000 at 01:51:26PM -0400 References: <008c01bfdb58$103e8140$f2a6b5d4@hagrid> <14673.158.183876.75480@localhost.localdomain> Message-ID: <20000621162731.B3918@amarok.cnri.reston.va.us> On Wed, Jun 21, 2000 at 01:51:26PM -0400, Jeremy Hylton wrote: >>>>>> "TP" == Tim Peters writes: > TP> + This mailing list doesn't work. At least the SourceForge >I agree that it's a complete mess, though. While you're all admiring the difficulty of the problem, how about actually checking in the pythonrun.c patch, assuming it's reasonable? Frankly, I don't think the current mailing list is broken, *as long as patches are handled with reasonable speed* so that the backlog doesn't build up. That hasn't been done, and I don't understand why. Obviously the CNRI->BeOpen transaction resulted in some downtime for everyone, but now it's a month later and there's still stagnation. Why aren't incoming patches being handled now? It's not like there are very many patches per day; an hour or two should suffice to keep the queue from growing. At this point, the best fix is to do two things: 1) Someone downloads the mbox archives of the patches list, and goes through all the past patches: apply them, discard them, send them back for revision. 2) Commit to handling new patches that arrive, and either apply/discard/revise them. Worrying about patch management mechanism, while more patches pile up and are ignored in the meantime, is not going to help and will just results in continued stagnation. -- A.M. Kuchling http://starship.python.net/crew/amk/ I couldn't think of one clever way to stop this guy, so I just trusted to mindless violence. -- Cliff Steele in DOOM PATROL #21 From guido at python.org Thu Jun 22 00:55:22 2000 From: guido at python.org (Guido van Rossum) Date: Wed, 21 Jun 2000 17:55:22 -0500 Subject: [Python-Dev] updated exit.py and supporting files for your perusal In-Reply-To: Your message of "Wed, 21 Jun 2000 13:15:19 EST." <14673.1591.506532.170015@beluga.mojam.com> References: <14673.1591.506532.170015@beluga.mojam.com> Message-ID: <200006212255.RAA02444@cj20424-a.reston1.va.home.com> If I had designed this, I might have called the module "onexit" or "atexit" and the public function simply "register()". But I've got only a +0 for my own proposal. A +1 for the general idea. --Guido van Rossum (home page: http://www.python.org/~guido/) From paul at prescod.net Thu Jun 22 00:13:39 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 21 Jun 2000 17:13:39 -0500 Subject: [Python-Dev] list comprehensions References: Message-ID: <39513E13.F8082811@prescod.net> Tim Peters wrote: > > ... > Nobody has been more vocal in support of these (& augmented assignments) > than me, but I very strongly doubt they'll be in 1.6. In the interests of > getting that out the door, Guido considers the 1.6 feature set to be frozen > already. Is there an argument for putting in features with flaming red neon lights: "warning, experimental, use at your risk." We want to follow a bazaar (if not outright bizarre) development strategy after all. Putting a patch "out there" really doesn't do much about having people really play with and comment on a feature. I would never have experimented (and decided against using...) metaclasses if they hadn't popped up as an experimental feature. Of course if there is a decent chance of breaking something already in there that works then that's another issue... > I think part of the pressure to get one more feature in Python (again & > again & again) is that release cycles have been soooooo protracted, now > slobbering well over the full year mark. Nah, no matter how quick you do the turnarounds, nobody wants to wait for their favorite feature. :) -- Paul Prescod - ISOGEN Consulting Engineer speaking for himself Floggings will continue until morale improves. From DavidA at ActiveState.com Wed Jun 21 19:25:07 2000 From: DavidA at ActiveState.com (David Ascher) Date: Wed, 21 Jun 2000 10:25:07 -0700 Subject: [Python-Dev] CVS and SSH under windows. In-Reply-To: Message-ID: > First, get the latest WinCVS. http://www.wincvs.org/download.html > I use the standard SSH Version 1.2.14 binary set. I cant recall the URL, There's a version at: ftp://ftp.cs.hut.fi/pub/ssh/contrib/ssh-1.2.14-win32bin.zip BUT... > You then need to make a ?key? file - I cant recall the exact process, but > it is pretty simple. This is creating the identify file you specify to > WinCVS, as well as the public key you upload to source-force. C:\WinCVS>ssh-keygen I always get a 'gethostname: no such file or directory' so I had to create the key on Linux (as is mentioned in the page http://bmrc.berkeley.edu/people/chaffee/winntutil.html). Maybe you have a better binary for ssh? > NOTE - from memory, you MUST have a HOME env var set, and you MUST have a > ?.ssh? directory under your home. Otherwise you get cryptic errors from > SSH that give no clue that this is the problem. > > After uploading the public key to source forge, you are nearly set. How do you do that? > The > last step is convinving CVS that you want to use this new SSH setting, and > not the setting CVS so kindly persists in its ?CVS\Root? files. The only > way I found to do this was to either edit the Root files manually, or > remove the directories locally and force CVS to re-create them > (and thereby > re-pull everything - I assume you have ADSL in that hotel room :-) > Alternatively, dig up that CVS script posted to py-dev recently and change > it - personally, I never trusted it :-) > > All my root files look like: > :ext:mhammond at cvs.python.sourceforge.net:/cvsroot/python > > Yours almost certainly will be setup for anon access, not using ssh. > > Hope that makes sense. Im happy to chase anything else up I can > for you... > > Mark. > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev > From nascheme at enme.ucalgary.ca Thu Jun 22 02:25:46 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Wed, 21 Jun 2000 18:25:46 -0600 Subject: [Python-Dev] updated exit.py and supporting files for your perusal In-Reply-To: <14673.1591.506532.170015@beluga.mojam.com>; from skip@mojam.com on Wed, Jun 21, 2000 at 01:15:19PM -0500 References: <14673.1591.506532.170015@beluga.mojam.com> Message-ID: <20000621182546.B25879@acs.ucalgary.ca> On Wed, Jun 21, 2000 at 01:15:19PM -0500, Skip Montanaro wrote: > Also, can someone tell me how to coax CVS into creating a > unified diff that actually contains new files? I tried > > cvs diff -RNau > > without success. Did you "cvs add" them? Neil -- "Simplicity does not precede complexity, but follows it." -- Alan Perlis From skip at mojam.com Thu Jun 22 02:39:03 2000 From: skip at mojam.com (Skip Montanaro) Date: Wed, 21 Jun 2000 19:39:03 -0500 (CDT) Subject: [Python-Dev] updated exit.py and supporting files for your perusal In-Reply-To: <20000621182546.B25879@acs.ucalgary.ca> References: <14673.1591.506532.170015@beluga.mojam.com> <20000621182546.B25879@acs.ucalgary.ca> Message-ID: <14673.24615.291912.261214@beluga.mojam.com> >> Also, can someone tell me how to coax CVS into creating a unified >> diff that actually contains new files? I tried >> >> cvs diff -RNau >> >> without success. Neil> Did you "cvs add" them? Not something I could do, since I'm cvs'ing against the sourceforge repository. The best I guess I can do is to mirror the repository twice, add the new files to one tree, then perform a regular diff... Skip From esr at thyrsus.com Thu Jun 22 04:09:35 2000 From: esr at thyrsus.com (esr at thyrsus.com) Date: Wed, 21 Jun 2000 22:09:35 -0400 Subject: [Python-Dev] list comprehensions In-Reply-To: References: <20000620132150.O8678@thyrsus.com> Message-ID: <20000621220934.A1044@thyrsus.com> Tim Peters : > Nobody has been more vocal in support of these (& augmented assignments) > than me, but I very strongly doubt they'll be in 1.6. In the interests of > getting that out the door, Guido considers the 1.6 feature set to be frozen > already. > > I think part of the pressure to get one more feature in Python (again & > again & again) is that release cycles have been soooooo protracted, now > slobbering well over the full year mark. If I accomplish nothing else at > BeOpen, I want to give that a major speed boost -- I don't think we should > ever let 6 months go by without at least pumping out a bugfix release. OK, I can buy this. Are there concrete plans (as in, a specified timeframe) for a release in which new features will be admitted? -- Eric S. Raymond What, then is law [government]? It is the collective organization of the individual right to lawful defense." -- Frederic Bastiat, "The Law" From mal at lemburg.com Thu Jun 22 11:05:09 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 22 Jun 2000 11:05:09 +0200 Subject: [Python-Dev] updated exit.py and supporting files for your perusal References: <14673.1591.506532.170015@beluga.mojam.com> Message-ID: <3951D6C5.BA31276B@lemburg.com> > This message contains four attached files: > > Lib/exit.py - a module that allows users to register cleanup functions > Lib/test/test_exit.py - a simple test script > Lib/test/output/test_exit - expected test output > Doc/lib/libexit.tex - library reference manual section > > Besides adding documentation and a test script, the following two mods were > made to exit.py since I previously posted it: > > 1. It implements a LIFO execution order > 2. If sys.exitfunc is already defined and not exit._run_exitfuncs, it is > treated as an exit function and appended to the exit function list. > > Comments, please. Looks ok to me, but since this is going to be a new standard module I guess we should wait for Guido's ok before checking it in. > Also, can someone tell me how to coax CVS into creating a > unified diff that actually contains new files? I tried > > cvs diff -RNau > > without success. I'm not an CVS expert, but I could imagine that you'll have to add the files to CVS first and then run the above diff. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gstein at lyra.org Thu Jun 22 15:30:53 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 22 Jun 2000 06:30:53 -0700 Subject: [Python-Dev] CVS and SSH under windows. In-Reply-To: ; from DavidA@ActiveState.com on Wed, Jun 21, 2000 at 10:25:07AM -0700 References: Message-ID: <20000622063053.M29590@lyra.org> On Wed, Jun 21, 2000 at 10:25:07AM -0700, David Ascher wrote: >... > > You then need to make a ?key? file - I cant recall the exact process, but > > it is pretty simple. This is creating the identify file you specify to > > WinCVS, as well as the public key you upload to source-force. > > C:\WinCVS>ssh-keygen > > I always get a 'gethostname: no such file or directory' so I had to create > the key on Linux (as is mentioned in the page > http://bmrc.berkeley.edu/people/chaffee/winntutil.html). > > Maybe you have a better binary for ssh? Nah. Mark just forgets that I generated the key for him from my Linux box :-) hehe... Cheers, -g -- Greg Stein, http://www.lyra.org/ From tim_one at email.msn.com Thu Jun 22 15:46:15 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 22 Jun 2000 09:46:15 -0400 Subject: [Python-Dev] SourceForge vs Windows In-Reply-To: Message-ID: I have to get SourceForge developer access working with Windows (Win98SE, specifically), so I'll write up detailed instructions along the way, building on Mark Hammond's good clues. Play along! I'll accumulate everyone's input & make a coherent how-to out of it. Today's installment only covers the first step, as it took 12 hours for meto complete it (rotten connectivity today, via 56K modem, requiring many attempts at downloading before one succeeded): [Mark Hammond] > First, get the latest WinCVS. Has some nice new features. Mine shows > as 1.1b13. It has a slightly ?slicker? more windowsy look than the > older one. What we really want is the version with the Options/Preferences > dialog that allows you to supply the ?RAS identity? file when you select > ?SSH Server? as the auth method. Previous versions allow you to select > the SSH Server, but give you nowhere to put the identity file. Hence > previous versions used a batch file wrapper, which you probably saw > reference to. This version makes it much simpler. I picked up the 1.1b14 version, released 19 Jun 2000, from http://www.wincvs.org/download.html It's a 3.21 Mb zip file. hard-to-blow-it-so-far-ly y'rs - tim From tim_one at email.msn.com Thu Jun 22 15:46:17 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 22 Jun 2000 09:46:17 -0400 Subject: [Python-Dev] list comprehensions In-Reply-To: <20000621220934.A1044@thyrsus.com> Message-ID: [Tim, sez the 1.6 feature set should be considered frozen, and that Python should move to a much less sloth-like release schedule thereafter] [esr at thyrsus.com] > OK, I can buy this. Comes with a 30-day warranty, too . > Are there concrete plans (as in, a specified timeframe) > for a release in which new features will be admitted? There damn well ought to be. PythonLabs will be having its first all-hands meeting tomorrow (Guido's been gone, I've been in this state less than a week, & I'm still not sure Jeremy Hylton exists), and rational, timely release schedules are certainly on my agenda. I have no problem with new features in minor releases either, provided they're 100% backward-compatible (e.g., list comprehensions, yes (so long as they don't introduce new bytecodes); having str(long) strip the trailing "L", no). More when we know more. and-less-when-we-know-less-ly y'rs - tim From nascheme at enme.ucalgary.ca Thu Jun 22 17:24:16 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Thu, 22 Jun 2000 09:24:16 -0600 Subject: [Python-Dev] updated exit.py and supporting files for your perusal In-Reply-To: <14673.24615.291912.261214@beluga.mojam.com>; from skip@mojam.com on Wed, Jun 21, 2000 at 07:39:03PM -0500 References: <14673.1591.506532.170015@beluga.mojam.com> <20000621182546.B25879@acs.ucalgary.ca> <14673.24615.291912.261214@beluga.mojam.com> Message-ID: <20000622092416.A31223@acs.ucalgary.ca> On Wed, Jun 21, 2000 at 07:39:03PM -0500, Skip Montanaro wrote: > Neil> Did you "cvs add" them? > > Not something I could do, since I'm cvs'ing against the sourceforge > repository. That's okay. "cvs add" only modifies things locally. You have to "cvs commit" to change things in the repository. Neil -- The internet: Learn what you know. Share what you don't. From klm at digicool.com Thu Jun 22 18:13:46 2000 From: klm at digicool.com (Ken Manheimer) Date: Thu, 22 Jun 2000 12:13:46 -0400 (EDT) Subject: [Python-Dev] CVS and SSH under windows. In-Reply-To: <20000622063053.M29590@lyra.org> Message-ID: A bit of a tangent, but MindTerm - http://www.mindbright.se/mindterm - is a pretty nice java SSH client which you can use on windows to generate the RSA identity. (It also is a fine SSH client, with just about all the nicities except compression - scp, x11 forwarding, arbitrary tunneling, etc are all in there...) Ken klm at digicool.com On Thu, 22 Jun 2000, Greg Stein wrote: > On Wed, Jun 21, 2000 at 10:25:07AM -0700, David Ascher wrote: > >... > > > You then need to make a ?key? file - I cant recall the exact process, but > > > it is pretty simple. This is creating the identify file you specify to > > > WinCVS, as well as the public key you upload to source-force. > > > > C:\WinCVS>ssh-keygen > > > > I always get a 'gethostname: no such file or directory' so I had to create > > the key on Linux (as is mentioned in the page > > http://bmrc.berkeley.edu/people/chaffee/winntutil.html). > > > > Maybe you have a better binary for ssh? > > Nah. Mark just forgets that I generated the key for him from my Linux box :-) > > hehe... > > Cheers, > -g > > -- > Greg Stein, http://www.lyra.org/ > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev > From skip at mojam.com Thu Jun 22 19:21:04 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 22 Jun 2000 12:21:04 -0500 (CDT) Subject: [Python-Dev] updated exit.py and supporting files for your perusal In-Reply-To: <200006212255.RAA02444@cj20424-a.reston1.va.home.com> References: <14673.1591.506532.170015@beluga.mojam.com> <200006212255.RAA02444@cj20424-a.reston1.va.home.com> Message-ID: <14674.19200.325533.979792@beluga.mojam.com> Guido> If I had designed this, I might have called the module "onexit" Guido> or "atexit" and the public function simply "register()". But Guido> I've got only a +0 for my own proposal. A +1 for the general Guido> idea. I'm happy to change things. I was a bit curious if people would ask about such a common word for a new module name. What module name do people prefer, "atexit", "onexit" (reads quickly like "one exit" if you're not careful), or something else? Skip From skip at mojam.com Thu Jun 22 19:27:18 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 22 Jun 2000 12:27:18 -0500 (CDT) Subject: [Python-Dev] updated exit.py and supporting files for your perusal In-Reply-To: <20000622092416.A31223@acs.ucalgary.ca> References: <14673.1591.506532.170015@beluga.mojam.com> <20000621182546.B25879@acs.ucalgary.ca> <14673.24615.291912.261214@beluga.mojam.com> <20000622092416.A31223@acs.ucalgary.ca> Message-ID: <14674.19574.609843.392230@beluga.mojam.com> Neil> That's okay. "cvs add" only modifies things locally. You have to Neil> "cvs commit" to change things in the repository. Ah, thanks for the tip. I'll try that next time... Skip From tim_one at email.msn.com Fri Jun 23 03:38:43 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 22 Jun 2000 21:38:43 -0400 Subject: [Python-Dev] RE: [Patches] Patch management (was: Warnings in pythonrun.c) In-Reply-To: <20000621162731.B3918@amarok.cnri.reston.va.us> Message-ID: [Andrew M. Kuchling] > While you're all admiring the difficulty of the problem, how about > actually checking in the pythonrun.c patch, assuming it's reasonable? I can't yet. Be my guest! > > > Frankly, I don't think the current mailing list is broken, *as long as > patches are handled with reasonable speed* so that the backlog doesn't > build up. Andrew, this is saying that if it didn't display all the symptoms of illness, it wouldn't be sick. The consistent (this started long before Guido's honeymoon!) lack of timely action here *is* the brokenness. > That hasn't been done, and I don't understand why. Why didn't you check in the pythonrun.c patch? Multiply by 10 people and 100 patches. There are no mechanisms in a mailing list for assigning, recording or checking responsibility, neither for recording or querying disposition status. Nobody owns any part of the problem now, and it's extraordinarly difficult to determine the status of any particular patch you may be interested in via this mish-mash of archived all-topic email scattered across patches and python-dev. Prior to this mailing list, Guido owned every problem and the database was in his head. I think it's the lack of the "owned" and "database" parts we're suffering from here, not especially the lack of the "Guido" part. SourceForge provides rudimentary mechanisms for both of the former; a Python replacement for Guido is one of BeOpen's highest secret priorities . > ... > Worrying about patch management mechanism, while more patches pile up > and are ignored in the meantime, is not going to help and will just > results in continued stagnation. At an all-hands PythonLabs group mtg today, it was decided to move patch activity to SourceForge and kill the patches list. I'll send more about that later. There is absolutely nothing new stopping checkins while the move to the SourceForge patch manager is in progress, so if the patches continue to pile up it's certainly not the move's fault. If the pythonrun.c patch is still sitting untouched after the move, I'll assign it to you <0.7 wink>. the-only-one-working-on-the-move-is-me-and-i-haven't-done-a-checkin- yet-anyway-ly y'rs - tim From mal at lemburg.com Fri Jun 23 10:03:41 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 23 Jun 2000 10:03:41 +0200 Subject: [Python-Dev] Re: [Patches] Patch management (was: Warnings in pythonrun.c) References: Message-ID: <395319DD.F2584321@lemburg.com> Tim Peters wrote: > > > Worrying about patch management mechanism, while more patches pile up > > and are ignored in the meantime, is not going to help and will just > > results in continued stagnation. > > At an all-hands PythonLabs group mtg today, it was decided to move patch > activity to SourceForge and kill the patches list. I'll send more about > that later. There is absolutely nothing new stopping checkins while the > move to the SourceForge patch manager is in progress, so if the patches > continue to pile up it's certainly not the move's fault. If the pythonrun.c > patch is still sitting untouched after the move, I'll assign it to you <0.7 > wink>. But how are we going to discuss new patches from people outside python-dev then ? I do see the use of moving patch submission to SourceForge, but posting the patches on the list for revision by everyone who listens is certainly better than having to scan the patch manager entries... (push strategies usually produce more feedback than pull ones). A gateway from the patch manager to the patches list would solve this nicely. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Vladimir.Marangozov at inrialpes.fr Fri Jun 23 12:00:23 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Fri, 23 Jun 2000 12:00:23 +0200 (CEST) Subject: [Python-Dev] updated exit.py and supporting files for your perusal In-Reply-To: <14674.19200.325533.979792@beluga.mojam.com> from "Skip Montanaro" at Jun 22, 2000 12:21:04 PM Message-ID: <200006231000.MAA03550@python.inrialpes.fr> Skip Montanaro wrote: > > > Guido> If I had designed this, I might have called the module "onexit" > Guido> or "atexit" and the public function simply "register()". But > Guido> I've got only a +0 for my own proposal. A +1 for the general > Guido> idea. > > I'm happy to change things. I was a bit curious if people would ask about > such a common word for a new module name. What module name do people > prefer, "atexit", "onexit" (reads quickly like "one exit" if you're not > careful), or something else? > > Skip atexit.py -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From mal at lemburg.com Fri Jun 23 12:08:46 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 23 Jun 2000 12:08:46 +0200 Subject: [Python-Dev] updated exit.py and supporting files for your perusal References: <200006231000.MAA03550@python.inrialpes.fr> Message-ID: <3953372E.274907AB@lemburg.com> Vladimir Marangozov wrote: > > Skip Montanaro wrote: > > > > > > Guido> If I had designed this, I might have called the module "onexit" > > Guido> or "atexit" and the public function simply "register()". But > > Guido> I've got only a +0 for my own proposal. A +1 for the general > > Guido> idea. > > > > I'm happy to change things. I was a bit curious if people would ask about > > such a common word for a new module name. What module name do people > > prefer, "atexit", "onexit" (reads quickly like "one exit" if you're not > > careful), or something else? > > > > Skip > > atexit.py How about exitfunc.py ? It would make the relation to sys.exitfunc pretty clear. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From akuchlin at cnri.reston.va.us Fri Jun 23 13:30:02 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Fri, 23 Jun 2000 07:30:02 -0400 Subject: [Python-Dev] Patch management In-Reply-To: <395319DD.F2584321@lemburg.com>; from mal@lemburg.com on Fri, Jun 23, 2000 at 10:03:41AM +0200 References: <395319DD.F2584321@lemburg.com> Message-ID: <20000623073002.B9385@newcnri.cnri.reston.va.us> On Fri, Jun 23, 2000 at 10:03:41AM +0200, M.-A. Lemburg wrote: >A gateway from the patch manager to the patches list would >solve this nicely. According to what was said to me, it's thought that mailing new patches to an e-mail address is supported, and therefore setting up a So, I no longer have much of a problem with moving patches to SF, though I *still* think the mailing list would be sufficient with a bit more focused effort; sorry, Tim! But at least we're not going to burn weeks looking at different patch manager products, and then arguing about them, which is what I feared most. --amk From bwarsaw at python.org Fri Jun 23 16:33:11 2000 From: bwarsaw at python.org (Barry A. Warsaw) Date: Fri, 23 Jun 2000 10:33:11 -0400 (EDT) Subject: [Python-Dev] updated exit.py and supporting files for your perusal References: <14674.19200.325533.979792@beluga.mojam.com> <200006231000.MAA03550@python.inrialpes.fr> Message-ID: <14675.29991.933911.446078@anthem.concentric.net> >>>>> "VM" == Vladimir Marangozov writes: VM> atexit.py +1 From gward at mems-exchange.org Fri Jun 23 17:42:03 2000 From: gward at mems-exchange.org (Greg Ward) Date: Fri, 23 Jun 2000 11:42:03 -0400 Subject: [Python-Dev] RFC: Including PIL in 1.6 In-Reply-To: <20000620140419.C10038@thyrsus.com>; from esr@thyrsus.com on Tue, Jun 20, 2000 at 02:04:19PM -0400 References: <20000609215719.47624E2673@oratrix.oratrix.nl> <20000609181924.A15728@thyrsus.com> <20000620083344.A3499@ludwig.cnri.reston.va.us> <20000620140419.C10038@thyrsus.com> Message-ID: <20000623114202.A1778@ludwig.cnri.reston.va.us> On 20 June 2000, esr at thyrsus.com said: > Watch that argument -- it could turn and bite you. What's the justification > for including, e.g. POP client classes in the standard distribution? > > One of Python's most important strengths is the "batteries *are* > included" richness of the standard environment. I totally agree. There are two extremes, both completely silly: include nothing with Python (except string, re, os, and sys -- because Distutils needs them ;-), and include every useful, working, documented module under the sun. I don't think anyone would seriously argue for either approach. (Although you could argue that a completely stripped-down Python might be useful in certain environments, eg. a hand-held. But I don't think you'd win that argument.) And I will be the first to admit that the Distutils still aren't good enough: in most respects, they're better than MakeMaker (IMHO), but there's nothing like CPAN.pm or the XEmacs package manager. And I know from personal experience that, amazing as CPAN.pm is, it's not The Answer; and others have attested, that XEmacs is pretty damn good but still not perfect. But I still don't think PIL should be included in the core, if only because it's one of the Distutils "test cases". ;-) Greg -- Greg Ward - software developer gward at mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From gward at mems-exchange.org Fri Jun 23 17:45:16 2000 From: gward at mems-exchange.org (Greg Ward) Date: Fri, 23 Jun 2000 11:45:16 -0400 Subject: [Python-Dev] list comprehensions In-Reply-To: <39513E13.F8082811@prescod.net>; from paul@prescod.net on Wed, Jun 21, 2000 at 05:13:39PM -0500 References: <39513E13.F8082811@prescod.net> Message-ID: <20000623114516.B1778@ludwig.cnri.reston.va.us> On 21 June 2000, Paul Prescod said: > Is there an argument for putting in features with flaming red neon > lights: "warning, experimental, use at your risk." We want to follow a > bazaar (if not outright bizarre) development strategy after all. Putting > a patch "out there" really doesn't do much about having people really > play with and comment on a feature. I would never have experimented (and > decided against using...) metaclasses if they hadn't popped up as an > experimental feature. Well, remember there will probably be a "--with-gc" option to the configure script in 1.6. That's a good example of getting an experimental feature out there. However, a "--with-list-comprehensions" option would be a really bad idea; all of a sudden, it's no longer enough to say, "You need Python 1.6" to run this script/use this module, now you need to say, "You need Python 1.6 built with list comprehensions". Ugh. Real language features should not be selectable: either the language is Python 1.6 or it isn't. Greg -- Greg Ward - software developer gward at mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From akuchlin at cnri.reston.va.us Fri Jun 23 17:54:02 2000 From: akuchlin at cnri.reston.va.us (Andrew M. Kuchling) Date: Fri, 23 Jun 2000 11:54:02 -0400 Subject: [Python-Dev] list comprehensions In-Reply-To: <20000623114516.B1778@ludwig.cnri.reston.va.us>; from gward@mems-exchange.org on Fri, Jun 23, 2000 at 11:45:16AM -0400 References: <39513E13.F8082811@prescod.net> <20000623114516.B1778@ludwig.cnri.reston.va.us> Message-ID: <20000623115402.B4805@amarok.cnri.reston.va.us> On Fri, Jun 23, 2000 at 11:45:16AM -0400, Greg Ward wrote: >idea; all of a sudden, it's no longer enough to say, "You need Python >1.6" to run this script/use this module, now you need to say, "You need >Python 1.6 built with list comprehensions". Ugh. The same argument applies to --with-gc, though, since people might write code that creates cycles and needs GC to run without leaking like a sieve. Making GC optional is still the right solution, though, because its performance effects are still unknown and might be costly. --amk From gvwilson at nevex.com Fri Jun 23 18:09:36 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Fri, 23 Jun 2000 12:09:36 -0400 (EDT) Subject: [Python-Dev] Re: list comprehensions / garbage collection / optional features In-Reply-To: <20000623115402.B4805@amarok.cnri.reston.va.us> Message-ID: > >Greg Ward wrote: > >idea; all of a sudden, it's no longer enough to say, "You need Python > >1.6" to run this script/use this module, now you need to say, "You need > >Python 1.6 built with list comprehensions". Ugh. > Andrew Kuchling wrote: > The same argument applies to --with-gc, though, since people might > write code that creates cycles and needs GC to run without leaking > like a sieve. Making GC optional is still the right solution, though, > because its performance effects are still unknown and might be costly. Greg Wilson writes: I'm really looking forward to recycling my rusty SETL idioms when list comprehensions become part of the "official" release, and to creating graphs in the obvious way if GC ever becomes standard. However, the more variations there are in the "standard" (as opposed to "developer") release, the more expensive (in time and sweat) it is to manage Python at large sites (like Los Alamos). This in turn makes it harder to persuade people that using Python will make their lives easier... Thanks, Greg Footnote: The existence of JPython was one of the arguments in favor of choosing Python for the Software Carpentry project. The fact that JPython and CPython have very different memory management behaviors almost negated that point: as one thirty-year veteran said, "It's no use having code that runs in lots of places if it runs differently in each." From nascheme at enme.ucalgary.ca Fri Jun 23 19:12:51 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Fri, 23 Jun 2000 11:12:51 -0600 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Objects classobject.c,2.86,2.87 dictobject.c,2.52,2.53 funcobject.c,2.20,2.21 listobject.c,2.73,2.74 tupleobject.c,2.36,2.37 In-Reply-To: <200006231418.HAA02869@slayer.i.sourceforge.net>; from jhylton@users.sourceforge.net on Fri, Jun 23, 2000 at 07:18:13AM -0700 References: <200006231418.HAA02869@slayer.i.sourceforge.net> Message-ID: <20000623111251.B10850@acs.ucalgary.ca> On Fri, Jun 23, 2000 at 07:18:13AM -0700, Jeremy Hylton wrote: > Round 1 of Neil Schemenauer's GC patches: Yay. :) > + class_traverse(PyClassObject *o, visitproc visit, void *arg) > + { ... > + return 0; > + } > + instance_traverse(PyInstanceObject *o, visitproc visit, void *arg) > + { ... > + return 1; > + } Oops. I think "return 0" is the proper thing to do. There are a few other functions that return 1 as well. Neil From fdrake at acm.org Fri Jun 23 20:08:06 2000 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Fri, 23 Jun 2000 11:08:06 -0700 (PDT) Subject: [Python-Dev] out of touch Message-ID: <14675.42886.423185.310220@mailhost.beopen.com> My laptop has died, so I'm catching up with a couple of days of mail. I've not had time to look at Paul's proposed DOM-like additions to the standard library. Hopefully Andrew can (or has) summarized the relevant portions of our discussion from yesterday; if I don't see it, I'll try to get another message out later. (But I don't have my saved mail or files, so there's still not a lot I can do. ;( ) -Fred -- Fred L. Drake, Jr. From fdrake at beopen.com Fri Jun 23 21:04:55 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 23 Jun 2000 12:04:55 -0700 (PDT) Subject: [Python-Dev] updated exit.py and supporting files for your perusal In-Reply-To: <14674.19200.325533.979792@beluga.mojam.com> References: <14673.1591.506532.170015@beluga.mojam.com> <200006212255.RAA02444@cj20424-a.reston1.va.home.com> <14674.19200.325533.979792@beluga.mojam.com> Message-ID: <14675.46295.836727.117258@mailhost.beopen.com> Skip Montanaro writes: > I'm happy to change things. I was a bit curious if people would ask about > such a common word for a new module name. What module name do people > prefer, "atexit", "onexit" (reads quickly like "one exit" if you're not I like "atexit" better. -Fred -- Fred L. Drake, Jr. From guido at python.org Fri Jun 23 22:08:36 2000 From: guido at python.org (Guido van Rossum) Date: Fri, 23 Jun 2000 15:08:36 -0500 Subject: [Python-Dev] updated exit.py and supporting files for your perusal In-Reply-To: Your message of "Fri, 23 Jun 2000 12:04:55 MST." <14675.46295.836727.117258@mailhost.beopen.com> References: <14673.1591.506532.170015@beluga.mojam.com> <200006212255.RAA02444@cj20424-a.reston1.va.home.com> <14674.19200.325533.979792@beluga.mojam.com> <14675.46295.836727.117258@mailhost.beopen.com> Message-ID: <200006232008.PAA02759@cj20424-a.reston1.va.home.com> > Skip Montanaro writes: > > I'm happy to change things. I was a bit curious if people would ask about > > such a common word for a new module name. What module name do people > > prefer, "atexit", "onexit" (reads quickly like "one exit" if you're not [fred] > I like "atexit" better. OK, let it be atexit. I'm glad this time the naming debate is at least civilized. :-) --Guido van Rossum (home page: http://www.python.org/~guido/) From DavidA at ActiveState.com Fri Jun 23 21:30:31 2000 From: DavidA at ActiveState.com (David Ascher) Date: Fri, 23 Jun 2000 12:30:31 -0700 Subject: [Python-Dev] updated exit.py and supporting files for your perusal In-Reply-To: <200006232008.PAA02759@cj20424-a.reston1.va.home.com> Message-ID: > OK, let it be atexit. I'm glad this time the naming debate is at > least civilized. :-) No, wait, i think it should be exit_AT! Actually, I'm sick of this english-centricity. You american jerks are all the same! Go home Yankee! It should be en_sortant or nothing at all! --david "I try..." ascher From nascheme at enme.ucalgary.ca Fri Jun 23 22:11:03 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Fri, 23 Jun 2000 14:11:03 -0600 Subject: [Python-Dev] Fwd: Re: Linux/NT python startup speed Message-ID: <20000623141103.A13079@acs.ucalgary.ca> Has this been addressed yet for 1.6? It is probably an easy fix. The original poster claimed it took 4 seconds to start Python on his machine. Neil ----- Forwarded message from Johannes Stezenbach ----- Date: Thu, 22 Jun 2000 15:03:01 +0200 From: yawyi at gmx.de (Johannes Stezenbach) Subject: Re: Linux/NT python startup speed Niklas Frykholm wrote: >Can someone explain this difference. (The processor on the Linux system is >certainly not 40 times faster.) This was discussed here a few months ago. The reason for the slow startup is the winsound module (source: PC/winsound.c) which is unnecessarily a builtin. winsound causes Python to load the Windows multimedia DLLs, which can be slow if your sound drivers make it so. Two solutions were discussed: a) make winsound a .pyd b) use some obscure "delayload" feature of the M$ linker. There is a ready to use python15.dll for Python 1.5.2 with this feature somewhere out there (I don't remember where, though, since I use Linux now) IMHO solution a) should be standard in Python 1.6 (it isn't in 1.6a2). Johannes ----- End forwarded message ----- From tim_one at email.msn.com Fri Jun 23 22:11:47 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 23 Jun 2000 16:11:47 -0400 Subject: [Python-Dev] updated exit.py and supporting files for your perusal In-Reply-To: Message-ID: [Guido] >> OK, let it be atexit. I'm glad this time the naming debate is at >> least civilized. :-) {David Ascher] > No, wait, i think it should be exit_AT! > > Actually, I'm sick of this english-centricity. You american jerks are all > the same! Go home Yankee! It should be en_sortant or nothing at all! Oh, screw you and the frog you rode in, Frenchie. Using an inferior language is no excuse for poor grammar: "exit at" reads like a freeway sign, as in "Kentucky Fried Chicken, exit at 12B". en_sortant is no better -- worse, I have no idea what this has to do with arranging ants in order (and what kind of algorithm is en_sort anyway?). uponbutpriortoexiting is an idea that can't even be expressed in French, I bet. internationally y'rs - tim From guido at python.org Fri Jun 23 23:49:05 2000 From: guido at python.org (Guido van Rossum) Date: Fri, 23 Jun 2000 16:49:05 -0500 Subject: [Python-Dev] Fwd: Re: Linux/NT python startup speed In-Reply-To: Your message of "Fri, 23 Jun 2000 14:11:03 CST." <20000623141103.A13079@acs.ucalgary.ca> References: <20000623141103.A13079@acs.ucalgary.ca> Message-ID: <200006232149.QAA03157@cj20424-a.reston1.va.home.com> > Has this been addressed yet for 1.6? It is probably an easy fix. > The original poster claimed it took 4 seconds to start Python on > his machine. In 1.6, winsound is a separate subproject and hence a separately loadable DLL, so it doesn't slow down the main code. Ditto for socket and a few others. --Guido van Rossum (home page: http://www.python.org/~guido/) From jeremy at beopen.com Sat Jun 24 00:01:19 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 23 Jun 2000 18:01:19 -0400 Subject: [Python-Dev] Python 1.6 planning Message-ID: We discussed plans for Python 1.6 at the all-hands PythonLabs staff meeting yesterday. (At this meeting, the PythonLabs staff closed ranks and agreed to say that Tim Peters exists.) I'd like to quickly summarize plans. The target release date for Python 1.6 beta 1 is early July. Any code that is going to be in the beta must be checked in before July 1. Tim Peters pushed us to take care of the patches backlog. Our plan is to close the patches list and move all patch management to Sourceforge. We know the list is broken; we don't know that Sourceforge is broken. There are a bunch of modules and technical issues that must be resolved one way or another. SRE-- /F needs to finish this up. Unanswered question is whether the beta will ship with known bugs. GC-- Neil's garbage collector will be shipped as experimental feature requiring configure option. XML-- Some parts of the XML package will be included in the library under the xmlcore package. SAX and DOM (provided that it is stable enough). Andrew gets to decide, I believe. List comprehensions -- Next release. Despite the love fest at the meeting (everyone seems to want them), there is no way an implementation will be ready or stable enough. httplib-- We will include Greg Stein's new httplib, provided that it supports an old-style HTTPS class. curses-- one return type needs to be implemented (5-tuple). Andrew will finish ASAP. ESR's ascii module will be part of the curses package. imputil-- The imputil module will be dropped in the std library to enable wider distribution, but no changes will be made to the normal import machinery. Unicode shorthand-- Andrew will look at Bill Tutt's code. We intend to add it. Unicode compression-- We need to find out if Christian will be able to provide a compressed database. ldso_aix-- I still don't understand, but I didn't really try; Vladimir must help threads-- They will be on by default if the platform supports. gettext-- Barry will check in his gettext module. atexit.py-- add it Jeremy From nascheme at enme.ucalgary.ca Sat Jun 24 00:22:50 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Fri, 23 Jun 2000 16:22:50 -0600 Subject: [Python-Dev] Python 1.6 planning In-Reply-To: ; from jeremy@beopen.com on Fri, Jun 23, 2000 at 06:01:19PM -0400 References: Message-ID: <20000623162250.A14311@acs.ucalgary.ca> On Fri, Jun 23, 2000 at 06:01:19PM -0400, Jeremy Hylton wrote: > threads-- They will be on by default if the platform supports. Does the Linux thread/fork problem still exist? It would be nice to kill this before 1.6 final. I will test this with the CVS source this weekend. Neil From skip at mojam.com Sat Jun 24 03:09:04 2000 From: skip at mojam.com (Skip Montanaro) Date: Fri, 23 Jun 2000 20:09:04 -0500 Subject: [Python-Dev] test failures... Message-ID: <200006240109.UAA14738@beluga.mojam.com> Using the latest CVS code, I get failures for three tests on my Linux Mandrake 6.1 laptop: test test_exceptions failed -- Writing: 'spam', expected: 'Attr' test test_types crashed -- exceptions.OverflowError : long int too long to convert test test_long failed -- int(long(-sys.maxint-1)) overflowed! Are these known/expected or unknown/unexpected failures? From skip at mojam.com Sat Jun 24 03:27:39 2000 From: skip at mojam.com (Skip Montanaro) Date: Fri, 23 Jun 2000 20:27:39 -0500 (CDT) Subject: [Python-Dev] atexit.py patch Message-ID: <14676.3723.916135.602@beluga.mojam.com> Here's the latest version of my exit module. Per the earlier discussion, the module has been renamed to atexit.py. I also took the suggestion from someone (Guido?) that the registration function be renamed to simply "register". Other than that everything else should be the same. I'm only sending this to python-dev, operating under the assumption that the patches list is about to take a long vacation... -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille O'Neal said: "He's got the rings. I listen to the man with the rings." -------------- next part -------------- A non-text attachment was scrubbed... Name: atexit.diff Type: application/octet-stream Size: 4402 bytes Desc: atexit.py & doc URL: From trentm at activestate.com Sat Jun 24 04:19:23 2000 From: trentm at activestate.com (Trent Mick) Date: Fri, 23 Jun 2000 19:19:23 -0700 Subject: [Python-Dev] test failures... In-Reply-To: <200006240109.UAA14738@beluga.mojam.com> References: <200006240109.UAA14738@beluga.mojam.com> Message-ID: <20000623191923.A25730@activestate.com> On Fri, Jun 23, 2000 at 08:09:04PM -0500, Skip Montanaro wrote: > Using the latest CVS code, I get failures for three tests on my Linux > Mandrake 6.1 laptop: > > test test_exceptions failed -- Writing: 'spam', expected: 'Attr' Don't know about this one. > test test_types crashed -- exceptions.OverflowError : long int too long to convert This is related to some conversion checking that I added a while back, I believe. > test test_long failed -- int(long(-sys.maxint-1)) overflowed! > Same thing. Potentially this *should* overflow and the test should expect that. Don't take my word on this right now, only looked quickly. I will look at it this weekend (hopefully). Skip, I don't get the test failures, although I am a few days behind Python-CVS. Are these very new failures? Could you provide the verbose output from running these tests indepedently? Thanks. Trent -- Trent Mick trentm at activestate.com From tim_one at email.msn.com Sat Jun 24 04:32:46 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 23 Jun 2000 22:32:46 -0400 Subject: [Python-Dev] test failures... In-Reply-To: <200006240109.UAA14738@beluga.mojam.com> Message-ID: [Skip Montanaro] > Using the latest CVS code, I get failures for three tests on my Linux > Mandrake 6.1 laptop: > > test test_exceptions failed -- Writing: 'spam', expected: 'Attr' > test test_types crashed -- exceptions.OverflowError : long int > too long to convert > test test_long failed -- int(long(-sys.maxint-1)) overflowed! > > Are these known/expected or unknown/unexpected failures? First two don't ring a bell, last one has shown up several times & each time traced to an optimization bug, usually in a particular older version of gcc. Recompile with optimization off and see whether that makes all of them go away. If so, try using a recent gcc. From tim_one at email.msn.com Sat Jun 24 04:41:23 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 23 Jun 2000 22:41:23 -0400 Subject: [Python-Dev] test failures... In-Reply-To: <20000623191923.A25730@activestate.com> Message-ID: >> test test_types crashed -- exceptions.OverflowError : long >> int too long to convert > This is related to some conversion checking that I added a while back, I > believe. Possible but doubt it. >> test test_long failed -- int(long(-sys.maxint-1)) overflowed! > Same thing. Potentially this *should* overflow and the test should expect > that. Definitely not on this one: sys.maxint is by defn the largest positive Python int, so on any 2's-comp machine -sys.maxint-1 should be a legit Python int too. This bogus failure has popped up due to compiler optimization bugs under at least two older different compilers, though (gcc being by far the more often reported culprit -- I think the other was one of those HP compilers that seems to generate more bad code than good <0.3 wink>). The first step in test failures like this is to recompile with optimization off. From skip at mojam.com Sat Jun 24 05:45:04 2000 From: skip at mojam.com (Skip Montanaro) Date: Fri, 23 Jun 2000 22:45:04 -0500 (CDT) Subject: [Python-Dev] test failures... In-Reply-To: References: <200006240109.UAA14738@beluga.mojam.com> Message-ID: <14676.11968.263924.752216@beluga.mojam.com> >> test test_exceptions failed -- Writing: 'spam', expected: 'Attr' >> test test_types crashed -- exceptions.OverflowError : long int too long to convert >> test test_long failed -- int(long(-sys.maxint-1)) overflowed! Tim> First two don't ring a bell, last one has shown up several times & Tim> each time traced to an optimization bug, usually in a particular Tim> older version of gcc. Recompile with optimization off and see Tim> whether that makes all of them go away. If so, try using a recent Tim> gcc. Turning off optimization got rid of the test_types and test_long failures. The test_exceptins failure remains. Here's a diff: diff test_exceptions.save test_exceptions 2a3 > spam 3a5 > spam 4a7 > spam 5a9 > spam 6a11 > spam 7a13 > spam 8a15 > spam 10a18 > spam 12a21 > spam 13a23 > spam 14a25 > spam 16a28 > spam 17a30 > spam 19a33 > spam 20a35 > spam 21a37 > spam 22a39 > spam 23a41 > spam I'm not sure what that means, but it seems consistent. ;-) As for the age of my gcc, I think I'm reasonably current (only a bit over a year old): % gcc -v Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/pgcc-2.91.66/specs gcc version pgcc-2.91.66 19990314 (egcs-1.1.2 release) I will try downloading a newer RPM. Skip From ping at lfw.org Sat Jun 24 08:08:42 2000 From: ping at lfw.org (Ka-Ping Yee) Date: Sat, 24 Jun 2000 01:08:42 -0500 (CDT) Subject: [Python-Dev] updated exit.py and supporting files for your perusal In-Reply-To: <200006232008.PAA02759@cj20424-a.reston1.va.home.com> Message-ID: On Fri, 23 Jun 2000, Guido van Rossum wrote: > [fred] > > I like "atexit" better. > > OK, let it be atexit. I'm glad this time the naming debate is at > least civilized. :-) Sorry to confuddle things, but what happened to the idea of sticking it in "sys"? If sys.exitfunc lives there, doesn't sys.atexit(...) also make sense? It can't be very hard to do... -- ?!ng From guido at python.org Sat Jun 24 18:03:07 2000 From: guido at python.org (Guido van Rossum) Date: Sat, 24 Jun 2000 11:03:07 -0500 Subject: [Python-Dev] test failures... In-Reply-To: Your message of "Fri, 23 Jun 2000 20:09:04 EST." <200006240109.UAA14738@beluga.mojam.com> References: <200006240109.UAA14738@beluga.mojam.com> Message-ID: <200006241603.LAA05123@cj20424-a.reston1.va.home.com> > test test_exceptions failed -- Writing: 'spam', expected: 'Attr' There's a "print buf" at the end of the new function test_raise_catch() that causes this. Jeremy added this; either the "print buf" shouldn't be there, or the file Lib/test/output/test_exceptions should be updated. It's up to Jeremy now. --Guido van Rossum (home page: http://www.python.org/~guido/) From skip at mojam.com Sat Jun 24 17:11:18 2000 From: skip at mojam.com (Skip Montanaro) Date: Sat, 24 Jun 2000 10:11:18 -0500 (CDT) Subject: [Python-Dev] updated exit.py and supporting files for your perusal In-Reply-To: References: <200006232008.PAA02759@cj20424-a.reston1.va.home.com> Message-ID: <14676.53142.263320.435588@beluga.mojam.com> Ping> Sorry to confuddle things, but what happened to the idea of Ping> sticking it in "sys"? If sys.exitfunc lives there, doesn't Ping> sys.atexit(...) also make sense? It can't be very hard to do... I like the general idea that stuff implemented in C is just a thin interface layer on top of existing system services and that higher level protocols are implemented in Python where there's no overriding need for them to be written in C. This fits that model, at least to a first approximation. The sys.exitfunc variable functions pretty much like calling the atexit(3) library call (though that's not how sys.exitfunc is implemented), and the atexit module provides a protocol that dictates how that mechanism is used in a cooperative setting. There's almost certainly no performance reason this code should be implemented in C. It's going to be easier to maintain and enhance if written in Python, and won't add size to the interpreter for those programmers who don't use it (or don't use other modules that do). -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille O'Neal said: "He's got the rings. I listen to the man with the rings." From nascheme at enme.ucalgary.ca Sat Jun 24 18:04:18 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Sat, 24 Jun 2000 10:04:18 -0600 Subject: [Python-Dev] test failures... In-Reply-To: ; from tim_one@email.msn.com on Fri, Jun 23, 2000 at 10:41:23PM -0400 References: <20000623191923.A25730@activestate.com> Message-ID: <20000624100418.A20411@acs.ucalgary.ca> On Fri, Jun 23, 2000 at 10:41:23PM -0400, Tim Peters wrote: > The first step in test failures like this is to recompile with > optimization off. Mandrake is known for shipping bad compilers. They used to ship pgcc as the default compiler even though it was know to have a lot of problems. Neil From tim_one at email.msn.com Sat Jun 24 19:27:19 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 24 Jun 2000 13:27:19 -0400 Subject: [Python-Dev] test failures... In-Reply-To: <14676.11968.263924.752216@beluga.mojam.com> Message-ID: [Skip Montanaro] > Turning off optimization got rid of the test_types and test_long failures. > The test_exceptins failure remains. Bingo, and Guido pinned test_exceptions on Jeremy. You can likely get a usable Python by disabling optimization only for longobject.c, if for some reason you need to stick with that compiler. > As for the age of my gcc, I think I'm reasonably current (only a > bit over a year old): > > % gcc -v > Reading specs from > /usr/lib/gcc-lib/i686-pc-linux-gnu/pgcc-2.91.66/specs > gcc version pgcc-2.91.66 19990314 (egcs-1.1.2 release) Well, I haven't had need of following the gcc/egcs soap opera, but I think "a year" (& particularly the last one ) is a lifetime in that saga. "2.95" rings a vague bell, as the only compiler in that line my former employer felt was usable for their development work under Linux. unlike-python-so-far-they've-had-some-bad-releases-ly y'rs - tim From tim_one at email.msn.com Sat Jun 24 19:30:54 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 24 Jun 2000 13:30:54 -0400 Subject: [Python-Dev] atexit.py patch In-Reply-To: <14676.3723.916135.602@beluga.mojam.com> Message-ID: [Skip] > I'm only sending this to python-dev, operating under the > assumption that the patches list is about to take a long vacation... Skip, if you can't put it on SourceForge for some reason (like what?), the patches list is certainly better than python-dev! I've got enough to do trying to disentangle multi-megabytes of patches-list archives that I'm not going to expand my search to other archives (like python-dev) too. From gstein at lyra.org Sat Jun 24 19:39:34 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 24 Jun 2000 10:39:34 -0700 Subject: [Python-Dev] test failures... In-Reply-To: ; from tim_one@email.msn.com on Sat, Jun 24, 2000 at 01:27:19PM -0400 References: <14676.11968.263924.752216@beluga.mojam.com> Message-ID: <20000624103934.Y29590@lyra.org> On Sat, Jun 24, 2000 at 01:27:19PM -0400, Tim Peters wrote: > [Skip Montanaro] > > Turning off optimization got rid of the test_types and test_long failures. > > The test_exceptins failure remains. > > Bingo, and Guido pinned test_exceptions on Jeremy. You can likely get a > usable Python by disabling optimization only for longobject.c, if for some > reason you need to stick with that compiler. Euh... shouldn't we insert some defensive code into longobject.c? Great, Skip knows to disable opt for that file... what about all the other people? Cheers, -g -- Greg Stein, http://www.lyra.org/ From tim_one at email.msn.com Sat Jun 24 19:42:29 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 24 Jun 2000 13:42:29 -0400 Subject: [Python-Dev] Patch management In-Reply-To: <20000623073002.B9385@newcnri.cnri.reston.va.us> Message-ID: [Andrew Kuchling] > ... > So, I no longer have much of a problem with moving patches to SF, > though I *still* think the mailing list would be sufficient with a bit > more focused effort; sorry, Tim! "Do something" to supply that focus on this mailing list, and then I can stop bothering with the move. That would be great. But repeating that if the list worked, it wouldn't be broken <0.7 wink>, has not proven sufficient to fix it. > But at least we're not going to burn weeks looking at different patch > manager products, and then arguing about them, which is what I feared > most. Same here. well-actually-the-radio-on-the-drive-down-to-va-got-me-more-worried- about-lyme-disease-ly y'rs - tim From tim_one at email.msn.com Sat Jun 24 19:51:14 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sat, 24 Jun 2000 13:51:14 -0400 Subject: [Python-Dev] test failures... In-Reply-To: <20000624103934.Y29590@lyra.org> Message-ID: [Greg Stein] > Euh... shouldn't we insert some defensive code into longobject.c? Great, > Skip knows to disable opt for that file... what about all the > other people? Don't understand what you want to see. The compiler in question is both broken & old. At most I'd put a note in one of the readmes saying so. From fdrake at beopen.com Sat Jun 24 23:19:50 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Sat, 24 Jun 2000 14:19:50 -0700 (PDT) Subject: [Python-Dev] updated exit.py and supporting files for your perusal In-Reply-To: References: <200006232008.PAA02759@cj20424-a.reston1.va.home.com> Message-ID: <14677.9718.880695.265962@mailhost.beopen.com> Ka-Ping Yee writes: > Sorry to confuddle things, but what happened to the idea of > sticking it in "sys"? If sys.exitfunc lives there, doesn't > sys.atexit(...) also make sense? It can't be very hard to do... I'd be happy with this as well, but I don't think it's required to do it that way. -Fred -- Fred L. Drake, Jr. From gstein at lyra.org Sun Jun 25 00:18:24 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 24 Jun 2000 15:18:24 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils util.py,1.36,1.37 In-Reply-To: <200006242040.NAA28315@slayer.i.sourceforge.net>; from gward@users.sourceforge.net on Sat, Jun 24, 2000 at 01:40:05PM -0700 References: <200006242040.NAA28315@slayer.i.sourceforge.net> Message-ID: <20000624151824.A29590@lyra.org> Would the "shlex" module be helpful here? It is in the standard library and is (well?) maintained by ESR. It could help reduce the code inside distutils. [ I've always questioned the need for distutils' own "copy file" functions and whatnot... seems there is a bit of duplication occurring... ] Cheers, -g On Sat, Jun 24, 2000 at 01:40:05PM -0700, Greg Ward wrote: > Update of /cvsroot/python/distutils/distutils > In directory slayer.i.sourceforge.net:/tmp/cvs-serv28287 > > Modified Files: > util.py > Log Message: > Added 'split_quoted()' function to deal with strings that are quoted in > Unix shell-like syntax (eg. in Python's Makefile, for one thing -- now that > I have this function, I'll probably allow quoted strings in config files too. > > Index: util.py > =================================================================== > RCS file: /cvsroot/python/distutils/distutils/util.py,v > retrieving revision 1.36 > retrieving revision 1.37 > diff -C2 -r1.36 -r1.37 > *** util.py 2000/06/18 15:45:55 1.36 > --- util.py 2000/06/24 20:40:02 1.37 > *************** > *** 167,168 **** > --- 167,235 ---- > > return error > + > + > + # Needed by 'split_quoted()' > + _wordchars_re = re.compile(r'[^\\\'\"\ ]*') > + _squote_re = re.compile(r"'(?:[^'\\]|\\.)*'") > + _dquote_re = re.compile(r'"(?:[^"\\]|\\.)*"') > + > + def split_quoted (s): > + """Split a string up according to Unix shell-like rules for quotes and > + backslashes. In short: words are delimited by spaces, as long as those > + spaces are not escaped by a backslash, or inside a quoted string. > + Single and double quotes are equivalent, and the quote characters can > + be backslash-escaped. The backslash is stripped from any two-character > + escape sequence, leaving only the escaped character. The quote > + characters are stripped from any quoted string. Returns a list of > + words. > + """ > + > + # This is a nice algorithm for splitting up a single string, since it > + # doesn't require character-by-character examination. It was a little > + # bit of a brain-bender to get it working right, though... > + > + s = string.strip(s) > + words = [] > + pos = 0 > + > + while s: > + m = _wordchars_re.match(s, pos) > + end = m.end() > + if end == len(s): > + words.append(s[:end]) > + break > + > + if s[end] == ' ': # unescaped, unquoted space: now > + words.append(s[:end]) # we definitely have a word delimiter > + s = string.lstrip(s[end:]) > + pos = 0 > + > + elif s[end] == '\\': # preserve whatever is being escaped; > + # will become part of the current word > + s = s[:end] + s[end+1:] > + pos = end+1 > + > + else: > + if s[end] == "'": # slurp singly-quoted string > + m = _squote_re.match(s, end) > + elif s[end] == '"': # slurp doubly-quoted string > + m = _dquote_re.match(s, end) > + else: > + raise RuntimeError, \ > + "this can't happen (bad char '%c')" % s[end] > + > + if m is None: > + raise ValueError, \ > + "bad string (mismatched %s quotes?)" % s[end] > + > + (beg, end) = m.span() > + s = s[:beg] + s[beg+1:end-1] + s[end:] > + pos = m.end() - 2 > + > + if pos >= len(s): > + words.append(s) > + break > + > + return words > + > + # split_quoted () > > > _______________________________________________ > Python-checkins mailing list > Python-checkins at python.org > http://www.python.org/mailman/listinfo/python-checkins -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Sun Jun 25 00:50:23 2000 From: gstein at lyra.org (Greg Stein) Date: Sat, 24 Jun 2000 15:50:23 -0700 Subject: [Python-Dev] test failures... In-Reply-To: ; from tim_one@email.msn.com on Sat, Jun 24, 2000 at 01:51:14PM -0400 References: <20000624103934.Y29590@lyra.org> Message-ID: <20000624155023.B29590@lyra.org> On Sat, Jun 24, 2000 at 01:51:14PM -0400, Tim Peters wrote: > [Greg Stein] > > Euh... shouldn't we insert some defensive code into longobject.c? Great, > > Skip knows to disable opt for that file... what about all the > > other people? > > Don't understand what you want to see. The compiler in question is both > broken & old. At most I'd put a note in one of the readmes saying so. The compiler Skip quoted was pgcc-2.91.66. The "pgcc" part may have introduced the problem, but my RedHat 6.2 (i.e. the LATEST) has the following: Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) Maybe 2.91.66 is "old" but that is the compiler being shipped on RedHat 6.2. Having said that, I bet the pgcc people messed up the compiler :-). I set -O9 on my box and recompiled longobject.c. It wouldn't reproduce the problem. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gmcm at hypernet.com Sun Jun 25 01:01:05 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Sat, 24 Jun 2000 19:01:05 -0400 Subject: [Python-Dev] test failures... In-Reply-To: References: <14676.11968.263924.752216@beluga.mojam.com> Message-ID: <1250234786-20097552@hypernet.com> Tim "The Windows Guy" Peters wrote: > [Skip Montanaro] > > /usr/lib/gcc-lib/i686-pc-linux-gnu/pgcc-2.91.66/specs > > gcc version pgcc-2.91.66 19990314 (egcs-1.1.2 release) > > Well, I haven't had need of following the gcc/egcs soap opera, > but I think "a year" (& particularly the last one ) is a > lifetime in that saga. gcc 2.90 (egcs 1.0.3) that came with RH 5.2 was broken - but got fixed by rebuilding it from source. - Gordon From gstein at lyra.org Sun Jun 25 10:40:23 2000 From: gstein at lyra.org (Greg Stein) Date: Sun, 25 Jun 2000 01:40:23 -0700 Subject: [Python-Dev] [rasmus@apache.org: Re: PMCs and Apache] Message-ID: <20000625014023.D29590@lyra.org> Woah... this is an interesting factoid about the number of committers for a project. I had no idea PHP had this many... Can this work with Python? Dunno. I think if a "true core" group pays attention to the -checkins alias, then yah. If that review is ever lost, then those "edge" committers could introduce crap. I'm not asking for more committers to Python. But if some people were worried about the "explosion" of committers from about six a couple months ago to the current 13, then just look to PHP and count your thanks :-) Mostly, this email is for pondering... Cheers, -g ----- Forwarded message from Rasmus Lerdorf ----- Reply-To: members at apache.org Date: Sat, 24 Jun 2000 20:52:01 -0700 (PDT) From: Rasmus Lerdorf To: members at apache.org Subject: Re: PMCs and Apache > More relevant is the process by which I became a contributor. For PHP, I > sent a note describing what I was exploring, and I was sent a note with a > password. I didn't know CVS. I didn't know PHP. I didn't know open > source. But like a stranger offering to help at a barn raising, I was > simply handed a hammer and expected to get busy. That has always been the atmosphere. It isn't quite as free as that. We get 10-20 cvs write account requests every week and tend to only hand out 1 or 2 actual accounts. There are a lot of clueless people out there. However, if the person has shown any sign of being competent by explaining in a rational manner what they plan on working on, I see no reason not to let them bash away. Reversing somebodys' changes and removing a cvs account is trivial, and in the past 5 years we have yet to revoke an account. We have reversed changes of course, but even that doesn't happen too often. There are currently 165 people with write access to the PHP source tree. This does also relate to the fact that the PHP project is a very broad project. No single person could possibly know all 16 supported low-level database apis, for example. For other projects with a much more limited scope, this approach is probably not optimal, but for PHP it works nicely. Someone will write a bit of broken code that shows some good ideas, and others will pounce on it and fix it. Often the people who fix it are poor sods who tried to use the broken feature and had to dive in and fix it themselves. They request a cvs account to do this, and they are hooked. They tend to never stop at fixing just one thing once they have been given the golden keys. This approach has also done wonders for the PHP documentation. The current manual is around 1100 pages long and has been fully translated to German, Italian and Japanese with more languages on the way. (check out http://snaps.php.net/manual/) -Rasmus ----- End forwarded message ----- -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Mon Jun 26 01:20:43 2000 From: gstein at lyra.org (Greg Stein) Date: Sun, 25 Jun 2000 16:20:43 -0700 Subject: [Python-Dev] Python/Apache stuff (was: Re: [XML-SIG] speed question re DOM parsing) In-Reply-To: <200006251540.JAA13556@localhost.localdomain>; from uogbuji@fourthought.com on Sun, Jun 25, 2000 at 09:40:59AM -0600 References: <200006251540.JAA13556@localhost.localdomain> Message-ID: <20000625162043.J29590@lyra.org> On Sun, Jun 25, 2000 at 09:40:59AM -0600, Uche Ogbuji wrote: > Greg Stein: > > When could I get to it? eek. I *will*, but dunno when. It is amazing just > > how much stuff can fall on a person's plate despite having no job :-). I've > > got some layered I/O in Apache, mod_dav integration, a new httplib, imputil > > issues, these qp_xml upgrades, ViewCVS stuff, edna releases, free threading > > changes, Python/Apache integration, and coding for Subversion. Fuggin > > frightening. > > Ooh! Ooh! Can you tell us more about the Python/Apache integration item? > We've been discussing distributing a 4Suite kit bundled with PyApache, but > that package is quite complex and I'm not sure how strongly maintained. Are > you talking about improvements to PyApache? Another approach entirely > (PyApache still has much more overhead than, say mod_perl)? Do you have an > approximate time-line? A project URL? There are several Python/Apache efforts (where Python is embedded into the Apache process): *) PyApache: essentially this is just a CGI accelerator. Take a standard CGI script and it will "run faster." (URL? dunno) *) mod_python: similar to mod_perl. Built for Apache 1.3. Despite its version 2.4, it is still a bit rough. I've been working with the author to improve the code. I did a code review a while back with a lot of suggestions. It is reasonable, but not as mature as mod_perl. http://www.modpython.org/ *) mod_snake: obvious misnomer :-). This is a module built for Apache 2.0, with the intent of making use of Apache 2.0's threadedness (plus a few of A2's other internal features). The code is very good looking. - available at SourceForge *) mod_slimpy: my name for an Apache 2.0 module which will be even lighter weight than mod_snake. There will be only the slimmest layer of C code to interface Apache and Python. Most/all operational logic will be deferred to the Python side. I've used this design to good effect in some of the Python/COM work and its univgw package in particular. Obviously, the latter two will compete, but oh well :-). The first two fit their problem environment without particular complications. When I start the mod_slimpy work, I'm also going to push on setting up python.apache.org. Essentially, it will host (under the ASF umbrella) the mod_slimpy work plus any other efforts that may want to operate there. I'm going to ask the authors of the other packages whether they would like to be hosted there, too. Of course, python.apache.org can host any Python project. It doesn't have to be related to the web server, or any other ASF project for that matter. Consider all the non-web stuff that operates under xml.apache.org, java.apache.org, and jakarta.apache.org. Cheers, -g -- Greg Stein, http://www.lyra.org/ From Vladimir.Marangozov at inrialpes.fr Mon Jun 26 13:33:56 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Mon, 26 Jun 2000 13:33:56 +0200 (CEST) Subject: [Python-Dev] Fw: Access violation when no memory In-Reply-To: from "Mark Hammond" at Jun 20, 2000 09:42:53 PM Message-ID: <200006261133.NAA03073@python.inrialpes.fr> Mark Hammond wrote: > > >From the newsgroup. Any thoughts? > > Mark. > > "Phil Mayes" wrote in message > news:... > > The following program progressively allocates all memory: > > size = 1 << 20 > > list = [None,] > > while size: > > try: > > mem = [None] * size > > mem[0] = list > > list = mem > > except: > > size = size / 2 > > > > It fails with an access violation. (Turn off virtual memory > > to provoke it.) I had a closer look at this report. It revealed a buglet in Instance_New and raises a question on how to handle the possible NULL values pushed on the stack in ceval.c, at the exception handling code block: > > 3. the NULL pointer at tb is pushed here: > > ceval.c line 1816: PUSH(tb); > > ceval.c line 1817: PUSH(val); > > ceval.c line 1818: PUSH(exc); 1. In PyInstance_New, when the inst->in_dict allocation fails, there's a DECREF(inst) which triggers the instance_dealloc function. The latter goes on checking whether __del__ is defined in the instance's dict (by calling getattr2) whithout checking first whether inst->in_dict is not NULL. I.e. the dealloc_function assumes the instance has been initialized successfully. The net effect is a segfault in PyDict_GetItem which is called with a NULL dict. There are two possible fixes, and I'm not sure which one is better: a) Fix the Instance_New code, by freeing the instance on inst->in_dict allocation failure (without decref'ing the instance). b) Fix the dealloc code, by checking whether in_dict is not NULL before proceeding with the __del__ finalization logic. Opinions? 2. In ceval.c, there are indeed cases where 'tb' and 'exc' are NULL on low-memory conditions. They are pushed on the stack, then popped with a segfault. The only reasonable behavior I get, after some testing, is by setting the tb and exc to Py_None if any of them is NULL before pushing them onto the stack. The program succeeds or the process is killed by the OS (tested on Linux). However, I'm not sure that setting tb and/or exc to Py_None, if NULL, makes any sense and won't cause side effects. Any other suggestions? -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From guido at python.org Mon Jun 26 16:49:11 2000 From: guido at python.org (Guido van Rossum) Date: Mon, 26 Jun 2000 09:49:11 -0500 Subject: [Python-Dev] Let's use the SourceForge Patch Manager In-Reply-To: Your message of "Fri, 23 Jun 2000 10:03:41 +0200." <395319DD.F2584321@lemburg.com> References: <395319DD.F2584321@lemburg.com> Message-ID: <200006261449.JAA01684@cj20424-a.reston1.va.home.com> It's official: I've changed the patch submission guidelines (http://www.python.org/patches/) to point to the patch manager at SourceForge. We are no longer bound by CNRI's legal department, so the requirement for disclaimers or wet signatures is gone. We'll have to see how it works in practice. I've set the address where new patches are mailed to patches at python.org; this should send notifications to the patches list. We could change this to python-dev perhaps, so we can retire the patches address completely (giving it an auto-respond pointing to the SF patch manager, as barry suggested). There are several tasks to be assigned now: we need a triage person who should go through the list of new patches regularly to assign them to developers; we need developers who are willing to have patches assigned to them. We also need a consensus process to decide which patches will be allowed through. I'm hoping to experiment with SF in the coming days to come up with something. Finally, we still need to do something about the existing backlog of patches. The PythonLabs team will try to do something reasonable here. This is not the end -- it's the beginning! --Guido van Rossum (home page: http://www.python.org/~guido/) From jack at oratrix.nl Mon Jun 26 16:29:05 2000 From: jack at oratrix.nl (Jack Jansen) Date: Mon, 26 Jun 2000 16:29:05 +0200 Subject: [Python-Dev] [rasmus@apache.org: Re: PMCs and Apache] In-Reply-To: Message by Greg Stein , Sun, 25 Jun 2000 01:40:23 -0700 , <20000625014023.D29590@lyra.org> Message-ID: <20000626142906.1DDBD37186E@snelboot.oratrix.nl> > Woah... this is an interesting factoid about the number of committers for a > project. I had no idea PHP had this many... > > Can this work with Python? Dunno. I think if a "true core" group pays > attention to the -checkins alias, then yah. If that review is ever lost, > then those "edge" committers could introduce crap. This is one of the reasons I never asked for committer status: the fewer people doing commits the better. I can live with the <2days delay we had upto recently, and for now I'm expecting it to go down to that again after all the turmoil is over. -- 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 guido at python.org Mon Jun 26 17:43:38 2000 From: guido at python.org (Guido van Rossum) Date: Mon, 26 Jun 2000 10:43:38 -0500 Subject: [Python-Dev] [rasmus@apache.org: Re: PMCs and Apache] In-Reply-To: Your message of "Mon, 26 Jun 2000 16:29:05 +0200." <20000626142906.1DDBD37186E@snelboot.oratrix.nl> References: <20000626142906.1DDBD37186E@snelboot.oratrix.nl> Message-ID: <200006261543.KAA02198@cj20424-a.reston1.va.home.com> [Jack Jansen] > This is one of the reasons I never asked for committer status: the > fewer people doing commits the better. I can live with the <2days > delay we had upto recently, and for now I'm expecting it to go down > to that again after all the turmoil is over. Actually, I'd be glad to give you committer status (your colleague Sjoerd just got his :-). I expect that the majority of the subscribers to python-dev can be trusted as committers. I fully expect that most committers won't be committing much -- I don't expect a frenzy of work by committers on the source tree. However the committer status offloads the responsibility of applying the patches you submit after they have been approved -- you can now do it yourself. Less work for me and the others here at PythonLabs! BTW, I would heartily recommend putting the Macintosh tree for Python under SourceForge! --Guido van Rossum (home page: http://www.python.org/~guido/) From mal at lemburg.com Mon Jun 26 17:03:30 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 26 Jun 2000 17:03:30 +0200 Subject: [Python-Dev] Let's use the SourceForge Patch Manager References: <395319DD.F2584321@lemburg.com> <200006261449.JAA01684@cj20424-a.reston1.va.home.com> Message-ID: <395770C2.B903724A@lemburg.com> Guido van Rossum wrote: > > It's official: I've changed the patch submission guidelines > (http://www.python.org/patches/) to point to the patch manager at > SourceForge. We are no longer bound by CNRI's legal department, so > the requirement for disclaimers or wet signatures is gone. > > We'll have to see how it works in practice. I've set the address > where new patches are mailed to patches at python.org; this should send > notifications to the patches list. We could change this to python-dev > perhaps, so we can retire the patches address completely (giving it an > auto-respond pointing to the SF patch manager, as barry suggested). Will there be a list which gets the patches mailed to it by SF ? I'm just asking because the current setup of having the patches available through mail really helps in discussing patch details. > There are several tasks to be assigned now: we need a triage person > who should go through the list of new patches regularly to assign them > to developers; we need developers who are willing to have patches > assigned to them. I'll volunteer for the Unicode side of things :-) > We also need a consensus process to decide which patches will be > allowed through. I'm hoping to experiment with SF in the coming days > to come up with something. > > Finally, we still need to do something about the existing backlog of > patches. The PythonLabs team will try to do something reasonable > here. > > This is not the end -- it's the beginning! -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From jack at oratrix.nl Mon Jun 26 17:13:54 2000 From: jack at oratrix.nl (Jack Jansen) Date: Mon, 26 Jun 2000 17:13:54 +0200 Subject: [Python-Dev] [rasmus@apache.org: Re: PMCs and Apache] In-Reply-To: Message by Guido van Rossum , Mon, 26 Jun 2000 10:43:38 -0500 , <200006261543.KAA02198@cj20424-a.reston1.va.home.com> Message-ID: <20000626151355.3EF8C37186E@snelboot.oratrix.nl> > Actually, I'd be glad to give you committer status (your colleague > Sjoerd just got his :-). I expect that the majority of the > subscribers to python-dev can be trusted as committers. Oww, grumble grumble... Okay, I'll apply for committer status. So there. > BTW, I would heartily recommend putting the Macintosh tree for Python > under SourceForge! I don't think MacCVS can do ssh authorization, and if I followed the discussion here that is needed, right? But if that hurdle can be taken: fine! -- 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 guido at python.org Mon Jun 26 18:32:37 2000 From: guido at python.org (Guido van Rossum) Date: Mon, 26 Jun 2000 11:32:37 -0500 Subject: [Python-Dev] Let's use the SourceForge Patch Manager In-Reply-To: Your message of "Mon, 26 Jun 2000 17:03:30 +0200." <395770C2.B903724A@lemburg.com> References: <395319DD.F2584321@lemburg.com> <200006261449.JAA01684@cj20424-a.reston1.va.home.com> <395770C2.B903724A@lemburg.com> Message-ID: <200006261632.LAA02506@cj20424-a.reston1.va.home.com> [MAL] > Will there be a list which gets the patches mailed to it > by SF ? > > I'm just asking because the current setup of having the patches > available through mail really helps in discussing patch details. I don't think this feature is part of the SF Patch Manager just yet. You could submit it as a request to the SF PM developers though -- apparently they're still working on it. --Guido van Rossum (home page: http://www.python.org/~guido/) From paul at prescod.net Mon Jun 26 17:43:31 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 26 Jun 2000 08:43:31 -0700 Subject: [Python-Dev] winreg Message-ID: <39577A23.EF7DE922@prescod.net> [I'm having mail troubles so my response time may be slow...] I've just had a chance to look at the winreg module. I think that it is too low-level. I wrote a wrapper class that I feel is more Pythonic. I'll outline the basic ideas and then if there is interest I'll develop a test suite and send it out for eyeballing by Mark and others. Yes, I am proposing this for 1.6. If we're going to put in a registry module, it should be as Pythonic as possible. First, about Winreg 1: It was perfect when it was part of the win32 package and was supposed to mirror the win32 APIs exactly (for reasons of documentation and familiarity) but as the "standard" Python registry manipulation module it seems too low-level to me. I'm sure Mark would be the first to admit that it isn't very Pythonic. It's more Microsoft-ic. In one part of the docs he says: "this API is lame, lame, lame. Don't use it." :) There are also bogus parameters that Microsoft hasn't got around to assigning values to, undocumented constants and so forth. My favorite is "WHOLE_HIVE_VOLATILE". Winreg 2: The basic idea in the pythonic wrapper is that there are key "objects" rather than just handles. winreg already has a primtive "handle object" but for some reason most of the stuff that would logically be methods are actually functions that take the handle as the first param. Keys can have subkeys. So in winreg 1 you would say: winreg.CreateKey( winreg.CreateKey( winreg.HKEY_LOCAL_MACHINE, "HARDWARE"), "DESCRIPTION" ) now you say: winreg.HKEY_LOCAL_MACHINE.createKey( "HARDWARE").createKey( "DESCRIPTION" ) (you could also use a path syntax in either case) You can get a complete list of existant subkeys with a getSubkeys() method call. This list behaves like a Python mapping and also like a sequence. You can use either string key names or integer ordinal indexes. You can fetch and delete keys based on those indexes: for key in winreg.HKEY_LOCAL_MACHINE.getSubkeys(): dosomething( key ) Before it was something like this: for index in xrange( 0, sys.maxint ): try: dosomething( winreg.EnumKey( index ) ) except WindowsError: break "Values" (in the Microsoft sense) are handled the same basic way. Looping, deleting, etc. is the same. When you fetch a value, you get a (type,value) tuple. Types are objects with properties: typeobj.intval -> 0..10 typeobj.msname -> REG_SZ, REG_SZ_MULTI, ... typeobj.friendlyname -> "String", "Sting List", ... Type coercions are all done by the underlying module (the old winreg) except that I've decided that binary data should be returned as an array.array('c') rather than an 8-bit string. -- Paul Prescod Out of timber so crooked as that which man is made nothing entirely straight can be built. - Immanuel Kant From fdrake at beopen.com Mon Jun 26 18:04:40 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 26 Jun 2000 09:04:40 -0700 (PDT) Subject: [Python-Dev] Let's use the SourceForge Patch Manager In-Reply-To: <395770C2.B903724A@lemburg.com> References: <395319DD.F2584321@lemburg.com> <200006261449.JAA01684@cj20424-a.reston1.va.home.com> <395770C2.B903724A@lemburg.com> Message-ID: <14679.32536.133849.573542@mailhost.beopen.com> M.-A. Lemburg writes: > Will there be a list which gets the patches mailed to it > by SF ? patches at python.org should get messages of patch manager activity (at least certain actions; not sure which ones yet, but at least additions). > I'm just asking because the current setup of having the patches > available through mail really helps in discussing patch details. Yes! I'd really hate to lose notifications! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Mon Jun 26 18:04:40 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 26 Jun 2000 09:04:40 -0700 (PDT) Subject: [Python-Dev] Let's use the SourceForge Patch Manager In-Reply-To: <395770C2.B903724A@lemburg.com> References: <395319DD.F2584321@lemburg.com> <200006261449.JAA01684@cj20424-a.reston1.va.home.com> <395770C2.B903724A@lemburg.com> Message-ID: <14679.32536.133849.573542@mailhost.beopen.com> M.-A. Lemburg writes: > Will there be a list which gets the patches mailed to it > by SF ? patches at python.org should get messages of patch manager activity (at least certain actions; not sure which ones yet, but at least additions). > I'm just asking because the current setup of having the patches > available through mail really helps in discussing patch details. Yes! I'd really hate to lose notifications! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From paul at prescod.net Mon Jun 26 17:43:31 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 26 Jun 2000 08:43:31 -0700 Subject: [Python-Dev] winreg Message-ID: <39577A23.EF7DE922@prescod.net> [I'm having mail troubles so my response time may be slow...] I've just had a chance to look at the winreg module. I think that it is too low-level. I wrote a wrapper class that I feel is more Pythonic. I'll outline the basic ideas and then if there is interest I'll develop a test suite and send it out for eyeballing by Mark and others. Yes, I am proposing this for 1.6. If we're going to put in a registry module, it should be as Pythonic as possible. First, about Winreg 1: It was perfect when it was part of the win32 package and was supposed to mirror the win32 APIs exactly (for reasons of documentation and familiarity) but as the "standard" Python registry manipulation module it seems too low-level to me. I'm sure Mark would be the first to admit that it isn't very Pythonic. It's more Microsoft-ic. In one part of the docs he says: "this API is lame, lame, lame. Don't use it." :) There are also bogus parameters that Microsoft hasn't got around to assigning values to, undocumented constants and so forth. My favorite is "WHOLE_HIVE_VOLATILE". Winreg 2: The basic idea in the pythonic wrapper is that there are key "objects" rather than just handles. winreg already has a primtive "handle object" but for some reason most of the stuff that would logically be methods are actually functions that take the handle as the first param. Keys can have subkeys. So in winreg 1 you would say: winreg.CreateKey( winreg.CreateKey( winreg.HKEY_LOCAL_MACHINE, "HARDWARE"), "DESCRIPTION" ) now you say: winreg.HKEY_LOCAL_MACHINE.createKey( "HARDWARE").createKey( "DESCRIPTION" ) (you could also use a path syntax in either case) You can get a complete list of existant subkeys with a getSubkeys() method call. This list behaves like a Python mapping and also like a sequence. You can use either string key names or integer ordinal indexes. You can fetch and delete keys based on those indexes: for key in winreg.HKEY_LOCAL_MACHINE.getSubkeys(): dosomething( key ) Before it was something like this: for index in xrange( 0, sys.maxint ): try: dosomething( winreg.EnumKey( index ) ) except WindowsError: break "Values" (in the Microsoft sense) are handled the same basic way. Looping, deleting, etc. is the same. When you fetch a value, you get a (type,value) tuple. Types are objects with properties: typeobj.intval -> 0..10 typeobj.msname -> REG_SZ, REG_SZ_MULTI, ... typeobj.friendlyname -> "String", "Sting List", ... Type coercions are all done by the underlying module (the old winreg) except that I've decided that binary data should be returned as an array.array('c') rather than an 8-bit string. -- Paul Prescod Out of timber so crooked as that which man is made nothing entirely straight can be built. - Immanuel Kant From fdrake at beopen.com Mon Jun 26 17:46:23 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 26 Jun 2000 08:46:23 -0700 (PDT) Subject: [Python-Dev] Fw: Access violation when no memory In-Reply-To: <200006261133.NAA03073@python.inrialpes.fr> References: <200006261133.NAA03073@python.inrialpes.fr> Message-ID: <14679.31439.11309.105239@mailhost.beopen.com> Vladimir Marangozov writes: > There are two possible fixes, and I'm not sure which one is better: > > a) Fix the Instance_New code, by freeing the instance on inst->in_dict > allocation failure (without decref'ing the instance). I think this is the right one; this *shold* be all that's ever needed, and isolates the check to the cod ethat can experiance failure. > b) Fix the dealloc code, by checking whether in_dict is not NULL > before proceeding with the __del__ finalization logic. This protects against bad C code elsewhere that makes a mess of existing objects by stepping around the API (such as by setting inst->in_dict to NULL). I'm not sure we want to protect against that since it could mask bugs (I doubt anyone would do that deliberatly, so I feel safe calling it a bug!). > Opinions? And for free! So infer what you will about their worth. :) > 2. In ceval.c, there are indeed cases where 'tb' and 'exc' are NULL on > low-memory conditions. They are pushed on the stack, then popped with > a segfault. The only reasonable behavior I get, after some testing, > is by setting the tb and exc to Py_None if any of them is NULL before > pushing them onto the stack. The program succeeds or the process is > killed by the OS (tested on Linux). > > However, I'm not sure that setting tb and/or exc to Py_None, if NULL, > makes any sense and won't cause side effects. This doesn't seem like a situation where you'd be masking some other kind of bug by using Py_None, and it avoids the core dump. Since you're not masking anything, I'd go ahead and use Py_None here. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From esr at thyrsus.com Mon Jun 26 20:01:25 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 26 Jun 2000 14:01:25 -0400 Subject: [Python-Dev] Now that the man is back... Message-ID: <20000626140125.A3266@thyrsus.com> Guido, can we get these into 1.6? They're needed for the the ncurses extensions I'm working on. -- Eric S. Raymond "This country, with its institutions, belongs to the people who inhabit it. Whenever they shall grow weary of the existing government, they can exercise their constitutional right of amending it or their revolutionary right to dismember it or overthrow it." -- Abraham Lincoln, 4 April 1861 -------------- next part -------------- A non-text attachment was scrubbed... Name: libascii.tex Type: application/x-tex Size: 4408 bytes Desc: not available URL: -------------- next part -------------- # # ascii.py -- constants and memembership tests for ASCII characters # NUL = 0x00 # ^@ SOH = 0x01 # ^A STX = 0x02 # ^B ETX = 0x03 # ^C EOT = 0x04 # ^D ENQ = 0x05 # ^E ACK = 0x06 # ^F BEL = 0x07 # ^G BS = 0x08 # ^H TAB = 0x09 # ^I HT = 0x09 # ^I LF = 0x0a # ^J NL = 0x0a # ^J VT = 0x0b # ^K FF = 0x0c # ^L CR = 0x0d # ^M SO = 0x0e # ^N SI = 0x0f # ^O DLE = 0x10 # ^P DC1 = 0x11 # ^Q DC2 = 0x12 # ^R DC3 = 0x13 # ^S DC4 = 0x14 # ^T NAK = 0x15 # ^U SYN = 0x16 # ^V ETB = 0x17 # ^W CAN = 0x18 # ^X EM = 0x19 # ^Y SUB = 0x1a # ^Z ESC = 0x1b # ^[ FS = 0x1c # ^\ GS = 0x1d # ^] RS = 0x1e # ^^ US = 0x1f # ^_ SP = 0x20 # space DEL = 0x7f # delete controlnames = [ "NUL", "SOH", "STX", "ETX", "EOT", "ENQ", "ACK", "BEL", "BS", "HT", "LF", "VT", "FF", "CR", "SO", "SI", "DLE", "DC1", "DC2", "DC3", "DC4", "NAK", "SYN", "ETB", "CAN", "EM", "SUB", "ESC", "FS", "GS", "RS", "US", "SP" ] def _ctoi(c): if type(c) == type(""): return ord(c) else: return c def isalnum(c): return isalpha(c) or isdigit(c) def isalpha(c): return isupper(c) or islower(c) def isascii(c): return _ctoi(c) <= 127 # ? def isblank(c): return _ctoi(c) in (8,32) def iscntrl(c): return _ctoi(c) <= 31 def isdigit(c): return _ctoi(c) >= 48 and _ctoi(c) <= 57 def isgraph(c): return _ctoi(c) >= 33 and _ctoi(c) <= 126 def islower(c): return _ctoi(c) >= 97 and _ctoi(c) <= 122 def isprint(c): return _ctoi(c) >= 32 and _ctoi(c) <= 126 def ispunct(c): return _ctoi(c) != 32 and not isalnum(c) def isspace(c): return _ctoi(c) in (12, 10, 13, 9, 11) def isupper(c): return _ctoi(c) >= 65 and _ctoi(c) <= 90 def isxdigit(c): return isdigit(c) or \ (_ctoi(c) >= 65 and _ctoi(c) <= 70) or (_ctoi(c) >= 97 and _ctoi(c) <= 102) def isctrl(c): return _ctoi(c) < 32 def ismeta(c): return _ctoi(c) > 127 def ascii(c): if type(c) == type(""): return chr(_ctoi(c) & 0x7f) else: return _ctoi(c) & 0x7f def ctrl(c): if type(c) == type(""): return chr(_ctoi(c) & 0x1f) else: return _ctoi(c) & 0x1f def alt(c): if type(c) == type(""): return chr(_ctoi(c) | 0x80) else: return _ctoi(c) | 0x80 def unctrl(c): bits = _ctoi(c) if bits == 0x7f: rep = "^?" elif bits & 0x20: rep = chr((bits & 0x7f) | 0x20) else: rep = "^" + chr(((bits & 0x7f) | 0x20) + 0x20) if bits & 0x80: return "!" + rep return rep From tim_one at email.msn.com Mon Jun 26 20:41:12 2000 From: tim_one at email.msn.com (Tim Peters) Date: Mon, 26 Jun 2000 14:41:12 -0400 Subject: [Python-Dev] RE: [Patches] Let's use the SourceForge Patch Manager In-Reply-To: <200006261449.JAA01684@cj20424-a.reston1.va.home.com> Message-ID: [Guido] > It's official: I've changed the patch submission guidelines > (http://www.python.org/patches/) to point to the patch manager at > SourceForge. We are no longer bound by CNRI's legal department, so > the requirement for disclaimers or wet signatures is gone. Yay! Wonder how long that will last . Attached is a first cut at documenting the intended use of SourceForge's patch status tags, and the workflow associated with patch status changes. The areas in need of fleshing out are marked with "[xxx ...]". Gripe at will. I don't think anyone expects this to work smoothly at first. Strive for patience, and let's work to make SF a really *good* place for patches! never-thought-i'd-actually-miss-lotus-notes-ly y'rs - tim PS: I'll move this (& related info) to a reasonable place eventually, so don't bother griping about email for now. Intended use of SourceForge patch status tags --------------------------------------------- revision 1 26-Jun-2000 Open The initial status of all patches. The patch is under consideration, but has not been reviewed yet. The status will normally change to Accepted or Rejected next. The person submitting the patch should (if they can) assign it to the person they most want to review it. Else the patch will be assigned via [xxx a list of expertise areas should be developed] Discussion of patches is carried out via [xxx Python-Dev? patches list? without a mail gateway, the SourceForge patch interface looks too clumsy to use for controversial patches] Accepted The powers that be have accepted the patch, but it has not been applied yet. [xxx flesh out -- Guido Bottleneck avoidable here?] The status will normally change to Closed next. The person changing the status to Accepted should, at the same time, assign the patch to whoever they believe is most likely to be able & willing to apply it (the submitter if possible). Closed The patch has been accepted and applied. The previous status was Accepted, or possibly Open if the submitter was Guido (or moral equivalent in some particular area of expertise). If possible, the submitter should apply the patch and change the status to Closed. Else anyone with sufficient power should feel encouraged to do these on the submitter's behalf. Rejected The patch has been reviewed and rejected. When the objections are addressed, the status may change to Open again. Note that SourceForge allows the submitter to overwrite the patch with a new version. Out of date Previous status was Open or Accepted or Postponed, but the patch no longer works. Please enter a comment when changing the status to "Out of date", to record the nature of the problem and the previous status. Postponed The previous status was Open or Accepted, but for some reason (e.g., pending release) the patch should not be reviewed or applied until further notice. The status will normally change to Open or Accepted next. Please enter a comment when changing the status to Postponed, to record the reason, the previous status, and the conditions under which the patch should revert to Open or Accepted. Deleted Bit bucket. Use only if it's OK for the patch and its SourceForge history to disappear. As of 26-June-2000, SF does not actually throw away Deleted patches, but that may change. From DavidA at ActiveState.com Mon Jun 26 21:10:04 2000 From: DavidA at ActiveState.com (David Ascher) Date: Mon, 26 Jun 2000 12:10:04 -0700 Subject: [Python-Dev] semaphore support in thread_*.h Message-ID: I noticed that the support for the semaphore calls in the various thread_* is very very spotty, with a comment in the BeOS implementation that read: * Guido says not to implement this because it's not used anywhere; * I'll do it anyway, you never know when it might be handy, and it's * easy... (that last bit is not true of all implementations, apparently =). 1) Is it true that the sema_ calls are never used? 2) If yes, shouldn't we remove the sema_ calls from the thread API and have similar functionality on all platforms? (There are related issues re: for example whether async thread locking is available, whether threads are joinable or not (see thread_cthread.h), etc.) --david From tim_one at email.msn.com Mon Jun 26 21:19:58 2000 From: tim_one at email.msn.com (Tim Peters) Date: Mon, 26 Jun 2000 15:19:58 -0400 Subject: [Python-Dev] Let's use the SourceForge Patch Manager In-Reply-To: <395770C2.B903724A@lemburg.com> Message-ID: [MAL] > Will there be a list which gets the patches mailed to it > by SF ? > > I'm just asking because the current setup of having the patches > available through mail really helps in discussing patch details. I agree -- SF isn't (yet) good for patch discussions. Plugging away, but haven't yet figured out exactly when or how SF decides to send email. In particular, don't yet know how (or whether it's possible) to trick current SF into populating a mailing list. From guido at python.org Mon Jun 26 22:24:57 2000 From: guido at python.org (Guido van Rossum) Date: Mon, 26 Jun 2000 15:24:57 -0500 Subject: [Python-Dev] Now that the man is back... In-Reply-To: Your message of "Mon, 26 Jun 2000 14:01:25 -0400." <20000626140125.A3266@thyrsus.com> References: <20000626140125.A3266@thyrsus.com> Message-ID: <200006262024.PAA01212@cj20424-a.reston1.va.home.com> [ESR] > Guido, can we get these into 1.6? They're needed for the the ncurses > extensions I'm working on. Eric, We (PythonLabs + Andrew Kuchling & Greg Ward) discussed this at our recent 1.6 planning meeting. This doesn't have much use outside curses. Therefore, Andrew will check it in as a submodule of the new curses package. --Guido van Rossum (home page: http://www.python.org/~guido/) From fdrake at beopen.com Mon Jun 26 21:24:40 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 26 Jun 2000 12:24:40 -0700 (PDT) Subject: [Python-Dev] Now that the man is back... In-Reply-To: <20000626140125.A3266@thyrsus.com> References: <20000626140125.A3266@thyrsus.com> Message-ID: <14679.44536.931222.448738@mailhost.beopen.com> Eric S. Raymond writes: > Guido, can we get these into 1.6? They're needed for the the ncurses > extensions I'm working on. This will be the curses.ascii module per a discussion last week which included both Guido and Andrew. Andrew, my Unix machine is down for repairs; can you check these in for me, changing the module name to curses.ascii in the documentation file? I don't want to hold up since Eric is still developing some of the ncurses support. Thanks! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From jeremy at beopen.com Mon Jun 26 21:35:17 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Mon, 26 Jun 2000 15:35:17 -0400 (EDT) Subject: [Python-Dev] Now that the man is back... In-Reply-To: <20000626140125.A3266@thyrsus.com> References: <20000626140125.A3266@thyrsus.com> Message-ID: <14679.45173.439937.800007@bitdiddle.concentric.com> The ascii module is going into the curses package. Andrew Kuchling is responsible for it. Jeremy From esr at thyrsus.com Mon Jun 26 21:46:50 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 26 Jun 2000 15:46:50 -0400 Subject: [Python-Dev] Now that the man is back... In-Reply-To: <14679.44536.931222.448738@mailhost.beopen.com>; from fdrake@beopen.com on Mon, Jun 26, 2000 at 12:24:40PM -0700 References: <20000626140125.A3266@thyrsus.com> <14679.44536.931222.448738@mailhost.beopen.com> Message-ID: <20000626154650.C3685@thyrsus.com> Fred L. Drake, Jr. : > This will be the curses.ascii module per a discussion last week > which included both Guido and Andrew. OK, I guess. It will be useful for more than curses, though, so I don't understand the naming choice. -- Eric S. Raymond Hoplophobia (n.): The irrational fear of weapons, correctly described by Freud as "a sign of emotional and sexual immaturity". Hoplophobia, like homophobia, is a displacement symptom; hoplophobes fear their own "forbidden" feelings and urges to commit violence. This would be harmless, except that they project these feelings onto others. The sequelae of this neurosis include irrational and dangerous behaviors such as passing "gun-control" laws and trashing the Constitution. From paul at prescod.net Mon Jun 26 21:53:18 2000 From: paul at prescod.net (Paul Prescod) Date: Mon, 26 Jun 2000 12:53:18 -0700 Subject: [Python-Dev] winreg Message-ID: <3957B4AE.5562716C@prescod.net> I haven't seen this message come through: http://www.python.org/pipermail/python-dev/2000-June/006346.html I'm not sure if I missed it due to an email problem. Paul Prescod - Not encumbered by corporate consensus When George Bush entered office, a Washington Post-ABC News poll found that 62 percent of Americans "would be willing to give up a few of the freedoms we have" for the war effort. They have gotten their wish. - "This is your bill of rights...on drugs", Harpers, Dec. 1999 From fdrake at beopen.com Mon Jun 26 21:59:10 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 26 Jun 2000 12:59:10 -0700 (PDT) Subject: [Python-Dev] Now that the man is back... In-Reply-To: <20000626154650.C3685@thyrsus.com> References: <20000626140125.A3266@thyrsus.com> <14679.44536.931222.448738@mailhost.beopen.com> <20000626154650.C3685@thyrsus.com> Message-ID: <14679.46606.287276.330659@mailhost.beopen.com> Eric S. Raymond writes: > OK, I guess. It will be useful for more than curses, though, so I don't > understand the naming choice. Eric, In theory, yes, but... there have not been a lot of requests for the is*() functions (which are the ones I think you're referring to as generally useful). I think some of these are already take care of by things like "if c in string.hexdigits:", and others can be handled by making queries on the Unicode character properties. Given the dearth of requests for this, I don't see a clear need to place this elsewhere. If feedback to the beta suggests a better location, we'll certainly consider it! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido at python.org Mon Jun 26 23:28:16 2000 From: guido at python.org (Guido van Rossum) Date: Mon, 26 Jun 2000 16:28:16 -0500 Subject: [Python-Dev] semaphore support in thread_*.h In-Reply-To: Your message of "Mon, 26 Jun 2000 12:10:04 MST." References: Message-ID: <200006262128.QAA01518@cj20424-a.reston1.va.home.com> > I noticed that the support for the semaphore calls in the various thread_* > is very very spotty, with a comment in the BeOS implementation that read: > > * Guido says not to implement this because it's not used anywhere; > * I'll do it anyway, you never know when it might be handy, and it's > * easy... > > (that last bit is not true of all implementations, apparently =). > > 1) Is it true that the sema_ calls are never used? > > 2) If yes, shouldn't we remove the sema_ calls from the thread API and have > similar functionality on all platforms? > > (There are related issues re: for example whether async thread locking is > available, whether threads are joinable or not (see thread_cthread.h), etc.) The sema_ calls aren't used anywhere in the current source. I'd be for removing them. I'm not even sure why they are there -- maybe Sjoerd remembers? (This code was once part of something else than Python.) --Guido van Rossum (home page: http://www.python.org/~guido/) From akuchlin at mems-exchange.org Mon Jun 26 23:28:26 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Mon, 26 Jun 2000 17:28:26 -0400 Subject: [Python-Dev] Now that the man is back... In-Reply-To: <14679.44536.931222.448738@mailhost.beopen.com> References: <20000626140125.A3266@thyrsus.com> <14679.44536.931222.448738@mailhost.beopen.com> Message-ID: <20000626172826.E2282@kronos.cnri.reston.va.us> On Mon, Jun 26, 2000 at 12:24:40PM -0700, Fred L. Drake, Jr. wrote: > Andrew, my Unix machine is down for repairs; can you check these in >for me, changing the module name to curses.ascii in the documentation >file? I don't want to hold up since Eric is still developing some of >the ncurses support. I'll do that tonight; I had no time for Python hacking over the weekend... --amk From mhammond at skippinet.com.au Tue Jun 27 02:03:16 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Tue, 27 Jun 2000 10:03:16 +1000 Subject: [Python-Dev] winreg In-Reply-To: <39577A23.EF7DE922@prescod.net> Message-ID: > I've just had a chance to look at the winreg module. I think that it is > too low-level. I agree. There was a proposal (from Thomas Heller, IIRC) to do just this. I successfully argued there should be _2_ modules for Python - the raw low-level API, which guarantees you can do (almost) anything. A higher-level API could cover the 80% of cases. It is probably worth getting in touch with Thomas - he may be able to dig up his proposed high-level API. Ive CCd him on this message [I hope is _was_ you Thomas - otherwise you will be wondering WTF I am on about :] I was very keen to ensure the win32api code was used as the low-level API, simply because it has been well tested and used. We _know_ it has no significant limitations. Im happy to support a high-level API, but didnt have the inclination to provide one. Every one I have seen and every one I have tried to design has started to fall-apart under real-world use - Ive needed to revert back to the low-level. > There are also bogus parameters that Microsoft hasn't got around to > assigning values to, undocumented constants and so forth. My favorite is > "WHOLE_HIVE_VOLATILE". This is exactly my concern with a high-level API - you cant hope to capture all this - especially the undocumented ones - so having a low-level API means you can do anything, even stuff never dreamt of by the high-level designer. I have no real problem with your proposed design, as long as it it written in Python, _using_ the low-level API. It could be called "registry" or I would even be happy for "winreg.pyd" -> "_winreg.pyd" and your new module to be called "winreg.py" Mark. From tim_one at email.msn.com Tue Jun 27 00:13:42 2000 From: tim_one at email.msn.com (Tim Peters) Date: Mon, 26 Jun 2000 18:13:42 -0400 Subject: [Python-Dev] semaphore support in thread_*.h In-Reply-To: Message-ID: [David Ascher] > I noticed that the support for the semaphore calls in the various thread_* > is very very spotty, with a comment in the BeOS implementation that read: > > * Guido says not to implement this because it's not used anywhere; > * I'll do it anyway, you never know when it might be handy, and it's > * easy... > (that last bit is not true of all implementations, apparently =). > > 1) Is it true that the sema_ calls are never used? Best I can tell, the following sema functions are indeed never used: PyThread_allocate_sema PyThread_free_sema PyThread_down_sema PyThread_up_sema the following #define's are never used: WAIT_SEMA NOWAIT_SEMA and the following non-sema pythread.h functions are not only never used, they're defined only in thread_sgi.h: PyThread_create_key PyThread_delete_key PyThread_set_key_value PyThread_get_key_value > 2) If yes, shouldn't we remove the sema_ calls from the thread > API and have similar functionality on all platforms? +1 from me. If someone wants platform-specific thread functions, they should be in a platform-specific extension module, not messing up the core. > (There are related issues re: for example whether async thread locking is > available, whether threads are joinable or not (see > thread_cthread.h), etc.) Sorry, don't know what you're getting at here (e.g., have any specific line or function of thread_cthread.h in mind?). From fdrake at beopen.com Tue Jun 27 00:25:42 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Mon, 26 Jun 2000 15:25:42 -0700 (PDT) Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager In-Reply-To: References: <14679.32536.133849.573542@mailhost.beopen.com> Message-ID: <14679.55398.996503.269852@mailhost.beopen.com> Tim Peters writes: > Fred, would you please explain how that works or where that was set up? > I've puttered away many hours now playing with the SourceForge facilities From the "project page", go to "Project Admin" on the left navigation bar, then "Edit Public Info" at the top of the page. There are places to edit some email addresses near the bottom of the page. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one at email.msn.com Mon Jun 26 23:38:51 2000 From: tim_one at email.msn.com (Tim Peters) Date: Mon, 26 Jun 2000 17:38:51 -0400 Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager In-Reply-To: <14679.32536.133849.573542@mailhost.beopen.com> Message-ID: [Fred] > patches at python.org should get messages of patch manager activity (at > least certain actions; not sure which ones yet, but at least > additions). Fred, would you please explain how that works or where that was set up? I've puttered away many hours now playing with the SourceForge facilities (alas, most of that time waiting for web pages to load), but haven't stumbled into anything that hints the patch manager knows anything about patches at python.org. so-stupid-in-so-many-ways-ly y'rs - tim From tim_one at email.msn.com Tue Jun 27 01:14:06 2000 From: tim_one at email.msn.com (Tim Peters) Date: Mon, 26 Jun 2000 19:14:06 -0400 Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager In-Reply-To: <14679.55398.996503.269852@mailhost.beopen.com> Message-ID: [Fred L. Drake, Jr.] > From the "project page", go to "Project Admin" on the left > navigation bar, then "Edit Public Info" at the top of the page. There > are places to edit some email addresses near the bottom of the page. Aha! The one & only link I had never clicked -- I bet I could have figured that out myself in another week or two . Thank you. Now why do we have "Use Bug Tracker" checked? If nobody objects, I'll turn that off -- we're still doing bugs w/ Jitterbug on python.org. ten-stop-shopping-ly y'rs - tim From guido at beopen.com Tue Jun 27 04:35:52 2000 From: guido at beopen.com (Guido van Rossum) Date: Mon, 26 Jun 2000 21:35:52 -0500 Subject: [Python-Dev] ANN: Release schedule Message-ID: <200006270235.VAA02631@cj20424-a.reston1.va.home.com> Here at BeOpen we're scrambling to get the release schedule for the rest of Python 1.6 planned. We're now looking at releasing Python 1.6b1 (or maybe it's going to be called 1.6a3 after all) on June 30! This means that if SRE isn't ready, we'll go with an incomplete SRE. Still better than no SRE! Please, PLEASE, if you have pending patches that you think should go into 1.6b1, submit them to SourceForge. We'll do our best to have a look at every patch submitted; but don't wait until the last moment. (Trent Mick, it would be helpful if you assigned each of your patches a potential reviewer from the list of existing developers -- that way we can split up the review load.) --Guido van Rossum (home page: http://www.python.org/~guido/) From trentm at activestate.com Tue Jun 27 05:52:59 2000 From: trentm at activestate.com (Trent Mick) Date: Mon, 26 Jun 2000 20:52:59 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test test_pyexpat.py,1.2,1.3 In-Reply-To: <200006270037.RAA25539@slayer.i.sourceforge.net> References: <200006270037.RAA25539@slayer.i.sourceforge.net> Message-ID: <20000626205259.A3866@activestate.com> On Mon, Jun 26, 2000 at 05:37:27PM -0700, A . M . Kuchling wrote: > Update of /cvsroot/python/python/dist/src/Lib/test > In directory slayer.i.sourceforge.net:/tmp/cvs-serv25501 > > Modified Files: > test_pyexpat.py > Log Message: > Change pyexpat test suite to exercise the .returns_unicode attribute, > parsing the sample data once with 8-bit strings and once with Unicode. > Does this require a new Lib/test/output/test_pyexpat? Trent -- Trent Mick trentm at activestate.com From DavidA at ActiveState.com Tue Jun 27 07:34:13 2000 From: DavidA at ActiveState.com (David Ascher) Date: Mon, 26 Jun 2000 22:34:13 -0700 Subject: [Python-Dev] semaphore support in thread_*.h In-Reply-To: Message-ID: > > (There are related issues re: for example whether async thread > locking is > > available, whether threads are joinable or not (see > > thread_cthread.h), etc.) > > Sorry, don't know what you're getting at here (e.g., have any > specific line > or function of thread_cthread.h in mind?). /* looks like solaris detaches the thread to never rejoin * so well do it here */ in thread_cthread.h The async thread locking comment was one of my personal issues -- I considered briefly providing a thread layer on top of the NSPR (Netscape Portable runtime) which is part of Mozilla. It has locks, but no async locking calls. --david From rob at hooft.net Tue Jun 27 11:32:02 2000 From: rob at hooft.net (Rob W. W. Hooft) Date: Tue, 27 Jun 2000 11:32:02 +0200 (CEST) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses ascii.py,NONE,1.1 textpad.py,NONE,1.1 In-Reply-To: <200006262355.QAA17089@slayer.i.sourceforge.net> References: <200006262355.QAA17089@slayer.i.sourceforge.net> Message-ID: <14680.29842.372192.274003@temoleh.chem.uu.nl> AMK> Update of /cvsroot/python/python/dist/src/Lib/curses AMK> In directory slayer.i.sourceforge.net:/tmp/cvs-serv17079 AMK> Added Files: AMK> ascii.py textpad.py AMK> Log Message: AMK> Added two modules for ASCII characters and a simple editing form (ESR) AMK> --- NEW FILE --- AMK> # AMK> # ascii.py -- constants and memembership tests for ASCII characters AMK> # ^^^^^ two letters too much? Rob From gvwilson at nevex.com Tue Jun 27 12:30:55 2000 From: gvwilson at nevex.com (Greg Wilson) Date: Tue, 27 Jun 2000 06:30:55 -0400 (EDT) Subject: [Python-Dev] C# (new language from Microsoft) Message-ID: I'm sure many of you will have seen this announcement already, but for those who haven't, Microsoft is launching a new language to compete with C, C++, and Java: http://msdn.microsoft.com/vstudio/nextgen/technology/csharpintro.asp Greg From effbot at telia.com Tue Jun 27 12:35:22 2000 From: effbot at telia.com (Fredrik Lundh) Date: Tue, 27 Jun 2000 12:35:22 +0200 Subject: [Python-Dev] ANN: Release schedule References: <200006270235.VAA02631@cj20424-a.reston1.va.home.com> Message-ID: <017501bfe023$684fca40$f2a6b5d4@hagrid> guido wrote: > Here at BeOpen we're scrambling to get the release schedule for the > rest of Python 1.6 planned. We're now looking at releasing Python > 1.6b1 (or maybe it's going to be called 1.6a3 after all) on June 30! > This means that if SRE isn't ready, we'll go with an incomplete SRE. > Still better than no SRE! a major SRE patch is coming up later today. btw, what would it take for me to check it in myself (assuming someone will give me commit privs, of course)? can I apply patches via sourceforge's web interface, or do I have to figure out how to run cvs over ssh etc etc (tim? where's the second installment of your sourceforge vs. windows series?) From gmcm at hypernet.com Tue Jun 27 12:36:07 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Tue, 27 Jun 2000 06:36:07 -0400 Subject: [Python-Dev] winreg In-Reply-To: References: <39577A23.EF7DE922@prescod.net> Message-ID: <1250020276-32999633@hypernet.com> Mark wrote: [Paul] > > I've just had a chance to look at the winreg module. I think > > that it is too low-level. > > I agree. There was a proposal (from Thomas Heller, IIRC) to do > just this. I successfully argued there should be _2_ modules for > Python - the raw low-level API, which guarantees you can do > (almost) anything. A higher-level API could cover the 80% of > cases. It is probably worth getting in touch with Thomas - he > may be able to dig up his proposed high-level API. Found it. ------- Forwarded message follows ------- From: "Thomas Heller" To: , Date sent: Thu, 3 Feb 2000 14:27:00 +0100 Subject: [Python-Dev] Revised proposal (and preliminary implementation): Registry access module for Python on Windows Ok, at least the first proposal did start the discussion. Here is a revised one: A preliminary implementation is available at http://starship.python.net/crew/theller/ ----------------------------------------------------------------- ----- winreg - windows registry access module Exception: error - raised when a function fails. Will contain a windows error code and a textual description. Objects: regnode object - represents a open key in the registry. Functions: OpenKey (name) -> regnode object Opens an existing key with the specified access rights and returns a regnode object. name is specified like "HKLM\Software\Python" or "HKEY_LOCAL_MACHINE\Software\Python" CreateKey (name) -> regnode object Creates a new key or opens an existing one and returns a regnode object. For the name format see OpenKey regnode object methods: Values () -> dict Returns a dictionary mapping names to values. The or unnamed value has the key ''. The values are either strings or integers, depending on the REG_* type. GetValue ([name]) -> integer or string Returns a value specified by name or the default value. SetValue ([name,] value) Set a named or the value. Named values must be integers or string (which are stored as REG_DWORD or REG_SZ). Should an optional third parameter be used, allowing to store in other REG_* typecodes? I dont think so. DeleteValue ([name]) Deletes a named or the value. SubKeys () -> sequence Returns a sequence containing the names of all subkeys. DeleteKey (name [,recursive=0]) If recursive is 0, deletes the named key if no subkeys exist. If there are subkeys an error is raised. If recursive is not 0, the named key is deleted including subkeys. OpenKey (name) -> regnode object Openes an existing subkey and returns a regnode object pointing to it. CreateKey (name) -> regnode object Creates a new or openes an existing subkey and returns a regnode object pointing to it. regnode objects have the following properties: name - the name of the RegistryKey, something like "HKLM\Software\Python" hkey - the integer keyhandle ----------------------------------------------------------------- ----- Thomas Heller _______________________________________________ Python-Dev maillist - Python-Dev at python.org http://www.python.org/mailman/listinfo/python-dev ------- End of forwarded message ------- - Gordon From gstein at lyra.org Tue Jun 27 12:52:02 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 27 Jun 2000 03:52:02 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses wrapper.py,1.2,1.3 In-Reply-To: <200006270050.RAA26210@slayer.i.sourceforge.net>; from akuchling@users.sourceforge.net on Mon, Jun 26, 2000 at 05:50:42PM -0700 References: <200006270050.RAA26210@slayer.i.sourceforge.net> Message-ID: <20000627035202.M29590@lyra.org> I just don't buy this. Look at that code. Look at the definition of finally. That code simply screams for the use of finally. Eric: just what happens? What is "broke things"? Do you have a reproducible test case that I can use? In good conscience, I have to disagree with reverting this stuff. If we're seeking to make the code the best possible, then this is a backward step. Besides its redundancy, it also places the traceback into a local variable and then raises an exception -- a perfect recipe for creating a ref loop. Cheers, -g On Mon, Jun 26, 2000 at 05:50:42PM -0700, A.M. Kuchling wrote: > Update of /cvsroot/python/python/dist/src/Lib/curses > In directory slayer.i.sourceforge.net:/tmp/cvs-serv26153 > > Modified Files: > wrapper.py > Log Message: > Drop back to old version of wrapper(); ESR reports that it broke things, > and I lack the time to track down the cause. > > > Index: wrapper.py > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Lib/curses/wrapper.py,v > retrieving revision 1.2 > retrieving revision 1.3 > diff -C2 -r1.2 -r1.3 > *** wrapper.py 2000/06/10 23:39:05 1.2 > --- wrapper.py 2000/06/27 00:50:40 1.3 > *************** > *** 18,24 **** > --- 18,26 ---- > """ > > + res = None > try: > # Initialize curses > stdscr=curses.initscr() > + > # Turn off echoing of keys, and enter cbreak mode, > # where no buffering is performed on keyboard input > *************** > *** 30,39 **** > stdscr.keypad(1) > > ! return apply(func, (stdscr,) + rest) > ! > ! finally: > ! # Restore the terminal to a sane state on the way out. > stdscr.keypad(0) > curses.echo() ; curses.nocbreak() > curses.endwin() > > --- 32,51 ---- > stdscr.keypad(1) > > ! res = apply(func, (stdscr,) + rest) > ! except: > ! # In the event of an error, restore the terminal > ! # to a sane state. > stdscr.keypad(0) > curses.echo() ; curses.nocbreak() > curses.endwin() > + > + # Pass the exception upwards > + (exc_type, exc_value, exc_traceback) = sys.exc_info() > + raise exc_type, exc_value, exc_traceback > + else: > + # Set everything back to normal > + stdscr.keypad(0) > + curses.echo() ; curses.nocbreak() > + curses.endwin() # Terminate curses > > + return res > > > _______________________________________________ > Python-checkins mailing list > Python-checkins at python.org > http://www.python.org/mailman/listinfo/python-checkins -- Greg Stein, http://www.lyra.org/ From thomas.heller at ion-tof.com Tue Jun 27 13:09:24 2000 From: thomas.heller at ion-tof.com (Thomas Heller) Date: Tue, 27 Jun 2000 13:09:24 +0200 Subject: [Python-Dev] winreg References: Message-ID: <019601bfe028$281dab90$4500a8c0@thomasnb> > > I've just had a chance to look at the winreg module. I think that it is > > too low-level. > > I agree. There was a proposal (from Thomas Heller, IIRC) to do just this. > I successfully argued there should be _2_ modules for Python - the raw > low-level API, which guarantees you can do (almost) anything. A > higher-level API could cover the 80% of cases. It is probably worth > getting in touch with Thomas - he may be able to dig up his proposed > high-level API. Ive CCd him on this message [I hope is _was_ you Thomas - > otherwise you will be wondering WTF I am on about :] Yes, it was me :-) Here is the 3. (final?) proposal, earlier ones are in the archives: http://www.python.org/pipermail/python-dev/2000-February/003417.html and http://www.python.org/pipermail/python-dev/2000-February/003472.html ---------------------------------------------------------------------- winreg - windows registry access module Exception: error - raised when a function fails. Will contain a windows error code and a textual description. Objects: regkey object - represents a open key in the registry. Functions: OpenKey (name) -> regkey object Opens an existing key with the specified access rights and returns a regkey object. name is specified like "HKLM\Software\Python" or "HKEY_LOCAL_MACHINE\Software\Python" CreateKey (name) -> regkey object Creates a new key or opens an existing one and returns a regkey object. For the name format see OpenKey regkey object methods: Standard Mapping protocol: len (r) r[k] r[k] = x del r[k] r.clear() r.has_key(k) r.items() r.keys() r.update(dict) r.values() r.get(k[, x]) todict() -> dictionary Returns a dictionary mapping value names to values. SubKeys () -> sequence Returns a sequence containing the names of all subkeys. DeleteKey (name [,recursive=0]) If recursive is 0, deletes the named key if no subkeys exist. If there are subkeys an error is raised. If recursive is not 0, the named key is deleted including subkeys. OpenKey (name) -> regkey object Openes an existing subkey and returns a regkey object pointing to it. CreateKey (name) -> regkey object Creates a new or openes an existing subkey and returns a regkey object pointing to it. regkey objects have the following properties: name - the name of the RegistryKey, something like "HKLM\Software\Python" hkey - the integer keyhandle ---------------------------------------------------------------------- It would not be too much work to implement it, but I will be away the next 20 days... > I have no real problem with your proposed design, as long as it it written > in Python, _using_ the low-level API. It could be called "registry" or I > would even be happy for "winreg.pyd" -> "_winreg.pyd" and your new module > to be called "winreg.py" > If we change the name of the low level api module, we have to change Distutils, because it is used there. Maybe we would better use the high level api then, but there is still this 1.5 compatibility using the win32api module. Thomas From guido at beopen.com Tue Jun 27 14:23:36 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 27 Jun 2000 07:23:36 -0500 Subject: [Python-Dev] ANN: Release schedule In-Reply-To: Your message of "Tue, 27 Jun 2000 12:35:22 +0200." <017501bfe023$684fca40$f2a6b5d4@hagrid> References: <200006270235.VAA02631@cj20424-a.reston1.va.home.com> <017501bfe023$684fca40$f2a6b5d4@hagrid> Message-ID: <200006271223.HAA01391@cj20424-a.reston1.va.home.com> [effbot] > a major SRE patch is coming up later today. Great! > btw, what would it take for me to check it in myself (assuming someone > will give me commit privs, of course)? can I apply patches via sourceforge's > web interface, or do I have to figure out how to run cvs over ssh etc etc Erm, the latter. From a Unix system it's a breeze. From Windows, it's a relative breeze to do an *anonymous* checkout (no SSH required), but getting commit permission is a pain -- Tim will research this. (Do you have access to any Unix or Linux system at all?) I'll make you a developer anyway. > (tim? where's the second installment of your sourceforge vs. windows series?) I'm waiting too! --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at beopen.com Tue Jun 27 16:30:30 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 27 Jun 2000 09:30:30 -0500 Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager In-Reply-To: Your message of "Mon, 26 Jun 2000 17:38:51 -0400." References: Message-ID: <200006271430.JAA01769@cj20424-a.reston1.va.home.com> > [Fred] > > patches at python.org should get messages of patch manager activity (at > > least certain actions; not sure which ones yet, but at least > > additions). [Tim] > Fred, would you please explain how that works or where that was set up? > I've puttered away many hours now playing with the SourceForge facilities > (alas, most of that time waiting for web pages to load), but haven't > stumbled into anything that hints the patch manager knows anything about > patches at python.org. Yes, it's hidden, and Fred had to show me too. First, login to SourceForge. Then, go to the Python Project. In the left sidebar, under Project: Python, go to Project Admin. Near the top, you now see some navigation links; go to Edit Public Info. At the very bottom there are three text fields for email addresses. The address for New Patches (a misnomer -- it's really all changes made to the Patch Manager) says patches at python.org. The address for New Bugs is currently set to guido at beopen.com. I suppose I should set it to pythoneers at beopen.com or even to python-dev at python.org? We're not using the Support manager yet. --Guido van Rossum (home page: http://www.python.org/~guido/) From mhammond at skippinet.com.au Tue Jun 27 16:45:07 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Wed, 28 Jun 2000 00:45:07 +1000 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses wrapper.py,1.2,1.3 In-Reply-To: <20000627035202.M29590@lyra.org> Message-ID: > Besides its redundancy, it also places the traceback into a > local variable > and then raises an exception -- a perfect recipe for creating a ref loop. Isnt it true that _every_ time you store a traceback object as a local variable, and that traceback has a reference to the frame holding the local, you _always_ get a reference loop, regardless of how you exit the function? ie, I believe that _every_ time you store a traceback obtained from inside an except handler, you _always_ get a ref-loop, period. The only way to clean the cycle is to explictly unbind the local from the traceback. Mark. From mhammond at skippinet.com.au Tue Jun 27 16:39:15 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Wed, 28 Jun 2000 00:39:15 +1000 Subject: [Python-Dev] C# (new language from Microsoft) In-Reply-To: Message-ID: I cant say much, as I am still under NDA. However, I probably can say: * C Sharp is really not the interesting part of this technology. MS are controlling the way (the order, really) the information is coming out; as more info comes out, C Sharp should move back into perspective for what is really is. Suffice it to say, hardly anyone on slashdot is even in the ball-park! * The MS PDC in a couple of weeks will be the official announcement of the more interesting things. After this, everyone involved in the project will be completely free to discuss all they know, including me (and a few other Pythoneers) * Python has a very good and interesting story in all this - there is no need to be alarmed. If anything, be excited :-) Mark. > -----Original Message----- > From: python-dev-admin at python.org [mailto:python-dev-admin at python.org]On > Behalf Of Greg Wilson > Sent: Tuesday, 27 June 2000 8:31 PM > To: Python Developers > Subject: [Python-Dev] C# (new language from Microsoft) > > > I'm sure many of you will have seen this announcement already, but for > those who haven't, Microsoft is launching a new language to compete with > C, C++, and Java: > > http://msdn.microsoft.com/vstudio/nextgen/technology/csharpintro.asp > > Greg > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev > From paul at prescod.net Tue Jun 27 17:15:29 2000 From: paul at prescod.net (Paul Prescod) Date: Tue, 27 Jun 2000 08:15:29 -0700 Subject: [Python-Dev] winreg References: <019601bfe028$281dab90$4500a8c0@thomasnb> Message-ID: <3958C511.17282EF7@prescod.net> Mark, Thomas and whoever, thanks for your input and I hope you can spare some more... Thomas Heller wrote: > This is similar to what I have implemented... > ---------------------------------------------------------------------- > winreg - windows registry access module > > Exception: > error - raised when a function fails. Will contain > a windows error code and a textual description. As an aside, I notice that the winreg documentation says it will raise an EnvironmentError but it actually raises a WindowsError. > Objects: > regkey object - represents a open key in the > registry. Right. Even the same name. My stance was that keys would always be created from keys, so you would start with HKEY_LOCAL_MACHINE.CreateKey("Software\Python") That mirrors the underlying API a little closer and reduces the number of functions to 0. The question is whether the CreateKey and OpenKey functions are important enough as "convenience functions". > regkey object methods: > Standard Mapping protocol: > len (r) > r[k] > r[k] = x > del r[k] > r.clear() > r.has_key(k) > r.items() > r.keys() > r.update(dict) > r.values() > r.get(k[, x]) I had a separate object for values. I couldn't really justify elevating either the Subkeys or the Values. I tried to treat them as alike as possible. > todict() -> dictionary > Returns a dictionary mapping value names to values. I called this getValues() and it returned an object that was both a mapping and a sequence and allowed read/write/delete of values. > SubKeys () -> sequence > Returns a sequence containing the names of all subkeys. > > DeleteKey (name [,recursive=0]) > If recursive is 0, deletes the named key if no subkeys exist. > If there are subkeys an error is raised. > If recursive is not 0, the named key is deleted > including subkeys. I may or may not get around to implementing the recursive version. You have to be VERY CAREFUL when you test such a thing. :) > OpenKey (name) -> regkey object > Openes an existing subkey and returns a regkey > object pointing to it. Okay. > CreateKey (name) -> regkey object > Creates a new or openes an existing subkey and > returns a regkey object pointing to it. Okay. > regkey objects have the following properties: > name - the name of the RegistryKey, something > like "HKLM\Software\Python" Okay. > hkey - the integer keyhandle Is this really useful? Better to use the low-level API in that case... > If we change the name of the low level api module, we have to change > Distutils, > because it is used there. Maybe we would better use the high level api then, > but there is still this 1.5 compatibility using the win32api module. The high level could probably be made compatible with 1.5 like this: try: import _winreg except ImportError: import win32api winreg=win32api It would probably be good for DistUtils to use the high level API as soon as it is possible for testing purposes. I am considering doing away with the two enumeration interfaces. The cost/benefit of having two more objects is probably low. We can simplify the whole thing by just using methods on the regkey object: deleteValue(name) getValue(name)-> (type, value) setValue(name,(type,value)) getValueNames() -> List of strings getSubkey(name) -> regkey deleteSubkey(name) getSubkeyNames( ) -> List of strings Iterating will be slightly less efficient because it will loop twice, once to gather the names and once to do whatever you need to do but that's not the typical registry use case anyhow. Anyone who needs absolute performance can use the low-level API. Recursive iteration under the existing model: def doit( key ): for subkey in key.getSubkeyNames(): doit( subkey ) Recursive iteration under the proposed model: def doit( key ): for keyname in key.getSubkeyNames(): doit( key.getSubkey( name )) -- Paul Prescod - Not encumbered by corporate consensus When George Bush entered office, a Washington Post-ABC News poll found that 62 percent of Americans "would be willing to give up a few of the freedoms we have" for the war effort. They have gotten their wish. - "This is your bill of rights...on drugs", Harpers, Dec. 1999 From paul at prescod.net Tue Jun 27 17:28:55 2000 From: paul at prescod.net (Paul Prescod) Date: Tue, 27 Jun 2000 08:28:55 -0700 Subject: [Python-Dev] winreg features References: <019601bfe028$281dab90$4500a8c0@thomasnb> Message-ID: <3958C837.ECD925CC@prescod.net> There are a few features missing from the proposed API. I don't think that this API should serve the 80%, but rather the 97%. The only things I plan to exclude from the low level API are things that are undocumented and a little bit of performance. I see no reason not to add support for close, flush, save, remote keys and REG_FOO types. If I ever figure out how to use HIVE_VOLATILE_IS_TRUE I would add support for that too. :) -- Paul Prescod - Not encumbered by corporate consensus When George Bush entered office, a Washington Post-ABC News poll found that 62 percent of Americans "would be willing to give up a few of the freedoms we have" for the war effort. They have gotten their wish. - "This is your bill of rights...on drugs", Harpers, Dec. 1999 From paul at prescod.net Tue Jun 27 17:29:16 2000 From: paul at prescod.net (Paul Prescod) Date: Tue, 27 Jun 2000 08:29:16 -0700 Subject: [Python-Dev] winreg features References: <019601bfe028$281dab90$4500a8c0@thomasnb> Message-ID: <3958C84C.37C3EAD@prescod.net> There are a few features missing from the proposed API. I don't think that this API should serve the 80%, but rather the 97%. The only things I plan to exclude from the low level API are things that are undocumented and a little bit of performance. I want to simplify the API, not dumb it down. I see no reason not to add support for close, flush, save, remote keys and REG_FOO types. If I ever figure out how to use HIVE_VOLATILE_IS_TRUE I would add support for that too. :) -- Paul Prescod - Not encumbered by corporate consensus When George Bush entered office, a Washington Post-ABC News poll found that 62 percent of Americans "would be willing to give up a few of the freedoms we have" for the war effort. They have gotten their wish. - "This is your bill of rights...on drugs", Harpers, Dec. 1999 From thomas.heller at ion-tof.com Tue Jun 27 17:42:26 2000 From: thomas.heller at ion-tof.com (Thomas Heller) Date: Tue, 27 Jun 2000 17:42:26 +0200 Subject: [Python-Dev] winreg References: <019601bfe028$281dab90$4500a8c0@thomasnb> <3958C511.17282EF7@prescod.net> Message-ID: <02e201bfe04e$4cecc700$4500a8c0@thomasnb> (Hopefully it is ok to use the reply-all button) > ... > My stance was that keys would always be created from keys, so you would > start with > > HKEY_LOCAL_MACHINE.CreateKey("Software\Python") > > That mirrors the underlying API a little closer and reduces the number > of functions to 0. Good idea! Maybe HKLM and so on should be provided as aliases. > > > > DeleteKey (name [,recursive=0]) > > If recursive is 0, deletes the named key if no subkeys exist. > > If there are subkeys an error is raised. > > If recursive is not 0, the named key is deleted > > including subkeys. > > I may or may not get around to implementing the recursive version. You > have to be VERY CAREFUL when you test such a thing. :) Someone (I don't remember who) mentioned in the discussion about my proposal that one should use SHDeleteKey for recursive deletion of keys. See the MSDN docs on RegDeleteKey for details. Don't know if this is exposed by the lowlevel module. > > > If we change the name of the low level api module, we have to change > > Distutils, > > because it is used there. Maybe we would better use the high level api then, > > but there is still this 1.5 compatibility using the win32api module. > > The high level could probably be made compatible with 1.5 like this: > > try: > import _winreg > except ImportError: > import win32api > winreg=win32api Currently it goes like this, because win32api and winreg (which will soon be _winreg) have slightly different apis, but it will doubtlessly be solved: try: import winreg _can_read_reg = 1 hkey_mod = winreg RegOpenKeyEx = winreg.OpenKeyEx RegEnumKey = winreg.EnumKey RegEnumValue = winreg.EnumValue RegError = winreg.error except ImportError: try: import win32api import win32con _can_read_reg = 1 hkey_mod = win32con RegOpenKeyEx = win32api.RegOpenKeyEx RegEnumKey = win32api.RegEnumKey RegEnumValue = win32api.RegEnumValue RegError = win32api.error except ImportError: pass Thomas From paul at prescod.net Tue Jun 27 17:52:27 2000 From: paul at prescod.net (Paul Prescod) Date: Tue, 27 Jun 2000 08:52:27 -0700 Subject: [Python-Dev] winreg References: <019601bfe028$281dab90$4500a8c0@thomasnb> <3958C511.17282EF7@prescod.net> <02e201bfe04e$4cecc700$4500a8c0@thomasnb> Message-ID: <3958CDBB.3F354C97@prescod.net> Right now the Python list is a little slow (at least for me) so I appreciate cc:s directly to me. Thomas Heller wrote: > > Good idea! > Maybe HKLM and so on should be provided as aliases. Sure. > Someone (I don't remember who) mentioned in the discussion > about my proposal that one should use SHDeleteKey for recursive > deletion of keys. See the MSDN docs on RegDeleteKey for details. > Don't know if this is exposed by the lowlevel module. Don't think so. > Currently it goes like this, because win32api and winreg (which > will soon be _winreg) have slightly different apis, but it will > doubtlessly be solved: Ouch. I don't know if I have time to figure out all of the correspondances. Are the only differences those four method names or are those the only four differences that DistUtils happened to care about. I'm not interested in 1.5 compatibility if it will take a lot of work. -- Paul Prescod - Not encumbered by corporate consensus When George Bush entered office, a Washington Post-ABC News poll found that 62 percent of Americans "would be willing to give up a few of the freedoms we have" for the war effort. They have gotten their wish. - "This is your bill of rights...on drugs", Harpers, Dec. 1999 From thomas.heller at ion-tof.com Tue Jun 27 18:03:30 2000 From: thomas.heller at ion-tof.com (Thomas Heller) Date: Tue, 27 Jun 2000 18:03:30 +0200 Subject: [Python-Dev] winreg References: <019601bfe028$281dab90$4500a8c0@thomasnb> <3958C511.17282EF7@prescod.net> <02e201bfe04e$4cecc700$4500a8c0@thomasnb> <3958CDBB.3F354C97@prescod.net> Message-ID: <02fe01bfe051$3df655b0$4500a8c0@thomasnb> > Right now the Python list is a little slow (at least for me) so I > appreciate cc:s directly to me. Same for me: All python lists take hours to distribute the mails. > > Someone (I don't remember who) mentioned in the discussion > > about my proposal that one should use SHDeleteKey for recursive > > deletion of keys. See the MSDN docs on RegDeleteKey for details. > > Don't know if this is exposed by the lowlevel module. > > Don't think so. The tricky thing is: Deletion of keys behaves differently on Win95/98 and NT/2000. (Quoting MSDN:) The RegDeleteKey function deletes a subkey. Windows 95/98: The function also deletes all subkeys and values. To delete a key only if the key has no subkeys or values, use the SHDeleteEmptyKey function. Windows NT/2000: The subkey to be deleted must not have subkeys. To delete a key and all its subkeys, you need to recursively enumerate the subkeys and delete them individually. To recursively delete keys, use the SHDeleteKey function. (end quote) The SHDelete* funtions require version 4.71 of shlwapi.dll, which is included in Win98 or 2000 (or in IE 4.0). > > > Currently it goes like this, because win32api and winreg (which > > will soon be _winreg) have slightly different apis, but it will > > doubtlessly be solved: > > Ouch. I don't know if I have time to figure out all of the > correspondances. Are the only differences those four method names or are > those the only four differences that DistUtils happened to care about. > I'm not interested in 1.5 compatibility if it will take a lot of work. So you should simply ignore this. We will work it out on distutils. Thomas (I will disappear soon for holidays) From Vladimir.Marangozov at inrialpes.fr Tue Jun 27 18:23:52 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Tue, 27 Jun 2000 18:23:52 +0200 (CEST) Subject: [Python-Dev] ANN: Release schedule In-Reply-To: <200006270235.VAA02631@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Jun 26, 2000 09:35:52 PM Message-ID: <200006271623.SAA04926@python.inrialpes.fr> Guido van Rossum wrote: > > Here at BeOpen we're scrambling to get the release schedule for the > rest of Python 1.6 planned. We're now looking at releasing Python > 1.6b1 (or maybe it's going to be called 1.6a3 after all) on June 30! > This means that if SRE isn't ready, we'll go with an incomplete SRE. > Still better than no SRE! > > Please, PLEASE, if you have pending patches that you think should go > into 1.6b1, submit them to SourceForge. We'll do our best to have a > look at every patch submitted; but don't wait until the last moment. So, to sum up (because I'm a bit lost after all this patch-related messages), what should I do to avoid at best adding to the collective burden : 1. Should I send patches to SF and be quiet until June 30 ? 2. Should I apply for privileges and spend installing an SSH client on my box (illegal in France ;), then make my Python way into the SF galaxy ? 3. If I volunteer for help with the patches backlog, what do I do ? 4. Other options presented to me ? Context : I (will) have some patches lying around, there are some patches of mine on the pile sent to patches at python.org that I'm confident about, I have read the FAQ at SF which gave me 0 clues on how things are being set up there (only general info about who why and what for + terms of service), and I managed to create an account with a personal page containing two bookmarks in it (after being distracted with personal and project ratings + gobs of links to gobs of stuff). -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From guido at beopen.com Tue Jun 27 19:27:24 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 27 Jun 2000 12:27:24 -0500 Subject: [Python-Dev] ANN: Release schedule In-Reply-To: Your message of "Tue, 27 Jun 2000 18:23:52 +0200." <200006271623.SAA04926@python.inrialpes.fr> References: <200006271623.SAA04926@python.inrialpes.fr> Message-ID: <200006271727.MAA03564@cj20424-a.reston1.va.home.com> > 1. Should I send patches to SF and be quiet until June 30 ? Yes. Not too quiet -- helping selecting which old patches are good would help. Also downloading patches from SF and commenting on them (+1/-1) in the patches list would help. > 2. Should I apply for privileges and spend installing > an SSH client on my box (illegal in France ;), then make my Python > way into the SF galaxy ? Probably no. > 3. If I volunteer for help with the patches backlog, what do I do ? Go through the patches archives and review patches. If you find one for which you would vote +1 and which you think I might like, submit it to SF. > 4. Other options presented to me ? > > Context : I (will) have some patches lying around, there are some > patches of mine on the pile sent to patches at python.org that I'm > confident about, I have read the FAQ at SF which gave me 0 clues > on how things are being set up there (only general info about > who why and what for + terms of service), and I managed to create > an account with a personal page containing two bookmarks in it > (after being distracted with personal and project ratings + gobs of > links to gobs of stuff). Go to the Python Project Summary, then to the Patch Manager. At the top, click on Submit Patch. --Guido van Rossum (home page: http://www.python.org/~guido/) From mal at lemburg.com Tue Jun 27 18:38:54 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue, 27 Jun 2000 18:38:54 +0200 Subject: [Python-Dev] SF patch manager... Message-ID: <3958D89E.39D084C8@lemburg.com> [Please excuse my ranting... :-)] I've received the first round of notification message from the patch manager and can't really say that I like them. Ok, I understand that the patch manager is still alpha or beta software, but these messages really don't have any usable content at all: """ Patch #100646 has been updated. Visit SourceForge.net for more info. http://sourceforge.net/patch/?func=detailpatch&patch_id=100646&group_id=5470 """ Also, reviewing the patches has become a pain and discussing them is nearly impossible (I don't consider the slashdot like comment mechanism to be of any use: there's simply no audience for discussion). Is there any chance of tee'ing patches from SF to the patches list or some other patch discussion and review forum ? I do understand that the mechanism can help with patch *checkins*, but it's certainly not going to help much with the discussion step needed before conidering any actions. The independent peer review principal doesn't work with this kind of setup. Ok, enough whining, let's get on with business now ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From esr at thyrsus.com Tue Jun 27 18:50:53 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Tue, 27 Jun 2000 12:50:53 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses wrapper.py,1.2,1.3 In-Reply-To: <20000627035202.M29590@lyra.org>; from gstein@lyra.org on Tue, Jun 27, 2000 at 03:52:02AM -0700 References: <200006270050.RAA26210@slayer.i.sourceforge.net> <20000627035202.M29590@lyra.org> Message-ID: <20000627125053.B6531@thyrsus.com> Greg Stein : > I just don't buy this. > > Look at that code. Look at the definition of finally. That code simply > screams for the use of finally. > > Eric: just what happens? What is "broke things"? Do you have a reproducible > test case that I can use? What happened is that your version failed to pass an error exception upwards after fielding it. My test case was a buggy version of cmlconfigure.py, bug since fixed. Cleanliness is good, but the code has to work first. -- Eric S. Raymond Faith may be defined briefly as an illogical belief in the occurrence of the improbable...A man full of faith is simply one who has lost (or never had) the capacity for clear and realistic thought. He is not a mere ass: he is actually ill. -- H. L. Mencken From trentm at activestate.com Tue Jun 27 18:46:58 2000 From: trentm at activestate.com (Trent Mick) Date: Tue, 27 Jun 2000 09:46:58 -0700 Subject: [Python-Dev] ANN: Release schedule In-Reply-To: <200006270235.VAA02631@cj20424-a.reston1.va.home.com> References: <200006270235.VAA02631@cj20424-a.reston1.va.home.com> Message-ID: <20000627094658.B7257@activestate.com> On Mon, Jun 26, 2000 at 09:35:52PM -0500, Guido van Rossum wrote: > (Trent Mick, it would be helpful if you assigned each of your patches > a potential reviewer from the list of existing developers -- that way > we can split up the review load.) > Do you mean I should reassigned patch-reviewing over and above the assignments that you have done recently? I was just going to put up twenty more patches and assign them all to Tim as well. :) Kidding. If, "yes", then I will make a go at that today. BTW I have answered a couple a questions on my patches. Does the person to whom the patch is assigned get an update notification? Trent -- Trent Mick trentm at activestate.com From trentm at activestate.com Tue Jun 27 18:57:38 2000 From: trentm at activestate.com (Trent Mick) Date: Tue, 27 Jun 2000 09:57:38 -0700 Subject: [Python-Dev] testing the Python/C API (was: Re: [Patches] PyObject_GetAttr/PyObject_SetAttr core dumps if given non-string names) In-Reply-To: <14679.36964.766774.864078@localhost.localdomain> References: <20000622193610.27452.qmail@eik.g.aas.no> <395272D0.B82A0353@lemburg.com> <39531A20.1BEAA51E@lemburg.com> <14675.30233.658776.764865@localhost.localdomain> <14679.36964.766774.864078@localhost.localdomain> Message-ID: <20000627095738.D7257@activestate.com> On Mon, Jun 26, 2000 at 01:18:28PM -0400, Jeremy Hylton wrote: > Ok. I was looking for a test case to include in the test suite. I've > made the change, but it looks like it will have to go without an > accompanying test. I asked the question a while back if it would reasonable/useful/popular to have a mechanism where parts of the Python/C Api could be tested directly. My proposal used an extension module _testmodule (although I made it a core module on UN*X it should not bog down the core) which exported a bunch o' test_* routines that tested specific parts of the Python/C API. A test_internal.py module would be added to the std regression test suite that would import this module and call each of the exported test_* routines in turn. This would allow things like the _GetAttr/_SetAttr behaviour to be tested. Anybody have any opinions? Trent p.s. I have a patch largely (all except the above menntion limitation) ready for this, including some tests that I used for my 64-bit porting stuff. -- Trent Mick trentm at activestate.com From skip at mojam.com Tue Jun 27 19:11:33 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 27 Jun 2000 12:11:33 -0500 (CDT) Subject: [Python-Dev] semi-subtle atexit gotcha? Message-ID: <14680.57413.385666.482385@beluga.mojam.com> In thinking about the new atexit module a little more, it occurred to me that I've handled the case where the atexit module gets loaded after another module that wants to set sys.exitfunc (it just incorporates that function into its list of functions), but not if atexit gets loaded before another modules that uses sys.exitfunc. I see two possible choices: 1. Punt and put a bit of verbiage in the atexit section of the library reference manual and the 1.6 release notes. 2. Have atexit.register check each time it's called to see if sys.exitfunc is what it expects. This isn't a perfect solution for a couple reasons. One, there's no guarantee that other sys.exitfunc- modifying code isn't executed after the last call to atexit.register. Two, there's no guarantee that the other code doesn't attempt to be "intelligent" in a fashion similar to atexit (can you say dueling banjos?). I vote for option number one since there appears to be no guaranteed way to make it work, but I'm open to other suggestions. -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille O'Neal said: "He's got the rings. I listen to the man with the rings." From trentm at activestate.com Tue Jun 27 19:16:58 2000 From: trentm at activestate.com (Trent Mick) Date: Tue, 27 Jun 2000 10:16:58 -0700 Subject: [Python-Dev] Re: [Patches] Let's use the SourceForge Patch Manager In-Reply-To: References: <200006261449.JAA01684@cj20424-a.reston1.va.home.com> Message-ID: <20000627101658.E7257@activestate.com> On Mon, Jun 26, 2000 at 02:41:12PM -0400, Tim Peters wrote: > Intended use of SourceForge patch status tags > --------------------------------------------- > revision 1 26-Jun-2000 > > > Open > The initial status of all patches. > The patch is under consideration, but has not > been reviewed yet. > The status will normally change to Accepted or Rejected next. > The person submitting the patch should (if they can) assign > it to the person they most want to review it. > Else the patch will be assigned via > [xxx a list of expertise areas should be developed] What are the chances of getting other meta data fields on patches, i.e. changes to the patch manager? Categorizing patches could really help as a filter. For instance, I may be a Unicode genius and would like to see the patches associated with it. > Discussion of patches is carried out via > [xxx Python-Dev? patches list? without a mail gateway, > the SourceForge patch interface looks too clumsy > to use for controversial patches] I like the separation of python-dev and patches, but it is not a biggie for me. > Postponed > The previous status was Open or Accepted, but for some reason > (e.g., pending release) the patch should not be reviewed or > applied until further notice. > The status will normally change to Open or Accepted next. > Please enter a comment when changing the status to Postponed, > to record the reason, the previous status, and the conditions > under which the patch should revert to Open or Accepted. Perhaps ownership (i.e. 'assigned to') of the patch should transfer to the person responsible for later taking to patch out of 'postponed' status. Trent -- Trent Mick trentm at activestate.com From jeremy at beopen.com Tue Jun 27 19:21:28 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Tue, 27 Jun 2000 13:21:28 -0400 (EDT) Subject: [Python-Dev] Re: testing the Python/C API (was: Re: [Patches] PyObject_GetAttr/PyObject_SetAttr core dumps if given non-string names) In-Reply-To: <20000627095738.D7257@activestate.com> References: <20000622193610.27452.qmail@eik.g.aas.no> <395272D0.B82A0353@lemburg.com> <39531A20.1BEAA51E@lemburg.com> <14675.30233.658776.764865@localhost.localdomain> <14679.36964.766774.864078@localhost.localdomain> <20000627095738.D7257@activestate.com> Message-ID: <14680.58008.466802.160183@bitdiddle.concentric.com> I think testing the C API directly is a great idea! Sorry I missed it the first time around. I don't think I understand the suggested approach well enough to critique it. Most of the tests need to be written in C, right? When an error is encountered, it seems that you should check what the C API returns *and* what happens at the Python level, i.e. whether the call sets a Python exception (or clears an existing Python exception). I guess you ought to show us the code. I don't think it will go in Python 1.6, but it sounds like a valuable component for future releases. Jeremy From trentm at activestate.com Tue Jun 27 19:37:00 2000 From: trentm at activestate.com (Trent Mick) Date: Tue, 27 Jun 2000 10:37:00 -0700 Subject: [Python-Dev] Re: testing the Python/C API (was: Re: [Patches] PyObject_GetAttr/PyObject_SetAttr core dumps if given non-string names) In-Reply-To: <14680.58008.466802.160183@bitdiddle.concentric.com> References: <20000622193610.27452.qmail@eik.g.aas.no> <395272D0.B82A0353@lemburg.com> <39531A20.1BEAA51E@lemburg.com> <14675.30233.658776.764865@localhost.localdomain> <14679.36964.766774.864078@localhost.localdomain> <20000627095738.D7257@activestate.com> <14680.58008.466802.160183@bitdiddle.concentric.com> Message-ID: <20000627103700.G7257@activestate.com> On Tue, Jun 27, 2000 at 01:21:28PM -0400, Jeremy Hylton wrote: > > I don't think I understand the suggested approach well enough to > critique it. Most of the tests need to be written in C, right? When All of the testing code would be in C, in the _testmodule.c, or whatever name. > an error is encountered, it seems that you should check what the C API > returns *and* what happens at the Python level, i.e. whether the call > sets a Python exception (or clears an existing Python exception). Yes you are right. It depends on the API under test. Basically you just try to test all conditions to ensure that the API behaves as expected/advertised. > > I guess you ought to show us the code. I don't think it will go in > Python 1.6, but it sounds like a valuable component for future > releases. > Okay. I agree that this would probably not make 1.6 so I will probably wait on this for a little while. Busy. Trent -- Trent Mick trentm at activestate.com From trentm at activestate.com Tue Jun 27 19:56:47 2000 From: trentm at activestate.com (Trent Mick) Date: Tue, 27 Jun 2000 10:56:47 -0700 Subject: [Python-Dev] my dev status on SourceForge In-Reply-To: <200006271430.JAA01769@cj20424-a.reston1.va.home.com> References: <200006271430.JAA01769@cj20424-a.reston1.va.home.com> Message-ID: <20000627105647.H7257@activestate.com> SPeaking of surprising little SourceForge things: I just made the mistake of clicking on the little garbage can beside "Python" in "My Projects". I seem to have booted myself from the Python project. Can I put myself back on? or can one of you with admin status please do that for me? my SourceForge username is: tmick Sorry and thanks, Trent -- Trent Mick trentm at activestate.com From akuchlin at mems-exchange.org Tue Jun 27 20:20:21 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Tue, 27 Jun 2000 14:20:21 -0400 Subject: [Python-Dev] curses/wrapper.py In-Reply-To: References: <20000627035202.M29590@lyra.org> Message-ID: <20000627142021.G19033@kronos.cnri.reston.va.us> On Wed, Jun 28, 2000 at 12:45:07AM +1000, Mark Hammond quoted: >> Besides its redundancy, it also places the traceback into a >> local variable >> and then raises an exception -- a perfect recipe for creating a ref loop. I think this is irrelevant for the curses.wrapper() function, which simply restores the terminal state before re-raising the exception. It probably won't ever be called repeatedly, making the question of a memory leak moot. Yes, I'd like to have wrapper() use Greg Stein's simpler and tidier code. Yes, I'd like to know why ESR claims the simpler version doesn't work and have a replicable test case. But right now there are higher priority things to do, so I'm shelving this until after 1.6b1. (Right now I'm trying to get the curses module compiling on Tru64, and things don't look good.) --amk From pingster at ilm.com Tue Jun 27 20:25:01 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Tue, 27 Jun 2000 11:25:01 -0700 (PDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses ascii.py,NONE,1.1 textpad.py,NONE,1.1 In-Reply-To: <14680.29842.372192.274003@temoleh.chem.uu.nl> Message-ID: On Tue, 27 Jun 2000, Rob W. W. Hooft wrote: > AMK> --- NEW FILE --- > AMK> # > AMK> # ascii.py -- constants and memembership tests for ASCII characters > AMK> # > ^^^^^ two letters too much? Grrrr... surely by now we should be getting docstrings instead of comments at the top of modules! In keeping with the format of most other modules, i also suggest not repeating the module name. Thus: """Constants and membership tests for ASCII characters.""" -- ?!ng (166 irender improvements since May 1999) From Vladimir.Marangozov at inrialpes.fr Tue Jun 27 20:39:35 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Tue, 27 Jun 2000 20:39:35 +0200 (CEST) Subject: [Python-Dev] ANN: Release schedule In-Reply-To: from "Vladimir Marangozov" at Jun 27, 2000 06:23:52 PM Message-ID: <200006271839.UAA05354@python.inrialpes.fr> I'm resending this msg since it didn't seem to get through the 1st time (and we're experiencing some major hw&sw router problems lately) Vladimir Marangozov wrote: > > Guido van Rossum wrote: > > > > Here at BeOpen we're scrambling to get the release schedule for the > > rest of Python 1.6 planned. We're now looking at releasing Python > > 1.6b1 (or maybe it's going to be called 1.6a3 after all) on June 30! > > This means that if SRE isn't ready, we'll go with an incomplete SRE. > > Still better than no SRE! > > > > Please, PLEASE, if you have pending patches that you think should go > > into 1.6b1, submit them to SourceForge. We'll do our best to have a > > look at every patch submitted; but don't wait until the last moment. > > So, to sum up (because I'm a bit lost after all this patch-related > messages), what should I do to avoid at best adding to the collective > burden : > > 1. Should I send patches to SF and be quiet until June 30 ? > > 2. Should I apply for privileges and spend installing > an SSH client on my box (illegal in France ;), then make my Python > way into the SF galaxy ? > > 3. If I volunteer for help with the patches backlog, what do I do ? > > 4. Other options presented to me ? > > Context : I (will) have some patches lying around, there are some > patches of mine on the pile sent to patches at python.org that I'm > confident about, I have read the FAQ at SF which gave me 0 clues > on how things are being set up there (only general info about > who why and what for + terms of service), and I managed to create > an account with a personal page containing two bookmarks in it > (after being distracted with personal and project ratings + gobs of > links to gobs of stuff). > > -- > Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr > http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 > -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From paul at prescod.net Tue Jun 27 20:46:40 2000 From: paul at prescod.net (Paul Prescod) Date: Tue, 27 Jun 2000 11:46:40 -0700 Subject: [Python-Dev] winreg References: <019601bfe028$281dab90$4500a8c0@thomasnb> <3958C511.17282EF7@prescod.net> <02e201bfe04e$4cecc700$4500a8c0@thomasnb> <3958CDBB.3F354C97@prescod.net> <02fe01bfe051$3df655b0$4500a8c0@thomasnb> Message-ID: <3958F690.EDB27D07@prescod.net> I'm trying to figure out all of the constants in _winreg. Some of them seem related to functions that _winreg doesn't support. I won't put those in new winreg because they can't be used. The only one I can't figure out through web searches is REG_OPTION_OPEN_LINK. RegNotifyChangeKeyValue (unsupported) REG_NOTIFY_CHANGE_NAME REG_NOTIFY_CHANGE_LAST_SET REG_NOTIFY_CHANGE_SECURITY REG_NOTIFY_CHANGE_ATTRIBUTES RegRestoreKey (unsupported) REG_FORCE_RESTORE REG_NO_LAZY_FLUSH REG_REFRESH_HIVE REG_WHOLE_HIVE_VOLATILE RegCreateKeyEx (unxupported) REG_OPTION_RESERVED REG_OPTION_VOLATILE REG_OPTION_NON_VOLATILE REG_OPTION_BACKUP_RESTORE REG_CREATED_NEW_KEY REG_OPENED_EXISTING_KEY REG_OPTION_CREATE_LINK I presume that nobody intends to add these three functions to _winreg in time for Python 1.6! -- Paul Prescod - Not encumbered by corporate consensus When George Bush entered office, a Washington Post-ABC News poll found that 62 percent of Americans "would be willing to give up a few of the freedoms we have" for the war effort. They have gotten their wish. - "This is your bill of rights...on drugs", Harpers, Dec. 1999 From effbot at telia.com Tue Jun 27 21:25:23 2000 From: effbot at telia.com (Fredrik Lundh) Date: Tue, 27 Jun 2000 21:25:23 +0200 Subject: [Python-Dev] CVS: python/dist/src/Lib/curses wrapper.py,1.2,1.3 References: <200006270050.RAA26210@slayer.i.sourceforge.net> <20000627035202.M29590@lyra.org> <20000627125053.B6531@thyrsus.com> Message-ID: <001f01bfe06d$753492a0$f2a6b5d4@hagrid> Eric S. Raymond wrote: > What happened is that your version failed to pass an error exception upwards > after fielding it. My test case was a buggy version of cmlconfigure.py, bug > since fixed. > > Cleanliness is good, but the code has to work first. umm. as far as I can tell from the patch, there's no way your code can work in a situation where try/finally wouldn't do exactly the same thing. if you *do* get different results (try inserting "raise whatever" in the try clause to test this), it might be that you've stumbled upon a real bug (either in Python or in the curses C bindings)... From guido at beopen.com Tue Jun 27 22:25:49 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 27 Jun 2000 15:25:49 -0500 Subject: [Python-Dev] Re: my dev status on SourceForge In-Reply-To: Your message of "Tue, 27 Jun 2000 10:56:47 MST." <20000627105647.H7257@activestate.com> References: <200006271430.JAA01769@cj20424-a.reston1.va.home.com> <20000627105647.H7257@activestate.com> Message-ID: <200006272025.PAA04010@cj20424-a.reston1.va.home.com> > SPeaking of surprising little SourceForge things: > > I just made the mistake of clicking on the little garbage can beside "Python" > in "My Projects". I seem to have booted myself from the Python project. Can I > put myself back on? or can one of you with admin status please do that for > me? > > my SourceForge username is: tmick OK, you're back! --Guido van Rossum (home page: http://www.python.org/~guido/) From pingster at ilm.com Tue Jun 27 21:38:15 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Tue, 27 Jun 2000 12:38:15 -0700 (PDT) Subject: [Python-Dev] SF patch manager... In-Reply-To: <3958D89E.39D084C8@lemburg.com> Message-ID: On Tue, 27 Jun 2000, M.-A. Lemburg wrote: > I've received the first round of notification message from the > patch manager and can't really say that I like them. I wish i could propose Roundup, but it currently lacks the ability to decode e-mail attachments. Aside from that, it has reasonable (if basic) e-mail handling, colour-coded status and priorities, and so on. I would jump on it in a second except that the Software Carpentry deadline is also this Friday and i'm still barely pulling that thing together. Of course, if you feel like hacking it up to do attachments feel free to get it at http://pingster.com/roundup.html and hack away! Alternatively i suppose you could keep the patch files on SourceForge and do the discussions in Roundup as an interim solution? Messy, i know, but it might be an improvement. -- ?!ng From paul at prescod.net Tue Jun 27 21:45:16 2000 From: paul at prescod.net (Paul Prescod) Date: Tue, 27 Jun 2000 12:45:16 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/curses ascii.py,NONE,1.1 textpad.py,NONE,1.1 References: Message-ID: <3959044C.B5C537FA@prescod.net> Ka-Ping Yee wrote: > > -- ?!ng > > (166 irender improvements since May 1999) > Although some shots were composited with Sabre, ILM's extensions > to Discreet Logic's Flame and Inferno software, CompTime was > the compositing tool for the CG department, according to > Jeff Yost. First used for one shot in Saving Private Ryan, > CompTime is based on the studio's long-time scripted system, but > now boasts a graphical user interface and hooks for plug-ins that > can be written in Python or C++. Is it safe to say that "Without Python, Saving Private Ryan would not have been possible, much less an Oscar winner?" -- Paul Prescod - Not encumbered by corporate consensus When George Bush entered office, a Washington Post-ABC News poll found that 62 percent of Americans "would be willing to give up a few of the freedoms we have" for the war effort. They have gotten their wish. - "This is your bill of rights...on drugs", Harpers, Dec. 1999 From effbot at telia.com Tue Jun 27 22:01:26 2000 From: effbot at telia.com (Fredrik Lundh) Date: Tue, 27 Jun 2000 22:01:26 +0200 Subject: [Python-Dev] Re: testing the Python/C API References: <20000622193610.27452.qmail@eik.g.aas.no> <395272D0.B82A0353@lemburg.com> <39531A20.1BEAA51E@lemburg.com> <14675.30233.658776.764865@localhost.localdomain> <14679.36964.766774.864078@localhost.localdomain> <20000627095738.D7257@activestate.com> <14680.58008.466802.160183@bitdiddle.concentric.com> <20000627103700.G7257@activestate.com> Message-ID: <006801bfe072$7abc0820$f2a6b5d4@hagrid> trent wrote: > > I don't think I understand the suggested approach well enough to > > critique it. Most of the tests need to be written in C, right? When > > All of the testing code would be in C, in the _testmodule.c, or whatever > name. SWIG, anyone? From effbot at telia.com Tue Jun 27 22:06:30 2000 From: effbot at telia.com (Fredrik Lundh) Date: Tue, 27 Jun 2000 22:06:30 +0200 Subject: [Python-Dev] SF patch manager... References: <3958D89E.39D084C8@lemburg.com> Message-ID: <007801bfe073$3008b0c0$f2a6b5d4@hagrid> mal wrote: > I've received the first round of notification message from the > patch manager and can't really say that I like them. Ok, I > understand that the patch manager is still alpha or beta software, > but these messages really don't have any usable content at all: > > """ > Patch #100646 has been updated. > Visit SourceForge.net for more info. > > http://sourceforge.net/patch/?func=detailpatch&patch_id=100646&group_id=5470 > """ > > Also, reviewing the patches has become a pain and discussing them > is nearly impossible (I don't consider the slashdot like comment > mechanism to be of any use: there's simply no audience for > discussion). > > Is there any chance of tee'ing patches from SF to the patches > list or some other patch discussion and review forum ? I do > understand that the mechanism can help with patch *checkins*, > but it's certainly not going to help much with the discussion > step needed before conidering any actions. The independent > peer review principal doesn't work with this kind of setup. I fully agree. someone really needs to fuse the patch manager with roundup (that we should use roundup for bug tracking goes without saying...) how much work would it be to move the entire repository over to pythonlabs, btw? sourceforget is frustratingly slow... From guido at beopen.com Tue Jun 27 23:07:41 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 27 Jun 2000 16:07:41 -0500 Subject: [Python-Dev] testing the Python/C API (was: Re: [Patches] PyObject_GetAttr/PyObject_SetAttr core dumps if given non-string names) In-Reply-To: Your message of "Tue, 27 Jun 2000 09:57:38 MST." <20000627095738.D7257@activestate.com> References: <20000622193610.27452.qmail@eik.g.aas.no> <395272D0.B82A0353@lemburg.com> <39531A20.1BEAA51E@lemburg.com> <14675.30233.658776.764865@localhost.localdomain> <14679.36964.766774.864078@localhost.localdomain> <20000627095738.D7257@activestate.com> Message-ID: <200006272107.QAA04498@cj20424-a.reston1.va.home.com> > I asked the question a while back if it would reasonable/useful/popular to > have a mechanism where parts of the Python/C Api could be tested directly. > > My proposal used an extension module _testmodule (although I made it a core > module on UN*X it should not bog down the core) which exported a bunch o' > test_* routines that tested specific parts of the Python/C API. A > test_internal.py module would be added to the std regression test suite that > would import this module and call each of the exported test_* routines in > turn. This would allow things like the _GetAttr/_SetAttr behaviour to be tested. > > Anybody have any opinions? > > > Trent > > p.s. I have a patch largely (all except the above menntion limitation) ready > for this, including some tests that I used for my 64-bit porting stuff. Great idea. Please wait for 1.7. There *will* be releases after 1.6! --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at beopen.com Tue Jun 27 23:08:42 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 27 Jun 2000 16:08:42 -0500 Subject: [Python-Dev] semi-subtle atexit gotcha? In-Reply-To: Your message of "Tue, 27 Jun 2000 12:11:33 EST." <14680.57413.385666.482385@beluga.mojam.com> References: <14680.57413.385666.482385@beluga.mojam.com> Message-ID: <200006272108.QAA04509@cj20424-a.reston1.va.home.com> > In thinking about the new atexit module a little more, it occurred to me > that I've handled the case where the atexit module gets loaded after another > module that wants to set sys.exitfunc (it just incorporates that function > into its list of functions), but not if atexit gets loaded before another > modules that uses sys.exitfunc. I see two possible choices: > > 1. Punt and put a bit of verbiage in the atexit section of the library > reference manual and the 1.6 release notes. > > 2. Have atexit.register check each time it's called to see if > sys.exitfunc is what it expects. This isn't a perfect solution for a > couple reasons. One, there's no guarantee that other sys.exitfunc- > modifying code isn't executed after the last call to > atexit.register. Two, there's no guarantee that the other code > doesn't attempt to be "intelligent" in a fashion similar to atexit > (can you say dueling banjos?). > > I vote for option number one since there appears to be no guaranteed way to > make it work, but I'm open to other suggestions. Yes, #1 is good enough. I don't think there will be lots of people bitten by this... --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at beopen.com Tue Jun 27 23:11:46 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 27 Jun 2000 16:11:46 -0500 Subject: [Python-Dev] Re: [Patches] Let's use the SourceForge Patch Manager In-Reply-To: Your message of "Tue, 27 Jun 2000 10:16:58 MST." <20000627101658.E7257@activestate.com> References: <200006261449.JAA01684@cj20424-a.reston1.va.home.com> <20000627101658.E7257@activestate.com> Message-ID: <200006272111.QAA04542@cj20424-a.reston1.va.home.com> > What are the chances of getting other meta data fields on patches, i.e. > changes to the patch manager? Categorizing patches could really help as a > filter. For instance, I may be a Unicode genius and would like to see the > patches associated with it. Good idea. The PM clearly needs work. I see two places where you could submit feature requests: (1) the "Report SF Bug" item in the left side bar; (2) the "Feature Requests" discussion forum (http://sourceforge.net/forum/forum.php?forum_id=4&et=0) > I like the separation of python-dev and patches, but it is not a biggie for > me. For me it's just an annoyance, especially when cross-posting is used. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at beopen.com Tue Jun 27 23:36:57 2000 From: guido at beopen.com (Guido van Rossum) Date: Tue, 27 Jun 2000 16:36:57 -0500 Subject: [Python-Dev] python.org mail unclogged Message-ID: <200006272136.QAA04723@cj20424-a.reston1.va.home.com> It seems we've removed a major source of email cloggage on python.org -- a site in France was hitting every page in the mailman membership administration using a commercial crawler (Teleport Pro) that didn't honor our robots.txt file, and forking a 4 Mb CGI script for each user in each mailing list. Thanks for Barry and Andrew! This was on top of problems caused when the Ultraseek crawler ran out of memory and caused postfix or mailman to fail. :-( Mail seems to be flowing again, the queues are emptying. Once we're happy, we'll turn on the Ultraseek crawler and search service. --Guido van Rossum (home page: http://www.python.org/~guido/) From jeremy at beopen.com Tue Jun 27 22:54:38 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Tue, 27 Jun 2000 16:54:38 -0400 (EDT) Subject: [Python-Dev] SF patch manager... In-Reply-To: References: <3958D89E.39D084C8@lemburg.com> Message-ID: <14681.5262.464079.557095@bitdiddle.concentric.com> Maybe the right solution is to work with the SourceForge maintainers to make roundup part of the standard support software. jeremy From fdrake at beopen.com Tue Jun 27 23:01:54 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Tue, 27 Jun 2000 17:01:54 -0400 (EDT) Subject: [Python-Dev] Re: [Patches] Let's use the SourceForge Patch Manager In-Reply-To: <20000627101658.E7257@activestate.com> References: <200006261449.JAA01684@cj20424-a.reston1.va.home.com> <20000627101658.E7257@activestate.com> Message-ID: <14681.5698.732269.523890@cj42289-a.reston1.va.home.com> Trent Mick writes: > Perhaps ownership (i.e. 'assigned to') of the patch should transfer to the > person responsible for later taking to patch out of 'postponed' status. Agreed; assignment should be changed whenever the next person required to deal with it changes. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From nascheme at enme.ucalgary.ca Tue Jun 27 23:05:55 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Tue, 27 Jun 2000 15:05:55 -0600 Subject: [Python-Dev] SF patch manager... In-Reply-To: <007801bfe073$3008b0c0$f2a6b5d4@hagrid>; from effbot@telia.com on Tue, Jun 27, 2000 at 10:06:30PM +0200 References: <3958D89E.39D084C8@lemburg.com> <007801bfe073$3008b0c0$f2a6b5d4@hagrid> Message-ID: <20000627150555.A3083@acs.ucalgary.ca> On Tue, Jun 27, 2000 at 10:06:30PM +0200, Fredrik Lundh wrote: > how much work would it be to move the entire repository over to > pythonlabs, btw? sourceforget is frustratingly slow... rsync access to the CVS repository would be nice too. rsync should be faster than "cvs update". Also, once you have the whole repository making diffs and checking out different versions is much faster. Neil -- "I saw `cout' being shifted "Hello world" times to the left and stopped right there." -- Steve Gonedes From jeremy at beopen.com Tue Jun 27 23:49:01 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Tue, 27 Jun 2000 17:49:01 -0400 (EDT) Subject: [Python-Dev] SF patch manager... In-Reply-To: <20000627150555.A3083@acs.ucalgary.ca> References: <3958D89E.39D084C8@lemburg.com> <007801bfe073$3008b0c0$f2a6b5d4@hagrid> <20000627150555.A3083@acs.ucalgary.ca> Message-ID: <14681.8525.343786.194271@bitdiddle.concentric.com> >>>>> "NS" == Neil Schemenauer writes: NS> On Tue, Jun 27, 2000 at 10:06:30PM +0200, Fredrik Lundh wrote: >> how much work would it be to move the entire repository over to >> pythonlabs, btw? sourceforget is frustratingly slow... NS> rsync access to the CVS repository would be nice too. rsync NS> should be faster than "cvs update". Also, once you have the NS> whole repository making diffs and checking out different NS> versions is much faster. Absolutely! OpenSSL works this way and I find it much more convenient than using a remote CVS server. I use commands like diff, log, and annotate frequently during development. Have you suggested that as a SourceForge feature? Jeremy From akuchlin at mems-exchange.org Tue Jun 27 23:47:07 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Tue, 27 Jun 2000 17:47:07 -0400 Subject: [Python-Dev] Testdrive systems Message-ID: <20000627174707.P19033@kronos.cnri.reston.va.us> Portability-related note: I've just fixed a reported compilation problem with the curses module on Tru64 Unix using a machine made available by Compaq. If you go to http://www.testdrive.compaq.com/, you can sign up for a free 30-day account on a variety of machines: Alphas running Tru64, FreeBSD, and Linux, and Intel machines running BSD or Linux. A nice way to fix reported problems quickly... The environment on the systems is a bit Spartan; emacs is there, but no fancy shells and no CVS (which is especially annoying). --amk From nascheme at enme.ucalgary.ca Wed Jun 28 00:56:09 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Tue, 27 Jun 2000 16:56:09 -0600 Subject: [Python-Dev] SF patch manager... In-Reply-To: <14681.8525.343786.194271@bitdiddle.concentric.com>; from jeremy@beopen.com on Tue, Jun 27, 2000 at 05:49:01PM -0400 References: <3958D89E.39D084C8@lemburg.com> <007801bfe073$3008b0c0$f2a6b5d4@hagrid> <20000627150555.A3083@acs.ucalgary.ca> <14681.8525.343786.194271@bitdiddle.concentric.com> Message-ID: <20000627165609.A3941@acs.ucalgary.ca> On Tue, Jun 27, 2000 at 05:49:01PM -0400, Jeremy Hylton wrote: > Have you suggested [rsync access to CVS] as a SourceForge feature? Nope. Be my guest. :) Neil From tim_one at email.msn.com Wed Jun 28 02:11:44 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 27 Jun 2000 20:11:44 -0400 Subject: [Python-Dev] SF patch manager... In-Reply-To: <3958D89E.39D084C8@lemburg.com> Message-ID: [MAL] > [Please excuse my ranting... :-)] No problem -- you're not complaining about *our* software . > I've received the first round of notification message from the > patch manager and can't really say that I like them. Ok, I > understand that the patch manager is still alpha or beta software, > but these messages really don't have any usable content at all: > > """ > Patch #100646 has been updated. > Visit SourceForge.net for more info. > > http://sourceforge.net/patch/?func=detailpatch&patch_id=100646&group_id=5470 > """ I expect the title of the patch was also in the Subject line, yes? And a live link to the patch is certainly "usable". I've found both those right on target as I've been assigned or deassigned to patches so far, although I'd sure like to see something in the body saying exactly *what* about the patch "has been updated". Not saying I think it's good enough, am saying it's (barely) a start. > Also, reviewing the patches has become a pain I don't understand that, in that the text of the patch is what you got before, and what you can get now. Is your complaint here specifically that patches don't show up in your mailbox by magic? Or something else? > and discussing them is nearly impossible (I don't consider the > slashdot like comment mechanism to be of any use: there's simply > no audience for discussion). Wholly agreed there. So use python-dev for discussions for now; I agree too with Guido that the rampant but inconsistent x-posting between patches and python-dev was part of the problem. > Is there any chance of tee'ing patches from SF to the patches > list or some other patch discussion and review forum ? I expect you know as much about SF's possibilities as anyone <0.5 wink>: don't know. The SF docs are either non-existent or inadequate, far as I can tell, and I believe I share a mistaken belief with Fred Drake that new patches "should" *already* be showing up on the patches list. > I do understand that the mechanism can help with patch *checkins*, Yes, but not yet as much as it should (e.g., the default view of patches lacks basic info like the patch current status, and there's apparently not yet any way to define a different view). > but it's certainly not going to help much with the discussion > step needed before conidering any actions. Python-Dev now, possibly roundup later. OTOH, it's perfectly adequate for tiny little principal-reviewer <-> submitter give-and-take; many patches are really quite trivial. > The independent peer review principal doesn't work with this > kind of setup. I think your view is warped on this one, as you've been in the extremely favored position of pumping out crucial patches for a hot area. Most other peoples' patches have been flatly ignored for *months* now. It's not necessarily bad if other people get some attention now too . From tim_one at email.msn.com Wed Jun 28 02:11:52 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 27 Jun 2000 20:11:52 -0400 Subject: [Python-Dev] SF patch manager... In-Reply-To: <007801bfe073$3008b0c0$f2a6b5d4@hagrid> Message-ID: [Fredrik Lundh] > ... > how much work would it be to move the entire repository over to > pythonlabs, btw? Impossibly more than we could make time for soon. > sourceforget is frustratingly slow... 'Tis very erratic indeed. It *can* be speedy, but that seems much more the exception than the rule. From pingster at ilm.com Wed Jun 28 01:29:04 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Tue, 27 Jun 2000 16:29:04 -0700 (PDT) Subject: [Python-Dev] Re: [Patches] Let's use the SourceForge Patch Manager In-Reply-To: <200006272111.QAA04542@cj20424-a.reston1.va.home.com> Message-ID: Fredrik Lundh wrote: > someone really needs to fuse the patch manager with roundup (that > we should use roundup for bug tracking goes without saying...) How sweet! Why, thank you. :) Trent Mick wrote: > What are the chances of getting other meta data fields on patches, i.e. > changes to the patch manager? Categorizing patches could really help as a > filter. For instance, I may be a Unicode genius and would like to see the > patches associated with it. I agree that doing that kind of filtering is very useful. I have a discussion thingie (based on Roundup) at http://headspaces.com/. (Also prototype -- very prototype.) I hacked out the "status" and "fixer" fields and added a "keywords" field. Not much volume yet, but i think it will work well. Perhaps something like that for discussing patches? Jeremy Hylton wrote: > Maybe the right solution is to work with the SourceForge maintainers > to make roundup part of the standard support software. Hmmm... maybe i should look into that after i've figured out how super-Roundup is going to work. -- ?!ng From gward at python.net Wed Jun 28 02:58:43 2000 From: gward at python.net (Greg Ward) Date: Tue, 27 Jun 2000 20:58:43 -0400 Subject: [Python-Dev] DOS text files and CVS Message-ID: <20000627205843.A1607@beelzebub> Hi all -- can anyone enlighten me on the right way to check in DOS text files to a CVS repository? I have Thomas Heller's C source for his simple graphical installer for Python modules, and it should definitely be in the Distutils CVS tree. But I don't want to check it in if it'll screw up line-endings for anyone. Is there a Right Way to do this? Thanks -- Greg -- Greg Ward - Linux nerd gward at python.net http://starship.python.net/~gward/ Just because you're paranoid doesn't mean they *aren't* out to get you. From tim_one at email.msn.com Wed Jun 28 03:13:54 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 27 Jun 2000 21:13:54 -0400 Subject: [Python-Dev] ANN: Release schedule In-Reply-To: <017501bfe023$684fca40$f2a6b5d4@hagrid> Message-ID: [Fredrik Lundh] > (tim? where's the second installment of your sourceforge vs. > windows series?) Waiting for you to finish SRE . Seriously, I don't *need* to get Windows checkin access for the imminent release, so I moved this down my priority list. I needed to move *something* down because finding a place to live around here is both urgent & consuming much more time than I had planned on (vacancy rate: 0%). Windows vs SourceForge is still on my plate, and I'm not giving up on it, just slipping it. just-carrying-my-plans-between-the-bathroom-&-the-bed-is- invigorating-exercise-ly y'rs - tim From mhammond at skippinet.com.au Wed Jun 28 03:18:44 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Wed, 28 Jun 2000 11:18:44 +1000 Subject: [Python-Dev] ANN: Release schedule In-Reply-To: Message-ID: > just-carrying-my-plans-between-the-bathroom-&-the-bed-is- > invigorating-exercise-ly y'rs - tim Your plans, or your pans? I-knew-you-were-old-but-not-that-old--ly, Mark. From tim_one at email.msn.com Wed Jun 28 03:39:31 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 27 Jun 2000 21:39:31 -0400 Subject: [Python-Dev] RE: [Distutils] DOS text files and CVS In-Reply-To: <20000627205843.A1607@beelzebub> Message-ID: [Greg Ward] > can anyone enlighten me on the right way to check in DOS text files to a > CVS repository? Aargh, I haven't used CVS in about 6 years ... somehow or other, I believe you need to convince CVS that it's a binary (not text) file. Then it will skip line-end conversions. not-a-solution-but-maybe-a-clue-ly y'rs - tim From gstein at lyra.org Wed Jun 28 03:46:15 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 27 Jun 2000 18:46:15 -0700 Subject: [Python-Dev] add Demo/imputil/importers.py ? Message-ID: <20000627184615.A29590@lyra.org> A while back, I pulled the "demo" importers out of imputil.py. I think those should be added into Demo/imputil/. It would also be Goodness to include JimA's zipimporter. Where would that go? Cheers, -g -- Greg Stein, http://www.lyra.org/ From gmcm at hypernet.com Wed Jun 28 03:47:30 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Tue, 27 Jun 2000 21:47:30 -0400 Subject: [Python-Dev] DOS text files and CVS In-Reply-To: <20000627205843.A1607@beelzebub> Message-ID: <1249965584-36289880@hypernet.com> Greg Ward asks: > can anyone enlighten me on the right way to check in DOS text > files to a CVS repository? I have Thomas Heller's C source for > his simple graphical installer for Python modules, and it should > definitely be in the Distutils CVS tree. But I don't want to > check it in if it'll screw up line-endings for anyone. Is there > a Right Way to do this? Well, if you checked it in from a Windows box, CVS would translate line endings to native, then a Windows checkout would translate back to Windows endings. So assuming you don't want to get your fingers dirty, give it *n*x line endings and check it in. CVS does understand text, you know :-). (And about the only Windows editor that barfs on *n*x line endings is Notepad.) - Gordon From arnold at dstc.monash.edu.au Wed Jun 28 03:50:24 2000 From: arnold at dstc.monash.edu.au (David Arnold) Date: Wed, 28 Jun 2000 11:50:24 +1000 Subject: [Python-Dev] Re: [Distutils] DOS text files and CVS In-Reply-To: Your message of "Tue, 27 Jun 2000 21:39:31 -0400." Message-ID: <200006280150.LAA17759@xevious.dstc.monash.edu.au> -->"Tim" == Tim Peters writes: Tim> Aargh, I haven't used CVS in about 6 years ... somehow or Tim> other, I believe you need to convince CVS that it's a binary Tim> (not text) file. Then it will skip line-end conversions. cvs add -kb file should work to add a binary file. not sure that this is the best way to deal with DOS files, but it should work ... d From amk1 at erols.com Wed Jun 28 04:04:53 2000 From: amk1 at erols.com (A.M. Kuchling) Date: Tue, 27 Jun 2000 22:04:53 -0400 Subject: [Python-Dev] Text about cycle GC Message-ID: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com> I've written some text for the What's New article on the GCing of cycles, but it wasn't a topic I paid close attention to at the time, so I'd like corrections. Here's what I've got; please send me comments privately. 6. Optional Collection of Cycles The C implementation of Python uses reference counting to implement garbage collection. Every Python object maintains a count of the number of references pointing to itself, and adjusts the count as references are created or destroyed. Once the reference count reaches zero, the object is no longer accessible, since you need to have a reference to an object to access it, and if the count is zero, no references exist any longer. Reference counting has some pleasant properties: it's easy to understand and implement, and the resulting implementation is portable, fairly fast, and reacts well with other libraries that implement their own memory handling schemes. The major problem with reference counting is that it sometimes doesn't realise that objects are no longer accessible, resulting in a memory leak. This happens when there are cycles of references. Consider the simplest possible cycle, a class instance which has a reference to itself: instance = SomeClass() instance.myself = instance After the above two lines of code have been executed, the reference count of instance is 2; one reference is from the variable named "'instance'", and the other is from the "myself"attribute of the instance. If the next line of code is del instance, what happens? The reference count of instance is decreased by 1, so it has a reference count of 1; the reference in the "myself" attribute still exists. Yet the instance is no longer accessible through Python code, and it could be deleted. Several objects can participate in a cycle if they have references to each other, causing all of the objects to be leaked. An experimental step has been made toward fixing this problem. When compiling Python, the -with-cycle-gc (XXX correct option flag?) option can be specified. This causes a cycle detection algorithm to be periodically executed, which looks for inaccessible cycles and deletes the objects involved. Why isn't this enabled by default? Running the cycle detection algorithm takes some time, and some tuning will be required to minimize the overhead cost. It's not yet obvious how much performance is lost, because benchmarking this is tricky and depends sensitively on how often the program creates and destroys objects. XXX is this actually the correct reason? Or is it fear of breaking software that runs happily while leaving garbage? Several people worked on this problem. Early versions were written by XXX1, XXX2. (I vaguely remember several people writing first cuts at this. Anyone recall who?) The implementation that's in Python 1.6 is a rewritten version, this time done by Neil Schemenauer. Lots of other people offered suggestions along the way, such as (in alphabetical order) Marc-Andr? Lemburg, Tim Peters, Greg Stein, Eric Tiedemann. (XXX other names? If you feel you should be added, e-mail me). The March 2000 archives of the python-dev mailing list contain most of the relevant discussion, especially in the threads titled ``Reference cycle collection for Python'' and ``Finalization again''. From ians at amc.com Wed Jun 28 03:51:45 2000 From: ians at amc.com (Ian Searle) Date: Tue, 27 Jun 2000 18:51:45 -0700 Subject: [Python-Dev] Re: [Distutils] DOS text files and CVS References: Message-ID: <39595A31.6462CA42@amc.com> The best way to check DOS text files into CVS is from a Windows/DOS machine using the CVS client/pserver route. Using this method, the files are stored in canonical format. When someone checks them out from a Unix client they get /n only. And, when someone checks them out from a Windows/DOS client, they get /r/n. And, everyone is happy (well, as much as can be expected :-) If you do a 'cvs add -kb foo.dos-txt' then CVS will treat the file as binary and forego the keyword substitutions and end of line translations. But, folks checking them out will always get the /r/n regardless of platform. -Ian Tim Peters wrote: > > [Greg Ward] > > can anyone enlighten me on the right way to check in DOS text files to a > > CVS repository? > > Aargh, I haven't used CVS in about 6 years ... somehow or other, I believe > you need to convince CVS that it's a binary (not text) file. Then it will > skip line-end conversions. > > not-a-solution-but-maybe-a-clue-ly y'rs - tim > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG at python.org > http://www.python.org/mailman/listinfo/distutils-sig From akuchlin at cnri.reston.va.us Wed Jun 28 04:04:15 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Tue, 27 Jun 2000 22:04:15 -0400 Subject: [Python-Dev] add Demo/imputil/importers.py ? In-Reply-To: <20000627184615.A29590@lyra.org>; from gstein@lyra.org on Tue, Jun 27, 2000 at 06:46:15PM -0700 References: <20000627184615.A29590@lyra.org> Message-ID: <20000627220415.A22246@newcnri.cnri.reston.va.us> On Tue, Jun 27, 2000 at 06:46:15PM -0700, Greg Stein wrote: >A while back, I pulled the "demo" importers out of imputil.py. I think those >should be added into Demo/imputil/. While on the subject of adding demo directories, I'd like to add a Demo/curses directory. (Not going to happen until after b1, though; cute little demos aren't a high priority at the moment.) --amk From bwarsaw at beopen.com Wed Jun 28 04:25:47 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Tue, 27 Jun 2000 22:25:47 -0400 (EDT) Subject: [Python-Dev] DOS text files and CVS References: <20000627205843.A1607@beelzebub> Message-ID: <14681.25131.166235.152210@anthem.concentric.net> >>>>> "GW" == Greg Ward writes: GW> can anyone enlighten me on the right way to check in DOS text GW> files to a CVS repository? I have Thomas Heller's C source GW> for his simple graphical installer for Python modules, and it GW> should definitely be in the Distutils CVS tree. But I don't GW> want to check it in if it'll screw up line-endings for anyone. GW> Is there a Right Way to do this? If there's no reason why it /has/ to be DOS text, convert it to Unix line endings first. XEmacs will even do the conversion for you! That is, if the other suggestions people have made don't help. -Barry From skip at mojam.com Wed Jun 28 04:51:03 2000 From: skip at mojam.com (Skip Montanaro) Date: Tue, 27 Jun 2000 21:51:03 -0500 (CDT) Subject: [Python-Dev] readline history read/write Message-ID: <14681.26647.228866.236111@beluga.mojam.com> The original thing that motivated me to propose what became atexit.py was my desire to read and write readline history files. The two attached context diffs patch Modules/readline.c and Lib/rlcompleter.py to do that. Two new functions are added to the readline module and rlcompleter is tweaked to read the history file referenced by the PYTHONHISTORY environment variable (if it's defined) and automatically save it when the interpreter exits. I'm looking for a little feedback. Here are a few things that jumped to my mind: 1. Is it okay to add the read and register/write code to rlcompleter.py? Reading and writing readline history files doesn't have anything directly to do with identifier completion, but they both have to do with readline. 2. Assuming that history file read/write is desired, should it be predicated on the presence of an environment variable or (as in bash and other readline-aware programs) should it just happen? 3. Am I correct in assuming that this capability will only be available to Unix/Linux environments, or is readline generally available, thus forcing me to think about cross-platform issues? 4. Is there some mechanism already present in IDLE and/or PythonWin I should be aware of and try to emulate? The two context diffs are both short. You should be able to follow everything just by reading the bits of code. Offering your thoughts on the above questions shouldn't require actually modifying your interpreter. Thx, -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille O'Neal said: "He's got the rings. I listen to the man with the rings." -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: readline.dif URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rlcompleter.dif URL: From gstein at lyra.org Wed Jun 28 05:08:46 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 27 Jun 2000 20:08:46 -0700 Subject: [Python-Dev] SF patch manager... In-Reply-To: ; from tim_one@email.msn.com on Tue, Jun 27, 2000 at 08:11:52PM -0400 References: <007801bfe073$3008b0c0$f2a6b5d4@hagrid> Message-ID: <20000627200846.D29590@lyra.org> On Tue, Jun 27, 2000 at 08:11:52PM -0400, Tim Peters wrote: > [Fredrik Lundh] > > ... > > how much work would it be to move the entire repository over to > > pythonlabs, btw? > > Impossibly more than we could make time for soon. > > > sourceforget is frustratingly slow... > > 'Tis very erratic indeed. It *can* be speedy, but that seems much more the > exception than the rule. hehe... I have 30ms pings and have observed multiple Mb/sec :-) download.sourceforge.net is excellent given those stats... Of course, I'm practically just down the street. Cheers, -g -- Greg Stein, http://www.lyra.org/ From tim_one at email.msn.com Wed Jun 28 05:13:52 2000 From: tim_one at email.msn.com (Tim Peters) Date: Tue, 27 Jun 2000 23:13:52 -0400 Subject: [Python-Dev] SF patch manager... In-Reply-To: <20000627200846.D29590@lyra.org> Message-ID: [Greg Stein] > hehe... I have 30ms pings and have observed multiple Mb/sec :-) > > download.sourceforge.net is excellent given those stats... > > Of course, I'm practically just down the street. Would please send me the Python script you use to configure Win98 so that I can get multiple Mb/sec too? Thanks in advance. I always *knew* there was a secret way to boost these 56K laptop modems . keep-gloating-pal-and-we'll-move-everything-to-a-server-in-barry's- basement-ly y'rs - tim From gstein at lyra.org Wed Jun 28 05:25:31 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 27 Jun 2000 20:25:31 -0700 Subject: [Python-Dev] SF patch manager... In-Reply-To: ; from tim_one@email.msn.com on Tue, Jun 27, 2000 at 11:13:52PM -0400 References: <20000627200846.D29590@lyra.org> Message-ID: <20000627202531.G29590@lyra.org> On Tue, Jun 27, 2000 at 11:13:52PM -0400, Tim Peters wrote: > [Greg Stein] > > hehe... I have 30ms pings and have observed multiple Mb/sec :-) > > > > download.sourceforge.net is excellent given those stats... > > > > Of course, I'm practically just down the street. > > Would please send me the Python script you use to configure Win98 so that I > can get multiple Mb/sec too? Thanks in advance. I always *knew* there was > a secret way to boost these 56K laptop modems . DSL big boy! DSL! And I use a real OS :-) > keep-gloating-pal-and-we'll-move-everything-to-a-server-in-barry's- > basement-ly y'rs - tim eek! -- Greg Stein, http://www.lyra.org/ From tim_one at email.msn.com Wed Jun 28 06:11:22 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 28 Jun 2000 00:11:22 -0400 Subject: [Python-Dev] ANN: Release schedule In-Reply-To: Message-ID: >> just-carrying-my-plans-between-the-bathroom-&-the-bed-is- >> invigorating-exercise-ly y'rs - tim [Mark Hammond] > Your plans, or your pans? > > I-knew-you-were-old-but-not-that-old--ly, My pans are in storage somewhere in Baltimore, so I can't report on their possible growth. Or is this an Australian thing ? put-another-pan-on-the-barbie-mate?-ly y'rs - tim PS: My testicles *have* grown since I moved to VA! I'm wondering whether it's an early symptom of Lyme disease. They're still easy to carry from room to room, though, provided simply I'm careful not to trip over them. From bwarsaw at beopen.com Wed Jun 28 06:13:32 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 28 Jun 2000 00:13:32 -0400 (EDT) Subject: [Python-Dev] SF patch manager... References: <20000627200846.D29590@lyra.org> Message-ID: <14681.31596.221693.491788@anthem.concentric.net> >>>>> "TP" == Tim Peters writes: TP> keep-gloating-pal-and-we'll-move-everything-to-a-server-in-barry's- TP> basement-ly y'rs - tim Say the word, send me some hardware, and I'll clear a space between the drums, bass rig, and litter boxes. cover-it-in-sisal-and-even-the-cats'll-be-happy-ly y'rs, -Barry From tim_one at email.msn.com Wed Jun 28 07:04:36 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 28 Jun 2000 01:04:36 -0400 Subject: [Python-Dev] testing the Python/C API (was: Re: [Patches] PyObject_GetAttr/PyObject_SetAttr core dumps if given non-string names) In-Reply-To: <20000627095738.D7257@activestate.com> Message-ID: [Trent Mick] > I asked the question a while back if it would reasonable/useful/popular > to have a mechanism where parts of the Python/C Api could be tested > directly. Not only reasonable, IMO it's essential. "If it's not tested, it's broken." Tattoo that on your neighbor's forehead so it's always in mind . Every time we get a legit bug report on Python, I view it as a failure of the test suite. That's one of the things I hope to spend a lot of time on (but have not been promised I can spend any time on -- aren't startups great ?). > My proposal used an extension module _testmodule (although I made > it a core module on UN*X it should not bog down the core) which exported > a bunch o' test_* routines that tested specific parts of the Python/C > API. A test_internal.py module would be added to the std regression test > suite that would import this module and call each of the exported test_* > routines in turn. This would allow things like the _GetAttr/_SetAttr > behaviour to be tested. > > Anybody have any opinions? Great start! But the people who most need to take this seriously (including but not limited to me) have no bandwidth to spare before 1.6 is out the door. focus!-it's-not-just-for-breakfast-anymore-ly y'rs - tim From DavidA at ActiveState.com Wed Jun 28 07:33:37 2000 From: DavidA at ActiveState.com (David Ascher) Date: Tue, 27 Jun 2000 22:33:37 -0700 Subject: [Python-Dev] testing the Python/C API (was: Re: [Patches] PyObject_GetAttr/PyObject_SetAttr core dumps if given non-string names) In-Reply-To: Message-ID: > [Trent Mick] > > I asked the question a while back if it would reasonable/useful/popular > > to have a mechanism where parts of the Python/C Api could be tested > > directly. > > Not only reasonable, IMO it's essential. "If it's not tested, > it's broken." Tattoo that on your neighbor's forehead so it's always in mind . Stay _off_ my forehead, thank you very much. My hairline is receding enough without ink stains killing off hair follicles. Besides, I like my lobster-colored forehead just fine. --da From tim_one at email.msn.com Wed Jun 28 08:23:38 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 28 Jun 2000 02:23:38 -0400 Subject: [Python-Dev] C# (new language from Microsoft) In-Reply-To: Message-ID: [Mark Hammond] > ... > * Python has a very good and interesting story in all this - there is no > need to be alarmed. If anything, be excited :-) I was never worried about Python, but I lay awake at night worrying about MS -- I'm still an MS shareholder, so don't screw this up . every-new-c#-programmer-is-a-potential-python-convert-ly y'rs - tim From tim_one at email.msn.com Wed Jun 28 08:23:40 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 28 Jun 2000 02:23:40 -0400 Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager In-Reply-To: <200006271430.JAA01769@cj20424-a.reston1.va.home.com> Message-ID: [Guido van Rossum] > ... > The address for New Bugs is currently set to guido at beopen.com. I > suppose I should set it to pythoneers at beopen.com or even to > python-dev at python.org? Since we (PythonLabs, last week) decided to continue using Jitterbug (on python.org) for now, should the SF Bug Manager even be enabled? If it is enabled, and we are using Jitterbug, then someone has to own reentering SF bugs into the Jitterbug system. obviously y'rs - tim From gstein at lyra.org Wed Jun 28 08:47:06 2000 From: gstein at lyra.org (Greg Stein) Date: Tue, 27 Jun 2000 23:47:06 -0700 Subject: [Python-Dev] C# (new language from Microsoft) In-Reply-To: ; from tim_one@email.msn.com on Wed, Jun 28, 2000 at 02:23:38AM -0400 References: Message-ID: <20000627234706.N29590@lyra.org> On Wed, Jun 28, 2000 at 02:23:38AM -0400, Tim Peters wrote: > [Mark Hammond] > > ... > > * Python has a very good and interesting story in all this - there is no > > need to be alarmed. If anything, be excited :-) > > I was never worried about Python, but I lay awake at night worrying about > MS -- I'm still an MS shareholder, so don't screw this up . I'm an MS shareholder, too. Oh. Wait. Did I say I was involved? Don't think so... ahem. -g -- Greg Stein, http://www.lyra.org/ From andy at reportlab.com Wed Jun 28 09:03:07 2000 From: andy at reportlab.com (Andy Robinson) Date: Wed, 28 Jun 2000 08:03:07 +0100 Subject: [Python-Dev] SourceForge win32 HOWTO Message-ID: Sorry, I've been offline and missed this thread. I could have saved you some time. These are the instructions we've used at ReportLab to work with SourceForge on Win32. No problems so far despite several Unix and CVS newbies, myself included. They are adapted from an article by Jay Andrew Kay somewhere on Sourceforge and are generic rather than specific to the Python source. I have used the ReportLab project and my user name as an example but I'm sure you guys can adapt that.... 1. Get ftp.reportlab.com/tools/cvs-1.10-win.zip and ftp.reportlab.com/tools/ssh-1.2.14-win32bin.zip (copied from somewhere obscure for safety, I forget where) 2. Unzip these to a location on your path. Type 'cvs' or 'shh' from somewhere else to verify. 3. Choose where to keep your CVS projects; let's assume C:\code 4. Create a subdirectory c:\code\.ssh (yes, dot-ssh) 5. Create two environment variables: HOME=C:\CODE CVS_RSH=SSH On Win9x, this can be done in a batch file or autoexec.bat; on NT or 2000, go to Control Panel | System | Environment and set them at either user or machine level. The first must point to the directory above your .ssh directory. 6. If not done so, get a Sourceforge account and a project you can log in to. 7. Test SSH independently by doing SSH -l username myproject.sourceforge.net It should prompt for a password, then tell you that "myproject.sourceforge.net" is added to the list of known hosts; then give you a shell. 8. You will need either a lengthy command line or a batch file for each sourceforge project. I set cvsroot in a batch file in my 'c:\code' directory, and have one such file for each CVS project I use (about ten of them!): ------cvsreportlab.bat-------------- set HOME=C:\CODE set CVS_RSH=SSH set CVSROOT=:ext:my_user_name at cvs.myproject.sourceforge.net:/cvsroot/dirname --------------------------------------- 'dirname' is the top level directory in the CVS tree; a project can have several, but usually there is just one. 9. execute this batch file. You can now go to C:\Code and do cvs -z7 checkout myproject (z7 means 'compress network traffic', handy over dialup lines) 10. From now on, just use CVS normally. I wouldn't survive without Karl Fogel's book "Open Source Development with CVS", Coriolis Press. Footnote: for anonymous checkout, I think you just omit the 'my_user_name@' part from the CVSROOT variable. I hope this helps; let me know if people have any problems with the instructions. - Andy Robinson ReportLab From andy at robanal.demon.co.uk Wed Jun 28 09:03:08 2000 From: andy at robanal.demon.co.uk (Andy Robinson) Date: Wed, 28 Jun 2000 08:03:08 +0100 Subject: [Python-Dev] Sourceforge Interface Concerns In-Reply-To: <20000628025304.BB64A1CE0D@dinsdale.python.org> Message-ID: I missed all the SourceForge discussions, but ReportLab have been running all our development on SourceForge for five months and I'd like to share some concerns. First, we all use command line CVS, mostly from Windows; I just posted our setup instructions. It works fine but a bit slowly. I find the web interface totally unusable from IE5 and Netscape 4.XX, working over 64k lines or dialup lines. Once one logs in via SSL, only about one click in five ever returns a sensible page, and most just time out and give an error message. Many other people on the reportlab-users list and my team report similar problems. On the other hand, many are incredulous and say they have never had a problem. I found no complaints on the SF discussion groups, but as far as I can tell hardly anyone uses them. It seems to be better over big corporate connections. I don't think it is because I am in Europe; we never have trouble with our US ISPs. As a result of this, we have not used the wonderful looking bug tracking, to-do-list, patch manager etc. How many people here have actually created accounts for themselves on SourceForge and tried to do stuff when logged in - raise bugs and so on? Did it work for you? We ought to get a few data points before making this the way Python is managed. - Andy Robinson From nhodgson at bigpond.net.au Wed Jun 28 09:23:52 2000 From: nhodgson at bigpond.net.au (Neil Hodgson) Date: Wed, 28 Jun 2000 17:23:52 +1000 Subject: [Python-Dev] Sourceforge Interface Concerns References: Message-ID: <002401bfe0d1$d05a9fd0$e3cb8490@neil> > How many people here have actually created accounts for themselves on > SourceForge and tried to do stuff when logged in - raise bugs and so on? > Did it work for you? We ought to get a few data points before making this > the way Python is managed. Its generally quite good for me now that I've upgraded from a modem to a cable connection although there are brown-out periods. The only web browser I have any success with is Navigator 4.6 and 4.7. Both IE and Mozilla give poor results with SSL login. As far as getting other people to use the bug logger, its been a complete failure. Its much easier to email me or the mailing list. Some parts of SourceForge such as the file release upload are quite poorly designed and are too unpleasant to use on a slow connection if you have several packages for each release. Neil From tim_one at email.msn.com Wed Jun 28 09:28:10 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 28 Jun 2000 03:28:10 -0400 Subject: [Python-Dev] SourceForge win32 HOWTO In-Reply-To: Message-ID: [Andy Robinson] > Sorry, I've been offline and missed this thread. I could have saved you > some time. These are the instructions we've used at ReportLab to work with > SourceForge on Win32. No problems so far despite several Unix and CVS > newbies, myself included. ... Thanks, Andy! I just *knew* that if I sat on my ass, someone would solve this one for me . I'll give these instructions a try, and also see what it takes to adapt them to wincvs. Note that I'm going to be putting similar (perhaps, by an amazing coincidence, even identical) instructions up on pythonlabs.com, so if you want to stop maintaining this, dump it on me. From tim_one at email.msn.com Wed Jun 28 09:28:26 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 28 Jun 2000 03:28:26 -0400 Subject: [Python-Dev] Sourceforge Interface Concerns In-Reply-To: Message-ID: [Andy Robinson] > ... > I find the web interface totally unusable from IE5 and Netscape 4.XX, > working over 64k lines or dialup lines. Once one logs in via SSL, only > about one click in five ever returns a sensible page, and most > just time out and give an error message. Many other people on the > reportlab-users list and my team report similar problems. On the other > hand, many are incredulous and say they have never had a problem. > I found no complaints on the SF discussion groups, but as far as I can > tell hardly anyone uses them. It seems to be better over big corporate > connections. I don't think it is because I am in Europe; we never have > trouble with our US ISPs. I'm in the middle: sometimes it works great, sometimes slow as molasses (IE5 via 56K modem on the other side of the country), and an error each one of two clicks. Greg Stein lives near it, and reports wonderful access via DSL. > As a result of this, we have not used the wonderful looking bug tracking, > to-do-list, patch manager etc. They're actually pretty feeble. > How many people here have actually created accounts for themselves on > SourceForge and tried to do stuff when logged in - raise bugs and so on? > Did it work for you? We ought to get a few data points before making this > the way Python is managed. We're not using the bug tracker, task list, news, forum or support managers. Just the CVS tree and the patch manager. There are particular reasons for using those particular two, and I doubt we'll be moving more there until SF gets better. OTOH, we're also interested in *helping* SF get better! SF is as much an Open Source project as Python, and it could become an incredible resource for the entire OS community. doesn't-mean-i-won't-gripe-too-though-ly y'rs - tim From gstein at lyra.org Wed Jun 28 10:04:07 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 28 Jun 2000 01:04:07 -0700 Subject: [Python-Dev] Sourceforge Interface Concerns In-Reply-To: ; from tim_one@email.msn.com on Wed, Jun 28, 2000 at 03:28:26AM -0400 References: Message-ID: <20000628010407.T29590@lyra.org> On Wed, Jun 28, 2000 at 03:28:26AM -0400, Tim Peters wrote: >... > We're not using the bug tracker, task list, news, forum or support managers. > Just the CVS tree and the patch manager. There are particular reasons for > using those particular two, and I doubt we'll be moving more there until SF > gets better. OTOH, we're also interested in *helping* SF get better! SF is > as much an Open Source project as Python, and it could become an incredible > resource for the entire OS community. This last statement is (unfortunately) not quite true. SourceForge is developed in a closed, cathedral environment. There is no CVS access to it, and all the developers work at VA Linux. Strictly speaking, the *output* of this closed development is GPL'd. But it isn't what you would expect. The documentation for SF is separate. Apparently, there was an independent effort to help do some documentation and they got a good ways. Then the VA guys suddenly popped out the "SFDocs" project, ignoring the work from the other people. Not sure where I read that, so I can't provide a reference to the stories/threads :-( btw, there is a survey about SF that you can fill out: http://sourceforge.net/survey/survey.php?group_id=1&survey_id=10599 Cheers, -g -- Greg Stein, http://www.lyra.org/ From mal at lemburg.com Wed Jun 28 10:03:00 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 28 Jun 2000 10:03:00 +0200 Subject: [Python-Dev] SF patch manager... References: Message-ID: <3959B134.1538B4B7@lemburg.com> Tim Peters wrote: > > [MAL] > > [Please excuse my ranting... :-)] > > No problem -- you're not complaining about *our* software . > > > I've received the first round of notification message from the > > patch manager and can't really say that I like them. Ok, I > > understand that the patch manager is still alpha or beta software, > > but these messages really don't have any usable content at all: > > > > """ > > Patch #100646 has been updated. > > Visit SourceForge.net for more info. > > > > > http://sourceforge.net/patch/?func=detailpatch&patch_id=100646&group_id=5470 > > """ > > I expect the title of the patch was also in the Subject line, yes? Right, but that's just about all the information you get: the title, the fact that something changed and a link to the patch page. > And a > live link to the patch is certainly "usable". I've found both those right > on target as I've been assigned or deassigned to patches so far, although > I'd sure like to see something in the body saying exactly *what* about the > patch "has been updated". > > Not saying I think it's good enough, am saying it's (barely) a start. True and I don't want to put this down. The only reason for my ranting is that I'd rather get more infos in mail than via some link to a page. Discussing patches via quoting email is just so much more convenient -- opening two or three browsers to get at the hard facts isn't and, as others have already noted, is rather slow too. > > Also, reviewing the patches has become a pain > > I don't understand that, in that the text of the patch is what you got > before, and what you can get now. Is your complaint here specifically that > patches don't show up in your mailbox by magic? Or something else? I would very much prefer to get the patches or changes appended to the update messages (much like was manually done on patches at python.org). That way I can read the patch and then reply to the sender and the list community from within the mail application -- without copy&paste, looking up email addresses in SF etc. > > and discussing them is nearly impossible (I don't consider the > > slashdot like comment mechanism to be of any use: there's simply > > no audience for discussion). > > Wholly agreed there. So use python-dev for discussions for now; I agree too > with Guido that the rampant but inconsistent x-posting between patches and > python-dev was part of the problem. > > > Is there any chance of tee'ing patches from SF to the patches > > list or some other patch discussion and review forum ? > > I expect you know as much about SF's possibilities as anyone <0.5 wink>: > don't know. The SF docs are either non-existent or inadequate, far as I can > tell, and I believe I share a mistaken belief with Fred Drake that new > patches "should" *already* be showing up on the patches list. They are showing up there... at least new ones are. Discussions (via posting comments on the patch page) are not relayed to the list though: only the comment authors get an email. > > I do understand that the mechanism can help with patch *checkins*, > > Yes, but not yet as much as it should (e.g., the default view of patches > lacks basic info like the patch current status, and there's apparently not > yet any way to define a different view). > > > but it's certainly not going to help much with the discussion > > step needed before conidering any actions. > > Python-Dev now, possibly roundup later. OTOH, it's perfectly adequate for > tiny little principal-reviewer <-> submitter give-and-take; many patches are > really quite trivial. True, but even small patches occasionally need peer review from more people than just the assigned developer. > > The independent peer review principal doesn't work with this > > kind of setup. > > I think your view is warped on this one, as you've been in the extremely > favored position of pumping out crucial patches for a hot area. Most other > peoples' patches have been flatly ignored for *months* now. It's not > necessarily bad if other people get some attention now too . Oops, did it shine through that much ? ;-) Seriously, I would like to see a processing speedup too, it's just the workflow that bothers me a bit. BTW, another great feature for the patch manager would be a button to perform the actual checkin via the web interface. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From rob at hooft.net Wed Jun 28 11:27:18 2000 From: rob at hooft.net (Rob W. W. Hooft) Date: Wed, 28 Jun 2000 11:27:18 +0200 (CEST) Subject: [Python-Dev] Typo's Message-ID: <14681.50422.966321.780406@temoleh.chem.uu.nl> I located some typo's in the CVS. Here is a patch. Warning: I'm a non-native English speaker. Please verify fixes. Rob Index: Demo/pdist/rcslib.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Demo/pdist/rcslib.py,v retrieving revision 1.6 diff -u -r1.6 rcslib.py --- Demo/pdist/rcslib.py 1998/09/14 16:43:57 1.6 +++ Demo/pdist/rcslib.py 2000/06/28 07:42:50 @@ -296,7 +296,7 @@ def _system(self, cmd): """INTERNAL: run COMMAND in a subshell. - Standard input for the command is taken fron /dev/null. + Standard input for the command is taken from /dev/null. Raise IOError when the exit status is not zero. Index: Demo/sgi/video/Vcopy.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Demo/sgi/video/Vcopy.py,v retrieving revision 1.7 diff -u -r1.7 Vcopy.py --- Demo/sgi/video/Vcopy.py 1996/11/27 19:50:07 1.7 +++ Demo/sgi/video/Vcopy.py 2000/06/28 07:42:50 @@ -8,7 +8,7 @@ # - Manipulate the time base: # = resample at a fixed rate # = divide the time codes by a speed factor (to make it go faster/slower) -# = drop frames that are less than n msec apart (to accomodate slow players) +# = drop frames that are less than n msec apart (to accommodate slow players) # - Convert to a different format # - Magnify (scale) the image Index: Demo/sgi/video/Vtime.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Demo/sgi/video/Vtime.py,v retrieving revision 1.4 diff -u -r1.4 Vtime.py --- Demo/sgi/video/Vtime.py 1996/11/27 19:50:28 1.4 +++ Demo/sgi/video/Vtime.py 2000/06/28 07:42:50 @@ -7,7 +7,7 @@ # # - resample at a fixed rate # - divide the time codes by a speed factor (to make it go faster/slower) -# - drop frames that are less than n msec apart (to accomodate slow players) +# - drop frames that are less than n msec apart (to accommodate slow players) # Usage: Index: Lib/Queue.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/Queue.py,v retrieving revision 1.10 diff -u -r1.10 Queue.py --- Lib/Queue.py 2000/02/02 15:10:14 1.10 +++ Lib/Queue.py 2000/06/28 07:42:51 @@ -119,7 +119,7 @@ def _qsize(self): return len(self.queue) - # Check wheter the queue is empty + # Check whether the queue is empty def _empty(self): return not self.queue Index: Lib/binhex.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/binhex.py,v retrieving revision 1.12 diff -u -r1.12 binhex.py --- Lib/binhex.py 2000/02/04 15:39:29 1.12 +++ Lib/binhex.py 2000/06/28 07:42:51 @@ -13,7 +13,7 @@ # XXXX Note: currently, textfiles appear in mac-form on all platforms. # We seem to lack a simple character-translate in python. # (we should probably use ISO-Latin-1 on all but the mac platform). -# XXXX The simeple routines are too simple: they expect to hold the complete +# XXXX The simple routines are too simple: they expect to hold the complete # files in-core. Should be fixed. # XXXX It would be nice to handle AppleDouble format on unix # (for servers serving macs). @@ -48,7 +48,7 @@ try: openrf = MacOS.openrf except AttributeError: - # Backward compatability + # Backward compatibility openrf = open def FInfo(): Index: Lib/calendar.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/calendar.py,v retrieving revision 1.15 diff -u -r1.15 calendar.py --- Lib/calendar.py 2000/02/02 15:10:14 1.15 +++ Lib/calendar.py 2000/06/28 07:42:51 @@ -1,6 +1,6 @@ """Calendar printing functions""" -# Revision 2: uses funtions from built-in time module +# Revision 2: uses functions from built-in time module # Import functions and variables from time module from time import localtime, mktime Index: Lib/fnmatch.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/fnmatch.py,v retrieving revision 1.7 diff -u -r1.7 fnmatch.py --- Lib/fnmatch.py 1997/10/22 20:57:40 1.7 +++ Lib/fnmatch.py 2000/06/28 07:42:51 @@ -36,7 +36,7 @@ return fnmatchcase(name, pat) def fnmatchcase(name, pat): - """Test wheter FILENAME matches PATTERN, including case. + """Test whether FILENAME matches PATTERN, including case. This is a version of fnmatch() which doesn't case-normalize its arguments. Index: Lib/locale.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/locale.py,v retrieving revision 1.6 diff -u -r1.6 locale.py --- Lib/locale.py 2000/06/08 17:49:41 1.6 +++ Lib/locale.py 2000/06/28 07:42:52 @@ -220,7 +220,7 @@ The language code corresponds to RFC 1766. code and encoding can be None in case the values cannot be determined or are - unkown to this implementation. + unknown to this implementation. """ code = normalize(localename) @@ -229,7 +229,7 @@ elif code == 'C': return None, None else: - raise ValueError,'unkown locale: %s' % localename + raise ValueError,'unknown locale: %s' % localename return l def _build_localename(localetuple): Index: Lib/posixpath.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/posixpath.py,v retrieving revision 1.30 diff -u -r1.30 posixpath.py --- Lib/posixpath.py 2000/02/29 13:31:16 1.30 +++ Lib/posixpath.py 2000/06/28 07:42:52 @@ -24,7 +24,7 @@ return s -# Return wheter a path is absolute. +# Return whether a path is absolute. # Trivial in Posix, harder on the Mac or MS-DOS. def isabs(s): @@ -304,7 +304,7 @@ # Expand paths containing shell variable substitutions. # This expands the forms $variable and ${variable} only. -# Non-existant variables are left unchanged. +# Non-existent variables are left unchanged. _varprog = None Index: Lib/sgmllib.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/sgmllib.py,v retrieving revision 1.19 diff -u -r1.19 sgmllib.py --- Lib/sgmllib.py 2000/02/04 15:28:40 1.19 +++ Lib/sgmllib.py 2000/06/28 07:42:53 @@ -47,7 +47,7 @@ # and , respectively, or do_foo to handle by itself. # (Tags are converted to lower case for this purpose.) The data # between tags is passed to the parser by calling self.handle_data() -# with some data as argument (the data may be split up in arbutrary +# with some data as argument (the data may be split up in arbitrary # chunks). Entity references are passed by calling # self.handle_entityref() with the entity reference as argument. Index: Lib/site.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/site.py,v retrieving revision 1.11 diff -u -r1.11 site.py --- Lib/site.py 2000/06/07 09:12:09 1.11 +++ Lib/site.py 2000/06/28 07:42:53 @@ -122,7 +122,7 @@ # # Set the string encoding used by the Unicode implementation to the # encoding used by the default locale of this system. If the default -# encoding cannot be determined or is unkown, it defaults to 'ascii'. +# encoding cannot be determined or is unknown, it defaults to 'ascii'. # def locale_aware_defaultencoding(): import locale Index: Lib/urllib2.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/urllib2.py,v retrieving revision 1.3 diff -u -r1.3 urllib2.py --- Lib/urllib2.py 2000/02/10 17:17:14 1.3 +++ Lib/urllib2.py 2000/06/28 07:42:54 @@ -141,7 +141,7 @@ _opener = opener # do these error classes make sense? -# make sure all of the IOError stuff is overriden. we just want to be +# make sure all of the IOError stuff is overridden. we just want to be # subtypes. class URLError(IOError): Index: Lib/xmllib.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/xmllib.py,v retrieving revision 1.18 diff -u -r1.18 xmllib.py --- Lib/xmllib.py 2000/06/21 20:01:10 1.18 +++ Lib/xmllib.py 2000/06/28 07:42:54 @@ -79,7 +79,7 @@ # special names to handle tags: start_foo and end_foo to handle # and , respectively. The data between tags is passed to the # parser by calling self.handle_data() with some data as argument (the -# data may be split up in arbutrary chunks). +# data may be split up in arbitrary chunks). class XMLParser: attributes = {} # default, to be overridden Index: Lib/distutils/cmd.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/distutils/cmd.py,v retrieving revision 1.18 diff -u -r1.18 cmd.py --- Lib/distutils/cmd.py 2000/06/08 00:02:36 1.18 +++ Lib/distutils/cmd.py 2000/06/28 07:42:55 @@ -323,7 +323,7 @@ should be disabled by the "dry run" flag, and should announce themselves if the current verbosity level is high enough. This method takes care of all that bureaucracy for you; all you have to - do is supply the funtion to call and an argument tuple for it (to + do is supply the function to call and an argument tuple for it (to embody the "external action" being performed), a message to print if the verbosity level is high enough, and an optional verbosity threshold. Index: Lib/distutils/util.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/distutils/util.py,v retrieving revision 1.37 diff -u -r1.37 util.py --- Lib/distutils/util.py 2000/06/24 20:40:02 1.37 +++ Lib/distutils/util.py 2000/06/28 07:42:55 @@ -28,7 +28,7 @@ return os.path.normpath(path) -# More backwards compatability hacks +# More backwards compatibility hacks def extend (list, new_list): """Appends the list 'new_list' to 'list', just like the 'extend()' list method does in Python 1.5.2 -- but this works on earlier Index: Lib/distutils/version.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/distutils/version.py,v retrieving revision 1.1 diff -u -r1.1 version.py --- Lib/distutils/version.py 1998/12/18 22:00:30 1.1 +++ Lib/distutils/version.py 2000/06/28 07:42:55 @@ -207,7 +207,7 @@ # provides enough benefit to be worth using, and will submit their # version numbering scheme to its domination. The free-thinking # anarchists in the lot will never give in, though, and something needs -# to be done to accomodate them. +# to be done to accommodate them. # # Perhaps a "moderately strict" version class could be implemented that # lets almost anything slide (syntactically), and makes some heuristic Index: Lib/distutils/command/build_ext.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/distutils/command/build_ext.py,v retrieving revision 1.51 diff -u -r1.51 build_ext.py --- Lib/distutils/command/build_ext.py 2000/06/28 01:29:37 1.51 +++ Lib/distutils/command/build_ext.py 2000/06/28 07:42:56 @@ -1,7 +1,7 @@ """distutils.command.build_ext Implements the Distutils 'build_ext' command, for building extension -modules (currently limited to C extensions, should accomodate C++ +modules (currently limited to C extensions, should accommodate C++ extensions ASAP).""" # created 1999/08/09, Greg Ward @@ -385,7 +385,7 @@ # Next, compile the source code to object files. # XXX not honouring 'define_macros' or 'undef_macros' -- the - # CCompiler API needs to change to accomodate this, and I + # CCompiler API needs to change to accommodate this, and I # want to do one thing at a time! # Two possible sources for extra compiler arguments: Index: Lib/dos-8x3/posixpat.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/dos-8x3/posixpat.py,v retrieving revision 1.10 diff -u -r1.10 posixpat.py --- Lib/dos-8x3/posixpat.py 2000/05/08 17:31:00 1.10 +++ Lib/dos-8x3/posixpat.py 2000/06/28 07:42:56 @@ -24,7 +24,7 @@ return s -# Return wheter a path is absolute. +# Return whether a path is absolute. # Trivial in Posix, harder on the Mac or MS-DOS. def isabs(s): @@ -304,7 +304,7 @@ # Expand paths containing shell variable substitutions. # This expands the forms $variable and ${variable} only. -# Non-existant variables are left unchanged. +# Non-existent variables are left unchanged. _varprog = None Index: Lib/dos-8x3/queue.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/dos-8x3/queue.py,v retrieving revision 1.7 diff -u -r1.7 queue.py --- Lib/dos-8x3/queue.py 2000/05/08 17:31:00 1.7 +++ Lib/dos-8x3/queue.py 2000/06/28 07:42:56 @@ -119,7 +119,7 @@ def _qsize(self): return len(self.queue) - # Check wheter the queue is empty + # Check whether the queue is empty def _empty(self): return not self.queue Index: Lib/dos-8x3/test_win.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/dos-8x3/test_win.py,v retrieving revision 1.1 diff -u -r1.1 test_win.py --- Lib/dos-8x3/test_win.py 2000/05/08 17:31:03 1.1 +++ Lib/dos-8x3/test_win.py 2000/06/28 07:42:57 @@ -115,7 +115,7 @@ # Opening should now fail! try: key = OpenKey(root_key, test_key_name) - assert 0, "Could open the non-existant key" + assert 0, "Could open the non-existent key" except WindowsError: # Use this error name this time pass Index: Lib/dos-8x3/test_zli.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/dos-8x3/test_zli.py,v retrieving revision 1.5 diff -u -r1.5 test_zli.py --- Lib/dos-8x3/test_zli.py 2000/05/08 17:31:03 1.5 +++ Lib/dos-8x3/test_zli.py 2000/06/28 07:42:57 @@ -11,7 +11,7 @@ buf = file.read() * 8 file.close() -# test the chucksums (hex so the test doesn't break on 64-bit machines) +# test the checksums (hex so the test doesn't break on 64-bit machines) print hex(zlib.crc32('penguin')), hex(zlib.crc32('penguin', 1)) print hex(zlib.adler32('penguin')), hex(zlib.adler32('penguin', 1)) Index: Lib/plat-irix5/CL_old.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/plat-irix5/CL_old.py,v retrieving revision 1.1 diff -u -r1.1 CL_old.py --- Lib/plat-irix5/CL_old.py 1995/05/17 11:18:22 1.1 +++ Lib/plat-irix5/CL_old.py 2000/06/28 07:42:57 @@ -200,7 +200,7 @@ BOTTOM_UP = 1 # -# SGI Proprietaty Algorithm Header Start Code +# SGI Proprietary Algorithm Header Start Code # HEADER_START_CODE = 0xc1C0DEC Index: Lib/plat-irix5/flp.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/plat-irix5/flp.py,v retrieving revision 1.17 diff -u -r1.17 flp.py --- Lib/plat-irix5/flp.py 1998/03/26 20:22:58 1.17 +++ Lib/plat-irix5/flp.py 2000/06/28 07:42:57 @@ -203,7 +203,7 @@ return datum[1] # # Internal: parse fd form, or skip if name doesn't match. -# the special value None means 'allways parse it'. +# the special value None means 'always parse it'. # def _parse_fd_form(file, name): datum = _parse_1_line(file) @@ -222,7 +222,7 @@ return None # -# Internal class: a convient place to store object info fields +# Internal class: a convenient place to store object info fields # class _newobj: def add(self, name, value): Index: Lib/plat-irix5/panel.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/plat-irix5/panel.py,v retrieving revision 1.4 diff -u -r1.4 panel.py --- Lib/plat-irix5/panel.py 1995/09/18 22:00:37 1.4 +++ Lib/plat-irix5/panel.py 2000/06/28 07:42:58 @@ -2,7 +2,7 @@ # # Support for the Panel library. # Uses built-in module 'pnl'. -# Applciations should use 'panel.function' instead of 'pnl.function'; +# Applications should use 'panel.function' instead of 'pnl.function'; # most 'pnl' functions are transparently exported by 'panel', # but dopanel() is overridden and you have to use this version # if you want to use callbacks. @@ -137,7 +137,7 @@ print 'assign failed:', stmt -# Build a real actuator from an actuator descriptior. +# Build a real actuator from an actuator description. # Return a pair (actuator, name). # def build_actuator(descr): Index: Lib/plat-irix6/flp.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/plat-irix6/flp.py,v retrieving revision 1.4 diff -u -r1.4 flp.py --- Lib/plat-irix6/flp.py 1998/03/26 20:23:01 1.4 +++ Lib/plat-irix6/flp.py 2000/06/28 07:42:58 @@ -203,7 +203,7 @@ return datum[1] # # Internal: parse fd form, or skip if name doesn't match. -# the special value None means 'allways parse it'. +# the special value None means 'always parse it'. # def _parse_fd_form(file, name): datum = _parse_1_line(file) @@ -222,7 +222,7 @@ return None # -# Internal class: a convient place to store object info fields +# Internal class: a convenient place to store object info fields # class _newobj: def add(self, name, value): Index: Lib/plat-irix6/panel.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/plat-irix6/panel.py,v retrieving revision 1.1 diff -u -r1.1 panel.py --- Lib/plat-irix6/panel.py 1997/01/15 19:19:11 1.1 +++ Lib/plat-irix6/panel.py 2000/06/28 07:42:58 @@ -2,7 +2,7 @@ # # Support for the Panel library. # Uses built-in module 'pnl'. -# Applciations should use 'panel.function' instead of 'pnl.function'; +# Applications should use 'panel.function' instead of 'pnl.function'; # most 'pnl' functions are transparently exported by 'panel', # but dopanel() is overridden and you have to use this version # if you want to use callbacks. @@ -137,7 +137,7 @@ print 'assign failed:', stmt -# Build a real actuator from an actuator descriptior. +# Build a real actuator from an actuator description. # Return a pair (actuator, name). # def build_actuator(descr): Index: Lib/test/test_al.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/test/test_al.py,v retrieving revision 1.2 diff -u -r1.2 test_al.py --- Lib/test/test_al.py 1998/03/26 19:41:38 1.2 +++ Lib/test/test_al.py 2000/06/28 07:42:58 @@ -8,7 +8,7 @@ alattrs = ['__doc__', '__name__', 'getdefault', 'getminmax', 'getname', 'getparams', 'newconfig', 'openport', 'queryparams', 'setparams'] -# This is a very inobstrusive test for the existance of the al module and all it's +# This is a very inobtrusive test for the existence of the al module and all it's # attributes. More comprehensive examples can be found in Demo/al def main(): Index: Lib/test/test_b1.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/test/test_b1.py,v retrieving revision 1.22 diff -u -r1.22 test_b1.py --- Lib/test/test_b1.py 2000/04/14 19:13:22 1.22 +++ Lib/test/test_b1.py 2000/06/28 07:42:58 @@ -270,7 +270,7 @@ # Different base: if int("10",16) <> 16L: raise TestFailed, 'int("10",16)' if int(u"10",16) <> 16L: raise TestFailed, 'int(u"10",16)' -# Test conversion fron strings and various anomalies +# Test conversion from strings and various anomalies L = [ ('0', 0), ('1', 1), Index: Lib/test/test_cd.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/test/test_cd.py,v retrieving revision 1.2 diff -u -r1.2 test_cd.py --- Lib/test/test_cd.py 1998/03/26 19:41:49 1.2 +++ Lib/test/test_cd.py 2000/06/28 07:42:58 @@ -10,7 +10,7 @@ 'ident', 'index', 'msftoframe', 'open', 'pnum', 'ptime'] -# This is a very inobstrusive test for the existance of the cd module and all it's +# This is a very inobtrusive test for the existence of the cd module and all it's # attributes. More comprehensive examples can be found in Demo/cd and # require that you have a CD and a CD ROM drive Index: Lib/test/test_cl.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/test/test_cl.py,v retrieving revision 1.2 diff -u -r1.2 test_cl.py --- Lib/test/test_cl.py 1998/03/26 19:41:52 1.2 +++ Lib/test/test_cl.py 2000/06/28 07:42:58 @@ -63,7 +63,7 @@ 'YUV422DC', 'YUV422HC', '__doc__', '__name__', 'cvt_type', 'error'] -# This is a very inobstrusive test for the existance of the cl +# This is a very inobtrusive test for the existence of the cl # module and all it's attributes. def main(): Index: Lib/test/test_pwd.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/test/test_pwd.py,v retrieving revision 1.5 diff -u -r1.5 test_pwd.py --- Lib/test/test_pwd.py 1998/03/26 19:42:32 1.5 +++ Lib/test/test_pwd.py 2000/06/28 07:42:58 @@ -59,7 +59,7 @@ else: print 'fakename', fakename, 'did not except pwd.getpwnam()' -# Choose a non-existant uid. +# Choose a non-existent uid. fakeuid = 4127 while byuids.has_key(fakeuid): fakeuid = (fakeuid * 3) % 0x10000 Index: Lib/test/test_winreg.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/test/test_winreg.py,v retrieving revision 1.2 diff -u -r1.2 test_winreg.py --- Lib/test/test_winreg.py 2000/04/01 05:25:57 1.2 +++ Lib/test/test_winreg.py 2000/06/28 07:42:58 @@ -115,7 +115,7 @@ # Opening should now fail! try: key = OpenKey(root_key, test_key_name) - assert 0, "Could open the non-existant key" + assert 0, "Could open the non-existent key" except WindowsError: # Use this error name this time pass Index: Lib/test/test_zlib.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/test/test_zlib.py,v retrieving revision 1.7 diff -u -r1.7 test_zlib.py --- Lib/test/test_zlib.py 2000/02/10 15:31:07 1.7 +++ Lib/test/test_zlib.py 2000/06/28 07:42:59 @@ -11,7 +11,7 @@ buf = file.read() * 8 file.close() -# test the chucksums (hex so the test doesn't break on 64-bit machines) +# test the checksums (hex so the test doesn't break on 64-bit machines) print hex(zlib.crc32('penguin')), hex(zlib.crc32('penguin', 1)) print hex(zlib.adler32('penguin')), hex(zlib.adler32('penguin', 1)) Index: Python/exceptions.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/exceptions.c,v retrieving revision 1.2 diff -u -r1.2 exceptions.c --- Python/exceptions.c 2000/06/20 18:36:26 1.2 +++ Python/exceptions.c 2000/06/28 07:42:59 @@ -189,7 +189,7 @@ * * First thing we create is the base class for all exceptions, called * appropriately enough: Exception. Creation of this class makes no - * assumptions about the existance of any other exception class -- except + * assumptions about the existence of any other exception class -- except * for TypeError, which can conditionally exist. * * Next, StandardError is created (which is quite simple) followed by Index: Python/import.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/import.c,v retrieving revision 2.134 diff -u -r2.134 import.c --- Python/import.c 2000/05/03 23:44:39 2.134 +++ Python/import.c 2000/06/28 07:43:01 @@ -87,7 +87,7 @@ #define MAGIC (50428 | ((long)'\r'<<16) | ((long)'\n'<<24)) /* Magic word as global; note that _PyImport_Init() can change the - value of this global to accomodate for alterations of how the + value of this global to accommodate for alterations of how the compiler works which are enabled by command line switches. */ static long pyc_magic = MAGIC; From effbot at telia.com Wed Jun 28 11:47:32 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 28 Jun 2000 11:47:32 +0200 Subject: [Python-Dev] Typo's References: <14681.50422.966321.780406@temoleh.chem.uu.nl> Message-ID: <012f01bfe0e5$e3dce360$f2a6b5d4@hagrid> > I located some typo's in the CVS. Here is a patch. wow! just one nit: "inobstrusive" should be "unobtrusive" (not "inobtrusive") (and it's not clear if "descriptior" means "description" or "descriptor"...) > Warning: I'm a non-native English speaker. same here. From effbot at telia.com Wed Jun 28 13:07:24 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 28 Jun 2000 13:07:24 +0200 Subject: [Python-Dev] OT: A Day in the Life of p5p Message-ID: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> http://prometheus.frii.com/~gnat/yapc/2000-p5p.txt unfortunately, his "What is it with those Python fucks anyway" talk isn't posted... ;-) From fdrake at beopen.com Wed Jun 28 13:16:53 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Wed, 28 Jun 2000 07:16:53 -0400 (EDT) Subject: [Python-Dev] back up & running Message-ID: <14681.56997.50955.892954@cj42289-a.reston1.va.home.com> My mega-laptop got fixed faster than I'd expected, so I'm back up to doing useful work. My top priorities are handling patches and going back through my email to find all the documentation patches that have sat idle for too long. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From mwh21 at cam.ac.uk Wed Jun 28 13:54:27 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 28 Jun 2000 12:54:27 +0100 Subject: [Python-Dev] Sourceforge Interface Concerns In-Reply-To: "Andy Robinson"'s message of "Wed, 28 Jun 2000 08:03:08 +0100" References: Message-ID: "Andy Robinson" writes: > It seems to be better over big corporate connections. I don't think it is > because I am in Europe; we never have trouble with our US ISPs. FWIW, it's pretty good from here (but then the university has pretty serious bandwidth). It seems a bit odd that it's so much worse with lower badwidth (in particular that people on modems get more errors). Oh well. Cheers, M. From Vladimir.Marangozov at inrialpes.fr Wed Jun 28 14:22:56 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Wed, 28 Jun 2000 14:22:56 +0200 (CEST) Subject: [Python-Dev] back up & running In-Reply-To: <14681.56997.50955.892954@cj42289-a.reston1.va.home.com> from "Fred L. Drake, Jr." at Jun 28, 2000 07:16:53 AM Message-ID: <200006281222.OAA03150@python.inrialpes.fr> Fred L. Drake, Jr. wrote: > > My mega-laptop got fixed faster than I'd expected, so I'm back up to > doing useful work. My top priorities are handling patches and going > back through my email to find all the documentation patches that have > sat idle for too long. Excellent! Finally someone who cares to checkin patches. I've been disappointed to see that the June 30 intent-date was announced, but people keep chewing-gumming about SourceForge caveats while the patches backlog grows and the number of closed patches stays invariably to 3, of which one is a test! -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From bwarsaw at beopen.com Wed Jun 28 15:27:12 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 28 Jun 2000 09:27:12 -0400 (EDT) Subject: [Python-Dev] Sourceforge Interface Concerns References: <20000628025304.BB64A1CE0D@dinsdale.python.org> Message-ID: <14681.64816.561341.920024@anthem.concentric.net> >>>>> "AR" == Andy Robinson writes: AR> How many people here have actually created accounts for AR> themselves on SourceForge and tried to do stuff when logged in AR> - raise bugs and so on? Did it work for you? We ought to get AR> a few data points before making this the way Python is AR> managed. In general SF's web has been fine for me, although it is sometimes unavailable due to routing problems. I'm on a fairly reliable DSL line now, though I don't remember significantly more SF-blamable problems when I was on a 56K line. It's often quite slow to do CVS/SSH to SF. Sometimes I'll have to spin for several minutes just to do an update or a diff. That sucks. -Barry From fdrake at beopen.com Wed Jun 28 15:30:22 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Wed, 28 Jun 2000 09:30:22 -0400 (EDT) Subject: [Python-Dev] Sourceforge Interface Concerns In-Reply-To: References: <20000628025304.BB64A1CE0D@dinsdale.python.org> Message-ID: <14681.65006.782463.491824@cj42289-a.reston1.va.home.com> Andy Robinson writes: > I find the web interface totally unusable from IE5 and Netscape 4.XX, > working over 64k lines or dialup lines. Once one logs in via SSL, only > about one click in five ever returns a sensible page, and most just time out I've not been able to reproduce this behavior; the Web interface seems to work well with IE5 and Netscape 4.XX for me; the only problem I've had with IE5 is accessing a project's anonymous FTP area from the project page (IE5 just froze completely). Netscape didn't exhibit that problem for me and allowed perfectly reasonable use. Sometimes it seems a little slow, but I attribute that to load and the public-key crypto using SSH for CVS access; I understand that CVS doesn't have the most efficient wire-protocol either. I should note that I've mostly used it over T1 and cable modem links; I don't know that smaller pipes would make a huge difference though. I'd be more suspicious of trans-Atlantic linkage than anything else without having more information. Routing can do strange things, so you may be getting the worst-possible link for SourceForge while other things get better routes, but I wouldn't expect that to be terribly consistent. > How many people here have actually created accounts for themselves on > SourceForge and tried to do stuff when logged in - raise bugs and so on? > Did it work for you? We ought to get a few data points before making this > the way Python is managed. I've never had the kind of problems you describe. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From Vladimir.Marangozov at inrialpes.fr Wed Jun 28 15:58:26 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Wed, 28 Jun 2000 15:58:26 +0200 (CEST) Subject: [Python-Dev] Typo's In-Reply-To: <012f01bfe0e5$e3dce360$f2a6b5d4@hagrid> from "Fredrik Lundh" at Jun 28, 2000 11:47:32 AM Message-ID: <200006281358.PAA03368@python.inrialpes.fr> Fredrik Lundh wrote: > > > I located some typo's in the CVS. Here is a patch. > > wow! Wow, indeed. +1 I've uploaded this patch to SourceForge. > > just one nit: > > "inobstrusive" should be "unobtrusive" (not "inobtrusive") fixed in the patch. > > (and it's not clear if "descriptior" means "description" or > "descriptor"...) I examined the patched file - it's "description". > > > Warning: I'm a non-native English speaker. > > same here. same here :-) -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From guido at beopen.com Wed Jun 28 16:55:00 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 28 Jun 2000 09:55:00 -0500 Subject: [Python-Dev] add Demo/imputil/importers.py ? In-Reply-To: Your message of "Tue, 27 Jun 2000 18:46:15 MST." <20000627184615.A29590@lyra.org> References: <20000627184615.A29590@lyra.org> Message-ID: <200006281455.JAA01690@cj20424-a.reston1.va.home.com> > A while back, I pulled the "demo" importers out of imputil.py. I think those > should be added into Demo/imputil/. OK. Go ahead and create that directory and add the demo importers. > It would also be Goodness to include JimA's zipimporter. Where would that go? Same place I'd hope? Can you check that it works? We're dependent on you volunteers to maintain relatively non-core things like this -- I don't want to extend the feature freeze to Demo/, but I also don't have the time to keep the stuff there up to date. Maybe at some point the Demo directory should become a separate distribution, or just a collection of stuff on the web? --Guido van Rossum (home page: http://www.python.org/~guido/) From akuchlin at mems-exchange.org Wed Jun 28 16:07:22 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Wed, 28 Jun 2000 10:07:22 -0400 Subject: [Python-Dev] Sourceforge Interface Concerns In-Reply-To: <14681.65006.782463.491824@cj42289-a.reston1.va.home.com> References: <20000628025304.BB64A1CE0D@dinsdale.python.org> <14681.65006.782463.491824@cj42289-a.reston1.va.home.com> Message-ID: <20000628100722.A9063@kronos.cnri.reston.va.us> On Wed, Jun 28, 2000 at 09:30:22AM -0400, Fred L. Drake, Jr. wrote: > I should note that I've mostly used it over T1 and cable modem >links; I don't know that smaller pipes would make a huge difference >though. At home I have a 28.8 modem (never figured out how to upgrade it to 56K), and while CVS operations are fairly slow, there usually aren't any problems. The same goes for accessing the Web pages through SSL; somewhat slow, but reliable. --amk From gward at mems-exchange.org Wed Jun 28 16:18:12 2000 From: gward at mems-exchange.org (Greg Ward) Date: Wed, 28 Jun 2000 10:18:12 -0400 Subject: [Python-Dev] Python 1.6 planning In-Reply-To: ; from jeremy@beopen.com on Fri, Jun 23, 2000 at 06:01:19PM -0400 References: Message-ID: <20000628101812.A15643@ludwig.cnri.reston.va.us> On 23 June 2000, Jeremy Hylton said: > ldso_aix-- I still don't understand, but I didn't really try; Vladimir must > help This has been fixed in the Distutils. AFAIK it's still broken for Makefile.pre.in builds -- as long as the installed Makefile is fixed (not the actual installation location of ld_so_aix), then Distutils builds will continue to work. (Thanks to Rene Liebscher for providing the Distutils fix, and Vladimir for testing it.) Greg From gward at mems-exchange.org Wed Jun 28 16:29:02 2000 From: gward at mems-exchange.org (Greg Ward) Date: Wed, 28 Jun 2000 10:29:02 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils util.py,1.36,1.37 In-Reply-To: <20000624151824.A29590@lyra.org>; from gstein@lyra.org on Sat, Jun 24, 2000 at 03:18:24PM -0700 References: <200006242040.NAA28315@slayer.i.sourceforge.net> <20000624151824.A29590@lyra.org> Message-ID: <20000628102901.B15643@ludwig.cnri.reston.va.us> On 24 June 2000, Greg Stein said: > Would the "shlex" module be helpful here? It is in the standard library and > is (well?) maintained by ESR. It could help reduce the code inside > distutils. I looked at "shlex", but didn't like the fact that it 1) does character-by-character analysis of input, and 2) requires a file-like object. Just a performance concern, really. > [ I've always questioned the need for distutils' own "copy file" functions > and whatnot... seems there is a bit of duplication occurring... ] Two reasons for that: bugs in the standard library versions, and missing features in the standard library versions. I think the first argument goes away now that I've given up on 1.5.1 compatibility (shutil.py was really broken in 1.5.1), but the fact remains that the copy functions in shutil.py don't have a dry_run option, don't have a verbose option, don't have a preserve_times option, don't have a preserve_symlinks option, etc. All of these things are somewhere between useful and necessary. I'm always open for ideas on reducing the amount of code in the Distutils; it really is getting ridiculous. It cracked 10k lines of code+comments+doc this weekend -- about 5300 lines of straight code, I think. Anyways, the basic required functionality is now in place, so I'm open to clever refactoring/reduction/simplification patches. Greg From guido at beopen.com Wed Jun 28 17:41:26 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 28 Jun 2000 10:41:26 -0500 Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager In-Reply-To: Your message of "Wed, 28 Jun 2000 02:23:40 -0400." References: Message-ID: <200006281541.KAA02041@cj20424-a.reston1.va.home.com> > Since we (PythonLabs, last week) decided to continue using Jitterbug (on > python.org) for now, should the SF Bug Manager even be enabled? If it is > enabled, and we are using Jitterbug, then someone has to own reentering SF > bugs into the Jitterbug system. OK, I've disabled the SF bugs manager. There were two bugs submitted so far. I've assigned one to you (about os.listdir on Windows) and one to MAL (about -U vs. exec/eval). You two can take care of entering these into JB. You can still access the bugs database via this URL: https://sourceforge.net/bugs/?group_id=5470 --Guido van Rossum (home page: http://www.python.org/~guido/) From gward at mems-exchange.org Wed Jun 28 17:35:05 2000 From: gward at mems-exchange.org (Greg Ward) Date: Wed, 28 Jun 2000 11:35:05 -0400 Subject: [Python-Dev] OT: A Day in the Life of p5p In-Reply-To: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid>; from effbot@telia.com on Wed, Jun 28, 2000 at 01:07:24PM +0200 References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> Message-ID: <20000628113505.C15643@ludwig.cnri.reston.va.us> On 28 June 2000, Fredrik Lundh said: > http://prometheus.frii.com/~gnat/yapc/2000-p5p.txt > > unfortunately, his "What is it with those Python fucks anyway" talk > isn't posted... ;-) But the "Conclusion" of his "Lies We Tell" talk: Perl sucks. Use Python. Presumably tongue-in-cheek, but you never know... Greg From trentm at activestate.com Wed Jun 28 18:53:19 2000 From: trentm at activestate.com (Trent Mick) Date: Wed, 28 Jun 2000 09:53:19 -0700 Subject: [Python-Dev] back up & running In-Reply-To: <200006281222.OAA03150@python.inrialpes.fr> References: <14681.56997.50955.892954@cj42289-a.reston1.va.home.com> <200006281222.OAA03150@python.inrialpes.fr> Message-ID: <20000628095319.C14129@activestate.com> On Wed, Jun 28, 2000 at 02:22:56PM +0200, Vladimir Marangozov wrote: > Fred L. Drake, Jr. wrote: > > > > My mega-laptop got fixed faster than I'd expected, so I'm back up to > > doing useful work. My top priorities are handling patches and going > > back through my email to find all the documentation patches that have > > sat idle for too long. > > Excellent! > > Finally someone who cares to checkin patches. I've been disappointed > to see that the June 30 intent-date was announced, but people keep > chewing-gumming about SourceForge caveats while the patches backlog > grows and the number of closed patches stays invariably to 3, of which > one is a test! > You can count me as one of the significatn bottlenecks here. Tim and Guido have accepted some of my patches, I just have to check them in. Real Soon Now (tm). Trent Mick (also tm) -- Trent Mick trentm at activestate.com From mal at lemburg.com Wed Jun 28 18:57:35 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 28 Jun 2000 18:57:35 +0200 Subject: [Python-Dev] Named Unicode Characters Message-ID: <395A2E7F.A1DDEC35@lemburg.com> I've just checked in the patches by Bill Tutt, which add support for \N{NAMED UNICODE CHARACTERS}. The new escape code is available per default in the standard unicode-escape codec. The (big) hash table needed to drive the mapping is loaded on demand to reduce memory overhead. The patch also includes a new tool called perfecthash which is used to generate the hash table (and function) from names to ordinals. I'm sure this can be of use in other areas too... but it needs some more work to become more generic (currently you have to edit the source code to generate other mapping modules). Thanks to Bill Tutt -- this is great work ! -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From paul at prescod.net Wed Jun 28 19:11:19 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 28 Jun 2000 10:11:19 -0700 Subject: [Python-Dev] OT: A Day in the Life of p5p References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> Message-ID: <395A31B7.911D9BC2@prescod.net> Fredrik Lundh wrote: > > http://prometheus.frii.com/~gnat/yapc/2000-p5p.txt How about this one: http://gisle.aas.no/perl/illguts/ Just thank your lucky stars... -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From paul at prescod.net Wed Jun 28 19:16:45 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 28 Jun 2000 10:16:45 -0700 Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager References: Message-ID: <395A32FD.D3C58B23@prescod.net> I don't want to be paranoid, but are we putting any important information into SourceForge that we are not backing up elsewhere? I mean okay, we've all got CVS dumps, but if it went away (DOJ antitrust suit...) would we have backups of our patches, bugs, wish lists and so forth? I hope that's a criteria in deciding what services to move to SourceForge. I am in the business of preserving investments in data and of telling customers to avoid software that does not keep them in complete control of their data. SF makes me nervous that way.... -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From mal at lemburg.com Wed Jun 28 19:22:40 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 28 Jun 2000 19:22:40 +0200 Subject: [Python-Dev] Checkin Utility Message-ID: <395A3460.3FF013F0@lemburg.com> I thought you might have some use for the attached utility. It's a simple script which helps with checking in patches which I've been using for a while now. It also hides the CVS options and parameters away as far as possible, so that CVS knowledge is not really needed to complete the task. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ -------------- next part -------------- A non-text attachment was scrubbed... Name: checkin.py Type: text/python Size: 8070 bytes Desc: not available URL: From esr at thyrsus.com Wed Jun 28 19:38:05 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 28 Jun 2000 13:38:05 -0400 Subject: [Python-Dev] OT: A Day in the Life of p5p In-Reply-To: <395A31B7.911D9BC2@prescod.net>; from paul@prescod.net on Wed, Jun 28, 2000 at 10:11:19AM -0700 References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> <395A31B7.911D9BC2@prescod.net> Message-ID: <20000628133805.D20855@thyrsus.com> Paul Prescod : > http://gisle.aas.no/perl/illguts/ > > Just thank your lucky stars... Ghods. Reading that just about ruined my lunch. -- Eric S. Raymond "The power to tax involves the power to destroy;...the power to destroy may defeat and render useless the power to create...." -- Chief Justice John Marshall, 1819. From paul at prescod.net Wed Jun 28 19:27:54 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 28 Jun 2000 10:27:54 -0700 Subject: [Python-Dev] Text about cycle GC References: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com> Message-ID: <395A359A.2CF0CA70@prescod.net> "A.M. Kuchling" wrote: > > ... > > An experimental step has been made toward fixing this problem. When > compiling Python, the -with-cycle-gc (XXX correct option flag?) option > can be specified. This causes a cycle detection algorithm to be > periodically executed, which looks for inaccessible cycles and deletes > the objects involved. I propose (without any investigation into the difficulty of implementation) that import cyclicgc should turn on the -with-cycle-gc flag. Then you could do a import cyclicgc import someDOM And not worry about cycles. If it's too slow, you remove the line and take responsibility for cycle checking. The important thing is that you don't have to tell YOUR USERS to turn on GC in order for your code to work. I think that this model will get more people actively using (and depending upon!) GC and thus give us a better idea about usage patterns, stability and performance. This is especially important in the beta period when we are trying to shake out bugs. Really, this comes back to Greg's point that we should not have incompatible sub-languages running around. A module depends on the feature or it doesn't. The end-user should not be responsible for knowing whether any module in a whole program needs GC. -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From paul at prescod.net Wed Jun 28 19:34:35 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 28 Jun 2000 10:34:35 -0700 Subject: [Python-Dev] OT: A Day in the Life of p5p References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> <395A31B7.911D9BC2@prescod.net> <20000628133805.D20855@thyrsus.com> Message-ID: <395A372B.34E15A62@prescod.net> "Eric S. Raymond" wrote: > > Ghods. Reading that just about ruined my lunch. You read it? Eric, I was just kidding! Actually, my theory is that the whole thing is a big, extended, April Fools joke. Not the document. The language. (rimshot) SvOOK-vs-SvIV-and-SvNV-indeed-ly 'yrs -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From gmcm at hypernet.com Wed Jun 28 19:37:07 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Wed, 28 Jun 2000 13:37:07 -0400 Subject: [Python-Dev] OT: A Day in the Life of p5p In-Reply-To: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> Message-ID: <1249908601-39717068@hypernet.com> > http://prometheus.frii.com/~gnat/yapc/2000-p5p.txt What I noticed is that Tim is mentioned in every other paragraph. Where-does-he-find-the-time?-ly y'rs - Gordon From jeremy at beopen.com Wed Jun 28 19:41:50 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Wed, 28 Jun 2000 13:41:50 -0400 (EDT) Subject: [Python-Dev] OT: A Day in the Life of p5p In-Reply-To: <395A31B7.911D9BC2@prescod.net> References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> <395A31B7.911D9BC2@prescod.net> Message-ID: <14682.14558.380773.307392@bitdiddle.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> Fredrik Lundh wrote: >> http://prometheus.frii.com/~gnat/yapc/2000-p5p.txt PP> How about this one: PP> http://gisle.aas.no/perl/illguts/ PP> Just thank your lucky stars... What beautiful diagrams! It almost makes me wish Python was complicated enough to require such pretty pictures. Jeremy From guido at beopen.com Wed Jun 28 20:41:48 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 28 Jun 2000 13:41:48 -0500 Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager In-Reply-To: Your message of "Wed, 28 Jun 2000 10:16:45 MST." <395A32FD.D3C58B23@prescod.net> References: <395A32FD.D3C58B23@prescod.net> Message-ID: <200006281841.NAA03154@cj20424-a.reston1.va.home.com> [PP] > I don't want to be paranoid, but are we putting any important > information into SourceForge that we are not backing up elsewhere? I > mean okay, we've all got CVS dumps, but if it went away (DOJ antitrust > suit...) would we have backups of our patches, bugs, wish lists and so > forth? I hope that's a criteria in deciding what services to move to > SourceForge. I am in the business of preserving investments in data and > of telling customers to avoid software that does not keep them in > complete control of their data. SF makes me nervous that way.... Good point. SF has a way to get a nightly snapshot of the CVS tree. We should suggest that they provide snapshots (in XML of course!) of the bugs database too. Note that I have no bandwidth left to communicate to SF folks so this is up to the user community. (I'm also very optimistic and trusting in nature. :-) --Guido van Rossum (home page: http://www.python.org/~guido/) From jeremy at beopen.com Wed Jun 28 19:49:32 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Wed, 28 Jun 2000 13:49:32 -0400 (EDT) Subject: [Python-Dev] Text about cycle GC In-Reply-To: <395A359A.2CF0CA70@prescod.net> References: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com> <395A359A.2CF0CA70@prescod.net> Message-ID: <14682.15020.589514.702145@bitdiddle.concentric.net> >>>>> "PP" == Paul Prescod writes: PP> "A.M. Kuchling" wrote: >> ... >> >> An experimental step has been made toward fixing this >> problem. When compiling Python, the -with-cycle-gc (XXX correct >> option flag?) option can be specified. This causes a cycle >> detection algorithm to be periodically executed, which looks for >> inaccessible cycles and deletes the objects involved. PP> I propose (without any investigation into the difficulty of PP> implementation) that PP> import cyclicgc PP> should turn on the -with-cycle-gc flag. The -with-cycle-gc flag is an option to configure when you build Python. It can't be turned on or off at runtime. We hope that everyone will build with the -with-cycle-gc flag during the beta testing, but we don't expect to have enough confidence in it by final release to make it anything other than an experimental option. Jeremy From esr at thyrsus.com Wed Jun 28 20:02:37 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 28 Jun 2000 14:02:37 -0400 Subject: [Python-Dev] OT: A Day in the Life of p5p In-Reply-To: <395A372B.34E15A62@prescod.net>; from paul@prescod.net on Wed, Jun 28, 2000 at 10:34:35AM -0700 References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> <395A31B7.911D9BC2@prescod.net> <20000628133805.D20855@thyrsus.com> <395A372B.34E15A62@prescod.net> Message-ID: <20000628140237.A21043@thyrsus.com> Paul Prescod : > "Eric S. Raymond" wrote: > > > > Ghods. Reading that just about ruined my lunch. > > You read it? Eric, I was just kidding! Yes, I read it. Un-fscking-believable. I knew Perl was complicated and ugly on the inside, but the full horror had not obtruded itself on me before now. If I'm any judge, that's an implementation on the brink of collapsing under its own weight. -- Eric S. Raymond Non-cooperation with evil is as much a duty as cooperation with good. -- Mohandas Gandhi From paul at prescod.net Wed Jun 28 19:53:16 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 28 Jun 2000 10:53:16 -0700 Subject: [Python-Dev] OT: A Day in the Life of p5p References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> <395A31B7.911D9BC2@prescod.net> <14682.14558.380773.307392@bitdiddle.concentric.net> Message-ID: <395A3B8B.B6117DA1@prescod.net> Note that the document doesn't yet cover the regular expression engine or the "PerlInterpreter". I can't think of a disclaimer that doesn't sound like it is tongue in cheek but I do feel bad about beating up on a design which, in its own way, has a certain kind of quality (just not one I happen to prefer). When you optimize the snot out of things they tend to start looking ugly. Perl runs faster than Python. That's probably not a coincidence. Jeremy Hylton wrote: > > What beautiful diagrams! It almost makes me wish Python was > complicated enough to require such pretty pictures. To be fair, our internals documentation needs some work. I'll bet there are a lot of people in comp.lang.python that would be interested in a project like that or another one, such as adding a full warning infrastructure to Python. I wonder how we could do a Software Carpentry like deal (no money) where we get people to submit designs and ideas and then "award" the job to someone. They could do it for reputational capital and an opportunity to join "the team" (of CVS committers, PythonDev denizens etc.). It's probably better to give people ideas rather than have them implement random things that we will need to turn down. Like stackless. -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From paul at prescod.net Wed Jun 28 20:09:38 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 28 Jun 2000 11:09:38 -0700 Subject: [Python-Dev] Text about cycle GC References: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com> <395A359A.2CF0CA70@prescod.net> <14682.15020.589514.702145@bitdiddle.concentric.net> Message-ID: <395A3F62.EA1E8B89@prescod.net> Jeremy Hylton wrote: > > .... > > The -with-cycle-gc flag is an option to configure when you build > Python. It can't be turned on or off at runtime. Doh! Sorry. Andrew's text does say that but I didn't read carefully and testing it with my stuff hasn't floated to the top yet (because when I looked into it, I realized I'd have to recompile...double doh!) Compiling is really slow on my "transitional" computer. I'm a little disappointed that it will be so difficult for people to test with GC on, but I'm not going to claim that there is some easy way to make it a runtime option because I haven't looked at it at all. There probably isn't. -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From nascheme at enme.ucalgary.ca Wed Jun 28 20:27:25 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Wed, 28 Jun 2000 12:27:25 -0600 Subject: [Python-Dev] Text about cycle GC In-Reply-To: <395A3F62.EA1E8B89@prescod.net>; from paul@prescod.net on Wed, Jun 28, 2000 at 11:09:38AM -0700 References: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com> <395A359A.2CF0CA70@prescod.net> <14682.15020.589514.702145@bitdiddle.concentric.net> <395A3F62.EA1E8B89@prescod.net> Message-ID: <20000628122725.A13473@acs.ucalgary.ca> On Wed, Jun 28, 2000 at 11:09:38AM -0700, Paul Prescod wrote: > I'm a little disappointed that it will be so difficult for people to > test with GC on, but I'm not going to claim that there is some easy way > to make it a runtime option because I haven't looked at it at all. There > probably isn't. There isn't. With an interpreter compiled --with-cycle-gc you can turn off the collection with gc.set_threshold(0) but that's not the same thing. Neil From bwarsaw at beopen.com Wed Jun 28 20:33:23 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 28 Jun 2000 14:33:23 -0400 (EDT) Subject: [Python-Dev] OT: A Day in the Life of p5p References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> <395A31B7.911D9BC2@prescod.net> <20000628133805.D20855@thyrsus.com> <395A372B.34E15A62@prescod.net> <20000628140237.A21043@thyrsus.com> Message-ID: <14682.17651.552666.318592@anthem.concentric.net> >>>>> "ESR" == Eric S Raymond writes: ESR> Yes, I read it. Un-fscking-believable. I knew Perl was ESR> complicated and ugly on the inside, but the full horror had ESR> not obtruded itself on me before now. If I'm any judge, ESR> that's an implementation on the brink of collapsing under its ESR> own weight. And of course, we'll be right there to pick up the pieces. :) From guido at beopen.com Wed Jun 28 21:43:06 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 28 Jun 2000 14:43:06 -0500 Subject: [Python-Dev] Python 1.6 schedule Message-ID: <200006281943.OAA03414@cj20424-a.reston1.va.home.com> I've updated the 1.6 page on python.org (http://www.python.org/1.6/) to include the latest schedule for 1.6. I've also included a link to Andrew's "what's new" article. Here's the new schedule in text form: July 1: beta 1; feature freeze. July 14: beta 2, in time for the O'Reilly Open Source Software Convention. August 1: release candidate. August 15: final release. I'm happy with how the patches are coming along today (/F even submitted the SRE patch...). We may actually have a release party Saturday! --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at beopen.com Wed Jun 28 22:27:43 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 28 Jun 2000 15:27:43 -0500 Subject: [Python-Dev] Named Unicode Characters In-Reply-To: Your message of "Wed, 28 Jun 2000 18:57:35 +0200." <395A2E7F.A1DDEC35@lemburg.com> References: <395A2E7F.A1DDEC35@lemburg.com> Message-ID: <200006282027.PAA04607@cj20424-a.reston1.va.home.com> > I've just checked in the patches by Bill Tutt, which add > support for \N{NAMED UNICODE CHARACTERS}. The new escape > code is available per default in the standard unicode-escape > codec. The (big) hash table needed to drive the mapping > is loaded on demand to reduce memory overhead. > > The patch also includes a new tool called perfecthash which > is used to generate the hash table (and function) from > names to ordinals. I'm sure this can be of use in other > areas too... but it needs some more work to become more > generic (currently you have to edit the source code to generate > other mapping modules). > > Thanks to Bill Tutt -- this is great work ! Thanks Bill and Marc-Andre! I've closed the patch in SF now. --Guido van Rossum (home page: http://www.python.org/~guido/) From tim_one at email.msn.com Wed Jun 28 21:40:18 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 28 Jun 2000 15:40:18 -0400 Subject: [Python-Dev] back up & running In-Reply-To: <20000628095319.C14129@activestate.com> Message-ID: [Vladimir Marangozov] > ... > I've been disappointed to see that the June 30 intent-date was > announced, but people keep chewing-gumming about SourceForge > caveats while the patches backlog grows and the number of closed > patches stays invariably to 3, of which one is a test! Absolutely on-target, Vladimir! The current state of our world is embarrassing. Someday when the bosses aren't listening, I'll explain to you how it got this way <0.9 wink>. [Trent Mick] > You can count me as one of the significant bottlenecks here. Tim and > Guido have accepted some of my patches, I just have to check them in. > Real Soon Now (tm). Trent, you are *not* a bottleneck! You've cooperated with the process (or lack thereof) every step of the way, and it hasn't even been 12 hours since I accepted some of your patches. And the bulk of them are still on my plate to review. I don't think we have an actual bottleneck now, but we do have a large backlog to work off, and people with too many things that need to be done. perseverance-and-patience-will-probably-work-better-than-their-opposites-ly y'rs - tim From gstein at lyra.org Wed Jun 28 21:46:06 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 28 Jun 2000 12:46:06 -0700 Subject: [Python-Dev] add Demo/imputil/importers.py ? In-Reply-To: <200006281455.JAA01690@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Wed, Jun 28, 2000 at 09:55:00AM -0500 References: <20000627184615.A29590@lyra.org> <200006281455.JAA01690@cj20424-a.reston1.va.home.com> Message-ID: <20000628124606.K29590@lyra.org> On Wed, Jun 28, 2000 at 09:55:00AM -0500, Guido van Rossum wrote: > > A while back, I pulled the "demo" importers out of imputil.py. I think those > > should be added into Demo/imputil/. > > OK. Go ahead and create that directory and add the demo importers. Will do. > > It would also be Goodness to include JimA's zipimporter. Where would that go? > > Same place I'd hope? Can you check that it works? Yup and yup. > We're dependent on you volunteers to maintain relatively non-core > things like this -- I don't want to extend the feature freeze to > Demo/, but I also don't have the time to keep the stuff there up to > date. Not a problem, and I had figured on being the "point man" on keeping it working. My query here was more along the lines of "is Demo/imputil/ a good idea? If so, then I'll run with it." You said "yes", so I'll go put on my shoes. > Maybe at some point the Demo directory should become a separate > distribution, or just a collection of stuff on the web? I believe a separate distribution. Unpacking the bugger to the main web site would also be a good option, but that would be a second priority. I'd throw Tools into the same thing. As a separate distro, you can have a faster release cycle. ... you could release Idle updates easily and distinctly from the Python core. Note: by a "collection on the web", the only view that I have, is that the collection exists on the python.org web site. Distributed pieces "here and there" is handled by the Vaults (and similar). The Demo/ directory is a bit more newbie-ish, so (IMO) it ought to get bundled up somehow since the Vaults are a bit daunting to find "example of embedding". If the bundle also happens to reside in an obvious area on python.org? Great. Cheers, -g -- Greg Stein, http://www.lyra.org/ From tim_one at email.msn.com Wed Jun 28 21:54:42 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 28 Jun 2000 15:54:42 -0400 Subject: [Python-Dev] OT: A Day in the Life of p5p In-Reply-To: <395A31B7.911D9BC2@prescod.net> Message-ID: [Paul Prescod] > How about this one: > > http://gisle.aas.no/perl/illguts/ > Just thank your lucky stars... Ack, don't get me started -- well, I'd love to, but have real work to do. I've posted about that before. I'm not infrequently amazed that they manage to keep Perl running at all. The amazing thing about the PerlGuts doc above is that it was apparently reverse-engineered by staring at Perl's implementation code. You can't find any of it explained in the source! either-those-guys-are-nuts-or-they're-a-*whole*-lot-smarter- than-us-and-i-know-which-of-those-i'm-more-likely-to- believe-ly y'rs - tim From guido at beopen.com Wed Jun 28 22:59:46 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 28 Jun 2000 15:59:46 -0500 Subject: [Python-Dev] Text about cycle GC In-Reply-To: Your message of "Wed, 28 Jun 2000 12:27:25 CST." <20000628122725.A13473@acs.ucalgary.ca> References: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com> <395A359A.2CF0CA70@prescod.net> <14682.15020.589514.702145@bitdiddle.concentric.net> <395A3F62.EA1E8B89@prescod.net> <20000628122725.A13473@acs.ucalgary.ca> Message-ID: <200006282059.PAA04852@cj20424-a.reston1.va.home.com> > On Wed, Jun 28, 2000 at 11:09:38AM -0700, Paul Prescod wrote: > > I'm a little disappointed that it will be so difficult for people to > > test with GC on, but I'm not going to claim that there is some easy way > > to make it a runtime option because I haven't looked at it at all. There > > probably isn't. > > There isn't. With an interpreter compiled --with-cycle-gc you can > turn off the collection with gc.set_threshold(0) but that's not > the same thing. > > Neil I wonder if we should turn this option *on* during beta testing? That way we gather a lot more experience with its use! Maybe nobody complains and we can leave it on in the final release... --Guido van Rossum (home page: http://www.python.org/~guido/) From akuchlin at mems-exchange.org Wed Jun 28 22:10:28 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Wed, 28 Jun 2000 16:10:28 -0400 Subject: [Python-Dev] OT: A Day in the Life of p5p In-Reply-To: <395A3B8B.B6117DA1@prescod.net> References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> <395A31B7.911D9BC2@prescod.net> <14682.14558.380773.307392@bitdiddle.concentric.net> <395A3B8B.B6117DA1@prescod.net> Message-ID: <20000628161028.C23352@kronos.cnri.reston.va.us> On Wed, Jun 28, 2000 at 10:53:16AM -0700, Paul Prescod wrote: >Note that the document doesn't yet cover the regular expression engine >or the "PerlInterpreter". The regex engine's pretty hard to read, mostly because comments are infrequent and not very helpful, and disentangling it from the rest of Perl would require a skilled wizard. (PCRE, if slower, is at least much clearer and easier to understand, though the compile() function is pretty ugly.) A while ago I saw a p5p post from Ilya Zakharevich who did most of the recent regex hacking; he draw attention to one flag variable in the code and said basically "I don't know what this flag means; I think it's some sort of UTF-8 setting, but Larry didn't explain it." >I can't think of a disclaimer that doesn't sound like it is tongue in >cheek but I do feel bad about beating up on a design which, in its own >way, has a certain kind of quality (just not one I happen to prefer). Agreed; it could be made much simpler, but maybe at a performance cost. (Though performance is tricky, and maybe the extra work costs more than it saves.) For example, note the flag bits in SvNULL, which have values like GMAGICAL. You could imagine a Python implementation that added flag bits to every object, and set a bit if there was a __getattr__ method defined; code could then do 'if (obj->flags & GMAGICAL) ...' instead of the more complicated 'if (PyObject_HasAttrString(obj, "__getattr__")'. It would be interesting to know if Topaz, Chip Salzenberg's experimental C++ implementation, preserves this complexity or aims to cut it away. The use of several levels of C structs is also reminiscent of the way you do OO in C, as in X toolkits. You can also see the importance of text processing in the SvPVBM type, for attaching a Boyer-Moore related table to a string and speeding up regex searches. --amk From tim_one at email.msn.com Wed Jun 28 22:15:34 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 28 Jun 2000 16:15:34 -0400 Subject: [Python-Dev] OT: A Day in the Life of p5p In-Reply-To: <395A3B8B.B6117DA1@prescod.net> Message-ID: [Paul Prescod] > ... > When you optimize the snot out of things they tend to start looking > ugly. Perl runs faster than Python. That's probably not a coincidence. More, IMO it's not even true. I can't make time for this now, but on several occasions I've coded the same algorithm in idiomatic Perl and Python, and Python was invariably faster (not talking orders of magnitude, but 10-40%). The catch is that I know something about both implementations, and avoided the sweet spots in both. Perl gets enormous bang out of its line-at-a-time text file input "cheating", and its integrated regexps. Avoid those, and it's generally *slower* in my experience, which is perfectly consistent with the relative messiness of its implementation (all those magic flags aren't passive, they need runtime conditionals to use! Perl can't even inline its refcount manipulations because they're so complicated due to the flags). Against that, line-at-a-time text file input in particular is something that every newbie bumps into at once, and Perl does have a monster advantage there (at least 2x faster, probably closer to 3 on most platforms). Perl doesn't really look like it was designed to "be fast" in general -- it looks like it was designed to be supernaturally fast in specific situations. Best I've been able to tell, that's how it *acts*, too. I'm keen to add comparable (but limited) internal warts to Python, but for *general* speedup ideas we'll be much better off looking to, e.g., Dylan and Squeak. all-that-said-python-is-fast-enough-for-me-already!-ly y'rs - tim From DavidA at ActiveState.com Wed Jun 28 22:17:46 2000 From: DavidA at ActiveState.com (David Ascher) Date: Wed, 28 Jun 2000 13:17:46 -0700 Subject: [Python-Dev] OT: A Day in the Life of p5p In-Reply-To: Message-ID: > either-those-guys-are-nuts-or-they're-a-*whole*-lot-smarter- > than-us-and-i-know-which-of-those-i'm-more-likely-to- > believe-ly y'rs - tim I was sitting next to Gisle (the author of said document) when he started to work on the Perl methods work for Zope. Within a day, starting w/ not knowing anything about Python, he had Perl embedded in Python. It says much about the cleanliness of Python's design and the quality of its documentation that Gisle could do that. It also says a lot about Gisle, as does the perlguts document Not saying anything about anyone being nuts, especially when responding to someone who talks about his in public. --david From pingster at ilm.com Wed Jun 28 22:22:15 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Wed, 28 Jun 2000 13:22:15 -0700 (PDT) Subject: [Python-Dev] OT: A Day in the Life of p5p In-Reply-To: <20000628161028.C23352@kronos.cnri.reston.va.us> Message-ID: On Wed, 28 Jun 2000, Andrew Kuchling wrote: > You could imagine a Python implementation that added flag > bits to every object, and set a bit if there was a __getattr__ method > defined; code could then do 'if (obj->flags & GMAGICAL) ...' instead > of the more complicated 'if (PyObject_HasAttrString(obj, > "__getattr__")'. That looks like a reasonable sort of optimization to me, though as far as i can tell it looks like that optimization has already been done: in PyClass_New(bases, dict, name): [...] op->cl_getattr = class_lookup(op, getattrstr, &dummy); [...] in instance_getattr(inst, name): if (res == NULL && (func = inst->in_class->cl_getattr) != NULL) { [...special __getattr__ handling...] } In general, optimizations of the form "add a flag to avoid a frequent expensive test" seem okay to me, as long they are a demonstrable win and the flag can be given a clear, simple name. -- ?!ng "To be human is to continually change. Your desire to remain what you are is what ultimately limits you." -- The Puppet Master, Ghost in the Shell From akuchlin at mems-exchange.org Wed Jun 28 22:25:54 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Wed, 28 Jun 2000 16:25:54 -0400 Subject: [Python-Dev] OT: A Day in the Life of p5p In-Reply-To: References: <20000628161028.C23352@kronos.cnri.reston.va.us> Message-ID: <20000628162554.E23352@kronos.cnri.reston.va.us> On Wed, Jun 28, 2000 at 01:22:15PM -0700, Ka-Ping Yee wrote: >That looks like a reasonable sort of optimization to me, though >as far as i can tell it looks like that optimization has already >been done: Damn time machine again... --amk From tim_one at email.msn.com Wed Jun 28 22:31:58 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 28 Jun 2000 16:31:58 -0400 Subject: SourceForge patch notifications (was RE: [Python-Dev] ANN: Release schedule) In-Reply-To: <20000628090230.A14129@activestate.com> Message-ID: [Trent Mick] > ... > BTW I have answered a couple a questions on my patches. Does > the person to whom the patch is assigned get an update notification? Trent & I investigated this offline: he added a comment to one of his patches to which I am assigned. I did indeed get prompt email notification, although as everyone has noticed by now, there's no indication from SF about *why* I was getting notified; just: From: noreply at sourceforge.net [mailto:noreply at sourceforge.net] Sent: Wednesday, June 28, 2000 12:01 PM To: tmick at mail.com; tim_one at email.msn.com Subject: [Patch #100513] fix posixmodule for 64-bit systems (mainly Win64) Patch #100513 has been updated. Visit SourceForge.net for more info. http://sourceforge.net/patch/?func=detailpatch&patch_id=100513&group_id=5470 So the outcome could have been worse . a-new-criterion-for-excellence-ly y'rs - tim From effbot at telia.com Wed Jun 28 22:42:56 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 28 Jun 2000 22:42:56 +0200 Subject: [Python-Dev] OT: A Day in the Life of p5p References: Message-ID: <033a01bfe141$71b0cfc0$f2a6b5d4@hagrid> tim wrote: > Against that, line-at-a-time text file input in particular is something that > every newbie bumps into at once, and Perl does have a monster advantage > there (at least 2x faster, probably closer to 3 on most platforms). and 2-3x is what you get if you replace readline with readlines, as described in this note: http://w1.132.telia.com/~u13208596/notes/readline-performance.htm it would be very nice if the file object could do something similar internally (only in text mode, perhaps). maybe in 1.7? (as I've mentioned earlier, SRE+faster IO can result in a 10x speedup for a straightforward while/readline/match loop...) From jack at oratrix.nl Wed Jun 28 22:58:27 2000 From: jack at oratrix.nl (Jack Jansen) Date: Wed, 28 Jun 2000 22:58:27 +0200 Subject: [Python-Dev] ucnhash module Message-ID: <20000628205832.C3234E2673@oratrix.oratrix.nl> I'm a bit worried about the ucnhash module and its huge size. I didn't follow the discussion closely at the time, because I thought I could always exclude it from the Pythons without dynamic linking, but now it seems that if i don't include it test_unicode doesn't run anymore. Is this a problem with test_unicode, or should I consider ucnhash a mandatory module? (BTW: there were also a couple of bugs in the module, include <> in stead of include "", and static in stead of staticforward declarations, I'll submit patches for those shortly). -- 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/ ++++ From gstein at lyra.org Wed Jun 28 23:03:42 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 28 Jun 2000 14:03:42 -0700 Subject: [Python-Dev] OT: A Day in the Life of p5p In-Reply-To: <033a01bfe141$71b0cfc0$f2a6b5d4@hagrid>; from effbot@telia.com on Wed, Jun 28, 2000 at 10:42:56PM +0200 References: <033a01bfe141$71b0cfc0$f2a6b5d4@hagrid> Message-ID: <20000628140342.Q29590@lyra.org> On Wed, Jun 28, 2000 at 10:42:56PM +0200, Fredrik Lundh wrote: > tim wrote: > > Against that, line-at-a-time text file input in particular is something that > > every newbie bumps into at once, and Perl does have a monster advantage > > there (at least 2x faster, probably closer to 3 on most platforms). > > and 2-3x is what you get if you replace readline with readlines, > as described in this note: > http://w1.132.telia.com/~u13208596/notes/readline-performance.htm > > it would be very nice if the file object could do something similar > internally (only in text mode, perhaps). maybe in 1.7? That could be troublesome. It should only be done if the file is seekable so that you can rewind. If a readline() on (say) a socket moved you *past* the newline, then you could be in big trouble. Or what happens in said socket is blocking? etc. Now... please don't start a thread about this now. Wait for post 1.6. Maybe I'm totally off, and some smart guy here can say so. But it just doesn't matter, so I'd rather not have to read a whole thread on the stuff :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Wed Jun 28 23:14:41 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 28 Jun 2000 14:14:41 -0700 Subject: [Python-Dev] PyOS_AfterFork() (was: CVS: python/dist/src/Doc/api api.tex,1.68,1.69) In-Reply-To: <200006281553.IAA11238@slayer.i.sourceforge.net>; from fdrake@users.sourceforge.net on Wed, Jun 28, 2000 at 08:53:17AM -0700 References: <200006281553.IAA11238@slayer.i.sourceforge.net> Message-ID: <20000628141441.R29590@lyra.org> Woah. Never knew this was in Python. It is quite interesting, as there is a very similar concept within Apache. In that model, you register a cleanup function for the particular data that needs to be cleaned post-fork. After the fork occurs, the cleanups are called. In essence, Python would register PyOS_AfterFork. Of course, any schmoe can call fork() and avoid the cleanups, so it bungs up the whole scheme. In Apache, the "only" way to fork is to call an APR function, which guarantees the cleanups. Cheers, -g On Wed, Jun 28, 2000 at 08:53:17AM -0700, Fred L. Drake wrote: > Update of /cvsroot/python/python/dist/src/Doc/api > In directory slayer.i.sourceforge.net:/tmp/cvs-serv11228/api > > Modified Files: > api.tex > Log Message: > > Added documentation for PyOS_AfterFork(). > > > Index: api.tex > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Doc/api/api.tex,v > retrieving revision 1.68 > retrieving revision 1.69 > diff -C2 -r1.68 -r1.69 > *** api.tex 2000/06/18 05:21:21 1.68 > --- api.tex 2000/06/28 15:53:13 1.69 > *************** > *** 1034,1037 **** > --- 1034,1044 ---- > \end{cfuncdesc} > > + \begin{cfuncdesc}{void}{PyOS_AfterFork}{} > + Function to update some internal state after a process fork; this > + should be called in the new process if the Python interpreter will > + continue to be used. If a new executable is loaded into the new > + process, this function does not need to be called. > + \end{cfuncdesc} > + > > \section{Process Control \label{processControl}} > > > _______________________________________________ > Python-checkins mailing list > Python-checkins at python.org > http://www.python.org/mailman/listinfo/python-checkins -- Greg Stein, http://www.lyra.org/ From effbot at telia.com Wed Jun 28 23:19:36 2000 From: effbot at telia.com (Fredrik Lundh) Date: Wed, 28 Jun 2000 23:19:36 +0200 Subject: [Python-Dev] exceptions trouble Message-ID: <036201bfe146$90b7fb00$f2a6b5d4@hagrid> import traceback try: raise SyntaxError, "argument" except: traceback.print_exc() prints: Traceback (most recent call last): File "test.py", line 3, in ? raise SyntaxError, "argument" Traceback (most recent call last): File "test.py", line 5, in ? traceback.print_exc() File "C:\py16\lib\traceback.py", line 182, in print_exc print_exception(etype, value, tb, limit, file) File "C:\py16\lib\traceback.py", line 110, in print_exception lines = format_exception_only(etype, value) File "C:\py16\lib\traceback.py", line 169, in format_exception_only list.append('%s: %s\n' % (str(stype), str(value))) SystemError: new style getargs format but argument is not a tuple not really what I expected. am I out of sync, or have I stumbled upon a bug in the new exceptions code? From tim_one at email.msn.com Wed Jun 28 23:21:52 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 28 Jun 2000 17:21:52 -0400 Subject: [Python-Dev] OT: A Day in the Life of p5p In-Reply-To: <20000628140342.Q29590@lyra.org> Message-ID: [Greg Stein] > ... > Now... please don't start a thread about this now. Wait for post > 1.6. Amen. > Maybe I'm totally off, and some smart guy here can say so. But it > just doesn't matter, so I'd rather not have to read a whole thread > on the stuff :-) If you change your mind, you can go back in the archives and read at least two old threads on the topic -- it's not like there's actually anything new here . From akuchlin at mems-exchange.org Wed Jun 28 23:30:38 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Wed, 28 Jun 2000 17:30:38 -0400 Subject: [Python-Dev] exceptions trouble In-Reply-To: <036201bfe146$90b7fb00$f2a6b5d4@hagrid> References: <036201bfe146$90b7fb00$f2a6b5d4@hagrid> Message-ID: <20000628173038.B28659@kronos.cnri.reston.va.us> On Wed, Jun 28, 2000 at 11:19:36PM +0200, Fredrik Lundh wrote: >SystemError: new style getargs format but argument is not a tuple >not really what I expected. am I out of sync, or have I >stumbled upon a bug in the new exceptions code? It works fine in my current copy of the CVS tree, and I think I rebuilt everything this morning. --amk From fdrake at beopen.com Wed Jun 28 23:32:36 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Wed, 28 Jun 2000 17:32:36 -0400 (EDT) Subject: [Python-Dev] PyOS_AfterFork() (was: CVS: python/dist/src/Doc/api api.tex,1.68,1.69) In-Reply-To: <20000628141441.R29590@lyra.org> References: <200006281553.IAA11238@slayer.i.sourceforge.net> <20000628141441.R29590@lyra.org> Message-ID: <14682.28404.125379.249287@cj42289-a.reston1.va.home.com> Greg Stein writes: > Woah. Never knew this was in Python. I didn't either, until I read a patch that used it. That's one way to keep the documentation up to date! ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From gstein at lyra.org Wed Jun 28 23:48:00 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 28 Jun 2000 14:48:00 -0700 Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163) In-Reply-To: <200006282112.OAA03095@slayer.i.sourceforge.net>; from gvanrossum@users.sourceforge.net on Wed, Jun 28, 2000 at 02:12:28PM -0700 References: <200006282112.OAA03095@slayer.i.sourceforge.net> Message-ID: <20000628144800.T29590@lyra.org> On Wed, Jun 28, 2000 at 02:12:28PM -0700, Guido van Rossum wrote: >... > - chunk #2: > The id() function guarantees a unique return value for different > objects. It does this by returning the pointer to the object. By > returning a PyInt, on Win64 (sizeof(long) < sizeof(void*)) the pointer > is truncated and the guarantee may be proven false. The appropriate > return function is PyLong_FromVoidPtr, this returns a PyLong if that > is necessary to return the pointer without truncation. > > [GvR: note that this means that id() can now return a long on Win32 > platforms. This *might* break some code...] Strictly speaking: the Long only occurs on Win64 platforms. I would guess that it is also possible on say, an Alpha running Linux. Presuming that has 64-bit pointers(?). Regardless: yes, it can certainly break some code. IMO, if any code out there makes any kinds of assumptions about id(), then they deserve to be broken :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From paul at prescod.net Wed Jun 28 23:44:33 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 28 Jun 2000 14:44:33 -0700 Subject: [Python-Dev] OT: A Day in the Life of p5p References: <033a01bfe141$71b0cfc0$f2a6b5d4@hagrid> <20000628140342.Q29590@lyra.org> Message-ID: <395A71C1.A4E332D@prescod.net> Re: Performance At the very least this readlines() optimization should be in FileInput which was invented, after all, in order to compete with Perl. --- Re: Inline Unicode smily faces Bill and Mark-Andre, you rock. Another feature stolen from Perl. If only it were as easy to steal cleanliness and elegance. :) --- Re: GC On by default in beta would be peachy. -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From bwarsaw at beopen.com Thu Jun 29 00:01:00 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Wed, 28 Jun 2000 18:01:00 -0400 (EDT) Subject: [Python-Dev] exceptions trouble References: <036201bfe146$90b7fb00$f2a6b5d4@hagrid> <20000628173038.B28659@kronos.cnri.reston.va.us> Message-ID: <14682.30108.714768.740415@anthem.concentric.net> >>>>> "AK" == Andrew Kuchling writes: AK> It works fine in my current copy of the CVS tree, and I think AK> I rebuilt everything this morning. Same here. From trentm at activestate.com Thu Jun 29 00:04:28 2000 From: trentm at activestate.com (Trent Mick) Date: Wed, 28 Jun 2000 15:04:28 -0700 Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163) In-Reply-To: <20000628144800.T29590@lyra.org> References: <200006282112.OAA03095@slayer.i.sourceforge.net> <20000628144800.T29590@lyra.org> Message-ID: <20000628150428.E17875@activestate.com> On Wed, Jun 28, 2000 at 02:48:00PM -0700, Greg Stein wrote: > Regardless: yes, it can certainly break some code. IMO, if any code out > there makes any kinds of assumptions about id(), then they deserve to be > broken :-) Amen. Trent -- Trent Mick trentm at activestate.com From nascheme at enme.ucalgary.ca Thu Jun 29 00:07:43 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Wed, 28 Jun 2000 16:07:43 -0600 Subject: [Python-Dev] id() on Win64 Message-ID: <20000628160743.A16262@acs.ucalgary.ca> [Greg Stein] >Strictly speaking: the Long only occurs on Win64 platforms. > >I would guess that it is also possible on say, an Alpha running >Linux. Presuming that has 64-bit pointers(?). I think the Alpha is okay. The problem is strange type models were int is 32 bits and pointers are 64. AFAIK, the Alpha uses 64 bits for both. Neil From guido at beopen.com Thu Jun 29 01:10:52 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 28 Jun 2000 18:10:52 -0500 Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163) In-Reply-To: Your message of "Wed, 28 Jun 2000 14:48:00 MST." <20000628144800.T29590@lyra.org> References: <200006282112.OAA03095@slayer.i.sourceforge.net> <20000628144800.T29590@lyra.org> Message-ID: <200006282310.SAA05850@cj20424-a.reston1.va.home.com> > > [GvR: note that this means that id() can now return a long on Win32 > > platforms. This *might* break some code...] > > Strictly speaking: the Long only occurs on Win64 platforms. You're right. > I would guess that it is also possible on say, an Alpha running Linux. > Presuming that has 64-bit pointers(?). No, because their longs are also 64 bits, and hence so are Python ints. > Regardless: yes, it can certainly break some code. IMO, if any code out > there makes any kinds of assumptions about id(), then they deserve to be > broken :-) That depends. It is documented as an integer -- which may be vague enough to encompass longs, but that's weasel-wording. ;-) I do think that the likelihood of this breaking significant code is low. --Guido van Rossum (home page: http://www.python.org/~guido/) From gstein at lyra.org Thu Jun 29 00:17:58 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 28 Jun 2000 15:17:58 -0700 Subject: [Python-Dev] PyString_GET_SIZE() (was: CVS: python/dist/src/Objects classobject.c,2.89,2.90 object.c,2.72,2.73) In-Reply-To: <200006282157.OAA05880@slayer.i.sourceforge.net>; from gvanrossum@users.sourceforge.net on Wed, Jun 28, 2000 at 02:57:20PM -0700 References: <200006282157.OAA05880@slayer.i.sourceforge.net> Message-ID: <20000628151758.X29590@lyra.org> On Wed, Jun 28, 2000 at 02:57:20PM -0700, Guido van Rossum wrote: > Update of /cvsroot/python/python/dist/src/Objects > In directory slayer.i.sourceforge.net:/tmp/cvs-serv5838 > > Modified Files: > classobject.c object.c > Log Message: > Trent Mick: change a few casts for Win64 compatibility. > > > Index: classobject.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Objects/classobject.c,v > retrieving revision 2.89 > retrieving revision 2.90 > diff -C2 -r2.89 -r2.90 > *** classobject.c 2000/06/23 19:37:01 2.89 > --- classobject.c 2000/06/28 21:57:18 2.90 > *************** > *** 284,288 **** > if (v == NULL || !PyString_Check(v)) > return "__name__ must be a string object"; > ! if ((long)strlen(PyString_AS_STRING(v)) != PyString_GET_SIZE(v)) > return "__name__ must not contain null bytes"; > set_slot(&c->cl_name, v); > --- 284,288 ---- > if (v == NULL || !PyString_Check(v)) > return "__name__ must be a string object"; > ! if (strlen(PyString_AS_STRING(v)) != (size_t)PyString_GET_SIZE(v)) > return "__name__ must not contain null bytes"; > set_slot(&c->cl_name, v); Actually, it would seem to make more sense to place the cast *inside* the PyString_GET_SIZE() macro. That is the "true" semantic for GET_SIZE. May as well start some ANSI-fication while we can... Guido: any problem with my changing the macro? Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Thu Jun 29 00:16:17 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 28 Jun 2000 15:16:17 -0700 Subject: [Python-Dev] httplib doc (was: CVS: python/dist/src/Doc/lib libhttplib.tex,1.19,1.20) In-Reply-To: <200006282151.OAA05489@slayer.i.sourceforge.net>; from fdrake@users.sourceforge.net on Wed, Jun 28, 2000 at 02:51:46PM -0700 References: <200006282151.OAA05489@slayer.i.sourceforge.net> Message-ID: <20000628151617.W29590@lyra.org> Please mark me for a TODO to update the httplib doc. For example, the code below is more effectively written as: h = httplib.HTTPConnection('www.musi-cal.com') h.request('POST', '/cgi-bin/query', paramstring, {'Accept': 'text/plain'}) response = h.getresponse() print response.status # should be 200 data = response.read() # get the raw HTML Note that 'Accept' is usually not a required header and can be omitted in most scenarios. I left it in the example simply to show how to fully map between the old/new APIs. [ Content-Length and Host are sent automatically by HTTPConnection. ] Cheers, -g On Wed, Jun 28, 2000 at 02:51:46PM -0700, Fred L. Drake wrote: > Update of /cvsroot/python/python/dist/src/Doc/lib > In directory slayer.i.sourceforge.net:/tmp/cvs-serv5474/lib > > Modified Files: > libhttplib.tex > Log Message: > > Skip Montanaro : > Added an example of using an HTTP POST request. > > > Index: libhttplib.tex > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Doc/lib/libhttplib.tex,v > retrieving revision 1.19 > retrieving revision 1.20 > diff -C2 -r1.19 -r1.20 > *** libhttplib.tex 1999/04/22 16:47:27 1.19 > --- libhttplib.tex 2000/06/28 21:51:43 1.20 > *************** > *** 115,119 **** > \nodename{HTTP Example} > > ! Here is an example session: > > \begin{verbatim} > --- 115,119 ---- > \nodename{HTTP Example} > > ! Here is an example session that uses the \samp{GET} method: > > \begin{verbatim} > *************** > *** 129,131 **** > --- 129,148 ---- > >>> data = f.read() # Get the raw HTML > >>> f.close() > + \end{verbatim} > + > + Here is an example session that shows how to \samp{POST} requests: > + > + \begin{verbatim} > + >>> import httplib, urllib > + >>> params = urllib.urlencode({'spam': 1, 'eggs': 2, 'bacon': 0}) > + >>> h = httplib.HTTP("www.musi-cal.com:80") > + >>> h.putrequest("POST", "/cgi-bin/query") > + >>> h.putheader("Content-length", "%d" % len(params)) > + >>> h.putheader('Accept', 'text/plain') > + >>> h.putheader('Host', 'www.musi-cal.com') > + >>> h.endheaders() > + >>> h.send(paramstring) > + >>> reply, msg, hdrs = h.getreply() > + >>> print errcode # should be 200 > + >>> data = h.getfile().read() # get the raw HTML > \end{verbatim} > > > _______________________________________________ > Python-checkins mailing list > Python-checkins at python.org > http://www.python.org/mailman/listinfo/python-checkins -- Greg Stein, http://www.lyra.org/ From mal at lemburg.com Thu Jun 29 00:38:29 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 29 Jun 2000 00:38:29 +0200 Subject: [Python-Dev] ucnhash module References: <20000628205832.C3234E2673@oratrix.oratrix.nl> Message-ID: <395A7E65.2271C723@lemburg.com> Jack Jansen wrote: > > I'm a bit worried about the ucnhash module and its huge size. I didn't > follow the discussion closely at the time, because I thought I could > always exclude it from the Pythons without dynamic linking, but now it > seems that if i don't include it test_unicode doesn't run anymore. > > Is this a problem with test_unicode, or should I consider ucnhash a > mandatory module? The ucnhash module is loaded on demand to avoid memory bloat. In practice the difference is not really noticeable since loading a shared module or swapping in a few pages of static C data result in pretty much the same overall memory usage. If no-one complains, I'll fix the test suite though to make the tests of the named Unicode characters optional. Is this ok with you, Bill ? > (BTW: there were also a couple of bugs in the module, include <> in > stead of include "", and static in stead of staticforward > declarations, I'll submit patches for those shortly). I didn't have any problem compiling the module (don't even get warnings when compiling with -Wall) ... but you're right: these ought to get fixed. BTW, since ucnhash.h|c are generated using the scripts in Tools/perfecthash/ your patch should probably also fix the instances of the problems found in there. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From tim_one at email.msn.com Thu Jun 29 00:47:04 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 28 Jun 2000 18:47:04 -0400 Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163) In-Reply-To: <20000628150428.E17875@activestate.com> Message-ID: [Greg Stein] > Regardless: yes, it can certainly break some code. IMO, if any code out > there makes any kinds of assumptions about id(), then they deserve to be > broken :-) [Trent Mick] > Amen. Guys, it's almost never that simple, and developers are the last ones to think of the reasonable cases that may break. In this case, e.g., code may be doing something as harmless as printing an id() via a "... %d ..." format in a log, and-- BOOM! --that blows up with an OverflowError if you feed it a Python long larger than a C long. I'd rather fix %d formats than leave id() broken, though! id() has to return a unique value. but-i'll-sympathize-with-the-users-even-in-public-ly y'rs - tim From trentm at activestate.com Thu Jun 29 01:49:55 2000 From: trentm at activestate.com (Trent Mick) Date: Wed, 28 Jun 2000 16:49:55 -0700 Subject: [Python-Dev] PyString_GET_SIZE() (was: CVS: python/dist/src/Objects classobject.c,2.89,2.90 object.c,2.72,2.73) In-Reply-To: <20000628151758.X29590@lyra.org> References: <200006282157.OAA05880@slayer.i.sourceforge.net> <20000628151758.X29590@lyra.org> Message-ID: <20000628164955.B19053@activestate.com> On Wed, Jun 28, 2000 at 03:17:58PM -0700, Greg Stein wrote: > On Wed, Jun 28, 2000 at 02:57:20PM -0700, Guido van Rossum wrote: > > Update of /cvsroot/python/python/dist/src/Objects > > In directory slayer.i.sourceforge.net:/tmp/cvs-serv5838 > > > > Modified Files: > > classobject.c object.c > > Log Message: > > Trent Mick: change a few casts for Win64 compatibility. > > > > > > Index: classobject.c > > =================================================================== > > RCS file: /cvsroot/python/python/dist/src/Objects/classobject.c,v > > retrieving revision 2.89 > > retrieving revision 2.90 > > diff -C2 -r2.89 -r2.90 > > *** classobject.c 2000/06/23 19:37:01 2.89 > > --- classobject.c 2000/06/28 21:57:18 2.90 > > *************** > > *** 284,288 **** > > if (v == NULL || !PyString_Check(v)) > > return "__name__ must be a string object"; > > ! if ((long)strlen(PyString_AS_STRING(v)) != PyString_GET_SIZE(v)) > > return "__name__ must not contain null bytes"; > > set_slot(&c->cl_name, v); > > --- 284,288 ---- > > if (v == NULL || !PyString_Check(v)) > > return "__name__ must be a string object"; > > ! if (strlen(PyString_AS_STRING(v)) != (size_t)PyString_GET_SIZE(v)) > > return "__name__ must not contain null bytes"; > > set_slot(&c->cl_name, v); > > Actually, it would seem to make more sense to place the cast *inside* the > PyString_GET_SIZE() macro. That is the "true" semantic for GET_SIZE. > > May as well start some ANSI-fication while we can... > I agree. Go to town, Greg. :) Trent -- Trent Mick trentm at activestate.com From gstein at lyra.org Thu Jun 29 02:08:40 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 28 Jun 2000 17:08:40 -0700 Subject: [Python-Dev] Text about cycle GC In-Reply-To: <200006282059.PAA04852@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Wed, Jun 28, 2000 at 03:59:46PM -0500 References: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com> <395A359A.2CF0CA70@prescod.net> <14682.15020.589514.702145@bitdiddle.concentric.net> <395A3F62.EA1E8B89@prescod.net> <20000628122725.A13473@acs.ucalgary.ca> <200006282059.PAA04852@cj20424-a.reston1.va.home.com> Message-ID: <20000628170840.E29590@lyra.org> On Wed, Jun 28, 2000 at 03:59:46PM -0500, Guido van Rossum wrote: > > On Wed, Jun 28, 2000 at 11:09:38AM -0700, Paul Prescod wrote: > > > I'm a little disappointed that it will be so difficult for people to > > > test with GC on, but I'm not going to claim that there is some easy way > > > to make it a runtime option because I haven't looked at it at all. There > > > probably isn't. > > > > There isn't. With an interpreter compiled --with-cycle-gc you can > > turn off the collection with gc.set_threshold(0) but that's not > > the same thing. > > > > Neil > > I wonder if we should turn this option *on* during beta testing? > > That way we gather a lot more experience with its use! Maybe nobody > complains and we can leave it on in the final release... That presumes an adequate number of testers and a wide variety of deployment/usage scenarios. Given the relatively short timeframe, that may be a bit aggressive. I *do* agree with enabling it during the beta. But I'm just not sure about leaving it on. Cheers, -g -- Greg Stein, http://www.lyra.org/ From tim_one at email.msn.com Thu Jun 29 02:07:20 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 28 Jun 2000 20:07:20 -0400 Subject: [Python-Dev] add Demo/imputil/importers.py ? In-Reply-To: <20000628124606.K29590@lyra.org> Message-ID: [Greg Stein] > ... > I'd throw Tools into the same thing [as Demos]. As a separate distro, > you can have a faster release cycle. ... you could release Idle > updates easily and distinctly from the Python core. Note that Guido gave his blessing for a "wide open" policy on IDLE (== its own project in SourceForge, and anyone can be a developer). If that's a success (& I predict it will be, provided someone actually bothers to set up the SF project!), I'd like to see it spread to Tools and Demos too. ignoring-the-downsides-cuz-they'll-make-themselves-known-ly y'rs - tim From guido at beopen.com Thu Jun 29 03:11:36 2000 From: guido at beopen.com (Guido van Rossum) Date: Wed, 28 Jun 2000 20:11:36 -0500 Subject: [Python-Dev] PyString_GET_SIZE() (was: CVS: python/dist/src/Objects classobject.c,2.89,2.90 object.c,2.72,2.73) In-Reply-To: Your message of "Wed, 28 Jun 2000 15:17:58 MST." <20000628151758.X29590@lyra.org> References: <200006282157.OAA05880@slayer.i.sourceforge.net> <20000628151758.X29590@lyra.org> Message-ID: <200006290111.UAA08357@cj20424-a.reston1.va.home.com> > > ! if (strlen(PyString_AS_STRING(v)) != (size_t)PyString_GET_SIZE(v)) > > Actually, it would seem to make more sense to place the cast *inside* the > PyString_GET_SIZE() macro. That is the "true" semantic for GET_SIZE. > > May as well start some ANSI-fication while we can... > > Guido: any problem with my changing the macro? Please leave the macro alone. The type of the macro should be the same as the type of the function -- PyString_Size() -- which is int. If you change this, you potentially get tons of warnings because of the signed / unsigned nature. ANSI-fication is a good project for after 1.6. But even then, it's a separate decision whether the size of a string should be a size_t instead of an int. (The ob_size field should also change, if so -- with even more consequences.) --Guido van Rossum (home page: http://www.python.org/~guido/) From gstein at lyra.org Thu Jun 29 02:29:20 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 28 Jun 2000 17:29:20 -0700 Subject: [Python-Dev] PyString_GET_SIZE() In-Reply-To: <200006290111.UAA08357@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Wed, Jun 28, 2000 at 08:11:36PM -0500 References: <200006282157.OAA05880@slayer.i.sourceforge.net> <20000628151758.X29590@lyra.org> <200006290111.UAA08357@cj20424-a.reston1.va.home.com> Message-ID: <20000628172919.G29590@lyra.org> On Wed, Jun 28, 2000 at 08:11:36PM -0500, Guido van Rossum wrote: > > > ! if (strlen(PyString_AS_STRING(v)) != (size_t)PyString_GET_SIZE(v)) > > > > Actually, it would seem to make more sense to place the cast *inside* the > > PyString_GET_SIZE() macro. That is the "true" semantic for GET_SIZE. > > > > May as well start some ANSI-fication while we can... > > > > Guido: any problem with my changing the macro? > > Please leave the macro alone. The type of the macro should be the > same as the type of the function -- PyString_Size() -- which is int. > If you change this, you potentially get tons of warnings because of > the signed / unsigned nature. > > ANSI-fication is a good project for after 1.6. But even then, it's a > separate decision whether the size of a string should be a size_t > instead of an int. (The ob_size field should also change, if so -- > with even more consequences.) Post 1.6, yes... I had figured on ob_size changing. Certainly not now :-) But I understand the point about different return types. No problem. [ of course, I would state that PyString_Size should also change and we fix those warnings... but I'll be patient :-) ] How about removing Py_PROTO() usage, and changing function definitions from K&R arg declaration to ANSI declarations? That kind of work is pretty simple, straight-forward, and if somebody has free time to plod through the work... so much the better. I believe that these changes would not introduce any stability problems, and could be done independently from your busy schedule. Hmm. Is there a good place to start listing these todo items? One that we can truly use for communicating this info? In Apache, we have a file named STATUS that everybody uses for dropping ideas, patch references, critical bugs, etc. As that file gets changed, we see it in the -checkins alias, so everybody is aware of the suggested changes/problems/available patches/etc. It also holds people's votes on particular changes. Can we institute something similar? Possibly Misc/STATUS? Should I post Apache's STATUS file as an example? Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Thu Jun 29 02:34:24 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 28 Jun 2000 17:34:24 -0700 Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager In-Reply-To: <395A32FD.D3C58B23@prescod.net>; from paul@prescod.net on Wed, Jun 28, 2000 at 10:16:45AM -0700 References: <395A32FD.D3C58B23@prescod.net> Message-ID: <20000628173424.H29590@lyra.org> I think you are being paranoid :-) Consider that this same issue applies to all 5900 projects and 38000 developers at SourceForge. VA Linux has a brand identity entirely built on the trust and support of the Linux (and Open Source) communities. If they blow away that trust, they are simply screwed. That said: it would still be a good thing to have export capabilities. I recall that certain portions of the data (the Trove map?) can be exported in XML format. I don't recall the magic URL for that, however. Cheers, -g On Wed, Jun 28, 2000 at 10:16:45AM -0700, Paul Prescod wrote: > I don't want to be paranoid, but are we putting any important > information into SourceForge that we are not backing up elsewhere? I > mean okay, we've all got CVS dumps, but if it went away (DOJ antitrust > suit...) would we have backups of our patches, bugs, wish lists and so > forth? I hope that's a criteria in deciding what services to move to > SourceForge. I am in the business of preserving investments in data and > of telling customers to avoid software that does not keep them in > complete control of their data. SF makes me nervous that way.... > > -- > Paul Prescod - Not encumbered by corporate consensus > The calculus and the rich body of mathematical analysis to which it > gave rise made modern science possible, but it was the algorithm that > made the modern world possible. > - The Advent of the Algorithm (pending), by David Berlinski > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://www.python.org/mailman/listinfo/python-dev -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Thu Jun 29 02:36:41 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 28 Jun 2000 17:36:41 -0700 Subject: [Python-Dev] RTFM: SourceForge access for Win32 Message-ID: <20000628173641.I29590@lyra.org> All right guys... all this banter about setting up CVS access for Win32 users has been quite silly. Did anybody even stop to look at the docs? http://sfdocs.sourceforge.net/sfdocs/ In particular: http://sfdocs.sourceforge.net/sfdocs/display_topic.php?topicid=19 http://sfdocs.sourceforge.net/sfdocs/display_topic.php?topicid=20 http://sfdocs.sourceforge.net/sfdocs/display_topic.php?topicid=46 There is also a new tool available (released today); http://sfsetup.sourceforge.net/ Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein at lyra.org Thu Jun 29 03:01:40 2000 From: gstein at lyra.org (Greg Stein) Date: Wed, 28 Jun 2000 18:01:40 -0700 Subject: [Python-Dev] add Demo/imputil/importers.py ? In-Reply-To: ; from tim_one@email.msn.com on Wed, Jun 28, 2000 at 08:07:20PM -0400 References: <20000628124606.K29590@lyra.org> Message-ID: <20000628180140.M29590@lyra.org> On Wed, Jun 28, 2000 at 08:07:20PM -0400, Tim Peters wrote: > [Greg Stein] > > ... > > I'd throw Tools into the same thing [as Demos]. As a separate distro, > > you can have a faster release cycle. ... you could release Idle > > updates easily and distinctly from the Python core. > > Note that Guido gave his blessing for a "wide open" policy on IDLE (== its > own project in SourceForge, and anyone can be a developer). If that's a > success (& I predict it will be, provided someone actually bothers to set up > the SF project!), I'd like to see it spread to Tools and Demos too. Are you suggesting that IDLE be separate from a Tools/Demo package, or that the whole bunch be shoved out into the wild? Hmm... I guess that I don't much have an opinion one way or the other, but was mostly looking for clarification. Cheers, -g -- Greg Stein, http://www.lyra.org/ From jeremy at beopen.com Thu Jun 29 04:08:51 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Wed, 28 Jun 2000 22:08:51 -0400 (EDT) Subject: [Python-Dev] how do I build pyexpat? Message-ID: <14682.44979.673881.83798@bitdiddle.concentric.net> Setup.in contains the following comment: # (Note: the expat build process doesn't yet build a libexpat.a; you can # do this manually while we try convince the author to add it.) I've got expat, and I've built it, but I don't have any idea how to build libexpat.a. It may be possible to do it manually, but it would help a lot if the comments could say how to build it or contain a link to instructions on how to build it. Jeremy From gward at python.net Thu Jun 29 04:37:08 2000 From: gward at python.net (Greg Ward) Date: Wed, 28 Jun 2000 22:37:08 -0400 Subject: [Python-Dev] Just spotted on SourceForge main page Message-ID: <20000628223707.A1168@beelzebub> Maybe this is what all you Windows folks are looking for. SFSetup v1 released mhearn - 06/28/00 11:00 - SourceForge Setup for Win32 SFSetup is a program to automatically setup SSH and WinCVS for SourceForge projects under the Windows 32 platform. It's now available for download so if you have not yet set up SSH and WinCVS and want it done for you, you can use this program. Go to sfsetup.sourceforge.net to find out how to use it. It's open source and written in Delphi - the code is in CVS and any improvements are welcome! Thanks -mike -- Greg Ward - Linux nerd gward at python.net http://starship.python.net/~gward/ I love ROCK 'N ROLL! I memorized the all WORDS to "WIPE-OUT" in 1965!! From fdrake at beopen.com Thu Jun 29 05:26:55 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Wed, 28 Jun 2000 23:26:55 -0400 (EDT) Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163) In-Reply-To: <200006282310.SAA05850@cj20424-a.reston1.va.home.com> References: <200006282112.OAA03095@slayer.i.sourceforge.net> <20000628144800.T29590@lyra.org> <200006282310.SAA05850@cj20424-a.reston1.va.home.com> Message-ID: <14682.49663.208158.88794@cj42289-a.reston1.va.home.com> Guido van Rossum writes: > That depends. It is documented as an integer -- which may be vague > enough to encompass longs, but that's weasel-wording. ;-) The 1.6 documentation will make it clear that this may be a long integer, but I don't think we need to promise on which platforms this will be the case. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From paul at prescod.net Thu Jun 29 06:21:41 2000 From: paul at prescod.net (Paul Prescod) Date: Wed, 28 Jun 2000 21:21:41 -0700 Subject: [Python-Dev] how do I build pyexpat? References: <14682.44979.673881.83798@bitdiddle.concentric.net> Message-ID: <395ACED5.83764D45@prescod.net> I don't know where you got your expat or how new it is, but with the one I got from the xml-sig, I can type "make libexpat.a" -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From tim_one at email.msn.com Thu Jun 29 06:55:22 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 29 Jun 2000 00:55:22 -0400 Subject: [Python-Dev] PyString_GET_SIZE() In-Reply-To: <20000628172919.G29590@lyra.org> Message-ID: [Greg Stein] > ... > How about removing Py_PROTO() usage, and changing function > definitions from K&R arg declaration to ANSI declarations? That > kind of work is pretty simple, straight-forward, and if somebody > has free time to plod through the work... so much the better. I think it's too late in the cycle to suggest work for others to do and get any payback from that. Unless you're the one with the free time -- in which case full speed ahead and God bless! I previously volunteered to take the Py_PROTO crap on, as I use an editor with a symbol database that gets confused by that stuff, but I'm sure not going to start that this week. > ... > Hmm. Is there a good place to start listing these todo items? Not that I know of. "Group whiteboards" and shared journals etc are darned useful, though. > One that we can truly use for communicating this info? In Apache, we > have a file named STATUS that everybody uses for dropping ideas, patch > references, critical bugs, etc. As that file gets changed, we see it > in the -checkins alias, so everybody is aware of the suggested > changes/problems/available patches/etc. It also holds people's votes > on particular changes. > > Can we institute something similar? Possibly Misc/STATUS? Should I post > Apache's STATUS file as an example? Yes, sure, no: just check one in! If Guido hates it, we can remove it later. In the meantime, I bet we'll find great ways to use it. In the spirit of Unix, maybe it should be called Misc/gwtbd . let-a-thousand-idiosyncracies-bloom-ly y'rs - tim From tim_one at email.msn.com Thu Jun 29 06:55:24 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 29 Jun 2000 00:55:24 -0400 Subject: [Python-Dev] RTFM: SourceForge access for Win32 In-Reply-To: <20000628173641.I29590@lyra.org> Message-ID: > All right guys... all this banter about setting up CVS access for Win32 > users has been quite silly. It's been a valuable object lesson, Greg: I showed everyone the value of sitting on their ass until someone who knows what they're doing can't stand it anymore <0.8 wink>. > Did anybody even stop to look at the docs? Didn't seem so to me. I personally never found any docs, despite looking for them. > http://sfdocs.sourceforge.net/sfdocs/ Great! Thank you. > ... > There is also a new tool available (released today); > > http://sfsetup.sourceforge.net/ From tim_one at email.msn.com Thu Jun 29 07:08:27 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 29 Jun 2000 01:08:27 -0400 Subject: [Python-Dev] add Demo/imputil/importers.py ? In-Reply-To: <20000628180140.M29590@lyra.org> Message-ID: [Greg Stein] > Are you suggesting that IDLE be separate from a Tools/Demo > package, or that the whole bunch be shoved out into the wild? There's already an IDLE distribution distinct from Python's: http://www.python.org/idle/ Note that the IDLE 0.5 there is not what was shipped with 1.5.2; I'm not clear on why that hasn't been updated to IDLE 0.6 already (suspect just lack of time). > Hmm... I guess that I don't much have an opinion one way or the other, but > was mostly looking for clarification. I don't have a specific plan in mind either -- just "me too"ing on the idea that it would do no harm and possibly do real good to let these peripheral (to the core) things live on their own schedules. I don't see any harm in including "the latest" snapshot of them with the core distribution, though -- it's handy for newcomers to get these things without needing to search for them. I know I learned a lot about Python at the start from browsing these directories. From skip at mojam.com Thu Jun 29 07:27:02 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 29 Jun 2000 00:27:02 -0500 (CDT) Subject: [Python-Dev] Another Python-based company makes good... Message-ID: <14682.56870.790737.261865@beluga.mojam.com> Saw this on InfoBeat today: ** Yahoo to buy EGroups Yahoo said it would buy e-mail service provider EGroups (www.egroups.com) for $437.5 million in stock to enhance the Internet giant's communications services. Yahoo (YHOO) said it would issue 3.43 million shares of stock for all of EGroups shares, options, and warrants. The purchase will be accounted for as a pooling of interests and is expected to close in the third quarter. Yahoo said it would report a one-time charge during the third quarter for expenses to cover the takeover. Looks like Scott Hassan can safely drop out of grad school now (if he hasn't already)... ;-) -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille O'Neal said: "He's got the rings. I listen to the man with the rings." From skip at mojam.com Thu Jun 29 07:39:09 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 29 Jun 2000 00:39:09 -0500 (CDT) Subject: [Python-Dev] OT: A Day in the Life of p5p In-Reply-To: <395A31B7.911D9BC2@prescod.net> References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> <395A31B7.911D9BC2@prescod.net> Message-ID: <14682.57597.600123.167311@beluga.mojam.com> Paul> http://gisle.aas.no/perl/illguts/ The author of all those pretty diagrams is going to be really pissed when they rename all the data structures in Perl 6... :-/ Skip From tim_one at email.msn.com Thu Jun 29 08:47:41 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 29 Jun 2000 02:47:41 -0400 Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager In-Reply-To: <200006281541.KAA02041@cj20424-a.reston1.va.home.com> Message-ID: [Guido] > OK, I've disabled the SF bugs manager. There were two bugs submitted > so far. I've assigned one to you (about os.listdir on Windows) and > one to MAL (about -U vs. exec/eval). You two can take care of > entering these into JB. You can still access the bugs database via > this URL: > > https://sourceforge.net/bugs/?group_id=5470 I moved "my" bug to Jitterbug, and moved Marc-Andre's too to save him the bother. Marked them "Closed" and "Duplicate" on SourceForge, so that if we reenable bug management there someday they won't confuse us. From moshez at math.huji.ac.il Thu Jun 29 09:12:17 2000 From: moshez at math.huji.ac.il (Moshe Zadka) Date: Thu, 29 Jun 2000 10:12:17 +0300 (IDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Doc TODO,1.26,1.27 In-Reply-To: <200006282213.PAA13365@slayer.i.sourceforge.net> Message-ID: On Wed, 28 Jun 2000, Fred L. Drake wrote: > + * Update the filecmp documentation (Moshe?). I'm waiting for Gordon to check-in his directory comparisons to filecmp. Gordon? -- Moshe Zadka http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com From effbot at telia.com Thu Jun 29 10:19:42 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 29 Jun 2000 10:19:42 +0200 Subject: [Python-Dev] id() on Win64 References: Message-ID: <00d501bfe1a2$c93f8cc0$f2a6b5d4@hagrid> tim wrote: > [Greg Stein] > > Regardless: yes, it can certainly break some code. IMO, if any code out > > there makes any kinds of assumptions about id(), then they deserve to be > > broken :-) > > [Trent Mick] > > Amen. > > Guys, it's almost never that simple, and developers are the last ones to > think of the reasonable cases that may break. especially since it's documented to be an integer: id (object) Return the `identity' of an object. This is an integer which is guaranteed to be unique and constant for this object during its lifetime. (section 2.1.4 says that "integer" is the same thing as a "plain integer", and that "long integer" is something different). From gstein at lyra.org Thu Jun 29 11:15:08 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 29 Jun 2000 02:15:08 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules _sre.c,2.4,2.5 In-Reply-To: <200006290857.BAA11219@slayer.i.sourceforge.net>; from effbot@users.sourceforge.net on Thu, Jun 29, 2000 at 01:57:57AM -0700 References: <200006290857.BAA11219@slayer.i.sourceforge.net> Message-ID: <20000629021508.P29590@lyra.org> Euh... can we get a bit more information in that checkin message. "towards 1.6b1" says zippo about what is changing or why. Cheers, -g On Thu, Jun 29, 2000 at 01:57:57AM -0700, Fredrik Lundh wrote: > Update of /cvsroot/python/python/dist/src/Modules > In directory slayer.i.sourceforge.net:/tmp/cvs-serv11206 > > Modified Files: > _sre.c > Log Message: > towards 1.6b1 > > Index: _sre.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Modules/_sre.c,v > retrieving revision 2.4 > retrieving revision 2.5 > diff -C2 -r2.4 -r2.5 > *** _sre.c 2000/06/01 17:34:20 2.4 > --- _sre.c 2000/06/29 08:57:54 2.5 > *************** > *** 4,20 **** > * $Id$ > * > ! * simple regular expression matching engine > * > * partial history: > ! * 99-10-24 fl created (based on the template matcher) > * 99-11-13 fl added categories, branching, and more (0.2) > * 99-11-16 fl some tweaks to compile on non-Windows platforms > * 99-12-18 fl non-literals, generic maximizing repeat (0.3) > ! * 99-02-28 fl tons of changes (not all to the better ;-) (0.4) > [...1589 lines suppressed...] > > void > ! #if defined(WIN32) > __declspec(dllexport) > #endif > *************** > *** 1708,1713 **** > Cursor_Type.ob_type = &PyType_Type; > > ! Py_InitModule("_sre", _functions); > } > > ! #endif > --- 1846,1851 ---- > Cursor_Type.ob_type = &PyType_Type; > > ! Py_InitModule("_" MODULE, _functions); > } > > ! #endif /* !defined(SRE_RECURSIVE) */ > > > _______________________________________________ > Python-checkins mailing list > Python-checkins at python.org > http://www.python.org/mailman/listinfo/python-checkins -- Greg Stein, http://www.lyra.org/ From effbot at telia.com Thu Jun 29 11:29:11 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 29 Jun 2000 11:29:11 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules _sre.c,2.4,2.5 References: <200006290857.BAA11219@slayer.i.sourceforge.net> <20000629021508.P29590@lyra.org> Message-ID: <005601bfe1ac$7e014460$f2a6b5d4@hagrid> greg wrote: > Euh... can we get a bit more information in that checkin message. "towards > 1.6b1" says zippo about what is changing or why. just bringing the repository in sync with the current development snapshot -- I promise to provide more info when the checkins are more focused... just gotta reach "1.6b1 quality" first... From bckfnn at worldonline.dk Thu Jun 29 11:42:03 2000 From: bckfnn at worldonline.dk (Finn Bock) Date: Thu, 29 Jun 2000 09:42:03 GMT Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163) In-Reply-To: References: Message-ID: <395b1528.5978476@smtp.worldonline.dk> [Tim Peters] >id() has to return a unique value. This property of id() does not hold in JPython. When used with hotspot, id() is not unique. regards, finn From Vladimir.Marangozov at inrialpes.fr Thu Jun 29 12:05:12 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Thu, 29 Jun 2000 12:05:12 +0200 (CEST) Subject: [Python-Dev] id() on Win64 In-Reply-To: <395b1528.5978476@smtp.worldonline.dk> from "Finn Bock" at Jun 29, 2000 09:42:03 AM Message-ID: <200006291005.MAA20940@python.inrialpes.fr> Finn Bock wrote: > > [Tim Peters] > > >id() has to return a unique value. > > This property of id() does not hold in JPython. When used with hotspot, > id() is not unique. Is it? Not unique or not persistent during the object's lifetime? -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From effbot at telia.com Thu Jun 29 12:07:42 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 29 Jun 2000 12:07:42 +0200 Subject: [Python-Dev] build problems under MSVC 5.0 Message-ID: <008a01bfe1b1$e08a8a60$f2a6b5d4@hagrid> Python\thread_nt.h(185) : error C2065: 'INT_PTR' : undeclared identifier Python\thread_nt.h(185) : error C2146: syntax error : missing ';' before identifier 'rv' Python\thread_nt.h(185) : error C2065: 'rv' : undeclared identifier Python\thread_nt.h(186) : error C2143: syntax error : missing ';' before 'type' Python\thread_nt.h(195) : error C2065: 'success' : undeclared identifier in MSVC 5.0, _beginthread returns an "unsigned long" (this is also how it's documented in MSDN). I suggest changing the declaration in thread_nt.h to: #if _MSC_VER >= 1200 INT_PTR rv; #else unsigned long rv; #endif on the other hand, the same docs claim that it returns -1 on errors. doesn't exactly look like an unsigned long to me, but that's another story... From effbot at telia.com Thu Jun 29 12:21:22 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 29 Jun 2000 12:21:22 +0200 Subject: [Python-Dev] arraymodule still broken? Message-ID: <009e01bfe1b3$c6cd4480$f2a6b5d4@hagrid> just checked everything out and rebuilt, the exceptions problem sure disappeared, but I still get this error: >>> import array >>> array.array("H", [60000]) Traceback (most recent call last): File "", line 1, in ? OverflowError: signed short integer is greater than maximum second opinion, anyone? From bckfnn at worldonline.dk Thu Jun 29 12:43:55 2000 From: bckfnn at worldonline.dk (Finn Bock) Date: Thu, 29 Jun 2000 10:43:55 GMT Subject: [Python-Dev] id() on Win64 In-Reply-To: <200006291005.MAA20940@python.inrialpes.fr> References: <200006291005.MAA20940@python.inrialpes.fr> Message-ID: <395b26e6.10520397@smtp.worldonline.dk> [Finn Bock] > This property of id() does not hold in JPython. When used with hotspot, > id() is not unique. [Vladimir Marangozov} >Is it? >Not unique or not persistent during the object's lifetime? Not unique. Two different objects can return the same value from System.identityHashCode(). The HTML java docs have this to say about hashCodes: """ As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. (This is typically implemented by converting the internal address of the object into an integer, but this implementation technique is not required by the JavaTM programming language.) """ Its just one of those small difference that we have to live with. In pratical term I have seen it cause problems in pickle.py and copy.deepcopy() regards, finn From gmcm at hypernet.com Thu Jun 29 14:22:12 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Thu, 29 Jun 2000 08:22:12 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Doc TODO,1.26,1.27 In-Reply-To: References: <200006282213.PAA13365@slayer.i.sourceforge.net> Message-ID: <1249841091-43777448@hypernet.com> Moshe wrote: > On Wed, 28 Jun 2000, Fred L. Drake wrote: > > > + * Update the filecmp documentation (Moshe?). > > I'm waiting for Gordon to check-in his directory comparisons to > filecmp. Gordon? Looking at CVS, my stuff was there in filecmp revision 1.2 (+299 -38) and wiped out by 1.3 (+38 -299) which was done the following day. - Gordon From akuchlin at cnri.reston.va.us Thu Jun 29 14:25:19 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Thu, 29 Jun 2000 08:25:19 -0400 Subject: [Python-Dev] how do I build pyexpat? In-Reply-To: <395ACED5.83764D45@prescod.net>; from paul@prescod.net on Wed, Jun 28, 2000 at 09:21:41PM -0700 References: <14682.44979.673881.83798@bitdiddle.concentric.net> <395ACED5.83764D45@prescod.net> Message-ID: <20000629082519.A13839@newcnri.cnri.reston.va.us> On Wed, Jun 28, 2000 at 09:21:41PM -0700, Paul Prescod wrote: >I don't know where you got your expat or how new it is, but with the one >I got from the xml-sig, I can type >"make libexpat.a" That's a patch I made to the Makefile and submitted to James Clark. For Modules/Setup.in, I can change it to explicitly list the 8 files from Expat that need to be linked to. The problem is that one of the files will vary: # Use one of the next two lines; unixfilemap is better if it works. FILEMAP_OBJ=xmlwf/unixfilemap.o #FILEMAP_OBJ=xmlwf/readfilemap.o --amk From gward at mems-exchange.org Thu Jun 29 14:26:47 2000 From: gward at mems-exchange.org (Greg Ward) Date: Thu, 29 Jun 2000 08:26:47 -0400 Subject: [Python-Dev] OT: A Day in the Life of p5p In-Reply-To: <033a01bfe141$71b0cfc0$f2a6b5d4@hagrid>; from effbot@telia.com on Wed, Jun 28, 2000 at 10:42:56PM +0200 References: <033a01bfe141$71b0cfc0$f2a6b5d4@hagrid> Message-ID: <20000629082647.A27322@ludwig.cnri.reston.va.us> On 28 June 2000, Fredrik Lundh said: > it would be very nice if the file object could do something similar > internally (only in text mode, perhaps). maybe in 1.7? Oddly enough, I've been idly contemplating writing an extension type (hypothetically called "superfile") that makes most of Perl's file-handling semantics, and maybe some of the speedup, available in Python. At one level, it would be a rewrite of my 'text_file' module/TextFile class in C. But this is all speculation, mainly predicated on the theory that I *really* should be eating my own dogfood and distributing some Python extension, instead of just telling other people how to do it. ;-) Greg From gward at mems-exchange.org Thu Jun 29 14:33:39 2000 From: gward at mems-exchange.org (Greg Ward) Date: Thu, 29 Jun 2000 08:33:39 -0400 Subject: [Python-Dev] Text about cycle GC In-Reply-To: <14682.15020.589514.702145@bitdiddle.concentric.net>; from jeremy@beopen.com on Wed, Jun 28, 2000 at 01:49:32PM -0400 References: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com> <395A359A.2CF0CA70@prescod.net> <14682.15020.589514.702145@bitdiddle.concentric.net> Message-ID: <20000629083339.B27322@ludwig.cnri.reston.va.us> On 28 June 2000, Jeremy Hylton said: > PP> import cyclicgc > > PP> should turn on the -with-cycle-gc flag. > > The -with-cycle-gc flag is an option to configure when you build > Python. It can't be turned on or off at runtime. No, no, *obviously* Paul meant that "import cyclicgc" should configure and compile a new Python interpreter with "--with-cycle-gc" and 'exec()' it for you. What else would it mean? ;-) Greg (PS. if this were Perl, you could say use cyclegc; to turn it on, and then elsewhere in your code no cyclegc; to turn it off. Maybe Python needs an "unimport" command?) (Kidding!) From gward at mems-exchange.org Thu Jun 29 14:39:08 2000 From: gward at mems-exchange.org (Greg Ward) Date: Thu, 29 Jun 2000 08:39:08 -0400 Subject: [Python-Dev] ucnhash module In-Reply-To: <395A7E65.2271C723@lemburg.com>; from mal@lemburg.com on Thu, Jun 29, 2000 at 12:38:29AM +0200 References: <20000628205832.C3234E2673@oratrix.oratrix.nl> <395A7E65.2271C723@lemburg.com> Message-ID: <20000629083908.D27322@ludwig.cnri.reston.va.us> On 29 June 2000, M.-A. Lemburg said: > The ucnhash module is loaded on demand to avoid memory bloat. > In practice the difference is not really noticeable since > loading a shared module or swapping in a few pages of static > C data result in pretty much the same overall memory usage. > > If no-one complains, I'll fix the test suite though to make > the tests of the named Unicode characters optional. How 'bout a separate "test_ucn" to test this feature? ...of course, this is yet another case of language syntax features becoming optional and selectable at compile-time, which I still think is a bad idea. Hmmm. Greg From guido at beopen.com Thu Jun 29 15:39:59 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 29 Jun 2000 08:39:59 -0500 Subject: [Python-Dev] add Demo/imputil/importers.py ? In-Reply-To: Your message of "Thu, 29 Jun 2000 01:08:27 -0400." References: Message-ID: <200006291339.IAA09887@cj20424-a.reston1.va.home.com> > There's already an IDLE distribution distinct from Python's: > > http://www.python.org/idle/ > > Note that the IDLE 0.5 there is not what was shipped with 1.5.2; I'm not > clear on why that hasn't been updated to IDLE 0.6 already (suspect just lack > of time). Yes. > > Hmm... I guess that I don't much have an opinion one way or the other, but > > was mostly looking for clarification. > > I don't have a specific plan in mind either -- just "me too"ing on the idea > that it would do no harm and possibly do real good to let these peripheral > (to the core) things live on their own schedules. I don't see any harm in > including "the latest" snapshot of them with the core distribution, > though -- it's handy for newcomers to get these things without needing to > search for them. I know I learned a lot about Python at the start from > browsing these directories. Additionally, it's great for Python on Windows to come with a working GUI. Pythonwin may be more like Windows, but it's much more fragile than (recent versions of) IDLE in my experience. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at beopen.com Thu Jun 29 15:49:32 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 29 Jun 2000 08:49:32 -0500 Subject: [Python-Dev] PyString_GET_SIZE() In-Reply-To: Your message of "Wed, 28 Jun 2000 17:29:20 MST." <20000628172919.G29590@lyra.org> References: <200006282157.OAA05880@slayer.i.sourceforge.net> <20000628151758.X29590@lyra.org> <200006290111.UAA08357@cj20424-a.reston1.va.home.com> <20000628172919.G29590@lyra.org> Message-ID: <200006291349.IAA09962@cj20424-a.reston1.va.home.com> > Hmm. Is there a good place to start listing these todo items? One that we > can truly use for communicating this info? In Apache, we have a file named > STATUS that everybody uses for dropping ideas, patch references, critical > bugs, etc. As that file gets changed, we see it in the -checkins alias, so > everybody is aware of the suggested changes/problems/available patches/etc. > It also holds people's votes on particular changes. > > Can we institute something similar? Possibly Misc/STATUS? Should I post > Apache's STATUS file as an example? Possibly, but I'm somewhat skeptical. I used to have a large TODO file -- still have it -- but it's so full of long-term ideas that never happened that I rarely look in it any more. I never got into the discipline of using it for my day-to-day priorities -- it was more of a place to write down long-term ideas so I could forget about them. I'll append it. I appreciate a copy of Apache's STATUS file. --Guido van Rossum (home page: http://www.python.org/~guido/) NEW TODO LIST FOR 1.6 ===================== IDLE: set window class? socket/ssl version mystery UNIFIED TODO LIST ================= From effbot at telia.com Thu Jun 29 14:58:13 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 29 Jun 2000 14:58:13 +0200 Subject: [Python-Dev] PyString_GET_SIZE() References: <200006282157.OAA05880@slayer.i.sourceforge.net> <20000628151758.X29590@lyra.org> <200006290111.UAA08357@cj20424-a.reston1.va.home.com> <20000628172919.G29590@lyra.org> <200006291349.IAA09962@cj20424-a.reston1.va.home.com> Message-ID: <006201bfe1c9$b928d400$f2a6b5d4@hagrid> guido wrote: > > Hmm. Is there a good place to start listing these todo items? One that we > > can truly use for communicating this info? In Apache, we have a file named > > STATUS that everybody uses for dropping ideas, patch references, critical > > bugs, etc. As that file gets changed, we see it in the -checkins alias, so > > everybody is aware of the suggested changes/problems/available patches/etc. > > It also holds people's votes on particular changes. > > > > Can we institute something similar? Possibly Misc/STATUS? Should I post > > Apache's STATUS file as an example? > > Possibly, but I'm somewhat skeptical. I used to have a large TODO > file -- still have it -- but it's so full of long-term ideas that > never happened that I rarely look in it any more. instead of a file, I suggest taking a look at ?!ng's Roundup (once 1.6 final is out, of course). From guido at beopen.com Thu Jun 29 15:58:00 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 29 Jun 2000 08:58:00 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Doc TODO,1.26,1.27 In-Reply-To: Your message of "Thu, 29 Jun 2000 08:22:12 -0400." <1249841091-43777448@hypernet.com> References: <200006282213.PAA13365@slayer.i.sourceforge.net> <1249841091-43777448@hypernet.com> Message-ID: <200006291358.IAA10045@cj20424-a.reston1.va.home.com> > Moshe wrote: > > > On Wed, 28 Jun 2000, Fred L. Drake wrote: > > > > > + * Update the filecmp documentation (Moshe?). > > > > I'm waiting for Gordon to check-in his directory comparisons to > > filecmp. Gordon? > > Looking at CVS, my stuff was there in filecmp revision 1.2 > (+299 -38) and wiped out by 1.3 (+38 -299) which was done > the following day. Argh! An inappropriate side effect of Ping's cleanup -- thanks for catching this. Apparently Ping didn't do a CVS update before generating his diffs. I can restore version 1.2 easily, but I'm not sure what to do with /F's changes (1.3 -> 1.4). Gordon, can you look at this and suggest what to do? --Guido van Rossum (home page: http://www.python.org/~guido/) From mal at lemburg.com Thu Jun 29 15:04:24 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 29 Jun 2000 15:04:24 +0200 Subject: [Python-Dev] ucnhash module References: <20000628205832.C3234E2673@oratrix.oratrix.nl> <395A7E65.2271C723@lemburg.com> <20000629083908.D27322@ludwig.cnri.reston.va.us> Message-ID: <395B4958.C9909145@lemburg.com> Greg Ward wrote: > > On 29 June 2000, M.-A. Lemburg said: > > The ucnhash module is loaded on demand to avoid memory bloat. > > In practice the difference is not really noticeable since > > loading a shared module or swapping in a few pages of static > > C data result in pretty much the same overall memory usage. > > > > If no-one complains, I'll fix the test suite though to make > > the tests of the named Unicode characters optional. > > How 'bout a separate "test_ucn" to test this feature? Good idea. > ...of course, this is yet another case of language syntax features > becoming optional and selectable at compile-time, which I still think is > a bad idea. Hmmm. It's not selectable at run-time: either you have compiled the module or not. It is enabled per default. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Vladimir.Marangozov at inrialpes.fr Thu Jun 29 15:31:21 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Thu, 29 Jun 2000 15:31:21 +0200 (CEST) Subject: [Python-Dev] Text about cycle GC In-Reply-To: <200006282059.PAA04852@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Jun 28, 2000 03:59:46 PM Message-ID: <200006291331.PAA21571@python.inrialpes.fr> Guido van Rossum wrote: > > I wonder if we should turn this option *on* during beta testing? Why not, as long as --without-gc does not suffer from bugs hidden by --with-gc. > > That way we gather a lot more experience with its use! Maybe nobody > complains and we can leave it on in the final release... This is risky. We don't have enough experience with this implementation. All we know is that things get slower and consume more memory. Without a clear picture of the impact of this GC implementation, it's probably a bad idea to enable (i.e. impose) it by default. The "optional experimental feature" label is good and IMO it complies with anybody's expectations. Interested people will jump in and will eventually contribute with improvements, those who don't care won't and will live happily without it (at least until the day the feature and its implementation reach their expected maturity). -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From gmcm at hypernet.com Thu Jun 29 15:27:01 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Thu, 29 Jun 2000 09:27:01 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Doc TODO,1.26,1.27 In-Reply-To: <200006291358.IAA10045@cj20424-a.reston1.va.home.com> References: Your message of "Thu, 29 Jun 2000 08:22:12 -0400." <1249841091-43777448@hypernet.com> Message-ID: <1249837203-44011365@hypernet.com> [Gordon] > > Looking at CVS, my stuff was there in filecmp revision 1.2 > > (+299 -38) and wiped out by 1.3 (+38 -299) which was done the > > following day. [Guido] > Argh! An inappropriate side effect of Ping's cleanup -- thanks > for catching this. Apparently Ping didn't do a CVS update before > generating his diffs. > > I can restore version 1.2 easily, but I'm not sure what to do > with /F's changes (1.3 -> 1.4). Gordon, can you look at this and > suggest what to do? If you have the eff-bot's diff, it should apply to 1.2 (my changes are all below there - basically I added a rewritten dircmp). I think a CVS merge would do the right thing, too. - Gordon From mal at lemburg.com Thu Jun 29 15:33:36 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 29 Jun 2000 15:33:36 +0200 Subject: [Python-Dev] CVS locks on SF Message-ID: <395B5030.C0F08E82@lemburg.com> I'm getting loads of lock messages during CVS checkins recently. Is this due to overload ? (I wonder why anoncvs access causes locking at all -- there is no write access so why should there be file locking ?): [06:31:40] waiting for anoncvs_python's lock in /cvsroot/python/python/dist/src/Lib/test cvs server: [06:32:10] waiting for anoncvs_python's lock in /cvsroot/python/python/dist/src/Lib/test cvs server: [06:32:41] waiting for anoncvs_python's lock in /cvsroot/python/python/dist/src/Lib/test cvs server: [06:33:11] waiting for anoncvs_python's lock in /cvsroot/python/python/dist/src/Lib/test -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fdrake at beopen.com Thu Jun 29 15:52:40 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 29 Jun 2000 09:52:40 -0400 (EDT) Subject: [Python-Dev] how do I build pyexpat? In-Reply-To: <20000629082519.A13839@newcnri.cnri.reston.va.us> References: <14682.44979.673881.83798@bitdiddle.concentric.net> <395ACED5.83764D45@prescod.net> <20000629082519.A13839@newcnri.cnri.reston.va.us> Message-ID: <14683.21672.414396.364125@cj42289-a.reston1.va.home.com> Andrew Kuchling writes: > That's a patch I made to the Makefile and submitted to James Clark. > For Modules/Setup.in, I can change it to explicitly list the 8 files > from Expat that need to be linked to. The problem is that one of the It's not in the stable version I picked up last night; I'll dig up the experimental version today. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From paul at prescod.net Thu Jun 29 15:52:21 2000 From: paul at prescod.net (Paul Prescod) Date: Thu, 29 Jun 2000 06:52:21 -0700 Subject: [Python-Dev] Text about cycle GC References: <200006291331.PAA21571@python.inrialpes.fr> Message-ID: <395B5495.CF274583@prescod.net> Vladimir Marangozov wrote: > >... > > This is risky. We don't have enough experience with this implementation. > All we know is that things get slower and consume more memory. Without > a clear picture of the impact of this GC implementation, it's probably > a bad idea to enable (i.e. impose) it by default. Won't we have a clear picture by the end of the beta period? > The "optional experimental feature" label is good and IMO it complies > with anybody's expectations. Interested people will jump in and will > eventually contribute with improvements, those who don't care won't > and will live happily without it (at least until the day the feature > and its implementation reach their expected maturity). A million Window users will live unhappily without it because they don't know how to recompile to get it! -- Paul Prescod - Not encumbered by corporate consensus The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made the modern world possible. - The Advent of the Algorithm (pending), by David Berlinski From billtut at microsoft.com Thu Jun 29 15:54:21 2000 From: billtut at microsoft.com (Bill Tutt) Date: Thu, 29 Jun 2000 06:54:21 -0700 Subject: [Python-Dev] re: ucnhash Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101D8BD24F@RED-MSG-50> Re: ucnhash and where the stuff gets tested Doesn't matter to me where the test goes. WRT how big it is, thats why its dynamically loaded at run time. If you don't compile it at all, then the \N{...} syntax just won't owrk. Re: static vs. staticforward I can actually do a patch for that, and regen ucnhash.c for you. Re: "" vs. <> Whats wrong with what I'm currently doing? All of the .h files I'm including are on the include file path. "" usage just means stick "." before everything else in your include path. None of the files need that. :) If there's a diffferent policy in the Python source 'bout that that I'm not aware of, then I can fix that issue too. Bill From guido at beopen.com Thu Jun 29 17:03:36 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 29 Jun 2000 10:03:36 -0500 Subject: [Python-Dev] CVS locks on SF In-Reply-To: Your message of "Thu, 29 Jun 2000 15:33:36 +0200." <395B5030.C0F08E82@lemburg.com> References: <395B5030.C0F08E82@lemburg.com> Message-ID: <200006291503.KAA10324@cj20424-a.reston1.va.home.com> > I'm getting loads of lock messages during CVS checkins recently. > Is this due to overload ? (I wonder why anoncvs access causes > locking at all -- there is no write access so why should there > be file locking ?): I haven't seen this myself. Could be you were just unlucky. Could be someone was doing a full checkout over a slow connection. I think the anon checkouts still use (read) locks because they need to get a consistent version. --Guido van Rossum (home page: http://www.python.org/~guido/) From gstein at lyra.org Thu Jun 29 16:10:51 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 29 Jun 2000 07:10:51 -0700 Subject: [Python-Dev] STATUS files (was: PyString_GET_SIZE()) In-Reply-To: <200006291349.IAA09962@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jun 29, 2000 at 08:49:32AM -0500 References: <200006282157.OAA05880@slayer.i.sourceforge.net> <20000628151758.X29590@lyra.org> <200006290111.UAA08357@cj20424-a.reston1.va.home.com> <20000628172919.G29590@lyra.org> <200006291349.IAA09962@cj20424-a.reston1.va.home.com> Message-ID: <20000629071051.T29590@lyra.org> On Thu, Jun 29, 2000 at 08:49:32AM -0500, Guido van Rossum wrote: > > Hmm. Is there a good place to start listing these todo items? One that we > > can truly use for communicating this info? In Apache, we have a file named > > STATUS that everybody uses for dropping ideas, patch references, critical > > bugs, etc. As that file gets changed, we see it in the -checkins alias, so > > everybody is aware of the suggested changes/problems/available patches/etc. > > It also holds people's votes on particular changes. > > > > Can we institute something similar? Possibly Misc/STATUS? Should I post > > Apache's STATUS file as an example? > > Possibly, but I'm somewhat skeptical. I used to have a large TODO > file -- still have it -- but it's so full of long-term ideas that > never happened that I rarely look in it any more. I never got into > the discipline of using it for my day-to-day priorities -- it was more > of a place to write down long-term ideas so I could forget about > them. I'll append it. I appreciate a copy of Apache's STATUS file. Attached below... -- Greg Stein, http://www.lyra.org/ Apache 2.0 STATUS: Last modified at [$Date: 2000/06/28 11:41:14 $] Release: 2.0a5 : ??? 2.0a4 : released June 7, 2000 2.0a3 : released April 28, 2000 2.0a2 : released March 31, 2000 2.0a1 : released March 10, 2000 RELEASE SHOWSTOPPERS: * Win32: Get mod_auth_digest working under win32 - APR_HAS_RANDOM should be defined on windows and there is a lib/apr/misc/win32/rand.c which is basically a copy of what mod_auth_digest used to use. * Re-work configuration for top level Apache. Work should start with trying to clean the autoconf stuff. If and only if this proves impossible to do (very unlikely), autoconf should be removed and we will roll our own config implementation. * suEXEC doesn't work Status: Manoj has posted an patch to fix this. <19991103003605.A20612 at samosa.mindspring.com> * Win32: Enable the Windows MPM to honor max_requests_per_child Status: Bill will fix this. * Win32: Get Apache working on Windows 95/98. The following work (at least) needs to be done: - winnt MPM: Fix 95/98 code paths in the winnt MPM. There is some NT specific code that is still not in NT only code paths - IOL binds to APR sendfile, implemented with TransmitFile, which is not available on 95/98. * Win32: Test access logging with multiple threads. Will the native file I/O calls serialize automagically like the CRT calls or do we need to add region locking each time we access the logs? Status: * Win32: Complete the revamp the service environment and relocation into the WinNT MPM. Changes ServerRoot service registry parameter into ConfigArgs for multiple service startup parameters. Problems to fix in the revamp: -k shutdown/restart are broken, signals are not being acknowledged. Close window and shutdown also seem out of sorts. OtherBill is working on this * Win32: fix build/run time environment to remove ApacheCore.dll linkage from ab.exe and htdigest.exe. * We need a thread-safe resolver, at least on Unix. Status: The best known candidate would be something from BIND v9. Status: Greg asks, "why? doesn't gethostbyname_r() handle this?" * Modify mod_cgi and mod_cgid to deal with directories. This allows a lot of directives to be removed from the core. RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: * OS/2: Get loadable modules working again. Requires shared core support which doesn't appear to be catered for in the current build system. * OS/2: Make mod_status work for spmt_os2 MPM. * Build scripts do not recognise AIX 4.2.1 pthreads, so the pthread MPMs will not build. * Win32: Reuse accept socket after transmitfile/close This is not a bug, but would be nice to get this feature in before ship. * Win32: Enable the winnt MPM to use the new scoreboard API * Win32: Implement ap_shm_ functions in APR. * Win32: Win9x console window still won't play nice with the close window, logoff and shutdown scenarios. * Win32: Add a simple hold console open patch (wait for close or the ESC key, with a nice message) if the server died a bad death (non-zero exit code) in console mode. * Platforms that do not support fork (primarily Win32 and AS/400) Consider introducing HAVE_FORK feature macro. Architect start-up code that avoids initializing all the modules in the parent process on platforms that do not support fork. * Clean the code. There are a lot of places we used APR but didn't remove the hacks that were required for the cross-platform code in 1.3. We need to make the code look like APR was supposed to be there. * Go throught the 1.3 Bug DB and research the bugs marked "suspended". People were told these would be considered for inclusion in Apache 2.0, it would be nice to actually do so. * Win32: Migrate the MPM over to use APR thread/process calls. This would eliminate some code in the Win32 branch that essentially duplicates what is in APR. Bill says we need a new procattr, APR_CREATE_SUSPENDED (or something similar) to direct ap_create_process to create the process suspended. We also need a call to wake up the suspended process This may not be able to be implemented everywhere though. Status: * Move I/O layering into APR. * There are still a number of places in the code where we are loosing error status (i.e. throwing away the error returned by a system call and replacing it with a generic error code) * Win32: Implement reliable piped logs on Windows Status: * Use APR to get rid of more platform dependancies. Status: Ryan Bloom is working on this. * The connection status table is not very efficient. Also, very few stats are exported to the connection status table (easy to fix), and mod_status is ugly. * Mass vhosting version of suEXEC. * Replace tables with a proper opaque ADT that has pluggable implementations (including something like the existing data type, plus hash tables for speed, with options for more later). Status: fanf is working on this. * configuration option to use *DBM Status: Greg +1 (volunteers) * add SDBM into src/lib/sdbm/ as a default/fallback DBM implementation. SDBM is used by Perl, mod_dav, mod_sssl, others for basic DBM support. Status: Greg +1 (volunteers) * Integrate mod_dav. Message-id: <20000625173247.M29590 at lyra.org> Status: in process. - APR does not provide a couple needed things: chmod() and ap_finfo_t.st_dev. - expat-lite needs to be brought up to parity with the 1.3 vsn and inserted into the config/build process - SDBM needs to go into the config/build process - fix up include dirs to pick up expat-lite, sdbm, dav/main - APR-ization to the dav/fs/ stuff - case_preserved_filename stuff * ap_core_translate() and its use by mod_mmap_static are a bit wonky. The function should probably be exposed as a utility function (such as ap_translate_url2fs() or ap_validate_fs_url() or something). Another approach would be a new hook phase after "translate" which would allow mod_mmap_static to munge what the translation has decided to do. Status: Greg +1 (volunteers), Ryan +1 * Go through ap_config.h and namespace-protect the symbols (e.g. USE_*). Some symbols can/should move to mpm_common.h where possible. * Explore use of a post-config hook for the code in http_main.c which calls ap_fixup_virutal_hosts(), ap_fini_vhost_config(), and ap_sort_hooks() [to reduce the logic in main()] * read the config tree just once, and process N times (as necessary) * add a version number to ap_initialize() as an extra failsafe against (APR) library version skew. MsgID: Status: Greg +1 (volunteers), Jeff +1, Ryan +1, Tony -0(?) * mod_info to use the configuration tree * add output filtering. there are a couple variants for this. - The "link-based" variant is ready to go: MsgID: <20000627044436.N29590 at lyra.org> (patch) MsgID: <20000627053302.O29590 at lyra.org> (demo usage) MsgID: (problems with the patch) Status: Greg +1, Ryan -1 Other bugs that need fixing: * MaxRequestsPerChild measures connections, not requests. Until someone has a better way, we'll probably just rename it "MaxConnectionsPerChild". * Regex containers don't work in an intutive way Status: No one has come up with an efficient way to fix this behavior. Dean has suggested getting rid of regex containers completely. * SIGSEGV on Linux (glibc 2.1.2) isn't caught properly by a sigwaiting thread. We need to work around this, perhaps unless there is hope soon for a fixed glibc. * The mod_cgid daemon process isn't always cleaned up when httpd gets SIGTERM. Jeff thinks it may be as simple as registering the daemon process for cleanup with the proper pool, but he hasn't looked at it in enough detail. * The MM library is built as static and shared library. This should be set up to build only the required version. Other features that need writing: * Finish infrastructure in core for async MPMs Status: post 2.0 * TODO in source -- just do an egrep on "TODO" and see what's there Documentation that needs writing: * Mod_status docs are needed. * The concept of MPMs, especially if we ship more than one MPM for a given platform * New directives in the various MPMs and appropriate links from obsolete directives in core.html to the MPM documentation. * Revise manual/stopping.html and the last part of manual/misc/perf-tuning.html to take account of the MPMs. * API documentation Status: Ben Laurie has written some hooks documentation (apache-2.0/htdocs/hooks.html) * Changes since 1.3.9 can be more easily seen in the commitlog file dev.apache.org:/home/cvs/CVSROOT/commitlogs/apache-2.0 which includes some of Roy's comments when the changes were committed in rough change-sets by purpose. Note that the commitlog does not show the contents of new files until later. * mod_dav documentation (once integrated) Available Patches: * Mike Abbott's patches to improve performance Status: These were written for 1.3, and are awaiting a port to 2.0 * Jim Winstead's patch to add CookieDomain and other small mod_usertrack features Open issues: * What do we do about mod_proxy? * Which MPMs will be included with Apache 2.0? * Is conf/highperformance.conf-dist obsolete? It looks obsolete. From fredrik at pythonware.com Thu Jun 29 16:11:26 2000 From: fredrik at pythonware.com (Fredrik Lundh) Date: Thu, 29 Jun 2000 16:11:26 +0200 Subject: [Python-Dev] Text about cycle GC References: <200006280204.WAA01120@207-172-112-182.s182.tnt4.ann.va.dialup.rcn.com> <395A359A.2CF0CA70@prescod.net> <14682.15020.589514.702145@bitdiddle.concentric.net> <395A3F62.EA1E8B89@prescod.net> <20000628122725.A13473@acs.ucalgary.ca> <200006282059.PAA04852@cj20424-a.reston1.va.home.com> Message-ID: <016a01bfe1d3$ea2474b0$0900a8c0@SPIFF> guido wrote: > I wonder if we should turn this option *on* during beta testing? +1 from me. > That way we gather a lot more experience with its use! Maybe nobody > complains and we can leave it on in the final release... I won't mind (unless it breaks my code, of course). From mal at lemburg.com Thu Jun 29 16:10:28 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 29 Jun 2000 16:10:28 +0200 Subject: [Python-Dev] re: ucnhash References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD24F@RED-MSG-50> Message-ID: <395B58D4.E52CBBD6@lemburg.com> Bill Tutt wrote: > > Re: ucnhash and where the stuff gets tested > > Doesn't matter to me where the test goes. I'm currently trying to check these changes in... doesn't work though due to some obscure CVS locks. > WRT how big it is, thats why its dynamically loaded at run time. > If you don't compile it at all, then the \N{...} syntax just won't owrk. > > Re: static vs. staticforward > I can actually do a patch for that, and regen ucnhash.c for you. Someone (Fred ?) already patches those places for you. He didn't send patches for the perfect hash tool though. > Re: "" vs. <> > Whats wrong with what I'm currently doing? <> uses a differnt header file lookup path... normally doesn't hurt, but... > All of the .h files I'm including are on the include file path. "" usage > just means stick "." before everything else in your include path. > None of the files need that. :) If there's a diffferent policy in the Python > source 'bout that that I'm not aware of, then I can fix that issue too. ... you already know that ;-) Again, these are already fixed :-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido at beopen.com Thu Jun 29 17:15:09 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 29 Jun 2000 10:15:09 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Doc TODO,1.26,1.27 In-Reply-To: Your message of "Thu, 29 Jun 2000 09:27:01 -0400." <1249837203-44011365@hypernet.com> References: Your message of "Thu, 29 Jun 2000 08:22:12 -0400." <1249841091-43777448@hypernet.com> <1249837203-44011365@hypernet.com> Message-ID: <200006291515.KAA10374@cj20424-a.reston1.va.home.com> > [Gordon] > > > Looking at CVS, my stuff was there in filecmp revision 1.2 > > > (+299 -38) and wiped out by 1.3 (+38 -299) which was done the > > > following day. > [Guido] > > Argh! An inappropriate side effect of Ping's cleanup -- thanks > > for catching this. Apparently Ping didn't do a CVS update before > > generating his diffs. > > > > I can restore version 1.2 easily, but I'm not sure what to do > > with /F's changes (1.3 -> 1.4). Gordon, can you look at this and > > suggest what to do? [Gordon] > If you have the eff-bot's diff, it should apply to 1.2 (my changes > are all below there - basically I added a rewritten dircmp). I > think a CVS merge would do the right thing, too. There was a change in indent style, so effbot's diff didn't apply cleanly -- but your suggestion made me realize that it was easy to re-apply manually. It's all fixed now. Thanks all! --Guido van Rossum (home page: http://www.python.org/~guido/) From mal at lemburg.com Thu Jun 29 16:15:23 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu, 29 Jun 2000 16:15:23 +0200 Subject: [Python-Dev] CVS locks on SF References: <395B5030.C0F08E82@lemburg.com> <200006291503.KAA10324@cj20424-a.reston1.va.home.com> Message-ID: <395B59FB.1CD472AE@lemburg.com> Guido van Rossum wrote: > > > I'm getting loads of lock messages during CVS checkins recently. > > Is this due to overload ? (I wonder why anoncvs access causes > > locking at all -- there is no write access so why should there > > be file locking ?): > > I haven't seen this myself. Could be you were just unlucky. Could be > someone was doing a full checkout over a slow connection. > > I think the anon checkouts still use (read) locks because they need to > get a consistent version. Looks like someone is using a 9.6kBaud mobile phone connection ;-) The problem still persists and I've been trying for about half an hour now. I'll try again later today... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido at beopen.com Thu Jun 29 17:21:47 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 29 Jun 2000 10:21:47 -0500 Subject: [Python-Dev] Text about cycle GC In-Reply-To: Your message of "Thu, 29 Jun 2000 06:52:21 MST." <395B5495.CF274583@prescod.net> References: <200006291331.PAA21571@python.inrialpes.fr> <395B5495.CF274583@prescod.net> Message-ID: <200006291521.KAA10440@cj20424-a.reston1.va.home.com> > Won't we have a clear picture by the end of the beta period? Not clear. Unfortunately, few people who run important apps will download a beta and try it. But they *will* download a new release labeled "final" and install it without making sure it works for their app. This has been my experience throughout Python's life. I've become pretty conservative about staying backwards compatible as a result... > > The "optional experimental feature" label is good and IMO it complies > > with anybody's expectations. Interested people will jump in and will > > eventually contribute with improvements, those who don't care won't > > and will live happily without it (at least until the day the feature > > and its implementation reach their expected maturity). > > A million Window users will live unhappily without it because they don't > know how to recompile to get it! This can be solved the way we solve everything for Windows users: give them two distributions to choose from -- or maybe one distribution with a checkbox to choose which version to use. --Guido van Rossum (home page: http://www.python.org/~guido/) From skip at mojam.com Thu Jun 29 15:38:20 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 29 Jun 2000 08:38:20 -0500 (CDT) Subject: [Python-Dev] Sourceforge Interface Concerns In-Reply-To: References: <20000628025304.BB64A1CE0D@dinsdale.python.org> Message-ID: <14683.20812.615266.196934@beluga.mojam.com> Andy> How many people here have actually created accounts for themselves Andy> on SourceForge and tried to do stuff when logged in - raise bugs Andy> and so on? Did it work for you? I've submitted a few patches with no problems. My usual connections are a corporate T1-ish connection or cable modem access from home, however. -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille O'Neal said: "He's got the rings. I listen to the man with the rings." From jeremy at beopen.com Thu Jun 29 16:45:27 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 29 Jun 2000 10:45:27 -0400 (EDT) Subject: [Python-Dev] how do I build pyexpat? In-Reply-To: <14683.21672.414396.364125@cj42289-a.reston1.va.home.com> References: <14682.44979.673881.83798@bitdiddle.concentric.net> <395ACED5.83764D45@prescod.net> <20000629082519.A13839@newcnri.cnri.reston.va.us> <14683.21672.414396.364125@cj42289-a.reston1.va.home.com> Message-ID: <14683.24839.650558.23732@bitdiddle.concentric.net> >>>>> "FLD" == Fred L Drake, writes: FLD> Andrew Kuchling writes: >> That's a patch I made to the Makefile and submitted to James >> Clark. For Modules/Setup.in, I can change it to explicitly list >> the 8 files from Expat that need to be linked to. The problem is >> that one of the FLD> It's not in the stable version I picked up last night; I'll FLD> dig up the experimental version today. I downloaded version 1.1 from the expat home page. The URL for the download is ftp://ftp.jclark.com/pub/xml/expat.zip. This version hasn't changed in the last two weeks. The instructions Fred include worked almost just right. I checked in the corrected ar command and it looks good. Jeremy From fdrake at beopen.com Thu Jun 29 16:46:48 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 29 Jun 2000 10:46:48 -0400 (EDT) Subject: [Python-Dev] CVS locks on SF In-Reply-To: <200006291503.KAA10324@cj20424-a.reston1.va.home.com> References: <395B5030.C0F08E82@lemburg.com> <200006291503.KAA10324@cj20424-a.reston1.va.home.com> Message-ID: <14683.24920.264911.840500@cj42289-a.reston1.va.home.com> Guido van Rossum writes: > I think the anon checkouts still use (read) locks because they need to > get a consistent version. Yes; you need a directory lock to avoid files getting modified or deleted underneath you while checking out/updating. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Thu Jun 29 16:48:38 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 29 Jun 2000 10:48:38 -0400 (EDT) Subject: [Python-Dev] re: ucnhash In-Reply-To: <395B58D4.E52CBBD6@lemburg.com> References: <4D0A23B3F74DD111ACCD00805F31D8101D8BD24F@RED-MSG-50> <395B58D4.E52CBBD6@lemburg.com> Message-ID: <14683.25030.205960.13328@cj42289-a.reston1.va.home.com> M.-A. Lemburg writes: > Someone (Fred ?) already patches those places for you. He didn't > send patches for the perfect hash tool though. Not this Fred... -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Thu Jun 29 16:52:28 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 29 Jun 2000 10:52:28 -0400 (EDT) Subject: [Python-Dev] how do I build pyexpat? In-Reply-To: <14683.24839.650558.23732@bitdiddle.concentric.net> References: <14682.44979.673881.83798@bitdiddle.concentric.net> <395ACED5.83764D45@prescod.net> <20000629082519.A13839@newcnri.cnri.reston.va.us> <14683.21672.414396.364125@cj42289-a.reston1.va.home.com> <14683.24839.650558.23732@bitdiddle.concentric.net> Message-ID: <14683.25260.182929.808330@cj42289-a.reston1.va.home.com> Jeremy Hylton writes: > The instructions Fred include worked almost just right. I checked in > the corrected ar command and it looks good. That's what I get for typing in the dark on a dark keyboard. ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one at email.msn.com Thu Jun 29 18:23:54 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 29 Jun 2000 12:23:54 -0400 Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163) In-Reply-To: <395b1528.5978476@smtp.worldonline.dk> Message-ID: [posted & mailed] [Tim] > id() has to return a unique value. [Finn Bock] > This property of id() does not hold in JPython. When used with hotspot, > id() is not unique. So it's possible there for one of these be true: id(x) == id(y) and x is not y id(x) != id(x) ? Then that's a bug in JPython or hotspot. Know which? Filed a bug report? In CPython, we just use the address of an object's header, and as CPython never moves an object's header in memory, the good stuff follows trivially. Don't know what JPython tries to do, but it's bound to be harder there (as Java can move memory around). From bckfnn at worldonline.dk Thu Jun 29 18:43:09 2000 From: bckfnn at worldonline.dk (Finn Bock) Date: Thu, 29 Jun 2000 16:43:09 GMT Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163) In-Reply-To: References: Message-ID: <395b79a7.31704869@smtp.worldonline.dk> [Tim] >So it's possible there for one of these be true: > > id(x) == id(y) and x is not y > id(x) != id(x) > >? Yes, the first. d = {} cnt = 0 for i in xrange(100000): s = "test" + `i` j = id(s) if d.has_key(j): cnt = cnt + 1 d[j] = s print cnt, "failures" Will print 500+ failures when run by JPython & JDK1.3 on win2k. >Then that's a bug in JPython or hotspot. Know which? JPython. > Filed a bug report? Years ago : http://www.python.org/jpython-bugs/incoming?id=118 >In CPython, we just use the address of an object's header, and as CPython >never moves an object's header in memory, the good stuff follows trivially. >Don't know what JPython tries to do, but it's bound to be harder there (as >Java can move memory around). That is also my guess. I cannot see what we can do about it, except inform users that not all python platform behave exactly the same. Which is why I brought it up. regards, finn From trentm at activestate.com Thu Jun 29 18:42:56 2000 From: trentm at activestate.com (Trent Mick) Date: Thu, 29 Jun 2000 09:42:56 -0700 Subject: [Python-Dev] arraymodule still broken? In-Reply-To: <009e01bfe1b3$c6cd4480$f2a6b5d4@hagrid> References: <009e01bfe1b3$c6cd4480$f2a6b5d4@hagrid> Message-ID: <20000629094256.A21926@activestate.com> On Thu, Jun 29, 2000 at 12:21:22PM +0200, Fredrik Lundh wrote: > just checked everything out and rebuilt, the exceptions > problem sure disappeared, but I still get this error: > > >>> import array > >>> array.array("H", [60000]) > Traceback (most recent call last): > File "", line 1, in ? > OverflowError: signed short integer is greater than maximum > > second opinion, anyone? > I think this is because we are in the middling state where all of my patches have not gotten in yet. I say this because this is what I get with my version that has all of my patches applied: Python 1.6a2 (#1, Jun 29 2000, 09:28:15) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> import array >>> array.array("H", [60000]) array('H', [60000]) >>> Specifically, I haven't looked for the issue. Is it alright if I look at this this weekend? Trent -- Trent Mick trentm at activestate.com From trentm at activestate.com Thu Jun 29 18:53:43 2000 From: trentm at activestate.com (Trent Mick) Date: Thu, 29 Jun 2000 09:53:43 -0700 Subject: [Python-Dev] build problems under MSVC 5.0 In-Reply-To: <008a01bfe1b1$e08a8a60$f2a6b5d4@hagrid> References: <008a01bfe1b1$e08a8a60$f2a6b5d4@hagrid> Message-ID: <20000629095343.B21926@activestate.com> On Thu, Jun 29, 2000 at 12:07:42PM +0200, Fredrik Lundh wrote: > Python\thread_nt.h(185) : error C2065: 'INT_PTR' : undeclared identifier > Python\thread_nt.h(185) : error C2146: syntax error : missing ';' before identifier 'rv' > Python\thread_nt.h(185) : error C2065: 'rv' : undeclared identifier > Python\thread_nt.h(186) : error C2143: syntax error : missing ';' before 'type' > Python\thread_nt.h(195) : error C2065: 'success' : undeclared identifier > This is a result of one of my patches. I was using MSVC 6.0, where INT_PTR is defined as you would expect. I did not realize that it was new to that version of the headers. BTW, INT_PTR, UINT_PTR, etc are the standard defines that I saw Microsoft suggesting in their Win64 docs. I don't like those names, because they are not portable. I should have used the (ANSI?) equivalents: intptr_t, uintptr_t. In fact, I *did* use those in some of my patches where the code portability was required (as obviously it is not in thread_*nt*.h). > in MSVC 5.0, _beginthread returns an "unsigned long" (this is also > how it's documented in MSDN). Yup. And in the Win64 headers _beginthread returns uintptr_t, which makes me wonder why I picked INT_PTR. > > I suggest changing the declaration in thread_nt.h to: > > #if _MSC_VER >= 1200 > INT_PTR rv; > #else > unsigned long rv; > #endif > As I said above, I acknowledge that I should not have used INT_PTR. Win32: unsigned long _beginthread() Win64: uintptr_t _beginthread() I think (am I wrong?) to generalize that the intention for both Win32 and Win64 is to have _beginthread return an unsigned pointer-sized integer: hence uintptr_t. This would eliminate the #ifdef but would require a typedef for uintptr_t on Win32. This can be done in PC/config.h (I already did this for intptr_t, because I needed *that* elsewhere.) Does this also need to be generalized to typedef uintptr_t whereever it is not defined, i.e. in the autoconf files. I can look at this this weekend, if that is soon enough. > on the other hand, the same docs claim that it returns -1 on errors. > doesn't exactly look like an unsigned long to me, but that's another > story... > Yes, strange. Trent -- Trent Mick trentm at activestate.com From effbot at telia.com Thu Jun 29 19:07:02 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 29 Jun 2000 19:07:02 +0200 Subject: [Python-Dev] build problems under MSVC 5.0 References: <008a01bfe1b1$e08a8a60$f2a6b5d4@hagrid> <20000629095343.B21926@activestate.com> Message-ID: <019e01bfe1ec$728c6c00$f2a6b5d4@hagrid> trent wrote: > I think (am I wrong?) to generalize that the intention for both Win32 and > Win64 is to have _beginthread return an unsigned pointer-sized integer: hence > uintptr_t. > > This would eliminate the #ifdef but would require a typedef for uintptr_t on > Win32. This can be done in PC/config.h (I already did this for intptr_t, > because I needed *that* elsewhere.) Does this also need to be generalized to > typedef uintptr_t whereever it is not defined, i.e. in the autoconf files. > > I can look at this this weekend, if that is soon enough. I suggest checking in the #ifdef as a stopgap measure, if you promise to come up with the right thing (whatever that is) in time for 1.6 final. Should I go ahead and check it in? From tim_one at email.msn.com Thu Jun 29 19:15:08 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 29 Jun 2000 13:15:08 -0400 Subject: [Python-Dev] CVS locks on SF In-Reply-To: <395B5030.C0F08E82@lemburg.com> Message-ID: [MAL] > I'm getting loads of lock messages during CVS checkins recently. > Is this due to overload ? (I wonder why anoncvs access causes > locking at all -- there is no write access so why should there > be file locking ?): IIRC, CVS maintains the illusion of being a multi-user system by using per-*directory* locks. That means it gives you the warm fuzzy feeling that you're being protected against (e.g.) getting an inconsistent snapshot while someone else is committing, but in fact you're not protected at all (inter-directory). It locks per-directory to ensure the integrity of its own data files, but users are subject to the luck of the draw. Note that Perl is maintained under (the commercial, alas) Perforce, which is one of the few SCMs to take multi-developer multi-directory issues seriously. So the good news is that when you see a CVS lock gripe, that means CVS is protecting itself from corruption. The bad news is that if we used a system that protected *us* against inconsistencies too, we'd probably see lock gripes even more often. From gmcm at hypernet.com Thu Jun 29 19:19:51 2000 From: gmcm at hypernet.com (Gordon McMillan) Date: Thu, 29 Jun 2000 13:19:51 -0400 Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163) In-Reply-To: References: <395b1528.5978476@smtp.worldonline.dk> Message-ID: <1249823239-44851587@hypernet.com> [Finn Bock] > > This property of id() does not hold in JPython. When used with > > hotspot, id() is not unique. [Tim] > So it's possible there for one of these be true: > > id(x) == id(y) and x is not y > id(x) != id(x) > > ? Then that's a bug in JPython or hotspot. Know which? Filed a > bug report? Oh, you silly boy. There are (by definition) no bugs in hotspot. it's-only-'cause-Guido's-a-weenie-that-Python-has-'em-ly y'rs - Gordon From tim_one at email.msn.com Thu Jun 29 19:44:45 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 29 Jun 2000 13:44:45 -0400 Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163) In-Reply-To: <395b79a7.31704869@smtp.worldonline.dk> Message-ID: [Finn Bock, says id() is buggy under JPython] [Tim] >> Filed a bug report? [Finn] > Years ago : > http://www.python.org/jpython-bugs/incoming?id=118 >> In CPython, we just use the address of an object's header, and as CPython >> never moves an object's header in memory, the good stuff follows >> trivially. Don't know what JPython tries to do, but it's bound to be >> harder there (as Java can move memory around). > That is also my guess. I cannot see what we can do about it, except > inform users that not all python platform behave exactly the same. Which > is why I brought it up. Well, neither Java's hashCode nor identityHashCode are correct implementations of Python's id(), so JPython's id() is simply wrong. I don't know anything about the internals of JPython. If there's a "choke point" for allocating Python objects, the quickest way out may be to add a write-once "id" field to each Python object under JPython, and simply fill it with an integer that's (safely) incremented by 1 on each allocation. Python doesn't guarantee you'll get the *same* id(x) across implementations, or even across runs under a single implementation, so the implementations of id() in CPython and JPython can do entirely different things. They have to meet the promises in the Python docs, though, and JPython's currently doesn't. From effbot at telia.com Thu Jun 29 19:51:32 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 29 Jun 2000 19:51:32 +0200 Subject: [Patches] Re: [Python-Dev] Let's use the SourceForge Patch Manager References: <395A32FD.D3C58B23@prescod.net> <20000628173424.H29590@lyra.org> Message-ID: <025701bfe1f2$ab5b8420$f2a6b5d4@hagrid> greg wrote: > I think you are being paranoid :-) > > Consider that this same issue applies to all 5900 projects and 38000 > developers at SourceForge. VA Linux has a brand identity entirely built on > the trust and support of the Linux (and Open Source) communities. If they > blow away that trust, they are simply screwed. on the other hand, lots of people thought that dejanews would store usenet postings forever... http://salon.com/tech/log/2000/06/20/deja/index.html From pingster at ilm.com Thu Jun 29 19:47:13 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Thu, 29 Jun 2000 10:47:13 -0700 (PDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Doc TODO,1.26,1.27 In-Reply-To: <200006291358.IAA10045@cj20424-a.reston1.va.home.com> Message-ID: On Thu, 29 Jun 2000, Guido van Rossum wrote: > > Argh! An inappropriate side effect of Ping's cleanup -- thanks for > catching this. Apparently Ping didn't do a CVS update before > generating his diffs. My apologies! I'm pretty sure i did an update, but i must have left too long a gap during which 1.2 got checked in. You'd think somehow a version-control system would have noticed the inconsistency between ancestor versions... Anyway, very sorry for the trouble. Glad it appears to be cleared up now. -- ?!ng From effbot at telia.com Thu Jun 29 19:56:02 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 29 Jun 2000 19:56:02 +0200 Subject: [Python-Dev] id() on Win64 References: <20000628160743.A16262@acs.ucalgary.ca> Message-ID: <027101bfe1f3$4d478ae0$f2a6b5d4@hagrid> neil wrote: > [Greg Stein] > >Strictly speaking: the Long only occurs on Win64 platforms. > > > >I would guess that it is also possible on say, an Alpha running > >Linux. Presuming that has 64-bit pointers(?). > > I think the Alpha is okay. The problem is strange type models > were int is 32 bits and pointers are 64. AFAIK, the Alpha uses > 64 bits for both. is this true for linux alpha too? it's definitely true for tru64; we've been using python extensively on that platform since 1995: http://www.smhi.se/weather/satelitbilder/satellitbilder.htm (in swedish, but I suppose you all can figure out what it is anyway ;-) From gward at mems-exchange.org Thu Jun 29 19:55:25 2000 From: gward at mems-exchange.org (Greg Ward) Date: Thu, 29 Jun 2000 13:55:25 -0400 Subject: [Python-Dev] Test results of linuxaudiodev.c Message-ID: <20000629135525.A5221@ludwig.cnri.reston.va.us> Hi -- here are results from testing linuxaudiodev from the latest CVS Python 1.6. This is on a Dell Dimension with on-board audio hardware: the Yamaha YMF724 chipset. I'm using the ALSA 0.5.8a driver (the latest as of a week or two ago, and the only one that supports the YMF724). Bottom line: the test sound plays, but it sounds horrible when played by linuxaudiodev. If I do this: $ play Lib/test/audiotest.au then Cardinal Fang comes through loud and clear. ("play" is a shell script wrapper for "sox", writing to /dev/dsp.) But if I do this: $ ./python Lib/test/regrtest.py test_linuxaudiodev he's still audible (and at the same volume), but very scratchy. Sounds kind of like a very over-driven amp, or like a cheap car radio that somebody attacked with a knife. [...some time passes...] OK, I just tried it on another machine, also a Dell but with a different sound chip: the Crystal CS4232. I'm pretty sure this one is using the OSS drivers included with the kernel, which is probably the second most important difference after the chipset itself. Bottom line: it also sounds horrible. Greg -- Greg Ward - software developer gward at mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From bwarsaw at beopen.com Thu Jun 29 19:57:27 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Thu, 29 Jun 2000 13:57:27 -0400 (EDT) Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163) References: <395b79a7.31704869@smtp.worldonline.dk> Message-ID: <14683.36359.864478.495915@anthem.concentric.net> >>>>> "TP" == Tim Peters writes: TP> Well, neither Java's hashCode nor identityHashCode are correct TP> implementations of Python's id(), so JPython's id() is simply TP> wrong. I don't know anything about the internals of JPython. TP> If there's a "choke point" for allocating Python objects, the TP> quickest way out may be to add a write-once "id" field to each TP> Python object under JPython, and simply fill it with an TP> integer that's (safely) incremented by 1 on each allocation. TP> Python doesn't guarantee you'll get the *same* id(x) across TP> implementations, or even across runs under a single TP> implementation, so the implementations of id() in CPython and TP> JPython can do entirely different things. They have to meet TP> the promises in the Python docs, though, and JPython's TP> currently doesn't. I can't generate patches right now, but what you need to change is in __builtin__.java, the id() function. It should probably call object.id() which would fill in the monotonically incrementing id as Tim suggestions. One question is what to do about Java proxies. Currently built-in id() returns the identityHashCode() of the proxy object, which is just an Object. I'm not sure sticking the id in the wrapper is the right thing or not. -Barry From effbot at telia.com Thu Jun 29 20:18:26 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 29 Jun 2000 20:18:26 +0200 Subject: [Python-Dev] Re: sourceforge data (was: Let's use the SourceForge Patch Manager) References: <395A32FD.D3C58B23@prescod.net> <20000628173424.H29590@lyra.org> <025701bfe1f2$ab5b8420$f2a6b5d4@hagrid> <20000629110557.W29590@lyra.org> Message-ID: <02d901bfe1f6$720ca920$f2a6b5d4@hagrid> greg wrote: > > on the other hand, lots of people thought that dejanews > > would store usenet postings forever... > > Different problem space. They weren't holding people's data. well, they dropped a few thousand eff-bot postings ;-) > Worrying about it is a useless exercise, IMO. well, I'm not worried. but in the internet universe, strange things happen all the time... (checked out http://www.fuckedcompany.com/ lately?) ... btw, has anyone checked what's in: http://cvs.sourceforge.net/cvstarballs/python-cvsroot.tar.gz (with ping times somewhere around one second, it's too large for me to check out...) From effbot at telia.com Thu Jun 29 20:05:34 2000 From: effbot at telia.com (Fredrik Lundh) Date: Thu, 29 Jun 2000 20:05:34 +0200 Subject: [Python-Dev] OT: A Day in the Life of p5p References: <016301bfe0f1$0ca8ea40$f2a6b5d4@hagrid> <20000628113505.C15643@ludwig.cnri.reston.va.us> Message-ID: <02cd01bfe1f4$a271cca0$f2a6b5d4@hagrid> greg wrote: > On 28 June 2000, Fredrik Lundh said: > > http://prometheus.frii.com/~gnat/yapc/2000-p5p.txt > > > > unfortunately, his "What is it with those Python fucks anyway" talk > > isn't posted... ;-) > > But the "Conclusion" of his "Lies We Tell" talk: > > Perl sucks. Use Python. > > Presumably tongue-in-cheek, but you never know... note that all lies he mentioned earlier in that talk was quoted; this one wasn't. in other words, it's a fact. but we already know that, don't we ;-) From bwarsaw at beopen.com Thu Jun 29 20:56:52 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Thu, 29 Jun 2000 14:56:52 -0400 (EDT) Subject: [Python-Dev] Test results of linuxaudiodev.c References: <20000629135525.A5221@ludwig.cnri.reston.va.us> Message-ID: <14683.39924.477408.233069@anthem.concentric.net> >>>>> "GW" == Greg Ward writes: GW> then Cardinal Fang comes through loud and clear. ("play" is a GW> shell script wrapper for "sox", writing to /dev/dsp.) But if GW> I do this: GW> $ ./python Lib/test/regrtest.py test_linuxaudiodev GW> he's still audible (and at the same volume), but very GW> scratchy. Sounds kind of like a very over-driven amp, or like GW> a cheap car radio that somebody attacked with a knife. I don't even get that. play works fine for me too, but on this Dell Optiplex GX110 with unknown sound chip set, test_linuxaudiodev gives me nothing. -Barry From gstein at lyra.org Thu Jun 29 20:05:57 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 29 Jun 2000 11:05:57 -0700 Subject: [Python-Dev] sourceforge data (was: Let's use the SourceForge Patch Manager) In-Reply-To: <025701bfe1f2$ab5b8420$f2a6b5d4@hagrid>; from effbot@telia.com on Thu, Jun 29, 2000 at 07:51:32PM +0200 References: <395A32FD.D3C58B23@prescod.net> <20000628173424.H29590@lyra.org> <025701bfe1f2$ab5b8420$f2a6b5d4@hagrid> Message-ID: <20000629110557.W29590@lyra.org> On Thu, Jun 29, 2000 at 07:51:32PM +0200, Fredrik Lundh wrote: > greg wrote: > > I think you are being paranoid :-) > > > > Consider that this same issue applies to all 5900 projects and 38000 > > developers at SourceForge. VA Linux has a brand identity entirely built on > > the trust and support of the Linux (and Open Source) communities. If they > > blow away that trust, they are simply screwed. > > on the other hand, lots of people thought that dejanews > would store usenet postings forever... Different problem space. They weren't holding people's data. If SourceForge were ever to close, then I have 100% faith that they would make sure to provide a way for everybody to get their data off the machines. Worrying about it is a useless exercise, IMO. Cheers, -g -- Greg Stein, http://www.lyra.org/ From guido at beopen.com Thu Jun 29 21:05:11 2000 From: guido at beopen.com (Guido van Rossum) Date: Thu, 29 Jun 2000 14:05:11 -0500 Subject: [Python-Dev] CVS locks on SF In-Reply-To: Your message of "Thu, 29 Jun 2000 13:15:08 -0400." References: Message-ID: <200006291905.OAA17265@cj20424-a.reston1.va.home.com> > [MAL] > > I'm getting loads of lock messages during CVS checkins recently. > > Is this due to overload ? (I wonder why anoncvs access causes > > locking at all -- there is no write access so why should there > > be file locking ?): > > IIRC, CVS maintains the illusion of being a multi-user system by using > per-*directory* locks. That means it gives you the warm fuzzy feeling that > you're being protected against (e.g.) getting an inconsistent snapshot while > someone else is committing, but in fact you're not protected at all > (inter-directory). It locks per-directory to ensure the integrity of its > own data files, but users are subject to the luck of the draw. Yes, that's how it works... > Note that Perl is maintained under (the commercial, alas) Perforce, which is > one of the few SCMs to take multi-developer multi-directory issues > seriously. We tried Perforce at CNRI. It's really neat, but somehow it was lacking some stuff we were used to and we never converted. Note that Perforce is free for open source projects -- at least at the time it was. (CNRI paid a license fee, but that was just an expression of CNRI's reluctance against free software. :-) There's also bitkeeper. It stayed in beta so long that we gave up (and they have a weird license) -- but it's out of beta since May 4: see http://www.bitkeeper.com/. But there's no immediate download! You must sign up and they send you instructions in the mail... > So the good news is that when you see a CVS lock gripe, that means CVS is > protecting itself from corruption. The bad news is that if we used a system > that protected *us* against inconsistencies too, we'd probably see lock > gripes even more often. Well, the implementation could save the previous consistent version and give you that while an update was under way... There are other ways to protect against inconsistencies. But I'm not sure that you always *want* this -- as a system grows, it's better to be able to deal with inconsistencies than to try to avoid them (and have the world blow up in your face when the avoidance fails). Anyway, I submitted a service request to have the lock in the Lib/test lock removed. (Apparently some process didn't clear up its lock. That's rare, but sometimes it happens.) It's been fixed now, so checkins in the Lib/test directory should move forward again. --Guido van Rossum (home page: http://www.python.org/~guido/) From bckfnn at worldonline.dk Thu Jun 29 21:15:45 2000 From: bckfnn at worldonline.dk (Finn Bock) Date: Thu, 29 Jun 2000 19:15:45 GMT Subject: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163) In-Reply-To: References: Message-ID: <395b9f71.41379240@smtp.worldonline.dk> [Tim] >Well, neither Java's hashCode nor identityHashCode are correct >implementations of Python's id(), so JPython's id() is simply wrong. I agree. >I don't know anything about the internals of JPython. If there's a "choke >point" for allocating Python objects, The constructor of PyObject should do nicely. >the quickest way out may be to add a >write-once "id" field to each Python object under JPython, and simply fill >it with an integer that's (safely) incremented by 1 on each allocation. Properly have to be a java long to avoid overflowing. >Python doesn't guarantee you'll get the *same* id(x) across implementations, >or even across runs under a single implementation, so the implementations of >id() in CPython and JPython can do entirely different things. They have to >meet the promises in the Python docs, though, and JPython's currently >doesn't. I haven't considered it to be so important. It is possible to fix the std modules so it doesn't cause problems (as is done in cPickle.java). [Barry] >One question is what to do about Java proxies. Currently built-in >id() returns the identityHashCode() of the proxy object, which is just >an Object. I'm not sure sticking the id in the wrapper is the right >thing or not. It properly isn't. New wrappers can be created for the same object. F.ex when a java object is passed from python into java code and returned back into python, two wrappers will exists for the same java object. Since these two wrappers represent the same object they should (as it does now) return the same id() value. regards, finn From bwarsaw at beopen.com Thu Jun 29 21:23:48 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Thu, 29 Jun 2000 15:23:48 -0400 (EDT) Subject: [Python-Dev] Re: sourceforge data (was: Let's use the SourceForge Patch Manager) References: <395A32FD.D3C58B23@prescod.net> <20000628173424.H29590@lyra.org> <025701bfe1f2$ab5b8420$f2a6b5d4@hagrid> <20000629110557.W29590@lyra.org> <02d901bfe1f6$720ca920$f2a6b5d4@hagrid> Message-ID: <14683.41540.530581.459708@anthem.concentric.net> >>>>> "FL" == Fredrik Lundh writes: FL> btw, has anyone checked what's in: FL> http://cvs.sourceforge.net/cvstarballs/python-cvsroot.tar.gz I suck down nightly copies of that file and the corresponding Mailman tarball. I looked at them when I first set up my script, but haven't checked them lately. -Barry From nascheme at enme.ucalgary.ca Thu Jun 29 22:02:02 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Thu, 29 Jun 2000 14:02:02 -0600 Subject: [Python-Dev] CVS locks on SF In-Reply-To: <200006291905.OAA17265@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jun 29, 2000 at 02:05:11PM -0500 References: <200006291905.OAA17265@cj20424-a.reston1.va.home.com> Message-ID: <20000629140201.A20446@acs.ucalgary.ca> I recently made the conversion from CVS to PRCS. I like PRCS much better. It is easier to use, implemented indepentant of rcs, faster, more flexible and has versioned project meta-data. Branching and merging is much simpiler than CVS. Operations on project versions are atomic. Renaming and moving files is easy. It is well documented. Unfortunately version 1 does not support distributed repositories. Josh has informed my that version to is coming (hopefully this year) and will support distributed repositories. For Python I don't think that a multi-user version control system is strictly necessary anyhow. The PRCS repository could be made available via rsync and a process could be setup for checking patches into the central repository. It should actually be more efficient than the current CVS setup. I just looked at the webpage and the beta for 2.0 is out: http://www.xcf.berkeley.edu/~jmacd/prcs.html If PythonLabs is interested in using PRCS I will even volunteer to make sure those Windows weenies have a good port. :) Neil From jeremy at beopen.com Thu Jun 29 22:40:14 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Thu, 29 Jun 2000 16:40:14 -0400 (EDT) Subject: [Python-Dev] CVS locks on SF In-Reply-To: <20000629140201.A20446@acs.ucalgary.ca> References: <200006291905.OAA17265@cj20424-a.reston1.va.home.com> <20000629140201.A20446@acs.ucalgary.ca> Message-ID: <14683.46126.19856.447975@bitdiddle.concentric.net> I was just looking at Josh's work last week, and thought it looks quite interesting. Despite my interest, I don't expect we would use it for Python unless SourceForge adopted it. We moved the Python CVS tree to SourceForge to avoid maintaing a large installation of software development/management tools. Jeremy From klm at digicool.com Thu Jun 29 22:53:21 2000 From: klm at digicool.com (Ken Manheimer) Date: Thu, 29 Jun 2000 16:53:21 -0400 (EDT) Subject: [Python-Dev] Wikis for todo lists, etc (was PyString_GET_SIZE()) In-Reply-To: Message-ID: On Thu, 29 Jun 2000, Tim Peters wrote: > > ... > > Hmm. Is there a good place to start listing these todo items? > > Not that I know of. "Group whiteboards" and shared journals etc are darned > useful, though. Wiki = Group whiteboard Zope could do a lot of this stuff well. As is, ZWiki offers some organizational features. I've held off on pushing them because they're still baking - things like change notifications, discretion about change privileges, versions (with differences, based on your ndiff.py), etc are coming soonish. (Exactly how soonish is hard to say, the way time and more direct business obligations are - but this stuff actually is important to us, we're using them a lot for collaboration, and need for the dynamics to scale...) I also have the feeling that our tracker would be good for patch management - except, i don't really know what the requirements are, there, and once again, tracker only gives notifications via email, it doesn't take input that way. Anyway, to see leads on both zwikis and tracker, see: http://www.zope.org/Members/klm/TrackerWiki Oh, and it would be easy to set up a wiki for python dev on zope.org somewhere - i could put it in my account, or we could situate one more centrally, in a storage that's never packed, so the version history is maintained. Or any of you could get a zope.org membership and set some up, yerselves. Or set up a zope somewhere - it'd be !cool! if sourceforge were willing... Ken klm at zope.org From klm at digicool.com Thu Jun 29 23:25:55 2000 From: klm at digicool.com (Ken Manheimer) Date: Thu, 29 Jun 2000 17:25:55 -0400 (EDT) Subject: [Python-Dev] Wikis for todo lists, etc (was PyString_GET_SIZE()) In-Reply-To: Message-ID: On Thu, 29 Jun 2000, Ken Manheimer wrote: > Wiki = Group whiteboard > [...] > Oh, and it would be easy to set up a wiki for python dev on zope.org > somewhere - i could put it in my account, or we could situate one more http://www.zope.org/Members/klm/PythonDev/TodoLists There's nothing else of substance there, but anyone who's a member at zope.org can edit and add pages... Ken From guido at python.org Fri Jun 30 01:25:09 2000 From: guido at python.org (Guido van Rossum) Date: Thu, 29 Jun 2000 18:25:09 -0500 Subject: [Python-Dev] New PythonLabs site revealed! Message-ID: <200006292325.SAA19744@cj20424-a.reston1.va.home.com> Today, without much fanfare, we opened the new PythonLabs website. The design is by BeOpen's creative Director, Jun Simmons. Thanks to Jeremy Hylton, who did most of the actual HTML editing to get our contents in place. The new beta will be released via this site. And since you python-dev folks will find this out through my checkins anyway, let this be an advance warning that it will be called Python 2.0. Here's my explanation for the version bump (soon to be checked in to README): """ While Pythoneers have grown fond of Python's exceedingly slow version incrementing, that same quality makes parts of the rest of the world think Python is barely out of its first alpha test. Especially enterprise customers are often fearful of anything that's version 1.x! The new version number also clearly marks Python's departure from CNRI. Previously, the version number 2.0 was associated with a mythical and elusive incompatible future release. That release (still ways off, and not as incompatible as people fear!) is now referred to as Python 3000. """ --Guido van Rossum (home page: http://www.python.org/~guido/) From mwh21 at cam.ac.uk Fri Jun 30 00:53:39 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 29 Jun 2000 23:53:39 +0100 Subject: [Python-Dev] Test results of linuxaudiodev.c In-Reply-To: Greg Ward's message of "Thu, 29 Jun 2000 13:55:25 -0400" References: <20000629135525.A5221@ludwig.cnri.reston.va.us> Message-ID: Greg Ward writes: > Hi -- > > here are results from testing linuxaudiodev from the latest CVS Python > 1.6. This is on a Dell Dimension with on-board audio hardware: the > Yamaha YMF724 chipset. I'm using the ALSA 0.5.8a driver (the latest as > of a week or two ago, and the only one that supports the YMF724). > > Bottom line: the test sound plays, but it sounds horrible when played by > linuxaudiodev. If I do this: > > $ play Lib/test/audiotest.au > > then Cardinal Fang comes through loud and clear. ("play" is a shell > script wrapper for "sox", writing to /dev/dsp.) But if I do this: > > $ ./python Lib/test/regrtest.py test_linuxaudiodev > > he's still audible (and at the same volume), but very scratchy. Sounds > kind of like a very over-driven amp, or like a cheap car radio that > somebody attacked with a knife. > > [...some time passes...] > > OK, I just tried it on another machine, also a Dell but with a different > sound chip: the Crystal CS4232. I'm pretty sure this one is using the > OSS drivers included with the kernel, which is probably the second most > important difference after the chipset itself. Bottom line: it also > sounds horrible. Just tried that here; ouch. I have a Dell Dimension XPS D233 (which has an on-board Yamaha chipset - the OPL2, I believe). I use the sound driver that comes with the redhat built kernel (which is the OSS one I think). $ play audiotest.au sounds fine, $ ../../../build/python regrtest.py test_linuxaudiodev.py \ test_linuxaudiodev sounds horrible; it sounds like it's being rammed through at far too high a volume, but playing with the PCM or volume sliders in gmix has no appreciable effect on the quality. This suggests somewhat that the problem lies in linuxaudiodev.c, doesn't it? Is this stuff, like, documented anywhere? I can't find any helpful manpages... I presume this module must work better than this for some people? Cheers, M. From guido at python.org Fri Jun 30 02:20:15 2000 From: guido at python.org (Guido van Rossum) Date: Thu, 29 Jun 2000 19:20:15 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils msvccompiler.py,1.33,1.34 In-Reply-To: Your message of "Thu, 29 Jun 2000 16:05:01 MST." <200006292305.QAA11929@slayer.i.sourceforge.net> References: <200006292305.QAA11929@slayer.i.sourceforge.net> Message-ID: <200006300020.TAA21877@cj20424-a.reston1.va.home.com> > On second thought, first try for _winreg, and then winreg. Only if both > fail do we try for win32api/win32con. If *those* both fail, then we don't > have registry access. Phew! Is this smart? Doesn't the new winreg have a very different I/F than the old one? --Guido van Rossum (home page: http://www.python.org/~guido/) From pingster at ilm.com Fri Jun 30 01:24:28 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Thu, 29 Jun 2000 16:24:28 -0700 (PDT) Subject: [Python-Dev] Test results of linuxaudiodev.c In-Reply-To: Message-ID: On 29 Jun 2000, Michael Hudson wrote: > $ play audiotest.au > > sounds fine, > > $ ../../../build/python regrtest.py test_linuxaudiodev.py \ > test_linuxaudiodev > > sounds horrible; it sounds like it's being rammed through at far too > high a volume Sounds like u-law to me. linuxaudiodev.c selects /dev/dsp by default, which accepts raw data, not .au format. Try setting the environment variable AUDIODEV to /dev/audio before running the test script. Does that work any better? -- ?!ng From fdrake at beopen.com Fri Jun 30 01:29:42 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 29 Jun 2000 19:29:42 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils msvccompiler.py,1.33,1.34 In-Reply-To: <200006300020.TAA21877@cj20424-a.reston1.va.home.com> References: <200006292305.QAA11929@slayer.i.sourceforge.net> <200006300020.TAA21877@cj20424-a.reston1.va.home.com> Message-ID: <14683.56294.836295.923883@cj42289-a.reston1.va.home.com> Greg Ward wrote in a checkin message: > On second thought, first try for _winreg, and then winreg. Only if both > fail do we try for win32api/win32con. If *those* both fail, then we don't > have registry access. Phew! Guido van Rossum writes on python-dev: > Is this smart? Doesn't the new winreg have a very different I/F than > the old one? No, this is bad. It *will* break with winreg; if _winreg isn't available, it should use the win32api/win32con/whatever stuff; it's a Python 1.5.2 interpreter at that point. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From skip at mojam.com Fri Jun 30 00:22:18 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 29 Jun 2000 17:22:18 -0500 (CDT) Subject: [Python-Dev] Mysterious SF message... Message-ID: <14683.52250.789900.357275@beluga.mojam.com> I just submitted a patch for lib/libatexit.tex. In the response page it displayed a list of patches, then the following cryptic message: Patch Uploaded Successfully Added Patch Could Not Send Patch Update Any idea what that means? -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille O'Neal said: "He's got the rings. I listen to the man with the rings." From tim_one at email.msn.com Fri Jun 30 01:32:42 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 29 Jun 2000 19:32:42 -0400 Subject: [Python-Dev] Controversial patch (cmath) Message-ID: I just voted to accept a patch that's broken. If you want to argue it, be my guest, but I'm out of it now . Here's the patch: https://sourceforge.net/patch/?func=detailpatch&patch_id=100651&group_id=547 0 Here's my comment (also available on that page): Accepted (but reluctantly; see below), and assigned back to Guido for checkin. cmathmodule is not production quality, and this patch isn't either, but its asinh and acosh are better than what's there now. The author avoided some of the numerical foolishness in the original, but didn't avoid all of it. For example, it's harder to get asinh to do something ridiculous now than it was before, but still possible: >>> cmath.acosh(1e200) (461.210165779+0j) >>> cmath.asinh(1e200) (1.#INF+0j) >>> asinh should have returned something approximately equal to what acosh returned. That may not be the patch's problem, though! I suspect that's due to one of the module's other functions that's too naive about the limits of floating point. In any case, it is much easier to provoke the *current* cmath functions into cases like this one. Another possible problem has to do with principal values. My reference books are in storage, so about the best I can do right now is compare what this code does to Macsyma (which I have on my laptop). The acosh in this patch often returns the negative of what Macysma computes. For example, >>> cmath.acosh(-1-1j) (1.06127506191-2.23703575929j) >>> Macsyma returns the negation of that. On the other hand, the *original* acosh doesn't agree with Macsyma on some signs where this acosh does. So call this one a wash. I may have mentioned this before : robust math libraries are extremely difficult to get right. It would take several months to write a production-quality cmath module from scratch, which is several months more than were devoted to Python's current cmath . I vote we check this in anyway (since it *is*, overall, an improvement), and look into borrowing some other language's complex math library later (note in particular that C9X adds complex numbers and these functions on them, so if we sit on our asses long enough, we can inherit libc's!). From mwh21 at cam.ac.uk Fri Jun 30 01:33:37 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 30 Jun 2000 00:33:37 +0100 Subject: [Python-Dev] Test results of linuxaudiodev.c In-Reply-To: Ka-Ping Yee's message of "Thu, 29 Jun 2000 16:24:28 -0700 (PDT)" References: Message-ID: Ka-Ping Yee writes: > On 29 Jun 2000, Michael Hudson wrote: > > $ play audiotest.au > > > > sounds fine, > > > > $ ../../../build/python regrtest.py test_linuxaudiodev.py \ > > test_linuxaudiodev > > > > sounds horrible; it sounds like it's being rammed through at far too > > high a volume > > Sounds like u-law to me. linuxaudiodev.c selects /dev/dsp by > default, which accepts raw data, not .au format. > > Try setting the environment variable AUDIODEV to /dev/audio > before running the test script. Does that work any better? That's the ticket. "play" and the test now sound identical, modulo some pops & cracks at the start and end of the test. I presume what follows is thus a good idea? Index: test_linuxaudiodev.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/test/test_linuxaudiodev.py,v retrieving revision 1.1 diff -u -r1.1 test_linuxaudiodev.py --- test_linuxaudiodev.py 2000/06/10 04:22:57 1.1 +++ test_linuxaudiodev.py 2000/06/29 23:32:55 @@ -17,4 +17,6 @@ def test(): play_sound_file(findfile('audiotest.au')) +os.environ["AUDIODEV"] = "/dev/audio" + test() Cheers, M. From Vladimir.Marangozov at inrialpes.fr Fri Jun 30 01:38:19 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Fri, 30 Jun 2000 01:38:19 +0200 (CEST) Subject: [Python-Dev] New PythonLabs site revealed! In-Reply-To: <200006292325.SAA19744@cj20424-a.reston1.va.home.com> from "Guido van Rossum" at Jun 29, 2000 06:25:09 PM Message-ID: <200006292338.BAA07798@python.inrialpes.fr> Guido van Rossum wrote: > > Today, without much fanfare, we opened the new PythonLabs website. > The design is by BeOpen's creative Director, Jun Simmons. Thanks to > Jeremy Hylton, who did most of the actual HTML editing to get our > contents in place. > > The new beta will be released via this site. > > And since you python-dev folks will find this out through my checkins > anyway, let this be an advance warning that it will be called Python > 2.0. Here's my explanation for the version bump (soon to be checked > in to README): Guido van Rossum just won't stop surprising us! :-) Witness the three shocking news that arrived in one day: (1) very strict self-discipline about "long-term" TODO's full of short-term and less than medium-term topics that were very logically left behind, (2) major version number revision one day before the official beta-cycle, (3) a new PythonLabs corporate-style Web site with a flashing color palette & tutti quanti. I am really (positively) amazed! :-) spanish-inquisition-is-all-we-deserve--ly y'rs -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From fdrake at beopen.com Fri Jun 30 01:39:48 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 29 Jun 2000 19:39:48 -0400 (EDT) Subject: [Python-Dev] documentation patch guidelines Message-ID: <14683.56900.433607.125111@cj42289-a.reston1.va.home.com> I've updated the patch guidelines for documentation to match other patches, and added a patch category for documentation. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From pingster at ilm.com Fri Jun 30 01:46:32 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Thu, 29 Jun 2000 16:46:32 -0700 (PDT) Subject: [Python-Dev] Test results of linuxaudiodev.c In-Reply-To: Message-ID: On Thu, 29 Jun 2000, Ka-Ping Yee wrote: > Try setting the environment variable AUDIODEV to /dev/audio > before running the test script. Does that work any better? Even if that works, i realize that's not the way the interface was intended to be used. To play an AU file, the routine should look something like this (not tested, as i don't have a working Linux box)... def play_au_file(path): fp = open(path, "r") # Read the .au file header. header = fp.read(24) hdrsize, length, encoding, rate, channels = \ struct.unpack(">xxxxiiiii", header) fp.read(hdrsize - 24) data = fp.read() fp.close() # Set the data format according to the code in the .au header. if encoding == 1: size, fmt = 8, linuxaudiodev.AFMT_MU_LAW elif encoding == 2: size, fmt = 8, linuxaudiodev.AFMT_S8 elif encoding == 3: size, fmt = 16, linuxaudiodev.AFMT_S16_BE else: raise "audio format not supported" dsp = linuxaudiodev.open("w") dsp.setparameters(rate, size, channels, fmt) dsp.write(data) dsp.close() -- ?!ng Explicit hoc totum; This completes the whole; Pro Christo da mihi potum. For Christ's sake give me a drink. -- from the colophon of a 12th-century copyist From nascheme at enme.ucalgary.ca Fri Jun 30 02:00:37 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Thu, 29 Jun 2000 18:00:37 -0600 Subject: [Python-Dev] Mysterious SF message... In-Reply-To: <14683.52250.789900.357275@beluga.mojam.com>; from skip@mojam.com on Thu, Jun 29, 2000 at 05:22:18PM -0500 References: <14683.52250.789900.357275@beluga.mojam.com> Message-ID: <20000629180037.A22566@acs.ucalgary.ca> On Thu, Jun 29, 2000 at 05:22:18PM -0500, Skip Montanaro wrote: > > I just submitted a patch for lib/libatexit.tex. In the response page it > displayed a list of patches, then the following cryptic message: > > Patch Uploaded Successfully Added Patch Could Not Send Patch Update > > Any idea what that means? SourceForge sucks? Seriously though, I think it means: Patch Uploaded Successfully, Added Patch, Could Not Send Patch Update For some reason it couldn't email out the patch update URL. Neil From mwh21 at cam.ac.uk Fri Jun 30 02:06:04 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 30 Jun 2000 01:06:04 +0100 Subject: [Python-Dev] Test results of linuxaudiodev.c In-Reply-To: Ka-Ping Yee's message of "Thu, 29 Jun 2000 16:46:32 -0700 (PDT)" References: Message-ID: Ka-Ping Yee writes: > On Thu, 29 Jun 2000, Ka-Ping Yee wrote: > > Try setting the environment variable AUDIODEV to /dev/audio > > before running the test script. Does that work any better? > > Even if that works, i realize that's not the way the interface > was intended to be used. To play an AU file, the routine should > look something like this (not tested, as i don't have a working > Linux box)... [snip] Yup, that works fine. Don't understand the details - and as I have my graduation ceremony tomorrow I'm going to go to bed and leave learning them until some other occasion! Cheers, M. PS: my Lib/test/test_linuxaudiodev.py is now this: from test_support import verbose, findfile, TestFailed import linuxaudiodev import os,struct def play_au_file(path): fp = open(path, "r") # Read the .au file header. header = fp.read(24) hdrsize, length, encoding, rate, channels = \ struct.unpack(">xxxxiiiii", header) fp.read(hdrsize - 24) data = fp.read() fp.close() # Set the data format according to the code in the .au header. if encoding == 1: size, fmt = 8, linuxaudiodev.AFMT_MU_LAW elif encoding == 2: size, fmt = 8, linuxaudiodev.AFMT_S8 elif encoding == 3: size, fmt = 16, linuxaudiodev.AFMT_S16_BE else: raise "audio format not supported" dsp = linuxaudiodev.open("w") dsp.setparameters(rate, size, channels, fmt) dsp.write(data) dsp.close() def test(): play_au_file(findfile('audiotest.au')) test() ... which is an improvement on what's there now. From pingster at ilm.com Fri Jun 30 02:44:35 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Thu, 29 Jun 2000 17:44:35 -0700 (PDT) Subject: [Python-Dev] Test results of linuxaudiodev.c In-Reply-To: Message-ID: On 30 Jun 2000, Michael Hudson wrote: > Yup, that works fine. Don't understand the details - and as I have my > graduation ceremony tomorrow I'm going to go to bed and leave learning > them until some other occasion! Cool. Okay, i just discovered sunau.py. Here's my real shot at test_linuxaudiodev.py. Can you give this a try? ---- test_linuxaudiodev.py ---- from test_support import verbose, findfile, TestFailed import linuxaudiodev import os, sunau formats = {("ULAW", 1): linuxaudiodev.AFMT_MU_LAW, ("NONE", 1): linuxaudiodev.AFMT_S8, ("NONE", 2): linuxaudiodev.AFMT_S16_BE} def play_au_file(path): au = sunau.open(path, "r") data = au.readframes(sunau.AUDIO_UNKNOWN_SIZE) au.close() spec = (au.getcomptype(), au.getsampwidth()) if not has_key(formats, spec): raise "audio format not supported by linuxaudiodev" dsp = linuxaudiodev.open("w") dsp.setparameters(au.getframerate(), au.getsampwidth() * 8, au.getnchannels(), formats[spec]) dsp.write(data) dsp.close() def test(): play_au_file(findfile('audiotest.au')) test() ---- test_linuxaudiodev.py ---- -- ?!ng From gstein at lyra.org Fri Jun 30 03:03:11 2000 From: gstein at lyra.org (Greg Stein) Date: Thu, 29 Jun 2000 18:03:11 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib sre.py,1.9,1.10 sre_compile.py,1.7,1.8 sre_constants.py,1.7,1.8 sre_parse.py,1.7,1.8 In-Reply-To: <200006291238.FAA01061@slayer.i.sourceforge.net>; from effbot@users.sourceforge.net on Thu, Jun 29, 2000 at 05:38:48AM -0700 References: <200006291238.FAA01061@slayer.i.sourceforge.net> Message-ID: <20000629180311.I29590@lyra.org> Fredrik, Something you are doing is forcing CVS to issue a new revision for some of those files, even when you are not changing them. These "false" revisions are probably not a good thing. Could you review your checkin process to see what is up? I would guess that you have the "-f" option in your commit line. Cheers, -g On Thu, Jun 29, 2000 at 05:38:48AM -0700, Fredrik Lundh wrote: > Update of /cvsroot/python/python/dist/src/Lib > In directory slayer.i.sourceforge.net:/tmp/cvs-serv899/Lib > > Modified Files: > sre.py sre_compile.py sre_constants.py sre_parse.py > Log Message: > > > - make sure group names are valid identifiers > (closes the "SRE: symbolic reference" bug) > > Index: sre.py > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Lib/sre.py,v > retrieving revision 1.9 > retrieving revision 1.10 > diff -C2 -r1.9 -r1.10 > > Index: sre_compile.py > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Lib/sre_compile.py,v > retrieving revision 1.7 > retrieving revision 1.8 > diff -C2 -r1.7 -r1.8 > > Index: sre_constants.py > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Lib/sre_constants.py,v > retrieving revision 1.7 > retrieving revision 1.8 > diff -C2 -r1.7 -r1.8 > > Index: sre_parse.py > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Lib/sre_parse.py,v > retrieving revision 1.7 > retrieving revision 1.8 > diff -C2 -r1.7 -r1.8 > *** sre_parse.py 2000/06/29 11:34:27 1.7 > --- sre_parse.py 2000/06/29 12:38:45 1.8 > *************** > *** 169,172 **** > --- 169,190 ---- > return this > > + def isident(char): > + return "a" <= char <= "z" or "A" <= char <= "Z" or char == "_" > + > + def isdigit(char): > + return "0" <= char <= "9" > + > + def isname(name): > + # check that group name is a valid string > + # FIXME: this code is really lame. should use a regular > + # expression instead, but I seem to have certain bootstrapping > + # problems here ;-) > + if not isident(name[0]): > + return 0 > + for char in name: > + if not isident(char) and not isdigit(char): > + return 0 > + return 1 > + > def _group(escape, state): > # check if the escape string represents a valid group > *************** > *** 419,425 **** > if char == ">": > break > - # FIXME: check for valid character > name = name + char > group = 1 > elif source.match("="): > # named backreference > --- 437,444 ---- > if char == ">": > break > name = name + char > group = 1 > + if not isname(name): > + raise error, "illegal character in group name" > elif source.match("="): > # named backreference > *************** > *** 523,540 **** > char = s.get() > if char is None: > ! raise error, "unterminated index" > if char == ">": > break > - # FIXME: check for valid character > name = name + char > if not name: > ! raise error, "bad index" > try: > index = int(name) > except ValueError: > try: > index = pattern.groupindex[name] > except KeyError: > ! raise IndexError, "unknown index" > a((MARK, index)) > elif len(this) > 1 and this[1] in DIGITS: > --- 542,560 ---- > char = s.get() > if char is None: > ! raise error, "unterminated group name" > if char == ">": > break > name = name + char > if not name: > ! raise error, "bad group name" > try: > index = int(name) > except ValueError: > + if not isname(name): > + raise error, "illegal character in group name" > try: > index = pattern.groupindex[name] > except KeyError: > ! raise IndexError, "unknown group name" > a((MARK, index)) > elif len(this) > 1 and this[1] in DIGITS: > > > _______________________________________________ > Python-checkins mailing list > Python-checkins at python.org > http://www.python.org/mailman/listinfo/python-checkins -- Greg Stein, http://www.lyra.org/ From akuchlin at cnri.reston.va.us Fri Jun 30 03:29:41 2000 From: akuchlin at cnri.reston.va.us (Andrew Kuchling) Date: Thu, 29 Jun 2000 21:29:41 -0400 Subject: [Python-Dev] Removing modules Message-ID: <20000629212941.A21563@newcnri.cnri.reston.va.us> For the "deleted modules" section of the 2.0 article, I drew up a list of modules that might be outdated, mostly the SGI-specific ones. Are those modules still useful, and do the libraries they were written for still exist? For your cogitation, here's the list: sgimodule.c, glmodule.c (and hence cgenmodule.c), imgfile.c, svmodule.c, flmodule.c, fmmodule.c, almodule.c, clmodule.c, knee.py. Also, can someone explain why importing a third party extension built for Python 1.5.x is supposed to result in an immediate crash on Windows? I'd like to explain why this happens... --amk From guido at python.org Fri Jun 30 05:13:13 2000 From: guido at python.org (Guido van Rossum) Date: Thu, 29 Jun 2000 22:13:13 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib sre.py,1.9,1.10 sre_compile.py,1.7,1.8 sre_constants.py,1.7,1.8 sre_parse.py,1.7,1.8 In-Reply-To: Your message of "Thu, 29 Jun 2000 18:03:11 MST." <20000629180311.I29590@lyra.org> References: <200006291238.FAA01061@slayer.i.sourceforge.net> <20000629180311.I29590@lyra.org> Message-ID: <200006300313.WAA22134@cj20424-a.reston1.va.home.com> > Fredrik, > > Something you are doing is forcing CVS to issue a new revision for some of > those files, even when you are not changing them. These "false" revisions > are probably not a good thing. > > Could you review your checkin process to see what is up? I would guess that > you have the "-f" option in your commit line. > > Cheers, > -g Greg, we already know why this is. It's the $ID$. --Guido van Rossum (home page: http://www.python.org/~guido/) From mhammond at skippinet.com.au Fri Jun 30 04:49:06 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Fri, 30 Jun 2000 12:49:06 +1000 Subject: [Python-Dev] Removing modules In-Reply-To: <20000629212941.A21563@newcnri.cnri.reston.va.us> Message-ID: > Also, can someone explain why importing a third party extension built > for Python 1.5.x is supposed to result in an immediate crash on > Windows? I'd like to explain why this happens... The 1.5 module is linked against Python15.dll. When Python.exe (linked against Python16.dll) starts up, it initializes the Python data structures in Python16.dll. When Python then imports foo.pyd (linked against Python15.dll), it immediately tries to call the functions in that DLL (such as getting the thread state). As Python has not been initialized in that DLL, we immediately die. Ironically, if Python1x.dll was simply named "Python.dll", there is a _reasonable_ chance it would work fine. The cost of doing this tho, is that you can not have Python 1.5 and Python 1.6 "side by side" on the same machine. There are a few possibilities for magic tricks we could pull, but to be honest Im not too inclined to bother with them myself... They would also require a commitment to a fully backwards compatible C API, which I dont think we can afford to commit to! Mark. From gward at python.net Fri Jun 30 05:30:03 2000 From: gward at python.net (Greg Ward) Date: Thu, 29 Jun 2000 23:30:03 -0400 Subject: [Python-Dev] Hey! who changed sys.platform?! Message-ID: <20000629233003.A1766@beelzebub> Curses! I just noticed that sys.platform in 1.6a2 (and the latest CVS from this morning) returns "linux2" on my PC, not "linux-i386". As I recall this decision is made in the configure script. Does anyone know why it changed? This is not the end of the world, but the OS name alone is not really enough on a multi-architecture OS... ...back to calling os.uname() myself, I guess. ;-( Greg -- Greg Ward - programmer-at-big gward at python.net http://starship.python.net/~gward/ God made machine language; all the rest is the work of man. From fdrake at beopen.com Fri Jun 30 05:33:45 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Thu, 29 Jun 2000 23:33:45 -0400 (EDT) Subject: [Python-Dev] Hey! who changed sys.platform?! In-Reply-To: <20000629233003.A1766@beelzebub> References: <20000629233003.A1766@beelzebub> Message-ID: <14684.5401.518766.362678@cj42289-a.reston1.va.home.com> Greg Ward writes: > I just noticed that sys.platform in 1.6a2 (and the latest CVS from this > morning) returns "linux2" on my PC, not "linux-i386". As I recall this I didn't know it ever returned linux-i386; perhaps you're thinking of Marc-Andre's platform module? -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From trentm at activestate.com Fri Jun 30 05:34:17 2000 From: trentm at activestate.com (Trent Mick) Date: Thu, 29 Jun 2000 20:34:17 -0700 Subject: [Python-Dev] Controversial patch (cmath) In-Reply-To: References: Message-ID: <20000629203417.B23077@activestate.com> [Tim discusses god awful math details] Would you want to foward this to python-list to see if any lurking mathematicians might be spurred to action? Trent -- Trent Mick trentm at activestate.com From gward at python.net Fri Jun 30 05:53:34 2000 From: gward at python.net (Greg Ward) Date: Thu, 29 Jun 2000 23:53:34 -0400 Subject: [Python-Dev] Hey! who changed sys.platform?! In-Reply-To: <14684.5401.518766.362678@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Thu, Jun 29, 2000 at 11:33:45PM -0400 References: <20000629233003.A1766@beelzebub> <14684.5401.518766.362678@cj42289-a.reston1.va.home.com> Message-ID: <20000629235334.B1294@beelzebub> On 29 June 2000, Fred L. Drake, Jr. said: > I didn't know it ever returned linux-i386; perhaps you're thinking > of Marc-Andre's platform module? D'ohh! That appears to be an artifact of Red Hat's build -- I was using /usr/bin/python (theirs), not /usr/local/bin/python (mine). $ /usr/bin/python Python 1.5.2 (#1, Feb 1 2000, 16:32:16) [GCC egcs-2.91.66 19990314/Linux (egcs- on linux-i386 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> sys.platform 'linux-i386' Sorry for getting alarmist. Guess I never should have started using sys.platform in the first place (or just not worry about getting the CPU in there too). Greg -- Greg Ward - geek gward at python.net http://starship.python.net/~gward/ Support bacteria -- it's the only culture some people have! From skip at mojam.com Fri Jun 30 04:57:47 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 29 Jun 2000 21:57:47 -0500 (CDT) Subject: [Python-Dev] available to look at bugs and patches... Message-ID: <14684.3243.480545.880199@beluga.mojam.com> Barry added me as a developer yesterday. Those people assigning bugs and patches can use me as a resource... Skip From gward at python.net Fri Jun 30 06:26:20 2000 From: gward at python.net (Greg Ward) Date: Fri, 30 Jun 2000 00:26:20 -0400 Subject: [Python-Dev] ANNOUNCE: Distutils 0.9 Message-ID: <20000630002620.A2329@beelzebub> Python Distribution Utilities release 0.9 June 29, 2000 The Python Distribution Utilities, or Distutils for short, are a collection of modules that aid in the development, distribution, and installation of Python modules. (It is intended that ultimately the Distutils will grow up into a system for distributing and installing whole Python applications, but for now their scope is limited to module distributions.) The Distutils are a standard part of Python 2.0; if you are running 2.0 (or one of the 1.6 alpha releases that preceded it), you don't need to install the Distutils separately. This release is primarily so that you can add the Distutils to a Python 1.5.2 installation -- you will then be able to install modules that require the Distutils, or use the Distutils to distribute your own modules. More information is available at the Distutils web page: http://www.python.org/sigs/distutils-sig/ and in the README.txt included in the Distutils source distribution. You can download the Distutils from http://www.python.org/sigs/distutils-sig/download.html Trivial patches can be sent to me (Greg Ward) at gward at python.net. Larger patches should be discussed on the Distutils mailing list: distutils-sig at python.org. From tim_one at email.msn.com Fri Jun 30 07:05:32 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 30 Jun 2000 01:05:32 -0400 Subject: [Python-Dev] Controversial patch (cmath) In-Reply-To: <20000629203417.B23077@activestate.com> Message-ID: [Trent Mick] > [Tim discusses god awful math details] > Would you want to foward this to python-list to see if any lurking > mathematicians might be spurred to action? God, please no! This requires a numerical analyst, not a mathematician. Voting by talented amateurs is only going to make things worse <0.5 wink>. I was an NA in a previous life, and know what needs to be done to resolve all this. But that takes way more time than we have before 2.0b1. The patch in question makes life better for the world's only known user of cmath . may-as-well-ask-c.l.py-to-discuss-python's-version-number-ly y'rs - tim From jeremy at beopen.com Fri Jun 30 07:08:30 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 30 Jun 2000 01:08:30 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Include objimpl.h,2.16,2.17 In-Reply-To: <200006300502.WAA03256@slayer.i.sourceforge.net> References: <200006300502.WAA03256@slayer.i.sourceforge.net> Message-ID: <14684.11086.47325.776691@bitdiddle.concentric.net> These patches should catch up with Neil's latest submissions, but may not have the very latest changes suggested by Neil and Vladimir. I will double-check with them in the morning. I will also change configure.in to enable GC by default for the beta test phase, unless there is strong objection. Jeremy From skip at mojam.com Fri Jun 30 06:00:29 2000 From: skip at mojam.com (Skip Montanaro) Date: Thu, 29 Jun 2000 23:00:29 -0500 (CDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test/output test_gc,NONE,1.1 In-Reply-To: <200006300502.WAA03286@slayer.i.sourceforge.net> References: <200006300502.WAA03286@slayer.i.sourceforge.net> Message-ID: <14684.7005.661874.713000@beluga.mojam.com> Jeremy> Log Message: Jeremy> final patches from Neil Schemenauer for garbage collection Jeremy> --- NEW FILE --- Jeremy> test_gc Jeremy> list 0x831a754 Jeremy> dict 0x831a754 ... Jeremy> dict 0x831a9bc Jeremy> func 0x831d9e4 I can all but guarantee you this test will always fail. Printing absolute machine addresses (via calls to id() in this case) in test cases should be verboten. -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille O'Neal said: "He's got the rings. I listen to the man with the rings." From trentm at activestate.com Fri Jun 30 08:05:50 2000 From: trentm at activestate.com (Trent Mick) Date: Thu, 29 Jun 2000 23:05:50 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/PCbuild python16.dsp,1.6,1.7 In-Reply-To: <200006300502.WAA03275@slayer.i.sourceforge.net> References: <200006300502.WAA03275@slayer.i.sourceforge.net> Message-ID: <20000629230550.A24811@activestate.com> On Thu, Jun 29, 2000 at 10:02:55PM -0700, Jeremy Hylton wrote: > Update of /cvsroot/python/python/dist/src/PCbuild > In directory slayer.i.sourceforge.net:/tmp/cvs-serv3220/PCbuild > > Modified Files: > python16.dsp > Log Message: > final patches from Neil Schemenauer for garbage collection > > > Index: python16.dsp > =================================================================== > RCS file: /cvsroot/python/python/dist/src/PCbuild/python16.dsp,v > retrieving revision 1.6 > retrieving revision 1.7 > diff -C2 -r1.6 -r1.7 > *** python16.dsp 2000/06/06 23:29:09 1.6 > --- python16.dsp 2000/06/30 05:02:53 1.7 > *************** > *** 660,663 **** > --- 660,677 ---- > # End Source File > # Begin Source File > + SOURCE=..\Modules\gcmodule.c > + > + !IF "$(CFG)" == "python16 - Win32 Release" > + > + !ELSEIF "$(CFG)" == "python16 - Win32 Debug" > + > + !ELSEIF "$(CFG)" == "python16 - Win32 Alpha Debug" > + > + !ELSEIF "$(CFG)" == "python16 - Win32 Alpha Release" > + > + !ENDIF > + > + # End Source File > + # Begin Source File > > SOURCE=..\Python\getargs.c > Pardon me if I am wrong (I have not actually checked the repository) but is this correct now that the version number is 2.0? Trent -- Trent Mick trentm at activestate.com From trentm at activestate.com Fri Jun 30 08:27:33 2000 From: trentm at activestate.com (Trent Mick) Date: Thu, 29 Jun 2000 23:27:33 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test README,NONE,1.1 In-Reply-To: <200006300608.XAA13124@slayer.i.sourceforge.net> References: <200006300608.XAA13124@slayer.i.sourceforge.net> Message-ID: <20000629232733.D24811@activestate.com> Cool On Thu, Jun 29, 2000 at 11:08:38PM -0700, Skip Montanaro wrote: > > --- NEW FILE --- > Writing Python Test Cases > ------------------------- > Skip Montanaro > > > To run the entire test suite, make the "test" target at the top level: > > cd ... > make test This is a UN*Xism, on Windows and UN*X: cd ...\Lib\test python regrtest.py A sample walk through to create a test might make it more approachable for people. As well, it would be helpful to mention test_support.{verbose|TESTFN|...}. But I have no right to bitch about good work. Trent -- Trent Mick trentm at activestate.com From tim_one at email.msn.com Fri Jun 30 08:39:15 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 30 Jun 2000 02:39:15 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test README,NONE,1.1 In-Reply-To: <20000629232733.D24811@activestate.com> Message-ID: [Trent Mick] > ... > But I have no right to bitch about good work. How do you figure that? We do it to you enough . BTW, I'd just like to say what a delight it is to work with *all* of you folks! I wanted to say that before I can be accused of pimping for my employer -- so far, BeOpen hasn't paid me a dime, so you know my opinion hasn't yet been bought. well-maybe-on-credit-ly y'rs - tim From tim_one at email.msn.com Fri Jun 30 08:39:12 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 30 Jun 2000 02:39:12 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/PCbuild python16.dsp,1.6,1.7 In-Reply-To: <20000629230550.A24811@activestate.com> Message-ID: [Trent Mick, on Guido's late-night (for him ) checkin of python16.dsp] > Pardon me if I am wrong (I have not actually checked the > repository) but is this correct now that the version number is 2.0? No, it is not, and the Windows build is slightly damaged now. I've already yelled at Guido about this, but I suspect he's asleep. I'm sure it will get sorted out in the morning. From trentm at activestate.com Fri Jun 30 08:52:47 2000 From: trentm at activestate.com (Trent Mick) Date: Thu, 29 Jun 2000 23:52:47 -0700 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test README,NONE,1.1 In-Reply-To: References: <20000629232733.D24811@activestate.com> Message-ID: <20000629235247.A25090@activestate.com> On Fri, Jun 30, 2000 at 02:39:15AM -0400, Tim Peters wrote: > BTW, I'd just like to say what a delight it is to work with *all* of you > folks! I feel a group hug coming on in the morning. Or maybe I am just moved by the beer that I had for dinner. :) Likewise, Tim. As my first foray into community development I find this, Python dev, a refreshing pleasure. Trent -- Trent Mick trentm at activestate.com From tim_one at email.msn.com Fri Jun 30 09:41:28 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 30 Jun 2000 03:41:28 -0400 Subject: [Python-Dev] Wikis for todo lists, etc (was PyString_GET_SIZE()) In-Reply-To: Message-ID: [Tim] > ... "Group whiteboards" and shared journals etc are darned > useful, though. [Ken Manheimer] > Wiki = Group whiteboard Ya, I kind of picked that up from your last passionate advertisement for this stuff . Not knocking it! Never tried it. Believe it or not, I spend as little time on the web as possible. After I've gotten into a place to live here, and this current release crunch is behind us, I'm definitely going to check out your leads. For the past several years my development group worked thru Lotus Notes, which I didn't much care for at the time, but I'm increasingly realizing just how essential group-modifiable shared persistent documents were to our productivity. Notes is the purest example of a whole being greater than the sum of its parts I've ever seen (lousy mail system, lousy database, lousy change manager, lousy bug tracker, lousy workflow manager, worse than lousy native scripting ... but they all sucked in ways that were downright synergistic <0.9 wink>). > ... > Anyway, to see leads on both zwikis and tracker, see: > > http://www.zope.org/Members/klm/TrackerWiki can-beopen-zwiki-2.0-be-far-behind?-ly y'rs - tim From pingster at ilm.com Fri Jun 30 10:21:08 2000 From: pingster at ilm.com (Ka-Ping Yee) Date: Fri, 30 Jun 2000 01:21:08 -0700 (PDT) Subject: [Python-Dev] New PythonLabs site revealed! In-Reply-To: <200006292338.BAA07798@python.inrialpes.fr> Message-ID: Guido van Rossum wrote: > let this be an advance warning that it will be called Python 2.0. On Fri, 30 Jun 2000, Vladimir Marangozov wrote: > Guido van Rossum just won't stop surprising us! :-) Will many be spooked by the jump in version number into fearing incompatibility with older scripts...? I wonder if we'll end up trying to persuade the user community that the changes are small ("no, don't worry, your scripts will still work") and yet big ("honest, it really deserves to be called 2.0, it's not just a ploy") at the same time. Perl 5 was basically incompatible with Perl 4. Some things run, but a lot don't. (Actually many microversions of Perl 5 were mutually incompatible with each other, but i'll ignore that. :) ) I've thought of the jump to Python3k (lowercase "k", please) much like the Perl-4-to-Perl-5 jump: simple stuff is still okay but a lot of guts have changed. If i hadn't been "on the inside" watching development activity, i might expect something of similar magnitude upon hearing of going from Python 1.x to 2.0. I guess we can point at Unicode and SRE as big things. -- ?!ng From effbot at telia.com Fri Jun 30 10:33:10 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 30 Jun 2000 10:33:10 +0200 Subject: [Python-Dev] SRE status report Message-ID: <005001bfe26d$d3dc3540$f2a6b5d4@hagrid> just checked in a test script for sre. the test_sre file is a copy of test_re, with some minor changes: -- disabled one test (caused by bug #8; see below) -- added T (template mode, experimental, unsupported) and U (unicode locale) flags to the flag test -- removed keyword arguments in pattern test loop: result = obj.search(s, pos=result.start(0), endpos=result.end(0)+1) was changed to: result = obj.search(s, result.start(0), result.end(0)+1) as far as I can tell, the docs don't mention anything about keyword arguments... -- added unicode pattern / target string / locale tests to the pattern test loop. however, the current version SRE doesn't fully pass the test. here's an annotated version of Lib/test/output/test_sre: 1) test_support -- test failed re module pickle 2) test_support -- test failed re module cPickle under SRE, patterns are C objects, not class instances. to allow pickling, I need to modify copy_reg (either by modifing the file itself, or by updating the registry when SRE is first imported). see patch #100650 for more info, 3) === Syntax error: ('(?Pa)(?P=foo_123)', 'aa', 0, 'g1', 'a') this is a bug in the SRE parser. should be easy to fix. 4) === Failed incorrectly ('^(.+)?B', 'AB', 0, 'g1', 'A') this is a bug in the engine (nested repetitions). needs further research. 5) === Failed incorrectly ('(a+)+\\1', 'aa', 0, 'found+"-"+g1', 'aa-a') this is a bug in the engine or in the parser. needs further research. 6) === grouping error ('([^/]*/)*sub1/', 'd:msgs/tdir/sub1/trial/away.cpp', 0, 'found+"-"+g1', 'd:msgs/tdir/sub1/-tdir/') 'd:msgs/tdir/sub1/-trial/' should be 'd:msgs/tdir/sub1/-tdir/' same as #5. 7) === Syntax error: ('(?Paa)(?P=id)', 'aaaa', 0, 'found+"-"+id', 'aaaa-aa') same as #3. 8) === grouping error ('([abc])*bcd', 'abcd', 0, 'found+"-"+g1', 'abcd-a') 'abcd-c' should be 'abcd-a' this is a bug in the engine. should be easy to fix, I think. in fact, I could have sworn that I'd fixed it already. 9) === grouping error ('(?i)([abc])*bcd', 'ABCD', 0, 'found+"-"+g1', 'ABCD-A') 'ABCD-C' should be 'ABCD-A' same as #8 10) === Syntax error: ('a(?!b).', 'abad', 0, 'found', 'ad') this is bug in the parser. should be easy to fix. 11) === Syntax error: ('a(?=d).', 'abad', 0, 'found', 'ad') same as (or at least related to) #10 12) === Syntax error: ('a(?=c|d).', 'abad', 0, 'found', 'ad') same as #11 13) === Failed incorrectly ('^(.+)?B', 'AB', 0, 'g1', 'A') same as #4 (literally!). ... fwiw, *all* RE-based code I've played with seem to work. ymmv. let me know asap if it does. From mhammond at skippinet.com.au Fri Jun 30 10:41:44 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Fri, 30 Jun 2000 18:41:44 +1000 Subject: [Python-Dev] New PythonLabs site revealed! In-Reply-To: Message-ID: > Will many be spooked by the jump in version number into fearing > incompatibility with older scripts...? > > I wonder if we'll end up trying to persuade the user community that > the changes are small ("no, don't worry, your scripts will still > work") and yet big ("honest, it really deserves to be called 2.0, > it's not just a ploy") at the same time. I see your concerns, but I think the trick is to be honest, just as Guido was. We simply say it was bumped to V2 for the reasons of percieved maturity, and a clear break from CNRI Python. Both seem reasonable. I believe many people will simply wait for some form of consensus on the newsgroup, regardless of the version number. Personally, Im a little - umm - lets just say that I can see the irony in the fact that I recently changed a few bits of code that were dependent on a hard-coded "Python15.dll" to work not only with 1.6, but _all_ of the 1.x family. I figured there was no point trying to predict the packaging details of the 2.x family, seeing it as still some time off. Nothing like foresight :-) And-"foresight"-isnt-an-excuse-for-Tim-to-get-back-on-the-topic-of-his-geni tals--ly, Mark. From effbot at telia.com Fri Jun 30 10:55:01 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 30 Jun 2000 10:55:01 +0200 Subject: [Python-Dev] New PythonLabs site revealed! References: Message-ID: <005801bfe270$e140d440$f2a6b5d4@hagrid> mark wrote: > Personally, Im a little - umm - lets just say that I can see the irony in > the fact that I recently changed a few bits of code that were dependent on > a hard-coded "Python15.dll" to work not only with 1.6, but _all_ of the 1.x > family. heh. you're not the only one... btw, now that we're bumping to 2.0, maybe we can break socket.connect and friends once again? if somebody com- plains, just tell them "it's a major release, dammit" ;-) From gstein at lyra.org Fri Jun 30 10:59:56 2000 From: gstein at lyra.org (Greg Stein) Date: Fri, 30 Jun 2000 01:59:56 -0700 Subject: [Python-Dev] CVS locks on SF In-Reply-To: <200006291905.OAA17265@cj20424-a.reston1.va.home.com>; from guido@beopen.com on Thu, Jun 29, 2000 at 02:05:11PM -0500 References: <200006291905.OAA17265@cj20424-a.reston1.va.home.com> Message-ID: <20000630015956.S29590@lyra.org> On Thu, Jun 29, 2000 at 02:05:11PM -0500, Guido van Rossum wrote: >... > > Note that Perl is maintained under (the commercial, alas) Perforce, which is > > one of the few SCMs to take multi-developer multi-directory issues > > seriously. > > We tried Perforce at CNRI. It's really neat, but somehow it was > lacking some stuff we were used to and we never converted. > > Note that Perforce is free for open source projects -- at least at the > time it was. (CNRI paid a license fee, but that was just an > expression of CNRI's reluctance against free software. :-) > > There's also bitkeeper. It stayed in beta so long that we gave up > (and they have a weird license) -- but it's out of beta since May 4: > see http://www.bitkeeper.com/. But there's no immediate download! > You must sign up and they send you instructions in the mail... And coming down the pipe (end of the year) is Subversion: http://subversion.tigris.org/ Cheers, -g -- Greg Stein, http://www.lyra.org/ From mhammond at skippinet.com.au Fri Jun 30 11:23:53 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Fri, 30 Jun 2000 19:23:53 +1000 Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/PCbuild readme.txt,1.5,1.6 In-Reply-To: <200006300904.CAA04151@slayer.i.sourceforge.net> Message-ID: > Making a tiny change to figure out what I'm going to screw up > by trying to use CVS under Windows at all ... Congratulations :-) Mark. From mhammond at skippinet.com.au Fri Jun 30 11:25:39 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Fri, 30 Jun 2000 19:25:39 +1000 Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/PCbuild readme.txt,1.5,1.6 In-Reply-To: Message-ID: > To: python-dev at python.org Damn damn damn - did it again. Sorry. [I wishing mailing-lists would agree on how they handle reply-to :-] Mark. From mal at lemburg.com Fri Jun 30 11:27:57 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 30 Jun 2000 11:27:57 +0200 Subject: [Python-Dev] Hey! who changed sys.platform?! References: <20000629233003.A1766@beelzebub> <14684.5401.518766.362678@cj42289-a.reston1.va.home.com> Message-ID: <395C681D.C3211F6@lemburg.com> "Fred L. Drake, Jr." wrote: > > Greg Ward writes: > > I just noticed that sys.platform in 1.6a2 (and the latest CVS from this > > morning) returns "linux2" on my PC, not "linux-i386". As I recall this > > I didn't know it ever returned linux-i386; perhaps you're thinking > of Marc-Andre's platform module? Python has returned 'linux2' on my machine ever since I moved to a 2.x kernel -- why should it return 'linux-i386' (without any indication of version) ? As Fred mentioned, you should probably use platform.py to access the information you have in mind. It supports loads of different architectures and has pretty much all the information you need for distutils warpped in nice APIs. Why not simply include it in distutils ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From effbot at telia.com Fri Jun 30 12:04:00 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 30 Jun 2000 12:04:00 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Tools/perfecthash GenUCNHash.py,1.1,1.2 References: <200006300953.CAA14782@slayer.i.sourceforge.net> Message-ID: <00b001bfe27a$845f7880$f2a6b5d4@hagrid> MAL wrote: > out.write(header) > out = open(cFileName, "w") > ! out.write("#include "%s"\n" % headerFileName) > out.write(code) > perfHash.generate_graph(out) umm. I suppose you meant: > ! out.write('#include "%s"\n' % headerFileName) or possibly: > ! out.write("#include \"%s\"\n" % headerFileName) From mal at lemburg.com Fri Jun 30 12:15:23 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 30 Jun 2000 12:15:23 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Tools/perfecthash GenUCNHash.py,1.1,1.2 References: <200006300953.CAA14782@slayer.i.sourceforge.net> <00b001bfe27a$845f7880$f2a6b5d4@hagrid> Message-ID: <395C733B.4E2AFFA3@lemburg.com> Fredrik Lundh wrote: > > MAL wrote: > > out.write(header) > > out = open(cFileName, "w") > > ! out.write("#include "%s"\n" % headerFileName) > > out.write(code) > > perfHash.generate_graph(out) > > umm. I suppose you meant: > > > ! out.write('#include "%s"\n' % headerFileName) > > or possibly: > > > ! out.write("#include \"%s\"\n" % headerFileName) Oops, you're right. Thanks. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From fdrake at beopen.com Fri Jun 30 15:20:23 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 30 Jun 2000 09:20:23 -0400 (EDT) Subject: [Python-Dev] Wikis for todo lists, etc (was PyString_GET_SIZE()) In-Reply-To: References: Message-ID: <14684.40599.135974.497497@cj42289-a.reston1.va.home.com> Tim Peters writes: > productivity. Notes is the purest example of a whole being greater than the > sum of its parts I've ever seen (lousy mail system, lousy database, lousy > change manager, lousy bug tracker, lousy workflow manager, worse than lousy > native scripting ... but they all sucked in ways that were downright > synergistic <0.9 wink>). I had to use Notes before working at CNRI, and wouldn't have described all those sucky components as "synergistic". ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Fri Jun 30 15:26:15 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 30 Jun 2000 09:26:15 -0400 (EDT) Subject: [Python-Dev] New PythonLabs site revealed! In-Reply-To: References: <200006292338.BAA07798@python.inrialpes.fr> Message-ID: <14684.40951.644965.274278@cj42289-a.reston1.va.home.com> Ka-Ping Yee writes: > Will many be spooked by the jump in version number into fearing > incompatibility with older scripts...? > > I wonder if we'll end up trying to persuade the user community that > the changes are small ("no, don't worry, your scripts will still > work") and yet big ("honest, it really deserves to be called 2.0, > it's not just a ploy") at the same time. Ping, Haven't we heard our users complain about the conservative version numbering a lot? Pushing to 2.0 allows us to make the next release 2.1, which neither the "never 1.x!" crowd nor the "never x.0!" will worry about. Sounds like a good move to me! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Fri Jun 30 15:28:15 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 30 Jun 2000 09:28:15 -0400 (EDT) Subject: [Python-Dev] New PythonLabs site revealed! In-Reply-To: <005801bfe270$e140d440$f2a6b5d4@hagrid> References: <005801bfe270$e140d440$f2a6b5d4@hagrid> Message-ID: <14684.41071.958061.743836@cj42289-a.reston1.va.home.com> Fredrik Lundh writes: > btw, now that we're bumping to 2.0, maybe we can break > socket.connect and friends once again? if somebody com- > plains, just tell them "it's a major release, dammit" ;-) If by "break" you mean "tightly conform to the documentation", I'm all for it! ;) -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Fri Jun 30 15:32:24 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 30 Jun 2000 09:32:24 -0400 (EDT) Subject: [Python-Dev] Hey! who changed sys.platform?! In-Reply-To: <395C681D.C3211F6@lemburg.com> References: <20000629233003.A1766@beelzebub> <14684.5401.518766.362678@cj42289-a.reston1.va.home.com> <395C681D.C3211F6@lemburg.com> Message-ID: <14684.41320.38954.833643@cj42289-a.reston1.va.home.com> Regarding platform.py: M.-A. Lemburg writes: > Why not simply include it in distutils ? Why not include it in the standard library? Guido? I'll document it if Marc-Andre is willing to provide the module and the regression test. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From mal at lemburg.com Fri Jun 30 15:40:36 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 30 Jun 2000 15:40:36 +0200 Subject: [Python-Dev] Hey! who changed sys.platform?! References: <20000629233003.A1766@beelzebub> <14684.5401.518766.362678@cj42289-a.reston1.va.home.com> <395C681D.C3211F6@lemburg.com> <14684.41320.38954.833643@cj42289-a.reston1.va.home.com> Message-ID: <395CA354.16AC5B7E@lemburg.com> "Fred L. Drake, Jr." wrote: > > Regarding platform.py: > > M.-A. Lemburg writes: > > Why not simply include it in distutils ? > > Why not include it in the standard library? > Guido? I'll document it if Marc-Andre is willing to provide the > module and the regression test. No objection from here. I've attached my most recent copy to this mail. I'm not sure how to write the regr. test though since output is dependent on the platform running the functions... perhaps I'll just add something like the audio thingie: "This string ought to identify the platform you are currently running... if not, then something is wrong ;-)". -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From bwarsaw at beopen.com Fri Jun 30 15:42:19 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Fri, 30 Jun 2000 09:42:19 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules gcmodule.c,NONE,2.1 Setup.thread.in,2.2,2.3 cPickle.c,2.43,2.44 newmodule.c,2.20,2.21 References: <200006300502.WAA03262@slayer.i.sourceforge.net> Message-ID: <14684.41915.59835.325026@anthem.concentric.net> So, Setup.thread.in isn't used just for threads anymore. Perhaps it should be renamed? At the very least, a comment should be added to the top that this file is for configure enabled modules. -Barry Index: Setup.thread.in =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/Setup.thread.in,v retrieving revision 2.2 retrieving revision 2.3 diff -C2 -r2.2 -r2.3 *** Setup.thread.in 2000/06/29 16:08:28 2.2 --- Setup.thread.in 2000/06/30 05:02:53 2.3 *************** *** 11,12 **** --- 11,15 ---- @USE_THREAD_MODULE at thread threadmodule.c + + # Garbage collection enabled with --with-cycle-gc + @USE_GC_MODULE at gc gcmodule.c From mal at lemburg.com Fri Jun 30 15:42:06 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 30 Jun 2000 15:42:06 +0200 Subject: [Python-Dev] Hey! who changed sys.platform?! References: <20000629233003.A1766@beelzebub> <14684.5401.518766.362678@cj42289-a.reston1.va.home.com> <395C681D.C3211F6@lemburg.com> <14684.41320.38954.833643@cj42289-a.reston1.va.home.com> <395CA354.16AC5B7E@lemburg.com> Message-ID: <395CA3AE.8A5800F1@lemburg.com> Ooops, forgot the attachement... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ -------------- next part -------------- A non-text attachment was scrubbed... Name: platform.py Type: text/python Size: 36884 bytes Desc: not available URL: From guido at python.org Fri Jun 30 16:47:29 2000 From: guido at python.org (Guido van Rossum) Date: Fri, 30 Jun 2000 09:47:29 -0500 Subject: [Python-Dev] Removing modules In-Reply-To: Your message of "Thu, 29 Jun 2000 21:29:41 -0400." <20000629212941.A21563@newcnri.cnri.reston.va.us> References: <20000629212941.A21563@newcnri.cnri.reston.va.us> Message-ID: <200006301447.JAA30671@cj20424-a.reston1.va.home.com> > For the "deleted modules" section of the 2.0 article, I drew up a list > of modules that might be outdated, mostly the SGI-specific ones. Are > those modules still useful, and do the libraries they were written for > still exist? Doubtful. I've asked Sjoerd and Jack, who were most involved in using these. > For your cogitation, here's the list: sgimodule.c, glmodule.c (and > hence cgenmodule.c), imgfile.c, svmodule.c, flmodule.c, fmmodule.c, > almodule.c, clmodule.c, knee.py. I'd like to keep knee.py -- it's a nice piece of *documentation* of the package import. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Fri Jun 30 16:55:08 2000 From: guido at python.org (Guido van Rossum) Date: Fri, 30 Jun 2000 09:55:08 -0500 Subject: [Python-Dev] Hey! who changed sys.platform?! In-Reply-To: Your message of "Fri, 30 Jun 2000 15:40:36 +0200." <395CA354.16AC5B7E@lemburg.com> References: <20000629233003.A1766@beelzebub> <14684.5401.518766.362678@cj42289-a.reston1.va.home.com> <395C681D.C3211F6@lemburg.com> <14684.41320.38954.833643@cj42289-a.reston1.va.home.com> <395CA354.16AC5B7E@lemburg.com> Message-ID: <200006301455.JAA30721@cj20424-a.reston1.va.home.com> > > Regarding platform.py: > > > > M.-A. Lemburg writes: > > > Why not simply include it in distutils ? > > > > Why not include it in the standard library? > > Guido? I'll document it if Marc-Andre is willing to provide the > > module and the regression test. > > No objection from here. > > I've attached my most recent copy to this mail. I'm not sure > how to write the regr. test though since output is dependent > on the platform running the functions... perhaps I'll just > add something like the audio thingie: "This string ought > to identify the platform you are currently running... if not, > then something is wrong ;-)". You didn't include it! But I vote -1 on this one anyway -- it's too much code and almost by its very nature not something that belongs in a "standard" library. Plus, I don't want to be responsible for maintaining it. Sorry, --Guido van Rossum (home page: http://www.python.org/~guido/) From bwarsaw at beopen.com Fri Jun 30 15:57:47 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Fri, 30 Jun 2000 09:57:47 -0400 (EDT) Subject: [Python-Dev] New PythonLabs site revealed! References: <005801bfe270$e140d440$f2a6b5d4@hagrid> Message-ID: <14684.42843.472230.609828@anthem.concentric.net> >>>>> "FL" == Fredrik Lundh writes: FL> btw, now that we're bumping to 2.0, maybe we can break FL> socket.connect and friends once again? if somebody com- FL> plains, just tell them "it's a major release, dammit" ;-) That's a good point. A bump in major rev number is an /opportunity/ to break things, like a bone that hasn't healed right, so that they can be fixed correctly. We'll lose that for 2.0, mostly likely because of the tight release schedule. There's always 3.0 though, which will mesh nicely with the mythical Py3k. -Barry From effbot at telia.com Fri Jun 30 16:08:13 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 30 Jun 2000 16:08:13 +0200 Subject: [Python-Dev] New PythonLabs site revealed! References: <005801bfe270$e140d440$f2a6b5d4@hagrid> <14684.42843.472230.609828@anthem.concentric.net> Message-ID: <016e01bfe29c$a2e8bb00$f2a6b5d4@hagrid> barry wrote: > >>>>> "FL" == Fredrik Lundh writes: > > FL> btw, now that we're bumping to 2.0, maybe we can break > FL> socket.connect and friends once again? if somebody com- > FL> plains, just tell them "it's a major release, dammit" ;-) > > That's a good point. A bump in major rev number is an /opportunity/ > to break things, like a bone that hasn't healed right, so that they > can be fixed correctly. We'll lose that for 2.0, mostly likely > because of the tight release schedule. yeah, but I'm sure Guido has the patches somewhere (after all, the 1.6 release notes still mention this change). if not, the mad patcher volunteers to fix (or rather, break) this. Guido? From bwarsaw at beopen.com Fri Jun 30 16:07:47 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Fri, 30 Jun 2000 10:07:47 -0400 (EDT) Subject: [Python-Dev] RE: [Python-checkins] CVS: python/dist/src/PCbuild readme.txt,1.5,1.6 References: Message-ID: <14684.43443.919858.897738@anthem.concentric.net> >>>>> "MH" == Mark Hammond writes: MH> [I wishing mailing-lists would agree on how they handle MH> reply-to :-] It's fundamentally broken, but the problem is in the mail readers (MUA). There's no header (that I'm aware of) that portably tells an MUA - "Hey, for a group follow up, don't go to the original list, go to THIS one instead, but for an individual followup (i.e. reply) still address that to the original author." This is one reason why munging reply-to is evil. But in this case we've agreed that following up to python-dev is more important than preserving the ability to reply to the author. -Barry From mal at lemburg.com Fri Jun 30 16:11:54 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 30 Jun 2000 16:11:54 +0200 Subject: [Python-Dev] Hey! who changed sys.platform?! References: <20000629233003.A1766@beelzebub> <14684.5401.518766.362678@cj42289-a.reston1.va.home.com> <395C681D.C3211F6@lemburg.com> <14684.41320.38954.833643@cj42289-a.reston1.va.home.com> <395CA354.16AC5B7E@lemburg.com> <200006301455.JAA30721@cj20424-a.reston1.va.home.com> Message-ID: <395CAAAA.5975A617@lemburg.com> Guido van Rossum wrote: > > > > Regarding platform.py: > > > > > > M.-A. Lemburg writes: > > > > Why not simply include it in distutils ? > > > > > > Why not include it in the standard library? > > > Guido? I'll document it if Marc-Andre is willing to provide the > > > module and the regression test. > > > > No objection from here. > > > > I've attached my most recent copy to this mail. I'm not sure > > how to write the regr. test though since output is dependent > > on the platform running the functions... perhaps I'll just > > add something like the audio thingie: "This string ought > > to identify the platform you are currently running... if not, > > then something is wrong ;-)". > > You didn't include it! I posted a reply to fix this ;-) > But I vote -1 on this one anyway -- it's too much code and almost by > its very nature not something that belongs in a "standard" library. > Plus, I don't want to be responsible for maintaining it. Sorry, You don't have to maintain it... I will anyway since it's part of mxCGIPython. Anyway, perhaps Greg Ward can find some use for it in distutils. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From effbot at telia.com Fri Jun 30 16:18:13 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 30 Jun 2000 16:18:13 +0200 Subject: [Python-Dev] SRE incompatibility Message-ID: <018401bfe29e$07f26720$f2a6b5d4@hagrid> my latest changes fixed a couple of things, but broke one of the old RE tests, namely: re.match('\\x00ffffffffffffff', '\377') != None or in other words, long hexadecimal escapes are cast down to 8-bit characters in RE. in SRE (after the latest change), they're cast down to the size of the engine's internal word size (currently 16 bits). is the old behaviour worth keeping? I'd rather not make the engine dependent on string types; it shouldn't really matter if you're using unicode patterns on 8-bit target strings, or vice versa. From gward at mems-exchange.org Fri Jun 30 16:13:40 2000 From: gward at mems-exchange.org (Greg Ward) Date: Fri, 30 Jun 2000 10:13:40 -0400 Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils msvccompiler.py,1.33,1.34 In-Reply-To: <14683.56294.836295.923883@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Thu, Jun 29, 2000 at 07:29:42PM -0400 References: <200006292305.QAA11929@slayer.i.sourceforge.net> <200006300020.TAA21877@cj20424-a.reston1.va.home.com> <14683.56294.836295.923883@cj42289-a.reston1.va.home.com> Message-ID: <20000630101340.A16350@ludwig.cnri.reston.va.us> On 29 June 2000, Fred L. Drake, Jr. said: > > Greg Ward wrote in a checkin message: > > On second thought, first try for _winreg, and then winreg. Only if both > > fail do we try for win32api/win32con. If *those* both fail, then we don't > > have registry access. Phew! > > Guido van Rossum writes on python-dev: > > Is this smart? Doesn't the new winreg have a very different I/F than > > the old one? > > No, this is bad. It *will* break with winreg; if _winreg isn't > available, it should use the win32api/win32con/whatever stuff; it's a > Python 1.5.2 interpreter at that point. What if it's a 1.6a1 or 1.6a2 interpreter? Presumably people will try Distutils 0.9 with them. Should I remove that feature now that 0.9 is out, but before Python 2.0b1? Greg -- Greg Ward - software developer gward at mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From esr at thyrsus.com Fri Jun 30 16:27:07 2000 From: esr at thyrsus.com (Eric S. Raymond) Date: Fri, 30 Jun 2000 10:27:07 -0400 Subject: [Python-Dev] Removing modules In-Reply-To: <200006301447.JAA30671@cj20424-a.reston1.va.home.com>; from guido@python.org on Fri, Jun 30, 2000 at 09:47:29AM -0500 References: <20000629212941.A21563@newcnri.cnri.reston.va.us> <200006301447.JAA30671@cj20424-a.reston1.va.home.com> Message-ID: <20000630102707.A27830@thyrsus.com> Guido van Rossum : > > For the "deleted modules" section of the 2.0 article, I drew up a list > > of modules that might be outdated, mostly the SGI-specific ones. Are > > those modules still useful, and do the libraries they were written for > > still exist? > > Doubtful. I've asked Sjoerd and Jack, who were most involved in using > these. > > > For your cogitation, here's the list: sgimodule.c, glmodule.c (and > > hence cgenmodule.c), imgfile.c, svmodule.c, flmodule.c, fmmodule.c, > > almodule.c, clmodule.c, knee.py. > > I'd like to keep knee.py -- it's a nice piece of *documentation* of > the package import. +1 on giving the SGI-specific modules the heave-ho. Their presence has always struck me as a sort of vermiform appendix in a core library otherwise clearly aimed at being as platform-independent as rdeasonably possible (e.g. given the Unix-vs.Windows differences). -- Eric S. Raymond Power concedes nothing without a demand. It never did, and it never will. Find out just what people will submit to, and you have found out the exact amount of injustice and wrong which will be imposed upon them; and these will continue until they are resisted with either words or blows, or with both. The limits of tyrants are prescribed by the endurance of those whom they oppress. -- Frederick Douglass, August 4, 1857 From gward at mems-exchange.org Fri Jun 30 16:22:42 2000 From: gward at mems-exchange.org (Greg Ward) Date: Fri, 30 Jun 2000 10:22:42 -0400 Subject: [Python-Dev] Hey! who changed sys.platform?! In-Reply-To: <395CAAAA.5975A617@lemburg.com>; from mal@lemburg.com on Fri, Jun 30, 2000 at 04:11:54PM +0200 References: <20000629233003.A1766@beelzebub> <14684.5401.518766.362678@cj42289-a.reston1.va.home.com> <395C681D.C3211F6@lemburg.com> <14684.41320.38954.833643@cj42289-a.reston1.va.home.com> <395CA354.16AC5B7E@lemburg.com> <200006301455.JAA30721@cj20424-a.reston1.va.home.com> <395CAAAA.5975A617@lemburg.com> Message-ID: <20000630102242.B16350@ludwig.cnri.reston.va.us> On 30 June 2000, M.-A. Lemburg said: > > But I vote -1 on this one anyway -- it's too much code and almost by > > its very nature not something that belongs in a "standard" library. > > Plus, I don't want to be responsible for maintaining it. Sorry, > > You don't have to maintain it... I will anyway since it's part > of mxCGIPython. > > Anyway, perhaps Greg Ward can find some use for it in > distutils. I looked at platform.py once briefly, and my impression was similar to Guido's: too big! All I want(ed) is "osname-cpu" -- linux-i386, solaris-sparc, whatever. osversion is optional. But, consider that that the Distutils might want to know if it should generate RPMs or Debian packages... then the stuff about grokking which Linux distribution it's running on is relevant. Argh! Anyways, I'm already taking static about too much code in the Distutils, and I partly agree. (I agree there's a *lot* of code, I know there are bits that can be refactored and reduced, but I'm not sure it's too much.) So I'll stick with sys.platform for now -- it's good enough. Greg -- Greg Ward - software developer gward at mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367 From sjoerd at oratrix.nl Fri Jun 30 16:21:53 2000 From: sjoerd at oratrix.nl (Sjoerd Mullender) Date: Fri, 30 Jun 2000 16:21:53 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Objects unicodeobject.c,2.31,2.32 In-Reply-To: Your message of Fri, 30 Jun 2000 03:29:59 -0700. <200006301029.DAA25494@slayer.i.sourceforge.net> References: <200006301029.DAA25494@slayer.i.sourceforge.net> Message-ID: <20000630142154.968F831047C@bireme.oratrix.nl> Why was the change that occurred in revision 2.31 reverted? Accident? The change log said: Jack Jansen: Use include "" instead of <>; and staticforward declarations On Fri, Jun 30 2000 "M.-A. Lemburg" wrote: > Update of /cvsroot/python/python/dist/src/Objects > In directory slayer.i.sourceforge.net:/tmp/cvs-serv25442/Objects > > Modified Files: > unicodeobject.c > Log Message: > Marc-Andre Lemburg : > New buffer overflow checks for formatting strings. > > By Trent Mick. > > Index: unicodeobject.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v > retrieving revision 2.31 > retrieving revision 2.32 > diff -C2 -r2.31 -r2.32 > *** unicodeobject.c 2000/06/29 00:06:39 2.31 > --- unicodeobject.c 2000/06/30 10:29:57 2.32 > *************** > *** 67,71 **** > #include "mymath.h" > #include "unicodeobject.h" > ! #include "ucnhash.h" > > #if defined(HAVE_LIMITS_H) > --- 67,71 ---- > #include "mymath.h" > #include "unicodeobject.h" > ! #include > > #if defined(HAVE_LIMITS_H) > *************** > *** 1245,1249 **** > ucnFallthrough: > /* fall through on purpose */ > ! default: > *p++ = '\\'; > *p++ = (unsigned char)s[-1]; > --- 1245,1249 ---- > ucnFallthrough: > /* fall through on purpose */ > ! default: > *p++ = '\\'; > *p++ = (unsigned char)s[-1]; > *************** > *** 1252,1256 **** > } > if (_PyUnicode_Resize(v, (int)(p - buf))) > ! goto onError; > return (PyObject *)v; > > --- 1252,1256 ---- > } > if (_PyUnicode_Resize(v, (int)(p - buf))) > ! goto onError; > return (PyObject *)v; > > *************** > *** 4374,4377 **** > --- 4374,4378 ---- > static int > formatfloat(Py_UNICODE *buf, > + size_t buflen, > int flags, > int prec, > *************** > *** 4379,4382 **** > --- 4380,4385 ---- > PyObject *v) > { > + /* fmt = '%#.' + `prec` + `type` > + worst case length = 3 + 10 (len of INT_MAX) + 1 = 14 (use 20)*/ > char fmt[20]; > double x; > *************** > *** 4387,4395 **** > if (prec < 0) > prec = 6; > - if (prec > 50) > - prec = 50; /* Arbitrary limitation */ > if (type == 'f' && (fabs(x) / 1e25) >= 1e25) > type = 'g'; > sprintf(fmt, "%%%s.%d%c", (flags & F_ALT) ? "#" : "", prec, type); > return usprintf(buf, fmt, x); > } > --- 4390,4408 ---- > if (prec < 0) > prec = 6; > if (type == 'f' && (fabs(x) / 1e25) >= 1e25) > type = 'g'; > sprintf(fmt, "%%%s.%d%c", (flags & F_ALT) ? "#" : "", prec, type); > + /* worst case length calc to ensure no buffer overrun: > + fmt = %#.g > + buf = '-' + [0-9]*prec + '.' + 'e+' + (longest exp > + for any double rep.) > + len = 1 + prec + 1 + 2 + 5 = 9 + prec > + If prec=0 the effective precision is 1 (the leading digit is > + always given), therefore increase by one to 10+prec. */ > + if (buflen <= (size_t)10 + (size_t)prec) { > + PyErr_SetString(PyExc_OverflowError, > + "formatted float is too long (precision too long?)"); > + return -1; > + } > return usprintf(buf, fmt, x); > } > *************** > *** 4397,4400 **** > --- 4410,4414 ---- > static int > formatint(Py_UNICODE *buf, > + size_t buflen, > int flags, > int prec, > *************** > *** 4402,4405 **** > --- 4416,4421 ---- > PyObject *v) > { > + /* fmt = '%#.' + `prec` + 'l' + `type` > + worst case length = 3 + 10 (len of INT_MAX) + 1 + 1 = 15 (use 20)*/ > char fmt[20]; > long x; > *************** > *** 4410,4413 **** > --- 4426,4436 ---- > if (prec < 0) > prec = 1; > + /* buf = '+'/'-'/'0'/'0x' + '[0-9]'*max(prec,len(x in octal)) > + worst case buf = '0x' + [0-9]*prec, where prec >= 11 */ > + if (buflen <= 13 || buflen <= (size_t)2+(size_t)prec) { > + PyErr_SetString(PyExc_OverflowError, > + "formatted integer is too long (precision too long?)"); > + return -1; > + } > sprintf(fmt, "%%%s.%dl%c", (flags & F_ALT) ? "#" : "", prec, type); > return usprintf(buf, fmt, x); > *************** > *** 4416,4421 **** > static int > formatchar(Py_UNICODE *buf, > ! PyObject *v) > { > if (PyUnicode_Check(v)) { > if (PyUnicode_GET_SIZE(v) != 1) > --- 4439,4446 ---- > static int > formatchar(Py_UNICODE *buf, > ! size_t buflen, > ! PyObject *v) > { > + /* presume that the buffer is at least 2 characters long */ > if (PyUnicode_Check(v)) { > if (PyUnicode_GET_SIZE(v) != 1) > *************** > *** 4447,4450 **** > --- 4472,4485 ---- > } > > + /* fmt%(v1,v2,...) is roughly equivalent to sprintf(fmt, v1, v2, ...) > + > + FORMATBUFLEN is the length of the buffer in which the floats, ints, & > + chars are formatted. XXX This is a magic number. Each formatting > + routine does bounds checking to ensure no overflow, but a better > + solution may be to malloc a buffer of appropriate size for each > + format. For now, the current solution is sufficient. > + */ > + #define FORMATBUFLEN (size_t)120 > + > PyObject *PyUnicode_Format(PyObject *format, > PyObject *args) > *************** > *** 4506,4513 **** > PyObject *v = NULL; > PyObject *temp = NULL; > ! Py_UNICODE *buf; > Py_UNICODE sign; > int len; > ! Py_UNICODE tmpbuf[120]; /* For format{float,int,char}() */ > > fmt++; > --- 4541,4548 ---- > PyObject *v = NULL; > PyObject *temp = NULL; > ! Py_UNICODE *pbuf; > Py_UNICODE sign; > int len; > ! Py_UNICODE formatbuf[FORMATBUFLEN]; /* For format{float,int,char}() */ > > fmt++; > *************** > *** 4659,4664 **** > > case '%': > ! buf = tmpbuf; > ! buf[0] = '%'; > len = 1; > break; > --- 4694,4700 ---- > > case '%': > ! pbuf = formatbuf; > ! /* presume that buffer length is at least 1 */ > ! pbuf[0] = '%'; > len = 1; > break; > *************** > *** 4696,4700 **** > goto onError; > } > ! buf = PyUnicode_AS_UNICODE(temp); > len = PyUnicode_GET_SIZE(temp); > if (prec >= 0 && len > prec) > --- 4732,4736 ---- > goto onError; > } > ! pbuf = PyUnicode_AS_UNICODE(temp); > len = PyUnicode_GET_SIZE(temp); > if (prec >= 0 && len > prec) > *************** > *** 4710,4715 **** > if (c == 'i') > c = 'd'; > ! buf = tmpbuf; > ! len = formatint(buf, flags, prec, c, v); > if (len < 0) > goto onError; > --- 4746,4752 ---- > if (c == 'i') > c = 'd'; > ! pbuf = formatbuf; > ! len = formatint(pbuf, sizeof(formatbuf)/sizeof(Py_UNICODE), > ! flags, prec, c, v); > if (len < 0) > goto onError; > *************** > *** 4719,4725 **** > if ((flags&F_ALT) && > (c == 'x' || c == 'X') && > ! buf[0] == '0' && buf[1] == c) { > ! *res++ = *buf++; > ! *res++ = *buf++; > rescnt -= 2; > len -= 2; > --- 4756,4762 ---- > if ((flags&F_ALT) && > (c == 'x' || c == 'X') && > ! pbuf[0] == '0' && pbuf[1] == c) { > ! *res++ = *pbuf++; > ! *res++ = *pbuf++; > rescnt -= 2; > len -= 2; > *************** > *** 4736,4741 **** > case 'g': > case 'G': > ! buf = tmpbuf; > ! len = formatfloat(buf, flags, prec, c, v); > if (len < 0) > goto onError; > --- 4773,4779 ---- > case 'g': > case 'G': > ! pbuf = formatbuf; > ! len = formatfloat(pbuf, sizeof(formatbuf)/sizeof(Py_UNICODE), > ! flags, prec, c, v); > if (len < 0) > goto onError; > *************** > *** 4746,4751 **** > > case 'c': > ! buf = tmpbuf; > ! len = formatchar(buf, v); > if (len < 0) > goto onError; > --- 4784,4789 ---- > > case 'c': > ! pbuf = formatbuf; > ! len = formatchar(pbuf, sizeof(formatbuf)/sizeof(Py_UNICODE), v); > if (len < 0) > goto onError; > *************** > *** 4759,4764 **** > } > if (sign) { > ! if (*buf == '-' || *buf == '+') { > ! sign = *buf++; > len--; > } > --- 4797,4802 ---- > } > if (sign) { > ! if (*pbuf == '-' || *pbuf == '+') { > ! sign = *pbuf++; len--; > } > *************** > *** 4796,4800 **** > if (sign && fill == ' ') > *res++ = sign; > ! memcpy(res, buf, len * sizeof(Py_UNICODE)); > res += len; > rescnt -= len; > --- 4834,4838 ---- > if (sign && fill == ' ') > *res++ = sign; > ! memcpy(res, pbuf, len * sizeof(Py_UNICODE)); > res += len; > rescnt -= len; > > -- Sjoerd Mullender From akuchlin at mems-exchange.org Fri Jun 30 16:29:00 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Fri, 30 Jun 2000 10:29:00 -0400 Subject: [Python-Dev] SRE incompatibility In-Reply-To: <018401bfe29e$07f26720$f2a6b5d4@hagrid>; from effbot@telia.com on Fri, Jun 30, 2000 at 04:18:13PM +0200 References: <018401bfe29e$07f26720$f2a6b5d4@hagrid> Message-ID: <20000630102900.A19597@kronos.cnri.reston.va.us> On Fri, Jun 30, 2000 at 04:18:13PM +0200, Fredrik Lundh wrote: > re.match('\\x00ffffffffffffff', '\377') != None >or in other words, long hexadecimal escapes are cast >down to 8-bit characters in RE. This is for compatibility with Python string literals: kronos Python-1.6>./python >>> '\x00fffffff' '\377' >>> u'\x00fffffff' u'\uFFFF' (Where do these semantics come from, BTW? C's \x seems to take any number of hex digits but then reports an error if the character is greater than 256, too large to fit into a byte.) Note that the \u escape for Unicode characters uses exactly 4 digits, no more, no less. It would certainly be simpler and clearer to only support a fixed number of digits with \x, since I find the casting down behaviour is magical and not obvious. But I don't know if we want to make that change now. (Guido now realizes the downside to numbering it 2.0, as everyone hurries to suggest their favorite backward-incompatible change.) That doesn't help with regexes, of course, since a pattern might be written as a regular string but be intended to match Unicode. Maybe the simplest rule is the best; always take 4 digits, even if it winds up being incompatible with the \x in string literals. --amk From fdrake at beopen.com Fri Jun 30 16:33:47 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 30 Jun 2000 10:33:47 -0400 (EDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: distutils/distutils msvccompiler.py,1.33,1.34 In-Reply-To: <20000630101340.A16350@ludwig.cnri.reston.va.us> References: <200006292305.QAA11929@slayer.i.sourceforge.net> <200006300020.TAA21877@cj20424-a.reston1.va.home.com> <14683.56294.836295.923883@cj42289-a.reston1.va.home.com> <20000630101340.A16350@ludwig.cnri.reston.va.us> Message-ID: <14684.45003.193701.382599@cj42289-a.reston1.va.home.com> Greg Ward writes: > What if it's a 1.6a1 or 1.6a2 interpreter? Presumably people will try > Distutils 0.9 with them. Should I remove that feature now that 0.9 is > out, but before Python 2.0b1? You're placing too much value on code labelled "alpha". ;) There are two interesting versions -- 1.5.2 (since you scrapped support for versions before that), and 2.0. And the CVS version is the closest approximation to 2.0 that anyone has. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From fdrake at beopen.com Fri Jun 30 16:38:51 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 30 Jun 2000 10:38:51 -0400 (EDT) Subject: [Python-Dev] Hey! who changed sys.platform?! In-Reply-To: <20000630102242.B16350@ludwig.cnri.reston.va.us> References: <20000629233003.A1766@beelzebub> <14684.5401.518766.362678@cj42289-a.reston1.va.home.com> <395C681D.C3211F6@lemburg.com> <14684.41320.38954.833643@cj42289-a.reston1.va.home.com> <395CA354.16AC5B7E@lemburg.com> <200006301455.JAA30721@cj20424-a.reston1.va.home.com> <395CAAAA.5975A617@lemburg.com> <20000630102242.B16350@ludwig.cnri.reston.va.us> Message-ID: <14684.45307.983394.125671@cj42289-a.reston1.va.home.com> Greg Ward writes: > But, consider that that the Distutils might want to know if it should > generate RPMs or Debian packages... then the stuff about grokking which > Linux distribution it's running on is relevant. Argh! Why would you need to figure this out? Are you selecting a platform-specific packaging system automatically? In that case, I'd search for the presence of the tools rather than asking what sort of distribution you're running on -- several distros use RPM, a few use .deb packages, etc. When the user specifies one on the command line, just use the one they name and be done with it. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From mal at lemburg.com Fri Jun 30 16:53:31 2000 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 30 Jun 2000 16:53:31 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Objects unicodeobject.c,2.31,2.32 References: <200006301029.DAA25494@slayer.i.sourceforge.net> <20000630142154.968F831047C@bireme.oratrix.nl> Message-ID: <395CB46B.34053D3E@lemburg.com> > Why was the change that occurred in revision 2.31 reverted? Accident? > > The change log said: > Jack Jansen: Use include "" instead of <>; and staticforward declarations Accident... I'll revert that change. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido at python.org Fri Jun 30 18:07:16 2000 From: guido at python.org (Guido van Rossum) Date: Fri, 30 Jun 2000 11:07:16 -0500 Subject: [Python-Dev] SRE incompatibility In-Reply-To: Your message of "Fri, 30 Jun 2000 16:18:13 +0200." <018401bfe29e$07f26720$f2a6b5d4@hagrid> References: <018401bfe29e$07f26720$f2a6b5d4@hagrid> Message-ID: <200006301607.LAA10829@cj20424-a.reston1.va.home.com> > my latest changes fixed a couple of things, but broke > one of the old RE tests, namely: > > re.match('\\x00ffffffffffffff', '\377') != None > > or in other words, long hexadecimal escapes are cast > down to 8-bit characters in RE. > > in SRE (after the latest change), they're cast down to > the size of the engine's internal word size (currently 16 > bits). > > is the old behaviour worth keeping? I'd rather not make > the engine dependent on string types; it shouldn't really > matter if you're using unicode patterns on 8-bit target > strings, or vice versa. To someone familiar with '\x00ffffffffffffff' == '\377', the failure is surprising. What Would Larry Do? (I.e. is this in Perl?) Maybe make it dependent on the type of the searched string ('\377') rather than on the type of the pattern? --Guido van Rossum (home page: http://www.python.org/~guido/) From skip at mojam.com Fri Jun 30 15:54:49 2000 From: skip at mojam.com (Skip Montanaro) Date: Fri, 30 Jun 2000 08:54:49 -0500 (CDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test README,NONE,1.1 In-Reply-To: <20000629232733.D24811@activestate.com> References: <200006300608.XAA13124@slayer.i.sourceforge.net> <20000629232733.D24811@activestate.com> Message-ID: <14684.42665.221905.911205@beluga.mojam.com> Trent> Cool Thanks. >> To run the entire test suite, make the "test" target at the top level: >> >> cd ... >> make test Trent> This is a UN*Xism, on Windows and UN*X: Trent> cd ...\Lib\test Trent> python regrtest.py Thanks, I'll check into it. I'm a Unix weenie so am (blissfully) unaware of how Windows weenies do these things... ;-) Trent> A sample walk through to create a test might make it more Trent> approachable for people. As well, it would be helpful to mention Trent> test_support.{verbose|TESTFN|...}. But I have no right to bitch Trent> about good work. I'll check into that as well. The README file was created in about 30 minutes and was a good excuse to test my checkin capabilities on something that wouldn't break anything. ;-) Skip From mhammond at skippinet.com.au Fri Jun 30 17:48:43 2000 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sat, 1 Jul 2000 01:48:43 +1000 Subject: [Python-Dev] Checked in new PC\config.h Message-ID: Hi all, I noticed that PC\config.h still had a reference to "Python16.lib". I simply checked in a new version without submitting a patch or following any other process. I hope this was appropriate. Mark. From akuchlin at mems-exchange.org Fri Jun 30 18:03:48 2000 From: akuchlin at mems-exchange.org (Andrew Kuchling) Date: Fri, 30 Jun 2000 12:03:48 -0400 Subject: [Python-Dev] SRE incompatibility In-Reply-To: <200006301607.LAA10829@cj20424-a.reston1.va.home.com>; from guido@python.org on Fri, Jun 30, 2000 at 11:07:16AM -0500 References: <018401bfe29e$07f26720$f2a6b5d4@hagrid> <200006301607.LAA10829@cj20424-a.reston1.va.home.com> Message-ID: <20000630120348.C19597@kronos.cnri.reston.va.us> On Fri, Jun 30, 2000 at 11:07:16AM -0500, Guido van Rossum wrote: >To someone familiar with '\x00ffffffffffffff' == '\377', the failure >is surprising. What Would Larry Do? (I.e. is this in Perl?) It uses two digits: "\x00ffff" is the string "ffff". >Maybe make it dependent on the type of the searched string ('\377') >rather than on the type of the pattern? Won't work; you could just be compiling a pattern to make a regex object, and have no idea what you're matching against. --amk From jeremy at beopen.com Fri Jun 30 18:10:09 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 30 Jun 2000 12:10:09 -0400 (EDT) Subject: [Python-Dev] SRE incompatibility In-Reply-To: <018401bfe29e$07f26720$f2a6b5d4@hagrid> References: <018401bfe29e$07f26720$f2a6b5d4@hagrid> Message-ID: <14684.50785.245652.345591@bitdiddle.concentric.net> I don't know if this is related, exactly, but there is some kind of problem with the current test. When I run make test, I see: test test_sre crashed -- exceptions.SyntaxError : inconsistent use of tabs and spaces in indentation tabnanny thinks test_sre.py is fine, so I'm not sure what the problem is. Jeremy From tim_one at email.msn.com Fri Jun 30 18:18:03 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 30 Jun 2000 12:18:03 -0400 Subject: [Python-Dev] Checked in new PC\config.h In-Reply-To: Message-ID: [Mark Hammond] > I noticed that PC\config.h still had a reference to > "Python16.lib". I simply checked in a new version without > submitting a patch or following any other process. I hope > this was appropriate. IMO, if you're an expert in an area and need to make a change in that area that indeed needs to be made and isn't going to screw anybody (and because you're an expert in that area, you're not wrong in your judgment of that ), just do it! We'll see the diffs come by later. Guido, Barry, Jeremy, & Fred have been working that way a long time now. If they didn't want us to work that way too, they shouldn't have given us the ability to commit. empowering-the-masses-ly y'rs - tim From guido at python.org Fri Jun 30 19:18:10 2000 From: guido at python.org (Guido van Rossum) Date: Fri, 30 Jun 2000 12:18:10 -0500 Subject: [Python-Dev] SRE incompatibility In-Reply-To: Your message of "Fri, 30 Jun 2000 12:03:48 -0400." <20000630120348.C19597@kronos.cnri.reston.va.us> References: <018401bfe29e$07f26720$f2a6b5d4@hagrid> <200006301607.LAA10829@cj20424-a.reston1.va.home.com> <20000630120348.C19597@kronos.cnri.reston.va.us> Message-ID: <200006301718.MAA12448@cj20424-a.reston1.va.home.com> > On Fri, Jun 30, 2000 at 11:07:16AM -0500, Guido van Rossum wrote: > >To someone familiar with '\x00ffffffffffffff' == '\377', the failure > >is surprising. What Would Larry Do? (I.e. is this in Perl?) > > It uses two digits: "\x00ffff" is the string "ffff". > > >Maybe make it dependent on the type of the searched string ('\377') > >rather than on the type of the pattern? > > Won't work; you could just be compiling a pattern to make a regex > object, and have no idea what you're matching against. OK. Let's change our spec. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Fri Jun 30 19:26:51 2000 From: guido at python.org (Guido van Rossum) Date: Fri, 30 Jun 2000 12:26:51 -0500 Subject: [Python-Dev] Checked in new PC\config.h In-Reply-To: Your message of "Fri, 30 Jun 2000 12:18:03 -0400." References: Message-ID: <200006301726.MAA12560@cj20424-a.reston1.va.home.com> > IMO, if you're an expert in an area and need to make a change in that area > that indeed needs to be made and isn't going to screw anybody (and because > you're an expert in that area, you're not wrong in your judgment of that > ), just do it! We'll see the diffs come by later. Guido, Barry, > Jeremy, & Fred have been working that way a long time now. If they didn't > want us to work that way too, they shouldn't have given us the ability to > commit. Exactly! So far it's working like a charm! --Guido van Rossum (home page: http://www.python.org/~guido/) From tim_one at email.msn.com Fri Jun 30 18:38:21 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 30 Jun 2000 12:38:21 -0400 Subject: [Python-Dev] SRE incompatibility In-Reply-To: <20000630102900.A19597@kronos.cnri.reston.va.us> Message-ID: [Andrew Kuchling] > ... > This is for compatibility with Python string literals: > > kronos Python-1.6>./python > >>> '\x00fffffff' > '\377' > >>> u'\x00fffffff' > u'\uFFFF' > > (Where do these semantics come from, BTW? C's \x seems to take any > number of hex digits but then reports an error if the character is > greater than 256, too large to fit into a byte.) The behavior of \x in C is mostly implementation-defined. The committee knew that C had to do *something* to support "large characters" down the road, but in those early days they had no clear idea exactly what. So, rather than do something sensible <0.5 wink>, they invented a perfectly general mechanism without portable semantics. "C itself" isn't complaining if the character "is greater than 256", it's the specific implementation of C you're using that's complaining. A different implementation is free to (& probably will!) do something different. Guido adopted the most commonly implemented semantics (ignore all but the last byte) in Python, apparently under the delusion that this would be a Good Thing . Marc-Andre followed suit by generalizing this madness to Unicode. > Note that the \u escape for Unicode characters uses exactly 4 digits, > no more, no less. I pushed for that obnoxiously. Glad you appreciate it . Java does the same. > It would certainly be simpler and clearer to only support a fixed > number of digits with \x, since I find the casting down behaviour is > magical and not obvious. Yes, it's basically nuts. > But I don't know if we want to make that change now. No from me, because it may break stuff. Wait for Python 2.0 . > (Guido now realizes the downside to numbering it 2.0, as everyone > hurries to suggest their favorite backward-incompatible change.) Guido always realized that, I believe. It's a "least of evils" kind of thing, mixed with a celebration, not a pure win. > That doesn't help with regexes, of course, since a pattern might be > written as a regular string but be intended to match Unicode. Maybe > the simplest rule is the best; always take 4 digits, even if it winds > up being incompatible with the \x in string literals. I vote for backward compatibility for now, and not only because that will irritate /F the most. From bwarsaw at beopen.com Fri Jun 30 18:51:15 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Fri, 30 Jun 2000 12:51:15 -0400 (EDT) Subject: [Python-Dev] --with-cycle-gc switch Message-ID: <14684.53251.309942.13110@anthem.concentric.net> I don't like --with-cycle-gc as the configure switch, and unfortunately configure is explicitly designed not to complain about bogus switches. I just typed --without-gc and was momentarily surprised that the module was still enabled. I propose to change the switch to --with(out)-gc and to not recognize --with(out)-cycle-gc. The switch hasn't been there long enough to support both. -Barry From jeremy at beopen.com Fri Jun 30 19:02:42 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 30 Jun 2000 13:02:42 -0400 (EDT) Subject: [Python-Dev] --with-cycle-gc switch In-Reply-To: <14684.53251.309942.13110@anthem.concentric.net> References: <14684.53251.309942.13110@anthem.concentric.net> Message-ID: <14684.53938.307841.921051@bitdiddle.concentric.net> The problem with the name --without-gc is that it suggests a build without any garbage collection. The new patch only handles one special case of garbage collection. The name --without-cycle-gc is a little unwieldy, but clearer. Jeremy From Vladimir.Marangozov at inrialpes.fr Fri Jun 30 19:11:50 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Fri, 30 Jun 2000 19:11:50 +0200 (CEST) Subject: [Python-Dev] --with-cycle-gc switch In-Reply-To: <14684.53251.309942.13110@anthem.concentric.net> from "Barry A. Warsaw" at Jun 30, 2000 12:51:15 PM Message-ID: <200006301711.TAA21382@python.inrialpes.fr> Barry A. Warsaw wrote: > > I propose to change the switch to --with(out)-gc and to not recognize > --with(out)-cycle-gc. The switch hasn't been there long enough to > support both. -0 for the reason summarized by Jeremy -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From effbot at telia.com Fri Jun 30 19:33:55 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 30 Jun 2000 19:33:55 +0200 Subject: [Python-Dev] SRE: a minor glitch in re.py References: <200006301625.JAA32503@slayer.i.sourceforge.net> Message-ID: <02cc01bfe2b9$61b8ee80$f2a6b5d4@hagrid> from the new re.py: > ! # change this to "pre" if your regexps stopped working. don't > ! # forget to send a bug report to is bugs-py at python.org suitable? or should we refer people to http://www.python.org/search/search_bugs.html or should they pester me directly? (i.e. effbot at telia.com) From guido at python.org Fri Jun 30 20:33:46 2000 From: guido at python.org (Guido van Rossum) Date: Fri, 30 Jun 2000 13:33:46 -0500 Subject: [Python-Dev] SRE: a minor glitch in re.py In-Reply-To: Your message of "Fri, 30 Jun 2000 19:33:55 +0200." <02cc01bfe2b9$61b8ee80$f2a6b5d4@hagrid> References: <200006301625.JAA32503@slayer.i.sourceforge.net> <02cc01bfe2b9$61b8ee80$f2a6b5d4@hagrid> Message-ID: <200006301833.NAA18667@cj20424-a.reston1.va.home.com> > from the new re.py: > > > ! # change this to "pre" if your regexps stopped working. don't > > ! # forget to send a bug report to > > is bugs-py at python.org suitable? > > or should we refer people to > http://www.python.org/search/search_bugs.html > > or should they pester me directly? (i.e. effbot at telia.com) Probably. You decide and check it in! --Guido van Rossum (home page: http://www.python.org/~guido/) From bwarsaw at beopen.com Fri Jun 30 19:39:12 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Fri, 30 Jun 2000 13:39:12 -0400 (EDT) Subject: [Python-Dev] --with-cycle-gc switch References: <14684.53251.309942.13110@anthem.concentric.net> <200006301711.TAA21382@python.inrialpes.fr> Message-ID: <14684.56128.700037.255534@anthem.concentric.net> >>>>> "VM" == Vladimir Marangozov writes: VM> -0 VM> for the reason summarized by Jeremy Okay, I'll leave it alone. From Vladimir.Marangozov at inrialpes.fr Fri Jun 30 19:52:15 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Fri, 30 Jun 2000 19:52:15 +0200 (CEST) Subject: [Python-Dev] Oops on AIX Message-ID: <200006301752.TAA22474@python.inrialpes.fr> After the CVS commit storm that occurred during the last 3 days, I wanted to validate the current build on AIX. And I am stalled. I am not sure, but it seems like the errors I get relate with the latest 64-bit support patches, and I don't dare to suggest corrections in this area, so I welcome any help... xlc_r -O -I./../Include -I.. -DHAVE_CONFIG_H -c methodobject.c "methodobject.c", line 183.36: 1506-280 (E) Function argument assignment between types "void*" and "struct _object*(*)(struct _object*,struct _object*)" is not allowed. xlc_r -O -I./../Include -I.. -DHAVE_CONFIG_H -c ./posixmodule.c "./posixmodule.c", line 293.16: 1506-213 (S) Macro name STAT cannot be redefined. "./posixmodule.c", line 293.16: 1506-358 (I) "STAT" is defined on line 170 of /usr/include/sys/dir.h. make: 1254-004 The error code from the last command is 1. Thanks. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From effbot at telia.com Fri Jun 30 19:53:45 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 30 Jun 2000 19:53:45 +0200 Subject: [Python-Dev] SRE incompatibility References: Message-ID: <032701bfe2bc$23da47a0$f2a6b5d4@hagrid> tim wrote: > > That doesn't help with regexes, of course, since a pattern might be > > written as a regular string but be intended to match Unicode. Maybe > > the simplest rule is the best; always take 4 digits, even if it winds > > up being incompatible with the \x in string literals. > > I vote for backward compatibility for now, and not only because that will > irritate /F the most. backward compatibility with what? 8-bit string literals or unicode string literals? the problem here is that the pattern is compiled once (from either 8-bit or unicode strings), and can then be used on either 8-bit or unicode targets. to be fully backwards compatible, this means that the compiler should use 8 bits, no matter what string type you're using. another solution would be to use the type of the pattern string to choose between 8 and 16 bits. I almost implemented that, before I realized that it broke the following rather nice property: sre.compile("some pattern") == sre.compile(u"some pattern") (well, the pattern type doesn't implement __cmp__, but you get the idea). the current implementation guarantees "==", but I'm planning to change that to "is" (!). anyway, I suspect it's too late to change this in 2.0b1. if enough people complain about this, we can always label it a "critical bug", and do something about it in b2. From bwarsaw at beopen.com Fri Jun 30 20:04:06 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Fri, 30 Jun 2000 14:04:06 -0400 (EDT) Subject: [Python-Dev] Odd behavior with `make test' Message-ID: <14684.57622.9807.868551@anthem.concentric.net> make test is behaving strangely. The first time I ran it I got test test_mmap crashed -- exceptions.SyntaxError : inconsistent use of tabs and spaces in indentation which I believe Jeremy has seen with test_sre. tabnanny says everything's fine, and running the module manually (and individually w/ regrtest) shows no problems with the test. Similarly, I got a different crash in test_sre. It says: test test_sre failed -- sre.search and I also get test test_re failed -- re.search I'm also getting bizare stuff like test test_strftime crashed -- exceptions.AttributeError : match test test_tokenize crashed -- exceptions.AttributeError : compile test test_xmllib crashed -- exceptions.AttributeError : compile This is all with a CVS updated Python 2.0b1. Now if I run "./python Lib/test/test_mmap.py" manually, this succeeds, and now either the failures go away or are transmorgrified into something more reasonable: mmap, strftime, tokenize, sre, and xmllib all pass. test_re still fails, but this time with test test_re failed -- Writing: '=== Failed incorrectly', expected: "('abc', 'abc', 0, 'fou" Blowing away the Lib/test/*.pyc's doesn't seem to re-trigger the problem once it's fixed, but doing a `make distclean' and `make test' gets me back to the initial situation. Weird! -Barry From effbot at telia.com Fri Jun 30 20:12:11 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 30 Jun 2000 20:12:11 +0200 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test README,NONE,1.1 References: <20000629232733.D24811@activestate.com> <20000629235247.A25090@activestate.com> Message-ID: <037e01bfe2be$b814d5a0$f2a6b5d4@hagrid> trent wrote: > On Fri, Jun 30, 2000 at 02:39:15AM -0400, Tim Peters wrote: > > BTW, I'd just like to say what a delight it is to work with *all* of you > > folks! > > I feel a group hug coming on in the morning. Or maybe I am just moved by the > beer that I had for dinner. :) beer for dinner? what an excellent idea. didn't I have some strong lager somewhere? ah, yes... hey, maybe I should rewrite the SRE core again, to get rid of those last glitches... From effbot at telia.com Fri Jun 30 20:15:37 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 30 Jun 2000 20:15:37 +0200 Subject: [Python-Dev] Odd behavior with `make test' References: <14684.57622.9807.868551@anthem.concentric.net> Message-ID: <038601bfe2bf$31c52da0$f2a6b5d4@hagrid> > test_re still fails, but this time with > > test test_re failed -- Writing: '=== Failed incorrectly', expected: "('abc', 'abc', 0, 'fou" note that test_re should fail; someone (me?) needs to regenerate the output file. the rest looks a bit scary, to say the least. does someone (sre?) overwrite something? does anyone have purify (dmalloc, fences, whatever) within reach? From Vladimir.Marangozov at inrialpes.fr Fri Jun 30 20:22:03 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Fri, 30 Jun 2000 20:22:03 +0200 (CEST) Subject: [Python-Dev] Odd behavior with `make test' In-Reply-To: <14684.57622.9807.868551@anthem.concentric.net> from "Barry A. Warsaw" at Jun 30, 2000 02:04:06 PM Message-ID: <200006301822.UAA22606@python.inrialpes.fr> Barry A. Warsaw wrote: > > make test is behaving strangely. The first time I ran it I got On which platform? Linux seems to do fine with most of this. On AIX (after some hacking related to my previous msg "Oops on AIX", I managed to compile everything but I'll dump an error log on Trent :-) > > test test_mmap crashed -- exceptions.SyntaxError : inconsistent use of tabs and spaces in indentation same here > test test_sre failed -- sre.search > ... > test test_re failed -- re.search > ... > test test_strftime crashed -- exceptions.AttributeError : match > test test_tokenize crashed -- exceptions.AttributeError : compile > test test_xmllib crashed -- exceptions.AttributeError : compile same here. I believe Guido & al. are aware as per the checkin msg, saying that /F promises to fix this. But on AIX I get in addition to the above failures: test test_array failed -- array('b') overflowed assigning -128L -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From tim_one at email.msn.com Fri Jun 30 20:20:46 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 30 Jun 2000 14:20:46 -0400 Subject: [Python-Dev] SRE incompatibility In-Reply-To: <032701bfe2bc$23da47a0$f2a6b5d4@hagrid> Message-ID: [Tim] > I vote for backward compatibility for now, and not only because > that will irritate /F the most. [/F] > backward compatibility with what? 1.5.2. > 8-bit string literals At least, because they were in 1.5.2. > or unicode string literals? I'm sorry \x escapes are even allowed in those -- \x notation is a gimmick for making strings hold arbitrary binary data, which we're trying to get away from. To the extent that they make any sense at all in Unicode strings, \u should be used instead. > the problem here is that the pattern is compiled once (from either > 8-bit or unicode strings), and can then be used on either 8-bit or > unicode targets. to be fully backwards compatible, this means that > the compiler should use 8 bits, no matter what string type you're > using. Unicode strings weren't in 1.5.2, so there can't possibly be a backwards compatibility issue with them -- at least not in the sense I'm using the phrase here. > another solution would be to use the type of the pattern string to > choose between 8 and 16 bits. I almost implemented that, before > I realized that it broke the following rather nice property: > > sre.compile("some pattern") == sre.compile(u"some pattern") > > (well, the pattern type doesn't implement __cmp__, but you get the > idea). the current implementation guarantees "==", but I'm planning > to change that to "is" (!). Do you mean that, e.g., sre.compile("\u0045") == sre.compile(u"\u0045") too? If so, that doesn't make any sense to me (interpreting \u in 8-bit strings is even more confused than interpreting \x in Unicode strings). But if you didn't mean to include this case, then the equality doesn't actually hold now, so there's nothing to preserve . > anyway, I suspect it's too late to change this in 2.0b1. if enough > people complain about this, we can always label it a "critical bug", > and do something about it in b2. I think the real problem here was MAL's generalization of \x to 2-byte stuff in Unicode strings. If Unicode strings *have* to support \x, then \x0123456789abcdef in Unicode strings should act like \u00ef in Unicode strings, and SRE should play along with that too. \x was broken to begin with; better to wipe it out than try to generalize it. OTOH, I didn't get much sleep last night <0.8 wink>. From effbot at telia.com Fri Jun 30 20:29:54 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 30 Jun 2000 20:29:54 +0200 Subject: [Python-Dev] Odd behavior with `make test' References: <200006301822.UAA22606@python.inrialpes.fr> Message-ID: <03ae01bfe2c1$30be3300$f2a6b5d4@hagrid> > > test test_sre failed -- sre.search > > ... > > test test_re failed -- re.search > > ... > > test test_strftime crashed -- exceptions.AttributeError : match > > test test_tokenize crashed -- exceptions.AttributeError : compile > > test test_xmllib crashed -- exceptions.AttributeError : compile > > same here. I believe Guido & al. are aware as per the checkin msg, > saying that /F promises to fix this. I have no idea what causes this. however, I just noticed that evil tabs had snucked their way into sre_parse and sre_compile. new, properly untabified versions are on their way to the repository. maybe the interpreter messes up badly once -tt has reported an error? try removing -tt from the TESTPYTHON line in the makefile, and see what happens. From gward at mems-exchange.org Fri Jun 30 20:26:51 2000 From: gward at mems-exchange.org (Greg Ward) Date: Fri, 30 Jun 2000 14:26:51 -0400 Subject: [Python-Dev] Hey! who changed sys.platform?! In-Reply-To: <14684.45307.983394.125671@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Fri, Jun 30, 2000 at 10:38:51AM -0400 References: <20000629233003.A1766@beelzebub> <14684.5401.518766.362678@cj42289-a.reston1.va.home.com> <395C681D.C3211F6@lemburg.com> <14684.41320.38954.833643@cj42289-a.reston1.va.home.com> <395CA354.16AC5B7E@lemburg.com> <200006301455.JAA30721@cj20424-a.reston1.va.home.com> <395CAAAA.5975A617@lemburg.com> <20000630102242.B16350@ludwig.cnri.reston.va.us> <14684.45307.983394.125671@cj42289-a.reston1.va.home.com> Message-ID: <20000630142650.B16028@ludwig.cnri.reston.va.us> On 30 June 2000, Fred L. Drake, Jr. said: > Why would you need to figure this out? Are you selecting a > platform-specific packaging system automatically? In that case, I'd > search for the presence of the tools rather than asking what sort of > distribution you're running on -- several distros use RPM, a few use > .deb packages, etc. When the user specifies one on the command line, > just use the one they name and be done with it. Currently it's up to the user to decide which kind of built distribution they want, with stupid defaults: dumb tarball for Unix, dumb ZIP file for Windows. If you want an RPM or a Windows installer, you have to say so explicitly. This is not a big deal, but it might be nice to detect automatically if we can build (say) RPMs and do so. This is not a high-priority feature, though. I'll accept a patch if someone out there is interested enough to implement it. Greg From effbot at telia.com Fri Jun 30 20:37:16 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 30 Jun 2000 20:37:16 +0200 Subject: [Python-Dev] SRE incompatibility References: Message-ID: <03ce01bfe2c2$38308560$f2a6b5d4@hagrid> tim wrote: > > to be fully backwards compatible, this means that the compiler > > should use 8 bits, no matter what string type you're using. ... > I think the real problem here was MAL's generalization of \x to 2-byte stuff > in Unicode strings. If Unicode strings *have* to support \x, then > > \x0123456789abcdef > > in Unicode strings should act like > > \u00ef > > in Unicode strings, and SRE should play along with that too. \x was broken > to begin with; better to wipe it out than try to generalize it. I think this means that we agree -- \x is a wart that can only be used to embed *binary bytes* in a string. From Vladimir.Marangozov at inrialpes.fr Fri Jun 30 20:37:35 2000 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Fri, 30 Jun 2000 20:37:35 +0200 (CEST) Subject: [Python-Dev] Odd behavior with `make test' In-Reply-To: <03ae01bfe2c1$30be3300$f2a6b5d4@hagrid> from "Fredrik Lundh" at Jun 30, 2000 08:29:54 PM Message-ID: <200006301837.UAA22688@python.inrialpes.fr> Fredrik Lundh wrote: > > maybe the interpreter messes up badly once -tt has reported an > error? try removing -tt from the TESTPYTHON line in the makefile, > and see what happens. Matches Barry's report exactly. To which I'll add the array('b') failure which is not due to an optimization of arraymodule.c. Will investigate this tonight. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From DavidA at ActiveState.com Fri Jun 30 20:43:14 2000 From: DavidA at ActiveState.com (David Ascher) Date: Fri, 30 Jun 2000 11:43:14 -0700 Subject: [Python-Dev] Hey! who changed sys.platform?! In-Reply-To: <200006301455.JAA30721@cj20424-a.reston1.va.home.com> Message-ID: > But I vote -1 on this one anyway -- it's too much code and almost by > its very nature not something that belongs in a "standard" library. > Plus, I don't want to be responsible for maintaining it. Sorry, > > --Guido van Rossum (home page: http://www.python.org/~guido/) Not that I hope to override the heavy -1, but I don't agree with the second point. It embodies a huge amount of knowledge that is needed to write portable code. As such, IMO, it _does_ belong in the standard library. How is it different in its nature from sys.platform, which is only a much weaker version of the same concept? --david From skip at mojam.com Fri Jun 30 19:35:20 2000 From: skip at mojam.com (Skip Montanaro) Date: Fri, 30 Jun 2000 12:35:20 -0500 (CDT) Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Misc COPYRIGHT,1.4,1.5 In-Reply-To: <200006301841.LAA20523@slayer.i.sourceforge.net> References: <200006301841.LAA20523@slayer.i.sourceforge.net> Message-ID: <14684.55896.890339.982232@beluga.mojam.com> Fred> The new copyright / license. ... Fred> ! ... IN NO EVENT SHALL THE REGENTS OR Fred> ! CONTRIBUTORS BE LIABLE FOR ... Who are the "regents" and the "contributors"? Should those terms be defined somewhere? not-a-lawyer-and-never-wanted-to-be-ly y'rs, -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille O'Neal said: "He's got the rings. I listen to the man with the rings." From nascheme at enme.ucalgary.ca Fri Jun 30 20:53:06 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Fri, 30 Jun 2000 12:53:06 -0600 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib/test/output test_gc,NONE,1.1 In-Reply-To: <14684.7005.661874.713000@beluga.mojam.com>; from skip@mojam.com on Thu, Jun 29, 2000 at 11:00:29PM -0500 References: <200006300502.WAA03286@slayer.i.sourceforge.net> <14684.7005.661874.713000@beluga.mojam.com> Message-ID: <20000630125306.B32568@acs.ucalgary.ca> On Thu, Jun 29, 2000 at 11:00:29PM -0500, Skip Montanaro wrote: > I can all but guarantee you this test will always fail. Printing absolute > machine addresses (via calls to id() in this case) in test cases should be > verboten. This test script should be better. It doesn't generate any output (the stuff the old script printed was pretty useless anyhow). Neil -------------- next part -------------- import gc from test_support import * def test_list(): l = [] l.append(l) gc.collect() del l assert gc.collect() == 1 def test_dict(): d = {} d[1] = d gc.collect() del d assert gc.collect() == 1 def test_tuple(): l = [] t = (l,) l.append(t) gc.collect() del t del l assert gc.collect() == 2 def test_class(): class A: pass A.a = A gc.collect() del A assert gc.collect() > 0 def test_instance(): class A: pass a = A() a.a = a gc.collect() del a assert gc.collect() > 0 def test_method(): class A: def __init__(self): self.init = self.__init__ a = A() gc.collect() del a assert gc.collect() > 0 def test_finalizer(): class A: def __del__(self): pass class B: pass a = A() a.a = a id_a = id(a) b = B() b.b = b gc.collect() del a del b assert gc.collect() > 0 for obj in gc.garbage: if id(obj) == id_a: return raise TestFailed def test_function(): d = {} exec("def f(): pass\n") in d gc.collect() del d assert gc.collect() > 0 def test_all(): threshold = gc.get_threshold() gc.set_threshold(0) # disable automatic collection gc.collect() test_list() test_dict() test_tuple() test_class() test_instance() test_method() test_finalizer() test_function() apply(gc.set_threshold, threshold) test_all() From tim_one at email.msn.com Fri Jun 30 20:51:59 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 30 Jun 2000 14:51:59 -0400 Subject: [Python-Dev] SRE incompatibility In-Reply-To: <03ce01bfe2c2$38308560$f2a6b5d4@hagrid> Message-ID: [/F] > I think this means that we agree -- \x is a wart that can only > be used to embed *binary bytes* in a string. We certainly agree about that part! I thought my > I'm sorry \x escapes are even allowed in [u-strings] -- \x notation > is a gimmick for making strings hold arbitrary binary data, which > we're trying to get away from. To the extent that they make any > sense at all in Unicode strings, \u should be used instead. was pretty explicit . What we may still disagree on is how SRE should deal with the \x mess. I'm in favor of making \x mean "just the last byte" in plain and Unicode strings -- do the least harm with this (mis)feature. Making \x mean anything other than that for plain strings, regardless of context, is not backward compatible (with 1.5.2). And since Unicode strings haven't been released yet, it's not too late to change what they do with \x. That would make SRE's job clear here, yes? And in a way that allows the now-failing test to pass again? From skip at mojam.com Fri Jun 30 19:43:21 2000 From: skip at mojam.com (Skip Montanaro) Date: Fri, 30 Jun 2000 12:43:21 -0500 (CDT) Subject: [Python-Dev] "make test" vs. "-tt" Message-ID: <14684.56377.293211.329273@beluga.mojam.com> Per Fredrik's suggestion, I changed "-tt" to simply "-t". I've not yet done a "cvs update" to grab the tab-corrected versions of whatever files were causing the indigestion. I'm down to a single test failure (test_re) now when running "make test" before .py[co] files have been created. I noticed a couple warnings when test_mmap was running though: ./Lib/sre_compile.py: inconsistent tab/space usage ./Lib/sre_parse.py: inconsistent tab/space usage Could it be that when "-tt" detects a problem it causes a broken .py[co] file to be generated? -- Skip Montanaro, skip at mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille O'Neal said: "He's got the rings. I listen to the man with the rings." From DavidA at ActiveState.com Fri Jun 30 20:58:20 2000 From: DavidA at ActiveState.com (David Ascher) Date: Fri, 30 Jun 2000 11:58:20 -0700 Subject: [Python-Dev] New PythonLabs site revealed! In-Reply-To: <14684.42843.472230.609828@anthem.concentric.net> Message-ID: > That's a good point. A bump in major rev number is an /opportunity/ > to break things, like a bone that hasn't healed right, so that they > can be fixed correctly. We'll lose that for 2.0, mostly likely > because of the tight release schedule. Yes, I find that frustrating. The story for months (years?) has been that we don't break things because it's a 'dot-release', and so we've shelved improvements left and right. Now we don't have time to do those things even when it _is_ a major release. Some advance notice would have been nice. --david From fdrake at beopen.com Fri Jun 30 21:05:42 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 30 Jun 2000 15:05:42 -0400 (EDT) Subject: [Python-Dev] New PythonLabs site revealed! In-Reply-To: References: <14684.42843.472230.609828@anthem.concentric.net> Message-ID: <14684.61318.668529.402341@cj42289-a.reston1.va.home.com> David Ascher writes: > Yes, I find that frustrating. The story for months (years?) has been that > we don't break things because it's a 'dot-release', and so we've shelved > improvements left and right. Now we don't have time to do those things even > when it _is_ a major release. > > Some advance notice would have been nice. I agree, but this was news to at least some of us even Wednesday. The upside is that major releases are more likely to happen now that the precedent has been set. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From tim_one at email.msn.com Fri Jun 30 21:06:04 2000 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 30 Jun 2000 15:06:04 -0400 Subject: [Python-Dev] New PythonLabs site revealed! In-Reply-To: Message-ID: [David Ascher, wishing he had had the opportunity to break things with 2.0] > ... > Some advance notice would have been nice. David, it would have been nice for us too <0.3 wink>. we're-not-keeping-secrets-we're-just-another-thrashing-startup-ly y'rs - tim From nascheme at enme.ucalgary.ca Fri Jun 30 21:50:52 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Fri, 30 Jun 2000 13:50:52 -0600 Subject: [Python-Dev] Windows build issues Message-ID: <20000630135052.A405@acs.ucalgary.ca> A couple of things: PCbuild/readme.txt Should be updated for the new release. PC/config.h VC++ 5.0 will not compile python20 unless "#include " is commented out. Trent? WITH_CYCLE_GC should be uncommented if we want to have GC enabled in the beta. PCbuild/python20.dsp Line endings seem to be incorrect. Someone probably edited the file on a Unix machine and munched things up. VC++ 5.0 likes DOS line endings otherwise it refuses to load the project. Also, I get a few warnings when compiling. One is about an /IZ (I think) option being ignored. There are a few other warnings as well which I didn't write down. Neil From effbot at telia.com Fri Jun 30 21:53:05 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 30 Jun 2000 21:53:05 +0200 Subject: [Python-Dev] SRE incompatibility References: Message-ID: <03f501bfe2cc$cf5dcce0$f2a6b5d4@hagrid> tim wrote: > That would make SRE's job clear here, yes? And in a way that allows the > now-failing test to pass again? sure. quoting from python-checkins: RCS file: /cvsroot/python/python/dist/src/Lib/test/output/test_sre,v ... test_sre - === Failed incorrectly ('\\x00ffffffffffffff', '\377', 0, 'found', '\377') === Failed incorrectly ('^(.+)?B', 'AB', 0, 'g1', 'A') ... still messes up on nested repetitions, but that's entirely different problem... From fdrake at beopen.com Fri Jun 30 22:23:35 2000 From: fdrake at beopen.com (Fred L. Drake, Jr.) Date: Fri, 30 Jun 2000 16:23:35 -0400 (EDT) Subject: [Python-Dev] 2.0b1 documentation online Message-ID: <14685.455.115147.446238@cj42289-a.reston1.va.home.com> See it at: http://www.python.org/doc/devel/ -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From guido at python.org Fri Jun 30 23:23:09 2000 From: guido at python.org (Guido van Rossum) Date: Fri, 30 Jun 2000 16:23:09 -0500 Subject: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Misc COPYRIGHT,1.4,1.5 In-Reply-To: Your message of "Fri, 30 Jun 2000 12:35:20 EST." <14684.55896.890339.982232@beluga.mojam.com> References: <200006301841.LAA20523@slayer.i.sourceforge.net> <14684.55896.890339.982232@beluga.mojam.com> Message-ID: <200006302123.QAA20537@cj20424-a.reston1.va.home.com> > Fred> The new copyright / license. > ... > Fred> ! ... IN NO EVENT SHALL THE REGENTS OR > Fred> ! CONTRIBUTORS BE LIABLE FOR ... > > Who are the "regents" and the "contributors"? Should those terms be > defined somewhere? Oops. I thought I caught all the regents and replaced them with a more politically correct term. Seems one got away. Fixed now. > not-a-lawyer-and-never-wanted-to-be-ly y'rs, Ditto, --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Fri Jun 30 23:26:21 2000 From: guido at python.org (Guido van Rossum) Date: Fri, 30 Jun 2000 16:26:21 -0500 Subject: [Python-Dev] New PythonLabs site revealed! In-Reply-To: Your message of "Fri, 30 Jun 2000 11:58:20 MST." References: Message-ID: <200006302126.QAA20621@cj20424-a.reston1.va.home.com> > > That's a good point. A bump in major rev number is an /opportunity/ > > to break things, like a bone that hasn't healed right, so that they > > can be fixed correctly. We'll lose that for 2.0, mostly likely > > because of the tight release schedule. [David Ascher] > Yes, I find that frustrating. The story for months (years?) has been that > we don't break things because it's a 'dot-release', and so we've shelved > improvements left and right. Now we don't have time to do those things even > when it _is_ a major release. You have no idea how frustration it is for me! But sometimes the marketing people force us engineers to act quickly. Just be glad I'm not following the release schedule that they had *wanted* me to use... :-) > Some advance notice would have been nice. Same here. :-) --Guido van Rossum (home page: http://www.python.org/~guido/) From nascheme at enme.ucalgary.ca Fri Jun 30 22:31:48 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Fri, 30 Jun 2000 14:31:48 -0600 Subject: [Python-Dev] Idle breakage Message-ID: <20000630143148.A9725@acs.ucalgary.ca> Caused by _sre perhaps? $ python Tools/idle/idle.py Traceback (most recent call last): File "Tools/idle/idle.py", line 8, in ? IdleConf.load(idle_dir) File "Tools/idle/IdleConf.py", line 109, in load idleconf.read((os.path.join(dir, "config.txt"), genplatfile, platfile, File "/usr/local/lib/python2.0/ConfigParser.py", line 207, in read self.__read(fp, filename) File "/usr/local/lib/python2.0/ConfigParser.py", line 382, in __read raise e ConfigParser.ParsingError: File contains parsing errors: Tools/idle/config.txt [line 21]: 'width= 80\012' [line 22]: 'height= 24\012' [line 26]: 'normal-foreground= black\012' [line 27]: 'normal-background= white\012' [line 29]: 'keyword-foreground= #ff7700\012' [line 30]: 'comment-foreground= #dd0000\012' [line 31]: 'string-foreground= #00aa00\012' [line 32]: 'definition-foreground= #0000ff\012' [line 33]: 'hilite-foreground= #000068\012' [line 34]: 'hilite-background= #006868\012' [line 35]: 'break-foreground= #ff7777\012' [line 36]: 'hit-foreground= #ffffff\012' [line 37]: 'hit-background= #000000\012' [line 38]: 'stdout-foreground= blue\012' [line 39]: 'stderr-foreground= red\012' [line 40]: 'console-foreground= #770000\012' [line 41]: 'error-background= #ff7777\012' [line 42]: 'cursor-background= black\012' [line 59]: 'enable= 0\012' [line 60]: 'style= expression\012' [line 61]: 'flash-delay= 500\012' [line 62]: 'bell= 1\012' [line 63]: 'hilite-foreground= black\012' [line 64]: 'hilite-background= #43cd80\012' From jeremy at beopen.com Fri Jun 30 22:33:01 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 30 Jun 2000 16:33:01 -0400 (EDT) Subject: [Python-Dev] New PythonLabs site revealed! In-Reply-To: <200006302126.QAA20621@cj20424-a.reston1.va.home.com> References: <200006302126.QAA20621@cj20424-a.reston1.va.home.com> Message-ID: <14685.1021.870885.796187@bitdiddle.concentric.net> >>>>> "GvR" == Guido van Rossum writes: >> That's a good point. A bump in major rev number is an >> /opportunity/ to break things, like a bone that hasn't healed >> right, so that they can be fixed correctly. We'll lose that >> for 2.0, mostly likely because of the tight release schedule. GvR> [David Ascher] >> Yes, I find that frustrating. The story for months (years?) has >> been that we don't break things because it's a 'dot-release', and >> so we've shelved improvements left and right. Now we don't have >> time to do those things even when it _is_ a major release. GvR> You have no idea how frustration it is for me! But sometimes GvR> the marketing people force us engineers to act quickly. Just GvR> be glad I'm not following the release schedule that they had GvR> *wanted* me to use... :-) Perhaps I am too easy-going, but I consider the 2.0 release a 'dot-release' masquerading as a major revision. It might be a little silly, but it seems even sillier to preserve a naming scheme that makes users think that the technology is immature. Jeremy From guido at python.org Fri Jun 30 23:33:52 2000 From: guido at python.org (Guido van Rossum) Date: Fri, 30 Jun 2000 16:33:52 -0500 Subject: [Python-Dev] Windows build issues In-Reply-To: Your message of "Fri, 30 Jun 2000 13:50:52 CST." <20000630135052.A405@acs.ucalgary.ca> References: <20000630135052.A405@acs.ucalgary.ca> Message-ID: <200006302133.QAA20696@cj20424-a.reston1.va.home.com> > A couple of things: > > PCbuild/readme.txt > > Should be updated for the new release. Tim will do this. > PC/config.h > > VC++ 5.0 will not compile python20 unless "#include > " is commented out. Trent? I'll leave this to Trent -- I don't know how to check for VC 5.0 vs. 6.0. > WITH_CYCLE_GC should be uncommented if we want to have GC > enabled in the beta. Done. > PCbuild/python20.dsp > > Line endings seem to be incorrect. Someone probably edited > the file on a Unix machine and munched things up. VC++ 5.0 > likes DOS line endings otherwise it refuses to load the > project. There was one missing CR. Fixed now. > Also, I get a few warnings when compiling. One is about an /IZ > (I think) option being ignored. There are a few other warnings > as well which I didn't write down. Probably 6.0 flags that 5.0 doesn't have. What can we do? --Guido van Rossum (home page: http://www.python.org/~guido/) From nascheme at enme.ucalgary.ca Fri Jun 30 22:40:21 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Fri, 30 Jun 2000 14:40:21 -0600 Subject: [Python-Dev] Idle breakage In-Reply-To: <20000630143148.A9725@acs.ucalgary.ca>; from nascheme@enme.ucalgary.ca on Fri, Jun 30, 2000 at 02:31:48PM -0600 References: <20000630143148.A9725@acs.ucalgary.ca> Message-ID: <20000630144021.A9847@acs.ucalgary.ca> Changing to pre fixes the problem. Neil From mwh21 at cam.ac.uk Fri Jun 30 22:50:37 2000 From: mwh21 at cam.ac.uk (Michael Hudson) Date: 30 Jun 2000 21:50:37 +0100 Subject: [Python-Dev] Re: Test results of linuxaudiodev.c In-Reply-To: Ka-Ping Yee's message of "Thu, 29 Jun 2000 17:44:35 -0700 (PDT)" References: Message-ID: To python-dev: Sorry for the hiatus. To python-list: does someone who knows about audio and can run linux want to play with this (Ping and I fall into just one of these categories each!). Ka-Ping Yee writes: > On 30 Jun 2000, Michael Hudson wrote: > > Yup, that works fine. Don't understand the details - and as I have my > > graduation ceremony tomorrow I'm going to go to bed and leave learning > > them until some other occasion! > > Cool. > > Okay, i just discovered sunau.py. Here's my real shot at > test_linuxaudiodev.py. Can you give this a try? > > > ---- test_linuxaudiodev.py ---- > from test_support import verbose, findfile, TestFailed > import linuxaudiodev > import os, sunau > > formats = {("ULAW", 1): linuxaudiodev.AFMT_MU_LAW, > ("NONE", 1): linuxaudiodev.AFMT_S8, > ("NONE", 2): linuxaudiodev.AFMT_S16_BE} > > def play_au_file(path): > au = sunau.open(path, "r") > data = au.readframes(sunau.AUDIO_UNKNOWN_SIZE) > au.close() > > spec = (au.getcomptype(), au.getsampwidth()) > if not has_key(formats, spec): ^^^^^^^ Oops? > raise "audio format not supported by linuxaudiodev" Maybe you mean: raise TestFailed, "audio format not supported by linuxaudiodev" ? I thought string exceptions were deprecated... > dsp = linuxaudiodev.open("w") > dsp.setparameters(au.getframerate(), au.getsampwidth() * 8, > au.getnchannels(), formats[spec]) > dsp.write(data) > dsp.close() > > def test(): > play_au_file(findfile('audiotest.au')) > > test() This doesn't work. I don't really understand why. For audiotest.au, |spec| is ("ULAW",2), which I don't think is right; file(1) says audiotest.au: Sun/NeXT audio data: 8-bit ISDN u-law, mono, 8000 Hz So I think this could be a bug in sunau. The other data (au.getframerate(), au.getnchannels()) agrees with file(1). Anybody have a better idea? Cheers, Michael Hudson, BA (as of today! woohoo!) From jeremy at beopen.com Fri Jun 30 22:57:44 2000 From: jeremy at beopen.com (Jeremy Hylton) Date: Fri, 30 Jun 2000 16:57:44 -0400 (EDT) Subject: [Python-Dev] last minute GC questions Message-ID: <14685.2504.722378.79294@bitdiddle.concentric.net> I've got two last minute questions. Does it look to you like I checked in all of the changes that you and Vladimir discussed? Might we change the strategy for deciding when to collect? There are two parts of the strategy that could probably change. The first is what kind of allocation events we count to determine when to collect. Right now, the gc is counting the net effect of allocations and deallocations. This isn't effective for at least a couple of cases. If we allocate N objects and don't deallocate anything, then no garbage is going to be created. If we have many objects currently allocated and then dealloc N objects without allocating any, we could create collectible garbage, but the collector won't run because there haven't been any allocations. It seems to me that counting deallocations only would be more effective. It is only the deallocations that cause a live object to become garbage. The other part of the strategy that might be changed is the collection frequency. Right now, the threshold is 100 net allocations & dealloactions. On the compiler benchmark, this leads to some 2600 collections, which seems like a lot. (I have no idea why it seems like a lot, but it does.) I experimented with a policy that runs the collected every N deallocations (not counting deallocations the occur during a collection). I set N == 1000 and got 1600 collections on the compiler benchmark. There is only a small speedup (just a few percent), so maybe this change doesn't have a big effect. I don't recall much about the cost/complexity of various GC approaches. Jeremy From nascheme at enme.ucalgary.ca Fri Jun 30 23:12:06 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Fri, 30 Jun 2000 15:12:06 -0600 Subject: [Python-Dev] Re: last minute GC questions In-Reply-To: <14685.2504.722378.79294@bitdiddle.concentric.net>; from jeremy@beopen.com on Fri, Jun 30, 2000 at 04:57:44PM -0400 References: <14685.2504.722378.79294@bitdiddle.concentric.net> Message-ID: <20000630151206.A10333@acs.ucalgary.ca> On Fri, Jun 30, 2000 at 04:57:44PM -0400, Jeremy Hylton wrote: > I've got two last minute questions. > > Does it look to you like I checked in all of the changes that you and > Vladimir discussed? Nope. Neil Index: 0.13/Include/objimpl.h *** 0.13/Include/objimpl.h Fri, 30 Jun 2000 13:05:40 -0600 nas (python/o/19_objimpl.h 1.1.2.1.2.1.2.1 644) --- 0.13(w)/Include/objimpl.h Fri, 30 Jun 2000 15:09:51 -0600 nas (python/o/19_objimpl.h 1.1.2.1.2.1.2.1 644) *************** *** 204,209 **** --- 204,211 ---- (PyVarObject *) PyObject_MALLOC( _PyObject_VAR_SIZE((typeobj),(n)) ),\ (typeobj), (n)) ) + #define PyObject_DEL(op) PyObject_FREE(op) + /* This example code implements an object constructor with a custom allocator, where PyObject_New is inlined, and shows the important distinction between two steps (at least): *************** *** 242,248 **** PyObject_{New, VarNew, Del} to manage the memory. Set the type flag Py_TPFLAGS_GC and define the type method tp_recurse. You should also add the method tp_clear if your object is mutable. Include ! PyGC_INFO_SIZE in the calculation of tp_basicsize. Call PyObject_GC_Init after the pointers followed by tp_recurse become valid (usually just before returning the object from the allocation method. Call PyObject_GC_Fini before those pointers become invalid --- 244,250 ---- PyObject_{New, VarNew, Del} to manage the memory. Set the type flag Py_TPFLAGS_GC and define the type method tp_recurse. You should also add the method tp_clear if your object is mutable. Include ! PyGC_HEAD_SIZE in the calculation of tp_basicsize. Call PyObject_GC_Init after the pointers followed by tp_recurse become valid (usually just before returning the object from the allocation method. Call PyObject_GC_Fini before those pointers become invalid *************** *** 255,261 **** #define PyObject_GC_Fini(op) #define PyObject_AS_GC(op) (op) #define PyObject_FROM_GC(op) (op) - #define PyObject_DEL(op) PyObject_FREE(op) #else --- 257,262 ---- *************** *** 289,295 **** /* Get the object given the PyGC_Head */ #define PyObject_FROM_GC(g) ((PyObject *)(((PyGC_Head *)g)+1)) ! #define PyObject_DEL(op) PyObject_FREE( PyObject_IS_GC(op) ? \ (ANY *)PyObject_AS_GC(op) : \ (ANY *)(op) ) --- 290,297 ---- /* Get the object given the PyGC_Head */ #define PyObject_FROM_GC(g) ((PyObject *)(((PyGC_Head *)g)+1)) ! #undef PyObject_DEL ! #define PyObject_DEL(op) PyObject_FREE( (op && PyObject_IS_GC(op)) ? \ (ANY *)PyObject_AS_GC(op) : \ (ANY *)(op) ) Index: 0.13/Objects/object.c *** 0.13/Objects/object.c Fri, 30 Jun 2000 13:05:40 -0600 nas (python/E/29_object.c 1.1.1.1.1.1.1.1.1.1.1.1 644) --- 0.13(w)/Objects/object.c Fri, 30 Jun 2000 15:05:26 -0600 nas (python/E/29_object.c 1.1.1.1.1.1.1.1.1.1.1.1 644) *************** *** 192,205 **** PyObject *op; { #ifdef WITH_CYCLE_GC ! if (PyType_IS_GC(op->ob_type)) { ! PyGC_Head *g = PyObject_AS_GC(op); ! PyObject_FREE(g); ! } else ! #endif ! { ! PyObject_FREE(op); } } #ifndef WITH_CYCLE_GC --- 192,202 ---- PyObject *op; { #ifdef WITH_CYCLE_GC ! if (op && PyType_IS_GC(op->ob_type)) { ! op = (PyObject *) PyObject_AS_GC(op); } + #endif + PyObject_FREE(op); } #ifndef WITH_CYCLE_GC From effbot at telia.com Fri Jun 30 23:20:20 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 30 Jun 2000 23:20:20 +0200 Subject: [Python-Dev] Windows build issues References: <20000630135052.A405@acs.ucalgary.ca> <200006302133.QAA20696@cj20424-a.reston1.va.home.com> Message-ID: <044b01bfe2d9$01dcee60$f2a6b5d4@hagrid> guido wrote: > > PC/config.h > > > > VC++ 5.0 will not compile python20 unless "#include > > " is commented out. Trent? > > I'll leave this to Trent -- I don't know how to check for VC 5.0 > vs. 6.0. #if _MSC_VER >= 1200 VC 6.0 #else VC 5.0 or earlier #endif (we added a similar workaround to Python/thread_nt.c) > > Also, I get a few warnings when compiling. One is about an /IZ > > (I think) option being ignored. There are a few other warnings > > as well which I didn't write down. > > Probably 6.0 flags that 5.0 doesn't have. What can we do? ignore it, for now. I remember seeing a few type warnings, but nothing critical. there's plenty of time to sort that out on the way to 2.0 final. From effbot at telia.com Fri Jun 30 23:24:06 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 30 Jun 2000 23:24:06 +0200 Subject: [Python-Dev] Idle breakage References: <20000630143148.A9725@acs.ucalgary.ca> Message-ID: <046a01bfe2d9$88302360$f2a6b5d4@hagrid> neil wrote: > Caused by _sre perhaps? > > ConfigParser.ParsingError: File contains parsing errors: Tools/idle/config.txt > [line 21]: 'width= 80\012' probably; I'll dig into this. when's the 2.0 deadline? From nascheme at enme.ucalgary.ca Fri Jun 30 23:30:08 2000 From: nascheme at enme.ucalgary.ca (Neil Schemenauer) Date: Fri, 30 Jun 2000 15:30:08 -0600 Subject: [Python-Dev] Fwd: Re: last minute GC questions Message-ID: <20000630153008.C10333@acs.ucalgary.ca> Oops, should have cc python-dev. ----- Forwarded message from Neil Schemenauer ----- Date: Fri, 30 Jun 2000 15:27:48 -0600 From: Neil Schemenauer Subject: Re: last minute GC questions To: Jeremy Hylton X-Url: http://www.enme.ucalgary.ca/~nascheme/ On Fri, Jun 30, 2000 at 04:57:44PM -0400, Jeremy Hylton wrote: > Might we change the strategy for deciding when to collect? We might. :) > It seems to me that counting deallocations only would be more > effective. It is only the deallocations that cause a live object to > become garbage. You can easily run out of memory with that strategy though: N = 10000 while 1: l = [] for i in xrange(N): l.append([]) l[0] = l You only get a couple of deallocations while a large amount of garbage is created. Think of large cyclic structures like graphs being created and then becoming garbage due to one deallocation. By counting the net new objects we guarantee that this doesn't happen. > The other part of the strategy that might be changed is the collection > frequency. Right now, the threshold is 100 net allocations & > dealloactions. On the compiler benchmark, this leads to some 2600 > collections, which seems like a lot. (I have no idea why it seems > like a lot, but it does.) Try setting the threshold to zero. The major part of the GC overhead does not seem to be running the collector. OTOH, the frequency could probably be decreased without the risk of running out of memory. No Python applications currently exist that create that amount of garbage anyhow. Neil ----- End forwarded message ----- From effbot at telia.com Fri Jun 30 23:39:26 2000 From: effbot at telia.com (Fredrik Lundh) Date: Fri, 30 Jun 2000 23:39:26 +0200 Subject: [Python-Dev] Idle breakage References: <20000630143148.A9725@acs.ucalgary.ca> <046a01bfe2d9$88302360$f2a6b5d4@hagrid> Message-ID: <049601bfe2db$acea1380$f2a6b5d4@hagrid> I wrote: > > Caused by _sre perhaps? > > > > ConfigParser.ParsingError: File contains parsing errors: Tools/idle/config.txt > > [line 21]: 'width= 80\012' > > probably; I'll dig into this. confirmed. SRE implements $ exactly as described in the library reference, RE doesn't ;-) patch coming within 30 minutes. From bwarsaw at beopen.com Fri Jun 30 23:57:19 2000 From: bwarsaw at beopen.com (Barry A. Warsaw) Date: Fri, 30 Jun 2000 17:57:19 -0400 (EDT) Subject: [Python-Dev] Odd behavior with `make test' References: <14684.57622.9807.868551@anthem.concentric.net> <038601bfe2bf$31c52da0$f2a6b5d4@hagrid> Message-ID: <14685.6079.779817.674190@anthem.concentric.net> >>>>> "FL" == Fredrik Lundh writes: FL> the rest looks a bit scary, to say the least. does someone FL> (sre?) overwrite something? does anyone have purify (dmalloc, FL> fences, whatever) within reach? I will very soon. I found a Solaris box on which I could load up an eval copy of Purify. Will report back soon. -Barry