[issue20655] test_subprocess is not executed in python -m test.test_asyncio

Guido van Rossum added the comment: Please apply the fix and make sure it gets cherry-picked. I agree on dynamic test recovery but don't find it a high priority. -- ___ Python tracker <http://bugs.python.org/is

[issue20666] asyncio/OpenBSD: make concurrent.futures dependency optional

Guido van Rossum added the comment: I'd prefer not to add a bad hack to support such a broken platform. If it doesn't have semaphores, not much Python code will run. Maybe the dummy_threading module can be used instead? -- ___ Python trac

[issue20493] asyncio: OverflowError('timeout is too large')

Guido van Rossum added the comment: For now, can we just add to the asyncio docs that timeouts shouldn't exceed one day? Then we can fix it later without breaking expectations. -- ___ Python tracker <http://bugs.python.org/is

[issue20668] Remove dependency on tests.txt when running test_asyncio suite

Guido van Rossum added the comment: Thanks, LGTM. Please commit and add to issue 20648. -- ___ Python tracker <http://bugs.python.org/issue20668> ___ ___ Pytho

[issue19612] test_subprocess: sporadic failure of test_communicate_epipe() on Windows 8

Guido van Rossum added the comment: LGTM. Please commit in both repos and add to the list of cherrypicks for Larry. On Tue, Feb 18, 2014 at 1:40 AM, STINNER Victor wrote: > > STINNER Victor added the comment: > > If I add a sleep of 1 second before stdin.write(), the test always

[issue20648] 3.4 cherry-pick: multiple changesets for asyncio

Guido van Rossum added the comment: This one needs to be CP'ed together with Yuri's UNIX sockets one. changeset: 89257:f81106f36656 tag: tip user: Guido van Rossum date:Tue Feb 18 10:24:30 2014 -0800 summary: asyncio: Make tests pass

[issue20653] Pickle enums by name

Guido van Rossum added the comment: For the record I'm against it, but I don't have time to explain until after 3.4 has been released. -- nosy: +gvanrossum ___ Python tracker <http://bugs.python.o

[issue20653] Pickle enums by name

Guido van Rossum added the comment: It should not be changed after the release either. On Tue, Feb 18, 2014 at 11:57 AM, Serhiy Storchaka wrote: > > Serhiy Storchaka added the comment: > > This is sad. Because after a release, change it will be

[issue19612] test_subprocess: sporadic failure of test_communicate_epipe() on Windows 8

Guido van Rossum added the comment: Sorry, forget everything I said. (That includes the LGTM, sadly -- as I wrote earlier I don't know this code very well.) -- ___ Python tracker <http://bugs.python.org/is

[issue20648] 3.4 cherry-pick: multiple changesets for asyncio

Guido van Rossum added the comment: TBH I don't think typos or pep8 cleanups ought to be CP'ed... On Tuesday, February 18, 2014, Larry Hastings wrote: > > Larry Hastings added the comment: > > 2e8a142dbccc just missed today's cherry-picking sessi

[issue20648] 3.4 cherry-pick: multiple changesets for asyncio

Guido van Rossum added the comment: Actually I am trying to quell the tide. :-). But nobody sent me a review request for those... On Tuesday, February 18, 2014, Larry Hastings wrote: > > Larry Hastings added the comment: > > Perhaps, but if they request cherry-picking for rev

[issue20648] 3.4 cherry-pick: multiple changesets for asyncio

Guido van Rossum added the comment: Thanks for checking! On Tuesday, February 18, 2014, Larry Hastings wrote: > > Larry Hastings added the comment: > > For what it's worth, > > Lib/asyncio/* > Lib/test/test_asyncio/* > Doc/library/async* > > are all exact

[issue20648] 3.4 cherry-pick: multiple changesets for asyncio

Guido van Rossum added the comment: That one is not critical. It can go in sfter 3.4 is released. On Wednesday, February 19, 2014, Vajrasky Kok wrote: > > Vajrasky Kok added the comment: > > > It is slowing down. I think we now only have some documentation updates > left. &

