When dealing with C extensions from Python there are circumstances
where a function is called and we get an OSError(errno) exception
without knowing what exactly went wrong internally. This is especially
not obvious on Windows, where multiple MSDN APIs may be invoked within
the same C function and
Currently, unpacking a dict in order to pass its items as keyword arguments
to a function will fail if there are keys present in the dict that are
invalid keyword arguments:
>>> def func(*, a):
... pass
...
>>> func(**{'a': 1, 'b': 2})
Traceback (most recent call last):
On Fri, Apr 12, 2019, 8:12 AM Viktor Roytman
> >>> func(**{'a': 1, 'b': 2})
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: func() got an unexpected keyword argument 'b'
>
Perhaps func(***kws)?
I think this is a real problem given the frequent conventio
On Sat, Apr 13, 2019 at 1:12 AM Viktor Roytman wrote:
>
> Currently, unpacking a dict in order to pass its items as keyword arguments
> to a function will fail if there are keys present in the dict that are
> invalid keyword arguments:
>
> >>> def func(*, a):
> ... pass
> ...
>
I could see this being an option, but to someone unfamiliar with it, it
might seem strange that * unpacks iterables, ** unpacks dicts, and *** is a
special thing only for keyword arguments that mostly behaves like **.
On Friday, April 12, 2019 at 11:26:37 AM UTC-4, Bruce Leban wrote:
>
>
> On Fr
That is certainly an option for functions that you have defined for
yourself, but generally not an option for a function from a library. I am
interested in a solution that works in general.
On Friday, April 12, 2019 at 11:48:38 AM UTC-4, Chris Angelico wrote:
>
> On Sat, Apr 13, 2019 at 1:12 AM
Hello !
I made *fief*, a small python package allowing just that using a decorator:
from fief import filter_effective_parameters as fief
@fief
def func(a, b):
# some implementation
# and then, use it as you want to:
func(**MY_BIG_CONFIG_DICT_WITH_MANY_WEIRD_KEYS)
Th
On 4/12/19, Giampaolo Rodola' wrote:
>
> As such I was thinking that perhaps it would be nice to provide 2 new
> cPython APIs:
>
> PyErr_SetFromErrnoWithMsg(PyObject *type, const char *msg)
> PyErr_SetFromWindowsErrWithMsg(int ierr, const char *msg)
> PyErr_SetExcFromWindowsErrWithMsg(PyObject *ty
On 12/04/2019 16:10, Viktor Roytman wrote:
Currently, unpacking a dict in order to pass its items as keyword arguments
to a function will fail if there are keys present in the dict that are
invalid keyword arguments:
>>> def func(*, a):
... pass
...
>>> func(**{'a': 1, 'b
Any time I am using a function from a library that accepts keyword
arguments. For example, an ORM model constructor that accepts fields as
keyword arguments (like Django).
On Friday, April 12, 2019 at 12:57:43 PM UTC-4, Rhodri James wrote:
>
> On 12/04/2019 16:10, Viktor Roytman wrote:
> > Curr
That is an interesting solution. In the case of a function from another
library, you could apply the decorator as needed like.
fief(func)(**{'a': 1, 'b': 2})
It looks a little strange, but I've seen stranger.
On Friday, April 12, 2019 at 12:18:34 PM UTC-4, Lucas Bourneuf wrote:
>
> Hello !
Viktor is looking for something at the call site, not the function
definition site (which he might not control).
I wrote calllib (horrible name, I know). It can do this, although I just
noticed it needs updating for keyword-only params.
But, here it is without keyword-only params:
>>> from c
Re-ordered to avoid top-posting...
On 12/04/2019 18:50, Viktor Roytman wrote:
On Friday, April 12, 2019 at 12:57:43 PM UTC-4, Rhodri James wrote:
On 12/04/2019 16:10, Viktor Roytman wrote:
Currently, unpacking a dict in order to pass its items as keyword
arguments
to a function will fail if
>
> > Any time I am using a function from a library that accepts keyword
> > arguments. For example, an ORM model constructor that accepts fields as
> > keyword arguments (like Django).
>
> That's not the same issue at all, if I'm understanding you correctly.
> In any case, surely you need to
I don't think it's possible to make this work reliably. In particular, it's
an important feature of python that you can make wrappers that pass through
arguments and are equivalent to the original function:
def original(a=0):
...
def wrapper(*args, **kwargs):
return original(*args, **kwar
On 4/12/2019 11:29 AM, Rhodri James wrote:
On 12/04/2019 16:10, Viktor Roytman wrote:
Currently, unpacking a dict in order to pass its items as keyword
arguments
to a function will fail if there are keys present in the dict that are
invalid keyword arguments:
>>> def func(*, a):
...
On 4/12/2019 1:52 PM, Viktor Roytman wrote:
That is an interesting solution. In the case of a function from another
library, you could apply the decorator as needed like.
fief(func)(**{'a': 1, 'b': 2})
It looks a little strange, but I've seen stranger.
Indeed. That's not so bad, and I'l
> On 12 Apr 2019, at 19:16, Eric V. Smith wrote:
>
> I don't want to speak for the OP, but I have a similar use case (which is why
> I wrote calllib). My use case is: I have number of callables that I don't
> control. I also have a dict of parameters that the callables might take as
> param
On 4/12/2019 4:00 PM, Anders Hovmöller wrote:
On 12 Apr 2019, at 19:16, Eric V. Smith wrote:
I don't want to speak for the OP, but I have a similar use case (which is why I
wrote calllib). My use case is: I have number of callables that I don't
control. I also have a dict of parameters tha
>
> That seems to me to be quite different issue. Just throwing invalid stuff
> on the ground in this scenario will avoid a crash but lose data. This seems
> much worse to me than the crash.
>
Throwing it away does seem extreme. Maybe something that indicates what's
left over? In other words
Bruce Leban wrote:
I think this is a real problem given the frequent convention that you
can freely add fields to json objects with the additional fields to be
ignored.
Unpacking json objects isn't something one does every day, so I
don't think it would be worth adding syntax just for this.
R
I'm not a fan of this idea for two (related) reasons:
1) This seems like something that's a relatively niche case to *want* to do
rather than doing unintentionally.
2) This vastly increases the chance of silent bugs in code.
With regards to #1, the main examples I've seen posited in this thread a
22 matches
Mail list logo
