473,785 Members | 2,380 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Article of interest: Python pros/cons for the enterprise

This is part of a series examining the strengths and weaknesses of
various scripting languages, with particular attention to enterprise
(read: big company) use.

You Used Python to Write WHAT?
Python is a powerful, easy-to-use scripting language suitable for use
in the enterprise, although it is not right for absolutely every use.
Python expert Martin Aspeli identifies when Python is the right
choice, and when another language might be a better option.
http://www.cio.com/article/185350
Feb 20 '08
62 2918
On Feb 21, 1:22 pm, Nicola Musatti <nicola.musa... @gmail.comwrote :
There are other downsides to garbage collection, as the fact that it
makes it harder to implement the Resource Acquisition Is
Initialization idiom, due to the lack of deterministic destruction.
That's not a downside: it's at least a wash.

In C++ you manage memory and the language manages resources. In
Python you manage resources and the language manages memory.

RAII is merely one way of minimizing complexity. Garbage collection
is another way.
Carl Banks
Feb 21 '08 #11
Carl Banks wrote:
On Feb 21, 1:22 pm, Nicola Musatti <nicola.musa... @gmail.comwrote :
>There are other downsides to garbage collection, as the fact that it
makes it harder to implement the Resource Acquisition Is
Initializati on idiom, due to the lack of deterministic destruction.

That's not a downside: it's at least a wash.

In C++ you manage memory and the language manages resources. In
Python you manage resources and the language manages memory.

RAII is merely one way of minimizing complexity. Garbage collection
is another way.
If you've already got a generic, language-supported way to manage
resources (like RAII with deterministic destruction), then why bother
with garbage collection? I'm not trying to knock it; it was a big step
up from C-style "who forgot to delete a pointer" games. It just seems
to me like a solution to something that's no longer a problem, at least
in well-written C++ code. I'll take destructors over GC any day.
Feb 22 '08 #12
On Feb 21, 7:17 pm, Jeff Schwab <j...@schwabcen ter.comwrote:
Carl Banks wrote:
On Feb 21, 1:22 pm, Nicola Musatti <nicola.musa... @gmail.comwrote :
There are other downsides to garbage collection, as the fact that it
makes it harder to implement the Resource Acquisition Is
Initialization idiom, due to the lack of deterministic destruction.
That's not a downside: it's at least a wash.
In C++ you manage memory and the language manages resources. In
Python you manage resources and the language manages memory.
RAII is merely one way of minimizing complexity. Garbage collection
is another way.

If you've already got a generic, language-supported way to manage
resources (like RAII with deterministic destruction), then why bother
with garbage collection?
Because now you have to manage memory? Did you read my post? You
have to manage one thing or the other.

I'm not trying to knock it; it was a big step
up from C-style "who forgot to delete a pointer" games. It just seems
to me like a solution to something that's no longer a problem, at least
in well-written C++ code. I'll take destructors over GC any day.
About 2% of the objects I creat have resources other than memory. I
would rather manage resources of 2% of objects than manage memory of
100%. YMMV, but I suspect mine is the more common opinion, if the
recent (like, 10-year) trend in programming languages is any
indication.
Carl Banks
Feb 22 '08 #13
On Feb 21, 11:17 am, "Reedick, Andrew" <jr9...@ATT.COM wrote:
So I wouldn't be
quick to dismiss the notion that Java/C#/C++ are more newbie-safe than
Python. =/

FWIW, when I posted my comment about C++, I was mocking the article
writer's notion that it was static typing and compile-time checking
that made Java and C# "safer" for newbies, by presenting an example
that clearly defied that. I was taking it for granted the C++ is
notoriously dangerous and newbie-unfriendly.

Obviously it is not a universal opinion (yet). Too bad.

But all I was really saying is that there are far more more important
things when it comes to "safety" than dynamic typing.
Carl Banks
Feb 22 '08 #14
Paul Rubin wrote:
It just seems to me that there is a killer language just around the
corner, with Python's ease-of-use but with a serious compile-time type
system, maybe some kind of cross between ML and Python.
Could Boo or Cobra fit the bill ? If not, what's missing at a
technical level (i.e. ignoring current maturity, community size,
marketing, etc.) ?

George
Feb 22 '08 #15
Jeff Schwab <je**@schwabcen ter.comwrites:
The most traditional, easiest way to open a file in C++ is to use an
fstream object, so the file is guaranteed to be closed when the
fstream goes out of scope.
Python has this too, except it's using a special type of scope
created by the "with" statement.
CPython offers a similar feature, since
you can create a temporary object whose reference count will become
zero at the end of the statement where it is defined:
$ echo world >hello
$ python
>>file('hello') .read()
'world\n'
CPython does not guarantee that the reference count will become zero
at the end of the statement. It only happens to work that way in your
example, because the file.read operation doesn't make any new
references to the file object anywhere. Other code might well do
something different, especially in a complex multi-statement scope.
Your scheme's determinism relies on the programmer accurately keeping
track of reference counts in their head, which is precisely what
automatic resource management is supposed to avoid. If you want
reliable destruction it's better to set it up explicitly, using
"with".
Feb 22 '08 #16
On Feb 22, 12:23 am, Jeff Schwab <j...@schwabcen ter.comwrote:
Carl Banks wrote:
On Feb 21, 7:17 pm, Jeff Schwab <j...@schwabcen ter.comwrote:
Carl Banks wrote:
On Feb 21, 1:22 pm, Nicola Musatti <nicola.musa... @gmail.comwrote :
There are other downsides to garbage collection, as the fact that it
makes it harder to implement the Resource Acquisition Is
Initializatio n idiom, due to the lack of deterministic destruction.
That's not a downside: it's at least a wash.
In C++ you manage memory and the language manages resourcewithout bringing
anything of particular value to the table.s. In
>Python you manage resources and the language manages memory.
RAII is merely one way of minimizing complexity. Garbage collection
is another way.
If you've already got a generic, language-supported way to manage
resources (like RAII with deterministic destruction), then why bother
with garbage collection?
Because now you have to manage memory? Did you read my post? You
have to manage one thing or the other.

