Re: Article of interest: Python pros/cons for the enterprise

[Paul Rubin]

Robert Brown <[EMAIL PROTECTED]> writes:
> Unfortunately, performance often comes at the cost of safety and
> correctness.  Optimized C programs can crash when pointers walk off the
> end of arrays or they can yield incorrect results when integers overflow
> the limits of the hardware.

Yes, even unoptimized C programs can do that.  C is just plain dangerous.

> [SBCL Common Lisp]
> Very rarely, say inside a loop, I temporarily change my default compiler
> settings.  Inside the lexical scope of these declarations, the compiled
> code does no run-time type checking and trusts me.  Here, broken Lisp
> code can crash the system (just as broken C code can), but the compiled
> code runs very fast.
> 
> I trade off safety for speed, but only where necessary.

It seems to me that this trade-off results from a problem with the
language's expressivity.  If you have a sound argument that the
subscripts in your loop are actually safe, you ought to be able to
express that argument to the compiler for static checking.  That
should result in safe code with no runtime checks needed.

That said, trying to provide that level of expressivity is at the
cutting edge of programming language research, and in real-world
languages, for now, we have to live with some runtime checks.
But in an example like (pseudocode):

   for i in 1..100:
   hack(x[i])

it should be enough to check outside the loop in constant time that
1..100 are valid subscripts for x, then generate the loop code with
no check on each separate access.  That is maybe not possible in C
because i might be aliased to something, but in a sane language it
should be possible.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[dave_mikesell]

Good article.  Re: the comparisons with C++, most of my experience is
with C++ and I like it because it's powerful, flexible, portable, and
keeps me employable.  However, I can't think of any application or
system I've written in C++ (or Java or Perl) that could not have been
written in Python.

In my hobbyist work, I've used Python quite a bit and will some more.
It's a joy to program with.  Love to get a Python gig someday, but
there's just not much of a market, and with Ruby on Rails emerging as
the next Silver Bullet, I don't see one emerging soon.

No worries.  C++ and Python will both enjoy long futures.  Longer than
I will be employed.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Robert Brown]

Paul Rubin  writes:

> Robert Brown <[EMAIL PROTECTED]> writes:
>> This is the approach taken by Common Lisp.  Often just a few type
>> declarations, added to code in inner loops, results in vastly faster code.

> That is just a dangerous hack of improving performance by turning off
> some safety checks, I'd say.  Static typing in the usual sense of the
> phrase means that the compiler can guarantee at compile time that a
> given term will have a certain type.  That can be done by automatic
> inference or by checking user annotations, but either way, it should
> be impossible to compile code that computes improperly typed values.

Unfortunately, performance often comes at the cost of safety and
correctness.  Optimized C programs can crash when pointers walk off the
end of arrays or they can yield incorrect results when integers overflow
the limits of the hardware.

Common Lisp compilers are allowed to completely ignore type
declarations, but the compiler I use, SBCL, uses a combination of
compile-time type inference and run-time checking to ensure that my
variables have the types I've declared them to have.  Sometimes I see an
error message at compile time but otherwise I get an exception at run
time.  It works this way because my code contains

(declaim (optimize (debug 3) (safety 3) (speed 0)))

which indicates I prefer correctness and ease of debugging to run-time
speed.

Very rarely, say inside a loop, I temporarily change my default compiler
settings.  Inside the lexical scope of these declarations, the compiled
code does no run-time type checking and trusts me.  Here, broken Lisp
code can crash the system (just as broken C code can), but the compiled
code runs very fast.

I trade off safety for speed, but only where necessary.

bob
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Jeff Schwab]

Aahz wrote:
> In article <[EMAIL PROTECTED]>,
> Carl Banks  <[EMAIL PROTECTED]> wrote:
>> On Feb 24, 7:03 pm, [EMAIL PROTECTED] (Aahz) wrote:
>>> In article <[EMAIL PROTECTED]>,
>>> Jeff Schwab  <[EMAIL PROTECTED]> wrote:
 (3) Garbage collection is at least as desirable a language feature as
 deterministic destruction.
>>> Enh.  There probably are some people who claim that, but I can't think
>>> of any off-hand.
>> I am most certainly claiming it; in fact I'm claiming that GC far more
>> desirable, because the cost of deterministic destruction is too high.
> 
> I'm trimming the rest of your post because I don't have time to argue
> with you, but I want to point out that you're making the same mistake
> that Jeff is: garbage collection and deterministic destruction are not
> the only techniques for managing memory and resources.  In particular,
> CPython primarily relies on reference counting

That is GC.  It's just not mark & sweep.

>, which has similarities
> with *both* GC and deterministic destruction.
> 
> Now you know why I said that I don't know anybody who makes Jeff's
> claim.  ;-)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Aahz]

In article <[EMAIL PROTECTED]>,
Carl Banks  <[EMAIL PROTECTED]> wrote:
>On Feb 24, 7:03 pm, [EMAIL PROTECTED] (Aahz) wrote:
>> In article <[EMAIL PROTECTED]>,
>> Jeff Schwab  <[EMAIL PROTECTED]> wrote:
>>>
>>>(3) Garbage collection is at least as desirable a language feature as
>>>deterministic destruction.
>>
>> Enh.  There probably are some people who claim that, but I can't think
>> of any off-hand.
>
>I am most certainly claiming it; in fact I'm claiming that GC far more
>desirable, because the cost of deterministic destruction is too high.

I'm trimming the rest of your post because I don't have time to argue
with you, but I want to point out that you're making the same mistake
that Jeff is: garbage collection and deterministic destruction are not
the only techniques for managing memory and resources.  In particular,
CPython primarily relies on reference counting, which has similarities
with *both* GC and deterministic destruction.

Now you know why I said that I don't know anybody who makes Jeff's
claim.  ;-)
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

"All problems in computer science can be solved by another level of 
indirection."  --Butler Lampson
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Matthew Woodcraft]

Nicola Musatti  <[EMAIL PROTECTED]> wrote:
> Sebastian Kaliszewski <[EMAIL PROTECTED]> wrote:
>> 3. You can't handle clean-up errors in reasonable way in C++ish approach, so
>> anything more complex should not by handled that way anyway.

> So it's okay for a Python mechanism to deal with 95% of the cases,
> but not for a C++ one? At least in C++ resource management only
> becomes more complicated if you need more control.

I don't think specifying how your program will respond to errors is
something you can avoid 95% of the time, or anywhere close to that.

-M-
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Steven D'Aprano]

On Tue, 26 Feb 2008 06:35:21 -0800, Aaron Watters wrote:

> I have found in the corporate
> environment that managers frequently don't like it when you do in a few
> days that things that they themselves don't know how to do in less than
> several months.  Especially when it makes the other programmers angry.

Easy solution to that:

Day 1 Solve problem.
Day 2 Read Slashdot, User Friendly.
Day 3 Call in sick.
Day 4 Muck about with StumbleUpon, YouTube.
...
Day 44 Post on comp.lang.python.
Day 45 Tell people you solved problem.


It's all billable time too. Since you're manager's requirement is that 
you work slowly and inefficiently so as not to upset him and your fellow 
coders, you would be billing for 45 days if you followed instructions 
anyway.

*wink*



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Nicola Musatti]

On Feb 26, 2:23 pm, Carl Banks <[EMAIL PROTECTED]> wrote:
> On Feb 26, 6:58 am, Paul Boddie <[EMAIL PROTECTED]> wrote:
>
> > The Lisp
> > scene has also been plagued by an unnecessary deference to commercial
> > interests, which means that the hottest topic on comp.lang.lisp right
> > now is probably Paul Graham's much-anticipated but arguably
> > disappointing Lisp "successor", Arc, amongst the usual in-fighting and
> > parade-dampening.
>
> It looks like his main contribution was to get rid of superfluous
> parentheses.  Which, admittedly, is no small thing for Lisp.

Guido already did that, didn't he? ;-)

Cheers,
Nicola Musatti
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Jeff Schwab]

Jeff Schwab wrote:
> Nicola Musatti wrote:
>> On Feb 24, 5:25 am, Paul Rubin  wrote:
>>> Jeff Schwab <[EMAIL PROTECTED]> writes:
> there's actually a published book specifically about C++ pitfalls.
 Mercy, a whole book?
>>> http://search.barnesandnoble.com/booksearch/isbnInquiry.asp?EAN=97802...
>>
>> Read the title. This is about "C Traps and Pitfalls". Although it
>> shows its age, it's still worth reading. Unfortunately from its price
>> you'd think it was handwritten.
> 
> That is not a book about C++ pitfalls.  That is a book about C pitfalls. 

Whoops!  You already pointed that out.  My mistake!

As you probably know, Andrew Koenig is reportedly the individual who 
first proposed argument-dependent lookup, a.k.a "Koenig" lookup, for C++.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Jeff Schwab]

Nicola Musatti wrote:
> On Feb 24, 5:25 am, Paul Rubin  wrote:
>> Jeff Schwab <[EMAIL PROTECTED]> writes:
 there's actually a published book specifically about C++ pitfalls.
>>> Mercy, a whole book?
>> http://search.barnesandnoble.com/booksearch/isbnInquiry.asp?EAN=97802...
> 
> Read the title. This is about "C Traps and Pitfalls". Although it
> shows its age, it's still worth reading. Unfortunately from its price
> you'd think it was handwritten.

That is not a book about C++ pitfalls.  That is a book about C pitfalls. 
  They really are two very different languages.  Don't get me wrong, C++ 
has pitfalls of its own -- perhaps the worst of which is writing C and 
thinking it's C++ in anything other than a superficial sense.  But there 
are vanishingly few cases that could lead to out-of-bounds indexes or 
dangling pointers anymore.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Paul Rubin]

Nicola Musatti <[EMAIL PROTECTED]> writes:
> > http://search.barnesandnoble.com/booksearch/isbnInquiry.asp?EAN=97802...
> Read the title. This is about "C Traps and Pitfalls". 

Whoops, I think the same author wrote a similar one about C++.  He hangs
out here on this newsgroup sometimes.  I didn't notice that my keyword search
got the wrong one.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Aaron Watters]

On Feb 25, 8:29 am, Nicola Musatti <[EMAIL PROTECTED]> wrote:
> > And the migration to Python is due in large part because of an
> > additional factor of 3-4x in personal productivity (over Java).
> > Improvements in runtime performance wouldn't hurt, but for many
> > applications that's not an issue.  (If optional data typing were
> > offered, Python's penetration in the enterprise space would be even
> > higher, and I suspect there would be performance gains as well.)
>
> This I found less hard to believe. Python is more expressive than Java
> and usually requires less code for the same task. Moreover the
> availability of libraries is comparable.

I tend to cheat when I code in java and pretend
I'm writing in Python.  But even then the biggest
pain comes in when I try to use really advanced
data structures and get all knotted up in the verbosity
-- and when I try to figure out what I was doing later
it's even worse.  For example in Python I tend to build
things like dictionaries of tuples to lists of
dictionaries without thinking about it, but in Java
the equivalent of

   D[ (x,y) ] = [ { a: b } ]

is too horrible to be imagined, even if you cheat
and use the non-type-safe containers.  Of course
this is in addition to other Java annoyances like
no proper support for multivalued returns or
function pointers, and overgeneralized
libraries.

However, I have found in the corporate
environment that managers frequently don't
like it when you do in a few days that
things that they themselves don't know how
to do in less than several months.  Especially
when it makes the other programmers angry.
Sometimes I think programmers should get
sociology/psychology/poli.sci degrees and pick up the
programming stuff on the job, since most of
what counts seems to be politics, really.

  -- Aaron Watters

===
http://www.xfeedme.com/nucular/pydistro.py/go?FREETEXT=spam+eggs
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Marc 'BlackJack' Rintsch]

On Tue, 26 Feb 2008 05:23:11 -0800, Nicola Musatti wrote:

> At least in C++ resource management only becomes more complicated if you
> need more control.

I think this is the point where so many people here disagree.  I'm coming
from a "garbage collection" background in OOP programming.  In C++
resource management becomes instantly more complicated because I have to
think about memory management and must actively manage it in *every case*.
Writing code in a RAII style and using smart pointer templates is a cost
for me.  A cost that's quite high, because it feels completely wrong to
have to think about it and to write in that "value style", because that
goes against my expectations/picture of OOP -- a graph of
independent/loosely coupled objects communicating with each other.  In
this sense C++ looks like a quite crippled and fragile OOP language to me.

Ciao,
Marc 'BlackJack' Rintsch
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Carl Banks]

On Feb 26, 6:58 am, Paul Boddie <[EMAIL PROTECTED]> wrote:
> The Lisp
> scene has also been plagued by an unnecessary deference to commercial
> interests, which means that the hottest topic on comp.lang.lisp right
> now is probably Paul Graham's much-anticipated but arguably
> disappointing Lisp "successor", Arc, amongst the usual in-fighting and
> parade-dampening.

It looks like his main contribution was to get rid of superfluous
parentheses.  Which, admittedly, is no small thing for Lisp.


Carl Banks
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Nicola Musatti]

On Feb 25, 3:59 pm, Sebastian Kaliszewski
<[EMAIL PROTECTED]> wrote:
[...]
> 1. Your "generic" resource-management infrastructure is not generic to begin
> with! It does not work for mutually dependant resources.

How so? Could you give a concrete example?

> 2. Your "generic" infrastructure increases burden on the programmer
> everywhere any resorce (including trivial one like memory) is used, while
> GC kills that burden in 95% of the cases. C++ish approach puts the notion
> of ownership everywhere - both in 95% of cases where it's useless and in
> remaining 5% where it's actually needed. That's not reduced effort by any
> means.

Like others around here you seem not to be aware of the existence of
the standard C++ library. That and local variables usually deal with
well over half the cases of memory management in any non trivial
application, and boost::shared_ptr can deal with a good portion of the
rest.

> 3. You can't handle clean-up errors in reasonable way in C++ish approach, so
> anything more complex should not by handled that way anyway.

So it's okay for a Python mechanism to deal with 95% of the cases, but
not for a C++ one? At least in C++ resource management only becomes
more complicated if you need more control.

Cheers,
Nicola Musatti
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Nicola Musatti]

