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
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
violators
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?
.
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 advise?
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't
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
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. Googling
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
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
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:
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,
I'll
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
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
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
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
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__
Guido van Rossum wrote:
The only thing this intends to break /.../
it breaks classic C types:
import cElementTree
x = cElementTree.Element(tag)
x
Element 'tag' at 00B4BA30
x.__copy__
built-in method __copy__ of Element object at 0x00B4BA30
x.__copy__()
Element 'tag' at 00B4BA68
import
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 course
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
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
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
24 matches
Mail list logo
