I just attempted to post the Monkey Typing draft pre-PEP, but it bounced
due to being just barely over the size limit for the list. :)
So, I'm just posting the preamble and abstract here for now, and a link to
a Wiki page with the full text. I hope the moderator will approve the
actual postin
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
propos
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 of
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
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, ei
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 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 p
> 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 i
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 t
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, either.
PyObject_GetIter invokes the '__iter__' met
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 *i
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 hav
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
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
> >their right mind expect the following to re
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 to
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,
"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
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 *
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 b
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 *s
On Fri, 14 Jan 2005 20:06:22 -0500, Phillip J. Eby
<[EMAIL PROTECTED]> wrote:
> >My feeling here was not that people thought that stateless adapters
> >were in general intrinsically better -- just when the adaptation was
> >going to be done implicitly (e.g. by type declarations).
>
> Yes, exactly.
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 alternati
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 m
On 2005 Jan 15, at 01:02, Glyph Lefkowitz wrote:
...
Now, we have nowhere to hide PointPen's state on SegmentPen - and why
were we trying to in the first place? It's a horrible breach of
encapsulation. The whole *point* of adapters is to convert between
*different* interfaces, not merely to r
24 matches
Mail list logo