On Feb 24, 5:25 am, Paul Rubin  wrote:
> Jeff Schwab <[EMAIL PROTECTED]> writes:
> > > there's actually a published book specifically about C++ pitfalls.
>
> > Mercy, a whole book?
>
> http://search.barnesandnoble.com/booksearch/isbnInquiry.asp?EAN=97802...

Read the title. This is about "C Traps and Pitfalls". Although it
shows its age, it's still worth reading. Unfortunately from its price
you'd think it was handwritten.

Cheers,
Nicola Musatti
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Nicola Musatti]

On Feb 26, 12:58 pm, Paul Boddie <[EMAIL PROTECTED]> wrote:
> On 25 Feb, 19:44, Nicola Musatti <[EMAIL PROTECTED]> wrote:
>
>
>
> > Witness the kind of
> > libraries/framework that used to and still come with some commercial C+
> > + implementation, and even some free/open source ones; Boost, ACE and
> > wxWidgets are the first that come to mind.
>
> Oh, that's another good reason for C++'s decline: the fragmentation of
> the development community through a plethora of proprietary products,
> each one with its advocates and a relatively small common ground
> (admittedly growing over the years thanks to Free Software and
> standards) between them all. When Java came along, even though the
> best GUI offering was AWT, it was better than nothing and it was one
> of the batteries included. Although Sun's Java was also proprietary,
> it was easier for people to obtain and redistribute, often without per-
> seat or per-unit licensing costs.

C++ was born and acquired its popularity in a period when freely
available software wasn't as common as it is today and corporation
didn't see any kind of advantage in investing in it.

By the way, funny you should mention AWT, given how it was soon
superceded by Swing, which in turn competes against SWT. And given the
state of the Python web framekork scene if I were you I'd start
looking for another language ;-)

Cheers,
Nicola Musatti
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Paul Boddie]

On 25 Feb, 19:44, Nicola Musatti <[EMAIL PROTECTED]> wrote:
>
> Witness the kind of
> libraries/framework that used to and still come with some commercial C+
> + implementation, and even some free/open source ones; Boost, ACE and
> wxWidgets are the first that come to mind.

Oh, that's another good reason for C++'s decline: the fragmentation of
the development community through a plethora of proprietary products,
each one with its advocates and a relatively small common ground
(admittedly growing over the years thanks to Free Software and
standards) between them all. When Java came along, even though the
best GUI offering was AWT, it was better than nothing and it was one
of the batteries included. Although Sun's Java was also proprietary,
it was easier for people to obtain and redistribute, often without per-
seat or per-unit licensing costs.

Of course, C++ isn't the only language with this problem. The Lisp
scene has also been plagued by an unnecessary deference to commercial
interests, which means that the hottest topic on comp.lang.lisp right
now is probably Paul Graham's much-anticipated but arguably
disappointing Lisp "successor", Arc, amongst the usual in-fighting and
parade-dampening.

Paul
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Paul Rubin]

Robert Brown <[EMAIL PROTECTED]> writes:
> > Python's dynamic typing is just fine.  But if I know the type, I want
> > the ability to nail it.  ...local variables, arguments, return values,
> > etc  And if I don't know or care, I'd leave it to dynamic typing.
> 
> This is the approach taken by Common Lisp.  Often just a few type
> declarations, added to code in inner loops, results in vastly faster code.

That is just a dangerous hack of improving performance by turning off
some safety checks, I'd say.  Static typing in the usual sense of the
phrase means that the compiler can guarantee at compile time that a
given term will have a certain type.  That can be done by automatic
inference or by checking user annotations, but either way, it should
be impossible to compile code that computes improperly typed values.
Lisp and Python don't attempt to make any such compile time checks.
They check at runtime, or (in the case of Lisp with the checks turned
off) they don't check at all.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Robert Brown]

Larry Bugbee <[EMAIL PROTECTED]> writes:
> Python's dynamic typing is just fine.  But if I know the type, I want
> the ability to nail it.  ...local variables, arguments, return values,
> etc  And if I don't know or care, I'd leave it to dynamic typing.

This is the approach taken by Common Lisp.  Often just a few type
declarations, added to code in inner loops, results in vastly faster code.
Also, although I don't tend to use type declarations while interactively
developing code, I often add them later.  Mostly, I add them to document the
code, but the added safety and faster execution time are nice benefits.

bob
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Aahz]

In article <[EMAIL PROTECTED]>,
Jeff Schwab  <[EMAIL PROTECTED]> wrote:
>Bruno Desthuilliers wrote:
>> 
>> Stating the obvious is not bashing. In my last shop I was working with 
>> (very talented BTW) Perl programmer, and he was the first to make jokes 
>> on Perl's abuse of cryptic syntax.
>
>It's not abuse.  It's meaningful and compact.  The $scalars are 
>intuitive to anybody who has ever written a shell script, the @arrays 
>are immediately recognizable...  I agree it takes some getting used to, 
>but then it becomes clear as day.

You're entitled to your opinion, but speaking as a former expert Perl
programmer, I disagree with you.
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

"All problems in computer science can be solved by another level of 
indirection."  --Butler Lampson
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Nicola Musatti]

On Feb 25, 3:17 pm, Carl Banks <[EMAIL PROTECTED]> wrote:
> On Feb 25, 8:29 am, Nicola Musatti <[EMAIL PROTECTED]> wrote:
>
> > On Feb 24, 9:14 pm, Larry Bugbee <[EMAIL PROTECTED]> wrote:
> > > Corporate marketing, and corporate attention in general, saw to it
> > > that Java was well equipped with libraries and frameworks addressing
> > > enterprise application needs.  ...but the *big* reason Java won over C+
> > > + is because your application became stable sooner.  ...with arguably
> > > fewer problems later.
>
> > The number of libraries you get "out of the box" appear to me as more
> > likely explanations for the productivity increase.
>
> The productivity increase of the language appears to me as a more
> likely explanation for the number of libraries you get "out of the
> box".

In the case of Python I suspect you have a point even without the
smiley, given how much of what's available was developed without any
major corporation's support. On the other hand, had the kind of money
that's been poured into Java and/or .NET been poured into *standard* C+
+, I dont' think it would be so far behind. Witness the kind of
libraries/framework that used to and still come with some commercial C+
+ implementation, and even some free/open source ones; Boost, ACE and
wxWidgets are the first that come to mind.

Cheers,
Nicola Musatti
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Paul Rubin]

Nicola Musatti <[EMAIL PROTECTED]> writes:
> > However, one of the consequences of programming in this style is
> > you allocate a lot of temporary objects which best managed by GC.
> 
> According to which metric? This statement appears as totally
> gratuitous to me. You seem to forget that deallocation of local
> objects only entails stack readjustment.

Why do you think they are local objects?  They are passed as arguments
to functions that could be storing references elsewhere.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Sebastian Kaliszewski]

Jeff Schwab wrote:
>> 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.
> 
> I disagree with you completely.  Your points don't make any sense to me
> at all.  I believe I am putting forth less effort by having a generic
> resource-management infrastructure, rather than a memory-specific
> language feature -- that's not just an implication, it's my honest belief.

Yet your belief is provably wrong. It's been realised by langauge developers
long time ago.

It's quite simple. 

1. Your "generic" resource-management infrastructure is not generic to begin
with! It does not work for mutually dependant resources.
2. Your "generic" infrastructure increases burden on the programmer
everywhere any resorce (including trivial one like memory) is used, while
GC kills that burden in 95% of the cases. C++ish approach puts the notion
of ownership everywhere - both in 95% of cases where it's useless and in
remaining 5% where it's actually needed. That's not reduced effort by any
means.
3. You can't handle clean-up errors in reasonable way in C++ish approach, so
anything more complex should not by handled that way anyway.


rgds
-- 
"Never underestimate the power of human stupidity" -- L. Lang
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Carl Banks]

On Feb 25, 8:29 am, Nicola Musatti <[EMAIL PROTECTED]> wrote:
> On Feb 24, 9:14 pm, Larry Bugbee <[EMAIL PROTECTED]> wrote:
> > Corporate marketing, and corporate attention in general, saw to it
> > that Java was well equipped with libraries and frameworks addressing
> > enterprise application needs.  ...but the *big* reason Java won over C+
> > + is because your application became stable sooner.  ...with arguably
> > fewer problems later.
>
> The number of libraries you get "out of the box" appear to me as more
> likely explanations for the productivity increase.

The productivity increase of the language appears to me as a more
likely explanation for the number of libraries you get "out of the
box".

:)


Carl Banks
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Nicola Musatti]

On Feb 24, 9:14 pm, Larry Bugbee <[EMAIL PROTECTED]> wrote:
> On Feb 21, 10:22 am, Nicola Musatti <[EMAIL PROTECTED]> wrote:
>
> > On Feb 21, 6:31 pm, Paul Boddie <[EMAIL PROTECTED]> wrote:
>
> > > The main reason why C++ has declined in usage is because almost
> > > everything of practical value is optional.
>
> No, disagree.
>
> > The main reason why C++ has declined in usage is because it never got
> > the kind of corporate marketing enjoyed by Java and C#.
>
> I'm inclined to disagree for two reasons.  C++ is a very complex
> language.  Java (and the later C#) less so.  Couple that with reduced
> debugging time due to garbage collection and fewer pointer problems, a
> lot of us decided a factor of 2x in personal productivity was worth
> it.  Runtime was initially an impediment, and still is for desktop
> applications, but the trade was worth it.

While this was probably true towards the end of the nineties, given
the standard library and Boost I find it hard to believe that a
similar increase can be accounted for just in terms of language
differences.

> Corporate marketing, and corporate attention in general, saw to it
> that Java was well equipped with libraries and frameworks addressing
> enterprise application needs.  ...but the *big* reason Java won over C+
> + is because your application became stable sooner.  ...with arguably
> fewer problems later.

The number of libraries you get "out of the box" appear to me as more
likely explanations for the productivity increase.

> And the migration to Python is due in large part because of an
> additional factor of 3-4x in personal productivity (over Java).
> Improvements in runtime performance wouldn't hurt, but for many
> applications that's not an issue.  (If optional data typing were
> offered, Python's penetration in the enterprise space would be even
> higher, and I suspect there would be performance gains as well.)

This I found less hard to believe. Python is more expressive than Java
and usually requires less code for the same task. Moreover tha
availability of libraries is comparable.

Cheers,
Nicola Musatti

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Nicola Musatti]

On Feb 24, 1:01 am, Paul Rubin  wrote:
> Nicola Musatti <[EMAIL PROTECTED]> writes:
> > >>>a = [f(x) + g(y) for x,y in izip(m1, m2) if h(x,y).frob() == 7]
> > [...]
> > > There you replace one line of code with 40+ lines to get around the
> > > absence of GC.  Sounds bug-prone among other things.
>
> > Come on, you didn't define f, g, izip, h or frob either. It's more
> > like 5 to one. Furthermore your code is more compact due to the
> > existence of list comprehensions, not because of GC. Had you written a
> > loop the difference would be smaller.
>
> No I don't need a loop if I don't use the listcomp.  I could say
>
>   a = map(lambda x,y: f(x)+g(y), ifilter(lambda x,y: h(x,y).frob==7,
>izip(m1, m2)))
>
> the listcomp is basically syntax sugar for that.
>
> The issue here is that Python is simply more expressive than C++,
> which doesn't support creation of higher order functions like that.

I see. The C++'s closest equivalent would probably be something like

int func(int x, int y) { return f(x) + g(y); }
bool filter(int x, int y) { return h(x,y).frob() == 7; }

transform_if(m1.begin(), m1.end(), m2.begin(),
std::back_inserter(a), func, filter);

Assuming that instead of izip you had the following, which is more in
style with how the C++ standard library usually works:

template 
inline void transform_if(InIter1T begin1, InIter1T end1,
InIter2T begin2, OutIterT out, FuncT func, FilterT filter)
{
while ( begin1 != end1 )
{
if ( filter(*begin1, *begin2) )
*out++ = func(*begin1, *begin2);
++begin1;
++begin2;
}
}

Nameless, local function definitions and a form of type inference
should officially become part of C++ in little over a year. These will
help achieve closer expressiveness for similar statements, but the
lack of native tuples in the language will probably make it impossible
to get much closer.

> However, one of the consequences of programming in this style is
> you allocate a lot of temporary objects which best managed by GC.

According to which metric? This statement appears as totally
gratuitous to me. You seem to forget that deallocation of local
objects only entails stack readjustment. You can hardly beat that with
dynamic memory management.

Cheers,
Nicola Musatti
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Carl Banks]

On Feb 24, 7:03 pm, [EMAIL PROTECTED] (Aahz) wrote:
> In article <[EMAIL PROTECTED]>,
> Jeff Schwab  <[EMAIL PROTECTED]> wrote:
> >(3) Garbage collection is at least as desirable a language feature as
> >deterministic destruction.
>
> Enh.  There probably are some people who claim that, but I can't think
> of any off-hand.

I am most certainly claiming it; in fact I'm claiming that GC far more
desirable, because the cost of deterministic destruction is too high.

