Much simpler sentinels(!)

[Edward K. Ream]

Every time I look at Eclipse I end up rededicating myself to Leo.
Eclipse has a lot of benefits, especially its great community, but Leo
makes so many of its features seem clumsy. And then there is Java...

So the thing to do is to make Leo mainstream by dealing with
sentinels.

I now know how to make sentinels less intrusive. The inspiration was
tiny urls.

Suppose we replace cumbersome gnx's (and the odious prompt for a
unique name when Leo starts for the very first time) with this scheme:

1. Each .leo files remembers the highest gnx ever used in it or any
of its external files. Call this number N.

2. When creating a new node, we assign it a number N+1. As before, it
is immutable.

3. Headlines will be represented by sentinels like this:

#@<gnx><x> <the headline>

<x> can be one of the following:

. No change in nesting level.
+ Increase nesting level by 1
- Decrease nesting level by 1
-n Decrease nesting level by n

We represent <gnx> as in a tiny url, that is by a number base 62: 26
upper case letters, 26 lower case letters and 10 digits. Even for
large, old, .leo files we might expect that <gnx> will require no more
than three base-62 digits: 62**3 is a large number.

Examples:

#@00. first headline
#@5ZQ+ another headline
#@6A0- yet another headline
#@Z-5 and another

The <gnx> part of a sentinel will never change, but the x part may
change as nodes are rearranged. However, changes will be minimal.

As always, there are complications with @others and sections
references, but that's a nit. This scheme makes possible the
elimination of trailing sentinels in the common case that one node is
followed directly by another node (rather than the end of a section
reference or @others range.)

This scheme is similar to Emacs outline markup. It should prove to be
more palatable to those who dislike sentinels.

Edward

--
You received this message because you are subscribed to the Google Groups "leo-editor" group.
To post to this group, send email to leo-e...@googlegroups.com.
To unsubscribe from this group, send email to leo-editor+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.

[Edward K. Ream]

On Fri, May 14, 2010 at 1:55 PM, Edward K. Ream <edre...@gmail.com> wrote:

> I now know how to make sentinels less intrusive.  The inspiration was
> tiny urls.

Along these lines, suppose there were a standard for three "invisible
text" unicode characters. Perhaps there already is. We could then
use two of them to represent any base-2 number, and the other for
punctuation. We could then represent any Leo sentinel as invisibly!

At present this is more like a daydream, but if an editor would treat
these invisible characters properly we would have the functional
equivalent of MacOs resource forks.

[Terry Brown]

On Fri, 14 May 2010 15:07:47 -0500
"Edward K. Ream" <edre...@gmail.com> wrote:

> At present this is more like a daydream, but if an editor would treat
> these invisible characters properly we would have the functional
> equivalent of MacOs resource forks.

I don't see how you could avoid accidentally deleting them...

On the numbers incrementing per .leo file gnx replacement... I guess there's no way that can lead in increased gnx clashes, as there will be lots of .leo files with gnx '1' out there. But I suppose as long as only leo moves the nodes between files, this won't be a problem.

Cheers -Terry

[Matt Wilkie]

> On the numbers incrementing per .leo file gnx replacement... I guess there's no way that can lead in increased gnx clashes, as there will be lots of .leo files with gnx '1' out there.  But I suppose as long as only leo moves the nodes between files, this won't be a problem.

if gnx1 were <creation-time>+1, while all other gnx's were gnx1+N
there is very little chance of clash. <creation-time> could be the
creation time of the leo file in milliseconds, stored once at the
beginning of the file (gnx0 ?). Just a thought.

-matt

[Edward K. Ream]

On Fri, May 14, 2010 at 3:22 PM, Terry Brown <terry_...@yahoo.com> wrote:

> I don't see how you could avoid accidentally deleting them...

These same way you avoid deleting sentinels now. That is, sentinels
would start with #@, so you know where they are.

> On the numbers incrementing per .leo file gnx replacement... I guess there's no way that can lead in increased gnx clashes, as there will be lots of .leo files with gnx '1' out there.  But I suppose as long as only leo moves the nodes between files, this won't be a problem.

The N for the .leo file would be max(N,n1,n2,...) where the ni are the
max N in each external file. Given that, no new gnx can conflict with
any data in either the .leo file or the external files. It's simple
and foolproof.

