Guido van Rossum wrote:
> Would it be okay to list the filename and line no instead of the
> class? That information is readily available from the code object.
Yes, that would be fine.
> (I'm assuming you're talking about Python functions/methods, not C
> ones --
Mainly, yes.
> for those, teh
On 5/10/06, Bill Janssen <[EMAIL PROTECTED]> wrote:
> Guido writes:
> > The crux of the matter seems to be how to add behavior *after* you
> > already have an instance of a class -- or, equivalently (?), how to
> > add behavior to a class when you have no control over the code that
> > creates inst
Guido writes:
> The crux of the matter seems to be how to add behavior *after* you
> already have an instance of a class -- or, equivalently (?), how to
> add behavior to a class when you have no control over the code that
> creates instances of it.
I have no contribution to make about either of t
On 5/10/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> Many people (including Guido, IIRC) have pointed out the severe limitations
> of your proposal, but you keep ignoring them. As far as I can tell, it is
> you who has proposed to break Python's type system by eliminating
> attribute-based duck
On 5/8/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> While we're on the subject, something that causes me
> intense annoyance from time to time is when I get a
> message like "Method foobar expects m args, got n",
> but it doesn't tell me *which* of the myriad foobar
> methods in my program it was tr
At 11:31 AM 5/10/2006 -0700, Bill Janssen wrote:
> > Which makes them inferior to existing adaptation systems for Python, which
> > in turn are inferior to generic functions.
>
>"Inferior" according to some belief system you obviously feel strongly
>about.
According to a very straightforward defin
"Phillip J. Eby" <[EMAIL PROTECTED]> writes:
> Note that if the notion of "interface" is reduced to "a set of generic
> functions to which an object may be passed", then it's not necessary
> to have explicit interface declaration - it's an automatic side effect
> of implementing methods for the ge
On 5/10/06, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > It only lets you inherit behaviour to new subclasses
> Not that it matters, but... Yes, that's right. In systems like
> these, that's how you "add functionality to already existing classes";
> you mix them with the new functionality into a
At 10:12 AM 5/10/2006 -0700, Bill Janssen wrote:
> > >> this approach doesn't do anything beyond what Java does
> > >
> > >Actually, it does. It lets you inherit behavior, as well as interfaces.
> >
> > It only lets you inherit behaviour to new subclasses
>
>Not that it matters, but...
Clearly it
> >> this approach doesn't do anything beyond what Java does
> >
> >Actually, it does. It lets you inherit behavior, as well as interfaces.
>
> It only lets you inherit behaviour to new subclasses
Not that it matters, but... Yes, that's right. In systems like
these, that's how you "add functio
At 04:59 PM 5/10/2006 +0200, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]>
wrote:
>Explicitly declared interfaces have a partial order, which is useful
>for dispatch.
Note that if the notion of "interface" is reduced to "a set of generic
functions to which an object may be passed", then it's not
Talin <[EMAIL PROTECTED]> writes:
> OK, so I hope I have established the requirement for duck typing.
> Now, I want to establish the requirement for interface discovery
> or 'type testing'.
These two are mutually incompatible. At least if we expect libraries
to be reliable and robust.
Python mus
On Wednesday, May 10, 2006, at 08:26AM, Bill Janssen <[EMAIL PROTECTED]> wrote:
>> If I understand your proposal correctly, this approach doesn't do anything
>> beyond what Java does, and is inferior to already-available adaptation and
>> interface systems for today's Python.
>
>Inferior is in
> If I understand your proposal correctly, this approach doesn't do anything
> beyond what Java does, and is inferior to already-available adaptation and
> interface systems for today's Python.
Inferior is in the eye of the beholder, I suppose. This is what
Python 2.x already provides.
> this
At 06:48 PM 5/9/2006 -0700, Bill Janssen wrote:
>Using mixins, you'd do something like:
>
>class adapted_mytype (sequential_ordering, mytype):
> def len(self):
> return self.nitems()
>
>You can now use "adapted_mytype", which respects both the
>"sequential_ordering" protoco
> Currently in Python for a third party to add a mixin, they would
> have to hack the class's __bases__, which I am not suggesting here at all.
I'm not suggesting it either. Here's what I meant:
Consider the type "sequential_ordering", which has methods
len() => INTEGER
iter(
Phillip J. Eby telecommunity.com> writes:
> Assuming we used argument declarations to do overloading, and that actual
> types (other than 'object') are considered to be more specific than
> typeclasses, you would have something like:
Lets start a new top-level thread to discuss this specific
p
Phillip J. Eby telecommunity.com> writes:
> Assuming we used argument declarations to do overloading, and that actual
> types (other than 'object') are considered to be more specific than
> typeclasses, you would have something like:
>
> @overloaded
> def flatten(arg:supports(iter)):
At 09:57 AM 5/9/2006 -0700, Talin wrote:
>Let me offer the following example as a basis for discussion, and see how
>it would work in such a system. (People who have different ideas as to how
>it should be done feel free to chime in -- I want to hear what other
>techniques are out there.)
>
>Let
At 09:56 AM 5/9/2006 -0700, Mike Krell wrote:
>On 5/9/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>>At 06:19 AM, 9 May 2006 +, Talin <[EMAIL PROTECTED]> wrote:
>> >Now, generic functions are good at dealing with these kinds of
>> >situations. However, generic functions (as they are usually co
Phillip J. Eby wrote:
> At 06:19 AM, 9 May 2006 +, Talin <[EMAIL PROTECTED]> wrote:
>
> In Haskell, interfaces are defined using "typeclasses". A typeclass is
> basically a collection of generic functions. For example, you could
> define a "sortable" typeclass that includes the generic fun
On 5/9/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 06:19 AM, 9 May 2006 +, Talin <[EMAIL PROTECTED]> wrote:
> >Now, generic functions are good at dealing with these kinds of
> >situations. However, generic functions (as they are usually concieved)
> >can only deal with specific, concrete
At 09:35 AM 5/9/2006 -0700, Bill Janssen wrote:
>Phillip Eby writes:
> > In Haskell, interfaces are defined using "typeclasses". A typeclass is
> > basically a collection of generic functions. For example, you could
> define
> > ...
> > Further, Haskell has a concept of "typeclass instances" whi
Phillip Eby writes:
> In Haskell, interfaces are defined using "typeclasses". A typeclass is
> basically a collection of generic functions. For example, you could define
> ...
> Further, Haskell has a concept of "typeclass instances" which basically
> give you adaptation. For example, suppose
At 06:19 AM, 9 May 2006 +, Talin <[EMAIL PROTECTED]> wrote:
>Now, generic functions are good at dealing with these kinds of
>situations. However, generic functions (as they are usually concieved)
>can only deal with specific, concrete types, not "types which satisfy
>some constraint".
In Haske
Talin wrote:
> (Think of a music scoring program, which
> displays various kinds of Midi events in a piano roll view, a drum
> machine view, a text view, or a music notation view.)
There is another way of handling things like this, using
a technique known as "double dispatching". For example
t
Guido van Rossum wrote:
> Now we're talking. Although it might make more sense if (an
> abbreviated form of) its repr() were included in the error message --
> that would help most humans diagnose the situation most easily.
While we're on the subject, something that causes me
intense annoyance fro
Jim Jewett gmail.com> writes:
> On 5/8/06, Talin acm.org> wrote:
> > Before we go to much further on this point, I want to get a sense of
> > what exactly people are objecting to:
>
> > -- Are they saying that interface discovery is not important, or is
> > bad style?
>
> Not in principle.
Guido van Rossum wrote:
> Well, personally, I don't see the advantage. I don't see the point of
> having lots of different exception types that say "you made a
> programming error" in different ways, and I severely doubt the
> usefulness of being able to distinguish between those different
> failur
Now we're talking. Although it might make more sense if (an
abbreviated form of) its repr() were included in the error message --
that would help most humans diagnose the situation most easily.
--Guido
On 5/8/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Mon, 2006-05-08 at 20:51 -0700, Guido v
On Mon, 2006-05-08 at 20:51 -0700, Guido van Rossum wrote:
> Well, personally, I don't see the advantage. I don't see the point of
> having lots of different exception types that say "you made a
> programming error" in different ways, and I severely doubt the
> usefulness of being able to distingui
Well, personally, I don't see the advantage. I don't see the point of
having lots of different exception types that say "you made a
programming error" in different ways, and I severely doubt the
usefulness of being able to distinguish between those different
failure modes at run time. Others do. I
On 5/8/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 5/8/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > It'd certainly be nice to be able to tell the difference between
> > the following two TypeErrors:
> >
> > >>> def s():
> > ... raise TypeError()
> > ...
> > >>> 's'
On 5/8/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> It'd certainly be nice to be able to tell the difference between
> the following two TypeErrors:
>
> >>> def s():
> ... raise TypeError()
> ...
> >>> 's'()
> Traceback (most recent call last):
> File "", line 1, in
On Mon, 2006-05-08 at 09:47 -0600, Steven Bethard wrote:
> On 5/8/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> > Perhaps then, if we get rid of callable()/PyCallable_Check() it would be
> > useful to add a NotCallableError (as a subclass of TypeError?) that
> > would get thrown should you try to c
On Mon, 2006-05-08 at 20:36 +0200, Marcin 'Qrczak' Kowalczyk wrote:
> Barry Warsaw <[EMAIL PROTECTED]> writes:
>
> > Obviously if someone registers a callback that isn't callable,
> > we don't want to waste time on every iteration trying to call it,
> > only to catch whatever error might occur.
>
Barry Warsaw <[EMAIL PROTECTED]> writes:
> Obviously if someone registers a callback that isn't callable,
> we don't want to waste time on every iteration trying to call it,
> only to catch whatever error might occur.
Who cares about performance of wrong code?
--
__("< Marcin Kowalcz
On 5/8/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> Perhaps then, if we get rid of callable()/PyCallable_Check() it would be
> useful to add a NotCallableError (as a subclass of TypeError?) that
> would get thrown should you try to call something that's not callable.
> The argument to the exceptio
Talin writes:
> Before we go to much further on this point, I want to get a sense of
> what exactly people are objecting to:
Good question. Answers below (speaking for myself only, of course!):
> -- Are they saying that interface discovery is not important, or is
> bad style? (Its hard to do
On Mon, 2006-05-08 at 15:55 +0200, Thomas Wouters wrote:
> Dare I suggest you convince Guido not to remove callable(), then? That
> is, after all, what this discussion is about.
We use callable() and PyCallable_Check() in a couple of places. I'm not
sure that our uses are enough to keep these al
On 5/8/06, Talin <[EMAIL PROTECTED]> wrote:
> Before we go to much further on this point, I want to get a sense of
> what exactly people are objecting to:
> -- Are they saying that interface discovery is not important, or is
> bad style?
Not in principle.
In practice, certain implementation
On 5/8/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
it's spelled callable(), is successfully used in popular and well-designed API:s, is well-defined in terms of duck-typing, and all counter-examples we've seen on this list areutterly contrived.
Dare I suggest you convince Guido not to remove calla
Greg Ewing wrote:
>> A common Python idiom is to take different actions based on the capabilities
>> of an object rather than its type.
>
> I have no objection to that when the capability can be
> tested for easily and efficiently and without danger of
> causing undesirable side effects. But calla
Thomas Wouters wrote:
> Duck typing isn't "ask the object whether it can do this". Duck typing is
> "do this".
that's your own definition, by the way. the usual definition is the one in the
Python
tutorial:
Duck Typing
Pythonic programming style that determines an object's type by ins
On 5/8/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
Thomas Wouters wrote:> Duck typing isn't "ask the object whether it can do this". Duck typing is> "do this". I don't believe 'taking different actions based on capabilities'> is all that common, and it certainly breaks easily.
have you used callab
Paul Moore wrote:
> guess('y') is *both* a string and a callable. OK, so it's a contrived
> example
generalizing from one contrived example is worse than generalizing from
no example at all.
___
Python-3000 mailing list
Python-3000@python.org
http
Talin wrote:
> This 'isFunction' test that I am thinking of would only return true for
> user defined functions, built-in functions, and similar objects; It
> would not return true for classes or other objects that are technically
> functions in a mathematically pure sense, but which normal peo
Thomas Wouters wrote:
> Duck typing isn't "ask the object whether it can do this". Duck typing is
> "do this". I don't believe 'taking different actions based on capabilities'
> is all that common, and it certainly breaks easily.
have you used callable(), or are you just making things up ?
> It
On 5/8/06, Talin <[EMAIL PROTECTED]> wrote:
Thomas Wouters python.org> writes:> He is, and for the same reasons as callable(): there is no way to> tell whether an object is a mapping or a sequence (considering
> Python object of both 'types' implement __getitem__, and that's> it. If you don't beli
On 8-mei-2006, at 8:58, Talin wrote:
And *how* exactly would you implement your isFunction test
so as to detect the "naive, everyday concept of a function"
that you seem to want, in a way that does any better job
than the current callable()?
This 'isFunction' test that I am thinking of would
Paul Moore <[EMAIL PROTECTED]> wrote:
>> Lets say we outlaw the use of isSequence - how do you propose to
>> implement this type of pattern? Or are you saying that this pattern
>> is bad style?
>
> Generic (overloadable) functions. See the archives - it's possible the
> discussion was before you s
On 5/8/06, Talin <[EMAIL PROTECTED]> wrote:
> Lets say we outlaw the use of isSequence - how do you propose to
> implement this type of pattern? Or are you saying that this pattern is
> bad style?
Generic (overloadable) functions. See the archives - it's possible the
discussion was before you subs
Greg Ewing wrote:
> Talin wrote:
>
>> How about instead of 'callable', an "isFunction' test to go along
>> with 'isSequence' and 'isMapping'. (You aren't getting rid of those -
>> I hope...?)
>
>
> Yes, we are! And for much the same reasons!
I'll have more to say on this later - but for now, l
Talin wrote:
> How about instead of 'callable', an "isFunction' test to go along
> with 'isSequence' and 'isMapping'. (You aren't getting rid of those -
> I hope...?)
Yes, we are! And for much the same reasons!
And *how* exactly would you implement your isFunction test
so as to detect the "naive
Thomas Wouters python.org> writes:
> On 5/7/06, Talin acm.org> wrote:
>
> > How about instead of 'callable', an "isFunction' test to go alongwith
> > 'isSequence' and 'isMapping'. (You aren't getting rid of those
> > - I hope...?)
>
> He is, and for the same reasons as callable(): there is no w
On 5/7/06, Talin <[EMAIL PROTECTED]> wrote:
All right, I'll desist.[insert distinct sound of persistance]
How about instead of 'callable', an "isFunction' test to go alongwith 'isSequence' and 'isMapping'. (You aren't getting rid of those -I hope...?)He is, and for the same reasons as callable():
Talin <[EMAIL PROTECTED]> writes:
> How about instead of 'callable', an "isFunction' test to go along
> with 'isSequence' and 'isMapping'. (You aren't getting rid of those -
> I hope...?)
Such predicates, unless backed by some explicit or strict criterion
like isinstance, are as suspicious for me
Guido van Rossum python.org> writes:
> > 1) Getting rid of 'callable'.
> >
> > The reccomended replacement is "just call the object and catch the resulting
> > exception", but I can think of a lot of situations where that wouldn't be
> > appropriate. For example, what if you want to know if somet
On 5/6/06, Talin <[EMAIL PROTECTED]> wrote:
> I want to say that I agree with everything in PEP 3100 except for two things:
>
> 1) Getting rid of 'callable'.
>
> The reccomended replacement is "just call the object and catch the resulting
> exception", but I can think of a lot of situations where t
Le dimanche 07 mai 2006 à 17:47 +1200, Greg Ewing a écrit :
> Talin wrote:
>
> > 1) Getting rid of 'callable'.
> >
> > The reccomended replacement is "just call the object and catch the resulting
> > exception",
>
> No, the recommended replacement should be "redesign your API
> so that you don't
Greg Ewing wrote:
> Talin wrote:
>
>> (Admittedly this particular case could be done without 'callable', since you
>> could test for string type, and assume callable otherwise.
>
> Yes, and that's exactly why it can be made to work
> in this particular case. Most likely no testing for
> callabili
Talin wrote:
> (Admittedly this particular case could be done without 'callable', since you
> could test for string type, and assume callable otherwise.
Yes, and that's exactly why it can be made to work
in this particular case. Most likely no testing for
callability is being done, only isinstanc
Talin wrote:
> A common Python idiom is to take different actions based on the capabilities
> of an object rather than its type.
I have no objection to that when the capability can be
tested for easily and efficiently and without danger of
causing undesirable side effects. But callability is
not
On 5/7/06, Talin <[EMAIL PROTECTED]> wrote:
> As an example, lets take a look at re.sub:
>
>sub(pattern, repl, string[, count])
>
> The documentation says that "repl can be a string or a function" and
> "If repl is a function, it is called for every non-overlapping occurrence
> of pattern. The
Thomas Wouters python.org> writes:
> It may be 'common' for programmers to try and write this kind of
code (accept either a string or an instance, a sequence or a single
object, etc) but it's certainly not a common idiom -- idioms don't suck
As an example, lets take a look at re.sub:
sub(p
On 5/7/06, Talin <[EMAIL PROTECTED]> wrote:
Greg Ewing canterbury.ac.nz> writes:> Talin wrote:>> > 1) Getting rid of 'callable'.> >> > The reccomended replacement is "just call the object and catch the resulting
> > exception",>> No, the recommended replacement should be "redesign your API> so tha
Greg Ewing canterbury.ac.nz> writes:
> Talin wrote:
>
> > 1) Getting rid of 'callable'.
> >
> > The reccomended replacement is "just call the object and catch the resulting
> > exception",
>
> No, the recommended replacement should be "redesign your API
> so that you don't need to test whether
Talin wrote:
> 1) Getting rid of 'callable'.
>
> The reccomended replacement is "just call the object and catch the resulting
> exception",
No, the recommended replacement should be "redesign your API
so that you don't need to test whether something is callable".
--
Greg
___
I want to say that I agree with everything in PEP 3100 except for two things:
1) Getting rid of 'callable'.
The reccomended replacement is "just call the object and catch the resulting
exception", but I can think of a lot of situations where that wouldn't be
appropriate. For example, what if you
69 matches
Mail list logo
