[issue1910] Document that with is slower than try/finally

Changes by Jeffrey Yasskin: -- nosy: +jyasskin __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1910 __ ___ Python-bugs-list mailing list Unsubscribe:

[issue1167] gdbm/ndbm 1.8.1+ needs libgdbm_compat.so

Eh Tan added the comment: According to gdbm NEW, the dbm/ndbm compatibility routines was moved to libgdbm_compat in v1.8.1, which was released in late 2002. The patch works for gdbm-1.8.1+. But I am afraid that the patch will cause build error with gdbm-1.8.0 and earlier version. A more

[issue1706863] Failed to build Python 2.5.1 with sqlite3

Eh Tan added the comment: The problem is at line 890, setup.py, r60970. sqlite_libfile = self.compiler.find_library_file( sqlite_dirs_to_check + lib_dirs, 'sqlite3') sqlite_libdir = [os.path.abspath(os.path.dirname(sqlite_libfile))]

[issue2168] gdbm needs to be iterable

Changes by Thomas Herve: -- keywords: +patch Added file: http://bugs.python.org/file9531/dbm.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2168 __ ___

[issue1910] Document that with is slower than try/finally

Raymond Hettinger added the comment: FWIW, we don't usually document relative speeds (or even O(n) performance). Those things are implementation dependent and can vary across releases. In the case of the with-statement, it would seem self-evident that with does everything try/finally does

[issue2168] gdbm needs to be iterable

Changes by Thomas Herve: Added file: http://bugs.python.org/file9532/gdbm.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2168 __ ___ Python-bugs-list mailing list

[issue2168] gdbm needs to be iterable

Thomas Herve added the comment: Attached files add contains method to dbm and gdbm objects. It fixes failures with test_shelve. I'm ready to add more tests for this, but #1960 should probably go in first (it converts the tests to unittest, and add some coverage). Please review!

[issue2168] gdbm needs to be iterable

Raymond Hettinger added the comment: The patch looks good to my eye, but I can't test it directly. Will apply and see what the buildbots think about it. -- nosy: +rhettinger priority: - high __ Tracker [EMAIL PROTECTED]

[issue2168] gdbm needs to be iterable

Changes by Raymond Hettinger: -- assignee: - rhettinger __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2168 __ ___ Python-bugs-list mailing list Unsubscribe:

[issue2173] Pyton fails silently on bad locale

New submission from Michael Otteneder: Python seems to fail silently when LANG enviroment variable is set to a bad value. In Mac OS X Leopard it is set too UTF-8 for instance which does not seem to be valid. Python fails building the modules during make and the generated python.exe is unable to

[issue1738] filecmp.dircmp does exact match only

Virgil Dupras added the comment: The documentation doesn't say anything about dircmp being supposed to support pattern matching. This ticket is a feature request rather than a bug. -- components: +Library (Lib) -None nosy: +vdupras type: behavior - feature request

[issue841728] urllib and cookie module improvements

John J Lee added the comment: This should be closed. Tracker [EMAIL PROTECTED] http://bugs.python.org/issue841728 ___ Python-bugs-list mailing list Unsubscribe:

[issue1040026] os.times() is bogus

Antoine Pitrou added the comment: Hi Alexander, 5% is a lot and IIRC os.times is used by some standard python profilers and 5% slowdown will affect people. Profiled runs are always slower than non-profiled runs, so I'm not convinced it is very important. You use profiling only when you need

[issue1729305] test_doctest fails when run in verbose mode

Mike Beachy added the comment: The basic issue here is that running in verbose mode echoes back the expected values from the file, so the results from non-ascii doctest files must be encoded before printing. It looks to me like the DocTestRunner class must grow an '_encoding' attribute to keep

[issue1729305] test_doctest fails when run in verbose mode

Mike Beachy added the comment: Here's a patch for test_doctest.py that checks the problem has been fixed. Added file: http://bugs.python.org/file9534/test_doctest.patch _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1729305

[issue1533] Bug in range() function for large values

