I'm trying to see how it can be done with current python.
from somelib import auto
auto(locals(), function, 'a', 'b', 'c', d=5)
auto(locals(), function).call('a', 'b', 'c', d=5)
auto(locals(), function)('a', 'b', 'c', d=5)
auto(locals()).bind(function).call('a', 'b', 'c', d=5)
One of those syntax for a class auto could be chosen but it allows you to
give locals in the call.
However, locals() gives a copy of the variables so it must be given as this
code illustrates :
def f(x):
y = x+1
a = locals()
g = 4
print(a)
f(5) # {'y': 6, 'x': 5}
Le jeu. 6 sept. 2018 à 15:18, Calvin Spealman <cspea...@redhat.com> a
écrit :
>
>
> On Thu, Sep 6, 2018 at 9:11 AM Steven D'Aprano <st...@pearwood.info>
> wrote:
>
>> On Thu, Sep 06, 2018 at 12:15:46PM +0200, Anders Hovmöller wrote:
>>
>> > I have a working implementation for a new syntax which would make
>> > using keyword arguments a lot nicer. Wouldn't it be awesome if instead
>> > of:
>> >
>> > foo(a=a, b=b, c=c, d=3, e=e)
>> >
>> > we could just write:
>> >
>> > foo(*, a, b, c, d=3, e)
>> >
>> > and it would mean the exact same thing?
>>
>> No.
>>
>>
>> > This would not just be shorter but would create an incentive for
>> > consistent naming across the code base.
>>
>> You say that as if consistent naming is *in and of itself* a good thing,
>> merely because it is consistent.
>>
>> I'm in favour of consistent naming when it helps the code, when the
>> names are clear and relevant. But why should I feel bad about failing to
>> use the same names as the functions I call? If some library author names
>> the parameter to a function "a", why should I be encouraged to use
>> that same name *just for the sake of consistency*?
>>
>
> I've been asking this same question on the Javascript/ES6 side of my work
> ever since unpacking was introduced there which baked hash-lookup into
> the unpacking at a syntax level.
>
> In that world its impacted this same encouragement of "consistency" between
> local variable names and parameters of called functions and it certainly
> seems
> popular in that ecosystem. The practice still feels weird to me and I'm on
> the fence
> about it.
>
> Although, to be honest, I'm definitely leaning towards the "No, actually,
> it is a
> good thing." I grew up, development-speaking, in the Python world with a
> strong emphasis drilled into me that style constraints make better code and
> maybe this is just an extension of that.
>
> Of course, you might not always want the same name, but it is only
> encouraged
> not required. You can always rename variables.
>
> That said... I'm not actually a fan of the specific suggested syntax:
>
> > foo(*, a, b, c, d=3, e)
>
> I just wanted to give my two cents on the name consistency issue.
>
>
>
>> > So the idea is to generalize the * keyword only marker from function
>> > to also have the same meaning at the call site: everything after * is
>> > a kwarg. With this feature we can now simplify keyword arguments
>> > making them more readable and concise. (This syntax does not conflict
>> > with existing Python code.)
>>
>> It's certainly more concise, provided those named variables already
>> exist, but how often does that happen? You say 30% in your code base.
>>
>> (By the way, well done for writing an analysis tool! I mean it, I'm not
>> being sarcastic. We should have more of those.)
>>
>> I disagree that f(*, page) is more readable than an explicit named
>> keyword argument f(page=page).
>>
>> My own feeling is that this feature would encourage what I consider a
>> code-smell: function calls requiring large numbers of arguments. Your
>> argument about being concise makes a certain amount of sense if you are
>> frequently making calls like this:
>>
>> # chosing a real function, not a made-up example
>> open(file, mode=mode, buffering=buffering, encoding=encoding,
>> errors=errors, newline=newline, closefd=closefd, opener=opener)
>>
>> If 30% of your function calls look like that, I consider it a
>> code-smell.
>>
>> The benefit is a lot smaller if your function calls look more like this:
>>
>> open(file, encoding=encoding)
>>
>> and even less here:
>>
>> open(file, 'r', encoding=self.encoding or self.default_encoding,
>> errors=self.errors or self.default_error_handler)
>>
>> for example. To get benefit from your syntax, I would need to
>> extract out the arguments into temporary variables:
>>
>> encoding = self.encoding or self.default_encoding
>> errors = self.errors or self.default_error_handler
>> open(file, 'r', *, encoding, errors)
>>
>> which completely cancels out the "conciseness" argument.
>>
>> First version, with in-place arguments:
>> 1 statement
>> 2 lines
>> 120 characters including whitespace
>>
>> Second version, with temporary variables:
>> 3 statements
>> 3 lines
>> 138 characters including whitespace
>>
>>
>> However you look at it, it's longer and less concise if you have to
>> create temporary variables to make use of this feature.
>>
>>
>> --
>> Steve
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
