Using python as primary language

8 views
Skip to first unread message

Michel Albert

unread,
Nov 8, 2007, 2:52:34 AM11/8/07
to
In our company we are looking for one language to be used as default
language. So far Python looks like a good choice (slacking behind
Java). A few requirements that the language should be able cope with
are:

* Database access to Sybase.
This seems to be available for python, but the windows-binaries for
the library
are not available. Self-Compiling them proved to be non-trivial (As
always
on windows).
* Easy GUI creation.
Solved using PyQt.
* Cross Platform (Linux + Windows).
Again, PyQt, solves this
* Easy deployment.
Solved using py2exe + innosetup
* Charting (Histograms, Line charts, bar charts, pie charts, ...)
I am currently looking into PyQwt, which looks promising.
* Report generation with GUI support
reportlab + rml?

So far, nearly all point seems to be manageable. But I was not yet
able to find a solution for the report generation. What we would like
to have is a sort of GUI interface to prepare the reports without
having to "code" the positioning. I found reportlab, and it looks like
it can do all that is needed in terms of output. But you still have to
code the report. And this is a no go. In context, I found RML and saw
links to graphical RML editors. But I have not yet found a concrete
example code, or documentation. What am I missing? Is RML a reportlab
creation or is it a recognised open standard? If not, is there an open
standard, that is easily to process with python?

Any pointers? I would prefer coding Python to coding Java or
worse..... VB ;) which is another contender in our roundup.

Jens

unread,
Nov 8, 2007, 7:41:33 AM11/8/07
to

I've been using Java since 1998, and Python for just about a year.
I've tried to do an objective analysis of the two languages. Both
languages have good and weak points, but personally I'd choose Python.
In the end, its a matter of personal taste and preferences. They're
both good languages. Try them both and see which one you like. Also,
try to write a wishlist for what you'd like in a language, and then
compare the wishlist to Java and Python.

About graphing - you should really try the NumPy/Matplotlib
combination. Works similar to MatLab.

About VB - I've coded a lot of VB. It is a very easy language to start
out with and it's based on .NET. Again, it depends on your needs, but
make that wishlist and compare with Java and Python.

Good luck!

Michael Bacarella

unread,
Nov 8, 2007, 2:09:54 PM11/8/07
to pytho...@python.org
> In our company we are looking for one language to be used as default
> language. So far Python looks like a good choice (slacking behind
> Java). A few requirements that the language should be able cope with
> are:

How do you feel about multithreading support?

A multithreaded application in Python will only use a single CPU on
multi-CPU machines due to big interpreter lock, whereas the "right thing"
happens in Java.

This can be worked around with fork() and shared memory but it certainly
surprised us to learn this.

kyos...@gmail.com

unread,
Nov 8, 2007, 2:49:23 PM11/8/07
to

For multithreaded apps, the usual recommendation is Parallel Python

http://www.parallelpython.com/

Mike

kyos...@gmail.com

unread,
Nov 8, 2007, 2:55:27 PM11/8/07
to

It looks like RML (Reportlab Markup Language) is a type of XML to me.
It also appears to be a ReportLab invention. Lots of code examples can
be found here:

http://developer.reportlab.com/examples.html

See also: http://www.reportlab.com/rml_index.html

I'm not sure what you mean by "editing" a report. I have an
application that allows users to enter data into a GUI and then it
takes their data and inputs it into a ReportLab generated PDF.

Mike

sjde...@yahoo.com

unread,
Nov 8, 2007, 5:30:05 PM11/8/07
to
On Nov 8, 2:09 pm, "Michael Bacarella" <m...@gpshopper.com> wrote:
> > In our company we are looking for one language to be used as default
> > language. So far Python looks like a good choice (slacking behind
> > Java). A few requirements that the language should be able cope with
> > are:
>
> How do you feel about multithreading support?
>
> A multithreaded application in Python will only use a single CPU on
> multi-CPU machines due to big interpreter lock, whereas the "right thing"
> happens in Java.

Note that this is untrue for many common uses of threading (e.g. using
threads to wait on network connections, or calling out to most common
compute-intensive C extensions), where the GIL is released and
multiple CPUs are used just fine.

Michael Bacarella

unread,
Nov 8, 2007, 6:22:53 PM11/8/07
to pytho...@python.org

> > How do you feel about multithreading support?
> >
> > A multithreaded application in Python will only use a single CPU on
> > multi-CPU machines due to big interpreter lock, whereas the "right
> thing"
> > happens in Java.
>
> Note that this is untrue for many common uses of threading (e.g. using
> threads to wait on network connections, or calling out to most common
> compute-intensive C extensions), where the GIL is released and
> multiple CPUs are used just fine.

