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

[Martin v . Löwis]

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. However, the package
itself should never set a user variable, particularly not to include
switches that are required for proper compilation of the package. Since
these variables are documented as being for the package builder, that
person rightfully expects to be able to override any of these variables
at build time.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Daniel Urban]

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)
   def __iter__(self): # its iterator is itself
   return self
   def __next__(self):
   if self.t > 0:
   self.t -= 1
   return self.o
   else:
   raise StopIteration

(Of course this is a trivial class, which could be substituted with
itertools.repeat, but I wanted to keep it simple for this example.)

The following code shows my problem:
>>> r1 = Repeater(1, 3)
>>> r2 = Repeater(2, 4)
>>> for i, j in zip_longest(r1, r2, fillvalue=0):
... print(i, j)
...
1 2
1 2
1 2
0Traceback (most recent call last):
 File "", line 2, in 
 File "zip_longest_test_case.py", line 30, in __next__
   raise StopIteration
StopIteration
>>>

It seems, that zip_longest lets through the StopIteration exception,
which it shouldn't. 

The strange thing is, that if I use the python implementation of
zip_longest, as it is in the documentation [1], I get the expected
result:

# zip_longest as it is in the documentation:
def zip_longest(*args, fillvalue=None):
   # zip_longest('ABCD', 'xy', fillvalue='-') --> Ax By C- D-
   def sentinel(counter = ([fillvalue]*(len(args)-1)).pop):
   yield counter() # yields the fillvalue, or raises IndexError
   fillers = repeat(fillvalue)
   iters = [chain(it, sentinel(), fillers) for it in args]
   try:
   for tup in zip(*iters):
   yield tup
   except IndexError:
   pass

Test code again:
>>> r1 = Repeater(1, 3)
>>> r2 = Repeater(2, 4)
>>> for i, j in zip_longest(r1, r2, fillvalue=0):
... print(i, j)
...
1 2
1 2
1 2
0 2

I would think, that this is the expected behaviour.

Also, Matthew Dixon Cowles discovered, that if using list(), the C
implementation of itertools.zip_longest also works fine:

>>> r1=Repeater(1,3)
>>> r2=Repeater(2,5)
>>> list(itertools.zip_longest(r1,r2,fillvalue=0))
[(1, 2), (1, 2), (1, 2), (0, 2), (0, 2)]

This is strange, and I think it really shouldn't work this way. 
(Thanks for Matthew Dixon Cowles' help on the python-help mailing list.)

I'm attaching a test script, which tries all 4 variations (library
zip_longest with and without list(), and the documentation's zip_longest
impplementation with and without list()). 

And another thing: it works fine in 2.6.4 (with izip_longest).

--
components: Extension Modules
files: zip_longest_test_case.py
messages: 94746
nosy: durban
severity: normal
status: open
title: itertools.zip_longest behaves strangely with an iterable class
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file15238/zip_longest_test_case.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7117] Backport py3k float repr to trunk

[Mark Dickinson]

Mark Dickinson  added the comment:

r75979:  Deprecate PyOS_ascii_atof and PyOS_ascii_strtod;  document
 PyOS_double_to_string.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Hirokazu Yamamoto]

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 iterator is itself
   return self
   def next(self):
   if self.t > 0:
   self.t -= 1
   return self.o
   else:
   raise StopIteration

r1 = Repeater(1, 3)
r2 = Repeater(2, 4)
for i, j in izip_longest(r1, r2, fillvalue=0):
print(i, j)

Be care that Repeater is using new-style class. (it's default on py3k) I
couldn't see any problem with officially released windows binary, but I
could see following error with VC6 debug build.

(1, 2)
(1, 2)
(1, 2)
(0, 2)
XXX undetected error
Traceback (most recent call last):
  File "a.py", line 20, in 
print(i, j)
  File "a.py", line 15, in next
raise StopIteration
StopIteration

# Still there is possibility this is VC6 bug though.

--
nosy: +ocean-city

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Hirokazu Yamamoto]

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_izip_longest.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Dickinson]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Georg Brandl]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7042] test_signal fails on os x 10.6

[Mark Dickinson]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Dickinson]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Daniel Urban]

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Jason R. Coombs]

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 to path either from
the current directory or from an optional start point".

The documentation should say "Return a relative filepath to a path,
where path is considered relative to the current directory, either from
the current directory or from an optional start point. On Windows, a
ValueError is raised if the current directory and the start path are not
on the same drive."

The clarification is that the path specified is _not_ relative to the
start point (which would have been my guess), but is relative to another
unspecified environmental condition (the current directory). To leave
out this clarification means that this implicit behavior is left to the
user to discover rather than to state that it's by design.

For my purposes, I wanted a function that would calculate a target based
on a start path and a relative or absolute path from it. Based on the
documentation, I thought relpath was it.