I'm definitely going to play with this. Switching from old-style to
new-style gnx's will require a bit of care at load time. There will
be dict whose keys are old gnx's and whose values are new-style gnx's.
We must be sure to use this dict when allocating new gnx's so as to
preserve clone links. But this is a routine complication.

Edward

P.S. The biggest payoff may actually be the elimination of closing
sentinels for most nodes. This is in fact a completely separate
issue. But unless I am forgetting some ancient gotcha, I think this
should be possible.

EKR

[Edward K. Ream]

On May 14, 1:55 pm, "Edward K. Ream" <edream...@gmail.com> wrote:

> I now know how to make sentinels less intrusive.  The inspiration was
> tiny urls.

I've been playing around with the visual appearance of the simpler
sentinels. Here is my best result:

#@+leo-ver=5-thin
#@0; @thin sentinels_test.py
#@+others
#@1+; 1-1
1-1
#@2+: 2-1
2-1
#@3+; 3-1
3-1
#@4-3; 1-2
1-2

Here are some of the considerations:

1. We want to eliminate @nonl sentinels. The convention shown above
is:

@#x; means @nonl: the last newline is removed.
@#x: means that the last newline is retained.

I think it is clearer visually to use both colons and semicolons to
separate the gnx from the headline, though only one is essential.

2. In most cases, when a node is at a lower level than its
predecessor, it is only one or two levels lower. A simple script
shows this distribution of level differences in leoPy.leo:

d {1: 636, 2: 136, 3: 26, 4: 10, 6: 1}

Thus, we can use plain '-' and '--' to indicate diffs of 1 and 2, and
use -n for all other (rare) cases. The example above shows -3 for the
last node.

3. The end of the file will end all outstanding paired sentinels.
Thus, there is no need for an @-others or @-leo sentinel at the end.
Similarly, any node sentinel ends any previous node sentinel not
contained in the range of @all, @others or a section reference.

4. Clearly, @all, @others and section references must generate
matching sentinels at all times, except that as just discussed the end
of the file ends implicitly provides any needed closing sentinels.

Without an @-others sentinel, there would be no reliable way to
determine where the lines generated by @others end and where the lines
that follow the @others start. In any case, matching sentinels for
@others and section references make the code clearer.

5. Note that the @+leo sentinel specifies ver=5. This is indicates
that this external file will use tiny gnx's.

All comments welcome.

[Edward K. Ream]

On May 15, 7:27 am, "Edward K. Ream" <edream...@gmail.com> wrote:
> On May 14, 1:55 pm, "Edward K. Ream" <edream...@gmail.com> wrote:
>
> > I now know how to make sentinels less intrusive.  The inspiration was
> > tiny urls.
>
> I've been playing around with the visual appearance of the simpler
> sentinels.  Here is my best result:
>
> #@+leo-ver=5-thin
> #@0; @thin sentinels_test.py
> #@+others
> #@1+; 1-1
> 1-1
> #@2+:    2-1
> 2-1
> #@3+; 3-1
> 3-1
> #@4-3; 1-2
> 1-2

I forgot to show you the outline structure. It is:

- @thin sentinels_test.py
- 1-1
- 2-1
- 3-1
- 1-2

EKR

[Edward K. Ream]

On May 15, 7:27 am, "Edward K. Ream" <edream...@gmail.com> wrote:

> 2. In most cases, when a node is at a lower level than its
> predecessor, it is only one or two levels lower.  A simple script
> shows this distribution of level differences in leoPy.leo:
>
>     d {1: 636, 2: 136, 3: 26, 4: 10, 6: 1}

Note that this is the distribution when the new node is at a lower
level than the previous node.

Another simple script shows that the maximum nesting level of any node
in leoPy.leo is 10.

This shows that it would not be pleasant to use the Emacs notation for
nesting, where **** indicates a node at level 4. Not only would this
notation be ugly deep in the tree, but it would generate far larger
bzr diffs when changing the level of groups of nodes.

EKR

[Edward K. Ream]

On May 15, 7:27 am, "Edward K. Ream" <edream...@gmail.com> wrote:

> 3. The end of the file will end all outstanding paired sentinels.

Actually, I think it would be best to explicitly indicate the end of
the @others range, even if it happens to be the end of the file.
There is little to be gained by the special case, and I think that
requiring ending sentinels for section references and @others is an
important consistency check for the external file.

In any event, the new scheme eliminates more than half of all
sentinels, simplifies gnx's, and eliminates the need for the initial
dialog prompting the poor newbie for a unique name.

