On 2005 Jan 13, at 02:18, Phillip J. Eby wrote:
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 particul
On 2005 Jan 13, at 03:57, Phillip J. Eby wrote:
Okay, I'm really out of time now. Hate to dump this in as a possible
spoiler on PEP 246, because I was just as excited as Alex about the
possibility of it going in. But this whole debate has made me even
less enamored of adaptation, and more inte
On Thu, 13 Jan 2005 01:04:01 -0500, Phillip J. Eby
<[EMAIL PROTECTED]> wrote:
> 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.
I was talking about how you declare such
Hi Guido,
On Wed, Jan 12, 2005 at 09:59:13AM -0800, Guido van Rossum wrote:
> The descriptor for __getattr__ and other special attributes could
> claim to be a "data descriptor"
This has the nice effect that x[y] and x.__getitem__(y) would again be
equivalent, which looks good.
On the other hand
On 2005 Jan 12, at 18:59, Guido van Rossum wrote:
...
[Alex]
Armin's fix was to change:
...
[And then proceeds to propose a new API to improve the situation]
I wonder if the following solution wouldn't be more useful (since less
code will have to be changed).
The descriptor for __getattr__ an
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
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
>
Michael Walter wrote:
Yepyep, but *how* you declare types now? Can you quickly type the function
def f(x): x.read()? without needing an interface interface x_of_f: def
read(): pass or a decorator like @foo(x.read)? I've no idea what you
mean, really :o)
Why would something like
def f(x):
x.re
At 10:18 PM 1/13/05 +1000, Nick Coghlan wrote:
Michael Walter wrote:
Yepyep, but *how* you declare types now? Can you quickly type the function
def f(x): x.read()? without needing an interface interface x_of_f: def
read(): pass or a decorator like @foo(x.read)? I've no idea what you
mean, really :o
At 08:50 AM 1/13/05 +0100, Alex Martelli wrote:
Your proposals are novel and interesting. They also go WAY deeper into a
critical reappraisal of the whole object model of Python, which has always
been quite reasonably close to the above-mentioned "canon" and indeed has
been getting _more_ so, r
Ahhh, there we go, so "file" is type you declare. All I was asking
for, I thought you were thinking in a different/"more sophisticated"
direction (because what "f" actually wants is not a file, but a "thing
which has a read() like file" -- I thought one would like to manifest
that in the type inste
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
stelios> Yes but in order to fall into a Liskov Violation, one will have
stelios> to use extreme OOP features (as I understand from the ongoing
stelios> discussion for which, honestly, I understand nothing:).
The first example here:
http://www.compulink.co.uk/~querrid/STANDARD/l
At 09:00 AM 1/13/05 +0100, Alex Martelli wrote:
Incidentally, "get this specialmethod from the type (with specialcasing
for classic classes &c)" is a primitive that PEP 246 needs as much as,
say, copy.py needs it. In the light of the recent discussions of how to
fix copy.py etc, I'm unsure abou
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, 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 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
At 10:16 AM 1/13/05 +, Armin Rigo wrote:
On the other hand, I fear that if there is a standard "metamethod" decorator
(named after Phillip's one), it will be misused. Reading the documentation
will probably leave most programmers with the feeling "it's something magical
to put on methods with
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
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
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 writes:
> IMO, it's simpler to handle this use case by letting __conform__
return
> None, since this allows people to follow the One Obvious Way to not
conform
> to a particular protocol.
>
> Then, there isn't a need to even worry about the exception name in the
> first place, either...
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
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
> > The descriptor for __getattr__ and other special attributes could
> > claim to be a "data descriptor"
>
> This has the nice effect that x[y] and x.__getitem__(y) would again be
> equivalent, which looks good.
>
> On the other hand, I fear that if there is a standard "metamethod" decorator
> (
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 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 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
At 09:02 AM 1/13/05 -0800, Guido van Rossum wrote:
[Armin]
> I guess that a name-based hack in type_new() to turn all __*__()
methods into
> data descriptors would be even more obscure?
To the contary, I just realized in this would in fact be the right
approach. In particular, any *descriptor* na
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 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 18:02, Guido van Rossum wrote:
...
In all cases, I'm +1 on seeing built-in method objects
(PyMethodDescr_Type)
become data descriptors ("classy descriptors?" :-).
Let's do override descriptors.
A Pronouncement!!!
And please, someone fix copy.py in 2.3 and 2.4.
Sure -- what wa
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
Terry Reedy wrote:
"Scott David Daniels" <[EMAIL PROTECTED]>
I believe our current policy is that the author warrants that the code
is his/her own work and not encumbered by any patent.
Without a qualifier such as 'To the best of my knowledge', the latter is an
impossible warrant both practically,
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
For a little background, I'm working on making an edit and continue
support in python a little more robust. So, in replacing references to
unmodifiable types like tuples and bound-methods (instance or class), I
iterate over gc.get_referrers.
So, I'm working on frame types, and wrote this code:
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 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
Shane Holloway (IEEE) wrote:
For a little background, I'm working on making an edit and continue
support in python a little more robust. So, in replacing references to
unmodifiable types like tuples and bound-methods (instance or class), I
iterate over gc.get_referrers.
So, I'm working on fram
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 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
> > Let's do override descriptors.
>
> A Pronouncement!!!
>
> > And please, someone fix copy.py in 2.3 and 2.4.
>
> Sure -- what way, though? The way I proposed in my last post about it?
This would do it, right? (From your first post in this conversation
according to gmail:)
> Armin's fix was
On 2005 Jan 14, at 00:11, Guido van Rossum wrote:
Let's do override descriptors.
A Pronouncement!!!
And please, someone fix copy.py in 2.3 and 2.4.
Sure -- what way, though? The way I proposed in my last post about
it?
This would do it, right? (From your first post in this conversation
according
Ok. I think we have identified two sorts of restrictions on the
sorts of adaptations one may want to have:
`stateless' the adaptation may only provide a result which
does not maintain its own state
`lossless' the adaptation preserves all information available
On Jan 13, 2005, at 20:03, Clark C. Evans wrote:
Ok. I think we have identified two sorts of restrictions on the
sorts of adaptations one may want to have:
`stateless' the adaptation may only provide a result which
does not maintain its own state
`lossless' the adaptation pre
> Then, Guido's 'Optional Static Typing',
>
> def f(X: Y):
> pass
>
>would be equivalent to
>
> def f(X):
> X = adapt(Y, True, True)
>
> In other words, while calling adapt directly would allow for any adapter;
> using the 'Static Typing' short-cut one would be
> Ok. I think we have identified two sorts of restrictions on the
> sorts of adaptations one may want to have:
>
> `stateless' the adaptation may only provide a result which
>does not maintain its own state
>
> `lossless' the adaptation preserves all information available
On Thu, Jan 13, 2005 at 08:08:43PM -0500, Bob Ippolito wrote:
| >Ok. I think we have identified two sorts of restrictions on the
| >sorts of adaptations one may want to have:
| >
| > `stateless' the adaptation may only provide a result which
| > does not maintain its own state
| >
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:
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
A couple months ago I proposed (maybe in a SF bug report) that
time.strptime() grow some way to parse time strings containing fractional
seconds based on my experience with the logging module. I've hit that
stumbling block again, this time in parsing files with timestamps that were
generated using
Skip Montanaro wrote:
A couple months ago I proposed (maybe in a SF bug report)
http://www.python.org/sf/1006786
that
time.strptime() grow some way to parse time strings containing fractional
seconds based on my experience with the logging module. I've hit that
stumbling block again, this time in
At 08:03 PM 1/13/05 -0500, Clark C. Evans wrote:
Ok. I think we have identified two sorts of restrictions on the
sorts of adaptations one may want to have:
`stateless' the adaptation may only provide a result which
does not maintain its own state
`lossless' the adaptation pre
On Thu, Jan 13, 2005 at 11:50:37PM -0500, Phillip J. Eby wrote:
| 'lossless' isn't really a good term for non-noisy. The key is that a
| "noisy" adapter is one that alters the precision of the information it
| provides, by either claiming greater precision than is actually present,
| or by losi
At 05:52 PM 1/13/05 -0800, Guido van Rossum wrote:
This may solve the curernt raging argument, but IMO it would make the
optional signature declaration less useful, because there's no way to
accept other kind of adapters. I'd be happier if def f(X: Y) implied X
= adapt(X, Y).
The problem is that ty
At 12:00 AM 1/14/05 -0500, Clark C. Evans wrote:
On Thu, Jan 13, 2005 at 11:50:37PM -0500, Phillip J. Eby wrote:
| 'lossless' isn't really a good term for non-noisy. The key is that a
| "noisy" adapter is one that alters the precision of the information it
| provides, by either claiming greater pr
[Guido]
> >This may solve the curernt raging argument, but IMO it would make the
> >optional signature declaration less useful, because there's no way to
> >accept other kind of adapters. I'd be happier if def f(X: Y) implied X
> >= adapt(X, Y).
[Phillip]
> The problem is that type declarations re
At 10:20 PM 1/13/05 -0800, Guido van Rossum wrote:
[Guido]
> >This may solve the curernt raging argument, but IMO it would make the
> >optional signature declaration less useful, because there's no way to
> >accept other kind of adapters. I'd be happier if def f(X: Y) implied X
> >= adapt(X, Y).
[P
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
59 matches
Mail list logo
