On Thu, Mar 27, 2008 at 4:46 AM, Georg Brandl <[EMAIL PROTECTED]> wrote:
> As Nick said, a drop-in replacement in C isn't feasible
>
> But probably users of decimal won't really care if they have to slightly
> adapt their code if they get the speed increase instead.
>
> We had a SOC student workin
On Thu, Mar 27, 2008 at 4:46 AM, Georg Brandl <[EMAIL PROTECTED]> wrote:
>
> As Nick said, a drop-in replacement in C isn't feasible
>
> But probably users of decimal won't really care if they have to slightly
> adapt their code if they get the speed increase instead.
>
Could you give me an examp
On Sun, Mar 30, 2008 at 5:54 PM, "Martin v. Löwis" <[EMAIL PROTECTED]>
wrote:
> If you have the time to figure it all out, sure.
> I found that quite a tedious task, and had to spent
> on some patches quite a long time to figure out what
> they do, and what the 3.x equivalent should be.
>
Is ther
On Sun, Mar 30, 2008 at 6:16 PM, "Martin v. Löwis" <[EMAIL PROTECTED]>
wrote:
> > Is there any easy way that the burden of trunk -> py3k
> > merging could be moved to the original committers of
> > the trunk patches?
>
> I'm not sure I understand the question. If the committer
> of the original pa
Hello all,
test_math is currently failing on the Debian/alpha buildbots (trunk and
py3k).
I've been trying, unsuccessfully, to figure out what's going wrong, and I'm
starting to run out of ideas, so I thought I'd ask the list for help to see
if
anyone has any useful suggestions.
Details of the fai
On Sat, May 31, 2008 at 11:33 AM, Georg Brandl <[EMAIL PROTECTED]> wrote:
>
> Now that the docs are reST, the source is almost pretty enough to display
> it raw, but I could also imagine a "text" writer that removes the more
> obscure markup to present a casual-reader-friendly text version.
>
> Th
On Sun, Jun 1, 2008 at 2:15 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Proposal
>
> Remove non-essential abstract methods like __index__, three argument
> __pow__,
> __lshift__, __rlshift__, __rshift__, __rrshift__, __and__, __rand__,
> __xor__,
> __rxor__, __or__, __ror__, and __
On Tue, Jun 24, 2008 at 8:05 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> Following the discussion in the issue tracker is really hard (since
> most of the discussion apparently refers to earlier versions). I also
> don't see any doc changes.
I think there may also still be room for some
On Thu, Jun 26, 2008 at 8:55 PM, "Martin v. Löwis" <[EMAIL PROTECTED]>
wrote:
>
> I think the feature is misguided in the first place. Why do you want
> a hex representation of floating point numbers?
Answering for myself: because it gives an exact representation of a
floating-point number in a
On Thu, Jun 26, 2008 at 9:28 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Can you show us what APIs and output formats C99 and Java support?
> Maybe we can borrow something from there rather than reinventing the
> wheel?
>
Java's toHexString method is documented at:
http://java.sun.com/java
On Thu, Jun 26, 2008 at 9:30 PM, "Martin v. Löwis" <[EMAIL PROTECTED]>
wrote:
> > Answering for myself: because it gives an exact representation of a
> > floating-point number in a fairly human-readable format.
>
> Ok. But
>
> py> binascii.hexlify(struct.pack("d", 3.14))
> '1f85eb51b81e0940'
>
>
On Thu, Jun 26, 2008 at 9:55 PM, Mark Dickinson <[EMAIL PROTECTED]> wrote:
>
> It's disadvantage from Python's point of view is that some features are IEEE
> 754
Aargh! I can't believe I wrote that. Its. Its. Its. Anyway; some
more detail:
Both C99 and Jav
On Thu, Jun 26, 2008 at 10:28 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Remind me what %a does?
From the C99 standard (section 7.19.6.1):
A double argument representing a floating-point number is converted in the
style [−]0xh.p±d, [...]
___
P
On Thu, Jun 26, 2008 at 10:30 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> ISTM, that the currently proposed output format gives
> us this benefit for free (no changes to the parser). The format is already
> close to the C99 notation but replaces the 'p' with '* 2.0 **' which I find
> to
> b
On Thu, Jun 26, 2008 at 11:00 PM, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Let me remind you that %a currently means "call ascii()" in 3.0.
Oh well. That's out then. I'll rephrase to "I'd be delighted with something
similar in spirit to '%a' support." :-)
Mark
On Thu, Jun 26, 2008 at 11:00 PM, Terry Reedy <[EMAIL PROTECTED]> wrote:
> Definitely. The paper I referenced in the issue discussion,
> http://bugs.python.org/issue3008 mentioned a few times here, is
> http://hal.archives-ouvertes.fr/docs/00/28/14/29/PDF/floating-point-article.pdf
Perhaps it'
On Fri, Jun 27, 2008 at 8:02 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Now that I've learned about the hex float format supported by C++ and
> Java, I wonder if it wouldn't be better to support conversion to and
> from that format and nothing else.
>
> E.g.
>
math.tohex(3.14)
> '0x1.91
On Fri, Jun 27, 2008 at 8:02 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Now that I've learned about the hex float format supported by C++ and
> Java, I wonder if it wouldn't be better to support conversion to and
> from that format and nothing else.
By the way, this particular format is als
On Sun, Jun 29, 2008 at 12:46 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Is everyone agreed on a tohex/fromhex pair using the C99 notation as
> recommended in 754R?
Sounds good to me.
I've attached a Python version of a possible implementation to the issue. See:
http://bugs.python.org/fi
On Mon, Jun 30, 2008 at 4:53 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> FWIW, I'm fine with making these methods on float -- a class method
> float.fromhex(...) echoes e.g. dict.fromkeys(...) and
> datetime.fromordinal(...). The to-hex conversion could be x.hex() --
> we don't tend to use ".
On Sun, Jun 29, 2008 at 3:12 AM, Alex Martelli <[EMAIL PROTECTED]> wrote:
> On Sat, Jun 28, 2008 at 4:46 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>> Is everyone agreed on a tohex/fromhex pair using the C99 notation as
>> recommended in 754R?
>
> Dunno about everyone, but I'm +1 on that.
>
>
I have a general question and a specific question. First the general one:
(1) When is it okay to use C99 code in the Python core? More particularly,
is it considered acceptable to use widely-implemented library functions that
are specified in C99 but not ANSI C, or widely-implemented features th
Does anyone have time to review the patch
http://bugs.python.org/file10876/hex_float5.patch
for issue 3008 (float <-> hexadecimal string conversion):
http://bugs.python.org/issue3008
? It would be really good if this could go in before next week's
beta. Guido's approved the idea in principle, b
On Tue, Jul 15, 2008 at 1:32 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> If there is anything you need a decision on, please follow up to this
> thread. I'm inundated with email so I can't watch every thread on the
> mailing lists. Or ping me on #python-dev.
Can I request permission to check i
On Wed, Jul 16, 2008 at 3:35 PM, Eric Smith
<[EMAIL PROTECTED]> wrote:
> Does anyone know why 'F' is the same as 'f'? Wouldn't it make more sense to
> either drop it, or make it convert the exponent to upper case
What exponent? Isn't the point of 'f' formatting that there is no exponent?
In C,
On Wed, Jul 16, 2008 at 4:14 PM, Daniel Stutzbach
<[EMAIL PROTECTED]> wrote:
> There's no exponent for small-magnitude numbers, but still an exponent
> for large-magnitude numbers:
>
'%f' % (10**100)
> '1e+100'
So there is! Thanks for the correction.
Mark
___
On Wed, Jul 16, 2008 at 4:15 PM, Eric Smith
<[EMAIL PROTECTED]> wrote:
> There's no exponent until the number gets large. I haven't looked up how
> big the number has to get. On my Mac, it's somewhere between 1e50 and 1e60.
I think it's around 1e50, courtesy of the rather oddly-phrased line in
u
On Fri, Jul 18, 2008 at 6:10 PM, Eric Smith
<[EMAIL PROTECTED]> wrote:
> Do we want to document the actual behavior, or do we want to normalize all
> platforms so that they all return 'nan' and 'inf'?
I seem to recall that Christian Heimes recently put some work into
making sure that repr() or str
[Martin v. Löwis]
> Perhaps Tim Peters should also comment here - but if you can come up
> with a patch that does that in a portable way, I would be in favor.
> The challenge, ISTM, is to make it still compile on all systems
> (regardless of how inefficient it might be on minor platforms).
I've ju
On Tue, Nov 4, 2008 at 6:33 PM, Tim Peters <[EMAIL PROTECTED]> wrote:
> Whenever
> two digits are multiplied, the code intends to cast (at least) one of
> them to "twodigits" first (if you ever see a spot where this doesn't
> happen, it's a bug). "twodigits" is typedef'ed to C long. C89
> guarant
On Mon, Nov 10, 2008 at 4:26 PM, Nick Craig-Wood <[EMAIL PROTECTED]> wrote:
>
> Looking at the assembler it produces (x86)
>
> mul:
>pushl %ebp
>xorl%edx, %edx
>movl%esp, %ebp
>movl12(%ebp), %eax
>imull 8(%ebp), %eax
>popl%ebp
>
Here's the test code I was using, modeled on the basic operation
that longobject needs: multiply two digits together and extract
high and low digits from the result.
typedef uint32_t digit;
typedef uint64_t twodigits;
#define SHIFT 30
#define MASK (((digit)1 << SHIFT) - 1)
/* multiply a and b,
On Tue, Nov 11, 2008 at 11:14 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Just trying to clarify the focus: would you like to see any of these
> applied to 2.6? To me, it's clear that they are out of scope now, as
> they don't fix bugs.
There are some minor bugs in longobject.c that I think
As Victor Stinner mentioned in a recent thread, there's a patch in
the works to add a numbits ... um ... gadget to integers, returning
the number of bits needed to represent the integer (or more
precisely, the ceiling of the log to base 2 of the integer). See
http://bugs.python.org/issue3439
Que
On Wed, Nov 12, 2008 at 12:16 AM, Mark Dickinson <[EMAIL PROTECTED]> wrote:
> precisely, the ceiling of the log to base 2 of the integer). See
D'oh. s/ceiling/1+floor/
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://m
On Wed, Nov 12, 2008 at 3:15 PM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> As for numbits, I think it should be a method, because while it's very fast
> for
> the current implementation of longs, it could be longer to calculate for a
> long
> implementation using something other than a power-o
[Antoine Pitrou]
> No, but Python is duck-typed and alternate integer classes could adopt such an
> implementation while trying to respect the Python-level long API.
Good point. That makes me feel a little uneasy about adding numbits
at all. Though I guess there are other parts of Python's integ
Torne,
Many thanks for your input!
> IEEE 754 doesn't include string formatting or parsing as far as I know,
> so I think this is irrelevant to whether we are compliant :)
I think IEEE 754 is relevant. :-)
There's a section 5.6 in the original 1985 standard that's called
something like: "Binar
Update: it looks like IEEE 754-1985 does require that
roundtripping works, at least when the rounding mode
is round-to-nearest. From section 5.6 again:
"""
When rounding to nearest, conversion from binary to decimal and back to
binary shall be the identity as long as the decimal string is carried
On Fri, Nov 28, 2008 at 4:48 PM, Torne Wuff
<[EMAIL PROTECTED]> wrote:
> Thanks for hunting down all that information! I'm in agreement: we
> should fix this so that it works for 17 digits.
Cool. I think this should make porting easier (and not just for
Python, either).
> Are you aware of any co
On Fri, Nov 28, 2008 at 4:48 PM, Torne Wuff
<[EMAIL PROTECTED]> wrote:
> Are you aware of any compliance suite, test vectors, etc we could
> 'borrow' to verify our implementation?
See also the ucbtest package, available from http://www.netlib.org/fp/
___
On Thu, Dec 4, 2008 at 3:12 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Patches for all versions of Python should land in the trunk. They are then
> merged into release26-maint and py3k branches. Changes for Python 3.0 are
> merged via the py3k branch.
Thanks, Christian!
Questions:
(1) If
On Thu, Dec 4, 2008 at 3:12 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Flow diagram
>
>
> trunk ---> release26-maint
> \-> py3k ---> release30-maint
>
I'm running into problems making this work, with a trivial change:
I committed r67590 (which adds a single ass
On Mon, Dec 8, 2008 at 6:51 PM, Adeodato Simó <[EMAIL PROTECTED]> wrote:
>
> The attached patch is a possible way to fix this issue. It'd be great if
> somebody could apply it, or write a more appropriate fix.
Please could you submit your patch to the bug tracker, at
http://bugs.python.org
That
On Tue, Dec 9, 2008 at 5:15 PM, Steve Holden <[EMAIL PROTECTED]> wrote:
> Is anyone aware of any implementations that use other than 64-bit
> floating-point? I'd be particularly interested in any that use greater
> precision than the usual 56-bit mantissa. Do modern 64-bit systems
> implement anyth
On Tue, Dec 9, 2008 at 5:15 PM, Steve Holden <[EMAIL PROTECTED]> wrote:
> precision than the usual 56-bit mantissa. Do modern 64-bit systems
> implement anything wider than the normal double?
I may have misinterpreted your question. Are you asking simply
about what the hardware provides, or about
On Tue, Dec 9, 2008 at 5:24 PM, Mark Dickinson <[EMAIL PROTECTED]> wrote:
> I don't know of any. There are certainly places in the codebase that
> assume 56 bits are enough. (I seem to recall it's something like
> 56 bits for IBM, 53 bits for IEEE 754, 48 for Cray, and
On Tue, Dec 9, 2008 at 9:48 PM, Lie Ryan <[EMAIL PROTECTED]> wrote:
> Why don't we create a DecimalFloat datatype which is a variable-width
> floating point number. Decimal is variable precision fixed-point number,
> while the plain ol' float would be system dependent floating point.
Decimal is *a
Hi all,
I'm having some trouble making some bits of the Python core code
available to extension modules. Specifically, I'm trying to add a
function 'Py_force_to_memory' to Python/pymath.c and then use
it (via a macro) from Modules/cmathmodule.c. But importing of
the cmath module fails with a 'Sy
On Sun, Dec 14, 2008 at 9:06 PM, "Martin v. Löwis" wrote:
> That's not the issue. Had pymath.o been linked into python, it's
> symbols would have been exported (is that proper use of English
> tenses?)
Sounds right to me.
>
> To fix this, I see three solutions
>
> [...]
Thanks for this; this g
On Mon, Jan 5, 2009 at 3:12 PM, Jim Jewett wrote:
> Our of curiousity, why are these constants for internal use only?
I don't think anyone ever thought about deliberately making them
public---I suspect they were introduced as a speed optimization.
I can see that having things like NaN = Decimal(
I noticed that the builtin numeric types (int, float, complex) all still
have a __long__ method in 3.x. Shouldn't this have disappeared as
part of the int/long unification? Is there any reason not to remove this
(by setting the nb_long entry to 0 in all three cases)?
Mark
___
On Sun, Jan 11, 2009 at 7:43 PM, Benjamin Peterson wrote:
> On Sun, Jan 11, 2009 at 12:40 PM, "Martin v. Löwis"
> wrote:
>> There are, apparently, still callers of the nb_long slot, so I would be
>> cautious.
>
> We should remove all usage of it and rename it to nb_reserved.
I see uses of nb_lo
On Thu, Jan 15, 2009 at 9:13 AM, Kristján Valur Jónsson
wrote:
> However, these:
>
> ==
> ERROR: test_ftruncate (test.test_os.TestInvalidFD)
> --
> Traceback (mos
On Thu, Jan 15, 2009 at 4:19 PM, Kristján Valur Jónsson
wrote:
> Well, all the other functions raise OSError when the file descriptor is
> invalid. IOError usually means that the IO itself failed.
> I wonder if it is platform specific? Does it raise IOError on all platforms?
It certainly looks
On Thu, Jan 15, 2009 at 5:06 PM, Kristján Valur Jónsson
wrote:
> Interesting.
> Looks like a bug, really. It's the only function that sets IOError. All
> others use posix_error which raises an OSError.
Maybe. But changing it risks breaking existing code, so would certainly
require (at least)
On Thu, Jan 15, 2009 at 10:40 PM, Kristján Valur Jónsson
wrote:
> Right. I've fixed the remainder, things should quiet down now.
> K
Thank you!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubsc
Now that all uses of nb_long and __long__ have disappeared from
the 3.x codebase, would it make sense to mark PyNumber_Long
as deprecated in the c-api documentation, and convert all existing
uses (I count a grand total of 3 uses in the py3k branch!) to
PyNumber_Int?
(The two functions behave ident
On Fri, Jan 16, 2009 at 10:42 PM, Brett Cannon wrote:
> Assuming we have been moving the C API usage to PyInt and not PyLong,
> then yes it makes sense.
Hmm. I don't think there's been any such move. Maybe there
should be.
Benjamin wondered aloud about deprecating PyNumber_Long
in the issue 49
This is probably a stupid question, but here goes:
Can anyone suggest good strategies for debugging buildbot
test failures, for problems that aren't reproducible locally?
There have been various times in the past that I've wanted
to be able to do this. Right now, I'm thinking particularly of
the
On Sun, Jan 18, 2009 at 11:03 PM, scott mc wrote:
> I built 2.7 on Haiku, but am getting failures in the regression tests.
> Many of them are in math related tests, failing in the 15th decimal
> place on test_decimal and a few others like that, I posted a ticket on
> Haiku's trac for that as it m
Thanks for all the feedback.
[Michael Foord]
> At Resolver Systems we regularly extend the test framework purely
> to provide more diagnostic information in the event of test failures.
> We do a lot of functional testing through the UI, which is particularly
> prone to intermittent and hard to dia
On Fri, Jan 30, 2009 at 4:03 PM, Barry Warsaw wrote:
> To clarify: cruft that should have been removed 3.0 is fine to remove for
> 3.0.1, for some definition of "should have been".
Just to double check, can I take this as a green light to continue
with the cmp removal (http://bugs.python.org/issu
Here's a question (actually, three questions) for python-dev that
came up in the issue 1717 (removing cmp) discussion.
Once the cmp removal is complete, the type object's tp_compare
slot will no longer be used. The current plan is to rename it to
tp_reserved, change its type to (void *), and rais
On Sat, Jan 31, 2009 at 9:28 PM, "Martin v. Löwis" wrote:
> tp_reserved sounds fine. In 3.0.1, filling it with a function pointer
> should give no error, since that would be a binary-incompatible change.
I'm not sure I understand you here. Are you saying that in your
opinion it is safe to chang
On Sun, Feb 1, 2009 at 4:21 PM, Guido van Rossum wrote:
> Sounds like Martin is referring to your suggestion to raise an
> exception when initializing a type that has a non-NULL thing here. I
> agree with him.
Got it. Thank you.
Mark
___
Python-Dev ma
On Sun, Feb 1, 2009 at 6:03 PM, "Martin v. Löwis" wrote:
> No. I thought someone (you?) proposed that it should cause a runtime
> error if a type definitions fills the tp_compare slot. I say that
> 3.0.1 must not produce such an error.
Thanks. I'm with you now. I'll get rid of the relevant bit
On Mon, Feb 2, 2009 at 11:38 AM, Nick Coghlan wrote:
> That's what the -3 command line switch is for - it sets a boolean flag
> that C code can check to see if it should emit warnings for things that
> are going to break in Python 3.x.
Understood. My worry was that we'd get a lot of false positi
On Mon, Feb 2, 2009 at 10:36 AM, Nick Coghlan wrote:
> I'm wondering if Mark should add the exception he recently removed back
> in as a Deprecation Warning when tp_compare is defined, but
> tp_richcompare is not.
This sounds reasonable to me. A third-party module that implements
tp_compare but
On Thu, Sep 29, 2011 at 2:45 AM, Victor Stinner
wrote:
> I would like to suggest the opposite: move platform independdant macros from
> pyport.h to pymacro.h :-) Suggestions:
> - Py_ARITHMETIC_RIGHT_SHIFT
> - Py_FORCE_EXPANSION
> - Py_SAFE_DOWNCAST
Not sure about the other two, but Py_ARITHMET
On Fri, Jan 13, 2012 at 2:57 AM, Guido van Rossum wrote:
> How
> pathological the data needs to be before the collision counter triggers? I'd
> expect *very* pathological.
How pathological do you consider the set
{1 << n for n in range(2000)}
to be? What about the set:
ieee754_powers_of
On Fri, Jan 13, 2012 at 5:43 PM, Guido van Rossum wrote:
>> How pathological do you consider the set
>>
>> {1 << n for n in range(2000)}
>>
>> to be? What about the set:
>>
>> ieee754_powers_of_two = {2.0**n for n in range(-1074, 1024)}
>>
>> ? The > 2000 elements of the latter set have only
On Mon, May 7, 2012 at 12:08 PM, victor.stinner
wrote:
> http://hg.python.org/cpython/rev/ab500b297900
> changeset: 76821:ab500b297900
> user: Victor Stinner
> date: Mon May 07 13:02:44 2012 +0200
> summary:
> Issue #14716: Change integer overflow check in unicode_writer_prepare(
On Mon, May 7, 2012 at 12:35 PM, Mark Dickinson wrote:
> will almost always be one less than a power of 2 and powers of 2 are
> always congruent to 1, 2 or 4 modulo 5, we're safe.
Bah. That should have read "1, 2, 3 or 4 modulo 5".
_
On Sun, Jul 15, 2012 at 1:36 PM, Antoine Pitrou wrote:
> On Sun, 15 Jul 2012 18:47:38 +1000
> Nick Coghlan wrote:
>> I'm not seeing the value in returning None over 0 for the don't know
>> case - it just makes the API harder to use.
>
> The point is that 0 is a legitimate value for a length hint.
On Mon, Sep 10, 2012 at 9:06 PM, Matti Picus wrote:
> Can the authors of the original file help me reconstruct the scripts or
> programs used to generate it, and reformulate them for 32 bit floats?
I used a ctypes wrapper around the MPFR library for most of the
testcases, though some were generat
I suspect I've missed the boat on this one (certainly for 3.3.0), but
here goes. The new TypeError reporting for bad function calls is a
huge improvement (thanks Benjamin!), but I have one small nitpick:
what *is* a positional argument? For example:
>>> def f(x): pass
...
>>> f()
On Thu, Sep 20, 2012 at 1:21 PM, Nick Coghlan wrote:
> +1 for using the unqualified "argument" in these error messages to
> mean "positional or keyword argument" (inspect.Parameter spells it out
> as POSITIONAL_OR_KEYWORD, but the full phrase is far too verbose for
> an error message).
Ah yes; I
On Thu, Sep 20, 2012 at 3:12 PM, Benjamin Peterson wrote:
> As you noted in your next message, keyword-only arguments need to be
> distinguished from these "positional" arguments somehow. Maybe it
> helps to think of "positional" to mean "the only formals you can pass
> to with position" (excepti
On Thu, Sep 20, 2012 at 4:14 PM, Benjamin Peterson wrote:
> 2012/9/20 Mark Dickinson :
>> And excepting optional ones, too, right? E.g., the c in
>>
>> def foo(a, b, c=1, *args, d):
>> pass
>>
>> can be passed to by position, but isn't
On Fri, Oct 19, 2012 at 4:26 PM, Benjamin Peterson wrote:
> 2012/10/19 Antonio Cuni :
>> indeed, you are right. So I suppose that in pypy we could just relax the
>> check
>> in cmath and be happy. Is there any chance that this will be changed in 2.7
>> and/or 3.x?
>
> Certainly 3.x, but not 2.7.
On Fri, Oct 19, 2012 at 5:31 PM, Christian Heimes wrote:
> In order to fix the bug the code in PyComplex_AsCComplex() must be
> altered to support float as return type from __complex__(). That's a
> major change.
Agreed that this doesn't seem appropriate for bugfix releases.
We might also want t
On Fri, Oct 19, 2012 at 3:13 PM, Nick Coghlan wrote:
> Given the way complex numbers interact with floats generally,
> returning a complex number with no imaginary component as a floating
> point value seems legitimate and the checks in cmath overly strict.
> Otherwise you would get redundancy lik
On Sun, Oct 21, 2012 at 6:26 AM, Greg Ewing wrote:
> I think I've changed my mind on this, since it was pointed
> out that if you're going to return a float instead of a
> complex, you should really be implementing __float__, not
> __complex__.
Yes, I'm wavering on this, too. I'm reasonably conv
On Sun, Oct 21, 2012 at 1:23 PM, Stephen J. Turnbull wrote:
> I probably not say that, but even so my personal taste would be to fix
> the docs to describe the current behavior in 2.7. Evidently somebody
> thought "float" was appropriate
The implementation of complex_new is complicated enough th
In Python 2, the 'exec' statement supports 'exec'-ing a (statement,
globals, locals) tuple:
>>> exec("print 2", {}, {})
2
This isn't currently documented at:
http://docs.python.org/reference/simple_stmts.html#the-exec-statement.
It's easy to fix the docs, but in doing so we'd effectively be
bles
On Mon, Nov 5, 2012 at 12:22 PM, Nick Coghlan wrote:
> If you can find an existing test for it, then definitely (although the
> fact it didn't previously work on Jython suggests there may not be
> one).
I don't see any *direct* tests for this feature, though there are a
couple of tests that just
On Fri, Dec 14, 2012 at 7:27 AM, Gregory P. Smith wrote:
> So changing the definition of the dummy side of the union makes zero
> difference to already compiled code as it (a) doesn't change the structure's
> size and (b) all existing implementations already align these on an 8 byte
> boundary.
I
301 - 388 of 388 matches
Mail list logo
