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! -GregFrom: Georg Mischler <schor...@schorsch.com> Subject: Re: [Radiance-dev] Python scripts for Radiance Date: March 21, 2016 2:21:12 PM PDTGreg, 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 documentationfor 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 thisspecific case you will find it to be unjustified.And if you should still run into trouble, there are enough Radiance usersout 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 somethingas complex as genBSDF to Python, where I couldn't understand or fix any problems that arise in future. Cheers, -GregFrom: 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/PyRadThe examples so far are exact drop-in replacements of the original cshor 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) formany years. Now I've updated it to using color palettes and to satisfyall 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 whatit'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 haverather unconventional command lines. In those cases, we might want toconsider 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 notas 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 inthe 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--Georg Mischler -- simulations developer -- schorsch at schorsch com +schorsch.com+ -- lighting design tools -- http://www.schorsch.com/_______________________________________________ Radiance-dev mailing list Radiance-dev@radiance-online.org http://www.radiance-online.org/mailman/listinfo/radiance-dev_______________________________________________ Radiance-dev mailing list Radiance-dev@radiance-online.org http://www.radiance-online.org/mailman/listinfo/radiance-dev
-- Georg Mischler -- simulations developer -- schorsch at schorsch com +schorsch.com+ -- lighting design tools -- http://www.schorsch.com/ _______________________________________________ Radiance-dev mailing list Radiance-dev@radiance-online.org http://www.radiance-online.org/mailman/listinfo/radiance-dev
