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 independent
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
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
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
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
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
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
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
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?
class
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 ]
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
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,
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
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
such.
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
[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_entry at rev
- 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).
-
https://sourceforge.net/tracker/index.php?func=detailaid=1103689group_id=5470atid=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
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 between
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
-
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
21 matches
Mail list logo
