On Fri, Jun 25, 2021 at 1:54 PM Ricky Teachey wrote:
>
> Would this feature allow me to declare str objects as not iterable in some
> contexts?
>
> If so, +1.
>
That depends. If the proposal is to intercept every attribute lookup
(parallel to a class's __getattribute__ method), then yes, but if
I've read all the posts in this thread, and am overall at least -0.5 on the
idea. I like methods well enough, but mostly it just seems to invite
confusion versus the equivalent and existing option of importing functions.
I am happy, initially, to stipulate that "some clever technique" is
Would this feature allow me to declare str objects as not iterable in some
contexts?
If so, +1.
On Thu, Jun 24, 2021, 3:22 PM Chris Angelico wrote:
> On Fri, Jun 25, 2021 at 3:31 AM Steven D'Aprano
> wrote:
> >
> > Here's a quick and dirty proof of concept I knocked up in about 20
> >
On Fri, Jun 25, 2021 at 3:31 AM Steven D'Aprano wrote:
>
> Here's a quick and dirty proof of concept I knocked up in about 20
> minutes, demonstrating that no deep compiler magic is needed. It's just
> a small change to the way `object.__getattribute__` works.
>
> I've emulated it with my own
Here's a quick and dirty proof of concept I knocked up in about 20
minutes, demonstrating that no deep compiler magic is needed. It's just
a small change to the way `object.__getattribute__` works.
I've emulated it with my own base class, since `object` can't be
monkey-patched.
The proof of
On Thu, Jun 24, 2021 at 09:19:36AM -0700, Christopher Barker wrote:
> Steven, you're making a pretty good case here, but a couple questions:
>
> 1) The case of newer versions of python adding methods to builtins, like
> .bit_length is really compelling. But I do wonder how frequently that comes
On Thu, Jun 24, 2021 at 12:17:17AM +1000, Chris Angelico wrote:
> On Wed, Jun 23, 2021 at 11:25 PM Steven D'Aprano wrote:
> > To a first approximation (ignoring shadowing) every dot lookup can be
> > replaced with getattr and vice versa:
> >
> > obj.name <--> getattr(obj, 'name')
> >
> > A
On 2021-06-24 09:19:36, Christopher Barker wrote:
> No -- we're not assuming Python users are idiots -- there is an important
> difference here:
>
> from extensions import flatten
> flatten(mylist)
>
> very clearly adds the name `flatten` to the current module namespace. That
> itself
Steven, you're making a pretty good case here, but a couple questions:
1) The case of newer versions of python adding methods to builtins, like
.bit_length is really compelling. But I do wonder how frequently that comes
up. It seems to me on this list, that people are very reluctant to add
On 24/06/2021 12:44, Richard Damon wrote:
On 6/24/21 7:09 AM, Simão Afonso wrote:
On 2021-06-24 20:59:31, Steven D'Aprano wrote:
Seriously, there's a time to realise when arguments against a feature
devolve down to utterly spurious claims that Python programmers are
idiots who will be
On 6/24/21 7:09 AM, Simão Afonso wrote:
> On 2021-06-24 20:59:31, Steven D'Aprano wrote:
>> Seriously, there's a time to realise when arguments against a feature
>> devolve down to utterly spurious claims that Python programmers are
>> idiots who will be confused by:
>>
>> from extensions
On 2021-06-24 20:59:31, Steven D'Aprano wrote:
> Seriously, there's a time to realise when arguments against a feature
> devolve down to utterly spurious claims that Python programmers are
> idiots who will be confused by:
>
> from extensions use flatten
> mylist.flatten()
>
> but can
On Wed, Jun 23, 2021 at 11:22:26AM -0700, Brendan Barnwell wrote:
> On 2021-06-23 03:02, Steven D'Aprano wrote:
> >Attribute lookups are just another form of name lookup. Name lookups
> >depend on the current execution scope, not the caller's scope. With
> >extension methods, so do attribute
On Thu, Jun 24, 2021 at 7:51 PM Steven D'Aprano wrote:
>
> I'm not sure if you completely understand the use-case I was describing,
> so let me clarify for you with a concrete example.
>
> Ints have a "bit_length" method, starting from Python 2.7. I needed to
> use that method going all the way
Oops, sorry, I neglected to trim my response to João. Please ignore my
previous response, with the untrimmed quoting at the start, and give any
replies to this.
On Wed, Jun 23, 2021 at 07:23:19PM +0200, João Santos wrote:
> Of course that means the the standard library might also introduce
On Wed, Jun 23, 2021 at 07:23:19PM +0200, João Santos wrote:
>
>
> On Wed, Jun 23 2021 at 20:48:39 +1000, Steven D'Aprano
> wrote:
> >I've just thought of a great use-case for extension methods.
> >
> >Hands up who has to write code that runs under multiple versions of
> >Python? *raises my
I've read the PEP and understand what's implemented. However there is pretty
limited discussion about what the design constraints were and what
intended/recommended usage would look like. I'll answer my own question:
1. If all we wanted was a version of TLS that worked in an analogous way
17 matches
Mail list logo
