New submission from Mark Dickinson :
Currently, in trunk:
>>> '%0.116x' % 1
'0001'
>>> '%0.117x' % 1
Traceback (most recent call la
Mark Dickinson added the comment:
Looks like I accidentally truncated that traceback. Here's the full version:
Python 2.7a2+ (trunk:78008M, Feb 5 2010, 23:39:39)
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits"
Mark Dickinson added the comment:
Removing 3.2 from the versions: the OverflowError appears to be specific to
2.x ints:
>>> '%0.117x' % 1L
'1'
Mark Dickinson added the comment:
Many thanks for the update. I'll close this as not a Python bug, then.
(Unless there's an easy and nonintrusive workaround...)
--
resolution: -> wont fix
status: open -> closed
___
Pytho
Changes by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue7889>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
[Antoine]
> >>> random.seed(int.from_bytes(b'foo', 'little'))
+1 for either documenting this useful trick, or modifying init_by_array to do
this automatically for buffer-like objects.
Disallowing other types of input for t
Changes by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue1533>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
Thanks for the report, and for the analysis.
I'd call this a bug in the Solaris strtod function (though that doesn't
preclude adding a workaround for Python): the C standards (well, C99, anyway;
I don't have access to C89 at the moment) en
Mark Dickinson added the comment:
> Is there any chance to get those changes you mentioned backported to 2.6?
Actually, to be honest, I'm not sure that backporting these changes to the
release branch is a good idea. Is this bug causing problems in real code
(besides the test sui
Mark Dickinson added the comment:
Out of curiosity, where are your data coming from?
For Python, this seems like a needless complication. It should be simple
enough to replace the 'D's with 'E's prior to passing the strings to float.
I notice that some varieties of Li
Mark Dickinson added the comment:
Sorry, I'm -1 on this: outside Fortran, using 'E' for the exponent marker
seems to be near universal. It just doesn't seem worth adding the extra
complication to the Python code, or going through all the various places that
expect an &#
Mark Dickinson added the comment:
> I would rather not do a search and replace every time before reading in > the
> data.
There's no need to do a search and replace *before* reading the data: read the
data first, then have Python do the replace for you before passing each st
Mark Dickinson added the comment:
Done in r78166 (trunk), r78167 (py3k).
--
___
Python tracker
<http://bugs.python.org/issue7919>
___
___
Python-bugs-list mailin
Mark Dickinson added the comment:
Some of the proposed struct module additions look far from straightforward; I
find that section of the PEP significantly lacking in details and motivation.
"Unpacking a long-double will return a decimal object or a ctypes long-double."
Returning
Mark Dickinson added the comment:
Whoops. ctypes does have long double, of course. Apologies.
--
___
Python tracker
<http://bugs.python.org/issue3132>
___
___
Mark Dickinson added the comment:
A couple of questions for the backport:
(1) should the 'signed' parameter remain keyword-only in 2.7? I'd say yes, to
avoid issues when forward-porting code from 2.7 to 3.2. On the other hand, 2.7
doesn't support keyword-only arguments
Mark Dickinson added the comment:
Thanks, Alexandre! Agreed on both points. I don't really want to allow u'big'
and u'little', but I think that's just my laziness talking. (Apart from that,
I have a working patch.)
There's some precedent for not allowi
Mark Dickinson added the comment:
Thanks both of you for (finally) tracking this down!
I've applied flox's quick fix in r78172, and reverted the old attempted fix in
r78173. Both merged to py3k in r78174.
--
resolution: -> fixed
stage: patch review -> committed
Mark Dickinson added the comment:
Actually, for Python 3.x, rather than using strtod directly it would be better
to use the PyOS_string_to_double C-API function. That function is entirely
locale-agnostic: it should behave identically to the float constructor.
Python 3.0 is no longer
Mark Dickinson added the comment:
Yes, adding carefully placed (size_t) casts seems like the right way to solve
the problem.
I've fixed all (I think) the warnings in r78183, r78184, r78189. I also fixed
one case (unrelated to this issue) of potential undefined behaviour from s
Mark Dickinson added the comment:
Thanks for reporting this.
Rather than documenting corner cases explicitly, maybe it would be enough to
point to the C99 standard: the corner cases for the math functions should
(modulo bugs) all follow Annex F of the C standard, while the corner cases for
Mark Dickinson added the comment:
Hmm. Looking at the docs, there are a number of revisions that would be
useful. For example, the docs mention signaling NaNs, but that doesn't make a
lot of sense: Python essentially treats all NaNs as quiet. I'll add this to
my
Mark Dickinson added the comment:
> And under what conditions would a ctype long double be used vs. a
> Decimal object.
Well, I'm guessing that this was really just an open question for the PEP, and
that the PEP authors hadn't decided which of these two options was more
appr
Mark Dickinson added the comment:
I'm looking for previous discussions of this PEP. There's a python-dev thread
in April 2007:
http://mail.python.org/pipermail/python-dev/2007-April/072537.html
Are there other discussions that I
Mark Dickinson added the comment:
The latest patch looks fine. I've attached a slightly tweaked version:
- Add conversions for number_class; without this, number_class is
inconsistent with the various is_*** methods. "c.is_normal(3)" should be
equivalent to "
Mark Dickinson added the comment:
Tweaked some doctests in r78218:
- add integer argument doctest for logical_invert
- fix integer literals with a leading zero for the other logical_***
methods, since they're illegal in Python 3.
Merged to py3k in r78219.
Thanks, eve
New submission from Mark Dickinson :
With a 64-bit debug non-framework builds of the trunk and py3k, on OS X 10.6,
I'm consistently getting the following failure in test_platform:
trunk dickinsm$ ./python.exe Lib/test/regrtest.py -uall test_platform
test_platform
[18064 refs]
'i
Mark Dickinson added the comment:
Specifically, the behaviour comes from an early check for empty strings in the
PyUnicode_FromEncodedObject function:
/* Convert to Unicode */
if (len == 0) {
Py_INCREF(unicode_empty);
v = (PyObject *)unicode_empty;
}
else
Mark Dickinson added the comment:
Thanks for the patch.
Rather than remove that optimization entirely, I'd consider pushing it into
PyUnicode_Decode.
All tests (whether for the standard library or for the core) go into Lib/test,
so that would be the right place. test_codecs_errors in
Mark Dickinson added the comment:
I take that back: test_codecs_errors isn't the right function to add these
tests to. I actually don't see any current tests for invalid codecs. Part of
the problem would be coming up with an invalid codec name in the first place:
as I understa
Mark Dickinson added the comment:
And PyUnicode_Decode doesn't look up the encoding in the registry either:
that's somewhere in PyCodec_Decode.
I'm going to butt out now and leave this to those who know the code better. :)
--
___
Mark Dickinson added the comment:
Apologies for the delay; tomorrow was a long time coming...
The patch looks great---thank you! I added a ".. versionchanged" note to the
documentation, and fixed a couple of whitespace issues; apart from that I
didn't change anything. Ap
Mark Dickinson added the comment:
I think this can be closed as a duplicate of issue 3132. (Yes, this issue came
first, but all the interesting(?) discussion is over in issue 3132.)
--
dependencies: -implement PEP 3118 struct changes
nosy: +mark.dickinson
resolution: -> duplic
Mark Dickinson added the comment:
[Meador Inge]
> So the next step is to kick off a thread on python-dev summarizing the
> questions\problems we have come up with? I can get that started.
Sounds good. I'd really like to see some examples of how these struct-module
additions would
Mark Dickinson added the comment:
> It does appear that curses itself is broken on FreeBSD
Rereading this, it doesn't say what I meant it to say: I meant that the Python
curses module seems to be broken, not that the system-level curses library is
broken (though that seems poss
Mark Dickinson added the comment:
The code you identify looks okay to me: in PyMarshal_ReadObjectFromString,
isn't it only the temporary variable rf that has a pointer to the string?
Have you read Misc/README.valgrind in the Python source?
--
nosy: +mark.dick
Mark Dickinson added the comment:
Thanks for the update!
--
___
Python tracker
<http://bugs.python.org/issue7974>
___
___
Python-bugs-list mailing list
Unsub
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
901 - 1000 of 6463 matches
Mail list logo
