I’ve always used a module-level “_marker = []” for non-shared and non-persistent sentinels, specifically because it stays in the module.

* in Perl 6 means “glob” in the shell sense, but taken to a functional/MMD extreme. For example, $foo .. * would be similar to $foo .. Inf, but is not specific to numeric types. What your type does with * is a matter of your type’s semantics (and perhaps those of a parent type), but the user will reasonably expect some sort of “infinity” or “all in range” behavior. For subscripting, @foo[*] would yield a shallow copy of @foo much like [ x for x in foo ] in python. However, for multi-dimensional arrays, this would be more handy:

@foo[*; 1..8 ; *]

For method and function dispatch, * dispatches like the Any type, but has no defined value. Thus the recipient would have to determine what they wanted to do with it.

But, in Python, I do think that a “just give me something” value might be interesting. For example generators might be able to do something useful with this, avoiding generating intermediate objects, but that’s not Perl 6′s *.

For those interested in advanced uses, * also supports expression currying. For example:

* + $x

curries up a function which returns $x plus its parameter. Thus:

my $x = 1;

my $y = * + $x;

say($y(7));

should print “8″. Currying has all sorts of interesting uses, though this example is trivial.

See for more information.

From your Perl6 example it seems that its use of ‘item(*)’ seems analogous to what would be ‘random.choice(item)’ in Python. I prefer the explicit Python version in this case.

• Paddy.

Even Python uses “*” for its import syntax to mean exactly the same thing:

from foo import *

The real reason not to use “*” in this way is that it already has two very different uses in Python (three if you count *args and **kwargs as distinct) and it doesn’t need a third (fourth). I think that the lack of grammatical ambiguity is a more interesting distinction between Python and Perl than the ratio of punctuation to non-punctuation. While there are interesting arguments for which approach is more useful for what reasons, it’s clear that the correct solution is consistency with the existing language, and in Python’s case that shoots down “*” in this case much more effectively than any degree of punctophobia.

In C we could get away with INT_MAX as long as we knew everything was guaranteed to be in int range. In Python there’s no largest integer per-se, which is why such a sentinel would indeed be useful.

Other than that, I’m fine with None. Just like in Lisp, where nil is the only real sentinel (together with ()) and they manage just fine.

In any case it could be done as sentinel if more logic was done in the algorithm. It just means various ‘if’ checks in the right places.

In any case it could be done as sentinel if more logic was done in the algorithm. It just means various ‘if’ checks in the right places.