I like the cleaner sentinels. They will make sentinels less
objectionable. How much they will reduce complaints is anyone's
guess...

[Edward K. Ream]

On May 15, 7:27 am, "Edward K. Ream" <edream...@gmail.com> wrote:

> 1. We want to eliminate @nonl sentinels.  The convention shown above
> is:
>
>    @#x; means @nonl: the last newline is removed.
>    @#x: means that the last newline is retained.

Haha. We can regularize newlines at the end of nodes simply by always
writing either a colon or semicolon as specified in a user option.

EKR

[Edward K. Ream]

On May 15, 7:27 am, "Edward K. Ream" <edream...@gmail.com> wrote:

> I've been playing around with the visual appearance of the simpler
> sentinels.  Here is my best result:
>
> #@+leo-ver=5-thin
> #@0; @thin sentinels_test.py
> #@+others
> #@1+; 1-1
> 1-1
> #@2+:    2-1
> 2-1
> #@3+; 3-1
> 3-1
> #@4-3; 1-2
> 1-2

It's possible to do quite a bit better, as shown below. The tree
structure has changed as follows:

Added the following at the start of the top-level @thin node:

@ This is a test.
@c

<< a >>

Added the << a >> node as the first child of the @thin node. This
node has two children, a-1 and a-2. The << a >> node has the
following body text:

QQQ
a

@others

b
QQQ


Here is the resulting file.

#@+leo-ver=5-thin
#@!0; @thin sentinels_test.py
#@{; @ # could also be @{;
@doc.
# This is a doc part.
#@}; @c

#@{: << a >>
#@!5+; << a >>
a

#@{: @others
#@!6+; a-1
a-1
#@!7; a-2
a-2
#@}: @others

b
#@}: << a >>
#@{: @others
#@!1; 1-1
1-1
#@!2+: 2-1
2-1
#@!3+; 3-1
3-1
#@!4-3; 1-2
1-2
#@}: @others

I **think** this will work. In particular, the 'b' line is part of
the << a >> node, **not** the @thin node, because the << a >> node has
not ended yet. In fact << a >> node ends at the #@}; << a >> sentinel
that ends the expansion of the section referenced.

Important: the range of an @others or section reference prevents
ending of nodes containing those constructs. All along I have been
assuming that the read code will maintain context stack indicating
which nodes can be closed when a construct is seen.

Anyway, this markup has some nice features:

- Nodes always start with #@!.

- The ;/: convention applies to nested constructs, which should
eliminate the need for @nl sentinels.

- Paired (nested) constructs now always start with #@{ and end with
#@}. As shown above, this makes @others and section references stand
out much more clearly. Furthermore, #@{; @ can match with
@}; @c, which again is a nice visual simplification.

- There is no need for an '=' sign to indicate that a node is at the
same level as the previous node.

This looks like good progress.

[Edward K. Ream]

On Sat, May 15, 2010 at 9:08 AM, Edward K. Ream <edre...@gmail.com> wrote:

> I **think** this will work.  In particular, the 'b' line is part of
> the << a >> node, **not** the @thin node, because the << a >> node has
> not ended yet.  In fact << a >> node ends at the #@}; << a >> sentinel
> that ends the expansion of the section referenced.

In the background of my thinking has been the plan to use unit tests
to drive the new code. Ages ago, when I first designed sentinels, I
had no notion of unit tests--I'm not even sure they existed anywhere
back then. Now, with unit tests, I can contemplate strategies that
are much more complicated.

Edward

P.S. I uncovered a bug in the @thin read code that causes comments
following @others to be deleted. I'm almost positive that at once
time such comments were preserved. It illustrates that the present
read code is not properly covered by unit tests.

EKR

[Edward K. Ream]

On Fri, May 14, 2010 at 1:55 PM, Edward K. Ream <edre...@gmail.com> wrote:

> I now know how to make sentinels less intrusive.  The inspiration was
> tiny urls.

Earlier I wondered whether the @shadow update algorithm, or something
like it, could be applied to @nosent trees.

I've just had a brand-new thought. What happens if we try to make
@nosent more friendly to sharing?

Unlike most @<file> nodes, @nosent stores outline structure in the
.leo file. As we know, without sentinels there is *no way* to share
structure directly.