Rafael Zanella added the comment: According to the documentation (http://docs.python.org/dev/library/functions.html) The arguments must be plain integers, so I think the wrong thing here is to run the object's __int__() under the range()'s hood. I think the right thing to do would be to

[issue1657] [patch] epoll and kqueue wrappers for the select module

Christian Heimes added the comment: I've updated the patch. The latest patch didn't contain the unit tests and it failed to apply cleanly, too. Added file: http://bugs.python.org/file9535/trunk_select_epoll_kqueue9.patch __ Tracker [EMAIL PROTECTED]

[issue1657] [patch] epoll and kqueue wrappers for the select module

Changes by Christian Heimes: Removed file: http://bugs.python.org/file9019/trunk_select_epoll_kqueue5.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1657 __ ___

[issue1657] [patch] epoll and kqueue wrappers for the select module

Changes by Christian Heimes: Removed file: http://bugs.python.org/file9029/trunk_select_epoll_kqueue7.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1657 __ ___

[issue1657] [patch] epoll and kqueue wrappers for the select module

Changes by Christian Heimes: Removed file: http://bugs.python.org/file9027/trunk_select_epoll_kqueue6.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1657 __ ___

[issue1657] [patch] epoll and kqueue wrappers for the select module

Changes by Christian Heimes: Removed file: http://bugs.python.org/file9241/trunk_select_epoll_kqueue8.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1657 __ ___

[issue2174] xml.sax.xmlreader does not support the InputSource protocol

New submission from Yitz Gale: In the documentation for xml.sax.xmlreader.InputSource objects (section 8.12.4 of the Library Reference) we find that users of InputSource objects should use the following sequence to get their input data: 1. If the InputSource has a character stream, use that. 2.

[issue2175] Expat sax parser silently ignores the InputSource protocol

New submission from Yitz Gale: The expat sax parser in xml.sax.expatreader does not fully support the InputSource protocol in xml.sax.xmlreader. It only accepts byte streams. It ignores the encoding indicated in the InputStream object and only uses the encoding read from the XML or defaults to

[issue2176] Undocumented lastrowid attribute i sqlite3 cursor class

Changes by Jakub Fedyczak: -- components: Documentation nosy: bukaj severity: normal status: open title: Undocumented lastrowid attribute i sqlite3 cursor class versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2176

[issue2175] Expat sax parser silently ignores the InputSource protocol

Yitz Gale added the comment: See also: #1483 and #2174. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2175 __ ___ Python-bugs-list mailing list Unsubscribe:

[issue2174] xml.sax.xmlreader does not support the InputSource protocol

Yitz Gale added the comment: See also: #1483 and #2175. -- components: +Unicode __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2174 __ ___ Python-bugs-list mailing list

[issue1306] Embedded python reinitialization

Christian Heimes added the comment: I've fixed the bug in Python 3.0 a few weeks ago. I'm not sure about the stackless bug but this is the wrong place to report it. Please contact the other Christian. -- resolution: - invalid status: open - closed __

[issue2176] Undocumented lastrowid attribute i sqlite3 cursor class

New submission from Jakub Fedyczak: con = sqlite3.connect(file) c = con.cursor() c.execute(INSERT INTO .) last_id = c.lastrowid --- nothing about it in the docs __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2176 __

[issue2174] xml.sax.xmlreader does not support the InputSource protocol

Yitz Gale added the comment: Hmm. When getSourceEncoding() is None, there needs to be some way for the parser to distinguish between the cases where it is getting pre-decoded Unicode through a character stream, or where it is getting a byte stream with an unspecified encoding. In the latter

[issue839159] iterators broken for weak dicts

Virgil Dupras added the comment: I made a patch to fix the problem. The cleaning up of they weakref keys or values will be held until all references to iterators created by the weakdict are dead. I also couldn't resist removing code duplication of code in items(), keys() and values(). At

[issue2174] xml.sax.xmlreader does not support the InputSource protocol

Yitz Gale added the comment: So I think there are two possibilities: 1. Use a special value for getSourceEnconding(), like unicode, to indicate that this is a unicode character stream and not a byte stream. 2. Provide yet another method in the XMLReader interface: sourceIsCharacterStream(),

[issue1040026] os.times() is bogus

Malte Helmert added the comment: Alexander, speed-wise your patch is worse than the original one on systems where HZ isn't predefined, because it calls sysconf 5 times in each call to os.times, rather than only once per call. If you worry about speed, the approach outlined in Antoine's last

[issue1040026] os.times() is bogus

Christian Heimes added the comment: I suggest that you define static int hz and assign a value to the var in INITFUNC(). #ifdef HZ hz = HZ; #elif defined(HAVE_SYSCONF) hz = sysconf(_SC_CLK_TCK); #else hz = 60; /* It's 50Hz in Europe */ #endif -- nosy: +tiran

[issue1040026] os.times() is bogus

Malte Helmert added the comment: Tiran, that's the general approach we should follow, yes. But the people who discussed this on #python-dev all felt a bit queasy about the 60 fallback -- this is what caused the bug in the first place on Guido's and my machine. (A value of 60 was assumed; 100

[issue1040026] os.times() is bogus

Malte Helmert added the comment: Never mind, on Windows a different code path is chosen. I'm now working on a patch that computes the hz value during module initialization. So should I keep the 60 magic value? What is the justification? _ Tracker [EMAIL

[issue1040026] os.times() is bogus

Christian Heimes added the comment: I don't *use* Windows except for some computer games. But I'm doing some development for Python on Windows in a VMWare box. I'm going to check HZ for you. Give me a couple of minutes to boot the image. How do you like this idea. Since HZ is only used in

[issue2177] Update compiler module to handle class decorators

New submission from Thomas Herve: The attached patch (tries to?) updates compiler to handle class decorators, and also to handle the new way decorated function are handled. I had a weird bug because it seems that ast.py was modified at hand last time (r51330). This fixes the recent failures in

[issue2110] Implement __format__ for Decimal

Mark Dickinson added the comment: Here's a first attempt at Decimal.__format__; the patch is against the trunk, and should be forward ported as usual to 3.0, with obvious minor changes related to str/unicode. It still needs some cleanup and some more tests, but I'm posting it now in the hope

[issue1040026] os.times() is bogus

Malte Helmert added the comment: Here is an updated patch (os_times4.PATCH) that incorporates Christian's suggestions. The patch includes the new unit test, so test_posix?.PATCH need not be applied separately. I again made the unit test a bit more lenient to allow an absolute error of 0.02

[issue1040026] os.times() is bogus

Alexander Belopolsky added the comment: I'd prefer a noisy compile error .. That would be fine if you could verify that none of the currently supported platforms will be affected. I would still feel uneasy about refusing to build python simply because os.times is not ported to a platform.

[issue1040026] os.times() is bogus

Antoine Pitrou added the comment: IMO, if there is no available way to compute HZ, a NotImplementedError should be raised rather than using the 60 magic value. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1040026

[issue1040026] os.times() is bogus

Malte Helmert added the comment: I'd prefer a noisy compile error .. That would be fine if you could verify that none of the currently supported platforms will be affected. I would still feel uneasy about refusing to build python simply because os.times is not ported to a platform.

[issue1040026] os.times() is bogus

Antoine Pitrou added the comment: but I will oppose any changes that affect x86_64 linux performance. Alexander, as I said I'm really curious about any situation where os.times() is so performance-critical that a 5% slowdown for that function call is unacceptable. Even when a profiler is

[issue1040026] os.times() is bogus

Malte Helmert added the comment: Alexander, your one-line patch *does* affect performance on my 64-bit Linux machine in a worse way than any other proposed patch by calling sysconf five times. HZ may be defined on your machine, but it isn't on my (Xeon) machine. I checked man pages on four

[issue1040026] os.times() is bogus

Malte Helmert added the comment: Antoine, none of the recently proposed patches uses the 60 magic value. Alexander's patch doesn't define times in that case (leading to an AttributeError when trying to call os.times) while my patch complains about the bogus environment during compilation.

[issue1040026] os.times() is bogus

Antoine Pitrou added the comment: I think it's better to make it a runtime error (upon invocation of os.times()), rather than a compile-time error. But it's quite theoretical until we find a system where the error does occur, anyway :) _ Tracker [EMAIL

[issue1040026] os.times() is bogus

Malte Helmert added the comment: s/standard library/system library/, of course. Also, the original code is wrong in preferring HZ over the sysconf value. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1040026 _

[issue1040026] os.times() is bogus

Alexander Belopolsky added the comment: HZ may be defined on your machine, but it isn't on my (Xeon) machine. Are you sure? Please note that HZ will not show up in grep -w HZ /usr/include because the right header file further up the tree. On Solaris: /usr/include/sys/param.h:#define

[issue1040026] os.times() is bogus

Malte Helmert added the comment: If I remove the #define 60 line in an unmodified posixmodule.c from trunk, I get the following compiler error: gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -DPy_BUILD_CORE -c

[issue1040026] os.times() is bogus

Malte Helmert added the comment: In the first line of my previous message, I mean #define HZ 60, of course. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1040026 _ ___

[issue1040026] os.times() is bogus

Christian Heimes added the comment: Guys, please don't waste too much time on this issue! The tracker still has more than 1,700 open issues for to debate on. While I enjoy the fact, that you three are enthusiastic, I strongly feel the urge to re-route your men power. This bug isn't important

[issue1230540] sys.excepthook doesn't work in threads

Tiago Alves added the comment: I don't see it as a problem or as the threading module trying to be clever. It clearly was a design choice to make the module have its own exception treatment in order to make it clear in which thread the exception occurred. IMHO the decision here should be to

[issue1040026] os.times() is bogus

Malte Helmert added the comment: Christian, I agree on all points. Alexander's patch posixmodule.diff satisfies those requirements. I suggest also adding the unit test from os_times4.PATCH (but not the changes to posixmodule.c in that patch), as this will help identify misbehaving platforms in

[issue1040026] os.times() is bogus

Alexander Belopolsky added the comment: Thanks Cristian for your intervention. This bug is clearly an aberration: how many GvR reported bugs do you know that stayed open for 3+ years? I think posixmodule.diff satisfies all your requirements and was not opposed by anyone except yours truly.

[issue1533] Bug in range() function for large values

Alexander Belopolsky added the comment: This is related to issue1540617 and issue1546078. issue1540617 contains a simple patch that extend acceptable range of argument to +/-2**63 issue1546078 contains a complete long integer support implementation and was accepted in Py3k. It looks like

[issue2178] Problems with Belarusian Latin locale

New submission from Ihar Hrachyshka: There is a glibc locale: [EMAIL PROTECTED] If my locale environment is set to this locale then all i18n-ed programs are shown with proper translation, except Python-based ones where I see POSIX (?) locale translation (all in English). Though if I set locale

[issue1533] Bug in range() function for large values

Christian Heimes added the comment: I'm -10 on the patch in issue1540617 ( +/-2**63). Reason: It's a good thing that the range of range is limited since it returns a list of integers. range(2**32) allocates (2**32)*16 bytes + small overhead for ints plus the space for the list (probably

[issue1040026] os.times() is bogus

Malte Helmert added the comment: Great, we're approaching closure! :-) One final small thing: As said somewhere above, the allowed discrepancy in test_posix4.PATCH is a bit too low for machines with only 60 ticks per second. I uploaded a slightly more generous test_posix5.PATCH instead. So

[issue2174] xml.sax.xmlreader does not support the InputSource protocol

Yitz Gale added the comment: Subclass of XMLReader would be needed, not InputStream. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2174 __ ___ Python-bugs-list mailing list

[issue1524] os.system() fails for commands with multiple quoted file names

Rafael Zanella added the comment: I don't have access to a Windows machine, but is it really necessary to quote the command part? I mean, on GNU/Linux if you pass a command wich has spaces , say e.g.: ls -lah, quoted it fails too, but if passed without quotes it runs just fine. -- nosy:

[issue1533] Bug in range() function for large values

Alexander Belopolsky added the comment: Christian, I was probably a bit sloppy using range instead of xrange, but issue1540617 is limited to xrange only. Are you still -10 on extending xrange on 64-bit platforms to +/- 2**63? If so, what is your position on backporting py3k's unlimited

[issue1858] Make .pypirc handle multiple servers

Tarek Ziadé added the comment: for the -r option, is has to be catched by both register and upload when the command is called like this : $ python setup.py register sdist upload -r my-pypi without the args lookup, register will get an empty value for -r. This option seems to me quite

[issue1533] Bug in range() function for large values

Alexander Belopolsky added the comment: So far the memory for the ints is *never* returned to the system. I'm working on the problem. Christian, Are you working on the memory problem or on this issue? I think I have a solution to OP's problem, but don't want to duplicate your effort.

[issue1986] io.StringIO allows any parameter

Rafael Zanella added the comment: oops, stupid me, this a 3.0 issue..., well seems the str() conversion is done as well on the 3.0 io module: class StringIO(TextIOWrapper): def __init__(self, initial_value=, encoding=utf-8, errors=strict, newline=\n):

[issue1986] io.StringIO allows any parameter

Rafael Zanella added the comment: I believe you're referring to StringIO, if so, it changes the parameter received to a string: class StringIO: def __init__(self, buf = ''): # Force self.buf to be a string or unicode if not isinstance(buf, basestring): buf =

[issue1986] io.StringIO allows any parameter

Christian Heimes added the comment: In Python 2.x StringIO.StringIO calls str() on its arguments: StringIO.StringIO(1).read() '1' StringIO.StringIO(object).read() type 'object' str(object) type 'object' io.StringIO has the same behavior: io.StringIO(1).read() '1'

[issue1533] Bug in range() function for large values

Christian Heimes added the comment: I'm working on the memory problem. See #2039 and #2013. xrange is a totally different story. I'm +0 on changing xrange. Is Python 3.0's range function compatible with xrange? If the answer is yes, we may reuse the code for an unlimited xrange.

[issue1533] Bug in range() function for large values

Alexander Belopolsky added the comment: Attached patch addresses OP's issue: $ ./python.exe bad_range.py [8, 9, 10, 11, 12, 13, 14, 15, 16, 17] here [18446744073709551616L, 18446744073709551617L, 18446744073709551618L, 18446744073709551619L, 18446744073709551620L, 18446744073709551621L,

[issue2179] with should be as fast as try/finally

New submission from Jeffrey Yasskin: Currently, 'with' costs about .2us over try/finally: $ ./python.exe -m timeit -s 'import thread; lock = thread.allocate_lock()' 'lock.acquire()' 'try: pass' 'finally: lock.release()' 100 loops, best of 3: 0.617 usec per loop $ ./python.exe -m timeit -s

[issue1910] Document that with is slower than try/finally

Jeffrey Yasskin added the comment: I've filed issue 2179 to see if it's possible to make with as fast as try/finally. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1910 __ ___

[issue1394] simple patch, improving unreachable bytecode removing

Alexander Belopolsky added the comment: I am not sure what this patch would accomplish. I tried $ cat t.py def f(): return 1 1+2 from dis import dis print dis(f) Both with and without patch I get $ ./python.exe -O t.py 2 0 LOAD_CONST 1 (1) 3

[issue1772673] Replacing char* with const char*

Alexander Belopolsky added the comment: Douglas Greiman submitted many similar changes with his issue2135 patch. His patch also amends documentation, which is missing here. I am adding dgreiman to the nosy list here to avoid duplication of effort. I am -0 on the idea. -- nosy:

[issue2179] with should be as fast as try/finally

Changes by Collin Winter: -- nosy: +collinwinter __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2179 __ ___ Python-bugs-list mailing list Unsubscribe:

[issue1766304] improve xrange.__contains__

Alexander Belopolsky added the comment: Do we really need another way to spell a = x b? Have you got a real-world use case in mind for the version with step 1? I'm at most lukewarm; I'd be willing to look at a patch to the C code in the py3k-struni branch, plus unit tests though. -- GvR

[issue2180] tokenize: mishandles line joining

Changes by Jared Grubb: -- components: Extension Modules nosy: jaredgrubb severity: minor status: open title: tokenize: mishandles line joining type: behavior versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2180

[issue2180] tokenize: mishandles line joining

New submission from Jared Grubb: tokenize does not handle line joining properly, as the following string fails the CPython tokenizer but passes the tokenize module. Example 1: s = if 1:\n \\\n #hey\n print 1 exec s Traceback (most recent call last): File stdin, line 1, in module File

[issue2181] optimize out local variables at end of function

New submission from Neal Norwitz: This patch optimizes code like: x = any_expression return x to: return any_expression Currently it only optimizes out the local variable if there is a return because it can't determine if this is the last use of the variable or not. This shouldn't

[issue2181] optimize out local variables at end of function

Neal Norwitz added the comment: I forgot to mention that if another loop was added to PyCode_Optimize that kept track of the # of times each local variable was LOAD_FAST/STORE_FAST/DELETE_FAST and that the count was 2, we could perform a similar optimization without requiring the return. Bonus

[issue2182] tokenize: does not allow CR for a newline

New submission from Jared Grubb: tokenize recognizes '\n' and '\r\n' as newlines, but does not tolerate '\r': s = print 1\nprint 2\r\nprint 3\r open('temp.py','w').write(s) exec(open('temp.py','r')) 1 2 3 tokenize.tokenize(open('temp.py','r').readline) 1,0-1,5:NAME'print'

[issue2180] tokenize: mishandles line joining

Jared Grubb added the comment: CPython allows \ at EOF, but tokenize does not. s = 'print 1\\\n' exec s 1 tokenize.tokenize(StringIO(s).readline) 1,0-1,5:NAME'print' 1,6-1,7:NUMBER '1' Traceback (most recent call last): File stdin, line 1, in module File

[issue2183] optimize list comprehensions

New submission from Neal Norwitz: Optimize list comprehensions by using the list on the stack, rather than storing in a (local/global) variable. This reduces the size of the stack by one pointer, reduces the bytecode size by 8, and reduces the iterations in the eval loop by 2 + # of iterations

[issue2181] optimize out local variables at end of function

Neal Norwitz added the comment: I forgot to mention that if another loop was added to PyCode_Optimize that kept track of the # of times each local variable was LOAD_FAST/STORE_FAST/DELETE_FAST and that the count was 2, we could perform a similar optimization without requiring the return. Bonus

[issue2184] Speed up Thread.start()

New submission from Jeffrey Yasskin: Thread.start() used sleep(0.01) to make sure it didn't return before the new thread had started. At least on my MacBook Pro, that wound up sleeping for a full 10ms (probably 1 jiffy). By using an Event instead, we can be absolutely certain that the thread

[issue1394] simple patch, improving unreachable bytecode removing

Neal Norwitz added the comment: It would be great to see test cases with this change. That would help answer Alexander's question too. -- nosy: +nnorwitz __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1394 __

[issue2185] code objects should conserve memory

New submission from Neal Norwitz: Various bits are often duplicated in code objects. For example, sometimes names and varnames are equal. In this case, we don't need two objects since they are both const. This patch implements a trivial fix for this case. However, there are more cases. We

[issue2181] optimize out local variables at end of function

Neal Norwitz added the comment: Guido says to do it only with -O. http://mail.python.org/pipermail/python-dev/2008-February/077193.html __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2181 __

[issue2186] map and filter shouldn't support None as first argument (in Py3k only)

New submission from Guido van Rossum: There are other ways of getting the same effects now (list() or zip() for map(None, ...)). -- keywords: easy messages: 62967 nosy: gvanrossum severity: normal status: open title: map and filter shouldn't support None as first argument (in Py3k only)

[issue2186] map and filter shouldn't support None as first argument (in Py3k only)

Changes by Guido van Rossum: -- components: +Interpreter Core type: - behavior __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2186 __ ___ Python-bugs-list mailing list

[issue2187] map and filter objects shouldn't call themselves itertools.imap and itertools.ifilter objects

New submission from Guido van Rossum: Probably ifilter and imap should go (moving the code over to bltinmodule.c). -- components: Interpreter Core keywords: easy messages: 62968 nosy: gvanrossum severity: normal status: open title: map and filter objects shouldn't call themselves

[issue1691070] Speed up PyArg_ParseTupleAndKeywords() and improve error msg

Neal Norwitz added the comment: Christian, Could you clean this patch up? Specifically: * Put everything into one patch * Eliminate unnecessary changes (changing variable name or whitespace) * Conform to the style in the file * Verify all the tests run with regrtest.py -u all when built

[issue2186] map and filter shouldn't support None as first argument (in Py3k only)

Alexander Belopolsky added the comment: In the absence of an identity function, map accepting None is useful in the cases like this: converters = {..} y = map(converters.get(c), x) That will now have to be rewritten as conv = converters.get(c) if conv is None: y = list(x) else: y =

[issue1740] use unittest for test_logging

Brett Cannon added the comment: I am attaching a reviewed version of the patch. It had some major PEP 8 violations that I had to clean up. I also moved over to the usage of test.test_support.captured_stdout(). Otherwise it looks good. I am going to wait a little while in hopes someone else can

[issue1540617] Use Py_ssize_t for rangeobject members

Martin v. Löwis added the comment: I fail to see the need for this, from more than an academic point of you. What specific event triggered your working on this? _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1540617

[issue1276] LookupError: unknown encoding: X-MAC-JAPANESE

Hye-Shik Chang added the comment: I'll take this. -- assignee: lemburg - hyeshik.chang nosy: +hyeshik.chang __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1276 __ ___