I understand better now what the purpose of relpath is, and it's not
what I was expecting. I think the documentation could be improved to
help manage this expectation for other users.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Dickinson]

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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7210] Proposed Syntax Checks in Test Suite

[Chuck Rhode]

Chuck Rhode  added the comment:

Thanks.  -ccr-

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Nick Coghlan]

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 the current drive (since no drive is specified).

Windows file pathing is hopeless, but it isn't the job of Python's
documentation to explain its quirks.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Jason R. Coombs]

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 exceptional conditions).

These two changes would have made it clear to me from the beginning that
relpath is not what I was searching for when I wanted to find a path
from one path to another. I'm just trying to help those who come after
me to not run into the same situation.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Hirokazu Yamamoto]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Georg Brandl]

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Dickinson]

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.)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Raymond Hettinger]

Raymond Hettinger  added the comment:

I've got it from here.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Ilya Sandler]

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 behavior is user-unfriendly (as wanting to stop
and then resume the execution is a very common use case which is not
supported by pdb at all (I think)).


The attached patch changes pdb's Ctrl-C behavior to match
gdb's: Ctrl-C will stop the program and the user can resume the
execution later.

--
components: Library (Lib)
files: sig.patch.v0
messages: 94764
nosy: isandler
severity: normal
status: open
title: better Ctrl-C support in pdb (program can be resumed)
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file15241/sig.patch.v0

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7242] Forking in a thread raises RuntimeError

[Gregory P. Smith]

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 sense here.

--
assignee:  -> gregory.p.smith
nosy: +twouters
priority:  -> normal
versions: +Python 2.7, Python 3.1, Python 3.2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Gregory P. Smith]

Changes by Gregory P. Smith :


--
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith -gps

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6748] test_debuglevel from test_telnetlib.py fails

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +ezio.melotti
priority:  -> normal

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Gregory P. Smith]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Antoine Pitrou]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6748] test_debuglevel from test_telnetlib.py fails

[Antoine Pitrou]

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, which apparently sometimes happens).

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?

--
nosy: +pitrou
versions: +Python 3.2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6748] test_debuglevel from test_telnetlib.py fails

[Derk Drukker]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6748] test_debuglevel from test_telnetlib.py fails

[Eric Smith]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6748] test_debuglevel from test_telnetlib.py fails

[Jack Diederich]

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 telnetlib.  It is the test server (which
started simple and then grew cruft) which seems to have OS specific
problems.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6896] Intermittent failures in test_mailbox

[Antoine Pitrou]

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 failures on my home system
with a variety of filesystems (ext3, ext4, reiserfs, xfs and even vfat),
I never got any failure here.

Ezio, could you give details on your system, your filesystem and its
mount options? (if you don't know them, look in /proc/mounts)

--
nosy: +pitrou
versions: +Python 3.1

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Gregory P. Smith]

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 instead of a /dev/tty file appears to lock things.

Compared to glibc's getpass implementation the locking should probably 
be done around a wider swath of getpass code in order to protect all 
possible race conditions of other code accessing the handle as we set it 
up and display the prompt.  I don't really think it is something worry 
about as it requires code executing within the context of your own 
getpass calling program to be doing something that'll interfere with 
your password reading.  If someone has -that- problem they have bigger 
issues.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6748] test_debuglevel from test_telnetlib.py fails

[Derk Drukker]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1006238] cross compile patch

[Garrett Cooper]

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 end-user to define the autoconf variables appropriately
to their platform when running configure (when provided an error message
telling them so), a longterm sustainable requirement? I know it isn't as
user friendly, but this is a definite problem that either needs to be
fixed in the autoconf tests (if possible) or the C code itself.

I wouldn't mind updating the INSTALL or README files to reflect this
change either, if needed.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1006238] cross compile patch

[Gregory P. Smith]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6896] Intermittent failures in test_mailbox

[Antoine Pitrou]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6896] Intermittent failures in test_mailbox

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +r.david.murray

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6896] Intermittent failures in test_mailbox

[Antoine Pitrou]

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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6896] Intermittent failures in test_mailbox

[Antoine Pitrou]

Antoine Pitrou  added the comment:

According to testers, both patches fail at addressing the issue.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6896] Intermittent failures in test_mailbox

[Antoine Pitrou]

Changes by Antoine Pitrou :


Removed file: http://bugs.python.org/file15243/test_mailbox.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6896] Intermittent failures in test_mailbox

[Antoine Pitrou]

Changes by Antoine Pitrou :


Removed file: http://bugs.python.org/file15244/test_mailbox2.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Nick Coghlan]

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).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6896] Intermittent failures in test_mailbox

[R. David Murray]

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Raghuram Devarakonda]

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.

--
nosy: +draghuram

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com