Need a compelling argument to use Django instead of Rails

[Ray]

I just moved to another company that's mainly a Java/.NET shop. I was
happy to find out that there's a movement from the grassroot to try to
convince the boss to use a dynamic language for our development!

Two of the senior developers, however, are already rooting for Ruby on
Rails--although they haven't tried RoR themselves. When I suggested
Django, they went like, "what's that?".

I said, "It's like the Python counterpart of RoR".

"Nah, we're not interested in Python."

I think they are already predisposed to RoR simply because of RoR's
visibility (i.e.: at my workplace everybody knows RoR but nobody knows
about Django unless they've used Python as well). So far the arguments
I can think of:

1. The investment of learning Python will be a good investment because
it transfer to platforms that we've already supported, i.e.: JVM and
..NET CLR (using Jython and IronPython). Ruby's availability on this
platform is not as mature--JRuby is still at 0.9 and I don't think
IronRuby is coming out anytime soon :)

2. Python is a much more mature language than Ruby--it's been around
since ages ago and as such has a lot more tools, articles, and other
resources than Ruby. It is also the language being used by
high-visibility company like Google, with the creator of the language
himself working there.

3. Python emphasizes readability instead of cleverness/conciseness.

4. What else? I haven't tried RoR so I can't argue meaningfully on
whether using Django will put us at an advantage.

Can you help me with my argument? Meanwhile I think I'll give RoR a try
as well.

Thank you,
Ray

[Ray]

Jaroslaw Zabiello wrote:

Ruby
has nice security system (private, protected, public scopes for methods and
attributes,

This is not "security", this is data-hiding.

No. Data hiding are in Python. Ruby uses security similiar to Java. If the
class has method marked as private it cannot be used in children classes.

Why are you calling this "security"? The enforcement of "private" is
not "security" in Java by a long shot. Trust me I know, been doing Java
since near its inception. By your definition of "security" C++ has
"security" too. But no, Java (real) security is very different from C++
and Ruby enforcement of private. It's a much bigger subject in its own
right.

[Bruno Desthuilliers]

Jaroslaw Zabiello wrote:

On Wed, 26 Jul 2006 18:20:44 +0200, Bruno Desthuilliers wrote:

>>May I suggest that you learn some Lisp dialect ?

Nope. I hate Lisp syntax.

This should not prevent you from learning it - at least, you'd then
avoid making dumb statements...

>

>>>Of course, I you like, you can freeze every object you want and nobody can
be able to open and change it. You can also trace all activity for changing
something to objects because Ruby has nice system hooks implemented.

__getattribute__ / __setattr__ / __delattr__

This is not the same. Ruby can also lock access to attributes.

Please re-read the doc for these methods.

Freezing is
different. It can freeze any object so you will not be able to add or
delete any method. Once freezed object cannot be unfrozen. So you can be
sure that nobody will change you classes if you do not like.

>>And of course import hooks.

Python?? Where?

RTFM:
http://www.python.org/doc/2.3.5/lib/built-in-funcs.html

What about learning Python instead of repeating arguments from clueless
people ?

>

>>>Ruby
has nice security system (private, protected, public scopes for methods and
attributes,

This is not "security", this is data-hiding.

No. Data hiding are in Python.

Oh, yes ? Where, exactly ?

Ruby uses security similiar to Java. If the
class has method marked as private it cannot be used in children classes.

Python methods are attributes, so from a Python POV, this is still
data-hiding. But granted, I should have used "language-inforced access
restriction" instead. So let me rephrase:

This is not "security", this is language-inforced access restriction.

>>And IIRC, Ruby's attributes are always private

Yes and no. Yes, because you cannot read them directly without accessors.
And no, because you can read them if you set proper accessor.

Adding accessors doesn't make the attributes public.

>

>>>In past Python had Bastion module (http://www.python.org/doc/lib/module-Bastion.html)
but it was rejected and now Python has nothing.

Seems like Zope is not doing so bad...

Zope is only a great application.

Zope is a framework and an application server.

Invision Power Board or ezPublish are
also great application, but it does not mean that PHP is great language. :)

You can't say that Python is dumb when it comes to security and reject
an example of a Python framework that address the problem.

Python has no security at all. I has only convention and mangling.

Please define "security". I fail to see how language-inforced access
restriction (and mandatory declarative static typing etc) relates to
'security'. As far as I'm concerned, security is about protecting a
system from piracy, not about inflicting useless pain to programmers.

Of
course somebode can say, it is enough, and maybe it is. But I think, that
this might be another reason why Java guys prefer Ruby to Python.

Agreed - but this all boil down to Ruby having a more canonical object
model than Python.

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"

[Bruno Desthuilliers]

Jaroslaw Zabiello wrote:

On Wed, 26 Jul 2006 18:23:22 +0200, Bruno Desthuilliers wrote:

>>>>Care to write an external DSL in Ruby ?

?

I mean : write a parser and interpreter for a DSL. In Ruby.

I see. Nope. I do not like code generators.

I'm not talking about "code generators", I'm talking about implementing
a language with another language.

In this sense every template
system is DSL.

Indeed.

E.g. Smarty Templates for PHP. You can create "external DSL"
even in C or assembler.

Indeed.

This is not the point. The point is Ruby is much
better suited to create internal DSL than Python

Care to back your claim ? Or are you just parroting what you read from
some clueless guy more concerned with hype and buzz than with reality ?

or PHP.

Please compare what is comparable.

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"

[Kay Schluehr]

Jaroslaw Zabiello wrote:

Of course, I you like, you can freeze every object you want and nobody can
be able to open and change it. You can also trace all activity for changing
something to objects because Ruby has nice system hooks implemented. Ruby
has nice security system (private, protected, public scopes for methods and
attributes, objects freezing, system hooks).

Sounds good. I guess unlike Java you can't inspect and modify all those
data using reflection in Ruby?

[Kay Schluehr]

Bruno Desthuilliers wrote:

>Care to write an external DSL in Ruby ?

I mean : write a parser and interpreter for a DSL. In Ruby.

It is this kind of stuff Rubys talk about when they mention "DSLs in
Ruby":

http://www.artima.com/rubycs/articles/ruby_as_dsl.html

[Bruno Desthuilliers]

Kay Schluehr wrote:

Bruno Desthuilliers wrote:

>>>>Care to write an external DSL in Ruby ?

I mean : write a parser and interpreter for a DSL. In Ruby.

It is this kind of stuff Rubys talk about when they mention "DSLs in
Ruby":

http://www.artima.com/rubycs/articles/ruby_as_dsl.html

yes, I know - embedded DSLs.

FWIW, after a *quick* glance at this article, I haven't seen anything
that seemed undoable nor even difficult to do in Python - it all boils
down to reading an ini-like file and creating a stub source-tree from it.

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"

[gregarican]

Bruno Desthuilliers wrote:

Please define "security". I fail to see how language-inforced access
restriction (and mandatory declarative static typing etc) relates to
'security'. As far as I'm concerned, security is about protecting a
system from piracy, not about inflicting useless pain to programmers.

I must agree here. When I am coding I appreciate ease of referencing
things above and beyond a language tying my hands behind my back
supposedly in the name of security. If I am savvy enough and know what
I am doing I can create classes, methods, etc. that implement an
effective security model in terms of encapsulation and hiding. But
there are times that I am creating something that I don't want boxed in
by the language enforcing all of this for me. It's like when people
dismiss PHP as a supposedly insecure language. It's more a problem of
too many newly initiated PHP developers not using techniques they
should be to create secure applications.

[Roman Susi]

Ben Sizer wrote:

Ray wrote:

>>Just that it's a big, huge, humongous pity to see Python keeps missing
the big thing over and over again. Last time when biotechnology was
hot, which language became The Language? Perl. Now simple web app is
hot? It's Ruby.

The problem is that Python is the 2nd best language for everything. ;)
As a general purpose language I don't think it can be beaten, but for
almost any given project of non-trivial size, there seems to always be
one language that has better support for the subject. I frequently find
myself wanting to use Python but being unable to, often due to some
library being unavailable, as in your case.

Is it a bad thing? In my opinion it is better to be 2nd place for a long
time than get to the top and fall short after that. Because then Python
will be associated with certain thing (like Ruby with Rails, Java with
Beans, C with two pluses, Fortran with 77 ;-)

Its healthy for a Pythons to live in many different ecosystems.

Regards,
Roman

[Ben Sizer]

Roman Susi wrote:

Ben Sizer wrote:

The problem is that Python is the 2nd best language for everything. ;)

