Could a single web framework popularize Python?
ted
But I'm wondering why there isn't a dominant web framework besides Zope?
I think if Python had something along the lines of a Jakarta Tomcat that was
actively developed, it would help popularize Python.
Any thoughts.
-Ted
Dave Benjamin
> I'm just staring out with Python and it looks great.
Good to hear. =)
> But I'm wondering why there isn't a dominant web framework besides Zope?
Well, mostly because there are so many available web frameworks for
Python that nobody can agree on which one is best. Zope and Webware seem
to be the most popular. Then, there's Twisted, which is (I'd say) the
dominant/most popular general-purpose networking framework for Python.
> I think if Python had something along the lines of a Jakarta Tomcat that was
> actively developed, it would help popularize Python.
I'd take mod_python over Tomcat in a heartbeat. Give me real Apache or
give me... well, another webserver besides Tomcat. =)
Peace,
Dave
Ian Bicking
> I'm just staring out with Python and it looks great.
>
> But I'm wondering why there isn't a dominant web framework besides
> Zope?
Because everyone has made their own, and no one can agree on what a
dominant web framework might be. Zope *was* that framework, with
dominant mindshare, but it didn't keep other people from making other
frameworks.
There's already a ton of frameworks, but I think I saw two brand new
ones on PyPI this last week. Crazy.
> I think if Python had something along the lines of a Jakarta Tomcat
> that was
> actively developed, it would help popularize Python.
Yes, I think that would be great. But I'm not sure how we get to there
from here. This isn't a problem because of a lack of interest, nor for
a lack of code.
--
Ian Bicking | ia...@colorstudy.com | http://blog.ianbicking.org
Dave Harrison
> dominant web framework might be. Zope *was* that framework, with
> dominant mindshare, but it didn't keep other people from making other
> frameworks.
>
> There's already a ton of frameworks, but I think I saw two brand new
> ones on PyPI this last week. Crazy.
hehehe.... my opinion is that development in python is fun, I doubt any
on this list would really disagree with me on that point ;-)
which ultimately means people are much more likely to say, "oh we need a
system that does X, sure, we can write that ourselves !" while chuckling
and rubbing their hands with glee at the prospect ;-)
so we end up with a huge range of tools for the same kinds of things.
vive la python !! ;-) *laughs*
ted
http://www.russellbeattie.com/notebook/20030725.html#125136
Talks about finding a good web framework. Here's an excerpt:
"So in my humble opinion, it would be great if a corporate entity - bigger
and more influential than Zope - started pushing Python a bit more.
Documentation, standards, application server reference implementations, etc.
In other words, a bit more like Java. There's got to be a middle ground
between tight corporate control and open source free-for-all. Corporate
sponsership (say by IBM or even Intel or some company of that stature) would
also give a boost to its use throughout the rest of the corporate world and
maybe give a boost to the numbers of jobs looking for Python skills. The
Python people who are happy with the status quo will probably think I'm
nuts, and that's fine. I'm writing this for the teeming hoards of Java
programmers looking around for something a bit funner (and more productive)
to use who are going to run smack into the same issues I've run into."
"Dave Harrison" <da...@nullcube.com> wrote in message
news:mailman.1065496032...@python.org...
Holger Krekel
> On Monday, October 6, 2003, at 09:11 PM, ted wrote:
> >
> > But I'm wondering why there isn't a dominant web framework besides
> > Zope?
>
> dominant web framework might be. Zope *was* that framework, with
> dominant mindshare, but it didn't keep other people from making other
> frameworks.
>
> There's already a ton of frameworks, but I think I saw two brand new
> ones on PyPI this last week. Crazy.
Maybe the current web frameworks are just not good enough? Also, there
are many different perspectives on how to do web-applications or
generate pages.
The best i hope for is factoring out common functionality into small
modules which eventually make it into the standard library. It's
not easy to get there, though. Analyzing the existing frameworks
down to the module level would be a good start, i guess.
Maybe the cost of sharing and reusing code is too high. If you e.g.
want to use a module from another project but not the whole thing
it's inconvenient and fragile to do this. Actually the Zope3-developers
tried to refactor common functionality into independent packages
(ZODB, the TAL-interpreter, security etc.) but i am not exactly sure
how well this will work out. It's still a huge thing with many pieces.
I like to think that the problem lies with the *framework* character
when i really just want a *library/module* that i can use. Frameworks
tend to impose a specific view of the world you have to adapt to. Thus
many people decide to roll their own ... often resulting in the
same problems for others. It's a vicious circle.
just my 2ec,
holger
Gilles Lenfant
nEpgb.18499$%o6.1...@news1.central.cox.net...
> ted wrote:
>
> > I'm just staring out with Python and it looks great.
>
> Good to hear. =)
>
> > But I'm wondering why there isn't a dominant web framework besides Zope?
>
> Well, mostly because there are so many available web frameworks for
> Python that nobody can agree on which one is best. Zope and Webware seem
> to be the most popular. Then, there's Twisted, which is (I'd say) the
> dominant/most popular general-purpose networking framework for Python.
Twisted is *not* a web publishing framework. It's a low level protocol
framework, in the same family of packages as Medusa.
Or I missed something :o)
--Gilles
Alex Martelli
...
>> to be the most popular. Then, there's Twisted, which is (I'd say) the
>> dominant/most popular general-purpose networking framework for Python.
>
> Twisted is *not* a web publishing framework. It's a low level protocol
> framework, in the same family of packages as Medusa.
> Or I missed something :o)
Twisted comprises both lower and higher levels. E.g., see
http://www.twistedmatrix.com/services/twisted-advantage
and I quote:
"""
Publish a Web Site
The twisted.web webserver is a scalable, small-footprint web server that's
easy to configure. It's efficient enough to serve a high-traffic website,
completely dynamic and reconfigureable on the fly, and simple enough to
configure that you can have it set up and running in just minutes after
you've downloaded it.
"""
Alex
Ian Bicking
Twisted is more like Apache or mod_python than a web framework. Woven
is a framework built on top of Twisted, and the closest thing to The
Twisted Web Framework.
Working directly with Twisted is like writing Python CGI scripts.
Sure, it works, but it's not a "framework". Of course, you can build a
framework on top of it (and you probably will be accident if not
intention).
It gets confusing, though, because Twisted is both a specific program
-- the Twisted server -- and a collection of tools and ideas, as well
as an execution model (asynchronous) that becomes a defining aspect of
Twisted. Woven's architecture is strongly influenced by the
requirements of asynchronous programming. So while there's nothing
keeping other frameworks from working on top of Twisted, Woven is one
of the few (only?) that would really be Twisted style. And of course
Woven is the only real framework included with the Twisted distribution.
Dave Benjamin
> On Tuesday, October 7, 2003, at 07:10 AM, Alex Martelli wrote:
>> Twisted comprises both lower and higher levels. E.g., see
>> http://www.twistedmatrix.com/services/twisted-advantage
>
> is a framework built on top of Twisted, and the closest thing to The
> Twisted Web Framework.
>
> Working directly with Twisted is like writing Python CGI scripts.
> Sure, it works, but it's not a "framework". Of course, you can build a
> framework on top of it (and you probably will be accident if not
> intention).
I guess it'd help to have a definition for what a web framework really is.
When I was working with mod_python a lot, I definitely had some
infrastructure to build, but it wasn't massive. It was basically a
combination of the following:
- database interface
- session handling
- cookie support (mostly already in the standard Python libs)
- templating
- publisher module (url->function mapping)
- assorted libraries (xml, imaging, etc.)
So, I'd say about half of the "framework" was available as Python libraries
(either built-in or third-party), and the main gaping holes were session
handling and templating. Since then, both of these are also available as
third-party modules.
Maybe Python doesn't have ONE_TRUE_FRAMEWORK because you have a choice in a
lot of these different domains. Maybe that's a blessing in disguise. It does
require that you think and actively make decisions about your architecture.
Dave
--
.:[ dave benjamin (ramenboy) -:- www.ramenfest.com -:- www.3dex.com ]:.
: d r i n k i n g l i f e o u t o f t h e c o n t a i n e r :
Ian Bicking
> I guess it'd help to have a definition for what a web framework really
> is.
> When I was working with mod_python a lot, I definitely had some
> infrastructure to build, but it wasn't massive. It was basically a
> combination of the following:
>
> - database interface
> - session handling
> - cookie support (mostly already in the standard Python libs)
> - templating
> - publisher module (url->function mapping)
> - assorted libraries (xml, imaging, etc.)
A framework is the stuff piece that fits those all together (of
course!) -- at least that fits the literal concept of "framework", and
also works in practice pretty well. Typically a framework also
provides some of those pieces too, but that's often a matter of
convenience. E.g., Webware includes a PSP (template) plugin, but it is
distinct from the framework and does not exclude other templates.
Collecting (and when necessary building) components is a packaging
issue -- but packaging is extremely important, especially when you are
starting with Python web programming.
> So, I'd say about half of the "framework" was available as Python
> libraries
> (either built-in or third-party), and the main gaping holes were
> session
> handling and templating. Since then, both of these are also available
> as
> third-party modules.
>
> Maybe Python doesn't have ONE_TRUE_FRAMEWORK because you have a choice
> in a
> lot of these different domains. Maybe that's a blessing in disguise.
> It does
> require that you think and actively make decisions about your
> architecture.
This diversity also keeps people from sharing. There is no significant
sharing between people using different frameworks. With the number of
frameworks out there that means that our efforts are very diluted.
Really only one framework (Zope) has critical mass. And Zope 3 is
reaching out the rest of the Python world -- it would be nice if we
reached back. (Whoever "we" are...)
But we don't have to eschew diversity to achieve interoperability. We
do have to try, though, because it won't happen on its own, and it
hasn't happened so far.
Alan Little
experienced (16 years) corporate developer who has worked on a lot of
big database systems and a couple of java/XML web services projects.
I'm finding python much more pleasant and productive to work with than
java, but it's frustrating that there is no clear (de facto) standard
for developing web systems. I've been following this discussion with
interest. Here are my thoughts on the subject - which are a series of
semi-disconnected bullet points, not a coherent essay.
I see no real likelihood of python ever eating a significant chunk of
the corporate big systems market - there's too much already invested
in J2EE (not to mention older architectures that are still heavily
used like CORBA and CICS). Java is more than good enough for the job
and the skills are readily available. Why would anybody risk their
company and their job on a completely unproven environment just
because it happens to use a nicer programming language? Coding
productivity as such is less important in this environment than proven
reliability and compatibility with existing environments.
Yes I know there are exceptions. "Google uses python" etc. etc. Google
started four years ago and did not have millions already invested in
Java, Cobol, SAP, Oracle business-critical systems. And Google uses
python for what? If they use it to drive their extremely high traffic
and usually admirably fast web front end, they're unlikely to tell
anyone how. And even if they did, their problem is very large numbers
of simple, read-only transactions none of which matter individually.
This is entirely different from, say, a typical financial system where
you have fairly large numbers of update transactions, some of them
complex, where the integrity of individual transactions matters a
great deal.
What do you mean by a "web framework"? In the Java world, JSP and
servlets are a subset of J2EE, the rest of which is aimed at
scaleability and transaction integrity for big corporate applications
that might just happen to have a web interface as one of their front
ends. (A large proportion of corporate back office systems that are
*really* serious about scaleability and transaction integrity are
probably still running CICS on mainframes, but that's a whole 'nother
story). Full-blown J2EE is overkill for [practically anything?]
applications that just want read & update one database via a web front
end.
So are you talking about a python equivalent of Tomcat, a python
equivalent of jBoss, or a python equivalent of the J2EE standard (with
something like Tomcat as a reference implementation of part of it),
where different products could implement different subsets but there
would be at least some hope of interoperability and portability? I'm
not necessarily saying that an overblown formal standard like J2EE is
the best way to go. "Rough consensus and running code" is a better way
to arrive at de facto standards that actually work in the long run.
But in the python web world at the moment there seems to be a surfeit
of "running code" in varying states of maturity, and no discernible
"rough consensus" about how to hang it all together.
Learning J2EE for a Java programmer is easy. If you're being paid by
your employer to learn it, you use what they use. If you're doing it
with your own time & money, the only decision you have to make is
which servlet engine to use in front of jBoss. Either way, you spend
maybe half a day installing and messing about with deployment files,
and you're off. You may not be taking much advantage of all the
facilities the environment has to offer, but you're up and running and
can learn gradually from there - the mountain is high, but the
learning curve isn't steep. (Horrible mixed metaphor, sorry).
With python, you face a non-trivial research project even deciding
which environment you're going to use.
The thing you're going to hear most about is Zope, but you're also
going to hear that Zope has a high & steep learning curve before you
can get anything working at all, and that even although Zope itself
is built using python, any existing python skills you may have aren't
going to be particularly relevant for building applications that use
it, for which you're going to have to learn some wierd template
language instead. I don't know if these things are necessarily
completely true or up to date, but they *are* what newcomers hear, and
in the case of this newcomer they were enough to put me off even
considering learning Zope.
If you decide not to use Zope, you have a choice of a wide variety of
wierd & wonderful offerings that address different but overlapping
subsets of the problem at varying levels of prototypishness. There is
no consensus as to what the emerging or de facto standards are, no
particular reason to believe that whatever you choose will be
supported or widely used in three years time - and if it isn't, the
skills you're invested your valuable time acquiring won't be directly
usable with whatever else is around. See the J2EE example above - if
BEA were to go out of business, the Weblogic folks wouldn't have much
difficulty switching their hard-earned skills over to jBoss.
My personal decision was that the advantages of python as a language
are so great that it's worth spending a bit of time finding something
that will run it nicely behind a web server for small personal
projects. I chose webware and I'm having fun playing with it. In its
current state I wouldn't feel at all confident about using or
recommending it for any kind of serious production system, even if it
was in a greenfield situation where the comments above about legacy &
compatibility didn't apply.
I don't understand all this talk about twisted as a transport
mechanism. The web runs on Apache (~70%) and IIS (~25%). Anything that
aspires to be at all widely adopted has to have speed and stability
running behind one or both of those as one of its primary goals. I
don't know much about twisted - perhaps somebody could explain where
it fits into that picture?
Alan Little
http://www.alanlittle.org/weblog
Ian Bicking
> I see no real likelihood of python ever eating a significant chunk of
> the corporate big systems market - there's too much already invested
> in J2EE (not to mention older architectures that are still heavily
> used like CORBA and CICS). Java is more than good enough for the job
> and the skills are readily available. Why would anybody risk their
> company and their job on a completely unproven environment just
> because it happens to use a nicer programming language? Coding
> productivity as such is less important in this environment than proven
> reliability and compatibility with existing environments.
While you might be right that Python won't get a significant chunk of
J2EE, for Python just a small chunk would be a huge win. Taking 1%
from Java increases Python by 100% (okay, I'm making up the numbers).
Of course, Java isn't the only web development language to compete
with. Both PHP and Perl are quite significant, especially for a
certain demographic (the hacker type, vs. the Professional Programmers
that use Java). Personally I think Perl is on the way down, and has
been for a while -- Perl 6 is a disaster that won't even arrive, and in
general the thrill of Perl is gone. PHP is almost more vulnerable,
because it's support is so shallow -- at least Perl programmers have a
certain loyalty, PHP programmers usually just fall into the language.
Of course, as a Free Software advocate in general, I (we) shouldn't
really celebrate their loss. Java would be a more appealing opponent.
Or more appealing yet, if we could be the alternative for people who
might use ColdFusion or ASP.
PHP's success, as I see it, has been from its shallow initial learning
curve (nevermind the ceilings you'll hit). Beginning web programmers
get stuff done quickly, it keeps them working, and if PHP is used in
larger, more formal situations it's because those
once-beginning-programmers have some influence later on in their
careers. I think ColdFusion and to a degree even ASP are similar.
Maybe Python can have a similar success. We aren't going to sell to
the top, but we have something good to offer the bottom.
> Yes I know there are exceptions. "Google uses python" etc. etc. Google
> started four years ago and did not have millions already invested in
> Java, Cobol, SAP, Oracle business-critical systems.
It's not like people have 20 years invested in Java. Nor that the 20
years of investment of COBOL leads people to write web applications in
that language. So there's still room.
> And Google uses
> python for what? If they use it to drive their extremely high traffic
> and usually admirably fast web front end, they're unlikely to tell
> anyone how. And even if they did, their problem is very large numbers
> of simple, read-only transactions none of which matter individually.
> This is entirely different from, say, a typical financial system where
> you have fairly large numbers of update transactions, some of them
> complex, where the integrity of individual transactions matters a
> great deal.
>
> What do you mean by a "web framework"? In the Java world, JSP and
> servlets are a subset of J2EE, the rest of which is aimed at
> scaleability and transaction integrity for big corporate applications
> that might just happen to have a web interface as one of their front
> ends. (A large proportion of corporate back office systems that are
> *really* serious about scaleability and transaction integrity are
> probably still running CICS on mainframes, but that's a whole 'nother
> story). Full-blown J2EE is overkill for [practically anything?]
> applications that just want read & update one database via a web front
> end.
>
> So are you talking about a python equivalent of Tomcat, a python
> equivalent of jBoss, or a python equivalent of the J2EE standard (with
> something like Tomcat as a reference implementation of part of it),
> where different products could implement different subsets but there
> would be at least some hope of interoperability and portability?
Since Python isn't proprietary, and doesn't encourage proprietary
offerings, something like the J2EE standard is unnecessary. An
implementation *is* the standard, just like CPython is the standard
definition of the language.
The irony is that there's lots of offerings, but there's not actually
lots of diversity. Most people just keep creating the same boring
infrastructure over and over, with small changes that provide a
slightly better fit to their coding flow and aesthetic sense.
There's a few novel offerings -- Zope, maybe Woven... and I'm not sure
that novelty is a good feature anyway. The rest are just different in
the details, and maybe have a different subset of features.
I feel like I'm sounding very pessimistic now. Maybe I am. The
current state of affairs is boring! Perhaps the worst sin of all...
> There is
> no consensus as to what the emerging or de facto standards are, no
> particular reason to believe that whatever you choose will be
> supported or widely used in three years time - and if it isn't, the
> skills you're invested your valuable time acquiring won't be directly
> usable with whatever else is around. See the J2EE example above - if
> BEA were to go out of business, the Weblogic folks wouldn't have much
> difficulty switching their hard-earned skills over to jBoss.
Eh, I don't worry too much about that. As long as the framework isn't
insular (which might rule out Zope and asynchronous Twisted
programming) it's easy to translate knowledge into another framework.
Python is Python, and that's really where your application is written.
But if there was some sort of standardization, I personally feel
strongly it should support the current frameworks running on top of
that standard. The early adopters don't deserve to be jilted, and
that's no way to build confidence in the standard either.
> My personal decision was that the advantages of python as a language
> are so great that it's worth spending a bit of time finding something
> that will run it nicely behind a web server for small personal
> projects. I chose webware and I'm having fun playing with it. In its
> current state I wouldn't feel at all confident about using or
> recommending it for any kind of serious production system, even if it
> was in a greenfield situation where the comments above about legacy &
> compatibility didn't apply.
>
> I don't understand all this talk about twisted as a transport
> mechanism. The web runs on Apache (~70%) and IIS (~25%). Anything that
> aspires to be at all widely adopted has to have speed and stability
> running behind one or both of those as one of its primary goals. I
> don't know much about twisted - perhaps somebody could explain where
> it fits into that picture?
Twisted's HTTP probably isn't the most interesting part -- it's
certainly not what attracts most people to it. More interesting is
Twisted's support for other protocols, like Jabber or SSH. Being
Python it's a bit more nimble, which is something the core of Apache
can't offer for the aspiring low-level networking programmer. Also
Twisted is a bit easier to pull apart. Then there's the asynchronous
programming -- you love it or you hate it -- but that's another
discussion. (Honestly I've never tried it enough to know, but I'm so
skeptical of the ability of asynchronous programming to appeal to a
general audience of programmers that I haven't bothered to give it a
real try)
Robert Brewer
> > I see no real likelihood of python ever eating a
> significant chunk of
> > the corporate big systems market - there's too much
> already invested
> > in J2EE (not to mention older architectures that are still heavily
> > used like CORBA and CICS). Java is more than good enough for the job
> > and the skills are readily available. Why would anybody risk their
> > company and their job on a completely unproven environment just
> > because it happens to use a nicer programming language?
Well, I did both; risked my company and my job. I worked for two years
to get management to agree I needed to rewrite our core business app: a
web app written in VB4!! I was then told to "do it in ASP". I refused,
and am now rewriting it in Python. I risked my job because I felt, given
our IT management history, that betting our systems on ASP or .Net would
be a medium-to-long-term disaster from which we would not recover.
Granted, we are a smallish business, developing our own software for our
own use. However, you did ask. ;)
Ian Bicking wrote:
> Of course, as a Free Software advocate in general, I (we) shouldn't
> really celebrate their loss. Java would be a more appealing
> opponent.
> Or more appealing yet, if we could be the alternative for people who
> might use ColdFusion or ASP.
Glad to appeal. :)
> Eh, I don't worry too much about that. As long as the
> framework isn't
> insular (which might rule out Zope and asynchronous Twisted
> programming) it's easy to translate knowledge into another
> framework.
> Python is Python, and that's really where your application is written.
>
> But if there was some sort of standardization, I personally feel
> strongly it should support the current frameworks running on top of
> that standard. The early adopters don't deserve to be jilted, and
> that's no way to build confidence in the standard either.
FWIW, I am writing my own framework. I have to integrate with a third
party's proprietary CRM product, and I simply felt better about adapting
my own framework to it than trying to add components onto Twisted or
Zope or the framework du jour. Regardless, I make every effort to give
others the freedom to use my code and *easily* replace/extend what
doesn't work for them. It may never have another developer, but it makes
my future brighter to be so maintainable. I like to think I could rip
out a good chunk and replace it with Twisted, etc. in a short time if
the need arose.
Had to provide an anecdote.
Robert Brewer
MIS
Amor Ministries
fuma...@amor.org
Alex Martelli
...
> that use Java). Personally I think Perl is on the way down, and has
> been for a while -- Perl 6 is a disaster that won't even arrive, and in
> general the thrill of Perl is gone. PHP is almost more vulnerable,
I think you're wrong, but I admit I'm guessing. To me, particularly
networking at OSCON, it seemed as if Parrot was generating lots of buzz.
> because it's support is so shallow -- at least Perl programmers have a
> certain loyalty, PHP programmers usually just fall into the language.
Interesting, because to me it seemed very different - i.e. as if the
_sociology_ of PHP was an example well worth studying and perhaps trying
to get inspiration from. I've often seen PHP'ers moving to Python
bemoan the fact that www.python.org isn't community-run and intense-
community-involvement the way www.php.org is -- that seems as inevitable
a complaint as Perlites-moving-to-Python's hankering for CPAN.
> PHP's success, as I see it, has been from its shallow initial learning
> curve (nevermind the ceilings you'll hit). Beginning web programmers
> get stuff done quickly, it keeps them working, and if PHP is used in
Sounds credible, but I think it may ignore the "buying into the
community" sociological effect. But, I _am_ just musing/guessing.
> Since Python isn't proprietary, and doesn't encourage proprietary
> offerings, something like the J2EE standard is unnecessary. An
It may not be indispensable, but it WOULD help a lot in avoiding
fragmentation of effort -- just like e.g. the DBAPI helps a bit
(and could do more) to help avoid fragmentation there.
> implementation *is* the standard, just like CPython is the standard
> definition of the language.
I don't think that's necessarily a good thing. One of the hopes of
the pypy project is eventually supplying a better "executable
pseudocode" definition;-).
>> With python, you face a non-trivial research project even deciding
>> which environment you're going to use.
True, and important (for both Web and GUI programming, BTW).
> Twisted's HTTP probably isn't the most interesting part -- it's
> certainly not what attracts most people to it. More interesting is
> Twisted's support for other protocols, like Jabber or SSH. Being
That's definitely how I got into Twisted -- via the lower level
only (I still haven't used any of the upper layers yet). Not sure
it generalizes all that much, though.
> Python it's a bit more nimble, which is something the core of Apache
> can't offer for the aspiring low-level networking programmer. Also
> Twisted is a bit easier to pull apart. Then there's the asynchronous
> programming -- you love it or you hate it -- but that's another
> discussion. (Honestly I've never tried it enough to know, but I'm so
> skeptical of the ability of asynchronous programming to appeal to a
> general audience of programmers that I haven't bothered to give it a
> real try)
This sounds to me like claiming that "a general audience of programmers"
will never be able to do GUI's because just about all of them require
event-driven, i.e. asynchronous, programming. And yet, what loomed like
a huge issue back in the time of (e.g.) early Macs / Windows / X now
doesn't seem anywhere like so terrible -- teaching GUI programming,
even in C, is quite easy (http://www.aleax.it/TutWin32/index.htm --
in Italian -- for an example; I have successfully used that material
to get beginning C programmers to code simple Windows GUI's on the bare
API's without breaking a sweat...).
Alex
A.M. Kuchling
Alex Martelli <al...@aleax.it> wrote:
> I think you're wrong, but I admit I'm guessing. To me, particularly
> networking at OSCON, it seemed as if Parrot was generating lots of buzz.
Buzz, sure -- people are willing to *talk* about it, but people are willing
to talk and opine about anything. When it comes to actually devoting coding
time to the project, however, people are much more conservative.
> to get inspiration from. I've often seen PHP'ers moving to Python
> bemoan the fact that www.python.org isn't community-run and intense-
> community-involvement the way www.php.org is -- that seems as inevitable
> a complaint as Perlites-moving-to-Python's hankering for CPAN.
Did you mean PHP.net, not PHP.org? PHP.org seems to be just a bunch of
forums; PHP.net has more content, but it's not clear how the site is more
community-oriented than python.org; are you referring to the annotatable
documentation, or to something else?
--amk
Alex Martelli
> On Fri, 10 Oct 2003 10:18:37 GMT,
> Alex Martelli <al...@aleax.it> wrote:
>> I think you're wrong, but I admit I'm guessing. To me, particularly
>> networking at OSCON, it seemed as if Parrot was generating lots of buzz.
>
> Buzz, sure -- people are willing to *talk* about it, but people are
> willing
> to talk and opine about anything. When it comes to actually devoting
> coding time to the project, however, people are much more conservative.
That is quite possible: I have no idea how well Parrot's coding is
actually progressing, your knowledge about that is much higher!
>> to get inspiration from. I've often seen PHP'ers moving to Python
>> bemoan the fact that www.python.org isn't community-run and intense-
>> community-involvement the way www.php.org is -- that seems as inevitable
>> a complaint as Perlites-moving-to-Python's hankering for CPAN.
>
> Did you mean PHP.net, not PHP.org? PHP.org seems to be just a bunch of
> forums; PHP.net has more content, but it's not clear how the site is more
> community-oriented than python.org; are you referring to the annotatable
> documentation, or to something else?
I'm referring, vaguely and second-hand, to what PHPers trying out Python
seem to say pretty often and uniformly -- and it's quite possible that
they're referring to the .net rather than the .org site. "Annotatable"
docs (perhaps with some overview) sure sounds like a way-cool idea, but
I have no first-hand experience of how well it works in practice.
Alex
Alan Little
> Well, I did both; risked my company and my job.
I hope it turns out to be a huge success for you.
And, I must say I'm relieved. I half expected to get my head ripped
off - I've known plenty of online discussions where a newcomer who
jumped into a big hot topic discussion and started pontificating would
immediately be shot down. What a civil and intelligent bunch you
python guys are - which, I must say, goes nicely with the feel of the
language.
I'm missing the organisedness of things like the java api specs or
cpan, but python has its compensations.
Cameron Laird
Alex Martelli <al...@aleax.it> wrote:
.
.
.
>they're referring to the .net rather than the .org site. "Annotatable"
>docs (perhaps with some overview) sure sounds like a way-cool idea, but
>I have no first-hand experience of how well it works in practice.
>
>
>Alex
>
Sometimes well, sometimes miserably. When *I* come across
PHPers, yes, it's the online collaboratively-composed docu-
mentation they say they miss. Showing them the Cookbook,
the Tutorial, the Reference, and the Wiki goes a long way
toward satisfying them.
The natural follow-up, one already taking place all around
us, is to wonder how to rework python.org so people find
the Cookbook, the Tutorial, the Reference, and the Wiki on
their own.
--
Cameron Laird <cla...@phaseit.net>
Business: http://www.Phaseit.net
Nick Vargish
> they're referring to the .net rather than the .org site. "Annotatable"
> docs (perhaps with some overview) sure sounds like a way-cool idea, but
> I have no first-hand experience of how well it works in practice.
My guess is that the annotatable docs at php.net are exactly what
PHPsters mean when they talk about community. I haven't been there
for a couple of years (not doing any PHP these days), but I had
mixed feelings about the docs. On one hand, there were often
helpful tips about how to use a function. On the other hand, the
comments sometimes contradicted each other, which was kind of
daunting.
Surely there's a good Python wiki that people who like such things
can be pointed at? (I like them, but don't have much time to
actively participate on one.)
Nick
--
# sigmask || 0.2 || 20030107 || public domain || feed this to a python
print reduce(lambda x,y:x+chr(ord(y)-1),' Ojdl!Wbshjti!=obwAcboefstobudi/psh?')
Ian Bicking
> Alex Martelli <al...@aleax.it> writes:
>
>> they're referring to the .net rather than the .org site.
>> "Annotatable"
>> docs (perhaps with some overview) sure sounds like a way-cool idea,
>> but
>> I have no first-hand experience of how well it works in practice.
>
> My guess is that the annotatable docs at php.net are exactly what
> PHPsters mean when they talk about community. I haven't been there
> for a couple of years (not doing any PHP these days), but I had
> mixed feelings about the docs. On one hand, there were often
> helpful tips about how to use a function. On the other hand, the
> comments sometimes contradicted each other, which was kind of
> daunting.
And on the third hand, the PHP docs were often vague or incomplete, so
the comments were required to understand how things worked or where
related functions might be. Python stdlib docs aren't perfect, but on
the whole they are considerably better than PHP. Without comments, of
course -- with comments the PHP docs are pretty good.
A.M. Kuchling
> mixed feelings about the docs. On one hand, there were often
> helpful tips about how to use a function. On the other hand, the
> comments sometimes contradicted each other, which was kind of
> daunting.
On the third hand, the material in the comments provides a very good clue on
what's missing from a given section of documentation. If the comments were
periodically swept for ideas, it might result in significant improvement
over a few versions.
--amk
A.M. Kuchling
Well, let's get some experience. python.org already has a Wiki, so we have
a facility for editing text. It would be straightforward to have a
"View/Edit comments" link on each page that directed the user to a
corresponding Wiki page, perhaps popping it up in a separate window.
Questions:
* Including comments in the page is difficult; I looked at modifying
MoinMoin to do this, but it's not easy. So how can the link be made fairly
obvious? Links at the bottom of page aren't very obvious. A sidebar link
perhaps? (Even if we don't do annotation for the current site design, it
might be worth coming up with a good indicator for the redesigned version.)
* Should comment links be on every single page, or should they just be
limited to certain sections, such as /doc/current/?
* Does the Wiki stylesheet need to be tweaked for this use? (Perhaps by
suppressing the sidebar, for a start. Pity, after Jurgen went to all that
effort to put it there.)
--amk
Ian Bicking
> On Fri, 10 Oct 2003 12:58:49 GMT,
> Alex Martelli <al...@aleax.it> wrote:
>> they're referring to the .net rather than the .org site.
>> "Annotatable"
>> docs (perhaps with some overview) sure sounds like a way-cool idea,
>> but
>> I have no first-hand experience of how well it works in practice.
>
> Well, let's get some experience. python.org already has a Wiki, so we
> have
> a facility for editing text. It would be straightforward to have a
> "View/Edit comments" link on each page that directed the user to a
> corresponding Wiki page, perhaps popping it up in a separate window.
>
> Questions:
>
> * Including comments in the page is difficult; I looked at modifying
> MoinMoin to do this, but it's not easy. So how can the link be made
> fairly
> obvious? Links at the bottom of page aren't very obvious. A
> sidebar link
> perhaps? (Even if we don't do annotation for the current site
> design, it
> might be worth coming up with a good indicator for the redesigned
> version.)
I don't really know how the Python site is set up now, but could
comments be included inline as an SSI? Like
<!--#include virtual="/cgi-bin/moinmoin.cgi/pagename" -->
? Maybe MoinMoin can be set up to use extremely minimal markup (just
the page content and the barest of controls). I think it would be best
done as a separate wiki, maybe with a namespace that fits the library
documentation structure better. Or maybe both are possible. It would
be neat if it hooked into the normal Wiki, but found (either via some
markup or just automatically) all references to other modules and
functions and such.
> * Should comment links be on every single page, or should they just be
> limited to certain sections, such as /doc/current/?
Maybe even just /doc/current/lib -- I don't imagine comments on indexes
and such to be that useful. Well, there's several things under
/doc/current that would also make sense, but I don't think it would be
hard to make a complete list.
Some places you might not want to show the comments in the page itself,
like the tutorial -- I think it could be overwhelming and misleading.
But if possible, it would be quite advantageous to show comments on the
same page as most reference documentation.
A.M. Kuchling
On Sat, 11 Oct 2003 19:19:41 -0500,
Ian Bicking <ia...@colorstudy.com> wrote:
> I don't really know how the Python site is set up now, but could
> comments be included inline as an SSI? Like
I don't think SSIs are currently enabled, but it wouldn't be hard to turn
them on. However, I have two worries about this:
1) Fitting the comments into the page design -- a page with a lot of
comments would be really, really lengthy.
2) What if people post obscenities or harmful material?
Showing comments by default would be embarrassing; if you have to
explicitly choose to view them, this is less worrying.
Python.org has a really good Google PageRank, I expect, making it
a good target for link spam, so this is something to worry about.
The Wiki has mostly escaped such vandalism; presumably it's unobtrusive
enough that spammers haven't noticed it.
> the page content and the barest of controls). I think it would be best
> done as a separate wiki, maybe with a namespace that fits the library
> documentation structure better. Or maybe both are possible. It would
Perhaps. Wiki names can contain '/', so we can have annotations for every
single page on the site by just using the full path name. The question is
whether we need that level of support; perhaps the docs are the only place
where comments are valuable. I do think that comments on the reference
manual or the Distutils manuals would be useful. (Possibly PEPs, too?)
I did a bit of experimenting with the separate page, adding JavaScript to
ht2html's output and adding an ugly 'view comment' link. If we're
interested in pursuing this, I'm willing to do the following:
1) Make a set of experimental pages with comment links, so we can see
what they look like and how they work in practice.
2) If 1) looks worthwhile, then I'll make a new Wiki for user notes that has
minimal styling.
What I'd really need is presentation suggestions: *how* to show the comment
link?
--amk
Mike Rovner
> amk> 1) Fitting the comments into the page design -- a page with
> a lot amk> of comments would be really, really lengthy.
>
> I would prefer to see a little icon next to paragraphs with comments.
> That minimizes the change in length. Click 'em to pop up a window
> (or something) with the relevant comments.
Given that we start with wiki comments, I'd prefer to have page coments
rather than
paragraph comments. Something like DocumentationComments/ref/imaginary
for doc/current/ref/imaginary.html with page autocreation feature for new
comments
(with just back reference to the doc page and short invitation).
> amk> 2) What if people post obscenities or harmful material?
> pages, or at least to the RecentChanges page, so they are alerted
> quickly to changes. Juergen, Guido and I have all reverted Wiki
> changes.
Wiki is being maintained, it's easy to undo changes, sofar this was not a
problem.
> I'd be against anything which actually modified the content of a page
> as a result of adding a comment, if for no other reason than it would
> have to integrate with ht2html+CVS, at least for the forseeable
> future.
I second that. Wiki is too volatile, let's doc maintainer to incorporate
(valuable) wiki content into the real doc page (and update/remove wiki
comments ;))
Mike
Ian Bicking
> [CC'ing to pydotorg-redesign, and setting followups there, too.]
>
> On Sat, 11 Oct 2003 19:19:41 -0500,
> Ian Bicking <ia...@colorstudy.com> wrote:
>> I don't really know how the Python site is set up now, but could
>> comments be included inline as an SSI? Like
>
> I don't think SSIs are currently enabled, but it wouldn't be hard to
> turn
> them on. However, I have two worries about this:
>
> 1) Fitting the comments into the page design -- a page with a lot of
> comments would be really, really lengthy.
Sites that have this usually offer versions of the documentation with
and without comments.
I can imagine three places where comments would become excessive -- the
documentation has problems, the domain is inherently confusing or large
(the cgi module turns into a tutorial on CGI), or significant recipes
are included.
These are all basic Wiki refactoring problems -- editing the original
documentation (to make it less ambiguous, so the comments aren't
needed, or otherwise improve it); or creating more documentation
(perhaps linking to other Wiki pages that go on at length on a topic).
> 2) What if people post obscenities or harmful material?
> Showing comments by default would be embarrassing; if you have to
> explicitly choose to view them, this is less worrying.
> Python.org has a really good Google PageRank, I expect, making it
> a good target for link spam, so this is something to worry about.
I think it will be better when the comments are included inline,
because many more people will view the comments. The same is true for
general accuracy. Spam and such is best handled on a Wiki when there's
lots of people to fix it. But maybe php.net or other places would have
more experience on this (php.net does put comments at the end of each
page). Maybe user logins are a good way to raising the bar to
discourage useless (or worse) comments.
I also like the idea of using Wiki pages instead of the traditional
appended comments -- I think it would be more constructive.
> The Wiki has mostly escaped such vandalism; presumably it's unobtrusive
> enough that spammers haven't noticed it.
>
>> the page content and the barest of controls). I think it would be
>> best
>> done as a separate wiki, maybe with a namespace that fits the library
>> documentation structure better. Or maybe both are possible. It would
>
> Perhaps. Wiki names can contain '/', so we can have annotations for
> every
> single page on the site by just using the full path name. The
> question is
> whether we need that level of support; perhaps the docs are the only
> place
> where comments are valuable. I do think that comments on the reference
> manual or the Distutils manuals would be useful. (Possibly PEPs, too?)
There's definitely places besides the library reference that could use
these comments, but I think they could all be listed out explicitly. A
little rewrite magic could keep it in a flat hierarchy.
> I did a bit of experimenting with the separate page, adding JavaScript
> to
> ht2html's output and adding an ugly 'view comment' link. If we're
> interested in pursuing this, I'm willing to do the following:
>
> 1) Make a set of experimental pages with comment links, so we can see
> what they look like and how they work in practice.
> 2) If 1) looks worthwhile, then I'll make a new Wiki for user notes
> that has
> minimal styling.
>
> What I'd really need is presentation suggestions: *how* to show the
> comment
> link?
I think it should *not* be in the sidebar -- the sidebar is
navigational and it's implied that it's specific to the site or
section, not that particular page. But the library reference doesn't
really have a sidebar, so nevermind that...
In the top bar then, by the TOC/modules/index links... or maybe the
arrows, since those are context-sensitive, where the other links are
global. Then maybe a larger link at the bottom of the page (kind of a
further reading link).
If the comments aren't included inline, I feel like it would be
important to indicate if there *were* any comments. It's annoying and
discouraging to be in a site that hints at things that aren't there --
and there will be a lot of "not there" when this feature is first
added. But I think implementing that would be fairly hard to do. But
important. But hard. Sigh.
Bengt Richter
>[CC'ing to pydotorg-redesign, and setting followups there, too.]
(somehow the email address got into the newsgroup slot for me, so I had to fix it)
Have a look at
http://www.xml.com/axml/testaxml.htm
for a way of associating commentary with (it says, at least) unchanged original matter
(in this case the XML spec). It's pretty easy on the eyes. I don't know the implementation,
but I think that separation of pristine original from comment material would be good. The
above site probably has the advantage of heavy xml tagging in the original that the commentary
database can used for retrieving associated commentary, I would guess.
Since full comment generation for dynamic javascript-controlled interaction is somewhat
computer-costly, caching results of generating responses to comments would make sense,
I think, and I don't think generating it should be the default.
If the python.org server is able to insert an optional footer chunk just before the </html>
when so configured to do it for a directory or a file (I don't know if Apache can do that,
since I just made it up, but ISTM it would be a useful option ;-), then that footer could
contain a link for viewing commentary.
The link would go to a comment-server URL, e.g., commentary.python.org/coments.cgi,
The cgi program will see HTTP_REFERER from the page the user clicked the comments link on,
and it can either get a copy via HTTP, or look it up on the local hard disk if it's local.
The URL can also be used as a key into a database of commentary, where also commenter-accounts
could be maintained to keep out spammers.
With the original page plus a database of commentary, the problem becomes building a new
image of the original with unobtrusive commentary navigation. With javascript you could
do floating hint text from commentary title lines associated with paragraphs or other
elements you were mousing over. Clicking might put the commentary in a separate popup window.
Right clicking on a previous comment might mean pop a form to add your 2 cents. Right
clicking on the main page where no comment hint is being displayed would pop up the
same but with an option to give it a title, since it's new commentary.
All of this is pretty much paragraph oriented. Indexing locations, which have to be w.r.t.
unmarked text in the original can do some kind of soft hash of <p> sections in the original
as indices instead of using line numbers, so the data base can have the hashes as keys, and
not get thrown too much by updates in the original. Actual anchor targets and tag ids
can be used too I suppose (I'm just thinking out loud ;-) Anyway, you get the idea. If it
makes you rich, I want a piece ;-)
my 2 cents ;-)
Regards,
Bengt Richter
Ian Bicking
> Have a look at
>
> http://www.xml.com/axml/testaxml.htm
>
> for a way of associating commentary with (it says, at least) unchanged
> original matter
> (in this case the XML spec). It's pretty easy on the eyes. I don't
> know the implementation,
> but I think that separation of pristine original from comment material
> would be good. The
> above site probably has the advantage of heavy xml tagging in the
> original that the commentary
> database can used for retrieving associated commentary, I would guess.
That does display quite nicely with the frames.
I wrote a system for doing comments like this some time ago, which was
usable for people doing a dedicated task (but probably would be
annoying for a casual reader). Ka-Ping Yee also wrote something quite
a while ago (crit.org, which seems to be gone now). I think he wrote
it in Perl, so no wonder he didn't keep it maintained and up ;)
I think there's generally two issues with comment systems -- entering
comments and preserving comments when the underlying document changes.
The two go together, because the robustness of the attachment of the
comments is related to how you define the place the comment goes.
Crit, if I remember, attached the comment to a phrase. You would copy
a piece of text into the form, and comment on that text. Then someone
could view the annotated version of that document, and wherever that
text appeared your comment would appear (which is hopefully only where
you meant your comment to appear). With feedback this could be made
more reliable, of course. I don't really like the input mechanism,
though.
So comments could get lost due to even trivial changes in the text, but
in reality many comments would be able to persist in their context even
when the document was restructured significantly.
Another technique -- used by Backtalk (in Zope) is to explicitly define
comment points. Several systems I've seen have used this. Typically
you have markup in the text (maybe a specially formatted comment), and
at such a point there'd be a button to add a comment. I haven't seen a
Backtalk page I've liked yet, but I think that has a lot to do with the
finer details of the system -- the graphical design badly needs
refinement.
The system I made inserted a comment point automatically for each
sentence. I was getting editorial feedback, so the exact context was
more important than aesthetics -- but by using a small but distinct
marker (on the size of a +) it didn't get in the way too much. I
didn't preserve comments over versions, so reliability didn't matter --
I suppose you could attach the comment to the preceding sentence
textually. I wouldn't want to read that casually, however.
Maybe better (to avoid distracting the casual reader) would be to have
paragraph-level comment points, and allow the commenter to be more
exact in a follow-up form if they choose. But that's very bad for
reliability, because paragraphs are likely to change in small ways or
be moved around in different versions of the documentation.
Maybe this could be fixed up manually, or orphaned comments could be
put at the bottom of the article (presumably to be fixed or deleted at
some later date). You could also keep track of what version of the
document the original comment was attached to, to more easily mark and
correct comments that may be incorrectly placed for a newer page (but
until corrected, you could guess based on fuzzy text matches or by
counting paragraphs).
I do definitely like the way comments are presented in that document --
that's definitely better than inline or popup comments.
Seems like a fun project, and something that could potentially be
implemented on top of the current website without directly changing the
current site (except adding links to the system when it was completed).
The reference documentation, being automatically generated, would also
be quite parsable... hmm... doesn't seem like a very hard project at
all. Hmm...