Pythonic way of web-programming
Giorgi
Let me start with the statement that I am not a professional
web-programmer. My tasks are rather linked with the scientific
calculations and algorithm prototyping.
Recently I have started to make a Georgian language based web-site for
Python. It was a natural feeling not to use, say, php or perl for
web-content management. I have gone through different approaches
available in Python; namely:
- CGI (with or without mod-python and / or cpy ) ;
- ZOPE ;
- Jython / J2EE ;
- ASP .NET ;
- Webware PSP.
I didn't examine all of them in depth as my real choice was somehow
restricted with either CGI or (utter maximum), webware appserver,
(which still has to be set up in a due manner by my ISP provider; I am
doing the site as they are willing to promote Python in Georgia).
My opinion, or rather feeling, is that "there is more than one way of
doing this"; something utterly unpythonic…
Hence my questions to the Python web-programming gurus:
- Is Python a real web-programming language at all? I mean, has
somebody ever used it for real, commercial tasks? Please, do not
consider my question too trivial. There is no language equally
suitable for all tasks, however, Python seems to me a language
naturally tailored for web-programming; this or that way, I have more
than two years of experience of professional programming in Python.
- If it is an intention of the Python community to keep or to
establish Python as a web-programming language on the level of Java,
C# and Co., what is the standard, or at least, recommended way to
web-program in Python? Which technology?
- Hasn't yet come the time to have the only *standard* way of
web-programming in Python? For example, will anybody ever use Java for
web-programming outside the J2EE framework? In Python, and I still
emphasize, it might be only my feeling, there are lots of ways to do
this job.
- Is there a need to design a genuine python framework for
web-programming? I admit that it should sound weird and fuzzy and that
I myself have no exact idea of how to do so, however, a mere porting
of technologies compels us to program, say, Java, in Python. Why
should we keep doing this? Python itself is one of the most powerful,
clear and emotionally beautiful language.
Or, maybe, ZOPE is the genuine pythonic way? I simply do not know. I
do not want to come with some "new ideas" simply not feeling myself
confident. Therefore, please, give me some hints where to start
web-programming in Python.
Thank you very much for your attention.
Best wishes,
Giorgi
Aahz
Giorgi <lekis...@python.qartu.com> wrote:
>
>- Is Python a real web-programming language at all? I mean, has
>somebody ever used it for real, commercial tasks? Please, do not
>consider my question too trivial. There is no language equally
>suitable for all tasks, however, Python seems to me a language
>naturally tailored for web-programming; this or that way, I have more
>than two years of experience of professional programming in Python.
No, Python is not a real web-programming language (in comparison to, say,
PHP). However, Python is a real programming language, period; with
Python, it is possible to construct useful frameworks for programming Web
applications, and Zope has served as a proof of this for many years.
The reason why there are so many solutions is because there are tradeoffs
for ease vs. power for each type of web application -- and there are
many types of web applications. The "only one way" Pythonic principle
just doesn't apply.
Probably the "standard" answers these days for the basic building block
of a web application is either Zope (if you want a full-blown framework
for content management) or Quixote (if you want a relatively simple
system that feels like programming in Python).
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
This is Python. We don't care much about theory, except where it intersects
with useful practice. --Aahz, c.l.py, 2/4/2002
Dylan Reinhardt
> - Is Python a real web-programming language at all? I mean, has
> somebody ever used it for real, commercial tasks?
Yes and yes.
> - Is there a need to design a genuine python framework for
> web-programming?
Zope is a highly Pythonic framework for building web-facing
applications. It's been quite good for at least a couple years now...
good enough for enterprise-level systems, good enough for e-commerce.
It's not trivial to learn, but it's well worth it if you need something
more robust than CGI-style web programming tools.
> Or, maybe, ZOPE is the genuine pythonic way?
Perhaps... it is highly object-oriented and readily extensible with
Python. Zope is hardly the only way, but it is worth a good look.
Some docs: http://www.zope.org/Documentation/Books/ZopeBook/2_6Edition
HTH,
Dylan
Giorgi
Thomas Guettler
> Hi all!
>
> Let me start with the statement that I am not a professional
> web-programmer. My tasks are rather linked with the scientific
> calculations and algorithm prototyping.
>
> Recently I have started to make a Georgian language based web-site for
> Python. It was a natural feeling not to use, say, php or perl for
> web-content management. I have gone through different approaches
> available in Python; namely:
> - CGI (with or without mod-python and / or cpy ) ; - ZOPE ; - Jython /
> J2EE ;
> - ASP .NET ;
> - Webware PSP.
It depends on what you want to do.
Zope is bloated. Nevertheless I use it because the ZCatalog lets you
index python objects easily. The downside: Most providers don't let you
use it.
If performance is not very important, I would use cgi.
I was told, that scgi is better than mod_python. But never used one of
both: http://www.mems-exchange.org/software/scgi/
If you want it to be 100% Python you can use medusa: A webserver written
in python.
thomas
--
Thomas Guettler <gue...@thomas-guettler.de>
http://www.thomas-guettler.de
Ian Bicking
generally. These things have been very much on my mind lately.
There are several options for Python web programming -- far more than
you list, actually, even when you take out the options that aren't being
actively developed. There's many ways to categorize them, but here I
might say:
* Zope, a world of its own. Certainly it could be a point of much
debate, but lots of people don't like Zope, often for the reasons they
do like Python.
* Python in language-neutral or foreign language frameworks (like
Jython/J2EE, or ASP .NET -- Python works fine in pre-.NET ASP too).
* Minimal, i.e., cgi.
* Some from-scratch implementation of a Python web environment. This is
where the diversity is right now.
Zope had its chance at being the canonical Python web framework -- there
was a time when all the focus of using Python for web applications was
towards Zope. It had 100% mindshare. But it's not good at being a
general-purpose platform for web applications, which is why all sorts of
people have created alternatives. And you have to create *something*,
because cgi doesn't cut it, you will want to work on a higher level.
Anyway, that said, we now have all this diversity. Maybe some of it is
called for -- I'd certainly be unhappy if we had unity around an option
I didn't like. But we have a lot of diversity that isn't useful too.
What's the One True Templating Language? I don't know. But I don't
think we need more than four -- there are several valid and useful
different ways to do templating. But there's also a limit.
The same is true in the from-scratch implementations. There are some
valid differences between, say, Webware and Quixote. But there's a
limit to that as well.
Right now, no, there isn't any Right Way to do Python on the web. Zope
might be the closest thing, but there is no consensus. I can't really
figure out what a consensus would be, but I imagine there's at least
some things we can come to consensus on... maybe underlying
infrastructure, or ways we can share code (like making templating
separate from the frameworks). There's still a lot of work to be done
on that path, though.
Ian
Bo M. Maryniuck
> Probably the "standard" answers these days for the basic building block
> of a web application is either Zope (if you want a full-blown framework
> for content management)
Zope ain't just a "full-blown framework for content management". This what
CMF-like or KONTENTOR-like products does. Zope is an application server,
where you can build anything for web you want, even intergrate it with J2EE
via SOAP/XML-RPC.
--
Regards, Bogdan
A computer without any MS Windows is like a fish without a bicycle.
-- With apologies to Gloria Steinem
Aahz
Bo M. Maryniuck <b.mar...@forbis.lt> wrote:
>On Friday 04 April 2003 19:32, Aahz wrote:
>>
>> Probably the "standard" answers these days for the basic building block
>> of a web application is either Zope (if you want a full-blown framework
>> for content management)
>
>Zope ain't just a "full-blown framework for content management". This what
>CMF-like or KONTENTOR-like products does. Zope is an application server,
>where you can build anything for web you want, even intergrate it with J2EE
>via SOAP/XML-RPC.
While true, my impression has been that most people choose solutions
other than Zope unless they need at least some content management.
Aahz
Thomas Guettler <pan-new...@thomas-guettler.de> wrote:
>
>If you want it to be 100% Python you can use medusa: A webserver written
>in python.
These days, you should use Twisted instead of medusa.
http://www.twistedmatrix.com/
At PyCon, I realized an hour before my presenation that I'd neglected to
set up a web server for my threads tutorial (which includes a spider),
and I was able to set up Twisted's web server in about fifteen minutes.
Giorgi
> Right now, no, there isn't any Right Way to do Python on the web. Zope
> might be the closest thing, but there is no consensus. I can't really
> figure out what a consensus would be, but I imagine there's at least
> some things we can come to consensus on... maybe underlying
> infrastructure, or ways we can share code (like making templating
> separate from the frameworks). There's still a lot of work to be done
> on that path, though.
>
The question is that the only way to establish Python as a language
for corporate level web-programming is to have the standard approach
if not introduced, then at least supported by the Python consortium...
Jp Calderone
Python consortium?
Heee.
Jp
--
http://catandgirl.com/view.cgi?44
--
up 16 days, 16:00, 5 users, load average: 1.13, 0.93, 0.85
Ian Bicking
> The question is that the only way to establish Python as a language
> for corporate level web-programming is to have the standard approach
> if not introduced, then at least supported by the Python consortium...
I don't think that's entirely true. It's difficult for *Python* to be a
language for certain areas of web programming (perhaps corporate), but
certain Python environments could still achieve that. The corporation
would choose an environment, not a language, and if a good environment
is written in Python then indirectly they'll have chosen Python.
But I'm not saying it wouldn't be nice to have more cohesion... that's
just not the way it is now. It's harder to make it happen, because
unlike Java or .NET, the Python community is not a top-down community.
Guido has some authority, but I think he's almost as much a decision
process as a decider -- he decides on things where there's some level of
consensus in the community, and doesn't make dictates otherwise. The
standard library has some authority, but its fairly neutral on these
things. Besides that there's no authority at the moment.
The next step I can envision would be for Twisted to become the
canonical infrastructure, where higher-level web frameworks are all
built ontop of it. In that way we can start to build consensus one
piece at a time.
Ian
Neil Schemenauer
> The next step I can envision would be for Twisted to become the
> canonical infrastructure, where higher-level web frameworks are all
> built ontop of it.
That's not feasible. Some applications would require extensive
modification to work on top of an event driven framework.
Neil
Jp Calderone
That's a shame. I think this indicates that they are poorly designed. ;)
Seriously, though. The input source of an application should *not* be
very tightly integrated with the actual logic of the application. I can see
how this is sometimes unavoidable, though, and how other times it simply is
more (perceived) work than it's (perceived) worth. Perhaps Ian should have
said "canonical event-driven infrastructure".
Jp
--
In the days when Sussman was a novice Minsky once came to him as he sat
hacking at the PDP-6. "What are you doing?" asked Minsky. "I am training a
randomly wired neural net to play Tic-Tac-Toe." "Why is the net wired
randomly?" asked Minsky. "I do not want it to have any preconceptions of how
to play." Minsky shut his eyes. "Why do you close your eyes?" Sussman asked
his teacher. "So the room will be empty." At that moment, Sussman was
enlightened.
--
up 17 days, 2:00, 5 users, load average: 1.13, 1.17, 1.09
Giorgi
> On Sat, 2003-04-05 at 12:49, Giorgi wrote:
> > The question is that the only way to establish Python as a language
> > for corporate level web-programming is to have the standard approach
> > if not introduced, then at least supported by the Python consortium...
>
> I don't think that's entirely true. It's difficult for *Python* to be a
> language for certain areas of web programming (perhaps corporate), but
> certain Python environments could still achieve that. The corporation
> would choose an environment, not a language, and if a good environment
> is written in Python then indirectly they'll have chosen Python.
>
That's what I wanted to say.
> But I'm not saying it wouldn't be nice to have more cohesion... that's
> just not the way it is now. It's harder to make it happen, because
> unlike Java or .NET, the Python community is not a top-down community.
> Guido has some authority, but I think he's almost as much a decision
> process as a decider -- he decides on things where there's some level of
> consensus in the community, and doesn't make dictates otherwise. The
> standard library has some authority, but its fairly neutral on these
> things. Besides that there's no authority at the moment.
>
Well, maybe we should establish an advisory board? :)
The issue is that an experoenced programmer will hardly ever change
his favorite framework; however, a newbie will have a standard
starting point. I am not a web-programmer and the only reason I went
relatively deep is my task to make a Georgian-language based site for
Python. I have a standard cgi module. At least it's there, but...
Therefore, I don't think that the consensus of the whole Python
community is really required...
> The next step I can envision would be for Twisted to become the
> canonical infrastructure, where higher-level web frameworks are all
> built ontop of it. In that way we can start to build consensus one
> piece at a time.
>
Ok, but who is (are) taking over?
Graham Fawcett
Neil, I may just be suffering from
daylight-savings-adjustment-syndrome, but what kinds of applications?
We are talking only about Web application frameworks, which are
request handlers and are therefore event-driven by definition.
Unless, as JP sugested, you're suggesting bad design, like an
application that is too tightly bound to a specific networking
framework?
I'm not a Twisted fanatic, just trying to understand.
-- Graham
Neil Schemenauer
> [...] what kinds of applications? We are talking only about
> Web application frameworks, which are request handlers and are
> therefore event-driven by definition.
For example, we have a web application that interacts with
FedEx's servers in order to create new shipping labels, track
packages, etc. With an event driven system, waiting for a
response for FedEx would freeze the entire server. Obviously
that can be fixed the hooking into the event loop. It's just a
matter of programming, right?
Another example: we have an application that does some CPU
intensive operations. We have multiple CPUs in our server. An
event driven system would not (normally) take full use of the
processors. Also, clients who have IO bound requests would be
blocked by one CPU bound request.
I have nothing against the event driven model. However, it is
not the solution to every network server problem.
Neil
Ian Bicking
> > But I'm not saying it wouldn't be nice to have more cohesion... that's
> > just not the way it is now. It's harder to make it happen, because
> > unlike Java or .NET, the Python community is not a top-down community.
> > Guido has some authority, but I think he's almost as much a decision
> > process as a decider -- he decides on things where there's some level of
> > consensus in the community, and doesn't make dictates otherwise. The
> > standard library has some authority, but its fairly neutral on these
> > things. Besides that there's no authority at the moment.
> >
> Well, maybe we should establish an advisory board? :)
I just recently proposed a web-sig, which is just a mailing list, but
from there I'm hoping we can get developers from the various frameworks
talking together and maybe make some progress. I'm just waiting on the
mailing list to be created. Here's my proposal:
http://mail.python.org/pipermail/meta-sig/2003-March/001246.html
You can email meta...@python.org if you think it's a good idea.
Ian
Ian Bicking
That was my initial impression too, but you don't have to program in the
Twisted/async style in order to use Twisted as a base -- Twisted can
spawn threads and wait for responses from those threads. I've been
thinking about this for Webware, and I don't think there would need to
be any change to user's code (and actually only very minimal changes to
Webware's code -- mostly just deleting the parts that are redundant with
Twisted and making a few wrappers).
It does change the installation procedure and some of the management --
which is okay in Twisted but not great. However, none of the frameworks
are great, and if we consolidate we have a better chance at improvement.
Ian
Ian Bicking
> Neil Schemenauer <nas-u...@arctrix.com> wrote in message news:<%5Oja.10776$7w2....@nwrddc01.gnilink.net>...
> > Ian Bicking <ia...@colorstudy.com> wrote:
> > > The next step I can envision would be for Twisted to become the
> > > canonical infrastructure, where higher-level web frameworks are all
> > > built ontop of it.
> >
> > That's not feasible. Some applications would require extensive
> > modification to work on top of an event driven framework.
> >
> > Neil
>
> Neil, I may just be suffering from
> daylight-savings-adjustment-syndrome, but what kinds of applications?
> We are talking only about Web application frameworks, which are
> request handlers and are therefore event-driven by definition.
In the Twisted/async model everything that's not really fast has to be
done with events. So instead of doing:
f = open("somefile")
contents = f.read()
unsafeHTML.sub('', contents)
...
You would do that with events and callbacks. I can't give a good
example of the translation because I'm not well-versed in that sort of
programming, but you'd compose it as a number of functions, with the
file read calling those functions once it's been completed.
It's pretty weird, and yes it isn't feasable, but luckily you don't have
to use that style to use Twisted (just if you want to program Twisted
protocols).
Ian
Chuck Swiger
[ ... ]
> For example, we have a web application that interacts with
> FedEx's servers in order to create new shipping labels, track
> packages, etc. With an event driven system, waiting for a
> response for FedEx would freeze the entire server. Obviously
> that can be fixed the hooking into the event loop. It's just a
> matter of programming, right?
Apparently almost anything can be regarded as a matter of programming,
as "Strauser family release #3" demonstrates (congratulations!)... :-)
Do your queries against FedEx's system need to be atomic, and in what
ways? If you want is to make multiple outstanding transactions against
a server asyncronously using an event-driven system without blocking,
can't you have a multithreaded component that generates queries, listens
until it gets the response, and then adds each completed transaction as
an event to a single event queue?
The event-loop & the logic of your application doesn't need to block
simply because there are some outstanding queries which haven't all been
answered; you'd only block if there aren't any responses available to
work on.
> Another example: we have an application that does some CPU
> intensive operations. We have multiple CPUs in our server. An
> event driven system would not (normally) take full use of the
> processors. Also, clients who have IO bound requests would be
> blocked by one CPU bound request.
Hmm. Well, to continue the paradigm I was using above for this example,
you could pull off as many responses off the event queue as you have
processors available; each time a processor finishes with one event, it
then grabs the next event from the queue.
Sure, if the events might be related to each other-- where the system
might need to update data which is in use (being processed, has some
dependency, etc), then the system gets more complex. You might need to
have mutexes around the event queue or other data structures, use a
2-phase transaction with explicit commit strategy, scan for and coalese
related events in the queue to catch updates, dispatch notifications of
changed data, interrupt & restart existing calculations, whatever.
Anyway, all of those are solutions to complexities resulting from the
application's needs; if what you're doing doesn't need them, then the
"one line of customers feeding multiple bank attendants" type of event
dispatch model should work fine.
> I have nothing against the event driven model. However, it is
> not the solution to every network server problem.
I certainly agree with your general notion: programming paradigms may be
well-suited for some tasks and not well-suited for others. Perhaps it's
not clear to me what else you had in mind: non-blocking I/O like
select() or poll()? What kind of SMP dispatch system are you using now?
Network server architectures tend to be event driven in design because
most flavors of network IPC are quantized into discrete network packets
by the lower levels of the system; local IPC via SysV shared memory is a
notable exception, though. Event-driven models tend to be used a lot
for various aspects of system UIs, and some of those systems might also
display an unfortunate tendency to have a UI that becomes modal or
single-threaded while processing events like mouse-drags, but the two
are not the same thing.
-Chuck
Neil Schemenauer
> Do your queries against FedEx's system need to be atomic, and in what
> ways?
They should be but I don't think they actually are. I'm getting
out of my depth here because I'm not an expert on the FedEx API.
> If you want is to make multiple outstanding transactions
> against a server asyncronously using an event-driven system
> without blocking
We don't need to do that since we are currently not using an
event driven model. Like I said previously, making the system
work using an event driven model is possible but would require
making changes.
> I certainly agree with your general notion: programming
> paradigms may be well-suited for some tasks and not well-suited
> for others. Perhaps it's not clear to me what else you had in
> mind: non-blocking I/O like select() or poll()? What kind of
> SMP dispatch system are you using now?
We using a "pre-fork" model, similar to what Apache 1.3 uses.
There are multiple worker processes that receive requests from a
manager process. The application interfaces with the web server
using mod_scgi. Most requests are handled quicky so one process
handles almost all requests. The other processes are there for
CPU intensive requests or for requests that block on other
resources.
> Network server architectures tend to be event driven in design
> because most flavors of network IPC are quantized into discrete
> network packets by the lower levels of the system;
Maybe. I think a more important reason is that most network
servers are network IO bound. For a static HTML file server or
FTP server, event driven is the way to go, IMHO.
Neil
Jp Calderone
> Graham Fawcett <graham_...@hotmail.com> wrote:
> > [...] what kinds of applications? We are talking only about
> > Web application frameworks, which are request handlers and are
> > therefore event-driven by definition.
>
> For example, we have a web application that interacts with
> FedEx's servers in order to create new shipping labels, track
> packages, etc. With an event driven system, waiting for a
> response for FedEx would freeze the entire server. Obviously
> that can be fixed the hooking into the event loop. It's just a
> matter of programming, right?
>
Hmm, you point this out as a problem, then say it is easily fixable. I'm
not sure what point you're trying to make here.
> Another example: we have an application that does some CPU
> intensive operations. We have multiple CPUs in our server. An
> event driven system would not (normally) take full use of the
> processors. Also, clients who have IO bound requests would be
> blocked by one CPU bound request.
Threads and multiple processes solve this easily. So do event-based IO
APIs, such as kqueue and AIO (Yes, I know AIO isn't ready for use in a
production system yet).
>
> I have nothing against the event driven model. However, it is
> not the solution to every network server problem.
No doubt. "Canonical" doesn't mean "universal" or "solitary".
Jp
--
No, `Eureka' is Greek for `This bath is too hot.'
-- Dr. Who
--
up 17 days, 19:01, 5 users, load average: 0.00, 0.20, 0.23
Lothar Scholz
> - Is Python a real web-programming language at all? I mean, has
> somebody ever used it for real, commercial tasks? Please, do not
> consider my question too trivial. There is no language equally
> suitable for all tasks, however, Python seems to me a language
> naturally tailored for web-programming; this or that way, I have more
No its not a naturally tailored web-programming language, because it
is
very hard to integrate in Server Pages. You have to change the
indentation syntax/semantic of python to embedd it in a real useable
way.
This is done by Webware but it looks very strange to normal python
programmers.
Of course you can use template systems. But this is not always a good
economic decision.
Ian Bicking
> No its not a naturally tailored web-programming language, because it
> is very hard to integrate in Server Pages. You have to change the
> indentation syntax/semantic of python to embedd it in a real useable
> way. This is done by Webware but it looks very strange to normal python
> programmers.
OTOH, it's rather easy to integrate HTML into Python code -- easier than
many other languages (maybe Perl is better, PHP isn't).
> Of course you can use template systems. But this is not always a good
> economic decision.
If you want a quick solution, then I'd recommend using no template at
all. If you want real templating, Server Pages aren't a particularly
good implementation.
Ian
Giorgi
> On Sun, 2003-04-06 at 20:58, Lothar Scholz wrote:
> > No its not a naturally tailored web-programming language, because it
> > is very hard to integrate in Server Pages. You have to change the
> > indentation syntax/semantic of python to embedd it in a real useable
> > way. This is done by Webware but it looks very strange to normal python
> > programmers.
>
> OTOH, it's rather easy to integrate HTML into Python code -- easier than
> many other languages (maybe Perl is better, PHP isn't).
exactly!
Graham Fawcett
Lothar, "not integrating well in Server Pages" is an incomplete argument
against Python as a Web programming language, IMHO.
First, "Server Pages" are a subset of a much larger range of
"templating" solutions. Server Page schemes tend to have a lot of code
embedded between pseudo-HTML tags, interspersed with HTML snippets. They
also tend to be unmaintainable, and often get polluted with application
logic, when they should be focusing on presentation alone.
If the script in your Server Page is doing much more than iterating a
list of elements, calling code from a Python module (that you wrote, or
that's in the standard library), or doing a bit of string manipulation,
then it's time to stop writing code for a while, Google "separate logic
from presentation" and think about your approach until you're really
sure you've got your concerns separated.
I would agree with you that Python isn't overly well suited to the
Server Page approach, though I've used it in ASP with very few problems
caused by indentation. Let's not count the language out quite yet...
Python has some outstanding templating options. I think, e.g., that
ZopePageTemplates (doesn't require Zope, btw) is a work of art, and
avoids many of the inherent design flaws that mar most templating
approaches. If you need it to, ZPT will coexist very peacefully with Web
designer tools (Dreamweaver, etc.), *far* better than most other
templating systems will, regardless of what language those systems
favour. And, best, ZPT makes it very *hard* to put application logic
into the page, thus forcing you to consider presentation alone, a very
helpful design constraint indeed.
Or, take a look at Quixote's approach to templating. It turns the whole
concept inside out, and gives a programmer-friendly way of building Web
output without inventing an pseudo-HTML minilanguage to struggle with. A
great approach that builds on Python's flexibility and strengths.
But the big point is that there is far more to Web application
programming than templating. Templating is the easy part! There's domain
modelling, business logic, scripting, persistence management, database
access, code maintainability, RAD, developer effectiveness, etc. Python,
most lithe of modern languages, seems an excellent fit to these more
serious needs.
Best,
-- Graham
Giorgi
> is
> very hard to integrate in Server Pages. You have to change the
> indentation syntax/semantic of python to embedd it in a real useable
> way.
> This is done by Webware but it looks very strange to normal python
> programmers.
>
> Of course you can use template systems. But this is not always a good
> economic decision.
OK, but can't one use XML/XLST as a sole solution for the view?
Alex Martelli
> On Sat, 2003-04-05 at 22:32, Neil Schemenauer wrote:
>> Ian Bicking <ia...@colorstudy.com> wrote:
>> > The next step I can envision would be for Twisted to become the
>> > canonical infrastructure, where higher-level web frameworks are all
>> > built ontop of it.
>>
>> That's not feasible. Some applications would require extensive
>> modification to work on top of an event driven framework.
>
> That was my initial impression too, but you don't have to program in the
> Twisted/async style in order to use Twisted as a base -- Twisted can
> spawn threads and wait for responses from those threads. I've been
> thinking about this for Webware, and I don't think there would need to
> be any change to user's code (and actually only very minimal changes to
> Webware's code -- mostly just deleting the parts that are redundant with
> Twisted and making a few wrappers).
A Webkit version running on top of Twisted would really be a wonderful
thing to have... I have a hard time conceiving of exactly how you'd fit
them together (maybe I'm not familiar enough with the _internals_ of
each, though I've used them both), but I'll accept your assessment that
it would be a pretty easy job for you, so, what about trying it out...?
> It does change the installation procedure and some of the management --
> which is okay in Twisted but not great. However, none of the frameworks
> are great, and if we consolidate we have a better chance at improvement.
A wise strategy, that would be...
Alex
Ian Bicking
> A Webkit version running on top of Twisted would really be a wonderful
> thing to have... I have a hard time conceiving of exactly how you'd fit
> them together (maybe I'm not familiar enough with the _internals_ of
> each, though I've used them both), but I'll accept your assessment that
> it would be a pretty easy job for you, so, what about trying it out...?
It should be pretty simple, really. WebKit has a single entry point
that takes an argument with the CGI-like variables for the request, an
input stream (e.g. for the POST data), and an output stream (with a
write method) that accepts CGI-like output (i.e., it may add headers,
translate Status into a response code, etc. -- but simple stuff). This
entry point is expected to run in a thread of its own.
Using the Twisted CGI code, it would be a quick change to make it
dispatch to a thread instead of a process (as with CGI).
The other detail is initializing the WebKit environment -- the
persistent Application object, plugins, etc. That would be easy to do
in a simplistic way, maybe more subtle if I was to use a more Twisted
way.
I'm still thinking about the strategy around it, which is why I haven't
actually tried implementing it. As an experiment it's not that
interesting to me, but maybe it could be more than that.
Ian
Paul Boddie
>
[WebKit on Twisted]
> Using the Twisted CGI code, it would be a quick change to make it
> dispatch to a thread instead of a process (as with CGI).
One of the main concerns about making Twisted the "Pythonic standard"
is that people who demand a non-threaded, non-CGI handler model for
scalability reasons (and this did come up recently on
comp.lang.python, so it is a valid concern) are very likely to fall
outside the resulting audience. Unfortunately, especially given the
success of mod_python and other process-forking frameworks, that could
amount to a lot of people.
> I'm still thinking about the strategy around it, which is why I haven't
> actually tried implementing it. As an experiment it's not that
> interesting to me, but maybe it could be more than that.
Well, I've been experimenting with implementing a small framework on
top of WebKit and mod_python (with Zope being another likely
candidate), and it has to be said that some frameworks share enough
similarity and do provide enough flexibility to make
"super-frameworks" possible. Moreover, with developments like POSH...
http://poshmodule.sourceforge.net
...it might even be possible for such "super-frameworks" to paper over
the fundamental but desirable differences between the underlying
frameworks. For example, some people might want a threaded model,
whilst others might prefer a process-forking model together with
similarly convenient data sharing semantics.
As for the issue of standard APIs, I believe that such APIs really
only serve a useful purpose as being something to build on that is
widely agreed upon, recognised and stable; they don't necessarily
serve the purpose of being something developers really want to write
to directly. For example, Java Servlets have arguably served as a
foundation for more high-level toolkits, whereas writing directly to
the Servlet API is something that the most productive developers
stopped doing years ago.
Paul
P.S. The Web frameworks shootout paper is most informative and serves
as an interesting guide as to the most accessible frameworks that
could be subverted (or "leveraged" depending on your mindset) by such
"super-frameworks".
Andy Robinson
>the fundamental but desirable differences between the underlying
>frameworks. For example, some people might want a threaded model,
>whilst others might prefer a process-forking model together with
>similarly convenient data sharing semantics.
Hear, hear.
I think it's sad that Python has this slogan "there's only one way
to do it", but that nowhere is this less true than web development.
At Python-UK I opined that this might be holding us back in comparison
to other languages and tools. Anyone coming into Java or .NET
development gets a very clear feeling of "one way to do it".
We have a bunch of competing frameworks, but if we analyze them
into layers then they compete less, and a more compatible approach
must be possible.
First, let's note the half-a-dozen different templating schemes
available. DTML, Woven, Quixote, YAPTU, preppy.
Second, it has always seemed to me that there is a very well
understood model of a web app consisting of a controller, Request,
Response and a few other things, handled in very similar ways by Java
servlets, ASP and WebKit. This is the basic 'dispatch loop'. It would
be wonderful if this could be systematized in something like the 'db
api', with some interfaces defined in the standard Python library.
Finally, there's a transport mechanism. Here one could use
CGI, Twisted, Zope, BaseHTTPServer or whatever else.
Wouldn't it be nice if one day we could have some standardized
interfaces, so that one could switch between these without undue pain
and reduce the confusion people must face?
Best Regards,
Andy Robinson
ReportLab Inc.
Courageous
>I think it's sad that Python has this slogan "there's only one way
>to do it", but that nowhere is this less true than web development.
>At Python-UK I opined that this might be holding us back in comparison
>to other languages and tools.
Not a bad point overall.
Of course, you're sort of leveraging the wrong quip. "There's only
one way to do it" applies to the *language*. It's never applied to
API's, really.
At the risk of boldly tossing incidental mud up in the face of
the entirety of all Pythonistas, I really don't think our community
has enough cohesion or clout to put together a uniform .NET/Web Services
style package with standards-establishing authority. We're not Microsoft,
after all, with a cool $billion to dispose of at a sneeze.
What you'll have to do instead is wait for the competitive feeding
frenzy to end and allow the technically superior platform to present
itself. This is both the bane and boon of open software in action,
IMO, and at a guess it very much applies here.
C//
Will Stuyvesant
> At the risk of boldly tossing incidental mud up in the face of
> the entirety of all Pythonistas, I really don't think our community
> has enough cohesion or clout to put together a uniform .NET/Web Services
> style package with standards-establishing authority. We're not Microsoft,
> after all, with a cool $billion to dispose of at a sneeze.
>
> What you'll have to do instead is wait for the competitive feeding
> frenzy to end and allow the technically superior platform to present
> itself. This is both the bane and boon of open software in action,
> IMO, and at a guess it very much applies here.
Well said. Or written. Whatever. I wish english was my native
language. I would like to add something. The major problem I face
when I want to use Python for web applications or services, is that
the host or internet provider just does not have Python installed, or
they have the old Python 1.5, like even sourceforge does. Or no
``#!/usr/bin/env Python`` or something like that configured for CGI
scripts. Running your own webserver is often just not allowed.
I feel we should concentrate, whoever of us can do such a thing, on
getting Python into *nix distros, especially the kind internet
providers use. And talk to Apache so they change their default
configuration script or something (I am not sure about the
technicalities here, there is something like mod_python also but how
about support?) so it will not only allow #!/bin/sh but also Python.
And for the rest of use mere programmers, we can kick ass producing
better tools for web environments. For example: I have not seen a
good, easy to use, web application that works well with RDF. How
about setting up a website with Python where you can input your RDF
file and it displays the tree with nice colors and URLs and so forth?
There are plenty possibilities using Python for things like this, but
you have to show it, working examples, *on the web* or nobody will see
it.
I think CGI is the only standard that will last some time, maybe
better concentrate on that.
--
As in Protestant Europe, by contrast, where sects
divided endlessly into smaller competing sects and no
church dominated any other, all is different in the
fragmented world of IBM. That realm is now a chaos of
conflicting norms and standards that not even IBM can
hope to control. You can buy a computer that works
like an IBM machine but contains nothing made or sold
by IBM itself. Renegades from IBM constantly set up
rival firms and establish standards of their own. When
IBM recently abandoned some of its original standards
and decreed new ones, many of its rivals declared a
puritan allegiance to IBM's original faith, and
denounced the company as a divisive innovator. Still,
the IBM world is united by its distrust of icons and
imagery. IBM's screens are designed for language, not
pictures. Graven images may be tolerated by the
luxurious cults, but the true IBM faith relies on the
austerity of the word.
-- Edward Mendelson, "The New Republic",
February 22, 1988
Alex Martelli
...
> First, let's note the half-a-dozen different templating schemes
> available. DTML, Woven, Quixote, YAPTU, preppy.
YAPTU's a toy -- and, as its author, I hope I can assert that with
some credibility!-) Cheetah, OTOH, is a serious contender for the
"best of breed" Python templating utility (at least when templates
need to be maintained by non-programmers). I don't know if it's
entirely correct to describe Quixote as a templating tool. Rather,
I _would_ count such packages as Spyce...
None of this invalidates your main point, of course (indeed, on
the contrary, it might reinforce it).
> be wonderful if this could be systematized in something like the 'db
> api', with some interfaces defined in the standard Python library.
The DB API isn't in the standard library (and until some substantial
amount of reusable CODE is factored out, rather than just somewhat
vague interface specs, I doubt it will be... or _should_ be). If a
consensus could be reached among a sufficient number of the maintainers
of existing packages, then, sure, some interfaces could be standardized.
However -- look at the XML situation for contrast. There IS just such
a standard (and parts of it ARE in the standard libraries, while others,
PyXML stuff, integrate as seamlessly as they can with those via some
import tricks). AND YET -- you guys have developed and maintain PyRXP,
which uses substantially different interfaces -- *AND WELL IT DOES*,
because thanks to the different interfaces (trees of bare tuples, or
lists as the case may be, rather than intricate objects as in DOM) it
can save a LOT of memory, and generally zip along much, much faster.
Aren't there analogies here...? preppy may be the simplest (and thus,
the best) templating tool for a Python programmer -- starting with a
good knowledge of Python, said programmer needs to learn very little to
start using preppy. Yet Cheetah's very different templating language
may be best if one needs templates to be handled with 3rd party tools
designed to handle HTML pages, and more generally maintained by people
who do not consider themselves programmers and might strongly resist
"having to learn to program". Targeting different audiences, is it
surprising that preppy and Cheetah end up with so different interfaces?
> Finally, there's a transport mechanism. Here one could use
> CGI, Twisted, Zope, BaseHTTPServer or whatever else.
Not sure I'd qualify Zope as a "transport" mechanism!-) Rather
the choice here is:
-- a custom server program coded in Python (BaseHTTPServer and
the like, Medusa, Twisted)
-- CGI, the only standard ensuring operability with different
webservers (maybe fast-CGI might live here too...?)
-- webserver-specific ways to cooperate with existing webservers:
LRWP for Xitami, mod_python or mod_webkit or PyApache for
Apache, ASP or lower-level interfaces to MS servers, ...
Can we find enough commonality among such disparate needs to
extract out some common interfaces? In the DB-API case (and in
the XML one) there were some existing external standards (not
necessarily well-observed, vide the SQL standard, but still maybe
better than nothing) as a reference point. Besides CGI, and
HTTP itself, what would we build upon here? Perhaps the Request-
Response model you mention would suffice for reasonably high
level interactions, but much of what one can do e.g. with mod_python
ISN'T "reasonably high level" (or else one would just use
PyApache for CGI-substition-level tasks...!).
> Wouldn't it be nice if one day we could have some standardized
> interfaces, so that one could switch between these without undue pain
> and reduce the confusion people must face?
Yes, it would be VERY nice, but I have no idea about how to make
it happen, or even about how it would look like if it ever did.
Alex
Paul Boddie
>
[Super-frameworks]
> I think it's sad that Python has this slogan "there's only one way
> to do it", but that nowhere is this less true than web development.
> At Python-UK I opined that this might be holding us back in comparison
> to other languages and tools. Anyone coming into Java or .NET
> development gets a very clear feeling of "one way to do it".
At the lowest level, Java (and presumably .NET) does indeed have one
strongly standardised way of doing things, and there's little point in
people going against the flow at that level, especially since most
people don't do a lot of work at that level when writing their
applications. However, the same could almost be true for Python: many
frameworks seem to adopt a request/response style and reuse parts of
the CGI implementation, although it's true that not all frameworks
expose request data in similar ways.
It's also worth noting that whilst the Java platform has various
favoured frameworks for Web programming, the "framework space" is
arguably as fragmented as it is for Python. Choose your framework from
"straight JSP", Struts, Cocoon, Turbine, Expresso... (See
http://www.waferproject.org/index.html for a long list.) The
consequence of all this is that Java development projects can tend to
play it safe and select a fairly low common denominator requiring lots
of tedious legwork and wheel reinvention.
> We have a bunch of competing frameworks, but if we analyze them
> into layers then they compete less, and a more compatible approach
> must be possible.
>
> First, let's note the half-a-dozen different templating schemes
> available. DTML, Woven, Quixote, YAPTU, preppy.
Modularisation at the templating level is essential for generic
frameworks. Thus, I find hard-wired Python-in-HTML solutions
uninteresting.
[...]
> Wouldn't it be nice if one day we could have some standardized
> interfaces, so that one could switch between these without undue pain
> and reduce the confusion people must face?
Indeed.
Paul
A.M. Kuchling
Andy Robinson <an...@reportlab.com> wrote:
> Second, it has always seemed to me that there is a very well
> understood model of a web app consisting of a controller, Request,
> Response and a few other things, handled in very similar ways by Java
> servlets, ASP and WebKit.
I've speculated about adding a standard HTTP{Request,Response} type to the
standard library, but even this seems unlikely because I doubt we can agree
on what should be in it, or what naming convention to use. (Quixote uses
underscore_names, WebWare uses camelCase; whose users have to change all
their code.)
There's also the inflexibility that comes with putting something in the
standard library; the interfaces can't be changed without breaking existing
users, so it's impossible to fix things. cgi.py has lots of cruft in it,
but I've never tried to clean it up because I have no idea what applications
out there might be broken, so cgi.py stays crufty. It's noteworthy that
Quixote's upload handling only got really reliable when Greg Ward wrote his
own upload parsing code and jettisoned use of cgi.py's code.
All this talk of unifying Web frameworks strikes me as pointless. Different
toolkits have different design principles and different goals; hoping for a
unified one is like hoping Python and Perl will settle their differences and
merge. The most to hope for is that some of the systems will die out,
leaving two or three more major ones in control of the space. The best we
can do now is to make it easier for users to choose which toolkit to use by
documenting them and comparing their differences.
--amk (www.amk.ca)
LEAR: I am a man more sinn'd against than sinning.
-- _King Lear_, III, ii
Michael Ströder
> The most to hope for is that some of the systems will die out,
> leaving two or three more major ones in control of the space.
Yes, that's my hope too. I'd like to substitute my own little framework with
another more comprehensive web toolkit. But it's hard to determine at the
moment which one will survive and will still be maintained in one or two
years => I stay with mine in the mean-time.
> The best we
> can do now is to make it easier for users to choose which toolkit to use by
> documenting them and comparing their differences.
I strongly agree.
Ciao, Michael.
Erik Max Francis
> First, let's note the half-a-dozen different templating schemes
> available. DTML, Woven, Quixote, YAPTU, preppy.
EmPy, too.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ The tremor of awe is the best in man.
\__/ Goethe
REALpolitik / http://www.realpolitik.com/
Get your own customized newsfeed online in realtime ... for free!
Jon Ribbens
> Wouldn't it be nice if one day we could have some standardized
> interfaces, so that one could switch between these without undue pain
> and reduce the confusion people must face?
I could suggest the interface defined in jonpy
(http://jonpy.sf.net/)... The low-level interface is very similar to
Java servlets and hence may be popular. There are implementations for
standard CGI, mod_python and FastCGI, and other implementations should
be entirely possible.
Is there a mailing list for this sort of thing?
Ian Bicking
> However -- look at the XML situation for contrast. There IS just such
> a standard (and parts of it ARE in the standard libraries, while others,
> PyXML stuff, integrate as seamlessly as they can with those via some
> import tricks). AND YET -- you guys have developed and maintain PyRXP,
> which uses substantially different interfaces -- *AND WELL IT DOES*,
> because thanks to the different interfaces (trees of bare tuples, or
> lists as the case may be, rather than intricate objects as in DOM) it
> can save a LOT of memory, and generally zip along much, much faster.
>
> Aren't there analogies here...?
There may be compelling differences in some areas. For instance, a
template that is DOM-like (i.e., externally controlled) vs. a template
that is self-evaluating, like Cheetah. But among self-evaluating
templates, the interface seems like it should be possible to unify.
There are deep differences and shallow ones. It would be really nice to
get rid of the shallow ones.
[...]
> > Finally, there's a transport mechanism. Here one could use
> > CGI, Twisted, Zope, BaseHTTPServer or whatever else.
>
> Not sure I'd qualify Zope as a "transport" mechanism!-) Rather
> the choice here is:
>
> -- a custom server program coded in Python (BaseHTTPServer and
> the like, Medusa, Twisted)
>
> -- CGI, the only standard ensuring operability with different
> webservers (maybe fast-CGI might live here too...?)
I don't think FastCGI has much relation to CGI. I don't entirely
understand FastCGI, but from what I can tell it just sucks -- it's
easier to do the same thing with a simpler socket connection to a
persistent process (as done with SCGI, WebKit adapters, mod_skunkweb,
and no doubt others). I think FastCGI manages starting that persistent
process on its own, which seems like a nice feature.
> -- webserver-specific ways to cooperate with existing webservers:
> LRWP for Xitami, mod_python or mod_webkit or PyApache for
> Apache, ASP or lower-level interfaces to MS servers, ...
mod_python is another concept entirely (mod_webkit is just one
implementation of a simple protocol that's web-server-neutral)...
mod_python really is something separate, though maybe it could be made
to look like any other forking request.
> Can we find enough commonality among such disparate needs to
> extract out some common interfaces? In the DB-API case (and in
> the XML one) there were some existing external standards (not
> necessarily well-observed, vide the SQL standard, but still maybe
> better than nothing) as a reference point. Besides CGI, and
> HTTP itself, what would we build upon here? Perhaps the Request-
> Response model you mention would suffice for reasonably high
> level interactions, but much of what one can do e.g. with mod_python
> ISN'T "reasonably high level" (or else one would just use
> PyApache for CGI-substition-level tasks...!).
There is a common thread here: HTTP. It's not that complicated, and the
interface you'd create for an HTTP transaction seems pretty self-evident
-- request and response objects don't have a lot of novelty to them.
There may be funny Apache-specific things you could do with mod_python,
but I think the benefit of those features is easily outweighed by the
potential benefits of some more unification of web programming for
Python... and besides mod_python, most frameworks share a pretty similar
foundation, even though each one phrases it slightly differently.
Ian
Ian Bicking
> On Tue, 15 Apr 2003 02:30:49 +0100,
> Andy Robinson <an...@reportlab.com> wrote:
> > Second, it has always seemed to me that there is a very well
> > understood model of a web app consisting of a controller, Request,
> > Response and a few other things, handled in very similar ways by Java
> > servlets, ASP and WebKit.
>
> I've speculated about adding a standard HTTP{Request,Response} type to the
> standard library, but even this seems unlikely because I doubt we can agree
> on what should be in it, or what naming convention to use. (Quixote uses
> underscore_names, WebWare uses camelCase; whose users have to change all
> their code.)
One option would be to use an interface with adapters, where if say the
Quixote interface was used, Webware would have an adapter from that
interface to the Webware HTTP{Request,Response} interface... though I'm
not sure how interesting request and response object are. Defining the
adapter may not be much less work than reimplementing it from scratch.
But maybe not...
> There's also the inflexibility that comes with putting something in the
> standard library; the interfaces can't be changed without breaking existing
> users, so it's impossible to fix things. cgi.py has lots of cruft in it,
> but I've never tried to clean it up because I have no idea what applications
> out there might be broken, so cgi.py stays crufty. It's noteworthy that
> Quixote's upload handling only got really reliable when Greg Ward wrote his
> own upload parsing code and jettisoned use of cgi.py's code.
I don't think development of the standard library would do well at
syncing with development of something like this, at least not for a
while. It seems to me like there's some questions about batteries
included anyway, that it makes development of new functionality
unwieldy. It's more important in making something the canonical
implementation, and maybe that's achievable through other techniques.
> All this talk of unifying Web frameworks strikes me as pointless. Different
> toolkits have different design principles and different goals; hoping for a
> unified one is like hoping Python and Perl will settle their differences and
> merge.
I disagree. Unifying with one model for building applications is not
likely, but there are a lot of places where the frameworks duplicate
effort without significant differentiation. By identifying those we
could make a more robust, more easily distributed, more compelling
foundation for web frameworks.
Ian
Ian Bicking
> Ian Bicking <ia...@colorstudy.com> wrote in message news:<mailman.1050210449...@python.org>...
> > dispatch to a thread instead of a process (as with CGI).
>
> One of the main concerns about making Twisted the "Pythonic standard"
> is that people who demand a non-threaded, non-CGI handler model for
> scalability reasons (and this did come up recently on
> comp.lang.python, so it is a valid concern) are very likely to fall
> outside the resulting audience. Unfortunately, especially given the
> success of mod_python and other process-forking frameworks, that could
> amount to a lot of people.
It seems like Twisted could fork as well...? Its internal paradigm
(async) doesn't seem like it needs to be reflected in the things that
are built ontop of it.
> > I'm still thinking about the strategy around it, which is why I haven't
> > actually tried implementing it. As an experiment it's not that
> > interesting to me, but maybe it could be more than that.
>
> Well, I've been experimenting with implementing a small framework on
> top of WebKit and mod_python (with Zope being another likely
> candidate), and it has to be said that some frameworks share enough
> similarity and do provide enough flexibility to make
> "super-frameworks" possible. Moreover, with developments like POSH...
>
> http://poshmodule.sourceforge.net
>
> ...it might even be possible for such "super-frameworks" to paper over
> the fundamental but desirable differences between the underlying
> frameworks. For example, some people might want a threaded model,
> whilst others might prefer a process-forking model together with
> similarly convenient data sharing semantics.
I'm increasingly drawn towards forking models as well, as they offer
more guarentees about stability, and some potential for using more
operating-system-level security (e.g., when run as root and dropping to
another user when executing a particular page).
Of course they don't port to Windows, which is why Apache 2 is so
wishy-washy about the execution model compared to 1.3. On an operating
system like Linux, where threads are simulated with processes, I'm not
sure what the real advantage of threads are -- except for the easy data
sharing, which can be a flaw as well (since there's less partitioning).
Maybe something like POSH would introduce the same problems.
Some partitioning can be achieved in a threading model by running
separate applications as long-running multi-threaded processes (which is
what I'd generally recommend for Webware/WebKit deployments).
Anyway, the particulars of the choice aside, there would be the
possibility of providing alternatives with a common framework ontop.
I'm a little wary of this, though... my own perception of Webware (which
just happens to be what I'm more aware of) is that the choices provided
didn't pan out like was hoped (though I wasn't around at the point those
basic pieces were being developed). For instance, there are a bunch of
different "adapters" meant to connect a web server to the application
server, but only a couple are actually useful (mostly mod_webkit and
wkcgi, and I suppose LWRPAdapter if you're using Xitami). The choice is
a false one -- offering a diversity of options where most are inferior
isn't very helpful.
Even the AppServer in Webware was built with this in mind, with the
threaded option being one among many... but only the threaded option was
ever really developed, and I think it would be just as valid to add more
features to that AppServer as it would be to create an alternate
implementation with different (say forking) behavior. No, it would be
better, because code wouldn't get as fragmented and the community
wouldn't be as fragmented.
So, choices are good, but only the best choices. Too many choices is
just confusing.
> As for the issue of standard APIs, I believe that such APIs really
> only serve a useful purpose as being something to build on that is
> widely agreed upon, recognised and stable; they don't necessarily
> serve the purpose of being something developers really want to write
> to directly. For example, Java Servlets have arguably served as a
> foundation for more high-level toolkits, whereas writing directly to
> the Servlet API is something that the most productive developers
> stopped doing years ago.
I think there's some basis for an API related to web stuff (on several
levels). We just need to identify those areas that are ripe.
> Paul
>
> P.S. The Web frameworks shootout paper is most informative and serves
> as an interesting guide as to the most accessible frameworks that
> could be subverted (or "leveraged" depending on your mindset) by such
> "super-frameworks".
Indeed, that has been on my mind too.
Ian
Alex Martelli
> On Tue, 2003-04-15 at 03:11, Alex Martelli wrote:
>> However -- look at the XML situation for contrast. There IS just such
>> a standard (and parts of it ARE in the standard libraries, while others,
>> PyXML stuff, integrate as seamlessly as they can with those via some
>> import tricks). AND YET -- you guys have developed and maintain PyRXP,
>> which uses substantially different interfaces -- *AND WELL IT DOES*,
>> because thanks to the different interfaces (trees of bare tuples, or
>> lists as the case may be, rather than intricate objects as in DOM) it
>> can save a LOT of memory, and generally zip along much, much faster.
>>
>> Aren't there analogies here...?
>
> There may be compelling differences in some areas. For instance, a
> template that is DOM-like (i.e., externally controlled) vs. a template
> that is self-evaluating, like Cheetah. But among self-evaluating
> templates, the interface seems like it should be possible to unify.
Possible, yes. Feasible, I dunno. Compare Cheetah and preppy, which
both process templates to produce Python modules. preppy does it in
a very simple, rather Pythonic way -- inserting "directives" enclosed
in {{...}} that are Python expressions or a few Python statements
modified to have explicit endif/endfor/&c termination rather than
relying on indentation. Any Python programmer should have no problem
understanding preppy in 10 minutes and then happily using e.g.
{{myobject.func()}}
or
{{myobject['index']}}
or
{{myobject.attr}}
&c &c in a fully appropriate manner -- since by definition a Python
programmer already understands perfectly the difference between
calling a function (and KNOWS you need empty parentheses when you
call a function without arguments -- something that keeps tripping
beginners up, btw), indexing a container, accessing an attribute.
But suppose your design intention is different -- you want your
templates to be maintained by NON-programmers, people which DO
have problems understanding the differences between the above
distinct concepts! In Cheetah, the above constructs would be
$myobject.func
$myobject.index
$myobject.attr
i.e., totally polymorphic. The Cheetah designer, on the basis of
a LOT of experience trying to have non-programmers maintain
templates, believe this extreme polymorphism makes things VERY
much easier for non-programmers (perhaps particularly ones that
have some previous exposure to languageoids such as Javascript
and VBScript that may also try to hide such differences...).
So who's right? Quite possibly both -=- a programmer will find it
easier and more productive to use and maintain preppy templates,
closer to Python, and a non-programmer Cheetah templates, which
requires him or her to learn fewer concepts (and do NOT require
empty parentheses for argumentless function calls, in particular).
> There are deep differences and shallow ones. It would be really nice to
> get rid of the shallow ones.
Personally I agree that the difference between {{x.y()}} and $x.y is
quite shallow. But I don't know if it's best gotten rid of -- I _have_
seen nonprogrammers (and even programmers with e.g. a Pascal background)
wrestle with forgetting the () over and over, yet as a programmer I FAR
prefer the clarity of the distinctions drawn by preppy (and Python)
for programming use...
Alex
A.M. Kuchling
> I don't think FastCGI has much relation to CGI. I don't entirely
> understand FastCGI, but from what I can tell it just sucks -- it's
The FastCGI protocol is really complicated because it supports multiplexing
several different transactions over one socket. Data is broken up into
multiple packets, each with a unique transaction ID, and the process on the
other end can then reassemble them and hand them out to different threads.
However, I'm not sure the Apache mod_fastcgi supports this and few client
modules seem to, so all of that complexity buys nothing in most cases.
--amk (www.amk.ca)
FLUTE: Nay, faith, let me not play a woman; I have a beard coming.
-- _A Midsummer Night's Dream_, I, ii
A.M. Kuchling
> One option would be to use an interface with adapters, where if say the
> Quixote interface was used, Webware would have an adapter from that
> interface to the Webware HTTP{Request,Response} interface... though I'm
> not sure how interesting request and response object are.
Perhaps they're not very interesting, but that seems the only level that
could be feasibly standardized.
I'm willing to host a mailing list for web discussion on my DSL-connected
machine. That might be easier than jumping through the SIG hoops. If
you're interested, just suggest a name ('web'?) for the list and I'll create
it. I can't do CVS, but maybe we could just use a sandbox/ directory in the
Python CVS tree.
> I disagree. Unifying with one model for building applications is not
> likely, but there are a lot of places where the frameworks duplicate
> effort without significant differentiation. By identifying those we
> could make a more robust, more easily distributed, more compelling
> foundation for web frameworks.
Yes, but usually those areas of duplication don't actually require a lot of
maintenance effort after the initial implementation. We're four months into
2003, and Quixote's HTTPRequest and Response haven't had a significant
change yet. The changes have all been to higher-level things like the
publishing logic.
--amk (www.amk.ca)
OTHELLO: Put out the light, and then put out the light.
-- _Othello_, V, ii
Jon Ribbens
>> I don't think FastCGI has much relation to CGI. I don't entirely
>> understand FastCGI, but from what I can tell it just sucks -- it's
>> easier to do the same thing with a simpler socket connection ...
You're wrong - FastCGI is excellent. It's a reasonably simple,
standard, well-supported, platform-independent way of speeding up your
CGI scripts. It provides nearly all the advantages (and in some ways,
more advantages) of something like mod_python without any of the
disadvantages of having to run your scripts in the same process as the
web server.
> The FastCGI protocol is really complicated because it supports multiplexing
> several different transactions over one socket. Data is broken up into
> multiple packets, each with a unique transaction ID, and the process on the
> other end can then reassemble them and hand them out to different threads.
> However, I'm not sure the Apache mod_fastcgi supports this and few client
> modules seem to, so all of that complexity buys nothing in most cases.
You are correct in that mod_fastcgi does not support this
multiplexing. I am not aware of any clients that do support it either,
except the one I wrote (jonpy) ;-). I don't agree that FastCGI is
particularly complex though, and even if you think it is it makes no
difference if you simply use a ready-made library to take care of all
the FastCGI work for you.
Gerhard Haering
> On 16 Apr 2003 00:16:49 -0500,
> Ian Bicking <ia...@colorstudy.com> wrote:
>
>>One option would be to use an interface with adapters, where if say the
>>Quixote interface was used, Webware would have an adapter from that
>>interface to the Webware HTTP{Request,Response} interface... though I'm
>>not sure how interesting request and response object are.
>
>
> Perhaps they're not very interesting, but that seems the only level that
> could be feasibly standardized.
>
> I'm willing to host a mailing list for web discussion on my DSL-connected
> machine.
I'd be interested in joining that list.
> That might be easier than jumping through the SIG hoops. If
> you're interested, just suggest a name ('web'?) for the list and I'll create
> it.
web-frameworks?
> I can't do CVS, but maybe we could just use a sandbox/ directory in the
> Python CVS tree.
Or, for that matter, any other Sourceforge project. I admin a few ones
we could (ab)use for this purpose. This has the benefit that the
commiters need not be Python committers.
> [...] Yes, but usually those areas of duplication don't actually require a lot of
> maintenance effort after the initial implementation. We're four months into
> 2003, and Quixote's HTTPRequest and Response haven't had a significant
> change yet. The changes have all been to higher-level things like the
> publishing logic.
We could also discuss the feasability of creating a common interface for
form handling and session management.
-- Gerhard
Ian Bicking
> I'm willing to host a mailing list for web discussion on my DSL-connected
> machine. That might be easier than jumping through the SIG hoops. If
> you're interested, just suggest a name ('web'?) for the list and I'll create
> it. I can't do CVS, but maybe we could just use a sandbox/ directory in the
> Python CVS tree.
I've put a fair amount of effort into Web-SIG, and I'm not quite ready
to give up on it yet (other things in life have taken me away from it
for the last few days is all).
Ian
Ian Bicking
That's okay though, because both just need a namespace to evaluate in.
Cheetah's handling of function calls and whatnot don't change its
interface, just the template language. A DOM-like templating language
obviously needs a different interface, but otherwise all the other
templates basically take a namespace and are otherwise self-executing.
So a template needs a source text and a namespace, and probably a way to
indicate certain other options (say, some languages may have a
case-insensitivity option, but others won't -- Cheetah allows the
NameMapper stuff to be turned off, for instance, making it more like
preppy). But there's still lots that they could share.
For a difference in interface, Cheetah takes a list of namespaces that
get folded together. I haven't looked at preppy, but let's say it takes
a dictionary or a single namespace. That's a different interface, but
it can be turned into one interface, and then both templating languages
will benefit.
Ian
Alex Martelli
...
> For a difference in interface, Cheetah takes a list of namespaces that
> get folded together. I haven't looked at preppy, but let's say it takes
> a dictionary or a single namespace. That's a different interface, but
> it can be turned into one interface, and then both templating languages
> will benefit.
Ah, I see your point, now -- you're talking about the way a templating
operation is initiated _from the Python side_ -- Cheetah's class Template
constructor (returning a class instance x that's then normally expanded
by str(x)), preppy's getModule function (returning a module object m that's
then normally expanded by calling m.run with a dict and output specs), &c.
Yes, I agree, it would definitely be possible to merge these interfaces
into a single one, so that Python code that needs templating can most
easily switch between using different templating packages -- at least
as long as the templating model is somewhat abstractly compatible,
enough commonality should be easily identifiable for this purpose,
while leaving each templating package the choice of what templating
little-language to implement, which is clearly the major differentiatior
(while in the DB-API analogy, the difference between SQL dialects is
hopefully minor in comparison).
Thanks for clarifying,
Alex
Michael Ströder
>
> The FastCGI protocol is really complicated because it supports multiplexing
> several different transactions over one socket. Data is broken up into
> multiple packets, each with a unique transaction ID, and the process on the
> other end can then reassemble them and hand them out to different threads.
> However, I'm not sure the Apache mod_fastcgi supports this and few client
> modules seem to, so all of that complexity buys nothing in most cases.
I'm using a multi-thread FastCGI web application with mod_fastcgi. Or maybe
I did not get your point.
Ciao, Michael.
Michael Ströder
>
> You're wrong - FastCGI is excellent.
Hmm, sometimes it's acting a little bit strange...some hangs...
Ciao, Michael.
A.M. Kuchling
Michael Ströder <mic...@stroeder.com> wrote:
> I'm using a multi-thread FastCGI web application with mod_fastcgi. Or maybe
> I did not get your point.
My point is that you're very rare; most people are not using multithreaded
FastCGI applications.
--amk
Andy Robinson
wrote:
>On Tue, 2003-04-15 at 03:11, Alex Martelli wrote:
>> However -- look at the XML situation for contrast. There IS just such
>> a standard (and parts of it ARE in the standard libraries, while others,
>> PyXML stuff, integrate as seamlessly as they can with those via some
>> import tricks). AND YET -- you guys have developed and maintain PyRXP,
>> which uses substantially different interfaces -- *AND WELL IT DOES*,
>> because thanks to the different interfaces (trees of bare tuples, or
>> lists as the case may be, rather than intricate objects as in DOM) it
>> can save a LOT of memory, and generally zip along much, much faster.
>>
>> Aren't there analogies here...?
I m having a little trouble following this as my newsreader does not
show my own post and the first day of replies (hardly a surprise
with BlueYonder), but I will try to infer what went between.
I did gripe a lot about Python's XML tools up to about 2 years ago,
but the main driver was the general lack of how-to documentation.
This problem has been very well addressed in PyXML and in
several good books, and Python does have a clear standard now.
We went our own way for what I hope are very clearly stated
reasons on the pyRXP page. Also, RXP is GPL, which killed
any plans to try and get it into the Python distro - I tried
to get that changed but could not. But I do have a "roadmap" to
bring that back into the fold one day.
1. The "tuple tree" structure and a standard getattr-based DOM-like
wrapper for it (whih I know Alex has been playing with) could be in
the Python XML package or even the standard library
2. A modest change to pyexpat would let it be generated at C-like
speeds without pyRXP
3. If you can bear GPL - or pay us :-) - you can use pyRXP for
validation. But you won't really need it to get the speed of our
approach.
Finding the time to execute the plan is of course much harder - it
might happen if some huge corporate swallows up ReportLab and
pays us to write cool code, but we now have a "solved problem"
so it's hard to really get wound up for it.
I'll join in with the rest when i find the intervening
2 days somewhere :-)
- Andy
poiboy
> > economic decision.
>
> OK, but can't one use XML/XLST as a sole solution for the view?
I use XSLT [partially] for that reason; it is a general templating solution.
The main reason I use XSLT however is because templating is the best (most
relevant) excuse I have to keep another X specification in my repetoire.
The primary drawback to XSLT is having to fudge an XML document out of your
template variables before being able to transform them. If you're retrieving
data from a native XML source, great, otherwise you need to build an imaginary
tree and make sure it matches up with the paths in the template.
Next, variable representation in the XSL template is likely to take up a whole
lot more room than a typical {{template_variable}}. Instead of standing out
nicely against a backdrop of HTML tags, the template variables in XSL have to
be searched for in small pools of xsl:for-each|value-of|copy-of|... tags and
select="/path/to/var" attributes (and if you've ever had trouble matching up
variable names in templates, you'll have a lot of fun with variable paths).
In the amount of time spent figuring out how to ensure unwanted text would
not appear without running my variable tree through a schema
(<xsl:template match="text()"/>), I could have implemented five other methods
to render my page (just guessing).
Neglecting the inherent joy of an education, I believe the cost of using XSLT
exceeds what benefits it may have (portability, and..) and is likely more
expensive than successive rewrites with other template systems.
Aloha, the poiboy
Andy Robinson
>
>Neglecting the inherent joy of an education, I believe the cost of using XSLT
>exceeds what benefits it may have (portability, and..) and is likely more
>expensive than successive rewrites with other template systems.
>
Many have said that to me in private or on the phone. Few have
been brave enough to say it on Usenet. Bravo :-)
- Andy Robinson
David Abrahams
I've always said that humans shouldn't be forced to read/write XML and
that goes for programmers, too. Writing a programming language in XML
format seems like the perversion of a sadist to me.
I don't care much about XML programming (haven't had a use for it),
but at PyConDC recently I got together with a couple of guys from the
Twisted project who do care, and designed a nice little meta-language
in Python for doing this sort of template processing. Here's a little
example of it in action:
template = body[
table(id="outer", width="100%", height="100%", border="0")[
tr(valign="bottom")[
td(id="output", width="75%", valign="top", model="latestOutput")[
div(pattern="listItem", view="html")[
"Foo"
]
],
td(id="room-contents", valign="bottom")[
strong[
"Stuff you have"
],
div(model="playerInventory", view="List")[
# Note programmatic elements
if_(not arg1)
[
div(_class="item")["Nothing"]
].else_
[
for_each(arg1)
[
div(
style=["color: red", "color: blue", None]
, view="item"
, controller="look")[arg1]
)
]
]
]
]
]
]
]
# invoke the template with some data
template(['foo', 'bar', 'baz', 'another item'])
which generates:
'''<body>
<table id="outer" width="100%" height="100%" border="0">
<tr valign="bottom">
<td id="output" width="75%" valign="top" model="latestOutput">
<div pattern="listItem" view="html">
Foo
</div>
</td>
<td>
<strong>Stuff you have</strong>
<div model="playerInventory" view="List">
<div style="color: red" view="item" controller="look">foo</div>
<div style="color: blue" view="item" controller="look">bar</div>
<div view="item" controller="look">baz</div>
<div style="color: red" view="item" controller="look">another item</div>
</div>
</td>
</tr>
</table>
</body>'''
I really loved this because it was the result of healthy
cross-pollination between the cultures and techniques of two very
different programming communities: Python and C++.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
Ian Bicking
> I don't care much about XML programming (haven't had a use for it),
> but at PyConDC recently I got together with a couple of guys from the
> Twisted project who do care, and designed a nice little meta-language
> in Python for doing this sort of template processing. Here's a little
> example of it in action:
>
> template = body[
> table(id="outer", width="100%", height="100%", border="0")[
> tr(valign="bottom")[
> td(id="output", width="75%", valign="top", model="latestOutput")[
> div(pattern="listItem", view="html")[
> "Foo"
> ]
> ],
> td(id="room-contents", valign="bottom")[
> strong[
> "Stuff you have"
> ],
> div(model="playerInventory", view="List")[
>
> # Note programmatic elements
> if_(not arg1)
> [
> div(_class="item")["Nothing"]
> ].else_
This could almost be plain Python, if Python allowed code blocks. The
use of []'s isn't really necessary, and actually the expressions could
maybe be eval'd as well...
td(id='room-contents', valign='bottom', contents=[
strong(contents=['Stuff you have']),
div(model='playerInventory', view="List", contents=[
if_(<not arg1>,
<[div(_class="item", contents=['Nothing'])]>,
<[for_each("i", <arg1>,
<[div(style=['color: red', 'color: blue', None],
view="item", controller="look",
contents=[arg1])]>)]>)])])
<> is the only nice nesting braces I could think of (`` wouldn't really
do, since it doesn't nest, not to mention it looks much to much like
''). Of course, closing that nested structure is kind of crazy.
And actually <> wouldn't work, because of if <a > 10> -- it's not
entirely ambiguous, but it certainly *looks* ambiguous. And << and >>
are also used, even if it's only for one of the more stupid operators.
Maybe <()>...
It's all pipe-dreams, but code blocks sure would be nice. I don't think
the argument that they allow New Control Structures is correct --
iterators and the traditional control structures actually cover
everything I've ever thought of. Though now that I think about it, is
the thing above a new control structure? A sort of inside-out control
structure, but also asort of lazy evaluation, like a callback.
I've played around with Python objects that allow lazily evaluated
expressions, by overloading all the comparison operators (though you
can't overload and, or, not, or is). In some ways it pleases me, though
it also feels fragile -- and it's not really compatible with normal
Python, i.e., you couldn't call a normal function with a lazy argument
(though you could call a method on a lazy object easily enough).
Ian
David Abrahams
> On Sun, 2003-04-20 at 04:21, David Abrahams wrote:
>> I don't care much about XML programming (haven't had a use for it),
>> but at PyConDC recently I got together with a couple of guys from the
>> Twisted project who do care, and designed a nice little meta-language
>> in Python for doing this sort of template processing. Here's a little
>> example of it in action:
>>
>> template = body[
>> table(id="outer", width="100%", height="100%", border="0")[
>> tr(valign="bottom")[
>> td(id="output", width="75%", valign="top", model="latestOutput")[
>> div(pattern="listItem", view="html")[
>> "Foo"
>> ]
>> ],
>> td(id="room-contents", valign="bottom")[
>> strong[
>> "Stuff you have"
>> ],
>> div(model="playerInventory", view="List")[
>>
>> # Note programmatic elements
>> if_(not arg1)
>> [
>> div(_class="item")["Nothing"]
>> ].else_
>
> This could almost be plain Python, if Python allowed code blocks.
I don't understand; it already *is* plain Python. While Donovan
Preston and I were designing the syntax, his friend Bob was sitting on
the couch coding it up.
> The use of []'s isn't really necessary, and actually the expressions
> could maybe be eval'd as well...
You've lost me here. Lots of the "syntax" choices aren't based on
what's neccessary, but on what's clear and expressive. As far as
"eval" is concerned, well, I'm not sure if you realize this but those
if_ and for_each elements are lazily evaluated. The expression
creates a callable object, "template", which generates new XML.
> td(id='room-contents', valign='bottom', contents=[
> strong(contents=['Stuff you have']),
Uh, I don't know much XML but I'd be shocked if you weren't already
allowed to have an attribute called "contents". I'd have used
single quotes, too, but double quotes are idiomatic for XML.
> div(model='playerInventory', view="List", contents=[
> if_(<not arg1>,
> <[div(_class="item", contents=['Nothing'])]>,
> <[for_each("i", <arg1>,
> <[div(style=['color: red', 'color: blue', None],
> view="item", controller="look",
> contents=[arg1])]>)]>)])])
>
> <> is the only nice nesting braces I could think of
Yikes! One reason I use Python is to relieve my brain from having to
read angle brackets in C++ (and X/HTml ;-)). Plus, now you have two
levels of parenthesis nesting for each sub-element. To my eye, your
version is *way* less-manageable than what we've already done in Pure
Python.
> (`` wouldn't really
> do, since it doesn't nest, not to mention it looks much to much like
> ''). Of course, closing that nested structure is kind of crazy.
>
> And actually <> wouldn't work, because of if <a > 10> -- it's not
> entirely ambiguous, but it certainly *looks* ambiguous. And << and >>
> are also used, even if it's only for one of the more stupid operators.
> Maybe <()>...
>
> It's all pipe-dreams, but code blocks sure would be nice. I don't think
> the argument that they allow New Control Structures is correct --
> iterators and the traditional control structures actually cover
> everything I've ever thought of. Though now that I think about it, is
> the thing above a new control structure? A sort of inside-out control
> structure, but also asort of lazy evaluation, like a callback.
I guess you do realize it's lazy. The thing above is just a callable
object. Nothing fancy <wink>
> I've played around with Python objects that allow lazily evaluated
> expressions, by overloading all the comparison operators (though you
> can't overload and, or, not, or is). In some ways it pleases me, though
> it also feels fragile -- and it's not really compatible with normal
> Python, i.e., you couldn't call a normal function with a lazy argument
> (though you could call a method on a lazy object easily enough).
I think that if you're not concerned with object identity, you can
make lazy objects fairly transparent. Python already hands you
proxies in a few places and you hardly ever even know the difference.
Ian Bicking
> I don't understand; it already *is* plain Python. While Donovan
> Preston and I were designing the syntax, his friend Bob was sitting on
> the couch coding it up.
Hmmm... I guess so. I was thinking of lists following an object, but it
actualy gets parsed as a __getitem__ with a tuple as an argument.
> > The use of []'s isn't really necessary, and actually the expressions
> > could maybe be eval'd as well...
>
> You've lost me here. Lots of the "syntax" choices aren't based on
> what's neccessary, but on what's clear and expressive. As far as
> "eval" is concerned, well, I'm not sure if you realize this but those
> if_ and for_each elements are lazily evaluated. The expression
> creates a callable object, "template", which generates new XML.
So it's not actually a Python program, it's Python syntax that gets
evaluated by your own evaluator...? I was trying to see if it could be
an actual Python program, which would construct an object you could use
later to handle the XML.
Ian
Bengt Richter
[...]
>
>I don't care much about XML programming (haven't had a use for it),
>but at PyConDC recently I got together with a couple of guys from the
>Twisted project who do care, and designed a nice little meta-language
>in Python for doing this sort of template processing. Here's a little
>example of it in action:
>
but I'd guess the approach was to define classes or factory functions
for body, table, tr, td, etc. and have them return suitable objects with suitable
__getitem__ methods. So "body" seems like a predefined object, unlike the others?
Or are they all predefined instances with factory and normal __call__ methods?
Am I mistaken about the apparent extra ")" below?
> template = body[
body()[ # might be more consistent?
> table(id="outer", width="100%", height="100%", border="0")[
> tr(valign="bottom")[
> td(id="output", width="75%", valign="top", model="latestOutput")[
> div(pattern="listItem", view="html")[
> "Foo"
> ]
> ],
> td(id="room-contents", valign="bottom")[
> strong[
> "Stuff you have"
> ],
> div(model="playerInventory", view="List")[
>
> # Note programmatic elements
> if_(not arg1)
> [
> div(_class="item")["Nothing"]
> ].else_
> [
> for_each(arg1)
> [
> div(
> style=["color: red", "color: blue", None]
> , view="item"
> , controller="look")[arg1]
, controller="look" # or drop the ")" of the next line?
> )
)[arg1] # or drop the ")" of the previous line?
> ]
>
> ]
> ]
> ]
> ]
> ]
> ]
>
> # invoke the template with some data
> template(['foo', 'bar', 'baz', 'another item'])
>
>which generates:
[ ... snip ...]
>I really loved this because it was the result of healthy
>cross-pollination between the cultures and techniques of two very
>different programming communities: Python and C++.
>
It's always nice to see people of different cultures able to
overcome xenophobia etc. and have a good time, but what did C++
per se actually have to do with the above? Was it done in C++ first?
;-)
Regards,
Bengt Richter
David Abrahams
> On Sun, 20 Apr 2003 05:21:41 -0400, David Abrahams <da...@boost-consulting.com> wrote:
> [...]
>>
>>I don't care much about XML programming (haven't had a use for it),
>>but at PyConDC recently I got together with a couple of guys from the
>>Twisted project who do care, and designed a nice little meta-language
>>in Python for doing this sort of template processing. Here's a little
>>example of it in action:
> Interesting ;-) Did you snip that from a working version?
I never had a working version of the code on my machine, but we fed
that code to Bob (never knew his last name) 's implementation and it
worked. You'd have to contact Donovan Preston to get ahold of the
code.
> I didn't work one up, but I'd guess the approach was to define
> classes or factory functions for body, table, tr, td, etc.
Actually those are defined as follows:
body = xml.body
table = xml.table
tr = xml.tr
td = xml.td
etc., so if you don't have a predefined constant for any given tag you
can just write:
xml.sometag(attr1="value1", attr2="value2", ...)[ "contents" ]
xml's __getattr__ method returns an object with a __call__ method and
a __getitem__ method (in case there are no attributes), etc.
> and have them return suitable objects with suitable __getitem__
> methods. So "body" seems like a predefined object, unlike the
> others? Or are they all predefined instances with factory and
> normal __call__ methods?
See above.
> Am I mistaken about the apparent extra ")" below?
No, you're not. I must've mangled the text by mistake at some point.
> [ ... snip ...]
>>I really loved this because it was the result of healthy
>>cross-pollination between the cultures and techniques of two very
>>different programming communities: Python and C++.
>>
> It's always nice to see people of different cultures able to
> overcome xenophobia etc. and have a good time, but what did C++
> per se actually have to do with the above? Was it done in C++ first?
We've been doing this sort of thing in C++ libraries to get deferred
evaluation and high-performance computation since at least 1994. See
http://osl.iu.edu/~tveldhui/papers/Expression-Templates/exprtmpl.html,
a seminal paper on the subject, and then look at some more-evolved
examples of the techniques:
http://www.boost.org/libs/lambda/doc/index.html#introduction
and finally,
http://spirit.sourceforge.net (also at
http://www.boost.org/libs/spirit).
which takes the benign abuse of operator overloading to an extreme.
Python is actually a much better language for the XML case, in part
due to its support for keyword arguments which map nicely onto
attributes.
David Abrahams
> On Sun, 2003-04-20 at 17:00, David Abrahams wrote:
>> I don't understand; it already *is* plain Python. While Donovan
>> Preston and I were designing the syntax, his friend Bob was sitting on
>> the couch coding it up.
>
> Hmmm... I guess so. I was thinking of lists following an object, but it
> actualy gets parsed as a __getitem__ with a tuple as an argument.
Yes.
>> > The use of []'s isn't really necessary, and actually the expressions
>> > could maybe be eval'd as well...
>>
>> You've lost me here. Lots of the "syntax" choices aren't based on
>> what's neccessary, but on what's clear and expressive. As far as
>> "eval" is concerned, well, I'm not sure if you realize this but those
>> if_ and for_each elements are lazily evaluated. The expression
>> creates a callable object, "template", which generates new XML.
>
> So it's not actually a Python program, it's Python syntax
And that's different from a Python program how? <.02 wink>
> that gets evaluated by your own evaluator...?
Basically, yes, though the evaluator might be built into the object
that gets constructed.
> I was trying to see if it could be an actual Python program, which
> would construct an object you could use later to handle the XML.
I think if you go in that direction it will end up looking much as it
does... the problem, as you say, is that code blocks are not
first-class objects in Python. Of course, that goes even further in
the direction of lambda-expressions than we've gone already, which is
the opposite of the direction GvR has been headed. On the other hand,
he recently started talking about adding support in the future for the
design of domain-specific languages (which this XML example was), and
I don't really see how you can do that job well without first-class
code blocks.
Mark E.
> xml.sometag(attr1="value1", attr2="value2", ...)[ "contents" ]
Of course there are always corner cases to deal with. For example, what's a good way
to handle XHTML's 'class' attribute?
xml.sometag(class="css_class_name")["contents"]
won't work.
One could map 'foo_' to 'foo' to handle conflicting names used in xml/html, or allow
a dictionary to serve the same purpose:
xml.sometag({"attr1" : "value1", "class" : "value2"})["contents"]
Mark
--
Mark E.: snowball3#&0064;softhome.net
David Abrahams
Sure, you have lots of options. Also:
xml.sometag(class_("value2"), attr1 = "value1")["contents"]
xml.sometag({'class':"value2", 'while':"value3"}, attr1 = "value1")["contents"]
xml.sometag(attr1 = "value1", _ = {'class':"value2", 'while':"value3"})["contents"]
it's all in the fun of designing domain-specific sublanguages.
Paul Boddie
> On 18 Apr 2003 11:01:48 -0700, bitb...@safe-mail.net (poiboy) wrote:
>
> >Neglecting the inherent joy of an education, I believe the cost of using XSLT
> >exceeds what benefits it may have (portability, and..) and is likely more
> >expensive than successive rewrites with other template systems.
But XSL is primarily a transformation language and not a templating
system, especially since templating systems often have domain-specific
features that reduce the verbosity. Moreover, it makes most sense to
use XSL(T) when you're working in an environment with the necessary
XML and XSL tools already in place, and where it isn't necessarily
going to be easier to write program code to do the transformations.
For example, I've used XSLT to process XML documents that have been
generated from various Java libraries, and that processing would have
been tedious to do by either modifying those Java libraries, or by
writing some Java classes and generating the output from the code.
> Many have said that to me in private or on the phone. Few have
> been brave enough to say it on Usenet. Bravo :-)
I'm not sure. Search for "XSLT overkill group:comp.text.xml" on
Google, for example. :-)
Paul
Bob Ippolito
well, in our implementation (off the top of my head) these are valid:
xml.sometag(_class = 'value2', attr1='value1')['contents']
xml.sometag({'class':'value2'}, attr1='value1')['contents']
xml.sometag('class="value2"', attr1='value1')['contents']
xml.sometag(('class', 'value2'),), attr1='value1')['contents']
The preferred is the first, it's easiest. It's assumed that you will
never want an attribute that actually starts with an underscore. If
you do (probably never), you'll have to use one of the other three
options.
-bob
David Abrahams
> David Abrahams <da...@boost-consulting.com> wrote in message news:<848yu3o...@boost-consulting.com>...
>> Sure, you have lots of options. Also:
>>
>> xml.sometag(class_("value2"), attr1 = "value1")["contents"]
>>
>> xml.sometag({'class':"value2", 'while':"value3"}, attr1 = "value1")["contents"]
>>
>> xml.sometag(attr1 = "value1", _ = {'class':"value2", 'while':"value3"})["contents"]
>>
>> it's all in the fun of designing domain-specific sublanguages.
>
> well, in our implementation (off the top of my head) these are valid:
>
> xml.sometag(_class = 'value2', attr1='value1')['contents']
> xml.sometag({'class':'value2'}, attr1='value1')['contents']
> xml.sometag('class="value2"', attr1='value1')['contents']
> xml.sometag(('class', 'value2'),), attr1='value1')['contents']
>
> The preferred is the first, it's easiest. It's assumed that you will
> never want an attribute that actually starts with an underscore. If
> you do (probably never), you'll have to use one of the other three
> options.
Hey, thanks for piping up, Bob! If you've got an implementation of
this, you must be the same Bob who sat on the couch at PyCon and coded
this stuff up while Donovan Preston and I were designing the
syntax... you sure were a Python-coding machine! A pleasure to meet
you; I never caught your last name. I guess if you still have an
implementation, it's still working out for you... (?)