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.
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
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
___
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
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
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, 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,
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, 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
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
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
"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
> >
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 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
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
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, 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
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:
> 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
> 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
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
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,
22 matches
Mail list logo
