Senthil Kumaran orsent...@gmail.com added the comment:
Interesting issue. RFC 2617 supports the claim. In RFC 2617, section
3.2.2 The Authorization Request Header, we see that nonce-count is
maintained for each particular nonce value and it can used by the server
to verify the replays.
The
Ezio Melotti ezio.melo...@gmail.com added the comment:
I'm not sure what the functions should do when start and end are
out of range.
I think the best approach would be to prevent these values to be out of
range in the first place.
All the args should be checked when the instance is created
Senthil Kumaran orsent...@gmail.com added the comment:
Fixed in r76288 (trunk), r76289 (release26-maint), r76290 (py3k) and
r76291(release31-maint). The issue is fixed. I am keeping it open to
remind of the pending tests (HTTPAuthDigest and nonce value check testcase).
--
resolution:
Nick Coghlan ncogh...@gmail.com added the comment:
2.7: r76286
3.2 merge is still a work in progress
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6816
___
Changes by Gabriel Genellina gagsl-...@yahoo.com.ar:
Removed file: http://bugs.python.org/file12774/mimetypes.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4969
___
Gabriel Genellina gagsl-...@yahoo.com.ar added the comment:
A new patch taking into account M. Pitrou comments:
- name changed to read_windows_registry()
- read_windows_registry() does nothing on non-Windows platforms; same
as read_mime_types(filename) when the file does not exist.
- I hope
Changes by Senthil Kumaran orsent...@gmail.com:
--
assignee: - orsenthil
nosy: +orsenthil
resolution: - accepted
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7291
___
Gabriel Genellina gagsl-...@yahoo.com.ar added the comment:
An updated version of the make_msgid patch.
Includes a random part plus a sequential part. Testing takes at most 3
seconds now (we're interested in those msgids generated in a whole
second)
--
Added file:
Changes by Gabriel Genellina gagsl-...@yahoo.com.ar:
Removed file: http://bugs.python.org/file14644/test_email.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6598
___
Changes by Gabriel Genellina gagsl-...@yahoo.com.ar:
Removed file: http://bugs.python.org/file14676/utils.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6598
___
Mark Dickinson dicki...@gmail.com added the comment:
The fix was applied to py3k in r76292, but I bodged the commit and
committed some extra (non-working) code by mistake. That was removed in
r76293, so all should be well now.
Merged to release31-maint in r76294.
trunk and the 2.6
New submission from Stefan Krah stefan-use...@bytereef.org:
This issue affects the format functions of float and decimal.
When calculating the padding necessary to reach the minimum width,
UTF-8 separators and decimal points are calculated by their byte
lengths. This can lead to printed
Gabriel Genellina gagsl-...@yahoo.com.ar added the comment:
An up-to-date patch; same contents, but this one can be cleanly
applied to trunk (as of r76294)
--
versions: +Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15340/subprocess.diff
Gabriel Genellina gagsl-...@yahoo.com.ar added the comment:
Document that warnings.catch_warnings is not thread safe.
--
keywords: +patch
Added file: http://bugs.python.org/file15341/warnings.diff
___
Python tracker rep...@bugs.python.org
Gabriel Genellina gagsl-...@yahoo.com.ar added the comment:
Documentation patch for BaseServer.server_forever() and shutdown()
--
keywords: +patch
Added file: http://bugs.python.org/file15342/socketserver.rst.diff
___
Python tracker
Mark Dickinson dicki...@gmail.com added the comment:
Backported the tests and some of the fixes to 2.x in r76295 (trunk) and
r76296 (release26-maint).
2.x seems to have been producing correct results in all cases on my
machine. The only problem on 2.x was that the code depended on signed
Thomas Courbon hart...@yahoo.fr added the comment:
*bump*
Hi there Pythoners !
As Timothy Farrell I'm currently working (or rather, toying since it
just for fun) on a Python3 web framework. I just started but when it
come to file upload I experience issues which I believe are connected to
that
Mark Dickinson dicki...@gmail.com added the comment:
Committed in r76300 (trunk) and r76301 (py3k). Thanks for all your help,
Stefan.
--
resolution: - fixed
stage: needs patch - committed/rejected
status: open - closed
___
Python tracker
Changes by Mark Dickinson dicki...@gmail.com:
--
priority: - low
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7261
___
___
Python-bugs-list
Mark Dickinson dicki...@gmail.com added the comment:
Committed to py3k in r76304. Leaving trunk alone, as Brett suggested.
--
resolution: - fixed
stage: commit review - committed/rejected
status: open - closed
___
Python tracker
Changes by Mark Dickinson dicki...@gmail.com:
--
priority: - normal
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7228
___
___
Python-bugs-list
Antoine Pitrou pit...@free.fr added the comment:
Thank you, the patch looks ok to me.
--
resolution: - accepted
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4969
___
Timothy Farrell tfarr...@swgen.com added the comment:
Perhaps this update should go in the linked email bug. The email team
has a goal of fixing the email module in time for the 3.2 release. I
also, feel as though I lack the skill to fix the email module, but it
goes beyond that since they're
Timothy Farrell tfarr...@swgen.com added the comment:
Just an update for people interested:
The email team has a goal of fixing the email module in time for the 3.2
release. There is the possibility of having to change some interfaces.
See this document:
Antoine Pitrou pit...@free.fr added the comment:
Committed in r76306 and r76307, closing.
--
resolution: accepted - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
Antoine Pitrou pit...@free.fr added the comment:
Giampaolo, do you plan to add something or is the patch ok to commit?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2054
___
Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com added the comment:
This issue is a duplicate of issue 7183.
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7326
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
resolution: - duplicate
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7326
___
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: -Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7326
___
Changes by Senthil Kumaran orsent...@gmail.com:
--
nosy: +pveloz
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7183
___
___
Python-bugs-list
New submission from Antoine Pitrou pit...@free.fr:
This works under 2.x but not 3.x:
$ ./python -m pydoc str
No module named subprocess
--
components: Library (Lib)
messages: 95297
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: pydoc doesn't work
Antoine Pitrou pit...@free.fr added the comment:
Same with an installed Python by the way:
$ usr/bin/python3 -m pydoc str
No module named subprocess
However, it works when not using -m but invoking the file directly:
$ ./python Lib/pydoc.py str
[displays the str doc page]
--
New submission from Ezio Melotti ezio.melo...@gmail.com:
Python currently accepts global statements at the top level:
global foo
Beside being a meaningless operation, this might lead unexperienced user
to make mistakes like:
foo = 5
global foo # make foo global
def func():
... print foo
Changes by Mark Dickinson dicki...@gmail.com:
--
priority: high - normal
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3944
___
___
Mark Dickinson dicki...@gmail.com added the comment:
The tanh-related failures are no longer happening, since the FreeBSD
buildbot was upgraded from FreeBSD 6.2 to FreeBSD 6.4.
I'm still worried by Skip's report, but that's a separate issue.
Closing.
--
resolution: - fixed
stage:
Giampaolo Rodola' billiej...@users.sourceforge.net added the comment:
If we want to add SSL support then the patch in attachment modifies the
last one as I described in my previous comment.
I re-run the tests and they are ok so I guess you can go on with the
commit.
--
Added file:
Mark Dickinson dicki...@gmail.com added the comment:
Added extra #ifdef HAVE_LONG_LONG as suggested.
Committed to trunk in r76308. I'm working on the merge to py3k, which
isn't entirely straightforward.
--
___
Python tracker rep...@bugs.python.org
Benjamin Peterson benja...@python.org added the comment:
Please bring this up on Python-dev if you'd like to change it. The fact
that there's a test verifying that this can happen suggests there is
some reason.
--
___
Python tracker
Antoine Pitrou pit...@free.fr added the comment:
The tests don't work under py3k, for some reason I can't figure out.
There's the following error and then the tests hang:
test_acct (test.test_ftplib.TestTLS_FTPClassMixin) ... Exception in
thread Thread-31:
Traceback (most recent call last):
Mark Dickinson dicki...@gmail.com added the comment:
Just so I don't lose it, here's the current version of the forward merge
of r76308 to py3k.
In testing this, I found some other possible bugs in the py3k
implementation of PyUnicode_FromFormat; I need to investigate and
possibly fix those
New submission from Mark Dickinson dicki...@gmail.com:
There seems to be something wrong with the width handling code in
PyUnicode_FromFormat; or perhaps I'm misusing it.
To reproduce: replace the line
return PyUnicode_FromFormat(range(%R, %R), r-start, r-stop);
in range_repr in
Brett Cannon br...@python.org added the comment:
It's a border case for backporting. The docs do say it should be returning
an absolute path, so that is a bug. And chances are anyone who has
discovered this and is working around it simply called os.path.abspath()
on the value instead of some
Antoine Pitrou pit...@free.fr added the comment:
I think we should be conservative. People may be relying on it *not*
returning an absolute path; besides, the bug itself wasn't a problem in
practice, so backporting the fix doesn't bring any added value.
--
nosy: +pitrou
Eric Smith e...@trueblade.com added the comment:
I agree there's not much value in making the attributes read/write, but
it looks like all of the exceptions allow it, so I don't really want to
make these exceptions the only ones that are different.
--
Eric Smith e...@trueblade.com added the comment:
It looks like PyUnicode_FromFormatV is computing callcount incorrectly.
It's looking for 'S', 'R', or 'A' immediately following '%', before the
width. It seems to me it should be treating them the same as 's',
although I'll admit to not having
R. David Murray rdmur...@bitdance.com added the comment:
The windows buildbots are reporting an odd error in test_runpy. I can't
see by visual inspection why the test is failing:
http://www.python.org/dev/buildbot/stable/builders/x86%20XP-4%20trunk/builds/2615/steps/test/logs/stdio
--
Antoine Pitrou pit...@free.fr added the comment:
The test is probably failing because the pattern is interpreted as a regex:
re.match(r'\t', r'\t') is None
True
There is another problem, which is that test_runpy (or runpy itself) is
now leaking references:
test_runpy
beginning 6 repetitions
Nick Coghlan ncogh...@gmail.com added the comment:
pydoc removes the scriptdir from sys.path. When run under -m, that
means it removes the standard library directory!
It works in 2.x because os.popen doesn't rely on subprocess there -
instead it comes direct from the builtin posix module.
Nick Coghlan ncogh...@gmail.com added the comment:
Fixed in r76312 and subsequent checkins (pydoc was corrupting sys.path
when run under -m and getting away with it in 2.x, but breaking os.popen
in 3.x)
--
___
Python tracker rep...@bugs.python.org
Changes by Nick Coghlan ncogh...@gmail.com:
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7328
___
Nick Coghlan ncogh...@gmail.com added the comment:
The windows errors are most likely due to the fact that I'm not doubling
the backslashes in the file paths before passing them to
assertRaisesRegex() as the regular expression pattern.
The reference leak is also interesting, since there isn't
Nick Coghlan ncogh...@gmail.com added the comment:
Hmm, definitely not the path importer cache - regrtest already takes
that into account by reverting it to its original state before checking
the reference counts.
--
___
Python tracker
David Bolen db3l@gmail.com added the comment:
Our last comments may have crossed, but as I mentioned in my last one,
yes, as best I can tell from my slaves (XP+VS-Express, XP+VS-Standard,
Win7+VS-Standard), the Visual Studio key is present in a brand new
install. Note that it is not present
Antoine Pitrou pit...@free.fr added the comment:
Not sure whether it's related, but there is now a sizeable refleak:
test_range
beginning 6 repetitions
123456
..
test_range leaked [150, 150, 150] references, sum=450
--
nosy: +pitrou
___
Python
R. David Murray rdmur...@bitdance.com added the comment:
It seems to me that all that patch does is re-enable the bug (in the
extension class context) that the patch for this issue was a workaround
for. I think perhaps the correct fix is to look at how the __doc__
attribute is found in the
Michael K Johnson a1237+pyb...@danlj.org added the comment:
The test case at the top of this issue reproduces just fine; if you are
looking for a different test case you'll have to specify what you don't
like about it so that it's clear what you are looking for.
I don't think there's any
Nick Coghlan ncogh...@gmail.com added the comment:
There's another cache in zipimport that wasn't being cleared when
hunting refleaks. I've updated that on the trunk and will include it in
the forward port to 3k (along with a fix for the Windows path separator
problem).
--
New submission from Nick Coghlan ncogh...@gmail.com:
I ran into a few gratuitous conflicts forward porting the command line
testing cleanup. This should be eliminated by making script_helper
sufficiently flexible to cover both the 2.x and 3.x use cases.
--
assignee: ncoghlan
components:
Nick Coghlan ncogh...@gmail.com added the comment:
Added to Py3k in r76324 (including the fixes made on 2.x after the
original checkin)
--
resolution: - accepted
status: open - closed
___
Python tracker rep...@bugs.python.org
Changes by Nick Coghlan ncogh...@gmail.com:
--
priority: normal - low
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7331
___
___
Python-bugs-list
Nick Coghlan ncogh...@gmail.com added the comment:
Lowering priority due to implementation of explicit syntax for multiple
context managers in a single with statement
--
priority: - low
___
Python tracker rep...@bugs.python.org
New submission from liang xfanli...@hotmail.com:
In our testbed,we have seem serveral sgement fault in our python scrit.
The enviroment is:
linux=2.6.29.6-0.6.smp.gcc4.1.x86_64
python=2.4.4-41.4-1
GCC = GCC 4.1.2 20070626 (rPath Inc.)] on linux2
Below are the detail call stack:
(gdb) bt
#0
62 matches
Mail list logo
