what does 'for _ in range()' mean?

[Peter Hansen]

In that context, it's allowed multiple times, but in some other contexts
it's not:


...
File "<stdin>", line 1
SyntaxError: duplicate argument '_' in function definition

Uh, okay... and does Ocaml allow duplicating argument
names in whatever it has that passes for a function
definition? This is all a reach from the original
point of the thread, which was to use it as a throw-away
control variable in a for loop...

-Peter

 

[Leif K-Brooks]

The best solution then would probably be:

def foo(*_):
pass

 

[Matteo Dell'Amico]

Uh, okay... and does Ocaml allow duplicating argument
names in whatever it has that passes for a function
definition? This is all a reach from the original
point of the thread, which was to use it as a throw-away
control variable in a for loop...

It allows pattern-matching. You can say, for instance, something as:

foo(a, a) = True
foo(_, _) = False

This means that foo is true when its arguments are equal. Note, too,
that 'a' has a different value from '_'.

 

[Dan Bishop]

Peter> _DEFAULT_UNUSED_LIST = [ '_', 'empty', 'unused', 'dummy', ]

One might consider adding 'i' to that list. If nothing else, it would avoid
a bunch of warnings... ;-)

But then we'd have to add a, t, n, and x, too

In other languages, I've used "fcrt" as a dummy variable name, to
indicate that is only named because the Friendly Compiler Requires
This.

 

[Peter Hansen]

It allows pattern-matching. You can say, for instance, something as:

foo(a, a) = True
foo(_, _) = False

This means that foo is true when its arguments are equal. Note, too,
that 'a' has a different value from '_'.

I have no idea what you are talking about; sorry. The "code"
you show is not valid, and since you aren't talking about a
function *definition* (where duplicate names are disallowed)
but apparently about calling a function, I can't see that this
has the slightest thing to do with the topic at hand.

Therefore I'm sure I misunderstood what you meant... please
explain.

-Peter

 

