Hi,
I'd like to reopen this discussion if anyone is interested. Some things
have changed since I wrote my original proposal so I'll first summarize:
1. People seem to prefer the syntax `foo(=a)` over the syntax I suggested.
I believe this is even more trivial to implement in CPython than my
On 12/09/2018 16:38, Steven D'Aprano wrote:
> On Wed, Sep 12, 2018 at 03:58:25PM +0100, Jonathan Fine wrote:
>
>> My question is about correctly implementing of __params__ as a keyword
>> identifier, with semantics as in Steve B's code snippet above.
>
> The semantics of Steve's code snippet
On Wed, Sep 12, 2018 at 03:58:25PM +0100, Jonathan Fine wrote:
> My question is about correctly implementing of __params__ as a keyword
> identifier, with semantics as in Steve B's code snippet above.
The semantics of Steve's code snippet are ambiguous.
> Here's my question: Do you think
On Wed, Sep 12, 2018 at 06:59:44AM -0700, Ethan Furman wrote:
> On 09/12/2018 05:17 AM, Steven D'Aprano wrote:
[...]
> >We could solve this race condition with locking, or by making the pair
> >of steps:
[...]
> >I'm not an expert on threaded code, so it is possible I've missed some
>
Hi Steve
Thank you for your prompt reply. You wrote:
> I'll confess that I couldn't work out what Steve B's code snippet was
> supposed to mean:
> params = {k:v for k,v in __params__ if k in parent.a_method.keys()}
The Zen of Python (which might not apply here) says:
In the face of
On Wed, Sep 12, 2018 at 02:23:34PM +0100, Jonathan Fine wrote:
> Steve Barnes suggested adding __params__, as in
>
> > def a_method(self, cr, uid, ids, values, context=None):
> >...
> >params = {k:v for k,v in __params__ if k in parent.a_method.keys()}
> ># Possibly
On 09/12/2018 05:17 AM, Steven D'Aprano wrote:
> Indeed. Each time you call locals(), it returns a new dict with a
snapshot of the current local namespace. Because it all happens inside
the same function call, no external thread can poke inside your current
call to mess with your local
Steve Barnes suggested adding __params__, as in
> def a_method(self, cr, uid, ids, values, context=None):
>...
>params = {k:v for k,v in __params__ if k in parent.a_method.keys()}
># Possibly add some additional entries here!
>super(self,
> On 8 Sep 2018, at 14:23, Anders Hovmöller wrote:
>
>> To me, the "30% of all arguments" deserves more careful examination.
>> Does the proposal significant improve the reading and writing of this
>> code? And are there other, perhaps better, ways of improving this
>> code?
>
> Maybe my tool
On Tue, Sep 11, 2018 at 04:57:16PM +0100, Jonathan Fine wrote:
> Summary: locals() and suggestion __params__ are similar, and roughly
> speaking each can be implemented from the other.
You cannot get a snapshot of the current locals just from the function
parameters, since the current locals
I wrote:
> In my opinion, the technically well-informed would prefer something
> like __args__ or __locals__ instead of __params__, for the current
> purpose.
>
> Finally, __params__ would simply be the value of __locals__ before any
> assignment has been done.
Following this up, I did a search
Summary: locals() and suggestion __params__ are similar, and roughly
speaking each can be implemented from the other. Experts / pedants
would prefer not to use the name __params__ for this purpose.
Steve D'Aprano wrote:
> I imagine it would be fairly easy to fill in such a special __params__
>
On 2018-09-11 14:20, Steven D'Aprano wrote:
On Tue, Sep 11, 2018 at 08:53:55PM +1000, Steven D'Aprano wrote:
[...]
Or perhaps we could have an officially blessed way to give tools a hint
as to what the real signature is.
class Child(Parent):
@signature_hint(Parent.method)
def
On Tue, Sep 11, 2018 at 08:53:55PM +1000, Steven D'Aprano wrote:
[...]
> Or perhaps we could have an officially blessed way to give tools a hint
> as to what the real signature is.
>
> class Child(Parent):
> @signature_hint(Parent.method)
> def method(self, **kwargs):
> pass
On Tue, Sep 11, 2018 at 9:34 PM, Steven D'Aprano wrote:
> I think that __params__ as an implicitly created local variable is
> just barely justifiable, if you don't care about slowing down all
> function calls for the benefit of a tiny number of them. But exposing
> that information as an
On Tue, Sep 11, 2018 at 04:47:37AM +, Steve Barnes wrote:
> Couldn't just about all of the use cases mentioned so far be met in
> quite a neat manner by providing access to a method, or dictionary,
> called __params__ which would give access, as a dictionary, to the
> parameters as
On Tue, Sep 11, 2018 at 10:12:56AM +0200, Chris Barker via Python-ideas wrote:
> hmm -- this is a trick -- in those cases, I find myself using *args,
> **kwargs when overloading methods. But that does hide the method signature,
> which is really unfortunate. IT works pretty well for things like
Did you mean to take this off-list? I hope not, as I'm bringing it back on.
On Tue, Sep 11, 2018 at 8:09 AM, Anders Hovmöller
wrote:
> I've spent this whole thread thinking: "who in the world is writing code
> with a lot of spam=spam arguments? If you are transferring that much state
> in a
On Mon, Sep 10, 2018 at 11:00 PM, Ethan Furman wrote:
>
> In my day job I spend a lot of time writing/customizing modules for a
> framework called OpenERP (now Odoo*). Those modules are all subclasses,
> and most work will require updating at least a couple parent methods -- so
> most calls
My 3 cents:
1. My most objective objection against the f(*, foo, bar, baz) syntax is
that it looks like positional arguments, and the syntactic marker *
which
dissuades you of that can be arbitrarily far apart from the keyword.
2. The syntax f(=foo, =bar, =baz) at least solves that
Op di 11 sep. 2018 om 06:48 schreef Steve Barnes :
>
>
> On 10/09/2018 22:00, Ethan Furman wrote:
> > On 09/10/2018 12:52 PM, Chris Barker via Python-ideas wrote:
> >
> >> I've spent this whole thread thinking: "who in the world is writing
> >> code with a lot of spam=spam arguments? If you are
On 10/09/2018 22:00, Ethan Furman wrote:
> On 09/10/2018 12:52 PM, Chris Barker via Python-ideas wrote:
>
>> I've spent this whole thread thinking: "who in the world is writing
>> code with a lot of spam=spam arguments? If you are transferring that
>> much state in a function call, maybe you
On 09/10/2018 12:52 PM, Chris Barker via Python-ideas wrote:
I've spent this whole thread thinking: "who in the world is writing code
with a lot of spam=spam arguments? If you are transferring that much
state in a function call, maybe you should have a class that holds that
state? Or pass in
On Sun, Sep 9, 2018 at 7:37 AM, Anders Hovmöller
wrote:
I've spent this whole thread thinking: "who in the world is writing code
with a lot of spam=spam arguments? If you are transferring that much state
in a function call, maybe you should have a class that holds that state? Or
pass in a
On Mon, Sep 10, 2018 at 08:05:22AM +0200, Anders Hovmöller wrote:
> I just realized I have another question for you:
Is that a generic you or just me personally? :-)
> If you had to chose which one would you prefer:
>
> f(*, a b, c)
>
> or:
>
> f(=a, =b, =c)
>
> ?
I can't say I
I just realized I have another question for you:
If you had to chose which one would you prefer:
f(*, a b, c)
or:
f(=a, =b, =c)
?
I know you’re clearly against the entire idea but it seems we should prefer the
least disliked alternative in such a scenario.
Can we all just PLEASE stop the meta-arguments enumerating logical
fallacies and recriminating about who made it personal first?!
Yes, let's discuss specific proposals and alternatives, and so on. If
someone steps out of line of being polite and professional, just ignore it.
On Sun, Sep 9, 2018,
On Sun, Sep 09, 2018 at 07:37:21AM +0200, Anders Hovmöller wrote:
>
> > You have carefully avoided explicitly accusing me of making a straw man
> > argument while nevertheless making a completely irrelevant mention of
> > it, associating me with the fallacy.
>
> I read that as him accusing you
On Sun, Sep 9, 2018 at 5:32 PM, Anders Hovmöller wrote:
>
>> I see it all the time in JavaScript, where ES2015 introduced a new
>> syntax {name} equivalent to {"name":name} - people will deliberately
>> change their variable names to match the desired object keys. So
>> saying "forcing" is an
> I see it all the time in JavaScript, where ES2015 introduced a new
> syntax {name} equivalent to {"name":name} - people will deliberately
> change their variable names to match the desired object keys. So
> saying "forcing" is an exaggeration, but a very slight one.
Do you have an opinion or
On Sun, Sep 9, 2018 at 3:37 PM, Anders Hovmöller wrote:
>
>> You have carefully avoided explicitly accusing me of making a straw man
>> argument while nevertheless making a completely irrelevant mention of
>> it, associating me with the fallacy.
>
> I read that as him accusing you very directly.
> You have carefully avoided explicitly accusing me of making a straw man
> argument while nevertheless making a completely irrelevant mention of
> it, associating me with the fallacy.
I read that as him accusing you very directly.
> That is not part of an honest or open discussion.
>
>
The proposal is to eliminate the redundancy of writing name=name
repeatedly. But IMHO it doesn't do that consistently. That is it allows
both forms mixed together, e.g.,
f(*, a, b, c=x, d, e)
I believe this is confusing in part because the * need not be near the
arguments it affects. Consider
On Sat, Sep 08, 2018 at 09:54:59PM +0200, Anders Hovmöller wrote:
[...]
[Steven (me)]
> > If we believe that this consistency is desirable then maybe this would
> > be a good thing. Linters could warn when you use "name=spam" instead of
> > "*, name"; style guides can demand that code always
On Sat, Sep 08, 2018 at 12:05:33PM +0100, Jonathan Fine wrote:
> Steve wrote:
>
> > With the usual disclaimer that I understand it will never be manditory
> > to use this syntax, nevertheless I can see it leading to the "foolish
> > consistency" quote from PEP 8.
>
> > "We have syntax to
>
> def foo():
> a, b, c = 1, 2, 3
> function(a=77, **use('b d'))
>
> foo()
> You get the output “77 None 33 None”. So basically it doesn’t work at all.
> For the reason I wrote clearly in my last mail. You have to dig through the
> stack frames to make use() work.
>
OK, you are right.
>
> I disagree. Those are examples of people being used to *positional
> arguments* and this expecting that order to carry over. I don’t think
> that’s a good argument because it presupposes that a habit of positional
> arguments is good.
>
If 99% of existing code uses:
pd.read_csv(fname,
I agree that this is a familiar pattern, but I long since forgot the
specifics of the domain it happens in. I borrowed your code, and added
filename tracking to see what source files had high
`could_have_been_a_matched_kwarg`. Here is the top one:
Le 06/09/2018 à 03:15, Anders Hovmöller a écrit :
> 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)
On Thu, Sep 06, 2018 at 07:05:57AM -0700, Anders Hovmöller wrote:
> On Thursday, September 6, 2018 at 3:11:46 PM UTC+2, Steven D'Aprano wrote:
[...]
> > But why should I feel bad about failing to
> > use the same names as the functions I call?
>
> Yea, why would you feel bad? If you should
On Sat, Sep 8, 2018, 6:34 AM Anders Hovmöller wrote:
> > A finer grained analysis tool would be helpful. I'm -0 on the idea
> because I believe it would discourage more expressive names in calling
> contexts in order to enable the proposed syntax. But I also see a big
> difference between cases
I'm not sure whether my toy function is better to assume None for a name
that is "used" but does not exist, or to raise a NameError. I can see
arguments in both directions, but either behavior is a very small number of
lines (and the same decision exists for the proposed syntax). You might
also
On Sat, Sep 8, 2018 at 9:34 AM Anders Hovmöller wrote:
> function(a=my_a, c=my_c, *, b, d)
> function(*, b, c, d, a=my_a, c=my_c)
>
Yes, those look less bad. They are also almost certainly should get this
message rather than working:
TypeError: function() got multiple values for
> A finer grained analysis tool would be helpful. I'm -0 on the idea because I
> believe it would discourage more expressive names in calling contexts in
> order to enable the proposed syntax. But I also see a big difference between
> cases where all keywords match calling names and cases
A finer grained analysis tool would be helpful. I'm -0 on the idea because
I believe it would discourage more expressive names in calling contexts in
order to enable the proposed syntax. But I also see a big difference
between cases where all keywords match calling names and cases where only a
few
> To me, the "30% of all arguments" deserves more careful examination.
> Does the proposal significant improve the reading and writing of this
> code? And are there other, perhaps better, ways of improving this
> code?
Maybe my tool should be expanded to produce more nuanced data? Like how many
Steve wrote:
> With the usual disclaimer that I understand it will never be manditory
> to use this syntax, nevertheless I can see it leading to the "foolish
> consistency" quote from PEP 8.
> "We have syntax to write shorter code, shorter code is better,
> so if we want to be Pythonic
> *At* two arguments? As in this example?
>
>map(len, sequence)
>
>
> I'll admit that I struggle to remember the calling order of list.insert,
> I never know which of these I ought to write:
>
>mylist.insert(0, 1)
>mylist.insert(1, 0)
>
> but *in general* I don't think two
On Fri, Sep 07, 2018 at 10:39:07AM +1200, Greg Ewing wrote:
> As for whether consistent naming is a good idea, seems to
> me it's the obvious thing to do when e.g. you're overriding
> a method, to keep the signature the same for people who want
> to pass arguments by keyword. You'd need to have a
On Fri, Sep 07, 2018 at 06:59:45AM -0700, Anders Hovmöller wrote:
> Personally I think readability suffers greatly already at two arguments if
> none of the parameters are named.
*At* two arguments? As in this example?
map(len, sequence)
I'll admit that I struggle to remember the calling
On Fri, Sep 7, 2018 at 2:22 PM Rhodri James wrote:
>
> Top posting for once, since no one is quoting well in this thread:
>
> Does this in any way answer David's question? I'm serious; you've spent
> a lot of words that, as best I can tell, say exactly nothing about how
> keyword arguments would
Top posting for once, since no one is quoting well in this thread:
Does this in any way answer David's question? I'm serious; you've spent
a lot of words that, as best I can tell, say exactly nothing about how
keyword arguments would help that quadratic function. If I'm missing
something,
Do you want to change my PEP suggestion to be about forcing stuff? Because
otherwise I don’t see why you keep being that up. We’ve explained to you two
times (three counting the original mail) that no one is saying anything about
forcing anything. ___
If you want to force using pos args, go ahead and use Python docstring
notation we'd write def quad(a,b,c, /)
The names should not be renamed because they already have a normal ordering
x ** n.
This notation is standard, so it would be a shame to use something people
don't use.
However, I
Here's a function found online (I'm too lazy to write my own, but it would
be mostly the same). Tell me how keyword arguments could help this... Or
WHAT names you'd give.
1. def quad(a,b,c):
2. """solves quadratic equations of the form
3. aX^2+bX+c, inputs a,b,c,
4. works for all
>
>
> I disagree. Keyword arguments are a fine and good thing, but they are
> best used for optional arguments IMHO. Verbosity for the sake of
> verbosity is not a good thing.
I disagree, when you have more than one parameter it's sometimes
complicated to remember the order. Therefore, when
On Fri, Sep 7, 2018, 12:00 AM Jacco van Dorp wrote:
> Sometimes we make a function only to be called once at a specific
> location, more because of factoring out some functions for clarity.
>
I've found myself making the opposite refactoring recently, improving
clarity by eliminating
On 07/09/18 14:59, Anders Hovmöller wrote:
I disagree. Keyword arguments are a fine and good thing, but they are
best used for optional arguments IMHO. Verbosity for the sake of
verbosity is not a good thing.
Hmm.. it seems to me like there are some other caveats to your position
here. Like
>
> I counted commas. I came up with the wrong number. Simple.
>
> For what it's worth, I don't like the keyword-only marker or the
> proposed positional-only marker for exactly the same reason.
>
There's also potentially trailing commas to confuse you further :P
I'm not a big fan of the
On 07/09/18 03:38, Anders Hovmöller wrote:
For comparison, my reaction did indeed involve awe. It was full of it,
in fact :-p Sorry, but that syntax looks at best highly misleading --
how many parameters are we passing? I don't like it at all.
(nitpick: we're passing arguments, not
> I must say I like the idea of being able to write it the way you propose.
> Sometimes we make a function only to be called once at a specific location,
> more because of factoring out some functions for clarity. Been doing that
> myself lately for scripting, and I think it'd increase
Op vr 7 sep. 2018 om 04:49 schreef Anders Hovmöller :
>
> Maybe something like this would be better:
>>
>> f(=a, =b, =c)
>>
>
> Haha. Look at my PEP, it's under "rejected alternative syntax", because of
> the super angry replies I got on this very mailing list when I suggested
> this syntax a
> Maybe something like this would be better:
>
> f(=a, =b, =c)
>
Haha. Look at my PEP, it's under "rejected alternative syntax", because of
the super angry replies I got on this very mailing list when I suggested
this syntax a few years ago :P
I think that syntax is pretty nice
> For calling, we can use
> https://docs.python.org/3/library/functions.html#locals
>
> >>> lcls = locals()
>
> >>> a = 'apple'
> >>> b = 'banana'
> >>> c = 'cherry'
>
> >>> dict((k, lcls[k]) for k in ('a', 'b', 'c'))
> {'b': 'banana', 'c': 'cherry',
On Thursday, September 6, 2018 at 6:51:12 PM UTC+2, Ethan Furman wrote:
>
> On 09/06/2018 07:05 AM, Anders Hovmöller wrote:
> > On Thursday, September 6, 2018 at 3:11:46 PM UTC+2, Steven D'Aprano
> wrote:
> >> On Thu, Sep 06, 2018 at 12:15:46PM +0200, Anders Hovmöller wrote:
>
> >>> Wouldn't it
>
>
> For comparison, my reaction did indeed involve awe. It was full of it,
> in fact :-p Sorry, but that syntax looks at best highly misleading --
> how many parameters are we passing? I don't like it at all.
>
(nitpick: we're passing arguments, not parameters)
I don't see how this could
On Thursday, September 6, 2018 at 4:13:45 PM UTC+2, David Mertz wrote:
>
> Steven's point is the same as my impression. It's not terribly uncommon in
> code I write or read to use the same name for a formal parameter (whether
> keyword or positional) in the calling scope. But it's also far
Rhodri James wrote:
that syntax looks at best highly misleading --
how many parameters are we passing? I don't like it at all.
Maybe something like this would be better:
f(=a, =b, =c)
Much more suggestive that you're passing a keyword argument.
As for whether consistent naming is a good
On Thu, 6 Sep 2018 at 09:51 Ethan Furman wrote:
> On 09/06/2018 07:05 AM, Anders Hovmöller wrote:
> > On Thursday, September 6, 2018 at 3:11:46 PM UTC+2, Steven D'Aprano
> wrote:
> >> On Thu, Sep 06, 2018 at 12:15:46PM +0200, Anders Hovmöller wrote:
>
> >>> Wouldn't it be awesome if [...]
> >>
>
Summary: I addressed the DEFINING problem. My mistake. Some rough
ideas for the CALLING problem.
Anders has kindly pointed out to me, off-list, that I solved the wrong
problem. His problem is CALLING the function fn, not DEFINING fn.
Thank you very much for this, Anders.
For calling, we can use
I missed an important line of code. Here it is:
>>> aaa = 'telltale'
Once you have that, these will work:
>>> eval('aaa', fn.__globals__)
'telltale'
>>> __name__
'__main__'
>>> import sys
>>> getattr(sys.modules[__name__], 'aaa')
'telltale'
--
On 09/06/2018 07:05 AM, Anders Hovmöller wrote:
On Thursday, September 6, 2018 at 3:11:46 PM UTC+2, Steven D'Aprano wrote:
On Thu, Sep 06, 2018 at 12:15:46PM +0200, Anders Hovmöller wrote:
Wouldn't it be awesome if [...]
No.
Heh. I did expect the first mail to be uncivil :P
Direct
Hi Anders
Thank you for your interesting message. I'm sure it's based on a real
need. You 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
On 06/09/18 15:05, Anders Hovmöller wrote:
On Thursday, September 6, 2018 at 3:11:46 PM UTC+2, Steven D'Aprano 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.
Steven's point is the same as my impression. It's not terribly uncommon in
code I write or read to use the same name for a formal parameter (whether
keyword or positional) in the calling scope. But it's also far from
universal. Almost all the time where it's not the case, it's for a very
good
On Thursday, September 6, 2018 at 3:11:46 PM UTC+2, Steven D'Aprano 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
>
Sorry, nevermind. I think I misunderstood the idea.
On Thu, Sep 6, 2018 at 9:56 AM Todd wrote:
> I have encountered situations like this, and generally I just use **kwargs
> for non-critical and handle the parameter management in the body of the
> function.
>
> This also makes it easier to
I have encountered situations like this, and generally I just use **kwargs
for non-critical and handle the parameter management in the body of the
function.
This also makes it easier to pass the arguments to another function. You
can use a dict comprehension to copy over the keys you want, then
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
On Thu, Sep 6, 2018 at 9:11 AM Steven D'Aprano 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:
> >
> >
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:
>
>
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? This would not just be
82 matches
Mail list logo
