By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,333 Members | 1,843 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,333 IT Pros & Developers. It's quick & easy.

What do you want in a new web framework?

P: n/a
Hello Everyone,

Now, I'm working on a new web framework. I tried many test on the other
programming languages. Then i decided to use python on my web framework
project.

Now i want to listen all of you. What do you want in that web
framework(Easy use of Database, Easy use of XML, GUI Designer, etc...)?

I'm wating your answers. Thank you for all answers...!

King Regards,

Emrah Ayanoglu

Aug 20 '06 #1
Share this Question
Share on Google+
34 Replies


P: n/a
In <11**********************@p79g2000cwp.googlegroups .com>, emrahayanoglu
wrote:
Now, I'm working on a new web framework. I tried many test on the other
programming languages. Then i decided to use python on my web framework
project.

Now i want to listen all of you. What do you want in that web
framework(Easy use of Database, Easy use of XML, GUI Designer, etc...)?

I'm wating your answers. Thank you for all answers...!
Don't think that yet another Python web framework is really needed.

Ciao,
Marc 'BlackJack' Rintsch
Aug 20 '06 #2

P: n/a
Marc 'BlackJack' Rintsch wrote:
emrahayanoglu wrote:

Now i want to listen all of you. What do you want in that web
framework(Easy use of Database, Easy use of XML, GUI Designer, etc...)?

Don't think that yet another Python web framework is really needed.
Why not? I know that some people are probably basking in the glory of
supposedly having their favourite framework recently blessed by the
BDFL, whilst others lament the almost unfair rejection of their own
framework on possibly dubious grounds by the very same person (thus
seeing their "winner takes all" strategy backfire totally), but open
source and various other network-effect movements benefit from lots of
people trying different things (the "scratch your own itch"
observation) rather than everyone gathering together for one big
strategy meeting.

Certainly, I'd recommend against anyone starting out on such a project
without having at least looked at the state of the Web frameworks scene
[1] and Python Web programming in general [2] (a resource which I've
recently updated in order to remove a degree of incoherency introduced
over the years), but apart from some Zope-based tools, I haven't seen
much GUI-designer-friendly stuff in the Python frameworks scene, for
example, nor does XML (in its widest W3C sense) seem to be
well-integrated into most frameworks (4Suite and some other less hyped
frameworks aside).

So it's not just a case of picking one of the more popular
frameworks-du-jour, especially since many of them seem to have their
own wheel-reinvention tendencies despite protests to the contrary.

Paul

[1] http://wiki.python.org/moin/WebFrameworks
[2] http://wiki.python.org/moin/WebProgramming

Aug 21 '06 #3

P: n/a
Hello Everyone,

I've just read all of the answers. Most of yours said that there are
many web frameworks ,so it is nonsense to make a new web framework in
python.

Now I'm using and testing all of the frameworks in python also asp.net,
jsp and java servlet, perl web frameworks and ruby on rails. Some of
them have good positive points like that asp.net have gridviews to show
data records, ruby on rails have ajax support, etc...
The framework that i'll make, includes most of the positive points of
the other frameworks. Maybe, it's a mix of web frameworks. I want to
use dojo toolkit for javascript in my framework, and make a gui
designer like Visual Studio and Sun Creator, etc...

After that, may be you'll change your mind. And i want to listen your
advices. Please feel free to say everything to me about framework. I'm
waiting your answers.

Best Regards,

Emrah
Ankara/Turkey

Aug 21 '06 #4

P: n/a
Hello Emrah :)
I'd love to have a good framework with focus on static-content.
Something simple and useful like rest2web
(http://www.voidspace.org.uk/python/rest2web/) that could parse some of
the many templates available and output nice (X)HTML+CSS. Bundle a
simple GUI and you have something very interesting.

hardemr wrote:
Maybe, it's a mix of web frameworks. I want to
use dojo toolkit for javascript in my framework, and make a gui
designer like Visual Studio and Sun Creator, etc...
How about skipping the framework and focusing on dojo + GUI? Choose a
target (templating + framework, or a couple of targets), build a Visual
Studio for AJAX and you'll be a hero. Hack wxScintilla and build
something with good template highlighting and WYSIWYG-ish preview and
you'll be very famous. Build a great framework and yours will be one of
the many ;)

Wishing you good luck,
Daniel

Aug 21 '06 #5

P: n/a
hardemr wrote:
I've just read all of the answers. Most of yours said that there are
many web frameworks ,so it is nonsense to make a new web framework in
python.
Hardemr, I like Ajacksu's answer, with a twist. Please concnentrate on
writing a Visual Studio-like gui designer, and make it possible to add
your Visual Studio like gui designer to Django (and TurboGears, et al).
Leverage the hard work of others and the installed base; add your
functionality on top. Don't re-create the wheel, build your internal
combustion engine powered vehicle on top of the 4 wheels that already
exist! ;-))

Please...

Ron Stephens

Aug 21 '06 #6

P: n/a
Ur**********@gmail.com wrote:
hardemr wrote:
>I've just read all of the answers. Most of yours said that there are
many web frameworks ,so it is nonsense to make a new web framework in
python.

Hardemr, I like Ajacksu's answer, with a twist. Please concnentrate on
writing a Visual Studio-like gui designer, and make it possible to add
your Visual Studio like gui designer to Django (and TurboGears, et al).
it only make sense if you are disabled (visual or upper limb). most if
not all web frameworks are "no cripples need apply".

why? mixed caps, mixed modes (i.e. html+python), crappy editors to
start. these few items have such a *huge* impact that it can mean the
difference between being able to do the job or not. if you want to make
a diff, make an IDE that works for the blind and the mobility impaired.
the work has been started but it needs labor (see voicecoder project).
second place to make a difference is to build a bridge between windows
and gnome at-spi so one can speak (NaturallySpeaking on windows) then
have the effect show up on linux.