The costs are:
1. extra effort (which Jeff Schwab denied but I don't remotely buy it)
2. mistakes are easier to make and more catastrophic when made

With deterministic destruction, you have to worry about the lifetime
of every single object, and that requires effort.

Either you are literally keeping track of all the object and manually
freeing and deleting them like in C, or you are sticking to a rigid
disciplined style that (mostly) guards against practices that lead to
invalid pointers and memory leaks.  The discipline itself takes
effort, but the rigid style also limits expressiveness, often
severely, and so you have to expend more effort writing the same
thing.

Point is, one way or another, you are paying for deterministic
destruction with more effort.

Even that innocuous object on the local stack frame can bite you if
you pass it to a function that, expecting a heap object, stores a
pointer.  Which means you have to keep track of what the functions
you're calling do, and you have to be deliberate about what the
functions you're writing do, so still more effort, yadda yadda.

I don't really think I have to say much with regard to error-proneness
compared to GC, nor the cost of mistakes  Invalid pointer dereferences
and segfaults don't happen in Python (aside from extensions), and
memory leaks only happen when you accidentally keep objects alive.
Mistakes are far more common and dangerous in C++.

And subtle I might add.  A destroyed object that is improperly
derferenced might "work" for awhile since its memory hadn't been
overwritten, then suddenly crash and burn in slightly different
circumstances (such as if it's running a different computer, like, for
instance, the customer's).

And tracking down and fixing those bugs, compared to the sorts of bugs
you get from garbage collection?  You guessed it--more effort.

Deterministic destruction would be a great thing if it weren't for all
the drawbacks.  Until then I will choose the path of lesser effort by
letting GC take care of memory, closing my own files, and having lots
of expressive power and freedom.


Carl Banks
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Aahz]

In article <[EMAIL PROTECTED]>,
Jeff Schwab  <[EMAIL PROTECTED]> wrote:
>
>What I would like is not so much a new Python implementation, as a 
>vehicle to help demonstrate a few things to other Python users. 
>Recently, I've had a few replies in tones that imply I'm on the brink of 
>entering several kill-files, mostly because I express disagreement with 
>a few closely held beliefs of some other c.l.p posters.  For example, 
>the following are widely held opinions with which I disagree:
>
>(1) Python is a gotcha-free language.

HAHAHAHAHAHAHA -- please, do provide some evidence for this assertion.

>(2) C++ is basically the same language as C, but more complicated.

Hardly.  Again, you need to provide evidence for this assertion.  What I
would say is that C++ has *all* the gotchas of C plus many of its own.

>(3) Garbage collection is at least as desirable a language feature as 
>deterministic destruction.

Enh.  There probably are some people who claim that, but I can't think
of any off-hand.  However, I suspect that part of the problem is that
you don't really understand Python: Python primarily relies on reference
counting, which combined with other features in Python makes cycle
creation rather easy, and there's no real option other than garbage
collection for cleaining up cycles.

>(4) Static typing is inferior to dynamic typing.

There's some truth to what you say, but you are entirely misrepresenting
what people actually say: static typing is inferior to unit tests, and
dynamic typing requires less boilerplate than static typing and is
therefore easier to write.

>In other ways, though, the Python community is just blindingly ignorant, 
>arrogant, and argumentative.  

Absolutely.  But your blind ignorance and arrogant argumentation isn't
helping any.

>I expect my use of Python to increase in the coming years, so I want   
>the best possible relationship with other regular users, especially on 
>Usenet.

Then maybe you should start by learning Python and what people actually
say about it.
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

"All problems in computer science can be solved by another level of 
indirection."  --Butler Lampson
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Larry Bugbee]

PS:  And tools like ShedSkin and Pyrex benefit.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Larry Bugbee]

> You mean static data typing, right?  Are there any known holes in the
> dynamic type system that still need to be plugged?  (I haven't heard of
> any.)

My apologies.  You are right, I meant optional, static typing.  Thanks
for the catch Jeff.

Python's dynamic typing is just fine.  But if I know the type, I want
the ability to nail it.  ...local variables, arguments, return values,
etc  And if I don't know or care, I'd leave it to dynamic typing.

The need for a lot of doc goes away, those new to the language that
think it's a big deal can be explicit, and as I suggested earlier, I
think the byte code interpreter could be made a lot smarter and
faster.  ...and corporate acceptance would follow.

Larry
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Jeff Schwab]

Larry Bugbee wrote:

> And the migration to Python is due in large part because of an
> additional factor of 3-4x in personal productivity (over Java).
> Improvements in runtime performance wouldn't hurt, but for many
> applications that's not an issue.  (If optional data typing were

You mean static data typing, right?  Are there any known holes in the 
dynamic type system that still need to be plugged?  (I haven't heard of 
any.)

> offered, Python's penetration in the enterprise space would be even
> higher, and I suspect there would be performance gains as well.)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Larry Bugbee]

On Feb 21, 10:22 am, Nicola Musatti <[EMAIL PROTECTED]> wrote:
> On Feb 21, 6:31 pm, Paul Boddie <[EMAIL PROTECTED]> wrote:
> >
> > The main reason why C++ has declined in usage is because almost
> > everything of practical value is optional.

No, disagree.

> The main reason why C++ has declined in usage is because it never got
> the kind of corporate marketing enjoyed by Java and C#.

I'm inclined to disagree for two reasons.  C++ is a very complex
language.  Java (and the later C#) less so.  Couple that with reduced
debugging time due to garbage collection and fewer pointer problems, a
lot of us decided a factor of 2x in personal productivity was worth
it.  Runtime was initially an impediment, and still is for desktop
applications, but the trade was worth it.

Corporate marketing, and corporate attention in general, saw to it
that Java was well equipped with libraries and frameworks addressing
enterprise application needs.  ...but the *big* reason Java won over C+
+ is because your application became stable sooner.  ...with arguably
fewer problems later.

And the migration to Python is due in large part because of an
additional factor of 3-4x in personal productivity (over Java).
Improvements in runtime performance wouldn't hurt, but for many
applications that's not an issue.  (If optional data typing were
offered, Python's penetration in the enterprise space would be even
higher, and I suspect there would be performance gains as well.)

Larry
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Lou Pecora]

In article 
<[EMAIL PROTECTED]>,
 Nicola Musatti <[EMAIL PROTECTED]> wrote:

> On Feb 22, 12:07 pm, Paul Rubin  wrote:
> > Nicola Musatti <[EMAIL PROTECTED]> writes:
> > > In C++ memory is just another resource which you can handle just like
> > > any other one, possibly using RAII.
> >
> > Ok, I'll bite.  Here's a straightforward Python expression:
> >
> >a = [f(x) + g(y) for x,y in izip(m1, m2) if h(x,y).frob() == 7]
> >
> > Consider how many intermediate objects are being allocated in figuring
> > out that listcomp.  Do you REALLY want to manage all the deallocation
> > with something like RAII?
> 
> 
> What makes you think that a translation of a similar expression would
> involve explicit dynamic allocation at all? Barring bugs, here's an
> equivalent example:
> 
> #include 
> #include 
> #include 

[cut a lot of C++ code]

I realize the original point was about dynamic allocation and GC, but 
for me the raw juxtaposition of the *one* line of clear Python code with 
the equivalent mass of C++ code is shocking.  Thanks for that.

-- 
-- Lou Pecora
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Jeff Schwab]

Matthew Woodcraft wrote:
> Jeff Schwab  <[EMAIL PROTECTED]> wrote:
>> Matthew Woodcraft wrote:
>>> I see. Then, unless you don't care about data loss passing silently,
>>> this 'most traditional' way to open a file is unsuitable for files
>>> opened for writing.
> 
>> No, why would you think so?  If you want something special to happen 
>> when the close() fails (as you indeed would if you were writing 
>> important data), you have to say somehow that you want your special code 
>> called.  What syntax would you like to see?  Here's what the C++ would 
>> look like, supposing you have a type LoggingCloser that calls close and 
>> logs any failure:
> 
> Sure, but this LoggingCloser isn't what you described as the 'most
> traditional, easiest way to open a file in C++'.

It's not there to open the file, it's there to check the error code on 
close.  That's what you said you wanted.


> The more general point is that, where you want to take action on
> cleanup and you need to handle errors from this action, it usually
> isn't enough to have one class per type of resource which knows what
> clean up action is required (because the required response to the error
> usually varies).

If there is variation, you can either pass some data to the responsible 
object's constructor, or you can give it "policies" for what to do in 
different situations.

http://en.wikipedia.org/wiki/Policy-based_design


> Additionally, in languages where exceptions are the usual way to report
> errors but exceptions from destructors are not managed pleasantly, the
> error recovery code can't use the language's normal mechanisms for
> dealing with the error response.

Huh?  Why not?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Lou Pecora]

Just some anecdotal confirmation:

In article <[EMAIL PROTECTED]>,
 "Ryan Ginstrom" <[EMAIL PROTECTED]> wrote:

> I personally used C++ for about 90% of my code for 10 years. During that
> time, I was chugging the C++ Kool-Aid so hard I almost peed myself. I still
> think that C++ is a beautiful language, but I have also come to think that
> starting a program with C++ is a premature optimization. 

Yes, I came to the same conclusion and now start all projects in Python, 
then add C/C++ extensions for optimization.  

> I think that very few Python programmers today started with Python. Most of
> them came to Python for a reason. 

Exactly right in my case.  In fact this observation is directly related 
to the one your the previous paragraph.  Python is a good language in 
which to start a progrom.

-- 
-- Lou Pecora
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Matthew Woodcraft]

Jeff Schwab  <[EMAIL PROTECTED]> wrote:
> Matthew Woodcraft wrote:
>> I see. Then, unless you don't care about data loss passing silently,
>> this 'most traditional' way to open a file is unsuitable for files
>> opened for writing.

> No, why would you think so?  If you want something special to happen 
> when the close() fails (as you indeed would if you were writing 
> important data), you have to say somehow that you want your special code 
> called.  What syntax would you like to see?  Here's what the C++ would 
> look like, supposing you have a type LoggingCloser that calls close and 
> logs any failure:

Sure, but this LoggingCloser isn't what you described as the 'most
traditional, easiest way to open a file in C++'.

The more general point is that, where you want to take action on
cleanup and you need to handle errors from this action, it usually
isn't enough to have one class per type of resource which knows what
clean up action is required (because the required response to the error
usually varies).

Additionally, in languages where exceptions are the usual way to report
errors but exceptions from destructors are not managed pleasantly, the
error recovery code can't use the language's normal mechanisms for
dealing with the error response.

-M-
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Arnaud Delobelle]

On Feb 24, 8:08 am, Steven D'Aprano <[EMAIL PROTECTED]
cybersource.com.au> wrote:
> On Sat, 23 Feb 2008 19:45:45 -0800, Jeff Schwab wrote:
> The second link is just bizarre. It claims that Python "does not have
> nested, block variable scopes like I am accustomed to in nearly every
> other programming language I use, like C, C#, C++, Objective C, Perl, and
> Java." (Notice the common denominator?) But that's nonsense -- Python
> does have nested block variable scopes. This "pitfall", if it is one, is
> that Python doesn't create a new scope for if-blocks. Coming from a
> Pascal background instead of C, it never even occurred to me that if-
> blocks could be a new scope, or that anyone would possibly want it to be.

I haven't read the link, but it is true that python < 3 is deficient
in that area: names in an enclosing scope can be accessed but not
rebound.  In the latter case the interpreter assumes them to be local
names.  Python 3000 fixes this with the new 'nonlocal' compilation
directive.  E.g.

(python 2.5)

>>> def counter(acc=0, step=1):
... def tick():
... acc += step
... return acc
... return tick
...
>>> c = counter()
>>> c()
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 3, in tick
UnboundLocalError: local variable 'acc' referenced before assignment
>>>

(python 3.0)

>> def counter(acc=0, step=1):
... def tick():
... nonlocal acc
... acc += step
... return acc
... return tick
...
>>> c = counter()
>>> c()
1
>>> c()
2
>>>

--
Arnaud

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Steven D'Aprano]

On Sat, 23 Feb 2008 19:45:45 -0800, Jeff Schwab wrote:

> Paul Rubin wrote:
>> Jeff Schwab <[EMAIL PROTECTED]> writes:
>>> One great thing about C is that
>>> a programmer can realistically hope to know the entire language
>>> definition; maybe Guido would like the same to be true of Python.
>> 
>> C is horrendously complicated, with zillions of obscure traps.  C++ is
>> even worse;
> 
> Who feeds you this stuff?
> 
> 
>> there's actually a published book specifically about C++ pitfalls.
> 
> Mercy, a whole book?

Well, that might not be "zillions", but it is sure a lot of pitfalls.


> My current favorite book of language-specific pitfalls:
> 
>  http://www.javapuzzlers.com/

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


> Wait a few years.  A Python Puzzlers book will surely be on the shelves
> eventually.

You wish.

If so, then it will either be an incredibly short book, or the language 
"Python" in 2012 will be nothing like Python now.



> Here are some of the top results when Googling "python
> pitfalls:"
> 
>  http://zephyrfalcon.org/labs/python_pitfalls.html
>  http://evanjones.ca/python-pitfall-scope.html

Yeah, let's have a look at those. From the first link:

1. Inconsistent indentation
2. Assignment, aka names and objects
3. The += operator
4. Class attributes vs instance attributes
5. Mutable default arguments
6. UnboundLocalError
7. Floating point rounding errors
8. String concatenation
9. Binary mode for files
10. Catching multiple exceptions

Ten pitfalls. You might be able to pad that out to a twenty page leaflet, 
including an index. Number ten is already gone from Python 3; numbers 7 
and 9 aren't Python specific at all; most of the others are only a 
pitfall if you come to Python thinking that Python is C or Java, or 
whatever other language you're used to.

The second link is just bizarre. It claims that Python "does not have 
nested, block variable scopes like I am accustomed to in nearly every 
other programming language I use, like C, C#, C++, Objective C, Perl, and 
Java." (Notice the common denominator?) But that's nonsense -- Python 
does have nested block variable scopes. This "pitfall", if it is one, is 
that Python doesn't create a new scope for if-blocks. Coming from a 
Pascal background instead of C, it never even occurred to me that if-
blocks could be a new scope, or that anyone would possibly want it to be.

Again, the real pitfall is not Python, but imagining that Python is C.


 
> Maybe C++ needs better pub.  The guy who wrote the first of those
> articles says elswhere on his web site:
> 
>  "My Python pitfalls article seems to be a popular read. It's
>  written from a somewhat negative viewpoint: things that can go
>  wrong. (Of course, that's useful; you're never going to do these
>  things wrong again. Right? ;-) To counter-balance this, I think
>  there should an article with a more positive viewpoint as well. So
>  I was wondering, if I could collect 10 "anti-pitfalls"; parts of
>  the Python language that are especially clever, elegant and
>  intuitive."
> 
> 
> Good luck with that.

[quote]
I've seen Python criticized as "ugly" precisely because it doesn't have a 
trick-based view of the world. In many ways, it's a dull language, 
borrowing solid old concepts from many other languages & styles: boring 
syntax, unsurprising semantics, few automatic coercions, etc etc. But 
that's one of the things I like about it. -- Tim Peters

But even given that, here's a good start, the first four things that came 
to mind:

1. Program structure follows indentation. No more wars over where to put 
the braces. The presentation *is* the structure.

