Am 2016-03-24 17:58, schrieb Gregory J. Ward:
Does rlux even work under Windows? I suppose it
does, or you wouldn't bother. Also, where does this program exit?
How does it return an error if it doesn't get at least two arguments?
Shouldn't there be a call to os.exit(1) after the print call? Why
isn't print() os.print() or sys.print()? These things seem mysterious
to me in the land of the "language that doesn't get in they way." The
mixture of straight function calls, method calls on class names, and
calls on null objects like ''.doSomethingWithString() seems eccentric,
or at the least, inconsistent.
The "big" version of rlux.py runs on *any* platform supporting both
Radiance and Python. The "small" one would require some fiddling with
quotes to run on Windows, as long as there are no spaces involved.
Python programs can exit in three different ways (quite similar to
Perl, I think):
By running off the bottom without error (exit value 0)
By the builtin function exit(n)/quit(n) (with the given exit value)
Via an uncaught exception (exit value 1)
That just reminds me that I probably should exit with a no-zero value
at the very bottom when catching the "Error" exception.
And a closely related bug you correctly detected in my quick-and-dirty
translation: Next to printing the usage message, it should indeed
exit() with a non-zero value as well.
One of the purposes of modules is to unclutter the local namespace.
However, there's still a number of very frequently used objects and
functions directly accessible from any context. Those include
the system exceptions
the type objects (which also serve as conversion functions)
other type conversion functions that aren't types themselfes
quit() and exit() (really the same thing)
print()
a smallish number of other very elementary functions
Part of that selection is necessarily arbitrary (design choice), and
has been reduced quite a bit over the evolution of the language.
The print function is global because it is probably one of the most
used functions of all. In earlyer versions of Python it actually used
to be a language keyword instead of a function.
Something like ''.split() or ''.join() is absolutely consistent with
the general object model, and handled pretty much the same in all
object oriented languages. It would rather be excentric to still
treat a string as an "array of char" in this context.
The use of qualified names for functions and methods serves to keep
namespaces seperate, in oder to avoid confusion. I understand that it
may not be obvious to you right now whether you see a function call in
a module, or a method call in an object instance (I don't think I'm
using any class methods in my code). But that will become clearer each
time you look at it.
My main concern is just the add-on nature of the libraries, and that
there can be too many to choose from. Having basic facilities that
everyone uses establishes conventions that make it easier to read
other people's code. So long as everyone chooses the same library to
make the same calls, and those calls don't change with new versions of
the libraries or of Python, then I don't have a problem with it. It's
not that I distrust libraries per se, just "extensionitis." Seeing
things like:
import os
import sys
import math
import tempfile
import argparse
import subprocess
at the top of a module is a bit scary -- it means I need to be
familiar with these classes to understand the code. It's just more
work. I prefer to avoid unnecessary work.
That block may look impressive (I could have written it on one line,
and you might have hardly noticed it). But the actual modules are
very common and rather obvious.
The documentation describes the most often used two modules as:
os - Miscellaneous operating system interfaces
sys - System-specific parameters and functions
You need "math" as soon as you want to do calculations beyond the basic
operators and min()/max().
"Tempfile" knows where the standard temp directories on every platforma
are, and helps to prevent tampering. I know that the latter is not
really critical for Radiance, but it's just good programming practise.
"Argparse" has an obvious name. Don't get fooled by the visually massive
appearance of the related code blocks, that is only because they
include all the text strings for the usage help output.
The "subprocess" module may be the least trivial of the lot, but it
simplifies things by encapsulating platform differences. And I've
again encapsulated its use in pyradlib/pyrad_proc. In the actual
scripts, we only need it for the constant subprocess.PIPE.
We could actually offer that for import through pyrad_proc, to make
it more obvious what it's used for.
Those are all very good questions that show your increasig grasp of
Python. All hope is not lost... ;)
An outside view is also quite helpful in finding the bugs hiding in
some of my own blind spots.
Perl also offers object oriented possibilities nowadays, even if by
far not as simple and elegant. Those features just don't seem to be as
popular with the target audience.
I suppose it's what you're used to. As I said earlier, the issue with
libraries is mostly about vocabulary and what you need to know that
isn't right before you. To me, writing a class to do something that
should be straightforward doesn't make sense. I might even argue that
writing a class where you only expect to create a single object in
that class also doesn't make sense, unless you plan to share the class
with other classes or modules.
People have built whole life philosophies around that question...
In my case, after working with object oriented methods for so many
years, it has just become second nature to start with a class.
Experience shows that as things grow, they tend to turn into a class
anyway, so I'm usually saving on one of the refactoring stages.
When converting those scripts, I chose to use the same pattern for all
of them for consistency. I was fully aware that I was adding around 90%
of boilerplate to rlux.py, hence the comment at the top of the file.
But we also need to keep in mind, that when we start distributing
those things as exe files on Windows, those users may not want to go
to look up the sources on radiance-online just to see how the script
is invoked correctly. So the script itself really needs to give them
good diagnostics and usage instructions. And in the extreme case of
around three lines of actual functionality, that will lead to this
seemingly absurd ratio of content to packaging.
Btw.: That doesn't mean that the original csh scripts need to go away!
They may serve as a reference implementation verified by you, that we
can use to compare the translations against. As long as you haven't
familiarized yourself with Python enough to check the more complex
examples directly, they can happily live next to each other.
Cheers
-schorsch
--
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
