Change by Mark Dickinson :
--
nosy: +Mark.Shannon
___
Python tracker
<https://bugs.python.org/issue46724>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
+1
--
nosy: +mark.dickinson
___
Python tracker
<https://bugs.python.org/issue46737>
___
___
Python-bugs-list mailing list
Unsub
Mark Dickinson added the comment:
Can you explain why you think the result of `a == b` should be `False` rather
than `True`? By default, equality for dataclasses is structural equality, and
`True` is the result that I'd expect here.
>From the
>[docs](https://docs.python.or
Mark Dickinson added the comment:
> the constructed Fraction first computes the range of the values that the
> input string could have been rounded from
There's too much magic and guesswork here for my liking; I don't really see
this as feasible. Moreover, depending on whi
Mark Dickinson added the comment:
> in which case the interval we need is [0.095, 0.15]
Whoops, sorry; brain fail. If we're rounding to two sig figs, the next
representable value up from 0.01 is 0.011, while the next one down is 0.099, so
the interval we'd be interested in wou
Mark Dickinson added the comment:
Sigh:
> the next representable value up from 0.01 is 0.011
should say:
> the next representable value up from 0.10 is 0.11
I think I'll duck out and give my brain a rest before commenting further.
--
___
Mark Dickinson added the comment:
One more example: what interval is implied by an input string of "1600"? Is it
(1550, 1650)? Or (1595, 1605)? Or even (1599.5, 1600.5).
Sorry, I just don't see this working - there are two many arbitrary choices
involved in guessing what in
Mark Dickinson added the comment:
> I'd modify the optimization to be that we continue to seek the smallest
> denominator, but in the case that multiple numerators would give ratios
> within the computed interval then we choose the numerator among these that
> gives the rat
Mark Dickinson added the comment:
Okay, let's close here; as Raymond says, that doesn't prevent further
discussion on python-ideas.
> The notions are currently too immature to warrant more core developer time.
Agreed. It seems that what Lee wants is some kind of blend between
Mark Dickinson added the comment:
Re python-ideas: there's a mailing list:
https://mail.python.org/archives/list/python-id...@python.org/
But the https://discuss.python.org/c/ideas/ category also works for this.
--
___
Python tracker
&
Mark Dickinson added the comment:
> I gave the code example in order to make that clear.
Yep, that didn't help: reverse engineering the intended behaviour from a
complicated piece of code isn't easy. An up-front description of the intended
behaviour wo
Change by Mark Dickinson :
--
nosy: -mark.dickinson
___
Python tracker
<https://bugs.python.org/issue24053>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Mark Dickinson :
--
title: Yaytext.net - Tạo văn bản chữ kiểu, kí tự đặc biệt độc đáo -> spam
___
Python tracker
<https://bugs.python.org/issu
Mark Dickinson added the comment:
I'd be happy to see `float.__setformat__` go, if it's not still needed for
Python's test suite (which was its entire raison d'être). If no-one noticed the
accidental misnaming, then it's pretty clear no-one's been using it.
I&#
Mark Dickinson added the comment:
Thanks, Victor. I think this can be closed now.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Mark Dickinson added the comment:
> I reopen the issue for the second part of my plan
Hmm. That sounds like it should be a separate issue, or at the least, this
issue should be retitled. It's helpful to keep issue titles accurate.
--
__
Change by Mark Dickinson :
--
components: -Distutils, Documentation, Extension Modules, Installation,
Parser, email
nosy: -barry, docs@python, dstufft, eric.araujo, lys.nikolaou, pablogsal
type: security -> behavior
___
Python tracker
<
Change by Mark Dickinson :
--
components: +Extension Modules
___
Python tracker
<https://bugs.python.org/issue6778>
___
___
Python-bugs-list mailing list
Unsub
Mark Dickinson added the comment:
> * Mention the new build requirement in What's New in Python 3.11.
> * Modify configure script to make it fail if the IEEE 754 support is missing.
> * Remove code handling missing NAN and infinity: float("nan"), float("inf&qu
Mark Dickinson added the comment:
This is the intended behaviour. See the docs here:
https://docs.python.org/3/reference/datamodel.html#object.__ror__
> These functions are only called if the left operand does not support the
> corresponding operation and the operands are of different
Change by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<https://bugs.python.org/issue46920>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson
added the comment:
To help explain what's going on, here's some Python code. The Python
function long_hash1 below has the properties that:
(1) long_hash1(n) == hash(n) for almost all integers
Mark Dickinson
added the comment:
Here's a revised patch, that only touches longobject.c and does the minimum
necessary to alter long.__hash__ from being *almost* completely predictable to
being completely predic
Mark Dickinson
added the comment:
And here's the updated decimal.__hash__ patch that goes with the
long.__hash__ patch.
_
Tracker <[EMAIL PROTECTED]>
<http://b
Mark Dickinson
added the comment:
There's a bug on line 1341 of decimal.py. That line currently reads:
otherside = otherside._rescale(exp, context=context)
It should read:
otherside = otherside._rescale(exp, co
Mark Dickinson
added the comment:
I should have said that the bug I mentioned above is just one of a
number of bugs (mostly in division, addition and square root) that have
been corrected in the trunk. Some of these fixes
Mark Dickinson added the comment:
I took a look at this a while back, and got as far as writing a pure
Python drop-in replacement for cmath, based on Kahan's "branch cuts for
elementary functions" paper. This fixes a variety of problems in cmath,
including the buggy branch
New submission from Mark Dickinson:
With the current ./configure setup, it looks to me as though there are
no circumstances under which the file Python/hypot.c is compliled.
There's a line
AC_REPLACE_FUNCS(hypot)
in configure.in; which is supposed (if I understand correctly) to check
Mark Dickinson added the comment:
hypot.patch contains a possible fix, together with a fix for the includes
in hypot.c itself. (As it was, compilation of hypot.c would fail due to
ssize_t being referenced before definition, in pyport.h.)
Added file: http://bugs.python.org/file8727
Mark Dickinson added the comment:
This is a feature request rather than a bug. There's a least one good
reason not to do this, namely that the specification on which the decimal
module is based specifically disallows this: At
http://www2.hursley.ibm.com/decimal/daconvs.html
it says:
Mark Dickinson added the comment:
Here is (quite a large) patch, cmath.patch, that fixes a variety of
problems in the current cmath module. A summary of the changes:
* sqrt, log, acos, acosh, asin, asinh, atan, atanh no longer produce
overflow errors for very large inputs
* exp, cos, sin
New submission from Mark Dickinson:
In Python2.5 and the current trunk, construction of a complex number from two
floats
loses the negative sign of a negative zero in the imaginary part.
>>> complex(-0., 0.).real # behaves as expected
-0.0
>>> complex(0., -0.).imag # lose
Mark Dickinson added the comment:
> I ran the ctypes tests on Debian GNU/Linux 5.0.8 (lenny) on an ARMv5tejl
> Versatile kernel and everything passed.
I believe the problem is specific to machines still using the old ABI ('OABI').
Which ABI was being used on your test machin
Mark Dickinson added the comment:
> "unlabelled balls in unlabelled boxes with capacity limits"
What does this mean? If the boxes are unlabelled, how can they have individual
capacity limits? Or do you mean just a single limit that applies to all boxes?
--
nosy: +m
Mark Dickinson added the comment:
> "unlabelled balls in labelled boxes with capacity limits"
Out of curiosity, what was the application that you needed this for?
This one feels a bit too specialized to me to be worth adding to the itertools
library; I see itertools more a
Mark Dickinson added the comment:
> I propose adding the Decimal fields "ctime", "atime", and "mtime" to the >
> named tuple returned by os.stat().
That would be an interesting precedent: I don't think there are many (any?)
other places outside
Mark Dickinson added the comment:
Yep, clearly a bug. Please fix!
--
___
Python tracker
<http://bugs.python.org/issue12963>
___
___
Python-bugs-list mailin
Changes by Mark Dickinson :
--
versions: +Python 3.3 -Python 3.2
___
Python tracker
<http://bugs.python.org/issue1172711>
___
___
Python-bugs-list mailin
Mark Dickinson added the comment:
Yes, please let's not add any new __int__-based duck typing here; IMO, we
should be moving away from such uses of __int__. I'd be fine with __index__
based duck-typing.
--
___
Python trac
Mark Dickinson added the comment:
> I don't think it is practical to support both ABIs.
I suspect you're right.
--
___
Python tracker
<http://bugs.pyth
Mark Dickinson added the comment:
> Mark, just to clarify a bit, the behavior is already there in the array module
Okay, understood. But the new 'long long' support provided by this patch still
allows for __int__-based duck typing, right?
>>> array('Q', [1,
Mark Dickinson added the comment:
>>> 2**64
0
Urk! I'd call that a release blocker.
--
___
Python tracker
<http://bugs.python.org/issue11149>
___
Mark Dickinson added the comment:
Reopening and assigning to me; it would be good to fix this in intobject.c as
well as adding the Clang-specific -fwrapv fix.
--
assignee: -> mark.dickinson
nosy: +mark.dickinson
status: closed -> open
___
Mark Dickinson added the comment:
Here's a simple patch. Is anyone in a good position to see if this fixes the
tests failures for Clang (without the fwrapv flag)?
--
keywords: +patch
Added file: http://bugs.python.org/file23155/issue12975
Mark Dickinson added the comment:
Thanks Victor; I just managed to install Clang, and it looks I can reproduce
the failures. I'm testing right now to see if the patch fixes them all...
--
___
Python tracker
<http://bugs.python.org/is
Mark Dickinson added the comment:
I've got Clang from MacPorts, on OS X 10.6.8.
iwasawa:cpython mdickinson$ clang --version
clang version 2.9 (tags/RELEASE_29/final)
Target: x86_64-apple-darwin10
Thread model: posix
Without the patch (and before the -fwrapv inclusion), I get the foll
Mark Dickinson added the comment:
I don't see how this is helpful---all it's reporting on is whether that
compiler happened to decide to optimize away that particular comparison;
something which is going to be highly dependent on compiler version, flags,
platform, etc., and sti
Mark Dickinson added the comment:
BTW, I suspect that the reason there were no related test failures with the
Intel compiler is that most of the problems in the Python code stem from
multiplications rather than additions. Probably icc isn't sophisticated enough
to optimize
Mark Dickinson added the comment:
Gah; did I really misnumber that issue patch? Sorry.
> Mark, did you write those rules down somewhere?
Well, they're all in the standard, which is publicly available. (Or at least,
a draft of the standard that's pretty much interchangeable
Mark Dickinson added the comment:
> an assumption that the C implementation will never raise an
> 'implementation-defined' signal (C99 6.3.1.3p3).
Sorry, this should have been more explicit: "will never raise ... when
converting
Mark Dickinson added the comment:
Those two patches (for listobject and itertools) look fine to me.
--
___
Python tracker
<http://bugs.python.org/issue12
Mark Dickinson added the comment:
Agreed. Commit first; worry about __int__ and __index__ later.
--
___
Python tracker
<http://bugs.python.org/issue1172
Mark Dickinson added the comment:
Yes, that's intentional. When use of __int__ was deprecated, a bug report
popped up from someone who wanted to be able to have their own objects treated
as integers for the purposes of struct.pack. (I don't recall which issue;
Meador, do yo
Mark Dickinson added the comment:
"won't fix" seems reasonable to me.
--
___
Python tracker
<http://bugs.python.org/issue7201>
___
___
Python-b
Changes by Mark Dickinson :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue7201>
___
___
Python-bugs-list mailing list
Unsubscri
Mark Dickinson added the comment:
> It's biggest deficiency (compared to Gay's dtoa.c) is its specialization > to
> IEEE doubles.
We're only using the portion of Gay's code (with some significant modifications
at this point) that applies to the IEEE 754 bina
Mark Dickinson added the comment:
> Balls-in-boxes _is_ one of the most basic of the canonical combinatorial
> problems.
Agreed. But in its basic form, this is covered by itertools.combinations,
isn't it? It may be worth a doc recipe showing how to use
itertools.combinatio
Mark Dickinson added the comment:
And using combinations_with_replacement, it's even a one-liner:
>>> balls_in_boxes = lambda n, k: (tuple(map(c.count, range(k))) for c in
>>> combinations_with_replacement(range(k), n))
>>> for item in balls_in_boxes(5,3): pri
New submission from Mark Dickinson :
The docstring of str.splitlines says:
splitlines(...)
S.splitlines([keepends]) -> list of strings
Return a list of the lines in S, breaking at line boundaries.
Line breaks are not included in the resulting list unless keepends
is gi
Mark Dickinson added the comment:
> (And applying the same change to bytes.splitlines.)
Oh, and bytearray.splitlines, too.
--
___
Python tracker
<http://bugs.python.org/issu
Mark Dickinson added the comment:
Here's a patch.
--
keywords: +patch
Added file: http://bugs.python.org/file23208/issue13012.patch
___
Python tracker
<http://bugs.python.org/is
Changes by Mark Dickinson :
--
stage: needs patch -> patch review
___
Python tracker
<http://bugs.python.org/issue13012>
___
___
Python-bugs-list mai
Changes by Mark Dickinson :
--
components: +ctypes
___
Python tracker
<http://bugs.python.org/issue13013>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
> Mark: I disagree ...
Okay, I misunderstood. I thought you were still talking about the unlabelled
balls in labelled boxes problem, which is an isomorphic problem to that solved
by combinations_with_replacement.
It looks as though you're now wide
Changes by Mark Dickinson :
--
components: +Interpreter Core
title: Resource is not released before returning from the functiion ->
bytearrayobject.c: Resource is not released before returning from the functiion
___
Python tracker
&l
Mark Dickinson added the comment:
Okay, all fixed here. Let's add any further signed overflow issues to the
issue #1621 discussion.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.
Mark Dickinson added the comment:
Thanks for the reviews.
Applied the first patch, plus Misc/NEWS entry, and minus the change to
Lib/collections/__init__.py; I think that change belongs more with the second
patch.
--
___
Python tracker
<h
Mark Dickinson added the comment:
Resetting versions.
--
versions: +Python 3.3 -Python 2.6, Python 3.1
___
Python tracker
<http://bugs.python.org/issue1
Mark Dickinson added the comment:
Clang has an -ftrapv option that seems to be less buggy and more complete than
gcc's. Compiling and running the test suite with that option enabled looks
like a good way to catch a lot of these signed over
Mark Dickinson added the comment:
Ezio's patch looks fine to me, though as Meador points out in the Rietveld
review, there are a couple of omissions that could be fixed.
Personally, I'm not so convinced of the value of upgrading all the existing
uses of splitlines to use 'kee
Mark Dickinson added the comment:
> don't apply any of the resulting changes to the maintenance releases,
> and target the issue only for 3.3.
That sounds fine to me, though if we find more instances of signed overflow
that actually trigger test failures in the maintenance branche
Mark Dickinson added the comment:
> This is mathematically wrong ...
No, it's not 'mathematically wrong'. There are many different rounding
conventions in use, and no single universally agreed convention for rounding
halfway cases. Python chooses to use unbiased round
Changes by Mark Dickinson :
--
type: -> feature request
versions: +Python 3.3 -Python 3.2
___
Python tracker
<http://bugs.python.org/issue13060>
___
___
Py
Mark Dickinson added the comment:
Classifying this as a feature request: the behaviour of round isn't going to
change here, but there might be community support for adding a mechanism for
round to allow other rounding modes. It might be worth taking this to the
python-ideas mailing li
Mark Dickinson added the comment:
> maybe there should be a warning in the 2.7 documentation
Well, such a warning really belongs in the Python 3 documentation rather than
the Python 2 documentation. (Or at least, AFAIK that's the convention that's
been followed to date: the
Changes by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue13061>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
See issue #3163.
--
___
Python tracker
<http://bugs.python.org/issue13098>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Mark Dickinson :
--
assignee: mark.dickinson ->
___
Python tracker
<http://bugs.python.org/issue3163>
___
___
Python-bugs-list mailing list
Un
Mark Dickinson added the comment:
Hi,
You're proposing a change to the core language and syntax; the bug-tracker's
not really appropriate for this---it's better suited for small, focused changes
(preferably with patches!). I suggest that you start a thread on the
python-ide
Mark Dickinson added the comment:
I meant to include a link to the mailing list:
http://mail.python.org/mailman/listinfo/python-ideas
--
___
Python tracker
<http://bugs.python.org/issue13
Changes by Mark Dickinson :
--
assignee: -> rhettinger
___
Python tracker
<http://bugs.python.org/issue13121>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Mark Dickinson :
--
type: behavior -> feature request
___
Python tracker
<http://bugs.python.org/issue13121>
___
___
Python-bugs-list mailing list
Un
Mark Dickinson added the comment:
I'm warming to this idea.
We already have several round-to-integer functions (but not
round-to-an-arbitrary-number-of-decimal-places) available in the math module
(under the names floor, ceil and trunc). This *does* seem to be a common need,
and it&#
Mark Dickinson added the comment:
Fixed. Thanks for the report!
--
nosy: +mark.dickinson
resolution: -> fixed
status: open -> closed
versions: +Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.org/i
Changes by Mark Dickinson :
--
assignee: docs@python -> mark.dickinson
___
Python tracker
<http://bugs.python.org/issue13145>
___
___
Python-bugs-list mai
Changes by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue13200>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Mark Dickinson :
--
components: +Interpreter Core
nosy: +mark.dickinson
stage: -> patch review
type: -> feature request
versions: +Python 3.3
___
Python tracker
<http://bugs.python.org/i
Mark Dickinson added the comment:
Nice patch! I put some comments on Rietveld.
--
___
Python tracker
<http://bugs.python.org/issue13201>
___
___
Python-bug
Changes by Mark Dickinson :
--
assignee: -> mark.dickinson
___
Python tracker
<http://bugs.python.org/issue13201>
___
___
Python-bugs-list mailing list
Un
Mark Dickinson added the comment:
The new patch looks fine; I'd still like to have the more explicit reference
counting in range_hash (see replies on Rietveld).
A few more things:
- The patch needs a Misc/NEWS entry before committing; it probably deserves a
line in Doc/whatsnew/3.
Mark Dickinson added the comment:
Your 'i = i + 1' is at the wrong indentation level.
--
nosy: +mark.dickinson
resolution: -> invalid
status: open -> closed
___
Python tracker
<http://bugs.py
Mark Dickinson added the comment:
I get a test failure in test_hash (which is checking exactly that the
hash(range) uses the default object hash, so that test is clearly out of date
now). Apart from that, the latest patch looks good to me.
I'm going to give this a couple of days in
Changes by Mark Dickinson :
--
stage: needs patch -> patch review
___
Python tracker
<http://bugs.python.org/issue9574>
___
___
Python-bugs-list mailing list
Un
Mark Dickinson added the comment:
What about
def total_minutes(td):
return td / datetime.timedelta(minutes=1)
?
--
___
Python tracker
<http://bugs.python.org/issue5
Mark Dickinson added the comment:
I've taken the liberty of updating the patch, with a few minor changes:
range_equality -> range_equals (like range_contains)
move identity check into range_equals
move comments before the code they describe (PEP7)
add whatsnew entry
remove check th
Mark Dickinson added the comment:
Hmm. Why does my patch not get a 'review' button?
--
___
Python tracker
<http://bugs.python.org/issue13201>
___
___
Mark Dickinson added the comment:
Ah, there it is. Never mind. :-)
--
___
Python tracker
<http://bugs.python.org/issue13201>
___
___
Python-bugs-list mailin
Mark Dickinson added the comment:
Thanks for the comments. Here's an updated patch, that actually makes use of
the pure Python version to test the built-in int-to-float conversion.
--
versions: -Python 2.7, Python 3.2
Added file: http://bugs.python.org/file
Mark Dickinson added the comment:
> In most cases, global variables Py_Zero and Py_One would be enough to
> simplify this kind of code.
Agreed.
--
___
Python tracker
<http://bugs.python.org/i
Changes by Mark Dickinson :
--
resolution: -> fixed
stage: commit review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
101 - 200 of 6463 matches
Mail list logo
