On 2005 Jan 15, at 02:30, Phillip J. Eby wrote:
is requested. It's too bad Python doesn't have some sort of
deallocation hook you could use to get notified when an object goes
away. Oh well.
For weakly referenceable objects, it does. Giving one to other objects
would be almost isomorphic to
Phillip J. Eby wrote:
At 07:02 PM 1/14/05 -0500, Glyph Lefkowitz wrote:
For the sake of argument, let's say that SegmentPen is a C type,
which does not have a __dict__, and that PointPen is a Python
adapter for it, in a different project.
There are multiple implementation alternatives
At 10:39 AM 1/15/05 +0100, Just van Rossum wrote:
That sounds extremely complicated as apposed to just storing the sate
where it most logically belongs: on the adapter.
Oh, the state will be on the adapter all right. It's just that for type
declarations, I'm saying the system should return the
At 01:20 PM 1/15/05 +, Paul Moore wrote:
I think there are the following distinct threads of discussion going
on at the moment:
* Details of what should be in PEP 246
* Discussions spinning off from Guido's type-declaration-as-adaptation
proposal
My understanding was that the first needed to
Phillip J. Eby wrote:
It's not at all clear to me that sticky behavior is the best
default behavior, even with implicit adoptation. Would anyone in
their right mind expect the following to return [0, 1, 2, 3, 4, 5]
instead of [0, 1, 2, 0, 1, 2]?
from itertools import *
seq =
Skip Montanaro [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
The first example here:
http://www.compulink.co.uk/~querrid/STANDARD/lsp.htm
Looks pretty un-extreme to me.
To both summarize and flesh out the square-rectangle example:
Q. Is a square 'properly' a rectangle? A.
At 05:32 PM 1/15/05 +0100, Just van Rossum wrote:
Phillip J. Eby wrote:
It's not at all clear to me that sticky behavior is the best
default behavior, even with implicit adoptation. Would anyone in
their right mind expect the following to return [0, 1, 2, 3, 4, 5]
instead of [0, 1, 2, 0, 1,
At 10:35 AM 1/15/05 +0100, Alex Martelli wrote:
On 2005 Jan 15, at 02:30, Phillip J. Eby wrote:
is requested. It's too bad Python doesn't have some sort of deallocation
hook you could use to get notified when an object goes away. Oh well.
For weakly referenceable objects, it does. Giving one
At 10:48 PM 1/15/05 +0100, Simon Percivall wrote:
On 2005-01-15, at 18.06, Phillip J. Eby wrote:
At 05:32 PM 1/15/05 +0100, Just van Rossum wrote:
Phillip J. Eby wrote:
It's not at all clear to me that sticky behavior is the best
default behavior, even with implicit adoptation. Would anyone in
Phillip J. Eby wrote:
But it _does_ perform an implicit adaptation, via PyObject_GetIter.
First, that's not implicit. Second, it's not adaptation, either.
PyObject_GetIter invokes the '__iter__' method of its target -- a
method that is part of the *iterable* interface. It has to have
On 2005-01-15, at 23.50, Just van Rossum wrote:
Phillip J. Eby wrote:
But it _does_ perform an implicit adaptation, via PyObject_GetIter.
First, that's not implicit. Second, it's not adaptation, either.
PyObject_GetIter invokes the '__iter__' method of its target -- a
method that is part of the
Phillip J. Eby wrote (in
http://mail.python.org/pipermail/python-dev/2005-January/050854.html)
* Classic class support is a must; exceptions are still required to be
classic, and even if they weren't in 2.5, backward compatibility should be
provided for at least one release.
The base of the
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 should be mentioned in the
At 11:50 PM 1/15/05 +0100, Just van Rossum wrote:
Phillip J. Eby wrote:
But it _does_ perform an implicit adaptation, via PyObject_GetIter.
First, that's not implicit. Second, it's not adaptation, either.
PyObject_GetIter invokes the '__iter__' method of its target -- a
method that is part
On 2005-01-16, at 02.57, Guido van Rossum wrote:
It's been suggested that all exceptions should inherit from Exception,
but this would break tons of existing code, so we shouldn't enforce
that until 3.0. (Is there a PEP for this? I think there should be.)
What would happen if Exception were made a
At 08:13 PM 1/15/05 -0500, James Y Knight wrote:
On Jan 15, 2005, at 6:02 PM, Simon Percivall wrote:
On 2005-01-15, at 23.50, Just van Rossum wrote:
Phillip J. Eby wrote:
But it _does_ perform an implicit adaptation, via PyObject_GetIter.
First, that's not implicit. Second, it's not adaptation,
At 05:57 PM 1/15/05 -0800, Guido van Rossum wrote:
It's been suggested that all exceptions should inherit from Exception,
but this would break tons of existing code, so we shouldn't enforce
that until 3.0. (Is there a PEP for this? I think there should be.)
Couldn't we require new-style exceptions
I started to edit the PEP, but found that we really don't have any
consensus on a great many items. The following is a bunch of topics,
and a proposed handling of those topics. A bulk of this comes from
a phone chat I had with Alex this past afternoon, and other items
come from my understanding
At 11:04 PM 1/15/05 -0500, Clark C. Evans wrote:
topic: a glossary
overview:
It seems that we are having difficulty with words that have shifting
definitions. The next PEP edit will need to add a glossary that
nails down some meanings of these words. Following are a few
19 matches
Mail list logo
