Re: Securely distributing python source code as an application?

[Tim Churches]

xkenneth wrote:
> Message should have read:
> Hi All,
> 
>  I'll shortly be distributing a number of python applications that
> use proprietary source code. The software is part of a much larger
> system and it
> will need to be distributed securely. How can i achieve this?

You need to define what you mean by "securely" by specifying what types
of threat you wish to protect against.

Tim C
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Web Ontology Language (OWL) parsing

[Tim Churches]

Sean Davis wrote:
> I would like to parse some OWL files, but I haven't dealt with OWL in
> python or any other language for that matter.  Some quick google
> searches do not turn up much in the way of possibilities for doing so
> in python.  Any suggestions of available code or using existing
> libraries for doing so?

I'm not sure whether it is still being maintained, but what about CWM,
by Sir Semantic Web himself: http://www.w3.org/2000/10/swap/doc/cwm.html

Tim C
(If it is written by a Tim it must be good.)

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Fast kNN from python

[Tim Churches]

Janto Dreijer wrote:
> I am looking for a Python implementation or bindings to a library that
> can quickly find k-Nearest Neighbors given an arbitrary distance
> metric between objects. Specifically, I have an "edit distance"
> between objects that is written in Python.

Orange? See http://www.ailab.si/orange/ - not sure about speed, but
quite a few parts of it are written in C, and it does kNN.

Tim C
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: how to implementation latent semantic indexing in python..

[Tim Churches]

Alex Martelli wrote:
> Tim Churches <[EMAIL PROTECTED]> wrote:
> 
>> malkarouri wrote:
>>> On 13 Jul, 17:18, 78ncp <[EMAIL PROTECTED]> wrote:
>>>> hi...
>>>> how to implementation algorithm latent semantic indexing in python
>>>> programming...??
>>> Of course you are aware that LSA is patented..
>> There is a US patent on it, sealed in 1989, but is it patented in any
>> other countries? There is no such thing as a "global patent" - patents
>> only cover the country which issues them. There is a global patent
>> application process (the Patent Co-operation Treaty), but that just
>> establishes a priority date for the invention in each country, but the
>> inventor still needs to file patent applications and have them approved
>> (sealed)  is each and every country. Did Bellcore do that back in the 1980s?
> 
> Aren't patents supposed to last 17 years, anyway?  A patent granted in
> 1989 should have expired in 2006, I believe (though IANAL, so...).

I thought that in the US utility patents (as opposed to plant and
circuit design patents) lasted for 20 years from the filing date, which
was 15th Sept 1988 for the patent in question
(http://www.google.com/patents?vid=USPAT4839853 ). But IANAL either.

Tim C

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: how to implementation latent semantic indexing in python..

[Tim Churches]

malkarouri wrote:
> On 13 Jul, 17:18, 78ncp <[EMAIL PROTECTED]> wrote:
>> hi...
>> how to implementation algorithm latent semantic indexing in python
>> programming...??
> 
> Of course you are aware that LSA is patented..

There is a US patent on it, sealed in 1989, but is it patented in any
other countries? There is no such thing as a "global patent" - patents
only cover the country which issues them. There is a global patent
application process (the Patent Co-operation Treaty), but that just
establishes a priority date for the invention in each country, but the
inventor still needs to file patent applications and have them approved
(sealed)  is each and every country. Did Bellcore do that back in the 1980s?

Tim C
-- 
http://mail.python.org/mailman/listinfo/python-list

Pythonic cats (and dogs?)

[Tim Churches]

A challenge: an elegant, parsimonious and more general[1] implementation of 
this, in Python: 

http://lol.ianloic.com/feed/www.planetpython.org/rss20.xml

Tim C

[1] Dogs, ponies, babies, politicians...
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Questions about mathematical and statistical functionality in Python

[Tim Churches]

Michael Hoffman wrote:
> Talbot Katz wrote:
> 
>> I hope you'll indulge an ignorant outsider.  I work at a financial 
>> software firm, and the tool I currently use for my research is R, a 
>> software environment for statistical computing and graphics.  R is 
>> designed with matrix manipulation in mind, and it's very easy to do 
>> regression and time series modeling, and to plot the results and test 
>> hypotheses.  The kinds of functionality we rely on the most are standard 
>> and robust versions of regression and principal component / factor 
>> analysis, bayesian methods such as Gibbs sampling and shrinkage, and 
>> optimization by linear, quadratic, newtonian / nonlinear, and genetic 
>> programming; frequently used graphics include QQ plots and histograms.  
>> In R, these procedures are all available as functions (some of them are 
>> in auxiliary libraries that don't come with the standard distribution, 
>> but are easily downloaded from a central repository).
> 
> I use both R and Python for my work. I think R is probably better for 
> most of the stuff you are mentioning. I do any sort of heavy 
> lifting--database queries/tabulation/aggregation in Python and load the 
> resulting data frames into R for analysis and graphics.

I would second that. It is not either/or. Use Python, including Numpy
and matplotlib and packages from SciPy, for some things, and R for
others. And you can even embed R in Python using RPy - see
http://rpy.sourceforge.net/

We use the combination of Python, Numpy (actually, the older Numeric
Python package, but soon to be converted to Numpy), RPy and R in our
NetEpi Analysis project - exploratory epidemiological analysis of large
data sets - see http://sourceforge.net/projects/netepi - and it is a
good combination - Python for the Web interface, data manipulation and
data heavy-lifting, and for some of the more elementary statistics, and
R for more involved statistical analysis and graphics (with teh option
of using matplotlib or other Python-based graphics packages for some
tasks if we wish). The main thing to remember, though, is that indexing
is zero-based in Python and 1-based in R...

Tim C
-- 
http://mail.python.org/mailman/listinfo/python-list

Flags of the world

[Tim Churches]

http://shaheeilyas.com/flags/

Scroll to the bottom to see why this is not entirely off-topic. Are
there other public examples in which Python has been used to harvest and
represent public information in useful and/or interesting ways? Ideas
for some more?

Tim C


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Anyone use PyPar (Python MPI implementation) recently?

[Tim Churches]

Ole Nielsen wrote:
> Cheers and thanks

Now that it is possible to purchase servers from tier-1 manufacturers
with dual quad-core processes (8 CPUs) for under $10k, complete with
discs and lots of RAM - that is, no tedious-to-set-up, space-occupying,
power-hungry and high-maintenance Beowulf-style cluster of commodity
boxes necessary - we are very keen to use PyPar to re-visit
parallelisation of our NetEpi epidemiological analysis code, but we are
aware that both our code and PyPar need to be updated to use NumPy as
opposed to the now deprecated Numeric Python. We still regard PyPar is
still the easiest-to-use wrapper for MPI for Python.

Tim C

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: HL7 servers in Python?

[Tim Churches]

Richard Low, MD wrote:
> Richard,
> 
> I was most impressed by your answer below (in '03)
> 
> Do you know whether there is a third party application/library that can
> interface our software to the HL7 sockets systems so we do not have to
> develop them?
> 
> If you do, which one would you recommend?
>
> Richard M. Low MD
> CEO
> 
> Infor-Med Corporation
> 6271 Variel Avenue, Suite A
> Woodland Hills, California 91367-2512, USA
> Phone:  818-592-2900
> Direct fax: (818)743-7759
> Email: <mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]
> URL:  <http://www.infor-med.com/>http://www.infor-med.com

I posed the original question back in 2003 which prompted Richard
Sharp's reply, and as far as I am aware, there is still no general
purpose HL7 2.x "server" written in Python. If that is still your
requirement, then you'll have to write one, but it is highly feasible.
We ended up writing our own, back in 2003, which met our specific need
of listening for incoming HL7 2.x messages of just a few specific types
using MLLP (HL7 minimum lower-level protocol), parsing and validating
them, writing the data as a transaction to a special purpose PostgreSQL
database and sending back an ACK. It is part of a public health
surveillance system described here:
http://www.biomedcentral.com/1471-2458/5/141

The code for our listener is available at
http://sourceforge.net/project/showfiles.php?group_id=123700&package_id=139062

Please note and observe the the open source license under which that
code is made available (it is a Mozilla license, so should not cause you
too many difficulties should you chose to make use of it, but do read
the license). At the very least examination of our code may give you
some ideas, although it is written for POSIX platforms and I note that
your company's products seem to be MS-Windows-based. The Python-based
solution has been relentlessly reliable in production use over the last
3 and a half years.

If you are looking for more general HL7 servers which use Python in some
respect but aren't necessarily written entirely in Python, then have a
look at Mirth - see http://www.mirthproject.org/ - which is an open
source HL7 messaging server which can use Python (or Jython) to script
rules and actions for incoming and outgoing messages, and Interfaceware,
whose  closed-source products also embed Python for scripting purposes -
see for example http://www.interfaceware.com/manual/ch-7-7-4.html

There may be others.

Hope this helps,

Tim C

> HL7 servers in Python?
> 
> Richard Sharp
> <mailto:python-list%40python.org?Subject=HL7%20servers%20in%20Python%3F&In-Reply-To=>rbsharp
> at gmx.de
> Mon Jun 16 17:29:22 CEST 2003
> 
>* Previous message:
> <http://mail.python.org/pipermail/python-list/2003-June/210414.html>"Structure
> and Interpretation of Computer Programs" in Python?
>* Next message:
> <http://mail.python.org/pipermail/python-list/2003-June/210188.html>HL7
> servers in Python?
>* Messages sorted by:
> <http://mail.python.org/pipermail/python-list/2003-June/date.html#210163>[
> date ]
> <http://mail.python.org/pipermail/python-list/2003-June/thread.html#210163>[
> thread ]
> <http://mail.python.org/pipermail/python-list/2003-June/subject.html#210163>[
> subject ]
> <http://mail.python.org/pipermail/python-list/2003-June/author.html#210163>[
> author ]
> 
> --
> 
> On Fri, 13 Jun 2003 07:10:26 +1000, Tim Churches wrote:
> 
>> Does anyone know of a Python HL7 socket server/daemon - that is, a
>> daemon which accepts socket connections on a TCP port from an HL7
>> source, receives an HL7 message via the connection, hands off the
>> message for processing, and then sends back an ACK or NACK H7 message -
>> usually synchronously, via a blocking connection (thus the server needs
>> to be multi-threaded)?
>>
>> HL7 stands for Health Level 7 (where 7 represents the 7th layer of the
>> OSI network stack) and is a widely-used standard for communication of
>> medical information. I'm not looking for HL7 message assembly or parsing
>> libraries, just the socket server bit. Perhaps the SocketServer module
>> in the Python library makes this so trivial that no-one has felt the
>> need to write a specific HL7 server in Python? Anyway, I've looked on
>> Google but can't spot anything obvious.
> 
> It is extremely doubtful, given the specialised nature of the question,
> whether most people understand what you want. Given that HL7 is really
> only sending and receiving some information in a curious format, and that
> you either receive data and then send the other side an ACK or a NAK, or
> wait until t

Re: Open Source Charting Tool

[Tim Churches]

A.M wrote:
> I can't browse to www.reporlab.org, but I found http://www.reportlab.com/ 
> which has a  commercial charting product. Is that what you referring to?

Typo in the URL. Try http://www.reportlab.org

You should also have a look at http://matplotlib.sourceforge.net/

Tim C
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: OLAP and pivot tables

[Tim Churches]

Ben Stroud wrote:
> George Sakkis wrote:
> 
>> After a brief search, I didn't find any python package related to OLAP
>> and pivot tables. Did I miss anything ? To be more precise, I'm not so
>> interested in a full-blown OLAP server with an RDBMS backend, but
>> rather a pythonic API for constructing datacubes in memory, slicing and
>> dicing them, drilling down or up dimensions and exposing them in some
>> suitable form to a presentation layer. I've hacked a first cut of a
>> pivot table implementation and an XHTML generator that produces
>> hierarchical html tables but it's not particularly general or easily
>> extensible so far. Is there any interest at all on a pythonic version
>> of something like JOLAP or XMLA ?
>>
> I'd be interested as well.  I posted a similar question to the ruby 
> mailing list a few months ago to no avail.  Ideally, someone much more 
> talented than myself would create a open OLAP library in C that could be 
> interfaced with dynamic languages easily (I ordered some OLAP books and 
> started in on this, and decided I was in over my head for now).  As far 
> as free software, all I've been able to find is java-based Mondrian.  
> Maybe it could serve as a reference implementation for someone.

