Mailman 3 August 2000 - Python-Dev

Re: [Python-checkins] CVS: python/nondist/peps pep-0000.txt,1.24,1.25
by Thomas Wouters Aug. 21, 2000

Aug. 21, 2000

On Mon, Aug 21, 2000 at 06:35:40AM -0700, Barry Warsaw wrote: > Update of /cvsroot/python/python/nondist/peps > In directory slayer.i.sourceforge.net:/tmp/cvs-serv27120 > Modified Files: > pep-0000.txt > Log Message: > PEP 202, change tim's email address to tpeters -- we really need a key > for these. > I 200 pep-0200.txt Python 2.0 Release Schedule jhylton > SA 201 pep-0201.txt Lockstep Iteration bwarsaw > ! S 202 pep-0202.txt List Comprehensions tim_one > S 203 pep-0203.txt Augmented Assignments twouters > S 204 pep-0204.txt Range Literals twouters I thought the last collumn was the SourceForge username ? I don't have an email address that reads 'twouters', except the SF one, anyway, and I thought tim had 'tim_one' there. Or did he change it ? -- Thomas Wouters <thomas(a)xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

5 6

Re: [Python-checkins] CVS: python/dist/src/Python import.c,2.146,2.147
by Fred L. Drake, Jr. Aug. 21, 2000

Aug. 21, 2000

Barry Warsaw writes: > Thomas reminds me to bump the MAGIC number for the extended print > opcode additions. You also need to document the new opcodes in Doc/lib/libdis.tex. ;) -Fred -- Fred L. Drake, Jr. <fdrake at beopen.com> BeOpen PythonLabs Team Member

1 0

OT: How to send CVS update mails?
by Peter Schneider-Kamp Aug. 21, 2000

Aug. 21, 2000

Sorry, but I cannot figure out how to make SourceForge send updates whenever there is a CVS commit (checkins mailing list). I need this for another project, so if someone remembers how to do this, please tell me. off-topic-and-terribly-sorri-ly y'rs Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de

4 3

gettext in the standard library
by bwarsaw＠beopen.com Aug. 21, 2000

Aug. 21, 2000