2. Namespaces.

3. Generators and iterators. Especially generators.

4. Exceptions. try blocks are fast, don't be scared to use them.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Using lambda [was Re: Article of interest: Python pros/cons for the enterprise]

[Steven D'Aprano]

On Sat, 23 Feb 2008 19:35:30 -0800, Jeff Schwab wrote:

> Every time somebody uses
> lambda here, they seem to get a bunch "why are you using lambda?"
> responses.

Not from me.

I even use "named anonymous functions" *cough* by assigning lambda 
functions to names:

foo = lambda x: x+1



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Paul Rubin]

Jeff Schwab <[EMAIL PROTECTED]> writes:
> > languages should be a red flag in a design review, and a factor in
> > determining product liability if a program misbehaves.
> 
> Your product gets the benefit of the doubt if it was written in
> Python, but not if written in C?  What if the Python interpreter
> screws up?

The Python interpreter has been run in production for over a decade
modulo comparatively small incremental changes, heavily reviewed and
tested by multiple people, between versions.  It's likely to be more
reliable than any one-off C program of comparable size.  Further, for
a C application, the analogous situation to the Python interpreter
screwing up would be the C compiler screwing up (generating wrong
code).  They have that possibility in common.  But for the C
application, the screwup can be in two places (the compiler or the
application) while Python limits it to one place.  The principle here
is to minimize the size of the so-called trusted codebase.

Either way, the ongoing effort (PyPy) to write Python in Python will
probably improve Python's reliability.

> In the first place, you're not distinguishing C from C++.  I know you
> think they're the same.  They're not.  Python's array bounds checking
> is done in C, as is the case for traditional OS kernels.  C++, like
> Python, offers you container types that "smell" like arrays, but do
> safety checking under the hood; 

Not as long as you can have pointers to those objects that contain
naked memory addresses which can be invalid.

> Buffer overflows are the result of developers deliberately
> choosing not to use bounds-checking.

Yes, the most common way that choice is expressed is by choosing to
code in C or C++ in the first place.

> to enable that access. Even then you're trusting the hardware
> developers to check for invalid indexes (bus errors and seg faults).
> Should we outlaw computer hardware, too?

Again, the concept is "best practices" which is an engineering term,
not a mathematical one.  Best practices are not infallible, they're
just the best normal practices observed in real-world projects of
similar scope.

> "Best practices," though, is usually just what managers say when
> they mean "what everybody else is doing."  

No really, among other things it includes following standards that
are designed by people who know what they're doing.  That actually
means something.  

> The idea is that if you're a manager who sticks to "best practices,"
> then if everything goes to hell, the problem can't be linked
> specifically to you.

That is a very valuable aspect.  If I'm writing an encryption program,
best practice is to use a standard algorithm like AES instead of
concocting my own algorithm.  If something does turn out to be wrong
wtih AES that makes my program fail, I'm very glad to be able to point
to the rigorous standardization process that AES went through and say
that I made the best choice I could with available information.  If
for some reason I think there's an 0.002% chance that something is
wrong with AES but only an 0.001% chance that something is wrong with
my home-cooked algorithm, AES is still the obvious choice.

Same thing with internet applications, I'm much better off writing in
a type-safe language than relying on the intricacies of my unique
application code to behave properly in a language without type-safety.

> The only way to keep them from writing code that will blow up
> at run-time is to impose formal verification of their program, every
> time they change it; that's what the C++ static type system lets you
> do, in a limited and easily subverted way. 

Why not get rid of the limitations and easy subversions?  And I can't
agree that using a basic type like "int x[10];" is somehow a
subversion.  Subversion means you have to go to some lengths to break
the type safety.

> Even if you could somehow remove every feature open to potential
> abuse, and thereby dodo-proof the language, the result would be a
> slow, weak, ugly language that non-dodos would not want to use.  But
> hey, at least it would still be "best practice."

Enforcing type safety is certainly an enormous step towards
dodo-proofing a language, it hugely helps the reliability of real
programs, and is one of the reasons Python and Java are displacing C++.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Jeff Schwab]

Paul Rubin wrote:
> Jeff Schwab <[EMAIL PROTECTED]> writes:
>>> there's actually a published book specifically about C++ pitfalls.
>> Mercy, a whole book?
> 
> http://search.barnesandnoble.com/booksearch/isbnInquiry.asp?EAN=9780201179286
> 
>>> C and C++ should practically be outlawed at this point.
>> On what grounds?  "I don't approve of the programming language you're
>> using.  Cease and desist.  Nyah!"
> 
> Well, "outlawed" of course is a figure of speech; however use of those
> languages should be a red flag in a design review, and a factor in
> determining product liability if a program misbehaves.

Your product gets the benefit of the doubt if it was written in Python, 
but not if written in C?  What if the Python interpreter screws up?


> Think of all
> the buffer overflow exploits against Microsoft Windows programs that
> couldn't have happened if Microsoft had used safer languages.  There
> was clearly a failure to use best engineering practices.

In the first place, you're not distinguishing C from C++.  I know you 
think they're the same.  They're not.  Python's array bounds checking is 
done in C, as is the case for traditional OS kernels.  C++, like Python, 
offers you container types that "smell" like arrays, but do safety 
checking under the hood; the C++ bounds checks, unlike the Python 
checks, are done in-language.  If C++ were marketed like Java, people 
might advertise that the C++ standard containers are "pure C++," or that 
"C++ is written in C++".

Secondly, you're going to have a hard time writing an operating system 
kernel without fixed-size buffers.  You have to read data in chunks of 
some size.  It's fine to say that buffer access should be checked to 
make sure indexes should be in range, but somebody actually has to write 
the code to do the checking, and then programmers have to use it. 
Buffer overflows are the result of developers deliberately choosing not 
to use bounds-checking.

In Python, somebody could still define a monolithic array, use different 
parts of it to represent different things, and then "oops" lose track of 
their index, thereby overwriting one part of the array with data that 
should have stayed in the other part.  If you're thinking "Yeah, they 
*could*, but only a dodo would do that, and it's not Python's fault that 
the programmer did something bone-headed," then you're beginning to get 
the picture.  If you somehow wrote an OS kernel in Python, and the 
above-mentioned bone-headedness took place, then there would be no 
"lower level" to save your OS from having a dangerous security hole. 
Even if the hardware supported checked access for large quantities of 
arbitrarily sized arrays, somebody would have to enable that access. 
Even then you're trusting the hardware developers to check for invalid 
indexes (bus errors and seg faults).  Should we outlaw computer 
hardware, too?

Thirdly, you mentioned a "failure to use best engineering practices." 
If you mean there was a failure to design and implement a bug-free 
operating system, then by Jiminy, you're right.  "Best practices," 
though, is usually just what managers say when they mean "what everybody 
else is doing."  The idea is that if you're a manager who sticks to 
"best practices," then if everything goes to hell, the problem can't be 
linked specifically to you.

Server-side Python is now, at this very moment, becoming acceptable as 
"best practice."  It's no better or worse for this; it's just that a lot 
more uninspired, uncreative programmers are about to start using it.  Do 
not underestimate their ability to make any programming language look 
bad.  If you make it fool-proof, they'll build a better fool.  The only 
way to keep them from writing code that will blow up at run-time is to 
impose formal verification of their program, every time they change it; 
that's what the C++ static type system lets you do, in a limited and 
easily subverted way.  Even if you could somehow remove every feature 
open to potential abuse, and thereby dodo-proof the language, the result 
would be a slow, weak, ugly language that non-dodos would not want to 
use.  But hey, at least it would still be "best practice."
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Paul Rubin]

Jeff Schwab <[EMAIL PROTECTED]> writes:
> > there's actually a published book specifically about C++ pitfalls.
> 
> Mercy, a whole book?

http://search.barnesandnoble.com/booksearch/isbnInquiry.asp?EAN=9780201179286

> > C and C++ should practically be outlawed at this point.
> 
> On what grounds?  "I don't approve of the programming language you're
> using.  Cease and desist.  Nyah!"

Well, "outlawed" of course is a figure of speech; however use of those
languages should be a red flag in a design review, and a factor in
determining product liability if a program misbehaves.  Think of all
the buffer overflow exploits against Microsoft Windows programs that
couldn't have happened if Microsoft had used safer languages.  There
was clearly a failure to use best engineering practices.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Paul Rubin]

Jeff Schwab <[EMAIL PROTECTED]> writes:
>  def mkadder(n):
>  return lambda x: x + n
> 
> I have gotten the impression that this was somehow inferior in Python
> though, at least in terms of performance.  Every time somebody uses
> lambda here, they seem to get a bunch "why are you using lambda?"
> responses.  If I am grossly mistake, please just enlighten me.

There are some Python users who object to lambda on stylistic
grounds, and would rather that you say

   def mkdadder(n):
  def adder(x, n):
 return x + n
  return adder

Those same users tend to object to higher-order functions (preferring
listcomps or genexps).  It seems to me though that Python is moving
more towards HOF-oriented styles because of the utility of HOF's over
iterators (look at itertools).  That might make its learning curve
steeper for beginners; I don't have a good sense of this.

> I note from your other posts that you seem to have a strong Lisp
> bent. Lisp programmer and Smalltalk programmers stand out in the
> crowd.  I first noted this when somebody found a while-loop offensive,
> on the grounds that recursion was somehow a more natural way to
> implement looping.  It can take a while to convince somebody like that
> they different idioms work best in different languages.

Well, the saying is "to iterate is human; to recurse, divine" ;-).
Scheme has while-loops but they are just syntax sugar for recursion.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Jeff Schwab]

Paul Rubin wrote:
> Jeff Schwab <[EMAIL PROTECTED]> writes:
>> One great thing about C is that
>> a programmer can realistically hope to know the entire language
>> definition; maybe Guido would like the same to be true of Python.
> 
> C is horrendously complicated, with zillions of obscure traps.  C++ is
> even worse;

Who feeds you this stuff?


> there's actually a published book specifically about C++
> pitfalls.

Mercy, a whole book?

My current favorite book of language-specific pitfalls:

 http://www.javapuzzlers.com/

Wait a few years.  A Python Puzzlers book will surely be on the shelves 
eventually.  Here are some of the top results when Googling "python 
pitfalls:"

 http://zephyrfalcon.org/labs/python_pitfalls.html
 http://evanjones.ca/python-pitfall-scope.html

Maybe C++ needs better pub.  The guy who wrote the first of those 
articles says elswhere on his web site:

 "My Python pitfalls article seems to be a popular read. It's
 written from a somewhat negative viewpoint: things that can go
 wrong. (Of course, that's useful; you're never going to do these
 things wrong again. Right? ;-) To counter-balance this, I think
 there should an article with a more positive viewpoint as well.
 So I was wondering, if I could collect 10 "anti-pitfalls"; parts
 of the Python language that are especially clever, elegant and
 intuitive."


Good luck with that.  Once language Y comes along, there will be a 
million reasons people believe that language X was downright unusable.


> Python is underspecified but freer of weird hazards in
> practice.
> 
> C and C++ should practically be outlawed at this point.  

On what grounds?  "I don't approve of the programming language you're 
using.  Cease and desist.  Nyah!"
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Jeff Schwab]

Paul Rubin wrote:
> Jeff Schwab <[EMAIL PROTECTED]> writes:
>> So to use the Perl example: If you want to sort a list using some
>> arbitrary snippet of code as the comparison function, you can write:
>>  sort { code to compare $a and $b } @elements
> 
> Yes, you can do that in Python, using a lambda expression, a named
> function, or whatever.

You can indeed.  I think you can also use this to do the other stuff you 
would expect, e.g. return locally defined code snippets to define closures:

 def mkadder(n):
 return lambda x: x + n

I have gotten the impression that this was somehow inferior in Python 
though, at least in terms of performance.  Every time somebody uses 
lambda here, they seem to get a bunch "why are you using lambda?" 
responses.  If I am grossly mistake, please just enlighten me.


>> What language do you have in mind, in which lambda is more basic than
>> named definitions?  Are you coming from a functional language
>> background?
> 
> All languages that I know of with lambda, treat it as more basic than
> named definitions, e.g. the Lisp family (not sure if those count as
> functional languages) in addition to functional languages like Haskell.

I note from your other posts that you seem to have a strong Lisp bent. 
Lisp programmer and Smalltalk programmers stand out in the crowd.  I 
first noted this when somebody found a while-loop offensive, on the 
grounds that recursion was somehow a more natural way to implement 
looping.  It can take a while to convince somebody like that they 
different idioms work best in different languages.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Jeff Schwab]

Matthew Woodcraft wrote:
> Jeff Schwab  <[EMAIL PROTECTED]> wrote:
>> Matthew Woodcraft wrote:
>>> Jeff Schwab  <[EMAIL PROTECTED]> wrote:
 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.
>  
>>> Out of interest, what is the usual way to manage errors that the
>>> operating system reports when it closes the file?
> 
>> By default, the fstream object just sets its "failbit," which you can 
>> check manually by calling my_stream.fail().  If you want anything 
>> particular to take place on failure to close a stream, you either have 
>> to call close manually, or you need a dedicated object whose destructor 
>> will deal with it.
> 
>> Alternatively, you can tell the fstream ahead of time that you want 
>> exceptions thrown if particular actions fail.  There's a convention that 
>> destructors don't ever throw exceptions, though, so it would be unusual 
>> to request an exception when close() fails.
> 
> I see. Then, unless you don't care about data loss passing silently,
> this 'most traditional' way to open a file is unsuitable for files
> opened for writing.

No, why would you think so?  If you want something special to happen 
when the close() fails (as you indeed would if you were writing 
important data), you have to say somehow that you want your special code 
called.  What syntax would you like to see?  Here's what the C++ would 
look like, supposing you have a type LoggingCloser that calls close and 
logs any failure:

 void f(std::string file_name) {
 std::ofstream out(file_name.c_str()); // [1]
 LoggingCloser closer(out);

 // ... your work code here ...
 }

The closer's destructor is guaranteed to be called before the file 
stream's.  That gives it a chance to call close manually, and keeps the 
error-handling code separate from the rest of the program logic. 
Compare the following Python equivalent, assuming we've replaced Logging 
Closer's constructor and destructor with __enter__ and __exit__ definitions:

 def f(file_name):
