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

Is Python suitable for a huge, enterprise size app?

P: n/a
The company I work for is about to embark on developing a commercial
application that will cost us tens-of-millions to develop. When all is
said and done it will have thousands of business objects/classes, some
of which will have hundreds-of-thousands of instances stored in a DB.
Our clients will probably have somewhere between 50-200 users working
on the app during the day, possibly in mutiple offices, and then a
large number of batch processes will have to run each night. It will
also need to have a web interface for certain users. It needs to be
robust, easy to maintain, and able to be customized for each client.

Right now it looks like Java is the language of choice that the app
will be developed in. However, I have been looking and reading a lot
about Python recently and it seems to me that Python could handle it.
The big attraction to me is the developer productivity. It seems that
if Python can handle it, then we could gain a huge savings by using
Python instead of Java from a productivity standpoint alone.

So, given the very general requirements in the first paragraph, do you
think that Python could handle it? If anyone has direct experience
developing large apps in Python, I would appreciate your insight.
Based on the responses I get, I am planning on writing a proposal to my
management to consider Python instead of Java.

Thanks,
John

Jul 19 '05 #1
Share this Question
Share on Google+
53 Replies


P: n/a
The answer seems to be yes. See http://www.artima.com/intv/speed.html

HTH,
Bernd

Jul 19 '05 #2

P: n/a
> So, given the very general requirements in the first paragraph, do
you
think that Python could handle it? If anyone has direct experience
developing large apps in Python, I would appreciate your insight.

I wouldn't, especially[1] if your thousands of business objects get
allocated/deallocated as the system runs. Currently python's memory
usage can grow rapidly (from the perspective of the o/s) when large
numbers of objects are repeatedly created and freed.

On the other hand, you could use a combination of python and C++
(perhaps using boost's python wrapping code). The ability to create
C/C++ modules is a "get out of jail free card" - if you did manage to
convince your company to go with python, and it fell short in some
area, a custom C module could be a handy trick.

Perhaps you could compare your project to existing large python
projects; like Zope maybe?

[1] if the objects in the system are static, rather than dynamic, of
course this is not an issue. My "I wouldn't" comes from the fact that
your requirements include "lots of object" as a feature, and no word on
how they will be used.

Good luck anyway :-)
Keir.

Jul 19 '05 #3

P: n/a
I don't see anything listed that would eliminate Python. You
may want to take a quick look at some of the rather large
applications that have been done with Zope (written in Python).
Zope might even be a good application platform to build upon
(can't say for sure, not enough detail about application).
Even if you don't want to use all of Zope the ZODB is a well
tested persistent Python object store that might prove
helpful.

There are many other projects supporting WAY more than 200
users that are written in Python.

-Larry Bates

john67 wrote:
The company I work for is about to embark on developing a commercial
application that will cost us tens-of-millions to develop. When all is
said and done it will have thousands of business objects/classes, some
of which will have hundreds-of-thousands of instances stored in a DB.
Our clients will probably have somewhere between 50-200 users working
on the app during the day, possibly in mutiple offices, and then a
large number of batch processes will have to run each night. It will
also need to have a web interface for certain users. It needs to be
robust, easy to maintain, and able to be customized for each client.

Right now it looks like Java is the language of choice that the app
will be developed in. However, I have been looking and reading a lot
about Python recently and it seems to me that Python could handle it.
The big attraction to me is the developer productivity. It seems that
if Python can handle it, then we could gain a huge savings by using
Python instead of Java from a productivity standpoint alone.

So, given the very general requirements in the first paragraph, do you
think that Python could handle it? If anyone has direct experience
developing large apps in Python, I would appreciate your insight.
Based on the responses I get, I am planning on writing a proposal to my
management to consider Python instead of Java.

Thanks,
John

Jul 19 '05 #4

P: n/a
Would the allocation/deallocation memory usage issue be different than
it would be with Java? Both Python and Java have automatic garbage
collection, correct? Is Python's not as effective as Java's? I think
the memory issues for the two languages would be similar in this area,
but maybe I am wrong.

John

Jul 19 '05 #5

P: n/a
"keirr" <ke***********@gmail.com> writes:

[snap]
I wouldn't, especially[1] if your thousands of business objects get
allocated/deallocated as the system runs. Currently python's memory
usage can grow rapidly (from the perspective of the o/s) when large
numbers of objects are repeatedly created and freed.
Isn't it true that in recent Python releases, one may replace the
default GC with custom one?
On the other hand, you could use a combination of python and C++
(perhaps using boost's python wrapping code). The ability to create
C/C++ modules is a "get out of jail free card" - if you did manage
to convince your company to go with python, and it fell short in
some area, a custom C module could be a handy trick.


In fact, it is not a trick -- combining C with Python is fairly
approved way of speeding up the app :)

--
http://www.peter.dembinski.prv.pl
Jul 19 '05 #6

P: n/a
>> I wouldn't, especially[1] if your thousands of business objects get
allocated/deallocated as the system runs. Currently python's memory
usage can grow rapidly (from the perspective of the o/s) when large
numbers of objects are repeatedly created and freed.
Isn't it true that in recent Python releases, one may replace the
default GC with custom one?


Good point. Indeed, since you have the source code you can change
anything you like. My warning was aimed at a specific situation, and
was meant to be a 'keep this in mind' comment (I phrased it as "don't
use python" really because I expected the majority of the responses to
be "do use python", and thought a bit of balance would be helpful).

As for a custom garbage collector, there has been a little discussion
about the gc code (on this group). My feeling is, if it was easy to
make it better someone would have done it already. Note I don't say
it's impossible (particularly with the resources the op mentioned),
just not straight-forward.

Of course, I wouldn't use Java, but that's another story '-)

Cheers,

Keir.

Jul 19 '05 #7

P: n/a
john67 wrote:
The company I work for is about to embark on developing a commercial
application that will cost us tens-of-millions to develop. [snip] Right now it looks like Java is the language of choice that the app
will be developed in. However, I have been looking and reading a lot
about Python recently and it seems to me that Python could handle it.
The big attraction to me is the developer productivity. It seems that
if Python can handle it, then we could gain a huge savings by using
Python instead of Java from a productivity standpoint alone.

So, given the very general requirements in the first paragraph, do you
think that Python could handle it?


Yes.

Python has good database support, it works well on a wide range of platforms,
and it's great at tying together different processes, machines, etc. - for
example, it's fairly easy to get Python to access C code, dynamic libraries,
system APIs, and external programs. It's easier to test than Java code as well,
and the overal cost of change is lower.

The concise nature of the language means that what would otherwise be a "huge"
enterprise app in Java might just be a "large" enterprise app in Python - the
project will not reach that unwieldy size as quickly, if ever.

The Google archives of this group have this topic covered in various ways many
times over - IMO Python is great for smallish apps, but its advantage over e.g.
Java actually *increases* with the size of the app.

If you go the Python route, two of the main obstacles will be:

1) mindshare - getting people on board, getting them to overcome biases one way
or another, convincing them to really take the time to come up to speed on Python.