but in the context of web frameworks, my hp friendly framework shows how
easy it is to make apps HP friendly. the framework is rtg except for
packaging (and some docs). (I'm having problems trying to understand
and speak the setup file at the same time.)

If you want specific examples handicap barriers, I'll tell you after my
new mic arrives and my hands stop hurting so much. my cost: this
message means 30-40 min timeout for the nerves to cool off.

--- eric

Aug 21 '06 #7

P: n/a
"Paul Boddie" <pa**@boddie.org.ukwrote:
>Marc 'BlackJack' Rintsch wrote:
>emrahayanoglu wrote:
>
Now i want to listen all of you. What do you want in that web
framework(Easy use of Database, Easy use of XML, GUI Designer, etc...)?

Don't think that yet another Python web framework is really needed.

Why not? I know that some people are probably basking in the glory of
supposedly having their favourite framework recently blessed by the
BDFL, whilst others lament the almost unfair rejection of their own
framework on possibly dubious grounds by the very same person (thus
seeing their "winner takes all" strategy backfire totally), but open
source and various other network-effect movements benefit from lots of
people trying different things (the "scratch your own itch"
observation) rather than everyone gathering together for one big
strategy meeting.
Ordinarily, I think the "do it yourself" nature of Python is a great thing,
and I would never try to dissuade someone from reinventing something
themselves. However, in the case of web frameworks, I believe Marc is
fundamentally correct: the web framework proliferation in Python is
actually doing the language a huge disservice.

Consider Ruby. If someone asks, "I'd like to do a web site with Ruby, what
should I use?", the answer comes back loud, clear, and unanimous: Ruby on
Rails. If someone asks, "I'd like to do a web site with Python, what
should I use?", she gets 25 different answers. "Look at HTMLGen, Cheetah,
WebWare, CherryPy, Karrigell, Django, Pylons, Plone, Zope, TurboGears,
etc., etc.", none of which are pre-installed in the typical Linux
distribution. To the non-programming decision maker, that kind of response
makes Python look unprofessional -- a toy.

Now, please do not send me ugly emails accusing me of running down Python.
I've been a Python believer since 1.52. I've done web sites in at least 5
of the frameworks, and I even wrote one of the wiki pages that compares web
frameworks. However, it is only the fact that I *AM* a true Python
believer that gave me the patience and incentive to try 5 different
frameworks. If a corporate decision maker were involved, that would never
happen. Python would simply fall off of the list of options, and the job
would get done in PHP or Ruby on Rails.

I agree with Marc. PLEASE do not create "yet another Python web
framework." Let's pick one, and join together to turn it into the One,
True, Unquestioned Web Solution.
--
- Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.
Aug 22 '06 #8

P: n/a
Tim Roberts wrote:
>
Consider Ruby. If someone asks, "I'd like to do a web site with Ruby, what
should I use?", the answer comes back loud, clear, and unanimous: Ruby on
Rails.
I actually believe that people in most buzzword shortlist situations
see Rails as being the name in the list of candidates, not Ruby - it's
somewhat like Zope being in the list rather than Python, or
Struts/Tapestry/Apache-project-of-the-month being in the list rather
than Java (albeit with a fairly warm corporate feeling that Java is
there underneath).
If someone asks, "I'd like to do a web site with Python, what
should I use?", she gets 25 different answers. "Look at HTMLGen, Cheetah,
WebWare, CherryPy, Karrigell, Django, Pylons, Plone, Zope, TurboGears,
etc., etc.", none of which are pre-installed in the typical Linux
distribution. To the non-programming decision maker, that kind of response
makes Python look unprofessional -- a toy.
Indeed. That's why, after enumerating the uncontrollably expanding list
of solutions for a time [1], I wanted to concentrate on showing the
viable options with all their differentiating features in the Python
Web Frameworks Overview [2]. Ultimately, that content was moved to the
python.org Wiki [3] and everyone got their chance to hype their pet
project - it became like a random set of links. Sure, everyone wants
everyone else to see their work, but there's a role in the community
for objective education about the right tool for the job rather than
either graphically showing the little fish tear each other apart, or
jumping on the bandwagon with the most momentum and hyping it to the
exclusion of everything else. In the latter case, the end result is to
promote the big fish to the bigger pool (that stuff about Rails, Zope,
Struts & friends above), creating another generation of "agile
frameworks".

[...]
I agree with Marc. PLEASE do not create "yet another Python web
framework." Let's pick one, and join together to turn it into the One,
True, Unquestioned Web Solution.
Let's say we go for front-runner "du jour", Django. I've looked at
Django, and I'll admit that parts of the core API are fairly well done
when compared to certain other frameworks. However, let's say that we
want to "do it right" whilst expressing our dissatisfaction with the
templating, noting that when doing XML-oriented templating (that's
HTML, XHTML, XML and so on) I prefer something which upsets my Web page
editor less than it already is. So we unplug the templating somehow and
offer other options which plug into whatever magic that exists in
Django to make everything work smoothly. Let's say we unplug the
database abstraction layer because it doesn't do everything we want,
either, noting that I don't have any strong opinions about Django's
object-relational mapper, but I am wary of Web frameworks which
apparently encourage a database installation just for "hello world"
even if it isn't strictly required from a technical perspective.
Ultimately, we end up in a situation that is described far better in
the following article:

http://www.cmlenz.net/blog/2006/08/the_python_web_.html

In my opinion, what has damaged the Python Web frameworks scene has
been the continual hype and land-grabbing, the refusal to cede ground
on even the most basic stuff ("my magic form request variables are
better than yours", even though the majority of such magic solutions
are lacklustre at best), and that continual sighting of a grand prize
that at best gives you a ticket to Zopeworld - you get your own
"business ecosystem" while everyone else starts working on the next
thing to undo you.

