Yury Selivanov wrote:
> On Mon, Jun 21, 2021 at 7:20 PM Mark Gordon msg...@gmail.com 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
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
> 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 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
>
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 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;
> 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
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
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
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 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 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 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 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: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 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.
>
> 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 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
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
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
20 matches
Mail list logo
