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 problem
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 look
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 func
I hope that in this thread we will share and develop our understanding
of how Python handles the interface between defining a function and
calling a function.
In this message, I describe a tension between the caller and
implementer of a function. I intend in further messages to cover
Elias Ta
Op di 11 sep. 2018 om 10:42 schreef Brice Parent :
> Le 11/09/2018 à 02:15, Abe Dillon a écrit :
>
> [Steven D'Aprano]
>
>> It would be great for non-C coders to be able to prototype proposed
>> syntax changes to get a feel for what works and what doesn't.
>
>
> I think it would be great in genera
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 GU
I wholly support this proposal.
___
Python-ideas mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
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 supplied
On Tue, Sep 11, 2018 at 8:03 PM, Jonathan Fine wrote:
> In some case, the implementer might prefer
>
> def method(self, aaa, bbb, **kwargs):
>
> # Do something with aaa and bbb.
> super().method(**kwargs)
>
>
> However, the CALLER might wish that the implementer has a signature
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 external
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
Here
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 method(s
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__
> lo
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 f
Gallian Colombeau wrote on 8/27/18 06:49:
As I understand, for a package to allow being extended in this way, it
must be a namespace package and not contain a marker file. As a matter
of fact, no sub-package until the top level package can have a marker file:
No, that's not true.
However, wh
15 matches
Mail list logo