2) reducing the complexity of what you think you need to build. I don't know how
to better describe this, but in Java, for example, I'd have whole bunches custom
classes to do various tasks but the Python equivalent collapsed into a single
module. Anyway, I predict that it'll take you some time to convince yourself
that you simply won't need to build all of the same components as you otherwise
would, or that they'll often be vastly simpler.

-Dave
Jul 19 '05 #8

P: n/a
In article <11**********************@f14g2000cwb.googlegroups .com>,
john67 <te*******@gmail.com> wrote:
The company I work for is about to embark on developing a commercial
application that will cost us tens-of-millions to develop. When all is
said and done it will have thousands of business objects/classes, some
of which will have hundreds-of-thousands of instances stored in a DB.
Our clients will probably have somewhere between 50-200 users working
on the app during the day, possibly in mutiple offices, and then a
large number of batch processes will have to run each night. It will
also need to have a web interface for certain users. It needs to be
robust, easy to maintain, and able to be customized for each client.

Right now it looks like Java is the language of choice that the app
will be developed in. However, I have been looking and reading a lot
about Python recently and it seems to me that Python could handle it.
The big attraction to me is the developer productivity. It seems that
if Python can handle it, then we could gain a huge savings by using
Python instead of Java from a productivity standpoint alone.

So, given the very general requirements in the first paragraph, do you
think that Python could handle it? If anyone has direct experience
developing large apps in Python, I would appreciate your insight.
Based on the responses I get, I am planning on writing a proposal to my
management to consider Python instead of Java.

Jul 19 '05 #9

P: n/a
This thread:

http://mail.python.org/pipermail/pyt...ry/051255.html

discusses the problem with memory allocation in CPython. Apparently
CPython is not good at, or incapable of, releasing memory back to the
operating system. There are ways to compensate for this. I guess the
comment about C modules was meant as one way to do so, either by
reducing memory requirement in the first place (C data structures are
more compact than Python) or else by allocating and freeing memory
wholly in the C module, which perhaps does work as expected.

The web page for Evan Jones does not obviously indicate the status of
the improved memory allocator patch he was working on. I wonder if it
is coming along.

Incidentally, does anyone know the prospects for CPython to be made
stackless? Say in 2.5 or 2.9? Or will that always be an independent
project?

Jul 19 '05 #10

P: n/a
LOL! That is really funny, in a dark humor kind of way. I don't want
the project to fail either. I am not convinced that we will succeed if
we go the Java route. However, I am just a grunt in the chain and not
in a position to make the decision. I hope I can have some influence
on the decision though. I will be pleased if I can get someone to at
least seriously consider Python.

I understand your sentiment about not encouraging something that might
fail to be done in Python. Hopefully it won't come to that. Thanks
for the info on Phaseit apps.

John

Jul 19 '05 #11

P: n/a
EHP
> Python has good database support, it works well on a wide range of
platforms, and it's great at tying together different processes, machines,
etc. - for example, it's fairly easy to get Python to access C code,
dynamic libraries, system APIs, and external programs. It's easier to test
than Java code as well, and the overal cost of change is lower.


Python has good DB support - but only simple connectors (like JDBC).
ORM in Java (like Hibernate) are much better than ORM in Python (probably the
best is sqlobject). How you can write huge OO app without ORM ?
IMHO supporting libraries for bussiness apps are better in Java (don't flame
please).

EHP
Jul 19 '05 #12

P: n/a
Hi All--

john67 wrote:

LOL! That is really funny, in a dark humor kind of way. I don't want
the project to fail either. I am not convinced that we will succeed if
we go the Java route. However, I am just a grunt in the chain and not
in a position to make the decision. I hope I can have some influence
on the decision though. I will be pleased if I can get someone to at
least seriously consider Python.

I understand your sentiment about not encouraging something that might
fail to be done in Python. Hopefully it won't come to that. Thanks
for the info on Phaseit apps.


What you're going to run into are two major stumbling blocks. One,
Python's got no credibility with management types unless the
credibility's already there. "Python? Never heard of it. Tell me
about it. ... Oh, it's interpreted, is it? Interesting." You can
see Python going down the sewer pipes, right on their faces. Two,
security. "This python sounds pretty interesting. Tell me about the
security. How can we prevent people from stealing our source code,
which we just spent millions developing? ... Hmm, trust the developers
out there not to peek? Oh, sure, let's use it." (True, there are ways
around the second, but you're going to have to talk _very_ fast and have
ALL the answers before the management type gets to his/her office and
shuts the door in your face and on your idea.)

Metta,
Ivan
----------------------------------------------
Ivan Van Laningham
God N Locomotive Works
http://www.andi-holmes.com/
http://www.foretec.com/python/worksh...oceedings.html
Army Signal Corps: Cu Chi, Class of '70
Author: Teach Yourself Python in 24 Hours
Jul 19 '05 #13

P: n/a

john67 wrote:
Would the allocation/deallocation memory usage issue be different than it would be with Java? Both Python and Java have automatic garbage
collection, correct?


In recent Python versions the CPython interpreter offers a
cycle-collector which weakens the most profound counter argument
against reference-counting techniques.

To answer Your initial question: there is probably no technical reason
against Python as a language or the CPython runtime. Both are very
stable and mature. Extension and optimization techniques are well
understood. The library support is great. I would be more concerned
about the development strategy. Be aware that Python is weak in
defining constraints on interfaces even more than Java ( Javas static
type system makes a bit easier what doesn't mean that static typing is
a really adequate solution for it at all ). There are almost no
declarative elements in the language. You have somehow to think about
communicating contracts between different developers across the team.
Elements of lightweight methodologys like continous integration and
early unit-testing are mandatory, not optional. Be also aware that
there are no IDEs / GUI-builders and UML-designers which are comparable
to those for Java or dotNET. You won't come as close to a group
consensus as if You would stick to VisualStudio7 for C#, or
IDEA/Eclipse for Java.

Regards,
Kay

Jul 19 '05 #14

P: n/a
EHP wrote:
Python has good database support, it works well on a wide range of
platforms, and it's great at tying together different processes, machines,
etc. - for example, it's fairly easy to get Python to access C code,
dynamic libraries, system APIs, and external programs. It's easier to test
than Java code as well, and the overal cost of change is lower.

Python has good DB support - but only simple connectors (like JDBC).
ORM in Java (like Hibernate) are much better than ORM in Python (probably the
best is sqlobject). How you can write huge OO app without ORM ?


I don't doubt that Hibernate is more mature, but having not used it, I can't
really say how much better/worse it is than, say, sqlobject for Python. But, as
you pointed out, there *are* ORM libraries for Python.

