Using python as primary language

[Michel Albert]

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]

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.

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]

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.

 

[kyosohma]

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.

For multithreaded apps, the usual recommendation is Parallel Python

http://www.parallelpython.com/

Mike

 

[kyosohma]

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.

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

 

[sjdevnull]

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]

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\)]

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

 

[Chris Mellon]

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.

 

[Michael Bacarella]

A multithreaded application in Python will only use a single CPU

on

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]

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

 

[Chris Mellon]

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)

import new
def f():

.... x = 10
.... def g():
.... return x
.... return 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]

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

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?

 

[Duncan Booth]

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 f(): cell
return f.func_closure[0]
cell = None
<cell at 0x00C5DAB0: empty>

Hmm, looks like there's a bug here:

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

 

[Hrvoje Niksic]

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]

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

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]

Ben Finney a écrit :

(snip)

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

 

[Marc 'BlackJack' Rintsch]

Ben Finney a écrit :

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? =)

Ciao,
Marc 'BlackJack' Rintsch

 

[Martin Vilcans]

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.

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?