This is part of a series examining the strengths and weaknesses of
various scripting languages, with particular attention to enterprise
(read: big company) use.
You Used Python to Write WHAT?
Python is a powerful, easy-to-use scripting language suitable for use
in the enterprise, although it is not right for absolutely every use.
Python expert Martin Aspeli identifies when Python is the right
choice, and when another language might be a better option. http://www.cio.com/article/185350
Feb 20 '08
62  2920 
Nicola Musatti wrote:
The real sad thing is that nobody is likely to convince Guido to turn
CPython into C++Python ;-)
How difficult would that be? Could it be done in stages? I would be
willing to spend some time on that kind of project. Since I know almost
nothing about Python internals, though, I'd appreciate it if a
C++-fluent Python expert could give an estimate in person-months. Also,
what would be the general break-down? Maybe:
(1) Prepare a build environment appropriate for Python, supporting code
in both C and C++. Include unit-test targets, and a mechanism for
module developers to add unit tests to those targets.
(2) Get all the headers C++-clean.
(3) Begin translating one module at a time. Different people could work
on different modules, and add their test-cases to the global target.
One potential problem would be linkage. Would Python-internal C++
modules still have to provide C-linkable APIs, so that they could be
invoked from other parts of Python? A breakdown of module dependencies
would help address this issue, so that it would be clear which parts of
the code-base would be directly affected by translating a given module
to C++.
At the external API level, would it still be important to support
C-style linkage, even if the implementation code isn't written in C? I
don't know whether it's realistic for people embedding Python in non-C++
applications to have to work directly with C++ APIs.
Carl Banks wrote:
On Feb 22, 12:23 am, Jeff Schwab <j...@schwabcen ter.comwrote:
>Carl Banks wrote:
>>On Feb 21, 7:17 pm, Jeff Schwab <j...@schwabcen ter.comwrote:
Carl Banks wrote:
On Feb 21, 1:22 pm, Nicola Musatti <nicola.musa... @gmail.comwrote :
>There are other downsides to garbage collection, as the fact that it
>makes it harder to implement the Resource Acquisition Is
>Initializa tion idiom, due to the lack of deterministic destruction.
That's not a downside: it's at least a wash.
In C++ you manage memory and the language manages resourcewithout bringing
anything of particular value to the table.s. In
>>>>Python you manage resources and the language manages memory.
RAII is merely one way of minimizing complexity. Garbage collection
is another way.
If you've already got a generic, language-supported way to manage
resources (like RAII with deterministic destruction), then why bother
with garbage collection?
Because now you have to manage memory? Did you read my post? You
have to manage one thing or the other.
Yes, I read your post. You seem to be saying there's some kind of
trade-off between automatic management of dynamically allocated memory,
and automated management of other kinds of resources. I don't
understand why you believe that, so I asked.
If you have proper RAII and deterministic destruction, the management is
of resources is consistent, and mostly automated.
If you have garbage collection, the management of memory is
consistent, and mostly automated.
>Managing memory is
just not that difficult,
Managing resources is just not that difficult,
>especially if the vast majority of objects are
allocated on the stack or in static memory.
Especially if the there are fewer resources to manage than there would
have been heap objects....
> A special language feature
for managing dynamically allocated memory robs the programmer of a
reliable way to clean up resources automatically,
A special language feature more managing dynamically allocated robs
the programmer of a reliable way to free memory automatically,
>without bringing
anything of particular value to the table.
without bringing
anything of particular value to the table.
It cuts both ways, chief.
You like managing your own memory, be my guest. But please don't
imply that you're putting forth less effort because of it. You're
just putting forth different effort.
I disagree with you completely. Your points don't make any sense to me
at all. I believe I am putting forth less effort by having a generic
resource-management infrastructure, rather than a memory-specific
language feature -- that's not just an implication, it's my honest belief.
But I guess we'll agree to disagree.
On Feb 22, 2:15 pm, Jeff Schwab <j...@schwabcen ter.comwrote:
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
On Behalf Of Jeff Schwab
When I see this silliness again and again, it really breaks
my heart
If you allow your heart to be broken by others' opinions, you're setting
yourself up for a lot of disappointment IMHO.
I personally used C++ for about 90% of my code for 10 years. During that
time, I was chugging the C++ Kool-Aid so hard I almost peed myself. I still
think that C++ is a beautiful language, but I have also come to think that
starting a program with C++ is a premature optimization.
I think that very few Python programmers today started with Python. Most of
them came to Python for a reason.
Regards,
Ryan Ginstrom
On Feb 23, 6:40 am, Jeff Schwab <j...@schwabcen ter.comwrote:
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
On Feb 23, 11:39 am, Nicola Musatti <Nicola.Musa... @gmail.comwrote :
Paul Rubin wrote:
Nicola Musatti <nicola.musa... @gmail.comwrite s:
> 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::someitera ble<int,int>::i terator 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.finishe d()" 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++.
Jeff Schwab <je**@schwabcen ter.comwrote:
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-
Matthew Woodcraft wrote:
Jeff Schwab <je**@schwabcen ter.comwrote:
>The most traditional, easiest way to open a file in C++ is to use an
fstream object, so the file is guaranteed to be closed when the fstream
goes out of scope.
Out of interest, what is the usual way to manage errors that the
operating system reports when it closes the file?
By default, the fstream object just sets its "failbit," which you can
check manually by calling my_stream.fail( ). If you want anything
particular to take place on failure to close a stream, you either have
to call close manually, or you need a dedicated object whose destructor
will deal with it.
Alternatively, you can tell the fstream ahead of time that you want
exceptions thrown if particular actions fail. There's a convention that
destructors don't ever throw exceptions, though, so it would be unusual
to request an exception when close() fails.
Jeff Schwab <je**@schwabcen ter.comwrites:
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.
Jeff Schwab <je**@schwabcen ter.comwrites:
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. This thread has been closed and replies have been disabled. Please start a new discussion. |
