Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Closing: Christian merged the trunk-math branch into the trunk in
r62380.
--
resolution: -> accepted
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs
New submission from Mark Hammond <[EMAIL PROTECTED]>:
As per a thread on python-dev, I offered to add sys.iswow64process. I'm
attaching a patch that does this (including news, docs and tests). I'm
adding Martin to the nosy list as he has expressed reservations ("It
sound
Mark Hammond <[EMAIL PROTECTED]> added the comment:
Checked in as r62636
--
resolution: -> fixed
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
I've made some progress here: I have a version of decimal.py for
Python 3.0 that uses a Deccoeff instead of a string for the Decimal
coefficient. It still needs a little work to make things efficient,
but it already passes all t
New submission from Mark Dickinson <[EMAIL PROTECTED]>:
In Python 3.0, the Decimal __round__, __ceil__ and __floor__ functions
don't work as intended: they all return 1, 0, or -1.
This is easy to fix. The only reason I'm making an issue (literally) of
it is that I remember so
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
I've removed __round__, __ceil__ and __floor__ in r62669; the code was
undocumented, untested and just plain wrong, so there doesn't seem to be
any point in leaving it in. (I'm not quite sure how it got there in the
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Here's a patch that implements __ceil__, __floor__ and __round__. (It
seems that just removing __ceil__, __floor__ and __round__ is not an
option, as I just discovered when r62669 turned all the buildbots red.)
Points to not
Mark Hammond <[EMAIL PROTECTED]> added the comment:
I'm not sure if that is suggesting MS had no reason to add that API
function, or those reasons don't apply to users of Python, but as its
clear there is significant resistance I'm rejecting this report.
--
res
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Here's a revised patch, with the following changes
- no keyword arguments to round
- check that the second argument to round is an integer.
Added file: http://bugs.python.org/file10188/decimal_ceilf
New submission from Mark Veldhuis <[EMAIL PROTECTED]>:
I changed module A, and then tested module B that imported module A. it
took a while to realise that what went wrong was that the change had not
registered in module B, even when I closed and reopened the window, the
shell etc. I had t
Changes by Mark Veldhuis <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10190/idleupdatebug.odt
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Mark Veldhuis <[EMAIL PROTECTED]>:
Added file: http://bugs.python.org/file10191/idleupdatebug.odt
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
New submission from Mark Summerfield <[EMAIL PROTECTED]>:
The new method float.is_integer() introduced in Py30a5 behaves unexpectedly:
>>> x = 5.0
>>> x.as_integer_ratio()
(5, 1)
>>> x.is_integer()
Traceback (most recent call last):
File "", lin
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Thanks for reviewing this, Raymond!
Committed, r62938.
--
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.py
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Is this on Windows? I can't reproduce it on OS X 10.5.2:
Python 3.0a5+ (py3k:62937M, May 9 2008, 09:32:27)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or &q
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
This should be fixed in r62938. Mark, can you confirm?
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
That should be r62939, not r62938. Sorry.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2801>
__
__
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
--
assignee: -> marketdickinson
priority: -> normal
__
Tracker <[EMAIL PROTECTED]>
<http://bugs
New submission from Mark Summerfield <[EMAIL PROTECTED]>:
In Py30a5 the 'n' format option is not v. useful for integers:
>>> for x in range(8):
print("{0:n} ".format(10**x), end="")
1 10 100 1,000 10,000 100,000 1e+06 1e+07
This is
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> I think that n should stay the same for floats, but for integers should
> never switch to g, but just use as many separators as needed.
I agree with this, in principle. It might be some work to implement,
though: for floats,
Mark Summerfield <[EMAIL PROTECTED]> added the comment:
On 2008-05-09, Mark Dickinson wrote:
> Mark Dickinson <[EMAIL PROTECTED]> added the comment:
>
> Is this on Windows? I can't reproduce it on OS X 10.5.2:
>
> Python 3.0a5+ (py3k:62937M, May 9 2008, 09:32:27
Mark Summerfield <[EMAIL PROTECTED]> added the comment:
On 2008-05-09, Mark Dickinson wrote:
> Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> > I think that n should stay the same for floats, but for integers should
> > never switch to g, but just use as many
Mark Summerfield <[EMAIL PROTECTED]> added the comment:
OK, I've just built against your fix and it works fine now!
Python 3.0a5+ (py3k:60668:62940, May 9 2008, 15:48:15)
[GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] on linux2
Type "help", "copyright", "credit
Mark Summerfield <[EMAIL PROTECTED]> added the comment:
On 2008-05-09, Eric Smith wrote:
> Eric Smith <[EMAIL PROTECTED]> added the comment:
>
> The reason for this is that 'n' is defined in PEP 3101 as being a float
> format only, and the rule is that if
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> As to the implementation, the OS supplied float formatting does not add
> thousands separators. I added the function add_thousands_grouping() to
> Python/pystrtod.c in order implement this for floats.
Excellent! I didn
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Thanks, Mark.
I've also backported the fix to the trunk in r62943.
--
resolution: -> fixed
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http:/
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
I've committed a (slightly reworked) version of this patch in r62948.
Closing this issue; the problem with 1 >> 2**31 is a separate issue.
Thanks for the report, Fredrik.
--
resolution: -> fixed
st
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
I'm actually pretty happy with the tables the way they are; everything's
working at the moment, and the current code seems clear enough.
Do you have a strong reason to want this change?
__
New submission from Mark Dickinson <[EMAIL PROTECTED]>:
In Python 2.6a3:
>>> 1 >> (2**31) # unexpected exception
Traceback (most recent call last):
File "", line 1, in
OverflowError: long int too large to convert to int
>>> 1 >> (2**31-1) #
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> On the second thought, it is theoretically possible to have a long int
a
> for which a >> maxsize is not zero
This occurred to me too; somehow this hardly seems worth worrying about-
--there are already other problems in
Mark Summerfield <[EMAIL PROTECTED]> added the comment:
Unfortunately, this bug appears to affect Py30a5 too (at least on Win XP
Home):
Python 3.0a5 (py3k:62932M, May 9 2008, 16:23:11) [MSC v.1500 32 bit
(Intel)] on win32
IDLE 3.0a5
>>> import sqlite3
Traceback (most r
New submission from Mark Summerfield <[EMAIL PROTECTED]>:
#Python 3.0a5 (py3k:62932M, May 9 2008, 16:23:11) [MSC v.1500 32 bit
#(Intel)] on win32
#
# If you run this tiny program on Linux and press Alt+F (Alt-f in Tk
# terminology) the File menu pops up as expected. But run it on
# W
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
I'm not sure I understand. What rule would be broken by this patch?
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
It's the current behaviour that seems arbitrary to me: a >> b is well-
defined, and efficiently computable, for any integer a and nonnegative
integer b; it seems odd to have an unnecessary and (from a user's
viewpoi
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Fair enough. Closing as won't fix.
--
resolution: -> wont fix
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http:/
Mark Veldhuis <[EMAIL PROTECTED]> added the comment:
Hi,
I repeated the same steps as before, with new filenames, and with the
same result, the printed value was 1, and not 2 as expected. After
closing all windows the value was 2.
answers to Kurt's questions:
When you "ope
Changes by Mark Veldhuis <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10191/idleupdatebug.odt
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Some comments/questions:
(1) It seems wasteful to wrap every addition in PyFPE_START/END_PROTECT,
and to check for NaNs and infinities after every addition. I'd wrap the
whole thing in a single PyFPE_START/END_PROTE
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
One more question:
What are the use cases for an exact summation algorithm? That is, in what
situations does one care about exactness rather than simply accuracy? I
know that loss of accuracy is a problem in things like n
New submission from Mark Summerfield <[EMAIL PROTECTED]>:
There appears to be an infinite recursion in Py30a5 (doing the same
thing in Py2.5.1 works fine):
Python 3.0a5 (r30a5:62856, May 9 2008, 11:23:06)
[GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] on linux2
Type "copyright&quo
Mark Summerfield <[EMAIL PROTECTED]> added the comment:
I get the same bug on Fedora 8 (Python build 63161) and Kubuntu 8
(official Py30a5 release)---but not on Windows XP Home where the URL is
opened correctly.
Python 3.0a5+ (py3k:60668:63161, May 12 2008, 14:46:40)
[GCC 4.1.2 2007092
Mark Summerfield <[EMAIL PROTECTED]> added the comment:
On 2008-05-12, Amaury Forgeot d'Arc wrote:
> Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
>
> The traceback suggest a problem when using KDE: a call to file() was
> renamed to open(),
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> One related issue is testing these, how can a NaN and +/-Infinity
> float object be created in Python?
In 2.6 and 3.0 (but not 2.5 and older), float('nan'), float('inf') and
float('-inf') should
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3439>
___
___
Python-bugs-list mailing list
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Accidentally removed the following message from Victor Stinner;
apologies. (Time to turn off tap-to-click on my trackpad, methinks.)
> See also issue #3724 which proposes to support long integers for
> math.log2().
One oth
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
One more minor deficiency in the patch: it gives incorrect results for
very large integers. For example, on a 32-bit build of the trunk:
>>> x = 1 << 2**31-1
>>> x <<= 2**31-1
>>> x.numbits()
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Note that log2(int) -> float wouldn't entirely replace
numbits, due to loss of precision in the result.
e.g. log2(2**100), log2(2**100+1) and log2(2**100-1) would likely all
return exactly the same result (100.0), where
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> Guido's patch breaks these tests:
>
> test_descr test_hash test_long test_richcmp test_set
It looks like all these are easily fixed: all these tests were making
outdated assumptions and needed updating.
Here's
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Presumably any nonzero entries for tp_compare in type initializers
should be looked at closely, as well?
I see nonzero tp_compare entries in:
Modules/_tkinter.c
Modules/parsermodule.c
Objects/cellobject.c
Objects/descrobject.
Mark Tsuchida <[EMAIL PROTECTED]> added the comment:
There are two symptoms here, each caused by a different bug.
Neither is specific to IDLE; they have to do with Tkinter recognizing
the correct Tcl/Tk installation at build time and run time.
Bug 1: The Python 2.6 binary installer a
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
This is not a bug, at least in the sense that the behaviour of Python
2.6 is intentional: asin has branch cuts from 1 to infinity and -1 to -
infinity along the real axis. As explained by the note at the top of
the cmath documentati
Mark Hammond <[EMAIL PROTECTED]> added the comment:
> I'm skeptical about adding build_data support, as it's not
> obvious what files would need conversion.
All .py files should be converted. I can't think why a project would
use this 2to3 capability for script
Mark Hammond <[EMAIL PROTECTED]> added the comment:
Thinking more about data_files, I'd agree that blindly converting all
.py files and nothing more isn't as useful for install_data as the other
commands. It might make more sense to allow data_files to specify a
list of patte
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> sihpc03:Python-2.6 anand$ ./configure --with-framework-name=Python64 --
> with-universal-archs=all --enable-framework --enable-
> universalsdk=MACOSX_DEPLOYMENT_TARGET=10.5
I think you want --enable-universalsdk=/ MACOSX_DE
Mark Hammond <[EMAIL PROTECTED]> added the comment:
I don't see a problem with this and can see how it would help with
private assemblies.
--
nosy: +mhammond
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Mark Hammond <[EMAIL PROTECTED]> added the comment:
I can see how this might be useful, but I agree it should not happen by
default, at least until it has been out for a while and feedback is
clear that people do want it by default.
I'd also like to find a way to pass all args, n
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
The test_math failure may well be due to a libm bug: tanh(-0.0)
might be incorrectly (judging by the BSD man pages) dropping the negative
sign from the negative zero.
In the output of ./configure, there should be a line that look
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
In addition, the description of binary literals is missing from the
lexical analysis section of the reference manual, as is the description
of new-style octal literals (i.e. "0o23" instead of "023").
Here's a
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Here's an updated patch, with the following changes from the original:
- make the size of a digit (both the conceptual size
in bits and actual size in bytes) available to Python
via a new structseq sys.int_info. This informatio
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
I've opened a separate issue (issue 4258) for the idea of using 30-bit
long digits instead of 15-bit ones. I'll remove the patch from this
issue.
Pernici Mario's idea applies even better to base 2**30 longs: one
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file11724/30bit.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Note that to avoid "bad marshal data" errors, you'll probably need to do a
'make distclean' before rebuilding with this patch.
___
Python tracker <[EMAIL PROTECTED]&
New submission from Mark Dickinson <[EMAIL PROTECTED]>:
Here's an experimental patch, against the py3k branch, that makes Python
represent its long integers internally in base 2**30 instead of base
2**15, on platforms that have 32-bit and 64-bit integers available.
On platform
New submission from Mark Seaborn <[EMAIL PROTECTED]>:
compile() raises a SyntaxError if the source code it is given contains
trailing spaces or a trailing carriage return character, but this does
happen if the same source code is imported or executed.
import subprocess
data = "if Tr
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
[Victor Stinner]
> I saw that you choosed to use the base 2^30 for marshal. For a better
> portability (be able to use .pyc generated without your patch), you
> may keep the base 2^15. I implemented that in my GM
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Following Victor's suggestion, here's an updated patch; same as before,
except that marshal now uses base 2**15 for reading and writing,
independently of whether PyLong_SHIFT is 15 or 30.
Added file: http://bugs.pyth
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> Yes, it uses base 2**15 but it's not the correct conversion to base
> 2**15. You convert each PyLong digit to base 2**15 but not the whole
> number.
I don't understand: yes, each base 2**30 digit is converted
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Other responses...
> It was an argument for changing the base used by the mashal :-)
Ah. I think I'm with you now. You're saying that ideally, marshal
shouldn't have to care about how Python stores its longs:
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
Added file: http://bugs.python.org/file11950/pybench_results.txt
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Here's a pybench comparison, on OS X 10.5/Core 2 Duo/gcc 4.0.1 (32-bit
non-debug build of the py3k branch). I got this by doing:
[create clean build of py3k branch]
dickinsm$ ./python.exe Tools/pybench/pybench.py -f bench_unpat
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Here's a minor update to the patch, that does some extra cleanup:
- don't include longintrepr.h in Objects/abstract.c or
Objects/boolobject.c --- it's not needed.
- fix several places in longobject.c where int should
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Another thought: macros that are going to be used elsewhere in Python
(like the way you're using PyLong_SIGN in mathmodule.c) would probably
be better off in longobject.h. The fewer places there are that have to
include lo
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> Same: it's better to write a separated patch.
Agreed.
Unfortunately, I think all of this is going to have to wait for Python
3.0 to be released before we can consider committing anything. The
first step is to commit the
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Interesting.
Incidentally, I'm already using sdigit for the signed version of digit---
this seems to fit with the current digit/twodigits/stwodigits typedefs.
What's the purpose of your sdigit? Do you really want it
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
There are so many things going on here it's getting difficult to keep
track of them all! Not only Victor's stuff, but also Mario's patches
for faster multiplication, and for subquadratic division. And it mig
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
This is indeed interesting. For what it's worth, I think
the Python 3.0 behaviour is the right one, here. Perhaps
it's worth adding a test to Python 3.0 to make sure that
this behaviour doesn't accidentally disappear
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
[Raymond]
> assuming basic invariants. In 2.6, all of the following are always
> true:
>
> assert a in [a]
> assert a in (a,)
> assert a in set([a])
> assert [a].count(a) == 1
And these are all still true
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Here's a version of the 15-bit to 30-bit patch
that adds in a souped-up version of Mario Pernici's
faster multiplication.
I did some testing of 100x100 digit and 1000x1000 digit
multiplies. On 32-bit x86:
100 x 100 digi
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> Taking it out probably had something to do with NaNs, but this
> discussion needs to avoid getting lost in NaN paradoxes and instead
> focus on a notion of membership that is ALWAYS true given object
> identity. Th
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Hi, Victor! Thanks for the updated patch.
Your patch still hangs on:
>>> from sys import maxint
>>> (-maxint-1).numbits()
on my 32-bit machine.
___
Python tracker &
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
One more data point: in both 2.x and 3.x, sets behave like the 2.x
lists:
Python 3.0rc2+ (py3k:67177M, Nov 10 2008, 16:06:34)
[GCC 4.0.1 (Apple Inc. build 5488)] on darwin
Type "help", "copyright", "
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Here's a patch incorporating Christian's tests, the missing lines from
PyObject_RichCompareBool, and some additional tests to check that
[x] == [x] and the like remain True even when x is a NaN. Oh, and a
Misc/NEWS entry.
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
See issue 4258 for a patch that combines 30-bit digits with
this multiplication optimization. The code is quite different
from the patch posted here, but the basic idea is the same.
___
Python t
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
With the lines Raymond mentions restored, all tests (including the extra
tests Christian's posted here) pass for me, and I also get:
>>> a = [float('nan')]
>>> a == a
True
Incidentally, it looks as th
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
[Michael]
> the real issue that caused problems [...] was Python deciding to
> silently cast NaN falues to 0L
> [...]
> it sounds like there is no intention to fix this for versions prior
> to 3.0,
Oh, ! Guido'
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
The latest patch from Victor looks good. A few comments:
(1) the number of bits should be computed first directly using C
arithmetic, and only recomputed using PyLong arithmetic if the C
computations overflow. For one thing, overf
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file11989/issue4296.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> Before committing, please add one
> other test that verifies the relationship between "in" in membership
> tests and "in" in a for-loop:
Added. (To test_contains, since this seems like a more appropri
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
You're mixing tabs and spaces in your code.
The 'if f_p > largest' line occurs one indentation level further out
than the preceding print.
--
nosy: +marketdickinson
resolution: -> inv
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Committed, r67204. Thanks guys, and thanks especially to Michael for
spotting this before 3.0 final.
--
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Is it be feasible to add arithmetic operations
to the ctypes integer types? Since ctypes is now
in the core, it would seem better to enhance ctypes
than provide a new module.
I think this would be valuable for rapid prototyping
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> I think in 2.6 we can't change this,
I'm not sure when it happened, but it looks like this
*was* fixed for 2.6.
Closing.
--
nosy: +marketdickinson
resolution: -> fixed
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> timedelta / should be disallowed in true division mode.
I don't understand this; why should the division mode affect
division operations involving timedeltas at all? The meaning
of "/" is unaffected by the divis
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
By the way, I assume that any plan to add this division would also include
adding the inverse operation:
timedelta * float -> timedelta.
It wouldn't make a whole lot of sense to have one wit
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
[Christian]
> float(td1) / float(td2) which is far more obvious than td1 / td2
To me, td1/td2 is more obvious that float(td1)/float(td2).
float(td) involves an arbitrary choice, to return time in *seconds*
(rather than
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
The bug is that the set operations return instances of the subclass,
rather than instances of set.
This is already fixed for 3.0: see issue 1721812. It was deemed too risky
to backport the change to 2.x.
--
assignee: t
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
This request has come up repeatedly (and been rejected) in the past. See
issues 2954, 3374, 1185383, 1462228, 1451588, 1619060.
Could you perhaps explain your particular use case for this? A few truly
convincing use-cases might in
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
What about cases where performance is unimportant, or where the key
function is fast (e.g. an attribute access)? Then something like
bisect(a, x, key=attrgetter('size'))
is easy to write and read. Mightn't this be c
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
One case I've been thinking about is that of maintaining a list of Decimal
objects that are sorted by absolute value. For this, having to create a
list of (abs(x), x) pairs just seems clumsy compared to using a key
argumen
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Looks good. Thanks, Raymond.
Minor typos: "numberic" -> "numeric"
"the expression ``x in y`` equivalent to" ->
"the expression ``x in y`` is equivalent to"
2401 - 2500 of 12223 matches
Mail list logo
