On Mon, Nov 7, 2011 at 4:43 PM, Terry Brown <[email protected]> wrote:
> - The initial directory at the top of the .leo file is the directory
> containing the .leo file. (*)
Yes, and this isn't going to change. That is, for almost all
purposes, Leo does the following when computing paths::
g.os_path_finalize_join(g.app.loadDir,whatever)
We can't change this now: it would break all outlines.
In essence, we are discussing what to do when "whatever" is an absolute path.
> - The path for each node is that directory, with any modifications
> made by @path or @<file> (@auto, @file, etc.) directives on the
> node itself or its ancestors. Any absolute paths encountered would
> eliminate the influence of all path information from any ancestor
> nodes.
Correct.
> So for the file /home/tbrown/myproject/project.leo,
>
> @auto projectnotes.txt would be /home/tbrown/myproject/projectnotes.txt
>
> @path docs
> @auto projectnotes.txt
> would be /home/tbrown/myproject/docs/projectnotes.txt
>
> @path /tmp
> @auto projectnotes.txt
> or
> @auto /tmp/projectnotes.txt
>
> would be /tmp/projectnotes.txt
The above has always been my intention.
> In the specific case of Window's drive specific relative paths, like
> A:projectnotes.txt,
Imo, this has no place in Leo.
> Given a .leo file C:\myproject\project.leo, what does @auto
> A:projectnotes.txt mean?
I agree that it means nothing. Imo, it should be flagged as an error.
> And for Windows paths like @auto \myproject\projectnotes.txt, the "root
> of which drive?" question can be answered consistently by following the
> above rules to work out which drive you started on, either the one
> holding the .leo file, or another specified by an absolute @path
> ancestor node.
Maybe, but I would prefer to keep the meaning of
g.os_path_finalize_join to be a close as possible to the underlying
os.path methods of which it is composed, namely:
QQQQQ
def os_path_finalize (path,**keys):
'''
Expand '~', then return os.path.normpath, os.path.abspath of the path.
There is no corresponding os.path method'''
c = keys.get('c')
if c: path = g.os_path_expandExpression(path,**keys)
path = g.os_path_expanduser(path)
path = os.path.abspath(path)
path = os.path.normpath(path)
return path
def os_path_finalize_join (*args,**keys):
'''Do os.path.join(*args), then finalize the result.'''
c = keys.get('c')
if c:
args = [g.os_path_expandExpression(z,**keys)
for z in args if z]
return os.path.normpath(os.path.abspath(
g.os_path_join(*args,**keys))) # Handles expanduser
QQQQQ
Unit tests (as expanded by the stupendous Aha) will be helpful, or
even decisive here. A unit test can be a design spec for dozens of
cases.
"Dense" unit tests have the following form::
table = (
case 1, # a tuple, defining (arg1,...,argK,expected)
...
case N,
)
for arg1,...,argK,expected in table:
result = aFunction(arg1,...,argK)
assert result == expected,'expected: %s, got: %s' % (
expected,result)
Note that the tuples in the table may also specify "aFunction".
I have written many such tests, and plan to write many more.
To illuminate the present discussion, "aFunction" will compute the
g.os_path_whatever on a given descendant tree containing @path
directives, @@file nodes (temporarily changed to @file nodes), etc.
Once this test is in place, we can suggest new table entries and argue
about what the expected result should be :-) I'll get started on this
unit test today.
Edward
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/leo-editor?hl=en.