FWIW, the only times I've been involved in database-centric projects with a cost
in the "tens of millions", the database team steered clear of any sort of any
automatic ORM layer altogether. Depending on your application, an ORM can fall
into the same category as, say, EJB - a nifty idea that looks great on paper but
can cause more problems than it solves.

Just because the app itself is very OO, it doesn't always follow that the
database level needs to be - there are lots and lots of problems for which
normal RDBMS tables & joins are a pretty darn good fit. (I'm not trying to
discount ORM layers or even object databases, just disagreeing with the notion
that huge OO apps automatically require ORM)

Have fun,
-Dave
Jul 19 '05 #15

P: n/a
On Wed, May 18, 2005 at 08:37:00AM -0700, john67 wrote:
The company I work for is about to embark on developing a commercial
application that will cost us tens-of-millions to develop. When all is
said and done it will have thousands of business objects/classes, some
of which will have hundreds-of-thousands of instances stored in a DB.
Our clients will probably have somewhere between 50-200 users working
on the app during the day, possibly in mutiple offices, and then a
large number of batch processes will have to run each night. It will
also need to have a web interface for certain users. It needs to be
robust, easy to maintain, and able to be customized for each client.

[snip]

The technical specifications seem OK, these aren't language constraints
in python more than any other language. The people constraints...

Tens of millions to develop? Whoa - it is easy for me to predict absolute
and complete failure right off the bat no matter the language (but only
after incurring cost overruns). If your head is anywhere near the chopping
block I suggest proffering a "proof of concept" version first. If you
can't do a first version in six months with a team of six people it is a sign
that you don't really know what you want. The final version might be
bigger and have more features - but 10M of features is pie in the sky stuff.
Everyone involved must have wild dreams about how awesome the final version
will be, and all those dreams diverge.

Ten million is ten guys writing for two years (top notch at US prices) to come
up with a product from sratch. Tens of millions is? Best of luck.

-jackdied
Jul 19 '05 #16

P: n/a
Ivan Van Laningham wrote:
... Oh, it's interpreted, is it? Interesting." You can
see Python going down the sewer pipes, right on their faces.


Nahh, the right answer is "It's byte-compiled, just like Java."

Andrew
da***@dalkescientific.com

Jul 19 '05 #17

P: n/a
"Ivan Van Laningham" wrote:
What you're going to run into are two major stumbling blocks. One,
Python's got no credibility with management types unless the
credibility's already there. "Python? Never heard of it. Tell me
about it. ... Oh, it's interpreted, is it? Interesting." You can
see Python going down the sewer pipes, right on their faces. Two,
security. "This python sounds pretty interesting. Tell me about the
security. How can we prevent people from stealing our source code,
which we just spent millions developing? ... Hmm, trust the developers out there not to peek? Oh, sure, let's use it." (True, there are ways around the second, but you're going to have to talk _very_ fast and have ALL the answers before the management type gets to his/her office and
shuts the door in your face and on your idea.)


Another issue that hasn't been mentioned so far is staffing. You can
find java programmers and software engineers a dime dozen, but for
python it will be harder. The alternative of teaching python to a team
for a week or a month is IMO far too risky when you're talking about
millions; even if they are able to read or code fast in a new language,
they won't have grasped the idioms and the good programming techniques,
so they will be essentially mentally translating from java/c++/c#,
whatever their programming mother tongue is. On the bright side, in
python you won't have to try as hard to pick the few good programmers
among a sea of average/inexperienced/clueless ones that you'll have for
java.

Personally, although I find nothing comes close to the clarity and
flexibility that python offers, in this case I would go with java, if
for nothing else, to be on the safe side. Think about it: if the
project fails (and that's quite likely for huge projects, not dark
humour) and you've done it in python, everyone will blame python and
you who chose it; java OTOH belongs in the realm of "standard business
practices", so in a way "it's ok" to screw up, you did what everybody
else does. Yet another failed java enterprise project, nothing to see
here.

An idea that perhaps takes the best of both worlds is use java for the
high level architecture and static type interfaces, and write the bulk
of the implementation in jython. PSF has awarded a grant to make jython
catch up with cpython, and that's good news for making the transition
from java to python smoother to a large audience. Others may have more
to say on the pros and cons of going with java/jython instead of
cpython, but it seems a good compromise to me.

George

Jul 19 '05 #18

P: n/a

john67 wrote:
[...] that will cost us tens-of-millions to develop.
[...]
Right now it looks like Java is the language of choice that the app
will be developed in. However, I have been looking and reading a lot
about Python recently [...]


Ignoring the technical aspects: if you have good group of people that
already know Java, and don't know Python, then use Java for this huge
project. Do a smaller project in Python first for the learning curve,
to build expertise and confidence, etc. People are more important than
programming language.

Brian.

Jul 19 '05 #19

P: n/a
George Sakkis wrote:
Personally, although I find nothing comes close to the clarity and
flexibility that python offers, in this case I would go with java, if
for nothing else, to be on the safe side. Think about it: if the
project fails (and that's quite likely for huge projects, not dark
humour) and you've done it in python, everyone will blame python and
you who chose it; java OTOH belongs in the realm of "standard business
practices", so in a way "it's ok" to screw up, you did what everybody
else does. Yet another failed java enterprise project, nothing to see
here.


lol - I got a kick out of this post and I agree with it: *if* you're pretty sure
the project will ultimately fail, and you're planning for the best way to point
fingers and avoid the ax when it happens, then by all means, Java is the right
way to go. Java is the new "nobody ever got fired for buying IBM".

-Dave
Jul 19 '05 #20

P: n/a
Hi All--

George Sakkis wrote:

"Ivan Van Laningham" wrote:

An idea that perhaps takes the best of both worlds is use java for the
high level architecture and static type interfaces, and write the bulk
of the implementation in jython. PSF has awarded a grant to make jython
catch up with cpython, and that's good news for making the transition
from java to python smoother to a large audience. Others may have more
to say on the pros and cons of going with java/jython instead of
cpython, but it seems a good compromise to me.


And another option that you'll find has a great deal of viability is
using Python in the build process. Python's _wonderful_ to glue things
together, and its i18n capabilities are outstanding; I handled all the
internationalization and mock translation processes for a project near
the size you're describing in a dozen languages without working up a
sweat. Python is easily called by Ant, it deals really well with
unicode & utf-8, can easily parse Java resource files and XML files, and
you can stick all this stuff together in a few hours to handle _really
big builds_.

It's been nearly a year since the project failed and the company riffed
60 people from our site besides me, and the java monkeys that are left
are still using my Python scripts, in the same state I left 'em. They
can run them but they can't modify them. And every time they have to
produce a new mock-translation build, they complain to their boss: "We
used to have someone here who LIKED to do this stuff! And who could fix
it when it broke! We laid him off WHY????"

;-)

