OK, even though my heart is bleeding, I can definitely see the idea
behind dropping the .py extension for command line tools (even though
it will make it a royal pain to edit those files in Eclipse). One
nasty-ish possibility would be to keep the extension and then have
the installer remove it...
Directory structure. What about something like this (I understand
that you guys thought about this a lot, please bear with me):
lsst
apps
someApp
src
python
bla.py
c
bla.c
...
doc
bla.txt
test
...
data
...
someOtherApp
...
mw
someMW
[same structure]
One further simplification would be to drop the 'apps', 'mw' level
and have
lsst
someApp
src
python
bla.py
c
bla.c
...
doc
bla.txt
test
...
data
...
someOtherApp
...
someMW
[same structure]
Cheers
Francesco
On Jun 30, 2006, at 6:47 AM, Russell E Owen wrote:
At 11:25 AM -0500 2006-06-30, Ray Plante wrote:
> Two aesthetical preferences: I would drop the prefix py and
keep the
extension .py.
The py prefix is just for package names. I personally would not
be upset
if you did not follow this one, but it is encouraged so that we can
recognize it as primarily a python package.
The py prefix is just for directories containing python packages.
It is there purely to avoid collisions with the rest of the svn
hierarchy. Without the py prefix we have, for example this in the
svn repository:
middleware/ (non-python middleware code)
mw/ (code for lsst.mw python package)
which I feel is *VERY* confusing. To avoid this I suggest:
middleware/ (non-python middleware code)
pymw/ (code for lsst.mw python package)
Same goes with the .py extension for command-line scripts, but an
argument
for not using it is that it may get implemented in another
language in the
future.
Exactly! From the user's perspective the extension adds no useful
information and reduces future compatibility.
-- Russell
_______________________________________________
LSST-data mailing list
[email protected]
http://www.lsstmail.org/mailman/listinfo/lsst-data
_______________________________________________
LSST-data mailing list
[email protected]
http://www.lsstmail.org/mailman/listinfo/lsst-data
