From master@89894.com Tue Feb 11 02:03:26 2003 From: master@89894.com (½Å¿ë ö) Date: Tue, 11 Feb 2003 11:03:26 +0900 Subject: [Catalog-sig] (no subject) Message-ID: <26250-2200322112326812@89894.com>
=C1=A4=BA=B8=C5=EB=BD=C5=BA=CE =B1=C7=B0=ED =BB=E7=C7=D7=BF=
=A1 =C0=C7=B0=C5 =C1=A6=B8=F1=BF=A1
[=B1=A4=B0=ED]=B6=F3=B0=ED =C7=A5=B1=E2=C7=D1 =B1=A4=B0=ED =B8=DE=C0=
=CF=C0=D4=B4=CF=B4=D9=2E
=BC=F6=BD=C5=C0=BB =BF=F8=C4=A1 =BE=CA=C0=B8=BD=
=C3=B8=E9
=
=BC=F6=BD=C5=B0=C5=BA=CE=B8=A6
=B4=AD=B7=AF=C1=D6=BC=BC=BF=E4
[=B0=FA=C7=D0] =B2=DE=C0=C7 =BF=A1=B3=CA=C1=F6 =B9=AB=C7=D1 =B5=BF= =B7=C2
=B9=AB=C7=D1 =B5=BF=B7=C2=C0=BA =B2=DE=C0=C7 =BF=A1=B3=CA=C1=F6=B0=A1 =BE=
=C6=B4=D2 =BC=F6 =BE=F8=BD=C0=B4=CF=B4=D9=2E=2E=2E=2E
=C8=AD=BC=AE =BF=AC=
=B7=E1=B8=A6 =BB=E7=BF=EB=C7=CF=C1=F6
=BE=CA=B0=ED,
=BF=AC=B7=E1=B0=A1=BE=F8=C0=CC =B5=B9=BE=C6=B0=A1=B4=C2 =
=BF=A3=C1=F8=C0=CC =C0=D6=B4=D9=B8=E9 =BF=A1=B3=CA=C1=F6=BF=A1=20
=B4=EB=C7=D1 =B9=AE=C1=A6=B4=C2 =B8=F0=B5=CE =C7=D8=B0=E1=B5=C9 =BC=F6 =C0=
=D6=B0=DA=C1=F6=BF=E4=2E
=C0=DA=B5=BF=C2=F7=B0=A1 =B1=E2=B8=A7=C0=CC =BE=
=F8=C0=CC =B4=DE=B8=B1
=BC=F6=C0=D6=B4=D9=B8=E9=2E=2E=2E=2E=2E?
=BF=AC=B7=E1=B8=A6 =BE=B2=C1=F6=
=BE=CA=B0=ED =B9=DF=C0=FC=B1=E2=BF=A1=BC=AD =B9=AB=C7=D1=C1=A4 =C0=FC=B1=E2=
=B0=A1=20
=B9=DF=BB=FD=B5=C8=B4=D9=B8=E9 =B1=D7 =BE=EE=B5=F0=BF=A1=BC=AD=B5=E7=C1=F6=
=C0=CE=B0=A3=C0=C7 =BB=EE=C0=BA =C7=B3=BF=E4=B7=CE=BF=EF=B0=CD=C0=CC=B8=E7=
,
=C8=AD=BC=AE =BF=AC=B7=E1=C0=C7 =B8=C5=BF=AC
=B0=F8=C7=D8=B9=AE=C1=A6=B4=C2 =B4=F5 =C0=CC=BB=F3=C0=C7 =BF=AC=B1=B8 =B4=EB=
=BB=F3=C0=CC =B5=C9 =BC=F6 =BE=F8=C0=B8=B8=E7=2E=2E=2E=2E=2E
=B1=D7=B7=AF=B3=AA =BE=D6=BC=AE =C7=CF=B0=D4=B5=B5 =BE=C6=C1=F7 =BF=EC=B8= =AE =C0=CE=B7=F9=B4=C2 =C0=CC =B9=AB=C7=D1 =B5=BF=B7=C2=C0=BB =B0=B3= =B9=DF=C0=BB =BC=BA=B0=F8 =C7=CF=C1=F6 =B8=F8=C7=DF=BD=C0=B4=CF=B4=D9=2E=2E=2E=2E=2E
=B8=B9=C0=BA =BB=E7=B6=F7=C0=CC =BF=A9=B1=E2=BF=A1 =B5=B5=C0=FC=C0=BB =C7=
=CF=B0=ED =C0=D6=C0=B8=B8=E7 =BC=BA=B0=F8=C0=C7 =B1=D7 =BC=F8=B0=A3 =
=C0=CE=B7=F9=C0=C7
=C7=E0=BA=B9=C0=CF=B0=CD=C0=D4=B4=CF=B4=D9=2E=2E=2E=2E
=C0=CE=B0=A3=C0=BA=
=C0=FA =B9=AB=C7=D1=C0=C7 =B0=F8=B0=A3=20
=BF=EC=C1=D6=B7=CE =BF=EC=C1=D6=B7=CE =B0=C5=C4=A7=BE=F8=C0=CC =B9=
=DF=C0=FC=C7=D8 =B3=AA=B0=A5 =B0=CD=C0=D4=B4=CF=B4=D9=2E=2E=2E
=C0=CC=B4=C2 =B0=F8=B0=A3 =C1=A6=C7=D1=C0=BB =B9=E7=C1=F6=BE=CA=B0=ED =BF= =A1=B3=CA=C1=F6=B8=A6 =B9=AB=C7=D1=BB=FD=BB=EA=C7=D2 =BC=F6 =C0=D6=B4=C2 =B9= =AB=C7=D1 =B5=BF=B7=C2=C0=CC =C0=D6=C0=BB =B0=E6=BF=EC=BF=A1=B8=B8 =B0=A1=B4=C9=C7=D1 =C0=CF=C0=D4=B4=CF=B4=D9=2E=2E= =2E
=BF=A9=B1=E2=BF=A1 =B0=ED=C1=A4 =BF=A1=B3=CA=C1=F6=B8=A6 =C0=CC=BF=EB=C7= =D1 =BF=A3=C1=F8=C0=BB 16=B3=E2=B0=A3=BF=A1=B0=C9=C3=C4 =B2=D9=C1=D8=C8=F7= =B0=B3=B9=DF=C7=CF=B0=ED=C0=D6=C0=B8=B8=E7 =C3=D6=B1=D9 5=B3=E2=BF=A9=B5=BF=BE=C8 6=C8=B8=BF=A1=B0=C9=C3=C4 =BA=CE=BA= =D0 =BA=CE=BA=D0=C0=BB =C1=A6=C0=DB=C7=CF=BF=A9 =B0=CB=C1=F5=C0=BB =C7=D8=BF= =C2=B9=D9=20 =C1=F6=B1=DD=C0=BA =BC=B3=B0=E8=B0=A1 =B8=B6=B9=AB=B8=AE=B5=C7=BE=EE =C1=BE= =C7=D5 =C0=FB=C0=CE =C1=A6=C0=DB =B0=FA=C1=A4=BF=A1 =BF=CD=C0=D6=C0=B8=B8=E7= ,
=BA=B8=B4=D9 =B8=B9=C0=BA =C0=CC =B5=E9=B7=CE=BA=CE=C5=CD =C7=D4=B2=B2 = =C7=CF=B0=ED=C0=DA =C4=AB=C6=E4 =BB=E7=C0=CC=C6=AE=B8=A6 =B0=B3=BC=B3=C7=CF= =BF=A9 =B5=BF=C8=A3=C0=CE=C0=C7 =B2=DE=C0=BB =B8=B8=B5=E9=BE=EE =B0=A1=B0=ED=C0=DA =C7=D5=B4=CF=B4=D9=2E=2E=2E
=C4=AB=C6=E4 =BB=E7=C0=CC=C6=AE : cafe=2Edaum=2Enet/106030 =C0=D4= =B4=CF=B4=D9=2E
=B8=B9=C0=CC =B9=E6=B9=AE=C7=CF=BD=C3=BE=EE =C0=DA=B7=E1 =B0=CB=BB=F6=C7= =CF=BD=C3=B0=ED =B6=C7 =B1=DB=C0=BB =B8=B9=C0=CC =BF=C3=B7=C1 =C1=D6=BC=BC= =BF=E4=2E=2E=2E=2E
^^ ** ^^ ^^ ** ^^
tel : 011-281-1434 =BD=C5 =BF=EB =C3=B6
section on pypi, although this would be usable if lines were shoved through textwrap.wrap() It would be benefitial to mandate certain trove classifiers, to make browsing usable on pypi (at the moment, about 75% of projects are implemented in no language whatsoever!) How about at least one of: Development Status :: * Environment :: * Intended Audience :: * License :: * Operating System :: * Programming Language :: * Topic :: * and possibly to complete the set of top level classifiers: Natural Language :: * (does this mean the language the docstrings are written in, or programs dealing with language processing?) -- Stuart Bishophttp://shangri-la.dropbear.id.au/ From stuart.b@commonground.com.au Thu Feb 27 03:45:58 2003 From: stuart.b@commonground.com.au (Stuart Bishop) Date: Thu, 27 Feb 2003 14:45:58 +1100 Subject: [Catalog-sig] More documentation for setup meta-data In-Reply-To: <200302271419.06949.rjones@ekit-inc.com> Message-ID: On Thursday, February 27, 2003, at 02:19 PM, Richard Jones wrote: > The current layout of the metadata on the release display page is ... > well, > it's a slightly refined version of a quick hack. It's the result of > competing > interests of getting something out there, and making it look pretty :) I think it more important getting the docs right for the Python 2.3 release and before the database gets too polluted. Making pypi render stuff correctly can be done whenever someone finds the time to deal with the bug report. > Unicode hadn't occurred to me. Any thoughts? I don't believe sqlite > can store > unicode, but we could probably work around that... If Unicode is supported, the trick would actually be to make sure that distutils and web forms submit the data in the correct encoding. I think adding a tag to the main template and making distutils do a foo.encode('utf8') on Unicode strings would be all that is required (and sqllite wouldn't know the difference). -- Stuart Bishop http://shangri-la.dropbear.id.au/ From rjones@ekit-inc.com Thu Feb 27 03:57:01 2003 From: rjones@ekit-inc.com (Richard Jones) Date: Thu, 27 Feb 2003 14:57:01 +1100 Subject: [Catalog-sig] More documentation for setup meta-data In-Reply-To: References: Message-ID: <200302271457.01068.rjones@ekit-inc.com> On Thu, 27 Feb 2003 2:45 pm, Stuart Bishop wrote: > If Unicode is supported, the trick would actually be to make sure that > distutils > and web forms submit the data in the correct encoding. I think adding > a > tag to the main template and making distutils do a foo.encode('utf8') on > Unicode strings would be all that is required (and sqllite wouldn't > know the > difference). As far as I can tell, unicode strings are coerced into ASCII when stored in sqlite. Richard From rjones@ekit-inc.com Thu Feb 27 03:19:06 2003 From: rjones@ekit-inc.com (Richard Jones) Date: Thu, 27 Feb 2003 14:19:06 +1100 Subject: [Catalog-sig] More documentation for setup meta-data In-Reply-To: <68E3A0DE-49FE-11D7-A92D-000393B63DDC@commonground.com.au> References: <68E3A0DE-49FE-11D7-A92D-000393B63DDC@commonground.com.au> Message-ID: <200302271419.06949.rjones@ekit-inc.com> On Thu, 27 Feb 2003 1:51 pm, Stuart Bishop wrote: > On Thursday, February 27, 2003, at 12:18 PM, Richard Jones wrote: > > I'm trying to better document the meta-data for the distutils (and > > hence > > PyPI). I've added words to the section in the dev doc about meta-data, > > and > > would like some feedback before I post the patch to be applied. Sorry, > > it's > > in LaTeX form (until someone writes the ReST->python doc converter ;) > > A patch was applied yesterday to dist.tex btw: > https://sourceforge.net/tracker/ > ?func=detail&atid=105470&aid=693474&group_id=5470 Note that python.org has an auto-forwarder set up to make sf references easier: http://www.python.org/sf/ > In particular, 'home_page' should be 'url' Huh. News to me :) > I think a definition of 'short string' and 'long string' are required: > - Are Unicode strings allowed? > - What formatting is allowed (eg. none whatsoever for short string, > and ReST for long string)? I think either ReST or an HTML subset > is required for the long description. It would suck if long > description > ended up in a section on pypi, although this would be usable if > lines were shoved through textwrap.wrap() The current layout of the metadata on the release display page is ... well, it's a slightly refined version of a quick hack. It's the result of competing interests of getting something out there, and making it look pretty :) Unicode hadn't occurred to me. Any thoughts? I don't believe sqlite can store unicode, but we could probably work around that... I think that ReST might be an option, but it's going to involve a bit of work hooking the parser/formatter into PyPI. Regardless, most long-description text will take to being ReST'ed just fine, since they're mostly all just paras. > It would be benefitial to mandate certain trove classifiers, to make > browsing > usable on pypi (at the moment, about 75% of projects are implemented in > no > language whatsoever!) +1 (there should be at least one of each top-level group specified) Note that in my modified documentation, the "platforms", "license" and "keywords" distutils meta-data are removed. I suspect that "license" must remain (to cope with oddities like the "Don't Bug Me Later License"). I don't believe we should promote the other two though. I realise that there will probably be disagreements about keywords ;) > (does this mean the language the docstrings are > written > in, or programs dealing with language > processing?) It's been pointed out (after I went live) that "Native Language" makes more sense. It's probably early enough days to make the change now. People who have already set up classifiers in their setup files will be annoyed though :( Richard From mal@lemburg.com Thu Feb 27 08:25:16 2003 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 27 Feb 2003 09:25:16 +0100 Subject: [Catalog-sig] Re: [Distutils] More documentation for setup meta-data In-Reply-To: <200302271218.46287.rjones@ekit-inc.com> References: <200302271218.46287.rjones@ekit-inc.com> Message-ID: <3E5DCB6C.9030008@lemburg.com> Richard Jones wrote: > I'm trying to better document the meta-data for the distutils (and hence > PyPI). I've added words to the section in the dev doc about meta-data, and > would like some feedback before I post the patch to be applied. Sorry, it's > in LaTeX form (until someone writes the ReST->python doc converter ;) > > \lineiii{download_url}{a location where the package may be > downloaded}{URL}{(3)} > \lineiii{classifiers}{a list of Trove classifiers}{list of strings}{(3)} > \end{tableiii} download_url is not a valid Distribution option (even though it is listed in the DistributionMetaData). I wonder why you mention it here. The concept of a single URL for downloads seems to simplistic to handle the issues involved with automatic installation. This information should also be provided in a lazy way, so that the package author can easily update the download links, e.g. by placing the information in an XML file on his site and then referencing this file in the distutils meta data. The file should then be parsed by a distutils subcommand to find the right download URL depending on the platform and Python version. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 27 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 33 days left EuroPython 2003, Charleroi, Belgium: 117 days left From lac@strakt.com Thu Feb 27 08:31:29 2003 From: lac@strakt.com (Laura Creighton) Date: Thu, 27 Feb 2003 09:31:29 +0100 Subject: [Catalog-sig] Re: [Distutils] More documentation for setup meta-data In-Reply-To: Message from "M.-A. Lemburg"of "Thu, 27 Feb 2003 09:25:16 +0100." <3E5DCB6C.9030008@lemburg.com> References: <200302271218.46287.rjones@ekit-inc.com> <3E5DCB6C.9030008@lemburg.com> Message-ID: <200302270831.h1R8VTjL028637@ratthing-b246.strakt.com> >The concept of a single URL for downloads seems to simplistic to >handle the issues involved with automatic installation. This >information should also be provided in a lazy way, so that the >package author can easily update the download links, e.g. by >placing the information in an XML file on his site and then >referencing this file in the distutils meta data. > >The file should then be parsed by a distutils subcommand to >find the right download URL depending on the platform and >Python version. > >-- >Marc-Andre Lemburg >eGenix.com > Will this make it possible to list multiple places where one can find software that is hosted more than one place? Seems desirable. Laura Creighton From mal@lemburg.com Thu Feb 27 10:00:56 2003 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 27 Feb 2003 11:00:56 +0100 Subject: [Catalog-sig] Re: [Distutils] More documentation for setup meta-data In-Reply-To: <200302270831.h1R8VTjL028637@ratthing-b246.strakt.com> References: <200302271218.46287.rjones@ekit-inc.com> <3E5DCB6C.9030008@lemburg.com> <200302270831.h1R8VTjL028637@ratthing-b246.strakt.com> Message-ID: <3E5DE1D8.5040505@lemburg.com> Laura Creighton wrote: >>The concept of a single URL for downloads seems too simplistic to >>handle the issues involved with automatic installation. This >>information should also be provided in a lazy way, so that the >>package author can easily update the download links, e.g. by >>placing the information in an XML file on his site and then >>referencing this file in the distutils meta data. >> >>The file should then be parsed by a distutils subcommand to >>find the right download URL depending on the platform and >>Python version. > > Will this make it possible to list multiple places where one can find > software that is hosted more than one place? Seems desirable. Right, that's the idea. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 27 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 33 days left EuroPython 2003, Charleroi, Belgium: 117 days left From rjones@ekit-inc.com Thu Feb 27 21:51:51 2003 From: rjones@ekit-inc.com (Richard Jones) Date: Fri, 28 Feb 2003 08:51:51 +1100 Subject: [Catalog-sig] Re: [Distutils] More documentation for setup meta-data In-Reply-To: <3E5DCB6C.9030008@lemburg.com> References: <200302271218.46287.rjones@ekit-inc.com> <3E5DCB6C.9030008@lemburg.com> Message-ID: <200302280851.52571.rjones@ekit-inc.com> On Thu, 27 Feb 2003 7:25 pm, M.-A. Lemburg wrote: > Richard Jones wrote: > > I'm trying to better document the meta-data for the distutils (and hence > > PyPI). I've added words to the section in the dev doc about meta-data, > > and would like some feedback before I post the patch to be applied. > > Sorry, it's in LaTeX form (until someone writes the ReST->python doc > > converter ;) > > > > \lineiii{download_url}{a location where the package may be > > downloaded}{URL}{(3)} > > \lineiii{classifiers}{a list of Trove classifiers}{list of > > strings}{(3)} \end{tableiii} > > download_url is not a valid Distribution option (even though it > is listed in the DistributionMetaData). I wonder why you mention > it here. It is new in 2.3 > The concept of a single URL for downloads seems to simplistic to > handle the issues involved with automatic installation. This > information should also be provided in a lazy way, so that the > package author can easily update the download links, e.g. by > placing the information in an XML file on his site and then > referencing this file in the distutils meta data. > > The file should then be parsed by a distutils subcommand to > find the right download URL depending on the platform and > Python version. This system sounds quite useful and flexible. It could also get very complicated, very quickly (for a package maintainer). The download_url may still be used for this purpose if it specifies a metadata file as the download. On the other hand, Anthony Baxter has written a distutils command that will download a specified package and install it. This was recently posted to distutils-sig "first cut at a distutils 'fetch' command". Sure, it's not an optimal solution - in the same way that PyPI is going to need tweaking over time once it's actually used. It's a start though. Note that I would like to see an alternative system that is used to disseminate packages which uses a set of mirrors similar to CPAN. There's an accepted naming system so that the package may be found just using the package name and version, and a fatch command that attempts to download the package from one or more of the mirrors (depending on availability). PyPI then supplies a list of the mirror sites. Distutils may also offer an upload command, to make life even easier for the package maintainer. No need to maintain download urls or even download sites. The kicker with this plan is the provision of the bandwidth. The other elements of it are ... well, trivial. They could be implemented before 2.3 is released. Richard From hpk@trillke.net Thu Feb 27 22:50:40 2003 From: hpk@trillke.net (holger krekel) Date: Thu, 27 Feb 2003 23:50:40 +0100 Subject: [Catalog-sig] Re: [Distutils] More documentation for setup meta-data In-Reply-To: <200302280851.52571.rjones@ekit-inc.com>; from rjones@ekit-inc.com on Fri, Feb 28, 2003 at 08:51:51AM +1100 References: <200302271218.46287.rjones@ekit-inc.com> <3E5DCB6C.9030008@lemburg.com> <200302280851.52571.rjones@ekit-inc.com> Message-ID: <20030227235040.O11666@prim.han.de> [Richard Jones Fri, Feb 28, 2003 at 08:51:51AM +1100] > Note that I would like to see an alternative system that is used to > disseminate packages which uses a set of mirrors similar to CPAN. There's an > accepted naming system so that the package may be found just using the > package name and version, and a fatch command that attempts to download the > package from one or more of the mirrors (depending on availability). PyPI > then supplies a list of the mirror sites. Distutils may also offer an upload > command, to make life even easier for the package maintainer. No need to > maintain download urls or even download sites. The kicker with this plan is > the provision of the bandwidth. The other elements of it are ... well, > trivial. They could be implemented before 2.3 is released. Maybe asking c.l.py subscribers for servers (with bandwidth) as mirrors for such a project would help. After all, python distutils-packages are usually not that big. And many people are longing for a way to upload/download packages semi-automatically. holger From mal@lemburg.com Fri Feb 28 16:22:04 2003 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 28 Feb 2003 17:22:04 +0100 Subject: [Catalog-sig] Re: [Distutils] More documentation for setup meta-data In-Reply-To: <200302280851.52571.rjones@ekit-inc.com> References: <200302271218.46287.rjones@ekit-inc.com> <3E5DCB6C.9030008@lemburg.com> <200302280851.52571.rjones@ekit-inc.com> Message-ID: <3E5F8CAC.8010000@lemburg.com> Richard Jones wrote: > On Thu, 27 Feb 2003 7:25 pm, M.-A. Lemburg wrote: > >>Richard Jones wrote: >> >>>I'm trying to better document the meta-data for the distutils (and hence >>>PyPI). I've added words to the section in the dev doc about meta-data, >>>and would like some feedback before I post the patch to be applied. >>>Sorry, it's in LaTeX form (until someone writes the ReST->python doc >>>converter ;) >>> >>> \lineiii{download_url}{a location where the package may be >>>downloaded}{URL}{(3)} >>> \lineiii{classifiers}{a list of Trove classifiers}{list of >>>strings}{(3)} \end{tableiii} >> >>download_url is not a valid Distribution option (even though it >>is listed in the DistributionMetaData). I wonder why you mention >>it here. > > It is new in 2.3 Uhm, it doesn't work in Python 2.3... that's why I was asking. >>The concept of a single URL for downloads seems to simplistic to >>handle the issues involved with automatic installation. This >>information should also be provided in a lazy way, so that the >>package author can easily update the download links, e.g. by >>placing the information in an XML file on his site and then >>referencing this file in the distutils meta data. >> >>The file should then be parsed by a distutils subcommand to >>find the right download URL depending on the platform and >>Python version. > > This system sounds quite useful and flexible. It could also get very > complicated, very quickly (for a package maintainer). The download_url may > still be used for this purpose if it specifies a metadata file as the > download. > > On the other hand, Anthony Baxter has written a distutils command that will > download a specified package and install it. This was recently posted to > distutils-sig "first cut at a distutils 'fetch' command". Sure, it's not an > optimal solution - in the same way that PyPI is going to need tweaking over > time once it's actually used. It's a start though. > > Note that I would like to see an alternative system that is used to > disseminate packages which uses a set of mirrors similar to CPAN. There's an > accepted naming system so that the package may be found just using the > package name and version, and a fatch command that attempts to download the > package from one or more of the mirrors (depending on availability). PyPI > then supplies a list of the mirror sites. Distutils may also offer an upload > command, to make life even easier for the package maintainer. No need to > maintain download urls or even download sites. The kicker with this plan is > the provision of the bandwidth. The other elements of it are ... well, > trivial. They could be implemented before 2.3 is released. If you intend to use the download_url for this purpose, then you ought to reserve it's usage for this now. Otherwise, people will simply put a link to the download web-site into this field. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 28 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2003, Oxford: 32 days left EuroPython 2003, Charleroi, Belgium: 116 days left