I'd like to hear suggestions on how some cooperation can be encouraged
above the WSGI level, which despite the fanfare didn't really give so
many good answers to those confused users looking for a solution. As
I've said often enough before, the abstract "paper comparison" of Web
frameworks evolved into WebStack [4] which was originally an exercise
in seeing just how different many frameworks are at the lower levels:
the answer, given that you can paper over them in that way, is
"different only in unhelpful ways but not irreconcilably so". One day,
the Python Web frameworks scene may grow up and realise this fact.

Paul

[1]
http://web.archive.org/web/200410110...b_modules.html
[2] http://www.boddie.org.uk/python/web_frameworks.html
[3] http://wiki.python.org/moin/WebProgramming
[4] http://www.python.org/pypi/WebStack

Aug 22 '06 #9

P: n/a
Tim Roberts <ti**@probo.comwrote:
...
themselves. However, in the case of web frameworks, I believe Marc is
fundamentally correct: the web framework proliferation in Python is
actually doing the language a huge disservice.
Indeed, it has been truthfully observed that Python's the only language
with more web frameworks than keywords.

I have already suggested to the BDFL that he can remedy this situation
in Py3k: all he has to do, of course, is to add a LOT more keywords.
Alex
Aug 22 '06 #10

P: n/a
Alex Martelli wrote:
Indeed, it has been truthfully observed that Python's the only language
with more web frameworks than keywords.
recent research indicates that it has more web frameworks than comments
in the source code.

</F>

Aug 22 '06 #11

P: n/a
On Tue, 2006-08-22 at 08:15 +0000, Tim Roberts wrote:
Ordinarily, I think the "do it yourself" nature of Python is a great thing,
and I would never try to dissuade someone from reinventing something
themselves. However, in the case of web frameworks, I believe Marc is
fundamentally correct: the web framework proliferation in Python is
actually doing the language a huge disservice.
I disagree. Even if most of the frameworks end up being nothing more
than research artifacts, the fact is they embody research. Without
research the Python web framework space will be forever relegated to
runner-up (and probably has-been at some point).
Consider Ruby. If someone asks, "I'd like to do a web site with Ruby, what
should I use?", the answer comes back loud, clear, and unanimous: Ruby on
Rails.
Or Wee. Or Nitro. Or Nemo. Or others that are surely to be written as
Ruby gains acceptance and experienced users capable of writing them.
If someone asks, "I'd like to do a web site with Python, what
should I use?", she gets 25 different answers. "Look at HTMLGen, Cheetah,
WebWare, CherryPy, Karrigell, Django, Pylons, Plone, Zope, TurboGears,
etc., etc.", none of which are pre-installed in the typical Linux
distribution. To the non-programming decision maker, that kind of response
makes Python look unprofessional -- a toy.
Ruby on Rails doesn't come preinstalled either. I don't think it's
appropriate (and apparently most Linux distros currently agree) to
install web programming frameworks by default.

I will add that at least a few distros offer TurboGears, Django and
Pylons as add-ons.
Now, please do not send me ugly emails accusing me of running down Python.
I've been a Python believer since 1.52. I've done web sites in at least 5
of the frameworks, and I even wrote one of the wiki pages that compares web
frameworks. However, it is only the fact that I *AM* a true Python
believer that gave me the patience and incentive to try 5 different
frameworks. If a corporate decision maker were involved, that would never
happen. Python would simply fall off of the list of options, and the job
would get done in PHP or Ruby on Rails.
Yes, because PHP has only one web framework too ;-)
I agree with Marc. PLEASE do not create "yet another Python web
framework." Let's pick one, and join together to turn it into the One,
True, Unquestioned Web Solution.
Yes, and for those of us who may not like your choice, we can move to
another language or write our own, so nothing will have changed.

I think the entire concept that Ruby on Rails is successful because it
happens to be the dominant solution on what was previously a practically
unknown language is just plain ridiculous. If that's the case then why
hasn't Eiffel taken over the world? Or Lua? Or Io?

No, the reason Rails is successful is due to being a decent, focused
product with *great* marketing (screencasts, anyone?).

We've had several good Python web frameworks for some time, but
practically zero marketing (except for Zope/Plone, which as it turns
out, weren't such great products, at least not for the "80% solution"
that Rails targets).

Also the fact that Ruby doesn't suck isn't hurting Rails any either. If
GvR wants to improve Python's status against Ruby, I suggest looking at
what people are *really* raving about in the Ruby world (despite how
they got there) and address those issues rather than getting sidetracked
with this nonsense.
Regards,
Cliff
--

Aug 22 '06 #12

P: n/a
Ur**********@gmail.com writes:
hardemr wrote:
I've just read all of the answers. Most of yours said that there are
many web frameworks ,so it is nonsense to make a new web framework in
python.

Hardemr, I like Ajacksu's answer, with a twist. Please concnentrate on
writing a Visual Studio-like gui designer, and make it possible to add
your Visual Studio like gui designer to Django (and TurboGears, et al).
Leverage the hard work of others and the installed base; add your
functionality on top. Don't re-create the wheel, build your internal
combustion engine powered vehicle on top of the 4 wheels that already
exist! ;-))
pyjamas!

http://pyjamas.pyworks.org/
Now would be a fantastic time to muck in and do as UrsusMaximus
suggests -- nobody on the pyjamas project is yet talking about such
things, but it's obviously an area that could make you very popular if
done well ;-)
John
Aug 23 '06 #13

P: n/a
"Fredrik Lundh" <fr*****@pythonware.comwrote:

| Alex Martelli wrote:
|
| Indeed, it has been truthfully observed that Python's the only language
| with more web frameworks than keywords.
|
| recent research indicates that it has more web frameworks than comments
| in the source code.
|
| </F>

Aaaaargh!
Aug 23 '06 #14

P: n/a
"Alex Martelli" <al***@mac.com>
| Tim Roberts <ti**@probo.comwrote:
| ...
| themselves. However, in the case of web frameworks, I believe Marc is
| fundamentally correct: the web framework proliferation in Python is
| actually doing the language a huge disservice.
|
| Indeed, it has been truthfully observed that Python's the only language
| with more web frameworks than keywords.
|
| I have already suggested to the BDFL that he can remedy this situation
| in Py3k: all he has to do, of course, is to add a LOT more keywords.
|
|
| Alex

*groan*
Aug 23 '06 #15

P: n/a
Cliff Wells wrote:
>
I disagree. Even if most of the frameworks end up being nothing more
than research artifacts, the fact is they embody research. Without
research the Python web framework space will be forever relegated to
runner-up (and probably has-been at some point).
It's perhaps surprising that even in the areas of the software industry
that are focused on selling expertise by providing services, as opposed
to selling licences for some code, that the research aspect of
developing some software, along with the knowledge gained in the
exercise, is frequently ignored in favour of some mass of code that is
gradually approaching legacy status. Familiarity with the problem
domain is extremely useful, even if it produces no long-lasting product
such as a popular Web framework, and the mere knowledge gained in
producing something that perhaps no-one else wants to use can be
important in informing future decisions about adopting (rather than
developing) suitable frameworks, if nothing else.

[...]
Ruby on Rails doesn't come preinstalled either. I don't think it's
appropriate (and apparently most Linux distros currently agree) to
install web programming frameworks by default.
I think the comment about pre-installed frameworks either confused the
issue of availability with the default package selection in some
distros, or mistook some announcement/hype about Rails on Mac OS X as
being an indication of a wider trend.

[...]
No, the reason Rails is successful is due to being a decent, focused
product with *great* marketing (screencasts, anyone?).
Screencasts? Perhaps, like a great showman, they draw in the punters
effectively enough, but I'd rather developers concentrate on writing
decent documentation than stuffing the pipes of the Internet up with
multi-megabyte proprietary blobs showing some individual developing
"hello world" (and still having to practise slight-of-hand in order to
make it "slick" enough).

[...]
Also the fact that Ruby doesn't suck isn't hurting Rails any either. If
GvR wants to improve Python's status against Ruby, I suggest looking at
what people are *really* raving about in the Ruby world (despite how
they got there) and address those issues rather than getting sidetracked
with this nonsense.
First of all, I'd take the raving from the Ruby scene with a pinch of
salt, given the tendency of the blog personalities doing the raving to
breathlessly declare some kind of victory at every turn - as Steve
Holden once said, these people are good at the "don't mention the
weaknesses" style of marketing, and that's probably something various
Python Web framework developers have picked up quite effectively. I'd
rather the Python core developers stopped chasing shadows and looked at
the Python distribution in its entirety. Hopefully, the Python 3000
exercise will see its focus shift into really removing the artifacts of
legacy decisions in both the language and the library rather than
shoehorning more wishlist items into the language.

Paul

P.S. Wishlist shoehorning example: decorators plus annotations ("not
really for static typing, honest!") equals...

http://mail.python.org/pipermail/pyt...st/003034.html

It's possible that the example decorator in the above message
unintentionally communicates the cynical view of decorators, but the
spectre of multi-page "annotations" is still worth worrying about even
if you're a decorator fan. See other messages in that thread for some
of the ideas (and to bring forth that longing for simpler times).

Aug 23 '06 #16

P: n/a
Alex Martelli wrote:
Indeed, it has been truthfully observed that Python's the only language
with more web frameworks than keywords.

I have already suggested to the BDFL that he can remedy this situation
in Py3k: all he has to do, of course, is to add a LOT more keywords.
Here is another remedy: he adds one of the frameworks to the standard
library :)

Peter Maas, Aachen
Aug 23 '06 #17

P: n/a
On Wed, 2006-08-23 at 02:28 -0700, Paul Boddie wrote:
Cliff Wells wrote:
No, the reason Rails is successful is due to being a decent, focused
product with *great* marketing (screencasts, anyone?).