Apologies for duplicates to those of you already on python-dev... I've been working on merging all the various implementations of Python interfaces to the GNU gettext libraries. I've worked from code contributed by Martin, James, and Peter. I now have something that seems to work fairly well so I thought I'd update you all. After looking at all the various wizzy and experimental stuff in these implementations, I opted for simplicity, mostly just so I could get my head around what was needed. My goal was to build a fast C wrapper module around the C library, and to provide a pure Python implementation of an identical API for platforms without GNU gettext. I started with Martin's libintlmodule, renamed it _gettext and cleaned up the C code a bit. This provides gettext(), dgettext(), dcgettext(), textdomain(), and bindtextdomain() functions. The gettext.py module imports these, and if it succeeds, it's done. If that fails, then there's a bunch of code, mostly derived from Peter's fintl.py module, that reads the binary .mo files and does the look ups itself. Note that Peter's module only supported the GNU gettext binary format, and that's all mine does too. It should be easy to support other binary formats (Solaris?) by overriding one method in one class, and contributions are welcome. James's stuff looked cool too, what I grokked of it :) but I think those should be exported as higher level features. I didn't include the ability to write .mo files or the exported Catalog objects. I haven't used the I18N services enough to know whether these are useful. I added one convenience function, gettext.install(). If you call this, it inserts the gettext.gettext() function into the builtins namespace as `_'. You'll often want to do this, based on the I18N translatable strings marking conventions. Note that importing gettext does /not/ install by default! And since (I think) you'll almost always want to call bindtextdomain() and textdomain(), you can pass the domain and localedir in as arguments to install. Thus, the simple and quick usage pattern is: import gettext gettext.install('mydomain', '/my/locale/dir') print _('this is a localized message') I think it'll be easier to critique this stuff if I just check it in. Before I do, I still need to write up a test module and hack together docos. In the meantime, here's the module docstring for gettext.py. Talk amongst yourselves. :) -Barry """Internationalization and localization support. This module provides internationalization (I18N) and localization (L10N) support for your Python programs by providing an interface to the GNU gettext message catalog library. I18N refers to the operation by which a program is made aware of multiple languages. L10N refers to the adaptation of your program, once internationalized, to the local language and cultural habits. In order to provide multilingual messages for your Python programs, you need to take the following steps: - prepare your program by specially marking translatable strings - run a suite of tools over your marked program files to generate raw messages catalogs - create language specific translations of the message catalogs - use this module so that message strings are properly translated In order to prepare your program for I18N, you need to look at all the strings in your program. Any string that needs to be translated should be marked by wrapping it in _('...') -- i.e. a call to the function `_'. For example: filename = 'mylog.txt' message = _('writing a log message') fp = open(filename, 'w') fp.write(message) fp.close() In this example, the string `writing a log message' is marked as a candidate for translation, while the strings `mylog.txt' and `w' are not. The GNU gettext package provides a tool, called xgettext that scans C and C++ source code looking for these specially marked strings. xgettext generates what are called `.pot' files, essentially structured human readable files which contain every marked string in the source code. These .pot files are copied and handed over to translators who write language-specific versions for every supported language. For I18N Python programs however, xgettext won't work; it doesn't understand the myriad of string types support by Python. The standard Python distribution provides a tool called pygettext that does though (usually in the Tools/i18n directory). This is a command line script that supports a similar interface as xgettext; see its documentation for details. Once you've used pygettext to create your .pot files, you can use the standard GNU gettext tools to generate your machine-readable .mo files, which are what's used by this module and the GNU gettext libraries. In the simple case, to use this module then, you need only add the following bit of code to the main driver file of your application: import gettext gettext.install() This sets everything up so that your _('...') function calls Just Work. In other words, it installs `_' in the builtins namespace for convenience. You can skip this step and do it manually by the equivalent code: import gettext import __builtin__ __builtin__['_'] = gettext.gettext Once you've done this, you probably want to call bindtextdomain() and textdomain() to get the domain set up properly. Again, for convenience, you can pass the domain and localedir to install to set everything up in one fell swoop: import gettext gettext.install('mydomain', '/my/locale/dir') """

4 18

RE: compile.c: problem with duplicate argument bugfix
by Charles G Waldman Aug. 21, 2000

Aug. 21, 2000

I'm catching up on the python-dev archives and see your message. Note that I submitted a patch back in May to fix this same problem: http://www.python.org/pipermail/patches/2000-May/000638.html There you will find a working patch, and a detailed discussion which explains why your approach results in a core-dump. I submitted this patch back before Python moved over to SourceForge, there was a small amount of discussion about it and then the word from Guido was "I'm too busy to look at this now", and the patch got dropped on the floor.

2 1

Py_MakePendingCalls
by Tim Peters Aug. 21, 2000

Aug. 21, 2000

Does anyone ever call Py_MakePendingCalls? It's an undocumented entry point in ceval.c. I'd like to get rid of it. Guido sez: The only place I know that uses it was an old Macintosh module I once wrote to play sounds asynchronously. I created Py_MakePendingCalls() specifically for that purpose. It may be best to get rid of it. It's not best if anyone is using it despite its undocumented nature, but is best otherwise.

2 1

Re: [Python-Dev] ANN: BerkeleyDB 2.9.0 (experimental)
by Martin v. Loewis Aug. 21, 2000

Aug. 21, 2000

Hi Andrew, I just downloaded your new module, and found a few problems with it: - bsddb3.db.hashopen does not work, as Db() is called with no arguments; it expects at least one argument. The same holds for btopen and rnopen. - The Db() function should accept None as an argument (or no argument), as invoking db_create with a NULL environment creates a "standalone database". - Error recovery appears to be missing; I'm not sure whether this is the fault of the library or the fault of the module, though: >>> from bsddb3 import db >>> e=db.DbEnv() >>> e.open("/tmp/aaa",db.DB_CREATE) >>> d=db.Db(e) >>> d.open("foo",db.DB_HASH,db.DB_CREATE) Traceback (most recent call last): File "<stdin>", line 1, in ? _bsddb.error: (22, 'Das Argument ist ung\374ltig') >>> d.open("foo",db.DB_HASH,db.DB_CREATE) zsh: segmentation fault python BTW, I still don't know what argument exactly was invalid ... Regards, Martin

1 0

Call for reviewer!
by Tim Peters Aug. 21, 2000

Aug. 21, 2000

There are 5 open & related patches to getopt.py: 101106 thru 101110 inclusive. Who wants to review these? Fair warning in advance that Guido usually hates adding stuff to getopt, and the patch comment I examined the entire 1.6b1 tarball for incompatibilities, and found only 2 in 90+ modules using getopt.py. probably means it's dead on arrival (2+% is infinitely more than 0% <0.1 wink>). On that basis alone, my natural inclination is to reject them for lack of backward compatibility. So let's get some votes and see whether there's sufficient support to overcome that.

8 12

Re: os.path.commonprefix breakage
by Skip Montanaro Aug. 21, 2000

Aug. 21, 2000

>>>>> "Mark" == Mark Hammond <MarkH(a)ActiveState.com> writes: Mark> I believe that Skip recently made a patch to os.path.commonprefix Mark> to only return the portion of the common prefix that corresponds Mark> to a directory. Mark> I have just dicovered some code breakage from this change. On Mark> 1.5.2, the behaviour was: >>>> os.path.commonprefix(["../foo/bar", "../foo/spam"]) Mark> '../foo/' Mark> While since the change we have: Mark> '../foo' I'm sure it can be argued that the slash should be there. The previous behavior was clearly broken, however, because it was advancing character-by-character instead of directory-by-directory. Consequently, calling os.path.commonprefix(["/home/swen", "/home/swenson"]) would yield the most likely invalid path "/home/sw" as the common prefix. It would be easy enough to append the appropriate path separator to the the result before returning. I have no problem with that. Others with more knowledge of path semantics should chime in. Also, should the behavior be consistent across platforms or should it do what is correct for each platform on which it's implemented (dospath, ntpath, macpath)? Skip

10 33

ANN: BerkeleyDB 2.9.0 (experimental)
by A.M. Kuchling Aug. 20, 2000

Aug. 20, 2000

This is an experimental release of a rewritten version of the BerkeleyDB module by Robin Dunn. Starting from Greg Smith's version, which supports the 3.1.x versions of Sleepycat's DB library, I've translated the SWIG wrapper into hand-written C code. Warnings: this module is experimental, so don't put it to production use. I've only compiled the code with the current Python CVS tree; there might be glitches with 1.5.2 which will need to be fixed. Cursor objects are implemented, but completely untested; methods might not work or might dump core. (DB and DbEnv objects *are* tested, and seem to work fine.) Grab the code from this FTP directory: ftp://starship.python.net/pub/crew/amk/new/ Please report problems to me. Thanks! --amk

1 0