On 2011-01-07 13:21:36 -0800, Antoine Pitrou said:
Ok, so, WSGI doesn't "already involve generators". QED.
Let me try this again. With the understanding that:
:: PEP 333[3] and 444 define a response body as an iterable.
:: Thus WSGI involves iterables through definition.
:: A generator is a type of iterable.
:: Thus WSGI involves generators through the use of iterables.
The hypothetical redefinition of an application as a generator is not
too far out to lunch, considering that WSGI _already involves
generators_. (And that the simple case, an application that does not
utilize async, will require a single word be changed: s/return/yield)
Is that clearer? The idea refered to below (and posted separately)
involve this redefinition, which I understand fully will have a number
of strong opponents. Considering PEP 444 is a new spec (already
breaking direct compatibility via the /already/ redefined return value)
I hope people do not reject this out of hand but instead help explore
the idea further.
On 2011-01-07 19:36:52 -0800, Antoine Pitrou said:
Alice Bevan–McGregor <al...@...> writes:
The particular use case happens to be PEP 444 as implemented using an
async and multi-process (some day multi-threaded) HTTP server, so I'm
not quite sure what you're getting at, here.
It's becoming to difficult to parse. You aren't sure yet what the async
part of PEP 444 should look like but you have already implemented it?
Marrow HTTPd (marrow.server.http) [1] is, internally, an asynchronous
server. It does not currently expose the reactor to the WSGI
application via any interface whatsoever. I am, however, working on
some p-code examples (that I will post for discussion as mentioned
above) which I can base a fork of m.s.http off of to experiment.
This means that, yes, I'm not sure how async will work in PEP 444 /in
the end/, but I am at least attempting to explore the practical
implications of the ideas thus far in a real codebase. I'm "getting it
done", even if it has to change or be scrapped.
I helped proof a book about Python 3 compatibility and am giving a
presentation in March that contains information on Python 3
compatibility from the viewpoint of implementing the Marrow suite.
Well, I hope not too many people will waste time trying to write code
cross-compatible code rather than solely target Python 3. The whole
point of Python 3 is to make developers' life better, not worse.
I agree, with one correction to your first point. Application and
framework developers should whole-heartedly embrase Python 3 and make
full use of its many features, simplifications and clarifications.
However, it is demonstrably not Insanely Difficult™ to have compatible
server and middleware implementations with the draft's definition of
native string. If server and middleware developers are willing to
create polygot code, I'm not going to stop them.
Note that this type of compatibility is not mandated, and the use of
native strings (with one well defined byte string exception) means that
pure Python 3 programmers can be blissfully ignorant of the
compatibility implications -- everything else is "unicode" (str), even
if it's just "bytes-in-unicode" (latin1/iso-8859-1). Pure Python 2
programmers have only a small difference (for them) of the URI values
being unicode; the remaining values are byte strings (str).
I would like to hear a technical reason why this (native strings) is a
bad idea instead of vague "this will make things harder" -- it won't,
at least, not measurably, and I have the proof as a working, 100% unit
tested, performant, cross-compatible polygot HTTP/1.1-compliant server.
Written in several days worth of "full-time work" spread across weeks
because this is a spare-time project; i.e. not a lot of literal work,
nor "hard".
Hell, it has transformed from a crappy hack to experiment with HTTP
into a complete (or very nearly so) implementation of PEP 444 in both
of its current forms (published and draft) that is almost usable,
ignoring the fact that PEP 444 is mutable, of course.
- Alice.
[1] http://bit.ly/fLfamO
_______________________________________________
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