Screencasts? Perhaps, like a great showman, they draw in the punters
effectively enough, but I'd rather developers concentrate on writing
decent documentation than stuffing the pipes of the Internet up with
multi-megabyte proprietary blobs showing some individual developing
"hello world" (and still having to practise slight-of-hand in order to
make it "slick" enough).
Well, I think screencasts are pretty great for this type of thing.
Think about the primary complaint: "Which one do I choose?". It can
take a while to wade through the various documentation (or lack of),
install, do some basic tests, etc and the whole process can be pretty
wearing on a newcomer. A screencast on the other hand lets you lazily
sip coffee while you get a small feel for the framework. I think it
also shows what someone who *knows* the framework can do (which can be
nearly impossible to know when you're testing it yourself). The "20
minute wiki" screencast would be the "2 day trial and error" for someone
new to the framework.
>
[...]
Also the fact that Ruby doesn't suck isn't hurting Rails any either. If
GvR wants to improve Python's status against Ruby, I suggest looking at
what people are *really* raving about in the Ruby world (despite how
they got there) and address those issues rather than getting sidetracked
with this nonsense.

First of all, I'd take the raving from the Ruby scene with a pinch of
salt, given the tendency of the blog personalities doing the raving to
breathlessly declare some kind of victory at every turn - as Steve
Holden once said, these people are good at the "don't mention the
weaknesses" style of marketing, and that's probably something various
Python Web framework developers have picked up quite effectively.
Oh sure. And you have to also remind yourself that most of these guys
are coming from PHP where practically nothing sucks by comparison (and
there are *lots* of PHP people to convert).

But there are interesting things in Ruby (and Ruby 2 should take care of
lots of warts Ruby 1.8 has) that Python could learn from. All-in-all,
Ruby is mostly as good as Python in most ways and better than Python in
a couple key ways. Add marketing to that (whatever kind it happens to
be) and you've got the recipe for success.

When I suggest using Python to customers they tend to get nervous as if
it's some esoteric language that might disappear off the map next
weekend and is only known to 12 people. I shouldn't need to reassure
people that it is what it is: one of the most popular languages in use
today. That's the other kind of bad marketing that Python should avoid.
I'd rather the Python core developers stopped chasing shadows and looked at
the Python distribution in its entirety. Hopefully, the Python 3000
exercise will see its focus shift into really removing the artifacts of
legacy decisions in both the language and the library rather than
shoehorning more wishlist items into the language.
My single wishlist item (which will probably never happen) is actually
the *removal* of a single "feature": the distinction between statements
and expressions. Forget list comprehensions, ternary operators, etc.
You get them with no additional syntax in expression-based languages. I
played with Logix a bit (but sadly the project appears dead) and the
expression-based Python syntax it provides gives me goose-bumps.

At this point in my life, inertia keeps me with Python (it's "good
enough" and I lack the time and energy to convert to another language),
but there's little doubt in my mind that this distinction will
eventually force me elsewhere *wipes away tear*.
Regards,
Cliff

Aug 23 '06 #18

P: n/a
On Wed, 2006-08-23 at 22:13 +0200, Peter Maas wrote:
Alex Martelli wrote:
Indeed, it has been truthfully observed that Python's the only language
with more web frameworks than keywords.

I have already suggested to the BDFL that he can remedy this situation
in Py3k: all he has to do, of course, is to add a LOT more keywords.

Here is another remedy: he adds one of the frameworks to the standard
library :)
That didn't help Tk maintain a monopoly on Python GUI toolkits.

Cliff

--

Aug 23 '06 #19

P: n/a
Cliff Wells <cl***@develix.comwrote:
>
But there are interesting things in Ruby (and Ruby 2 should take care of
lots of warts Ruby 1.8 has) that Python could learn from. All-in-all,
Ruby is mostly as good as Python in most ways and better than Python in
a couple key ways.
....but you can't READ Ruby code. One of the things I like best about
Python is that, like Cobol, you can read Python code like prose (or poetry
;) and, for the most part, know what the code does, even without being a
Python guru. I have not had the same experience with Ruby. There are
special characters in there that make the program say something I can't
immediately discern.

To be sure, people whose opinions I trust (one of whom is Cliff Wells) have
said that Ruby is great, so I suppose I need to look again. I just haven't
had the same "aha!" experience that I had with Python.
--
- Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.
Aug 24 '06 #20

P: n/a
On Thu, 2006-08-24 at 04:04 +0000, Tim Roberts wrote:
Cliff Wells <cl***@develix.comwrote:

But there are interesting things in Ruby (and Ruby 2 should take care of
lots of warts Ruby 1.8 has) that Python could learn from. All-in-all,
Ruby is mostly as good as Python in most ways and better than Python in
a couple key ways.

...but you can't READ Ruby code.
Yeah, that's one of the big reasons I haven't seriously considered
trying it. It's expressive, got interesting features... and appears
unreadable to me. I'm usually pretty good at deciphering most
languages, even if I haven't used them before, but Ruby is one of the
exceptions.
One of the things I like best about
Python is that, like Cobol, you can read Python code like prose (or poetry
;) and, for the most part, know what the code does, even without being a
Python guru. I have not had the same experience with Ruby. There are
special characters in there that make the program say something I can't
immediately discern.
There's the line noise aspect, but also some things are just expressed
in what appears (to me) to be rather non-idiomatic ways. But I suppose
it depends on your background. A rather brilliant friend of mine with a
Smalltalk background thinks that the Ruby reads like a novel. Shrug. He
also reads Japanese, so maybe that's a factor ;-)
To be sure, people whose opinions I trust (one of whom is Cliff Wells) have
said that Ruby is great, so I suppose I need to look again. I just haven't
had the same "aha!" experience that I had with Python.
Thanks for the vote of confidence. I have lots of opinions, but even I
only trust a few of them ;-)

I think Ruby has great things and I'm certain it's a great fit for many
people. But I'm with you 100% on Python's readability. I just wish we
could have the great things from both.

This brings us back around to the web framework debates. For many
people Ruby "fits" their brains and for others Python does. I think
frameworks are similar. I tried Django and while I thought it was a
great product, it simply didn't "fit" how I think about that problem
domain. TurboGears on the other hand did, and really, it helped clarify
a few things I had vague notions about. I think we'll do better not
trying to shoehorn people into one or the other.

Regards,
Cliff
--

Aug 24 '06 #21

P: n/a
Cliff Wells wrote:
On Thu, 2006-08-24 at 04:04 +0000, Tim Roberts wrote:
Cliff Wells <cl***@develix.comwrote:
>
>But there are interesting things in Ruby (and Ruby 2 should take care of
>lots of warts Ruby 1.8 has) that Python could learn from. All-in-all,
>Ruby is mostly as good as Python in most ways and better than Python in
>a couple key ways.
The big difference between Ruby and Python is the lifecycle phase that
the languages/systems are in: Ruby arguably has room for a lot of basic
improvements in the architecture of the virtual machine and presumably
has a list of "must add" features that cover gaping holes with respect
to certain audiences [1], whereas Python has been around for ages and
has covered most of the critical gaps in the feature list (although we
can always suggest things which bother our own part of the community).
Whereas the Ruby people merely have to agree on how critical their
missing features are and to move in one widely agreed direction, the
Python people face a tougher choice as to what should be done next;
strategies include a tidying-up exercise to make the language more
coherent, a complete reimplementation, deep modifications to the
runtime, the introduction of radical new semantics.