with file(file_name, 'w') as out:
 with LoggingCloser(out) as closer:
 // ... your work code here ...

In this case, the Python with-statement is not too bad, because you only 
have two constructor/destructor pairs.  For each new pair, though, it 
seems like you need an extra level of nesting (and therefore 
indentation).  Of course, it may just be that I don't yet know how to 
use the with-statement effectively.

[1] That c_str() kludge is usually the primary complaint about using 
ofstream.  It has been fixed in the new draft standard, which will 
become official in 2009.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Paul Rubin]

Jeff Schwab <[EMAIL PROTECTED]> writes:
> So to use the Perl example: If you want to sort a list using some
> arbitrary snippet of code as the comparison function, you can write:
>  sort { code to compare $a and $b } @elements

Yes, you can do that in Python, using a lambda expression, a named
function, or whatever.  

> What language do you have in mind, in which lambda is more basic than
> named definitions?  Are you coming from a functional language
> background?

All languages that I know of with lambda, treat it as more basic than
named definitions, e.g. the Lisp family (not sure if those count as
functional languages) in addition to functional languages like Haskell.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Paul Rubin]

Jeff Schwab <[EMAIL PROTECTED]> writes:
> One great thing about C is that
> a programmer can realistically hope to know the entire language
> definition; maybe Guido would like the same to be true of Python.

C is horrendously complicated, with zillions of obscure traps.  C++ is
even worse; there's actually a published book specifically about C++
pitfalls.  Python is underspecified but freer of weird hazards in
practice.

C and C++ should practically be outlawed at this point.  
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Jeff Schwab]

Paul Rubin wrote:
> "Terry Reedy" <[EMAIL PROTECTED]> writes:
>> | Yes, this seems to be the Python way:  For each popular feature of some
>> | other language, create a less flexible Python feature that achieves the
>> | same effect in the most common cases (e.g. lambda to imitate function
>> | literals, or recursive assignment to allow x = y = z).
>>
>> This is a rather acute observation.  Another example is generators versus 
>> full coroutines (or continuations).  Guido is content to capture 80% of the 
>> practical use cases of a feature.  He never intended Python to be a 100% 
>> replace-everything language.
> 
> I don't understand the lambda example due to not being sure what Jeff
> means by "function literals".  But in other languages, lambda is the
> basic primitive, and "def" or equivalent is syntax sugar.

Sorry, I didn't know what else to call them except "lambdas."  I meant 
the bare code blocks you can use in Perl, or what Java tries to achieve 
via anonymous inner classes.  So to use the Perl example:  If you want 
to sort a list using some arbitrary snippet of code as the comparison 
function, you can write:

 sort { code to compare $a and $b } @elements

This isn't really "native" in C++ either:

 http://www.boost.org/doc/html/lambda.html

What language do you have in mind, in which lambda is more basic than 
named definitions?  Are you coming from a functional language background?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Jeff Schwab]

Terry Reedy wrote:
> "Jeff Schwab" <[EMAIL PROTECTED]> wrote in message 
> news:[EMAIL PROTECTED]
> [snip discussion of 'with' statements]
> 
> | Yes, this seems to be the Python way:  For each popular feature of some
> | other language, create a less flexible Python feature that achieves the
> | same effect in the most common cases (e.g. lambda to imitate function
> | literals, or recursive assignment to allow x = y = z).
> 
> This is a rather acute observation.  Another example is generators versus 
> full coroutines (or continuations).  Guido is content to capture 80% of the 
> practical use cases of a feature.  He never intended Python to be a 100% 
> replace-everything language.

I think the idea is to balance power on one hand, against complexity and 
potential confusion on the other.  One great thing about C is that a 
programmer can realistically hope to know the entire language 
definition; maybe Guido would like the same to be true of Python.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Hrvoje Niksic]

"Terry Reedy" <[EMAIL PROTECTED]> writes:

> "Jeff Schwab" <[EMAIL PROTECTED]> wrote in message 
> news:[EMAIL PROTECTED]
> [snip discussion of 'with' statements]
>
> | Yes, this seems to be the Python way:  For each popular feature of some
> | other language, create a less flexible Python feature that achieves the
> | same effect in the most common cases (e.g. lambda to imitate function
> | literals, or recursive assignment to allow x = y = z).
>
> This is a rather acute observation.  Another example is generators versus 
> full coroutines (or continuations).

Another example that comes to mind is "with" statement versus a macro
system that allowed one to define custom statements based on
try...finally.  contextlib.contextmanager implements an even more
specific subset of this functionality.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Paul Rubin]

"Terry Reedy" <[EMAIL PROTECTED]> writes:
> | Yes, this seems to be the Python way:  For each popular feature of some
> | other language, create a less flexible Python feature that achieves the
> | same effect in the most common cases (e.g. lambda to imitate function
> | literals, or recursive assignment to allow x = y = z).
> 
> This is a rather acute observation.  Another example is generators versus 
> full coroutines (or continuations).  Guido is content to capture 80% of the 
> practical use cases of a feature.  He never intended Python to be a 100% 
> replace-everything language.

I don't understand the lambda example due to not being sure what Jeff
means by "function literals".  But in other languages, lambda is the
basic primitive, and "def" or equivalent is syntax sugar.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Terry Reedy]

"Jeff Schwab" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
[snip discussion of 'with' statements]

| Yes, this seems to be the Python way:  For each popular feature of some
| other language, create a less flexible Python feature that achieves the
| same effect in the most common cases (e.g. lambda to imitate function
| literals, or recursive assignment to allow x = y = z).

This is a rather acute observation.  Another example is generators versus 
full coroutines (or continuations).  Guido is content to capture 80% of the 
practical use cases of a feature.  He never intended Python to be a 100% 
replace-everything language.

tjr



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Paul Rubin]

Nicola Musatti <[EMAIL PROTECTED]> writes:
> >>>a = [f(x) + g(y) for x,y in izip(m1, m2) if h(x,y).frob() == 7]
> [...]
> > There you replace one line of code with 40+ lines to get around the
> > absence of GC.  Sounds bug-prone among other things.
> 
> Come on, you didn't define f, g, izip, h or frob either. It's more
> like 5 to one. Furthermore your code is more compact due to the
> existence of list comprehensions, not because of GC. Had you written a
> loop the difference would be smaller.


No I don't need a loop if I don't use the listcomp.  I could say

  a = map(lambda x,y: f(x)+g(y), ifilter(lambda x,y: h(x,y).frob==7,
   izip(m1, m2)))

the listcomp is basically syntax sugar for that.

The issue here is that Python is simply more expressive than C++,
which doesn't support creation of higher order functions like that.
However, one of the consequences of programming in this style is
you allocate a lot of temporary objects which best managed by GC.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Paul Rubin]

Jeff Schwab <[EMAIL PROTECTED]> writes:
>   some_class().method()
> The method body could create an external reference to the instance of
> some_class, such that the instance would not be reclaimed at the end of
> the statement.

Yes.  Therefore there is no way to predict if the object will be be
freed, without intimate knowledge of the semantics of the class and
method.  

> It's not "my" scheme.  I got it from Martelli.

Well, he's a very wise and knowledgable Pythonista, so I hope he's
using the "with" statement by now.

> This is a special case of the reference count being 1, then
> immediately dropping to zero.  It is simple and convenient.  The
> approach is, as you rightly point out, not extensible to more
> complicated situations in Python, because the reference counting
> ceases to be trivial.

It's not trivial even in the simplest case, like the one you cited
of opening a file.  Maybe you've shadows the "open" function to
keep a cache of file contents or something.

> The point is that once you tie object lifetimes to scope, rather than
> unpredictable garbage collection, you can predict with perfect ease
> and comfort exactly where the objects are created and destroyed.

Sure, fine, Python does that with the "with" statement and C++ does
it with class destructors on automatic variables.  The old kludge of 

  some_class().method()

creates an instance of some_class but does NOT tie it to a scope,
for the reasons we've discussed.  

> That's true of the current language.  I don't have enough experience
> with "with" yet to know whether it's a realistic solution to the
> issue. IMO, they are at least preferable to Java-style
> finally-clauses, but probably not a replacement for C++-style RAII.

It is a more general version of what C++ does, as I understand it.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Matthew Woodcraft]

Jeff Schwab  <[EMAIL PROTECTED]> wrote:
>Matthew Woodcraft wrote:
>> Jeff Schwab  <[EMAIL PROTECTED]> wrote:
>>> 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.
 
>> Out of interest, what is the usual way to manage errors that the
>> operating system reports when it closes the file?

> By default, the fstream object just sets its "failbit," which you can 
> check manually by calling my_stream.fail().  If you want anything 
> particular to take place on failure to close a stream, you either have 
> to call close manually, or you need a dedicated object whose destructor 
> will deal with it.

> Alternatively, you can tell the fstream ahead of time that you want 
> exceptions thrown if particular actions fail.  There's a convention that 
> destructors don't ever throw exceptions, though, so it would be unusual 
> to request an exception when close() fails.

I see. Then, unless you don't care about data loss passing silently,
this 'most traditional' way to open a file is unsuitable for files
opened for writing.

-M-
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Jeff Schwab]

Matthew Woodcraft wrote:
> Jeff Schwab  <[EMAIL PROTECTED]> wrote:
>> 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.
> 
> Out of interest, what is the usual way to manage errors that the
> operating system reports when it closes the file?

By default, the fstream object just sets its "failbit," which you can 
check manually by calling my_stream.fail().  If you want anything 
particular to take place on failure to close a stream, you either have 
to call close manually, or you need a dedicated object whose destructor 
will deal with it.

Alternatively, you can tell the fstream ahead of time that you want 
exceptions thrown if particular actions fail.  There's a convention that 
destructors don't ever throw exceptions, though, so it would be unusual 
to request an exception when close() fails.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Matthew Woodcraft]

Jeff Schwab  <[EMAIL PROTECTED]> wrote:
> 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.

Out of interest, what is the usual way to manage errors that the
operating system reports when it closes the file?

-M-
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Rhamphoryncus]

On Feb 23, 11:39 am, Nicola Musatti <[EMAIL PROTECTED]> wrote:
> Paul Rubin wrote:
> > Nicola Musatti <[EMAIL PROTECTED]> writes:
> >>>a = [f(x) + g(y) for x,y in izip(m1, m2) if h(x,y).frob() == 7]
> [...]
> > There you replace one line of code with 40+ lines to get around the
> > absence of GC.  Sounds bug-prone among other things.
>
> Come on, you didn't define f, g, izip, h or frob either. It's more like
> 5 to one. Furthermore your code is more compact due to the existence of
> list comprehensions, not because of GC. Had you written a loop the
> difference would be smaller.

So here's three versions, for comparison:


a = [f(x) + g(y) for x,y in izip(m1, m2) if h(x,y).frob() == 7]


a = []
for x, y in izip(m1, m2):
if h(x, y).frob() == 7:
a.append(f(x) + g(y))


std::vector a;
for (std::someiterable::iterator i = izip(m1, m2); !
i.finished(); ++i) {
if (h(i->first, i->second).frob() == 7)
a.push_back(f(i->first) + g(i->second));
}

Although the the benefits of static typing can be argued, surely you
can see the clarity tradeoffs that you make for it?

Some notes:
* izip() takes two iterables as input and returns an iterator, using
only O(1) memory at any given time.  Your original version got this
wrong.
* I fudged the "!i.finished()" as I couldn't find an appropriate
official version in time for this post
* The iterator can't sanely be copied, so it probably needs to use
refcounting internally.  Oops, that's GC...
* Whoever decided to keep C's i++ syntax for iterators should be shot
* x and y aren't named.  They could be extracted, but it's just enough
effort that it's probably not worth it in C++.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Jeff Schwab]

Carl Banks wrote:
> On Feb 23, 6:40 am, Jeff Schwab <[EMAIL PROTECTED]> wrote:
>> Recently, I've had a few replies in tones that imply I'm on the brink of
>> entering several kill-files, mostly because I express disagreement with
>> a few closely held beliefs of some other c.l.p posters.
> 
> A bit of advice:
> 
> Python and C++ have almost no common ground in terms of what the
> priorties of the language are.

Producing software of measurable quality.  Increasing developer 
productivity.  Providing in-language support for formal design and 
development processes.  I think the languages approach the same 
high-level goals, just from very different angles.


> So, if you're a big proponent of the
> language features of C++, you really ought to expect lots of
> disagreement over just about anything you opine.
> 
> P.S. I've had much sharper disagreements with some Pythonistas over
> aspects of Python.  None of them are in my killfile.

Good to know. :)


>> One of the things that's supposed to be great about Python is the user
>> community, and in many ways, that community is wonderful; for example,
>> both new and experienced users can quickly get a variety of solutions to
>> any given coding issue, just by asking for help.
> 
> They say that about every small language community.

I'm not sure Python qualifies as a small community anymore.

Language-based communities that continue to support free thought and 
open conversation over time are much more rare.  The worst case scenario 
is (apologies in advance) the Lisp-style consensus: This language is 
just the best tool for every job, period.


>> In other ways, though, the Python community is just blindingly ignorant,
>> arrogant, and argumentative.
> 
> You're not exactly riding the humble bus there yourself, chief.
> Saying things like (in so many words), "I'm just here because C++
> doesn't have good runtime libraries", doesn't come off too well.

That's not how I feel, and I never meant to imply anything like it. 
Things I like about Python:

- No separate compilation step during development
- Emphasis on design-for-test
- Extensibility from other languages
- Clean syntax
- Portability
- Mainstream use and support
- Excellent documentation
- Large standard library
- Progress by design, rather than ad hoc "improvements"
- Design decisions value "useful" over "neat-o"
- Support for data-as-code (or code-as-data)


>> and I am starting to become
>> really concerned about the clarity of mind of the Python community,
>> because I hope to rely on it.
> 
> I think your expectations for the Python community are unreasonable.

Maybe.


> My advice to you, if you want a good relationship with the Python
> community, would be to keep the comparisons with C++ out of it as much
> as possible.  Understand that a lot--a lot--of people are going to say
> bad things about C++ and various features that C++ implements.  If you
> try to defend C++ every time that happens, you won't last long here.

