Re: [Python-Dev] function for counting items in a sequence
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, 0) + 1 return d Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] concerns regarding callable() method
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 raised inside its __call__ and exception raised if object is not callable to begin with. 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. Currently, you can assert callable (x) But if callable() is removed, there is no apparent replacement. Of course, you cannot call `x' since it might have side-effects or be slow etc. Please reconsider removal of callable() or provide an adequate replacement. Paul ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] concerns regarding callable() method
> 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 raised inside its __call__ and > exception raised if object is not callable to begin with. I seem to recall bringing up the same issue a while ago; at the time, the answer was that if you need it, you can write your own: def callable(x): return hasattr(x, '__call__') My own preference would be for such queries to be defined abstractly as a built-in part of the language, but apparently my preference is out of sync with the community in this particular respect. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] concerns regarding callable() method
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 to somehow to > differentiate between exception raised inside its __call__ and > exception raised if object is not callable to begin with. Why? > 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. > Currently, you can > > assert callable (x) > > But if callable() is removed, there is no apparent replacement. Of > course, you cannot call `x' since it might have side-effects or be > slow etc. 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. > Please reconsider removal of callable() or provide an adequate > replacement. What if someone passes a callable that doesn't have the expected signature? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] concerns regarding callable() method
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. > > Currently, you can > > > > assert callable (x) > > > > But if callable() is removed, there is no apparent replacement. Of > > course, you cannot call `x' since it might have side-effects or be > > slow etc. > > 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 way, callable() is just a sugar and not something unimplementable in other ways. Therefore, my objection is discarded. (But PEP 3100 should probably be update to mention this, otherwise you may get this complaint again ;) > > Please reconsider removal of callable() or provide an adequate > > replacement. > > 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 trick above.) Paul ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] concerns regarding callable() method
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 > trick above.) My point is that it's futile to use callable() -- even if it passes, you have no assurance that you actually have a valid callback. So why bother with it at all? It's counter to the spirit of Python. If someone passes you a bad callback, they will see a traceback when you call it. Then they fix their program. That's how it's supposed to work. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] concerns regarding callable() method
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 way, > callable() is just a sugar and not something unimplementable in other > ways. Therefore, my objection is discarded. (But PEP 3100 should probably > be update to mention this, otherwise you may get this complaint again ;) I whole-heartedly agree here, because people who start learning python (like me some time ago) usually learn that it's bad to test for __call__ (can't remember where I read about that though), and that we should always use callable() to be on a safe side. When I first heard that callable() was going to be removed I kinda panicked myself, it's good to know that at least there's still a way to be sure that object is callable or not... ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] concerns regarding callable() method
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() will not make it worse (even if you don't know about hasattr > > trick above.) > My point is that it's futile to use callable() -- even if it passes, > you have no assurance that you actually have a valid callback. So why > bother with it at all? It's counter to the spirit of Python. If > someone passes you a bad callback, they will see a traceback when you > call it. Then they fix their program. That's how it's supposed to > work. But what if you need to do different things based on argument is callable or not? Take for example "Dependency Injection" recipe: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/413268 It uses callable to differentiate whether it needs to use object as singleton or to instantiate it on each request. I'm sure there might be other uses for callable when it's really useful. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] concerns regarding callable() method
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 if you don't know about hasattr > > trick above.) > > My point is that it's futile to use callable() -- even if it passes, > you have no assurance that you actually have a valid callback. So why > bother with it at all? It's counter to the spirit of Python. If > someone passes you a bad callback, they will see a traceback when you > call it. Then they fix their program. That's how it's supposed to > work. 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 error occured when you passed something wrong to set_callback() call and not in some obscure place 200 lines later, because otherwise it will only obfuscate error reason. Yes, assert will not catch all errors, but at least it will some. I consider it perfectly acceptable that you cannot test signature, because (since Python is untyped) you could only test number of arguments and even that would probably involve dumb syntax. So, I understand such assert will not catch all errors. But I don't want to remove it, since I find catching at least some errors (e.g. like passing None) an improvement over catching no errors. Paul ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Extended buffer PEP
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 it doesn't get something > unexpected. Yes, I agree. We had something like that at one point. > > I imagine most uses of buffer protocol would be for direct, > one-dimensional arrays of bytes with no striding. It's not clear > whether read-only or read-write should be the least common > denominator, so require at least one of these flags: > > Py_BUF_READONLY > Py_PUF_READWRITE > > Then allow any of these flags to allow more complex access: > > Py_BUF_MULTIDIM - allows strided and multidimensional arrays > Py_BUF_INDIRECT - allows indirect buffers (implies Py_BUF_MULTIDIM) > > An object is allowed to return a simpler array than requested, but not > more complex. If you allow indirect buffers, you might still get a > one-dimensional array of bytes. > > > Other than that, I would add a note about the other things considered > and rejected (the old prototype for getbufferproc, the delegated > buffer object). List whether to backport the buffer protocol to 2.6 > as an open question. Thanks for the suggestions. > > Then submit it as a real PEP. I believe this idea has run its course > as PEP XXX and needs a real number. How does one do that. Who assigns the number? I thought I "had" submitted it as a real PEP. -Travis ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] concerns regarding callable() method
"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 make it worse (even if you don't know about hasattr > > trick above.) > > My point is that it's futile to use callable() -- even if it passes, > you have no assurance that you actually have a valid callback. So why > bother with it at all? It's counter to the spirit of Python. If > someone passes you a bad callback, they will see a traceback when you > call it. Then they fix their program. That's how it's supposed to > work. The point of using callable(x), or it's equivalent now of hasattr(x, '__call__') is to reduce reduce the time/lines of code between when an error occurs and when it is reported. Errors should never pass silently. While we currently cannot verify that some callable takes the proper arguments, number of arguments, etc., we *can* verify that it is callable. I think this is a good thing, as allowing the assignment of a non-callable to a name that is supposed to be callable is the silent passing of an error. With relatively minimal effort in Python 3, one could use a function signature object (PEPs 3107 and 362) to verify that a callable takes the proper number of arguments, expected keyword arguments, etc., which while still not allowing one to verify that the implementation of a callback is correct (technically impossible), it does get us closer to being able to know whether a callable "is" or "may not be" crap when it is assigned. If you still think that these two operations are undesireable (testing the callability, and that a callable takes certain arguments), that's fine (I disagree completely). But unless we mangle callables to not support these operations, people are probably going to do them anyways; especially those who are using annotations, function signature objects, etc., in their various frameworks. But maybe I'm misreading or reading to much into your statement of "If someone passes you a bad callback, they will see a traceback when you call it. Then they fix their program. That's how it's supposed to work." - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] function for counting items in a sequence
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 missing item should be 0 or a KeyError: * Brett Cannon - 0 * Greg Ewing - 0 Because the number of times an unseen item was seen is 0. So I'll stick with returning 0. That's the normal behavior for a defaultdict(int). Raymond Hettinger suggested that the function should be called dict.fromcount() instead. I lean towards the collections module instead of a dict classmethod because the feedback above suggests that the count of an unseen item should be 0. This means returning a defaultdict(int), which might be a bit confusing from a classmethod of *dict*. Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] function for counting items in a sequence
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 counts(). I can live with counts(), though I always ask myself "who counts?" ;) > On whether the count of a missing item should be 0 or a KeyError: > * Brett Cannon - 0 > * Greg Ewing - 0 > Because the number of times an unseen item was seen is 0. So I'll > stick with returning 0. That's the normal behavior for a > defaultdict(int). +1 from me too for 0. > Raymond Hettinger suggested that the function should be called > dict.fromcount() instead. I lean towards the collections module > instead of a dict classmethod because the feedback above suggests that > the count of an unseen item should be 0. This means returning a > defaultdict(int), which might be a bit confusing from a classmethod of > *dict*. defaultdict.fromcount? Too obscure, I guess. Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] function for counting items in a sequence
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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] concerns regarding callable() method
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 catch such situations now, so removing > > > callable() will not make it worse (even if you don't know about hasattr > > > trick above.) > > My point is that it's futile to use callable() -- even if it passes, > > you have no assurance that you actually have a valid callback. So why > > bother with it at all? It's counter to the spirit of Python. If > > someone passes you a bad callback, they will see a traceback when you > > call it. Then they fix their program. That's how it's supposed to > > work. > >But what if you need to do different things based on argument is >callable or not? Then delegate that behavior to the object using adaptation or a generic function. That is, use *table-driven* code, rather than if-then based code. >Take for example "Dependency Injection" recipe: > > http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/413268 > >It uses callable to differentiate whether it needs to use object as >singleton or to instantiate it on each request. And that's a *bad* thing. What if I want to have a callable singleton? Or what if I want to have a singleton that gets notified of each request? With table-driven code (adaptation, generic functions) I can support the first case by reregistering an existing handler, and the second by registering my own handler. If-then based introspection is harmful here, because it's an attempt to *guess* what should be done with the object. Explicit is better than implicit, and it's better not to guess. callable(), like hasattr() or any other "interface probing" is essentially an attempt to guess at the callers intent, instead of providing a reasonable default that they can override. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] concerns regarding callable() method
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 catch such situations now, so removing > > > callable() will not make it worse (even if you don't know about hasattr > > > trick above.) > > > > My point is that it's futile to use callable() -- even if it passes, > > you have no assurance that you actually have a valid callback. So why > > bother with it at all? It's counter to the spirit of Python. If > > someone passes you a bad callback, they will see a traceback when you > > call it. Then they fix their program. That's how it's supposed to > > work. > > The point of using callable(x), or it's equivalent now of hasattr(x, > '__call__') is to reduce reduce the time/lines of code between when an > error occurs and when it is reported. > Errors should never pass silently. I'm not sure if that argument weighs much (taken a bit farther it would require static typing :-). Two arguments made earlier are stronger IMO: - The traceback can be much clearer if it comes from setcallback(x) rather than from the actual call, much later. - The pragmatic ability (which often occurs in "DWIM"-ish behavior in template systems) to do different things depending on whether something is callable or not. (While in theory I agree with Phillip's objection that this should be dealt with in a more systematic way, in practice, at least for Python 2.x, I think it's an "okay" thing to do.) But the same thing can be said for properties like iterable, or hashable, and other primitive operations. FWIW, I haven't given up on doing something with abstract base classes here. I think they (or interfaces or generic functions, for that matter :-) provide a more systematic approach than either callable() or hasattr(x, "__call__"). TBC, --Guido > While we currently cannot verify that some callable takes the proper > arguments, number of arguments, etc., we *can* verify that it is > callable. I think this is a good thing, as allowing the assignment of a > non-callable to a name that is supposed to be callable is the silent > passing of an error. > > With relatively minimal effort in Python 3, one could use a function > signature object (PEPs 3107 and 362) to verify that a callable takes the > proper number of arguments, expected keyword arguments, etc., which > while still not allowing one to verify that the implementation of a > callback is correct (technically impossible), it does get us closer to > being able to know whether a callable "is" or "may not be" crap when it > is assigned. > > If you still think that these two operations are undesireable (testing > the callability, and that a callable takes certain arguments), that's > fine (I disagree completely). But unless we mangle callables to not > support these operations, people are probably going to do them anyways; > especially those who are using annotations, function signature objects, > etc., in their various frameworks. > > But maybe I'm misreading or reading to much into your statement of "If > someone passes you a bad callback, they will see a traceback when you > call it. Then they fix their program. That's how it's supposed to work." > > > - Josiah > > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] function for counting items in a sequence
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 a general-purpose mapping object, and not become a catchall for utility functions that happen to return a dict. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] concerns regarding callable() method
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 error occured when you passed something wrong > to set_callback() call and not in some obscure place 200 lines later, > because otherwise it will only obfuscate error reason. Using the duck typing philosophy; "if it quacks like a duck and walks like a duck, then it probably is a duck." But how can you be so sure it is NOT a duck if you have never seen it walk or heard it quack? What if you are passing in an object that is not callable but later on becomes callable? Is it really an error? I think the plan is that in py3k, you will be able to do type-checking using function annotations (bleach). Like this: def set_callback(self, callback : CallableType): self.callback = callback You probably also need to add some more gunk to make it work. I believe it should be able to replace most uses of callable(). -- mvh Björn ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Extended buffer PEP
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 like that at one point. Maybe this could be handled in an intermediate layer between the user and implementor of the interface, i.e. the user calls PyBuffer_GetBuffer(obj, &info, flags); the object's tp_getbufferinfo just gets called as getbufferinfo(self, &info) and PyBuffer_GetBuffer then checks that the result conforms to the requested feature set. This would relieve users of the interface from having to check that themselves, while not requiring implementors to be burdened with it either. Possibly you might want to pass the flags on to the object as well, in case it can reduce the amount of work it has to do if not all the features are being requested. But the object would be free to ignore them if it wants. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] function for counting items in a sequence
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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] concerns regarding callable() method
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> see a traceback when you call it. Then they fix their Guido> program. That's how it's supposed to work. There's one place where I find the traceback somewhat unhelpful. Consider calling a method of a class with incorrect arguments: >>> class C: ... def __init__(self): ... pass ... >>> C(1) Traceback (most recent call last): File "", line 1, in TypeError: __init__() takes exactly 1 argument (2 given) While in this example it's clear what method wasn't called correctly, a callback called with the wrong number of arguments yields a fairly useless stack trace. I'm thinking in particular of callbacks called from C code (e.g. Gtk signal handlers). I think it would be helpful to check to see if the function being called had an "im_class" attribute. If so, then resolve the class name and include it in the TypeError message: TypeError: C.__init__() takes exactly 1 argument (2 given) Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Weekly Python Patch/Bug Summary
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.5 "What's New" document contains socket errors (2007-03-17) CLOSED http://python.org/sf/1682878 opened by Jp Calderone ConfigParser support for alt delimiters (2007-03-18) http://python.org/sf/1682942 opened by Stephen Hansen Demo/parser/unparse.py fixes and cleanups (2007-03-19) CLOSED http://python.org/sf/1683328 opened by Piet Delport Refactor test_minidom.py to use unittest. (2007-03-18) CLOSED http://python.org/sf/1683397 opened by Jerry Seutter PEP 361 Warnings (2007-03-19) http://python.org/sf/1683908 opened by Adam Olsen add os.chflags() and os.lchflags() where available (2006-05-17) http://python.org/sf/1490190 reopened by nnorwitz Documentation for C-API string functions (2007-03-21) CLOSED http://python.org/sf/1684834 opened by Björn Lindqvist cgi.py invalid REQUEST_METHOD set (2005-03-08) CLOSED http://python.org/sf/1159139 reopened by joesalmeri new function: os.path.relpath (2005-10-27) CLOSED http://python.org/sf/1339796 reopened by loewis MSVCCompiler creates redundant and long PATH strings (2007-03-21) CLOSED http://python.org/sf/1685563 opened by Scott Dial Add IllegalStateError (2007-03-22) http://python.org/sf/1685642 opened by Björn Lindqvist Method cache (2007-03-22) http://python.org/sf/1685986 opened by Armin Rigo More PEP 3116 classes (2007-03-22) CLOSED http://python.org/sf/1686273 opened by Mark Russell int to Py_ssize_t changes (2007-03-22) CLOSED http://python.org/sf/1686451 opened by Alexander Belopolsky Allow any mapping after ** in calls (2007-03-22) http://python.org/sf/1686487 opened by Alexander Belopolsky extending os.walk to support following symlinks (2005-08-26) CLOSED http://python.org/sf/1273829 reopened by loewis Replace time_t by Py_time_t (2007-03-27) http://python.org/sf/1689402 opened by Christian Heimes Refactor test_sax.py to use unittest. (2007-03-28) CLOSED http://python.org/sf/1690164 opened by Jerry Seutter Refactor test_pyexpat.py to use unittest. (2007-03-28) CLOSED http://python.org/sf/1690169 opened by Jerry Seutter Added support for custom readline functions (2007-03-28) http://python.org/sf/1690201 opened by Ben Timby Don't block on Queue get/put when time is moved back (2007-03-29) http://python.org/sf/1690578 opened by xiaowen Migrate test_minidom.py to unittest (2007-03-30) http://python.org/sf/1691032 opened by Jason Orendorff Fix for bug #1283289 (2007-03-30) http://python.org/sf/1691070 opened by Roger Upole Move initial args assignment to BaseException.__new__ (2007-04-01) http://python.org/sf/1692335 opened by ?iga Seilnacht warnings.py gets filename wrong for eval/exec (2007-04-01) http://python.org/sf/1692664 opened by Adam Olsen trace.py --ignore-module should accept module name list. (2007-04-02) http://python.org/sf/1693149 opened by Raghuram Devarakonda Fix for duplicate "preferences" menu-OS X (2007-04-02) http://python.org/sf/1693258 opened by Kevin Walzer tarfile bug when opening a file directly (2007-04-05) http://python.org/sf/1695229 opened by Arve Knudsen Fix test_urllib on Windows buildbots (2007-04-07) http://python.org/sf/1695862 opened by Ziga Seilnacht Remove redundant code in ntpath.walk() (2007-04-08) http://python.org/sf/1696393 opened by Michael Haggerty Adding an index method to tuples (2007-04-08) http://python.org/sf/1696444 opened by Paul Boddie Patches Closed __ TypeError swallowing in UNPACK_SEQUENCE opcode (2007-03-16) http://python.org/sf/1682205 closed by gbrandl Make PyComplex_AsCComplex use __complex__ (2007-03-07) http://python.org/sf/1675423 closed by gbrandl remove sys.exitfunc, rewrite atexit in C (2007-03-14) http://python.org/sf/1680961 closed by collinwinter telnetlib option subnegotiation fix (2003-01-07) http://python.org/sf/664020 closed by gbrandl telnetlib.py change to ease option handling. (2006-07-10) http://python.org/sf/1520081 closed by gbrandl Python 2.5 "What's New" document contains socket errors (2007-03-17) http://python.org/sf/1682878 closed by gbrandl PEP 3115 patch (2007-03-14) http://python.org/sf/1681101 closed by gvanrossum Adding a testcase for the bug in find_longest_match (2007-03-11) http://python.org/sf/1678339 closed by gbrandl Patch to add tempfile.SpooledTemporaryFile (for #415692) (2007-01-07) http://python.org/sf/1630118 closed by collinwinter Demo/parser/unparse.py fixes and cleanups (2007-03-19) http://pyth