However, what it really means is that there is no way to share
*changes* in structure without sentinels. So what if we *lock*
@nosent trees by default so that it takes significant work to add or
delete nodes? In that environment we only have to update content
(body text) rather than structure. In such an environment, we should
indeed be able to update an @nosent tree when the corresponding
external file changes.

Such a "slowly changing" outline structure would allow clones because
the needed data resides in the .leo file.

To share initial outline structure, users could share @thin files at
first, and then convert them to @nosent trees later.

Compared to @auto, this scheme has advantages and disadvantages:

1. Clones are allowed, as are organizer nodes.

2. Changing outline structure by adding and deleting organizer nodes
requires real work.

3. Sharing is just as easy as other schemes, provided outline
structure varies infrequently. Otoh, there is no automatic way to
share changes in node order or outline structure.

This might be pursuing further. It seems to be a new kind of
compromise. Your comments please.

[Edward K. Ream]

On May 15, 10:57 am, "Edward K. Ream" <edream...@gmail.com> wrote:

> Earlier I wondered whether the @shadow update algorithm, or something
> like it, could be applied to @nosent trees.

As much as I enjoy this kind of speculation, this is an idea that has
no chance of working. Indeed, it suffers from a fatal flaw: the lack
of sharing essential data about structure in a collaborative
environment. To "make up" for this lack, odious restraints are
required in usage. This is hopeless.

I suppose a proper update algorithm would make a bit a sense in a non-
collaborative setting, but in such a setting sentinels are not much of
an issue so the whole idea seems limp.

[Edward K. Ream]

On May 14, 5:37 pm, "Edward K. Ream" <edream...@gmail.com> wrote:

> > On the numbers incrementing per .leo file gnx replacement... I guess there's no way that can lead in increased gnx clashes, as there will be lots of .leo files with gnx '1' out there.  But I suppose as long as only leo moves the nodes between files, this won't be a problem.
>
> The N for the .leo file would be max(N,n1,n2,...) where the ni are the
> max N in each external file.  Given that, no new gnx can conflict with
> any data in either the .leo file or the external files.  It's simple
> and foolproof.

Alas not. The scheme fails badly when moving an existing external
file into a new .leo file. Consider two files, a.py and b.py, created
in a.leo and b.leo. Each .py file might have gnx's whose numbers are
0, 1, 2, etc. If we then create @thin b.py in a.leo, many clashes
will result.

So I think we have to use "traditional" gnx's, or something like them.

Edward

P.S. getpass.getuser() may be a way to dispense with the dialog asking
for a user name.

P.P.S. For reference, using hashlib.sha1 and base64.urlsafe_b64encode
creates a 28-character gnx. These are much less readable than
traditional gnx's, but they have a fixed length.

import base64, hashlib
m = hashlib.sha1()
m.update(old_gnx)
new_gnx= base64.urlsafe_b64encode(str(m.digest()))

I probably won't bother with this.

[Edward K. Ream]

On May 16, 6:18 pm, "Edward K. Ream" <edream...@gmail.com> wrote:

> So I think we have to use "traditional" gnx's, or something like them.

Before I discovered the gotcha discussed, I realized that whitespace
might make sentinels more readable. Furthermore, I think I have
changed my mind regarding nesting level. An "absolute" level may be
visually clearer.

For reference, using hashlib.sha1 followed by

base64.urlsafe_b64encode creates a 28-character gnx. These are much

less readable than traditional gnx's, but the new gnx's have a fixed
length.

Here is an example:

#@+leo-ver=5-thin
#@!ekr.20100515061539.2126; * @thin sentinels_test.py
#@{; @

# This is a doc part.
#@}; @c

#@<< a >>

#@!ekr.20100515062623.2132; ** << a >>
a

#@{: @others
#@!ekr.20100515062623.2133; *** a-1
a-1
#@!ekr.20100515062623.2134; *** a-2
a-2
#@}: @others

b

#@{: @others
#@!ekr.20100515061539.2127; ** 1-1
1-1
#@!ekr.20100515061539.2128; *** 2-1
2-1
#@!ekr.20100515061539.2129; **** 3-1
3-1
#@!ekr.20100515061539.2130; ** 1-2
1-2
#@}: @others

Obviously, the gnx's are more intrusive. However, the nesting level
is clearer than before.

As before, the unnecessary closing node sentinels are gone.

My own opinion is that this scheme is considerably more pleasant than
any previous sentinel scheme. Please note that most nodes will be
much longer than shown here, so that sentinels will be a much small
part of the total.

