[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1

Martin v. Löwis added the comment: > Martin, can you please elaborate on this? I never heard of such > "standards" in OSS. MAL already gave the link. From the link: Sometimes package developers are tempted to set user variables such as CFLAGS because it appears to make their job easier. Howeve

[issue7244] itertools.zip_longest behaves strangely with an iterable class

New submission from Daniel Urban : I'm trying to write an iterable class, and it behaves strangely with itertools.zip_longest. The following example demonstrates this: class Repeater: # this class is similar to itertools.repeat def __init__(self, o, t): self.o = o self.t = int(t

[issue7117] Backport py3k float repr to trunk

Mark Dickinson added the comment: r75979: Deprecate PyOS_ascii_atof and PyOS_ascii_strtod; document PyOS_double_to_string. -- ___ Python tracker ___ __

[issue7244] itertools.zip_longest behaves strangely with an iterable class

Hirokazu Yamamoto added the comment: I saw strange thing with following code + release26-maint/trunk. from itertools import * class Repeater(object): # this class is similar to itertools.repeat def __init__(self, o, t): self.o = o self.t = int(t) def __iter__(self): # its i

[issue7244] itertools.zip_longest behaves strangely with an iterable class

Hirokazu Yamamoto added the comment: I hope an attached patch will fix this issue. (this patch is for trunk) I think PyErr_Clear() is needed to clear StopIteration there. -- keywords: +patch versions: +Python 2.6, Python 2.7, Python 3.2 Added file: http://bugs.python.org/file15239/fix_i

[issue6603] Compilation error if configuref --with-computed-gotos

Mark Dickinson added the comment: Applied to 2.7, 2.6, 3.2, 3.1 in r75982 through r75985. -- stage: patch review -> committed/rejected status: open -> closed ___ Python tracker _

[issue7244] itertools.zip_longest behaves strangely with an iterable class

Georg Brandl added the comment: The patch is incorrect; tp_iternext can raise exceptions other than StopIteration which must be let through. -- assignee: -> rhettinger nosy: +georg.brandl, rhettinger ___ Python tracker

[issue7042] test_signal fails on os x 10.6

Mark Dickinson added the comment: I've fixed test_itimer_virtual and test_itimer_prof to use a timeout instead of an xrange/range(1) loop, in r75986 through r75989. -- status: open -> closed ___ Python tracker

[issue3864] 26.rc1: test_signal issue on FreeBSD 6.3

Mark Dickinson added the comment: I'm hoping (though it's only a faint hope) that the change in r75986 might allow the test suite to run to completion on the FreeBSD buildslave. -- nosy: +mark.dickinson ___ Python tracker

[issue7244] itertools.zip_longest behaves strangely with an iterable class

Daniel Urban added the comment: > I saw strange thing with following code + release26-maint/trunk. I tried your code (with the new-style class) with Python 2.6.4 and 2.7a0 (trunk), and both worked fine. I built them with GCC 4.2.4 on Ubuntu 8.04. -- ___

[issue7195] Value error 'path is on drive c: start on drive d:' in os.path.relpath

Jason R. Coombs added the comment: Based on the response, then the documentation is inadequate. I don't want to make a stink about this, but I think the issue is still unresolved. If it would be better to discuss this elsewhere, please advise. The documentation says "Return a relative filepath

[issue7228] %lld for PyErr_Format (Modules/_io/bufferedio.c)

Mark Dickinson added the comment: Patch to add %lld support to PyString_FromFormat(V). (Against the trunk.) -- keywords: +patch stage: -> patch review type: -> feature request Added file: http://bugs.python.org/file15240/add_lld_format.patch ___ P

[issue7210] Proposed Syntax Checks in Test Suite

Chuck Rhode added the comment: Thanks. -ccr- -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue7195] Value error 'path is on drive c: start on drive d:' in os.path.relpath

Nick Coghlan added the comment: The path *returned* is relative to the start point. The target path is figured out normally (i.e. relative to the current directory if an absolute path is not given). In your example, you aren't passing in an absolute Windows path - you give a path relative to th

