Mark Hammond added the comment:
Can anyone point me at a test that failed in this case? A quick look
over winsig.c shows no asserts. I didn't compare the vs2005 crt source
though, so its highly likely I just missed it...
On the broader point, it could be argued that if it is the
Mark Dickinson added the comment:
I assume you're referring to Dec_0 and friends?
Fixed in the trunk in r68182. Leaving open until I get the chance to
merge it to the other branches.
--
resolution: -> fixed
versions: -Python 2.7
__
Mark Dickinson added the comment:
Fine. Will re-rename in the morning. Are _Inf, _negInf, _NaN and
_Infsign okay as they are?
___
Python tracker
<http://bugs.python.org/issue4
Mark Dickinson added the comment:
Instead of the repeated divisions and Inexact tests, how about a direct
approach: n/2**k = (n*5**k)/10**k, so something like:
sign = 0 if copysign(1.0, self) == 1.0 else 1
n, d = abs(self).as_integer_ratio()
k = d.bit_length() - 1
return
Mark Dickinson added the comment:
A couple more things:
1. There's a typo 'equilvalent' in the decimal.py part of the patch.
2. Can I suggest using
return d._fix(self)
instead of
return self.plus(d)
in create_decimal_from_float. The plus method does two things: rounds
Mark Dickinson added the comment:
Done (r68191 through r68194).
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue4812>
___
___
Python-
Mark Dickinson added the comment:
I agree that the proposed behaviour seems more correct: the collection of
all subsets of size 4 of range(3) is perfectly valid and well-defined; it
just happens to be empty. I've also encountered this in practice (in code
that was enumerating parti
Mark Dickinson added the comment:
[Georg Brandl, on spark.py]
> This is used by asdl_c.py which generates Python-ast.c -- it should be
> updated.
The only issue here is a single comment, which reads:
# GenericASTMatcher. AST nodes must have "__getitem__" and "__cmp__&q
New submission from Mark Dickinson :
Misc/cheatsheet could do with an upgrade, both for the 2.x and 3.x branches.
For 3.x, I guess the changes needed are quite extensive. I'm not sure
how much needs to be changed or added for 2.x; at a quick
glance, the 'with' statement, the
Mark Dickinson added the comment:
autoconf checks for isinf and isnan fixed in r68299.
I also added a check for isfinite, which should really be used in
preference to finite: isfinite is standard in C99, while finite doesn't
seem to be part of any sta
Mark Dickinson added the comment:
Is this the same issue as issue 4388?
--
nosy: +marketdickinson
___
Python tracker
<http://bugs.python.org/issue4824>
___
___
Mark Dickinson added the comment:
Raymond,
Do you think it would be worth replacing the two uses of
conditional expressions in Decimal.from_float with if-else
statements?
Alex Goretoy pointed out (on c.l.p) that the trunk version of
decimal.py can no longer be imported into Python 2.4 (and
Mark Dickinson added the comment:
Looking at this again, I don't like my solution.
I think it would be better to fix Py_IS_INFINITY directly, putting all the
complication into one place; then users of Py_IS_INFINITY don't have to
spend time worrying about whether they should
Mark Dickinson added the comment:
Tim, I'm in need of some advice on Py_IS_INFINITY. It's currently
implemented (on platforms that don't provide isinf) as
#define Py_IS_INFINITY(X) ((X) && (X)*0.5 == (X))
I'd like to rewrite it as something like:
#define Py_IS_I
Mark Dickinson added the comment:
s/false positives/false negatives/
___
Python tracker
<http://bugs.python.org/issue4575>
___
___
Python-bugs-list mailing list
Unsub
Mark Dickinson added the comment:
Answering my own question, there *are* pitfalls: (X) > DBL_LONG_MAX will
evaluate to true for some finite extended precision values that are *just*
larger than DBL_LONG_MAX, but nevertheless round to DBL_LONG_MAX rather
than infinity.
Another not-so-bri
Mark Dickinson added the comment:
This patch currently causes test_pickle to fail (and test_random, but that
failure is also pickle related). Am investigating.
___
Python tracker
<http://bugs.python.org/issue4
Mark Dickinson added the comment:
I'm seeing this too on OS X, with Python 2.6.
Python 2.6.1+ (release26-maint:68182M, Jan 2 2009, 23:13:43)
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
Type "help", "copyright", "credits" or "license&q
Mark Dickinson added the comment:
Here's the issue with pickle: with this patch, the pickle of a long using
pickle protocol 0 under 2.x can't be read by Python 3.x, because (1) the
pickled long includes a trailing L, and (2) unpickling goes via a call to
PyLong_FromString.
Mark Dickinson added the comment:
The problem comes down to the platform strtod: on some systems,
strtod sets errno to ERANGE on underflow. The load_float function in
Modules/cPickle.c calls PyOS_ascii_strtod and then raises ValueError
if that call sets errno.
I suggest replacing the call to
Mark Dickinson added the comment:
Change title; this has nothing to do with 64 bit.
--
title: cPickle can pickle, but cannot unpickle on 64bit machines -> cPickle
cannot unpickle subnormal floats on some machines
___
Python tracker
&l
New submission from Mark Dickinson :
int('3L') is still valid in Python 3.x. Presumably this is unintentional.
Is there any possibility of changing this for 3.0.1 or 3.1?
--
components: Interpreter Core
messages: 79121
nosy: marketdickinson
severity: normal
status: open
Mark Dickinson added the comment:
Here's a patch.
--
keywords: +patch
Added file: http://bugs.python.org/file12592/issue4842.patch
___
Python tracker
<http://bugs.python.org/i
Mark Dickinson added the comment:
I guess that makes this a release blocker for 3.0.1, then.
Here's a second patch, complementary to the first, that fixes pickling of
longs so that pickle protocol 0 in Python 3.0.1 and later behaves
identically to pickle protocol 0 in Python 2.x. N
Mark Miller added the comment:
It's actually due to the merge of the libffi3 branch back in March,
which removed the logic for configure to deal with MIPS in
fficonfig.py.in. I've attached a patch which allows the build to work
correctly on the QEMU instance of the MIPSEL mach
Mark Miller added the comment:
Adding this as affecting the 2.6 branch as well, since I initially
tested on a 2.6.1 tarball with this problem.
--
versions: +Python 2.6
___
Python tracker
<http://bugs.python.org/issue4
Mark Dickinson added the comment:
[Mark]
> inputs with a special real or imaginary component. On balance, I'd
> support making complex('nan + nan*j') do the right thing.
Having thought about this a bit more, I take this back. Some reasons are
given below.
[Da
Mark Dickinson added the comment:
Christian, any comments? Is it okay to close this as a 'won't fix'?
___
Python tracker
<http://bugs.python.org/issue2121>
___
__
Mark Dickinson added the comment:
As Christian says, it's about not increasing code complexity without a
good reason. For me, it's also about mental complexity: the set of valid
inputs to the complex constructor should be small, and should be easy to
understand and to desc
Mark Dickinson added the comment:
An exponential distribution with parameter 0 isn't an exponential distribution
any more. On the real line, there isn't
even a limiting distribution as the parameter approaches 0.
Is there really any use for having expovariate degenerate this way
Mark Dickinson added the comment:
I would suggest adding a note to the documentation stating clearly that
the parameter should be nonzero. The documentation is also unclear on
whether a negative parameter value is permitted, although the current code
works exactly the way that I'd e
Mark Dickinson added the comment:
> to allow lambda=0 is sometimes useful in simulations, meaning that it's
> infinite time to the next event, i.e. it never occurs.
Thanks; that makes sense. If 1./0. returned inf then expovariate would
already do what you want. But rightly
Mark Dickinson added the comment:
Doc fixes in r68378. Closing.
--
resolution: -> rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Mark Dickinson added the comment:
> 5. This one bugs me a bit. It is nice to have all the factorial
> formulas just work and not have a piecewise definition.
IIRC, in the 'Concrete Mathematics' book, Knuth and co use something
like
(n choose k) = (n-to-the-k-falling)/k!
to
Mark Dickinson added the comment:
Results from Magma, Sage and Gap:
Magma provides functions "Subsets(S, k)" and "Permutations(S, k)". From
the documentation:
Subsets(S, k) : The set of subsets of the set S of size k. If k is
larger than the cardinality of S then the
Mark Dickinson added the comment:
Got Sage working again. It also returns an empty list for r > n. For r
negative, Combinations returns an empty list and Permutation gives an
error.
sage: Combinations(range(4), 6)
Combinations of [0, 1, 2, 3] of length 6
sage: Combinations(range(4)
Mark Dickinson added the comment:
Interesting. How many of those casts are actually necessary to make
things work? Have you figured out more precisely why this is failing?
E.g., is it somehow that LONG_MIN ends up being an unsigned constant?
It seems to me that a better fix would be to fix
Changes by mark pennock :
--
components: None
nosy: markpennock
severity: normal
status: open
title: Can't Locate File with No Capital in Name
versions: Python 2.5
___
Python tracker
<http://bugs.python.org/i
New submission from mark pennock :
error reading files in python 2.5
reports files don't exist under certain conditions
*Doesn't Work Code*
f = open("D:\test.html", "r").read()
*Does Work Code*
(Change file name and retry)
f = open("D:\Test.html", &
mark pennock added the comment:
Your right! Thanks a lot, I am obviously a newbie.
___
Python tracker
<http://bugs.python.org/issue4900>
___
___
Python-bugs-list m
Mark Hammond added the comment:
Early windows CE devices were very crippled, and IIRC, only the Unicode
version of the API existed, and (also IIRC) this was well before Python
had builtin unicode. I agree with Martin; it is probably worth
investigating how much effort it is to get thread_nt.h
Mark Dickinson added the comment:
(Adding Raymond to the nosy list.)
In r68494, I've checked in some work towards rewriting Decimal (or parts
of Decimal) in C. I reused Facundo's old /decimal directory in the
sandbox, so the URL is:
http://svn.python.org/view/sandbox/tru
Mark Dickinson added the comment:
Changing title and assignee. (But all help is appreciated: if anyone
wants to commit changes to the sandbox directory, please go ahead!)
___
Python tracker
<http://bugs.python.org/issue2
Changes by Mark Dickinson :
--
assignee: facundobatista -> marketdickinson
title: Decimal slowdown in 3.0 due to str/unicode changes -> Recode (parts of)
decimal module in C
___
Python tracker
<http://bugs.python.org/
Mark Dickinson added the comment:
> (2) Bring proposals to add a decimal literal to C ...
That should be "to Python", not "to C", of course.
___
Python tracker
<http:/
New submission from Mark Dickinson :
In Python 3.x:
>>> int.__long__.__doc__
'x.__long__() <==> long(x)'
But the long builtin no longer exists.
I'm actually not sure why the nb_long slot still exists in 3.x at all.
Can anyone enlighten me?
--
message
Mark Dickinson added the comment:
I agree the PEP should be updated. Your proposed update looks good to me.
___
Python tracker
<http://bugs.python.org/issue4796>
___
___
Mark Dickinson added the comment:
long(x) replaced by int(x) in r68508.
I'm still wondering about the nb_long slot, though.
--
title: help(int.__long__) refers to nonexistent long function -> Should both
nb_long and nb_int still exis
Mark Sapiro added the comment:
This problem also occurs when building the 2.6.1 parser module on Cygwin
1.5.25. It did not occur with Python 2.6 or 2.5.x.
The error from 'make' is
building 'parser' extension
gcc -shared -Wl,--enable-auto-image-base
build/temp.cygwin-1.5.25
Changes by Mark Sapiro :
--
nosy: +msapiro
___
Python tracker
<http://bugs.python.org/issue4288>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Sapiro added the comment:
Thank you for adding the redirects, and for getting them right in spite
of my garbling some of them in the original report.
I have updated the links for the next Mailman release.
___
Python tracker
<http://bugs.python.
Mark Dickinson added the comment:
I'm not sure that this is desirable behaviour. There's no such thing as a
complex literal---only imaginary literals. Why allow evaluation of 2+1j
but not of 2 + 1, or 2*1j.
In any case, I'm not sure that the patch behaves as intended
Mark Dickinson added the comment:
Here's a patch against the py3k branch that gets rid of the two existing
uses of nb_long in the core:
- in PyNumber_Long, conversion was attempted first using nb_int and
then using nb_long. The patch simply removes the nb_long code, so
int(
Mark Dickinson added the comment:
That was a pretty poor patch. Here's a better one:
- added Misc/NEWS entry
- added tests to check that __long__ is never called
- removed Modules/_struct.c change, in the interests of
keeping the patch focused.
Added file: http://bugs.pytho
Mark Dickinson added the comment:
Guess that makes this a bit of a wasted effort on my part, then. Darn.
> a substantial portion of the module should be coded in C and
> needs to function independently of Python, with accessors provided to
> for Python to wrap around.
I'm cur
Mark Dickinson added the comment:
BTW, both those "I'm not sure"s should be taken literally: I'm not a user
of the ast module, I don't know who the typical users are, and I don't
know what the typical uses for the literal_eval function are. The patch
just stru
Mark Dickinson added the comment:
Nice fix!
Exactly which complex strings should be accepted here?
The patched version of literal-eval still accepts some
things that would be rejected as inputs to complex():
>>> ast.literal_eval('-1+-3j')
(-1-3j)
>>> complex(
Mark Dickinson added the comment:
So why accept (4+2j) but not (2j+4)?
(BTW, I'm fairly sure that the complex constructor does
accept parentheses; you're right about the whitespace, though.)
___
Python tracker
<http://bugs.python.
Mark Dickinson added the comment:
> If you say that
> literal_eval can safely evaluate the repr() of builtins
Sorry, yes, that makes perfect sense. (And now I see that that's what
distinguishes 4+2j from 2j+4---finally the light dawns.) Apologies for
b
Mark Dickinson added the comment:
What's the purpose of old_i? It looks like it's never used for anything.
Other than than, the patch looks good to me.
I'd guess that the "if (i < 0)" was simply optimized away. This isn't
necessarily a compiler bug: if
Mark Dickinson added the comment:
Actually, what's the purpose of old_j? It looks like that's not needed
any more, either!
___
Python tracker
<http://bugs.python.
Mark Hammond added the comment:
Martin,
Would you be happier if this functionality was exposed via _msvcrt and
disabled in the test suite (either globally or selectively)? Obviously
this is still not thread-safe, but it is closer towards putting this
behaviour in the control of the app
Mark Dickinson added the comment:
Looks fine; I think this should be applied.
It seems as though your reindentation left trailing whitespace on
the blank lines in the function: the svn commit hook might
complain about this...
--
resolution: -> accep
Mark Dickinson added the comment:
Hmm. I take it back: this *does* appear to be OS X specific.
I've attached a small (17-line) example that fails with
the Errno 57 error on OS X, but passes on the Linux machines I tested.
In this example, it appears that when 'conn.close()' i
Mark Dickinson added the comment:
Found a better (one-line) fix. Fixed in the trunk in r68611.
Will port to 2.6, 3.0, 3.1.
--
resolution: -> fixed
versions: -Python 2.7
___
Python tracker
<http://bugs.python.org/iss
Mark Dickinson added the comment:
Fixed in 2.6, 3.0, 3.1.
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue4397>
___
___
Python-
Mark Dickinson added the comment:
Thanks, Benjamin! Checked in in r68553, backported to 3.0 in r68556.
Here's the second patch, which fixes almost all remaining uses of nb_long
but stops short of actually removing/renaming the nb_long slot.
Notes:
(1) I haven't tested the ch
Mark Dickinson added the comment:
Retargeting, now that 2.5 is in security-fix-only mode.
Bob, can you clarify what *should* be happening in 2.6, 2.7, 3.0 and 3.1
for things like:
struct.pack('L', 2009.1)
struct.pack('L', Decimal('3.14'))
?
It also seems that
Mark Dickinson added the comment:
Some more strange results:
Python 2.6.1+ (release26-maint:68613, Jan 15 2009, 15:19:54)
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>
Mark Dickinson added the comment:
Does anyone have time to review these patches? I think the first is
straightforward, and I'm reasonably sure of the correctness of the second
patch. I'm less sure that it's the right thing to do. The question is
what should happen when pick
Mark Dickinson added the comment:
> I wonder if we should mark
> PyNumber_Long as deprecated in the docs, though.
It would be nice to standardize on one of (PyNumber_Long, PyNumber_Int)
and document the other as deprecated.
Maybe it would make more sense to stick with PyNumber_Lo
Mark Dickinson added the comment:
Second patch applied in r68619 (py3k) and r68620 (3.0 maintenance branch).
Here's the third and final patch: rename the nb_long slot to nb_reserved,
and change its type to (void *).
Added file: http://bugs.python.org/file12756/issue4910_3.
Mark Dickinson added the comment:
Here's a patch, against the trunk, that simply amends load_float to ignore
errno on underflow (while retaining it on overflow). This fixes the problem on
my machine.
The added tests may be a little severe. There's no *good* reason why
dumpin
Mark Dickinson added the comment:
Kristján,
The r68461 checkin seems to be causing a number of the buildbots to fail,
typically with output like:
test_capi
test test_capi failed -- Traceback (most recent call last):
File
"/home/pybot/buildarea/trunk.klose-debian-ppc/build/Lib
Mark Dickinson added the comment:
How about using a timer instead of the 'count += 1' loop: after starting
the 32 self.pendingcalls_submit threads, set up a threading.Event and
start yet another thread that simply does a time.sleep(5.0) (or whatever)
and then sets that event.
Mark Dickinson added the comment:
Thanks for the patch, Victor!
Looks pretty good at first glance, except that it seems that the UTF-32 to
UTF-16 translation is skipped if HAVE_USABLE_WCHAR_T is defined. Is that
deliberate?
A test would be good, too
New submission from Mark Dickinson :
The x86 gentoo 3.0 and 3.x buildbots have been failing for a while at the test
stage, with:
make: *** [buildbottest] Unknown signal 32
program finished with exit code 2
I noticed a common denominator with these failures, which is that they always
seem to
Mark Dickinson added the comment:
Another observation is that after test_os has been run, the first test to
actually cause the 'unknown signal' failure always seems to be one that
involves threads (e.g., test_wait3, or test_queue, or te
Mark Dickinson added the comment:
...and there's a related message from Neal Norwitz at:
http://mail.python.org/pipermail/python-3000/2007-August/009944.html
I suspect that
python Lib/test/regrtest.py test_os test_wait3
(possibly with some additional flags to regrtest.py) should
be e
Mark Dickinson added the comment:
> I understand this code as: sizeof(wchar_t) == sizeof(Py_UNICODE). If I
> misunderstood the code, it's a a heap overflow :-)
Yep, sorry. You're right.
>> A test would be good, too.
>
>PyUnicode_FromWideChar() is not a public AP
Mark Dickinson added the comment:
Thanks again for reviewing, Benjamin. nb_long renamed in r68651, merged
to 3.0 (along with a few other long->int cleanups) in r68666.
There seems to be a consensus on deprecating PyNumber_Int. I'll leave
this open until that's
Mark Dickinson added the comment:
Here's a patch that deprecates PyNumber_Int in favour of PyNumber_Long:
- move PyNumber_Int definition from abstract.h to intobject.h (and
fix up comments at the top of intobject.h)
- mark PyNumber_Int as deprecated in the c-api docs, with a promise
Mark Dickinson added the comment:
>From the included patch, I assume you're talking about a failure of
test_pickle.
I'm not seeing any such failure on my (32-bit) system, and the code in
Modules/cPickle.c looks correct to me. I suspect that the problem is that
in your set
Mark Dickinson added the comment:
You might try replacing the strtol call with a call to PyOS_strtol.
Please let us know if this works!
___
Python tracker
<http://bugs.python.org/issue4
Mark Dickinson added the comment:
The distinction between < and <= is fairly meaningless when applied to a
computed floating-point result. I think the docs should be fixed to
replace the < with <=. In any case, the b <= N < a bit has the
inequalities the wrong way around:
Mark Dickinson added the comment:
Looks good to me.
I'm not in a position to test with 16-bit wchar_t, but I can't see why
anything would go wrong. I think we can take our chances: check this in
and watch the buildbots for signs of trouble.
Some minor whitespace iss
Mark Hammond added the comment:
Given bug 4120, this seems the most appropriate resolution...
--
resolution: -> out of date
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Mark Dickinson added the comment:
I believe that __slots__ was used for performance (memory, speed) reasons
here rather than for preventing random attribute assignments. But maybe
inheriting from Rational invalidates those reasons as well...
--
nosy: +marketdickinson
Mark Dickinson added the comment:
The Decimal class has the same issue in py3k (but not in the trunk).
___
Python tracker
<http://bugs.python.org/issue4998>
___
___
Pytho
Mark Dickinson added the comment:
Closing as invalid.
--
resolution: -> invalid
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Mark Dickinson added the comment:
Luke,
I closed this as invalid because it's not a Python bug: your system's
strtol is buggy, so your bug report should go elsewhere.
___
Python tracker
<http://bugs.python.
Mark Dickinson added the comment:
That seems to have done the trick. Thanks!
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/iss
Mark Dickinson added the comment:
Antoine, I leave it to you to decide what to do with this.
As far as I can see, the only action that one might want to take
as a result of this issue is to replace strtol with PyOS_strol
in the codebase (in the struct module, and there's also an
occurren
Changes by Mark Dickinson :
--
nosy: -marketdickinson
___
Python tracker
<http://bugs.python.org/issue4977>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
A random data point: just for fun, I just tried assessing the impact of
__slots__ on Decimal instances, by the crude method of putting all of the
Decimal instances that are created during a complete run of the Decimal
test suite (over 10 of them) into a
Mark Dickinson added the comment:
> ~44 bytes per Decimal on average with __slots__
> ~183 bytes per Decimal on average without __slots__
...and of course a difference of 140 bytes shouldn't really be
much of a surprise:
Python 3.1a0 (py3k:68809M, Jan 20 2009, 16:55:13)
[GCC 4.0.1
Mark Dickinson added the comment:
Thanks for the patch, Raymond.
I'm don't really have any experience with ABCs. I've read the PEP (a few
times), but am not convinced that I fully understand all the ideas
involved.
What are the practical differences between having Fracti
Mark Dickinson added the comment:
Got it. Thanks, Jeffrey. The patch looks good to me---please go ahead
and apply.
--
assignee: marketdickinson -> rhettinger
___
Python tracker
<http://bugs.python.org/iss
Mark Dickinson added the comment:
BTW, Raymond, it looks as though your earlier commit, r68799, changed
distutils/command/wininst-8.0.exe. Was that deliberate?
___
Python tracker
<http://bugs.python.org/issue4
Mark Dickinson added the comment:
Thanks, Martin.
Fixed in py3k in r68814 and r68815, and merged to 3.0 release branch in
r68818.
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/iss
2701 - 2800 of 12223 matches
Mail list logo