Metta,
Ivan
----------------------------------------------
Ivan Van Laningham
God N Locomotive Works
http://www.andi-holmes.com/
http://www.foretec.com/python/worksh...oceedings.html
Army Signal Corps: Cu Chi, Class of '70
Author: Teach Yourself Python in 24 Hours
Jul 19 '05 #21

P: n/a
George Sakkis wrote:
Personally, although I find nothing comes close to the clarity and
flexibility that python offers, in this case I would go with java, if
for nothing else, to be on the safe side.
"No manager got ever fired for buying IBM"
Think about it: if the
project fails (and that's quite likely for huge projects, not dark
humour) and you've done it in python, everyone will blame python and
you who chose it; java OTOH belongs in the realm of "standard business practices", so in a way "it's ok" to screw up, you did what everybody
else does. Yet another failed java enterprise project, nothing to see
here.


Hi George, You probably know the tale about Achilles and the turtle?
Where do You think Achilles would be located in the race against the
turtle if Zeno would have convinced him that motion is impossible? I
always thought that we Germans were hopeless pessimists ;)

It's a very funny logical loop inside this kind of arguments: don't use
great Python for grand multimillion $ projects because if You fail
everyone trashes cute Python and claims that it is not reliable for
grand projects and therefore will not be used for those.

Ciao,
Kay

Jul 19 '05 #22

P: n/a
Ivan Van Laningham wrote:
(snip)

What you're going to run into are two major stumbling blocks. One,
Python's got no credibility with management types unless the
credibility's already there. "Python? Never heard of it. Tell me
about it. ... Oh, it's interpreted, is it? Interesting."
Nope, Sir, it's byte-compiled just like Java. But you don't have to
invoke the compiler yourself...
You can
see Python going down the sewer pipes, right on their faces. Two,
security. "This python sounds pretty interesting. Tell me about the
security. How can we prevent people from stealing our source code,
which we just spent millions developing? ... Hmm, trust the developers
out there not to peek? Oh, sure, let's use it."
Just like Java, which is so easy to reverse-engineer...
(True, there are ways
around the second, but you're going to have to talk _very_ fast and have
ALL the answers before the management type gets to his/her office and
shuts the door in your face and on your idea.)


+1

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

P: n/a
"Steve M" <sj******@gmail.com> wrote
http://mail.python.org/pipermail/pyt...ry/051255.html

discusses the problem with memory allocation in CPython. Apparently
CPython is not good at, or incapable of, releasing memory back to the
operating system.


and unless your operating system is totally braindead, and thus completely unfit
to run huge enterprise size applications, that doesn't really matter much. leaks
are problematic, large peak memory use isn't.

(fwiw, I'm tempted to argue that people who don't understand how memory
allocation works on modern systems are unfit to run enterprise applications as
well, but that's another story).

btw, very few memory allocators "release memory back to the operating system"
for small allocations; most memory allocators, including Pythons, do that for large
allocations. try running this, and check the memory use after each step:
x = 10000000 * "x"
y = x[1:]
z = x[2:]
del z
del y
del z


still claiming that CPython's incapable of releasing memory back to the system?

(finding the smallest multiplier that gives the same effect is left as an exercise etc.)

</F>

Jul 19 '05 #24

P: n/a
Paul Rubin wrote:
2) If you want to display a gif image in tkinter, you can make a
frame object, put a canvas in it, and put a PhotoImage object
onto the canvas, which works fine. But if you use your own
subclass of frame (maybe to add your own gui stuff), for some
reason the gif doesn't display in the canvas.


did you read the PhotoImage documentation? see e.g. the note at the
bottom of this page:

http://effbot.org/zone/tkinter-photoimage.htm

(this used to be explained in the Python FAQ too, but it looks as if that
was lost in the great FAQ reorganization).

</F>

Jul 19 '05 #25

P: n/a
"Fredrik Lundh" <fr*****@pythonware.com> writes:
did you read the PhotoImage documentation? see e.g. the note at the
bottom of this page:

http://effbot.org/zone/tkinter-photoimage.htm
Thanks! I hadn't seen that. It explains what otherwise seemed
completely bizarre.
(this used to be explained in the Python FAQ too, but it looks as if that
was lost in the great FAQ reorganization).


I wouldn't have thought of looking there either. Do you think you
could mention it in your Tkinter doc? That would be a logical place
for it.
Jul 19 '05 #26

P: n/a
Paul Rubin <http://ph****@NOSPAM.invalid> writes:
... Do you think you
could mention it in your Tkinter doc? That would be a logical place
for it.


