On 2005 Jan 14, at 00:11, Guido van Rossum wrote:
Let's do override descriptors.
A Pronouncement!!!
And please, someone fix copy.py in 2.3 and 2.4.
Sure -- what way, though? The way I proposed in my last post about
it?
This would do it, right? (From your first post in this conversation
according
> > Let's do override descriptors.
>
> A Pronouncement!!!
>
> > And please, someone fix copy.py in 2.3 and 2.4.
>
> Sure -- what way, though? The way I proposed in my last post about it?
This would do it, right? (From your first post in this conversation
according to gmail:)
> Armin's fix was
On 2005 Jan 13, at 18:02, Guido van Rossum wrote:
...
In all cases, I'm +1 on seeing built-in method objects
(PyMethodDescr_Type)
become data descriptors ("classy descriptors?" :-).
Let's do override descriptors.
A Pronouncement!!!
And please, someone fix copy.py in 2.3 and 2.4.
Sure -- what wa
At 09:02 AM 1/13/05 -0800, Guido van Rossum wrote:
[Armin]
> I guess that a name-based hack in type_new() to turn all __*__()
methods into
> data descriptors would be even more obscure?
To the contary, I just realized in this would in fact be the right
approach. In particular, any *descriptor* na
> > The descriptor for __getattr__ and other special attributes could
> > claim to be a "data descriptor"
>
> This has the nice effect that x[y] and x.__getitem__(y) would again be
> equivalent, which looks good.
>
> On the other hand, I fear that if there is a standard "metamethod" decorator
> (
At 10:16 AM 1/13/05 +, Armin Rigo wrote:
On the other hand, I fear that if there is a standard "metamethod" decorator
(named after Phillip's one), it will be misused. Reading the documentation
will probably leave most programmers with the feeling "it's something magical
to put on methods with
On 2005 Jan 12, at 18:59, Guido van Rossum wrote:
...
[Alex]
Armin's fix was to change:
...
[And then proceeds to propose a new API to improve the situation]
I wonder if the following solution wouldn't be more useful (since less
code will have to be changed).
The descriptor for __getattr__ an
Hi Guido,
On Wed, Jan 12, 2005 at 09:59:13AM -0800, Guido van Rossum wrote:
> The descriptor for __getattr__ and other special attributes could
> claim to be a "data descriptor"
This has the nice effect that x[y] and x.__getitem__(y) would again be
equivalent, which looks good.
On the other hand
On Wed, Jan 12, 2005, Guido van Rossum wrote:
>
> PS. The term "data descriptor" now feels odd, perhaps we can say "hard
> descriptors" instead. Hard descriptors have a __set__ method in
> addition to a __get__ method (though the __set__ method may always
> raise an exception, to implement a read-o
At 09:59 AM 1/12/05 -0800, Guido van Rossum wrote:
We would need to introduce a new decorator so that classes overriding
these methods can also make those methods "data descriptors", and so
that users can define their own methods with this special behavior
(this would be needed for __copy__, probab
[Alex]
> Armin's fix was to change:
>
> conform = getattr(type(obj), '__conform__', None)
>
> into:
>
> for basecls in type(obj).__mro__:
> if '__conform__' in basecls.__dict__:
> conform = basecls.__dict__['__conform__']
> break
> else:
> # no
Since this bug isn't the cause of Fredrik's problem I'm changing the
subject (and keep discussing the specific problem that Fredrik
uncovered under the original subject).
On 2005 Jan 12, at 05:11, Guido van Rossum wrote:
...
I had exactly the same metabug in the pep 246 reference
implementat
12 matches
Mail list logo
