Changes by Mark Dickinson :
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Mark Dickinson added the comment:
Closing as "won't fix", for reasons given above.
--
resolution: -> wont fix
status: open -> closed
___
Python tracker
<http://b
Mark Dickinson added the comment:
I've fixed some of the inaccurate comments in Objects/longobject.c, for the
default branch; I'm still looking at the Doc update.
This really is a bit of a mess, especially for cases like PyLong_AsVoidPtr,
which can either end up calling PyLong_As
Mark Dickinson added the comment:
> It could be fun to remove these conversions and see how much of the
> test-suite fails. :-)
... On my machine, just test_ctypes and test_getargs2, as it turns out.
--
___
Python tracker
<http://bugs.p
Mark Dickinson added the comment:
New changeset 221638ba5d2a by Mark Dickinson in branch 'default':
Issue #13248, issue #8540: Remove deprecated Context._clamp attribute from
Decimal module.
http://hg.python.org/cpython/rev/22
Changes by Mark Dickinson :
--
priority: normal -> critical
stage: -> needs patch
versions: +Python 3.3
___
Python tracker
<http://bugs.python.org/i
Mark Dickinson added the comment:
Patch looks good to me.
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue13343>
___
___
Python-bug
Mark Dickinson added the comment:
I can't reproduce this:
Python 2.7.2 |EPD 7.1-2 (32-bit)| (default, Jul 3 2011, 15:40:35)
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "packages", "demo" or "enthought" for more information.
>>> from random
Mark Dickinson added the comment:
> What do you suggest? Doing it in _PyEval_SliceIndex() in 2.7 is
> problematic, as we don't want x[None:2], right? :)
Eh? Don't we already have this?
Python 2.7.2 (default, Aug 22 2011, 13:53:27)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)
Mark Dickinson added the comment:
> it would be convenient if low=high=mode returned low (or mode or high)
Yes, I agree that random.triangular should degrade gracefully, in the same way
that random.uniform does.
--
___
Python tracker
&l
Mark Dickinson added the comment:
How would you suggest refactoring this?
For that example, I'd prefer not to remove the repetition; as it is, the code
is clean and clear. Eliminating the repetition would involve adding an extra
layer of indirection, making the code in one of
Mark Dickinson added the comment:
Sorry, I'm closing this as rejected. It might possibly have been better to
write the code this way to begin with, but the code is already there, it's
working, and there's little to be gained by 'fixing' it at this po
Changes by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue11937>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
Yep, there's an oddity here that's directly inherited from C's sprintf family
of functions, namely that in %e-style formatting you give the number of digits
after the point (= one less than the total number of significant digits), and
in %g-s
Mark Dickinson added the comment:
> Maybe a note describing that %g is different from the others in this regard?
-1 from me; I don't really see that that would improve the documentation.
Maybe that's just me, but I expect reference documentation to be clean, and
uncluttered
Changes by Mark Dickinson :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue12245>
___
___
Python-bugs-list
Changes by Mark Dickinson :
--
assignee: mark.dickinson ->
___
Python tracker
<http://bugs.python.org/issue7433>
___
___
Python-bugs-list mailing list
Un
Mark Dickinson added the comment:
Closing as won't fix. Even deprecation doesn't seem worth the effort here.
--
resolution: -> wont fix
status: open -> closed
___
Python tracker
<http://bugs.p
Changes by Mark Dickinson :
--
versions: +Python 3.3 -Python 2.7, Python 3.2
___
Python tracker
<http://bugs.python.org/issue2813>
___
___
Python-bugs-list mailin
Mark Dickinson added the comment:
Status update: all the reported errors from the Objects/ directory have been
fixed in the default branch (many of these were fixed recently as part of
making sure that the test-suite runs under Clang's -ftrapv option), or are out
of date. I haven'
Mark Dickinson added the comment:
See also issue #1621.
--
___
Python tracker
<http://bugs.python.org/issue9530>
___
___
Python-bugs-list mailing list
Unsub
Mark Dickinson added the comment:
The issues reported for the datetime, array, itertools and math modules are
also already fixed. That just leaves the following two of the reported issues
outstanding:
: Op: <<=, Reason :
Signed Left Shift Error: Right operand is negative or is g
Mark Dickinson added the comment:
See also issue #9530.
--
___
Python tracker
<http://bugs.python.org/issue1621>
___
___
Python-bugs-list mailing list
Unsub
Changes by Mark Dickinson :
--
versions: +Python 3.2, Python 3.3 -Python 2.6
___
Python tracker
<http://bugs.python.org/issue13433>
___
___
Python-bugs-list mailin
Mark Dickinson added the comment:
> I'd be happy to re-run the tests sometime.
Yes, please! Alternatively, if there are easy instructions for us to re-run
these tests, that would be valuable, too. Do I understand correctly that you
have a publicly available extension to LLVM
Mark Dickinson added the comment:
+1 to kwargs support in sched. I've also ended up modifying sched.py to
support this in the past.
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/is
New submission from Mark Dickinson :
Docs nit: at http://docs.python.org/dev/library/stdtypes.html#boolean-values
we have
"""
The built-in function bool() can be used to cast any value to a Boolean ...
"""
It's a little unusual to talk about casting in Py
Mark Dickinson added the comment:
Given that we typically need at least 4 bytes just for the PyObject * pointer
for each item in a list, I guess real lists are safe.
But how about list-like objects, implementing __len__ and __getitem__? The
following appears to run forever on my machine
Mark Dickinson added the comment:
> Does Python really need yet another multiprecision library?
It's not really another library: it's a reimplementation of the existing
decimal library in C. The decimal library is *hugely* valuable to the
financial world, but its slowne
Mark Dickinson added the comment:
See also issue #13496.
--
___
Python tracker
<http://bugs.python.org/issue9530>
___
___
Python-bugs-list mailing list
Unsub
Mark Dickinson added the comment:
Well, it's sort of documented implicitly: from
http://docs.python.org/c-api/intro.html#exceptions
"In general, when a function encounters an error, it sets an exception,
discards any object references that it owns, and returns an error indicator
Changes by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue13535>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
The 'self.bit_length() >= bits' condition for to_unsigned doesn't look right to
me.
E.g., if bits == 32, I'd expect the acceptable range of values to be
range(-2**31, 2**31)---i.e., including -2**31, but excluding 2**31.
Mark Dickinson added the comment:
On the feature request itself, I have to say that I'm unconvinced. Doing x %
(2**32) seems good enough to me, in situations where you don't need the bounds
checking. (And it's not clear to me that needing the bounds checks is the more
c
Changes by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue13534>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Mark Dickinson :
--
versions: -Python 3.4
___
Python tracker
<http://bugs.python.org/issue13534>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
Thanks for the report, and all the sleuthing. It's always good to see Python's
test suite expose C library (or C compiler) bugs. :-)
I propose closing this as 'won't fix': I certainly wouldn't want to add
workarounds in the
Changes by Mark Dickinson :
--
assignee: -> mark.dickinson
___
Python tracker
<http://bugs.python.org/issue13534>
___
___
Python-bugs-list mailing list
Un
Mark Dickinson added the comment:
Style nit: how about
'except ValueError as e'
instead of
'except ValueError, e'
(Actually, why do we need e?)
--
nosy: +mark.dickinson
___
Python tracker
<http://bug
Mark Dickinson added the comment:
Isn't the documentation that you refer to about *nested* list comprehensions,
rather than list comprehensions with multiple 'for' clauses?
E.g.,:
[number for row in matrix for number in row]
is not a nested list comprehension: it&
Mark Dickinson added the comment:
Mind you, I'm not at all sure about that use of 'apprehension'...
--
___
Python tracker
<http://bugs.pyt
Mark Dickinson added the comment:
+1 for fixing this.
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue13573>
___
___
Python-bugs-list m
Mark Dickinson added the comment:
Agree with the -1s.
--
___
Python tracker
<http://bugs.python.org/issue13603>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
> Can this be fixed?
Not without breaking backwards compatibility, I would think.
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issu
Mark Dickinson added the comment:
Did you have specific changes in mind?
While we're still maintaining 2.x and 3.x code in parallel, there's a benefit
to not having the versions of decimal.py diverge too much. Given that the
2.3-compatible code isn't actually broken, I&
Mark Dickinson added the comment:
No, but they take tuples:
>>> 'abcd'.endswith(('a', 'b'))
False
>>> 'abcd'.endswith(('c', 'd'))
True
Suggest closing as out of date.
--
nosy: +
Mark Dickinson added the comment:
[Antoine]
> Also, how about false positives? Having legitimate programs break
> because of legitimate data would be a disaster.
This worries me, too.
[MAL]
> Yes, which is why the patch should be disabled by default (using
> an env var) in dot-re
Mark Dickinson added the comment:
Here's a patch. Stefan, could you please review?
--
keywords: +patch
Added file: http://bugs.python.org/file22068/issue12080.patch
___
Python tracker
<http://bugs.python.org/is
Changes by Mark Dickinson :
--
stage: -> commit review
___
Python tracker
<http://bugs.python.org/issue12080>
___
___
Python-bugs-list mailing list
Unsubscri
Mark Dickinson added the comment:
Here's a slightly improved version that adds guards against computing 10**ye
for large ye in the case y < 0, ye > 0.
--
Added file: http://bugs.python.org/file22069/issue12080_v2.patch
___
Python tra
New submission from Mark Dickinson :
In Python 2.6 and 2.7, str.translate accepts None as a first argument. That's
documented in the docs, but not in the str.translate docstring.
--
assignee: docs@python
components: Documentation
messages: 136720
nosy: docs@python, mark.dick
Mark Dickinson added the comment:
How about something like: "Return a float with the magnitude of x but the sign
of y."?
The behaviour of math.copysign with respect to non-float inputs matches that of
almost all the other math module functions: integer arguments are first
co
Changes by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue12185>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
Thanks for the patches! Here's a slight expansion of the wording on your
second patch:
Return a copy of the string S, where all characters occurring
in the optional argument deletechars are removed, and the
remaining characters have been mapped th
Mark Dickinson added the comment:
Closing, based on feedback in the comments. Maybe one day...
--
resolution: -> later
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Mark Dickinson added the comment:
float_info.rounds is a bit of an odd fish, and I think it was probably a
mistake to include it in sys.float_info in the first place.
All the other float_info fields relate to parameters of the floating-point
format, which is fixed, useful information. In
Changes by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue12232>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Mark Dickinson :
--
nosy: +christian.heimes
___
Python tracker
<http://bugs.python.org/issue12245>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Mark Dickinson :
--
assignee: docs@python -> mark.dickinson
___
Python tracker
<http://bugs.python.org/issue12245>
___
___
Python-bugs-list mai
Mark Dickinson added the comment:
Fixed for 3.3 and 2.7.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Mark Dickinson added the comment:
> I think we should include the "On a platform ..."
Sure, sounds good. One of the main things that makes copysign useful is that
it distinguishes between -0.0 and 0.0.
--
___
Python t
Mark Dickinson added the comment:
> Is it possible that the problem is related to floating point exceptions?
Hmm. It's possible, but it's still a bit surprising that the crash occurs at
import time rather than when calling one of the cmath functions. But it's very
possi
Mark Dickinson added the comment:
Looking at the cmath source, I'd be a bit suspicious that either the Py_NAN or
the Py_HUGE_VAL macro (or both) is triggering an FPE. Both those values are
used during module initialization.
--
___
Python tr
Mark Dickinson added the comment:
This is expected behaviour: Python 3 changed the semantics of the comparison
operators <, <=, >, >=. See:
http://docs.python.org/py3k/whatsnew/3.0.html#ordering-comparisons
for more.
--
nosy: +mark.dickinson
resolution: -> inval
Mark Dickinson added the comment:
> In this example, I'm sort by item number 1, which is a list, and its
> first value is an int.
? You're sorting by the values of the dict d, and those values have the form
[int, int, dict]; so when the two ints match (e.g., in your data
Mark Dickinson added the comment:
... and you probably want
sorted(lst0, key=len, reverse=True)
anyway. :-)
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue12
Mark Dickinson added the comment:
Not to mention d(area of circle of radius r) = r dr matey.
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue12
Changes by Mark Dickinson :
--
resolution: accepted -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue12164>
___
___
Pyth
Changes by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue12381>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
> all it does is give information about the FPU settings at the time that
> Python was compiled
Hmm. It's actually a bit better than that: as far as I can tell, it reflects
the value of FLT_ROUNDS at the time that Python is started (when the sys
Mark Dickinson added the comment:
Patch that elaborates a bit on the meaning of sys.float_info.rounds.
--
keywords: +patch
Added file: http://bugs.python.org/file22454/issue12245.patch
___
Python tracker
<http://bugs.python.org/issue12
Changes by Mark Dickinson :
--
assignee: mark.dickinson ->
___
Python tracker
<http://bugs.python.org/issue9990>
___
___
Python-bugs-list mailing list
Un
Changes by Mark Dickinson :
--
assignee: mark.dickinson ->
___
Python tracker
<http://bugs.python.org/issue10227>
___
___
Python-bugs-list mailing list
Un
Mark Dickinson added the comment:
Thanks for the patch!
--
nosy: +mark.dickinson
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Mark Dickinson added the comment:
Thanks for the report.
--
nosy: +mark.dickinson
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Mark Dickinson added the comment:
Hadn't seen that. Interesting!
--
___
Python tracker
<http://bugs.python.org/issue7117>
___
___
Python-bugs-list m
Mark Dickinson added the comment:
[Amaury]
"It would be interesting to see if it is better/faster than the current dtoa."
I agree that it would be interesting to compare.
[Eric]
"maybe we can say we we can live with 99.5% shortest repr coverage"
Please no! As you say,
Mark Dickinson added the comment:
The result of:
struct.pack("d", float("inf"))
would also be interesting. I'd expect to see:
'\x7f\xf0\x00\x00\x00\x00\x00\x00'
--
___
Python tracker
Mark Dickinson added the comment:
The '1.06...e-314' number in the gdb output is interesting: it indicates a
byte-ordering issue, though maybe that issue is only pertinent to gdb itself.
On a little-endian machine:
>>> struct.pack('>> struct.pack('
Mark Dickinson added the comment:
Question: does this test also fail after configuring with the --with-pydebug
flag? (Which I *think* should turn compiler optimizations off, amongst other
things.)
--
___
Python tracker
<http://bugs.python.
Mark Dickinson added the comment:
If there's dependence on undefined behaviour (from overflow of signed integer
operations) in intobject.c, I'd call that a bug. I've been trying to remove
similar overflow checks from the Python source when I've encountered them, but
th
Mark Dickinson added the comment:
> "/ 2" is an integer division, so it should be "// 3" in Python 3.
No, I don't think that's right: 2to3 has no way of knowing that the programmer
intended an integer division here (self.maxstars could be a float).
Inste
Changes by Mark Dickinson :
--
nosy: +benjamin.peterson
resolution: -> invalid
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Changes by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue12754>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
I agree with you on the correct 8 output bytes. And those expected bytes are
exactly what struct.pack is producing here:
Python 2.7.2 |EPD 7.1-1 (32-bit)| (default, Jul 3 2011, 15:40:35)
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "packages&qu
Mark Dickinson added the comment:
> with codes 0x3f and 0x63 respectively
Whoops: that should be '... 0x3f and 0x6e ...'.
--
___
Python tracker
<http://bugs.pytho
Mark Dickinson added the comment:
+1 for turning these into TypeErrors. It makes little sense that
PyLong_AsLongLong and PyLong_AsUnsignedLongLong behave differently here.
Do you have a patch handy?
--
___
Python tracker
<http://bugs.python.
Mark Dickinson added the comment:
> This probably shouldn't be backported to 3.2
Agreed; I don't see this as a bugfix (especially since AFAIK it's not
documented that TypeError should be raised here); rather, as a design
improvement.
> Also, it's worth noti
Mark Dickinson added the comment:
The patch still needs tests (e.g., in test_capi). I'm not sure whether it
would be good to add information about the TypeError to the docs.
--
___
Python tracker
<http://bugs.python.org/is
Mark Dickinson added the comment:
Looks good to me.
I'd prefer 'test_long_as_size' to be called 'test_long_as_size_t' (even though
that's inaccurate for the ssize_t bits :-).
The 'Py_None' reference counting in test_long_as_size and test_long_as_dou
Mark Dickinson added the comment:
> is it really worth adding?
Probably not. For improvements along these lines, I'd rather see random.choice
support sets:
>>> random.choice({1, 2})
Traceback (most recent call last):
File "", line 1, in
File
"/Lib
Mark Dickinson added the comment:
[about adding float128]
> I realize a new float type would be a major undertaking
That's an understatement and a half. The only way this could ever be viable is
if float128 support becomes widespread enough that we don't have to write our
own a
Mark Dickinson added the comment:
Thanks, Ned!
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue8457>
___
___
Changes by Mark Dickinson :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue7037>
___
___
Python-bugs-list
Mark Dickinson added the comment:
The problem here is the spaces in the input string:
newton:~ dickinsm$ python2.7
Python 2.7 (r27:82500, Jul 13 2010, 14:10:05)
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type "help", "copyright", "credits" or "license
Mark Dickinson added the comment:
Note also that spaces are already allowed immediately inside the parentheses in
a string argument to the complex constructor (in python 2.6 and later):
>>> complex("( 1.1+2.1j )")
(1.1001+
Changes by Mark Dickinson :
--
stage: -> needs patch
versions: +Python 3.2 -Python 2.5, Python 2.6, Python 2.7, Python 3.1
___
Python tracker
<http://bugs.python.org/iss
Mark Dickinson added the comment:
I'm wondering whether the moratorium (PEP 3003) applies to this; from a close
reading I'd say it does. At any rate, it seems like an inessential
enhancement, so I'd be happy to delay this until 3.3.
--
versions: +Python
Mark Dickinson added the comment:
I don't think determining *which* whitespace is allowed is a problem; just use
whatever's already being used for the whitespace that's already allowed (around
the whole complex input, for example, or between the optional parentheses and
the n
Mark Dickinson added the comment:
Fixed in 2.6 in r83970 (3.1 and 2.7 were fixed in revisions r83781, r83782).
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/iss
201 - 300 of 6463 matches
Mail list logo