Is it a bad thing?

I don't know. I suppose that depends on how you define 'bad'! For me,
it is often inconvenient, because I'd prefer to use Python but
generally find that I have to choose something else if I want to do the
best possible for any particular project.

In my case, multimedia and game support is patchy, and web development
support is still oriented towards the Java/enterprise user - if CGI
doesn't suffice, that is. In the original poster's case, it's seemingly
because specific database support seems to be lacking. Improving the
libraries in these areas would hopefully increase the diversity of
Python's potential applications rather than diminish it.

--
Ben Sizer

[Paul Boddie]

Ben Sizer wrote:

>
In my case, multimedia and game support is patchy,

There are lots of multimedia and game frameworks for Python. Which ones
have you tried and why are they insufficient?

and web development support is still oriented towards the Java/enterprise user - if CGI
doesn't suffice, that is.

Certainly, some Web frameworks have some element of Java flavouring,
but there's also considerable diversity at least at certain levels.

In the original poster's case, it's seemingly because specific database support seems to
be lacking. Improving the libraries in these areas would hopefully increase the diversity
of Python's potential applications rather than diminish it.

Last time I checked, which was admittedly a long time after I actually
needed the modules concerned, support for Oracle with Python was
actually pretty good. I suppose it's a case of the Django people
getting round to gluing the Oracle modules to their object-relational
mapper and making sure that it all still works, and perhaps some
motivated member of the Django community can step forward and do the
work to get it going. Otherwise, no amount of complaining will put the
two technologies together.

Paul

[Ben Sizer]

Paul Boddie wrote:

Ben Sizer wrote:

In my case, multimedia and game support is patchy,

There are lots of multimedia and game frameworks for Python. Which ones
have you tried and why are they insufficient?

PyGame was barely maintained for a year, and is based on SDL which was
also barely maintained for a year, and which hasn't kept up with
hardware advances at all. On the graphical side you can opt for OpenGL,
the Python library for which is also barely maintained (though I hear
work is underway behind the scenes) and doesn't provide much more than
a minimal layer over the C interface anyway. DirectX support only
appeared this year unless you used IronPython, and it doesn't seem very
popular.

Which other frameworks are you thinking of? I know of a variety of
wrappers around individual libraries, and of wrappers around 3D engines
such as Irrlicht and Ogre, but not much else.

Certainly, some Web frameworks have some element of Java flavouring,
but there's also considerable diversity at least at certain levels.

Pretty much every Python web offering revolves around you having your
own server with the luxury of running your own long-running processes
on it. Great for business apps, not much use for the hobbyist or
independent site. There are probably some hosts that will provide
shared hosting for your Django or Turbogears app, but they are not
exactly numerous. The barrier to entry here is much higher than with
PHP or ASP, for example. And even with the full framework approach, the
field has been so fragmented until recently that in terms of community
support, you'd be better off opting for another language. I appreciate
there's a diversity vs. standardisation argument there which may never
be settled, so I accept this is just a personal opinion, but I do think
a critical mass of users is important with any technology.

I'm in a similar situation to the original poster; I'd like to use
Turbogears for an app I want to write, but will probably end up doing
it in PHP instead, because I can't get dedicated hardware or a local
host for Turbogears. (Never mind the lack of documentation.)

Otherwise, no amount of complaining will put the
two technologies together.