Ehhh, specifically I meant it would be good to mention this in the
PhotoImage example in Chapter 16 of "An Introduction to Tkinter" (The
Canvas Image Item). That's the example I followed and was confused as
heck why the image only appeared some of the time (I never saw it
actually appear and then disappear, but that's just luck).

Thanks again, I never would have figured this one out.
Jul 19 '05 #27

P: n/a
john67 wrote:
The company I work for is about to embark on developing a commercial
application that will cost us tens-of-millions to develop. When all is
said and done it will have thousands of business objects/classes, Ok, that sounds like a big app, but does it really have to be like
that, or is that something you imagine because things usually get
that complex using other tools?

In my experience, development costs grow faster than linearly with
class model size. (Of course, this is true regardless of programming
language.)

Prototyping things with Python is often an good way to discover simpler
ways of handling a problem, and it's not unheard of that a Python
prototype is good enough to keep as the final implementation.

Thus, apart from the fact that you typically meed much less code to
develop the same functionality in Python than in Java, you might also
discover that you can do things in a smarter way which reduces you
application size even more.

There are plenty of descriptions of successful use of Python at:
http://www.pythonology.com/

Of course, every language has a sweetspot, and particularly if you
have a bunch of experienced Java developers who will think in Java
idioms whatever language they code in, they might end up building
a really stupid system in Python. Perhaps you should also read:
http://dirtsimple.org/2004/12/python-is-not-java.html
http://dirtsimple.org/2004/12/java-i...on-either.html
some
of which will have hundreds-of-thousands of instances stored in a DB. That sounds like a moderately sized database.Hundreds of thousands of
new entries per month might be big if you need to keep data for years,
but this doesn't seem to be a limiting factor for you assuming a system
which uses a real database backend.
Our clients will probably have somewhere between 50-200 users working
on the app during the day, possibly in mutiple offices, and then a
large number of batch processes will have to run each night.
This is not a problem in itself. There are a number of different ways
to partition such a system between clients and different kinds of
servers, but it can certainly be done in Python.
It will
also need to have a web interface for certain users. It needs to be
robust, easy to maintain, and able to be customized for each client.
This sounds like a good fit. Python is at least excellent for the
customization part. I'll talk about how we do that here at Carmen
Systems at the Europython conference in June. Slides will be available.
Mail me if you want to have a look at a draft.

We basically use Python for customization and use C++ for the core code.
Python and C++ is a very good mix. Java and CPython might not be such
a good fit, but that depends a bit what your intentions with Java is.
(E.g. is JNI ok, or is hardware independence considered very important?)

Java/Jython is a better pair of course, but Jython has few maintainers
and is a few versions behind CPython.
Right now it looks like Java is the language of choice that the app
will be developed in. However, I have been looking and reading a lot
about Python recently and it seems to me that Python could handle it.
To be perfectly honest, I'd be very wary to stick out my neck and be
a Python champion if my trust in Python was based only on reading...
As a manager I'd also find it rather unconvincing...

Let me put it this way: Python has a potential to make your system
better, and to reach your goals in a shorter time. It fits very well
with an agile approach, and in most systems of the kind I imagine you
intend to build, agile development is very helpful in tracking project
progress. You produce *real* programs early, not a lot of paperwork
which a year later turns out to represent a misunderstanding of the
actual problem, or how an effective solution should behave.

I think it would be worthwile to investigate what Python could mean to
you. It might certainly be very useful in the toolbox of the developers.
It might be just a tool to aid in the development, it might be used as
a glue language to connect interacting components written in other
languages (Java, C++, C# etc), it might be an embedded macro language,
a prototyping tool, or the implementation language for at least parts
of the application.

After all, one tool is unlikely to fit all tasks.

Why not hire a well respected Python trainer for a few days, let a few
developers learn Python and explore how it could fit into your system.
The big attraction to me is the developer productivity. It seems that
if Python can handle it, then we could gain a huge savings by using
Python instead of Java from a productivity standpoint alone.
Quite possible, but the choice of programming language(s) is just one
of many very important decisions that determine the outcome of a
software development project.
So, given the very general requirements in the first paragraph, do you
think that Python could handle it? If anyone has direct experience
developing large apps in Python, I would appreciate your insight.
You might want to consult with e.g. Marc-Andre Lemburg, who has
experience in developing large business apps in Python. (See
http://www.egenix.com/ )
Based on the responses I get, I am planning on writing a proposal to my
management to consider Python instead of Java.


Consider suggesting it as a complement.
Jul 19 '05 #28

P: n/a
>>>>> "brian" == brian <br***@mirror.org> writes:

brian> to build expertise and confidence, etc. People are more
brian> important than programming language.

Or so you would think before writing sizeable software in C++.

--
Ville Vainio http://tinyurl.com/2prnb
Jul 19 '05 #29

P: n/a
You can
see Python going down the sewer pipes, right on their faces. Two,
security. "This python sounds pretty interesting. Tell me about the
security. How can we prevent people from stealing our source code,
which we just spent millions developing? ... Hmm, trust the developers
out there not to peek? Oh, sure, let's use it."

Just like Java, which is so easy to reverse-engineer...

It makes big difference (legally) to if the codes are there and someone
sees it, to if the codes are locked in some packaged or zipped form and
someone reverse-engineer it. It is legally as different as if you drop
money on the ground and I pick it up, to pick-pocketing you and take the
money.

Nobody seems to be able to understand this simple logic.

Yes, Java class files can be reverse-engineered quite easily but the act
of doing that is criminal, unless performed under specified Council
Directives (in EU) or under any statutory law in specific countries. But
the act of looking at the codes if it is there is not criminal, just
like reading a book in bookstore. If anyone can program in binary today,
no codes will be safe with them anyway...

maurice
Jul 19 '05 #30

P: n/a
"George Sakkis" <gs*****@rutgers.edu> wrote:
Another issue that hasn't been mentioned so far is staffing. You can
find java programmers and software engineers a dime dozen, but for
python it will be harder.


Yes, there are a lot more people out there who put Java on their resume
than put Python on their resume. Most of those so-called Java programmers
write total crap. Of course, there's a lot of crap written in Python too.
But since there're a lot more Java programmers out there, it stands to
reason that there's a lot more crappy Java programmers too.

It's a lot easier to teach a good programmer Python than it is to teach a
crappy programmer good software engineering skills.
Jul 19 '05 #31

P: n/a
In article <d6**********@news3.zwoll1.ov.home.nl>,
vincent wehren <vi*****@visualtrans.de> wrote:
Jul 19 '05 #32

P: n/a
Maurice LING wrote:
It makes big difference (legally) to if the codes are there and someone
sees it, to if the codes are locked in some packaged or zipped form and
someone reverse-engineer it. It is legally as different as if you drop
money on the ground and I pick it up, to pick-pocketing you and take the
money.

Nobody seems to be able to understand this simple logic.


So you're saying that reverse engineering Java bytecode is illegal,
while doing the same with Python bytecode is not? Or something like
that? (And you're a lawyer, right? Because if you're not, and you're
not citing your sources, why is it we should put any value in these
comments about what is (legally) true?)

-Peter
Jul 19 '05 #33

P: n/a
Paul Rubin wrote:
"Kay Schluehr" <ka**********@gmx.net> writes:
To answer Your initial question: there is probably no technical reason
against Python as a language or the CPython runtime. Both are very
stable and mature.

I'd like to agree with this but I just can't. Python is a great
language for prototyping and trying stuff out. It's fast and pleasant
to write. But you're right when you say that constant testing and
integration is absolutely necessary to develop anything substantial in
Python.

[snip] I'm in the middle of prototyping something in Python and it's going
pretty well despite occasional snags like those mentioned above. But
at the end of the day I don't think what we get will be solid enough
for use in production. We're planning to use the Python prototype to
get the feature set and protocols figured out, then reimplement in Java.
The OP might consider that approach.


You bring up some good points and I imagine the bugs you've encountered are
pretty frustrating, but I'm surprised at how different our experience has been.
I know my comments about Python probably come across a "total fan boy" - but for
us Python has been extremely positive.

We currently use Python, in production, in the following ways:

- custom HTTP web servers
- custom HTTP proxies
- behind-the-scenes log processors and other operational tools
- several Zope-based applications, both internally and externally facing
- both the client and server sides of a distributed work cluster
- the client side of a media encoding farm (server is a Zope app)
- a downloadable Windows client that our customer's customers use, that includes
a Windows COM server (an ActiveX control we implemented using ctypes).

Most of these have been in production for a year or more, with the oldest being
about 4 years (not a long time, but certainly long enough to be considered
stable). The toughest pieces initially were the Zope apps and the Windows COM
stuff - Zope because of documentation and COM because, well, it's COM.

During that time, the biggest problem we had with Python and its standard
libraries was one issue with socket.recv and memory allocation when doing lots
of receives. That lost us a few days of hunting for a memory leak, but we were
able to resolve it by looking at the C source. Another problem was the need to
call unlink (or something like that) on XML minidom elements in some
circumstances. Apart from that, we haven't encountered much of anything in terms
of bugs in the language or the standard library in *years*. In fact, I don't
recall encountering a bug in the language itself.

We've generally trailed the standard Python releases by about a year (although
this week I moved the encoding farm to Python 2.4.1, which is half a year
early). We don't use Tkinter. We don't use much outside the standard library: we
make heavy use of ctypes, psycopg (Postgres), and lately CherryPy, but that's
about it. So for us, the number of bugs in Python + stdlib has been really low.

One thing from your experience that did resonate with me is that, except for
ftplib and occasionally urllib (for basic, one-shot GETs), we don't use any of
the standard library's "protocol" modules - partly because we had to implement
our own HTTP libraries for performance and scalability reasons anyway, and
partly because we had trouble figuring out e.g. all the ins and outs of
urllib/urllib2/httplib.

Overall it's been such a positive experience for us that nobody in the company -
from grunt testers up to the CTO - has any reservations about using Python in
production anymore (even though initially they all did). All of the developers
have previous experience with using Java in production systems, and none
seriously consider it for new projects at all.

-Dave
Jul 19 '05 #34

P: n/a
In article <ma*************************************@python.or g>,
Fredrik Lundh <fr*****@pythonware.com> wrote:

(this used to be explained in the Python FAQ too, but it looks as if that
was lost in the great FAQ reorganization).


Send e-mail to we*******@python.org -- actually, you can have commit
privs if you want.
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"The only problem with Microsoft is they just have no taste." --Steve Jobs
Jul 19 '05 #35

P: n/a
aa**@pythoncraft.com (Aahz) writes:
Send e-mail to we*******@python.org -- actually, you can have commit
privs if you want.


I think I'm going to enter an SF bug on the issue if there isn't
already one. It's not obvious to me whether a reasonable fix is
possible, but at least it should be tracked. The current behavior is
weird and confusing.
Jul 19 '05 #36

P: n/a
Peter Hansen wrote:
Maurice LING wrote:
It makes big difference (legally) to if the codes are there and
someone sees it, to if the codes are locked in some packaged or zipped
form and someone reverse-engineer it. It is legally as different as if
you drop money on the ground and I pick it up, to pick-pocketing you
and take the money.

Nobody seems to be able to understand this simple logic.

So you're saying that reverse engineering Java bytecode is illegal,
while doing the same with Python bytecode is not? Or something like
that? (And you're a lawyer, right? Because if you're not, and you're
not citing your sources, why is it we should put any value in these
comments about what is (legally) true?)

-Peter


I am not saying reverse engineering Python bytecodes is legal while
reverse engineering Java bytecodes is illegal. Please do not put words
into my mouth, I am just saying "codes locked in some packaged or zipped
form", reverse engineering is illegal unless specifically approved, be
it Python bytecodes, Java bytecodes, Smalltalk, compiled executables etc
etc... AND THIS HAD BEEN DISCUSSED IN OTHER THREADS, like in "bytecode
non-backcompatibility" in April 2005 of python-list.

I am not a lawyer. Based on what I've read and seen, I won't try it.
Below is an example of such articles by a law firm, citating case laws.
Please google the term "reverse engineering computer sources" and you
will find heaps of materials. You might like to test the depth of your
pockets in courtroom, be my guest
From http://www.jenkins-ip.com/serv/serv_6.htm

COMPUTER PROGRAMS

In the case of computer programs, the EU directive states (11) that the
ideas and principles underlying a program are not protected by
copyright, and that (12) logic, algorithms and programming languages may
to some extent comprise ideas and principles.

Analysis of the function of a program (but not decompilation (13))is
permitted under Article 5.3, if it is carried out by a licensed user in
the normal use of the program.

Reverse engineering is allowed under Article 6, but only for the single
purpose of producing an interoperable program (rather than a competing
program).

For this purpose, in addition to reverse engineering itself (i.e.
producing a high level version of the code) subsequent forward
engineering to produce the interoperable program is permitted.

However, the reverse engineer has to cross a host of formidable barriers
before he can make use of this right;

1. It must be indispensable to reverse engineer to obtain the
necessary information.
2. The reverse engineering has to be by a licensee or authorised user.
3. The necessary information must not already have been readily
available to those people.
4. Only the parts of the program necessary for interoperability
(i.e. the interfaces) can be reproduced.
5. The information generated by the reverse engineering cannot be
used for anything other than achieving interoperability of an
independently created program.
6. The information cannot be passed on to others except where
necessary for this purpose.
7. The information obtained cannot be used to make a competing
program (rather than just an interoperable one).
8. The "legitimate interests" of the copyright owner or "normal
exploitation" of the program must not be prejudice.

Thus, far from creating a general right to reverse engineer, these
provisions create only the smallest of openings for the reverse
engineer; they are intended for use only to defeat locked, confidential,
proprietary interfaces.
(11) Council Directive 96/9/EC 11 March 1996; enacted in the UK as S.I.
1997 No. 3032 13th recital
(12) 14th recital
(13) See, for example, Copyright, Designs and Patent Act 1988, Section
29(4)

SEGA ENTERPRISES LTD v. ACCOLADE INC 977 F.2D 1510 (9TH CIR. 1992)

This US software copyright case concerned Sega's video game console and
cartridges. The cartridges had a 20-25 byte code segment which was
interrogated by the console, as a security measure.

Accolade disassembled the code which was common to three different Sega
games cartridges, to find the security segment, and included it in
competing games cartridges.

The Ninth Circuit held this disassembly to be a permitted "fair use" of
the copyright in the games programs.

ATARI v. NINTENDO 975 F.2D 872 (FED. CIR. 1992)

This US software copyright case concerned Nintendo’s NES video game
console and cartridges. The cartridges contained a microprocessor, and
program code, and was interrogated by the console microprocessor, as a
security measure, like the Sega system. The security was potentially a
two-way process, with the console checking for a valid cartridge and the
potential for the cartridge to check for a valid console (which Nintendo
did not actually do).

Atari disassembled the program code which performed the security
signalling exchange (the interface code). However, they also had access
to a copy of the source code from the US Copyright Registry, to obtain
which they stated (untruthfully) that it was for the purposes of litigation.

They implemented the signalling exchange to validate the cartridge, thus
achieving compatibility of their cartridges with Nintendo consoles.
However, they went further and implemented the rest of the interface, to
validate the consoles, apparently in case Nintendo changed their product
in future. In each case, they copied some actual code, allegedly only to
the extent necessary.

The Court held that the intermediate copying during reverse engineering
was legitimate, as "fair use". However, Atari infringed copyright
nonetheless, in going too far in copying beyond what was strictly
necessary. The programmer apparently also had sight of the source code
from the US Copyright Registry, casting some doubt on whether the
copying was solely due to the reverse engineering operation.

Finally, Nintendo had a patent on the interface, and Atari were found to
infringe that too.

AUTODESK INC v. DYASON [1992] RPC 575 & (NO. 2) [1993] 12 RPC 259

This Australian software copyright case concerned a CAD package, which
was supplied with a hardware device containing an EPROM, called the
AutoCAD lock, which operated with part of the package called the
"Widget-C" program. The program sent a challenge signal to the lock,
which replied with a return signal. The program checked the return
signal against a lookup table. The lookup table comprised 16 bytes of a
30kByte program. An encrypted form of the lookup table was held in the
lock EPROM.

The Defendant studied the signals with an oscilloscope, and read them.
Apparently, the correct contents of the EPROM were deduced from this
functional analysis, without reading of the EPROM. They then produced an
alternative lock device. The Plaintiff alleged that the table was a
substantial part of the program, and that the program had thus been copied.

The Court held that the table was a substantial part of the program (an
issue of importance rather than size) and that it had been copied, and
that this was an infringement. A move to re-hear the case, on the basis
that the Court had misunderstood, was dismissed (with dissenting
judgements).

POWERFLEX SERVICES PTY LTD v. DATA ACCESS CORP [1997] 12 EIPR 732

This Australian software copyright case concerned a database management
system (Dataflex) which was "cloned" by the Defendant. Apparently,
although the Court referred to reverse engineering, the Defendant did
not actually analyse the code by decompilation or disassembly, but read
the manual to produce a lookalike using the same commands and file
structures. All this was held not to infringe.

However, Dataflex used compression of records, using a stored table of
Huffman codes to compress and decompress. The table thus constituted an
interface between the program and the files. There is no indication that
the files were to be shared with other programs, so the table was not an
interface to non-competing interoperable programs. The Defendant wanted
his program to be able to read files created by Dataflex and so he
calculated the required compression table, apparently from inspection of
stored records, which therefore reproduced that of Dataflex.

It was held that although the table was not a substantial part of the
program (or even part of the program at all), it attracted literary
copyright as a compilation in its own right, and that copyright was held
infringed.

CREATIVE TECHNOLOGY LTD v. AZTECH SYSTEMS PTE LTD [1997] FSR 491

This Singapore software copyright case concerned the Sound Blaster PC
Sound Card It contained firmware, and was supplied with an ancillary PC
program to operate with it. The Defendants wanted to produce a sound
card which could interoperate with PC programs which would operate with
the Sound Blaster – in other words, to create a competing substitute.
They bought and studied a Sound Blaster and ancillary program. They were
held (on the balance of probabilities) to have disassembled and reverse
engineered the firmware, and admitted running the ancillary program
(which they pleaded as a "fair dealing"). In their product, only about
4% of the code was identical to that of the Sound Blaster firmware, but
that 4% included redundancies and errors present in the original,
suggesting copying (going beyond that which is necessary).

The Court held (reversing the first instance) that although the ultimate
products did not involve a substantial reproduction of the original
program, there was clear evidence that reverse engineering had been used
and hence that an intermediate copy had been made. This and the admitted
copying (in unlicensed use) of the ancillary program were both not "fair
dealing", and hence infringed.
Jul 19 '05 #37

P: n/a
Peter Hansen wrote:
Maurice LING wrote:
It makes big difference (legally) to if the codes are there and
someone sees it, to if the codes are locked in some packaged or zipped
form and someone reverse-engineer it. It is legally as different as if
you drop money on the ground and I pick it up, to pick-pocketing you
and take the money.

Nobody seems to be able to understand this simple logic.

So you're saying that reverse engineering Java bytecode is illegal,
while doing the same with Python bytecode is not? Or something like
that? (And you're a lawyer, right? Because if you're not, and you're
not citing your sources, why is it we should put any value in these
comments about what is (legally) true?)

-Peter


What I'm saying is reverse engineering anything is illegal unless
allowed by the laws of the state, be it <your language> bytecodes or
compiled executables, but if the original source codes are there, you
can see it.

To put it sexually and crudely (to get the idea across), if a female
strips and parade in front of me, I'm not violating any law to open my
eyes and look at it (whether morally or religiously right is a total
different matter) but it is criminal for me to grab any moving female,
strip her and look at her naked. Can see the point?

maurice
Jul 19 '05 #38

P: n/a

Dave Brueck wrote:
Overall it's been such a positive experience for us that nobody in the company - from grunt testers up to the CTO - has any reservations about using Python in production anymore (even though initially they all did). All of the developers have previous experience with using Java in production systems, and none seriously consider it for new projects at all.

-Dave


Think there is still a lack of communicating success on that scale. If
I think about serious IT magazines published in Germany ( e.g. "Object
Spectrum" ), there are tons of experience reports about all kinds of
enterprise systems, that were created and managed in Java/dotNET.

There might be a slight progress if you review some of the talks on the
next Europython conference:

http://www.python-in-business.org/ep...html?track=692

But this is still internal from the fans of the language to other fans.

Ciao,
Kay

Jul 19 '05 #39

P: n/a
Paul Rubin wrote:
Send e-mail to we*******@python.org -- actually, you can have commit
privs if you want.


I think I'm going to enter an SF bug on the issue if there isn't
already one. It's not obvious to me whether a reasonable fix is
possible, but at least it should be tracked. The current behavior is
weird and confusing.


this has been reported before, and it won't get fixed (unless you're volunteering
to add Python-compatible garbage collection to Tk, that is).

</F>

Jul 19 '05 #40

P: n/a
Sure it does not. As well as C, unless you instaead of malloc use low
level os-dependant APIs.

Jul 19 '05 #41

P: n/a
Dave Brueck <da**@pythonapocrypha.com> writes:
One thing from your experience that did resonate with me is that,
except for ftplib and occasionally urllib (for basic, one-shot GETs),
we don't use any of the standard library's "protocol" modules - partly
because we had to implement our own HTTP libraries for performance and
scalability reasons anyway, and partly because we had trouble figuring
out e.g. all the ins and outs of urllib/urllib2/httplib.


What do you use for HTTPS? And did you use the Cookie module in your
HTTP servers? You may have had problems without even being aware of
them (until recently if you used Cookie with its default settings, any
attacker could completely take over your server by sending you
carefully concoted cookies). I'm not trying to be contentious here,
just mentioning a couple further cases of where problems aren't
visible from far away but are there when you look close.
Jul 19 '05 #42

P: n/a
"Fredrik Lundh" <fr*****@pythonware.com> writes:
this has been reported before, and it won't get fixed (unless you're
volunteering to add Python-compatible garbage collection to Tk, that is).


Yeah, I think I understand what the issue is. I can think of some
kludgy possible fixes but I assume they've been thought about already
and rejected. The workaround of making the application save an extra
reference isn't too bad, but all relevant docs that say anything about
these images should mention the requirement emphatically.
Jul 19 '05 #43

P: n/a
Paul Rubin wrote:
Dave Brueck <da**@pythonapocrypha.com> writes:
One thing from your experience that did resonate with me is that,
except for ftplib and occasionally urllib (for basic, one-shot GETs),
we don't use any of the standard library's "protocol" modules - partly
because we had to implement our own HTTP libraries for performance and
scalability reasons anyway, and partly because we had trouble figuring
out e.g. all the ins and outs of urllib/urllib2/httplib.

What do you use for HTTPS?


Hi Paul,

m2crypto (plus some patches to make asynchronous SSL do what we needed).
And did you use the Cookie module in your
HTTP servers? You may have had problems without even being aware of
them (until recently if you used Cookie with its default settings, any
attacker could completely take over your server by sending you
carefully concoted cookies).


Are you referring to the use of pickle for cookie serialization? In any case, we
didn't use Cookie.py from the stdlib (on the servers, nearly everything related
to URLs & HTTP was custom-built, with the exception of urlparse, for the
aforemenioned reasons).