It's true in exactly the case where you would gain the most benefit
from multiple CPUs. So I'm not sure how uncommon that is.


Prepscius, Colin (IT)

unread,
Nov 8, 2007, 6:30:15 PM11/8/07
to pytho...@python.org
The last argument to new.function takes a closure, which is a tuple of
cell objects. Does anybody know how to create those cell objects 'by
hand'?

Thanks!
Colin
--------------------------------------------------------

NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.

Chris Mellon

unread,
Nov 8, 2007, 6:38:27 PM11/8/07
to pytho...@python.org
On Nov 8, 2007 5:22 PM, Michael Bacarella <mb...@gpshopper.com> wrote:
>
> > > How do you feel about multithreading support?
> > >
> > > A multithreaded application in Python will only use a single CPU on
> > > multi-CPU machines due to big interpreter lock, whereas the "right
> > thing"
> > > happens in Java.
> >
> > Note that this is untrue for many common uses of threading (e.g. using
> > threads to wait on network connections, or calling out to most common
> > compute-intensive C extensions), where the GIL is released and
> > multiple CPUs are used just fine.
>
> It's true in exactly the case where you would gain the most benefit
> from multiple CPUs. So I'm not sure how uncommon that is.
>

It's pretty uncommon. There are relatively few CPU bound tasks that
are a) highly parallel and b) can't be easily scaled between
processes. Python is not (by itself) an especially good tool for those
tasks.

I find that, by far, the most common use of threads (especially in
Java applications) has more to do with the designers lack of knowledge
of other concurrency models than any particular benefit of the
threading model.

Python is excellently suited to be the "primary language" for pretty
much any company because of its flexibility and (especially) it's
willingness to play nicely with other languages and environments. It
isn't well suited to being the *only* language used, and I would argue
that no language is - lots of companies to try to treat C#/.NET or
Java as the One True Language and suffer for it in stagnant, expensive
development, cumbersome library use, and lack of flexibility.

Jean-Paul Calderone

unread,
Nov 8, 2007, 7:08:20 PM11/8/07
to pytho...@python.org
On Thu, 8 Nov 2007 18:30:15 -0500, "Prepscius, Colin \(IT\)" <colin.p...@morganstanley.com> wrote:
>The last argument to new.function takes a closure, which is a tuple of
>cell objects. Does anybody know how to create those cell objects 'by
>hand'?

Here's one approach:

>>> def f():
... x = 10
... def g():
... a = x
... return g
...
>>> f().func_closure
(<cell at 0xb7d47494: int object at 0x8141d44>,)
>>>

I don't know what your use-case is, so I have no idea if this is the
kind of solution you're looking for.

Jean-Paul

Michael Bacarella

unread,
Nov 8, 2007, 7:05:26 PM11/8/07
to pytho...@python.org
> > > > A multithreaded application in Python will only use a single CPU
> on
> > > > multi-CPU machines due to big interpreter lock, whereas the
> "right
> > > thing"
> > > > happens in Java.
> > >
> > > Note that this is untrue for many common uses of threading (e.g.
> using
> > > threads to wait on network connections, or calling out to most
> common
> > > compute-intensive C extensions), where the GIL is released and
> > > multiple CPUs are used just fine.
> >
> > It's true in exactly the case where you would gain the most benefit
> > from multiple CPUs. So I'm not sure how uncommon that is.
>
> It's pretty uncommon. There are relatively few CPU bound tasks that
> are a) highly parallel and b) can't be easily scaled between
> processes. Python is not (by itself) an especially good tool for those
> tasks.

Is there any reason for this besides economics?

I only assumed this because Perl threads can tax multiple CPUs.

Ben Finney

unread,
Nov 8, 2007, 7:15:02 PM11/8/07
to
"Prepscius, Colin (IT)" <Colin.P...@morganstanley.com> writes:

> NOTICE: If received in error,

If I've received it, it's not "received in error", it's received
successfully.

If, instead, you're referring to the actual recipient being different
from the intended recipient, why are you putting this judgement onto
the actual recipient? Surely they're in no position to judge the
intentions of the sender.

> please destroy and notify sender.

(Insert humour regarding different parsings of the grammar in the
above.)

In that order? If I'm supposed to notify the sender, I have to
re-transmit the message or at least part of it. That seems quite the
opposite of destroying it.

