Mailman 3 January 2001 - Python-Dev

Re: [Python-Dev] xreadlines : readlines :: xrange : range
by Guido van Rossum 03 Jan '01

03 Jan '01

Apparently getc_unlocked() is in the Single Unix spec. Not sure how widespread that is -- do Linux developers pay attention to this standard at all? According to the webpage it's (c) 1997. --Guido van Rossum (home page: http://www.python.org/~guido/) ------- Forwarded Message Date: Wed, 03 Jan 2001 10:58:44 +0200 From: Erno Kuusela <erno(a)iki.fi> To: guido(a)python.org Subject: getc_unlocked note hello, i was reading the python-dev archives and saw that someone had noticed my getline/getc_unlocked post from the newsgroup. a correction to the python-dev thread: getc_unlocked and friends are infact standard (not c99 though since c99 doesn't specify threads); they are part of the single unix specification. link: http://www.opennc.org/onlinepubs/007908799/xsh/getc_unlocked.html -- erno ------- End of Forwarded Message

2 2

Std test failures on WIndows: test_compare, test_minidom
by Tim Peters 02 Jan '01

02 Jan '01

test_compare is broken because the expected-output file has bizarre stuff in it like: cmp(2, [1]) = -108 cmp(2, (2,)) = -116 cmp(2, None) = -78 What's up with that? I'll leave test_minidom to someone who thinks they know what it's doing. Both failures are very recent.

2 6

testing, please ignore
by barry＠digicool.com 02 Jan '01

02 Jan '01

Sorry folks, just making sure things are working again. you-really-didn't-want-email-this-millennium-didja?-ly y'rs, -Barry

1 0

Applying the PEP 208 (coercion overhaul) patch
by Neil Schemenauer 02 Jan '01

02 Jan '01

I'm almost ready to apply SF patch #102652. Guido has give the okay assuming there are no objections from the rest of python-dev. The patch is large and modifies some complicated parts of the interpreter. I expect there will be some bugs. If you would like me to wait, speak now. Guido has sent me some comments on the patch today which I plan to review and address tonight. I will probably apply the patch tomorrow evening. Neil

1 0

RE: [Python-Dev] Fwd: try...else
by Tim Peters 02 Jan '01

02 Jan '01

[Robin Becker] > The 2.0 docs clearly state 'The optional else clause is executed when no > exception occurs in the try clause.' This makes it sound as though it > gets executed on the 'way out'. Of course. That's not what the docs meant, though, and Guido is not going to change the implementation now because that would break code that relies on how Python has always *worked* in these cases. The way Python works is also the way Guido intended it to work (I'm allowed to channel him when he's on vacation <0.9 wink)>. Indeed, that's why I suggested a specific doc change. If your friend would also be confused by that, then we still have a problem; else we don't.

3 5

curses in the core?
by Martin v. Loewis 02 Jan '01

02 Jan '01

> If curses is a core facility now, the default build should tread it > as one. ... > IMO ssl isn't an issue because it's not documented as being in the > standard module set. ... > 3. Documented as being in the core but not built in by default. > My more general claim is that the existence of class 3 is a problem In the case of curses, I believe there is a documentation error in the 2.0 documentation. The curses packages is listed under "Generic Operating System Services". I believe this is wrong, it should be listed as "Unix Specific Services". Unless I'm mistaken, the curses module is not available on the Mac and on Windows. With that change, the curses module would then fall into Eric's category 2 (Not documented as being in the core and not built in by default). That documentation change should be carried out even if curses is autoconfigured; autoconf is used on Unix only, either. Regards, Martin P.S. The "Python Library Reference" content page does not mention the word "core" at all, except as part of asyncore...

3 2

FAQ Horribly Out Of Date
by Moshe Zadka 01 Jan '01

01 Jan '01