The fewer obvious issues that a language has, the less energy there is
in the community to deal with those issues thoroughly, I think. I guess
the Perl community chose a bold new direction in line with the
observation that a big vision can inspire much more in people than lots
of incremental changes to an existing vision, but the energy required
to follow through on such a vision can be immense. In addition to all
this, a large existing community is more likely to want larger benefits
for smaller levels of disruption because of the amount of existing
code. Thus, the available energy for change is less in a mature project
than in a growing project because people have to constantly monitor the
breakage in their existing investments in the language.
...but you can't READ Ruby code.

Yeah, that's one of the big reasons I haven't seriously considered
trying it. It's expressive, got interesting features... and appears
unreadable to me. I'm usually pretty good at deciphering most
languages, even if I haven't used them before, but Ruby is one of the
exceptions.
My feeling is that I'd rather learn more about Lisp or Scheme than Ruby
- the benefits are greater and for me Lisp and Scheme increasingly have
the edge on readability. Perhaps I'm just not "tuned in" to
Smalltalk-style syntaxes.
This brings us back around to the web framework debates. For many
people Ruby "fits" their brains and for others Python does. I think
frameworks are similar. I tried Django and while I thought it was a
great product, it simply didn't "fit" how I think about that problem
domain.
I thought that the most interesting thing about Django was the URL
mapping strategy it employs, although you have to be fond of regular
expressions to really appreciate it, I think. The template and
persistence mechanisms used have the principal advantage of just being
there in the same package when compared with other solutions, and I
don't think they'd have many fans if they were just some random
projects available from the Python Package Index.
TurboGears on the other hand did, and really, it helped clarify
a few things I had vague notions about. I think we'll do better not
trying to shoehorn people into one or the other.
The goal is to provide appropriate solutions for particular problem
cases, especially common cases like database-backed Web sites, rather
than choosing something which only does a particular flavour of
database-backed site and then claiming that it's a silver bullet. I've
written a number of Web applications for my own use, and many such
applications either don't use a relational database or use it in a way
that is completely orthogonal to some relatively simple
object-relational scheme. Some of these applications are admittedly
simple, but having to create various tables in relational databases as
an offering to some framework deity is pure unnecessary overhead that
should suggest, at least to the more objective among us, that any
solution requiring such baggage is perhaps not always the most optimal.

Paul

[1]
http://headius.blogspot.com/2006/06/...-in-jruby.html

Aug 24 '06 #22

P: n/a
On Thu, 2006-08-24 at 04:28 -0700, Paul Boddie wrote:
Cliff Wells wrote:
On Thu, 2006-08-24 at 04:04 +0000, Tim Roberts wrote:
Cliff Wells <cl***@develix.comwrote:

But there are interesting things in Ruby (and Ruby 2 should take care of
lots of warts Ruby 1.8 has) that Python could learn from. All-in-all,
Ruby is mostly as good as Python in most ways and better than Python in
a couple key ways.

The big difference between Ruby and Python is the lifecycle phase that
the languages/systems are in: Ruby arguably has room for a lot of basic
improvements in the architecture of the virtual machine and presumably
has a list of "must add" features that cover gaping holes with respect
to certain audiences [1], whereas Python has been around for ages and
has covered most of the critical gaps in the feature list (although we
can always suggest things which bother our own part of the community).
Whereas the Ruby people merely have to agree on how critical their
missing features are and to move in one widely agreed direction, the
Python people face a tougher choice as to what should be done next;
strategies include a tidying-up exercise to make the language more
coherent, a complete reimplementation, deep modifications to the
runtime, the introduction of radical new semantics.
All true, but there's a more fundamental difference that's going to show
more as a larger number of people become used to Ruby's semantics: any
Ruby statement can be used as an expression. This is firmly from the
Lisp family of languages whereas Python's statement-based syntax is
firmly in the Fortran branch. With the exception of Lisp itself, no
language has seen the popularity of this style of programming until
Ruby. I think this represents a real danger to Python's mindshare.
Once people have tried expression-based languages, they tend to be
loathe to return to statement-based languages. To date,
expression-based languages have been mostly of interest in academia or
to a small group of elitists and so weren't practical to use for
day-to-day work. Ruby has changed that and I think we're just starting
to see the fallout. Rails may have brought them there, but Ruby itself
is keeping them there. My fear is that the expression-based family of
languages is the Homo Sapiens to our statement-based Neanderthals and we
can either evolve or disappear. Python is unique in many ways and I'd
hate to see those unique features lost because we're stuck on the wrong
evolutionary branch.
The fewer obvious issues that a language has, the less energy there is
in the community to deal with those issues thoroughly, I think. I guess
the Perl community chose a bold new direction in line with the
observation that a big vision can inspire much more in people than lots
of incremental changes to an existing vision, but the energy required
to follow through on such a vision can be immense. In addition to all
this, a large existing community is more likely to want larger benefits
for smaller levels of disruption because of the amount of existing
code. Thus, the available energy for change is less in a mature project
than in a growing project because people have to constantly monitor the
breakage in their existing investments in the language.
...but you can't READ Ruby code.
Yeah, that's one of the big reasons I haven't seriously considered
trying it. It's expressive, got interesting features... and appears
unreadable to me. I'm usually pretty good at deciphering most
languages, even if I haven't used them before, but Ruby is one of the
exceptions.