> Sender does not intend to waive confidentiality or privilege.

Then perhaps sender should not be posting to a public forum. There is
*no* confidentiality or privilege in postings to this forum, so this
disclaimer is null and void.

> Use of this email is prohibited when received in error.

There's no way for a recipient to know whether they're in such a
"prohibited" zone. Don't make such threatening statements to an entire
community, please.


In general:

Please, don't attach these disclaimers and threats to messages —
*especially* on a public forum. If you're choosing to apply them to
your messages, please stop.

If, on the other hand, your organisation is applying them
indiscriminately to every outgoing message, even in cases where
there's no such thing as "confidentiality" or "privilege", then
they're mindlessly undermining the meaning of those terms. Please get
your organisation to *only* apply these threats and disclaimers where
they have meaning.

<URL:http://www.goldmark.org/jeff/stupid-disclaimers/>

--
\ "Earth gets its price for what Earth gives us." -- James |
`\ Russell Lowell |
_o__) |
Ben Finney

Chris Mellon

unread,
Nov 8, 2007, 7:17:29 PM11/8/07
to Prepscius, Colin (IT), pytho...@python.org
On Nov 8, 2007 5:30 PM, Prepscius, Colin (IT)

<Colin.P...@morganstanley.com> wrote:
> The last argument to new.function takes a closure, which is a tuple of
> cell objects. Does anybody know how to create those cell objects 'by
> hand'?
>

Beyond copying them from an existing closure, you'll have to use the C
API to create the new cell objects:

>>> pc = ctypes.pythonapi.PyCell_New
>>> pc.restype = ctypes.py_object
>>> pc.argtypes = [ctypes.py_object]
>>> pc(100)
<cell at 0x01B8D970: int object at 0x00946044>
>>> import new


>>> def f():
... x = 10
... def g():

... return x


... return g
...
>>> f()

<function g at 0x01B8CF30>
>>> g = _
>>> new.function(g.func_code, {}, "freeeeee as a bird", None, (pc(100),))
<function freeeeee as a bird at 0x01B941F0>
>>> _()
100
>>> g()
10


I don't really know how safe this is or what sort of refcount or GC
implications creating cell objects on the fly like this might have.

Terry Reedy

unread,
Nov 9, 2007, 12:01:44 AM11/9/07
to pytho...@python.org

"Michael Bacarella" <mb...@gpshopper.com> wrote in message
news:004901c82264$3b10f460$b132dd20$@com...

| > It's pretty uncommon. There are relatively few CPU bound tasks that
| > are a) highly parallel and b) can't be easily scaled between
| > processes. Python is not (by itself) an especially good tool for those
| > tasks.
|
| Is there any reason for this besides economics?

If by 'this' you mean the global interpreter lock, yes, there are good
technical reasons. All attempts so far to remove it have resulted in an
interpeter that is substantially slower on a single processor.

Martin Vilcans

unread,
Nov 9, 2007, 3:40:18 AM11/9/07
to pytho...@python.org
> If by 'this' you mean the global interpreter lock, yes, there are good
> technical reasons. All attempts so far to remove it have resulted in an
> interpeter that is substantially slower on a single processor.

Is there any good technical reason that CPython doesn't use the GIL on
single CPU systems and other locking mechanisms on multi-CPU systems?
It could be selected at startup with a switch, couldn't it?

--
mar...@librador.com
http://www.librador.com

Duncan Booth

unread,
Nov 9, 2007, 3:49:29 AM11/9/07
to
"Prepscius, Colin \(IT\)" <Colin.P...@morganstanley.com> wrote:

> The last argument to new.function takes a closure, which is a tuple of
> cell objects. Does anybody know how to create those cell objects 'by
> hand'?
>

>>> def newcell():
def f(): cell
return f.func_closure[0]
cell = None

>>> newcell()
<cell at 0x00C5DAB0: empty>

Hmm, looks like there's a bug here:

>>> cell.cell_contents

Traceback (most recent call last):
File "<pyshell#15>", line 1, in <module>
cell.cell_contents
SystemError: error return without exception set
>>>

Hrvoje Niksic

unread,
Nov 9, 2007, 4:37:15 AM11/9/07
to
"Martin Vilcans" <mar...@librador.com> writes:

>> If by 'this' you mean the global interpreter lock, yes, there are good
>> technical reasons. All attempts so far to remove it have resulted in an
>> interpeter that is substantially slower on a single processor.
>
> Is there any good technical reason that CPython doesn't use the GIL
> on single CPU systems and other locking mechanisms on multi-CPU
> systems?

It's not the locking mechanism itself that is slow, what's slow is the
Python you get when you remove it. By removing the GIL you grant
different threads concurrent access to a number of shared resources.
Removing the global lock requires protecting those shared resources
with a large number of smaller locks. Suddenly each incref and decref
(at the C level) must acquire a lock, every dict operation must be
locked (dicts are used to implement namespaces and in many other
places), every access to a global (module) variable must be locked, a
number of optimizations that involve using global objects must be
removed, and so on. Each of those changes would slow down Python;
combined, they grind it to a halt.

Michel Albert

unread,
Nov 9, 2007, 5:32:33 AM11/9/07
to

What I meant was that one should be able to "draw" a report template.
Basically a graphical user interface for RML in this case. I
personally would opt for writing RML or whatever code myself. But it's
impossible to convice my boss. The dialog usually goes like this:

"So, did you find a click-and-play editor for reports" - "Not yet, but
anyway, writing code is more flexible and easier to manage later on" -
"Hmmm... but it's code!" - "Sure, but you only write it once for one
report, you can easily re-use code-snippets, modifying the code does
not require one additional program, you just use your text-editor of
choice,..." - "Okay,.... but it's CODE!"....

and this goes on forever. My boss seems to be allergic to writing code
by hand. Which is very frustrating. I'm happy that Qt has the
"designer", although it's very easy to code the GUI's too ;)

Bruno Desthuilliers

unread,
Nov 9, 2007, 6:58:46 AM11/9/07
to
Ben Finney a écrit :

> "Prepscius, Colin (IT)" <Colin.P...@morganstanley.com> writes:
>
(snip)

>> please destroy and notify sender.

Does that mean I should first destroy the sender ? And if so, how could
I *then* notify her ?-)

Marc 'BlackJack' Rintsch

unread,
Nov 9, 2007, 7:14:33 AM11/9/07
to
On Fri, 09 Nov 2007 12:58:46 +0100, Bruno Desthuilliers wrote:

> Ben Finney a écrit :
>> "Prepscius, Colin (IT)" <Colin.P...@morganstanley.com> writes:
>>
> (snip)
>>> please destroy and notify sender.
>
> Does that mean I should first destroy the sender ? And if so, how could
> I *then* notify her ?-)

Ask a medium? Use a crystal ball for the very long distance call? Call
Dr. Frankenstein for help? =:o)

Ciao,
Marc 'BlackJack' Rintsch

Martin Vilcans

unread,
Nov 9, 2007, 10:54:17 AM11/9/07
to pytho...@python.org

But if Python gets slow when you add fine-grained locks, then most
certainly it wouldn't get so slow if the locks were very fast, right?

But that's not what my question was about. It was about whether it
would make sense to, on the same python installation, select between
the GIL and fine-grained locks at startup. Because even if the locks
slows down the interpreter, if they let you utilize a 32 core CPU, it
may not be so bad anymore. Or am I missing something?

--
mar...@librador.com
http://www.librador.com

Chris Mellon

unread,
Nov 9, 2007, 11:14:58 AM11/9/07
to pytho...@python.org
On Nov 9, 2007 9:54 AM, Martin Vilcans <mar...@librador.com> wrote:
>
> On Nov 9, 2007 10:37 AM, Hrvoje Niksic <hni...@xemacs.org> wrote:
> But if Python gets slow when you add fine-grained locks, then most
> certainly it wouldn't get so slow if the locks were very fast, right?
>
> But that's not what my question was about. It was about whether it
> would make sense to, on the same python installation, select between
> the GIL and fine-grained locks at startup. Because even if the locks
> slows down the interpreter, if they let you utilize a 32 core CPU, it
> may not be so bad anymore. Or am I missing something?
>

The performance overhead of a runtime swap between fine-grained locks
and the GIL would probably swamp any benefit you gained from having it
be switchable. A compile time switch is more reasonable, but it has
all the other problems of going fine-grained in the first place (it
breaks compatibility with existing extensions, large code size
increase, increased maintenance burden) and it adds the additional
problem that one or other of the modes won't be as heavily tested
(this will start out as the fine-grained mode, of course, which is the
worst case because it's the more complicated and subtly error prone
one). It's really best in the long term to pick one and stick with it.

The heavy use of dicts is one of the problems - they're all over the
place and even if you removed the GIL, a "global dict lock" would give
essentially the same effect. And a per-dict lock means that there will
be a *lot* more locking and unlocking, which means a slower
interpreter.

kyos...@gmail.com

unread,
Nov 9, 2007, 12:11:50 PM11/9/07
to

wxPython has multiple "designers", like Boa and SPE...but as for a way
to "draw a report", I think you're stuck with something like VBA in an
Office application or the "holy grail" of report generators, Crystal
Reports. Personally speaking, I find Crystal to be more difficult to
use than coding it myself. To each their own, I suppose.

Mike

Rhamphoryncus

unread,
Nov 9, 2007, 12:52:34 PM11/9/07
to
On Nov 9, 9:14 am, "Chris Mellon" <arka...@gmail.com> wrote:
> The heavy use of dicts is one of the problems - they're all over the
> place and even if you removed the GIL, a "global dict lock" would give
> essentially the same effect. And a per-dict lock means that there will
> be a *lot* more locking and unlocking, which means a slower
> interpreter.

It's worse than that. Not only are they slower for a single thread,
but when using multiple threads the cores will contend over the cache
lines containing the locks, leaving you yet slower still!

I've starting putting together a site explaining my approach to
solving these problems:

http://code.google.com/p/python-safethread/


--
Adam Olsen, aka Rhamphoryncus

Boris Borcic

unread,
Nov 9, 2007, 1:13:58 PM11/9/07
to
Michel Albert wrote:
>
> What I meant was that one should be able to "draw" a report template.
> Basically a graphical user interface for RML in this case. I
> personally would opt for writing RML or whatever code myself. But it's
> impossible to convice my boss. The dialog usually goes like this:
>
> "So, did you find a click-and-play editor for reports" - "Not yet, but
> anyway, writing code is more flexible and easier to manage later on" -
> "Hmmm... but it's code!" - "Sure, but you only write it once for one
> report, you can easily re-use code-snippets, modifying the code does
> not require one additional program, you just use your text-editor of
> choice,..." - "Okay,.... but it's CODE!"....
>
> and this goes on forever. My boss seems to be allergic to writing code
> by hand. Which is very frustrating. I'm happy that Qt has the
> "designer", although it's very easy to code the GUI's too ;)
>

Probably worth pointing out that a click-and-point editor for reports can't be
both fully mimetic (as a GUI designer may be) and practical.

FWIW OpenOffice 2.3 added something of the sort. The kind of tools I'd expect to
lead me to roadblocks. Now OpenOffice *does* allow scripting with python; but
the couple times I looked into it, the specs&docs on the scripting interface
scared me completly.

Good luck, BB

Terry Reedy

unread,
Nov 9, 2007, 3:45:17 PM11/9/07
to pytho...@python.org

"Martin Vilcans" <mar...@librador.com> wrote in message
news:f782707a0711090754n5e2...@mail.gmail.com...

| But that's not what my question was about. It was about whether it
| would make sense to, on the same python installation, select between
| the GIL and fine-grained locks at startup. Because even if the locks
| slows down the interpreter, if they let you utilize a 32 core CPU, it
| may not be so bad anymore. Or am I missing something?

1. The need for some group to develop and maintain what anounts to a forked
version of CPython.

2. If micro-locked Python ran, say, half as fast, then you can have a lot
of IPC (interprocess communition) overhead and still be faster with
multiple processes rather than multiple threads.

Rhamphoryncus

unread,
Nov 9, 2007, 6:48:26 PM11/9/07
to
On Nov 9, 1:45 pm, "Terry Reedy" <tjre...@udel.edu> wrote:
> "Martin Vilcans" <mar...@librador.com> wrote in message
>
> news:f782707a0711090754n5e2...@mail.gmail.com...
> | But that's not what my question was about. It was about whether it
> | would make sense to, on the same python installation, select between
> | the GIL and fine-grained locks at startup. Because even if the locks
> | slows down the interpreter, if they let you utilize a 32 core CPU, it
> | may not be so bad anymore. Or am I missing something?
>
> 1. The need for some group to develop and maintain what anounts to a forked
> version of CPython.

That's pretty much what I'm doing.


> 2. If micro-locked Python ran, say, half as fast, then you can have a lot
> of IPC (interprocess communition) overhead and still be faster with
> multiple processes rather than multiple threads.

Of course you'd be faster still if you rewrote key portions in C.
That's usually not necessary though, so long as Python gives a roughly
constant overhead compared to C, which in this case would be true so
long as Python scaled up near 100% with the number of cores/threads.

The bigger question is one of usability. We could make a usability/
performance tradeoff if we had more options, and there's a lot that
can give good performance, but at this point they all offer poor to
moderate usability, none having good usability. The crux of the
"multicore crisis" is that lack of good usability.

Waldemar Osuch

unread,
Nov 9, 2007, 10:15:51 PM11/9/07
to
On Nov 8, 12:52 am, Michel Albert <exh...@gmail.com> wrote:
> In our company we are looking for one language to be used as default
> language. So far Python looks like a good choice (slacking behind
> Java). A few requirements that the language should be able cope with
> are:
>
> * Database access to Sybase.
> This seems to be available for python, but the windows-binaries for
> the library
> are not available. Self-Compiling them proved to be non-trivial (As
> always
> on windows).

Consider using ODBC. "mxODBC" as well as "pyodbc" and "ceODBC" could
be
good alternatives.

> * Easy GUI creation.
> Solved using PyQt.
> * Cross Platform (Linux + Windows).
> Again, PyQt, solves this
> * Easy deployment.
> Solved using py2exe + innosetup
> * Charting (Histograms, Line charts, bar charts, pie charts, ...)
> I am currently looking into PyQwt, which looks promising.
> * Report generation with GUI support
> reportlab + rml?
>
> So far, nearly all point seems to be manageable. But I was not yet
> able to find a solution for the report generation. What we would like
> to have is a sort of GUI interface to prepare the reports without
> having to "code" the positioning. I found reportlab, and it looks like
> it can do all that is needed in terms of output. But you still have to
> code the report. And this is a no go. In context, I found RML and saw
> links to graphical RML editors. But I have not yet found a concrete
> example code, or documentation. What am I missing? Is RML a reportlab
> creation or is it a recognised open standard? If not, is there an open
> standard, that is easily to process with python?

I still have to try it but pisa looks very promising:
http://pisa.spirito.de/content/501/pisa3.html
PDF generation using HTML+CSS for layout.
I hope your boss considers HTML acceptable "coding".

>
> Any pointers? I would prefer coding Python to coding Java or
> worse..... VB ;) which is another contender in our roundup.

You mean VB before .Net? You know that Microsoft ended support for
it.
Thanks to that brilliant decision Python is an "official" language at
my place of work.

Martin Vilcans

unread,
Nov 12, 2007, 4:28:02 AM11/12/07
to pytho...@python.org

Certainly. I guess it would be possible to implement GIL-less
threading in Python quite easily if we required the programmer to
synchronize all data access (like the synchronized keyword in Java for
example), but that gets harder to use. Am I right that this is the
problem?

Actually, I would prefer to do parallell programming at a higher
level. If Python can't do efficient threading at low level (such as in
Java or C), then so be it. Perhaps multiple processes with message
passing is the way to go. It just that it seems so... primitive.

--
mar...@librador.com
http://www.librador.com

Hrvoje Niksic

unread,
Nov 12, 2007, 5:01:23 AM11/12/07
to
"Martin Vilcans" <mar...@librador.com> writes:

> But if Python gets slow when you add fine-grained locks, then most
> certainly it wouldn't get so slow if the locks were very fast,
> right?

Given the sheer number of increfs and decrefs happening, they should
be impossibly fast (meaning: nonexistent). Even adding an additional
test to those macros slows down Python, let alone adding a lock.

> But that's not what my question was about. It was about whether it
> would make sense to, on the same python installation, select between
> the GIL and fine-grained locks at startup. Because even if the locks
> slows down the interpreter, if they let you utilize a 32 core CPU,
> it may not be so bad anymore.

Unfortunately the selection must be done at compile time, not at
run-time. Even taking into account the possibility of selection, so
far no one has come up with a set of patches that remove the GIL that
would come close to being accepted.

This is a recent discussion about GIL removal that provides good
reading:
http://mail.python.org/pipermail/python-dev/2007-September/thread.html#74545

Marc 'BlackJack' Rintsch

unread,
Nov 12, 2007, 5:51:36 AM11/12/07
to
On Mon, 12 Nov 2007 10:28:02 +0100, Martin Vilcans wrote:

> Actually, I would prefer to do parallell programming at a higher
> level. If Python can't do efficient threading at low level (such as in
> Java or C), then so be it. Perhaps multiple processes with message
> passing is the way to go. It just that it seems so... primitive.

Well, to me threads seem to be more primitive. You have to be careful
with shared memory accesses and they don't scale so well if you want to go
from single machines to a cluster.

Take a look at XML-RPC or Pyro for higher level communication between
processes.

Ciao,
Marc 'BlackJack' Rintsch

Rhamphoryncus

unread,
Nov 12, 2007, 12:41:17 PM11/12/07
to

What you've got to ask is "what is a message?" Can you define your
own class and use it as a message? Doing so seems very useful. If
you allow that you end up with something like Concurrent Pascal's
monitors (which enforce their boundary, so they lack the memory model
needed by java or C.)

Once you make message passing easy to use you end up with something
that looks very much like threads anyway, just lacking the shared-
state and the resulting memory model.

Russell E. Owen

unread,
Nov 13, 2007, 2:47:35 PM11/13/07
to
In article <1194508354.2...@v3g2000hsg.googlegroups.com>,
Michel Albert <exh...@gmail.com> wrote:

> In our company we are looking for one language to be used as default
> language. So far Python looks like a good choice (slacking behind
> Java). A few requirements that the language should be able cope with
> are:
>
> * Database access to Sybase.
> This seems to be available for python, but the windows-binaries for
> the library
> are not available. Self-Compiling them proved to be non-trivial (As
> always
> on windows).

> * Easy GUI creation.
> Solved using PyQt.
> * Cross Platform (Linux + Windows).
> Again, PyQt, solves this
> * Easy deployment.
> Solved using py2exe + innosetup

How do you deploy python on linux? The only solution I know of is
pyinstaller and I never could get it to work for me on linux (I never
bothered to try on Windows since I already had py2exe doing what I
needed).

In my opinion this is one of Python's few weaknesses compared to Java.
Others that come to mind are:
- Lack of a built-in networking library that works with GUI toolkits
(use Twisted Framework and hope it continues to be supported)
- Lack of a good built-in GUI toolkit (but there are several good
alternatives including Qt)

> * Charting (Histograms, Line charts, bar charts, pie charts, ...)
> I am currently looking into PyQwt, which looks promising.

HippoDraw is very good. I am not familiar with PyQwt so I cannot compare
them.

-- Russell

kyos...@gmail.com

unread,
Nov 13, 2007, 4:39:02 PM11/13/07
to
On Nov 13, 1:47 pm, "Russell E. Owen" <ro...@cesmail.net> wrote:
> In article <1194508354.226023.232...@v3g2000hsg.googlegroups.com>,

> Michel Albert <exh...@gmail.com> wrote:
>
>
>
> > In our company we are looking for one language to be used as default
> > language. So far Python looks like a good choice (slacking behind
> > Java). A few requirements that the language should be able cope with
> > are:
>
> > * Database access to Sybase.
> > This seems to be available for python, but the windows-binaries for
> > the library
> > are not available. Self-Compiling them proved to be non-trivial (As
> > always
> > on windows).
> > * Easy GUI creation.
> > Solved using PyQt.
> > * Cross Platform (Linux + Windows).
> > Again, PyQt, solves this
> > * Easy deployment.
> > Solved using py2exe + innosetup
>
> How do you deploy python on linux? The only solution I know of is
> pyinstaller and I never could get it to work for me on linux (I never
> bothered to try on Windows since I already had py2exe doing what I
> needed).


The wxPython users seem to create RPMs and Debs. (http://
www.wxpython.org/download.php)

You might find these articles interesting as well:

http://docs.python.org/dist/dist.html
http://www.linux.com/feature/118439
http://docs.python.org/dist/creating-rpms.html

>
> In my opinion this is one of Python's few weaknesses compared to Java.
> Others that come to mind are:
> - Lack of a built-in networking library that works with GUI toolkits
> (use Twisted Framework and hope it continues to be supported)
> - Lack of a good built-in GUI toolkit (but there are several good
> alternatives including Qt)
>
> > * Charting (Histograms, Line charts, bar charts, pie charts, ...)
> > I am currently looking into PyQwt, which looks promising.
>


The wxPython user's group mentions charting quite a bit. I think they
use matplotlib among others. You might contact them for suggestions as
well.

Mike

Diez B. Roggisch

unread,
Nov 13, 2007, 7:07:54 PM11/13/07
to
Russell E. Owen schrieb:

> In article <1194508354.2...@v3g2000hsg.googlegroups.com>,
> Michel Albert <exh...@gmail.com> wrote:
>
>> In our company we are looking for one language to be used as default
>> language. So far Python looks like a good choice (slacking behind
>> Java). A few requirements that the language should be able cope with
>> are:
>>
>> * Database access to Sybase.
>> This seems to be available for python, but the windows-binaries for
>> the library
>> are not available. Self-Compiling them proved to be non-trivial (As
>> always
>> on windows).
>> * Easy GUI creation.
>> Solved using PyQt.
>> * Cross Platform (Linux + Windows).
>> Again, PyQt, solves this
>> * Easy deployment.
>> Solved using py2exe + innosetup
>
> How do you deploy python on linux? The only solution I know of is
> pyinstaller and I never could get it to work for me on linux (I never
> bothered to try on Windows since I already had py2exe doing what I
> needed).

Having a running python interpreter under linux is the same effort as
getting a JRE running. Actually due to licensing problems, python
usually just ships whereas java has to be explicitly installed.

From there, deploying using setuptools is easy enough IMHO.

>
> In my opinion this is one of Python's few weaknesses compared to Java.
> Others that come to mind are:
> - Lack of a built-in networking library that works with GUI toolkits
> (use Twisted Framework and hope it continues to be supported)
> - Lack of a good built-in GUI toolkit (but there are several good
> alternatives including Qt)

I'm not sure if you mean both above "compared to Java" - but I won't
call Swing/AWT "good" - eclipse doesn't come with SWT for nothing. And I
simply don't understand the networking that works with GUI toolkits. I'm
aware of some eventloop-unifications twisted does, but I never really
understood the need for that - multi-threading is a problem for GUIs,
not for networking. And queues are your friend.

Diez

sturlamolden

unread,
Nov 14, 2007, 11:46:32 AM11/14/07
to
On 13 Nov, 22:39, kyoso...@gmail.com wrote:

> The wxPython user's group mentions charting quite a bit. I think they
> use matplotlib among others. You might contact them for suggestions as
> well.

Indeed, use NumPy/SciPy and matplotlib if you are using Python for
numerical computing and data visualization. Matplotlib has capabilites
similar to the 2D plotting/charting of Matlab, and gives you beautiful
antialiased graphs. Matplotlib works nicely with wxPython, PyGTK and
tkinter.

NumPy and matplotlib is not in the Python standard library, but I hope
that will change one day.

sturlamolden

unread,
Nov 14, 2007, 12:16:02 PM11/14/07
to
On 8 Nov, 08:52, Michel Albert <exh...@gmail.com> wrote:


> In our company we are looking for one language to be used as default
> language. So far Python looks like a good choice (slacking behind
> Java). A few requirements that the language should be able cope with
> are:
>
> * Database access to Sybase.
> This seems to be available for python, but the windows-binaries for
> the library
> are not available. Self-Compiling them proved to be non-trivial (As
> always
> on windows).
> * Easy GUI creation.
> Solved using PyQt.
> * Cross Platform (Linux + Windows).
> Again, PyQt, solves this
> * Easy deployment.
> Solved using py2exe + innosetup

> * Charting (Histograms, Line charts, bar charts, pie charts, ...)
> I am currently looking into PyQwt, which looks promising.

> * Report generation with GUI support
> reportlab + rml?


These are all library issues, and has nothing to do with the language!

Besides that, if Visual Studio and .NET is what you want, you can
always use IronPython.

sturlamolden

unread,
Nov 14, 2007, 12:25:04 PM11/14/07
to
On 14 Nov, 01:07, "Diez B. Roggisch" <de...@nospam.web.de> wrote:

> I'm not sure if you mean both above "compared to Java" - but I won't
> call Swing/AWT "good" - eclipse doesn't come with SWT for nothing.

Swing vs. SWT is a matter of taste and religion.

The main complaint against Swing was how it looked. That has changed.
Also, Swing was sluggish ong Windows and SWT was sluggish on X11.


> And I
> simply don't understand the networking that works with GUI toolkits. I'm
> aware of some eventloop-unifications twisted does, but I never really
> understood the need for that - multi-threading is a problem for GUIs,
> not for networking. And queues are your friend.

Indeed.

I think the need for these "eventloop unifications" stems from Visual
Basic. VB programmers never learned to use more than one thread, and
they are still struggling to unlearn the bad habits they aquired.

Jean-Paul Calderone

unread,
Nov 16, 2007, 1:09:10 PM11/16/07
to pytho...@python.org
On Wed, 14 Nov 2007 09:25:04 -0800, sturlamolden <sturla...@yahoo.no> wrote:
> [snip]

>I think the need for these "eventloop unifications" stems from Visual
>Basic. VB programmers never learned to use more than one thread, and
>they are still struggling to unlearn the bad habits they aquired.
>

+1 QOTW

Jean-Paul

Reply all
Reply to author
Forward
0 new messages