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
> Unfortunately, we do have a problem with the code in copy.py:
>
> class MetaCopyableClass(type):
> def __copy__(cls):
> """ code to copy CLASSES of this metaclass """
> # etc, etc, snipped
>
> class CopyableClass:
> __metaclass__ = MetaCopyableClass
> # rest of clas
back in Python 2.1 (and before), an object could define how copy.copy should
work simply by definining a __copy__ method. here's the relevant portion:
...
try:
copierfunction = _copy_dispatch[type(x)]
except KeyError:
try:
copier = x.__copy__
except
At 02:58 PM 1/11/05 -0800, Guido van Rossum wrote:
[Phillip]
> Looks like a bug to me; it breaks the behavior of classic classes, since
> type(classicInstance) returns InstanceType.
I'm not so sure. I can't seem to break this for classic classes.
Sorry; I was extrapolating from what I thought was F
[Fredrik]
> >I recently discovered that this feature has disappeared in 2.3 and 2.4. in-
> >stead of looking for an instance method, the code now looks at the object's
> >type:
> >
> > ...
> >
> > cls = type(x)
> >
> > copier = _copy_dispatch.get(cls)
> > if copier:
> > ret
At 11:20 PM 1/11/05 +0100, Fredrik Lundh wrote:
I recently discovered that this feature has disappeared in 2.3 and 2.4. in-
stead of looking for an instance method, the code now looks at the object's
type:
...
cls = type(x)
copier = _copy_dispatch.get(cls)
if copier:
return
At 11:56 PM 1/11/05 +0100, Alex Martelli wrote:
What "both issues"? There's only one issue, it seems to me -- one of
metaconfusion.
I was relying on Fredrik's report of a problem with the code; that is the
other "issue" I referred to.
___
Python-Dev m
On 2005 Jan 11, at 23:58, Guido van Rossum wrote:
...
cls = type(x)
copier = _copy_dispatch.get(cls)
if copier:
return copier(x)
...
is this a bug, or a feature of the revised copy/pickle design?
[Phillip]
Looks like a bug to me; it breaks the behavior of classic classes,
On 2005 Jan 11, at 23:39, Phillip J. Eby wrote:
...
cls = type(x)
copier = _copy_dispatch.get(cls)
if copier:
return copier(x)
...
this a bug, or a feature of the revised copy/pickle design?
Looks like a bug to me; it breaks the behavior of classic classes,
since type(cla
On 2005 Jan 11, at 23:20, Fredrik Lundh wrote:
back in Python 2.1 (and before), an object could define how copy.copy
should
work simply by definining a __copy__ method. here's the relevant
portion:
...
try:
copierfunction = _copy_dispatch[type(x)]
except KeyError:
tr
21 matches
Mail list logo