Another possibility would be to put gnx's at the end of the line,
possibly after column 80. So the first 80 columns would look like:

#@+leo-ver=5-thin
#@ * @thin sentinels_test.py
#@{; @

# This is a doc part.
#@}; @c

#@<< a >>

#@ ** << a >>
a

#@{: @others
#@ *** a-1
a-1
#@ *** a-2
a-2
#@}: @others

b

#@{: @others
#@ ** 1-1
1-1
#@ *** 2-1
2-1
#@ **** 3-1
3-1
#@ ** 1-2
1-2
#@}: @others

This looks good, but of course there is a lot of cruft at the end of
headlines that is not shown. The :/; conventions would still be used,
but it would appear after the gnx.

Finally, some escape convention would have to be created to be able to
tell where the headline stops and the gnx begins. This isn't needed
when the gnx comes first.

I'm not sure which way I prefer. Putting the gnx's first is a bit
intrusive, but creating very long sentinel lines may not be great
either.

Edward

[Edward K. Ream]

On May 16, 6:44 pm, "Edward K. Ream" <edream...@gmail.com> wrote:

> The :/; conventions would still be used.

Actually, why bother? We might as well just consider that the newline
before the next sentinel is "real". The point is that a newline will
be added as needed to make the next sentinel start a line, so the only
difference would be whether a newline appears in the outline. But
that doesn't matter because the "output" is the same external file
either way!

In other words, @nonl and @nl just fussily mess up thin external
files. Converting @nonl and @nl to ; and : doesn't really change
anything. Getting rid of this conventions would be good: it would
remove yet another source of meaningless bzr diffs.

[Edward K. Ream]

On May 16, 6:44 pm, "Edward K. Ream" <edream...@gmail.com> wrote:

> Obviously, the gnx's are more intrusive...

Here is yet another scheme, using a translation table at the end of
the file.

#@+leo-ver=5-thin
#@!1 * @thin sentinels_test.py

#@{ @
# This is a doc part.
#@} @c

#@<< a >>

#@!2 ** << a >>
a

#@{ @others
#@!3 *** a-1
a-1
#@!4 *** a-2

a-2
#@} @others

b

#@{ @others

#@!5 ** 1-1
1-1
#@!6 *** 2-1
2-1
#@!7 **** 3-1
3-1
#@!8 ** 1-2
1-2
#@} @others

#@ gnx translation table. Do not delete.
#@1 ekr.20100515061539.2126
#@2 ekr.20100515062623.2132
#@3 ekr.20100515062623.2133
#@4 ekr.20100515061539.2127
#@5 ekr.20100515062623.2134
#@6 ekr.20100515061539.2128
#@7 ekr.20100515061539.2129
#@8 ekr.20100515061539.2130

I'm not sure what I think of this idea. It makes node sentinels
cleaner, but I'm not sure by how much.

Does anyone care about any of this?

[Kent Tenney]

No, in that I'm happy without sentinels,
Yes in that reducing sentinel footprint is good.

Considering Leo as a component in a data management toolchain, some of
this looks
interesting.

I've always liked the fact that the gnx is a creation timestamp, I
like knowing the age
of nodes and having the capability to timeline a Leo file.

I like the idea of eliminating the closing sentinel.

I like the idea of the sentinel providing level information.

I think hashes are wonderful, are you implying the gnx would change if
headline and
body change? I like the idea of a node being content addressable, but
it seems like this
would eliminate the timestamp data.

[Edward K. Ream]

On Sun, May 16, 2010 at 9:06 PM, Kent Tenney <kte...@gmail.com> wrote:

>> Does anyone care about any of this?

Thanks for the comments. They are particularly welcome because your
comments started me thinking about this again.

> I've always liked the fact that the gnx is a creation timestamp, I
> like knowing the age
> of nodes and having the capability to timeline a Leo file.

I'm pretty sure that gnx's will stay pretty much as they have in the
past. The only improvement would be to use getpass.getuser() rather
that .leoID.txt. This would eliminate the initial dialog, which would
really be nice because when the dialog goes up a) the user is a
complete newbie and b) Leo isn't sure how to put up the dialog.

> I like the idea of eliminating the closing sentinel.

Eliminating @nl and @nonl sentinels, and simplifying how @doc parts
are represented should have been done years ago. All these changes
would reduce the burden of sentinels significantly, and getting rid of
@nl and @nonl sentinels will eliminate lots of useless diffs.

