python-dev summary, July 5-15

[Andrew Kuchling]

This is a summary of traffic on the python-dev mailing list between
July 5 and July 15 (inclusive) 2001.  It is intended to inform the
wider Python community of ongoing developments.  To comment, just post
to python-list@python.org or comp.lang.python in the usual way. Give
your posting a meaningful subject line, and if it's about a PEP,
include the PEP number (e.g. Subject: PEP 201 - Lockstep iteration)
All python-dev members are interested in seeing ideas discussed by the
community, so don't hesitate to take a stance on a PEP if you have an
opinion.
	
Summaries are archived at:
	 
<http://starship.python.net/crew/mwh/summaries/>
<http://www.amk.ca/python/dev/>

Michael Hudson is taking a break from writing the python-dev
summaries, so I'll be writing them for the summer.  This summary for
July 4-15 is quite late, having been delayed first by my week-long
vacation in Quebec and then by the file getting accidentally deleted
from my laptop -- remember, kids, don't leave important text files
sitting in /tmp/.  Anyway, after unpacking my luggage and running
'strings' on my root partition, here it is.

--am"crawling from the wreckage"k
	   

XML-RPC added to standard library
=================================

Eric S. Raymond forwarded a suggestion from Dave Winer to add XML-RPC
support to Python's standard library.

	Dave suggests that the open-source community can turn up the
        heat on Microsoft by visibly supporting and promoting open RPC
        standards that compete with .NET, such as XML-RPC and SOAP
        1.1.  He thinks that the implementors of scripting languages
        like Perl and Python are in a particularly good position to
        make this happen, by making XML-RPC and/or SOAP 1.1 fully
        documented parts of their standard libraries.

XML-RPC is a simple protocol for making remote procedure calls;
function parameters are converted into an XML format and sent using
HTTP.  Implementations exist for many different languages, and there
are two Python implementations, /F's xmlrpclib.py and Eric Kidd's C
library.  Kidd posted to suggest using /F's code:

	My library, although nice, is intended for C programmers, and
        needlessly duplicates a lot of Python functionality.  It has its
        own data model (based on Python's), UTF-8 processing (based on
        Python's), structure builder (based on Python's), and so
	on. You get the picture.

One objections raised was that XML-RPC is ostensibly ASCII-only,
though almost everyone seems to ignore this and supports Unicode
anyway, as Eric Kidd pointed out:
    
	Fredrik's library supports Unicode.  My library supports Unicode.
        The Java libraries all support Unicode.  And furthermore, we all
        appear to have interop.

I was +0, as while XML-RPC works pretty well, what it does isn't
very much:

	My misgiving is that XML-RPC is pretty limited, the lack of
        support for None being particularly painful to a Python
        programmer.  Perhaps, if we can only have one, SOAP would be
        better, but I haven't used SOAP seriously for anything yet.

/F was +1 on adding xmlrpclib.py, -0 on SOAP support:

	-0 on soap support in 2.2 (it's still a moving target; a new spec
        draft was released this weekend).  if we want something now, it
	should be cayce ullman's SOAP.py, not my soaplib.py.  but I don't
        think we need SOAP in the standard library for another year or
        two.

	(fwiw, my current thinking is that SOAP is a flawed idea, and that
         the need for SOAP will go away when people get better XML/Schema
         tools, but that's another story.  and don't get me started on SOAP
         BDG...)
        
So he checked in the code, and ESR contributed documentation for the
module.  There's no sign that SOAP is going into 2.2, as everyone
seemed rather lukewarm about it.

GvR also wondered if Python 2.2 should support DAV ("That's another
open protocol that Python could easily support out of the box.") and
/F agreed, but Greg Stein, the DAV expert and champion on python-dev,
remained silent.


site-packages on Windows
========================

On Windows, third-party Python packages get installed into the root of
the Python installation, C:\PYTHON2.1.  Pete Shinners complained about
this:

	for the love of all things good, can we please make a
        recommendation in our PEP that the windows installation location
        be something other than "C:\PYTHON21"? something like
        "C:\PYTHON21\SITE-PACKAGES" would be a big improvement. i thought
        i heard that macpython recently made this "fix", why is the
        windows version lagging on this?

PEP 250, by Paul Moore, discusses fixing this.
http://python.sourceforge.net/peps/pep-0250.html

        
Encodings for Unicode literals
==============================

Another lengthy thread centred around PEP 263, "Defining Unicode
Literal Encodings", by M.-A. Lemburg, which suggests using the
directive statement proposed by PEP 244 to define a default encoding
for Unicode literals.  Right now a Unicode literal always uses the
'unicode-escape' encoding, so a literal such as u"\u1234\u4720" is
turned into a 2-character Unicode string consisting of U+1234, U+4720.
PEP 263 suggests that you could define the encoding to be something
else, so you could put, say, Cyrillic characters into a Unicode
literal and have them be automatically converted.

Most of the problems people have aren't with the idea of indicating
the encoding, but rather with how it should be done.  PEP 263
suggests something like this:
    directive unicodeencoding = "UTF-8"

But that syntax isn't actually allowed by PEP 244.  There's also a
circular problem with module docstrings; many tools expect the module
docstring to be the very first thing in the file, preceded only by
comments and blank lines, so putting a directive first will break such
tools.  But the encoding should apply to the docstring if it's a
Unicode literal, so the directive has to come first.

Discussion was inconclusive.  Some people liked the idea; others think
a comment would be better and easier for non-Python tools such as
editors to deal with; yet others don't approve of having a 'directive'
statement at all.  There seems agreement that the issue of source file
encoding is worth clearing up, but no obvious solution is at hand.


Related Links
=============

Python-dev archives:
        http://www.python.org/pipermail/python-dev/
	http://aspn.activestate.com/ASPN/Mail/Browse/Threaded/python-dev

Python project page on SourceForge:
        http://sourceforge.net/projects/python

Python Enhancement Proposals (PEPs):
        http://python.sourceforge.net/peps/