Since this bug isn't the cause of Fredrik's problem I'm changing the
subject (and keep discussing the specific problem that Fredrik
uncovered under the original subject).
On 2005 Jan 12, at 05:11, Guido van Rossum wrote:
...
I had exactly the same metabug in the pep 246 reference
I have started writing a patch that replaces PyOS_InputHook with
PyOS_AddInputHook and PyOS_RemoveInputHook. I am a bit confused though on how
hook functions are supposed to work with threads.
PyOS_InputHook is a pointer to a hook function, which can be defined for example
in a C extension
On 2005 Jan 12, at 00:30, Fredrik Lundh wrote:
Guido van Rossum wrote:
The only thing this intends to break /.../
it breaks classic C types:
True!!! And it only breaks copy, NOT deepcopy, because of the
following difference between the two functions in copy.py...:
def deepcopy(x, memo=None,
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
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
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
[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 unnecessary
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
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:
conform
[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 heuristic for
[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 the
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
[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(type(obj),
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
On Tue, Jan 11, 2005 at 02:15:23PM +, Jp Calderone wrote:
I would like to see (optional?) support for this before your patch is
merged. I have a long-term interest in a Python-based service control /
init replacement / system management application, for use in specialised
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
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
Raymond Would the csv module be a good place to add a DBF reader and
Raymond writer?
Not really.
Raymond I've posted a draft on ASPN. It interoperates well with the
Raymond rest of the CSV module because it also accepts/returns a list
Raymond of fieldnames and a sequence of
Andrew The csv parser consumes lines from an iterator, but it also has
Andrew it's own idea of end-of-line conventions, which are currently
Andrew only used by the writer, not the reader, which is a source of
Andrew much confusion. The writer, by default, also attempts to emit a
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
Skip Montanaro wrote:
Who is going to decide if a particular library would be affected by one or
more of the 500 patents IBM released?
Skip
I am thinking more along the lines of, our policy on accepting new code
[will/will not] be to allow new submissions which use some of that
patented code. I
[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
Now that Python 2.4 is out the door (and the problems with
StreamReader.readline() are hopefully fixed), I'd like bring
up the topic of a feed style codec API again. A feed style API
would make it possible to use stateful encoding/decoding where
the data is not available as a stream.
Two examples:
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 number
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
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*
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 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,
Michael This must be one of those cases where I am mislead by my
Michael background... I thought of Liskov substitution principle as a
Michael piece of basic CS background that everyone learned in school
Michael (or from the net, or wherever they learned
Michael programming).
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
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
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 C++.
Skip Montanaro wrote:
Michael This must be one of those cases where I am mislead by my
Michael background... I thought of Liskov substitution principle
Michael as a piece of basic CS background that everyone learned
Michael in school (or from the net, or wherever they
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
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
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 object,
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
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
At 05:54 PM 1/12/05 -0700, Steven Bethard wrote:
Not that my opinion counts for much =), but returning None does seem
much simpler to me. I also haven't seen any arguments against this
route of handling protocol nonconformance... Is there a particular
advantage to the exception-raising scheme?
At 02:03 PM 1/12/05 -0600, Skip Montanaro wrote:
I don't think that's appropriate in this case. Liskov violation is
something precise. I don't think that changing what you call it will help
beginners understand it any better in this case. I say leave it as it and
make sure it's properly
Jack On MacOSX you really want universal newlines. CSV files produced
Jack by older software (such as AppleWorks) will have \r line
Jack terminators, but lots of other programs will have files with
Jack normal \n terminators.
Won't work. You have to be able to write a Windows csv
On Jan 12, 2005, at 21:39, Skip Montanaro wrote:
Jack On MacOSX you really want universal newlines. CSV files
produced
Jack by older software (such as AppleWorks) will have \r line
Jack terminators, but lots of other programs will have files with
Jack normal \n terminators.
Won't
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 a
At 11:26 PM 1/12/05 -0500, Clark C. Evans wrote:
Regardless,
getting back to the main goal I had when writing PEP 246 -- your
alternative proposal still doesn't seem to provide a mechanism for
component developers to have a dialogue with one another to connect
components without involving the
instead interfaces can be defined in terms of individual operations, and
those operations can be initially defined by an abstract base, concrete
class, or an interface object.
I think this is quite problematic in the sense that it will force many
dummy interfaces to be created. At least
At 09:57 PM 1/12/05 -0500, Phillip J. Eby wrote:
class StringIO:
def read(self, bytes) implements file.read:
# etc...
could be used to indicate the simple case where you are conforming to an
existing operation definition. A third-party definition, of the same
thing might
At 12:01 AM 1/13/05 -0500, Michael Walter wrote:
What am I missing?
The fact that this is a type-declaration issue, and has nothing to do with
*how* types are checked.
Note that I'm only proposing:
1) a possible replacement for PEP 246 that leaves 'adapt()' as a function,
but uses a different
47 matches
Mail list logo