-Dave
Jul 19 '05 #44

P: n/a
C programs also can be disassembled. Serious people do not consider
braking the machine code harder byte-code.

Jul 19 '05 #45

P: n/a
Dave Brueck <da**@pythonapocrypha.com> writes:
What do you use for HTTPS?


m2crypto (plus some patches to make asynchronous SSL do what we needed).


That seems to be a nice piece of code, but it's still at version 0.13;
if something goes wrong, are you sure you want to explain that you
were using beta-test software to protect your customers' production
financial transactions? There's also been some traffic on the
python-crypto list about Zope encountering memory leaks with it. I
haven't read the messages carefully though, so I'm not sure what the
situation is.
did you use the Cookie module in your HTTP servers?...

Are you referring to the use of pickle for cookie serialization?


Yes.
Jul 19 '05 #46

P: n/a
Paul Rubin wrote:
Dave Brueck <da**@pythonapocrypha.com> writes:
What do you use for HTTPS?
m2crypto (plus some patches to make asynchronous SSL do what we needed).

That seems to be a nice piece of code, but it's still at version 0.13;


Version numbers are fairly relative, though. In another project we're using some
proprietary, closed source libraries (unrelated to crypto) that are version 3
and they seem buggier and less stable than m2crypto.

And don't get me started on Microsoft products (we've been using DirectShow *9*
in some stuff, and due to bugs in DirectShow we were completely and utterly
screwed despite what the documentation said; things just didn't work as they
should, and Microsoft has confirmed that it's a bug that will be fixed in some
future release - so we had to backtrack, ripping out code that should work just
fine, and take another stab at getting DirectShow to cooperate). Version NINE
(supposedly).
if something goes wrong, are you sure you want to explain that you
were using beta-test software to protect your customers' production
financial transactions?
lol - what? We're not doing any financial transactions with it (IOW - we
evaluated m2crypto for what we needed to do, and it's a good fit - that we
didn't evaluate it in terms of what we don't need it to do doesn't bother me).