It's a fair point, but on the other hand, saying "if you want it doing,
do it yourself" doesn't objectively improve the status quo. If
something doesn't exist, it doesn't exist, and it's valid to comment
upon that fact.

--
Ben Sizer

[Ray]

Ben Sizer wrote:

Roman Susi wrote:

Ben Sizer wrote:

The problem is that Python is the 2nd best language for everything. ;)

Is it a bad thing?

I don't know. I suppose that depends on how you define 'bad'! For me,
it is often inconvenient, because I'd prefer to use Python but
generally find that I have to choose something else if I want to do the
best possible for any particular project.

Exactly. It's bad because Python is the language you'd love to use at
work but can't :) Don't tell me to look for a job in a Python shop,
there's none. OTOH, there IS at least one RoR shop that I know of and
they're doing pretty well!

In my case, multimedia and game support is patchy, and web development
support is still oriented towards the Java/enterprise user - if CGI
doesn't suffice, that is. In the original poster's case, it's seemingly
because specific database support seems to be lacking. Improving the
libraries in these areas would hopefully increase the diversity of
Python's potential applications rather than diminish it.

Yep, (support in Django, specifically, not Python).

>
--
Ben Sizer

[Ray]

Ben Sizer wrote:

a minimal layer over the C interface anyway. DirectX support only
appeared this year unless you used IronPython, and it doesn't seem very
popular.

IronPython is not released yet, I do hope it will become popular
though. It's in RC1 now and should be released soon. I'm really looking
forward to it!

Certainly, some Web frameworks have some element of Java flavouring,
but there's also considerable diversity at least at certain levels.

Pretty much every Python web offering revolves around you having your
own server with the luxury of running your own long-running processes
on it. Great for business apps, not much use for the hobbyist or
independent site. There are probably some hosts that will provide
shared hosting for your Django or Turbogears app, but they are not
exactly numerous. The barrier to entry here is much higher than with
PHP or ASP, for example. And even with the full framework approach, the
field has been so fragmented until recently that in terms of community
support, you'd be better off opting for another language. I appreciate
there's a diversity vs. standardisation argument there which may never
be settled, so I accept this is just a personal opinion, but I do think
a critical mass of users is important with any technology.

Diversity can be a pain in the ass sometimes. Instead of ending up with
something really good you end up with a lot of mediocre stuff (Note:
I'm not saying anything about Django or Turbogears here, mind!).
Reminds me of the time when I was installing Linux for the first time
and finding out that there were tons of text editor included in the
distro. I only need vi so that wasn't a problem, but I could imagine
someone from a strictly Windows world would wish that there was only
one text editor :)

I'm in a similar situation to the original poster; I'd like to use
Turbogears for an app I want to write, but will probably end up doing
it in PHP instead, because I can't get dedicated hardware or a local
host for Turbogears. (Never mind the lack of documentation.)

Yep. And my case now is pretty much shot with no Oracle/SQL Server
support.

Otherwise, no amount of complaining will put the
two technologies together.

It's a fair point, but on the other hand, saying "if you want it doing,
do it yourself" doesn't objectively improve the status quo. If
something doesn't exist, it doesn't exist, and it's valid to comment
upon that fact.

Couldn't agree more. A lot of would-be users, upon being told that,
would simply turn to another framework/language/platform/whatever that
does provide the feature in question. This is especially true for
companies with fast moving projects like the one I'm working for at the
moment.

Of course, then we can always say, "sureeee, go ahead, your loss blah
blah blah" Well maybe. But how does it help ourselves really?

>
--
Ben Sizer

[Paul Boddie]

Ben Sizer wrote:

Paul Boddie wrote:

Ben Sizer wrote:

>
In my case, multimedia and game support is patchy,

There are lots of multimedia and game frameworks for Python. Which ones
have you tried and why are they insufficient?

PyGame was barely maintained for a year, and is based on SDL which was
also barely maintained for a year, and which hasn't kept up with
hardware advances at all. On the graphical side you can opt for OpenGL,
the Python library for which is also barely maintained (though I hear
work is underway behind the scenes) and doesn't provide much more than
a minimal layer over the C interface anyway. DirectX support only
appeared this year unless you used IronPython, and it doesn't seem very
popular.

I can only profess familiarity with Pygame which still seems to do more
or less what it always did, although I haven't kept up with the
community, but I have recently released a simple game which seems to
work quite well. By "simple", I mean two-dimensional playing areas,
pre-recorded soundtracks, retro-style gameplay.

If I were to get into OpenGL, I'd look at stuff like PyQt alongside
other traditional bindings, mostly because such frameworks - certainly
Qt, as far as I've seen from various reports - usually incorporate a
lot of effort resulting from a serious amount of developer attention to
integrating such technologies and making them work reliably in a number
of environments.

Which other frameworks are you thinking of? I know of a variety of
wrappers around individual libraries, and of wrappers around 3D engines
such as Irrlicht and Ogre, but not much else.

If I were to consider other three-dimensional rendering technologies,
I'd probably look at things like Soya 3D, Panda3D and whatever other
people have dug up:

http://www.vrplumber.com/py3d.py

You also mentioned multimedia frameworks, and this is probably another
area where there are so many projects that it's hard to pick the good
ones.

Certainly, some Web frameworks have some element of Java flavouring,
but there's also considerable diversity at least at certain levels.

Pretty much every Python web offering revolves around you having your
own server with the luxury of running your own long-running processes
on it. Great for business apps, not much use for the hobbyist or
independent site.

Once upon a time I used to advocate my WebStack framework as a solution
to this problem situation: WebStack applications run on BaseHTTPServer
or other monolithic servers (Webware, Twisted, Zope 2, Java Servlet),
but can also be deployed as CGI or in mod_python environments. The
apparent response to this advocacy (which was backed up by an actual
implementation) was that no-one needed such flexibility: an opinion
somewhat at odds with actual practice if you consider widely-deployed
applications such as ViewCVS/ViewVC, Trac, MoinMoin, and so on, where
all of these have provided their own server abstractions at least until
very recently.

