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 rais
> 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 yo
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 easie
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 ha
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 work
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
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 mak
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 m
"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
> >
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 wi
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. :-)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-D
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 do
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,
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 b
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
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 s
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
Gu
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 2.
22 matches
Mail list logo