Having said that - I think we probably *would* use it for production financial
transactions - but that's more a matter of closed vs. open source than Python vs
not.

Besides, do you really think that, if something went wrong, you'd in the end
have some meeting where you explain to your customer that you were using beta
software? Of course not - it just doesn't work that way. Either they won't care
and will drop you because of the problem (regardless of the source) or they want
some broad details.
There's also been some traffic on the
python-crypto list about Zope encountering memory leaks with it.


Ok... so? I mean, if there's a memory leak, and it's hurting us, we have
options: we can go look in the source code, we can make Zope reboot itself
often, we can hire somebody to fix it, we can see if the author wants to give us
a support contract, etc.

Memory leaks aren't exactly unique to Python - according to bugs.sun.com, there
are currently 382 *open* bugs related to memory leaks in the JDK alone. If
you're using Java in your "huge, enterprise size app" and get bit by one of
those bugs, and if you're not a big enough company to get some
ridiculously-priced support contract from Sun, what are your options? Again,
this seems more like an open-vs-closed source issue, but to me it's another
reason why I'd feel uncomfortable using Java in mission critical work.

-Dave
Jul 19 '05 #47

P: n/a
"Fredrik Lundh" <fr*****@pythonware.com> writes on Thu, 19 May 2005 09:54:15 +0200:
...
and unless your operating system is totally braindead, and thus completely unfit
to run huge enterprise size applications, that doesn't really matter much. leaks
are problematic, large peak memory use isn't.


