[ python-Feature Requests-1673203 ] add identity function

SourceForge.net noreply at sourceforge.net
Thu Mar 22 14:06:29 CET 2007


Feature Requests item #1673203, was opened at 2007-03-03 19:21
Message generated for change (Comment added) made by twobitsprite
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: paul rubin (phr)
Assigned to: Raymond Hettinger (rhettinger)
Summary: add identity function

Initial Comment:
Requested and assigned to Raymond at his suggestion:

http://groups.google.com/group/comp.lang.python/msg/603870361743c85c

There should be an identify function identity(x)=x.

I suggest it also take and ignore an optional second arg: identity(x1,x2)=x1.  The second arg can be useful in some generator expressions:

foo = (x for x in bar if condition(x) and identity(True, memoize(x))

That allows calling memoize (or some other function) on the selected elements in the genexp, and disposing of the returned value.  It's sort of like the const function (K combinator) to go along with the identity function's I combinator.  OK, the above is not really in the functional spirit, but it's been useful.

There could conceivably be also an actual const function const(k)=partial(identity,k) but I can't remember needing that in Python code.  The two-arg identity function (uncurried version of const) is probably enough.

----------------------------------------------------------------------

Comment By: Memotype (twobitsprite)
Date: 2007-03-22 09:06

Message:
Logged In: YES 
user_id=1679533
Originator: NO

I also would like to have a built-in identity function (in fact, I found
this by googling "python identity function"). My use-case is a bit
different. I ofter find myself wanting to simply specify a function for be
used in a loop, something like:

def f(items):
    if something:
        wrapper = int
    else:
        wrapper = identity

    for item in items:
        yield wrapper(item)

of course, usually it's a bit more complex than that, but you get the
idea... and I supposed its actually more like the previous use-case than I
thought.

I realize I could just use "lambda x: x", but I feel that comes with an
unnecessary performance impact for something so trivial. I don't know how
much python does to compile built-in functions, but I imagine that the
identity function can be mostly optimized out at compile time if it were
built-in.

Just my two-cents.


----------------------------------------------------------------------

Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-03-19 15:57

Message:
Logged In: YES 
user_id=835142
Originator: NO

I have just realized that the requested functionality is known in C as the
comma operator.  I often find myself writing "return Py_INCREF(o),o;" in my
C code, but I cannot really defend that idiom against "Py_INCREF(o); return
o;" alternative.  My personal reason is entirely C-specific, if  followed
an if(), the first form does not require curly braces.

In any case, comma operator can be emulated in python as

exp1,expr2,expr3   ->  (exp1,expr2,expr3)[-1]


Since multi-argument "identity" is likely to be rejected, my proposal to
alter the order of arguments is moot.  My other suggestion that with
identity, map(None, ..) should be deprecated in favor of map(identity, ..)
is probably an arument against the identity proposal now.  

----------------------------------------------------------------------

Comment By: Collin Winter (collinwinter)
Date: 2007-03-19 15:05

Message:
Logged In: YES 
user_id=1344176
Originator: NO

I can see adding the 1-argument form to operator or functools (as it's
useful in functional programming), but the 2-argument form you've suggested
is right out. If you really feel the need to torture a "for" loop into a
genexp/listcomp like that,

foo = (x for x in bar if condition(x) and [memoize(x)])

does the same thing using today's capabilities.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2007-03-12 16:06

Message:
Logged In: YES 
user_id=341410
Originator: NO

Not all x line functions should be built into Python.  Further, Python's
standard syntax offers an infix operator that does the same thing (though
in slightly different order as described below, you can reorder with
minimal effort).

identity(X, Y) -> (Y and False) or X

Also, the only use-case that you are provided and that I can imagine, are
examples like you provide where one is changing state within a statement
(if, elif, while, etc.) or expression (generator, list comprehension,
conditional, etc.).

----------------------------------------------------------------------

Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-03-05 09:21

Message:
Logged In: YES 
user_id=835142
Originator: NO

1. If this proposal is accepted, it will make sense to deprecate the use
of None as an identity function in map:

>>> map(None, range(10))
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

2. Some other languages have an dyadic identity function that returns the
*second* argument. 

For example, K has : primitive:

  identity:(:)
  identity[1;2]
2

The rationale in K is that it is useful in an ammed function that replaces
entries of an an array with a result of a dyadic function applied to the
old and the supplied value and it is natural to have old value first:

  @[1 2 3;1;-;20]
1 -18 3
  @[1 2 3;1;:;20]
1 20 3

This rationale does not apply to Python, but in the absence of other
reasons to choose the order of arguments, Python may as well follow the
precedent. Does anyone know a less exotic language that has a dyadic
identity?




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470


More information about the Python-bugs-list mailing list