Re: Pros/Cons of Turbogears/Rails?
fuzzylollipop wrote: Paul Boddie wrote: In various open source circles, the mere usage of 1.0 may indicate some kind of stability, but not necessarily maturity, or at least the desire of the developers to persuade users that the code is ready for them to use. nope in GENERAL usage, 1.x means that the developer is designating a version that is feature complete and stable. Please note the distinction between stable and mature - these are not quite the same thing. Django, Rails and Turbogears may be at or approaching 1.0, meaning that their developers regard them as being stable (ie. no showstopping bugs), but that's not the same as being mature. Moreover, the developers of all those frameworks will most likely not stop at 1.0 but start working towards 2.0, possibly creating quite a different product. I never ever mentioned comparing version numbers between differing packages. No, but there are important psychological factors at work when choosing and interpreting version numbers: do you go for ABC 0.9, XYZ 1.2 or PQR 7.1? What about the newly announced XYZ 2.0 - is that a safer choice than its 1.x predecessor? MY POINT was the developers of Rails JUST RECENTLY decided that it was ready for general consumption compared to all the PREVIOUS Rails releases. That judgement call may be true, but they haven't exactly been reticent about getting people to download and use it before now. And NONE of these frameworks has been used to power anything along the scale of what I work with on a daily basis. I can believe that. Do you have any success stories to share? And speaking from experience, autogenerated Active Object Pattern frameworks dont' scale. And Rails is no exception. It didn't work 10 years ago when all the ORM vendors were selling ridiculously price point and click database application builders, what makes people think it will now? My feeling was that any object-relational mapper that (supposedly in this case) dictates how you're supposed to design your database automatically rules itself out over a vast territory of existing and new applications. Having seen the EJB army march themselves into a swamp, my feeling is that most such mappers seem to be an increasingly complicated excuse not to learn SQL. Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Pros/Cons of Turbogears/Rails?
[EMAIL PROTECTED] wrote: I was initially leaning towards Rails due to maturity, but the most recent version of TurboGears seem to have fixed a lot of the ad hoc feeling I got from previous versions. But I'm still very much up in the air. Thanks, Ken I've found that familiarity with Windows in the Ruby/Rails community is less than in the Python/TG community. Ruby/Rails seems to have been mainly *nix until fairly recently. Sometimes the Windows version of a module or tutorial will lag significantly. (ldap comes to mind.) Sometimes Windows-oriented questions get pretty short shrift along the lines of: Perish the thought! or Why would you? instead of serious treatment. It's not a deal-breaker and neither community is perfect in this respect. I now work mostly with Ruby/Rails, but I did Python/CherryPy for quite a while, and that's my impression. Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: Pros/Cons of Turbogears/Rails?
[EMAIL PROTECTED] wrote: + SqlObject allows working with the DB tables without using SQL itself. Rails has ActiveRecord ORM, which IMO has nicer and simpler syntax than SQLObject. Rails has migrations, TB - not (Migrations is versioning system for evolving database schema) + Likely to be faster because as far as I'm aware, Python is significantly faster. Python is maybe faster, but with YARM (which is not stable yet) Ruby will be about 10x faster. YARM is full virtual machine like Java. + Easy access to other libraries (such as the Python Imaging Library) that Ruby, being a relatively newer language, doesn't have equivalents to. Ruby is not so young you think. It became more popular when Rails has appeared. + Built-in default SQLite makes it easier to set up? What? :) YAML is much easier. (as far as I can tell, Ruby requires MySql by default--don't know how easy this is to change.) Change in config/database.yml driver: mysql to any you want, like db2, postgres, sqlserver, sqlite, firebird, oracle etc. You can change default settings as well. See: rails --help + I find the templating system somewhat cleaner; code in py: xml namespace allows pure .html templates, instead of equivalent of .rhtml files. But rhtml is much more flexible because it can generate *any content*, not only xml. But Rails has THREE template systems: rhtml (main), rxml (for rss and xml generation) and rjs (for javascript and AJAX). And last but not least, TG is based on poor, unstable and buggy CherryPy server. We had huge problems with CherryPy. I think that Django or Pylons are much better frameworks. IMO TG is no competition for Rails at all. The only real competition is Django or Pylons. -- Jaroslaw Zabiello http://blog.zabiello.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Pros/Cons of Turbogears/Rails?
Jaroslaw Zabiello [EMAIL PROTECTED] writes: [EMAIL PROTECTED] wrote: + SqlObject allows working with the DB tables without using SQL itself. Rails has ActiveRecord ORM, which IMO has nicer and simpler syntax than SQLObject. Rails has migrations, TB - not (Migrations is versioning system for evolving database schema) TG supports SQL Alchemy as well. With SQL Alchemy I believe you'll have a better experience than with Rails' ORM. With regards to Migrations, SQL Object does support something like that, but you have to explicitly code it and then you can run sqlobject-admin upgrade (or the equivalente tg-admin sql upgrade, since it is a wrapper...). But rhtml is much more flexible because it can generate *any content*, not only xml. But Rails has THREE template systems: rhtml (main), rxml (for rss and xml generation) and rjs (for javascript and AJAX). Well, TG has a few templating systems... MarkUp, Kid, Cheetah, ZPT, and others. You can choose the one that best fits your needs / brain. You can even have multiple template systems used depending on what was requested for the same controller... Which one is better isn't of my concern. I've already tested then and decided what I want to use. The best thing is try them and see what works. You don't have to choose only one -- but you have to use one per project to make it less messy ;-) -- Jorge Godoy [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Pros/Cons of Turbogears/Rails?
Jaroslaw Zabiello wrote: [EMAIL PROTECTED] wrote: + SqlObject allows working with the DB tables without using SQL itself. Rails has ActiveRecord ORM, which IMO has nicer and simpler syntax than SQLObject. Rails has migrations, TB - not (Migrations is versioning system for evolving database schema) I don't really see TG sticking with SQLObject. In moving to SQLAlchemy it would pick up not only a migration system but also a much more flexible abstraction system due to the use of a Data Mapper pattern instead of the Active Record pattern. There already is an implementation of Active Record on top of that, so that benefit stays as well. + Likely to be faster because as far as I'm aware, Python is significantly faster. Python is maybe faster, but with YARM (which is not stable yet) Ruby will be about 10x faster. YARM is full virtual machine like Java. I tried to check out information on this, but the only docs I found that looked like what I wanted were written in japanese. Do you have any links discussing the status of this project? Does it make any breaking changes to the Ruby implementation that will have to be fixed? Has the RoR project already agreed to port to this when it is stable? + Easy access to other libraries (such as the Python Imaging Library) that Ruby, being a relatively newer language, doesn't have equivalents to. Ruby is not so young you think. It became more popular when Rails has appeared. Although that is true there are not as many libraries available for Ruby as there are for Python. This will probably change as the language gains popularity, but for right now it pays to look into library support before considering anything else about the language. + I find the templating system somewhat cleaner; code in py: xml namespace allows pure .html templates, instead of equivalent of .rhtml files. But rhtml is much more flexible because it can generate *any content*, not only xml. But Rails has THREE template systems: rhtml (main), rxml (for rss and xml generation) and rjs (for javascript and AJAX). Kid can be used to generate xhtml, rss, xml, pretty much anything that is xml-based. I have even seen it used to generate xul applications for firefox. The only thing on your list that it doesn't do is javascript. Personally I would rather learn one templating language that is able to treat all of my xml as xml no matter what use it is put to. And last but not least, TG is based on poor, unstable and buggy CherryPy server. We had huge problems with CherryPy. I think that Django or Pylons are much better frameworks. IMO TG is no competition for Rails at all. The only real competition is Django or Pylons. I have never had much in the way of problems with CherryPy. From what I have heard the project has made a lot of improvements recently, so it may have changed since you last took a look at it. Actually that point right there is where I think TG is a lot more competitive that you believe. When a new version of any of the foundation projects comes out, or a better project to fill that particular need, TG can absorb it in the next version. The TurboGears developers can spend most of their time working on additional code that makes the project more useful instead of bug fixes and minor feature upgrades to the core components. This philosophy is proven to work for most other open source projects, and I have yet to hear a good argument why it would not be successful for a web framework. -Adam -- http://mail.python.org/mailman/listinfo/python-list
Re: Pros/Cons of Turbogears/Rails?
Jaroslaw Zabiello a écrit : Python is maybe faster, but with YARM (which is not stable yet) Ruby will be about 10x faster. YARM is full virtual machine like Java. Google doesn't find YARM and so, YARM does not exist. Care to provide an URL or something? -- http://mail.python.org/mailman/listinfo/python-list
Re: Pros/Cons of Turbogears/Rails?
Paul Boddie wrote: fuzzylollipop wrote: uh, no, Python predates Ruby by a good bit Rails might be older than Turbogears but it still JUST went 1.0 officially. It can't be called mature' by any defintition. Version numbers are a fairly useless general metric of project maturity, taken in isolation. But 1.0 releases do mean something, it means the DEVELOPER of the package things it is just now ready for general consumption. That means something regardless of what the number is. Matter of fact, all major version releaese mean that, it is generally understood thing. x.0 means this is now ready for non-beta general use. -- http://mail.python.org/mailman/listinfo/python-list
Re: Pros/Cons of Turbogears/Rails?
Christophe [EMAIL PROTECTED] wrote: Google doesn't find YARM and so, YARM does not exist. Care to provide an URL or something? it's YARV - http://www.atdot.net/yarv/ -- Lawrence - http://www.oluyede.org/blog Nothing is more dangerous than an idea if it's the only one you have - E. A. Chartier -- http://mail.python.org/mailman/listinfo/python-list
Re: Pros/Cons of Turbogears/Rails?
Ray wrote: fuzzylollipop wrote: uh, no, Python predates Ruby by a good bit Rails might be older than Turbogears but it still JUST went 1.0 officially. It can't be called mature' by any defintition. But at least in most developers' perception ... snip nobody is talking about perception -- http://mail.python.org/mailman/listinfo/python-list
Re: Pros/Cons of Turbogears/Rails?
fuzzylollipop wrote: Paul Boddie wrote: fuzzylollipop wrote: uh, no, Python predates Ruby by a good bit Rails might be older than Turbogears but it still JUST went 1.0 officially. It can't be called mature' by any defintition. Version numbers are a fairly useless general metric of project maturity, taken in isolation. But 1.0 releases do mean something, it means the DEVELOPER of the package things it is just now ready for general consumption. That means something regardless of what the number is. In various open source circles, the mere usage of 1.0 may indicate some kind of stability, but not necessarily maturity, or at least the desire of the developers to persuade users that the code is ready for them to use. Consequently, there are numerous stable packages at 0.x because the developers don't think they're near finished (ie. have produced a mature system), numerous unstable packages at 1.x because the developers want their 15 minutes of fame (GNOME 1.0 was apparently a good example of this), and various packages at 3.x or 4.x that would suggest a legacy of decades when they've probably only been in existence for eighteen months at the most. Matter of fact, all major version releaese mean that, it is generally understood thing. x.0 means this is now ready for non-beta general use. Agreed. Still, let's take some examples from the python.org Wiki's WebFrameworks page to illustrate what I mean: SkunkWeb (3.4.0), Zope (2.9.4 and 3.2.1), Plone (2.5), Karrigell (2.3), CherryPy (2.2.1), Spyce (2.1), QP (1.8), Cymbeline (1.3.1), Django (0.95), Webware (0.9.1), Pylons (0.9.1), TurboGears (0.8.9), PyLucid (v0.7.0RC4), Paste (0.4.1), web.py (.138) Now, just over half of the above have presumably passed some stability threshold, and we could possibly even estimate the age of many of the frameworks based on how high their version numbers are. However, note that whilst Zope 3.2.1 is now presumably considered stable, something like Zope 3.0 couldn't really be considered as mature as Zope 2.8 or 2.9 purely because of the nature of the code: a rewrite of the architecture which, even if considered stable, cannot be considered mature in comparison to its established predecessors with all the accumulated expertise and experience associated with them. Such comparisons of unequal things having the same name have also affected projects like CherryPy, where 1.x and 2.x were apparently quite different, and whilst CherryPy is currently at 2.2.1 and used by other projects, it is described as unstable elsewhere in this thread - contradicting various reports of successful large scale deployments, I might add. Meanwhile, the original framework upstart, Webware, hasn't even reached 1.0, yet it has been around for longer than many of the others, whilst Pylons bears an identical version number. Part of the difficulty in maintaining an overview such as the WebFrameworks page arises from attempting to measure maturity, stability, vitality and quality - something which some repositories like Freshmeat attempt to tackle using various methods of measurement. And as I was editing the version numbers recently, I did consider the issue of whether they provided a reasonable impression of project stability and/or maturity, but I rather feel that more considered evaluations are the only way to get that kind of information. Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Pros/Cons of Turbogears/Rails?
On Thu, 31 Aug 2006 11:42:47 -0300, Jorge Godoy wrote: TG supports SQL Alchemy as well. With SQL Alchemy I believe you'll have a better experience than with Rails' ORM. I would not be so sure. I have tried to work with SQL Alchemy (using Pylons) and I have been disappointed. :( It's syntax for selects is ugly and not intuitive. Django ORM looks much better. SQLAlchemy has to be added to Django as alternative ORM but *without breaking* current, clean API: http://groups.google.com/group/django-developers/browse_thread/thread/5149e1c60dc65bff/a177bb34cfde1ec7 But rhtml is much more flexible because it can generate *any content*, not only xml. But Rails has THREE template systems: rhtml (main), rxml (for rss and xml generation) and rjs (for javascript and AJAX). Well, TG has a few templating systems... MarkUp, Kid, Cheetah, ZPT, and others. You can choose the one that best fits your needs / brain. This is another topic. Rails can also use another third-party template system (like Liquid which was inspired by Django). For me using many, different template systems *for the same task* make no sense. Rails uses three templates, but for *different tasks*. Its RJS is perfect for AJAX. Really cool, simple, and almost no javascript is required. Just clean Ruby for everything. -- Jarosław Zabiełło http://blog.zabiello.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Pros/Cons of Turbogears/Rails?
On 31 Aug 2006 08:24:29 -0700, Adam Jones wrote: In moving to SQLAlchemy it would pick up not only a migration system but also a much more flexible abstraction system due to the use of a Data Mapper pattern instead of the Active Record pattern. What is the advantage of Data Mapper? I cannot find.. And last but not least, TG is based on poor, unstable and buggy CherryPy server. We had huge problems with CherryPy. I think that Django or Pylons are much better frameworks. IMO TG is no competition for Rails at all. The only real competition is Django or Pylons. I have never had much in the way of problems with CherryPy. From what I have heard the project has made a lot of improvements recently, so it may have changed since you last took a look at it. We have created two quite big sites in CheerryPy in past and we have many issues with its bad implementation. Sessions were useless, forks were removed from early code without any warning. Maybe now it is better, but I have lost any confidence in CherryPy quality. -- Jarosław Zabiełło http://blog.zabiello.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Pros/Cons of Turbogears/Rails?
On 31 Aug 2006 08:24:29 -0700, Adam Jones [EMAIL PROTECTED] wrote: Jaroslaw Zabiello wrote: [EMAIL PROTECTED] wrote: + SqlObject allows working with the DB tables without using SQL itself. Rails has ActiveRecord ORM, which IMO has nicer and simpler syntax than SQLObject. Rails has migrations, TB - not (Migrations is versioning system for evolving database schema) I don't really see TG sticking with SQLObject. In moving to SQLAlchemy it would pick up not only a migration system but also a much more flexible abstraction system due to the use of a Data Mapper pattern instead of the Active Record pattern. There already is an implementation of Active Record on top of that, so that benefit stays as well. yes indeed as someone said earlier the support is already there and all that needs to be done is a migration path. + Easy access to other libraries (such as the Python Imaging Library) that Ruby, being a relatively newer language, doesn't have equivalents to. Ruby is not so young you think. It became more popular when Rails has appeared. Although that is true there are not as many libraries available for Ruby as there are for Python. This will probably change as the language gains popularity, but for right now it pays to look into library support before considering anything else about the language. either that or all the hipy of RoR will go away. + I find the templating system somewhat cleaner; code in py: xml namespace allows pure .html templates, instead of equivalent of .rhtml files. But rhtml is much more flexible because it can generate *any content*, not only xml. But Rails has THREE template systems: rhtml (main), rxml (for rss and xml generation) and rjs (for javascript and AJAX). Kid can be used to generate xhtml, rss, xml, pretty much anything that is xml-based. I have even seen it used to generate xul applications for firefox. The only thing on your list that it doesn't do is javascript. Personally I would rather learn one templating language that is able to treat all of my xml as xml no matter what use it is put to. and for javascript you have mochikit which is really nice. Actually that point right there is where I think TG is a lot more competitive that you believe. When a new version of any of the foundation projects comes out, or a better project to fill that particular need, TG can absorb it in the next version. The TurboGears developers can spend most of their time working on additional code that makes the project more useful instead of bug fixes and minor feature upgrades to the core components. This philosophy is proven to work for most other open source projects, and I have yet to hear a good argument why it would not be successful for a web framework. I believe that is the most important part of TG, taking the best of the best, and letting the framework adapt and morphe. for example noone plan to move to SA, 0.1 came out a couple of people took and look and like it, then 0.2 was mature enough so people started thinking about the migration. after that some code was made and now we have TG with SA, eventually it will be the default. Same with templates, kid is really weak at generating non-xml, it has a plain text serializer but the input must be xml so that's overkill. So a new template frontend (chettah was born). Someone ones said on the mailing list TG is the Ubuntu of web frameworks, and I think I'll add and you can strip down the kernel and it wont break :) -Adam -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Pros/Cons of Turbogears/Rails?
On 8/31/06, Jorge Vargas [EMAIL PROTECTED] wrote: On 31 Aug 2006 08:24:29 -0700, Adam Jones [EMAIL PROTECTED] wrote: I believe that is the most important part of TG, taking the best of the best, and letting the framework adapt and morphe. for example noone plan to move to SA, 0.1 came out a couple of people took and look and like it, then 0.2 was mature enough so people started thinking about the migration. after that some code was made and now we have TG with SA, eventually it will be the default. Same with templates, kid is really weak at generating non-xml, it has a plain text serializer but the input must be xml so that's overkill. So a new template frontend (chettah was born). Someone ones said on the mailing list TG is the Ubuntu of web frameworks, and I think I'll add and you can strip down the kernel and it wont break :) But that is not really true. If you use Cheetah instead of Kid, you lose out: No widgets, no auto-generated code and the (incomplete) documentation won't apply anymore (it assumes Kid templates ofcourse). If you use SQLAlchemy instead of SQLObject, no identity framework, no administrative tools (tg-admin sql, CatWalk etc) and no documentation. If you use prototype instead of MochiKit... I have no idea what happens and using another webserver than CherryPy isn't possible right now, I guess? In fact, if you decide to replace so many modules that TurboGears depend on, what do you gain in using TurboGears at all? It seems like the TurboGears developers have a lot of work to do, (and a lot of documentation to write) if they want to make their framework as easy to use as others (ie: Django) that takes a more holistic approach. TurboGears more seem to be like emacs than Ubuntu - infinitely customizable... In the future both Rails and TurboGears will probably be great. But since someone mentioned Rails moving to YARV, and TurboGears moving to SQLAlchemy and Markup, it seems to me that they are both in a state of flux and not quite ready yet. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: Pros/Cons of Turbogears/Rails?
On Thu, 2006-08-31 at 23:31 +0200, BJörn Lindqvist wrote: On 8/31/06, Jorge Vargas [EMAIL PROTECTED] wrote: On 31 Aug 2006 08:24:29 -0700, Adam Jones [EMAIL PROTECTED] wrote: Someone ones said on the mailing list TG is the Ubuntu of web frameworks, and I think I'll add and you can strip down the kernel and it wont break :) But that is not really true. If you use Cheetah instead of Kid, you lose out: No widgets, Untrue. Even though I don't use widgets much myself, I wanted to make sure they *could* be used with TurboStan, so I did a quick test with Kevin's autocomplete widget. Worked fine. I can't see why Cheetah would be any different. no auto-generated code What auto-generated code? The example templates that you get with quickstart? Hardly a loss. and the (incomplete) documentation won't apply anymore (it assumes Kid templates ofcourse). True. However I've had little trouble translating from Kid to Stan (and that's probably a longer jump than from Kid to Cheetah). If you use SQLAlchemy instead of SQLObject, no identity framework, Completely false. no administrative tools (tg-admin sql, True. CatWalk etc True. ) and no documentation. Partially true. The documentation exists but some of it is out-of-date and it was never very complete to begin with. Of course, like many OSS projects, the mailing list is your best resource and SQLAlchemy itself has quite good documentation. If you use prototype instead of MochiKit... I have no idea what happens You get Prototype instead of MochiKit. and using another webserver than CherryPy isn't possible right now, I guess? Not that I'm aware of. Nor do I think it would make much sense since CherryPy is the heart of TurboGears. I typically use CherryPy to serve the dynamic content and a real webserver (Nginx) to serve static files. I've never felt this was a handicap. In fact, if you decide to replace so many modules that TurboGears depend on, what do you gain in using TurboGears at all? If you got to the point where you were replacing more parts than you were using, then you'd certainly want to find a different framework as TurboGears is clearly not for you. I fail to see your point. Personally I've chosen to go a different route on a couple things and leave the rest intact. I expect most people are the same. With most frameworks, there's typically one or two things most people don't like and it's nice to be able to replace those things without a lot of fuss. I don't see how that's a liability. It seems like the TurboGears developers have a lot of work to do, (and a lot of documentation to write) if they want to make their framework as easy to use as others (ie: Django) that takes a more holistic approach. That's odd, because I've actually used both and found TurboGears far easier to get started with (no mucking about with Apache and mod_python for one thing, no need to setup explicit url regexes just to get hello, world on a page). Judging from your above comments it sounds to me like you're mostly speculating about TurboGears. TurboGears more seem to be like emacs than Ubuntu - infinitely customizable... Not quite enough IMO, but close enough. In the future both Rails and TurboGears will probably be great. But since someone mentioned Rails moving to YARV, and TurboGears moving to SQLAlchemy and Markup, it seems to me that they are both in a state of flux and not quite ready yet. TurboGears is certainly in a state of flux although from an outside (i.e. API) standpoint it's not nearly as bad as you might think from the changes that have gone on under the hood. There's been only a few breaking changes up til now (I converted a site I'd built on 0.8 to the latest SVN last night and most of the issues I encountered were with my own changes to TurboStan). Regards, Cliff -- -- http://mail.python.org/mailman/listinfo/python-list
Re: Pros/Cons of Turbogears/Rails?
On Thu, 2006-08-31 at 09:04 -0700, Paul Boddie wrote: SkunkWeb (3.4.0), Zope (2.9.4 and 3.2.1), Plone (2.5), Karrigell (2.3), CherryPy (2.2.1), Spyce (2.1), QP (1.8), Cymbeline (1.3.1), Django (0.95), Webware (0.9.1), Pylons (0.9.1), TurboGears (0.8.9), PyLucid (v0.7.0RC4), Paste (0.4.1), web.py (.138) And ironically, the one with the *lowest* version number (web.py) is used to power some fairly large (and ambitious) public projects: https://www.youos.com/ ( see http://blog.youos.com/?p=49 ) http://reddit.com/ I'd like to claim that in OSS, version numbers mean little, but I still recall Windows NT 1.0 (er, I mean 3.1), so I guess they don't mean much anywhere. Version numbers are *picked* by project leads for varying reasons, so comparing version numbers from different projects is pretty pointless. Is Windows 2000 more stable than Linux 2.6? It ought to be since it's 769 times more mature, right? Even if you called it Windows NT 5.0, I'd have to wonder if it's even twice as stable (I'm being intentionally generous here, so bear with me). Personally I tend to look at what the users (especially former users) say about a project and what's been or being done with that project. If it seems promising, I try it. I can't think of any other reasonable way of making that decision. Regards, Cliff -- -- http://mail.python.org/mailman/listinfo/python-list
Re: Pros/Cons of Turbogears/Rails?
Someone ones said on the mailing list TG is the Ubuntu of web frameworks, and I think I'll add and you can strip down the kernel and it wont break :) But that is not really true. If you use Cheetah instead of Kid, you lose out: No widgets, Untrue. Even though I don't use widgets much myself, I wanted to make sure they *could* be used with TurboStan, so I did a quick test with Kevin's autocomplete widget. Worked fine. I can't see why Cheetah would be any different. Maybe I stand corrected then. But the definition of the AutoCompleteField widget is here: http://trac.turbogears.org/turbogears/browser/trunk/turbogears/widgets/big_widgets.py#L88 I really don't understand how a completely different non-xml based templating engine, with a completely different syntax, would be able to grok that. If you use SQLAlchemy instead of SQLObject, no identity framework, Completely false. Yes, I'm sorry. Last time I used it, it didn't work. But now it seem to have 100% compatibility. no administrative tools (tg-admin sql, True. CatWalk etc True. ) and no documentation. Partially true. The documentation exists but some of it is out-of-date and it was never very complete to begin with. Of course, like many OSS projects, the mailing list is your best resource and SQLAlchemy itself has quite good documentation. SQLAlchemy does, yes. If you use prototype instead of MochiKit... I have no idea what happens You get Prototype instead of MochiKit. ... And the docs showing you how to integrate TurboGears with AJAXy stuff ofcourse no longer applies. Personally I've chosen to go a different route on a couple things and leave the rest intact. I expect most people are the same. With most frameworks, there's typically one or two things most people don't like and it's nice to be able to replace those things without a lot of fuss. I don't see how that's a liability. I disagree, most frameworks do not let you replace its components. They are a take it or leave it kind of deal. I like that. The more adaptable you try to make a piece of code, the more complex it becomes. Obviously, it is easier to make code that supports one templating engine than to make it that supports everyone. You then most solve that additional complexity. Both in the code AND in the documentation and you must ensure that the additional complexity doesn't leak and make users life miserable. I think Jorge claimed that TurboGears was very pluggable and I claimed that it wasn't so. My point is that making the code pluggable is not enough. All the stuff around it also need to support the pluggability, not the least the docs. That's odd, because I've actually used both and found TurboGears far easier to get started with (no mucking about with Apache and mod_python for one thing, no need to setup explicit url regexes just to get hello, world on a page). Judging from your above comments it sounds to me like you're mostly speculating about TurboGears. Not so. During 3 months a few months ago I've built a pretty big web application using TurboGears. The easy of use of a framework isn't writing hello, world applications, it is finding out how to do things, doing them and how fast you can do it. In the future both Rails and TurboGears will probably be great. But since someone mentioned Rails moving to YARV, and TurboGears moving to SQLAlchemy and Markup, it seems to me that they are both in a state of flux and not quite ready yet. TurboGears is certainly in a state of flux although from an outside (i.e. API) standpoint it's not nearly as bad as you might think from the changes that have gone on under the hood. There's been only a few breaking changes up til now (I converted a site I'd built on 0.8 to the latest SVN last night and most of the issues I encountered were with my own changes to TurboStan). You must have been luckier than me then or maybe you didn't use much advanced functionality? I converted a site from SVN head somewhere at 0.9 to 1.1 and there were lots of breakages. Anyway, I think we have different definitions for not quite ready. Lets say you have to build and maintain a site or web application together with two other developers who (like most web developers) doesn't know Python. Would you then choose TurboGears? -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: Pros/Cons of Turbogears/Rails?
Paul Boddie wrote: fuzzylollipop wrote: Paul Boddie wrote: fuzzylollipop wrote: uh, no, Python predates Ruby by a good bit Rails might be older than Turbogears but it still JUST went 1.0 officially. It can't be called mature' by any defintition. Version numbers are a fairly useless general metric of project maturity, taken in isolation. But 1.0 releases do mean something, it means the DEVELOPER of the package things it is just now ready for general consumption. That means something regardless of what the number is. In various open source circles, the mere usage of 1.0 may indicate some kind of stability, but not necessarily maturity, or at least the desire of the developers to persuade users that the code is ready for them to use. nope in GENERAL usage, 1.x means that the developer is designating a version that is feature complete and stable. I never ever mentioned comparing version numbers between differing packages. MY POINT was the developers of Rails JUST RECENTLY decided that it was ready for general consumption compared to all the PREVIOUS Rails releases. And NONE of these frameworks has been used to power anything along the scale of what I work with on a daily basis. And speaking from experience, autogenerated Active Object Pattern frameworks dont' scale. And Rails is no exception. It didn't work 10 years ago when all the ORM vendors were selling ridiculously price point and click database application builders, what makes people think it will now? -- http://mail.python.org/mailman/listinfo/python-list
Re: Pros/Cons of Turbogears/Rails?
Sam Smoot wrote: big rant snipped since Google Groups has what I responding to: So if you decide to reply, might I suggest spending a few minutes with Google to get your facts straight next time? Oh, and keeping an eye on the actual topic might be a good idea too. I got my facts straight, Ruby is not tested in production environments. And I am speaking from a BIG internet site scale. Apache is mature, there is a definition of mature tested in the wild in production, and you qualified your opinion by excluding edge cases, the internet is NOTHING BUT EDGE CASES. Just look at the SMTP and HTTP RFC's they are nothing but edge cases. And read the entire thread, I am the one that specifically stated that the original poster was confused on what he was asking about. Let me make it really clear. Neither Ruby NOR Rails is mature by ANY REASONABLE definition. -- http://mail.python.org/mailman/listinfo/python-list
Re: Pros/Cons of Turbogears/Rails?
fuzzylollipop wrote: I got my facts straight, Ruby is not tested in production environments. That's odd... it's running bank websites, credit-card processing, high traffic sites like ODEO and Penny-Arcade. Seems pretty production to me. And I am speaking from a BIG internet site scale. Yes yes, I'm sure that never fails to impress the ladies. The internet is NOTHING BUT EDGE CASES. I beg to differ. Step outside of the Top 1000 and the web is largely marketing, portfolio, reporting, and boring administration sites. Neither Ruby NOR Rails is mature by ANY REASONABLE definition. Companies and individuals are using it to competitive advantage every day. Obviously you don't have much (if any) actual experience with Ruby OR Rails. By the way, we've yet to hear your opinion on Python and TurboGears... -- http://mail.python.org/mailman/listinfo/python-list
Re: Pros/Cons of Turbogears/Rails?
On 8/31/06, BJörn Lindqvist [EMAIL PROTECTED] wrote: On 8/31/06, Jorge Vargas [EMAIL PROTECTED] wrote: On 31 Aug 2006 08:24:29 -0700, Adam Jones [EMAIL PROTECTED] wrote: I believe that is the most important part of TG, taking the best of the best, and letting the framework adapt and morphe. for example noone plan to move to SA, 0.1 came out a couple of people took and look and like it, then 0.2 was mature enough so people started thinking about the migration. after that some code was made and now we have TG with SA, eventually it will be the default. Same with templates, kid is really weak at generating non-xml, it has a plain text serializer but the input must be xml so that's overkill. So a new template frontend (chettah was born). Someone ones said on the mailing list TG is the Ubuntu of web frameworks, and I think I'll add and you can strip down the kernel and it wont break :) But that is not really true. If you use Cheetah instead of Kid, you lose out: No widgets, that is not correct all widgets have a template attribute which yes it's kid but replacing it is as simple as changing it's value to a Cheetah template. no auto-generated code and the (incomplete) that is not correct, the only part I can think about is not having default templates, which are just a demostration/sample app. other then master.kid I don't think any of the others are used, and the concept of master.kid doesn't exists in cheetah I think, if you are really concern about this please create pasteScript with the chettah default templates and I'll make sure it gets into the trunk as the sqlalchemy autogenerated code did. documentation won't apply anymore (it assumes Kid templates ofcourse). actually no, you get a dict of values into your template, now if your talking about teaching how to use the other templating engines then I suggest you read their docs, because at that point TG changes nothing (except 2 or 3 variables that are populated by TG into the templates) If you use SQLAlchemy instead of SQLObject, no identity framework, not true it was commited together with the support for SA 0.2 no administrative tools (tg-admin sql, CatWalk etc) ok first tg-admin sql is just a wrapper around sqlobject-admin so the lack of that tool is actually a lack in SA. about Catwalk and model designer they where created to work with SO, in fact they are so couple that probably a new tool will be written. and no documentation. yes we had many troubles with that we have went from one system to another but we settle with rest and are going to use moinmoin for a while until docudo is ready. all the docs are being integrated there and as we have said there wont be 1.0 until we have lots of docs. If you use prototype instead of MochiKit... I have no idea what happens MochiKit is the most decouple part of the project you can include almost anything as long as the javascript doesn't collide with eachother (for example there was a problem with prototype and MochiKit used together a couple of months ago) and using another webserver than CherryPy isn't possible right now, I guess? there have been some initiatives (experiments mostly about it, and docs about it on trac) and they work although changing CP is the most challenging part and I don't think anyone involve with the project wants that, although you are welcome to try, if X becomes a replacement for CP we'll migrate to it. all that needs to be done is write the method/paths logic and make X handle dictionaries as return values. you may as well make your own smash up of tools if you want to replace all components a couple of emails below you said you just wanted to say that there is no infix replace and I never said it was like that I said if you want to change it go ahead the framework wont stop you like happens with RoR or Django. at last I dont' agree with you that making the framework support more things makes it more complex, TG design is genious in that part for example all template plugins (which are small package define a small set of variables (actually a class, or abstract class or interface, whatever you want to call it.) http://www.turbogears.org/docs/plugins/template.html so after that the rest of the code doesn't cares about which render is actually going to be use. and that's why the same TG app can render with more then one templating engine at the time. in fact you can have the same method render with 2 different engines if you may need it. In fact, if you decide to replace so many modules that TurboGears depend on, what do you gain in using TurboGears at all? It seems like the TurboGears developers have a lot of work to do, (and a lot of documentation to write) if they want to make their framework as easy to use as others (ie: Django) that takes a more holistic approach. TurboGears more seem to be like emacs than Ubuntu - infinitely customizable... In the future both Rails and TurboGears will probably be great. But
Re: Pros/Cons of Turbogears/Rails?
[comp.lang.ruby snipped] Ray wrote: Paul Boddie wrote: So actual maturity isn't important when using a technology: it's perceived maturity that counts, right? Well depends on counts in what sense. Counts as in the managers up there perceive something as mature, despite proofs of the contrary, certainly counts, because then we'll end up having to work with a probably immature technology (nothing about RoR here, I'm talking in general). Yes, I saw this with Java several years ago. However, as someone actually using the technology concerned, it's obviously vital to make the distinction between actual and perceived maturity. My impression is that we're seeing developers, not managers, failing to make that distinction. Yet with more people using it, its actual maturity will inevitably rise as well, maybe eventually to a level near that of its perceived maturity. This sentiment somehow reminds me of various Oracle products. Counts as in to us developers who are actually spending our lives doing this? Perhaps yes too. If you're well-versed in something that is widely perceived to be mature, you may find it easier to win bread for your family, even if you have a painful time using it. Sure. Just get certified on whatever today's middle management are advocating, spend a few years working with that stuff, then repeat the process for the next generation of middle management - it can certainly make money for people who don't seek any meaning in what they do. [...] If you only listen to Bruce Tate et al, I imagine you could have the above impression, but I'd be interested to see hard facts to back up those assertions. Yeah, see, the thing is that Python is not lacking luminaries endorsing it either, e.g.: Eric Raymond and Bruce Eckel. But for some reason this Python is good meme is not that viral. I wonder why... Python has had its share of the spotlight: Eric Raymond's advocacy dates back to the late 1990s; Bruce Eckel still advocates Python but started doing so a few years ago. Perhaps the latest arrivals to the party (celebrating dynamic languages in this case) are usually the loudest, in order to make up for their sluggish realisation that Java isn't the panacea they insisted it was while it was still the cool new thing. Or perhaps a lot of these people do quite nicely out of surfing whatever trend currently is the cool new thing. And, since when do hard facts matter anyway? When certain individuals claim that more Java people know about Ruby than they do about Python. I know that there are people out there who know (about) Java but not about Jython, for example, but even in circles where buzz and hype seem like everything (eg. marketing) the hard facts or statistics are still critical because they actually help those people do their job properly. Moreover, just stating something doesn't make it true - the hard facts serve to prove or disprove such assertions, and to anyone serious about understanding the underlying phenomena, it's vital to seek those facts out. I've met a number of people who've told me they'd program in Eiffel if they could. And hey, perhaps in its day Eiffel *was* the best OO language out there. Certainly it looked cleaner than C++! :) So why don't they? Management pressure? Why don't people write more Python in their day job? Any suggestions? Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Pros/Cons of Turbogears/Rails?
Paul Boddie a écrit : [comp.lang.ruby snipped] Ray wrote: I've met a number of people who've told me they'd program in Eiffel if they could. And hey, perhaps in its day Eiffel *was* the best OO language out there. Certainly it looked cleaner than C++! :) So why don't they? Management pressure? Why don't people write more Python in their day job? Any suggestions? Probably because of the extreme Bondange And Disciplineness of Eiffel, the incredible cost of each user license, lack of generic programing ( you know, the thing easy to do in Python/Ruby but requires templates in C++ ) and the complete lack of a correct debugger. By now, it seems that some of those problems have been fixed in various ways but we now have even better : incompatible implementations of the language! Eiffel is for all purposes a niche language only used by some fanatics here and there :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Pros/Cons of Turbogears/Rails?
Paul Boddie wrote: snip Sure. Just get certified on whatever today's middle management are advocating, spend a few years working with that stuff, then repeat the process for the next generation of middle management - it can certainly make money for people who don't seek any meaning in what they do. It can certainly make money--true. Don't seek any meaning in what they do?! You're just accusing a lot of honest hardworking people to be mindless drones there. We have feelings too, you know :( Yeah, see, the thing is that Python is not lacking luminaries endorsing it either, e.g.: Eric Raymond and Bruce Eckel. But for some reason this Python is good meme is not that viral. I wonder why... Python has had its share of the spotlight: Eric Raymond's advocacy dates back to the late 1990s; Bruce Eckel still advocates Python but started doing so a few years ago. Perhaps the latest arrivals to the party (celebrating dynamic languages in this case) are usually the loudest, in order to make up for their sluggish realisation that Java isn't the panacea they insisted it was while it was still the cool new thing. Or perhaps a lot of these people do quite nicely out of surfing whatever trend currently is the cool new thing. Perhaps that is true. A pity though, personally I tried to learn Ruby but it just doesn't go well with my brain. And, since when do hard facts matter anyway? When certain individuals claim that more Java people know about Ruby than they do about Python. First, that question was supposed to be rhetorical :) Second, my claim is not that general. Certainly proving such a general claim is an enormous undertaking. It just happens that most of Java developers I know, and I know quite a lot since I've been doing this for years, they know Ruby and Rails. Python, Django, Turbogears, make them go huh?. I've heard of one entrepreneurial guy starting an exclusively RoR shop and doing quite well at it. I haven't heard a Django/Turbogears shop yet. I know that there are people out there who know (about) Java but not about Jython, for example, but even in circles where buzz and hype seem like everything (eg. marketing) the hard facts or statistics are still critical because they actually help those people do their job properly. Moreover, just stating something doesn't make it true - the hard facts serve to prove or disprove such assertions, and to anyone serious about understanding the underlying phenomena, it's vital to seek those facts out. True. But since when do hard facts matter? That is, it's not that I haven't tried to make people know how great Python is. but I can talk until I'm blue in the face and they just go, nah. What I'm saying is that people (and management) unfortunately are sold to not with hard facts, but with whatever that X viral factor is. And for some reason the RoR crowd has managed to make it quite viral. I've met a number of people who've told me they'd program in Eiffel if they could. And hey, perhaps in its day Eiffel *was* the best OO language out there. Certainly it looked cleaner than C++! :) So why don't they? Management pressure? Why don't people write more Python in their day job? Any suggestions? Well, I posted in this group a few weeks ago because I was trying to convince the managers to give Python a try and was looking for additional ammo. In the end Django is out because of its lack of support for Oracle. But it's a catch 22 isn't it? We're a Java shop so our developers are trained in Java, Struts, Tomcat, etc. Any switch to a dynamic language will be a huge change. However it baffles me that they are open to at least a PoC in Rails. but when I suggested Python, they went: nah we're not interested in Python. Rails it is. *shrugs* whatever it is, those guys are doing something right. Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Pros/Cons of Turbogears/Rails?
Ray wrote: It can certainly make money--true. Don't seek any meaning in what they do?! You're just accusing a lot of honest hardworking people to be mindless drones there. We have feelings too, you know :( Well, I'm sorry for the unintentional insult. However, I've come to believe that some people have the personality traits that let them tolerate redoing the same work over and over again for no reason other than management furniture rearranging, whereas others start to resent having their (working) life repeatedly flashed before their eyes, but in slightly different colours, over a longer period of time. If there's some kind of art that somehow increases tolerance of such things in a humane way, I'd be interested to know what it is. [...] Well, I posted in this group a few weeks ago because I was trying to convince the managers to give Python a try and was looking for additional ammo. In the end Django is out because of its lack of support for Oracle. But it's a catch 22 isn't it? In the end, provided you have the time and energy (or money) for it, you just have to make your own plan for bridging whatever gap there is in the functionality of whatever open source project you intend to employ professionally. I was once in a similar situation myself, with Oracle products as well, where I had to put in the work myself to get the necessary support needed for having my Python plus Oracle code working in an environment that was Python-sceptical at best. I guess the code was ultimately taken out of production, and everyone went over to a pure Java strategy, but you can't always infuence people by lobbying. We're a Java shop so our developers are trained in Java, Struts, Tomcat, etc. Any switch to a dynamic language will be a huge change. However it baffles me that they are open to at least a PoC in Rails. but when I suggested Python, they went: nah we're not interested in Python. Rails it is. *shrugs* whatever it is, those guys are doing something right. Making the Java people feel like they're doing something wrong, I guess. And perhaps the Rails people realised that by giving those people who lack direction, motivation, conviction or a sense of purpose or control something to gravitate towards, some of them might feel empowered enough to evangelise their discovery to the rest of the group. Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Pros/Cons of Turbogears/Rails?
Paul Boddie wrote:
Ray wrote:
(snip)
We're a Java shop so
our developers are trained in Java, Struts, Tomcat, etc. Any switch to
a dynamic language will be a huge change. However it baffles me that
they are open to at least a PoC in Rails. but when I suggested Python,
they went: nah we're not interested in Python. Rails it is.
*shrugs* whatever it is, those guys are doing something right.
Making the Java people feel like they're doing something wrong, I
guess. And perhaps the Rails people realised that by giving those
people who lack direction, motivation, conviction or a sense of purpose
or control something to gravitate towards, some of them might feel
empowered enough to evangelise their discovery to the rest of the
group.
FWIW, and while it's certainly not enough by itself to explain the
phenomenon, I think that Ruby's object model being much more
conventional than Python's may have some influence too on RoR's adoption
by the Java world.
--
bruno desthuilliers
python -c print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@')])
--
http://mail.python.org/mailman/listinfo/python-list
Re: Pros/Cons of Turbogears/Rails?
Bruno Desthuilliers wrote:
Paul Boddie wrote:
Ray wrote:
(snip)
We're a Java shop so
our developers are trained in Java, Struts, Tomcat, etc. Any switch to
a dynamic language will be a huge change. However it baffles me that
they are open to at least a PoC in Rails. but when I suggested Python,
they went: nah we're not interested in Python. Rails it is.
*shrugs* whatever it is, those guys are doing something right.
Making the Java people feel like they're doing something wrong, I
guess. And perhaps the Rails people realised that by giving those
people who lack direction, motivation, conviction or a sense of purpose
or control something to gravitate towards, some of them might feel
empowered enough to evangelise their discovery to the rest of the
group.
FWIW, and while it's certainly not enough by itself to explain the
phenomenon, I think that Ruby's object model being much more
conventional than Python's may have some influence too on RoR's adoption
by the Java world.
I don't know enough about Ruby to comment, but how is its object model
more conventional than Python's? The only thing I can see is access
control for methods, which seems like a silly thing to base a language
decision on.
--
bruno desthuilliers
python -c print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@')])
--
http://mail.python.org/mailman/listinfo/python-list
Re: Pros/Cons of Turbogears/Rails?
Adam Jones wrote:
Bruno Desthuilliers wrote:
Paul Boddie wrote:
Ray wrote:
(snip)
We're a Java shop so
our developers are trained in Java, Struts, Tomcat, etc. Any switch to
a dynamic language will be a huge change. However it baffles me that
they are open to at least a PoC in Rails. but when I suggested Python,
they went: nah we're not interested in Python. Rails it is.
*shrugs* whatever it is, those guys are doing something right.
Making the Java people feel like they're doing something wrong, I
guess. And perhaps the Rails people realised that by giving those
people who lack direction, motivation, conviction or a sense of purpose
or control something to gravitate towards, some of them might feel
empowered enough to evangelise their discovery to the rest of the
group.
FWIW, and while it's certainly not enough by itself to explain the
phenomenon, I think that Ruby's object model being much more
conventional than Python's may have some influence too on RoR's adoption
by the Java world.
I don't know enough about Ruby to comment, but how is its object model
more conventional than Python's?
short answer (no time to elaborate...) and IMHO (of course):
Well, Ruby's object model is mostly based on Smalltalk, with private
attributes representing state, public methods representing behaviour,
and a message passing mechanism which will select the appropriate
method an call it.
In Python, an object is mostly a set of attributes, some of them
implementing the descriptor protocol, some of them being callables, and
one of them being the class object (which itself etc...). On top of
this, you have a lookup mechanism and a 'call' operator. And message
passing in fact boils down to retrieving an attribute (thru the lookup
mechanism, which can itself cause function/method calls, decorate the
attribute etc), and eventually apply the call operator to this attribute.
From the surface, the main visible differences are that Python has no
proper access restrictions and that one can retrieve a reference to a
method object via simple lookup, but the philosophy is really different
IMHO.
The only thing I can see is access
control for methods, which seems like a silly thing to base a language
decision on.
Java's philosophy is bondage and discipline. This has been sold over and
over to both suits and programmers. Making the move to a dynamically
typed language is already a big step for some of these peoples, so even
if all the difference they see is the absence of access control, I think
it can impact the choice. Now go tell them you can even change the class
of a given instance at runtime, and look at them running away screaming !-)
Not to say Ruby is less flexible or dynamic than Python (AFAICT, they
both have roughly equivalent potential in this domain), but Ruby can
surely look safer and way less confusing than Python to Java'ers.
--
bruno desthuilliers
python -c print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@')])
--
http://mail.python.org/mailman/listinfo/python-list
Re: Pros/Cons of Turbogears/Rails?
Robert Kern wrote: You might be. No one else in the thread is. What are you saying? That my perception that RoR is mature is wrong? I never even said that was mine. That was what I got from talking to a lot of developers whose main language is neither Python nor Ruby, while I was trying to introduce Python to them. I've always been enthusiastic about Python and think it'd be nice for a change to be able to work with it in a project at work instead of at home. And yes, no one else in this thread, which consists of 6 posts so far, says so, so how is it even relevant to how other developers perceive RoR in comparison with Django or Turbogears? You're not making any sense here. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: Pros/Cons of Turbogears/Rails?
Ray wrote: Robert Kern wrote: You might be. No one else in the thread is. What are you saying? That my perception that RoR is mature is wrong? No, that the part of your message that I quoted was wrong. Specifically, we're talking of perception here. No one else here is talking about the perception of maturity but claims about the actual maturity. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: Pros/Cons of Turbogears/Rails?
Hi allIt might be interesting to watch the videos about Django and Rails (http://www.djangoproject.com/snakesandrubies/). Django makes a good impression, although I would not agree with all of their arguments (eg. templating language, ajax). Most striking, though, is the difference in attitude! While Django grew out of a production environment and solves real problems very elegantly, Rails comes out of beauty, whatever that means. Is Ruby code more beautiful than Python - don't think so. Nevertheless, I agree with original statement that we Python guys need to look very closely at Ruby and why they are able to catch so much attention. There are good things in the language and Python marketing could certainly be improved. The new web site and logo are good steps in the right direction. Now for free t-shirts to create pervasive awareness? ;-) regardsAndre -- http://mail.python.org/mailman/listinfo/python-list
Re: Pros/Cons of Turbogears/Rails?
Ray wrote:
(snip)
Sadly, there are more Java guys who know about Ruby than Python,
despite the fact that Python predates Ruby by quite a few years...
FWIW, Python is somewhat older than Java too...
--
bruno desthuilliers
python -c print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@')])
--
http://mail.python.org/mailman/listinfo/python-list
Re: Pros/Cons of Turbogears/Rails?
[EMAIL PROTECTED] wrote:
First, I don't intend this to be a flame war, please.
Then avoid crossposting to both c.l.ruby and c.l.python !-)
(BTW, fu2 c.l.python).
Python
and Ruby are the only two languages I'd willingly work in
(at least amongst common languages), and TurboGears and
Rails seem roughly equivalent.
I'm much more knowledgable about Python, but that's a minor
issue--I've been intending to learn more Ruby anyway.
Here are the pros and cons that I'm aware of and consider
important:
Turbogears:
+ SqlObject allows working with the DB tables without
using SQL itself.
I personnaly don't like SqlObject. SqlAlchemy looks like a much better
solution IMHO. And FWIW, Ruby has it's own ORM too.
(snip)
I was initially leaning towards Rails due to maturity,
but the most recent version of TurboGears seem to have
fixed a lot of the ad hoc feeling I got from previous
versions. But I'm still very much up in the air.
Then take a few days to play with both Rails and TG and go with the one
that better fits your brain.
FWIW, you may also want to check Pylons (another Python Web-MVC framework).
My 2 cents
--
bruno desthuilliers
python -c print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@')])
--
http://mail.python.org/mailman/listinfo/python-list
Re: Pros/Cons of Turbogears/Rails?
Ray wrote: fuzzylollipop wrote: uh, no, Python predates Ruby by a good bit Rails might be older than Turbogears but it still JUST went 1.0 officially. It can't be called mature' by any defintition. Version numbers are a fairly useless general metric of project maturity, taken in isolation. But at least in most developers' perception, it is (not necessarily in the absolute sense, but perhaps relative to Django or Turbogears). Mind, it doesn't even need to be true, we're talking of perception here. So actual maturity isn't important when using a technology: it's perceived maturity that counts, right? Any continuation down that particular path of reasoning surely leads you to the point where you claim, in concert with the developers, that increasing levels of inconvenience caused by gratuitous changes or broken documentation is not caused by bugs or general immaturity but by features. I guess this is the definition of opinionated software that some people are so excited about. [...] Sadly, there are more Java guys who know about Ruby than Python, despite the fact that Python predates Ruby by quite a few years... (this must be that Bruce Tate dude's fault! ) If you only listen to Bruce Tate et al, I imagine you could have the above impression, but I'd be interested to see hard facts to back up those assertions. Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Pros/Cons of Turbogears/Rails?
As I read in another post on this thread, do some initial scoping out of either framework and pick the one that seems to suit your way of thinking/coding the best. If you scan over some sample code on the projects' websites you should get a basic idea of what they will be like. Although a bit more obscure than the two frameworks you are considering, have you checked out Seaside (http://seaside.st)? It's a Smalltalk framework that interests me personally. I've had the opportunity to check it out briefly, but haven't had a chance to actually mock up an app using it. If you check it out as well as a neat AJAX library that can overlay it called Scriptaculous (http://script.aculo.us) you can do some pretty slick things concisely. I doubt that something like this will immediately skyrocket to the top of the commercial developer's hit list, but it is something that I would play around with since it will only expand my knowledge base. And I can have fun while doing it :-) Out of what I've seen working with Rails and checking out TurboGears I chose Rails since it fit in with my way of thinking the best. Everyone has their own taste so I wouldn't take any one person's (or one group's) opinion. Read up on them a bit and see which one looks the most interesting to you. [EMAIL PROTECTED] wrote: First, I don't intend this to be a flame war, please. Python and Ruby are the only two languages I'd willingly work in (at least amongst common languages), and TurboGears and Rails seem roughly equivalent. I'm much more knowledgable about Python, but that's a minor issue--I've been intending to learn more Ruby anyway. Here are the pros and cons that I'm aware of and consider important: Turbogears: + SqlObject allows working with the DB tables without using SQL itself. + Likely to be faster because as far as I'm aware, Python is significantly faster. + Easy access to other libraries (such as the Python Imaging Library) that Ruby, being a relatively newer language, doesn't have equivalents to. + Built-in default SQLite makes it easier to set up? (as far as I can tell, Ruby requires MySql by default--don't know how easy this is to change.) + I find the templating system somewhat cleaner; code in py: xml namespace allows pure .html templates, instead of equivalent of .rhtml files. Ruby: + More mature system. More stable? More features? + Much better documented. This is a biggie. + Built-in Rubydoc system would make documenting the system easier. (IMHO, developers almost always underestimate the need for good documentation that is written along withe the system.) Is there a Python doc system that has received Guido's blessing yet? D'oxygen would seem an obvious choice. + Better coordination with Javascript helper code? I was initially leaning towards Rails due to maturity, but the most recent version of TurboGears seem to have fixed a lot of the ad hoc feeling I got from previous versions. But I'm still very much up in the air. Thanks, Ken P.S. If I wanted to provide an image by streaming the file data directly over the connection, rather than by referring to an image file, how would I do that? I'd like to build code that would allow images to be assembled into a single-file photo album (zip or bsddb file), and so can't refer to them as individual image files. -- http://mail.python.org/mailman/listinfo/python-list
Re: Pros/Cons of Turbogears/Rails?
fuzzylollipop wrote: uh, no, Python predates Ruby by a good bit Rails might be older than Turbogears but it still JUST went 1.0 officially. Wow that's a lot of FUD, especially since you're beating up on Rails for it's docs and maturity, when I doubt (but couldn't prove) turbogears comes close. Lets be specific: 12/13/05: http://dev.rubyonrails.org/changeset/3303 It can't be called mature' by any defintition. It's easy to deploy a site without running into bugs as long as you're not dealing with any edge-cases. As far as OSS solutions go, that pretty well fits my definition of mature. So there's one. Rails has no documentation, period. The authors acknowledge this openly. Why you would just talk out of your ass like this escapes me. http://api.rubyonrails.org (Look at any of the :Base classes for overviews) http://rubydoc.org (For basic Ruby help) http://rails.techno-weenie.net/ (Help with the lesser known areas of RoR, and tips tricks) http://www.bigbold.com/snippets/tags/rails (Snippets other people have found useful) http://wiki.rubyonrails.com/rails/pages/Howtos (Lots of Getting Started type how-tos) http://caboo.se (A blog aggregation of some of the committer's ) Then again, you could just google for rails documentation (here's a link: http://www.google.com/search?client=safarirls=enq=rails+documentationie=UTF-8oe=UTF-8 ) And the top link will take you to a page on the Wiki that describes all of this. Until you want to start writing plugins and such, this documentation pretty much fits the bill. Could there be more? Yes. Is it perfect? Obviously not. Is finding documentation going to be a problem for anyone willing to spend a few minutes with Google or on IRC asking questions if you're genuinely trying? I seriously doubt it. again, Ruby can't be considered 'mature' by any definition. It seems like you're the one confusing things now. Ruby is obviously a pretty mature language. There are definite feature holes (encoding aware Strings, native Threads), but the community, documentation, tutorials (by far the best of any language I've learned), are all pretty mature. Is Rails mature? Compared to JSP? Probably not... compared to TurboGears? (The entire point of this topic, which you conveniently side-step by managing to not mention it once) Easily. So if you decide to reply, might I suggest spending a few minutes with Google to get your facts straight next time? Oh, and keeping an eye on the actual topic might be a good idea too. -- http://mail.python.org/mailman/listinfo/python-list
Re: Pros/Cons of Turbogears/Rails?
In my understanding, which relies completely on the judgements of co-workers regarding the rails side of the debate, TurboGears is more flexible. Tasks which fall inside the scope of Rails' opinion are probably easier there, but anything outside of what Rails was built to do is harder than equivalent deviations from TurboGears. Obviously this amounts to little more than hearsay, but nonetheless I think it is an important element to look into. I can say that each of them has their own genius decisions, and neither is so lacking in documentation or community support to preclude choosing either framework based on how well it suits your project. -- http://mail.python.org/mailman/listinfo/python-list
Re: Pros/Cons of Turbogears/Rails?
Paul Boddie wrote: But at least in most developers' perception, it is (not necessarily in the absolute sense, but perhaps relative to Django or Turbogears). Mind, it doesn't even need to be true, we're talking of perception here. So actual maturity isn't important when using a technology: it's perceived maturity that counts, right? Well depends on counts in what sense. Counts as in the managers up there perceive something as mature, despite proofs of the contrary, certainly counts, because then we'll end up having to work with a probably immature technology (nothing about RoR here, I'm talking in general). Yet with more people using it, its actual maturity will inevitably rise as well, maybe eventually to a level near that of its perceived maturity. Counts as in to us developers who are actually spending our lives doing this? Perhaps yes too. If you're well-versed in something that is widely perceived to be mature, you may find it easier to win bread for your family, even if you have a painful time using it. Any continuation down that particular path of reasoning surely leads you to the point where you claim, in concert with the developers, that increasing levels of inconvenience caused by gratuitous changes or broken documentation is not caused by bugs or general immaturity but by features. I guess this is the definition of opinionated software that some people are so excited about. [...] Sadly, there are more Java guys who know about Ruby than Python, despite the fact that Python predates Ruby by quite a few years... (this must be that Bruce Tate dude's fault! ) If you only listen to Bruce Tate et al, I imagine you could have the above impression, but I'd be interested to see hard facts to back up those assertions. Yeah, see, the thing is that Python is not lacking luminaries endorsing it either, e.g.: Eric Raymond and Bruce Eckel. But for some reason this Python is good meme is not that viral. I wonder why... And, since when do hard facts matter anyway? I've met a number of people who've told me they'd program in Eiffel if they could. And hey, perhaps in its day Eiffel *was* the best OO language out there. Certainly it looked cleaner than C++! :) Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Pros/Cons of Turbogears/Rails?
On 8/27/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: First, I don't intend this to be a flame war, please. Python and Ruby are the only two languages I'd willingly work in (at least amongst common languages), and TurboGears and Rails seem roughly equivalent. I'm much more knowledgable about Python, but that's a minor issue--I've been intending to learn more Ruby anyway. Here are the pros and cons that I'm aware of and consider important: Turbogears: + SqlObject allows working with the DB tables without using SQL itself. yes and SQLAlchemy lets you do more complex things, like working with an existing database. + Likely to be faster because as far as I'm aware, Python is significantly faster. no idea there. + Easy access to other libraries (such as the Python Imaging Library) that Ruby, being a relatively newer language, doesn't have equivalents to. python's'lib is MUCH more bigger + Built-in default SQLite makes it easier to set up? actually no you still have to install sqlite and the build in is just a config entry. (as far as I can tell, Ruby requires MySql by default--don't know how easy this is to change.) + I find the templating system somewhat cleaner; code in py: xml namespace allows pure .html templates, instead of equivalent of .rhtml files. Ruby: + More mature system. More stable? More features? not at all, you could say that in a TG vrs django or zope. + Much better documented. This is a biggie. TG docs are lacking at the moment mainly due to a problem with the documentation engine, we have been bouncing between trac,docudo, xmls and now moinmoin. this will be settle soon, until this is fix there will be on 1.0 (which may be the reason why RoR is already out and TG isn't) + Built-in Rubydoc system would make documenting the system easier. (IMHO, developers almost always underestimate the need for good documentation that is written along withe the system.) Is there a Python doc system that has received Guido's blessing yet? D'oxygen would seem an obvious choice. huh? docstrings ... + Better coordination with Javascript helper code? again huh, in TG you include a JS lib and it's done. if someone has made a widget for it all you have to do is install it (easy_install widget). I was initially leaning towards Rails due to maturity, but the most recent version of TurboGears seem to have fixed a lot of the ad hoc feeling I got from previous versions. But I'm still very much up in the air. is that 0.5 and 0.8? almost everyone on TG runs the 0.9 alpha's there has been so much code in to them that is stable as a rock. Thanks, Ken P.S. If I wanted to provide an image by streaming the file data directly over the connection, rather than by referring to an image file, how would I do that? I'd like to build code that would allow images to be assembled into a single-file photo album (zip or bsddb file), and so can't refer to them as individual image files. if that's the case either is just overkill all you need is a simple httpserver and reading a bit about image encoding. -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Pros/Cons of Turbogears/Rails?
Ray wrote: Paul Boddie wrote: But at least in most developers' perception, it is (not necessarily in the absolute sense, but perhaps relative to Django or Turbogears). Mind, it doesn't even need to be true, we're talking of perception here. So actual maturity isn't important when using a technology: it's perceived maturity that counts, right? Well depends on counts in what sense. Counts as in the managers up there perceive something as mature, despite proofs of the contrary, certainly counts, because then we'll end up having to work with a probably immature technology (nothing about RoR here, I'm talking in general). Yet with more people using it, its actual maturity will inevitably rise as well, maybe eventually to a level near that of its perceived maturity. Counts as in to us developers who are actually spending our lives doing this? Perhaps yes too. If you're well-versed in something that is widely perceived to be mature, you may find it easier to win bread for your family, even if you have a painful time using it. Any continuation down that particular path of reasoning surely leads you to the point where you claim, in concert with the developers, that increasing levels of inconvenience caused by gratuitous changes or broken documentation is not caused by bugs or general immaturity but by features. I guess this is the definition of opinionated software that some people are so excited about. [...] Sadly, there are more Java guys who know about Ruby than Python, despite the fact that Python predates Ruby by quite a few years... (this must be that Bruce Tate dude's fault! ) If you only listen to Bruce Tate et al, I imagine you could have the above impression, but I'd be interested to see hard facts to back up those assertions. Yeah, see, the thing is that Python is not lacking luminaries endorsing it either, e.g.: Eric Raymond and Bruce Eckel. But for some reason this Python is good meme is not that viral. I wonder why... And, since when do hard facts matter anyway? I've met a number of people who've told me they'd program in Eiffel if they could. And hey, perhaps in its day Eiffel *was* the best OO language out there. Certainly it looked cleaner than C++! :) Also remember that there are still lots of Python users who keep the fact quiet because they regard it as a strategic advantage. They don't *want* Python usage to spread, or they'll lose their advantage. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden -- http://mail.python.org/mailman/listinfo/python-list
Pros/Cons of Turbogears/Rails?
First, I don't intend this to be a flame war, please. Python and Ruby are the only two languages I'd willingly work in (at least amongst common languages), and TurboGears and Rails seem roughly equivalent. I'm much more knowledgable about Python, but that's a minor issue--I've been intending to learn more Ruby anyway. Here are the pros and cons that I'm aware of and consider important: Turbogears: + SqlObject allows working with the DB tables without using SQL itself. + Likely to be faster because as far as I'm aware, Python is significantly faster. + Easy access to other libraries (such as the Python Imaging Library) that Ruby, being a relatively newer language, doesn't have equivalents to. + Built-in default SQLite makes it easier to set up? (as far as I can tell, Ruby requires MySql by default--don't know how easy this is to change.) + I find the templating system somewhat cleaner; code in py: xml namespace allows pure .html templates, instead of equivalent of .rhtml files. Ruby: + More mature system. More stable? More features? + Much better documented. This is a biggie. + Built-in Rubydoc system would make documenting the system easier. (IMHO, developers almost always underestimate the need for good documentation that is written along withe the system.) Is there a Python doc system that has received Guido's blessing yet? D'oxygen would seem an obvious choice. + Better coordination with Javascript helper code? I was initially leaning towards Rails due to maturity, but the most recent version of TurboGears seem to have fixed a lot of the ad hoc feeling I got from previous versions. But I'm still very much up in the air. Thanks, Ken P.S. If I wanted to provide an image by streaming the file data directly over the connection, rather than by referring to an image file, how would I do that? I'd like to build code that would allow images to be assembled into a single-file photo album (zip or bsddb file), and so can't refer to them as individual image files. -- http://mail.python.org/mailman/listinfo/python-list
Re: Pros/Cons of Turbogears/Rails?
[EMAIL PROTECTED] wrote: + Built-in Rubydoc system would make documenting the system easier. (IMHO, developers almost always underestimate the need for good documentation that is written along withe the system.) Is there a Python doc system that has received Guido's blessing yet? afaik, TurboGears has standardized on PythonDoc markup in docstrings: http://effbot.org/zone/pythondoc.htm P.S. If I wanted to provide an image by streaming the file data directly over the connection, rather than by referring to an image file, how would I do that? I'd like to build code that would allow images to be assembled into a single-file photo album (zip or bsddb file), and so can't refer to them as individual image files. some browsers support special data URL:s for images, but that doesn't work well for large images, and isn't portable. on the other hand, I don't really see why there has to be 1:1 mapping between URL:s and image files on your machine, especially if you're using a web application framework... /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Pros/Cons of Turbogears/Rails?
Fredrik Lundh wrote: [EMAIL PROTECTED] wrote: P.S. If I wanted to provide an image by streaming the file data directly over the connection, rather than by referring to an image file, how would I do that? I'd like to build code that would allow images to be assembled into a single-file photo album (zip or bsddb file), and so can't refer to them as individual image files. some browsers support special data URL:s for images, but that doesn't work well for large images, and isn't portable. on the other hand, I don't really see why there has to be 1:1 mapping between URL:s and image files on your machine, especially if you're using a web application framework... I think he's just asking how do you specify a mimetype and stream binary data from within the framework. IIANM in TurboGears all you have to do is return a file-like object from your page handler. -Jonathan -- http://mail.python.org/mailman/listinfo/python-list
Re: Pros/Cons of Turbogears/Rails?
[EMAIL PROTECTED] wrote: Looks like you mixing comparisons. Ruby: + More mature system. More stable? More features? uh, no, Python predates Ruby by a good bit Rails might be older than Turbogears but it still JUST went 1.0 officially. It can't be called mature' by any defintition. + Much better documented. This is a biggie. Rails has no documentation, period. The authors acknowledge this openly. + Built-in Rubydoc system would make documenting the system easier. (IMHO, developers almost always underestimate the need for good documentation that is written along withe the system.) Is there a Python doc system that has received Guido's blessing yet? D'oxygen would seem an obvious choice. Pydoc IS standard. This has been around for a long time. + Better coordination with Javascript helper code? Again, is this a Python vs Ruby or Turbogears vs Rails post, you seem highly confused on the distinctions between language vs framework. I was initially leaning towards Rails due to maturity, but the most recent version of TurboGears seem to have fixed a lot of the ad hoc feeling I got from previous versions. But I'm still very much up in the air. again, Ruby can't be considered 'mature' by any definition. Thanks, Ken P.S. If I wanted to provide an image by streaming the file data directly over the connection, rather than by referring to an image file, how would I do that? I'd like to build code that would allow images to be assembled into a single-file photo album (zip or bsddb file), and so can't refer to them as individual image files. ?? -- http://mail.python.org/mailman/listinfo/python-list
Re: Pros/Cons of Turbogears/Rails?
fuzzylollipop wrote: uh, no, Python predates Ruby by a good bit Rails might be older than Turbogears but it still JUST went 1.0 officially. It can't be called mature' by any defintition. But at least in most developers' perception, it is (not necessarily in the absolute sense, but perhaps relative to Django or Turbogears). Mind, it doesn't even need to be true, we're talking of perception here. Also, I'm not talking about only Python and/or Ruby developers here, I'm talking about developers in general, a huge bunch of which comes from Java/.NET background. I know many of them and a lot of them do know Rails. When you say Turbogears or Django, however, they go, what?. Sadly, there are more Java guys who know about Ruby than Python, despite the fact that Python predates Ruby by quite a few years... (this must be that Bruce Tate dude's fault! ) snip -- http://mail.python.org/mailman/listinfo/python-list
Re: Pros/Cons of Turbogears/Rails?
Ray wrote: fuzzylollipop wrote: uh, no, Python predates Ruby by a good bit Rails might be older than Turbogears but it still JUST went 1.0 officially. It can't be called mature' by any defintition. But at least in most developers' perception, it is (not necessarily in the absolute sense, but perhaps relative to Django or Turbogears). Mind, it doesn't even need to be true, we're talking of perception here. You might be. No one else in the thread is. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