Thanks.  I do value my sanity, and would like to preserve what's left of it.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Nicola Musatti]

Paul Rubin wrote:
> Nicola Musatti <[EMAIL PROTECTED]> writes:
>>>a = [f(x) + g(y) for x,y in izip(m1, m2) if h(x,y).frob() == 7]
[...]
> There you replace one line of code with 40+ lines to get around the
> absence of GC.  Sounds bug-prone among other things.

Come on, you didn't define f, g, izip, h or frob either. It's more like 
5 to one. Furthermore your code is more compact due to the existence of 
list comprehensions, not because of GC. Had you written a loop the 
difference would be smaller.

>> int f(int n) { return n * 2; }
>> int g(int n) { return ( n * 2 ) + 1; }
> 
> That is not a reasonable translation, since you've assumed the output
> of f and g are integers that don't need to be dynamically allocated.
> Maybe in the Python example, f and g and x and y are all bignums or
> matrices or something like that.

In my example I return a map by value just to show that it can be 
generalized to more complex data types. This is not C: in C++ you can go 
a long way without allocating dynamic memory explicitly. In my example 
std::map and std::vector do it for me.

Cheers,
Nicola Musatti
-- 
Nicola.Musatti  gmail  com
Home: http://nicola.musatti.googlepages.com/home
Blog: http://wthwdik.wordpress.com/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Nicola Musatti]

Marc 'BlackJack' Rintsch wrote:
[...]
> Or are used to think of OOP as a graph of objects that are communicating
> with each other.  In the value type style you are "talking" to copies of
> objects all the time which I find a bit confusing because *I* have to keep
> track of which maybe not so identical twin brother of an object I'm
> talking at each point.

But C++ gives you both; you use values for things that have equality but 
not identity and (smart) pointers for the opposite case.

> Also it seems odd to me to copy large collections around instead of
> passing references.  Your `izip()` creates a quite small `map` -- what
> about big ones.  With mutable objects!?

True, and in a serious application I'd probably pass the map by 
reference into the function. Still, it's rather likely that these copies 
are optimized away by the compiler; this is what VC++ does, for instance.

Cheers,
Nicola Musatti
-- 
Nicola.Musatti  gmail  com
Home: http://nicola.musatti.googlepages.com/home
Blog: http://wthwdik.wordpress.com/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Carl Banks]

On Feb 23, 6:40 am, Jeff Schwab <[EMAIL PROTECTED]> wrote:
> Recently, I've had a few replies in tones that imply I'm on the brink of
> entering several kill-files, mostly because I express disagreement with
> a few closely held beliefs of some other c.l.p posters.

A bit of advice:

Python and C++ have almost no common ground in terms of what the
priorties of the language are.  So, if you're a big proponent of the
language features of C++, you really ought to expect lots of
disagreement over just about anything you opine.

P.S. I've had much sharper disagreements with some Pythonistas over
aspects of Python.  None of them are in my killfile.


> One of the things that's supposed to be great about Python is the user
> community, and in many ways, that community is wonderful; for example,
> both new and experienced users can quickly get a variety of solutions to
> any given coding issue, just by asking for help.

They say that about every small language community.


> In other ways, though, the Python community is just blindingly ignorant,
> arrogant, and argumentative.

You're not exactly riding the humble bus there yourself, chief.
Saying things like (in so many words), "I'm just here because C++
doesn't have good runtime libraries", doesn't come off too well.


> and I am starting to become
> really concerned about the clarity of mind of the Python community,
> because I hope to rely on it.

I think your expectations for the Python community are unreasonable.

My advice to you, if you want a good relationship with the Python
community, would be to keep the comparisons with C++ out of it as much
as possible.  Understand that a lot--a lot--of people are going to say
bad things about C++ and various features that C++ implements.  If you
try to defend C++ every time that happens, you won't last long here.


Carl Banks
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Jeff Schwab]

Paul Rubin wrote:
> Jeff Schwab <[EMAIL PROTECTED]> writes:
>> 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.

Yes, this seems to be the Python way:  For each popular feature of some
other language, create a less flexible Python feature that achieves the
same effect in the most common cases (e.g. lambda to imitate function
literals, or recursive assignment to allow x = y = z).


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

It doesn't "happen" to work that way in the example; it works that way
by design.  I see what you're saying, though, and it is a good point.
Given a statements of the form:

some_class().method()

The method body could create an external reference to the instance of
some_class, such that the instance would not be reclaimed at the end of
the statement.


> Other code might well do
> something different, especially in a complex multi-statement scope.
> Your scheme's

It's not "my" scheme.  I got it from Martelli.


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

This is a special case of the reference count being 1, then immediately 
dropping to zero.  It is simple and convenient.  The approach is, as you 
rightly point out, not extensible to more complicated situations in 
Python, because the reference counting ceases to be trivial.

The point is that once you tie object lifetimes to scope, rather than 
unpredictable garbage collection, you can predict with perfect ease and 
comfort exactly where the objects are created and destroyed.  If you can 
then request that arbitrary actions be taken automatically when those 
events happen, you can pair up resource acquisitions and releases very 
easily.  Each resource has an "owner" object whose constructor acquires, 
and whose destructor releases.  The resources are released in the 
reverse order, which is almost always exactly what you want.

Suppose you are using objects that have to be closed when you have 
finished with them.  You would associate this concept with a type:

 class Closer:
 def __init__(self, closable):
 self.closable = closable)
 def __del__(self):
 self.closable.close()

The C++-style paradigm would then let you do this:

 def my_func(a, b, c):
 a_closer = Closer(a)
 b_closer = Closer(b)
 c_closer = Closer(c)

# ... arbitrary code ...

If an exception gets thrown, the objects get closed.  If you return 
normally, the objects get closed.  This is what "with" is supposed to 
replace, except that it only seems to cover the trivial case of a 
single, all-in-one cleanup func.  That's only a direct replacement for a 
single constructor/destructor pair, unless you're willing to have an 
additional, nested with-statement for each resource.

Now suppose there is an object type whose instances need to be 
"released" rather than "closed;" i.e., they have a release() method, but 
no close() method.  No problem:  You have the Closer class get its 
action indirectly from a mapping of types to close-actions.  Whenever 
you have a type whose instances require some kind of cleanup action, you 
add an entry to the mapping.

 class Closer:
actions = TypeActionMap()

 # ...

 def __del__(self):
 actions[type(self.closable)](self.closable)

The mapping is not quite as simple as a dict, because of inheritance. 
This is what function overloads and C++ template specializations are 
meant to achieve.  Similar functionality could be implemented in Python 
via pure Python mapping types, represented above by TypeActionMap.


> If you want
> reliable destruction it's better to set it up explicitly, using
> "with".

That's true of the current language.  I don't have enough experience 
with "with" yet to know whether it's a realistic solution to the issue. 
  IMO, they are at least preferable to Java-style finally-clauses, but 
probably not a replacement for C++-style RAII.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Jeff Schwab]

Ryan Ginstrom wrote:
>> On Behalf Of Jeff Schwab
>> When I see this silliness again and again, it really breaks 
>> my heart
> 
> If you allow your heart to be broken by others' opinions, you're setting
> yourself up for a lot of disappointment IMHO.

It's not so much their opinions, as the fact that their opinions 
strongly influence their work.  But you're probably right, anyway.


> I personally used C++ for about 90% of my code for 10 years. During that
> time, I was chugging the C++ Kool-Aid so hard I almost peed myself.> I still
> think that C++ is a beautiful language, but I have also come to think that
> starting a program with C++ is a premature optimization. 

I'm not much of a Kool Aid drinker. :)  I just tend to find, when I 
develop anything non-trivial in a language other than C++, that I wish I 
had used C++, because it would have allowed me to enforce design 
semantics more efficiently.  Optimization has nothing to do with it; I'm 
a firm believer in profiling before you optimize.


> I think that very few Python programmers today started with Python. Most of
> them came to Python for a reason. 

For several reasons, even!
-- 
http://mail.python.org/mailman/listinfo/python-list

RE: Article of interest: Python pros/cons for the enterprise

[Ryan Ginstrom]

> On Behalf Of Jeff Schwab
> When I see this silliness again and again, it really breaks 
> my heart

If you allow your heart to be broken by others' opinions, you're setting
yourself up for a lot of disappointment IMHO.

I personally used C++ for about 90% of my code for 10 years. During that
time, I was chugging the C++ Kool-Aid so hard I almost peed myself. I still
think that C++ is a beautiful language, but I have also come to think that
starting a program with C++ is a premature optimization. 

I think that very few Python programmers today started with Python. Most of
them came to Python for a reason. 

Regards,
Ryan Ginstrom

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Jeff Schwab]

George Sakkis wrote:
> On Feb 22, 2:15 pm, Jeff Schwab <[EMAIL PROTECTED]> wrote:
> 
>> Nicola Musatti wrote:
>>> The real sad thing is that nobody is likely to convince Guido to turn
>>> CPython into C++Python ;-)
>> How difficult would that be?  Could it be done in stages?  I would be
>> willing to spend some time on that kind of project.
> 
> Yeah right.. what we need is yet another implementation of Python. At
> least Jython/IronPython/Pypy (and Pyrex, Cython, Shedskin, etc.) had a
> better motivation than "my language is better than yours". I am sure
> your time, skills and experience would be much appreciated in more
> useful projects.

Neither C++ nor C is "my" language, nor "yours."  I love all my children 
the same. :)  That said, your point is well taken.

What I would like is not so much a new Python implementation, as a 
vehicle to help demonstrate a few things to other Python users. 
Recently, I've had a few replies in tones that imply I'm on the brink of 
entering several kill-files, mostly because I express disagreement with 
a few closely held beliefs of some other c.l.p posters.  For example, 
the following are widely held opinions with which I disagree:

(1) Python is a gotcha-free language.

(2) C++ is basically the same language as C, but more complicated.

(3) Garbage collection is at least as desirable a language feature as 
deterministic destruction.

(4) Static typing is inferior to dynamic typing.

One of the things that's supposed to be great about Python is the user 
community, and in many ways, that community is wonderful; for example, 
both new and experienced users can quickly get a variety of solutions to 
any given coding issue, just by asking for help.

In other ways, though, the Python community is just blindingly ignorant, 
arrogant, and argumentative.  I expect my use of Python to increase in 
the coming years, so I want the best possible relationship with other 
regular users, especially on Usenet.  To do that, I think it would be 
helpful to have an informed discussion.  Instead, I mostly just the same 
old justifications for baseless bigotry:

"I worked with crappy [Perl or C++] code for ten years, so when I tell 
you [Perl or C++] encourages crappy code, I know what I'm talking about."

"These beliefs are accepted by just about everybody.  You don't *really* 
think all these bright people are wrong, do you?"

"C++ is not newbie-friendly; if you need proof, just look at all these 
really low-level ways you can screw yourself."

When I see this silliness again and again, it really breaks my heart, 
because the culture of the software development industry has a strong 
effect on the quality of my own life.  I care about clean air, because I 
breath it; clean water, because I drink it; and I am starting to become 
really concerned about the clarity of mind of the Python community, 
because I hope to rely on it.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Jeff Schwab]

Bruno Desthuilliers wrote:
> Jeff Schwab a écrit :
>> Bruno Desthuilliers wrote:
>>> Carl Banks a écrit :
 On Feb 20, 8:58 am, Tim Chase <[EMAIL PROTECTED]> wrote:
>> You Used Python to Write WHAT?
>> http://www.cio.com/article/185350
> """
> Furthermore, the power and expressivity that Python offers means
> that it may require more skilled developers.
> [...down to the summary...]
> Python may not be an appropriate choice if you:
> [...]
> *  Rely on teams of less-experienced programmers. These
> developers may benefit from the wider availability of training
> for languages like Java and are less likely to make mistakes with
> a compile-time, type-checked language.
> """
>
>>> (snip)

 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)
>>
>>
>> NB:  This is not a troll.  (Please, nobody try to be cute with a "yes 
>> it is" reply.)
> 
> NB : standard disclaimer about all the following being MVHO.
> 
>> c.l.python seem to be about the most close-minded of any of the 
>> currently popular language-specific news groups. 
> 
> May I suggest you take a tour on c.l.lisp then ?-)
> 
>> It's just taken for granted that Perl and C++, two of my personal 
>> favorite things in this world, inherently favor ugly, buggy code. 
> 
> I wouldn't say so.
> 
> It's a fact that C++ is a really complex language with quite a lot of 
> room for BigMistakes(tm), and that there's something like a 
> 'my-code-is-more-cryptic-than-yours' culture in Perl. You cannot 
> seriously argue on this.

I'm not going to argue, because I'm tired of arguing.  But I think 
you're SeriouslyMistaken(tm).


> Now this has nothing to do with the respective merits of both languages 
> (FWIW, Perl, as a 'Practical Extracting and Reporting Language', beats 
> any other language I know pants down), and I'd be sorry if you were to 
> confuse what is mostly on the friendly jokes side with mere bashing. You 
> may not have noticed, but quite a lot of people here have a working 
> experience with either C++ and/or Perl.

Yes.  These "jokes" don't strike me as friendly, though.  They strike me 
as ignorant and hostile.


> As for my above comment, it doesn't imply anything else than the fact 
> that C++ is way harder to learn than Python (or Ruby etc...), and that 
> bugs in C++ code are likely to have way more nasty results.

Both of which I disagree with.  I don't see how the same brain can 
believe it's much harder to do good things, yet much easier to do bad 
things, in the same language.


> The joke is 
> not "against" C++, but about people asserting than static type checking 
> is safer than dynamic type checking without realizing that what is 
> really important is*runtime type checking - something C++ doesn't provide.

C++ does provide some run-time type-checking, whereas Python offers 
virtually no static type-checking.  Clearly, C++ does not natively have 
a run-time environment as powerful as Python's, and that's one of the 
primary reasons to use Python.  If you need a heavyweight runtime 
environment available from C++, you have to provide one.  This is a 
direct consequence of early design decisions intended to make C++ 
competitive with C.  I have yet to see a runtime-heavy C++ library I 
really like, whereas Python, Ruby, and Java all have fantastic sets of 
run-time facilities.