Since that time, WSGI has emerged as an interoperability technology,
but the fundamental platform fragmentation issues remain, as everyone
attempts to show how easy it is to write "WSGI middleware". Moreover,
the server abstractions required by widely-deployed applications are
still necessary, and it is in precisely this area that framework
proliferation has occurred.

There are probably some hosts that will provide
shared hosting for your Django or Turbogears app, but they are not
exactly numerous. The barrier to entry here is much higher than with
PHP or ASP, for example.

I think the attitude has been that if you're not willing to lay out the
bucks (albeit not quite as much as it used to be now that virtual
private servers are becoming commonplace), the big players in the
frameworks scene aren't willing to pay you much attention. But as
applications like ViewCVS show, many people appreciate Web application
deployment on low-end hosting, and that not all Web applications are
part of some big Web 2.0 rollout.

And even with the full framework approach, the
field has been so fragmented until recently that in terms of community
support, you'd be better off opting for another language. I appreciate
there's a diversity vs. standardisation argument there which may never
be settled, so I accept this is just a personal opinion, but I do think
a critical mass of users is important with any technology.

I've said this a few times now, but it's worth repeating: when WSGI was
proposed as the next great thing in Python Web standardisation (a topic
in which no-one had any substantial interest until PHP/Ruby were
considered ahead of Python in certain much-discussed decisions), it was
formulated in such a way as to stay off the turf already occupied by
the significant Python frameworks of the time. The consequence of that
decision has been a slight, one centimetre upward movement of the
Python Web scene's "healthy competition" in the entire "framework
stack".

I'm in a similar situation to the original poster; I'd like to use
Turbogears for an app I want to write, but will probably end up doing
it in PHP instead, because I can't get dedicated hardware or a local
host for Turbogears. (Never mind the lack of documentation.)

Sorry to hear that! This point was probably raised a while ago on the
Web-SIG mailing list, and if you're bothered, I'm sure you can track
down whatever reasoning was put forward for the neglect of this
particular usage situation throughout the major frameworks.

Otherwise, no amount of complaining will put the
two technologies together.

It's a fair point, but on the other hand, saying "if you want it doing,
do it yourself" doesn't objectively improve the status quo. If
something doesn't exist, it doesn't exist, and it's valid to comment
upon that fact.

Well, returning to the original point, Oracle database modules have
existed for more than ten years and are presumably a mature area now.
Meanwhile, Django seemed to favour PostgreSQL as an RDBMS last time I
checked. All it takes is someone to stick their neck out and finish the
job - an activity which can admittedly seem suspended for years,
considering the varying levels of support for different database
systems in Webware's MiddleKit persistence layer over its lifetime.

Paul

[Bruno Desthuilliers]

Ben Sizer wrote:
(snip)

Pretty much every Python web offering revolves around you having your
own server with the luxury of running your own long-running processes
on it.

This is becoming less and less of a "luxury" - the cost of dedicated web
servers is really dropping at eyesight.

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"

[Ben Sizer]

Paul Boddie wrote:

I can only profess familiarity with Pygame which still seems to do more
or less what it always did, although I haven't kept up with the
community, but I have recently released a simple game which seems to
work quite well. By "simple", I mean two-dimensional playing areas,
pre-recorded soundtracks, retro-style gameplay.

PyGame is great at what it does, which as you say, is usually
retro-style 2D games. It also provides a reasonable way of setting up a
window for input, sound mixing, etc. But its 2D technology is primitive
(eg. DirectDraw 6 on Windows if I remember correctly) and much of the
rest is not very advanced, such as limited support for controllers,
extra mouse buttons, 3D sound, etc. This is more a limitation of SDL
which got neglected in recent years.

Even C++ comes with OpenGL in the standard library. I am disappointed
that this hasn't become the case with Python. I don't even know if
PyOpenGL is compatible with the latest incarnation of NumPy or whether
you have to rebuild it all yourself. It's a bit of a mess really.

If I were to get into OpenGL, I'd look at stuff like PyQt alongside
other traditional bindings, mostly because such frameworks - certainly
Qt, as far as I've seen from various reports - usually incorporate a
lot of effort resulting from a serious amount of developer attention to
integrating such technologies and making them work reliably in a number
of environments.

Does PyQT play well with PyGame? And isn't it more of a windowing
environment?

Pretty much every Python web offering revolves around you having your
own server with the luxury of running your own long-running processes
on it. Great for business apps, not much use for the hobbyist or
independent site.

Once upon a time I used to advocate my WebStack framework as a solution
to this problem situation: WebStack applications run on BaseHTTPServer
or other monolithic servers (Webware, Twisted, Zope 2, Java Servlet),
but can also be deployed as CGI or in mod_python environments. The
apparent response to this advocacy (which was backed up by an actual
implementation) was that no-one needed such flexibility: an opinion
somewhat at odds with actual practice if you consider widely-deployed
applications such as ViewCVS/ViewVC, Trac, MoinMoin, and so on, where
all of these have provided their own server abstractions at least until
very recently.

Of course, if you're a developer producing your own framework - as
pretty much everybody on the Web-SIG was - then you're presumably
already aiming at the dedicated hosting space, so it's not surprising
that such flexibility is not held in high regard by those.

I've said this a few times now, but it's worth repeating: when WSGI was
proposed as the next great thing in Python Web standardisation (a topic
in which no-one had any substantial interest until PHP/Ruby were
considered ahead of Python in certain much-discussed decisions), it was
formulated in such a way as to stay off the turf already occupied by
the significant Python frameworks of the time.

This is something I wasn't incredibly happy about, as I felt it meant
that personal egos were being saved at the expense of improving Python.
And I always thought that WSGI was solving the wrong problem. It
certainly didn't go very far towards meeting the expressed goals of the
Web-SIG. Oh well.
<http://mail.python.org/pipermail/web-sig/2004-August/000650.html>

--
Ben Sizer

[Terry Reedy]

