Anyone want to help moderate the Web-SIG list? Very low activity level.
I'd just like to get some more people who can manipulate the levers.
Bill
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubs
ing ABC that would allow us to define
> our own.
I think the most effective way to lobby here would be to provide the
String ABC and an implementation of "encoded strings", i.e. strings with
an internal representation that's a byte sequence in a particular
encoding.
Bill
_
nd urlencoded was
that it was always Latin-1. You were supposed to use
"multipart/form-data" for non-Latin-1 encodings. Long thread on
www-talk circa 1994 about this.
I think bytes are the safest way to go here. It would be nice if we
could automagically detect the correct encoding, but the
Jim Fulton wrote:
> I'm working on another project, bozo, to facilitate using bobo
> resources in Zope and use Zope components with bobo applications.
Good names, Jim.
Bill
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www
Alan Kennedy wrote:
> Hi Bill,
>
> [Bill]
> > I think the controlling reference here is RFC 3875.
>
> I think the controlling references are RFC 2616, RFC 2396 and RFC 3987.
I see what you're saying, but it's darn near impossible, as a practical
matter, to get a
ith PATH_INFO set; I think it's
obsolete usage (but pretty clearly a string). RFC 3875 says, "Similarly,
treatment of non US-ASCII characters in the path is system-defined."
QUERY_STRING -- should always be an ASCII string. May indeed encode
non-Unicode strings or purely binary data
ever wrote this was that it
would succeed. Which is the correct expectation?
Bill
def test_url_encoding(self):
# Try some URL encodings of the PATHs.
# (the behaviour here has changed from libwww-perl)
c = CookieJar(DefaultCookiePolicy(rfc2965=True))
interact_296
d
various broken browsers, because I was trying to guess "common
practice" and follow it. Until I actually read the RFCs and made the
server follow them. Now that it does, almost all of those errors have
gone away. So, my experience seems to differ from yours.
Bill
_
ords if a user agent sent text
> in ISO-8859-x and didn't say it was doing so, then an
> error should be raised when non-ASCII data is seen.
Yep.
Bill
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Uns
, though. But the default is ASCII.
> If there is a problem in the decoding, the client is broken (or there is
> a bug in the application).
> So the correct response is Bad Request, IMHO.
Yes, I think that's right.
Bill
___
Web-SIG ma
; it should be used.
Yes, I agree.
Bill
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
x for it yet, because of the large number
of badly implemented server frameworks that are out there.
Bill
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
d Request in case of errors.
It's clearly not safe to do so generally. If you do decide to do
this, please tell me what framework you're building so that I can
avoid it :-).
Bill
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://
rding to RFC 2046, the default charset for "text/plain" is
"US-ASCII".
> Can you point me to the discussion on python-dev list?
See http://mail.python.org/pipermail/python-dev/2008-July/081013.html
and the subsequent conversation.
ctly decoded. Otherwise, you lose information that the app
cannot recover.
Bill
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
icted to ASCII values by the HTML 4.01 spec,
multipart/form-data can contain arbitrary Unicode strings.
In Python 3.x, strings are all Unicode.
Bill
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
ht
I've just cleared the queue of admin tasks for the Web-SIG list, so
don't be surprised to see some old messages appear...
Bill
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.
> Is it time there was a JSON codec included in the python standard library?
Great idea. In fact, I'd support including a whole ECMAscript
interpreter module, much as we have XML parsers.
Bill
___
Web-SIG mailing list
Web-SIG@python.org
Web S
ote", "quote_plus", "unquote", and
"unquote_plus" from urllib. Not sure how representative that is, but
they should at least be preserved in urllib2. By the way, shouldn't
the name "urllib" be used for "urllib2", if "urllib" is tos
e Python, not
improve it. Given that, I'd rather see what's in the stdlib be
updated to best-of-breed, instead of
the-first-thing-we-thought-of-in-1995, as all too much of it is.
Bill
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: h
any of these.
We don't really have interfaces in Python.
Bill
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
ats
I'm still restricting myself to Python 2.3, so I haven't really looked
at cookielib.
Bill
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
ention the new SSL module. I found it irritating that I had
to write all of this myself, instead of just pulling it from the
standard library. Now that it's released, what's already in the
standard library (that I just didn't know about :-)? A
oing into PEP 3108, so either join the stdlib-sig,
or read the PEP, if you care about all this.
Alexandre Vassalotti further proposes the following:
> xmlrpclib -> xmlrpc.tools
> SimpleXMLRPCServer -> xmlrpc.server
> DocXMLRPCServer -> xmlrpc.server
> For symmetry's sake in Windows a Python service manager could simply
> use SCManager API under the hood (through win32all) to get the job done,
> still keeping a consistent cross-platform modus operandi.
That's what I do in UpLib. Works
Or should
SimpleHTTPServer just be deleted altogether?
Bill
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
> I am happy to direct these conversations to
> wherever folks want. Is this the place, after all?
You bet! Let's keep things here, till folks complain.
Bill
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/s
27;d like to be able to use them
together in a single address space. It sounds like you've worked out
most of the issues with IMAP4, so I'll take a closer look.
Bill
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/si
for indexing and search, and has the ability to do
auto-filtering on a per-user basis with either MH procmail scripts or
a Python script that uses a particular API. I don't need an SMTP
server, I don't need a Web interface to mail.
If DivmodQuotient is anywher
n requests very well. I figured I'd adapt
Medusa for this, again; set up an HTTP handler and an IMAP handler.
But I thought I'd check the wisdom of the crowd, first.
Bill
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.o
what WSGI-supporting environments will also support PyLucene (the
limiting factor is that the GCJ runtime has to be linked in, and all
threads must be GCJ threads).
Bill
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/si
> Perhaps this could go in Demo/wsgiref/?
Perhaps both Ian's and Phillip's examples could go into Demo/wsgiref/?
Bill
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.pytho
> It still looks like an application of WSGI, not part of a reference
> implementation.
It seems to me that canonical exemplars are part of what a "reference"
implementation should include. Otherwise it would be a "standard"
implementation, which is con
t.
If anyone would like to help with that, send me mail.)
Bill
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
or ILU. I often wish I had it around today for AJAX...
Bill
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
on objects would be, as you say, a bare
minimum. One way to this would be to translate the Javascript into
Python, and use existing introspection hooks to watch the Python
execute.
Bill
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http:/
it's the flip side of Python in the browser.
Bill
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Nice list, Alan. I think you make a lot of sense here.
Bill
> [Alan Kennedy]
> >>>Maybe we need a PEP
>
> [Bill Janssen]
> >>Great idea! That's exactly what I thought when I organized this SIG a
> >>couple of years ago.
>
> [Guido van Ross
> What would we be PEPing?
Well, when we started, I made up a list of various things that seem to
be missing in the standard library, like server-side support for
SSL-encrypted socket connections.
http://www.parc.com/janssen/web-sig/needed.html
B
that automatically sync with the
user's browser cookie repositories.
I don't believe there's any support for server-side cookie handling either.
Bill
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
(rationally ;-) and sort out all of the issues before we go ahead and
> commit anything?
Great idea! That's exactly what I thought when I organized this SIG a
couple of years ago.
Bill
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG
ith this thinking. Non-production code shouldn't
go into the stdlib; instead, Alan's proposed module should go onto
some pedagogical website somewhere with appropriate tutorial
documentation.
Bill
___
Web-SIG mailing list
Web-SIG@python.org
Web
If no one has done a WSGI implementation for Medusa, I think I'll take
a shot at it this weekend...
Bill
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/we
>From the Python point of view, it might be interesting to have a
Javascript (isn't it properly called ECMAscript?) interpreter that
functions like one of the Python HTML parsers. That is, every time
some javascript action happens, there's the opportunity to interpose
some Pytho
Anyone done a WSGI module for Medusa yet?
Bill
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
pure-Python, ready-to-use Python web app framework,
called Medusa. No other installs necessary -- you don't have to get
some database running unless you really want to. Works remarkably
well; I've written a few app servers in it already. Perhaps your
buddy is actually switching for so
'm just interested,
on this mailing list, in improving ways of helping Python-savvy
engineers provide and use Web services.
Bill
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.
with me. I'm
interested in improving the ability to do things *with Python*. And
that doesn't (for me) mean switching to something else, no matter how
many other people understand that "something else".
Bill
___
Web-SIG mailing li
dynamic_content['title'] = 'How to write a Web service'
dynamic_content['author'] = 'Someone Good'
request.reply(template % dynamic_content)
Bill
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://w
x27;t want to write in
some cumbersome and buggy XML format (which is what I'm guessing ZCML
is) when I could be writing clean Python code.
Bill
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mai
bprocesses.
Wedges are extremely rare, and I have yet to see one caused by Python
code.
Bill
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
51 matches
Mail list logo