[issue7195] Value error 'path is on drive c: start on drive d:' in os.path.relpath

Jason R. Coombs added the comment: The documentation changes I suggested make no mention to Windows pathing quirks. They instead clarify two aspects: 1) cross-platform behavior (how the path is interpreted) and 2) platform-specific implementation of relpath (what Python exceptions to expect in

[issue7228] %lld for PyErr_Format (Modules/_io/bufferedio.c)

Hirokazu Yamamoto added the comment: I tried your patch on windows, your patch worked great. One little thing: I think line 346 of patch can be wrapped with "#ifdef HAVE_LONG_LONG". -- ___ Python tracker __

[issue7244] itertools.zip_longest behaves strangely with an iterable class

Georg Brandl added the comment: > I tried your code (with the new-style class) with Python 2.6.4 and 2.7a0 > (trunk), and both worked fine. I built them with GCC 4.2.4 on Ubuntu 8.04. The problem seems to only show up in debug builds on 2.x, but it is there. -- ___

[issue5972] Failing test_signal.py on Redhat 4.1.2-44

Mark Dickinson added the comment: I think this failure may now be fixed in svn: see issue #7042. dmauldin, are you in a position to test this on Red Hat with a recent svn checkout? (Either trunk or release26-maint, it doesn't matter which.) -- ___

[issue7244] itertools.zip_longest behaves strangely with an iterable class

Raymond Hettinger added the comment: I've got it from here. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue7245] better Ctrl-C support in pdb (program can be resumed)

New submission from Ilya Sandler : Currently, pressing Ctrl-C in pdb will terminate the program and throw the user into post-mortem debugging. Other debuggers (e.g gdb and pydb) treat Ctrl-C differently: Ctrl-C only stops the program and the user can resume it if needed. I believe current pdb

[issue7242] Forking in a thread raises RuntimeError

Gregory P. Smith added the comment: This only appears to happen on Solaris. What version of Solaris are you using? (i doubt that matters, i expect it happens on all versions) I haven't look closely enough at the code yet, but reinitializing the import lock in the child process should make s

[issue7208] Getpass echo's password to screen on 2.6, but not on 2.5 or 3.1

Changes by Gregory P. Smith : -- assignee: -> gregory.p.smith nosy: +gregory.p.smith -gps ___ Python tracker ___ ___ Python-bugs-list

[issue6748] test_debuglevel from test_telnetlib.py fails

Changes by Ezio Melotti : -- nosy: +ezio.melotti priority: -> normal ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscr

[issue7208] Getpass echo's password to screen on 2.6, but not on 2.5 or 3.1

Gregory P. Smith added the comment: Peter - can you apply the patch from svn r76000 and test that it works properly on Solaris? -- ___ Python tracker ___ ___

[issue7208] Getpass echo's password to screen on 2.6, but not on 2.5 or 3.1

Antoine Pitrou added the comment: Regarding your comment in r76000: """NOTE: The Python C API calls flockfile() (and unlock) during readline.""" This may be true in 2.x but not in 3.x. Does it have any security implication? -- ___ Python tracker

[issue6748] test_debuglevel from test_telnetlib.py fails

Antoine Pitrou added the comment: This failure actually still happens quite regularly (on the buildbots and also on my Mandriva system). Judging from a quick Google search, errno 104 (ECONNRESET) should be treated as a case of EOF (it means the TCP connection was reset using RST rather than FIN

[issue6748] test_debuglevel from test_telnetlib.py fails

Derk Drukker added the comment: This patch fixes the issue. -- keywords: +patch nosy: +drukker Added file: http://bugs.python.org/file15242/issue6748.patch ___ Python tracker ___

[issue6748] test_debuglevel from test_telnetlib.py fails

Eric Smith added the comment: I still get 'Connection reset by peer' on OS/X 10.5.8 with this patch (http://bugs.python.org/file15242/issue6748.patch). -- nosy: +eric.smith ___ Python tracker __

[issue6748] test_debuglevel from test_telnetlib.py fails

Jack Diederich added the comment: Antoine Pitrou: Besides, the test flow in test_telnetlib really is a mess (setUp and tearDown getting called multiple times, for example), could you clean it up? Yes, I'm working on refactoring the test server and separating out testing that versus testing the

[issue6896] Intermittent failures in test_mailbox

Antoine Pitrou added the comment: Looking at the frequent buildbot failures, they always seem to happen in TestMaildir. Therefore, it may have to do with the metadata-updating behaviour of the filesystem (since maildir uses one file per message). Unfortunately, while I tried to reproduce the fa

[issue7208] Getpass echo's password to screen on 2.6, but not on 2.5 or 3.1

Gregory P. Smith added the comment: It might mean that other threads with access to the same file handle could interfere and intercept part of the password entry if they wanted to but thats not too concerning. py3k/Modules/_io/bufferedio.c which is presumably used when input is sys.stdin ins

[issue6748] test_debuglevel from test_telnetlib.py fails

Derk Drukker added the comment: The change in the patch worked for me on py3k on Ubuntu 9.10. It makes sense, though, that it could still fail: conn can get closed too soon. -- ___ Python tracker _

[issue1006238] cross compile patch

Garrett Cooper added the comment: I'm trying to resolve this issue on: 2.6-releasemaint trunk 3.1-releasemaint py3k first by resolving issues configure.in, but there are a TON of AC_TRY_RUN's, which means that this code cannot be cross-compiled as-is (25 on 2.x -- 27 on 3.x). Is requiring the

[issue1006238] cross compile patch

Gregory P. Smith added the comment: Documenting the parameters needed to avoid all AC_TRY_RUNs is a good first step for any that are not obvious how to convert from AC_TRY_RUN into something else. -- ___ Python tracker

[issue6896] Intermittent failures in test_mailbox

Antoine Pitrou added the comment: Ezio, could you give a try to the following patch? -- keywords: +patch Added file: http://bugs.python.org/file15243/test_mailbox.patch ___ Python tracker __

[issue6896] Intermittent failures in test_mailbox

Changes by Antoine Pitrou : -- nosy: +r.david.murray ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail

[issue6896] Intermittent failures in test_mailbox

Antoine Pitrou added the comment: Another possible explanation is that the logic for computing Maildir._last_time is wrong. It should be computed before refreshing the internal cache, not after. Here is a patch. -- Added file: http://bugs.python.org/file15244/test_mailbox2.patch __

[issue6896] Intermittent failures in test_mailbox

Antoine Pitrou added the comment: According to testers, both patches fail at addressing the issue. -- ___ Python tracker ___ ___ Pytho

[issue6896] Intermittent failures in test_mailbox

Changes by Antoine Pitrou : Removed file: http://bugs.python.org/file15243/test_mailbox.patch ___ Python tracker ___ ___ Python-bugs-list maili

[issue6896] Intermittent failures in test_mailbox

Changes by Antoine Pitrou : Removed file: http://bugs.python.org/file15244/test_mailbox2.patch ___ Python tracker ___ ___ Python-bugs-list mail

[issue7195] Value error 'path is on drive c: start on drive d:' in os.path.relpath

Nick Coghlan added the comment: os.relpath *does* give you a relative path between two directories. The problem you are encountering is that, on Windows, a relative path doesn't even *exist* if the two directories are on different drives (which is exactly what the error message says).

[issue6896] Intermittent failures in test_mailbox

R. David Murray added the comment: I hacked mailbox.py so that a _toc refresh is always done and ran the tests in a loop, and did not get a failure in 30+ runs, whereas without that hack I would get failures almost every run. So I think Antoine is on the right track. -- __

[issue7245] better Ctrl-C support in pdb (program can be resumed)

Raghuram Devarakonda added the comment: It is better for this functionality to be added in "Cmd" module as that will benefit all users of that module. Please see bug #1294 which has a patch for this purpose. It would be nice if you can test with that patch and see if pdb works as you expected.