My feeling is that I'd rather learn more about Lisp or Scheme than Ruby
- the benefits are greater and for me Lisp and Scheme increasingly have
the edge on readability. Perhaps I'm just not "tuned in" to
Smalltalk-style syntaxes.
I'm in the same camp. As I mentioned earlier, it's been mostly inertia
and the wealth of the Python community that's kept me with Python.
That's why I was so excited when I found Logix. Lisp-like features with
Python's syntax that generates Python bytecode. Actually Logix is
perhaps too far the other direction as it supports Lisp-style macros and
the creation of arbitrary syntax, which perhaps would justify some of
the fears people have of Lisp-like languages.
The part I found appealing was having Python-like syntax in an
expression-based language, with the capability to integrate completely
with Python libraries. Absolutely the best of both worlds. I've been
trying to contact the author of Logix to find out what the status of the
project is or if he's abandoned it. If you haven't looked at it you
really ought to.

http://livelogix.net/logix/

This brings us back around to the web framework debates. For many
people Ruby "fits" their brains and for others Python does. I think
frameworks are similar. I tried Django and while I thought it was a
great product, it simply didn't "fit" how I think about that problem
domain.

I thought that the most interesting thing about Django was the URL
mapping strategy it employs, although you have to be fond of regular
expressions to really appreciate it, I think.
Django's dispatch mechanism is flexible, but what I disliked about it
was the extra steps required upfront just to get a single page online.
I prefered CherryPy's object-publishing scheme for its sheer simplicity.
I think that simple mechanism, coupled with Routes for more complicated
stuff is the sweet spot in this area.
The template and
persistence mechanisms used have the principal advantage of just being
there in the same package when compared with other solutions, and I
don't think they'd have many fans if they were just some random
projects available from the Python Package Index.
Perhaps, but I find the ORM and templates from Django inferior to other
projects, namely SQLAlchemy and Stan. These two aspects of frameworks
seem to be the ones that generate the most passionate debate, probably
because they touch the spot the framework user spends most of his time
working in. The bottom line is that if you don't like the ORM or the
template engine, you probably won't like the framework, even though they
are logically separate entities.

Also, I think TurboGears has demonstrated that it's quite possible to
paste together a lot of subprojects into a single uberproject and have
it succeed. Not only has TurboGears succeeded, it's increased interest
in the various subprojects that it's composed of.

One project I'm keeping my eye on is Clever Harold which is taking the
most loosely-coupled approach to date, using WSGI to paste together all
the layers so you could conceivably replace every component in the
framework. I haven't tried it yet, but it sounds interesting.

http://www.cleverharold.org/
TurboGears on the other hand did, and really, it helped clarify
a few things I had vague notions about. I think we'll do better not
trying to shoehorn people into one or the other.

The goal is to provide appropriate solutions for particular problem
cases, especially common cases like database-backed Web sites, rather
than choosing something which only does a particular flavour of
database-backed site and then claiming that it's a silver bullet.
I've written a number of Web applications for my own use, and many such
applications either don't use a relational database or use it in a way
that is completely orthogonal to some relatively simple
object-relational scheme. Some of these applications are admittedly
simple, but having to create various tables in relational databases as
an offering to some framework deity is pure unnecessary overhead that
should suggest, at least to the more objective among us, that any
solution requiring such baggage is perhaps not always the most optimal.
I don't think any of the frameworks really require a database. There
was some discussion of this exact topic on the TurboGears list a while
back, but I don't recall the outcome, but yes, I think there's a place
for all sorts of web frameworks, ranging from simple to Zope ;-)
Regards,
Cliff
--

Aug 24 '06 #23

P: n/a

Peter Maas wrote:
Alex Martelli wrote:
Indeed, it has been truthfully observed that Python's the only language
with more web frameworks than keywords.

I have already suggested to the BDFL that he can remedy this situation
in Py3k: all he has to do, of course, is to add a LOT more keywords.

Here is another remedy: he adds one of the frameworks to the standard
library :)

Peter Maas, Aachen
But there are already 3 ;-)

http://docs.python.org/lib/module-BaseHTTPServer.html
http://docs.python.org/lib/module-SimpleHTTPServer.html
http://docs.python.org/lib/module-CGIHTTPServer.html

To answer the original poster, I personally like the ASP.NET model of
Controls (I'm sure some people will disagree) that do things like
automatically render, automatically marshall/unmarhall form data and
bind to variables, and respond to events. I always think it's a little
stupid when I try to use a framework, and I still need to manually
extract info from post data, and I still need to manually construct
simple things like <input text /boxes. That is probably an
interesting area to explore.

I haven't looked at python web frameworks in a while, so if there are
any existing frameworks out there that do things with a similar model,
someone please let me know.

-Grant

Aug 24 '06 #24

P: n/a
Cliff Wells wrote:
On Wed, 2006-08-23 at 22:13 +0200, Peter Maas wrote:
>Alex Martelli wrote:
[...]
>>I have already suggested to the BDFL that he can remedy this situation
in Py3k: all he has to do, of course, is to add a LOT more keywords.
Here is another remedy: he adds one of the frameworks to the standard
library :)

That didn't help Tk maintain a monopoly on Python GUI toolkits.
I must not be a monopoly. A center of gravity would be nice, too.

Peter Maas, Aachen
Aug 29 '06 #25

P: n/a
ol*****@verizon.net wrote:
>Here is another remedy: he adds one of the frameworks to the standard
library :)

Peter Maas, Aachen

But there are already 3 ;-)

http://docs.python.org/lib/module-BaseHTTPServer.html
http://docs.python.org/lib/module-SimpleHTTPServer.html
http://docs.python.org/lib/module-CGIHTTPServer.html
These aren't web frameworks, just HTTP servers.

Peter Maas, Aachen
Aug 29 '06 #26

