Mark Dickinson added the comment:
Thanks for the confirmation, David!
The work in the trunk-math branch should also fix this, in a rather
better fashion (i.e., without per-platform hacks). This issue should probably
be revisited after it's decided whether to merge trunk-math
into the
Mark Dickinson added the comment:
pending -> closed.
--
status: pending -> closed
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue923643>
__
Mark Dickinson added the comment:
Here's a first attempt at Decimal.__format__; the patch is against the
trunk, and should be forward ported as usual to 3.0, with obvious minor
changes related to str/unicode. It still needs some cleanup and some
more tests, but I'm posting it now i
Mark Dickinson added the comment:
I'm wondering what there is left to do here. Are we close to being able
to close this issue? Some thoughts:
(1) I think the docs could use a little work (just expanding, and giving
a few examples). But it doesn't seem urgent that this gets done b
Mark Dickinson added the comment:
I've committed a reworked version of the patch in r61123.
--
resolution: -> accepted
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.
Mark Dickinson added the comment:
Signed zeros cause difficulties with round-tripping, too:
>>> z = complex(-0.0, -0.0); w = complex(repr(z))
>>> z
-0j
>>> w
-0j
>>> z.real
-0.0
>>> w.real
0.0
--
nosy: +marketdickinson
___
Mark Dickinson added the comment:
I don't think this is Mac specific---one of the linux buildbots has also
been having this problem, it seems. I think it's a result of having
an older version of sqlite3 installed.
My OS X 10.4 box has sqlite3 version 3.1.3 installed, and that
versi
New submission from Mark Summerfield:
On Fedora 8 I get this message:
Failed to find the necessary bits to build these modules:
_bsddb
To find the necessary bits, look in setup.py in detect_modules() for the
module's name.
On Kubuntu 6.06 LTS I get the same message, but about different mo
Mark Summerfield added the comment:
On 2008-03-03, Martin v. Löwis wrote:
> Martin v. Löwis added the comment:
>
> Modules/Setup is out of date; _bsddb supports anything between 3.3 and 4.5.
>
FYI, only now I've just realised that Fedora 8's db version is 4.6.21,
but I tho
Mark Summerfield added the comment:
On 2008-03-03, Martin v. Löwis wrote:
> Martin v. Löwis added the comment:
>
> Rereading your report, I cannot quite understand what issue specifically
> you are reporting. What error message do you find confusing, and what do
> you think should
New submission from Mark Summerfield:
In IDLE for Py30a3 if you enter:
>>> class A(
as soon as you type the ( you get the following output to stderr (on
Fedora 8 with Tcl/Tk 8.4):
: *** Internal Error: rpc.py:SocketIO.localcall()
Object: exec
Method: >
Args: ('A',)
Mark Summerfield added the comment:
On 2008-03-03, Martin v. Löwis wrote:
> Martin v. Löwis added the comment:
> > What I find confusing is:
> >
> > Failed to find the necessary bits to build these modules:
> >
> > To find the necessary bits, look in set
Mark Dickinson added the comment:
Coming back to this, I think that it actually *is* clear what
struct(">f", large_float) should do: it should raise OverflowError.
This fits in well with the general philosophy that Python (at least
tries to) follow for floating-point exceptions.
Mark Dickinson added the comment:
The docs say that development for the MacPython OSA modules has stopped,
and that a replacement is expected for Python 2.5.
Can this issue now be closed, or at least have its priority downgraded?
--
nosy: +marketdickinson
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
This is a minor annoyance that's tripped me up before as well. Only
minor, since it only happens when there's something wrong with
decimal.py.
The patch looks sound; I've attached a regenerated version of it
agai
New submission from Mark Summerfield <[EMAIL PROTECTED]>:
Here is how to reproduce the bug:
from xml.etree.ElementTree import parse
import io
xml1 = """
text"""
xml2 = """
text"""
f1 = io.StringIO(xml1)
f2 = io.StringIO(xml2)
tre
New submission from Mark Summerfield <[EMAIL PROTECTED]>:
According to the docs lambda can handle the same parameter list as can
def. But this does not appear to be the case as the following (both
2.5.1 and 30a3) shows:
>>> def f(*a, **kw): return a, kw
>>> f(1,2,a=3,b
Changes by Mark Summerfield <[EMAIL PROTECTED]>:
--
type: -> behavior
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2283>
__
___
Python-b
Changes by Mark Summerfield <[EMAIL PROTECTED]>:
--
components: +Library (Lib), XML
type: -> behavior
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.py
Mark Summerfield <[EMAIL PROTECTED]> added the comment:
On 2008-03-13, Imri Goldberg wrote:
> Imri Goldberg <[EMAIL PROTECTED]> added the comment:
>
> This is not a bug, just missing parenthesis.
>
> >>> lambda x: x,x
>
> Traceback (most recent call l
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Fixed in r61383.
--
status: open -> closed
Tracker <[EMAIL PROTECTED]>
<http://bugs.pyth
New submission from Mark Dickinson <[EMAIL PROTECTED]>:
Grant Edwards pointed out in a comp.lang.python posting that the
documentation for urlopen in the urllib module appears to be self-
contradictory: at http://docs.python.org/dev/library/urllib.html
in the third-to-last paragraph f
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
--
title: Confusing documentation for urllip.urlopen -> Confusing documentation
for urllib.urlopen
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.py
Mark Summerfield <[EMAIL PROTECTED]> added the comment:
You're right that the parser should not recognise "utf8" since it isn't
correct XML (as per the references you gave).
I made the mistake because I used the etree module and wrote an XML file
with encoding "u
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
This issue is currently causing test_tokenize failures in Python 3.0.
There are other ways to fix the test failures, but making tokenize honor
the source file encoding seems like the right thing to do to me.
Does this still seem like
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Michael, is the disappearance of the generate_tokens function in the new
version of tokenize.py intentional?
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Is it worth keeping generate_tokens as an alias for tokenize, just
to avoid gratuitous 2-to-3 breakage? Maybe not---I guess they're
different beasts, in that one wants a string-valued iterator and the
other wants a bytes-valu
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Sorry---ignore the last comment; if readline() doesn't supply bytes
then the line.decode('ascii') will fail with an AttributeError. So
there won't be silent failure.
I'll try thinking fi
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
I'm not opposed to adding factorial somewhere, and it doesn't seem
as though anyone else is actively opposed to factorial either. The
problem is working out where best to put it. To my inexperienced
eyes, it feels wrong to
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
With the patch,
./python.exe Lib/test/regrtest.py test_tokenize
fails for me with the following output:
Macintosh-2:py3k dickinsm$ ./python.exe Lib/test/regrtest.py test_tokenize
test_tokenize
test test_tokenize produced unexpected
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
All tests pass for me on OS X 10.5.2 and SuSE Linux 10.2 (32-bit)!
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.
Mark Summerfield <[EMAIL PROTECTED]> added the comment:
On 2008-03-20, Sean Reifschneider wrote:
> Sean Reifschneider <[EMAIL PROTECTED]> added the comment:
>
> Don't modify Modules/Setup*, do as the message says and modify setup.py.
> Search for "4, 5&quo
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
I'll fix this.
--
nosy: +marketdickinson
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2478>
__
___
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
--
versions: +Python 2.6, Python 3.0
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2478>
__
__
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Fixed in r61892 (2.6) and r61893 (2.5). Thanks for the report!
This bug exposes a flaw in the decimal testsuite: the thousands of
testcases in Lib/test/decimaltestdata are only ever run with an explicitly
given context. Would
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
--
assignee: -> marketdickinson
nosy: +marketdickinson
versions: +Python 2.6
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.py
New submission from Mark Dickinson <[EMAIL PROTECTED]>:
In 3.0, the int and float constructors accepts bytes instances as well as
strings:
>>> int(b'1')
1
>>> float(b'1')
1.0
but the complex constructor doesn't:
>>> complex(b&#x
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
For both these use cases, don't you still have a problem going
the other way, from an integer back to bytes? Is there an easier way
than
bytes(str(n), 'ascii')
?
__
Tracker <
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
I'm not sure that converting to bytes for Python 3.0 is going to
be a simple change. For one thing, most of the arithmetic functions
have to do the reverse conversion (int -> str/bytes) at some point.
At the moment, a
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
str -> unicode regression fixed in r61904, r61906.
(I backported the fix to 2.5; it's not absolutely clear that it's worth
it, but this *is* a bug, and it seems worth not letting the various
decimal.py versio
New submission from Mark Dickinson <[EMAIL PROTECTED]>:
The Python 3.0 version of decimal.py currently stores the coefficient of
a Decimal number (or the payload of a NaN) as a string, all of whose
characters are in the range '0' through '9'.
It may be more t
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
The original bug here is fixed, so I'm closing this issue. I've opened
a separate issue (issue 2486) for discussing changing the Decimal
coefficient from str to bytes.
--
resolution: -> fixed
sta
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Here's a first try at a patch that converts the Decimal coefficient
from type str to type bytes. It needs some work: here are some timings
for a complete run of the test suite (best of 3 in each case) on my
MacBook.
Pyth
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
I agree that the second and fourth cases are bugs.
The second case looks like a Windows only problem: I get the expected
OverflowError on both OS X 10.5.2/Intel and SuSE Linux 10.2/i686.
The fourth case is cross-platform, and occur
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
There are similar problems with integer shifts. In the trunk:
>>> 1>>(2**40)
Traceback (most recent call last):
File "", line 1, in
OverflowError: long int too large to convert to int
and in Python 3.0:
New submission from Mark Summerfield <[EMAIL PROTECTED]>:
# If you run the code below on Py30a3 you get the output shown at the end
import calendar, datetime, time
pastdate = datetime.datetime(1969, 12, 31)
print(pastdate)
timestamp = calendar.timegm(pastdate.utctimetuple())
print(tim
New submission from Mark Summerfield <[EMAIL PROTECTED]>:
The tiny program at the end of this message runs under Python 2.5 &
30a3. Under 2 it gives the following output:
: python sax.py test.xml
('+', u'document')
('+', u'outer')
('+'
New submission from Mark Hammond <[EMAIL PROTECTED]>:
I've taken the liberty of adding Trent, Christian and Martin to the nosy
list as I know they are actively, if reluctantly interested in this.
This patch allows the distutils to cross-compile on Windows. It has
been tested on x8
New submission from Mark Summerfield <[EMAIL PROTECTED]>:
>>> # Py30a3
>>> import locale
>>> locale.setlocale(locale.LC_ALL, "en_US.UTF8")
'en_US.UTF8'
>>> locale.format("%d", 12345, True)
'12,345'
>>>
Mark Hammond <[EMAIL PROTECTED]> added the comment:
Hi Marc-Andre,
The PCBuild/README.txt file has some info about compatibility with VS
versions (but probably needs to say more about x64 builds). There is
also talk about releasing "Profile Guided Optimization" built bina
Mark Hammond <[EMAIL PROTECTED]> added the comment:
I'd like to keep this issue specifically about cross-compilation in the
current tree, and while some of the other ideas may have merit, let's
not bog this issue down with them unless they directly impact the patch.
Does
New submission from Mark Summerfield <[EMAIL PROTECTED]>:
The 30a4 RELNOTES file doesn't cover 30a3 or 30a4.
--
assignee: georg.brandl
components: Documentation
messages: 64918
nosy: georg.brandl, mark
severity: normal
status: open
title: Py30a4 RELNOTES only cover 30a1 an
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
I'm almost tempted to call the first of these a bug: isn't '((x|y)*)*'
a perfectly valid (albeit somewhat redundant) regular expression? What
am I missing here?
Even if there are issues with capturing, sho
Mark Hammond <[EMAIL PROTECTED]> added the comment:
Been sitting here for a while without comment, so:
Sending_winreg.c
Committed revision 62180.
--
resolution: -> fixed
status: open -> closed
_
Tracker <[EMAIL PR
New submission from Mark Hammond <[EMAIL PROTECTED]>:
The move to vs2008 has caused .manifest files to be created next to
distutils created extensions modules, rather than being embedded as
recommended by Microsoft.
See http://msdn2.microsoft.com/en-us/library/ms235591(VS.80).aspx
The at
Mark Hammond <[EMAIL PROTECTED]> added the comment:
Checked in r62197, including the patch from Thomas. Note I expanded the
patch to the distutils doc (noting you need to build Python itself for
the target platform before it works) and added a short entry to Misc/NEWS
--
reso
Mark Hammond <[EMAIL PROTECTED]> added the comment:
I can repro this too using python-2.6a2.msi - after selecting "just for
me" on XP running as a non-admin user, I see an error message regarding
permissions. On vista, I get an elevation prompt (and if I hit "allow",
i
New submission from Mark Dickinson <[EMAIL PROTECTED]>:
The production list for integer literals is missing the `bininteger`
term for binary integer literals. Patch attached.
--
assignee: georg.brandl
components: Documentation
files: bininteger.diff
keywords: patch, patch
me
New submission from Mark Hammond <[EMAIL PROTECTED]>:
The attached patch adds basic UAC support to bdist_wininst created
installers. A new option '--user-access-control' has been added to
bdist_wininst, which is written to the INI file read by the installer.
The installer read
Mark Hammond <[EMAIL PROTECTED]> added the comment:
Note that we are actually using the linker to *generate* the manifest
(something linkers pre VC2005 couldn't do), so if we could tell the
linker to skip that manifest generation and embed it directly in the
DLL, it would certainl
New submission from Mark Summerfield <[EMAIL PROTECTED]>:
In Py30a4's trace.py there is this:
calls = self.calledfuncs.keys()
calls.sort()
which causes:
AttributeError: 'dict_keys' object has no attribute 'sort'
There are two other occurrences
New submission from Mark Summerfield <[EMAIL PROTECTED]>:
A bare * in a parameter list behaves differently depending on what
follows it:
Py30a4:
>>> def f(*, a=1, b=2): return 1
>>> def g(*, **kwargs): return 1
SyntaxError: named arguments must follow bare * (, line
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Closing this: the consensus seems to be that things are fine as they
are.
See the thread at
http://mail.python.org/pipermail/python-3000/2008-April/013100.html
for discussion.
--
resolution: ->
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
--
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2483>
__
___
Python-b
New submission from Mark Summerfield <[EMAIL PROTECTED]>:
At the moment fnmatch.py (and therefore glob.py) support:
* . [chars] [!chars]
The attached version of fnmatch.py extends this to:
* . [chars] [!chars] {one,two,...}
There are 2 changes from the original fnmatch.py file:
(
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
I can reproduce the problem, and agree with the analysis.
Giuseppe, do you have time to produce a patch that fixes
this problem and adds appropriate tests to test_textwrap.py?
--
keywords: +easy
nosy: +marketdickinson
pr
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Sounds good.
What patch? :-)
--
nosy: +marketdickinson
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Got it. Thanks. This may also fix the failure to build cmath on alpha
Tru64.
--
assignee: -> marketdickinson
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.py
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
--
priority: -> normal
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2662>
__
___
Python-b
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Applied in r62418.
Thank you very much!
--
resolution: -> accepted
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
--
priority: -> normal
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2664>
__
___
Python-b
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
This is now fixed in the trunk, as a result of the trunk-math merge.
Closing as 'out of date'.
--
resolution: -> out of date
status: open -> closed
__
Tracker <
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Substantial fixes for the cmath module went into the trunk and the py3k
branches as part of the merge of the trunk-math branch. These fixes
address the asinh problems in this issue, amongst other things. See
r62380 (trunk) and
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
There are some current math and cmath test failures on the Debian alpha
buildbots (2.6 and 3.0), and I think there's a good possibility that
adding -mieee to BASECFLAGS would fix these.
I'm struggling to find the right w
New submission from Mark Dickinson <[EMAIL PROTECTED]>:
test_math and test_cmath currently fail on Debian/alpha, apparently due to
mishandling of subnormal numbers. I have high hopes that this can be
fixed by compiling with -mieee.
The attached patch modifies the configure script to
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
See also issue 1496032.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2685>
__
___
Python-bugs
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Okay---I've added -mieee to BASECFLAGS in r62499, when uname -m reports
alpha* and when gcc is the compiler; I've also added a configure message
that simply reports the output of uname -m, to aid debugging in case
anythi
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
So with this patch, range(10**100) produces an OverflowError: is that
right?
I don't much like this aspect of the change: there are uses for
for i in range(ridiculously_large_number):
...
if condition_that_occurs_early_
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Fixed for Python 2.6 in r62500. Thanks for the report!
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
--
resolution: -> fixed
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2635>
__
__
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
I guess there needs to be a decision on whether to make range objects of
length >= PY_SSIZE_T_MAX illegal; perhaps more discussion on python-dev
would be worthwhile?
I can see three options, besides leaving things as they are:
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> What are the use cases for ranges with length greater than maxsize?
Yeah---I'm a bit short on use cases. The one that originally bit me with
Python 2.x was when I was doing a search for a quadratic non-residue
modulo a
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> Hmm, AFAIKT there is always at least one non-residue between 1 and p
> and therefore you can just write
>
> for i in itertools.count(1):
> if (i_is_a_nonresidue_modulo_p):
> break
>
> maybe with
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Here's a patch that should fix ldexp(x, large_int), as follows:
ldexp(x, n) = x if x is a NaN, zero or infinity
ldexp(x, n) = copysign(0., x) for x finite and nonzero, n large and -ve
ldexp(x, n) -> OverflowError for x finite
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Done in r62499
--
resolution: -> accepted
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Adding -mieee didn't fix the math and cmath problems. Should I revert
the change in r62499, or leave it in? It seems to me that having -mieee
is a good thing on the whole. The main reason to not want IEEE 754
conformance wou
Mark Hammond <[EMAIL PROTECTED]> added the comment:
For those trying to follow along at home: best I can tell we have 3
other issues on this: #1092502 and #1389051 are dupes of an initial bug,
but the fix for those bugs caused regressions reported in this bug and
in #2632. To try and
Changes by Mark Hammond <[EMAIL PROTECTED]>:
--
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2601>
__
___
Python-b
Changes by Mark Hammond <[EMAIL PROTECTED]>:
--
resolution: -> duplicate
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2601>
__
___
Python-b
Mark Hammond <[EMAIL PROTECTED]> added the comment:
FYI, #2632 is tracking a regression caused by this change.
--
nosy: +mhammond
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
There are a couple of problems here. The direct reason for the failure is
that there's an earlier doctest (around line 61 of decimal.py) that sets
the precision of the current context to 18 instead of its default value of
28.
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10149/decimal_localcontext.patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Removed the old patch.
Here's a better patch, that avoids changing the semantics of the
threading tests.
As far as I can tell, the setting and resetting of DefaultContext traps
in DecimalTest's setUp and tearDown meth
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
201 - 300 of 2132 matches
Mail list logo
