Steven D'Aprano wrote:
> Proposal:
> We should have a mechanism that collects the current function or
> method's parameters into a dict, similar to the way locals() returns all
> local variables.
> This mechanism could be a new function,or it could even be a magic local
> variable inside each
On Sat, May 16, 2020 at 10:07 PM Eric V. Smith wrote:
> But my question is: If this technique has been available for 12 years,
> why is it not more popular?
>
Because linters will not recognise a third party solution. Personally I've
written code like:
```
def __init__(self, **kwargs):
On 5/16/2020 2:35 PM, Joao S. O. Bueno wrote:
So, this thread has stalled, but I saw no contrary opinions to a
decorator like this.
I think the plain version (not treating positional only arguments differently,
no partially-initialized namespace, no annotations based auto-argument cast)
could
Thanks for the support Joao, obviously I would be keen to have it in. Happy to
help out with the PRs and reviews etc. if it does go ahead
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to
So, this thread has stalled, but I saw no contrary opinions to a
decorator like this.
I think the plain version (not treating positional only arguments differently,
no partially-initialized namespace, no annotations based auto-argument cast)
could make it into a bpo -
what do you say?
On Wed, 6
On May 4, 2020, at 17:26, Steven D'Aprano wrote:
>
> Proposal:
>
> We should have a mechanism that collects the current function or
> method's parameters into a dict, similar to the way locals() returns all
> local variables.
>
> This mechanism could be a new function,or it could even be a
On Wed, 6 May 2020 at 15:08, Ricky Teachey wrote:
>
> On Wed, May 6, 2020 at 1:44 PM Alex Hall wrote:
>>
>> I think this looks great, I can't think of anything wrong with it.
>>
>> Could we put this into the standard library, so that IDEs and linters are
>> programmed to recognise it?
>
>
> If
> Although I might use it a lot (more than I would like to admit), I don't
> like this feature. First of all, I think it favors not-very-pretty code,
> effectively reducing the cost you pay for writing too-many-argument
> functions. It'd also obfuscate the code, and here I would like to quote the
On Wed, 6 May 2020 at 18:56, Lewis Ball wrote:
>
> Joao S. O. Bueno wrote:
> > Here - with the current inspect.Signature, it is straightforward
> > to get a decorator that can do that covering most, if not all,
> > corner cases, and even adding some extra functionality:
> >
Hello everyone, I am Pablo from Argentina! This is my first email here, so
just let me know if I am missing anything that is of use in this list, such
as presenting myself. As for this topic in particular:
Although I might use it a lot (more than I would like to admit), I don't
like this feature.
Joao S. O. Bueno wrote:
> Here - with the current inspect.Signature, it is straightforward
> to get a decorator that can do that covering most, if not all,
> corner cases, and even adding some extra functionality:
> https://gist.github.com/jsbueno/f689a181d50384f627b43b9b2aabe4f2
>
> from
> In the example above, self.b is assigned the value of b, not Enum(b). And
even if you called-- or gave the option to call-- func(*args, **kwargs)
first, autoassign still wouldn't know that you want to modify the supplied
parameter value.
>>>
>>> But you could just write
On Wed, May 6, 2020 at 8:49 PM Ricky Teachey wrote:
>
>>> In the example above, self.b is assigned the value of b, not Enum(b).
>>> And even if you called-- or gave the option to call-- func(*args, **kwargs)
>>> first, autoassign still wouldn't know that you want to modify the supplied
>>>
>
>
>> In the example above, self.b is assigned the value of b, not Enum(b). And
>> even if you called-- or gave the option to call-- func(*args, **kwargs)
>> first, autoassign still wouldn't know that you want to modify the supplied
>> parameter value.
>>
>
> But you could just write `self.b =
On Wed, May 6, 2020 at 8:08 PM Ricky Teachey wrote:
> On Wed, May 6, 2020 at 1:44 PM Alex Hall wrote:
>
>> I think this looks great, I can't think of anything wrong with it.
>>
>> Could we put this into the standard library, so that IDEs and linters are
>> programmed to recognise it?
>>
>
> If
On Wed, May 6, 2020 at 1:44 PM Alex Hall wrote:
> I think this looks great, I can't think of anything wrong with it.
>
> Could we put this into the standard library, so that IDEs and linters are
> programmed to recognise it?
>
If it does cover the majority of corner cases, I think this is a
I think this looks great, I can't think of anything wrong with it.
Could we put this into the standard library, so that IDEs and linters are
programmed to recognise it?
On Wed, May 6, 2020 at 4:55 PM Joao S. O. Bueno
wrote:
> Here - with the current inspect.Signature, it is straightforward
>
Here - with the current inspect.Signature, it is straightforward
to get a decorator that can do that covering most, if not all,
corner cases, and even adding some extra functionality:
https://gist.github.com/jsbueno/f689a181d50384f627b43b9b2aabe4f2
```
from inspect import signature, Parameter
On Mon, 4 May 2020 at 19:13, Lewis Ball wrote:
>
> I had a similar solution with a decorator using inspect.getfullargspec but it
> is pretty fiddly and it is pretty easy to miss
> some of the edge cases. Having a standard implementation would definitely
> take care of this. And I imagine
>
On Tue, May 5, 2020 at 3:14 PM Steven D'Aprano wrote:
> On Tue, May 05, 2020 at 02:55:24PM +0200, Alex Hall wrote:
>
> > Perhaps we should take the energy that is going into this thread and
> direct
> > it towards supporting keyword-only arguments in dataclasses, a discussion
> > which is
On Tue, May 05, 2020 at 02:55:24PM +0200, Alex Hall wrote:
> Perhaps we should take the energy that is going into this thread and direct
> it towards supporting keyword-only arguments in dataclasses, a discussion
> which is apparently struggling:
Why? How are dataclasses relevant (don't assume
Perhaps we should take the energy that is going into this thread and direct
it towards supporting keyword-only arguments in dataclasses, a discussion
which is apparently struggling:
https://github.com/python/cpython/pull/6238#issuecomment-584579729
On Mon, May 4, 2020 at 10:49 PM Lewis Ball
On Tue, May 5, 2020 at 10:08 PM Steven D'Aprano wrote:
>
> On Tue, May 05, 2020 at 04:05:20AM -, Brandt Bucher wrote:
> > It's a fairly common idiom to just collect `locals()` on the first
> > line of a function or method with lots of arguments
>
> Indeed, but it's that requirement that it
On Tue, May 05, 2020 at 04:05:20AM -, Brandt Bucher wrote:
> > We should have a mechanism that collects the current function or method's
> > parameters into a dict, similar to the way locals() returns all local
> > variables.
>
> Maybe I'm missing something here, but how about... `locals`?
> We should have a mechanism that collects the current function or method's
> parameters into a dict, similar to the way locals() returns all local
> variables.
Maybe I'm missing something here, but how about... `locals`? It works exactly
as you hope:
```
def __init__(self, argument_1,
On Mon, May 04, 2020 at 07:01:03PM +0100, Lewis Ball wrote:
> Hi All,
>
> First of all, if this is something which has been discussed in the past the
> please point me in the right direction.
It certainly has been, but with no conclusion one way or another. I
think people agree that it is a
I had a similar solution with a decorator using inspect.getfullargspec but
it is pretty fiddly and it is pretty easy to miss some of the edge cases.
Having a standard implementation would definitely take care of this. And I
imagine static analysis tools would be able to cope with it, they do a
I agree that dataclasses are for a slightly different use case.
It looks like this could be implemented as a decorator using the
functionality afforded by `inspect.signature`, though what I've come up
with so far is a bit clunky because you have to account for parameters that
could be positional
I did think about data classes and although I haven't really used them much
they do seem to be for a different use case, for example they don't support
keyword-only args or positional-only args. I'm not sure if there are any
other differences. Maybe a data class which supported kW-only args and
You are not the first to have this idea. Unless I am mistaken you might
find what you are looking for in dataclasses which were added in Python 3.7:
https://docs.python.org/3/library/dataclasses.html
On Mon, 4 May 2020 at 19:06, Lewis Ball wrote:
> Hi All,
>
> First of all, if this is
30 matches
Mail list logo
