On Fri, 14 Jan 2005 08:50:27 +0100, Alex Martelli <[EMAIL PROTECTED]> wrote:
> Ooops -- sorry; I wouldn't have imagined Brazilian hits would swamp the
> google hits to that extent, mostly qualifying post-grad courses and the
> like... seems to be an idiom there for that.
'Lato sensu' is used to in
On 2005 Jan 14, at 04:08, David Ascher wrote:
Alex Martelli wrote:
Yes, there is (lato sensu) "non-determinism" involved, just like in,
say:
for k in d:
print k
Wow, it took more than the average amount of googling to figure out
that lato sensu means "broadly speaking",
Ooops -- sorry
Alex Martelli wrote:
Yes, there is (lato sensu) "non-determinism" involved, just like in, say:
for k in d:
print k
Wow, it took more than the average amount of googling to figure out that
lato sensu means "broadly speaking", and occurs as "sensu lato" with a
1:2 ratio.
I learned some
On Jan 13, 2005, at 12:46 PM, Clark C. Evans wrote:
My current suggestion to make 'transitive adaption' easy for a
application builder (one putting togeher components) has a few
small parts:
- If an adaptation is not found, raise an error, but list in
the error message two additional things:
On 2005 Jan 13, at 22:43, Paramjit Oberoi wrote:
On Thu, 13 Jan 2005 20:40:56 +0100, Alex Martelli <[EMAIL PROTECTED]>
wrote:
So please explain what's imperfect in wrapping a str into a StringIO?
If I understand Philip's argument correctly, the problem is this:
def print_next_line(f: file):
pr
On Thu, 13 Jan 2005 13:43:53 -0800, Paramjit Oberoi <[EMAIL PROTECTED]> wrote:
> On Thu, 13 Jan 2005 20:40:56 +0100, Alex Martelli <[EMAIL PROTECTED]> wrote:
> >
> > So please explain what's imperfect in wrapping a str into a StringIO?
>
> If I understand Philip's argument correctly, the problem i
On Thu, 13 Jan 2005 20:40:56 +0100, Alex Martelli <[EMAIL PROTECTED]> wrote:
>
> So please explain what's imperfect in wrapping a str into a StringIO?
If I understand Philip's argument correctly, the problem is this:
def print_next_line(f: file):
print f.readline()
s = "line 1\n" "line 2"
p
On Thu, Jan 13, 2005 at 08:40:56PM +0100, Alex Martelli wrote:
| >The other issue with registries (and why I avoided them in the
| >origional) is that they often require a scoping; in this case,
| >the path taken by one module might be different from the one
| >needed by another.
|
| I think th
On 2005 Jan 13, at 19:21, Clark C. Evans wrote:
...
Are you _sure_ you have M*N adapters here? But even so,
Yep.
for j in (J1,J2,J3,J4,...,JM)
for i in (I1,I2,...,IN):
register(j,i)
Uh? WHAT are you registering for each j->i...?
The other issue with registries (and why I avoided th
On Thu, Jan 13, 2005 at 06:27:08PM +0100, Alex Martelli wrote:
| >The 'implicit' adaptation refers to the automagical construction of
| >composite adapters assuming that a 'transitive' property holds. I've
| >seen nothing in this thread to explain why this is so valueable, why
|
| Let me play dev
On Wed, Jan 12, 2005 at 01:15:20PM -0800, Guido van Rossum wrote:
| [Clark]
| > - add a flag to adapt, allowTransitive, which defaults to False
|
| That wouldn't work very well when most adapt() calls are invoked
| implicitly through signature declarations (per my blog's proposal).
Understood.
On 2005 Jan 13, at 16:13, Carlos Ribeiro wrote:
...
+1, specially for the last sentence. An adapter with local state is
not an adapter anymore! It's funny how difficult it's to get this...
but it's obvious once stated.
...? A StringIO instance adapting a string to be used as a
readablefile is
On 2005 Jan 13, at 16:08, Phillip J. Eby wrote:
this with their string/file/path discussions -- *nobody* is safe from
implicit adaptation if adaptation actually creates new objects with
independent state! An adapter's state needs to be kept with the
original object, or not at all, and most of t
On 2005 Jan 13, at 15:34, Clark C. Evans wrote:
...
The 'implicit' adaptation refers to the automagical construction of
composite adapters assuming that a 'transitive' property holds. I've
seen nothing in this thread to explain why this is so valueable, why
Let me play devil's advocate: I _have_
On Fri, Jan 14, 2005 at 12:30:17AM +1000, Nick Coghlan wrote:
| Anyway, I'd like to know if the consensus I think you've reached is the
| one the pair of you think you've reached :)
This stated position is not the current PEP status, and it's
not a concensus position I share.
| That is, with A
On Fri, Jan 14, 2005 at 02:03:57AM +1000, Nick Coghlan wrote:
| Carlos Ribeiro wrote:
| > On Thu, 13 Jan 2005 10:08:10 -0500, Phillip J. Eby wrote:
| > > With the previous PEP, people could create all sorts of subtle problems
| > > in their code (with or without transitivity!) and have no direct
On Thu, 13 Jan 2005 10:26:54 -0500, Phillip J. Eby
<[EMAIL PROTECTED]> wrote:
> At 09:34 AM 1/13/05 -0500, Clark C. Evans wrote:
> >On Thu, Jan 13, 2005 at 10:35:39AM +, Paul Moore wrote:
> >| One thing I feel is key is the fact that adaptation is a *tool*, and
> >| as such will be used in diff
Carlos Ribeiro wrote:
On Thu, 13 Jan 2005 10:08:10 -0500, Phillip J. Eby
<[EMAIL PROTECTED]> wrote:
With the previous PEP, people could create all sorts of subtle problems in
their code (with or without transitivity!) and have no direct indicator of
a problem. Clark and Ian made me realize this wi
Phillip J. Eby wrote:
Anyway, I'm at least +0 on dropping this; the reservation is just
because I don't think everybody else will agree with this, and don't
want to be appearing to imply that consensus between you and me implies
any sort of community consensus on this point. That is, the adapta
At 09:34 AM 1/13/05 -0500, Clark C. Evans wrote:
On Thu, Jan 13, 2005 at 10:35:39AM +, Paul Moore wrote:
| One thing I feel is key is the fact that adaptation is a *tool*, and
| as such will be used in different ways by different people. That is
| not a bad thing, even if it does mean that some
At 10:35 AM 1/13/05 +, Paul Moore wrote:
Now, a lot of the talk has referred to "implicit" adaptation. I'm
still struggling to understand how that concept applies in practice,
beyond the case of adaptation chains - at some level, all adaptation
is "explicit", insofar as it is triggered by an ad
On Thu, 13 Jan 2005 10:08:10 -0500, Phillip J. Eby
<[EMAIL PROTECTED]> wrote:
> With the previous PEP, people could create all sorts of subtle problems in
> their code (with or without transitivity!) and have no direct indicator of
> a problem. Clark and Ian made me realize this with their string/
At 11:31 AM 1/13/05 +0100, Alex Martelli wrote:
On 2005 Jan 12, at 21:42, Phillip J. Eby wrote:
...
Anyway, hopefully this post and the other one will be convincing that
considering ambiguity to be an error *reinforces* the idea of I-to-I
perfection, rather than undermining it. (After all, if
On Thu, Jan 13, 2005 at 10:35:39AM +, Paul Moore wrote:
| One thing I feel is key is the fact that adaptation is a *tool*, and
| as such will be used in different ways by different people. That is
| not a bad thing, even if it does mean that some people will abuse the tool.
|
| Now, a lot of t
On Wed, 12 Jan 2005 21:50:14 -0600, Ian Bicking <[EMAIL PROTECTED]> wrote:
> Phillip J. Eby wrote:
> > At 04:07 PM 1/12/05 -0600, Ian Bicking wrote:
> >
> >> It also seems quite reasonable and unambiguous that a path object
> >> could be adapted to a IReadableFile by opening the file at the given
>
On 2005 Jan 12, at 21:42, Phillip J. Eby wrote:
...
Anyway, hopefully this post and the other one will be convincing that
considering ambiguity to be an error *reinforces* the idea of I-to-I
perfection, rather than undermining it. (After all, if you've written
a perfect one, and there's alre
Phillip J. Eby wrote:
At 04:07 PM 1/12/05 -0600, Ian Bicking wrote:
It also seems quite reasonable and unambiguous that a path object
could be adapted to a IReadableFile by opening the file at the given
path.
Not if you think of adaptation as an "as-a" relationship, like using a
screwdriver "as
[Clark]
> - add a flag to adapt, allowTransitive, which defaults to False
That wouldn't work very well when most adapt() calls are invoked
implicitly through signature declarations (per my blog's proposal).
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
__
At 04:07 PM 1/12/05 -0600, Ian Bicking wrote:
It also seems quite reasonable and unambiguous that a path object could be
adapted to a IReadableFile by opening the file at the given path.
Not if you think of adaptation as an "as-a" relationship, like using a
screwdriver "as a" hammer (really an IP
At 03:19 PM 1/12/05 -0700, Steven Bethard wrote:
On Wed, 12 Jan 2005 16:07:37 -0600, Ian Bicking <[EMAIL PROTECTED]> wrote:
> One case occurred to me with the discussion of strings and files, i.e.,
> adapting from a string to a file. Let's say an IReadableFile, since
> files are too ambiguous.
>
>
On Wed, Jan 12, 2005 at 04:07:37PM -0600, Ian Bicking wrote:
| A two-step adaptation encodes specific intention that it seems transitive
| adaption would be blind to.
Exactly. Nice example Ian. To parrot your example a bit more
concretely, the problem happens when you get two different
adaptati
On Wed, 12 Jan 2005 16:07:37 -0600, Ian Bicking <[EMAIL PROTECTED]> wrote:
> As I think these things through, I'm realizing that registered
> adaptators really should be 100% accurate (i.e., no information loss,
> complete substitutability), because a registered adapter that seems
> pragmatically u
On Wed, 12 Jan 2005 16:07:37 -0600, Ian Bicking <[EMAIL PROTECTED]> wrote:
> One case occurred to me with the discussion of strings and files, i.e.,
> adapting from a string to a file. Let's say an IReadableFile, since
> files are too ambiguous.
>
> Consider the case where we are using a path obje
Phillip J. Eby wrote:
Anyway, I'm honestly curious as to whether anybody can find a real
situation where transitive adapter composition is an *actual* problem,
as opposed to a theoretical one. I've heard a lot of people talk about
what a bad idea it is, but I haven't heard any of them say they
At 09:30 PM 1/12/05 +0100, Alex Martelli wrote:
On 2005 Jan 12, at 20:51, Phillip J. Eby wrote:
...
There's a very simple reason. If one is using only non-noisy adapters,
there is absolutely no reason to ever define more than one adapter
between the *same* two points. If you do,
...but there
On 2005 Jan 12, at 20:51, Phillip J. Eby wrote:
...
There's a very simple reason. If one is using only non-noisy
adapters, there is absolutely no reason to ever define more than one
adapter between the *same* two points. If you do,
...but there's no harm whatsoever done, either. If I have f
At 08:59 PM 1/12/05 +0100, Alex Martelli wrote:
Even though Guido claimed I have been belaboring the following point, I do
think it's crucial and I still haven't seen you answer it.
My post on that probably crossed with this post of yours; it contains an
excruciating analysis of why I chose to co
On Wed, 12 Jan 2005 10:16:14 -0800, Guido van Rossum
<[EMAIL PROTECTED]> wrote:
> But now, since I am still in favor of automatic "combined" adaptation
> *as a last resort*, I ask you to consider that Python is not C++, and
> that perhaps we can make the experience in Python better than it was
> in
At 09:05 PM 1/12/05 +0100, Alex Martelli wrote:
On 2005 Jan 12, at 20:39, Phillip J. Eby wrote:
It's burned me more than just a few times, and I *still* sometimes make
it if I'm not paying attention. It's just too easy to make the
mistake. So, I'm actually open to considering dropping interface
On 2005 Jan 12, at 20:39, Phillip J. Eby wrote:
...
> it's difficult because intuitively an interface defines a
*requirement*, so
> it seems logical to inherit from an interface in order to add
requirements!
Yes... I would fall into this trap as well until I'd been burned a
few times.
It's b
At 05:02 PM 1/12/05 +0100, Alex Martelli wrote:
So, I think PEP 246 should specify that the step now called (e) [checking
the registry] comes FIRST; then, an isinstance step [currently split
between (a) and (d)], then __conform__ and __adapt__ steps [currently
called (b) and (c)].
One question,
On 2005 Jan 12, at 20:06, Phillip J. Eby wrote:
At 10:16 AM 1/12/05 -0800, Guido van Rossum wrote:
For example, inteface B (or perhaps this should be a property of the
adapter for B->C?) might be marked so as to allow or disallow its
consideration when looking for multi-step adaptations. We could e
On Wed, Jan 12, 2005 at 10:16:14AM -0800, Guido van Rossum wrote:
| But now, since I am still in favor of automatic "combined" adaptation
| *as a last resort*, I ask you to consider that Python is not C++, and
| that perhaps we can make the experience in Python better than it was
| in C++. Perhaps
At 03:48 PM 1/12/05 +0100, Alex Martelli wrote:
Demanding that the set of paths of minimal available length has exactly
one element is strange, though, IF one is assuming that all adaptation
paths are exactly equivalent except at most for secondary issues of
performance (which are only adjudicat
At 09:46 AM 1/12/05 -0800, Michael Chermside wrote:
This is a collection of responses to various things that don't appear
to have been resolved yet:
Phillip writes:
> if a target protocol has optional aspects, then lossy adaptation to it is
> okay by definition. Conversely, if the aspect is *not*
At 07:49 AM 1/12/05 -0800, Guido van Rossum wrote:
[Phillip]
> As for the issue of what should and shouldn't exist in Python, it doesn't
> really matter; PEP 246 doesn't (and can't!) *prohibit* transitive
> adaptation.
Really? Then isn't it underspecified?
No; I just meant that:
1. With its current
On 2005 Jan 12, at 19:16, Guido van Rossum wrote:
...
[Alex]
Hm?
I meant if there were multiple A's. For every Ai that has an Ai->B you
would also have to register a trivial Ai->C. And if there were
multiple C's (B->C1, B->C2, ...) then the number of extra adaptors to
register would be the numbe
At 10:16 AM 1/12/05 -0800, Guido van Rossum wrote:
For example, inteface B (or perhaps this should be a property of the
adapter for B->C?) might be marked so as to allow or disallow its
consideration when looking for multi-step adaptations. We could even
make the default "don't consider", so only p
I'd just like to share a use case for transitive adaption that I've
just run into (I'm using Zope.Interface which does not support it).
Make of this what you will, I just thought an actual example where
transitive adaption is actually necessary might be useful to the
discussion.
I have a frame
At 07:04 PM 1/12/05 +0100, Alex Martelli wrote:
On 2005 Jan 12, at 18:58, Phillip J. Eby wrote:
...
I have some data about people coming in from LDAP and the like, which I
want to record in that SQL DB -- the incoming data is held in types that
implement IPerson, so I write an adapter IPerson
At 07:26 AM 1/12/05 -0800, Guido van Rossum wrote:
[Alex]
> I'm saying that if, by mistake, the programmer has NOT
> registered the A->C adapter (which would be easily coded and work
> perfectly), then thanks to transitivity, instead of a clear and simple
> error message leading to immediate diagno
> > [Alex]
> >> I'm saying that if, by mistake, the programmer has NOT
> >> registered the A->C adapter (which would be easily coded and work
> >> perfectly), then thanks to transitivity, instead of a clear and simple
> >> error message leading to immediate diagnosis of the error, they'll get
> >>
On 2005 Jan 12, at 18:58, Phillip J. Eby wrote:
...
I have some data about people coming in from LDAP and the like, which
I want to record in that SQL DB -- the incoming data is held in types
that implement IPerson, so I write an adapter IPerson -> IFullname
for the purpose.
This doesn't answ
At 06:18 PM 1/12/05 +0100, Alex Martelli wrote:
On 2005 Jan 12, at 17:40, Phillip J. Eby wrote:
At 04:36 PM 1/12/05 +0100, Alex Martelli wrote:
I already know -- you told us so -- that if I had transitivity as you
wish it (uncontrollable, unstoppable, always-on) I could not any more
write and reg
This is a collection of responses to various things that don't appear
to have been resolved yet:
Phillip writes:
> if a target protocol has optional aspects, then lossy adaptation to it is
> okay by definition. Conversely, if the aspect is *not* optional, then
> lossy adaptation to it is not acce
On 2005 Jan 12, at 17:40, Phillip J. Eby wrote:
At 04:36 PM 1/12/05 +0100, Alex Martelli wrote:
I already know -- you told us so -- that if I had transitivity as you
wish it (uncontrollable, unstoppable, always-on) I could not any more
write and register a perfectly reasonable adapter which fills
At 04:36 PM 1/12/05 +0100, Alex Martelli wrote:
I already know -- you told us so -- that if I had transitivity as you wish
it (uncontrollable, unstoppable, always-on) I could not any more write and
register a perfectly reasonable adapter which fills in with a NULL an
optional field in the adapte
On 2005 Jan 12, at 16:49, Guido van Rossum wrote:
[Phillip]
As for the issue of what should and shouldn't exist in Python, it
doesn't
really matter; PEP 246 doesn't (and can't!) *prohibit* transitive
adaptation.
Really? Then isn't it underspecified? I'd think that by the time we
actually implement
On 2005 Jan 12, at 16:45, Guido van Rossum wrote:
My personal POV here: even when you break Liskov in subtle ways, there
are lots of situations where assuming substitutability has no ill
effects, so I'm happy to pretend that a subclass is always a subtype
of all of its base classes, (and their base
On 2005 Jan 12, at 16:44, Thomas Heller wrote:
...
conform = getattr(type(obj), '__conform__', None)
...
I'm confused. Do you mean that
getattr(obj, "somemethod")(...)
does something different than
obj.somemethod(...)
with new style class instances? Doesn't getattr search the __dic
[Armin]
> > ... is that the __adapt__() and __conform__() methods should work just
> > like all other special methods for new-style classes. The confusion
> > comes from the fact that the reference implementation doesn't do that.
> > It should be fixed by replacing:
> >
> >conform = getattr(ty
On 2005 Jan 12, at 16:26, Guido van Rossum wrote:
...
[Alex]
I'm saying that if, by mistake, the programmer has NOT
registered the A->C adapter (which would be easily coded and work
perfectly), then thanks to transitivity, instead of a clear and simple
error message leading to immediate diagnosi
[Phillip]
> As for the issue of what should and shouldn't exist in Python, it doesn't
> really matter; PEP 246 doesn't (and can't!) *prohibit* transitive
> adaptation.
Really? Then isn't it underspecified? I'd think that by the time we
actually implement PEP 246 in the Python core, this part of th
[Alex]
> Of course, it's possible that some such wrappers are coded much
> more tighter &c, so that in fact some roundabout A -> X1 -> X2 -> C
> would actually be better performing than either A -> B -> C or A -> Z
> -> C, but using one of the shortest available paths appears to be a
> reasonable h
Armin Rigo <[EMAIL PROTECTED]> writes:
> ... is that the __adapt__() and __conform__() methods should work just
> like all other special methods for new-style classes. The confusion
> comes from the fact that the reference implementation doesn't do that.
> It should be fixed by replacing:
>
>
On 2005 Jan 12, at 16:12, Phillip J. Eby wrote:
At 02:27 PM 1/12/05 +, Mark Russell wrote:
I strongly prefer *not* to have A->B and B->C automatically used to
construct A->C. Explicit is better than implicit, if in doubt don't
guess, etc etc.
So I'd support:
- As a first cut, no automatic
[Alex]
> I'm saying that if, by mistake, the programmer has NOT
> registered the A->C adapter (which would be easily coded and work
> perfectly), then thanks to transitivity, instead of a clear and simple
> error message leading to immediate diagnosis of the error, they'll get
> a subtle unnecessar
At 02:27 PM 1/12/05 +, Mark Russell wrote:
I strongly prefer *not* to have A->B and B->C automatically used to
construct A->C. Explicit is better than implicit, if in doubt don't
guess, etc etc.
So I'd support:
- As a first cut, no automatic transitive adaptation
- Later, and only if e
On 2005 Jan 12, at 15:00, Paul Moore wrote:
On Wed, 12 Jan 2005 00:33:22 +0100, Alex Martelli <[EMAIL PROTECTED]>
wrote:
By imposing transitivity, you're essentially asserting that, if a
programmer forgets to code and register an A -> C direct adapter, this
is never a problem, as long as A -> B an
I strongly prefer *not* to have A->B and B->C automatically used to
construct A->C. Explicit is better than implicit, if in doubt don't
guess, etc etc.
So I'd support:
- As a first cut, no automatic transitive adaptation
- Later, and only if experience shows there's a need for it,
On 2005 Jan 12, at 14:44, Paul Moore wrote:
On Wed, 12 Jan 2005 00:33:22 +0100, Alex Martelli <[EMAIL PROTECTED]>
wrote:
But adaptation is not transmission! It's PERFECTLY acceptable for an
adapter to facade: to show LESS information in the adapted object than
was in the original. It's PERFECTLY
On Wed, 12 Jan 2005 00:33:22 +0100, Alex Martelli <[EMAIL PROTECTED]> wrote:
> By imposing transitivity, you're essentially asserting that, if a
> programmer forgets to code and register an A -> C direct adapter, this
> is never a problem, as long as A -> B and B -> C adapters are
> registered, bec
On Wed, 12 Jan 2005 00:33:22 +0100, Alex Martelli <[EMAIL PROTECTED]> wrote:
> But adaptation is not transmission! It's PERFECTLY acceptable for an
> adapter to facade: to show LESS information in the adapted object than
> was in the original. It's PERFECTLY acceptable for an adapter to say
> "th
Clark C. Evans wrote:
On Tue, Jan 11, 2005 at 12:54:36PM -0500, Phillip J. Eby wrote:
...
| * In my experience, incorrectly deriving an interface from another is the
| most common source of unintended adaptation side-effects, not adapter
| composition
It'd be nice if interfaces had a way to spec
At 07:52 PM 1/11/05 -0500, Raymond Hettinger wrote:
Also, it is not clear to me how or if existing manual adaption practices
should change. For example, if I need a file-like interface to a
string, I currently wrap it with StringIO. How will that change it the
future? By an explicit adapt/confor
I'm trying to understand the relation between Guido's posts on optional
static typing and PEP 245 (interfaces) and 246 (adaptation). I have a
couple of questions
PEP 245 proposes to introduce a fundamental distinction between type and
interface. However, 245 only introduces a syntax for inte
At 12:33 AM 1/12/05 +0100, Alex Martelli wrote:
But adaptation is not transmission! It's PERFECTLY acceptable for an
adapter to facade: to show LESS information in the adapted object than was
in the original.
It's also true that it's acceptable for a router to choose not to forward
packets, e.g
> Thus, my argument is that an adapter like this should never be made
part
> of
> the adapter system, even if there's no transitivity. However, if you
> agree
> that such an adapter shouldn't be implicit, then it logically follows
that
> there is no problem with allowing transitivity, except of co
At 06:38 PM 1/11/05 -0500, Clark C. Evans wrote:
| To implement a Liskov violation with my proposal, you do exactly the same
| as with your proposal, *except* that you can simply return None instead
| of raising an exception, and the logic for adapt() is more
| straightforward.
I think I prefer jus
On Tue, Jan 11, 2005 at 03:30:19PM -0500, Phillip J. Eby wrote:
| Clark said he didn't want to assume substitutability; I was pointing out
| that he could choose to not assume that, if he wished, by implementing an
| appropriate __conform__ at the base of his hierarchy.
Oh, that's sufficient.
On 2005 Jan 11, at 22:08, Phillip J. Eby wrote:
...
Yes, you're ALLOWED to stuff with NULL any field that isn't
explicitly specified as NOT NULL.
But you should ONLY do so when the information is REALLY missing, NOT
when you've lost it along the way because you've implemented
adapter-chain t
At 09:10 PM 1/11/05 +0100, Alex Martelli wrote:
On 2005 Jan 11, at 20:48, Phillip J. Eby wrote:
...
I'd rather not assume that class inheritance implies substitutability,
Hm, you should take that up with Alex then, since that is what his
current PEP 246 draft does. :) Actually, the earlier dr
At 09:23 PM 1/11/05 +0100, Alex Martelli wrote:
Is the concept of *PRAGMATICS* so deucedly HARD for all of your eggheads?!
Hmm. Pot, meet kettle. :)
Yes, you're ALLOWED to stuff with NULL any field that isn't explicitly
specified as NOT NULL.
But you should ONLY do so when the information is R
On 2005 Jan 11, at 20:48, Phillip J. Eby wrote:
...
I'd rather not assume that class inheritance implies substitutability,
Hm, you should take that up with Alex then, since that is what his
current PEP 246 draft does. :) Actually, the earlier drafts did that
too, so I'm not sure why you want
On 2005 Jan 11, at 20:44, Phillip J. Eby wrote:
...
If we're just recomending that people design for transitivity, then I
don't have a problem (although see Alex's fairly good point
illustrated
with LotsOfInfo, PersonName, and FullName -- I found it convincing).
It's a bit misleading, however;
At 01:50 PM 1/11/05 -0500, Clark C. Evans wrote:
On Tue, Jan 11, 2005 at 12:54:36PM -0500, Phillip J. Eby wrote:
| * Replacing LiskovViolation is possible by dropping type/isinstance
| checks from adapt(), and adding an isinstance check to
| object.__conform__; Liskov violators then override __conf
At 10:47 AM 1/11/05 -0800, Michael Chermside wrote:
I'd agree except for the case where I am trying to pass an object
into code which is misbehaving. If we do add type declarations that
trigger an adapt() call, then people WILL write poor code which
declares concrete types, and I will find myself w
David Ascher writes:
> Terminology point: I know that LiskovViolation is technically correct,
> but I'd really prefer it if exception names (which are sometimes all
> users get to see) were more informative for people w/o deep technical
> background. Would that be possible?
I don't see how. Googl
Alex Martelli wrote:
On 2005 Jan 10, at 23:15, Thomas Heller wrote:
Alex Martelli <[EMAIL PROTECTED]> writes:
PEP: 246
Title: Object Adaptation
Minor nit (or not?): You could provide a pointer to the Liskov
substitution principle, for those reader that aren't too familiar with
that term.
Excellen
On Tue, Jan 11, 2005 at 12:54:36PM -0500, Phillip J. Eby wrote:
| * Replacing LiskovViolation is possible by dropping type/isinstance
| checks from adapt(), and adding an isinstance check to
| object.__conform__; Liskov violators then override __conform__ in their
| class to return None when ask
I wrote:
> >... but in my world, half the time I'm using adaptation to
> >correct for the fact that someone else's poorly-written
> >code requests some class where it should have just used
> >an interface.
Phillip replies:
> PEP 246 adaptation? Or are you talking about some other language?
> (I a
At 11:59 AM 1/11/05 +0100, Alex Martelli wrote:
On 2005 Jan 11, at 11:01, Alex Martelli wrote:
On 2005 Jan 10, at 18:59, Phillip J. Eby wrote:
At 12:43 PM 1/10/05 -0500, Phillip J. Eby wrote:
As a practical matter, all of the existing interface systems (Zope,
PyProtocols, and even the defunct Twis
At 09:27 AM 1/11/05 -0800, Michael Chermside wrote:
Phillip:
I think you must inhabit a far more perfect world than I do.
You say, for instance, that:
> ...-1 if this introduces a performance penalty [...] just to
> support people who want to create deliberate Liskov violations.
> I personally don'
At 10:59 AM 1/11/05 +0100, Alex Martelli wrote:
all you have to do is ADD
def __conform__(self, protocol):
if issubclass(protocol, Abstract):
raise LiskovViolation
that's all.
That will raise a TypeError if protocol is not a class or type, so this
could probably serve as an
At 10:34 AM 1/11/05 +0100, Alex Martelli wrote:
The volume of these discussions is (as expected) growing beyond any
reasonable bounds; I hope the BDFL can find time to read them but I'm
starting to doubt he will. Since obviously we're not going to convince
each other, and it seems to me we're a
On 2005 Jan 11, at 18:27, Michael Chermside wrote:
...
... but in my world, people violate Liskov all the time, even
in languages that attempt (unsuccessfully) to enforce it. [1]
...
[1] - Except for Eiffel. Eiffel seems to do a pretty good job
of enforcing it.
...has Eiffel stopped its he
Phillip:
I think you must inhabit a far more perfect world than I do.
You say, for instance, that:
> ...-1 if this introduces a performance penalty [...] just to
> support people who want to create deliberate Liskov violations.
> I personally don't think that we should pander to Liskov
> violator
On 2005 Jan 11, at 16:34, Phillip J. Eby wrote:
...
Anyway, I agree that your version of the code should be used to form
the reference implementation, since the purpose of the reference
implementation is to show the complete required semantics.
Great, one point at last on which we fully agree
At 12:41 PM 1/11/05 +, Armin Rigo wrote:
The point about tp_xxx slots is that when implemented in C with slots, you get
the latter (correct) effect for free. This is how metaconfusion is avoided in
post-2.2 Python. Using getattr() for that is essentially broken. Trying to
call the method and
Hi Phillip,
On Mon, Jan 10, 2005 at 04:38:55PM -0500, Phillip J. Eby wrote:
> Your new proposal does not actually fix this problem in the absence of
> tp_conform/tp_adapt slots; it merely substitutes possible confusion at the
> metaclass/class level for confusion at the class/instance level.
I
1 - 100 of 122 matches
Mail list logo