[issue20668] Remove dependency on tests.txt when running test_asyncio suite

Guido van Rossum added the comment: Please wait until after 3.4 release. Not critical. On Wednesday, February 19, 2014, Yury Selivanov wrote: > > Changes by Yury Selivanov >: > > > -- > nosy: +yselivanov > > ___

[issue20720] test_create_server() of test_asyncio failure on "x86 Windows Server 2008 [SB] 3.x" buildbot

Guido van Rossum added the comment: I suspect it's just a race in the test. This happened to me recently too when I ran the tests on my Windows 7 laptop, and upon the second try it passed, so I just figured it was a race. After all the test does use run_briefly(), which might as we

[issue20720] test_create_server() of test_asyncio failure on "x86 Windows Server 2008 [SB] 3.x" buildbot

Guido van Rossum added the comment: Agreed. I suppose all tests currently using run_briefly() should be modified to use run_until() with a lambda and a timeout. The timeout must be (a) large enough to never fail on a buildbot, yet (b) small enough that when a test is actually failing we don&#

[issue20841] asyncio.StreamReader.readline() lack lines limit optional parameter

Guido van Rossum added the comment: > > It seems to me that the StreamReader() limit parameter is for buffer size > while the io.BytesIO.readline() "n" parameter is for maximum number of > lines to be retreived, I guess. > You sound confused. The parameter for io.Byte

[issue20847] asyncio docs should call out that network logging is a no-no

New submission from Guido van Rossum: The asyncio package uses the logging module. We should remind users that they should always configure their logs to go to a file on the local filesystem -- using any kind of network logging will block the event loop. -- assignee: haypo messages

[issue20847] asyncio docs should call out that network logging is a no-no

Guido van Rossum added the comment: If you really need network logging you should be able to configure a handler that puts things in a queue whose other end is serviced by an asyncio task. There should be no need to mess with the type of the logger object. Anyway, in 3.4 it is what it is

[issue20841] asyncio.StreamReader.readline() lack lines limit optional parameter

Guido van Rossum added the comment: Yes, your whole world will be turned upside-down. However, we have to do it one module at a time -- the approach will be different for each case. -- resolution: -> wont fix status: open -> closed ___

[issue1921] Confusing Descrintro example

Guido van Rossum added the comment: I'm guessing you weren't ready for learning about metaclasses if you didn't get the fact that 'name' was the loop control variable in the two different loops. The example is only 11 lines long! Still, I'm fine with the two su

[issue6490] os.popen documentation in 2.6 is probably wrong

