Changes by Mark Dickinson :
--
resolution: -> invalid
___
Python tracker
<http://bugs.python.org/issue7974>
___
___
Python-bugs-list mailing list
Unsubscri
Mark Dickinson added the comment:
Please could you generate and upload a patch against the Python source? (For
Windows, you can do this using the WinMerge tool, amongst others.) I'm unable
to open the file you attached on my machine:
"""No applicati
Mark Dickinson added the comment:
About long doubles again: I just encountered someone on the #python IRC
channel who wanted to know whether struct.pack and struct.unpack supported
reading and writing of x87 80-bit long doubles (padded to 12 bytes each in the
input). A few quotes from him
Mark Dickinson added the comment:
The ideal exponent for three-argument pow should definitely be zero. You're
returning what's essentially an integer, loosely disguised as a decimal
instance.
--
___
Python tracker
<http://bu
Mark Dickinson added the comment:
I've fixed the docs to accurately describe three-argument pow results (the
exponent in particular) in r78312 through r78315.
--
___
Python tracker
<http://bugs.python.org/i
Mark Dickinson added the comment:
> One benefit of having a type code for 'long double' (assuming you are
> mapping the value to the platform's 'long double') is that the you
> don't have to know how many bytes are in the underlying representation.
Mark Dickinson added the comment:
I agree that the performance improvement isn't worth the extra code, or the
risk of introducing bugs (the comments so far show that it's not trivial to get
this right).
Closing as rejected.
--
nosy: +mark.dickinson
resolution: -> re
Mark Dickinson added the comment:
Well, the real problem is that powmod doesn't really belong in the decimal
module at all. It's not a natural primitive arithmetic operation; it's
certainly not naturally a floating-point operation; nothing like this appears
in any floating
Mark Dickinson added the comment:
This looks good! Is it worth mentioning that autoreconf updates pyconfig.h.in
as well as configure?
There's also an OS X oddity to be aware of, though I'm not sure whether it's
worth mentioning in the FAQ. On OS X 10.6, the system auto
Mark Dickinson added the comment:
> BTW, should the changes to the generated "configure" be excluded
> from such patches, or should they be included? (to what extent do
> they contain meaningful information during review?)
Not sure. I think it's fine to leave the co
Mark Dickinson added the comment:
Might it be T_PYSSIZET rather than T_INT? In which case it's PyLong_AsSsize_t
that's at fault: it should raise TypeError for non-integers. What's slightly
less clear is whether PyLong_AsSsize_t should also try to call int to conv
Mark Dickinson added the comment:
Here's a patch that raises TypeError if either PyLongAs_Size_t or
PyLong_As_Ssize_t gets called with a valid non-integer PyObject *.
I'm not sure where the most appropriate place for a test is.
--
assignee: -> mark.dickinson
key
Mark Dickinson added the comment:
This is a bug in your code, rather than in Python.
A simpler example, for the purposes of explanation:
>>> root, total = [0], []
>>> total.append(root)
>>> total # good so far
[[0]]
>>> root[0] = 1 # modify root
>&
Mark Dickinson added the comment:
> So s.append(x) just copies the pointer, not the actual value.
Yes, that's a reasonable way to think about it (though the term 'reference'
seems to more popular than 'pointer' in this context). It matches the
implementation
Mark Dickinson added the comment:
I'd be open to re-allowing use of __int__ (and __long__) consistently for all
integer packing codes in 2.7, as a temporary measure; I'd really prefer not to
allow this for 3.x.
What would make more sense, IMO, would be to allow use of the __inde
Mark Dickinson added the comment:
More or less, yes: when trying to pack a non-integer `x` (i.e. something
that's not an instance of int or long) with an integer format code (one of
'bBhHiIlLqQ', or 'P'), `x.__index__()` would be called to convert `x` to an
intege
Mark Dickinson added the comment:
Also, it may be that some of r73858 needs to be reverted; going from accepting
non-ints and longs in 2.6 to a TypeError in 2.7 is a bit much; there should
have at least been a DeprecationWarning. I need to find some time to look at
this properly, and work
Mark Dickinson added the comment:
How common is this 'common practice'? Could you point to some publicly
available examples? Are there other languages that have built-in facilities for
dealing with hexadecimal representations of integers in this way?
I think I've seen hex st
Mark Dickinson added the comment:
Closing this for now; if you want to pursue this, please take the suggestion
to the python-ideas mailing list.
--
resolution: -> rejected
status: open -> closed
___
Python tracker
<http://bugs.p
Mark Dickinson added the comment:
Before a patch, there needs to be a concrete proposal: how would this be
specified, and what would the precise semantics be?
--
___
Python tracker
<http://bugs.python.org/issue8
Mark Dickinson added the comment:
Please note that the docs distinguish 'standard size and alignment' from
'native size and alignment'. The standard size (which is what you get if your
struct format string doesn't start with '<', '>', &#
Mark Dickinson added the comment:
Oops. In "... struct format string doesn't start with.. " in my comment above,
replace "doesn't start with" with "starts with".
--
___
Python tr
Mark Dickinson added the comment:
Well, it's a bug inasmuch as the docs aren't as clear as they could be.I've
got issue 7355 open to remind me to do something about that, though, so this
one can probably be closed.
--
resolution: -> invalid
stat
Mark Dickinson added the comment:
I'm confused: are you talking about producing underscores when formatting an
integer for hexadecimal output, or allowing numeric literals to contain
underscores?
Your perl example produces:
305441741
with not an underscore in sight. I'm
Mark Dickinson added the comment:
+1 for Benjamin's patch, having just been bitten by this exact problem.
I'm trying to do unit testing, checking both that a piece of code produces a
DeprecationWarning and that it gives the correct result, with something like:
Mark Dickinson added the comment:
This is somewhat orthogonal, but it might also be nice to have some way to tell
check_warnings not to touch __warningregistry__. See also issue 4180.
--
nosy: +mark.dickinson
___
Python tracker
<h
Mark Dickinson added the comment:
Here's a patch to restore the old usage of __int__ to convert non-integer
arguments; it also produces a DeprecationWarning whenever __int__ is used in
this way. For consistency and simplicity, __int__ will be tried for *any*
non-integer argument
Mark Dickinson added the comment:
Updated patch, with slightly saner warnings checks.
--
Added file: http://bugs.python.org/file16484/issue1530559__int__2.patch
___
Python tracker
<http://bugs.python.org/issue1530
Mark Dickinson added the comment:
Restored use of __int__ for all integer conversion codes in r78762.
--
___
Python tracker
<http://bugs.python.org/issue1530
Mark Dickinson added the comment:
Recent checkins messed up Meador Inge's __index__ patch; here's a regenerated
version.
--
Added file: http://bugs.python.org/file16485/issue-1530559__index__.patch
___
Python tracker
<http://bu
Mark Dickinson added the comment:
Comments and thoughts on the __index__ patch:
(1) Thank you for a remarkably complete patch!
(2) For 2.x, I'm a bit uncomfortable with introducing the extra Python layer on
top of the C layer. Partly I'm worried about accidentally breaking someth
Mark Dickinson added the comment:
This isn't a bug in Python: it's an unavoidable symptom of using binary
floating-point arithmetic internally to store values.
I recommend looking at the last chapter of the Python tutorial, which gives a
very nice explanation of floating-point iss
Mark Dickinson added the comment:
Applied in r78902.
--
resolution: -> accepted
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Mark Dickinson added the comment:
Thanks, Benjamin! test_structmembers.py looks perfect.
--
___
Python tracker
<http://bugs.python.org/issue8014>
___
___
Pytho
Mark Dickinson added the comment:
Tests for this issue, currently failing on T_INT/T_UINT (internal error),
T_LONG/T_ULONG (fails to raise TypeError), T_PYSSIZET (internal error). The
older patch only fixes the T_PYSSIZET failures; I'm working on a fix for the
others.
--
Mark Dickinson added the comment:
Internal errors for T_UINT and T_PYSSIZET fixed in r78918. The fix needs to be
backported to the release31-maint branch, but I don't think it's urgent enough
to try getting it in between 3.1.2 rc1 and 3.1.2 final.
There's still a probl
Mark Dickinson added the comment:
Fixed reason for failing tests (there was a bad error check in structmembers.c
that compared a return value with (unsigned int)-1 instead of (unsigned
long)-1), and re-enabled those tests, in r78920.
Leaving open for the backport to 3.1.
--
versions
New submission from Mark Dickinson :
test_issue5604 from test_imp is currently failing on OS X !0.6 (py3k branch),
with the following output:
==
ERROR: test_issue5604 (__main__.ImportTests
Mark Dickinson added the comment:
Also affects 3.1.
--
versions: +Python 3.1
___
Python tracker
<http://bugs.python.org/issue8133>
___
___
Python-bugs-list mailin
Mark Dickinson added the comment:
Here's a patch:
- comparisons between a Decimal and float produce a result based
on the numeric values of the Decimal and float
- change Decimal.__hash__ so that floats and Decimals with (exactly)
equal value have the same hash. This pres
Mark Dickinson added the comment:
I see that you already closed this; but just for completeness:
This is expected behaviour: in 2.x, the '/' operator does floor division
unless you've done a 'from __future__ import division', in which case it does
true division.
Mark Dickinson added the comment:
Brett: any thoughts on this? Should imp.find_module automatically apply NFD
normalization to the given string on OS X?
It seems to me that doing this properly is a bit nasty, since the correct
condition isn't that the OS is OS X, but that the rel
Mark Dickinson added the comment:
For anyone interested, there's an ongoing python-dev discussion about how to
resolve this at
http://mail.python.org/pipermail/python-dev/2010-March/098437.html
--
___
Python tracker
<http://bugs.py
Mark Dickinson added the comment:
I don't think there's anything worth fixing here. It's true that getsizeof is
sometimes going to return results that are too small, because there are a good
few places in the longobject internals where it's not predictable in advance
ex
Mark Dickinson added the comment:
That patch works for me.
(You should probably commit the comment fix in the patch separately though,
rather than mixing it up with this issue.)
--
___
Python tracker
<http://bugs.python.org/issue8
New submission from Mark Dickinson :
Here's a patch that makes hash(x) == hash(y) for any numeric types (int, float,
complex, Decimal, Fraction, bool) when x and y are numerically equal.
This is a prerequisite for making all numeric types accurately comparable with
each
Mark Dickinson added the comment:
Uploaded to Rietveld:
http://codereview.appspot.com/660042
--
___
Python tracker
<http://bugs.python.org/issue8188>
___
___
Mark Dickinson added the comment:
Updated patch, with a bit of cleanup and some comments describing the hashing
strategy; I'll update the Rietveld issue as well.
--
Added file: http://bugs.python.org/file16606/numeric_hash2.patch
___
P
Changes by Mark Dickinson :
Removed file: http://bugs.python.org/file16606/numeric_hash2.patch
___
Python tracker
<http://bugs.python.org/issue8188>
___
___
Python-bug
Mark Dickinson added the comment:
Whoops; that patch included some accidental Lib/test/test_decimal changes.
Here's the correct patch.
--
Added file: http://bugs.python.org/file16607/numeric_hash2.patch
___
Python tracker
<http://bugs.py
Mark Dickinson added the comment:
> Why aren't you using 64-bit hashes on 64-bit architectures?
Mostly because I haven't got around to putting that in yet. :)
Ideal would be to use _PyHASH_BITS=61 for 64-bit machines, throughout.
--
_
Mark Dickinson added the comment:
No, I mean 61. 2**61 - 1 is prime; 2**63-1 is not. (So 2 bits of the hash
get wasted, but that's not a big deal, especially since they're the high-end
bits and Python mostly cares about the lower-
Mark Dickinson added the comment:
Restore tests accidentally omitted from second patch.
--
Added file: http://bugs.python.org/file16608/numeric_hash2.patch
___
Python tracker
<http://bugs.python.org/issue8
Changes by Mark Dickinson :
Removed file: http://bugs.python.org/file16607/numeric_hash2.patch
___
Python tracker
<http://bugs.python.org/issue8188>
___
___
Python-bug
Mark Dickinson added the comment:
Updated patch:
- put hash parameters into pyport.h, to avoid repetition; make them
available to Python code via a private attribute sys._hash_info.
- use a modulus of 2**61-1 on systems where SIZEOF_LONG >= 8, and
a modulus of 2**31 - 1 otherw
Mark Dickinson added the comment:
Another update, partly to address comments raised by Guido on Rietveld. I'll
upload these changes to Rietveld later today.
- rename sys._hash_info to sys.hash_info and make it public rather than
private (it still needs docs somewhere)
- add
Mark Dickinson added the comment:
Re-opening to address a couple of points that came out of the python-dev
discussion:
(1) As Stefan pointed out on python-dev, equality and inequality comparisons
involving signaling nans should signal (order comparisons already do). IEEE
754 is fairly
Mark Dickinson added the comment:
> I think hash(Decimal("snan")) should also succeed
On second thoughts, this would be bad, since it would lead to unpredictable
results for sets of dicts containing a signaling nan:
>>> from decimal import Decimal
[69536 refs]
>
Mark Dickinson added the comment:
Here's a patch (against py3k) to make all comparisons involving signaling nans
raise InvalidOperation.
Stefan, does this look okay to you?
--
keywords: +patch
Added file: http://bugs.python.org/file16631/issue7279.
Mark Dickinson added the comment:
Here's a version of the patch that adds exact comparisons between the various
numeric types. The only slightly tricky comparison is the Fraction <-> Decimal
one: an obvious strategy is to convert the Decimal exactly to a Fraction and
then use t
Mark Dickinson added the comment:
>From the values in the report, float.fromhex is giving the correct value here,
>but MIN-3*TINY is somehow coming out incorrectly.
Correct values (with Python 2.6, so old float repr; OS X 10.6.2):
Python 2.6.5+ (release26-maint:79559:79560, Apr 1 20
Changes by Mark Dickinson :
--
priority: -> high
___
Python tracker
<http://bugs.python.org/issue8257>
___
___
Python-bugs-list mailing list
Unsubscri
Mark Dickinson added the comment:
Float-to-decimal comparisons have been fixed, and the Decimal hash function
changed so that numerically equal Decimal and float instances hash equal, in
r79583.
The idea of raising an exception for float<->Decimal comparisons was discarded
part
Mark Dickinson added the comment:
Raymond, do you want this to go into 2.7 as well? I'm assuming that we're not
going to allow mixed-type float+decimal operations in 2.7.
Also, if we're doing this, it seems to me that all the reasons you give for the
Decimal constructor a
Mark Dickinson added the comment:
Thanks, Stefan. Applied to trunk in r79588. Still needs to be forward ported
to py3k.
--
versions: +Python 3.2
___
Python tracker
<http://bugs.python.org/issue7
Mark Dickinson added the comment:
Allowed hashing of Decimal('nan') in r79589; Decimal('snan') continues to
raise TypeError.
I've also rewritten Decimal.__hash__ a little bit, so that it won't care if
float('inf') raises an exception. This will al
Mark Dickinson added the comment:
The backport wasn't as straightforward as I'd hoped, and we've pretty much run
out of time for 2.7.
One issue is that long.from_bytes(b, ...) converts b to bytes type using the
equivalent of "bytes(b)". This doesn't work wel
Mark Dickinson added the comment:
The original error, for a 32-bit machine, looks like expected behaviour to me;
at worst, it's a doc bug. If the right-hand argument doesn't fit into a
Py_ssize_t, then I think it's reasonable to refuse to do the shift.
But Antoine's &#
Mark Dickinson added the comment:
> Mark, I do think we should have decimal+float-->float in 2.7 also.
That's fine with me in principle. But isn't 2.7 in feature freeze from
tomorrow?
--
___
Python tracker
<http://bugs.p
Mark Dickinson added the comment:
> And yes, I agree that Fraction(somedecimal) should work too.
What about Fraction(1.1)?
--
___
Python tracker
<http://bugs.python.org/iss
Mark Dickinson added the comment:
I made a couple of experimental checkins to the release26-maint branch (I
didn't want to do a temporary checkin to the trunk with a release imminent):
see r79560 (which didn't work :) and its fix in r79601. Results:
MIN = 2.2250738585072014e-
Mark Dickinson added the comment:
A nitpick: on OS X, the gdb script ends up being called:
python.exe-gdb.py
Is this intentional? If it is, then I'll add this filename to the svn:ignore
property. (And also to make distclean, I guess. Is python-gdb.py currently
deleted by a
Mark Dickinson added the comment:
Added python.exe-gdb.py to svn:ignore in r79616.
--
___
Python tracker
<http://bugs.python.org/issue8032>
___
___
Python-bug
Mark Dickinson added the comment:
> To my knowledge, OS X doesn't ship with gdb 7
That sounds right. On my OS X 10.6.3 machine, the system gdb is:
Mark-Dickinsons-MacBook-Pro:py3k dickinsm$ gdb --version
GNU gdb 6.3.50-20050815 (Apple version gdb-1346) (Fri Sep 18 20:40:51 UTC 2009)
New submission from Mark Dickinson :
Here's a patch that allows direct construction of a Fraction instance from a
float or Decimal instance, performing an exact conversion in either case.
>>> from fractions import Fraction
>>> from decimal import Decimal
>
Mark Dickinson added the comment:
(The patch is against trunk, btw.)
--
___
Python tracker
<http://bugs.python.org/issue8294>
___
___
Python-bugs-list mailin
Mark Dickinson added the comment:
Unfortunately, that line is wrong (or at least incomplete), since decimals in
exponential form are also accepted:
>>> Fraction('2.3e4')
Fraction(23000, 1)
I could try to reinstate a fixed version.
Attaching a second version of the patch:
Mark Dickinson added the comment:
Thanks, Raymond. Committed to trunk in r79629. Will forward port to py3k.
--
versions: -Python 2.7
___
Python tracker
<http://bugs.python.org/issue8
Mark Dickinson added the comment:
Merged to py3k in r79670.
--
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Mark Dickinson added the comment:
r79588 and r79589 were merged to py3k in r79668.
--
resolution: invalid -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Mark Dickinson added the comment:
Closing this; it's too late for Python 2.7.
--
status: open -> closed
versions: -Python 2.7
___
Python tracker
<http://bugs.python.org/i
Mark Dickinson added the comment:
Merged to py3k in r79668.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Mark Dickinson added the comment:
Closing this; a separate feature request should be opened for the idea of
adding __index__ awareness to struct.pack in py3k.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
New submission from Mark Dickinson :
In Python 2.7, struct.pack with an integer format can handle non-integers that
provide an __int__ method (although this *does* raise a DeprecationWarning).
Python 2.7a4+ (trunk:79659:79661, Apr 3 2010, 11:28:19)
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1
Changes by Mark Dickinson :
--
components: +Extension Modules
stage: -> test needed
type: -> feature request
___
Python tracker
<http://bugs.python.org/
Mark Dickinson added the comment:
I've opened issue 8300 for adding the __index__ handling.
--
superseder: -> Allow struct.pack to handle objects with an __index__ method.
___
Python tracker
<http://bugs.python.org/i
Mark Dickinson added the comment:
Here's a patch for trunk. It combines the docs and tests from Meador Inge's
patch in issue 1530559 with a C-level change to get_pylong in Modules/struct.c.
--
keywords: +patch
versions: +Python 2.7
Added file: http://bugs.python.org
Mark Dickinson added the comment:
Adding Meador Inge to nosy.
--
nosy: +minge
___
Python tracker
<http://bugs.python.org/issue8300>
___
___
Python-bugs-list m
Mark Dickinson added the comment:
That patch was a bit hasty in many respects; here's a better one.
For 2.7, the scheme is as follows: when packing a non-integer with an integer
format:
(1) First __index__ is tried
(2) If the __index__ method doesn't exist, or the call to __inde
Changes by Mark Dickinson :
--
priority: -> normal
stage: test needed -> patch review
___
Python tracker
<http://bugs.python.org/issue8300>
___
___
Pyth
Mark Dickinson added the comment:
Committed this patch to trunk in r79674. Will forward port to py3k.
--
___
Python tracker
<http://bugs.python.org/issue8
Mark Dickinson added the comment:
This still seems to be an issue for OS X. With the current trunk (r79716), I
get:
Mark-Dickinsons-MacBook-Pro:trunk dickinsm$ ./python.exe -3
./Lib/test/regrtest.py test_macostools test_py3kwarn
test_macostools
/Users/dickinsm/python/svn/trunk/Lib/importlib
New submission from Mark Dickinson :
I'm seeing a very peculiar test_pep263 failure when doing 'make test' on OS X
10.6.3. It's enough to run test___all__ and test_pep263, in that order:
Mark-Dickinsons-MacBook-Pro:trunk dickinsm$ ./python.exe -Wd -3 -E -tt
./
Mark Dickinson added the comment:
That should be "NameError" in the last line of the previous message, not
"TypeError".
--
___
Python tracker
<http://bu
Mark Dickinson added the comment:
After some more digging, it looks as though this is due to the Tkinter import
(that ends up happening as a result of test___all__) changing the locale(?),
and in particular the meaning of isalpha:
Python 2.7a4+ (trunk:79716, Apr 3 2010, 22:06:18)
[GCC
Mark Dickinson added the comment:
> (Is there some way that I can see the locale change more explicitly from
> Python?)
Found it. :)
>>> locale.nl_langinfo(locale.CODESET)
'US-ASCII'
[40683 refs]
>>> import Tkinter
[56953 refs]
>>> locale.nl_l
Mark Dickinson added the comment:
I realize that the above doesn't really explain why the NameError is occurring:
Python's token recognition algorithm, in tok_get in tokenizer.c, uses isalpha,
which is locale-aware. In particular, it seems that chr(255) is considered
alphabetic in
Mark Dickinson added the comment:
Ned: yes, that works too. Thanks!
--
___
Python tracker
<http://bugs.python.org/issue8307>
___
___
Python-bugs-list mailin
Mark Dickinson added the comment:
What Ilya Sandler said!
Computing sin or cos with large arguments requires high precision for the
intermediate calculations (e.g., for sin(1e22) you'd need around 40 digits of
precision for the reduction step), so most math libraries don't bother.
Mark Dickinson added the comment:
Probably both those conditions can't be satisfied; I'm wasn't sure what
happened if something's __index__ method returned something other than an int
or long.
But now I bother to look at the source (in Objects/abstract.c) I see that th
1801 - 1900 of 12223 matches
Mail list logo
