At 12:59 PM 1/18/05 +, Armin Rigo wrote:
> How can we express your thoughts so that they fit into a narrative
> describing how adapt() should and should not be used?
I'm attaching a longer, hopefully easier reformulation...
Well said! You've explained my "interface per use case" theory much be
Hi Clark,
On Fri, Jan 14, 2005 at 12:41:32PM -0500, Clark C. Evans wrote:
> Imagine enhancing the stack-trace with additional information about
> what adaptations were made;
>
> Traceback (most recent call last):
>File "xxx", line 1, in foo
> Adapting x to File
>File
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
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
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
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,
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
On Fri, 2005-01-14 at 19:14 -0500, Bob Ippolito wrote:
> I think the idea is that it's "better" to have an adapter from
> IBusinessThunk -> IGtkUIPlugFactory, which you can use to *create* a
> stateful object that complies with the IGtkUIPlug interface.
>
> This way, you are explicitly creating
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 possible here; it isn't
necessary
At 05:37 PM 1/14/05 -0700, Steven Bethard wrote:
On Fri, 14 Jan 2005 19:02:52 -0500, Glyph Lefkowitz <[EMAIL PROTECTED]> wrote:
> On Fri, 2005-01-14 at 10:07 -0500, Phillip J. Eby wrote:
>
> > Maybe I'm missing something, but for those interfaces, isn't it okay to
> > keep the state in the *adapted
On Fri, 14 Jan 2005 19:02:52 -0500, Glyph Lefkowitz <[EMAIL PROTECTED]> wrote:
> On Fri, 2005-01-14 at 10:07 -0500, Phillip J. Eby wrote:
>
> > Maybe I'm missing something, but for those interfaces, isn't it okay to
> > keep the state in the *adapted* object here? In other words, if PointPen
> > j
On Jan 14, 2005, at 19:02, Glyph Lefkowitz wrote:
On Fri, 2005-01-14 at 10:07 -0500, Phillip J. Eby wrote:
Maybe I'm missing something, but for those interfaces, isn't it okay
to
keep the state in the *adapted* object here? In other words, if
PointPen
just added some private attributes to store
On Fri, 2005-01-14 at 10:07 -0500, Phillip J. Eby wrote:
> Maybe I'm missing something, but for those interfaces, isn't it okay to
> keep the state in the *adapted* object here? In other words, if PointPen
> just added some private attributes to store the extra data?
I have been following thi
At 02:25 PM 1/14/05 -0500, Clark C. Evans wrote:
I'm not sure what else this mechanism provides; besides limiting
adapters so that they cannot maintain their own state.
* No need to write adapter classes for stateless adapters; just declare
methods
* Allows partial adapters to be written for e.g.
At 10:02 AM 1/14/05 -0800, Michel Pelletier wrote:
I get it!
Thanks for the positive feedback, I was getting worried that I had perhaps
gone quite insane during the great debate. :)
Your last description didn't quite sink in but this one does and
I've been thinking about this quite a bit, and
At 12:41 PM 1/14/05 -0500, Clark C. Evans wrote:
May I suggest that you write this up as a PEP?
Already committed to it for this weekend, but my statement was buried in a
deep thread between Alex and I, so you might've missed it.
___
Python-Dev mailing
At 06:56 PM 1/14/05 +0100, Just van Rossum wrote:
Phillip J. Eby wrote:
> For example, if there were a weak reference dictionary mapping
> objects to their (stateful) adapters, then adapt() could always
> return the same adapter instance for a given source object, thus
> guaranteeing a single state
On 2005 Jan 14, at 20:25, Clark C. Evans wrote:
| Does anyone know of any other languages that take this "operational"
| aproach to solving the substitutability problem?
Microsoft's COM?
I don't see the parallel: COM (QueryInterface) is strictly
by-interface, not by-method, and has many other diff
On Fri, Jan 14, 2005 at 10:02:39AM -0800, Michel Pelletier wrote:
| Phillip J. Eby wrote:
| > The result is that you generate a simple adapter class whose
| > only state is a read-only slot pointing to the adapted object,
| > and descriptors that bind the registered implementations to that object.
> Date: Fri, 14 Jan 2005 02:38:05 -0500
> From: "Phillip J. Eby" <[EMAIL PROTECTED]>
> Subject: Re: [Python-Dev] PEP 246: lossless and stateless
> To: [EMAIL PROTECTED]
> Cc: "Clark C. Evans" <[EMAIL PROTECTED]>, python-dev@python.org
> Message-
Phillip J. Eby wrote:
> For example, if there were a weak reference dictionary mapping
> objects to their (stateful) adapters, then adapt() could always
> return the same adapter instance for a given source object, thus
> guaranteeing a single state.
Wouldn't that tie the lifetime of the adapter
On Fri, Jan 14, 2005 at 12:28:16PM -0500, Phillip J. Eby wrote:
| At 08:32 AM 1/14/05 -0800, Guido van Rossum wrote:
| >I have no desire to add syntax
| >complexities like this to satisfy some kind of theoretically nice
| >property.
|
| Whether it's syntax or a decorator, it allows you to create s
On Fri, Jan 14, 2005 at 04:39:00PM +, Armin Rigo wrote:
| I'm trying to reserve the usage of "interface" to something more
| concrete: the concrete ways we have to manipulate a given object
| (typically a set of methods including some unwritten expectations).
I'd say that a programmer inte
At 04:39 PM 1/14/05 +, Armin Rigo wrote:
Ideally, both the caller and the callee know (and write down) that the
function's argument is a "reference to some kind of file stuff", a very
general concept; then they can independently specify which concrete object
they expect and provide, e.g. "a str
At 08:32 AM 1/14/05 -0800, Guido van Rossum wrote:
I have no desire to add syntax
complexities like this to satisfy some kind of theoretically nice
property.
Whether it's syntax or a decorator, it allows you to create stateless
adapters without needing to write individual adapter *classes*, or eve
Hi Phillip,
On Fri, Jan 14, 2005 at 10:22:36AM -0500, Phillip J. Eby wrote:
> Note that this is solvable in practice by the author of a method or
> framework choosing to define an interface that they accept, and then
> pre-defining the adaptation from string to that interface. So, what a
> str
[Phillip]
> Quick demo (strawman syntax) of declaring adapters...
>
> First, a type declaring that its 'read' method has the semantics of
> 'file.read':
>
> class SomeKindOfStream:
> def read(self, byteCount) like file.read:
> ...
[and more like this]
Sorry, this is de
Phillip J. Eby wrote:
> At 10:09 AM 1/14/05 +0100, Just van Rossum wrote:
> >Guido van Rossum wrote:
> >
> > > Are there real-life uses of stateful adapters that would be
> > > thrown out by this requirement?
> >
> >Here are two interfaces we're using in a project:
> >
> > http://just.letterror.
At 09:47 AM 1/14/05 +, Armin Rigo wrote:
For example, strings "mean" very
different concepts in various contexts, e.g. a file name, an url, the byte
content a document, or the pickled representation of something.
Note that this is solvable in practice by the author of a method or
framework cho
At 10:09 AM 1/14/05 +0100, Just van Rossum wrote:
Guido van Rossum wrote:
> Are there real-life uses of stateful adapters that would be thrown out
> by this requirement?
Here are two interfaces we're using in a project:
http://just.letterror.com/ltrwiki/PenProtocol (aka "SegmentPen")
http://jus
On Fri, Jan 14, 2005 at 09:47:15AM +, Armin Rigo wrote:
| In my opinion a user-defined class or interface mixes two notions: a
| "concept" meaningful for the programmer that the instances
| represent, and the "interface" provided to manipulate it.
...
| This suggests that only concrete objects
On Fri, Jan 14, 2005 at 12:11:10AM -0500, Phillip J. Eby wrote:
| Clark's proposal isn't going to solve this issue for PEP 246, alas. In
| order to guarantee safety of adaptive type declarations, the
| implementation strategy *must* be able to guarantee that 1) adapters do
| not have state of t
On Thu, Jan 13, 2005 at 08:54:33PM -0500, Raymond Hettinger wrote:
| > Since __conform__ and __adapt__
| > would sprout two new arguments, it would make those writing adapters
| > think a bit more about the kind of adapter that they are providing.
|
| Using optional arguments may not be the most e
Hi Guido,
On Thu, Jan 13, 2005 at 10:20:40PM -0800, Guido van Rossum wrote:
> Hm. Maybe that post points out that adapters that add state are bad,
> period. I have to say that the example of adapting a string to a file
> using StringIO() is questionable. Another possible adaptation from a
> string
Guido van Rossum wrote:
> Are there real-life uses of stateful adapters that would be thrown out
> by this requirement?
Here are two interfaces we're using in a project:
http://just.letterror.com/ltrwiki/PenProtocol (aka "SegmentPen")
http://just.letterror.com/ltrwiki/PointPen
They're both
At 10:20 PM 1/13/05 -0800, Guido van Rossum wrote:
[Guido]
> >This may solve the curernt raging argument, but IMO it would make the
> >optional signature declaration less useful, because there's no way to
> >accept other kind of adapters. I'd be happier if def f(X: Y) implied X
> >= adapt(X, Y).
[P
[Guido]
> >This may solve the curernt raging argument, but IMO it would make the
> >optional signature declaration less useful, because there's no way to
> >accept other kind of adapters. I'd be happier if def f(X: Y) implied X
> >= adapt(X, Y).
[Phillip]
> The problem is that type declarations re
At 12:00 AM 1/14/05 -0500, Clark C. Evans wrote:
On Thu, Jan 13, 2005 at 11:50:37PM -0500, Phillip J. Eby wrote:
| 'lossless' isn't really a good term for non-noisy. The key is that a
| "noisy" adapter is one that alters the precision of the information it
| provides, by either claiming greater pr
At 05:52 PM 1/13/05 -0800, Guido van Rossum wrote:
This may solve the curernt raging argument, but IMO it would make the
optional signature declaration less useful, because there's no way to
accept other kind of adapters. I'd be happier if def f(X: Y) implied X
= adapt(X, Y).
The problem is that ty
On Thu, Jan 13, 2005 at 11:50:37PM -0500, Phillip J. Eby wrote:
| 'lossless' isn't really a good term for non-noisy. The key is that a
| "noisy" adapter is one that alters the precision of the information it
| provides, by either claiming greater precision than is actually present,
| or by losi
At 08:03 PM 1/13/05 -0500, Clark C. Evans wrote:
Ok. I think we have identified two sorts of restrictions on the
sorts of adaptations one may want to have:
`stateless' the adaptation may only provide a result which
does not maintain its own state
`lossless' the adaptation pre
On Thu, Jan 13, 2005 at 08:08:43PM -0500, Bob Ippolito wrote:
| >Ok. I think we have identified two sorts of restrictions on the
| >sorts of adaptations one may want to have:
| >
| > `stateless' the adaptation may only provide a result which
| > does not maintain its own state
| >
> Ok. I think we have identified two sorts of restrictions on the
> sorts of adaptations one may want to have:
>
> `stateless' the adaptation may only provide a result which
>does not maintain its own state
>
> `lossless' the adaptation preserves all information available
> Then, Guido's 'Optional Static Typing',
>
> def f(X: Y):
> pass
>
>would be equivalent to
>
> def f(X):
> X = adapt(Y, True, True)
>
> In other words, while calling adapt directly would allow for any adapter;
> using the 'Static Typing' short-cut one would be
On Jan 13, 2005, at 20:03, Clark C. Evans wrote:
Ok. I think we have identified two sorts of restrictions on the
sorts of adaptations one may want to have:
`stateless' the adaptation may only provide a result which
does not maintain its own state
`lossless' the adaptation pre
57 matches
Mail list logo
