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 June 7, 2000

June 7, 2000

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 June 7, 2000

June 7, 2000

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 … [View More]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/ [View Less]

6 8

ANSI-fication (was: RE: [Patches] fix simple 64-bit warnings/errors in signalmodule.c and bufferobject.c)
by Greg Stein June 7, 2000

June 7, 2000

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 > … [View More]

5 5

Re: [Python-checkins] CVS: python/dist/src/Modules Setup.in,1.100,1.101
by pf＠artcom-gmbh.de June 7, 2000

June 7, 2000

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 > > ! … [View More]

1 0

req: Software Carpentry / coding standards
by Greg Wilson June 6, 2000

June 6, 2000

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.… [View More]

9 10

Trying again: [Patches] Patch to import.c
by Jack Jansen June 6, 2000

June 6, 2000

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 … [View More]

1 0

about patches on SourceForge
by Trent Mick June 6, 2000

June 6, 2000

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 … [View More]

3 3

PyMarshal_WriteLongToFile: writes 'long' or 32-bit integer?
by Trent Mick June 6, 2000

June 6, 2000

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 … [View More]

5 5

Guido and Kim married
by Ken Manheimer June 6, 2000

June 6, 2000

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 … [View More]

1 0

httplib (was: Adding LDAP to the Python core... ?!)
by Greg Stein June 5, 2000

June 5, 2000

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 … [View More]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/ [View Less]

2 5