Mark Dickinson added the comment:
Thanks, Stuart!
I've committed the fix in r67703 and r67704, so it should appear in 3.0.1.
This should fix the silent build failure, and the zero-output interpreter.
The behaviour is still not ideal: a bad LC_CTYPE setting causes
sys.stdout and sys.
Changes by Mark Dickinson :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue2173>
___
___
Python-bugs-list
Changes by Mark Dickinson :
Removed file: http://bugs.python.org/file10764/issue3167.patch
___
Python tracker
<http://bugs.python.org/issue3167>
___
___
Python-bugs-list m
Mark Dickinson added the comment:
Thanks, both!
Fixed in the trunk in r67707. I'll wait to be sure that the buildbots are
happy, then merge to 2.6, 3.0, 3.1.
--
versions: +Python 3.0, Python 3.1
___
Python tracker
<http://bugs.py
Mark Dickinson added the comment:
Closing this. Let's stick with what we have.
--
status: open -> closed
___
Python tracker
<http://bugs.python.or
Mark Dickinson added the comment:
Victor,
Thanks for the updated patch.
I think you need to do a PyErr_Clear after the 'return PyLong_FromSize_t' line.
To be safe, you should probably check the exception type first, and either
do a PyErr_Clear and continue if it's an Overflo
Mark Dickinson added the comment:
Alternatively, you could just ignore _PyLong_NumBits entirely and put the
whole calculation into long_numbits. You're already halfway there with
the calculation of msd_bits anyway, and I suspect the code will look
cleaner (and run faster) tha
Mark Dickinson added the comment:
Buildbots seem content. Merged to 2.6, 3.0, 3.1.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Mark Dickinson added the comment:
I've committed the issue 3167 fix in revisions r67707 to r67710.
I'm fairly sure that this patch should resolve this issue. (Let me know
if it doesn't.)
--
resolution: -> fixed
status: open -> closed
_
Mark Dickinson added the comment:
Victor,
This looks good. If it's okay with you, I'll work on the documentation
a little (we need an entry in whatsnew, and a description of the
semantics of numbits for 0 and negative integers.) Then I think this
will be ready.
> I prefe
Mark Dickinson added the comment:
Here's Victor's patch, but with extra documentation. No code has been
changed.
Two more questions about the code, Victor; specifically about
long_numbits:
- why do you use PyLong_FromSize_t rather than PyInt_FromSize_t?
- isn't the i
Mark Dickinson added the comment:
Oops. Here's the patch.
Added file: http://bugs.python.org/file12331/numbits-6a.patch
___
Python tracker
<http://bugs.python.org/i
Mark Dickinson added the comment:
Duplicate of issue #4640.
--
nosy: +marketdickinson
resolution: -> duplicate
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Mark Dickinson added the comment:
Duplicate of issue #4640.
--
nosy: +marketdickinson
resolution: -> duplicate
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Mark Dickinson added the comment:
> I choosed to use consistent result type. But now I would prefer int :-) I see
> that PyInt_FromSize_t() returns a long if the value doesn't fit in an int. So
> it's correct.
Cool. I think int is better, simply because the result is almo
Changes by Mark Dickinson :
Removed file: http://bugs.python.org/file12331/numbits-6a.patch
___
Python tracker
<http://bugs.python.org/issue3439>
___
___
Python-bug
Mark Dickinson added the comment:
As far as I'm concerned, this patch is ready to be applied.
Raymond, care to give a second opinion?
--
assignee: marketdickinson -> rhettinger
stage: patch review -> commit review
___
Python tra
Mark Summerfield added the comment:
Although I stand by my criticism of IDLE not offering the option of
switching off cursor blink, I've now discovered that the problem was
with Fedora 10 no longer executing xrdb .Xdefaults; once I added that
line to my .bash_profile the cursor blinking st
Mark Dickinson added the comment:
About the name:
Java's Bignum has a 'significantBits' method, which apparently returns
the position of the MSB (i.e., numbits - 1).
GMP has mpz_sizeinbase; mpz_sizeinbase(n, 2) is almost the same as
numbits, except that mpz_sizeinbase(0,
Mark Dickinson added the comment:
> Perhaps n.bit_length() with an underscore.
I thought I recalled Guido having a preference for float.fromhex over
float.from_hex when that got implemented. But either spelling seems good
to me.
___
Python tracker
&l
Mark Dickinson added the comment:
> I thought I recalled Guido having a preference for float.fromhex over
Can't find anything to back this up. It looks like I'm just making this
up.
___
Python tracker
<http://bugs.pyth
Mark Dickinson added the comment:
> Did you look at the O(lg n) algorithm yet? Any thoughts?
So there are two places this could be applied: the int_numbits method
and _PyLong_NumBits. I'd be quite surprised if this offered any
noticeable speedup in either case. Might be wor
Mark Dickinson added the comment:
Three files:
(1) bit_length7.patch just does the numbits->bit_length renaming;
otherwise it's the same as numbits-6b.patch.
(2) bit_length7_opt.patch uses the fast bitcount method that Raymond
pointed out.
(3) bit_length_pybench.patch adds a
Changes by Mark Dickinson :
Added file: http://bugs.python.org/file12337/bit_length7_opt.patch
___
Python tracker
<http://bugs.python.org/issue3439>
___
___
Python-bug
Changes by Mark Dickinson :
Added file: http://bugs.python.org/file12338/bit_length_pybench.patch
___
Python tracker
<http://bugs.python.org/issue3439>
___
___
Python-bug
Mark Dickinson added the comment:
> Well, I don't think bit_length() warrants a specific test which will
> slow down the whole pybench suite.
Me neither. It's a temporary patch to pybench, to establish whether it's
worth applying optimizations to bit_length. I didn
Mark Dickinson added the comment:
Slightly improved optimized version.
Added file: http://bugs.python.org/file12339/bit_length7_opt.patch
___
Python tracker
<http://bugs.python.org/issue3
Changes by Mark Dickinson :
Removed file: http://bugs.python.org/file12337/bit_length7_opt.patch
___
Python tracker
<http://bugs.python.org/issue3439>
___
___
Python-bug
Mark Dickinson added the comment:
Added another test to pybench; it makes sense to consider cases where the
input n is uniformly distributed in [0, 2**31) as well as cases where the
output n.bit_length() is uniformly distributed in [0, 32).
Added file: http://bugs.python.org/file12340
Changes by Mark Dickinson :
Removed file: http://bugs.python.org/file12338/bit_length_pybench.patch
___
Python tracker
<http://bugs.python.org/issue3439>
___
___
Pytho
Mark Dickinson added the comment:
I think I've found the happy medium:
bit_length7_opt2.patch achieves nearly the same performance gains as
bit_length7_opt.patch (around 7% for uniformly-distributed inputs, 3.5%
for uniformly-distributed outputs), but is much more straightforwar
Changes by Mark Dickinson :
Removed file: http://bugs.python.org/file12332/numbits-6b.patch
___
Python tracker
<http://bugs.python.org/issue3439>
___
___
Python-bug
Mark Dickinson added the comment:
> In the documentation, should "same value as ``x.bit_length``" not be
> "same value as ``x.bit_length()``"?
Yes, of course. Thanks!
Added file: http://bugs.python.org/file12343/bit_length7_opt2.patch
Changes by Mark Dickinson :
Removed file: http://bugs.python.org/file12342/bit_length7_opt2.patch
___
Python tracker
<http://bugs.python.org/issue3439>
___
___
Python-bug
Changes by Mark Dickinson :
Removed file: http://bugs.python.org/file12339/bit_length7_opt.patch
___
Python tracker
<http://bugs.python.org/issue3439>
___
___
Python-bug
Changes by Mark Dickinson :
Removed file: http://bugs.python.org/file12336/bit_length7.patch
___
Python tracker
<http://bugs.python.org/issue3439>
___
___
Python-bug
Mark Dickinson added the comment:
Updated patch; cleanup of comments and slight refactoring of code.
Int->float conversions are even a speck faster than the current code, for
small inputs. (On my machine, on a Friday night, during a full moon.
Your results may differ. :))
Also, retar
Changes by Mark Dickinson :
Removed file: http://bugs.python.org/file10694/long_as_double.patch
___
Python tracker
<http://bugs.python.org/issue3166>
___
___
Python-bug
Changes by Mark Dickinson :
Removed file: http://bugs.python.org/file12343/bit_length7_opt2.patch
___
Python tracker
<http://bugs.python.org/issue3439>
___
___
Python-bug
Mark Dickinson added the comment:
Update both patches:
(1) change PyLong_FromLong(ndigits-1) to PyLong_FromSsize_t(ndigits-1) in
both patches (it's possible to have a 32-bit long and 64-bit Py_ssize_t), and
(2) in the optimized patch, add the table lookup optimization for
long_bit_l
Changes by Mark Dickinson :
Added file: http://bugs.python.org/file12349/bit_length7_opt2.patch
___
Python tracker
<http://bugs.python.org/issue3439>
___
___
Python-bug
Changes by Mark Dickinson :
Removed file: http://bugs.python.org/file12320/long_as_double2.patch
___
Python tracker
<http://bugs.python.org/issue3166>
___
___
Python-bug
Mark Dickinson added the comment:
Here's a patch (force_to_memory2.patch) that I'm hoping fixes the cmath
test failures on Solaris 10/x86.
Skip, could you give it a try?
The patch isn't final: I need to look for more places where
Py_FORCE_DOUBLE should be applied. But I&
Mark Dickinson added the comment:
> The macro Py_IS_INFINITY don't work on linux. The test case(force-inf.c)
> is attached. The result don't depend from optimisation flag.
Thanks, Roumen. I rather suspected that Py_IS_INFINITY was dodgy this
way.
On the other hand, this i
Mark Dickinson added the comment:
Thanks, Skip. Looks like this problem is 'solved in principle'. Now I
have to figure out a non-hackish solution.
___
Python tracker
<http://bugs.python.
Mark Dickinson added the comment:
It looks to me as though all these are valid, and the patch should be
applied to py3k and the 3.0 maintenance branch.
Minor nit: the "sizeof(theInfo)" line exceeds 79 characters, in violation
of PEP 7.
Is there any core developer who's in a p
Mark Dickinson added the comment:
Thanks for all the comments. Here's an updated patch, with quite a few
changes:
code:
- drop lookup tables in favour of "while(x) {x >>= 1; count += 1;}"
- add example to docstring, and use PyDoc_STRVAR macro for docstrings
docs
Changes by Mark Dickinson :
--
components: +Interpreter Core -Library (Lib)
___
Python tracker
<http://bugs.python.org/issue3439>
___
___
Python-bugs-list mailin
Mark Dickinson added the comment:
Okay; I don't have strong feelings about the form the Python code takes;
I'll let you guys argue it out and then fix things accordingly
___
Python tracker
<http://bugs.python.
Mark Dickinson added the comment:
Updated patch.
Added file: http://bugs.python.org/file12363/bit_length9.patch
___
Python tracker
<http://bugs.python.org/issue3
Changes by Mark Dickinson :
Removed file: http://bugs.python.org/file12348/bit_length7.patch
___
Python tracker
<http://bugs.python.org/issue3439>
___
___
Python-bug
Changes by Mark Dickinson :
Removed file: http://bugs.python.org/file12349/bit_length7_opt2.patch
___
Python tracker
<http://bugs.python.org/issue3439>
___
___
Python-bug
Changes by Mark Dickinson :
Removed file: http://bugs.python.org/file12362/bit_length8.patch
___
Python tracker
<http://bugs.python.org/issue3439>
___
___
Python-bug
Mark Dickinson added the comment:
Bah. Fix test_int so that it actually works.
Added file: http://bugs.python.org/file12364/bit_length10.patch
___
Python tracker
<http://bugs.python.org/issue3
Changes by Mark Dickinson :
Removed file: http://bugs.python.org/file12363/bit_length9.patch
___
Python tracker
<http://bugs.python.org/issue3439>
___
___
Python-bug
Mark Dickinson added the comment:
...and use proper unittest methods instead of asserts...
Added file: http://bugs.python.org/file12365/bit_length11.patch
___
Python tracker
<http://bugs.python.org/issue3
Mark Dickinson added the comment:
> Before applying, consider adding back the part of the docs with the '1 +
> floor(...' definition.
My only (minor) objection to this definition is that a straight Python
translation of it doesn't work, thanks to roundoff error and
the
New submission from Mark Florisson :
sys.exit() exits the program when non-daemonic threads are still
running, in versions >= 2.5.
Test included. A demonstration here: http://paste.pocoo.org/show/95766/
(On debian GNU/Linux)
--
components: None
files: foo.py
messages: 77978
nosy: e
Mark Dickinson added the comment:
Committed to trunk in r67822, py3k in r67824.
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/iss
Mark Dickinson added the comment:
Thanks for the report. I can reproduce this both on the py3k branch and the
trunk. It looks as though there's a race condition
in the testShutDown/_testShutDown pair of methods in SocketConnectedTest. If
you add the line
time.sleep(0.01)
to the m
New submission from Mark Evans :
The "GUI Programming on the Mac" page:
http://www.python.org/doc/2.5.3/mac/node10.html
states that the PyObjC project is at:
http://pybojc.sourceforge.net
This is incorrect and should be:
http://pyobjc.sourceforge.net
This appears fixed in t
Mark Dickinson added the comment:
Fixed in r67844 (trunk), r67845 (2.6), r67846 (py3k) and r67847 (3.0).
Thanks for the report and patch!
--
nosy: +marketdickinson
resolution: -> fixed
status: open -> closed
versions: +Python 2.7, Pyth
Mark Dickinson added the comment:
About the footnote:
floor(log(n, 2)) is poor code. This is not supposed to be a dramatic
statement, just a statement of fact. Its correctness is dependent on
minute details of floating point. It is poor code in exactly the same way
that "while x <
Mark Dickinson added the comment:
> ... so that ``k`` is approximately ``1 + int(log(abs(x), 2))``.
I guess that could work.
One other thing: the docs for the trunk seem to suggest that we should
be using trunc here, rather than int. I'm looking at:
http://docs.python.org/dev
New submission from Mark Dickinson :
pybench needs to be updated for Python 3.0, in particular to remove use of
cmp. Here's a patch, against the py3k branch.
Questions (mainly for Marc-André Lemburg):
1. Should the version number be bumped for *all* tests, or just for those
that
Mark Dickinson added the comment:
Still to do:
pybench needs updating to remove a cmp reference; since the changes
required for pybench are a little bit more substantial than simple cmp
replacement, I've broken this out into a separate issue: issue 4704.
There are many uses of cmp
Mark Dickinson added the comment:
Should Py_CmpToRich (in object.c) disappear?
It's currently used in longobject.c, but nowhere else as far as I can
tell. It shouldn't be too hard to update longobject.c to remove the use.
___
Python trac
Mark Dickinson added the comment:
Looks like a bug to me. I get the expected behaviour on my machine.
Python 3.0+ (release30-maint:67878, Dec 20 2008, 17:31:44)
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
Type "help", "copyright", "credits" or "license&
Mark Dickinson added the comment:
Correction: it looks like two bugs to me.
I think the wrong-return-type bug is rather serious, possibly a release
blocker for 3.0.1. I'll see if I can produce a patch.
The incorrect rounding (returning 30.0 instead of 20.0) is less serious,
but still
Mark Dickinson added the comment:
> Why do you say the return type is incorrect? It should, and does,
> return a float.
The documentation at:
http://docs.python.org/dev/3.0/library/functions.html#round
says, of round(x[, n]):
"""The return value is an integer if cal
Mark Dickinson added the comment:
Jeffrey, any opinion on this?
--
nosy: +jyasskin
___
Python tracker
<http://bugs.python.org/issue4707>
___
___
Python-bug
Mark Dickinson added the comment:
> Is your guess for round(25.0,
> -1)==30.0 that 25.0*(1/10.0) is slightly more than 2.5 on some
> systems?
Yes, something like that. I don't think it's feasible to make round
perfectly correct (for floats) in all cases without implement
Mark Dickinson added the comment:
Here's a first attempt at a patch for round(int, int) -> int.
--
keywords: +patch
Added file: http://bugs.python.org/file12407/round_int_int.patch
___
Python tracker
<http://bugs.python.or
Mark Dickinson added the comment:
Updated patch: fix test_builtin. (Rest of the patch unchanged.)
Added file: http://bugs.python.org/file12412/round_int_int2.patch
___
Python tracker
<http://bugs.python.org/issue4
Mark Dickinson added the comment:
> >>> round(2, -2**31 + 2) # Press Ctrl + C
> Segmentation fault
> (backtrace below)
Thanks, Daniel. It looks like I messed up the refcounting in the error-
handling section of the code. I'll fix this.
I don't think the hang i
Mark Dickinson added the comment:
Cause of segfault was doing Py_XDECREF on a pointer that hadn't been
initialised to NULL.
Here's a fixed patch.
I still get the instant result:
>>> round(2, -2**31+1)
2
which is a little odd. It's the correct result, but I can
Mark Dickinson added the comment:
Aha. The special result for round(x, 1-2**31) has nothing to do with this
particular patch. It's a consequence of:
#define UNDEF_NDIGITS (-0x7fff) /* Unlikely ndigits value */
in bltinmodule.c. The same behaviour results for all types, not just
Mark Dickinson added the comment:
> [Me]
> > which is a little odd. It's the correct result, but I can't see how
[Daniel]
> Is it correct?
No. :-) It should be 0, as you say.
> Given that "round(2, 2**31)" throws an OverflowError
I think this is wrong,
Mark Dickinson added the comment:
Thanks for the responses!
> I don't think should go into 3.0.1 - they are a new feature
> and not a bug fix.
But if these changes don't go into 3.0.1, and the removal of cmp does,
that means that pybench won't run on 3.0.1. It seem
Mark Dickinson added the comment:
Final patch.
Skip, could you please give this one a try, and then with any luck this
can be fixed for 3.0.1. (Sorry for creating more work; this should be
the last time.)
I've added a configure test that detects x87 FPU usage, via the double
rou
New submission from Mark Sapiro :
The Mailman GUI contains a few links to the python.org documentation
which are now broken. These links and the current equivalents are:
http://www.python.org/doc/
works, but could map to http://docs.python.org/
http://www.python.org/doc/current/
works
Mark Hammond added the comment:
I've no time to dig deeper now as I suspect testing will require removal
of the vc9 assembly from the GAC and testing with a local one, but some
comments:
test.c's error is "can't find the DLL" - this will be as we attempt to
load Pyth
Mark Hammond added the comment:
I meant to mention: FWIW, *some* py2exe apps work fine with the old
scheme - specifically, IIUC, any app will work fine so long as the .pyd
files were next to the executable, which is next to the assembly. I
understand this is a significant restriction, but its
New submission from Mark Hammond :
This block in exceptions.c:
#if defined _MSC_VER && _MSC_VER >= 1400 && defined(__STDC_SECURE_LIB__)
...
/* turn off assertions in debug mode */
prevCrtReportMode = _CrtSetReportMode(_CRT_ASSERT, 0);
#endif
Does exactly what the c
Mark Hammond added the comment:
I've hacked together something that fixes the problem. I'm working on
making it a real patch, but the basis is:
* In DllMain (dl_nt.c), we call:
case DLL_PROCESS_ATTACH:
GetCurrentActCtx(&PyWin_DLLhActivationContext);
Mark Hammond added the comment:
It would be interesting to know which tests actually fail. If the tests
are explicitly checking a bad fd, then IMO it makes more sense for that
test to simply be avoided in debug builds and nothing of value would be
left untested. OTOH, I'd also be happy
Mark Hammond added the comment:
I guess another option is to expose it via msvcrt and let the test
themselves disable it?
___
Python tracker
<http://bugs.python.org/issue4
Mark Hammond added the comment:
Attaching a patch which works for me against python 2.6. Only ever
tested on Vista (ie, where the function pointers etc all load)
--
keywords: +needs review, patch
Added file: http://bugs.python.org/file12536/bug4566.patch
Changes by Mark Hammond :
Removed file: http://bugs.python.org/file12536/bug4566.patch
___
Python tracker
<http://bugs.python.org/issue4566>
___
___
Python-bugs-list m
Mark Hammond added the comment:
Attaching a new patch with some typos in the comments corrected. While
I'm here, I also meant to mention (again!):
* No need to remove the the assembly from the sxs cache - the test
"fails correctly" with VS2009 installed. FWIW, I compiled
Mark Dickinson added the comment:
> Accordingly, I recommend Decimal.from_float(f) with no qualifiers or
> optional arguments.
I agree with this. Since lossless conversion is feasible, this seems
the obvious way to go.
It's lucky that the exponent range for (binary) floats is
Mark Dickinson added the comment:
One also has to worry about the exponent of the converted result: e.g.,
should Decimal.from_float(10.0) produce Decimal('1E1') or Decimal('10')?
The latter looks nicer, to me.
IEEE 754 isn't much help here: as far as I can tell it s
Mark Dickinson added the comment:
> Just for the avoidance of all doubt, do you mean the largest exponent
> with the number normalised to one digit to the right of the decimal
> place?
No. I'm using 'exponent' in the sense described in the standard. See:
http:/
Mark Dickinson added the comment:
Here's a patch (against py3k) generated from the current state of the
py3k-issue1717 branch, for ease of review and testing.
The patch needs serious review; it should be considered a first draft,
and there are probably many more changes still to be mad
Mark Dickinson added the comment:
[Raymond]
> I would
> not like to see that extended to cmath or complex() unless compelling
> real-world use cases arise.
Hmm. Have you looked at the cmath module recently? You may be in for a
nasty surprise...
> Mark, does Inf hav
Mark Dickinson added the comment:
cdavid, in your application, how hard is it to work around the problem by
simply printing and parsing pairs of floats rather than complex numbers?
E.g.,
z = complex(float(real_part), float(imag_part))
___
Python tracker
Mark Dickinson added the comment:
> Uhm ? The builtin cmp wasn't removed.
Non-removal of cmp for 3.0 was an oversight. It *might* be removed in
3.0.1. See issue 1717.
--
nosy: +marketdickinson
___
Python tracker
<http://bugs
Mark Dickinson added the comment:
> It looks like you and Raymond have rejected #2 but are keeping #1
I'm not against #2, but I'm not particularly for it either. In any case,
once you've converted your float to Decimal it's trivial to round it to
whatever precisi
Changes by Mark Hammond :
Removed file: http://bugs.python.org/file12537/bug4566.patch
___
Python tracker
<http://bugs.python.org/issue4566>
___
___
Python-bugs-list m
Mark Hammond added the comment:
Uploading a corrected patch; some old docs I saw said DWORD, and I
obviously neglected to fix every spot I used that, and I've changed
'Vista' to 'XP' in the patch comments.
Added file: http://bugs.python.or
2601 - 2700 of 12223 matches
Mail list logo