The NetEpi Analysis project - see http://sourceforge.net/projects/netepi
, although not strictly an OLAP or datacube engine, might offer some of
the things you are looking for. It is intended for exploratory
epidemiological analysis of (potentially large) health-related datasets,
but should work with most types of data for which an OLAP engine would
be useful. Underneath there is a vertically-disaggregated,
ordinally-mapped, set-theoretic data selection and summarisation engine,
which is a pompous way of saying that it holds data column-wise in
memory-mapped Numpy (Numeric Python) arrays, and uses some fast
(custom-written) set functions on inverted indexes on the ordinal
positions of column values to select and summarise data (entirely at
run-time, cf most OLAP engines, which rely on a degree of
pre-summarisation along pre-chosen dimensions). It is all Python and
thus has a  Python(ic) API, including an SQL-like WHERE clause parser
for data selection (OK, SQL is not Pythonic, but that's just for data
subsetting). It includes quite a few statistical functions and nice
graphics courtesy of R (http://www.r-project.org) (which is embedded via
RPy - http://rpy.sourceforge.net/). Full support for missing values and
weighted datasets is provided (but not full support for survey data with
complex sample designs - that's forthcoming). Currently it works well
with datasets in the 5-10 million row range, but the basic design lends
itself easily to parallelisation if you have bigger datasets, and
preliminary work indicates good speed improvements - something we want
to pursue given all these multi-core CPUs which are now available at
reasonable cost. Be warned that NetEpi Analysis is currently only of
beta quality, and is a bit of a pig to install, on Linux/Unix/Mac OS X
only at present. We hope to be able to ready a production-ready Version
1.0 by the end of 2006, possibly with MS-Windows support as well.
However, the core data summarisation/subsetting engine is thought to be
sound (and there are some unit tests to attest to that).

Probably not quite what you were after but I thought it worth a mention.
Please post follow-ups, if any, to the NetEpi mailing list:
http://sourceforge.net/mail/?group_id=123700

Tim C





> 
> Cheers,
> Ben

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Software Needs Philosophers

[Tim Churches]

Xah Lee wrote:
> Software Needs Philosophers
> 
> by Steve Yegge, 2006-04-15.
> 
> Software needs philosophers.
> 
> People don't put much stock in philosophers these days. The popular
> impression of philosophy is that it's just rhetoric, just frivolous
> debating about stuff that can never properly be answered. “Spare me
> the philosophy; let's stick to the facts!”
> 
> The funny thing is, it's philosophers who gave us the ability to think
> rationally, to stick to the facts. If it weren't for the work of
> countless philosophers, facts would still be getting people tortured
> and killed for discovering and sharing them.

Paging Dr Mertz... (http://www.gnosis.cx)

Tim C
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Recommendations for a PostgreSQL db adapter, please?

[Tim Churches]

Gerhard Häring wrote:
> Keen Anthony wrote:
>>> Hello,
>>>
>>> I am currently using psycopg 2 as my db adapter for a mod_python & 
>>> PostgreSQL web app. It's works fine, and I haven't any complaints. I 
>>> would appreciate some input on what other pythonistas like in an 
>>> adapter. There were several different options available to me, but there 
>>> was no particular informed reason for me to choose psycopg. Am I missing 
>>> anything?
> 
> Considering pyPgSQL, psycopg1, PyGreSQL and psycopg2 - psycopg2 is a good
> choice.

Hmmm, Gerhard, you are listed as one of two developers for pyPgSQL on
SourceForge  ( http://sourceforge.net/projects/pypgsql/ ). The fact that
you are recommending a different DB adaptor project suggests a degree of
disengagement with pyPgSQL. Is Billy G. Allie still interested in
pyPgSQL, or is it now completely unloved? If so, then perhaps some new
maintainers can be found for it - several projects rely on pyPgSQL,
including ours ( http://sourceforge.net/projects/netepi/ )  - for which
we currently need to provide our own pyPgSQL tarball rolled from CVS
plus some of our own minor but important patches - which were submitted
for consideration but have not (AFAIK) been checked into the pyPgSQL
CVS. The latest tarball for pyPgSQl available from the pyPgSQL
SourceForge pages is dated 2003.

No criticism is intended in any of the foregoing observations - it is
inevitable that people move on to new projects (such as pySQLite), but
it would be a shame if pyPgSQL just rotted, because it has several
things in its favour, such as some unit tests (which were conspicuously
absent from any of the alternatives when we evaluated them in 2003 -
perhaps they have been added by now). Overall we have found pyPgSQL to
be very reliable.

Tim C

-- 
http://mail.python.org/mailman/listinfo/python-list

Link to Daily Python-URL from www.python.org?

[Tim Churches]

Am I correct in thinking that there is no longer any link from anywhere
on the Python Web site at http;//www.python.org to the Daily Python-URL
at http://www.pythonware.com/daily/ ? There is no sign of it on the
Community page, nor any reference to it at http://planet.python.org/

I'm sure there was a link to it last time I looked.

Tim C




-- 
http://mail.python.org/mailman/listinfo/python-list

Re: pyRTF and cells

[Tim Churches]

Raja Raman Sundararajan wrote:
> Hello,
> I have been playing around with pyRTF module for generating rtf
> documents.
> Its a very nice tool that fits my basic needs. However I have a problem
> controlling cells in
> a table.
> 
> I am not able to
> 1. do an align right of contents inside a cell
> 2. set backgroundcolor of a cell
> 3. I wonder if there is a property to set cell height (?)
> 
> Do you guys have any input on this?

Yes. The correct approach is to:

a) do a Google search on "RTF specification", find the latest version of
the RTF specs, and read through them to determine whether what you want
to do is supported by RTF itself. If it is, then:

b) Ask Simon Cusack, the author of PyRTF, whether PyRTF supports these
attributes or if not, the best way to go about adding support for them, or

c) just add the features yourself to PyRTF and send Simon a copy of your
modified code.

Cheers,

Tim C

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: MS word document generator

[Tim Churches]

Raja Raman Sundararajan wrote:
> Hello guys,
> Is there any nice library to generate word documents using Python.
> 
> As of today I am generating a HTML document and then open it with MS
> Word.
> But the problem is that I am not able to control the pages in the
> document and as a result of it the output looks terrible.
> 
> I have been using reportlab's platypus to generate PDF documents.
> Its a nice application which allows controlling segments of the pages
> programatically.
> 
> I was wondering if there was any library as reportlab to generate word
> documents.

How about PyRTF to generate Rich Text Format documents which MS-Word
will lap up? Thanks to the efforts of Simon Cusack (hi Simon).

See http://cheeseshop.python.org/pypi/PyRTF/0.45

Tim C

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Cheese Shop: some history for the new-comers

[Tim Churches]

A.M. Kuchling wrote:
> On Sat, 11 Mar 2006 16:50:26 +1100, 
>   richard <[EMAIL PROTECTED]> wrote:
>> So I did what people always do in this situation, I asked Barry Warsaw to
>> name. it. And he did, "Cheese Shop". I liked the name, so it was done. When
>> the new pydotorg machines went live last year, so too did the name
>> cheeseshop.python.org
> 
> Given the endless whiny complaints about the name,

I was just hoping that honour would be bestowed upon me for suggesting a
brilliant alternative name, but I sense it is not to be...oh well
(whistles tune to himself).

> though, I think we
> should just give up and go back to PyPI (pronounced 'Pippy').

Perusable Index of Packages for PYthon -> PIPPY (or PipPy if CamelCase
is preferred, or pippy...).

PyPi is doomed to be mispronounced pie-pie.

Anyway, thanks to Richard Jones for all his work on PyPI/Cheese Shop,
whining about the name notwithstanding.

Tim C

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Cheese Shop -> BSOL?

[Tim Churches]

Tim Churches wrote:
> Would it be possible to rename "Cheese Shop" as "Bright Side of Life"?
> 
> That's a cheery, upbeat name, there are overtones of commerce or filthy
> lucre, 

I meant "no overtones", mea culpa.

Tim C

-- 
http://mail.python.org/mailman/listinfo/python-list

Cheese Shop -> BSOL?

[Tim Churches]

Would it be possible to rename "Cheese Shop" as "Bright Side of Life"?

That's a cheery, upbeat name, there are overtones of commerce or filthy
lucre, it is a clear reference to one of the Monty Python crew's
greatest works, it can be easily abbreviated to BSOL (to avoid confusion
with BSL for blood sugar level, and to have some resonance with another
well-known Python acronym, BDFL), it is associated with a memorable
theme tune which, appropriately, reminds one to always look on the BSOL
(see http://www.geocities.com/fang_club/Bright_side_of_life.html for the
 lyrics), one can install an (ALOT)BSOL ringtone on your mobile (cell)
phone if one wishes like - see (or hear) for example
http://www.niksula.cs.hut.fi/~ajvaanan/p_80861/ , and it possesses a
certain irony just like the original Cheese Shop allusion.

So, BSOL instead of Cheese Shop? I am quite prepared to be crucified
(cheerfully) for this suggestion.

Tim C


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python Evangelism

[Tim Churches]

Benny wrote:
> Paul Boddie wrote:
> 
>> Bizarre names may be cute (to some people) but they don't lend
>> themselves to guessing or searching. Consequently, people who want
>> answers yesterday aren't likely to be amused to eventually discover
>> that the name of the resource they've been looking for is some opaque,
>> three-levels-of-indirection-via-irony, in-crowd joke. And even acronyms
>> like CPAN are better than wacky names, anyway.
> 
> To emphasize the point as a newbie: I know what CPAN is. I would go to 
> the Vaults of Parnassus for Python stuff. But Cheese Shop?

I like the irony of the name Cheese Shop, but I do think that there is a
problem with "Shop", as it typically means a place where you buy things
for money. However, the vast majority of the cheesy comestibles at the
Cheese Shop are available for free. In fact, of 1287 packages currently
listed there, only 7 have non-free or proprietary licenses. Actually, it
was the "National Cheese Emporium" in the original sketch, although Mr
Wensleydale does describe it as a cheese shop - but both "shop" and
"emporium" are used to describe places of commerce. On re-acquaintance,
the sketch itself is still very funny after all these years, except
perhaps for the ending, in which Mousebender shoots dead Mr Wensleydale
for deliberately wasting his time. In the early 1970s in Britain, when
shooters were possessed by a very small minority of blaggards, that
might have been funny, but in the early 21st century, I find it grates a
little (no pun intended) - I can imagine the same fate befalling a
latter-day Wensleydale in a different country who happens to be fresh
out of meira. But I am sure ESR would defend Mousebender's right to blow
poor Wensleydale away - see http://www.catb.org/~esr/guns/gun-ethics.html .

So is there an alternative Monty Python sketch which has a theme of
purveyance as opposed to commerce? None spring to mind.

Tim C




-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python Evangelism

[Tim Churches]

Kay Schluehr wrote:
> Magnus Lycka wrote:
> 
>> They do this on purpose in the U.S. A country full
>> of religious fanatics, where it's impossible to be
>> elected president unless you claim that you are a
>> devoted Christian and say "God bless America" every
>> time you open your mouth.
> 
> Maybe Pythonistas should make a cultural investment in emergent
> markets?
> 
> http://www.khandro.net/mysterious_naga.htm

I notice the above page mentions Glykon - see also
http://www.livius.org/gi-gr/glykon/glykon.html

I think that Glykon should be invited to be the sponsoring divinity for
PyCon next year. I hear that worship of pagan gods is, like everything
else, bigger in Texas.

Tim C


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python Evangelism

[Tim Churches]

Douglas Alan wrote:
> Ruby didn't start catching on until Ruby on Rails came out.  If Python
> has a naming problem, it's with the name of Django, rather than
> Python.  Firstly, Django doesn't have "Python" in the name, so it
> doesn't popularize the language behind it, even should Django become
> very popular.  Secondly, Django just doesn't have the ring of "Ruby on
> Rails".  They should change the name to "Blood Python" instead.  Okay,
> well, maybe not.  How about "Green Tree Python"?  Hmmm, kind of
> boring.  Well, maybe "Python on the Bullet Train"?  Okay, too
> derivative.  "Maglev Python"?  "Python with Panache"?  "Python on
> Prozac"?

How about Amethyst? As in "amethyst python" - see
http://www.stthomasschool.org/Classrooms/ausnz/AmPython.htm

Of course, although amethyst was originally considered a "cardinal gem"
alongside ruby, it no longer is since huge quantities were discovered in
Brazil - at least, that's what is says here:
http://www.answers.com/topic/gemstone-1

> I give up.  In any case, I'm sure Django was a great musician, but the
> product needs a better name to have any chance of displacing Rails.

I find the Django name tres cool and am considering changing the names
of two Python projects on which I am working to Thelonious and Miles.

Tim C

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python Evangelism

[Tim Churches]

Robert Boyd wrote:
> And re Cheeseshop, yes, it's a poor name when you consider that the
> point of the skit was that the cheeseshop _had no cheese_, whose only
> purpose was to "deliberately waste your time." Not a great name for a
> package library, especially for those in the know of Python humor!

"Cheese shop" is intended as a double irony, surely? I suppose some
cultures (and certain types of people, especially PHBs) are challenged
by single irony, let alone a double dose.

Tim C

-- 
http://mail.python.org/mailman/listinfo/python-list

Python and the health of the public

[Tim Churches]

The use of Python in a public health surveillance system is described
here (see references 15 and 26):
http://www.biomedcentral.com/1471-2458/5/141

Some more papers describing Python's starring role in some other public
health projects should appear in the next several months.

Tim C



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Re: Calling GPL code from a Python application

[Tim Churches]

Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> 
> On Wed, 04 Jan 2006 21:53:32 +1100, Tim Churches wrote:
> 
> >> Secondly, perhaps you should consider that dynamically linking to a
> >> work is creating a derivative work, which most certainly falls under
> >> the "modification" clause.
> 
> [snip]
> 
> > I am sorry, but dynamic linking at run-time does not, by any stretch 
> of
> > the imagination, correspond to the definition of "derivative work"
> > above.
> 
> I don't have to stretch my imagination even the tiniest bit to see why
> program Foo (consisting of code X linked to code Y) is obviously derived
> from program Bar consisting of code X on its own.

Steven,

My point is that it may well be obvious to *you* that dynamic linking 
constitutes derivative work, but from the way "derivative work" is 
explicitly defined in the GPL itself, it doesn't. Look at the language of the 
GPL:

Section 0.
The "Program", below, refers to any such program or work, and a 
"work based on the Program" means either the Program or any 
derivative work under copyright law: that is to say, a work containing 
the Program or a portion of it, either verbatim or with modifications 
and/or translated into another language.

The key verb is "containing", and I'm sorry, but "link" (or "reference" or 
"call" or whatever other verb could reasonably used to describe 
dynamic run-time linking) does not mean the same as "contain".

Tim C
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Calling GPL code from a Python application

[Tim Churches]

Mike Meyer wrote:
>> So is putting that program behind a web server and letting others
>>execute it.
> 
> That's pretty clearly a public performance. One has to wonder whether
> or not the exemption for program execution would apply to such? Of
> course, in cases where it matters (i.e. - I provide public access to
> my legally purchased copy of the Brittanica, or some such), copyrights
> on things other than the program come into play. Possibly multiple
> copyrights.

I agree that that is a public performance of the software, but teh GPL
allows that: once I again point out the clause in Section 0:

"The act of running the Program is not restricted, and the output from
the Program is covered only if its contents constitute a work based on
the Program (independent of having been made by running the Program)."

So in the vast majority of cases (unless the output constitues a "work
based on the Program"), you can place GPLed software on a Web server and
allow others to run that software.

Now, the FSF may regard this as a mistake on their part in including
these clauses in the GPL V2, but copyright holders who have licensed
their code under the GPL may not share that view. In fact, they may be
very pleased if their software is actually being used by third parties
through a Web server.

Tim C
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Calling GPL code from a Python application

[Tim Churches]

Steven D'Aprano wrote:
> On Wed, 04 Jan 2006 14:57:58 +1100, Tim Churches wrote:
> 
> 
>>Steven D'Aprano <[EMAIL PROTECTED]> wrote:
>>
>>>In particular:
>>>
>>>http://www.gnu.org/licenses/gpl-faq.html
>>>
>>>[quote]
>>>
>>>Q: If a library is released under the GPL (not the LGPL), does that mean
>>>that any program which uses it has to be under the GPL? 
>>>
>>>A: Yes, because the program as it is actually run includes the library. 
>>>
>>>[end quote]
>>
>>Yes, but the rather fundamental problem with the FSF position above being
>>the following words as contained in the GPL itself:
>>
>>Section 0., Para 1 (assuming zero-based paragraph numbering...): 
>>
>>"Activities other than copying, distribution and modification are not 
>>covered by this License; they are outside its scope. The act of running 
>>the Program is not restricted,..." 
>>
>>Sorry, but "Yes, because the program as it is actually run includes the
>>library." is incompatible with "Activities other than copying,
distribution
>>and modification are not covered by this License; they are outside its
scope.
>>The act of running the Program is not restricted."
> 
> Tim,
> 
> Firstly, perhaps you could use a mail/news client that correctly limits
> lines to (say) 72 characters, that would make it a lot easier to read your
> comments.

Sorry, was using the Optus webmail client which does not do line
wrapping - please complain to them.

> Secondly, perhaps you should consider that dynamically linking to a work
> is creating a derivative work, which most certainly falls under the
> "modification" clause.

Well, Section 0 of the GPL defines "derivative work" thus:

"The 'Program', below, refers to any such program or work, and a 'work
based on the Program' means either the Program or any derivative work
under copyright law: that is to say, a work containing the Program or a
portion of it, either verbatim or with modifications and/or translated
into another language. (Hereinafter, translation is included without
limitation in the term 'modification'.)

That is about as clear as it gets: as far as teh GPL is concerned, a
"derivative work" conatins the original Program or part of it, either
verbatim or with modifications and/or translated into another language.

I am sorry, but dynamic linking at run-time does not, by any stretch of
the imagination, correspond to the definition of "derivative work" above.

> Thirdly, I don't think it is particularly helpful for people to go hunting
> through licences -- whether the GPL or a restrictive, commercial,
> closed-source we-own-your-first-born licence -- looking for loop-holes.
> Not only is it immoral and unethical, but it is also dangerous: it is easy
> to think you have found a loop-hole only to discover that the judge
> disagrees.

It can also be argued that it is unethical to attempt to discourage the
use of useful GPLed software in settings where it can, in fact, be
legally used. Indeed, it is wrong to assume that copyright holders of
GPLed software don't want their code to be used through dynamic run-time
linking from other non-GPLed programmes (which may themselves be open
sourced under GPL-incompatible licenses, such as teh Mozilla license).
The best approach is to ask the copyright holder what their wishes are,
and failing that, to adopt a literal interpretation of the GPL itself.

Tim C
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Re: Calling GPL code from a Python application

[Tim Churches]

Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> In particular:
> 
> http://www.gnu.org/licenses/gpl-faq.html
> 
> [quote]
> 
> Q: If a library is released under the GPL (not the LGPL), does that mean
> that any program which uses it has to be under the GPL? 
> 
> A: Yes, because the program as it is actually run includes the library. 
> 
> [end quote]

Yes, but the rather fundamental problem with the FSF position above being the 
following words as contained in the GPL itself:

Section 0., Para 1 (assuming zero-based paragraph numbering...): 

"Activities other than copying, distribution and modification are not 
covered by this License; they are outside its scope. The act of running 
the Program is not restricted,..." 

Sorry, but "Yes, because the program as it is actually run includes the 
library." is incompatible with "Activities other than copying, distribution and 
modification are not covered by this License; they are outside its scope. The 
act of running the Program is not restricted."

Tim C

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Re: Calling GPL code from a Python application

[Tim Churches]

Mike Meyer <[EMAIL PROTECTED]> wrote:
> But in that case, you're going to need a real lawyer, so you might as
> well talk to one beforehand, and only try what they think you have a
> chance of getting in court.

This is excellent advice. We did, in fact, talk to a real lawyer, and paid him 
real money for his opinion, which I have paraphrased previously (in Feb 2005, 
search Google Groups).

Tim C
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Re: Calling GPL code from a Python application

[Tim Churches]

Mike Meyer <[EMAIL PROTECTED]> wrote:
> In
> particular, if I distribute an application that has to be dynamically
> linked with a GPL'ed library to run, I need to distribute my
> application under the terms of the GPL.

Mike,

Which section(s) of the GPL say(s) that, exactly? I mean, where is dynamic 
linking mentioned, or even implied? I can see where it says "derived from", but 
not where it says "dependent on at run-time".

Tim C
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Calling GPL code from a Python application

[Tim Churches]

Michel Sanner <[EMAIL PROTECTED]> wrote:
> One of the greatest feature of Python in my opinion is the way the 
> interpreter can be used to integrate a wide variety of
> software packages by dynamically linking them.  This approach has been 
> extremely successful for us so far but now I run
> into a license nightmare.
> 
> Some the libraries we wrapped using SWIG are under GPL but the 
> applications we are distributing are not (mainly because
> we are asked by funding agencies to keep track of users and hence ask 
> people to download the source from our site).

There was a long discussion of this issue on this list in Feb 2005 - do a 
search on Google Groups for that. The gist of my contribution to that 
discussion was that Section 0., Para 1 (assuming zero-based 
paragraph numbering...) of the GPL unequivocably says: 

"Activities other than copying, distribution and modification are not 
covered by this License; they are outside its scope. The act of running 
the Program is not restricted,..." 

Therefore if what you want to do does not involve copying, distribution or 
modification of GPLed code, then you are on safe ground and need not feel bad 
about not respecting the wishes of the licensors of the GPLed code in question. 
Our approach to thsi issue has been to instruct end users to obtain third party 
GPLed code from its original source, and to install both it and our non-GPLed 
code (it is Mozilla licensed) on their system. In that way what we are doing 
cannot possibly be construed as "copying, distributing or modifying" that 
third-party GPLed code. Rather, our code just calls it at run-time on the end 
user's system. Nevertheless, it is always good practice to ask their permission 
anyway. But if they refuse, ask them about the above clause in the GPL.

If using SWIG or other wrapping mechanisms, do be careful that you are not 
statically linking using header files or other GPLed API definition files as 
part of the wrapping process, and then distributin the linked object files. 
Some GPLed projects (eg the R statistical environment) license their API header 
files under a different license (the LGPL) in order to allow non-GPLed code to 
use the header files.

Of course, the GPL propogation provisions only apply if you (or anyone else) is 
distributing GPLed code to thrid parties. Thus, if your non-GPLed SWIG source 
code needs to use GPLed header files, there is nothing to stop you distributing 
your code to an end user, and then instructing the end user to download the 
GPLed coded needed by your non-GPLed code, and to then compile everything, all 
within teh confines of their system. Provided that the end results of this 
compilation are not then distributed to anyone else, then the GPL is not 
violated, not in letter nor in spirit.

It-pays-to-actually-read-the-GPL-before-you-distribute-your-code-under-it-ly 
yours,

Tim C
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: New Python chess module

[Tim Churches]

Will McGugan wrote:
> There is a new version if anyone is interested...
> 
> http://www.willmcgugan.com/chess.py
> 
> It contains optimizations and bugfixes.
> 
> Can anyone suggest a name for this module? pyChess is already taken...

Pyawn???

Tim C

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python logo

[Tim Churches]

Fredrik Lundh wrote:

>Tim Churches wrote:
>
>  
>
>>>>also, ahem, to certain aspects of the Python standard library.
>>>>
>>>>
>>>you've read the python style guide, I presume?
>>>
>>>http://www.python.org/peps/pep-0008.html
>>>  
>>>
>>A Foolish Consistency is the Hobgoblin of Little Minds.
>>--often ascribed to Ralph Waldo Emerson but
>>  in fact due to[1] G. van Rossum and B Warsaw.
>>
>>[1] The convention that quotes are ascribed to those who first used them
>>is, of course, a foolish consistency.
>>
>>
>
>in case you really got that backwards, I should probably point out that
>the style guide reference was in response to the "certain aspects of the
>python standard library" part of your post,  not the "emerson said this"
>part.
>  
>
I was indulging in the leg pulling which your reply invited, Fred. I 
think we both agree that the minor inconsistencies in various aspects of 
the Python standard library are of no consequence to anyone except the 
pathologically pedantic.

Tim C

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python logo

[Tim Churches]

Fredrik Lundh wrote:
> Tim Churches wrote:
> 
> 
>>PPS Emerson's assertion might well apply not just to Python logos, but
>>also, ahem, to certain aspects of the Python standard library.
> 
> 
> you've read the python style guide, I presume?
> 
> http://www.python.org/peps/pep-0008.html

A Foolish Consistency is the Hobgoblin of Little Minds.
 --often ascribed to Ralph Waldo Emerson but
   in fact due to[1] G. van Rossum and B Warsaw.

[1] The convention that quotes are ascribed to those who first used them
is, of course, a foolish consistency.

Tim C
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python logo

[Tim Churches]

Xah Lee wrote:

>i noticed that Python uses various logos:
>
>http://python.org/pics/pythonHi.gif
>http://python.org/pics/PyBanner038.gif
>http://python.org/pics/PyBanner037.gif
>http://python.org/pics/PythonPoweredSmall.gif
>http://wiki.python.org/pics/PyBanner057.gif
>
> is this some decision that python should use various different logos?
>
> Xah
> [EMAIL PROTECTED]
>∑ http://xahlee.org/
>
>  
>
"A foolish consistency is the hobgoblin of little minds."
  - Ralph Waldo Emerson

Tim C

PS Yes, I know that I shouldn't feed the trolls (or hobgoblins), but I 
invoke Screwtape's Defence: other people who should know better don't 
seem to be able to resist the temptation either...

PPS Emerson's assertion might well apply not just to Python logos, but 
also, ahem, to certain aspects of the Python standard library.

TC


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Robust statistics and optimmization from Python

[Tim Churches]

[EMAIL PROTECTED] wrote:
> Robert Kern wrote:
> 
> 
> 
>>If you find suitable
>>FORTRAN or C code that implements a particular "robust" algorithm, it
>>can probably wrapped for scipy relatively easily.
> 
> 
> An alternative would be to call R (a free statistical package) from
> Python, using something like the R/SPlus - Python Interface at
> http://www.omegahat.org/RSPython/ .

Unless you really want to call Python from R (as opposed to calling R
from Python), I strongly suggest that you use RPy (http://rpy.sf.net)
rather than RSPython. RPy is much easier to install and use and far less
buggy than RSPython.

> Many statistical algorithms,
> including those for robust statistics, have been implemented in R,
> usually by wrapping C or Fortran 77 code.

Yup, and if you really don't like the extra dependency or extra memory
requirements of R and RPy, it is often possible to port the R code back
to Python (or Numeric Python), with some effort.

Tim C

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: SAS Transport FIle

[Tim Churches]

Jeff wrote:
> Does anyone know of a python module to read a SAS Transport (XPORT)
> file?

I am not aware of any native Python module to read SAS portable
transport (XPORT) files (but that doesn't mean you shouldn't search for
one using Google etc). However, the format of the XPORT files is
publically available (see
http://support.sas.com/techsup/technote/ts140.html )and I would be happy
to help test such a module should you or anyone else care to write one.
Be aware that the XPORT file format harks back to the days when SAS was
only available on IBM mainframes, and teh specs contain some
peculiarities for a post-mainframe world, such as the use of IBM double
precision representation of floats (7 bits for the exponent and 56 bits
for the mantissa, whereas IEEE
format uses 11 bits for the exponent and 52 bits for the mantissa) -
thus you have to take additional care if you want to retain the full
precision expressible in the XPORT format.

There are alternative routes, though.

1) The foreign package (see
http://cran.r-project.org/doc/packages/foreign.pdf ) for the R
statistical system (see http://www.r-project.org) contains a function
read.xport which does as its name suggests. You can then use RPy (see
http://rpy.sf.net) to convert the resulting R data object(s) into Python
objects. Obviously you need to install R and RPy (and ideally Numeric
Python too) for this to work, but they are worth installing in their own
right. If your XPORT daatset is very large, then R/RPy may not be an
option, as R stores everything in memory.

2) Recent (within the last 6 years or so) versions of SAS come with an
XML engine, and it easy to export a SAS dataset to an XML file, which
would be easier to parse and convert into Python objects than teh SAS
XPORT file format, I dare say. The DTD used by SAS is also publicly
available (Google for it)

3) Recent versions of SAS also come with PROC EXPORT, which you can use
to dump you SAS dataset to a CSV or tab-delimited (or fixed format) text
file - but be careful with representation and precision issues. You can
write a SAS data step programme to accomplish the same thing in earlier
versions of SAS (in fact, that's all that PROC EXPORT does, behind the
scenes).

Tim C


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Cheese shop (was Re: python2.4/site-packages)

[Tim Churches]

Michael Hoffman wrote:

>Ben Finney wrote:
>
>  
>
>>Conversely, PyPI is a dull name with no obvious pronunciation, thus
>>difficult to remember; whereas Cheese Shop is a short phrase (that can
>>be translated), is easy to remember and has easy analogies to its
>>actual function.
>>
>>
>
>A place you visit where you can never find what you want?
>  
>
Indeed. A place completely uncontaminated by cheese: 
http://www.minderella.com/words/cheeseshop.htm

Tim C
-- 
http://mail.python.org/mailman/listinfo/python-list

Python-based system wins 2005 Australian Eureka Science Prize

[Tim Churches]

See
http://www.amonline.net.au/eureka/communications_technology/2005_winner.htm

A Google search on "scamseek python" reveals the nexus with Python - see
for example
http://www.cs.usyd.edu.au/~lkmrl/Scamseek-Project-data-mining-conf-v0.pdf

Congratulations to Prof Jon Patrick and team on their win, and for
choosing Python!

Tim C


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: When someone from Britain speaks, Americans hear a "British accent"...

[Tim Churches]

muldoon wrote:
> Americans consider having a "British accent" a sign of sophistication
> and high intelligence. Many companies hire salespersons from Britain to
> represent their products,etc. Question: When the British hear an
> "American accent," does it sound unsophisticated and dumb?
> 
> Be blunt. We Americans need to know. Should we try to change the way we
> speak? Are there certain words that sound particularly goofy? Please
> help us with your advice on this awkward matter.

To true Pythonistas, the only regional English accent which denotes
sophistication and high intelligence is the Dutch-English accent.

For those wishing to practice their faux-Dutch-English accent
(absolutely necessary  if you are to be taken seriously at any
Python-related gathering, no matter where in the world it is held),
some examples to emulate can be found here (needs Quicktime):

http://classweb.gmu.edu/accent/dutch0.html

and here:

http://www.itconversations.com/shows/detail545.html
http://www.itconversations.com/shows/detail559.html

Tim C


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A World Beyond Capitalism 2005, An Annual International Multiracial Alliance Building Peace Conference Is Accepting Proposals...

[Tim Churches]

Peter Hansen wrote:
> Jack Diederich wrote:
> 
>>The '.info' domain also defeats
>>the linux 'whois' command to dig for registrar info.
> 
> 
> Maybe so, but it's always pretty easy to Google for "whois" plus the 
> domain to find a way of doing it via the web, in this case with 
> http://www.afilias.info/cgi-bin/whois.cgi .
> 
> (It's registered to something called the Institute of Pamela, which 
> seems to stand for "Peaceful Alliances facilitated by Multilingual, 
> multiracial Education, handicapable outreach and native Language 
> Accessibility".  I think this thing really exists, making this spam and 
> not just a farce.)

It is not spam, it is actually on-topic for the Python list. If you read
through the message, you will see:

"Below are a few of the different groups that you can look forward to
seeing at the Grassroots Exhibition:

(Listed in Alphabetical order)
...
Opensource Technology Activist or user
Punk Music and Art
Python/computer activists
...
Wicca Activists"

Presumably the last-mentioned group writes code exclusively in hexadecimal.

One has to admire their goal (a world beyond capitalism), but given the
state of things in this post-end-of-history (as Francis Fukuyama put it
with an ugly flourish of triumphalism) world, I can't help thinking that
the Wicca activists are their best bet...

Tim C
-- 
http://mail.python.org/mailman/listinfo/python-list

ANN: Version 0.9 of NetEpi Case Manager

[Tim Churches]

Version 0.9 of NetEpi Case Manager is now available via
http://www.netepi.org

NetEpi Case Manager is a tool (built using Python, the Albatross Web
application framework for Python, and PostgreSQL) for securely
collecting structured information about cases and contacts of
communicable (and other) diseases of public health importance, through
Web browsers and the Internet.

New data collection forms can be designed and deployed quickly
by epidemiologists, using a Web browser 'point-and-click' interface,
without the need for knowledge of or training in any programming
language. Data can then be collected from authenticated users of the
system, who can be located anywhere in the world, into a centralised
database. All that is needed by users of the system is a relatively
recent Web browser and an Internet connection (“NetEpi” is short for
“Network-enabled Epidemiology”).

Development of NetEpi Case Manager has been motivated in large part by
the challenge of collecting rapidly changing data from many sources in
the event of an outbreak of an emerging communicable disease, such as
SARS and HPAI (highly pathogenic avian influenza). However, we hope that
it has utility in addressing other distributed, ad hoc data collection
problems in the public health and health care domains.

A list of prerequisites and installation notes are available at
http://sourceforge.net/docman/display_doc.php?docid=28865&group_id=123700

Version 0.9 incorporates a large number of improvements over previous
versions, including:

* simplification of and cosmetic improvements to the user interface and
  workflow - sample screenshots available
  at http://sourceforge.net/project/screenshots.php?group_id=123700;

* greater robustness and improved security;

* improved validation of field inputs;

* the ability to specify help pages (and images) for each question on
  a form;

* the ability to roll-forward data collected with previous versions of
  a form to the latest version;

* the ability to export contact as well as case information in a
  "flattened" format suitable for analysis and reporting;

* comprehensive end-user and administrator guides (the latter over 100
  pages long);

* additional installation options to allow easier customisation;

* much greater speed when deployed via FastCGI on the Web server;

* an initial suite of functional tests using the excellent open source
  Selenium web application test environment, as well as some  additional
  unit tests.

We welcome feedback (and bug reports) on this new release, as well as
contributions to future releases. Please contact us directly by email or
use the NetEpi mailing list (see
http://lists.sourceforge.net/lists/listinfo/netepi-discuss ).

We have a long list of additional features and potential improvements
which could be added to Case Manager, and we would be very happy to hear
from experienced Python programmers wishing to contribute to this work.
We would also be very happy to hear from anyone willing to do further
work on the documentation (using OpenOffice2), and from anyone willing
to write additional Selenium test scripts, either in the Selenese
scripting language or in Python via the Selenium "driven" mode (or more
Python unit tests, for that matter).

Tim Churches and Andrew McNamara
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python interest group software

[Tim Churches]

Skip Montanaro wrote:
> David> Is there already any software out there to manage a Python
> David> Interest Group? Something that can register users, take RSVPs for
> David> meetings, etc.
> 
> I suspect a fair number take advantage of meetup.com.

And a fair number of people now suspect meetup.com of taking advantage
of them, by introducing completely unreasonable fees (in relation to
what is offered in return) - see
http://slashdot.org/article.pl?sid=05/04/13/0359253&tid=187&tid=215&tid=98

Tim C

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python interest group software

[Tim Churches]

David Stanek wrote:
> Is there already any software out there to manage a Python Interest
> Group? Something that can register users, take RSVPs for meetings,
> etc.

I dare say that Roundup - http://roundup.sourceforge.net/ - (not to be
confused with Roundup - http://www.roundup.com/ ) - could be used
effectively for such purposes, since it provides both Web and email
interfaces for ad hoc interest groups. Not good for weedy types, though.

Tim C
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How do you drive-by-wire a car using Python ?

[Tim Churches]

[EMAIL PROTECTED] wrote:
> Hello everybody,
> 
> Our entry in the DARPA Grand Challenge race uses Python as a
> programming language. For those of you who are interested, we are
> beginning to put some of our code on our blog.

Here is a shot of a Pythonic DARPA Grand Challenge autonomous vehicle
pausing to do garbage collection:
http://www.shoalhaven.nsw.gov.au/council/sections/waste/images/garbage_truck_lifting_bin_1.jpg

Tim C


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: DIY Spam Filter in Python

[Tim Churches]

Peter Ballard wrote:
> I've no idea if this will be of any use to anyone. But since I've gone
> to the effort of writing it, I might as well make it publicly
> available...
> 
> Until last year, spam filtering was a source of frustration for me.
> Freeware packages I tried (specifically, spamassassin and dspam) were
> difficult to use. Custom rules using procmail were a pain.
> 
> Then I noticed that python came with email parsing capabilities in the
> email module. So I thought that maybe custom rules in python would be
> easier than (a) custom rules in procmail, or (b) deciphering the
> documentation of a package. And a lot more fun.
> 
> It turned out to be very easy. I got the filter up in a few evenings,
> and I've been using it successfully, and slowly enhancing it, over a
> number of months.
> 
> In short: a success story for "using the batteries" - at least in my
> opinion.
> 
> Source code, and a bit of documentation, is at:
> http://members.ozemail.com.au/~pballard/diyspamfilter.html
> 
> --
> Regards,
> 
> Peter Ballard
> Adelaide, AUSTRALIA
> http://members.ozemail.com.au/~pballard/

Pete mate,

Nice work, but your Web page on your DIY Spam Filter doesn't mention
SpamBayes, which is surely the definitive Pythonic spam filter, as well
as being eerily effective - see http://spambayes.sourceforge.net

Not sure that the Reverend Bayes would have agreed with your theology -
a bit too post-modern for him, no doubt, but he was nevertheless a
lovely little thinker.

Tim C
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: character-filtering and Word (& company)

[Tim Churches]

Charles Hartman wrote:
> I'm working on text-handling programs that want plain-text files as
> input. It's fine to tell users to feed the programs with plain-text
> only, but not all users know what this means, even after you explain it,
> or they forget. So it would be nice to be able to handle gracefully the
> stuff that MS Word (or any word-processor) puts into a file. Inserting a
> 0-127 filter is easy but not very friendly. Typically, the w.p. file
> loads OK (into a wx.StyledTextCtrl a.k.a Scintilla editing pane), and
> mostly be readable. Just a few characters will be wrong: "smart"
> quotation marks and the like.
> 
> Is there some well-known way to filter or translate this w.p. garbage? I
> don't know whether encodings are relevant; I don't know what encoding an
> MSW file uses. I don't see how to use s.translate() because I don't know
> how to predict what the incoming format will be.
> 
> Any hints welcome.

Antiword? See http://www.winfield.demon.nl/

OpenOffice driven via PyUNO interface?

Tim C
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: intrusive posts

[Tim Churches]

Charles Hartman wrote:
> 
> On Mar 23, 2005, at 7:10 PM, [EMAIL PROTECTED] wrote:
> 
>>7. (",) Do You Want To Know For Sure You Are Going To Heaven?
> 
> 
> Is there no way of filtering this recurring offensive material from the
> list?

Yes: http://spambayes.sourceforge.net/

Works a treat.

There once was a reverend called Bayes,
Who mooned in peculiar ways.
He'd show his prior
To any admirer,
But to see his posterior, you pays!

[Source: http://www.amstat.org/sections/spes/GRC2001/Limericks2001.htm ]

Tim C
-- 
http://mail.python.org/mailman/listinfo/python-list

Python limericks (was Re: Text-to-speech)

[Tim Churches]

Steve Holden wrote:
> Tim Churches wrote:
>> There once was a language called Python...
>>
>> (which is pretty close to having three anapaestic left feet)
>>
>> or more promisingly, rhyme-wise, but metrically rather worse :
>>
>> There once was a mathematician named van Rossum...
>>
>> Tim C
>>
> Of course this last suggestion clearly has the wrong meter for a good
> limerick. 

I did say it was metrically worse...

> Not everyone knows the ingredients of a good limerick, which
> led to the following (which has been around in various forms since God
> was a lad):
> 
> There was a young man from Japan
> Who never quite learned how to scan.
>   He got on quite fine
>   Until the last line
> And then somehow he could never quite get the number of syllables
> right,or make it rhyme.

This page on meta-limericks is worth a look:
http://www.kith.org/logos/words/lower/l.html

> So, let's accept that the first line should scan correctly, that would
> make the following first lines acceptable:
> 
> A mathematician named Guido ...
> The inventor of Python, called Guido ...
> A mathematician (van Rossum) ...
> Van Rossum, inventor of Python ...
> 
> Hopefully that will begin to get the idea across.

The Wikipaedia page on limericks is also worth reading:
http://en.wikipedia.org/wiki/Limericks

> Since it's PyCon week, I will offer a prize of $100 to the best (in my
> opinion) limerick about Python posted to this list (with a Cc: to
> [EMAIL PROTECTED]) before midday on Friday. The prize money will be my
> own, so there are no other rules. I will post my judgment when the PyCon
> nonsense has died down a little, but the winner will be read before the
> entire PyCon audience. Get to it!

My first attempt (which does not scan properly):

A Dutch mathematician most prophetic,
Did invent a language, name herpetic.
  With design quite intelligent,
  And syntax mostly elegant,
Big ideas could be made non-hypothetic.

Tim C


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Text-to-speech

[Tim Churches]

Charles Hartman wrote:
> Does anyone know of a cross-platform (OSX and Windows at least) library
> for text-to-speech? I know  there's an OSX API, and probably also for
> Windows. I know PyTTS exists, but it seems to talk only to the Windows
> engine. I'd like to write a single Python module to handle this on both
> platforms, but I guess I'm asking too much -- it's too hardware
> dependent, I suppose. Any hints?
> 
> Charles Hartman
> Professor of English, Poet in Residence
> http://cherry.conncoll.edu/cohar

No, but I do wonder how many other users of Python are
poets-in-residence, or indeed, published poets?

And congratulations on the release of Scandroid Version 1.0a (written in
Python) on 18.iii.05 (as you elegantly record it).

All this begs the question: Have any poems been written in Python
(similar to the well-known Perl Poetry (see
http://directory.google.com/Top/Computers/Programming/Languages/Perl/Poetry/
)?

Indeed, have any poems ever been written about Python - other than "The
Zen of Python" by Tim Peters? A limerick, even?

There once was a language called Python...

(which is pretty close to having three anapaestic left feet)

or more promisingly, rhyme-wise, but metrically rather worse :

There once was a mathematician named van Rossum...

Tim C

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Jigsaw solver

[Tim Churches]

[EMAIL PROTECTED] wrote:
Tim Churches wrote:
 

[EMAIL PROTECTED] wrote:
   

ObPuzzle: how did I "damage" the image?
 

You created a mirror image.
   

Damn. Too easy.
There is another explanation for the rapidity with which your brain 
teaser was solved, but modesty prevents me from mentioning it.

The system can be made resistant to that problem by only allowing
palindromic messages to be encoded, such as "Madam I am Adam.", 'Able was I ere I saw Elba." and "Named under a ban, a bared nude man."
   

Why couldn't they simply encode your input as a palindrome?
  Input: Mary had an aeroplane
Encoding: Mary has an aeroplaneenalporea na dah yraM
 

I should have been more precise and said "natural language palindrome", 
the rules for which promulgated by Martin Gardiner of Scientific 
American fame are that capitalisation, whitespace and punctuation are 
ignored and that each word must be a recognised  word or commonly used 
proper noun in the target language (and it must read the same forwards 
and backwards).

I wonder, do ideographic languages have palindromes?
No doubt it is patented to death by Xerox.
   

Has that ever stopped anybody?
 

Ask the Xerox legal department.
Tim C
--
http://mail.python.org/mailman/listinfo/python-list

Re: Jigsaw solver

[Tim Churches]

[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
 

This can be interesting:
http://science.slashdot.org/science/05/03/01/2340238.shtml
Bearophile
   

Hey, that DataGlyph demo works pretty neat.
 

...
Of course, being an old System Test Engineer whose job it
was to figure out how to break software, I couldn't let
this challenge go unanswered.
So, picking up the gauntlet, I broke it in 5 seconds.
 

...
Naturally, the real answer is none of the above.
And the damage can be undone in 5 seconds also.
And, under the right circumstances, an undamaged
DataGlyph could suffer the same fate (which also implies
that the damaged DataGlyph could be read under the
same circumstances).
ObPuzzle: how did I "damage" the image?
 

You created a mirror image.
The system can be made resistant to that problem by only allowing 
palindromic messages to be encoded, such as "Madam I am Adam.", 'Able 
was I ere I saw Elba." and "Named under a ban, a bared nude man."

Seriously, I am surprised that the Xerox demo does not try flipping the 
image around various axes. It would be trivial to add these  
transformations. Well, trivial to flip images along a few, obvious axes, 
but not along every possible axis.

What I want to know is whether any open source implementations of this 
technology are available. No doubt it is patented to death by Xerox.

Tim C
--
http://mail.python.org/mailman/listinfo/python-list

Re: Fuzzy matching of postal addresses

[Tim Churches]

McBooCzech wrote:
Sorry for my "Ferbl typo". 

No offense was caused, I was just joking.
For the local anti-smoking campaign 

As a public health epidemiologist, that's the sort of application of our 
project I like to see! And judging by the reports by Martin Mcgee and 
colleagues at the European Public Health Observatory, such campaigns are 
sorely needed in most of eastern Europe. I am sure Vaclav Havel is 
convinced of the need for anti-smoking campaigns.

I am
trying to link some addresses which contain following "linkable"
informations (data fields) only:
RECORD_ID, Street + No., City, Post code,
All data are now w/o Unicode characters. Do you think it possible to
try to link it with Febrl w/o deep code modification?
 

Yes.
I did try to link our data but the result is just a plenty of warning
messages but no links. What is your suggestion? Please understand I do
not want to bother you with my questions. I am just asking you your
comments or pointers before I will try to dig in to the code. You
probably know some "tricks" in data organization or something like
that, which can be much easier then code digging.
I can send our CSVs to you (they are small, just about 3204 records in
the A data-set and about 1241 records in the B data-set) and a log as
well.
I have tried to organized oru files as following:
  FEBRL reqirements : Our data
  ==
'rec_id': RECORD_ID,
'given_name': ""
   'surname': ""
'street_num': ""
'address_part_1': ""
'address_part_2': Street + No.
'suburb': City
  'postcode': Post code
 'state': ""
 'date_of_birth': ""
'soc_sec_id': ""
Thanks for your answer and suggestions
 

We would be pleased to assist - but off-list. Please send the exact text 
of the error messages (the log) directly to Peter Christen and myself in 
the first instance. Further discussion of these applictaon-specific 
issues is not appropriate for the general Python list - but you could 
report back to the Python list on your overall experience after we have 
solved the problems with you.

Regards,
Tim C
--
http://mail.python.org/mailman/listinfo/python-list

Re: Fuzzy matching of postal addresses

[Tim Churches]

McBooCzech wrote:
Tim,
do you think Ferbel can parse properly with non English data-sets?
The official name for the project is "Febrl" (freely-extensible 
biomedical record linkage) but perhaps "Furball" would be better name, 
given its focus on fuzziness (if that is not a contradiction in terms). 
My cat could cough up a suitable graphical logo, no doubt.

I
mean do you think it will work properly with data they include non
English characters as well? As we live in Europe, we have to solve such
a problems here : If the software needs some changes, I am ready,
according to your suggestions, to try to do it.
 

The underlying method (hidden Markov models) should work with any kind 
of data. If the non-English characters can be read as normal Python 
strings then it will definitely work. If you need to use Unicode 
strings, it may work, but that is not something we have tested - 
although it is on the TO-DO list. Peter Christen could comment further 
on that (off-line).  You would need to supply your own  tagging look-up 
tables of course, and bootstrap your own models as it unlikely that the 
sample models for Australian addresses will work well for Czech 
addresses. But none of that should be too hard.

Tim C
--
http://mail.python.org/mailman/listinfo/python-list

Re: SHA1 broken

[Tim Churches]

Paul Rubin  wrote:
> 
> FYI.
> >From :
> 
> The research team of Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu
> (mostly from Shandong University in China) have been quietly
> circulating a paper announcing their results:
> 
> * collisions in the the full SHA-1 in 2**69 hash operations, 
> much
>   less than the brute-force attack of 2**80 operations based on
>   the hash length.
> 
> * collisions in SHA-0 in 2**39 operations.
> 
> * collisions in 58-round SHA-1 in 2**33 operations.
> ...
> 
> This is the same group that broke MD5 a few months ago and so this is
> probably real.  It doesn't immediately turn everyone's applications
> inseecure (2**69 operations is still more than the 2**64 operations
> that it takes to break MD5 by brute force) and if it's like the MD5
> result, finds only free rather than targeted collisions.  So don't 
> panic.

Also, the new findings only apply to hash collisions, not to the invertibility 
of SHA1 
hashes - thus, as Schneier points out, uses of keyed hashes (such as HMAC) are 
not 
compromised by this.

Tim C

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Re: Big development in the GUI realm

[Tim Churches]

Courageous <[EMAIL PROTECTED]> wrote:
> 
> 
> >It should also be pointed out that the FSF's interpretation of the GPL
> >with respect to Qt means absolutely zero.
> 
> Indeed. It would be the court that would have to decide what the
> language of the GPL means, given the substantial body of case
> law as the court sees it.
> 
> 
> >... but it establishes that you *knew* what their interpretation ...
> 
> But it doesn't. They'd really need to put it into their license
> expressly.

Indeed. The GPL itself says:

"The precise terms and conditions for copying, distribution and modification 
follow.
...
END OF TERMS AND CONDITIONS"

It's what is between those sentences which counts when to comes to governing 
the 
use of the covered software. There is no mention of "And also see the FAQs on 
the 
GPL on the FSF Web site to understand what we really mean by the GPL."

Tim C

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Big development in the GUI realm

[Tim Churches]

Fredrik Lundh wrote:
Tim Churches wrote:
 

except that if *you* set things up so the code is combined when run, *you* are
copying, distributing, and/or modifying the program in order to mix, include 
and/or
combine your work with the GPL:ed work.
if you leave all that to the user, you're clear.
 

Yes, that is what I, and others, have been saying, and doing, all along. Our Mozilla Public 
Licensed Python application imports (but contains no code from) a GPLed third-party Python module 
at runtime, but we don't distribute that module, we just tell users to obtain it independently and 
install it on their systems.
   

does your program work (in any way) without this module?
 

Yes.
Tim C
--
http://mail.python.org/mailman/listinfo/python-list

Re: Big development in the GUI realm

[Tim Churches]

Fredrik Lundh wrote:
Tim Churches wrote:
 

and how exactly are you going to load a DLL from an EXE file with-
out "mixing, including, or combining" the two?
 

You can't, but as long as that "mixing, including, or combining" only occurs at 
runtime,
the GPL itself specifically says that is out of scope and the GPL does not 
apply. Their
words, not mine - to quote (yet again):
"Activities other than copying, distribution and modification are not covered by this
License; they are outside its scope. The act of running the Program is not restricted,..."
   

except that if *you* set things up so the code is combined when run, *you* 
are
copying, distributing, and/or modifying the program in order to mix, include 
and/or
combine your work with the GPL:ed work.
if you leave all that to the user, you're clear.
 

Yes, that is what I, and others, have been saying, and doing, all along. 
Our Mozilla Public Licensed Python application imports (but contains no 
code from) a GPLed third-party Python module at runtime, but we don't 
distribute that module, we just tell users to obtain it independently 
and install it on their systems.

(relying on word games is a lousy legal strategy in most parts of the world)
 

(Gee, I thought that word games were the entire basis of much legal 
endeavour in most parts of the world. Patent specifications in 
particular spring to mind.)

Less flippantly, I agree, and I find it Hanlonesque that the FSF 
continues to promote a license which is at best unclear and at worst 
completely contradictory on the issue of whether dynamic, runtime 
linking or calling does or doesn't fall under its scope. Others have 
thought the same - as we have seen, Linus Torvalds felt compelled to 
include an addition to the GPL when licensing the Linux kernel to make 
it crystal clear that making runtime system calls to the kernel did not 
fall under the scope of the kernel license.

I would urge anyone who has published a GPLed Python module to add a 
similar extension in order to clarify their use of the GPL in this regard.

Tim C
--
http://mail.python.org/mailman/listinfo/python-list

Re: Re: Big development in the GUI realm

[Tim Churches]

Luke Skywalker <[EMAIL PROTECTED]> wrote:
> 
> On Tue, 08 Feb 2005 13:24:35 +1100, Tim Churches
> <[EMAIL PROTECTED]> wrote:
> >: NOTE! This copyright does *not* cover user programs that use kernel
> >: services by normal system calls - this is merely considered normal 
> use
> >: of the kernel, and does *not* fall under the heading of "derived 
> work".
> 
> OK, so according to Linus, the GPL allows a proprietary program to
> make calls to the kernel, but TrollTech says the GPL doesn't allow a
> proprietary program to make calls to the Qt library.

No. Linus is providing a specific **extension** to the GPL which excludes calls 
to 
kernel services from the scope of the GPL. Whether he needs to do that is, as 
we 
have seen, debatable, but he is making the situation crystal clear.

Tim C
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Re: Big development in the GUI realm

[Tim Churches]

Luke Skywalker <[EMAIL PROTECTED]> wrote:
> 
> On Mon, 07 Feb 2005 17:47:30 -0800, Robert Kern <[EMAIL PROTECTED]>
> wrote:
> >Now, that's not to say that they are correct in their interpretation 
> of 
> >the GPL's terms. In fact, if I had to bet on an outcome, I'd probably 
> >wager that the court would hold that only static linking would force 
> the 
> >program as a whole to follow the GPL terms. However, I certainly don't 
> 
> >have the money to pony up to run a test case. Consequently, I try to 
> >follow the wishes of the copyright holder.
> 
> It's strange that something so central hasn't been clarified yet, but
> maybe it's part of the changes meant for V.3.
> 
> When you think about it, it'd be like banning any closed-source apps
> from being developed for Linux, since any application makes syscalls
> to the kernel and its libraries.
> 
> But the fact is that there are now closed-source apps for that
> platform, and are considered legit since those apps don't include code
> from the kernel, but instead, merely make calls to binary objects. I
> fail to see the difference between making calls to the kernel API and
> making calls to Qt libraries.

The COPYING file for the Linux kernel includes this note:

Linux main COPYING:

: NOTE! This copyright does *not* cover user programs that use kernel
: services by normal system calls - this is merely considered normal use
: of the kernel, and does *not* fall under the heading of "derived work".
: Also note that the GPL below is copyrighted by the Free Software
: Foundation, but the instance of code that it refers to (the Linux
: kernel) is copyrighted by me and others who actually wrote it.
:
: Also note that the only valid version of the GPL as far as the kernel
: is concerned is _this_ particular version of the license (ie v2, not
: v2.2 or v3.x or whatever), unless explicitly otherwise stated.
:
: Linus Torvalds

Tim C

> 
> Luke.
> -- 
> http://mail.python.org/mailman/listinfo/python-list
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Re: Big development in the GUI realm

[Tim Churches]

Luke Skywalker <[EMAIL PROTECTED]> wrote:
> 
> On Tue, 08 Feb 2005 10:47:25 +1100, Tim Churches
> <[EMAIL PROTECTED]> wrote:
> >So there you have it: there must be some portion of the GPLed Program 
> contained in 
> >the other work for it to fall under the scope of the GPL, and/or as 
> defined as a 
> >derivative work in local copyright law (local because the GPL does not 
> nominate a 
> >particular jurisdiction for covering law).
> 
> Has someone worked with Qt for Windows before, and could tell us
> whether it involves static or dynamic linking?
> 
> If dynamic, then, it doesn't make sense that an EXE that builds on Qt
> should also be GPLed.

Well you do need to consider whether any headers or declarations from the GPLed 
library need to be included in the source code of your non-GPLed programme - if 
so, 
then the latter also needs to be GPLed (if you distribute it to thers). There 
is also the 
issue of  whether you can directly include the names of the functions being 
called from 
the GPLed library (and the signatures of those functions) in your non-GPLed 
programme without your programme then being considered a derivative work. This 
comes back to the definition of derivative work, which I understands differs in 
different 
national copyright laws. One commonly adopted tactic is to write a 
dual-licensed 
wrapper around the GPLed library. I am unable to comment on whether that is a 
legally 
sound or morally justifiable strategy.

Tim C
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Re: Big development in the GUI realm

[Tim Churches]

Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> 
> Tim Churches wrote:
> 
> > Thus, it seems to me, and to the expert legal advice which we sought 
> (note the scope of the advice 
> > was Australian law only) that provided no GLPed source or object code 
> is mixed, included or 
> > combined with non-GPLed code
> 
> and how exactly are you going to load a DLL from an EXE file with-
> out "mixing, including, or combining" the two?

You can't, but as long as that "mixing, including, or combining" only occurs at 
runtime, 
the GPL itself specifically says that is out of scope and the GPL does not 
apply. Their 
words, not mine - to quote (yet again):

"Activities other than copying, distribution and modification are not covered 
by this 
License; they are outside its scope. The act of running the Program is not 
restricted,..."

No argument from me that combination of source code or static linking is 
covered by 
the GPL, but runtime(-only) linking of two programmes which do not share any 
code 
and which are distributed as clear separate packages would seem to be out of 
scope 
of the GPL. Note that deeming the making of runtime calls on a GPLed library 
as "modification" of that GPLed library would be drawing a very long bow 
indeed, given 
that elsewhere in the GPL it says (as included commentary):

"Thus, it is not the intent of this section to claim rights or contest your 
rights to work 
written entirely by you; rather, the intent is to exercise the right to control 
the 
distribution of derivative or collective works based on the Program."

Now, I concede that the use of the adjective "collective" in the above 
commentary does 
make things even less clear. However, Section 0 of the GPL specifically defines 
what 
is meant by "a work based on the {GPLed] Program", to wit:

"The 'Program', below, refers to any such program or work, and a 'work based on 
the 
Program' means either the Program or any derivative work under copyright law: 
that is 
to say, a work containing the Program or a portion of it, either verbatim or 
with 
modifications and/or translated into another language."

So there you have it: there must be some portion of the GPLed Program contained 
in 
the other work for it to fall under the scope of the GPL, and/or as defined as 
a 
derivative work in local copyright law (local because the GPL does not nominate 
a 
particular jurisdiction for covering law).

Clear as mud.

Tim C

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Big development in the GUI realm

[Tim Churches]

Fredrik Lundh wrote:
Luke Skywalker wrote:
 

Considering the fact that the Qt DLL exist by themselves, that the
version used is the one provided by Qt, and that the EXE uses a
standard, open way to communicate with it, the above does seem to say
this use would be valid.
   

   http://www.gnu.org/licenses/gpl-faq.html#MereAggregation
   "/.../ If modules are designed to run linked together in a shared address
   space, that almost surely means combining them into one program.
   By contrast, pipes, sockets and command-line arguments are
   communication mechanisms normally used between two separate
   programs. So when they are used for communication, the modules
   normally are separate programs. But if the semantics of the
   communication are intimate enough, exchanging complex internal
   data structures, that too could be a basis to consider the two parts
   as combined into a larger program."
 
 

Yes, that is what the FSF GPL FAQ says. However, the GPL itself says:
"[Section 0] Activities other than copying, distribution and 
modification are not covered by this License; they are outside its scope."

There is not, AFAICS, any formal definition of what is meant by 
"modification" in the GPL.

Section 2.b of the GPL says:
"b) You must cause any work that you distribute or publish, that in 
whole or in part contains or is derived from the Program or any part 
thereof, to be licensed as a whole at no charge to all third parties 
under the terms of this License."

and Section 2 goes on to say:
"These requirements apply to the modified work as a whole. If 
identifiable sections of that work are not derived from the Program, and 
can be reasonably considered independent and separate works in 
themselves, then this License, and its terms, do not apply to those 
sections when you distribute them as separate works. But when you 
distribute the same sections as part of a whole which is a work based on 
the Program, the distribution of the whole must be on the terms of this 
License, whose permissions for other licensees extend to the entire 
whole, and thus to each and every part regardless of who wrote it."

Thus, it seems to me, and to the expert legal advice which we sought 
(note the scope of the advice was Australian law only) that provided no 
GLPed source or object code is mixed, included or combined with 
non-GPLed code, and that the GPLed and non-GPLed code are distributed or 
otherwise made available in packages which are very clearly separate 
works, and that any interaction between the two is restricted to 
runtime, then the GPL does not require that non-GPLed code to be 
distributed under the GPL.

It is arguable whether that opinion is at odds with the sentiments 
expressed in the FSF GPL FAQ - it depends whether importing two python 
modules into the same namespace is considered equivalent to, as the FAQ 
says, "run linked together in a shared address space", but ultimately, 
it is what the GPL license text says, not what the FSF FAQ says, which 
matters.

Note that I am not in favour of or advocating any attempt to circumvent 
or undermine the GPL. I just think it is important to be guided by what 
software licenses actually say, rather than by what the authors of the 
licenses wished they had said in retrospect.

Tim C
--
http://mail.python.org/mailman/listinfo/python-list

Re: [Fwd: [gnu.org #220719] Re: python and gpl]

[Tim Churches]

Tim Churches wrote:
> Can't get much clearer than that.
Whoops! Sorry about all the embedded HTML links, making it most unclear. 
Here is the relevant Australian law in a clearer form:

 COPYRIGHT ACT 1968 (as amended by the Copyright Amendment Act
 2000) - SECT 47B
*Reproduction for normal use or study of computer programs*
(1)   Subject to subsection (2), the copyright  in a 
literary work  that is a computer program  is not infringed by the 
making of a reproduction of the work  if:
(a)   the reproduction  is incidentally and 
automatically made as part of the technical process of running a copy 
of the program for the purposes for which the program was designed; and
(b)   the running of the copy  is done by, or on 
behalf of, the owner or licensee of the copy .
(2)   Subsection (1) does not apply to the making of a 
reproduction of a computer program:
(a)   from an infringing copy of the computer 
program ; or
(b)   contrary to an express direction  or 
licence  given by, or on behalf of, the owner of the copyright in the 
computer program to the owner or licensee of the copy from which the 
reproduction is made when the owner or licensee of that copy acquired it.
I see no express directions or other provisions in the GPL which would 
invoke section 47(2). Indeed, the GPL says: "The act of running the 
Program is not restricted".

Tim C
--
http://mail.python.org/mailman/listinfo/python-list

Re: [Fwd: [gnu.org #220719] Re: python and gpl]

[Tim Churches]

Richard Brodie wrote:
"Tim Churches" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
 

1) In Australia and Europe at least, loading program code from disc into memory in
order to execute it is not considered as making an infringing copy under copyright law.
   

I don't think it's as clear cut as that. Sony won their modchip case in Britain
for exactly that reason. They lost in Australia and elsewhere in Europe.
 

In Australia, the following law applies:
***
 COPYRIGHT ACT 1968 (as amended by the Copyright Amendment Act
 2000) - SECT 47B
*Reproduction for normal use or study of computer programs*
(1)   Subject to subsection (2), the copyright 
<http://www.austlii.edu.au/au/legis/cth/consol_act/ca1968133/s10.html#copy> 
in a literary work 
<http://www.austlii.edu.au/au/legis/cth/consol_act/ca1968133/s189.html#literary_work> 
that is a computer program 
<http://www.austlii.edu.au/au/legis/cth/consol_act/ca1968133/s47ab.html#computer_program> 
is not infringed by the making of a reproduction 
<http://www.austlii.edu.au/au/legis/cth/consol_act/ca1968133/s47b.html#reproduction> 
of the work 
<http://www.austlii.edu.au/au/legis/cth/consol_act/ca1968133/s189.html#work> 
if:

(a)   the reproduction 
<http://www.austlii.edu.au/au/legis/cth/consol_act/ca1968133/s47b.html#reproduction> 
is incidentally and automatically made as part of the technical process 
of running a copy 
<http://www.austlii.edu.au/au/legis/cth/consol_act/ca1968133/s10.html#copy> 
of the program for the purposes for which the program was designed; and

(b)   the running of the copy 
<http://www.austlii.edu.au/au/legis/cth/consol_act/ca1968133/s10.html#copy> 
is done by, or on behalf of, the owner or licensee of the copy 
<http://www.austlii.edu.au/au/legis/cth/consol_act/ca1968133/s10.html#copy>. 

(2)   Subsection (1) does not apply to the making of a 
reproduction 
<http://www.austlii.edu.au/au/legis/cth/consol_act/ca1968133/s47b.html#reproduction> 
of a computer program 
<http://www.austlii.edu.au/au/legis/cth/consol_act/ca1968133/s47ab.html#computer_program>: 

(a)   from an infringing copy 
<http://www.austlii.edu.au/au/legis/cth/consol_act/ca1968133/s10.html#infringing_copy> 
of the computer 
<http://www.austlii.edu.au/au/legis/cth/consol_act/ca1968133/s47ab.html#computer_program> 
program 
<http://www.austlii.edu.au/au/legis/cth/consol_act/ca1968133/s47ab.html#computer_program>; 
or

(b)   contrary to an express direction 
<http://www.austlii.edu.au/au/legis/cth/consol_act/ca1968133/s248a.html#direct> 
or licence 
<http://www.austlii.edu.au/au/legis/cth/consol_act/ca1968133/s136.html#licence> 
given by, or on behalf of, the owner of the copyright 
<http://www.austlii.edu.au/au/legis/cth/consol_act/ca1968133/s10.html#copy> 
in the computer program 
<http://www.austlii.edu.au/au/legis/cth/consol_act/ca1968133/s47ab.html#computer_program> 
to the owner or licensee of the copy 
<http://www.austlii.edu.au/au/legis/cth/consol_act/ca1968133/s10.html#copy> 
from which the reproduction 
<http://www.austlii.edu.au/au/legis/cth/consol_act/ca1968133/s47b.html#reproduction> 
is made when the owner or licensee of that copy 
<http://www.austlii.edu.au/au/legis/cth/consol_act/ca1968133/s10.html#copy> 
acquired it.
***

Can't get much clearer than that. Furthermore, I see no express 
directions or other provisions in the GPL which would invoke section 
47(2). Indeed, the GPL says: "The act of running the Program is not 
restricted".

Tim C
--
http://mail.python.org/mailman/listinfo/python-list

Re: [Fwd: [gnu.org #220719] Re: python and gpl]

[Tim Churches]

Steve Holden <[EMAIL PROTECTED]> wrote:
> 
> In the absence of other information I Cc'd [EMAIL PROTECTED] to ask their 
> opinion about the relationship between GPL'd Python modules and 
> programs  that imported them
...
> > If a Python program imports a module licensed under the GPL, in your 
> > opinion does the Python program become a derivative work of the GPL'd 
> 
> > software?
> 
> Generally, yes.
> 
> -- 
> -Dave "Novalis" Turner
> GPL Compliance Engineer
> Free Software Foundation
> 
> So, there we have it, not a legal opinion but at least what a GPL 
> compliance engineer thinks. I must add, I can't remember when I saw a 
> dafter title.

Definitely not a legal opinion, which are characterised by an explanation of 
the logic 
and reasoning behind the opinion.

Perhaps you can ask the GPL Compliance Engineer how he responds to the 
following 
facts:

0) Section 0 of the GPL states: "Activities other than copying, distribution 
and 
modification are not covered by this License; they are outside its scope."

1) In Australia and Europe at least, loading program code from disc into memory 
in 
order to execute it is not considered as making an infringing copy under 
copyright law. 
Thus it is drawing a very long bow indeed to describe importing a third-party 
GPLed 
module at runtime as "copying" in these countries.

2) Importing a third-party GPLed Python module at runtime cannot be considered 
distribution, nor can it be considered modification, since the source or object 
code for 
that module is not being edited or modified.

Given these fatcs, under what possible interpretation (in Australia and Europe 
and 
probably elsewhere) can the act of importing a GPLed Python module at runtime 
be 
considered to fall under the scope of the GPL as set out in Section 0, quoted 
above?

See also this article, in which Lawrence Rosen, the attorney for OSI, admits 
that it is 
impossible for anyone to properly interpret the application of various open 
source 
licenses under the various national laws: 
http://www.devx.com/opensource/Article/27171 

I suspect that this issue applies equally to the FSF.

Tim C
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Re: python and gpl

[Tim Churches]

Paul Rubin <http://[EMAIL PROTECTED]> wrote:
> 
> Tim Churches <[EMAIL PROTECTED]> writes:
> > >The question is: does shipping a backend which imports a module that
> > > links with GPL code make some or all of the library GPL.
> > We sought formal legal advice on this issue from a lawyer with
> > expertise in open source licensing ...> 
> > The answer was that the GPL does not apply to combination of code at
> > run-time. Specifically, Section 0., Para 1 (assuming zero-based
> > paragraph numbering...) says:> 
> > "Activities other than copying, distribution and modification are not
> > covered by this License; they are outside its scope. The act of
> > running the Program is not restricted,..."
> 
> My IANAL amateur reading is that the GPL does in fact apply, at least
> in the US.  Running the program is not restricted, but loading the
> program from disk to memory before you can run it counts as copying
> it, which invokes the license, Computer Associates v. Altai, 982 F.2d
> 693.  I personally believe that doctrine is insane, but that's what
> software companies pushed through the courts in order to make
> shrink-wrap EULA's enforceable.  (Otherwise they'd only be enforceable
> if you agreed to the terms before the vendor got your money).

I can't comment on the situation in the US, but our advice made no reference to 
similar 
case law or interpretations under Australian law. However, even if what you say 
is true 
(that loading code from disk into memory is "copying"), it makes no difference, 
because the GPL copyleft licensing provisions only apply to copies which you 
give or 
make available to others. In other words, you can mix and match GPLed code and 
non-
GPLed code, in source code form, in object code form, or by runtime linking to 
your 
heart's content, provided you do so in teh privacy of your own organisation, 
and you 
are NOT obliged to distribute all the other code you mix together to others 
under the 
GPL. However, if you do distribute to others, it must be under the GPL. Runtime 
linking, importing or making function calls does not involve distribution to 
others. 

The so-called "viral" properties of the GPL - that by using GPLed code somehow 
your 
entire source code base will need to be made available to the entire world 
under the 
GPL - is just FUD perpetuated by certain large software companies and their 
fellow 
travellers. Sure, if you distribute your mixed GPL-and-other code to third 
parties then 
the whole lot has to be under the GPL, but the GPL does not force you to 
distribute it. 
So even if loading code into memory is copying (in the US), it isn't 
distributing to 
others.

> > Furthermore, Section 2 para 1 says: "These requirements apply to the
> > modified work as a whole. If identifiable sections of that work are
> > not derived from the Program, and can be reasonably considered
> > independent and separate works in themselves, then this License, and
> > its terms, do not apply to those sections when you distribute them
> > as separate works. ..."
> 
> That means you can run your separate program all by itself without
> needing to load the GPL module.

That test is just one interpretation of what that paragraph means. "Reasonably 
considered independent and separate works in themselves" can also be 
interpreted to 
mean that the source code is clearly identified as belonging to a separate 
work, and 
that the there is no mixing of sorce code between the two works.

However, in the case of our application, and in the case of Matplotlib, if I am 
not 
mistaken, that test is satisfied anyway.

> 
> > and Section 2 para 3 says:
> > 
> > "In addition, mere aggregation of another work not based on the
> > Program with the Program (or with a work based on the Program) on a
> > volume of a storage or distribution medium does not bring the other
> > work under the scope of this License."
> 
> That means the two programs have nothing to do with each other.

If the source code for work A does not contain a single line of the source code 
for 
application B, then it would seem reasonable to say that work A is not based on 
work 
B. However, work A can still call functions defined in work B at runtime, 
without "being 
based on it".

> > On the basis of these clauses, the legal advice to us was that merely
> > including "import rpy" and making calls to RPy-wrapped R functions
> > does not invoke the provisions of the GPL because these calls only
> > relate to run-time linking, which is not covered by the GPL. 
> 
> According to the FSF, it doesn't matter whether the linking is static
> or dynamic; the GPL applies to both c

Re: python and gpl

[Tim Churches]

John Hunter wrote:
I have a question about what it takes to trigger GPL restrictions in
python code which conditionally uses a GPL library.
Here is the context of my question.  matplotlib, which I develop, is a
plotting module which is distributed under a PSF compatible license,
and hence we avoid using GPLd code so as to not trigger the GPL
requirements.  matplotlib has rigid segregation between the front end
(plotting commands, figure objects, etc) and backends (gtk, wx, ps,
svg, etc).  The backend is chosen dynamically at runtime -- eg the
same python script could trigger the import gtk, wx, or ps, depending
an some rc settings or command line opts.
The question is: does shipping a backend which imports a module that
links with GPL code make some or all of the library GPL. 

We sought formal legal advice on this issue from a lawyer with expertise 
in open source licensing - in our case, our application which is 
licensed under a (very slightly) modifided version of the Mozilla Public 
License v1.1 imports a GPLed Python module (RPy) which wraps a GPLed 
library (R).

The answer was that the GPL does not apply to combination of code at 
run-time. Specifically, Section 0., Para 1 (assuming zero-based 
paragraph numbering...) says:

"Activities other than copying, distribution and modification are not 
covered by this License; they are outside its scope. The act of running 
the Program is not restricted,..."

Furthermore, Section 2 para 1 says:
"These requirements apply to the modified work as a whole. If 
identifiable sections of that work are not derived from the Program, and 
can be reasonably considered independent and separate works in 
themselves, then this License, and its terms, do not apply to those 
sections when you distribute them as separate works. ..."

and Section 2 para 3 says:
"In addition, mere aggregation of another work not based on the Program 
with the Program (or with a work based on the Program) on a volume of a 
storage or distribution medium does not bring the other work under the 
scope of this License."

On the basis of these clauses, the legal advice to us was that merely 
including "import rpy" and making calls to RPy-wrapped R functions does 
not invoke the provisions of the GPL because these calls only relate to 
run-time linking, which is not covered by the GPL. However, combining 
GPLed source code or static linking would invoke the GPL provisions. 
Additionally, we were advised to (re-)distribute any GPLed components 
required by our application in clearly separate packages i.e as separate 
tarballs or zip files, and not to bind them together in an omnibus 
distribution or installation file. However, putting them on the same 
CD-ROM or other media is fine.

Note that the formal advice was specific to Australian law, and did 
mention some Australian case law regarding fair use under the Copyright 
Act with respect to making API calls - that relates to our application 
making API calls to the GPLed library which is imported at runtime. The 
opinion was that we were on safe ground here, but you might want to 
investigate this aspect wrt copyright laws in other countries. My 
understanding is that most copyright law provides for "fair use" which 
may cover use of parts of an API to a GPLed library (as distinct from 
complete incorporation of the entire API into another application - 
which would invoke the GPL).

IANAL, and the above constitutes mangled paraphrasing of carefully 
worded formal legal advice, the scope of which was restricted to 
Australian law. However, the sections of the GPL quoted above are pretty 
unambiguous.

The other, informal advice, was to ignore the FAQs and other opinions on 
the FSF web site regarding intepretation of the GPL - it's only the 
license text which counts.

Tim C
--
http://mail.python.org/mailman/listinfo/python-list

Re: Re: Fuzzy matching of postal addresses

[Tim Churches]

Andrew McLean <[EMAIL PROTECTED]> wrote:
> 
> Thanks for all the suggestions. There were some really useful pointers.
> 
> A few random points:
> 
> 1. Spending money is not an option, this is a 'volunteer' project. I'll 
> try out some of the ideas over the weekend.
> ...
> I am tempted to try an approach based on splitting the address into a 
> sequence of normalised tokens. Then work with a metric based on the 
> differences between the sequences. The simple case would look at 
> deleting tokens and perhaps concatenating tokens to make a match.

Do please have a look at the Febrl project at http://febrl.sf.net

We would be most interested to learn how well its HMM address parser works well 
for 
all those "quaint" English addresses, and its Fellegi-Sunter probabilistic 
matching 
engine should give good results on your data (or use the simpler deterministic 
engine if 
you like). Provided that your data are not too large (eg more than a few 
hundred 
thousand records), Febrl should work fairly well. We'd be pleased to get any 
feedback 
you may have.

Tim C
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Fuzzy matching of postal addresses

[Tim Churches]

 Andrew McLean <[EMAIL PROTECTED]> wrote:
> I have a problem that is suspect isn't unusual and I'm looking to 
> see if there is any code available to help. I've Googled without success.
>
> Basically, I have two databases containing lists of postal addresses and 
> need to look for matching addresses in the two databases. More 
> precisely, for each address in database A I want to find a single 
> matching address in database B.

Have a look at http://febrl.sf.net

It is a prototype probabilistic record linkage (fuzzy matching) engine, in 
Python, which 
includes, inter alia, a hidden Markov model address parser. It might be 
overkill or (at 
this stage of its development) too slow for your application. The next version 
(ina 
month or two) will include a geocoding engine which could also be used for what 
you 
want to do, I suspect.

Tim C

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: hash patent by AltNet; Python is prior art?

[Tim Churches]

GerritM wrote:
ZDnet features an article about the had patent at AltNet
http://news.zdnet.com/2100-9588_22-5534087.html . Apparantly this issue
plays already for some time, now the p2p companies are threatened, becuase
they use hashing to recognize files.
I find it incredibly annoying when journalists reporting on patent 
issues don't bother to quote the patent numbers (or patent application 
numbers) concerned (failure to do so probably means they haven't 
bothered to examine the patent or patent application themselves). In 
this case, a search is made doubly difficult because the patent was 
purchased from someone else, so a name serach can't be done. A quick 
keyworfd search on the USPTO web site revealed some related patents 
issued to Apple and Sony, but hard to identify this particular patent.

As far as I know hasing is a very old technique used to quickly look up
information. The use of hashing always requires an idnetity check, because
the lookup is not unique (mapping a very big amount of possibilities on a
limited amount of entries). This is a fast and robust way of finding
information, if the right hashing function is used.
How can this type of fundamental knowledge be patented? I am afraid this is
again an example of a total failure of the current patent system.
Unfortunately these ridiculous examples endanger smaller companies, open
software activities amd innovation in general.
What you have to remember is that the US (and some countries which have 
been stupid enough to follow its lead, like Japan, Australia and now it 
seems India) permits patents not just on software algorithms and 
techniques, but also on business methods. Thus the "novel" application 
of a well-known and widely-used technique such as hashing to a 
particular field of endeavour (like file sharing on the Internet) can be 
patented (in the US). To be novel, there must be no published prior art 
- but the prior art needs to be specific to the claims of the patent. So 
if the patent says "use of hashing to uniquely identify files in a 
peer-to-peer network via IP over the Internet", then the prior art needs 
to describe exactly that. The Australian government recently passed 
legislation which tightened this test of novelty (thank goodness) by 
allowing separate bits of prior art which describe aspects of a patent 
claim to be combined to some degree when opposing a patent - but the 
test for novelty remains remarkably lax in the US, I beleive.

And I agree 100% with Alex Martelli - Europe and other countries must 
reject software, algorithmic and business method patents and thus create 
a powerhouse of innovation. let the US and fellow-travellers stew in 
their own juice - they will become powerhouses of litigation instead. 
Provided other countries don't recognise software and business method 
patents, the litigation will be confined within US borders, where 
resources can be productivelt spent making television dramas about 
attractive young patent attorneys and plodding, tram-riding patent 
clerks who are really brilliant physicists if only someone would 
recognise their potential. So yes, please write to your MP and MEP and 
protest against the prospect of software and business method patents in 
Europe. Hopefully one day within my lifetime we'll have a governemt here 
in Australia which will roll back the damage done to our patent system 
by trying to make just like the US system, just so we can conclude an 
unbelieveably inequitable free trade agreement with the US. But that's 
our problem.

Tim C
--
http://mail.python.org/mailman/listinfo/python-list

Re: Re: Python.org, Website of Satan

[Tim Churches]

TimC <[EMAIL PROTECTED]> wrote:
> 
> Writing code that has to be indented *exactly* or it just won't
> work. I bet they all use eVIl VI too.
> 
> -- 
> TimC -- http://astronomy.swin.edu.au/staff/tconnors/

Hey, two (real, actual) TimCs from the same country posting to the same list on 
the 
same stupid topic...

TimC
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python.org, Website of Satan

[Tim Churches]

[EMAIL PROTECTED] wrote:
> 
> python.org = 194.109.137.226
> 
> 194 + 109 + 137 + 226 = 666
> 
> What is this website with such a demonic name and IP address?  What
> evils are the programmers who use this language up to?

More evidence of Beelzebub at work: GUIDO VAN ROSSUM is an anagram of 
SAVIOUR MUD SONG - besmirching the name of our Lord through filthy canticles!

Tim C
-- 
http://mail.python.org/mailman/listinfo/python-list

Python and Tsunami Warning Systems

[Tim Churches]

Boc Cringely's column on the need for a grassroots (seaweed roots?) 
tsunami warning system for the Indian Ocean (and elsewhere) makes some 
very good points - see 
http://www.pbs.org/cringely/pulpit/pulpit20041230.html

In his following column ( 
http://www.pbs.org/cringely/pulpit/pulpit20050107.html ), he notes:

"Now to last week's column about tsunamis and tsunami warning systems. 
While my idea may have set many people to work, only a couple of them 
have been telling me about it. Developer Charles R. Martin and Canadian 
earth scientist Darren Griffith met through this column, and are in the 
initial stages of building an Open Tsunami Alerting System (OTAS). 
Although work has just started, they've established a few basic 
principles: OTAS will be very lightweight; will use openly available 
geophysical or seismic data sources; will be highly distributed and 
decentralized; and will be built to run on very low-powered commodity 
hardware. They currently foresee using Python and Java, but aren't 
religious about it. Anyone who wants to help out is welcome and their 
OTAS blog can be found in this week's links."

See http://otasblog.blogspot.com/
It seems to me that this would be a valuable and feasible type of 
project for the Python community to get involved in (or perhaps take the 
lead on). Something the PSF might even consider resourcing to some degree?

Tim C
--
http://mail.python.org/mailman/listinfo/python-list

Re: Dr. Dobb's Python-URL! - weekly Python news and links (Jan 9)

[Tim Churches]

Josiah Carlson wrote:
QOTW:  Jim Fulton: "[What's] duck typing?"
Andrew Koenig: "That's the Australian pronunciation of 'duct taping'."
I must protest.
1) No (true-blue) Australian has every uttered the words 'duct taping', 
because Aussies (and Pommies) know that the universe is held together 
with gaffer tape, not duct tape. See http://www.exposure.co.uk/eejit/gaffer/
b) If an Australian were ever induced to utter the words 'duct typing', 
the typical Strine (see 
http://www.geocities.com/jendi2_2000/strine1.html ) pronunciation would 
be more like 'duh toypn' - the underlying principle being one of 
elimination of all unnecessary syllables, vowels and consonants, thus 
eliminating the need to move the lips (which reduces effort and stops 
flies getting in).

Tim C
Sydney, Australia
--
http://mail.python.org/mailman/listinfo/python-list

Re: How can engineers not understand source-code control?

[Tim Churches]

Cameron Laird wrote:
I've seen the infatuation for Excel (and so on) for years, but
never found it at all tempting myself.  I mostly just ignore the
issue--no, actually, I guess I give them Excel, but show at the
same time that they really want the alternative views that I
also provide.
See http://www.burns-stat.com/pages/Tutor/spreadsheet_addiction.html for 
 a thoughtful essay by a statistician on this affliction. I think that 
Python would be an excellent addition to his Treatment Centre pharmacopoeia.

Tim C
--
http://mail.python.org/mailman/listinfo/python-list

Re: Frameworks for "Non-Content Oriented Web Apps"

[Tim Churches]

[EMAIL PROTECTED] wrote:
Hi,
There are great Python Web Application Framework. But most of them are
meant for content oriented web apps.
Is there something that can ease the development of application that
are not content oriented(I call them "NON CONTENT-ORIENTED WEB
APPLICATIONS" because I don't know what else to call them). I mean the
applications like, accounting,  high volume data entry apps,  where
normally GUI clients have ruled. I know very high quality ERP and
similar packages have been implemented in a web based environment. But
problem is that they have been developed with the tools that were
actually meant for content oriented apps like Zope, PHP, etc.
Can you give some URL for publicly accessible examples of what you mean 
by a "NON CONTENT-ORIENTED WEB APPLICATIONS", so we can get a better 
idea of what you mean?

Tim C
--
http://mail.python.org/mailman/listinfo/python-list

ANN: NetEpi (pre-alpha) - tools for epidemiology and public health

[Tim Churches]

Pre-alpha versions of several Pythonic tools for epidemiology and public 
health practice are now available under a slightly modified version of 
the Mozilla Public License - see http://www.netepi.org for further 
details. Some screenshots and copies of README files and end-user 
documentation are available from the project page on SourceForge (follow 
the link on the above page).

Development of these tools was motivated by concerns over bioterrorism, 
and by the global SARS outbreak in early 2003, but they have a wide 
range of potential uses in population health epidemiology, in disease 
outbreak investigation and management, and in other areas of public 
health practice (including management of public health problems in 
post-disaster situtaions).

Currently the tools are functional but lack important features and 
require more testing (and more unit and functional tests) before they 
can be used routinely. It is hoped the the tools can be brought to 
"production-ready" status during 2005.

The main tools are:
- NetEpi Case Manager: this is a tool for securely collecting structured 
information about cases and contacts of diseases (and other conditions) 
of public health importance, through Web browsers and the Internet. New 
data collection forms can be designed and deployed quickly by 
epidemiologists, using a "point-and-click" interface, without the need 
for knowledge of or training in any programming language (not even 
Python). Data can then be collected from users of the system, who can be 
located anywhere in the world, into a centralised database. All that is 
needed by users of the system is a relatively recent Web browser and an 
Internet connection. In some respects, NetEpi Case Manager is like a 
Web-enabled version of the data entry facilities in the very popular Epi 
Info suite of programmes provided in various forms since the mid-1980s 
by the United States Centers for Disease Control and Prevention. 
However, NetEpi Case Manager aims to provide additional facilties to 
make it easier to administer a rapidly-deployable, widely-distributed 
data collection system which can scale to handle hundreds of thousands 
of cases and contacts if required.

- NetEpi Analysis: this is a tool for conducting epidemiological 
analysis of data sets, both large and small, either through a Web 
browser interface, or via a Pythonic programmatic interface. In some 
respects it is similar to the analysis facilities included in Epi Info, 
except that NetEpi Analysis is primarily designed to be installed on 
servers and accessed remotely via Web browsers (or other remote 
procedure call or web service mechanisms), rather than being installed 
on individual desktop or laptop computers (although it can and does run 
nicely on Linux and Apple Mac OS X desktops and laptops, and on 
Microsoft Windows machines in future versions).

Contributions by experienced Python programmers to the further 
development of these tools are welcome - please use the mailing list 
(details on the project home page at http://www.netepi.org) for initial 
contact.

Also many thanks to the Python development team, and to the developers 
of the various Python packages which these tools make use of - 
particularly the Albatross web application framework, the eGenix 
MxDateTime module, the pyPGSQL DB-API package, Numeric Python, and the 
RPy package which interfaces Python with R (and thanks to the R 
development team for the R statsistics package, of course).

Tim C
Sydney, Australia
--
http://mail.python.org/mailman/listinfo/python-list

Re: Koolaid (was Re: Optional Static Typing)

[Tim Churches]

Peter Hansen <[EMAIL PROTECTED]> wrote:
> 
> John Roth wrote:
> > "Rocco Moretti" <[EMAIL PROTECTED]> wrote:
> >> The question is, should Guido state "TDD is the one true way to 
> >> program in Python.", or should concessions be made in the language 
> >> design for those who don't "drink the TDD Kool-aide".
> > 
> > Neither one. I hope you didn't mean  that people
> > who advocate TDD are suicidal fanatics, because
> > that's exactly what "drink the  kool-aid" means.
> 
> I always thought the connotation was more that those who
> "drank the Kool-Aid" were unthinking drones, following what
> others told them to do.

I thought it was an allusion to "The Electric Kool-Aid Acid test" by Tom Wolfe 
- see 
http://en.wikipedia.org/wiki/The_Electric_Kool_Aid_Acid_Test

Tim C
-- 
http://mail.python.org/mailman/listinfo/python-list