Guido van Rossum added the comment: I am guessing the reason to keep os.popen() (albeit now reimplemented using subprocess) is that it is a convenient wrapper for a common use case and also familiar. I see no problem with this. (Indeed the big problem was with the proliferation of popenN

[issue1466065] base64 module ignores non-alphabet characters

Guido van Rossum added the comment: It strikes me as simply a documentation bug. Maybe whoever wrote the docs just assumed it would work that way. I expect that changing it to insist on valid input would break some use cases. If you want a validating API, perhaps a new API could be added that

[issue2335] Backport set literals

Guido van Rossum added the comment: Raymond, I know you see this differently, but personally I don't see a problem with 2.7 getting additional backports of 3.x features, as long as they are backwards compatible. While personally I wouldn't spend effort on this particular backport, I d

[issue6681] email.parser clips trailing \n of multipart/mixed part if part ends in \r\n

New submission from Guido van Rossum : I am using an edge case of multipart/mixed and find that the multipart/mix parser in the email package is broken. See attached example. Similar code using cgi.FieldStorage (!) works fine. The problem happens through the following combination of factors

[issue6681] email.parser clips trailing \n of multipart/mixed part if part ends in \r\n

Guido van Rossum added the comment: Older Python versions too. -- versions: +Python 2.5 ___ Python tracker <http://bugs.python.org/issue6681> ___ ___ Python-bug

[issue6695] PyXXX_ClearFreeList for dict, set, and list

Guido van Rossum added the comment: A slot in every type object for this purpose seems wasteful; the large majority of types won't have a free list. (Remember, each user-defined class allocates a full type structure on the heap.) -- assignee: gvanr

[issue2516] Instance methods are misreporting the number of arguments

Changes by Guido van Rossum : -- nosy: -gvanrossum ___ Python tracker <http://bugs.python.org/issue2516> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue6749] Support for encrypted zipfiles when interpreting zipfile as script

Guido van Rossum added the comment: Some (supportive) discussion on python-dev at http://mail.python.org/pipermail/python-dev/2009-August/091324.html . -- nosy: +gvanrossum ___ Python tracker <http://bugs.python.org/issue6

[issue6749] Support for encrypted zipfiles when interpreting zipfile as script

Changes by Guido van Rossum : -- nosy: -gvanrossum ___ Python tracker <http://bugs.python.org/issue6749> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue5135] Expose simplegeneric function in functools module

Guido van Rossum added the comment: Please don't introduce this without a PEP. -- nosy: +gvanrossum ___ Python tracker <http://bugs.python.org/issue5135> ___ ___

[issue7012] Tabs is better than spaces for identation

Guido van Rossum added the comment: Wow. You (rohdef) really do sound like you are a time capsule from the eighties. Tabs would save keystrokes and bandwidth, and are not confusing? The keystrokes argument is wrong for most editors; the bandwidth argument doesn't matter due to disk

[issue7008] str.title() misbehaves with apostrophes

Guido van Rossum added the comment: Raymond, please refrain from emotional terms like "bug factory". I have nothing to say about whether string.capwords() should be removed, but I want to note that it does a split on whitespace and then rejoins using a single space, so that strin

[issue7008] str.title() misbehaves with apostrophes

Guido van Rossum added the comment: A doc fix sounds like a great idea. -- ___ Python tracker <http://bugs.python.org/issue7008> ___ ___ Python-bugs-list mailin

[issue7008] str.title() misbehaves with apostrophes

Changes by Guido van Rossum : -- assignee: gvanrossum -> ___ Python tracker <http://bugs.python.org/issue7008> ___ ___ Python-bugs-list mailing list Unsubscri

[issue7012] Tabs is better than spaces for indentation

Changes by Guido van Rossum : -- nosy: -gvanrossum ___ Python tracker <http://bugs.python.org/issue7012> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue7008] str.title() misbehaves with apostrophes

Changes by Guido van Rossum : -- assignee: gvanrossum -> nosy: -gvanrossum ___ Python tracker <http://bugs.python.org/issue7008> ___ ___ Python-bugs-list mai

[issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds fail with KeyError

Guido van Rossum added the comment: Before we start pointing fingers or throwing mud, was this bug fix which apparently breaking setuptools introduced knowing that this would break setuptools users? I'm surprised that nobody at all tried to use the release candidate with any of the l

[issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds fail with KeyError

Guido van Rossum added the comment: Thanks for the quick action Tarek!!! -- ___ Python tracker <http://bugs.python.org/issue7064> ___ ___ Python-bugs-list mailin

[issue7083] locals() behaviour differs when tracing is in effect

Guido van Rossum added the comment: So there's no bug here right? It's even documented. -- nosy: +gvanrossum resolution: -> rejected status: open -> closed ___ Python tracker <http://bugs.p

[issue7105] weak dict iterators are fragile because of unpredictable GC runs

Guido van Rossum added the comment: > delay all removals until all iterators are done +1 -- nosy: +gvanrossum ___ Python tracker <http://bugs.python.org/iss

[issue7120] 2.6.4rc1 regression

New submission from Guido van Rossum : Following my own (Twitter) advice I downloaded the 2.6.4rc1 release candidate and installed it on my x86 iMac running OS X 10.5.8, and tried to run a Google App Engine app with it. Google App Engine prefers Python 2.5, but so far it has always worked

[issue7120] 2.6.4rc1 regression

Guido van Rossum added the comment: FWIW, I've ruled out App Engine SDK 1.2.6 as the source of the regression; on a MacBook Pro with the same OS 10.5.8 I get a similar traceback with SDK 1.2.6. -- ___ Python tracker <http://bugs.py

[issue7120] 2.6.4rc1 regression

Guido van Rossum added the comment: The full traceback had probably 1000 lines (or whatever the limit is); the piece between two calls to logging.warn() is repeated over and over. -- ___ Python tracker <http://bugs.python.org/issue7

[issue7120] 2.6.4rc1 regression

Guido van Rossum added the comment: Yes, App Engine uses a PEP 302 style import hook to implement the sandbox. Could it be that there's a new module dependency introduced by 2.6.3-4? -- ___ Python tracker <http://bugs.python.org/i

[issue7120] 2.6.4rc1 regression

Guido van Rossum added the comment: The dependency of logging on multiprocessing feels backwards. But it's not actually a new regression, it seems that was there in 2.6.2. -- ___ Python tracker <http://bugs.python.org/i

[issue7120] logging depends on multiprocessing

Guido van Rossum added the comment: The addition of multiprocessing support to logging seems to have happened in 2.6.2; bad timing for a feature. :-( -- title: 2.6.4rc1 regression -> logging depends on multiprocessing ___ Python tracker &l

[issue7120] logging depends on multiprocessing

Guido van Rossum added the comment: Confirmed, the stack limit error is gone now. Thanks!! (There's another error, the import of _scproxy from urllib, but that's easily added to the App Engine SDK's whitelist. I am still concerned about the amount of change in the 2.6 branch,

[issue7120] logging depends on multiprocessing

Guido van Rossum added the comment: (I don't know why the tracker reopened the issue when I added a comment. Anyway, is the fix going into 2.6.4 or will it have to wait for 2.6.5?) -- ___ Python tracker <http://bugs.python.org/i

[issue1235] CGIHTTPRequestHandler.run_cgi() does not run on Windows if sys.executable contains blanks

Changes by Guido van Rossum : -- nosy: -gvanrossum ___ Python tracker <http://bugs.python.org/issue1235> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue1294] Management of KeyboardInterrupt in cmd.py

Changes by Guido van Rossum : Removed file: http://bugs.python.org/file8578/unnamed ___ Python tracker <http://bugs.python.org/issue1294> ___ ___ Python-bugs-list mailin

[issue1294] Management of KeyboardInterrupt in cmd.py

Guido van Rossum added the comment: I don't think this is a good idea. -- resolution: -> rejected status: open -> closed ___ Python tracker <http://bugs.python

[issue1286] fileinput, StringIO, and cStringIO do not support the with protocol

Changes by Guido van Rossum : -- nosy: -gvanrossum ___ Python tracker <http://bugs.python.org/issue1286> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue1859] textwrap doesn't linebreak on "\n"

Guido van Rossum added the comment: I think the code originally wasn't meant to support this feature (honor embedded newlines when replace_whitespace=False). I'm thinking that we could add it though. Maybe Mark is interested in getting this into 2.7 and 3.2? I imagine it n

[issue7353] cporting docs recommend using Include/intobject.h, which was removed in 3.1?

Guido van Rossum added the comment: I don't think it would hurt to put it back, would it? I think the "remove this in 3.1" note was made when we expected 3.1 to be happening 1.5 years after 3.0 rather than a few months. -- no

[issue1515] deepcopy doesn't copy instance methods

Guido van Rossum added the comment: Smells like a feature to me. "Bug" == "coding error" "Feature" == "change in (documented or intended) behavior" I'm fine with this going into 2.7 / 3.2. -- ___ Pyth

[issue1771] Remove cmp parameter to list.sort() and builtin.sorted()

Guido van Rossum added the comment: Can someone provide a code sample to make this argument more understandable for those of us who don't compare points by angular order for a living... :-) I'm not sure what the 2to3 example (I presume you mean msg59937) shows except that convers

[issue1771] Remove cmp parameter to list.sort() and builtin.sorted()

Changes by Guido van Rossum : Removed file: http://bugs.python.org/file15463/unnamed ___ Python tracker <http://bugs.python.org/issue1771> ___ ___ Python-bugs-list mailin

[issue1771] Remove cmp parameter to list.sort() and builtin.sorted()

Changes by Guido van Rossum : Removed file: http://bugs.python.org/file15473/unnamed ___ Python tracker <http://bugs.python.org/issue1771> ___ ___ Python-bugs-list mailin

[issue1771] Remove cmp parameter to list.sort() and builtin.sorted()

Guido van Rossum added the comment: Python's sort implementation is carefully written to only use the "<" comparison, ever. So a cmp really isn't the most natural way to specify a comparison. (This should really be documented somewhere -- I know know it because T

[issue7459] Magic word incorrect in Python 3

Guido van Rossum added the comment: I don't see a bug here. The value returned by imp.get_magic() matches the first bytes of a bytecode file. That's all that matters. Of course, we could remove the global variable and just use the defined constant; but that's just an opti

[issue1580] Use shorter float repr when possible

Guido van Rossum added the comment: What maintenance issues are you anticipating? ___ Python tracker <http://bugs.python.org/issue1580> ___ ___ Python-bugs-list mailin

[issue1580] Use shorter float repr when possible

Guido van Rossum added the comment: On Thu, Feb 26, 2009 at 1:01 PM, Tim Peters wrote: > Is it worth it?  To whom ;-) ?  It was discussed several times before on > various Python mailing lists, and nobody was willing to sign up for the > considerable effort required (both to update G

[issue5380] pty.read raises IOError when slave pty device is closed

Guido van Rossum added the comment: IIUC the problem is that a read() syscall on the pty after the other end has been closed raises an error instead of reading 0 bytes? Isn't that a bug in the pty implementation? For lots of devices (e.g. sockets, pipes) a short non-empty read just means

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Guido van Rossum added the comment: Agreed. Multiple threads trying to read interactive input from a keyboard sounds like a bad idea anyway. ___ Python tracker <http://bugs.python.org/issue1

[issue5380] pty.read raises IOError when slave pty device is closed

Guido van Rossum added the comment: That may be how it works, but how do you expect to deal with it? ___ Python tracker <http://bugs.python.org/issue5380> ___ ___ Pytho

[issue5389] Uninitialized variable may be used in PyUnicode_DecodeUTF7Stateful()

New submission from Guido van Rossum : [Found by a Googler who prefers to remain anonymous] This might be easier to trigger on a 64-bit: PyObject *PyUnicode_DecodeUTF7Stateful(...) { ... Py_ssize_t startinpos; ... while (s < e) { ... utf7Error: outpos

[issue5380] pty.read raises IOError when slave pty device is closed

Guido van Rossum added the comment: > Well, as I suggested, in FileIO.read(): when receiving errno=5 on a > read() call and if S_IFIFO() returns true, clear errno and return an > empty string. > The question is whether a genuine EIO error ("low level IO error")

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Guido van Rossum added the comment: Hm, I'm not sure why Adam brought up readline. The behavior is certainly guaranteed (I put that guarantee in myself long ago :-) and it should be fixed. I have no opinion about the proposed patch, since I cannot test this and have long lost suffi

[issue1580] Use shorter float repr when possible

Guido van Rossum added the comment: I tried that, and it was more subtle than that in corner cases. Another argument against it is that on Windows the system input routine doesn't correctly round unless 17 digits of precision are given. One of Tim Peters's responses should have e

[issue5389] Uninitialized variable may be used in PyUnicode_DecodeUTF7Stateful()

Guido van Rossum added the comment: It looks like it was fixed in 2.6 by adding an assignment to startinpos to this block: else if (SPECIAL(ch,0,0)) { startinpos = s-starts; /* <-- This was added */ errmsg = "unexpected special character";

[issue1580] Use shorter float repr when possible

Guido van Rossum added the comment: I changed my mind on the cross-platform requirement. ___ Python tracker <http://bugs.python.org/issue1580> ___ ___ Python-bugs-list m

[issue1641] asyncore delayed calls feature

Guido van Rossum added the comment: The idea is to be able (whether you see a use case or not) to use different tasks lists simultaneously. Messing with globals is the worst possible API for that. All you need is to add a tasks=None argument to the loop() signature, rename the global tasks

[issue1641] asyncore delayed calls feature

Guido van Rossum added the comment: You could solve this with a "reserved" keyword argument _tasks. Or you could have two different factory methods, call_later_with_tasks() and call_later(). ___ Python tracker <http://bugs.python.

[issue1580] Use shorter float repr when possible

Guido van Rossum added the comment: Sounds good to me. ___ Python tracker <http://bugs.python.org/issue1580> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue5426] README slight error re OSX

Guido van Rossum added the comment: What makes you think it is not called python.exe? Maybe you're confused by the Finder's auto-hiding of externsions? -- nosy: +gvanrossum resolution: -> invalid status: open -> closed ___ Pytho

[issue5389] Uninitialized variable may be used in PyUnicode_DecodeUTF7Stateful()

Guido van Rossum added the comment: Well, this one is technically a security fix, though I have no idea how it could be exploited unless you offer your users a facility to execute arbitrary Python code. ___ Python tracker <http://bugs.python.org/issue5

[issue5426] README slight error re OSX

Guido van Rossum added the comment: That sentence however does not refer to the name of the installed Python binary, but the binary as it is built in the source tree (or a build directory). And there we chose to call it "python.exe" because we couldn't call it "python"

[issue5389] Uninitialized variable may be used in PyUnicode_DecodeUTF7Stateful()

Guido van Rossum added the comment: OK, submitted. -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/issue5389> ___ __

[issue400608] just testing

Guido van Rossum added the comment: This is specific to the Python tracker, which Rietveld tries to avoid. You could maintain this as a locally modified version, but a better approach would be to make just enough changes to upload.py itself so that you can write the rest of this script as a

[issue5237] Allow auto-numbered replacement fields in str.format() strings

Guido van Rossum added the comment: Please go ahead and finish this. I'm glad this is going in! -- message_count: 16.0 -> 17.0 nosy: +gvanrossum nosy_count: 6.0 -> 7.0 ___ Python tracker <http://bugs.python

[issue2312] Update PEP 3135 (super())

Guido van Rossum added the comment: Thanks for contributing. However since you reformatted the whole file it's kind of hard to see what you changed, which makes review laborious. Could you try to upload a unified diff relative to the PEP source code in Subve

[issue2312] Update PEP 3135 (super())

Guido van Rossum added the comment: Thanks! Reviewing now... -- assignee: georg.brandl -> gvanrossum ___ Python tracker <http://bugs.python.org/iss

[issue2312] Update PEP 3135 (super())

Guido van Rossum added the comment: Submitted as revision 70312, with some additional changes. I suppose it could use some more work (e.g. adding the penultimate proposal to the History section) but I'll leave that to others. (Lie, if you feel like writing that history section, just add

[issue5237] Allow auto-numbered replacement fields in str.format() strings

Guido van Rossum added the comment: Not sure if that's worth it -- doesn't sound like the people who would need that feature would mind much using explicit numbering. Let's try KISS. -- ___ Python tracker <http://bugs.py

[issue5237] Allow auto-numbered replacement fields in str.format() strings

Guido van Rossum added the comment: (I meant that as a reply to the {:{fmt}} example, but it applies to your later post too. :-) -- ___ Python tracker <http://bugs.python.org/issue5

[issue5237] Allow auto-numbered replacement fields in str.format() strings

Guido van Rossum added the comment: > About '{:{fmt}}' and other wacky combinations, like '{.__doc__}': > > It's much easier and cleaner in the code to allow these cases than it > would be to disallow them. And I rather like the '{:{fmt}}' exampl

[issue5530] datetime class names should obey PEP 8 CapWords convention

Guido van Rossum added the comment: Please don't do this. We need stable APIs. Trying to switch the entire community to use CapWord APIs for something as commonly used as datetime sounds like wasting a lot of cycles with no reason except the mythical "PEP 8 conformance". As I sa

[issue5577] yield in iterators

Guido van Rossum added the comment: Can anyone think of a *reason* to put a yield inside a generator expression? ISTM we could just forbid this syntactically. It seems insane and hard to read so if someone has a reason they should write it out using an explicit for-statement. -- nosy

[issue5577] yield in iterators

Guido van Rossum added the comment: Fine! -- resolution: -> wont fix status: open -> closed ___ Python tracker <http://bugs.python.org/issue5577> ___ ___

[issue2591] ErrorHandler buffer overflow in ?unused? SGI extension module almodule.c

Guido van Rossum added the comment: (Almost) nobody uses these any more, so let's close as won't fix. The SGI modules are removed from 3.0. The few people who still have Irix could probably care less about the buffer overflows, but they *might* care about the modules (otherwise the

[issue2578] Figure out what to do with unittest's redundant APIs

Guido van Rossum added the comment: The naming pattern (assertListEqual, assertDictEqual, etc.) is pretty easy to pick up so I don't think the addition of several new methods is a big deal. Making assertEqual() do the right thing all the time is hard if there are subclasses that might ove

[issue2578] Figure out what to do with unittest's redundant APIs

Guido van Rossum added the comment: I would love to use the time machine to kill the 'fail' variants as well as 'assert_'. However they are in use and we don't want to break people's tests. Breaking tests is painful. And there are a lots of tests. So we'

[issue4352] imp.find_module() fails with a UnicodeDecodeError when called with non-ASCII search paths

Guido van Rossum added the comment: At the sprint, Andrew Svetlov, Martin von Loewis and I looked into this a bit, and discovered that Andrew's Vista copy uses a Russian locale for the filesystem encoding (despite using English as the language). In this locale, a-umlaut cannot be repres

[issue5604] imp.find_module() mixes UTF8 and MBCS

New submission from Guido van Rossum : There's a path in imp.find_module that mixes encodings. The module name is encoded to char* using UTF-8 by the 's' format passed to PyArg_ParseTuple(). But the path name is converted (in the loop over the path in find_module()) to

[issue1175933] threading.Condition.wait() return value indicates timeout

Guido van Rossum added the comment: Since Tim Peters is the absolute authority on concurrency in Python, let's just close this as Rejected rather than letting it sit here forever. -- nosy: +gvanrossum resolution: -> rejected status: open -

[issue1674032] Make threading.Event().wait(timeout=3) return isSet

Guido van Rossum added the comment: Looking at this, I think this change is fine. The _Event class itself holds the condition that it's checking for, and the is_set() method doesn't acquire the lock, so there's no reason to prefer e.wait() if e.is_set(): GOT_IT()

[issue1522237] _threading_local.py logic error in _localbase __new__

Guido van Rossum added the comment: Looks good to me. Amaury, can you make sure this lands in 2.6, 2.7, 3.0 and 3.1? -- assignee: -> amaury.forgeotdarc nosy: +gvanrossum resolution: -> accepted ___ Python tracker <http://bugs.p

[issue2578] Figure out what to do with unittest's redundant APIs

Guido van Rossum added the comment: > Antoine Pitrou added the comment: > Wouldn't it be simpler to make assertRaises return the exception and let > the calling code match it as it feels like? Hm, that sounds awfully familiar. I can't recall if there was ever a good re

[issue5604] imp.find_module() mixes UTF8 and MBCS

Guido van Rossum added the comment: Thanks Andrew! Committed to 3.0.2 as 70756. Should be merged into 3.1, but should *not* be backported to 2.x. -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/

<    40   41   42   43   44   45   46   47   48   49   >