Steven D'Aprano wrote:
I'm arguing with those who insist that objects of type MethodType aren't
methods, and objects of type FunctionType aren't functions but methods,
except when they are, based on that simplified, incomplete glossary entry.
I'm not arguing that based on the glossary entry. I
Steven D'Aprano wrote:
Er, perhaps "code injection" is not the best name for this, on account of it
also being the name for a security vulnerability anti-pattern:
I'm talking about a variety of dependency injection where you either add an
entirely new method to an instance, or give the instan
Steven D'Aprano wrote:
Gregory Ewing wrote:
If things worked the way you want, it would be
impossible to store a function in an instance
attribute and get it out again *without* it
being treated as a method
>
Not impossible, just inconvenient... the
solution is to use a custom descriptor
Bu
On Tuesday, February 3, 2015 at 4:05:57 PM UTC-6, Ian wrote:
> On Tue, Feb 3, 2015 at 10:40 AM, Steven D'Aprano wrote:
> > AT LONG LAST THE LIGHT DAWNS! THE PENNY DROPS!
>
> Careful there, you're starting to sound like Ranting Rick. ;-)
Ha! My meme's are far more catchy and intellectual. But as t
Gregory Ewing wrote:
> Marko Rauhamaa wrote:
>> Right now Python generates the trampoline from the class prototype every
>> time you call a method. If the semantics allowed, you could create the
>> trampoline at instantiation time (for better or worse). That way, the
>> problem you seem to be refe
Gregory Ewing wrote:
> Marko Rauhamaa wrote:
>> For (almost) all practical purposes, that is the Python way as well. If
>> object instantiation (conceptually) copied the class's methods into the
>> object's dict, you'd get the semantics I'm looking for.
>
> If things worked the way you want, it w
On 02/03/2015 03:32 PM, Marko Rauhamaa wrote:
> Gregory Ewing :
>
>> You seem to be suggesting an optimisation that pre-creates bound
>> methods when the instance is created. Keeping a cache of bound methods
>> would achieve the same thing without changing the semantics. I think
>> CPython might a
On 03/02/2015 23:32, Marko Rauhamaa wrote:
Gregory Ewing :
You seem to be suggesting an optimisation that pre-creates bound
methods when the instance is created. Keeping a cache of bound methods
would achieve the same thing without changing the semantics. I think
CPython might already be doing
On Wed, Feb 4, 2015 at 10:32 AM, Marko Rauhamaa wrote:
> No, I'm saying Python should behave differently.
>
> Python:
>
>>>> class A:
>...def f(self):
>... print("f")
>...def g(self):
>... print("g")
>...
>>>> a = A()
>>>> a.__class__.f = a.__cla
Gregory Ewing :
> You seem to be suggesting an optimisation that pre-creates bound
> methods when the instance is created. Keeping a cache of bound methods
> would achieve the same thing without changing the semantics. I think
> CPython might already be doing that, but I'm not sure.
No, I'm sayin
Marko Rauhamaa wrote:
Right now Python generates the trampoline from the class prototype every
time you call a method. If the semantics allowed, you could create the
trampoline at instantiation time (for better or worse). That way, the
problem you seem to be referring to wouldn't materialize.
S
On Wed, Feb 4, 2015 at 4:40 AM, Steven D'Aprano
wrote:
> given that the glossary need not be 100% complete and definitive, "function
> defined inside a class body" is close enough to the truth.
* This *
We are arguing, not about an element in a formal grammar, but about a
glossary entry. If one
On Tue, Feb 3, 2015 at 10:40 AM, Steven D'Aprano
wrote:
> AT LONG LAST THE LIGHT DAWNS! THE PENNY DROPS!
Careful there, you're starting to sound like Ranting Rick. ;-)
--
https://mail.python.org/mailman/listinfo/python-list
Steven D'Aprano wrote:
If some methods can be defined outside of the body of a class, then being
defined inside the body of a class does not define a method.
Nobody's disputing that. The business about super() is
just a possible reason for the glossary to define the
word 'method' in a more rest
Gregory Ewing :
> Marko Rauhamaa wrote:
>> For (almost) all practical purposes, that is the Python way as well. If
>> object instantiation (conceptually) copied the class's methods into the
>> object's dict, you'd get the semantics I'm looking for.
>
> If things worked the way you want, it would b
Marko Rauhamaa wrote:
For (almost) all practical purposes, that is the Python way as well. If
object instantiation (conceptually) copied the class's methods into the
object's dict, you'd get the semantics I'm looking for.
If things worked the way you want, it would be
impossible to store a func
Devin Jeanpierre wrote:
> On Mon, Feb 2, 2015 at 6:07 AM, Steven D'Aprano
> wrote:
>> Run this code:
>>
>> # === cut ===
>>
>> class K(object):
>> def f(self): pass
>>
>> def f(self): pass
>>
>> instance = K()
>> things = [instance.f, f.__get__(instance, K)]
>> from random import shuffle
>> s
Steven D'Aprano wrote:
In Python 2, they are methods. In Python 3, they are functions, and aren't
converted into methods until you access them via the instance:
They're methods in both cases. They don't have to be
"converted into methods"; they already are, by virtue
of their location and inte
Steven D'Aprano wrote:
Both K.f and K.g are methods, even though only one meets the definition
given in the glossary. The glossary is wrong.
Or rather, it is not so much that it is *wrong*, but that it is incomplete
and over-simplified.
I agree with that; a more complete definition would be
"a
Chris Angelico :
> On Tue, Feb 3, 2015 at 9:38 PM, Marko Rauhamaa wrote:
>> It's slightly sad that Python exposes the two-level attribute lookup.
>> It would be more elegant if, conceptually, all methods were retrieved
>> from the object's attribute dict. That way, the class would be simply
>> a
On Tue, Feb 3, 2015 at 9:38 PM, Marko Rauhamaa wrote:
> It's slightly sad that Python exposes the two-level attribute lookup. It
> would be more elegant if, conceptually, all methods were retrieved from
> the object's attribute dict. That way, the class would be simply a
> mundane optimization tri
Devin Jeanpierre :
> It isn't mystical. There are differences in semantics of defining
> methods inside or outside of a class that apply in certain situations
> (e.g. super(), metaclasses). You have cherrypicked an example that
> avoids them.
It's slightly sad that Python exposes the two-level at
On Mon, Feb 2, 2015 at 6:20 AM, Steven D'Aprano
wrote:
> Devin Jeanpierre wrote:
>> Oops, I just realized why such a claim might be made: the
>> documentation probably wants to be able to say that any method can use
>> super(). So that's why it claims that it isn't a method unless it's
>> defined
On Mon, Feb 2, 2015 at 6:07 AM, Steven D'Aprano
wrote:
> Run this code:
>
> # === cut ===
>
> class K(object):
> def f(self): pass
>
> def f(self): pass
>
> instance = K()
> things = [instance.f, f.__get__(instance, K)]
> from random import shuffle
> shuffle(things)
> print(things)
>
> # === c
Devin Jeanpierre wrote:
> Oops, I just realized why such a claim might be made: the
> documentation probably wants to be able to say that any method can use
> super(). So that's why it claims that it isn't a method unless it's
> defined inside a class body.
You can use super anywhere, including
Devin Jeanpierre wrote:
> On Mon, Feb 2, 2015 at 4:06 AM, Steven D'Aprano
> wrote:
>> instance.f is a method by the glossary definition. Its type is identical
>> to types.MethodType, which is what I used to create a method by hand.
>
> You are assuming that they are both methods, just because t
On Mon, Feb 2, 2015 at 5:00 AM, Devin Jeanpierre wrote:
> On Mon, Feb 2, 2015 at 4:06 AM, Steven D'Aprano
> wrote:
>>> On Sun, Feb 1, 2015 at 11:15 PM, Steven D'Aprano
>>> wrote:
>> Both K.f and K.g are methods, even though only one meets the definition
>> given in the glossary. The glossary is
On Mon, Feb 2, 2015 at 4:06 AM, Steven D'Aprano
wrote:
>> On Sun, Feb 1, 2015 at 11:15 PM, Steven D'Aprano
>> wrote:
> Both K.f and K.g are methods, even though only one meets the definition
> given in the glossary. The glossary is wrong.
I agree, it oversimplified and has made a useless distinc
Rustom Mody wrote:
> My point was more methodological/sociological than technical:
>
> Are these dunder methods as 'internal' as say the register-allocation used
> by a C compiler?
Dunder methods are implementation, not interface. If you are the class
author, then you care about the implementat
On Monday, February 2, 2015 at 10:57:27 AM UTC+5:30, Vito De Tullio wrote:
> Steven D'Aprano wrote:
>
> > Checking the REPL first would have revealed that [].__dir__ raises
> > AttributeError. In other words, lists don't have a __dir__ method.
>
> ?
>
> Python 3.4.2 (default, Nov 29 2014, 00:45:
Steven D'Aprano wrote:
> Both K.f and K.g are methods, even though only one meets the definition
> given in the glossary. The glossary is wrong.
Oh I'm sure somebody is going to pick me up on this...
In Python 2, they are methods. In Python 3, they are functions, and aren't
converted into metho
Devin Jeanpierre wrote:
> -- Devin
>
> On Sun, Feb 1, 2015 at 11:15 PM, Steven D'Aprano
> wrote:
>> Gregory Ewing wrote:
>>
>>> Steven D'Aprano wrote:
[quote]
If the object has a method named __dir__(), this method will
be called and must return the list of attributes.
-- Devin
On Sun, Feb 1, 2015 at 11:15 PM, Steven D'Aprano
wrote:
> Gregory Ewing wrote:
>
>> Steven D'Aprano wrote:
>>> [quote]
>>> If the object has a method named __dir__(), this method will
>>> be called and must return the list of attributes.
>>> [end quote]
>>>
>>> The first
Gregory Ewing wrote:
> Steven D'Aprano wrote:
>> [quote]
>> If the object has a method named __dir__(), this method will
>> be called and must return the list of attributes.
>> [end quote]
>>
>> The first inaccuracy is that like all (nearly all?) dunder methods,
>> Python only loo
Steven D'Aprano wrote:
> Checking the REPL first would have revealed that [].__dir__ raises
> AttributeError. In other words, lists don't have a __dir__ method.
?
Python 3.4.2 (default, Nov 29 2014, 00:45:45)
[GCC 4.8.3] on linux
Type "help", "copyright", "credits" or "license" for more informa
Steven D'Aprano wrote:
[quote]
If the object has a method named __dir__(), this method will
be called and must return the list of attributes.
[end quote]
The first inaccuracy is that like all (nearly all?) dunder methods, Python
only looks for __dir__ on the class, not the inst
On Monday, February 2, 2015 at 9:34:53 AM UTC+5:30, Rustom Mody wrote:
> On Monday, February 2, 2015 at 9:22:51 AM UTC+5:30, Rustom Mody wrote:
> > On Sunday, February 1, 2015 at 9:51:11 PM UTC+5:30, Steven D'Aprano wrote:
> > > Rustom Mody wrote:
> > >
> > > > The other day I was taking a class i
On Monday, February 2, 2015 at 9:22:51 AM UTC+5:30, Rustom Mody wrote:
> On Sunday, February 1, 2015 at 9:51:11 PM UTC+5:30, Steven D'Aprano wrote:
> > Rustom Mody wrote:
> >
> > > The other day I was taking a class in which I was showing
> > > - introspection for discovering -- help, type, dir et
On Sunday, February 1, 2015 at 9:51:11 PM UTC+5:30, Steven D'Aprano wrote:
> Rustom Mody wrote:
>
> > The other day I was taking a class in which I was showing
> > - introspection for discovering -- help, type, dir etc at the repl
> > - mapping of surface syntax to internals eg. a + b ←→ a.__add__
On 2/1/2015 12:45 PM, Chris Angelico wrote:
Simple answer: You write dunder methods and the interpreter calls
them. You don't call them yourself.
I can't currently think of any situation where it's appropriate to
call a dunder method manually (cue the swamping of such situations on
the list); yo
On Sun, Feb 1, 2015 at 4:36 PM, Rustom Mody wrote:
> The other day I was taking a class in which I was showing
> - introspection for discovering -- help, type, dir etc at the repl
> - mapping of surface syntax to internals eg. a + b ←→ a.__add__(b)
>
> And a student asked me the diff between
> dir
On Sun, Feb 1, 2015 at 9:55 AM, Steven D'Aprano
wrote:
> Steven D'Aprano wrote:
>
>> len tries to call __len__ if it exists, and if not, it tries walking the
>> iterable counting items.
>
> Hmmm, I may have mis-remembered that. Perhaps I'm thinking of Ruby.
I think you just got it backward. iter
Steven D'Aprano wrote:
> len tries to call __len__ if it exists, and if not, it tries walking the
> iterable counting items.
Hmmm, I may have mis-remembered that. Perhaps I'm thinking of Ruby.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Rustom Mody wrote:
> The other day I was taking a class in which I was showing
> - introspection for discovering -- help, type, dir etc at the repl
> - mapping of surface syntax to internals eg. a + b ←→ a.__add__(b)
>
> And a student asked me the diff between
> dir([])
> and
> [].__dir__()
>
>
On 01/31/2015 09:36 PM, Rustom Mody wrote:
>
> And a student asked me the diff between
> dir([])
> and
> [].__dir__()
>
> I didnt know what to say...
> Now surely the amount of python I dont know is significantly larger than what
> I know
> Still it would be nice to have surface-syntax ←→ dunder
On Sunday, February 1, 2015 at 10:15:13 AM UTC+5:30, Ethan Furman wrote:
> On 01/31/2015 07:16 PM, Steven D'Aprano wrote:
> >
> > But by default, Python will fallback on __repr__ if __str__ doesn't exist,
> > or __str__ if __repr__ doesn't exist, or both. Or something. (I always
> > forget what th
46 matches
Mail list logo
