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 at least getting close to
pinpointing our differ
On 2005 Jan 10, at 23:19, Phillip J. Eby wrote:
...
As I said, after more thought, I'm actually less concerned about the
performance than I am about even remotely encouraging the combination
of Liskov violation *and* concrete adaptation
As per other msg, abstract classes have just the same iss
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.
Excellent idea, thanks.
Besides
On 2005 Jan 10, at 19:34, Phillip J. Eby wrote:
...
IMO it's more desirable to support abstract base classes than to allow
classes to "opt out" of inheritance when testing conformance to a base
class. If you don't have an "is-a" relationship to your base class,
you should be using delegation
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 Twisted implementation) treat
interface inheritance as guaranteeing substitutability for the base
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 Twisted implementation) treat
interface inheritance
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
On Tue, 11 Jan 2005 08:54:42 +0100, "\"Martin v. Löwis\"" <[EMAIL PROTECTED]>
wrote:
>Philippe Biondi wrote:
> > I've done a small patch to use linux AF_NETLINK sockets (see below).
> > Please comment!
>
> I have a high-level comment - python-dev is normally the wrong place
> for patches; please
On Tue, 11 Jan 2005 01:32:52 +, David Wilson <[EMAIL PROTECTED]> wrote:
>On Mon, Jan 10, 2005 at 05:17:49PM +0100, Philippe Biondi wrote:
>
> > I've done a small patch to use linux AF_NETLINK sockets (see below).
> > Please comment!
>
> As of 2.6.10, a very useful new netlink family was merge
On Tue, 11 Jan 2005, [ISO-8859-1] "Martin v. Löwis" wrote:
> Philippe Biondi wrote:
> > I've done a small patch to use linux AF_NETLINK sockets (see below).
> > Please comment!
>
> I have a high-level comment - python-dev is normally the wrong place
> for patches; please submit them to sf.net/proj
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
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
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
Dear people on the dev list!
I hope that this is the right environment to post my submission request
(I'm new to the scene).
I have modified the RotatingFileHandler of the logging module to create
a daily rolling file handler.
As it works quite good, I would like to suggest inclusion into the
Title: RE: [Python-Dev] logging class submission
[Stephan Stapel]
#- # Copyright 2004-2005 by Stephan Stapel <[EMAIL PROTECTED]>. All
#- Rights Reserved.
#- #
#- # Permission to use, copy, modify, and distribute this
#- software and its
#- # documentation for any purpose and without fee is
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
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
Title: RE: [Python-Dev] logging class submission
[Stephan Stapel]
#- > There's a license issue here?
#-
#- I was given the advise to use this license. If this license
#- prohibts inclusion into Python, how should I re-license the code?
I just was asking. Who gave you the advise?
.
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
On Tue, 2005-01-11 at 12:58, Batista, Facundo wrote:
> [Stephan Stapel]
>
> #- > There's a license issue here?
> #-
> #- I was given the advise to use this license. If this license
> #- prohibts inclusion into Python, how should I re-license the code?
>
> I just was asking. Who gave you the ad
> I just was asking. Who gave you the advise?
someon in a german python forum. I'll change the license asap.
I'm just curious, but do I really have to use the contributor agreement etc.? I
mean I'm just trying to submit a small class, no big framework.
cheers,
Stephan
_
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 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
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
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
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
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
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
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
To save everyone from having to wade through the lengthy discussions
between Alex and I, and to avoid putting all the summarization burden on
Alex, I thought I would start a new thread listing my concrete proposals
for PEP 246 changes, and summarizing my understanding of the current
agreements
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;
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
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
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
On 2005 Jan 11, at 23:20, Fredrik Lundh wrote:
back in Python 2.1 (and before), an object could define how copy.copy
should
work simply by definining a __copy__ method. here's the relevant
portion:
...
try:
copierfunction = _copy_dispatch[type(x)]
except KeyError:
tr
On 2005 Jan 11, at 23:39, Phillip J. Eby wrote:
...
cls = type(x)
copier = _copy_dispatch.get(cls)
if copier:
return copier(x)
...
this a bug, or a feature of the revised copy/pickle design?
Looks like a bug to me; it breaks the behavior of classic classes,
since type(cla
On 2005 Jan 11, at 23:58, Guido van Rossum wrote:
...
cls = type(x)
copier = _copy_dispatch.get(cls)
if copier:
return copier(x)
...
is this a bug, or a feature of the revised copy/pickle design?
[Phillip]
Looks like a bug to me; it breaks the behavior of classic classes,
Michael Chermside wrote:
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
> My point is that it'd be nice if we could come up with an exception name
> which could be grokkable without requiring 1) Google, 2) relatively
> high-level understanding of type theory.
How about SubstitutabilityError?
> The point is broader, though -- when I get my turn in the time machine,
>
Guido van Rossum wrote:
My point is that it'd be nice if we could come up with an exception name
which could be grokkable without requiring 1) Google, 2) relatively
high-level understanding of type theory.
How about SubstitutabilityError?
That would be far, far better, yes.
We did that for Unbound
At 11:56 PM 1/11/05 +0100, Alex Martelli wrote:
What "both issues"? There's only one issue, it seems to me -- one of
metaconfusion.
I was relying on Fredrik's report of a problem with the code; that is the
other "issue" I referred to.
___
Python-Dev m
At 11:20 PM 1/11/05 +0100, Fredrik Lundh wrote:
I recently discovered that this feature has disappeared in 2.3 and 2.4. in-
stead of looking for an instance method, the code now looks at the object's
type:
...
cls = type(x)
copier = _copy_dispatch.get(cls)
if copier:
return
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
[Fredrik]
> >I recently discovered that this feature has disappeared in 2.3 and 2.4. in-
> >stead of looking for an instance method, the code now looks at the object's
> >type:
> >
> > ...
> >
> > cls = type(x)
> >
> > copier = _copy_dispatch.get(cls)
> > if copier:
> > ret
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.
At 02:58 PM 1/11/05 -0800, Guido van Rossum wrote:
[Phillip]
> Looks like a bug to me; it breaks the behavior of classic classes, since
> type(classicInstance) returns InstanceType.
I'm not so sure. I can't seem to break this for classic classes.
Sorry; I was extrapolating from what I thought was F
Guido van Rossum wrote:
The point is broader, though -- when I get my turn in the time machine,
I'll lobby for replacing NameError with UndefinedVariable or something
Strange, my blog reading just hit upon
http://blogs.zdnet.com/open-source/index.php?p=93
...
"Perhaps as open source developers are
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
Would the csv module be a good place to add a DBF reader and writer?
Dbase's dbf file format is one of the oldest, simplest and more common
database interchange formats. It can be a good alternative to CSV as a
means of sharing data with pre-existing, non-python apps.
On the plus side, it has
back in Python 2.1 (and before), an object could define how copy.copy should
work simply by definining a __copy__ method. here's the relevant portion:
...
try:
copierfunction = _copy_dispatch[type(x)]
except KeyError:
try:
copier = x.__copy__
except
Guido van Rossum wrote:
> The only thing this intends to break /.../
it breaks classic C types:
>>> import cElementTree
>>> x = cElementTree.Element("tag")
>>> x
>>> x.__copy__
>>> x.__copy__()
>>> import copy
>>> y = copy.copy(x)
Traceback (most recent call last):
File "", line 1, in ?
F
> 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
>Would the csv module be a good place to add a DBF reader and writer?
I would have thought it would make sense as it's own module (in the same
way that we have separate modules that present a common interface for
the different databases), or am I missing something?
I'd certainly like to see a D
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
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 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
> Unfortunately, we do have a problem with the code in copy.py:
>
> class MetaCopyableClass(type):
> def __copy__(cls):
> """ code to copy CLASSES of this metaclass """
> # etc, etc, snipped
>
> class CopyableClass:
> __metaclass__ = MetaCopyableClass
> # rest of clas
57 matches
Mail list logo
