Is Python Dead?
Edward B. Wilson II
frustrated with it as I was in 1996.
Python still doesn't have good database support, nor has it grown to be
useful in the web space as mod_perl. PyApache has been around longer than
mod_php, yet php has far surpassed it as a productivity tool in the web
space.
It would seem Python can do everything, yet nothing. Everyone wants to
write the next killer application with Python, XML parsers, image
manipulators, super computer steering modules, yet no one wants to work on
making Python perform where it matters most. Python is the best language at
eclectic stuff, however, poor at bread and butter tasks.
Python needs better leadership in areas of its growth. Python is truly the
best language in use today, except it still isn't very useful for the
largest solution sector, database access, and information presentation (web,
or otherwise).
It seems that Python should strive to be great at the ABC's before it
attempts poetry.
--Ed
Chris Gonnerman
From: "Edward B. Wilson II" <e...@ewilson.com>
> I have been following Python for five years now, and I am still just as
> frustrated with it as I was in 1996.
>
> Python still doesn't have good database support,
What exactly is "good database support?" I haven't had a problem.
> nor has it grown to be
> useful in the web space as mod_perl.
mod_perl is unlikely to be useful to me since I can't stand the
mess that Perl programmers call source code. I suspect that many
Python programmers would agree.
> PyApache has been around longer than
> mod_php, yet php has far surpassed it as a productivity tool in the web
> space.
I'm not a Zope user myself, but from what I've read about both PHP
and Zope, it appears they are pretty much even in capability (hopefully
an expert on the subject will comment here).
> It would seem Python can do everything, yet nothing. Everyone wants to
> write the next killer application with Python, XML parsers, image
> manipulators, super computer steering modules, yet no one wants to work on
> making Python perform where it matters most. Python is the best language
at
> eclectic stuff, however, poor at bread and butter tasks.
This seems a bit broad to me. I use Python all the time; when I am forced
to use another language I always see exactly why I don't like them.
When am I forced? Sadly it seems that integrating any other language
directly into MS Access is out of the question. (Am I wrong? Someone
please tell me if I am!)
The only other time is when I must work with dBase tables... but I would
hardly typify that as not being "good database support".
> Python needs better leadership in areas of its growth. Python is truly
the
> best language in use today, except it still isn't very useful for the
> largest solution sector, database access, and information presentation
(web,
> or otherwise).
Here again, database access and information presentation aren't a problem
to me... is anyone else here having trouble with this?
Cristian Echeverria
news:MNS%6.355$Xs4.2...@news.pacbell.net...
> I have been following Python for five years now, and I am still just as
> frustrated with it as I was in 1996.
>
Of cource I don´t agree with this, because I sell database solution
implemented with python with great results. With Python you have great ODBC
support and a choice for almost any vendor out there.
Alex Martelli
news:mailman.994049882...@python.org...
...
> When am I forced? Sadly it seems that integrating any other language
> directly into MS Access is out of the question. (Am I wrong? Someone
> please tell me if I am!)
Depends what you mean by "directly". With COM and ActiveScripting,
it's generally not a problem to use Python or other AS-compliant languages
with any Office or other Automation-enabled app, albeit with a simple
passage through VBA or VBScript.
> The only other time is when I must work with dBase tables... but I would
> hardly typify that as not being "good database support".
http://www.stud.ifi.uio.no/~larsga/download/python/
or mxODBC + the dBase/clipper/foxpro ODBC drivers, or...?
Alex
Arnaud Fontaine
Gonnerman" <chris.g...@newcenturycomputers.net> wrote:
> ----- Original Message -----
> From: "Edward B. Wilson II" <e...@ewilson.com>
>> Python still doesn't have good database support,
>
> What exactly is "good database support?" I haven't had a problem.
I just want to add my voice here : I use Python with databases everyday and
don't have any problem (maybe because I NEVER work with poor MS
products)
> mod_perl is unlikely to be useful to me since I can't stand the mess
> that Perl programmers call source code. I suspect that many Python
> programmers would agree.
One of the reason I left Perl away for Python.
> I'm not a Zope user myself, but from what I've read about both PHP and
> Zope, it appears they are pretty much even in capability (hopefully an
> expert on the subject will comment here).
I use both in production.
Zope alone (not as CGI) is a great product, really good for most web based
application and its asynchronous approach makes it really efficient on the
IO aspect. Add to this its caching feature and you have one of the best
web product around.
PHP is, to my eyes, easier. Maybe because I've been using it for years
(it was still called PHP/FI and just hit version 2). You have a bunch of
lib with PHP so you can interact with most of the major products onthe
market. It handle nicely the load and is really well embeded in Apache.
But PHP as a langage is not as good as Python.
So, use the product you like ... but remember PHP is just a langage and
most of its power comes from Apache. Zope is more than that.
I've been running some benchmarks using ab to compare PHP/Apache/Mysql
with Zope on a simple application (a simple ppl directory : 1 static home
page, a database with contacts, 1 form to query the DB). I haven't kept
the numbers but both compared. Apache was a little better to serve the
static page but Zope handled the load better querying the database
(thanks to its caching feature).
-Arnaud
alan runyan
I think this is mostly due to the lack of centralization of python software
(ala CPAN). I believe there are stable python modules to access pretty much
any database: oracle, odbc, sybase, bsdb (sleepycat), solid, postgresql,
etc... I thought python's database support was weak, but when i needed it
it always came through.
> I'm not a Zope user myself, but from what I've read about both PHP
> and Zope, it appears they are pretty much even in capability (hopefully
> an expert on the subject will comment here).
I'm far from an expert, but.. I do have an opinion. From what I've seen in
PHPland, ZOPE compares pretty much feature-for-feature and then some!. ZOPE
is a larger more comprehensive framework than any PHP 'framework' that
exists (including eGrail or phpGroupware). Remember: PHP is a web
programming language. Python is a general purpose language. ZOPE is a
python framework. IMHO, Zope has suffered popularity because it refuses to
embed python (code) into the presentation layer (unlike PHP). Also ZOPE is
100% object-oriented. PHP isnt OO and reusibility is garnished from lots of
#includes (where as ZOPE has access to Pythons lib and ZOPE accessories and
there is hooks into using Perl from ZOPE also.. so you get Perl's DB support
as well). PHP is faster, but it doesnt stack up in reusability, speed of
development, or flexibility (Python as you mentioned, we all consider to be
the best language on the net ;) in language design. also, the ZODB is being
wheened off of ZOPE dependency and is starting to show signs of Standalone
distribution. this is a __HUGE__ win for Python -- a trivially easy to use
object database.
> > Python needs better leadership in areas of its growth. Python is truly
> the
> > best language in use today, except it still isn't very useful for the
> > largest solution sector, database access, and information presentation
> (web,
> > or otherwise).
uhm. I completely disagree.
information presentation I believe is fully covered by Python, nothing (that
I know of) comes close to the bredth of GUI support in Python: QT, GDK,
wxPython, TkInter, ?FOX?, and there are others! oh including Swing via
Jython. On the web scene there is healthy competition: WebWare (which is
modelled after Java's Servlet design), ZOPE (which is a highly evolved
framework that comes with a transactional object database), Quixote and
quite a few others. HTMLGen. I believe mod_snake (?) is being kept up.
There is a hook into the Ars Digita system via Python. I believe you can
present information using python in a myriad of ways -- its your choice ;)
~runyaga
Gilles Lenfant
But there is a full featured DBI 2.0 API spec and lot of addon DB packages
compliant with this spec.
This API is very simple and the Python power makes it easy to put an object
layer above the database (persistant objects). Can you do it in Perl.
For Web development, AFAIK Zope is the best open source solution for content
management with a built-in object database. Zope is not done in Perl or PHP
but in Python (95%).
If you find a better solution than the pythonic one, please let us know.
--Gilles
Armin Steinhoff
>
>I have been following Python for five years now, and I am still just as
>frustrated with it as I was in 1996.
>
>Python still doesn't have good database support,
IMHO ... if something is dead, then it's your perception :)
Here some database links ... out of the reality.
http://www.oraclepower.com/isapi/orapower.dll?AID=SC&CAT_ID=1166
http://starship.python.net/crew/sturner/informixdb.html
http://object-craft.com.au/projects/sybase/
http://www.druid.net/pygresql/
http://www.zope.org/Members/adustman/Products/MySQLdb
http://www.python.org/topics/database/DatabaseAPI-2.0.html
http://www.lemburg.com/files/python/mxODBC.html
http://www.ziclix.com/zxjdbc/
http://www.chordate.com/gadfly.html
http://clientes.netvisao.pt/luiforra/gvib/
http://www.equi4.com/metakit/python.html
http://pybsddb.sourceforge.net/
Armin
Gerhard Häring
>In article <MNS%6.355$Xs4.2...@news.pacbell.net>, "Edward says...
>>
>>I have been following Python for five years now, and I am still just as
>>frustrated with it as I was in 1996.
>>
>>Python still doesn't have good database support,
>
>IMHO ... if something is dead, then it's your perception :)
>
>Here some database links ... out of the reality.
>
>http://www.oraclepower.com/isapi/orapower.dll?AID=SC&CAT_ID=1166
>http://starship.python.net/crew/sturner/informixdb.html
>http://object-craft.com.au/projects/sybase/
>http://www.druid.net/pygresql/
>http://www.zope.org/Members/adustman/Products/MySQLdb
>http://www.python.org/topics/database/DatabaseAPI-2.0.html
>http://www.lemburg.com/files/python/mxODBC.html
>http://www.ziclix.com/zxjdbc/
>http://www.chordate.com/gadfly.html
>http://clientes.netvisao.pt/luiforra/gvib/
>http://www.equi4.com/metakit/python.html
>http://pybsddb.sourceforge.net/
For more, go here:
http://www.dmoz.org/Computers/Programming/Languages/Python/Modules/Database/
If you have one that isn't there, submit it :-)
Gerhard
--
mail: gerhard <at> bigfoot <dot> de registered Linux user #64239
web: http://highqualdev.com public key at homepage
public key fingerprint: DEC1 1D02 5743 1159 CD20 A4B6 7B22 6575 86AB 43C0
reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))
Gerhard Häring
>I have been following Python for five years now, and I am still just as
>frustrated with it as I was in 1996.
>
>Python still doesn't have good database support, nor has it grown to be
>useful in the web space as mod_perl. PyApache has been around longer than
>mod_php, yet php has far surpassed it as a productivity tool in the web
>space.
PHP is IMHO even worse a programming language than Perl. The main difference
may be that there is a company behind PHP, whereas there are AFIK no sponsors
of mod_python and mod_snake development (you know about these and not only
about PyApache, do you?).
I have had no problems with Python's database support, yet I didn't push it to
the limits yet (only did simple stuff). There is at least one Python database
module available for any major database that I know of.
>Python needs better leadership in areas of its growth. Python is truly the
>best language in use today, except it still isn't very useful for the
>largest solution sector, database access, and information presentation (web,
>or otherwise).
There are tons of modules available for these sectors. Do you think that they
are all buggy or lack important features?
Chris Gonnerman
From: "Alex Martelli" <ale...@yahoo.com>
> "Chris Gonnerman" <chris.g...@newcenturycomputers.net> wrote in
message
> news:mailman.994049882...@python.org...
> ...
> > When am I forced? Sadly it seems that integrating any other language
> > directly into MS Access is out of the question. (Am I wrong? Someone
> > please tell me if I am!)
>
> Depends what you mean by "directly". With COM and ActiveScripting,
> it's generally not a problem to use Python or other AS-compliant languages
> with any Office or other Automation-enabled app, albeit with a simple
> passage through VBA or VBScript.
Define "simple"... what I want is to drop in Python in place of VBA. I'm
still not sure it's possible.
> > The only other time is when I must work with dBase tables... but I would
> > hardly typify that as not being "good database support".
>
> http://www.stud.ifi.uio.no/~larsga/download/python/
I can't get this URL to work... I am getting Forbidden errors.
Lyle Johnson
Kris J. Zaragoza
dive in anyway. :-)
On Sun, 1 Jul 2001 21:42:37 -0700, Edward B. Wilson II <e...@ewilson.com> wrote:
>I have been following Python for five years now, and I am still just as
>frustrated with it as I was in 1996.
>
>Python still doesn't have good database support, nor has it grown to be
>useful in the web space as mod_perl. PyApache has been around longer than
>mod_php, yet php has far surpassed it as a productivity tool in the web
>space.
It seems that you are completely ignoring both mod_snake and
mod_python, both of which offer all the power of mod_perl. You are
also ignoring the wealth of database drivers available for Python, as
others in this thread have already attested to.
>It would seem Python can do everything, yet nothing. Everyone wants to
>write the next killer application with Python, XML parsers, image
>manipulators, super computer steering modules, yet no one wants to work on
>making Python perform where it matters most. Python is the best language at
>eclectic stuff, however, poor at bread and butter tasks.
Here is your fundamental error: You are assuming that everyone else
sees Python from your point of view. For many people, XML parsers,
image analysis and manipulation, and heavy numerical work ARE bread
and butter tasks. There are many people working within corporations
and research institutions that couldn't care less about spitting out
web pages. What you consider to be extremely important is simply
trivial or completely unimportant to others.
>
>Python needs better leadership in areas of its growth. Python is truly the
>best language in use today, except it still isn't very useful for the
>largest solution sector, database access, and information presentation (web,
>or otherwise).
>
>It seems that Python should strive to be great at the ABC's before it
>attempts poetry.
I think that Python's leadership (specifically Guido) has been doing a
fantastic job. The powers that be have avoided trying to pigeon-hole
Python into one particular application area, instead making it useful
to a broader audience of software developers. It is this flexibility
that makes Python so incredibly useful, in my opinion.
I myself use Python for a variety of tasks. It scales down nicely to
simple scripting tasks, and scales up to heavy data analysis and
manipulation using relational databases. I use Python for "bread and
butter" work that has nothing to do with generating web pages. I'm
even using the Jython implementation in a production order processing
environment and haven't seen a single hiccup. Python gives me all the
power and flexibility I need to get my job done.
-Kris
--
Kris J. Zaragoza | "Unfortunately, most people can't out-think a
kzar...@mediaone.net | grapefruit." --Jon Bodner
Joe Potter
>This strikes me as flamebait, but I'll put on my asbestos suit and
>dive in anyway. :-)
>
>On Sun, 1 Jul 2001 21:42:37 -0700, Edward B. Wilson II <e...@ewilson.com> wrote:
>>I have been following Python for five years now, and I am still just as
>>frustrated with it as I was in 1996.
>>
>>Python still doesn't have good database support, nor has it grown to be
>>useful in the web space as mod_perl. PyApache has been around longer than
>>mod_php, yet php has far surpassed it as a productivity tool in the web
>>space.
>
<snip>
>>
>>It seems that Python should strive to be great at the ABC's before it
>>attempts poetry.
>
>I think that Python's leadership (specifically Guido) has been doing a
>fantastic job. The powers that be have avoided trying to pigeon-hole
>Python into one particular application area, instead making it useful
>to a broader audience of software developers. It is this flexibility
>that makes Python so incredibly useful, in my opinion.
>
For example, one lone programmer (as I understand it) wrote a nice SQL
server/client entirely in Python. This would be Gadfly.
Talk about your scaling up and down.
>
>I myself use Python for a variety of tasks. It scales down nicely to
>simple scripting tasks, and scales up to heavy data analysis and
>manipulation using relational databases. I use Python for "bread and
>butter" work that has nothing to do with generating web pages. I'm
>even using the Jython implementation in a production order processing
>environment and haven't seen a single hiccup. Python gives me all the
>power and flexibility I need to get my job done.
>
>-Kris
Regards, Joe
François Pinard
> PHP is IMHO even worse a programming language than Perl [...]
When I needed dynamic Web pages, I took a few days to see things available
in Python, and many things I found indeed. From simple things (sometimes
quite clever) to the ambitious ZOPE. I also looked at SSI, and various other
avenues. Despite PHP has many good ideas, I was rather rebuked by the
aspect of the language.
I merely decided to make an ad hoc tool for my Web designers, inspired
from Python for the overall flow of preprocessing conditional and loops,
but also allowing tight Python for more serious tasks, database access,
and such. I called my tool `traiter', short of a better name; I wrote the
first draft in half a day. I polished it afterwards as needed, probably
a few weeks overall. It has been very satisfying to us so far.
Since the tool was essentially simple, I did not thought about publishing it,
as I presumed others could also do similar things as fast as I did this one.
In fact, I acquired the opinion at the time that Python is just the proper
tool for implementing dynamic Web pages simply, and that it was probably
not worth debating the virtues of similar tools, nor harassing potential
users with such debates. (I keep ZOPE aside as a notable special case, as
it is a whole framework, not just a quickly made tool like mine and others'.)
Yet, sometimes, I wonder if I should not document `traiter' and make it
available, just as a kind of reply to those who seem do consider Python
bad if they have to write a few lines of it to get their Web job done! :-)
Documenting `traiter' does not attract me much, as my actual users do not
read English. I should at least write French documentation. Currently,
my users just walk in my office when they have a question or a need...
Documenting `traiter' would be more about its setup, and the good tricks that
make it so useful, as these are usually not apparent solely from its code.
--
François Pinard http://www.iro.umontreal.ca/~pinard
Martijn Faassen
> frustrated with it as I was in 1996.
And 'is Python dead' will guarantee you people will read your post.
> Python still doesn't have good database support,
I realize I'm not familiar with Perl's dbi, which I hear is more powerful
than Python's database interfacing, but I've happily connected
Python to things like Access, MySQL and PostgreSQL. Also from
within Zope. What do you consider to be 'good database support'?
> nor has it grown to be
> useful in the web space as mod_perl. PyApache has been around longer than
> mod_php, yet php has far surpassed it as a productivity tool in the web
> space.
What about Zope, Quixote, WebWare? I mean, really, this is an area which
has seen a lot of growth in recent years.
http://www.zope.org
http://www.mems-exchange.org/software/python/quixote/
http://webware.sourceforge.net/
And then there's this:
where you can find much more web related stuff, in case that wasn't enough.
> It would seem Python can do everything, yet nothing. Everyone wants to
> write the next killer application with Python, XML parsers, image
> manipulators, super computer steering modules, yet no one wants to work on
> making Python perform where it matters most. Python is the best language at
> eclectic stuff, however, poor at bread and butter tasks.
You'll just have to be more specific about this..
> Python needs better leadership in areas of its growth. Python is truly the
> best language in use today, except it still isn't very useful for the
> largest solution sector, database access, and information presentation (web,
> or otherwise).
But those areas are exactly what I've been using it for the last couple
of years! Surely I would've noticed it if Python was dead. :)
Of course, some things could be nicer (relational object
integration would be nice), and as have been discussed recently,
the Python Standard Library could've seen some more development.
Also of course a comprehensive Python Catalog ala CPAN would be nice.
But really, either you've managed to miss an amazing amount of developments
the last few years (really, had you missed Zope?), or your post here
was rather unclear -- what exactly is it that you're missing?
Regards,
Martijn
--
History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?
Martijn Faassen
[snip]
>> The only other time is when I must work with dBase tables... but I would
>> hardly typify that as not being "good database support".
> http://www.stud.ifi.uio.no/~larsga/download/python/
> or mxODBC + the dBase/clipper/foxpro ODBC drivers, or...?
You can use the ODBC that comes with PythonWin to access dBase
tables, in fact. I've done so in the past. Windows comes with dBase
drivers for ODBC by default.
Alex Martelli
...
> > "Chris Gonnerman" <chris.g...@newcenturycomputers.net> wrote in
> message
> > news:mailman.994049882...@python.org...
> > ...
> > > When am I forced? Sadly it seems that integrating any other language
> > > directly into MS Access is out of the question. (Am I wrong? Someone
> > > please tell me if I am!)
> >
> > Depends what you mean by "directly". With COM and ActiveScripting,
> > it's generally not a problem to use Python or other AS-compliant
languages
> > with any Office or other Automation-enabled app, albeit with a simple
> > passage through VBA or VBScript.
>
> Define "simple"... what I want is to drop in Python in place of VBA. I'm
> still not sure it's possible.
I agree it's not possible to "drop in Python _in place of_ VBA" -- tricking
MS Access (or other office app) into using other DLL's in lieu of the
ones it's linked-to would be anything BUT simple (or solid:-). What I
do mean by "simple" is, the (e.g.) code that responds to the (whatever)
event is still in VBA, but all it does is delegate the call right to a
Python object.
> > > The only other time is when I must work with dBase tables... but I
would
> > > hardly typify that as not being "good database support".
> >
> > http://www.stud.ifi.uio.no/~larsga/download/python/
>
> I can't get this URL to work... I am getting Forbidden errors.
Darn, it's giving forbidden errors to me too, right now, it worked
the other day. I haven't tried it, but maybe http://www.fiby.at/dbfpy.tgz
may help you -- or perhaps the idea of using ODBC (or ADO/OleDB, etc)
to access the dBase files remains better.
Alex
Alex Martelli
...
> > > > The only other time is when I must work with dBase tables... but I
> would
> > > > hardly typify that as not being "good database support".
> > >
> > > http://www.stud.ifi.uio.no/~larsga/download/python/
> >
> > I can't get this URL to work... I am getting Forbidden errors.
>
> Darn, it's giving forbidden errors to me too, right now, it worked
> the other day. I haven't tried it, but maybe http://www.fiby.at/dbfpy.tgz
> may help you -- or perhaps the idea of using ODBC (or ADO/OleDB, etc)
> to access the dBase files remains better.
Oh, and, what about http://sourceforge.net/projects/xdb/? Now
renamed to XBase, I'm told, but apparently the URL still has
XDB in it. Haven't checked it, but they claim support for C++,
Perl and Python.
Alex
Kemp Randy-W18971
Regards,
Roman Suzi
Once we tried 3 databases (MySQL, PostgreSQL, Interbase) to suit our task.
And for every database (we stopped at Interbase) there was Python support.
However, my collegues were not satisfied with it. One somplain was that in
ASP/IIS it is "very easy" to receive a "recordset" from database and then
apply it in different situations in the ASP-page, because recordset is an
object and even subqueries could be made without quering DB again.
From this and also from my own experience with PostgeSQL queries from
Python, I could say that DB support in Python exists, but need enhancement
and standartization. Probably, higher level more or less common
object-oriented interfaces could help this.
I must also say, that I myself am completely satisfied with Python DB
support, but I do not use DB extentensively and routinely to judge.
However, I think that including some more DB support, at least for open
source databases like Postgresql and MySQL + ODBC/JDBC, could be a good
idea and will give a standard. (Yes, I know about Python DB API).
Are there licensing problems or what stops from letting RDB support
modules into standard library?
Sincerely yours, Roman Suzi
--
_/ Russia _/ Karelia _/ Petrozavodsk _/ r...@onego.ru _/
_/ Monday, July 02, 2001 _/ Powered by Linux RedHat 6.2 _/
_/ "Catalyze: To lie while looking cute." _/
Eduard Hiti
| Oh, and, what about http://sourceforge.net/projects/xdb/? Now
| renamed to XBase, I'm told, but apparently the URL still has
| XDB in it. Haven't checked it, but they claim support for C++,
| Perl and Python.
Unfortunately support for various scripting languages, including Python, is
still on the To Do-list (at least on their home page)
David Bolen
> However, my collegues were not satisfied with it. One somplain was that in
> ASP/IIS it is "very easy" to receive a "recordset" from database and then
> apply it in different situations in the ASP-page, because recordset is an
> object and even subqueries could be made without quering DB again.
Just curious, but did your colleagues try using Python's COM interface
to ADO to retrieve an actual recordset object that they could
manipulate the same in Python as in other ASP languages?
At least under Windows, it would seem that having solid ODBC and COM
support should pretty much cover in Python anything you'd do elsewhere.
On other environments, direct support for a particular database is
likely to be more desirable, as it's more typical in those
environments, but as you've noted, there's a plethora of support
modules for various databases - some at various levels.
--
-- David
--
/-----------------------------------------------------------------------\
\ David Bolen \ E-mail: db...@fitlinxx.com /
| FitLinxx, Inc. \ Phone: (203) 708-5192 |
/ 860 Canal Street, Stamford, CT 06902 \ Fax: (203) 316-5150 \
\-----------------------------------------------------------------------/
Alex Martelli
news:mailman.994100826...@python.org...
> It seems I start to understand database concerns of Mr. Wilson the second.
>
> Once we tried 3 databases (MySQL, PostgreSQL, Interbase) to suit our task.
> And for every database (we stopped at Interbase) there was Python support.
>
> However, my collegues were not satisfied with it. One somplain was that in
> ASP/IIS it is "very easy" to receive a "recordset" from database and then
Internet Information Server (IIS) serves webpages, including Active
Server Pages (ASP), but neither has anything to do with database access.
What you're using to access databases in such a setting is most likely
MSDAC (MicroSoft Data Access Controls, I believe) and specifically the
ADO (Active Data Objects, I believe) part thereof. So if that's what you
like, why not access it from Python? I happen to like it quite a bit too,
and as it happens Python + win32all makes it a snap to use it (on a
Win32 platform, only, of course -- but then, that's where IIS runs, too,
or has MS released it for OpenBSD lately?-).
> apply it in different situations in the ASP-page, because recordset is an
> object and even subqueries could be made without quering DB again.
Yep, the recordset part of ADO is undoubtedly the most popular single
feature of it among us lazy programmers. You can even disconnect from
the DB and keep the recordset around, persist it to a file (maybe in XML),
depersist it later... it's fun!-)
> From this and also from my own experience with PostgeSQL queries from
> Python, I could say that DB support in Python exists, but need enhancement
> and standartization. Probably, higher level more or less common
> object-oriented interfaces could help this.
It seems to me the (DB API 2) standard is fine (maybe a bit too
ambitious, so actual implementations may not have reached up
to it yet?-).
> I must also say, that I myself am completely satisfied with Python DB
> support, but I do not use DB extentensively and routinely to judge.
> However, I think that including some more DB support, at least for open
> source databases like Postgresql and MySQL + ODBC/JDBC, could be a good
> idea and will give a standard. (Yes, I know about Python DB API).
And? What's wrong with it? What support would you get from ODBC,
portably between Postgres & MySQL, that the relevant DB API modules
don't supply? Maybe we could supply an ADO-recordset-workalike on
top of any DB API compliant implementation, that might be handy at
times I guess. But hardly a make-or-break thing, no?
> Are there licensing problems or what stops from letting RDB support
> modules into standard library?
Why would I want to have to download support for many databases
I don't use each and every time I download Python? It's bad enough
getting the Irix or Mac stuff as a part of my (e.g.) Windows d'load --
why would I want Postgres and/or MySQL and/or Oracle and/or SQL
Server and/or (&c) if what I end up using is Interbase (as you did)?
If I had a vote, I'd rather seen _Gadfly_ tuned up (out with regex
and regsub, in favour of re; minimal-tolerance support of stuff it
does not implement, such as NULLs) and made a part of Python. It
might give a taste of SQL to SQL-unaware programmers and it would
provide a DB API implementation (usable like dumbdbm is as the
last-choice fallback for anydbm, if you see what I mean). But it sure
wouldn't be THE db of choice for demanding professional use -- go
see Oracle or SQL Server for that, or maybe Interbase, MySQL &c if
that's what rocks your boat. The DB scene seems just too fragmented
at this point in time to warrant including support for 10% of it in
the standard Python library, I think...
Alex
jasper van putten
> It seems I start to understand database concerns of Mr. Wilson the second.
>
> Once we tried 3 databases (MySQL, PostgreSQL, Interbase) to suit our task.
> And for every database (we stopped at Interbase) there was Python support.
>
> However, my collegues were not satisfied with it. One somplain was that in
> ASP/IIS it is "very easy" to receive a "recordset" from database and then
> apply it in different situations in the ASP-page, because recordset is an
> object and even subqueries could be made without quering DB again.
>
<snip>
you can use ADO and DAO in python too.
there is some documention about in "python programming on win32". I think
that there was a site about it too somewhere.
Jasper
Jaap Spies
> It seems that Python should strive to be great at the ABC's before it
> attempts poetry.
>
> --Ed
>
You should know that the roots of Python are in the ABC Programming
Language and
as I mentioned before reading/writing Python is really Poetry!
Jaap Spies
SteveN
Zen
>Yep, the recordset part of ADO is undoubtedly the most popular single
>feature of it among us lazy programmers. You can even disconnect from
>the DB and keep the recordset around, persist it to a file (maybe in XML),
>depersist it later... it's fun!-)
I'm preparing a PEP to address a few issues with the Python DB API
and an initial draft has been presented to the DB-SIG.
I'm unfamiliar with ADO. When you retrieve a recordset, are all
relevant tuples retrieved from the database (like the Cursor.fetchall()
method in the DB API)? Or is it a lazy object that only downloads
the rows when they are accessed by the application (like the Cursor.fetch()
or Cursor.fetchmany() methods in the DB API)?
Can you provide examples of things you can do using the ADO interface
(don't care what programming language) that are difficult to do using
the Python DB API? Even if it is outside the scope of *this* PEP, I need
to understand peoples wishlists to ensure they can be integrated
in the future.
>> From this and also from my own experience with PostgeSQL queries from
>> Python, I could say that DB support in Python exists, but need enhancement
>> and standartization. Probably, higher level more or less common
>> object-oriented interfaces could help this.
>It seems to me the (DB API 2) standard is fine (maybe a bit too
>ambitious, so actual implementations may not have reached up
>to it yet?-).
The 2.0 driver implementations of the major databases seem fine to me.
One problem I notice with database tools is extremly rare for someone
to deal with more than three vendors RDBMS implementations, and generally
people only develop with one or two.
>> I must also say, that I myself am completely satisfied with Python DB
>> support, but I do not use DB extentensively and routinely to judge.
>> However, I think that including some more DB support, at least for open
>> source databases like Postgresql and MySQL + ODBC/JDBC, could be a good
>> idea and will give a standard. (Yes, I know about Python DB API).
>And? What's wrong with it? What support would you get from ODBC,
>portably between Postgres & MySQL, that the relevant DB API modules
>don't supply? Maybe we could supply an ADO-recordset-workalike on
>top of any DB API compliant implementation, that might be handy at
>times I guess. But hardly a make-or-break thing, no?
>If I had a vote, I'd rather seen _Gadfly_ tuned up (out with regex
>and regsub, in favour of re; minimal-tolerance support of stuff it
>does not implement, such as NULLs) and made a part of Python. It
I agree that it would be a benefit and worth a PEP if the
Gadfly author agrees and someone volunteers to do the
required tweaking.
I don't see a point in including drivers in the core for databases that
follow a different development cycle. Last thing we want is obsolete
PostgreSQL drivers out there when a new version of PostgreSQL is
released. Although PHP manages to do this.... can any PHP users comment?
Alex
> I don't understand why people are replying to this troll.
I didn't recognize it as such, at first. :)
Alex.
Roman Suzi
>Roman Suzi <r...@onego.ru> writes:
>
>> However, my collegues were not satisfied with it. One somplain was that in
>> ASP/IIS it is "very easy" to receive a "recordset" from database and then
>> apply it in different situations in the ASP-page, because recordset is an
>> object and even subqueries could be made without quering DB again.
>
>Just curious, but did your colleagues try using Python's COM interface
>to ADO to retrieve an actual recordset object that they could
>manipulate the same in Python as in other ASP languages?
Aha! Now I could understand what is the brake of Python library
development. Most of Python users are Windows users. And they
have COM for whatever is in their system.
>At least under Windows, it would seem that having solid ODBC and COM
>support should pretty much cover in Python anything you'd do elsewhere.
>
>On other environments, direct support for a particular database is
>likely to be more desirable, as it's more typical in those
>environments, but as you've noted, there's a plethora of support
>modules for various databases - some at various levels.
We mostly have Linux servers, so COM+ADO is no option. The point was not
to choose between Windows and Linux, ASP was choosen to serve particular
purpose, for the database already implemented in Microsoft land.
>--
>-- David
Sincerely yours, Roman Suzi
--
_/ Russia _/ Karelia _/ Petrozavodsk _/ r...@onego.ru _/
_/ Tuesday, July 03, 2001 _/ Powered by Linux RedHat 6.2 _/
_/ "Paranoia is nothing to be afraid of!!" _/
Chris Gonnerman
> >
> > I can't get this URL to work... I am getting Forbidden errors.
>
> Darn, it's giving forbidden errors to me too, right now, it worked
> the other day. I haven't tried it, but maybe http://www.fiby.at/dbfpy.tgz
> may help you -- or perhaps the idea of using ODBC (or ADO/OleDB, etc)
> to access the dBase files remains better.
I went up the URL until I got to the root http://www.stud.ifi.uio.no/
and got a page described as:
Institutt for informatikks studentserver
I don't read the language, but I'd say that last word is pretty clear
even to an English-speaker like myself. I guess that "larsqa" is out
of school by now. I get redirected to "lmariusg's" homepage before
getting the "Forbidden" error.
Bummer.
Roman Suzi
>"Roman Suzi" <r...@onego.ru> wrote in message
>news:mailman.994100826...@python.org...
>> It seems I start to understand database concerns of Mr. Wilson the second.
>>
>> Once we tried 3 databases (MySQL, PostgreSQL, Interbase) to suit our task.
>> And for every database (we stopped at Interbase) there was Python support.
>>
>> However, my collegues were not satisfied with it. One somplain was that in
>> ASP/IIS it is "very easy" to receive a "recordset" from database and then
>
>Internet Information Server (IIS) serves webpages, including Active
>Server Pages (ASP), but neither has anything to do with database access.
>
>What you're using to access databases in such a setting is most likely
>MSDAC (MicroSoft Data Access Controls, I believe) and specifically the
>ADO (Active Data Objects, I believe) part thereof. So if that's what you
>like, why not access it from Python? I happen to like it quite a bit too,
>and as it happens Python + win32all makes it a snap to use it (on a
>Win32 platform, only, of course -- but then, that's where IIS runs, too,
>or has MS released it for OpenBSD lately?-).
Yes, ADO is what I meant.
With the recent object-orientation hype, Windows looks more attractive to
developers than UNIX. Probably ADO adds to it.
>> apply it in different situations in the ASP-page, because recordset is an
>> object and even subqueries could be made without quering DB again.
>
>Yep, the recordset part of ADO is undoubtedly the most popular single
>feature of it among us lazy programmers. You can even disconnect from
>the DB and keep the recordset around, persist it to a file (maybe in XML),
>depersist it later... it's fun!-)
I have not tried Zope (it's overkill for our tasks) but I think
Zope must have something similar.
>> From this and also from my own experience with PostgeSQL queries from
>> Python, I could say that DB support in Python exists, but need enhancement
>> and standartization. Probably, higher level more or less common
>> object-oriented interfaces could help this.
>
>It seems to me the (DB API 2) standard is fine (maybe a bit too
>ambitious, so actual implementations may not have reached up
>to it yet?-).
>
>> I must also say, that I myself am completely satisfied with Python DB
>> support, but I do not use DB extentensively and routinely to judge.
>> However, I think that including some more DB support, at least for open
>> source databases like Postgresql and MySQL + ODBC/JDBC, could be a good
>> idea and will give a standard. (Yes, I know about Python DB API).
>
>And? What's wrong with it?
According to some individuals here it makes Python dead snake :-))))
>What support would you get from ODBC,
>portably between Postgres & MySQL, that the relevant DB API modules
>don't supply? Maybe we could supply an ADO-recordset-workalike on
>top of any DB API compliant implementation, that might be handy at
>times I guess. But hardly a make-or-break thing, no?
>> Are there licensing problems or what stops from letting RDB support
>> modules into standard library?
>
>Why would I want to have to download support for many databases
>I don't use each and every time I download Python? It's bad enough
>getting the Irix or Mac stuff as a part of my (e.g.) Windows d'load --
>why would I want Postgres and/or MySQL and/or Oracle and/or SQL
>Server and/or (&c) if what I end up using is Interbase (as you did)?
This is clever. Though ADO-like higher-level abstraction could
be useful.
>If I had a vote, I'd rather seen _Gadfly_ tuned up (out with regex
>and regsub, in favour of re; minimal-tolerance support of stuff it
>does not implement, such as NULLs) and made a part of Python.
Yes, this could be cool.
> It
>might give a taste of SQL to SQL-unaware programmers and it would
>provide a DB API implementation (usable like dumbdbm is as the
>last-choice fallback for anydbm, if you see what I mean). But it sure
>wouldn't be THE db of choice for demanding professional use -- go
>see Oracle or SQL Server for that, or maybe Interbase, MySQL &c if
>that's what rocks your boat. The DB scene seems just too fragmented
>at this point in time to warrant including support for 10% of it in
>the standard Python library, I think...
>Alex
Sincerely yours, Roman Suzi
Paul Prescod
behavior on comp.lang.python? Keep an eye out and don't bother
responding to anything inflammatory.
--
Take a recipe. Leave a recipe.
Python Cookbook! http://www.ActiveState.com/pythoncookbook
Aahz Maruch
Paul Prescod <pa...@ActiveState.com> wrote:
>
>Is anybody else suspicious about the sudden uptick of troll-like
>behavior on comp.lang.python? Keep an eye out and don't bother
>responding to anything inflammatory.
Partly. I think it's more the weather, though; William Park, for one,
has certainly been around here a while.
--
--- Aahz <*> (Copyright 2001 by aa...@pobox.com)
Hugs and backrubs -- I break Rule 6 http://www.rahul.net/aahz/
Androgynous poly kinky vanilla queer het Pythonista
"I'm not tense, i'm just terribly, terribly alert" --unknown
Alex Martelli
> On 2 Jul 2001, David Bolen wrote:
>
> >Roman Suzi <r...@onego.ru> writes:
> >
> >> However, my collegues were not satisfied with it. One somplain was that
in
> >> ASP/IIS it is "very easy" to receive a "recordset" from database and
then
> >> apply it in different situations in the ASP-page, because recordset is
an
> >> object and even subqueries could be made without quering DB again.
> >
> >Just curious, but did your colleagues try using Python's COM interface
> >to ADO to retrieve an actual recordset object that they could
> >manipulate the same in Python as in other ASP languages?
>
> Aha! Now I could understand what is the brake of Python library
> development. Most of Python users are Windows users. And they
> have COM for whatever is in their system.
I strongly doubt that "most Python users are Windows users", but
it's certainly true that most Python users *WHO CONSIDER ASP/IIS
AN ALTERNATIVE* are Windows users (and pretty-clueless ones, if
they don't know Python can work perfectly well WITHIN ASP/IIS!-).
> We mostly have Linux servers, so COM+ADO is no option. The point was not
> to choose between Windows and Linux, ASP was choosen to serve particular
> purpose, for the database already implemented in Microsoft land.
If COM+ADO is not an option then neither is ASP/IIS!
Alex
Roman Suzi
>"Roman Suzi" <r...@onego.ru> wrote in message
>news:mailman.994135925...@python.org...
>> On 2 Jul 2001, David Bolen wrote:
>>
>> >Roman Suzi <r...@onego.ru> writes:
>> >
>> >> However, my collegues were not satisfied with it. One somplain was that
>in
>> >> ASP/IIS it is "very easy" to receive a "recordset" from database and
>then
>> >> apply it in different situations in the ASP-page, because recordset is
>an
>> >> object and even subqueries could be made without quering DB again.
>> >
>> >Just curious, but did your colleagues try using Python's COM interface
>> >to ADO to retrieve an actual recordset object that they could
>> >manipulate the same in Python as in other ASP languages?
>>
>> Aha! Now I could understand what is the brake of Python library
>> development. Most of Python users are Windows users. And they
>> have COM for whatever is in their system.
>
>I strongly doubt that "most Python users are Windows users", but
>it's certainly true that most Python users *WHO CONSIDER ASP/IIS
>AN ALTERNATIVE* are Windows users (and pretty-clueless ones, if
>they don't know Python can work perfectly well WITHIN ASP/IIS!-).
Ok, I've not pushed the issue because people wanted to learn
ASP.
>> We mostly have Linux servers, so COM+ADO is no option. The point was not
>> to choose between Windows and Linux, ASP was choosen to serve particular
>> purpose, for the database already implemented in Microsoft land.
>
>If COM+ADO is not an option then neither is ASP/IIS!
I am sorry that I gave inaccurate description.
There were no point in installing Python just to serve 3-4
pages from IIS.
*
Anyway, I wanted to say that some generic (!=Windows only) ADO
could help for those who consider Python for tasks usually
done with PHP or ASP.
Probably it could be coupled with gadfly to make
subqueries possible.
Kemp Randy-W18971
and violets are blue,
I program in Python,
and so can you.
-----Original Message-----
From: Jaap Spies [mailto:j.s...@hccnet.nl]
Sent: Monday, July 02, 2001 5:12 PM
To: pytho...@python.org
Subject: Re: Is Python Dead?
Alex Martelli
...
> Anyway, I wanted to say that some generic (!=Windows only) ADO
> could help for those who consider Python for tasks usually
> done with PHP or ASP.
We seem to keep hitting a brickwall here. Let's try an analogy.
It's exactly as if somebody said "consider Fortran for tasks
usually done with Lisp or Unix". This is not an "alternative".
Fortran is a language. It runs within environments. Unix is
an environment within which some languages run. You do not
*CHOOSE BETWEEN* Fortran and Unix. You choose your language
and your environment, and it could, if you want, be Fortran
under Unix. If you like Fortran and you like Unix, go for it.
Of course Fortran also runs on many other environments (not
all) and Unix also runs many other languages (not all), but
that doesn't make them ALTERNATIVE to each other!!!
Now, it's EXACTLY the same situation: you say "consider Python
for tasks usually done with PHP or APS". This is not an
"alternative". Python is a language. It runs within environments.
ASP is an environment within which some languages run. You do
not *CHOOSE BETWEEN* Python and ASP. You choose your language
and your environment, and it could, if you want, be Python under
ASP. If you like Python and you like ASP, go for it. Of course
Python also runs on many other environments (not all) and ASP also
runs many other languages (not all), but that doesn't make them
ALTERNATIVE to each other!!!
*WHY* is it apparently so durned HARD?! Why do people keep
saying "ASP" as if it somehow IMPLIED a language choice when
one can perfectly well run any number of languages even on
the *SAME SINGLE* Active Server Page?! Microsoft brainwashing?
Anti-Microsoft brainwashing? I don't really understand. It's
clearer why people may believe that taking advantage of the
JVM and the huge amount of libraries for it somehow requires
coding in Java (it doesn't, of course - Python is a possible
alternative!), since Sun has done their best to blur the key
distinction between language and environment. But Microsoft
HAS been highlighting in glow-in-the-dark bright orance that
THEIR environments are FULLY multi-language, since day one.
Is Microsoft marketing really SO feeble that they still have
not been able to get THIS single VERY simple point across?!
If you're considering deploying Python on IIS, it really makes
no difference whether Python duplicates much of the powerful
infrastructure that you get on IIS anyway -- it's crucial that
Python lets you fully exploit that existing infrastructure, but
any duplications are mostly wasted effort.
If you're considering deploying Python or PHP on Apache in a
cross-platform way, or on some specific target system where
ADO is not available, then what you need to compare is not
either language vs ADO, but the languages and their libraries
with each other. I'm no PHP expert, but it appears to me that
the closest you get on PHP to a DB-independent interface is
as a part of PHPLib, e.g. cfr
http://phplib.netuse.de/documentation/documentation-3.html#ss3.1
After studying that page a bit, unless I'm missing something,
it appears to me that this interface is *VASTLY* inferior to
the Python DB API. In particular, there's nothing even
vaguely approaching the nice convenience functionality that
ADO supplies.
So *what* makes you think people are choosing PHP rather than
Python because of DB connectivity issues? Apparently they're
so choosing DESPITE Php's _inferiority_ in DB connectivity.
So, further enhancing the DB functionality of Python seems
unlikely to have any important effect in this regard.
It may very well be that it's worthwhile designing a higher
level, somewhat ADOlike superstructure on top of the DB API,
but, if so, then it DEFINITELY cannot be because of some
kind of "competition" between Python and PHP -- much less,
of course, "between Python and ASP", which is as peculiar a
"competition" as "between Python and Unix" or "between
Python and the JVM"...!!!
Alex
Neil Hodgson
> Is anybody else suspicious about the sudden uptick of troll-like
> behavior on comp.lang.python? Keep an eye out and don't bother
> responding to anything inflammatory.
Its that damned PSU - Martijn must have let something a little sensitive
out and they're flooding the group hoping to
Steve Holden
Violets are blue
Everyone knows
Four into nine gives two
regards
Steve
--
http://www.holdenweb.com/
"Kemp Randy-W18971" <Randy....@motorola.com> wrote in message
news:mailman.994164845...@python.org...
Steve Holden
the record sets returned by DB API compliantr modules so you can either:
a) Refer to fields as attributes of the db tuple, or
b) treat the db tuple as a dictionary and select fields a la ASP/ADO.
If your colleagues think VBScript database access is easy they are clearly
not pushing SQL to anywhere near its limits. Ask them how they would to the
equivalent of the DB API's
cursor.execute("SELECT f1, f2, f3 FROM table WHERE f4=? AND f5=?", (f4val,
f5val))
I think you'll find it's more than a little tricky. Also, in VBScript, if rs
is a recordset (with an implied current member), you have to access fields
using
rs("FieldName")
This is a bizarre way to reference things by name. If your colleagues see
this as natural then they have their Microsoft blinkers on. I have no
objection to them preferring ASP/ADO, and there are some nice tools
available which let you do some nifty things without having to hack too much
source (as long as you can ignore the resulting code bloat).
But Python is pretty good when it comes to databases, even without touching
ADO.
regards
Steve
"Roman Suzi" <r...@onego.ru> wrote in message
news:mailman.994135925...@python.org...
Roman Suzi
>"Roman Suzi" <r...@onego.ru> wrote in message
>news:mailman.994155184...@python.org...
> ...
>> Anyway, I wanted to say that some generic (!=Windows only) ADO
>> could help for those who consider Python for tasks usually
>> done with PHP or ASP.
>
>We seem to keep hitting a brickwall here. Let's try an analogy.
-skip Python vs. ASP -
I have not used ASP. (I must confess, I have not even looked into ASP
deeply and had no knowledge ASP could be used with other languages than
Basic (or whatever). My assumption was that ASP is like PHP.
Thanks for lesson!
>http://phplib.netuse.de/documentation/documentation-3.html#ss3.1
>After studying that page a bit, unless I'm missing something,
>it appears to me that this interface is *VASTLY* inferior to
>the Python DB API.
I do not believe it. PHP is so widely used with databases
that I cant believe it's database connectivity is that bad!
>It may very well be that it's worthwhile designing a higher
>level, somewhat ADOlike superstructure on top of the DB API,
>but, if so, then it DEFINITELY cannot be because of some
>kind of "competition" between Python and PHP -- much less,
>of course, "between Python and ASP", which is as peculiar a
>"competition" as "between Python and Unix" or "between
>Python and the JVM"...!!!
Sincerely yours, Roman Suzi
Kemp Randy-W18971
A quarter infraction (in fraction, get it),
This error in Python,
Would deserve drastic action.
-----Original Message-----
From: Steve Holden [mailto:sho...@holdenweb.com]
Sent: Tuesday, July 03, 2001 8:41 AM
To: pytho...@python.org
Subject: Re: Is Python Dead?
Roses are red
Violets are blue
Everyone knows
Four into nine gives two
regards
Steve
--
http://www.holdenweb.com/
Alex Martelli
news:3b4116e1$1...@mercury.its.rmit.edu.au...
> "Alex Martelli" <ale...@yahoo.com> writes:
>
> >Yep, the recordset part of ADO is undoubtedly the most popular single
> >feature of it among us lazy programmers. You can even disconnect from
> >the DB and keep the recordset around, persist it to a file (maybe in
XML),
> >depersist it later... it's fun!-)
>
> I'm preparing a PEP to address a few issues with the Python DB API
> and an initial draft has been presented to the DB-SIG.
>
> I'm unfamiliar with ADO. When you retrieve a recordset, are all
> relevant tuples retrieved from the database (like the Cursor.fetchall()
> method in the DB API)? Or is it a lazy object that only downloads
> the rows when they are accessed by the application (like the
Cursor.fetch()
> or Cursor.fetchmany() methods in the DB API)?
Yes. That is, you can program it either way, ot a bit of each
(see later).
> Can you provide examples of things you can do using the ADO interface
> (don't care what programming language) that are difficult to do using
> the Python DB API? Even if it is outside the scope of *this* PEP, I need
> to understand peoples wishlists to ensure they can be integrated
> in the future.
An ADO Recordset holds results from a datasource and implements
or delegates cursor behavior to the datasource. Once the Recordset
has some data, you can keep working with the Recordset (even in an
independent way from the datasource) -- navigate in it, modify it,
persist and depersist it... at some later time you may decide to
connect to the datasource again, and have the Recordset send an
'update' to the datasource regarding the modifications you did to
the Recordset while the datasource was away. It's *NOT* what I
would call a shining example of clean, minimalist, elegant OO
design. It *IS* deucedly handy and seductive as soon as you start
getting used to it, though:-).
One example of systematical, handy though inelegant, redundance.
Basically all parameters to methods are optional. If you do not
supply them, the object uses some of its properties as the
parameters. You can query and change the properties at some
time, and later call the methods without parameters and they'll
do the right thing, or pass some parameters and have only some
others default. Think of it as cheap and inelegant, but handy
and versatile, 'overridable currying'.
So take for example the Open method of a Recordset. It has an
argument Source (or that may default from the Source property
of the Recordset) which can be a Command object (which can
encapsulate several different ways to fetch data) or a text
string which, together with option flags, can be implicitly
used to build the suitable Command object (an URL, an SQL
statement, a Stream object containing a persisted Recordset,
etc, etc). An Options argument lets you specify several
things (again, you can use properties if you prefer) such
as the execution-and-fetching model:
adAsyncExecute fully asynchronous
adAsyncFetch synchronous for the first CacheSize rows,
then async for the rest (CS is a property)
adAsyncFetchNonBlocking like adAsyncFetch, but the attempt
to read a row not yet fetched won't block
adExecuteNoRecords no records are expected in response to
the command, the framework will throw away
any that might return (but shouldn't:-)
adExecuteStream the results are packaged up as a Stream
object
adExecuteRecord special-case: ONE, but only one, record is
returned as the result
Default is synchronous access, but the options, as you see,
are many. Indeed perhaps TOO many -- not all apply in all
situations, always a bad sign (e.g., adExecuteStream with a
Source that is NOT a Command object executing is an error).
But back to the Open verb. An argument ActiveConnection
lets you specify on what connection to open the recordset
(a Connection object, a string from which it can be
constructed, can default from the connection properties
of the recordset itself OR of the command object if you
have passed one as Source argument, etc).
And then you get to specify (still at Open time) what
kind of cursor-type and lock-type you desire. Which is
a big topic in itself. adOpenForwardOnly only lets you
move forward in the recordset, but is lightweight and
may afford optimization. At the other extreme, one can
adOpenDynamic and see committed (or even uncommitted,
if that's the isolation level for your transaction)
changes made by other users while the cursor is open.
The transparent get recordset/disconnect/persist the
recordset/depersist it later/worh with the recordset
(client-side cursor of course!)/persist it again/&c
and later reconnect and send the update (as just a
delta). All of the clientside software that displays
and edits the recordset doesn't even *know* whether
it's working on a live DB connection or in such a
disconnected edit-at-leisure scenario -- it's all
easily encapsulated. If I had to choose one big
convenience feature, I think that would be it.
Maybe we can get such a level of convenience WITHOUT
adopting the "richly redundant architecture" that is
so characteristic of ADO... laziness apart, having to
do things in one specific sequence rather than any
which way isn't half bad (easier to document and
explain, not to mention code and test, for example).
But apart from such issues there IS real power in
such a concept as "a temporarily disconnected and
possibly persisted recordset" and the ability to
operate polymorphically on either THAT, or a live DB
connection.
> >> From this and also from my own experience with PostgeSQL queries from
> >> Python, I could say that DB support in Python exists, but need
enhancement
> >> and standartization. Probably, higher level more or less common
> >> object-oriented interfaces could help this.
>
> >It seems to me the (DB API 2) standard is fine (maybe a bit too
> >ambitious, so actual implementations may not have reached up
> >to it yet?-).
>
> The 2.0 driver implementations of the major databases seem fine to me.
> One problem I notice with database tools is extremly rare for someone
> to deal with more than three vendors RDBMS implementations, and generally
> people only develop with one or two.
True. The specific DB-using product I currently consult for
(Think3's ThinkTeam PDM package) currently fully supports only
Oracle, SQL Server, and (ecch) Jet (aka "the Access DB") -- we've
more or less dropped Informix, Ingres &c as years went by. But
my dad's office still works on Watcom SQL (on DOS 3.1...), and
of course one has to keep evaluating new releases of such things
as MySQL, Interbase, etc, so I try to keep current on more RDBMS's
than are strictly necessary for my job. And emerging standards...
> >If I had a vote, I'd rather seen _Gadfly_ tuned up (out with regex
> >and regsub, in favour of re; minimal-tolerance support of stuff it
> >does not implement, such as NULLs) and made a part of Python. It
>
> I agree that it would be a benefit and worth a PEP if the
> Gadfly author agrees and someone volunteers to do the
> required tweaking.
But would then Gadfly be included in the standard Python
distribution if so tuned-up and tweaked? If it's to remain
an isolated module the motivation to go and clean it up
is an order of magnitude lessened, I think. Having Gadfly
in the distribution would really enhance the "batteries
included" part of Python's appeal...!!!
Of course, it would have to be made clear in the docs that
Gadfly is great for small problems but that you can scale
up your programs to other (compatible) DB interfaces and
put a DB engine behind them, etc, etc.
> I don't see a point in including drivers in the core for databases that
> follow a different development cycle. Last thing we want is obsolete
> PostgreSQL drivers out there when a new version of PostgreSQL is
> released. Although PHP manages to do this.... can any PHP users comment?
I would hope major DB vendors keep compatibility in their
next releases with programs developed to their previous
API's...! My objection would be another -- if there are
a dozen major RDBMS's and I, as a typical user, care about
1 or 2, why would I want to download the other 10 or so
at each Python upgrade?
Alex
Hamish Lawson
Python can work perfectly well WITHIN ASP/IIS
Roman Suzi:
ADO could help for those who consider Python for tasks usually
done with PHP or ASP.
I suspect there may be cross-purposes here, due to differences in how
the term 'ASP' is being used. Strictly ASP is a technology for dynamic
web pages, but without any reference to any particular programming
language. VBScript just happens to be the most widely used language
for working with ASP, but other languages can be used - JScript,
PerlScript, Python, etc. Thus to compare Python with ASP is, strictly
speaking, as meaningless as comparing Python with CGI (when you
actually meant Perl).
Hamish Lawson
Alex Martelli
...
> >http://phplib.netuse.de/documentation/documentation-3.html#ss3.1
> >After studying that page a bit, unless I'm missing something,
> >it appears to me that this interface is *VASTLY* inferior to
> >the Python DB API.
>
> I do not believe it. PHP is so widely used with databases
> that I cant believe it's database connectivity is that bad!
As I said, I'm no PHP expert -- I hit on phplib because I
saw it mentioned as the only way to program PHP in such a
way that you won't have to redo everything if you move
from one RDBMS to another, which to me feels like a very
fundamental requirement. Maybe the typical PHP user cares
not a whit about that and is deliriously happy to program
against Oracle-only, or MySQL-only, or whatever -- I have
not examined the widely different (I'm told) interfaces
you get to use for that, only saw what seemed to me highly
justified SQUEALS of pain by Perl programmers used to the
RDBMS-portability of Perl's DBI at the idea of having to
program against a _specific_ RDBMS and redo everything when
(not if -- life doesn't work that way) the RDBMS that has
to be used changes under them...
Alex
Aahz Maruch
>>news:mailman.994164845...@python.org...
>>>
>>> Roses are red,
>>> and violets are blue,
>>> I program in Python,
>>> and so can you.
>>
>>Violets are blue
>>Everyone knows
>>Four into nine gives two
>
>A quarter infraction (in fraction, get it),
>This error in Python,
>Would deserve drastic action.
Burma Shave
Alex Martelli
news:Y3k07.26347$he.13...@e420r-atl1.usenetserver.com...
...
> cursor.execute("SELECT f1, f2, f3 FROM table WHERE f4=? AND f5=?", (f4val,
> f5val))
>
> I think you'll find it's more than a little tricky. Also, in VBScript, if
rs
Make a command object, with the CommandText property set to just
the same string as above, and call its Execute with the Parameters
set to Array(f4val,f5val). What's "more than a little tricky"
about this -- having to set CommandText then call Execute in
two steps? But this opens an opportunity to _prepare_ the
command object (set its Prepared property too) if you need to
execute it repeatedly with different parameters.
> is a recordset (with an implied current member), you have to access fields
> using
>
> rs("FieldName")
>
> This is a bizarre way to reference things by name. If your colleagues see
> this as natural then they have their Microsoft blinkers on. I have no
I guess I must have such blinkers, because I don't see this as an
issue. I may typically have the field names in variables, so how
else would I access the fields unless by using those values as
parameters to SOME call or other? it could be more explicit, for
sure -- hey, you CAN write rs.Fields("FieldName").Value, you know,
you don't HAVE to take the above shortcuts!-).
I'm no Microsoft lover, but SOME of their stuff ain't too bad,
and I think ADO falls into the "not too bad" category (some SMALL
subset of their stuff is EXCELLENT, and COM is right there, but
that's another issue:-). Indeed, I believe ADO (and much more
so, COM:-) deserves a far better language than Visual Basic...
Python, for example!-).
Alex
Alex Martelli
news:915a998f.01070...@posting.google.com...
> Alex Martelli:
>
> Python can work perfectly well WITHIN ASP/IIS
>
> Roman Suzi:
>
> ADO could help for those who consider Python for tasks usually
> done with PHP or ASP.
>
> I suspect there may be cross-purposes here, due to differences in how
> the term 'ASP' is being used. Strictly ASP is a technology for dynamic
> web pages, but without any reference to any particular programming
> language. VBScript just happens to be the most widely used language
> for working with ASP, but other languages can be used - JScript,
Actually, JScript seems to be more widespread in this role, judging
from various hints -- including the fact that in the next Microsoft
language generation, VBScript disappears (reabsorbed by VB, if
you will) but JScript is still being intensely invested on (also, the
examples on MSDN seems strongly JScript-biased).
> PerlScript, Python, etc. Thus to compare Python with ASP is, strictly
> speaking, as meaningless as comparing Python with CGI (when you
> actually meant Perl).
Yep, this is exactly what I think Roman finally got from this
exchange.
Alex
David Bolen
> On 2 Jul 2001, David Bolen wrote:
>
> >Roman Suzi <r...@onego.ru> writes:
> >
> >> However, my collegues were not satisfied with it. One somplain was that in
> >> ASP/IIS it is "very easy" to receive a "recordset" from database and then
> >> apply it in different situations in the ASP-page, because recordset is an
> >> object and even subqueries could be made without quering DB again.
> >
> >Just curious, but did your colleagues try using Python's COM interface
> >to ADO to retrieve an actual recordset object that they could
> >manipulate the same in Python as in other ASP languages?
>
> Aha! Now I could understand what is the brake of Python library
> development. Most of Python users are Windows users. And they
> have COM for whatever is in their system.
Um, I don't necessarily agree about the breakdown of Python users.
But you should realize that the reason I pointed this out is that your
statement above implies that _you_ (or at the very least your
colleagues) are working under Windows, or else they wouldn't be
comparing to ASP/IIS and ADO recordssets (which are Windows only).
If that's not true, then they are comparing apples to oranges, and the
difference is the Unix versus Windows/COM models, which has little to
do with Python or its database access methods. :-)
> We mostly have Linux servers, so COM+ADO is no option. The point was not
> to choose between Windows and Linux, ASP was choosen to serve particular
> purpose, for the database already implemented in Microsoft land.
Then I'm having trouble seeing the lack of satisfaction of your
colleagues having anything at all do with Python, and more to do with
a lack of satisfaction with a missing object model under Linux that
they liked under Windows. In other words, I don't think the problem
here is a Python database related issue.
--
-- David
--
/-----------------------------------------------------------------------\
\ David Bolen \ E-mail: db...@fitlinxx.com /
| FitLinxx, Inc. \ Phone: (203) 708-5192 |
/ 860 Canal Street, Stamford, CT 06902 \ Fax: (203) 316-5150 \
\-----------------------------------------------------------------------/
David Bolen
> *WHY* is it apparently so durned HARD?! Why do people keep
> saying "ASP" as if it somehow IMPLIED a language choice when
> one can perfectly well run any number of languages even on
> the *SAME SINGLE* Active Server Page?! Microsoft brainwashing?
> Anti-Microsoft brainwashing? I don't really understand.
(...)
> But Microsoft
> HAS been highlighting in glow-in-the-dark bright orance that
> THEIR environments are FULLY multi-language, since day one.
> Is Microsoft marketing really SO feeble that they still have
> not been able to get THIS single VERY simple point across?!
As someone who only finally had to deal with ASP pages this year, I
can say that until I started working with it, that I certainly might
have made the same mistake as referring to ASP as if it was more than
just the environment. It's far more common to see references to
IIS/ASP (both in and out of Microsoft stuff) than to see references to
the actual default scripting language (VBScript?) involved. At least
I found it so.
It's crystal clear when you actually start using it, but if you're
just talking hypothetically (perhaps the original poster had not
actually done any ASP work), it's pretty easy to make that mistake
IMO.
Magnus Lie Hetland
news:mailman.994136404...@python.org...
[...]
> I went up the URL until I got to the root http://www.stud.ifi.uio.no/
> and got a page described as:
>
> Institutt for informatikks studentserver
>
> I don't read the language,
I do ;)
> but I'd say that last word is pretty clear
> even to an English-speaker like myself. I guess that "larsqa" is out
> of school by now. I get redirected to "lmariusg's" homepage before
> getting the "Forbidden" error.
lmariusg sounds like "Lars Marius Garshol" (don't remember where I
have that name from...) -- a quick search turned up this:
http://www.garshol.priv.no/download/software/python/index.html
--
Magnus Lie Hetland http://www.hetland.org
"Reality is that which, when you stop believing in
it, doesn't go away." -- Philip K. Dick
Bengt Richter
I'm a bit new here, so I'd appreciate it if you could exp
Tim Peters
> Is anybody else suspicious about the sudden uptick of troll-like
> behavior on comp.lang.python? Keep an eye out and don't bother
> responding to anything inflammatory.
But, Paul! We *like* talking with you!
some-people-are-just-inflammatory-by-nature-ly y'rs - tim
Resty Cena
> I have been following Python for five years now, and I am still just as
> frustrated with it as I was in 1996.
>
> Python still doesn't have good database support,
I, too, have been following Python since 1996, waiting all the while
to make it easy for me to do database programming. What I'd call good
database support is where I download a file or set of files into a
directory under my Python directory, perhaps run an install program,
then start Python, import a package, issue a command to connect to
Oracle, and start playing around with the scott/tiger database. I
don't want, nor do I have the time, to compile anything, nor muck
around with the Windows registry, nor manually set paths -- I just
want to try the product, not install it for production use. Ideally,
I'd like the IDE to do this for me. I'm a database programmer, and I
want to write applications right away. I'm also lazy and I expect much
from my tools.
Steve Holden
news:458b194a.01070...@posting.google.com...
Of course, one of the reasons why support isn't better is the huge ratio of
consumers to producers. That's not necessarily a bad thing, but most of the
best parts of Python have been the results of individuals providing what
they needed for their own purposes and then opening up the resulting code.
Continue to sit on your hands by all means. What you need should be along in
another five years or so. But simply posting to complain that things aren't
as you want is unlikely to change in the next six months what nothing else
has changed in the last five years.
There are lots of people doing much good database work with Python. The
mxODBC package (free for non-commerical use) and the cx_Oracle package
(free) do indeed let you do what you describe (i.e. download, unpack, run an
install script and connect to a database). So I suggest you look a little
harder and complain a little less. Normally I try to include URLs in
postings such as this, but you know, somehow I get the impression that
clicking on a link in a news posting might just be too much trouble ;-)
Come on in, the water's lovely.
Steve Williams
> "Edward B. Wilson II" <e...@ewilson.com> wrote in message news:<MNS%6.355$Xs4.2...@news.pacbell.net>...
> > I have been following Python for five years now, and I am still just as
> > frustrated with it as I was in 1996.
> >
> > Python still doesn't have good database support,
>
> I, too, have been following Python since 1996, waiting all the while
> to make it easy for me to do database programming.
[snip]
How about this little jewel returned by a Google search on "Python DB2 AIX"?
From
http://webevents.broadcast.com/ibm/developer/050901/display_qa.asp
Question 10:
DB/2 can be used whit PHP or Pyton ?
Answered by Nanda Pilaka:
DB2's supports C/C++/Java/COBOL/REXX/Basic/Perl/Fortran currently.
Python is not supported.
We now return you to the whitespace discussion currently in progress. . .
Joe Potter
Spot on, Steve.
Regards, Joe
Steve Holden
"Steve Williams" <stevew...@wwc.com> wrote in message
news:3B448C81...@wwc.com...
allow access. Does anyone actually USE DB/2 with Python?
The DB SIG module list seems a little out of date, and a monthly mail
archive of over 20KB seems to be the exception rather than the rule.
Gerhard Häring
>The DB SIG does list a DB/2 module, but the ftp server it links to doesn't
>allow access. Does anyone actually USE DB/2 with Python?
>
>The DB SIG module list seems a little out of date, and a monthly mail
>archive of over 20KB seems to be the exception rather than the rule.
As an alternative, there's always dmoz.org. The URL is
http://dmoz.org/Computers/Programming/Languages/Python/Modules/Database/ For
suggestions, you can contact the editor. That's me :-) There's also an
add/update URL link.
Gerhard
--
mail: gerhard <at> bigfoot <dot> de registered Linux user #64239
web: http://highqualdev.com public key at homepage
public key fingerprint: DEC1 1D02 5743 1159 CD20 A4B6 7B22 6575 86AB 43C0
reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))
Steve Williams
>
[snip]
> Does anyone actually USE DB/2 with Python?
>
Yes.
phil hunt
>"Edward B. Wilson II" <e...@ewilson.com> wrote in message news:<MNS%6.355$Xs4.2...@news.pacbell.net>...
>> I have been following Python for five years now, and I am still just as
>> frustrated with it as I was in 1996.
>>
>> Python still doesn't have good database support,
>
>I, too, have been following Python since 1996, waiting all the while
>to make it easy for me to do database programming. What I'd call good
>database support is where I download a file or set of files into a
>directory under my Python directory, perhaps run an install program,
>then start Python, import a package, issue a command to connect to
>Oracle, and start playing around with the scott/tiger database. I
>don't want, nor do I have the time, to compile anything, nor muck
>around with the Windows registry, nor manually set paths -- I just
>want to try the product, not install it for production use. Ideally,
>I'd like the IDE to do this for me.
Then why don't you write one, instead of just complaining that
the tools available don't work quite how you like?
--
## Philip Hunt ## ph...@comuno.freeserve.co.uk ##
David Bolen
> I, too, have been following Python since 1996, waiting all the while
> to make it easy for me to do database programming. What I'd call good
> database support is where I download a file or set of files into a
> directory under my Python directory, perhaps run an install program,
> then start Python, import a package, issue a command to connect to
> Oracle, and start playing around with the scott/tiger database. I
> don't want, nor do I have the time, to compile anything, nor muck
> around with the Windows registry, nor manually set paths -- I just
> want to try the product, not install it for production use. Ideally,
> I'd like the IDE to do this for me. I'm a database programmer, and I
> want to write applications right away. I'm also lazy and I expect much
> from my tools.
BTW, this doesn't cover the whole universe (which is complicated
enough), but since you mentioned it - under Windows, what you want is
pretty much how I perceive the state of affairs, using mxODBC. All I
did was download it, unzip it (or install it for the newer versions)
and I was done. I could connect to any of my existing data sources
(via ODBC) just as with any of my other database access mechanisms in
that environment. No recompiling, no special settings or anything.
True, that's ODBC based, but that seems pretty standard for all the
other access mechanisms I've used under Windows. I'm sure with other
environments with direct client libraries per-database there's more
complexity, and I can't directly address Python's state of affairs
there.
Kemp Randy-W18971
-----Original Message-----
From: ph...@comuno.freeserve.co.uk [mailto:ph...@comuno.freeserve.co.uk]
Sent: Thursday, July 05, 2001 6:21 PM
To: pytho...@python.org
Subject: Re: Is Python Dead?
On 5 Jul 2001 08:11:48 -0700, Resty Cena <rc...@epcor.ca> wrote:
>"Edward B. Wilson II" <e...@ewilson.com> wrote in message news:<MNS%6.355$Xs4.2...@news.pacbell.net>...
>> I have been following Python for five years now, and I am still just as
>> frustrated with it as I was in 1996.
>>
>> Python still doesn't have good database support,
>
>I, too, have been following Python since 1996, waiting all the while
>to make it easy for me to do database programming. What I'd call good
>database support is where I download a file or set of files into a
>directory under my Python directory, perhaps run an install program,
>then start Python, import a package, issue a command to connect to
>Oracle, and start playing around with the scott/tiger database. I
>don't want, nor do I have the time, to compile anything, nor muck
>around with the Windows registry, nor manually set paths -- I just
>want to try the product, not install it for production use. Ideally,
>I'd like the IDE to do this for me.
Then why don't you write one, instead of just complaining that
Resty Cena
with my hands tucked between my pants and the chair. I donwloaded
cx_Oracle and, yes, it's up. Now, would you happen to have, or know
of, some materials (sample code, tips, tricks, techniques, tutorials)
on getting started on programming *forms* based applications in Oracle
and Python? That would be just great.
"Steve Holden" <sho...@holdenweb.com> wrote in message news:<TH%07.3499$i8.3...@e420r-atl3.usenetserver.com>...
Steve Holden
> Well thank you for jolting me out of my comfortable position sitting
> with my hands tucked between my pants and the chair. I donwloaded
> cx_Oracle and, yes, it's up. Now, would you happen to have, or know
> of, some materials (sample code, tips, tricks, techniques, tutorials)
> on getting started on programming *forms* based applications in Oracle
> and Python? That would be just great.
>
GUI-based programs using Oracle rather than Oracle Forms stuff? There is
some coverage in Hammond & Robinson's Programming Win32 in Python book, for
a start. Other people speak highly of Grayson's Python and Tkinter
programming, though it isn't my cup of tea. I'm not currently aware of
anything drag-and-drop which includes database awareness, but Boa
Constructor and BlackAdder GUI tools both have theie adherents.
Since you've taken the effort to get started I am reasonably sure that the
c.l.py GUI community will be out in force to help you (right, guys?) -
you've probably seen the regular threads on "Which GUI is the best" and
realise there's a choice.
I am currently working on a simple web-based framework for data editing,
which I plan to translate to one or other of the available GUIs, but that's
currently on the horizon. It will be open source when it's finished.
Charlie Dyson
>> What exactly is "good database support?" I haven't had a problem.
>
> I think this is mostly due to the lack of centralization of python
> software
> (ala CPAN). I believe there are stable python modules to access pretty
> much
> any database: oracle, odbc, sybase, bsdb (sleepycat), solid, postgresql,
> etc... I thought python's database support was weak, but when i needed it
> it always came through.
>
>> I'm not a Zope user myself, but from what I've read about both PHP
>> and Zope, it appears they are pretty much even in capability (hopefully
>> an expert on the subject will comment here).
>
> I'm far from an expert, but.. I do have an opinion. From what I've seen
> in
> PHPland, ZOPE compares pretty much feature-for-feature and then some!.
> ZOPE
> is a larger more comprehensive framework than any PHP 'framework' that
> exists (including eGrail or phpGroupware). Remember: PHP is a web
> programming language. Python is a general purpose language. ZOPE is a
> python framework. IMHO, Zope has suffered popularity because it refuses
> to
> embed python (code) into the presentation layer (unlike PHP). Also ZOPE
> is
> 100% object-oriented. PHP isnt OO and reusibility is garnished from lots
> of
> #includes (where as ZOPE has access to Pythons lib and ZOPE accessories
> #and
> there is hooks into using Perl from ZOPE also.. so you get Perl's DB
> support
> as well). PHP is faster, but it doesnt stack up in reusability, speed of
> development, or flexibility (Python as you mentioned, we all consider to
> be
> the best language on the net ;) in language design. also, the ZODB is
> being wheened off of ZOPE dependency and is starting to show signs of
> Standalone
> distribution. this is a __HUGE__ win for Python -- a trivially easy to
> use object database.
>
>> > Python needs better leadership in areas of its growth. Python is truly
>> the
>> > best language in use today, except it still isn't very useful for the
>> > largest solution sector, database access, and information presentation
>> (web,
>> > or otherwise).
>
> uhm. I completely disagree.
>
> information presentation I believe is fully covered by Python, nothing
> (that I know of) comes close to the bredth of GUI support in Python: QT,
> GDK, wxPython, TkInter, ?FOX?, and there are others! oh including Swing
> via
> Jython. On the web scene there is healthy competition: WebWare (which is
> modelled after Java's Servlet design), ZOPE (which is a highly evolved
> framework that comes with a transactional object database), Quixote and
> quite a few others. HTMLGen. I believe mod_snake (?) is being kept up.
> There is a hook into the Ars Digita system via Python. I believe you can
> present information using python in a myriad of ways -- its your choice ;)
>
> ~runyaga
>
>
>
I have never used Zope, but I have opinions on everything, so here goes. I
have used PHP, an liked it. I think that PHP is *very* strong when dealing
with database-interaction, whilst Zope is better targeted at maintaining
large content websites. I personally would *really* like to see some way of
using both. If I ever develop a large database driven website, here's how I
would do it (yes, lots of people could do this better than me):
Have PHP to deal with the actual database part of the website
Have everything else - Homepage, help, about us, anything else the site
does powered by Zope, because of it's excellent content-managing systems
(which I do not understand...)
Anyway, I hear that there is some sort of Zope-like thing for PHP. I love
PHP and Python, and so it's difficult to choose which to use. Let's face
it, if anyone ever creates a one-size-fits-all web programming/site
maintaining/database interfacing/dinner making programming language/content
system, it'll either be so spread out, huge and bloated that it will be
impossible to use, or only very badly do everything it does. It's better to
have sharp, closely defined tools that can do one or two things well, and
other things less well. That is why we have so many programming languages.
Hope I haven't bored you all,
Charlie Dyson - cha...@charliedyson.net
(I've only just started contributing to this group)
David LeBlanc
says...
> On 2 Jul 2001, David Bolen wrote:
>
> >Roman Suzi <r...@onego.ru> writes:
> >
> >> However, my collegues were not satisfied with it. One somplain was that in
> >> ASP/IIS it is "very easy" to receive a "recordset" from database and then
> >> apply it in different situations in the ASP-page, because recordset is an
> >> object and even subqueries could be made without quering DB again.
> >
> >Just curious, but did your colleagues try using Python's COM interface
> >to ADO to retrieve an actual recordset object that they could
> >manipulate the same in Python as in other ASP languages?
>
> Aha! Now I could understand what is the brake of Python library
> development. Most of Python users are Windows users. And they
> have COM for whatever is in their system.
>
> >support should pretty much cover in Python anything you'd do elsewhere.
> >
> >On other environments, direct support for a particular database is
> >likely to be more desirable, as it's more typical in those
> >environments, but as you've noted, there's a plethora of support
> >modules for various databases - some at various levels.
>
> We mostly have Linux servers, so COM+ADO is no option. The point was not
> to choose between Windows and Linux, ASP was choosen to serve particular
> purpose, for the database already implemented in Microsoft land.
>
> >-- David
>
> Sincerely yours, Roman Suzi
>
If you don't mind spending $$, then COM and ASP are most definately an
option on Unix. Check out ChiliASP (www.chilisoft.com ?). Even COM all by
it's lonesome is available for Unix since ChiliSoft uses a COM library
from a 3rd party supplier.
Dave LeBlanc
kosh
That is one of the reasons that I use debian with apt-get. There are lots
of python libraries, documentation etc. apt-get install python-imaging
That will install the Python Imaging Library with no nead to compile etc.
You can then immediately use it.
I would prefer someting like the database that debian to track all these
products were to get bigger and more advanced so it would have more
products. This is what the LSB is trying to do now. They recommend RPM
right now however they are working on making a new package format that
should be better then both RPM and DEB when done. Then the whole thing can
be tied together with a nicer database system then apt is right now.
This way each project doesn't have to create something like CPAN. That
seems like just reinventing the wheel over and over again. This would make
it a system wide feature and programs should then plugin to it.
Maybe if windows people were interested they could port it to windows also.
Resty Cena
rename this thread "Is Python Dead? Long Live Python!" or some such.
"Steve Holden" <sho...@holdenweb.com> wrote in message news:<7sn17.7740$i8.6...@e420r-atl3.usenetserver.com>...
Skip Montanaro
Resty> By the way, someone should rename this thread "Is Python Dead?
Resty> Long Live Python!" ...
Couldn't you have done that? ;-)
S
Edward Wilson
with the contemporary. Python will become more or less mainstream
(live or die) on it's own merits.
A scripting language should be good at scripting. From my
observation, Python appears to be headed in more of an acedemic
direction rather than that of mainstream commerce. Acedemics are
good, it's where technology comes from. Unfortunately, I still
haven't found a way to make money using Python. If I can't make money
with Python, then Python is dead to me. I would imagine my voice
represents a small crowd of developers, who wish they too could make
money with and contribute to Python on a daily basis (on company
time).
If this is so, Python won't bennefit from the best developers, the
developers who code for a living. From what I can tell, PHP and Ruby
are flying past Python in acceptance rates. The difference that I see
in these groups, is a sensitivity to industry, rather than an
adoration for pure acedemic elegance.
Beauty is only beauty if one can experience it. I can't experience
Python on a day to day basis (in the workplace), so therefore I can't
appreciate it.
As far as ODBC--ODBC is too slow for what I do. I'm using Oracle
Pro/C. Most serious developers would agree that ODBC is slow.
Wheather Java decides to use (cheat with) ODBC or not is Java's
problem. Java is WAY too slow for serious development of any kind.
If it weren't, it would be the perfect language--if that were
possible.
Yes, native drivers for all db vendors. This is why I mentioned (in
an earlier post) that this should be a community effort. Python could
break the door down if it paid more attention to the needs of the
commond professional. Satellite controlers are great too, but
Priorities have meaining in a time of war.
--
ed
Skip Montanaro <sk...@pobox.com> wrote in message news:<mailman.994599260...@python.org>...
James_...@i2.com
Edward Wilson wrote:
<snip>
>Java is WAY too slow for serious development of any kind.
Might we be over-generalizing just a wee bit, perhaps? My company is
generating hundreds of millions of dollars of revenue with products written
in Java (with major pieces implemented in Jython :-).
(I suppose *serious development* is relative <wink>).
Jim
James Logajan
"A few billion here, a few billion there, and pretty soon you're talking
real money." A few hundred million? A mere pittance! Obviously no one who
wants to make real money develops in Java!
(Do I really need to add a wink or smiley??)
Lindstrom Greg - glinds
>I can't experience Python on a day to day basis
>(in the workplace), so therefore I can't
>appreciate it.
This is quite true in my experience, too. I work in an IT shop that simply
refuses to recognize Python (and Perl) because most of the people in
leadership will not accept it. The major strikes?
1. It's Free. How serious can a language be if it's given away? We seem to
feel more secure in spending over $2500.00 per box for MS Developers Studio
and various other software license (CORBA goes for $1,200 a box, I'm told)?
2. If my boss had to code in C/C++, it's should be good enough for me
(dammit!). C++ has the added benefit of producing code that is nearly
unreadable, and complex enough to take days to explain. Now this may be
because we do not know how to properly code C++ (surely there is good C++
code out there somewhere). In a recent (very large) project here, the
"architecture team" would not even consider STL for the string class; they
designed and wrote their own! The ironic twist in this is that 10 years ago
these same people insisting on C/C++ were the ones leading the way away from
assembler language.
3. No Support! At least no 900 number to call for a per minute fee. Doesn't
seem to matter that in the past couple of years I have never had to wait
over a day to get a answer to a question. Perhaps we would feel better if
there were someone we could sue.
4. To easy to understand. A sin among most coders. It's embarrassing to go
into a review meeting and show product managers and others code that they
can understand. It's much more impressive to hand out code that baffles 10
year veterans. I showed the code to a recent prototype to a customer
relationship manager, and she understood the flow (to be fair, she could not
have produced the code, but she felt good about making minor changes).
5. A fear of maintainability. My boss worries that nobody will be able to
maintain the code I write. While I believe that is a fair criticism on Perl
(and is why I stopped coding Perl), it is my experience that Python is quite
easy to understand. Of course, a poor programmer can produce poor code in
any language (they just have to work a little harder at it in Python).
Perl and Python (and I love 'em both) are gaining ground among those who
have to get things done because they improve productivity. I write almost
all of my test routines in Python if for no other reason as to remove a
common language between application and test. Most of my prototypes are
Python (love the wxPython). In time, I hope others will be won over; and --
with no disrespect to Python -- it does not keep up with my needs as a
programmer, I will leave it for anything better that comes along. Until
then I will fight for both Perl and Python.
Greg Lindstrom
"When the solution is simple, God has spoken"
Albert Einstein
Paul Prescod
> > are flying past Python in acceptance rates. The difference that I see
> > in these groups, is a sensitivity to industry, rather than an
> > adoration for pure acedemic elegance.
I think even the Ruby people would be surprised to hear about Edward's
statistics about it flying past Python!
I've decided to flame Edward offlist because it becomes increasingly
difficult to take him seriously.
--
Take a recipe. Leave a recipe.
Python Cookbook! http://www.ActiveState.com/pythoncookbook
Neil Schemenauer
> [...] Python won't bennefit from the best developers, the
> developers who code for a living.
How exactly are these developers going to benefit Python? It appears to
me that the loss would be minor. If you think there is something wrong
with the DB support in Python then do something about it. Posting lots
of whiny messages to c.l.p doesn't help.
Python-helps-those-who-help-themselves-ly'rs Neil
James_...@i2.com
James Logajan wrote:
Nah. I'm sure Everett Dirksen is smiling somewhere "out there".
Jim
Paul Prescod
>
>...
>
> This is quite true in my experience, too. I work in an IT shop that simply
> refuses to recognize Python (and Perl) because most of the people in
> leadership will not accept it. The major strikes?
>
> 1. It's Free. How serious can a language be if it's given away? We seem to
> feel more secure in spending over $2500.00 per box for MS Developers Studio
> and various other software license (CORBA goes for $1,200 a box, I'm told)?
ActiveState has a program wherein we can sell you Python at whatever
price point is comfortable for you. :) If $2500.00 is your price point,
that's fine with us.
Actually scratch that. I'm going to run this program myself from home.
Contact me separately for my home phone number.
>..
> 3. No Support! At least no 900 number to call for a per minute fee. Doesn't
> seem to matter that in the past couple of years I have never had to wait
> over a day to get a answer to a question. Perhaps we would feel better if
> there were someone we could sue.
Actually, ActiveState really does have a program where we can provide
technical support for open source languages. Despite my levity above,
this is a real product that provides serious value to people who need to
know that they can get (e.g.) custom builds of Python when they need
them.
Peter Hansen
>
> refuses to recognize Python (and Perl) because most of the people in
> leadership will not accept it. The major strikes?
>
> 1. It's Free.
> (dammit!).
The real problem, as I have come to understand in my successful effort to
bring Python into my current employer's company in a big way (sixteen
programmers using it for a wide variety of applications and utilities)
is management COWARDICE.
It's not that they don't buy the argument that free software could
save money, or that code readability is a good thing, or that c.l.p
can provide better support than any commercial organization ever does.
They understand all that at some level, but have a mental - no, make that
political - problem accepting it and acting on it.
To allow Python a role in the organization would be to assume a leadership
position. To take a risk (from the standpoint of their current ignorance)
that they might make a mistake. To show some vision.
These are not things most managers readily do. Their job safety lies
in following, not leading. Calling them "the people in leadership" is
an insult to real leaders everywhere.
I recommend a persistent onslaught of griping about current tools,
constant pointing out of how superior Python would be in a given problem
situation, projections that a new development could take M months of work
in a more typical language but only N months were it written in Python,
whining at the difficulty of maintaining code in another language,
and periodic forwarding of links and articles showing how companies
with more cohones than yours are achieving significant successes with
Python (especially any near competitors).
Good luck! :-)
--
----------------------
Peter Hansen, P.Eng.
pe...@engcorp.com
CyberKat
> Lindstrom Greg - glinds wrote:
>
> I recommend a persistent onslaught of griping about current tools,
> constant pointing out of how superior Python would be in a given problem
> situation, projections that a new development could take M months of work
> in a more typical language but only N months were it written in Python,
> whining at the difficulty of maintaining code in another language,
> and periodic forwarding of links and articles showing how companies
> with more cohones than yours are achieving significant successes with
> Python (especially any near competitors).
>
Nice - I just have to find the _time_ to learn Python well enough to
point out where and how it's better - I like the look and concepts of
Python (tho' I'd like some sort of strong typing option [constrictor
maybe ;-) ] ) but I just don't have enough hours on the d**n day to
get deep enough into it. Like any other language it's not until you're
deep into a major app with it that you find out its strengths and
weaknesses.
Alan
Kemp Randy-W18971
-----Original Message-----
From: James Logajan [mailto:Jam...@Lugoj.Com]
Sent: Monday, July 09, 2001 4:24 PM
To: pytho...@python.org
Benjamin.Altman
> 3. No Support! At least no 900 number to call for a per minute fee. Doesn't
> seem to matter that in the past couple of years I have never had to wait
> over a day to get a answer to a question. Perhaps we would feel better if
> there were someone we could sue.
I am sure plenty of people would be willing to charge per minute to give Python
advice - just a matter of offering the service to get some suckers.. I mean
companies to take it up.
Kemp Randy-W18971
then a Python 900 number would work. Heck, we could even get creative here.
Write a Python program to randomly generate some psychic advice, and open a
second psychic line for $4.95/minute. You could even have the same line,
and answer like this.
Caller: Ring, Ring.
Hello. Is the Guru in?
Respondent: Are you calling the Python Guru or the Python psychic.
Caller: I want the Python psychic.
-----Original Message-----
From: Benjamin.Altman [mailto:benjami...@noaa.gov]
Sent: Tuesday, July 10, 2001 10:14 AM
To: pytho...@python.org
Subject: Re: Is Python Dead? Long Live Python!
Skip Montanaro
Benjamin> Lindstrom Greg - glinds wrote:
>> 3. No Support! At least no 900 number to call for a per minute
>> fee. Doesn't
>> seem to matter that in the past couple of years I have never had
>> to wait over a day to get a answer to a question. Perhaps we would
>> feel better if there were someone we could sue.
Benjamin> I am sure plenty of people would be willing to charge per
Benjamin> minute to give Python advice - just a matter of offering the
Benjamin> service to get some suckers.. I mean companies to take it up.
Throw in a little heavy breathing and I'm sure you'd turn a profit... ;-)
Skip
James_...@i2.com
Randy.L.Kemp wrote:
>Let's give Java its due respect, and Python its due respect. J2EE does
have a considerable amount of >emphasize in the business world, along with
creating some open source efforts (www.jboss.org and >www.enhydra.org).
But Python should be used more in the business world. Unfortunately, it is
not.
So our approach -- which seems to have worked very well so far -- is to use
*Jython* so that we can leverage both Java/J2EE *and* Python!
Jim
"Jürgen A. Erhard"
Edward> Languages never die; they just fall out of use when they loose touch
Edward> with the contemporary. Python will become more or less mainstream
Edward> (live or die) on it's own merits.
Edward> A scripting language should be good at scripting. From my
Edward> observation, Python appears to be headed in more of an acedemic
Edward> direction rather than that of mainstream commerce. Acedemics are
Edward> good, it's where technology comes from. Unfortunately, I still
Edward> haven't found a way to make money using Python. If I can't make money
Edward> with Python, then Python is dead to me. I would imagine my voice
Edward> represents a small crowd of developers, who wish they too could make
Edward> money with and contribute to Python on a daily basis (on company
Edward> time).
Edward> If this is so, Python won't bennefit from the best developers, the
Edward> developers who code for a living. From what I can tell, PHP and Ruby
Edward> are flying past Python in acceptance rates. The difference that I see
Edward> in these groups, is a sensitivity to industry, rather than an
Edward> adoration for pure acedemic elegance.
Edward> Beauty is only beauty if one can experience it. I can't experience
Edward> Python on a day to day basis (in the workplace), so therefore I can't
Edward> appreciate it.
Edward> As far as ODBC--ODBC is too slow for what I do. I'm using Oracle
Edward> Pro/C. Most serious developers would agree that ODBC is slow.
Edward> Wheather Java decides to use (cheat with) ODBC or not is Java's
Edward> problem. Java is WAY too slow for serious development of any kind.
Edward> If it weren't, it would be the perfect language--if that were
Edward> possible.
Edward> Yes, native drivers for all db vendors. This is why I mentioned (in
Edward> an earlier post) that this should be a community effort. Python could
Edward> break the door down if it paid more attention to the needs of the
Edward> commond professional. Satellite controlers are great too, but
Edward> Priorities have meaining in a time of war.
Bwahahahahha... heehee, *wheeeze*... please, stop, this is too good!
My stomach's starting to hurt! "Java ... serious development of any
kind." ... mua... mwua... Mwuahaha, Bwuahahaha!
Bye, J
PS: If ever you should have a need for a second career, try stand-up
comedy. You should be good at it...
PPS: I agree with Paul: it's hardly possible to take you seriously
anymore.
--
Jürgen A. Erhard (juergen...@gmx.net, j...@users.sourceforge.net)
MARS: http://members.tripod.com/Juergen_Erhard/mars_index.html
"Perl Programmers are from Mars,
Python Programmers are from Yorkshire" -- Alex in c.l.py
--pgp-sign-Multipart_Tue_Jul_10_21:11:38_2001-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iEYEABECAAYFAjtLU3gACgkQN0B+CS56qs2brwCgpOBj9XunGgpNyL5XE9aFsQ3Z
g9sAoIg2OhrdvQLCgyDoIffH13plT146
ypId
-----END PGP SIGNATURE-----
--pgp-sign-Multipart_Tue_Jul_10_21:11:38_2001-1--
Kemp Randy-W18971
acceptance because they address business needs, what needs to be done to
carry Python in that direction? And while Java may be slow, Sun pushing it
for business solutions also gives that language acceptance. How can Python
become as popular as Perl, Java, or PHP?
-----Original Message-----
From: "Jürgen A. Erhard" [mailto:juergen...@gmx.net]
Sent: Tuesday, July 10, 2001 2:12 PM
To: web...@yahoo.com
Cc: pytho...@python.org
Subject: Re: Is Python Dead? Long Live Python!
Paul Wright
Paul Prescod <pa...@ActiveState.com> wrote:
>> > From what I can tell, PHP and Ruby
>> > are flying past Python in acceptance rates. The difference that I see
>> > in these groups, is a sensitivity to industry, rather than an
>> > adoration for pure acedemic elegance.
>
>I think even the Ruby people would be surprised to hear about Edward's
>statistics about it flying past Python!
Shurely he means that the derivative of the number of users wrt time is
greater for Ruby than for Python, which may be true because Python has a
far larger user base and so is nearer "saturation".
--
----- Paul Wright ------| No storm can shake my inmost calm,
-paul....@pobox.com--| while to that rock I'm clinging.
http://pobox.com/~pw201 | Since love is lord of heaven and earth
| how can I keep from singing?
"Jürgen A. Erhard"
Kemp> So an interesting question is raised.
Is it?
Kemp> If PHP and Ruby are gaining acceptance because they address
Kemp> business needs, what needs to be done to carry Python in
Kemp> that direction?
*If*! We can debate to no end whether PHP and Ruby are gaining
acceptance, in business circles.
And PHP and Ruby are quite different beasts.
I'm looking on my Debian system... and lo and behold, I don't see any
significant app or tool written in Ruby. Okay, that might not mean
too much... I can find tons of *important* stuff using Python,
however (apt-cache showpkg python-base scrolls off the screen... a 60
line screen. The same for ruby fits nicely)
Kemp> And while Java may be slow, Sun pushing it for business
Kemp> solutions also gives that language acceptance. How can
Kemp> Python become as popular as Perl, Java, or PHP?
What Paul said... especially concerning Java. Just Sun alone probably
has a marketing budget for Java that no company in the Python camp can
match.
Bye, J
PS: This will really (yeah, sure ;-) be the last from me in this
thread.
--
Jürgen A. Erhard (juergen...@gmx.net, j...@users.sourceforge.net)
MARS: http://members.tripod.com/Juergen_Erhard/mars_index.html
GNU Privacy Guard (http://www.gnupg.org)
I have a firm grip on reality, now I can strangle it.
--pgp-sign-Multipart_Wed_Jul_11_21:40:43_2001-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iEYEABECAAYFAjtMq8MACgkQN0B+CS56qs34YwCZARIM16bqdVFCpNNQO5sIHBa7
IgsAn2HRhyOFWVcVxW8j1QmMK/qO/C06
isKh
-----END PGP SIGNATURE-----
--pgp-sign-Multipart_Wed_Jul_11_21:40:43_2001-1--
Kemp Randy-W18971
-----Original Message-----
From: "Jürgen A. Erhard" [mailto:juergen...@gmx.net]
Sent: Wednesday, July 11, 2001 2:41 PM
To: Kemp Randy-W18971
Cc: pytho...@python.org
Subject: Re: Is Python Dead? Long Live Python!
Peter Hansen
>
> In article <mailman.994711525...@python.org>,
> Paul Prescod <pa...@ActiveState.com> wrote:
> >> > From what I can tell, PHP and Ruby
> >> > are flying past Python in acceptance rates. The difference that I see
> >> > in these groups, is a sensitivity to industry, rather than an
> >> > adoration for pure acedemic elegance.
> >
> >I think even the Ruby people would be surprised to hear about Edward's
> >statistics about it flying past Python!
>
> Shurely he means that the derivative of the number of users wrt time is
> greater for Ruby than for Python, which may be true because Python has a
> far larger user base and so is nearer "saturation".
Wouldn't this only hold true if Ruby's _potential_ user base were
sufficiently large compared to Python's potential user base?
I believe that many more people will eventually use Python than will
use Ruby (language war thread!). That might mean Python's rate of
increase in user base per unit time is still larger than Ruby's.
(And this certainly fits with my own observations over the last year.)
Peter Hansen
[snip]
> But it is hard to get others at my company on
> that bandwagon. I have a hard enough time selling Perl.
If you are trying to sell both Perl and Python, maybe you're
just confusing your audience with a mixed message. Are you
trying to promote them on the same basis?
If anyone tried to tell me I should be using Perl for a task,
although I could also consider using Python because that would
be just as effective, I'd have to laugh... (and then apologize
and all that stuff, which I really hate. ;-)
phil hunt
>--pgp-sign-Multipart_Wed_Jul_11_21:40:43_2001-1
>Content-Type: text/plain; charset=ISO-8859-1
>Content-Transfer-Encoding: quoted-printable
>
>>>>>> "Kemp" =3D=3D Kemp Randy-W18971 <Randy....@motorola.com> writes:
>
> Kemp> So an interesting question is raised.
>
>Is it?
>
> Kemp> If PHP and Ruby are gaining acceptance because they address
> Kemp> business needs, what needs to be done to carry Python in
> Kemp> that direction?
>
>*If*! We can debate to no end whether PHP and Ruby are gaining
>acceptance, in business circles.
>
>And PHP and Ruby are quite different beasts.
PHP is very popular in open source projects. Ruby less so.
--
## Philip Hunt ## ph...@comuno.freeserve.co.uk ##
Kemp Randy-W18971
-----Original Message-----
From: Peter Hansen [mailto:pe...@engcorp.com]
Sent: Wednesday, July 11, 2001 5:09 PM
To: pytho...@python.org
Subject: Re: Is Python Dead? Long Live Python!
Kemp Randy-W18971
statement, and I was raising a question, given that the information was
true. But I also have my doubts. PHP is also competing for the market with
JSP, ASP, and Cold Fusion, and you can run JSP (with Tomcat) and ASP (with
Win doze and IIS) for nothing. Ruby is still mainly used in Japan, and not
outside that country. There is a good test of how popular something is.
Walk into a big book store that carries technical books (Border's is an
example in the US), or a web outlet like www.amazon.com. Count how many
books are on a topic: Perl, Java, Python, Ruby, PHP, ASP, etc. It may not
be foolproof, but it is a good start. And yes -- I am a big Python fan, even
though I don't get a chance to use it as frequently as others on this list.
-----Original Message-----
From: ph...@comuno.freeserve.co.uk [mailto:ph...@comuno.freeserve.co.uk]
Sent: Wednesday, July 11, 2001 4:33 PM
To: pytho...@python.org
Subject: Re: Is Python Dead? Long Live Python!
Peter Hansen
> There is a good test of how popular something is.
I'm not convinced this is really a good test...
> Walk into a big book store that carries technical books (Border's is an
> example in the US), or a web outlet like www.amazon.com. Count how many
> books are on a topic: Perl, Java, Python, Ruby, PHP, ASP, etc. It may not
> be foolproof, but it is a good start.
Let's consider the case of two hypothetical languages.
One of them was designed by someone with extensive language design
background and an innate good sense of design. It was easy to learn
and apply and well-supported by a friendly newsgroup, etc. (not
thinking of any particular language here... this is just a hypothetical
case, remember :-). The language was mature, with a strong,
established and mostly content user base which was growing steadily.
The other language was a twisted hodge-podge of braces and Perlishness
built on a poor design with only a very limited field of application in
mind, by someone fresh out of university and with relatively little
language design in his background (and, if not poor design sense,
then poor taste in choice of starting point). Luckily, however,
the language struck a chord with a frenzied population of web-meisters
and script kiddies who up until now were limited to writing code in
Javascript to run on the client side and, as a result, exploded in popularity
almost overnight. Unfortunately as a result of the language's design,
it was difficult for new programmers to learn, and because of its
limitations it was very difficult for those programmers to apply it
outside of its narrow niche without assistance.
I think it would be reasonable to assume that a much larger number
of books (and I mean those big, thick books that Philip Greenspun
derides so well in http://philip.greenspun.com/wtr/dead-trees/story.html)
would be written about the second language than the first.
The users of the first would have most of their needs met by the
online information available, and the incredible ease of learning
the language or of applying it in diverse areas.
Publishers can smell this and would not put their efforts into
tree-killing for the second language. Entire forests, however,
would be slaughtered in the name of the second language, to buy
Mercedes automobiles for the publishing executives.
Hypothetically speaking, of course. ;)
Paul Prescod
>
>...
>
> The users of the first would have most of their needs met by the
> online information available, and the incredible ease of learning
> the language or of applying it in diverse areas.
>
> Publishers can smell this and would not put their efforts into
> tree-killing for the second language. Entire forests, however,
> would be slaughtered in the name of the second language, to buy
> Mercedes automobiles for the publishing executives.
If this is true, why are there so many Python books all of a sudden?
Even a simple language needs books because many people prefer to learn
from books than from web tutorials. And no language is truly simple when
you look at it in sufficient context. Do you know everything about
Python including how to handle Unicode, XML, Tk, windows APIs, CORBA,
and a hundred other buzzwords? Even if there were a language you could
teach in one chapter (lambda calculus for dummies, anyone?), the
libraries and add-ons would add up to a thick book.
Plus, you can always pair it with another buzzword. "ADO Programming
with Python." "Web Services with Python." and so forth. The number of
books is a pretty good indication of a languages' growth. The only
problem is that it is an indicator that trails badly. For all we know
there are twenty Ruby books under development but they won't show up
until a year from now.
Publishers clearly believe that Python is going to be a big thing.
Consider:
http://www.deitel.com/whatsnew.html
These guys are the ultimate trend-watchers. The fact that Python has
attracted their attention means that it is gaining mainstream
traction....or was last year. :)
Peter Hansen
>
> Peter Hansen wrote:
> >...
> > The users of the first would have most of their needs met by the
> > online information available, and the incredible ease of learning
> > the language or of applying it in diverse areas.
> >
> > Publishers can smell this and would not put their efforts into
> > tree-killing for the second language. Entire forests, however,
> > would be slaughtered in the name of the second language, to buy
> > Mercedes automobiles for the publishing executives.
>
> If this is true, why are there so many Python books all of a sudden?
I wouldn't have described the situation as "so many", rather "so few",
but a quick Amazon search shows 30-odd Python books published or soon
to be, so maybe "all of a sudden" is the key. I thought there were
only ten!
I think, however, the trick is that with PHP the books were probably
being written with or even before the hype, and probably even
contributed directly to the sudden popularity. After all, when someone
sees four whole shelves shouting ASP or PHP, surely that must be
one of the best languages ever invented. Four lone books (one written
in 1995) dispersed across three sections of the bookstore clearly
indicate a dying language with a lack of focus....
Which means if Python's popularity has grown to the point of
attracting significant publisher attention, then as you say "The number
of books is a pretty good indication of a languages' growth. The only
problem is that it is an indicator that trails badly."
I stand corrected. :)
> Publishers clearly believe that Python is going to be a big thing.
Well, maybe if we could measure, sometime in the future when the
user base of Python and PHP is identical (not sure which is
actually larger now, mind you), publisher revenues from the books,
I might still be sort of right... I can't believe Python will
end up with the volume of five-inch thick books that PHP and
its ilk have barfed forth.
Paul Prescod
>
> ...
>
> Well, maybe if we could measure, sometime in the future when the
> user base of Python and PHP is identical (not sure which is
> actually larger now, mind you), publisher revenues from the books,
> I might still be sort of right... I can't believe Python will
> end up with the volume of five-inch thick books that PHP and
> its ilk have barfed forth.
I still think that you have too much faith that the actual technical
features of the topic have any real effect on the structure of the books
(or the market). Once you move past the first ten books written by
zealots and early adopters, the rest are written by people like "the
Deitels" who have a structure and are looking for content to pour into
it.
That isn't necessarily a bad thing -- people who buy a book from the
Deitels (or the Dummies series or ...) know exactly what they are going
to get! As long as they don't do too much damage to the content pouring
it into their form, it doesn't seem so terrible. Sometimes books by the
"writing experts" are better than those by the technical experts. And
sometimes they are worse.