"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> What do people think? (My main motivation for this, as stated before,
> is that it adds complexity without much benefit.)
>From the viewpoint of learning and explaining Python, this is a plus.
I never understood why
On Sun, 2005-01-16 at 22:12 -0800, Guido van Rossum wrote:
> What do people think? (My main motivation for this, as stated before,
> is that it adds complexity without much benefit.)
> ***
> *** 331,339
> def test_im_class():
> class C:
> def foo(self): pass
> -
On Sun, 2005-01-16 at 13:00 -0500, Phillip J. Eby wrote:
> """One type is the "extender", ...
> By contrast, an "independent adapter" ...
I really like the way this part of the PEP is sounding, since it really
captures two almost, but not quite, completely different use-cases, the
confusion betw
https://sourceforge.net/tracker/index.php?func=detail&aid=1103689&group_id=5470&atid=305470
Here's a patch that gets rid of unbound methods, as
discussed here before. A function's __get__ method
now returns the function unchanged when called without
an instance, instead of returning an unbound met
> - protocol means any object, usually a type or class or interface,
> which guides the construction of an adapter
Then what do we call the abstract *concept* of a protocol?
> - adaptee-class refers to the adaptee's class
Please make it explicit that this is a.__class__, not type(a).
>
[EMAIL PROTECTED] (Kurt B. Kaiser) writes:
> [EMAIL PROTECTED] (Kurt B. Kaiser) writes:
>> [JH]
>>> ../Python/symtable.c:193: structure has no member named `st_tmpname'
>>>
>>> Do you see that?
>>
>> Yeah, the merge eliminated it from the symtable struct in symtable.h.
>> You moved it to symtable
Oops. I forgot to cancel this posting; it's an older version.
At 11:51 PM 1/15/05 -0500, Phillip J. Eby wrote:
This is only a partial first draft, but the Motivation section nonetheless
attempts to briefly summarize huge portions of the various discussions
regarding adaptation, and to coin a hop
This is only a partial first draft, but the Motivation section nonetheless
attempts to briefly summarize huge portions of the various discussions
regarding adaptation, and to coin a hopefully more useful terminology than
some of our older working adjectives like "sticky" and "stateless" and
suc
Patch / Bug Summary
___
Patches : 272 open ( +5) / 2737 closed (+10) / 3009 total (+15)
Bugs: 793 open ( -5) / 4777 closed (+29) / 5570 total (+24)
RFE : 165 open ( +0) / 141 closed ( +1) / 306 total ( +1)
New / Reopened Patches
__
Enhance t
I've revised the draft today to simplify the terminology, discussing only
two broad classes of adapters. Since Clark's pending proposals for PEP 246
align well with the concept of "extenders" vs. "independent adapters", I've
refocused my PEP to focus exclusively on adding support for "extenders
At 09:15 AM 1/16/05 -0800, Guido van Rossum wrote:
Given the many and various issues with automamtic adaptation
(transitivity, lossiness, statelessness, and apparently more still)
that might be a better approach.
Actually, I think Clark, Alex, and I are rapidly converging on a relatively
simple co
The various PEP 246 threads are dead AFAIC -- I won't ever have the
time to read them in full length, and because I haven't followed them
I don't get much of the discussion that's still going on.
I hear that Clark and Alex are going to do a revision of the PEP; I'm
looking forward to the results.
Hello
I've looked at one bug and a bunch of patches and
added a comment to them:
(bug) [ 1102649 ] pickle files should be opened in binary mode
Added a comment about a possible different solution
[ 946207 ] Non-blocking Socket Server
Useless, what are the mixins for? Recommend close
[ 756021 ] Allo
At 10:28 AM 1/16/05 +0100, Martin v. Löwis wrote:
Phillip J. Eby wrote:
Couldn't we require new-style exceptions to inherit from Exception?
Since there are no new-style exceptions that work now, this can't break
existing code.
This would require to make Exception a new-style class, right?
>>> clas
On 2005 Jan 16, at 12:03, Fredrik Lundh wrote:
Alex Martelli wrote:
Problem: to write unit tests showing that the current copy.py
misbehaves with a classic extension
type, I need a classic extension type which defines __copy__ and
__deepcopy__ just like /F's
cElementTree does. So, I made one: a
On 2005 Jan 16, at 11:17, Raymond Hettinger wrote:
[Alex]
So, as per discussion here, I have prepared a patch (to the
maintenance
branch of 2.3, to start with) which adds unit tests to highlight these
issues, and fixes them in copy.py. This patch should go in the
maintenance of 2.3 and 2.4, but in
Alex Martelli wrote:
> Problem: to write unit tests showing that the current copy.py misbehaves with
> a classic extension
> type, I need a classic extension type which defines __copy__ and __deepcopy__
> just like /F's
> cElementTree does. So, I made one: a small trycopy.c and accompanying
[Alex]
> So, as per discussion here, I have prepared a patch (to the
maintenance
> branch of 2.3, to start with) which adds unit tests to highlight these
> issues, and fixes them in copy.py. This patch should go in the
> maintenance of 2.3 and 2.4, but in 2.5 a different approach based on
> new sp
Alex Martelli wrote:
What would happen if Exception were made a new-style class, enforce
inheritance from Exception for all new-style exceptions, and allow all
old-style exceptions as before.
string exceptions would break.
Couldn't we just specialcase strings specifically, to keep
grandfathering
On 2005 Jan 16, at 10:28, Martin v. Löwis wrote:
Phillip J. Eby wrote:
Couldn't we require new-style exceptions to inherit from Exception?
Since there are no new-style exceptions that work now, this can't
break existing code.
This would require to make Exception a new-style class, right?
Not nec
On 2005 Jan 16, at 10:27, Martin v. Löwis wrote:
Simon Percivall wrote:
What would happen if Exception were made a new-style class, enforce
inheritance from Exception for all new-style exceptions, and allow all
old-style exceptions as before.
string exceptions would break.
Couldn't we just specialc
copy.py, as recently discussed starting from a post by /F, has two
kinds of misbehaviors since 2.3 (possibly 2.2, haven't checked), both
connected to instance/type/metatype confusion (where do special methods
come from? in classic classes and types, from the instance, which may
delegate to the
Phillip J. Eby wrote:
Couldn't we require new-style exceptions to inherit from Exception?
Since there are no new-style exceptions that work now, this can't break
existing code.
This would require to make Exception a new-style class, right?
This, in itself, could break existing code.
Regards,
Mar
Simon Percivall wrote:
What would happen if Exception were made a new-style class, enforce
inheritance from Exception for all new-style exceptions, and allow all
old-style exceptions as before.
string exceptions would break.
In addition, code may break which assumes that exceptions are classic
inst
Guido van Rossum wrote:
The base of the Exception hierarchy happens to be a classic class.
But why are they "required" to be classic?
More to the point, is this a bug, a missing feature, or just a bug in
the documentation for not mentioning the restriction?
It's an unfortunate feature; it shou
On 2005 Jan 16, at 03:17, Phillip J. Eby wrote:
...
Uh oh. I just used "view" to describe an iterator as a view on an
iterable, as distinct from an adapter that adapts a sequence so that
it's iterable. :)
I.e., using "view" in the MVC sense where a given Model might have
multiple independe
26 matches
Mail list logo