New project coming up...stay with Python, or go with a dot net language??? Your thoughts please!

[spiffo]

The Main Issue in a nutshell

I am a corporate developer, working for a single company. Got a new project
coming up and wondering if I should stay with Python for this new, fairly
large project, are jump back on the 'safe' M$ bandwagon using a dot net
language? Cross platform is NOT an issue, but COMPLETE control/compatability
with MsSql Server (current and future versions) certainly is.

Quick History

Started out 10+ yrs ago using FoxPro, upgrading as Fox did, was a good
system but never really loved it due to many factors I won't get into now.

Did alot of work in Delphi, once version 5 came out... really loved it for
awhile. Began using MS SQL server as database.

Had a HUGE re-write of an old dos-based database system to do, did alot of
work on it in Delphi 7, but really began to have issues with Delphi, even
tho alot of it is fantastic.

As I was working on the re-write, had another smaller system to work up, so
I was going to have to do both at once... I began to look around for another
language as was having issues with Delphi, very long story short, I became
enthralled with Python, and using it, with wxWindows to write the interface,
and adodbapi.py to communicate with ms sql server, I did the other smaller
system.

To my big surprise, within a short time where I wrote a wrapper class that
emulated working with the Delphi ado record set object, around the very nice
(but somewhat limited) adodbapi.py module. For the windows user interface, I
also learned how to create wx resource files with the stock resource editor
and connect the controls to code. And using a free text editor (pspad) I was
MORE PRODUCTIVE than with the super-duper point and click visual Delphi.

Ok, I got the small system done very quickly, and dumped my problematic
delphi version of the big system, and re-worked it up with my thrown
together, totally free Python package, and I swear, had it finished before I
would have if I had stayed with the Delphi version.

Ok, time goes by, the big system continues to get improved etc... now all of
a sudden, the smaller system needs to grow big time, as it has morphed and
they need all these new things.

THE DILEMMA

Ok, I LOVE python, so that is not the issue, but, I am getting very worried
about it's growth. I recently re-visted the web looking at alot of projects
I assumed would be up and running by now from over a year ago, such as Boa
Constructor, Iron Python etc... it seems all these projects get started, but
never finished.

Also, more and more I need *complete* control of ms sql from my apps, which
is simply not available from the adodbapi module I got off the internet...
also, ms sql 2005 is getting ready to come out... what if the guy that wrote
adodbapi.py does not feel like upgrading it so it even works with MS SQL
SERVER 2005? Yeesh... you get the picture...

So, wondering if anyone else is having these concerns or not, and if not,
why etc... Any input appreciated.

Python lover, but worried,
diego

 

[D H]

Ok, I LOVE python, so that is not the issue, but, I am getting very worried
about it's growth. I recently re-visted the web looking at alot of projects
I assumed would be up and running by now from over a year ago, such as Boa
Constructor, Iron Python etc... it seems all these projects get started, but
never finished.

Also, more and more I need *complete* control of ms sql from my apps, which
is simply not available from the adodbapi module I got off the internet...
also, ms sql 2005 is getting ready to come out... what if the guy that wrote
adodbapi.py does not feel like upgrading it so it even works with MS SQL
SERVER 2005? Yeesh... you get the picture...