> NB : As a side note, and while being myself a bit passionated when it 
> comes to languages and my job in general, I would not go as far as 
> labelling any language or technology as "one of my favorite things in 
> this world".

That's OK. :)  I really do feel that way, though.  Call me a dork.


>> That is the farthest thing from the truth as I see it.  You can (and 
>> plenty of people will) write terrible code in any language, including 
>> Python.
> 
> Indeed. Bad coders write bad code, period. And I think we've all been 
> bad coders one day, and that we're all still bad coders sometimes.

Aha!  Now we're getting somewhere!


>> To use Python effectively, you have to know something about how it 
>> works, and the same is true of Perl and C++. 
> 
> And of any other language. Now a decent C++ or Perl programmer can be 
> proficient in Python in a couple weeks and become a master within a year 
> at worst. And it seems that non-professional, occasional programmers 
> (hobbyists, gamers, scientists, and any other kind of power user) are 
> able to get their job done in Python without much pain.

They can get their jobs done with C++ without much pain, too, given even 
a little bit of decent guidance.  It's true that you *can* shoot 
yourself in the foot with C++, but you kind of have to work at it.  (One 
good way is to write C code, and think it's C++.)


>> But a newbie who's

Re: Article of interest: Python pros/cons for the enterprise

[George Sakkis]

On Feb 22, 2:15 pm, Jeff Schwab <[EMAIL PROTECTED]> wrote:

> Nicola Musatti wrote:
> > The real sad thing is that nobody is likely to convince Guido to turn
> > CPython into C++Python ;-)
>
> How difficult would that be?  Could it be done in stages?  I would be
> willing to spend some time on that kind of project.

Yeah right.. what we need is yet another implementation of Python. At
least Jython/IronPython/Pypy (and Pyrex, Cython, Shedskin, etc.) had a
better motivation than "my language is better than yours". I am sure
your time, skills and experience would be much appreciated in more
useful projects.

George
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Jeff Schwab]

Carl Banks wrote:
> On Feb 22, 12:23 am, Jeff Schwab <[EMAIL PROTECTED]> wrote:
>> Carl Banks wrote:
>>> On Feb 21, 7:17 pm, Jeff Schwab <[EMAIL PROTECTED]> wrote:
 Carl Banks wrote:
> On Feb 21, 1:22 pm, Nicola Musatti <[EMAIL PROTECTED]> wrote:
>> 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 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.

I disagree with you completely.  Your points don't make any sense to me 
at all.  I believe I am putting forth less effort by having a generic 
resource-management infrastructure, rather than a memory-specific 
language feature -- that's not just an implication, it's my honest belief.

But I guess we'll agree to disagree.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Jeff Schwab]

Nicola Musatti wrote:

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

How difficult would that be?  Could it be done in stages?  I would be 
willing to spend some time on that kind of project.  Since I know almost 
nothing about Python internals, though, I'd appreciate it if a 
C++-fluent Python expert could give an estimate in person-months.  Also, 
what would be the general break-down?  Maybe:

(1) Prepare a build environment appropriate for Python, supporting code 
in both C and C++.  Include unit-test targets, and a mechanism for 
module developers to add unit tests to those targets.

(2) Get all the headers C++-clean.

(3) Begin translating one module at a time.  Different people could work 
on different modules, and add their test-cases to the global target.

One potential problem would be linkage.  Would Python-internal C++ 
modules still have to provide C-linkable APIs, so that they could be 
invoked from other parts of Python?  A breakdown of module dependencies 
would help address this issue, so that it would be clear which parts of 
the code-base would be directly affected by translating a given module 
to C++.

At the external API level, would it still be important to support 
C-style linkage, even if the implementation code isn't written in C?  I 
don't know whether it's realistic for people embedding Python in non-C++ 
applications to have to work directly with C++ APIs.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Paul Rubin]

Nicola Musatti <[EMAIL PROTECTED]> writes:
> >a = [f(x) + g(y) for x,y in izip(m1, m2) if h(x,y).frob() == 7]
> >
> > Consider how many intermediate objects are being allocated in figuring
> > out that listcomp.  Do you REALLY want to manage all the deallocation
> > with something like RAII?
> 
> What makes you think that a translation of a similar expression would
> involve explicit dynamic allocation at all? Barring bugs, here's an
> equivalent example: ...

There you replace one line of code with 40+ lines to get around the
absence of GC.  Sounds bug-prone among other things.

> int f(int n) { return n * 2; }
> int g(int n) { return ( n * 2 ) + 1; }

That is not a reasonable translation, since you've assumed the output
of f and g are integers that don't need to be dynamically allocated.
Maybe in the Python example, f and g and x and y are all bignums or
matrices or something like that.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Paul Rubin]

Nicola Musatti <[EMAIL PROTECTED]> writes:
> > Partial guarantees are like being a little bit pregnant.
> 
> Yes, and I'm sure your tests cover all possible paths through your code.

That is the point of type checking.  With a sound type system, "int x"
makes sure, at compile time, that x stays an integer through every
possible path through the code and never becomes a string or anything
like that.  That's why Pierce's book on type systems describes them as
"lightweight formal methods".

The happening thing in language research these days is designing more
and more powerful type systems so that you can make sure, at compile
time, that any predicate that you can describe mathematically remains
true through all possible paths through the code.  So you can have the
compiler make sure, through every possible path through the code, not
just that x is some integer, but is the actual integer that you want,
e.g. if you want x to be the largest prime number smaller than 3*y,
you can define a type for that, and then if your program to compute x
passes the type checker, it cannot compute the wrong value.

Python is a very pleasant and productive environment for banging out
code quickly that does practical things straightforwardly, but in some
ways it feels almost like assembly language, in that you have to keep
track in your head of what types of values your program is computing,
instead of being able to rely on the compiler to catch errors.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Nicola Musatti]

On Feb 22, 5:13 pm, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote:
> On Fri, 22 Feb 2008 04:48:28 -0800, Nicola Musatti wrote:
[...]
> > As you can see the standard library takes care of all memory
> > management.
>
> Aaah, that's much nicer and easier to understand than the list
> comprehension.  After this great example I'll switch to C++.  ;-)

You should. As you can see C++ is way more explicit than
Python ;-)
>
> But somehow you still manage memory by writing in a style that favors
> value types.

Certainly, but this is a natural C++ programming style, at least for
those that aren't too deeply rooted in their C heritage.

Cheers,
Nicola Musatti


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Marc 'BlackJack' Rintsch]

On Fri, 22 Feb 2008 04:48:28 -0800, Nicola Musatti wrote:

> On Feb 22, 12:07 pm, Paul Rubin  wrote:
>> Nicola Musatti <[EMAIL PROTECTED]> writes:
>> > In C++ memory is just another resource which you can handle just like
>> > any other one, possibly using RAII.
>>
>> Ok, I'll bite.  Here's a straightforward Python expression:
>>
>>a = [f(x) + g(y) for x,y in izip(m1, m2) if h(x,y).frob() == 7]
>>
>> Consider how many intermediate objects are being allocated in figuring
>> out that listcomp.  Do you REALLY want to manage all the deallocation
>> with something like RAII?
> 
> 
> What makes you think that a translation of a similar expression would
> involve explicit dynamic allocation at all? Barring bugs, here's an
> equivalent example:
> 
> #include 
> #include 
> #include 
> 
> int f(int n) { return n * 2; }
> int g(int n) { return ( n * 2 ) + 1; }
> 
> std::map izip(int i, int j) {
>   std::map m;
>   m[i] = j;
>   m[j] = i;
>   return m;
> }
> 
> class A {
>   int i, j;
> public:
>   A(int ii, int jj) : i(ii), j(jj) {}
>   int frob() { return i + j; }
> };
> 
> A h(int i, int j) { return A(i, j); }
> 
> int main() {
>   int m1 = 3;
>   int m2 = 4;
>   std::vector a;
>   std::map m = izip(m1, m2);
>   for ( std::map::iterator i = m.begin(); i != m.end(); ++i )
>   {
>   if ( h(i->first, i->second).frob() == 7 )
>   a.push_back(f(i->first) + g(i->second));
>   }
>   for ( std::vector::iterator i = a.begin(); i != a.end(); ++i )
>   std::cout << *i << '\n';
> }
> 
> As you can see the standard library takes care of all memory
> management.

Aaah, that's much nicer and easier to understand than the list
comprehension.  After this great example I'll switch to C++.  ;-)

But somehow you still manage memory by writing in a style that favors
value types.

SCNR,
Marc 'BlackJack' Rintsch
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Chris Mellon]

On Fri, Feb 22, 2008 at 4:56 AM, Nicola Musatti
<[EMAIL PROTECTED]> wrote:
> On Feb 22, 12:24 am, Carl Banks <[EMAIL PROTECTED]> wrote:
>  > On Feb 21, 1:22 pm, Nicola Musatti <[EMAIL PROTECTED]> wrote:
>  >
>  > > 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.
>
There are many different kinds of resource and they have different
optimal handling techniques. Memory in particular is really easily
handled by GC - it's a resource that you can reclaim under pressure,
so deferring it's collection and release makes sense, and it's even
common these days for high quality GC to beat manual management in
performance (never mind correctness). Other kinds of resource are much
more timely, and require tight control over scopes, like mutexes and
other locks. RAII is fantastic for these sort of things. Shared but
limited resources like files work best with refcounting (closing a
file that something else holds a reference to is usually an error).

Optimally, you would have a language that provides all three in easy,
transparent ways. Python only provides two, but the first on is the
least important so Python manages at least a B. C++ provides all 3,
but importantly there's no language level enforcement of use, so you
can (and people do, and this is a common source of bugs) accidentally
bypass the mechanisms.

If I had to use C++ these days, I'd use D instead.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Nicola Musatti]

On Feb 22, 3:25 pm, Roy Smith <[EMAIL PROTECTED]> wrote:
> In article
> <[EMAIL PROTECTED]>,
>  Nicola Musatti <[EMAIL PROTECTED]> wrote:
>
> > Yet I'm convinced that even such partial guarantee is worth having.
>
> Partial guarantees are like being a little bit pregnant.

Yes, and I'm sure your tests cover all possible paths through your
code.

Cheers,
Nicola Musatti
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Lou Pecora]

In article <[EMAIL PROTECTED]>,
 "Reedick, Andrew" <[EMAIL PROTECTED]> wrote:

> 
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:python-
> > [EMAIL PROTECTED] On Behalf Of Carl Banks
> > Sent: Wednesday, February 20, 2008 8:39 PM
> > To: python-list@python.org
> > Subject: Re: Article of interest: Python pros/cons for the enterprise
> 
> > 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.
> 
> Eh, don't laugh too hard.  Since Python code isn't type-checked until
> the actual code block is executed, you have to go through the extra step
> of testing/running  every  line of code before you'll find an error.
> Then there's the problem of how mutable Python objects are.  So even if
> you execute every line of code, you might not have executed the code
> with every possible type of object combination.
> 
> Compared to a statically typed language, it can get very expensive to
> write comprehensive test cases for python scripts.  So I wouldn't be
> quick to dismiss the notion that Java/C#/C++ are more newbie-safe than
> Python. =/
> 
> An amusing case in point was where I had a type-cast error in an
> exception's catch block's print statement.  This simple error caused the
> program to stop with an unhandled exception.  Something that basic would
> have been caught in a statically typed language very early in the dev
> cycle when it's cheaper to fix the problem.  And the idea of
> running/testing exceptions or simple print statements isn't always
> foremost in people's minds.  =P


Well, you're technically right about static typing. That could head off 
some bugs... But my experience over several years has been that this has 
never happened to me.  That is, where I need to test every line of code 
or even half of them.  What usually happens is that I get an error, I 
get the line and module, go there, and realize I tried to use data that 
didn't fit the expression (e.g. an object without the required method).  
Usually, a one-step fix.  What still occasionally gets me is mutable 
objects where I just use "=" to set two things (accidentally) equal to a 
mutable object instead of copying. Then modify one and get and error 
when the other object is used since they were the same object.  I know 
better, but I have a half life on this of about 4 months which means 
that about twice a year this one gets me.

Looking at it the other way having done C++ development, I am  w a y  
more productive in Python and overall spend far less time debugging.  
Just my experience.  YMMV.

-- 
-- Lou Pecora
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Roy Smith]

In article 
<[EMAIL PROTECTED]>,
 Nicola Musatti <[EMAIL PROTECTED]> wrote:

> Yet I'm convinced that even such partial guarantee is worth having.

Partial guarantees are like being a little bit pregnant.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Bruno Desthuilliers]

Nicola Musatti a écrit :
> On Feb 22, 9:03 am, Bruno Desthuilliers  [EMAIL PROTECTED]> wrote:
>> Nicola Musatti a écrit :
> [...]
>>> 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.
> 
> I suspect nobody seriously does, not even in C++ newsgroups ;-)

Mmm... Feel like I've been trolled !-)

>>> Had we been speaking of productivity... but we weren't, were we?
>> Should we ?-)
> 
> Oh, I'm convinced that Python wins in many contexts, but I believe
> that it has more to do with the number of batteries that come with the
> package rather than to its being a dynamically typed language. Is this
> controversial enough? ;-)

Brillant !-)

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Nicola Musatti]

On Feb 22, 12:07 pm, Paul Rubin  wrote:
> Nicola Musatti <[EMAIL PROTECTED]> writes:
> > In C++ memory is just another resource which you can handle just like
> > any other one, possibly using RAII.
>
> Ok, I'll bite.  Here's a straightforward Python expression:
>
>a = [f(x) + g(y) for x,y in izip(m1, m2) if h(x,y).frob() == 7]
>
> Consider how many intermediate objects are being allocated in figuring
> out that listcomp.  Do you REALLY want to manage all the deallocation
> with something like RAII?


What makes you think that a translation of a similar expression would
involve explicit dynamic allocation at all? Barring bugs, here's an
equivalent example:

#include 
#include 
#include 

int f(int n) { return n * 2; }
int g(int n) { return ( n * 2 ) + 1; }

std::map izip(int i, int j) {
std::map m;
m[i] = j;
m[j] = i;
return m;
}

class A {
int i, j;
public:
A(int ii, int jj) : i(ii), j(jj) {}
int frob() { return i + j; }
};

A h(int i, int j) { return A(i, j); }

