Thread: HTML generation with PL/PgSQL

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/18740/url_homepage/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
understandtheir ways of doing things. 
Both are different from the rather inelegant way of printing each HTML element using special coding, which Oracle looks
likeit uses.   
Draco has strong logic/presentation seperation. Quixote takes the unique approach of allowing you to embed HTML in
Pythonrather 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
ofmod_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

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/18740/url_homepage/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

Quoting Scott Chapman <scott_list@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/18740/url_homepage/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

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/python_success_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

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/python_success_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...

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.
 _____/ _____/  _/               Colombo@ESI.it

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
elein@varlena.com
=============================================================
elein@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

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.

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 :-)

>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

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. ron.l.johnson@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

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

Scott Chapman <scott_list@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

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. ron.l.johnson@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

On Mon, 27 Oct 2003, 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.
>
> 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...

(most are totally unrelated BTW - like string.strip() manual)

Only broken editors display ascii 09 (hardware tab, HT) as 4 or 6 spaces.
Any serious editor can tell the difference between a HT and "softtabs"
(what happens when you hit the 'TAB' key). Even vi. People may be used
to broken editors, it's their problem.

I think everybody wants his code to be correctly displayed
by cat, more, less, type, notepad, _insert your favorite text viewer_,
any printing system (from cat file > /dev/lp, to text2ps converters)
WITHOUT having to learn how to change the standard meaning of HT.

HT being considered 8 spaces is not an issue.

> > 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
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^

Oh, now I see your problem. You have never actually used python. B-)
I used to agree with you, just writing a few small scripts (expecially
learing GTK and converting C examples from the GTK tutorial to python
on the fly) made me change my mind.
You'll hardly need "dirty tricks" like the one you're showing below
(which I do use in PHP/C/...). Python code is very clean.

And BTW:

x = 4
if x > 3: print "Yes!!"

it's a perfectly valid python program.

> 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 :-)

Once I've even wrote a small python program which produces a perl script
and runs it. The combination of 2 tools sometimes it's better than one
tool only. B-)

Sometimes what I need is just "awk on steroids". While Perl is more
than just that, I find that it's perfect for me in replacing awk.
Just read 'man perlrun': Perl is very strong in supporting commandline
processing. Try and do the same in any other language, with less
keystrokes:

find / -print0 | perl -ln0e 'print if -p'

(process a \0 separated list of filenames, filter only named pipes,
output a \n separated list of filenames).

.TM.
--
      ____/  ____/   /
     /      /       /            Marco Colombo
    ___/  ___  /   /              Technical Manager
   /          /   /             ESI s.r.l.
 _____/ _____/  _/               Colombo@ESI.it

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   <kleptog@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