R. David Murray added the comment:
If you know what an iterator is, the documentation, it seems to me, is clear.
That is, an iterator cannot be indexed, so the behavior you expected could not
be implemented by enumerate.
That doesn't meant the docs shouldn't be improved. An exam
R. David Murray added the comment:
Your code doesn't appear to have anything to do with the reported bug, which is
about an infinite loop. But FYI to my understanding your script can't work on
windows, since foo can't be imported. On linux, foo doesn't
R. David Murray added the comment:
My fix (and the tests) for this are wrong. decode_header returns (binary,
charset) pairs, but the chunks list is (string, charset) pairs.
--
stage: committed/rejected -> needs patch
status: closed ->
New submission from R. David Murray :
I went to write a test that would trigger something if it was run on 3.3.0, and
had to look in the source code to figure out what the hexversion for that would
be. I think the hexversion algorithm should be documented in its sys entry
R. David Murray added the comment:
You subclassed unicode. So print printed the value of your unicode object,
which didn't need coercion.
--
nosy: +r.david.murray
resolution: -> invalid
stage: -> committed/rejected
status: ope
R. David Murray added the comment:
For the record, this isn't as simple as I made it sound. See, for example,
issue 9196.
--
___
Python tracker
<http://bugs.python.org/is
R. David Murray added the comment:
Note that when this is fixed, make_header on the return value from
decode_header will fail because it doesn't know now to handle unknown-8bit.
--
___
Python tracker
<http://bugs.python.org/is
R. David Murray added the comment:
Well, it's possible I'm wrong and you've found a bug. There are numerous
differences between 2 and 3 in both string handling and special method
handling, though, so it may be hard to pin down. If you poke around a bit more
and still th
Changes by R. David Murray :
--
stage: -> patch review
type: -> feature request
versions: +Python 3.3
___
Python tracker
<http://bugs.python.org/i
R. David Murray added the comment:
Given that it happens randomly I suspect a timing issue, but without having
reviewed the code in question. I'm not sure when I'll have time to look at
this.
--
___
Python tracker
<http://bu
Changes by R. David Murray :
--
status: closed -> open
___
Python tracker
<http://bugs.python.org/issue9319>
___
___
Python-bugs-list mailing list
Unsubscri
R. David Murray added the comment:
Yeah, I looked at the source of calendar.gmtime, and it turns out it ignores
the isdst flag, which it also seems should be irrelevant anyway, looking at the
test code again.
I tried setting my /etc/localtime to /usr/share/zoneinfo/posix/Asia/Calcutta
R. David Murray added the comment:
For the record: yes this is the way regrtest works when a test named on the
command line doesn't exist. Not pretty, I'll grant you. Maybe someone will
propose a patch/feature request to improve the error message some day.
--
nosy: +r.da
R. David Murray added the comment:
Your best resources would probably be the python mailing list (python-list, see
http://mail.python.org) which is also comp.lang.python, or the #python irc
channel on freenode.
--
___
Python tracker
<h
R. David Murray added the comment:
Thanks! I tidied up the ReST formatting a bit and changed the bit numbering to
the more standard left to right order (standard for bit fields...I realize
hexversion is a number, but conceptually one deals with it as a bit field).
--
resolution
R. David Murray added the comment:
So this is probably not a python problem at all, but a problem with your system
c library time functions. time.mktime is a thin wrapper around the mktime libc
call. Perhaps you could write a short C program to test it? I've added Barry
as nosy sin
R. David Murray added the comment:
As part of fixing this we should add a unit test to pydoc that goes something
like this:
assertEqual(sorted(pydoc.Helper.keywords.keys())), sorted(keyword.kwlist))
--
nosy: +r.david.murray
___
Python tracker
R. David Murray added the comment:
We don't ship unless all tests pass on all of our test platforms (and we have
quite a few). If you look at that test it says the regex "should match 'ls -ld
/.' on any posix system, however perversely configured". Perhaps your
R. David Murray added the comment:
The re matches for me if I call it manually with your ls -ld output.
What output do you get if you do a 'print commands.getstatus("/.")' using your
build of the python interpreter?
By the way, this is a deprecated function under test
R. David Murray added the comment:
Hmm. This is very odd. The output from getstatus is the same as your ls
output, and that output passes the re. Python has its own regular expression
implementation, so your pcre version shouldn't have anything to do with it.
That complicated re, b
R. David Murray added the comment:
You are running selinux, right? Have you checked for things in the log that
might indicate selinux is blocking the ls call for some reason?
--
___
Python tracker
<http://bugs.python.org/issue11
R. David Murray added the comment:
I would say that coreutils is wrong to be appending a space. If a program were
to parse the output of ls, it would reasonably expect the filename to be
rendered exactly as it appears in the directory. That is, a program should
treat a trailing space as
R. David Murray added the comment:
By the way, I wouldn't expect most programs to ever notice that trailing space
parsing -l output, but if it also attaches the trailing space in regular ls
output, *that* I would expect more programs would trip
R. David Murray added the comment:
Oh, drat. We could have figured this out much sooner if I'd been paying closer
attention. I was testing based on current 2.7 tip instead of 2.7.1, and indeed
this test bug was only recently (April 4th!) fixed. And the issue is indeed
selinux; the fi
R. David Murray added the comment:
No, if you take a look at tip, the problem is that bit of re is not covering
all cases, and should look like this:
[.+@]? # It may have special attributes.
I assumed the "." was selinux, but I don't actually know, as I don't se
R. David Murray added the comment:
Did you try a make distclean/configure/make? _thread.info is a new attribute
introduced by a relatively recent patch.
--
___
Python tracker
<http://bugs.python.org/issue11
R. David Murray added the comment:
Sorry, didn't see that you'd figured it out in the midst of your other comments
not relevant to this bug.
If the re were simpler it wouldn't actually be *testing* the function under
test, and so would be a useless test. (It would show th
R. David Murray added the comment:
Just so you know, you aren't likely to get much help using this approach to bug
reporting. A single, focused bug report is much more likely to get attention.
You might also want to try starting with a "vanilla configure" and see how
thin
R. David Murray added the comment:
A focused bug report would focus on *one* of the test failures (as in the
failures from running a single test_x).
Python3 does not support Berkeley DB out of the box, you need a third party
library to get bdb support.
You might be interested to look at
R. David Murray added the comment:
The six error messages tell you that six different tests failed. Yes, the
failures are probably all due to the same cause, but that's just how unit
testing works. (And yes, the argparse tests are a bit more terse and difficult
to understand than ma
R. David Murray added the comment:
test_distutils should not be dependent on the existence of rpm (if it
references the system rpm it should skip if it doesn't exist).
It is difficult to find someone willing to run a buildbot as the root user, so
while we will see about fixing the test
Changes by R. David Murray :
--
nosy: +r.david.murray
___
Python tracker
<http://bugs.python.org/issue11959>
___
___
Python-bugs-list mailing list
Unsubscribe:
R. David Murray added the comment:
This change was made by Raymond in issue 5729. It is the only feature added by
that patch; the missing versionchanged was an oversight and I don't think it
makes any more likely that other features were added that weren't documented.
If you ar
R. David Murray added the comment:
The call to connect() is not required in the first example, since the hostname
is passed to the constructor in that case. Since these examples are about the
email package rather than smtplib, I preferred to change the other examples to
pass localhost to
R. David Murray added the comment:
The problem with this patch is that it would also show 'new mail' if what had
in fact happened was that a message had been *deleted* (see the comments at the
beginning of the flush method). So actually fixing this is a bit more
complicated.
A
R. David Murray added the comment:
Kasun, were you able to reproduce the problem (or show it doesn't happen)
calling mktime directly from C?
--
resolution: -> invalid
stage: -> committed/rejected
status: open -> pending
___
Python
R. David Murray added the comment:
The failing test is launching a subprocess to compile python code, waiting for
the subprocess to exit, and then checking to see if the file was created. So
the timing issue would appear to be that the file created by the subprocess
doesn't appear to
R. David Murray added the comment:
Thanks for catching that, and for the patch.
--
nosy: +r.david.murray
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
type: -> behavior
___
Python tracker
<http://
Changes by R. David Murray :
--
assignee: docs@python ->
nosy: +brian.curtin, tim.golden
___
Python tracker
<http://bugs.python.org/issue11834>
___
___
Python-
R. David Murray added the comment:
Running test_compileall with -F it failed on iteration 588 on my linux box. So
this isn't platform specific. No idea why that particular test should be
fragile, but I'll look in to it when I get some time if nobody beats me to it.
--
New submission from R. David Murray :
The following code:
class X(list):
def __contains__(self, key):
print('X contains:', key)
class Y():
def __init__(self, x):
self.x = x
def __getattr__(self, key):
retu
R. David Murray added the comment:
Well, then I suppose my question is why isn't __contains__ looked up? Other
special methods that don't exist on Y do cause __getattr__ to be called. Why
is __contains__ special? The docs for __getattr__ don't hint at this
possibility eithe
R. David Murray added the comment:
Ah, that's what my problem is. My test example was poorly conceived (I used
__del__!) so I *thought* the other special methods were triggering getattr.
I'd have figured it out if I hadn't screwed up my test :(
--
resolution: -
Changes by R. David Murray :
--
nosy: +r.david.murray
___
Python tracker
<http://bugs.python.org/issue11999>
___
___
Python-bugs-list mailing list
Unsubscribe:
R. David Murray added the comment:
Here is a patch that adds datetime support to email.utils.formatdate.
Ultimately the email package will give programs access to datetime+timezone
representations of the dates in various headers, so this provides the output
end of the round trip.
Alexander
R. David Murray added the comment:
Thanks everyone.
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
versions: +Python 3.3
___
Python tracker
<http://bugs.python.o
R. David Murray added the comment:
Not all system mail spools are mode 1777. Mutt needs to be setgid mail on
systems that aren't, if I understand correctly. Making a python program setgid
mail is a bit more of security issue than making a well-tested C program
setgid, since it is easi
R. David Murray added the comment:
Yes if you are a member of group mail you would not need setgid mail, obviously.
The problem report in question was submitted by one of the Debian maintainers,
so I have to believe that the system in question was not misconfigured. This
part of the
R. David Murray added the comment:
Steffen, your sense of humor is great, but oftentimes I have no clue what you
are talking about. Where does ftruncate factor in?
I was asking what mutt does when it modifies a file in the hopes that it had
some pithy algorithm for making sure the mailbox
R. David Murray added the comment:
I believe this is out of scope for Python itself, and is a platform
distribution issue. The platform must do some special magic to make those
things work; they don't in a vanilla python build as far as I know. You might
look to your readline configur
Changes by R. David Murray :
--
keywords: +easy
nosy: +r.david.murray
stage: -> test needed
type: crash -> behavior
___
Python tracker
<http://bugs.python.org/i
R. David Murray added the comment:
I ran the patched version 2945 times without failure.
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
type: -> behavior
___
Python tracker
<http://
R. David Murray added the comment:
Do you think we can get 9527 in? My patch was based on the non-existence of a
LocalTimezone facility in the stdlib.
Good point about the special interpretation of -. Given 9527 (and only
given 9527) it would indeed make sense to restrict email to
R. David Murray added the comment:
You are right that I got the regex wrong (I'm bad at regexes), but in fact it
is fine the way it is. Since there's no r, the regex is actually "ba[^/]$",
which is exactly what I meant.
--
__
R. David Murray added the comment:
"prepare new tail" means all of the text from the first modified line to the
end? (As opposed to "just the new mail"?)
mailbox does locking. I see no reason in principle it couldn't stat/restore,
it would just be setting the tim
R. David Murray added the comment:
Oh, and does mutt's behavior apply to any mbox, or only the one in the system
spool?
--
___
Python tracker
<http://bugs.python.org/is
R. David Murray added the comment:
LocalTimezone support would be *really* helpful for the email module. It would
allow us to have unambiguous semantics for datetime objects representing
timestamps exacted from or inserted into email messages (see issue 665194 for
recent discussion). The
R. David Murray added the comment:
Yes, since the package will save the original text anyway, I think just
clamping to 59 is best.
Hmm. Maybe instead I could put in an assert that says "please report this
incident to bugs.python.org so we can argue that datetime should get support
for
R. David Murray added the comment:
Well, it turns out that this sporadic failure is not a test bug, but a real bug
in the mailbox module that the test is revealing.
This issue is the same one that motivated the changes in issue 6896. Those
changes, however, merely reduced the problem, but
Changes by R. David Murray :
Removed file: http://bugs.python.org/file21904/mailbox_mtime.patch
___
Python tracker
<http://bugs.python.org/issue11999>
___
___
Python-bug
Changes by R. David Murray :
Added file: http://bugs.python.org/file21905/mailbox_mtime.patch
___
Python tracker
<http://bugs.python.org/issue11999>
___
___
Python-bug
R. David Murray added the comment:
Isn't this a bit out of scope for the mailbox module, though? Mailbox is
getting called at irregular intervals, and a clock monitor really wants to be a
polling daemon of some sort, I think. In which case a complete application
system that use
R. David Murray added the comment:
Oh, and to be clear: the problem wasn't that the one second interval was too
short, the problem was that the times stamps of the files were being compared
to the wrong check value (the system clock instead of their previous state).
The extra one
R. David Murray added the comment:
I am open to the argument that we should make it two seconds and a bit to
support FAT, but how many people are going to use maildir on FAT?
--
___
Python tracker
<http://bugs.python.org/issue11
R. David Murray added the comment:
All right, let's make it two seconds and a bit, then.
Why do you think a tenth of second is too small? A clock with a skew of half
that much would be badly broken.
--
___
Python tracker
<http://bugs.py
R. David Murray added the comment:
Hmm. That error message is more than a bit misleading. What you need to do is
add a flush method to your FlushFile class. Something changed between 3.1 and
3.2 that causes that message to be generated instead of suppressed. Not sure
what it was. The
R. David Murray added the comment:
Now we see if the buildbots agree with me that this is fixed.
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> pending
title: sporadic failure in test_mailbox on FreeBSD -> sporadic failure in
test_mailbox
type:
R. David Murray added the comment:
In 3.x, yes (the nonlocal keyword). Not in 2.7, though.
--
nosy: +r.david.murray
___
Python tracker
<http://bugs.python.org/issue12
Changes by R. David Murray :
--
nosy: +lukasz.langa
___
Python tracker
<http://bugs.python.org/issue12036>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from R. David Murray :
It doesn't matter which order test_os and test_ctypes run in, but if they
precede test_wait3 test_wait3 will fail. When the test is immediately re-run
it passes.
The reason ought to be interesting once we figure it out :)
Tested on linux. Do
R. David Murray added the comment:
Raymond: I haven't read the examples in detail so I don't have an opinion on
the appropriateness of the text, but I'm curious: while what you say certainly
applies to the Language Reference, does it also apply to the Tutorial?
R. David Murray added the comment:
Raymond: yes, thanks for the clear guidance. Perhaps it could be added to
Documenting Python, perhaps in the Style Guide chapter?
--
___
Python tracker
<http://bugs.python.org/issue11
R. David Murray added the comment:
Confirmed working on my box as well, and on my buildbot (where I first noticed
it).
--
___
Python tracker
<http://bugs.python.org/issue12
Changes by R. David Murray :
--
nosy: +r.david.murray
___
Python tracker
<http://bugs.python.org/issue8824>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from R. David Murray :
See
http://www.python.org/dev/buildbot/all/builders/x86%20Gentoo%203.2/builds/34/steps/test/logs/stdio
Antoine says that connect_ex should be returning an error, not None, in that
situation.
--
components: Tests
keywords: buildbot
messages
R. David Murray added the comment:
My usual pattern (adopted from examples in the stdlib tests) is this:
TestSomethingBase:
tests
PyTestSomething(TestSomethingBase, TestCase):
stuff
CTestSomething(TestSomethingBase, TestCase):
stuff
Is there a reason that won't work in
Changes by R. David Murray :
--
resolution: -> accepted
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
R. David Murray added the comment:
AFAIK build.sh is only as out of date as the svn/hg switchover. I believe this
particular issue was dealt with, but I haven't checked.
It runs the refcount tests for 2.7 (Antoine has a separate script that runs
them fo
R. David Murray added the comment:
Antoine removed that check as part of the -j support, if I recall correctly.
The check for unexpected output was part of the support for the transition
between the old pre-unittest test suite and the unittest based test suite, and
does seem like it is
R. David Murray added the comment:
Right, that's why I said "if it is a bug" :)
FreeBSD has the same behavior, so I'd actually prefer that Apple not "fix"
this. It would be nice if FreeBSD did and Apple adopted it, though, since only
dropping the % is t
Changes by R. David Murray :
--
keywords: +buildbot
nosy: +r.david.murray
___
Python tracker
<http://bugs.python.org/issue12096>
___
___
Python-bugs-list mailin
Changes by R. David Murray :
--
assignee: -> r.david.murray
stage: test needed -> patch review
___
Python tracker
<http://bugs.python.org/issue12009>
___
__
R. David Murray added the comment:
With these new additions, the test input is getting unwieldy. If you have the
time, I'd like to see the unit tests refactored to be more unit-testy. That
is, instead of a single test netrc file, have multiple inputs, one for each
thing being tested
R. David Murray added the comment:
Brett's been very busy with real life. Maybe someone else can commit this.
--
nosy: +r.david.murray
___
Python tracker
<http://bugs.python.org/is
R. David Murray added the comment:
Haypo, since you've created a new directory there are makefile (and PC build
file, I think) updates that will need to be made. (This should be documented
in the dev guide if it isn't already.)
--
nosy: +r.da
R. David Murray added the comment:
This is a long-standing design choice in the email package. If you want to
advocate for changing it, please join the email-sig mailing list (see
mail.python.org). We are in the process of developing a new version, which
will at least reject things like
R. David Murray added the comment:
See also #9921.
--
nosy: +r.david.murray
resolution: rejected -> duplicate
superseder: -> os.path.join('x','') behavior
___
Python tracker
<http
R. David Murray added the comment:
IMO 3.3 is definitely too soon. 3.4 may be too, depending on how many people
are stuck on legacy systems using 2.7.
--
nosy: +r.david.murray
___
Python tracker
<http://bugs.python.org/issue12
R. David Murray added the comment:
In fact, not fixing it might send a small message as to what we think about
that particular system default :)
--
nosy: +r.david.murray
___
Python tracker
<http://bugs.python.org/issue12
R. David Murray added the comment:
I agree with Amaury. IMO the IOError is the correct error, since it is
bubbling up unexpectedly (from zipfile's viewpoint) from a lower layer and is
not an error specific to the zip protocol implementation. (CF the discussion
surrounding PEP
R. David Murray added the comment:
2.7 is post-3.1. This works as you expect in 3.2. This is, it is a new
feature in both 2.7 and 3.2.
(NB: this is why I wanted 3.2 to come out close to 2.7, but fortunately this is
the first report like this I think we've gotten.)
--
R. David Murray added the comment:
"first part" by itself sounds like there can only be two parts. How about
'inserts a separator between each pair of...'
Also, what does 'absolute' mean on Windows? Does it include the drive? If so,
the second sentence
R. David Murray added the comment:
The argument against adding this to the pdb docs is that if you pull in that
statement from cmd, you really ought to pull in the full description of the
__init__ arguments. And whether you do that or just pull in that single
statement, you are duplicating
R. David Murray added the comment:
I doubt that close is ever called when removehandler is called. That doesn't
strike me as sensible semantics. I suspect that what is happening is that in
2.6 calling removehandler removed all references to the handler, and python's
garbage
R. David Murray added the comment:
Thanks for diagnosis and the test patch, and welcome to the bug weekend.
Some comments:
test.support has a symbol, TESTFN, which is guaranteed to be unique for the
test run and located in an appropriate writeable location. Many tests use it
to create a
R. David Murray added the comment:
There are currently no tests in argparse that test the content of error
messages, which is fairly standard for stdlib tests since the error messages
aren't considered part of the API (only the nature of the exception is). So
there's really no exi
R. David Murray added the comment:
Just as an FYI, a similar situation exists on Solaris. I had to fix one of the
Python test suite tests once because it was naively trying to rmtree the CWD.
--
nosy: +r.david.murray
___
Python tracker
<h
R. David Murray added the comment:
unsupported locale setting is a message that comes from the C runtime, IIUC.
Does it work on windows with 2.6?
--
nosy: +lemburg, r.david.murray
___
Python tracker
<http://bugs.python.org/issue10
Changes by R. David Murray :
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue10467>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by R. David Murray :
--
keywords: -easy
___
Python tracker
<http://bugs.python.org/issue5871>
___
___
Python-bugs-list mailing list
Unsubscribe:
1201 - 1300 of 10554 matches
Mail list logo
