Soni L. writes:
> The trick to extension methods is that they're only available when you
> explicitly use them.
What does "explicitly use them" mean? How does this help avoid the
kinds of problems we know that monkey-patching causes?
___
Python-ideas
On 2021-06-21 12:26 p.m., Stephen J. Turnbull wrote:
> Soni L. writes:
>
> > The trick to extension methods is that they're only available when you
> > explicitly use them.
>
> What does "explicitly use them" mean? How does this help avoid the
> kinds of problems we know that monkey-patching c
On Tue, Jun 22, 2021 at 1:44 AM Soni L. wrote:
>
>
>
> On 2021-06-21 12:26 p.m., Stephen J. Turnbull wrote:
> > Soni L. writes:
> >
> > > The trick to extension methods is that they're only available when you
> > > explicitly use them.
> >
> > What does "explicitly use them" mean? How does this
>
> If there is a problem to solve here it's that people want to
> concatenate things and reach out to the sum function because the
> concatenate function doesn't exist.
But that’s not the problem here — sum IS concatenation for any type for
which __add__ means concatonate.
The problem is that c
On Tue, Jun 22, 2021 at 01:49:56AM +1000, Chris Angelico wrote:
> So what you're saying is that, in effect, every attribute lookup has
> to first ask the object itself, and then ask the module? Which module?
> The one that the code was compiled in? The one that is currently
> running? Both?
Mu.
On Tue, Jun 22, 2021 at 3:43 AM Steven D'Aprano wrote:
>
> On Tue, Jun 22, 2021 at 01:49:56AM +1000, Chris Angelico wrote:
>
> > So what you're saying is that, in effect, every attribute lookup has
> > to first ask the object itself, and then ask the module? Which module?
> > The one that the code
On 2021-06-21 12:49 p.m., Chris Angelico wrote:
> On Tue, Jun 22, 2021 at 1:44 AM Soni L. wrote:
> >
> >
> >
> > On 2021-06-21 12:26 p.m., Stephen J. Turnbull wrote:
> > > Soni L. writes:
> > >
> > > > The trick to extension methods is that they're only available when you
> > > > explicitly u
On Tue, Jun 22, 2021 at 3:55 AM Soni L. wrote:
>
>
>
> On 2021-06-21 12:49 p.m., Chris Angelico wrote:
> > On Tue, Jun 22, 2021 at 1:44 AM Soni L. wrote:
> > >
> > >
> > >
> > > On 2021-06-21 12:26 p.m., Stephen J. Turnbull wrote:
> > > > Soni L. writes:
> > > >
> > > > > The trick to extension
On 2021-06-21 3:01 p.m., Chris Angelico wrote:
> Thanks for clarifying. This doesn't change the problem though - it
> just changes where the issue shows up. (BTW, what you're describing is
> closer to __getattribute__ than it is to __getattr__, so if you're
> proposing this as the semantics, I st
On Mon, Jun 21, 2021 at 3:28 PM Soni L. wrote:
>
>
>
> For exec/eval you just pass in the locals:
>
> exec(foo, globals(), locals())
>
> because this __getattribute__ is just a local like any other.
>
> As for each module, you'd import them. But not quite with "import":
>
> import extension_metho
On Mon, Jun 21, 2021 at 02:54:52PM -0300, Soni L. wrote:
> Quite the opposite. You ask the local module (the one that the code was
> compiled in), and the module decides whether/when to ask the object itself.
>
> In other words, every
>
> foo.bar
>
> would be sugar for
>
> __getattr__(foo, "ba
On 2021-06-21 8:42 p.m., Steven D'Aprano wrote:
> On Mon, Jun 21, 2021 at 02:54:52PM -0300, Soni L. wrote:
>
> > Quite the opposite. You ask the local module (the one that the code was
> > compiled in), and the module decides whether/when to ask the object itself.
> >
> > In other words, every
It seems odd that it would be per module and not per scope?
On Tue, 22 Jun 2021, 00:55 Soni L., wrote:
>
>
> On 2021-06-21 8:42 p.m., Steven D'Aprano wrote:
> > On Mon, Jun 21, 2021 at 02:54:52PM -0300, Soni L. wrote:
> >
> > > Quite the opposite. You ask the local module (the one that the code
> However this is not exactlly the same as the task will inherit a copy of
my_context rather than running directly on my_context.
Yeah, it would indeed inherit the copy. We could, theoretically, make
asyncio.Task accept context objects and not copy them, but what would that
give us? If a coroutine
On Tue, Jun 22, 2021 at 03:56:00AM +1000, Chris Angelico wrote:
> I'm actually not concerned so much with the performance as the
> confusion. What exactly does the registration apply to?
Good question.
Extension methods have four steps:
- you write a method;
- declare which class it extends;
On 2021-06-21 8:57 p.m., Thomas Grainger wrote:
> It seems odd that it would be per module and not per scope?
It's unusual to import things at the scope level. Usually things get
imported at the module level, so, using module language doesn't seem
that bad.
But yes, it's per scope, but in pract
On 2021-06-21 9:39 p.m., Steven D'Aprano wrote:
>
> Fourth step is that you go ahead and use lists as normal. Whether you
> use getattr or dot syntax, any extension methods defined in spam.py will
> show up, as if they were actual list methods.
>
> hasattr([], 'head') # returns True
>
> Yeah, it would indeed inherit the copy. We could, theoretically, make
> asyncio.Task accept context objects and not copy them, but what would that
> give us?
My main thinking was to just be similar to the closest synchronous analog I'm
aware of, contextvars.Context.run. I would think an explana
On Mon, Jun 21, 2021 at 7:20 PM Mark Gordon wrote:
> > Yeah, it would indeed inherit the copy. We could, theoretically, make
> > asyncio.Task accept context objects and not copy them, but what would
> that
> > give us?
>
> My main thinking was to just be similar to the closest synchronous analog
Yury Selivanov wrote:
> On Mon, Jun 21, 2021 at 7:20 PM Mark Gordon [email protected] wrote:
> > Yeah, it would indeed inherit the copy. We could, theoretically, make
> > asyncio.Task accept context objects and not copy them, but what would
> > that
> > give us?
> > My main thinking was to just be s
20 matches
Mail list logo