"Ben Sizer" <ky*****@gmail.comwrote in message
news:11**********************@75g2000cwc.googlegro ups.com...

PyGame was barely maintained for a year, and is based on SDL which was
also barely maintained for a year, and which hasn't kept up with
hardware advances at all.

I believe there is a recent release of SDL, but which what advances I do
not know. Pygame is being actively worked on by more than one person.
tjr

[Vincent Delporte]

On Fri, 28 Jul 2006 17:58:24 +0200, Bruno Desthuilliers
<on***@xiludom.growrote:

>Ben Sizer wrote:
(snip)

>Pretty much every Python web offering revolves around you having your
own server with the luxury of running your own long-running processes
on it.

BTW, what is the advantage of running a CherryPy/Django server instead
of the regular way of code in pages? Improved performance because the
Python interpreter is already up and running?

[Paul Boddie]

Ben Sizer wrote:

>
Even C++ comes with OpenGL in the standard library.

Which standard library?

[...]

Does PyQT play well with PyGame? And isn't it more of a windowing
environment?

I'll have to let that question go, but I imagine the PyQt mailing list
would be able to provide some kind of answer:

http://mats.imk.fraunhofer.de/pipermail/pykde/

As for the nature of PyQt, it is a framework for developing
applications of various kinds, with the graphical user interface part
being the most interesting for most Python developers, I imagine. I
have read that the drawing and rendering support is rather powerful in
PyQt4, and I believe that various Qt-based visualisation solutions
exist.

[Web-SIG standardisation]

This is something I wasn't incredibly happy about, as I felt it meant
that personal egos were being saved at the expense of improving Python.

And some of the old frameworks whose APIs were so sacred have since
been replaced by a selection of new frameworks, each with their own
variation on what could easily be a common API. The original exercise
which led to the making WebStack was to investigate and document just
how each of the main frameworks differed; what I learned was that the
sacred "convenient" APIs of numerous frameworks were frequently
underdefined wrappers around parts of the cgi module that, despite
protests to the contrary, were more or less providing the same
functionality with varying amounts of subjective convenience.

(To an extent, WebStack doesn't expose certain functionality of the old
cgi module API completely, either, but with a dose of additional
motivation, I'd probably update the API to do certain things in a more
satisfactory way whilst preserving the improved semantics.)

And I always thought that WSGI was solving the wrong problem. It
certainly didn't go very far towards meeting the expressed goals of the
Web-SIG. Oh well.
<http://mail.python.org/pipermail/web-sig/2004-August/000650.html>

There are some remarks just after that message about the SIG charter
needing to change or having become irrelevant, but in fact the need for
standard functionality is as relevant today as ever. At a slightly
higher level, everyone would now prefer that you buy into their total
"full stack" solution, perhaps with the exception of the Paste
developers whose selection of packages either suggest a problem of
internal framework proliferation or one of a lack of coherency in
presenting a suitable solution to the casual inquirer.

Given the amount of traffic the Web-SIG mailing list has been getting,
it's safe to say that while many would consider the job done, the
project has mostly failed in meeting its objectives.

Paul

[Tim Roberts]

Vincent Delporte <ju*****@acme.comwrote:

>
BTW, what is the advantage of running a CherryPy/Django server instead
of the regular way of code in pages? Improved performance because the
Python interpreter is already up and running?

Exactly. The Python interpreter can take a significant fraction of a
second to start. For the typical short web request, the overhead can add
up.

On the other hand, unless you're handling dozens of requests per minute,
users are unlikely to notice.

You can also keep session state in memory instead of spilling to disk, and
you can keep database sessions open.
--
- Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.

[Vincent Delporte]

On Sat, 29 Jul 2006 04:07:12 GMT, Tim Roberts <ti**@probo.comwrote:

>Exactly. The Python interpreter can take a significant fraction of a
second to start. For the typical short web request, the overhead can add
up.

On the other hand, unless you're handling dozens of requests per minute,
users are unlikely to notice.

You can also keep session state in memory instead of spilling to disk, and
you can keep database sessions open.

Thanks for the explanations.

[Ben Sizer]

Paul Boddie wrote:

Ben Sizer wrote:

Even C++ comes with OpenGL in the standard library.

Which standard library?

Sorry, it was a long day, and I used entirely the wrong term here. By
that, I meant "typically shipped with each compiler". I've never had to
even install a development library to use OpenGL, whether under Win32
or Linux. It's just a typical part of the distribution.

[Web-SIG standardisation]

And I always thought that WSGI was solving the wrong problem. It
certainly didn't go very far towards meeting the expressed goals of the
Web-SIG. Oh well.
<http://mail.python.org/pipermail/web-sig/2004-August/000650.html>

There are some remarks just after that message about the SIG charter
needing to change or having become irrelevant, but in fact the need for
standard functionality is as relevant today as ever. At a slightly
higher level, everyone would now prefer that you buy into their total
"full stack" solution, perhaps with the exception of the Paste
developers whose selection of packages either suggest a problem of
internal framework proliferation or one of a lack of coherency in
presenting a suitable solution to the casual inquirer.

Yeah. On the server side I think there's been a sad lack of attention
to the large middle ground that lies between simple CGI scripting and
full stack solutions. In fact, I'd guess that the majority of web sites
fall into that middle ground, just perhaps not the most interesting or
financially lucrative ones. Examples might be things like the various
PHP forums, or web-based non-real-time games. These applications are
complex enough to deserve a decent implementation language such as
Python, yet simple and small enough that most users won't want to set
up dedicated hardware for the purpose. I think there's definitely scope
in the standard library to go well beyond the current cgi module and
the piecemeal offerings in other modules, without needing to provide
another integrated web stack.

--
Ben Sizer

[Ben Sizer]

Sybren Stuvel wrote:

Ben Sizer enlightened us with:

PyGame was barely maintained for a year, and is based on SDL which
was also barely maintained for a year, and which hasn't kept up with
hardware advances at all.

Still, ID Software and Epic both use SDL + OpenGL for their games. Why
is it good for them but insufficient for you?

