All I can say is:
SHORTPROGN = os.path.splitext(os.path.split(sys.argv[0])[1])[0]
> From: Georg Mischler <schor...@schorsch.com>
> Subject: Re: [Radiance-dev] Python scripts for Radiance
> Date: March 21, 2016 4:22:47 PM PDT
>
> You're arguing with some of the most syntactitcally complex aspects
> of current programming languages here. (STL?!?)
> In contrast, Pythons syntax was specifically designed to be easy to
> understand and use (there's a lot of research into that).
>
> Maybe you should just invest an hour and play through the tutorial
> https://docs.python.org/3/tutorial/ (also in the downloaded docs)
> Then you may see firsthand that Python is really different from
> all the horrible things you've already seen...
>
> If you can't get your head wrapped around object oriented ideas,
> Python won't force them onto you (other than Java). But if you want
> to use them, they're much simpler to implement in Python.
>
> Python is "the language that doesn't get in the way".
>
> -schorsch
>
>
> Am 2016-03-21 22:55, schrieb Gregory J. Ward:
>> Hmmm... Well, I may be a little thicker with respect to learning new
>> languages than you give me credit for. Lately, I've been trying to
>> pick up Java for one of my client projects and having a lot of
>> trouble, despite (or because of?) its passing similarity to C++. Perl
>> is relatively easy for me precisely because it doesn't have all the
>> object-oriented stuff or extensive libraries. I always avoided the
>> C++ STL because I never could understand what they wanted me to do
>> with it. It's less a matter of language philosophy and more a matter
>> of how much vocabulary/syntax one needs to master, because my mental
>> capacity for "miscellaneous stuff" is severely limited. I never could
>> get the hang of foreign languages because I can't remember vocabulary.
>> So, I stick by my preference not to rewrite all the existing Perl
>> scripts as Python, except in cases where I am not needed for their
>> future maintenance. I understand that it is important to move away
>> from C-shell, and that's fine. Unfortunately, my ability to fix
>> anything more than the way the Radiance tools get called in Python is
>> currently zero, and looking at your new scripts, I don't see that
>> changing anytime soon.
>> Also, I wish I had some test cases for these scripts, but I was never
>> really good about that. I generally wrote something when I needed it
>> or had an example ready, but I didn't have the foresight to keep those
>> examples around, so I'm not much help there. Sorry!
>> -Greg
>>> From: Georg Mischler <schor...@schorsch.com>
>>> Subject: Re: [Radiance-dev] Python scripts for Radiance
>>> Date: March 21, 2016 2:21:12 PM PDT
>>> Greg, someone of your capacity will be fluent in the Python syntax within
>>> an hour, the object and exception system in a day, and the most elementary
>>> parts of the library within a few days (the included library is so huge
>>> that even experienced pythonistas will keep searching the documentation
>>> for more arcane modules).
>>> Python is "the language thet doesn't get in the way", and not another Perl.
>>> You will very quickly have less problems debugging a Python program by
>>> someone else, compared to a Perl program you have written yourself.
>>> While I definitively understand your reluctance, I also think that in this
>>> specific case you will find it to be unjustified.
>>> And if you should still run into trouble, there are enough Radiance users
>>> out there who are already very fluent and can help out.
>>> So now we need a few more good conversion candidates with test cases.
>>> Do you by chance still have any of the test cases you used to verify
>>> the existing scripts when you created them?
>>> -schorsch
>>> Am 2016-03-21 20:44, schrieb Gregory J. Ward:
>>>> There is the downside that I don't know Python at all, and learning
>>>> yet another object-oriented language with completely different syntax
>>>> isn't high on my list of priorities. That said, if we can get past
>>>> the support issues on various platforms, I have no problem with
>>>> Schorsch and others making contributions they wish to support on an
>>>> ongoing basis, or ones that are unlikely to require support.
>>>> For this reason, I don't have much enthusiasm for converting something
>>>> as complex as genBSDF to Python, where I couldn't understand or fix
>>>> any problems that arise in future.
>>>> Cheers,
>>>> -Greg
>>>>> From: Georg Mischler <schor...@schorsch.com>
>>>>> Subject: [Radiance-dev] Python scripts for Radiance
>>>>> Date: March 21, 2016 9:02:03 AM PDT
>>>>> Hi again!
>>>>> I have converted some of the original Radiance shell scripts into Python.
>>>>> https://github.com/gmischler/PyRad
>>>>> The examples so far are exact drop-in replacements of the original csh
>>>>> or Perl versions, but with some extra functionality and benefits.
>>>>> * usage instructions (-H)
>>>>> * progress report (-V)
>>>>> * dry-run mode (-N)
>>>>> * detailed error diagnostics
>>>>> * compatible with Python 2.7 and Python 3.x
>>>>> * self contained (all functionality can be combined in one file)
>>>>> * truly cross-platform (no dependencies other than Python and Radiance)
>>>>> * direct process management (no intermediate shell calls)
>>>>> * immune to whitespace in file names
>>>>> * tamper-proof use of temporary files
>>>>> * instrumented for building a single-file *.exe with pyinstaller
>>>>> The current selection is still small, the examples were chosen for
>>>>> varying reasons:
>>>>> * falsecolor.py
>>>>> This one has been sitting on my disk (in much less refined form) for
>>>>> many years. Now I've updated it to using color palettes and to satisfy
>>>>> all the points above.
>>>>> * phisto.py
>>>>> * rlux.py
>>>>> * pveil.py
>>>>> Those three became test candidates because they are simple and have
>>>>> a straightforward command line.
>>>>> I'm looking for ideas (and contributions) on where to continue next.
>>>>> Good candidates are scripts that are commonly used.
>>>>> It is also very helpful if a script includes documentation about what
>>>>> it's actually supposed to do. Ideally with a set of test data to
>>>>> verify that it really does that.
>>>>> Actually, a solid set of test cases for the current collection would
>>>>> be very helpful too.
>>>>> Some of the csh/Perl scripts present a challenge, because they have
>>>>> rather unconventional command lines. In those cases, we might want to
>>>>> consider changing the interface to something more regular, provided
>>>>> this is possible.
>>>>> Not all of the existing scripts are really worth the effort.
>>>>> The Python versions with the extra functionality are definitively not
>>>>> as simple as the originals. Flexibility and safety has its price.
>>>>> On the other hand, they will definitively be *much* easier to maintain.
>>>>> Many of the current scripts (csh *and* Perl) blindly assume the
>>>>> existence of a unix type shell, a number of other posix tools
>>>>> (grep/awk/sed/etc.), and they often fail with spaces in file and
>>>>> directory names. Fixing this would introduce additional overhead
>>>>> in any language.
>>>>> Why Python?
>>>>> For developers, it is simply one of the most productive tools around.
>>>>> Python has grown into one of the most popular languages just by its
>>>>> practical merits, without any corporate backing, and without a very
>>>>> strong web appeal.
>>>>> Most Radiance users will already have it installed, no matter the
>>>>> platform.
>>>>> On unix, scripts can be invoked by "#!" (like any other).
>>>>> Any script can be "compiled" into a standalone executable file.
>>>>> This is important on Windows, because invoking scripts (Python,
>>>>> *.bat, or otherwise) from within programs is a real hassle there.
>>>>> In fact, it ended up being the simplest way to get winimage to
>>>>> perform falsecolor analysis.
>>>>> (This could also be done with Perl, but...)
>>>>> I expect Python to play an increasing role in Radiance development in
>>>>> the future, with or without my own involvement. So we might just as
>>>>> well embrace it.
>>>>> I would like to suggest adding Python versions of the most commonly
>>>>> used scripts to the distribution. There are several possible
>>>>> configurations how this could be done, so we'd have to discuss a
>>>>> number of technical details first. And yes, verification before
>>>>> inclusion would be an important step.
>>>>> Opinions?
>>>>> -schorsch
_______________________________________________
Radiance-dev mailing list
Radiance-dev@radiance-online.org
http://www.radiance-online.org/mailman/listinfo/radiance-dev
