On Wed, Jun 23, 2021 at 11:40 AM Steven D'Aprano wrote:
>
> On Tue, Jun 22, 2021 at 10:25:33PM +1000, Chris Angelico wrote:
>
> > > If its a problem for getattr, it is a problem for dot syntax, because
> > > they are essentially the same thing.
> >
> > Ahh but that is precisely the problem.
>
>
On Tue, Jun 22, 2021 at 10:25:33PM +1000, Chris Angelico wrote:
> > If its a problem for getattr, it is a problem for dot syntax, because
> > they are essentially the same thing.
>
> Ahh but that is precisely the problem.
Is it? Don't be shy. Tell us what the problem is and why its a problem.
On 2021-06-22 8:11 p.m., Chris Angelico wrote:
> On Wed, Jun 23, 2021 at 9:06 AM Soni L. wrote:
> > On 2021-06-22 7:38 p.m., Chris Angelico wrote:
> > > Have you actually tried designing this into a larger project to see
> > > what problems you run into, or is this something you've only
> > >
On Wed, Jun 23, 2021 at 9:06 AM Soni L. wrote:
> On 2021-06-22 7:38 p.m., Chris Angelico wrote:
> > Have you actually tried designing this into a larger project to see
> > what problems you run into, or is this something you've only
> > considered at this trivial level?
>
> 1. It's opt-in.
> 2.
On 2021-06-22 7:38 p.m., Chris Angelico wrote:
> On Wed, Jun 23, 2021 at 8:30 AM Soni L. wrote:
> >
> >
> >
> > On 2021-06-22 5:54 p.m., Chris Angelico wrote:
> > > On Wed, Jun 23, 2021 at 6:41 AM Soni L. wrote:
> > > > It would have local scope, similar to uh... locals. Y'know how locals
> >
On Wed, Jun 23, 2021 at 8:30 AM Soni L. wrote:
>
>
>
> On 2021-06-22 5:54 p.m., Chris Angelico wrote:
> > On Wed, Jun 23, 2021 at 6:41 AM Soni L. wrote:
> > > It would have local scope, similar to uh... locals. Y'know how locals
> > > are just sugar for locals()['foo'] and stuff? Yeah.
> >
> >
On 2021-06-22 5:34 p.m., Brendan Barnwell wrote:
> On 2021-06-22 13:09, Soni L. wrote:
>> Think about it like this, extension methods give you the ability to make
>> imported functions that look like this:
>>
>> foo(bar, baz)
>>
>> look like this instead:
>>
>> bar.foo(baz)
>>
>> That's all
On 2021-06-22 5:54 p.m., Chris Angelico wrote:
> On Wed, Jun 23, 2021 at 6:41 AM Soni L. wrote:
> >
> >
> >
> > On 2021-06-22 5:23 p.m., Chris Angelico wrote:
> > > On Wed, Jun 23, 2021 at 6:13 AM Soni L. wrote:
> > > > Think about it like this, extension methods give you the ability to make
>
On Wed, Jun 23, 2021 at 6:41 AM Soni L. wrote:
>
>
>
> On 2021-06-22 5:23 p.m., Chris Angelico wrote:
> > On Wed, Jun 23, 2021 at 6:13 AM Soni L. wrote:
> > > Think about it like this, extension methods give you the ability to make
> > > imported functions that look like this:
> > >
> > >
On 2021-06-22 13:09, Soni L. wrote:
Think about it like this, extension methods give you the ability to make
imported functions that look like this:
foo(bar, baz)
look like this instead:
bar.foo(baz)
That's all there is to them. They're just a lie to change how you
read/write the code. Some
On 2021-06-22 5:23 p.m., Chris Angelico wrote:
> On Wed, Jun 23, 2021 at 6:13 AM Soni L. wrote:
> > Think about it like this, extension methods give you the ability to make
> > imported functions that look like this:
> >
> > foo(bar, baz)
> >
> > look like this instead:
> >
> > bar.foo(baz)
> >
On Wed, Jun 23, 2021 at 6:13 AM Soni L. wrote:
> Think about it like this, extension methods give you the ability to make
> imported functions that look like this:
>
> foo(bar, baz)
>
> look like this instead:
>
> bar.foo(baz)
>
> That's all there is to them. They're just a lie to change how you
On 2021-06-22 3:43 p.m., Brendan Barnwell wrote:
> On 2021-06-22 05:14, Chris Angelico wrote:
>> Fair point. However, I've worked with a good number of languages that
>> have some notion of object methods, and generally, an object has or
>> doesn't have a method based on what the object*is*, not
On 2021-06-22 05:14, Chris Angelico wrote:
Fair point. However, I've worked with a good number of languages that
have some notion of object methods, and generally, an object has or
doesn't have a method based on what the object*is*, not on who's
asking.
I agree, and this is the aspect of the
On 2021-06-22 9:25 a.m., Chris Angelico wrote:
> (Oh, and another wrinkle, although a small one: Code objects would
> need to keep track of their modules. Currently functions do, but code
> objects don't. But that seems unlikely to introduce further
> complications.)
What? No you just stop
On Tue, Jun 22, 2021 at 9:56 PM Steven D'Aprano wrote:
>
> On Tue, Jun 22, 2021 at 09:12:53PM +1000, Chris Angelico wrote:
>
> > > The must be no semantic difference between:
> > >
> > > obj.method(arg)
> > >
> > > and
> > >
> > > getattr(obj, 'method')(arg)
> > >
> > > regardless of
Off-topic
Someone on this list wrote:
Mu.
>
> https://en.wikipedia.org/wiki/Mu_(negative)#%22Unasking%22_the_question
This is a koan, a device in Zen Buddhism used by a teacher to help the
student liberate themselves from being imprisoned by rational discursive
thought.
Here is another koan.
On Tue, Jun 22, 2021 at 9:23 PM Steven D'Aprano wrote:
>
> On Tue, Jun 22, 2021 at 05:50:48PM +1000, Chris Angelico wrote:
>
> > Hmm, that's not what I'd usually understand "encapsulation" to mean.
> > That's what would normally be called "namespacing".
>
> Pfft, who you going to believe, me or
On Tue, Jun 22, 2021 at 09:12:53PM +1000, Chris Angelico wrote:
> > The must be no semantic difference between:
> >
> > obj.method(arg)
> >
> > and
> >
> > getattr(obj, 'method')(arg)
> >
> > regardless of whether `method` is a regular method or an extension
> > method.
>
> And this is a
Oh this is a long one.
Hypothetically, let's say you have a proxy object:
class Foo:
def __getattribute__(self, thing):
return getattr(super().__getattribute__(self, "proxied"), thing)
Should this really include extension methods into it by default?
This is clearly wrong. The local
On Tue, Jun 22, 2021 at 05:50:48PM +1000, Chris Angelico wrote:
> Hmm, that's not what I'd usually understand "encapsulation" to mean.
> That's what would normally be called "namespacing".
Pfft, who you going to believe, me or some random folx on the internet
editing Wikipedia? *wink*
Okay,
On Tue, Jun 22, 2021 at 8:01 PM Steven D'Aprano wrote:
> The whole point of extension methods is that once the caller opts in to
> use them, method look ups (and that includes hasattr and getattr) must
> work as if the extension methods **are in place**.
>
> The must be no semantic difference
I'm sorry Soni, I don't understand what you are arguing here. See below.
On Mon, Jun 21, 2021 at 10:09:17PM -0300, Soni L. wrote:
>
>
> 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
As someone who originally worked on implementing PEP 448, I wanted to chime
in that while I agreed with the decision to be conservative when adding new
features, I originally hoped that [*x for x in xs] would eventually make
its way into Python. To me, it seemed intuitive and I hoped people
On Tue, Jun 22, 2021 at 10:40 AM Steven D'Aprano wrote:
> > True, all true, but considering that this is *not* actually part of
> > the class, some of that doesn't really apply. For instance, is it
> > really encapsulation? What does that word even mean when you're
> > injecting methods in from
25 matches
Mail list logo