Because id and Epic have many millions of dollars and better developers
to throw at the problem than I do. :) To put it another way, they have
lots of in-house middleware that is built on top of those technologies
to make them more effective. SDL and OpenGL is the bottom of the stack
for them. We mere mortals often prefer to start with something a little
higher level. :)

--
Ben Sizer

[Ben Sizer]

Terry Reedy wrote:

"Ben Sizer" <ky*****@gmail.comwrote in message
news:11**********************@75g2000cwc.googlegro ups.com...

PyGame was barely maintained for a year, and is based on SDL which was
also barely maintained for a year, and which hasn't kept up with
hardware advances at all.

I believe there is a recent release of SDL, but which what advances I do
not know. Pygame is being actively worked on by more than one person.

The recent release of SDL was another minimal one, though there is an
intention to make the important changes 'soon'. As for PyGame, it's
good that development there has picked up again but I'd love to see it
broaden its horizons beyond SDL. Maybe that is impractical, however.

--
Ben Sizer

[Gerhard Fiedler]

On 2006-07-29 01:07:12, Tim Roberts wrote:

Vincent Delporte <ju*****@acme.comwrote:

>>
BTW, what is the advantage of running a CherryPy/Django server instead
of the regular way of code in pages? Improved performance because the
Python interpreter is already up and running?

Exactly. The Python interpreter can take a significant fraction of a
second to start. For the typical short web request, the overhead can add
up.

Is this start-up overhead the same thing for PHP? Or is this handled
differently there?

Gerhard

[Ben Sizer]

Gerhard Fiedler wrote:

On 2006-07-29 01:07:12, Tim Roberts wrote:

Vincent Delporte <ju*****@acme.comwrote:

>
BTW, what is the advantage of running a CherryPy/Django server instead
of the regular way of code in pages? Improved performance because the
Python interpreter is already up and running?

Exactly. The Python interpreter can take a significant fraction of a
second to start. For the typical short web request, the overhead can add
up.

Is this start-up overhead the same thing for PHP? Or is this handled
differently there?

Typically you run PHP as a module in your webserver, so there should be
no process startup overhead. mod_python provides the same sort of
functionality for Python, but is not as popular or widely installed as
the PHP Apache module.

--
Ben Sizer

[Vincent Delporte]

On 31 Jul 2006 07:05:27 -0700, "Ben Sizer" <ky*****@gmail.comwrote:

>Typically you run PHP as a module in your webserver, so there should be
no process startup overhead. mod_python provides the same sort of
functionality for Python, but is not as popular or widely installed as
the PHP Apache module.

So, if mod_python provides the same functionality, it's not the main
reason why Python developers use application servers while PHP users
still program with page codes in /htdocs.

Why do PHP users stick to that old way of things? Because they mostly
use shared hosts, with no way to install their application server?

[Terry Reedy]

"Ben Sizer" <ky*****@gmail.comwrote in message
news:11*********************@m73g2000cwd.googlegro ups.com...

>As for PyGame, it's
good that development there has picked up again but I'd love to see it
broaden its horizons beyond SDL. Maybe that is impractical, however.

By wrapping SDL and interfacing to Numeric, Pete Shinners picked a chunk
that he could chew and maintain. The Pygame site has recently added a
PyGame Cookbook or the equivalent so people can more easily share small
chunks built on pygame and comment thereupon.

tjr

[Bruno Desthuilliers]

Vincent Delporte wrote:

On 31 Jul 2006 07:05:27 -0700, "Ben Sizer" <ky*****@gmail.comwrote:

>Typically you run PHP as a module in your webserver, so there should be
no process startup overhead. mod_python provides the same sort of
functionality for Python, but is not as popular or widely installed as
the PHP Apache module.

So, if mod_python provides the same functionality, it's not the main
reason why Python developers use application servers while PHP users
still program with page codes in /htdocs.

Why do PHP users stick to that old way of things? Because they mostly
use shared hosts, with no way to install their application server?

PHP has never been designed to allow writing such a thing as a web
server (some may say that PHP has never been designed at all, but this
is another troll^Mquestion). IIRC, it was initially meant to run as cgi,
then rewrote as an apache module.

And the fact is that while there's no startup overhead in PHP (at least
when deployed as a module), you still have to rebuild the whole world
(includes, app-specific conf etc) for each request. This is what
long-running application servers try to solve.

mod_python is at once lower-level and a bit more powerful than PHP. It
really exposes most of Apache's API to Python - which BTW doesn't make
it that well-suited for shared hosting... (most of the time, updating a
mod_python based app requires restarting the server).
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"

[Gerhard Fiedler]

On 2006-07-31 14:37:26, Bruno Desthuilliers wrote:

>So, if mod_python provides the same functionality, it's not the main
reason why Python developers use application servers while PHP users
still program with page codes in /htdocs.

Why do PHP users stick to that old way of things? Because they mostly
use shared hosts, with no way to install their application server?

I'm not sure about PHP users in general, but I think that there are many
sites hosted on shared hosts. Many of those sites need a solution for
dynamic pages. That's quite a market.

mod_python is at once lower-level and a bit more powerful than PHP. It
really exposes most of Apache's API to Python - which BTW doesn't make
it that well-suited for shared hosting... (most of the time, updating a
mod_python based app requires restarting the server).

Why is that (restarting required)? And is there a way to "lock down" a
mod_python installation WRT Apache, in a way similar to a typical PHP
installation? AFAIK there are a number of shared hosts that support Python.
I'm not sure whether that's mod_python, though...

Thanks,
Gerhard

[Ben Sizer]

Vincent Delporte wrote:

On 31 Jul 2006 07:05:27 -0700, "Ben Sizer" <ky*****@gmail.comwrote:

Typically you run PHP as a module in your webserver, so there should be
no process startup overhead. mod_python provides the same sort of
functionality for Python, but is not as popular or widely installed as
the PHP Apache module.

