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
implementat
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 modu
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, _nil
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
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
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 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
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 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
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
[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
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:
>
>
[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
[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
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
[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: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
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: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 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
> > envir
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 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
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
IBM has recently released 500 patents for use in opensource code.
http://www.ibm.com/ibm/licensing/patents/pledgedpatents.pdf
"...In order to foster innovation and avoid the possibility that a
party will take advantage of this pledge and then assert patents or
other intellectual pro
There is already a TimedRotatingFileHandler which will do backups on a
schedule, including daily.
The correct way of doing what you want is to submit a patch via
SourceForge. If the patch is accepted, then your code will end up in Python.
Thanks,
Vinay Sajip
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
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 sequenc
[Alex]
> Armin's fix was to change:
>
> conform = getattr(type(obj), '__conform__', None)
>
> into:
>
> for basecls in type(obj).__mro__:
> if '__conform__' in basecls.__dict__:
> conform = basecls.__dict__['__conform__']
> break
> else:
> # no
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
>>> 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 do
Scott> Since this includes patents on compression and encryption stuff,
Scott> we will definitely be faced with deciding on whether to allow use
Scott> of these patents in the main Python library.
Who is going to decide if a particular library would be affected by one or
more of the 5
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
I wrote:
> I don't see how [LiskovViolation could have a more descriptive name].
> Googling on Liskov immediately brings up clear and understandable
> descriptions of the principle
David writes:
> Clearly, I disagree. [...]
Skip writes:
> I had never heard the term before and consulted the Googl
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
> >>
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:
At 09:59 AM 1/12/05 -0800, Guido van Rossum wrote:
We would need to introduce a new decorator so that classes overriding
these methods can also make those methods "data descriptors", and so
that users can define their own methods with this special behavior
(this would be needed for __copy__, probab
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
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
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
On Wed, Jan 12, 2005, Guido van Rossum wrote:
>
> PS. The term "data descriptor" now feels odd, perhaps we can say "hard
> descriptors" instead. Hard descriptors have a __set__ method in
> addition to a __get__ method (though the __set__ method may always
> raise an exception, to implement a read-o
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
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 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*
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
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
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
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> programmi
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 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 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
Skip Montanaro <[EMAIL PROTECTED]> writes:
> 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 docum
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
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 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 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
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
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
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, 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
>You can argue that reading csv data from/writing csv data to a file on
>Windows if the file isn't opened in binary mode is an error. Perhaps we
>should enforce that in situations where it matters. Would this be a start?
>
>terminators = {"darwin": "\r",
> "win32": "\r\n"}
>
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.
>
>
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
Skip Montanaro wrote:
Michael> Guido writes:
>> How about SubstitutabilityError?
I don't think that's any better. At the very least, people can Google for
"Liskov violation" to educate themselves. I'm not sure that the results of
a Google search for "Subtitutability Error" will be any clear
"Scott David Daniels" <[EMAIL PROTECTED]>
> IBM has recently released 500 patents for use in opensource code.
>
> http://www.ibm.com/ibm/licensing/patents/pledgedpatents.pdf
>
> "...In order to foster innovation and avoid the possibility that a
> party will take advantage of this pledg
[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/)
__
Just van Rossum wrote:
> ...and then there are those Python users who have no formal CS
> background at all. Python is used quite a bit by people who's main job
> is not programming.
...and among us who do programming as a main job, I can assure that I'm
not the only one who, if told by a compute
On 12-jan-05, at 2:59, Skip Montanaro wrote:
terminators = {"darwin": "\r",
"win32": "\r\n"}
if (dialect.lineterminator != terminators.get(sys.platform, "\n")
and
"b" not in getattr(f, "mode", "b")):
raise IOError, ("%s not opened in binary mode" %
On Wed, 12 Jan 2005 19:49:06 -0500, Phillip J. Eby
<[EMAIL PROTECTED]> wrote:
> So the *only* way you can see
> this error is if you call __conform__ directly, and somebody added code
> like this:
>
> raise LiskovViolation
>
> So, it's not something you need to worry about a newbie seeing.
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?
On
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 document
>> The idea of the check is to enforce binary mode on those objects that
>> support a mode if the desired line terminator doesn't match the
>> platform's line terminator.
Andrew> Where that falls down, I think, is where you want to read an
Andrew> alien file - in fact, under u
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
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.
Wo
This is a pretty long post; it starts out as discussion of educational
issues highlighted by Clark and Ian, but then it takes the motivation for
PEP 246 in an entirely new direction -- possibly one that could be more
intuitive than interfaces and adapters as they are currently viewed in
Zope/Tw
>Isn't universal newlines only used for reading?
That right. And the CSV reader has it's own version of univeral newlines
anyway (from the py1.5 days).
>I have had no problems using the csv module for reading files with
>universal newlines by opening the file myself or providing an iterator.
Ne
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
Phillip,
In my mind, the driving use-case for PEP 246 was to allow causual
programmers to plug components together and have it 'just work'; it
does this by enabling the component vendors to carry on a discussion
via __adapt__ and __conform__ to work together. I was not picturing
that your average
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 appli
> 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 w
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 in
85 matches
Mail list logo
