On Sunday, 9 September 2018 06:30:19 UTC+1, Steven D'Aprano wrote:
>
> On Sat, Sep 08, 2018 at 04:33:07AM -0700, Paddy3118 wrote:
> > I wrote a blog post
> > <
> http://paddy3118.blogspot.com/2009/07/case-of-disappearing-over-bar.html>nearly
>
>
> > a decade ago on extending a Rosetta Code ta
Hi,
I implemented the inheritance via meta classes and function and class
attributes for pre/postconditions and invariants, respectively. Unless I
missed something, this is as far as we can go without the proper language
support with a library based on decorators:
https://github.com/Parquery/icont
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 particularly
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 **kwarg
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 a
[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 general for the community to be able to try
out ideas and mull things over.
If there was something like a Python F
That looks great to me! I also think the '/' syntax looks fine and the pun
works. If part of the motivation for position-only arguments was better
performance and that motivation still holds water, then it makes sense to
allow Python to support that optimization, but I would be happy with just a
de
[Cameron Simpson]
> I've been writing quite a few functions lately where it is reasonable for
> a
> caller to want to pass arbitrary keyword arguments, but where I also want
> some
> additional parameters for control purposes.
I've run into this before and use the trailing '_' convention for nam
This has been bouncing around in my head for a while regarding the
requisite keys() method on mappings:
How come the ** unpacking operator, a built-in language feature, relies on
a non-dunder to operate?
To me, I mean to say, requiring that classes implement keys() – a method
whose name is totall
I can see custom mapping types where iterating the keys() would be trivial, but
items() could be expensive. I could use that as an argument, but I don't have
to. The keys() method is part of the API, just like index() and count() are
part of the sequence API. To be treated like a mapping every
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 s
11.09.18 05:04, Elias Tarhini пише:
This has been bouncing around in my head for a while regarding the
requisite keys() method on mappings:
How come the ** unpacking operator, a built-in language feature, relies
on a non-dunder to operate?
To me, I mean to say, requiring that classes impleme
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 tr
13 matches
Mail list logo