int main() {
int m1 = 3;
int m2 = 4;
std::vector a;
std::map m = izip(m1, m2);
for ( std::map::iterator i = m.begin(); i != m.end(); ++i )
{
if ( h(i->first, i->second).frob() == 7 )
a.push_back(f(i->first) + g(i->second));
}
for ( std::vector::iterator i = a.begin(); i != a.end(); ++i )
std::cout << *i << '\n';
}

As you can see the standard library takes care of all memory
management.

Cheers,
Nicola Musatti
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Paul Boddie]

On 22 Feb, 06:37, George Sakkis <[EMAIL PROTECTED]> wrote:
> 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.) ?

Boo and Cobra have their interesting sides, although I doubt that I'm
alone in finding it hard to take them as seriously as I might because
of various blatant, seemingly gratuitous, incompatible differences
with Python. And although one can always say that we should ignore
community size, what we've seen from Python-oriented projects like
PyPy and Shed Skin is that without being able to use a lot of existing
code, people don't hang around considering using something seriously
for very long, even if there's merit in hanging around and reworking
existing code.

Both Boo and Cobra are quite focused on the CLR, which isn't
necessarily appealing for a number of reasons (technical, legal [*]).
They both promote static typing plus type inference, although it
doesn't seem to be particularly extensive type inference and may
benefit from working against a load of statically typed libraries.
Both have language extensions which people have argued for in Python,
but choose different ways of doing things: Boo's property declarations
are minimal but seem out of place; Cobra's property declarations add a
bit more syntax; Boo provides some support for preconditions (as far
as I can see); Cobra has syntax for contracts. Boo also adds a load of
extra stuff for interfaces, abstract methods, and so on.

I don't blame people for going off and doing their own language: it's
clear that Python is moving in it's own direction and introducing
syntax incompatibilities which aren't justified by high level
objectives such as performance or compile-time tests. But since the
days of Vyper (a defunct Python implementation in OCaml which added
stuff like regular expression syntax) people judge new languages by
the extent of the differences to Python and on their perception of the
value of such differences. For example, I'm still unimpressed by the
eager introduction of type declarations in such new languages when we
already have things like Pyrex which provide similar capabilities, and
when I think that there's a certain amount of investigation to be done
to determine whether such things are really worthwhile, given the
potential impact of people writing "value as int" all over the place.

I also think that in order to achieve certain objectives many new
languages make the mistake of adding new syntax rather than
principally removing confusing stuff from Python. It should be more
about "Python 300" than "Python 3", in my opinion.

Paul

[*] Yes, Mono is Free Software, but no-one has really addressed the
Microsoft patent issues other than just giving people the brush-off
and telling them not to worry about it. I don't think the Microsoft-
Novell agreement did much to make people feel any better about this.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Nicola Musatti]

On Feb 22, 12:09 pm, Paul Rubin  wrote:
> Nicola Musatti <[EMAIL PROTECTED]> writes:
> > The real point about garbage collection is that it's about the only
> > way to ensure that an object of one type is never taken to be of
> > another type, e.g. by keeping around pointers to the object that
> > occupied its memory before it was reallocated. I believe that this
> > degree of type safety is worth having, which is why I favour the
> > addition of optional GC to C++.
>
> But in C++, garbage collection makes no such guarantee.  Think of
> out-of-range subscripts.

I'm aware that the guarantee would not be perfect. For instance
another source of problems could be holding pointers to local
variables that went out of scope. Yet I'm convinced that even such
partial guarantee is worth having.

Cheers,
Nicola Musatti
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Nicola Musatti]

On Feb 22, 9:03 am, Bruno Desthuilliers  wrote:
> Nicola Musatti a écrit :
[...]
> > 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.

I suspect nobody seriously does, not even in C++ newsgroups ;-)

> > Had we been speaking of productivity... but we weren't, were we?
>
> Should we ?-)

Oh, I'm convinced that Python wins in many contexts, but I believe
that it has more to do with the number of batteries that come with the
package rather than to its being a dynamically typed language. Is this
controversial enough? ;-)

Cheers,
Nicola Musatti

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Paul Rubin]

Nicola Musatti <[EMAIL PROTECTED]> writes:
> The real point about garbage collection is that it's about the only
> way to ensure that an object of one type is never taken to be of
> another type, e.g. by keeping around pointers to the object that
> occupied its memory before it was reallocated. I believe that this
> degree of type safety is worth having, which is why I favour the
> addition of optional GC to C++.

But in C++, garbage collection makes no such guarantee.  Think of
out-of-range subscripts.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Paul Rubin]

Nicola Musatti <[EMAIL PROTECTED]> writes:
> In C++ memory is just another resource which you can handle just like
> any other one, possibly using RAII. 

Ok, I'll bite.  Here's a straightforward Python expression:

   a = [f(x) + g(y) for x,y in izip(m1, m2) if h(x,y).frob() == 7]

Consider how many intermediate objects are being allocated in figuring
out that listcomp.  Do you REALLY want to manage all the deallocation
with something like RAII?  
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Nicola Musatti]

On Feb 22, 1:17 am, Jeff Schwab <[EMAIL PROTECTED]> wrote:
[...]
> 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.

The real point about garbage collection is that it's about the only
way to ensure that an object of one type is never taken to be of
another type, e.g. by keeping around pointers to the object that
occupied its memory before it was reallocated. I believe that this
degree of type safety is worth having, which is why I favour the
addition of optional GC to C++.

Cheers,
Nicola Musatti
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Nicola Musatti]

On Feb 22, 12:24 am, Carl Banks <[EMAIL PROTECTED]> wrote:
> On Feb 21, 1:22 pm, Nicola Musatti <[EMAIL PROTECTED]> wrote:
>
> > 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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Nicola Musatti]

Paul Boddie wrote:
> On 21 Feb, 19:22, Nicola Musatti <[EMAIL PROTECTED]> wrote:
[...]
> > 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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Bruno Desthuilliers]

Jeff Schwab a écrit :
> Bruno Desthuilliers wrote:
>> Carl Banks a écrit :
>>> On Feb 20, 8:58 am, Tim Chase <[EMAIL PROTECTED]> wrote:
> You Used Python to Write WHAT?
> http://www.cio.com/article/185350
 """
 Furthermore, the power and expressivity that Python offers means
 that it may require more skilled developers.
 [...down to the summary...]
 Python may not be an appropriate choice if you:
 [...]
 *  Rely on teams of less-experienced programmers. These
 developers may benefit from the wider availability of training
 for languages like Java and are less likely to make mistakes with
 a compile-time, type-checked language.
 """

>> (snip)
>>>
>>> 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)
> 
> 
> NB:  This is not a troll.  (Please, nobody try to be cute with a "yes it 
> is" reply.)

NB : standard disclaimer about all the following being MVHO.

> c.l.python seem to be about the most close-minded of any of the 
> currently popular language-specific news groups. 

May I suggest you take a tour on c.l.lisp then ?-)

> It's just taken for 
> granted that Perl and C++, two of my personal favorite things in this 
> world, inherently favor ugly, buggy code. 

I wouldn't say so.

It's a fact that C++ is a really complex language with quite a lot of 
room for BigMistakes(tm), and that there's something like a 
'my-code-is-more-cryptic-than-yours' culture in Perl. You cannot 
seriously argue on this.

Now this has nothing to do with the respective merits of both languages 
(FWIW, Perl, as a 'Practical Extracting and Reporting Language', beats 
any other language I know pants down), and I'd be sorry if you were to 
confuse what is mostly on the friendly jokes side with mere bashing. You 
may not have noticed, but quite a lot of people here have a working 
experience with either C++ and/or Perl.

As for my above comment, it doesn't imply anything else than the fact 
that C++ is way harder to learn than Python (or Ruby etc...), and that 
bugs in C++ code are likely to have way more nasty results. The joke is 
not "against" C++, but about people asserting than static type checking 
is safer than dynamic type checking without realizing that what is 
really important is*runtime type checking - something C++ doesn't provide.

NB : As a side note, and while being myself a bit passionated when it 
comes to languages and my job in general, I would not go as far as 
labelling any language or technology as "one of my favorite things in 
this world".

> That is the farthest thing 
> from the truth as I see it.  You can (and plenty of people will) write 
> terrible code in any language, including Python.

Indeed. Bad coders write bad code, period. And I think we've all been 
bad coders one day, and that we're all still bad coders sometimes.

> To use Python effectively, you have to know something about how it 
> works, and the same is true of Perl and C++. 

And of any other language. Now a decent C++ or Perl programmer can be 
proficient in Python in a couple weeks and become a master within a year 
at worst. And it seems that non-professional, occasional programmers 
(hobbyists, gamers, scientists, and any other kind of power user) are 
able to get their job done in Python without much pain.

> But a newbie who's 
> learning from a decent source (avoid the "C++ for Morons" style books) 
> is likely (I contend) to be writing semi-useful programs about as fast 
> as with Python,  and to be writing heavy-duty work-horse programs far
> sooner.

Sorry but I don't buy this.

> Perl is, and always has been, a language for getting your job done; when 
> everything else failed, Perl and C++ got me through some of the toughest 
> tasks of my life.  Translating file formats, automating system-level 
> tasks...  And now that the C++ standard library is getting regular 
> expressions, I can replace plenty of glued-together scripts with 
> single-language, cohesive applications.
> 
> I like Python, and I think it's got a brilliant future ahead of it.  It 
> is rapidly becoming the dynamic language of choice, especially for C++ 
> projects.  I am glad that Python can be extended straightforwardly in 
> any C-linkable language.  But this bashing of other powerful languages 
> on the basis that they're hard to read and hard to use correctly is, 
> frankly, nonsense.

Stating the obvious is not bashing. In my last shop I was working with 
(very talented BTW) Perl programmer, and he was the first to make jokes 
on Perl's abuse of cryptic syntax.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Bruno Desthuilliers]

Nicola Musatti a écrit :
> On Feb 21, 10:55 am, Bruno Desthuilliers  [EMAIL PROTECTED]> wrote:
>> 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 ?-)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Carl Banks]

On Feb 22, 12:23 am, Jeff Schwab <[EMAIL PROTECTED]> wrote:
> Carl Banks wrote:
> > On Feb 21, 7:17 pm, Jeff Schwab <[EMAIL PROTECTED]> wrote:
> >> Carl Banks wrote:
> >>> On Feb 21, 1:22 pm, Nicola Musatti <[EMAIL PROTECTED]> wrote:
>  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 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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Paul Rubin]

George Sakkis <[EMAIL PROTECTED]> writes:
> 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.) ?

I just spent a minute looking at these and both are interesting,
though Cobra looks .NET specific and I'd rather have something that
makes standalone native executables.  Also, I don't see support in
either of these languages for higher-order functions, iterators,
libraries with powerful static datatypes, etc.  Also, no mention of
concurrency.  But, as I said, I only looked for a minute.

There is something called Links that looks interesting for web
programming:

  http://groups.inf.ed.ac.uk/links/

I don't know if it's still being worked on.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Paul Rubin]

Jeff Schwab <[EMAIL PROTECTED]> writes:
> 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".
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[George Sakkis]

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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Jeff Schwab]

Carl Banks wrote:
> On Feb 21, 7:17 pm, Jeff Schwab <[EMAIL PROTECTED]> wrote:
>> Carl Banks wrote:
>>> On Feb 21, 1:22 pm, Nicola Musatti <[EMAIL PROTECTED]> wrote:
 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.

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.  Managing memory is 
just not that difficult, especially if the vast majority of objects are 
allocated on the stack or in static memory.  A special language feature 
for managing dynamically allocated memory robs the programmer of a 
reliable way to clean up resources automatically, without bringing 
anything of particular value to the table.


>> 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%.

That's not how it works.  If I'm going to allocated a C++ object 
dynamically, I have to assign it to some kind of handle, anyway, so I 
might as well just use a smart pointer that will delete the object when 
there are no more references to it.  There is no extra effort involved.

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.  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'

It's graceful, easy to write, and a million times better than having to 
clean up the resource explicitly.  A book on Python I was reading 
recently (either Alex Martelli or Mark Lutz) used this idiom again and 
again, and every time had to have a footnote about how it wouldn't work 
right on (e.g.) JPython, because who knows if/when the resource-owning 
object's finalizer will ever get called.

Admittedly, you have to know enough to use the right kinds of objects, 
but that's something you have to learn anyway.


> YMMV, but I suspect mine is the more common opinion, if the
> recent (like, 10-year) trend in programming languages is any
> indication.

I agree that support for non-deterministic GC has grown very popular 
over the past ten years or so.  I don't think that is evidence of it 
being a good idea though; I suspect that opinion of being the product of 
widespread ignorance about alternatives to unpredictable GC.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Paul Rubin]

Carl Banks <[EMAIL PROTECTED]> writes:
> 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.

Well, sure, but the danger from C++ is precisely that it is untyped
(so you can dereference invalid pointers, etc).  Yes, C++ has a type
system, but it leaks, so the most you can say about it is that it's
better than nothing.  A better example than C++ might have been Ada,
which is in fact designed to be newbie-friendly in the sense that one
of its design criteria is that engineers who are not software
specialists (e.g. jet engine designers) are supposed to not be led
astray when reading it.  I have the impression that Ada programs are
much less likely to crash than C++ programs, unless you set special
compiler flags to make them unsafe (e.g. by disabling subscript
checking).

Yes, good programmers can keep track in their heads what types their
programs are supposed to compute, so Python doesn't stop them too
much, and the dynamicness makes some things easier (e.g. deserializing
arbitrary structures).  But it's the same way with assembly language.
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.

I don't think Coq (http://coq.inria.fr) is beginner friendly
enough yet ;-).
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Carl Banks]

On Feb 21, 11:17 am, "Reedick, Andrew" <[EMAIL PROTECTED]> 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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Article of interest: Python pros/cons for the enterprise

[Carl Banks]

On Feb 21, 7:17 pm, Jeff Schwab <[EMAIL PROTECTED]> wrote:
> Carl Banks wrote:
> > On Feb 21, 1:22 pm, Nicola Musatti <[EMAIL PROTECTED]> wrote:
> >> 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
-- 
http://mail.python.org/mailman/listinfo/python-list