Instead of a separate function in collections, it may be sensible to stick with
the familiar and provide a dictionary contructor for the commonly encounter use
case of counting things:
@classmethod
def fromcount(cls, iterable):
d = cls()
for elem in iterable:
d[elem] = d.get(elem,
Hi,
I have seen in PEP 3100 that callable() function is planned to be
removed in Python 3000 with this replacement: just call the object
and catch the exception???. For one, the object (if it is
callable) can raise exception itself, so you need to somehow to
differentiate between exception
I have seen in PEP 3100 that callable() function is planned to be
removed in Python 3000 with this replacement: just call the object
and catch the exception???. For one, the object (if it is
callable) can raise exception itself, so you need to somehow to
differentiate between exception
On 4/8/07, Paul Pogonyshev [EMAIL PROTECTED] wrote:
I have seen in PEP 3100 that callable() function is planned to be
removed in Python 3000 with this replacement: just call the object
and catch the exception???. For one, the object (if it is
callable) can raise exception itself, so you need
Guido van Rossum wrote:
On 4/8/07, Paul Pogonyshev [EMAIL PROTECTED] wrote:
Additionally consider something like
something.set_callback (x)
Assume that set_callback() wants to check if `x' is callable at
all, to raise exception early and make error tracking easier.
On 4/8/07, Paul Pogonyshev [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
What if someone passes a callable that doesn't have the expected signature?
Well, I don't know a way to catch such situations now, so removing
callable() will not make it worse (even if you don't know about hasattr
On 4/8/07, Paul Pogonyshev [EMAIL PROTECTED] wrote:
assert hasattr(x, '__call__')
I note that callable() was introduced before all callable objects had
a __call__ attribute. This is no longer the case, so it's not needed.
I just didn't think about that possibility. If that works the same
On 4/8/07, Guido van Rossum [EMAIL PROTECTED] wrote:
On 4/8/07, Paul Pogonyshev [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
What if someone passes a callable that doesn't have the expected
signature?
Well, I don't know a way to catch such situations now, so removing
callable()
Guido van Rossum wrote:
On 4/8/07, Paul Pogonyshev [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
What if someone passes a callable that doesn't have the expected
signature?
Well, I don't know a way to catch such situations now, so removing
callable() will not make it worse (even
Carl Banks wrote:
Only one concern:
typedef int (*getbufferproc)(PyObject *obj, struct bufferinfo
*view)
I'd like to see it accept a flags argument over what kind of buffer
it's allowed to return. I'd rather not burden the user to check all
the entries in bufferinfo to make sure
Guido van Rossum [EMAIL PROTECTED] wrote:
On 4/8/07, Paul Pogonyshev [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
What if someone passes a callable that doesn't have the expected
signature?
Well, I don't know a way to catch such situations now, so removing
callable() will not
A summary response to the issues raised so far...
On what the name should be:
* Adam Olsen - countunique(), countdistinct(), countduplicates()
* Greg Ewing - counteach(), countall()
* Kevin Jacobs - tally()
* Guido - counts() is fine
So I guess I'll stick with counts().
On whether the count of a
Steven Bethard schrieb:
A summary response to the issues raised so far...
On what the name should be:
* Adam Olsen - countunique(), countdistinct(), countduplicates()
* Greg Ewing - counteach(), countall()
* Kevin Jacobs - tally()
* Guido - counts() is fine
So I guess I'll stick with
On 4/8/07, Georg Brandl [EMAIL PROTECTED] wrote:
I can live with counts(), though I always ask myself who counts? ;)
The Count, of course. :-)
ducks/
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
At 08:01 PM 4/8/2007 +0400, Alexey Borzenkov wrote:
On 4/8/07, Guido van Rossum [EMAIL PROTECTED] wrote:
On 4/8/07, Paul Pogonyshev [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
What if someone passes a callable that doesn't have the expected
signature?
Well, I don't know a way to
On 4/8/07, Josiah Carlson [EMAIL PROTECTED] wrote:
Guido van Rossum [EMAIL PROTECTED] wrote:
On 4/8/07, Paul Pogonyshev [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
What if someone passes a callable that doesn't have the expected
signature?
Well, I don't know a way to
Raymond Hettinger wrote:
Instead of a separate function in collections, it may be sensible to stick
with
the familiar and provide a dictionary contructor for the commonly encounter
use
case of counting things:
I don't think that's a good idea. The dict class
should restrict itself to being
On 4/8/07, Paul Pogonyshev [EMAIL PROTECTED] wrote:
I have no problems with Python being untyped. But I want that error
stack traces provide some useful information as possible with reasonable
effort and that errors happen as early as possible. In particular, stack
trace should mention that
Travis Oliphant wrote:
Carl Banks wrote:
I'd like to see it accept a flags argument over what kind of buffer
it's allowed to return. I'd rather not burden the user to check all
the entries in bufferinfo to make sure it doesn't get something
unexpected.
Yes, I agree. We had something
Steven Bethard wrote:
* Greg Ewing - counteach(), countall()
* Guido - counts() is fine
I'm happy with counts() too -- I only suggested the
others in case counts() wasn't acceptable for some
reason. If Guido likes it, that's good enough for
me.
--
Greg
Guido My point is that it's futile to use callable() -- even if it
Guido passes, you have no assurance that you actually have a valid
Guido callback. So why bother with it at all? It's counter to the
Guido spirit of Python. If someone passes you a bad callback, they will
Guido
Patch / Bug Summary
___
Patches : 349 open ( +7) / 3737 closed (+25) / 4086 total (+32)
Bugs: 939 open (-12) / 6648 closed (+60) / 7587 total (+48)
RFE : 249 open ( -8) / 278 closed (+12) / 527 total ( +4)
New / Reopened Patches
__
Python
22 matches
Mail list logo
