[Radiance-general] Python Radiance Package

[Thomas Bleicher]

Hi Chris.

On Tue, Nov 9, 2010 at 10:33 AM, Christopher Rush
<Christopher.Rush at arup.com> wrote:
> It sounds like what you’re looking to write is an enhanced version of the
> ‘rad’ program with ability to go through multiple geometries or light
> conditions for batch processing and comparison purposes with the additional
> flexibility of file naming that would be required, and maybe automatic
> falsecolor generation or pcond calls, rtrace data processing routines, etc.

We haven't discussed the actual nature of this package yet,
I think. My understanding was that at first it would be only
a wrapper for the Radiance binaries that would provide a
less complicated way of accessing their features from
Python.

Your idea of an enhanced 'rad' is interesting but I don't feel
that this is the main goal here. However, the Python package
should allow anyone inclined to do so to write an enhanced
'rad' without having to deal with all the gritty details of file
handling and process control.

> I think the challenge would be to make it generic enough that it is still
> useful for all the unique scenarios that come up, but at the same time make
> it worth the effort of creating and maintaining this extra interface –
> instead of the current M.O. of any user putting to use whichever shell or
> scripting package they’re most comforable with.

For a start it should be very 'generic' because it only exposes
the Radiance features on a Python level. I doubt that we
can achieve all the flexibility of Radiance on a Unix shell
because that's what all the binaries are designed for. But
within a Python script you can achieve the same results
with a few more Python commands. In most cases this
will also improve the readability of the script.

> There is a danger that it makes it makes Python expertise
> necessary to keep up to date with the most current
> developments, and be able customize as needed.

Knowledge of Python will definitely be required. It's a
Python module after all. However, all of those who have
shown an interest in the project already have done some
programming in Python and I expect that we have a fair
amount of duplicated features in our common code base.

If nothing else this project could help the known Python
enthusiasts to share parts of their code.

> Although maybe there’s something to be said for moving
> toward a common cross-platform scripting language
> amongst the community.

Unfortunately even within the official distribution there
is already quite a spread of scripting languages:
Python/CSH for building
CSH for some scripts
Perl for other scripts
TCL/Tk for trad

I expect that it will always be true that on Unix you are
spoiled for choice of scripting environments and on Windows
most users rely on a graphical frontend like Ecotect.

> PS, I write this from the perspective of someone using bash and unix
> commands and who has (very briefly) looked into Python several times, but
> could never figure out why I would want to re-write the bash shell commands
> I’m already familiar with into Python with all the same information just
> within parantheses and with the word “subprocess” before it  = )

That's because you haven't discovered the beauty of
Python OO code yet. I agree that there is little benefit
in rewriting shell scripts in Python unless you do
something more with it (or you are not that familiar
with CSH/Bash programming).

Python has it's strength where you extend the basic
Radiance tools to a more complex application. That
could be an image manipulation app that combines
the various p-something tools or a script that automats
rendering and analysis of a scene with variations.

Thomas