Mark Dickinson <[EMAIL PROTECTED]> added the comment:
There's also the recursive division algorithm due
to Burnikel and Ziegler; this might be worth a look.
I think it's the same asymptotic complexity (constant
times karatsuba multiplication complexity), but may
turn out to b
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Closing this as a duplicate; it's superseded by issue 3451.
--
resolution: -> duplicate
status: open -> closed
superseder: -> Asymptotically faster divmod and str(long)
__
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
See also issue 1746088.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3451>
___
__
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Here's a pure Python implementation of the Burnikel and Ziegler recursive
division algorithm. I've no idea whether it's faster or slower than
Newton, but it might be worth a look. It depends heavily on bit
operatio
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Oops. Wrong file. Here's the right one.
Added file: http://bugs.python.org/file11060/fast_div.py
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file11059/fast_str.py
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
New patch committed, r65518. Conversion of a nan to an integer now raises
ValueError consistently across platforms.
--
status: open -> closed
___
Python tracker <[EMAIL PROTE
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Mike,
Can you propose an implementation, for those platforms that haven't yet
caught up with C99? Something comparable to the implementation of log1p
in Python/pymath.c would be appropriate. Ideally, such an
implementation w
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
A cheap trick would be to use the identity
expm1(x) = 2*exp(x/2)*sinh(x/2)
This could also be used in Python as a
workaround, for now. But I agree that
expm1 should go into the math l
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
The behavior of range is very unlikely to be changed in Python 2.x, for
backwards compatibility reasons.
But it's a great idea! So great, in fact, that it's already been
implemented for Python 3.0. :-) There range(
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
By the way, do you already know about xrange?
xrange([start,] stop[, step]) -> xrange object
Like range(), but instead of returning a list, returns an object that
generates the numbers in the range on demand. For looping, this is
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> Sadly so high numbers are longs and xrange seems to get an integer.
Something like that, yes: the start, step and length of an xrange object
are stored internally as C longs (just as Python ints are), and this is
unlikely
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> I believe the conn refused error is another race, the child processes
> are connecting to a manager which is shutting down/gone
After some research, I think it actually has to do with the value of the
'backlog' par
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Here's what's going on with the incref error:
Look in the Server class, in managers.py: consider a shared object with
id 'id'. When a reference to the shared object is created, its id is
added to the id_to_refco
New submission from Mark Dickinson <[EMAIL PROTECTED]>:
The BaseManager.from_address method is documented at:
http://docs.python.org/dev/library/multiprocessing.html#multiprocessing.ma
nagers.BaseManager.from_address
but it looks as though this method doesn't actually exist. In con
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Hmmm. That last message wasn't too coherent; I really shouldn't try to
post at 2:30am.
Summary: the refcounting logic in the Server class is flawed. In
Server.create(), the initial refcount of a newly-created shared o
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Adding Richard Oudkerk to the nosy list in case he can shed any light on
this.
Should this be considered a release-blocker?
--
nosy: +roudkerk
___
Python tracker <[EMAIL PROTECTE
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
--
assignee: -> marketdickinson
components: +Extension Modules -None
priority: -> normal
versions: +Python 2.7, Python 3.1 -Python 3.0
___
Python tracker <[EMAIL PROTECTED]>
<h
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> Indeed, that seems to be much faster. In the mean time, do you mind if I
> steal the code? :-)
Not at all!
I guess constant factors could well appear and/or disappear when
recoding in C; it might well be worth trying to im
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> So rather than use a static list, I switched the code to use the
> errno module.
Yup. That's definitely a better solution.
Your patch fixed the problem for me.
Thanks!
___
Pytho
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
With the patch, the following code causes a
non-keyboard-interruptible interpreter hang.
>>> from sys import maxint
>>> (-maxint-1).numbits()
[... interpreter hang ...]
The culprit is, of course, the statement
if
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
One possible fix would be to compute the absolute value
of n as an unsigned long. I *think* the following is
portable and avoids any undefined behaviour coming
from signed arithmetic overflow.
unsigned long absn;
if (n < 0)
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Here's a patch, in final form, that replaces fsum with an lsum-based
implementation. In brief, the accumulated sum-so-far is represented in
the form
huge_integer * 2**(smallest_possible_exponent)
and the huge_integer is store
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10988/fsum7.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file11008/fsum8.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file11014/fsum10.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Here's a patch that fixes the incref problem for me. This *definitely*
needs review from someone more familiar with the multiprocessing module
than I am; I'm not at all confident that it won't break something else.
New submission from Mark Dickinson <[EMAIL PROTECTED]>:
Here's a report from Ismail Donmez (cartman), extracted from the
issue 3419 discussion in an effort to avoid putting multiple
problems under one tracker issue.
[cartman]
With trunk when running test_multiprocessing in a tight
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
[jnoller]
> As for if this should block the release, it should be resolved before
> final, but should not block the next beta.
So the priority should be 'deferred blocker', no?
[cartman]
> With trunk when running
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Thanks for the patch, George!
This patch fixes the problem in some, but not all cases. I'd like to take
this a little further.
As far as I can see, getting correctly rounded results in all cases is out
of reach without eit
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Hit submit too soon; sorry...
But it would be reasonable to aim for correctly rounded results when the
second argument to round is not too large (less than 22 in absolute
value, for example), so that 10**abs(n) is exactly representa
New submission from Mark Dickinson <[EMAIL PROTECTED]>:
On a 64-bit OS X build of Python, built with:
./configure --with-universal-archs=64-bit --enable-universalsdk=/
MACOSX_DEPLOYMENT_TARGET=10.5 &&
make
I get the following result:
Python 2.6b2+ (trunk:65805M, Aug 18 2008, 1
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
It turns out that uid_t (and gid_t) actually *is* an unsigned 32-bit
integer type on OS X 10.5, so perhaps the pw_uid and pw_gid values are
correct. So to rephrase: one or both of the following facts might be
considered bugs:
(1
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Issue 1747858 looks closely related. I propose extending the simple fix
used there, parsing all uids and gids as longs rather than ints.
___
Python tracker <[EMAIL PROTECTED]>
<http://
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> In every case I can think of, I've wanted (0).numbits() to be 0.
Me too, in most cases, though I've encountered the occasional case where
raising ValueError would be more appropriate and would catch some bugs
that m
New submission from Mark Summerfield <[EMAIL PROTECTED]>:
When the attached program is run on Linux it runs "instantly" and
outputs one line, e.g.:
$ python3 mtest.py
100 files, 1702627142 bytes
(The number of bytes will vary depending on the system.)
When run on Windows XP th
Mark Summerfield <[EMAIL PROTECTED]> added the comment:
On 2008-08-19, Antoine Pitrou wrote:
> Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
>
> For what it's worth, this is documented in
> http://docs.python.org/dev/library/multiprocessing.html#windows
Mark Summerfield <[EMAIL PROTECTED]> added the comment:
On 2008-08-19, Antoine Pitrou wrote:
> Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
>
> Fixed in r65860. Someone should check the docs though (at least try to
> generate them, and review my changes a bi
Mark Summerfield <[EMAIL PROTECTED]> added the comment:
On 2008-08-19, Antoine Pitrou wrote:
> Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
>
> Fixed in r65860. Someone should check the docs though (at least try to
> generate them, and review my changes a bi
New submission from Mark Hammond <[EMAIL PROTECTED]>:
A number of tests are designed to be skipped on 64bits, but they don't
detect 64bit windows builds as 64bits. Also, test_bytes.test_repeat()
assumes sys.maxint bytes can't be allocated, which isn't necessarily
true on Wi
Changes by Mark Hammond <[EMAIL PROTECTED]>:
--
nosy: +mhammond
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3617>
___
___
Python
Mark Hammond <[EMAIL PROTECTED]> added the comment:
Obviously IANAL, but my reading of eula.txt included with VS9 seems less
restrictive than the 2003 one. It has 2 clauses that seem relevant:
* [you must] require distributors and external end users to agree to
terms that protect it at
New submission from Mark Summerfield <[EMAIL PROTECTED]>:
When I try to run IDLE in Py30b3 I get a traceback, then the main window
appears with an error message box and an OK button; once I click OK,
IDLE goes away.
$ ~/opt/python30b3/bin/idle
Traceback (most recent call last):
File &q
New submission from Mark Summerfield <[EMAIL PROTECTED]>:
Here are the results of running the same tiny program against 2.5.2,
30b2, and 30b3. The program creates a regex and tries to match 3
strings. For 2.5.2 and 30b2 this works fine; for 30b3 the regex won't
even compile:
$ pytho
Mark Summerfield <[EMAIL PROTECTED]> added the comment:
Just realised how to fix this. Change line 76 in idlelib/run.py:
# change this:
sockthread.set_daemon(True)
# to this:
sockthread.daemon = True
and IDLE runs fine.
___
Python tracker &
Mark Hammond <[EMAIL PROTECTED]> added the comment:
MAL:
> This was already discussed on the PSF members mailing list.
Yeah, but not specifically about VS2008 which this bug seemed to be
specifically targetting. FWIW, this appears like *less* of a problem
for 2.6 than for 2.4 and
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
I'll take a look, though if anyone has some time to spare and access to a
Solaris machine then they can probably figure this out more quickly.
The first step would be to fix the test so that it at least shows which
input the fai
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Here's a patch for the test-suite to get more information about where
float.fromhex is failing. Could someone else please review this quickly
so that I can check it in? It shouldn't take more than a few mi
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
--
keywords: +needs review
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3419>
___
_
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Thanks, Benjamin! Change to test committed in r65958, merged to py3k in
r65959. Time to watch the py3k solaris buildbot.
--
keywords: -needs review
___
Python tracker <[EMAIL PROTECTE
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
This should be changed in 2.6 as well (from sockthread.setDaemon(True) to
sockthread.daemon = True).
By the way, I notice that there are also used of setDaemon, isDaemon,
getName and setName in Lib/multiprocessing/dummy/__init__.py;
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
The problem appears to be that on Solaris, the isxdigit function (which
is supposed to check whether a character is a valid hex digit) returns
true for Unicode fullwidth digits. On other systems I have access to,
isxdigit just r
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Here's a patch. I'm reasonably confident that this should fix the
problem, but I don't have a Solaris machine to test it on.
If anyone can check this on Solaris that would be fantastic, but I'll
settle for
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
...and here's the actual patch!
Added file: http://bugs.python.org/file11199/issue3633.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
--
keywords: +needs review
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3633>
___
_
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Thanks, Antoine. Committed, r65964 (2.6) and r65965 (3.0). Setting
status to pending; will close if/when the Solaris buildbot goes green.
--
resolution: -> fixed
status: open -
New submission from Mark Hammond <[EMAIL PROTECTED]>:
[from python-dev]
I've found a recursion related crash in test_cpickle on 64bit builds.
Specifically, the 'cPickleDeepRecursive' is causing a stack overflow,
and the debugger tells me the actual recursion depth was 6
Changes by Mark Hammond <[EMAIL PROTECTED]>:
--
assignee: -> mhammond
keywords: +64bit
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Mark Hammond <[EMAIL PROTECTED]> added the comment:
I forgot about sys.maxsize - that makes things much cleaner, and even
means I don't need to skip the check for insane amounts of memory.
If you think this is OK, please also specifically say if you approve for
me to check it into tr
Mark Hammond <[EMAIL PROTECTED]> added the comment:
It looks like I made a dupe at http://bugs.python.org/issue3625, where I
reported the same thing on 64bit windows (and 2 other cases that I'd be
interested to know if cause problems for you too...)
--
nosy
Mark Hammond <[EMAIL PROTECTED]> added the comment:
Thanks. Checked into the trunk in r65986
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Mark Hammond <[EMAIL PROTECTED]> added the comment:
Sorry for the initial noise - your analysis is correct, mine was flawed
:) Simple recursion to a depth of 1000 does work fine on a 64bit build.
cpickle.patch does make test_cpickle pass for me. FWIW,
find_recursionlimit.py now ca
Changes by Mark Hammond <[EMAIL PROTECTED]>:
--
nosy: +mhammond
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3566>
___
___
Python
Mark Hammond <[EMAIL PROTECTED]> added the comment:
I stumbled across this when mimetools import of test failed due to
finding a local test package, not the python test package, so I too will
be happy to see this fixed.
--
nosy: +mhammond
___
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
I can't really see a compelling reason to make this change---it
seems like an unnecessary complication to add to what's currently
a simple function. Someone who really needs the accuracy can
just use log10. Perha
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
It's possible that this patch would cause breakage on other systems:
there's a reason that errno is currently ignored, which is that it can't
be trusted on all systems (notably Linux: on one Linux system I'
New submission from Mark Hammond <[EMAIL PROTECTED]>:
It appears r66103 introduced a regression - file objects are treated as
having an encoding, so non-ascii data fails. It was further complicated
by the fact that file objects in 2.6 have an 'encoding' attribute, but
by default
Changes by Mark Hammond <[EMAIL PROTECTED]>:
Added file: http://bugs.python.org/file11370/logging_encoding.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> Do we want to mention it in the tutorial? If not,
> this issue could now be closed.
I think it might be worth mentioning both this and float.hex in the
tutorial---it would fit well into the floating-point issues section.
He
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Sorry for the silence: new country + new job + no internet connection
outside work = not many opportunities to spend time on this (or any
other part of Python) at the moment.
I do now have a version 0.2 of the deccoeff type, an
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Does the attached patch help fix this at all? I encountered possibly the
same problem on a 64-bit Mac build of Python, and this patch fixed the
problem for me.
--
keywords: +patch
nosy: +marketdickinson
Added file
Mark Hirota <[EMAIL PROTECTED]> added the comment:
I'd like to piggyback on this issue if okay :D
I have some zipfiles I'm working with that contain junk in the extra
fields. The ZipFile object croaks at the call to the
ZipInfo._decodeExtra() call when it could really just
Mark Hammond <[EMAIL PROTECTED]> added the comment:
I instrumented the code a little. The error is happening because
self.client_startupdone never gets set to True. This is supposed to be
set in the client_startupdone() method. It expects an event type of
db.DB_EVENT_REP_STARTUPDONE,
Mark Hammond <[EMAIL PROTECTED]> added the comment:
As discussed with Barry on #python-dev, I committed r66498 which skips
the failing assertion on Windows and replaces it with some noise to
stderr. Note that only that one assertion fails - the rest of the test
passes on Windows.
Also,
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Thanks, Alan. I realised my answer was a shallow one after reading (too
late!) the thread you started on python-dev.
However, I have a suspicion that that particular array test
(test_alloc_overflow) was merely meant to test the c
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
s/Alan/Andrew/. Need more coffee. Apologies.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Mark Hammond <[EMAIL PROTECTED]> added the comment:
We are seeing one more error almost identical to the one I fixed (even
the method name is the same), but its at line 315 - this is the last
error in the Windows buildbot! Please let me know if you would like me
to make a similar "f
Mark Hammond <[EMAIL PROTECTED]> added the comment:
Actually, I've decided to leave it alone. The buildbots most recent
failure was:
test test_bsddb3 failed -- Traceback (most recent call last):
File
"S:\buildbots\python\trunk.nelson-windows\build\lib\bsddb\test\test_repli
New submission from Mark Summerfield <[EMAIL PROTECTED]>:
Py30rc1
On Windows the file object returned by urllib.request.urlopen() appears
to be in binary mode, so .read() returns a bytes object. But on Linux it
appears to be in text mode, so .read() returns a str object. It seeems
to m
Mark Summerfield <[EMAIL PROTECTED]> added the comment:
Sorry, I now can't reproduce it. I made a tiny test script and it worked
fine on both Windows and Linux. Now when I run the real test that works
fine too. So could you close/remove this "bug" for me please?
#!/usr/b
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> So I would suggest either a new directory in the sandbox, or re-using
> Facundo's original directory (which includes the telco benchmark)
Makes sense---thanks for the suggestion!
But since it seems I don't have any o
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Just to be clear: this patch halves the number of shifts and masks,
asymptotically; it doesn't affect the number of adds and multiplies
(except for saving a few additions to zero by setting the initial carry
intelligently
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
--
assignee: -> marketdickinson
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3944>
___
_
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Thanks for the patch, Mario! I'll give a look when I get the chance.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
New submission from Mark Summerfield <[EMAIL PROTECTED]>:
# This program works fine with Python 2.5 and 2.6:
def f():
"""
>>> f()
'xyz'
"""
return "xyz"
if __name__ == "__main__":
import doctest
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Thanks for the updated patch! Looks good, on a quick scan.
(One comment typo I noticed: there's a line
BASE - 3 = 2*MASK - 1
presumably this should be 2*BASE - 3 on the LHS.)
Just out of interest, is it possible to go further,
Mark Hammond <[EMAIL PROTECTED]> added the comment:
pywin32 has a number of files that break in this way - often files
generated by h2py.py
--
nosy: +mhammond
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
New submission from Mark Hammond <[EMAIL PROTECTED]>:
The following source file:
"""
import _winreg
_winreg.OpenKey(_winreg.HKEY_LOCAL_MACHINE, "foo")
"""
results in the following "patch":
-import _winreg
-_winreg.OpenKey(_winreg.H
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Nice work! Seems like we're going to be able to look forward to faster
integer arithmetic in Python 2.7 / 3.1. I'll try to find time to review
your patch properly sometime soon.
Regarding the HAVE_INT64, there's a st
New submission from Mark Hammond <[EMAIL PROTECTED]>:
Create an empty directory with only 2 files, foo.py and bar.py, both
exactly 1 line:
foo.py:
|from bar import bar
bar.py:
|bar = "bar"
Running 2to3 results in the following patch for foo.py:
-from bar import bar
+from
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
The 2**16 in the error message is wrong. Maybe the error message should
be something like:
"Attempt to create array of size larger than maxsize failed to raise
MemoryError."
A bit verbose, but more accurate.
There's
Mark Hammond <[EMAIL PROTECTED]> added the comment:
I must be going crazy, but I can't see r66707 in the trunk, the py3k
branch, or anywhere else in the svn tree. Can you please lend me a
clue-stick?
___
Python tracker <[EMAIL PRO
New submission from Mark Hammond <[EMAIL PROTECTED]>:
All the exception handlers i dustutils.file_utils._copy_file_contents()
are of the form:
|except os.error as e:
|(errno, errstr) = e
This fails to unpack the exception in py3k. I'm attaching a patch that
uses exception
Mark Hammond <[EMAIL PROTECTED]> added the comment:
r66806 on the py3k branch.
--
assignee: -> mhammond
resolution: accepted -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://b
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
It looks as though changing PyLong_SHIFT to 30 everywhere is much simpler
than I feared. Here's a short patch that does exactly that. It:
- changes the definitions in longintrepr.h
- changes marshal.c to write digits as
New submission from Mark Hammond <[EMAIL PROTECTED]>:
The way build_py uses lib2to3 is out of date. Instead of a dummy
Options object a dict should be used, and it seems the 'fixers' must
explicitly be loaded. I'm afraid I don't have a specific patch as I
don't
New submission from Mark Hammond <[EMAIL PROTECTED]>:
The distutils commands 'build_scripts' and 'install_data' both may end
up installing .py files. Such .py file should be able tobe run through
lib2to3 in the same way supported by build_py.
pywin32 has en
Mark Hammond <[EMAIL PROTECTED]> added the comment:
r=me - thanks.
--
keywords: -needs review
resolution: -> accepted
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Changes by Mark Hammond <[EMAIL PROTECTED]>:
--
nosy: +mhammond
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1284316>
___
__
New submission from Mark Dickinson <[EMAIL PROTECTED]>:
Here's a snippet from Python 2.6:
>>> from decimal import Decimal, getcontext
>>> getcontext().prec = 3
>>> Decimal('NaN').max(Decimal('1234'))
Decimal('sNaN234')
The re
1601 - 1700 of 12223 matches
Mail list logo
