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 yyy,
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
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 =
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
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
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,
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
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 to
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
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
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
string
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
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
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
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
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
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-ID: [EMAIL PROTECTED]
Content-Type: text/plain; charset=us-ascii
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.
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
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.
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 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,
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.
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 this
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
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
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
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
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
|
|
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
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
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
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
41 matches
Mail list logo