[Matteo Dell'Amico]

I have no idea what you are talking about; sorry. The "code"
you show is not valid, and since you aren't talking about a
function *definition* (where duplicate names are disallowed)
but apparently about calling a function, I can't see that this
has the slightest thing to do with the topic at hand.

Of course this is not valid python code.
This is a pseudo-functional language function definition. It is
specified by pattern matching:

foo(a, a) = True

means that calling foo with a tuple of two identical arguments returns
True, while

foo(_, _) = False

means that calling foo with a tuple of any two arguments returns False,
if the above condition isn't met.

The goal was to put into evidence the use of pattern-matching and '_'.
That's all.

I hope this is clearer now...

 

[Peter Hansen]

[...snip attempted explanation...]

I hope this is clearer now...

Actually, not in the least, but I'm happy to go on faith that
you have a point and hope you have managed to communicate it
to others. :-|

-Peter

 

[Matteo Dell'Amico]

Actually, not in the least, but I'm happy to go on faith that
you have a point and hope you have managed to communicate it
to others. :-|

Let's try it again: in functional programming languages, you can use
pattern-matching, so that you can define functions in a declarative
fashion this way:

f(1) = 2
f(2) = 3
f(3) = 4
f(_) = 42

In python, this could be written as:

def f(x):
if x == 1:
return 2
elif x == 2:
return 3
elif x == 3:
return 4
else:
return 42

'_' is the identifier that means "anything here".

 

[Peter Hansen]

Let's try it again: in functional programming languages, you can use
pattern-matching, so that you can define functions in a declarative
fashion this way:

Oh! Enlightment dawns.... we were still talking about Ocaml then.
I see.

So to get this back to the point that was being made:

Phil said Ocaml allowed multiple _ in tuple assignments but
that Python did not, while I attempted to correct that assertion by
showing that it in fact did.

David and you were discussing a case involving function languages,
which Python is not, where the use of multiple _ (which now has
syntactical meaning, as opposed to being just an "ignore this" by
convention) is allowed.

Sounds to me like the two discussions are unrelated.

-Peter

 

[Matteo Dell'Amico]

Phil said Ocaml allowed multiple _ in tuple assignments but
that Python did not, while I attempted to correct that assertion by
showing that it in fact did.

David and you were discussing a case involving function languages,
which Python is not, where the use of multiple _ (which now has
syntactical meaning, as opposed to being just an "ignore this" by
convention) is allowed.

Sounds to me like the two discussions are unrelated.

More or less so. It was only a discussion on the etimology of the
underscore convention.

 

[Peter Hansen]

More or less so. It was only a discussion on the etimology of the
underscore convention.

In that case they would be related, but is this any more than
supposition on your part? Is the use of _ as a throw-away in
for loops, and perhaps even in the interpreter as "last result",
definitely descended from its wildcard usage in functional
languages (or, at least, Ocaml)?

-Peter

 

[Christopher T King]

In that case they would be related, but is this any more than
supposition on your part? Is the use of _ as a throw-away in
for loops, and perhaps even in the interpreter as "last result",
definitely descended from its wildcard usage in functional
languages (or, at least, Ocaml)?

I'm pretty sure they're both descended from the use of _ as both a
throw-away and a wildcard in Prolog, as another poster pointed out.

For reference, Prolog was born in 1970, OCaml was born in 1996 (with roots
dating back to ML in 1983), and Python was born in 1991. (Data gleaned
from the Programming Language Genealogy Project at everything2.com.)

 

[Peter Hansen]

I'm pretty sure they're both descended from the use of _ as both a
throw-away and a wildcard in Prolog, as another poster pointed out.

I'm just as unsure about any of that. It seems more likely to
me that a number of people have independently found _ to be a handy
"anonymous" variable in different situations, and that trying to find
links to analogous usage in other languages is largely speculative.

Of course, that said, we'll probably hear shortly from someone
channelling the person who added it to the interpreter as the
"last result" name, contra-dicting me.

-Peter

 

[Matteo Dell'Amico]

I'm just as unsure about any of that. It seems more likely to
me that a number of people have independently found _ to be a handy
"anonymous" variable in different situations, and that trying to find
links to analogous usage in other languages is largely speculative.

It would surprise me if the three were unrelated... there are
similarities between prolog's unification, ML's pattern matching and
python's tuple unpacking (even if the latter is considerably simpler and
less powerful), and note that the specific meaning of _ - both in Prolog
and in ML-like languages - is "throw away": if I'm not mistaken, you can
always replace an underscore with a new unused variable.

Of course, that said, we'll probably hear shortly from someone
channelling the person who added it to the interpreter as the
"last result" name, contra-dicting me.

I see this one as a totally unrelated meaning, similar to perl's $_. I'm
waiting to be contradicted, too.

 

[Dave Benjamin]

Note also there's a noticeable difference between the anonymous variable
in Prolog and the use of _ in Python; in Prolog, the anonymous variable
can be used multiple times in the same expression and there is no need
for the variable to represent the same thing. In

middle(X) :- inOrder(_, X, _).

In Python, it's possible to use _ multiple times in the same expression,
too. I guess there's no obvious reason why this shouldn't work, but I
discovered the following tuple-unpacking idiom recently:
.... print val
....
2
5
8

 

[Terry Reedy]

In Python, it's possible to use _ multiple times in the same expression,

In Python, _ is a (non-keyword) name like any other. It can be used like
any other name. In interactive mode, it is the default name bound to bare
expressions, but it is still just a name.

too. I guess there's no obvious reason why this shouldn't work, but I
discovered the following tuple-unpacking idiom recently:

... print val
...
2
5
8

So does

for a,v,a in [[1,2,3], [4,5,6]]: print v

....
2
5

too much fuss over simplicity yours

Terry J. Reedy

 

[Heike C. Zimmerer]

In Python, it's possible to use _ multiple times in the same expression,

There is, however, one objection to the use of _ as a placeholder for
a dummy variable: it is used by the gettext module. So if a program
may be subject to internationalization, it is advisable to keep this
name reserved, or you may run into problems.

 

[Skip Montanaro]

Heike> There is, however, one objection to the use of _ as a placeholder
Heike> for a dummy variable: it is used by the gettext module. So if a
Heike> program may be subject to internationalization, it is advisable
Heike> to keep this name reserved, or you may run into problems.

Only if you use it as both a placeholder variable and call it as a function
within the same function, or have the misfortune to declare

global _

in some function where it's used as a placeholder in a module whose other
functions call _("some string").

Skip

 

[Dave Benjamin]

In Python, _ is a (non-keyword) name like any other. It can be used like
any other name. In interactive mode, it is the default name bound to bare
expressions, but it is still just a name.

Right, I guess what surprised me is that you can tuple-unpack to the same
variable repeatedly. I understand that there's nothing special about "_"
(aside from its special treatment in the interpreter).

Funny, I was sure that someone would nitpick about my misuse of the word
"expression".

 

[Dave Benjamin]

There is, however, one objection to the use of _ as a placeholder for
a dummy variable: it is used by the gettext module. So if a program
may be subject to internationalization, it is advisable to keep this
name reserved, or you may run into problems.

Speaking of which, am I the only one here that sees this _() function as a
total hack? Usually, having a one-character function (and a global one at
that!) would be considered outrageous, and why not have global string
constants instead of looking up complete sentences as keys in a mapping
table? Not that I could propose a better solution if you're trying to make
an already existing, large application multilingual, but still...