coady / placeholder Goto Github PK

How do I this?

filter(_ in "123", names)

I tried to implement it since _ has not __contains__, but the only result was not-working "123" in _. Hopes the author can implement this better than me.

Hi,
I was wondering how I could do _.mymethod() . The following code gives me an error.

if __name__ == '__main__':
    from placeholder import _
    class A:
        def __init__(self, a_list):
            self.d = a_list
        def data(self):
            return self.d

    data = [A([1, 2]), A([3, 4])]
    mapped = map(lambda a: a.data(), data)
    print(">> Using Lambda")
    print(list(mapped))
    print(">> Using Placeholder")
    mapped = map(_.data(), data)
    print(list(mapped))

Traceback (most recent call last):
  File "/home/rajiv/Documents/dev/python/mercylog/trial.py", line 61, in <module>
    mapped = map(_.data(), data)
TypeError: attrgetter expected 1 argument, got 0
>> Using Lambda
[[1, 2], [3, 4]]
>> Using Placeholder

The sdist distributed on PyPI cannot be used to build the project, because it doesn't include docs/requirements.txt which is referenced in setup.py.

It probably just needs to be added to MANIFEST.in.

The following doesn't return a correct lambda:
_.x == None

So the fact that _.foo.{{ bar }} always creates a callable which does the equivalent of lambda x: x.foo.{{ bar }}, unless {{ bar }} is one special-cased string, in which case it returns operator.attrgetter('foo'), is something I would call a "hole" - in the regular space of the interface, there's this one spot which you have to know about, remember, and remain vigilant about.

When some library gets enough users, most users don't look at the docs, they just learn and generalize from example. It's very easy for a developer to end up seeing at least one _.foo.bar example and naturally assume regularlity of interface, only to one day accidentally fall into this hole when _.foo happens to be, say, something like a functools.partial instance - something with a .func attribute.

So here's the question: for the next backwards-compatibility-breaking release, are you willing to consider alternatives for getting the raw underlying function, which don't require poking a hole in the surface of the interface?

For example, perhaps an extra external function, so that you'd do from placeholder import raw_callable or whatever you want to call it, and then instead of _.foo.func we'd do raw_callable(_.foo)?

Since _ + _ works like lambda a, b: a + b, and _ + _ - 1 works like lambda a, b: a + b - 1, I would expect _ + _ - _ to work like lambda a, b, c: a + b - c.

But unfortunately it doesn't:

>>> ((_ + _) - _)(1, 1, 1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/user/python3/lib/python3.9/site-packages/placeholder/__init__.py", line 19, in pipe
    value = funcs[0](*args, **kwargs)
TypeError: add expected 2 arguments, got 3

It seems that this is because _ + _ - _ creates F(<function pipe at 0x7fbcee4eee50>, (<built-in function add>, <built-in function sub>)), which if I understand right is more like compose(operator.sub, operator.add), so it behaves like lambda a, b: operator.sub(a + b):

>>> ((_ + _) - _)(1, 1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/user/python3/lib/python3.9/site-packages/placeholder/__init__.py", line 21, in pipe
    value = func(value)
TypeError: sub expected 2 arguments, got 1

Now that the project needs to be built with a C compiler, would you consider shipping Windows wheels? Not all Windows systems have a C compiler available.