So, if mod_python provides the same functionality, it's not the main
reason why Python developers use application servers while PHP users
still program with page codes in /htdocs.

Why do PHP users stick to that old way of things? Because they mostly
use shared hosts, with no way to install their application server?

Yes, one reason is because they can't install anything other than web
pages. Not only can they not install a Python application server, they
can't install mod_python either, and few places will have it
pre-installed. Shared hosting accounts for a massive number of sites so
this is a significant issue.

Another perfectly good reason is that PHP pages are much simpler to
deploy than any given Python application server. Just add the code into
your HTML pages as required and you're done. Python could come close to
this if something like the Python Server Pages implementation in
mod_python was to become widely available and well known, but that
still requires overcoming the first problem.

--
Ben Sizer

[Paul Rubin]

"Ben Sizer" <ky*****@gmail.comwrites:

Another perfectly good reason is that PHP pages are much simpler to
deploy than any given Python application server. Just add the code into
your HTML pages as required and you're done. Python could come close to
this if something like the Python Server Pages implementation in
mod_python was to become widely available and well known, but that
still requires overcoming the first problem.

I didn't realize you could do shared hosting with mod_python, because
of the lack of security barriers between Python objects (i.e. someone
else's application could reach into yours). You really need a
separate interpreter per user. A typical shared hosting place might
support 1000's of users with ONE apache/php instance (running in a
whole bunch of threads or processes, to be sure).

[Ben Sizer]

Paul Rubin wrote:

"Ben Sizer" <ky*****@gmail.comwrites:

Another perfectly good reason is that PHP pages are much simpler to
deploy than any given Python application server. Just add the code into
your HTML pages as required and you're done. Python could come close to
this if something like the Python Server Pages implementation in
mod_python was to become widely available and well known, but that
still requires overcoming the first problem.

I didn't realize you could do shared hosting with mod_python, because
of the lack of security barriers between Python objects (i.e. someone
else's application could reach into yours). You really need a
separate interpreter per user. A typical shared hosting place might
support 1000's of users with ONE apache/php instance (running in a
whole bunch of threads or processes, to be sure).

Ah yes, I hadn't considered that. Is this a Python limitation?
Py_Initialize() seems to initialise a global Python object which
obviously makes it awkward to share. Other languages allow you to
create multiple instances (eg. Lua has lua_newstate() which returns a
new Lua state) which would facilitate running multiple interpreters
without the new process overhead. A brief search implies that mod_perl
doesn't have the same problem as mod_python (but has other problems).
It would be a shame if Python is almost alone in having this issue.

--
Ben Sizer

[Alex Martelli]

Bruno Desthuilliers <on***@xiludom.growrote:
...

>And of course import hooks.

Python?? Where?

RTFM:
http://www.python.org/doc/2.3.5/lib/built-in-funcs.html

Perhaps a better reference is <http://www.python.org/dev/peps/pep-0302/>
..

Alex

[Alex Martelli]

Ray <ra********@yahoo.comwrote:

Damjan wrote:

BTW I'd choose TurboGears for it's flexibility, but I guess Django could be
nice when more rapid results are needed (and the problem doesn't fall too
far from the Django sweet spot).

Well actually I was thinking of exaclty the same thing, because our
apps are mostly CRUD apps anyway. However I just learned of one very
big killer--lack of support for Oracle and MS SQL Server. That pretty
much shoots Django down from the list, and with it Python.

According to
<http://wiki.rubyonrails.com/rails/pages/Framework+Performance>, with
Rails...:

"""
When connecting rails to Oracle the performance dropped to the extent it
made any production use of the product useless.
...
Oracle. I would bet performance degrades dramatically when Rails
connects to Oracle as Rails does not use Bind Variables or cache
prepared statements. Not using bind variables in Oracle is the single
most common mistake. When running the load test connected to Oracle,
does Oracle consume a lot of the CPU?
Its unfortunate, as until Rails handles Oracle correctly, its not really
fit to be used on it, and I was really hoping to use it there!
"""

IOW, if these comments are correct, Rails is also _practically_ unusable
with Oracle. Meanwhile, Django has experimental Oracle support with a
patch (<http://code.djangoproject.com/ticket/1990>, latest checkin is
from Jul 31, but it has been around for over a year in some form or
other). As to what will mature first, Rails/Oracle performance or the
Django/Oracle patch, who knows. I suspect it won't matter much, because
"buzz" trumps substance (in the short run, at least), and Ruby on Rails
has buzz (according to Tim O'Reilly's reports at OSCON last week, sales
of Ruby books have overtaken sales of Perl books recently -- Python
books, while gaining relative to Perl, are still below).

The one big issue that may preserve Perl, Python and PHP against Ruby's
onslaught is -- acronyms. Any of the "P" languages can acronymically be
part of a "LAMP" setup, one of the coolest acronyms in years; indeed,
BSD, PostgreSQL and lighttpd may already have been handicapped by the
un-coolness of acronyms such as BLPP. But Ruby suffers even worse here,
since somebody using Ruby instead of a P-language would be a... LAMR!!!

If I were on the board of the Ruby equivalent of the PSF, I'd be
lobbying hard for the language's name to be changed to PRuby -- with the
P being mute, as in Wodehouse's character Psmith. _That_ would remove
the acronymical barrier and ensure PRuby's triumph.
Alex

[aaronwmail-usenet]

Paul Rubin wrote:

I didn't realize you could do shared hosting with mod_python, because
of the lack of security barriers between Python objects (i.e. someone
else's application could reach into yours). You really need a
separate interpreter per user. A typical shared hosting place might
support 1000's of users with ONE apache/php instance (running in a
whole bunch of threads or processes, to be sure).