> I like the idea of the sentinel providing level information.

I agree. Absent the gnx's, sentinels would look like Emacs
outline-mode comments.

> I think hashes are wonderful, are you implying the gnx would change if
> headline and
> body change? I like the idea of a node being content addressable, but
> it seems like this would eliminate the timestamp data.

The hash scheme I discussed isn't going to happen: it's not
significantly shorter than traditional gnx's, it would be a pain to
switch between old and new gnx's, and the new gnx's would not provide
the timestamp info that you and I both like.

Content addressability can't happen in external files: there would be
far too many diffs. It could happen in the .leo file itself easily
enough.

[Kent Tenney]

And, since I'm anti-sentinels in externals, I'm turning my attention more
to the .leo file.

I've been working on code which uses leoBridge to access
the file, I think this is the way I'll continue to go, treating the
.leo file like
a graph database, Leo as the interface, but other apps will be just as
interested in the .leo file data.

The NoSQL buzz seems to be raising the profile of those working with
graphs and graph databases. Maybe they are comrades in the sense
of SQL alternatives. Regardless, Leo and it's world view fit well with the
graph people.

Networkx http://networkx.lanl.gov/
Pycon presentation on graph database http://tinyurl.com/2d3od7a

Thanks,
Kent

[Matt Wilkie]

> I agree.  Absent the gnx's, sentinels would look like Emacs
> outline-mode comments.

Minor comment in terms of readability, I find it easier to read and
count dashes or pluses than asterisks. Stars are more "dense".

#@!5 ++ 1-1
1-1
#@!6 +++ 2-1
2-1
#@!7 ++++ 3-1


For the same reason I like a double colon :: instead of @, but I can
see how that might be too deep a change.

--
-matt

[zpcspm]

Being an user of current trunk, I "fear" that at some point I will
wake up, sync with launchpad, open an outline containing external
files and it would get broken due to changes in sentinels format.
Of course I do backups, but they would just assure I can restore an
old version, not a painless transition to leo's new sentinels.
So a couple of questions arise.
Is my fear motivated? Will leo be as smart as auto-converting old-
style sentinels to new-style ones?

[Edward K. Ream]

On Wed, May 19, 2010 at 3:28 AM, zpcspm <zpc...@gmail.com> wrote:

> Will leo be as smart as auto-converting old-style sentinels to new-style ones?

Yes. I won't enable the new code on the trunk until it has
successfully converted all of Leo's files.

I'll probably write a script to check various aspects of the
conversion: node structure stays the same, the files are the same
modulo sentinels, and round tripping all files leaves the files
unchanged.

Edward

[Edward K. Ream]

On Tue, May 18, 2010 at 6:12 PM, Matt Wilkie <map...@gmail.com> wrote:
>> I agree.  Absent the gnx's, sentinels would look like Emacs
>> outline-mode comments.
>
> Minor comment in terms of readability, I find it easier to read and
> count dashes or pluses than asterisks. Stars are more "dense".

I like them for that reason. If we are going to use this scheme it
should be more visible, not less. And I think the it would be best to
follow the emacs convention here unless there is a strong reason to do
otherwise.

Edward

[Terry Brown]

On Wed, 19 May 2010 08:20:10 -0500

"Edward K. Ream" <edre...@gmail.com> wrote:

> > count dashes or pluses than asterisks. Stars are more "dense".

> I like them for that reason.

I think Matt meant more dense as in closer to contiguous black blocks and harder to visually separate and count.

I suspect I will continue to avoid sentinels simply because the ascetic of python code is part of the appeal of python to me, but of course that's not relevant to the refinement of sentinels for those that like them.

Cheers -Terry

[Ville M. Vainio]

On Wed, May 19, 2010 at 5:17 PM, Terry Brown <terry_...@yahoo.com> wrote:

> I suspect I will continue to avoid sentinels simply because the ascetic of python code is part of the appeal of python to me, but of course that's not relevant to the refinement of sentinels for those that like them.

"Sparse is better than dense"

(fr. zen of python).

--
Ville M. Vainio
http://tinyurl.com/vainio

[Matt Wilkie]

> I think Matt meant more dense as in closer to contiguous black blocks and harder to visually separate and count.

yes, this is what I meant. thank you for the extra clarification.

--
-matt