Article of interest: Python pros/cons for the enterprise
estherschindler
various scripting languages, with particular attention to enterprise
(read: big company) use.
You Used Python to Write WHAT?
Python is a powerful, easy-to-use scripting language suitable for use
in the enterprise, although it is not right for absolutely every use.
Python expert Martin Aspeli identifies when Python is the right
choice, and when another language might be a better option.
http://www.cio.com/article/185350
Tim Chase
"""
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.
"""
Oh noes! You might need competent programmers that actually
understand what they're doing!
(they might even have to write testing code to make sure their
code works as intended...it's a good thing that Python includes
unittest and doctest modules in the stock install)
Sigh. Any programmer that can overcome the hurdles of learning
Java or C# can quickly/easily pick up Python as long as they're
willing to unlearn some bad habits.
-tkc
Carl Banks
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.
Carl Banks
TerryP
Thanks for the link, was a nice read.
"Have specialized needs better served by other languages that you already
know. For example, if you want to do a lot of text processing and you have
a basement full of Perl programmers, there's no compelling reason to
switch."
Now that really hits the sweet spot hehe.
The threads topic reminds me of a project I had in mind not so long ago, I
wanted to write it in Ruby because I could get it done in a few hours and
move on to other work but chose not to because I could not find a way
to /100%/ secure some information that had to be both kept classified and
apart of the program for business reasons.
So obviously ANSI C and the hunt for a suitable networking library to fill
in the biggest time waster came to mind.
Then I remembered any one we wanted to *prevent* getting that information
out of the Ruby scripts could do the same with a little (easy) forensics
work if the application was done in C or C++. So choosing a language like
Ruby or Python wouldn't be much worse for the situation.
Needless to say I went back to using languages on a scale of best shoe to
fit first and the project got side-stepped by new hardware and a stop-gap
in a can.
--
The young Georgia miss came to the hospital for a checkup.
"Have you been X-rayed?" asked the doctor.
"Nope," she said, "but ah've been ultraviolated."
Bruno Desthuilliers
> On Feb 20, 8:58 am, Tim Chase <python.l...@tim.thechases.com> 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.
>> """
>>
>
> 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)
Nicola Musatti
42.desthuilli...@wtf.websiteburo.oops.com> 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. 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. So, yes, your big company is
likely to be safer with newbie C++ programmers than with Python newbie
programmers.
Had we been speaking of productivity... but we weren't, were we?
Cheers,
Nicola Musatti
Ryan Ginstrom
> Newbies learn, and the fundamental C++ lessons are usually
> learnt quite easily. 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. So, yes, your big company is likely to be safer
> with newbie C++ programmers than with Python newbie programmers.
The danger of memory leaks alone makes C++ a decidedly newbie-unfriendly
language. Java I might go along with, but C++?
Regards,
Ryan Ginstrom
(who learned C++ before Python and has grappled with his share of memory
bugs)
Tim Chase
> learnt quite easily.
Ah yes...that would be why Scott Meyers has written three
volumes[1] cataloging the gotchas that even experienced C++
programmers can make...
And the 1030 page Stroustrup C++ reference is easily comprehended
by the uninitiated[2]. The Python core language is a mere 97
pgs. The documentation for the *entire* standard library is
about the size of just the C++ Language Reference.[3]
Assembly language is pretty easy to learn too. But is it a
productive use of a programmer's time? Only if it's 1975.
-tkc
[1]
http://www.amazon.com/s?url=search-alias%3Daps&field-keywords=scott%20meyers
Nicola Musatti
On Thu, Feb 21, 2008 at 4:00 PM, Tim Chase
<pytho...@tim.thechases.com> wrote:
[...]
--
Nicola.Musatti <at> gmail <dot> com
Home: http://nicola.musatti.googlepages.com/home
Blog: http://wthwdik.wordpress.com/
Nicola Musatti
> > On Behalf Of Nicola Musatti
> > Newbies learn, and the fundamental C++ lessons are usually
> > learnt quite easily. 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. So, yes, your big company is likely to be safer
> > with newbie C++ programmers than with Python newbie programmers.
>
> The danger of memory leaks alone makes C++ a decidedly newbie-unfriendly
> language. Java I might go along with, but C++?
Memory *leaks* are just as common in garbage collected languages if
not more, thanks to C++'s deterministic destruction and its standard
library, especially if complemented with smart pointers such as
Boost's shared_ptr. At least C++ programmers tend to know that memory
must be managed, while newbies in other languages are often lead to
believe - wrongly - that the garbage collector takes care of
everything.
Dereferencing invalid pointers however is indeed a more serious
problem. This is the one lesson I had in mind when I wrote my previous
message; newbies that are not hopeless tend to learn it rather quickly
and the number of mistakes of this kind they make tends to fall in a
rather short time. I do admit however that even experienced
programmers make similar errors every now and again.
While attempting to dereference a null reference is a rather common
mistake in languages such as Java and C# - I'm not sure about Python -
the one invaluable guarantee provided by the garbage collector is the
absence of *invalid* references. This is one of the reasons why
there's an ongoing effort to add garbage collection to the C++
standard, albeit in an optional form.
Cheers,
Nicola Musatti
Nicola Musatti
> > Newbies learn, and the fundamental C++ lessons are usually
> > learnt quite easily.
>
> Ah yes...that would be why Scott Meyers has written three
> volumes[1] cataloging the gotchas that even experienced C++
> programmers can make...
Scott Meyers's books don't just catalogue gotcha's, but suggest
effective ways to use the language. Moreover their combined word count
is probably below the "Python Cookbook"'s one.
> And the 1030 page Stroustrup C++ reference is easily comprehended
> by the uninitiated[2]. The Python core language is a mere 97
> pgs. The documentation for the *entire* standard library is
> about the size of just the C++ Language Reference.[3]
A more reasonable comparison would be against the core portion of the C
++ standard. This is still roughly three times the Python Reference
Manual. The C++ syntax is way more complex than Python's and mostly
due to its C heritage is also often inconsistent. However, despite its
apparent semplicity, Python allows extremely advanced programming
techniques. I wouldn't be surprised if the proportion of Python
programmers that are capable of exploiting the language's full power
was comparable to the corresponding proportion of C++ expert
programmers.
While I find the Python standard library documentation adequate for a
free, voluntary effort, I consider it one of the weakest spots of
Python as a professional tool. Still comparing its size against
Stroustrup's book's is really comparing apples with oranges.
> Assembly language is pretty easy to learn too. But is it a
> productive use of a programmer's time? Only if it's 1975.
It depends on the task at hand.
Cheers,
Nicola Musatti
Steve Holden
>> On Behalf Of Nicola Musatti
>> learnt quite easily. 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. So, yes, your big company is likely to be safer
>> with newbie C++ programmers than with Python newbie programmers.
>
> language. Java I might go along with, but C++?
>
> Ryan Ginstrom
> (who learned C++ before Python and has grappled with his share of memory
> bugs)
>
have surrounded Nicola's assertion.
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
Reedick, Andrew
> From: python-list-bounces+jr9445=att...@python.org [mailto:python-
> list-bounces+jr9445=att...@python.org] On Behalf Of Tim Chase
> Sent: Wednesday, February 20, 2008 8:58 AM
> To: estherschindler
> Cc: pytho...@python.org
> Subject: Re: Article of interest: Python pros/cons for the enterprise
>
>
> Oh noes! You might need competent programmers that actually
> understand what they're doing!
>
> (they might even have to write testing code to make sure their
> code works as intended...it's a good thing that Python includes
> unittest and doctest modules in the stock install)
>
> Sigh. Any programmer that can overcome the hurdles of learning
> Java or C# can quickly/easily pick up Python as long as they're
> willing to unlearn some bad habits.
>
> -----Original Message-----
> From: python-list-bounces+jr9445=att...@python.org [mailto:python-
> list-bounces+jr9445=att...@python.org] On Behalf Of Carl Banks
> Sent: Wednesday, February 20, 2008 8:39 PM
> To: pytho...@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
*****
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA625
Nicola Musatti
> Ryan Ginstrom wrote:
> >> On Behalf Of Nicola Musatti
> >> Newbies learn, and the fundamental C++ lessons are usually
> >> learnt quite easily. 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. So, yes, your big company is likely to be safer
> >> with newbie C++ programmers than with Python newbie programmers.
>
> > The danger of memory leaks alone makes C++ a decidedly newbie-unfriendly
> > language. Java I might go along with, but C++?
> I think you can safely assume that an <irony></irony> tag pair should
> have surrounded Nicola's assertion.
To an extent, certainly. As not all companies can afford to hire only
the best, you do have to cater for newbies. The way to do it, however,
is not to provide them with "sandbox" languages [1], but rather to
ensure that they acquire experience as quickly as possible and that
they aren't in a position to do more damage than expert programmers
through their inexperience. To this purpose mentoring, tests and code
inspections appear to me as more effective tools than a garbage
collector.
Still, suppose you were to choose a team of swimmers that had to be
ready for a tough task in a short time; the first time around, would
you push them into the swimming pool with or without a life jacket?
The trouble with C++ is that at times it takes you sooo long to
drown ;-)
Cheers,
Nicola Musatti
[1] I'm not thinking of any specific language, but rather to the
notion that some languages are inherently "safe".
Paul Boddie
>
> While attempting to dereference a null reference is a rather common
> mistake in languages such as Java and C# - I'm not sure about Python -
> the one invaluable guarantee provided by the garbage collector is the
> absence of *invalid* references. This is one of the reasons why
> there's an ongoing effort to add garbage collection to the C++
> standard, albeit in an optional form.
The main reason why C++ has declined in usage is because almost
everything of practical value is optional. Meanwhile, those C++
newbies we were talking about are having to deal with decisions that
everyone else can quite happily ignore, knowing that the right choice
has probably already been made for them, where automatic memory
management is probably the right choice for the biggest decision of
them all, as Java demonstrated quite successfully to the hordes of
enterprise programmers (and their managers) at the end of the 1990s.
Back to those C++ newbies, then. Of course, none of them pushed into a
C++ project is going to have much say about which memory management
"best practice" is going to be used - the decisions are already set in
stone by the project - and so it's all about coping with the tedious
tracking of "who owns which pointer" and hoping that different
libraries don't have different policies. Taking the quotes out of
order...
> At least C++ programmers tend to know that memory
> must be managed, while newbies in other languages are often lead to
> believe - wrongly - that the garbage collector takes care of
> everything.
Sure, there are some issues with memory consumption patterns with
various garbage collectors, but the "it's good for you" attitude has
scant justification unless you're dealing with constrained
environments. And even with people watching the dials in their C++
application, you still get obscene resource misuse, which is why
Firefox eventually consumes over 1GB memory on this desktop. There are
considerably fewer caveats involved with regard to languages with
garbage-collected runtime environments.
I seem to remember that Hans Boehm had some interesting observations
about garbage collection myths, especially around performance, but
since the mindset persists in large tracts of the C++ development
landscape that it must somehow be cheating to use a garbage collector,
I suppose we still have a few more years of applications accessing the
wrong memory locations and showing the usual useless backtrace
dialogues for submission to uninterested developers who insisted on
using C++ because "everything else is slow".
Paul
Jeff Schwab
NB: This is not a troll. (Please, nobody try to be cute with a "yes it
is" reply.)
c.l.python seem to be about the most close-minded of any of the
currently popular language-specific news groups. It's just taken for
granted that Perl and C++, two of my personal favorite things in this
world, inherently favor ugly, buggy code. 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.
To use Python effectively, you have to know something about how it
works, and the same is true of Perl and C++. 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.
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.
Nicola Musatti
[...]
> The main reason why C++ has declined in usage is because almost
> everything of practical value is optional.
The main reason why C++ has declined in usage is because it never got
the kind of corporate marketing enjoyed by Java and C#.
> Meanwhile, those C++
> newbies we were talking about are having to deal with decisions that
> everyone else can quite happily ignore, knowing that the right choice
> has probably already been made for them, where automatic memory
> management is probably the right choice for the biggest decision of
> them all, as Java demonstrated quite successfully to the hordes of
> enterprise programmers (and their managers) at the end of the 1990s.
A choice that is available to C++ programmers too, altough I admit
it's not a common one and does usually require an external library. As
to it being the right choice it's debatable: it took Java something
like ten years to come out with usable GUI applications and, judging
from many articles and postings across the internet memory management
*is* an issue with Java, especially for long running applications.
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.
Other languages, such as Python and C#, are recognizing this fact and
provide the with/using statement, which serves this purpose but is
definitely more clumsy.
> Back to those C++ newbies, then. Of course, none of them pushed into a
> C++ project is going to have much say about which memory management
> "best practice" is going to be used - the decisions are already set in
> stone by the project - and so it's all about coping with the tedious
> tracking of "who owns which pointer" and hoping that different
> libraries don't have different policies. Taking the quotes out of
> order...
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.
> > At least C++ programmers tend to know that memory
> > must be managed, while newbies in other languages are often lead to
> > believe - wrongly - that the garbage collector takes care of
> > everything.
>
> Sure, there are some issues with memory consumption patterns with
> various garbage collectors, but the "it's good for you" attitude has
> scant justification unless you're dealing with constrained
> environments.
It's not just a matter of memory consumption patterns, it's also a
question of explicitly resetting your memory references to ensure that
the GC can reclaim them. This can be less than obvious when complex
data structures and/or callback objects are involved.
> And even with people watching the dials in their C++
> application, you still get obscene resource misuse, which is why
> Firefox eventually consumes over 1GB memory on this desktop. There are
> considerably fewer caveats involved with regard to languages with
> garbage-collected runtime environments.
Unfortunately C++ by itself cannot ensure that only top programmers
use it ;-)
> I seem to remember that Hans Boehm had some interesting observations
> about garbage collection myths, especially around performance, but
> since the mindset persists in large tracts of the C++ development
> landscape that it must somehow be cheating to use a garbage collector,
> I suppose we still have a few more years of applications accessing the
> wrong memory locations and showing the usual useless backtrace
> dialogues for submission to uninterested developers who insisted on
> using C++ because "everything else is slow".
Things change. Boehm himself is working for the inclusion of -
optional - garbage collection in the C++ standard.
Cheers,
Nicola Musatti
Steve Holden
amount of what we might term "defensive push back" against static
language bigots, some of whom come from the C++ camp. You are certainly
right about bad programmers producing bad programs in any language.
As far as C++ goes I usually defer to Alex Martelli, who used it a long
time at IBM and is therefore well able to address its deficiencies. I
believe you are also right in that the defensive posture tends to remain
even after the bigots go away.
For the record, there are many fine systems crafted in a mix of C++ and
Python (EVE Online being a prime example). For any sufficiently large
software system there will always be engineering problems, some of which
are conditioned by choice of language and some by other factors.
> To use Python effectively, you have to know something about how it
> works, and the same is true of Perl and C++. 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.
>
I agree that C++ is a nice language conceptually, and haven't used it
enough to hit the hard problems.
> 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.
>
Yes, Perl has always been a pragmatist's language (and indeed the
author's favored acronym has the P stand for "practical"). I *did* have
to use Perl for quite a while in the early days of the web and so got to
experience its many delights at first hand. Again, you are probably
right in saying we should accept Perl for its efficiencies (I believe
even now it will generally beat Python on regular expression processing)
and stop knocking it for its ill-though-out syntax and clumsy object
implementation.
> 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.
Agreed, mostly. I think Perl *is* hard to read (and frankly have been
amazed at the intentions of the Perl 6 designers), but that shouldn't
stop people using it, and isn't something that needs constant repetition.
Paul Boddie
> On Feb 21, 6:31 pm, Paul Boddie <p...@boddie.org.uk> wrote:
> [...]
>
> > The main reason why C++ has declined in usage is because almost
> > everything of practical value is optional.
>
> 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.
[...]
> > Back to those C++ newbies, then. Of course, none of them pushed into a
> > C++ project is going to have much say about which memory management
> > "best practice" is going to be used - the decisions are already set in
> > stone by the project - and so it's all about coping with the tedious
> > tracking of "who owns which pointer" and hoping that different
> > libraries don't have different policies. Taking the quotes out of
> > order...
>
> 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.
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.
[...]
> It's not just a matter of memory consumption patterns, it's also a
> question of explicitly resetting your memory references to ensure that
> the GC can reclaim them. This can be less than obvious when complex
> data structures and/or callback objects are involved.
As I said, the caveats are fewer, but there are caveats involved, yes.
Paul
John Nagle
> On 21 Feb, 19:22, Nicola Musatti <nicola.musa...@gmail.com> wrote:
>> On Feb 21, 6:31 pm, Paul Boddie <p...@boddie.org.uk> wrote:
>> [...]
>>
>>> The main reason why C++ has declined in usage is because almost
>>> everything of practical value is optional.
>> The main reason why C++ has declined in usage is because it never got
>> the kind of corporate marketing enjoyed by Java and C#.
No, the real problem is that C++ is the only major language to
have hiding ("abstraction") without memory safety. C has neither hiding
nor safety. Python, Java, Modula 3, Delphi, Ruby, C#, and Ada have hiding
with safety. Javascript, Perl, and LISP have safety without hiding. C++
stands alone as having hiding without safety, the least safe possibility.
The safety problems with C++ could be fixed, but the C++ committee
is off in template la-la land, ignoring safety issues in favor of
cute template features no one will use in production code.
This has nothing to do with language efficiency or whether the
language is interpreted. Of the languages listed with both hiding
and safety, Ada and Modula 3 are always compiled to hard machine code,
and Java can be. (GCC offers that option.)
John Nagle
Carl Banks
> There are other downsides to garbage collection, as the fact that it
> makes it harder to implement the Resource Acquisition Is
> Initialization idiom, due to the lack of deterministic destruction.
That's not a downside: it's at least a wash.
In C++ you manage memory and the language manages resources. In
Python you manage resources and the language manages memory.
RAII is merely one way of minimizing complexity. Garbage collection
is another way.
Carl Banks
Jeff Schwab
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.
Paul Rubin
> This has nothing to do with language efficiency or whether the
> language is interpreted. Of the languages listed with both hiding
> and safety, Ada and Modula 3 are always compiled to hard machine code,
> and Java can be. (GCC offers that option.)
But Java still takes a big performance hit because of method-call
overhead, unless the compiler does whole-program optimization, if I
understand it right. This is required in order to make sure that
private instance variables are really private against access from
malicious objects running in the same JVM. That really does seem to
me to be a weird and expensive requirement to put into a general
purpose language.
Carl Banks
> Carl Banks wrote:
> > On Feb 21, 1:22 pm, Nicola Musatti <nicola.musa...@gmail.com> 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
Carl Banks
> 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
Paul Rubin
> 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 ;-).
Jeff Schwab
> On Feb 21, 7:17 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
>> Carl Banks wrote:
>>> On Feb 21, 1:22 pm, Nicola Musatti <nicola.musa...@gmail.com> 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.
George Sakkis
> 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
Paul Rubin
> 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".
Paul Rubin
> 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.
Carl Banks
> Carl Banks wrote:
> > On Feb 21, 7:17 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
> >> Carl Banks wrote:
> >>> On Feb 21, 1:22 pm, Nicola Musatti <nicola.musa...@gmail.com> 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.
> 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
Bruno Desthuilliers
> On Feb 21, 10:55 am, Bruno Desthuilliers <bruno.> [...]
>>> 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)
>
> 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 ?-)
Bruno Desthuilliers
> Bruno Desthuilliers wrote:
>> Carl Banks a écrit :
>>> On Feb 20, 8:58 am, Tim Chase <python.l...@tim.thechases.com> 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.
Nicola Musatti
Paul Boddie wrote:
> On 21 Feb, 19:22, Nicola Musatti <nicola.musa...@gmail.com> 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
Nicola Musatti
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
Nicola Musatti
[...]
> 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
Paul Rubin
> 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?
Paul Rubin
> 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.
Nicola Musatti
42.desthuilli...@wtf.websiteburo.oops.com> 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
Nicola Musatti
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
Paul Boddie
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 30000", 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.
Nicola Musatti
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 <iostream>
#include <map>
#include <vector>
int f(int n) { return n * 2; }
int g(int n) { return ( n * 2 ) + 1; }
std::map<int, int> izip(int i, int j) {
std::map<int, int> 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<int> a;
std::map<int, int> m = izip(m1, m2);
for ( std::map<int,int>::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<int>::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
Bruno Desthuilliers
> On Feb 22, 9:03 am, Bruno Desthuilliers <bruno.
> 42.desthuilli...@wtf.websiteburo.oops.com> 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 !-)
Roy Smith
<a88eef80-1b0a-4e09...@71g2000hse.googlegroups.com>,
Nicola Musatti <nicola....@gmail.com> wrote:
> Yet I'm convinced that even such partial guarantee is worth having.
Partial guarantees are like being a little bit pregnant.
Lou Pecora
"Reedick, Andrew" <jr9...@ATT.COM> wrote:
>
> > -----Original Message-----
> > From: python-list-bounces+jr9445=att...@python.org [mailto:python-
> > list-bounces+jr9445=att...@python.org] On Behalf Of Carl Banks
> > Sent: Wednesday, February 20, 2008 8:39 PM
> > To: pytho...@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
Nicola Musatti
> In article
> <a88eef80-1b0a-4e09-ae46-9fa632bc1...@71g2000hse.googlegroups.com>,
> Nicola Musatti <nicola.musa...@gmail.com> 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
Chris Mellon
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.
Marc 'BlackJack' Rintsch
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
Nicola Musatti
> 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 waaaaay 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
Paul Rubin
> > 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.
Paul Rubin
> > 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
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.
Jeff Schwab
> 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.
Jeff Schwab
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.
George Sakkis
> 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
Marc 'BlackJack' Rintsch
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.
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!?
I like C and until I discovered Python, I liked Java. Then I looked at
C++ and find it really ugly and confusing. Even Haskell looks somewhat
easier to me. Someone mentioned D -- that's a good step between C++ and
Java IMHO. Garbage collection plus an easy way to declare "scoped"
variables that are destroyed when the names goes out of scope. So one can
leave memory management most of the time to the runtime but use RAII for
files, locks and other resources. The `main()` of your C++ example looks
like this in D:
void main()
{
auto m1 = 3;
auto m2 = 4;
scope a = new int[0];
scope m = izip(m1, m2);
foreach (int first, int second; m) {
if (h(first, second).frob == 7) {
a ~= [f(first) + g(second)];
}
}
foreach (int i; a) writef("%d\n", i);
}
Ciao,
Marc 'BlackJack' Rintsch
Jeff Schwab
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 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.
OK...
>> 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.
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.
Jeff Schwab
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.
Ryan Ginstrom
> 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
Jeff Schwab
>> 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!
Jeff Schwab
> Jeff Schwab <je...@schwabcenter.com> 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.
Carl Banks
> 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
Nicola Musatti
[...]
> 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 <at> gmail <dot> com
Home: http://nicola.musatti.googlepages.com/home
Blog: http://wthwdik.wordpress.com/
Nicola Musatti
> Nicola Musatti <nicola....@gmail.com> 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.
Jeff Schwab
> On Feb 23, 6:40 am, Jeff Schwab <j...@schwabcenter.com> 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.
Rhamphoryncus
> >>> 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<int> a;
for (std::someiterable<int,int>::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++.
Matthew Woodcraft
> 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-
Jeff Schwab
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.
Matthew Woodcraft
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-
Paul Rubin
> 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.
Paul Rubin
> >>> 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.
Terry Reedy
"Jeff Schwab" <je...@schwabcenter.com> wrote in message
news:f76dnYohFaXb0V3a...@comcast.com...
[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
Paul Rubin
> | 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.
Hrvoje Niksic
> "Jeff Schwab" <je...@schwabcenter.com> wrote in message
> news:f76dnYohFaXb0V3a...@comcast.com...
> [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.
Jeff Schwab
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.
Jeff Schwab
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?
Paul Rubin
> 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.
Paul Rubin
> 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.
Jeff Schwab
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.
Jeff Schwab
> Jeff Schwab <je...@schwabcenter.com> 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.
Jeff Schwab
> Jeff Schwab <je...@schwabcenter.com> 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:
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!"
Paul Rubin
> 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.
Paul Rubin
> > 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.
Jeff Schwab
> Jeff Schwab <je...@schwabcenter.com> 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."
Paul Rubin
> > 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++.
Steven D'Aprano
> 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
Steven D'Aprano
> Paul Rubin wrote:
>> Jeff Schwab <je...@schwabcenter.com> 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
Arnaud Delobelle
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 "<stdin>", line 1, in <module>
File "<stdin>", 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
Matthew Woodcraft
> 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-
Lou Pecora
In article <mailman.1128.1203771...@python.org>,
"Ryan Ginstrom" <soft...@ginstrom.com> 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
Jeff Schwab
> Jeff Schwab <je...@schwabcenter.com> 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?
Lou Pecora
<d7a77bf9-4e9c-42a3...@c33g2000hsd.googlegroups.com>,
Nicola Musatti <nicola....@gmail.com> wrote:
> On Feb 22, 12:07 pm, Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
> > Nicola Musatti <nicola.musa...@gmail.com> 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 <iostream>
> #include <map>
> #include <vector>
[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
Larry Bugbee
> On Feb 21, 6:31 pm, Paul Boddie <p...@boddie.org.uk> 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
Jeff Schwab
> 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.)
Larry Bugbee
> 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
Larry Bugbee
Aahz
Jeff Schwab <je...@schwabcenter.com> 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 (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
"All problems in computer science can be solved by another level of
indirection." --Butler Lampson
Terry Reedy
"Steven D'Aprano" <st...@REMOVE-THIS-cybersource.com.au> wrote in message
news:13s26lu...@corp.supernews.com...
| On Sat, 23 Feb 2008 19:35:30 -0800, Jeff Schwab wrote:
|
| > lambda here, they seem to get a bunch "why are you using lambda?"
| > responses.
I think you are overgeneralizing ;-)
I use 'em.
| Not from me.
|
| I even use "named anonymous functions" *cough* by assigning lambda
| functions to names:
|
| foo = lambda x: x+1
Even though I consider the above to be clearly inferior to
def foo(x): return x+1
since the latter names the function 'foo' instead of the generic
'<lambda>'.
The only other situation in which I would critisize lambda usage are
multi-line (or super-long-line) monstrousities that are not intentionally
'obfuscated Python'.
tjr
Carl Banks
> In article <Y9KdnVYb7bq_m13anZ2dnUVZ_sedn...@comcast.com>,
> Jeff Schwab <j...@schwabcenter.com> 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
Nicola Musatti
> Nicola Musatti <Nicola.Musa...@gmail.com> 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 <typename InIter1T, typename InIter2T,
typename OutIterT, typename FuncT, typename FilterT>
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
Nicola Musatti
> On Feb 21, 10:22 am, Nicola Musatti <nicola.musa...@gmail.com> wrote:
>
> > On Feb 21, 6:31 pm, Paul Boddie <p...@boddie.org.uk> 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