Yes, I read your post. You seem to be saying there's some kind of
trade-off between automatic management of dynamically allocated memory,
and automated management of other kinds of resources. I don't
understand why you believe that, so I asked.

If you have proper RAII and deterministic destruction, the management is
of resources is consistent, and mostly automated.
If you have garbage collection, the management of memory is
consistent, and mostly automated.
Managing memory is
just not that difficult,
Managing resources is just not that difficult,
especially if the vast majority of objects are
allocated on the stack or in static memory.
Especially if the there are fewer resources to manage than there would
have been heap objects....
A special language feature
for managing dynamically allocated memory robs the programmer of a
reliable way to clean up resources automatically,
A special language feature more managing dynamically allocated robs
the programmer of a reliable way to free memory automatically,
without bringing
anything of particular value to the table.
without bringing
anything of particular value to the table.

It cuts both ways, chief.

You like managing your own memory, be my guest. But please don't
imply that you're putting forth less effort because of it. You're
just putting forth different effort.
Carl Banks
Feb 22 '08 #17
Nicola Musatti a écrit :
On Feb 21, 10:55 am, Bruno Desthuilliers <bruno.
42.desthuilli.. .@wtf.websitebu ro.oops.comwrot e:
>Carl Banks a écrit :
[...]
>>C++ is a compile-time, type-checked language, which means it is
totally safer for newbies than Python. Yep, your big company is
totally safe with newbie C++ programmers.
Mouarf ! Brillant demonstration, thanks Carl !-)

(and BTW, +1 QOTW)

Newbies learn, and the fundamental C++ lessons are usually learnt
quite easily.
Which is why the most common source of nasty bugs in C++ apps - even
coded by experimented, careful and talented programmers -has to do with
dangling pointers, memory leaks, erroneous typecasts and other related
niceties... Things that are somewhat less likely to happen in Python.
Unless we're talking about idiots, that is, but in this
case at least C++ is likely to make their deficiencies evident sooner
than most other programming languages.
Here at least you have a point !-)
So, yes, your big company is
likely to be safer with newbie C++ programmers than with Python newbie
programmers.
Sorry but I don't buy your arguments.
Had we been speaking of productivity... but we weren't, were we?
Should we ?-)
Feb 22 '08 #18


Paul Boddie wrote:
On 21 Feb, 19:22, Nicola Musatti <nicola.musa... @gmail.comwrote :
[...]
The main reason why C++ has declined in usage is because it never got
the kind of corporate marketing enjoyed by Java and C#.

What? C++ was practically the favoured language for serious
applications development on the win32 platform for a good decade. It
was all about Visual C++/Studio until Microsoft dabbled with J++, got
sued and eventually came up with C# (and Managed C++). You can't
really ask for a more influential patron than Microsoft.
You're partly right, but there are a couple of things to consider:
first, at the time the language wars hadn't started yet. As you say
when Sun came out with Java Microsoft first tried to jump on the
bandwagon on its own terms, then invented .NET. Don't forget that
Visual Studio stuck at the 6.0 release for about 5 years. Second, what
Microsoft pushed at the time was their own notion of C++, centred
around the MFC framework. People used to say that there were C++
programmers *and* Visual C++ programmers.

[...]
Sorry, but although this was probably true in the early 90's that's
not the way it goes in practice nowadays, thanks to automatic
variables, destructors, the standard library containers and smart
pointers.

Yes, but support for a lot of this stuff usually lags behind the best
practices, so there are usually the tools that actually do attempt to
provide this stuff, then there are the tools which people have to use
(such as Visual Studio) and which don't work satisfactorily, although
I'll admit that the situation was improving (on the Free Software
side, at least) when I last had anything to do with C++ in a project.
Things have changed a lot in the last six years. VC++ and g++ are both
very good C++ compilers, quite close to standard compliance and both
moving to anticipate the next version of the standard itself.
Sadly, it took most of the 1990s for widespread support for several
key C++ features to become available. The joke always used to be about
templates and exceptions, but I've had pages full of bizarre errors
from libraries like Boost more recently than the 1990s. And I've seen
plenty of libraries this century which probably don't follow the best
practices, possibly because the people involved have no faith in the
language implementations .
Both VC++ and g++ support Boost quite well nowadays, with way fewer
workarounds than were required a few years ago. Note that basic things
like shared_ptr have been working well on most C++ compilers for at
least five years.

The real sad thing is that nobody is likely to convince Guido to turn
CPython into C++Python ;-)

Cheers,
Nicola Musatti
Feb 22 '08 #19
On Feb 22, 12:24 am, Carl Banks <pavlovevide... @gmail.comwrote :
On Feb 21, 1:22 pm, Nicola Musatti <nicola.musa... @gmail.comwrote :
There are other downsides to garbage collection, as the fact that it
makes it harder to implement the Resource Acquisition Is
Initialization idiom, due to the lack of deterministic destruction.

That's not a downside: it's at least a wash.

In C++ you manage memory and the language manages resources. In
Python you manage resources and the language manages memory.

RAII is merely one way of minimizing complexity. Garbage collection
is another way.
In C++ memory is just another resource which you can handle just like
any other one, possibly using RAII. GC deals with memory very
reasonably, but makes it more complicate to deal with other resources.

Cheers,
Nicola Musatti
Feb 22 '08 #20

This thread has been closed and replies have been disabled. Please start a new discussion.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.