quetz-mod_python-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Fraser <dav...@sjsoft.com>
Subject Re: Talking about PSP: Internals
Date Thu, 10 Apr 2003 19:19:59 GMT
Sterling Hughes wrote:

>On Thu, 2003-04-10 at 12:55, Michael C. Neel wrote:
>>	I'm not a fan of PHP, I don't think it lends itself well to
>>large systems.  This is because I don't care to have heavy amounts of
>>code mixed into a template; I don't like having my data, design, and
>>logic mixing (and yes Sterling, I read your thoughts on that in your
>>blog =p).  Not to say that is not possible in PHP, it is, but to me it
>>feels a bit awkward and may lead to the several include issue I
>>mentioned above.
>Hehe.  This conversation could go on for years without an end - I'm
>Just a note that in the current infrastructure you can use psp as your
>templating language.  Just import _psp  and use the _psp.parse and
>_psp.execute functions.  I have some better support for this in my local
>versions, which should make it in soon.  That way if you want very
>nicely relegated code and logic, you have it.  You'll even be allowed to
>pass a dictionary of objects to psp files, which will become globally
>accessable from within the psp template.
I think the advantage of psp is for systems where you're doing more html 
than Python.
If you need a lot of Python work to generate that HTML, the 
intermingling would get in the way...
But I've never programmed PHP so this may be ignorance...

>>	So my point is in here that for psp, we should be open to other
>>methods than the ones used in php and not assume that the php methods
>>are the best ones for python.  Which brings me to my next point...
>>3.  What is psp offering over php?  Are we simply going for a php but
>>with python syntax?  I'm not sure that would be the best use of the
>>strengths of the python language.  I am a strong fan of the Albatross
>>system, which I think does make use of the python strengths such as
>>extensibility and, for lack of a better term, "clean" code.
>I agree with you (we need to offer more than php).  One thing I think
>you underestimate however is just how important python syntax is.  Yes,
>whitespace is a bitch when it comes to embedding python in html ('{' and
>'}' are optional additions to whitespace, when you use PSP).
I don't see how whitespace is a problem. You just need to think more 
python-centric than html-centric.
But then again, the whole framework requires that you mark you python 
with psp tags... and that might require a different approach (see my 
other mail)

>One of the things immediately attractive about python is the
>performance, OO wise.  PHP is perfectly fast running procedural code,
>however if you look at PHP's OO model (PHP5 is the first version with a
>real model to speak of), you'll see a system that *must* run with the
>following requirements::
>1) Single Pass, Non optimizing compiler
>2) Stack based virtual machine running P-Code
>And pages are parsed on *every* request unless you couple it with an
>optimizer/compiler cache.  There are already signs of language
>optimizations that shouldn't be, ie, import is global to the scope of a
>project, to improve performance since resolution is done at runtime.  If
>you're running PHP4 systems, its even worse, objects are base types.
And you can do funky things with objects :-) Not sure how the PHP ones 
work, but you can do just about anything with the Python ones.
Metaclasses, inspection, function wrapping ... very cool. For a simple 
example of function wrapping:

def header(title):
  return "<head><title>%s</title></head>" % title

def body(text):
  return "<body><p>%s</p></body>" % text

def mypage(title, text):
  return "<html>" + header(title) + body(text) + "</html>"

def logfunction(fn):
  def logfn(*args):
    print "calling function %r with args %r" % (fn, args)
    result = apply(fn, args)
    print "leaving function %r, result %r" % (fn, args)
    return result
  return logfn

header, body, mypage = [logfunction(fn) for fn in (header, body, mypage)]

print mypage("title","this is the text")

>>4.  To be useful to a large selection of python users, psp will need to
>>have quite an api with it.  While things like databases, session
>>management, and input validation are outside of the scope of mod_python
>>(rightfully so), I think they are within the scope of psp.
>>I don't want to sound down on the project, I'm feel quite the opposite.
>>Python needs something other than Zope to be it's "killer app"; Zope I
>>think scares more people away from python than it brings to python.  Psp
>>is in a much better position to introduce python to more people, and
>>that's always a good thing.
>That's a part of my second mail (not yet written), I wholeheartedly
>agree.  My first step is just to get the basics working (rewriting, and
>a few basic utilities.)  Then I think there should be a focus (how much
>I still don't know) on adding some killer features. :)
>I don't think the mod_python should bundle anything outside of the scope
>of HTTP.  I think mod_python + psp should really focus on being a two
>part thing:
>1) PSP supports an extensible set of common http routines.  This
>includes accessing get, post data.  Setting/getting cookies.  managing
>session information (this is one area php does beautifully,
>http://www.php.net/manual/en/ref.session.php), etc.  These common
>routines are always available to PSP applications.
Yup, sessions is something that's definitely important...
Looking forward to what comes out of this,


View raw message