Could you elaborate a bit?

Large peak memory use means that the application got a large
address space. What garantees that the residual memory use
(after the peak) is compact and not evenly spread across
the address space. While the OS probably is able to
reuse complete pages which are either unused for a longer
time or at least rarely accessed, it may become nasty when
almost every page contains a small amount of heavily used
memory.
Dieter
Jul 19 '05 #48

P: n/a
Dave Brueck <da**@pythonapocrypha.com> writes:
m2crypto (plus some patches to make asynchronous SSL do what we needed). That seems to be a nice piece of code, but it's still at version
0.13;


Version numbers are fairly relative, though. In another project we're
using some proprietary, closed source libraries (unrelated to crypto)
that are version 3 and they seem buggier and less stable than m2crypto.


Yeah, OpenSSL itself is something like 0.97, which however does sound
closer to a final release than 0.13 of anything.
Having said that - I think we probably *would* use it for production
financial transactions - but that's more a matter of closed vs. open
source than Python vs not.
That makes some sense; once you have the code in-house and the
expertise to evaluate it and maintain it, it's at least no worse than
something you wrote yourself. If you just downloaded it and plopped
it into your application with your eyes closed, that might be asking
for trouble.
There's also been some traffic on the
python-crypto list about Zope encountering memory leaks with it.


Ok... so? I mean, if there's a memory leak, and it's hurting us, we
have options: ...


I just mean the memory leak is a symptom that the software isn't yet
completely debugged.
Memory leaks aren't exactly unique to Python - according to
bugs.sun.com, there are currently 382 *open* bugs related to memory
leaks in the JDK alone.


Are any of those memory leaks in JSSE? It's one thing to have a
problem in some noncritical GUI widget, another to have it in the
crypto code.
Jul 19 '05 #49

P: n/a
Peter Hansen wrote:
Maurice LING wrote:
It makes big difference (legally) to if the codes are there and
someone sees it, to if the codes are locked in some packaged or zipped
form and someone reverse-engineer it. It is legally as different as if
you drop money on the ground and I pick it up, to pick-pocketing you
and take the money.

Nobody seems to be able to understand this simple logic.

So you're saying that reverse engineering Java bytecode is illegal,
while doing the same with Python bytecode is not? Or something like
that? (And you're a lawyer, right? Because if you're not, and you're
not citing your sources, why is it we should put any value in these
comments about what is (legally) true?)

-Peter


I think he's saying that if you distributed your python code as
byte-compiled module.pyc or module.pyo form, rather than ascii-text
module.py form, it would be harder for a reverse-engineer to say "But I
was JUST looking at it!". Especially when the lawyers are involved.

Joal Heagney
Jul 19 '05 #50

53 Replies

This discussion thread is closed

Replies have been disabled for this discussion.