Mailman 3 June 2000 - Python-Dev

Re: [Python-Dev] Idea: emulating _locale (was Re: [Python-checkins] CVS: python/dist/src/Lib locale.py,1.4,1.5)
by Jack Jansen 07 Jun '00

07 Jun '00

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(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

1 0

Re: [Patches] Translating doc strings
by M.-A. Lemburg 07 Jun '00

07 Jun '00

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/

6 8

ANSI-fication (was: RE: [Patches] fix simple 64-bit warnings/errors in signalmodule.c and bufferobject.c)
by Greg Stein 07 Jun '00

07 Jun '00

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/

5 5

Re: [Python-checkins] CVS: python/dist/src/Modules Setup.in,1.100,1.101
by pf＠artcom-gmbh.de 07 Jun '00

07 Jun '00

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

1 0

req: Software Carpentry / coding standards
by Greg Wilson 06 Jun '00

06 Jun '00

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

9 10

Trying again: [Patches] Patch to import.c
by Jack Jansen 06 Jun '00

06 Jun '00

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

1 0

about patches on SourceForge
by Trent Mick 06 Jun '00

06 Jun '00

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(a)activestate.com

3 3

PyMarshal_WriteLongToFile: writes 'long' or 32-bit integer?
by Trent Mick 06 Jun '00

06 Jun '00

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(a)activestate.com

5 5

Guido and Kim married
by Ken Manheimer 06 Jun '00

06 Jun '00

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(a)digicool.com

1 0

httplib (was: Adding LDAP to the Python core... ?!)
by Greg Stein 06 Jun '00

06 Jun '00

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 <gstein(a)lyra.org> 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/

2 5