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

HTML generation with PL/PgSQL

P: n/a
Hi,

I'm very fresh to PostgreSQL, coming from Oracle.
I want to developp web applications based on apache and postgresql.
Is there an equivalent of OWA server (Oracle Web Application server) for
postgresql.
Shortly, OWA provides an apache module and a set of stored
procedures/functions that generate html pages.

A simple example could be the following procedure :

procedure hello {
htp.htmlOpen;
htp.headOpen;
htp.title("Simple test page");
htp.headClose:
htp.bodyOpen
htp.print( htf.h2( htf.center( "This is a simple test page" ) ) );
htp.paragraph;
htp.print("Dynamic hello from Postgresql");
htp.bodyClose;
htp.htmlClose;
}

That would generate the following html code :

<html>
<head>
<title>Simple test page</title>
</head>
<body>
<h2><center>This is a simple test page</center></h2>
<p></p>
Dynamic hello from Postgresql
</body>
</html>

Is such a product exists (preferably opensource).
I'm ready to go for python etc, but I really wuld have to re-educate
myself.....

Thanks in advance.
Bir

Nov 12 '05 #1
Share this Question
Share on Google+
15 Replies


P: n/a
On Thursday 23 October 2003 11:38, Birahim FALL wrote:
Is such a product exists (preferably opensource).
I'm ready to go for python etc, but I really wuld have to re-educate
myself.....


Bir,
There are a LOT of ways to make web pages with data from Postgres.

I'd suggest you get:

The latest Postgres
Apache2 (http://httpd.apache.org)
Mod_Python (http://www.modpython.org) Get the latest CVS version (3.1.2b at this writing).
Python 2.3.2+ (http://www.python.org)
Draco (http://draco.boskant.nl) 0.99.4 or (Quixote http://freshmeat.net/redir/quixote/1...mepage/quixote)
and Psycopg (http://freshmeat.net/projects/psycopg)
and whatever few dependencies these have (mxDateTime comes to mind).

Get the latest versions of everything. That's a complete kit to make Anything You Want.

Draco and Quixote take much different approaches to gluing Python to web pages. Both are worth a good look, just to understand their ways of doing things.
Both are different from the rather inelegant way of printing each HTML element using special coding, which Oracle looks like it uses.
Draco has strong logic/presentation seperation. Quixote takes the unique approach of allowing you to embed HTML in Python rather than the more common opposite.
There are LOTS of other packages to "glue" HTML and databases together in Python. I wouldn't look anywhere beyond Python.
I've found Draco to be very approachable and well designed and fairly complete. (You will need the CVS version 3.1.2b of mod_python or newer to make it work right).

Everyone, of course, disagrees on what combination is be the Right Thing. These are my favorites, for now.
I'm re-educating myself out of Perl, Procedural Programming and other Wrong Things (ducking to avoid flames).
It's a hill to climb but I'm really enjoying it and have Big Plan$ that Postgres will be driving. :-)

Happy Trails,
Scott

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Nov 12 '05 #2

P: n/a
On Friday 24 October 2003 06:24, Scott Chapman wrote:
On Thursday 23 October 2003 11:38, Birahim FALL wrote:
Is such a product exists (preferably opensource).
I'm ready to go for python etc, but I really wuld have to re-educate
myself.....


Bir,
There are a LOT of ways to make web pages with data from Postgres.

I'd suggest you get:

The latest Postgres
Apache2 (http://httpd.apache.org)
Mod_Python (http://www.modpython.org) Get the latest CVS version (3.1.2b at
this writing). Python 2.3.2+ (http://www.python.org)
Draco (http://draco.boskant.nl) 0.99.4 or (Quixote
http://freshmeat.net/redir/quixote/1...mepage/quixote) and Psycopg
(http://freshmeat.net/projects/psycopg)
and whatever few dependencies these have (mxDateTime comes to mind).


Python is very well respected, and Perl has modules to do anything you want
and many things you don't/shouldn't/are bad for your health.

You might want to look at PHP (http://www.php.net) which has a syntax which is
quite close to what you want.
A word of warning - it's very easy in PHP to mix your code and HTML. For
anything but the smallest project you don't want to do this. There are lots
of templating options, but smarty (http://smarty.php.net) is quite popular
and flexible.

--
Richard Huxton
Archonet Ltd

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

Nov 12 '05 #3

P: n/a
Quoting Scott Chapman <sc********@mischko.com>:
On Thursday 23 October 2003 11:38, Birahim FALL wrote:
Is such a product exists (preferably opensource).
I'm ready to go for python etc, but I really wuld have to re-educate
myself.....


Bir,
There are a LOT of ways to make web pages with data from Postgres.

I'd suggest you get:

The latest Postgres
Apache2 (http://httpd.apache.org)
Mod_Python (http://www.modpython.org) Get the latest CVS version (3.1.2b at
this writing).
Python 2.3.2+ (http://www.python.org)
Draco (http://draco.boskant.nl) 0.99.4 or (Quixote
http://freshmeat.net/redir/quixote/1...mepage/quixote)
and Psycopg (http://freshmeat.net/projects/psycopg)
and whatever few dependencies these have (mxDateTime comes to mind).

Get the latest versions of everything. That's a complete kit to make
Anything You Want.

Draco and Quixote take much different approaches to gluing Python to web
pages. Both are worth a good look, just to understand their ways of doing
things.
Both are different from the rather inelegant way of printing each HTML
element using special coding, which Oracle looks like it uses.
Draco has strong logic/presentation seperation. Quixote takes the unique
approach of allowing you to embed HTML in Python rather than the more common
opposite.
There are LOTS of other packages to "glue" HTML and databases together in
Python. I wouldn't look anywhere beyond Python.
I've found Draco to be very approachable and well designed and fairly
complete. (You will need the CVS version 3.1.2b of mod_python or newer to
make it work right).

Everyone, of course, disagrees on what combination is be the Right Thing.
These are my favorites, for now.
I'm re-educating myself out of Perl, Procedural Programming and other Wrong
Things (ducking to avoid flames).
It's a hill to climb but I'm really enjoying it and have Big Plan$ that
Postgres will be driving. :-)

Happy Trails,
Scott

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match


Bir,

There are definitely a lot of ways to do this. One of the things you want to
decide first is how you are going to serve your pages. I'd say there are 3
basic types.

1) Static- Obviously you are not going to be doing this since you want data
coming out of the database but read on...
2) "Somewhat" Dynamic - I would characterize this as static pages with embedded
code. See Apache's server side includes documentation
at http://httpd.apache.org/docs-2.0/howto/ssi.html.
3) Dynamic- I would characterize this as complete page generation from a server
side process. You can pretty much use any language you want.
I personally use perl (http://perl.apache.org) but you should check
out Apache's Java server info (http://jakarta.apache.org) as well
as Sun's J2 technology (http://java.sun.com). There is also
PHP at http://www.php.net. This info for python was already
provided to you. 'Course there are still other way to skin this
cat.

I additionally would strongly recommend going through Apache's site as
previously posted since the back integration options (or at least the depth and
breadth of how far you can go with them) are going to be centered around the web
server. Thus if you are using some other flavor of web server, you should see
what your integration options are there as part of your research.

Get your favorite elixer and browse away :)

Good luck!

--
Keith C. Perry
Director of Networks & Applications
VCSN, Inc.
http://vcsn.com

____________________________________
This email account is being host by:
VCSN, Inc : http://vcsn.com

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 12 '05 #4

P: n/a
On Friday 24 October 2003 01:28, Richard Huxton wrote:
Python is very well respected, and Perl has modules to do anything you want
and many things you don't/shouldn't/are bad for your health.

You might want to look at PHP (http://www.php.net) which has a syntax which
is quite close to what you want.
A word of warning - it's very easy in PHP to mix your code and HTML. For
anything but the smallest project you don't want to do this. There are lots
of templating options, but smarty (http://smarty.php.net) is quite popular
and flexible.


I don't want to start a flame war on the different scripting languages
available out there, ok, but I do want to share my reasoning on scripting
languages in case it's helpful. Insightful comments are welcome!

I looked at Python initially but the guy I was going to work for didn't like
it because it was not known to him. So I looked further.

When I started evaluating scripting languages, PHP was becoming popular. I
decided against it because it only did web pages. It's not (or wasn't then)
a general purpose scripting language. I didn't want to climb that learning
curve for a single use. It also didn't have a consistent database interface
across different databases (which I understand has been fixed now). Since
then, I've bumped into documentation on Rackspace's attempt to use PHP and
their move to Python
(http://python.oreilly.com/news/pytho...ss_stories.pdf) and felt I'd made
the right choice.

Then I switched to Perl. Perl has CPAN which keeps you from reinventing the
wheel. It's Perl's ace in the hole. I programmed a Postgres-driven web
application over a 3-year period, in EmbPerl (because it allowed me to embed
Perl in the HTML (like PHP) - which I later learned is not such a Good Thing
but it got the job done). Perl is "mind-share king", I think, in the Linux
web space. It got the job done. I was using procedural programming mostly;
having not climbed the Object Oriented trail yet. I know Perl can do OO but
see below.

I began looking for an alternative to Perl and studying OO. Python got a
second look and I decided to implement my next project in Python. It's OO
from the ground up, not having OO "bolted on" later like C -> C++. That
makes it more comfortable to program in. I also love the indentation to
differentiate code blocks rather than the junk I'd been used to seeing in
Perl and previous languages. It also has a very nice set of modules in it's
standard library and more out on the Net so CPAN's "ace" status is being
eroded for Perl.

Those are my ramblings on scripting languages. Take a good look at your
options before you jump!

Cordially,
Scott

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Nov 12 '05 #5

P: n/a
On Fri, 24 Oct 2003, Scott Chapman wrote:
On Friday 24 October 2003 01:28, Richard Huxton wrote:
Python is very well respected, and Perl has modules to do anything you want
and many things you don't/shouldn't/are bad for your health.

You might want to look at PHP (http://www.php.net) which has a syntax which
is quite close to what you want.
A word of warning - it's very easy in PHP to mix your code and HTML. For
anything but the smallest project you don't want to do this. There are lots
of templating options, but smarty (http://smarty.php.net) is quite popular
and flexible.
I don't want to start a flame war on the different scripting languages
available out there, ok, but I do want to share my reasoning on scripting
languages in case it's helpful. Insightful comments are welcome!

I looked at Python initially but the guy I was going to work for didn't like
it because it was not known to him. So I looked further.

When I started evaluating scripting languages, PHP was becoming popular. I
decided against it because it only did web pages.


I started using it around version 3.0.5 (i.e. set the way back machine Mr.
Peabody...) and it already worked fine as a general purpose scripting
language back then, you just had to know to compile the CGI version and
use it like any other interpreter.
It also didn't have a consistent database interface
across different databases (which I understand has been fixed now).
Well, it did have ODBC, which is pretty database neutral, but it's not the
same as a genuine db abstraction layer like adodb.

Since then, I've bumped into documentation on Rackspace's attempt to use PHP and
their move to Python
(http://python.oreilly.com/news/pytho...ss_stories.pdf) and felt I'd made
the right choice.
Actually, having read that article now, I'm amazed at how many problems
they've had. As an old C programmer, I've got the discipline need to
write stuff in PHP or C and make a maintainable mound of code without the
need for as much hand holding as it appeared the rackspace folks must have
needed. And I've never had the issues they mention with things like lost
objects, etc... Of course, we moved to PHP 4 only after it had settled
down a bit. I don't generaly put .0 releases into production for much of
anything.
Then I switched to Perl. Perl has CPAN which keeps you from reinventing the
wheel. It's Perl's ace in the hole. I programmed a Postgres-driven web
application over a 3-year period, in EmbPerl (because it allowed me to embed
Perl in the HTML (like PHP) - which I later learned is not such a Good Thing
but it got the job done). Perl is "mind-share king", I think, in the Linux
web space. It got the job done. I was using procedural programming mostly;
having not climbed the Object Oriented trail yet. I know Perl can do OO but
see below.
I always found CPAN to be both a blessing and a bane. It's designed for a
single person sitting in front of a single machine, much like Windows
updates. I.e. if I've got a farm with 30 servers in it, CPAN felt like it
was designed so I was supposed to sit in front of each one and download
all 30 or so packages I needed on each one. There are, I'm certain, ways
around that, but they never seemed very obvious to me.
I began looking for an alternative to Perl and studying OO. Python got a
second look and I decided to implement my next project in Python. It's OO
from the ground up, not having OO "bolted on" later like C -> C++. That
makes it more comfortable to program in.
Agreed, although some languages seem to take to having OO bolted on better
than others (i.e. PHP's OO is fairly well done, C++ is the old Dog becomes
octopus after having 4 more legs stapled to it).
I also love the indentation to
differentiate code blocks rather than the junk I'd been used to seeing in
Perl and previous languages.
Sorry, that was the one big turnoff for me in Python. Indentation is
simple to me, I do it linux kernel style, and don't even have to pay
attention to it anymore, it's just automatic for me. I guess I'm just
used to doing it the old fashioned way.
It also has a very nice set of modules in it's
standard library and more out on the Net so CPAN's "ace" status is being
eroded for Perl.
PHP, by the way, as it's own repository, called PEAR, that's quite nice
too.
Those are my ramblings on scripting languages. Take a good look at your
options before you jump!


I will, and hope you the best. Later...
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Nov 12 '05 #6

P: n/a
On Fri, 24 Oct 2003, scott.marlowe wrote:
On Fri, 24 Oct 2003, Scott Chapman wrote:

[...]
I also love the indentation to
differentiate code blocks rather than the junk I'd been used to seeing in
Perl and previous languages.


Sorry, that was the one big turnoff for me in Python. Indentation is
simple to me, I do it linux kernel style, and don't even have to pay
attention to it anymore, it's just automatic for me. I guess I'm just
used to doing it the old fashioned way.


I don't get it. If you already indent code, what's the problem with
Python? Python _requires_ correct indentation, so it's a problem only
to beginners who don't like indenting (and forces them in doing
the Right Thing). If indentation is automatic for you, you're already
doing it the Python way.
Enforcing correct indentation is not more a burden than enforcing
braces matching (or BEGIN/END): it's just syntax, and comes natural
to most experienced programmers. Python codes is just prettier to
the eyes (and thus, to the mind), just because it's simpler w/o
braces and semicolons (any UNIX/C programmer already has an internal
background parser for that, I know).

BTW, I do 80% of my scripting in PHP (started with PHP/FI), 10% in perl
(perl4) and 10% in python (1.5). PHP is usually web-oriented (but
use php -f sometimes, expecially for cron scripts that share code
with CGI ones). Perl is unbeatable in quick&dirty processing scripts
(Perl can be both _very_ quick and _very_ dirty), Pyhton for anything
bigger and well-designed (and with a GUI). All three should have
a place in your toolbox, and you should use the right tool for the
right task. The same applies to PostgreSQL. I'd never use it as
permanent storage for my Perl hashes or Python dictionaries: old-style
NDBM/Berkeley DB will do (and do well) most of the times.

Don't go with one scripting language, learn them all. Even tcl will teach
you something (not much, I admit).

..TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ Co*****@ESI.it
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Nov 12 '05 #7

P: n/a
In addition to all of the fancy tools, there is the
simple options on psql:

psql -H -c "select * from pg_user;";

This outputs the selections in HTML which I am
not including here. If you also use the -T
option you can set the table attributes.

--elein
el***@varlena.com
================================================== ===========
el***@varlena.com www.varlena.com
PostgreSQL Consulting & Support
PostgreSQL General Bits http://www.varlena.com/GeneralBits/
================================================== ===========
I have always depended on the [QA] of strangers.

On Thu, Oct 23, 2003 at 08:38:37PM +0200, Birahim FALL wrote:
Hi,

I'm very fresh to PostgreSQL, coming from Oracle.
I want to developp web applications based on apache and postgresql.
Is there an equivalent of OWA server (Oracle Web Application server) for
postgresql.
Shortly, OWA provides an apache module and a set of stored procedures/functions
that generate html pages.

A simple example could be the following procedure :

procedure hello {
htp.htmlOpen;
htp.headOpen;
htp.title("Simple test page");
htp.headClose:
htp.bodyOpen
htp.print( htf.h2( htf.center( "This is a simple test page" ) ) );
htp.paragraph;
htp.print("Dynamic hello from Postgresql");
htp.bodyClose;
htp.htmlClose;
}

That would generate the following html code :

<html>
<head>
<title>Simple test page</title>
</head>
<body>
<h2><center>This is a simple test page</center></h2>
<p></p>
Dynamic hello from Postgresql
</body>
</html>

Is such a product exists (preferably opensource).
I'm ready to go for python etc, but I really wuld have to re-educate
myself.....

Thanks in advance.
Bir


---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 12 '05 #8

P: n/a
I'm a big fan of Python, and the indentation doesn't bother me, but I do
miss brace matching in Vi. % % was so handy for hopping thru code or
checking blocks.

Marco Colombo wrote:
On Fri, 24 Oct 2003, scott.marlowe wrote:
On Fri, 24 Oct 2003, Scott Chapman wrote:


[...]
I also love the indentation to
differentiate code blocks rather than the junk I'd been used to seeing in
Perl and previous languages.


Sorry, that was the one big turnoff for me in Python. Indentation is
simple to me, I do it linux kernel style, and don't even have to pay
attention to it anymore, it's just automatic for me. I guess I'm just
used to doing it the old fashioned way.

I don't get it. If you already indent code, what's the problem with
Python? Python _requires_ correct indentation, so it's a problem only
to beginners who don't like indenting (and forces them in doing
the Right Thing). If indentation is automatic for you, you're already
doing it the Python way.
Enforcing correct indentation is not more a burden than enforcing
braces matching (or BEGIN/END): it's just syntax, and comes natural
to most experienced programmers. Python codes is just prettier to
the eyes (and thus, to the mind), just because it's simpler w/o
braces and semicolons (any UNIX/C programmer already has an internal
background parser for that, I know).

BTW, I do 80% of my scripting in PHP (started with PHP/FI), 10% in perl
(perl4) and 10% in python (1.5). PHP is usually web-oriented (but
use php -f sometimes, expecially for cron scripts that share code
with CGI ones). Perl is unbeatable in quick&dirty processing scripts
(Perl can be both _very_ quick and _very_ dirty), Pyhton for anything
bigger and well-designed (and with a GUI). All three should have
a place in your toolbox, and you should use the right tool for the
right task. The same applies to PostgreSQL. I'd never use it as
permanent storage for my Perl hashes or Python dictionaries: old-style
NDBM/Berkeley DB will do (and do well) most of the times.

Don't go with one scripting language, learn them all. Even tcl will teach
you something (not much, I admit).

.TM.


---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

Nov 12 '05 #9

P: n/a
On Sat, 25 Oct 2003, Marco Colombo wrote:
On Fri, 24 Oct 2003, scott.marlowe wrote:
On Fri, 24 Oct 2003, Scott Chapman wrote: [...]
I also love the indentation to
differentiate code blocks rather than the junk I'd been used to seeing in
Perl and previous languages.


Sorry, that was the one big turnoff for me in Python. Indentation is
simple to me, I do it linux kernel style, and don't even have to pay
attention to it anymore, it's just automatic for me. I guess I'm just
used to doing it the old fashioned way.


I don't get it. If you already indent code, what's the problem with
Python? Python _requires_ correct indentation,


No, it RELIES on it. I.e. code blocks are marked out by how you indent.
I.e. it doesn't look for block markers, then make sure indentation is
right, it uses the indentation to show it where code blocks are.

The fact that tabs are parsed as 8 spaces by Python, when many editors are
set to render them as 4 or 6 makes it quite possible to have a file that
looks like it should run but doesn't. I'll take good old {} anyday.

Just do a google search for "python whitespace tabs" and you'll get about
7820 results back...
so it's a problem only
to beginners who don't like indenting (and forces them in doing
the Right Thing). If indentation is automatic for you, you're already
doing it the Python way.


Not exactly. I still prefer being able to do simple:

if (something) do one thing; constructs

Or put in debug lines that ARE NOT indented so they're easier to see:
function test(var1){
# delete this test var when testing is done
$test_var = "set";
start of code...
}

without worrying about the parser complaining about white space.

Indentation is for ME, not the parser. Having it count as the block
marker just feels wrong to me. I'm not even sure I can explain why
completely, but my above points are just one small part of it.

I agree with you on using the right tool for the job. Except Perl.
The more I use other languages, the less I want to use Perl. Maybe it was
a bad experience as a junior developer long ago with it or something :-)
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 12 '05 #10

P: n/a
I agree with you on using the right tool for the job. Except Perl.
The more I use other languages, the less I want to use Perl. Maybe it was
a bad experience as a junior developer long ago with it or something :-)
The problem with Perl is that it is written to provide any and all ways
to do one thing.
The problem with Python is that it is written to provide on way to do
one thing (in theory).
The problem with this argument is that anybody can be a bad programmer ;)
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-222-2783 - jd@commandprompt.com - http://www.commandprompt.com
Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

Nov 12 '05 #11

P: n/a
On Mon, 2003-10-27 at 21:35, Joshua D. Drake wrote:
I agree with you on using the right tool for the job. Except Perl.
The more I use other languages, the less I want to use Perl. Maybe it was
a bad experience as a junior developer long ago with it or something :-)

The problem with Perl is that it is written to provide any and all ways
to do one thing.
The problem with Python is that it is written to provide on way to do
one thing (in theory).
The problem with this argument is that anybody can be a bad programmer ;)


The only parse tree for that last sentence that makes any sense to
me seems to imply that people who use Python are bad programmers,
as opposed to people who plant inward-facing claymores at their PC
(implicit variables in Perl), and wield sharp knives on freshly waxed
dance floors (pointers, in C).

--
-----------------------------------------------------------------
Ron Johnson, Jr. ro***********@cox.net
Jefferson, LA USA

"What other evidence do you have that they are terrorists, other
than that they trained in these camps?"
17-Sep-2002 Katie Couric to an FBI agent regarding the 5 men
arrested near Buffalo NY
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Nov 12 '05 #12

P: n/a
On Monday 27 October 2003 07:19, scott.marlowe wrote:
On Sat, 25 Oct 2003, Marco Colombo wrote:
On Fri, 24 Oct 2003, scott.marlowe wrote:
On Fri, 24 Oct 2003, Scott Chapman wrote:
[...]
> I also love the indentation to
> differentiate code blocks rather than the junk I'd been used to
> seeing in Perl and previous languages.

Sorry, that was the one big turnoff for me in Python. Indentation is
simple to me, I do it linux kernel style, and don't even have to pay
attention to it anymore, it's just automatic for me. I guess I'm just
used to doing it the old fashioned way.


I don't get it. If you already indent code, what's the problem with
Python? Python _requires_ correct indentation,


No, it RELIES on it. I.e. code blocks are marked out by how you indent.
I.e. it doesn't look for block markers, then make sure indentation is
right, it uses the indentation to show it where code blocks are.


You two are saying the same thing using different words, I think. The fact
that Python requires and relies on indentation is, after all, what we're
discussing here! :-)
The fact that tabs are parsed as 8 spaces by Python, when many editors are
set to render them as 4 or 6 makes it quite possible to have a file that
looks like it should run but doesn't. I'll take good old {} anyday.
From the Python Lang Ref:
/docs/python2.3.2/ref/indentation.html

"First, tabs are replaced (from left to right) by one to eight spaces such
that the total number of characters up to and including the replacement is a
multiple of eight (this is intended to be the same rule as used by Unix)."

I include this to point out that it doesn't arbitrarily replace the tabs with
8 spaces. Python PEP 8 gives us useful guidelines on indentation (don't use
tabs, basically):

" Tabs or Spaces?

Never mix tabs and spaces. The most popular way of indenting
Python is with spaces only. The second-most popular way is with
tabs only. Code indented with a mixture of tabs and spaces should
be converted to using spaces exclusively. (In Emacs, select the
whole buffer and hit ESC-x untabify.) When invoking the python
command line interpreter with the -t option, it issues warnings
about code that illegally mixes tabs and spaces. When using -tt
these warnings become errors. These options are highly
recommended!

For new projects, spaces-only are strongly recommended over tabs.
Most editors have features that make this easy to do. (In Emacs,
make sure indent-tabs-mode is nil)."
Just do a google search for "python whitespace tabs" and you'll get about
7820 results back...
so it's a problem only
to beginners who don't like indenting (and forces them in doing
the Right Thing). If indentation is automatic for you, you're already
doing it the Python way.
Not exactly. I still prefer being able to do simple:

if (something) do one thing; constructs


if x == 1: print "X is equal to 1"
blah (not indented - not part of if construct)

.... works in Python.
Or put in debug lines that ARE NOT indented so they're easier to see:
function test(var1){
# delete this test var when testing is done
$test_var = "set";
start of code...
}

without worrying about the parser complaining about white space.
There are other ways to work around this. Typically some #commented string
with something visible in it. Comments can always start at column 1 by the
way for increased visibility.
Indentation is for ME, not the parser. Having it count as the block
marker just feels wrong to me. I'm not even sure I can explain why
completely, but my above points are just one small part of it.
I find it humerous that programmers complain about Python's indentation
requirement when all it's really doing is enforcing a basic tenant of decent
code writing anyway. It does take a bit of adjusting your head around in
order to be comfortable with it for programmers in other languages, but I'm
sure anyone could do this if they put their first impression aside. Someone
once said, "My first impression of him was not good so I determined to get to
know him better". The whole "religion" (and subsequent "wars") around
indententation are indeed humerous. Python has so many strengths that I
certainly wouldn't let the indentation keep me from thoroughly checking out
the language.

' Some good links from Bruce Eckel and Eric Raymond on Python:

http://www.mindview.net/Etc/About/InformITRaw_html
http://mindview.net/FAQ/FAQ-012
http://www.linuxjournal.com/article.php?sid=3882
http://mindview.net/Books/Python/ThinkingInPython.html (The section near the
bottom, "Favorite Quotes").
I agree with you on using the right tool for the job. Except Perl.
The more I use other languages, the less I want to use Perl. Maybe it was
a bad experience as a junior developer long ago with it or something :-)


' Going off on another tangent here, regarding "the right tool for the job".
This may be a difference between seriously educated & experienced programmers
and home-brew ones but I don't think so:

I think that the right tool for the job is generally the one you are most
competent with, in programming languages. Some programmers (the educated &
experienced variety) may have exposure to enough knowlege about programming
languages and problems to be solved that they can actually look at a group of
languages and a problem to be solved and sort out the languages accordingly,
based solely on the language itself (not external factors around it). I
honestly doubt that this is the case in the vast majority of cases (except in
more obvious situations where I may need the speed and control of assembly or
C vs. the bytecode of Python, for instance). I doubt that very many
programmers can actually make a reasoned and objective argument that a given
language will work better for the problem than another. Usually it will be
based on external factors such as "What code libraries are already available
that I'll need so I can get it done faster?" and "Which can I write it in
quickest and best?". This last case is the one that will drive the majority
of cases, I think, and the answer will be the language I'm most fluent in.

Just my 2 cents worth.

Cordially,
Scott
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Nov 12 '05 #13

P: n/a
Scott Chapman <sc********@mischko.com> writes:
You two are saying the same thing using different words, I think. The fact
that Python requires and relies on indentation is, after all, what we're
discussing here! :-)


Since it's completely OT for pgsql-general, maybe you could take it
somewhere else? There's a nice big crossposted flamewar going on
between comp.lang.python and comp.lang.lisp--this'd fit in just fine
there. ;)

-Doug

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

Nov 12 '05 #14

P: n/a
On Tue, 2003-10-28 at 10:51, Scott Chapman wrote:
On Monday 27 October 2003 07:19, scott.marlowe wrote:
On Sat, 25 Oct 2003, Marco Colombo wrote:
On Fri, 24 Oct 2003, scott.marlowe wrote:
> On Fri, 24 Oct 2003, Scott Chapman wrote:

[...]
[snip] I think that the right tool for the job is generally the one you are most
competent with, in programming languages. Some programmers (the educated &
experienced variety) may have exposure to enough knowlege about programming
languages and problems to be solved that they can actually look at a group of
languages and a problem to be solved and sort out the languages accordingly,
based solely on the language itself (not external factors around it). I
honestly doubt that this is the case in the vast majority of cases (except in
more obvious situations where I may need the speed and control of assembly or
C vs. the bytecode of Python, for instance). I doubt that very many
programmers can actually make a reasoned and objective argument that a given
language will work better for the problem than another. Usually it will be
based on external factors such as "What code libraries are already available
that I'll need so I can get it done faster?" and "Which can I write it in
quickest and best?". This last case is the one that will drive the majority
of cases, I think, and the answer will be the language I'm most fluent in.


Don't forget the old standby: 'what language(s) are installed on
this machine?' This is a pretty common issue on Big Iron (which
now includes "mini-computers" and big Sun boxen.

--
-----------------------------------------------------------------
Ron Johnson, Jr. ro***********@cox.net
Jefferson, LA USA

"You ask us the same question every day, and we give you the same
answer every day. Someday, we hope that you will believe us..."
U.S. Secretary of Defense Donald Rumsfeld, to a reporter
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Nov 12 '05 #15

P: n/a
On Tue, Oct 28, 2003 at 04:57:34PM +0100, Marco Colombo wrote:
processing. Try and do the same in any other language, with less
keystrokes:

find / -print0 | perl -ln0e 'print if -p'
I would imagine:

find / -type p

is shorter, but that probably wasn't your point :)

--
Martijn van Oosterhout <kl*****@svana.org> http://svana.org/kleptog/ "All that is needed for the forces of evil to triumph is for enough good
men to do nothing." - Edmond Burke
"The penalty good people pay for not being interested in politics is to be
governed by people worse than themselves." - Plato


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE/ov1iY5Twig3Ge+YRAmNDAKCd5ZYAYlfRoByoKN5j4xSpoihfPQ Cgsmw7
O1SrGnw0yCOvxr52Q/pG9AM=
=ZIbS
-----END PGP SIGNATURE-----

Nov 12 '05 #16

This discussion thread is closed

Replies have been disabled for this discussion.