Re: [Web-SIG] Re: Just lost another one to Rails
On 4/28/05, Greg Wilson [EMAIL PROTECTED] wrote: My solution is for Guido (or someone with equivalent authority) to appoint someone Benevolent Dictator for the Web for One Year, with a mandate to put together something that has all the features that are getting Rails so much attention. Whatever s/he comes up with in that year will then be shipped as part of the 2.X release of Python in 2006. I don't think this is a good idea for several reasons. Let's imagine we could go back in time four years and tell the Ruby community the same thing: Appoint someone to research a popular new way of building web applications and add that to the next release of Ruby. What would the result have been for Ruby? Would it now look like PHP? I don't know, but I'm skeptical of a solution that copies an existing popular tool. I don't think a large web programming toolkit belongs in the Python distribution. If anything, go the other way around and package a particular version of Python with this web toolkit. I'm also skeptical of a plan that sets out to build the one right way that everyone will use. I don't know anything about the history of Rails, but I'm guessing that the project didn't start because Matz said Build the official web toolkit for Ruby users and it didn't become successful because Ruby programmers adopted it. That is, I imagine it became popular because people liked it and not because people agreed in advance that the would like it. Jeremy PS None of the top 10 Google results for web programming mentioned Python (PHP is second). Four of the top 10 results for web programming frameworks mention Python, including Ian's blog post about why web programming matters. Maybe we'd do better if we didn't have the frameworks 0.2 wink. ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Re: Just lost another one to Rails
Uh, just to clarify this was me, not mike, I forgot to kill that attribution line! * Todd Grimason [2005-04-29 12:02]: * mike bayer [2005-04-29 11:57]: Just to emerge from lurking for a moment, and without years of working in the python community like you guys, it seems pretty obvious to me that such a solution (a dictated web app approach) would never happen. From what I've read of Guido's this seems completely at odds with his views/approach, not to mention the wide revolt it would cause. (back to lurking) -- __ toddgrimason*todd-AT-slack.net ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Re: Just lost another one to Rails
At the last Bay Piggies meeting, as well as at PyCon, Guido felt strongly that no Python Web application framework belonged in the Python standard library for these reasons: o The release schedule for such a library doesn't match the release schedule of Python. Imagine having to wait a year before an update to the library came out? That'd be unacceptible. o Much of this is a matter of taste. o There's no clear cut winner. Zope and Twisted aren't a part of Python either, despite the fact that they're wildly successful. Perhaps it just doesn't make sense. Best Regards, -jj On 4/29/05, Ian Bicking [EMAIL PROTECTED] wrote: Martijn Faassen wrote: There are a ton of non-core XML frameworks around for Python, enjoying considerate popularity. The python 'xml' package is not the one true way to do XML with Python, and certainly doesn't enjoy anything near the popularity and buzz of Ruby on Rails, say. I don't see why the situation for any higher-level web framework should be different in this respect. I think the standard library is difficult, because it mixes all sorts of things together. I involves methodology -- very conservative, backward compatible, slow to improve -- which suggests that a package should be at a certain point in its life. It also suggests applicability, that the package should be reasonably generic and not unduly complex. And it encourages people to use it, either directly or indirectly, instead of alternatives. All of these are important, but they are fairly separate. mxDateTime would have been a very capable implementation of date-time objects, and was a de facto standard, but because of methodology conflicts that didn't happen (I assume because mxDateTime had to be released on a schedule determined by commercial concerns). Wx is similar but even worse; there's no practical way I can imagine it going into the standard library, and it's not just inertia, but rather Tk actually *remains* ideal simply because it is largely dead. Generally the standard library is become much less practical way to move Python forward. Backporting has to be extensive for the library to be viable to use. Up-front design becomes burdensome -- I'm sure there was a lot of useful things that came out of the decimal discussion, but the whole process seemed odd and drawn-out from the outside. Copied designs can shortcut this (e.g., logging), but lead to other design problems. And even as this happens, distributions are often pulling the standard library apart into pieces. Batteries Included has certainly helped me as a developer, but it's not what I have my eyes on for the future. It would be nice if process and politics could be separated. There's a lot of modules in the standard library that no one should use, even if they aren't marked deprecated -- there might be no reason for those modules to go away ever, but they just shouldn't get new users. Similarly there's modules not in the standard library that should be de facto standards, but for good reason can't be part of the standard library development process. But there's no way to suggest that to people except for information question-and-answer sessions in IRC or mailing lists, or the the vague and unpredictable rankings of Google. Politics might be a bad name for this; it doesn't have to be contentious -- for instance, sgmllib has no hero who will be offended that people are steered away from it. But I can't think of a better name. Anyway, I think it might be possible to resolve that issue more easily than the technical issues involved in extending the standard library. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/jjinux%40gmail.com -- I have decided to switch to Gmail, but messages to my Yahoo account will still get through. ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Re: Just lost another one to Rails
Shannon -jj Behrens wrote: When I came to IronPort, I had to act as such a benevolent dictator, or rather, a benevolent concensus builder...Note, I'm not trying to force Aquarium on *anybody*. I wrote it because I needed it. I open sourced it because I like sharing. To add to JJ's background on Aquarium, note that IronPort's backing not only includes a commitment to using Aquarium in at least 7 different divisions of the company but also paying him to work on Aquarium part time. In conversations with JJ, I learnt that this commitment did not come lightly, but instead as a result of an internal comparison of the leading Python web frameworks. The comparison was biased a little against Aquarium by having the initial thought that it would/could not be the best solution and given the calibre of the people at IronPort and the quality of the competition the result is no mean feat. Recently, I've implemented fundamentally the same web application in Quixote, Subway and Aquarium and found that I much prefer to work with Aquarium. One major reason for this is the 'tools, not policy' approach that Aquarium takes. Another plus is that it leverages the full power of Cheetah, handling the issue of compilation of templates totally seamlessly. This eliminates any manual recompilation as well as the need to continually stop and restart the server, which, while not a huge problem, is surprisingly beneficial to the 'flow' of hacking away at a solution. The mailing list support from all projects has been fantastic, but I must highlight the dedication of JJ, making himself available on a number of occasions well into the early hours of the morning answering questions and debugging issues that were uncovered when running Aquarium in a Windows environment. I strongly recommend that people take a serious look at the Aquarium project and while it may not have the same prescriptive nature and the depth of backup material as RoR (yet) it is a good place to start a search for the right tool for the job and for a project to become involved in. Robert PS I'm newly subscribed to the list so I apologise if, in my enthusiasm, I'm a little too 'project specific'. ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Re: Just lost another one to Rails
A.M. Kuchling wrote: On Mon, Apr 18, 2005 at 05:01:41PM +1000, Anthony Baxter wrote: If you spell it wrong, you either get a broken web application with no useful traceback, or else a monstously hideous traceback that's almost entirely useless. This is also part of why I've never been able to get anywhere with Twisted, and why I'm suspicious of systems that depend critically on interfaces, adaptors, and other such extensions to the object model. When they go wrong, diagnosing the problem is messy, and simple typos can get turned into huge debugging expeditions. I think this fairly accurately describes the risk of strongly decoupled systems like Zope 3 and Twisted. In the beginning of OO, people had this complaint about inheritance hierarchies too. And they were partially right, but not entirely. I believe adaptation is a useful tool, but like inheritance, one shouldn't overdo it and use with it with care. I can certainly say Zope 3 in some areas goes overboard with this. How would you deal with the flexibility requirements that these systems have, though? Regards, Martijn ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Re: Just lost another one to Rails
Greg Wilson wrote: Paul Boddie wrote: ...I firmly believe in unbundling templating languages from frameworks. But doesn't that just make more work for the poor sods who are trying to build things? After all, they have to rebundle them, don't they? I think there's a difference between maintaining and developing something separately and not physically distributing something together. I agree that the Zope project, for instance, should be maintaining and distributing the ZODB separately from Zope, as they have been doing for some time now. But I certainly don't mind Zope shipping with right version of the ZODB included and having to only install Zope. If you really want to solve this, you'd end up with package management systems with dependency resolution. Most linux distributions have this. Let's not worry too much about physical distribution in this debate, more about how web frameworks should be organized and how they should relate to each other. Regards, Martijn ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Re: Just lost another one to Rails
Martijn Faassen wrote: I've sighed a few times the last months when I ran into more and more Python-based schema and form frameworks. I developed Formulator for Zope 2 pretty early on, and was involved in 2002 in setting up Zope 3's schema framework, so I've contributed to the problem. In the Zope world there's also Archetypes, and I heard Archetypes is now working on a new generation which redesigns everything.. And I ran into Schevo and I saw formencode, which both have a history too, and then finally what made me sigh was running into a weblog post by Philip Eby on Spike. It all looks all very cool, but how many more do we need here? I believe that what we, framework developers, need is a bit more humility (We're open, you just all plug into our great solution! is not humble), and more active outreach to include pieces of other frameworks. While we also need to do a bit of work of opening up the neat bits of our frameworks to reuse by others, but that rather easily turns into the non-humble Use mine!, so I think what we really need to do more of is the Let's look for something to reuse! variety of outreach than the look, I made mine real great! outreach (we'll do the latter automatically anyway :). I think Ian Bicking has been saying similar things. Well, since I show up in both paragraphs (having written FormEncode), and both sides of the issue, I guess I should reflect on why. The duplication of work did occur to me (and I was looking to give up at one time: http://blog.ianbicking.org/where-next-for-formencode.html). And I realized that I was spread too thin to give the necessary attention to all my still independently-developed projects. The resolution of such a situation can go a couple ways -- I abandon the project entirely, I somehow get other developers involved, or I try to fold the ideas into someone else's project. All three are very difficult, some in practical ways (how to get other people interested, how to find a compatible project) some emotionally (abandoning code, or the humility required to abandon code *and* work on someone else's project). I've gone through all three processes at times too -- FormEncode went dormant for a long time, then I kind of reminded myself of what it was useful for, then I looked around for other similar projects -- but I had no idea what to do once I found them. Say hey, stop using what you are using, I got some better ideas? I feel like an interloper. What I'm doing might apply to Archetypes or Zope schemas, but I'm not involved or invested *at all* with those projects, so my connection is tenuous. I feel like we have to meet in the middle somewhere, some neutral ground where people can be equally invested and involved... but I'm not sure how to do that, because what seems like a Big and Difficult Problem to me (form generation) may seem (at least at the moment) to be incidental to another project; useful, but not worth the coordination effort. Not to mention, what I think is important and distinguishing isn't what other people feel is important. (The other direction I considered was documentation: http://blog.ianbicking.org/a-theory-on-form-toolkits.html -- but is documenting a design aimed at decoupling that different than distributing the code that informed that design?) I need to figure this out, because WSGIKit is in the same position -- I'm trying to factor out something that I think deserves to be shared among projects, but how to I get other developers to adopt the project or participate in the development? Make It And They Will Come isn't that reliable. I think people are comfortable letting projects Compete In The Marketplace, i.e., put a bunch of stuff out there and see what comes out on top. But in reality nothing comes out on top, and reimplementation is common -- especially with something that tends to be mixed with an object model, like form generation. Everyone pretty much agrees that simple is better, but simple can be hard to define. Some projects -- Zope 3 in particular -- build up a bunch of new metaphors for programming, like adaptation, interfaces, utilities, and declarative glue. To a core Zope 3 developer these aren't complexity, they are fundamental ways of thinking about development. They are the prerequesites for understanding everything else. These prerequesites always exists -- I consider some level of OO understanding a foundation that I expect, and so I don't consider (many) OO techniques to be a sign of increased complexity. But for someone with only procedural experience this won't be the case. This is okay, because The World has agreed that OO is a fundamental concept. But there isn't a consensus on these new object models that people are working on, not even within the domain of the web. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org ___ Web-SIG mailing list
Re: [Web-SIG] Re: Just lost another one to Rails
On Wednesday 13 April 2005 23:05, Martijn Faassen wrote: Buggy? I don't think ZCML is buggy. Where's that coming from? I wouldn't say ZCML is *buggy* as such, but it _is_ an utter pain in the arse to debug and get right. If you spell it wrong, you either get a broken web application with no useful traceback, or else a monstously hideous traceback that's almost entirely useless. The only way I found to do ZCML sanely was to copy an existing product's ZCML and modify it - this is nuts. In the mean time, in the world of HTML templating, we see a lot more agreement that sometimes a domain specific language is useful. People generally don't want to be producing all their HTML from Python functions. I've seen far less complaints about ZPT being cumbersome and buggy. That's because when you make a mistake in ZPT, it's nearly always extremely obvious what the problem is. This is not the case with ZCML - well, unless this has changed dramatically since about the middle of last year. That's not say ZCML as it stands doesn't have some didactic/learning curve issues. But to reject this out of hand just like that is a bit too easy, I think. Attempting to debug some random ZCML error was what drove me screaming away from Zope3 last year (having done a fair amount of work on and with it). I was spending far more time on debugging the simple task of configuration and hooking things together than I was on _actually_ _writing_ _code_. Screw that for a game of soldiers. I _like_ a lot of the stuff in Zope3. But ZCML was just too awful for me to continue working with it. It was too much like just changing stuff randomly and hitting it with a stick for my liking - there were far too many different XML tags with non-obvious names and what felt like a pile of dead chickens required to get it right. -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Re: Just lost another one to Rails
Amen. I don't mean to slam the work of any web framework developers, but you can't overestimate how much it helps just-beginning web developers to see a unified framework, or at least a good website that directs them to one particular way to do things. this is what i dont understand; whats so hard about doing a little research ? why do people need to be told only one way of doing things ? python is not the the mcdonalds of computer languages...its sophisticated and thoughtful. If youre dealing with a thoughtful and sophisticated community, you need to approach it in a more thoughtful and sophisticated way.its reasonable to expect the community to work up some standards for interoperabilitybut less so to present a monolithic one-size-fits-all methodology to the masses so that nobody need be bothered with some thinking and decision making. that just dulls the community down to its most unsophisticated level and insures only the most mediocre outcomes. Let me put it this way: I've spent weeks and weeks researching many many python frameworks, but never found one that seemed proven in terms of adoption by a large number of high-traffic sites. And since you can never really learn how good a framework is until you try it out, this information gathering had a tremendous cost! That cost slows down the entire community and keeps people out -- at some level, it's good just to have popularity among simple web developers, not just the people willing to hack around and create new frameworks. -Brendan ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/brendan.t.oconnor%40gmail.com ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Re: Just lost another one to Rails
- I agree completely, that's why I'm adding yet another framework to the mix! (I'm waiting for someone to stand up at PyCon and say, Web App People's Front? We're the People's Front of Web Apps!) I think the term framework is becoming a little vague as well. there is the notion of framework as, the entire front-to-back approach to serve HTTP requests via Python, then there is the architectural approach that is used on top of an existing web API, and then there are templating languages which have varying degrees of pluggability into existing systems. I know that I chimed in with Myghty as well heres what I did!. But really, its 90% a templating language you can use with whatever framwork you want, and 10% an architectural approach which you can use more or less of. In all cases it requires a web API of some kind and doesnt try to replace that. And as far as templating languages for Python, I had a great need for it. The only other powerful options for python-embedded-html seemed to be Cheetah and Spyce, both of which did not fit the bill for me. I'm all for WSGI being as much of a standard as we should be embracing. But the Python community is a lot more varied than the Ruby one; people are thinking way out in their own boxes and have their preferred way of doing things (i.e. like people who only want to do python-generated HTML)...instead of reacting to and imitating the Ruby community, we should be presenting the world with our own community, where here are our favorite ways of doing web applications, but there are several varieties of how we do it. In the Python world, you have to use your brain a little bit. ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Re: Just lost another one to Rails
mike bayer [EMAIL PROTECTED] wrote: I think the term framework is becoming a little vague as well. there is the notion of framework as, the entire front-to-back approach to serve HTTP requests via Python, then there is the architectural approach that is used on top of an existing web API, and then there are templating languages which have varying degrees of pluggability into existing systems. Yes, and I firmly believe in unbundling templating languages from frameworks. Perhaps it says more about me than the Python community, or more about the Python community than some other community, but it's a real turn off to look at frameworks where special hooks for some preferred template language are foisted on the developer. People have complained about stuff like how hard it is to use XML with Zope (or perhaps it was that there isn't an easy way in), and I'm sure that there are how to texts about working with XML in JSP, but templating should be something that developers can make their own decisions about without sacrificing 90% of the benefits of any given framework. I fondly remember the days when one had to call DTML manually in Bobo applications but still had the remotest chance of using it in other applications, and whilst I see the benefit in supporting instantaneous hello world-style page publishing on top of a framework, one shouldn't have to get the power! tools out to make other technology choices. I know that I chimed in with Myghty as well heres what I did!. But really, its 90% a templating language you can use with whatever framwork you want, and 10% an architectural approach which you can use more or less of. In all cases it requires a web API of some kind and doesnt try to replace that. I'd encourage every templating language developer to make their work as independent of any given framework as possible. As I probably said in some blog or other, plain libraries have a great record when it comes to code re-use, and to be able to cleanly integrate a templating language in an application by just importing some modules and feeding objects or functions with data, on whichever framework, would be highly beneficial for everyone concerned. And as far as templating languages for Python, I had a great need for it. The only other powerful options for python-embedded-html seemed to be Cheetah and Spyce, both of which did not fit the bill for me. Fair enough. No-one should be criticised for writing something which works for them. What is worrying, however, is the trend towards the proliferation of highly excluding top-to-bottom solutions where you buy into the whole thing and cannot easily back out of any particular technology choice without substantial re-plumbing. That there's skepticism in the Python community about Rails, which in part seems to advocate the top-to-bottom buy-in, doesn't surprise me a great deal - there wouldn't be as many different Python frameworks if people loved that sort of thing. I'm all for WSGI being as much of a standard as we should be embracing. But the Python community is a lot more varied than the Ruby one; people are thinking way out in their own boxes and have their preferred way of doing things (i.e. like people who only want to do python-generated HTML)...instead of reacting to and imitating the Ruby community, we should be presenting the world with our own community, where here are our favorite ways of doing web applications, but there are several varieties of how we do it. In the Python world, you have to use your brain a little bit. Agreed. The emergence of WSGI seemed to signal some kind of realisation that the layers of the Web applications stack should be more independent and interoperable, but I think it would be more productive to pursue such an agenda at a higher level - templating and database access are areas where good solutions exist that work with as much of everything else as possible. Choice in itself isn't a bad thing as long as the decision-making process is supported by good documentation and lets people change their mind about mere implementation details. What I'm advocating is this: * That the community provides narrow/thin but *completely separate* components/solutions which offer very well-defined benefits - eg. Web APIs, templating systems, database access layers. These things shouldn't be mixed up in the fundamental system on the pretense of convenience. * That documentation is produced to describe how one plugs these things into each other and how one might go about integrating other functionality into applications. * That genuine solutions for certain styles of application may be made, but not foisted on people from the lowest levels of any given system. Some applications benefit from having .myapp on the end of every Web resource, and by being able to write hello world in a text file and have it pumped out dynamically from the server; not all
Re: [Web-SIG] Re: Just lost another one to Rails
On Apr 15, 2005, at 2:49 PM, Ian Bicking wrote: Greg Wilson wrote: Paul Boddie wrote: ...I firmly believe in unbundling templating languages from frameworks. But doesn't that just make more work for the poor sods who are trying to build things? After all, they have to rebundle them, don't they? I don't think it's too bad. I'm happy with how ZPTKit works, even though ZPT isn't written (at all) with Webware in mind, or vice versa. OTOH, I don't think ZPT with Webware provides a very good experience without the non-trivial amount of glue code in ZPTKit, and that glue is kind of a NxM problem (# of template languages time # of frameworks). But it's not at the top of my list of problems. Other templating languages, like Webware's PSP (which is JSP-like) are harder to generalize like this, because they are more closely tied to the underlying code (servlets in PSP's case). But, maybe ironically, I find an entirely separate templating language easier to work with. We're experiencing this problem with Kid, which is framework neutral. I'm finding that the amount of glue code needed for most frameworks is more than I expected. The other issue I'm having with is that it's really hard to provide anything but really simple template examples and other documentation without assuming a certain framework. I can show the basic layout control and substitution features but it's hard to show real world examples of, say, how a basic site should be laid out. Framework specific idioms bleed into the template. I guess this isn't always bad but it makes it hard to talk about templating without declaring a certain framework beforehand. I'd personally love to see a common set of request/response/session objects (a la Paul's webstack) be adopted. I'm beginning to think that separating templates from frameworks can only work well if the glue in between is somewhat standardized. I've never quite understood why everyone wants to maintain these objects themselves anyway. I've looked at Quixote's, CherryPy's, and Webware's implementations of the basic request/response/session objects and I just don't see a whole lot of variance. I'm not looking for templates to be completely portable or anything, I just wish we could talk about and document them without a chapter about what environment it's running under. Ryan ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Re: Just lost another one to Rails
Hey, Not much debate from me here on this front, just a lot of agreement. Ian Bicking wrote: Martijn Faassen wrote: [...] One issue seems to be that Python programmers are automatically allergic to domain specific glue languages like ZCML, especially when they look like XML. I think this attitude is not really reasonable, but it's extremely widespread. Jim Fulton looked into a Zope 3 based bobo a while back; something I haven't studied, but might be a way to avoid ZCML for some projects. In my gut -- and I don't think I'm alone -- ZCML doesn't feel right to me. It's quite literally a gut feeling, or maybe you could call it a code smell, it just doesn't smell right to me. Experience might or might not change that feeling, but it's there nonetheless. Do you think domain specific component configuration/glue languages are not right in general, or is it something specific about ZCML in particular? [...] This: http://svn.zope.org/Zope3/trunk/src/zope/app/demo/hellopackage/ is a documented hello world package in Zope 3 by the way. It creates a persistent hello world object that can be added through the Zope 3 UI, with a page template and the like. It's too verbose as a minimal case; dumping the UI requirement and some stylistic issues could cut it down a bit more. If you were to add 'hello world' as a template to an existing object, it'd be a lot simpler still (cutting away all Python code and just leaving a ZCML snippet to hook up the template, and the template itself). Looking just very briefly, I think the issue is one of approachability and incremental learning. Agreed completely, very good point. I harped about this on the Zope 3 list for a while last year. There's some big concepts there, and it's unclear where to start. Interfaces, adaptation, ZCML, ZPT... they are all somewhat foreign, at least to the typical Python programmer. I think Jeffrey Shell has been trying to create a more linear tutorial with a to-do list, which is probably a good idea. A good tutorial -- challenging to make, to be sure -- is one where each step seems clear, relevent to previous steps, and creates something usable. And where you don't have to say ooh, this stuff is something you can ignore for now, *and* where you don't have to explain a lot of irrelevant material as well. My favorite example of this is Hello world in Python versus Hello world in Java. In Java, to new programmers, you'll either have to say well, ignore this class thingy for now. Just look at the method. Ignore this too. And that, which gives a bad impression of programming. Or alternatively, you'll have to explain it all well, this is a class, and that's to do with object oriented programming, which is.. which will confuse and overwhelm new programmers entirely. Zope 3 suffers from the same problem. I think in part this can be solved by writing a good tutorial as you say, and in part we need to ruthlessly eliminate stuff that we otherwise cannot avoid in the tutorial. The Zope 3 tutorial as written by Jim Fulton is very complete, but is not a good tutorial for beginners in my mind. It introduces functional doctesting using tcpwatch before you write your first adapter, or something... I attempted to write something like a simple tutorial in the context of Five (Zope 3 in Zope 2). Here they are, in all their magicpoint glory: http://codespeak.net/svn/z3/Five/trunk/doc/five_interface_tutorial.mgp http://codespeak.net/svn/z3/Five/trunk/doc/five_views_tutorial.mgp Most of this can be safely translated to Zope 3, which in fact I did in part for a presentation once. It is still too overwhelming perhaps for the amount of stuff you end up doing, which isn't that much. I think this is really where my gut feeling about ZCML comes from -- it's intimately tied to other pieces of the code, and often is a prerequesite to making that code functional (at least functional with respect to its real intention, which is usable in a Zope context), and separate files that have to be subtley in sync always makes me uncomfortable. Of course, that kind of dependency happens all the time, and in an interconnected system you can't expect otherwise. But I won't try to make it an entirely rational argument, that's not actually where my uncomfortable feeling is coming from. I recognize the feeling. Python was liberating after having to mess about with header files in C and C++ for me, and they are slightly similar to ZCML. ZCML and interface files bring the header file feeling back to Python, which is not good. Even though I also agree that this kind of dependency really happens all the time, and you can't really expect otherwise in larger systems. I also think some concepts are being overused in Zope 3. Adaptation, specifically -- multi-argument Adapters break my understanding of what Adaptation is supposed to be, and I think they are being used for all sorts of clever, useful things, where clever is meant as a
Re: [Web-SIG] Re: Just lost another one to Rails
Buggy? I don't think ZCML is buggy. Where's that coming from? Sorry, didn't mean to knock ZCML specifically. I meant to say that use of XML is inherently buggy when people have to edit it with a text editor, because of the bad syntax. I have the same gripe with the XUL used by Firefox. Nothing specific to the design of ZCML (which I haven't even seen). And lose interoperability, accessibility by a host of programmers that *don't* know your codebase, and code yourself onto an island. Sorry, Martijn, none of these arguments have much weight with me. I'm interested in improving the ability to do things *with Python*. And that doesn't (for me) mean switching to something else, no matter how many other people understand that something else. Bill ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Re: Just lost another one to Rails
my own project, Myghty, is modeled after Perl's HTML::Mason, which in turn is a lot like PHP with regards to just plug it in and start writing pages. it does foster a more compentized design than PHP and also integrates nicely into whatever MVC framework the developer chooses. Myghty also includes a rudimentary MVC framework paradigm built into it, but its completely optional; you can use whatever architecture you want and just use the python server pages aspect of the engine. the whole idea with Myghty is that theres a lot of options for how it can be used, it wont let you down when the site gets big, and also its as out of the box as it gets; just untar the dist, and it includes a demo server that runs right out of the distribution directory so you can see it run, browse the docs and source code, and start playing with your own pages without even installing it. Basing it off of HTML::Mason was because i think the Mason development model is extremely productive, having used it for several years, after lots of experience with both JSP/servlet and ASP models which I feel are less productive. a lot of other people agree too; its the most popular web framework for Perl, OReilly book and everything. unfortunately I did Myghty a disservice by not showing up to hawk it at Pycon. as its deriviate of something from the perl world, i would never expect it to become the de-facto python tool; but then also, i think the python web framework world should remain open to various architectures coexisting. On Apr 9, 2005, at 11:20 AM, Peter Hunt wrote: Ruby on Rails, ColdFusion, ASP.NET, and to a lesser degree PHP and ASP share two important traits that no Python web framework currently embraces. First, when one writes an application for these frameworks, one spends the vast majority of time writing code for their application, writing the logic that their application specifically requires. Contrast this with J2EE or Zope. In writing a Zope 3 application, for example, one must design objects that fit the Zope interface requirements, write a couple of XML configuration files to document the object, and figure out the entire API all at once. Contrast this to PHP, where one spends time simply writing what their application needs to do, and does not need to write a single ambiguous XML configuration file. This extends to deployment. In a J2EE application, you need to deploy a WAR, while with PHP, you just need to drop a few .php files on the server and it works. Second, these frameworks have batteries included. Rails is a full-stack framework, which, according to its API documentation, includes everything needed to create database-backed web-applications according to the Model-View-Control pattern of separation. It handles everything from form validation to database integration to sending email. No Python framework currently embodies such functionality with such good integration. I really want to be able to say that we should all come together to improve Zope, the king of Python web frameworks . . . but I can't say that. Zope 2 was a mess, and Zope 3 is so overengineered that it's painful to write code. The ideal framework should allow the programmer to be organized, while still allowing a monkey to write Hello, World. My two cents . . . what's yours? ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/ mike_mp%40zzzcomputing.com ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
