On 7/28/06, Andrew Koenig <[EMAIL PROTECTED]> wrote:
> Methinks that the suggestion includes defining hashable(x) in such a way as
> to give the right answer, irrespective of how x.__hash__ is defined.
I'm getting tired of this discussion, so I'm just going to stop
reading this thread.
--
--Guid
Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Use cases for a "may be hashable" pretest are much weaker (and typically
> hypothetical), but there are cases where it makes a certain amount of sense.
> For example, if you have a set-based fast path if all the objects being
> handled are hashable, and
Andrew Koenig wrote:
> I note in PEP 3000 the proposal to remove callable(), with the comment "just
> call the object and catch the exception."
>
> I think that's a bad idea, because it takes away the ability to separate the
> callability test from the first call. As a simple example, suppose you
Marcin 'Qrczak' Kowalczyk wrote:
> Stefan Behnel <[EMAIL PROTECTED]> writes:
>
>> So, if hashable() returns True, it means that a) the designer didn't
>> care about switching it off or b) there are cases where it works, so
>> it makes sense to try calling it.
>
> If the code can successfully work
> Guido van Rossum wrote:
> > So how about we change callable() and add hashable(), iterable() and
> > whatever else makes sense so that these all become like this:
> >
> > def callable(x):
> > return getattr(x, "__call__", None) is not None
> This *still* doesn't fully solve the problem in
Stefan Behnel <[EMAIL PROTECTED]> writes:
> So, if hashable() returns True, it means that a) the designer didn't
> care about switching it off or b) there are cases where it works, so
> it makes sense to try calling it.
If the code can successfully work with either hashable or non-hashable
object
Marcin 'Qrczak' Kowalczyk wrote:
> Stefan Behnel <[EMAIL PROTECTED]> writes:
>
>> It just says: I support the protocol, so it makes sense to apply the
>> protocol operations to me if you need to.
>>
>> I think that's perfectly reasonable semantics for the three functions.
>
> I see no essential
Stefan Behnel <[EMAIL PROTECTED]> writes:
> It just says: I support the protocol, so it makes sense to apply the
> protocol operations to me if you need to.
>
> I think that's perfectly reasonable semantics for the three functions.
I see no essential difference between an object which doesn't sup
Steven Bethard wrote:
> On 7/27/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>>> So how about we change callable() and add hashable(), iterable() and
>>> whatever else makes sense so that these all become like this:
>>>
>>> def callable(x):
>>> return getattr(x, "__c
On 7/27/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > So how about we change callable() and add hashable(), iterable() and
> > whatever else makes sense so that these all become like this:
> >
> > def callable(x):
> > return getattr(x, "__call__", None) is not None
>
On 7/27/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > So how about we change callable() and add hashable(), iterable() and
> > whatever else makes sense so that these all become like this:
> >
> > def callable(x):
> > return getattr(x, "__call__", None) is not None
>
Guido van Rossum wrote:
> So how about we change callable() and add hashable(), iterable() and
> whatever else makes sense so that these all become like this:
>
> def callable(x):
> return getattr(x, "__call__", None) is not None
This *still* doesn't fully solve the problem in the case
of _
On 7/27/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> [1] It might get you something for __hash__() if object.__hash__() is
> not removed, but that debate still seems to be in progress and I'm not
> sure it's worth the added complexity to handle one special case.
FWIW, I don't believe your "solu
On 7/27/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> So how about we change callable() and add hashable(), iterable() and
> whatever else makes sense so that these all become like this:
>
> def callable(x):
> return getattr(x, "__call__", None) is not None
>
> This way classes can explic
On 7/26/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > I'd be happy to extend the convention to all such attributes --
> > setting it to None to mean that the subclass doesn't want to provide
> > it. That's clean, can't possibly be interpreted to mean anything else,
> > and
So how about we change callable() and add hashable(), iterable() and
whatever else makes sense so that these all become like this:
def callable(x):
return getattr(x, "__call__", None) is not None
This way classes can explicitly declare that they aren't callable,
hashable, iterable etc. by s
> While this makes sense from the perspective you mention, paraphrased
> as "different objects have different capabilities, and I want to query
> what capabilities this object has," I'm not convinced that any but the
> most uncommon uses involve enumerating the capabilities of an object.
> And thos
On 7/26/06, Andrew Koenig <[EMAIL PROTECTED]> wrote:
> * Uniform -- the general form of the inquiry does not
> depend on the particular capability being inquired about
While this makes sense from the perspective you mention, paraphrased
as "different objects have different
Guido van Rossum wrote:
> On 7/26/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>>class Unhashable(object):
>>__hash__ = Undefined
>
> Simpler: set it to None. That could be a convention.
>
And someone else pointed out that this could still be a trigger for NULL'ing
out slots at the C
Greg Ewing wrote:
> Guido van Rossum wrote:
>
>> I'd be happy to extend the convention to all such attributes --
>> setting it to None to mean that the subclass doesn't want to provide
>> it. That's clean, can't possibly be interpreted to mean anything else,
>> and doesn't require you to actually
Guido van Rossum wrote:
> I'd be happy to extend the convention to all such attributes --
> setting it to None to mean that the subclass doesn't want to provide
> it. That's clean, can't possibly be interpreted to mean anything else,
> and doesn't require you to actually call the attribute.
Altho
> > I felt uncomfortable about exposing the implementation that way
> ...but double-underscore methods are part of the language definition,
> not part of the implementation.
Yes and no. For example, it appears to be part of the language definition
that foo() is equivalent to foo.__call__(), but
Andrew Koenig writes:
> I started the thread because I wanted to call attention to an issue: Objects
> sometimes have properties that have side effects when exploited, and it can
> be useful to be able to test for the presence of such properties without
> evoking the side effects.
Good point. I ag
On 7/26/06, Andrew Koenig <[EMAIL PROTECTED]> wrote:
> In other words, the current notion appears to be:
>
> An object is callable iff it has a __call__ attribute.
>
> An object is hashable iff its __hash__ attribute is not None.
>
> This example only strengthens my original intuiti
> > I for one have gotten along quite happily without
> > ever wanting to test for hashability.
> Me too, as said elsewhere. This whole thread seems like a purely
> theoretical debate.
That may be because it has departed from its original intent.
I started the thread because I wanted to call att
On Wednesday 2006-07-26 07:20, Greg Ewing wrote:
> Andrew Koenig wrote:
> > I think of a
> > function f as being idempotent if f(x) == x for all x in dom(f).
>
> Um, that's an identity function, isn't it? I think
> you mean something more like f(f(x)) == f(x).
>
> But even that's not quite what w
On 7/26/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>class Unhashable(object):
>__hash__ = Undefined
Simpler: set it to None. That could be a convention.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-3000 maili
Greg Ewing wrote:
> Guido van Rossum wrote:
>
>> Personally, I'm not sure this problem needs solving; I don't recall
>> ever needing to know whether something is hashable.
>
> I for one have gotten along quite happily without
> ever wanting to test for hashability.
Me too, as said elsewhere. This
Greg Ewing wrote:
> Nick Coghlan wrote:
>
>> The use case is being able to block the inheritance of special methods
>> that object provides default implementations for (like '__hash__'),
>> such that a hasattr() check (or a check for a type slot being 0) for
>> those special methods will actual
Nick Coghlan wrote:
> The use case is being able to block the inheritance of special methods
> that object provides default implementations for (like '__hash__'), such
> that a hasattr() check (or a check for a type slot being 0) for those
> special methods will actually fail.
Maybe descriptor
Guido van Rossum wrote:
> Ouch, that's a problem indeed. There's not really a clean way out
> unfortunately: either we remove object.__hash__ and let hash() do the
> default implementation, and then presence of __hash__ is no longer an
> indicator of hashability; or we keep it, and override it to r
Guido van Rossum wrote:
> Personally, I'm not sure this problem needs solving; I don't recall
> ever needing to know whether something is hashable.
I for one have gotten along quite happily without
ever wanting to test for hashability.
--
Greg
___
Pyth
Andrew Koenig wrote:
> I think of a
> function f as being idempotent if f(x) == x for all x in dom(f).
Um, that's an identity function, isn't it? I think
you mean something more like f(f(x)) == f(x).
But even that's not quite what we're talking about
here, because we're not hashing the result of
Collin Winter wrote:
> On 7/25/06, Andrew Koenig <[EMAIL PROTECTED]> wrote:
>>> With your CD example, you need an external resource (the CD itself) in
>>> order to calculate the hash - in that case, you can't safely defer
>>> the hash calculation until the first time you know you need it,
>>> sinc
Ouch, that's a problem indeed. There's not really a clean way out
unfortunately: either we remove object.__hash__ and let hash() do the
default implementation, and then presence of __hash__ is no longer an
indicator of hashability; or we keep it, and override it to raise an
exception in unhashable
On 7/25/06, Andrew Koenig <[EMAIL PROTECTED]> wrote:
> > With your CD example, you need an external resource (the CD itself) in
> > order to calculate the hash - in that case, you can't safely defer
> > the hash calculation until the first time you know you need it,
> > since you don't know whether
Andrew Koenig wrote:
> It's still the case that evaluating a hash might be expensive the
> first time you do it, so you may want to be able to test whether it
> can be done and actually do it only later.
I think you're doing a lot of guess-work here. In real world situations,
computing the hash i
> With your CD example, you need an external resource (the CD itself) in
> order to calculate the hash - in that case, you can't safely defer
> the hash calculation until the first time you know you need it,
> since you don't know whether or not you'll have access to the
> physical CD at that point
Andrew Koenig wrote:
>> All of which is a long-winded way of saying "calculation of an object hash
>> should be both cheap and idempotent" :)
>
> Actually, I disagree -- I don't see why there's anything wrong with a hash
> being expensive to calculate the first time you do it.
True, but if you ca
> All of which is a long-winded way of saying "calculation of an object hash
> should be both cheap and idempotent" :)
Actually, I disagree -- I don't see why there's anything wrong with a hash
being expensive to calculate the first time you do it.
For example, consider a string type in which the
Andrew Koenig wrote:
>> In both cases, __hash__ is not idempotent, and is thus an abomination.
>
> Why do you say it's not idempotent? The first time you call it, either it
> works or it doesn't. If it doesn't work, then you shouldn't have called it
> in the first place. If it does work, all su
> Which case are you considering? In case 1, __hash__ of the parent object
> is not idempotent because it depends on whether __hash__ of the child
> object has a cached value or not.
I don't see why you should say that; it's certainly not my intent. What did
I say that makes you think that that d
Earlier in the thread:
> two troublesome cases:
[...]
> 1) An object x with a component y that might be hashable. x is hashable
> apart from x.y, but hashing x for the first time has side effects, so the
> value is cached. The hash of x depends partly on the hash of x.y.
[...]
>
> In both cases, __hash__ is not idempotent, and is thus an abomination.
Why do you say it's not idempotent? The first time you call it, either it
works or it doesn't. If it doesn't work, then you shouldn't have called it
in the first place. If it does work, all subsequent calls will return the
I wrote:
> [1] I subtlely switched language from "side effect free" to "idempotent"
> here because caching *IS* acceptable in __hash__ mehtods. If you're
> not paying close attention I probably got away with it.
Andrew Koenig responds:
> I picked it up before seeing the footnote :-)
Yea
> A __hash__ method with side effects is not formally prohibited in the
> documentation but nevertheless, a __hash__ which is not idempotent is
> an abomination.[1] Thus, there is no need for a test of whether __hash__
> will succeed: just try it.
> [1] I subtlely switched language from "side effe
Andrew Koenig writes:
> This issue started out as a question of side effects; from an architectural
> viewpoint, I consider performance to be less important because side effects
> are likely to affect correctness.
Indeed... side effects are the primary concern.
A __hash__ method with side effects
Guido van Rossum wrote:
> I propose to take the same approach as for callable: if it has
> __hash__ we consider it hashable even though the hash may fail
Fair enough, although since object has __hash__
we end up concluding that everything is
hashable except when it isn't. :-)
--
Greg
On 7/23/06, Andrew Koenig <[EMAIL PROTECTED]> wrote:
> > But you've just pointed out that they're *not*
> > the same kind of concept, no matter how much
> > you might wish that there were.
>
> > The only way to make hashability testable at
> > less cost than attempting to do it would be
> > to have
> But you've just pointed out that they're *not*
> the same kind of concept, no matter how much
> you might wish that there were.
> The only way to make hashability testable at
> less cost than attempting to do it would be
> to have a separate __is_hashable__ method for
> that purpose, which would
Andrew Koenig wrote:
> To my way of thinking, callable, iterable, and hashable are the same kind of
> concept,
But you've just pointed out that they're *not*
the same kind of concept, no matter how much
you might wish that there were.
The only way to make hashability testable at
less cost than a
On 7/22/06, Andrew Koenig <[EMAIL PROTECTED]> wrote:
> This example illustrates an important point: Some object properties don't
> correspond directly to the presence of a particular attribute, and can't
> easily be made to do so.
>
> In other words:
>
> Is it callable? No problem, just c
> > That would be at odds with the approach taken with
> > list.__hash__ which has to be called in order to find-out it is not
> > hashable.
> That feature of __hash__ is just an unfortunate necessity.
> It arises because hashability is sometimes a "deep"
> property (i.e. it depends on the hashabi
Raymond Hettinger wrote:
> That would be at odds with the approach taken with
> list.__hash__ which has to be called in order to find-out it is not
> hashable.
That feature of __hash__ is just an unfortunate necessity.
It arises because hashability is sometimes a "deep"
property (i.e. it depends
Guido writes:
> I'd like to hear from others whether the default iter fallback ought
> to stay or go.
Go, I think.
It's not that hard to supply __iter__(), and the simplicity and
explicitness feel Pythonic.
-- Michael Chermside
___
Python-3000 mailing
Guido van Rossum wrote:
> def __iter__(self):
> for i in itertools.count():
> yield self[i]
Note that this likely raises IndexError, not StopIteration.
Stefan
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/lis
On 7/21/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Since builtin dicts and dict subclasses will already be iterable, the
> mappings in question would be from user-defined classes with lookup
> behavior and but not providing an iterator:
>
>class C:
> '''This could be either a ma
>>>str and unicode don't have __iter__, list, tuple and dict do:
>>>
>>>
>>[...]
>>
>>
>>>Should that be fixed too?
>>>
>>>
>>Yes, please. (In Python 2.6 if you can.)
>>
>>
If implicit SeqIter wrapping won't potentially go away until Py3.0, why
would this go into Py2.6? What
>>
>> > We should make a conscious decision whether we should make it a
>> > permanent feature or not.
>>
>> It sure simplified writing extensions.
>> And it provided a convenient guarantee that all sequences are iterable.
>> I don't see a downside to keeping it.
>
>
> Well, it will also make mapp
On 7/21/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
I'd like to hear from others whether the default iter fallback oughtto stay or go.It should go (in py3k, obviously not in 2.6.) Maybe there should be a convenient way to spell 'iter me like a sequence', but it should definately be explicit, no
Guido van Rossum wrote:
> On 7/20/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>> str and unicode don't have __iter__, list, tuple and dict do:
> [...]
>> Should that be fixed too?
>
> Yes, please. (In Python 2.6 if you can.)
Here's the patch: bugs.python.org/1526367
Servus,
Walter
___
Greg Ewing wrote:
> Guido van Rossum wrote:
>
>> Actually, the autowrapping was intended a backwards compatibility measure.
>
> But it seems like a perfectly good and useful feature
> in its own right to me. Why force every sequence to
> implement its own __iter__ if there is a default one
> that
Guido van Rossum wrote:
> Actually, the autowrapping was intended a backwards compatibility measure.
But it seems like a perfectly good and useful feature
in its own right to me. Why force every sequence to
implement its own __iter__ if there is a default one
that does the same as what your custo
On 7/20/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Walter Dörwald wrote:
>
> > I don't know about __call__, but str and unicode don't have __iter__,
> > list, tuple and dict do:
>
> That's probably because str and unicode don't do their
> own iteration, but rely on the fallback implementation.
> I
On 7/20/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
On 7/20/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:>> >> Why is this a defect? Have we abandoned the notion of SeqIter> >> automatically wrapping any object with __getitem__()?
> >> >> > Actually, the autowrapping was intended a backward
On 7/20/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
Walter Dörwald wrote:> I don't know about __call__, but str and unicode don't have __iter__,> list, tuple and dict do:That's probably because str and unicode don't do theirown iteration, but rely on the fallback implementation.
In which case it's pe
Walter Dörwald wrote:
> I don't know about __call__, but str and unicode don't have __iter__,
> list, tuple and dict do:
That's probably because str and unicode don't do their
own iteration, but rely on the fallback implementation.
In which case it's perfectly correct for them not to
have an __it
On 7/20/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
> >> Why is this a defect? Have we abandoned the notion of SeqIter
> >> automatically wrapping any object with __getitem__()?
> >
> >
> > Actually, the autowrapping was intended a backwards compatibility
> > measure.
> >
> > We should make
>> Why is this a defect? Have we abandoned the notion of SeqIter
>> automatically wrapping any object with __getitem__()?
>
>
> Actually, the autowrapping was intended a backwards compatibility
> measure.
>
> We should make a conscious decision whether we should make it a
> permanent feature or
On 7/20/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> >On 7/20/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
> >>str and unicode don't have __iter__, list, tuple and dict do:
> >>Should that be fixed too?
> >Yes, please. (In Python 2.6 if you can.)
> Why is the a d
Guido van Rossum wrote:
>On 7/20/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>
>
>>str and unicode don't have __iter__, list, tuple and dict do:
>>
>>
>[...]
>
>
>>Should that be fixed too?
>>
>>
>
>Yes, please. (In Python 2.6 if you can.)
>
>
>
Why is the a defect? Have we aband
On 7/20/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
> str and unicode don't have __iter__, list, tuple and dict do:
[...]
> Should that be fixed too?
Yes, please. (In Python 2.6 if you can.)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
__
Guido van Rossum wrote:
> On 7/18/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
>> Andrew Koenig wrote:
>>
>>> I am uncomfortable about exposing the implementation this way, if only
>>> because it would require fixing the equivalence between callable() and
>>> hasattr(obj, '__call__') for all time.
>>
Ronald Oussoren wrote:
> On Jul 20, 2006, at 3:26 AM, Greg Ewing wrote:
>
>> Ronald Oussoren wrote:
>>
>>> Classic classes?
>> I just checked, and it seems they've been fixed too:
>> callable() and hasattr(obj, '__call_') give the same
>> result -- true if and only if a __call__ method has
>> been
On Jul 20, 2006, at 3:26 AM, Greg Ewing wrote:
> Ronald Oussoren wrote:
>
>> Classic classes?
>
> I just checked, and it seems they've been fixed too:
> callable() and hasattr(obj, '__call_') give the same
> result -- true if and only if a __call__ method has
> been defined.
But classic classes
Ronald Oussoren wrote:
> Classic classes?
I just checked, and it seems they've been fixed too:
callable() and hasattr(obj, '__call_') give the same
result -- true if and only if a __call__ method has
been defined.
Anyway, the point I was making is that this equivalence
is a *good* thing -- I can
On Jul 19, 2006, at 6:31 PM, Guido van Rossum wrote:
> On 7/18/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
>> Andrew Koenig wrote:
>>
>>> I am uncomfortable about exposing the implementation this way, if
>>> only
>>> because it would require fixing the equivalence between callable
>>> () and
>>>
On 7/18/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Andrew Koenig wrote:
>
> > I am uncomfortable about exposing the implementation this way, if only
> > because it would require fixing the equivalence between callable() and
> > hasattr(obj, '__call__') for all time.
>
> I don't see anything bad ab
Greg Ewing wrote:
> Guido van Rossum wrote:
>
>> But I'm not proposing to use hasattr(obj, '__call__'). I'm basically
>> saying that the callable test has very little to do with whether the
>> later call will succeed, because we have no way to test the signature.
>
> I don't think that's needed
Greg Ewing wrote:
> Guido van Rossum wrote:
>
>
>>But I'm not proposing to use hasattr(obj, '__call__'). I'm basically
>>saying that the callable test has very little to do with whether the
>>later call will succeed, because we have no way to test the signature.
>
>
> I don't think that's neede
Greg Ewing wrote:
> For that purpose, hasattr(obj, '__call__') is sufficient,
> I think. And if it's not, the API you're trying to
> implement is ill-conceived in the first place, just like
> testing for sequenceness is not a well-defined operation.
I should add that for ipython's purposes, it se
Andrew Koenig wrote:
> I am uncomfortable about exposing the implementation this way, if only
> because it would require fixing the equivalence between callable() and
> hasattr(obj, '__call__') for all time.
I don't see anything bad about fixing that equivalence.
I regard the fact that it *wasn't
Guido van Rossum wrote:
> But I'm not proposing to use hasattr(obj, '__call__'). I'm basically
> saying that the callable test has very little to do with whether the
> later call will succeed, because we have no way to test the signature.
I don't think that's needed for the sort of things people
> Then it becomes a matter of whether it's worth having callable()
> around as an alternative spelling. Those arguing in favour of
> it would have to explain whether we should also have addable(),
> subtractable(), mutiplyable(), indexable(), etc. etc. etc...
I'd love to be able to determine wheth
> Andrew Koenig wrote:
> > I note in PEP 3000 the proposal to remove callable(), with the comment
> "just call the object and catch the exception."
> I think that should be amended to "just use hasattr(obj. '__call__')
> instead". That's what callable() will become equivalent to once
> old_style
> Agreed. I think the people who want to use this as a test for whether
> a client passed them a usable object are barking up the wrong tree.
> What I do see it as useful for is making an api that accepts a
> foo-like-object, or a callable object that returns a foo-like-object.
Yes. What really g
On 7/18/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> But I'm not proposing to use hasattr(obj, '__call__'). I'm basically
> saying that the callable test has very little to do with whether the
> later call will succeed, because we have no way to test the signature.
Agreed. I think the people
On 7/18/06, Michael Urman <[EMAIL PROTECTED]> wrote:
> On 7/18/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > I think that should be amended to "just use hasattr(obj. '__call__')
> > instead". That's what callable() will become equivalent to once
> > old_style classes are gone.
> >
> > Then it becom
On 7/18/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> I think that should be amended to "just use hasattr(obj. '__call__')
> instead". That's what callable() will become equivalent to once
> old_style classes are gone.
>
> Then it becomes a matter of whether it's worth having callable()
> around as a
Hi,
Greg Ewing wrote:
> Andrew Koenig wrote:
>> I note in PEP 3000 the proposal to remove callable(), with the comment "just
>> call the object and catch the exception."
>
> I think that should be amended to "just use hasattr(obj. '__call__')
> instead". That's what callable() will become equival
Andrew Koenig wrote:
> I note in PEP 3000 the proposal to remove callable(), with the comment "just
> call the object and catch the exception."
I think that should be amended to "just use hasattr(obj. '__call__')
instead". That's what callable() will become equivalent to once
old_style classes are
On 7/17/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
"Alex Martelli" <[EMAIL PROTECTED]> wrote:>> On 7/17/06, Andrew Koenig <[EMAIL PROTECTED]> wrote:> > I note in PEP 3000 the proposal to remove callable(), with the comment "just
> > call the object and catch the exception."> >> > I think that's
> If 'callable' is to stay, then in order to pull its weight it needs to
> grow to provide a way to check "callable with the following signature"
> -- at the very least in terms of numbers and names of arguments,
> though (if py3k does gain some syntax for specifying argument types)
> it might do m
"Alex Martelli" <[EMAIL PROTECTED]> wrote:
>
> On 7/17/06, Andrew Koenig <[EMAIL PROTECTED]> wrote:
> > I note in PEP 3000 the proposal to remove callable(), with the comment "just
> > call the object and catch the exception."
> >
> > I think that's a bad idea, because it takes away the ability t
On 7/17/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
> [proposal for a type annotations-based version of callable()]
To weigh in from the function/type annotations side of things, the
consensus has been that Python 3000's function annotations are only a
way to map parameter names to some arbitrary
On 7/17/06, Andrew Koenig <[EMAIL PROTECTED]> wrote:
> I note in PEP 3000 the proposal to remove callable(), with the comment "just
> call the object and catch the exception."
>
> I think that's a bad idea, because it takes away the ability to separate the
> callability test from the first call. A
Calvin Spealman wrote:
> I second that removal of callable() would be a bad idea. There are too
> many cases where it is not feasable to "just call the object and catch the
> exception". In the cases where the call would not happen until later than
> the test for callability, it would require then
I second that removal of callable() would be a bad idea. There are too many cases where it is not feasable to "just call the object and catch the exception". In the cases where the call would not happen until later than the test for callability, it would require then that any state changes caused b
I note in PEP 3000 the proposal to remove callable(), with the comment "just
call the object and catch the exception."
I think that's a bad idea, because it takes away the ability to separate the
callability test from the first call. As a simple example, suppose you're
writing a function that you
99 matches
Mail list logo