Hi! The current FAQ is horribly out of date. I think the FAQ-Wizard method has proven itself not very efficient (for example, apparently no one noticed until now that it's not working <0.2 wink>). Is there any hope putting the FAQ in Misc/, having a script which scp's it to the SF page, and making that the official FAQ? On a related note, what is the current status of the PSA? Is it officially dead? -- Moshe Zadka <sig(a)zadka.site.co.il> This is a signature anti-virus. Please stop the spread of signature viruses!

5 8

PSA (Was: FAQ Horribly Out Of Date)
by Martin v. Loewis 01 Jan '01

01 Jan '01

> It appears that CNRI can only think about one thing at a time <0.5 > wink>. For the last 6 months, that thing has been the license. If > they ever resolve the GPL compatibility issue, maybe they can be > persuaded to think about the PSA. In the meantime, I'd suggest you > not renew <ahem>. I think we need to find a better answer than that, and soon. While everybody reading this list probably knows not to renew, the PSA is the first thing that you see when selecting "Python Community" on python.org. The first paragraph reads # The continued, free existence of Python is promoted by the # contributed efforts of many people. The Python Software Activity # (PSA) supports those efforts by helping to coordinate them. The PSA # operates web, ftp, and email services, organizes conferences, and # engages in other activities that benefit the Python user # community. In order to continue, the PSA needs the membership of # people who value Python. If you look at the current members list (http://www.python.org/psa/Members.html), it appears that many long-time members indeed have not renewed. This page was last updated Nov 14 - so it appears that CNRI is still processing applications when they come. It may well be that many of the newer members ask themselves by now what happened to their money; it might not be easy to get an answer to that question. However, there is clearly somebody to blame here: The Python Community. So I'd like to request that somebody with write permissions to these pages changes the text, to something along the lines of replacing the first paragraph with # The Python community organizes itself in different ways; people # interested in discussing development of and with Python usually # participate in <a href="MailingLists.html">mailing lists</a>. # # <p>Organizations that wish to influence further directions of the # Python language may join the <a href="/consortium">Python # Consortium</a>. # # <p>The <a href="http://www.cnri.reston.va.us/">Corporation for # National Research Initiatives</a> hosts the Python Software # Activity, which is described below. The PSA used to provide funding # for the Python development; that is no longer the case. If there is a factual error in this text, please let me know. Regards, Martin

2 1

Re: Copyright statements ([Patch #103002] Fix for #116285: Properly raise UnicodeErrors)
by M.-A. Lemburg 01 Jan '01

01 Jan '01

Martin von Loewis wrote: > > > My only problem with it is your copyright notice. AFAIK, patches to > > the Python core cannot contain copyright notices without proper > > license information. OTOH, I don't think that these minor changes > > really warrant adding a complete license paragraph. > > I'd like to get an "official" clarification on this question. Is it > the case that patches containing copyright notices are only accepted > if they are accompanied with license information? > > I agree that the changes are minor, I also believe that I hold the > copyright to the changes whether I attach a notice or not (at least > according to our local copyright law). True. > What concerns me that without such a notice, gencodec.py looks as if > CNRI holds the copyright to it. I'm not willing to assign the > copyright of my changes to CNRI, and I'd like to avoid the impression > of doing so. > > What is even more concerning is that CNRI also holds the copyright to > the generated files, even though they are derived from information > made available by the Unicode consortium! The copyright for the files and changes needed for the Unicode support was indeed transferred to CNRI earlier this year. This was part of the contract I had with CNRI. I don't know why the copyright notice wasn't subsequently removed from the files after final checkin of the changes, though, because, as I remember, the copyright line was only added as "search&replace" token to the files in question in the sign over period. The codec files were part of the Unicode support patch, even though they were created by the gencodec.py tool I wrote to create them from the Unicode mapping files. That's why they also carry the copyright token. Note that with strict reading of the CNRI license, there's no problem with removing the notice from the files in question: """ ...provided, however, that CNRI's License Agreement and CNRI's notice of copyright, i.e., "Copyright (c) 1995-2000 Corporation for National Research Initiatives; All Rights Reserved" are retained in Python 1.6 alone or in any derivative version prepared by Licensee... """ The copyright line in the Unicode files is "(c) Copyright CNRI, All Rights Reserved. NO WARRANTY.", so this does not match the definition they gave in their license text. -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

1 0

Re: [Patch #103002] Fix for #116285: Properly raise UnicodeErrors
by Martin von Loewis 01 Jan '01

01 Jan '01

[resent since python.org ran out of disk space] > My only problem with it is your copyright notice. AFAIK, patches to > the Python core cannot contain copyright notices without proper > license information. OTOH, I don't think that these minor changes > really warrant adding a complete license paragraph. I'd like to get an "official" clarification on this question. Is it the case that patches containing copyright notices are only accepted if they are accompanied with license information? I agree that the changes are minor, I also believe that I hold the copyright to the changes whether I attach a notice or not (at least according to our local copyright law). What concerns me that without such a notice, gencodec.py looks as if CNRI holds the copyright to it. I'm not willing to assign the copyright of my changes to CNRI, and I'd like to avoid the impression of doing so. What is even more concerning is that CNRI also holds the copyright to the generated files, even though they are derived from information made available by the Unicode consortium! Regards, Martin

2 2