If everything revolves tightly around a microsoft product (ms sql 2005,
which isn't even released yet), you probably are boxed in more towards
other microsoft products. That's vendor lock-in for you. You might try
VS.NET 2005 and see if C# or VB.NET and the ADO.NET api work well for
you: http://lab.msdn.microsoft.com/vs2005/
Of course that plus ms sql 2005 will end up costing a great deal of
money. Plus none of it is cross-platform, but you already said you do
not need that.

There are free .NET alternatives like Mono, Sharpdevelop, boo (
http://boo.codehaus.org/ ) and nemerle, but they are not caught up with
..NET 2 stuff yet. Again, it hasn't even been released yet, and there
are still bugs in their beta versions.
So it wouldn't surprise me if the python libraries can't handle ms sql
2005-specific stuff yet either.

So, if you need a short answer now, I'd say go with vs.net 2005, but if
you can afford to wait a while, free python and .net alternatives will
catch up.

 

[Rob Cowie]

Perhaps with the time saved by using Python instead of C# or some such,
you could help to improve adodbapi.py, ensuring support for the next
version of MS SQLServer, although that might be of little help in the
short term. Just a thought.

Also, have a gander at http://www.object-craft.com.au/projects/mssql/
I have no knowledge of it, but it may prove useful to you.

 

[Steven D'Aprano]

The Main Issue in a nutshell

I am a corporate developer, working for a single company. Got a new project
coming up and wondering if I should stay with Python for this new, fairly
large project, are jump back on the 'safe' M$ bandwagon using a dot net
language?

What makes you think dot net will be any safer than the last half dozen
"bet the farm" technologies Microsoft used?

http://lwn.net/Articles/85797/?format=printable

(Disclaimer: the author is my boss.)

Cross platform is NOT an issue, but COMPLETE control/compatability
with MsSql Server (current and future versions) certainly is.

How can you have COMPLETE (your emphasis) control over software when you
don't have access to the source code?

[snip]

Ok, I LOVE python, so that is not the issue, but, I am getting very worried
about it's growth. I recently re-visted the web looking at alot of projects
I assumed would be up and running by now from over a year ago, such as Boa
Constructor, Iron Python etc... it seems all these projects get started, but
never finished.

I'm not sure what you are trying to say here.

Why do you care if "a lot of projects" are not finished? Do you need them?
Why waste time worrying about projects that don't interest you?

What do you mean by "finished"? To my mind, a finished project is an
obsolete project that nobody is working on any more. Is that a good thing?
Is MS SQL "finished"?

Also, more and more I need *complete* control of ms sql from my apps, which
is simply not available from the adodbapi module I got off the internet...
also, ms sql 2005 is getting ready to come out... what if the guy that wrote
adodbapi.py does not feel like upgrading it so it even works with MS SQL
SERVER 2005? Yeesh... you get the picture...

Then you could offer him some money to support it.

Or, if it is Open Source software, you could support it yourself, or hire
a consultant to do it. How much is it worth to you? What would it cost you
to *not* use Python?

If it would cost you $100,000 to develop your app in Python, and $200,000
to develop it in the alternatives, then that gives you a war-chest of
$100,000 you can spend.

(Disclaimer: the company I work for does that sort of consulting and
development work.)

How much money will you save by dropping MS SQL licence fees by migrating
to MySQL or Postgres? Will that money saved be enough to hire a full-time
developer to keep adodbapi updated?

 

[Max M]

The Main Issue in a nutshell

I am a corporate developer, working for a single company. Got a new project
coming up and wondering if I should stay with Python for this new, fairly
large project, are jump back on the 'safe' M$ bandwagon using a dot net
language?

Hehe ...

I can run my very first Python program right now in the current version
of Python. I cannot even find a platform to run my .asp code from that
same timeframe ... So much for 'safe'!


--

hilsen/regards Max M, Denmark

http://www.mxm.dk/
IT's Mad Science

 

[=?iso-8859-1?q?Lasse_V=E5gs=E6ther_Karlsen?=]

While Microsoft and other big software vendors might have a roadmap
that ties you very tightly in with their budget, and also changes that
roadmap from time to time which breaks your current software, a lot of
open source projects have no roadmap at all.

This means that a .x.y.2 upgrade might very well kill your software in
the same way a 6-7 upgrade with VB might. The biggest reason for this,
as far as I can tell, is that open source projects are very much built
to integrate with other projects, simply because the source is
available and it's thus far easier to integrate them, but that also
means that unless you upgrade two integrated projects at the same time,
you risk an upgrade in one breaking the other.

As an example, Komodo from ActiveState has serious problems (on my 4
computers) debugging functions with Python 2.4.2. Right now I don't
know if Python 2.4.2 fixed a bug Komodo depended on or if 2.4.2
introduced a bug breaking Komodo, or if my computer is some freaky
thing that just refuses to behave. I'm reinstalling my office computer
these days so I'll see what happens then, but until that's done, I've
had to go back to 2.4.1 in order to debug properly.

With a 6.0 to 7.0 upgrade for a project, I expect problems. Even
Microsoft came out and said this new release will definitely break your
software projects. The whole point of an upgrade is that something that
did X before, does Y now, something different. Preferrably Y = X+1, but
sometimes it's radically different.

I think a main point in a lot of projects is that unless you have to
upgrade, don't. That way you can avoid a lot of problems by default.

Now, as for OP, the only way to easily get full support for all the new
Microsoft technology when it comes out will probably be to upgrade to
the latest and the greatest of the Microsoft tools. I bet the Python
community will react quicker than you can turn your head, but the tools
will still not be the same as Microsoft. Does it mean they won't be as
good ? No, it means they will be different. It means that you probably
can't follow Microsoft help when dealing with Python modules.

And that, is exactly as it should be.

 

[=?iso-8859-1?q?Lasse_V=E5gs=E6ther_Karlsen?=]

Ok, when re-reading my post it seems that I'm saying that Python has no
roadmap. That was not my intent. I meant projects other than Python,
even though the problems I got with 2.4.2 is real, I suspect there's
something in Komodo that is the problem since I can run all my python
programs with 2.4.2 without problems, just not in Komodo.

I'll go wash my mouth now

 

[Peter Decker]

I am a corporate developer, working for a single company. Got a new project
coming up and wondering if I should stay with Python for this new, fairly
large project, are jump back on the 'safe' M$ bandwagon using a dot net
language? Cross platform is NOT an issue, but COMPLETE control/compatability
with MsSql Server (current and future versions) certainly is.

Quick History

Started out 10+ yrs ago using FoxPro, upgrading as Fox did, was a good
system but never really loved it due to many factors I won't get into now..

Did alot of work in Delphi, once version 5 came out... really loved it for
awhile. Began using MS SQL server as database.

Had a HUGE re-write of an old dos-based database system to do, did alot of
work on it in Delphi 7, but really began to have issues with Delphi, even
tho alot of it is fantastic.

Hey, you might want to take a look at Dabo <http://dabodev.com>. It
was written by a couple of ex-Fox guys, and is a complete 3-tier app
framework. They support several databases on the backend, and have
announced that they are looking for someone to help them add MS-SQL to
that list.

 

[Luis M. Gonzalez]

Boa Constructor, Iron Python etc... it seems all these projects get started,

but never finished.

I don't know Boa (never liked it, never used it), but you could try
PythonCard: much higher level, easier and more productive. As for
Ironpython seems to be moving full steam towards a stable release
(current version is 0.9.2). And once it's ready, integration with other
MS technologies will be assured, so you shouldn't be concerned about
that.
If not Ironpython, Boo (which could be considered almost an static
version of Python for .NET) would be a great choice. It is already
integrated to SharpDevelop and soon it will be compliant with .NET 2.0.

It seems your concerns are all related to the future, and I think that
no matter what implementation of python you use, the future looks
brighter than ever, because the same code base will run on .NET, Pypy
(which will support many platforms) and java (through Jython) .

What other language gives you so many options?

 

[Benji York]

If not Ironpython, Boo (which could be considered almost an static
version of Python for .NET) would be a great choice.

You could also use Python for .Net
(http://www.zope.org/Members/Brian/PythonNet).

 

[Istvan Albert]

Disclaimer: this is not a flame against Boo.

It just boggles my mind that a language that describes itself as
"python inspired syntax" keeps being touted as:

Luis M. Gonzalez wrote:
Boo (which could be considered almost an static version of Python for .NET)

Boo is *nothing* like a static version of Python. Stop perpetuating
this nonsense.

 

[Paul Boddie]

While Microsoft and other big software vendors might have a roadmap
that ties you very tightly in with their budget, and also changes that
roadmap from time to time which breaks your current software, a lot of
open source projects have no roadmap at all.

This means that a .x.y.2 upgrade might very well kill your software in
the same way a 6-7 upgrade with VB might.

I think this explanation confuses the term roadmap with general release
discipline. A lot of open source projects are, well, open about things
like API stability and will label their stuff as "alpha" if things are
going to change frequently - one complaint heard relatively often is
that many open source projects are reluctant to put out a 1.0 release
because they don't consider their work to be finished. Meanwhile, many
open source projects do try and preserve consistency between
micro-releases, with any inconsistency being a fault that should be
raised with the maintainers - such faults being a phenomenon not
limited to open source software, either.

The biggest reason for this, as far as I can tell, is that open source projects are very
much built to integrate with other projects, simply because the source is
available and it's thus far easier to integrate them, but that also
means that unless you upgrade two integrated projects at the same time,
you risk an upgrade in one breaking the other.

I'm not sure whether source availability is really the problem here.
I've experienced micro-release breakage and it was due to the
integration of lots of different libraries, many of which were upgraded
in the process of making the new micro-release of the software in
question, but with some of the more egregious breakage coming about
because in some micro-update of one of the libraries, the author
decided to radically change the available features of that library.
Since this was all Java-based, source availability really wasn't a
factor (these were all .jar files, after all); the problem could be
boiled down to good old release discipline: if one of your dependencies
plays fast and loose with API stability, expect some users to get
caught out.

If package maintainers make transitions of their software from release
2.4.2 to release 2.4.3 involve significant rewrites of your own
application, my advice involves either avoiding such packages from the
beginning or, if it's too late, considering what would be necessary to
maintain/subvert acceptably stable versions of them.

I think a main point in a lot of projects is that unless you have to
upgrade, don't. That way you can avoid a lot of problems by default.

This is good advice! The big difference between open source and
Microsoft, however, is that you can feasibly choose not to upgrade to
the next bloated/misguided release of some software and yet attempt to
roll in all the security updates and useful enhancements whose absence
would otherwise expose your applications to misuse or obsolescence.
Either path can involve a lot of hard work, but at least you get the
choice with open source software.

Paul

 

[D H]

Disclaimer: this is not a flame against Boo.

It just boggles my mind that a language that describes itself as
"python inspired syntax" keeps being touted as:




Boo is *nothing* like a static version of Python. Stop perpetuating
this nonsense.

There is no static version of python, only a proposal[1] which was
quickly stomped on and revised to be about slower runtime type-checking:

def gcd(a: int, b: int) -> int:
while a:
a, b = b%a, a
return b

The boo equivalent is: (http://boo.codehaus.org/)

def gcd(a as int, b as int) as int:
while a:
a, b = b%a, a
return b

Looks "nearly identical" to me.

(Istvan has been a long spewer of anti-boo FUD on this list)

[1] http://www.artima.com/weblogs/viewpost.jsp?thread=85551

 

[Luis M. Gonzalez]

If you read again my comment, I said "almost" an static version of
Python for .NET.
That means that it's not a Python implementation, but another language.
It takes a lot from python though, and it is aknowledeged by its
creator in the first paragraph of its homepage.

And if you still feel the need to argue, please don't do it with me, do
it with Guido Van Rossum himself, who said that Boo is 95% Python, but
statically typed...
http://aws.typepad.com/aws/2005/01/amazon_devcon_g_5.html
Although he makes clear that he doesn't want python to become Boo.

So, we can safely say that Boo is "almost" a static python
implementation. Wether you like or not, is another problem, but please,
do not insist with your reiterative anti-boo ranting.

I'm not a Boo evangelist and I don't think I'm perpetuating any
"nonsense". I just made a simple comment in reply to an specific
question, and I think this comment is very pertinent.

 

[Paul Boddie]

So, we can safely say that Boo is "almost" a static python
implementation. Wether you like or not, is another problem, but please,
do not insist with your reiterative anti-boo ranting.

I can't comment on Boo beyond the documentation's description of the
language, but the question of what makes Python the language it is (or
was) - what one would need to add or remove to stop Python being Python
- remains very interesting. Boo appears to have some relatively simple
type inference (compared to things like Shedskin) and has various
static typing constraints presumably to fit the underlying virtual
machine. Seeing through the syntax, do such things keep it sufficiently
like Python? (Remember that Java looks like C++ but it has been
suggested that it is closer to Smalltalk in character.)

Looking not very far down the description of Boo's type inference [1]
reveals some pretty fundamentally different semantics, although one
could argue that they are "better" according to some criteria. I'd
argue, considering other evidence, that Boo isn't enough like Python to
be a kind of Python - not necessarily a criticism, though, but an
observation. Meanwhile, the temptation to add similar type annotations
to Python should be resisted, in my view, since the book certainly
isn't closed on alternative strategies for compile-time checking and
program optimisation.

Paul

[1] http://boo.codehaus.org/Type+Inference

 

[Luis M. Gonzalez]

that Boo isn't enough like Python to

be a kind of Python - not necessarily a criticism, though, but an
observation.

This is correct. I completely agree with you and I'm not saying that
boo is python.
Again, I just said that it could be considered "almost" a static python
implementation for .NET. It has many similarities, but also some
fundamental differences, therefore, it is a different language.

However, I think its similarities make it "pythonic" enough (or closely
related to python) to be considered, commented and appreciated by the
people in this mailing list.

Unfortunately, others disagree with this idea, and insist (over and
over again) that Boo is not python or that it has nothing to do with
it.

 

[Istvan Albert]

It has many similarities, but also some fundamental differences,

considered "almost" a static python

lol, if that is your definition of 'almost' then your statement is
correct

 

[Cameron Laird]

.
.
.

I am a corporate developer, working for a single company. Got a new project
coming up and wondering if I should stay with Python for this new, fairly
large project, are jump back on the 'safe' M$ bandwagon using a dot net
language? Cross platform is NOT an issue, but COMPLETE control/compatability

.
.
.
While I know others in this thread have already mentioned the
fact somewhat obliquely, I'll make it explicit: Python IS "a
dot net language" <URL: http://ironpython.com/ >.

 

[Bugs]

Another page with up to date IronPython information:
http://www.gotdotnet.com/workspaces/workspace.aspx?id=ad7acff7-ab1e-4bcb-99c0-57ac5a3a9742