Ralf Schmitt added the comment:
I'm attaching a patch, which makes mmap.mmap the mmap class itself and
also makes it subclassable. It also contains changes to the documentation.
This is against revision 60148 of trunk.
--
nosy: +schmir
Added file:
Ralf Schmitt added the comment:
Ok, I've upped the limit to some very high value and tried to provoke a
stack overflow.
eval([*x+]*x) segfaults on my machine for x somewhere around 2
(linux, amd64). When setting MAXSTACK to 5000 eval([*x+]*x) works
for x = 333. So, I guess this should be
Georg Brandl added the comment:
Committed as r60149. Thanks for the patch!
--
resolution: - accepted
status: open - closed
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1269
__
Armin Rigo added the comment:
I don't see in general how the patch can be kept compatible with
extension modules that change the tp_dict of arbitrary types. All I can
think of is a way to be safe against extension modules that only change
the tp_dict of their own non-heap types (i.e. types
New submission from Ralf Schmitt:
The parser can handle nested structures only up to a certain limit.
The limit is currently reached around 33 deeply nested lists, which is a
bit too low.
This patch increases that limit by a factor of 10.
see http://bugs.python.org/issue21 for further
Georg Brandl added the comment:
IOW, this is rejected.
--
nosy: +georg.brandl
resolution: - rejected
status: open - closed
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1880
__
Changes by Ralf Schmitt:
--
versions: +Python 2.6
Added file: http://bugs.python.org/file9249/up-maxstack.txt
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1881
__
___
New submission from Jakub Wilk:
PEP 0263 allows an encoding declaration in the second line, but
py_compile seems not to recognize such ones:
MODULE = \n# encoding=UTF-8\nU = u'\xc3\xb3'\n
f = file('tmp.py', 'w')
f.write(MODULE)
f.close()
from py_compile import compile
compile('tmp.py',
Christian Heimes added the comment:
Mark Dickinson wrote:
So e.g. cos(infinity) should give a ValueError, while log(infinity) and
exp(infinity)
should not raise any Python exception, but should return an infinity instead.
And most
single variable operations should return an input NaN
Christian Heimes added the comment:
The mail interface screwed up the message:
math.atanh(.)
18.714973875118524
math.atanh(.9)
Traceback (most recent call last):
File stdin, line 1, in module
ValueError: math domain error
__
Christian Heimes added the comment:
Parser/parser.h was not in the list of dependencies. I fixed it in r60151
--
nosy: +tiran
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue21
Mikhail Zabaluev added the comment:
Wow, it's exciting to receive followups 6+ years after filing the bug.
Could you come up with a patch ?
No, I don't do much Python development these days.
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue460474
Vlado Handziski added the comment:
So what is the procedure for checking in the patch? I don't have a
commit access to the repository to do it myself...
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1754489
_
Marc-Andre Lemburg added the comment:
Sorry for not getting back to you earlier.
The ticket was unassigned and only assigned to me yesterday.
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue460474
A.M. Kuchling added the comment:
Closing as fixed, since the problem was reported as solved in 2.5alpha2
and it's unlikely anyone will make a 2.4.x bugfix release now.
--
nosy: +akuchling
resolution: - fixed
status: open - closed
_
Tracker [EMAIL
Georg Brandl added the comment:
Guido, is the 10-fold increase okay?
--
assignee: - gvanrossum
nosy: +georg.brandl, gvanrossum
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1881
__
A.M. Kuchling added the comment:
I don't see how win-win could be uninitialized. curses.newwin() creates
a PyCursesWindowObject using PyCursesWindow_New(), which always fills in
the -win field.
I'm puzzled by the 2007-06-28 traceback. Pycurses_new_panel has args =
0x000110246dc0; args
Changes by A.M. Kuchling:
--
assignee: - akuchling
nosy: +akuchling
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1723038
_
___
Python-bugs-list mailing list
Changes by A.M. Kuchling:
--
assignee: mwh - akuchling
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1119331
_
___
Python-bugs-list mailing list
Unsubscribe:
Changes by A.M. Kuchling:
--
assignee: - akuchling
nosy: +akuchling
title: cannot catch KeyboardInterrupt when using curses getkey() - cannot
catch KeyboardInterrupt when using curses getkey()
_
Tracker [EMAIL PROTECTED]
Christian Heimes added the comment:
I've added your complex patch and its tests to my patch. The tests are
showing some flaws in the atanh (or log1p) function on Windows:
AssertionError: atanh0022:atanh(-1.00) returned -18.36840028483855,
expected -18.714973875118524
On Linux the tests are
Changes by A.M. Kuchling:
--
keywords: +easy
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1470548
_
___
Python-bugs-list mailing list
Unsubscribe:
Christian Heimes added the comment:
10-fold is very progressive. Let's be a bit more conservative for
platforms with a small stack size (e.g. *BSD and mobile phones). A
parser stack limit of about 1500 would still allow roughly 100 deeply
nested lists.
--
nosy: +tiran
priority: -
Georg Brandl added the comment:
Reviewed and committed in r60152.
--
nosy: +georg.brandl
resolution: - accepted
status: open - closed
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1087741
_
Ralf Schmitt added the comment:
Many thanks for handling it immediately.
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1087741
_
___
Python-bugs-list mailing list
Christian Heimes added the comment:
It's most probably the fault of log1p():
AssertionError: atanh0022:atanh(-0.99989) returned
-18.36840028483855, expected -18.714973875118524
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1640
Mark Dickinson added the comment:
Christian: I'm definitely not proposing atanh(1) = inf: it should raise
ValueError. I'm proposing that we follow Tim's rules for now; this means no
change for finite inputs.
The new thing here is that since you've made inf and nan more accessible and
Changes by Georg Brandl:
--
priority: - urgent
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1878
__
___
Python-bugs-list mailing list
Unsubscribe:
Raghuram Devarakonda added the comment:
If rmtree() always returns in case of symbolic links (as it is
checked-in), wouldn't it be much simpler to totally do away with
'onerror' handling? I thought 'onerror' gives the user the option how to
proceed (which is true in other usages).
Mark Dickinson added the comment:
Christian: would it be possible for you to tell me what the argument of the
log1p call is on Windows in that last branch of c_atanh, for the testcase
atanh0022.
On OS X I get:
Input to log1p is 3.2451855365842669075e+32
It's hard to imagine that there's
Mark Dickinson added the comment:
Okay: here's an attempted guess at what's happening on Windows:
Near the end of c_atanh, there's a line that reads:
r.real = log1p(4.*z.real/((1-z.real)*(1-z.real) + ay*ay))/4.;
Somehow, when z.real is 0.99989 and ay is 0, the argument to log1p
Changes by Raghuram Devarakonda:
--
components: +Documentation -Library (Lib)
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1577
__
___
Python-bugs-list mailing list
Mark Dickinson added the comment:
Sorry: those lines should have been:
double temp = 1-z.real;
printf(temp is %.19e\n, temp);
r.real = log1p(4.*z.real/(temp*temp + ay*ay))/4.;
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1640
Mark Dickinson added the comment:
This is a duplicate of issue #1742669
--
nosy: +marketdickinson
resolution: - duplicate
status: open - closed
superseder: - %d format handling for long values
_
Tracker [EMAIL PROTECTED]
Georg Brandl added the comment:
The patch only amends TextDoc -- what about HtmlDoc?
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1715
__
___
Python-bugs-list mailing list
Georg Brandl added the comment:
Okay, I'll remove the docs again. If you want to deprecate
bundlebuilder, it must be added to PEP 4.
--
resolution: - fixed
status: open - closed
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue779825
Georg Brandl added the comment:
Fixed in r60158.
--
resolution: - fixed
status: open - closed
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue997912
___
Christian Heimes added the comment:
Mark Dickinson wrote:
Mark Dickinson added the comment:
Christian: would it be possible for you to tell me what the argument of the
log1p call is on Windows in that last branch of c_atanh, for the testcase
atanh0022.
On OS X I get:
Input to log1p
Georg Brandl added the comment:
Guido explicitly said it should raise IOError, not ValueError,
and it should use the onerror() handling used for all other errors
which makes sense for me too.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1669
Georg Brandl added the comment:
We can of course add something like in #1229239, which allows type
attributes to be set with PyObject_SetAttr, thereby updating the cache.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1878
Georg Brandl added the comment:
plistlib is now documented. I also added a stub for bundlebuilder that
only has the module docstring as an overview -- Ronald, if you want to
write more about that?
--
assignee: - ronaldoussoren
nosy: +georg.brandl
Georg Brandl added the comment:
I added documentation and moved plistlib to the general library in r60155.
Ronald, if you want to enhance the documentation, please go ahead :)
--
resolution: - fixed
status: open - closed
_
Tracker [EMAIL PROTECTED]
Changes by Georg Brandl:
--
assignee: aleax - marketdickinson
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1678380
_
___
Python-bugs-list mailing list
Christian Heimes added the comment:
Georg Brandl wrote:
So what's the resolution here?
We don't have a resolution yet. I may need the WINVER for the patch
#1763 but I've to investigate the patch before I can submit it.
Christian
__
Tracker [EMAIL PROTECTED]
New submission from Georg Brandl:
so that this doesn't get lost...
--
assignee: georg.brandl
components: Library (Lib)
messages: 61418
nosy: georg.brandl
severity: normal
status: open
title: Adapt pydoc to new doc system
versions: Python 2.6, Python 3.0
Mark Dickinson added the comment:
Sorry: I should have read more carefully. So math.atanh works on Linux
but is producing some strange results on Windows.
It's still rather puzzling though. I still suspect that it's the
argument to log1p that's coming out wrong rather than the result.
Christian Heimes added the comment:
Please update Misc/NEWS for the bug fix. You forgot to update it for
this and another logging fix a week ago.
--
nosy: +tiran
status: closed - pending
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1836
Georg Brandl added the comment:
Where exactly is that broken link?
--
nosy: +georg.brandl
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1621660
_
___
Georg Brandl added the comment:
I also left out the changes to the ftplib and distutils functions since
they also accept file objects as parameters, to keep b/w compatibility.
Committed the rest as r60163.
--
assignee: - georg.brandl
nosy: +georg.brandl
resolution: - accepted
status:
Christian Heimes added the comment:
Mark Dickinson wrote:
Sorry: I should have read more carefully. So math.atanh works on Linux
but is producing some strange results on Windows.
It's still rather puzzling though. I still suspect that it's the
argument to log1p that's coming out wrong
Georg Brandl added the comment:
Clarified in r60164.
--
assignee: effbot - georg.brandl
resolution: - fixed
status: open - closed
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1631394
_
Georg Brandl added the comment:
This is a dupe of #1254695.
--
resolution: - duplicate
status: open - closed
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1570672
_
Georg Brandl added the comment:
Now that we have a (different) rational module in the stdlib, shouldn't
we remove this one altogether?
--
assignee: - jyasskin
nosy: +georg.brandl, jyasskin
_
Tracker [EMAIL PROTECTED]
Georg Brandl added the comment:
Committed as r60166.
--
nosy: +georg.brandl
resolution: - accepted
status: open - closed
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1530959
_
Raghuram Devarakonda added the comment:
and it should use the onerror() handling used for all other errors
which makes sense for me too.
Sure. I am ok with using 'onerror'. The point I am trying to make is
that there is slight difference between 'onerror' in this case and in
the three other
Georg Brandl added the comment:
Rejecting as per discussion.
--
nosy: +georg.brandl
resolution: - rejected
status: open - closed
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1678345
_
Vinay Sajip added the comment:
I've updated the docs (Formatter.format) to mention the caching and its
effect on multiple formatters.
--
nosy: +vsajip
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1295
__
Changes by Christian Heimes:
Removed file: http://bugs.python.org/file8989/trunk_math_sign_inf_nan.patch
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1640
__
___
Changes by Christian Heimes:
Removed file: http://bugs.python.org/file8975/trunk_mathmodule.patch
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1640
__
___
Python-bugs-list
Changes by Christian Heimes:
Removed file:
http://bugs.python.org/file9250/trunk_pymath_hyberbolic_complex.patch
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1640
__
___
Changes by Christian Heimes:
Removed file: http://bugs.python.org/file9243/trunk_pymath_hyberbolic.patch
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1640
__
___
Changes by Guido van Rossum:
--
nosy: -gvanrossum
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1640
__
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
I don't know what common stack sizes are any more. Even on the same
platform, the main thread may have a different stack size than other
threads.
Would it make sense to make this limit more platform-dependent?
I guess really good would be a way to handle
Changes by Vinay Sajip:
--
status: pending - closed
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1836
__
___
Python-bugs-list mailing list
Unsubscribe:
Georg Brandl added the comment:
Thanks for the report, fixed in r60168, r60169 (2.5).
--
nosy: +georg.brandl
resolution: - fixed
status: open - closed
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1882
__
Georg Brandl added the comment:
Raising priority.
--
components: +Library (Lib) -None
nosy: +georg.brandl
priority: normal - high
type: - behavior
versions: +Python 2.6, Python 3.0
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1750076
Eric Sammons added the comment:
Has anybody else tested this against an RPC server that has more than
300 items to be returned. I find it interesting that before all the
xmlrpc code changed everything works fine, but after the code change
(re-write) things don't seem to work.
As for the bug, I
Eric Sammons added the comment:
I have added the verbose=1 option, the processing hangs in the body: where :
code
for a in l:
print a['channel_label']
/code
Is returning the data. Initially it returns data quickly and then slows
until it eventually stops.
Here is the sample of the body
New submission from Jim Wilson:
I believe Codepage (a summary property which must be set *before* any
other string value), is a string. Documentation admits it might also be
an integer, but it doesn't matter. Both foo.SetProperty(PID_CODEPAGE,
'1252') and foo.SetProperty(PID_CODEPAGE, 1252)
Mark Dickinson added the comment:
The problem with atanh is that it should be using absx throughout, rather than
x.
So in if (absx 0.5) branch and the following branch, replace all
occurrences of x with
absx, and it should work.
One other comment: asinh shouldn't directly set errno for a
Mark Dickinson added the comment:
Also, for the C-level routines, atanh(1.0) and atanh(-1.0) should definitely
return
infinity and -infinity (and probably set errno as well.)
Note that this is not an argument about what Python should do: Python will
still raise a
ValueError for atanh(1.0)
Mark Dickinson added the comment:
One more comment: the Py_IS_NAN test in acosh is likely never reached, since
the
comparison x = two_pow_p28 will probably evaluate to 0 when x is a NaN.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1640
Mark Dickinson added the comment:
Also: -1.0 shouldn't be returned at this level to indicate an error; these
are pure C functions
we're writing---the Python wrappers, and Python error conventions, apply
further up the chain
somewhere.
Just so I'm doing something a little more constructive
New submission from Giampaolo Rodola':
Steps to reproduce the problem:
1: Run python setup.py sdist --formats=gztar,tar.
2. dist directory now contains module.gztar and module.tar files
as expected.
3: Run python setup.py sdist --formats=tar,gztar.
4. dist directory now contains only
Antoine Pitrou added the comment:
Actually, HtmlDoc already lists all module members in the inspected
module (regardless of whether they are modules imported from outside or
submodules defined inline). You can try it with the updated pydocfodder:
import pydoc
from test import pydocfodder
Paul Pogonyshev added the comment:
I personally think that this bug is a showstopper for the caching patch
in 2.6. Well, the problem can be deemed insignificant, but it is sure a
break of backward compatibility and, worse yet, it results in _very_
obscure fails. Even if type dictionary changes
Martin v. Löwis added the comment:
I can't see anything wrong with the feature. Of course, the patch itself
lacks changes to the test suite.
Ideally, there would also be changes to the documentation, but as
PyMemberDef seems to be undocumented currently, it's unfair to ask for
documentation
Georg Brandl added the comment:
Well, I believe you. :)
Committed r60178.
--
resolution: - accepted
status: open - closed
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1715
__
Georg Brandl added the comment:
Okay, added tests, removed the cast and committed in r60181. If I find
time, I'll add docs for PyMemberDef in the next few days.
--
resolution: - accepted
status: open - closed
_
Tracker [EMAIL PROTECTED]
New submission from Giampaolo Rodola':
Currently creating tar, gztar, bztar source distributions using the
--formats=tar,gztar,bztar distutils option requires external utilities
(tar and possibly one of gzip, bzip2, or compress) to be installed on
the system since distutils uses them.
This is
Giampaolo Rodola' added the comment:
I provided a patch here: http://bugs.python.org/issue1886
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1885
__
___
Python-bugs-list
Changes by Raghuram Devarakonda:
--
nosy: -draghuram
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1706039
_
___
Python-bugs-list mailing list
Unsubscribe:
Phillip J. Eby added the comment:
On systems where the gzip or bz2 modules aren't installed, this patch
can raise a tarfile.CompressionError, which should be caught and handled
correctly. The import of tarfile should also be inside the relevant
function (as is done for make_zipfile) instead of
Mark Dickinson added the comment:
This was fixed in the trunk in revision 57284. I've backported the fix to
Python 2.5.2 in revision
60183.
Leaving this open because there's still a problem for complex numbers, though I
guess this is less
likely to bite people:
Python 2.6a0 (trunk:60158M,
Raghuram Devarakonda added the comment:
I started looking at the bugs in chronological order in the hope that I
can close some issues that don't make sense any more. Can I close this
one? I am almost sure that this module is not going to be included in
stdlib (I myself haven't used this module,
Georg Brandl added the comment:
Go ahead.
--
nosy: +georg.brandl
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue479195
___
Python-bugs-list mailing list
Raghuram Devarakonda added the comment:
Closing as there is no activity for long time and the request is
unlikely to be accepted, anyway.
--
resolution: - rejected
status: open - closed
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue479195
Santiago Gala added the comment:
El sáb, 19-01-2008 a las 20:44 +, Georg Brandl escribió:
Georg Brandl added the comment:
Fixed in r60100.
If the problem with the output of filter is solved at the call site I'd
suggest the second hunk of:
$ svn diff Lib/pydoc.py
Index: Lib/pydoc.py
Raghuram Devarakonda added the comment:
should have been closed long time back :-).
--
nosy: +draghuram
resolution: - rejected
status: open - closed
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue491331
Antoine Pitrou added the comment:
I'm not sure about the implications of Amaury's proposal, but in any
case here is a patch which contains an unit test as well.
(it seems to me swapping __stop() and __delete() can do no harm as there
is no way for user code to be executed synchronously between
Georg Brandl added the comment:
Guido, you wrote that code...
--
assignee: rhettinger - gvanrossum
nosy: +georg.brandl, gvanrossum
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1703448
_
Mark Dickinson added the comment:
Here's a patch, against the trunk, that imitates Alex's fix for the complex
case.
--
keywords: +patch
Added file: http://bugs.python.org/file9255/plus_minus_0j.patch
_
Tracker [EMAIL PROTECTED]
Amaury Forgeot d'Arc added the comment:
Hm, this is multithreading. There is still the possibility of a switch
between the two calls. In this case the thread is not marked as stopped,
but enumerate() does not return it. Not easy to reproduce, though.
_
Mark Dickinson added the comment:
This can be closed, I think: it's already been fixed in the trunk (with a
different
fix, also due to Alex, from the one given here) and the fix has been backported
to
2.5.2.
Not sure what the appropriate resolution is here; plumping for 'out of date'.
Antoine Pitrou added the comment:
There is still the possibility of a switch
between the two calls. In this case the thread is not marked as stopped,
but enumerate() does not return it.
But user code is unlikely to rely on this because in most cases the
thread *will* be marked as stopped ;)
Antoine Pitrou added the comment:
Oops, sorry Amaury, I got your remark backwards. Nevermind...
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1703448
_
___
Gregory P. Smith added the comment:
why not just do this?
finally:
with _active_limbo_lock:
self.__stop()
try:
self.__delete()
except:
pass
(i believe with works on locks? if not turn that into an acquire, try:
Changes by Gregory P. Smith:
--
assignee: - gregory.p.smith
nosy: +gregory.p.smith
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1221598
_
___
Python-bugs-list
Antoine Pitrou added the comment:
__delete() already acquires _active_limbo_lock so your proposal must be
changed for the following:
with _active_limbo_lock:
self.__stop()
try:
del _active[_get_ident()]
except:
Changes by Antoine Pitrou:
Added file: http://bugs.python.org/file9256/thrbug2.patch
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1703448
_
___
Python-bugs-list
1 - 100 of 118 matches
Mail list logo