You just need to run multiple apache
instances, which is advisable anyway.
The hosting service formerly known as
python-hosting has been doing this
for years. For example my http://www.xfeedme.com
site uses it (which seems to be down at the moment!
oh no! :( ).
-- Aaron Watters

ps: little known fact: mod_python descends
from an NSAPI plugin implementation
I wrote as an example of embedding python in
the defunct "Internet Programming
with Python" book. Books die, but software lives on.

===
if you are happy and you know it stick with your dosage.
-- seen in the New Yorker

[Ben Sizer]

aa***************@yahoo.com wrote:

Paul Rubin wrote:

A typical shared hosting place might
support 1000's of users with ONE apache/php instance (running in a
whole bunch of threads or processes, to be sure).

You just need to run multiple apache
instances, which is advisable anyway.
The hosting service formerly known as
python-hosting has been doing this
for years.

Would you need one instance per user? Is it practical to run 1000s of
Apache instances on one server?

--
Ben Sizer

[aaronwmail-usenet]

Ben Sizer wrote:

aa***************@yahoo.com wrote:

Paul Rubin wrote:

A typical shared hosting place might
support 1000's of users with ONE apache/php instance (running in a
whole bunch of threads or processes, to be sure).

You just need to run multiple apache
instances, which is advisable anyway.
The hosting service formerly known as
python-hosting has been doing this
for years.

Would you need one instance per user? Is it practical to run 1000s of
Apache instances on one server?

I'm almost certain Apache spawns instances as needed.
If they are all active at the same time you will need at least
that many threads anyway and I don't think processes
are really much more expensive than threads usually.
But I'm not an expert on virtual hosting or apache or
even thread/process internals.

However when I do a "ps -aef" on my shared server
(http://www.xfeedme.com) I only see the apache
instances that are active, and not the 50 dormant
ones, if I recall.

-- Aaron Watters

===
She was flirty, dirty, musta been about thirty
-- 70's stones lyrics
She was nifty, shifty musta been about fifty
-- 90's stones lyrics

[Bruno Desthuilliers]

Paul Rubin wrote:

"Ben Sizer" <ky*****@gmail.comwrites:

>Another perfectly good reason is that PHP pages are much simpler to
deploy than any given Python application server. Just add the code into
your HTML pages as required and you're done. Python could come close to
this if something like the Python Server Pages implementation in
mod_python was to become widely available and well known, but that
still requires overcoming the first problem.

I didn't realize you could do shared hosting with mod_python, because
of the lack of security barriers between Python objects (i.e. someone
else's application could reach into yours). You really need a
separate interpreter per user.

mod_python uses sub-interpreters - can be per virtual server, per
directory etc, cf
http://www.modpython.org/live/curren...other-ipd.html
http://www.modpython.org/live/curren...ther-ipdv.html
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"

[Damjan]

>I didn't realize you could do shared hosting with mod_python, because

>of the lack of security barriers between Python objects (i.e. someone
else's application could reach into yours). You really need a
separate interpreter per user.

mod_python uses sub-interpreters - can be per virtual server, per
directory etc, cf
http://www.modpython.org/live/curren...other-ipd.html
http://www.modpython.org/live/curren...ther-ipdv.html

Yes, but your mod_python programs still run with the privileges of the
Apache process, as are all the other mod_python programs. This means that
my mod_python program can (at least) read files belonging to you -
including your config file holding your database password.

PHP solves this problem by using it's safe mode and basedir restrictions.
Mod_python nor Python itself don't have this feature.

There are sollutions for Apache that run each virtual host under a different
uid but they have quirks:

Metux MPM - http://www.metux.de/mpm/en/
mod_suid - for apache 1.3.x
http://www.palsenberg.com/index.php/..._1_xx_mod_suid
mod_suid2 - for apache 2.0.x
http://bluecoara.net/item24/cat5.html
mod_ruid - seems to be an improvement of mod_suid2
http://websupport.sk/~stanojr/projects/mod_ruid/

But I see mod_python more as a way to extend Apache itself, than for running
Python applications. A lot of the Apache mod_auth_* modules could be
replaced with mod_python scripts.

OTOH SCGI or FastCGI seem better sutied for python web (WSGI) applications.

--
damjan

[aaronwmail-usenet]

Damjan wrote:

Yes, but your mod_python programs still run with the privileges of the
Apache process, as are all the other mod_python programs. This means that
my mod_python program can (at least) read files belonging to you -
including your config file holding your database password....

I think a standard solution to this is to
associate each virtual host server to a
different port and have the main apache
redirect to the port. Inetd makes sure
that the vserver apache instance only
stays alive while it's needed. It might be
complicated to set up, but it works.
Again, something like this is probably
advisable anyway to limit the ways one
vserver can damage another generally
speaking.
-- Aaron Watters

===
It's not the years. It's the mileage.
-- Indiana Jones

[Damjan]

>Yes, but your mod_python programs still run with the privileges of the

>Apache process, as are all the other mod_python programs. This means that
my mod_python program can (at least) read files belonging to you -
including your config file holding your database password....

I think a standard solution to this is to
associate each virtual host server to a
different port and have the main apache
redirect to the port. Inetd makes sure
that the vserver apache instance only
stays alive while it's needed. It might be
complicated to set up, but it works.
Again, something like this is probably
advisable anyway to limit the ways one
vserver can damage another generally
speaking.

Starting a new Apache process with python included (trough mod_python) is
even worse than CGI.

But it seems AppArmor supports secureing mod_python (and mod_php and
mod_perl) with a special Apache module (and the AppArmor support in the
Linux kernel - yes this is Linux only).

http://developer.novell.com/wiki/ind..._protection.3F

Now that it's GPL AppArmor seems to get a lot of supporters.

--
damjan

[aaronwmail-usenet]

Damjan wrote:>

Starting a new Apache process with python included (trough mod_python) is
even worse than CGI.

Yes, but I think only for the first interaction
after being dormant for a period. In fact I've
noticed that hitting http://www.xfeedme.com
the first time is usually slow. But once the
apache is up it seems to stay up until it has
been inactive for a good while, and it's fast.
I'm inferring all this from what I see using
"ps" and other indirect tools.

-- Aaron Watters

===
as the poet said:
"Everybody have fun tonight
Everybody Wang Chung tonight"