P: n/a
Peter Maas <pe********@somewhere.comwrote:
Cliff Wells wrote:
On Wed, 2006-08-23 at 22:13 +0200, Peter Maas wrote:
Alex Martelli wrote:
[...]
>I have already suggested to the BDFL that he can remedy this situation
in Py3k: all he has to do, of course, is to add a LOT more keywords.
Here is another remedy: he adds one of the frameworks to the standard
library :)
That didn't help Tk maintain a monopoly on Python GUI toolkits.

I must not be a monopoly. A center of gravity would be nice, too.
<http://www.youtube.com/watch?v=hFGz-t5R0BE?....

[it helps to know some Italian, but it's not necessarily a must...
Francesco Battiato's amply demonstrated his music and lyrics can
fascinate non-speakers of Italian, too;-)]
Alex
Aug 30 '06 #27

P: n/a
Alex Martelli wrote:
[...]
>
<http://www.youtube.com/watch?v=hFGz-t5R0BE?....
[...]

youtube says:

The url contained a malformed video id.

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

Aug 30 '06 #28

P: n/a
I have already suggested to the BDFL that he can remedy this situation
in Py3k: all he has to do, of course, is to add a LOT more keywords.
Here is another remedy: he adds one of the frameworks to the standard
library :)

That didn't help Tk maintain a monopoly on Python GUI toolkits.
In fact, it almost seems like it is the opposite. There exist better
third party modules and packages of most functionality in the standard
library. The only examples I can think of that seem to have a
"monopoly" is subprocess, decimal, thread and pickle. Are there any
more? Maybe when ElementTree joins the stdlib it will also have a
monopoly on DOM parsers.

--
mvh Björn
Aug 30 '06 #29

P: n/a
"BJörn Lindqvist" <bj*****@gmail.comwrites:
In fact, it almost seems like[...] There exist better third party
modules and packages of most functionality in the standard
library. The only examples I can think of that seem to have a
"monopoly" is subprocess, decimal, thread and pickle. Are there any
more? Maybe when ElementTree joins the stdlib it will also have a
monopoly on DOM parsers.
I'm not sure what criteria should be used for "monopoly" in that
context.

For me, standard library modules that do their one thing well enough
that I don't consider looking elsewhere:

re
struct
unicodedata
decimal
random
logging
Queue
urlparse
email

A shorter list than I expected, now that I come to make it.

--
\ "Time is the great legalizer, even in the field of morals." -- |
`\ Henry L. Mencken |
_o__) |
Ben Finney

Aug 30 '06 #30

P: n/a
Cliff Wells wrote:
My single wishlist item (which will probably never happen) is actually
the *removal* of a single "feature": the distinction between statements
and expressions. Forget list comprehensions, ternary operators, etc.
You get them with no additional syntax in expression-based languages. I
played with Logix a bit (but sadly the project appears dead) and the
expression-based Python syntax it provides gives me goose-bumps.
Ironically I would prefer to turn Logix block expressions of the kind

var = expression:
SUITE

into statements to avoid deep and awkward nestings: passing the
side-effect created by SUITE to var but preserving the distinction
between expressions and block statements nevertheless. I'm not yet sure
if the Python 2.5 with-stmt cannot be used for exactly this purpose?

Note that I'm not completely against blurring the distinction between
expressions and statements in Python. The Python grammar itself
contains a basic distinction between statements namely simple_stmt and
compound_stmt nodes.

Simple statements are defined by:

simple_stmt: small_stmt ( ";" small_stmt)* [";"] NEWLINE

where small_stmt nodes are nodes for assert, print, raise, return,
assignment etc.

It took me an evening using EasyExtend to define an enhanced lambda
that enables expressions like:

lambda lst: s = sum(lst); return float(s)/len(lst)

or

lambda x: print x; x+1

which are other Logix examples.

Aug 30 '06 #31

P: n/a
2006/8/30, Ben Finney <bi****************@benfinney.id.au>:
re
struct
unicodedata
decimal
random
logging
Queue
urlparse
email
operator
cStringIO
math
cmath
sets (merged to the language)
itertools
os + stat
time
tempfile
glob

Not that I use them all the time, but they are really useful and
usually fulfill my needs.

--
Felipe.
Aug 30 '06 #32

P: n/a
Steve Holden <st***@holdenweb.comwrote:
<http://www.youtube.com/watch?v=hFGz-t5R0BE?>
Oops, <http://www.youtube.com/watch?v=hFGz-t5R0BE-- not sure how the
stray trailing questionmark got in, sorry.
Alex
Aug 30 '06 #33

P: n/a
Alex Martelli wrote:
Peter Maas <pe********@somewhere.comwrote:
>Cliff Wells wrote:
>>On Wed, 2006-08-23 at 22:13 +0200, Peter Maas wrote:
Alex Martelli wrote:
[...]
>>>>I have already suggested to the BDFL that he can remedy this situation
in Py3k: all he has to do, of course, is to add a LOT more keywords.
Here is another remedy: he adds one of the frameworks to the standard
library :)
That didn't help Tk maintain a monopoly on Python GUI toolkits.
I must not be a monopoly. A center of gravity would be nice, too.

<http://www.youtube.com/watch?v=hFGz-t5R0BE?....

[it helps to know some Italian,
No problem: "Centro di Gravità Permanente" = "permanent center of gravity" :)

Peter Maas, Aachen
Sep 2 '06 #34

P: n/a
Peter Maas <pe********@somewhere.comwrote:
...
I must not be a monopoly. A center of gravity would be nice, too.
<http://www.youtube.com/watch?v=hFGz-t5R0BE?....

[it helps to know some Italian,

No problem: "Centro di Gravità Permanente" = "permanent center of gravity" :)
Yep, but the lyrics around that title are worthwhile too;-).
Alex

Sep 2 '06 #35

This discussion thread is closed

Replies have been disabled for this discussion.